에이전트 런타임 이벤트 모델

프레임워크 전쟁은 주의 분산이다

엔지니어들은 계속 저에게 어떤 에이전트 프레임워크를 선택해야 할지 묻습니다. LangChain인지 CrewAI인지 아니면 직접 구축할 것인지 말이죠. 이는 가장 먼저 던져서는 안 되는 질문입니다. 실제로 복합적으로 작용하는 아키텍처적 선택은 프레임워크 선택이 아닙니다. 바로 에이전트 런타임 내부에 정책(policy)을 연결할 수 있는 지점입니다.

지난 18개월 동안 제가 배포한 모든 프로덕션 에이전트 스택은 동일한 결론으로 수렴했습니다: 네 가지 런타임 이벤트, 네 가지 정책 연결 표면(policy-attachment surfaces), 그리고 각 이벤트에서 확보할 수 있는 후크 커버리지(hook coverage)가 데모와 규제 대상 구매자가 서명할 만한 제품을 가르는 기준입니다.

여기에 분류 체계(taxonomy), 각 이벤트가 방지하는 버그 클래스, 그리고 이번 주에 어떤 에이전트 스택에도 적용해 볼 수 있는 세 가지 질문의 감사 목록을 제시합니다.

이벤트 모델이란 무엇인가

배포할 가치가 있는 모든 프로덕션 에이전트 런타임은 소수의 정책 연결 이벤트를 노출합니다. 아래 분류 체계는 제가 매일 작업하는 개발자 측 에이전트 런타임인 Claude Code의 후크 모델에서 가져온 것입니다: UserPromptSubmit, PreToolUse, PostToolUse, Stop. 저는 SaaS가 실행되는 서버 측 에이전트 스택에서도 동일한 네 가지 이벤트 모델을 채택하여 해당 런타임에 매핑했습니다. 이름은 Claude Code의 것이지만, 아키텍처 패턴은 이식성이 있습니다. LangChain은 유사한 표면을 각각 on_chat_model_start / on_tool_start / on_tool_end / on_agent_finish라고 부릅니다. OpenAI의 Agents SDK는 이를 on_agent_start / on_tool_start / on_tool_end / on_agent_end라고 부릅니다. 이름은 다릅니다. 하지만 연결 표면과 그들이 방지하는 버그는 동일합니다.

UserPromptSubmit — 프롬프트가 모델에 도달하기 전.
PreToolUse — 에이전트가 선택한 도구가 실행되기 전.
PostToolUse — 도구가 반환된 후, 모델이 출력을 보기 전에.
Stop — 에이전트가

각 이벤트는 고유한 의미론(semantics)을 가진 정책 부착 지점(policy-attachment surface)이며, 이러한 차이점이 바로 여러분이 설계를 고민해야 할 지점입니다. 지연 시간 예산(latency budget)은 각기 다릅니다. UserPromptSubmit은 사용자의 입력 경로(input path)에 위치하므로 한 자릿수 밀리초(ms) 내에 실행되어야 하는 반면, Stop은 사용자가 이미 입력을 제출하고 읽고 있는 상태이므로 1초 정도 소요되어도 괜찮습니다. 이러한 격차 때문에 입력 경로 이벤트에서는 동기적인 심층 검사(synchronous deep check)를 수행할 수 없습니다. 입력 경로에서는 빠르게 실패(fail fast)하고, 실제 검증은 비용을 감당할 수 있는 Stop 단계로 미뤄야 합니다. 훅(hook)이 차단될 때의 실패 모드(failure modes) 또한 다릅니다. 데이터 형태(data shape)도 마찬가지입니다. 프롬프트 이벤트는 가공되지 않은 사용자 텍스트를 보고, 도구 실행 전(pre-tool) 이벤트는 계획된 도구 호출(tool invocation)을 보며, 도구 실행 후(post-tool) 이벤트는 도구의 반환 페이로드(return payload)를 보고, Stop 이벤트는 전체 기록(transcript)을 봅니다.

