클로드 하나에게 다 시키지 말고, 일의 종류에 맞는 역할을 부른다.

앞 글에서 클로드 코드 위에 OMC라는 조율 층을 얹어 쓴다고 했습니다. 이 글은 그 OMC가 실제로 무엇을 제공하는지, 그중 무엇을 어떻게 썼는지 정리한 것입니다. 설치된 OMC 5.0에는 스킬(작업 흐름) 30여 개와 역할(에이전트) 19개가 들어 있지만, 2주 동안 실제로 쓴 건 흐름 4개와 역할 9개입니다. 안 쓴 건 적지 않았습니다.

먼저 용어 두 개

• 스킬: 정해진 순서로 일을 처리하는 작업 흐름입니다. 채팅에 /plan, /verify 처럼 슬래시 이름을 치거나, 특정 단어를 쓰면 저절로 켜집니다.
• 역할(에이전트): 스킬 안에서 실제로 일하는 클로드입니다. 설계만 하는 클로드, 구현만 하는 클로드, 검토만 하는 클로드처럼 하는 일이 정해져 있고, 서로의 대화를 공유하지 않습니다. 그래서 검토 담당은 구현 담당의 변명을 모릅니다.

기본 흐름 4단계

OMC의 핵심 흐름은 계획 → 실행 → 검토 → 검증 순서입니다. 각 단계가 스킬 하나이고, 큰 일은 이 순서를 그대로 밟습니다. 작은 수정은 실행 하나만 씁니다.

• /plan — 계획: 무엇을 어떻게 만들지 문서로 씁니다. 테니스 일반 대회 양식 때 planner 역할이 저장 공간 제약, 재사용할 코드, 대진 생성 규칙의 의사코드까지 686줄짜리 계획을 먼저 썼고, 구현은 그 문서를 그대로 따랐습니다.
• /execute — 실행: 승인된 계획을 코드로 만듭니다. executor 역할이 맡고, 이번 2주에 16번 불렀습니다. 화면 디자인이 중심인 일은 executor 대신 designer 역할(10번)을 썼습니다.
• /review — 검토: 만든 결과를 다른 클로드가 읽고 결함·위험·단순화 여지를 찾습니다. code-reviewer 역할이 일반 대회 코드에서 문제 7건을 찾았고, 그중 하나는 결선 점수가 엉뚱한 팀에 붙는 실제 결함이었습니다.
• /verify — 검증: 완료라고 말하기 전에 실제로 되는지 확인합니다. verifier 역할이 화면 26개를 세 가지 폭과 다크 모드로 열어 108장을 찍고 어긋남 13건을 보고한 게 이 단계였습니다.

실제로 쓴 역할 9개

괄호 안은 2주 동안 부른 횟수입니다. 역할은 슬래시 명령이 아니라 문장으로 부릅니다. "○○ 에이전트한테 맡겨줘"처럼 말하면 클로드가 그 역할을 띄웁니다. 카드 아래 문장을 누르면 복사되니 그대로 붙여 쓰면 됩니다. 설계·검토처럼 판단이 필요한 일은 큰 모델(opus)에, 단순 조사는 작은 모델에 맡길 수도 있습니다.

쓰지 않은 역할도 열 개쯤 있습니다. 테스트 전문(test-engineer), 디버거(debugger), 데이터 분석(scientist), 깃 정리(git-master) 등인데, 이 사이트에는 자동 테스트가 없고 깃도 단순해서 필요하지 않았습니다. 필요한 것만 부르는 게 맞습니다.

한마디로 끝까지 — 자동 실행 스킬

스킬은 슬래시 명령입니다. 채팅 맨 앞에 /oh-my-claudecode:이름 을 치고 뒤에 할 일을 적으면 됩니다. autopilot·ultrathink 같은 단어는 명령 없이 문장에 넣어도 켜집니다. 카드 아래 문장을 누르면 복사돼요.

이번에 쓰지 않은 흐름도 있습니다. 끝날 때까지 스스로 반복하는 ralph, 여러 클로드가 한 목록을 나눠 드는 team, 애매한 요청을 문답으로 좁히는 deep-interview 같은 것들입니다. 요청이 대부분 스크린샷 한 장과 한 줄이라 그 정도까지 필요하지 않았습니다.

규칙 파일이 하는 일

OMC는 설정 파일(CLAUDE.md)에 적어 둔 규칙을 어떤 역할이 일하든 똑같이 지키게 합니다. 이 사이트에 적어 둔 규칙은 이런 것들입니다.

• 설명은 개발을 모르는 사람 기준으로, 용어에는 한 줄 풀이를 붙인다.
• 커밋 메시지는 바뀐 것·이유·영향 범위·확인 방법을 적는다. 나중에 사람이 읽고 검토하는 유일한 단서다.
• 한 작업에서 300줄 넘게 바뀌면 멈추고 알린다.
• 새 컴포넌트를 만들기 전에 이미 있는 걸 먼저 찾는다.
• 저장 공간 구조 변경·배포·비밀번호·라이브러리 추가는 사람에게 넘긴다.
• 같은 줄에 놓인 카드는 아래선을 맞춘다. (이 규칙은 2주 중에 새로 생겼습니다.)

규칙이 파일에 있으면 대화가 길어져 앞 내용을 잊어도, 새 역할이 투입돼도 같은 선을 지킵니다. 이번에 헤더가 쪼그라든 사고 뒤에 검사 폭에 945px를 추가한 것도 규칙 파일이 아니라 기억 파일에 적어 두었고, 그 뒤 검사에서는 그 폭이 포함됐습니다.

비용과 한계

• 토큰을 더 씁니다. 역할을 나누면 같은 코드를 여러 클로드가 읽습니다. 한두 줄 수정에는 쓰지 않는 게 맞습니다.
• 역할끼리 같은 파일을 동시에 고치면 충돌합니다. 이번에도 한 번 있었고, 그 뒤로는 같은 파일을 건드리는 일은 순서대로 줄 세웠습니다.
• 통신이 끊기면 역할이 중간에 멈춥니다. 끊긴 자리에서 이어 가게 할 수 있지만, 어디까지 됐는지는 사람이 확인해야 합니다.

정리

OMC를 잘 쓰는 법은 많이 쓰는 게 아니라 필요한 것만 부르는 것이었습니다. 큰 일은 계획 → 실행 → 검토 → 검증을 밟고, 작은 일은 바로 고치고, 되돌릴 수 없는 일은 사람이 합니다. 스킬 30여 개 중 4개, 역할 19개 중 9개로 2주가 충분했습니다.