AI 에이전트를 제품으로 만들겠다고 마음먹으면, 많은 팀이 시작부터 거대한 설계를 꿈꾼다. 권한 체계도 넣고 싶고, 장기 메모리도 붙이고 싶고, 여러 도구를 연결하고 싶고, 자동 복구와 평가 파이프라인도 한 번에 갖추고 싶어진다. 문제는 그렇게 시작한 프로젝트가 자주 완성되지 않는다는 데 있다. 구조는 복잡한데, 정작 사용자는 한 번도 써보지 못하는 상태가 오래간다.
그래서 제품 수준의 하네스를 만들고 싶을수록, 출발점은 오히려 작아야 한다. 최소 실행 가능한 하네스는 대단한 자동화가 아니다. 대신 통제 가능한 자동화다. 입력이 무엇인지 분명하고, 어떤 순서로 일하는지 보이며, 결과를 어디서 멈춰야 하는지도 알 수 있는 아주 작은 작업장이다.
이 장의 목표는 완벽한 하네스를 설계하는 것이 아니다. 가장 작은 통제 구조를 만들어 빠르게 검증하고, 그다음 확장할 수 있는 출발점을 만드는 것이다.
MVP 하네스는 작은 기능이 아니라 작은 통제 구조다
많은 사람이 MVP를 기능 축소판으로 이해한다. 물론 기능을 줄이는 것도 맞다. 하지만 에이전트에서는 그것만으로는 부족하다. 에이전트의 MVP는 기능을 줄인 버전이면서 동시에 통제 지점을 남겨 둔 버전이어야 한다.
예를 들어, 고객 문의를 처리하는 에이전트를 만든다고 해보자. 처음부터 메일을 읽고, CRM을 조회하고, 환불 정책을 찾고, 답장을 보내고, 티켓 상태까지 바꾸게 만들 필요는 없다. 그렇게 하면 멋져 보이지만, 어디서 실패했는지 알기 어려워진다. MVP에서는 한 단계만 맡긴다. 고객 문의를 읽고, 관련 문서를 찾고, 답변 초안을 만드는 정도면 충분하다. 전송은 사람이 한다.
이 차이는 매우 중요하다. 작은 기능은 그저 덜하는 제품이지만, 작은 통제 구조는 무엇이 잘되고 무엇이 위험한지를 학습하게 해주는 제품이다.
최소 구조는 다섯 칸이면 된다
최소 실행 가능한 하네스는 복잡할 필요가 없다. 다만 다음 다섯 칸은 있어야 한다.
입력: 무엇을 받아서 시작하는가
계획: 지금 어떤 방식으로 처리할지 어떻게 정하는가
실행: 어떤 도구나 모델 호출로 실제 작업을 하는가
검증: 결과가 최소 기준을 만족하는지 어떻게 확인하는가
출력: 사람이 쓰거나 다음 시스템이 받을 수 있는 형태로 어떻게 내보내는가
이 다섯 칸이 없으면 에이전트는 그냥 한 번 대답하는 모델 호출에 가깝다. 반대로 이 다섯 칸만 있어도 작은 제품처럼 움직이기 시작한다.
핵심은 각 칸을 크게 만드는 것이 아니라, 칸 사이의 경계를 분명히 만드는 데 있다. 입력과 출력이 섞이면 재현이 어렵고, 계획과 실행이 섞이면 오류 원인을 찾기 힘들며, 검증이 빠지면 자동화는 곧바로 위험해진다.
입력: 넓게 받지 말고 좁게 정의하라
MVP 단계에서 가장 흔한 실수는 입력을 너무 넓게 잡는 것이다. 모든 자연어 요청을 처리하겠다는 식의 출발은 멋있지만 실패하기 쉽다. 최소 하네스에서는 입력을 일부러 좁혀야 한다.
좋은 입력 정의는 세 가지를 분명하게 만든다.
어떤 형식의 요청만 받는가
어떤 정보가 반드시 포함되어야 하는가
어떤 요청은 애초에 받지 않는가
예를 들어 고객 문의 답변 초안 하네스라면 입력은 이렇게 좁힐 수 있다. 사용자가 보낸 원문 메시지, 고객 유형, 언어, 관련 주문 번호 정도만 받는다. 첨부파일 해석, 감정 분석, 다국어 번역, 환불 승인 판단 같은 것은 일단 제외한다.
입력을 좁히면 좋은 점이 많다. 우선 프롬프트가 짧아진다. 다음으로 검증 기준을 세우기 쉬워진다. 마지막으로 실패를 분류하기 쉬워진다. 무엇보다 중요한 것은, 입력 스키마가 곧 제품의 첫 번째 안전장치가 된다는 점이다.
MVP에서 입력은 자유로운 대화가 아니라, 잘 정의된 작업 요청에 가까워야 한다.
계획: 오래 생각하게 하지 말고 결정하게 하라
계획 단계라고 해서 거창한 추론 체계를 먼저 만들 필요는 없다. MVP에서 계획은 보통 두세 가지 판단만 잘해도 충분하다. 이 요청이 처리 가능한 범위인지, 어떤 도구가 필요한지, 성공 조건이 무엇인지 정하는 정도면 된다.
여기서 중요한 것은 모델에게 긴 생각을 요구하는 것이 아니라, 명확한 결정 포인트를 주는 것이다. 예를 들어 다음과 같은 질문이면 충분하다.
이 요청은 지원 가능한 범위 안에 있는가?
문서 검색이 필요한가, 아니면 바로 답변 초안을 만들 수 있는가?
불확실성이 높다면 사람 검토로 넘겨야 하는가?
계획이 너무 복잡해지면 MVP가 아니라 작은 연구 프로젝트가 된다. 계획은 실행을 똑똑하게 만드는 장치가 아니라, 실행을 예측 가능하게 만드는 장치라고 생각하는 편이 좋다.
실행: 도구는 하나로 시작하라
최소 실행 가능한 하네스를 만들 때는 도구를 하나만 연결하는 것이 좋다. 가능하면 읽기 전용 도구가 가장 안전하다. 검색, 조회, 읽기 같은 동작부터 시작하고, 수정, 전송, 삭제, 결제 같은 쓰기 동작은 나중으로 미루는 편이 낫다.
도구를 하나로 시작해야 하는 이유는 단순하다. 에이전트 실패의 상당수는 모델 자체보다 도구 선택과 도구 사용에서 나온다. 도구가 많아질수록 잘못된 선택 가능성이 커지고, 디버깅도 어려워진다. 반대로 도구가 하나면 실패가 훨씬 선명하게 보인다. 검색어가 나빴는지, 문서를 잘못 읽었는지, 문서가 원래 없었는지처럼 원인을 좁힐 수 있다.
MVP 단계에서는 다음과 같은 원칙이 유용하다.
읽기 전용 도구부터 시작한다.
도구 설명은 짧고 단순하게 쓴다.
한 번의 작업에서 도구 호출 횟수에 상한을 둔다.
도구가 실패하면 재시도보다 사람 검토로 넘기는 편을 우선한다.
에이전트를 똑똑하게 보이게 만드는 것보다, 도구 사용을 예측 가능하게 만드는 것이 먼저다.
검증: 정답을 맞히는 것보다 위험한 오답을 막아라
MVP에서 검증은 완벽한 채점기가 아니다. 최소 검증은 결과가 쓸 만한지보다, 위험한 상태인지 아닌지를 먼저 가려내는 장치다.
예를 들어 고객 문의 답변 초안이라면 이런 검증 규칙을 둘 수 있다.
관련 문서 근거가 하나도 없으면 실패로 본다.
환불, 법률, 계정 보안처럼 민감한 주제는 자동 답변 금지로 본다.
답변이 지나치게 단정적이거나 정책과 충돌하면 사람 검토로 넘긴다.
출력 형식이 정해진 틀을 벗어나면 재생성하거나 실패 처리한다.
이 검증의 목적은 모델의 지능을 평가하는 데 있지 않다. 제품 위험을 제어하는 데 있다. 좋은 MVP 하네스는 높은 정답률보다 낮은 사고율을 먼저 만든다.
검증을 너무 늦게 넣으면 팀은 금방 이런 착각에 빠진다. 데모에서는 잘 되던데 왜 실제 운영에서 문제지? 이유는 간단하다. 데모는 보기 좋은 사례만 보여주고, 운영은 보기 싫은 사례까지 전부 받아들이기 때문이다. 검증은 바로 그 보기 싫은 사례를 걸러내기 위한 장치다.
출력: 사람이 바로 쓸 수 있는 형태여야 한다
에이전트 출력은 그럴듯한 문장이 아니라, 다음 행동으로 이어질 수 있는 결과물이어야 한다. MVP일수록 이 원칙이 중요하다. 출력이 애매하면 사람은 매번 다시 읽고 해석해야 하고, 그러면 자동화의 이점이 줄어든다.
좋은 출력은 보통 다음 요소를 포함한다.
최종 결과물
결과를 만든 근거 또는 사용한 자료
확신 수준 또는 검토 필요 여부
다음 단계 제안
예를 들어 답변 초안 하네스의 출력은 단순한 문장 덩어리가 아니라, 답변 제목, 본문 초안, 참고 문서 ID, 사람 검토 필요 여부로 구성될 수 있다. 그러면 운영자는 바로 복사해 쓰거나, 수정이 필요한 건만 골라낼 수 있다.
출력 형식을 먼저 정해 두면 프롬프트도 좋아지고 검증도 쉬워진다. 에이전트를 설계할 때 입력보다 출력부터 정하는 편이 실무에서 더 잘 먹히는 이유가 여기에 있다.
로그는 MVP에도 반드시 있어야 한다
아직 작은 실험인데 로그까지 필요하냐는 질문을 자주 받는다. 필요하다. 오히려 MVP일수록 필요하다. 왜냐하면 이 단계의 목적은 자동화 자체보다 학습에 있기 때문이다.
최소한 다음 정도는 남겨 두는 편이 좋다.
어떤 입력이 들어왔는가
어떤 프롬프트 버전으로 실행했는가
어떤 도구를 몇 번 호출했는가
검증에서 통과했는가, 실패했는가
최종적으로 사람에게 전달됐는가, 중단됐는가
처리 시간은 얼마나 걸렸는가
이 정도만 있어도 팀은 중요한 질문에 답할 수 있다. 실패가 입력 문제인지, 계획 문제인지, 도구 문제인지, 검증 문제인지 구분할 수 있기 때문이다. 로그가 없으면 개선은 감에 의존하게 되고, 감에 의존한 자동화는 대체로 오래가지 못한다.
실패 처리: 멈춤도 기능이다
최소 하네스에서 특히 중요한 설계는 실패를 다루는 방식이다. 많은 팀이 성공 경로만 만든 뒤, 실패는 나중에 생각하자고 미룬다. 하지만 에이전트는 실패 경로가 먼저 설계돼야 한다. 멈출 줄 아는 자동화가 위험하지 않은 자동화다.
MVP에서는 실패를 크게 세 가지로만 나눠도 충분하다.
재질문: 입력이 부족해 작업을 진행할 수 없을 때
재시도: 일시적인 도구 오류나 형식 오류가 있을 때
이관: 민감하거나 불확실해 사람 검토가 필요할 때
여기서 중요한 것은, 실패를 숨기지 않는 것이다. 답을 억지로 만들어 내는 것보다, 지금은 판단 불가라고 말하는 편이 훨씬 낫다. 제품 수준의 신뢰는 똑똑해 보이는 답변보다, 멈춰야 할 때 멈추는 태도에서 생긴다.
최소 하네스에서 일부러 빼야 하는 것들
MVP를 만들 때는 무엇을 넣을지보다 무엇을 빼야 하는지가 더 중요하다. 초기에 욕심을 내면 구조가 금방 무거워진다.
처음 버전에서는 보통 다음 요소를 의도적으로 제외하는 편이 좋다.
장기 메모리
여러 도구의 조합 실행
완전 자동 승인과 전송
멀티에이전트 분업
복잡한 자기 수정 루프
사용자별 세밀한 개인화
이 기능들은 나중에 필요할 수 있다. 하지만 MVP의 질문은 이것이다. 이 작업이 작은 통제 구조 안에서 반복 가능하게 돌아가는가? 이 질문에 답하기 전에는 기능을 늘릴수록 불확실성만 커진다.
예시: 고객 문의 답변 초안 하네스
이제 아주 작은 예시를 하나 보자. 목표는 고객 문의를 자동 처리하는 것이 아니라, 고객 문의에 대한 초안을 빠르게 만드는 것이다.
입력은 고객 문의 원문과 주문 번호다. 계획 단계에서는 문의 유형을 분류하고, 문서 검색이 필요한지 결정한다. 실행 단계에서는 도움말 문서 검색 도구를 한 번 또는 두 번 호출한다. 검증 단계에서는 정책 문서가 실제로 검색되었는지, 민감 주제인지, 답변 형식이 맞는지를 확인한다. 출력 단계에서는 답변 초안과 참고 문서, 검토 필요 표시를 함께 보낸다.
이 구조의 좋은 점은 아주 분명하다. 에이전트는 고객에게 직접 메일을 보내지 않는다. 주문을 변경하지도 않는다. 환불을 승인하지도 않는다. 하지만 사람의 시간을 줄이는 데는 이미 충분히 도움이 된다. 무엇보다 실패 원인이 잘 보인다. 문서를 못 찾았는지, 검색어가 나빴는지, 답변이 정책을 과장했는지 모두 로그로 남길 수 있다.
이런 MVP는 겉으로 보기에는 소박하다. 그러나 제품 관점에서는 훨씬 강하다. 통제 가능한 작은 성공을 만드는 구조이기 때문이다.
MVP 하네스의 평가 기준
최소 하네스가 준비되면, 이제 정말 중요한 질문을 던져야 한다. 이 구조가 확장할 가치가 있는가?
그 판단은 화려한 데모가 아니라 몇 가지 단순한 지표로 내릴 수 있다.
사람이 거의 손대지 않고 사용할 수 있는 출력 비율이 얼마나 되는가
위험한 요청이 적절히 사람 검토로 이관되는가
도구 호출 실패와 형식 오류가 얼마나 자주 나는가
기존 수작업 대비 시간이 실제로 줄었는가
같은 유형의 요청에서 결과 품질이 반복 가능하게 유지되는가
이 지표를 보면 다음 단계가 보인다. 출력 품질은 괜찮은데 처리 시간이 느리다면 실행 구조를 손보면 된다. 품질은 좋은데 위험 요청 구분이 약하다면 검증 규칙을 강화하면 된다. 사람 수정량이 너무 많다면 입력 범위를 더 줄이거나 출력 형식을 바꿔야 한다.
즉, MVP 하네스의 목적은 완성품을 만드는 것이 아니라 어디를 키워야 하는지 알게 만드는 것이다.
작은 하네스가 좋은 확장의 출발점이 된다
처음부터 완벽한 하네스는 없다. 잘 만든 하네스는 대개 작게 시작해서 커진다. 입력을 좁히고, 도구를 하나로 제한하고, 검증을 단순하게 두고, 출력 형식을 고정한 뒤, 로그를 보면서 조금씩 넓혀 간다. 이 순서를 건너뛰면 자동화는 금방 멋진 혼란이 된다.
최소 실행 가능한 하네스는 볼품없는 프로토타입이 아니다. 오히려 제품으로 가기 위한 가장 현실적인 출발점이다. 입력, 계획, 실행, 검증, 출력이라는 다섯 칸만 제대로 세워도 에이전트는 비로소 한 번의 응답이 아니라 하나의 작업 시스템처럼 움직이기 시작한다.
중요한 것은 크기가 아니라 경계다. 작더라도 어디까지 맡기고 어디서 멈추는지가 분명한 하네스는 신뢰를 만든다. 그리고 그 신뢰가 쌓일 때, 비로소 우리는 MVP를 프로덕션으로 키울 자격을 얻게 된다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.