1부 3장. 좋은 에이전트와 나쁜 에이전트

지난 장에서 우리는 에이전트의 최소 단위를 보았다. 모델, 상태, 도구, 실행 루프. 겉으로 보면 여기서부터는 조립의 문제처럼 느껴진다. 네 가지 부품만 잘 붙이면 그럴듯한 에이전트가 나올 것 같기 때문이다.

하지만 실제로는 여기서부터가 진짜 시작이다. 같은 모델을 쓰고, 같은 도구를 연결하고, 비슷한 루프를 돌려도 어떤 시스템은 믿고 맡길 수 있고 어떤 시스템은 두 번 다시 쓰고 싶지 않다. 차이는 화려함이 아니라 품질에서 난다. 더 정확히 말하면, 얼마나 똑똑하게 보이느냐보다 얼마나 예측 가능하게 행동하느냐에서 갈린다.

좋은 에이전트는 종종 조금 심심해 보인다. 괜히 과장하지 않고, 모르면 묻고, 해야 할 일만 하고, 끝나면 멈춘다. 반대로 나쁜 에이전트는 처음엔 인상적이다. 질문 하나에 이것저것 많이 해 주고, 여러 도구를 부지런히 부르며, 스스로 열심히 일하는 듯한 분위기를 낸다. 그런데 자세히 보면 문제가 드러난다. 필요 없는 행동을 반복하고, 도구를 아무 때나 쓰고, 애초의 목표에서 조금씩 벗어난다.

이 장에서는 바로 그 차이를 다룬다. 잘 되는 데모와 실제로 믿고 쓰는 시스템은 무엇이 다른가. 신뢰할 수 있는 에이전트는 어떤 성질을 가져야 하는가. 그리고 루프 폭주, 도구 오용, 목표 표류 같은 대표 실패 패턴은 왜 생기는가.

좋은 에이전트는 똑똑한 시스템이 아니라 통제되는 시스템이다

많은 사람이 좋은 에이전트를 떠올릴 때 먼저 추론 능력을 생각한다. 물론 중요하다. 하지만 실전에서 더 중요한 것은 따로 있다. 행동의 경계가 분명한가, 상태를 일관되게 유지하는가, 불확실할 때 무리하지 않는가 같은 점들이다.

예를 들어 일정 조율 에이전트를 만든다고 해 보자. 사용자가 "다음 주 중 가능한 시간 찾아서 미팅 잡아 줘"라고 말했을 때, 좋은 에이전트는 먼저 필요한 조건을 확인한다. 누구와의 미팅인지, 시간대는 무엇인지, 캘린더 접근 권한은 있는지, 바로 예약해도 되는지 따져 본다. 그리고 필요한 경우엔 짧게 되묻는다. 그런 뒤 일정 조회를 하고, 가능한 시간을 비교하고, 확인된 범위 안에서만 행동한다.

나쁜 에이전트는 다르게 움직인다. 상대방이 누구인지도 모른 채 여러 캘린더를 뒤지고, 애매한 시간대를 임의로 해석하고, 심지어 사용자가 아직 승인하지 않았는데 예약까지 시도할 수 있다. 겉으로는 적극적이지만 실제로는 위험하다.

즉, 좋은 에이전트는 많이 행동하는 시스템이 아니다. 맞는 행동을, 맞는 순서로, 맞는 범위 안에서 하는 시스템이다.

신뢰할 수 있는 에이전트의 공통점

좋은 에이전트에는 몇 가지 공통된 특징이 있다.

• 목표가 분명하다.

• 상태가 또렷하다.

• 도구 사용에 이유가 있다.

• 멈춰야 할 때 멈춘다.

먼저 목표가 분명해야 한다. 에이전트는 사용자의 요청을 듣고 "무엇을 끝내야 하는가"를 정확히 붙잡아야 한다. 보고서 초안을 쓰는 일인지, 사실을 확인하는 일인지, 실제로 외부 시스템을 변경하는 일인지가 흐려지면 이후 행동도 흐려진다.

