브리프(Brief)와 스펙(Spec)은 같은 것이 아닙니다

우리는 초기에 많은 팀이 현재 겪고 있을 법한 상황을 경험했습니다.

한 엔지니어가 월요일 아침에 업무를 맡았습니다. 월요일 오후에는 코드가 작성되었습니다. 화요일에는 리뷰를 거쳐 머지(Merge)되었습니다. 수요일이 되자 PM은 스탠드업(Standup) 미팅에서 실제로 무엇이 배포되었는지 묻고 있었습니다. PR(Pull Request) 설명이 그녀가 이해했던 업무 내용과 정확히 일치하지 않았기 때문입니다.

기능은 작동했습니다. 테스트도 통과했습니다. 다만... 디자이너가 명시한 내용과 완전히 일치하지 않았고, PM이 브리프(Brief)를 작성할 때 의도했던 바와도 완전히 일치하지 않았습니다. 그리고 엔지니어는 — 합리적으로 — 자신이 할 수 있는 유일한 방법인 스스로 판단(Make a call)을 내림으로써 그 간극을 메웠습니다.

누구도 잘못한 것은 없었습니다. 브리프는 브리프가 모호한 일반적인 방식대로 모호했습니다. 과거의 타임라인이었다면, 그 모호함은 구현(Implementation) 과정 중에 드러났을 것입니다. 엔지니어가 막히거나, 질문을 하거나, 무언가 맞지 않는다는 이유로 PR을 되돌렸을 것입니다. 루프 안의 인간(Human in the loop)은 충분히 느렸기에 이를 잡아낼 시간이 있었습니다.

AI는 느리지 않았습니다. AI는 스스로 판단을 내리고 계속 진행했습니다.

저는 속도가 팀이 붕괴되는 방식에 특정한 영향을 미친다고 생각하게 되었습니다.

우리가 구축해 온 조정 메커니즘(Coordination mechanisms) — 디자인 리뷰(Design reviews), PM 승인(PM sign-offs), 스펙 워크스루(Spec walkthroughs), 심지어 단순히

제가 계속해서 목격하는 점은 "우리는 이것을 논의했다"와 "우리는 스펙(Spec)이 있었다"가 같은 것처럼 느껴지지만, 실제로는 그렇지 않다는 것입니다.

브리프(Brief)는 의도(Intent)입니다. 그것은 무엇(what)과 왜(why)에 관한 것이며, 대개 제품(Product) 관객을 위해 작성됩니다. 구현(Implementation)에 중요한 방식들, 즉 조건, 엣지 케이스(Edge cases), AI 에이전트(AI agent)가 어디서 멈춰야 하는지를 알려주는 명시적 제외 사항(Explicit exclusions)들이 구현 관점에서는 대개 불충분하게 명시되어 있습니다.

스펙(Spec)은 실행 가능한 의도(Executable intent)입니다. 누군가가 브리프를 단 하나의 합리적인 해석만이 존재할 정도로 구체적인 무언가로 번역했을 때 얻게 되는 결과물입니다. 완료된 상태는 어떤 모습인가? 무엇을 할 수 없는가? 어떤 제약 조건(Constraints)이 적용되는가? 누가 무엇을 결정했는가?

이 둘 사이의 간극이 바로 조정 실패(Coordination failure)가 발생하는 지점입니다. PM(Product Manager)은 브리프가 있었기 때문에 스펙 논의가 이루어졌다고 생각합니다. 엔지니어(Engineer)는 브리프가 명확해 보였기 때문에 논의가 이루어졌다고 생각합니다. AI는 간극이 존재한다는 사실조차 알지 못하며, 주어진 것에 따라 확신을 가지고 구축해 나갑니다.

우리가 정착한 패턴은 원칙적으로는 충분히 간단하지만 실행하기에는 더 어려운 방식이었습니다: 빌드(Build)가 시작되기 전에 스펙을 작성하는 것입니다. 엔지니어 혼자서도, PM 혼자서도 아닙니다. 누구도 터미널(Terminal)을 열기 전에, 함께 동일한 문서 내에서 작성합니다.

