LLM은 왜 reason 필드를 먼저 작성할까?

Chain of Thought Prompting과 Structured Output의 관계

LLM(대형 언어 모델)을 활용해 Agent 시스템이나 검색 자동화를 만들다 보면 종종 이런 코드를 볼 수 있어요.

class WebSearchItem(BaseModel):
    reason: str = Field(
        description="Your reasoning for why this search is important to the query."
    )

    query: str = Field(
        description="The search term to use for the web search."
    )


class WebSearchPlan(BaseModel):
    searches: list[WebSearchItem] = Field(
        description="A list of web searches to perform to best answer the query."
    )

처음 보면 단순한 데이터 구조처럼 보입니다. 하지만 실제로는 이 코드 안에 LLM의 추론 능력을 끌어내기 위한 중요한 설계 철학이 숨어 있습니다. 이 코드가 단순한 “데이터 모델”이 아니라, 어떻게 LLM의 사고 과정을 유도하는 프롬프트 역할까지 수행하는지 자세히 살펴보겠습니다.

 

이 코드는 크게 두 단계로 구성되어 있습니다.

WebSearchPlan
 └── searches (리스트)
      └── WebSearchItem
            ├── reason
            └── query

1. 전체 검색 계획(WebSearchPlan)을 만들고
2. 그 안에 여러 개의 검색(WebSearchItem)을 넣는 구조입니다.

예를 들어 사용자가 "OpenAI 최신 GPT 모델과 경쟁사 동향을 조사해줘"라고 요청하면 모델은 내부적으로 이런 구조를 생성할 수 있습니다.

WebSearchPlan(
    searches=[
        WebSearchItem(
            reason="Need recent OpenAI announcements about GPT models.",
            query="latest OpenAI GPT model release"
        ),
        WebSearchItem(
            reason="Need competitor information related to Anthropic and Google Gemini.",
            query="Anthropic Claude and Google Gemini latest updates"
        )
    ]
)

여기서 중요한 건 단순 검색어 리스트가 아니라 검색 “의도(reason)”까지 함께 생성한다는 거죠.

BaseModel은 무엇인가?

이 코드는 보통 Pydantic 기반으로 작성됩니다.

class WebSearchItem(BaseModel):

 

BaseModel은:

• 데이터 구조 정의
• 타입 검증(validation)
• JSON 변환
• Structured Output 생성

등을 쉽게 해주는 클래스이며, 이 구조를 사용하면 LLM이 반드시 다음 형태로 답하도록 강제할 수 있습니다.

{
  "reason": "...",
  "query": "..."
}

 

이것이 바로 최근 Agent 시스템에서 매우 중요한 Structured Output 패턴입니다.

 

그런데, Field(description=...)는 단순 주석이 아닙니다. 일반 Python 코드에서는 거의 맞는 말이지만 LLM 환경에서는 전혀 다르게 동작합니다.

 

예를 들어:

reason: str = Field(
    description="Your reasoning for why this search is important to the query."
)

description은 단순 주석이 아니고, LLM에게 전달되는 “행동 지침(prompt)” 역할을 수행합니다.

즉 모델은 내부적으로 거의 이런 프롬프트를 받는 셈입니다.

reason:
- Explain why this search is important.

query:
- Generate the actual web search query.

 

reason 필드에서는 검색 이유를 설명하고 query 필드에서는 실제 검색어를 생성하도록 유도되는 것입니다.

왜 reason을 먼저 생성하게 할까?

여기서 핵심은 reason -> query 와 같은 “순서”입니다. 모델은 먼저:

1. 왜 검색이 필요한지 생각하고
2. 그 reasoning을 바탕으로
3. 검색어를 생성

하게 됩니다. 이 구조는 AI 분야에서 유명한 기법인 Chain-of-thought prompting과 매우 유사합니다.

Chain of Thought(CoT)는 간단히 말하면:

“바로 답하지 말고, 먼저 생각 과정을 거쳐라” 라고 모델을 유도하는 기법입니다.

 

LLM은 “다음 토큰 예측기”다

LLM은 실제로는 “생각”하는 것이 아니라 다음에 올 가능성이 가장 높은 토큰(token)을 계속 예측하면서 문장을 생성합니다. 여기서 흥미로운 일이 발생합니다. 모델이 먼저 "Need recent OpenAI announcements about GPT models." 같은 reasoning 토큰들을 생성했다면, 그 다음 query를 생성할 때도 그 맥락(context)이 유지됩니다. 그러면 이후 생성되는 검색어는 reasoning과 일관되고, 더 구체적이며, 더 의미적으로 자연스러운 형태가 될 가능성이 높아집니다.

바로 이것이 “reason을 먼저 생성하게 하면 query 품질이 좋아지는 이유” 입니다. 즉 reason이 query 생성 방향 자체를 잡아주는 것입니다.

 

마무리

요즘 Agent 프레임워크를 보면 이런 필드가 굉장히 많이 등장합니다.

thought
reason
analysis
plan
reflection

 

이들은 단순 로그 저장용이 아닙니다. 실제로 모델이 생각하고, 계획 세우고, 도구 선택하고, 행동 전에 검토하도록

유도하는 장치들입니다. 즉 현대 LLM 시스템에서는 “좋은 답변을 얻고 싶다면 모델에게 먼저 생각할 공간을 줘라”가 매우 중요한 설계 원칙이 되고 있습니다.

 

reason: str
query: str

 

안에도 사실은 LLM의 추론 품질을 높이기 위한 중요한 철학이 담겨 있습니다.

특히:

Field(description="...")

 

는 단순 문서화가 아니라 모델 행동 유도, 추론 방향 제어, Chain of Thought 유발, 출력 품질 개선 역할까지 수행합니다.

Structured Output 스키마는 단순 데이터 구조가 아니라, LLM에게 “어떻게 생각할지”를 설계하는 프롬프트이기도 한 것입니다.