피드백을 들을수록 길을 잃는 에이전트를 위한 제약 트리 탐색

Constraint Tree Exploration for Learning from Language Feedback라는, arXiv에 2610.09107 번호로 공개된 논문을 다룹니다. 이 연구는 사용자의 의도를 행동 공간 위에 놓인 숨은 제약으로 보고, 언어 피드백으로부터 배우는 과정을 가능한 영역을 좁혀가는 순수 탐색으로 다시 씁니다. 원문 논문으로 이어지는 연결은 제목 아래에 걸려 있습니다.

제가 이 논문에서 가장 흥미롭게 본 부분은 피드백을 듣는 태도를 바꾼 대목입니다. 보통은 피드백이 오면 그 말을 바로 믿고 행동을 고치는데, 여기서는 그 말을 일단 후보로 올려두고 직접 시험해본 뒤에야 받아들입니다. 그래서 겉으로 보면 돌아가는 것 같지만, 실제로는 훨씬 덜 헤매는 구조가 됩니다.

피드백을 듣는데 왜 자꾸 엉뚱한 곳으로 갈까

여러 사람이 함께 일하다 보면, 누군가의 말 한마디가 팀 전체의 방향을 바꾸기도 합니다. 그렇다면 AI 에이전트가 사람과 대화하면서 일할 때도 비슷한 일이 생길까요. 당연히 생깁니다. 그런데 사람 팀과 다른 점이 하나 있는데, 에이전트는 말의 뉘앙스를 흘려듣는 대신 곧이곧대로 받아들이는 쪽에 가깝다는 것입니다.

언어로 된 피드백은 대개 왜 실패했는지를 설명합니다. 가령 영화 추천을 해달라고 했는데 에이전트가 공포 영화를 내밀었다고 해보죠. 사용자가 "나는 잠들기 전에 보는 가벼운 영화를 원했어"라고 말하면, 그 말속에는 여러 가지 요구가 섞여 있습니다. 가벼울 것, 잠들기 전에 볼 수 있을 것, 어쩌면 상영 시간이 짧을 것까지요. 그런데 에이전트가 이 말을 "가벼운 영화는 곧 코미디" 정도로 성급하게 굳혀버리면 어떻게 될까요. 그다음부터는 코미디만 고집하면서 정작 사용자가 원한 늦은 밤의 짧은 영화를 놓치게 됩니다.

생각해보면 사람도 비슷하게 배웁니다. 한 번 지적을 받으면 그 말을 마음에 새기는데, 그 해석이 빗나가면 다음 시도도 함께 빗나갑니다. 에이전트에게는 이 문제가 더 아픕니다. 한 번 잘못 굳힌 해석이 유효한 답까지 통째로 지워버릴 수 있기 때문입니다. 그래서 이 논문은 질문을 이렇게 바꿉니다. 피드백 문장을 어떻게 믿을지가 아니라, 피드백을 어떻게 시험할지로 말이죠.

의도를 말의 뜻이 아니라 지켜야 할 조건으로 읽기

이 논문이 맨 처음에 하는 일은 사용자 의도를 다시 정의하는 것입니다. 의도를 "사용자가 머릿속으로 바라는 느낌"처럼 막연하게 두지 않고, 행동 공간 위에 놓인 숨은 제약들의 모음으로 봅니다. 행동 공간이란 에이전트가 내놓을 수 있는 모든 답의 자리이고, 제약이란 그중에서 어떤 답은 안 된다고 선을 긋는 조건입니다.

이렇게 보면 학습의 목표도 또렷해집니다. 사용자의 마음을 맞히는 일이 아니라, 숨은 선들을 하나씩 찾아내서 가능한 영역을 좁혀가는 일이 되기 때문입니다. 논문은 이 과정을 순수 탐색이라고 부르는데, 보상을 바로 챙기는 탐욕적인 선택이 아니라 어디까지가 허용되는지를 알아내는 데 집중한다는 뜻입니다.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 피드백을 점수로 바꾸는 관점에서는 "얼마나 맞았나"만 남지만, 제약으로 보는 관점에서는 "무엇을 어겼나"가 남기 때문입니다. 무엇이 어긋났는지를 알아야 다음 행동을 고칠 수 있는데, 점수만으로는 그 방향이 잘 안 보이거든요. 그래서 제약을 찾겠다는 이 첫 단추는 단순한 말장난이 아니라, 이후에 나오는 트리 구조 전체를 떠받치는 토대가 됩니다.

