어제, backend-reviewer는 하나의 모델을 사용하여 풀 리퀘스트 (pull requests)를 검토했고, 저장소 (repository)와 공개 문서 (public documentation)만 읽었으며, 변경 사항을 제안하기 전에 인간의 승인을 위해 멈췄습니다.

오늘 그것은 정확히 같은 이름을 가지고 있습니다. 모델은 변경되었고, 시스템 지침 (system instructions)은 다시 작성되었으며, 인시던트 이력 (incident history)이 이제 컨텍스트 소스 (context source)로 사용 가능해졌고, 작업 간에 메모리 (memory)가 유지되며, 데이터베이스 마이그레이션 (database migration) 변경 사항은 더 이상 제안 전에 승인을 요구하지 않습니다.

대시보드에는 여전히 동일한 팀원이 표시됩니다. 품질과 리스크를 책임지는 엔지니어는 다른 에이전트를 바라보고 있습니다.

식별자 (identifier)는 그대로 유지되었습니다. 동작 (behavior)이 이동했습니다.

그 차이가 바로 AI 개발 팀을 위한 오픈 사양 (open specification)인 NexFlow가 가시화하려고 노력하는 부분입니다. 이 프로젝트는 현재 프로덕션 런타임 (production runtime), 프로덕션 CLI (production CLI), 또는 모델 제공자 통합 (model-provider integrations)을 제공하지 않습니다. 현재의 역할은 더 좁지만, 제 관점에서는 더 중요합니다. 즉, 팀에게 무언가가 실행되기 전에 에이전트 변경 사항을 검토할 수 있는 언어를 제공하는 것입니다.

이름은 잘못된 질문에 답합니다

에이전트 이름은 사람들에게 유용합니다. 코드 리뷰어 (code reviewer)와 문서 작성자 (documentation writer)를 구분하고 팀 내에서 장기적인 역할을 설정합니다.

이름은 특정 결과를 만들어낸 설정 (configuration)에 대해 거의 알려주지 않습니다.

모델 변경은 코드 품질, 비용, 지연 시간 (latency), 그리고 불확실성 (uncertainty)을 처리하는 방식에 영향을 미칠 수 있습니다. 새로운 지침은 분석 순서와 허용 가능한 답변의 기준을 변경합니다. 추가된 소스는 가용 지식과 노출 표면 (exposure surface)을 모두 확장합니다. 메모리는 한 작업의 결과를 다른 작업으로 전달합니다. 새로운 권한은 출력 스타일 그 이상을 변경합니다. 즉, 오류가 무엇을 손상시킬 수 있는지를 변경합니다.

따라서 감사 (audit) 목적으로 "어떤 에이전트가 작업을 수행했는가?"라는 질문은 불완전합니다. 두 번째 질문도 그만큼 중요합니다: 해당 에이전트 정의의 어떤 버전 (version)이 활성화되어 있었는가?

초안 RFC-0004에서, NexFlow는 안정적인 에이전트 ID (identity)와 버전이 지정된 에이전트 정의 (definition)를 분리합니다. ID에는 역할 (role), 설명 (description), 그리고 장기적인 책임 (long-lived responsibility)이 포함됩니다. 정의 (definition)는 행동 릴리스 (behavioral release)를 포착합니다. 즉, 에이전트의 출력 (output)이나 권한 (authority)을 실질적으로 변경할 수 있는 컴포넌트 (components)들의 집합을 의미합니다.

행동 릴리스 (behavioral release)에 포함되는 것들
에이전트 정의 (agent definition)는 모델 프로필 (model profile), 프롬프트 세트 (prompt set), 그리고 검색 규칙 (retrieval rules)을 참조할 수 있습니다. 또한 컨텍스트 접근 (context access), 메모리 범위 (memory scopes), 기능 (capabilities), 권한 (permissions), 자율성 (autonomy), 그리고 확장 기능 (extensions)을 식별합니다.

각 컴포넌트 (component)는 서로 다른 방식으로 에이전트를 변경합니다.

