LLM은 천재이자 건망증 환자다 — AI 에이전트를 위한 인지 보철학 설계 가이드

서론: 수평선 위의 쓰나미, 그리고 건망증 천재

앤트로픽 CEO 다리오 아모데이는 이렇게 경고했다. "쓰나미가 수평선에 보이는데 사람들은 빛의 착시라고 변명한다." AI는 이미 인간 지능 수준에 근접했지만, 사회는 이를 실감하지 못하고 있다.

그런데 이 쓰나미에는 아이러니가 있다. Claude Code의 GitHub 커밋은 13개월 만에 42,896% 증가하여 하루 134,646건에 도달했고, GitHub 전체 퍼블릭 커밋의 약 4%를 차지한다. AI는 분명히 코드를 쓰고, 테스트를 만들고, PR을 생성하는 천재다.

하지만 이 천재에게 30페이지짜리 스펙 문서를 건네면 어떤 일이 벌어질까? 컬리 기술블로그의 박재영 개발자는 냉정하게 기록했다 — 중간 내용이 사라지고, 요청하지 않은 기능이 추가되며, 전체 방향이 미묘하게 어긋난다.

LLM은 인류가 만든 가장 박식한 존재이면서, 동시에 가장 심각한 건망증 환자다. 이 글은 그 모순을 정면으로 응시하고, 건망증 천재를 위한 인지 보철물(Cognitive Prosthetics)을 설계하는 방법을 탐구한다.

Part 1. LLM의 5가지 인지적 한계 — 천재의 약점 해부

컬리 기술블로그에서 박재영 개발자가 실증적으로 밝힌 LLM의 인지적 한계 5가지는, AI 에이전트를 설계하는 모든 사람이 반드시 이해해야 할 기본 소양이다.

1. Lost in the Middle — 중간 정보가 증발한다

인간에게 초두 효과(처음 정보를 잘 기억)와 최신 효과(마지막 정보를 잘 기억)가 있는 것처럼, LLM도 긴 컨텍스트의 중간 정보를 희석시킨다.

[30페이지 스펙]
├── 1~5페이지:   잘 반영됨 ✓
├── 6~25페이지:  일부 누락 가능 ⚠️  ← 핵심 보안 요구사항이 여기 있었다면?
└── 26~30페이지: 잘 반영됨 ✓

30페이지 스펙을 한 번에 넣으면, 6~25페이지의 핵심 요구사항이 조용히 사라진다. 이것이 Lost in the Middle 문제다.

2. 학습 데이터의 시점 편향 — 과거로 회귀하는 본능

대화가 길어질수록 LLM은 학습 데이터에서 더 많이 본 패턴으로 회귀한다. "Zustand를 사용해, Redux는 금지"라고 명시해도, 15턴째에는 Redux 패턴이 슬그머니 섞여 들어온다. Zustand는 2019년 등장이지만, 학습 데이터에는 Redux 예제가 압도적으로 많기 때문이다.

3. 스펙의 모호성 — 엔트로피가 높은 지시는 발산한다

"보안을 고려한 인증 시스템을 만들어줘" — 이 한 문장은 비밀번호 암호화만 의미할 수도, 2FA 도입일 수도, OAuth 2.0 + JWT + 세션 관리 전체일 수도 있다. LLM은 확률적으로 하나를 선택하고, 그 선택이 전체 구현을 지배한다.

4. 오류 중첩 — 자기회귀의 눈덩이 효과

LLM은 자기회귀(autoregressive) 방식이다. 초반의 작은 오해가 눈덩이처럼 커진다. "보안을 고려"를 "2FA가 필요하겠군"으로 해석하면, 세션 관리 → 에러 처리 → UI → 테스트까지 모두 2FA 전제로 구현된다. 요청하지 않은 2FA가 시스템 전체에 녹아든다.

5. 작업 기억의 한계 — 4개 이상은 동시에 못 잡는다

인간의 작업 기억 용량은 4±1개(Cowan, 2001). GPT-4조차 n-back 테스트에서 3개 이상 항목을 동시에 추적하면 성능이 급격히 떨어진다(Zhang et al., 2024 EMNLP). 가장 치명적인 차이는 — 인간은 불필요한 정보를 내려놓을 수 있지만, LLM은 컨텍스트에 들어온 모든 정보를 계속 들고 있어야 한다는 것이다.

Part 2. 컨텍스트 엔지니어링 — 프롬프트를 넘어 '세계'를 설계하다

