ADHD: Coding Agent에 Tree-of-Thought 병렬 추론 엔진 붙이기

CLI가 LLM을 호출하다가 가끔 90초 동안 멈출 때, retry와 timeout은 어떻게 설계해야 할까요? 교과서식 답은 이렇게 말합니다. exponential backoff에 jitter를 붙이고, 절대 timeout을 두고, 자동 retry를 한 번 넣으라고요. 크게 틀린 답은 아니지만, 한 가지 질문이 빠졌다는 느낌이 들 수 있습니다. 느린 것이 정말 네트워크일까요, 아니면 애초에 모델 선택이 잘못된 걸까요? 사용자가 기다릴수록 버튼은 점점 더 뜨거워져야 하고, 한 번 누르면 더 빠른 모델로 넘길 수 있어야 하지 않을까요?

ADHD가 풀려는 문제가 바로 이것입니다. Agent에게 “한 번 더 생각해 봐”라고 말하는 prompt가 아니라, AI 코딩 Agent에 붙이는 병렬 추론 구조입니다. 먼저 여러 독립 분기가 서로 다른 인지 관점에서 동시에 발산하고, 그다음 별도 critic이 점수화, 클러스터링, 함정 제거, 생존 후보 심화를 맡습니다. 이 글은 이 skill의 메커니즘, 경계, 사용 판단을 정리합니다.

ADHD는 무엇인가(prompt 기법이 아니다)

ADHD의 포지셔닝은 분명합니다. prompt에 격려 문구를 조금 더 붙이는 것이 아니라, 자기회귀 추론의 조기 수렴을 고치려는 시도입니다.

자기회귀 모델은 token을 하나씩 이어서 생성합니다. 앞의 몇 단계가 어떤 방향을 잡으면 뒤 내용은 그 방향을 중심으로 펼쳐집니다. 이 방식은 효율적이지만 열린 엔지니어링 문제에서는 부작용이 있습니다. 첫 번째 그럴듯한 답이 anchor가 되고, 모델은 가장 흔하고 훈련 데이터와 가장 닮은 경로로 미끄러집니다. 그 답은 교과서적으로는 맞는 경우가 많지만, 뻔하지 않으면서 더 가치 있는 선택지를 자주 놓칩니다.

일반 prompt도 “여러 방안을 나열한 뒤 비교하라”, “다른 관점에서 생각하라”, “너무 빨리 결론 내리지 말라”고 요구할 수 있습니다. 문제는 그 분기들이 여전히 같은 컨텍스트 안에서 서로 오염된다는 점입니다. 모델은 생성하면서 동시에 평가하고, 초기 방향 하나가 글로 적힌 뒤에는 후속 분기가 그것에서 완전히 벗어나기 어렵습니다.

ADHD의 방식은 더 단단합니다. 발산 단계는 N개의 완전히 격리된 Agent SDK 호출로 쪼개지고, 각 분기는 원문 문제, 하나의 인지 frame, 평가를 금지하는 system prompt만 봅니다. 분기 사이에는 공유 컨텍스트가 없습니다. 평가 단계에서야 별도 critic 호출이 전체를 점수화, 클러스터링, 가지치기, 심화합니다.

한 줄로 말하면 CoT는 한 머리가 더 천천히 생각하게 하고, Tree-of-Thought는 한 머리가 더 넓게 검색하게 하며, ADHD는 여러 머리가 병렬로 다르게 생각하게 한 뒤 심사자가 고르게 합니다.

2단계 메커니즘: Diverge/Focus 하드월 격리

ADHD의 핵심은 Phase 1 Diverge와 Phase 2 Focus라는 두 단계입니다. 두 단계 사이에는 하드월이 있습니다. 발산 중에는 평가를 금지하고, 평가 단계에서야 수렴을 허용합니다.

Phase 1 Diverge: N개 경로의 동시 격리

첫 단계는 N개의 인지 frame을 선택합니다. 기본 N=5이고, 이어서 N개의 격리된 Agent SDK query를 동시에 시작합니다. 각 분기는 세 가지만 받습니다.

