멀티턴 대화란? AI가 이전 말을 기억하는 방식과 문맥 관리

AI 공부 · LLM 이해 / 대화 설계

멀티턴(multi-turn)은 질문 한 번과 답변 한 번으로 끝내지 않고, 앞선 대화를 이어 받아 다음 요청을 처리하는 방식입니다. “내일 오전 7시에 알려줘” 다음에 “아니, 평일에만”이라고 말했을 때 무엇을 평일에만 하라는 건지 알 수 있어야 합니다. 핵심은 AI가 사람처럼 영구히 기억한다는 뜻이 아니라, 애플리케이션이 앞선 대화의 필요한 내용을 다음 요청에 연결한다는 점입니다.

그림은 일반적인 구현 흐름입니다. 서비스마다 대화 기록을 애플리케이션이 다시 보내거나, 서버가 관리하는 대화 식별자를 전달하는 방식이 다릅니다.

1. 싱글턴과 멀티턴은 어디서 갈리는가?

한 번의 독립적인 요청으로 답을 얻으면 싱글턴(single-turn)입니다. “오늘의 AI 뉴스 세 건을 각각 한 문장으로 요약해줘”가 그 예입니다. 다음 질문이 앞선 답변이나 조건을 가리키면 멀티턴이 됩니다. “두 번째 뉴스만 자세히 설명해줘”에서 두 번째가 무엇인지 알려면 이전의 뉴스 목록과 답변이 필요합니다.

순서	대화	이번 답변에 필요한 맥락
1	사용자: “알림 문장 세 개에서 일정을 찾아줘.”	알림 원문 세 개
2	AI: “병원 예약 1건, 납부 기한 1건을 찾았습니다.”	어떤 항목을 찾았는지 기록
3	사용자: “그중 병원 예약만 달력에 넣을 후보로 보여줘.”	‘그중’이 가리키는 앞선 결과와 원문

3번 문장만 새 요청으로 보내면 ‘그중’의 대상이 사라집니다. 반대로 1·2번을 함께 전달하거나 같은 대화의 상태를 이어 주면 모델이 지시 대상을 파악할 수 있습니다. 하지만 맥락을 받은 모델도 예약 날짜를 잘못 읽을 수 있으므로, 대화 연결과 사실 검증은 별개입니다.

2. AI는 이전 대화를 어떻게 ‘기억’하는가?

API로 만든 챗봇에서 흔한 방법은 사용자 발화와 모델 답변을 순서대로 저장한 다음, 새 발화와 함께 다시 전달하는 것입니다. Google의 Gemini generateContent 문서는 REST 요청의 contents에 이전 user·model 메시지를 넣는 멀티턴 예를 보여 줍니다. SDK의 채팅 인터페이스는 이 기록 관리를 대신할 수 있습니다.

다른 방법은 제공자가 앞선 응답을 가리키는 식별자를 받아 대화를 이어 주는 것입니다. OpenAI Responses API의 대화 상태 문서는 previous_response_id로 응답을 연결하는 예를 제시합니다. 어느 방법이든 설계자는 어떤 기록을 저장하고, 어느 사용자와 연결하고, 언제 지울지 결정해야 합니다. 챗봇 화면에 지난 메시지가 보인다는 사실만으로 모델에 그 메시지가 모두 전달됐다고 단정할 수 없습니다.

이것은 파인튜닝과 다릅니다. 대화 기록을 다음 요청의 문맥으로 넣는다고 모델의 가중치가 바뀌지는 않습니다. 새 채팅에서 같은 내용을 기억하게 하려면 별도 저장소에서 관련 정보를 꺼내 다시 제공하거나, 서비스가 지원하는 지속적 기억 기능을 사용해야 합니다. 모델 학습, 현재 대화의 문맥, 장기 저장된 사용자 정보는 서로 구분해야 합니다.

3. 앞선 답을 그대로 쌓으면 왜 문제가 생기는가?

