일하는 에이전트는 왜 잊는 법부터 배워야 할까

Agent-Controlled Forgetting for Tool-Using Agents: Reversible Context Curation in Practice는 arXiv에 2610.10590 번호로 공개된 연구로, 도구 사용 에이전트가 스스로 과거의 도구 관찰 결과를 골라 보관하는 방법을 제안합니다. 이 방법이 하는 일은 한 문장으로 정리할 수 있는데, 별도의 과제 전용 훈련 없이 행동 모델이 직접 잊을 관찰을 고르고 각 결과를 원래 자리에 짧은 메모로 바꾼 뒤 정확한 원본은 되찾을 수 있는 보관함에 남긴다는 것입니다. 이 글에서는 그 동작 방식과 OpenTelemetry 궤적에서 보고된 토큰 및 비용 변화를 순서대로 따라가 보겠는데, 원문 논문으로 이어지는 연결은 제목 아래에 걸려 있습니다.

오래 일하는 에이전트를 보면 가방부터 무거워집니다

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

오래 일하는 사람을 보면 가방이 먼저 무거워진다는 말이 있는데, 도구 쓰는 에이전트를 옆에서 지켜보면 느낌이 비슷합니다. 일을 잘한다는 이유로 계속 일을 맡기면, 처음에는 가볍게 움직이던 에이전트가 어느 순간부터 숨이 차오르거든요. 그렇다면 그 무거움은 정확히 어디에서 오는 걸까요?

제가 이 논문에서 가장 흥미롭게 본 부분은 바로 그 질문을 정면으로 다룬다는 점입니다. 도구 사용 에이전트는 명령을 실행할 때마다 관찰 결과를 받아오는데, 문제는 그 관찰을 매번 통째로 들고 다닌다는 데 있습니다. 로그 몇 줄만 있으면 되는 상황에서도 수천 줄짜리 출력 전체를 다음 차례, 또 그다음 차례까지 계속 복사해서 가지고 다니죠. 사람이 출장 다녀와서 영수증 뭉치를 전부 주머니에 넣고 다니는 모습과 다르지 않습니다. 실제로 필요한 내용은 그중 몇 줄에 불과한데도 말이죠.

이런 누적은 처음에는 티가 나지 않습니다. 한두 번 도구 호출쯤이야 맥락 창에 여유가 있으니까요. 그런데 디버깅처럼 도구를 수십 번 호출하는 궤적에서는 이야기가 달라집니다. 매 차례마다 과거 관찰이 전부 다시 입력되기 때문에, 뒤로 갈수록 입력이 기하급수적으로 불어납니다. 저는 이 지점에서 고개를 끄덕였습니다. 토큰 비용이 무서워서 에이전트를 짧게 끊어 쓰는 팀을 여럿 봐왔기 때문입니다. 길게 일하게 하고 싶은데 길게 일할수록 비싸지는 구조라면, 그건 설계의 문제라고 봐야 하지 않을까요?

버리는 게 아니라 창고에 넣어두는 쪽을 택한 이유

그렇다면 쌓인 기록을 어떻게 줄일 수 있을까요? 가장 먼저 떠오르는 답은 요약입니다. 긴 관찰을 짧게 줄여서 보관하자는 것이죠. 그런데 요약에는 묘하게 불안한 구석이 있습니다. 한 번 줄여버리면 원래 문장이 사라지기 때문에, 나중에 그 줄임이 잘못됐다는 걸 알게 돼도 되돌릴 길이 없거든요. 사람이 중요한 계약서를 요약본만 남기고 원본을 파쇄하는 일과 비슷합니다. 당장은 깔끔해 보이지만, 분쟁이 생기면 막막해집니다.

이 연구가 고른 답은 그래서 요약이 아니라 보관입니다. 잊을 관찰을 고르고, 그 자리에 짧은 메모를 남기며, 정확한 원본은 별도의 보관함 안에 그대로 두는 방식이죠. 메모는 어디에 무엇이 있었는지를 알려주는 이정표 역할을 하고, 원본은 필요해지면 다시 꺼내올 수 있습니다. 저는 이 구분이 마음에 들었습니다. 잊는다는 말을 들으면 삭제부터 떠올리기 쉬운데, 여기서는 잊기가 삭제가 아니라 정리에 가깝기 때문입니다. 책상 위에 쌓인 서류를 버리는 대신 상자에 넣어 옆에 두는 셈이죠. 자리만 차지하지 않으면 당장 눈앞에 없어도 괜찮은 것들은 일단 치워두고, 필요하면 상자를 열면 됩니다.

