<div id="readability-page-1" class="page"><article><div><p>안녕하세요. LY Corporation에서 인증·인가 기반 Athenz의 개발·운영을 담당하고 있는 보안 플랫폼 엔지니어 김정우입니다.</p>
<p>지난 글 <a href="https://techblog.lycorp.co.jp/ko/id-jag-next-generation-authentication-ai-era" target="_blank">AI 시대에 인증 과제를 해결할 차세대 표준 후보, ID-JAG</a>에서는, Identity Assertion JWT Authorization Grant(이하 ID-JAG)가 AI 에이전트 환경에서 왜 점점 더 중요해지고 있는지, 기존의 싱글 사인온(SSO) 신뢰 모델을 API 영역으로 어떻게 확장하는지, AI 개발자와 기업 관점에서 ID-JAG의 핵심 이점과 도입 시 고려해야 할 사항을 다뤘습니다.</p>
<p>오늘은 이론을 넘어 실전으로 한 걸음 더 들어가 보려고 합니다. 추상적인 사양과 실제 작동 사이의 간극을 메우기 위해 <a href="https://github.com/athenz-community/id-jag-the-hard-way" target="_blank">athenz-community/id-jag-the-hard-way</a>라는 실습 핸즈온을 준비했습니다. 이 로컬 핸즈온 환경에서 AI 에이전트가 사용자를 대신해 보호된 API에 접근하기 위해 필요한 정확한 토큰과 정책이 무엇인지, 신뢰 관계가 어떻게 형성되는지 직접 관찰할 수 있습니다. 다음은 데모 영상입니다.</p>
<figure><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/084edb90bf9948879fb8c048e22ed84f.gif?updatedAt=1779437603000" alt="ID-JAG The Hard Way Demo" width="800" height="450">
<figcaption>저장소: <a href="https://github.com/athenz-community/id-jag-the-hard-way" target="_blank">athenz-community/id-jag-the-hard-way</a></figcaption>
</figure>
<h2 id="tldr">TL;DR: 이 글에서 배울 수 있는 것</h2>
<ul><li>로컬 환경에서 ID-JAG의 엔드투엔드 흐름을 재현해 AI 에이전트가 로그인한 사용자를 대신해 보호된 API에 안전하게 접근하도록 구성하는 방법</li><li>AI 에이전트가 보호된 MCP(Model Context Protocol) 서버와 상호작용하는 방식, 인가(authorization) 서버가 기업 정책을 평가하는 방식, 리소스 서버가 최소한의 권한으로 발급된 액세스 토큰을 요구하는 메커니즘</li><li>토큰이 정확히 어디에서 발급되며, 특정 정책이 누락되었을 때 파이프라인의 어느 지점에서 실행이 차단되는지</li></ul>
<h2 id="1-1">1. 구성도의 그 너머로</h2>
<p>ID-JAG는 현재 IETF의 OAuth 워킹 그룹에서 활발히 논의 중인 인터넷 초안(2026년 5월 기준 <a href="https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/" target="_blank">draft-ietf-oauth-identity-assertion-authz-grant-03</a>)으로, 다음 두 가지 기존 RFC 사양을 결합해 안전하게 위임된 크로스 도메인 API 접근을 지원합니다.</p>
<ul><li>OAuth 2.0 Token Exchange(<a href="https://datatracker.ietf.org/doc/html/rfc8693" target="_blank">RFC 8693</a>)</li><li>JWT Profile for OAuth 2.0 Authorization Grants(<a href="https://datatracker.ietf.org/doc/html/rfc7523" target="_blank">RFC 7523</a>)</li></ul>
<p>아키텍처 구성도는 전체적인 그림을 파악하는 데는 유용하지만, 실제 구현 과정에서 마주치는 다음과 같은 실무적인 엔지니어링 질문에는 답해주지 않는 경우가 많습니다.</p>
<ul><li>사용자가 AI 에이전트에 로그인할 때 정확히 어떤 토큰 페이로드가 생성되는가?</li><li>이미 ID 토큰을 가지고 있는데 왜 ID-JAG를 거치지 않고 직접 액세스 토큰으로 교환하면 안 되는가?</li><li>인증은 IdP(identity provider, 자격 증명 제공자)에 맡기면서도 기업의 인가 정책 관리와 평가는 별도의 정책 결정 지점(policy decision point, PDP)으로 분리할 수 있는가?</li><li>AI 에이전트가 MCP 서버를 호출할 때 정확히 어떤 권한을 가지며, 자신이 로그인한 사용자의 대리인임을 어떻게 증명하는가?</li><li>기업 IdP와 인가 서버 간의 시스템 수준 신뢰 관계는 어떻게 설정되는가?</li></ul>
<p>ID-JAG를 벌써 사실상 표준(de facto standard)이라고 부르기에는 이를 수 있지만, 표준 OAuth 메커니즘에서 위임된 접근을 모델링하기 위해 사용하는, 떠오르고 있는 유망한 OAuth 기반 프로필임은 분명합니다. 이 핸즈온에서는 이러한 핵심 개념을 AI 에이전트 인가라는 과제에 직접 적용해 보겠습니다.</p>
<h2 id="2ai">2. AI 에이전트 인가의 과제</h2>
<p>기존 애플리케이션 보안 모델에서는 사람이나 서비스 계정이 자격 증명(비밀번호, 인증서 등)을 제시해 정적인 접근 권한을 얻었습니다. 하지만 AI 에이전트는 사람이나 서비스 중 어느 것에도 딱 들어맞지 않습니다. 사전에 정해진 예측 가능한 루틴을 실행하는 서비스 계정도 아니고, 자신의 행동에 즉각 책임을 질 수 있는 사람도 아닙니다. 대신, 독특하고 끊임없이 진화하는 새로운 유형의 행위자(actor)라고 볼 수 있습니다.</p>
<p>AI 에이전트는 백그라운드에서 내부 API, SaaS 도구, 데이터베이스를 지속적으로 호출합니다. 그런데 이렇게 자동화된 체인의 모든 단계마다 사용자에게 동의(consent)를 구한다면 사용자 경험은 심각하게 훼손될 것입니다.</p>
<p>반대로, 에이전트에게 포괄적이고 영구적인 권한을 부여하면 장애 발생 시의 영향 범위(blast-radius)가 커지고 책임 소재가 불분명해지는 문제가 발생합니다. 에이전트가 오작동하거나 악용될 경우 사용자의 의도와 에이전트의 자율 행동을 구분하기 어려워집니다. 이는 개인 사용자가 에이전트의 행동을 수동으로 감시하게 만들어 인지 부하를 높이고 주의력과 운영 리소스를 낭비하게 만듭니다. 또한, 기업 내 '섀도우 AI(shadow AI)'가 확산되도록 만들어 프롬프트 인젝션과 같은 새로운 공격 벡터에 조직을 노출시키고 기업의 공격 표면을 크게 넓힐 수 있습니다.</p>
<p>이 환경을 안전하게 보호하려면 질문의 초점을 ‘이 사용자는 누구인가?’에서 다음과 같이 바꿔야 합니다.</p>
<p>‘이 AI 에이전트는 현재 이 특정 사용자를 대신해 정확히 이 권한 범위 내에서 이 특정 리소스에 접근하도록 인가되었는가?’</p>
<p>ID-JAG는 임시방편으로 구성한 파편화된 연결에서 벗어나, 세밀한 기업 정책으로 통제하는 기업 IdP와 인가 서버 간 중앙 집중형 신뢰 아키텍처를 구축함으로써 이 문제 해결을 돕습니다.</p>
<h2 id="3">3. 데모 아키텍처 구성 요소</h2>
<p>이 핸즈온 환경은 다음 5가지 핵심 구성 요소로 구성됩니다.</p>
<table><thead><tr><th>구성 요소</th><th>기술</th><th>역할</th></tr></thead><tbody><tr><td><strong>요청 에이전트</strong></td><td>Open WebUI, Ollama, Gemma 4, AI 클라이언트 게이트웨이 Gateway</td><td>사용자를 대신해 도구를 실행하는 로컬 AI 에이전트 및 게이트웨이</td></tr><tr><td><strong>IdP</strong></td><td>Keycloak(Docker 환경)</td><td>사용자 인증 및 주체(subject) 어서션(assertion)을 관리하는 자격 증명 제공자</td></tr><tr><td><strong>IdP 인가 서버</strong></td><td>Athenz <code>KeycloakTokenExchangePlugin</code></td><td>ID 어서션을 검증하고 ID-JAG 토큰을 발급하는 플러그인</td></tr><tr><td><strong>인가 서버</strong></td><td>Athenz(로컬 쿠버네티스 환경)</td><td>액세스 토큰을 발급하는 PDP 역할을 하는 인가 서버</td></tr><tr><td><strong>리소스 서버</strong></td><td>샘플 문서 API</td><td>보호 대상인 최종 리소스 서버</td></tr></tbody></table>
<h3 id="">아키텍처 설계 참고 사항</h3>
<p>표준 ID-JAG 모델에서는 일반적으로 IdP 인가 서버가 사용자를 인증하고, 클라이언트가 해당 사용자를 대신해 행동할 수 있는지 평가한 뒤 ID-JAG를 발급하는 역할을 모두 수행합니다.</p>
<p>하지만 이 핸즈온에서는 의도적으로 그 책임을 분리했습니다. Keycloak은 사용자 인증과 원본 ID 어서션을 담당하는 업스트림 IdP 역할을 합니다. 반면 Athenz는 <code>KeycloakTokenExchangePlugin</code>을 통해 상호 연동된 IdP 인가 서버로 작동하며 Keycloak이 발급한 어서션을 검증하고 기업 정책을 적용한 후 최종 ID-JAG 어서션을 발급합니다.</p>
<p>이는 ID-JAG 드래프트에 설명돼 있는 가장 단순한 배포 모델과는 약간 다르지만 커버하는 보안 영역은 동일합니다. 리소스 인가 서버는 업스트림 Keycloak 토큰을 리소스 인가 그랜트(authorization grant)로 무조건 수용하지 않습니다. 대신 발급자(issuer), 서명, 대상(audience), 주체(subject), 클라이언트 바인딩 및 기업 정책 검사를 모두 거친 후에만 발급되는 Athenz 발급 ID-JAG를 신뢰합니다.</p>
<p>이러한 분리는 인증 IdP가 벤더 관리 시스템인 환경에서 매우 유용합니다. 인가 정책과 위임 제어를 여러 IdP와 SaaS 벤더 또는 리소스 앱에 분산하지 않고 Athenz 한 곳에 집중시킴으로써, 기업은 교차 애플리케이션 위임 정책을 중앙에서 관리할 수 있고, 인가 로직에 대한 벤더 종속(lock-in)을 줄이며, 여러 시스템에 걸쳐 있는 중복되거나 모순된 정책 때문에 발생하는 운영 및 보안 리스크를 피할 수 있습니다.</p>
<p>따라서 이 핸즈온 환경에서 Athenz는 ID-JAG 발급자이자 중앙 리소스 인가 서버 및 PDP로 기능하며, 위임된 API 접근에 대한 기업 내 '단일 진실 공급원(single source of truth)' 역할을 수행합니다.</p>
<h2 id="4">4. 실행 흐름 따라가기</h2>
<p>핸즈온을 실행하면 내부에서 다음과 같은 순서로 작업이 진행됩니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/00cfc0290959414896f22f57a28f232c.png?updatedAt=1781075996000" width="1000" height="auto" alt="랩 실행 흐름"></p>
<ol><li>사용자가 Keycloak IdP를 통해 시스템에 로그인합니다.</li><li>사용자가 프롬프트를 입력해 AI 에이전트에 작업을 지시합니다.</li><li>AI 에이전트가 Athenz IdP 인가 서버에 ID-JAG 토큰을 요청합니다.</li><li>Athenz는 기업 정책을 평가하고 검증하여 요청된 위임이 허용되는지 확인합니다.</li><li>AI 에이전트가 Athenz 인가 서버에 액세스 토큰을 요청합니다.</li><li>AI 에이전트는 발급받은 토큰을 포함하여 MCP 서버에 요청을 보냅니다.</li><li>MCP 서버는 인가 서버와 토큰 교환을 수행합니다.</li><li>MCP 서버는 교환된 토큰을 사용하여 최종 리소스 서버에 요청을 보냅니다.</li></ol>
<p>핵심은 AI 에이전트가 장기적인 마스터 키를 보유하는 것이 아니라 기업 정책 엔진이 평가한 특정한 경계 내에서만 작동한다는 점입니다.</p>
<h2 id="5">5. 실패를 가정한 설계: 차단을 통해 배우기</h2>
<p>AI 에이전트 인가 아키텍처는 성공 경로보다 실패 경로를 통해 이해하는 것이 가장 좋습니다. 인가되지 않은 상태를 시스템이 어떻게 처리하는지 관찰할 때 보안 설계가 더 명확히 보이기 때문입니다. 이 핸즈온은 다음과 같은 의도적인 실패 지점을 경험하도록 설계되었습니다.</p>
<ul><li>토큰 없이 보호된 API를 호출해 <code>401 Unauthorized</code> 에러가 발생하는 것을 관찰합니다.</li><li>엔터프라이즈 역할은 구성하지만 멤버십을 누락시켜 토큰 교환 실패를 유도합니다.</li><li>에이전트에게 필요한 권한을 명시적으로 부여하지 않고 위임 호출을 시도해 위임 체인이 끊어지는 것을 확인합니다.</li></ul>
<p>각 오류는 체인 내에 특정 정책 구성 요소나 신뢰 관계가 왜 존재해야만 하는지를 정확히 보여줍니다.</p>
<h3 id="id">아키텍처 딥다이브: ID 토큰을 직접 교환하면 안 되는 이유</h3>
<p>이 핸즈온과 같은 소규모 로컬 설정에서는 Keycloak의 ID 토큰을 Athenz의 액세스 토큰으로 직접 교환하는 것도 기술적으로는 가능합니다. Athenz가 Keycloak 토큰의 발급자, 서명, 대상(audience), 주체(subject)를 검증하고 Athenz 정책을 평가해 액세스 토큰을 발급할 수 있습니다.</p>
<p>하지만 그렇게 구성한 모델은 암묵적으로 로그인 토큰을 리소스 접근을 위한 인가 그랜트로 취급합니다. 이 차이는 장애나 감사(audit) 경로에서 매우 중요합니다. ID 토큰은 사용자가 클라이언트에 성공적으로 인증되었음을 증명할 뿐입니다. 반면 인가 그랜트는 특정 리소스와 범위에 대한 액세스 토큰을 요청하기 위해 인가 서버에 제출하는 아티팩트(artifact)입니다. 인가 그랜트에 경계를 도입하면 인증 실패, 그랜트 검증 실패, 에이전트 위임 거부, 기업 정책 거부, 리소스 토큰 거부를 명확히 분리할 수 있습니다. 요약하자면, 자격 증명 데이터가 명시적인 접근 권한과 혼동되는 것을 막고, 인증 이벤트가 크로스 도메인의 인가 권한을 자동으로 보장하지 않도록 방지하는 것입니다.</p>
<p>이 데모를 작동시키는 데 ID-JAG가 필수는 아닙니다. 하지만 ID-JAG의 진정한 가치는 (특히 실패 상황에서) 이 인가 경계를 명확하게 만들어 준다는 데 있습니다.</p>
<h2 id="6">6. 퀵스타트: 로컬에서 흐름 실행하기</h2>
<p>실습을 시작하려면 아래 저장소 링크로 이동해 주세요.</p>
<ul><li>저장소: <a href="https://github.com/athenz-community/id-jag-the-hard-way" target="_blank">athenz-community/id-jag-the-hard-way</a></li></ul>
<p>메인 페이지에서 <strong>START THE TUTORIAL NOW</strong> 버튼을 클릭하면 로컬 환경을 설정하고 ID-JAG 흐름을 검증하는 단계로 안내됩니다.</p>
<p><a href="https://github.com/athenz-community/id-jag-the-hard-way/blob/main/README.md" target="_blank"><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/63201b03d2c942d18c8f87ffe4683e23.png?updatedAt=1781076127000" width="1000" height="auto" alt="리포지터리에서 튜토리얼 실행하기"></a></p>
<p>가이드 자체는 의도적인 '실패와 수정' 루프를 중심으로 구성되어 있으며, 궁극적으로 완벽하게 작동하는 상태로 안내합니다. 핸즈온을 마친 후에도 언제든지 설정을 수동으로 망가뜨려 경계를 테스트해 볼 수 있습니다. 예를 들어 Athenz UI에 들어가 에이전트의 위임 권한을 제거하고 실행 차단이 정확히 어디서 발생하는지 추적해 보세요. 이러한 능동적인 실험이야말로 중앙 집중형 정책 제어에 대해 가장 많이 배울 수 있는 방법입니다.</p>
<h2 id="-1">마치며</h2>
<p>AI 에이전트가 기업 워크플로 전반으로 확장되면서 프론트 도어에서 인증을 검증하는 것만으로는 더 이상 충분하지 않습니다. 현대 아키텍처는 위임된 접근에 대한 시스템 관점의 제어와 명시적인 감사를 요구합니다.</p>
<p>ID-JAG는 이러한 복잡성을 관리할 수 있는 구조화된 접근 방식을 제공하며, 이는 직접 실습하며 실험해 볼 때 가장 잘 이해할 수 있습니다. <a href="https://github.com/athenz-community/id-jag-the-hard-way" target="_blank">id-jag-the-hard-way</a>에 대한 기여, 이슈 등록, 피드백은 언제나 환영합니다.</p>
<h3 id="techverse2026">Tech-Verse 2026 프리뷰</h3>
<p>LY Corporation의 연례 기술 콘퍼런스인 <a href="https://tech-verse.lycorp.co.jp/2026/ko/" target="_blank">Tech-Verse 2026</a>에서 이 주제로 세션을 진행할 예정입니다.</p>
<blockquote>AI 시대의 차세대 인가 표준 “ID-JAG”: MCP·A2A 기반 Enterprise-Ready 인가 솔루션</blockquote>
<p>기본적인 프로토콜 메커니즘을 넘어 중앙 정책 제어 모델을 논의하고, Google의 A2A(Agent2Agent) 이니셔티브와 클라우드 플랫폼의 전반적인 AI 에이전트 보안 접근 방식 등 에이전트 생태계 주변의 동향을 살펴볼 예정입니다. 또한, 이런 전략과 동향을 Okta와 Ping Identity의 기여자들이 참여하고 있는 ID-JAG 초안과 비교해 보며 분석할 계획입니다. 콘퍼런스에서 뵙겠습니다!</p>
<p><strong>이 저자의 다른 글 보기</strong></p>
<ul><li>
<p><a href="https://techblog.lycorp.co.jp/ko/why-did-an-athenz-engineer-take-on-the-kubestronaut-challenge" target="_blank">Athenz 엔지니어는 왜 Kubestronaut에 도전했는가?</a></p>
</li><li><a href="https://techblog.lycorp.co.jp/ko/id-jag-next-generation-authentication-ai-era" target="_blank">AI 시대에 인증 과제를 해결할 차세대 표준 후보, ID-JAG</a></li></ul></div></article></div>

LINE ENGINEERING

안녕하세요. LY Corporation에서 인증·인가 기반 Athenz의 개발·운영을 담당하고 있는 보안 플랫폼 엔지니어 김정우입니다.지난 글 AI 시대에 인증 과제를 해결할 차세...

ID-JAG The Hard Way: 실패로 배우는 AI 에이전트 보안 핸즈온

댓글