스킬 하나 만들었더니 9개가 얽혔다-문장 분석 AI에 ‘한 번에 하나만 고르는 라우터’를 만든 과정

📝 한줄 요약

문장과 글을 깊이 분석하는 AI 스킬을 만든 뒤, 포정해우·식소사번·법률 검토·문체 교정처럼 인접한 9개 스킬이 언제 연결되어야 하는지를 다시 설계했다. 단순한 관련 스킬 목록을 넘어, 현재 요청의 산출물에 맞는 스킬 하나만 선택하고 실제 정보공백이 발견될 때만 다음 스킬로 넘기는 5개 범주·12개 조건부 인계의 라우터, 즉 요청을 알맞은 스킬로 보내는 분기 도구를 만들었다.

바쁘시면 이것만 읽어도 됩니다:

• 시작은 “문장, 글을 분석하는 스킬”이라는 짧은 요청이었다.

• 문법만 고치는 도구가 아니라 명제·범위·논리·구조·문체·독자 효과를 근거와 함께 판독하는 전용 스킬을 만들었다.

• 지시어 중의성과 표본에서 전체로 확대되는 논리 비약을 별도의 새 세션에서 시험했다.

• 유사 스킬을 찾으며 포정해우·Humanizer·Copy Editing 등과 비교했지만, “식소사번은 어디 있어?”라는 질문에서 목록 중심 접근의 빈틈이 드러났다.

• 문제는 스킬의 부재가 아니라, 서로 다른 폴더와 용도에 흩어진 관련 스킬을 하나의 의미 체계로 보여주지 못한 것이었다.

• 그래서 9개 스킬을 5개 범주로 묶고, 현재 요청에는 1차 스킬 하나만 선택하는 text-reasoning-router를 만들었다.

• 8개의 경계 사례를 실제로 분류했고, 존재하지 않는 스킬을 참조하면 검증기가 실행을 차단하는지도 확인했다.

🎯 이런 분들께 도움됩니다

• AI 스킬이 늘어나면서 어떤 스킬을 언제 써야 할지 헷갈리는 사람

• 문장 분석, 논리 검토, 글쓰기, 법률 검토를 하나의 거대한 프롬프트로 처리하고 있는 사람

• 관련 스킬을 폴더별 목록이 아니라 실제 업무 흐름으로 연결하고 싶은 사람

• AI가 여러 도구를 한꺼번에 불러 과잉 분석하는 문제를 줄이고 싶은 사람

• 개인의 판단 방식을 재사용 가능한 스킬과 라우팅 규칙으로 만들고 싶은 비개발자

😫 문제 상황 — “글을 분석해 줘”에는 서로 다른 일이 섞여 있었다

“이 글을 분석해 줘”라는 요청은 단순해 보인다. 하지만 실제로는 전혀 다른 작업을 포함할 수 있다.

• 대명사가 누구를 가리키는지 판독한다.

• 주장의 근거와 숨은 전제를 찾는다.

• 문서 전체에서 결정적 정보공백을 찾는다.

• 빠진 사실을 사람에게 물을 질문을 설계한다.

• 법적으로 유효한 결론인지 조문과 판례를 검토한다.

• AI처럼 보이는 문체를 자연스럽게 고친다.

• 결론이 먼저 보이도록 문단 순서를 바꾼다.

이 작업들을 하나의 “글 분석”으로 묶으면 두 가지 문제가 생긴다.

첫째, AI가 사용자가 요청하지 않은 일까지 한다. 분석만 부탁했는데 전체 글을 다시 쓰거나, 문언의 의미만 물었는데 법률 의견처럼 답할 수 있다.

둘째, 전문 스킬이 많아질수록 오히려 선택이 어려워진다. 관련 스킬 목록을 길게 보여줘도 사용자는 어느 스킬부터 시작해야 하는지 알기 어렵다.

처음 요청은 아주 짧았다.

문장, 글을 분석하는 스킬

이 요청을 곧바로 기존 글쓰기 스킬에 넘기지 않았다. 현재 설치된 스킬을 먼저 확인해 보니, 각각 강점은 있었지만 문장·명제·논리·문단·문체·독자 효과를 하나의 근거 중심 분석으로 묶는 스킬은 없었다.

