TL;DR

• LLM 및 그 주변 기술이 성숙해짐에 따라, 병목 현상(bottleneck)은 LLM의 외부로 이동한다
• prompt / context / agent / harness라는 4가지 engineering 레이블은 이러한 이동의 흔적으로 읽을 수 있다
• 이는 대체가 아닌 적층이다
• 동일한 메타 법칙을 적용하면, 다음 병목 현상은 eval(평가)과 governance(거버넌스) 영역으로 이미 이동하기 시작했다

서론

prompt engineering, context engineering, agent engineering, harness engineering. 지난 1~2년 동안 '○○ engineering'이라는 레이블이 차례차례 등장했습니다. 새로운 레이블이 나올 때마다 기법과 정의를 파악해야 하는 과제가 쌓입니다.

이 4가지를 나열해 보면 공통된 패턴이 떠오릅니다. LLM 및 그 주변 기술이 성숙해짐에 따라, 병목 현상은 LLM의 외부로 이동한다는 패턴입니다. 4가지 레이블은 유행어의 교체가 아니라, 병목 현상 이동의 흔적으로 읽을 수 있습니다. 이전 레이어가 교체되는 것이 아니라, 그 위에 새로운 레이어가 쌓이는 형태로 무게 중심이 이동하고 있습니다.

Bassim Eledath의 L1-L8 분류[1]와 같이 레벨별로 나누는 정리 방식도 있지만, 본 기사에서는 병목 현상의 이동이라는 관점에서 4가지 레이블을 계보로서 정리합니다. 각 레이어가 필요하게 된 배경을 외부 연구 및 사례로 뒷받침한 뒤, 동일한 메타 법칙을 적용하여 harness 너머에서 이미 드러나기 시작한 병목 현상을 정리합니다.

병목 현상은 LLM의 외부로 밀려나고 있다

4가지 engineering 레이블의 관계를 표로 정리합니다.

각 레이어의 장은 메타 법칙인 "LLM 및 그 주변 기술이 성숙해짐에 따라, 병목 현상은 외부로 이동한다"의 구체적인 사례로 읽을 수 있습니다.

prompt engineering: "입력을 어떻게 설계할 것인가"가 제약이었던 시기

LLM 초기, 모델은 입력의 표현 방식에 민감했습니다. 입력 텍스트의 설계가 출력 품질을 크게 좌우하던 시대였습니다.

GPT-3의 few-shot learning[2]은 "예시를 몇 개 보여주는 것만으로 태스크를 수행할 수 있음"을 보여주었고, Chain-of-Thought (CoT) [3]는 "사고 과정을 쓰게 하면 추론 정밀도가 올라감"을 보여주었습니다. 이 시기의 핵심 도구는 few-shot 예문 선정, CoT 사고 과정 설계, 역할(role) 지정과 같은 입력 텍스트의 최적화였습니다.

하지만 모델의 능력이 향상됨에 따라, prompt의 표현 방식에 따른 차이는 상대적으로 작아지고 있습니다. Wharton GenAI Labs의 조사에 따르면, reasoning model (o3-mini, o4-mini, Gemini 2.5 Flash)에 CoT를 추가해도 상당한 시간 비용 증가에 비해 개선 효과는 제한적이라고 보고되었습니다[4].

CoT의 효과가 체감될 뿐만 아니라, 더 세련된 prompt 기법이 오히려 역효과를 내는 사례도 등장하고 있습니다. Khan의 "Prompting Inversion" 연구[5]가 바로 그것입니다. Sculpting(규칙 기반의 제약을 부여하여 의미적 모호함을 줄이는 prompt 기법)은 gpt-4o에서는 standard CoT를 상회했습니다 (97% vs 93%). 그러나 gpt-5에서는 역전되어, standard CoT는 96%인 반면 Sculpting은 94%로 떨어졌습니다. 모델 능력의 향상에 따라 제약을 가하는 prompt 기법이 오히려 발목을 잡는 현상을 Khan은 "Prompting Inversion"으로 정식화했습니다.

모델이 똑똑해짐에 따라 입력의 표현 방식에 의존할 필요는 줄어들었습니다. 대신 부상한 것은 "컨텍스트를 어떻게 구성할 것인가"라는 문제입니다.

context engineering: "컨텍스트를 어떻게 구성할 것인가"가 제약이 된 시기

