AI 코딩 에이전트(AI coding agents)는 이미 많은 컨텍스트(context)에 접근할 수 있습니다.

그들은 저장소(repositories)를 인덱싱하고, 파일을 검색하며, 문서를 검색(retrieve)하고, Git 히스토리를 조사하며, MCP 도구를 사용하고, 다양한 형태의 세션 메모리(session memory)를 유지할 수 있습니다.

하지만 Contorium을 구축하면서 저는 다른 문제에 계속 직면했습니다.

저장소 컨텍스트(Repository context)는 프로젝트 이해(project understanding)와는 다른 것입니다.

누락된 레이어

저장소는 에이전트에게 다음과 같은 정보를 알려줄 수 있습니다:

src/
auth/
api/
database/
services/

또한 어떤 함수가 존재하는지, 모듈들이 서로 어떻게 의존하는지도 알려줄 수 있습니다.

하지만 에이전트에게 다음과 같은 점들은 알려주지 못할 수 있습니다:

왜 이 아키텍처(architecture)가 선택되었는가?
왜 다른 접근 방식은 거부되었는가?
어떤 제약 사항(constraints)이 의도적인 것인가?
어떤 결정들이 여전히 유효한가?
원래 설계 이후 무엇이 바뀌었는가?
현재 프로젝트의 상태는 무엇인가?

이러한 정보는 종종 커밋(commits), 대화(conversations), 이슈(issues), 문서(documentation), 그리고 — 가장 중요하게는 — 개발자 자신의 추론(reasoning)에 분산되어 있습니다.

그것이 바로 제가 실험하고 있는 레이어입니다.

프로젝트 인텔리전스 (Project Intelligence)

Contorium은 이 레이어를 프로젝트 인텔리전스(Project Intelligence)라고 정의합니다.

높은 수준(High level)에서 보면 다음과 같습니다:

의도 (Intent)
↓
결정 (Decisions)
↓
추론 (Reasoning)
↓
구현 (Implementation)
↓
결과 (Outcomes)
↓
진화 (Evolution)
↓
현재 상태 (Current State)

중요한 부분은 단순히 이러한 객체들을 저장하는 것이 아닙니다.

그것들을 연결하는 것입니다.

예를 들어:

결정 (Decision)
│
├── 동기 부여됨 → 제약 사항 (Constraint)
│
├── 구현됨 → 모듈 (Module)
│
├── 대체됨 → 새로운 결정 (New Decision)
│
└── 결과로 이어짐 → 결과 (Outcome)

이는 또 다른 평면적인 메모리 저장소(flat memory store)가 아닌, 프로젝트 수준의 지식 구조를 생성합니다.

Contorium의 위치

아키텍처는 의도적으로 AI 코딩 도구와 분리되어 있습니다:

┌─────────────────────────────────────────┐
│ AI 도구 (AI Tools) │
│ │
│ Cursor · Claude Code · Codex · VS Code │
└───────────────────┬─────────────────────┘
│
▼
CIL — 인지 상호작용 레이어 (Cognitive Interaction Layer)
│
▼
프로젝트 인텔리전스 (Project Intelligence)
│
▼
.contora/
│
▼
당신의 프로젝트 (Your Project)

CIL은 상호작용 레이어(interaction layer)입니다.

프로젝트 인텔리전스는 지속적인 프로젝트 수준의 상태(persistent project-level state)입니다.

.contora/ 디렉토리는 해당 인텔리전스를 프로젝트 자체와 연결하여 유지합니다.

이러한 분리는 매우 중요한데, AI 런타임 (AI runtime)이 프로젝트에 축적된 이해도를 소유해서는 안 되기 때문입니다.

왜 단순히 Git을 사용하지 않을까요?

Git은 이미 히스토리 (history)를 포함하고 있습니다.

하지만 Git은 다음과 같은 질문에 답합니다:

무엇이 변경되었는가?

프로젝트 인텔리전스 (Project Intelligence)는 다음과 같은 질문에 답하려고 시도합니다:

왜 변경되었는가?

