AI에게 휘둘리지 않으려면 스펙부터 써라 — 'Specsmaxxing'이 던지는 새 규율

요즘 개발자 커뮤니티에서 조용히 번지는 단어가 하나 있습니다. Specsmaxxing인데요. 직역하면 “스펙을 최대치로 끌어올리기"쯤 되는데, AI 코딩 도구에 휘둘리지 않으려면 코드를 짜기 전에 YAML 스펙부터 빡세게 작성하라는 새로운 규율입니다. 왜 갑자기 이런 단어가 떠올랐을까요.

AI 코딩이 만들어낸 새로운 병, ‘AI 사이코시스’

Cursor, Claude Code, Copilot 같은 도구를 써보신 분이라면 한 번쯤 겪어보셨을 겁니다. 처음엔 신나게 코드를 만들어내다가, 어느 순간부터 AI가 엉뚱한 파일을 건드리고, 이전 결정을 뒤집고, 같은 버그를 세 번째 다른 방식으로 고치는 상황 말이죠.

개발자들은 이걸 AI 사이코시스(AI psychosis)라고 부르기 시작했습니다. 사람도, AI도 같이 정신줄을 놓는 상태를 가리키는 반쯤 농담 섞인 표현인데요. 컨텍스트 윈도우가 늘어지고, 의도가 흐려지고, 결국 “내가 뭘 만들려고 했더라"가 되는 순간입니다. 자연어 프롬프트만으로는 이 흐름을 잡기 어렵다는 게 핵심입니다.

Specsmaxxing이 뭐길래

Specsmaxxing의 핵심 주장은 단순합니다. 코드를 한 줄도 짜기 전에 YAML(또는 마크다운) 형식의 명세부터 완성하라는 겁니다. 그것도 아주 구체적으로요.

• 무엇을 만드는지 (목표, 비목표)
• 입력과 출력의 정확한 형태
• 엣지 케이스와 실패 시 동작
• 의존성과 제약 조건
• 테스트 시나리오

YAML을 쓰는 이유는 명확합니다. AI가 가장 잘 읽고, 가장 일관되게 해석하는 구조화 포맷이기 때문입니다. 자연어로 “사용자 인증 잘 만들어줘"라고 하면 매번 다른 결과가 나오지만, 스키마로 정의하면 흔들림이 줄어듭니다. 일종의 인간과 AI 사이의 계약서인 셈이죠.

“프롬프트는 휘발되지만 스펙은 남는다”

흥미로운 건 이 방법론이 단순한 생산성 팁이 아니라는 점입니다. 지지자들은 스펙 문서가 시스템의 진짜 소스 오브 트루스가 되어야 한다고 주장합니다. 코드는 그 스펙을 구현한 결과물일 뿐이라는 거죠.

이 관점에서 보면 재밌는 역전이 일어납니다. 지금까지 우리는 코드를 짜고 그걸 문서로 정리했지만, Specsmaxxing은 문서를 짜고 그걸로 코드를 생성합니다. AI가 충분히 똑똑해진 시대에는 사람이 손으로 다듬어야 할 진짜 자산이 코드가 아니라 명세라는 발상의 전환입니다.

실제로 한 번 스펙을 잘 짜두면 같은 문서를 가지고 Claude로도, GPT로도, Gemini로도 동일한 결과물을 뽑아낼 수 있습니다. 도구에 종속되지 않는 자산이 만들어지는 거죠.

그런데 이게 진짜 새로운 이야기일까

솔직히 말하면, Specsmaxxing은 새로운 발명은 아닙니다. 요구사항 명세서, 설계 문서, TDD는 소프트웨어 공학이 수십 년간 강조해온 것들이죠. 베테랑 개발자들이 “이거 그냥 옛날에 하던 거잖아"라고 말하는 이유입니다.

차이는 동기에 있습니다. 과거의 명세는 사람 협업자를 위한 것이었습니다. 지금의 명세는 AI 협업자를 위한 것입니다. AI는 사람보다 훨씬 빨리 코드를 뽑아내지만, 그만큼 빨리 잘못된 방향으로도 달려갑니다. 잡아줄 가드레일이 없으면 한 시간 만에 5천 줄짜리 카오스를 만들죠.

그래서 아이러니하게도, AI 시대일수록 사전 설계의 가치가 올라갑니다. “바이브 코딩"으로 시작해서 “스펙 코딩"으로 회귀하는 흐름이 보이는 이유입니다.

실무에서 어떻게 적용할까

당장 도입해보고 싶다면 이렇게 해보세요. 먼저 작은 기능부터 시작하는 게 좋습니다. 거창한 전체 시스템 스펙은 부담스럽고 결국 안 쓰게 됩니다.

기능 단위로 .spec.yaml 파일을 하나 만들고, 거기에 목표·입력·출력·엣지 케이스를 적습니다. 그 파일을 AI에게 컨텍스트로 던지면서 “이 스펙에 맞춰 구현해달라"고 요청하면, AI가 중간에 헤매도 다시 스펙으로 돌아오게 만들 수 있습니다. 일종의 닻(anchor) 역할입니다.

스펙 자체를 AI와 함께 다듬는 것도 좋은 방법입니다. 내가 빠뜨린 엣지 케이스를 AI가 짚어주는 경우가 의외로 많거든요.

마치며

Specsmaxxing이 만병통치약은 아닙니다. 하지만 AI 코딩이 일상이 된 지금, “그냥 시키고 받기"의 한계를 느낀 개발자라면 한 번쯤 시도해볼 가치가 있습니다.

결국 질문은 이겁니다. AI가 코드를 더 빨리 짜줄 수 있는 시대에, 사람이 진짜로 잘해야 하는 일은 무엇일까요. 어쩌면 답은 키보드를 두드리는 손이 아니라, 무엇을 만들지 정확히 정의하는 머리에 있는지도 모르겠습니다.