오 마이 클로드 코드(OMC) 설치 및 사용법: 실전 가이드

오 마이 클로드 코드(OMC)란?

오 마이 클로드 코드(OMC)는 Claude Code에 여러 역할의 AI 에이전트와 작업 모드를 추가하는 오픈소스 플러그인이에요. 요구사항 정리부터 구현, 검증, 수정까지 작업을 단계별로 나누어 진행하도록 도와줍니다.

클로드 코드로 간단한 코드를 수정할 때는 AI 에이전트 하나만으로도 충분한 경우가 많아요. 하지만 여러 파일을 수정하는 기능을 개발하거나, 구현이 끝난 뒤 테스트와 검증까지 이어가야 하는 작업은 이야기가 달라집니다. 작업이 어디까지 진행됐는지 확인하기 어렵고, 처음 요청에서 놓친 조건 때문에 같은 내용을 여러 번 수정하게 되기도 해요.

오 마이 클로드 코드(Oh My Claude Code, OMC)는 이런 작업을 더 체계적으로 진행할 수 있도록 클로드 코드에 여러 역할의 AI 에이전트를 연결해주는 플러그인이에요. 하나의 요청을 계획, 요구사항 정리, 구현, 검증, 수정 등의 단계로 나누고, 작업에 맞는 에이전트가 각 단계를 맡도록 도와줍니다.

쉽게 말하면 클로드 코드에 각자 맡은 역할이 있는 AI 작업팀을 붙이는 것과 비슷해요.

이 글에서는 OMC를 처음 접하는 분을 위해 설치 방법부터 설치 직후 실행할 첫 프롬프트, 자주 사용하는 모드와 실전 예시까지 차례대로 살펴볼게요.

1. 설치 전 준비하기

OMC를 사용하려면 먼저 Claude Code CLI가 설치되어 있어야 해요. Claude Code를 이용할 수 있는 Pro·Max·Team·Enterprise 요금제 또는 결제가 활성화된 Anthropic Console 계정 등이 필요합니다. 무료 Claude.ai 요금제에는 Claude Code 이용 권한이 포함되지 않아요. 이미 터미널에서 Claude Code를 사용하고 있다면 설치 단계는 건너뛰어도 됩니다.

macOS

터미널을 열고 아래 명령어를 실행해 주세요.

curl -fsSL https://claude.ai/install.sh | bash

Windows CMD

명령 프롬프트에서 아래 명령어를 실행해 주세요.

curl -fsSL https://claude.ai/install.cmd -o install.cmd&& install.cmd&& del install.cmd

Windows PowerShell

PowerShell에서 아래 명령어를 실행해 주세요.

irm https://claude.ai/install.ps1 | iex

설치가 끝나면 아래 명령어로 설치 상태를 확인해 주세요.

claude --version
claude doctor

이후 프로젝트 폴더에서 claude를 실행하고 안내에 따라 로그인하면 됩니다. 위 명령어들은 OMC가 아니라 Claude Code CLI 자체를 설치하는 명령어예요.

2. 오 마이 클로드 코드 설치하기

이제 Claude Code를 실행한 상태에서 아래 명령어를 한 줄씩 차례대로 입력합니다. 두 명령어를 한 번에 붙여넣으면 실패할 수 있으니, 첫 번째 명령어의 실행이 끝난 뒤 두 번째 명령어를 입력해 주세요.

2-1. 플러그인 마켓플레이스 추가하기

/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode

이 명령어는 OMC를 내려받을 플러그인 마켓플레이스를 Claude Code에 등록해요.

2-2. OMC 플러그인 설치하기

/plugin install oh-my-claudecode

설치 후 Claude Code를 다시 시작하라는 안내가 표시되면 안내에 따라 진행해 주세요.

2-3. 처음 한 번만 기본 설정하기

플러그인 설치가 끝나면 아래 명령어 중 하나를 실행해 최초 설정을 진행합니다.

/setup

또는 기존 진입점인 다음 명령어를 사용할 수도 있어요.

/omc-setup

화면 안내에 따라 설정을 마치면 이후부터는 평소처럼 Claude Code에 자연어로 작업을 요청하거나, 목적에 맞는 OMC 명령어를 사용할 수 있습니다.

2-4. 최신 버전으로 업데이트하기

2026년 8월 3일 확인 기준 최신 릴리스는 v4.15.7이에요. Claude Code 플러그인과 npm CLI는 별도의 설치 경로이므로, 자신이 설치한 방식에 맞춰 업데이트해야 합니다.

마켓플레이스에서 플러그인을 설치했다면 아래 명령어를 Claude Code 세션 안에서 차례대로 실행해 주세요.