멀티턴에서 새 요청은 이전의 지시·자료·답변 일부 또는 전부와 함께 처리될 수 있습니다. 대화가 길어질수록 입력 토큰이 늘고, 모델의 문맥 창 한도와 비용을 고려해야 합니다. OpenAI의 공식 안내는 이전 응답 ID로 연결해도 앞선 입력 토큰이 과금 계산에 포함될 수 있다고 설명합니다. 제공자·API·캐시 정책에 따라 실제 사용량은 달라지므로 응답의 사용량 값을 확인해야 합니다.

더 큰 문제는 오래된 조건과 새 조건의 충돌입니다. “매일 오전 7시” 뒤에 “평일 오전 8시로 바꿔줘”라고 했는데 두 조건을 모두 살아 있는 지시로 취급하면 일정이 두 개 생길 수 있습니다. “앞선 결정: 평일 오전 8시, 주말 발송 없음”처럼 현재 유효한 상태를 구조화해 남겨야 합니다. 단순 요약으로 날짜나 부정 조건이 빠질 수 있으므로, 요약은 원본을 완벽히 대체하는 기억 장치가 아닙니다.

턴	사용자의 말	갱신해야 할 현재 상태
1	“매일 오전 7시에 보내줘.”	발송일: 매일 / 시간: 07:00
2	“주말은 빼줘.”	발송일: 월~금 / 시간: 07:00
3	“한 시간 늦춰줘.”	발송일: 월~금 / 시간: 08:00

세 번째 발화의 “한 시간”은 바로 앞의 07:00에 적용해야 합니다. 첫 턴의 “매일”을 다시 살려서는 안 됩니다. 실제 일정 프로그램이라면 최종 상태를 화면에 보여 준 뒤 예약 작업을 한 번만 수정해야 합니다. 대화 로그는 왜 값이 바뀌었는지 설명하는 이력이고, 현재 상태는 실행할 설정입니다. 두 역할을 하나의 긴 문자열에 맡기면 충돌이 생겼을 때 원인을 찾기 어렵습니다.

대화가 길어지면 관련 없는 과거 내용이 새 답에 섞일 수도 있습니다. 해결책은 무조건 전체 기록을 넣거나 무조건 가장 최근 몇 개만 남기는 식의 고정 규칙이 아닙니다. 작업에 필요한 사실·확정된 변경·원문 근거를 고르고, 더 이상 유효하지 않은 조건은 상태에서 제거하되 감사가 필요하다면 변경 이력에 별도로 보관합니다.

4. 생활 알림 정리기에 멀티턴을 붙인다면

멍냥잇 생활 알림 정리기의 공개 버전은 알림 문장을 한 번 처리해 사람이 검토할 후보를 만드는 방식입니다. 연속 대화로 일정을 수정하는 멀티턴 기능은 구현하지 않았습니다. 아래는 이 도구를 확장할 때의 설계 예시입니다.

1. 원본을 보존합니다. 알림의 실제 문장, 출처, 날짜를 따로 저장하고 AI가 만든 설명으로 원문을 덮어쓰지 않습니다.
2. 후속 지시를 해석합니다. “두 번째는 취소해줘”라고 하면 먼저 두 번째가 어떤 후보인지 식별하고, 여러 후보가 있으면 확인 질문을 합니다.
3. 현재 상태를 명시합니다. 후보마다 원문 ID, 종류, 날짜, 검토 상태를 둡니다. AI의 자연어 답변만을 데이터베이스처럼 쓰지 않습니다.
4. 실행 전에 검증합니다. “취소해줘”가 후보 삭제인지 실제 예약 취소인지 다릅니다. 외부 서비스에 변경을 보내기 전 대상·권한·결과를 사용자에게 보여 주고 확인합니다.

예를 들어 “병원 예약만 보여줘”는 필터링 요청이지만 “병원 예약을 취소해줘”는 실제 세계의 약속을 바꾸는 요청일 수 있습니다. 모델이 앞 문장을 이해했다고 해서 외부 시스템을 바로 실행하게 만들면 안 됩니다. 멀티턴 설계에는 문맥 연결뿐 아니라 상태 전이와 실행 권한의 경계가 필요합니다.

5. 직접 확인하는 세 턴 실습

