요약문 100편보다 원본 1편이 낫다. 이건 내가 투자 5.5년을 하면서 뼈로 배운 원칙이다. 유튜브 매크로 영상이 아닌 1차 뉴스와 원문 보고서를 읽을 때 엣지가 생겼다. AI-native 개발에서도 같다. 유튜브 “AI로 SaaS 하루 만에” 클립이 아니라, 실제 이 문제를 풀고 있는 사람들의 원본 글을 읽어야 한다.
이 글은 내가 지난 한 달 동안 직접 읽은 다섯 개의 원본 자료에 대한 기록이다.
사전이해 — 왜 원본인가
요약은 결론을 옮긴다. 원본은 과정까지 담는다. 저자가 무엇을 시도했다 버렸는지, 어떤 제약 아래에서 이 결정이 나왔는지, 어떤 실패 데이터가 있었는지. 이 세 가지가 빠지면 남의 결론을 복사할 뿐이다.
AI 시대엔 원본의 가치가 더 올라간다. AI가 요약을 너무 잘하기 때문이다. 남들이 요약을 복붙하는 동안 내가 원본을 읽으면, 그것만으로 정보 우위가 생긴다.
문제 — 검색이 주는 레퍼런스의 한계
“AI로 대규모 프로젝트” 또는 “AI-native 개발자"를 검색하면 나오는 글은 대체로 두 부류다. 마케팅 톤 (“이걸 하면 10배 빨라진다”) 또는 일반론 (“컨텍스트가 중요하다”). 실무자가 원하는 “왜 이렇게 했는가"는 빠져 있다.
그 “왜"는 네 곳에 있다.
- 동료검증 논문 (arXiv, OOPSLA 등)
- 공식 문서 (제품 팀의 설계 결정이 박혀 있음)
- GitHub 이슈·PR (실시간 설계 토론)
- 원저자 에세이 (동기와 실패를 솔직히 밝힘)
나는 이 네 곳에서 자료를 뽑았다.
핵심 — 읽은 다섯 자료
1. Simon Willison · 개인 블로그
유형: 원저자 에세이 · 분량: 거의 매일 1편, 한 달 정독 기준 ~20편 URL: simonwillison.net
Django 공동 창작자이자 지금 LLM 블로깅의 사실상 표준. 특히 “My LLM codegen workflow atm”에서 “내가 설명할 수 없는 코드는 커밋하지 않는다"는 원칙을 만났다. 그의 블로그는 페리컨 SVG 렌치(유명한 모델 비교 벤치마크)부터 실제 프로젝트 디버깅까지 넓은데, 공통점은 그라운딩이다. 과장이 없다.
얻은 것: 매일 업데이트되는 실무자의 관찰 기록이 유튜브 영상 50편보다 낫다는 확신. 그리고 Harper Reed 3단계 워크플로우 링크를 여기서 발견.
2. Harper Reed · “My LLM codegen workflow atm”
유형: 원저자 에세이 · 분량: 긴 한 편 URL: harper.blog/2025/02/16/my-llm-codegen-workflow-atm
Obama 2012 캠프 CTO였던 사람의 개인 블로그. 솔로 빌더용 3단계 루프를 공식화한 글이다.
스펙(spec.md) → 플랜(prompt_plan.md) → 실행(순차 프롬프트)
핵심 문장을 그대로 인용한다:
“Start with a conversational back-and-forth to iterate on a comprehensive spec, ask questions one at a time.”
즉, 한 번에 하나씩 질문하며 스펙을 만들게 하라는 것. Reed는 본인이 “팀으로 쓰긴 어렵다, 봇들이 충돌한다"고 솔직히 밝혔다. 솔로용으로 최적화된 워크플로우라 지금 나한테 맞았다.
얻은 것: Alpha Court의 새 기능 개발에 이 3단계를 그대로 적용 중. spec.md·prompt_plan.md·todo.md를 분리하고 나서 구현 속도보다 판단 속도가 올라갔다.
3. Anthropic · “How we built our multi-agent research system”
유형: 공식 엔지니어링 글 · 분량: 긴 기술 보고 URL: anthropic.com/engineering/built-multi-agent-research-system
멀티 에이전트 아키텍처의 공식 레퍼런스. 구조는 orchestrator-worker: LeadResearcher가 쿼리를 분석하고 플랜을 메모리에 기록(컨텍스트 오버플로 방지)한 뒤 서브에이전트 3~5개를 병렬로 띄운다.
수치가 인상적이었다:
“Opus 4 lead + Sonnet 4 서브 조합이 단일 Opus 4 대비 약 90% 더 좋은 성능. 단, 토큰은 15배.”
그리고 Anthropic 본인들이 명시한 경고:
“This pattern works well for breadth-first parallel tasks but is less effective for tightly coupled coding tasks.”
얻은 것: 멀티 에이전트에 들뜨지 않는 감각. feature들이 서로 독립적일 때만 병렬이 의미 있다. 의존성 있는 코딩 작업엔 단일 에이전트 + 명확한 스펙이 낫다. Armin Ronacher가 1년 36편 쓰고 결국 서브에이전트를 버린 사례가 이 경고의 실증이다.
4. Andrej Karpathy · “Software 3.0” (YC Startup School 2025-06)
유형: 강연 · 분량: 약 40분 URL: YouTube 검색 “Andrej Karpathy YC Software 3.0”
“1.0은 코드, 2.0은 신경망 가중치, 3.0은 자연어 프롬프트.”
Karpathy는 AI를 “사람을 대체하는 것"이 아니라 자율성 슬라이더를 조절하는 도구로 봐야 한다고 한다. 아이언맨 슈트 비유. 전면 자동화가 아니라 부분 자동화가 현실이라는 주장이다.
그가 2026년 초 인터뷰에서 톤을 더 낮춘 점이 중요하다:
“업계가 너무 크게 건너뛰고 있다. 지금은 autocomplete이 sweet spot이다.”
원조가 이렇게 보수적으로 말하는데 유튜브엔 “AI가 모든 걸 만든다"는 영상뿐이다. 이 간극이 모든 마케팅 영상을 의심해야 하는 이유다.
얻은 것: 자율성 슬라이더 개념. Alpha Court에서 어떤 기능은 슬라이더를 높게(예: 기본 CRUD·UI 보일러플레이트), 어떤 기능은 낮게(예: 투자 검증 로직, 사용자 판단과 닿는 곳) 유지한다.
5. Geoffrey Huntley · “Ralph Wiggum” 루프
유형: 원저자 에세이 · 분량: 짧은 글 연작 URL: ghuntley.com
호주 엔지니어. 본질은 Bash 루프 하나다. PROMPT.md·AGENTS.md·fix_plan.md를 매 반복마다 똑같이 주입하고 하나의 태스크를 돌리는 결정론적 루프. 극단적이지만 HashiCorp Nomad 클론, Tailscale 재빌드, 새 언어까지 이 방식으로 만들었다고 한다. Anthropic이 공식 Ralph Wiggum 플러그인을 낼 정도로 업계가 받아들였다.
Huntley의 선언 한 줄:
“Software development/programming is now dead. We deeply need software engineers.”
코드 타이핑은 상품화되고, 이 루프들을 안전하게 설계하는 엔지니어링이 더 중요해진다는 뜻이다.
얻은 것: 결정론적 루프의 매력. 그러나 Huntley 본인의 경고 — 회사 규모 프로젝트에선 검증 하네스(테스트·린트·빌드 Stop hook)를 먼저 깔아야 이 루프가 안전하다. Kenton Varda의 CVE-2025-4143 사례가 이걸 안 하면 어떻게 되는지 보여준다.
접근 — 나의 독해 방법
이 독해 습관 자체는 투자에서 먼저 체득한 것이다. 매크로 분석을 하려면 요약 뉴스가 아니라 1차 문건(연준 성명, 정책 원문, 실적 보고서)을 직접 읽어야 했다. 당시 Grok3가 RAG를 잘 지원해서 뉴스와 핵심 정보를 내가 정제해 넣으면 시각화가 가능했다. 그 습관이 지금 AI-native 개발 자료 읽기로 그대로 옮겨왔다.
한 자료당 약 2시간 1독 + 1시간 정리. 비판 프레임 세 개를 돌린다.
- 저자의 제약: 어떤 조건에서 이 결정이 나왔나? (회사 규모? 시간? 기술 스택?)
- 저자가 안 쓴 것: 숨긴 실패, 덜 말한 한계는 무엇인가?
- 내 맥락 적용: Alpha Court(1인 프로젝트, 베타)에 그대로 가져올 수 있나, 수정이 필요한가?
메모는 Obsidian 로컬 볼트에 YYYY-MM-DD-저자명 형식으로 남긴다.
세부 — 다섯 자료가 서로를 보강한 방식
이들은 서로 독립 자료 같지만 읽어보면 같은 결론을 다른 각도에서 가리킨다.
- Willison → 골든 룰 (“설명 못 하는 코드 커밋 금지”)
- Reed → 그걸 가능하게 하는 워크플로우 (spec→plan→execute)
- Anthropic → 그걸 팀·병렬로 확장할 때의 한계 (의존성 코딩에 약함)
- Karpathy → 근본 철학 (자율성 슬라이더, 전면 자동화 환상 경계)
- Huntley → 극단 사례로 검증 하네스의 필요성 증명
유튜브 요약은 이 연결을 못 잡는다. 각자 한 문장씩만 옮기고 끝내니까.
영향 — Alpha Court에 녹인 흔적
- Harper Reed 3단계 → 새 기능은
spec.md부터 시작한다. 구현 전에 의사결정을 먼저 문서화. - Anthropic 경고 → Alpha Court는 단일 에이전트 + 명확한 스펙 구조를 유지. 멀티 에이전트는 병렬화 가능한 태스크(예: 데이터 수집)에만.
- Karpathy 자율성 슬라이더 → 사용자 판단과 닿는 UI는 AI 자율성을 낮게, 내부 CRUD는 높게.
- Huntley 검증 하네스 → CI에 테스트·린트·타입체크를 Stop hook으로 묶음. 통과 전엔 merge 불가.
결과 — 앞으로 읽을 것
다음 3개월 읽기 큐:
- Sean Grove(OpenAI), 스펙 영속 자산론 원문
- Armin Ronacher(Flask 창작자), “Things That Didn’t Work” + 2025년 에이전트 글 36편
- Boris Cherny(Anthropic Claude Code 헤드) 팟캐스트 2편 — Lenny’s 2026-02, Pragmatic Engineer 2026-03
- Anthropic Claude Code 공식 문서 전면 정독
개인 원칙 한 줄:
요약 인용 금지. 원본 직접 링크.
이 글 자체가 그 원칙의 첫 실천 기록이다.
유튜브를 끊고 블로그와 공식 문서를 열자. 한 달만 해보면 정보의 질이 완전히 달라진다.