묻는 것도 실력이다, CLEAT가 가르쳐준 질문의 가치

오늘 다룰 논문은 CLEAT: Learning Value-Guided Clarification for Interactive Agents입니다. arXiv에 2610.12655번으로 공개된 연구인데요. 이 연구가 내세우는 주장은 한 문장으로 정리되는데, 에이전트는 묻는 행위 자체가 아니라 묻고 나서 답을 이용해 결정을 실제로 개선할 때만 질문해야 하며, 그 가치는 같은 상황에서 묻는 경우와 그냥 진행하는 경우를 나란히 굴려봐야 알 수 있다는 것입니다. 원문 링크는 제목 아래에 걸어 두었습니다.

사실 제목만 보면 또 하나의 질문 생성 기법처럼 보이지만, 논문을 펼치면 질문을 잘 만드는 방법이 아니라 질문할지 말지를 가리는 방법이 나옵니다. 그래서 저는 읽는 내내 고개를 끄덕이면서도 계속 반문하게 됐습니다. 우리는 왜 에이전트에게 묻는 법은 가르치면서, 묻지 않는 법은 가르치지 않았을까 하고요.

왜 저는 이 논문을 끝까지 읽었을까

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

저는 평소에 에이전트 데모를 볼 때마다 비슷한 장면에서 멈칫하는데, 에이전트가 사용자 요청을 받자마자 너무 빨리 일을 시작하거나 반대로 너무 사소한 것까지 물어보면서 시간을 끌 때입니다. 여행 일정을 짜 달라고 했는데 날짜도 인원도 예산도 정해지지 않은 채 비행기부터 검색하는 에이전트, 그리고 출발지가 국내인지 해외인지조차 확인하지 않고 묻지도 않는 에이전트를 본 적이 있습니다. 그렇다면 여러분은 어느 쪽이 더 답답하신가요.

제가 이 논문을 끝까지 읽은 이유는 그 답답함을 수치나 규칙이 아니라 학습 문제로 바꿨기 때문입니다. CLEAT는 질문을 예의나 안전장치로 취급하지 않고, 질문을 하나의 행동으로 보고 그 행동이 작업 성과를 얼마나 올려주는지로만 판단합니다. 질문이 성과로 이어지면 남기고, 그렇지 않으면 버리는데, 생각해보면 사람도 비슷하게 배웁니다. 신입 시절에는 뭐든 물어보지만, 일을 익히면 물을 것과 그냥 진행할 것을 가리게 되니까요.

여기서 제가 가장 흥미롭게 본 부분은 질문의 가치를 정책과 분리하지 않았다는 점입니다. 질문이 좋은지 나쁜지는 에이전트가 답을 얼마나 잘 쓰느냐에 따라 달라지는데, 아무리 좋은 질문을 해도 답을 무시하고 원래 하던 대로 하면 소용이 없기 때문입니다. 반대로 평범한 질문이라도 답을 결정에 잘 녹이면 성과가 오릅니다. 그래서 이 논문은 질문을 고르는 정책과 질문의 가치를 매기는 장치를 따로 놀게 두지 않고 함께 학습시킵니다.

에이전트가 묻지 않아서 실패할 때가 있다

여러 사람이 함께 일하다 보면, 말 한마디만 했어도 오해가 풀렸을 순간이 있습니다. 에이전트도 이와 같은데, 사용자가 목표나 제약을 다 말하지 않은 채 일을 시키는 경우가 생각보다 많기 때문입니다.

논문이 출발점으로 삼은 장면이 바로 이 지점입니다. 언어 모델 에이전트는 복잡한 작업을 수행하는 능력은 좋아졌지만, 사용자가 말하지 않은 목표와 제약을 맞추는 일에는 여전히 약합니다. 이를 논문은 대화형 의도 정렬이라는 말로 부르는데, 거창하게 들리지만 내용은 단순합니다. 사용자가 생략한 부분을 에이전트가 알아서 채우지 말고, 필요하면 물어서 채우라는 것입니다.