모델 프로필 (model profile)은 선택 제약 조건 (selection constraints), 비용 (cost), 지연 시간 (latency), 데이터 처리 (data handling), 그리고 감사 기대치 (audit expectations)를 기술합니다. 프롬프트 세트 (prompt set)는 지침 수정 사항 (instruction revisions)과 검토 메타데이터 (review metadata)를 기록합니다. 검색 프로필 (retrieval profile)은 소스 (sources), 최신성 (freshness), 인용 (citations), 그리고 제외 사항 (exclusions)을 다룹니다. 컨텍스트 (context) 및 메모리 정책 (memory policies)은 정보 경계 (information boundaries)를 정의합니다. 기능 (capabilities)은 기술적 동작 (technical actions)을 설명하며, 권한 (permissions)은 해당 동작이 허용되는지 여부를 결정합니다. 자율성 (autonomy)은 에이전트가 어디에서 멈춰야 하는지를 설정합니다.

모든 세부 사항을 하나의 거대한 에이전트 레코드 (agent record)에 포함시키면 매니페스트 (manifests)를 검토하기 어려워질 것입니다. 승인된 컴포넌트들이 여러 에이전트에 걸쳐 복사될 것이며, 중요한 변경 사항이 수십 개의 관련 없는 줄 사이에서 사라져 버릴 수도 있습니다.

대신 RFC-0004는 버전이 지정된 컴포넌트들을 참조하는 에이전트 정의 (agent definition)를 제안합니다. 현재 초안의 형태는 대략 다음과 같습니다:

id: backend_reviewer_2026_07
agentRef: backend-reviewer
definitionVersion: "2026.07.0"
...

필드 (fields)는 여전히 변경될 수 있습니다. RFC-0004는 여전히 초안 상태이며, NexFlow 자체도 0.1 초안 단계에 있습니다. 중요한 부분은 구조입니다. 즉, 안정적인 에이전트가 별개의 행동 릴리스 (behavioral releases)를 가질 수 있으며, 각 릴리스는 엔지니어링 변경 (engineering change)으로서 검토 가능해야 한다는 점입니다.

참조 (reference)는 컴포넌트를 선택하는 것이지, 권한 (authority)을 부여하는 것이 아닙니다

버전이 지정된 설정(Versioned configuration)은 위험한 착각을 불러일으킬 수 있습니다. 에이전트 정의가 권한 집합(permission set)이나 메모리 범위(memory scope)를 참조할 경우, 그 참조를 접근(access)으로 취급하고 싶은 유혹을 느낄 수 있습니다.

NexFlow는 이러한 우려 사항들을 분리하여 관리합니다.

RFC-0014 초안은 핵심 규칙을 명확하게 제시합니다. 에이전트 정의는 검토된 동작(reviewed behavior)을 선택하는 것이고, 정책 매니페스트(policy manifests)가 이를 승인하고 제약합니다. 역량 참조(capability reference)가 행동을 허용하지 않습니다. 컨텍스트 참조(context reference)가 데이터 분류를 무효화하지도 않습니다. 작업 수준 설정(task-level setting)이 자율성(autonomy)을 조용히 높여서는 안 됩니다.

이러한 분리는 특히 버전을 비교할 때 중요해집니다. 프롬프트 수정은 일반적인 검토가 필요할 수 있습니다. 더 광범위한 메모리 접근이나 승인 게이트 제거는 위험 표면(risk surface)을 변경시키므로 더 강력한 심사가 필요합니다. 두 변화 모두 그 결과가 매우 다르더라도 동일한 JSON 스키마(JSON Schema) 하에서 구조적으로 유효하게 유지될 수 있습니다.

플로팅 버전은 행동 변화를 숨깁니다

모든 컴포넌트를 영원히 고정하는 것이 항상 실용적인 것은 아닙니다. 팀은 '최신 승인된 소규모 코딩 모델'이나 문서 인덱스의 현재 버전을 원할 수 있습니다.

그러한 정책은 수동 업데이트를 줄여주지만 재현(reproduction)을 더 어렵게 만듭니다. 동일한 백엔드 검토자(backend-reviewer)가 6월과 7월에 자신의 매니페스트를 변경하지 않고도 다른 모델이나 코퍼스(corpora)를 사용할 수 있습니다.

