AI 시스템 설계: 워크플로, 에이전트, 가드레일

용어 지도: 무엇이 어느 층에 있나

LLM 기반 시스템을 만들 때 고를 수 있는 손잡이는 생각보다 적다. 결국 다섯 가지 중 하나를 바꾸는 것이다. ① 모델의 가중치(무엇을 '아는가'·어떻게 '말하는가'), ② 매 호출의 컨텍스트(이번에 무엇을 보여 주나), ③ 모델과 코드 사이의 인터페이스(모델 출력이 어떻게 행동이 되나), ④ 앱과 외부 도구의 연결 규격(도구를 어떻게 꽂나), ⑤ 제어 흐름(다음에 무엇을 할지 누가 정하나). 이 장에서 다루는 용어는 모두 이 다섯 층 중 하나에 놓인다.

이 그림 하나로 많은 혼동이 풀린다. RAG는 컨텍스트 층의 기법이고, MCP는 연결 층의 프로토콜이며, 에이전트는 제어 흐름 층의 아키텍처다. 그래서 "에이전트가 MCP 서버가 노출한 검색 도구를 툴 콜링으로 불러 RAG를 수행하고, 그 모델은 사내 문체로 파인튜닝되어 있다"는 문장은 다섯 층을 모두 쓰는 정상적인 설계다. 각 개념의 바탕은 앞 장에서 다뤘다. RAG 파이프라인은 10장, 에이전트 루프·MCP 기초·컨텍스트 엔지니어링은 11장, 파인튜닝과 RLHF는 7장을 보라. 이 장은 그것들을 나란히 놓고 비교하고, 실제 서비스로 운영할 때 필요한 공학(평가·안전·관측·장애 대응)을 다룬다.

AI 에이전트란 무엇인가

"에이전트"는 2024~2026년 가장 남용된 단어다. 챗봇, 자동화 스크립트, RPA, 고정된 LLM 파이프라인까지 모두 에이전트라고 부르는 경우가 있다. 이 장에서는 다음 정의를 쓴다.

핵심은 두 번째 줄이다. LLM이 도구를 쓴다고 에이전트가 되는 것이 아니다. "검색 → 요약 → 번역"을 코드로 순서대로 부르면 각 단계에 LLM과 도구가 있어도 다음 단계를 정하는 주체가 코드이므로 워크플로다. 반대로 단계가 두 개뿐이어도 "검색을 더 할지 이제 답할지"를 모델이 정하면 에이전트적이다. 종료 조건도 둘로 나눠 생각해야 한다. 모델이 판단하는 성공 종료("다 했다")와, 모델의 판단과 무관하게 하네스가 강제하는 안전 종료(최대 단계, 시간, 비용, 반복 감지)다. 후자가 없으면 에이전트는 실패를 인정하지 못하고 같은 도구를 계속 부를 수 있다.

자율성의 스펙트럼

에이전트냐 아니냐는 이분법보다, "모델이 제어 흐름의 얼마만큼을 결정하나"라는 연속적인 축으로 보는 편이 설계에 유용하다. 자율성이 오를수록 처리할 수 있는 입력의 다양성은 커지지만, 예측 가능성·테스트 용이성·비용 상한은 나빠진다.

에이전트 vs 워크플로

Anthropic의 엔지니어링 글 "Building effective agents"(2024.12)는 이 구분을 널리 퍼뜨렸다. 워크플로(workflow)는 LLM과 도구가 미리 정의된 코드 경로를 따라 조율되는 시스템이고, 에이전트는 LLM이 자신의 프로세스와 도구 사용을 동적으로 결정하는 시스템이다. 둘 다 LLM을 여러 번 부를 수 있다는 점은 같다. 차이는 오직 "분기와 반복을 누가 정하나"다.

워크플로의 다섯 가지 패턴

언제 무엇을 쓰나