그런데 여기서 재미있는 질문이 생깁니다. 왜 에이전트는 물을 때가 있는데도 묻지 않을까요. 제가 현장에서 본 이유는 크게 세 가지였는데, 첫째는 에이전트가 자신의 불확실성을 모른다는 점입니다. 겉보기에는 요청이 그럴듯해 보이니 그냥 진행합니다. 둘째는 질문이 비용이라고 학습된 경우로, 빨리 답을 내야 칭찬을 받으니 묻는 쪽으로 기울지 않습니다. 셋째는 물어도 답을 쓸 줄 모르기 때문인데, 질문하고 답을 받아도 다음 행동이 바뀌지 않으면 질문은 그냥 왕복 시간만 늘리는 셈이 됩니다.

이런 배경에서 보면 CLEAT의 문제의식은 꽤 현실적입니다. 묻는 능력을 키우는 것만으로는 부족하고, 묻는 선택이 성과로 이어지는 고리를 만들어야 한다는 것입니다. 저는 이 대목에서 저희가 새로운 AI 구조를 볼 때 쓰는 기준을 떠올렸습니다. 벤치마크 숫자만 보지 않고 실제로 무엇이 바뀌었고 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보는데요. 이 논문은 질문 횟수가 아니라 질문 뒤에 바뀌는 결정에 시선을 둡니다.

묻는다고 다 좋아지는 것은 아니죠

그렇다면 무조건 많이 물으면 해결될까요. 그렇지 않다는 것은 누구나 경험으로 알고 있죠. 너무 자주 묻는 에이전트는 사용자를 지치게 하고, 너무 안 묻는 에이전트는 엉뚱한 결과를 내놓기 때문입니다.

이 논문이 던지는 지적도 같은 방향으로, 질문은 답을 더 좋은 결정으로 바꿀 수 있을 때만 쓸모가 있다는 것이죠. 이 문장은 짧지만 applied system 관점에서 보면 꽤 매섭습니다. 질문에는 왕복 지연이 있고 사용자 주의라는 예산이 들며, 대화가 길어질수록 이후 추론 비용도 늘어나기 때문입니다. 그래서 질문을 공짜라고 가정하면 설계가 쉽게 망가집니다.

제가 여기서 조금 의심했던 부분은 기준을 어디에 두느냐입니다. 사람이 보기에는 당연히 물어야 할 것 같은데, 에이전트 입장에서는 그냥 진행해도 점수가 잘 나오는 경우가 있습니다. 반면 사람이 보기에는 사소하지만, 에이전트에게는 답 하나가 전체 계획을 바꾸는 경우도 있습니다. 결국 질문의 좋고 나쁨을 사람의 직감으로 정하면 어긋나기 쉬우니, 에이전트의 현재 실력에 비춰서 지금 이 정책이라면 묻는 게 남는지를 따져야 합니다.

논문은 이 생각을 residual query value라는 개념으로 정리합니다. 우리말로 옮기면 질문의 남은 가치 정도인데요. 지금 정책대로 그냥 진행했을 때와, 지금 물어보고 답을 받아 진행했을 때의 작업 효용 차이를 말합니다. 같은 에이전트라도 실력이 바뀌면 이 값도 바뀌는데, 초보일 때는 질문이 큰 도움이 되지만 숙련된 뒤에는 같은 질문이 별 도움이 안 될 수도 있기 때문입니다. 그래서 가치는 한 번 정해두는 상수가 아니라 정책과 함께 움직이는 값이 됩니다.

그래서 가치를 먼저 계산하자는 제안이 나옵니다

표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 질문의 가치를 말로 정의하는 것은 쉽지만, 학습 신호로 만드는 것은 다른 일이니까요.

