Context Is King: Rethinking Domain Ownership, Product, and the "Spec Phase"
If you’ve spent any time recently writing detailed product requirement documents or meticulously...
개요 #
제품 요구사항 문서(PRD)나 티켓 명세를 정성 들여 써본 사람이라면 한 번쯤 이상한 역설을 느꼈을 것이다. 이슈를 빈틈없이 명세하는 것 자체가 이미 문제 해결에 필요한 작업의 90%라는 점이다.
Dev.to 창립자 Ben Halpern은 최근 글에서 이 역설이 소프트웨어 개발 방식, 팀 협업, 그리고 "경쟁력 있는 개발자"의 정의까지 조용히 바꾸고 있다고 주장했다. 컨텍스트를 모으고, 엣지 케이스를 정리하고, 사용자 흐름을 그리고, 기대 동작을 다른 사람이 마찰 없이 실행할 수 있을 만큼 상세히 적고 나면 — 무거운 정신적 노동은 이미 끝난 상태다. 그 명세를 코드로 옮기는 일은 점점 쉬운 부분이 되어가고 있다.
'부품으로서의 개발자'는 끝났다 #
과거의 소프트웨어 개발은 조립 라인 모델에 가까웠다. PM이 상세한 스펙을 쓰고, 엔지니어링 리드에게 넘기면, 리드가 하위 티켓으로 쪼개 개발자에게 배분하는 식이다. 개발자의 역할은 기계 속 부품이었다. 티켓을 받아 스펙대로 코드를 짜고 QA로 넘기면 끝.
Halpern은 이 모델이 애초에 이상적이지 않았다고 짚는다. 사일로를 만들고, 일에 대한 무관심을 낳고, 커뮤니케이션 루프를 비대하게 만들었다. 그래도 어쨌든 굴러는 갔다.
하지만 지금은 사정이 다르다. 아이디어와 실행 사이의 마찰이 줄어들자, 전통적인 핸드오프의 오버헤드가 가장 큰 병목이 되었다. 제품 정의와 코드 딜리버리 사이에서 벌어지는 '전화 게임(games of telephone)'이 팀 속도를 기어가는 수준으로 떨어뜨리는 동안, 컨텍스트가 풍부한 팀은 몇 바퀴씩 앞서 나간다. 예전 방식은 이제 비효율적인 정도가 아니라 경쟁 자체가 안 되는 방식이라는 얘기다.
'스펙 단계'라는 마찰 #
Photo by Hammad Khalid on Pexels
완전한 스펙을 쓰는 데 인지적 노력의 90%가 든다면, "일을 생각하는 사람"과 "일을 구현하는 사람" 사이의 끊임없는 핸드오프는 엄청난 저항을 만든다. 도메인 오너십이 기본 요건(table stakes)이 된 이유가 여기에 있다.
개발자가 도메인을 진짜로 소유하면 — 문제 공간, 사용자, 시스템 아키텍처, 비즈니스 목표를 깊이 이해하면 — 어색하고 비용 큰 '스펙 단계'를 건너뛸 수 있다. 다음 기능을 만드는 데 10페이지짜리 PRD가 필요 없다. 컨텍스트가 이미 머릿속에 있기 때문이다. 스펙이 완성되기를 기다리지 않고, 실시간으로 트레이드오프를 판단하고 제품 결정을 인라인으로 내리면서 문제에서 문제로 유연하게 옮겨 다닌다.
개발자와 PM의 경계가 다시 그려진다 #
이 변화가 PM의 소멸을 뜻하지는 않는다. 다만 역할의 경계는 훨씬 유동적으로 변한다. Halpern은 두 가지 방향을 제시한다.
- PM이 된 개발자. 많은 영역에서 개발자가 곧 프로덕트 매니저다. 도메인 컨텍스트를 쥐고 있으니 다음에 뭘 만들어야 할지 스스로 판단하고, 머릿속에서 스펙을 잡아가며 곧바로 출시한다.
- 빌더가 된 PM. 반대 방향의 워크플로우도 있다. PM이 로우코드 도구나 스크립트, AI 모델로 기능을 90%까지 끌고 간다 — 동작하는 프로토타입을 만들고, 데이터 흐름을 잡고, 초기 구조를 세우는 식이다. 나머지 10%를 개발자가 넘겨받아 마무리한다.
그 마지막 10%가 왜 중요할까. 단순해 보이는 기능도 깊은 기술적 성찰을 요구하기 때문이다. 아키텍처 정합성, 대규모 트래픽에서의 성능, 엣지 케이스 방어, 보안, 장기 유지보수성 — 전부 그 10% 안에 들어 있다.
'경쟁력 있는 소프트웨어'라는 움직이는 골대 #
지금 추세만 보면 이런 생각이 들기 쉽다. 모델과 도구가 좋아지면 그 마지막 10%도 결국 사라지고, 버튼 하나로 소프트웨어가 알아서 만들어지고 유지되는 날이 오지 않을까?
Halpern은 이 관점이 소프트웨어 시장의 작동 방식을 놓치고 있다고 반박한다. 코드 생성이 싸고 빨라질수록 "경쟁력 있는 소프트웨어"의 기준선도 계속 올라간다. 3개월 걸리던 기능이 3일 만에 나오면, 고객의 기대치도 그만큼 높아진다. 제품을 돋보이게 하는 기준은 더 높은 수준의 완성도, 더 깊은 통합, 더 탄탄한 성능, 더 나은 사용자 경험으로 이동한다.
마지막 10%는 사라지지 않는다. 더 미묘하고 정교해질 뿐이다.
결국 남는 것: 문제 컨텍스트와 품질 기준 #
우리는 문법적으로 코드를 얼마나 뽑아내는지, 미리 포장된 경직된 스펙을 얼마나 잘 실행하는지로 가치를 재던 시대에서 벗어나고 있다. Halpern이 꼽는 현대 소프트웨어 엔지니어링의 진짜 레버리지는 두 가지다.
- 문제 컨텍스트 관리(Problem Context Management). 사용자의 니즈, 비즈니스 목표, 시스템 아키텍처를 체화해서, 스펙을 기다리지 않고도 높은 수준의 판단을 즉석에서 내리는 능력.
- 품질 임계점(Quality Thresholds). AI든 동료든 PM이든, 누가 만들었든 90% 완성된 결과물을 보고 프로덕션 수준 — 확장 가능하고 회복력 있는 상태 — 까지 가려면 정확히 뭐가 더 필요한지 아는 능력.
도구는 계속 진화할 것이고 코드를 쓰는 방식도 계속 바뀔 것이다. 하지만 깊은 도메인 컨텍스트를 쌓고 품질에 타협하지 않는 기준을 유지하는 엔지니어는 경쟁에서 살아남는 정도가 아니라, 속도를 정하는 쪽에 서게 될 것이라는 게 글의 결론이다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.