그렇다면 트리는 무엇을 붙잡고 있는 걸까

여기서 TRACE라는 방법이 등장합니다. 이름 그대로 제약 트리 탐색인데, 후보가 되는 제약들을 나무처럼 벌려 세운 뒤 하나씩 시험해보는 방식입니다. 가지 하나하나가 "아마도 이런 조건이 숨어 있지 않을까"라는 가설이고, 뿌리에서 잎으로 내려가면서 가설이 점점 구체적으로 다듬어집니다.

트리가 좋은 점은 기억을 구조화한다는 데 있습니다. 그냥 지금까지 들은 말을 차례로 쌓아두면, 어느 말이 어느 판단을 만들었는지 금방 뒤엉킵니다. 반면 트리에서는 어떤 정제(refinement)가 어디에서 갈라져 나왔는지가 그대로 남습니다. 그래서 나중에 "아, 그 해석은 틀렸네"라고 알게 되더라도, 그 가지만 잘라내면 되고 전체를 뒤집을 필요가 없습니다.

여기서 재미있는 질문이 생깁니다. 가지를 뻗는 일과 가지를 믿는 일은 어떻게 다를까요. 많은 방법은 이 둘을 구분하지 않습니다. 후보가 생기면 곧바로 믿고 다음 행동에 반영하죠. 그런데 TRACE는 후보를 만드는 일과 그 후보에 커밋하는 일을 일부러 떼어놓습니다. 후보는 가볍게 만들되, 믿는 것은 무겁게 가져가는 셈입니다. 이 차이는 생각보다 중요합니다. 가볍게 만들고 무겁게 믿어야, 잘못된 피드백 해석에 통째로 끌려가지 않기 때문입니다.

틀렸다는 말과 무엇이 틀렸다는 말은 다르다

TRACE에는 두 가지 작동 방식이 있는데, 그 차이를 가르는 말이 바로 반박(falsification)과 식별(identification)입니다. 처음 들으면 비슷해 보이지만, 실제로는 에이전트에게 요구하는 일이 꽤 다릅니다.

반박은 지금 시험 중인 제약 묶음에 어긋나는 일이 벌어졌다는 사실 자체를 잡아내는 일입니다. 가령 "밤에 보는 짧은 영화"라는 묶음을 시험 중인데, 사용자가 "이건 길어서 안 되겠어"라고 말하면 그 묶음이 어딘가 틀렸다는 신호가 됩니다. 그런데 정확히 어떤 가지가 문제인지는 아직 모릅니다. 길이에 대한 해석이 틀렸을 수도 있고, 밤이라는 시간대에 대한 해석이 틀렸을 수도 있죠.

반면 식별은 한 걸음 더 나아가서, 어긴 제약이 구체적으로 무엇인지 이름까지 짚는 일입니다. "길어서 안 된다"는 말이 길이 제약을 어겼다는 뜻이라고 짚어주는 것이죠. 말로 풀면 쉬워 보이지만, 시스템 관점에서 보면 이 차이는 상당히 큽니다. 반박만 있으면 "어딘가 틀렸다"는 것만 알 뿐 어디를 고쳐야 할지 모르지만, 식별까지 되면 다음에 뻗을 가지의 방향이 정해지기 때문입니다. 저는 여기서 조금 멈칫했습니다. 식별이 좋아 보이긴 한데, 그 식별 자체가 틀리면 오히려 더 깊이 헤매는 것 아닌가 싶었거든요. 그런데 논문이 뒤에서 보여주는 장치는 바로 이 걱정을 다루는 대목이라서, 끝까지 따라가 볼 만합니다.

의심스러운 해석은 직접 행동으로 시험해본다

이제 TRACE가 후보를 다루는 방식으로 들어갑니다. 순서는 의외로 단순한데, 그 단순함 뒤에 조심스러움이 숨어 있습니다.

