💡 이번주 뉴스레터에는 이런 내용을 담았어요!

• 멀티턴 상황에서 명세 부족(Underspecification)으로 성능이 저하되는 현상인 Lost in Conversation 현상을 소개했습니다.
• Lost in Conversation 현상의 네 가지 원인을 정리했습니다.
• Lost in Conversation 현상을 해결하기 위한 업계와 학계의 방안을 정리했습니다.

안녕하세요, 에디터 영이입니다.

“이 CSV 파일 전처리해주는 코드 짜줘. pandas로, 결측치는 평균으로 채우고, 이상치는 IQR 기준으로 제거하고, 마지막엔 월별 추이를 라인 플롯으로 그려줘.” 이렇게 한 번에 지시하면 AI는 꽤 근사한 코드를 내놓습니다.

그런데 현실에서 우리는 보통 이렇게 일하지 않습니다. “이 데이터 좀 정리해줘”라고 우선 보내놓고, AI가 뭔가 만들어오면 그제야 “pandas로 작성 부탁해”, “결측치는 평균으로 채워줘”, “이상치 거르는 코드도 추가해줘”, “마지막에 그래프로 보여주면 좋을 것 같은데…”와 같이, 조건을 하나씩 붙여나갑니다. 직접 분석할 때도 데이터를 열어보기 전까지는 뭐가 필요한지 다 알기 어려우니, 지극히 자연스러운 작업 방식이라고 볼 수 있죠.

그런데 LLM은 이 방식을 그리 반기지 않습니다. 지시 사항을 한 번에 다 주는지 나눠서 주는지에 따라 LLM의 성능이 극명하게 차이가 나는데요. 이 현상을 Microsoft Research와 Salesforce Research가 함께 발표한 논문 <LLMs Get Lost In Multi-Turn Conversation> (Laban et al., 2025)을 통해 살펴보겠습니다.

논문에서는 대화의 턴 수가 많아서 LLM의 답변에 문제가 생기는 게 아니라, 정보가 한 번에 다 주어지지 않고 나눠서 들어올 때 문제가 생긴다는 점을 지적합니다. 연구진은 이렇게 문제 해결에 필요한 정보가 아직 다 갖춰지지 않은 상태를 명세 부족(Underspecification) 상태라고 부릅니다. 즉 명세 부족 상태가 몇 턴에 걸쳐 지속되느냐가 핵심이지, 대화 자체가 얼마냐 기냐는 부차적인 문제라는 뜻입니다.

연구진은 이를 검증하기 위해 샤딩(Sharding)이라는 실험 프레임워크를 설계했습니다. 원래 하나로 완성된 지시문을 여러 조각(샤드, Shard)으로 쪼갠 뒤, 대화 턴마다 한 조각씩 입력으로 주는 방식입니다.  

연구진은 LLM의 성능 저하를 두 요소로 분해했습니다. 하나는 역량(Aptitude), 즉 모델이 가장 잘했을 때 낼 수 있는 최고 성능입니다. 다른 하나는 신뢰성(Reliability)으로, 즉 같은 문제를 여러 번 풀었을 때 최선의 결과와 최악의 결과 사이의 격차입니다. 이 격차가 클수록 모델이 같은 문제를 풀어도 답이 매번 달라져 믿을 수 없는 상태가 됩니다.

싱글턴 설정에서는 역량이 높은 모델일수록 신뢰성도 높다는, 상식적으로 납득 가는 관계가 나타났습니다. GPT-4.1과 Gemini 2.5 Pro처럼 유능한 모델이 가장 안정적이었고, Llama 3.1-8B처럼 역량이 낮은 모델이 가장 불안정했습니다.

그런데 멀티턴 설정에서는 완전히 다른 그림이 펼쳐집니다. 역량 자체는 평균 16% 정도만 떨어졌는데, 신뢰성은 무려 112% 증가했습니다. 더 놀라운 부분은, 애초에 역량 차이가 컸던 모델이 멀티턴에서는 전부 비슷하게 불안정해진다는 점입니다. 아무리 똑똑한 모델이어도 정보가 나눠서 들어오는 순간 운에 좌우되는 상태로 빠져버립니다. 모델을 더 크게, 더 똑똑하게 만드는 것만으로는 문제를 해결할 수 없음을 시사하죠.

