“TODO 앱 하나 만들어줘.”

몇 마디만 입력했는데 AI가 프로젝트를 만들고, 코드를 작성하고, 화면까지 완성합니다. 불과 얼마 전까지만 해도 개발자가 직접 하나씩 구현해야 했던 일을 이제는 자연어만으로 시작할 수 있습니다.

2025년 초 안드레 카파시가 언급한 ‘바이브 코딩(Vibe Coding)’은 자연어로 AI에게 코딩을 맡기는 새로운 개발 방식으로 주목받았습니다. 이제는 전문 개발자가 아니더라도 AI를 활용해 빠르게 프로토타입을 만들고 아이디어를 검증할 수 있는 시대가 됐습니다. 이러한 흐름은 단순히 LLM에 코딩을 맡기는 것을 넘어, 계획 → 코딩 → 검증의 루프를 통해 더 견고하고 완성도 있는 제품을 만드는 ‘에이전틱 코딩’의 패러다임으로 확장되고 있습니다.

처음 바이브 코딩을 접하면 이 속도 자체가 가장 큰 매력으로 다가옵니다. 만들고 싶은 것을 설명하면 AI가 코드로 바꿔주고, 수정할 부분이 생기면 다시 자연어로 요청하면 되니까요.

하지만 프로젝트가 커지고 기능이 하나둘 늘어나기 시작하면 이야기가 달라집니다. 처음에는 잘 동작했던 코드에 기능을 하나 더 붙이고, 다시 수정하고, 또 다른 요구사항을 추가하다 보면 어느 순간 이런 생각이 들기 시작합니다. “이 코드, 정말 괜찮은 걸까?”

“알아서 만들어줘”가 위험해지는 순간

AI에게 너무 큰 일을 한꺼번에 맡길 때 더욱 뚜렷해집니다.

예를 들어 “회원가입과 로그인 기능을 만들어줘”라고 요청한다고 생각해봅시다. AI는 회원가입, 비밀번호 암호화, 로그인, JWT 발급, 인증 미들웨어 등 여러 기능을 한 번에 구현할 수도 있습니다. 결과물이 잘 동작한다면 편리하겠지만, 문제가 발생했을 때는 어느 단계부터 잘못됐는지 확인하기가 어려워집니다. 개발자가 검토해야 할 코드의 범위도 그만큼 넓어집니다.

그래서 AI와 협업할 때는 한 번에 하나의 작업만 요청하는 방식이 중요합니다. 인증 기능을 구현한다면 먼저 회원가입 기능을 만든 뒤 제대로 동작하는지 확인합니다. 이후 비밀번호 암호화를 추가하고 저장 결과를 검증합니다. 로그인 API를 만들었다면 반환된 토큰이 유효한지 확인하고, 인증 미들웨어를 별도로 만든 다음 단독으로 테스트합니다. 마지막으로 보호된 라우트에 미들웨어를 적용해 인증 없이 접근했을 때 제대로 차단되는지 확인합니다. 이렇게 작업을 작은 단계로 나누면 문제가 생겼을 때 AI도, 개발자도 어느 지점에서 잘못됐는지 빠르게 파악할 수 있습니다.

그렇다고 작업을 무조건 잘게 쪼개는 것이 답은 아닙니다. 너무 큰 작업은 검증하기 어렵지만, 지나치게 작은 작업은 AI가 계속 컨텍스트를 다시 읽고 코드를 탐색해야 하기 때문에 오히려 비효율적일 수 있습니다. 적절한 작업 크기를 판단할 때는 몇 가지 기준을 생각해볼 수 있습니다. 하나의 요청은 하나의 책임만 다루고, 결과를 독립적으로 테스트할 수 있어야 하며, 경험적으로는 AI가 만든 코드를 살펴보고 테스트하는 데 10분 이상 걸린다면 작업을 더 나눠볼 필요가 있습니다.

여기서 중요한 것은 'AI가 한 번에 얼마나 많은 코드를 만들 수 있느냐'가 아닙니다. ‘사람이 그 결과를 얼마나 빠르고 정확하게 검증할 수 있느냐’입니다.

AI가 추측하게 만들지 마세요