여기서 재미있는 질문이 생깁니다. 무엇을 상자에 넣을지는 누가 정할까요? 외부 규칙으로 정할 수도 있고, 별도로 훈련한 작은 모델에게 맡길 수도 있습니다. 하지만 이 연구는 일을 하고 있는 행동 모델 본인에게 그 선택을 맡깁니다. 지금 궤적을 가장 잘 아는 존재가 바로 그 모델이기 때문입니다. 어떤 관찰이 이미 쓰임을 다했는지, 어떤 관찰은 나중에 다시 필요할지, 그 감각은 바깥에서 정한 규칙보다 현장의 판단에 가깝죠. 그래서 이 방법은 새로운 훈련을 요구하지 않습니다. 이미 일하고 있는 모델에게 잠깐 멈춰 서서 가방을 정리할 권한을 주는 셈입니다.

만지면 안 되는 물건부터 정해두는 일

그런데 가방을 정리하라고 하면, 가끔 중요한 여권을 함께 버리는 사람이 있습니다. 에이전트에게 잊을 권한을 준다고 할 때 제가 가장 먼저 걱정했던 부분도 바로 그 점이었습니다. 사용자가 준 지시나 지금까지 어시스턴트가 내놓은 판단까지 함께 정리해 버리면, 궤적 자체가 무너지기 때문입니다. 그래서 이 방법은 시작부터 만지면 안 되는 물건을 정해둡니다.

이 설계에서는 사용자 지시와 어시스턴트 메시지는 보관 대상에서 제외됩니다. 아무리 길어 보여도 손대지 않는 것이죠. 정리 대상은 이전에 관찰한 도구 결과로 한정됩니다. 생각해보면 꽤 상식적인 구분인데, 막상 시스템으로 만들려면 명확한 경계가 필요합니다. 도구 출력은 길고 버릴 게 많아 보이는 반면, 사용자 지시는 짧아도 잃어버리면 복구가 안 되기 때문입니다. 연구가 파이썬 하네스 안에 이 보호 규칙을 넣어둔 이유도 여기에 있다고 봅니다. 판단은 모델에게 맡기되, 판단이 작동하는 울타리는 코드로 고정해두는 것이죠.

이 대목에서 실제 시스템 관점으로 보면 다음 질문이 바로 생깁니다. 보호 규칙이 있으면 모델이 실수로 지시를 지우는 일은 막을 수 있지만, 도구 결과 안에 섞여 있던 중요한 단서는 어떻게 될까요? 예를 들어 디버깅 로그 중간에 있던 에러 코드 한 줄이 나중에 결정적인 단서가 되는 경우 말이죠. 이 방법의 답은 그 단서를 메모에 힌트로 남기고 원본을 보관함에 두는 것입니다. 완전히 지우는 게 아니라 참조 형태로 남기니까요. 물론 메모가 부실하면 나중에 다시 꺼내오기까지 한 단계가 더 필요해집니다. 이 교환 관계는 뒤에서 숫자와 함께 다시 살펴보겠습니다.

에이전트가 스스로 고르는 과정은 어떻게 돌아갈까

이제 실제 정리 과정이 어떻게 돌아가는지 따라가 보겠습니다. 상상해보면 장면은 이렇습니다. 에이전트가 도구를 여러 번 호출한 뒤, 어느 시점에서 잠깐 멈춰 서서 지금까지의 궤적을 되돌아봅니다. 그리고 각 도구 관찰에 대해 지금 당장 눈앞에 두어야 하는지, 아니면 보관함으로 옮겨도 되는지를 고릅니다. 고른 관찰은 원래 자리에서 짧은 메모로 바뀌고, 정확한 원본은 보관함으로 이동합니다. 궤적의 순서는 그대로 유지되기 때문에, 나중에 읽어보면 어디에서 무엇이 치워졌는지가 그대로 드러납니다.

