에이전트 운영 설계 노트 (2/9) — 좋은 에이전트 런타임의 5계층

-

에이전트를 평가할 때 많은 팀이 먼저 모델, 프롬프트, 벤치마크 점수부터 본다. 물론 중요하다. 하지만 실제 운영에서 더 자주 문제를 만드는 것은 다른 층이다. 무엇을 항상 읽히게 할지, 어떤 도구를 어떤 형태로 노출할지, 작업 상태를 어디에 남길지, 어디서 멈추게 할지, 실패를 어떻게 보이게 할지. 좋은 에이전트 런타임은 이 다섯 가지를 한꺼번에 설계한 구조에 가깝다.

핵심 요약

  • 에이전트 런타임은 단순한 "모델 실행기"가 아니라, 컨텍스트, 도구, 상태, 경계, 관측성을 함께 묶는 작업 환경이다.
  • 품질이 흔들리는 원인은 종종 모델 부족이 아니라, 잘못된 계층 배치다. 예를 들어 상태를 대화 안에만 남기거나, 도구 권한과 승인 경계를 분리하지 않으면 같은 모델도 쉽게 불안정해진다.
  • 좋은 런타임은 더 많은 기능보다 더 명확한 선택 구조를 제공한다.
  • 다섯 계층은 독립적이지 않다. 컨텍스트 구조가 도구 선택에 영향을 주고, 상태 구조가 관측성 비용을 바꾸며, 경계 설계가 실패 반경을 결정한다.
  • 그래서 "좋은 에이전트를 어떻게 만들까"라는 질문은 점점 "좋은 런타임을 어떻게 쌓을까"라는 질문으로 바뀌고 있다.

1. 왜 이제는 모델보다 런타임을 먼저 봐야 하나

짧은 질의응답에서는 모델의 언어 능력이 거의 전부처럼 보일 수 있다. 하지만 파일을 읽고, 도구를 호출하고, 여러 턴 동안 작업을 이어 가는 순간부터 문제의 중심은 바뀐다.

실무에서 더 자주 중요한 질문은 이런 것들이다.

  • 이 에이전트는 무엇을 먼저 읽는가
  • 어떤 도구를 언제 쓰는가
  • 중간 상태는 어디에 남는가
  • 위험한 행동은 어디서 차단되는가
  • 실패했을 때 사람이 무엇을 볼 수 있는가

이 질문들은 프롬프트 문장 하나로 해결되지 않는다. 전부 런타임 설계 문제다.

그래서 에이전트 품질을 볼 때는 모델 위에 다음 작업대를 같이 봐야 한다.

  1. 어떤 컨텍스트가 들어오는가
  2. 어떤 도구 표면이 주어지는가
  3. 상태가 어떻게 외부화되는가
  4. 어떤 경계가 행동을 제한하는가
  5. 그 모든 과정이 어떻게 관측되는가

이 다섯 층이 맞물려야 런타임이 된다.

2. 1계층: 컨텍스트는 "많이 넣기"가 아니라 "언제 넣을지"의 문제다

에이전트 런타임의 첫 계층은 컨텍스트다. 하지만 여기서 컨텍스트는 단순히 긴 시스템 프롬프트를 뜻하지 않는다. 더 정확히는 어떤 규칙과 정보가 어떤 시점에 주입되는가의 구조다.

좋은 런타임은 보통 컨텍스트를 최소한 두 층으로 나눈다.

구분 역할
항상 보이는 컨텍스트 역할, 금지사항, 출력 규칙, 현재 작업 목표
필요 시 로드하는 컨텍스트 상세 문서, 긴 참고 자료, 과거 상태, 절차 문서

이 구분이 중요한 이유는 단순하다. 상시 문맥에 모든 것을 밀어 넣으면 중요한 규칙이 묻히고, 시작 비용이 커지고, 충돌하는 설명이 늘어난다.

좋은 컨텍스트 계층은 아래 질문에 답한다.

  • 이 규칙은 항상 보여야 하나
  • 이 정보는 이번 작업에만 필요한가
  • 이 문서는 지시인가, 참고인가, 상태인가
  • 다음 세션도 같은 정보를 같은 우선순위로 봐야 하나