작업을 적절한 크기로 나눴다면 다음으로 중요한 것은 ‘명확하게 지시하는 것’입니다.  예를 들어 AI에게 이렇게 요청했다고 생각해봅시다. “TODO API 만들어줘.” 겉보기에는 간단하지만 실제로는 정해지지 않은 것이 많습니다. REST API인지 GraphQL인지, 어떤 필드가 필요한지, 완료 상태를 어떻게 저장할지, 에러 응답 형식은 무엇인지, 인증이 필요한지 알 수 없습니다.

이런 정보가 빠져 있으면 빈칸은 AI가 스스로 채워야 합니다. 그리고 AI의 판단이 우리가 원했던 방향과 같다는 보장은 없습니다.

AI는 모호한 지시보다 명확한 지시에서 훨씬 좋은 결과를 냅니다. SDD (Specification-Driven Development)의 핵심 가치 중 하나도 ‘대충 이렇게 해줘’가 아닌 명확한 명세 기반 개발에 있습니다.

결국 AI에게 일을 잘 시키려면 ‘무엇을 해야 하는지’뿐만 아니라 ‘어디까지 하면 완료인지’도 알려줘야 합니다. 필요한 컨텍스트를 전달하고 완료 조건을 명확하게 하면 AI가 자기 방식대로 추측할 여지가 줄어듭니다. 프로젝트가 커질수록 이러한 지시는 명세의 형태로 발전합니다. 요청 필드와 응답 형식, 에러 코드와 제약 사항 등을 정리한 명세가 있다면 AI는 자신의 해석이 아니라 개발자가 정한 기준에 맞춰 코드를 생성할 수 있습니다.

명세는 사람만을 위한 문서가 아닙니다. 개발자는 구현 방향을 이해하기 위해 읽고, AI는 코드를 생성하기 위한 맥락으로 활용할 수 있습니다. 하나의 문서가 개발자와 AI 모두에게 기준점이 되는 셈입니다.

좋은 AI 코딩은 결국 ‘알아서 잘 만들어줘’라고 말하는 기술이 아니라, AI가 무엇을 해야 하는지 명확하게 판단할 수 있도록 만드는 기술에 가깝습니다.

코드를 받았으면, 먼저 멈추고 확인하세요

AI가 코드를 만들어냈습니다. 실행해보니 잘 동작합니다. 그러면 바로 다음 기능을 요청해도 될까요? 아니요. 이 지점에서 중요한 것이 있습니다. 바로 리뷰입니다.

AI가 만든 코드의 작은 문제를 확인하지 않고 다음 작업으로 넘어가면 AI는 그 결과물을 다시 컨텍스트로 삼아 그 위에 새로운 코드를 작성합니다. 처음에는 변수명 하나, 예외 처리 하나 정도의 작은 문제였을 수 있습니다. 하지만 이런 문제가 계속 누적되면 나중에는 전체 구조를 손봐야 하는 기술 부채로 커질 수 있습니다.

첫 번째 작업에서 AI가 조금 이상한 구조로 함수를 만들었는데 이를 그대로 수용한 뒤 다음 작업을 요청하면, AI는 그 결과물을 기반으로 계속 코드를 작성합니다. 초기의 작은 문제가 코드베이스 전체의 구조적인 문제로 확대될 수 있습니다. 따라서 AI와의 개발은 “요청하고 결과를 받는 것”으로 끝나지 않습니다. 작은 작업 요청 → AI 결과물 확인 → 코드 리뷰 → 테스트 → 수정 또는 커밋 → 다음 작업 이런 사이클을 반복해야 합니다.

특히 리뷰할 때는 코드가 요구사항을 충족하는지, 품질에 문제가 없는지, 의도하지 않은 변경이 발생하지 않았는지 확인해야 합니다. 방향 자체가 잘못됐다면 AI에게 계속 수정을 시키며 살려내려고 하기보다 이전 상태로 되돌아가는 것도 방법입니다. AI와 작업할 때 ‘되돌리기’는 실패가 아니라 개발자가 주도권을 유지하기 위한 전략인 셈입니다.

결국 중요한 건 개발자의 판단입니다

여기까지 보면 한 가지 의문이 생깁니다. AI가 점점 더 똑똑해진다면 이런 과정도 언젠가는 모두 AI에게 맡길 수 있지 않을까요? 물론 AI는 코드베이스를 분석할 수 있습니다. 기술적으로 훌륭한 구현도 제안할 수 있습니다. 하지만 코드만 보고는 알 수 없는 것이 있습니다.

