AI 에이전트에게 ADHD를 부여했더니 추론 능력이 두 배로 향상됐다.

 
AI 에이전트에게 ADHD를 부여했더니 추론 능력이 두 배로 향상됐다.
이걸 실제 상황에 적용한다면 최소 1.5배 이상으로 향상된다고도  할 수 있겠지만 , 역시나 두뇌를 부정적으로 부적절하게 의도적으로 그리고 반복적으로  소비  또는 낭비하는  무쓸모 두뇌에는 해당되지 않는다고 할 수  있다.
 

 

Table of Contents

• ADHD brains are not bad at thinking. They’re bad at choosing one thread.
• What “attention collapse” actually looks like in an agent
• Three ADHD traits, three architectural rules
• Same query, two agents, two very different answers
• The full implementation
• Why Groq specifically changes the latency math
• When to use this and when not to

ADHD 뇌는 생각에 나쁜 것이 아닙니다. 하나의 스레드를 선택하는 것이 나쁜 것입니다. 즉, 선택의 문제입니다.

제가 제대로 이해하는 데 꽤 시간이 걸렸던 사실이 하나 있습니다. ADHD는 주의력 결핍이 아닙니다. 주의력 조절의 결핍입니다. ADHD를 가진 뇌는 집중하는 데 어려움을 겪는 것이 아닙니다. 한 가지 일을 끝내기도 전에 다른 일을 시작하려는 충동을 멈추는 것, 중요할지도 모르는 신호를 무시하는 것, 다른 세 가지 길도 흥미로울 때 단 하나의 길에만 집중하는 데 어려움을 겪습니다. 물론, 의도적이고도 역겨운 책임회피 와 그에 따른 합리화 등은 제외하고도 말이죠.


이건 마치 버그처럼 들립니다. 서로 연결된 여러 층으로 이루어진 추론 과제의 경우, 이는 오히려 장점이 됩니다.

저는 제 연구용 에이전트가 실패하는 방식에서 일정한 패턴을 발견한 후 이 점에 대해 생각하기 시작했습니다. 명백한 실패가 아니라, 에이전트가 정답을 찾아내고는 멈춰 버려, 바로 인접한 층에 더 중요한 답이 있다는 사실을 전혀 눈치채지 못하는 미묘한 실패들 말입니다.

ADHD를 가진 뇌는 거기서 멈추지 않을 것입니다. 여전히 그 인접한 실마리를 계속 쫓아갈 것입니다.  물론 자신의 결정에 따른 책임회피와 그에 따른 자기 합리화로 비정상적이고도 예외적인 활용을 의도적으로 하는 경우도 있습니다.

에이전트에서 "주의력 붕괴"가 실제로 어떤 모습인지

일반 에이전트는 초기에 “이것이 핵심 관점이다”라고 판단합니다. 그 후 모든 단계는 이 판단을 바탕으로 진행됩니다. ReAct 에이전트에게 기술 문서의 위험 요소를 분석해 달라고 요청하면, 해당 에이전트는 위험 요소 섹션을 찾아 읽어본 뒤 결과를 보고합니다. 작업 완료. 기술적으로는 정확합니다.

하지만 놓치는 부분이 있습니다. 아키텍처 다이어그램에 숨겨진 위험, 위험 섹션과 모순되는 구현 노트 속의 무심코 던진 한 마디, 세 개의 별도 섹션을 동시에 살펴봐야만 드러나는 패턴 등이 바로 그것입니다.

저는 이를 ‘주의력 붕괴(attention collapse)’라고 부릅니다. 에이전트는 첫 단계에서 특정 프레임에 고정되고, 그 프레임이 이후 인지하는 모든 것을 결정합니다.

이는 모델 성능의 문제가 아닙니다. GPT-4나 Llama 70B에서 실행해도 똑같은 실패를 겪게 됩니다. 이는 구조적인 문제입니다. 시스템이 모든 결정 지점에서 다음 단계를 하나만 선택해야 할 때, 터널 비전을 갖게 됩니다.

ADHD의 세 가지 특징, 세 가지 설계 원칙