상태가 또렷하다는 것은 지금까지 무엇을 했고 무엇이 남았는지가 분명하다는 뜻이다. 좋은 에이전트는 스스로의 작업 메모가 깔끔하다. 이미 조회한 데이터, 아직 받지 못한 승인, 실패한 도구 호출 횟수 같은 것이 정리되어 있다. 그래서 같은 일을 다시 하지 않고, 이미 끝난 일을 또 시도하지도 않는다.

도구 사용에 이유가 있다는 것도 중요하다. 좋은 에이전트는 도구를 장식처럼 쓰지 않는다. 검색이 정말 필요할 때만 검색하고, 파일을 읽어야 할 때만 파일을 읽는다. 마치 숙련된 기술자가 공구함을 열 때처럼, 지금 필요한 것 하나를 집어 든다.

마지막으로 멈춰야 할 때 멈춘다. 이것이 의외로 가장 어려운 능력이다. 많은 실패가 "더 해 보자"에서 시작된다. 좋은 에이전트는 충분한 정보가 없으면 사용자에게 되묻고, 권한이 부족하면 중단하고, 목표가 완료되면 종료한다. 끝낼 줄 아는 시스템이 결국 신뢰를 얻는다.

나쁜 에이전트는 왜 처음엔 좋아 보일까

실패하는 에이전트의 상당수는 첫 시연에서는 인상적이다. 이유는 간단하다. 움직임이 많기 때문이다. 검색도 하고, 요약도 하고, 파일도 뒤지고, 뭔가 복잡한 판단을 하는 것처럼 보인다. 보는 사람 입장에서는 "와, 스스로 알아서 다 하네"라는 느낌을 받기 쉽다.

하지만 제품 환경은 시연과 다르다. 실제 사용자는 애매한 요청을 하고, 정보는 자주 비어 있으며, 도구는 실패하고, 외부 시스템은 느리거나 잘못된 값을 줄 때도 있다. 여기서 좋은 시스템과 나쁜 시스템의 차이가 드러난다.

데모에서는 한 번만 잘하면 된다. 제품에서는 매번 비슷하게 잘해야 한다. 데모에서는 멋진 한 장면이 중요하다. 제품에서는 예외 상황에서 덜 망가지는 것이 중요하다. 데모에서는 약간의 과감함이 박수받을 수 있다. 제품에서는 그 과감함이 사고로 이어질 수 있다.

그래서 믿고 쓰는 에이전트는 대개 데모 영상에서 가장 화려한 주인공이 아니다. 대신 실제 환경에서 일관되게 덜 틀리고, 덜 헤매고, 덜 위험하다.

실패 패턴 1: 루프 폭주

에이전트의 대표적인 실패 중 하나는 루프 폭주다. 말 그대로 실행 루프가 멈춰야 할 타이밍을 놓치고 계속 도는 상태다. 한 번쯤은 성실해 보이지만, 조금만 지나면 같은 복도를 계속 걷는 사람처럼 보인다.

예를 들어 문서 조사 에이전트가 있다고 해 보자. 사용자는 "이 계약서에서 자동 갱신 조항만 찾아 요약해 줘"라고 요청했다. 좋은 에이전트라면 계약서를 읽고, 해당 조항을 찾고, 필요하면 한두 번 확인한 뒤 답을 준다. 그런데 나쁜 에이전트는 이미 충분한 정보를 얻었는데도 계속 검색한다. 조항을 찾았는데도 유사 계약서를 더 뒤지고, 이미 읽은 문서를 다시 읽고, 비슷한 요약을 반복해서 만든다.