실무의 경험칙은 "가장 단순한 해법부터"다. 단일 호출 + 좋은 프롬프트(+ RAG)로 충분하면 거기서 멈추고, 단계가 명확하면 워크플로로, 경로를 미리 정할 수 없을 때만 에이전트로 간다. 그리고 에이전트를 쓰더라도 바깥은 결정적 코드로 감싸 상한·검증·승인을 둔다.

툴 콜링 vs 함수 호출: 같은 것의 두 이름

툴 콜링(tool calling, tool use)과 함수 호출(function calling)은 같은 메커니즘을 가리키는 다른 이름이다. 2023년 6월 OpenAI API가 "function calling"이라는 이름으로 대중화했고, Anthropic은 "tool use", Google Gemini는 다시 "function calling"이라고 부른다. 이후 OpenAI API도 파라미터 이름을 tools로 바꾸면서 업계 전반에서 두 표현이 섞여 쓰인다. 본질은 하나다.

벤더별 명칭과 메시지 모양

필드 이름은 API 버전마다 바뀌므로 외울 필요가 없다. 기억할 것은 세 가지 공통 구조다. (1) 요청에는 호출 id가 붙고, 결과는 같은 id로 짝지어 돌려준다. 그래서 한 번에 여러 호출(병렬 도구 호출)을 내도 결과를 맞출 수 있다. (2) 응답의 종료 이유(stop reason)가 "도구 호출 때문에 멈춤"으로 표시되어, 앱은 이를 보고 실행 단계로 넘어간다. (3) tool_choice 같은 옵션으로 "반드시 이 도구를 불러라/부르지 마라"를 강제할 수 있다. 강제 도구 호출은 사실상 구조화 출력(8장)과 같다. 출력 스키마가 곧 인자 스키마이기 때문이다.

MCP: 무엇을 표준화하는가

11장에서 본 MCP(Model Context Protocol)를 한 줄로 요약하면, AI 애플리케이션(호스트)과 도구·데이터 제공자(서버) 사이의 통신 규격이다. 호스트 안의 클라이언트가 서버마다 연결 하나를 맡고, 메시지는 JSON-RPC 2.0, 전송은 로컬 프로세스면 표준 입출력(stdio), 원격이면 HTTP(Streamable HTTP)를 쓴다. 서버는 세 가지를 노출한다: 모델이 호출하는 tools, 앱이 컨텍스트에 첨부하는 resources, 사용자가 고르는 prompts. 이 절에서는 구조를 다시 설명하지 않고, 함수 호출과 무엇이 다른가에 집중한다.

예를 들어 호스트(채팅 앱, IDE, CLI, 사내 봇, 브라우저 확장)가 5개, 연결할 시스템(위키, 이슈 트래커, DB, 드라이브 …)이 20개면, 규격이 없을 때 통합은 5 × 20 = 100개다. MCP가 있으면 호스트 5곳이 클라이언트를 한 번씩, 시스템 20곳이 서버를 한 번씩 구현해 25개로 끝난다. MCP의 가치는 모델을 똑똑하게 만드는 것이 아니라 이 통합 비용을 M×N에서 M+N으로 바꾸는 데 있다. 서버 쪽 세 가지 외에, 클라이언트도 서버에 기능을 제공한다. 서버가 호스트의 모델에게 생성을 부탁하는 sampling, 작업 범위(폴더 등)를 알려 주는 roots, 사용자에게 추가 입력을 요청하는 elicitation이다.

핵심 비교: RAG · 툴 콜링 · MCP · 에이전트 · 파인튜닝 · 워크플로

이제 여섯 용어를 한 표에 놓는다. 각 행을 "이것은 기법인가, 프로토콜인가, 아키텍처인가"부터 읽으면 헷갈릴 일이 크게 줄어든다.

서로 어떻게 조합되나

