결제 금액이 조금씩 어긋나기 시작했다
할인율을 적용해 최종 결제 금액을 계산하는 함수가 있다고 해봅시다. 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 루프로 반복 검증 |
| 문제 발생 시 책임 소재 | 불명확 | 사람이 최종 책임 |
정리하면
결제 로직의 1원짜리 오류는 사소해 보이지만, 같은 패턴이 재고 계산이나 권한 체크 로직에서 벌어지면 훨씬 큰 문제가 됩니다. AI가 코드를 짜는 속도는 그대로 활용하되, 계획 단계와 실행 단계 각각에 사람의 확인을 끼워 넣는 것. PH-AH 루프가 하는 일은 이게 전부입니다.
자주 묻는 질문
Q. PH-AH 루프를 적용하면 개발 속도가 많이 느려지지 않나요? 계획 단계에서의 검토는 보통 몇 분이면 끝납니다. 반면 코드가 다 만들어진 뒤 오류를 발견해서 되돌리는 데 걸리는 시간과 비교하면, 전체적으로는 오히려 시간이 절약되는 경우가 많습니다.
Q. 모든 작업에 이 루프를 적용해야 하나요? 아닙니다. 실수가 나도 되돌리기 쉽고 영향이 작은 작업(예: 문서 초안, 간단한 스크립트)은 가볍게 검토해도 됩니다. 되돌리기 어렵거나 실제 금전·데이터 손실로 이어지는 작업일수록 루프를 엄격하게 적용하세요.