NexFlow: AI 개발 팀을 위한 공통 언어

이 글은 또 다른 표준을 발명하려는 추상적인 시도로 시작된 것이 아닙니다.

실무에서 비롯되었습니다.

저는 소프트웨어 개발, 문서화, 프로젝트 조사, 지식 저장소 (knowledge-vault) 유지 관리, 작업 계획, 그리고 때로는 일반적인 업무 시나리오에서도 AI 에이전트 (AI agents)를 많이 사용합니다. 이들과 함께 일하면 할수록, 한 가지 반복되는 문제가 점점 더 명확하게 보입니다.

우리는 종종 우리가 같은 것에 대해 이야기하고 있다고 생각합니다.

하지만 실무에서 우리는 종종 서로 다른 것을 의미합니다.

현재 더 많은 AI 지원 개발 도구들이 존재합니다. 더 많은 에이전트 (agents), 더 많은 코파일럿 (copilots), 더 많은 자동화 레이어 (automation layers)가 있습니다. 많은 제품들이 워크플로 (workflows), 메모리 (memory), 컨텍스트 (context), 도구 (tools), 권한 (permissions), 승인 (approvals), MCP, 에이전트 (agents), 그리고 인간 참여형 (human-in-the-loop) 시스템에 대해 이야기합니다.

하지만 공유된 언어는 여전히 부족합니다.

어떤 도구는 "에이전트 (agent)"라고 말하며 저장소 접근 권한이 있는 채팅 인터페이스를 의미합니다. 다른 도구는 "에이전트 (agent)"라고 말하며 자율적인 작업자를 의미합니다. 세 번째 도구는 "워크플로 (workflow)"라고 말하지만, 그것은 프롬프트 체인 (prompt chain), CI 파이프라인 (CI pipeline), 작업 계획 (task plan), 또는 단순히 멋진 다이어그램을 의미할 수도 있습니다. "메모리 (memory)"는 채팅 기록, 벡터 데이터베이스 (vector database), 프로젝트 노트, 사용자 프로필, 또는 조직의 지식을 의미할 수 있습니다. "권한 (permission)"은 시스템 프롬프트 (system prompt), 승인 버튼, GitHub 토큰, 정책 파일, 또는 비공식적인 팀 합의를 의미할 수 있습니다.

한 사람이 한 명의 어시스턴트 (assistant)와 함께 일하는 동안에는 이것이 용인될 수 있습니다.

하지만 업무에 여러 명의 사람, 여러 개의 에이전트, 여러 개의 저장소, 여러 개의 도구, 그리고 프로젝트 내부의 실제 동작이 포함될 때, 문제는 심각해집니다.

그 시점에서 질문은 더 이상 모델이 얼마나 똑똑한가에 그치지 않습니다.

질문은 작업 그 자체를 어떻게 기술하느냐입니다.

문제는 에이전트만이 아니다

AI 개발 도구 분야에서 우리는 종종 너무 빠르게 다음과 같은 질문으로 건너뜁니다: "이 에이전트가 무엇을 할 수 있는가?"

그 질문도 중요합니다. 하지만 그 질문에 앞서, 더 지루하고 더 근본적인 질문들이 있습니다.

누가 프로젝트에 참여하는가? 각 액터(Actor)의 책임은 무엇인가? 어떤 컨텍스트 소스(Context sources)를 읽을 수 있는가? 접근이 금지된 소스는 무엇인가? 작업이 끝난 후에도 유지될 수 있는 메모리(Memory)는 무엇인가? 에이전트가 제안만 할 수 있는 액션(Action)은 무엇이며, 직접 수행할 수 있는 액션은 무엇인가? 검토(Review)가 필요한 지점은 어디인가? 위험한 변경 사항을 누가 승인하는가? 무엇을 핸드오프(Handoff)로 간주할 것인가? 감사 추적(Audit trail)에는 무엇이 포함되어야 하는가?

이러한 사항들이 명시적으로 기술되지 않는다면, 시스템은 여전히 작동할 수도 있습니다.

단지 습관, 숨겨진 프롬프트(Prompts), 도구별 특정 설정, 그리고 인간의 기억을 통해 작동할 뿐입니다.

초기에는 괜찮습니다. 하지만 확장성(Scale) 측면에서는 좋지 않습니다.

AI가 엔지니어링 작업의 일부가 될 때, 부족한 계층(Layer)은 또 다른 아름다운 UI나 또 다른 프롬프트 목록이 아닙니다.

부족한 계층은 읽을 수 있고, 논의할 수 있으며, 확인하고, 비교하고, 도구 간에 이동할 수 있는 무언가입니다.

더 간단히 말하자면, 명세 계층(Specification layer)입니다.

내가 NexFlow를 시작한 이유