컨텍스트 윈도우 (Context Window)가 수십만~100만 토큰 규모로 확대되면서, 토큰 상한 제약은 크게 완화되었습니다. 하지만 컨텍스트 윈도우가 넓어져도 정보를 많이 채워 넣을수록 성능은 떨어집니다. Microsoft와 Salesforce의 공동 연구에서는 멀티턴 (Multi-turn) 대화에서 평균 -39%의 성능 저하가 보고되었으며, o3조차 98.1% → 64.1%까지 떨어졌다고 합니다[6].

Anthropic은 2025년 9월 기사에서 context engineering을 다음과 같이 정의했습니다[7].

"the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts."

즉, "추론 시의 최적의 토큰 집합(정보)을 선별 및 유지하는 전략군이며, 프롬프트 이외에 컨텍스트에 포함될 수 있는 모든 정보를 포함한다"는 정의입니다. 해당 기사에서는 3가지 기법을 제시했습니다. 커뮤니티에서도 다른 관점에서 기법들이 언어화되고 있습니다.

context engineering 레이어에서는 RAG나 서브 에이전트 분리(Sub-agent separation)와 같이 여러 컴포넌트를 가로지르는 설계가 요구됩니다. 지식 베이스 정비, 검색 기반, 전처리 파이프라인 등 설계의 범위가 확장된 단계입니다.

여기까지는 "컨텍스트를 어떻게 구성할 것인가"에 대한 이야기였습니다. 컨텍스트 구성이 갖춰지면, LLM은 단발성 응답을 넘어 여러 턴에 걸쳐 자율적으로 움직이는 에이전트 (Agent)로 사용되기 시작합니다. 그러면 이번에는 "에이전트의 추론 루프 (Reasoning loop)를 어떻게 설계할 것인가"가 병목 (Bottleneck)이 됩니다.

agent engineering: 「에이전트의 추론 루프를 어떻게 설계할 것인가」가 병목이 된 시기

컨텍스트 구성이 갖춰진 단계에서, LLM은 observe → think → act 사이클을 자율적으로 돌리는 에이전트로 사용되기 시작했습니다. 병목은 "어떤 정보를 전달할 것인가"에서 "에이전트의 추론·행동 루프를 어떻게 설계할 것인가"로 이동합니다.

Yao 등의 ReAct[8]는 추론 (Reasoning)과 행동 (Acting)을 번갈아 반복하는 패턴을 정식화하여 에이전트 설계의 기본 형태가 되었습니다. OpenAI의 Assistants API, Anthropic의 tool use API와 같은 플랫폼 기능이 뒤를 이었고, 도구 호출 (Tool use)을 포함한 에이전트 구축이 표준화되어 갑니다.

이 시기의 핵심 과제는 에이전트가 언제 도구를 호출할지, 어떻게 계획을 세울지, 실패로부터 어떻게 복구할지 등 추론 루프 그 자체의 설계였습니다.

개별 에이전트의 추론 루프가 정형화되면, 다음에는 다른 문제가 부상합니다. 에이전트를 프로덕션 환경에서 안정적으로 구동하기 위해서는 샌드박스 격리 (Sandbox isolation), 실행 스케줄링, 장애 복구 등 에이전트 외부의 실행 환경이 필요합니다.

harness engineering: 「에이전트를 어떻게 제어할 것인가」가 병목이 되고 있는 시기

에이전트의 추론 루프가 성숙함에 따라, 개별 에이전트의 설계보다 그 실행 환경을 어떻게 구성하느냐가 성능을 좌우하게 되었습니다.

Philipp Schmid (Hugging Face / Google DeepMind)는 다음과 같은 비유를 들었습니다[9].

Model = CPU

Context Window = RAM

Agent Harness = OS

Agent = Application

모델이 CPU처럼 안정적인 부품이 됨에 따라, OS에 해당하는 하네스 (Harness) 설계가 성능을 좌우한다는 견해입니다.

Aparna Dhinakaran (Arize AI)는 다른 각도에서 하네스를 애플리케이션 그 자체로, 샌드박스를 서버에 비유하고 있습니다[10]. 나아가 framework와 harness의 경계에 대해, 프레임워크 (LangChain, LangGraph 등)는 인간이 에이전트를 만들기 위한 도구이며, 하네스는 에이전트가 구동되는 환경 그 자체라고 정의합니다[11].