🌱 처음에는 ‘새 스킬 하나’면 충분하다고 생각했다

가장 가까운 기존 스킬은 다음과 같았다.

그래서 기존 포정해우 스킬을 늘리는 대신, 별도의 문장·글 분석 스킬을 만들기로 했다.

권장안으로 하자

여기서 중요한 조건은 기존 스킬에 영향을 주지 않는 것이었다. 새 스킬은 독립된 파일과 호출 조건을 갖고, 필요할 때만 포정해우를 관련 스킬로 참고하도록 했다.

🛠️ 사용한 도구와 자료

• Hermes Agent / TARDIS: 스킬 조사·작성·실행·검증·범주화 조율

• Hermes Skill 시스템: 반복 가능한 분석 절차와 라우팅 규칙 저장

• 기존 로컬 스킬: 포정해우, 식소사번, 상앙식 차등반응, 법률 검토, Humanizer 등 역할 비교

• Hermes Skills Hub와 공개 저장소: Copy Editing, Summsi, Word Counter 등 외부 후보 조사

• 스킬 패밀리 레지스트리: 스킬 범주·책임·조건부 연결을 사람이 읽고 프로그램도 검사할 수 있는 목록으로 저장

• 검증 스크립트와 새 Hermes 세션: 형식·참조·실제 라우팅을 독립적으로 시험

이 글에서 스킬은 AI가 반복해서 따를 수 있도록 저장한 업무 절차를 뜻한다. sentence-text-analysis는 문장·글 분석 절차의 시스템 이름이고, text-reasoning-router는 요청을 알맞은 스킬 하나로 보내는 분기 절차의 시스템 이름이다. Humanizer는 원뜻을 유지하면서 기계적이고 상투적인 표현을 자연스럽게 고치는 스킬이다. 포정해우·식소사번·상앙식 차등반응은 각각 구조와 틈 찾기, 사람에게서 작은 관찰 사실 확인하기, 선택과 행동에서 숨은 우선순위 추론하기를 맡는다.

🔧 작업 과정

1. 문법 교정기가 아니라 ‘근거 중심 판독기’를 만들었다

새 스킬의 이름은 sentence-text-analysis로 정했다.

단순히 맞춤법과 표현을 고치는 것이 아니라, 다음 층위를 구분해 보도록 설계했다.

1. 문장층: 주어·서술어, 수식 범위, 지시어, 생략, 중의성

2. 의미층: 핵심 명제, 전제, 함의, 범위와 양태

3. 논리층: 주장, 근거, 숨은 전제, 비약, 반례

4. 구조층: 문단 기능, 배열, 전환, 반복과 누락

5. 문체층: 어조, 리듬, 추상도, 수사와 AI 문체 징후

6. 독자층: 배경지식 부담, 오해 가능성, 설득 효과

7. 교정층: 최소 수정안과 적극 수정안

8. 검증층: 원뜻·범위·확실성 보존과 사실 추가 금지

핵심 원칙은 네 가지였다.

• 판단 전에 정확한 구절을 근거로 제시한다.

• 텍스트에서 직접 보이는 것과 해석한 것을 분리한다.

• 일부를 전체로, 가능성을 확정으로 바꾸지 않는다.

• 전면 재작성보다 문제를 고치는 최소 수정을 먼저 제안한다.

이렇게 하자 “문장이 어색하다”는 막연한 평가가 다음처럼 바뀌었다.

근거 구절 → 관찰 가능한 문제 → 가능한 해석 → 독자 영향 → 최소 수정 → 보존 여부

2. 실제 예문에서 ‘뜻을 바꾸지 않는지’ 시험했다

스킬 파일이 만들어졌다고 곧바로 완성이라고 부르지 않았다. 새 Hermes 세션을 열어 서로 다른 실패 유형을 시험했다.

첫 번째 문장은 지시어가 두 사람 중 누구를 가리키는지 불분명한 사례였다.

민수는 준호에게 보고서를 전달한 뒤 그가 수정해야 한다고 말했다.

