이 글은 2014년부터 2020년까지 고속 성장 환경에서 얻은 경험과 2025년 Imprint의 빠른 성장 및 AI 도구 도입으로 인한 작업 속도 변화를 바탕으로, 엔지니어링 리더십에 대한 새로운 접근 방식을 제시합니다. 저자는 지난 한 해 동안 진행된 구체적인 프로젝트들을 통해 이러한 규칙들이 왜 중요하고 어떻게 적용되는지 설명하며, 이전보다 훨씬 빠르게 변화하는 기술 환경에서 조직의 성공을 위한 핵심 전략을 강조합니다.

1. 개정된 엔지니어링 리더십 규칙들 ✨

1.1. 마이그레이션은 개인이 주도할 수 있다 🏃‍♀️

예전에는 복잡하고 큰 변화를 동반하는 마이그레이션은 여러 팀이 오랜 시간 협력해야 하는 일로 여겨졌어요. 하지만 이제는 한두 명의 개인이 마이그레이션의 95% 이상을 주도하고, 훨씬 짧은 시간에 완료할 수 있습니다. 마이그레이션에 필요한 초기 비용이 낮아지면서, 그 결과물의 품질이 더욱 중요해졌어요. 작은 문제라도 동료들의 소프트웨어에 대한 이해를 깨뜨릴 수 있기 때문이죠. 개인이 회사에 미치는 영향력이 그 어느 때보다 커진 시대입니다!

1.2. 개발 환경(Harness)이 작업 코드의 비용을 결정한다 🛠️

요즘 많은 회사에서 '모두가 코드를 작성해야 한다'고 말하지만, 실제로는 잘 작동하는 코드를 작성하고 예상치 못한 문제들을 피하는 것은 여전히 어려운 일이에요. 코드 작성의 난이도는 테스트, CI/CD, 검증 환경, 변경 사항 미리 보기 기능 등 개발 환경(development harness)에 크게 좌우됩니다. 마케팅팀이 직접 서버 자원을 줄이지는 않겠지만, 안전한 경계 내에서 참여할 수 있는 환경이 중요하다는 의미와 같아요. 2년 전이나 지금이나 엔지니어링 속도를 높이는 데 가장 중요한 요소는 바로 이런 개발 환경의 개선이라는 점을 잊지 마세요!

1.3. 대부분의 프로세스는 에이전트 중심으로 최적화될 수 있다 🤖

대부분의 프로세스는 초기 단계에서 자동화된 에이전트를 통해 처리될 수 있습니다. 적절한 개발 환경, 제어 시스템, 도메인 지식, 그리고 설계자의 뛰어난 판단력이 있다면, 현대 기술 기업의 대부분 프로세스 초기 단계를 완전히 자동화할 수 있어요. 예를 들어, 인간이 직접 코드 리뷰를 하는 것보다 잘 설계된 개발 환경이 훨씬 빠르고 효과적인 코드 리뷰를 제공할 수 있죠. 물론 에이전트도 놓치는 부분이 있겠지만, 사람도 마찬가지이고, 대부분의 영역은 비교적 안전하게 변경할 수 있습니다. 위험도가 높은 특정 영역을 효과적으로 구분하여 처리한다면, 위험 없이 훨씬 빠르게 진행할 수 있습니다. 😮

"인간이 함께 계획하는 것은 여전히 중요하지만, 더 높은 수준에서 작동해야 합니다."

1.4. 높은 소유권을 가진 견고한 팀이 더욱 중요해졌다 🤝

이전에 Uber에서 얻은 가장 큰 교훈 중 하나는 영속적이고 견고한 팀이 놀라운 성과를 낸다는 점입니다. 이러한 팀들은 도메인 지식을 축적하고, 동료애를 형성하며, 특정 영역에 대한 소유감을 강화하면서 마법 같은 결과를 만들어냅니다. AI 시대에도 특정 작업을 훨씬 저렴하게 수행할 수 있게 되었지만, 여전히 '올바른 일'을 해야 합니다. 이는 조금 더 쉬워졌지만 근본적으로 크게 쉬워진 것은 아니며, 구조적인 개선이 이 문제를 해결하는 데 도움이 됩니다.

흔히 AI 중심 기업에서는 소수의 천재 엔지니어가 완벽한 결과물을 하나씩 만들어내고, 유지보수할 필요가 없을 정도로 잘 해낼 것이라는 인식이 있지만, 저는 그렇게 보지 않습니다. 뛰어난 판단력을 가진 개인들이 회사 전체에서 놀라운 일을 할 수는 있지만, 결국 도메인 지식의 부족으로 한계에 부딪히게 될 것입니다. 그렇기 때문에 견고한 팀은 AI 시대에도 여전히 기본적인 구성 요소로 남을 것입니다. 💪

1.5. 빠르고, 올바르며, 지속 가능한 의사 결정이 AI 활용의 전제 조건이다 🎯

