지난주 Will Larson(@Lethain)가 리더들이 AI 역량을 가진 엔지니어 매니저를 어떻게 평가하는지에 대해 질문했습니다. 제가 생각해 볼 만한 질문 목록으로 답을 올렸는데, 많은 북마크를 받았습니다.
좀 더 광범위하게는, 저는 한동안 AI 네이티브(AI-native) 엔지니어링 조직을 구축하는 방법에 대해 고민해 왔습니다. FurtherAI에서 지난 9개월 동안 구축하면서 얻은 몇 가지 교훈을 공유합니다.
파트 1: 배포 방식의 변화
엔지니어당 배포량 증대
지난 1월 이후, 각 엔지니어가 하루에 병합하는 코드 변경(code changes) 수는 약 5배 증가했으며, 저희의 되돌림 비율(revert rate)은 0.5% 미만을 유지했습니다.
하지만 엔지니어들에게 코딩 에이전트(coding agents)를 제공하는 것만으로는 여기까지 도달할 수 없었습니다.
우리가 한 단계를 가속화할 때마다, 다음 단계에 작업 부하가 쌓였습니다.
그래서 저희는 소프트웨어를 배포하는 전체 프로세스를 한 단계씩 거치며, 무엇을 최적화할 수 있을지 파악하기 시작했습니다.
배포 프로세스 재구축
– 에이전트가 코드를 작성하고 엔지니어가 이를 조종합니다. 이 과정이 언제부터 시작되었는지 명확한 숫자는 없지만, 초창기에는 도구가 변경 사항에 표시를 남기는 것이 가끔씩이었을 뿐입니다. 하지만 이제는 거의 100%라고 말해도 좋습니다.코드 (3월)– 에이전트가 코드와 함께 테스트도 작성합니다. 변경 사항의 91%에 테스트가 포함되며, 이는 이전 15%에서 증가한 수치입니다.테스트 (4월)– AI가 사람이 검토하기 전에 변경 사항의 99%를 검토합니다. 이는 이전 60%에서 증가한 수치이며, 인간 검토자는 판단이 필요한 부분에 집중할 수 있습니다.검토 (5월)– 테스트를 병렬화하고 변경 사항에 영향을 받는 것만 실행합니다. 이제 CI(지속적 통합)는 동일한 17분 동안 이전보다 20배 많은 테스트를 실행합니다.CI (6월)– 저희는 버그 접수 프로세스를 자동화하기 위해 ClaudeTag(@claudeai) 사용을 시작했습니다. 누구나 Slack에서 버그를 보고할 수 있으며, ClaudeTag가 중복 여부를 파악하고, 티켓을 작성하며, 적절한 담당자에게 할당합니다. 이제 버그 티켓의 60%를 처리합니다.버그 보고 (7월)– 버그나 검토 코멘트에서 엔지니어만이 아는 규칙이 노출되었을 때, 저희는 이를 모든 커밋과 PR(Pull Request)마다 실행되는 작은 Python 체크로 변환했습니다. 이 체크가 실패하면 빌드가 중단되고 수정 사항이 출력됩니다. 이런 방식으로 우리는 암묵지(tribal knowledge)를 규칙으로 전환합니다. 에이전트들은 이 체크들을 통과하며, 스스로 코드를 수정하고 다음 단계로 넘어갑니다.
우리는 0개에서 21개의 규칙을 갖게 되었습니다. 이 규칙들은 저위험 변경 사항이 사람의 개입 없이 병합될 수 있게 된 주요 원인입니다.
규칙 (8월) – 테스트, 자동화된 검사 및 AI 검토를 통과한 저위험 변경 사항은 스스로 병합됩니다. 현재 저희는 변경 사항 중 최대 3분의 1이 사람의 개입 없이 병합되고 있습니다.
병합 (8월) – 누구나 Slack 채널을 열고 에이전트에게 변경 사항을 설명하여 PR(Pull Request)을 열 수 있습니다. 아직 정확한 숫자는 없지만, 협업에 매우 도움이 되었습니다. 여러 사람이 하나의 채널에서 동일한 에이전트를 사용하여 컨텍스트를 추가하고 진행 상황에 따라 방향을 제시할 수 있었습니다. 또한 저희는 팀 단위의 협업을 위해 Devin의 (@cognition) 클라우드 세션을 적극적으로 사용합니다.
코드 채널 (9월)
저희는 사내 Poirot 및 Sherlock 에이전트를 사용하여 운영 환경(production)과 스테이징 환경(staging) 전반에 걸쳐 문제를 조사하고 해결하기도 합니다. 이 에이전트들은 로그, 메트릭, 트레이스 및 읽기 전용 데이터베이스 접근 권한을 통해 필요한 모든 도구와 컨텍스트를 갖추고 있습니다.
가장 흥미로운 순간은 에이전트들이 함께 작동할 때입니다. Claude Tag가 요청을 분류(triage)하고, Devin이 작업을 수행하며, Poirot가 필요한 내부 데이터를 가져오는 식입니다. 이들이 서로 대화하고 정보를 전달하는 것을 지켜보는 것은 재미있습니다.
흥미로운 부작용 중 하나는 엔지니어가 아닌 사람들도 코드를 배포하기 시작했다는 점입니다. 저희 디자이너는 디자인 시스템을 구축한 변경 사항들을 포함하여 8월 이후 약 50개의 변경 사항을 병합했습니다. 또한 배포 및 고객 대면 역할을 맡은 직원들조차 Slack에서 직접 UI 수정이 가능합니다.
비용 분석
이 모든 것이 공짜는 아니었습니다. 여름 동안 저희 엔지니어링 노력의 상당 부분은 테스트와 도구 개발에 투입되었으며, 엔지니어당 고객 대면 변경 사항 수는 월 17개에서 30개 사이를 유지했습니다.
9월에는 이 수치가 45개로 급증했으며, 10월은 48개를 목표로 하고 있습니다.
파트 2: 팀의 변화
엔지니어링 속도가 빨라짐에 따라 저희는 다른 문제를 인식하기 시작했습니다.
새로운 병목 지점
저희는 코드를 작성하는 것에는 훨씬 빨라졌지만, 무엇을 구축할지 결정하는 것은 그만큼 빠르지 않습니다.
여기에 단순화된 예시를 소개합니다.
한 기능이 예전에는 10일이 걸린다고 가정해 봅시다. 계획에 3일, 구축에 6일, 검토에 1일이 소요되었습니다.
만약 에이전트가 구축 속도를 3.5배 빠르게 만들지만, 계획과 검토는 변하지 않는다면, 전체 기능은 단지 1.75배만 빨라집니다.
이제 계획과 검토가 시간의 70%를 차지하며, 이전에는 40%였습니다.
전통적으로 이러한 많은 결정들은 엔지니어링 매니저, PM(제품 관리자), 디자이너를 거쳐 이루어졌습니다. 엔지니어들이 빨라질수록 이는 점점 더 어려워집니다.
의사 결정과 검토 단계에서 병목 현상(bottlenecks)을 만들지 않으면서 엔지니어들이 훨씬 빠르게 구축할 수 있는 팀을 어떻게 구성해야 할까요?
저희의 생각은 엔지니어들에게 더 많은 오너십(ownership)을 부여하는 것입니다. 관리 계층을 추가하기보다는, 엔지니어들이 계획, 실행, 검토 과정의 대부분을 스스로 처리하도록 하는 것입니다.
이는 우리가 엔지니어와 매니저에게 기대하는 바를 변화시킵니다.
엔지니어에게 의미하는 것
저는 이제 엔지니어링 시니어리티(seniority)를 누군가가 문제를 처음부터 끝까지 얼마나 오너십 할 수 있는지의 관점에서 생각하기 시작했습니다. 대략적으로는 다음과 같습니다:
– 에이전트로 구축하고 잘못되었을 때를 파악할 수 있다. 주니어 엔지니어(Junior engineer)
– 자신의 작업을 계획하고 검토한다. 시니어 엔지니어(Senior engineer)
– 모호한 문제를 받아들여 트레이드오프(tradeoffs)를 결정하고, 그것이 작동했는지 여부를 보여주는 숫자를 오너십 한다. 스태프 엔지니어(Staff engineer)
또한 이는 엔지니어가 고객에게 더 가까워져야 함을 의미합니다.
우리는 엔지니어들이 고객 문제 이해부터 솔루션 배포, 성공 검증, 그리고 프로덕션 환경의 회귀(regressions) 오너십까지 프로세스 전반에 걸쳐 더 많은 주도권을 갖도록 역량을 강화하고 있습니다.
매니저에게 의미하는 것
이는 엔지니어링 매니저에게 기대하는 바 또한 변화시킵니다.
1. 업무에 직접 참여하기.
매니저는 무엇을 구축하고 있는지, 왜 필요한지, 그리고 그것이 올바른 해결책인지 이해해야 합니다.
저는 매니저들이 코드가 검토되었는지 확인하는 것을 넘어, 최종 사용자처럼 스테이징(staging) 환경에서 기능을 직접 사용해 보기를 바랍니다. 실제로 제품을 사용하면 다른 유형의 문제들을 발견할 수 있기 때문입니다.
하지만 목표는 단순히 검토하는 양을 늘리는 것이 아닙니다. 언제나 그랬듯이, 관리자가 판단이 필요한 경우에만 개입할 수 있도록 스스로 올바른 결정을 내릴 수 있는 엔지니어를 육성하는 것입니다.
2. 제품 이해도를 높여야 합니다 (Be more product-savvy).
코드를 작성하는 것이 저렴해질수록, 무엇을 만들지 결정하는 것이 훨씬 더 중요합니다.
저는 고객을 이해하고, 강력한 제품 의견(product opinions)을 가지고 있으며, 기술적인 문제뿐만 아니라 제품 관련 의사결정을 내리는 데 편안함을 느끼는 엔지니어링 매니저를 원합니다. 또한 그들은 엔지니어들이 이러한 판단력을 개발하도록 도와야 합니다. 모든 사소한 제품 결정에 PM이나 디자이너가 필요해서는 안 됩니다.
이것이 우리에게 남기는 것들
우리는 올해 대부분을 엔지니어를 더 빠르게 만드는 방법을 찾는 데 보냈습니다. 이제 우리는 조직 전체를 그 속도로 움직이게 하는 방법을 찾으려고 노력하고 있습니다.
저는 이것이 코드, 테스트 및 검토 자동화보다 더 어려운 문제일 것이라고 생각합니다.
우리는 아직 초기 단계이며, 우리가 파악하지 못한 것들이 많습니다. 하지만 제가 작업해 본 가장 흥미로운 엔지니어링 과제 중 하나입니다.
다른 팀들은 어떤 것을 보고 있는지 궁금합니다. 엔지니어가 더 빠르게 배포(shipping)하기 시작했을 때 무엇이 가장 먼저 무너졌나요?
저희는 다음 단계의 도전을 해결하기 위해 @furtheraicom에서 Engineering Manager / Director를 채용하고 있습니다. 흥미롭게 느껴진다면 연락 주세요!
