# AI 코딩 도구 선택을 개인 에이전트의 스킬로 저장했다
## 📝 한줄 요약
Claude Code와 Codex에 OMC·OMX를 설치하는 데서 끝내지 않고, **내 업무를 보고 어떤 도구와 워크플로우가 적합한지 AI가 먼저 판단해 선택지를 제안하는 스킬**을 만들었다.
**바쁘시면 이것만 읽어도 돼요:**
- OMC·OMX 설치 상태를 실제 진단으로 확인하고 충돌 가능성을 정리했다.
- 복잡한 업무에는 멀티에이전트를, 단순한 업무에는 단일 에이전트를 추천하도록 기준을 만들었다.
- AI가 자동 실행하지 않고 추천 이유·실행 방식·대안을 먼저 제시하게 했다.
- 대화를 삭제해도 남는 Hermes 스킬로 저장했다.
- 핵심은 도구를 많이 설치하는 것이 아니라 **도구를 선택하는 기준을 먼저 자산화하는 것**이었다.
## 🎯 이런 분들께 도움돼요
- Claude Code, Codex 등 여러 AI 코딩 도구를 설치했지만 언제 무엇을 써야 할지 어려운 실무자
- 멀티에이전트가 좋아 보여 모든 업무에 적용했다가 오히려 복잡해진 경험이 있는 사람
- 개인 AI 에이전트에 자신의 판단 기준과 승인 규칙을 남기고 싶은 사람
## 😫 문제 상황: 도구는 늘었는데 선택 기준은 없었다
Claude Code에는 OMC, Codex에는 OMX를 설치했다. 두 도구 모두 요구사항 인터뷰, 합의형 계획, 반복 실행, 병렬 팀 같은 강력한 기능을 제공한다.
문제는 설치 다음이었다.
- 요구사항이 모호할 때는 무엇을 써야 할까?
- 계획만 필요할 때도 멀티에이전트를 돌려야 할까?
- 병렬 작업과 반복 실행은 어떻게 구분할까?
- 단순한 질문에도 OMC나 OMX를 쓰는 것이 맞을까?
결국 매번 도구를 고르는 일이 새로운 업무가 됐다. 기능은 많아졌지만, **의사결정 기준은 여전히 내 머릿속에만 있었다.**
내가 원한 것은 도구 하나를 기본값으로 고정하는 것이 아니었다.
```
업무마다 OMC·OMX가 유리한지 먼저 판단하고, 이점이 있다면 실제 사용할 명령어와 대안을 제시해줘. 내가 선택하기 전에는 실행하지 마.
```
## 🛠️ 사용한 도구
- **Hermes Agent**: 설치 진단, 스킬 작성, 지속 메모리와 실행 규칙 관리
- **Claude Code + OMC**: 요구사항 인터뷰·합의형 계획·지속 실행·팀 워크플로우
- **Codex CLI + OMX**: Codex 기반 멀티에이전트 오케스트레이션
- **Hermes Skills**: 업무 판단 기준과 절차를 대화 밖에 영구 저장
---
## 🔧 작업 과정
### 1. 강의안과 실제 설치 상태를 대조했다
먼저 “설치했으니 되겠지”라는 가정부터 버렸다. 강의안에서 설명한 OMC·OMX의 역할과 현재 PC의 실제 상태를 비교했다.
Claude Code와 Codex의 실행 버전, OMC 플러그인 활성화 여부, OMX 설정과 Team 상태를 각각 진단했다. 이 과정에서 OMC·OMX 자체는 설치돼 있었지만 두 가지 운영 위험이 드러났다.
- Claude Code의 네이티브 버전과 오래된 npm 전역 버전이 동시에 존재했다.
- OMX가 두 스킬 저장소에서 이름이 같은 스킬 6개를 발견했고, 그중 3개는 내용도 달랐다.
설치 성공 메시지와 운영 가능한 상태는 다르다는 점이 첫 번째 교훈이었다.
### 2. 무조건 삭제하지 않고 충돌 가능성을 정리했다
오래된 Claude Code 전역 설치는 제거하고, 자동 업데이트가 적용되는 최신 네이티브 설치만 남겼다. 정리 후 진단에서는 설치 문제가 없다는 결과를 확인했다.
OMX의 중복 스킬은 더 조심스럽게 처리했다. 내용이 다른 파일을 비교해보니 한쪽은 Claude Code 표현을, 다른 쪽은 Codex 표현을 사용하고 있었다. Codex에 맞게 수정된 최근 내용을 표준 저장소에 반영하고, 중복 파일은 삭제 대신 별도 백업으로 이동했다.
정리 후 OMX 진단 결과는 다음과 같았다.
- 기본 진단 18개 항목 통과
- 경고 0개
- 실패 0개
- Team 진단 통과
- 설정 변경 필요 항목 없음
여기서 중요한 것은 단순히 경고를 없앤 것이 아니다. **차이가 있는 파일을 비교하고, 사용할 버전을 보존하고, 되돌릴 수 있게 백업한 뒤 다시 진단했다는 점**이다.
### 3. 가장 어려운 문제는 ‘언제 무엇을 쓸지’였다
설치 문제를 해결해도 핵심 고민은 남았다. OMC와 OMX에는 비슷한 이름의 강력한 기능이 많았다. 그래서 기능 목록이 아니라 업무 구조를 기준으로 라우팅 규칙을 만들었다.
| 업무 상황 | 추천 방식 |
|---|---|
| 목표와 요구사항이 모호함 | 질문을 통해 모호성을 줄이는 인터뷰 |
| 중요한 계획에 여러 관점의 검토가 필요함 | 계획자·설계자·비평가가 참여하는 합의형 계획 |
| 실패를 수정하며 검증될 때까지 계속해야 함 | 지속 실행 루프 |
| 서로 독립적인 작업이 여러 개 있음 | 병렬 팀 실행 |
| 작고 명확한 단일 작업 | 일반 Claude 또는 Codex 단일 실행 |
이 기준을 세우면서 한 가지 원칙을 명확히 했다.
> 강력한 도구를 가능한 한 많이 쓰는 것이 아니라, 현재 업무에 필요한 가장 작은 실행 방식을 선택한다.
### 4. 판단 기준을 대화가 아닌 스킬로 저장했다
완성된 기준은 `omc-omx-task-routing`이라는 Hermes 스킬로 만들었다. 이 스킬은 새 요청이 들어올 때마다 다음 순서로 작동한다.
1. OMC·OMX를 쓰면 실제 이점이 있는지 판단한다.
2. 이점이 없으면 불필요한 설명 없이 일반 방식으로 처리한다.
3. 이점이 있으면 추천 이유와 도구를 먼저 알려준다.
4. 실제 사용할 실행 방식과 단일 에이전트 대안을 함께 보여준다.
5. 사용자가 선택하기 전에는 실행하지 않는다.
가장 인상적이었던 순간은 여기였다. 이제 내가 매번 도구 이름을 기억해 지시하지 않아도, AI가 요청의 구조를 보고 다음과 같이 먼저 제안할 수 있다.
```
이 업무는 요구사항이 아직 모호해서 인터뷰 후 합의형 계획으로 넘어가는 방식이 유리해 보여. OMC로 진행할지, OMX로 진행할지, 아니면 일반 단일 에이전트로 처리할지 선택해줘.
```
단순한 “자동화”가 아니라 **판단은 선제적으로 지원하되 실행 권한은 사용자에게 남겨두는 구조**가 된 것이다.
### 5. 대화를 지워도 남는 업무 자산이 됐다
이 규칙은 현재 대화 안에만 적힌 메모가 아니다. Hermes의 영구 스킬 저장소에 별도 문서로 저장돼 있다. 사용자 선호 역시 지속 메모리에 분리돼 있다.
따라서 현재 대화를 종료하거나 삭제해도 다음 원칙은 유지된다.
- OMC·OMX가 유리한 업무인지 먼저 판단한다.
- 유리하다면 이유와 실행 선택지를 선제적으로 제시한다.
- 사용자의 선택 전에는 실행하지 않는다.
대화가 일회성 지시였다면, 스킬은 반복 사용할 수 있는 **개인 업무 운영 규칙**이 됐다.
---
## ✅ 결과
### Before vs After
| 항목 | Before | After |
|---|---|---|
| AI 도구 선택 | 내가 매번 기능과 명령을 기억해 선택 | AI가 업무 구조를 보고 적합한 방식과 대안을 먼저 제안 |
| 멀티에이전트 사용 | 강력해 보여도 언제 써야 할지 불명확 | 인터뷰·계획·지속 실행·병렬 작업 기준으로 구분 |
| 실행 통제 | 요청과 실행이 바로 연결될 수 있음 | 추천 후 사용자가 방식 선택, 그다음 실행 |
| 설치 신뢰도 | 설치 완료 여부 중심 | 경로·설정·훅·중복·Team 상태까지 실제 진단 |
| 지속성 | 현재 대화에 의존 | 대화와 분리된 스킬·지속 메모리로 보존 |
### 검증된 현재 상태
- Claude Code 중복 실행 경로 정리 완료
- OMC 설치 및 활성화 확인
- OMX 기본 진단: 18개 통과, 경고 0개, 실패 0개
- OMX Team 진단 통과
- 핵심 워크플로우 활성 상태 확인
- Hermes 라우팅 스킬 설치 및 파일 검증 완료
### 아직 측정하지 않은 것
- 실제 업무 시간 절감률
- OMC·OMX 추천 정확도
- 단일 에이전트 대비 멀티에이전트의 품질 개선 폭
이 값들은 아직 측정하지 않았기 때문에 성과 수치로 주장하지 않았다.
## 💬 이 과정에서 배운 AI 활용 팁
### 효과적이었던 것
1. **도구보다 선택 기준을 먼저 만든다**
- 설치 목록을 늘리기 전에 어떤 조건에서 어떤 방식을 쓸지 정의해야 한다.
2. **추천과 실행을 분리한다**
- AI는 이유와 선택지를 제시하고, 최종 실행 방식은 사용자가 고르게 한다.
3. **설치 메시지보다 진단 결과를 믿는다**
- 버전뿐 아니라 경로·설정·훅·중복 상태까지 확인해야 한다.
4. **정리 작업은 백업과 재검증까지 포함한다**
- 경고를 지우는 것이 아니라 문제 원인을 없애고 되돌릴 수 있어야 한다.
### 이렇게 하면 안 돼요
1. 모든 복잡한 업무에 무조건 멀티에이전트를 쓰지 않는다.
2. 서로 강하게 연결된 작업을 억지로 병렬화하지 않는다.
3. 과거에 한 번 승인했다는 이유로 다음 업무까지 자동 실행하지 않는다.
4. 권한 우회나 안전장치 해제를 기본 명령으로 사용하지 않는다.
## 🌍 다른 업무에 적용한다면?
이 방식은 OMC·OMX에만 한정되지 않는다.
- 문서 작성 도구가 여러 개일 때 산출물별 선택 기준 만들기
- 리서치 업무에서 직접 조사·LLM Wiki·외부 검색의 라우팅 기준 만들기
- PMO 업무에서 일정·회의·품질검토·대시보드 스킬의 실행 조건 만들기
- 반복 업무에서 자동 실행 전 승인 수준을 구분하는 안전 규칙 만들기
결국 개인 AI 에이전트의 경쟁력은 모델 하나가 아니라, **내 업무에 맞춰 축적된 선택 기준과 검증 절차**에서 나온다.
## 🚀 앞으로의 계획
다음 단계는 이 실행 스킬을 LLM Wiki와 온톨로지 개념에 연결하는 것이다.
- **LLM Wiki:** 도구, 업무 유형, 성공·실패 사례, 근거 자료를 축적
- **온톨로지:** 업무·도구·위험·승인·산출물 사이의 관계를 구조화
- **Hermes Skill:** 축적된 지식을 실제 행동과 승인 절차로 전환
예를 들어 “요구사항이 모호하고 보안 영향이 있는 기존 프로젝트 수정”이라는 요청이 들어오면, 지식저장소에서 유사 사례와 위험 기준을 찾고, 스킬이 적절한 인터뷰·합의형 계획·검증 워크플로우를 제안하는 구조다.
지식이 쌓이는 것에서 끝나지 않고, **지식이 다음 행동의 선택 기준으로 연결되는 개인 AI 업무체계**로 발전시키고 싶다.
## 📋 재사용 가능한 프롬프트
### 프롬프트 1: AI 도구 선택 스킬 만들기
> 내가 사용하는 AI 도구와 워크플로우를 점검해줘. 각 도구가 유리한 업무 조건과 불리한 조건을 구분하고, 새 요청마다 가장 적합한 도구·실행 방식·대안을 먼저 제안하는 재사용 스킬을 만들어줘. 자동 실행하지 말고 내가 방식을 선택한 뒤 진행하도록 승인 절차를 포함해줘.
### 프롬프트 2: 설치 상태와 충돌 가능성 점검하기
> 설치 완료 메시지만 믿지 말고 실제 실행 버전, 명령 경로, 설정 파일, 훅, 중복 스킬과 진단 결과를 확인해줘. 문제가 있으면 기존 사용자 설정을 보존하고 복구 가능한 백업을 만든 뒤 정리해줘. 마지막에는 같은 진단을 다시 실행해 경고와 실패가 남았는지 알려줘.
### 프롬프트 3: LLM Wiki와 실행 스킬 연결하기
> 내 업무 지식을 LLM Wiki에 축적하고, 업무 유형·도구·위험·승인·산출물 관계를 온톨로지 형태로 정리해줘. 그 지식에서 현재 요청에 적합한 실행 스킬을 찾되, 실행 전에는 추천 이유와 구체적인 선택지를 사용자에게 먼저 제시하도록 설계해줘.
