AI 에이전트 데모는 대개 한 가지, 즉 모델이 무엇을 생성할 수 있는지에 최적화되어 있습니다. 하지만 실제 운영 시스템(Production systems)은 다른 곳에서 실패합니다. 바로 상태(state), 메모리(memory), 검색(retrieval), 그리고 권한(authority)을 둘러싼 경계 지점입니다.

지난 몇 달 동안 저는 이러한 경계 지점들을 중심으로 작은 공개 포트폴리오를 구축해 왔습니다. 이 프로젝트들이 하나의 통합된 스택을 형성한다는 주장은 아닙니다. 이들은 동일한 엔지니어링 질문으로 연결된 독립적인 도구들입니다:

에이전트가 수정하는 시스템에 대해 무제한적인 권한을 부여하지 않으면서, 어떻게 유용한 능력을 부여할 수 있을까?

저는 아래에 설명된 프로젝트들의 저자이자 유지관리자입니다. 이 포스트의 목적은 별(stars)을 요청하는 것이 아니라, 문제점과 현재의 설계 선택, 그리고 한계점을 설명하는 것입니다.

1. 무제한적 변이(Unrestricted mutation): ESAA-Core

코딩 에이전트는 파일을 수정하고, 명령을 실행하며, 성공을 선언할 수 있습니다. 하지만 대화 기록(transcript)은 상태 머신(state machine)이 아니며, 메시지 로그가 결과적인 저장소(repository) 상태가 허용된 워크플로우를 따랐음을 증명하지는 않습니다.

ESAA-Core는 더 엄격한 모델을 탐구합니다:

에이전트가 제안함
  -> 오케스트레이터(Orchestrator)가 검증함
    -> 이벤트 스토어(Event store)에 기록함
...

에이전트는 claim, complete, 또는 review와 같은 의도(intention)를 방출합니다. 단일 작성자(single writer)가 전이(transition)를 검증하고, 워크플로우 게이트(workflow gates)를 적용하며, 추가 전용(append-only) 이벤트를 기록하고, 읽기 모델(read model)을 재구축합니다.

이것이 LLM을 진실되게 만들거나 나쁜 코드를 제거해 주는 것은 아닙니다. 하지만 여러 종류의 잘못된 전이를 관찰 가능하게 하고 거부할 수 있게 만듭니다. 예를 들어, 사전 claim 없이 작업을 완료하거나, 허용된 경계 밖에서 파일 효과를 적용하거나, 잘못된 역할로 승인하거나, 터미널 작업을 조용히 다시 여는 행위 등을 말합니다.

실질적인 이점은 재생 가능성(replayability)입니다. 최신 JSON 파일이나 채팅 메시지를 신뢰하는 대신, 시스템은 정렬된 이벤트 히스토리로부터 현재 상태를 재구축하고 프로젝션 해시(projection hashes)를 검증할 수 있습니다.

2. 도구 간의 컨텍스트 손실: Conversation ESAA

거버넌스 상태(Governance state)와 대화 메모리(conversational memory)는 서로 다른 관심사입니다. 작업 프로토콜(task protocol)이 모든 어시스턴트 메시지의 쓰레기통이 되어서는 안 되지만, Codex, Claude Code, Grok 또는 다른 러너(runner) 사이를 전환할 때 결정을 내리게 한 추론 과정이 지워져서도 안 됩니다.

Conversation ESAA는 에이전트 간의 연속성과 핸드오프(handoff)를 위한 이벤트 소싱(event-sourced) 메모리 계층입니다. 이는 대화 이벤트(conversation events)를 캡처하고, 주제(topics)와 핸드오프를 도출하며, 추가 전용(append-only) 히스토리를 공식적인 ESAA 작업 저장소(task store)와 분리하여 유지합니다.

이러한 분리는 매우 중요합니다:

• 거버넌스(governance)는 다음을 답합니다: 어떤 전환(transition)이 유효한가?
• 메모리(memory)는 다음을 답합니다: 다음 에이전트가 복구해야 할 컨텍스트(context)는 무엇인가?

이 둘을 혼합하면 둘 다 추론하기가 더 어려워질 것입니다. Conversation ESAA는 ESAA에 의해 관리되는 작업을 지원할 수 있지만, 거버넌스 프로토콜(governance protocol)을 대체하는 것은 아닙니다.

3. 검색 오버헤드(Retrieval overhead): rag-sqlite

시맨틱 검색(Semantic search)은 방대한 대화 기록에 유용하지만, 동기식 훅(synchronous hook) 내부에서 임베딩(embeddings)을 실행하는 것은 운영 측면에서 좋지 않은 트레이드오프(trade-off)입니다. 초기 파일럿 프로젝트에서는 첫 번째 인덱스(index)를 구축하는 데 약 16분이 소요되었습니다. 이 작업을 임계 경로(critical path)에 두면 훅 지연 시간(hook latency)이 증가하고, 기본 워크플로가 Ollama 및 임베딩 모델에 의존하게 됩니다.

rag-sqlite는 하나의 SQLite 데이터베이스를 기반으로 하는 JSON CLI로서 결정론적 로컬 검색(deterministic local retrieval)을 패키징합니다. 이는 로컬 Ollama 임베딩, 테스트를 위한 오프라인 해시 모드, 하이브리드 랭킹(hybrid ranking), 인덱스 생성, 그리고 LLM 도구를 위한 안정적인 커맨드 인터페이스(command surface)를 지원합니다.

Conversation ESAA는 이를 **선택적인 외부 어댑터(optional external adapter)**로 사용합니다:

activity.jsonl
  -> 비동기식 내보내기 (asynchronous export)
    -> 도출된 프라이빗 코퍼스 (derived private corpus)
...