/plugin marketplace update omc
/setup

npm으로 CLI를 함께 설치했다면 터미널에서 다음 명령어를 실행합니다.

npm i -g oh-my-claude-sisyphus@latest

ask, ccg, 터미널 기반 omc team처럼 CLI에 의존하는 기능을 사용한다면 npm CLI도 최신 상태인지 확인해 주세요.

3. 설치 직후 바로 실행해 보기

설치가 끝났는데 무엇부터 입력해야 할지 모르겠다면 autopilot:으로 작은 기능 하나를 맡겨보세요. Autopilot은 요구사항이 어느 정도 정리된 기능을 구현부터 테스트까지 이어서 처리하고 싶을 때 사용하는 모드예요.

아래 프롬프트를 복사해 첫 작업을 실행해 볼 수 있습니다.

autopilot: 할 일을 생성, 조회, 수정, 삭제할 수 있는 REST API를 구현해줘.
요청 데이터 검증과 존재하지 않는 항목에 대한 오류 처리를 추가하고,
각 엔드포인트의 주요 성공 및 실패 사례를 테스트해줘.
모든 테스트와 타입 검사가 통과하면 변경 내용을 정리해줘.

슬래시 명령어 형태로 실행하고 싶다면 다음처럼 입력해도 돼요.

/autopilot "할 일을 생성, 조회, 수정, 삭제할 수 있는 REST API를 구현해줘. 요청 데이터 검증과 오류 처리를 추가하고 관련 테스트도 작성해줘."

autopilot:은 자연어로 모드를 활성화하는 방식이고, /autopilot은 Claude Code 세션 안에서 사용하는 슬래시 명령어예요.

짧은 요청보다 완료 기준까지 적어주세요

다음과 같은 요청도 실행할 수 있지만, AI가 판단해야 하는 부분이 너무 많아요.

autopilot: 로그인 기능을 만들어줘.

무엇을 만들지, 어떤 상황을 처리할지, 언제 완료로 볼지를 함께 적으면 결과를 확인하기 쉬워집니다.

autopilot: 이메일과 비밀번호를 사용하는 로그인 기능을 구현해줘.
로그인 실패 시 사용자가 이해할 수 있는 오류 메시지를 표시하고,
현재 프로젝트의 인증 구조와 코딩 스타일을 유지해줘.
관련 테스트를 작성하고 모든 테스트와 타입 검사가 통과하면 완료로 처리해줘.

좋은 요청에는 보통 다음 네 가지가 들어가요.

1. 무엇을 만들거나 수정할지
2. 반드시 포함할 동작과 예외 상황
3. 기존 구조처럼 지켜야 할 조건
4. 테스트나 빌드처럼 확인 가능한 완료 기준

4. 상황별 OMC 명령어와 프롬프트 예시

OMC의 모든 명령어를 처음부터 외울 필요는 없어요. 지금 하려는 작업의 상태에 따라 적합한 모드를 하나씩 사용해 보면 됩니다.

4-1. /deep-interview: 요구사항이 아직 모호할 때

아이디어는 있지만 사용자, 화면, 데이터, 예외 상황이 아직 정리되지 않았다면 바로 구현부터 시작하지 않는 편이 좋아요. /deep-interview는 코드를 작성하기 전에 질문을 통해 숨은 요구사항과 애매한 조건을 확인하는 기능입니다.

기본 문법은 다음과 같아요.

/deep-interview "만들고 싶은 내용을 입력하세요."

새로운 앱의 요구사항을 정리하고 싶을 때:

/deep-interview "운동 기록을 저장하고 지난 기록과 비교할 수 있는 앱을 만들고 싶어. 주요 사용자와 핵심 화면, 저장할 데이터, 예외 상황을 먼저 질문해줘."

기존 서비스에 회원 전용 기능을 추가할 때:

/deep-interview "현재 블로그에 회원 전용 콘텐츠 기능을 추가하고 싶어. 구현 전에 사용자 흐름과 권한별 접근 범위, 로그인하지 않은 사용자의 동작을 먼저 정리해줘."

조건이 많은 결제 기능을 준비할 때:

/deep-interview "월간 구독 결제 기능을 만들고 싶어. 결제 성공과 실패, 구독 취소, 재결제, 환불 상황까지 빠짐없이 질문해줘."

인터뷰 중 답을 정하기 어려운 질문이 나오면 억지로 결정하기보다 가능한 선택지와 장단점을 요청해 보세요. 인터뷰 결과를 검토한 다음 Autopilot이나 Team으로 구현을 이어가면 됩니다.

