AI가 코드를 대신 쓰게 되면 소프트웨어 개발에서 가장 중요한 산출물은 무엇이 될까? OpenAI에서 alignment(정렬, 모델이 의도한 가치대로 행동하게 만드는 일)를 연구하는 Sean Grove는 2025년 AI Engineer World's Fair 발표 ["The New Code"](https://www.youtube.com/watch?v=8rABwKRsec4)에서 그 답을 **명세(specification)**라고 했다. 명세란 사람이 읽을 수 있는 글로 무엇을 왜 원하는지 적은 문서다. ==코드는 명세를 손실 있게 투영한 결과일 뿐이므로, 의도를 정확한 명세로 옮기는 능력이 핵심 기술이 된다==는 주장이다.

이 문서는 발표 녹취록을 기준으로 주장을 정리하고, 중국 매체 36Kr과 Medium에 실린 반론을 함께 놓고 어디까지 받아들일 수 있는지 판단한다. 인용은 제3자가 자동 생성한 [녹취록](https://lawwu.github.io/transcripts/8rABwKRsec4.html)에서 가져왔으므로 세부 문구는 영상과 다를 수 있다.

## 주장 세 가지

### 소프트웨어 개발은 원래 구조화된 소통이다

Grove는 엔지니어가 만드는 가치 중 코드는 "10%에서 20%"에 그친다고 본다. 나머지는 사용자와 이야기하고(talking), 문제를 이해하고(understanding), 요구사항을 추리고(distilling), 해법을 구상하고(ideating), 계획하고(planning), 공유하고(sharing), 코드로 옮기고(translating), 테스트하고(testing), 의도대로 됐는지 검증하는(verifying) 일이다. 이 흐름 전체가 **구조화된 소통(structured communication)**이고, 코드 작성은 그중 한 단계다. 모델이 그 한 단계를 맡게 되면 병목은 나머지 소통으로 옮겨 간다. 그래서 Grove는 "효과적으로 소통할 수 있으면 프로그래밍할 수 있다"고 말하고, 가장 잘 소통하는 사람이 가장 가치 있는 프로그래머가 된다고 결론짓는다.

### 코드는 명세의 손실 투영이다

발표의 표현은 "code itself is actually a lossy projection from the specification"이다. **손실 투영(lossy projection)**은 JPEG 같은 손실 압축처럼, 결과물에서 원본의 일부 정보를 되살릴 수 없는 변환을 말한다. 코드에는 "무엇을 실행할지"는 남지만 "왜 그렇게 하는지", "무엇을 지키려 했는지", "어떤 대안을 버렸는지"는 남지 않는다. Grove의 말로는 코드가 "의도와 가치를 모두 담고 있지는 않다".

예를 들어 `if (user.age < 14) return showParentConsentForm();`라는 코드만 보고는 14가 개인정보보호법상 법정대리인 동의 기준인지, 기획자가 임의로 정한 숫자인지 알 수 없다. 그러니 "해외 서비스에서는 13으로 바꿔도 되는가"라는 질문에 코드만으로는 답할 수 없다. 반대로 명세에 이유와 경계가 적혀 있으면 그 명세에서 코드를 다시 만들 수도 있고, 다른 언어로 옮길 수도 있고, 문서나 튜토리얼을 파생시킬 수도 있다.

여기서 발표에서 가장 많이 인용된 비유가 나온다. 지금 우리는 AI에게 코드를 생성시킨 뒤 "생성된 코드는 남기고 프롬프트는 지운다". Grove는 이것을 "소스는 파쇄하고 바이너리는 아주 조심스럽게 버전 관리하는" 일에 비유한다.

### 명세는 실행 가능하다

명세가 좋은 기획서에 그친다면 새로운 주장이 아니다. Grove는 명세가 코드처럼 **실행되고 테스트된다**는 점을 근거로 든다. 사례는 OpenAI [Model Spec](https://model-spec.openai.com/)이다.

- Model Spec은 "Markdown 파일 모음"이다. 그래서 엔지니어뿐 아니라 제품, 법무, 안전, 연구, 정책 담당자도 읽고 기여할 수 있다. 명세는 모델을 정렬하기 전에 사람들을 먼저 정렬하는 도구다.
- 조항마다 ID가 있고, ID별로 그 조항을 시험하는 까다로운 예시 프롬프트가 붙어 있다. 이 예시가 성공 기준, 즉 단위 테스트 역할을 한다.
- 2025년 4월 GPT-4o 업데이트 후 모델이 지나치게 아첨하는 문제가 생겼다([OpenAI 사후 분석](https://openai.com/index/sycophancy-in-gpt-4o/)). Model Spec에 이미 "아첨하지 말라(Don't be sycophantic)"는 조항이 있었기 때문에, 이 동작이 합의된 의도와 어긋나는 **버그**라고 판정하고 롤백할 수 있었다. Grove는 명세가 "신뢰의 기준점(trust anchor)"으로 작동했다고 표현한다.

명세를 실행하는 구체적인 방법은 [deliberative alignment](https://openai.com/index/deliberative-alignment/)다. 흐름은 한 줄로 이어진다.

```text
명세 + 조항별 예시 프롬프트
  → 학습 중인 모델이 응답
  → 채점 모델이 명세 기준으로 응답을 채점
  → 점수로 모델 가중치 강화
```

이렇게 하면 같은 문서가 학습 자료와 평가 자료를 겸하고, 원래 추론할 때마다 프롬프트로 넣던 명세가 가중치 안으로 들어간다. Grove는 이 경험에서 명세가 코드와 같은 성질을 갖는다고 본다. 조합(compose)할 수 있고, 실행할 수 있고, 테스트할 수 있고, 현실 세계와 닿는 인터페이스가 있고, 모듈로 배포할 수 있다.

이 관점을 넓히면 미국 헌법도 "국가 단위의 model spec"이 된다. 수정헌법은 버전 관리이고, 사법 심사는 명세 기준의 채점이며, 판례는 테스트 케이스에 해당한다. 그래서 Grove는 "PM이든 입법자든 엔지니어든 마케터든, 명세를 쓰는 사람이 이제 프로그래머"라고 말한다. 미래의 IDE도 문법 자동완성 대신 명세의 모호함을 찾아 해소하게 돕는 "통합 사고 정리 도구(integrated thought clarifier)"가 될 것이라고 전망한다. 발표는 다음 AI 기능을 만들 때 명세부터 쓰고, 그 명세를 모델에 넣고, 명세를 기준으로 테스트하라는 요청으로 끝난다.

## 반론

### 폭포수 모델의 귀환 (36Kr)

36Kr은 발표 내용을 번역해 소개하면서 제목을 "OpenAI가 새 '프로그래밍' 패러다임을 내놨다고? 사실은 폭포수 모델의 귀환: 'PM 말 듣고 요구사항 문서를 써라'"로 달았다([영문판](https://eu.36kr.com/en/p/3388182127870345), 중국 AI 매체 AI Front의 2025년 7월 21일 기사 재게재). **폭포수(waterfall) 모델**은 요구사항 → 설계 → 구현 → 테스트를 순서대로 진행하고 앞 단계 문서가 뒤 단계를 구속하는 개발 방식이다. 요구사항이 바뀌면 대응하기 어렵다는 약점 때문에 애자일(agile)이 등장했다.

다만 "폭포수"라는 말은 제목에만 있고 본문에서 체계적으로 논증되지는 않는다. 본문에 실린 반응은 대체로 이런 내용이다. 이 방식은 엔지니어를 "요구사항 문서를 관리하는 PM"으로 바꾸려는 것이다. 애자일 선언은 원래 개발자가 문서 관리자가 되기를 거부한 결과이며, AI는 오히려 애자일·TDD·BDD가 옳았음을 보여 준다. 새벽 3시에 서비스가 죽으면 디버깅하는 대상은 Markdown이 아니라 코드다. 기사는 또 Grove가 이 방식이 지금 자동으로 돌아간다는 증거를 보여 주지 않았다고 지적한다. 그러면서도 명세 중심 개발이 중요한 전환점이라는 점과, 개발자의 가치가 "바퀴를 발명하는 일"에서 "방향을 정하는 일"로 옮겨 갈 수 있다는 점은 인정한다.

### 코드는 죽지 않았다 (Medium)

Medium의 반론 중 논증이 가장 구체적인 글은 Alexander Olmedo의 ["Code is Not Dead: Why Specifications Aren't the Full Story"](https://medium.com/@olmedo2408/code-is-not-dead-why-specifications-arent-the-full-story-40a654736856)(2025-07-10)다. 핵심은 네 가지다.

1. **모호함을 해소하는 쪽은 코드다.** 자연어 명세는 해석의 여지를 남기지만 코드는 정밀해야 한다. 그러므로 코드는 손실 투영이 아니라 "의도를 정밀하게 실행 가능한 형태로 실현한 것"이다.
2. **결정성(determinism)이 중요하다.** 핵심 시스템에는 예측 가능한 동작이 필요한데 AI 출력은 확률적이다. 그래서 생성된 코드는 코드 수준에서 철저히 검증해야 한다.
3. **진실의 원천은 코드다.** 실행되는 산출물은 코드뿐이고, 장애가 나면 고치는 것도 코드다.
4. **명세만으로 실패를 막지 못한다.** 아첨 조항이 있었는데도 아첨 버그는 배포됐다. 명세는 예방이 아니라 사후 수습에 쓰였을 뿐이다.

이 글도 명세가 사람 사이의 정렬과 상위 계획에 "필수"라는 점은 인정한다. 다만 그것만으로는 충분하지 않고, 시스템 사고, 위험 판단, 성능, 디버깅, 아키텍처 판단은 여전히 엔지니어의 몫이라고 본다.

"실체 없는 과장"이라는 평가에 더 가까운 글은 ["The Emperor's New Code: Hype vs. Reality of AI 'Executable Specs'"](https://medium.com/@delimiterbob/the-emperors-new-code-hype-vs-reality-of-ai-executable-specs-ff64d961e8ab)다. 이 글은 본문에 접근하지 못해 검색 요약으로만 확인했다. 요약에 따르면 Grove가 근거로 든 Model Spec은 가치, 지시, 테스트 케이스를 공들여 쌓은 문서이므로 대충 쓴 바람 목록으로는 같은 효과를 낼 수 없다고 지적한다. 또 OpenAI가 문제가 해결되기 한참 전에 화려한 발표로 기대부터 만드는 경향이 있다고 비판한다. 그러면서도 소통과 명확성이 중요하다는 강조 자체는 틀리지 않았다고 본다.

## 판단: 어디까지 받아들일 수 있나

반론은 Grove 주장의 표현 방식, 특히 "명세가 코드를 대체한다"는 읽기를 겨냥할 때 가장 강하다. "명세를 1급 산출물로 다루자"는 실천적 주장에는 상대적으로 약하다.

**폭포수 비판은 절반만 맞는다.** 폭포수의 문제는 문서를 먼저 쓴다는 것보다 그 문서를 **앞에서 한 번 확정하고 얼려 둔다**는 데 있었다. Grove가 그리는 명세는 버전 관리되고, 조항마다 테스트가 붙고, 아첨 사건처럼 문제가 생기면 고쳐지는 살아 있는 문서다. 헌법 비유에서도 핵심은 수정헌법, 곧 개정이다. 이렇게 운영하면 애자일에서 테스트가 하는 역할에 가깝다. 반면 명세 작성이 PM이나 기획 쪽에 몰리고 구현 피드백이 명세로 돌아오지 않는 조직이라면, 36Kr이 걱정한 대로 폭포수가 그대로 재현된다. 결국 차이는 명세가 아니라 피드백 루프에서 생긴다.

**손실은 양방향이다.** Olmedo의 첫 번째 반론은 Grove의 비유가 놓친 부분을 짚는다. 코드에서 "왜"가 빠지는 것도 사실이지만, 자연어 명세에서 코드로 갈 때는 명세가 정하지 않은 결정, 이를테면 경계값, 오류 처리, 동시성 같은 것이 대량으로 더해진다. 그러니 명세만 남기고 코드를 매번 다시 생성하면 그 결정들이 매번 달라질 수 있다. 두 산출물은 서로 다른 정보를 잃는다. 명세는 "왜"를 보존하고, 코드와 테스트는 "정확히 어떻게"를 보존한다. 하나를 버리는 것이 아니라 둘을 함께 버전 관리하는 것이 합리적인 결론이다.

**아첨 사례는 양쪽 해석이 모두 가능하다.** Grove는 이 사례를 명세 덕분에 버그임을 판정할 수 있었던 예로 들었지, 명세가 버그를 막았다고 주장하지는 않았다. 그러니 "예방에 실패했다"는 반론은 Grove가 하지 않은 주장을 반박하는 면이 있다. 그래도 조항을 적어 두는 것만으로는 동작이 보장되지 않는다는 점은 정확히 보여 준다. 조항이 효과를 내려면 예시 프롬프트와 채점 같은 실행 장치가 실제로 돌아야 한다.

**근거의 범위가 좁다.** Model Spec의 성공은 OpenAI가 학습 파이프라인 전체를 갖고 명세를 가중치에 넣을 수 있다는 조건 위에 있다. 일반 애플리케이션 개발자는 모델 가중치를 학습시키지 않는다. 그 환경에서 "명세를 실행 가능하게 만든다"는 말은 명세에서 테스트, eval, 타입, 계약을 끌어내는 일을 뜻한다. 발표는 이 번역 과정이 자동으로 돌아간다는 증거를 보여 주지 않았고, 이 점에서는 36Kr과 "과장" 비판이 정당하다.

```mermaid
---
config:
  theme: neutral
  flowchart:
    curve: linear
  themeVariables:
    fontFamily: Pretendard Variable, sans-serif
    fontSize: 16px
---
flowchart TD
  accTitle: 명세와 구현의 피드백
  accDescr: 명세에서 구현으로, 구현에서 검증으로 진행한다. 검증에서 발견한 조건과 예외는 명세 개정으로 돌아온다. 실선은 작업 진행이고 점선은 피드백이다.
  spec["명세: 무엇을 왜 원하는가"] -->|작업 진행| code["구현: 구체적인 동작 결정"]
  code -->|작업 진행| test["검증: 의도와 동작 비교"]
  test -. 명세 개정 .-> spec
```

<p class="diagram-caption">그림 1. 실선은 작업 진행, 점선은 명세로 돌아오는 피드백이다. 피드백이 명세 개정으로 이어지는지가 문서를 한 번 확정하고 얼려 두는 방식과의 차이다.</p>

## 적용

이 판단을 실제 작업에 옮기면 다음과 같다.

- **프롬프트와 지시 파일을 버리지 말고 버전 관리한다.** `AGENTS.md`나 `CLAUDE.md` 같은 에이전트 지시 파일은 규칙만 적은 작은 model spec이다. 규칙마다 왜 생겼는지(유래 사건, 날짜)를 함께 적어 두면, 나중에 그 규칙을 바꿔도 되는지 판단할 근거가 남는다.
- **명세 조항마다 그것을 깨뜨리는 예시를 붙인다.** "아첨하지 말라"에 예시 프롬프트가 붙듯, "14세 미만은 보호자 동의"에는 13세·14세·15세 경계 테스트가 붙어야 한다. 예시가 없는 조항은 실행되지 않는 바람에 가깝다.
- **명세와 코드 중 하나를 진실로 고르지 않는다.** 명세는 의도를, 코드와 테스트는 결정을 보존한다. 둘이 어긋나면 어느 쪽이 틀렸는지 판정하는 기회로 삼는다. Grove가 아첨을 버그로 판정한 방식이 바로 이것이다.
- **피드백이 명세로 돌아오는지 확인한다.** 구현하다 발견한 모호함이나 예외가 명세 개정으로 이어지지 않으면 폭포수가 된다.