CLEAT가 제안한 구조는 두 개의 축으로 이뤄져 있습니다. 하나는 일을 직접 하는 작업 정책(task policy)이고, 다른 하나는 질문의 가치를 예측하는 컨트롤러(controller)입니다. 작업 정책은 질문을 고르고 답을 받아 행동하며, 컨트롤러는 지금 대화 상태에서 물어보는 게 남는지를 예측합니다. 두 모듈은 같은 상호작용 결과에서 배우는데요. 따로 만든 점수를 가져다 쓰는 것이 아니라, 에이전트가 실제로 부딪혀 얻은 성과에서 라벨을 뽑아냅니다.

이 차이는 생각보다 중요합니다. 외부에서 만든 좋은 질문 데이터만 모아서 학습하면, 에이전트는 그럴듯한 질문을 흉내 내는 쪽으로 기울기 쉽습니다. 하지만 CLEAT는 묻는 경우와 진행하는 경우의 성과 차이를 직접 재서 학습하므로, 질문이 실제 성과로 증명될 때만 강화되는 것이죠. 그래서 질문 스타일이 아니라 질문의 쓰임이 남습니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이렇게 두 모듈을 두면 추론이 무거워지지 않을까 하는 점입니다. 논문이 보여주는 답은 의외로 가벼운데, 학습 때는 컨트롤러가 다음 데이터를 모으는 과정을 안내하지만 추론 때는 컨트롤러를 떼어내도 작업 정책 자체가 좋아져 있기 때문입니다. 이 대목은 뒤에서 숫자와 함께 다시 다루겠습니다.

같은 상황에서 두 갈래로 굴려보는 방법

그렇다면 가치는 어떻게 잴까요. 여기서 논문이 택한 답은 paired rollouts, 즉 같은 대화 기록에서 두 갈래를 함께 펴보는 방식인데요. 한쪽에서는 여기서 질문을 던지고 답을 받아 끝까지 일을 마치고, 다른 한쪽에서는 묻지 않고 현재 정책대로 바로 다음 행동으로 갑니다. 출발선이 같으니 두 결말의 차이는 질문이 만든 것으로 읽을 수 있죠. 저는 이 발상이 꽤 정직하다고 봅니다. 질문 문장이 예쁜지가 아니라 답을 받아 결말이 바뀌었는지만 묻기 때문입니다.

이 비교가 마음에 드는 이유는 통제가 분명하기 때문입니다. 에이전트 평가는 시작 조건이 조금만 달라져도 결과가 쉽게 흔들리는데, 같은 history에서 분기하면 적어도 출발선 논쟁은 줄어들기 때문입니다. 물론 답을 주는 상대방이나 사용자 시뮬레이터의 흔들림까지 없앨 수는 없습니다. 하지만 같은 상태에서 잰 차이만큼은 질문의 기여도로 읽을 여지가 훨씬 커지죠. 그래서 저는 이 측정을 일종의 공정거래라고 봅니다. 같은 선에서 묻기와 진행하기를 직접 겨루게 하니까요.

이 대결의 진행 순서는 생각보다 단순합니다. 에이전트가 어떤 대화 상태에 도착하면, 그 상태에서는 한 번은 질문을 던져봅니다. 그러면 사용자나 시뮬레이션된 사용자로부터 답이 돌아오고, 그 답을 포함한 채로 끝까지 일을 마칩니다. 반면 다른 한 번은 질문 없이 바로 다음 행동으로 가서 같은 끝까지 가는데요. 그런 뒤 두 궤적의 최종 작업 점수를 빼면 그 차이가 바로 질문의 잔여 가치가 됩니다. 이 값은 컨트롤러의 학습 라벨이 되고, 동시에 작업 정책이 어떤 질문을 골라야 하는지를 가르는 신호로 쓰입니다.

여기서 놓치기 쉬운 점이 하나 있습니다. 좋은 질문을 고르는 실력과 답을 받아 쓰는 실력은 서로 다른데, paired rollouts는 이 둘을 함께 보기 때문입니다. 질문이 좋아도 답을 못 쓰면 점수 차이가 안 나고, 반대로 답을 잘 써도 질문이 엉뚱하면 차이가 나지 않죠. 그래서 두 차이가 크게 나는 질문이야말로 지금 정책에게 진짜 필요한 질문이 됩니다. 저는 이 대목이 꽤 정직하다고 봅니다. 질문 문장을 예쁘게 만드는 데 점수를 주지 않고, 답을 받아 바뀐 결말에만 점수를 주니까요.

