LLM은 왜 대화가 길어질수록 길을 잃을까?

작성자: 아이피렉스 특허법률사무소 김용덕 변리사

ChatGPT 같은 대화형 AI를 쓰다 보면 이상한 순간이 있다. 처음에는 꽤 정확하게 따라오던 모델이 조건을 하나씩 추가할수록 엉뚱한 방향으로 간다. 방금 정정한 내용을 다시 틀리기도 하고, 처음에 스스로 세운 가정을 끝까지 붙잡기도 한다. 대화 기록은 모두 남아 있는데도 마치 중요한 조건 몇 개를 놓친 것처럼 행동한다.

이 현상을 단순히 “컨텍스트가 길어져서 기억을 못 한다”라고 설명하면 핵심을 놓친다. Microsoft Research와 Salesforce Research의 연구진이 발표한 「LLMs Get Lost in Multi-Turn Conversation」은 같은 과제를 한 번에 완전하게 지시했을 때와 여러 대화 턴에 나누어 지시했을 때를 비교했다. 바뀐 것은 정보의 양이 아니라 정보가 공개되는 방식이었다.

결과는 꽤 선명했다. 평균 성능은 단일 턴 약 90점에서 멀티턴 약 65점으로 떨어졌다. 논문은 이를 평균 39%의 상대적 성능 하락으로 정리한다. 반면 모델이 잘 풀렸을 때의 잠재력을 나타내는 적성은 평균 16% 감소하는 데 그쳤고, 같은 문제를 반복했을 때 결과가 얼마나 흔들리는지를 보여주는 불신뢰성은 평균 112% 증가했다. 즉, “모델이 갑자기 바보가 됐다”기보다 “같은 능력을 안정적으로 꺼내 쓰지 못하게 됐다”는 쪽이 더 정확하다.

실제 사용자는 처음부터 요구사항을 완벽하게 정리해 입력하지 않는다. “보고서 하나 써줘”라고 시작한 뒤 다음 메시지에서 분량을 말하고, 그다음에는 표를 빼달라고 하고, 마지막에 독자와 목적을 덧붙이는 식이다. 하지만 기존의 많은 LLM 평가는 필요한 조건을 첫 프롬프트에 모두 넣어 둔 상태에서 모델을 평가한다. 이 논문은 바로 이 간극을 실험으로 분리했다.

연구진이 구분한 첫 번째 조건은 Fully-Specified다. 사용 목적, 제약 조건, 입력 데이터, 출력 형식이 첫 메시지에 모두 들어 있으므로 모델은 바로 최종 답을 만들어도 된다. 반대로 Underspecified 멀티턴에서는 첫 메시지에 큰 목적만 주어지고 세부 조건은 이후 턴에서 순차적으로 공개된다. 이때 모델은 아직 알 수 없는 부분을 비워 두거나 질문해야 하지만, 실제로는 빈칸을 추정해 너무 일찍 답을 완성하는 경우가 많았다.

중요한 점은 멀티턴이라는 형식 자체가 항상 나쁜 것은 아니라는 것이다. 번역처럼 각 턴의 결과를 독립적으로 이어 붙일 수 있는 과제에서는 성능 저하가 상대적으로 작았다. 반면 새로운 조건이 들어올 때마다 기존 코드, SQL, 계산식, 요약 전체를 다시 수정해야 하는 과제에서는 문제가 크게 나타났다. 결국 난점은 “앞선 대화 전체를 새 조건에 맞춰 다시 통합해야 하는가”에 있었다.

연구진은 완전한 지시문을 원자적인 정보 조각으로 나눈 뒤 첫 조각에는 상위 목적을, 나머지 조각에는 세부 조건을 넣었다. 사용자 시뮬레이터는 각 턴마다 아직 공개되지 않은 조건을 최대 하나씩 전달했고, 평가 대상 모델은 이러한 실험 구조를 모른 채 일반 사용자와 대화하듯 응답했다. 이 방식을 Sharded Conversation이라고 부른다.

모델의 응답은 질문, 보류, 토론, 거절, 가정에 따른 후보 제시, 실제 답변 시도 등으로 분류됐다. 모델이 답변을 시도하면 코드 실행, SQL 실행, 정확 일치, BLEU, 인용이 포함된 요약 점수 등 과제에 맞는 평가기로 채점했다. 오답이면 다음 조건이 공개되고, 정답이 나오거나 더 공개할 조건이 없으면 대화가 종료됐다.