4-2. autopilot:: 기능 하나를 처음부터 끝까지 맡길 때

Autopilot은 요구사항이 어느 정도 정리된 기능을 구현하고 테스트하는 데 잘 맞아요. 범위가 너무 큰 프로젝트 전체보다 확인 가능한 기능 하나를 맡기는 편이 좋습니다.

로그인 기능을 만들 때:

autopilot: 이메일과 비밀번호로 로그인하는 기능을 구현해줘.
잘못된 로그인 정보에는 구체적인 오류 메시지를 표시하고,
현재 프로젝트의 인증 구조와 코딩 방식에 맞춰 관련 테스트도 작성해줘.

게시글 검색 기능을 추가할 때:

autopilot: 게시글 제목과 내용으로 검색할 수 있는 기능을 추가해줘.
검색어가 비어 있을 때와 결과가 없을 때의 화면도 처리하고,
기존 게시글 목록 기능이 깨지지 않는지 테스트해줘.

파일 업로드 기능을 만들 때:

autopilot: 프로필 이미지를 업로드하고 변경할 수 있는 기능을 구현해줘.
허용할 파일 형식과 최대 용량을 검증하고 잘못된 파일에는 오류를 표시해줘.
기존 이미지 교체와 업로드 실패 상황을 포함한 테스트도 작성해줘.

Autopilot에 작업을 요청할 때는 기존 구조를 유지해야 하는지, 수정하면 안 되는 범위가 있는지, 테스트나 타입 검사 중 무엇을 통과해야 하는지 함께 알려주세요.

4-3. /team: 여러 작업을 역할별로 나눌 때

여러 파일과 영역을 다루는 큰 작업을 역할별 에이전트에게 나누고 싶다면 Team을 사용할 수 있어요. 현재 OMC에서 권장하는 표준 멀티 에이전트 방식이며, 대략 계획 → 요구사항 정리 → 실행 → 검증 → 수정 흐름으로 작업합니다.

기본 문법은 다음과 같아요.

/team 3:executor "작업 내용"

Team 기능을 사용하려면 ~/.claude/settings.json에 다음 환경 변수를 추가해 주세요.

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Team이 비활성화되어 있으면 OMC가 경고를 표시하고, 가능한 경우 팀을 사용하지 않는 실행 방식으로 전환합니다.

TypeScript 오류를 여러 에이전트에게 나눠 수정할 때:

/team 3:executor "현재 프로젝트의 TypeScript 오류를 모두 확인하고 수정해줘.
각 에이전트가 겹치지 않는 파일이나 영역을 맡도록 작업을 나누고,
마지막에 전체 타입 검사와 테스트를 실행해줘."

회원가입 기능을 영역별로 나눠 구현할 때:

/team 3:executor "회원가입 기능을 구현해줘.
API와 데이터 검증, 사용자 화면, 테스트 작업을 서로 겹치지 않게 나누고,
기존 로그인 기능이 깨지지 않았는지도 함께 검증해줘."

프로젝트를 여러 관점에서 점검할 때:

/team 3:executor "현재 프로젝트를 성능, 접근성, 코드 품질 관점에서 점검해줘.
각 영역을 별도로 조사한 뒤 우선순위가 높은 문제부터 수정하고,
변경한 내용과 아직 남아 있는 문제를 마지막에 정리해줘."

에이전트 수를 늘린다고 항상 더 빨라지는 것은 아니에요. 같은 파일을 여러 에이전트가 동시에 크게 수정하면 충돌과 검토 부담이 커질 수 있으므로, 담당 영역이 겹치지 않도록 작업 경계를 명확하게 적어주는 것이 중요합니다.

4-4. ralph:: 완료될 때까지 검증과 수정을 반복할 때

Ralph는 한 번의 수정으로 끝나기 어려운 작업을 완료 기준에 도달할 때까지 반복해서 검증하고 수정하는 모드예요. 리팩터링, 반복되는 테스트 오류, 반드시 끝까지 해결해야 하는 작업에 잘 맞습니다.

인증 모듈을 리팩터링할 때:

ralph: 인증 모듈을 역할별로 분리해 리팩터링해줘.
외부에서 사용하는 기존 인터페이스는 유지하고,
관련 테스트와 전체 타입 검사가 통과할 때까지 검증과 수정을 반복해줘.

실패하는 테스트의 근본 원인을 수정할 때:

ralph: 현재 실패하는 테스트의 원인을 찾아 수정해줘.
테스트를 삭제하거나 검증 조건을 약화하지 말고 회귀 테스트를 추가해줘.
전체 테스트가 통과할 때까지 원인 분석과 수정을 반복해줘.

