# Speculative tree search

> 생산성 향상을 위한 인간-AI 협업 패턴에 대해 고민하다가 투기적 트리 탐색(speculative tree search)이라는 방법을 떠올렸다.

생산성 향상을 위한 인간-AI 협업 패턴에 대해 고민하다가 투기적 트리 탐색(speculative tree search)이라는 방법을 떠올렸다.

## 개요

[LLM](https://wiki.g15e.com/pages/Large%20language%20model.txt) 토큰을 10배나 100배 쓰는 건 쉽지만, 그 결과로 10배나 100배의 생산성을 달성하기는 어렵다. 그동안(<2025년 10월> 까지)은 주로 생산성 향상 방법보다는 역량 향상 방법을 고민했는데 막상 본격적으로 뭔가를 해보려고 하니(<2025년 11월> 이후) 아무래도 생산성 향상으로 관심이 쏠리게 됐다.

## 그동안 해봤던 시도들

그동안도 생산성 향상에 대해 고민을 안했던 건 아니라서 이런저런 시도들을 간헐적으로 해보긴 했는데, 이참에 정리를 해봤다.

### 여러 프로젝트를 병렬로 하기

동일한 명세서를 놓고 여러 프로젝트를 병렬로 진행하는 시도를 해봤다([간단한 마인크래프트 클론](https://akngs.github.io/vox2/)). 이런 걸 하게 된 동기:

- 동일한 명세서를 주더라도 에이전트가 만들어내는 결과물의 품질이 제법 다른 경우가 많다. 명세서로부터 결과물이 생성되는 걸 1회 시행이라고 봤을 때, 시행 횟수를 늘리면 좋은 결과물이 얻어질 가능성이 높다는 뜻.
- [에이전틱 코딩](https://wiki.g15e.com/pages/Agentic%20coding.txt)에서 어차피 대부분의 코드는 AI가 만들고 나는 주로 리뷰만 한다. AI가 코딩을 하는 동안에는 내가 대기하고 내가 리뷰를 하는 동안에는 AI가 대기를 하는 패턴이라 실제로 흐른 물리적 시간 중 유휴 시간이 절반이다.
- 과도한 병렬 작업은 맥락 전환 비용을 높이기 때문에 오히려 생산성을 낮추지만, 적절한 수준의 병렬 작업은 유휴 자원을 줄이기 때문에 생산성을 높일 수 있다고 봤다.
- ([Claude Code](https://wiki.g15e.com/pages/Claude%20Code.txt) 맥스 플랜을 구독했기 때문에 토큰을 많이 써야한다는 동기도 있었다 ㅋㅋ)

두 프로젝트를 약 5-10분 간격으로 전환하며 약 2.5일 간 40시간 정도 집중해서 써봤는데(그 사이에 명세서만 남기고 전체를 다 지운 뒤 새로 시작하기를 몇 번 반복), 극도의 집중력이 필요했고 지력이 매우 빠르게 소진됐다. 이 방식으로는 10x는 커녕 2x도 안된다. 게다가 유사한 두 프로젝트를 오가느라 생기는 간섭도 상당했다(예: "[코요테 타임](https://wiki.g15e.com/pages/Coyote%20time.txt)을 여기에서 구현했던가? 저쪽 프로젝트였나?").

### 한 번에 긴 작업 시켜보기

(<2025년 10월> 기준) 아직까지는 코딩 에이전트에게 긴 작업을 시키기가 좀처럼 쉽지 않다.

[How Does Time Horizon Vary Across Domains?](https://metr.org/blog/2025-07-14-how-does-time-horizon-vary-across-domains/) 같은 연구에서는 소프트웨어 관련 작업을 1시간 이상 수행할 수 있다고 하지만, 일상에서 느끼는 작업 시간의 중앙값은 3-5분 사이인 것 같다. 작정하고 오래 걸릴만한 일을 시켜도 보통은 30분 안에 끝난다. (ML 모델을 만들고 평가하고 개선하는 작업처럼 오래 걸릴 수 밖에 없는 일들은 예외)

게다가 LLM에게 긴 작업을 시키는 경우 통상 두 가지 문제를 겪는다.

- AI가 오래 일할수록 대체로 결과물이 커진다. 결과물이 커지면 인간의 검토 시간이 길어진다.
- AI가 오래 일할수록 대체로 결과물의 품질이 나쁘다. 품질이 나쁘면 인간의 검토 시간이 길어진다.

이 방식으로도 10x 생산성을 달성할 수는 없어 보이고, 오히려 생산성이 낮아지는 경우도 있다.

### 작은 단위의 작업을 단계적으로 하도록 예약해놓기

작업량이 동일하다고 가정했을 때, 큰 커밋 하나가 있는 것에 비해 응집력 있는 작은 커밋 여러 개가 있는 게 리뷰하기에 훨씬 편하다는 점에서 착안하여 이런 시도를 해봤다. (실제로는 프롬프트가 훨씬 길지만 짧게 줄임)

```bash
#!/bin/bash
while true
do
  claude -p "다음 작업을 하나 수행하고 문서를 갱신한 다음에 커밋해."
  claude -p "직전 커밋을 검토하고 관련 테스트를 추가한 다음에 커밋해."
  claude -p "직전 두 개 커밋을 검토하고 버그를 수정한 뒤 커밋해. 버그가 없으면 아무것도 하지 마."
  claude -p "구현과 명세 사이에 불일치를 찾아서 고치고 커밋해."
  claude -p "전체 코드를 검토하고 가장 지저분한 코드를 찾아서 최소한으로 리패토링한 뒤 커밋해."
done
```

실제로는 따옴표 안에 더 길게 써야 한다. 예를 들면 이런 식:

> Carefully read `SPEC.md` and related documents, and analyze the current implementation. Find out what to do next and perform the task. Don't try to make too much progress. The task should be the smallest possible improvement you can make from the current state. After completing the work, minimally update relevant documents to reflect the changes. ultrathink

이런 스크립트를 만들어서 이틀 동안 돌렸더니 470개의 커밋이 만들어졌다. 평균 6분 간격으로 커밋을 하나씩 만들어낸 것.

결과물은 썩 괜찮았지만 여러 보완할 점들이 있었다. 몇 가지 예:

- 방향성 없이 무턱대고 "리팩토링"을 하라고 하면 <Extract function>을 했다가 <Inline function>을 했다가 하면서 왔다갔다 하는 경우가 잦다.
- 이틀만에 커밋을 470개나 하는 걸 검토할 엄두가 나지 않는다.

이 방식으로도 10x 생산성을 달성할 수는 없어 보인다.

## 교훈

위 시도들로부터 어떤 교훈을 얻을 수 있을지 고민하다가, 10x 생산성을 위한 전제들을 명시적으로 정리했다. 써놓고 보니 당연한 얘기들인데 그래도 이후 생각을 전개할 때 도움이 됐다.

전제:

- 인간은 AI보다 매우 비싸다. (즉, AI 많이 써서 인간의 노력을 조금 줄이는건 좋은 거래다)
- 시간은 돈보다 매우 비싸다. (즉, 돈 많이 써서 시간을 조금 단축하는건 좋은 거래다)
- 인간의 맥락 전환 비용은 비싸다.
- 인간의 판단이 필요한 일들이 존재한다.
- 인간의 판단에 드는 비용(시간과 노력)은 AI가 만든 산출물의 크기에 비례하고 품질에 반비례한다.
- 인간의 판단 실수는 인간의 비용(맥락 전환 비용, 판단 비용)에 비례한다.
- 인간의 판단 실수는 비싸다.

위 전제가 참이라고 수용했을 때, 생산성을 극대화하기 위한 인간-AI 협업 패턴은 어때야 할까?

1. 인간 개입이 필요 없는 부분을 최대한 분리하여 자동화해야 한다.
2. 인간 개입이 필요한 프로세스에서, AI가 일을 오래 할수록 산출물의 크기가 커져서는 안된다. 대신 산출물의 품질이 좋아져야 한다.
3. 인간이 여러 일을 동시에 진행하는 경우에도 맥락 전환을 최소화할 수 있어야 한다.

이 중 2와 3에 대해 더 생각해봤다.

## 투기적 트리 탐색 Speculative tree search

<투기적 실행>이라는 성능 최적화 기법이 있다. 실행이 필요할지 아닐지 확실치 않은 상황일 때, 확실해지기를 기다리는 대신 일단 미리 실행을 해놓는 방법이다. 실행이 필요하다는 결론이 나면? 이미 실행을 했기 때문에 대기시간이 사라진다. 실행이 필요 없다는 결론이 나면? 실행했던 결과를 그냥 버리면 된다.

투기적 실행은 아래 조건이 성립하는 상황에서 유효한 전략이다. (보통은 유휴 자원으로 실행을 하기 때문에 '미리 실행을 하느라 쓴 비용'은 전력 비용 등을 따지지 않는다면 0에 가깝다)

> 미리 실행을 하느라 쓴 비용 < 대기하느라 든 비용

앞에서 도출한 전제들을 고려하여 인간-AI 협업 맥락에 투기적 실행 개념을 적용해보자.

- 명세서를 아무리 잘 써도 인간의 판단이 필요한 상황이 온다.
- AI가 인간이 내릴 법한 판단의 후보들을 미리 열거하고 실행해두면 1) 인간의 대기 시간을 줄일 수 있고, 2) 물리적 시간도 줄일 수 있다.
- 인간은 AI보다 비싸고 물리적 시간은 돈보다 비싸니까 AI를 "미리 실행을 하느라 쓴 비용 < 대기하느라 든 비용"이 성립한다.

한편, 여러 프로젝트를 동시에 진행한다고 했을 때 인간이 각 프로젝트를 돌아다니며(interleaving) 판단을 내리려면 맥락 전환 비용이 발생한다. 따라서 여러 프로젝트를 동시에 진행하는 상황에서도 각 프로젝트에서 일련의 판단을 연속하여 내린 후 다음 프로젝트를 방문하는 식으로 순회하면 이 비용을 줄일 수 있다.

그러려면 재귀적인 투기적 실행이 필요한데 이는 결국 투기적 트리 탐색(speculative tree search)이라고 볼 수 있다.

의사코드:

- 인간이 AI에게 일을 시킨다.
- AI가 일을 수행한다.
  - 일이 끝났으면? 종료.
  - 일을 진행하기 위해 인간의 판단이 필요하면? 선택지를 나열한 후 각 선택지에 대해 재귀적으로 반복.

이 방식의 문제는 트리가 깊어지면서 탐색 공간이 급격히 커진다는 점인데, 트리 탐색을 효율화하는 여러 전략들이 있으니 큰 문제는 없어 보인다. 예를 들어  [MCTS](https://wiki.g15e.com/pages/Monte%20Carlo%20tree%20search.txt)를 살짝 변형한 방법을 생각해볼 수 있다. MCTS의 네 단계(selection, expansion, rollout, backprop) 중 rollout 단계를 생략하고 그냥 LLM이 점수를 추정하도록 하는 식으로 변형한다거나.

물론 탐색 공간을 줄이는 가장 효과적인 방법은 명세서를 되도록 구체적으로 쓰는 것인데, 이 부분은 상대적으로 독립된 문제이므로 논외로 하자. (관련 글: [s4](https://wiki.g15e.com/pages/Semi-structured%20software%20spec.txt), [자연어로 작성된 명세서](https://wiki.g15e.com/pages/Specification%20written%20in%20natural%20language.txt))

## 적용할 수 있는/없는 분야

위 방식은 투기적 실행이 부수효과(side-effect)를 만들지 않는 경우에만 적용할 수 있다. (부수효과가 있다면? [Spectre](https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)) 안녕?)

예를 들어 투기적 실행의 결과로 이메일을 발송한다면 나중에 UNDO 할 수가 없으므로 이 방식을 적용할 수 없다. 로컬 머신에서 분기에 따라 깃 브랜치를 만들고 커밋을 하는 건 (대부분의 상황에서) 안전하므로 적용 가능하다.

문서 작성, 코드 작성, 아트워크 생성 등에 적용이 가능해보인다.

## 결과

<TODO>: 실제로 해보고 내용 추가하기.

## See also

- [생성형 AI와 프로그래머의 역량](https://wiki.g15e.com/pages/Generative%20AI%20and%20competency%20of%20programmers.txt)
- [코딩 연습 도구로써의 AI](https://wiki.g15e.com/pages/AI%20as%20coding%20practice%20tool.txt)
- [AI 시대의 프로그래밍 교육](https://wiki.g15e.com/pages/Programming%20education%20in%20the%20AI%20era.txt)
- [AI 지원 프로그래밍을 위한 새 실천법](https://wiki.g15e.com/pages/New%20practices%20for%20AI-aided%20programming.txt)