스킬은 그가의 대상을 임의로 확정하지 않았다. 민수와 준호라는 두 가능성을 나누고, 수정 대상도 생략됐음을 표시한 뒤 각 해석에 맞는 최소 수정안을 제안했다.

두 번째 문장은 표본을 전체로 확대하는 사례였다.

세 명의 이용자가 새 절차를 불편해했다. 따라서 이 제도는 모든 이용자에게 실패했다.

스킬은 다음 두 점을 분리했다.

• 세 명에서 모든 이용자로 범위가 확대됐다.

• 불편함에서 제도 실패로 판단 강도가 높아졌다.

그리고 세 명의 반응만으로 전체 이용자의 실패를 확정할 수 없다는 점을 “알 수 없음”으로 남겼다. 두 실행은 내부 새 세션에서 분석 결과와 정상 종료 상태를 확인했다.

재검증용 사례는 두 문장만 두지 않았다. 지시어 중의성, 범위 비약, 가능성과 확정의 구별, 문단 구조, 문학적 반복, AI 문체 징후와 저자 판정의 구별, 사실 추가 금지, 두 문안의 목적별 비교까지 모두 8개 유형으로 만들었다. 공개 글에는 대표 사례 두 개를 풀어 쓰고, 나머지는 어떤 오류가 다시 생기면 안 되는지 확인하는 기준으로 사용했다.

3. 유사 스킬을 찾았더니 기능은 많았지만 관계가 보이지 않았다

다음 요청은 새 스킬을 더 넓은 생태계 안에서 비교해 보는 것이었다.

유사한 스킬을 검색해서 리스트업해봐

로컬 스킬, Hermes Skills Hub, 공개 저장소를 함께 살폈다.

이번에 확인한 Hermes Skills Hub와 공개 저장소 범위에서는 새 스킬과 완전히 같은 범위의 외부 스킬을 찾지 못했다. 확인한 후보 대부분은 문체, 요약, 가독성, 교육 평가처럼 한 영역에 집중했다.

조사는 2026년 7월 29일에 수행했다. 로컬 설치 스킬 목록과 Hermes Skills Hub에서 text analysis, writing critique, argument analysis, grammar rhetoric prose, proofread editor essay, literary analysis, copy editing을 검색하고, 검색 결과로 확인된 공개 GitHub 스킬 문서를 비교했다. 이는 당시 검색으로 확인 가능한 후보 비교이며, 인터넷의 모든 스킬을 전수조사했다는 뜻은 아니다.

하지만 이 목록에는 중요한 스킬 하나가 빠져 있었다.

4. 전환점 — “식소사번 스킬은 어디 있어?”

사용자가 물었다.

식소사번 스킬은 어디있어?

식소사번 스킬은 실제로 설치돼 있었다. 결론을 바로 묻지 않고, 결론을 구성하는 작은 관찰 사실을 적법한 질문으로 확보하는 면담·증인신문 설계 스킬이었다.

예를 들어 “회사가 지급불능 위험을 알고 있었습니까?”라고 결론부터 묻는 대신 다음을 묻는다.

• 급여 지급일이 언제부터 바뀌었는가

• 거래처의 독촉이 얼마나 늘었는가

• 결재 한도가 축소됐는가

• 현금지출 승인자가 바뀌었는가

• 회의에서 어떤 수치가 보고됐는가

이 질문은 문장 분석과 똑같은 기능은 아니다. 그렇지만 글이나 진술을 분석하다 결정적인 사실공백이 발견되고, 그 사실이 사람에게만 있을 때 바로 다음 단계가 된다.

여기서 문제의 본질이 드러났다.

식소사번이 누락된 것은 검색 실패라기보다, ‘비슷한 기능’만 찾고 ‘다음 단계의 관계’를 보여주지 못한 분류 실패였다.

단순 유사도 목록은 이름과 기능이 가까운 스킬을 보여준다. 하지만 실제 업무에서는 다음 질문이 더 중요하다.

• 지금 어느 스킬부터 시작해야 하는가?

• 어떤 조건이 확인되면 다음 스킬로 넘어가야 하는가?

• 어떤 단어가 나온 것만으로는 전문 스킬을 호출하면 안 되는가?