Birgitta Böckeler는 martinfowler.com의 기사[12]에서 하네스(Harness)의 구성 요소를 두 축으로 분류했습니다. 세로축은 "에이전트를 올바른 방향으로 이끄는 메커니즘 (Guides)"와 "에이전트의 행동을 감지하는 메커니즘 (Sensors)"입니다. 가로축은 "코드나 규칙으로 결정적으로 제어하는가 (Computational)" 또는 "LLM의 추론에 맡기는가 (Inferential)"입니다.

예를 들어, formatter(좌측 상단)는 에이전트의 판단을 거치지 않고 기계적으로 코드를 정렬합니다. 반면, AGENTS.md(우측 상단)는 에이전트가 읽고 해석해야 합니다. 하네스 설계에서는 이 4분면을 어떻게 조합하느냐가 관건입니다.

정량적인 뒷받침

Harvey(리걸 AI)는 자사 블로그[13]에서 모델을 바꾸지 않고 하네스만 개수함으로써 대폭적인 정확도 향상을 달성했다고 보고했습니다. 다만, Harvey 스스로 "This is a small-scale experiment"라며 한계성을 인정했습니다. 그럼에도 모델이 아닌 하네스가 성능을 결정한 사례로서 시사하는 바가 큽니다. 이후 Legal Agent Benchmark (LAB)로서 1,200개 이상의 태스크와 24개 법무 영역을 커버하는 벤치마크를 OSS(Open Source Software)화했습니다[13:1].

OpenAI의 Codex 팀 실험[14]도 같은 방향을 가리키고 있습니다. 5개월 동안 100만 행 이상의 코드를 생성했으며, 3명에서 7명 규모의 팀이 약 1,500개의 PR, 하루 평균 3.5개의 PR, 약 10억 토큰을 소비했습니다. 엔지니어의 역할은 "코드를 작성하는 것"에서 "환경 설계, 의도의 명문화, 피드백 루프 구축"으로 이동하고 있습니다.

업계지에서도 같은 관점이 나오고 있습니다. "서로 다른 연구소의 프론티어 모델(Frontier Model) 간의 차이는 대폭 축소된 반면, 동일한 모델의 잘 설계된 하네스(well-designed harness) 유무에 따른 차이는 극적으로 확대되었다"[15]. 본 기사의 주장, 즉 병목 현상이 LLM의 외곽으로 이동하고 있다는 견해와 일치하는 분석입니다.

harness engineering 레이어에서는 Harvey처럼 조직 전체가 하네스를 개수하는 규모가 되었으며, Böckeler의 4분면은 애초에 여러 설계자의 분업을 전제로 구성되어 있습니다. 팀의 규율로서 운용되는 단계에 진입했습니다.

이렇게 에이전트를 프로덕션에서 구동하기 위한 기반이 갖춰지고 있습니다. 여기까지가 실천과 외부 사례로 뒷받침된 4개 레이어의 계보입니다. 그렇다면 병목 현상은 여기서 멈출까요? 동일한 메타 법칙을 적용하면 그 너머도 보입니다.

그 너머: 병목 현상은 더욱 외곽으로

eval(평가)과 governance(거버넌스) 정리에 들어가기에 앞서, harness 레이어에서 일어나고 있는 변화를 짚어둡니다.

Anthropic은 2026년 4월에 Claude Managed Agents[16]를 퍼블릭 베타로 공개했습니다. 샌드박스 격리, 툴 오케스트레이션(Tool Orchestration), 에러 복구 등 지금까지 팀마다 자체적으로 설계해야 했던 하네스의 난제들을 플랫폼 측에서 PaaS(Platform as a Service)로서 흡수하기 시작했습니다. 유사한 움직임은 OpenAI의 Responses API(code interpreter나 file search를 내장 툴로 제공), LangGraph Platform(에이전트의 배포 및 오케스트레이션을 PaaS화), Vercel AI SDK(프레임워크 레벨에서 하네스 프리미티브를 제공)에서도 진행 중입니다. 하네스의 범용화(Commodity)는 한 회사의 움직임이 아니라, 플랫폼들 사이에서 동시다발적으로 일어나고 있습니다.

