바이브코딩을 멈추세요: AI 에이전트와 TDD로 코딩하는 EXACT

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

바이브코딩의 한계를 줄이려면 EXACT 방식으로 만들 것을 예시로 정하고, AI 에이전트를 TDD로 한 단계씩 이끌어야 한다.

📌 핵심 요점

1. EXACT의 출발점은 구체적인 예시다. 추상적인 요구 설명을 보완해 AI가 무엇을 만들어야 하는지 명확하게 한다.
2. 예시 매핑 → 자연어 테스트 목록 → 레드·그린·리팩터 순서로 진행한다. 사람은 이해관계자와 요구를 정리하고, LLM은 빠진 예시나 경우의 수를 점검한다.
3. 영상에 제시된 실험에서는 예시 매핑 후 클레임 오피스 정확도가 27%에서 94%로, 스핑크스 스코어는 15%에서 100%로 높아졌다. 다만 각 조건을 여섯 번 실행한 결과이므로 일반화에는 추가 검증이 필요하다.
4. 리팩터링 전담 서브 에이전트의 효과는 모델에 따라 달랐다. 예측형 TDD는 실행 전에 예상 결과와 실패 이유를 명시해 실제 결과와 대조하도록 한다.
5. 사람의 개입 수준도 설계 대상이다. 단계별 확인부터 완전 자율 실행까지 선택할 수 있지만, 요구 이해와 방향 수정에는 여전히 사람의 판단이 중요하다는 설명이다.

🧩 배경과 문제 정의

AI가 만든 코드가 실행되더라도 사용자가 원한 기능이나 품질을 충족하지 못하는 상황이 출발점이다. 영상은 마르코와 페르디의 EXACT 코딩을 통해 기존의 TDD와 리팩터링 원칙을 AI 에이전트 작업에 적용하는 방법을 소개한다.

핵심 문제는 요구의 모호함과 구현 과정의 통제다. 이해관계자와 구체적인 예시를 만들어 무엇을 개발할지 합의하고, 이를 테스트 목록과 짧은 검증 사이클로 연결한다. 이후에는 서브 에이전트 분리, 실행 결과 예측, 사람의 개입 수준을 어떻게 조합할지 살펴본다.

🕒 시간순 섹션별 상세정리

1. 바이브코딩의 문제와 예시 중심 개발

• AI가 코드를 만들어도 원하는 결과와 다르거나 품질 문제가 생길 수 있다는 경험에서 EXACT의 필요성을 보여준다. [01:28]
• TDD를 ‘예시로 이끄는 개발’로 이해하면 구체적인 예시에 반응하는 AI 에이전트와의 작업에도 유용하다는 관점을 제시한다. [02:15]

2. 예시 매핑에서 TDD 실행까지

• 이해관계자와 사용자 스토리를 예시로 정리한 뒤, LLM과 자연어 테스트 목록을 만들고 항목별로 레드·그린·리팩터를 반복한다. [03:12]
• 사람은 협업을 통해 무엇을 만드는지 이해하고, LLM은 테스트 목록에서 빠진 예시나 경우의 수를 점검한다. [03:56]
• 예시 매핑은 스토리·규칙·예시·미해결 질문을 색깔 카드로 구분한다. TDD는 실패하는 테스트, 통과에 필요한 구현, 동작을 유지하는 구조 개선으로 계속된다. [04:28]

3. 예시 매핑 전후의 실험 결과

• 영상의 표 설명에 따르면 클레임 오피스 정확도는 줄글 설명만 사용했을 때 27%였고, 예시 매핑을 먼저 했을 때 94%였다. 스핑크스 스코어는 15%에서 100%로 높아졌다. [06:12]
• 자막은 오퍼스 5 모델로 조건마다 여섯 번 실행한 결과라고 설명하며, 코드 카타를 연습용 코딩 문제로 보여준다. [06:19]

4. 요구의 모호함과 문서 중심 접근의 한계

• 출연자는 보험·은행·전자상거래 현장에서는 개발자가 도메인 전문가가 아닌 경우가 많고 요구에도 모호함이 남는다고 보여준다. [06:58]
• 명세 중심 프레임워크에서 계획과 마크다운 문서가 늘어나도 사람이 내용을 충분히 이해하거나 검토하기 쉬워지는 것은 아니라는 비판을 제시한다. [07:59]
• 예시 매핑과 도메인 모델링으로 사고를 앞당기고, 대화와 협업을 통해 이해를 쌓는 것이 EXACT 앞부분의 목적이라고 정리한다. [08:28]

5. TDD 단계 분리와 서브 에이전트 실험의 출발

• 영상은 상세 TDD 실행으로 논점을 옮긴 뒤, 처음에는 하나의 TDD 명령으로 접근했다고 보여준다. [10:23]
• 긴 컨텍스트 중간의 정보가 약해질 수 있다는 문제의식에서, TDD 단계마다 새로운 컨텍스트를 가진 서브 에이전트를 쓰면 나을지 실험하게 됐다고 드러낸다. [11:16]

6. 리팩터링 전담 에이전트의 효과와 모델 차이

• Opus 5.5와 Claude Code를 사용한 사례에서는 주 에이전트가 대부분의 TDD를 맡고 별도 에이전트가 리팩터링을 담당했을 때 코드 품질이 더 좋았지만, 차이는 크지 않았다고 보여준다. [11:53]
• Opus 4.6에서는 전담 리팩터링 에이전트의 추가 효과가 더 컸으며, 최근에는 그 효과가 약해졌다고 비교한다. [12:14]

