머릿수가 적을수록 spec에 의존하라 · leejk

TL;DR. vibe coding — AI에게 시킨 코드를 읽지 않고 통째로 받아들이는 방식 — 은 버릴 코드엔 옳다. 틀린 건 *"소형·1인이니까 vibe"*라는 면죄부다. 축은 팀 크기가 아니라 그 코드가 살아남느냐고, 1인은 면제가 아니라 가장 취약한 쪽이다 — 버릴 것과 살아남을 것을 가장 못 가르고, 살아남았을 때 받아낼 팀이 없다.

면죄부의 후반부

요즘 합의는 hybrid다 — 큰 팀·규제 산업엔 spec-driven, 1인·주말 프로젝트엔 vibe. 전반부는 옳다. 후반부는 틀렸다고 본다. spec-first는 인원수 문제가 아니라 되돌리기 비용 문제다. 명제는 "항상 spec"이 아니라 *"버릴 게 확실할 때만 vibe"*다. 1인이어도 두 달 뒤의 자신은 그 코드를 처음 보는 다른 사람이고, "소형이니 가볍게"가 정확히 그 부채로 들어가는 입구다.

필자는 spec 우선 쪽이다. AI를 최대로 쓰라는 글과 모순이 아니다 — 거기선 AI를 최대로 쓰라였고, 여기선 방법을 제약하라다. 사용을 줄이라는 게 아니라 방법(spec)을 걸라는 것이다.

vibe는 발명자 스펙대로 버릴 코드용이다

반대 진영을 가장 센 형태로 세우면, "소형엔 vibe"는 뒤늦은 카브아웃이 아니라 발명자의 원래 정의다. Andrej Karpathy가 2025년 2월 vibe coding을 코이닝한 원 트윗은 이렇게 끝난다 — "I 'Accept All' always, I don't read the diffs anymore. … It's not too bad for throwaway weekend projects." Accept All, 디프 안 읽음, "코드가 존재한다는 걸 잊어라", 그리고 적용 범위를 명시적으로 throwaway weekend projects로 못 박았다. vibe coding은 설계된 방법론이라기보다 코이너 본인이 버릴 코드에 한정해 묘사한 관행이고 — Karpathy는 나중에 그 트윗을 "아무 생각 없이 던진 throwaway tweet"이라 불렀다 — "1인·소형엔 vibe"는 그 원래 스코프를 그대로 따른 것뿐이다. 발명자 권위가 반대 진영을 받친다.

그리고 vibe가 진짜 이기는 자리가 있다. 탐색·MVP·일회성 스크립트. 이런 곳에 spec을 강제하면 속도가 죽는다. 학술 쪽도 이걸 인정한다 — "Vibe Coding in Practice"(2025-12)는 vibe의 핵심을 flow와 technical debt의 맞교환으로 본다. 마찰 없는 생성이 프로토타입·MVP를 가속하는 건 사실이고, 부채는 그 대가다. hybrid 합의가 상식인 데는 이유가 있다.

1인은 면제가 아니라 최악의 자리

쐐기 하나 — 버릴 코드는 안 버려진다. flow와 debt의 맞교환에서, 버리기로 한 코드가 실제로 버려지면 부채는 회수된다. 문제는 안 버려진다는 것이다. "잘 엮인 MVP"가 진짜 유저·데이터·트래픽을 만나면 그대로 프로덕션으로 승격한다. 1년치 vibe 코드가 만기로 돌아온다 — Salesforce Ben은 2026년을 "기술부채의 해"로 예측하며 vibe coding을 직접 지목했다. 비용 측 수치도 또렷하다. Stack Overflow 2025 서베이에서 개발자의 45.2%가 AI 생성 코드 디버깅이 더 오래 걸린다를 불만으로 꼽았고, Veracode 벤치마크에선 AI가 작성한 코드의 45%가 OWASP Top 10 취약점을 끌어들였다.

쐐기 둘, 핵심 — 1인은 면제가 아니라 가장 비싼 자리다. 면죄부의 논리는 "팀이 작으니 부담도 작다"인데 정확히 반대다. 첫째, 1인은 버릴 것과 살아남을 것을 가장 못 가른다 — 코드 리뷰가 없으니 "이건 프로토타입으로 끝낼 거야"라는 자기 판단을 교정해 줄 두 번째 눈이 없다. 둘째, 살아남으면 유지보수가 곧 자신이다 — 부채를 받아낼 팀이 없다. 셋째, 프로덕션 사고 하나가 deep work를 끊고 머릿속에 쌓아둔 상태를 통째로 날린다(복구에 며칠). 면죄부가 약속한 "가벼움"이 1인에게서 가장 비싸게 청구된다.

쐐기 셋 — 파는 쪽이 spec을 판다. AI 코딩을 가장 적극적으로 파는 Amazon은 자기 에이전트 IDE Kiro를 vibe coding을 넘어서라는 포지션으로, Requirements→Design→Tasks라는 spec 워크플로를 제품의 핵심으로 내놨다(2025-07 출시). 벤더가 파는 건 vibe가 아니라 spec이다. 그리고 에이전틱 AI가 연루됐다고 보도된 사고가 터지자 — FT는 Kiro가 환경을 "삭제 후 재생성"했다고 전했고, Amazon은 AI가 아니라 권한 오설정이라 반박하며 프로덕션 접근에 동료 리뷰를 의무화했다 — 그 회사가 손을 뻗은 곳은 vibe가 아니라 프로세스였다.

축을 다시 세우면, 규모가 아니라 생존이다. "이 코드 버릴 거야?"에 확신이 있으면 vibe, 없으면 spec. 그리고 1인은 그 확신을 가장 자주 틀린다.

코이너가 면죄부를 회수하는 시점

2025년 2월 Karpathy가 vibe coding을 코이닝하고 1년, 그 1년치 코드가 2026년 부채로 만기 도래했다(Salesforce Ben, 1월). 그리고 2026년 2월, 코이너 본인이 vibe coding을 "passé"라 부르며 agentic engineering으로 갈아탔다 — 코드를 직접 쓰는 게 아니라 에이전트를 오케스트레이션하고 감독한다는 것이다. "코드가 존재한다는 걸 잊어라"에서 "감독하라"로. 면죄부를 발급한 사람이 그 전제를 거둬들이는 중이다.

지금 "소형이니 vibe"로 판단을 미루면, 그 코드가 살아남는 순간 비용은 복리로 청구된다. 그리고 1인에겐 그 청구서를 나눠 질 사람이 없다.

참고

vibe의 원래 정의 (반대 진영)

부채 측 신호

파는 쪽이 파는 spec