관련 있어 보이는 스킬이 항상 도움이 되지는 않는다

오늘 살펴볼 연구는 An Empirical Study of Agent Skills' Downstream Utility이며, arXiv에 2610.08875번으로 공개된 실증 논문입니다. 원문 링크는 제목 아래에 걸려 있습니다. 이 연구가 던지는 주장은 한 문장으로 정리됩니다. 관련 있어 보이는 스킬이 실제 과제 수행도를 항상 끌어올리는 것은 아니며, 도움이 되는지 여부는 모델과 하네스 조합에 따라 달라진다는 것입니다.

안녕하세요, 패트릭입니다. 저는 한동안 에이전트에게 일을 시키면서 묘한 장면을 자주 봤습니다. 분명히 도움이 되라고 넣어준 설명서가 있는데, 에이전트는 그 설명서를 읽느라 오히려 일을 더디게 하는 것이죠. 마치 요리를 도와주려고 옆에서 레시피를 계속 읽어주는 사람이, 정작 손은 느리게 만드는 경우와 비슷합니다. 이번 연구는 그 답답함을 숫자로 확인해준 셈이라서, 저는 읽으면서 여러 번 고개를 끄덕였습니다.

왜 스킬이 있는데도 에이전트는 헤맬까

에이전트에게 일을 맡겨본 분이라면 비슷한 경험을 해보셨을 겁니다. 분명히 관련 자료를 잔뜩 쥐여줬는데, 결과물은 기대만큼 나아지지 않는 경우 말이죠. 그래서 저는 이 논문을 처음 펼쳤을 때 제목부터 눈에 들어왔습니다. 스킬이라는 말이 요즘은 너무 쉽게 쓰이기 때문입니다. 절차를 적어둔 문서도 스킬이라 부르고, 도구 모음도 스킬이라 부르고, 예시 답안 몇 개도 스킬이라 부릅니다. 그런데 정작 현장에서 궁금한 것은 하나입니다. 그걸 넣었을 때 일이 실제로 더 잘 풀리느냐는 것이죠.

이 연구는 그 질문을 정면으로 붙잡습니다. 스킬을 넣으면 에이전트가 더 유능해지는 것처럼 말하는 분위기가 있지만, 연구진은 그 말을 그대로 믿지 않습니다. 관련성이 있다는 것과 수행도가 오른다는 것은 다른 이야기니까요. 도서관에서 관련 책을 열 권 빌려왔다고 해서 시험 점수가 오르는 것은 아니잖아요. 어떤 책은 시험 범위와 맞고, 어떤 책은 읽기만 해도 시간이 부족해집니다. 에이전트의 스킬도 같다고 저는 봅니다.

여기서 제가 흥미롭게 본 부분은 연구의 태도입니다. 스킬을 잘 만드는 법을 먼저 설교하지 않고, 스킬이 실제로 과제 성공률을 얼마나 움직이는지부터 재봅니다. 에이전트 일을 오래 해보면 이런 순서가 얼마나 중요한지 알게 됩니다. 좋은 도구를 고르는 일보다 먼저 할 일은, 도구가 있을 때와 없을 때 결과가 어떻게 달라지는지 차분히 비교하는 것이니까요.

관련 있어 보이는 것과 도움이 되는 것은 다릅니다

우리가 흔히 저지르는 착각이 하나 있습니다. 검색 결과가 맨 위에 보여준 문서라면 도움도 가장 클 거라고 믿는 것이죠. 그런데 검색 순위는 대개 주제의 겹침을 재지, 일이 풀리는지를 재지 않습니다. 제목에 같은 단어가 많이 들어 있으면 위로 올라가지만, 그 문서가 지금 과제에서 필요한 동작을 실제로 받쳐주는지는 다른 문제입니다.