1. 원래 문제.
2. 어떤 frame의 관점 prompt. 예를 들어 지연, 메모리 배치, 규제, on-call, 역산으로 이 문제를 다시 묻게 합니다.
3. 평가, 순위 매기기, 망설임을 금지하는 system prompt.

분기들은 서로 보지 못합니다. 규제 감사 관점의 분기는 speedrunner 분기가 쓴 내용을 읽을 수 없고, 하드웨어 엔지니어 관점의 분기도 10살 아이 관점에 먼저 anchor되지 않습니다. 각 분기는 독립 stateless session입니다. anchoring 효과는 모델의 자기 절제로 누르는 것이 아니라 구조적으로 잘라냅니다.

동시성은 semaphore가 제어하며 기본 concurrency=4입니다. Token 비용은 분기 수에 선형으로 늘어 O(N×분기당 비용)입니다. 뒤 분기는 앞 분기의 전체 내용을 다시 읽지 않으므로 N²가 아닙니다.

Phase 2 Focus: 별도 critic 호출

두 번째 단계에서는 별도 critic 호출로 바뀝니다. critic은 세 가지 일을 합니다.

1. score: 각 분기의 novelty, feasibility, fit을 0~10점으로 평가하고, 함정에는 메커니즘 기반 이유를 붙입니다.
2. cluster: 표면 키워드가 아니라 underlying angle 기준으로 클러스터링합니다.
3. deepen top-K: 기본 K=3개의 생존 후보를 심화해 스케치, 하중 위험, 첫 동작, 3~5개의 하위 아이디어를 보강합니다.

이 설계의 핵심은 generator와 critic의 기계적 분리입니다. generator 단계는 평가를 금지하고, critic 단계는 평가를 의무화합니다. 같은 세션 안의 말뿐인 약속이 아니라 서로 다른 API 호출입니다.

격리 분기의 호출 모양은 대략 이렇습니다.

const branches = await Promise.all(
  frames.map((frame) =>
    withSemaphore(concurrency, () =>
      callLLM({
        systemPrompt: `${frame.vantage}\n\nFORBIDDEN: evaluation, ranking, hedging. JSON array out.`,
        userPrompt: `${problem}\n\n${context ?? ""}`,
      }),
    ),
  ),
);

처음의 retry/timeout 문제로 돌아가면 baseline은 표준 hybrid를 내놓기 쉽습니다. 첫 token timeout 15초, token 사이 timeout 30초, 절대 상한 90초, 자동 retry 1회 같은 식입니다. ADHD의 가치는 이 답을 더 길게 쓰는 데 있지 않습니다. “기다릴수록 버튼이 점점 뜨거워지고, 클릭하면 취소 후 더 빠른 모델로 넘긴다” 같은 선택지를 추가로 끌어내는 동시에, “token을 역순으로 streaming하기”, “인내심 기준 과금”처럼 신기해 보이지만 엔지니어링상 함정인 방안을 미리 표시하는 데 있습니다.

CoT/ToT와의 구조 비교

차원	Chain-of-Thought (CoT)	Tree-of-Thought (ToT)	ADHD
thread 수	단일 선형	단일 tree traversal	N개 병렬 격리
공유 컨텍스트	yes, 전부 공유	yes, 보통 일부 공유	no, 하드월 격리
generator/critic	같은 세션 안에서 동시 평가	같은 모델이 생성과 평가를 교대	단계 분리, 호출 분리, 반대 posture
분기 구동	명시적 분기 없음	다음 단계 변형	인지 frame으로 전체 문제를 다시 질문
병렬성	없음	대부분 순차	진짜 병렬, semaphore 제어
적합한 문제	다단계 논리, 수학 추론	검색, 계획, puzzle	열린 엔지니어링 설계와 구상

세 가지 하중 차이