실제 구현을 떠올리면 다음 질문이 바로 생깁니다. 이 과정을 매번 돌리면 학습 비용이 두 배로 들지 않을까 하는 점입니다. 논문은 이 부담을 줄이기 위해 컨트롤러가 가치를 예측하게 두어, 가치가 있어 보이는 상태에서 데이터를 모으도록 안내합니다. 모든 상태에서 매번 두 갈래를 다 굴리는 대신 필요한 곳에만 굴리는 셈인데요. 그래서 데이터를 모으는 과정 자체가 점점 더 필요한 곳에 집중됩니다. 저는 이 절약이 꽤 현실적이라고 봅니다. 학습 때는 비싸게 재고, 그 결과를 예측기로 남겨 다음 수집을 아끼는 방식이니까요.

컨트롤러와 정책을 함께 키우면 무엇이 달라질까

앞에서 미뤄둔 이야기로 돌아올 차례인데, 왜 두 모듈을 함께 학습시켜야 할까요. 따로 학습시키면 안 될까요.

논문의 답은 함께 굴리는 과정에서 생기는 순환에 있습니다. 컨트롤러가 다음 rollout 수집을 안내하면, 작업 정책은 가치가 높은 상황에서 더 많은 질문 경험을 얻습니다. 그러면 작업 정책이 질문을 고르고 답을 쓰는 법을 배우고, 그 결과 질문의 가치 자체가 바뀝니다. 바뀐 가치는 다시 새로운 라벨이 되어 컨트롤러를 업데이트하는데, 한쪽이 앞서가면 다른 쪽이 따라오고 따라오면 다시 앞선 쪽의 기준이 바뀌는 구조입니다.

이 순환을 사람 일에 비유해볼 수 있습니다. 신입 매니저가 처음에는 모든 결정을 상사에게 물어봅니다. 상사는 그중 어떤 질문이 시간을 아꼈는지를 피드백합니다. 신입은 점점 물을 것과 스스로 정할 것을 가립니다. 그러면 상사의 피드백 기준도 바뀌어, 이제는 더 어려운 질문에만 시간을 쓰라고 합니다. CLEAT의 co-training도 이와 비슷합니다. 고정된 선생이 정답을 알려주는 것이 아니라, 함께 일하면서 기준이 같이 움직입니다.

제가 이 구조에서 눈여겨본 것은 라벨이 정책에 종속된다는 점입니다. residual query value는 절대적인 좋은 질문 점수가 아니라, 지금 정책이라면 이 질문이 남는지를 묻습니다. 그래서 정책이 약할 때는 기초적인 확인 질문도 가치가 크게 나옵니다. 정책이 강해지면 같은 확인 질문의 가치는 떨어지고, 더 어려운 분기에서만 질문 가치가 남습니다. 이런 적응성이 없으면 에이전트는 초보 시절에 배운 질문 습관을 고수한 채로 멈추기 쉽습니다.

물론 이런 순환 구조는 흔들릴 수도 있습니다. 컨트롤러가 잘못 안내하면 정책이 편향된 데이터만 보고, 정책이 편향되면 라벨도 같이 기울기 때문입니다. 논문이 paired rollouts라는 비교적 직접적인 측정을 쓰는 이유도 여기에 있다고 봅니다. (참고로 저는 이런 종류의 자기 참조 학습에서 측정 장치가 단순할수록 오래 간다고 봅니다. 복잡한 보상 모델을 끼우면 그 모델의 편향이 전체를 끌고 가기 때문입니다.) 같은 출발선에서 묻기와 진행하기를 직접 겨루는 방식은 적어도 무엇이 좋아졌는지를 성과 차이로 보여줍니다.