아키텍처 측면에서의 질문은 "어떤 프레임워크를 쓸 것인가"가 아닙니다. "내 런타임이 실제로 이 네 가지 이벤트 중 무엇을 노출하는가, 그리고 각 이벤트에서 어떤 정책 커버리지(policy coverage)를 확보할 수 있는가?"입니다.

이 모델은 Express 미들웨어(middleware)보다는 오히려 관점 지향 인터셉터(aspect-oriented interceptor, AOP interceptor)에 가깝지만, 어느 쪽과도 완벽하게 일치하지는 않습니다. 미들웨어는 고정된 요청-응답(request-response) 형태를 중심으로 구성되지만, AOP 인터셉터는 하나의 메서드 호출을 감쌉니다. 훅(hook)은 런타임에 의해 정의된 명명된 라이프사이클 이벤트(lifecycle event)에 부착되며, 런타임의 디스패처(dispatcher)가 실행 시점과 실행 여부를 결정합니다. 페이로드 형태는 이벤트별로 특화되어 있으며, 여러분이 지켜야 할 유일한 계약(contract)은 종료 코드(exit code)와 변형된 페이로드(mutated payload)뿐입니다.

프레임워크가 대신 결정해 줄 수 없는 한 가지가 있습니다. 바로 훅(hook) 자체가 충돌(crash)했을 때 어떤 일이 일어날 것인가 하는 점입니다. 개인정보(PII) 삭제기나 비밀 정보 유출 차단기는 반드시 '실패 시 차단(fail closed)' 방식으로 동작해야 합니다. 자격 증명이 유출되는 것보다는 요청이 거부되는 편이 낫기 때문입니다. 반면, 일반적인 응답을 제어하는 완전성 검증기(completeness verifiers)는 '실패 시 허용(fail open)' 방식으로 동작해야 합니다. 분류기(classifier)가 충돌했다고 해서 사용자가 응답을 받는 것을 막아서는 안 됩니다. 예외가 규칙을 증명합니다. 만약 Stop 이벤트가 마이그레이션이나 배포와 같은 파괴적인 동작을 제어한다면, 대신 '실패 시 차단'하고 경고를 보내야 합니다. 훅의 실패 모드는 인프라의 문제가 아니라 정책의 문제입니다. 이를 잘못 결정하면 보안 취약점(security hole)을 배포하거나 서비스 거부(denial-of-service) 상태를 초래하게 됩니다.

각 이벤트가 방지하는 버그의 유형

UserPromptSubmit

이 이벤트는 패턴 매칭(pattern matching)과 미확인 형식에 대한 엔트로피 점수(entropy scoring)를 사용하여 프롬프트 내의 비밀 정보(secrets)를 강력하게 차단하며, 지연 시간 예산(latency budget)이 허용될 경우 고가치 패턴(Stripe, AWS, GitHub)에 대해 제공자 검증(provider verification)을 수행합니다. 비밀 저장소에 심어둔 카나리 토큰(canary token)은 두 가지 방식을 모두 통과하는 드문 유출 사례를 포착합니다. 만약 해당 토큰이 제출된 프롬프트에 나타난다면, 실제 자격 증명(credential)도 동일한 경로를 거쳤음을 의미합니다. 또한 개인정보(PII)를 가역적인 플레이스홀더(reversible placeholders)로 토큰화하여, 모델이 실제 주소 대신 ⟪PII_email_42⟫를 바탕으로 추론하도록 합니다. 실제 사례: 제가 출시 중인 SaaS에서 일주일 동안 코드 리뷰를 세 번이나 통과했던 자격 증명 유출 유형이 이 기능이 연결된 후 더 이상 불가능해졌습니다. 훅(hook)은 종료 코드(exit 2)를 반환하며 프롬프트는 제공자에게 도달하지 않습니다. 동일한 유출 사례를 누군가 기억하고 수행해야 하는 리뷰 단계가 아닌, 런타임(runtime)에서 포착하게 됩니다.

