생각은 외주해도, 이해는 외주할 수 없다 — Karpathy의 Sequoia 30분, 그리고 에이전트 시대의 사람 관리
Andrej Karpathy가 Sequoia에서 한 30분 토크를 보고 정리한 메모. 에이전트끼리 먼저 미팅하는 세상, 사람이 아닌 에이전트를 위한 docs, 토큰을 단위로 일하는 시대 — 그리고 새로 합류할 경력직·주니어를 그 안에서 어떻게 관리하고 성장시킬 것인가.
본업 쪽에 새로운 사람들이 합류할 예정이다. 경력직도 있고 주니어도 있다. 머리로는 환영인데, 매일 코드 한 줄 한 줄을 에이전트와 짜고 있는 입장에서 — 6개월 전 머리로 그리던 팀 빌딩과 지금 그리는 팀 빌딩은 종류가 다르다. 사람을 들이는 건지, 사람과 그 사람이 데리고 올 에이전트 묶음을 함께 들이는 건지 모호하다.
그 와중에 Andrej Karpathy의 Sequoia 토크를 봤다. 30분짜리. 회의 가는 길에 켰는데, 도착해서 차에서 5분 더 보고 들어갔다.
한 문장이 박혔다
“You can outsource your thinking, but you can’t outsource your understanding.”
생각은 외주할 수 있다. 그런데 이해는 외주가 안 된다.
이 문장이 왜 이렇게 박혔냐면 — 내가 매일 하는 일이 정확히 그 경계에 서 있기 때문이다. 코드는 Claude Code가 짠다. 설계 초안도 던져준다. 회의록 요약도 한다. 나는 검토하고, 머지하고, 다음 작업을 던진다. 효율은 미쳤다.
근데 이해는 누가 하는가. 이 코드가 왜 이렇게 짜여있는지, 이 의사결정이 왜 이쪽으로 갔는지, 다음에 비슷한 상황이 오면 같은 판단을 다시 할 수 있는지 — 그건 외주가 안 된다. 외주 줬다고 착각하는 순간, 다음 분기에 내가 아무것도 못 하는 사람이 된다.
2월에 쓴 “생각의 외주화” 글이 Sarkar의 TED였다면, 이번 Karpathy 토크는 같은 진실의 엔지니어 버전이다. Sarkar는 “지적 관광객”이 된다고 했고, Karpathy는 더 단순하게 잘랐다. thinking ≠ understanding. 결국 같은 얘기인데, 엔지니어가 말하니 더 무겁다.
Karpathy가 30분 동안 한 얘기
토크를 한 줄로 줄이면 이렇다.
소프트웨어가 또 한 번 바뀌고 있다. 이번엔 우리가 “프로그래밍 언어”를 영어로 갈아탔다.
1.0은 사람이 짠 코드. 2.0은 데이터로 학습된 신경망 가중치. 그리고 지금 3.0은 — 자연어 프롬프트가 곧 프로그램이 되는 시대. 이 변화가 어떤 의미냐면, 누구나 프로그래머가 될 수 있는 동시에, 진짜 이해하는 사람만 신뢰할 만한 시스템을 만들 수 있다는 뜻이다.
토크에서 인상 깊었던 비유 몇 개를 적어둔다.
- LLM은 1960년대의 메인프레임 같다. 비싸고, 시간 단위로 빌려쓰고, 누구나 직접 만지지는 못한다. 클라이언트(우리)가 시간을 쪼개 접속한다.
- “Iron Man suit” 비유. 완전 자율 에이전트가 아니라, 사람이 입는 강화복으로서의 AI. 자율도(slider)를 사람이 조절한다. 이게 현실적이다.
- 그리고 가장 중요한 한 줄 — “vibe coding”이 가능해진 시대지만, vibe만으로는 프로덕션이 안 된다.
Sequoia 토크 끝부분, 영상 25분 즈음 Karpathy가 살짝 던진 그 한 문장이 thinking vs understanding이었다. 영상에선 짧게 지나갔는데, 그게 30분 전체를 관통하는 주제였다.
미래엔 에이전트끼리 먼저 미팅한다
토크를 보면서 머릿속에 그려진 장면이 하나 있다. 가까운 미래에 회의실 풍경.
내 에이전트와 상대편 에이전트가 먼저 만난다. 일정 조율부터 가격 협상까지 1차 라운드는 둘이 끝낸다. 사람은 결정해야 할 두세 가지 분기점만 남겨놓고 나타난다. 인사하고, 사인하고, 술 한 잔 한다. 그게 다다.
이건 SF가 아니다. 이미 우리는 그 초기 버전을 산다. 캘린더 어시스턴트가 양쪽 일정을 잡고, 메일 비서가 1차 답장을 쓰고, 코드 리뷰는 에이전트가 1차 패스를 돌린다. 다음 단계는 명확하다 — 에이전트가 에이전트와 직접 통신하기 위한 프로토콜이 필요해진다. Anthropic의 MCP, OpenAI의 Realtime API, Google의 A2A — 이 흐름이 그쪽으로 가고 있다.
“Stripe 결제 이메일 ≠ 서비스 이메일” — Karpathy의 한 장면
토크 중에 길게 잡고 본 대목이 하나 있다. Karpathy가 “agent가 진짜로 reliable해지려면” 같은 얘기를 하면서 든 예시였다. Stripe 결제 계정의 이메일과 우리 서비스 계정의 이메일이 다를 수 있다. 같은 사람인데 메일주소가 다르다. 환불 처리, VIP 식별, 정산 — 이 매핑이 잘못되면 다 어긋난다. 좋은 엔지니어는 그 엣지케이스를 본능적으로 잡아낸다. 6개월 뒤, 1년 뒤엔 에이전트도 잡아낼 거다. 점점 잘 잡아낼 거다.
그런데 잡아낸 다음이 문제다. 에이전트가 “이거 매핑 안 맞는 케이스 있는데요?”라고 알려준 그 다음, 어떻게 매핑할지를 정하는 일은 누구의 몫인가.
- 옵션 A: 두 이메일을 fuzzy하게 매핑한다 (도메인+로컬파트 정규화).
- 옵션 B: 사용자한테 둘 다 등록하게 시키고 OR로 묶는다.
- 옵션 C: 새 internal UUID를 발급하고 양쪽을 모두 외래키로 단다.
- 옵션 D: Stripe의 customer.metadata에 우리 user_id를 박는다.
이건 단순히 어떤 게 정답이냐의 문제가 아니다. UX·보안·마이그레이션 비용·향후 확장성이 다 다르게 걸린다. 에이전트는 네 옵션을 다 알고 있고, 각각의 트레이드오프도 잘 정리해서 던질 거다. 그런데 우리 사용자가 어떤 사람들이고, 우리 도메인에서 어떤 실수가 비싸고, 1년 뒤 어떤 방향으로 확장할 예정인가 — 이걸 알고 결정하는 건 결국 매니저 에이전트거나, 그 매니저 에이전트를 관리하는 사람이다. 이해의 책임은 위로 위임된다. 절대 사라지지 않는다.
이게 thinking 외주화의 회사 버전이다. 에이전트가 잘할수록, 결정 권한은 더 위로 올라간다. 그리고 위로 올라간 자리에서 이해 없이 결정만 누르는 사람이 있다면, 그게 가장 위험한 자리다.
사람이 아닌 에이전트를 위한 docs
며칠 전에 PG사 연동을 다시 들여다봤다. 토스페이먼츠 docs를 열었는데, 사이드바에 못 보던 게 있었다. llms.txt 와 비슷한 카테고리. 사람용 docs가 아니라, 에이전트가 한 번에 긁어가서 컨텍스트로 쓰기 좋게 정제된 마크다운이 따로 있다.
처음 본 순간 솔직히 멈칫했다. 우리는 늘 사람을 위한 문서를 어떻게 잘 쓸지 고민해왔다. 친절한 톤, 예제 코드, 잘 정리된 목차, 검색 잘 되는 SEO. 그런데 이제 문서의 1차 독자가 사람이 아닌 시대가 오고 있다. Cursor가, Claude Code가, 회사 내부 에이전트가 그 docs를 먼저 읽고, 사람한테는 요약만 전달한다.
이 흐름의 표준이 llms.txt다. 사이트 루트에 LLM이 우선 참조해야 할 인덱스를 두는 제안. Anthropic, Mintlify, Vercel, 그리고 토스페이먼츠가 한국에선 거의 첫 사례로 들어왔다. fintech가 이런 흐름에서 빠를 거라곤 6개월 전엔 생각 못 했다.
이게 무슨 의미냐면:
- 문서 작성의 1차 청중이 바뀐다. 사람한테 친절한 톤이 에이전트한테 친절한 톤과 같지 않다.
- 검색의 1차 사용자도 바뀐다. Google SEO가 LLM SEO로 옮겨가는 중이다. LLM이 어떻게 우리 페이지를 인덱싱하느냐가 결국 사람한테 도달하느냐를 결정한다.
- 개발자 경험(DX)이 “에이전트 경험(AX)”으로 확장된다. SDK가 사람한테 직관적이냐 못지않게, 에이전트가 도구로 잘 호출하느냐가 중요해진다.
내가 매일 쓰는 CLAUDE.md도 같은 종류다. 사람 협업자한테 보내는 온보딩 문서가 아니라, 에이전트한테 보내는 system prompt다. 이 파일을 잘 쓴 사람과 못 쓴 사람의 생산성 차이가, 6개월 뒤엔 코딩 실력 차이보다 클 수도 있다.
토큰을 단위로 일하는 시대
Jensen Huang이 NVIDIA 행사에서 한 말이 계속 머리에 남는다. 대략 이런 톤이었다.
“연봉 10만 달러 엔지니어가 AI 에이전트를 안 쓰고 있다면 그건 회사의 손실이다. 적어도 일주일에 수만 토큰은 써야 한다.”
처음 들었을 땐 좀 거칠다고 생각했다. 토큰 = 노동량인가? 토큰을 적게 쓰는 사람이 일을 적게 한 거냐 — 그건 너무 단순한 KPI다.
그런데 새 사람들이 합류한다는 일을 머리에 두고 보니, 이 말이 다르게 들렸다. 회사가 진짜로 측정해야 하는 건 토큰이 아니다. 토큰은 단지 시그널이다. 핵심은 — 이 사람이 자기 일의 어느 부분을 에이전트에게 위임하고, 어느 부분을 자기가 잡고 있는가.
옛날엔 평가가 단순했다. 책상에 오래 앉아있는 사람이 일을 많이 했다. 코드 라인 수, 커밋 수, 야근 시간. 이런 게 “엉덩이 무거운 좋은 사원”의 신호였다. 지금은 다 깨졌다. 코드 라인 수는 에이전트가 부풀린다. 커밋 수도 fake가 가능하다. 야근 시간은 의미가 없다 — 에이전트가 8시간 일하는 동안 사람은 자도 된다.
그렇다고 토큰 많이 쓴 사람이 일 잘하는 사람이냐 — 이것도 단순하다. 토큰을 잘못 쓰면, thinking까지 외주해버린 사람이 토큰을 가장 많이 쓴다. understanding은 0인데 token은 1억인 사람.
내가 지금 그려보는 평가축은 이런 거다.
| 축 | 옛날 시그널 | 지금 시그널 |
|---|---|---|
| 산출량 | 코드 라인, 문서 페이지 | 머지된 PR, 완성된 의사결정 |
| 사고력 | 야근, 토론 시간 | 에이전트한테 던지는 질문의 깊이 |
| 협업 | 회의 참석률 | system prompt / docs 정비 수준 |
| 학습 | 책, 사이드 프로젝트 | “이해의 잔존량” — AI 끄고도 설명 가능한가 |
마지막 줄이 핵심이다. AI 끄고도 설명 가능한가. 이게 understanding이 남아있는지 확인하는 가장 단순한 테스트다. 토큰 사용량은 그 다음 얘기다.
경력직 합류 — 일하는 방식이 다른 사람을 어떻게 들이는가
새 사람들이 들어오는 일로 다시 돌아오면 — 사실 가장 오래 머리에 두고 있는 부분이 이거다.
우리 팀은 에이전트 네이티브에 가깝다. CLAUDE.md, MCP, 자동화 파이프라인이 일상이다. 들어올 경력직들은 그렇지 않을 가능성이 크다. 자기 손으로 코드를 짜는 손맛이 있는 시니어들이다. 능력이 부족해서가 아니다. 오히려 반대다. 다만 도구의 세대가 다르고, 일하는 문화가 다르고, 어디까지 자동화에 맡기는지의 기준이 다르다.
이걸 어떻게 합칠 것인가. 머리에 옵션을 늘어놓고 한참 봤다.
옵션 1: 강제 전환. 모든 협업을 에이전트 친화적인 형식으로 통일한다. Slack DM 금지, 결정은 무조건 의사결정 로그, 코드는 무조건 PR. 빠르지만 인재가 떠난다. 손맛 있는 시니어가 환영받지 못한다고 느끼는 순간, 합류 자체의 의미가 없어진다.
옵션 2: 방치. 각자 스타일대로 일하게 두고, 결과만 합친다. 갈등은 없지만 시너지가 0이다. 같은 팀이 됐는데 같은 언어를 안 쓴다.
옵션 3: 가교 만들기. 만나는 경계면에만 표준을 강제한다. API 문서, PR 템플릿, 회의록 포맷, 의사결정 로그 — 이 네 가지만. 내부 스타일은 각자 유지한다.
내 결론은 3번이다. 그리고 이 결정을 내릴 때 가장 도움이 됐던 게 — 아이러니하게도 Sarkar의 TED와 Karpathy의 Sequoia를 같은 주에 다시 본 일이었다. 한쪽은 인지과학의 경고, 한쪽은 엔지니어의 비전. 둘이 같은 곳을 가리키고 있었다.
도구를 강요할 수는 없다. 하지만 도구를 쓰는 사람의 이해는 공통 단위로 잡아야 한다. 우리가 표준화해야 할 건 “Claude Code를 무조건 써라”가 아니라, “당신이 어떻게 의사결정에 도달했는지 한 문단으로 적어라”다. 손으로 짜든 에이전트로 짜든 — 그 결정을 이해하고 있는지를 코드 리뷰에서 확인할 수 있어야 한다.
이게 새 사람과 옛 사람을 같은 언어로 묶는 다리다. 도구가 아니라 understanding을 공통 화폐로 잡는 것.
에이전트 시대의 원온원은 어떻게 바뀌어야 하는가
원온원(1:1)이 가장 먼저 바뀔 의식(ritual)이라고 생각한다.
옛날 원온원의 기본 메뉴는 셋이었다. (1) 진행 상황 업데이트, (2) 블로커, (3) 커리어 대화. 이게 70% 정도였다. 그런데 (1)은 이제 PR 목록·에이전트 로그·토큰 사용량에 다 적혀 있다. (2)도 상당 부분은 에이전트가 풀려고 시도한 흔적이 로그에 남는다. 사람 둘이 30분 잡고 (1)과 (2)를 짚는 건 — 솔직히 비싼 회의다.
그래서 원온원을 다시 설계한다면, 메뉴를 이렇게 바꿔보고 싶다.
1. “이번 주 에이전트가 한 일 중에 당신이 다시 검증한 건 뭐였나요?” 보고가 아니라 이해의 잔존량을 확인하는 질문이다. 머지된 PR을 본 게 아니라, 왜 머지했는지를 본인 입으로 설명할 수 있는지를 본다.
2. “이번 주 에이전트의 제안을 거절한 결정이 있나요? 왜였나요?” 이게 핵심 질문이다. 에이전트의 제안을 그대로 받기만 하는 사람은 thinking까지 외주한 사람이다. 거절·수정 사례가 한 주에 하나도 없다면 — 그건 둘 중 하나다. 일이 매우 단순했거나, 본인이 판단을 안 하고 있거나. 보통 후자다.
3. “에이전트가 더 잘했으면 좋겠는 부분은 뭔가요?” 이건 도구를 주체적으로 쓰고 있는지를 본다. 에이전트가 잘하는 일을 만족하며 쓰는 사람은 많다. 에이전트가 못 하는 일을 불편해하는 사람은 적다. 그 불편함이 다음 분기 자동화 백로그가 된다.
4. 커리어 대화. 이건 그대로 둔다. 다만 형식이 바뀐다 (아래 주니어 섹션에서 이어진다).
블로커 확인은 비동기 채널로 옮긴다. 원온원 시간엔 데이터로 안 보이는 것만 다룬다. 30분이 길게 느껴지지 않는 형태다.
주니어에게 어떤 성장을 권할 것인가
이게 가장 오래 답을 못 찾고 있는 질문이다. 솔직히 지금도 확신은 없다. 다만 며칠 머리에 두고 정리한 가설을 적는다.
1. “코드 잘 짜는 사람”이 되라고 하지 않는다
옛날에는 주니어한테 “기초를 단단하게 다져라, 알고리즘 풀어라, 작은 PR을 많이 쳐서 손에 익혀라”라고 했다. 일부는 여전히 유효하다 — 자료구조, 디버깅, 시스템 설계 같은 근육은 끝까지 필요하다. 그런데 코드를 빠르게 정확하게 타이핑하는 능력은 더는 차별화가 안 된다. 그건 commodity다.
대신 권하고 싶은 건 셋이다.
① 도메인 깊이. 에이전트는 breadth가 거의 무한이다. 그래서 사람이 만들 수 있는 차별화는 depth다. 특정 도메인 — 결제, 의료, 보안, 인프라, 광고, 추천 — 어디든 좋다. 틀린 답이 비싼 도메인을 고르라고 하고 싶다. 거기서 1년만 진지하게 파면 에이전트가 못 따라잡는 판단력이 생긴다.
② 취향(taste). 에이전트는 100가지 안을 던진다. 그중에 어느 안이 좋은 안인지를 고르는 건 사람이다. 코드의 우아함, 제품의 결, UX의 호흡 — 이런 고르는 눈은 빠르게 노출되고 비평받으면서 길러진다. 라이브러리 코드 100개 읽기, 잘 만든 제품 매주 분해해 보기, 본인의 결정을 왜 그게 좋은지 한 문단으로 적기. 이게 새로운 의미의 “기초”다.
③ 에이전트를 오케스트레이션하는 능력. 1명이 1명 분량의 일을 하던 시절은 끝났다. 1명이 5명의 에이전트를 동시에 굴리는 게 표준이 된다. 그러려면 내가 지금 어떤 에이전트가 어디서 뭘 하고 있는지를 머리에 들고 있는 능력이 필요하다. 이건 IC 스킬이 아니라 플레잉 매니저 스킬이다. 주니어한테도 이걸 가르쳐야 한다.
2. 꿈은 “10x 엔지니어”가 아니라 “한 사람 회사”로
옛날 주니어한테 영감을 주던 비전은 “10x 엔지니어”였다. 지금 그게 더는 멋있지 않다. 10x는 에이전트가 한다. 그게 그냥 baseline이 된다.
새로운 비전은 — 한 사람이 회사 하나 분량을 책임지는 모델이라고 생각한다. 제품 결정, 디자인, 코드, 마케팅, 데이터 분석을 한 사람이 에이전트 군단과 함께 끝까지 끌고 가는 모델. 솔로 founder가 ARR $10M을 만드는 시대가 오고 있고, 이미 일부는 와 있다. 주니어한테 이걸 일찍 그려주고 싶다. 큰 회사 한 자리가 아니라, 작은 회사 전체를 머리에 그릴 수 있는 사람이 되라고.
3. 평가는 AI 꺼도 설명 가능한가로
주니어 평가축도 바뀌어야 한다. PR 수, 토큰 사용량, 머지된 라인 수 — 이건 다 noise다. 하나만 본다면 AI 꺼도 같은 결과를 설명할 수 있는가다.
원온원에서 직접 물어본다. “지난주 머지한 그 PR, 다시 짜야 한다면 뭐부터 시작할 거예요?” 에이전트 없이도 답이 나오는 사람과, 답이 흐릿한 사람의 차이가 1년 뒤엔 경력 자체의 차이가 된다. 이건 평가가 아니라 주니어 본인을 살리는 질문이라고 생각한다.
4. 조언 한 줄로 줄이면
“에이전트에게 타이핑을 외주해라. 사고는 절대 외주하지 마라.”
이게 지금 내가 주니어한테 줄 수 있는 가장 정직한 한 줄이다. 너무 단순해서 거의 cliché 같지만, 매일 코드를 짜다 보면 — 이 한 줄을 지키는 게 생각보다 어렵다. 어른들이 매번 이걸 까먹는다.
그래서, 토큰 모니터링은 할 거냐
질문을 다시 적어본다. 각자의 에이전트 토큰 사용량을 모니터링해야 하나?
내 답은 — 본인 단위로는 한다. 평가 단위로는 안 한다.
본인 단위는 의미가 있다. 이번 달에 내가 토큰을 어디에 얼마 썼는지를 보면, 내가 어디서 생각을 외주했는지가 보인다. 코드 리뷰에 100만 토큰 썼다면 그건 좋다. 의사결정 회의 요약에 100만 토큰 썼다면 — 그건 이해까지 외주했을 가능성이 있다는 신호다. 토큰은 그런 식의 자기점검 단위다.
반대로 평가 단위로 쓰는 건 위험하다. “이 사람은 이번 분기에 토큰 1억을 썼으니 일을 잘 했다”는 결론이 나오기 시작하면, 다들 토큰을 부풀리기 시작한다. 결국 thinking은 외주했고 understanding도 사라진 직원들이 가장 좋은 평가를 받는다. 회사 전체의 understanding 잔존량이 0으로 수렴한다.
그래서 토큰은 내가 나를 보는 거울로만 쓸 거다. 남을 평가하는 자로 쓰지 않는다.
마무리 — 같은 한 문장에서 끝낸다
Karpathy의 30분에서 가장 오래 남은 한 문장으로 다시 돌아간다.
“You can outsource your thinking, but you can’t outsource your understanding.”
새 사람들이 들어오는 일을 머릿속에 두고 이 문장을 다시 읽으면, 결국 이 모든 얘기가 같은 자리로 모인다.
- 에이전트끼리 미팅하는 미래에서도, 어떻게 매핑할지를 정하는 결정은 결국 사람한테 위임된다. Stripe 이메일 매핑이 그 좋은 예다.
- 에이전트를 위한 docs를 쓰는 시대에도, 그 docs를 왜 그렇게 썼는지는 사람이 알고 있어야 한다.
- 토큰을 단위로 일하는 세상에서도, 그 토큰이 만든 결과를 설명할 수 있는 사람만 신뢰할 만하다.
- 경력직과 새 사람을 한 팀으로 묶는 다리는 도구가 아니라 understanding이다.
- 원온원은 보고에서 이해의 잔존량 점검으로 옮겨가야 한다.
- 주니어한테는 “코드 잘 짜라”가 아니라 “도메인 깊이·취향·에이전트 오케스트레이션”을 권한다.
효율은 외주할 수 있다. 그게 에이전트의 핵심 가치다. 그런데 회사 전체의 이해까지 외주하기 시작하면, 우리는 누구의 회사를 운영하고 있는 건지 모르게 된다.
이번 분기 안에 한 가지만 정하기로 했다. 모든 의사결정 로그를 공통 포맷으로 묶는 것. 어떤 도구로 만들었든 — 왜 그 결정을 했는지를 사람이 한 문단으로 적는다. 다른 건 다 양보할 수 있다. 이거 하나는 안 양보한다.
30분짜리 토크 하나가 한 분기 운영 메모만큼 결정을 정리해줬다. 가끔 이런 일이 있다.