명세 기반 개발(Spec-Driven Development)이 50년 된 철의 삼각형을 깨뜨리는 방식

5명. 3개월. 몇 주 동안 작성된 명세서(specs), 길어질수록 마치 진전이 있는 것처럼 느껴지는 그런 종류의 문서 말입니다.

저는 회의에 참석해 질문 하나를 던졌습니다. "우리는 이것을 왜 만드는 건가요?"

아무도 대답하지 못했습니다. 잘못된 대답이라도 좋았을 것입니다. 하지만 제가 얻은 것은 아무런 대답도 없었습니다. 명세서는 '어떻게(how)'를 설명하는 데 급급했고, 아무도 '왜(why)'를 방어하기 위해 멈춰 서지 않았습니다. 그 질문을 던진 지 10분 만에 명세서는 사라졌습니다. 수정된 것이 아니라, 사라졌습니다.

의도(intent)가 회의실에 등장하자, 문서의 대부분은 무의미해졌습니다.

의도가 명확해지자, 실제 해결책은 이틀짜리 작업이 되었습니다. 좋습니다, 음, 아마 열흘 정도 걸릴 수도 있겠네요. 첫 번째 방식은 5명이 3개월이 걸렸지만, 두 번째 방식은 열흘이 걸렸습니다. 계산해 보세요. 명세서는 우리를 약 $96,000의 비용으로 몰고 가지만, 의도는 우리를 약 $16,000로 이끕니다. $80,000라는 금액은 명세서와 질문 사이의 간극에 놓여 있었습니다.

$80,000가 핵심은 아니었습니다. 핵심은 질문 하나가 전체 프레임을 움직였고, 그 명세서의 단 한 줄도 그 질문을 던지는 것을 고려하지 않았다는 점입니다. 명세서는 완벽하고 상세했지만, 가장 중요한 단 한 가지에 대해 틀렸으며, 그 완벽함이야말로 회의실에서 그 사실을 숨겼던 바로 그 요소였습니다.

우리가 균형을 맞추던 삼각형

30년 동안 소프트웨어는 프로젝트 관리의 '철의 삼각형(iron triangle)'이라 불리는 하나의 삼각형 안에 머물러 있었습니다: 시간(time), 비용(cost), 품질(quality). 이 중 두 가지만 선택할 수 있었죠. 빠르고 저렴하지만 품질은 낮거나, 빠르고 품질은 좋지만 비싸거나, 품질은 좋고 저렴하지만 느리거나 말입니다. 우리가 구매했던 모든 방법론은 어떤 모서리를 포기할지 선택하는 서로 다른 방식일 뿐이었습니다.

에이전틱 코딩(Agentic coding)이 그 삼각형을 깨뜨렸지만, 대부분의 팀은 이를 알아차리지 못했습니다.

속도(Speed)가 가장 먼저 사라졌습니다. 과거에는 두 가지 방식으로 속도를 샀습니다. 인력을 더 투입하여 엔지니어를 늘리고 비용을 높이거나, 혹은 팀이 처음부터 시작하지 않아도 되게끔 미리 만들어진 자산과 프레임워크인 가속기(accelerators)를 사용하는 것이었습니다. 이제 에이전트(agent)는 팀이 몇 주 걸려 배포하던 것을 몇 시간 만에 배포합니다. 따라서 속도는 더 이상 구매하는 것이 아니라 고객이 당연하게 여기는 것이 되었습니다. 그것은 기본 요건(table stakes)이 되었습니다. 이제 속도는 삼각형 밖에 존재합니다.