PreToolUse

도구 호출(tool-call) 단위의 비용 예산(cost-budget) 집행: 일별, 작업별, 도구별로 적용됩니다. 파일 읽기에 대한 차단 목록(blocklist) 집행(예: .env* 금지, 자격 증명 파일 금지, 비밀 정보가 포함된 렌더링된 설정 파일 금지). 적대적(adversarial) 또는 신뢰할 수 없는 입력(untrusted-input) 컨텍스트에서의 도구 화이트리스트(whitelisting) 적용. 이는 "에이전트가 무엇이든 할 수 있다"를 "에이전트가 정책이 허용하는 것만 할 수 있다"로 바꾸는 이벤트입니다. 명확히 언급할 주의 사항이 하나 있습니다: 이것은 정책 경계(policy boundary)이지, 격리 경계(isolation boundary)가 아닙니다. 진정으로 신뢰할 수 없는 코드 실행을 위해서는 여전히 하단에 OS 수준의 샌드박싱(sandboxing, 예: gVisor, Firecracker)이 필요합니다. 훅은 무엇이 허용될지를 결정하고, 샌드박스는 잘못된 상황을 격리합니다.

PostToolUse

모델이 도구 출력(tool output)을 흡수하기 전, 표준 출력(stdout)에 대한 개인정보(PII) 삭제(redaction). 보안 검토자에게 전달할 수 있는 해시 체인(hash chain)이 포함된 컴플라이언스 감사 로그(compliance audit log). 인젝션 스캔(Injection-scan): 프롬프트 인젝션(prompt injection)처럼 보이는 도구 출력은 대화에 다시 진입하기 전에 제거되며, 이는 순수 시스템 프롬프트 방어로는 도달할 수 없는 간접 프롬프트 인젝션(indirect prompt injection) 유형을 차단합니다.

Stop

