70% 문제: AI 보조 워크플로

이 책에서 가장 유명한 개념인 70% 문제를 짚어야 해. AI가 프로젝트의 70%를 뚝딱 만들어주는데, 나머지 30%에서 벽에 부딪히거든. 그리고 그 30%가 진짜 어려운 부분이야.

먼저 현실 점검부터. AI 코딩 도구의 마케팅 영상에서는 "5분 만에 앱을 만들었다"고 하지만, 실제 개발 현장에서의 경험은 달라.

설문 조사와 인터뷰를 기반으로 정리한 실제 사용 패턴을 보면:

• 보일러플레이트 생성 — 가장 많이 쓰이는 용도야. 설정 파일, CRUD 엔드포인트, 테스트 스캐폴딩 같은 반복적인 코드를 AI에게 맡기지
• 코드 설명/문서화 — 레거시 코드나 남이 쓴 코드를 이해할 때 "이 코드가 뭘 하는 건지 설명해줘"
• 버그 디버깅 — 에러 메시지를 붙여넣고 "왜 이런 에러가 나는지" 물어보기
• 프로토타이핑 — 아이디어를 빠르게 검증할 때. MVP를 먼저 만들고 판단
• 학습 — 새로운 기술을 배울 때 실시간 질의응답

여기서 눈에 띄는 건, 대부분의 개발자가 AI를 "전체를 만드는 도구"가 아니라 "부분을 도와주는 도구"로 쓰고 있다는 거야. 100%를 AI에게 맡기는 사람은 극소수이고, 대부분은 자기가 주도하면서 특정 작업만 AI에게 위임하지.

이제 핵심 개념. 관찰된 패턴은 이래:

AI를 써서 프로젝트를 시작하면 초반 70%가 놀랍도록 빠르게 진행돼. UI가 뚝딱 나오고, 기본 로직이 구현되고, 뭔가 돌아가는 것처럼 보여. 여기까지는 마법 같지.

그런데 나머지 30%에서 문제가 터져:

• 엣지 케이스 — 행복한 경로(happy path)는 잘 되는데, 예외 상황에서 깨짐
• 통합 문제 — 개별 컴포넌트는 잘 되는데, 합치면 안 돼. 상태 관리가 꼬이거나, API 계약이 안 맞거나
• 성능 — 작은 데이터에서는 잘 되는데, 실제 규모의 데이터를 넣으면 느려지거나 터짐
• 보안 — 기본적인 보안 조치가 빠져 있거나, AI가 알려진 취약 패턴을 생성함
• 유지보수 — 시간이 지나면서 코드를 수정해야 하는데, AI가 생성한 코드의 구조를 이해 못 해서 수정이 어려움

이걸 70% 문제라고 부르는 이유는, 70%까지의 성공 경험이 나머지 30%의 난이도를 과소평가하게 만들기 때문이야. "거의 다 됐는데"라는 착각이 위험하다는 거지.

비유를 하자면 — 등산에서 정상까지 70%를 쉽게 올라갔다고 나머지 30%가 쉬운 게 아닌 것처럼. 오히려 마지막 30%가 경사가 급하고 위험한 구간인 경우가 많잖아.

70% 문제를 인식한 위에서, 바이브 코딩을 효과적으로 하기 위한 원칙이 필요해.

원칙 1: 작게 시작하고, 자주 검증해

한 번에 전체 앱을 만들려고 하지 마. 작은 단위로 나눠서 생성하고, 각 단위가 제대로 동작하는지 확인한 후에 다음으로 넘어가. AI가 생성한 코드를 무조건 수용하지 말고, 이해하고 나서 넘어가야 해.

원칙 2: AI의 결과를 의심해

AI가 자신감 있게 생성한 코드가 잘못된 경우가 많아. 특히 존재하지 않는 API를 호출하거나, 더 이상 지원되지 않는 문법을 쓰는 경우. 결과를 받으면 컴파일 → 실행 → 테스트 순서로 반드시 검증해야 해.

원칙 3: 맥락을 충분히 제공해

프로젝트의 기술 스택, 기존 코드 구조, 코딩 컨벤션을 AI에게 알려줘야 해. 맥락 없이 코드를 생성하면 프로젝트와 동떨어진 결과물이 나오거든. 이전 장에서 다룬 시스템 프롬프트가 여기서도 핵심이지.

원칙 4: 되돌릴 수 있는 상태를 유지해

AI가 생성한 코드를 적용하기 전에 Git 커밋을 해둬. 문제가 생기면 되돌릴 수 있어야 하거든. AI와 작업할 때 커밋 빈도를 높이는 게 좋아. "AI가 만든 인증 모듈 추가"처럼 작업 단위로 커밋하는 거지.

원칙 5: AI를 페어 프로그래머로 대해

AI는 만능이 아니라 동료야. 동료한테 일을 시키는 것처럼 명확하게 요청하고, 결과를 리뷰하고, 피드백을 주는 방식으로 협업해. 맹목적으로 신뢰하지도 말고, 무시하지도 말고.

바이브 코딩이 특히 효과적인 상황이 있어:

• 프로토타이핑과 MVP — 빠르게 아이디어를 검증하는 단계. 코드 품질보다 속도가 중요할 때
• 익숙하지 않은 도메인 탐색 — 새로운 프레임워크나 언어를 처음 써볼 때. 학습 곡선을 줄여줌
• 일회성 스크립트 — 데이터 마이그레이션, 일괄 처리 같은 한 번 쓰고 버릴 코드
• 표준적인 패턴의 구현 — REST API, CRUD, 폼 처리 같이 패턴이 정형화된 작업
• 개인 프로젝트 — 품질 기준이 상대적으로 낮고, 본인만 쓸 코드

반대로 바이브 코딩이 위험한 상황도 있지:

• 높은 신뢰성이 필요한 시스템 — 결제, 의료, 항공 같은 도메인. 70%만 맞으면 안 되는 곳
• 복잡한 비즈니스 로직 — 도메인 특화된 규칙이 많고, AI의 학습 데이터에 없는 패턴일 때
• 대규모 코드베이스 수정 — 기존 코드와의 정합성을 맞춰야 하는데, AI가 전체 맥락을 파악하기 어려움
• 성능 크리티컬한 코드 — 밀리초 단위 최적화가 필요한 부분. AI가 "돌아가는 코드"는 만들지만 "최적화된 코드"는 잘 못 만들어
• 보안 민감한 코드 — 인증, 암호화, 권한 관리 같은 부분. AI 생성 코드를 그대로 쓰면 안 돼

결론은 이래 — 바이브 코딩을 쓸지 말지의 판단 기준은 **"실패했을 때의 비용"**이야. 실패 비용이 낮으면(프로토타입, 개인 프로젝트) 과감하게 쓰고, 실패 비용이 높으면(프로덕션, 보안) 신중하게 써.

---

정리

3장에서 기억할 거 세 가지:

1. 70% 문제는 AI 코딩의 가장 큰 함정이야. 초반의 빠른 진행이 나머지 30%의 난이도를 과소평가하게 만들거든. 엣지 케이스, 통합, 보안에서 진짜 문제가 터져
2. 바이브 코딩의 효과는 상황에 따라 극명하게 갈려. 프로토타이핑에는 최고, 프로덕션 보안 코드에는 위험하지. 실패 비용으로 판단해
3. 작게 시작하고, 의심하고, 되돌릴 수 있게 해. 이 세 가지만 지켜도 바이브 코딩에서 생기는 대부분의 문제를 예방할 수 있어