먼저 후보 정제를 하나 집어듭니다. 가령 "상영 시간이 90분 이내여야 한다"는 식의 구체적인 조건이죠. 그러고 나서 그 조건을 만족하는 행동을 직접 만들어봅니다. 실제로 90분 이내의 가벼운 영화 몇 편을 골라 사용자에게 내미는 식입니다. 여기서 포인트는 머릿속으로만 따지지 않는다는 데 있습니다. 조건을 만족하는 답을 꺼내놓고, 그 답에 대한 반응을 받아보는 것이죠.

그러고 나서 피드백이 그 후보를 부정하는지를 반복해서 확인합니다. 한 번 부정적인 말이 나왔다고 바로 버리지 않고, 여러 번 시험하면서 모순이 반복되는지를 봅니다. 모순이 계속되면 그 가지는 잘라내고, 모순이 나오지 않으면 그때서야 정제를 받아들입니다. 일종의 유예 기간을 두는 셈인데, 이 대목이 TRACE 전체에서 제가 가장 마음에 든 부분입니다. 언어 피드백이라는 게 워낙 해석의 여지가 넓다 보니, 한 번의 말에 운명을 걸지 않겠다는 태도가 엉뚱하게 들리는 대신 꽤 현명하게 느껴졌거든요.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 시험용 행동을 얼마나 만들어야 할까요. 너무 적게 만들면 운에 기대게 되고, 너무 많이 만들면 사용자를 지치게 합니다. 그래서 뒤에 나오는 보장과 실험 숫자는 이 시험 횟수를 어떻게 다뤄야 하는지에 대한 답이라고 읽으면 됩니다.

후보가 많을수록 보장이 무거워지는 이유

여기서는 조금 조심해서 읽을 필요가 있습니다. 논문은 TRACE의 두 방식에 대해 커버리지 보장을 제시하는데, 말이 어려워 보이지만 뜻은 단순합니다. 일정 횟수만큼 시험하고 나면, 진짜로 지켜야 할 조건들을 놓치지 않고 품고 있을 확률이 높다는 것입니다.

반박 방식의 보장은 후보 집단의 크기, 논문에서 H로 부르는 값에 기대게 됩니다. 후보가 많을수록 그중 어딘가에 숨어 있는 정답을 건드릴 가능성이 커지지만, 동시에 잘못 건드릴 가능성도 커지니까 보장을 세게 말하기가 어려워집니다. 선택지가 열 개일 때와 만 개일 때, 같은 횟수의 시험으로 같은 확신을 갖기가 어렵다는 점을 떠올리면 됩니다.

그런데 식별 방식에서는 이 의존성을 바꿀 수 있다고 말합니다. 후보 전체의 크기가 아니라, 숨어 있는 진짜 제약의 개수 K와 빠진 제약을 끄집어낼 확률의 하한 p_ext로 보장을 다시 쓰는 것이죠. 식으로 쓰면 K를 p_ext로 나눈 값 정도가 됩니다. 저는 이 대목을 읽고 "아, 시야가 바뀌었구나" 싶었습니다. 전체 후보가 얼마나 넓은지가 아니라, 진짜로 찾아야 할 것이 몇 개이고 그것을 얼마나 잘 끄집어내는지가 보장를 좌우한다는 뜻이니까요.

다만 이 보장을 그대로 믿기 전에 조건을 봐야 합니다. p_ext가 낮으면, 즉 빠진 진짜 제약을 잘 끄집어내지 못하면 보장은 다시 무거워집니다. 식별이 정확하다는 전제 위에서만 가벼워지는 보장이라는 점은 분명히 짚고 넘어갈 필요가 있습니다. 논문도 이 점을 숨기지 않는데, 그래서 다음에 나오는 실험이 단순한 점수 자랑이 아니라 이 조건이 실제로 맞을 때 무슨 일이 벌어지는지를 보여주는 장면으로 읽힙니다.

스무 번 안에 일곱 할, 예순 번 안에 여덟 할을 넘긴 과정

이제 RecMovie라는 영화 추천 환경에서의 결과를 봅니다. 숫자 자체는 단순한데, 그 숫자가 만들어진 조건을 함께 봐야 합니다.