저는 이 장면에서 두 가지가 눈에 띄었습니다. 하나는 원래 위치에 메모를 남긴다는 점입니다. 단순히 지워버리면 나중에 그 자리에 무엇이 있었는지조차 알 수 없는데, 짧은 메모가 남으면 흐름이 끊기지 않기 때문입니다. 책에서 몇 페이지를 발췌해 별책으로 옮기면서, 원래 페이지에는 어디로 옮겼다는 쪽지를 붙여두는 방식과 비슷합니다. 다른 하나는 이 선택을 별도 훈련 없이 한다는 점입니다. 새로운 모델을 학습시키는 대신, 이미 궤적을 이해하고 있는 행동 모델에게 정리를 요청하는 것이죠. 그래서 도입 비용이 가벼운 편입니다. 규칙을 일일이 손으로 적어줄 필요도 없고, 과제마다 정리 모델을 다시 만들 필요도 없습니다.

그렇다면 모델이 잘못 고르면 어떻게 될까요? 이 질문은 자연스럽지만, 답은 생각보다 차분합니다. 잘못 골라도 원본이 보관함에 남아 있으니 복구할 수 있기 때문입니다. 물론 복구에 손이 가긴 합니다. 그래도 요약처럼 되돌릴 수 없이 정보를 잃는 경우와는 성격이 다릅니다. 저는 이 부분을 읽으면서 일종의 안전망이 있는 위임이라고 느꼈습니다. 권한을 주되, 실수했을 때 돌아올 길을 함께 만들어둔 것이죠. 에이전트를 오래 돌려본 분이라면 이 감각이 얼마나 중요한지 아실 겁니다. 자율성을 주면서도 복구 가능성을 남기는 설계는 운영에서 마음이 놓이니까요.

한 번에 하나씩이 아니라 묶음으로 처리하는 이유

정리할 때마다 관찰 하나씩을 낚아채듯 처리하면 어떻게 될까요? 얼핏 효율적이어 보이지만, 실제로는 판단이 파편화되기 쉽습니다. 어떤 관찰이 쓸모없는지는 앞뒤 관찰과 함께 봐야 알 수 있는 경우가 많기 때문입니다. 그래서 이 방법의 하네스는 일괄 보관이라는 방식을 씁니다. 여러 관찰을 한 번에 묶어서 보관 결정을 내리는 것이죠.

이 선택은 생각보다 중요합니다. 도구 궤적에서는 비슷한 출력이 반복되는 경우가 많은데, 하나씩 보면 매번 남길지 말지 헷갈리지만 묶어서 보면 패턴이 보이기 때문입니다. 예를 들어 같은 테스트를 세 번 돌려서 비슷한 로그가 세 번 쌓였다면, 그중 최신 것만 남기고 나머지는 보관함으로 옮기는 판단이 쉬워집니다. 반면 하나씩 따로 보면 매번 이 로그가 나중에 필요할지 고민하게 되죠. 묶음 처리는 그런 반복 판단을 한 번에 끝내는 효과가 있습니다.

여기서 또 하나 눈여겨볼 점은 이 묶음 처리가 파이썬 하네스라는 명확한 형태로 제공된다는 것입니다. 연구 아이디어가 말로만 있으면 현장에서 쓰기 어렵지만, 보관과 복구라는 동작이 코드로 정리되어 있으면 바로 시험해볼 수 있거든요. 저희가 새로운 AI 기법을 볼 때도 논문의 주장만큼이나 재현 가능한 형태를 함께 봅니다. 말은 그럴듯한데 손에 잡히는 게 없으면, 좋은 아이디어도 현장까지 오지 못하기 때문입니다. 그런 점에서 일괄 보관과 명시적 복구를 코드 수준에서 나눠둔 것은 꽤 실무적인 선택이라고 봅니다.

필요해지면 다시 꺼내 오는 장치는 왜 따로 있을까

보관만 있고 복구가 없으면 그건 그냥 우아한 삭제입니다. 그래서 이 방법에는 명시적인 복구 동작이 따로 있습니다. 메모만 보고는 부족하고 원본이 다시 필요하다고 판단되면, 보관함에서 정확한 원본을 꺼내오는 것이죠. 이 장치가 따로 있다는 사실이 언뜻 번거롭게 느껴질 수도 있습니다. 그런데 막상 운영을 생각하면 분리가 오히려 자연스럽습니다.

이유는 판단의 시점이 다르기 때문입니다. 보관은 지금 당장 필요 없어 보이는 것을 치우는 일이고, 복구는 나중에 다시 필요하다는 걸 깨닫는 일인데, 두 판단은 서로 다른 순간에 일어납니다. 하나의 동작으로 합쳐버리면 그때그때의 맥락을 놓치기 쉽죠. 그래서 하네스는 두 동작을 나눠서 제공합니다. 치울 때는 치우는 기준으로, 꺼낼 때는 꺼내는 기준으로 생각하라는 것입니다. 사람이 창고를 정리하는 방식과 비슷합니다. 넣을 때는 자주 쓰는지로 판단하고, 꺼낼 때는 지금 하는 일에 필요한지로 판단하니까요. 기준이 다르니 손잡이도 두 개인 게 편합니다.