Anthropic의 Claude Code 문서가 프로젝트 메모리, 사용자 메모리, 로컬 프로젝트 메모리를 분리해 설명하는 것도 같은 맥락이다. 컨텍스트는 길게 쌓는 문제가 아니라, 목적과 수명에 따라 배치하는 문제다.

즉 컨텍스트 계층의 핵심은 풍부함보다 배치다.

3. 2계층: 도구는 기능 목록이 아니라 선택 인터페이스다

두 번째 계층은 도구다. 많은 팀이 도구를 많이 붙이는 데 집중하지만, 실전에서 더 중요한 것은 개수보다 표면의 선명도다.

에이전트는 도구 구현을 이해한 뒤 선택하는 것이 아니다. 이름, 설명, 입력 schema, 출력 형식을 보고 판단한다. 따라서 도구는 백엔드 함수이면서 동시에 인터페이스다.

좋은 도구 계층은 보통 아래 특성을 가진다.

  • 이름이 구체적이다
  • 언제 써야 하는지 설명이 명확하다
  • 입력이 좁고 실수하기 어렵다
  • 출력이 짧고 구조적이다
  • 읽기, 수정, 실행, 외부 전송의 위험도가 분리된다

반대로 나쁜 도구 계층은 대체로 이렇다.

  • 비슷한 도구가 너무 많다
  • 만능 도구 하나가 너무 많은 행동을 품는다
  • 검색 결과나 로그를 너무 길게 반환한다
  • 권한이 도구 목적과 맞지 않게 넓다

OpenAI Agents SDK가 handoff와 guardrail을 각각 별도 구조로 두고, Anthropic이 서브에이전트별 허용 도구 범위를 따로 설명하는 이유도 같다. 중요한 것은 기능 수보다 에이전트가 무엇을 어떻게 고르게 되는가다.

좋은 런타임은 도구를 더 자유롭게 만드는 대신, 도구 선택 비용을 줄이는 방향으로 설계된다.

4. 3계층: 상태는 메모리가 아니라 재개 구조다

세 번째 계층은 상태다. 여기서 가장 흔한 오해는 상태를 "대화가 기억하는 것" 정도로 보는 것이다. 운영 관점에서는 그보다 더 중요한 정의가 있다.

상태는 다음 행동을 결정하기 위해 런타임 바깥에 남겨 둔 구조다.

즉 상태 계층의 목적은 저장이 아니라 재개다.

좋은 상태 계층은 보통 아래 요소를 포함한다.

상태 종류 예시
현재 목표 지금 무엇을 끝내려는가
진행 기록 어디까지 했고 무엇이 남았는가
검증 상태 무엇이 확인됐고 무엇이 미확인인가
인계 포인트 다음 세션이 어디서 시작해야 하는가
장기 기억 반복 규칙, 자산화할 지식, 안정된 메모리

이 구조가 없으면 장시간 작업에서 항상 같은 문제가 반복된다.

  • 세션이 바뀌면 다시 워밍업한다
  • 중간 판단 근거가 사라진다
  • 미검증 상태가 사실처럼 남는다
  • 사람이 개입해도 어디서 이어야 할지 애매하다

좋은 상태 계층은 "많이 기억하는 시스템"이 아니라, 끊겨도 다시 이어붙일 수 있는 시스템을 만든다.

5. 4계층: 경계는 제약이 아니라 품질 장치다

네 번째 계층은 경계다. 에이전트 시스템을 처음 만들 때는 경계를 답답한 제약처럼 느끼기 쉽다. 하지만 운영으로 갈수록 해석이 바뀐다.

경계는 에이전트를 덜 유능하게 만드는 장치가 아니라, 덜 헷갈리게 만드는 장치다.

경계 계층은 보통 아래 질문을 다룬다.

  • 무엇을 읽을 수 있는가
  • 무엇을 수정할 수 있는가
  • 무엇은 승인 없이 실행할 수 없는가
  • 어떤 행동은 반드시 사람에게 넘겨야 하는가
  • 외부 전송과 내부 수정은 같은 위험도로 볼 수 있는가

좋은 경계 계층은 추상적 경고보다 구조적 차단에 가깝다.

