스펙이 새로운 소스코드다? — 가장 뜨거운 주장의 팽팽한 뒷면

2025년 개발 담론의 중심에는 한 문장이 있다. "스펙(specification, 무엇을 만들지 적은 명세)이 새로운 소스코드다." Andrej Karpathy는 "가장 뜨거운 새 프로그래밍 언어는 영어"라고 선언했고, OpenAI의 Sean Grove는 "당신이 짜는 코드는 가치의 10~20%일 뿐, 나머지 80~90%는 구조화된 커뮤니케이션"이라며 버전 관리하고 보존할 1차 산출물은 코드가 아니라 스펙이라고 못박았다. Thoughtworks는 2025년 이 흐름을 spec-driven development(SDD, 스펙 주도 개발)라는 이름으로 핵심 신규 엔지니어링 프랙티스에 올렸다.

거물들이 밀고, 도구가 쏟아진다. 그런데 정말 코드는 부산물이 되는가? 이 글의 입장은 이렇다. "스펙이 새로운 소스코드"라는 방향성 자체는 진지하게 받아들일 가치가 있다. 하지만 아직 컨센서스가 아니다. 특히 강한 형태 — "사람은 더 이상 코드를 만지지 않는다"는 spec-as-source — 는 두 가지 오래된 함정을 동시에 밟을 위험이 있다. 자연어 스펙은 형식적 실행 의미론(execution semantics, 이 문장이 실행되면 정확히 무엇이 일어나는지의 수학적 정의)을 완전히 대체하지 못하고, 그 강한 형태는 과거 Model-Driven Development(MDD, 모델 주도 개발)가 겪은 경직성의 실패를 반복할 수 있다.

지지 진영 — 코드는 손실 있는 투영이다

지지 진영의 핵심 은유는 "투영(projection)"이다. Grove의 논리는 이렇다. 우리가 진짜로 담고 싶은 것은 의도·가치·제약이다. 코드는 그 의도를 특정 언어의 문법으로 눌러 담은 결과물이며, 그 과정에서 "왜 이렇게 했는가"는 대부분 증발한다. 그래서 코드는 스펙의 손실 있는 투영이고, 보존해야 할 원본은 스펙이라는 것이다.

이 주장이 공허하지 않은 이유는 실제 사례가 있기 때문이다. OpenAI의 Model Spec은 그 자체가 markdown 문서 모음이다. 코드가 아니기 때문에 엔지니어뿐 아니라 PM·법무·정책 담당자도 직접 기여하고 리뷰할 수 있다. 즉 스펙이 소스가 되면, 소스를 다룰 수 있는 사람의 범위가 넓어진다. Grove의 표현을 빌리면 "스펙을 마스터한 사람이 가장 가치 있는 프로그래머"가 된다.

Karpathy는 여기에 더 큰 프레임을 얹는다. Software 1.0은 손으로 짠 코드, 2.0은 학습된 가중치, 그리고 3.0은 자연어 프롬프트가 곧 프로그램이 되는 시대다. 자연어가 계산 인터페이스가 되는 흐름에서, 영어로 의도를 기술하는 일이 곧 프로그래밍이 된다는 것이다.

반론 진영 — 충분히 상세한 스펙은 이미 프로그램이다

반론의 칼날은 논리적이다. 기계가 사람 개입 없이 원하는 동작을 정확히 산출할 만큼 상세한 스펙이라면, 그것은 이미 프로그램이다. 모호함이 하나도 남지 않은 자연어 명세는 프로그래밍 언어의 다른 이름일 뿐이며, 그렇다면 "스펙이 코드를 대체한다"는 명제는 "코드를 코드로 대체한다"는 동어반복이 된다.

반대로 스펙에 모호함을 남겨두면, 그 빈칸을 LLM이 비결정적으로 채운다. 같은 스펙에서 매번 다른 코드가 나오고, 여기서 spec drift(스펙과 산출물이 점점 어긋나는 현상)와 hallucination(모델이 없는 사실을 지어내는 현상)이 본질적으로 발생한다. 이것이 spec-as-source의 딜레마다. 스펙을 코드만큼 엄밀하게 쓰면 MDD 시절의 경직성(모든 것을 미리 형식화해야 하는 부담)을 떠안고, 느슨하게 쓰면 LLM의 비결정성을 떠안는다. 두 함정을 동시에 밟을 수 있다는 것이 반론의 핵심이다.

여기서 기시감을 느끼는 사람이 많을 것이다. 2000년대 MDD는 UML 같은 고수준 모델을 원본으로 두고 코드를 자동 생성한다는 이상을 내걸었지만, 모델이 현실의 모든 예외를 담으려다 코드만큼 복잡해지고, 생성된 코드를 손대는 순간 모델과 코드가 어긋나는 문제로 주류가 되지 못했다. spec-as-source의 자연어 스펙은 UML보다 유연하지만, "원본 하나에서 산출물을 내려받는다"는 구조는 동일하다. 달라진 것은 결정적 코드 생성기가 비결정적 LLM으로 바뀌었다는 점인데, 이는 문제를 완화한 게 아니라 새로운 축을 하나 더 얹은 것에 가깝다.

