기존의 LLM 벤치마크는 대부분 완전히 명시된 단일 턴 지시 사항을 기준으로 성능을 측정해 왔습니다. 하지만 현실에서 사용자는 보통 이런 식으로 말하지요: [‘이력서용 자기소개서 좀 써 줘’ 👉🏼 ‘참고로 AI 회사야. 분량은 3문단 정도!’]

이처럼 점진적으로 지시 사항이 정해지는 대화 방식인데, 기존 평가 방식은 이를 반영하지 못한다는 주장이지요. 이번 연구는 현실적인 대화 환경에서 LLM이 어떻게 반응하는지를 평가하기 위한 실험이었습니다.

 

Shard는 지시문을 찢어..🐻

 

연구의 핵심은 바로 Shard(샤드) 시스템입니다. ‘파편’이라는 뜻에서 알 수 있듯이, 지시 사항을 여러 ‘파편’으로 나누는 방식인데요. 대화 턴마다 샤드를 하나씩 제공하는 방식으로 다중 턴 환경을 시뮬레이션할 수 있습니다. AI가 연구진이 설정한 기준에 맞춰 정보를 샤드로 나누면, 마지막에 인간이 검수하는 방식으로 만들었습니다.

물론, 다중 턴이더라도 각 질문이나 요청 사항이 독립적으로 해석이 가능한 경우는 성능에 큰 영향을 미치지 않습니다. 이번 연구에서는 독립적인 하위 지시가 아닌, 하나의 지시를 여러 턴에 걸쳐 점진적으로 정의하는 대화 방식에 대한 LLM의 반응을 살펴보는데요. 지시문을 샤드로 나누는 원칙은 아래와 같습니다:

1. 
   정보 보존 (Information Preservation)
   - 원래 지시문을 완료하는 데 필요한 어떤 정보도 손실되지 않아야 한다.


2. 
   명확한 초기 의도 (Clear Initial Intent)
   - 첫 번째 샤드는 전체 요청 사항의 목적을 분명히 드러내야 한다.


3. 
   순서 비의존성 (Order Insensitive)
   - 첫 번째 샤드를 제외한 나머지들은 서로 참조하거나 순서에 의존하지 않아야 한다.
   - 순서를 바꿔도 동일한 정보를 전달해야 한다.


4. 
   최대 분할 (Maximal Sharding)
   - 가능한 한 많은 샤드를 만든다.
   - 각 샤드는 하나의 구체적 정보만 포함한다.


5. 
   최소한의 변형 (Minimal Transformation)
   - 각 샤드는 원본 지시문의 언어 스타일과 의미를 최대한 그대로 유지하며, 단순화하거나 해석하지 않는다.

 

LLM에 샤드를 하나씩 제공하는 방식으로 실험은 진행되는데요. LLM이 답변을 제공하지 못하고 되묻거나 모른다고 둘러대는 등 회피하는 경우, 샤드를 하나 더 제공합니다. 하지만 답변을 제공했다고 간주하는 경우, 답변을 평가합니다. 정답이면 대화 시뮬레이션은 종료됩니다. 오답이면 다시 처음으로 돌아가 샤드를 하나 더 제공하고 LLM의 반응을 살피는데요. 정확한 정답이나 오답이 나올 때까지 이 과정을 반복합니다. (전체 흐름을 파악하기 위한 단순화된 설명입니다. 정답 시도 여부와 상세한 평가 기준 등은 논문에서 확인하실 수 있습니다.)

연구진은 GPT-4.1, Claude 3.7 Sonnet, Gemini 2.5 Pro를 포함한 총 15개 LLM 모델에게 코딩, SQL 작성, API 호출, 수학 문제, 데이터 해석, 문서 요약 작업을 시켰습니다. 샤드 또한 다양한 방식으로 활용했는데요. 종류를 살펴볼까요?
 

• 
  FULL: 전체 지시 사항을 한 번에 제공 (기준 성능 측정)


• 
  SHARDED: 지시 사항을 샤드 단위로 나눠 턴마다 하나씩 공개


• 
  CONCAT: 샤드들을 bullet-point로 묶어 한 번에 제공


• 
  RECAP: SHARDED 후 마지막에 전체 지시 요약 제공 (잘못된 경로를 회복하는지 보기 위함)


• 
  SNOWBALL: 턴마다 이전 샤드들을 반복해서 누적 제공 (잘못된 경로를 회복하는지 보기 위함)

 

결과는 어땠을까요?🧪