느린 API를 개선할 때:

ralph: 게시글 목록 API의 응답 속도가 느린 원인을 찾아 개선해줘.
기존 응답 형식은 유지하고 성능 개선 전후를 비교해줘.
모든 관련 테스트가 통과하고 확인된 병목이 해결될 때까지 반복해줘.

Ralph를 사용할 때는 “깔끔하게 만들어줘” 같은 추상적인 표현보다 “전체 테스트와 타입 검사가 통과할 때까지 수정해줘”처럼 확인 가능한 완료 조건을 넣는 것이 좋아요.

4-5. ulw: 독립적인 수정 작업을 빠르게 병렬 처리할 때

Team의 단계별 협업 과정까지는 필요하지 않지만, 서로 독립적인 여러 오류나 수정 작업을 빠르게 처리하고 싶다면 Ultrawork를 사용할 수 있어요. 자연어 트리거인 ulw 또는 /ultrawork로 실행합니다.

ulw: 린트 오류와 사용하지 않는 import를 정리하고,
서로 독립적인 작업은 병렬로 처리해줘.
기능 동작은 변경하지 말고 마지막에 전체 테스트를 실행해줘.

Team은 큰 작업을 역할별로 나누어 단계적으로 협업해야 할 때, Ultrawork는 서로 독립적인 오류나 수정 사항을 빠르게 병렬 처리할 때 선택하면 됩니다.

4-6. /skillify: 해결 방법을 다음에도 재사용할 때

이번 작업에서 발견한 프로젝트 규칙이나 반복 가능한 해결 방법을 다음 작업에도 사용하고 싶다면 /skillify로 스킬을 만들 수 있어요.

/skillify "이번에 적용한 API 오류 응답 작성 규칙과 테스트 패턴을
이 프로젝트에서 재사용할 수 있는 스킬로 정리해줘."

프로젝트에서 함께 사용할 스킬은 .omc/skills/, 개인적으로 여러 프로젝트에서 사용할 스킬은 ~/.omc/skills/에 저장할 수 있어요. 팀 프로젝트에서는 프로젝트 범위 스킬을 버전 관리하고, API 키나 토큰, 개인정보, 내부 주소 같은 민감한 정보가 포함되지 않았는지 반드시 확인해 주세요.

5. 어떤 모드를 선택해야 할까요?

선택 기준을 한 문장으로 정리하면 다음과 같아요.

6. 바로 복사해서 쓰는 OMC 프롬프트 템플릿

프로젝트와 기능 이름만 바꿔서 사용할 수 있는 범용 템플릿도 준비했어요.

기능 개발용

autopilot: [기능 이름]을 구현해줘.
사용자는 [핵심 행동]을 할 수 있어야 하고,
[실패 상황]에서는 [오류 처리 방식]을 제공해줘.
현재 프로젝트의 구조와 코딩 스타일을 유지하고 관련 테스트를 작성해줘.
모든 테스트와 타입 검사가 통과하면 변경 내용을 요약해줘.

오류 수정용

ralph: [오류 현상]의 원인을 찾아 수정해줘.
증상만 임시로 막지 말고 재현 조건과 근본 원인을 먼저 확인해줘.
기존 테스트를 삭제하거나 검증 기준을 낮추지 말고 회귀 테스트를 추가해줘.
전체 테스트가 통과할 때까지 검증과 수정을 반복해줘.

리팩터링용

ralph: [대상 모듈]을 리팩터링해줘.
외부에서 사용하는 인터페이스와 현재 동작은 유지하고,
중복된 책임을 분리하되 관련 없는 코드는 수정하지 마.
기존 테스트와 타입 검사, 빌드가 모두 통과할 때까지 검증해줘.

팀 작업용

/team 3:executor "[전체 작업]을 진행해줘.
작업을 [영역 1], [영역 2], [영역 3]으로 나누고,
각 에이전트가 겹치지 않는 파일과 책임을 맡게 해줘.
마지막에는 변경 내용을 통합해 전체 테스트와 타입 검사를 실행해줘."

코드 리뷰용

/team 3:executor "[검토 대상]을 보안, 성능, 유지보수성 관점에서 검토해줘.
각 관점을 별도로 조사하고 문제의 근거와 영향을 설명해줘.
수정이 필요한 항목은 위험도가 높은 순서로 정리하고,
안전하게 수정할 수 있는 항목은 테스트와 함께 반영해줘."

7. Codex·Gemini 등 외부 CLI도 함께 사용하고 싶다면

OMC는 선택적으로 Codex, Gemini, Antigravity 같은 외부 CLI를 별도의 워커로 실행할 수 있어요. 다만 여기서 사용하는 omc team과 앞에서 살펴본 /team은 이름은 비슷하지만 서로 다른 실행 방식입니다.

