AI 에이전트 개발, "어떤 모델 쓰냐"보다 "어떻게 설계하냐"가 진짜 차이다

한줄 요약

AI 에이전트 품질은 모델이 아니라 루프·역할·컨텍스트 설계에서 결정된다.

AI 에이전트 개발을 의뢰받은 에이전시라면, 가장 먼저 이 질문을 던져야 한다. "어떤 모델을 붙일까"가 아니라 "그 모델이 어떤 구조 위에서 움직이게 할까."

요즘 클라이언트 미팅에서 "GPT-4o 써주세요", "Claude 써주세요"라는 요청은 흔하다. 하지만 모델이 곧 에이전트는 아니다. 모델은 재료고, 에이전트는 그 재료를 실제로 일하게 만드는 실행 구조다. 이 차이를 모르면, 데모는 그럴싸한데 운영에서 무너지는 시스템을 납품하게 된다.

에이전트란 결국 무엇인가

단순하게 정의하면, 에이전트는 "한 번 답하고 끝나는 시스템"이 아니다. 목표가 완료될 때까지 도구를 쓰고, 결과를 받아 다음 행동을 결정하고, 그 과정을 반복하는 실행 루프가 있어야 에이전트라고 부를 수 있다.

이 루프 안에는 최소한 다섯 가지 요소가 필요하다.

• 실행 루프(agent loop): 모델이 도구를 호출하고, 결과를 받아 다음 행동을 이어가는 반복 구조
• 상태 관리(state): 작업이 어디까지 왔는지 기억하고 이어가는 장치
• 도구 계층(tools): 검색, 파일 접근, 외부 API 호출 등 모델이 실제 세계에 작동하는 수단
• 안전장치(guardrails): 위험한 행동을 사전에 차단하거나 사람의 검토를 거치게 하는 정책
• 관측 가능성(observability): 시스템이 왜 그 행동을 했는지 로그와 트레이스로 추적하는 능력

에이전시 관점에서 이 다섯 가지는 전부 설계 항목이다. 모델을 고르는 건 그 이후의 일이다.

클라이언트 요구사항이 "에이전트"일 때, 뭐가 달라지나

일반 챗봇이나 단순 자동화와 에이전트의 가장 큰 차이는 실패 시나리오의 복잡도다.

챗봇은 답변이 틀려도 사용자가 다시 질문하면 그만이다. 하지만 에이전트는 파일을 수정하고, API를 호출하고, 데이터베이스를 건드린다. 중간에 잘못된 판단이 나오면 되돌리기 어렵다. 그래서 에이전트 프로젝트를 받을 때는 기획 단계부터 다음 질문을 클라이언트와 함께 정해야 한다.

• 에이전트가 실패하면 어디서 멈춰야 하는가
• 어떤 행동은 자동 실행이 가능하고, 어떤 행동은 사람 승인이 필요한가
• 한 번 실행으로 최대 몇 단계까지 허용할 것인가
• 중간 결과물은 어디에 저장하고 어떻게 감사(audit)할 것인가

이 질문들에 답이 없으면, 기술적으로 완성된 시스템도 운영 중에 클라이언트 신뢰를 잃는다.

"만능 에이전트 하나"보다 "역할이 나뉜 구조"가 낫다

에이전시가 가장 흔하게 저지르는 실수는 모든 기능을 하나의 거대한 에이전트에 몰아넣는 것이다. 프롬프트를 길게 써서 "이것도 하고, 저것도 해"라고 지시하는 방식이다. 데모 단계에서는 통한다. 하지만 실제 운영 데이터가 들어오기 시작하면 맥락이 섞이고, 어떤 판단이 어디서 나왔는지 추적이 안 된다.

더 나은 접근은 역할을 나누는 것이다. 예를 들어, 문서 기반 고객 응대 에이전트를 만든다고 하면 이렇게 나눌 수 있다.

• 조율 에이전트(orchestrator): 전체 흐름을 제어하고, 어떤 전문 에이전트를 호출할지 결정
• 검색 에이전트: 관련 문서를 찾아 근거 ID만 반환, 쓰기 권한 없음
• 답변 에이전트: 검색 결과를 받아 응답 생성, 근거 없으면 답변 불가로 설계
• 실행 에이전트: 티켓 생성이나 데이터 수정 등 실제 변경 작업, 조율 에이전트의 승인 없이는 실행 불가

여기서 중요한 건 "나눴다"는 사실이 아니라, 각 에이전트의 입력·출력·권한이 명확히 제한되어 있다는 점이다. 역할 분리는 구조도를 예쁘게 만드는 작업이 아니라, 책임과 권한을 분리하는 작업이다.

도구 설계는 기능별이 아니라 위험도별로 해야 한다

에이전트가 쓰는 도구(tool)는 기능별로 나열하는 것보다 위험도 등급으로 분류하는 편이 실전에서 훨씬 유용하다.

등급	예시	처리 방식
읽기 전용	문서 검색, 파일 조회	자동 실행 허용
외부 읽기	외부 API 조회	자동 실행, 로깅 필수
쓰기	파일 수정, 초안 생성	사람 검토 후 실행
실행	코드 실행, 스크립트 구동	사람 승인 필수
파괴적	데이터 삭제, 프로덕션 배포	기본 차단

클라이언트에게 "어떤 도구를 붙였는가"를 설명하는 것보다, "어떤 도구를 어떤 조건에서 열었는가"를 설명할 수 있어야 한다. 이 기준이 없으면 에이전트가 예상치 못한 행동을 했을 때 원인 파악도, 클라이언트 설득도 어렵다.

---

컨텍스트 관리가 에이전시의 기술 경쟁력이 된다

모델 성능이 상향 평준화되면서, 에이전시 간 기술 차이가 나는 영역이 점점 컨텍스트 관리 쪽으로 옮겨가고 있다.

컨텍스트는 많이 넣는다고 좋아지지 않는다. 오히려 불필요한 정보가 쌓이면 모델이 우선순위를 잘못 판단하거나, 이전 작업의 잔재가 현재 판단을 오염시킨다. 실전에서는 이렇게 나누는 편이 안정적이다.

• 지속 규칙: 프로젝트 전반에 걸쳐 항상 적용되는 원칙. 짧고 핵심만 유지
• 세션 상태: 현재 작업의 중간 결과물. 작업이 끝나면 정리
• 전달 카드: 한 에이전트에서 다른 에이전트로 넘길 때, 전체 대화 이력이 아니라 요약된 작업 정보만 전달

이 세 가지를 구분하지 않고 모든 걸 하나의 컨텍스트에 쑤셔넣으면, 에이전트가 길어질수록 품질이 떨어진다. 그리고 그 품질 저하의 원인을 모델 탓으로 돌리게 된다.

결국 좋은 에이전트를 납품하는 에이전시는 "더 좋은 모델을 쓴 곳"이 아니라, "모델이 제대로 일할 수 있는 구조를 설계한 곳"이다.