이러한 움직임은 이전 레이어에서 일어났던 일의 반복입니다. 모델의 능력 향상이 prompt의 표현 차이를 흡수했듯이, 플랫폼의 성숙이 harness의 설계 차이를 흡수해 나갈 것입니다. harness가 commodity(범용화)될수록 차별화의 축은 더욱 바깥쪽, 즉 무엇을 평가할 것인가, 누구에게 어떤 권한을 부여할 것인가로 옮겨갑니다.

지금까지 살펴본 메타 법칙을 적용하면, "harness 다음에 드러날 병목 현상(bottleneck)은 어디인가"를 생각할 수 있습니다. 다음은 업계에서 확립된 라벨이 아직 붙어 있지 않은 영역이지만, 기술 표준과 규제 양면에서 이미 움직임이 시작된 분야들입니다.

eval: 「출력 품질을 어떻게 정의할 것인가」

prompt · context · agent · harness의 4개 층은 모두 "에이전트가 올바르게 동작하게 만들기" 위한 고안이었습니다. harness가 갖춰지면 에이전트는 동작합니다. 하지만 동작하는 것과 좋은 결과를 내는 것은 별개의 문제입니다.

기존의 머신러닝 (Machine Learning)이라면 accuracy나 F1 등 확립된 지표가 있었습니다. 생성 AI (Generative AI)의 자유 형식 출력에서는 그렇지 않습니다. 동일한 입력에 대해 타당한 출력이 여러 개 존재할 수 있을 뿐만 아니라, 문장으로서 자연스럽더라도 사실 관계의 오류가 섞여 들어갈 수 있습니다. 지표를 선택하는 것이 아니라, 무엇을 좋다고 할 것인지에 대한 기준 그 자체를 용도별로 설계하고, 이를 검증 가능한 형태로 운영에 포함시키는 것이 필요합니다.

Galileo는 "Eval Engineering"이라는 브랜딩과 함께 eval의 CI/CD 통합을 추진하고 있습니다[17]. commit-based (커밋 기반 자동 실행), schedule-based (정기 실행), event-driven (이벤트 기반)의 세 가지 트리거로 eval을 릴리스 파이프라인에 포함시키는 방향성을 제시하고 있습니다. 2026년 4월에는 Cisco/Splunk가 Galileo의 인수를 발표하였으며[18], 이는 eval의 산업화를 보여주는 신호로 해석됩니다. "eval engineering"이라는 라벨 자체는 Galileo에서 시작된 브랜딩 성격이 강하며, Anthropic · OpenAI · Google은 모두 단순히 "evals"라고 부릅니다. 하지만 eval의 설계와 운영이 다음 병목 현상이 될 것이라는 방향성은 각 기업의 움직임을 통해서도 읽을 수 있습니다.

Amazon Bedrock의 AgentCore Evaluations[19]는 또 다른 관점을 제시합니다. OpenTelemetry / OpenInference와 통합하여 에이전트의 트레이스 (trace)를 통일된 포맷으로 변환하고, LLM-as-a-Judge 방식으로 평가합니다. 이는 observability (관측 가능성)의 문법으로 에이전트 평가를 이야기할 수 있도록 하려는 시도입니다.

eval의 자동화가 진행될수록, eval 자체의 편향 (bias)이라는 재귀적인 문제도 부상합니다. Gu 등의 서베이(survey)[20]는 LLM-as-a-Judge의 position bias, length bias, knowledge bias, concreteness bias를 체계화했습니다. Zhou 등의 연구[21]에서도 judge 모델이 다양한 편향 패턴을 보인다는 점이 보고되었습니다. eval을 자동화할수록 "eval을 eval 하는" 메커니즘이 필요해지는 재귀 구조는 이 레이어 고유의 어려움입니다.

나아가 eval은 한 번 설계하고 끝나는 것이 아닙니다. 모델의 업데이트, 참조 데이터의 변화, 이용 패턴의 확대, 업무 규칙의 개정에 따라 이전에는 적절했던 평가 기준이 더 이상 작동하지 않을 수 있습니다. 평가 기준을 운영 과정에서 지속적으로 업데이트하는 메커니즘이 요구됩니다.

governance: 에이전트 간의 가시성 격차

eval을 통해 단일 에이전트의 출력 품질을 측정할 수 있게 되었다 하더라도, 에이전트끼리 통신하는 A2A (Agent-to-Agent) 트래픽의 가시화는 그 범위에 포함되지 않습니다. A2A의 가시화를 위해서는 observability의 별도 레이어가 필요하며, 그 위에 에이전트의 identity (신원) 관리, 통신 감사 로그, 권한의 동적 제어와 같은 설계가 쌓이게 됩니다.

