AI 정확도 16%→99.7%: Least-to-Most 프롬프팅 완벽 가이드

“분명 예제랑 똑같이 줬는데, 왜 조금만 길어지면 딴소리를 할까요?”

프롬프트 엔지니어링을 진지하게 파고든 개발자라면 누구나 한 번쯤 겪어봤을 좌절입니다. Chain-of-Thought(CoT)가 등장했을 때 우리는 환호했습니다. “드디어 AI가 논리적인 사고를 한다!”라고요. 하지만 그 기쁨은 오래가지 않았습니다. 학습된 예제보다 조금만 더 복잡한 문제, 전문 용어로 ‘Easy-to-Hard Generalization(쉬운 문제에서 어려운 문제로의 일반화)’ 상황을 마주하면 AI는 어김없이 환각(Hallucination)을 일으킵니다.

여러분의 프롬프트가 잘못된 게 아닙니다. ‘일하는 방식(Workflow)’이 빠져있었을 뿐입니다.

오늘 소개할 Least-to-Most Prompting(최소에서 최대로 프롬프팅)은 바로 이 지점을 파고듭니다. 구글 브레인(Google Brain) 팀이 ICLR 2023에서 발표한 이 기법은, 기존 CoT 방식에서 16% 정답률을 보이던 문제를 무려 99.7%까지 끌어올렸습니다. 도대체 어떤 마법을 부린 걸까요? 그 기술적 비밀을 낱낱이 파헤쳐 봅니다.

왜 Chain-of-Thought(CoT)는 실패하는가?

먼저 적을 알아야 합니다. CoT의 치명적인 약점은 ‘한 번에 너무 많은 연산을 처리하려 한다는 것’입니다. 논문에서는 이를 증명하기 위해 ‘마지막 글자 이어붙이기(Last-Letter Concatenation)’ 실험을 진행했습니다.

실험 A: 기호 조작 (Symbolic Manipulation)

쉬운 문제 (길이 4): “think, machine” → “ke” (think의 k + machine의 e). 이건 CoT도 잘합니다.

어려운 문제 (길이 12): “brightness, preparatory, intense, … (12개 단어)”

결과는 처참했습니다. 리스트 길이가 12개로 늘어나자, GPT-3(code-davinci-002) 기반의 CoT 정확도는 31.8%로 곤두박질쳤습니다. 예시(Few-shot)로 보여준 패턴보다 입력값이 길어지자 논리적 맥락을 놓쳐버린 것입니다.

반면, 오늘 소개할 Least-to-Most(L2M) 기법은 동일한 조건에서 74.0%의 정확도를 기록했습니다. 2배가 넘는 성능 차이입니다. 이 격차는 어디서 오는 걸까요?

해결의 열쇠: ‘분해’와 ‘순서’의 2단계 아키텍처

Least-to-Most 프롬프팅은 인간이 복잡한 문제를 해결하는 방식을 그대로 모방했습니다. 거대한 코끼리를 냉장고에 넣으려면? ‘썰어서 넣는다’는 농담처럼, 복잡한 문제도 ‘쪼개야’ 합니다. 논문은 이를 두 가지 명확한 단계로 정의합니다.

Phase 1: 문제 분해 (Decomposition)

AI에게 바로 정답을 요구하지 마세요. 대신 “이 문제를 풀기 위해 해결해야 할 하위 질문들이 뭐야?”라고 물으세요.

[예시: 에이미의 미끄럼틀]
Q: 에이미가 미끄럼틀 꼭대기까지 4분 걸려 올라가고, 1분 동안 내려옵니다. 미끄럼틀은 15분 뒤에 닫힙니다. 몇 번 탈 수 있나요?

CoT의 접근: (한 번에 계산하다가 실수함)
L2M의 접근 (분해): “이 문제를 풀려면 먼저 ‘한 번 타는 데 얼마나 걸리는지’를 알아야 합니다.”

Phase 2: 순차 해결 (Sequentially Solve)

1단계에서 얻은 하위 질문부터 하나씩 풉니다. 여기서 가장 중요한 핵심 기술은 ‘문맥 연결(Context Chaining)’입니다. 첫 번째 질문의 답을 두 번째 질문의 입력으로 넣어주는 것이죠.

• 질문 1: 한 번 타는 데 얼마나 걸려?
  답변 1: 올라갈 때 4분 + 내려올 때 1분 = 5분 걸려.
• 질문 2 (질문 1의 답을 포함): 한 번 타는 데 5분 걸리는데, 15분 동안은 몇 번 탈 수 있어?
  답변 2: 15 나누기 5는 3이니까, 3번 탈 수 있어!

