[바이브 코딩] 5. 워크플로 : 사람과 AI 역할 나누기

(바이브 코딩 ⑤) 워크플로

이 시리즈를 관통하는 결론은 하나다. 바이브 코딩을 오래 잘하는 사람은 사람과 AI의 역할을 헷갈리지 않는다. 둘이 잘하는 게 다르기 때문이다.

사람이 잡는 것은 목표, 설계, 검수, 그리고 최종 결정이다. 무엇을 왜 만들지, 어떤 구조로 갈지, 나온 결과가 맞는지, 그리고 위험한 걸 실행할지 말지. 이건 넘기면 안 되는 영역이다. AI가 잘하는 것은 구현, 탐색, 반복이다. 정해진 방향대로 코드를 써 내려가고, 여러 방법을 빠르게 시도하고, 피드백을 받아 고치는 일. 이건 사람보다 빠르다.

실전 루프로 정리하면 이렇다. 사람이 목표와 제약을 명확히 던진다 → AI가 구현한다 → 돌려서 검증한다 → 어긋나면 구체적으로 지적해 다시 시킨다 → 통과하면 사람이 검수하고 받아들인다. 이 사이클을 작게 여러 번 도는 게, 한 번에 크게 던지는 것보다 훨씬 안정적이다.

역할을 표로 정리하면

사람이 맡는 것	AI가 맡는 것
목표 — 무엇을 왜 만들지	구현 — 코드로 옮기기
설계 — 어떤 구조로 갈지	탐색 — 여러 대안 제시
검수 — 나온 게 맞는지 판단	반복 — 빠른 수정
최종 결정과 책임	(여기까지 오면 사람 몫)

어디까지 맡길까 — ‘되돌리기’가 기준

판단 기준은 단순하다. 되돌리기 쉬운가. 초안·탐색·반복처럼 틀려도 쉽게 버리고 다시 할 수 있는 일은 넓게 맡긴다. 반대로 DB 마이그레이션, 배포, 파일 삭제처럼 비가역적인 일은 사람이 확인한 뒤에 진행한다. 여기에 ‘검증 가능성’을 하나 더 본다 — 테스트로 맞는지 확인할 수 있는 작업이면 더 맡겨도 안전하다.

기록과 계획이 워크플로를 지탱한다

오래 잘하는 사람은 프롬프트 로그와 결정 메모를 남긴다. 무엇을 왜 이렇게 정했는지가 기록으로 남아야 나중에 넘기거나 되짚을 수 있다. 그리고 큰 작업은 코드부터 시키지 않고 계획부터 세운다. 이 두 습관 — 기록하고 계획하기 — 이 속도를 ‘반짝’이 아니라 ‘지속 가능’하게 만든다.

데인 기록 하나 — 검수가 잡은 것

역할 분담을 말로만 하면 공허하니, 실제로 데일 뻔했던 기록 하나. 블로그 글 100여 편을 일괄 수정하는 스크립트를 AI에게 맡겼을 때다. 스크립트는 “이미 처리된 글은 건너뛴다”를 특정 문구가 본문에 있는지로 판정했는데, 하필 그 문구와 우연히 겹치는 문장이 있던 글 하나가 처리 안 됐는데 처리된 걸로 건너뛰어졌다. 실행 로그는 전부 정상이었다.

이걸 잡은 건 사람의 검수 단계였다 — 처리 결과 개수를 원본 목록과 대조하니 하나가 비었다. AI의 구현은 합리적이었고(멱등 처리), 버그도 아니었고(판정 로직대로 동작), 그냥 엣지 케이스였다. 교훈은 분명하다: 위임한 대량 작업일수록 ‘전부 됐다’는 보고를 믿지 말고, 독립적인 수단으로 총량을 대조하라. 검수는 AI가 짠 것을 다시 읽는 게 아니라, 다른 각도에서 재는 일이다.

결국 남는 건 판단력

도구와 모델은 계속 바뀐다. 하지만 ‘무엇을 만들지’와 ‘나온 게 맞는지’를 판단하는 능력은 사람에게 남는다. 바이브 코딩은 그 판단력을 없애는 게 아니라, 판단력 있는 사람의 손을 몇 배로 키우는 도구다. 이 시리즈를 관통한 결론이 바로 이것이다. 무엇을 넣어줄지를 더 파고들고 싶다면 컨텍스트 엔지니어링 시리즈로 이어가면 좋다.

위임해도 되는 것과 안 되는 것

경계가 헷갈릴 때 쓰는 간단한 분류다.

• 넓게 맡김 — 초안 작성, 여러 대안 탐색, 반복 수정, 정해진 규칙의 대량 변경, 테스트로 검증 가능한 것.
• 사람이 확인 후 — DB 마이그레이션, 배포, 파일·데이터 삭제, 보안·인증 코드, 비용이 큰 외부 호출.
• 사람만 — 무엇을 왜 만들지(목표), 큰 구조 결정, 최종 승인과 책임.

AI에게 어디까지 맡겨도 되나요?

되돌리기 쉽고 검증 가능한 작업(초안·반복·탐색)은 넓게 맡기고, 파괴적·비가역 작업은 사람이 확인한 뒤 진행하세요.