행동하기 전에 고르기, 긴 도구 사용 에이전트가 배워야 할 한 박자

Choosing Before Acting: Comparative Value Estimation for Long-Horizon Tool-Use Agents는 arXiv에 공개된 연구로 arXiv 번호 2610.02330으로 등록되어 있다. 원문 링크는 제목 아래에 걸어두었다.

이 연구가 내세우는 주장은 하나의 문장으로 정리된다. 긴 도구 사용 과정을 다루는 에이전트는 다음 도구 호출을 실행하기 전에 그 호출이 최종 성공에 이를 가능성을 견주어 보는 법을 배워야 한다는 것이다. 이 글에서는 그 문제의식에서 출발해 왜 마지막 결과만으로는 부족한지, 매 단계의 가치를 어떻게 가르칠 수 있는지, 그리고 비교라는 선택이 무엇을 바꾸는지 차례로 따라간다.

에이전트를 써보면 도구를 고르는 손이 먼저 떨린다

저는 이 논문을 읽기 전에 며칠 동안 에이전트에게 자료 조사 일을 시키고 있었습니다. 논문 몇 편을 찾아서 표를 정리하고, 중간에 막히면 다른 검색어로 돌아오라고 했죠. 결과는 절반만 맞았습니다. 마지막 표는 그럴듯했는데, 중간에 어떤 검색을 골랐는지 들여다보면 운이 좋았다는 말이 더 어울렸습니다. 잘 고른 다음 검색 덕분에 풀린 게 아니라, 서툰 검색 몇 번을 버티고 나서 겨우 답에 닿은 셈이었죠.

여러 사람이 함께 일하다 보면, 누군가의 사소한 선택 하나가 오후의 일정 전체를 바꾸기도 합니다. 점심 전에 어떤 업체에 먼저 전화를 거느냐 같은 결정이 그렇죠. 그렇다면 여러 단계를 이어가는 AI 에이전트에서도 비슷한 일이 생기지 않을까요. 첫 번째 도구 호출이 두 번째 장면을 만들고, 두 번째 호출이 세 번째 선택지를 좁힙니다. 마지막에 성공했는지 실패했는지만 보면, 그 과정에서 어떤 선택이 일을 살렸는지 알기 어렵습니다.

제가 이 논문에서 가장 흥미롭게 본 부분은 바로 그 지점이었습니다. 긴 도구 사용에서는 행동 자체보다 행동 전의 고르기가 어렵다는 것인데, 이 말은 들으면 쉬워 보이지만 막상 학습으로 옮기면 까다롭습니다. 에이전트가 고를 수 있는 다음 호출은 많은데, 로그에는 그중 실제로 고른 하나만 남기 때문입니다. 그렇다면 고르지 않은 선택은 어떻게 가르칠 수 있을까요. 이 질문이 논문 전체를 끌고 갑니다.

마지막에 맞았다고 매번 잘한 게 아니다

긴 도구 사용 과제를 상상해보면 구조가 금방 드러납니다. 에이전트는 검색을 부르고, 문서를 읽고, 파일을 정리하고, 계산기를 두드리고, 다시 검색으로 돌아옵니다. 호출 하나가 과제 상태를 바꾸고, 바뀐 상태가 다음 결정을 조건 짓죠. 열 번 스무 번 이어지는 과정에서 처음 몇 번의 선택이 나중에 큰 차이를 만듭니다.

그런데 최종 성공이라는 보상은 이 과정을 통째로 뭉뚱그립니다. 성공했으면 전부 잘한 것처럼 보이고, 실패했으면 전부 잘못한 것처럼 보이죠. 길게 이어진 상호작용 기록 위에서는 어느 단계의 공로를 누구에게 돌려야 할지 흐릿해집니다. 논문이 말하는 약한 신용 할당(weak credit assignment)이 바로 이 현상인데, 말 자체는 낯설어도 내용은 익숙합니다. 시험 마지막 점수만 보고 일주일 치 공부 중에서 어느 날의 선택이 점수를 만들었는지 묻는 것과 비슷하니까요.