경계 유형 목적
범위 경계 어느 파일과 자원까지 다룰 수 있는지 제한
권한 경계 읽기, 쓰기, 실행, 전송의 위험도 분리
승인 경계 사람이 확인해야 하는 행동을 분리
소유 경계 누가 최종 판단과 자산화를 책임지는지 명시

이 계층이 약하면 모델이 잘못된 결정을 한 번 내렸을 때 실패 반경이 급격히 커진다. Anthropic의 권한 문서가 hooks, allow/deny rules, canUseTool, permission mode를 함께 두고, OpenAI Agents SDK가 input/output/tool guardrail을 구분하는 이유도 여기 있다. 반대로 경계가 선명하면 같은 모델이라도 훨씬 안정적으로 운영된다.

6. 5계층: 관측성은 로그 수집이 아니라 실패를 설명하는 능력이다

다섯 번째 계층은 관측성이다. 이 층은 종종 가장 나중에 붙지만, 장시간 운영에서는 오히려 앞단 설계에 가깝다.

이유는 간단하다. 관측성이 없으면 실패를 모델 탓으로 뭉뚱그리게 되기 때문이다.

좋은 관측성 계층은 최소한 아래 질문에 답할 수 있어야 한다.

  • 에이전트가 어떤 입력을 근거로 행동했는가
  • 어떤 도구를 어떤 순서로 호출했는가
  • 실패는 모델 판단 실패인가, 도구 실패인가, 정책 차단인가
  • 어느 단계에서 지연과 비용이 커졌는가
  • 다음 개선은 프롬프트, 도구, 상태, 경계 중 어디를 만져야 하는가

좋은 관측성은 "모든 로그를 남긴다"와 다르다. 오히려 운영에 필요한 신호를 선별해야 한다.

  • 입력 우선순위
  • 도구 호출 이력
  • 체크포인트 상태
  • 승인/차단 이벤트
  • 검증 결과

즉 관측성 계층의 핵심은 기록량이 아니라 설명력이다.

7. 다섯 계층은 따로 좋아도, 함께 배치가 틀리면 무너진다

이 다섯 계층은 체크리스트처럼 따로 존재하는 것이 아니다. 서로를 강하게 바꾼다.

예를 들면:

  • 컨텍스트 계층이 과도하게 길면 도구 선택 품질이 떨어진다.
  • 도구 출력이 너무 길면 상태 계층이 대화 안으로 빨려 들어간다.
  • 상태를 외부화하지 않으면 관측성은 남아도 재개 비용은 줄지 않는다.
  • 경계가 추상적 경고뿐이면 관측성은 실패를 설명해도 실패를 막지 못한다.

그래서 좋은 런타임은 다섯 계층을 각각 "최적화"하기보다, 서로 충돌하지 않게 접합한다.

간단히 요약하면 이런 구조에 가깝다.

계층 좋은 질문
컨텍스트 지금 반드시 보여야 하는 것은 무엇인가
도구 지금 고르기 쉬운 행동 표면은 무엇인가
상태 다음 세션이 바로 이어받을 수 있는가
경계 잘못된 행동을 어디서 멈추는가
관측성 실패 원인을 다시 설명할 수 있는가

이 질문에 모두 답할 수 있어야 런타임이 단단해진다.

8. 흔한 실패 패턴은 계층 누락보다 계층 혼합에서 나온다

현장에서 더 자주 보이는 실패는 "한 계층이 없다"기보다 "서로 다른 계층을 한 군데에 밀어 넣었다"는 문제다.

긴 지시 파일 하나로 모든 걸 해결하려 한다

컨텍스트, 상태, 경계를 한 문서에 섞으면 우선순위가 흐려진다.

만능 도구에 권한까지 몰아 준다

도구 계층과 경계 계층이 분리되지 않으면 오선택 비용이 커진다.

상태를 대화 이력에만 남긴다

재개 구조가 없어서 장시간 작업이 반복적으로 끊긴다.

로그만 쌓고 설명 구조가 없다

관측성은 생긴 것 같지만, 무엇을 개선해야 하는지는 여전히 불명확하다.

좋은 런타임은 다섯 계층을 많이 만드는 것이 아니라, 섞지 않아야 할 것을 분리하는 것에서 시작한다.

9. 실무 적용: 좋은 에이전트 런타임을 만들기 위한 최소 체크리스트