바로 여기서 이 비유가 유용해집니다. 에이전트에 의도적으로 반영될 경우, 복잡한 쿼리를 처리하는 방식을 변화시키는 세 가지 구체적인 ADHD 인지적 특성이 있습니다.

첫 번째 특성: 어떤 하나의 스레드에도 완전히 몰두하지 않는다

ADHD 사고방식은 여러 탐색 스레드를 동시에 생성합니다. 스레드 A가 해결되기를 기다리지 않고 바로 스레드 B를 시작합니다. 그 결과, 순차적 효율성을 희생하는 대가로 더 넓은 범위를 커버할 수 있습니다.

이를 아키텍처로 해석하면, 어떤 검색이나 추론을 수행하기 전에 쿼리에 대해 세 가지 서로 다른 관점을 생성해야 합니다. 같은 관점의 변형이 아니라, 각각 서로 다른 정보를 도출해 낼 가능성이 높은 진정으로 다른 프레임워크여야 합니다. 그런 다음 결과를 비교하기 전에 이 세 가지를 모두 병렬로 탐색합니다.

특성 2: 각 스레드는 자신의 영역에 극도로 집중한다

이것이 바로 대부분의 사람들이 ADHD 사고방식에서 간과하는 부분입니다. 한 번 스레드가 시작되면 깊이 파고듭니다. 세 가지를 반쯤만 탐구하지 않습니다. 다른 것들로부터의 상호 간섭 없이, 각각을 독립적으로 완전히 탐구합니다.

아키텍처로 해석하면: 각 탐색 분기는 특정 관점을 부여받으며, 오직 그 관점만을 추구해야 합니다. “정량적 신호가 무엇을 시사하는가”에 집중하는 탐색자는 정성적 맥락에 주의를 빼앗겨서는 안 됩니다. 관점의 특이성이야말로 분기들이 중복되지 않고 상호 보완적으로 작용하게 만드는 요소입니다.
Trait t세 번째 특징: 예상치 못한 연결이 바로 핵심이다
ADHD를 가진 사람들의 뇌는 집중력만 있고 단선적인 사고 방식으로는 결코 발견할 수 없는 생각의 실타래들 사이에 연결 고리를 만들어 냅니다. 그 가치는 어느 하나의 실타래에 있는 것이 아닙니다. 모든 실타래를 동시에 비교했을 때 드러나는 것에 있습니다.

이를 건축학에 비유하자면, 종합 단계는 단순한 요약이 아닙니다. 이는 교차 엔트로피 분석 과정으로, 한 가지 분기에서는 존재하지만 다른 분기에는 없는 정보를 구체적으로 찾아내고, 분기들 간의 모순을 파악하며, 세 가지를 동시에 고려했을 때만 나타나는 패턴을 발견하는 과정입니다.

이 세 가지 특성은 구현의 세 가지 구성 요소, 즉 ‘다각화’, ‘병렬 탐색’, ‘종합’이 됩니다.

Same query, two agents, two very different answers

코드 실행 전, 출력 결과입니다. 동일한 문서, 동일한 질문입니다.
Query: “What are the key risks in this system design document?”
Linear agent output:

The document identifies three main risks:
1. Scalability under load (Section 3)
2. Third-party API dependency (Section 4)
3. Data migration complexity (Section 7)

These are documented in the risk register with mitigation plans.

ADHD agent output:

Three threads surfaced different risk signals:

Quantitative thread: The load estimates in Section 3 assume 500 concurrent users,
but the infrastructure diagram (Appendix B) is sized for 200. That gap is
unaddressed anywhere in the risk register.

Implementation thread: Section 6 says the migration runs in a single transaction.
For the data volumes in Section 2 (18M rows), that's a 4-6 hour lock window.
Section 7 lists "data migration complexity" as a risk but doesn't mention the
lock duration or its operational impact.

Contradiction thread: The risk register (Section 7) marks the third-party API
dependency as "low risk, mitigated." The vendor contract summary in Appendix C
shows the SLA is 99.5%, not 99.9% as assumed in the system's availability
calculations. The mitigation plan doesn't account for this discrepancy.

Cross-thread finding: Two out of three threads independently surfaced a capacity
assumption mismatch. The risk register does not reflect this.