아래 문장은 모두 가상 사례입니다. 같은 채팅에서 순서대로 넣고, 마지막 질문을 새 채팅에도 따로 넣어 비교해 보세요. 모델별·서비스별 결과를 보장하는 시험은 아니며, 어떤 정보가 전달돼야 하는지 관찰하는 연습입니다.

1. “가상 알림 A: 11월 6일 오전 10시 병원 방문. 가상 알림 B: 11월 5일까지 진료 예약을 취소하면 수수료가 없습니다. 방문 일정 후보만 골라줘.”
2. “방금 고른 일정의 날짜와 시간을 한 줄로 적어줘.”
3. “아니, 취소 기한도 방문 일정에 넣은 것 같아. 원문 A·B를 다시 확인하고, 방문일과 취소 기한을 구분해줘.”

정상적인 구분은 A의 11월 6일 오전 10시가 방문 일정이고, B의 11월 5일은 취소 조건의 기한이라는 것입니다. 세 번째 턴에서 AI가 앞선 답을 고치더라도, 그 자체가 학습된 것은 아닙니다. 같은 오류가 다음 대화에서 반복될 수 있습니다. 특히 “그 일정” 같은 지시어를 새 채팅에서 알아맞힌다면 실제로 맥락이 전달됐는지 확인해야 합니다. 모델이 추측으로 그럴듯하게 답했을 수도 있습니다.

6. 멀티턴, RAG, 장기 기억은 어떻게 다른가?

개념	목적	예시	주의할 점
멀티턴 문맥	이어지는 질문의 지시 대상을 파악	“두 번째 알림만”	이전 기록이 실제 요청에 포함되는가?
RAG·검색	대화 밖의 자료에서 필요한 근거를 찾음	예약 변경 정책 문서 검색	검색한 문서가 현재 유효한가?
장기 기억	여러 세션에 걸쳐 저장한 정보를 재사용	사용자가 허용한 브리핑 시간	동의, 보존 기간, 수정·삭제 경로가 있는가?

세 개를 함께 쓸 수도 있습니다. 새 대화에서 저장된 선호 시간을 불러오고, 정책 문서를 검색한 뒤, 방금 받은 후속 질문과 결합하는 식입니다. 다만 모든 과거 대화와 문서를 모델에 늘 보내는 방식은 비용과 개인정보 노출 범위를 키웁니다. 필요한 정보만 골라 보내고, 원본과 수정 이력을 구분하며, 민감한 내용의 저장·삭제 기준을 정해야 합니다.

7. 멀티턴 챗봇을 만들 때 확인할 체크포인트

1. 대화 식별: 서로 다른 사용자의 기록이 섞이지 않도록 세션과 사용자 경계를 명확히 합니다.
2. 기록 전달: 이전 사용자 발화뿐 아니라 필요한 모델 답변과 도구 결과도 다음 턴에 이어지는지 확인합니다.
3. 정정 처리: 최신 지시가 예전 결정을 바꾸면 현재 상태를 갱신하고 충돌을 해소합니다.
4. 길이 관리: 문맥 창과 실제 토큰 사용량을 확인하고, 오래된 원문을 줄일 때 날짜·대상·부정 조건을 잃지 않도록 시험합니다.
5. 검증·권한: AI가 설명을 고치는 것과 달력·메일·예약을 실제 변경하는 것을 분리합니다.

멀티턴은 “AI가 나를 더 많이 학습한다”는 기능이 아닙니다. 이어지는 요청을 이해하도록 대화 상태를 관리하는 설계입니다. 이 구분을 알면 챗봇이 왜 어떤 말은 기억하고 어떤 말은 놓치는지, 긴 대화에서 무엇을 따로 저장·검증해야 하는지 판단할 수 있습니다. AI 공부 목록으로 돌아가기 →

확인한 공식 자료: Google Gemini API: 멀티턴 대화와 기록 전달 · OpenAI API: 대화 상태·이전 응답 연결·문맥 창 · OpenAI API: 메시지 역할과 멀티턴. 생활 알림 대화와 실습은 개념 설명을 위한 가상 사례입니다. 공개된 생활 알림 정리기에 멀티턴 기능을 구현·평가했다는 뜻이 아닙니다.