프롬프트 엔지니어링이 "LLM에게 뭐라고 말할까"에 집중했다면, 컨텍스트 엔지니어링은 "LLM이 사는 세계를 어떻게 구축할까"를 묻는다. 이것은 단순한 용어 변경이 아니라, 패러다임의 전환이다.

프롬프트 엔지니어링 vs 컨텍스트 엔지니어링

Weaviate의 컨텍스트 엔지니어링 가이드는 이를 6가지 핵심 구성요소로 정리한다.

컨텍스트 엔지니어링의 6가지 구성요소

1. Agents (에이전트) — 의사결정의 두뇌. 다른 5개 구성요소를 조율한다.
2. Query Augmentation (쿼리 증강) — 사용자의 질문을 해석하고 풍부하게 만든다.
3. Retrieval (검색) — 필요한 정보를 적시에 가져온다. RAG의 핵심이다.
4. Memory (기억) — 세션 간 맥락을 유지한다. 건망증 천재에게 가장 필요한 보철물이다.
5. Tools (도구) — LLM이 외부 세계와 상호작용하는 손과 발이다.
6. Prompting (프롬프트) — 여전히 중요하지만, 전체의 일부일 뿐이다.

핵심은 "더 좋은 프롬프트를 작성하는 것만으로는 LLM의 근본적 한계를 해결할 수 없다"는 인식이다. 모델 주위에 시스템을 구축해야 한다.

RAG는 여전히 필요한가?

IBM Technology의 분석에 따르면, 100만 토큰 이상의 컨텍스트 창이 열렸음에도 RAG는 여전히 필요하다. 그 이유는 명확하다.

• 컴퓨팅 효율성: 25만 토큰의 매뉴얼을 매 쿼리마다 처리하는 것은 막대한 비효율
• '건초 더미 속 바늘' 문제: 50만 토큰 이상에서 어텐션 메커니즘이 희석되어 중간에 묻힌 정보를 놓침
• 무한 데이터 처리: 기업 데이터는 테라바이트/페타바이트 규모. 어떤 컨텍스트 창도 이를 담을 수 없다

Long Context는 제한된 데이터의 복잡한 전역 추론에, RAG는 무한 데이터의 정밀 검색에 각각 최적이다. 둘은 대체재가 아니라 보완재다.

Part 3. 에이전틱 워크플로우 — 건망증을 시스템으로 극복하다

LLM의 인지 한계를 극복하기 위해 지금까지 발전해온 해결책의 흐름을 보면 분명한 패턴이 보인다.

Chain of Thought (2022) — 출력 텍스트 자체가 "외부 메모지"
Extended Thinking (2024~) — thinking tokens으로 추론 단계 추가
에이전트 루프 (2025~) — Plan→Act→Verify 반복, 파일시스템을 외부 작업 공간으로 활용

이 흐름의 결론은 명쾌하다: LLM 내부에 작업 기억을 만든 게 아니라, 외부에 작업 공간을 제공하는 방식이다. 에이전틱 워크플로우 패턴은 바로 이 원리를 체계화한 것이다.

핵심 에이전틱 워크플로우 6+3 패턴

각 패턴은 LLM의 특정 인지 한계에 대한 시스템 수준의 보상 장치다. 예를 들어 Prompt Chaining은 "한 번에 30페이지를 주지 말고, 3페이지씩 10번에 나눠서 주라"는 것이고, 이는 Lost in the Middle과 작업 기억 한계를 동시에 우회한다.

Part 4. MCP의 역발상 — 도구가 AI를 부르는 시대

MCP(Model Context Protocol)는 원래 AI가 도구를 호출하기 위한 프로토콜이었다. Ouroboros 프로젝트는 이를 정확히 뒤집었다.

기존 MCP vs Ouroboros 역방향 MCP

Ouroboros의 구조는 이렇다: MCP 호출 하나를 던지면, 그 안에서 Coordinator가 작업을 쪼개고, 각 작업마다 Claude SDK로 새로운 AI 세션을 띄워서 실행한다. 동시에 할 수 있는 건 병렬로, 순서가 필요한 건 순차로. 전부 끝나면 결과만 돌려준다.

이것이 왜 혁명적인가? 메인 세션의 컨텍스트가 오염되지 않는다. 건망증 천재에게 모든 일을 시키는 대신, 업무별로 새로운 천재를 불러오는 것이다. 마치 운영체제가 프로그램을 실행하면 OS가 자원을 배분하고 스케줄링하는 것처럼.

Part 5. SDLC에서 ADLC로 — 개발 사이클 자체가 인지 아키텍처다

