개정된 엔지니어링 리더십 규칙 — AI 시대의 5대 원칙과 실전 적용

> Will Larson(Lethain)이 1년간 AI 도구 전환과 hypergrowth 환경에서 검증해 재정립한 엔지니어링 리더십 5대 규칙을 정리합니다. 원문은 lethain.com/revised-rules-of-engineering-leadership에 공개돼 있으며, GeekNews#30994를 통해 2026년 7월 1일자로 공유됐습니다(Points 19, Comments 0).

도입: 왜 다시 "엔지니어링 리더십 규칙"인가

Will Larson은 2014~2020년 hypergrowth 환경에서 근무하며 "실수가 내년이 아닌 다음 달에 드러난다"는 교훈을 얻었다고 회고합니다. 6년이 지난 지금, Imprint의 빠른 사업 성장 + 대규모 채용 + AI 도구 전환이 다시 hypergrowth 환경을 만들었고, 그는 지난 1년간의 프로젝트로 다섯 가지 규칙을 재정립했습니다. 핵심 메시지는 단순합니다. AI가 코드 작성 비용을 낮추면, 그에 따라 사람이 책임져야 할 영역의 무게가 더 커진다는 점입니다.

5대 규칙 요약 비교표

| # | 규칙 | 핵심 변화 | 측정 임팩트 |

|---|---|---|---|

| 1 | 마이그레이션은 개인이 95% 소유 | 팀 프로젝트 → 개인 주도 | 기존 10% 시간에 완료 |

| 2 | 1차 코드 무료, 동작 코드는 하네스 종속 | 작성 난이도 → 환경 난이도 | 테스트·CI/CD 비용 결정 |

| 3 | 프로세스 기본 케이스 = 에이전트 자동화 | 사람 리뷰 1차 → 하네스 리뷰 1차 | 사람 리뷰는 더 높은 가치 피드백 집중 |

| 4 | 지속적·고소유 팀이 더욱 중요 | 영역 순환 → 전담 소규모 팀 | 도메인 컨텍스트 축적 |

| 5 | 빠르고 견고한 의사결정 = AI 수혜 전제 | 관료적 CTO → 기술적 CTO | 실행 속도 이점의 게이트 |

규칙 1: 마이그레이션은 팀이 아닌 개인이 수행 가능

복잡하고 큰 변경도 한 명이 95% 소유해 기존 대비 10% 시간에 완료할 수 있게 됐습니다. 초기 비용이 낮아질수록 각 마이그레이션 품질의 보상/벌점이 커집니다. 작은 결함도 동료의 소프트웨어 멘탈 모델을 무너뜨리기 때문입니다.

# 예시: 마이그레이션 소유 비율을 정의하는 간단한 데이터 구조
class Migration:
    def __init__(self, owner: str, scope: str):
        self.owner = owner        # 1명이 95% 소유
        self.scope = scope
        self.individual_judgment_impact = "high"  # 개인 판단 영향력 ↑

• 실전 사례*:
• 주 6회 → 주 200~400회 배포 (YoY 20~30배, 엔지니어 2배)
• 설정 방식을 두 가지 메커니즘으로 통합 → 수년짜리 프로젝트가 한 분기 미만으로 단축
• 멀티 레포 프런트엔드를 모노레포로 통합 → 프런트엔드 엔지니어 1명이 약 한 달 주도
• npm → pnpm 전환을 한 엔지니어가 며칠간 하루 몇 시간씩 작업

규칙 2: 1차 코드는 거의 무료, 동작하는 코드의 비용은 하네스에 좌우

모두가 코드를 작성하는 시대지만, 잘 동작하는 코드를 작성하는 난이도는 여전히 높습니다. 이 난이도는 테스트·CI/CD·검증 환경·변경 미리보기 같은 개발 하네스에 따라 결정됩니다.

# 예시: 잘 동작하는 코드를 만드는 하네스 구성 요소
dev_harness:
  testing: "자동화 테스트 (단위/통합/E2E)"
  ci_cd: "GitHub Actions + 자동 배포"
  preview_env: "PR별 임시 환경"
  verification: "타입 체크 + 린트 + 보안 스캔"

핵심 인사이트는 "모두가 코딩"하는 회사라도 마케팅 팀이 서버 할당을 줄이는 게 아니라, 그들이 안전하게 참여할 수 있는 경계의 존재가 핵심이라는 점입니다. 2년 전 엔지니어링 속도를 높이는 데 가장 가치 있던 것들이 오늘날에도 여전히 가장 가치 있다는 사실이 인상적입니다.

규칙 3: 프로세스의 기본 케이스는 에이전트로 자동화

적절한 하네스·통제·도메인 컨텍스트 + 설계자의 좋은 판단이 있으면 대부분의 프로세스 기본 케이스는 완전 자동화 가능합니다. 사람의 코드 리뷰 기본 케이스는 좋은 하네스의 코드 리뷰보다 느리고 덜 효과적입니다.

