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회 → 현재 주
  **200400회 배포**, 엔지니어 인원은 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 도입은 경쟁사 및 미도입 안과의 어려운 논의였고, 교차 기능 논쟁을 마무리하는
  임원의 승인이 필요

마무리

• 위 사례는 대표적 일부일 뿐 그 외에도 다수 수행, 가능한 일의 범위는 매월 계속 확장
• 발목을 잡는 요인은 크게 바뀌지 않음:
  조직적 비정렬, 명확성 부족, 부실한 기술 아키텍처

댓글과 토론