에이전트를 분해해서 보면 덜 신비롭다
지난 장에서 우리는 설계란 자율성의 범위를 정하는 일이라고 봤다. 이제는 그 자율성을 실제로 만드는 부품을 뜯어볼 차례다. 많은 사람이 에이전트를 보면 거대한 마법 상자처럼 느낀다. 하지만 실제로는 꽤 공학적이다. 잘 만든 에이전트는 보통 네 가지가 맞물려 돌아간다. 생각하는 모델, 행동 원칙을 정하는 프롬프트, 바깥세상과 연결되는 도구, 시간을 이어 주는 메모리다.
이 네 부품을 분리해서 보면 중요한 사실이 하나 드러난다. 에이전트의 성능은 모델 점수 하나로 결정되지 않는다. 모델이 좋아도 프롬프트가 흐리면 행동이 흔들리고, 도구가 많아도 정의가 나쁘면 엉뚱한 버튼을 누른다. 메모리가 많아도 정리와 검색이 서툴면, 많이 기억하는 것이 아니라 많이 헷갈리는 상태가 된다.
이 장의 목표는 단순하다. 에이전트를 더 멋져 보이게 만드는 것이 아니라, 어느 부품이 무슨 역할을 맡는지 머릿속에 선명한 배치도를 만드는 것이다. 배치도가 생기면 문제를 만났을 때도 훨씬 빨리 진단할 수 있다. 이건 모델 문제인가, 프롬프트 문제인가, 도구 문제인가, 아니면 메모리 문제인가.
모델: 에이전트의 두뇌이지만, 혼자서는 완전하지 않다
모델은 에이전트의 두뇌다. 보통 텍스트를 중심으로 이해하고 생성하는 LLM이 핵심이 되고, 이미지까지 함께 읽고 해석하는 작업이 필요하면 VLM이 들어온다. 예를 들어 고객이 보낸 영수증 사진, 대시보드 스크린샷, 계약서 스캔본, 앱 화면 캡처를 이해해야 한다면 텍스트만 잘하는 모델로는 한계가 있다. 이때 VLM은 눈 역할을 한다.
하지만 여기서 자주 생기는 오해가 있다. 모델이 똑똑하면 곧 에이전트도 똑똑하리라고 기대하는 것이다. 실제로 모델은 아주 중요한 부품이지만, 혼자서는 완성품이 아니다. 모델 자체는 기본적으로 상태를 오래 붙잡아 두지 못하는, 매 요청마다 새로 시작하는 계산기에 가깝다. 긴 대화 기록을 계속 덧붙여 보내는 방식은 처음에는 쉬워 보이지만, 곧 컨텍스트 길이 한계, 이해 품질 저하, 비용 증가 문제를 만난다.1
쉽게 말해, 모델의 컨텍스트 창은 넓은 책상일 수는 있어도 창고는 아니다. 책상을 아무리 넓혀도 예전에 어디에 뭘 두었는지 자동으로 정리되지는 않는다.
모델을 고를 때는 성능표만 보기보다, 이 에이전트가 실제로 어떤 일을 하는지 먼저 봐야 한다. 특히 다음 네 가지가 중요하다.
텍스트만 다루는가, 아니면 이미지와 문서 화면도 함께 이해해야 하는가
추론 품질이 더 중요한가, 아니면 응답 속도와 비용이 더 중요한가
도구 호출을 안정적으로 잘하는가
긴 입력을 많이 받아야 하는가, 아니면 필요한 정보만 뽑아 쓰는 구조가 더 적합한가
예를 들어 사내 정책 문서를 읽고 답하는 에이전트라면 긴 문맥 처리와 정확한 요약이 중요할 수 있다. 반면 캘린더를 확인하고 회의를 잡는 비서 에이전트라면 아주 깊은 추론보다 도구 호출의 안정성과 응답 속도가 더 중요할 수 있다. 즉, 좋은 모델은 절대적인 1등 모델이 아니라 그 일에 맞는 모델이다.
프롬프트: 시스템 프롬프트는 말투 설정이 아니라 운영 규칙이다
프롬프트라고 하면 많은 사람이 먼저 말투를 떠올린다. 친절하게 말해라, 짧게 답해라, 이모지를 쓰지 마라 같은 것들이다. 물론 이런 것도 필요하다. 하지만 에이전트 설계에서 더 중요한 것은 시스템 프롬프트를 운영 규칙으로 보는 관점이다.
시스템 프롬프트는 에이전트에게 이런 질문에 대한 답을 준다. 너는 누구인가. 무엇을 성공이라고 보는가. 무엇은 하지 말아야 하는가. 모르면 어떻게 할 것인가. 언제 도구를 써야 하는가. 언제 사람에게 넘겨야 하는가.
좋은 시스템 프롬프트는 화려한 문장보다 경계가 분명하다. 예를 들면 이런 식이다. 고객지원 에이전트라면 추정으로 환불을 약속하지 말 것, 계정 관련 민감 작업은 반드시 본인 확인 후 진행할 것, 정책에 없는 것은 확답하지 말고 확인 경로를 제시할 것, 필요한 정보가 부족하면 먼저 질문할 것. 이런 문장들이 에이전트의 행동 습관을 만든다.
도구를 쓰는 에이전트에서는 시스템 프롬프트와 함께 도구 설명 자체도 프롬프트의 일부라고 보는 편이 정확하다. 모델은 도구 이름, 설명, 파라미터 정의를 보고 어떤 도구를 언제 써야 할지 판단한다. 즉, 도구 설명이 애매하면 모델도 애매하게 행동하기 쉽다.2
실무에서는 시스템 프롬프트에 최소한 다음 항목이 들어가면 좋다.
역할과 목표
성공 조건과 종료 조건
금지 행동과 위험 행동
도구 사용 원칙
정보가 부족하거나 불확실할 때의 대응 방식
출력 형식과 톤
여기서 중요한 요령이 하나 있다. 프롬프트를 길게 쓰는 것과 분명하게 쓰는 것은 다르다. 길고 장엄한 프롬프트는 멋있어 보이지만, 실제로는 규칙끼리 충돌하거나 핵심이 흐려질 때가 많다. 좋은 시스템 프롬프트는 소설이 아니라 작업 지침서에 가깝다.
도구: 함수 호출이 생기면, 에이전트는 비로소 손발을 얻는다
모델은 글을 잘 쓰고 판단도 어느 정도 할 수 있다. 그런데 현실 세계의 정보는 계속 바뀌고, 실제 일은 밖에서 일어난다. 오늘 환율, 지금 재고, 사용자의 캘린더 상태, 사내 데이터베이스 값, 파일 시스템의 실제 내용은 모델의 학습 기억만으로는 알 수 없다. 그래서 에이전트에는 도구가 필요하다.
여기서 핵심 개념이 함수 호출, 또는 도구 호출이다. 원리는 생각보다 단순하다. 모델이 직접 API를 두드리는 것이 아니라, 우선 구조화된 형식으로 어떤 도구를 어떤 인자로 호출하고 싶은지를 출력한다. 그러면 애플리케이션이 그 요청을 실제로 실행하고, 그 결과를 다시 모델에게 돌려준다. 모델은 그 결과를 보고 다음 행동을 결정하거나 최종 답을 만든다.2
이 흐름은 작은 연극처럼 이해하면 쉽다. 모델이 "날씨 조회"라고 말하면, 무대 뒤 스태프가 실제 날씨 API를 호출한다. 그리고 그 결과를 다시 모델에게 속삭인다. 모델은 그제야 "내일 파리는 비가 옵니다"라고 말한다. 즉, 에이전트는 생각과 행동이 번갈아 일어나는 루프 위에서 움직인다.2
도구는 종류가 아주 다양하다. 웹 검색, 데이터베이스 조회, 사내 문서 검색, 계산기, 캘린더, 이메일 발송, 파일 읽기와 쓰기, 코드 실행, 결제 시스템 연결까지 모두 도구가 될 수 있다. 하지만 여기서도 많이 주는 것이 능사는 아니다. 도구 설계가 나쁘면 에이전트는 똑똑한 조수가 아니라 버튼 많은 리모컨이 된다.
좋은 도구 설계에는 몇 가지 공통점이 있다.3
도구 하나가 한 가지 책임을 갖는다
이름과 설명만 읽어도 언제 써야 할지 감이 온다
파라미터가 명확하고, 가능하면 엄격하게 제한된다
실패했을 때도 에이전트가 이해할 수 있는 오류를 돌려준다
예를 들어 search_web과 send_email은 책임이 분명하다. 반면 do_task 같은 이름은 거의 도움이 되지 않는다. 도구 설명도 마찬가지다. "웹 검색"이라고만 쓰는 것보다, "최신 정보가 필요한 질문에 사용한다. 최근 뉴스, 실시간 가격, 오늘 일정처럼 학습 데이터 이후에 바뀔 수 있는 정보를 찾을 때 사용한다"라고 쓰는 편이 훨씬 낫다.2
그리고 정말 중요한 한 가지가 더 있다. 권한 설계다. 읽기 도구와 쓰기 도구는 위험도가 완전히 다르다. 문서를 읽는 도구는 실수해도 비교적 안전하지만, 메일 발송, 결제 승인, 파일 삭제, 고객 정보 변경 같은 도구는 한 번의 잘못된 호출이 바로 사고로 이어질 수 있다. 이런 도구에는 사람 승인 단계를 두거나, 기본값을 읽기 전용으로 두는 것이 좋다. 외부 데이터 안에 숨은 악성 지시가 모델을 속여 잘못된 행동을 유도하는 간접 프롬프트 인젝션 같은 위험도 실제로 고려해야 한다.4
좋은 에이전트 설계자는 도구를 많이 붙이는 사람보다, 어떤 도구는 주지 않는 사람에 더 가깝다.
메모리: 많이 저장하는 것보다, 필요한 순간에 제대로 꺼내는 것이 중요하다
에이전트 메모리는 많은 팀이 가장 늦게 진지하게 보게 되는 부품이다. 처음에는 대화 기록만 잘 붙이면 될 것처럼 보이기 때문이다. 하지만 조금만 길게 운영해 보면 곧 알게 된다. 메모리는 저장보다 선별, 요약, 검색, 갱신, 삭제가 더 중요하다.1
메모리는 크게 세 층으로 이해하면 편하다.5
첫째는 작업 메모리다. 지금 이 순간 문제를 푸는 데 필요한 메모장이다. 예를 들어 여행 에이전트가 현재 사용자의 요청이 "다음 달 파리 출장, 직항 선호, 예산 상한 있음"이라는 핵심만 붙잡고 있는 상태가 여기에 가깝다. 전체 대화를 통째로 들고 있는 것보다, 현재 의사결정에 필요한 정보만 뽑아 두는 편이 더 효율적일 때가 많다.
둘째는 단기 메모리다. 한 세션, 한 대화, 한 작업 흐름 동안 이어지는 문맥이다. 사용자가 "파리 항공권은 얼마야?"라고 묻고 이어서 "거기 숙소는?"라고 말했을 때, 여기서의 "거기"가 파리라는 사실을 잊지 않게 해 주는 층이다.5
셋째는 장기 메모리다. 세션이 끝난 뒤에도 남는 정보다. 사용자의 선호, 자주 쓰는 형식, 반복되는 제약 조건, 과거 상호작용에서 얻은 사실 같은 것들이 여기에 들어간다. 이런 정보가 있어야 다음 대화에서 처음 만난 척하지 않는다.5
현실에서는 이 세 층 외에도 더 세분화한 메모리를 쓰기도 한다. 특정 사용자의 취향을 담는 프로필 메모리, 과거 작업의 성공과 실패를 남기는 에피소드 메모리, 대화에서 사람·장소·제품 같은 개체를 뽑아 저장하는 엔티티 메모리 같은 방식이다.5
여기서 중요한 설계 포인트는 단 하나다. 모든 것을 기억하지 말고, 다시 쓸 가능성이 높은 것을 기억하라. 사용자가 잠깐 던진 잡담까지 영구 저장하면 개인화가 좋아지는 것이 아니라 잡음이 늘어난다.
메모리는 어떻게 만들까: 버퍼, 요약, 검색, 프로필
메모리를 구현하는 방식도 한 가지가 아니다. 아주 단순한 에이전트는 최근 메시지 몇 개만 유지하는 버퍼 메모리로도 충분하다. 하지만 대화가 길어지거나 세션을 넘겨야 하면 다른 전략이 필요해진다.6
가장 흔한 방식은 네 가지다.6
최근 대화만 유지하는 슬라이딩 윈도우
오래된 대화를 압축하는 요약 메모리
벡터 검색으로 관련 조각을 꺼내 오는 검색 기반 메모리
최근 세부 맥락과 오래된 요약을 함께 쓰는 계층형 메모리
각 방식에는 성격이 있다. 슬라이딩 윈도우는 단순하고 빠르지만 오래된 중요한 정보를 잃기 쉽다. 요약 메모리는 토큰을 아끼지만, 섬세한 뉘앙스를 놓칠 수 있다. 검색 기반 메모리는 방대한 정보를 다룰 수 있지만, 검색 품질이 나쁘면 엉뚱한 기억을 꺼낸다. 그래서 실전에서는 하나만 쓰기보다 섞어서 쓴다.
예를 들어 현재 대화는 최근 8개 메시지로 유지하고, 오래된 내용은 주기적으로 요약하고, 사용자 선호는 별도의 프로필 저장소에 넣고, 필요한 경우에만 벡터 검색으로 과거 메모리를 불러오는 식이다. 이런 하이브리드 구조가 많아지는 이유는, 메모리가 단순한 저장 문제가 아니라 비용, 속도, 품질의 균형 문제이기 때문이다.7
메모리 설계에서 자주 빠지는 함정도 있다. 오래된 정보를 지우지 않아 검색 품질이 나빠지는 경우, 이미 있는 사실을 계속 중복 저장하는 경우, 바뀐 선호를 갱신하지 못하는 경우가 대표적이다. 그래서 메모리는 저장뿐 아니라 중복 제거, 버전 관리, 갱신, 망각 정책까지 함께 설계해야 한다.17
또 하나 놓치기 쉬운 점은 사용자 통제다. 장기 메모리를 쓰는 에이전트라면, 사용자가 무엇이 저장되었는지 알 수 있어야 하고 필요하면 수정하거나 삭제할 수 있어야 한다. 기억력이 좋은 비서는 유용하지만, 무엇을 기억하는지 알려주지 않는 비서는 금방 불편해진다.
네 부품은 따로 놀지 않는다
이제 중요한 장면이 하나 남았다. 네 부품은 각각 독립적이지만, 실제 에이전트에서는 항상 함께 움직인다.
예를 들어 출장 지원 에이전트를 상상해 보자. 사용자가 항공권 스크린샷을 올리며 "이 일정 기준으로 호텔도 잡아줘"라고 말한다.
먼저 VLM이 스크린샷에서 날짜, 도시, 항공편 시간을 읽는다. 그다음 시스템 프롬프트가 행동의 경계를 잡는다. 예산 한도를 넘기면 먼저 확인하고, 회사 정책상 허용되지 않는 옵션은 추천하지 말라는 식이다. 이어서 에이전트는 호텔 검색 API와 사내 출장 정책 도구를 호출한다. 마지막으로 메모리가 사용자의 선호를 보탠다. 예를 들어 조용한 숙소를 선호한다든지, 아침 미팅이 많아 회의장 근처를 좋아한다든지 하는 정보다.
이 과정을 보면 역할이 선명하다. 모델은 이해하고 판단하고, 프롬프트는 기준을 정하고, 도구는 실제 세상을 건드리고, 메모리는 시간을 이어 준다. 네 부품 중 하나라도 빠지면 경험이 급격히 어색해진다. 모델만 있으면 말은 그럴듯한데 행동을 못 하고, 도구만 있으면 자동화 스크립트는 되지만 상황 판단이 약하다. 메모리가 없으면 매번 처음부터 다시 묻고, 프롬프트가 약하면 같은 도구를 가지고도 엉뚱한 방식으로 일한다.
그래서 좋은 설계는 "가장 좋은 모델을 넣자"로 끝나지 않는다. 오히려 "이 네 부품의 책임을 어떻게 나눌까"가 핵심 질문이 된다.
설계할 때 꼭 던져야 할 질문
이 장을 실전에 연결하려면, 부품별로 질문을 던지는 습관이 필요하다.
모델: 이 작업은 텍스트만 이해하면 충분한가, 아니면 이미지와 화면도 읽어야 하는가. 깊은 추론이 필요한가, 빠른 반응이 중요한가.
프롬프트: 성공과 실패를 어떻게 정의할 것인가. 불확실할 때는 무엇을 먼저 하게 할 것인가. 어떤 행동은 금지할 것인가.
도구: 읽기 도구와 쓰기 도구를 분리했는가. 각 도구의 책임이 선명한가. 실패 시 재시도나 대체 경로가 있는가.
메모리: 무엇을 저장할 것인가. 언제 꺼낼 것인가. 언제 잊게 할 것인가. 사용자가 수정하고 삭제할 수 있는가.
이 질문에 답하지 못한 채 구현을 시작하면, 나중에 문제가 생겼을 때도 원인을 분리하기 어렵다. 반대로 이 질문에 답해 두면, 디버깅도 빨라진다. 검색이 이상하면 메모리와 도구를 보고, 말투가 흔들리면 프롬프트를 보고, 이미지 해석이 자꾸 틀리면 모델 선택을 다시 보면 된다.
흔한 오해 네 가지
마지막으로, 처음 설계할 때 자주 만나는 오해를 짚고 넘어가자.
첫째, 큰 모델이면 다 해결된다는 오해다. 큰 모델은 도움이 되지만, 도구 정의와 메모리 설계가 나쁘면 비싼 혼란이 될 뿐이다.
둘째, 긴 컨텍스트가 곧 메모리라는 오해다. 긴 문맥 창은 좋은 작업 공간일 뿐, 오래된 정보를 정리하고 우선순위를 매기고 다시 꺼내 오는 메모리 시스템과는 다르다.1
셋째, 도구를 많이 주면 더 유능해진다는 오해다. 실제로는 선택지가 많을수록 잘못 고를 가능성도 커진다. 에이전트에게 필요한 것은 도구의 개수보다 도구의 명확성이다.23
넷째, 모든 것을 기억할수록 개인화가 좋아진다는 오해다. 사람도 쓸데없는 정보를 너무 많이 들고 있으면 집중이 흐려진다. 에이전트도 마찬가지다. 좋은 기억력은 저장량보다 회상 품질에 가깝다.57
이 장의 핵심
에이전트는 모델 하나가 아니다. 모델, 프롬프트, 도구, 메모리가 서로 역할을 나눠 가진 시스템이다.
모델은 사고의 중심이지만 혼자서는 현재 세계를 알지도, 행동하지도, 오래 기억하지도 못한다. 프롬프트는 에이전트의 성격 장식이 아니라 운영 규칙이다. 도구는 에이전트에게 손발을 주지만, 동시에 가장 큰 위험 면적도 만든다. 메모리는 연속성과 개인화를 주지만, 많이 저장하는 것보다 잘 골라 저장하고 잘 꺼내는 것이 중요하다.
이 네 부품을 분해해서 볼 수 있게 되면, 이제부터 에이전트 설계는 훨씬 덜 추상적이 된다. 다음 장에서는 이 부품들을 바탕으로, 하나의 에이전트를 어떤 패턴으로 설계할 수 있는지 본격적으로 살펴보게 된다.
참고
2Function Calling in AI Agents
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.