법률 검토를 자동화로 대체하는 것은 법률 팀이 그 변화를 수용할 때만 가능합니다. 이는 자동화를 신중하게 설계하고, 팀들의 협업 의지가 있을 때 비로소 가능하죠. 새로운 기능을 구현하는 것도 그 기능을 출시하기로 결정할 수 있을 때만 가치가 있습니다.

회사가 이러한 향상된 실행 속도의 이점을 얻으려면 빠르고, 올바르며, 지속 가능한 의사 결정을 내릴 수 있어야 합니다. 제 생각에 이것이 평균적인 CTO 역할이 1년 전보다 훨씬 기술적이고 덜 관료적으로 변해야 하는 주된 이유입니다. 팀 간에 의견이 불일치할 때 구속력 있는 결정을 내릴 수 있는 유일한 사람이 되는 경우가 많아졌고, 새로운 환경에서는 이 속도를 유지하기 위해 끊임없이 결정을 내리고 있습니다. 🗣️

2. 실제 적용 사례들 💡

지난 한 해 동안 Imprint에서 진행된 프로젝트들을 통해 위의 규칙들이 어떻게 적용되었는지 구체적인 사례를 공유해 드릴게요.

2.1. 마이그레이션 프로젝트 사례들 🔄

• 배포 프로세스 개선: 1년 전에는 수동으로 주 6회 정도 배포했지만, 지금은 주 200~400회 배포합니다! 😲 엔지니어링 인력은 두 배로 늘었지만, 배포 횟수는 20~30배 증가했어요. 이는 인프라팀 두 명이 두 달 동안 마이그레이션을 주도하여 배포 방식을 완전히 바꾼 덕분입니다.
• AI 코딩 도구 도입: 1월 초에는 팀원의 약 25%만이 Claude Code나 Cursor를 사용했지만, 2월 말에는 100%가 사용하게 되었어요. 위에서 지시하지 않고도 좋은 도구를 제공하고, 불편함을 해소해주면서 자연스럽게 이루어진 변화였습니다. 이제는 거의 모든 PR의 초안이 AI에 의해 작성되고 있습니다.
• 설정 관리 통일: 다양한 설정 메커니즘을 두 가지로 통일했어요. 이는 예전 같으면 여러 사람이 몇 년이 걸릴 프로젝트였겠지만, 한두 명의 엔지니어가 주도하여 한 분기 만에 완료되었고, 엔지니어와 비엔지니어 팀 모두가 값을 관리할 수 있는 새로운 내부 도구까지 만들어졌습니다.
• 프런트엔드 모노레포 전환: 여러 개의 리포지토리에 분산되어 있던 프런트엔드 애플리케이션 아키텍처를 한 달 만에 모노레포로 통합했습니다. 한 명의 프런트엔드 엔지니어가 95%를 주도했어요. 이제 공유된 개발 환경을 사용하고, 라이브러리 유지보수 비용을 절감하며, npm 사용으로 인한 마찰도 완전히 없앴습니다.
• 프런트엔드 코드 정적 타이핑: 대부분 타입이 없던 프런트엔드 코드를 몇 주 만에 완전히 정적 타이핑으로 바꿨습니다. 이것도 한 명의 엔지니어가 해낸 일입니다.
• 패키지 관리자 교체: npm에서 pnpm으로 전환하여 보안 기본값을 강화하고 배포 속도를 높였습니다. 한 명의 엔지니어가 며칠 동안 하루에 몇 시간씩 투자하여 이루어졌어요.

2.2. 개발 환경이 작업 코드의 비용을 결정한다는 사실을 깨달은 경험들 💡

• 부실한 PR과 설계 문서의 해악: 다른 팀 엔지니어들에게 대충 만든 설계 문서나 PR을 넘겨주면, 아무런 진전도 없었습니다. 이런 것들은 만들어내는 데는 비용이 적게 들지만, 오히려 해로울 수 있어요. 수정해야 할 뿐만 아니라, LLM(대규모 언어 모델)의 컨텍스트를 오염시켜 처음부터 다시 시작하는 것보다 못한 결과를 초래하기도 합니다.
• 관리자의 코드 기여 효과: 관리자들이 직접 소프트웨어 개발에 참여하고, 변경 사항이 적용된 후 대시보드를 확인하며, 문제가 발생하면 직접 해결하는 경우 엄청난 성공을 거두었습니다. 하지만 이런 과정을 거치지 않는 경우에는 긍정적인 영향을 거의 찾을 수 없었어요.

2.3. 에이전트 중심 프로세스 최적화 사례들 🤖