비교 조건도 촘촘하게 설계됐다. FULL은 원래의 완전한 지시문을 첫 턴에 제공하는 기준 조건이다. SHARDED는 조건을 여러 턴에 나누어 공개한다. CONCAT은 SHARDED에서 나눈 문장을 다시 한 턴에 합쳐 제공해, 단순한 문장 재표현이나 정보 손실 때문인지 확인한다. RECAP은 SHARDED 대화의 마지막에 전체 조건을 다시 정리해 주고, SNOWBALL은 매 턴 지금까지의 조건을 누적해서 반복한다. 이 다섯 조건을 비교하면 “정보를 나누는 행위 자체”와 “여러 턴에 걸친 통합 실패”를 어느 정도 분리할 수 있다.

실험 범위는 한두 모델의 사례 수준이 아니다. 연구진은 코드 생성, 자연어를 SQL로 바꾸는 데이터베이스 과제, API 호출 생성, 초등 수학, 표를 문장으로 설명하는 과제, 여러 문서를 인용하며 요약하는 과제까지 여섯 종류를 사용했다. 과제별로 90~120개의 분할 지시문을 만들어 총 600개의 지시문을 구성했다.

비교 대상에는 GPT-4.1, GPT-4o, o3, Gemini 2.5 Pro와 Flash, Claude 3.7 Sonnet, DeepSeek-R1, Llama 계열, Phi-4, OLMo 2, Command-A 등 당시 대표 모델 15개가 포함됐다. 모델과 지시문, 대화 조건의 조합을 여러 번 반복하면서 전체 대화 수는 20만 건을 넘었다.

같은 문제를 반복한 이유도 중요하다. LLM은 확률적으로 문장을 생성하기 때문에 한 번의 성공이나 실패만으로 안정성을 판단하기 어렵다. 같은 문제를 여러 번 실행해야 평균 성능뿐 아니라 잘 풀렸을 때와 크게 실패했을 때의 격차도 볼 수 있다. 이 논문의 핵심은 바로 그 “격차”를 별도의 신뢰성 문제로 꺼내 보였다는 데 있다.

논문은 평균 성능만 보지 않고 적성(Aptitude)과 불신뢰성(Unreliability)을 따로 봤다. 적성은 반복 실행 중 상위 10% 수준의 성과를 뜻한다. 쉽게 말해 모델이 컨디션 좋게 문제를 풀었을 때 어디까지 해낼 수 있는지를 보여준다. 불신뢰성은 같은 지시문에 대한 상위 10%와 하위 10% 성과의 차이다. 이 값이 클수록 같은 요청이라도 대화 경로에 따라 결과가 크게 출렁인다.

모든 모델은 모든 과제에서 FULL보다 SHARDED에서 낮은 성능을 보였다. 평균 성능은 약 90에서 65로 25점 하락했고, 상대 기준으로 평균 39% 감소했다. 그런데 적성은 평균 16% 감소에 그쳤다. 반면 불신뢰성은 평균 112% 증가해 두 배 이상 커졌다. 한 지시문 안에서도 최선과 최악의 실행 사이에 평균 약 50점의 차이가 나타났다.

CONCAT 결과는 이 해석을 더 강하게 만든다. 분할된 조건을 다시 한 번에 합쳐 제공했을 때 성능은 FULL의 약 95.1% 수준을 유지했다. 즉, 문장을 잘게 나누면서 정보가 손실되었거나 표현이 바뀌었기 때문에 성능이 떨어졌다고 보기는 어렵다. 같은 정보를 여러 턴에 걸쳐 받아들여야 하는 상황에서 모델이 대화 상태를 통합하는 과정 자체가 문제였다.

그래서 이 논문의 메시지는 “최신 LLM도 멀티턴을 못 한다”가 아니다. 더 정확한 표현은 “잘할 수는 있지만, 그 능력을 매번 안정적으로 재현하지 못한다”다. 제품 관점에서는 최고 벤치마크 점수보다 동일한 요구사항을 서로 다른 순서와 대화 경로로 제시했을 때 결과가 얼마나 흔들리는지를 함께 봐야 한다.

코드와 수학 과제에서 첫 답변 시도가 대화 초반 20% 이내에 나온 경우 평균 점수는 30.9였다. 반대로 마지막 20% 구간까지 기다린 경우 평균 점수는 64.4였다. 아직 필요한 조건이 충분히 공개되지 않았는데도 모델이 먼저 해답을 만들면, 그 해답 안에 사용자에게서 듣지 않은 가정이 들어갈 가능성이 커진다.

LLM은 모르는 부분을 그대로 남겨 두기보다 문맥상 그럴듯한 값을 채워 답을 완성하려는 경향이 있다. 문제는 뒤에서 새로운 조건이 들어왔을 때다. 모델은 답 전체를 폐기하고 다시 계산하기보다 이미 만든 구조의 일부만 수정하는 경우가 많다. 그러면 초반의 잘못된 전제가 대화의 뼈대가 되고, 후속 수정이 그 위에 계속 쌓인다.