그림을 문장으로 읽어 보자. "에이전트가 MCP 서버의 검색 도구로 RAG를 수행한다"는 다음 뜻이다. 에이전트(아키텍처)가 루프 중에 검색이 필요하다고 판단해 툴 콜링(인터페이스)으로 search_docs를 요청하고, 호스트가 이를 MCP(프로토콜)로 서버에 전달하며, 서버가 하이브리드 검색으로 찾은 청크가 다음 호출의 컨텍스트에 들어가 생성의 근거가 된다(RAG, 기법). 세 개의 서로 다른 층이 한 문장에 들어 있다.

흔한 오해 모음

멀티 에이전트: 나누면 좋아지나

멀티 에이전트(multi-agent) 시스템은 여러 LLM 인스턴스가 각자의 컨텍스트로 일하며 협력하는 구조다. 가장 흔한 형태는 오케스트레이터–서브에이전트다. 리드 에이전트가 과업을 쪼개 서브에이전트들에게 맡기고(대개 병렬), 서브에이전트는 자기 컨텍스트 안에서 탐색한 뒤 압축된 결과만 돌려준다. 그림 14-3의 오케스트레이터–워커 워크플로와 모양이 같지만, 서브에이전트 각자가 도구 루프를 도는 에이전트라는 점이 다르다.

숫자 감각을 위한 공개 사례가 있다. Anthropic은 2025년 자사 리서치 기능의 멀티 에이전트 구조를 소개하면서, 내부 평가에서 단일 에이전트보다 크게 나았지만 토큰 사용량이 일반 채팅의 약 15배(단일 에이전트는 약 4배)였고, 성능 차이의 상당 부분이 "토큰을 더 많이 쓴 것" 자체로 설명되었다고 보고했다. 반대로 Cognition(2025)은 서브에이전트들이 서로의 결정을 모른 채 일하면 결과가 어긋난다며, 강하게 얽힌 과업에서는 단일 에이전트 + 컨텍스트 압축을 권했다. 둘은 모순이 아니다. 병렬화되는 넓은 과업이냐, 결정이 서로 얽힌 깊은 과업이냐의 차이다. 멀티 에이전트 실패를 분류한 연구(Cemri 등, 2025)는 실패를 크게 ① 명세·설계 문제(역할·종료 조건 불명확), ② 에이전트 간 불일치(정보 누락, 다른 에이전트 입력 무시, 같은 일 반복), ③ 검증 실패(조기 종료, 잘못된 검증)로 나눈다.

계획: ReAct, 계획-실행, 재계획

에이전트가 "다음에 무엇을 할지"를 정하는 방식은 크게 둘이다. ReAct(Yao 등, 2022)는 매 단계 생각 → 행동 → 관찰을 반복하며 한 걸음씩 결정한다(11장의 기본 루프). 계획-실행(plan-and-execute)은 먼저 전체 단계 목록을 세우고(planner), 실행기(executor)가 그 목록을 차례로 수행한다. Plan-and-Solve(Wang 등, 2023), LLMCompiler(Kim 등, 2023)처럼 계획을 의존성 그래프로 만들어 독립 단계를 병렬 실행하는 변형도 있다.

재계획(replanning)의 트리거는 명시적으로 정해 두는 것이 좋다. ① 도구 오류가 같은 방식으로 2회 이상 반복될 때, ② 관찰이 계획의 전제를 반박할 때(예: "해당 파일 없음"), ③ 예산(단계·토큰)의 절반을 썼는데 진척이 절반 미만일 때. Reflexion(Shinn 등, 2023)처럼 실패한 시도에서 "무엇이 잘못됐나"를 언어로 반성해 다음 시도의 컨텍스트에 넣는 방법도 재계획의 한 형태다. 추론 모델(11장)은 긴 사고 안에서 암묵적으로 계획을 세우므로, 별도 플래너 없이 ReAct만으로도 꽤 긴 과업을 푼다. 그래도 계획을 외부 파일(할 일 목록)로 써 두게 하면 컨텍스트가 압축·초기화되어도 진행 상황을 잃지 않는다.

메모리: 단기와 장기, 쓰기 정책과 오염