숫자보다 구조를 먼저 보고 싶었습니다

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 그래도 숫자를 먼저 짚고 가겠습니다. 실험은 Qwen3-4B를 바탕으로 네 가지 벤치마크에서 열 가지 평가 설정을 돌렸고, CLEAT는 열 개 설정 모두에서 평균 점수 1위를 기록했습니다.

그중 두 숫자는 paired comparison이 특히 잘 드러나는데, UserGym Travel에서는 가장 강한 기준선보다 13.2%포인트 높았고 IN3의 underspecification 판단 정확도에서는 6.5%포인트 높았습니다. 같은 모델에 같은 질문을 던져도 결과가 크게 달라질 수 있다는 것을 경험으로 알고 있죠. 그런데 여기서는 질문 방식이 아니라 질문 시점을 가리는 학습이 점수를 밀어 올렸습니다.

여행 계획 예시로 감을 잡아보겠습니다. 사용자가 3박 4일로 어딘가 다녀오고 싶다고만 말한 상태라고 해보겠습니다. 출발 도시, 예산 상한, 동행 인원, 이동 제약을 모르면 어떤 검색도 반쯤은 헛발질입니다. 그냥 진행하는 에이전트는 일단 인기 여행지를 골라 일정을 채울 텐데, 겉보기에는 일을 하는 것 같지만 나중에 예산이나 동행 조건이 드러나면 전체를 갈아엎어야 합니다. 반대로 묻는 에이전트는 예산과 동행 여부만 확인해도 검색 범위가 확 좁혀집니다. paired rollouts 관점에서 보면 이 확인 질문의 가치는 큽니다. 묻기와 안 묻기의 결말 차이가 크기 때문입니다.

반면 이미 조건이 충분한 상태에서는 같은 질문의 가치가 작아집니다. 출발지와 날짜와 예산이 다 정해진 뒤에 동행 여부를 한 번 더 묻는다고 결말이 크게 바뀌지는 않기 때문입니다. 컨트롤러는 이런 상태에서 묻지 않는 쪽을 예측하게 되므로, 평균 점수가 오른 것과 함께 질문의 선택성이 좋아졌다고 읽어야 합니다. 많이 물어서 오른 것이 아니라, 물을 때 물어서 오른 것입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 열 개 설정 모두에서 1위라는 결과는 분명 강하지만, Qwen3-4B라는 특정 규모에서의 결과입니다. 더 크거나 작은 모델, 다른 사용자 시뮬레이터, 다른 작업 분포에서도 같은 폭의 향상이 이어질지는 아직 모릅니다. 저는 그래서 이 숫자를 일반 법칙처럼 읽기보다, paired 비교에서 뽑은 가치 신호가 작업 정책까지 실제로 옮겨갔다는 증거로 읽는 쪽입니다.

컨트롤러를 떼어내도 실력이 남을까

논문에서 개인적으로 인상 깊었던 점은 ablation 결과입니다. 학습 때 함께 키운 작업 정책은 추론 때 컨트롤러를 떼어내도 좋아져 있다는 것이죠.

이게 왜 중요할까요. 실제 서비스에서는 추론 경로에 모듈 하나를 더 올리는 결정이 꽤 무겁기 때문입니다. 지연이 늘고, 서빙 그래프가 복잡해지며, 장애 지점도 하나 더 생깁니다. 그런데 co-training의 효과가 정책 안에 증류되어 남는다면, 학습 때만 비싸고 추론 때는 가벼운 구조가 됩니다. 저희가 새로운 AI 구조를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보는데요. 바로 그 기준으로 보면 이 ablation은 운영 쪽에 좋은 소식입니다.