TRACE의 식별 방식은 평가받은 출력이 스무 개로 묶였을 때 최종 성공률이 73%에 닿았고, 예순 개까지 허용됐을 때 86%까지 올랐습니다. 같은 피드백과 같은 출력 개수 제한 아래에서, 프롬프트를 직접 다듬는 방식들은 스무 개 구간에서 아무리 좋아도 42%, 예순 개 구간에서 48%를 넘지 못했습니다. 일반 파일에만 남겼을 때와 달리 조건을 묶어둘 때처럼, 같은 재료를 썼는데도 결과가 크게 갈린 것이죠.

이 차이는 생각보다 중요합니다. 스무 개라는 제한은 실제 대화에서는 꽤 빡빡한 편입니다. 사용자에게 스무 번 물어보고 답을 고르는 것도 피곤한 일인데, 예순 번이면 더 말할 것도 없죠. 그런데 TRACE는 빡빡한 구간에서 이미 일곱 할을 넘겼고, 여유가 생기자 여덟 할 중반까지 올라갔습니다. 반면 직접 누적하는 방식은 기회를 더 줘도 오십 퍼센트 언저리에 머물렀습니다. 기회를 더 준다고 해결될 문제가 아니었다는 뜻입니다.

왜 이런 차이가 났을까요. 논문의 설명을 제 언어로 풀면, 직접 다듬는 방식은 피드백을 들을 때마다 곧바로 해석을 덮어쓰기 때문에 한 번의 오해가 오래 남습니다. 반면 TRACE는 후보를 트리에 올려두고 여러 번 시험한 뒤에야 받아들이니, 한 번의 오해가 가지 하나에서 멈춥니다. 그래서 같은 스무 번을 쓰더라도, TRACE의 스무 번은 시험의 스무 번이고 다른 방식의 스무 번은 수정의 스무 번이 됩니다. 같은 횟수처럼 보여도 쓰는 방식이 달랐던 것이죠.

흔들리는 말 앞에서도 쉽게 무너지지 않은 이유

여기까지 읽으면 이런 반문이 들 수 있습니다. 시험을 꼼꼼히 하는 건 알겠는데, 피드백 자체가 흔들리면 소용없는 것 아닐까요. 논문은 이 질문을 피하지 않고, 신원을 일부러 흐리는 통제 실험을 따로 둡니다. 피드백을 주는 주체의 식별 정보를 오염시켜서, 말이 엉키기 쉬운 상황을 일부러 만든 것이죠.

결과는 TRACE 쪽이 직접 쌓아가는 방식보다 더 잘 버텼다는 쪽으로 나왔습니다. 다만 단서가 붙는데, 반박을 감지하는 장치가 믿을 만하게 유지될 때 그렇다는 것입니다. 저는 이 단서가 오히려 솔직해서 좋았습니다. 흔들리는 말 앞에서도 무조건 강하다는 식으로 말하지 않고, "어긋남을 잡아내는 눈이 살아 있을 때 버틴다"고 선을 그었기 때문입니다.

이 대목은 운영 측면에서 보면 꽤 크게 다가옵니다. 실제 서비스에서는 사용자가 매번 또렷하게 말해주지 않습니다. 피곤해서 짧게 말하기도 하고, 앞말과 뒷말이 조금 어긋나기도 하죠. 그런 상황에서 매번 곧바로 덮어쓰면 시스템은 사용자의 기분에 따라 춤을 추게 됩니다. 반면 모순이 반복되는지를 보고 받아들이면, 한두 번의 흔들림은 가지치기 대상이 아니라 그냥 바람으로 흘려보낼 수 있습니다. 밤사이 공시가 늦게 도착해도 라인을 멈추지 않는 장치처럼, 말이 흔들리는 날에도 추천을 지켜주는 완충재가 생기는 셈입니다.

매번 처음부터 헤매지 않게 만드는 것은 무엇일까

앞에서 미뤄뒀던 질문으로 돌아올 차례입니다. 왜 직접 다듬는 방식은 기회를 더 줘도 제자리였을까요. 이 지점에서 논문이 말하는 것과 제가 느낀 것을 함께 놓아보겠습니다.