저는 여기서 조금 멈칫했습니다. 복구가 가능하다는 말이, 복구가 공짜라는 뜻은 아니기 때문입니다. 다시 꺼내오려면 추가 요청이 필요하고, 그만큼 시간과 토큰이 듭니다. 실험에서도 이 비용이 실제로 드러납니다. 그럼에도 불구하고 복구 장치가 있는 것과 없는 것의 차이는 큽니다. 없는 경우에는 한 번의 잘못된 정리가 궤적 전체를 망가뜨릴 수 있지만, 있는 경우에는 추가 비용을 내고 되돌리면 되기 때문입니다. 안전망은 공짜가 아니어도 있는 편이 낫다는 것, 운영을 해본 사람이라면 공감하실 겁니다.

숫자가 말하는 것과 말하지 않는 것

이제 숫자를 볼 차례입니다. 연구가 제시한 궤적은 OpenTelemetry를 디버깅하고 구현하는 긴 작업인데, 도구 호출이 반복되면서 맥락이 무겁게 쌓이는 종류의 일입니다. 이 궤적에서 기록을 그대로 유지한 쪽은 제공자 기준으로 보고된 프롬프트 토큰이 912,492까지 불어났습니다. 반면 보관 방법을 쓴 쪽은 같은 일을 끝내고도 231,951에서 멈췄습니다. 단순 비교로도 4분의 1 수준인데, 누적 입력 토큰으로는 절반을 썼다고 보고됩니다. 비용 추정치도 4.38달러 근처에서 1.28달러에서 1.44달러 사이로 내려왔습니다.

일반 파일에만 남겼을 때와 다른 장치에 남겼을 때 결과가 달라졌던 앞선 사례들처럼, 숫자는 조건과 함께 읽어야 합니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 토큰이 줄었다는 사실 자체보다, 어떻게 줄었는지가 다음 일에 그대로 적용될지를 가르쳐주기 때문입니다. 여기서는 도구 관찰이라는 특정 구간이 줄었습니다. 사용자 지시나 어시스턴트 판단이 줄어든 게 아니라, 반복되는 관찰 더미가 정리된 것이죠. 그래서 이 절감은 관찰이 많이 쌓이는 일에서 크게 나타나고, 관찰이 별로 없는 일에서는 작아질 수밖에 없습니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 비용 추정치는 그 자체로 정확한 청구서가 아니라 조건이 붙은 계산이기 때문입니다. 모델 가격, 제공자의 토큰 집계 방식, 복구 때문에 늘어난 요청 횟수가 함께 얽혀 있습니다. 그럼에도 불구하고 방향은 분명합니다. 길고 반복적인 도구 궤적에서는 보관만으로 체감할 수 있는 절감이 생긴다는 것이죠. 저는 그래서 이 숫자를 할인율로 읽기보다 구조의 증거로 읽는 편이 좋다고 봅니다. 어디가 무거웠고, 어디를 치웠더니 가벼워졌는지를 보여주는 기록으로 말이죠. 그렇게 읽으면 다음 질문이 자연스럽게 이어집니다. 가벼워진 대신 무엇을 더 냈을까요?

빨라진 게 아니라 가벼워진 것이라는 오해에 대하여

이 방법을 처음 들으면 더 빨라지고 더 싸지는 기술처럼 느껴지기 쉽습니다. 그런데 실험 기록을 들여다보면 이야기가 조금 다릅니다. 보관 방법을 쓴 쪽은 요청을 더 많이 보냈고, 전체 소요 시간도 17퍼센트 길어졌습니다. 메모를 남기고, 보관하고, 필요하면 다시 꺼내오는 과정 자체가 일을 늘리기 때문입니다. 가방은 가벼워졌지만, 정리하느라 손이 더 간 셈이죠.

