AI 에이전트에게도 예외 없다 — 명세서 기반 개발이 무너지는 경우(Garbage In, Garbage Out)

Symphony SPEC.md로 드러난 슬롭(Slop) 명세의 실체와 신뢰할 수 없는 코드 생성의 원인

쓰레기가 들어가면 쓰레기가 나온다

---

문제 제기: AI 에이전트는 불명확한 명세를 "알아서" 채워주지 않는다

에이전틱 코딩 도구를 쓰는 개발자들은 은연중에 다음과 같이 기대한다.
"명세에 빠진 부분이 있어도 AI가 알아서 채워줄 것이다."

 

이 기대는 틀렸다.

Gabriel Gonzalez는 haskellforall.com에서 내린 결론이다.

"코딩 에이전트는 마음을 읽는 존재가 아니며,
설령 그렇다 하더라도 사고 자체가 혼란스러우면 할 수 있는 것이 없다."

 

"Garbage in, garbage out" 원칙은 AI 에이전트에도 그대로 적용된다.
불명확한 명세를 입력하면 신뢰할 수 없는 코드가 나온다.

 

AI가 빠진 부분을 채우기는 하지만 — 의도와 다른 방향으로 채울 가능성이 크다.

---

공감: Symphony SPEC.md는 왜 실패했는가

OpenAI Symphony의 README는 SPEC.md를 기반으로 에이전트를 구현하라고 권장한다.
다음은 그 결과를 기반으로 Gabriel Gonzalez가 겪은 상황이다.

 

버그 1:
코드가 작동하지 않음.
다수의 버그 발생. 프롬프트를 통한 수정이 반복 필요 (커밋 히스토리에서 확인 가능).

 

버그 2:
에러 메시지 없이 "작동"하는 것처럼 보이는 경우에도,
codex 에이전트가 단순한 Linear 티켓 — "빈 git 리포지토리 생성" — 에 대해 아무 진전 없이 무한 대기했다.

Gonzalez는 이를 Symphony의 "헛된 언어적 정밀성 시도" 라고 부른다.

---

해결: 슬롭(Slop) 명세의 특징을 알면 피할 수 있다

슬롭이란 표면적으로는 명세처럼 보이지만
실제로는 일관성·목적·큰 그림 이해가 결여된 AI 산출물 형태의 문서이다.

슬롭 명세의 특징 4가지

특징 1. 개별 규칙의 나열, 전체 맥락 부재

SPEC.md Section 10.5 예시:
- query는 비어있지 않은 문자열이어야 한다
- 정확히 하나의 GraphQL 연산을 포함해야 한다
- ...

 

각각의 규칙은 그럴듯해 보인다.
그러나 이 규칙들이 왜 존재하는지, 전체 시스템에서 어떤 역할을 하는지가 없다.
구현자(AI 또는 인간)가 규칙의 의도를 알 수 없다.

 

특징 2. 코드 스니펫이 구문 하이라이팅 없이 text로 주석 처리

<!-- 코드가 text 블록으로 처리된 예 -->
available_slots = max(max_concurrent_agents - running_count, 0)

 

이것은 AI 생성 문서의 징후이다.
모델이 "코드처럼 보이는 내용을 포함해줘"라는 요청의 취지가 아닌 문자 그대로를 따른 결과이다.

 

특징 3. 납품 속도에 최적화된 구조

명세가 필요한 이유를 이해하지 않고 "명세 문서처럼 보이는 것"을 빠르게 만드는 데 집중했다는 흔적이 보인다.

 

특징 4. 중복 섹션의 존재

Symphony SPEC.md에는 "Config Fields Summary (Cheat Sheet)" 같은 중복 섹션이 있다.
이것은 AI 에이전트가 코드를 생성할 때 도움이 되도록 명시적으로 추가된 보조 자료이다.
명세가 불충분해서 보충 자료가 필요한 것 자체가 명세의 실패를 보여준다.

---

"주류 언어로 하면 다를 것"이라는 반론

"에이전트가 Haskell 코드 생성에 어려움을 겪는다면,
이는 훈련 데이터 너머로의 일반화 능력 부족을 시사한다."

 

이것은 단순한 언어 문제가 아니다.

AI 에이전트가 훈련 데이터에서 충분히 본 언어에서는 잘 작동하지만 그렇지 않은 경우에는 실패한다.
즉, AI의 이해가 진짜 이해가 아니라 패턴 매칭임을 보여준다.
명세가 불명확할 때 이 한계가 더 크게 드러난다.

---

신뢰할 수 있는 AI 코딩 에이전트 활용을 위한 명세 작성 원칙

Gonzalez의 분석에서 도출할 수 있는 실용적 원칙이다.

 

원칙 1. 각 규칙에 이유를 붙여라

"query는 비어있지 않아야 한다"
대신 "query가 비어있으면 GraphQL 서버가 500 오류를 반환하므로, 클라이언트 측에서 사전 검증이 필요하다."

 

원칙 2. 전체 시스템의 흐름을 먼저 기술하라

개별 규칙 나열 전에
"이 모듈이 전체 시스템에서 어떤 역할을 하는가"를 한 단락으로 쓴다.

 

원칙 3. 엣지 케이스와 실패 시나리오를 명시하라

"정상 작동"만 기술하는 명세는 슬롭이다.
AI 에이전트는 예외 상황에서 명세에 없는 것을 임의로 채운다.

 

원칙 4. 명세가 길어진다면 코드로 직접 쓰는 것을 검토하라

납품 시간 최적화가 목적이라면,
중간 명세 문서를 거치는 것보다 코드를 직접 작성하는 것이 유리하다.

---

마치며

"Garbage in, garbage out"은 AI 에이전트에도 예외 없이 적용된다.

 

불명확한 명세를 입력하면 신뢰할 수 없는 코드가 나온다.
Symphony의 사례는 유명 AI 기업이 만든 프로젝트도 예외가 아님을 보여준다.

 

명세를 빠르게 만들어 AI에 위임하는 것이 목표라면,
그 명세의 품질이 결과의 품질을 결정한다.
빠른 납품을 원한다면 오히려 명세를 거치지 않고 코드를 직접 작성하는 것이 나을 수 있다.

---

📎 참고 출처

• haskellforall.com: https://www.haskellforall.com/2026/03/a-sufficiently-detailed-specification.html