엔지니어 1인당 코드 변경 5배, FurtherAI가 AI 네이티브 조직을 만든 방법
Building an AI-native engineering org
FurtherAI의 Sashank Gondala가 지난 9개월간 AI 네이티브 엔지니어링 조직을 구축하며 얻은 교훈을 공유한다. 1월 이후 엔지니어당 하루 머지하는 코드 변경 수는 약 5배 늘었고 revert율은 0.5% 미만을 유지했다. 코드 작성, 테스트, 리뷰, CI, 버그 접수, 머지까지 단계별로 에이전트를 도입했으며, 이제 변경의 최대 3분의 1이 사람 없이 머지된다. 그러나 코드 작성이 빨라지면서 계획과 리뷰가 전체 시간의 70%를 차지하는 새로운 병목이 드러났고, 그는 엔지니어에게 더 많은 소유권을 넘기는 방향으로 조직을 바꾸고 있다.
우리는 코드 작성 속도는 훨씬 빨라졌지만, 무엇을 만들지 결정하는 속도는 그만큼 빨라지지 않았다.
HN 토론
111- juancn
가치나 수익에 대한 언급은 단 한 번도 없네요.
올라간 지표는 딱 세 가지뿐입니다: LOC, 토큰 지출, 그리고 아마도 릴리스 속도/빈도겠죠.
마크업(이익/COGS)은 어떤가요? 올랐나요?
고객 만족도는요? NPS가 어느 쪽으로 움직이고 있나요?
- nater5000
이 글은 저한테 웃기게 느껴져요. 제대로 된, 미래지향적인 "AI 네이티브" 엔지니어링 조직의 실제 모습에는 한참 못 미친다고 생각하거든요. 그러니까, 글쓴이는 이걸 일반적인 엔지니어링에서 상당히 급진적으로 벗어난 것으로 제시하고 있는데, 제 눈에는 그냥 AI가 더해진 평범한 엔지니어링으로 보여요. 저는 그걸 AI 네이티브라고 보지 않습니다.
제게 진정한 "AI 네이티브" 엔지니어링은 인간이 코드 리뷰 같은 걸 어떻게 할지에 대한 질문이 무의미해지는 그런 것입니다. 전형적인 소프트웨어 엔지니어링이라는 개념 자체를 명시적으로 버리고, 대신 AI에 맡기는 거죠. 인간으로서 당신의 일은 오직 AI가 물리적으로 할 수 없는 일을 하는 것뿐입니다. 그건 AI가 현재 할 수 있는 것과 당신이 필요로 하는 능력 사이의 격차를 메우는 것과는 다릅니다. 말 그대로 AI가 할 수 있는 모든 것은 그 자체로 올바른 것으로 취급하고, 당신은 인간으로서 그것을 지원만 한다는 걸 강제하는 거예요.
그게 황당하게 들린다면, 실제로 황당하기 때문입니다. 우리에겐 아직 그렇게 유능한 AI 시스템이 없어요. 영원히 없을 수도 있고요. 하지만 그건 요점에서 벗어난 얘기입니다. 현실은 기존 프로세스와 시스템 위에 AI를 얹기만 해서 "AI 네이티브" 엔지니어링 조직을 만들려는 건 헛수고라는 거죠. AI의 능력이 가속하는 속도로 계속 향상될 거라고 기대한다면, 이런 임시방편들은 무의미합니다. 차라리 AI가 완전히 장악할 수 있을 때까지 AI를 아예 무시하는 게 낫겠죠. 그게 불가피한 목표니까요, 그렇죠?
그게 가능할 거라고 받아들일 의향이 있다면 […]
- simonw
이 시점에서, 꽤 많은 팀들이 올해 3월쯤부터 AI 우선, 완전히 리뷰되지는 않은 코드에 의존해 왔습니다.
즉 우리는 이미 6~8개월째 접어들었고, 그 기간 동안 모델 능력이 향상된 것에 이상하게도 영향을 받긴 했지만, 실제로 그게 어떤 모습인지 거의 1년치 경험을 갖게 되는 것과 다름없죠.
그 회고들이 기대됩니다. 그렇게 한 팀들에게 이게 잘 통했나요? 가장 큰 실패나 놀라움은 무엇이었나요? 돌이켜보면, 이게 좋은 품질의 소프트웨어를 만들어냈나요?
- fg137
저는 방금 Claude가 제게 생성해 준 사용자 대상 오류 메시지 몇 개를 보고 있었는데, 불필요하거나 관련 없는 기술적 세부 사항이 들어 있으면서도 명확한 지침이나 해결책을 제공하지 못하더군요.
얼마 전에는 명시된 범위보다 훨씬 많은 일을 하고, 공개 API를 바꾸고, 새로운 동작을 도입하는 코드를 리뷰했어요. 거의 전부를 다시 해야 했습니다.
속으로 생각했죠, 실제로 코드를 읽어보지 않고서(혹은 어떤 사람들이 말하듯 "의도"만 보고서) 작성된 그대로 코드를 배포할 리 없다고. 코드나 실제 동작이 어떻게 돌아가는지 전혀 모른 채 사용자 불만만 더 받게 될 테니까요.
이런 조직들이 어떻게 해내는 건지 정말 궁금하네요.
- liorgrossman
저를 포함한 많은 빌더들이 잘못된 것에 집중하는 함정에 빠지는 걸 봅니다. 개발 속도 자체는 중요하지 않고, 중요한 건 수익이나 견인력의 성장 같은 것들이죠. 자동화/시스템/프로세스를 실제 비즈니스 성과와 혼동하기는 정말 쉽습니다. 움직임 ≠ 진전이니까요.
- simonw
관련해서: 이 글은 클릭베이트 제목 덕분에 Hacker News 홈페이지에 오르기 매우 어려웠을 텐데, 그래도 읽어보시길 권합니다: https://twitter.com/jsnnsa/status/2115623382721126826
한 팀이 토큰에 급여의 30배인 월 3,000,000달러를 토큰 지출로 쓰면서 멀티플레이어 게임을 만드는데, 사용자들의 인시던트와 버그 리포트가 Fable 5/5.1 에이전트에게 직접 전달되어 에이전트가 조치하고 변경 사항을 프로덕션에 배포한다는 내용입니다.
"매시간 배포하지 못하면 우리는 이를 장애로 간주한다"
완전한 재앙이거나 미래의 한 단면, 혹은 아마 둘 다일 수 있어서 읽어볼 가치가 있습니다.
- mirmor23
몇 분 동안 인포머셜을 읽었는데 후회했어요. 엔지니어링 원칙이 먼저 기반이 되어야 하고, AI 도구는 그 원칙에 맞춰지는 것이지 이 인포머셜이 주장하듯 그 반대가 아닙니다. 링크드인 냄새가 나는 것도 크게 거슬리네요.
- DavCreator