← Back to list

[AI] Tree of Thoughts와 Context Engineering

지난 글에서 CoT(Chain-of-Thought)를 다뤘다. AI가 복잡한 문제를 풀 때 중간 추론 과정을 단계적으로 생성하는 방식이었다. 그런데 CoT에는 근본적인 한계가 있다. 이번 글에서는 그 한계를 극복한 Tree of Thoughts…

duckdev · 2026-03-18 04:53 · 0 claps · 4.2 min read
#ai #tot #context-engineering
Open on Medium ↗
Wiki topics: PE · Prompt Engineering AI · AI · General

[AI] Tree of Thoughts와 Context Engineering

지난 글에서 CoT(Chain-of-Thought)를 다뤘다. AI가 복잡한 문제를 풀 때 중간 추론 과정을 단계적으로 생성하는 방식이었다. 그런데 CoT에는 근본적인 한계가 있다. 이번 글에서는 그 한계를 극복한 Tree of Thoughts, 그리고 프롬프트 엔지니어링 자체를 넘어서는 개념인 Context Engineering을 다룬다.

Tree of Thoughts (ToT)

CoT의 한계 CoT는 강력하지만 구조적으로 취약한 지점이 있다.

문제 → 추론 1 → 추론 2 → 추론 3 → 답

이 흐름은 단선적(linear) 이다. 추론 1에서 방향을 잘못 잡으면 그 오류가 끝까지 이어진다. 되돌아가는 기능이 없기 때문이다. 처음 생각한 게 틀리면 계속 틀린 방향으로 간다.

복잡한 수학 문제나 전략적 판단이 필요한 상황에서 이 한계는 명확히 드러난다.

ToT의 접근 방식

Tree of Thoughts(ToT)는 2023년 Shunyu Yao 외 연구팀이 NeurIPS에서 발표한 프레임워크다. CoT의 단선적 추론을 트리 구조로 확장한다.

핵심 아이디어는 이렇다.

하나의 추론 경로만 따라가는 대신, 여러 개의 사고 후보를 동시에 생성하고, 단계마다 평가해서 가장 유망한 경로를 선택한다. 막힌 경로는 버리고 이전 단계로 돌아가 다른 방향을 탐색할 수 있다.

                   [문제]
                /    |    \
           [A]      [B]      [C]       ← 1단계: 후보 생성
          /   \      |      /   \
       [A1]  [A2]  [B1]  [C1]  [C2]   ← 2단계: 각 경로 평가
              ✓            ✗     ✓
             ...                ...    ← 유망한 경로만 계속 탐색

각 단계에서 모델은 스스로 각 사고(thought)를 자기 평가(self-evaluation) 하고, 좋은 경로는 계속 탐색하고 막힌 경로는 폐기한다.

실제 성능 차이

논문에서 “Game of 24” 과제(네 개의 숫자로 사칙연산을 조합해 24를 만드는 문제)를 실험했을 때, GPT-4 + CoT의 성공률은 4%였다. ToT를 적용하자 74% 로 올랐다. 단순한 개선이 아니라 차원이 다른 결과다.

일반 프롬프팅: ~1%(GPT-4 성공률) CoT: 4%(GPT-4 성공률) ToT: 74%(GPT-4 성공률)

CoT vs ToT 요약

추론 구조: 단선적 (linear) / 트리형 (branching) 오류 복구: 불가 / 백트래킹 가능 적합한 문제: 단계가 명확한 문제 / 탐색·전략이 필요한 문제 계산 비용: 낮음 / 높음

ToT가 무조건 좋은 건 아니다. 계산 비용이 높기 때문에, 단순한 추론에는 CoT로도 충분하다. 복잡한 계획, 탐색, 전략 수립이 필요한 문제에서 ToT가 빛을 발한다.

Context Engineering

패러다임이 바뀌고 있다

2025년 6월, Shopify CEO 토비 뤼트케와 전 OpenAI 연구원 안드레이 카르파티가 공개적으로 “컨텍스트 엔지니어링”이라는 용어를 지지하면서 업계에서 빠르게 확산된 개념이다.

카르파티의 요지는 이렇다:

“프롬프트 엔지니어링”이라는 말은 짧은 지시문을 잘 쓰는 것처럼 들린다. 하지만 실제 프로덕션 LLM 앱에서 중요한 건, 모델이 답변을 생성하는 동안 참고하는 모든 정보와 환경을 설계하는 것이다.

컨텍스트란 무엇인가

LLM이 “지금 이 순간” 답변을 만들 때 참고하는 모든 입력 정보를 컨텍스트(Context) 라고 한다.

우리가 채팅창에 입력하는 질문은 그 일부일 뿐이다. 실제 LLM 입력은 이것들을 모두 포함한다:

  • System prompt (역할, 규칙 지정)
  • 사용자 질문
  • 이전 대화 히스토리
  • 검색 결과 (RAG)
  • 툴(Tool) 응답
  • 메모리
  • 프로젝트 구조, 의존성 정보 (코딩 에이전트의 경우)

컨텍스트 윈도우(Context Window) 는 모델이 한 번에 참고할 수 있는 최대 길이다. 이를 초과하면 성능이 저하되거나 내용이 잘린다.

왜 컨텍스트 엔지니어링인가

프롬프트 엔지니어링은 질문만 다룬다:

  • 질문을 어떻게 쓸까?
  • 지시를 어떻게 명확하게 줄까?
  • 출력 형식을 어떻게 유도할까?

컨텍스트 엔지니어링은 더 넓은 질문을 다룬다:

  • 모델이 보는 전체 정보를 어떻게 구성할까?
  • 컨텍스트 윈도우를 어떻게 효율적으로 관리할까?
  • 어떤 정보를 넣고, 어떤 정보를 버릴까?
프롬프트 엔지니어링 ⊂ 컨텍스트 엔지니어링

프롬프트 엔지니어링은 컨텍스트 엔지니어링의 하위 집합이다.

핵심: 컨텍스트 윈도우는 길다고 좋은 게 아니다

직관적으로는 “정보가 많을수록 좋다”고 생각하기 쉽지만, 실제로는 반대다.

컨텍스트가 길어질수록 LLM은 집중도가 낮아지고, 노이즈의 영향이 커진다. 컨텍스트 엔지니어링의 본질은 결국 이것이다:

제한된 컨텍스트 윈도우 안에 ‘가장 가치 있는 정보만’ 유지하는 것

ToT 마무리

CoT가 “단계적으로 생각하기”였다면, ToT는 “여러 가능성을 탐색하고 스스로 평가하기”다. LLM의 추론 능력이 어디까지 발전할 수 있는지 보여주는 방향이다.

Context Engineering 마무리

프롬프트 한 줄을 잘 쓰는 시대에서, 모델이 보는 세계 전체를 설계하는 시대로 넘어오고 있다. 질문을 어떻게 쓸지보다, 무엇을 보여줄지가 더 중요해졌다.

참고:


메타데이터
post_id
bc0ccfcf4881
slug
ai-tree-of-thoughts와-context-engineering-bc0ccfcf4881
url
https://medium.com/@zero86/ai-tree-of-thoughts%EC%99%80-context-engineering-bc0ccfcf4881
canonical_url
https://medium.com/@zero86/ai-tree-of-thoughts%EC%99%80-context-engineering-bc0ccfcf4881
author_url
https://medium.com/@zero86
status
ok
fetched_at
2026-06-12 07:40:50