LLM의 인지 한계를 이해하면, 소프트웨어 개발 사이클 자체가 왜 변해야 하는지가 명확해진다. SDLC(Software Development Lifecycle)에서 ADLC(Agentic Development Lifecycle)로의 전환은 단순한 도구 교체가 아니라, 개발 사이클의 철학이 "순차적 생산"에서 "지속적 지능 협업"으로 이동하는 것이다.

SDLC vs ADLC 핵심 비교

여기서 가장 의미 있는 개념은 "Write Skills"이다. 에이전트가 사용할 도구, 프롬프트, 규칙, 능력을 설계하는 단계 — 이것은 곧 에이전트를 위한 인지 보철물을 제작하는 행위다.

리니어(Linear) CEO가 "이슈 트래킹은 죽었다"고 선언한 것도 같은 맥락이다. 바이브 코딩 시대에 기획서 3일 쓸 시간이면 프로토타입 3일 만드는 것이 효율적이다. 프로토타입 비용이 제로에 가까운 지금, 사람의 역할은 실행자에서 의사결정자로 전환된다. 사람에게 남는 것은 의도(Intent), 판단(Judgment), 취향(Taste) — 이 세 가지다.

Part 6. 인지부채 경고 — 천재에게 모든 걸 맡기면 인간이 바보가 된다

여기까지 읽으면 자연스럽게 "그러면 모든 걸 AI에게 맡기면 되지 않나?"라는 생각이 든다. 하지만 MIT Media Lab의 연구(2025.06)가 냉정한 경고를 보낸다.

MIT 연구: "Your Brain on ChatGPT"

54명의 참여자를 LLM 그룹 / 검색엔진 그룹 / 뇌만 사용 그룹으로 나누어 4개월간 추적한 결과:

더 충격적인 것은 교차 실험 결과다. 4개월간 LLM에 의존한 후 뇌만 사용하도록 전환했더니, 알파·베타파가 저하된 상태에서 회복되지 않았다.

기술부채 vs 인지부채

IT 역사에도 유사한 패턴이 있다. ORM/JPA가 SQL 없이 쿼리를 처리해주었지만, 결국 쿼리 성능 저하와 SQL 역량 소멸을 초래했다. 깊은 지식 없이 지름길을 제공하는 도구는 단기 각광 → 장기 역량 격차를 만든다.

Part 7. 실전 설계 원칙 — 인지 보철물 5가지 제작법

지금까지의 분석을 종합하여, AI 에이전트를 위한 인지 보철물 설계 5원칙을 제안한다.

원칙 1: 정보를 쪼개라 — Multi-turn Small Requests

30페이지를 한 번에 주지 말라. 3페이지씩 10번에 나눠라. Lost in the Middle을 직접 우회한다. Prompt Chaining 패턴의 핵심이다.

원칙 2: 규칙을 명시하라 — CLAUDE.md / 시스템 프롬프트

LLM은 학습 데이터의 관성이 있다. "Zustand만 사용, Redux 금지"는 한 번 말해서는 안 된다. 매 세션의 시스템 프롬프트에 명시해야 한다. Petabridge의 경험에서도, 시스템 프롬프트 없이는 LLM이 MCP 도구를 자발적으로 호출하지 않는다.

원칙 3: 검증 루프를 만들라 — Plan Mode + Checklist

스펙 모호성과 오류 중첩을 막는 가장 확실한 방법은 사전 검증이다. 구현 전 Plan Mode로 계획을 확인하고, Todo 체크리스트로 진행을 추적한다. Evaluator-Optimizer 패턴의 실전 적용이다.

원칙 4: 컨텍스트를 분리하라 — Sub-agent / Ouroboros 패턴

하나의 긴 대화에서 모든 것을 하려 하지 말라. 작업별로 독립 세션을 만들어 컨텍스트 오염을 방지한다. Ouroboros의 MCP 역방향 패턴이 이를 가장 우아하게 해결했다.

원칙 5: 주기적으로 정리하라 — Compact / Context Cleanup

LLM은 불필요한 정보를 내려놓지 못한다. 대화가 길어지면 적극적으로 요약하고, 완료된 작업의 세부사항을 제거하여 작업 기억 공간을 확보한다.

결론: 인지 아키텍처, 설계하지 않으면 무너진다

AI 시대의 핵심 병목은 더 이상 타자 속도가 아니다. 아키텍처 선택이다.

• Agile = 액셀 (속도)
• Architecture = 핸들 (방향)
• AI = 엔진 (동력)

