FurtherAI가 AI 에이전트로 배포 과정을 다시 짜자 병목이 의사결정으로 옮겨갔다

Hacker News그저께

FurtherAI의 공동창업자 겸 CTO인 Sashank Gondala가 X에 공개한 글은 'AI 네이티브 엔지니어링 조직'을 9개월간 실제로 만들어보며 얻은 관찰을 정리한 것이다. Will Larson이 엔지니어링 매니저의 AI 역량을 어떻게 평가하는지 물었던 논의에서 출발했지만, 글의 본체는 코드 생산부터 배포·장애 대응까지 파이프라인 전체를 단계별로 다시 짠 기록에 가깝다.

출발점은 숫자다. 올해 1월 이후 엔지니어 한 명이 하루에 머지하는 코드 변경 건수는 약 5배로 늘었고, 되돌림(revert) 비율은 0.5% 아래를 유지했다. 다만 저자는 코딩 에이전트를 나눠준 것만으로 이 결과가 나온 건 아니라고 선을 긋는다. 한 단계를 빠르게 만들 때마다 그다음 단계에 작업이 쌓였고, 결국 소프트웨어를 내보내는 전 과정을 하나씩 뜯어보며 최적화 지점을 찾는 방식으로 접근했다.

단계별 변화는 시기와 수치로 제시된다. 3월부터 코드는 사실상 100% 에이전트가 작성하고 엔지니어가 방향을 잡는 형태가 됐다. 4월에는 테스트를 코드와 함께 에이전트가 쓰도록 했고, 테스트를 포함하는 변경 비중이 15%에서 91%로 올라갔다. 5월에는 사람보다 AI가 먼저 변경의 99%를 리뷰하도록 했으며(이전 60%), 사람은 판단이 필요한 부분에 집중하게 됐다. 6월에는 영향받는 테스트만 골라 병렬 실행하도록 CI를 손봐서 같은 17분 안에 20배 많은 테스트를 돌린다.

7월에는 사내 슬랙에서 누구나 버그를 신고하면 ClaudeTag가 중복을 걸러내고 티켓을 만들어 담당자에게 배정하는 구조를 붙였다. 전체 버그 티켓의 60%가 이 방식으로 생성된다. 8월에는 엔지니어 개인에게만 있던 암묵지를 커밋과 PR마다 실행되는 작은 파이썬 검사 21개로 바꿔, 실패 시 빌드를 멈추고 수정 방법까지 출력하게 했다. 같은 달부터 테스트·자동 검사·AI 리뷰를 통과한 저위험 변경은 사람 없이 머지되며, 전체 변경의 최대 3분의 1이 여기에 해당한다.

9월에는 슬랙 채널을 열어 에이전트에게 변경을 설명하고 PR을 받는 방식이 추가됐다. 여러 사람이 한 채널에서 같은 에이전트에 맥락을 더하고 방향을 조정할 수 있다는 점이 협업 측면에서 유용했다고 한다. 프로덕션과 스테이징 이슈를 조사하는 사내 에이전트 Poirot과 Sherlock도 로그·메트릭·트레이스·읽기 전용 DB 접근 권한을 갖고 운영된다. 티켓 분류는 ClaudeTag가, 실제 작업은 Devin이, 내부 데이터 조회는 Poirot이 맡는 식으로 에이전트끼리 정보를 넘기는 장면도 나온다.

부수 효과도 있었다. 비엔지니어가 코드를 내보내기 시작한 것이다. 디자이너는 8월 이후 디자인 시스템 구축분을 포함해 약 50건의 변경을 머지했고, 배포나 고객 대응 역할의 인원도 슬랙에서 직접 UI를 손본다. 공짜는 아니었다. 여름 내내 엔지니어링 역량 상당 부분이 테스트와 툴링에 들어갔고, 엔지니어 1인당 월간 고객 대상 변경 건수는 17~30건에 머물렀다. 9월에 45건으로 뛰었고 10월은 48건 페이스다.

여기서 두 번째 문제가 드러난다. 코드를 쓰는 속도는 빨라졌지만 무엇을 만들지 정하는 속도는 그대로였다는 점이다. 기획 3일, 구현 6일, 리뷰 1일이 걸리던 기능을 예로 들면, 구현만 3.5배 빨라져도 전체 소요는 1.75배 단축되는 데 그친다. 기획과 리뷰가 차지하는 시간 비중은 40%에서 70%로 커졌다. 이 결정들이 매니저·PM·디자이너를 거쳐 흐르는 구조에서는 엔지니어가 빨라질수록 병목이 심해진다.

조직의 선택은 관리 계층을 늘리는 대신 엔지니어에게 소유권을 더 넘기는 것이다. 저자는 시니어리티를 '문제를 어디까지 끝까지 책임질 수 있는가'로 다시 정의한다. 주니어는 에이전트와 함께 만들되 결과가 틀렸을 때 알아채는 수준, 시니어는 자기 작업을 스스로 기획하고 리뷰하는 수준, 스태프는 모호한 문제를 받아 트레이드오프를 정하고 성과 지표까지 책임지는 수준이다. 고객 문제 이해부터 배포, 성과 검증, 프로덕션 회귀 대응까지 엔지니어가 직접 맡는 범위가 넓어진다.

매니저의 역할도 함께 바뀐다. 무엇을 왜 만드는지, 그게 맞는 해법인지 이해해야 하고, 코드 리뷰 여부를 확인하는 대신 스테이징에서 실제 사용자처럼 기능을 써봐야 한다는 것이다. 목표는 리뷰를 늘리는 게 아니라 엔지니어가 스스로 옳은 판단을 내리도록 길러서, 매니저가 개입할 지점을 줄이는 데 있다. 저자는 고객을 이해하고 제품에 대한 의견을 가지며 제품 결정을 편하게 내릴 수 있는 엔지니어링 매니저상을 요구한다.

글은 아직 초기라는 단서를 달고 끝난다. 코드 자동화보다 조직 전체를 같은 속도로 움직이는 일이 더 어려운 문제일 것이라는 전망과 함께, 다른 팀들이 엔지니어의 배포 속도가 빨라질 때 가장 먼저 무엇이 무너졌는지 묻는 것으로 마무리된다. FurtherAI는 이 문제를 함께 풀 엔지니어링 매니저·디렉터를 채용 중이라고 덧붙였다.