첫째, ADHD는 검색이 아니라 격리입니다. ToT의 분기는 여전히 같은 tree 위에서 펼쳐지고, 초기 node가 후속 node에 영향을 줍니다. ADHD의 분기는 발산 중 서로 보지 못하므로 anchoring이 구조적으로 제거됩니다.

둘째, ADHD는 next-step 변형이 아니라 frame을 씁니다. ToT는 대개 “다음에 무엇을 할까”에서 선택지를 확장합니다. ADHD는 전체 문제를 다른 인지 위치에서 다시 묻습니다. parameter를 조금 조정하는 것이 아니라, 모델이 지연, 물리 제약, 규제 책임, 새벽 3시 on-call 압박 속에서 문제를 다시 보게 합니다.

셋째, generator-critic 분리는 약속이 아니라 기계적 구조입니다. 같은 세션 안에서 “먼저 평가하지 말라”고 말해도 생성 과정에서 은근히 비교가 끼어들 수 있습니다. ADHD는 서로 다른 호출, 서로 다른 system prompt, 서로 다른 자세로 이를 분리합니다.

덧붙이면 frame은 persona가 아닙니다. persona는 “당신은 어떤 역할이다”에 가깝고, frame은 “특정 제약과 어휘로 전체 문제를 다시 물어보라”에 가깝습니다. 앞의 것은 신분표를 바꾸고, 뒤의 것은 문제의 틀을 바꿉니다.

15개 인지 frame과 custom 방법

ADHD에는 같은 문제를 서로 다른 방향으로 비틀기 위한 15개 인지 frame이 내장되어 있습니다. codeMode는 기본적으로 코드와 설계 관점에 기울고, 매번 wild slot 하나를 남겨 발산이 너무 얌전해지지 않게 합니다.

내장 frame 예시

frame	관점
하드웨어 엔지니어	지연, 메모리 배치, 물리 제약으로 생각
규제 감사	컴플라이언스, 리스크, 책임 추적 관점으로 생각
10살 아이	가장 단순한 언어와 논리로 생각
그것을 뚫으려는 경쟁자	대립 관점에서 취약점과 약점을 찾음
생물학	진화, 생태, 대사 제약으로 생각
물류	공급망, 창고, 운송 제약으로 생각
게임 디자인	플레이어 경험, 밸런스, feedback loop로 생각
시장	가격, 경쟁자, 포지셔닝 관점으로 생각
역산	이미 성공했다고 가정하고 결과에서 거꾸로 생각
0달러 또는 무한 예산	극단적인 예산 제약으로 생각
하중 가정 제거	당연하다고 여긴 가정을 제거
speedrunner	가장 적은 단계로 목표 달성
개미 군집	분산, 무중심 협업으로 생각
새벽 3시 on-call	긴급, 피로, 자원 제한 상황에서 생각
wild slot	무작위 관점 하나를 남김

선택 규칙

• 같은 문제와 같은 seed는 같은 frame 집합을 결정적으로 선택하므로 재현하기 쉽습니다.
• codeMode는 기본적으로 code/design 관점에 기울어 있어, 엔지니어링 문제를 전혀 무관한 비유에만 맡기지 않습니다.
• 매번 wild slot 하나를 고정으로 남겨, 시스템이 지나치게 정돈된 틀 밖으로 나갈 기회를 줍니다.

custom frame

custom frame은 길게 쓸 필요가 없습니다. 핵심은 정말로 문제를 바꾸는 것입니다. 좋은 frame은 아래 세 조건 중 적어도 두 가지를 만족해야 합니다.

1. 독특한 어휘가 있어야 합니다. 단순히 “여러 각도에서 생각하라”가 아니어야 합니다.
2. 독특한 자세가 있어야 합니다. 예를 들어 대립적, 건설적, 순진한, 극단적 제약입니다.
3. 재현 가능한 왜곡이 있어야 합니다. 매번 적용했을 때 추론 방향을 안정적으로 바꿔야 합니다.

예를 들어 구독 제품에는 이런 frame을 쓸 수 있습니다.

