AI 모델은 놀라울 만큼 똑똑해졌다. 질문에 답하고, 글을 쓰고, 코드를 만들고, 표를 읽고, 이미지를 이해한다. 몇 년 전만 해도 연구 데모처럼 보이던 일이 이제는 브라우저 한 탭 안에서 자연스럽게 벌어진다. 그래서 많은 팀이 이렇게 생각한다. "이 정도 모델이면 우리 제품에도 바로 넣을 수 있겠는데?"
바로 여기서 첫 번째 착각이 시작된다. 모델이 똑똑하다는 사실과 제품이 믿을 만하다는 사실은 같은 말이 아니다. 모델은 훌륭한 추론과 생성 능력을 보여줄 수 있지만, 제품은 그보다 훨씬 더 많은 것을 요구한다. 사용자의 요청을 안정적으로 받아야 하고, 필요한 정보를 제때 가져와야 하며, 올바른 도구만 사용해야 하고, 실패했을 때는 멈추거나 복구해야 한다. 무엇보다 같은 조건에서 비슷한 품질을 반복적으로 내야 한다.
이 차이를 이해하지 못하면 팀은 자주 같은 함정에 빠진다. 데모에서는 감탄을 자아냈는데 정작 서비스에 붙이자 불안정하다. 어떤 날은 똑똑하고 어떤 날은 엉뚱하다. 테스트 환경에서는 잘 되는데 실제 고객 데이터 앞에서는 흔들린다. 한마디로, 모델은 잘하는데 제품은 불안하다.
이 장에서는 왜 이런 일이 벌어지는지 살펴본다. 핵심은 단순하다. AI 제품의 품질은 모델 하나로 결정되지 않는다. 모델 바깥의 시스템, 즉 실행 환경이 제품의 실제 완성도를 좌우한다.
모델 성능과 제품 품질은 다르다
모델 성능은 보통 정답률, 추론 능력, 언어 이해력, 코드 생성 능력 같은 기준으로 이야기된다. 쉽게 말해 "이 모델이 얼마나 똑똑한가"를 묻는 질문이다. 반면 제품 품질은 전혀 다른 질문을 던진다. "이 기능이 실제 사용자 앞에서 얼마나 안정적으로 작동하는가", "예상 밖의 입력에도 견디는가", "실수했을 때 피해를 통제할 수 있는가" 같은 질문이다.
이 둘의 차이는 자동차 엔진과 운전 경험의 차이에 가깝다. 엔진 출력이 높다고 해서 무조건 좋은 자동차가 되는 것은 아니다. 브레이크는 잘 듣는지, 핸들은 예측 가능하게 움직이는지, 비 오는 날에도 안정적인지, 계기판은 읽기 쉬운지, 사고가 났을 때 안전한지가 함께 중요하다. AI 제품도 마찬가지다. 모델은 강력한 엔진일 수 있지만, 제품은 엔진만으로 완성되지 않는다.
같은 모델을 써도 어떤 서비스는 유용하고 어떤 서비스는 불안한 이유가 여기에 있다. 차이를 만드는 것은 모델의 지능 그 자체보다, 그 지능을 어떻게 감싸고 통제하며 검증하는가다.
제품 관점에서 중요한 것은 다음과 같은 질문들이다.
모델이 어떤 정보에 접근할 수 있는가
어떤 도구를 어떤 순서로 사용할 수 있는가
잘못된 행동을 했을 때 누가, 어떻게 멈출 수 있는가
결과가 맞는지 무엇으로 검증할 것인가
실패 원인을 나중에 추적할 수 있는가
이 질문들은 대부분 모델의 파라미터가 아니라 시스템 설계의 문제다. 즉, 좋은 AI 제품을 만들려면 "모델을 얼마나 잘 골랐는가"보다 "모델이 일하는 환경을 얼마나 잘 설계했는가"가 더 중요해지는 순간이 온다.
데모는 쉬운데 운영은 어려운 이유
많은 AI 프로젝트가 데모 단계에서는 매우 인상적이다. 이유는 간단하다. 데모는 대체로 통제된 환경에서 진행되기 때문이다. 입력이 비교적 깨끗하고, 시나리오가 잘 준비되어 있으며, 실패해도 큰 문제가 없다. 무엇보다 보는 사람들은 모델이 할 수 있는 최선의 순간을 본다.
하지만 운영 환경은 다르다. 사용자는 친절하게 입력하지 않는다. 요구사항은 애매하고, 데이터는 지저분하며, 작업은 길고, 외부 시스템은 자주 흔들린다. 어떤 사용자는 모호한 지시를 내리고, 어떤 사용자는 한 번에 여러 일을 시키며, 어떤 사용자는 시스템의 빈틈을 무심코 혹은 의도적으로 건드린다. 이때부터 모델의 똑똑함만으로는 감당하기 어려운 문제가 나타난다.
예를 들어 보자. "지난 분기 매출을 요약해서 팀장에게 메일로 보내줘"라는 요청은 데모에서는 매우 간단해 보인다. 하지만 실제 서비스에서는 질문이 꼬리를 문다. 지난 분기의 기준은 회계 분기인가, 달력 분기인가. 어느 데이터베이스를 읽어야 하는가. 초안만 만들 것인가, 실제 발송까지 할 것인가. 받는 사람은 누구인가. 숫자가 맞는지 누가 검증하는가. 메일 내용이 민감 정보에 해당하면 어떻게 할 것인가.
모델은 이 중 일부를 잘 추론할 수 있다. 그러나 제품은 추론에만 기대면 안 된다. 시스템이 애매함을 줄여야 하고, 민감한 행동에는 권한을 걸어야 하며, 결과를 검산할 수 있어야 한다. 데모는 "될 수도 있음"을 보여주지만, 운영은 "계속 되게 만들기"를 요구한다.
운영이 어려운 이유는 결국 변동성과 책임 때문이다. 데모에서는 한 번의 성공이 박수를 받지만, 제품에서는 백 번 중 아흔아홉 번의 안정성이 필요하다. 그리고 남은 한 번의 실패가 금전 손실, 보안 사고, 고객 이탈로 이어질 수 있다.
AI 에이전트 제품에서 자주 발생하는 실패
AI 에이전트가 제품에 들어가면 문제는 단순한 오답에서 끝나지 않는다. 에이전트는 읽고, 판단하고, 도구를 쓰고, 행동할 수 있기 때문이다. 즉, 말실수보다 행동 실수가 더 중요해진다.
실무에서 자주 만나는 실패는 몇 가지 유형으로 반복된다.
필요한 도구가 있는데도 잘못된 도구를 선택한다.
맞는 도구를 골랐지만 잘못된 인자를 넣어 실행한다.
작업 도중 목표를 잊고 옆길로 샌다.
충분한 정보가 없는데도 자신 있게 결론을 낸다.
오래된 정보와 최신 정보를 섞어 잘못 판단한다.
읽기만 해야 할 작업에서 쓰기나 삭제 같은 위험한 행동까지 시도한다.
실패를 알아차리지 못해 같은 행동을 반복한다.
이 목록은 겉으로 보면 제각각처럼 보이지만, 조금만 들여다보면 공통점이 있다. 대부분은 "모델이 똑똑하지 않아서"라기보다 "시스템이 행동을 잘 조직하지 못해서" 생긴다.
예를 들어 도구 선택 오류는 단순히 모델의 추론 부족 때문만은 아니다. 도구 설명이 모호했을 수도 있고, 비슷한 기능의 도구가 너무 많았을 수도 있으며, 입력 형식이 일관되지 않았을 수도 있다. 무한 반복 역시 모델이 고집이 세서가 아니라, 종료 조건이 없거나 실패 시 다른 경로로 빠져나가는 장치가 없기 때문일 수 있다.
즉, 에이전트 실패는 대개 구조적인 실패다. 모델의 순간적인 실수처럼 보이지만, 실제로는 설계된 환경의 빈틈이 드러난 결과인 경우가 많다.
환각보다 더 무서운 것은 실행 실패다
생성형 AI를 이야기할 때 가장 자주 나오는 단어는 환각이다. 없는 사실을 그럴듯하게 말하는 문제다. 물론 중요하다. 하지만 에이전트 시대에는 환각 못지않게, 때로는 그보다 더 위험한 것이 실행 실패다.
채팅만 하는 시스템에서의 실수는 잘못된 설명으로 끝날 때가 많다. 반면 에이전트는 외부 세계에 영향을 미칠 수 있다. 파일을 수정하고, 메일을 보내고, 일정을 잡고, 데이터베이스에 쓰고, 결제를 요청할 수 있다. 이때 문제는 "틀린 말을 했다"가 아니라 "틀린 행동을 했다"로 바뀐다.
예를 들어 어떤 에이전트가 고객 문의를 분류하고 환불 여부를 처리한다고 해보자. 이 에이전트가 환불 정책을 잘못 이해한 채 답변만 잘못 쓴다면 아직 수습할 여지가 있다. 하지만 실제로 환불을 승인하거나 주문 상태를 변경해버리면 손실은 곧바로 현실이 된다. 다시 말해, 행동 가능한 AI는 정확도뿐 아니라 통제 가능성이 핵심이다.
그래서 에이전트 제품에서는 질문이 바뀌어야 한다. "정답을 잘 말하나?"만 물어서는 부족하다. 대신 "무엇을 실행할 수 있나?", "실행 전에 무엇을 확인하나?", "실패하면 어떻게 멈추나?"를 함께 물어야 한다.
이 관점 전환이 중요하다. AI를 똑똑한 대화 상대로만 보면 프롬프트를 고치는 데 집중하게 된다. 하지만 AI를 행동하는 시스템으로 보면 권한, 검증, 로그, 승인, 롤백 같은 문제들이 한꺼번에 보이기 시작한다.
모델 바깥의 시스템이 품질을 만든다
좋은 제품은 모델 하나 위에 세워지지 않는다. 그 주위를 둘러싼 여러 층이 함께 작동해야 한다. 입력을 정리하는 층이 있고, 필요한 정보를 모으는 층이 있으며, 도구 사용을 중개하는 층이 있고, 결과를 검증하는 층이 있다. 그리고 문제를 기록하고 추적하는 층이 있다.
이 층들이 제대로 설계되지 않으면, 아무리 좋은 모델도 흔들린다. 반대로 이 층들이 잘 설계되면, 아주 최상위 모델이 아니어도 실용적인 제품을 만들 수 있다. 사용자는 종종 모델의 이름보다 경험의 안정성을 더 먼저 기억한다. 요청을 이해하는 속도, 엉뚱한 행동을 하지 않는 신뢰감, 문제가 생겼을 때의 복구 경험이 제품의 인상을 결정한다.
모델 바깥의 시스템을 조금 더 구체적으로 보면 다음과 같은 요소들이 있다.
어떤 정보를 입력으로 줄지 결정하는 컨텍스트 구성
어떤 도구를 연결하고 어떻게 호출할지 정하는 인터페이스 설계
어디까지 허용하고 어디서 멈출지 정하는 권한과 승인 구조
중간 상태를 어떻게 기억하고 잊을지 정하는 메모리 설계
작업 결과를 어떻게 확인할지 정하는 검증 절차
실패 원인을 어떻게 추적할지 정하는 로그와 관측 체계
이 요소들은 각자 따로 존재하는 것처럼 보여도 실제로는 긴밀하게 연결된다. 예를 들어 권한 설계가 느슨하면 검증 부담이 커지고, 컨텍스트 설계가 엉성하면 도구 선택 오류가 늘어나며, 로그가 없으면 개선 자체가 어려워진다. 결국 제품 품질은 개별 기술의 합이 아니라, 전체 흐름의 설계 수준에서 결정된다.
왜 사람은 어설픈 결과를 참지 않는데, 데모는 통과될까
흥미로운 점이 하나 있다. 사람들은 AI 데모에서는 꽤 너그럽다. "오, 이런 것도 하네?" 하고 감탄한다. 그런데 막상 제품으로 쓰기 시작하면 작은 실수도 매우 거슬려한다. 왜 그럴까.
이유는 기대치가 달라지기 때문이다. 데모를 볼 때 사람은 가능성을 본다. 제품을 쓸 때 사람은 책임을 본다. 데모에서는 한 번 멋지게 성공하면 충분하지만, 제품에서는 언제나 비슷한 수준으로 작동해야 한다. 사용자는 자신이 직접 확인하고 감독해야 하는 시스템을 좋은 제품으로 느끼지 않는다.
즉, 제품화란 단지 기능을 추가하는 일이 아니다. 사용자가 매번 불안을 감수하지 않아도 되는 상태를 만드는 일이다. AI가 똑똑해 보여도 사용자가 늘 "이거 다시 확인해야 하나?"라고 느끼면 그 제품은 자동화가 아니라 검수 보조 도구에 머문다.
바로 이 지점에서 하네스 설계의 필요가 생긴다. 사용자의 불안을 줄이려면 모델에게 더 긴 프롬프트를 주는 것만으로는 부족하다. 애초에 실수하기 어려운 환경, 실수해도 피해가 제한되는 구조, 실수를 빨리 알아차릴 수 있는 관측 체계가 필요하다.
에이전트 제품화의 문제를 시스템 문제로 다시 보기
많은 팀이 에이전트 개발 초기에 문제를 모델 문제로만 해석한다. 응답이 이상하면 프롬프트를 수정하고, 성능이 아쉬우면 더 큰 모델을 찾고, 컨텍스트가 부족하면 문서를 더 넣는다. 물론 이런 조정은 필요하다. 하지만 일정 시점이 지나면 개선 폭이 작아진다. 그때부터는 질문을 바꿔야 한다.
"모델이 왜 이랬지?"보다 먼저 "이 시스템은 왜 이런 행동을 허용했지?"를 물어야 한다.
예를 들어 에이전트가 잘못된 파일을 수정했다면, 단순히 모델이 실수했다고 끝낼 일이 아니다. 왜 수정 가능한 파일 범위가 그렇게 넓었는지, 변경 전에 미리보기 단계가 왜 없었는지, 테스트를 먼저 돌리게 하는 절차가 왜 없었는지, 사람 승인 지점이 왜 빠졌는지를 함께 봐야 한다.
이렇게 보면 에이전트 제품화의 핵심 문제는 지능 부족이 아니라 운영 구조 부족인 경우가 많다. 실제 현장에서 막히는 지점도 대부분 이쪽이다.
어디까지 자동화하고 어디서 사람을 넣을 것인가
어떤 작업은 즉시 실행하고 어떤 작업은 승인받게 할 것인가
실패를 감추지 않고 드러내려면 무엇을 기록해야 하는가
결과 품질을 사후가 아니라 중간 단계에서 어떻게 확인할 것인가
시스템이 복잡해질수록 비용과 속도를 어떻게 통제할 것인가
이 질문들은 모두 제품 설계의 언어다. 그리고 이 언어를 이해해야 비로소 AI를 기능이 아니라 시스템으로 다룰 수 있다.
좋은 AI 제품은 똑똑함보다 예측 가능성이 있다
사용자는 대개 "가끔 천재 같은 서비스"보다 "대체로 믿을 만한 서비스"를 더 좋아한다. 이유는 간단하다. 제품은 놀라움보다 신뢰를 필요로 하기 때문이다.
예측 가능성은 심심해 보이지만 제품에서는 강력한 장점이다. 어떤 요청에는 어떤 범위 안에서 동작하는지, 어디까지 자동으로 처리하고 어디서 멈추는지, 무슨 근거로 답했는지, 문제가 생기면 어떻게 되돌릴 수 있는지가 분명할수록 사용자는 안심한다.
이런 특성은 모델의 재능만으로 생기지 않는다. 잘 정의된 입력, 정돈된 도구, 제한된 권한, 분명한 종료 조건, 충분한 검증, 촘촘한 로그가 함께 만들어낸다. 말하자면 좋은 AI 제품은 똑똑한 모델 위에 세운 견고한 작업장이다.
작업장이 엉망이면 숙련된 사람도 실수한다. 도구가 아무 데나 놓여 있고, 위험한 기계에 잠금장치가 없고, 작업 순서가 정리되어 있지 않고, 검사 절차가 빠져 있다면 사고는 결국 일어난다. AI 에이전트도 같다. 모델이 아무리 유능해도 일하는 환경이 거칠면 결과는 불안정해진다.
이 책이 풀려는 문제
이 책은 "어떻게 하면 모델이 더 그럴듯하게 대답하게 만들까"만을 다루지 않는다. 그보다 한 단계 바깥으로 나가, "어떻게 하면 모델이 실제 환경에서 안전하고 반복 가능하며 검증 가능한 방식으로 일하게 만들까"를 다룬다.
첫 장에서 꼭 붙잡아야 할 문장은 이것이다.
좋은 모델이 곧 좋은 제품은 아니다.
좋은 제품은 좋은 모델 위에, 좋은 실행 환경이 더해졌을 때 비로소 만들어진다. 모델의 능력은 출발점일 뿐이고, 제품의 완성도는 그 능력을 어떤 구조 안에 넣느냐에서 갈린다.
그래서 에이전트 제품을 만들려는 사람은 모델 성능표만 보아서는 안 된다. 모델이 어떤 도구를 쓸지, 어떤 정보만 보게 할지, 어떤 행동을 금지할지, 어떤 실패를 감지할지, 어떤 방식으로 검증할지를 함께 설계해야 한다. 이 설계가 바로 이후 장들에서 본격적으로 다룰 주제다.
다음 장에서는 이 지점을 좀 더 명확히 구분해볼 것이다. 프롬프트 엔지니어링이 모델에게 어떻게 지시하는 기술이라면, 컨텍스트 엔지니어링은 무엇을 보여주는 기술이다. 그리고 하네스 설계는 그 둘을 감싸는 더 큰 질문, 즉 모델이 어떤 환경에서 어떤 절차로 일하게 할 것인가를 다룬다.
AI가 똑똑한데도 서비스가 불안한 이유를 이해했다면, 이제 다음 질문으로 넘어갈 준비가 된 것이다. 문제는 모델 하나가 아니었다. 문제는 작업장이었다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.