루프 폭주는 여러 이유로 생긴다. 가장 흔한 이유는 종료 조건이 약하기 때문이다. 에이전트가 언제 일을 끝난 것으로 볼지 정의되어 있지 않으면, 시스템은 "혹시 더 나은 답이 있을지도 몰라"라는 분위기 속에서 계속 움직인다. 두 번째 이유는 상태가 부정확하기 때문이다. 이미 필요한 정보가 모였다는 사실이 상태에 반영되지 않으면, 에이전트는 아직 일이 남은 줄 안다. 세 번째 이유는 모델에게 너무 큰 자유를 줬기 때문이다. "최대한 잘해 봐" 같은 지시는 친절해 보이지만, 루프 입장에서는 끝없는 출장 명령과 비슷하다.

루프 폭주의 문제는 단순히 느리다는 데 있지 않다. 비용이 커지고, 도구 호출 실패 가능성이 늘고, 답의 일관성이 떨어진다. 무엇보다 사용자는 시스템이 자기 목적을 잊고 혼자 일에 취한 듯한 느낌을 받는다. 에이전트가 유능해 보이는 순간은 짧고, 피로감은 오래 남는다.

좋은 에이전트는 이 문제를 피하기 위해 늘 질문한다. 지금 목표가 충족되었는가. 새로 얻은 정보가 실제로 필요한가. 같은 행동을 반복하고 있지는 않은가. 이 세 질문이 루프를 엔진으로 만들지, 기관차 탈선으로 만들지 가른다.

실패 패턴 2: 도구 오용

도구는 에이전트의 손과 발이지만, 손과 발이 많다고 좋은 것은 아니다. 오히려 손이 너무 많으면 실수도 많아진다. 도구 오용은 대체로 두 가지 형태로 나타난다. 쓸 필요가 없는데 쓰는 경우와 써도 되는 범위를 넘어서 쓰는 경우다.

첫 번째는 의외로 흔하다. 예를 들어 사용자가 "이 문장을 더 부드럽게 고쳐 줘"라고 했는데, 에이전트가 굳이 웹 검색을 하거나 외부 문서를 조회할 이유는 없다. 그런데 도구가 연결되어 있으면 일부 시스템은 마치 장난감을 자랑하듯 먼저 써 보고 싶어 한다. 그 결과 단순한 요청이 괜히 느려지고, 외부 정보가 불필요하게 끼어들며, 심지어 원래 요청보다 산만한 답이 나오기도 한다.

두 번째는 더 위험하다. 예를 들어 결제 취소 도구, 메일 발송 도구, 데이터 수정 도구처럼 실제 세계를 바꾸는 도구를 생각해 보자. 좋은 에이전트는 이런 도구를 사용할 때 조건을 엄격히 확인한다. 사용자가 정말 원했는지, 필요한 식별자가 있는지, 승인이 필요한 단계는 지났는지, 되돌릴 수 없는 작업은 아닌지 따진다. 반면 나쁜 에이전트는 대충 맥락을 짐작해 행동으로 넘어간다. 그럴듯한 자신감이 가장 위험한 순간이다.

도구 오용은 보통 모델이 나빠서라기보다 도구의 인터페이스와 정책이 흐려서 생긴다. "send_email"이라는 도구 하나만 던져 주고 알아서 쓰라고 하면, 에이전트는 너무 많은 경우를 혼자 판단해야 한다. 누구에게 보낼 수 있는지, 초안만 만들 수 있는지, 실제 발송은 승인 후인지 같은 제약이 도구 설계에 녹아 있어야 한다.

좋은 에이전트는 도구를 능력의 상징으로 다루지 않는다. 책임이 따르는 행동 수단으로 다룬다. 이 차이가 매우 크다.

실패 패턴 3: 목표 표류

목표 표류는 에이전트가 처음 받은 일을 조금씩 잊고 다른 방향으로 흘러가는 현상이다. 처음엔 아주 미묘하다. 그런데 어느 순간 사용자는 깨닫게 된다. "내가 부탁한 건 이게 아닌데?"