추론 모델이라고 다르지 않았습니다. DeepSeek-R1 등의 추론 모델로 실험했을 때도 비추론 모델과 비슷한 방식의 성능 저하가 발생하였습니다. 즉, 추가로 오래 생각한다고 해서 멀티턴 대화를 더 잘 다루게 되지는 않는다는 뜻이죠. 연구진은 그 이유로 흥미로운 단서를 하나 발견했습니다. 추론 모델이 비추론 모델보다 평균 33% 더 긴 답변을 생성하는 경향이 있었는데, 답변이 길어지는 것 자체가 오히려 독으로 작용하기 때문입니다.

왜 이런 현상이 발생할까요? 연구진은 실제 대화 로그를 하나하나 뜯어보면서 LLM에서 반복되는 네 가지 반복되는 패턴을 찾아냈습니다.

첫째, 성급한 답변 시도입니다. 대화 초반은 정보가 가장 부족한 시점인데, 이때 모델이 벌써 완결된 답을 내놓으려는 경향이 있습니다. 수학 문제와 코드 과제로 분석했더니, 대화의 첫 20% 구간에서 답을 시도한 경우 평균 성능이 30.9점에 그쳤는데, 마지막 20% 구간까지 기다렸다가 답한 경우에는 64.4점으로 두 배 넘게 높았습니다. 초반에 성급하게 낸 답에는 잘못된 가정이 들어가고, 이 가정이 이후 대화 내내 오염원 역할을 합니다.

둘째, 답변 부풀림(Answer Bloat) 현상입니다. 멀티턴 대화에서는 모델이 여러 번 답을 시도하게 되는데, 매번 이전 답을 기반으로 계속 덧붙이다 보니 최종 답이 점점 길어집니다. 코드 과제에서 정답에 도달한 경우만 놓고 비교해봐도, 멀티턴에서 나온 정답 코드는 싱글턴 정답보다 평균 27% 더 길었습니다. 문제가 다 풀렸는데도 결과물의 질은 더 떨어져 있는, 비효율적인 상태인 것이죠.

셋째, 중간 턴을 잊어버리는 현상입니다. 연구진은 여러 문서를 턴마다 하나씩 받아서 요약하는 과제로 이를 분석했습니다. 마지막 8번째 턴에 작성된 요약을 보면, 8번째 턴에 도입된 문서를 인용한 비율이 20%였던 반면, 2번째나 3번째 턴에 도입된 문서를 인용한 비율은 8%에 그쳤습니다. 즉 모델이 대화의 시작과 끝 부분은 잘 기억하면서 중간 부분은 상대적으로 소홀히 다루는 것입니다.

넷째, 과도하게 장황한 답변입니다. 답변이 길수록 성능이 떨어지는 경향이 여섯 과제 중 다섯 개에서 관찰됐습니다. 가장 짧게 답한 상위 20% 대화와 가장 길게 답한 상위 20% 대화를 비교하면, 짧게 답한 쪽이 10~50% 더 높은 성능을 보였습니다. 연구진은 답변이 길어질수록 그 안에 불필요한 가정이나 추측이 더 많이 섞여 들어가고, 이게 다음 턴에서 혼란을 일으킨다고 해석합니다.

네 가지 원인에는 공통점이 한 가지 있습니다. 전부 충분한 확신 없이 뭔가를 확정 지으려는 경향에서 비롯된다는 점입니다. 모델은 침묵하거나 되묻기보다는, 뭐라도 그럴듯한 답을 내놓는 쪽을 택합니다. 그리고 한번 낸 답에는 좀처럼 발을 빼지 못합니다.

