설계 고민만 2주째 하는 개발자가 오늘 바로 동작하는 코드를 뽑아내는 법
TuBrief Editorial
August 9, 2026
0
정신 건강Written with AI assistance from the source video. The video is the authority.
More from the community
Comments (0)
Log in to leave a comment
No posts yet
Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
아키텍처 스펙을 가공하고 머릿속으로 예외 케이스를 시뮬레이션하는 작업은 달콤하다. 머릿속의 코드는 버그도 없고 완벽하니까. 하지만 에디터를 열지 않은 채 고민만 길어지면 그건 신중함이 아니라 그냥 ترس, 즉 실패에 대한 공포일 뿐이다. 불확실성을 피하려고 만든 거대한 설계 문서는 막상 개발을 시작하면 첫 번째 요구사항 변경에 그대로 깨진다.
분석 마비에 빠져 시간을 허비하는 개발자를 위해, 완벽주의를 부수고 오늘 당장 프로토타입을 던져놓는 작업 방식을 정돈했다.
코드 한 줄 쓰기 전에 온갖 프레임워크와 아키텍처를 비교하는 행위는 고도의 인지적 과부하를 부른다. 발생 확률 0.1%도 안 되는 에러 처리에 집착하거나, 요구사항도 안 나왔는데 추상화 레이어부터 쌓는 건 전형적인 손실 회피 반응이다.
McKinsey와 Leadership IQ가 포춘 500 기업을 조사한 결과에 따르면, 결정 장애와 과도한 분석으로 허비되는 시간은 연간 53,000일이 넘는다. 인건비로 치면 2억 5,000만 달러에 달하는 돈이 아무 결과물도 없이 허공으로 날아가는 셈이다. 개발자 개인의 생산성도 사전 최적화 때문에 40% 이상 깎인다.
머릿속 시뮬레이션이 길어진다 싶으면 시스템으로 강제 종료해야 한다. 익스트림 프로그래밍(XP)의 스파이크 솔루션 패턴을 일상에 적용하면 된다.
2주 동안 기획 단계에 묶여 있다면 스펙이 부족한 게 아니라 실행 맥락이 없는 거다. 이럴 때는 설계 문서를 다 끄고 30분 타임박싱을 걸어야 한다.
완성도 30% 프로토타입은 예외 처리, DB 연동, UI 정교함을 전부 덜어낸 상태다. 입력값을 넣었을 때 원하는 결과가 나오는지만 본다. 실리콘밸리 제품 팀들이 추상적인 요구사항 문서 대신 직접 동작하는 프로토타입으로 회의하는 이유도 여기에 있다. 화면을 직접 눌러봐야 불확실성이 사라진다.
지연 비용(Cost of Delay)으로 따져보자. 주당 $2,025를 받는 엔지니어 4명이 2주 동안 아키텍처 회의만 거듭하면 $16,200의 직간접적 손실이 발생한다.
| 평가 항목 | 스펙 중심 개발 | 프로토타입 우선 개발 | 효과 |
|---|---|---|---|
| 초기 요구사항 정의 | 2주~4주 (문서 작성) | 30분~1일 (스파이크 작성) | 시간 90% 절감 |
| 기획 수정 회의 | 평균 8회~12회 (추상적 논쟁) | 평균 2회~3회 (시연 기반) | 회의 70% 감소 |
| 방향성 오류 수정 | 구조 전체 재건축 | 30분짜리 초안 폐기 | 재작업 비용 최소화 |
| PR 검토 속도 | 병목 발생 | Draft PR 선공개 | 리뷰 속도 30% 증가 |
생각과 구현이 섞이면 코드를 쓰다가도 자꾸 뒤돌아보게 된다. 하루 업무 시간을 분석 단계와 무조건 구현 단계로 딱 잘라 나누는 이유다. Basecamp의 Shape Up 방법론이 말하는 '고정된 시간, 가변적인 스코프' 원칙과 같다. 시간을 먼저 정해두고, 그 안에 안 끝날 것 같으면 기능을 버린다.
막히는 구간이 생겼을 때 깊은 사색에 빠지지 않고 우회하는 기준은 마틴 파울러의 기술 부채 사분면 중 '의도적이고 신중한 부채' 개념을 따른다. 나중에 쉽게 바꿀 수 있는 코드라면 지금 가장 단순한 우회로를 택해 커밋하는 편이 낫다.
제프 베조스는 확실성이 70% 수준에 도달했을 때 결정하고 움직이라고 했다. 90% 이상 완벽해질 때까지 기다리는 건 속도를 죽이는 일이다.
코드가 완벽하지 않다고 숨겨두면 나중에 더 큰 재작업으로 돌아온다. Shopify 엔지니어링 팀은 완벽한 코드를 검수받는 게 아니라 작업 방향을 검증받으려고 Draft PR을 올린다.
PR 크기는 200~300줄 이하로 유지하는 게 좋다. "알고리즘 구조 방향성에 대한 피드백만 받습니다"라는 WIP 태그를 붙여 올리면 리뷰어의 부담도 줄어든다.
초기 코드는 내 작품이 아니라 검증할 가설일 뿐이다. 피드백이 오면 빠르게 반영하고 넘어가면 된다.
완벽한 가상 아키텍처는 머릿속을 벗어나지 못한다. 오늘 작성한 엉성하지만 동작하는 초안 한 줄이 내 진짜 실력이 된다. 완벽주의라는 핑계를 버릴 때 지연 비용의 늪에서 빠져나올 수 있다.