이 질문이 새 스킬 하나를 스킬 패밀리와 라우터로 확장하는 전환점이 됐다.

5. 폴더를 옮기지 않고 의미상 5개 범주를 만들었다

이런 관련스킬을 범주화시킬수는 없나?

물리적으로 스킬 폴더를 옮기는 방법도 있다. 그러나 그렇게 하면 기존 참조와 검색 경로가 깨질 수 있다. 게다가 reasoning, creative, productivity 같은 설치 폴더는 기술적 위치일 뿐, 실제 업무 순서를 설명하지 못한다.

그래서 기존 경로와 파일은 그대로 두고, 별도의 의미 레지스트리, 즉 스킬 관계표에서 다음 5개 범주를 만들었다.

전체 패밀리는 9개 설치 스킬로 구성됐다.

여기서 범주화의 목적은 보기 좋은 목록을 만드는 것이 아니었다. 현재 요청에 맞는 하나의 1차 스킬을 고르는 것이었다.

6. “관련 스킬을 모두 불러오지 않는다”는 라우터를 만들었다

사용자의 승인을 받은 뒤 text-reasoning-router를 만들었다.

그래, 네 생각이 좋아. 그렇게 하자

라우터의 핵심 계약은 간단하다.

현재 요청에서 당장 필요한 산출물을 판별한다.
→ 1차 스킬을 정확히 하나 선택한다.
→ 그 스킬을 실행한다.
→ 실제 인계 조건이 발견된 경우에만 다음 스킬을 하나 추가한다.

예를 들면 계약서라는 단어가 나왔다고 무조건 법률 검토를 시작하지 않는다.

• “상당한 기간이 무엇을 수식하는지 분석”은 문언의 범위가 산출물이므로 문장·글 분석으로 간다.

• “이 조항이 판례상 무효인지 검토”는 법률적 유효성이 산출물이므로 법률 검토로 간다.

AI라는 단어도 마찬가지다.

• “AI 문체 징후만 분석”은 진단이므로 문장·글 분석으로 간다.

• “뜻은 유지하고 AI 티를 없애기”는 실제 변환이므로 Humanizer로 간다.

증인이라는 단어도 자동으로 식소사번을 켜지 않는다.

• “진술서의 문장별 모순 찾기”는 텍스트 판독이다.

• “그 모순을 확인할 반대신문 질문 설계”는 사람에게서 사실을 확보하는 질문이 산출물이므로 식소사번이다.

이 원칙을 한 문장으로 줄이면 다음과 같다.

주제어가 아니라 이번 단계에서 사용자가 받아야 할 산출물로 라우팅한다.

7. 스킬 간 연결에 이름과 조건을 붙였다

스킬이 관련되어 있다는 정보만으로는 실행 순서를 정할 수 없다. 그래서 12개의 조건부 인계에 각각 관계 유형과 발동 조건을 붙였다.

대표 연결은 다음과 같다.

반대로 잘못된 자동 연결을 막는 규칙도 넣었다.

• 법률용어가 있다는 이유만으로 법률 검토를 시작하지 않는다.

• 정보가 부족하다는 이유만으로 사람에게 질문하지 않는다. 파일·로그·법령에서 찾을 수 있으면 먼저 조회한다.

• AI 문체가 보인다는 이유만으로 원문을 고치지 않는다.

• 표정이나 말투 하나로 숨은 선호를 단정하지 않는다.

• 관련 스킬 목록을 동시 실행 명령으로 해석하지 않는다.

8. 실제 경계 사례 8개로 라우터를 시험했다

라우터도 파일 생성만으로 끝내지 않았다. 새 Hermes 세션에서 헷갈리기 쉬운 요청 8개를 분류했다.

포정해우에서 이미 문서 전체 구조와 결정적 정보공백을 찾았고, 그 정보가 회의 참석자의 직접 경험에만 있는 상황도 별도로 시험했다. 라우터는 포정해우를 다시 실행하지 않고, 현재 산출물인 면담 질문을 위해 식소사번을 선택했다.

9. 잘못된 참조가 조용히 지나가지 않도록 고장 상황을 시험했다

