서브에이전트와 에이전트 스킬, 오래 일하는 지식을 실행하는 두 가지 방법

오늘 다룰 글은 arXiv에 공개된 연구 Subagents vs Agent Skills: Executing Reusable Knowledge for Long-Horizon Agentic Tasks이며, 식별자는 arXiv 2609.09233입니다. 이 연구가 내세우는 주장은 한 문장으로 정리하면, 스킬 패키지가 분명한 입출력 계약과 그 계약을 지키는 절차 지식을 갖출 때 서브에이전트 실행이 컨텍스트 내 스킬 실행보다 오래 버틴다는 것입니다. 원문은 제목 아래에 걸어둔 링크에서 확인할 수 있습니다.

안녕하세요, 패트릭입니다.

여러 사람이 함께 일하다 보면, 매뉴얼을 옆에 펼쳐두는 것만으로는 일이 잘 안 풀릴 때가 있습니다. 그렇다면 매뉴얼을 통째로 외우는 대신, 그 일을 잘 아는 동료에게 일부를 통째로 맡기면 어떻게 될까요. 제가 이 논문에서 가장 흥미롭게 본 부분은 바로 이 선택지를 정면으로 비교했다는 점인데, 같은 재사용 가능한 지식을 두고도 꺼내 읽는 방식이 아니라 실행하는 방식이 결과를 가른다는 발상이었기 때문입니다.

요리책을 통째로 외우면 주방이 빨라질까

저는 처음에 이 주제를 조금 가볍게 봤습니다. 스킬이 있으면 에이전트가 잘하겠지 싶었기 때문입니다. 그런데 곰곰이 따져보면 재사용 가능한 지식이라는 말은 생각보다 모호합니다. 문서가 있다는 사실과 그 문서를 오래 쓰는 일 사이에는 거리가 있기 때문입니다. 짧은 작업에서는 매뉴얼을 한 번 읽고 따라 하면 충분하지만, 작업이 길어지면 읽어야 할 것도 쌓이고 기억해야 할 중간 결과도 쌓이면서 처음에는 또렷하던 판단이 점점 흐려지죠.

그렇다면 무엇이 먼저 무너질까요. 제 경험으로는 추론의 순서가 먼저 흔들립니다. 무엇을 확인했고 무엇을 아직 안 했으며, 지금 답이 어느 단계에 해당하는지가 뒤섞이기 시작하기 때문입니다. 이런 상태에서는 지식이 많아도 도움이 되지 않고, 오히려 읽을 것이 늘수록 판단은 더 무거워집니다. 이 논문이 파고든 지점이 바로 여기인데, 지식을 모으는 문제가 아니라 긴 시간 동안 지식을 실행하는 문제로 질문을 옮긴 셈입니다.

현장에서 일하는 분이라면 감각적으로 아실 겁니다. 오전 9시에 시작한 자동화 작업이 오후 3시까지 이어질 때, 중간에 쌓인 로그와 도구 출력과 메모가 에이전트의 머릿속을 가득 채우면 그 뒤에 들어온 분명한 지시조차 놓치기 쉬워지기 때문입니다. 사람은 이럴 때 메모를 치우거나 일을 나누는데, 에이전트에게도 비슷한 선택지가 필요하지 않을까요.

오래 일할수록 왜 에이전트는 헤맬까

긴 작업을 어렵게 만드는 것은 모델이 게을러서가 아닙니다. 컨텍스트 안에 정보가 계속 쌓이면서 추론 품질이 서서히 떨어지기 때문입니다. 이 논문은 그 과정을 정직하게 짚는데, 스킬 설명을 앞에 붙여놓고 일을 시키면 앞부분의 지시는 분명해도 뒤로 갈수록 그 지시와 현재 상태 사이의 연결이 느슨해집니다. 처음에는 지시를 따르던 에이전트가 어느 순간부터는 지시를 참조하기보다 눈앞의 출력에 반응하기 시작하기 때문입니다.

이 차이는 생각보다 중요합니다. 짧은 질의응답에서는 컨텍스트가 깨끗하니까 지시를 한 번만 읽어도 충분합니다. 하지만 여러 도구를 쓰고 파일을 고치고 중간 결과를 검증해야 하는 작업에서는, 에이전트가 이미 본 것과 지금 해야 할 것을 계속 대조해야 합니다. 그러다 보면 스킬에 적힌 절차가 배경처럼 흐려지고, 그 자리에 직전 도구 출력이 들어서는데, 결국 에이전트는 지식을 잊은 것이 아니라 지식에 닿기 어려워진 것입니다.