선형적 사고를 하는 담당자는 위험 등록부에 기재된 내용을 파악했습니다. ADHD 성향을 가진 담당자는 위험 등록부에 명시된 내용과 문서의 나머지 부분에서 암시하는 내용 사이의 괴리를 발견했습니다. 바로 그 괴리가 실제 위험입니다.

 

The full implementation(전체 구현)

따라서 LLM 제공자로 Groq를 사용하고, Python을 활용해 이 시스템을 구축할 것입니다.

import asyncio
import os
from dataclasses import dataclass, field
from groq import AsyncGroq

client = AsyncGroq(api_key=os.environ["GROQ_API_KEY"])
MODEL = "llama-3.3-70b-versatile"  # free tier on Groq

@dataclass
class Branch:
    angle: str
    findings: str = ""

@dataclass
class ResearchResult:
    query: str
    branches: list[Branch] = field(default_factory=list)
    synthesis: str = ""

TypedDicts 대신 Dataclasses를 사용하세요. 인스턴스화하기 더 간단하고, 런타임에 검사하기 쉬우며, asyncio를 사용하여 직접 동시성을 관리할 때 LangGraph 상태 관리 메커니즘이 필요하지 않습니다.
 

async def generate_angles(query: str) -> list[str]:
    """Generate three distinct exploration angles for the query."""
    response = await client.chat.completions.create(
        model=MODEL,
        messages=[
            {
                "role": "system",
                "content": (
                    "You are a research strategist. Given a query, return exactly "
                    "three numbered lines. Each line is a distinct angle to investigate. "
                    "Angles must be genuinely different - quantitative, qualitative, "
                    "and adversarial (what could be wrong or missing). "
                    "No preamble. Just the three lines."
                ),
            },
            {"role": "user", "content": f"Query: {query}"},
        ],
        temperature=0.8,
        max_tokens=300,
    )

    raw = response.choices[0].message.content.strip()
    lines = [line.lstrip("123. ").strip() for line in raw.splitlines() if line.strip()]
    return lines[:3]

세 가지 고정 관점 유형: 정량적(숫자, 지표, 측정값), 정성적(의도, 맥락, 함의), 대립적(무엇이 잘못되었는지, 무엇이 누락되었는지, 무엇이 모순되는지). 이 세 가지 범주는 문서 분석 작업에서 서로 다른 정보를 확실하게 도출해 냅니다. 재표현이 아닌 진정한 차이를 확보하기 위해 온도 값을 0.8로 설정합니다.
 

async def explore_angle(query: str, angle: str) -> Branch:
    """Explore one angle independently. No cross-contamination from other branches."""
    response = await client.chat.completions.create(
        model=MODEL,
        messages=[
            {
                "role": "system",
                "content": (
                    "You are a focused researcher with one job: investigate your "
                    "assigned angle thoroughly. Do not drift into other angles. "
                    "Report specifically what your angle reveals. Include what you "
                    "looked for and did not find. Be direct and specific."
                ),
            },
            {
                "role": "user",
                "content": (
                    f"Query: {query}\n\n"
                    f"Your angle: {angle}\n\n"
                    "What does this angle reveal?"
                ),
            },
        ],
        temperature=0.3,
        max_tokens=600,
    )
    return Branch(
        angle=angle,
        findings=response.choices[0].message.content.strip(),
    )

이 단계의 온도 값은 0.3으로, 발산 단계와는 반대입니다. 창의적인 각도 생성을 원한다면, 각 각도 내에서 집중적인 실행이 필요합니다. 온도를 낮게 유지하면 각 분기가 제 궤도를 따르게 됩니다. 탐색 단계에서 0.8을 사용하면 분기들이 서로의 영역으로 침범하기 시작하여 상호 보완성이 사라집니다.
 