직접 다듬는 방식은 피드백을 해석하고 바로 반영합니다. 이 구조에서는 해석이 틀리면 그다음 행동도 틀어지고, 틀어진 행동에 대한 다음 피드백도 어긋난 맥락에서 읽히게 됩니다. 처음 단추가 잘못 끼워지면 셔츠 전체가 삐뚤어지는 것과 비슷한데, 문제는 단추를 다시 끼울 기회가 매번 와도 어디서부터 잘못됐는지를 모른다는 데 있습니다.

반면 트리 탐색은 잘못을 가두는 구조입니다. 후보가 트리의 가지로 남으니, 나중에 모순이 드러나면 그 가지만 잘라내면 됩니다. 뿌리까지 뽑을 필요가 없죠. 그래서 TRACE는 매번 처음부터 헤매지 않습니다. 헤맨 기록이 구조로 남아서, 다음 탐색이 같은 골목으로 다시 들어가지 않게 막아주기 때문입니다.

저희가 새로운 AI 구조를 볼 때도 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 이 논문의 경우, 바뀌는 것은 시험 횟수이고 생기는 비용은 사용자에게 더 보여줘야 한다는 부담입니다. 그런데 RecMovie 숫자는 그 비용을 내고도 남는다고 말합니다. 스무 번이라는 빡빡한 예산 안에서 이미 격차가 크게 벌어졌으니까요. 물론 이 대목에서는 예산의 정의도 함께 봐야 합니다. 여기서 예산은 평가받은 출력의 개수라서, 실제 대화 턴 수나 사용자의 피로도와 정확히 같은 말은 아닙니다. 그 간극을 메우는 일은 논문이 아니라 제품을 만드는 쪽에 남습니다.

그래서 다음에 지켜볼 것은 무엇일까

질문도 바뀌었습니다. 어떻게 하면 피드백을 잘 반영할까에서 어떻게 하면 피드백을 성급히 믿지 않을까로 말이죠. 이 전환이 TRACE라는 방법의 뼈대이고, 트리와 반복 시험과 반박이라는 장치는 그 뼈대에 살을 붙인 것입니다.

그렇다면 이 흐름은 어디에서 더 단단해질 수 있을까요. 제가 앞으로 보고 싶은 것은 세 가지입니다. 먼저 식별을 얼마나 믿을 수 있는지입니다. 보장이 가벼워지는 조건이 바로 빠진 제약을 잘 끄집어내는 능력에 걸려 있는데, 실제 대화에서는 이 능력이 모델의 해석 능력과 사용자의 말버릇에 함께 좌우됩니다. 반박 감지기가 흔들리면 버팀목도 함께 흔들린다는 앞선 단서와 같은 이야기죠.

다음으로 시험용 행동을 만드는 비용입니다. 조건을 만족하는 행동을 직접 만들어서 반응을 본다는 발상은 좋지만, 영화 추천처럼 보여주기 쉬운 영역이 아닌 곳에서는 시험 자체가 어려울 수 있습니다. 가령 되돌리기 어려운 행동이라면, 시험 한 번의 무게가 가볍지 않기 때문입니다.

마지막으로 트리가 커질 때의 관리입니다. 가지가 늘어날수록 기억은 풍부해지지만, 탐색도 길어집니다. 언제 가지를 치고 언제 깊이 들어갈지에 대한 운영 감각이 필요해지는데, 이 부분은 논문이 열어둔 다음 질문에 가깝습니다.

이 논문이 남기는 감각은 단순한 점수 이상입니다. 피드백을 잘 듣는다는 것이 말귀를 빨리 알아듣는 것이 아니라, 말의 후보를 붙잡아두고 행동으로 물어볼 줄 아는 일이라는 감각이죠. 다음에 에이전트가 사용자의 한마디에 곧바로 방향을 틀 때, 저는 이 트리를 떠올릴 것 같습니다. 지금 믿으려는 그 해석을 한 번만 더 시험해보면 어떨까 하고 말이죠. 그렇다면 사람의 역할은 무엇일까요. 아마도 무엇을 지킬지를 정해주는 일, 즉 정답이 아니라 선을 그어주는 일에 더 가까워질 것입니다.

(End of file - total 655 lines)