엔지니어링 리더십, 새로운 규칙들

게시일: 2026년 6월 24일 | 원문 작성일: 2026년 6월 15일 | 저자: Will Larson | 원문 보기

• • •

2014년 초부터 2020년 말까지 저는 하이퍼그로스T1 환경에서 일했어요. 힘들기도 했지만, 그만큼 배움도 많았어요. 하이퍼그로스의 가장 큰 장점은 실수가 다음 해가 아니라 다음 달에 드러난다는 점이에요. 빠르게 움직이면 무언가 잘못됐을 때 아주 시끄럽게 티가 나거든요.

요즘 들어 하이퍼그로스를 다시 많이 생각하게 돼요. ImprintT2의 비즈니스가 빠르게 성장하고 있고, 작년에 채용을 많이 했기도 하지만, AI 도구의 변화로 인해 일할 수 있는 속도 자체가 달라졌기 때문이에요.

이 글에서는 지난 1년간 제가 수정한 엔지니어링 리더십 원칙들을 정리하고, 그 믿음을 갖게 된 구체적인 프로젝트들을 소개할게요.

새로운 규칙들

1. 마이그레이션은 팀이 아니라 개인이 해낼 수 있어요.
   복잡하고 대규모의 변경도 주도하는 개인이나 팀이 95%를 책임지고, 기존 대비 10%의 시간에 완료할 수 있어요. 마이그레이션의 초기 비용이 낮아질수록, 각 마이그레이션의 품질이 가져오는 보상과 패널티는 더 커져요. 작은 날카로운 모서리 하나가, 동료들과 함께 유지보수하는 소프트웨어에 대한 멘탈 모델을 무너뜨릴 수 있어요. 개인의 판단이 회사에 미치는 영향은 역사상 그 어느 때보다 높아졌어요.

2. 1차 코드 작성 비용은 거의 0에 가깝지만, 동작하는 코드의 비용은 개발 하네스에 달려 있고 결코 공짜가 아니에요.
   지금은 많은 회사들이 “everyone이 코드를 써야 한다”고 말하는 시대예요. 저희 경험으로는, 코드가 제대로 동작하면서 지저분한 엣지 케이스까지 피하게 만드는 건 여전히 어려워요. 그 난이도는 개발 하네스, 즉 테스트, CI/CD, 검증 환경, 변경 사항의 미리보기 가능성 등에 따라 크게 달라요.

   개인적으로 회사의 모든 사람이 코드를 기여하는 게 가치 있다고 생각하지는 않아요. 하지만 이 주제에 대한 대부분의 견해 차이는 사실 소통의 오해에서 비롯된 것 같아요. “모두가 코드를 쓴다”는 회사에서도 마케팅 팀이 서버 리소스 할당을 줄이는 건 아니에요. 핵심은 그들이 참여할 수 있는 안전한 경계가 있느냐의 문제예요. (커스터마이즈를 소프트웨어 작성으로 허용하는 SaaS 제품과 비슷한 방식이죠.)

   좋은 소식은, 2년 전에 엔지니어링 속도를 높이는 데 가장 가치 있었던 것들이 지금도 여전히 가장 가치 있다는 점이에요.

3. 프로세스의 기본 케이스를 에이전트 기준으로 최적화하세요.
   적절한 하네스, 올바른 통제 장치, 도메인 맥락, 그리고 설계자의 좋은 판단력이 갖춰진다면, 현대 기술 회사의 대부분의 프로세스에서 기본 케이스를 완전히 자동화할 수 있어요. 예를 들어, 코드 리뷰의 기본 케이스라면 사람 리뷰어보다 잘 만든 하네스가 더 빠르고 효과적이에요. 물론 하네스도 놓치는 게 있지만, 사람 리뷰어도 마찬가지예요. 그리고 대부분의 영역은 변경을 가하기에 비교적 안전해요. 더 위험해서 이것이 통하지 않는 영역도 있긴 해요.

   이 차이를 제대로 포착하면 위험 없이 훨씬 빠르게 나아갈 수 있어요. 포착하지 못하면, 문제를 스스로 끝없이 만들어내게 되는 거죠.

   이와 연결되는 얘기인데, 주간이나 격주 스프린트 같은 기획 프로세스 대부분이 너무 낮은 고도에서 운영되고 있다고 생각해요. 사람들이 함께 기획하는 것은 여전히 중요하지만, 더 높은 차원에서 이루어져야 해요.