완결성 검증 (Completeness verification). 작은 분류기 (classifier)가 사용자의 항목들을 읽고 각 항목이 처리되었는지 확인합니다. 저희의 배포 사례에서는 약 2주간의 튜닝을 거친 후, 오탐률 (false-positive rate)이 8% 근처에서 안정되었습니다. 따라서 저희는 이를 강제 차단 (hard block)이 아닌 소프트 경고 (soft warning)로 취급합니다. 비용 계산은 관대합니다. 작은 분류기는 턴당 약 $0.001 (Haiku 가격 기준, 입력 토큰 약 500개)로 실행되므로, 스팸성 패턴인 "다음에 할게요" (I'll do that next) 유형 20개 중 단 하나만 잡아내도 비용을 여러 배 상회하는 가치를 얻습니다. 테스트 재실행 게이팅 (Test re-run gating) 또한 에이전트가 완료를 선언하기 전 이 단계에 위치합니다.

이것이 프레임워크 선택보다 우월한 이유

훅 (Hooks)은 프레임워크에 구애받지 않습니다 (framework-agnostic). 계약의 대상은 프레임워크 API가 아니라 런타임 이벤트 (runtime event)입니다. 하나의 프레임워크를 다른 것으로 교체하더라도, 이미 연결해 둔 정책 로직 (policy logic)은 여전히 적용됩니다. 즉, 정책 자체를 다시 쓰는 것이 아니라 각 런타임의 페이로드 (payload)를 추출하는 얇은 통합 접착제 (integration glue)만을 다시 작성하면 됩니다. 이는 전체 아키텍처를 재설계하는 것에 비하면 극히 일부에 불과합니다.

경제적 논거는 더욱 명확합니다. 프레임워크 선택은 생태계가 변화함에 따라(새로운 진입자, 더 나은 추상화, 몇 년마다 발생하는 마이그레이션 등) 다시 검토하게 될 결정입니다. 하지만 훅 커버리지 (Hook coverage)는 그 모든 것보다 오래 지속됩니다. 왜냐하면 훅에 연결된 정책들이 계속 늘어나더라도, 그 훅이 사용하는 네 가지 이벤트는 변하지 않기 때문입니다.

OWASP의 2023년 첫 번째 LLM Top 10에서도 이미 이 점이 지적되었으며, 2025년 업데이트에서 더욱 날카로워졌습니다. 10개 항목 중 4개인 프롬프트 인젝션 (Prompt Injection, LLM01), 민감 정보 노출 (Sensitive Information Disclosure, LLM02), 부적절한 출력 처리 (Improper Output Handling, LLM05), 과도한 권한 (Excessive Agency, LLM06)은 모두 런타임 제어 (runtime-control) 문제입니다. 이 중 어느 것도 프레임워크 선택의 문제가 아닙니다. 논의의 초점은 정책을 실제로 부착할 수 있는 한 단계 아래 계층으로 이동했습니다.

세 가지 질문의 감사 (audit)

모든 프로덕션 에이전트 스택에 대해 던져야 할 세 가지 질문입니다:

당신의 비밀 정보 유출 방지(secret-leak prevention) 기능은 어떤 이벤트에 연결되어 있습니까? 만약 없다면, 당신은 모든 팀이 최소 한 번은 겪어본 알려진 유출 표면(leak surface)을 가진 채 제품을 출시하고 있는 것입니다. (OWASP LLM02: 민감 정보 노출 (Sensitive Information Disclosure).)
완료에 대한 거짓말, 즉 에이전트가 완료하지 않았음에도 완료했다고 말하는 상황을 잡아내는 이벤트는 무엇입니까? 만약 없다면, 사용자 신뢰는 눈에 보이지 않게 침식되며, 결국 이탈률(churn)이 급증할 때까지 그 이유를 추적할 수 없게 됩니다. (아직 OWASP 항목은 없습니다. 이는 표준이 아직 따라잡지 못한 공백입니다.)
모델이 데이터를 재섭취(reingest)하기 전에 도구 출력물(tool outputs) 내의 개인정보(PII)를 감사(audit)하는 이벤트는 무엇입니까? 만약 없다면, 규제 산업 분야에서는 데모가 아무리 인상적이더라도 당신의 스택을 배포할 수 없습니다. (OWASP LLM02 + LLM05: 부적절한 출력 처리 (Improper Output Handling).)

프레임워크는 범용화(commodity)되고 있습니다. 당신의 훅(hook) 커버리지가 바로 해자(moat)입니다.

출처 (Sources)

Claude Code Hooks 레퍼런스 — https://code.claude.com/docs/en/hooks (권위 있는 이벤트 표면, 페이로드 형태, 종료 코드 의미론)
LangChain Callbacks (BaseCallbackHandler) — https://reference.langchain.com/python/langchain-core (프레임워크 간 매핑)
OWASP Top 10 for LLM Applications 2025 — https://genai.owasp.org/llm-top-10/ (런타임 이벤트에 대한 LLM01 / LLM02 / LLM05 / LLM06 매핑)
NIST AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework (Generative AI Profile, NIST-AI-600-1, 2024년 7월 — 이 프레임워크의 govern/map/measure/manage 기능은 조직 및 라이프사이클 수준에 위치합니다. 이러한 런타임 이벤트는 NIST가 정의하는 곳이 아니라, 해당 통제 항목들이 실행(operationalized)되는 한 지점입니다)
Microsoft Presidio — Anonymizer — https://microsoft.github.io/presidio/anonymizer/ (가역적 PII 토큰화 패턴)

Trufflehog — verifier 기반 비밀 탐지 도구 — https://github.com/trufflesecurity/trufflehog (2026년 자격 증명 스캐닝 산업 표준)
7. Greshake 등, "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection" — https://arxiv.org/abs/2302.12173 (PostToolUse 주입-스캔 주장க்கான 학술적 근거)
8. Anthropic Claude 가격 책정 — https://platform.claude.com/docs/en/about-claude/pricing (턴당 약 $0.001 비용 수치 확인)