정보를 나누어 다중 턴으로 제공하면 평균 성능이 39%나 떨어진다는 결과입니다. 여기서 말하는 ‘성능 저하’란 단일 턴에서는 정답을 잘 맞히던 모델이 멀티 턴에서는 같은 문제를 틀리는 현상을 말하는데요. 정보가 누락되거나 왜곡되지는 않았지만, 모델이 대화 흐름을 잘 따라가지 못해 생긴 ‘문맥 처리 실패’라고 볼 수 있습니다.

 

성능 저하 원인은 무엇일까?

 

도대체 왜 이런 일이 생기는 걸까요? 연구진은 네 가지 이유를 추정합니다.

 

• LLM은 문제를 너무 일찍 해결하려고 성급하게 시도한다.


• LLM은 이전에 스스로 시도한 잘못된 답변에 과도하게 의존하여, 응답이 점점 길고 비대해진다.


• LLM은 답변을 제공하기 직전 대화에 지나치게 영향을 받아, 중간에 나눈 대화 내용을 잊는 현상이 나타난다.


• LLM은 응답을 지나치게 장황하게 생성한다. 이에 따라 문제에 대한 불필요한 가정이 포함되고, 사용자 요청에 대한 집중력이 떨어진다.

 

프롬프팅 팁🍯

 

모든 연구가 그렇듯, 이번 연구 또한 한계가 존재합니다. 시뮬레이션 된 대화를 사용하기 때문에 실제로 발생하는 오류나 변수를 반영하지 못합니다. 또한 데이터 추출이나 코드 생성 등 정답이 명확한 작업만 실험해 창의적인 작업에서는 어떻게 반응하는지 정량적으로 알 수 없지요. 영어로 된 텍스트 중심 실험이라 다른 언어나 멀티모달에서는 또 어떨지 알 수 없습니다.

하지만 알아낸 정보에 기반해 적어도 지금, 좀 더 현명하게 프롬프팅 하는 방법을 유추할 수 있는데요!🕵🏻‍♂️

 

✔ 정보는 가능하면 한 번에 제공하자
👉🏼 이유는 이제 아시지요? 😉
 

 ✔ 정보를 나눠야 한다면, 각 질문이 문맥 없이도 이해되도록 나누자
👉🏼 지시대명사를 쓰거나 키워드를 생략하지 말고, 온전한 지시를 내리세요!
 

✔ 대화 초반에 전체 목적을 밝히자
👉🏼 처음과 마지막에 하는 말이 중요합니다. LLM이 맥락을 오해하지 않도록 초반부터 방향을 확실하게 잡아주세요.
 

✔ 중간에 준 조건은, 반복해서 리마인드해 주자
👉🏼 SNOWBALL 방식에서 성능이 향상된 결과를 함께 보셨지요? 무아지경에 빠진 LLM이 중간에 나눈 대화를 가볍게 여길 수 있으니 자주 리마인드해 주세요.
 

✔ 가능하다면, 새로운 대화를 시작하자
👉🏼 LLM이 이미 잘못된 방향으로 가고 있다면.. 과감하게 놔 주세요!
 

✔ 다시 시도할 때는, 지금까지의 지시를 요약해 달라고 요청하자
👉🏼 다시 지시하기 귀찮을 때 Tip: 지금까지 말한 걸 정리해 달라고 요청한 후, 정리된 프롬프트를 새로운 대화창에 붙여넣어 사용하세요!
 

✔ ‘간결하게’ 답하라고 미리 말하자
👉🏼 모델이 너무 장황하게 답하면서 판단력을 잃지 않도록, 미리 제한을 걸어주세요.

 

마치며

​프롬프팅 팁을 살펴보면, 마지막 세 개를 제외하고는 사람과 명확하게 소통하는 방법과 무척 유사합니다. 두괄식으로 명확하게, 목적을 밝히고 중요한 부분은 다시 한번 강조하는 방식이지요.

AI로 대체되거나 AI랑 일을 하거나, 둘 중 하나의 상황은 맞닥뜨릴 확률이 높아지고 있습니다. 한 번에 요구사항을 깔끔하게 전달하는 능력은 AI에도, 인간에게도 좋은 동료가 되기 위한 핵심 역량으로 보입니다.✨

 

참고: LLMs Get Lost in Multi-Turn Conversation (2025)

---

 

📮 먀. AI 뉴스레터 매주 단순 트렌드 나열이 아닌, '진짜' 인공지능 이야기를 받아보세요!

👉🏼 구독하기: https://mmmya.stibee.com/