AI 에이전트 스킬 재사용률 24%, 원인은 회수 배선 부재였다

무엇이 문제였나 — 정성 피드백만으로 자율성을 판단해 왔다

에이전트에게 업무 자동화 작업을 맡긴 지 시간이 꽤 지났을 때, 이 회사가 실제로 쓸 수 있는 판단 재료는 '요즘 좀 더 알아서 하는 것 같다' 같은 인상뿐이었습니다. 사람이 개입해야 승인해 주는 지점(게이트)을 좁힐지 넓힐지, 새로 만든 작업 절차(스킬)를 계속 늘려도 되는지를 전부 이 인상으로 결정하고 있었습니다.

인상만으로 판단하면 두 가지를 확인할 방법이 없습니다. 좋아졌다는 느낌이 실제로 좋아진 것인지 증명할 수 없고, 조용히 나빠지고 있어도 눈치채지 못합니다. 그래서 사람 개입이 얼마나 잦은지, 실패했을 때 스스로 회복하는 비율이 얼마나 되는지, 만들어 둔 작업 절차가 실제로 다시 쓰이는지를 숫자로 재는 지표를 정의하기로 했습니다.

이 인상 기반 판단이 오래 쌓이면 판단 자체가 판단의 근거가 되는 순환이 생깁니다. '요즘 괜찮아 보인다'는 인상으로 승인해야 하는 지점을 넓히고, 넓어진 지점 아래에서 다시 '역시 괜찮아 보인다'는 인상을 얻는 식입니다. 이 순환을 끊으려면 인상이 아니라 매번 같은 방식으로 셀 수 있는 숫자가 필요했습니다.

• 인간 개입 비율 — 사람이 얼마나 자주 끼어드는가
• 비용 대비 성공률 — 하나를 끝내는 데 비용과 시간이 얼마나 드는가
• 실패 자력 복구율 — 막혔을 때 도움 없이 스스로 회복하는가
• 표류 빈도 — 같은 자리를 맴도는 일이 얼마나 잦은가
• 스킬 재사용률 — 한 번 만든 작업 절차가 다른 세션에서도 다시 불려 쓰이는가

이 다섯 가지를 정리해 둔 문서의 제목에는 '4가지 핵심 지표'라고 적혀 있었습니다. 목록을 하나씩 세어 보니 실제로는 다섯 번째 항목이 따로 있었고, 그 다섯 번째가 바로 스킬 재사용률이었습니다. 이름표부터 실제 개수와 어긋나 있었던 셈인데, 그 사실 자체가 이 지표들을 정말로 재보기 전까지는 아무도 이상하다고 느끼지 못했다는 증거이기도 했습니다.

다섯 지표 각각을 왜 만들었는지도 근거가 있었습니다. 실패했을 때 사람이 개입하지 않고 스스로 복구하는 비율을 재려는 이유는, 다른 회사 사례에서 같은 답을 58회나 반복해도 알아채지 못한 일이 있었기 때문입니다. 표류 빈도를 재려는 이유는 도구를 50개 넘게 연이어 부르기 시작하면 품질이 눈에 띄게 떨어진다는 연구 결과 때문이고, 같은 조건에서 이전 목표를 다시 읽어 주는 절차를 넣으면 정확도가 4% 오른다는 실험도 있었습니다. 실패 자력 복구율을 조심스럽게 다루는 이유는 또 있습니다 — 외부 신호 없이 스스로 답을 고치게 시키면, 원래 정확도가 높은 모델일수록 오히려 16.7%까지 떨어진다는 연구가 있어서, 단순히 '다시 해봐'만 반복하는 방식으로는 이 지표를 개선할 수 없다고 봤습니다.

이 네 지표는 전부 근거는 갖췄지만 아직 측정 도구가 없었습니다. 사람 개입 횟수를 세려면 검사 기록을 전부 훑어야 하고, 표류 빈도를 재려면 같은 결과가 반복되는 것을 자동으로 잡아내는 장치가 따로 있어야 합니다. 그런데 스킬 재사용률은 달랐습니다 — 세션 기록에 이미 '이 이름을 불렀다'는 흔적이 남고 있었기 때문에, 새 장치 없이도 그 흔적만 세면 첫 측정이 가능했습니다. 다섯 지표 중 스킬 재사용률만 먼저 잴 수 있었던 이유가 여기에 있었습니다.