나는 그러한 공통 언어를 만들기 위한 시도로 NexFlow를 시작했습니다.

NexFlow는 AI 개발 팀을 기술하기 위한 오픈 명세 우선(Specification-first) 프로젝트입니다.

저장소(Repository)는 여기서 공개되어 있습니다:

https://github.com/iwizy/NexFlow

경계가 중요합니다: NexFlow는 AI 코딩 에이전트(Coding agent), LLM 래퍼(Wrapper), 채팅 애플리케이션, 또는 프로덕션 런타임(Runtime)이 아닙니다.

현 단계에서 이것은 명세(Specification), 문서(Documentation), JSON 스키마(JSON Schemas), 참조 예제(Reference examples), 그리고 RFC 프로세스입니다.

나는 런타임(Runtime)이 아닌 언어(Language)부터 시작하고 싶었습니다.

너무 일찍 런타임부터 시작하면, 현재의 선호도를 코드에 고착시키기 쉽습니다: 특정 제공자(Provider), 특정 메모리 모델(Memory model), 특정 권한 모델(Permission model), 특정 워크플로우(Workflow) 등 말이죠. 그렇게 되면 명세는 단지 하나의 제품을 설명하는 것에 불과하게 됩니다.

나는 그 반대를 원했습니다.

먼저, 언어를 기술하는 것부터 시작해야 합니다.

팀이 프로젝트, 에이전트 (agents), 작업 (tasks), 인계 (handoffs), 권한 (permissions), 기능 (capabilities), 컨텍스트 소스 (context sources), 메모리 범위 (memory scopes), 제공자 (providers), 이벤트 (events), 그리고 확장 기능 (extensions)을 어떻게 선언적으로 기술할 수 있을까요? 어떻게 하면 읽기에 충분히 단순하면서도, 스키마 (schemas)로 검증하고 나중에 실행할 수 있을 만큼 충분히 구조화될 수 있을까요?

현재 버전은 여전히 초기 초안 단계입니다.

하지만 이미 작업을 더 정밀하게 논의하기 위한 방법으로서 유용합니다.

기능 (Capability)은 권한 (Permission)이 아니다

NexFlow의 핵심적인 구분 중 하나는 기능 (capability) 대 권한 (permission)입니다.

기능 (capability)은 액터 (actor)가 기술적으로 무엇을 할 수 있는지를 의미합니다.

예를 들어: 저장소 (repository) 읽기, 파일 수정, 풀 리퀘스트 (pull request) 생성, 명령 실행, Linear 접속, MCP 서버 호출, 또는 문서 읽기 등이 있습니다.

권한 (permission)은 정책 결정입니다: 해당 동작이 허용되는지, 거부되는지, 또는 승인 절차를 거쳐야 하는지를 결정합니다.

실제로 이 구분은 당연하게 들립니다. 하지만 실제 AI 도구들에서는 종종 모호하게 처리됩니다.

만약 에이전트 (agent)가 기술적으로 도구를 호출할 수 있다면, 그것이 호출을 허용한다는 의미일까요? GitHub 이슈 (issue)를 읽을 수 있다면, 그 이슈를 수정할 수도 있을까요? 문서를 볼 수 있다면, 그 결과를 장기 메모리 (long-term memory)로 저장할 수 있을까요? 로컬 파일 시스템 (local filesystem) 접근 권한이 있다면, 어디에나 쓸 수 있을까요?

진지한 시스템이라면, 그 답이 현재 채팅의 기분에 따라 달라져서는 안 됩니다.

명시적으로 선언되어야 합니다. 기능 (capability)이 자동으로 동작을 승인해서는 안 됩니다.

이는 작은 차이지만, 이를 중심으로 더 통제 가능한 시스템을 구축할 수 있습니다.

컨텍스트 (Context) 또한 명시적이어야 한다

AI 에이전트 (agent)는 빈 공간에서 작동하지 않습니다.

에이전트는 저장소 (repositories), 작업 (tasks), 문서 (documentation), 설계 파일 (design files), 이슈 트래커 (issue trackers), 지식 베이스 (knowledge bases), 결정 이력 (decision history), Obsidian 볼트 (Obsidian vaults), Linear 프로젝트 (Linear projects), Figma 파일 (Figma files), MCP 서버 (MCP servers), 웹 소스 (web sources), 그리고 로컬 파일 (local files)을 읽습니다.

하지만 컨텍스트 (context)는 단순히 "모델에게 더 많은 텍스트를 주는 것"이 아닙니다.

컨텍스트 (context)는 소스 (source), 접근 모드 (access mode), 최신성 (freshness), 분류 (classification), 소유자 (owner), 제한 사항 (limitations), 그리고 위험 수준 (risk level)을 가집니다.