연구진은 이 지점을 downstream utility라는 말로 부릅니다. 말이 조금 어렵게 들리지만, 뜻은 단순합니다. 같은 과제, 같은 모델, 같은 하네스 조건에서 스킬이 없을 때와 있을 때의 성공률 차이를 재는 것이죠. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 관련성이라는 느낌을 걷어내고, 성공률이라는 결과로만 묻기 때문입니다.

예를 들어 새벽에 장애가 나서 로그를 뒤져야 하는 상황을 떠올려보죠. 옆에 있는 동료가 관련 있어 보이는 위키 문서 다섯 개를 던져줍니다. 제목은 모두 그럴듯합니다. 그런데 막상 열어보면 필요한 명령어는 없고 배경 설명만 길게 이어집니다. 읽는 데 20분이 걸리고, 정작 복구는 늦어집니다. 이때 그 문서들은 관련성은 높았지만 downstream utility는 낮았던 셈입니다. 에이전트에게 스킬을 주는 일도 구조는 같습니다. 관련 있어 보인다는 말만으로는 부족하고, 과제 성공률을 움직였는지를 물어야 합니다.

그렇다면 도움이 된다는 건 어떻게 쟀을까

그렇다면 연구진은 도움이 된다는 것을 어떻게 쟀을까요. 답은 비교적 담백합니다. SkillsBench라는 과제 묶음 87개를 놓고, 스킬이 없는 경우의 성공률을 기준선으로 삼은 뒤, 같은 과제와 같은 모델 및 하네스 조합에서 스킬을 줬을 때 성공률이 얼마나 달라지는지를 잽니다. 조건을 고정하고 스킬 유무만 바꾸는 방식이라서, 숫자 하나하나가 해석하기는 까다로워도 방향은 분명합니다.

저는 여기서 멈칫했습니다. 87개라는 숫자가 크다고도 보이고 작다고도 보이기 때문입니다. 에이전트가 실제 세계에서 만나는 일의 가짓수를 생각하면 87개는 일부에 불과합니다. 하지만 같은 조건에서 스킬 유무를 바꿔가며 반복 측정했다는 점에서는 꽤 단단한 설계입니다. 한 번의 인상적인 데모보다, 조건을 고정한 반복 비교가 현장에서는 훨씬 믿을 만하니까요.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 성공률이라는 말은 무엇을 성공이라고 불렀느냐에 따라 달라지지 않느냐는 것입니다. 과제가 요구한 최종 결과물이 나왔는지, 중간 절차를 예쁘게 따랐는지를 구분해야 합니다. 이 연구가 본 것은 최종 과제 성공률의 차이입니다. 절차를 잘 따랐는지가 아니라 일이 풀렸는지를 묻는 것이죠. 저는 이 선택이 마음에 들었습니다. 현장에서 중요한 것은 과정의 품평이 아니라 결과의 변화이기 때문입니다.

같은 설명서가 어떤 팀에는 약이고 어떤 팀에는 짐이 된다

이제 숫자로 들어가 보죠. 이 연구에서 저를 가장 오래 붙잡아둔 대목은 36.78%라는 수치입니다. 전체 과제 중에서 같은 스킬이 어떤 모델과 하네스 조합에서는 성공률을 올리지만, 다른 조합에서는 오히려 떨어뜨린 경우가 그 정도 비율로 나왔다는 것입니다. 세 과제 중 하나를 훌쩍 넘는 비율이죠.

이 차이는 생각보다 중요합니다. 스킬 자체가 좋다거나 나쁘다는 식으로는 설명되지 않기 때문입니다. 같은 설명서를 놓고 어떤 팀은 일이 빨라지고 어떤 팀은 느려진다면, 문제는 설명서만의 문제가 아닙니다. 읽는 쪽의 실력, 일하는 방식, 도구를 다루는 순서가 함께 얽혀 있습니다. 등산 지도를 예로 들어볼까요. 지도가 정확해도, 지도 읽기에 익숙한 팀과 그렇지 않은 팀의 결과는 다릅니다. 게다가 어떤 팀은 지도를 보느라 발밑을 놓치고 넘어지기도 합니다.