여기서는 조금 조심해서 읽을 필요가 있습니다. 최종 보상이 쓸모없다는 이야기가 아니기 때문입니다. 최종 성공은 과제가 요구한 것을 끝까지 해냈는지 보여주는 정직한 신호죠. 다만 그 신호 하나만으로는 다음에 무엇을 다르게 해야 할지 알려주지 못합니다. 성공한 기록 안에도 서툰 호출이 섞여 있을 수 있고, 실패한 기록 안에도 잘 고른 호출이 들어 있을 수 있는데, 마지막 점수는 그 둘을 구분해주지 않습니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 성공한 궤적만 모아서 흉내 내면 에이전트가 나아질까요. 어느 정도는 그렇습니다. 그런데 성공한 궤적 안의 어설픈 선택까지 함께 따라 배우면, 에이전트는 운 좋은 기록을 정답인 줄 알고 외우게 되죠. 저는 이 대목이 논문의 출발점이라고 봅니다. 마지막 점수를 부정하는 게 아니라, 마지막 점수만으로는 고르는 법을 가르치기 어렵다는 것을 인정하는 일인데, 이 인정이 있어야 다음 이야기가 시작되지 않을까요.

매 단계를 채점하고 싶지만 사람이 매번 볼 수는 없죠

그렇다면 각 단계를 따로 채점하면 되지 않을까. 이런 생각이 자연스럽게 이어집니다. 단계별 보상은 어느 호출이 도움이 됐는지 바로 짚어줄 수 있으니까요. 실제로 많은 연구가 그 방향을 시도했습니다. 중간 결정을 보고 잘했는지 말해주는 신호를 따로 만드는 것이죠.

문제는 그다음입니다. 누가 그 점수를 매기느냐는 것인데, 선택지가 셋 정도로 좁혀집니다. 사람이 직접 보거나, 언어 모델에게 심사를 맡기거나, 같은 자리에서 여러 번 굴려보며 앞날을 어림하는 것인데, 어느 쪽도 공짜가 아닙니다. 사람이 매번 보면 정확도는 올라가도 속도와 비용이 감당되지 않고, 언어 모델에게 맡기면 빠르지만 판단이 흔들리거나 자기 취향으로 기울 수 있죠. 같은 장면에서 여러 앞날을 굴려보는 방식은 원리적으로 솔직하지만, 긴 도구 사용에서는 한 번 굴리는 데도 호출과 대기가 길게 이어집니다.

월요일 아침에 서류 검토 일을 떠올려보자. 열 페이지짜리 보고서가 스무 건 쌓여 있는데, 매 문장마다 팀장이 옆에서 점수를 매겨준다고 생각해보죠. 정확도는 높아질지 몰라도 일은 앞으로 나가지 않습니다. 에이전트의 단계별 보상도 같은 처지인데, 매 호출마다 비싼 심사를 붙이면 학습은 느려지고 운영은 무거워집니다. 그래서 연구자들은 싼 값에 그럴듯한 단계 점수를 얻는 법을 찾게 됩니다.

저는 여기서 멈칫했습니다. 단계 점수가 정확하지 않으면 오히려 독이 될 수 있기 때문입니다. 어설픈 심사가 서툰 호출을 칭찬하면 에이전트는 잘못된 습관을 더 빨리 굳히죠. 점수를 촘촘히 주는 것과 점수를 믿을 만하게 주는 것은 다른 일인데, 둘을 함께 잡기가 어렵습니다. 그렇다면 실행 전에 다음 선택의 가치를 어림하는 별도의 눈을 만드는 편이 낫지 않을까요. 논문은 이 갈림길에서 후자를 택합니다.

행동하기 전에 한 번 골라보는 일

논문이 제안하는 방법은 이름부터 태도가 분명합니다. CITA라는 이름 아래에 깔린 생각은, 에이전트가 도구를 움직이기 전에 가능한 다음 호출의 긴 호흡 가치를 어림해야 한다는 것입니다. 지금 문맥에서 이 호출을 고르면 마지막 성공 쪽으로 얼마나 가까워지는지를 미리 견주는 것이죠.