가속기(accelerator) 또한 형태를 바꾸고 있으며, 저는 다음 글에서 다룰 예정이기에 여기서는 아이디어만 제시하겠습니다. 자산을 미리 구축하는 것을 중단하는 것입니다. 의도(intent)와 기대치(expectations), 즉 클라이언트 전반에 걸쳐 유지되는 부분들을 준비해 두고, 클라이언트에게는 그들만의 유일한 조각인 컨텍스트(context)를 제공하게 합니다. 소프트웨어는 필요가 실제로 발생했을 때 구축되며, 그 전에는 구축되지 않습니다. 저는 이를 프로토-소프트웨어(proto-software), 즉 클라이언트의 컨텍스트가 호출할 때까지 의도로서 대기하는 소프트웨어라고 부릅니다. 그리고 의도, 컨텍스트, 기대치라는 세 가지 요소를 모두 앞에 두게 되면, 구축에 토큰(token)이 얼마나 비용으로 들지 마침내 확인할 수 있습니다. 그것이 다음 기사의 주제입니다.

다음은 품질(Quality)이었으며, 더 조용하게 진행되었습니다. 품질은 바닥으로 내려앉았습니다. 결정론적 검사(deterministic checks), 평가(evals), SonarQube와 같은 도구들이 이제 사람이 모든 차이(diff)를 읽지 않아도 품질을 유지해 줍니다. 품질은 타협해야 하는 모서리(corner)가 아니라, 용접하여 고정해 버리는 바닥(floor)이 되었습니다. 그리고 바로 여기에 위험이 도사리고 있습니다. 속도가 공짜가 되고 토큰이 주시해야 할 숫자가 될 때, 품질을 의도적으로 바닥에 못 박아두지 않는다면 품질은 어둠 속에서 무너지는 모서리가 됩니다.

따라서 두 개의 모서리가 사라졌습니다. 하나는 기본 요건(table stakes)이 되었고

그 계량기(meter)는 이미 무섭게 돌아가고 있습니다. Uber는 Claude Code 도입률이 엔지니어의 84%까지 급증한 이후, 약 4개월 만에 2026년 AI 코딩 예산을 모두 소진했습니다. 엔지니어 1인당 지출은 월 500달러에서 2,000달러에 달했습니다. Uber의 CTO는 그들이 다시 원점으로 돌아왔다고 말했습니다. COO는 진짜 질문을 명확하게 던졌습니다. 해당 지출과 출시된 가치(shipped value) 사이의 연결 고리가 "아직 존재하지 않는다"는 것입니다. Microsoft의 한 부서는 비용 문제로 Claude Code 사용을 취소하고 엔지니어들을 자체 개발 도구로 이동시켰습니다. 계량기는 돌아가고 있고, 가격은 위로 재조정되고 있으며, 가치 측면은 여전히 불확실합니다. 비용은 지금 당장 눈앞에 존재하지만, 가치는 당신이 증명해야 할 과제입니다.

우리는 이전에 의도(intent)를 유지하려 노력해 왔습니다

의도를 유지하는 데 실패하는 것은 새로운 일이 아니며, 이를 해결하려는 시도 또한 새로운 것이 아닙니다. 가장 명확한 시도는 Agile(애자일)이었습니다. Agile은 대화의 흐름을 진전시켰습니다. '출시하고 기도하기(ship and pray)' 대신 '스프린트(sprints)', '사용자 스토리(user stories)', '출시 후 학습(ship and learn)'을 도입했습니다. 그리고 그 형식(ceremony)의 이면에서는 팀들에게 '왜(why)'를 유지하고 문서에 숭배하는 것을 멈추라고 요구했습니다. 하지만 팀들은 Agile을 주기가 더 짧은 명세(spec) 프로세스로 변질시켰습니다. 똑같은 문서, 똑같은 프론트 로딩(front-loading)을 단지 2주 단위로 수행하게 된 것입니다. 문제는 해결책보다 더 오래 지속되었습니다. 왜냐하면 그 해결책이 실제로 무엇을 위한 것인지 아무도 명명하지 않았기 때문입니다. 해결책은 형식이 아니라, 그 형식이 드러내고자 했던 '의도(intent)'였습니다.

이것은 어떤 방법론도 벗어날 수 없는 부분입니다. 프레임워크(framework)는 추진력이 가득한 방 안에 앉아