마지막 SHARDED 답변은 FULL이나 CONCAT 답변보다 20~300% 더 길어졌다. 정답만 놓고 봐도 코드 답변은 평균 27%, SQL 답변은 평균 14% 더 길었다. 연구진은 이를 Answer Bloat라고 부른다. 모델이 앞선 답을 지우고 새로 계산하기보다 예외와 보정 설명을 덧붙이는 방식으로 대응하기 때문이다.

장문 요약 과제에서는 여덟 번째 턴의 요약이 마지막 턴에 공개된 문서를 20% 인용한 반면, 두 번째와 세 번째 턴에 공개된 문서는 각각 8%만 인용했다. 대화의 시작과 끝에 있는 정보가 상대적으로 강하게 반영되고, 가운데 들어온 조건이 약해지는 현상이다. 연구진은 이를 Loss-in-Middle-Turns라고 이름 붙였다.

여섯 과제 중 다섯 과제에서 가장 짧은 응답 그룹이 가장 긴 응답 그룹보다 10~50% 높은 성능을 보였다. 초기 턴에서 긴 설명을 만들수록 사용자가 말하지 않은 가정과 임시 해결책이 늘어날 수 있고, 이후 턴에서는 이 내용이 새로운 입력의 일부가 된다. 멀티턴 상황에서는 초반에 장문의 답을 쏟아내는 능력보다 “아직 무엇을 모르는지”를 판단하고 짧은 확인 질문을 던지는 능력이 더 중요할 수 있다.

가장 쉬운 처방은 대화 내용을 다시 반복해 주는 것이다. RECAP처럼 마지막에 모든 조건을 다시 정리하면 SHARDED보다 성능이 개선됐다. 다만 실제 서비스에서는 사용자가 언제 마지막 조건을 말했는지 알기 어렵다. SNOWBALL처럼 매 턴 지금까지의 조건을 반복하면 성능 저하 폭의 약 15~20%를 완화했지만, 프롬프트가 빠르게 길어지고 FULL 수준까지 회복되지는 못했다.

생성의 무작위성을 낮추는 방법도 제한적이었다. 온도를 낮추면 단일 턴에서는 불신뢰성이 크게 줄었지만 멀티턴에서는 개선 폭이 작았다. 온도 0에서도 약 30%의 불신뢰성이 남았다. 대화는 한 턴의 작은 차이가 다음 턴의 입력 자체를 바꾸기 때문에, 단일 생성의 랜덤성을 줄이는 것만으로 누적 오차를 없애기 어렵다.

추론 계산을 더 쓰는 모델도 자동으로 해결하지 못했다. o3와 DeepSeek-R1 같은 추론 모델도 비추론 모델과 비슷한 멀티턴 성능 저하를 보였다. 연구진은 추론 모델이 평균적으로 더 긴 답변을 생성하는 경향을 지적한다. 답이 길어질수록 모델이 스스로 만든 가정도 많아지고, 다음 턴에서 사용자 요구와 모델의 추정을 구분하기 더 어려워질 수 있다.

이 결과를 제품 설계 관점에서 읽으면 방향이 꽤 분명해진다. 첫째, 필수 조건이 채워지기 전에는 완성 답변을 만들지 않는 최종 답변 게이트가 필요하다. 단순히 “모르면 질문하라”는 프롬프트가 아니라, 현재 상태에서 최종 생성을 허용할지 판단하는 제어 로직이 필요하다는 뜻이다.

둘째, 사용자 조건과 모델의 가정을 같은 대화 기록 안에 섞어 두지 않는 것이 중요하다. 사용자가 확정한 요구사항, 아직 미확정인 항목, 모델이 임시로 추정한 값, 이후 철회된 조건을 구조화된 상태로 구분해 저장해야 한다. 그래야 새 조건이 들어왔을 때 무엇을 유지하고 무엇을 폐기할지 판단할 수 있다.

셋째, 새 정보가 기존 가정과 충돌하는지 검증하고, 충돌한다면 관련 중간 결과와 답변 초안을 무효화하는 절차가 필요하다. 모델에게 “수정해줘”라고만 하면 기존 구조를 보존한 채 덧붙이는 Answer Bloat가 생길 수 있다. 필요한 경우에는 이전 답을 고치는 것이 아니라 검증된 조건만 가져와 새 추론 분기를 시작하는 편이 더 안정적이다.

넷째, 일정 시점마다 대화 전체를 요약하는 것보다 “검증된 사용자 조건만” 다시 완전 명시 지시문으로 재구성하는 방식이 유용할 수 있다. 턴 수, 토큰 수, 조건 충돌 횟수, 답변 수정 횟수 같은 신호를 이용해 재요약이나 재시작 시점을 정하는 방식도 제품 차원의 설계 포인트가 된다.