따라서 플로팅 참조(floating reference)는 이벤트 로그나 감사 로그(audit log)에 기록되는 구체적인 값으로 해결되어야 합니다. 이러한 기록이 없으면, 사고 조사 시 정책의 이름만 있을 뿐 실제로 실행된 설정을 신뢰할 수 있게 파악하기 어렵습니다.

고정된 참조(pinned reference)는 예측 가능성(predictability)을 선호합니다. 플로팅 참조는 통제된 업데이트를 허용합니다. 프로젝트가 해결된 선택(resolved choice)을 기록하고 어떤 변경 사항이 추가 검토를 필요로 하는지 정의한다면, 어느 쪽이든 작동할 수 있습니다.

Git 히스토리는 가치가 있지만, 에이전트 버전은 아닙니다

한 가지 합리적인 반론은 저장소(repository)가 이미 모든 변경 사항을 기록하고 있다는 점입니다. Git은 어떤 줄이 이동했는지, 그리고 누가 이를 승인했는지를 보여줄 수 있습니다.

하지만 이벤트(event), 아티팩트(artifact), 또는 핸드오프(handoff)는 여전히 이를 생성한 행동 릴리스(behavioral release)에 대한 이식 가능한 참조(portable reference)를 필요로 합니다. 그렇지 않으면 조사관들은 간접적인 증거로부터 활성 커밋(active commit), 브랜치(branch), 외부 컴포넌트 버전(external component versions), 그리고 런타임 선택 사항(runtime choices)을 재구성해야만 합니다.

에이전트 정의 버전(agent definition version)은 결과를 해당 설정(configuration)에 직접 연결합니다:

agent:
  id: backend-reviewer
  definitionRef: backend_reviewer_2026_07
...

향후의 런타임(runtime)은 안전이 보장되는 경우, 해결된 프로바이더 모델(resolved provider model)과 프로바이더별 세부 사항(provider-specific details)을 기록할 수도 있습니다. 그러한 값들은 실행 계층(execution layer)에 속합니다. 핵심 사양(core specification)은 이벤트의 의미를 재구성할 수 있을 만큼 충분한 식별성을 유지하면서도, 프로바이더 중립적(provider-neutral)인 상태를 유지할 수 있습니다.

버전 관리는 에이전트가 실행되기 전부터 도움이 됩니다

이 접근 방식은 프로덕션 런타임(production runtime)을 기다릴 필요가 없습니다.

에이전트 정의(agent definitions)는 코드 옆에 존재하며 풀 리퀘스트(pull requests)에서 검토될 수 있습니다. 검토자는 릴리스가 컨텍스트 소스(context source)를 추가했는지, 프롬프트 세트(prompt set)를 변경했는지, 또는 자율성(autonomy)을 높였는지 확인할 수 있습니다. 변경 사항에는 소유자(owner), 요약(summary), 그리고 명시적인 이전 버전(predecessor)이 부여됩니다.

라이프사이클(lifecycle) 또한 가시화됩니다. 초안(draft)은 일반적인 운영 설정이 아닙니다. 활성 릴리스(active release)는 프로젝트의 검토 프로세스를 통과한 상태입니다. 지원 중단된(deprecated) 릴리스는 마이그레이션(migration) 동안 유효하게 유지됩니다. 은퇴한(retired) 릴리스는 더 이상 새로운 작업에 선택되어서는 안 됩니다.

NexFlow의 경우, 이는 구현된 런타임 동작이라기보다는 사양 어휘(specification vocabulary)에 가깝습니다. 하지만 이 어휘는 검토 자체를 개선합니다. “에이전트를 약간 업데이트했습니다”라는 말은 다음과 같은 구체적인 변경 사항 세트로 변합니다: 새로운 모델 프로필(model profile), 수정된 프롬프트 세트(prompt set), 더 넓은 컨텍스트(context), 다른 메모리(memory), 또는 더 약화된 승인 경계(approval boundary).

동일한 식별자로는 더 이상 서로 다른 운영 조건(operating conditions)을 숨길 수 없습니다.

에이전트 이름은 팀의 누가 참여하는지를 알려줍니다. 에이전트의 정의 버전은 팀이 이 결과에 대해 어떤 참여자를 신뢰했는지를 알려줍니다.