바이브 코딩: 참호에서 얻은 5가지 교훈

기사 듣기

AI 코딩 어시스턴트가 처음 저희 워크플로에 도입되었을 때, 마치 마법처럼 느껴졌습니다. Windsurf, Cursor, GitHub Copilot 같은 도구를 사용하여 사양을 입력하면 몇 분 만에 작동하는 코드를 얻을 수 있었습니다. 개발자 두 명과 팀 리더 한 명으로 구성된 저희처럼 소규모 팀에게는 이러한 속도가 판도를 바꿀 만큼 중요했습니다. 저희 앱은 클라이언트 시스템과 통합되어야 했고, 각 모듈은 클라이언트와 다른 모듈 모두에 API를 노출해야 했습니다. 즉, API 전반의 정확성과 일관성이 매우 중요했습니다. 

우리는 프로젝트 개요, 도메인 분류, 기능별 설명, 작업 분류, 작업 로그 등 체계적인 문서화 프로세스를 구축했습니다. 이론적으로 이러한 방식은 AI가 충실하고 고품질의 코드를 생성하는 데 필요한 모든 것을 제공했습니다. 하지만 실제로는 AI에 지나치게 의존하고 그 순간에 "옳다고 느껴지는" 것을 믿는 바이브 코딩(vibe coding)이 함정에 빠지게 했습니다. AI는 종종 중복된 코드를 생성하거나, 범위를 벗어나거나, 단독으로는 잘 작동하지만 통합에는 실패하는 모듈을 생성했습니다. 

시행착오와 수많은 수정 과정을 거쳐 우리는 AI 활용 방식을 완전히 바꿔놓은 다섯 가지 핵심 교훈을 얻었습니다. 바로 여기 있습니다. 

초기에는 AI에 기능 설명 전체를 전달하고 "모듈 생성"을 요청했습니다. 결과는 인상적이었지만, 중복 로직, 누락된 사양 요건, 그리고 형제 모듈과 제대로 연결되지 않은 API 등 여러 문제가 숨겨져 있었습니다. 이러한 문제를 해결하는 데는 작은 조각들을 직접 작성하는 것보다 더 오랜 시간이 걸렸습니다. 

이제 우리는 간단한 규칙을 따릅니다. 만약 차이가 검토하기에는 너무 크다고 느껴진다면, 처음부터 생성하기에는 너무 큰 차이였던 것입니다. 작은 단위의 증분은 코드를 더 깔끔하게 만들고, 검토를 더 빠르게 진행하며, 통합 과정에서 예상치 못한 문제를 줄여줍니다. 세분성이 핵심입니다. 단일 기능 내에서도 자체 개발 로직을 따르는 것이 가장 좋습니다. 한 번에 생성하는 대신, 다음에 무엇을 할지 생각하고 AI에 먼저 요청하는 식으로 모든 단계를 반복하세요.  

AI가 생성한 코드를 기반으로 테스트를 작성했을 때, 우리가 테스트한 것은 AI가 구현한 현실이 제대로 작동하는지 여부뿐이었습니다. 하지만 그 테스트는 완전히 실패했습니다. 예를 들어, 대출 신청 엔드포인트는 대출 기록을 올바르게 생성했지만 필수 승인 단계와 문서 요건을 건너뛰었습니다. 하지만 테스트는 통과했습니다. AI가 구현한 내용만 반영했을 뿐, 사양에서 요구하는 내용은 반영하지 않았기 때문입니다. 

전환은 FEATURE-DESCRIPTION.md라는 md 파일에 저장된 사양을 바탕으로 직접 테스트를 작성하는 것이었습니다. 모든 비즈니스 규칙과 요구 사항이 테스트 케이스가 되었습니다. 이렇게 생성된 단위 테스트만이 AI가 생성한 코드를 제대로 검증할 수 있습니다. 

이러한 변화는 테스트를 AI 출력을 사양으로 되돌리는 강제 메커니즘으로 전환했습니다. 또한, 문서화되지 않은 선택 필드와 같은 범위 변동이 시스템에 확산되기 전에 포착했습니다. 핵심은 다음과 같습니다. 테스트는 코드의 동작뿐만 아니라 비즈니스 사양을 준수한다는 것을 증명해야 합니다. 

당사의 QA 책임자인 데이빗은 현재 AI를 많이 사용하는 프로젝트를 시작하기 전에 QA 계획을 수립하는 작업을 진행하고 있습니다. 

중간 검토 없이 풀 리퀘스트가 1,500줄 이상으로 불어났습니다. 검토는 느리고 고통스러웠으며, 뒤늦게 예상치 못한 일들이 끊이지 않았습니다. 간단히 해결할 수 있었던 버그와 환각 현상들이 값비싼 재작업으로 이어졌습니다. 