LLM 호출 자체는 상태가 없다. 에이전트의 '기억'은 전부 시스템 설계다. 단기 기억(short-term / working memory)은 현재 컨텍스트 창, 즉 이번 호출에 넣은 메시지들이다. 장기 기억(long-term memory)은 창 밖의 외부 저장소(파일, DB, 벡터 인덱스)에 써 두었다가 필요할 때 검색해 다시 창에 넣는 정보다. 인지 구조 관점의 분류(CoALA, Sumers 등, 2023)를 빌리면 장기 기억은 다시 셋으로 나뉜다.

장기 기억을 읽는 것은 사실상 RAG다(검색 대상이 문서 대신 과거 기억일 뿐). 어려운 쪽은 쓰기다. 무엇을, 언제, 어떤 형태로 저장할지가 메모리 쓰기 정책(memory write policy)이다.

• 무엇을: 원문 전체(검색은 쉬우나 노이즈 많음) vs 추출한 사실(깔끔하나 추출 오류). 사용자가 명시적으로 "기억해"라고 한 것만 저장하는 보수적 정책부터 시작하는 것이 안전하다.
• 언제: 매 턴(비용↑), 세션 종료 시 요약, 또는 모델이 save_memory 도구를 호출할 때.
• 갱신·삭제: "회의는 화요일" → 나중에 "목요일로 변경". 새 사실을 추가만 하면 모순된 기억이 쌓인다. 키 단위 덮어쓰기, 타임스탬프, 만료(TTL)가 필요하다. 사용자가 기억을 보고 지울 수 있어야 한다(개인정보 측면에서도).
• 범위: 사용자별·프로젝트별로 격리한다. 한 사용자의 기억이 다른 사용자의 답에 섞이면 정보 유출이다.

사람 개입: 승인 게이트와 에스컬레이션

사람 개입(human-in-the-loop, HITL)은 자동화 흐름의 특정 지점에서 사람의 판단을 받는 설계다. 모든 행동을 승인받으면 자동화의 의미가 없고, 아무것도 승인받지 않으면 사고가 난다. 핵심은 어디에 게이트를 둘지다.

게이트 위치를 정하는 가장 중요한 질문은 "되돌릴 수 있는가"다. 읽기·초안 작성·샌드박스 안 코드 실행은 되돌릴 수 있다. 외부 발송, 결제, 삭제, 프로덕션 배포는 되돌릴 수 없거나 비용이 크다. 되돌릴 수 없는 행동은 위험 점수와 무관하게 게이트를 두고, 나머지는 위험도로 거른다. 승인 화면에는 모델의 설명이 아니라 실제로 실행될 인자(받는 사람, 금액, 삭제 대상)를 보여 줘야 한다. 모델의 요약은 틀리거나 조작될 수 있다.

에이전트 평가: pass@k와 pass^k, 궤적과 비용

11장에서 SWE-bench·τ-bench 같은 벤치마크와 오류 누적을 다뤘다. 여기서는 내 시스템을 평가할 때 필요한 지표를 정리한다. 에이전트는 같은 입력에도 매번 다른 궤적을 밟으므로, 한 번 돌려 본 결과는 평가가 아니라 일화다.

숫자로 보면 차이가 극적이다. \(p=0.8\)인 과업은 pass@5 = 1−0.2⁵ = 0.9997이지만 pass^5 = 0.8⁵ = 0.33이다. "다섯 번 중 한 번은 된다"는 연구 데모에는 충분해도, 고객이 매번 쓰는 기능이라면 "다섯 번 연속 성공할 확률 33%"가 실제 경험이다. 사람이 결과를 고를 수 있는 상황(코드 후보 여러 개 중 테스트 통과한 것 선택)은 pass@k, 자동화된 반복 업무는 pass^k가 맞는 지표다.

결과만이 아니라 궤적과 비용을