이 차이는 생각보다 중요합니다. 토큰이 줄었다고 해서 모든 비용이 줄었다고 말할 수는 없기 때문입니다. 입력 토큰은 절반으로 줄었지만, 그 대신 요청 횟수와 대기 시간이 늘어났습니다. 어떤 팀에게는 이 교환이 남는 장사고, 어떤 팀에게는 그렇지 않을 수 있습니다. 토큰 단가가 부담스러운 팀이라면 기꺼이 시간을 조금 더 내줄 것이고, 응답 속도가 중요한 서비스라면 반대로 판단할 수 있죠. 저는 이 대목을 읽으면서, 이 방법은 절약 기술이라기보다 비용의 모양을 바꾸는 기술에 가깝다고 느꼈습니다. 총량을 줄이는 대신, 비싼 입력의 반복을 싼 추가 요청 몇 번으로 바꾸는 것이죠.

그렇다면 행동 품질은 어떻게 됐을까요? 두 경우 모두 두 개짜리 기본 행동 판정을 통과했지만, 후속 평가를 완전히 만족하지는 못했습니다. 이 결과는 해석이 필요한데, 보관 쪽만 못한 게 아니라 양쪽 다 후속 평가에서 아쉬웠다는 점이 눈에 띕니다. 다시 말해 그 후속 평가는 보관 여부와 상관없이 어려운 과제였던 셈입니다. 여기서는 보관 방법이 일을 망쳤다고 읽기보다, 기본 난도가 높은 과제에서도 기본 동작은 유지됐다고 읽는 편이 사실에 가깝습니다. 물론 후속 평가를 통과하지 못했다는 사실 자체는 남습니다. 그래서 저는 이 결과를 성공 선언이 아니라 조건부 합격점으로 봅니다. 가벼워졌고 기본 동작은 지켰지만, 어려운 마무리는 여전히 숙제로 남았다는 것이죠.

어떤 일에서는 통하고 어떤 일에서는 그대로인 이유

앞에서 본 OpenTelemetry 궤적의 절감이 모든 일에 그대로 적용될까요? 연구가 덧붙인 대조 사례는 그렇지 않다고 말합니다. 응용 프로그램을 만드는 또 다른 궤적 쌍에서는 뚜렷한 절감이 나타나지 않았습니다. 같은 방법을 썼는데도 한쪽에서는 절반이 줄고 다른 쪽에서는 그대로였던 것이죠. 이 차이를 어떻게 이해해야 할까요?

이유를 따져보면 구조로 돌아옵니다. 이 방법이 치우는 것은 도구 관찰이기 때문에, 관찰이 많이 쌓이지 않는 일에서는 치울 분량 자체가 적습니다. 반대로 로그가 쏟아지는 디버깅처럼 관찰이 계속 쌓이는 일에서는 치울 게 많아집니다. 마치 옷장 정리와 비슷합니다. 옷이 가득한 방은 정리 효과가 크지만, 원래 옷이 몇 벌 없는 방은 정리해도 티가 나지 않죠. 그래서 이 방법은 만능 절약기가 아니라 작업에 따라 효과가 갈리는 정리법이라고 보는 편이 정확합니다. 어디에나 뿌리면 좋아지는 비료가 아니라, 더미가 쌓이는 곳에서 힘을 발휘하는 도구인 셈입니다.

이 지점에서 흔한 오해를 하나 짚고 넘어가고 싶습니다. 보관한다고 해서 에이전트가 똑똑해지는 건 아니라는 점입니다. 이 방법은 추론 능력을 올리거나 새로운 지식을 넣어주지 않습니다. 그저 들고 다니는 짐을 가볍게 만들 뿐이죠. 그런데 현장에서는 가벼움이 곧 성능이 되는 경우가 있습니다. 맥락이 너무 길어지면 모델이 앞부분을 놓치거나 중간 지시를 희미하게 기억하는 일이 생기기 때문입니다. 짐을 줄이면 그런 실수가 줄어들 수 있습니다. 다만 이번 실험만으로 그 효과까지 단정하기는 어렵습니다. 기본 판정은 통과했지만 후속 평가가 남았듯이, 가벼움이 정확도 향상으로 이어지는지는 별도의 질문이기 때문입니다.

그래서 저는 다음 실험에서 무엇을 보고 싶냐면

여기까지 오면 자연스럽게 다음 질문이 생깁니다. 이 정리법이 어디까지 통할까요? 제가 앞으로 보고 싶은 것은 세 가지입니다. 첫째는 보관 기준의 일관성입니다. 같은 궤적을 여러 번 정리해도 비슷한 관찰을 고르는지, 아니면 매번 다른 것을 고르는지가 궁금합니다. 기준이 들쭉날쭉하면 운영에서 예측이 어렵기 때문입니다. 둘째는 메모의 품질입니다. 짧은 메모가 얼마나 정확하게 원본을 가리키는지, 그리고 메모만으로 충분한 경우와 원본 복구가 필요한 경우를 얼마나 잘 가르는지가 중요합니다. 메모가 부실하면 복구 요청이 늘어나서 아낀 토큰을 도로 내놓게 되니까요.