async def synthesize(query: str, branches: list[Branch]) -> str:
    """Cross-entropy pass: find what each branch has that the others don't."""
    branches_text = "\n\n".join(
        f"Angle: {b.angle}\nFindings: {b.findings}" for b in branches
    )
    response = await client.chat.completions.create(
        model=MODEL,
        messages=[
            {
                "role": "system",
                "content": (
                    "You are a senior analyst with findings from three independent "
                    "research threads. Your job is not to summarize each thread. "
                    "Your job is to find:\n"
                    "1. What each thread found that the others did not\n"
                    "2. Direct contradictions between threads\n"
                    "3. The pattern or conclusion that only emerges when all three "
                    "are visible simultaneously\n\n"
                    "Label your cross-thread finding explicitly. That's the value."
                ),
            },
            {
                "role": "user",
                "content": f"Query: {query}\n\n{branches_text}",
            },
        ],
        temperature=0.2,
        max_tokens=800,
    )
    return response.choices[0].message.content.strip()

async def adhd_agent(query: str) -> ResearchResult:
    """Run the full diverge-explore-synthesize loop."""
    result = ResearchResult(query=query)
    # Step 1: generate angles
    result.branches = [Branch(angle=a) for a in await generate_angles(query)]
    # Step 2: explore all angles simultaneously
    explored = await asyncio.gather(*[
        explore_angle(query, b.angle) for b in result.branches
    ])
    result.branches = list(explored)
    # Step 3: cross-entropy synthesis
    result.synthesis = await synthesize(query, result.branches)
    return result

‘explore’ 단계에서 호출되는 asyncio.gather가 바로 병렬 실행이 이루어지는 부분입니다. 세 가지 분기 모두 동시에 실행됩니다. 어느 분기도 다른 분기를 기다리지 않습니다. ‘generate_angles’와 ‘synthesize’ 단계는 앞 단계의 결과를 필요로 하기 때문에 순차적으로 실행됩니다. 병렬 처리는 분기들이 서로 독립적인 ‘explore’ 단계에서만 의미가 있습니다.

# Run it
async def main():
    query = "What are the key risks in this system design document?"
    result = await adhd_agent(query)
    print("=== Individual branches ===")
    for branch in result.branches:
        print(f"\nAngle: {branch.angle}")
        print(branch.findings)
    print("\n=== Cross-thread synthesis ===")
    print(result.synthesis)

if __name__ == "__main__":
    asyncio.run(main())

이 프로그램을 실행하려면 패키지 하나와 환경 변수 하나가 필요합니다.
 

pip install groq
export GROQ_API_KEY=your_key_here
python adhd_agent.py

이것이 전체 구성입니다. 오케스트레이션 프레임워크도, 벡터 저장소도, 그래프 정의도 없습니다. 이 아키텍처는 세 개의 비동기 함수와 하나의 asyncio.gather 호출로 이루어져 있습니다.
 

 
이 패턴을 사용할 때와 사용하지 말아야 할 때
이 패턴이 모든 경우에 개선 효과를 주는 것은 아닙니다. 솔직한 분석은 다음과 같습니다.

따라서 쿼리에 명백하지 않은 여러 층위가 존재할 때 이 패턴을 사용하세요. 문서 위험 분석, 기술 실사, 연구 종합 등, “그 부분에 대한 섹션이 있다”는 답변만으로는 불충분하고 실제 핵심 정보가 문서 전체에 분산되어 있는 모든 경우에 해당합니다. 이러한 작업들은 모델이 아무리 뛰어나더라도 선형 에이전트가 지속적으로 저조한 성과를 보이는 영역입니다.

사실 확인을 위한 조회에는 사용하지 마세요. “이 구성 파일의 타임아웃 설정은 무엇인가요?”와 같은 질문에는 세 가지 관점이 필요하지 않습니다. 정확한 검색 결과 하나면 충분합니다. 단순한 쿼리에 ADHD 패턴을 적용하는 것은 낭비입니다. 세 번의 LLM 호출 비용을 지불하고, 모두 같은 사실을 찾아내며, 종합기는 “모든 스레드가 일치합니다”라고 보고할 뿐, 아무 소용 없이 3초의 지연 시간만 추가하게 됩니다.

순차적인 감사 추적이 필요한 경우에는 사용하지 마세요. 에이전트가 어떻게 결론에 도달했는지 단계별로 정확히 보여줘야 한다면, 병렬 분기는 이를 더 어렵게 만듭니다. 선형 ReAct 체인은 추론 과정이 단일하고 추적 가능한 경로이기 때문에 설명 가능성 측면에서 실제로 더 우수합니다.