그렇다면 왜 이런 일이 생길까요. 이유는 학습 데이터의 분포에 있습니다. 컨트롤러의 안내를 받으면서 정책은 가치가 높은 상태에서 질문 경험을 더 많이 쌓습니다. 어떤 질문이 통했고, 어떤 답이 결정을 바꿨는지를 반복해서 보기 때문입니다. 그러면 정책 자체가 좋은 질문을 고르고 답을 반영하는 쪽으로 이동합니다. 나중에 안내자를 떼어내도 몸에 밴 선택이 남는 셈인데, 생각해보면 사람도 비슷하게 배웁니다. 처음에는 코치가 옆에서 타이밍을 알려주지만, 익숙해지면 코치 없이도 타이밍을 압니다.

논문은 한 걸음 더 나아가 안내를 정책 변화에 맞춰 적응시키는 것이 추가 향상을 만든다고 보고합니다. 고정된 질문 규칙으로 데이터를 모으는 것이 아니라, 정책이 바뀌면 가치가 바뀌고 바뀐 가치로 다시 데이터를 모읍니다. 이 순환이 없으면 학습 후반에는 이미 배운 상태만 반복해서 보게 됩니다. 적응형 안내는 학습이 stale해지는 것을 막아줍니다.

물론 여기서도 과대해석은 경계해야 합니다. 컨트롤러 없이도 좋아졌다는 말이 컨트롤러가 쓸모없다는 뜻은 아닙니다. 학습 중 안내는 여전히 필요했고, 추론 때도 컨트롤러를 두면 추가로 얻을 수 있는 부분이 있을 수 있습니다. 다만 이 결과는 적어도 이런 해석을 허락합니다. CLEAT의 이득이 추론 시점의 복잡한 분기에만 있는 것이 아니라, 정책 자체의 선택과 반영 능력이 좋아진 데 있다는 것이죠.

실제 시스템에 올린다고 상상해 보면

좋은데, 이걸 어디에 올릴까요. 이 질문은 논문을 읽을 때마다 하게 됩니다.

먼저 떠오르는 곳은 여행, 일정, 구매처럼 조건이 자주 빠지는 작업입니다. 사용자가 다 말해주길 기대하기보다, 빠진 것을 확인하는 흐름이 자연스러운 영역이기 때문입니다. CLEAT처럼 가치를 재는 방식은 이런 곳에서 질문 예산을 관리하는 데 잘 맞습니다. 무작정 묻는 것이 아니라 결말을 바꾸는 질문에만 예산을 쓰니, 사용자 입장에서는 묻는 횟수가 줄고 묻는 타이밍은 더 정확해집니다.

다음으로 생각할 것은 사용자 시뮬레이터와 실제 사용자의 간격입니다. paired rollouts는 답을 주는 상대가 있어야 합니다. 학습 때는 시뮬레이션된 사용자로 답을 만들 수밖에 없는데, 실제 사용자는 시뮬레이터처럼 친절하지 않을 수 있습니다. 답을 짧게 주거나, 되묻거나, 엉뚱한 답을 줄 수도 있습니다. 그래서 시뮬레이터에서 크게 나온 질문 가치가 실제 대화에서도 같은 크기로 나올지는 따져봐야 합니다. 저는 이 간격이 CLEAT 같은 방법의 다음 관문이라고 봅니다.

서빙 관점에서도 볼 것이 남습니다. 학습 때는 두 갈래 전개를 돌리니 비용이 듭니다. 모든 상태에서 다 돌릴 수는 없고, 컨트롤러가 골라준 상태에서 돌리는 설계가 그래서 필요합니다. 추론 때는 정책만 써도 된다는 결과가 있으니 부담은 줄어듭니다. 그래도 질문을 던지는 순간에는 사용자 왕복이 생기므로, 질문 한 번의 지연과 사용자의 주의 비용을 감안한 예산 설계가 필요합니다. 가치가 0을 살짝 넘는다고 매번 물을 수는 없으니까요. 얼마 이상의 가치일 때 물을지에 대한 임계값, 그리고 한 대화에서 최대 몇 번까지 물을지에 대한 상한은 제품 정책으로 정해야 합니다.

