[AX 시리즈 100편 기념 특집] 능력을 119개 만들었더니 16개가 80%를 합니다 — 하네스를 늘리는 것과 기르는 것의 차이

여섯 단으로 된 사다리 위에 능력 블록들이 얹혀 있고, 위 칸일수록 가볍고 아래 칸일수록 무겁게 표현된 개념도 — '어디에 두느냐가 비용을 정한다'는 은유

AX 시리즈 100편 기념 특집 2편 · 하네스 고도화

100편 기념 특집 — 세 편으로 읽는 하나의 지도

무엇을 갖고 있는가 — 운영 화면 다섯 장과 지식 구조 일곱 층을 통째로 엽니다
어디에 둘 것인가 지금 이 글 — 그 일곱 층이 늘어날 때 무엇이 비싸지는지, 그리고 새것을 어느 층에 둘지 정합니다
무엇을 사람이 쥐는가 — 업무 원형 22개에서 뽑은 위임 경계입니다

규칙 한 줄로 시작한 하네스는 금방 늘어납니다. 그리고 대여섯 개를 넘는 순간 새로운 문제가 생깁니다 — “이 새 능력을 어디에 둘 것인가.” 저는 이 판단을 잘못해서 능력을 119개까지 늘렸고, 세어보니 그중 16개가 전체 사용의 80%를 하고 있었습니다. 늘리는 법이 아니라 어디에 둘지 고르는 법에 대한 글입니다.

바쁜 분을 위한 3줄 요약

능력은 고르게 쓰이지 않습니다. 팩 119개 중 16개(13%)가 누적 라우팅 26,957건의 80%를 차지했고, 9개는 한 번도 선택되지 않았습니다.
그래서 “만들까 말까”가 아니라 “어느 층에 둘까”가 진짜 질문입니다. 6단 배치 사다리에서 ①~③은 비용이 거의 0이고, ④(팩)부터 정밀도·지연·관리 비용을 냅니다.
계측 지표는 세 개면 됩니다 — 빈 선택률·사용 분포·마지막 사용일. 제 빈 선택률은 3개월 창 17.8%에서 최근 30일 4.7%로 내려왔습니다.

The second problem규칙 다섯 개를 넘으면 시작되는 두 번째 문제

처음 하네스를 만들 때의 문제는 단순합니다. “무엇을 규칙으로 만들 것인가.” 같은 실수를 두 번 한 자리를 찾아 한 줄 적으면 됩니다.

그런데 그렇게 대여섯 개가 쌓이면 성격이 다른 문제가 옵니다. 새로 만들 것이 생겼을 때 — 이걸 기존 규칙에 한 줄 더할지, 새 규칙으로 뺄지, 아예 다른 형태로 만들지를 매번 정해야 합니다. 그리고 이 판단을 안 하면 기본값은 언제나 “새로 하나 더 만들기”입니다. 그게 제일 쉬우니까요.

저도 그랬습니다. 3개월 동안 제안서를 200건 넘게 쓰면서, 쓸모 있어 보이는 건 일단 만들었습니다. 결과는 능력 119개였습니다. 문제는 그 다음이었습니다.

늘어난 것의 비용은 나중에 옵니다

능력 하나를 만드는 비용은 30분입니다. 그런데 그 하나가 이후 모든 요청에서 “이번엔 이게 맞나”를 판별당합니다. 후보가 많아질수록 엉뚱한 게 뽑히고, 판별에 시간이 더 걸리고, 안 쓰는 걸 언제 버릴지 결정해야 합니다. 만드는 비용은 한 번, 갖고 있는 비용은 매번입니다.

Power law실측 — 119개를 만들었더니 16개가 80%를 합니다

감이 아니라 수를 세어 봤습니다. 팩별 누적 선택 횟수를 뽑아 정렬한 결과입니다.

프롬프트 팩별 누적 라우팅 분포 막대 도식 — 작업 단축 트리거 4,939건(18.3%), 프로젝트 관리 판단 기준 3,759건(13.9%), 보고서 품질 바 3,199건(11.9%) 등 상위 12개가 나열되고 나머지 107개 팩 전부가 6,518건(24.2%). 우측에 상위 16/119개가 라우팅의 80%를 차지한다는 수치와 한 번도 선택되지 않은 팩 9개 표시 — 팩별 누적 라우팅 26,957건의 분포 (2026-08-05 기준 · 표시명은 역할 한글 라벨 · 고객사 종속 팩은 익명 처리)

119

만든 능력(팩)

사용의 80%를
차지하는 개수

한 번도
선택되지 않음

22일 이상
미사용

90일 이상 미사용
(폐기 후보 없음)

상위 3개가 차지하는
비율 44%