공개된 README를 읽는 것과 내부 로드맵 (roadmap)을 읽는 것은 별개의 문제입니다. 프로덕션 로그 (production logs)를 여는 것도 별개이며, 개인 데이터를 사용하는 것도 별개입니다. 그 결과를 장기 메모리 (long-term memory)에 저장하는 것은 또 다른 문제입니다.

만약 이러한 소스들이 기술되지 않는다면, AI 시스템은 안개 속에서 작동하기 시작합니다.

마치 에이전트 (agent)가 "프로젝트를 알고 있는" 것처럼 느껴집니다.

하지만 그 지식은 어디에서 왔을까요? 최신 정보인가요? 허용된 것인가요? 누가 접근을 승인했나요? 작업이 끝난 후 무엇이 유지될까요?

NexFlow에서는 컨텍스트 소스 (context sources)를 명시적으로 선언해야 합니다.

단순히 그것이 우아해 보이기 때문이 아닙니다.

그것 없이는 보안 (security), 품질 (quality), 그리고 책임 (responsibility)에 대해 솔직하게 논의하기 어렵기 때문입니다.

메모리는 마법 같아서는 안 된다

모두가 AI가 "컨텍스트를 기억하기"를 원합니다.

저도 원합니다. 하지만 경계가 없는 메모리는 빠르게 잡동사니 서랍이 되고, 개인정보 보호 위험이 되며, 이상한 결정의 원인이 됩니다. 특히 에이전트가 한 작업의 컨텍스트를 다른 작업으로, 한 프로젝트에서 다른 프로젝트로, 또는 한 사용자에서 다른 사용자로 가져갈 때 더욱 그렇습니다.

따라서 메모리는

구현 에이전트 (implementation agent)가 작업을 완료하면, 리뷰어 (reviewer)에게 정확히 무엇을 전달하게 될까요? 어떤 아티팩트 (artifacts)가 포함될까요? 수락 기준 (acceptance criteria)은 무엇인가요? 무엇이 차단 (blocked)된 상태로 남아 있나요? 무엇이 테스트되었나요? 무엇이 테스트되지 않았나요? 어떤 결정이 내려졌나요? 인간의 판단 (human judgment)이 필요한 부분은 어디인가요?

적절한 핸드오프 (handoff) 없이는, 작업이 그저 메시지의 흐름이 되어버립니다.

적절한 핸드오프가 있다면, 작업은 상태 (state)를 갖게 됩니다.

그리고 상태는 읽히고, 검토되고, 자동화되며, 유지될 수 있습니다.

왜 명세 우선 (Specification-First) 인가

다음과 같은 질문을 던지는 것은 타당합니다: 왜 즉시 CLI나 런타임 (runtime)을 구축하지 않나요?

명확한 모델이 없는 런타임은 너무 일찍 아키텍처 결정 (architectural decisions)을 내리기 시작하기 때문입니다.

상태가 어떻게 저장될지, 에이전트 (agents)의 이름은 어떻게 지을지, 권한 (permissions)은 어떻게 작동할지, 메모리 (memory)는 어떻게 기록될지, 프로바이더 (providers)는 어떻게 선택될지, 승인 (approvals)은 어떻게 이루어질지, 이벤트 (events)는 어떻게 로그 (log)로 남을지를 결정해 버립니다.

너무나 자주, 이러한 결정들은 하나의 제품 내부에만 머물게 됩니다.

저는 다른 계층 (layer)에 관심이 있습니다.

런타임이 존재하기 전부터 유용한 계층 말입니다.

팀은 매니페스트 (manifests)를 통해 프로젝트를 설명할 수 있어야 합니다: 누가 참여하는지, 어떤 에이전트가 존재하는지, 그들이 무엇을 할 수 있는지, 어떤 컨텍스트 소스 (context sources)를 사용할 수 있는지, 승인이 필요한 곳은 어디인지, 어떤 메모리가 허용되는지, 그리고 어떤 이벤트를 감사 (audited)해야 하는지 말입니다.

설령 아무것도 자동으로 실행되지 않더라도, 해당 설정은 이미 검토 가능한 문서로서 유용합니다.

런타임은 나중에 와도 됩니다.

그 반대가 되어서는 안 됩니다.

현재 존재하는 것

NexFlow는 현재 초안 단계인 0.1 매니페스트 어휘 (manifest vocabulary)를 보유하고 있습니다.

핵심 파일 세트에는 다음이 포함됩니다:

project.yaml, agents.yaml, agent-definitions.yaml, workflow.yaml, tasks.yaml, handoffs.yaml, permissions.yaml, capabilities.yaml, context.yaml, memory.yaml, providers.yaml, model-profiles.yaml, prompt-sets.yaml, retrieval-profiles.yaml, events.yaml, 그리고 extensions.yaml.