그렇다면 모델 자체를 고치는 대신, 모델을 감싸고 있는 에이전트 시스템으로 제어할 수는 없을까요? LLM 모델은 그대로 두고 이 프레임워크가 지금까지 나온 이야기를 요약해서 다시 보여주기만 해도 문제가 풀리지 않을까 하는 아이디어입니다. 연구진은 이를 검증하기 위해 대화 마지막에 지금까지 나온 유저 발화를 전부 다시 정리해서 모델에게 마지막 기회를 주는 방식인 리캡(Recap)과 매 턴마다 새로운 정보를 줄 때 이전 정보까지 함께 반복해주는 방식인 스노우볼(Snowball) 방식을 사용했습니다. 둘 다 어느 정도 효과는 있었지만, 싱글턴이나 통합된 지시문(Concat) 수준에는 한참 못 미쳤습니다. 특히 리캡은 개입 시점이 대화 마지막이라는 점에서 실전에서는 쓰기 어려운 비현실적인 설정이기도 합니다. 언제 대화가 끝날지 실시간으로는 알 수 없으니까요. 스노우볼은 좀 더 현실적인 방식인데, 이걸로 얻을 수 있는 개선 폭은 15~20% 정도에 그쳤습니다.

실제로 이 문제를 해결하기 위해 업계와 학계가 모두 고군분투하고 있습니다. 최근 가장 널리 쓰이는 코딩 에이전트를 보면, 성급한 확정을 정면으로 막으려는 장치가 포함되어 있습니다. Claude Code에는 Ask User Question이라는 전용 툴이 있습니다. Claude가 작업을 진행하다가 사용자 입력이 필요하다고 판단하면 이 툴을 호출하고, 질문과 선택지를 생성합니다. 예를 들어 데이터 전처리 스크립트를 짜는 작업이라면, 결측치를 평균으로 채울지 중앙값으로 채울지, 이상치는 어떤 기준으로 걸러낼지, 시각화는 어떤 형태로 할지를 먼저 확인합니다. 추측으로 답을 밀어붙이는 대신, 사용자 의도에 맞는 판단을 내리기 위해 먼저 묻는 것입니다. Plan Mode에서는 아예 실제 실행하기 전에 계획을 세우고 사용자가 검토할 수 있는 단계를 따로 마련해 두기도 했습니다. Cursor도 비슷한 전략을 취합니다. Plan Mode에서는 요구사항을 이해하기 위해 Clarifying Question을 먼저 제시하고, 코드베이스를 통해 맥락을 확인한 후에야 실행 계획을 세우고 검토를 받습니다. 백그라운드에서 작업이 계속 진행되는 동안에도 중간중간 사용자에게 Clarifying Question을 묻는 워크플로우가 마련돼 있습니다.

한편으로는 LLM 모델 자체를 직접 개선하려는 시도도 이어지고 있습니다. <Found in Conversation: LLMs Teach Themselves to Close the Multi-Turn Gap> (Chen et al., 2026) 논문에서는 정보를 나눠서 줄 때 LLM의 성능이 저하되는 것은 LLM 자체에 능력이 없어서가 아니라, 이미 갖고 있는 능력을 대화 상황에서 제대로 꺼내 쓰지 못하기 때문이라고 주장합니다. 이 관찰을 바탕으로 연구진은 모델이 자기 자신을 가르치게 만드는 학습 방법을 설계했는데, 이를 View-Asymmetric Self-Distillation(VASD)이라고 부릅니다. 정보가 다 주어진 상태에서 잘 푸는 자기 자신을 선생님으로, 정보가 나눠져서 들어오는 상태에서 헤매는 자기 자신을 학생으로 놓고, 학생이 선생님의 확률 분포를 따라가도록 자기 증류(Self-distillation) 방식으로 학습하는 것입니다.

흥미로운 건, 두 방식 모두 결국 같은 곳을 가리키고 있다는 점입니다. “일단 뭐라도 답해라”는 LLM의 오래된 본능을 억제하는 것. 잘 대답하는 능력보다, 아직 대답할 때가 아니라는 걸 아는 능력이 더 어렵다는 사실을, AI도 이제 막 배우기 시작한 셈입니다.