모델과 하네스의 조합이 바로 그런 변수입니다. 모델마다 지시를 따르는 방식이 다르고, 하네스마다 도구를 호출하고 파일을 읽는 흐름이 다릅니다. 그래서 어떤 조합에서는 스킬의 절차가 길잡이가 되지만, 다른 조합에서는 발목을 잡습니다. 저는 이 대목을 읽으면서 예전에 겪은 일을 떠올렸습니다. 같은 플레이북을 두 팀에 나눠줬는데, 한 팀은 장애 복구 시간이 줄고 다른 팀은 오히려 회의만 늘어난 적이 있습니다. 플레이북이 아니라 플레이북과 팀의 궁합이 문제였던 것이죠. 스킬도 마찬가지라고 봅니다.

친절한 절차가 언제 짐이 될까

그렇다면 절차는 왜 짐이 될까요. 연구진이 실행 궤적을 들여다본 결과는 꽤 직관적입니다. 스킬이 권장한 절차가 도움이 되는 안내가 아니라 실행 부담으로 바뀌는 경우가 있다는 것입니다. 단계가 많아지고, 확인하라는 항목이 늘고, 읽어야 할 파일이 쌓이면서 에이전트는 정작 해야 할 일을 미루게 됩니다.

밤늦게 서버를 만지는 장면을 상상해보시죠. 매뉴얼에는 일곱 단계가 적혀 있습니다. 로그를 모으고, 설정을 대조하고, 임시 파일을 정리하고, 다시 검증하라는 것이죠. 그런데 지금 장애는 두 번째 단계에서 이미 원인이 보입니다. 사람이라면 여기서 바로 조치하고 넘어가겠죠. 하지만 절차를 곧이곧대로 따르도록 배운 에이전트는 남은 다섯 단계를 마저 돌면서 시간을 씁니다. 친절했던 절차가 그 순간에는 발목을 잡는 것입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 절차가 길다는 이유만으로 나쁘다고 말할 수는 없기 때문입니다. 어떤 과제에서는 꼼꼼한 절차가 실수를 막아줍니다. 특히 되돌리기 어려운 삭제를 하거나 외부에 요청을 보내는 일에서는 한 번 더 확인하는 단계가 소중합니다. 문제는 절차의 길이가 아니라 과제와의 맞물림입니다. 지금 과제에서 꼭 필요한 확인인지, 아니면 관성으로 들어간 확인인지를 가려야 합니다. 저는 그래서 절차의 분량보다 분기점이 중요하다고 봅니다. 언제 건너뛰고 언제 멈출지를 알려주지 않는 절차는, 길든 짧든 짐이 되기 쉽습니다.

마켓에 쌓인 수많은 스킬 중에서 무엇을 고를까

스킬 이야기가 나오면 곧바로 따라오는 질문이 있습니다. 좋은 스킬이 있다면 어디에서 고르느냐는 것이죠. 연구진은 비교를 위해 37,596개로 정리된 스킬 모음을 가져와 마켓플레이스 후보를 찾는 실험을 합니다. 숫자를 일부러 짚는 이유는 규모감을 주기 위해서입니다. 고를 수 있는 것이 몇 개가 아니라 수만 개라는 것이죠.

규모가 커지면 선택의 성격이 달라집니다. 몇 개 중에서는 직접 읽고 고르면 되지만, 수만 개 중에서는 검색이 먼저입니다. 이때 검색이 무엇을 기준으로 올려주는지가 전체 결과를 좌우합니다. 관련 있어 보이는 것을 올리는 검색과, 실제로 일을 풀어줄 것을 올리는 검색은 다릅니다. 마치 앱 장터에서 별점이 높은 앱과 내 일에 맞는 앱이 다른 것과 비슷합니다.