셋째는 더 긴 궤적에서의 거동입니다. 이번 OpenTelemetry 궤적도 충분히 길지만, 실제 운영에서는 며칠씩 이어지는 에이전트도 있습니다. 보관함 자체가 커지면 그 보관함을 어떻게 관리할지도 문제가 됩니다. 보관함이 또 다른 무거운 가방이 되지는 않을까요? 아마 보관함 안에서도 오래된 것부터 요약하거나 버리는 2차 정리가 필요해질 겁니다. 그렇다면 그때는 무엇을 버릴 수 있을까요? 이런 질문이 꼬리를 무는 이유는, 잊기가 한 번의 동작이 아니라 계속 이어지는 관리이기 때문입니다. 한 번 치우고 끝나는 청소가 아니라, 살림처럼 계속 손이 가는 일이죠.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이 방법을 지금 당장 도입한다면 어디부터 적용할까요? 저는 관찰이 많이 쌓이는 디버깅이나 탐색 작업부터 시험해볼 것 같습니다. 효과가 가장 크게 나타나는 자리이기도 하고, 실패해도 복구 장치가 있으니 부담이 적기 때문입니다. 반대로 사용자 지시가 복잡하게 얽힌 작업이나, 도구 출력 한 줄 한 줄이 모두 중요한 작업에서는 조금 늦춰도 됩니다. 아낄 게 적은 곳에 먼저 도입하면 손에 남는 게 적기 때문입니다. 좋은 건 알겠는데 이걸 실제로 어디에 올릴까요라는 질문에 대한 저의 답은, 더미가 쌓이는 곳부터라는 것입니다.

가벼운 가방이 오래 일하는 습관을 만듭니다

처음에 가방 이야기로 시작했는데, 다시 그 이야기로 돌아오겠습니다. 오래 일하는 에이전트가 필요해질수록, 많이 기억하는 능력만큼이나 잘 잊는 능력이 중요해집니다. 이 연구가 보여준 것은 잊기를 삭제가 아니라 관리로 바꾸는 하나의 구체적인 형태입니다. 원래 자리에 메모를 남기고, 정확한 원본을 보관함에 두고, 필요하면 다시 꺼내오며, 사용자 지시와 어시스턴트 메시지는 손대지 않는 것이죠. 별도 훈련 없이 일하는 모델 본인이 고른다는 점도 현장에서는 반가운 조건입니다.

숫자를 다시 떠올려보면, OpenTelemetry 궤적에서 프롬프트 토큰은 912,492에서 231,951로 줄었고 누적 입력은 절반이 되었으며 비용 추정치는 4.38달러 근처에서 1달러대 초반으로 내려왔습니다. 대신 요청은 늘었고 시간은 17퍼센트 길어졌으며, 다른 작업 쌍에서는 절감이 나타나지 않았습니다. 저는 이 한 묶음을 함께 기억하고 싶습니다. 절감만 떼어내어 자랑하면 오해가 생기지만, 조건과 함께 읽으면 설계 감각이 생기기 때문입니다. 어디가 무거웠는지, 무엇을 치웠는지, 그 대신 무엇을 냈는지, 그리고 어떤 일에서는 통하지 않는지를 함께 아는 것이 이 논문을 읽는 가장 실용적인 방법이라고 봅니다.

그렇다면 사람의 역할은 무엇일까요. 에이전트가 스스로 잊을 수 있게 됐다고 해서 사람의 판단이 덜 중요해지는 건 아닙니다. 오히려 무엇을 잊어도 되는지, 어디까지 되돌릴 수 있어야 하는지, 어떤 작업에 먼저 적용할지를 정하는 일은 여전히 사람의 몫입니다. 잊기를 맡기되, 잊는 방식은 함께 설계하는 것이죠. 가벼운 가방이 오래 일하는 습관을 만들듯, 잘 고른 잊기가 오래 일하는 에이전트를 만든다고 저는 봅니다. 다음에 긴 궤적을 돌릴 때, 통째로 들고 다니는 관찰 뭉치부터 한 번 들여다보시면 어떨까요?