4. 도메인 맥락을 갖추고, 강한 오너십으로 지속하는 팀이 더욱 중요해졌어요.
   Uber에서 얻은 가장 큰 교훈 중 하나는 지속적이고 안정적인 팀이 마법을 부린다는 것이에요. 도메인 맥락을 축적하고, 동료애를 쌓고, 한 영역에서 계속 일하면서 점점 더 강한 오너십을 느끼게 되거든요. 특정 작업을 수행하는 비용이 훨씬 저렴해진 시대에도, 올바른 것을 해야 한다는 사실은 변하지 않아요. 그 판단이 조금은 쉬워졌지만 많이는 아니에요. 구조적인 개선이 이를 보완해주긴 해요.

   (최근 사례로, 프로덕션에서 발생한 문제를 해결하는 데 필요한 데이터 자체가 애초에 수집되지 않고 있었어요. 하네스가 제안한 해결책은 합리적이었지만 틀렸어요. 유일한 진짜 해결책은 빠진 정보를 직접 계측 데이터로 추가하는 것이었거든요.)

   한 가지 다른 시각도 있어요. AI 퍼스트 회사에서는 소수의 천재 엔지니어들이 완벽한 버전을 하나씩 만들어내고, 유지보수가 거의 필요 없을 만큼 잘 해낼 것이라는 견해예요. 매력적인 비전이지만, 저는 그런 일이 일어나는 걸 보지 못했어요. 판단력 높은 개인들이 회사 전체를 누비며 놀라운 일을 해낼 수 있어요. 하지만 어느 지점에서는 도메인 맥락의 부재에 막히게 돼요. 그래서 지속적인 팀이 이 시대에도 근본적인 빌딩 블록이에요.

5. 빠르고, 좋고, 지속 가능한 의사결정은 AI로부터 의미 있는 혜택을 누리기 위한 선결 조건이에요.
   법무 검토를 자동화로 대체하는 것은 법무팀이 그 변경에 동의할 수 있을 때만 작동해요. 이는 자동화를 신중하게 설계하는 것, 그리고 팀의 협업 의지 모두에 달려 있어요. 새로운 기능을 구현하는 것은 그 기능을 출시하기로 결정할 수 있을 때만 가치 있어요.

   팀과 회사가 이 빨라진 실행 속도를 실제로 활용하려면, 좋은 결정을 빠르게, 그리고 지속 가능하게 내릴 수 있어야 해요. 제 생각엔 이것이 평균적인 CTO 역할이 1년 전보다 훨씬 더 기술적이고 덜 관료적으로 변한 주된 이유예요. 많은 경우, 팀들이 방향에 동의하지 못할 때 구속력 있는 결정을 내릴 수 있는 건 저뿐이에요. 이 새로운 세계에서 속도를 유지하기 위해 저는 끊임없이 결정을 내리고 있어요. (이것이 임원이 더 나은 의사결정자라는 주장은 아니에요. 임원들이 서로 충분히 합의돼 있어서 그 결정을 실제로 따를 수 있을 때, 구속력 있는 임원 결정은 유독 강한 힘을 발휘한다는 뜻이에요.)

실제로 어떻게 했나요

위의 규칙들은 지난 1년간의 경험을 통해 진심으로 믿게 된 것들이에요. 이 믿음을 갖게 해준 구체적인 프로젝트들과 연결해볼게요.