RAG 프로젝션(projection)은 일회성(disposable)이며, 메인 대화 파이프라인에 대해 페일 오픈(fail-open) 방식으로 동작합니다. 훅(Hooks)은 인덱스를 더티(dirty) 상태로 표시하고 작업을 예약할 뿐, 메인 동기화 잠금(synchronization lock)을 보유한 상태에서 임베딩을 실행하지 않습니다. 검색을 사용할 수 없는 경우에도 동기화 및 검증은 여전히 작동합니다.

이 프로젝트는 의도적으로 독립적입니다. 또한 모든 사용이 ESAA 채택인 것처럼 가장하지 않고도 다른 로컬 코퍼스 (local corpora)에 서비스를 제공할 수 있습니다. 이 프로젝트의 다운로드 및 사용량은 ESAA 채택 지표와 별도로 유지되어야 합니다.

4. 검증 불가능한 자동 감사: ESAA-Security

보안 에이전트 (Security agents)는 또 다른 권한 문제를 야기합니다. 모델은 그럴듯한 결과물을 생성할 수 있지만, 팀은 어떤 도메인이 검토되었는지, 어떤 경계가 적용되었는지, 어떤 증거가 분류를 뒷받침했는지, 그리고 재실행 시 동일한 감사 상태를 재구성할 수 있는지 알아야 합니다.

ESAA-Security는 16개 보안 도메인에 걸쳐 구조화된 자동 감사에 ESAA 아키텍처를 적용합니다. 결과, 분류 및 감사 전환 (audit transitions)은 동일한 추가 전용 (append-only) 및 투영 지향적 (projection-oriented) 접근 방식을 통해 관리됩니다.

이 프로젝트의 목표는 인간의 보안 검토를 대체하는 것이 아닙니다. 자동화된 감사 작업이 검사 가능하도록 만드는 것입니다. 즉, 명시적인 범위, 반복 가능한 작업, 기록된 전환, 그리고 증거로 추적 가능한 결과물을 제공하는 것입니다.

통합 스택이 아닌 포트폴리오

현재 네 가지 프로젝트는 다음과 같은 단순한 어휘를 중심으로 정렬되어 있습니다:

이 프로젝트들은 현재 매끄러운 플랫폼으로 설명되어서는 안 됩니다. 마케팅 용어가 이를 하나의 스택 (stack)이라고 주장하기 전에, 통합을 위한 계약 (contracts), 예시, 그리고 테스트가 필요합니다.

증거와 한계

2026년 7월 23일 기준으로, 공개 채택 스캔 결과 ESAA 패턴의 5개 공개 구현 사례에서 4개의 독립적인 Tier 3 채택자를 발견했습니다. ESAA-Core는 지난 30일 동안 GitHub 별(stars) 57개와 PyPI 다운로드 812회를 기록했으며, ESAA-Security는 별 200개를 기록했습니다. 별과 다운로드 수는 도달 범위(reach)를 나타내는 신호일 뿐, 운영상의 채택을 증명하는 것은 아닙니다.

더 중요한 한계는 기술적인 부분입니다:

• ESAA-Core는 아직 프리릴리스 (pre-release) 소프트웨어입니다.
• 이벤트 소싱 (Event sourcing)은 알려진 잘못된 전이 (invalid transitions)를 거부할 뿐, 에이전트의 구현이 올바르다는 것을 증명하지는 않습니다.
• 대화 메모리 (Conversation memory)는 좋은 컨텍스트 (context)만큼이나 잘못된 컨텍스트도 충실하게 보존할 수 있습니다.
• 검색 (Retrieval) 품질은 코퍼스 (corpus), 임베딩 모델 (embedding model), 그리고 랭킹 (ranking) 설정에 따라 달라집니다.
• 자동화된 보안 탐지 결과 (Automated security findings)는 여전히 검증과 인간의 판단을 필요로 합니다.
• 이 프로젝트들은 소규모 팀에 의해 유지 관리되고 있으며, 더 많은 외부 재현 (reproduction)이 필요합니다.

라이선스 (Licensing)

ESAA-Core, Conversation ESAA, 그리고 rag-sqlite는 MIT 라이선스를 따릅니다. 게시 시점을 기준으로 GitHub은 ESAA-Security에 대한 명시적인 라이선스를 감지하지 못했으므로, 이를 오픈 소스 재사용 권한을 부여하는 것으로 가정하기보다는 공개적으로 읽을 수 있는 코드로 취급해야 합니다. 해당 리포지토리의 라이선스를 명확히 하는 것이 구체적인 후속 과제입니다.

다음에 배우고 싶은 것

다음 이정표는 더 큰 홍보용 수치가 아닙니다. 더 나은 외부적 증거입니다:

1. 새로운 유지 관리자 (maintainer)가 도움 없이 ESAA-Core 퀵스타트 (quickstart)를 실행할 수 있는가?
2. 어떤 워크플로 게이트 (workflow gates)가 합성 테스트 (synthetic tests)뿐만 아니라 실제 실수를 거부하는가?
3. Conversation ESAA가 실제 에이전트 간 핸드오프 (cross-agent handoff)를 개선하는가?
4. rag-sqlite가 적절한 트레이드오프 (trade-off)가 아니게 되는 코퍼스 (corpus) 크기는 어느 정도인가?
5. 어떤 ESAA-Security 도메인이 독립적인 검증을 통과하는 탐지 결과를 생성하는가?

만약 여러분이 코딩 에이전트 (coding agents), 에이전트 메모리 (agent memory), 로컬 RAG (local RAG), 또는 앱 보안 (AppSec) 자동화 분야에서 일하고 있다면, 일반적인 찬사보다는 한계점과 실패 모드 (failure modes)에 대한 비판을 더 환영합니다.

ESAA-Core로 시작하거나, 전체 공개 리포지토리 목록을 살펴보세요.