처음부터 거대한 프레임워크가 필요한 것은 아니다. 아래 질문만으로도 설계 상태를 빠르게 점검할 수 있다.

  1. 항상 보이는 규칙과 필요 시 읽는 자료가 분리되어 있는가
  2. 도구 이름, 설명, 입력, 출력이 선택 비용을 낮추는가
  3. 현재 목표와 재개 포인트가 대화 밖에 남아 있는가
  4. 읽기, 수정, 실행, 외부 전송의 경계가 분리되어 있는가
  5. 실패했을 때 원인을 계층별로 설명할 수 있는가

이 다섯 질문에 막히는 지점이 있다면, 대개 그곳이 지금의 런타임 병목이다.

10. 결론: 좋은 에이전트는 좋은 모델 위에서가 아니라 좋은 런타임 안에서 나온다

에이전트 시대에 모델 선택은 여전히 중요하다. 하지만 같은 모델을 써도 팀마다 결과 차이가 크게 나는 이유는 점점 더 런타임에서 설명된다.

좋은 런타임은 아래 다섯 층이 선명하다.

  • 컨텍스트는 언제 무엇을 보여 줄지 안다
  • 도구는 무엇을 고르기 쉬운지 안다
  • 상태는 어디서 다시 시작할지 안다
  • 경계는 어디서 멈춰야 하는지 안다
  • 관측성은 무엇이 왜 실패했는지 안다

결국 좋은 에이전트 런타임은 화려한 기능 묶음이 아니라, 에이전트가 덜 헷갈리고 덜 위험하게 더 오래 일할 수 있게 만드는 작업 환경이다.

모델이 점점 상향 평준화될수록, 경쟁력은 더 많이 "무엇을 호출하는가"보다 "어떤 런타임 안에서 호출하는가" 쪽으로 이동할 가능성이 크다.

함께 읽으면 좋은 글

참고 자료

시리즈 전체 안내: 시리즈 목차

댓글

댓글 쓰기

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/6 파인튜닝 → 트랜스포머 한 블록의 데이터 흐름을 문자열 → 토큰 → 임베딩 → 어텐션 → 출력 표현 까지 손으로 풀어 본다. 이번 편이 끝나면 "왜 \(\sqrt{d_k}\)로 나누는가", "RoPE는 무엇을 회전시키는가", "한국어가 영어보다 토큰이 많은 까닭은 무엇인가"가 한 줄로 설명될 수 있다. 0. 학습 목표 이 편을 마치면 다음을 직접 할 수 있다. BPE 토크나이저 가 어휘를 어떻게 학습하고 새 문자열을 어떻게 자르는지 종이 위에서 시뮬레이션한다. 임베딩 행렬 의 모양과 초기화, weight tying의 의미를 한 줄로 설명한다. Scaled Dot-Product Attention 의 식을 차원 단위로 추적하고 PyTorch 30줄로 재현한다. Multi-Head Attention 이 한 헤드와 비교해 무엇이 다른지, 헤드 수가 늘면 어디가 비싸지는지 답한다. Sinusoidal·RoPE·ALiBi 세 위치 인코딩의 식과 외삽 성질을 구분한다. 컨텍스트 확장이 왜 \(O(N^2)\)인지, "Lost in the Middle"이 왜 발생하는지 설명한다. 1. 핵심 요약 트랜스포머의 입력은 문자열 이 아니라 정수 ID 시퀀스 다. 토크나이저가 문자열 → ID로 자른다. 임베딩은 정수 ID를 \(d\)차원 벡터로 lookup하는 학습 가능한 테이블이다. Self-Attention은 \(\text{softmax}(QK^\top / \sqrt{d_k}) V\) 한 줄이 핵심이고, 멀티헤드는 같은 연산을 여러 부분 공간에서 병렬화한 것이다. 위치 정보는 임베딩에 직접 더하거나(Sinusoidal), Q·K에 회전을 가하거나(RoPE), 어텐션 스코어에 거리 패널티를 더해서(ALiBi) 주입한다. 컨텍스트 길이 \(N\)에 대해 표준 어텐션은 \(O(N^2)\) 비용을 갖고, 긴 컨텍스트에서는 중간 위...
Read more »

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