유용한 사고 모델: 이 문제를 해결하는 인간 전문가가 결론을 내리기 전에 자연스럽게 여러 각도에서 살펴보고 싶어 할 것이라면, ADHD 패턴을 사용하세요. 답이 한 곳에 있고 그저 그것을 찾기만 하면 된다면, 표준 검색을 사용하세요.
 
세 가지 고정된 관점에 대한 참고 사항
‘정량적, 정성적, 대립적’ 관점이 유일한 유효한 관점 체계는 아닙니다. 이는 제가 테스트한 문서 분석 작업 전반에서 가장 효과적이었던 관점일 뿐입니다. 코드 검토 작업의 경우 ‘정확성, 성능, 보안’을, 비즈니스 분석의 경우 ‘재무적, 운영적, 전략적’ 관점을 사용할 수 있습니다.

핵심은 관점들이 진정으로 직교적이어야 하며, 각 관점이 다른 관점과는 다른 정보를 도출해 낼 가능성이 높아야 한다는 점입니다. 만약 두 관점이 계속해서 동일한 결과를 반환한다면, 그 관점들은 충분히 직교적이지 않은 것입니다. 이는 실패가 아니라 조정이 필요하다는 신호입니다. generate_angles 시스템 프롬프트를 조정하여 모델이 더 다양한 관점으로 접근하도록 유도하세요.

함께 계속 연구하고 배워나갑시다
이 글이 에이전트의 추론 방식이나 병렬 탐색을 구성하는 방법에 대해 색다른 시각을 갖는 데 실제로 도움이 되었나요? 여러분의 의견을 듣고 싶습니다.  라고 하기에는 실생활에 응용하여 그 결과를 도출해 낼 수 있다.

하지만, 실생활에서는 최종 의사 결정 과 추론에 따른 실천력을 위한 성실함이 중요한데 이 두가지 요소만 결합된다면 더할나위 없다.  만약 컴퓨터가 여전히 존재한다면 실제로 구축해서 응용해 볼 필요성은 여전히 존재한다.

카테고리별 요약
① 아침 루틴 (4개)
- 운세, 주간 식단, 매일 시 이메일, ENFP 아침 인텐션 메일
- 예상보다 효과 좋았음: "아침에 정보를 소비하지 않고 그냥 생각하는 시간"의 가치
② 집중력 관리 (4개)
- AI가 캘린더 gap을 찾아 자동 focus block 생성
- #mute 메일 보내면 폰 자동 무음, 통화 종료 시 DND 해제
- 실제로 써보니 "방해 받기 전에 방지하는 게 이렇게 큰 차이일 줄 몰랐다"
③ 저축/지출 (4개)
- Slickdeals 할인 다이제스트, Splitwise → Discord 공유
- Instagram 사진 올릴 때마다 Qapital 자동 저축 — "습관이 저축을 밀어주는 피드백 루프"
④ 태스크 관리 (4개)
- Google Calendar 이벤트 시작 시 Todoist 태그 자동 생성
- Trello 카드 → Todoist + 알림
- "도구 사이 정보 옮기는 데 쓰던 정신 에너지가 사라졌다"
⑤ 독서/호기심 (4개)
- RSS → iOS Reminders + 캘린더 + Reading List 한번에
- r/FreeEBOOKS → 일일 이메일 다이제스트
- Bluesky에 RSS 자동 포스팅
⑥ 건강 (4개)
- Oura Ring readiness score → 아침 이메일 자동 발송
- Strava 활동 → Google Calendar에 자동 등록
- Strava 완료 → Monzo 저금통 자동 저축
결론
"가장 좋은 자동화는 인상적인 게 아니라, 눈에 띄지 않는 것이다. 쓸만한 Applet은 단순히 '한 단계를 줄여주는' 게 아니라, 그 단계를 생각할 필요 자체를 없애준다."
한 번에 24개 다 할 필요 없고, "지금 가장 귀찮은 일 하나" 골라서 하나만 진행해보라는 게 조언.