3줄 요약

  1. Will Larson(Imprint CTO, 이전 Uber/Stripe/Calm 리더십 경험자)이 하이퍼그로스와 AI 툴링 전환기를 1년 겪은 뒤 자기 엔지니어링 리더십 원칙 5개를 다시 짰다.
  2. 다섯 축은 이렇다 — 개인의 판단력이 회사에 미치는 영향이 그 어느 때보다 크고, 1차 코드는 사실상 공짜지만 실제로 굴러가는 코드의 비용은 개발 하네스에 달렸고, 대부분의 프로세스는 에이전트 기준으로 새로 짜야 하고, 도메인 컨텍스트를 쌓는 지속적 팀은 오히려 더 중요해졌으며, AI의 속도를 실제로 누리려면 빠르고 결정적인 의사결정이 선결 조건이다.
  3. 실증 근거는 Imprint의 지난 1년 — 주간 배포 6회에서 200~400회, Claude Code 채택률 두 달 만에 25%에서 100%, 마이그레이션 대부분은 한두 명이 몇 주에서 몇 달 만에 완수했다.

개정된 5원칙

1. 마이그레이션은 팀이 아니라 개인이 할 수 있다

복잡하고 규모가 큰 변경조차 주도하는 개인이나 팀이 95%를 소유한 채 10%의 시간에 끝낼 수 있다. 마이그레이션의 초기 비용이 내려간 만큼, 각 마이그레이션의 품질이 주는 보상과 처벌이 커진다 — 작은 예리한 모서리도 함께 코드를 유지하는 동료의 멘탈 모델을 부숴 놓는다. 개인의 판단력이 회사에 미치는 영향력이 이보다 컸던 적이 없다.

2. 1차 코드는 거의 공짜지만, 굴러가는 코드의 비용은 하네스에 달려 있다

지금은 “모두가 코드를 써야 한다"고 말하는 회사가 많은 시대다. 하지만 실제로 잘 굴러가면서 지저분한 엣지 케이스를 피하는 코드를 쓰는 일은 여전히 어렵고, 그 난이도는 개발 하네스 — 테스트, CI/CD, 검증 환경, 변경사항의 프리뷰 가능성 등 — 에 좌우된다.

Larson 자신은 회사의 대부분 구성원이 코드를 기여하는 게 유용하다고 보지 않지만, 이 주제의 대부분의 이견은 사실 오해라고 진단한다. “모두가 코드를 쓴다"는 회사에서도 마케팅팀이 서버 리소스 할당을 줄이는 게 아니다. 요는 그들이 안전한 경계 안에서 참여할 수 있는지의 문제다 (SaaS 제품이 사용자에게 커스터마이징 코드 작성을 허용하는 것과 비슷하다).

좋은 소식은 이것이다 — 2년 전에 엔지니어링을 빠르게 만들어 주던 것들이 지금도 여전히 엔지니어링을 가장 빠르게 만들어 주는 것들이다.

3. 대부분 프로세스의 기본 케이스는 에이전트 기준으로 새로 짜라

적절한 하네스, 적절한 통제, 도메인 컨텍스트, 그리고 설계자의 좋은 판단만 있으면 현대 테크 기업의 대부분 프로세스의 기본 케이스는 완전 자동화가 가능하다. 예를 들어 사람이 하는 코드 리뷰의 기본 케이스는 잘 만든 하네스의 코드 리뷰보다 느리고 덜 효과적이다. 물론 하네스가 놓치는 것이 있지만 사람 리뷰어도 놓친다. 대부분 영역은 변경이 상대적으로 안전하다.

물론 위험 영역이 있고 그런 곳에서는 이 원칙이 성립하지 않는다. 이 구분을 제대로 잡아내면 위험을 늘리지 않고도 훨씬 빨리 갈 수 있다. 잡아내지 못하면 헤아릴 수 없이 많은 문제를 자초하게 된다.

따름 결론으로 — 대부분의 주간/격주 스프린트 같은 기획 프로세스는 지금 너무 낮은 고도에서 돌아가고 있다. 사람이 함께 계획을 세우는 일은 여전히 중요하지만 더 높은 수준에서 이루어져야 한다.

4. 지속적이고 소유권이 높으며 도메인 컨텍스트를 가진 팀은 오히려 더 중요하다

Larson이 Uber에서 얻은 가장 큰 교훈 중 하나는 지속적이고 오래 가는 팀이 마법을 부린다는 것이었다 — 도메인 컨텍스트를 쌓고, 동료애를 만들며, 자기 영역에 대한 소유권 감각을 점점 강하게 느낀다. 무언가를 구체적으로 해내는 비용이 훨씬 저렴해진 지금도 여전히 옳은 것을 해야 하며, 그 판단은 조금 쉬워졌을 뿐 크게 쉬워지지 않았다. 구조적 개선이 이 문제를 다룬다.

최근 사례 하나 — Imprint에서 프로덕션 이슈를 최적화하려고 하는데 정작 필요한 데이터가 아예 수집되지 않고 있었다. 그래서 하네스가 내놓은 해법은 합리적이지만 틀렸다. 유일한 진짜 경로는 누락된 정보의 인스트루먼테이션이었다.