저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 스킬 고르기도 같다고 생각합니다. 후보가 몇만 개라면 제목의 유사도만 보고 고를 수는 없습니다. 어떤 동작을 지원하고, 어떤 실패를 막아주며, 어떤 조건에서 짐이 되는지를 함께 봐야 합니다. 그렇지 않으면 장터는 넓어지는데 정작 손에 잡히는 도구는 없는 상태가 됩니다.

관련도 순서가 놓치는 것이 있습니다

연구가 짚은 다음 대목은 검색의 맹점입니다. 관련도 순으로 매긴 후보 목록이, 평가 대상 안에서 더 유용한 후보를 놓치는 경우가 있다는 것입니다. 다시 말해 맨 위에 있는 것이 실제로 가장 도움이 되는 것은 아닐 수 있다는 뜻입니다.

표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 검색이 놓치는 이유는 검색이 과제의 속살을 보지 못하기 때문입니다. 과제를 푸는 데 필요한 동작이 무엇인지, 어떤 파일을 만져야 하고 어떤 도구를 불러야 하는지를 검색 순위는 잘 반영하지 못합니다. 그래서 제목은 비슷하지만 막상 열어보면 필요한 동작이 없는 문서가 위로 올라가고, 제목은 투박하지만 필요한 동작을 정확히 받쳐주는 문서는 아래에 가라앉습니다.

저는 이 대목을 읽으면서 냉장고에 붙은 메모를 떠올렸습니다. 급할 때 필요한 것은 화려한 요리책이 아니라 지금 남은 재료로 만들 수 있는 한 끼의 순서입니다. 재료가 달걀과 밥뿐인데 프랑스 코스 요리책을 준다고 도움이 되지는 않죠. 에이전트에게도 마찬가지입니다. 과제에서 요구하는 동작을 지원하지 않는 스킬은, 아무리 주제와 가까워 보여도 현장에서는 힘을 쓰지 못합니다. 그래서 순위를 매기는 기준 자체를 바꿔야 한다는 문제의식이 나옵니다.

필요한 동작을 받쳐주는지부터 물어보면 달라질까

여기서 연구진은 작은 방향 전환을 시도합니다. 관련도 순서 대신, 과제에 필요한 동작을 얼마나 받쳐주는지를 기준으로 다시 정렬하는 것이죠. 그러자 세 가지 조합에서 첫 번째로 고른 후보의 성공률이 4.35에서 5.80 포인트만큼 올라갔다는 결과가 나옵니다.

숫자를 그대로 믿기 전에 조건을 봐야 합니다. 몇 포인트의 차이는 작아 보일 수도 있습니다. 하지만 첫 번째 선택의 성공률이 그만큼 움직였다는 것은 실무적으로 꽤 큽니다. 에이전트가 매번 여러 후보를 뒤적일 수 없기 때문입니다. 시간과 비용이 걸리니까요. 첫 번째로 집어 든 것이 바로 쓸 만한 것일 확률이 올라가면, 전체 파이프라인의 낭비가 줄어듭니다. 택배 상자를 열자마자 필요한 공구가 나오는 것과, 상자를 세 개째 뒤져서야 나오는 것의 차이라고 할까요.

제가 앞으로 보고 싶은 것은 이 재배열이 언제 더 크게 작동하는지입니다. 모든 과제에서 균등하게 좋아지는 것인지, 아니면 특정 종류의 과제에서만 효과가 집중되는 것인지가 궁금합니다. 필요한 동작이라는 것도 과제에 따라 선명도가 다르니까요. 파일 편집처럼 동작이 분명한 과제에서는 재배열이 크게 먹히겠지만, 답의 형태가 모호한 과제에서는 기준 자체를 세우기 어려울 수 있습니다. 그럼에도 방향은 분명해 보입니다. 무엇을 닮았는지가 아니라 무엇을 할 수 있게 해주는지를 먼저 묻는 것이죠.