나는 곧장 아키텍처(architecture)로 직행했습니다. 단 한 줄의 코드도 실행되기 전에 전체 그림, 계층 다이어그램(layered diagram), 모든 박스가 제자리에 있는 구조를 만들려 했습니다. 나는 한 가지 버전을 만들어냈습니다. 그것은 틀렸습니다. 또 다른 버전을 만들었습니다. 더 깔끔했지만, 여전히 틀렸습니다. 박스들은 올바르게 보였고 용어(vocabulary)도 적절했지만, 전문가라면 4초 만에 알아챘을 방식으로 핵심을 놓치고 있었으며, 나는 네 번의 시도 끝에 이를 깨달았습니다.

그때 나는 멈췄고, 발밑의 바닥이 꺼져 내려가는 듯한 기분을 느꼈습니다. 내가 무엇을 하고 있는지 보았기 때문입니다. 나는 명세(spec)를 먼저 작성하고 있었습니다. 충분히 구축하여 이해하지도 못한 대상의 설계 전체를 앞단에 몰아넣고(front-loading) 있었습니다. 나는 일주일 내내 비판하며 글을 써왔던 바로 그 행동을 실행하고 있었습니다.

그래서 나는 아키텍처를 내려놓았습니다. 실제로 실행 가능한 가장 작은 형태, 즉 내가 필요한 몇 개의 박스만을 정의하고 그 외에는 아무것도 만들지 않았습니다. 그리고 나머지는 더 많이 알게 되었을 때 채워 넣겠다고 말했습니다. 모든 것을 미리 그릴 수 있는 척하는 것을 멈춘 순간, 작업의 정체가 풀렸습니다.

내가 이를 잡아낼 수 있었던 이유는 이미 그것을 찾고 있었기 때문입니다. 그것이 유일한 이유입니다. 그 요소를 제거한다면, 나도 9만 6천 달러짜리 명세를 가진 팀이 될 것이고, 당신도 마찬가지일 것입니다.

에이전트적 철의 삼각형 (The Agentic Iron Triangle)

철의 삼각형(iron triangle)은 고객과의 계약을 지배했습니다. 작업이 실제로 일어나는 현장에서는 그 후계자가 그 자리를 이어받았으며, 이는 재구성된 철의 삼각형이기에 이름을 붙일 가치가 있습니다. 이를 '에이전트적 철의 삼각형(Agentic Iron Triangle)'이라 부릅시다. 세 가지 기존 제약 조건은 여전히 존재합니다. 에이전트 기반 코딩(agentic coding)은 단지 각 요소를 이동시켰을 뿐입니다. 시간(Time)은 속도(Speed)가 되어 기본 요건(table stakes)으로 물러났습니다. 품질(Quality)은 평가(evals)가 지탱하는 바닥 수준으로 떨어졌습니다. 그리고 여전히 살아있는 한 축인 비용(Cost)은 두 개로 나뉘었습니다.

그 분리가 전부입니다. 이제 당신은 작업을 완수하기 위해 두 가지를 소비합니다. 토큰(tokens), 그리고 에이전트(agents)를 지시하고 머릿속에 의도(intent)를 유지하는 데 필요한 주의력(cognition), 즉 당신 자신의 인지 능력입니다. 품질(Quality)은 그 아래 바닥에 머물며 협상의 여지가 없는 상태가 됩니다. 품질이 조용히 미끄러지지 않도록 붙잡아주는 결정론적 파이프라인(deterministic pipeline)이 되기 때문입니다. 그리고 속도(speed)는 더 이상 당신이 선택할 수 있는 타협점이 아닙니다. 그것은 앞서 말한 두 가지 레버(levers)가 당신에게 가져다주는 결과물이며, 상한선이 존재합니다. 당신은 오직 토큰과 당신의 주의력이 허용하는 만큼만 빠르게 움직일 수 있으며, 둘 중 더 희소한 것이 고갈되면 벽에 부딪히게 됩니다.

