.png)
바이브 코딩을 넘어, 스펙 주도 AI 코딩으로
기획 연재 2편 : AI와 오래 대화하는 능력이 아니라, AI가 바로 실행할 수 있는 명세(Spec)를 정의하고 결과를 검증하는 능력이 진짜 생산성을 가른다.
📚 연재 안내 | 이 글은 3부작 연재의 2편입니다.
① 왜 개발자의 역할이 바뀌는가
② 바이브 코딩을 넘어 어떻게 일할 것인가(현재 글)
③ 팀에서 어떻게 운영할 것인가
지난 1편에서 우리는 AI 시대에 개발자의 역할이 단순한 타이핑에서 '시스템의 기억과 제약을 설계하는 오케스트레이터'로 변해야 한다고 이야기했습니다. 그렇다면 이 거창한 변화를 매일매일의 '실무'에는 어떻게 적용해야 할까요?
최근 1~2년 사이 코딩 방식은 극적으로 변했습니다. 자연어로 "이런 화면을 만들어줘"라고 입력해 코드를 얻고, 결과를 보며 "버튼 색깔을 파란색으로 바꿔줘", "여기 에러 고쳐줘"라고 대화하듯 코딩을 이어가는 ‘바이브 코딩(Vibe Coding)’이 크게 유행했습니다.
바이브 코딩의 등장은 분명 혁명적이었습니다. 코딩을 전혀 모르는 비전문가도 아이디어만 있으면 챗봇과 대화하며 그럴싸한 프로토타입을 마법처럼 쏟아낼 수 있게 되었으니까요. 빠른 아이디어 검증과 UI 탐색에 있어서는 여전히 훌륭하고 유효한 패러다임입니다.
하지만 실무 개발에서는 여기서 한 단계 더 나아가야 합니다. 프로토타입을 빠르게 만드는 능력과, 운영 가능한 상용 제품을 안정적으로 만드는 능력은 완전히 다른 영역이기 때문입니다.
프로토타입을 넘어 '프로덕션'으로 가려면 통제가 필요하다
우리가 마주하는 실무 환경의 소프트웨어는 단순히 "화면에 한 번 예쁘게 렌더링되는 것"으로 끝나지 않습니다. 기존 코드베이스와 충돌하지 않아야 하고, 수십 가지의 예외 케이스를 방어해야 하며, 엄격한 아키텍처 규칙과 테스트를 통과해야 합니다.
바이브 코딩의 대화 흐름에만 의존해 결과물을 상용 환경(Production)으로 밀어 넣다 보면, 1편에서 경고했던 ‘그럴싸한 코드(Plausible code)’의 함정에 빠집니다. 당장 눈앞의 버그는 고쳐지지만 전체 시스템의 아키텍처는 서서히 무너집니다.
게다가 실무 환경에서 AI와 핑퐁 대화를 길게 이어가는 방식은 시간과 토큰 비용을 급격히 증가시킵니다. 대화가 길어지고 컨텍스트 윈도우가 커질수록 요구사항은 이리저리 흩어집니다. 실제로 Anthropic의 Claude Code 공식 문서에서도 *"컨텍스트 윈도우가 빨리 차고 가득 찰수록 모델의 성능이 떨어지며, 이전 지시를 잊거나 실수가 늘어날 수 있다"*고 지적하며, 주기적인 컨텍스트 비우기(초기화)를 강력히 권장하고 있습니다.
명심해야 합니다. 긴 대화창은 결코 좋은 설계 문서가 될 수 없습니다. 그저 산만하고 난잡한 회의록일 뿐입니다.
대화형 코딩 vs 스펙 주도 코딩
실무형 AI 코딩, '스펙 주도 개발'을 정의하다
제가 말하는 실무형 AI 코딩은 대화로 우연히 결과물을 맞춰가는 방식이 아닙니다. 먼저 요구사항과 제약 조건을 정리하고, AI가 바로 실행할 수 있는 크기로 작업을 나눈 뒤, 각 작업에 목표·범위·완료 기준·검증 방법을 함께 제공하는 방식입니다.
더 정확히 말하면 이것은 '스펙 주도 AI 코딩(Spec-Driven AI Coding)'입니다. 프롬프트로 "잘 만들어줘"라고 뭉뚱그려 부탁하는 것이 아니라, 1편에서 강조한 하네스(Harness, 통제 환경)의 개념을 빌려 "무엇을 지켜야 하고, 무엇이 완료인지"를 문서로 명시해 규정하는 방식입니다.
대화는 '구현'이 아니라 '스펙 설계'를 위해 쓰세요
그렇다면 AI와의 대화는 이제 불필요할까요? 아닙니다. 대화의 목적과 타이밍이 완전히 달라져야 합니다. 우리가 AI와 치열하게 대화해야 하는 순간은 코딩하는 구현 단계가 아니라, 요구사항의 맹점을 찾고 예외 케이스와 테스트 기준을 세우는 '스펙 설계 단계'입니다.
실제로 저는 코드를 직접 타이핑하거나 디버깅하는 대신, AI와 함께 실행 가능한 마크다운(.md) 형태의 스펙 문서를 작성하고 정제하는 데 개발 시간의 대부분을 사용합니다.
이는 글로벌 개발 도구들이 발전하는 방향과도 정확히 일치합니다.
- GitHub Spec Kit: AI 보조 개발에서 임의의 프롬프트가 아니라 Markdown 산출물 기반의 구조화된 컨텍스트를 제공하는 Spec → Plan → Tasks → Implement 흐름을 공식적으로 강조합니다.
- Kiro (AI 코딩 프레임워크): 요구사항과 설계를 각각 독립된 문서(requirements.md, design.md, tasks.md)로 나누어, 고수준 아이디어를 AI가 실행할 수 있는 원자적(Atomic) 작업으로 바꾸는 아키텍처를 제시합니다.
📝 [실행 가능한 .md 스펙 작성 실전 샘플]
# 기능 명세: 로그인 예외 처리 고도화 (auth_login_spec.md)
## 1. 목표 (Goal)
- 로그인 실패 시 원인에 따른 명확한 오류 메시지(비밀번호 오류, 미존재 계정 등)를 노출한다.
## 2. 수정 범위 (Scope) 및 제약(Harness)
- `frontend/src/features/auth/login` 하위 컴포넌트로 변경을 제한한다.
- [절대 주의] backend 인증 API 응답 형식은 절대 변경하지 않는다.
## 3. 완료 및 검증 기준 (Verification)
- [ ] 비밀번호 5회 오입력 시 해당 계정 상태를 잠금 UI로 렌더링할 것.
- [ ] `npm test auth` 실행 시 기존 로그인 성공 테스트가 100% 통과할 것.
생산성을 향상시키는 핵심: 격리된 환경에서의 '병렬 위임'
의도를 스펙으로 충분히 정의했다면, 이제 코딩은 선형적 타이핑에서 '병렬 작업(Parallel Delegation)'의 영역으로 넘어갑니다.
저의 경우, 설계가 끝난 모듈별로 서로 다른 독립 환경에서 AI에게 병렬 지시를 내립니다. 어떤 팀은 여러 터미널을 쓸 수도 있고, git worktree를 쓰거나 클라우드 샌드박스를 활용할 수도 있습니다. 심지어 물리적인 PC를 여러 대 세팅하는 분들도 있습니다. 핵심은 어떤 방식이냐가 아니라, 작업 공간이 서로 격리되어 있고, 각 AI 에이전트가 충돌하지 않는 범위에서 명세서대로 철저히 독립적으로 일한다는 점입니다.
주의할 점은, 무작정 AI에게 던져준다고 생산성이 알아서 올라가지 않는다는 것입니다. METR의 2025년 무작위 대조 실험(RCT)에서는 숙련된 오픈소스 개발자 16명이 성숙한 프로젝트에서 AI 도구를 사용할 때, 복잡한 실무 환경의 특성상 오히려 작업 시간이 19% 늘어나는 충격적인 역효과가 나왔습니다. 무분별하게 생성된 코드를 수습하고 재작업(Rework)하느라 오히려 시니어의 시간이 더 소모되었기 때문입니다. 다만 METR도 이 수치가 모든 개발자나 모든 코드베이스에 그대로 일반화되는 증거는 아니라고 분명히 선을 그었습니다. 핵심은 ‘AI를 쓰면 느려진다’가 아니라, 생산성은 작업을 얼마나 잘게 나누고 어떻게 통제하느냐에 따라 달라지는 조건부 결과라는 점입니다.
생산성은 결국 작업을 얼마나 잘게 나누고, 컨텍스트(명세)를 얼마나 뾰족하게 제한하며, 결과를 얼마나 빠르게 병렬로 회수하느냐에 달려 있습니다.
병렬 위임 아키텍처 다이어그램
AI 코딩을 완성하는 최후의 보루: 3단계 루프와 철저한 '검증'
앞으로의 실무 AI 코딩은 반드시 다음 3가지 루프로 돌아가야 합니다.
- 명세화 (Specify): AI가 지켜야 할 '기억'과 '제약'을 스펙 문서(.md)로 구조화합니다.
- 위임 (Delegate): AI가 실행 가능한 단위로 쪼개어, 충돌 없는 독립 환경에 병렬로 위임합니다.
- 검증 (Verify): AI 스스로 완료를 판단하게 두지 않고, 반드시 테스트와 리뷰로 객관적 검증을 거칩니다.
특히 3번 '검증(Verify)'은 절대 타협해선 안 되는 최후의 보루입니다. 최근 AI 코딩 에이전트 평가에서는 모델의 점수 자체보다 ‘문제 설명의 품질과 테스트의 정확성’이 결과를 좌우하는 핵심 변수로 떠올랐습니다. 실제로 OpenAI는 2026년 들어 SWE-bench Verified가 최신(frontier) 코딩 능력을 충분히 측정하지 못한다고 보고, 평가 기준을 SWE-bench Pro 등으로 옮기고 있다고 밝혔습니다. 그만큼 ‘무엇을, 어떤 테스트로 검증하느냐’가 점점 더 중요해지고 있다는 뜻입니다
또한 UTBoost 연구가 날카롭게 지적하듯, 개발자가 설정한 테스트(검증 기준) 자체가 약하면 AI가 실제 문제는 전혀 해결하지 못한 가짜 패치(그럴싸한 코드)만 만들고도 테스트를 통과해버리는 치명적인 오작동이 발생할 수 있습니다. AI가 코드를 짜는 속도가 폭발적으로 빨라진 만큼, 이 코드의 무결성을 검증하는 자동화된 테스트 게이트웨이는 더욱 철벽같아져야 합니다.
마치며: 진정한 오케스트레이터가 되는 길
바이브 코딩은 코딩의 대중화를 이끈 훌륭한 시작점이었습니다. 하지만 실무 개발의 다음 단계는 긴 대화창 안에서 결과를 우연히 맞춰가는 방식이 아닙니다.
개발자의 일은 사라지지 않습니다. 오히려 코드 입력에서 '실행 설계'로, 구현 속도에서 '검증 가능한 결과 관리'로, 단일 작업 수행에서 '여러 AI 작업 흐름의 오케스트레이션'으로 무대를 넓히고 있습니다.
이제는 AI 에디터 앞에서 긴 대화로 결과를 맞춰가기보다, 명세와 검증 루프에 더 많은 시간을 써야 합니다. 시스템의 제약을 파악해 명확한 명세(.md)를 내리고, 격리된 샌드박스에 병렬 위임하며, 철벽같은 테스트로 검증하는 프로세스만이 여러분을 AI 시대의 대체 불가능한 '오케스트레이터'로 만들어 줄 것입니다.
다음 3편에서는 이 ‘명세화 → 위임 → 검증’ 루프를 실제로 어떤 폴더 구조와 지침 문서, 리뷰 게이트로 구현하는지 보여드리겠습니다. 팀이 그대로 가져다 쓸 수 있는 마크다운 기반의 실무 프레임워크로 풀어 보겠습니다.
기억의 설계자
