결제 금액이 조금씩 어긋나기 시작했다
할인율을 적용해 최종 결제 금액을 계산하는 함수가 있다고 해봅시다. AI에게 “할인율 적용 로직을 짜줘”라고 요청했더니 코드가 뚝딱 나왔고, 테스트 몇 건을 돌려보니 문제없이 작동했습니다. 그대로 배포했습니다.
몇 주 뒤, 특정 금액대(예: 소수점이 딱 떨어지지 않는 금액)에서 결제 금액이 1원씩 어긋나는 문제가 발견됩니다. 코드를 열어보니, AI가 짠 반올림 처리 방식이 이 회사의 결제 정책과 미묘하게 달랐습니다. 코드를 짤 당시 아무도 그 로직을 제대로 들여다보지 않았기 때문에, 이 차이를 아무도 눈치채지 못했던 겁니다.
이게 바이브코딩의 전형적인 실패 패턴입니다.
바이브코딩이 위험한 이유
바이브코딩은 AI가 만든 코드를, 그 동작 원리를 이해하지 않은 채로 그냥 쓰는 태도를 말합니다. 당장은 작동하는 것처럼 보입니다. 테스트도 통과합니다. 문제는 나중에 오류가 발생했을 때입니다. 코드를 짠 사람이 애초에 로직을 이해하지 못했으니, 무엇이 잘못됐는지 스스로 찾아낼 수 없습니다. 코드에 숨어 있던 결함도 사전에 검토되지 않았기 때문에, 문제가 겉으로 드러날 때까지 계속 누적됩니다.
에이전틱 엔지니어링의 원칙
에이전틱 엔지니어링은 이 문제에 대한 대응입니다. 핵심 원칙은 단순합니다. AI는 초안을 빠르게 만드는 역할을 하고, 사람은 방향을 정하고 결과물을 반드시 검토하는 역할을 맡습니다. 속도는 AI 덕분에 확보하되, 품질에 대한 책임은 사람이 계속 갖고 있는 겁니다. 이 원칙은 모델 성능이 아무리 좋아져도 바뀌지 않습니다. 모델이 똑똑해질수록 오히려 그럴듯하게 틀린 코드를 만들 가능성이 커지기 때문에, 검토의 필요성은 줄어들지 않습니다.
PH-AH 루프: 계획과 실행 각각에 사람을 넣는다
PH-AH는 Plan+Human-in-the-loop, Action+Human-in-the-loop의 줄임말입니다. 결제 로직 사례에 대입하면 이렇게 됩니다.
계획 단계 (Plan + Human). AI에게 “할인율 적용 로직을 어떻게 짤 건지 계획부터 설명해줘”라고 먼저 물어봅니다. AI가 “반올림은 이런 방식으로, 예외 케이스는 이렇게 처리하겠다”는 계획을 제시하면, 사람이 이 계획을 검토합니다. 여기서 “우리 회사는 반올림이 아니라 절사 방식을 쓴다”는 걸 미리 알려주면, 코드를 짜기 전에 방향을 바로잡을 수 있습니다.
실행 단계 (Action + Human). 확정된 계획대로 AI가 실제 코드를 작성합니다. 코드가 나오면 사람이 결과를 리뷰합니다. 여기서도 문제가 있으면 수정을 요청하고 확정합니다.
이 두 단계를 거치면, 결제 로직 사례에서 발생했던 반올림 오류는 계획 단계에서 걸러졌을 가능성이 높습니다. “계획을 먼저 보여줘”라는 한 단계가 나중에 몇 주 뒤 발견되는 오류를 미리 막아주는 겁니다.
왜 이게 오류를 줄이는가
PH-AH 루프가 작동하는 이유는 검증 지점을 앞으로 당기기 때문입니다. 코드가 다 만들어진 뒤에 검토하면, 이미 그 코드 위에 다른 기능들이 얹혀 있어서 되돌리기 어렵습니다. 계획 단계에서 방향이 틀렸다는 걸 발견하면, 코드를 한 줄도 쓰기 전에 바로잡을 수 있습니다. 작은 단위로 반복해서 검증하기 때문에, 오류가 누적되기 전에 하나씩 걸러지는 구조입니다.
모든 걸 다 검토하면 AI를 쓰는 의미가 없다
여기서 흔히 하는 오해가 있습니다. “그럼 결국 사람이 모든 코드를 한 줄 한 줄 다 봐야 하는 거 아니냐”는 겁니다. 그렇게 하면 AI를 쓰는 속도상의 이점이 사라집니다.
실무에서는 검토의 강도를 구분합니다. 결제 금액 계산처럼 틀리면 실제 손실이 발생하는 로직은 코드를 한 줄씩 검토합니다. 반면 화면 레이아웃처럼 눈으로 보고 바로 판단할 수 있는 부분은 결과물만 훑어봐도 충분합니다. 프론트엔드는 시각적 결과 확인, 백엔드 핵심 로직은 코드 검토, 이런 식으로 검토 대상과 강도를 미리 구분해두는 게 실무적인 절충안입니다.
바이브코딩 vs 에이전틱 엔지니어링
| 항목 | 바이브코딩 | 에이전틱 엔지니어링 |
|---|---|---|
| 태도 | 이해 없이 그대로 사용 | 리뷰한 뒤 활용 |
| 사람의 역할 | 최종 확인만 하거나 아예 안 함 | 계획·실행 각 단계에서 검토·확정 |
| 프로세스 | 반복 없이 한 번에 끝 | PH-AH 루프로 반복 검증 |
| 문제 발생 시 책임 소재 | 불명확 | 사람이 최종 책임 |
검토 강도를 어떻게 나누는가
실무에서 모든 코드를 똑같은 강도로 검토하는 건 비현실적입니다. 아래 기준으로 나눠보면 결정이 쉬워집니다.
| 코드 유형 | 예시 | 검토 강도 |
|---|---|---|
| 금전·수량이 걸린 계산 로직 | 할인율 적용, 재고 차감, 포인트 적립 | 한 줄씩 리뷰, 엣지 케이스(소수점, 0, 음수) 직접 테스트 |
| 권한·보안 관련 | 접근 제어, 인증 토큰 처리 | 한 줄씩 리뷰 + 별도 보안 체크리스트 |
| 데이터 변환·마이그레이션 | 대량 데이터 일괄 수정 | 실행 전 소수 샘플로 결과 검증 |
| 화면 레이아웃·스타일 | 버튼 위치, 색상 | 결과물을 눈으로 훑어보는 수준으로 충분 |
| 반복적인 보일러플레이트 | CRUD API 뼈대 | 패턴이 맞는지만 확인 |
이 표의 기준은 “틀렸을 때 피해가 큰가”와 “틀렸는지 눈으로 바로 알 수 있는가” 두 축으로 정리한 것입니다. 피해가 크고 눈으로 바로 알기 어려운 로직(결제, 권한)일수록 PH-AH 루프의 검토를 촘촘하게 넣어야 합니다.
두 번째 예시 — 포인트 적립 로직
같은 패턴이 포인트 적립 기능에서도 반복될 수 있습니다. “구매 금액의 5%를 포인트로 적립해줘”라는 요청에 AI가 코드를 짜면, 보통은 잘 동작합니다. 다만 “환불 시 적립된 포인트를 어떻게 처리할지”는 요청에 명시하지 않으면 AI가 임의로 판단합니다 — 어떤 경우엔 포인트를 회수하는 로직을 빼먹고, 어떤 경우엔 과도하게 회수하는 로직을 만들기도 합니다. 계획 단계에서 “환불 시 포인트 처리 방침”을 사람이 먼저 명시해주는 것만으로, 이런 누락을 코드 작성 전에 막을 수 있습니다. PH-AH 루프의 가치는 결국 “AI가 혼자 판단하게 두는 지점”을 사람이 먼저 걸러낸다는 데 있습니다.
정리하면
결제 로직의 1원짜리 오류는 사소해 보이지만, 같은 패턴이 재고 계산이나 권한 체크 로직에서 벌어지면 훨씬 큰 문제가 됩니다. AI가 코드를 짜는 속도는 그대로 활용하되, 계획 단계와 실행 단계 각각에 사람의 확인을 끼워 넣는 것. PH-AH 루프가 하는 일은 이게 전부입니다.
자주 묻는 질문
Q. PH-AH 루프를 적용하면 개발 속도가 많이 느려지지 않나요? 계획 단계에서의 검토는 보통 몇 분이면 끝납니다. 반면 코드가 다 만들어진 뒤 오류를 발견해서 되돌리는 데 걸리는 시간과 비교하면, 전체적으로는 오히려 시간이 절약되는 경우가 많습니다.
Q. 모든 작업에 이 루프를 적용해야 하나요? 아닙니다. 실수가 나도 되돌리기 쉽고 영향이 작은 작업(예: 문서 초안, 간단한 스크립트)은 가볍게 검토해도 됩니다. 되돌리기 어렵거나 실제 금전·데이터 손실로 이어지는 작업일수록 루프를 엄격하게 적용하세요.
AI가 쓴 코드를 배포하기 전 점검할 6가지
- AI가 짠 로직을 사람이 한 줄씩 설명할 수 있는가 (설명할 수 없다면 아직 배포 단계가 아니다)
- 계획 단계에서 사람이 방향을 확인하고, 실행 단계에서 결과를 다시 확인하는 두 지점이 있는가
- 반올림·단위·경계값처럼 정책과 미묘하게 달라지는 부분을 테스트 케이스로 만들었는가
- 테스트가 통과했다는 사실을 정확성의 증거로 과신하지 않았는가
- 결제·정산처럼 오류 비용이 큰 영역은 검토를 더 강하게 설계했는가
- 문제가 생겼을 때 원인을 추적할 로그와 변경 이력이 있는가
추가로 자주 나오는 질문
Q. 바이브코딩은 항상 나쁜가요? 오류 비용이 낮은 프로토타입이나 일회성 스크립트에는 효율적일 수 있습니다. 문제는 결제처럼 틀리면 비용이 큰 영역에 이해 없이 쓰는 것입니다.
Q. 모델이 좋아지면 검토가 필요 없어지나요? 아닙니다. 모델이 좋아질수록 그럴듯하게 틀린 코드가 늘어 눈에 띄기 어려워질 수 있어 검토의 필요성은 줄지 않습니다.
Q. PH-AH 루프를 도입하면 속도가 느려지나요? 초안은 AI가 빠르게 만들기 때문에 속도 이점은 유지되고, 사람은 방향 확인과 결과 검토에만 개입합니다. 위험도가 낮은 구간은 개입을 줄일 수 있습니다.