생각해보면 사람도 비슷하게 배웁니다. 일종의 작업 기억이 꽉 차면 책상 위에 붙여둔 체크리스트가 눈에 들어오지 않기 때문입니다. 체크리스트가 나빠진 게 아니라 그것을 볼 여유가 사라진 것인데, 저는 이 대목을 읽으면서 긴 에이전트 작업을 평가할 때 성공률만 보지 말고 컨텍스트가 얼마나 지저분해졌는지도 함께 봐야겠다고 느꼈습니다. 같은 실패라도 이유가 전혀 다를 수 있으니까요.

스킬 패키지라는 상자 안에는 무엇이 들었나

이 연구에서 말하는 에이전트 스킬은 한 장짜리 프롬프트가 아닙니다. 지시와 스크립트와 관련 자료를 함께 묶은 스킬 패키지, 즉 여러 파일로 이루어진 묶음에 가깝습니다. 어떤 일을 할 때 읽을 설명이 있고 그대로 돌릴 수 있는 코드나 도구가 있으며, 참고할 예시나 자원이 함께 들어 있는 상자라고 보면 됩니다. 그래서 스킬을 만든다는 것은 문장 하나를 잘 쓰는 일이 아니라 작은 작업 환경을 포장하는 일에 가깝죠.

여기서 재미있는 질문이 생깁니다. 상자 안에 무엇이 들어 있느냐만큼, 그 상자를 어떻게 여느냐도 중요하지 않을까요. 같은 상자라도 뚜껑을 열어 책상 위에 전부 펼쳐놓고 일할 수도 있고, 상자째로 다른 사람에게 건네며 결과만 받아볼 수도 있습니다. 이 논문은 바로 그 여는 방식을 비교하는데, 하나는 스킬 설명을 에이전트의 컨텍스트에 직접 올리고 따르게 하는 방식이고 다른 하나는 그 일을 맡을 서브에이전트를 따로 띄워 부분 작업을 풀게 하는 방식입니다.

저는 이 구분이 마음에 들었습니다. 그동안 스킬 이야기는 대체로 내용의 품질로 수렴했기 때문입니다. 더 좋은 설명, 더 자세한 예시, 더 친절한 문서가 해답처럼 다뤄졌는데, 이 연구는 시선을 살짝 옮겨서 내용이 같아도 실행 구조가 다르면 체감이 달라질 수 있다고 말합니다. 상자의 내용물 목록만 보지 말고, 상자가 일하는 자리로 들어가는 경로를 보자는 제안으로 읽혔습니다.

같은 지식을 두 가지 방식으로 꺼내 쓰는 법

관행적인 스킬 실행은 직관적입니다. 스킬 설명을 메인 에이전트의 컨텍스트에 넣고 에이전트가 그것을 읽고 따르도록 기대하기 때문입니다. 손에 매뉴얼을 들고 주방에서 요리하는 모습과 비슷해서, 재료도 보이고 레시피도 보이니 처음에는 든든합니다. 작업이 짧고 변수가 적다면 이 방식이 가장 빠른데, 따로 사람을 부를 필요도 없고 설명할 시간도 들지 않기 때문입니다.

반면 서브에이전트 실행은 사람을 하나 더 부르는 선택에 가깝습니다. 스킬 설명을 메인 컨텍스트에 전부 올리는 대신, 부분 작업을 위한 새 컨텍스트를 띄우고 그 안에서 스킬을 풀게 하기 때문입니다. 메인 에이전트는 무엇을 맡겼고 무엇을 돌려받을지만 알면 되는데, 마치 주방장이 소스 담당에게 이 레시피대로 소스만 만들어줘, 완성되면 맛과 양만 알려줘라고 맡기는 것과 비슷합니다. 주방장의 머릿속은 가벼워지고, 소스 담당의 눈앞에는 소스 일만 남기 때문입니다.