핸들 없이 엔진만 밟으면 재앙이다. "잘못된 길 위에서의 속도는 재앙이다."

LLM은 인류가 만든 가장 강력한 엔진이다. 하지만 이 엔진에는 치명적인 인지적 결함이 있다. 중간을 잊어버리고, 과거로 회귀하며, 모호함 앞에서 발산하고, 실수를 눈덩이처럼 키우며, 4개 이상의 항목을 동시에 추적하지 못한다.

이 결함을 이해하지 않고 "AI에게 다 시키면 된다"고 생각하는 것은, 브레이크 없는 스포츠카를 타고 고속도로에 진입하는 것과 같다. 반대로, 이 결함에 대한 인지 보철물 — 컨텍스트 엔지니어링, 에이전틱 워크플로우, MCP 역방향 패턴, ADLC — 을 올바르게 설계하면, 건망증 천재는 그 어떤 인간 팀보다 빠르고 정확하게 목표를 달성할 수 있다.

다만, 하나만 잊지 말자. 천재에게 모든 걸 맡기면 인간이 바보가 된다. 인지부채는 기술부채처럼 보이지 않게 쌓이고, 복리로 청구된다. AI는 초안과 검토의 파트너로, 핵심 사고는 여전히 인간의 몫으로 — 이것이 건망증 천재와 공존하는 유일한 방법이다.

셀프 평품: 이 글의 작성동기와 검색전략

작성동기

기존 웹노리 기사 12편을 분석한 결과, 하네스 엔지니어링·Pencil Creator·CLI 도구 등 실무 도구 중심의 글이 주류였다. AI 에이전트의 근본적 설계 철학을 다룬 글은 없었다. "왜 AI 에이전트가 가끔 엉뚱한 결과를 내는가?"라는 질문에서 출발하여, LLM의 인지적 한계를 정면으로 해부하고 시스템 수준의 해결책을 종합하는 글이 필요하다고 판단했다.

검색전략

메모라이저에서 4가지 축으로 다각 검색을 실시했다:

1. "AI 에이전트 최신 트렌드" — AI 네이티브 기업 전환, 경량 문명, 에이전트 도입 성공 전략 등 거시적 맥락 확보
2. "LLM 프롬프트 엔지니어링 기법" — 에이전틱 워크플로우 9가지 패턴, 바이브 코딩 전략, ReAct 프레임워크 등 기술적 패턴 확보
3. "AI 자동화 워크플로우 실전 사례" — SDLC→ADLC, Claude Code 커밋 증가, AI 기반 개발 방법론 등 실증 데이터 확보
4. "MCP model context protocol" — MCP 상세 구현, 역방향 활용(Ouroboros), A2A 프로토콜 등 최신 프로토콜 트렌드 확보

추가로 "인지부채 기술부채", "SDLC ADLC", "컨텍스트 엔지니어링" 키워드로 심층 검색하여 MIT 연구, 컬리 기술블로그, Weaviate eBook 등 핵심 소스를 발굴했다.

주제 채택 사유

검색 결과를 교차 분석하면서, 여러 독립적 자료들이 하나의 서사로 수렴하는 것을 발견했다:

• 컬리 기술블로그의 LLM 인지 한계 5가지가 문제의 정의
• 컨텍스트 엔지니어링과 에이전틱 워크플로우가 시스템 수준의 해결책
• Ouroboros의 MCP 역방향 패턴이 가장 참신한 기술적 인사이트
• SDLC→ADLC가 개발 문화 차원의 변화
• MIT의 인지부채 연구가 균형 잡힌 경고

이 다섯 줄기를 "인지 보철학(Cognitive Prosthetics)"이라는 하나의 메타포로 엮으면 — LLM의 한계를 인정하면서도 그 한계를 시스템으로 보상하는 설계 철학 — 기존에 없던 독창적 서사가 완성된다고 판단했다.

글쓰기 전략

• 역설적 타이틀: "천재이자 건망증 환자"라는 모순으로 독자의 호기심을 자극
• 문제→원인→해결→경고 구조: 단순 기술 소개가 아닌, 논리적 서사 흐름 설계
• 다중 출처 교차 인용: 11개 이상의 독립 출처를 교차하여 주장의 신뢰성 확보
• 실무 적용 가능성: Part 7의 5가지 설계 원칙으로 이론을 실전으로 착지
• 균형 잡힌 경고: "AI 만능론"에 빠지지 않도록 인지부채 섹션으로 균형 유지