o1 패러다임: AI가 더 똑똑해지기 위해 더 느려지는 이유

How Thinking AI Models Are Rewriting Inference Scaling Laws

OpenAI의 o-시리즈 모델(o1, o3, o4 등)을 사용해 보셨다면, 무언가 당혹스러운 점을 발견하셨을 겁니다. 바로 ‘멈춤(pause)’입니다.

지난 수년 동안 우리는 거대언어모델(LLM)을 ‘속도’에 최적화해 왔습니다. 밀리초(ms) 단위의 지연 시간을 측정하며 즉각적인 텍스트 생성을 추구했죠. 하지만 2024년 말, 컴퓨터 과학계에 중대한 변화가 일어났습니다. 바로 ‘학습 단계 연산(Training-Time Compute)’에서 ‘추론 단계 연산(Inference-Time Compute)’으로의 전환입니다.

“o1 패러다임”은 단순한 모델 업데이트가 아닙니다. 이는 AI를 위한 시스템 2 사고(System 2 thinking)의 산업화라고 볼 수 있습니다. 속도를 지능과 맞바꾸어, 입을 열기 전에 컴퓨팅 자원을 소모하며 침묵 속에서 “생각”하는 방식을 택한 것입니다.

이것이 개발자와 엔지니어에게 어떤 의미를 갖는지, 그리고 여러분의 워크플로우를 어떻게 변화시켜야 하는지 알아보겠습니다.

핵심 개념: 추론 단계 연산 (Inference-Time Compute)

o1을 이해하려면 추론의 법칙(Scaling Laws of Inference)을 이해해야 합니다.

이전까지 AI의 지능은 학습 단계에 쏟아부은 연산량(인터넷 데이터를 학습하는 데 보낸 몇 달간의 시간)에 의해 결정되었습니다. 학습이 끝나면 모델은 정적인 상태가 됩니다. 이는 “시스템 1” 사고방식으로, 빠르고 직관적이지만 복잡한 논리 앞에서는 환각(hallucination)을 일으키기 쉬웠습니다.

o1 패러다임은 여기에 테스트 시간 연산(Test-Time Compute)이라는 새로운 변수를 도입합니다. 모델이 사용자는 볼 수 없는 “히든 토큰(hidden tokens, 내적 사고)”을 생성하게 함으로써, API 호출 도중에 스스로 오류를 수정하고, 계획을 세우고, 역추적할 수 있게 만든 것입니다.

시스템 1 vs. 시스템 2

  • 시스템 1 (GPT-4o, Claude 3.5 Sonnet): “빠른 사고.” 패턴 매칭. 창의적인 글쓰기, 간단한 코드 작성, 요약에 적합합니다.
  • 시스템 2 (o1, o3-mini, DeepSeek R1): “느린 사고.” 신중한 추론. 아키텍처 설계, 복잡한 수학, 법률 분석에 적합합니다.

이제 성능과 연산의 관계는 다음과 같이 근사할 수 있습니다.

즉, 단순히 더 큰 모델을 학습시키는 것뿐만 아니라, 모델이 더 오래 “생각”하게 함으로써 더 높은 지능을 달성할 수 있다는 뜻입니다.

숨겨진 생각의 사슬 시각화

아래 다이어그램은 추론 모델(Reasoning Model)이 일반적인 LLM과 어떻게 다른지 보여줍니다.

graph TD
    A["사용자 프롬프트"] --> B{"모델 유형"}
    
    B -- "일반 LLM (GPT-4o)" --> C["토큰 예측"]
    C --> D["즉각적인 출력"]
    
    B -- "추론 모델 (o1)" --> E["숨겨진 생각의 사슬(CoT) 시작"]
    E --> F["문제 분해"]
    F --> G["솔루션 초안 작성"]
    G --> H{"자가 수정 필요?"}
    H -- "네 (오류 발견)" --> F
    H -- "아니요" --> I["최종 답변 종합"]
    I --> D
    
    style E fill:#333,stroke:#fff,color:#fff
    style F fill:#333,stroke:#fff,color:#fff
    style G fill:#333,stroke:#fff,color:#fff
    style H fill:#333,stroke:#fff,color:#fff

코드: 추론 토큰(Reasoning Tokens) 다루기

o1 계열 모델을 사용하여 개발할 때는 추론 토큰(Reasoning Tokens)에 대한 비용이 청구됩니다. 이는 모델이 생각하는 동안 생성하는 히든 토큰들입니다. 최종 응답에는 나타나지 않지만, 컨텍스트 윈도우와 예산을 소비합니다.

다음은 OpenAI SDK (v1.50+)를 사용하여 요청을 구조화하는 방법입니다. 특히 모델이 얼마나 깊게 생각할지 제어하는 reasoning_effort 파라미터에 주목하세요.

