Command Center
TL;DR
눈 뜨고 일어나니 또 뭐가 생겼다...
Alen님이 공유해주신 Command Center 개념을 직접 커머스 프로젝트에 적용해봤다. 도메인 지식,비즈니스 정책,코드 위치를 한 곳에 모아두고 Claude Code가 그걸 읽어 작업하도록 구성하는 방식인데 Claude Code가 좋은 코드를 짜려면 프로젝트의 맥락을 알아야 한다는 전제에서 출발한다.
| BE, FE, 디자이너, PO 등 직무에 구애받지 않고 원활한 협업이 가능하게 하며 프로젝트를 고도화 시킨다.
Command Center가 뭔데
프로젝트의 도메인 지식, 비즈니스 정책, 코드 위치를 한 곳에서 관리하는 AI 기반 팀 공용 작업 공간이다. PO, 디자이너, FE, BE 누구든 Claude Code를 통해 같은 방식으로 작업할 수 있게 설계됐다.
핵심은 Claude Code가 작업을 시작하기 전에 프로젝트의 구조와 맥락을 먼저 읽는다는 점이다. 단순히 CLAUDE.md에 설명을 쌓는 방식이 아니라, 도메인 간 관계와 의사결정 배경까지 온톨로지,위키,위키 세 계층으로 구조화해둔다.
언제 왜 필요할까
Claude Code를 쓰다 보면 답답한 순간이 온다.
기능 하나 만들어달라고 했는데 기존 정책을 모르고 멋대로 짜거나, 관련 도메인을 빠뜨리거나, 같은 패턴을 프로젝트 스타일과 다르게 구현한다. 틀린 게 아니라 맥락을 몰라서 생기는 문제다.
CLAUDE.md에 넣어봤다. 한계가 금방 왔다. 프로젝트가 크면 파일 하나에 다 넣을 수 없고 파일이 길어지면 Claude가 전부 참고하지도 않는다.
결국 문제는 두 가지다.
첫째, 도메인 구조가 어디에도 명시돼 있지 않다. 코드를 전부 읽지 않으면 어떤 모듈이 어디에 있는지, 어떤 서비스가 어떤 서비스를 호출하는지 파악이 안 된다.
둘째, 의사결정 맥락이 코드에 없다. 왜 이 방식으로 구현했는지, 어떤 트레이드오프를 고려했는지는 코드에 남지 않는다. 새 팀원이 오거나 6개월 뒤 내가 다시 봐도 알 수 없다.
Command Center는 이 두 가지를 구조적으로 해결하려는 시도다.
구성 방식
세 계층으로 나뉜다.
ontology ← 도메인 지도 (어디에 뭐가 있나)
wiki ← 정책 문서 (왜 이렇게 됐나)
skills ← Claude Code 커스텀 커맨드
온톨로지는 YAML로 도메인 개념, 관계, 코드 패키지 위치를 명시한다. Claude가 작업 전에 이 파일을 읽으면 전체 구조를 코드를 뒤지지 않고도 파악한다.
위키는 코드에 드러나지 않는 정책과 의사결정 배경을 Markdown으로 기록한다. Redisson을 왜 썼는지, 재시도를 3번으로 정한 이유가 뭔지 같은 것들.
스킬은 이 두 계층을 Claude Code가 자동으로 탐색하도록 연결하는 커스텀 커맨드다. /dev, /domain-audit 같은 명령으로 작업 흐름을 제어한다.
셋 중 하나라도 빠지면 절반짜리다. 온톨로지만 있으면 지도는 있는데 맥락이 없다. 위키만 있으면 맥락은 있는데 Claude가 어디서 읽어야 할지 모른다. 스킬 없이는 수동으로 파일을 열어서 프롬프트에 붙여 넣는 작업을 반복해야 한다.
타이밍
새 기능 개발 전
영향 범위를 먼저 파악해야 할 때 온다. 온톨로지에 도메인 간 관계가 정리돼 있으면 주문 도메인을 건드릴 때 재고, 쿠폰, 결제 중 어디까지 연쇄 영향이 가는지 Claude가 바로 짚어준다.
코드 리뷰
구현 방식이 기존 정책과 맞는지 확인할 때 쓴다. 리뷰어가 맥락을 모르면 코드만 보고 판단하게 된다. 위키에 정책 배경이 있으면 Claude가 리뷰할 때 그 기준으로 체크해준다.
새 팀원 온보딩
지금 당장은 팀이 없어도, Command Center가 있으면 새 팀원이 왔을 때 온톨로지 하나로 전체 구조를 빠르게 잡을 수 있다. 구두로 설명하는 시간이 줄고, 설명이 흐릿하게 전달되는 문제도 줄어든다.
리팩토링
어디까지 바꿔도 되는지 범위를 잡을 때 유용하다. 의존 관계가 정리돼 있으면 특정 모듈을 건드릴 때 사이드이펙트가 어디까지 퍼지는지 파악하고 시작할 수 있다.
고도화
처음부터 완벽하게 만들려 하면 안 된다. 온톨로지를 잘 쓰려면 도메인을 잘 알아야 하고, 위키를 잘 쓰려면 정책을 잘 정리해야 한다. 프로젝트 초반에 그게 다 갖춰져 있는 경우는 없다.
1단계 — 뼈대만 만들기
주요 도메인 2-3개만 골라서 온톨로지를 초안 수준으로 잡는다. 완벽하지 않아도 된다. 관계 엣지 몇 개, 코드 패키지 위치 정도면 충분하다. 위키도 마찬가지 — README 수준으로 시작해서 결정이 생길 때마다 추가한다.
2단계 — 스킬로 진입점 만들기
온톨로지와 위키가 있어도 Claude가 알아서 읽지 않으면 의미가 없다. /dev 스킬에 작업 전 온톨로지를 읽는 단계를 박아두면, 기능 개발 요청이 들어올 때마다 Claude가 먼저 구조를 파악하고 시작한다.
3단계 — /domain-audit 주기적으로 돌리기
코드는 바뀌는데 온톨로지는 그대로인 상황이 가장 위험하다. 오래된 지도를 믿고 이동하는 것과 같다. /domain-audit으로 주기적으로 온톨로지·위키·코드 세 곳의 정합성을 점검하면 그 괴리를 잡을 수 있다.
4단계 — 스킬 커스터마이즈
프로젝트마다 반복되는 작업이 다르다. 처음엔 기본 스킬 세트로 시작해도 되지만, 쓰다 보면 이 프로젝트에만 있는 패턴이 보인다. 그걸 스킬로 만들면 Claude Code가 그 맥락까지 알고 작업한다.
직접 써보니...
온톨로지 설계가 제일 어렵다. 개념 간 관계를 어느 수준까지 명시할지, 정책을 어디에 쓸지 등등 처음엔 기준이 없어서 계속 고쳤다. 그런데 고치는 과정이 프로젝트 구조를 다시 생각하게 만들어서, 온톨로지 자체가 설계 도구처럼 됐다.
맥락을 구조화해두는 것 자체가 Claude Code 품질에 영향을 준다는 걸 체감했다. 매번 배경을 설명하는 대신 Claude가 알아서 읽고 시작하니 작업 시작 전 마찰이 줄었다.
마치며
프롬프트를 잘 쓰는 것보다 Claude가 작업 전에 읽을 수 있는 구조화된 지식을 미리 만들어두는 게 효과가 컸다.
완성된 구조가 아니어도 된다. 온톨로지 파일 하나, 위키 파일 하나, 간단한 스킬 하나만 있어도 아무것도 없는 것과 다르다.