예를 들어 사용자가 "지난주 고객 불만의 주요 원인 세 가지만 정리해 줘"라고 요청했다고 해 보자. 좋은 에이전트는 고객 불만 데이터를 보고, 분류하고, 상위 원인을 세 가지로 좁혀서 간결하게 정리한다. 그런데 목표 표류가 시작되면 에이전트는 점점 다른 일을 한다. 먼저 고객 만족도 일반론을 설명하고, 업계 평균과 비교하고, 장기 개선 전략까지 제안하며, 급기야 조직 문화 이야기를 꺼낸다. 다 틀린 말은 아니지만, 요청한 핵심과는 멀어진다.

왜 이런 일이 생길까. 한 가지 이유는 모델이 문맥 속에서 가장 그럴듯한 방향으로 확장하려는 성질을 갖기 때문이다. 사용자가 짧게 요청하면, 시스템은 종종 "더 도움이 되는" 방향으로 내용을 넓히고 싶어 한다. 또 다른 이유는 상태에 목표가 충분히 선명하게 적혀 있지 않아서다. 작업의 성공 조건이 "주요 원인 세 가지 정리"인지, "관련 인사이트를 최대한 많이 제공"인지 모호하면 에이전트는 자꾸 곁길로 간다.

목표 표류의 무서운 점은 결과물이 종종 꽤 그럴듯하다는 데 있다. 그래서 리뷰하지 않으면 놓치기 쉽다. 사용자는 얼핏 만족할 수도 있지만, 반복해서 쓰다 보면 피로가 쌓인다. 내가 시킨 일보다 시스템이 하고 싶은 일을 더 많이 하기 때문이다.

좋은 에이전트는 친절함과 과잉을 구분한다. 친절함은 목표를 더 잘 완수하는 쪽으로 작동해야 한다. 목표를 밀어내고 자기 확장을 시작하는 순간, 그 친절함은 방해가 된다.

좋은 에이전트는 불확실성을 숨기지 않는다

신뢰의 핵심은 정답률만이 아니다. 모를 때 어떤 태도를 보이느냐도 중요하다. 사람도 그렇다. 잘 모르는 분야를 아는 척하는 동료보다, 어디까지는 알고 어디부터는 확인이 필요하다고 말하는 동료가 더 믿음직하다.

에이전트도 마찬가지다. 좋은 에이전트는 불확실성을 처리하는 방식이 건강하다. 필요한 정보가 없으면 되묻고, 도구 결과가 충돌하면 그 사실을 말하고, 확신이 낮으면 추정임을 분명히 한다. 이 태도는 겸손처럼 보이지만, 실은 설계의 성숙함에 가깝다.

나쁜 에이전트는 빈칸을 견디지 못한다. 이름이 없으면 대충 유추하고, 날짜가 애매하면 적당히 정하고, 검색 결과가 부족해도 단정적으로 말한다. 문장은 매끄럽지만 시스템으로서는 위험하다. 사용자는 처음엔 유능함으로 착각할 수 있으나, 한 번 큰 실수를 겪으면 신뢰는 빠르게 무너진다.

좋은 에이전트가 사용자에게 주는 가장 큰 안심은 이것이다. 모를 때도 이상하게 행동하지 않는다.

실제로 믿고 쓰는 시스템은 왜 덜 화려한가

실전 시스템은 자주 보수적으로 설계된다. 승인 단계를 둔다. 최대 반복 횟수를 제한한다. 쓰기 도구보다 읽기 도구를 먼저 열어 준다. 애매한 요청에는 자율성을 줄이고, 명확한 요청에만 넓은 행동 권한을 준다.

이런 구조는 데모에서는 답답해 보일 수 있다. "왜 바로 안 하지?"라는 생각이 들 수 있다. 하지만 제품 환경에서는 바로 그 보수성이 품질이 된다. 자동차에 브레이크가 있다고 해서 덜 진보한 것이 아닌 것처럼, 에이전트도 멈춤 장치가 있을수록 더 멀리 갈 수 있다.

좋은 에이전트는 자율성을 과시하지 않는다. 자율성을 관리한다. 이 차이는 작아 보여도 시스템의 운명을 바꾼다.

좋은 에이전트를 만드는 설계 감각