이 분포는 이상 현상이 아닙니다. 능력을 늘리면 거의 언제나 이렇게 됩니다. 자주 하는 일이 자주 있으니까요. 문제는 분포 자체가 아니라, 긴 꼬리가 공짜가 아니라는 사실을 모르고 계속 늘리는 것입니다.

So what여러분 환경에서도 같은 것을 재보십시오. 규칙이든 템플릿이든 프롬프트든, “지난 한 달 동안 실제로 몇 번 썼는가”를 세면 대개 비슷한 모양이 나옵니다. 그 표를 처음 보는 순간이 고도화의 출발점입니다.

The ladder배치 사다리 — 만들기 전에 “어느 층인가”를 먼저 묻습니다

그래서 저는 새 능력을 만들 때 여섯 개의 층을 위에서부터 검토하고, 충분한 층에서 멈추는 규칙을 씁니다. 핵심은 위층일수록 싸다는 것입니다.

배치 사다리 6단 도식 — ①기존 것 확장(비용 0) ②경로 규칙(비용 0, 열 때만 로드) ③온톨로지 데이터(데이터 1행) ④프롬프트 팩(후보 풀 비용: 정밀도·지연·관리) ⑤스킬(호출 표면) ⑥외부 연동(연결·인증·유지). 하단에 규칙으로 가는 것=사람이 도구 없이 해도 유효한 절차, 팩으로 가는 것=판단의 잣대를 바꾸는 기준이라는 경계 판단 두 카드 — 배치 사다리 — 위에서부터 검토하고 충분하면 멈춥니다 (추가를 막는 규칙이 아니라 층을 고르는 규칙)

가장 자주 쓰이는 판단선

사람이 도구 없이 수행해도 유효한 절차·확인이면 → 규칙(②).
결과물의 판단 기준 자체가 달라지는 것이면 → 팩(④).
둘 다 해당하면 쪼갭니다 — 절차는 규칙으로, 판단은 팩으로. 이 한 줄이 제 경우 가장 많은 오배치를 막았습니다.

일곱 층은 “늘어날 때 갉는 것”이 각각 다릅니다

앞 글에서 제 지식 구조를 일곱 층으로 열어 보였는데, 그때는 무엇이 얼마나 쌓였는가만 보여드렸습니다. 정리를 하려면 하나가 더 필요합니다 — 층마다 증식의 대가가 다르다는 것입니다. 팩만 조심하면 되는 게 아닙니다.

층 (현재 규모)	늘어날 때 갉는 것	어떻게 막는가
① 도메인 온톨로지 20개	판별 부하는 없지만 낡음이 쌓입니다. 갱신 안 된 좌표를 계속 참조하게 됩니다	늘리는 걸 막지 말고 마감 절차에 재봉인을 묶습니다
② 프롬프트 팩 119개	판별 정밀도와 지연 — 이 글에서 실측한 유일한 층입니다	사다리로 ①②③에 흡수 + 수명주기로 회수
③ 운영 규칙 29개	로드 비용은 0이지만 게이트끼리 충돌합니다. 같은 취지의 확인이 두 군데 생기면 정본이 흐려집니다	신설 전에 기존 게이트와 의미 중복을 확인하고 겹치면 병합
④ SOP 16건	사람이 읽어야 작동합니다. 늘어날수록 안 읽힐 확률이 올라갑니다	절차가 자동화 가능해지면 규칙으로 내려보냅니다
⑤ 사례 코퍼스 1,205건	회수 정밀도가 희석됩니다. 비슷한 사례가 많아지면 가장 가까운 것이 안 나옵니다	좌표(업종·일 유형·근거 등급)를 붙여 넓히지 말고 나눕니다
⑥ 회수 계획 6종	경로가 많아지면 엉뚱한 데서 먼저 찾습니다	기본 경로 하나를 정하고 나머지는 예외로 둡니다
⑦ 아웃컴 보상 루프	바꾼 근거가 된 데이터를 그 변경의 효과 증거로 다시 쓰면 측정이 오염됩니다	채택 전후 창을 분리해서 재측정합니다

이 표에서 계측된 것은 한 줄뿐입니다

②의 정밀도·지연은 실제로 잰 값입니다. 나머지 여섯 줄은 각 층의 구조적 성질에서 따라 나오는 것이지 제가 측정한 값이 아닙니다. 그래서 “이 층은 몇 개가 적정”이라는 숫자는 쓰지 않았습니다 — 층마다 무엇을 지켜봐야 하는지만 적었습니다.

가장 흔한 오배치 세 가지