다른 회사는 이미 숫자로 재고 있었다

이 지표들을 처음부터 만들어 낸 것은 아닙니다. 에이전트를 만드는 다른 회사가 2026년 4월 자체 측정 결과를 공개로 발표했는데, 경험 많은 사용자 기준 자동 승인 비율이 약 40%, 사람이 끼어드는 비율이 약 9%였습니다. 세션 하나당 사람이 개입하는 횟수는 5.4회에서 3.3회로, 응답 하나를 처리하는 시간의 99.9 백분위수는 25분에서 45분으로 늘었다고 밝혔습니다 — 처리가 느려진 게 아니라 한 번에 더 긴 작업을 맡길 수 있게 됐다는 뜻이었습니다.

이 숫자는 전부 그 회사 자신의 3개월치 결과이지 저희 결과가 아닙니다. 저희에게 의미가 있었던 부분은 절대값이 아니라 그 회사가 개입 횟수를 숫자로 추적하고 있다는 사실 자체였습니다. 저희는 그 시점까지 이런 숫자를 하나도 갖고 있지 않았고, 같은 틀로 다섯 지표를 정의한 뒤 첫 측정부터 시작하기로 했습니다.

목표치는 다른 회사의 결과를 그대로 베끼지 않고 저희 상황에 맞춰 낮춰 잡았습니다. 자동 승인율은 30% 이상, 사람이 개입하는 비율은 15% 이하를 목표로 잡았습니다. 되돌릴 수 없는 작업이 벌어지는 비율은 0.8%에서 0.5%로 낮추기로 목표를 잡았고, 안전장치가 걸린 상태로 실행되는 도구 호출 비율은 80% 이상을 목표로 삼았습니다. 다만 이 목표치들은 아직 목표일 뿐이고, 실제로 재본 것은 이 글에서 다루는 스킬 재사용률 하나뿐입니다.

사이클마다 쓸 수 있는 양을 미리 정해 뒀다

측정 지표만 만든 게 아니라, 사람 개입 없이 여러 작업을 이어서 처리하는 한 사이클마다 쓸 수 있는 양도 미리 정해 뒀습니다. 이런 단계 구분은 저희가 처음 고안한 방식이 아니라, 다른 에이전트 코딩 도구들이 이미 쓰고 있는 방식을 그대로 가져왔습니다 — 검증과 재확인만 하는 가벼운 단계, 표준적인 구현을 하는 보통 단계, 여러 작업을 동시에 벌이는 확장 단계로 나누는 방식입니다.

작업을 몇 개의 하위 에이전트로 나눠 맡길지도 복잡도에 따라 정해 뒀습니다. 근거는 그 회사가 발표한 다중 에이전트 연구였습니다 — 토큰 사용량이 성능 편차의 80%를 차지하고, 여러 에이전트가 나눠 맡는 방식은 대화 하나로 처리할 때보다 토큰을 15배 더 씁니다. 그래서 단순한 사실 확인이나 파일 하나를 보는 작업은 하위 에이전트를 0개(직접 처리), 여러 각도의 비교 조사는 2개에서 4개(에이전트당 도구 호출 10회에서 15회), 복잡한 리서치나 전역 감사는 10개 이상(에이전트당 15회 이상)으로 나눴습니다.

처음 잰 숫자 — 스킬 17개 중 4개만 다시 불려 나왔다

다섯 지표 중 실제로 첫 측정까지 마친 것은 스킬 재사용률 하나였습니다. 2026년 6월 14일 처음 쟀습니다. 에이전트가 반복해서 쓰는 작업 절차를 매뉴얼처럼 만들어 두면 스킬이라 부르는데, 후보로 만든 스킬 47개 중 검증을 거쳐 정식으로 등록(승격)된 것이 17개였습니다. 승격률로 보면 27%였습니다.