-
이미지
← 1/6 기본 📚 시리즈 목차 3/6 디코딩과 생성 → 사전학습된 LLM을 내 데이터 에 적응시키는 방법을 비용·메모리·일반화 관점에서 정리한다. Full FT의 한계 → Adapter → LoRA → QLoRA → Distillation 순으로 같은 그림을 점점 확대해 본다. 0. 학습 목표 Full fine-tuning의 메모리 병목을 옵티마이저 상태·그래디언트·가중치·활성화 의 4분할로 설명한다. Adapter(Houlsby 2019)와 LoRA(Hu 2021)의 식 차이를 한 줄로 적는다. LoRA의 \(A, B\) 행렬이 왜 저랭크 이고, rank \(r\) 선택이 무엇을 결정하는지 답한다. QLoRA(Dettmers 2023)의 NF4·double-quant·paged optimizer를 분리해서 설명한다. Catastrophic Forgetting을 분포 시프트 관점에서 정의하고 완화 기법을 두 개 이상 든다. Hinton 2015의 Knowledge Distillation 식을 손으로 유도한다. 1. 핵심 요약 Full FT는 메모리/디스크/시간 모두 비싸다. 7B 모델 full FT는 V100 8장 + A100 1장으로도 큰 부담이다. PEFT(파라미터 효율 파인튜닝) 일가족은 극히 일부 파라미터만 학습 해 같은 효과를 얻는다. LoRA: \(\Delta W = BA\) (rank \(r \ll \min(d_{\text{in}}, d_{\text{out}})\))로 가중치 업데이트를 저랭크 분해. QLoRA: 베이스 모델을 4-bit(NF4)로 양자화한 채 LoRA만 풀-정밀(BF16)으로 학습. Catastrophic Forgetting: 새 분포에 적응하느라 이전 능력이 무너지는 현상. PEFT 자체가 부분 완화책. Distillation: 큰 교사 모델의 soft target 을 학습 신호로 써서 작은 학생 모델 을 만든다. 2. 직관: 왜 사전학습만으로는 부족한가 사전학습은 일반...
Read more »

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/9 이웃 알고리즘 → 이 시리즈는 신경망과 로컬 LLM으로 가기 전에 손에 익혀 둬야 할 머신러닝 기초 9편이다. 1편은 모든 ML 코드가 공유하는 공통 문법 을 잡는 데 쓴다. sklearn은 그 문법을 가장 일관되게 보여주는 도구다. 이번 편이 끝나면 어떤 모델을 만나도 fit → predict → score → 평가 흐름이 같다는 것이 손에 잡힌다. 0. 학습 목표 이 편을 마치면 다음을 할 수 있어야 한다. 지도학습·비지도학습·강화학습을 한 문장씩 구분해 설명한다. sklearn의 estimator 인터페이스 ( fit , predict , score , transform )를 코드 한 화면 안에서 쓸 수 있다. train/validation/test 분할을 왜 하는지, 어디서 데이터 누수가 생기는지 식과 그림으로 설명한다. 분류·회귀의 핵심 평가 지표(accuracy, precision, recall, F1, MSE, R²)를 정의에서 직접 계산할 수 있다. k-fold 교차검증 을 코드 한 줄로 돌리고, 결과의 평균과 표준편차를 함께 보고할 수 있다. Pipeline 으로 전처리와 모델을 묶어 데이터 누수를 구조적으로 막는 방법을 설명한다. 1. 핵심 요약 머신러닝은 데이터에서 함수 \(f: X \to Y\)를 찾는 작업 이다. 어떤 모델이든 이 본질은 같다. sklearn은 모든 모델을 같은 인터페이스( fit , predict , score )로 통일해, 모델을 바꿀 때 한 줄만 바꾸면 되게 한다. train/val/test 세 분할이 표준이다. 검증으로 하이퍼파라미터를 고르고, 테스트는 마지막에 한 번만 본다. 데이터 누수 (test 정보가 train에 새는 현상)는 ML 입문자가 가장 자주 만드는 실수이며, Pipeline + cross_val_score 조합으로 구조적으로 막을 수 있다. 평가 지표는 문제 유형 (분류/회귀) 과 클래스 불균형...
Read more »