Gravitee의 "State of AI Agent Security 2026"[22] (919명 대상 조사)는 이러한 격차를 수치로 보여줍니다. A2A 통신에 대해 완전한 가시성 (full visibility)을 확보한 조직은 단 24.4%에 불과합니다. 에이전트를 신원 보유 엔티티 (identity-bearing entity)로 취급하는 조직은 21.9%뿐이며, 45.6%는 공유 API 키 (shared API keys)를 사용하여 에이전트 간 인증을 수행하고 있습니다. 또한, 88%가 최근 12개월 내에 에이전트 보안 사고 (agent security incident)를 경험했습니다.

기술 측면에서는, MCP Authorization Spec이 OAuth 2.1을 기반으로 에이전트 간 인증의 표준화를 추진하고 있습니다[23]. HashiCorp는 SPIFFE (워크로드 단위의 ID 프레임워크)를 AI 에이전트에 적용하여, 인간이 아닌 워크로드에 귀속되는 신원 (identity)을 발행하는 설계를 제시하고 있습니다[24]. Trend Micro는 Agentic Governance Gateway를 통해 에이전트 거버넌스 (governance)를 "신원 (identity: 누가), 권한 (authority: 어떤 권한으로), 행동 (action: 무엇을 하는가), 증거 (evidence: 어떻게 증적을 남기는가)"의 4가지 요소로 정식화했습니다[25].

규제 측면에서도 움직임이 있습니다. EU AI Act의 GPAI Code of Practice는 범용 AI 모델 제공자에게 리스크 평가 및 투명성 의무를 부과하며, 2026년 8월에 집행 (enforcement)이 시작될 예정입니다[26].

NIST 또한 2026년 2월에 AI Agent Standards Initiative를 발표했습니다[27]. 이는 CAISI (Center for AI Standards and Innovation)가 주도하며, 업계 주도의 표준 제정, MCP·A2A를 베이스라인으로 하는 오픈 소스 프로토콜의 발전 지원, 에이전트 인증 및 보안 평가의 기초 연구라는 세 가지 핵심 축으로 구성되어 있습니다. 2026년 4분기에는 에이전트 간 연동의 표준 사양인 "Agent Interoperability Profile"의 초판 출시가 예정되어 있으며, 이는 에이전트의 신원 (identity), 인가 (authorization), 감사 로그 (audit log) 처리를 표준화하는 방향을 지향합니다. 거버넌스 (governance)는 예측의 영역이 아니라, 기술 표준과 규제 양면에서 이미 형태를 갖추기 시작했습니다.

eval (평가)과 governance (거버넌스)는 모두 하네스 (harness)의 외부에서 드러나기 시작한 병목 현상입니다. 아직 정착된 엔지니어링 (engineering) 레이블은 없지만, 기술 표준과 규제 양면에서 기반이 다져지기 시작한 만큼, 이 레이어에 대한 투자 결정은 머지않은 미래에 직면하게 될 것입니다.

요약

prompt / context / agent / harness라는 네 가지 엔지니어링 (engineering) 레이블은 LLM과 그 주변 생태계가 성숙함에 따라 병목 현상이 이동한 흔적으로 읽을 수 있습니다.

• prompt → context → agent → harness 순으로, 병목 현상이 LLM의 외부로 밀려났다.
• 각 전이는 "이전 레이어에서 부족해진 부분"을 떠맡으며 발전했다. 즉, 대체가 아닌 적층이다.

동일한 메타 법칙을 적용하면, 다음 병목 현상은 이미 eval과 governance의 영역으로 이동하기 시작했습니다. 다음 레이블이 등장했을 때, 그것이 단순한 유행어인지 아니면 병목 현상 이동의 결과인지 구분하는 관점으로 본 글의 정리가 도움이 되기를 바랍니다.

Bassim Eledath "The 8 Levels of Agentic Engineering" (2026-03-10) https://www.bassimeledath.com/blog/levels-of-agentic-engineering ↩︎

Brown et al. "Language Models are Few-Shot Learners" (2020) https://arxiv.org/abs/2005.14165 ↩︎

Wei et al. "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" (2022) https://arxiv.org/abs/2201.11903 ↩︎