표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 다음 호출을 고르는 일은 단순 분류가 아니기 때문인데, 같은 호출이라도 문맥에 따라 뜻이 달라집니다. 일곱 번째 단계에서 부른 검색과 열일곱 번째 단계에서 부른 검색은 이름만 같을 뿐 역할이 다릅니다. 앞에서는 방향을 잡는 호출이고, 뒤에서는 빠진 조각을 메우는 호출이죠. 그래서 가치를 묻는 질문도 호출 이름이 아니라 호출과 문맥의 짝을 향합니다. 지금 이 자리에서 이 호출이냐는 것이죠.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 최종 보상만 보고 배우는 방식에서는 에이전트가 행동하고 나서야 평가받는데, CITA에서는 행동하기 전에 한 번 고르는 장면이 생깁니다. 순서가 바뀌면 학습의 성격도 바뀌는데, 지나간 기록을 외우는 공부에서 다음 장면을 고르는 공부로 옮겨가기 때문입니다. 생각해보면 사람도 중요한 결정을 앞두고는 손을 멈추고 앞날을 그려봅니다. 계약서에 서명하기 전에 조항을 다시 읽고, 전화를 걸기 전에 할 말을 정리하죠. 에이전트에게도 그런 한 박자를 가르치자는 제안인데, 저는 이 비유가 논문의 태도를 잘 보여준다고 봅니다.

여기서 한 가지 오해를 미리 걷어둘 필요가 있습니다. 실행 전에 어림한다는 말이 매번 느리게 고민하라는 뜻은 아니기 때문입니다. 평소에는 가볍게 고르고, 어려운 고비에서 그 가벼운 눈이 방향을 잡아주면 됩니다. 이 눈이 정확하면 에이전트는 불필요한 호출을 덜 돌고, 한 번 고른 호출에 더 오래 기대어 갈 수 있죠. 그렇다면 그 눈은 어떻게 만드느냐는 질문이 남는데, 다음 장면이 바로 그 제작 과정입니다.

이건 다음 행동을 맞히는 기계가 아니다

CITA를 처음 들으면 흔히 드는 생각이 있습니다. 다음에 올 도구 호출을 맞히는 예측기를 하나 더 붙인 것 아닌가 하는 의심이죠. 로그를 보고 다음 호출을 잘 맞히면 에이전트도 잘 움직일 것 같으니까요. 그런데 논문이 겨냥하는 것은 그 예측과 조금 다릅니다.

다음 호출 맞히기는 지난 기록에서 자주 나온 선택을 따라 합니다. 자주 고른 호출이 좋은 호출일 때가 많지만, 항상 그런 것은 아니죠. 사람들이 자주 여는 메뉴가 그날 필요한 메뉴와 다를 때가 있듯이, 기록의 빈도와 지금의 가치는 다른 질문입니다. 논문이 묻는 것은 무엇이 자주 나왔느냐가 아니라 무엇이 마지막 성공을 도울 가능성이 크냐는 것입니다. 빈도의 공부가 아니라 가치의 공부죠.

또 하나 헷갈리는 지점은 reranking과의 관계인데, 표를 다시 정렬하는 장치를 하나 얹으면 되는 것 아닌가 하는 생각입니다. 겉보기에는 비슷하지만 바라보는 시간이 다릅니다. 눈앞의 답을 고르는 reranking은 지금의 적절함을 묻고, 논문의 비교 추론 모델은 지금의 선택이 먼 성공과 어떻게 이어지는지를 묻습니다. 한 걸음 앞이 아니라 여러 걸음 뒤를 내다본다는 차이가 있는데, 긴 도구 사용에서는 그 차이가 생각보다 큽니다. 눈앞에서 매끄러운 호출이 다섯 걸음 뒤를 막을 때가 있기 때문입니다.

저는 이 구분이 실무적으로도 도움이 된다고 봅니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 예측기 하나를 얹었다는 설명과, 고르기 전에 가치를 견주는 눈을 따로 배웠다는 설명은 겉보기 숫자가 비슷해도 운영에서 전혀 다르게 읽힙니다. 전자는 기록을 더 잘 외우는 쪽이고, 후자는 기록에 없는 선택까지 견주는 쪽이니까요. 그렇다면 기록에 없는 선택은 어디에서 데려올까요.

보지 못한 선택지를 어떻게 가르칠까

논문이 가르치는 대상은 비교 추론 모델(Comparative Inference Model)이라는 작은 판단자입니다. 하는 일은 하나로 모입니다. 지금 문맥이 주어졌을 때, 가능한 다음 도구 호출이 최종 성공을 도울 가능성을 어림하는 것이죠. 에이전트 본체가 아니라 그 옆에서 고르기를 돕는 눈이라고 생각하면 가깝습니다.

