IBM 코딩 에이전트 Bob, HITL 체크포인트로 파일럿 실패 패턴을 끊는다

AI 에이전트가 파일럿에서 프로덕션으로 넘어갈 때 가장 많이 실패하는 이유는 오케스트레이션 구조가 없어서다. IBM이 AI 코딩 에이전트 Bob을 글로벌 출시하면서 멀티모델 라우팅과 HITL(Human-in-the-Loop) 체크포인트를 시스템 설계 단계부터 내장했다. 파일럿에서만 됐던 AI 코딩을 실제 프로덕션에서 쓸 수 있게 만드는 구조적 접근이다.

HITL이 뭐고, 왜 지금 이게 핵심인가

HITL은 Human-in-the-Loop의 약자다. 에이전트가 혼자 결정하지 않고, 중요한 단계에서 사람의 승인을 받는 구조를 뜻한다. 단순히 '에이전트를 감시한다'는 개념이 아니라, 체크포인트를 어디에 어떻게 설계하느냐가 시스템의 신뢰도를 결정한다.

기존 AI 코딩 도구의 문제는 두 가지였다. 단일 모델에만 의존하고, 인간 개입이 임의적이라는 점이다. Bob은 이 두 가지를 동시에 바꿨다.

• 멀티모델 라우팅: 작업 유형에 따라 최적 모델을 자동 선택해 단일 모델 의존 리스크를 줄인다
• 구조화된 HITL: 파일럿 단계가 아니라 프로덕션 SDLC(소프트웨어 개발 라이프사이클) 전체에 승인 게이트를 설계 단계부터 내장한다

에이전트가 중요한 결정을 내리기 직전, 사람이 개입할 수 있는 지점을 시스템이 강제한다. '에이전트를 믿을 수 없을 때'가 아니라 '에이전트를 믿기 때문에' 체크포인트를 두는 설계 철학이다.

내가 만드는 AI 서비스에 이게 왜 필요한가

소규모 빌더가 AI 서비스를 만들 때 자주 겪는 패턴이 있다. 테스트 환경에서는 잘 돌아가다가, 실제 사용자 데이터와 실시간 상황이 붙으면 에이전트가 엉뚱한 결정을 내린다. IBM이 Bob에서 해결하려는 문제가 정확히 이것이다.

지금 만들고 있는 AI 도구에서 '에이전트가 혼자 결정하는 순간'이 몇 개인지 한 번 세어보면 좋다. 결제를 건드리는 결정인지, 외부 API를 호출하는 결정인지, 데이터를 수정하는 결정인지 — 그 중 하나에 '승인 게이트'를 달았을 때 서비스 신뢰도가 어떻게 달라지는지가 HITL 설계의 출발점이다.

IBM Bob이 엔터프라이즈 규모에서 이 구조를 적용하는 첫 공개 사례라는 점에서, 개인 빌더가 참고할 수 있는 설계 패턴이 여기서 나오기 시작한다.