[심층분석] "충분히 상세한 명세서는 결국 코드다" — AI 에이전트 코딩의 근본적 한계를 짚다

왜 지금 이 논쟁이 뜨거운가

에이전틱(Agentic) 코딩이 개발 업계의 최대 화두로 떠오른 2026년, 한 가지 매력적인 약속이 개발자들 사이에 퍼지고 있다. "명세서(spec)만 잘 쓰면 AI가 코드를 대신 짜준다." 이 비전은 엔지니어를 코드 작성자에서 명세서 작성자, 즉 일종의 '매니저'로 격상시키겠다는 것이다.

하스켈 생태계의 저명한 블로거 Gabriel Gonzalez가 올린 글 "A sufficiently detailed spec is code"는 Reddit에서 337점, 133개 댓글을 기록하며 뜨거운 반응을 얻었다. 그의 핵심 주장은 단순하면서도 날카롭다: 명세서가 코드를 대체하려면, 결국 그 명세서 자체가 코드만큼 상세해져야 하고, 그 시점에서 명세서와 코드의 구분은 무의미해진다.

핵심 논증: 두 가지 오해를 해부하다

Gonzalez는 에이전틱 코딩 옹호론의 근거를 두 가지 핵심 오해(misconception)로 분류한다.

오해 1: 명세서는 코드보다 단순하다

에이전틱 코딩을 '차세대 아웃소싱'으로 바라보는 시각이다. 엔지니어가 명세서를 작성하고, AI 에이전트 팀에 작업을 분배하면 된다는 논리인데, 이것이 성립하려면 명세서를 쓰는 비용이 코드를 짜는 비용보다 저렴해야 한다. 하지만 현실의 명세서는 모호함을 제거할수록 코드와 동일한 복잡도로 수렴한다.

오해 2: 명세서 단계를 거치면 품질이 올라간다

에이전틱 코딩의 품질 우려에 대한 반론으로, 명세서라는 필터를 통과시키면 더 나은 엔지니어링이 가능하다는 주장이다. 그러나 Gonzalez는 명세서 작성 과정에서 발생하는 사고의 깊이가 코딩 과정과 본질적으로 다르지 않다고 반박한다.

구체적 사례: OpenAI Symphony 프로젝트

Gonzalez는 OpenAI의 Symphony 프로젝트를 직접 분석하며 자신의 주장을 뒷받침한다. Symphony는 에이전트 오케스트레이터로, SPEC.md라는 명세서로부터 생성되었다고 홍보된 프로젝트다.

그런데 이 명세서의 내용을 살펴보면:

• 데이터베이스 스키마의 산문체 나열: session_id, thread_id, turn_id 등 필드 정의가 마크다운 형태로 상세히 기술
• 동시성 제어 로직의 산문체 기술: available_slots = max(max_concurrent_agents - running_count, 0) 같은 수식이 그대로 등장

결국 이 "명세서"는 마크다운 문법으로 포장된 의사코드(pseudocode)에 불과하다. 프로그래밍 언어의 문법만 빠졌을 뿐, 복잡도와 상세함은 실제 코드와 다를 바 없다. Gonzalez의 표현을 빌리면 이것은 "thinly-veiled code" — 얇은 베일을 씌운 코드다.

업계 맥락: 명세서-코드 간극의 오랜 역사

이 논쟁은 사실 소프트웨어 공학의 오래된 주제와 맞닿아 있다.

• MDD(Model-Driven Development): 2000년대 UML 다이어그램에서 코드를 자동 생성하겠다던 시도. 모델이 충분히 상세해지면 코드와 다를 바 없어지는 문제로 주류에서 밀려났다.
• No-Code/Low-Code 플랫폼: 비개발자도 앱을 만들 수 있다고 했지만, 복잡한 비즈니스 로직에서는 결국 코드 수준의 설정이 필요해진다.
• 현재의 에이전틱 코딩: Cursor, Devin, OpenAI Codex 에이전트 등이 경쟁 중이지만, 프롬프트(명세)의 정밀도가 낮으면 결과물의 품질도 낮아지는 근본 문제는 동일하다.

즉 "추상화 수준을 올려 개발 비용을 줄이겠다"는 시도는 반복적으로 같은 벽에 부딪혀 왔다. AI 에이전트도 이 법칙에서 자유롭지 않다는 것이 Gonzalez의 핵심 통찰이다.

한국 개발자에게 미치는 영향

실무적 시사점은 명확하다:

• AI 코딩 도구의 기대치 조절: 에이전틱 코딩은 유용하지만, "명세만 던지면 끝"이라는 환상은 위험하다. 결국 개발자가 상세한 기술적 판단을 내려야 한다.
• 명세서 작성 역량의 재평가: 역설적으로, AI 시대에 더 중요해지는 것은 모호하지 않은 명세를 쓰는 능력이다. 그런데 그 능력은 곧 코딩 능력과 동치다.
• 주니어 개발자 육성 전략 재고: "AI가 코딩을 대체하니 코딩 교육이 불필요하다"는 논리가 위험한 이유를 이 글이 잘 보여준다. 명세를 제대로 쓰려면 코드를 이해해야 한다.
• 기술 의사결정 시 근거 확보: 사내에서 에이전틱 코딩 도입을 검토할 때, 이 글의 논증은 현실적 기대치를 설정하는 좋은 참조 자료가 된다.

마무리

이 글의 메시지는 "AI 코딩이 쓸모없다"가 아니다. 충분히 상세한 명세서는 이미 코드이므로, 명세서와 코드 사이에 마법 같은 추상화 격차는 존재하지 않는다는 것이다. AI 코딩 도구는 분명 생산성을 높여주지만, 개발자의 기술적 사고를 대체하는 것이 아니라 증폭시키는 도구로 이해해야 한다.

토론 질문: 여러분이 실무에서 AI 에이전트에 작업을 맡길 때, 명세(프롬프트)를 얼마나 상세하게 작성하시나요? 그 상세함의 수준이 직접 코딩하는 것과 비교했을 때 실질적으로 노력을 절감해 준다고 느끼시나요?