판정은 가능하면 결정적 검사(테스트, DB 상태 비교, 정규식)로 하고, 어쩔 수 없을 때만 LLM 심사(LLM-as-a-judge)를 쓴다. LLM 심사는 긴 답·자기 모델 답을 선호하는 편향이 있으므로, 채점 기준표를 구체적으로 주고 사람 라벨과의 일치도를 먼저 측정해야 한다. 모델·프롬프트를 바꿀 때마다 같은 평가 세트를 돌리는 회귀 평가를 CI에 넣는 것이 실무의 기본이다.

에이전트 안전과 가드레일

가드레일(guardrails)은 모델의 입력·출력·행동을 모델 바깥에서 검사하고 제한하는 장치다. 출발점은 앞에서 본 사실이다. 모델은 요청만 하고 실행은 코드가 한다. 그러니 안전은 "모델이 착하게 행동하기를 바라는 것"이 아니라 "모델이 무엇을 요청하든 코드가 허용하는 범위 안에서만 일이 일어나게" 설계하는 것이다. 특히 에이전트에 ① 개인·사내 데이터 접근, ② 신뢰할 수 없는 외부 콘텐츠(웹, 메일, 문서), ③ 외부로 내보내는 수단(메일, HTTP 요청)이 동시에 있으면, 프롬프트 인젝션 한 번으로 데이터가 유출될 수 있다. 셋 중 하나를 끊는 것이 가장 확실한 방어다.

계층을 겹치는 효과는 계산할 수 있다. 세 층이 위험 행동을 각각 70%, 80%, 90% 잡고 서로 독립이면 모두 통과할 확률은 0.3 × 0.2 × 0.1 = 0.6%다. 하지만 실제 층들은 독립이 아니다. 같은 우회 표현에 함께 속는 두 분류기는 한 층이나 다름없다. 그래서 층은 서로 다른 원리(모델 기반 분류 + 결정적 규칙 + 권한 구조)로 구성해야 곱셈 효과가 난다. 특히 권한·샌드박스·허용 목록은 모델이 얼마나 교묘하게 속든 무관하게 작동하는 결정적 층이다.

관측성: 트레이스, 스팬, 메트릭

에이전트가 틀린 답을 냈을 때 "왜?"에 답하려면, 그 실행에서 어떤 프롬프트로 몇 번 모델을 불렀고, 어떤 도구가 무엇을 돌려줬으며, 어디서 시간이 걸렸는지를 재구성할 수 있어야 한다. 이것이 관측성(observability)이다. 분산 시스템에서 쓰던 개념을 그대로 가져온다.

표준화도 진행 중이다. OpenTelemetry는 생성형 AI용 시맨틱 컨벤션(gen_ai.* 속성: 모델 이름, 입력·출력 토큰 수 등)을 2024~2026년에 걸쳐 정의하고 있어, 특정 벤더 도구에 묶이지 않고 트레이스를 남길 수 있다. 실무에서 특히 중요한 것은 프롬프트 버전 관리다. 프롬프트는 코드와 같다. 템플릿을 저장소에서 버전으로 관리하고, 모든 LLM 스팬에 프롬프트 id·버전·모델 이름을 속성으로 달아 두면, 품질이 떨어졌을 때 "어느 변경 이후인가"를 트레이스와 평가 결과로 바로 추적할 수 있다.

재시도와 폴백: 실패를 전제로 설계하기

LLM API는 외부 네트워크 서비스다. 과부하(HTTP 429), 일시 장애(5xx), 타임아웃이 일상적으로 일어나고, 모델 출력도 형식이 깨질 수 있다. 신뢰성 공학의 오래된 도구들이 그대로 쓰인다.

독립 실패를 가정하면 계산은 간단하다. 시도당 실패율 \(p\), 재시도 최대 \(n\)회(총 \(n+1\)회 시도)면 성공률은 \(1-p^{n+1}\)이다. \(p=0.1\), \(n=3\)이면 99.99%. 폴백도 같은 원리다. 주 모델 가용성 99%, 독립인 폴백 98%면 체인의 가용성은 \(1-0.01\times0.02=99.98\%\)다. 그러나 이 숫자들은 독립이라는 가정에 기대고 있다. 제공자 장애가 5분간 이어지면 그 안의 재시도는 모두 같이 실패한다. 그래서 백오프의 총 대기 시간이 장애 지속 시간과 비슷한 규모여야 하고, 폴백은 다른 장애 도메인(다른 제공자·리전)에 둬야 의미가 있다.