레지스트리에는 5개 범주, 9개 스킬, 12개 조건부 연결이 들어 있다. 하지만 스킬 이름이 바뀌거나 삭제되면 관계표만 남고 실제 실행 대상이 없어질 수 있다.

이를 막기 위해 검증 스크립트를 만들었다.

검증기는 다음을 확인한다.

• 모든 범주에 실제 스킬이 하나 이상 있는가

• 대표 스킬이 해당 범주의 구성원인가

• 9개 구성 스킬이 실제로 설치돼 있는가

• 모든 연결의 출발점과 도착점이 존재하는가

• 자기 자신으로 돌아가는 잘못된 연결이 없는가

• 같은 관계가 중복되지 않았는가

• 한 번에 하나의 1차 스킬만 선택하는 정책이 유지되는가

마지막으로 존재하지 않는 가짜 스킬을 임시로 레지스트리에 넣었다. 검증기는 이를 즉시 탐지하고 실행을 중단했다.

정상 경로가 작동하는 것만 확인한 것이 아니라, 잘못된 상태가 조용히 통과하지 않는지도 확인한 것이다.

✅ 결과 — 1개 스킬이 5개 항로의 패밀리로 확장됐다

전후 비교

실제 산출물과 검증 범위

측정하지 않은 시간 절감이나 정확도 비율은 제시하지 않았다. 대신 실제 파일, 대표 문장 2개의 새 세션 분석, 8개 라우팅 결과, 구조 검사, 잘못된 참조를 막는 고장 상황 검사를 내부 증거로 남겼다. 공개 게시 시에는 라우팅 결과와 검증기 차단 화면을 이미지로 덧붙이면 독자가 이 결과를 직접 확인하기 더 쉽다.

레지스트리 구조 검사의 실제 출력은 다음과 같았다.

PASS family=text-reasoning lanes=5 members=9 relations=12 missing=0

경계가 헷갈리는 요청 8개의 실제 분류 결과도 모두 기대 항로와 일치했다.

1: sentence-text-analysis
2: legal-review-sequence
3: sentence-text-analysis
4: sikso-sabeon-elicitation
5: sentence-text-analysis
6: humanizer
7: shangyang-differential-response-analysis
8: value-first-reordering

존재하지 않는 가짜 스킬을 임시 사본에 넣은 검사에서는 다음처럼 실행이 차단됐다. 원본 레지스트리는 수정하지 않았다.

FAIL: missing local skills: missing-sentinel-skill
PASS: 존재하지 않는 스킬 참조를 탐지하고 검증을 중단함

이 증거는 2026년 7월 29일 당시 로컬 설치 상태와 내부 새 세션 실행 결과를 기록한다. 실제 업무 품질 향상률이나 시간 절감률을 측정한 자료는 아니다. 실행이 끝난 뒤 외부 도구 연결을 정리하는 과정에서 경고가 한 번 표시됐지만, 라우팅 작업은 정상적으로 끝났고 8개 결과도 모두 출력됐다. 기능 결과와 종료 뒤 정리 경고를 서로 다른 것으로 구분했다.

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

효과적이었던 것

1. 새 기능을 만들기 전에 기존 역할을 먼저 비교하기
   이름이 비슷한지만 보지 말고 입력, 산출물, 실패 조건, 다음 단계가 같은지 확인한다.

2. 분석과 변환을 분리하기
   문제를 찾는 것과 원문을 고치는 것은 다른 요청이다. 분석만 요청받았다면 전체 재작성으로 넘어가지 않는다.

3. 관련성을 실행 순서로 착각하지 않기
   관련 스킬 목록은 탐색용이다. 실제 인계에는 “어떤 조건이 관찰됐는가”가 필요하다.

4. 주제어보다 즉시 산출물로 라우팅하기
   계약서라도 문장 구조를 묻는다면 문장 분석, 일반 문서라도 법적 유효성을 묻는다면 법률 검토다.

5. 사람에게 물어야 할 정보와 파일에서 찾을 정보를 구분하기
   식소사번은 모든 정보공백에 쓰는 스킬이 아니다. 사람의 직접 경험이나 인식에 있는 사실을 적법하게 확보할 때 사용한다.