진짜 궁금했던 것은 승격률이 아니라 그다음이었습니다. 정식으로 등록된 스킬 17개 중, 서로 다른 세션 2개 이상에서 실제로 다시 불려 쓰인 것은 몇 개였을까요. 세어 보니 4개였습니다. 재사용률로 환산하면 24%(4/17)였습니다.

재사용 흔적이 없는 나머지 스킬 중 4개는 다른 이유가 있었습니다. 이 4개는 에이전트가 직접 부르는 방식이 아니라 뒤에서 프로그램(스크립트)이 대신 실행하는 방식으로 쓰이고 있어서, 세션 로그에 호출 흔적이 남지 않았을 뿐 실제로는 쓰이고 있을 가능성이 있었습니다. 이 4개를 빼고 나면 정말로 쓰인 흔적이 없는 스킬은 9개였습니다.

세운 가설 — 만들어 두면 알아서 재사용될 것이다

숫자를 재기 전 이 회사가 갖고 있던 가정은 단순했습니다. 검증을 거쳐 정식으로 등록한 스킬이라면, 나중에 비슷한 작업을 만난 에이전트가 알아서 찾아 쓸 것이라는 가정이었습니다. 스킬을 만드는 일 자체가 이미 여러 세션에서 반복된 패턴을 확인한 뒤에 이뤄지기 때문에, 한 번 만들어 두면 그 반복이 계속될 거라고 본 것입니다.

다른 연구도 비슷한 주장을 내놓은 적이 있습니다. 스킬을 20개쯤 쌓아 두면 이후 작업이 40% 정도 빨라진다는 주장이었는데, 이 주장이 성립하려면 전제 조건이 하나 있습니다 — 새로 작업을 시작하기 전에 만들어 둔 스킬 목록부터 검색해야 한다는 전제입니다. 이 회사는 그 전제를 검증하지 않은 채 스킬 개수만 계속 늘려 왔습니다.

전제를 검증하지 않았던 이유는 단순합니다. 스킬을 만드는 일과 스킬을 검색하는 일이 서로 다른 절차라는 사실 자체를 미처 나눠서 보지 못했습니다. 둘을 하나의 흐름으로 뭉뚱그려 생각하고 있었기 때문에, 만드는 쪽만 잘 갖추면 검색도 자연히 따라올 거라고 넘겨짚었습니다.

가설이 틀린 지점은 어디였나?

결과를 보면 가설은 틀렸습니다. 승격 기준을 통과한 17개 중 실제로 다시 불려 쓰인 것은 4개, 24%뿐이었으니 '만들어 두면 알아서 다시 쓰인다'는 가정은 성립하지 않았습니다. 스크립트 뒤에서 쓰이고 있었을 가능성이 있는 4개를 후하게 쳐줘도 절반에 못 미쳤습니다.

더 눈에 띄는 대목은 승격률(27%)과 재사용률(24%)이 거의 같은 수준이라는 점이었습니다. 후보에서 정식으로 올라가는 관문을 통과하는 비율과, 정식으로 올라간 뒤 실제로 다시 불려 쓰이는 비율이 우연히 비슷하게 나온 것인지, 아니면 두 관문에 같은 종류의 문제가 있는 것인지는 이 측정 하나만으로는 알 수 없었습니다.

이 결과는 스킬 하나하나의 품질 문제가 아니라 절차 문제라는 신호이기도 했습니다. 승격된 스킬 17개를 하나씩 열어 보면 내용 자체는 특별히 부실하지 않았습니다. 문제는 그 스킬이 필요한 순간에 아무도 목록을 열어 보지 않았다는 데 있었습니다.

진짜 원인 — 만드는 절차와 찾는 절차가 따로 없었다