문제는 그다음입니다. 두 방식 모두 그럴듯한데, 언제 어느 쪽이 오래 버틸까요. 이 논문이 던지는 답은 조건부인데, 스킬이 분명한 입출력 계약을 드러내고 그 계약을 실제로 지키는 절차 지식을 담고 있을 때 서브에이전트 쪽이 더 잘 버틴다는 것입니다. 다시 말해 맡기는 일이 분명하고 맡긴 일을 푸는 순서가 상자 안에 정리되어 있을 때 분업이 통한다는 이야기인데, 저는 이 조건부가 오히려 신뢰가 갔습니다. 무조건 분업이 낫다는 식의 단정이 아니었기 때문입니다.

컨텍스트에 얹으면 편한데 왜 무너질까

직접 컨텍스트에 올리는 방식의 매력은 분명합니다. 설명할 필요가 없으니 시작이 빠르기 때문입니다. 그런데 작업이 길어지면 이 편함이 빚이 되어 돌아옵니다. 컨텍스트 안에 스킬 설명, 대화 기록, 도구 출력, 중간 파일 내용이 함께 쌓이면, 에이전트는 무엇을 근거로 판단해야 할지 점점 헷갈리기 때문입니다. 스킬은 앞에 있고 지금 일은 뒤에 있으니 둘 사이의 거리가 멀어지는 셈입니다.

이런 상황에서는 이상한 실패가 생깁니다. 스킬에 분명히 적힌 순서를 건너뛰거나 이미 확인한 조건을 다시 확인하거나, 반대로 확인하지 않은 것을 확인했다고 착각하는 식입니다. 지식이 없어서 생긴 실패가 아니라 지식이 묻혀서 생긴 실패인데, 책상 위에 서류가 산처럼 쌓이면 가장 위에 있는 서류부터 손이 가는 것과 비슷합니다. 중요도와 무관하게 최근 것이 이기는 현상이죠.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 그렇다면 컨텍스트를 비우거나 요약하면 되지 않을까. 물론 도움이 됩니다. 하지만 요약은 또 다른 판단이 필요하고, 그 판단이 틀리면 스킬의 전제가 통째로 사라질 수 있습니다. (요약을 잘한다는 것은 무엇을 버려도 되는지를 안다는 뜻인데, 긴 작업에서는 그 판단 자체가 어렵습니다.) 그래서 이 방식은 짧은 일에는 가볍고 빠르지만 긴 일에서는 구조적으로 불리해지며, 편함과 지속 가능함이 같은 방향이 아닌 셈입니다.

새 창을 열고 일을 맡기면 무엇이 달라질까

서브에이전트 실행은 발상을 뒤집습니다. 메인 컨텍스트를 깨끗하게 유지하려고 애쓰는 대신, 더러운 일을 할 새 방을 하나 내주기 때문입니다. 부분 작업마다 새 컨텍스트를 띄우면 그 안에서는 스킬 설명과 지금 푸는 문제 사이의 거리가 가깝게 유지됩니다. 메인 에이전트는 전체 목표와 중간 결과의 요점만 들고 있고, 세부 절차는 서브에이전트가 자기 방에서 처리하기 때문입니다.

이 분리가 주는 효과는 심리적으로도 이해하기 쉽습니다. 방이 바뀌면 눈앞의 일이 단순해지기 때문입니다. 메인 에이전트는 이 부분 작업의 입력은 무엇이고 출력은 무엇이어야 하는가에 집중하면 되고, 서브에이전트는 주어진 입력으로 계약된 출력을 어떻게 만들 것인가에만 집중합니다. 서로의 머릿속에 불필요한 중간 과정이 들어가지 않으니 긴 작업에서도 판단의 축이 흔들리지 않는데, 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 성공률이 아니라 무엇이 성공을 가능하게 했는지를 봐야 다음 설계로 이어지기 때문입니다.

다만 이 방식에도 조건이 있습니다. 맡기는 쪽과 맡는 쪽 사이에 무엇을 주고받을지가 분명해야 하기 때문입니다. 입력이 모호하면 서브에이전트는 깨끗한 방에서도 헤매고, 출력의 기준이 없으면 메인 에이전트는 돌아온 결과를 믿기 어렵습니다. 그래서 새 창을 연다는 것은 단순히 컨텍스트를 나누는 기술이 아니라 일을 나누는 설계이며, 어디서 자르고 무엇을 넘기고 무엇을 검사할지를 미리 정해야 합니다. 그 약속이 서 있으면 분리는 힘이 되고, 약속이 없으면 분리는 흩어짐이 됩니다.

