에이전트 메모리 카드 생성기 — 하나의 프롬프트가 거버넌스 대시보드로 변신하다

이 포스트는 DEV Education Track: Build Apps with Google AI Studio에 제출하는 저의 작업물입니다.

내가 만든 것

대부분의 AI 에이전트 (AI agent) 도구들은 에이전트가 할 수 있는 것이 무엇인지 알려줍니다.

하지만 에이전트가 _무엇을 하도록 허용되어야 하는지_를 알려주는 곳은 아무도 없습니다.

이 앱은 바로 그 간극을 메우기 위해 만들어졌습니다.

저는 **Agent Memory Card Generator (에이전트 메모리 카드 생성기)**를 만들었습니다. 이 도구는 AI 에이전트의 이름, 목적, 지침 (instructions)을 입력받아 각 지침을 위험 수준별로 분류하고, 에이전트의 권한 태세(authority posture)인 '안전 (Safe)', '주의 (Cautious)', 또는 '제한됨 (Restricted)'을 보여주는 시각적 아이덴티티 카드를 생성하는 거버넌스 (governance) 대시보드입니다.

분류 방식은 블랙박스가 아닌 투명한 휴리스틱 (heuristics)을 사용합니다:

• 고위험 / 제한됨 (High-risk / Restricted) — 자격 증명 (credentials), 결제 (payments), 개인 데이터 (private data), 되돌릴 수 없는 작업 (irreversible actions), 외부 통신 (external communication)
• 검증 필요 (Requires Verification) — 오래된 메모리 (stale memory), 사용자 주장 (user claims), 제3자 승인 (third-party approvals), 시대에 뒤처질 수 있는 모든 것
• 수행 가능 (Safe to Act On) — 정보 제공 (informational), 되돌릴 수 있는 작업 (reversible), 포맷팅 (formatting), 요약 (summarization), 내부 계획 (internal planning)

각 지침에 대해 이 앱은 분류, 이유, 권장되는 액션 게이트 (action gate) (answer / verify_first / block), 그리고 AGENTS.md 또는 CLAUDE.md 파일에 바로 붙여넣을 수 있는 제안된 메타데이터 (metadata) 필드를 출력합니다.

Google AI Studio에서 사용한 프롬프트:

"Agent Memory Card Generator"라는 웹 앱을 구축하세요. 사용자는 AI 에이전트의 이름, 목적, 그리고 최대 5개의 핵심 지침 (instructions)을 입력합니다. 앱은 투명한 휴리스틱 (heuristics)을 사용하여 각 지침을 분석하고 이를 다음과 같이 분류합니다: 실행 가능 (Safe to act on), 확인 필요 (Requires verification), 또는 고위험/제한됨 (High-risk / restricted). 각 지침에 대해 분류 결과, 이유, 권장되는 액션 게이트 (action gate: answer / verify_first / block), 그리고 제안된 메타데이터 (metadata) 필드를 보여줍니다. 그런 다음 에이전트 이름, 목적, 권한 태세 (authority posture), 그리고 색상 코드(안전: 녹색/청색, 주의: 황색/청색, 제한: 적색/흑색)를 보여주는 Imagen 시각적 아이덴티티 카드를 생성합니다. 구조화된 권한 요약과 AGENTS.md 또는 CLAUDE.md 형식으로 내보낼 수 있는 일반 텍스트 보고서를 출력합니다. 모든 분류 로직은 클라이언트 사이드 (client-side)에서 실행됩니다. Imagen은 서버 사이드 (server-side)에서 시각적 카드를 처리하며, API를 사용할 수 없는 경우 세련된 CSS 폴백 (fallback)을 제공합니다.

단 하나의 프롬프트. 단 한 번의 빌드 과정. 그 결과물은 클라이언트 사이드 휴리스틱 엔진, 서버 사이드 Imagen 통합, CSS 폴백 카드, 그리고 클릭 한 번으로 내보낼 수 있는 마크다운 (markdown) 보고서를 갖춘 풀스택 (full-stack) 앱이었습니다.

데모 (Demo)

라이브 앱: Agent Memory Card Generator

다음 입력을 사용하여 직접 테스트해 보세요:

에이전트 이름 (Agent Name): Atlas Support Agent
목적 (Purpose): 소규모 사업자가 고객 지원, 결제 및 내부 운영을 관리하는 것을 돕습니다.