여기서 재미있는 질문이 생깁니다. 보지 못한 선택의 가치를 어떻게 가르치느냐는 것인데, 로그에는 실제로 고른 호출 하나만 남기 때문입니다. 같은 자리에서 다른 호출을 골랐으면 어땠을지는 기록에 없습니다. 이 빈칸을 메우기 위해 논문은 세 가지 신호를 한 쌍으로 묶습니다. 관찰된 행동과 베이지안 도구 그래프 시뮬레이터, 그리고 언어 모델의 비교가 그것인데, 각각이 서로의 빈틈을 메우는 모양입니다.

관찰된 행동은 현실의 바닥입니다. 실제로 에이전트가 무엇을 골랐고 그 뒤에 일이 어떻게 흘렀는지를 보여주죠. 다만 현실만으로는 대안을 만들 수 없는데, 그래서 시뮬레이터가 필요합니다. 도구 사이의 관계를 그래프로 어림해두면, 같은 자리에서 다른 호출을 골랐을 때의 앞날을 흉내 내어볼 수 있기 때문입니다. 물론 흉내는 어디까지나 근사인데, 그래서 세 번째 신호인 언어 모델의 비교가 들어옵니다. 두 앞날을 나란히 놓고 어느 쪽이 성공 쪽으로 더 자연스럽게 이어지는지를 읽어주는 것이죠.

이 과정을 요리 연습에 비유해볼 수 있습니다. 실제 주방 기록만 보면 그날 만든 한 가지 맛밖에 모릅니다. 재료 궁합 표가 있으면 다른 양념을 넣었을 때의 맛을 어림할 수 있고, 옆에서 맛을 본 동료가 두 완성본 중 어느 쪽이 손님 입맛에 가까운지 말해줄 수 있죠. 세 신호를 묶으면 한 번의 실제 경험에서 여러 비교 공부를 뽑아낼 수 있는데, 논문이 쌍으로 묶는다는 표현을 쓰는 이유가 여기에 있습니다. 같은 문맥, 다른 선택이라는 한 쌍이 있어야 고르기가 배우기 때문입니다.

로그에는 간 길이 하나만 남는다

같은 문맥에서의 대안 비교가 왜 필요한지는 로그의 성질을 보면 더 분명해집니다. 기록된 궤적에는 그때 실제로 간 호출 하나만 남습니다. 가지 않은 길은 적히지 않죠. 등산로로 치면 정상에 오른 한 팀의 발자국만 있고, 옆 능선으로 갔으면 어땠을지는 지도에 없습니다.

그래서 단순히 성공한 궤적을 따라 배우면 에이전트는 간 길만 외웁니다. 안 간 길의 가치를 물을 방법이 없기 때문입니다. 이건 데이터가 부족해서가 아니라 데이터의 모양 때문인데, 같은 자리에서 두 선택을 나란히 본 적이 없으니 우열을 가르칠 수 없는 것이죠. 비교 학습에는 비교 가능한 쌍이 필요한데, 로그는 처음부터 쌍이 아니라 단수로 적힙니다.

여기서 시뮬레이터와 언어 모델 비교가 하는 일이 갈라집니다. 시뮬레이터는 안 간 길의 앞날을 어림해서 쌍의 반쪽을 만들어주고, 언어 모델 비교는 두 앞날 중 어느 쪽이 성공에 가까운지를 읽어줍니다. (참고로 시뮬레이터를 베이지안 그래프 형태로 둔 것은 도구 사이의 관계를 확률로 다루겠다는 뜻인데, 정해진 순서표보다 불확실한 현장에 가깝게 두려는 선택으로 읽힙니다.) 이렇게 만든 쌍을 모으면, 비교 추론 모델은 같은 문맥에서 어느 호출이 더 나은지를 가리는 법을 배웁니다.

저는 이 대목에서 논문의 순서 감각이 좋다고 봤습니다. 부족한 것을 더 많은 로그로 메우려 하지 않고, 한 번의 문맥에서 더 많은 비교를 뽑아내는 쪽을 택했기 때문입니다. 로그를 쌓는 일은 현장에서 비싸고 느린데, 같은 자리에서의 대안 생각을 보태면 학습 한 번당 얻는 정보가 늘어납니다. 다만 여기서 조심할 점도 생깁니다. 시뮬레이터의 어림이 어긋나거나 언어 모델의 비교가 기울면, 그 빗나감이 그대로 가르침이 되기 때문입니다. 쌍을 만드는 장치가 좋아야 고르는 눈도 좋아진다는 것인데, 이 의존성이 논문의 다음 시험을 읽을 때의 관전 포인트가 됩니다.