원인을 찾으려고 스킬을 만드는 절차와 스킬을 찾아 쓰는 절차를 나란히 놓고 봤습니다. 만드는 절차는 이미 갖추고 있었습니다. 반복된 패턴을 확인하고, 검증하고, 정식으로 등록하는 순서까지 전부 있었습니다. 그런데 찾는 절차, 그러니까 새 작업을 시작하기 전에 '혹시 이미 만들어 둔 스킬이 있는지' 먼저 검색하는 절차는 아예 없었습니다.

만들기만 하고 찾는 길은 안 깔아 둔 셈입니다. 정식으로 등록된 스킬 17개는 목록에는 존재했지만, 그 목록을 새 작업 시작 시점에 조회하는 단계 자체가 절차에 없었으니 아무리 좋은 스킬을 만들어 둬도 우연히 이름을 기억하고 있지 않는 한 다시 불릴 방법이 없었습니다. 재사용률 24%(4/17)는 우연히 기억해 낸 4번의 기록이었을 가능성이 컸습니다.

이 사실은 처음부터 알고 있었던 것이 아니라, 승격 절차와 검색 절차를 나란히 놓고 비교하면서 뒤늦게 드러났습니다. 승격 절차를 적어 둔 문서에는 검증 단계·명명 규칙·등록 위치까지 자세히 나와 있었지만, '언제 이 목록을 조회하는가'라는 질문에 답하는 문장은 한 줄도 없었습니다.

조치 — 검색 절차를 자율 실행 진입과 세션 마무리에 끼워 넣다

조치는 새 검색 프로그램을 만들어 두 지점에 끼워 넣는 일이었습니다. 하나는 사람 개입 없이 여러 작업을 이어서 처리하는 자율 실행 모드에 들어가는 첫 단계이고, 다른 하나는 세션을 마무리하는 절차의 한 단계입니다. 두 지점 모두 새 작업을 시작하거나 마무리하는 경계라서, 그 경계에서 '만들어 둔 스킬 목록부터 검색'하는 절차를 강제로 넣었습니다.

검색 프로그램은 세션 기록에 남는 '이 이름의 스킬을 불렀다'는 표시만 세도록 만들었습니다. 다만 이 집계 방식에는 알려진 한계가 있습니다. 뒤에서 프로그램이 대신 실행하는 스크립트 백엔드 방식의 스킬은 이 표시가 세션 기록에 남지 않아 실제보다 적게 잡힙니다. 그래서 이 숫자는 하한값이라고 못 박아 뒀고, 스크립트 백엔드로 쓰이는 스킬은 별도 표시로 구분해 뒀습니다.

지금 측정 방식은 아직 사람이 손으로 세는 첫 단계입니다. 매주 검사 기록을 하나씩 눈으로 세어 보는 방식이고, 다음 단계는 이 집계를 스크립트 하나로 자동 추출하는 일이며, 그다음 단계는 모든 턴을 기록에 남겨 화면으로 보는 일입니다. 스킬 재사용률도 지금은 첫 단계 방식 그대로, 세션 기록을 손으로 열어 이름을 세는 식으로 다시 잴 예정입니다. 자동화 단계로 넘어가기 전에 먼저 손으로 두 번은 재 보고 방식 자체가 믿을 만한지 확인하기로 했습니다.

재측정 결과는 왜 아직 나오지 않았는가?

검색 절차를 끼워 넣은 지금, 가장 궁금한 질문은 하나입니다. 다시 불리지 않았던 9개가 검색 절차가 생긴 뒤에는 다시 불려 쓰이는 쪽으로 바뀌었을까요. 정직하게 답하면 아직 모릅니다. 이 글을 쓰는 시점까지 두 번째 측정을 하지 않았습니다.

매주 이 지표들을 정리해 적을 표 양식도 미리 만들어 뒀습니다. 그 양식에는 예시로 채워 넣은 값이 있는데, 인간 개입 비율 12%, 비용 대비 성공률 항목당 38분, 실패 자력 복구율 71%(5/7), 표류 빈도 4%(12/300 도구 호출), 스킬 재사용률 24%(4/17)가 적혀 있었습니다. 이 중 실제로 잰 값은 스킬 재사용률 24%(4/17) 하나뿐이고, 나머지 네 개는 양식이 어떻게 채워질지 보여 주는 예시일 뿐 아직 한 번도 실제로 측정되지 않았습니다.