from openai import OpenAI
import os

client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

# 복잡한 논리 작업 정의
prompt = """
분산 작업 스케줄러를 위한 Python 클래스 계층 구조를 설계하세요.
낙관적 잠금(optimistic locking)을 사용하여 경쟁 상태(race condition)를 처리해야 하며,
다양한 개별 레벨을 가진 우선순위 큐를 지원해야 합니다.
"""

response = client.chat.completions.create(
    model="o1", # 또는 "o3-mini"
    messages=[
        {"role": "user", "content": prompt}
    ],
    # 'reasoning_effort'는 숨겨진 생각의 사슬 깊이를 제어합니다.
    # 옵션: "low", "medium", "high"
    reasoning_effort="high" 
)

# 콘텐츠 추출
final_answer = response.choices[0].message.content

# 사용량을 검사하여 "생각 비용" 확인
usage = response.usage
input_tokens = usage.prompt_tokens
output_tokens = usage.completion_tokens
# 'reasoning_tokens'는 completion_tokens의 하위 집합입니다.
reasoning_tokens = usage.completion_tokens_details.reasoning_tokens

print(f"최종 답변 길이: {len(final_answer)} 자")
print(f"총 출력 토큰: {output_tokens}")
print(f"숨겨진 추론 토큰: {reasoning_tokens}")

코드의 핵심 시사점:
만약 reasoning_tokens가 4000개인데 눈에 보이는 출력(visible output)이 200토큰에 불과하다면, 이는 모델이 단 한 줄의 코드를 작성하기 전에 아키텍처를 고민하는 데 엄청난 연산을 수행했음을 의미합니다.

단계별 가이드: 추론을 위한 프롬프팅

오래된 습관은 쉽게 고쳐지지 않습니다. GPT-4 시절 통했던 프롬프트 엔지니어링 트릭들(Chain-of-Thought 프롬프팅, “심호흡하고 생각해 봐” 등)은 이제 안티패턴(antipatterns)이 되었습니다. 이러한 기법들은 오히려 모델 고유의 추론 과정을 방해합니다.

  1. “단계별로 생각하라(Step-by-Step)”고 요청하지 마세요:
    모델에게 단계를 나누어 생각하라고 지시하지 마세요. o1은 이미 내부적으로(히든 체인에서) 이 과정을 수행합니다. 이를 억지로 겉으로 드러내게 하면 성능이 저하되고 토큰만 낭비됩니다.
  2. “System” 대신 “Developer” 메시지를 사용하세요:
    o1-preview 및 초기 o1 버전에서는 추론 능력을 제한하지 않기 위해 system 역할이 지양되고 user 또는 developer 역할이 권장되었습니다. (이 부분은 빠르게 변하므로 최신 API 스펙을 확인하세요).
  3. 지시(Instruction)보다 맥락(Context)을 우선하세요:
    모델에게 어떻게 생각할지(지시) 알려주는 대신, 무엇에 대해 생각해야 할지(데이터/맥락)를 더 많이 제공하세요.

    • 나쁜 예: “이 논리 퍼즐을 풀어라. 먼저 변수를 나열하고, 제약 조건을 정의한 다음…”
    • 좋은 예: “이 논리 퍼즐을 풀어라. 여기 변수와 제약 조건, 그리고 원하는 출력 형식이 있다.”
  4. 컨텍스트 윈도우 관리:
    추론 토큰도 컨텍스트 제한에 포함됩니다. 입력 프롬프트가 너무 방대하면(예: 10만 토큰), 모델이 생각할 수 있는 ‘연습장(scratchpad)’ 공간이 줄어듭니다. 복잡한 작업의 경우 RAG(검색 증강 생성)를 사용하여 관련성 높은 스니펫만 제공하세요.
  5. 구분자(Delimiters) 사용:
    프롬프트를 명확하게 구조화하세요. 추론 모델은 데이터가 구획화되어 있을 때 뛰어난 성능을 발휘합니다.

    <policy_document>
    [텍스트 삽입]
    </policy_document>
    
    <user_query>
    [질문 삽입]
    </user_query>
    

o1 패러다임은 ‘느낌(vibe) 위주의 AI’가 끝나고 검증 가능한 추론의 시대가 시작되었음을 알립니다. 우리는 이제 단순히 텍스트를 요청하는 것이 아니라, 사고(thought)를 요청하고 있습니다. 여러분의 역할은 더 이상 모델의 손을 잡고 이끄는 것이 아니라, 모델이 스스로 길을 찾을 수 있도록 문제를 명확하게 정의해 주는 것입니다.

참고 자료