1. 마이그레이션

   1. 1년 전, 저희는 수동으로 주 6회 정도 배포했어요. 지금은 주 200400회 배포해요. 엔지니어링 인원이 두 배가 됐지만, 이전 배포 횟수를 단순히 두 배로 늘려도 전년 대비 2030배 증가예요. 이는 배포 및 마이그레이션 방식을 전면 개편한 덕분이에요. 이 마이그레이션은 두 달에 걸쳐 인프라 팀의 두 명이 90%를 해냈어요.
   2. 1월 1일, 팀원의 약 25%가 매일 Claude Code 또는 Cursor를 사용하고 있었어요. 2월 말에는 100%가 됐어요. 상의하달 지시 없이, 그냥 도구를 좋게 만들고 미채택자들과 대화해서 마찰을 제거했어요. 지금은 거의 모든 PR이 하네스로 작성돼요. 적어도 1차 초안은요.
   3. 다양한 설정 메커니즘에서 두 가지 설정 메커니즘으로 마이그레이션했어요. 하나는 거의 변경되지 않는 클라이언트/서버 상수용이고, 다른 하나는 제품별 또는 자주 변경되는 값용이에요. 이것은 개별 엔지니어들이 독립적인 프로젝트로 진행한 대규모 변경 시리즈였어요. 먼저 한 엔지니어가 이 접근 방식을 지원하도록 아키텍처를 정리했어요. 그다음 다른 엔지니어가 새 접근 방식에 대한 레퍼런스 아키텍처를 만들었어요. 그다음 여러 엔지니어들이 코드베이스의 다른 영역에서 레퍼런스 아키텍처를 따랐어요. 이전 방식이었다면 여러 사람이 수년을 쏟았을 프로젝트예요. 엔지니어·비엔지니어 팀 전체가 사용하는 새 내부 설정 관리 도구까지 포함해서 한 분기 안에 완료됐어요.
   4. 멀티 레포 프론트엔드 아키텍처를 모노레포 프론트엔드 아키텍처로 약 한 달에 걸쳐 통합했어요. 한 프론트엔드 엔지니어가 95%를 이끌었어요. 이제 공유 프론트엔드 개발 하네스가 생겼고, 라이브러리를 저렴하게 유지보수할 수 있으며, 지속적인 마찰의 원인이었던 패키지 호스팅용 npm 사용도 완전히 벗어났어요.
   5. 원래 프론트엔드 코드 대부분에는 타입이 없었는데, 한 엔지니어가 수 주에 걸쳐 많은 토큰을 써서 전체를 완전히 정적 타입화했어요.
   6. 더 나은 보안 기본값과 빠른 배포를 위해 npm에서 pnpm으로 마이그레이션했어요. 한 엔지니어가 며칠 동안 하루에 몇 시간씩 작업해서 완료했어요.

2. 동작하는 코드의 비용은 개발 하네스에 달려 있어요

   1. 다른 팀의 엔지니어들에게 설계 문서와 PR을 “담장 너머로” 던져준 경우, 한 번도 제대로 진행된 적이 없었어요. 조잡한 풀 리퀘스트와 설계 문서는 값싸지만 오히려 해로워요. 정리하고 수정해야 하는 부담도 있지만, 더 큰 문제는 그 맥락이 LLM을 오염시킨다는 거예요. 처음부터 다시 시작하는 것보다 더 나쁜 결과가 나오게 돼요.
   2. 매니저들이 소프트웨어에 기여해서 엄청난 성과를 낸 사례를 봤어요. 단, 직접 결과를 검증하고, 배포 후 대시보드를 확인하고, 문제가 생기면 직접 수습한 매니저들에 한해서예요. 그런 과정 없이 변경만 시도한 경우에는 긍정적인 영향을 전혀 보지 못했어요.