이러한 이유로 저희는 일주일 이상 소요된 모든 기능에 대해 매주 진행 중인 작업(WIP) 검토를 도입합니다. 이는 공식적인 승인이나 마스터 코드로의 병합으로 이어지는 것이 아니라, 최신 차이점을 살펴보고 간단한 질문을 던지는 체크포인트일 뿐입니다. 

코드가 여전히 사양과 일치합니까? 

형제 모듈과 통합이 되나요? 

중복된 코드나 AI 환각의 징후가 있나요? 

테스트가 비즈니스 규칙에 맞춰져 있나요? 

우리가 기대하는 결과는 다음과 같습니다. 환각과 코드 품질 문제를 조기에 발견하고, 검토해야 할 차이점을 줄이고, 최종 PR을 더욱 원활하게 처리하는 것입니다. 우리는 이렇게 표현합니다. 환각이 코드베이스 전체에 뿌리를 내리고 나서가 아니라, 아직 저렴할 때 환각을 잡으세요. 

AI를 사용하면 즉시 코딩을 시작할 수 있지만, QA 계획 없이는 고립된 상태에서는 "작동"하는 기능을 구축하고 실제 상황에서는 실패할 위험이 있습니다. 대출 처리 모듈이 지급을 정상적으로 처리했지만 지급 취소 또는 담보 검증 과정에서 오류가 발생하면서 이 사실을 알게 되었습니다. 

이제 개발 시작 전에 QA를 진행할 예정입니다. 계획은 간단합니다. 성공 경로, 예외 상황, 통합 점검, 실패 모드, 회귀 위험 등을 담은 체크리스트입니다. 이렇게 작성하면 요구사항을 면밀히 검토해야 하며, 코딩을 시작하기도 전에 누락된 부분을 발견하는 경우가 많습니다. 

우리는 이렇게 말하게 되었습니다. 어떻게 테스트할지 모르면, 어떻게 완료할지 알 수 없습니다. 

AI는 코드를 빠르게 작성할 수 있지만, 항상 학습된 사용 사례와 코드를 사용하기 때문에 도메인과 사양에만 엄격하게 집중할 수 없습니다. 우리는 이를 어렵게 배웠습니다. 즉, 즉시 로딩이 누락되어 성능 문제가 발생하고, 권한 확인이 부족하여 보안 격차가 발생하며, 불필요한 추가 매개변수로 인해 범위가 변경되는 것입니다. 

해결책은 AI를 마치 잘 훈련된 신입 개발자처럼 대하는 것이었습니다. 도움이 되긴 하지만 검토가 필요한 존재처럼 말입니다. 항상 다음과 같은 안전장치를 마련해 두세요. 

린터, 정적 분석, 스키마 검사. 

취약점과 안전하지 않은 패턴을 찾아내는 보안 스캐닝. 

간단한 수동 검토 체크리스트: 사양 준수, 스타일, 검증, 중복성 및 테스트. 

사고방식의 전환 또한 마찬가지로 중요합니다. 잘못된 결과는 신속하게 거부하고, 더 엄격한 범위로 다시 요청하며, AI를 점진적으로 교육해야 합니다. 우리는 신뢰할 수 있지만, 항상 검증해야 합니다. 

테이크 아웃 : AI는 코드를 빠르게 작성할 수 있지만, 올바른 코드인지 확인할 수 있는 사람은 오직 당신뿐입니다.

결론

AI와 추진력을 규율보다 우선시하는 바이브 코딩은 빠르게 발전할 수 있지만, 숨겨진 부채를 쌓게 됩니다. 현재로서는 이러한 접근 방식에만 전적으로 의존하는 것은 지속 가능하지 않습니다. 어떤 규모의 프로젝트든 하이브리드 모델이 여전히 필요합니다. 즉, AI를 활용하여 진행 속도를 높이는 동시에 체계적인 엔지니어링 방식을 적용하여 위험을 관리하고 기술 부채를 통제하는 것이 중요합니다. 우리가 얻은 다섯 가지 교훈은 AI 활용 방식을 재정립하는 데 도움이 될 것입니다. 작은 단위로 코드를 생성하고, 테스트를 사양에 맞춰 진행하고, 매주 진행 상황을 검토하고, 코딩 전에 QA를 계획하고, 코드 검토를 절대 건너뛰지 않는 것입니다. 

AI는 개발자의 규율을 대체하는 것이 아니라 증폭하는 역할을 합니다. 좋은 습관을 들이면 AI는 문제를 일으키지 않고 더 빠르게 움직일 수 있도록 도와줍니다. 하지만 가드레일을 무시하면 더 빨리 구멍을 파는 데 그칠 뿐입니다. AI를 실험하는 모든 개발자에게 주어지는 과제는 다음과 같습니다. 단지 분위기만 쫓지 마세요. 코드가 정직하게 유지되도록 프로세스를 구축하세요.