계약이 분명할 때만 위임이 통하는 이유

이 논문에서 제가 가장 오래 멈춘 대목은 조건에 대한 서술이었습니다. 서브에이전트 실행이 앞서는 경우는 스킬 패키지가 분명한 입출력 계약을 드러내고, 그 계약을 이행하는 절차 지식을 담고 있을 때라고 정리되기 때문입니다. 이 문장은 짧지만 뜯어볼수록 할 말이 많은데, 계약이란 결국 맡긴 일의 경계이기 때문입니다. 무엇이 들어가고 무엇이 나와야 하며 무엇이 성공인지를 모두가 같은 언어로 아는 상태라는 뜻입니다.

예를 들어 밤늦게 돌아가는 데이터 정리 작업을 떠올려 보겠습니다. 입력으로 어떤 기간의 어떤 테이블을 쓸지, 출력으로 어떤 형식의 어떤 파일을 어디에 남길지, 빈 값이 나오면 어떻게 처리할지가 정해져 있다면 이 일은 방을 따로 내어 맡기기 좋습니다. 서브에이전트는 그 약속 안에서 절차를 밟으면 되고 메인 에이전트는 약속대로 나왔는지만 보면 되기 때문입니다. 반면 적당히 정리해줘처럼 경계가 흐릿하면 방을 몇 개를 내줘도 소용이 없습니다. 깨끗한 방에서 모호한 일을 하면 모호함만 깨끗하게 남기 때문입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 이 결과는 스킬의 내용이 좋아서 이겼다는 뜻이 아니라, 내용이 위임 가능한 형태로 정리되어 있을 때 분리가 이긴다는 뜻에 가깝기 때문입니다. 다시 말해 지식의 양이 아니라 지식의 모양이 승부를 가른 것인데, 절차 지식이 있다는 것은 순서를 안다는 뜻이고 계약이 있다는 것은 순서를 검사할 수 있다는 뜻입니다. 저는 그래서 스킬을 만들 때 설명을 길게 쓰기 전에 입구와 출구를 먼저 좁혀야 한다고 봅니다. 들어오는 것과 나가는 것이 분명하면 가운데 절차는 고치고 가르치기가 훨씬 쉬워지기 때문입니다.

깨끗한 분리가 공짜가 아닌 이유

여기까지 읽으면 분업이 만능처럼 들릴 수 있는데, 연구는 반대쪽도 분명히 말합니다. 격리의 대가는 통신 오버헤드이며, 메인 에이전트와 서브에이전트 사이의 조율에 추가 토큰이 들기 때문입니다. 방을 나누면 각 방은 깨끗해지지만 방 사이를 오가는 설명과 확인과 수정 요청이 새로 생깁니다. 일을 맡길 때 맥락을 넘겨줘야 하고 결과가 오면 검사해야 하며, 어긋나면 다시 설명해야 하기 때문입니다.

이 대가는 작업이 짧을수록 아프게 느껴집니다. 간단한 일을 굳이 나누면 일하는 시간보다 설명하는 시간이 길어질 수 있기 때문입니다. 옆 사람에게 부탁하는 말을 고르는 동안 혼자 끝낼 수 있는 일이 분명히 있습니다. 반면 작업이 길고 복잡할수록 이 비용은 상대적으로 가벼워지는데, 메인 컨텍스트가 무너져서 생기는 손해가 설명에 드는 비용보다 커지기 때문입니다. 결국 같은 예산을 어디에 쓸지 고르는 일이라고 할 수 있으며, 컨텍스트 혼잡으로 잃을 것이 큰 작업에서는 조율 비용을 내는 편이 남는 장사가 됩니다.

저희가 새로운 AI 구조를 볼 때도 숫자의 크기만 보지는 않습니다. 실제로 무엇이 바뀌었고 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보기 때문입니다. 이 연구도 같은 태도로 읽을 수 있는데, 서브에이전트가 이겼다는 결론보다 무엇을 내고 무엇을 샀는지가 더 오래 남는 정보이기 때문입니다. 토큰이 더 든다는 사실은 단점이 아니라 가격표이며, 이 가격표를 보고 어떤 작업에 분리를 살지를 고르면 됩니다.