6. 정상 사례와 고장 상황을 함께 시험하기
   올바른 요청을 잘 분류하는 것뿐 아니라, 존재하지 않는 참조와 과잉 호출을 차단하는지도 확인한다.

7. 보기 좋은 폴더보다 안정적인 의미 레지스트리를 먼저 만들기
   기존 경로를 옮기지 않고도 범주·관계·조건을 별도 관계표로 관리할 수 있다.

이렇게 하면 안 됩니다

1. “글 분석”이라는 이유로 문법·논리·법률·문체 교정을 한꺼번에 실행하지 않는다.

2. 법률·증인·AI 같은 단어만 보고 전문 스킬을 자동 호출하지 않는다.

3. 문체 징후를 AI가 작성했다는 증거로 단정하지 않는다.

4. 하나의 지시어 또는 반응만으로 사람의 의도와 숨은 선호를 확정하지 않는다.

5. 관련 스킬을 모두 한 개의 거대한 스킬로 합치지 않는다.

6. 범주를 정리한다는 이유로 검증된 기존 스킬 경로를 섣불리 옮기지 않는다.

7. 성공 사례만 시험하고 깨진 참조가 통과하는지는 확인하지 않는 실수를 피한다.

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

고객지원 라우팅

“결제가 안 된다”는 말만으로 모든 지원 도구를 실행하지 않는다. 사용자가 원하는 현재 산출물이 원인 진단인지, 환불 규정 확인인지, 계정 상태 복구인지 구분하고 1차 담당 하나를 선택한다. 실제 원인이 다른 영역에 있을 때만 다음 팀으로 넘긴다.

법률·세무 상담

문언 해석, 사실확인, 법령 검토, 증거 보강, 불복 절차를 한 답변에 섞지 않는다. 현재 단계의 산출물을 고르고, 미확인 사실이 사람에게 있는지 공식 기록에 있는지에 따라 인계 경로를 달리할 수 있다.

문서 제작 파이프라인

요약, 구조 재배열, 문체 교정, 사실 검증, 발행은 서로 다른 책임이다. “보고서를 다듬어 달라”는 요청도 현재 필요한 결과가 무엇인지 먼저 분류하면 원문 훼손과 불필요한 재작업을 줄일 수 있다.

여러 AI 에이전트 운영

에이전트 이름을 늘리는 대신 각 에이전트의 즉시 산출물과 인계 조건을 정의할 수 있다. 관련 에이전트를 모두 호출하지 않고, 한 에이전트가 실제로 발견한 정보공백만 다음 에이전트에게 넘긴다.

🤝 배워서 남 주기

이번 결과는 특정 환경의 스킬 목록만 정리한 것이 아니다. 누구나 자신의 AI 도구 모음을 범주화할 때 사용할 수 있는 세 가지 원칙으로 정리할 수 있다.

1. 현재 산출물로 1차 책임을 고른다.
   이번 단계에서 사용자가 받아야 할 결과를 명사로 적는다.

2. 인계에는 관찰 가능한 조건을 붙인다.
   “관련 있으니까”가 아니라 어떤 정보공백·위험·변환 요청이 확인됐는지 적는다.

3. 잘못된 자동 연결을 명시적으로 막는다.
   분야를 나타내는 단어, 단일 반응, 미래 계획만으로 전문 흐름을 켜지 않도록 자동 선택 금지 규칙을 만든다.

이 원칙은 스킬 이름이나 플랫폼이 달라져도 그대로 재사용할 수 있다.

🕊️ 누구의 어려움을 줄일 수 있나

AI 도구가 적을 때는 이름만 기억해도 된다. 하지만 스킬과 에이전트가 늘어나면 사용자는 “무엇이 있는가”보다 “지금 무엇을 써야 하는가”에서 더 많이 막힌다.

이 사례가 줄이고 싶은 어려움은 세 가지다.

• 비개발자가 많은 스킬 이름을 외워야 하는 부담

• AI가 관련 도구를 과도하게 동원해 결과를 복잡하게 만드는 문제

• 분석·사실확인·법률검토·편집이 뒤섞이며 원문과 책임 경계가 흐려지는 문제