단순해 보이지만, 이 과정은 RNN(Recurrent Neural Network)이 이전 상태(State)를 기억하며 다음 값을 예측하는 원리와 유사합니다. AI에게 ‘논리적 징검다리’를 놓아주는 셈입니다.

압도적 데이터: SCAN 벤치마크 99.7%의 충격

L2M의 진가는 자연어 명령을 로봇 행동으로 변환하는 SCAN 벤치마크에서 드러났습니다. 특히 훈련 데이터보다 더 긴 명령어를 테스트하는 ‘Length Split’ 조건은 모든 모델의 무덤이었습니다.

명령어 예시: “run opposite left thrice after walk around right twice” (오른쪽으로 두 번 돌고 걸은 후, 왼쪽 반대편으로 세 번 뛰어라)

이 복잡한 명령을 처리할 때, 각 프롬프트 기법의 성적표는 다음과 같았습니다.

단 14개의 예시만 프롬프트에 넣어줬음에도 99.7%를 달성했습니다. 기존 CoT가 16%대에서 헤맬 때, L2M은 거의 완벽하게 문제를 해결했습니다. 이것은 단순한 성능 향상이 아니라, LLM이 가진 잠재력을 완전히 잠금 해제(Unlock)한 것입니다.

엔지니어를 위한 딥 다이브: 언제 실패하는가? (Error Analysis)

완벽해 보이는 L2M도 만능은 아닙니다. 구글 연구진은 논문의 부록(Appendix)에서 L2M의 실패 사례를 투명하게 공개했습니다. 이를 알면 여러분의 디버깅 시간을 아낄 수 있습니다.

1) 분해 실패 (Decomposition Error)

가장 치명적인 오류입니다. 문제를 쪼개는 것 자체가 틀리면 뒤의 모든 과정이 무너집니다.

사례: “run around left twice”를 분해할 때, 중간 단계인 “run around left”를 건너뛰고 바로 “run left”만 계산하여 오답을 낸 경우가 있었습니다.

2) 도메인 일반화의 어려움 (Limitations)

수학 문제를 위해 만든 분해 프롬프트 템플릿은 상식 퀴즈에는 적용되지 않습니다. 즉, 여러분이 해결하려는 도메인(코딩, 요약, 추론 등)에 맞는 고유한 ‘분해 예시’를 작성해 주어야 합니다. “알아서 쪼개줘”라고 하면 AI도 당황합니다.

🚀 실전 가이드: 지금 당장 적용하는 L2M 템플릿

이론은 충분합니다. 이제 여러분의 코드에 적용해 봅시다. API를 사용한다면 다음과 같은 로직으로 에이전트를 구성할 수 있습니다.

Step 1: 분해 프롬프트 (Decomposer)

먼저 사용자의 복잡한 질문을 받아 리스트 형태로 반환받습니다.

[System]
당신은 복잡한 문제를 해결 가능한 하위 단계로 분해하는 전문가입니다.
 
Q: [사용자 질문]
A: 이 문제를 풀기 위해 다음 단계들이 필요합니다:
1. ...
2. ...

Step 2: 해결 루프 (Solver Loop)

파이썬 의사 코드(Pseudo-code)로 표현하면 다음과 같습니다.

# 개념적 구현 예시
question = "복잡한 사용자 질문..."
sub_questions = decompose(question) # 1단계: 리스트 받기
 
context = ""
for sub_q in sub_questions:
    # 이전 문맥(context)을 포함하여 질문
    answer = ask_llm(f"Context: {context}\nQuestion: {sub_q}")
   
    # 답변을 다시 문맥에 추가 (핵심!)
    context += f"Q: {sub_q}\nA: {answer}\n"
 
final_answer = ask_llm(f"Context: {context}\nFinal Question: {question}")

이 루프 구조를 갖추는 순간, 여러분의 AI 에이전트는 단기 기억(Short-term Memory)을 활용해 복잡한 맥락을 놓치지 않고 끝까지 따라갈 수 있게 됩니다.

결론: 지시하지 말고, 대화하세요

Least-to-Most 프롬프팅은 AI를 대하는 우리의 태도를 바꿀 것을 요구합니다. 일방적으로 “답 내놔”라고 지시(Prompting)하는 시대는 지났습니다. 이제는 단계를 밟아가며 서로의 답을 확인하는 ‘양방향 대화(Bidirectional Conversation)’의 시대로 나아가야 합니다.

16%의 늪에 빠져 있나요? 지금 바로 문제를 분해하세요. 작은 순서의 변화가 99.7%의 기적을 만듭니다.