디자이너(Designer)는 예상 결과(Expected results)를 작성합니다. PM은 조건을 설정합니다. 리드(Lead)는 경계(Boundaries)를 그립니다. 그러고 나서 — 오직 그때서야 — AI 에이전트가 스펙을 입력값(Input)으로 받게 됩니다.

이것이 구조적으로 하는 역할은 정렬(Alignment)에 관한 대화를 빌드 이후가 아닌 빌드 이전으로 옮기는 것입니다. 스펙에 대한 검토가 디자인 리뷰(Design review), PM 승인(PM sign-off), 그리고 범위 설정(Scoping) 대화가 한꺼번에 이루어지는 과정이 됩니다. AI가 작업을 마치면, PR(Pull Request)은 모두가 합의한 내용을 반영하게 됩니다. 왜냐하면 모두가 스펙에 합의했고, 스펙은 AI가 그에 맞춰 구축한 것이기 때문입니다.

속도는 사라지지 않습니다. 오히려 개선됩니다. 스펙이 더 잘 정의되었다고 해서 AI가 느려지는 것이 아닙니다. 오히려 여러분이 이틀 동안 되돌려야 할 추측(Guesses)을 하지 않기 때문에 더 빨라집니다.

여기에는 조직적인 변화(Organisational shift)도 포함되어 있으며, 이 부분이 가장 많은 적응을 필요로 하는 대목입니다.

스펙(Spec)은 팀의 산출물(Artifact)이어야 합니다. 누군가가 혼자 작성하여 에이전트(Agent)에게 건네주는 프롬프트(Prompt)가 아닙니다. 한 사람의 머릿속이나 한 사람의 에디터(Editor)에만 존재하는 문서도 아닙니다. 결과물에 이해관계가 있는 모든 사람이 코드가 존재하기 전에 실제로 읽고 승인(Sign off)한 공유 문서여야 합니다.

이는 PM(Product Manager)의 역할을 변화시킵니다. 브리프(Brief)를 작성하고 PR(Pull Request)을 기다리는 대신, PM은 스펙(Spec)에 참여하여 조건을 설정합니다. 디자이너(Designer)의 역할도 변화합니다. 결과물을 검토하는 대신, 예상되는 결과를 사전에 형성합니다. 리드(Lead)의 역할도 변화합니다. 아키텍처 제약 사항(Architectural constraints)은 검토 과정에서 발견되는 것이 아니라, 빌드(Build)가 시작되기 전 스펙(Spec)에 경계(Boundaries)로서 작성됩니다.

AI는 훌륭한 협업(Coordination)이 무엇인지에 대한 정의를 바꾸지 않습니다. 단지 협업을 건너뛰었을 때 어떤 일이 발생하는지를 매우 빠르게 드러낼 뿐입니다.

Penling은 이를 위해 우리가 만든 도구입니다. 누군가 터미널(Terminal)을 만지기 전에 스펙(Spec)이 작성되는 공유 워크스페이스(Shared workspace)이며, 작성된 스펙은 MCP를 통해 코딩 에이전트(Coding agent)에게 직접 전달되고, 작업이 완료되어 배포(Ship)될 때 PR과 함께 저장소(Repository)에 커밋(Commit)됩니다. 작업에 참여하는 모든 사람은 AI가 구축을 시작하기 전, 동일한 시간에 동일한 산출물(Artifact)을 공유합니다.

스탠드업(Standup) 대화도 바뀌었습니다. "실제로 무엇을 배포했는가"라는 질문은 훨씬 줄어들었고, "계획대로 정확히 진행되었다"라는 말이 훨씬 많아졌습니다.

이 글은 스펙 주도 개발(Spec-driven development) 도입에 관한 시리즈의 일부입니다. 첫 번째 파트는 왜 스펙(Spec)이 AI 출력의 신뢰성을 높이는지에 대해 다룹니다. 두 번째 파트는 코드가 병합(Merge)된 후 추론(Reasoning)에 어떤 일이 일어나는지를 다룹니다.