마지막으로 평가는 평균 정답률 하나로 끝나면 안 된다. 동일한 요구사항을 여러 정보 공개 순서로 반복 실행해 성능 분산, 가정 철회율, 오답 후 복구율, 최선과 최악의 격차를 함께 측정해야 한다. 이 논문이 말하는 신뢰성 문제는 결국 “한 번 잘하는가”가 아니라 “여러 경로에서도 안정적으로 잘하는가”의 문제다.

이 논문은 새로운 기반 모델 아키텍처를 제안했다기보다 대화형 AI의 취약점을 재현하고 계량화하는 평가 프레임워크와 신뢰성 지표를 제시한 연구에 가깝다. 따라서 제품이나 서비스 차원에서 기술적 차별화를 검토한다면 “LLM이 멀티턴을 잘 처리한다”는 추상적인 목표보다, 그 목표를 구현하는 구체적인 상태 관리 구조와 제어 절차가 더 중요하다.

예를 들어 현재 입력만으로 최종 답변을 만들어도 되는지 판단하는 미명시 조건 탐지, 확정 조건·미확정 조건·모델 가정·철회 조건을 분리해 저장하는 요구사항 원장, 새 발언과 기존 가정의 충돌을 탐지해 중간 산출물을 선택적으로 폐기하는 가정 무효화, 특정 조건에서 대화 상태를 완전 명시 프롬프트로 재구성하는 요약 트리거, 검증된 조건만 승계해 새 추론을 시작하는 대화 분기, 서로 다른 정보 공개 순서를 반복해 복구율과 변동성을 측정하는 신뢰성 평가 시스템 등이 기술 구성으로 구체화될 수 있다.

다만 “이전 대화를 요약한다”, “필요하면 질문한다”, “대화를 기억한다” 정도의 추상적인 아이디어만으로는 차별화가 쉽지 않다. 어떤 정보를 어떤 데이터 구조에 저장하는지, 미명시 상태를 어떤 신호로 판단하는지, 가정을 어떤 단위로 연결하고 무효화하는지, 최종 모델 호출을 언제 차단하거나 허용하는지, 그 결과 오류율·복구율·토큰 사용량·지연이 어떻게 달라지는지까지 구체화해야 기술적 특징과 효과를 설명하기 쉬워진다.

또한 이 논문은 2025년 5월 9일 공개됐다. 이후 관련 기술의 신규성·진보성을 검토할 때에는 단순한 Sharded Simulation, FULL·CONCAT·SHARDED 비교, RECAP·SNOWBALL 반복, 적성과 불신뢰성의 정의만으로 차별화를 주장하기 어려울 수 있다. 실제 권리화에서는 제품 고유의 상태 관리 구조, 충돌 검증 절차, 모델 라우팅, 자원 절감이나 안전성 제어 같은 추가 구성이 중요해진다.

일반 사용자에게도 적용할 수 있는 교훈이 있다. 첫 요청에서 모든 조건을 완벽하게 써야 한다는 뜻은 아니다. 오히려 조건이 덜 정해졌다면 모델이 임의로 채우지 못하도록 “정보가 부족하면 먼저 확인 질문을 해달라”고 명시하는 편이 낫다. 조건을 추가할 때는 기존 조건 중 무엇을 유지하고 무엇을 변경하거나 삭제하는지도 분명히 말하는 것이 좋다.

대화가 길어졌다면 중간에 한 번 “지금까지 내가 확정한 조건만 다시 정리하고, 네가 추정한 내용은 따로 표시해 달라”고 요청할 수 있다. 모델이 이미 잘못된 구조에 깊게 앵커링된 것 같다면 계속 수정시키는 대신, 확정된 조건만 새 대화에 한 번에 넣고 다시 시작하는 편이 더 안정적일 수 있다. 중요한 업무라면 같은 완전 명시 프롬프트를 새 대화에서 한 번 더 실행해 결과를 비교하는 것도 현실적인 검증 방법이다.

이 논문은 단일 턴 벤치마크가 높은 모델이라고 해서 실제 대화형 서비스에서도 같은 품질을 안정적으로 제공하는 것은 아니라는 점을 보여준다. 요구사항이 여러 턴에 걸쳐 공개되면 모델은 너무 일찍 답을 만들고, 자신의 가정을 사실처럼 유지하고, 중간 턴의 조건을 약하게 반영하고, 기존 답에 내용을 계속 덧붙이는 방식으로 흔들릴 수 있다.

그래서 다음 세대 대화형 AI의 경쟁력은 더 많은 지식이나 더 긴 답변만으로 결정되지 않을 가능성이 크다. 정보가 부족할 때 기다릴 수 있는 능력, 사용자 요구와 모델의 추정을 구분하는 능력, 새로운 조건이 들어오면 기존 판단을 철회하는 능력, 잘못된 경로에 들어갔을 때 검증된 상태만 가지고 다시 시작하는 능력이 제품 신뢰성의 핵심이 된다.