실무 관찰도 이 우려를 뒷받침한다. Amazon Kiro가 사소한 버그 수정 하나를 무려 16개의 acceptance criteria(수용 기준 — 이 조건을 만족하면 완료로 치는 검수 항목)로 부풀리는 사례가 보고됐다. "이럴 바엔 markdown 더미를 읽느니 코드 리뷰가 낫다"는 냉소가 나온다. 스펙이 코드보다 반드시 짧고 명료하리란 보장은 없다는 것이다.

실증 — 담론과 현실의 간극

먼저 SDD 도구가 실제로 어디에 서 있는지 보자. Fowler/Böckeler의 정리에 따르면 SDD 도구는 통제 수준에 따라 세 층위로 나뉜다.

다이어그램 설명. 세 층위는 스펙에 얼마나 큰 권한을 주느냐의 스펙트럼이다. "spec-first"는 스펙으로 시작하되 코드가 여전히 산출물이고 사람이 계속 편집하는 단계, "spec-anchored"는 스펙과 코드가 함께 진화하며 스펙이 지속 참조점이 되는 단계, "spec-as-source"는 사람이 코드를 아예 만지지 않는 단계다. 담론은 "spec-as-source"를 이야기하지만, GitHub Spec-Kit조차 브랜치 하나에 스펙 하나를 붙이는 구조라 실제로는 "spec-first"에 그친다. 사람이 코드를 아예 안 만지는 지점까지 밀어붙이는 도구는 Tessl 정도에 불과하다. 즉 "스펙이 소스"라는 강한 명제는 아직 담론이 앞서가고 구현이 뒤따라오는 상태이고, 자동화가 강해질수록 비결정성과 drift 리스크가 함께 커진다는 대가가 붙는다.

학계의 신호는 양가적이다. 통제된 연구에서 인간이 정제한 스펙을 주면 LLM 생성 코드의 오류가 최대 절반까지 줄었다. 이는 스펙 중심 접근의 강력한 근거처럼 보인다. 그런데 같은 결과를 뒤집으면 이렇게 읽힌다. 개선을 만든 것은 "인간의 정제"였고, "모델 단독의 스펙 해석"은 아직 그 수준에 못 미친다는 뜻이다. 사람을 회로에서 빼는 순간 이득의 상당 부분이 사라질 수 있다.

스펙을 코드의 반대 방향에서 다루려는 시도도 있다. 코드에서 계약(contract)을 역으로 뽑아내려는 연구나 구조화된 스펙에서 리포지토리 전체를 생성하려는 연구가 나오고 있지만, 여전히 실험 단계다.

다이어그램 설명. 스펙을 하나의 원본으로 두고 코드·문서·평가·모델 동작을 "컴파일"해 내려받는다는 spec-as-source의 이상형이다. 문제는 그 컴파일이 컴파일러처럼 결정적이지 않다는 데 있다. "비결정적 컴파일" 분기가 보여주듯 같은 스펙이 매번 다른 결과로 갈라지고, 그래서 이상적 그림의 종착점에는 결국 인간 검증이 다시 끼어들어야 한다. 이것이 강한 spec-as-source가 아직 완결되지 못한 이유다.

잠정 결론 — 아직 컨센서스가 아니다

정리하면, 약한 형태의 SDD(spec-first, spec-anchored)는 이미 유용하고 도구도 성숙 중이다. 스펙을 진지하게 쓰면 코드 품질이 오른다는 증거도 있다. 그러나 "사람은 코드를 안 만진다"는 강한 형태는 다르다. 대규모 사전 스펙 설계에 회의적이고 작은 반복이 최선이라는 실무자들의 유보, 그리고 개선의 열쇠가 여전히 인간의 정제였다는 실증을 함께 놓고 보면, spec-as-source는 방향으로서는 흥미롭되 도착점으로 선언하기엔 이르다. 담론은 뜨겁지만 컨센서스는 아직 없다.

정리 — 스펙트럼으로 읽는다

"스펙이 소스"는 스펙트럼이다. spec-first부터 시작하고, spec-as-source를 최종 목표로 성급히 선언하지 않는다. 스펙의 가치는 실증됐지만, 그 이득의 큰 부분은 "인간의 정제"에서 온다 — 사람을 회로에서 빼는 순간 계산이 달라진다. 스펙을 코드만큼 엄밀히 쓰면 MDD의 경직성, 느슨하게 쓰면 LLM의 비결정성 — 강한 형태는 둘을 동시에 떠안을 수 있다. 그리고 도구의 마케팅 층위(spec-as-source)와 실제 동작 층위(대개 spec-first)를 구분해서 읽어야 한다.

---

참고한 공개 자료:

• Sean Grove, "The New Code" — AI Engineer World's Fair 2025 (https://www.youtube.com/watch?v=8rABwKRsec4)
• Andrej Karpathy, "Software 3.0" — Latent Space (https://www.latent.space/p/s3)
• Exploring spec-driven development tools — Martin Fowler / Birgitta Böckeler (https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)
• The Emperor's New Code: Hype vs Reality of AI-Executable Specs — Medium (https://medium.com/@delimiterbob/the-emperors-new-code-hype-vs-reality-of-ai-executable-specs-ff64d961e8ab)
• 스펙 정제가 LLM 코드 오류를 최대 50% 감소 — SANER 2026, arXiv (https://arxiv.org/html/2601.03878v1)
• From Code to Contract — 코드에서 계약 역추출 연구, arXiv (https://arxiv.org/html/2602.00180v1)
• 구조화 스펙 기반 리포지토리 생성 연구 — arXiv (https://arxiv.org/pdf/2605.02455)

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.