Larson이 이 지점에서 명시적으로 반대하는 유행하는 통념이 있다 — “AI 우선 회사는 소수의 천재 엔지니어가 완벽한 것을 하나씩 만들어 유지보수할 것이 없어질 것이다"라는 그림. Larson은 이 그림에 동의하지 않는다. 판단력 높은 개인이 회사 전역을 돌며 놀라운 일들을 할 수는 있지만, 어느 순간 도메인 컨텍스트의 부재로 막힌다. 그래서 지속적 팀이 이 시대에도 여전히 근본 빌딩 블록이라 결론 낸다.

5. 빠르고, 좋고, 지속되는 의사결정은 AI 혜택의 선결 조건

법률 리뷰를 자동화로 대체하는 일은 Legal이 그 변경에 커밋할 수 있어야만 성립하며, 그것은 자동화의 사려 깊은 설계와 팀들의 협업 의지에 달렸다. 새 기능 구현도 그 기능을 출시하기로 결정할 수 있어야만 가치가 있다.

늘어난 실행 속도의 혜택은 결정을 빠르게, 결정을 좋게, 결정을 지속되게 내릴 수 있어야만 팀과 회사에 돌아온다. Larson은 이것이 지난 1년 사이 평균적인 CTO 역할이 훨씬 더 기술적이고 덜 관료적으로 변한 주요 이유라고 본다. 팀들이 앞으로 갈 길에서 이견을 낼 때 결정을 내릴 수 있는 유일한 사람이 자기인 경우가 많고, 그래서 이 새로운 세계에서 속도를 유지하려면 계속 결정을 내려야 한다.

(다만 이것이 임원이 더 좋은 의사결정자라는 뜻은 아니라고 부연한다. 임원의 구속력 있는 결정은 임원들 자신이 그 결정을 존중할 만큼 정렬되어 있는 한에서만 독보적으로 강력하다.)

Imprint에서 실제로 있었던 일

Larson은 자기가 이 원칙들을 믿는 이유를 지난 1년 프로젝트로 되짚는다.

마이그레이션

  • 1년 전에는 수동 배포에 주당 약 6회 배포였다. 지금은 주당 200~400회. 엔지니어링 인원이 두 배가 됐지만, 이전 배포량의 두 배를 계산해도 전년 대비 20~30배 증가다. 인프라팀 두 명이 두 달에 걸쳐 배포·마이그레이션 방식을 전면 정비한 결과다 (90%를 두 명이 함께 몰았다).
  • 1월 1일 시점에 팀의 약 25%가 매일 Claude Code나 Cursor를 썼다. 2월 말에는 100%가 매일 썼다. 하향식 지시 없이 툴링을 좋게 만들고 미채택자와 대화하며 마찰 원인을 걷어내는 방식으로만 왔다. 이제 거의 모든 PR의 1차는 하네스가 작성한다.
  • 다양한 설정 메커니즘을 두 가지로 통합했다 — 하나는 거의 바뀌지 않는 클라이언트/서버 상수용, 다른 하나는 자주 바뀌는 제품 특화 값용. 개별 엔지니어의 격리 프로젝트로 이어달렸다. 예전 세계라면 여러 사람이 몇 년을 걸릴 일이 한 분기 이하로 끝났고, 여기에는 엔지니어와 비엔지니어 팀 모두를 위한 내부 관리 도구까지 포함된다.
  • 다중 리포 프런트엔드를 모노 리포로 통합했다. 약 한 달, 프런트엔드 엔지니어 한 명이 95%를 몰았다. 이제 공유 프런트엔드 개발 하네스가 있고, 라이브러리 유지 비용이 싸졌으며, 마찰 원인이었던 npm 패키지 호스팅에서 완전히 벗어났다.
  • 프런트엔드 코드를 완전히 정적 타입화했다. 이전에는 대부분 타입이 없었다. 엔지니어 한 명과 많은 토큰으로 몇 주 만에 끝냈다.
  • npm에서 pnpm으로 옮겼다 — 더 나은 보안 기본값과 더 빠른 배포. 엔지니어 한 명이 며칠 동안 하루 몇 시간씩.

하네스가 만드는 격차

  • 다른 팀 엔지니어에게 설계 문서와 PR을 “벽 너머로 던지려” 한 시도는 전부 어디로도 가지 못했다. 슬롭(slop) PR과 설계 문서는 저렴하지만 능동적으로 해롭다. 정리·수리 비용에 더해, 그 컨텍스트가 LLM을 오염시켜 처음부터 다시 시작하는 것보다 나쁜 결과를 낸다.
  • 반대로 매니저가 소프트웨어에 기여할 때는 엄청난 성공을 봤다 — 단, 그 매니저가 직접 작업을 검증하고 변경 후 대시보드를 확인하고 자기 변경이 일으킨 이슈를 해결하는 조건 하에. 이 세 가지를 하지 않고 시도하는 사람들에게서는 긍정적 효과를 하나도 보지 못했다.