스킬을 잘 쓰는 설명서는 어떻게 생겼을까

스킬을 고르는 일만큼 중요한 것이 스킬을 쓰는 일입니다. 연구진은 여기서 17가지 작성 관행을 정리합니다. 실행 가능한 절차와 복구 방법, 과제 요구사항의 보존, 최종 결과물에 대한 점검을 서로 엮는 관행들이라고 합니다.

저는 숫자를 세는 것보다 묶음이 흥미로웠습니다. 실행, 복구, 보존, 점검이라는 네 갈래가 서로를 물고 있기 때문입니다. 절차를 적어두는 것만으로는 부족하고, 틀렸을 때 돌아오는 길을 함께 적어야 합니다. 요구사항을 처음에 밝히는 것만으로는 부족하고, 중간에 흐려지지 않게 붙잡아두는 장치가 필요합니다. 마지막에는 결과물이 요구사항을 만족했는지 직접 확인하는 눈이 있어야 합니다.

이사를 앞둔 집을 떠올려보죠. 짐 목록만 적어둔 종이는 반쪽짜리입니다. 깨지기 쉬운 것은 어떻게 포장하고, 분실되면 어디에서 찾을지, 도착한 뒤에는 어떤 방에 무엇을 둘지가 함께 적혀 있어야 합니다. 그리고 마지막에는 빠진 짐이 없는지 현관에서 한 번 더 세어봐야 합니다. 스킬 문서도 구조는 같습니다. 하라는 일만 나열한 문서는 약하고, 틀렸을 때의 대처와 마지막 점검이 함께 있을 때 비로소 쓸 만해집니다.

다만 여기서도 과장하지 않고 싶습니다. 17가지 관행이 모든 스킬에 같은 무게로 적용되는 것은 아닐 겁니다. 과제 성격에 따라 어떤 관행은 필수이고 어떤 관행은 사치입니다. 짧은 단일 파일 수정에 거창한 복구 계획을 붙이면 오히려 짐이 됩니다. 반대로 여러 파일을 건드리는 작업에서 점검을 빼면 위험합니다. 그래서 저는 이 목록을 규칙집이 아니라 점검표로 읽고 싶습니다. 쓸 때마다 전부 지킬 것이 아니라, 지금 과제에서 빠진 고리가 어디인지를 찾는 용도로 말이죠.

순서를 정해주는 것과 의존 관계를 그려주는 것의 차이

스킬이 여러 개 주어질 때의 이야기로 넘어가보죠. 연구진은 스킬을 쓰는 순서를 그대로 따르는 방식과, 단계 계획이나 의존 관계 그래프를 함께 주는 방식을 비교합니다. 결과는 단계 계획과 의존 관계 그래프가 단순한 사용 순서보다 낫다는 쪽으로 나옵니다. 특히 의존 관계 그래프의 추가 이득은 스킬이 다섯 개나 여섯 개 주어진 과제들에 모여 있었다고 합니다.

왜 그럴까요. 스킬이 두세 개일 때는 순서만 정해줘도 충분합니다. 먼저 이것, 다음에 저것이면 됩니다. 하지만 스킬이 다섯 개, 여섯 개가 되면 일이 달라집니다. 어떤 일은 먼저 끝나야 다음 일이 시작되고, 어떤 일은 서로 상관없이 병렬로 해도 됩니다. 이때 일렬 순서만 주면 에이전트는 불필요하게 기다리거나, 반대로 준비되지 않은 일을 먼저 건드립니다.

주방을 떠올려보면 분명해집니다. 요리 두 개를 만들 때 순서는 간단합니다. 하지만 다섯 가지 요리를 동시에 만들 때는 순서가 아니라 의존 관계가 필요합니다. 밥은 미리 안쳐야 하고, 국은 마지막에 간을 봐야 하며, 반찬 중 일부는 서로 재료를 나눠 씁니다. 일렬 레시피만 들고 주방에 들어가면 동선이 꼬입니다. 무엇이 무엇을 기다리는지를 그린 그림이 있어야 손이 겹치지 않습니다. 스킬 다섯 개, 여섯 개가 주어진 과제가 바로 그런 주방이라고 저는 봅니다.

