CBIM: 왜 당신의 AI 코딩 에이전트는 대규모 코드베이스를 실제로 읽지 못하는가

시리즈 서론: 이 글은 CBIM: From AI Coding Workflow to AgenticOS 시리즈의 파트 1입니다.
CBIM은 제가 설계한 AI 코딩 워크플로우 (AI coding workflow) 아키텍처입니다. 이것의 핵심은 "더 나은 프롬프트 엔지니어링 (Prompt Engineering)"이나 "컨텍스트 관리 (Context Management) 기술"이 아닙니다. 그것은 근본적인 설계 목표, 즉 구조화된 메모리 (Memory)에 의해 유지되는 능력 (Capability)과 비즈니스/도메인 지식 (Business/Domain knowledge) 사이의 독립성을 달성하는 것입니다.
이 시리즈는 CBIM의 설계 이론, 엔지니어링 구현 및 진화 과정을 상세히 기록합니다.

⚠️ 상태: 설계 초안 / 이론적 프레임워크 (Design Draft / Theoretical Framework)
이 글은 CBIM의 핵심 설계 철학과 원칙을 제시합니다. 이는 V1 (순수 프롬프트 기반 버전)의 검증 경험에서 도출된 이론적 프레임워크이자, V2 (네이티브 에이전트를 처음부터 구축)를 위한 설계 확장입니다. 이것은 프로덕션 규모에서 검증된 "베스트 프랙티스 가이드 (Best practices guide)"가 아닙니다. 일부 메커니즘은 아직 실제 부하 하에서 테스트되지 않았습니다. 저는 정직한 토론이 이러한 아이디어들을 스트레스 테스트하고 진화시키는 가장 좋은 방법이라고 믿기 때문에 이 글을 게시합니다.

서론: 우리는 패러다임의 교차로에 서 있습니다

지난 2년 동안 AI 코딩은 "바이브 코딩 (Vibe Coding)"에서 "하네스 엔지니어링 (Harness Engineering)"으로 급격히 진화했습니다. Claude Code 및 Cursor와 같은 도구들은 실행 계층 (Execution layer)에서 놀라운 성과를 거두었습니다. 이들은 복잡한 코딩 작업을 효율적이고 높은 성공률로 완료할 수 있습니다.

하지만 관점을 "단일 작업"에서 "지속되고 진화하는 프로젝트"로 전환하면, 더 깊은 문제가 드러납니다:

왜 이토록 유능한 AI 도구들이 대규모 코드베이스 (Large codebase)를 실제로 이해하지 못하는 걸까요?

근본적인 원인은 기존 도구들의 지배적인 패러다임이 _작업 실행 최적화 (Task execution optimization)_에 있기 때문입니다. 이들은 사용자의 현재 요청을 최소한의 단계로, 가장 높은 성공률로 완료하는 데 집중합니다. 이들은 강력한 문제 해결사이지만, 자격을 갖춘 프로젝트 구성원은 아닙니다. 이들은 프로젝트의 이력을 알지 못하며, 모듈 간의 암묵적인 계약 (Implicit contracts)을 이해하지 못하고, 장기적인 협업에 걸친 전역적인 관점 (Global view)을 유지할 수 없습니다.

이는 체계적인 역설(Systemic paradox)을 만들어냅니다. AI가 작업을 수행하는 능력이 뛰어나질수록, 프로젝트 구조는 더 빠르게 붕괴될 수 있습니다. 모든 효율적인 "지역 최적점 (Local optimum)" 결정은 전체 아키텍처에 잠재적인 지뢰를 심는 행위가 될 수 있습니다.

CBIM은 이러한 근본적인 긴장 상태를 해결하기 위한 저의 시도입니다. CBIM의 목표는 Cursor를 대체하는 것이 아니라, 간과되었던 질문에 답하는 것입니다:

어떻게 하면 AI가 단순히 "작업을 실행"하는 것을 넘어, 실제로 "프로젝트를 이해하고 관리"하게 만들 수 있을까?

파트 1: CBIM 핵심 공식

CBIM은 프롬프트 엔지니어링 (Prompt engineering) 프레임워크도 아니고, 컨텍스트 관리 (Context management) 도구도 아닙니다. 그 핵심 목표는 하나의 공식으로 표현될 수 있습니다:

