충분히 상세한 명세는 코드다

• 에이전틱 코딩이면 "명세 문서로 코드를 대체할 수 있다"는 주장에 대해, 명세가 충분히 정밀해지면 결국 코드와 동일한 형태로 수렴할 수밖에 없다는 근본적 한계 지적
• OpenAI의 Symphony 프로젝트를 보면, 해당 SPEC.md가 명세가 아니라 사실상 마크다운 형식의 의사코드임
• 실제로 Symphony 명세를 기반으로 Haskell 구현을 시도한 결과, 다수의 버그와 에이전트 무한 대기 등 신뢰성 문제 발생
• 명세 작업은 원래 코딩보다 더 깊은 사고를 요구하지만, 현재 업계의 속도 최적화 풍조 속에서 AI가 생성한 저품질 명세가 양산되는 구조
• "garbage in, garbage out" 원칙은 코딩 에이전트에도 그대로 적용되며, 명확성과 디테일이 결여된 문서로는 신뢰할 수 있는 코드 생성이 불가능

에이전틱 코딩의 두 가지 오해

• 에이전틱 코딩 옹호자들이 기대는 두 가지 핵심 오해 존재
  • 오해 1: 명세 문서는 대응하는 코드보다 단순하다 — 엔지니어를 명세 문서를 작성하는 관리자로 전환하고, 에이전트 팀에 작업을 위임할 수 있다는 아웃소싱적 시각
  • 오해 2: 명세 작업은 코딩 작업보다 반드시 더 사려 깊다 — 명세 문서를 거치면 품질이 향상되고 더 나은 엔지니어링 관행이 촉진된다는 주장

명세인 척하는 코드: Symphony 사례 분석

• OpenAI의 Symphony 프로젝트는 명세 문서(SPEC.md)로부터 생성된 에이전트 오케스트레이터로 소개되지만, 실제 SPEC.md의 내용은 명세보다 마크다운 형식의 의사코드에 가까움
• SPEC.md에 포함된 내용 유형:
  • 데이터베이스 스키마의 산문체 덤프 — session_id, thread_id, codex_input_tokens 등 필드 나열
  • 코드의 산문체 변환 — 동시성 제어의 available_slots = max(max_concurrent_agents - running_count, 0) 같은 수식, 재시도 백오프 공식(delay = min(10000 * 2^(attempt-1), agent.max_retry_backoff_ms)) 등
  • 모델의 코드 생성을 돕기 위해 명시적으로 추가된 "Config Fields Summary (Cheat Sheet)" 같은 중복 섹션
  • start_service() 함수처럼 사실상 코드 그 자체인 "Reference Algorithms" 섹션
• 명세 문서가 코드의 대체물이라고 주장하면서 정작 그 문서가 코드처럼 읽히는 것은 기만적
• 명세 문서를 충분히 정밀하게 만들려면 필연적으로 코드 형태로 변형시키거나, 고도로 구조화된 형식적 영어로 작성해야 함

Dijkstra의 "좁은 인터페이스" 논거

• Dijkstra의 글을 인용, 인터페이스 선택이 단순한 노동 분배가 아니며 인터페이스를 넘는 협업과 소통의 비용이 추가됨
• 그리스 수학이 언어적·시각적 활동에 머물러 정체되었고, 이슬람 대수학이 수사학적 스타일로 회귀하며 쇠퇴했으며, 서양 유럽이 중세 스콜라주의의 "헛된 언어적 정밀성 시도"에서 벗어나 Vieta, Descartes, Leibniz, Boole 등의 형식적 기호 체계 덕분에 발전한 역사적 사례 제시
• 에이전틱 코더들은 엔지니어링 노동이 요구하는 "좁은 인터페이스"(= 코드) 를 피할 수 없으며, 그 노동을 표면적으로 다르게 보이지만 동일한 정밀성을 요구하는 형태로 변환할 수 있을 뿐임

불안정성: 명세 기반 코드 생성의 신뢰성 문제

• Symphony README가 권장하는 대로 Claude Code에 Haskell로 구현을 요청한 결과, 작동하지 않음
  • 다수의 버그 발생, 프롬프트를 통한 수정 필요 (커밋 히스토리에서 확인 가능)
  • 에러 메시지 없이 "작동"하는 경우에도 codex 에이전트가 간단한 Linear 티켓("빈 git 리포지토리 생성")에 대해 아무 진전 없이 무한 대기
• Dijkstra의 표현을 빌려 Symphony의 "헛된 언어적 정밀성 시도"가 여전히 신뢰할 수 있는 구현 생성에 실패함을 확인
• 이 문제는 Symphony에 국한되지 않음 — YAML 명세처럼 극도로 상세하고 널리 사용되며 적합성 테스트 스위트까지 갖춘 명세도, 대다수 YAML 구현이 스펙을 완전히 준수하지 못함
• Symphony의 명세는 이미 포함된 Elixir 구현의 1/6 크기에 달하며, 더 확장하면 Borges의 "과학의 정확성에 관하여" — 제국과 동일한 크기의 지도를 만들어 결국 쓸모없게 된다는 우화 — 와 같은 상황에 도달
• "더 주류 언어로 생성하면 결과가 좋을 것"이라는 반론에 대해, 에이전트가 Haskell 코드 생성에 어려움을 겪는다면 이는 훈련 데이터 너머로의 일반화 능력 부족을 시사

슬롭(Slop): AI 생성 명세의 품질 문제

• 명세 작업은 원래 코딩보다 더 어려워야 하며, 코딩 시작 전 프로젝트를 숙고적·비판적 관점에서 바라보도록 유도하는 것이 목적
• 하지만 기술 기업에서 노동을 축소·평가절하하려는 업계 흐름 속에서, "명세 작업이 코딩보다 쉽다"는 전제로 출발하면 실패가 예정됨
• 납품 속도 최적화를 추구하면서 명세 작성이 요구하는 어렵고 불편한 작업을 수행하는 것은 불가능
• Symphony SPEC.md의 Section 10.5(linear_graphql extension contract)가 대표적 슬롭 사례 — "명세처럼 보이는" 문장들의 일관성·목적·큰 그림 이해가 결여된 에이전트 산출물 형태
  • query는 비어있지 않은 문자열이어야 한다, 정확히 하나의 GraphQL 연산을 포함해야 한다 등 개별 규칙이 나열되지만 전체적 맥락이 부재
• 이런 명세 문서는 인간이 작성했더라도 필연적으로 슬롭일 수밖에 없음 — 일관성이나 명확성이 아닌 납품 시간에 최적화했기 때문
• 코드 스니펫이 구문 하이라이팅 없이 text로 주석 처리된 점도 AI 생성 문서의 징후 — 모델이 요청의 취지가 아닌 문자 그대로를 따른 결과로 추정

결론

• 명세는 원래 시간 절약 장치로 설계된 것이 아님
• 납품 시간 최적화가 목적이라면, 중간 명세 문서를 거치는 것보다 코드를 직접 작성하는 것이 유리
• "garbage in, garbage out" 원칙이 그대로 적용 — 명확성과 디테일이 부족한 문서를 입력하면, 코딩 에이전트가 그 부족분을 신뢰성 있게 채워줄 수 있는 세계는 존재하지 않음
• 코딩 에이전트는 마음을 읽는 존재가 아니며, 설령 그렇다 하더라도 사고 자체가 혼란스러우면 할 수 있는 것이 없음