이것이 질문을 바꿉니다. OpenAI와 Anthropic의 빠른 모델들은 효과적이고, 중독성이 있으며, 저는 그것들을 사랑하지만, 동시에 비쌉니다. 그리고 그것들에 의존하는 것이 바로 함정입니다. 그러니 단일 에이전트가 얼마나 빨리 끝내는지를 묻지 마십시오. 당신의 머리가 더 이상 부하를 견딜 수 없을 때까지 한 번에 얼마나 많은 에이전트를 실행할 수 있는지를 물으십시오. 이제 속도는 모델이 빨라지는 것이 아니라 병렬화(parallelization)에서 나옵니다. 명확한 의도(intent)를 바탕으로 많은 에이전트를 실행함으로써 토큰으로 속도를 사거나, 더 적은 수의 에이전트를 직접 더 강하게 몰아붙임으로써 주의력으로 속도를 사는 것입니다. 어떤 방식이든 당신은 대가를 지불하며, 청구서는 이 두 가지 중 하나로 날아옵니다.

해결책

어쩌면 해결책이란 없을지도 모릅니다. 애자일(Agile)은 명세(spec) 프로세스로 퇴보했습니다. 어쩌면 ICE는 30개의 필드로 구성된 의도 양식(intent form)으로 퇴보할 것이고, 우리는 문 앞에 새로운 이름만 붙인 채 다시 이곳으로 돌아오게 될 것입니다. TDD(테스트 주도 개발) 역시 살아남지 못했으며, 지금의 저 또한 SDD(명세 기반 개발)를 비난하며 IDD(의도 기반 개발)가 나아갈 길이라고 말하고 있습니다. 제 방식이 영원할 것이라고 가장하지는 않겠습니다. 하지만 저는 여전히 노력하고 있으며, 저에게 유효한 것은 다음과 같습니다.

각 방법론이 해체되고 있다는 것을 알면서, 업계가 우리가 본 적 없는 속도로 개념들을 집어삼키고 있다는 것을 알면서도 저는 무엇을 해야 할까요? 바이브 코딩(Vibe coding)은 6개월 만에 죽었습니다. SDD는 1년도 안 되어 무너지기 시작했습니다. 어쩌면 IDD는 조금 더 오래 살아남을지도 모릅니다. 하지만 그 무엇도 다음 행보를 바꾸지는 못합니다. 왜냐하면 행보는 결코 방법론(method)이 아니었기 때문입니다. 그것은 올해 어떤 이름으로 불리든 그 밑바탕에 깔린 규율(discipline)입니다.

나는 무엇을 하는가

나는 무엇보다 먼저 바닥을 용접합니다. 평가(evals)는 이미 구축되어 있으며, 그것들이 결코 생략되지 않도록 보장합니다.

나는 이를 위해 나의 대화를 이해하고 거기서부터 실타래를 이어가는 기술인 'craft-ice'를 만들었습니다. 나는 단 한 문장으로 의도(intent), 즉 이것이 누구를 위한 것인지와 그들이 무엇을 필요로 하는지를 전달합니다. 만약 한 문장으로 말할 수 없다면, 나는 멈춥니다. 왜냐하면 아직 그것을 이해하지 못했기 때문입니다. 그런 다음 나는 그 의도와 기대치가 일치하는지 확인하고, 오직 그럴 때만 움직입니다. 만약 일치하지 않는다면, 나는 다시 시작합니다.

맞습니다, 시간이 걸립니다. 하지만 그만한 가치가 있습니다.

그것이 내가 하는 일 중 가장 저렴하면서도 레버리지(leverage)가 높은 일입니다. 또한 그것은 단지 입력(input)일 뿐입니다. 나머지는 내가 두 가지 레버를 어떻게 사용하는가에 달려 있습니다. 나는 가장 빠른 모델을 찾는 것이 아니라, 그 의도에 따라 많은 에이전트(agents)를 병렬로 실행함으로써 속도를 확보하며, 내 머리가 여전히 감당할 수 있는 만큼만 실행합니다. 에이전트들 사이의 맥락을 놓치는 순간이 바로 나의 한계에 도달한 시점이며, 그 한계를 억지로 넘어서려고 할 때 바로 품질이 떨어지기 시작합니다.