name: subscription_retention
vocabulary: ["subscription", "retention", "churn", "renewal", "lifecycle"]
stance: "Think in terms of subscription churn and lifetime value, not one-off transactions"
distortion: "Assume users will churn; design mechanisms that reduce churn"

이 frame은 모델을 “growth manager”라고 부르는 데서 끝나지 않습니다. 문제를 retention, churn, lifetime value라는 제약 속으로 밀어 넣습니다.

언제 쓰고 언제 쓰지 말아야 하나

ADHD는 결정 지점 도구이지, 매 키 입력마다 쓰는 도구가 아닙니다. 가장 단순한 판단은 이렇습니다. junior가 Google로 찾을 수 있다면 baseline이 이깁니다. senior가 “이건 다른 각도에서 1분만 생각해 보자”라고 말할 순간에 ADHD 차례입니다.

적합한 시나리오

시나리오	왜 적합한가
아키텍처/설계 결정	비용이 크고, 여러 각도의 논증이 필요하며, 함정을 놓치기 쉬움
API/SDK/CLI 인터페이스 설계	사용자 mental model이 다양해 여러 진입점을 커버해야 함
네이밍	의미상의 모호성이 많고, 역할마다 다르게 읽을 수 있음
모호한 디버깅	원인이 불명확해 먼저 가설을 생성한 뒤 검증해야 함
마이그레이션/리팩터링 계획	성능, 보안, 호환성, 속도 사이에 충돌이 있음
code review 확장	서로 다른 reviewer의 관심사를 시뮬레이션해야 함
전략/가격 책정	비즈니스 제약이 많아 대립과 시장 관점을 넣기 좋음

부적합한 시나리오

시나리오	왜 부적합한가
사실 조회	정답이 하나라 발산이 필요 없음
원인이 알려진 bug 수정	인과관계가 명확해 발산이 수정을 늦춤
검색 한 번이면 나오는 문제	baseline이 더 빠르고 저렴함
내부 루프/키 입력 단위 저지연	30~90초 지연을 받아들이기 어려움
단일 정답 문제	여러 분기가 유효 정보를 늘리지 못함

설치와 트리거

설치 전에는 서드파티 skill 보안 검토를 먼저 하세요. 적어도 SKILL.md를 한 번 보고 Agent에게 무엇을 요구하는지, 외부 명령을 호출하는지, 원하지 않는 디렉터리를 읽거나 쓰지 않는지 확인해야 합니다. OpenClaw skill 보안 리뷰 실전 가이드의 점검 방식을 참고할 수 있습니다.

공통 설치

공통 설치 명령은 다음과 같습니다.

npx skills add UditAkhourii/adhd

이 명령은 Claude Code, Cursor, Antigravity, Codex, Cline, Gemini CLI, Windsurf 등 약 50종의 Agent를 자동 인식하고 해당 skill 파일을 설치합니다.

Codex 전용 설치

공통 명령이 Codex에 skill을 등록하지 못하면 대상을 강제로 지정할 수 있습니다.

npx skills add UditAkhourii/adhd -a codex -g

수동 설치도 가능합니다.

curl -o ~/.codex/skills/adhd/SKILL.md https://raw.githubusercontent.com/UditAkhourii/adhd/main/SKILL.md

수동 설치 후에는 Codex를 재시작해 skill 디렉터리를 다시 로드하게 합니다.

트리거 방식

트리거 방식은 다음과 같습니다.

/adhd "문제"

예를 들면 다음과 같습니다.

/adhd "CLI에서 LLM 호출이 가끔 90초 멈춘다. retry/timeout/UX는 어떻게 설계해야 할까?"

매번 자동완성에 붙이지 마세요. 더 적합한 사용법은 아키텍처, 인터페이스 설계, 네이밍, 모호한 디버깅 같은 지점에서 명시적으로 트리거하는 것입니다.

비용과 가치

비용 데이터

차원	데이터
LLM 호출 수	약 10회: N=5 발산 + 점수화 1회 + 클러스터링 1회 + K=3 심화
시간	보통 30~90초
비용 배수	단발 호출의 5~10배
Token 비용	O(N×분기당 비용), 선형 증가, N² 아님

