고도화 로드맵

지금까지 §1~§4에서 다룬 것은 ai-workspace-standards의 현재 구현이다. 이 절은 그 반대 — 아직 구현되지 않았지만 저장소가 나아가고 있는 다섯 가지 방향을 다룬다. 인프라 수준(컨테이너 연계·메모리 취합·variant 배포 자동화) 세 가지와 거버넌스 수준(보일러플레이트 전략·모델 티어 전략) 두 가지로 나뉜다.

컨테이너 기반 서비스 연계

현재 각 베리언트(variant)로 스캐폴딩된 프로젝트는 로컬 워크스페이스 안에서 Claude Code/App, Antigravity, Codex 같은 AI 코딩 도구와 직접 연동되는 방식으로만 동작한다. 하지만 실제 기업 환경에서는 프로젝트 단위로 독립적인 서비스로 배포되어야 하는 경우가 많다.

고도화의 핵심은, 스캐폴딩된 프로젝트가 Docker 또는 Kubernetes 환경에서 **Open WebUI 같은 프론트엔드 서비스와 연계되어 개인 단위로 지원**될 수 있어야 한다는 점이다. 각 사용자가 자신에게 할당된 에이전트 팀을 브라우저 인터페이스를 통해 호출하고, 결과를 확인하고, 세션 간 컨텍스트를 유지할 수 있는 형태다.

메모리 취합과 정리

현재 각 L3 프로젝트는 독립적인 memory/YYYY-MM-DD.md 파일을 유지한다(5장 §4에서 다룸). 이 파일은 해당 프로젝트의 세션 간 컨텍스트를 기록하지만, 프로젝트가 늘어날수록 메모리 파일도 산재되어 전체 워크스페이스 수준에서의 인사이트를 파악하기 어려워진다.

고도화의 두 번째 축은, 개별 프로젝트 단위로 흩어져 있는 메모리 파일들을 **취합해서 정리할 수 있는 기능**이 필요하다는 점이다. 예를 들어 "지난 주 모든 프로젝트에서 에이전트 팀이 어떤 패턴의 오류를 자주 겪었는가", "어떤 역할 조합이 가장 자주 쓰였는가" 같은 워크스페이스 수준의 트렌드 분석이 가능해져야 한다.

variant 배포 방식의 진화

현재 variant 배포는 new-project.ts에 의한 로컬 스캐폴딩 중심이고, 템플릿 갱신이 L2에 자동으로 전파되지 않는 포크 모델을 따른다. 이 방식은 의도한 차이를 보존한다는 장점이 있지만, 운영 관점에서는 템플릿의 버그 수정이나 보안 패치가 각 프로젝트에 일일이 수동 반영되어야 한다는 부담을 만든다.

고도화 방향으로는 (a) 포크 모델의 장점을 유지하면서도 보안 패치나 중요 버그 수정만 선택적으로 L2에 전파할 수 있는 **동의 기반(consent-based) 수신 모델**, (b) 베리언트(variant)를 중앙 레지스트리에서 관리하고 new-project.ts가 네트워크를 통해 최신 버전을 끌어오는 **비동기 배포 파이프라인**이 거론된다.

위 세 가지가 인프라 수준의 고도화 방향이라면, 아래 두 가지는 거버넌스 수준의 고도화 방향이다 — §1과 §4에서 다룬 보일러플레이트 전략·모델 티어 전략이 지금 어떤 한계를 갖고 있고, 어느 방향으로 다듬어질 수 있는지를 다룬다.

보일러플레이트 전략 고도화

§1·§4에서 LOCKED·MERGE·PRESERVE·SYNC_IF_NEWER·PRUNE 5분류를 "무엇을 잠그고 무엇을 열어 둘지"의 판단 기준으로 다뤘다. 지금 이 분류는 upgrade-project.ts 코드 안에 파일 경로 단위로 하드코딩돼 있다 — 어떤 파일이 LOCKED인지, MERGE인지는 스크립트를 고쳐야만 바뀐다. 이 방식은 저장소가 관리하는 파일 종류가 적을 때는 문제가 없지만, 조직마다 "우리는 이 파일도 LOCKED로 취급하고 싶다"거나 "이 MERGE 파일은 우리 조직에서는 완전히 PRESERVE로 풀고 싶다" 같은 예외가 늘어날수록 스크립트 자체를 포크해야 하는 부담으로 이어진다.

고도화 방향은 이 분류를 코드가 아니라 선언적 매니페스트로 옮기는 것이다. 예를 들어 워크스페이스 루트에 boilerplate-policy.json 같은 파일을 두고, 각 조직이 자신의 LOCKED/MERGE/PRESERVE 경계를 파일 패턴 단위로 재정의할 수 있게 하는 방향이 거론된다. 이렇게 되면 upgrade-project.ts는 하드코딩된 분류표 대신 이 매니페스트를 읽어 동작하게 되고, 조직은 스크립트를 건드리지 않고도 자신들의 보안·거버넌스 기준에 맞게 경계를 조정할 수 있다.

모델 티어 전략 고도화

§1·§4에서 tier 배정이 agents/*.md frontmatter에 정적으로 박혀 있고, L0에서 바뀌면 upgrade-project.ts의 SYNC_IF_NEWER로만 전파된다는 것을 봤다. 이 방식의 한계는 티어 배정이 "역할"에만 묶여 있고, 실제 작업의 난이도나 조직의 비용 예산은 반영하지 못한다는 점이다. 예를 들어 code-writer 역할은 항상 medium이지만, 실제로는 프로젝트마다 code-writer가 다루는 코드베이스의 복잡도가 크게 다르다. 지금 구조에서는 이 차이를 반영하려면 사람이 직접 각 프로젝트의 agents/*.md를 손으로 고쳐야 한다.

고도화 방향으로는 (a) 세션 로그나 /cost 데이터를 근거로 "이 역할은 최근 N번의 세션에서 반복적으로 재시도가 발생했다 → high로 올리는 것을 권장" 같은 운영 데이터 기반 티어 추천, (b) 워크스페이스 전체 또는 조직 단위로 "이번 달 예산은 이 정도이니 high 티어 배정은 N개 역할로 제한한다" 같은 티어 예산 상한 governance가 거론된다. 두 방향 모두 지금의 "정적 배정 + 수동 오버라이드" 모델을 유지하면서, 그 위에 관측 가능성(observability)과 조직 정책을 얹는 확장이다.