• /team은 Claude Code 세션 안에서 Claude 에이전트가 협업하는 네이티브 팀이에요.
• omc team은 터미널에서 tmux를 이용해 선택한 CLI 프로세스를 별도 워커로 실행해요.

이 기능을 사용하려면 npm 패키지인 oh-my-claude-sisyphus, 사용할 외부 CLI, 해당 CLI의 인증, 활성화된 tmux 세션이 필요합니다.

Codex에 보안과 아키텍처 리뷰를 맡길 때:

omc team 2:codex "review the authentication module for security and architecture risks"

Gemini에 UI와 접근성 검토를 맡길 때:

omc team 2:gemini "review the UI components for usability and accessibility"

Gemini 워커는 최신 공식 문서에서 기업 또는 API 키 환경의 대안으로 안내됩니다. 일반적인 UI·문서 작업에는 Antigravity 워커도 사용할 수 있어요.

omc team 2:antigravity "review the UI components for usability and accessibility"

Claude에 일반적인 구현 작업을 맡길 때:

omc team 1:claude "implement the payment flow and add tests"

/ccg는 최신 버전에서 Codex와 Antigravity의 의견을 받은 뒤 Claude가 종합하는 기능이에요. 이전 가이드에서 Gemini 조합으로 소개된 내용과 다를 수 있습니다.

/ccg 이 PR을 검토해줘.
Codex는 아키텍처와 보안을, Antigravity는 UI와 접근성을 검토하고,
Claude가 두 결과를 종합해 수정 우선순위를 정리해줘.

작업에 참여하는 CLI가 많아질수록 설정과 결과를 검토할 비용도 늘어나요. 작은 작업에서는 여러 도구를 동시에 실행하기보다 가장 적합한 에이전트 하나에게 명확하게 요청하는 편이 효율적일 수 있습니다.

8. OMC를 사용할 때 기억할 점

신뢰할 수 있는 프로젝트에서 실행하세요

OMC 에이전트는 파일과 도구를 사용해 실제 변경을 만들 수 있어요. 출처를 모르는 저장소의 설정이나 .mcp.json을 그대로 신뢰하지 말고, 회사 코드에서는 조직의 보안 정책과 허용된 외부 AI 서비스를 먼저 확인해 주세요.

작업 범위를 작고 분명하게 나눠주세요

“앱 전체를 개선해줘”보다 “로그인 실패 시 오류 메시지를 수정하고 관련 테스트를 추가해줘”처럼 대상과 완료 기준이 분명한 요청이 결과를 확인하기 쉬워요.

에이전트의 담당 영역이 겹치지 않게 해주세요

여러 에이전트가 같은 파일을 동시에 크게 수정하면 충돌이 발생하거나 마지막 검토가 어려워질 수 있어요. Team을 사용할 때는 파일, 기능 또는 검토 관점처럼 서로 분리할 수 있는 기준으로 역할을 나눠주세요.

작업 전후의 Git 변경 사항을 확인하세요

작업을 시작하기 전에 현재 변경 사항을 커밋하거나 별도로 보관하고, 작업이 끝난 후에는 수정된 파일과 diff를 확인하는 습관이 필요해요. 중요한 프로젝트에서는 별도 브랜치에서 실행하는 것이 안전합니다.

AI가 만든 코드는 반드시 사람이 검토하세요

테스트를 통과했다는 사실만으로 모든 코드가 안전하다고 볼 수는 없어요. 특히 로그인과 인증, 사용자 권한, 결제와 환불, 데이터 삭제, 개인정보 처리, API 키와 관련된 코드는 배포 전에 반드시 사람이 직접 검토해야 합니다.

9. 자주 묻는 질문

마무리

OMC의 핵심은 단순히 에이전트 수를 늘리는 것이 아니에요. 큰 작업을 이해하기 쉬운 단계와 역할로 나누고, 구현 후 검증과 수정까지 이어갈 수 있다는 점에 있습니다.

처음부터 모든 명령어를 외울 필요도 없어요. 설치 후에는 autopilot:으로 작은 기능 하나를 맡겨보고, 요구사항이 모호할 때는 /deep-interview, 여러 역할이 필요한 작업에는 /team, 완료될 때까지 반복해야 하는 작업에는 ralph:를 사용해 보세요.

어떤 모드를 선택하든 가장 중요한 것은 무엇을 원하는지, 지켜야 할 조건이 무엇인지, 언제 작업이 끝났다고 판단할지를 명확하게 전달하는 것입니다.