그래서 지식이 좋다는 말은 절반만 맞다

이 연구가 남기는 문장 중 제가 오래 기억할 것은 재사용 가능한 지식의 가치는 내용만이 아니라 그것을 정리하고 꺼내는 방식에 달려 있다는 대목입니다. 같은 스킬이라도 어떻게 묶고 어떻게 부르느냐에 따라 긴 작업에서의 수명이 달라지기 때문입니다. 그동안 스킬 평가는 좋은 문서 찾기에 가까웠다면, 이제는 좋은 실행 고르기가 함께 들어가야 하죠.

질문도 바뀌었습니다. 무엇을 스킬에 담을 것인가에서 담은 것을 어떤 구조로 실행할 것인가로 말이죠. 내용을 잘 만드는 팀과 실행을 잘 설계하는 팀이 같은 팀이어야 하는 이유도 여기 있는데, 계약이 흐릿한 스킬을 서브에이전트에 얹으면 흩어지고 절차가 없는 스킬을 컨텍스트에 얹으면 묻히기 때문입니다. 어느 쪽이든 내용과 실행이 따로 놀면 긴 작업에서 탈이 나는데, 그래서 스킬 리뷰를 할 때는 문서의 친절함과 함께 입출력의 좁음, 절차의 검사 가능함, 위임의 단위를 같이 봐야 합니다.

그렇다면 우리 일에 바로 적용할 수 있는 것은 무엇일까요. 저는 먼저 스킬 목록을 내용별로 나누기보다 위임 단위로 다시 써보겠습니다. 이 스킬은 통째로 맡길 수 있는가, 맡기려면 입력과 출력을 어떻게 좁혀야 하는가, 절차 중 어디를 검사점으로 삼을 것인가를 묻기 때문입니다. 답이 바로 나오지 않아도 괜찮습니다. 그 질문을 던지는 순간 스킬은 문서에서 작업 단위로 바뀌기 시작하기 때문입니다.

오래 버티는 에이전트를 보고 싶다면 무엇을 물을까

앞으로 남은 질문도 분명합니다. 어떤 스킬이 계약을 잘 드러내는지, 절차 지식은 어느 정도 구체적이어야 하는지, 작업 길이에 따라 분리의 이득이 어디서 역전되는지를 더 잘 알아야 하기 때문입니다. 이 연구가 방향을 잡아준 셈이지만 현장의 작업은 논문의 작업보다 지저분한 경우가 많습니다. 도구가 바뀌고 형식이 어긋나고 중간에 사람이 끼어들기도 하는데, 그런 지저분함 속에서도 계약이 버티는지가 다음에 확인할 일입니다.

제가 앞으로 보고 싶은 것은 실패의 모양입니다. 서브에이전트가 실패할 때는 어디서 실패하는지, 계약이 흐릿해서인지 절차가 빠져서인지 조율이 어긋나서인지가 궁금하기 때문입니다. 실패의 위치가 보이면 고칠 곳도 보입니다. 컨텍스트 실행의 실패가 흐려짐에서 온다면 서브에이전트의 실패는 엇갈림에서 올 가능성이 큰데, 무엇을 기대했는지가 서로 달랐을 때 생기는 실패이기 때문입니다. 이 둘을 구분할 수 있으면 작업의 길이에 따라 실행 방식을 고르는 기준이 훨씬 또렷해집니다.

그렇다면 사람의 역할은 무엇일까요. 저는 스킬을 쓰는 사람이 아니라 스킬을 나누는 사람에 가깝다고 봅니다. 어디서 일을 자르고 무엇을 약속으로 남기며 어떤 검사를 통과해야 다음으로 넘어가는지를 정하는 일이기 때문입니다. 오래 일하는 에이전트는 결국 잘게 나눠진 약속 위에서 버팁니다. 이 논문은 그 약속의 값어치를 조용히 보여준 셈인데, 다음에 긴 에이전트 작업을 설계할 때 저는 지식을 더 모으기 전에 먼저 이렇게 물을 것 같습니다. 이 일은 누구의 방에서 풀어야 가장 덜 흐려질까, 하고요.