그다음에는:

그 이후에 어떤 일이 일어났는가?

그리고 궁극적으로는:

원래의 추론 (reasoning)이 여전히 유효한가?

Git은 프로젝트 히스토리의 필수적인 소스입니다.

하지만 그것이 프로젝트 진화의 전체 시맨틱 모델 (semantic model)인 것은 아닙니다.

왜 단순히 RAG를 사용하지 않을까요?

RAG는 검색 (retrieval)에 매우 뛰어납니다.

만약 질문이 다음과 같다면:

인증 (authentication)에 관한 문서를 찾아줘.

검색은 정확히 우리에게 필요한 것입니다.

하지만 프로젝트 인텔리전스 시스템은 다음과 같은 요소들을 연결해야 할 수도 있습니다:

인증 (Authentication)
│
├── 결정 (Decision)
│ └── 왜 JWT가 거부되었는가
│
├── 제약 사항 (Constraint)
│ └── 기존 모바일 클라이언트
│
├── 모듈 (Module)
│ └── auth-service
│
└── 결과 (Outcome)
└── 마이그레이션 완료

흥미로운 부분은 단순히 관련 문서를 검색하는 것이 아닙니다.

그 문서들 사이의 관계를 이해하는 것입니다.

AI 에이전트에게 이것이 중요한 이유

하나의 AI 코딩 도구에서 다른 도구로 전환한다고 가정해 봅시다.

새로운 에이전트는 저장소 (repository)를 읽을 수 있습니다.

현재 코드를 검사할 수도 있습니다.

하지만 프로젝트 인텔리전스가 없다면, 에이전트는 여전히 프로젝트의 히스토리와 추론을 재구성해야 할 수도 있습니다.

지속적인 프로젝트 레이어 (persistent project layer)가 있다면, 워크플로 (workflow)는 다음과 같이 변합니다:

새로운 에이전트
↓
프로젝트 인텔리전스 읽기
↓
결정 사항 이해
↓
제약 사항 이해
↓
현재 상태 이해
↓
개발 계속

모델이 바뀌어도,

도구가 바뀌어도,

프로젝트 인텔리전스는 남아 있습니다.

현재의 Contorium

Contorium은 현재 다음과 같은 여러 요소들을 중심으로 구축되고 있습니다:

• 프로젝트 히스토리 (project history)
• 구조화된 프로젝트 상태 (structured project state)
• 결정 및 추론 추적 (decision and reasoning tracking)
• 프로젝트 그래프 (project graph)
• AI 준비 완료 핸드오프 (AI-ready handoff)
• MCP 통합 (MCP integration)
• IDE 통합 (IDE integration)
• 로컬 .contora/ 저장소 (local .contora/ storage)

이 프로젝트는 오픈 소스이며, 저는 의도적으로 이를 공개적으로 구축 (building in public)하고 있습니다.

제가 Project Intelligence (프로젝트 인텔리전스)가 해결된 문제라고 주장하는 것은 아닙니다.

저는 그것을 위한 적절한 추상화 (abstraction)를 찾으려고 노력하고 있습니다.

더 큰 질문은 이것입니다.

AI 코딩은 다음과 같이 변화하고 있습니다:

인간 (Human) → 프롬프트 (Prompt) → 코드 (Code)

다음 방향으로:

인간 (Human)
↓
프로젝트 (Project)
↓
다중 AI 에이전트 (Multiple AI Agents)
↓
지속적인 진화 (Continuous Evolution)

여러 에이전트가 장기간에 걸쳐 동일한 프로젝트에서 작업하게 되면, 프로젝트에 축적된 이해도를 보존할 무언가가 필요합니다.

그것이 바로 제가 관심을 두고 있는 문제입니다.

단순히 AI 메모리 (AI memory)만은 아닙니다.

단순히 더 많은 컨텍스트 (context)를 제공하는 것도 아닙니다.

바로 Project Intelligence (프로젝트 인텔리전스)입니다.

그것이 Contorium (컨토륨)이 지향하는 방향입니다.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium