철학·원칙

"좋은 이름" 이 무엇인지에 대해서는 여러 책과 연구가 있습니다. 이 글은 Clean Code · Code Complete · Mythical Man-Month · 인지부하 (Cognitive Load) 이론을 사실 기준으로 정리합니다.

저장소에는 두 종류의 독자를 위한 문서가 공존합니다. 사람과 코드 보조 에이전트 (LLM 기반 IDE 보조 · AI 코더). 이 글은 두 종류의 표준 · 관습.

폴더 구조는 단순한 파일 분류가 아니라, 코드 사이의 의존 방향과 변경 영향 범위를 약속하는 장치가 될 수 있습니다. 이 글은 Feature-Sliced Design · Domain-Driven Design · Hexagonal Architecture 의 사실.

피처 플래그 (feature flag · feature toggle) 는 큰 회사 사례에서 자주 인용되는 패턴. 작은 팀에서도 같은 무게의 기대를 거는 경우가 있는데, 비용과 이득은 환경에 따라 다릅니다. 이 글은 사실 기준으로 정리.

세 머리글자는 소프트웨어 설계 원칙으로 자주 함께 인용. 출처와 의미가 조금씩 다르고, 서로 충돌하는 해석도 있습니다. 이 글은 각 원칙의 출처 · 의도 · 자주 혼동되는 사례.

LLM 기반 코드 보조가 일상화되며 "AI 가 도왔다는 것을 어떻게 표기할 것인가" 가 팀마다 다른 결정으로 갈라졌습니다. 이 글은 관련 사실 (소송 · OSS 라이선스 입장 · 커밋 트레일러 관습) 을 객관적으로 정리합니다.

한 번에 큰 리팩터로 모든 문제를 해결하려는 시도는 자주 실패합니다. 작은 단위로 꾸준히 정리하는 패턴이 더 안정적인 결과를 낸다는 평이 흔합니다. 이 글은 Boy Scout Rule 과 Strangler Fig Pattern.

영어가 아닌 모국어로 문서 · 주석을 적는 선택은 비영어권 개발 팀에서 자주 마주치는 결정. 이 글은 식별자 (영어) 와 문서 / 주석 (모국어) 의 분리 관습 · 유니코드 식별자 표준.

SSOT (Single Source of Truth) 는 데이터 거버넌스 용어에서 시작해 코드 · 문서 · 스키마 운영의 원칙으로 확장. 이 글은 출처 · 적용 영역 · 트레이드오프.

"best practice" 라는 말은 종종 의문 없이 적용되지만, 모든 환경에 똑같이 들어맞는 단일한 답은 드뭅니다. 이 글은 맥락 의존성을 보여 주는 세 고전 (CAP · PACELC · Conway's Law) 의 사실.