세 개 시험장에서 여러 모델로 돌리면 무슨 일이 생길까

논문은 세 개의 도구 사용 평가 묶음과 여러 기반 언어 모델에 걸쳐 CITA를 시험합니다. 하나의 시험장에서만 잘 되는지가 아니라, 과제 묶음을 바꾸고 에이전트의 몸통이 되는 모델을 바꾸어도 모양이 유지되는지를 본 것이죠. 저는 이 선택이 마음에 들었습니다. 도구 사용은 과제 성격과 기반 모델 성향에 따라 결과가 쉽게 흔들리기 때문에, 한 조합에서의 성공만으로는 말을 아껴야 하니까요.

결과는 방향이 한결같습니다. 도구 선택을 재는 Tool F1과 과제 성공이 함께 좋아졌는데, 이 짝이 함께 움직였다는 점이 눈에 띕니다. 도구만 그럴듯하게 고르고 과제는 못 끝내는 경우도 있을 수 있고, 반대로 운 좋게 과제는 풀었는데 도구 선택은 어설픈 경우도 있을 수 있죠. 그런데 논문이 전하는 그림은 두 지표가 같은 쪽을 향합니다. 고르기가 나아지면서 끝까지 해내는 일도 늘었다는 것인데, 실행 전에 견주는 눈이 헛돌지 않았다는 뜻으로 읽힙니다.

여기서 한 걸음 더 들어간 분석도 있습니다. 비교 추론 모델이 단계별 가치 어림을 실제로 잘 배웠는지를 들여다본 것인데, 단순히 마지막 성공률이 올랐으니 중간도 잘했겠지 하고 넘기지 않은 것이죠. 비교 상황에서 어느 호출이 더 성공 쪽에 가까운지를 가리는 정확도를 따로 본 셈인데, 저는 이런 확인을 좋아합니다. 마지막 점수만 좋아지고 중간 판단은 그대로라면, 그 개선이 어디에서 왔는지 말하기 어렵기 때문입니다.

그렇다면 이 결과를 어디까지 믿어야 할까요. 저는 절반은 기쁘게, 절반은 유보적으로 읽습니다. 여러 시험장과 여러 몸통에서 같은 방향이 나왔다는 것은 우연한 과적합만으로 설명하기 어렵습니다. 반면 시험장에 없던 도구 관계나 현장의 노이즈 앞에서도 같은 눈이 통할지는 아직 모릅니다. 시뮬레이터가 잘 어림하던 관계가 현장에서는 조금씩 어긋날 수 있고, 언어 모델의 비교도 과제 말이 바뀌면 감각이 달라질 수 있기 때문입니다. 그래서 다음 질문은 자연스럽게 운영 쪽으로 넘어갑니다. 시험장에서 배운 눈을 현장에 올리면 무엇이 달라질까요.

실제 시스템에 올리면 계산은 어디에서 늘고 어디에서 줄까

실제 시스템 관점에서 보면 관심은 정확도에서 비용으로 옮겨갑니다. 비교 추론 모델을 하나 더 두면 추론 한 번의 계산은 늘어납니다. 다음 호출을 고를 때마다 그 호출들의 가치를 어림해야 하니까요. 이 추가 계산이 아깝지 않으려면 다른 곳에서 더 큰 절약이 있어야 합니다.

절약이 생기는 자리는 의외로 분명합니다. 잘못 고른 호출이 부르는 연쇄 비용인데, 서툰 검색 한 번이 문서 읽기 세 번을 낳고, 어긋난 파일 쓰기 한 번이 복구 호출 다섯 번을 낳습니다. 긴 도구 사용에서는 한 번의 오선택이 뒤쪽 호출을 줄줄이 늘리죠. 실행 전에 고르는 눈이 이런 헛걸음을 몇 번만 막아줘도 전체 호출 수는 줄어듭니다. 가벼운 판단을 앞에 두어 무거운 되돌아감을 뒤에서 덜어내는 구조인데, 저는 이 교환이 성립할 때가 많다고 봅니다.

