슬라이드 한 장에 이미지를 넣는 작업을 떠올려 보자. AI 에이전트(스스로 여러 단계를 밟아 일을 처리하는 AI)는 이미지를 넣은 발표 파일을 이미 저장해 뒀다. 그런데 다음 작업을 시작할 때 그 파일은 다시 열지 않는다. 대신 '이미지를 어떻게 넣었는지' 주고받은 대화 기록부터 다시 읽는다.
작업이 길어질수록 이 기록은 눈덩이처럼 불어난다. 느려지고, 비싸지고, 어제 확정한 것을 조금씩 다르게 기억하기 시작한다. 결과는 파일에 멀쩡히 남아 있는데도 그렇다.
CarryOn의 발상은 단순하다. 완성한 결과물은 환경에 그대로 두고, AI에는 '그게 어디 있고 어떤 조건에서 다시 쓸 수 있는지'만 넘긴다.
기존 방법은 컨텍스트(AI가 한 번에 참고하는 정보 전체)를 줄이기는 해도, 결과물과 조금씩 어긋난다. 크게 두 갈래다. 하나는 기록을 관리하는 쪽이다. 요약하거나, 오래된 걸 잘라내거나(슬라이딩 윈도우: 최근 몇 개만 남기고 옛 기록을 버리는 방식), 필요한 부분만 검색해 가져온다. 다른 하나는 상태를 외부화하는 쪽이다. 진행 상황을 별도 메모나 구조로 옮겨 적는다.
둘의 약점은 같다. 요약이든 옮겨 적은 상태든 결국 '원본을 압축한 설명'이다. AI가 실제로 열어 고치는 결과물과 조금씩 미끄러진다. 이 미끄러짐을 드리프트(drift)라고 부른다.
CarryOn은 압축한 설명을 들고 다니지 않는다. 완성본은 환경에 그대로 두고, 그 위치와 재사용 조건만 넘긴다. 효과는 눈에 보인다. 논문 그림 1의 슬라이드 편집 예시에서, 한 번에 참고하는 정보량은 4만 2,400토큰까지 불어났다가 CarryOn을 적용하면 1만 4,400토큰으로 준다(66.0% 감소). 보고서 작업에서는 5만 8,400에서 2만 3,500으로(59.7%) 준다. 여기서 토큰은 그 정보의 양을 세는 단위다.
어느 시점에 멈춰 보면 손에 쥔 것은 세 가지다. 이미 이미지가 들어간 발표 파일, "표지 로고는 교체 대기"·"본문 글꼴 11pt 유지" 같은 남은 요구와 규칙, 그리고 방금 주고받아 아직 정리하지 않은 날것의 대화. CarryOn은 이 셋을 다음 담당자에게 넘기는 인계서처럼 다룬다.
완성본 파일 자체는 환경에 그대로 둔 채, 이 인계서만 넘어간다.
운반체가 가리키는 '성과'가 꼭 파일인 것은 아니다. 세 가지 형태가 있다. 다시 열 수 있는 파일(외부 객체), 파일로는 안 남는 발견(정보 산출물), 특정 앱·세션 안에서만 유효한 화면 상태(상황적 상태)다.
| 형태 | 무엇인가 | 예 | 운반체가 적는 것 |
|---|---|---|---|
| 외부 객체(External Objects) | 환경에 독립적으로 남아 다시 열고 고칠 수 있는 작업물 | 코드 파일, 문서, 스프레드시트 | 객체의 위치, 담긴 진행 상황, 재사용 조건 |
| 정보 산출물(Information Products) | 상호작용으로 얻은, 파일로는 안 남는 발견 | 종합한 정보, 문제 해결 결론 | 발견 내용과 근거 출처, 재사용 조건 |
| 상황적 상태(Situated State) | 특정 앱·세션 안에서만 유효한 진행 상황 | 열어 둔 화면의 상태 | 돌아갈 화면이나 환경, 확립된 상태, 유효 범위 |
CarryOn의 날카로운 부분은 여기다. '무엇을 결과물로 인정하느냐'가 곧 '언제 기록을 버릴 수 있느냐'를 정한다.
작동 방식부터 보자. 라이브 테일이 일정량 쌓이면 CarryOn은 그걸 접어(이 정리 과정을 접기(fold)라 한다) 운반체와 실행 컨텍스트로 옮기고, 접힌 구간의 원본 로그는 치운다. 매번 전부 다시 쓰지 않는다. 바뀐 기록만 고치고, 검증을 통과하면 한꺼번에 반영하며, 실패하면 기존 기록을 그대로 둔다.
접기에는 규칙이 하나 박혀 있다. 성공한 정리는 운반체를 반드시 한 군데 이상 바꿔야 한다. 실행 컨텍스트만 손봐서는 원본 로그를 치울 수 없다. 사소해 보이는 이 규칙이 실무에서 어떻게 작동하는지, 승인된 시안이 교체되는 상황을 끝까지 따라가 보자.
색 시안 A안이 "모바일에서 더 잘 읽힌다"는 근거로 승인됐다. 운반체에는 '현재 확정 = 시안 v1, 재사용 조건 = A안·모바일 가독성'이 적힌다. 이미지를 몇 번째에 어떤 순서로 넣었는지는 파일만 있으면 버려도 된다. 하지만 '왜 A안인가', 곧 승인 조건은 파일만 봐선 모르니 운반체에 남는다. 다음 날 디자이너가 시안을 v2로 바꾼다. 이제 파일 버전이 교체됐으니 v1에 붙었던 승인은 더는 유효하지 않다.
문제는 여기서 갈린다. 운반체의 '확정 = A안' 꼬리표가 파일 교체에 맞춰 함께 갱신되지 않으면, 에이전트는 무효가 된 승인을 멀쩡하다 믿고 v2를 확정본처럼 이어간다. 그래서 운반체의 재사용 조건은 '어떤 파일 버전에 대한 승인인가'와 '그 버전이 바뀌면 승인은 무효'를 함께 담아야 한다. 다만 앞의 '운반체를 최소 한 군데 바꾼다'는 규칙이 이 갱신까지 보장해 주지는 않는다. 접기는 다른 운반체를 바꾸는 것만으로도 성립하고, 확인되지 않은 후보는 건너뛴 채 다른 후보만 손볼 수도 있다. 버전·승인 꼬리표가 파일 교체에 맞춰 제때 갱신되도록 하는 일은 규칙이 강제하는 게 아니라 정리 모듈이 책임져야 하는 몫이고, 그래서 뒤에서 볼 '조건을 잘못 적을 위험'이 남는다.
결국 결과물의 테두리를 어디에 긋느냐가 로그를 언제 버릴지를 정한다. 좁게 잡으면 버리지 못한 로그가 쌓이고, 넓게 잡으면 승인 근거 같은 미묘한 정보까지 결과물에 눌러 담아야 한다. 어디에 긋느냐는 결국 설계자의 몫이다.
OSWorld 2.0은 컴퓨터를 직접 조작하는 과제 모음이다. 같은 모델에 CarryOn을 붙였을 때와 안 붙였을 때를, 과제를 끝낸 정도와 과제당 쓴 토큰·비용으로 비교했다. 점수는 두 종류다. 이진점수는 과제를 끝까지 해낸 비율, 부분점수는 중간까지 얼마나 해냈는지다.
| 지표(OSWorld 2.0 전체) | 기준선 | CarryOn |
|---|---|---|
| 부분점수 | 43.9% | 49.7% (+5.8%p) |
| 이진점수 | 15.7% | 19.4% (+3.7%p) |
| 과제당 총 토큰 | 4,010만 | 1,930만 (51.9% 감소) |
| 과제당 비용 | $36.8 | $23.6 (35.9% 감소) |
'과제당 총 토큰'은 한 번에 읽는 양이 아니라 작업 전체에서 읽고 쓴 양의 합이다. CarryOn의 $23.6은 에이전트가 실제 작업에 쓴 $20.51에 컨텍스트를 정리하느라 쓴 $3.11을 더한 값이고, 총 토큰 1,930만 가운데 정리 몫은 69만이다. 관리 비용을 더하고도 토큰은 절반으로, 비용은 3분의 1 넘게 줄었다.
설정 메모: 본체 에이전트와 CarryOn의 정리 모듈(Tracker·Compiler)에는 모두 Claude Opus 4.7을 썼다. 과제당 최대 500스텝을 허용했고, 점수는 공식 방식대로 부분·이진을 함께 보고한다. 효율은 에이전트가 쓴 양뿐 아니라 정리 호출이 추가로 쓴 양까지 함께 센 값이다.
검색 과제에서도 정확도는 오르고 토큰·비용은 준다. BrowseComp-Plus(무작위 100문항, Qwen3-32B 모델이 공식 기준으로 채점)에서 정확도는 49.0%에서 56.0%로(+7%p) 올랐고, 총 토큰은 22.9%, 총 비용은 7.1% 줄었다. 비용 절감폭이 OSWorld보다 작은 이유는 분명하다. 검색 과제는 과제당 토큰 규모 자체가 작아(기준선 156만 대 4,010만) 정리 호출이 차지하는 비중이 상대적으로 크다.
절감은 작업이 길어질수록 쌓인다. 논문 그림 3에서 기준선의 컨텍스트는 작업 내내 자라 20만 토큰을 넘어서지만, CarryOn의 평균 입력 컨텍스트는 약 6만 5,000토큰에서 멈춘다. 비용 곡선은 처음엔 정리 호출 때문에 더 들지만 곧 기준선과 교차하고, 턴 500에서는 정리 비용까지 포함한 누적 비용을 34.1% 줄인다.
같은 결과물 중심 원리를 요약 안에만 넣는 것과, 작업 내내 유지·관리하는 것은 결과가 다르다. 40과제 공유 집합에서 다섯 방식을 맞붙였다.
| 방식 | 접기 후 텍스트 길이(k자) | 이진(%) | 부분(%) |
|---|---|---|---|
| 기준선 | – | 22.50 | 50.32 |
| 슬라이딩 윈도우 | 12.08 | 15.00 | 37.41 |
| 일반 요약(GS) | 17.60 | 15.00 | 44.94 |
| CarryOn식 가이드 요약(CGS) | 23.94 | 20.00 | 50.93 |
| CarryOn | 21.54 | 22.50 | 55.93 |
'접기 후 텍스트 길이'는 한 번 정리한 직후 남은 분량으로, 앞의 '총 토큰'(작업 전체에서 읽고 쓴 양)과는 다른 수치다. 이 집합의 기준선 점수도 전체 벤치마크와 모집단이 달라 위 주 결과와 직접 비교하면 안 된다.
관측된 결과는 이렇다. 기록을 공격적으로 압축하는 슬라이딩 윈도우와 일반 요약은 컨텍스트를 가장 짧게 유지하지만, 꼭 필요한 정보까지 함께 버려 점수가 기준선보다 떨어진다. 결과물 중심 원리를 요약 텍스트에만 적용한 CGS는 부분점수를 50.93%까지 올렸다. 그런데 그 구조를 작업 내내 유지한 완전한 CarryOn은 55.93%로 더 높았고, 정리 직후 남은 분량은 오히려 더 짧았다(21.54k자 대 23.94k자).
설계상 차이가 여기서 나온다. CGS는 접을 때마다 요약을 통째로 새로 써서 갈아끼운다. CarryOn은 같은 결과물의 기록을 여러 번의 접기에 걸쳐 '유지'하면서 바뀐 부분만 고친다. 실제로 검증을 거쳐 반영된 정리 전후로 운반체 기록의 80%가 그대로 유지되거나 갱신된다.
해석은 조심해서 해야 한다. 점수가 오른 것은 매번 다시 쓰는 과정의 정보 손실을 줄였을 가능성이 있지만, 이 설계는 드리프트를 직접 측정하지는 않았다. 결과물 중심이 요약보다 덜 미끄러진다는 주장은 과제 점수로 간접 뒷받침될 뿐이다. 확실히 하려면 에이전트가 앞선 결과를 다시 뒤지거나 제약을 빠뜨리는 빈도를 따로 세어 봐야 한다.
운반체와 실행 컨텍스트는 서로를 대신하지 못한다. 한쪽씩 꺼 보면 드러난다. 실행 컨텍스트를 숨기면 이진점수가 22.50%에서 17.50%로, 부분점수가 55.93%에서 44.00%로 떨어진다. 에이전트 호출 수는 거의 그대로다. 완성된 결과물은 여전히 보이지만 목표·제약·남은 요구가 사라져 작업을 끝맺지 못한다.
운반체를 숨기면 반대로 움직인다. 부분점수가 44.62%로 떨어지고, 호출이 23.8%, 비용이 22.3% 늘어난다. 이미 이뤄 놓은 진행에 바로 닿지 못해, 앞선 결과를 되찾거나 다시 만들어야 하는 것으로 보인다. 그게 '되찾기'인지 '다시 만들기'인지는 이 수치만으로는 가릴 수 없다.
접기 한 번은 네 단계로 돈다.
온틀은 소기업과 1인 창업가의 반복 업무를 덜어 주는 AI PM 파견형 서비스다. AI PM이 '3일짜리 신제품 소개 페이지 제작'처럼 여러 날 걸리는 과제를 맡으면, 앞의 슬라이드 문제가 그대로 재연된다. 확정된 문구 파일은 다시 열지 않고 늘어진 과거 대화만 되읽는 식이다. CarryOn식이라면 확정 문구·배포된 시안·승인된 색 설정이 각각 운반체가 되어 넘어가고, 수정 과정은 접혀 빠진다.
넣을지 말지는 두 가지로 가늠한다(아직 적용 전의 가정이다).
첫째, 파일이 교체될 때 승인 조건이 함께 갱신되는가. 앞서 본 시안 교체가 그대로 업무에서 일어난다. 옛 승인이 새 파일에 잘못 들러붙으면, 절감은 품질을 깎는다.
둘째, 재작업과 총비용이 실제로 내려가는가. PM이 이미 끝낸 걸 다시 하거나 지켜야 할 제약을 빠뜨리는 일이 도입 전후로 줄고, 정리 비용까지 더한 총비용이 내려가야 한다.
검토하는 사람이 스스로 던질 질문은 세 가지로 좁혀진다. 내 작업은 다시 열 수 있는 산출물을 남기는가, 아니면 전부 대화 안에서만 사는가. 그 산출물이 '어떤 조건에서 유효한가'까지 운반체에 적히는가. 그리고 이 작업은 접기 비용을 뽑을 만큼 긴가.
지금 구현에서 성공한 접기는 최근 기록 전체를 한 번에 덮는다. 일부만 접는 전략은 이 논문의 범위 밖이다.
아니다. 이 검증은 정리 과정이 모순되거나 근거 없는 내용으로 오염되는 걸 막는 장치일 뿐, 과제의 정답 여부는 보지 않는다. 과제 수준의 검증은 따로 둬야 한다.
정보 산출물 운반체에 발견 내용과 근거 출처, 재사용 조건을 적어 둔다. 정리할 때 적힌 내용이 원래 출처와 맞는지 확인하는 단계를 거친다.