CBIM = Capability × Business × Independence + Memory

1. Capability (역량): 전문적인 도메인 지식 (Domain Knowledge) 모델링

Capability는 다음과 같은 질문에 답합니다: 이 에이전트는 어떤 전문적인 전문 지식을 갖추고 있는가?

모델링 관점은 현실 세계의 채용 논리를 반영합니다. 회사가 채용을 할 때, 후보자가 어떤 기술(Unity 개발, 웹 개발, 백엔드 아키텍처 등)을 가져오는지를 봅니다. 후보자의 과거 프로젝트 경험을 검토할 때도, 이전 직장의 비즈니스 로직을 통째로 가져오는 것이 아니라 유사한 문제를 해결할 수 있는 능력을 평가하는 것입니다.

Capability는 프로젝트 전반에 걸쳐 재사용 가능한 전문적 자산입니다.

Capability 유형	예시	전이 가능성 (Transferability)
도메인 전문 지식 (Domain expertise)	Unity 개발, 웹 프론트엔드, 백엔드 아키텍처, DevOps	동일한 도메인의 다른 프로젝트로 전환할 때도 여전히 적용 가능함
...

Capability는 "처리 모드 (Processing mode)"에 따라 조직됩니다: 스케줄링 (Scheduling), 추론 (Reasoning), 메모리 (Memory), 실행 (Execution). 이것들은 비즈니스 요구사항에 따라 변하지 않는 안정적인 인지 기술입니다. (구체적인 피질 영역 아키텍처는 파트 2에서 다룰 예정입니다.)

구현 방식에 관계없이, 핵심 원칙은 **역량-비즈니스 디커플링 (Capability-Business decoupling)**입니다. 즉, 역량은 독립적으로 진화 가능한 자산입니다.

2. 비즈니스 (Business): 프로젝트 특화 도메인 지식 모델링

비즈니스는 다음과 같은 질문에 답합니다: 이 에이전트가 현재 작업 중인 프로젝트의 도메인 구조는 무엇인가?

비즈니스 지식은 프로젝트 간에 재사용할 수 없습니다. 모든 프로젝트는 고유한 비즈니스 로직 (Business logic), 모듈 분해 (Module decomposition), 도메인 규칙 (Domain rules), 그리고 역사적 결정 사항들을 가지고 있습니다. 설령 두 프로젝트 모두에 "결제 모듈 (Payment module)"이 있다고 하더라도, 그 인터페이스 계약 (Interface contracts), 비즈니스 규칙, 그리고 의존성 (Dependencies)은 완전히 다를 수 있습니다.

비즈니스 지식은 현재 프로젝트 자체로부터 성장해야 하는 프로젝트 특화 컨텍스트 (Project-specific context)입니다.

비즈니스 요소	예시	출처
모듈 구조	모듈 트리 (Module tree), 서브 모듈 분해, 의존성 그래프	프로젝트 설계 문서 + 코드 구조
...

비즈니스 지식은 "도메인 구조 (Domain structure)"에 의해 조직되어 프로젝트의 지식 지도 (Knowledge map)를 형성합니다. 결제 모듈, 주문 모듈, 사용자 모듈 등이 이에 해당하며, 각 노드는 고유한 인터페이스 계약과 설계 제약 조건을 가집니다. (모듈 트리 구현은 파트 2에서 다룰 예정입니다.)

3. 독립성 (Independence): 디커플링 및 독립적 진화

역량 (Capability)과 비즈니스 (Business)는 서로 직교(Orthogonal)해야 하며, 디커플링되어 있고, 독립적으로 진화할 수 있어야 합니다.

독립성의 모습	설명
비즈니스를 교체하고 역량을 재사용	"Unity 개발자" 에이전트가 새로운 게임 프로젝트로 전환할 때: 역량은 유효하게 유지되며, 단지 새로운 프로젝트의 모듈 트리만 로드하면 됨
...

독립성은 CBIM과 기존의 모든 도구 사이의 가장 근본적인 차이점입니다.