배포 형태를 떠올려보자. 밤사이 수백 건의 조사 일을 처리하는 배치 라인이 있다고 해보죠. 각 건마다 에이전트가 열 번 넘게 도구를 부르는데, 중간에 길을 잃으면 제한을 넘겨 중단되거나 사람이 다시 봐야 합니다. 비교 추론 모델이 앞에 서면 호출마다 작은 판단이 붙지만, 중단과 재시도가 줄면 전체 처리량과 대기 시간은 오히려 좋아질 수 있습니다. 물론 판단 모델 자체가 느리면 이야기가 달라지는데, 그래서 이 눈을 얼마나 가볍게 만들지, 캐시를 어디에 둘지, 어려운 고비에서만 깊게 볼지 같은 운영 결정이 따라옵니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 같은 연산량이 같은 하드웨어 비용을 뜻하지는 않기 때문입니다. 시뮬레이터를 돌리는 비용과 언어 모델을 한 번 더 부르는 비용, 메모리와 대역폭의 부담은 서로 다른 모양으로 옵니다. 논문이 말하는 개선이 현장에서도 같은 값으로 남으려면, 무엇을 재었을 때 좋아진 것인지를 함께 물어야 합니다. 호출 수, 지연, 동시 처리, 메모리와 대역폭 같은 조건이 바뀌면 교환의 셈도 바뀌죠. 저는 그래서 이 방법을 쓸 때는 정확도 그래프 옆에 운영 그래프를 나란히 두라고 권하고 싶습니다. 고르는 눈이 좋아졌다는 말과, 그 눈을 켠 채로도 라인이 잘 돈다는 말은 다른 말이니까요.

그래서 다음에 제가 보고 싶은 장면

앞에서 미뤄둔 질문으로 돌아올 차례입니다. 보지 못한 선택을 가르치는 장치가 얼마나 믿을 만한가 하는 것인데, 논문의 답은 세 신호를 묶으면 길이 열린다는 쪽입니다. 저는 이 답에 대체로 동의하면서도, 다음 연구에서 더 보고 싶은 장면이 몇 개 있습니다.

먼저 시뮬레이터의 어림이 어긋날 때의 모습입니다. 도구 사이의 관계를 그래프로 잡아두면 매끄럽게 돌지만, 현장의 도구는 버전이 바뀌고 응답이 늦어지고 가끔은 말없이 형식이 바뀝니다. 그래프가 어제 관계로 오늘 앞날을 어림하면 빗나감이 생기죠. 그 빗나감이 비교 추론 모델에 어떻게 스며드는지, 그리고 빗나간 가르침을 스스로 알아채는 장치가 있는지를 보고 싶습니다. 어림은 쓸수록 편해지지만, 어림인 줄 잊으면 위험해지니까요.

다음은 언어 모델 비교의 기울기입니다. 두 앞날을 나란히 놓고 고르는 일은 말의 결을 타는데, 길게 설명된 앞날이 짧게 적힌 앞날보다 좋아 보이거나, 익숙한 도구 이름이 낯선 도구 이름보다 믿음직해 보일 수 있습니다. 이런 기울기가 비교 쌍에 스며들면, 에이전트는 성공에 가까운 선택이 아니라 말 잘 듣게 생긴 선택을 고르게 됩니다. 어떤 과제 말투에서는 공평하던 비교가 다른 말투에서는 기울지는 않는지, 저는 그 경계가 궁금합니다.

마지막으로 현장의 긴 호흡입니다. 세 개의 평가 묶음에서 본 개선이 수십 단계로 이어지는 실제 업무에서도 같은 모양으로 남을까요. 현장에서는 중간에 사람이 끼어들고, 도구가 막히고, 목표 자체가 바뀌기도 합니다. 그런 흔들림 속에서도 실행 전의 고르기가 계속 방향을 잡아주는지 보고 싶습니다. 시험장의 성공과 현장의 성공은 같은 단어를 쓰지만 다른 풍경을 가리킬 때가 있으니까요.

이 논문이 남기는 것은 그래서 수치보다 질문에 가깝습니다. 에이전트를 좋게 만든다는 것은 답을 잘 말하게 하는 것을 넘어, 다음 행동을 고르기 전에 앞날을 견주는 법을 가르치는 일이기도 하다는 것인데, 저는 이 전환이 마음에 듭니다. 그렇다면 사람의 역할은 무엇일까요. 에이전트가 스스로 고르는 법을 배울수록, 어떤 앞날을 좋은 앞날이라고 부를지를 정하는 일은 더 분명히 사람의 몫으로 남을 것 같습니다.