• 고객 지원 이슈 자동 분류: 고객 운영팀에서 들어오는 모든 이슈를 에이전트가 자동으로 분류합니다. 이 에이전트는 팀 정보, 열려 있는 티켓, 데이터 웨어하우스 접근 권한을 활용하여 이슈의 영향을 측정하죠. 이는 복잡하고 숙련된 작업이지만, 이제는 에이전트를 통해 더 빠르고 효율적으로 처리되고 있습니다. 물론 예외적인 경우에 대비하여 사람이 직접 확인하는 과정은 여전히 존재합니다. 중요한 점은 인간의 작업 흐름을 바꾸지 않고, 일부 단계를 자동화하는 방식으로 진행되었다는 것입니다.
• 코드 리뷰 초안 자동화: 코드 변경 사항을 구현하는 동일한 개발 환경이 코드 리뷰의 초안을 작성합니다. 이를 통해 사람들은 더 가치 있는 피드백에 집중할 수 있게 되었어요.
• 전사적 AI 도구 도입: 지난 분기에 Claude Code와 Cowork를 모든 직원에게 도입했고, 이를 통해 많은 업무를 자동화하는 모습을 보았습니다. 특히 사기 방지팀은 수동으로 하던 업무를 데이터 기반의 자동화된 초안으로 대체하여 잠재적인 공격에 대한 초기 조사를 자동화하는 데 매우 적극적이었습니다.
• Linear로의 전환: Jira 대신 Linear를 도입하여 워크플로우를 개선했습니다. 더 강력한 MCP(Master Control Program)와 향상된 Slack 통합을 통해, 모든 직원이 에이전트 중심의 워크플로우를 구축하는 데 더 나은 인프라를 갖게 되었습니다. 이제 Linear에서 이슈를 가져와 자동으로 해결하는 내부 시스템을 테스트 중이며, 이것이 다음 목표입니다.

2.4. 견고한 팀의 중요성을 보여준 사례들 🤝

• 전담 팀 구축: 제가 합류했을 당시에는 뛰어난 직원들이 프로젝트별로 여러 영역을 빠르게 순환했습니다. 물론 일은 진행되었지만, 문제 발생 시 즉각적인 대응이 어려웠어요. 지금은 회사의 모든 중요한 영역에 최소한 소규모 전담 팀을 배치할 수 있게 되었고, 이 팀들이 지속적으로 투자하며 AI가 제공하는 모든 새로운 기술들을 활용하고 있습니다. 이 팀들이 없었다면 이러한 기회들을 포착할 수 없었을 것입니다.
• SierraAI 개발 및 개선: SierraAI를 출시했고, 이후 팀은 끊임없이 반복 작업을 통해 이를 정말 훌륭하게 만들었습니다. 전담하고 집중하는 팀이 없었다면 불가능했을 일입니다.

2.5. 빠르고, 올바르며, 지속 가능한 의사 결정의 필요성 🎯

• 설정 방식 변경: 설정 방식을 변경하는 것은 논란이 많은 결정이었고, 이에 대한 설명을 여러 번 해야 했습니다. 이 결정은 각 팀에 다르게 영향을 미치기 때문에 아래에서 위로(bottom-up) 진행하기는 매우 어려웠을 것입니다. 결정의 이점은 전체 시스템 수준에서 발휘되기 때문입니다.
• CI/CD 파이프라인 재정비: CI/CD 파이프라인을 재정비하는 것 또한 논란이 많았습니다. 이는 배포 및 릴리스 방식에 대한 많은 사람들의 인식을 바꾸었기 때문입니다(예: 기능 플래그를 통해 배포와 릴리스를 명시적으로 분리해야 했습니다). 이 역시 아래에서 위로 결정하기에는 느리고 어려웠을 것입니다.
• 웹 모노레포 통합: 웹 모노레포로 통합하는 것 또한 다양한 의견이 있었던 논란의 여지가 있는 결정이었지만, 통합된 의사 결정 덕분에 큰 이점을 얻을 수 있었습니다.
• SierraAI 도입: SierraAI 도입은 경쟁 제품들과의 비교는 물론, 아예 도입하지 않는 방안까지 고려하며 어려운 논의를 거쳤습니다. 이 기능 교차 기능 토론을 마무리하기 위해서는 경영진의 결정이 필요했습니다.

이들은 단지 대표적인 예시이며, 실제로는 훨씬 더 많은 일을 해냈습니다. 올해는 매달 '무엇이 가능한가'의 범위가 계속 확장되었지만, 우리를 가로막는 요소들(조직적 불일치, 명확성 부족, 좋지 못한 기술 아키텍처)은 크게 변하지 않았습니다. 기술 분야에서 일하기에 정말 흥미진진한 시기네요! 🎢

결론 🌟

AI 시대의 엔지니어링 리더십은 개인의 역량 발휘, 최적화된 개발 환경, 에이전트 중심의 프로세스 자동화, 강력한 도메인 지식을 갖춘 팀, 그리고 신속하고 정확한 의사 결정에 그 성패가 달려 있습니다. 이러한 변화의 물결 속에서 우리는 조직의 구조와 업무 방식을 끊임없이 재고하고 혁신해야 할 것입니다. 🚀