가치 포지셔닝

공식 포지셔닝은 이렇습니다. 0.30달러 규모의 비용으로 5만 달러급 아키텍처 결정을 넓혀라. 이 말은 모든 작은 문제마다 ADHD를 돌리라는 뜻이 아니라, 열린 엔지니어링 결정의 오류 비용이 한 번의 다분기 추론보다 훨씬 클 수 있음을 상기시키는 말입니다.

실제 프로젝트에서는 컨텍스트 비용도 봐야 합니다. Claude Code나 비슷한 Agent 세션에서는 각 분기가 기본 프로젝트 컨텍스트, tool 설명, repository 규칙을 모두 로드할 수 있습니다. 순수 알고리즘으로는 O(N×분기당 비용)이지만, 실제 청구는 N×(base context + branch work)에 더 가깝습니다. 그래서 “이렇게 설계해도 되는가”라는 지점에는 맞고, “다음 한 줄 코드를 어떻게 채울까”에는 맞지 않습니다.

eval 결과 해석

ADHD 프로젝트는 자체 eval을 제시합니다. 열린 엔지니어링 문제 6개, 동일 모델, 독립 LLM 심사, A/B 순서 무작위라는 조건입니다. 이 범위는 분명히 써야 합니다. 제3자 학술 benchmark도 아니고, 인간 평가도 아닙니다.

5차원 비교표

차원	ADHD	baseline	향상
breadth(방안 폭)	9.00	4.83	1.9x
novelty(새로움)	7.83	2.67	2.9x
trap detection(함정 발견)	9.50	1.83	5.2x
actionability(실행 가능성)	9.50	6.50	1.5x
builder usefulness(builder에게 유용함)	7.67	6.83	1.1x

평가 조건의 주의

이 숫자는 방향을 설명하기에는 좋지만 권위 있는 점수처럼 인용하기에는 맞지 않습니다. “ADHD가 모든 추론 전략보다 항상 강하다”를 증명하지는 못합니다. 다만 더 좁은 판단은 뒷받침합니다. 열린 엔지니어링 문제에서 격리 발산과 별도 critic 구조는 방안의 폭, 새로움, 함정 발견을 뚜렷하게 다르게 만들 수 있습니다.

따라서 본문에서는 “업계 benchmark 선두”처럼 쓰면 안 됩니다. 더 안정적인 표현은 “프로젝트 자체 eval에서 열린 엔지니어링 문제 6개 중 5개를 ADHD가 이겼고, 특히 trap detection 차이가 컸다”입니다. 사실의 경계를 지켜야 독자가 이 숫자를 어떻게 써야 할지 압니다.

결론

ADHD에서 주목할 점은 답을 더 길게 쓰는 것이 아닙니다. “다르게 생각하기”를 구조로 만든다는 점입니다. 발산 분기는 서로 격리되고, frame은 문제를 다시 묻게 하며, critic은 따로 올라와 가지치기를 맡습니다. 이 구조는 열린 엔지니어링 문제에서 Coding Agent가 첫 번째 그럴듯한 답으로 너무 빨리 수렴하는 약점을 정확히 찌릅니다.

일상적인 키 입력 루프가 아니라 핵심 결정 지점에 두세요. 아키텍처, 인터페이스, 네이밍, 마이그레이션, 모호한 디버깅에는 30~90초를 더 쓸 가치가 있습니다. 사실 조회, 원인이 알려진 bug 수정, 한 줄짜리 boilerplate 작성에는 baseline이 더 적합합니다.

AI 코딩 도구 체인을 정리하고 있다면 2026년 AI 코딩 도구 전체 지도를 이어서 읽어 도구 지형 안에서의 위치를 볼 수 있습니다. 또는 DeepAgents 아키텍처 분석을 읽고 sub-agent와 planning tool이 더 긴 추론 체인을 어떻게 조직하는지 살펴볼 수 있습니다.