결정적 시스템 vs 확률적 시스템

전통적 소프트웨어는 결정적(deterministic)이다. 같은 입력이면 같은 출력이 나오고, 그래서 단위 테스트가 "기대값과 같은가"로 성립한다. LLM은 확률적(probabilistic) 구성 요소다. 출력은 분포에서 뽑은 표본이다. AI 시스템 설계의 큰 부분은 이 확률적 부품을 결정적 코드로 감싸 전체를 예측 가능하게 만드는 일이다.

비결정성의 원인

1. 샘플링: 온도 \(T>0\), top-p 등(8장)이면 같은 분포에서 다른 토큰을 뽑는 것이 정상 동작이다. 시드를 고정해도 아래 이유로 보장되지 않는다.
2. 온도 0(그리디)에서도: 부동소수점 덧셈은 결합법칙이 성립하지 않는다(\((a+b)+c \ne a+(b+c)\)). GPU 커널은 성능을 위해 리덕션(합산)을 여러 조각으로 나누는데, 그 분할 방식이 배치 크기에 따라 달라지는 경우가 많다. 서버는 다른 사용자 요청과 함께 동적으로 배치하므로(12장), 내 요청의 로짓이 그때그때의 서버 부하에 따라 마지막 몇 비트 달라진다. Thinking Machines Lab(2025)은 이를 "배치 불변성의 부재"로 분석하고, 배치 불변 커널로 온도 0 출력을 비트 단위로 재현할 수 있음을 보였다(대가로 처리량 감소).
3. 근소한 동점과 자기회귀 증폭: 상위 두 토큰의 로짓 차이가 부동소수점 오차보다 작으면 argmax가 뒤집힌다. 한 토큰이 달라지면 그 뒤 생성 전체가 다른 길로 간다.
4. 시스템 쪽 변화: 같은 모델 별칭 뒤의 버전 갱신, 양자화·하드웨어 차이, 도구 결과(검색 순위, 시각)의 변화.

결정적 코드로 감싸기와 테스트 전략

• LLM에게는 판단만, 계산·상태 변경은 코드에게: 금액 합계를 모델이 "말하게" 하지 말고 계산기 도구나 코드로 계산한다. 모델은 어떤 항목을 더할지만 정한다.
• 검증 가능한 출력: 자유 텍스트 대신 스키마가 있는 구조화 출력, 인용은 원문 위치(청크 id)로, 코드는 테스트로, SQL은 실행 전 파싱·읽기 전용 검사로. 검증에 실패하면 오류를 피드백해 재생성(최대 N회)한다. 이것이 확률적 부품을 "성공 확률 × 검증"으로 신뢰성 있게 만드는 기본 패턴이다. 1회 형식 성공률 0.9, 독립 재생성 2회까지면 \(1-0.1^3=0.999\).
• 재현을 위한 기록: 모든 LLM 호출의 입력·출력·모델 버전·파라미터를 트레이스로 남긴다. 디버깅은 "다시 돌려 보기"가 아니라 "기록 재생"으로 한다.
• 테스트 피라미드: 아래 표처럼 층을 나눈다.

평가 세트의 통계적 판정에는 표본 크기 감각이 필요하다. 성공률 80%를 과업 100개로 재면 표준오차는 \(\sqrt{0.8\cdot0.2/100}=0.04\), 즉 95% 신뢰구간이 대략 ±8%p다. 프롬프트를 바꿨더니 78% → 82%가 되었다는 것은 이 크기에서는 잡음과 구별되지 않는다. 같은 과업으로 두 버전을 비교하는 짝지은 비교, 과업 수 늘리기가 필요하다.