재측정을 미룬 것이 아니라 아직 그럴 시점이 아니라고 판단했습니다. 검색 절차가 실제로 작동하려면 새 세션 여러 개가 그 절차를 거쳐 지나가야 하는데, 절차를 끼워 넣은 지 얼마 되지 않아 표본이 부족했습니다. 표본이 부족한 상태에서 재측정해 숫자가 조금 올랐다고 발표하면, 그 상승이 절차 덕분인지 우연인지 구분할 수 없습니다.

그래서 다음 측정 시점은 진짜 미사용으로 분류됐던 9개 스킬이 검색 절차를 거친 뒤 재사용으로 전환되는지를 확인하는 시점으로 정해 뒀습니다. 이 9개가 이번 측정의 재측정 대상이고, 아직 결과가 없다는 사실 자체를 감추지 않고 그대로 남겨 둡니다. 성급하게 좋아 보이는 숫자를 만들어 내는 쪽보다, 없는 결과를 없다고 말하는 쪽을 택했습니다.

남는 한계 — 숫자 하나에 낚이지 않는 법

숫자로 재기 시작하면 새로운 위험이 따라옵니다. 이번 지표를 설계하면서 미리 적어 둔 함정이 네 가지 있습니다.

첫째, 목표를 절대값으로 잡는 함정입니다. 재사용률 100%를 목표로 걸면, 오래된 스킬을 억지로 다시 부르는 일이 생길 수 있습니다. 그래서 절대값 목표 대신 추세만 추적하기로 했습니다.

둘째, 다른 인공지능 모델에게 판정을 맡기는 함정입니다. 도메인 전문가끼리도 판정 합의율이 64%에서 68%에 그친다는 연구 결과가 있어서, 판정은 사람이 직접 내리기로 했습니다.

셋째, 공개된 성능 평가표를 그대로 따라가는 함정입니다. 널리 쓰이던 한 성능 평가표에서는 같은 모델의 점수가 80.9%에서 45.9%까지 떨어진 사례가 있었습니다. 그래서 자체적으로 쌓은 사례만 기준으로 삼기로 했습니다.

넷째, 실패했을 때 외부 신호 없이 '다시 해봐'만 반복하는 함정입니다. 스스로 정답을 고치는 능력이 뛰어난 모델일수록 외부 신호 없는 재시도에서 정확도가 16.7%까지 떨어진다는 연구도 있었고, 사용자가 '이거 맞아?'라고 되묻기만 해도 답을 58.19%의 비율로 뒤집는다는 결과도 있었습니다. 그래서 재시도는 항상 로그나 기록 같은 외부 신호를 붙인 뒤에만 하기로 했습니다.

이 네 가지는 전부 스킬 재사용률 지표를 설계하며 미리 적어 둔 주의사항이고, 아직 하나도 실제로 겪은 사고는 아닙니다. 다만 재측정을 시작하기 전에 이 네 가지부터 다시 읽기로 해 뒀습니다.

네 가지 함정을 미리 적어 둔 이유는 단순합니다. 첫 측정에서 숫자가 낮게 나왔다고 해서 그 숫자를 억지로 끌어올리는 방향으로만 움직이면, 지표를 만든 원래 목적 — 정성적인 인상 대신 실제 상태를 아는 일 — 을 잃어버리기 쉽기 때문입니다. 24%라는 숫자 자체보다, 그 숫자가 왜 그렇게 나왔는지를 나중에도 설명할 수 있는 상태를 유지하는 쪽이 더 중요하다고 봤습니다.

에이전트가 실제로 얼마나 자율적으로 일하는지 재는 다른 계측 기록은 Claude Code 자율 실행이 왜 한 턴 만에 멈추는지 계측한 글에도 남겨 두었습니다. 비슷한 방식으로 업무 자동화의 효과를 정직하게 재고 싶다면 상담에서 이야기해 볼 수 있습니다.