A-2. 일정·범위·완료 리스크
한 줄 요약: 소프트웨어 작업이 끝나 보이는 순간부터 길어지는 구조를 일정, 범위, 통합, 의사결정 비용의 관점에서 설명할 수 있다.
학습 목표
- 90-90 Rule, Hofstadter's Law, Parkinson's Law가 일정 추정에서 가리키는 서로 다른 실패 모드를 설명할 수 있다.
- Brooks' Law를 인력 추가 금지 규칙이 아니라 작업 분할 가능성과 커뮤니케이션 비용을 묻는 질문으로 사용할 수 있다.
- Pareto Principle, Law of Triviality, Wadler's Law를 범위 조정과 회의 운영의 위험 신호로 해석할 수 있다.
- "거의 끝났다"는 표현을 배포 가능한 완료 조건으로 분해할 수 있다.
배경: 왜 이것이 존재하는가
소프트웨어 일정은 기능 구현 시간만으로 결정되지 않는다. 구현 뒤에는 통합, 예외 처리, 접근성 확인, 디자인 QA, 브라우저 차이, 캐시 무효화, 배포 파이프라인, 모니터링, 문서화, 리뷰 반영이 남는다. 프론트엔드는 사용자의 눈에 가장 가까운 계층이라 이 잔여 작업이 더 자주 드러난다. 버튼 하나를 추가해도 loading, disabled, focus, keyboard interaction, analytics, feature flag, 서버 오류 상태가 따라온다.
일정 관련 법칙들은 "개발자는 추정을 못 한다"는 냉소가 아니다. 이들은 작업이 늦어지는 구조가 반복된다는 관찰이다. 이 구조를 이해하면 추정치를 더 크게 부르는 데서 끝나지 않고, 완료 조건을 명확히 하고, 작업을 분리하고, 의사결정 병목을 줄이는 방향으로 움직일 수 있다.
핵심 개념
마지막 10%는 구현 밖에 숨어 있다
90-90 Rule은 코드의 첫 90%와 나머지 10%가 각각 시간의 90%를 차지한다는 농담이다. 농담이 설득력을 얻는 이유는 "완료"의 정의가 중간에 바뀌기 때문이다. 개발자는 처음에 기능이 동작하는 시점을 완료에 가깝게 느끼지만, 제품은 사용자가 다양한 상태에서 신뢰할 수 있게 쓸 때 완료된다.
프론트엔드에서 마지막 10%는 다음 영역에 숨어 있다.
| 숨은 작업 | 드러나는 시점 |
|---|---|
| 오류 상태 | API가 실패하거나 권한이 바뀔 때 |
| 접근성 | 키보드 탐색, 스크린 리더, focus 복귀를 확인할 때 |
| 디자인 QA | 실제 데이터 길이와 반응형 화면을 넣을 때 |
| 성능 | 느린 기기와 느린 네트워크에서 interaction을 볼 때 |
| 배포 | 캐시, 환경 변수, feature flag, rollback을 확인할 때 |
| 운영 | 로그, 알림, 사용자 문의 대응 경로를 준비할 때 |
"거의 끝났다"는 말은 기능 동작을 의미할 수도 있고, 리뷰 요청 가능 상태를 의미할 수도 있으며, 배포와 운영 준비까지 끝났다는 뜻일 수도 있다. 일정 회의에서는 이 표현을 그대로 받아들이지 않고 남은 완료 조건을 나열해야 한다.
지연을 예상해도 다시 지연된다
Hofstadter's Law는 지연을 고려해도 작업이 더 걸린다는 자기 참조적 관찰이다. 추정자는 "이번에는 여유를 넣었다"고 생각하지만, 여유는 보이지 않는 작업을 모두 포함하지 못한다. 특히 새로운 도메인, 새로운 팀 경계, 외부 의존, 브라우저 호환성, 보안 검토가 있는 작업은 추정 오차가 커진다.
이 법칙의 실무적 사용법은 추정치를 무한히 늘리는 것이 아니다. 불확실성을 작업 구조로 바꾼다. 예를 들어 "결제 페이지 개편 2주"보다 "결제 API 계약 확인 1일, 실패 상태 프로토타입 2일, UI 구현 4일, QA와 접근성 2일, 배포 리허설 1일"처럼 불확실성을 분리한다. 모르는 것을 하나의 큰 추정치에 숨기지 않는다.
시간은 작업의 모양을 바꾼다
Parkinson's Law는 작업이 주어진 시간을 채우도록 늘어난다는 관찰이다. 이는 사람이 게으르다는 뜻보다, 품질 기준과 의사결정 폭이 시간에 맞춰 확장된다는 뜻에 가깝다. 시간이 넉넉하면 리팩터링 범위, 디자인 대안, 기술 검토, 테스트 범위가 늘어난다. 시간이 너무 짧으면 실패 상태와 관측 가능성이 잘린다.
따라서 일정은 단순한 마감이 아니라 품질 기준을 정하는 장치다. "이번 릴리스에서 반드시 지킬 완료 조건"과 "다음 릴리스로 미룰 수 있는 개선"을 구분해야 한다. 이 구분이 없으면 짧은 일정은 품질 누락을 만들고 긴 일정은 끝없는 확장을 만든다.
늦은 프로젝트에 사람을 더하는 것은 의존 그래프를 바꾼다
Brooks' Law는 늦은 소프트웨어 프로젝트에 인력을 추가하면 더 늦어질 수 있다는 관찰이다. 핵심은 사람 수가 아니라 작업의 분할 가능성이다. 새 사람이 들어오면 온보딩, 맥락 전달, 리뷰, 충돌 해결, 의사결정 경로가 추가된다. 작업이 병렬화 가능하지 않으면 사람은 처리량보다 조정 비용을 더 늘린다.
하지만 이 법칙은 인력 추가가 언제나 나쁘다는 규칙이 아니다. 다음 조건에서는 도움이 될 수 있다.
| 도움이 될 수 있는 조건 | 위험한 조건 |
|---|---|
| 작업이 명확히 분리되어 있다 | 핵심 설계가 아직 흔들린다 |
| 새 인력이 도메인과 코드베이스를 안다 | 온보딩 문서와 테스트가 부족하다 |
| 리뷰와 승인 경로가 분리된다 | 한 명의 의사결정자에게 모든 질문이 몰린다 |
| QA, 문서, 계측처럼 병렬 작업이 있다 | 같은 파일과 같은 추상화를 동시에 고친다 |
따라서 질문은 "Brooks' Law라서 안 된다"가 아니라 "이 작업은 어떤 축으로 안전하게 쪼갤 수 있는가"다.
80%의 효과와 나머지 20%의 위험
The Pareto Principle은 일부 원인이 대부분의 결과를 만든다는 관찰이다. 제품에서는 상위 사용자 흐름, 핵심 브라우저, 주요 성능 병목, 빈번한 오류에 집중하게 해 준다. 그러나 나머지 20%가 법적 요구, 접근성, 보안, 결제 실패, 데이터 손실과 연결된다면 무시할 수 없다.
프론트엔드에서 "주요 사용자 80%가 데스크톱 Chrome"이라는 사실은 모바일 접근성을 버려도 된다는 뜻이 아니다. 어떤 20%는 낮은 빈도지만 높은 피해를 만든다. Pareto Principle은 우선순위를 정하는 데 쓰되, 피해의 크기와 복구 가능성을 함께 봐야 한다.
사소한 논쟁은 모두가 참여할 수 있어서 커진다
The Law of Triviality와 Wadler's Law는 본질적 설계보다 사소하고 눈에 잘 보이는 주제가 더 오래 논의되는 현상을 설명한다. 시스템 경계, 데이터 모델, 보안 정책은 어렵고 불확실하지만, 버튼 색상, 파일명, formatter 옵션, 문법 스타일은 누구나 의견을 낼 수 있다.
이 문제는 의견을 금지해서 해결하지 않는다. 결정 방식을 미리 정한다. formatter는 자동화한다. naming convention은 문서화한다. 사소한 논쟁에는 시간 제한을 둔다. 본질적 결정은 ADR로 올리고 대안과 기각 이유를 남긴다.
개선은 단기적으로 느려질 수 있다
Hutber's Law는 개선이 처음에는 상황을 악화시킬 수 있다는 관찰로 읽을 수 있다. 테스트 도입은 초기 속도를 늦춘다. 디자인 시스템은 처음에는 컴포넌트 선택과 토큰 논의를 늘린다. TypeScript strictness 강화는 많은 오류를 드러낸다. 이때 단기 생산성 하락을 실패로만 보면 개선은 시작되지 않는다.
하지만 모든 전환 비용이 정당화되는 것은 아니다. 전환이 성공하려면 종료 조건, rollback 경로, 점진적 적용 범위, 관측 지표가 있어야 한다. "지금은 힘들지만 나중에 좋아질 것"이라는 말만으로는 부족하다.
실무 관점
일정 회의에서는 다음 표처럼 선택지를 비교한다.
| 선택 | 얻는 것 | 잃는 것 | 경계 조건 |
|---|---|---|---|
| 인력 추가 | 병렬 가능한 작업 처리량 | 온보딩과 조정 비용 | 작업 경계와 리뷰 경로가 명확해야 한다 |
| 범위 축소 | 배포 가능성 | 사용자 가치 일부 | 핵심 사용자 흐름을 보존해야 한다 |
| 품질 기준 조정 | 단기 속도 | 장애와 유지보수 위험 | 보안, 데이터 손실, 접근성 핵심은 줄이기 어렵다 |
| 릴리스 분리 | 위험 분산 | feature flag와 운영 복잡도 | 독립 배포 가능한 경계가 필요하다 |
| 마감 연기 | 완성도 | 시장·조직 비용 | 남은 작업이 실제로 줄어들어야 한다 |
완료 조건은 "코드 완료"보다 구체적이어야 한다. 예를 들어 검색 기능은 다음처럼 쪼갠다.
- 정상 검색 결과가 표시된다.
- 빈 결과와 오류 결과가 구분된다.
- 느린 네트워크에서 loading 상태가 보인다.
- 중복 제출과 요청 race condition이 제어된다.
- 키보드와 스크린 리더 흐름이 깨지지 않는다.
- 배포 후 관찰할 로그와 지표가 있다.
더 깊이
일정 법칙들은 서로 충돌할 수 있다. Parkinson's Law를 의식하면 시간을 짧게 제한하고 싶어진다. 하지만 90-90 Rule을 의식하면 완료 조건을 더 넓게 잡아야 한다. Brooks' Law는 인력 추가를 경계하지만, Pareto Principle은 핵심 병목에 전문가를 투입하라고 말할 수 있다.
따라서 일정 판단은 법칙 하나로 결정하지 않는다. 작업의 의존 그래프, 실패 비용, 병렬화 가능성, 품질 기준, 외부 의존성을 함께 본다. Phase 10 프로젝트에서는 이 판단을 ADR이나 릴리스 계획에 남긴다. 나중에 추정이 빗나갔을 때 "누가 틀렸는가"보다 "어떤 불확실성을 보지 못했는가"를 학습하기 위해서다.
회고 질문
- "거의 끝났다"는 말에서 아직 검증되지 않은 완료 조건은 무엇인가?
- 인력을 추가한다면 어떤 작업이 독립적으로 분리되는가?
- 사소한 논쟁을 자동화하거나 위임할 수 있는 기준은 무엇인가?
- 이번 일정에서 품질 기준을 줄이면 어떤 피해가 사용자에게 전가되는가?
- 개선 작업의 단기 비용을 언제까지 감수할 것인지 종료 조건이 있는가?
정리
- 일정 지연은 개인의 추정 실패보다 숨은 완료 조건과 의존성에서 자주 나온다.
- Brooks' Law는 인력 추가 금지가 아니라 작업 분할 가능성을 묻는 법칙이다.
- Pareto Principle은 우선순위를 돕지만 낮은 빈도의 높은 피해를 지워서는 안 된다.
- Law of Triviality와 Wadler's Law는 사소한 논쟁을 닫는 팀 규칙의 필요성을 보여 준다.
- 개선의 전환 비용은 종료 조건과 관측 지표가 있을 때만 설득력을 얻는다.
확인 문제
- 프로젝트가 2주 늦어졌고, 팀장은 프론트엔드 개발자 두 명을 추가하자고 한다. Brooks' Law 관점에서 무엇을 확인해야 하는가?
정답과 해설
작업이 병렬화 가능한지, 새 인력이 도메인 맥락을 아는지, 온보딩과 리뷰 비용을 누가 감당하는지, 같은 파일과 설계를 동시에 수정하지 않는지 확인해야 한다. QA, 문서, 계측, 독립 화면 구현처럼 분리 가능한 작업이면 도움이 될 수 있지만 핵심 설계가 흔들리는 상태라면 지연을 키울 수 있다.
- "핵심 사용자 80%만 대응하자"는 말이 위험해지는 조건은 무엇인가?
정답과 해설
나머지 20%가 접근성, 결제 실패, 보안, 데이터 손실, 법적 요구와 연결될 때 위험하다. 빈도만 보지 말고 피해 크기와 복구 가능성을 함께 봐야 한다.
- 팀이 formatter 설정으로 긴 논쟁을 반복한다. Law of Triviality 관점에서 어떤 대응이 적절한가?
정답과 해설
논쟁을 매번 새로 열지 않도록 자동화와 기준 문서를 둔다. 결정권자나 시간 제한을 정하고, 본질적 설계 논의와 스타일 논의를 분리한다.
참고 자료
- <dwmkerr/hacker-laws>: 일정과 범위 관련 법칙의 원문 목록이다.
- Phase 6-5. CI와 배포: 완료 조건에 배포와 검증을 포함하는 관점을 연결한다.
- Phase 7-7. 협업 워크플로: 리뷰와 의사결정 비용을 줄이는 Git 협업 구조를 연결한다.
- Phase 10-1. 프로젝트 가이드: 범위와 완료 조건을 프로젝트 운영 문서로 남기는 방법을 연결한다.