개정된 엔지니어링 리더십 규칙
(lethain.com)- AI 도구 전환과 빠른 성장(hypergrowth) 환경에서 지난 1년간 검증해 재정립한 엔지니어링 리더십 5대 규칙과 이를 뒷받침하는 실제 프로젝트 사례 정리
- 마이그레이션은 이제 팀이 아닌 개인이 95% 주도해 기존의 10% 시간에 완료 가능, 초기 비용이 낮아질수록 개인 판단의 영향력이 커짐
- 1차 코드는 거의 무료지만 잘 동작하는 코드의 비용은 테스트·CI/CD 등 개발 하네스에 좌우되어 무료가 아님
- 대부분 프로세스의 기본 케이스는 에이전트로 완전 자동화 가능하며, 코드 리뷰 첫 패스도 좋은 하네스가 사람보다 빠르고 효과적
- AI의 이점을 실제로 누리려면 도메인 컨텍스트를 가진 지속적 팀과 빠르고 견고한 의사결정이 전제 조건
배경
- 2014년 초~2020년 말 hypergrowth 환경에서 근무, hypergrowth의 가장 큰 가치는 실수가 내년이 아닌 다음 달에 드러난다는 점 (빠르게 움직이면 문제가 크게 터짐)
- 최근 hypergrowth를 다시 떠올린 이유는 Imprint의 빠른 사업 성장, 작년 대규모 채용, 그리고 AI 도구 전환으로 작업 가능 속도가 달라졌기 때문
- 이 글은 재정립한 리더십 규칙과 그 믿음을 갖게 한 지난 1년간의 구체적 프로젝트를 함께 정리
개정된 규칙
1. 마이그레이션은 팀이 아닌 개인이 수행 가능
- 복잡하고 큰 변경도 주도하는 개인 또는 팀이 95% 소유하며 기존 대비 10% 시간에 완료
- 초기 비용이 낮아질수록 각 마이그레이션 품질의 보상/벌점이 커짐
- 작은 결함도 함께 유지보수하는 동료의 소프트웨어 멘탈 모델을 무너뜨림
- 회사에 미치는 개인 판단의 영향력이 그 어느 때보다 큼
2. 1차 코드는 거의 무료지만, 동작하는 코드의 비용은 개발 하네스에 좌우
- 모두가 코드를 작성해야 한다는 시대지만, 지저분한 엣지케이스를 피하며 잘 동작하는 코드 작성은 여전히 어려움
- 그 난이도는 테스트, CI/CD, 검증 환경, 변경 미리보기 등 개발 하네스에 따라 결정
- "모두가 코딩"하는 회사라도 마케팅 팀이 서버 할당을 줄이는 것이 아니라, 그들이 안전하게 참여할 수 있는 경계의 존재 여부가 핵심 (소프트웨어 작성으로 커스터마이징을 허용하는 SaaS 제품과 유사)
- 2년 전 엔지니어링 속도를 높이는 데 가장 가치 있던 것들이 오늘날에도 여전히 가장 가치 있음
3. 프로세스의 기본 케이스를 에이전트에 맞게 최적화
- 적절한 하네스·통제·도메인 컨텍스트와 설계자의 좋은 판단이 있으면 대부분 프로세스의 기본 케이스를 완전 자동화 가능
- 사람의 코드 리뷰 기본 케이스는 좋은 하네스의 코드 리뷰보다 느리고 덜 효과적
- 하네스도 놓치지만 사람도 놓치며, 대부분 영역은 변경이 비교적 안전
- 다만 일부 고위험 영역은 예외이며, 이 구분을 제대로 포착하면 위험 없이 더 빨라지고 실패하면 무수한 문제 발생
- 따름정리로, 주간·격주 스프린트 같은 계획 프로세스는 너무 낮은 고도에서 작동 중이며, 사람의 공동 계획은 더 높은 수준에서 이뤄져야 함
4. 도메인 컨텍스트를 가진 지속적·고소유(high ownership) 팀이 더욱 중요
- Uber에서의 교훈: 지속적이고 견고한 팀이 도메인 컨텍스트 축적, 동료애 형성, 강한 소유 의식으로 마법 같은 성과를 냄
- 실행 비용이 싸진 시대에도 올바른 일을 해야 하며, 이는 약간 쉬워졌을 뿐 크게 쉬워지지 않음
- 예: 프로덕션 최적화에 필요한 데이터가 아예 수집되지 않아 하네스의 해법은 합리적이나 틀렸고, 유일한 해결책은 누락된 정보의 계측이었음
- AI 우선 기업이 소수의 천재 엔지니어로 운영된다는 통념에 반대, 고판단 개인도 도메인 컨텍스트 부족으로 한계에 부딪히므로 지속적 팀이 근본 단위
5. 빠르고 좋고 견고한 의사결정이 AI 수혜의 전제 조건
- 법무 검토를 자동화로 대체하려면 Legal이 그 변경을 약속할 수 있어야 하며, 이는 신중한 설계와 팀의 협업 의지에 달림
- 실행 속도 향상의 혜택은 빠르고 견고하며 좋은 의사결정을 내릴 수 있을 때만 가능
- 이것이 평균적 CTO 역할이 1년 전보다 훨씬 더 기술적이고 덜 관료적으로 변한 주된 이유
- 팀 간 이견 시 구속력 있는 결정을 내릴 수 있는 유일한 사람인 경우가 많아, 속도 유지를 위해 끊임없이 결정 중
- 임원이 더 나은 결정자라는 주장이 아니라, 임원들이 서로 정렬되어 결정을 존중하는 한 구속력 있는 임원 결정이 독보적으로 강력
실제 적용 사례
마이그레이션
- 1년 전 수동 배포로 주 ~6회 → 현재 주 200~400회 배포, 엔지니어 인원은 2배지만 YoY 20~30배 증가, 배포·마이그레이션 운영 방식 전면 개편을 인프라팀 2명이 두 달간 90% 수행
- 1월 1일 ~25%가 매일 Claude Code 또는 Cursor 사용 → 2월 말 100%, 하향식 지시 없이 도구 품질 개선과 비채택자와의 대화로 마찰 제거, 현재 거의 모든 PR의 1차 작성은 하네스가 담당
- 다양한 설정 방식을 두 가지 설정 메커니즘(거의 바뀌지 않는 클라이언트/서버 상수용, 제품별·자주 바뀌는 값용)으로 통합, 개별 엔지니어들의 독립 프로젝트로 진행
- 한 명이 아키텍처 정리 → 다른 한 명이 참조 아키텍처 구현 → 여러 명이 다른 영역에 적용, 과거엔 수년짜리 프로젝트였으나 한 분기 미만에 완료, 엔지니어·비엔지니어 팀의 값 관리용 내부 도구 포함
- 멀티 레포 프런트엔드를 약 한 달 만에 모노레포 아키텍처로 통합, 95%를 프런트엔드 엔지니어 1명이 주도, 공유 프런트엔드 하네스 확보 및 마찰 원인이던 npm 패키지 호스팅 완전 탈피
- 대부분 타입이 없던 프런트엔드 코드를 완전 정적 타입화, 한 엔지니어가 다량의 토큰으로 몇 주에 걸쳐 수행
- 더 나은 보안 기본값과 빠른 배포를 위해 npm에서 pnpm으로 전환, 한 엔지니어가 며칠간 하루 몇 시간씩 작업
동작하는 코드의 비용은 개발 하네스에 좌우
- 설계 문서나 PR을 다른 팀 엔지니어에게 "벽 너머로 던지는" 방식은 성과 없음, 부실한(slop) PR·설계 문서는 싸지만 오히려 해로움
- 정리·수정이 필요하고 그 컨텍스트가 LLM을 오염시켜 처음부터 시작하는 것보다 못한 결과 초래
- 매니저가 변경을 직접 검증하고 배포 후 대시보드를 확인하며 발생 문제를 해결하는 한 매니저의 코드 기여는 큰 성공, 그렇지 않은 경우 긍정적 효과 없음
프로세스 기본 케이스의 에이전트 최적화
- 고객 운영팀의 모든 인입 이슈를 팀·열린 티켓을 알고 데이터 웨어하우스에 제한적으로 접근해 영향도를 산정하는 하네스로 트리아지, 복잡·고숙련이나 흥미롭지 않은 노동을 더 빠르게 처리
- 엣지케이스는 여전히 사람이 트리아지하며, 인간 워크플로우 변경 없이 동일 흐름에서 일부 단계만 자동화
- 코드 리뷰 1차 패스는 변경을 구현한 동일 하네스가 작성 컨텍스트를 비운 상태로 수행, 사람은 더 높은 가치의 피드백에 집중
- 지난 분기 Claude Code와 Cowork를 전사 배포, fraud팀이 특히 적극적으로 수작업을 1차 자동화로 대체해 잠재적 공격의 초기 조사를 자동 수행 (데이터 자체에 기인한 어트리뷰션 포함)
- Jira에서 Linear로 이전, 더 강력한 MCP와 나은 Slack 통합으로 에이전트 우선 워크플로우 인프라 강화, Linear에서 이슈를 가져와 자동 해결하는 내부 하네스 알파 테스트 거의 완료
도메인 컨텍스트를 가진 지속적·고소유 팀
- 합류 당시 재능 있는 인력이 프로젝트별로 빠르게 영역을 순환해 매우 반응적이었으나, 현재 모든 중요한 영역에 전담 소규모 팀을 배치해 지속 투자, 이 팀들이 직접 새로운 AI 기법 활용
- SierraAI 출시 후 팀이 끊임없이 개선해 진정 탁월한 수준으로 발전, 전담·집중 팀 없이는 불가능했을 성과
빠르고 좋고 견고한 의사결정
- 설정 방식 변경은 논쟁적이어서 접근법을 반복 설명, 팀마다 영향이 다르고 혜택은 생태계 수준(한 사람이 전 팀의 설정을 구성)에서만 발생해 상향식으로는 어려움
- CI/CD 파이프라인 재작업도 배포·릴리스 멘탈 모델을 바꿔 논쟁적, 피처 플래깅으로 배포와 릴리스를 명시적으로 분리하도록 강제
- 웹 모노레포 통합 역시 의견이 갈린 논쟁적 결정으로 통합된 결정의 이점이 큼
- SierraAI 도입은 경쟁사 및 미도입 안과의 어려운 논의였고, 교차 기능 논쟁을 마무리하는 임원의 승인이 필요
마무리
- 위 사례는 대표적 일부일 뿐 그 외에도 다수 수행, 가능한 일의 범위는 매월 계속 확장
- 발목을 잡는 요인은 크게 바뀌지 않음: 조직적 비정렬, 명확성 부족, 부실한 기술 아키텍처