또 하나는 답을 쓰는 능력입니다. CLEAT는 질문 선택과 답 반영을 함께 학습시킵니다. 그런데 실제 시스템에서는 답을 반영하는 쪽이 검색이나 도구 호출과 엮여 있습니다. 사용자가 예산 상한을 알려줬는데 검색 쿼리에 반영하지 못하면 질문 값어치가 사라지죠. 그래서 질문 정책을 고도화할 때 답 반영 경로까지 함께 점검해야 합니다. 질문-답-행동이 하나의 파이프라인으로 이어질 때만 잔여 가치가 실현됩니다.

그래서 저는 다음 질문이 더 궁금해졌습니다

그렇다면 이 흐름은 어디까지 이어질 수 있을까요. 논문을 덮으면서 남는 질문들을 정리해 보겠습니다.

첫째는 가치 예측의 일반화입니다. 학습 때 본 대화 분포에서는 컨트롤러가 잘 맞을 수 있습니다. 그런데 사용자가 새로운 방식으로 요청을 생략하거나, 작업 도구가 바뀌면 질문의 가치도 바뀝니다. 컨트롤러가 이런 분포 이동에도 따라갈 수 있을까요. co-training이 적응을 돕는다고는 하지만, 완전히 새로운 생략 패턴 앞에서는 다시 paired 측정이 필요할 수 있습니다. 저는 그래서 온라인으로 가치를 조금씩 고쳐 쓰는 흐름이 자연스럽다고 봅니다.

둘째는 질문의 종류입니다. 지금 구조는 물을지 말지를 가리는 데 강합니다. 그런데 무엇을 물을지, 어떻게 물을지의 문제도 남습니다. 같은 예산 정보를 물을 때도 묻는 방식에 따라 답의 질이 달라집니다. paired 신호가 질문 내용까지 세밀하게 가르칠 수 있을지, 아니면 시점 선택에 주로 영향을 줄지는 더 뜯어봐야 합니다. 작업 정책이 질문 내용을 함께 배우는 구조이긴 하지만, 내용의 질을 재는 해상도가 시점만큼 높을지는 아직 확신하기 어렵습니다.

셋째는 평가의 문제입니다. 최종 작업 점수로 질문 가치를 재는 방식은 분명하지만, 그 점수가 사용자의 진짜 만족과 같은지는 다른 문제입니다. 점수는 올랐는데 묻는 과정이 매끄럽지 않으면 체감은 다를 수 있습니다. 반대로 점수는 비슷해도 묻는 타이밍이 좋아서 신뢰가 오를 수도 있습니다. 그래서 다음 연구에서는 작업 성공률과 함께 질문 횟수, 대화 길이, 사용자 중단율 같은 과정을 함께 봐야 합니다.

이런 질문이 남는다는 것은 이 논문이 답을 덜 냈다는 뜻이 아닙니다. 오히려 물을 만한 다음 장면을 남겼다는 뜻에 가깝습니다. 질문을 잘 만드는 문제에서 질문할지 말지를 재는 문제로 시선을 옮겼고, 그 가치를 같은 출발선에서의 차이로 재는 방법을 보여줬기 때문입니다. 저는 앞으로 이런 부류의 연구를 볼 때 한 가지를 먼저 볼 생각입니다. 질문 횟수가 아니라 질문 뒤에 바뀐 결정이 보이는지, 그리고 그 선택이 정책 안에 남는지입니다.

에이전트가 더 오래 일하고 더 많은 도구와 연결될수록, 생략된 의도와 마주치는 횟수는 늘어날 것입니다. 그때마다 매번 묻거나 매번 밀어붙이는 에이전트는 어딘가에서 삐걱댈 수밖에 없습니다. 물을 때와 밀어붙일 때를 가리는 감각, 그 감각을 성과 차이에서 배우는 구조가 바로 이 논문이 남긴 장면입니다. 여러분이라면 지금 쓰는 에이전트에게 어떤 질문을 먼저 가르치시겠습니까.