AI 에이전트 도입 판단 기준 다섯 가지와 벡터DB·MCP를 잇는 내부 동작 구조 정리

핵심 메시지

• 예전에는 여행 예약 같은 반복 업무를 스크립트로 짰지만, 요구사항이 조금만 바뀌어도 사람이 스크립트를 직접 고쳐야 했다. 대규모 언어모델이 등장하면서 상황에 맞게 API를 호출하는 쪽으로 옮겨갔다.
• 에이전트를 만들지 판단하는 다섯 가지 기준은 문제가 자주 일어나는가, 변동과 판단이 적은가, 위험이 낮은가, 사람이 개입할 일이 적은가, 투입 노력이 적은가이다.
• 내부 구조는 사용자 질의에 벡터 데이터베이스로 맥락을 덧붙이고, 시스템 프롬프트로 역할과 단계별 사고 과정을 예시로 주고, 언어모델이 제안한 행동을 에이전트가 대신 수행하는 흐름이다.
• 언어모델 자체는 행동을 실행하지 못하고 제안만 하지만, MCP(모델 컨텍스트 프로토콜)가 등장하면서 에이전트가 MCP 클라이언트가 되어 MCP 서버에 실제 예약이나 결제를 요청할 수 있게 됐다.
• 강연자는 지금의 에이전트가 사실상 크론잡이나 워크플로 파일에 가깝고 스스로 배우거나 추론하지 못해서, 에이전트라는 이름이 아직은 마케팅 문구에 가깝다고 본다.

쉽게 이해하기

뭄바이에서 방갈로르로 가는 일정을 맡기면 항공권과 호텔 예약을 대신 처리해 주는 여행 에이전트를 떠올려 보자. 예전에도 이 흐름을 스크립트로 짤 수는 있었지만, 요구사항이 조금만 바뀌어도 사람이 스크립트를 손봐야 하는 것이 문제였다. 대규모 언어모델이 들어오면서 에이전트는 상황과 요구에 맞춰 필요한 API를 골라 호출할 수 있을 만큼 똑똑해졌다.

기업 입장에서 효과가 나는 지점은 고객 응대와 영업처럼 여러 단계를 순서대로 조율해야 하는 업무다. 항공권 환불을 요청받으면 세부 정보를 묻고 적절한 부서로 넘긴 뒤 승인이나 거절로 이어지는데, 이 과정에 약간의 판단만 붙어도 고객 만족도가 눈에 띄게 올라간다는 것이다.

그래서 엔지니어나 제품 담당자가 던져야 할 질문은 '언제 에이전트를 만들 것인가'다. 강연자는 다섯 가지를 든다. 문제가 자주 반복되면 절약한 시간이 곧바로 이익으로 바뀌므로 투자 가치가 있다. 고객마다 맞춤 로드맵을 짜는 일처럼 변동과 판단이 큰 업무는 보조는 몰라도 전담은 어렵다. 위험이 큰 곳도 피해야 하는데, 환불 처리를 맡기면 모델이 너무 관대해 모두 승인해도 손실이고 곧바로 거절해도 위험하다. 사람이 끼어들 일은 최소여야 하고, 마지막으로 투입 노력이 적어야 한다. 에이전트가 사람을 완전히 대체한다고 보는 시각이 많지만 현실의 절차는 복잡해서 결국 사람에게 넘겨야 할 순간이 온다는 것이다.

동작 구조는 이렇다. 에이전트가 언어모델과 직접 대화하고, 질의를 받으면 먼저 벡터 데이터베이스를 찾아가 맥락을 보강한다. 사용자가 세 시간째 사이트에 머물렀는지, 지금까지 몇 번 구매했는지, 마지막 구매가 무엇이고 할인을 자주 찾는지 같은 정보가 질의와 함께 실려 간다. 여기에 '당신은 예약을 관리하는 여행 에이전트다' 같은 역할 설명과 항공권·비용·숙소·일정 등록으로 이어지는 단계별 사고 과정을 예시로 넣어 주면, 모델이 그 예시를 따라 현재 상황을 훨씬 잘 재구성한다.

모델이 취해야 할 행동을 답으로 내놓으면 실제 실행은 에이전트의 몫이다. 강연자는 항공사가 예약용 MCP 서버를 열어 두면 에이전트가 그 서버에 항공권 예약과 결제까지 요청할 수 있다고 설명한다. 사용자에게는 매끄러운 대행처럼 보이지만 실체는 공개된 API를 찾아 호출하는 것이다. 마지막으로 결과에 대한 사람의 반응이 좋은 행동을 강화하고 나쁜 행동을 줄이는 피드백으로 쓰인다. 다만 이 학습은 거칠어서, 가격이 비싸다는 불만을 받아도 어느 지점이 문제인지 짚지 못한 채 지난번 절차 전체를 피하고 다른 방식을 시도하는 식으로 작동한다.

주요 인사이트

• 도입 기준 다섯 가지는 결국 '자주 일어나고, 변동이 적고, 위험이 낮은' 업무로 수렴한다. 회사의 손익이 걸린 핵심 판단은 여전히 사람의 몫이고 모델은 보조에 머물러야 한다는 선 긋기다.
• 프롬프트에 단계별 사고 과정을 예시로 넣어 주는 것만으로 응답 품질이 크게 올라간다는 대목은, 에이전트 성능이 모델 교체보다 맥락 설계에서 갈릴 수 있음을 시사한다.
• MCP는 언어모델을 '제안'에서 '실행'으로 옮기는 연결 고리다. 사용자에게는 하나의 비서처럼 보이지만 실제로는 외부에 공개된 API를 클라이언트가 찾아 호출하는 구조라는 점을 기억할 필요가 있다.
• 사람의 피드백이 지나치게 뭉뚱그려져 있다는 지적이 날카롭다. 뜨거운 팬에 데면 그 팬만 피하면 되는데 그 자리까지 걸어간 과정 전체를 피해 버리는 식이어서, 실제로 나아지는 에이전트가 드물다는 것이다.
• 강연자는 지금의 에이전트를 '반응은 하지만 사고하지 못하는 파충류'에 빗댄다. 예약 후 항공권을 내려받아 주는 정도의 상식적 추론조차 시키지 않으면 하지 못한다는 점이 남은 과제다.

자주 묻는 질문

관련 AI 소식