Meincke, Mollick et al. "The Decreasing Value of Chain of Thought" (2025) https://arxiv.org/abs/2506.07142 ↩︎

• Khan "Prompting Inversion" (2025) https://arxiv.org/abs/2510.22251 ↩︎

• Laban et al. (Microsoft + Salesforce) "LLMs Get Lost In Multi-Turn Conversation" (2025) https://arxiv.org/abs/2505.06120 ↩︎

• Anthropic "Effective context engineering for AI agents" (2025-09-29) https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ↩︎

• Yao et al. "ReAct: Synergizing Reasoning and Acting in Language Models" (2022) https://arxiv.org/abs/2210.03629 ↩︎

• Philipp Schmid "The importance of Agent Harness in 2026" (philschmid.de, 2026-01-05) https://www.philschmid.de/agent-harness-2026 ↩︎

• Aparna Dhinakaran（Arize AI Co-founder）의 하네스 관련 발신 (2026-04-19 경). 블로그나 SNS에서의 일련의 논의에 기반 ↩︎

• Aparna Dhinakaran에 의한 프레임워크(framework)와 하네스(harness)의 경계 정의 (2026-04-24 경). 블로그나 SNS에서의 일련의 논의에 기반 ↩︎

• Birgitta Böckeler "Harness Engineering for Coding Agents" (martinfowler.com, 2026-04-02) https://martinfowler.com/articles/harness-engineering.html ↩︎

• Harvey AI "Open-Sourcing Harvey's Long Horizon Legal Agent Benchmark" (2026-05-06) https://harvey.ai/blog/introducing-harveys-legal-agent-benchmark — 하네스 수정(改修)을 통한 정확도 향상 보고. Harvey 자체가 한계점을 인정함. LAB은 1,200개 이상의 태스크와 24개의 법률 영역을 커버 ↩︎ ↩︎

• Ryan Lopopolo "Harness engineering: leveraging Codex in an agent-first world" (openai.com, 2026-02-11) https://openai.com/index/harness-engineering/ ↩︎

• Tom K. "'Harness Engineering' Emerges as the Fourth Paradigm of AI Engineering" (TechTimes, 2026-05-13) https://www.techtimes.com/articles/316587/20260513/harness-engineering-emerges-fourth-paradigm-ai-engineering.htm ↩︎

• Anthropic Claude Managed Agents (Public beta 2026-04-08). 하네스의 어려움을 PaaS로 제공 ↩︎

• Galileo "Eval Engineering" https://galileo.ai/evalengineering — eval의 CI/CD 통합을 추진. commit 기반 / 스케줄 기반 / 이벤트 주도(event-driven)의 3가지 트리거를 제시 ↩︎

• Cisco/Splunk에 의한 Galileo 인수. SiliconANGLE (2026-05-17) 보도를 기반 https://siliconangle.com/2026/05/17/eval-engineering-missing-piece-agentic-ai-governance/ ↩︎

• Amazon Bedrock AgentCore Evaluations https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations.html — OpenTelemetry / OpenInference 통합을 통한 LLM-as-a-Judge 평가 ↩︎

• Gu et al. "A Survey on LLM-as-a-Judge" (2024) https://arxiv.org/abs/2411.15594 ↩︎

• Zhou et al. (2026) https://arxiv.org/abs/2603.08091 ↩︎

• Gravitee "State of AI Agent Security 2026" (919명 조사, 2026-02-03) https://gravitee.io/state-of-ai-agent-security ↩︎

• MCP Authorization Spec (modelcontextprotocol.io/specification/draft/basic/authorization) — OAuth 2.1 + PKCE 기반의 에이전트 간 인증 표준. Microsoft, Okta/Auth0, Anthropic 등이 공동으로 제정 ↩︎

• HashiCorp "SPIFFE: Securing the Identity of Agentic AI and Non-Human Actors" https://hashicorp.com/en/blog/spiffe-securing-the-identity-of-agentic-ai-and-non-human-actors ↩︎

• Trend Micro "Agentic Governance Gateway" (newsroom.trendmicro.com, 2026-03-24) — NVIDIA GTC 2026에서 발표. identity / authority / action / evidence의 4요소로 governance를 정식화 ↩︎

• EU AI Act GPAI Code of Practice (digital-strategy.ec.europa.eu/en/policies/contents-code-gpai) — 2025년 8월 승인, 2026년 8월 시행 예정 ↩︎