그리고 나는 더 이상 처음부터 전체를 구축하지 않습니다. 하네스(harness)가 시스템을 고정하고 내 머릿속에 대략적인 형태를 유지해주지만, 개별적인 플레이(plays)는 실제 필요가 생길 때 구축됩니다. 첫날에는 쓸 수 없었던 아키텍처(architecture)는, 구축 과정이 나에게 그것이 무엇인지 가르쳐준 뒤 며칠이 지나면 스스로 작성됩니다. 그것이 바로 프로토-소프트웨어(proto-software) 방식의 움직임입니다.

당신이 CTO 또는 CIO라면

당신은 모든 의도를 직접 작성할 수 없으며, 그래서도 안 됩니다. 당신이 할 수 있는 일은 누군가가 '왜(why)'를 책임지게 만드는 것입니다. 모든 빌드(build) 시점에 '이것이 누구를 위한 것인가?'와 '만약 이것이 존재하지 않는다면 그들에게 무엇이 망가지는가?'를 묻는 것이 직무인 사람을 지정하고, 바로 그 사람이 의도를 제공하는 사람이 되도록 하십시오. 책임자가 없는 결정은 '왜'라는 질문이 조용히 사라지는 지점입니다.

그리고 당신이 무엇을 측정하는지 지켜보십시오. 만약 당신의 대시보드(dashboards)가 작성된 명세(specs)와 출시된 기능(features)의 수를 센다면, 팀은 바로 그것을 당신에게 줄 것이며, 그 작업이 실제로 필요했는지 여부는 결코 논의되지 않을 것입니다. 더 어려운 것을 측정하십시오. 작업이 시작되기 전에 이것이 누구를 위한 것인지 물어본 사람이 있는지를 측정하십시오. 이제 당신의 역할은 산출물(output)을 세는 것이 아니라 가치(value)를 정의하는 것입니다.

그리고 코드 그 이상을 검토하는 기술을 구축하십시오. SonarQube와 Snyk는 이미 코드를 처리하고 있습니다. 당신에게 아직 없는 기술은 의도(intent) 자체를 검토하고, 코드 한 줄이 작성되기 전에 ICE를 확인하는 기술입니다. 바로 그 기술을 구축하십시오.

엔지니어라면

당신의 의도를 구축하는 기술을 기르십시오. 코드를 작성하는 것은 LLM(Large Language Models)과 하네스(harness)가 쉽게 만들어 놓은 부분입니다. 이제 갖춰야 할 가치 있는 기술은, 그들이 가장 잘하는 일을 하도록 안내하는 소프트웨어를 작성하는 것입니다.

그리고 사용된 토큰(tokens) 양으로 자신을 측정하지 마십시오. Peter Steinberger는 OpenAI의 Codex를 사용하여 오픈 소스 프로젝트를 구축하는 동안, 130만 달러 상당의 한 달 치 토큰 6030억 개를 사용했다고 게시했습니다. OpenAI가 비용을 지불했고, 그는 그곳에서 일합니다. 토큰 사용량을 게시하는 대부분의 사람들은 그 비용을 지불하지 않습니다. 하지만 당신은 지불하게 될 것입니다. 리더보드(leaderboard)의 상단에 오르기 위해서가 아니라, 소프트웨어를 출시하기 위해 똑똑하게 구축하고 토큰을 사용하는 사람이 되십시오. 당신의 전략(plays)을 세우고, 그 결과와 토큰 비용을 모두 측정하십시오.

SDD가 이를 붕괴시키는 이유, 그리고 IDSD가 이를 되살리는 이유