지침 (Instructions):

1. 저장된 회사 노트를 사용하여 고객 질문에 답변합니다.
2. 환불 질문에 답변하기 전에 결제 기록을 확인합니다.
3. API 키, 비밀번호 또는 개인 고객 데이터를 절대 공개하지 않습니다.
4. 결제 확인을 보내기 전에 원장 (ledger)과 대조하여 확인합니다.
5. 매일 업무 종료 시 지원 티켓 (support tickets)을 요약합니다.

이 입력을 통해 앱이 생성한 결과물:

• Instruction 1 → Safe / answer
• Instruction 2 → Requires Verification / verify_first
• Instruction 3 → High-risk / block
• Instruction 4 → Requires Verification / verify_first
• Instruction 5 → Safe / answer
• Overall posture: Cautious (amber)

그다음 스포츠 헤드라인 요약기나 일일 일정 플래너와 같이 위험도가 낮은 다른 지침(instructions)으로 교체해 보세요. 그러면 포스처(posture, 태세)가 실시간으로 Restricted(제한됨)에서 Safe(안전함)로 변하는 것을 확인할 수 있습니다. 이러한 비례적인 대응이 바로 핵심입니다.

나의 경험

빌드 자체는 단 하나의 프롬프트와 한 번의 실행(pass)으로 끝났습니다. 나머지는 테스트, 배포, 그리고 검증 과정이었습니다.

예상치 못했던 점은 분류 엔진이 균일하게 반응하는 것이 아니라 비례적으로 반응한다는 것이었습니다. 스포츠 요약 에이전트는 5개의 지침, 0개의 검증, 0개의 제한 사항을 가진 Safe 상태로 분류됩니다. 자격 증명(credentials), 결제, 고객 데이터를 다루는 에이전트는 Restricted 상태가 됩니다. 혼합된 위험도를 가진 에이전트는 Cautious 상태가 됩니다. 포스처는 단순히 위험한 단어 하나가 포함되었는지 여부가 아니라, 지침 세트의 실제 위험 프로필(risk profile)을 추적합니다.

이는 들리는 것보다 훨씬 더 중요합니다. 대부분의 거버넌스(governance) 도구는 허용되거나 되지 않거나 하는 이진법(binary) 방식입니다. 하지만 이 도구는 그라데이션(gradient)을 생성하며, 이는 실제 에이전트의 위험이 작동하는 방식에 더 가깝습니다.

가장 기억에 남는 놀라운 점은 내보낸 보고서가 AGENTS.md 및 CLAUDE.md 구문(syntax)으로 직접 포맷팅된다는 것이었습니다. 출력물은 단순한 시각화 자료가 아니라 즉시 실행 가능한 결과물입니다. 이를 복사하여 에이전트 설정 파일에 붙여넣기만 하면, 메모리 저장소(memory store)는 시작부터 구조화된 권한 메타데이터(authority metadata)를 갖게 됩니다.

이는 제가 AI 에이전트 메모리에 대해 구축해 온 더 큰 연구 흐름과 연결됩니다. 핵심적인 발견은 다음과 같습니다. 검색 시스템(retrieval systems)은 가장 관련성 높은 메모리를 선택하지만, 관련성(relevance)과 권한(authority)은 서로 다른 개념이라는 점입니다. 에이전트가 올바른 지침을 검색하더라도, 해당 지침에 시스템이 무엇을 관리할 권한이 있는지 알려주는 메타데이터가 없다면 여전히 잘못된 행동을 할 수 있습니다.

카드 생성기(card generator)는 에이전트가 실행되기 전에 그러한 차이점을 가시화합니다. 다음 단계는 생성(generation)을 감사(audit)와 연결하는 것입니다. 한 도구는 권한을 인식하는 지침(authority-aware instructions)을 만드는 데 도움을 주고, 감사 워크플로우(auditor workflow)는 기존의 AGENTS.md 또는 CLAUDE.md 파일을 검사하여 오래되었거나, 느슨하거나, 누락된 권한 메타데이터(authority metadata)를 찾아낼 수 있습니다. 제가 구축하고자 하는 목표는 바로 그러한 더 완전한 그림입니다.

만약 이를 테스트한다면 — 여러분의 에이전트는 어떤 태세(posture)를 갖추게 될까요?