7. 실행 전에 결과를 예측하는 TDD

• 예측형 TDD는 각 단계를 실행하기 전에 결과를 예상하는 방식이다. 실패 테스트라면 왜 실패해야 하는지와 어떤 오류 메시지가 나와야 하는지 먼저 드러낸다. [13:12]
• 예상과 실제 결과를 비교하면 사람과 LLM이 코드와 실행 환경을 제대로 이해하고 있는지 점검하는 데 도움이 된다는 설명이다. [13:31]
• 예측이 문제를 LLM 컨텍스트 앞으로 가져오기 때문에 효과가 있을 것이라는 해석은 출연자들의 가설로 드러난다. [13:46]

8. 자율성 수준과 사람의 개입

• 하네스에서는 모든 단계 확인, 리팩터링 후 확인, 여러 테스트 후 확인, 완전 자율 실행 등 개입 수준을 선택할 수 있다고 보여준다. [14:46]
• 출연자는 자신이 진행 상황을 이해하고 방향을 수정할수록 결과가 더 좋았다고 드러낸다. [15:04]
• 무엇이 필요한지와 현실의 조건을 이해하는 정신적 모델을 만드는 과정에는 여전히 사람의 개입이 중요하다고 강조한다. [15:23]

9. TDD 입문과 운영 방식 선택

• TDD 지식이 완전하지 않아도 시작할 수 있고, 사용하면서 이해를 깊게 할 수 있다는 의견을 제시한다. [15:58]
• 더 깊은 TDD 지식은 하네스를 개선하고 자신의 지식을 반영하는 데 도움이 된다고 보여준다. [16:08]
• 말미에는 오픈소스 공개와 집필 중인 책을 언급하고, 자율성을 목록 끝까지 실행하기·사이클마다 멈추기·단계마다 멈추기로 정리한다. [16:22]

10. 원하는 것을 정하고 테스트로 이끄는 개발

• 마지막 정리는 예시 매핑 등 협업 모델링으로 만들 대상을 정하고, 예측형 TDD와 모델에 맞는 리팩터링 에이전트로 구현 품질을 관리하자는 것이다. [16:45]
• 느낌에 맡기는 대신 예시와 테스트로 AI를 이끌자는 메시지로 마무리하고, 시청자의 작업 방식을 묻고 인사를 전해진다. [17:01]

🧾 결론

• EXACT는 예시로 올바른 대상을 정하고, 테스트와 리팩터링으로 구현 품질을 관리하는 작업 방식이다.
• 핵심은 문서의 분량보다 사람이 요구를 이해하고 검증 가능한 예시를 만드는 과정에 있다.
• 서브 에이전트 구성과 자율성 수준은 사용하는 모델과 실제 결과를 보고 조정해야 한다.

📈 투자·시사 포인트

• AI 개발 도구를 평가할 때 코드 생성량과 함께 요구 충족도와 코드 품질을 살펴볼 필요가 있다. 영상이 제시하는 문제는 코드가 실행돼도 원하는 결과와 다를 수 있다는 점이다.
• 요구가 모호한 보험·은행·전자상거래 업무에서는 도메인 이해와 예시를 통한 협업이 AI 활용의 중요한 조건으로 제시된다.
• 모델이 발전하면 리팩터링 전담 에이전트의 추가 효과도 달라질 수 있다. 특정 에이전트 구성을 고정하기보다 현재 모델에서 효과를 확인하는 접근이 필요하다.
• 이 영상은 개발 방식에 관한 사례와 실험을 다룬다. 개별 기업의 실적이나 투자수익을 판단할 직접적인 근거는 제공하지 않는다.

⚠️ 불확실하거나 확인이 필요한 부분

• 정확도와 스코어의 평가 기준, 전체 과제 구성, 실행 조건은 제공된 자막만으로 확인하기 어렵다. 조건별 여섯 번의 실행 결과를 다른 프로젝트의 기대 성과로 그대로 적용하기는 어렵다.
• 자막에는 실험 설명에서 ‘오퍼스 5’, 이후에는 ‘Opus 5.5’와 ‘Opus 4.6’ 등이 등장한다. 실제 모델명과 각 실험의 대응 관계는 원본 표나 실험 자료 확인이 필요하다.
• 예측형 TDD가 문제를 컨텍스트 앞으로 가져와 효과를 낸다는 설명은 출연자의 가설이다. 영상은 이를 확정된 작동 원리로 입증하지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 작은 사용자 스토리 하나를 골라 규칙, 구체적인 예시, 미해결 질문을 예시 매핑으로 정리한다.
• 예시를 자연어 테스트 목록으로 바꾸고, AI와 함께 빠진 경우의 수를 점검한다.
• 테스트를 하나씩 선택해 실패 확인, 최소 구현, 리팩터링 순서로 진행한다.
• 각 TDD 단계 실행 전에 예상 결과를 적고, 실패 단계에서는 예상 오류와 실패 이유까지 실제 결과와 대조한다.

❓ 열린 질문

• 예시 매핑의 효과는 새로운 도메인과 더 큰 기존 코드베이스에서도 유지될까?
• 모델별로 리팩터링 전담 에이전트가 유효해지는 조건은 무엇일까?
• 요구 충족도와 코드 품질을 유지하면서 사람의 확인 빈도를 어디까지 줄일 수 있을까?