| 영역 | Before (사람 1차) | After (하네스 1차) |

|---|---|---|

| 코드 리뷰 1차 패스 | 사람이 컨텍스트 없이 검토 | 동일 하네스가 작성 컨텍스트 비운 채 검토 |

| 고객 이슈 트리아지 | 인입 → 사람이 영향도 산정 | 인입 → 하네스가 영향도 산정, 엣지케이스만 사람 |

| 주간 스프린트 | 사람이 계획 수립 | 너무 낮은 고도 → 사람의 공동 계획은 더 높은 수준으로 |

• 실전 사례*:
• 고객 운영팀의 모든 인입 이슈를 하네스로 트리아지 (엣지케이스는 사람)
• 코드 리뷰 1차 패스는 하네스가 작성 컨텍스트를 비운 상태로 수행 → 사람은 더 높은 가치의 피드백에 집중
• Claude Code와 Cowork를 전사 배포, fraud팀이 잠재적 공격의 초기 조사를 자동 수행
• Jira → Linear 이전으로 에이전트 우선 워크플로우 인프라 강화, Linear 이슈를 자동 해결하는 내부 하네스 알파 테스트 중

규칙 4: 도메인 컨텍스트를 가진 지속적·고소유 팀이 더욱 중요

Uber에서의 교훈은 명확합니다. 지속적이고 견고한 팀이 도메인 컨텍스트를 축적하고 동료애와 강한 소유 의식으로 마법 같은 성과를 냅니다. 실행 비용이 싸진 시대에도 올바른 일을 해야 하며, 이는 약간 쉬워졌을 뿐 크게 쉬워지지 않았습니다.

> "AI 우선 기업이 소수의 천재 엔지니어로 운영된다는 통념에 반대한다. 고판단 개인도 도메인 컨텍스트 부족으로 한계에 부딪히므로 지속적 팀이 근본 단위다."

• 실전 사례*:
• SierraAI 출시 후 팀이 끊임없이 개선해 진정 탁월한 수준으로 발전 → 전담·집중 팀 없이는 불가능했을 성과
• 프로덕션 최적화에 필요한 데이터가 아예 수집되지 않아 하네스의 해법은 합리적이나 틀렸고, 유일한 해결책은 누락된 정보의 계측

규칙 5: 빠르고 좋고 견고한 의사결정이 AI 수혜의 전제 조건

법무 검토를 자동화로 대체하려면 Legal이 그 변경을 약속할 수 있어야 하며, 이는 신중한 설계와 팀의 협업 의지에 달립니다. 실행 속도 향상의 혜택은 빠르고 견고하며 좋은 의사결정을 내릴 수 있을 때만 가능합니다.

이것이 평균적 CTO 역할이 1년 전보다 훨씬 더 기술적이고 덜 관료적으로 변한 주된 이유입니다:

• 팀 간 이견 시 구속력 있는 결정을 내릴 수 있는 유일한 사람인 경우가 많아, 속도 유지를 위해 끊임없이 결정 중
• 임원이 더 나은 결정자라는 주장이 아니라, 임원들이 서로 정렬되어 결정을 존중하는 한 구속력 있는 임원 결정이 독보적으로 강력

• 실전 사례*:
• 설정 방식 변경은 팀마다 영향이 달라 상향식으로는 어려움 → 임원의 통합된 결정
• CI/CD 파이프라인 재작업 → 피처 플래깅으로 배포와 릴리스를 명시적으로 분리하도록 강제
• 웹 모노레포 통합 → 의견이 갈린 논쟁적 결정이지만 통합된 이점이 큼

마무리: 발목을 잡는 요인은 같다

Will Larson은 위 사례가 대표적 일부일 뿐 그 외에도 다수가 수행됐다고 강조합니다. 그리고 발목을 잡는 요인은 크게 바뀌지 않았다고 결론짓습니다:

• 조직적 비정렬 — 팀 간 목표·우선순위 충돌
• 명확성 부족 — 무엇이 옳은 일인지 합의 부재
• 부실한 기술 아키텍처 — 하네스 부재

AI 도구가 아무리 발전해도 이 세 가지는 사람의 책임입니다. 1년 전과 비교해 마이그레이션 비용은 10분의 1이 됐지만, 그만큼 한 개인의 판단 무게는 더 커졌습니다. 엔지니어링 리더십의 본질은 여전히 "올바른 일을 올바르게 결정하는 것"이며, AI는 그 결정의 속도를 높여줄 뿐 대체하지 않습니다.

• --

• 참고 링크*:
• 원문: lethain.com/revised-rules-of-engineering-leadership
• GeekNews: news.hada.io/topic?id=30994