기존 도구들은 역량과 비즈니스를 하나로 융합합니다 (프롬프트가 역량 선언인 동시에 비즈니스 바인딩인 "프론트엔드 에이전트"를 작성하는 방식). 반면 CBIM은 이를 분리합니다: 역량은 자산(Asset)이고, 비즈니스는 컨텍스트(Context)입니다. 자산은 축적되고 재사용 가능하지만, 컨텍스트는 교체 가능하며 진화합니다.

이것이 실제 환경에서 무엇을 의미할까요?

웹 프로젝트에서 모바일 프로젝트로 전환할 때, 에이전트의 "코드 분석 (code analysis)" 및 "아키텍처 추론 (architecture reasoning)" 능력은 다시 학습할 필요가 없습니다. 단지 그 능력이 작동하는 비즈니스 지식만 변경될 뿐입니다.
에이전트의 "테스트 생성 능력 (test generation capability)"을 강화하고 싶을 때, 기존의 모듈 트리 구조나 비즈니스 경계(business boundaries)를 방해하지 않습니다.

4. Memory: 독립성을 지탱하는 메커니즘

구조화된 메모리 (Memory) 없이는 능력(Capability)과 비즈니스(Business)의 독립성을 실제로 구현할 수 없습니다. 메모리는 다음을 담당합니다:

기능	설명
매핑 관계 기록	어떤 종류의 비즈니스를 처리할 때 어떤 능력이 가장 잘 작동하는가? 과거의 경험은 무엇을 말해주는가?
...

컨텍스트 최소화 (Context minimization)는 목표가 아니라 결과입니다.

능력과 비즈니스 도메인이 올바르게 정의되어 독립적으로 유지되고, 메모리가 적절한 매핑 관계를 제공할 때, 모든 스케줄링 또는 추론 작업에 필요한 컨텍스트는 이론적으로 자연스럽게 최소화됩니다.

5. Side-by-Side: 기존 도구 vs. CBIM

기존 도구의 작동 방식

입력	설명
요청 (Request)	사용자가 지금 당장 완수하고자 하는 작업
예시	"결제 모듈의 타임아웃 버그를 수정해줘"
...

흐름: 사용자가 요청을 제출 → 도구가 요청 + 혼합된 프롬프트 (mixed prompt) + 프로젝트 전체 컨텍스트를 LLM에 밀어 넣음 → LLM이 답변을 생성하거나 동작을 실행함.

문제점: 에이전트의 "능력"과 "비즈니스"가 하나로 용접되어 있습니다. 워크스페이스 범위는 정밀한 타겟팅 없이 "프로젝트 전체"이며, 그 사이에 구조적 사고 계층 (structural thinking layer)이 존재하지 않습니다.

CBIM의 작동 방식

입력	설명	CBIM의 차이점
요청 (Request)	사용자가 완수하고자 하는 작업	동일한 시작점
...

흐름: 사용자가 요청을 제출 → CBIM이 능력 그래프 (capability graph) + 비즈니스 구조 트리 (business structure tree) + 메모리를 분석 → 이론적으로 최소화된 작업 목록을 자동으로 생성함.

해당 작업 목록(task list)의 각 항목 또한 그 자체로 최소화됩니다:

작업 요소 (Task Element)	최소화의 모습
요구사항 파편 (Requirement fragment)	"결제 모듈 버그 수정"이 아니라, "잠금 세분화(lock granularity) 문제 위치 파악" 및 "타임아웃 설정 확인"과 같이 분리된 원자(atoms) 단위로 구성
...

한 줄 요약:

	기존 도구 (Existing Tools)	CBIM
핵심 로직 (Core logic)	요청(Request) → LLM (혼합된 프롬프트 + 전체 프로젝트) → 답변	요청(Request) → 역량 그래프(capability graph) + 비즈니스 그래프(business graph) + 메모리(memory) → 최소화된 작업 목록
본질 (Essence)	하나의 LLM이 혼란스러운 컨텍스트에 직접 직면함	스케줄링 엔진(scheduling engine)이 먼저 분해한 후, 정밀하게 범위가 지정된 작업 공간(workspaces)에서 실행하도록 특화된 역량들을 할당함

파트 2: 핵심 메커니즘 — 독립성과 메모리에 기반한 자동 스케줄링

