개인 프로젝트에서 AI 에이전트를 설계부터 구현까지 해보며 고민한 것들을 원칙으로 정리해보려 한다. 대단한 경험은 아니지만, 직접 구현하며 고민했던 나만의 설계 기준을 남겨 두고 싶었다.
AI 에이전트는 사람이 매 단계를 지시하지 않아도 한 번의 입력만으로 스스로 계획하고 도구를 골라 쓰며 여러 단계를 거쳐 목표를 달성하는 프로그램이다. 그래서 모델 하나가 똑똑하다고 저절로 잘 되는 게 아니라, 어떻게 설계하느냐가 중요하다고 느꼈다.
그렇다면 나의 경우 AI 에이전트를 설계할 때 가장 중요한 건 뭘까?
컨텍스트, 환경, 피드백 이렇게 세 가지를 가장 우선적으로 고려할 것이다. 그 이유는 에이전트는 결국 LLM 모델을 호출하여 동일한 작업의 루프를 반복하는 것이고, 모델 자체는 우리가 바꿀 수 없는 상수에 가깝다. 우리가 실제로 손대는 건 단계마다 모델이 무엇을 보고(컨텍스트), 무엇을 할 수 있고(환경), 잘 가고 있는지 확인(피드백)할 뿐이다. 이 셋이 에이전트 품질의 대부분을 결정하게 된다.
좋은 에이전트는 똑똑한 모델뿐 아니라 잘 설계된 컨텍스트, 환경, 피드백에 기반한다고 생각한다.
컨텍스트 — 모델이 작업할 때 무엇을 보는가
에이전트가 무너질 때, 원인은 대개 모델이 멍청해서가 아니다. 봐야 할 게 빠졌거나, 엉뚱한 게 섞여 컨텍스트가 오염됐기 때문이다. 시스템 지시와 대화 이력, RAG로 읽어들인 문서, 툴이 실행된 결과, 이전 단계의 출력, 요약된 메모리의 내용 — 이 모든 건 결국 ‘이번 단계에 모델이 보게 될 정보’들을 채우는 재료다. 그 정보의 품질이 곧 답의 품질로 이어진다.
컨텍스트를 채우는 재료 중 상당수는 메모리에서 온다. 컨텍스트가 ‘지금 모델이 보는 화면’이라면, 메모리는 ‘그 화면을 채우려 저장하고 인출하는 곳’이다. 그리고 메모리는 지속 범위로 나뉜다. 지금 이 대화 안에서만 유지되는 단기 메모리(현재 사용자가 제시한 조건, 직전 검색 결과)와, 대화가 바뀌어도 계속 이어져야 하는 장기 메모리(사용자의 취향, 반복되는 설정)다. 단기는 이번 대화 상태로 들고 있으면 되지만, 장기는 따로 저장해 두었다가 필요할 때 다시 불러와 컨텍스트에 넣는다.
그래서 컨텍스트는 많이 넣는 게 아니라 어떻게 잘 골라 기록하고 관리할 지의 문제다. 필요한 것들만 골라 노이즈로 인해 정보의 분별력을 약화하지 않아야 하고, 바깥에서 들어온 텍스트는 데이터로만 취급해 지시로 실행되지 않도록 경계를 둔다. 그러고도 길어지면 요약해 압축한다. 내 예약 안내 서비스도 검색 결과가 낡았을 수 있어, 답을 만들기 직전 원본을 다시 읽어 최신값으로 채운다.
특히 검색 결과는 그대로 들이붓는 게 아니라, 여러 번의 조회를 거쳐 ‘답변에 바로 쓸 형태’로 가공해 넣는 편이 좋다. 예를 들어 “흑백요리사 맛집 리스트 정리해줘” 같은 작업은 한 번의 검색으로 끝나지 않는다.
- 먼저 ‘흑백요리사’가 무엇인지부터 찾는다 (키워드로 요리 서바이벌 예능에 대한 정보부터).
- 그 출연 셰프들이 운영하는 식당을 검색한다.
- 식당별 대표 메뉴, 장르, 방문 후기까지 추가로 찾아 채운다.
이렇게 흩어진 검색 결과가 ‘출연 셰프 → 식당 → 메뉴/후기’로 엮이면서, 답변에 바로 쓸 형태의 지식으로 정리된다. 검색이 단순 ‘조회’가 아니라 ‘컨텍스트를 빚는 과정’이 되는 셈이다.
요즘 ‘프롬프트 엔지니어링’에서 ‘컨텍스트 엔지니어링’으로 무게중심이 옮겨간다는 말이 자주 들리는 것도 같은 맥락이다.
컨텍스트는 많이 넣는 문제가 아니라 잘 골라, 잘 가공해 넣는 문제다.
환경 — 에이전트가 무엇을 할 수 있는가
모델은 혼자서는 아무것도 못 한다. 검색하고 조회하고 예약하려면 외부와 소통할 창구가 필요하다. 이걸 흔히 도구라 부르지만 함수 호출, 스킬, 외부 시스템까지 더 넓게 아우르기 위해 여기서는 환경이라 부른다. 에이전트에게 ‘무엇을 할 수 있게 하느냐’는 프롬프트만큼, 때로는 그 이상으로 중요한 설계 문제다.
앞의 흑백요리사 맛집 정리를 다시 떠올려 보자. 그 작업이 가능하려면 모델에게 최소한 ‘웹 검색’ 도구가 있어야 한다. 환경이 곧 에이전트가 할 수 있는 작업의 범위인 것이다.
특히 도구는 정의 자체가 곧 사용 설명서다. 모델은 도구의 이름과 설명, 파라미터만 보고 언제 어떻게 쓸지 판단하기 때문에, 설명이 모호하면 오용하고 명확하면 알아서 잘 쓴다. 그래서 실패를 돌려줄 때도 그냥 에러를 던질 게 아니라 모델이 이해하고 회복할 수 있는 형태로 알려줘야 하며(“결과 0건”, “파라미터가 범위를 벗어남”처럼), 반환값도 장황한 원본 덤프가 아니라 모델이 이해하기 쉬운 구조로 전달하도록 해야 한다.
# 도구 정의 자체가 모델에게 주는 '사용 설명서'다
{
"name": "search_reservations",
"description": "카테고리/지역/상태로 공공서비스 예약을 조회한다",
"parameters": {
"category": {"type": "string", "enum": ["체육", "문화", "교육", "진료"]},
"district": {"type": "string", "description": "자치구명 (예: 강남구)"},
"status": {"type": "string", "enum": ["접수중", "마감"]},
},
}Anthropic이 “Building Effective Agents”에서 이 에이전트-컴퓨터 인터페이스 설계에 프롬프트만큼 공을 들이라고 강조하는 이유가 여기 있다. 모델을 갈아끼우는 것보다 도구 설명 한 줄을 다듬는 게 더 큰 개선일 때가 많다.
피드백 — 잘 가고 있는지 어떻게 아는가
컨텍스트를 잘 채우고 도구를 잘 줘도, 결과가 좋은지 스스로 판단하지 못하면 에이전트는 잘못된 방향으로 계속 나아간다. 그래서 검색 결과가 비었는지, 한쪽으로 쏠렸는지를 점검하고, 아니다 싶으면 방향을 바꿔 다시 시도하는 장치가 필요하다. 그리고 언제 ‘이만하면 됐다’ 혹은 ‘여기까지가 한계다’라고 멈출지에 대한 기준도 명확히 정해야 한다.
흑백요리사 예시로 보면 분명하다. 셰프 이름으로 검색했는데 식당이 안 나오면 상호나 지역을 바꿔 다시 찾고, 후기가 빈약하면 다른 소스를 더 뒤진다. 이런 점검과 재시도가 없으면, 모델은 부실한 첫 검색 결과만 쥐고 그럴듯한 리스트를 지어내 버린다.
다만 이 되먹임 루프에는 반드시 브레이크가 필요하다. 종료 조건과 재시도 횟수/비용의 상한이 없으면, 자기 교정은 무한 루프나 비용 폭주로 이어진다. 회복 가능성과 지연/비용 사이에서 상한을 정해 두어야 한다. 내 서비스도 답을 만들기 직전 결과 품질을 자각하고 방향을 바꿔 재시도하되, 그 횟수에 상한을 둔다.
그리고, 에이전트 바깥의 평가 체계
여기까지가 에이전트 안의 이야기라면, 외적으로는 ‘이게 정말 좋아지고 있나’를 재는 체계가 있어야 한다. 에이전트의 품질을 발전시키기 위해 여러 변경이 생기기 마련인데, 변경 후 품질을 평가하는 시스템이 있어야 일관되게 품질을 검증할 수 있게 되고 운영 환경에 안전하게 배포가 가능해진다. 나는 이 체계가 사실상 AI 에이전트의 설계만큼 중요하다고 생각한다.
에이전트에 대한 변경이 생기게 되면 회귀 테스트를 통해 다른 케이스는 잘못 되지는 않았는지 확인하고, 정답을 봉인한 평가셋으로 품질을 객관적으로 측정하며(프롬프트나 예시가 이 셋을 참조하면 점수가 오염된다), recall이나 정확도 같은 품질 지표와 지연/비용을 함께 본다.
에이전트는 비결정적이라 ‘고쳤다’를 감으로 판단하면 회귀를 놓치기 쉽다. OpenAI의 에이전트 구축 가이드가 가드레일과 평가를 비중 있게 다루는 것도 결국 신뢰의 문제이기 때문이다. 내 경우엔 봉인 평가셋의 recall로 설정 변경의 채택 여부를 정한다. 숫자가 오르지 않으면 그럴듯해 보여도 버린다.
측정 없는 개선이라면 개선이라는 착각은 아닐지 점검해볼 필요가 있다.
정리
정리하면, 에이전트에서 모델은 ‘고르는 것’이고 우리가 실제로 ‘설계하는 것’은 다음 세 가지다.
- 컨텍스트(메모리) — 매 단계 모델에게 무엇을 보여줄 것인가
- 단기 메모리 — 이번 대화 안에서만 유지되는 것
- 장기 메모리 — 대화를 넘어 이어져야 하는 것
- 환경 — 모델이 무엇을 할 수 있게 할 것인가
- 피드백 — 잘 가고 있는지 어떻게 알게 할 것인가
그리고 이 셋을 만든 뒤에는 평가 체계로 바깥에서 계속 검증하고 다듬는다. 더 똑똑한 모델을 기다리기보다 이 네 가지에 공을 들이는 편이, 대체로 더 빠르고 확실한 개선이다.
모델은 고르고, 나머지는 설계한다. 그리고 측정을 통해 지속적으로 발전할 수 있도록 한다.
언젠가 또 다른 시스템을 구현하게 되면, 그때의 경험과 이 글을 나란히 놓고 지금의 생각이 얼마나 바뀌어 있을지 궁금하다.
참고
- Anthropic — Building Effective Agents
- Cognition — Don’t Build Multi-Agents
- Google Cloud Architecture Center - 에이전트 AI
- OpenAI — A Practical Guide to Building Agents