3. 프로세스의 기본 케이스를 에이전트 기준으로 최적화하기

   1. 고객 운영팀에서 들어오는 모든 이슈를 하네스로 트리아지하고 있어요. 이 하네스는 팀 정보와 오픈 티켓을 알고 있고, 이슈의 영향도를 파악하기 위해 데이터 웨어하우스에도 제한적으로 접근할 수 있어요. 복잡하고 고숙련이지만 특별히 흥미롭지는 않은 작업인데, 이제 에이전트로 더 잘, 더 빠르게 하고 있어요. 엣지 케이스에 대한 사람의 트리아지는 여전히 있어요. 중요한 건, 사람의 워크플로우를 바꾸지 않고 한다는 점이에요. 같은 흐름 그대로, 일부 단계만 자동화한 거예요.
   2. 코드 리뷰의 1차는 변경 사항을 구현한 바로 그 하네스가 수행해요. 단, 코드를 작성할 때 사용한 맥락은 지운 상태로요. 이를 통해 사람들이 더 높은 가치의 피드백에 집중할 수 있어요.
   3. 지난 분기에 회사 전체에 Claude Code와 CoworkT3를 배포했어요. 각 팀에서도 점점 더 많은 업무를 스스로 자동화해 나가고 있어요. 사기 팀은 잠재적 공격에 대한 초기 조사를 자동화하는 데 특히 적극적이었어요. 수동 워크플로우를 자동화 1차 처리로 대체하되, 판단의 근거는 데이터 자체에서 명시하는 방식이에요.
   4. LinearT4로 마이그레이션하고 Jira를 떠났어요. 더 유능한 MCP와 더 나은 Slack 통합으로 이 워크플로우를 더 잘 지원하기 위해서예요. 덕분에 내부의 모든 사람이 에이전트 퍼스트 워크플로우를 구축하기 더 좋은 인프라를 갖추게 됐어요. 더 자세한 내용은 나중에 이야기하겠지만, Linear에서 이슈를 가져와 자동으로 해결하는 내부 하네스의 알파 테스트가 거의 끝나가고 있어요. 이것이 이 방향에서 다음으로 가장 큰 걸음이에요.

4. 도메인 맥락을 갖추고, 강한 오너십으로 지속하는 팀

   1. 제가 합류했을 때, 여러 영역을 매우 재능 있지만 프로젝트 단위로 빠르게 순환하는 사람들이 맡고 있었어요. 이것도 작동했지만, 이슈에 매우 수동적으로 반응하게 됐어요. 이제 회사의 모든 중요한 영역에 적어도 소규모 팀을 전담시킬 수 있게 됐어요. 그들이 지속적으로 투자할 수 있게 됐고요. 이 팀들은 이제 AI가 제공하는 모든 새로운 기법을 직접 활용하고 있어요. 동시에 너무 많은 일이 벌어지고 있어서, 전담 팀 없이는 아무도 이 기회들을 포착하지 못했을 거예요.
   2. SierraAIT5를 런칭했을 때는 꽤 잘 됐어요. 그 이후로 팀이 끊임없이 개선해서 진정으로 탁월한 수준으로 만들었어요. 전담하고 집중된 팀 없이는 할 수 없었을 일이에요.

5. 빠르고, 좋고, 지속 가능한 의사결정

   1. 설정 방식을 변경하는 것은 논란이 많은 결정이었고, 접근 방식에 대해 반복해서 명확히 해야 했어요. 각 팀에 미치는 영향이 다르고, 혜택은 생태계 수준에서야 느껴지기 때문에 바텀업으로 하기엔 매우 어려웠을 거예요. (혜택이란 건, 한 사람이 팀 전체의 모든 설정을 한 곳에서 구성할 수 있다는 것이에요.)
   2. CI/CD 파이프라인을 재작업하는 것도 논란이 많았어요. 배포와 릴리즈를 피처 플래그로 명시적으로 분리하도록 강제하는 등 많은 사람의 멘탈 모델을 바꿨어요. 논쟁적인 결정이었고, 바텀업으로는 느리고 어려웠을 거예요.
   3. 웹 모노레포로 통합하는 것도 다양한 의견이 있는 논란이 많은 결정이었어요. 통일된 결정으로 크게 혜택을 받았어요.
   4. SierraAI로 이동하는 것도 다양한 경쟁사와의 비교, 그리고 아예 하지 않는 것 대비 어려운 논의였어요. 여러 팀이 얽힌 논의를 마무리짓기 위해 임원이 최종 결정을 내려야 했어요.

• • •

이것들은 대표적인 예시일 뿐이에요. 훨씬 더 많은 것들을 해냈어요. 올해 매달 할 수 있는 것의 폭이 계속 넓어지고 있지만, 저희를 막고 있는 것들은 크게 변하지 않았어요. 조직의 불일치, 명확성 부족, 그리고 나쁜 기술 아키텍처. 기술 업계에서 일하기엔 정말 정신없이 대단한 시대예요.