왜 이 기능이 중요한가?
우리 사용자는 실제로 어떻게 사용하는가?
지금 이 서비스에 정말 필요한 기능인가?

예를 들어 AI에게 TODO 앱에 목록 조회 API를 만들라고 한 상황을 생각해 봅시다. AI는 페이지네이션과 정렬, 태그, 첨부파일, 댓글까지 고려한 정교한 API를 만들었을 것입니다. 기술적으로는 아주 훌륭하죠. 하지만 대부분의 사용자가 몇 개의 할 일만 관리하는 단순한 TODO 앱을 원하는 상황이라면 어떨까요? 좋은 기술과 좋은 제품은 항상 같은 의미가 아닙니다.

AI는 코드베이스를 분석할 수 있지만 ‘왜 이 기능이 중요한가’, ‘사용자가 실제로 어떻게 사용하는가’, ‘현재 무엇이 중요한가’와 같은 비즈니스 맥락에는 한계가 있습니다. 이런 맥락을 AI에게 전달하지 않는다면 기술적으로 좋아 보이지만 실제로는 불필요한 기능을 구현할 수도 있습니다.

결국 AI는 여러 선택지를 제안할 수 있지만 현재 상황에서 무엇이 적절한지를 결정하는 것은 개발자의 몫입니다. 이때 필요한 것이 개발자의 ‘Taste’, 즉 기술적 판단력입니다. 문법적으로 올바른 코드와 좋은 코드를 구분하고, 여러 선택지 가운데 현재 상황에 적합한 것을 고르고, 장기적으로 유지하기 좋은 구조인지 판단하는 능력입니다.

AI 시대에 코드 작성의 비중은 줄어들 수 있지만, 이 판단의 중요성은 오히려 커집니다.

바이브 코딩의 다음 단계는 ‘협업’입니다

바이브 코딩이 잘못된 개발 방식이라는 이야기는 아닙니다. AI 덕분에 아이디어를 빠르게 코드로 옮기고 실험해볼 수 있게 된 것은 분명 큰 변화입니다. 전문 개발자가 아니더라도 빠르게 프로토타입을 만들고 아이디어를 검증할 수 있게 됐다는 것 역시 AI 코딩이 가져온 중요한 변화입니다.

하지만 ‘AI에게 코딩을 맡기는 것’만으로 규모가 있는 소프트웨어를 안정적으로 만들어가기에는 부족합니다. 프로젝트가 커질수록 개발자는 다시 질문해야 합니다.

이 작업을 어떻게 나눌 것인가?

AI에게 어떤 정보를 전달할 것인가?

결과는 어떻게 검증할 것인가?

그리고 어디에서 개발자가 판단할 것인가?

AI 시대의 개발자는 단순히 프롬프트를 입력하는 사람이 아닙니다. AI에게 작업을 지시하고, 결과를 검토하고, 방향을 조율하며 최종 품질을 판단하는 사람입니다. 바이브 코딩으로 우리는 “AI에게 코딩을 맡길 수 있다”​는 것을 경험했습니다. 이제 그다음 질문을 고민할 때입니다. “AI와 어떻게 제대로 일할 것인가?”

바이브 코딩의 다음 단계는 AI에게 더 많은 코드를 맡기는 것이 아니라, AI와 제대로 협업하는 개발일지도 모릅니다.

위 컨텐츠는 『클로드 코드 마스터』 내용을 바탕으로 작성하였습니다.  

바이브 코딩의 한계를 넘어, AI가 더 체계적으로 일하도록 만들고 그 결과를 검증하려면 어떻게 해야 할까요?

『개발자 기술 면접 노트』, 『클로드 코드 마스터』의 이남희 저자가 진행하는 이번 세미나에서는 바이브 코딩에서 한 단계 더 나아가, Claude Code를 활용한 하네스 엔지니어링과 코드 검증 방법을 다룹니다. AI에게 일을 맡기는 것에서 그치지 않고, 통제하고 검증하는 방법이 궁금하다면 세미나에서 직접 확인해 보세요.

세미나 자세히 보기