좋은 에이전트를 만들고 싶다면 모델의 성능표보다 먼저 행동의 설계도를 봐야 한다. 특히 다음 감각이 중요하다.

첫째, 목표를 한 문장으로 고정할 수 있어야 한다. 에이전트가 지금 무엇을 끝내야 하는지 흐려지면 이후의 모든 판단이 흐려진다.

둘째, 상태는 판단에 필요한 만큼만 선명해야 한다. 너무 적으면 맥락을 잃고, 너무 많으면 중요한 신호가 묻힌다. 에이전트가 길을 잃는 이유는 종종 기억이 부족해서가 아니라, 기억이 탁해서다.

셋째, 도구는 가능한 한 좁고 분명해야 한다. "무엇이든 할 수 있는 브라우저"보다 "주문 상태 조회", "초안 메일 생성", "승인 요청 전송" 같은 구체적인 도구가 더 안전하고 예측 가능하다.

넷째, 루프에는 항상 종료 조건이 있어야 한다. 목표 달성, 추가 정보 필요, 권한 부족, 반복 한도 초과 같은 조건이 없으면 에이전트는 열심히 일하는 척하며 맴돌기 쉽다.

다섯째, 실패를 정상 경로로 다뤄야 한다. 도구는 실패한다. 응답은 비어 있을 수 있다. 외부 시스템은 느릴 수 있다. 좋은 에이전트는 이런 상황을 예외가 아니라 일상으로 가정하고 움직인다.

이 감각들은 화려한 비법이 아니다. 그러나 실전에서는 이런 평범한 원칙이 결국 가장 큰 차이를 만든다.

데모와 제품의 차이는 신뢰의 밀도다

이쯤에서 이번 장의 핵심을 한 문장으로 정리할 수 있다. 좋은 에이전트와 나쁜 에이전트의 차이는, 똑똑함의 크기보다 신뢰의 밀도에 있다.

잘 되는 데모는 한 번의 성공 장면을 보여 준다. 믿고 쓰는 시스템은 백 번의 사용 동안 크게 벗어나지 않는다. 데모는 놀라움을 준다. 제품은 안심을 준다. 데모는 "이런 것도 되네"를 증명한다. 제품은 "이 정도는 맡겨도 되겠네"를 쌓아 간다.

신뢰는 거대한 선언으로 생기지 않는다. 작은 행동들이 축적되며 만들어진다. 필요할 때만 도구를 쓰고, 모를 때는 묻고, 같은 실수를 반복하지 않고, 끝나면 멈추는 것. 이런 사소해 보이는 품질이 사용자의 마음에 남는다.

결국 좋은 에이전트는 사람을 놀라게 하는 시스템이 아니라, 사람을 지치게 하지 않는 시스템이다. 사용자는 마술사를 원하는 것이 아니다. 믿고 함께 일할 수 있는 동료를 원한다.

이제 비교할 준비가 되었다

앞선 두 장에서 우리는 에이전트가 무엇인지, 그리고 어떤 부품으로 이루어지는지 보았다. 이번 장에서는 그 부품들이 어떤 품질로 조립되어야 하는지 살펴보았다. 같은 모델, 같은 도구, 같은 루프를 가져도 결과는 완전히 달라질 수 있다. 차이를 만드는 것은 통제, 경계, 상태, 종료 조건, 그리고 불확실성을 다루는 태도다.

이제 다음 질문으로 자연스럽게 넘어갈 수 있다. 그렇다면 에이전트는 언제 정말 필요한가. 어떤 문제는 검색 보강으로 충분하고, 어떤 문제는 고정된 워크플로가 더 낫고, 어떤 문제에서만 비로소 에이전트다운 자율성이 가치가 생기는가.

다음 장에서는 바로 그 경계를 다룬다. RAG, 워크플로, 에이전트는 무엇이 다른가. 이름만 다른 비슷한 시스템처럼 보이지만, 실제로는 풀어야 하는 문제와 설계 철학이 꽤 다르다.