핵심 개념(core concepts), 매니페스트 참조(manifest reference), 컨텍스트 모델(context model), 메모리 모델(memory model), 자율성 모델(autonomy model), 역량 모델(capability model), 핸드오프 프로토콜(handoff protocol), 이벤트 모델(event model), 에이전트 정의(agent definitions), 모델 프로파일(model profiles), 프롬프트 세트(prompt sets), 검색 프로파일(retrieval profiles), 확장 기능(extensions), 제공자 추상화(provider abstraction), 보안(security), 거버넌스(governance), 검증(validation), 그리고 준수(conformance)에 대한 문서가 있습니다.

매니페스트를 위한 실용적인 초안 JSON Schema도 존재합니다.

최소 규모, 소프트웨어, 스타트업, 엔터프라이즈, 제품 배포 팀을 위한 참고 예시들이 마련되어 있습니다.

또한 RFC(Request for Comments) 프로세스가 있으며, 여기에는 승인된 프로젝트 비전 및 핵심 매니페스트 RFC와 준수, 검증, 확장 네임스페이스, 승인 게이트, 에이전트 정의 버전 관리와 관련된 여러 활성 초안 RFC가 포함되어 있습니다.

그리고 중요한 제한 사항이 하나 더 있습니다. 이것은 아직 런타임(runtime)이 아니라는 점입니다.

NexFlow는 워크플로우를 실행하지 않습니다. 제공자(providers)를 호출하지 않습니다. 에이전트를 구동하지 않습니다. 프로덕션 메모리를 영속시키지 않습니다. 또한, 프로덕션용 CLI도 아직 제공하지 않습니다.

이는 의도된 바입니다.

먼저 언어(language)가 오고, 그다음 검증(validation)이 오고, 마지막으로 런타임 결정(runtime decisions)이 오는 것입니다.

이것이 실제 의미하는 바는 무엇인가요

실질적인 질문도 중요합니다. 만약 런타임이 아직 워크플로우를 실행하지 못한다면, 개발자나 팀은 이 설명에서 무엇을 얻게 될까요?

답변은 간단합니다. 검토 가능한 아티팩트(reviewable artifact)입니다.

팀은

이는 도구를 비교하고, 검토를 준비하며, 보안 모델을 설명하고, 핸드오프 (handoff)를 설계하며, 기술적 역량과 조직적 권한을 혼동하는 것을 방지하는 데 도움을 줍니다.

이것이 나중에 왜 중요할 수 있는가

모든 팀이 내일부터 당장 AI 팀 매니페스트 (AI-team manifests)를 작성하기 시작할 것이라고는 생각하지 않습니다.

보통 그런 일들은 그렇게 일어나지 않습니다.

하지만 이러한 언어에 대한 필요성은 커질 것이라고 생각합니다.

AI 에이전트 (AI agent)가 개인 비서처럼 행동할 때는 채팅만으로 충분합니다. 하지만 AI 에이전트가 개발, 지원, 분석, QA, 문서화, 릴리스 프로세스 및 제품 인도 (product delivery)의 일부가 될 때, 기업들은 실제로 어떤 일이 일어나고 있는지 알고 싶어 할 것입니다.

누가 무엇에 접근할 수 있었는지.

왜 에이전트가 특정 동작을 수행하도록 허용되었는지.

누가 위험한 작업을 승인했는지.

어떤 컨텍스트 (context)가 사용되었는지.

어떤 메모리 (memory)가 기록되었는지.

왜 작업이 한 액터 (actor)에서 다른 액터로 이동했는지.

무엇이 자동으로 수행되었고, 무엇이 제안되었을 뿐인지.

공통된 언어가 없다면, 각 도구는 이러한 질문에 자신만의 방식으로 답할 것입니다.

공통된 언어가 있다면, 이식성 (portability), 감사 가능성 (auditability), 비교 가능성, 그리고 AI 지원 엔지니어링의 더 차분한 진화의 가능성이 열립니다.

핵심 요점

NexFlow에는 마법 같은 것이 없습니다.

솔직히, 저는 그 점이 마음에 듭니다.

훌륭한 기초 시스템 (foundational systems)은 종종 처음에는 지루해 보입니다. 이들은 일주일 만에 팀을 대체하겠다고 약속하지 않습니다. 에이전트가 "그냥 모든 것을 다 할 것"이라고 말하지도 않습니다. 대신 현실을 더 정확하게 설명할 수 있는 방법을 제공합니다.

AI 분야에서는 이것이 특히 중요합니다.

모델과 도구가 강력해질수록, 단순히 무언가를 수행하는 것뿐만 아니라 누가 그것을 했는지, 왜 그것이 허용되었는지, 어떤 컨텍스트가 사용되었는지, 그리고 누구의 책임하에 발생했는지를 이해하는 것이 더욱 중요해집니다.