『Staff Engineer』의 저자이자 Stripe·Uber·Calm·Carta를 거친 전설적 엔지니어링 리더 Will Larson이, 하이퍼그로스 핀테크 Imprint에서 18개월간 AI를 도입한 뒤 자신의 리더십 규칙을 '개정'했다. 마이그레이션은 이제 개인 프로젝트가 됐고, 프로세스의 기본 케이스는 에이전트가 삼킨다 — 그런데도 왜 그는 '천재 1인 엔지니어' 신화를 정면으로 반박할까. 5대 개정 규칙을, 그 뒤를 떠받치는 에이전트 하니스 아키텍처(ReAct·Reflexion 논문)까지 쉽고 자세하게 풀어본다.
2026년 6월, 엔지니어링 리더들의 타임라인이 한 편의 글로 술렁였습니다. 제목은 담백했습니다 — 「엔지니어링 리더십의 개정된 규칙(Revised Rules of Engineering Leadership)」. 쓴 사람은 Will Larson(윌 라슨). 이 이름을 아는 사람이라면, 이 제목이 왜 사건인지 압니다.
라슨은 지난 10년간 엔지니어링 리더십의 '교과서'를 써온 사람이기 때문입니다. 그런 그가 "규칙을 개정한다"고 말한 겁니다. 그것도 조심스러운 수정이 아니라, 자기가 오래 지켜온 원칙 몇 개를 뿌리째 뒤집는 방식으로요.
이 글은 세 가지를 차례로 풀어봅니다. 첫째, 누가 Will Larson이고 왜 그의 '개정'이 화제인가. 둘째, 그가 내놓은 5대 개정 규칙이 무엇이고 왜 중요한가 — 사례를 풍부하게. 셋째, 그 규칙들을 실제로 떠받치는 에이전트 하니스라는 기계 장치의 아키텍처를, 용어 하나하나 뜯어가며.
Will Larson의 이력서는 지난 15년 실리콘밸리 하이퍼그로스의 목록과 거의 겹칩니다. Digg → Uber → Stripe → Calm → Carta의 CTO를 거쳤고, 지금은 핀테크 스타트업 Imprint에서 엔지니어링을 이끕니다.
그런데 그를 유명하게 만든 건 직함이 아니라 글입니다. 그는 자신의 블로그 lethain.com("Irrational Exuberance")에 십수 년간 엔지니어링 조직 운영의 노하우를 정리해 왔고, 그것을 세 권의 책으로 묶었습니다.
| 책 | 다루는 층위 | 한 줄 요약 |
|---|---|---|
| An Elegant Puzzle | 엔지니어링 매니지먼트 | 조직을 시스템으로 다루는 법 |
| Staff Engineer | 관리자 아닌 기술 리더 | "매니저 트랙 너머의 리더십" |
| The Engineering Executive's Primer | CTO·VP 임원 | 기술 임원의 첫 90일과 그 이후 |
그가 블로그에서 반복해 온 핵심 개념이 "레일(rails)"입니다. 조직의 성과 바닥(floor)을 끌어올리기 위해 강한 표준 레일을 깔아준다는 발상이죠. 라슨은 솔직하게 고백합니다 — "초기엔 이걸 명령(mandate)으로 만드는 실수를 했다. 시간이 지나며 규범(norm)으로 프레이밍하는 법을, 그리고 기대치보다 그 근거를 설명하는 데 쓰는 시간이 훨씬 중요하다는 걸 배웠다."
즉 그의 "규칙"은 즉흥적 트윗이 아니라, 10년에 걸쳐 다져진 레일입니다. 그래서 그가 그 레일을 "개정한다"고 하면, 그건 업계의 지반이 움직였다는 신호로 읽힙니다.
라슨이 지금 몸담은 Imprint는 브랜드 제휴 신용카드(co-branded credit card)를 만드는 뉴욕의 핀테크입니다. 2020년 설립, 2025년 12월 시리즈 D로 1.5억 달러를 유치하며 기업가치 12억 달러(유니콘)에 올라섰습니다. 전형적인 하이퍼그로스 환경이죠.
이 환경이 중요합니다. 라슨은 글 서두에서 이렇게 말합니다 — 하이퍼그로스에서는 "당신의 실수가 내년이 아니라 다음 달에 드러난다." 회사가 빠르게 크면 잘못된 판단의 대가가 즉시 청구되기 때문에, 교훈이 압축적으로, 그리고 빠르게 쌓입니다. 게다가 카드사이니 실시간 사기 대응 같은 고위험 자동화의 실험장이기도 합니다.
여기에 두 번째 힘이 겹쳤습니다. AI 도구의 폭발적 성숙입니다. 라슨은 약 18개월간 Imprint에서 LLM·에이전트 도입을 직접 이끌었고(회사 차원의 AI 도입기를 따로 정리했을 만큼), 그 경험이 오래된 레일을 다시 보게 만들었습니다.
정리하면 이렇습니다. 하이퍼그로스(빠른 피드백) × 에이전트 도구(값싼 실행)라는 두 힘이 만나면서, 라슨이 오래 믿어온 규칙 몇 개의 전제가 무너졌습니다. 그래서 "개정"입니다.
아래 위젯으로 5대 규칙의 "예전 통념 ↔ 개정된 규칙"을 먼저 한눈에 훑어보세요. 이어지는 2부에서 하나씩 자세히 풉니다.
규칙을 뜯어보기 전에, 왜 지금 이런 이야기가 나오는지의 역사적 맥락을 짧게 짚겠습니다. 이 흐름을 알면 다섯 규칙이 훨씬 선명해집니다.
이야기의 뿌리는 2019년, 강화학습의 아버지 리처드 서튼(Richard Sutton)의 짧은 글 「쓰라린 교훈(The Bitter Lesson)」입니다. 70년 AI 연구사를 한 문장으로 요약하면 — "연산(computation)을 활용하는 일반적인 방법이 결국 가장 효과적이며, 그것도 큰 격차로 그렇다." 사람이 규칙을 손으로 새겨 넣는 방식은 단기엔 빛나지만 장기엔 데이터·연산으로 스스로 배우는 시스템에 진다는 것이죠.
이 교훈은 트랜스포머(2017) → 스케일링 법칙(참고) → 대규모 언어모델로 이어졌고, 2024~2025년에는 마침내 코드를 쓰고 도구를 쓰는 에이전트로 진화했습니다. Claude Code, Cursor, Codex 같은 코딩 에이전트가 일상에 들어온 게 바로 이 시기입니다.
이 변화의 실무적 의미를 코어닷은 이미 여러 번 다뤘습니다. 개발자들이 "에이전트에게 프롬프트하지 말고, 에이전트를 프롬프트하는 시스템(하니스)을 설계하라"고 외친 루프 엔지니어링, 그리고 그 하니스를 실제로 짜는 오토하니스 이야기가 그것입니다. 라슨의 글은 이 흐름을 엔지니어링 리더의 눈높이에서 다시 정리한 문서라고 보면 됩니다.
라슨의 다섯 규칙은 결국 하나의 축을 중심으로 돕니다.
이제 규칙을 하나씩 봅니다.
예전 통념: 대형 마이그레이션(예: 결제 시스템 교체, 언어 전환)은 전담 팀이 여러 분기에 걸쳐 밀어붙이는 대공사다.
개정된 규칙: 복잡하고 큰 변경도 "그것을 이끄는 개인이나 팀이 95%를 소유하고, 10%의 시간에" 끝낼 수 있다.
라슨이 든 실제 사례들은 구체적이라 더 설득력 있습니다.
여기서 핵심 통찰이 하나 나옵니다. 마이그레이션 비용이 낮아질수록, 개별 판단의 품질이 조직 건강에 비례적으로 더 중요해진다. 실행이 싸지면 아무거나 시작할 수 있게 되고, 그러면 "무엇을 마이그레이션할지"라는 선택 자체가 병목이자 위험이 됩니다.
아래 시뮬레이터로 이 직관을 직접 만져보세요. AI 레버리지를 올릴수록 투입 인원과 기간은 급감하지만, 판단의 레버리지(잘못 고르면 그만큼 손해도 커지는 정도)는 반대로 치솟습니다.
참고로 "주간 배포 6 → 200회" 같은 지표는 그냥 자랑이 아닙니다. 배포 빈도(deployment frequency)는 소프트웨어 딜리버리 성과를 측정하는 DORA 4대 지표 중 하나로, 조직이 얼마나 안전하고 빠르게 변경을 내보내는지를 보여줍니다.
예전 통념: 코드를 쓰는 일 자체가 비싸다. 그러니 "누가 코드를 쓰느냐"를 통제한다.
개정된 규칙: 코드 생성은 이제 거의 공짜다. 하지만 "엣지 케이스가 없고 유지보수 가능한, 실제로 작동하는 코드"를 만드는 비용은 전적으로 개발 인프라(테스트, CI/CD, 검증 환경, 프리뷰 기능)에 달려 있다.
라슨이 던지는 프레임 전환이 날카롭습니다. 질문은 더 이상 "사람들이 코드를 써도 되는가?"가 아니라 "참여할 수 있는 안전한 경계(safe boundaries)가 있는가?"입니다.
그리고 유명해진 경고가 여기 있습니다.
"슬롭(slop) PR과 설계 문서는 값싸지만, 적극적으로 해롭다."
왜일까요? 대충 만든 저품질 산출물은 그저 무해한 노이즈가 아닙니다. 그것이 코드베이스와 문서에 컨텍스트로 남아, 다음번 LLM이 그걸 읽고 더 나쁜 출력을 뱉게 만들기 때문입니다. 오염된 맥락이 미래의 작업을 갉아먹는 것이죠. (LLM이 왜 맥락에 취약한지는 컨텍스트 엔지니어링에서 자세히 다뤘습니다.)
예전 통념: 프로세스의 각 단계는 사람이 하나하나 판단하며 밟아야 한다.
개정된 규칙: 올바른 하니스·통제·도메인 맥락·좋은 판단만 갖추면, 현대 기술 회사 대부분 프로세스의 기본 케이스(base-case)는 완전히 자동화할 수 있다.
핵심은 고위험 예외와 안전한 기본 케이스를 분리하는 것입니다. 대부분의 요청은 정형적인 base-case이고, 사람의 손이 꼭 필요한 건 소수의 예외입니다. 그 둘을 제대로 갈라내면, 위험을 늘리지 않으면서 조직을 가속할 수 있습니다.
라슨의 사례:
라슨은 여기서 도발적인 한마디를 덧붙입니다. "주간·격주 스프린트 같은 계획 프로세스는 너무 낮은 고도(too low an altitude)에서 작동하고 있다." 사람이 스프린트 단위로 잘게 관리하던 일의 상당 부분을, 이제는 하니스가 통째로 처리할 수 있다는 뜻입니다.
이 규칙의 실제 기계 장치 — "하니스"가 대체 어떻게 생겼는지 — 는 4부에서 아키텍처로 낱낱이 해부합니다.
이 자동화가 무섭게 폭주하지 않도록 사람이 어디에 개입해야 하는지는 Human-in-the-Loop 논의와 맞닿아 있습니다.
예전 통념(그리고 2026년의 유행): AI-first 회사는 소수의 천재 엔지니어(genius engineers)가 이끈다. 몇 명의 고수가 완벽한 시스템을 뚝딱 만들어낸다.
개정된 규칙: 실행이 아무리 싸져도, 오래 지속되는(durable) 팀이 쌓는 도메인 맥락과 오너십은 대체 불가능한 근본 building block으로 남는다.
이 대목이 이 글에서 가장 논쟁적입니다. 2026년 실리콘밸리에는 "AI를 든 1인 창업자가 팀 열 명 몫을 한다", "에이전트 오케스트레이션으로 초소형 팀이 유니콘을 만든다"는 서사가 넘쳐납니다. Sequoia가 초소형 팀의 산출을 가리켜 "agentic leverage(에이전트 레버리지)"라는 말로 투자 모델을 손볼 정도죠.
라슨은 이 유행을 정면으로 반박합니다. 고판단(high-judgment) 개인이 회사 곳곳을 누비며 놀라운 일을 할 수는 있지만, 그들은 결국 도메인 맥락의 부재에 가로막힌다(get hemmed in)는 것입니다. 실행이 공짜여도 "무엇이 옳은가"를 알아내는 일은 여전히 어렵고, 그 답은 오랫동안 한 영역을 지켜본 팀 안에 축적됩니다.
흥미롭게도 이건 라슨만의 주장이 아닙니다. 2026년, AI로 팀 몫을 해내던 솔로 창업자들조차 "고객 지원 티켓을 직접 넘겨보는 일이, 제품에서 벌어지는 일을 놓치지 않기 위해 실제로 필요했다"고 고백합니다. 맥락은 위임되지 않습니다.
이 주제는 코어닷의 개발자 직무의 재정의, 나보다 나은 사람을 뽑아라와도 이어집니다.
예전 통념: 리더십은 신중하게, 충분한 합의를 거쳐 결정한다.
개정된 규칙: 자동화가 아무리 값싸도, 조직이 변경을 커밋하고 기능을 런칭하기로 결정하지 못하면 아무 소용이 없다. 팀은 "빠르고(quick), 좋고(good), 그리고 durable한" 의사결정을 내려야 한다.
라슨의 관찰 중 가장 시사적인 부분입니다. 이 필요성이 임원 CTO를 더 기술적이고 덜 관료적으로 만들었다는 것. 실행 속도를 유지하기 위해, 이제 CTO들은 끊임없이 구속력 있는(binding) 결정을 내리고 있습니다.
논쟁적이었지만 통일된 리더십 결정 덕에 이득을 본 사례들:
규칙 3에서 "하니스가 프로세스의 기본 케이스를 삼킨다"고 했습니다. 그런데 하니스(harness)란 정확히 뭘까요? 생소한 단어일 텐데, 이 절에서 용어 하나하나를 뜯어 설명합니다. 놀랍게도 라슨은 Imprint의 AI 도입기에서 실제 구조를 꽤 구체적으로 공개했습니다.
하니스의 원래 뜻은 말에 씌우는 마구(馬具)입니다. 힘센 말(=LLM)에 굴레와 고삐를 채워 원하는 방향으로 일을 시키는 장치죠. AI에서 하니스는 LLM을 감싸서, 목표를 주고·도구를 쥐어주고·결과를 검증하고·루프를 돌리는 코드 골격을 뜻합니다. 프롬프트가 "한 번의 말 걸기"라면, 하니스는 "그 말 걸기를 자동으로 반복시키는 시스템"입니다. (추상화의 사다리: 프롬프트→컨텍스트→하니스→루프 참고.)
Imprint의 하니스는 의외로 소박하게 생겼습니다.
| 구성요소 | 실제 구현 | 역할 |
|---|---|---|
| 본체 | 약 3,000줄 Python stateless Lambda 하나 | 다양한 HTTP 요청을 한 함수가 다 받는다 |
| 모델 접근 | AWS Bedrock 위의 Claude(+Cursor/Claude Code), 사내 전반은 OpenAI | 실행 엔진 |
| 도구 | MCP 서버 — Slack/Notion/Jira 조회, 엔티티 검증 | LLM이 세상과 상호작용하는 손발 |
| 프롬프트 저장소 | 중앙 Notion DB(대부분 누구나 편집, 민감 건은 Git 관리) | 회사 지식을 프롬프트로 축적 |
| 관측·로깅 | Datadog + Slack #ai-logs 채널 | 무슨 일이 벌어졌는지 전부 보이게 |
| 검증 스텝 | 응답이 참조한 항목이 실재하는지 필수 확인 | 환각(hallucination) 방어 |
여기서 MCP(Model Context Protocol)는 LLM이 외부 도구·데이터에 접근하는 표준 규약입니다(MCP 이해하기). 예컨대 Slack 사용자를 찾을 때 display_name → name → real_name 순으로 매칭하는 조회 도구, JIRA의 특수 문서 포맷을 다루는 포매팅 도구 같은 것들이죠. 그리고 마지막 검증 스텝이 인상적입니다 — 응답이 언급한 티켓·문서·사람이 진짜 존재하는지 반드시 확인해서, 그럴듯하지만 없는 것을 지어내는 환각을 막습니다.
아래 해부도로 이 하니스가 이슈 트리아지·코드 리뷰·사기 조사 세 상황에서 각각 어떻게 도는지, 단계별로 눌러보세요. 핵심은 ④ 분기 — 대부분(기본 케이스)은 자동 처리되고, 사람은 예외만 본다는 점입니다.
해부도 ③에 나오는 ReAct 루프가 하니스의 심장입니다. 용어를 풀면 Reason(추론) + Act(행동)의 합성어로, 2023년 논문 「ReAct: Synergizing Reasoning and Acting in Language Models」(Yao 등)이 제안한 에이전트의 기본 골격입니다.
작동 원리는 사람이 문제 푸는 방식과 똑같습니다.
search_codebase("PaymentProcessor.ts")이 생각 → 행동 → 관찰의 고리를 목표가 달성될 때까지 반복합니다. 미리 완벽한 계획을 세우지 않고, 한 걸음 갈 때마다 관찰 결과를 보고 다음 수를 정하는 게 핵심이죠. (코어닷의 ReAct: 추론과 행동에서 더 깊이 다룹니다.) 아래 시뮬레이터로 실제 루프가 도는 모습을 직접 재생해볼 수 있습니다.
ReAct가 "한 번의 시도"라면, 그 위에 Reflexion(리플렉션)이 얹힙니다. 2023년 논문 「Reflexion」(Shinn 등)이 제안한 개념으로, 에이전트가 자신의 과거 시도를 되돌아보고(self-reflection), 그 반성을 다음 시도의 추가 맥락으로 넣어 스스로 개선하게 만듭니다.
라슨의 코드 리뷰 사례가 정확히 이 구조입니다 — 코드를 생성한 하니스가 컨텍스트를 비운 뒤 새 눈으로 자기 결과물을 다시 검토하죠. 환경의 피드백(테스트 실패, 리뷰 지적)이 일종의 의미론적 기울기 신호(semantic gradient)가 되어, 다음 출력을 더 나은 방향으로 밀어줍니다.
정리하면, 라슨의 다섯 규칙을 실제로 굴러가게 만드는 기계 장치는 이렇게 쌓여 있습니다 — MCP 도구(손발) + ReAct 루프(심장) + Reflexion(자기교정) + base-case/예외 분기(안전판) + 검증·로깅(신뢰). 이 스택이 있어야 "프로세스를 자동화한다"는 말이 위험한 도박이 아니라 통제된 엔지니어링이 됩니다.
이 글의 제목이 "개정된(revised) 규칙"인 이유는, 라슨 자신이 오래 지켜온 레일이 있었기 때문입니다. 예전 라슨의 조언은 대체로 이런 톤이었습니다 — "마이그레이션은 팀으로 신중히", "프로세스로 예측 가능성을 확보하라", "합의를 쌓아라". 안정적 성장 환경에서 실행 비용이 비쌌기 때문에 옳았던 규칙들이죠.
개정판의 무게중심은 정반대로 이동했습니다. 실행이 싸졌으니 개인에게 위임하고, 기본 케이스는 자동화하고, 결정은 더 빠르게 내리라고요. 그런데 — 이게 이 글의 반전인데 — 라슨은 동시에 "근본은 그대로다"라고 못 박습니다. durable 팀, 좋은 아키텍처, 명확한 방향. 그래서 이 글은 "AI가 다 바꾼다"는 흥분과 "아무것도 안 변했다"는 냉소 사이의 균형점을 제시한 문서로 읽혔습니다.
가장 뜨거운 지점은 역시 규칙 4였습니다. 2026년의 지배적 서사 — "AI-first 회사는 소수 천재가 이끈다" — 를 업계에서 가장 신뢰받는 리더 중 한 명이 정면으로 반박했기 때문입니다.
| 관점 | 주장 | 한계 |
|---|---|---|
| 천재 1인 서사 | AI 레버리지로 초소형 팀이 유니콘을 만든다 | 도메인 맥락·오너십이 위임되지 않는다 |
| 라슨의 반박 | durable 팀이 여전히 근본 building block | 느려 보일 수 있으나 "옳은 것"을 안다 |
| 현실의 절충 | "AI로 이기는 사람은 AI 없이도 이겼을 사람 — 더 빠르고 린해졌을 뿐" | 실행은 싸졌어도 판단·맥락은 여전히 비싸다 |
라슨의 결론은 시원합니다. 가능성의 조리개(aperture)는 매달 넓어지고 있지만, 여전히 발목을 잡는 제약은 늘 똑같다는 것 — 조직의 misalignment(정렬 실패), 명확성의 부재, 그리고 나쁜 기술 아키텍처. 도구가 아무리 좋아져도, 이 셋을 못 풀면 속도는 나오지 않습니다.
"기술 업계에서 일하기에 지금은 정말 거친(wild) 시대다." — Will Larson
라슨의 개정판이 우리에게 남기는 메시지는 명료합니다. AI는 "무엇을 할 수 있는가"의 지도를 다시 그렸지만, "무엇을 해야 하는가"의 나침반은 여전히 사람과 조직 안에 있다는 것입니다.
코어닷의 시선에서 보면, 이 다섯 규칙은 결국 하나의 실천으로 수렴합니다 — 하니스를 잘 짜고(값싼 실행), 방향을 잘 정하는(비싼 판단) 조직을 만드는 것. 도구는 매달 좋아지겠지만, 이기는 팀과 지는 팀을 가르는 건 여전히 정렬·명확성·아키텍처라는 오래된 근본입니다.
"실수가 다음 달에 드러나는" 빠른 시대일수록, 좋은 판단을 빠르게 내리는 조직이 이깁니다. 그 판단을 돕는 것이 바로 코어닷이 만드는 AI의 역할입니다.
