설계 문서는 완성도가 아니라 공통 이해를 만든다

이 문장을 설계 원칙으로 번역하면

• 설계 문서 = 합의 도구
• 완성도 높은 문서 ≠ 잘 작동하는 조직
• 공통 이해가 생기면 구현은 각자 달라도 된다

왜 “완성도” 집착이 위험한가

• 문서가 정답처럼 소비됨 → 변경이 죄가 됨
• 현실과 어긋나도 문서부터 고치느라 시간 낭비
• 읽는 사람마다 다르게 해석 (길수록 더 심함)
• 결과적으로 문서만 남고 합의는 없음

좋은 설계 문서의 최소 요건 (5가지)

1. 문제 정의가 1페이지 이내
   • “무엇을 만들지”보다 “무엇을 해결하는지”
2. 결정된 것 / 열어둔 것 분리
   • 결정사항(Decision)과 보류사항(Open Question) 명시
3. 변경 포인트 표시
   • 여기서 바뀔 수 있다는 걸 문서가 먼저 말해줌
4. 비결정 이유 기록
   • 왜 안 했는지가 나중에 가장 중요
5. 독자 기준 명확화
   • 이 문서는 개발/기획/운영 중 누굴 위한 문서인지

“공통 이해”가 생겼는지 확인하는 방법

• 회의 후 같은 질문에 같은 답이 나오는가
• 일정/리스크에 대한 인식이 수렴되는가
• 구현 방식은 달라도 방향은 같은가
• 변경이 생겨도 책임 공방이 줄어드는가

실무에서 통하는 문서 전략

• 다이어그램 + 결정 로그면 충분
• 상세 시퀀스/클래스 다이어그램은 필요한 부분만
• 문서는 회의 전·후에만 살아 있고, 그 외엔 참고용
• 최신성 유지 못 할 문서는 아예 만들지 않는다

한 줄 리프레이즈

• “설계 문서는 설명서가 아니라 합의서다.”
• “문서는 완성될수록 가치가 떨어질 수 있다.”