그렇다면 의존 관계 그래프는 언제나 정답일까요. 저는 여기서는 조금 다르게 봅니다. 그래프를 그리는 데 드는 비용도 만만치 않기 때문입니다. 과제가 단순한데 매번 그래프를 그리면 배보다 배꼽이 커집니다. 연구 결과가 스킬이 많을 때 이득이 모였다고 말한 대목이 그래서 설득력이 있습니다. 복잡도가 일정 수준을 넘어설 때만 그래프가 값을 한다는 것이죠. 작은 일에는 가벼운 순서를, 얽힌 일에는 의존 관계를 쓰는 식의 구분이 현장에서는 더 자연스러워 보입니다.

그래서 앞으로 스킬을 어떻게 고르고 쓸까요

지금까지의 이야기를 한 줄로 모아보면 이렇습니다. 스킬은 넣는다고 저절로 좋아지는 것이 아니라, 고르는 기준과 쓰는 방식이 함께 맞아야 좋아진다는 것입니다. 관련도만 보고 고르면 놓치는 것이 생기고, 절차를 그대로 믿으면 짐이 되며, 여러 개를 쓸 때는 얽힘을 그려줘야 합니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 그렇다면 당장 무엇을 바꿀 수 있을까요. 저는 세 가지를 꼽고 싶습니다. 먼저 스킬을 고를 때는 제목의 유사도보다 필요한 동작의 지원 여부를 먼저 봅니다. 어떤 파일을 만지고 어떤 도구를 쓰는지, 그 동작을 스킬이 직접 받쳐주는지를 묻는 것이죠. 다음으로 스킬을 쓸 때는 절차를 그대로 돌리기 전에 건너뛰어도 되는 지점을 표시합니다. 장애 대응처럼 시간이 촉박한 일에서는 이 표시 하나가 체감 속도를 바꿉니다. 마지막으로 스킬이 많아질 때만 의존 관계를 그립니다. 다섯 개, 여섯 개가 얽힐 때 그래프가 값을 한다는 이번 결과를 그대로 쓰면 됩니다.

물론 남는 질문도 있습니다. 87개 과제 밖에서는 이 경향이 어떻게 이어질까요. 모델이 바뀌고 하네스가 바뀌면 36.78%라는 비율도 달라지겠죠. 17가지 관행 중에서 어떤 것이 가장 먼저 효과를 내는지도 따로 확인해보고 싶습니다. 그리고 재배열의 이득이 세 가지 조합 너머에서도 이어지는지도 궁금합니다. 연구 하나가 모든 답을 주지는 않습니다. 다만 묻는 법을 바꿔줬다는 점에서는 분명히 남는 것이 있습니다. 스킬이 있느냐가 아니라 스킬이 일을 풀어주느냐를 묻는 법 말이죠.

그렇다면 사람의 역할은 무엇일까요. 저는 스킬을 모으는 사람보다 스킬을 가려내는 사람이 더 중요해지는 쪽으로 기울어갑니다. 수만 개 중에서 관련 있어 보이는 것을 긁어모으는 일은 검색이 대신할 수 있습니다. 하지만 지금 과제에서 꼭 필요한 동작이 무엇인지 정의하고, 절차 중에서 짐이 되는 부분을 덜어내며, 마지막 결과물을 점검하는 일은 여전히 사람의 판단에 가깝습니다. 좋은 스킬 생태계란 결국 좋은 질문에서 시작되는 것 아닐까요. 이 스킬이 일을 끝까지 풀어주는지, 그 한 가지를 묻는 것부터 말이죠.