이렇게 만들기 쉽습니다	실제로는	왜
업종마다 전용 능력을 하나씩 만든다	③ 데이터 한 행으로 흡수	업종 차이의 대부분은 용어와 좌표지 판단 기준이 아닙니다. 데이터로 두면 후보 풀이 안 커집니다
“이럴 땐 이렇게 하자”를 새 능력으로 만든다	② 경로 규칙이면 충분	특정 폴더를 열 때만 붙으면 되는 규율은 평소엔 존재하지 않는 것과 같습니다 — 비용이 0
기존 것과 겹치는데 이름이 달라서 새로 만든다	① 기존 것에 한 줄	겹치는 능력 둘은 서로를 갉습니다. 판별기가 매번 둘 사이에서 헷갈립니다

다만 사다리를 관문으로 만들지 마십시오

이 사다리를 승인 절차로 바꾸면 만드는 속도가 죽습니다. 저는 3개월에 200건 넘게 만드는 속도로 일하는데, 그 속도를 관료제로 눌렀다면 지금의 자산은 없었을 겁니다. 그래서 이건 막는 규칙이 아니라 고르는 규칙이고, ④ 이하로 갈 때 “왜 위쪽으로는 안 되는지” 한 줄만 남기게 합니다.

Lifecycle수명주기 — 두 번의 기회를 주고 내립니다

배치를 잘해도 시간이 지나면 안 쓰이는 것이 생깁니다. 버리는 규칙이 없으면 사다리는 반쪽입니다.

22일 미사용 → 검토 대상. 지우지 않고 표시만 합니다. 계절성 있는 업무(분기 보고, 연말 평가)가 여기서 잘못 잘립니다.

90일 미사용 → 폐기 후보. 이때 처음으로 지울지 묻습니다. 두 번의 기회를 주는 셈입니다.

단, 면제 조항이 있습니다. 다른 규칙이 근거로 참조하는 능력은 사용 기록이 0이어도 보호합니다. 판별기가 안 뽑을 뿐 규칙이 직접 부르기 때문입니다 — 이걸 빼먹으면 살아 있는 걸 지웁니다.

지금 제 상태는 22일 이상 미사용 23개, 90일 이상은 0개입니다. 90일이 0이라는 건 수명주기가 실제로 돌고 있다는 뜻이고, 23개가 있다는 건 다음 분기 정리 대상이 그만큼이라는 뜻입니다.

어디서 온 능력인가	개수	수명주기에서의 취급
작업 중에 필요해서 만든 것	91	일반 대상 — 사용 기록으로 판정합니다
절차(스킬)가 참조하는 것	18	절차가 살아 있으면 함께 보존
규칙이 근거로 삼는 것	7	사용 기록 0이어도 면제
기본 제공	3	제거 대상 아님

So what버릴 때 필요한 건 “안 썼다”는 사실만이 아닙니다. “왜 만들어졌는가”가 함께 기록돼 있어야 안전하게 버립니다. 능력을 만들 때 출처 한 줄을 같이 남기십시오 — 나중에 그 한 줄이 지울지 말지를 결정합니다.

Telemetry계측 — 지표는 세 개면 충분합니다

여기까지가 설계라면, 이제 그 설계가 맞았는지 아는 방법입니다. 저는 처음에 지표를 많이 봤는데, 실제로 행동을 바꾼 건 셋뿐이었습니다.

지표	무엇을 알려주는가	움직였을 때 할 일
빈 선택률 아무 능력도 안 뽑힌 비율	커버리지 공백. 높으면 새 유형의 일이 들어오고 있다는 신호	빈 선택 요청을 모아 유형을 묶습니다. 같은 유형이 다섯 건 넘으면 그때가 새 능력이 정답인 순간
사용 분포 상위 몇 개가 80%인가	꼬리의 길이. 급격히 길어지면 오배치가 쌓이는 중	꼬리 쪽을 사다리로 재검토 — 대부분 ②나 ③으로 내려갑니다
마지막 사용일 능력별 경과 일수	수명주기 진입 시점	22일·90일 두 문턱에서 자동으로 표시되게 만듭니다

제 실측 궤적 — 그리고 이것을 성과라 부르지 않는 이유

빈 선택률은 제 환경에서 이렇게 움직였습니다.

31%

3개월 창
(2026년 6월 시점)

17.8%

91일 누적
(5/6~8/5 · 11,562건)

4.7%

최근 30일
(5,875건)

이 숫자를 인과로 읽지 마십시오

세 값은 창(window)이 서로 다릅니다. 그리고 같은 기간에 능력도 늘었고 판별 조건도 손봤고 제가 하는 일 자체도 바뀌었습니다. “사다리를 도입해서 내려갔다”고 말할 근거가 없습니다. 제가 말할 수 있는 건 추세가 관측됐다는 것까지입니다. 자기 하네스를 계측하실 때도 이 구분을 지키시는 편이 좋습니다 — 계측의 목적은 자랑이 아니라 다음 행동을 정하는 것이니까요.