에이전트 기준의 프로세스 재설계

  • 고객 운영팀이 들어오는 이슈를 팀 정보·오픈 티켓·데이터 웨어하우스 제한 접근을 아는 하네스로 트리아지한다. 복잡하고 고숙련이지만 특별히 재미있지는 않은 노동을, 에이전트로 더 잘, 더 빨리 한다. 엣지 케이스는 여전히 사람이 본다. 중요한 점은 사람 워크플로우를 바꾸지 않았다는 것 — 같은 워크플로우에 일부 단계만 자동화됐다.
  • 코드 리뷰의 1차는 변경을 구현한 것과 같은 하네스가 컨텍스트를 비운 뒤 수행한다. 사람은 더 높은 가치의 피드백에 집중한다.
  • 지난 분기 Claude Code와 Cowork을 사내 전원에게 배포했고, 이들도 자기 업무의 점점 큰 영역을 자동화하는 것을 봤다. 사기 방지팀은 특히 적극적으로, 잠재 공격의 초기 조사를 데이터 자체에 귀속시키는 방식으로 자동화의 1차를 굴리고 있다.
  • Jira에서 Linear로 옮겼다 — 더 강력한 MCP와 더 나은 Slack 통합으로 이런 워크플로우를 뒷받침하기 위해서다. 지금은 Linear의 이슈를 끌어와 자동으로 해결하는 사내 하네스의 알파 테스트가 거의 끝나가는 상태 — 이 방향의 가장 큰 다음 단계다.

지속적 팀

  • Larson이 합류했을 때 몇몇 영역은 재능 있는 사람들이 프로젝트 단위로 빠르게 순환하며 지원하는 형태였다. 굴러가긴 했지만 이슈에 반응하는 자세가 지배적이었다. 지금은 회사의 모든 중요 영역에 최소한의 작은 팀이라도 전담시킬 수 있게 됐고, 이들이 지속적으로 투자한다. 이 팀들이 AI가 열어 준 새 기법들을 직접 휘두른다. 그들 없이는 아무도 이 기회를 잡지 못했을 것 — 벌어지는 일이 너무 많다.
  • SierraAI를 출시했다. 꽤 좋은 상태로 나왔지만 그 이후 담당 팀이 끈질기게 반복 개선해 진짜로 훌륭해졌다. 전담 집중 팀 없이는 못 했을 일.

빠르고 결정적인 의사결정

  • 설정 방식을 바꾸는 것은 논쟁적 결정이었다. Larson이 접근에 대해 반복적으로 해명해야 했다. 각 팀에 미치는 영향이 다르고, 이익은 생태계 수준(한 사람이 팀 전역의 설정을 다룰 수 있음)에서만 체감되기 때문에 상향식으로는 매우 어려웠을 결정.
  • CI/CD 파이프라인 개조도 논쟁적이었다 — 배포와 릴리스의 멘탈 모델을 바꾸는 일이었다 (기능 플래그로 배포와 릴리스를 명시적으로 분리하도록 강제했다). 상향식으로는 느리고 어려웠을 결정.
  • 웹 모노 리포 통합도 다양한 의견이 갈렸던 논쟁적 결정. 단일 결정의 이점이 컸다.
  • SierraAI로의 이전은 여러 경쟁 제품과 “안 하기” 사이에서 어려운 논의였고, 크로스펑셔널 논쟁을 마무리하는 데 임원의 도장이 필요했다.

나를 붙들어 세운 지점

Larson이 마지막 문단에서 지나가듯 던진 문장 하나가 오래 남는다.

이런 것은 대표적 사례일 뿐이다. 우리가 한 일은 훨씬 더 많다. 올해 매달 가능한 것의 조리개는 계속 확장돼 왔지만, 우리를 붙들고 있는 것들은 크게 달라지지 않았다 — 조직적 오정렬, 명확성의 부재, 그리고 나쁜 기술 아키텍처.

새 도구가 실행 비용을 압축하는 만큼 조직의 마찰 비용이 상대적으로 부각된다. Larson이 “CTO 역할이 훨씬 더 기술적이고 덜 관료적으로 변했다"고 진단한 이유가 여기에 있다 — 이제 병목은 사람과 사람 사이의 미결정, 대화 없이 벽 너머로 던져지는 문서, 그리고 뒤엉킨 코드베이스 그 자체다. AI가 개발자를 대체하는지 하지 않는지의 담론과 별개로, AI가 조직의 낡은 병목을 잔인할 정도로 노출시킨다는 진단이 이 글에 담겨 있다.

한 가지 더 — 개별의 판단력이 회사에 미치는 영향이 그 어느 때보다 커졌다는 첫 원칙과 지속적 팀이 오히려 더 중요해졌다는 네 번째 원칙은 겉으로 모순처럼 보인다. Larson은 이를 이렇게 봉합한다. 판단력 높은 개인은 회사 전역을 돌며 놀라운 일을 할 수 있지만, 어느 순간 도메인 컨텍스트 부재로 막힌다. 그래서 개인의 판단은 지속적 팀 위에서만 오래 간다. 이 짝지음이 이 글의 실용적 뼈대다.

출처

원문에는 인용할 만한 이미지나 도식이 없어 텍스트 다이제스트로 정리했다.