범주와 라우터가 있으면 사용자는 자연어로 원하는 결과를 말하면 된다. 내부에서는 현재 산출물에 맞는 스킬 하나가 선택되고, 실제 필요가 확인될 때만 다음 전문 흐름이 열린다.

🚀 앞으로의 계획

이 패밀리는 고정된 완성품이라기보다 실제 충돌 사례를 축적하는 운영 구조다.

1. 실사용 라우팅 사례 축적
   새 요청이 두 스킬 사이에서 헷갈릴 때 어떤 산출물이 결정적이었는지 기록한다.

2. 잘못된 자동 선택을 막는 재검증 사례 보강
   법률용어·AI 문체·정보공백처럼 과잉 호출을 만드는 패턴을 고장 상황 사례로 추가한다.

3. 정량 텍스트 지표의 선택적 연결
   Word Counter 같은 도구에서 문장 길이 분포와 반복어 등 의미를 침해하지 않는 보조 지표만 검토한다.

4. 다른 스킬 패밀리로 확장
   문서 변환, 강의 정리, 리서치, 발행처럼 여러 전문 흐름이 만나는 영역에도 같은 ‘하나의 1차 항로 + 조건부 인계’ 원칙을 적용한다.

📋 재사용 가능한 프롬프트

프롬프트 1: 여러 스킬을 의미 패밀리로 범주화하기

현재 설치된 [대상 스킬 목록 또는 스킬 디렉터리]를 조사해 주세요.
이름이 비슷한지보다 각 스킬의 즉시 산출물, 필요한 입력, 실패 조건, 다음 단계가 무엇인지 비교해 주세요.
기존 파일과 경로는 이동하거나 수정하지 말고, 3~7개의 의미 범주로 묶어 주세요.
각 범주마다 대표 스킬, 선택 조건, 선택하면 안 되는 조건을 적고, 관련 스킬 목록을 실행 순서로 해석하지 않도록 구분해 주세요.

프롬프트 2: 한 번에 하나만 선택하는 라우터 만들기

[스킬 패밀리 또는 에이전트 목록]을 위한 얇은 라우터를 설계해 주세요.
사용자가 이번 단계에서 받아야 할 즉시 산출물을 먼저 판별하고, 1차 스킬은 정확히 하나만 선택하게 해 주세요.
두 번째 스킬은 첫 번째 스킬이 관찰 가능한 인계 조건을 발견했을 때만 추가해 주세요.
주제어만으로 과잉 호출되지 않도록 우선 적용 규칙과 잘못된 자동 선택을 막는 규칙을 만들고, 경계가 헷갈리는 요청을 최소 8개 시험해 주세요.

프롬프트 3: 스킬 간 조건부 인계표 만들기

다음 스킬들의 관계를 단순한 related skills 목록이 아니라 조건부 인계표로 바꿔 주세요.
[스킬 목록]
각 관계에 출발 스킬, 관찰된 조건, 도착 스킬, 전달해야 할 정보, 선택하면 안 되는 상황을 적어 주세요.
파일·로그·공식 기록에서 찾을 수 있는 정보와 사람에게 질문해야 하는 정보를 구분하고, 존재하지 않는 스킬 참조가 있으면 실패하도록 검증 규칙도 제안해 주세요.

📌 마무리

처음에는 문장과 글을 잘 분석하는 스킬 하나가 필요했다. 그 스킬을 만들고 유사 스킬을 찾아보는 동안, 더 큰 문제가 보였다.

스킬이 부족한 것이 아니라 관계를 설명하는 언어가 부족했다.

식소사번은 문장 분석과 같은 기능이 아니었지만, 문장과 진술을 분석하다 사람에게만 있는 결정적 사실공백을 발견했을 때 반드시 이어질 수 있는 다음 단계였다. 이 관계를 발견하면서 스킬 관리는 폴더와 목록의 문제가 아니라 현재 산출물과 조건부 인계의 문제가 됐다.

가장 중요한 한 문장은 이것이다.

관련된 것을 모두 불러오지 말고, 지금 필요한 하나를 고른 뒤 실제 조건이 확인될 때만 다음 방을 연다.