단계 (Step)	작업 (Action)	출력 (Output)
1. 역량-비즈니스 식별 (Capability-Business identification)	요청의 어느 부분이 역량(capability)에 의존하는지, 어느 부분이 비즈니스(business)에 의존하는지 구분	역량 차원(Capability-dimension) 및 비즈니스 차원(Business-dimension) 레이블
...

사용자는 목표를 말하기만 하면 됩니다. CBIM은 역량-비즈니스 독립성(Capability-Business independence)과 메모리(Memory)를 기반으로, 가장 군더더기 없고 적절한 할당 계획(dispatch plan)을 자동으로 생성합니다.

파트 3: 네 가지 핵심 설계 원칙

원칙 1: 역량-비즈니스 디커플링 (Capability-Business Decoupling)

반대 사례: 프롬프트 내에서 "나는 프론트엔드 전문가이다(역량)"를 "나는 React 컴포넌트를 다룬다(비즈니스)"와 깊게 결합시킨 "프론트엔드 에이전트"를 작성하는 경우입니다. 이 에이전트를 Flutter 프로젝트로 전환하면, 에이전트 전체가 쓸모없게 됩니다.

CBIM의 실제 적용:

역량 측면 (Capability side): "처리 모드 (processing mode)"에 따라 피질 구역(cortex zones: 전전두엽, 두정엽, 해마, 운동 피질)으로 분할됩니다. 이 구역들은 특정 프로젝트와 무관하게 에이전트가 가진 고유한 구조입니다.
비즈니스 측면 (Business side): "도메인 구조 (domain structure)"에 따라 모듈 트리(Workspace)로 구성되며, 각 노드는 해당 비즈니스 모듈의 지식과 계약(contracts)을 보유합니다.

이 두 가지는 서로 직교(orthogonal)하며 런타임(runtime) 시 동적으로 결합됩니다. 프로젝트를 전환하더라도 역량 피질 구역은 변하지 않으며, 단지 새로운 모듈 트리를 로드할 뿐입니다.

원칙 2: 구조의 외재화 (Structure Externalization)

LLM이 머릿속에 안정적으로 담아둘 수 없는 것이라면 — 그것을 암기하게 하지 마십시오. 결정론적(deterministic)이어야 하는 것이라면 — 그것을 추론하게 하지 마십시오.

제어 흐름의 외재화 (Control flow externalization): 자연어 프롬프트로부터 워크플로우(workflow)를 추출하여 결정론적 구조로 표현합니다. LLM은 실제로 판단이 필요한 곳에서만 결정을 내리며, 워크플로우 오케스트레이션(orchestration)은 결정론적 엔진이 담당합니다.
전체 맥락의 외재화 (Big-picture externalization, 모듈 트리): LLM이 프로젝트 전체를 한 번에 이해하도록 요구하지 마십시오. 프로젝트 구조를 확대/축소 가능한 모듈 트리로 외재화합니다. LLM은 한 번에 하나의 로컬 노드에서만 작동하며, 계층화된 계약(layered contracts)을 통해 전역적인 정확성(global correctness)을 보장합니다.

원칙 3: 구조적 동형성 (Structural Isomorphism)

동일한 모델링 아이디어가 서로 다른 규모에서 반복됩니다.

로컬의 "전전두엽 스케줄링 피질 구역 (prefrontal scheduling cortex zone)"은 네트워크 버전에서 "전문 에이전트들을 스케줄링하는 PM 에이전트"에 대응합니다. (파트 3에서 다룹니다.)

원칙 4: 엔트로피 감소 루프 (Entropy-Reduction Loop)

호출될 때만 작동하는 시스템은 시간이 지남에 따라 성능이 저하됩니다: 메모리 비대화(memory bloat), 지식 드리프트(knowledge drift), 역량 노후화(capability staleness).

시스템에는 유휴 시간(idle-time) 동안의 자가 유지보수가 필요하며, 우리는 이를 **드림 루프 (Dream loop)**라고 부릅니다. 이는 단기 경험을 장기적인 구조화된 지식으로 증류하여 엔트로피에 대응합니다.

드림(Dream)은 있으면 좋은 기능(nice-to-have)이 아닙니다. 이는 CBIM의 지속 가능성을 위한 구조적 기둥이며, 시스템 수준에서 메모리(Memory) 메커니즘을 운반하는 핵심 요소입니다.