두 개의 스킬을 만들 필요가 없었군 - 애써 나눈 스킬을 하나로 합친 이야기

두 개의 스킬을 만들 필요가 없었군..

📝 한줄 요약

비슷한 일을 하는 두 개의 Skill을 따로 만들지 않고, 하나의 Skill 안에 기본 route와 AI route를 만들었습니다.

평소에는 기본 route를 사용하고, AI의 자연스러운 설명이 필요할 때만 AI route를 선택합니다.

공통 과정은 한 곳에서 관리하므로 유지보수와 검증을 반복하지 않아도 됩니다.

🎯 이런 분들께 도움돼요

• Skill을 여러 개 만들었지만 서로 겹치는 부분이 많은 분

• AI 자동화를 만들면서 기본 기능과 선택 기능을 나누고 싶은 분

• 비개발자도 이해할 수 있는 단순한 실행 구조를 만들고 싶은 분

• AI가 만든 설명과 원본 데이터를 안전하게 분리하고 싶은 분

😫 문제 상황 (Before)

비슷한 작업을 하는 Skill을 두 개로 나눠 쓰고있었습니다.

첫 번째 작업은 원본 로그를 Python 스크립트로 사람이 읽을 수 있는 문서로 바꾸는 일이었습니다. 두 번째 작업은 같은 원본 로그를 AI가 더 자연스럽게 설명하는 일이었습니다.

하지만 비슷한 작업을 하고 있는 2개의 스킬을 가진 것 뿐입니다. 전체 과정을 다시 살펴보니 두 작업의 대부분은 같았습니다.

• 같은 원본 로그, 같은 실행 폴더를 확인, 같은 candidate와 validation 과정, 같은 Dashboard 검토와 승인 과정

비슷한 과정을 두 개의 Skill로 따로 관리하면 한쪽을 수정할 때 다른 쪽도 함께 확인해야 합니다. 검증 규칙을 바꾸거나 출력 형식을 수정할 때도 같은 일을 두 번 해야 합니다. 또, 시간이 지나면서 두 Skill의 동작이 달라질 수 있습니다. 한쪽에는 새로운 안전장치를 추가했는데 다른 쪽에는 빠져 있다면, 같은 종류의 작업인데도 결과가 달라질 수 있습니다.

🛠️ 사용한 도구

• 도구: Codex

• 대상: 주간 로그 동기화 Skill

• 결과 형식: 기본 Markdown 기록과 선택적 AI 설명 Markdown

• 핵심 설계: 하나의 Skill 안에 기본 route와 AI route 구성

🔧 작업 과정

비슷해 보이는 두 작업을 다시 비교했습니다

처음에는 문서를 만드는 방법이 다르다는 이유로 Skill을 나누려고 했습니다.

하지만 Skill 전체의 흐름을 나란히 놓고 보니 차이는 일부 단계에만 있었습니다.

첫 번째 흐름: a → b → c → d
두 번째 흐름: a → b′ → c → d

두 흐름 모두 처음과 마지막은 같았습니다. 중간만 달랐습니다.

이때 중요한 질문은 “공통 과정이 얼마나 많은가?”였습니다.

공통 과정은 하나로 합쳤습니다

공통 과정은 sync-harness-week-logs 하나가 담당하도록 했습니다.

sync-harness-week-logs
├─ 기본 route
│  a → b → c → d
│
└─ AI route
   a → b′ → c → d

필요한 경우에만 route를 선택하도록 했습니다

일반적으로 Skill을 호출하면 기본 route가 실행됩니다.

AI가 더 쉽게 설명해주기를 원하는 경우에만 AI route를 선택합니다.

이미 기본 route가 실행되어 유효한 결과가 있다면 그 결과를 다시 만들지 않습니다.

기존 기본 기록이 유효함
→ 기존 기본 기록 재사용
→ AI 설명 작성
→ 이후 검증 과정 실행

반대로 기본 기록이 없거나 원본 로그가 변경되었다면 먼저 기본 기록을 새로 만듭니다. 오래된 결과를 조용히 재사용하지 않도록 확인 절차를 둔 것입니다.

기존 AI Skill은 삭제하지 않고 연결 통로로 남겼습니다

기존에 사용하던 generate-ai-week-log 호출을 바로 없애지는 않았습니다.

대신 이 Skill을 호출해도 실제 작업은 통합된 sync-harness-week-logs의 AI route가 처리하도록 했습니다.

기존 사용 방식으로 호출하고 싶을 때 사용 할 수 있습니다.

겉으로는 이전 이름을 계속 사용할 수 있지만, 안에서는 중복된 전체 pipeline을 실행하지 않습니다.

✅ 결과 (After)

Before vs After

가장 큰 변화는 Skill의 개수가 줄었다는 사실이 아닙니다. 공통 과정과 선택 과정을 분리하면서, 필요한 경우에만 의도를 말하면 되도록 만든 점이 핵심입니다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. Skill을 나누기 전에 전체 흐름을 먼저 비교하기
   출력 파일이 다르다는 이유만으로 Skill을 나누지 말고, 처음부터 끝까지 어떤 단계가 같은지 비교하는 것이 중요했습니다.

2. 공통 과정과 선택 과정을 구분하기
   전체 과정 중 일부만 다르다면 Skill을 두 개 만들기보다 route로 나누는 방법을 먼저 검토할 수 있습니다.

3. 원본과 설명을 분리하기
   원본 데이터는 사실의 기준으로 남기고, AI 문서는 그 내용을 설명하는 보조 문서로 두어야 안전합니다.

4. AI route는 명시적으로 호출하기
   기본 작업에 AI를 항상 끼워 넣지 않고, 사용자가 원하는 경우에만 선택하게 하면 사용법이 단순해집니다.

이렇게 하면 안 돼요

1. 전체 Skill을 복사해서 하나 더 만들지 않습니다.

2. 기본 route와 AI route의 검증 기준을 서로 다르게 만들지 않습니다.

🌍 다른 업무에 적용한다면?

이 구조는 로그 정리 외에도 여러 곳에 적용할 수 있습니다.

• 기본 보고서와 임원용 요약 보고서

• 표준 회의록과 AI가 풀어쓴 회의 설명

• 기계가 읽는 결과와 사람이 읽는 안내문

• 기본 알림과 사용자가 요청했을 때만 제공하는 상세 설명

핵심은 업무의 본체는 하나로 두고, 사람에게 보여주는 방식만 route로 나누는 것입니다.

앞으로 새로운 출력 형식이 필요해도 전체 Skill을 하나 더 복사하지 않고, 기존 Skill 안에 새로운 route를 추가하면 됩니다.

🚀 앞으로의 계획

앞으로는 새로운 Skill을 만들기 전에 먼저 다음 질문을 확인하려고 합니다.

1. 기존 Skill과 시작점이 같은가?

2. 마지막 결과를 검증하는 과정이 같은가?

3. 실제로 다른 부분은 중간의 한두 단계뿐인가?

4. 기본 사용과 선택 사용으로 나눌 수 있는가?

이 질문에 대한 답이 대부분 “그렇다”라면 새로운 Skill을 만들기보다 기존 Skill에 route를 추가하는 방향을 먼저 검토할 것입니다.

📋 재사용 가능한 프롬프트

이 두 작업은 정말 별도 Skill이 필요한가? 공통 과정과 다른 과정으로 나누어 보고, 하나의 Skill 안에서 route로 합칠 수 있는지 검토해줘.