참고로 판별에 걸리는 시간은 중앙값 234밀리초, 상위 5%가 961밀리초입니다. 이 값이 커지기 시작하면 후보가 너무 많아졌다는 뜻이라, 꼬리를 정리할 때가 된 것입니다.

Do it today오늘 할 수 있는 세 가지

도구가 무엇이든 순서는 같습니다. 규칙 파일이든 프롬프트 모음이든 문서 템플릿이든 상관없습니다.

목록을 만들고 옆에 “지난달 사용 횟수”를 적습니다. 기록이 없으면 기억으로라도 적으십시오. 대부분 절반 이상이 0일 겁니다. 그 표를 보는 게 1단계 전부입니다.

0인 것들을 사다리로 다시 봅니다. “이건 사실 특정 폴더 작업할 때만 필요한 것 아닌가?”, “이건 판단 기준이 아니라 용어 목록 아닌가?” — 대부분 아래층에서 위층으로 옮겨집니다. 옮기면 후보 풀에서 빠져 판별이 정확해집니다.

계측 한 줄을 붙입니다. 거창할 필요 없습니다. 능력을 쓸 때마다 이름과 날짜 한 줄을 파일에 덧붙이면 그게 사용 기록입니다. 한 달 뒤 그 파일을 세면 위 세 지표가 다 나옵니다.

순서를 바꾸지 마십시오

계측 없이 정리부터 하면 쓸모 있는 걸 지웁니다. 반대로 계측만 하고 정리를 안 하면 표만 늘어납니다. 목록 → 재배치 → 계측 순서로 한 바퀴를 돌리고, 그 다음부터는 계측이 재배치를 알려주게 됩니다.

Honesty정직한 한계

관측119개·26,957건·16개가 80%·9개 미선택·23개 22일 초과는 전부 원장을 직접 집계한 값입니다. 본문의 도식도 원장을 읽어 생성했으므로, 자산이 늘면 도식이 따라 갱신됩니다.

1인 환경이 분포는 혼자 쓰는 하네스의 것입니다. 여럿이 쓰면 사용이 더 고르게 퍼질 수도, 팀별로 더 쏠릴 수도 있습니다. 표본은 하나입니다.

미검증“사다리대로 배치하면 품질이 오른다”는 측정하지 않았습니다. 측정한 것은 후보 풀 크기·판별 시간·빈 선택률이지 산출물 품질이 아닙니다. 효과가 아니라 비용 구조에 대한 주장입니다.

주의꼬리가 길다는 것이 “만들지 말았어야 했다”는 뜻은 아닙니다. 커버리지 공백을 메우려면 새 능력이 정답일 때가 있습니다. 이 글의 주장은 “적게 만들라”가 아니라 “맞는 층에 두라”입니다.

Closing능력을 늘리는 일과 하네스를 기르는 일은 다릅니다

119개를 세어 보기 전까지 저는 제가 하네스를 기르고 있다고 생각했습니다. 실제로는 능력을 늘리고 있었을 뿐이었습니다. 둘은 초반에는 같아 보이지만, 어느 지점부터 갈라집니다 — 늘리기만 하면 판별이 흐려지고, 안 쓰는 것이 쌓이고, 어디에 뭐가 있는지 본인도 모르게 됩니다.

기르는 쪽으로 돌리는 방법은 의외로 단순했습니다. 만들기 전에 “어느 층인가”를 한 번 묻고, 만든 뒤에 “쓰이는가”를 한 번 세는 것. 그 두 번의 질문이 늘리기와 기르기를 가릅니다.

오늘 목록 한 장만 만들어 보십시오. 옆 칸에 지난달 사용 횟수를 적는 순간, 다음에 무엇을 해야 할지가 그 표 안에 이미 적혀 있을 겁니다.

AGENTIC PM 시리즈 — 전체 102편 · 조직을 바꾼다 24 · 나를 바꾼다 67 · 공용 11 · 전체 보기 →

조직을 바꾼다AIDD 도메인주도 컨설팅 · 24편

🎯 조직 문 진입 (종합 게이트)

M-2 당신의 도메인은 어느 답을 받았습니까 — 일곱 도메인 26주 종합

🏭 도메인 26주 실증

🧩 배정·관문 설계

📈 AX 전략·조직 전환

🏢 조직 단위 기록

나를 바꾼다AX 역량 · 67편

🔄 역할·역량 전환

🧱 개념·프레임워크

🧠 사고 체계·개인 지식

🔧 하네스·에이전트 구축

⚖️ 모델·도구·환경 실측

🧪 AI 개발·SDLC 실험

🤝 사람·소통·평가 대화

👤 AI 인물·리더

🏫 워크숍 현장 기록

두 문이 함께 딛는 근거하네스 · 수렴 · 월간 · 11편

🧭 길잡이·수렴 (두 문 공용)

검색

RSS 구독