요약
코딩 에이전트만으로는 부족하고, 배포 과정 전체를 고쳐야 AI 네이티브 조직이 됩니다.
퍼더AI의 공동 창업자이자 CTO인 사샨크 곤달라가 지난 9개월의 경험을 정리한 글입니다. 윌 라슨이 엔지니어링 관리자의 AI 역량을 어떻게 평가하는지 물은 일을 계기로 썼습니다.
왜 중요한가
- 한 단계를 빠르게 하면 다음 단계에 일이 밀리므로, 도구 도입만으로는 속도가 오르지 않습니다.
- 병목이 무엇을 만들지 정하는 일로 옮겨 가면서 엔지니어와 관리자에게 기대하는 역할도 달라집니다.
핵심 내용
- 1월 이후 엔지니어 1인당 하루 병합 건수는 약 5배 늘었고, 되돌림 비율(병합 후 취소한 변경의 비율)은 0.5% 미만을 유지했습니다.
- 코드, 테스트, 리뷰, 병합을 차례로 자동화해 이제 변경의 최대 3분의 1은 사람 없이 병합됩니다.
- 엔지니어만 알던 규칙을 커밋마다 도는 파이썬 검사 21개로 옮겨, 에이전트가 스스로 코드를 고치게 했습니다.
- 여름까지는 테스트와 도구에 힘을 쏟느라 고객용 변경이 1인당 월 17~30건에 머물렀고, 9월에야 45건으로 뛰었습니다.
- 저자는 관리 계층을 늘리는 대신 엔지니어에게 계획부터 성과 확인까지 맡기고, 관리자에게는 제품 감각을 요구합니다.
HN 반응
- 매출이나 고객 만족은 없이 코드량과 병합 수만 내세운다는 비판이 이어졌고, 되돌림 비율만은 볼 만하다는 평가도 나왔습니다.
- 기존 방식에 AI를 얹었을 뿐이라는 지적에는, 대부분의 회사가 실제로 겪는 과도기라는 반론이 나왔습니다.
가치나 매출 이야기는 한 마디도 없습니다.
올라간 지표는 코드 줄 수, 토큰 사용량, 그리고 아마도 릴리스 속도와 빈도, 이 세 가지뿐입니다.
마크업(이익/매출원가)은 어떤가요? 올랐나요?
고객 만족도는요? NPS는 어느 쪽으로든 움직이고 있나요?
코드를 더 많이 만드는 데 왜 이렇게 집착하는지 모르겠어요. 좋은 개발 관행은 다 어디로 갔죠? 아이러니하게도 그런 관행을 따르면 LLM도 더 효율적으로 일하거든요. 저라면 개발팀이 몇 년째 붙들고 있던 버그를 잡았다거나 장애가 거의 없었다는 얘기를 듣고 싶어요. 제겐 기능을 마구 찍어서 내보내는 것보다 그쪽이 훨씬 값져요.
공감합니다. 아주 강하게 공감하지만, 제가 "엔지니어링 팀"과 "제품 팀"이라고 부르는 두 쪽 사이에는 늘 긴장이 있었습니다. 엔지니어링 팀은 장기적인 플랫폼 안정성과 성능 등을 원합니다. 제품 팀은 새 기능을 빨리 내보내고 싶어 합니다. 물론 사업이 살아남으려면 두 가지 사고방식과 일하는 방식이 모두 필요합니다. 하지만 모든 경영진이 엔지니어링 팀의 관점으로 세상을 보지는 않습니다. 오히려 대부분은 반대쪽으로 기울어 있다고 생각하는데, 이해는 가지만 안타까운 일입니다. 또 제품 팀은 대체로 "비즈니스와 더 가깝기" 때문에 실제 의사결정권자에게 더 잘 보이는 경향이 있다고 봅니다.
이런 새 도구는 이 문제를 더 키울 뿐입니다.
이런 긴장 때문에 저는 스스로를 프로덕트 엔지니어라고 부릅니다. 기술 배경이 없는 프로덕트 매니저(말씀하신 "제품 팀")가 주도하는 팀은 기능 공장이 되어 결국 자기들이 쌓은 기술 부채에 빠져 허우적댑니다. 반대로 제 배꼽만 들여다보는 엔지니어링 매니저(말씀하신 "엔지니어링 팀")에게 힘이 너무 실리면 성급한 플랫폼화와 아름다운 아키텍처 다이어그램만 남고 사용자 요구는 채워지지 않습니다.
핵심은 컴퓨터가 인간의 필요를 채우려고 존재한다는 점을 이해하는 것입니다. 문제를 풀 때 코드, UI, 거쳐야 할 절차는 적을수록 좋고, 처음부터 끝까지 이어서 생각해야 합니다. 그렇게 할 수 있다면, 위원회가 만든 시스템 대부분에는 큰 희생 없이 개선할 수 있는 손쉬운 부분이 많습니다. 현실에서는 정치적 사정이나 운영상의 문제가 발목을 잡을 수 있지만, 엔지니어로서 성공적으로 일하는 길은 이것뿐이라고 굳게 믿습니다. AI 시대에는 이 점이 더 중요해질 겁니다.
저는 애자일 같은 것이 이제 예전보다 더 중요하다고 느껴요. 이제 그 역할은 고객을 나쁜 변경에서 지키고, 영향을 실제로 측정하는 전체 과정을 끝까지 따라가는 쪽이어야 해요. 어떤 부사장의 사심 프로젝트라는 이유로 제품에 10만 줄짜리 변경을 밀어 넣기가 너무 쉬워졌거든요.
플랫폼을 잘 만들어 두면 빠르게, 그러면서도 안전하게 실행할 수 있습니다.
저는 "돈과 데이터는 신성하다"는 원칙을 밀어붙입니다. 둘 중 하나라도 잃으면 누군가는 울게 되니까요. 플랫폼은 느리게도, 빠르게도 만듭니다. 거버넌스, 확장성 같은 것이 여기에 들어갑니다.
레퍼런스 API를 제공하고, 제품 팀이 원하는 건 뭐든 한 방에 만들어 보게 하세요. 빠르고 실험적으로 만들게 하되, 제약은 플랫폼이 강제하는 겁니다.
양쪽의 장점을 다 취하는 방식입니다(다시 백엔드 개발과 프런트엔드 개발로 돌아간 느낌이긴 하지만요).
정말 맞는 말인데, 탄탄한 플랫폼에 투자하려는 사람은 점점 줄고 다들 빠르지만 불안전하게 실행하는 쪽으로만 뛰어들려는 것 같아요. 그러면서 AI가 둘 다 확실히 해낼 수 있다고 우기는데, 실제로 써 보면 경험이 꽤 달라요.
적어도 한 번은 그 과정이 실시간으로 벌어지는 걸 봤어요. 보통은 플랫폼이 생기기까지 몇 년을 만드는 데 쓰는데, 그러고 나면 12~18개월 동안 새 기능 없이, 성과도 수치로 따지기 어렵고 어쩌면 아예 없을지도 모르는 곳에 투자할 의욕이 경영진에게 남아 있지 않아요. 그러다 "플랫폼 네이티브"인 신생 업체에 밀려나죠. 이 말은 사실 그쪽의 엔지니어링 실수가 아직 드러나지 않았다는 뜻이거나, 설령 처음에 제대로 짚었더라도 세상이 바뀌어서 한때 옳았던 해법이 이제는 실패작이 됐다는 뜻이에요. 그리고 이제는 "AI 네이티브"라는 것이 나와서 이 모든 걸 일거에 해결해 줄 거라고 하죠. 일종의 마법으로요. 그 마법을 진심으로 믿지 않으면 이런 회사를 이끌 수도 없고요.
“보통은 플랫폼이 생기기까지 몇 년을 만드는 데 쓰는데, 그러고 나면 12~18개월 동안 새 기능 없이, 성과도 수치로 따지기 어렵고 어쩌면 아예 없을지도 모르는 곳에 투자할 의욕이 경영진에게 남아 있지 않아요.” —> 이건 팀의 실패이고, 특히 그 팀에서 프로덕트 매니지먼트 일을 해야 했던 사람들의 실패예요.
저는 운이 좋은 것 같아요. 제품 팀이 탄력적인 시스템을 만드는 일에서 "제 편"이라고 느끼거든요. 나쁜 아키텍처가 파편화되고 마찰 많은 UX로 드러난다는 걸 이해하고 있어요.
새 기능을 요구하는 쪽은 고객 체크리스트의 항목을 하나라도 더 채우고 싶은 영업과 임원들이에요.
결국 월급은 그 체크리스트 항목이 걸린 계약에서 나옵니다. 허공에서 저절로 생기는 게 아니에요. 계약이 없으면 아키텍처가 아무리 견고하고 우아해도 소용없습니다.
저는 지난 2주 대부분을 AI가 제발 그 망할 코드 좀 적게 쓰게 만드는 데 썼어요. 예를 들어 데이터베이스 두 개 사이를 통째로 갈아탈 수 있다는 건 대단하죠. 그런데 AI가 일종의 에너지 소모 같은 개념을 갖추면 좋겠어요. 새 데이터베이스 접근 계층을 정의하는 2000줄을 쏟아내기 전에, 코드베이스에 이미 구현된 게 있는지 잠깐이라도 확인하고, 어떤 작업 하나 때문에 건드리면 안 되는 엉뚱한 코드를 할 수 있다는 이유만으로 수백 줄씩 다시 쓰지 말았으면 해요. 어떻게든 대충 커버할 것 같은 테스트를 쓰기가 아무리 쉬워졌다 해도 상관없어요. 몇 년 동안 현장에서 굴러온 코드만큼 검증된 새 코드는 없으니까요.
능력이 있다고 해서 꼭 써야 하는 건 아니에요.
저는 Knuth도 감동해서 눈물 흘릴 만큼 간결하고 아름다운 코드를 바라는 게 아니에요. 그저 기존 함수 수십 개에 매개변수를 세 개씩 덧붙이고 거의 아무 일도 안 하는 코드를 줄줄이 붙이지 말아 달라는 거예요. 제 프롬프트를 특정 방식으로 읽으면 제가 우연히 어렴풋이 암시한 것처럼 보이는 사용 사례를 처리한답시고요. 정작 제가 원한 건 그게 아니었으니까요.
전적으로 동의하지만, 우리가 바라는 바는 AI 기업의 이익과 상충할 거라고 생각해요.
맞아요. AI가 코드를 덜 쓰게 만들 방법이 있기는 해요. 하지만 토큰이 당연히 10배는 들죠. LLM을 심사자로 쓰고 자동 리뷰를 돌리든, 해법을 10개 쓰게 해서 1개만 남기든요. AI 기업이 이런 상황을 좋아하는 면도 있지만, 어쩌다 자기들에게 유리하게 굴러간 의도치 않은 결과인 면도 있어요.
좋은 아키텍처 감각을 훈련하면 노력 허용치가 높을 때 오히려 성급한 최적화가 생겨요. 동시에 그 최적화가 나중에 정말 쓸모가 생겨도 알아보거나 활용하지 못하죠. 노력 수준을 낮추면 합리적인 추상화는 건너뛰고, DRY는 하나도 지켜지지 않고, 분해 방식은 제정신이 아니에요.
주제나 줄 수 한도로 편안한 영역을 벗어난 프런티어 모델에서는 단순한 작업에 딱 맞는 수준을 맞추기가 거의 안 돼요. 그래도 그럴 가치가 있는지 그냥 결정해야 해요. 현실에서는 고품질 코드를 위해 끊임없이 감독하거나, 시스템 설계를 아주 잘 해서 코드 품질이 약점이 덜 되게 하거나 둘 중 하나예요.
올해 들어 여러 번 목격한 게 하나 있습니다. 코드량이 늘면 예전과 똑같은 문제가 생겨요. 다만 이제는 적은 인원으로 아주 빨리 터질 뿐입니다. 예전에는 몇 년 걸려서 터지던 문제가 MVP를 내놓기도 전에 나타나는데, 사람들은 빠르게 움직인다는 명분으로 전부 덮어 버립니다.
소프트웨어가 만들어지는 속도도, 망가지고 쓸모없다는 이유로 버려지는 속도도 역대 최고예요. 이 두 변화를 보정하고 나면, 개발자 한 명이 만들어 내는 수명이 몇 년 단위인 쓸 만한 소프트웨어(즉 장기적 가치가 실제로 있는 소프트웨어)의 양이 정말 그렇게 많이 달라졌는지 저는 전혀 확신이 안 서요.
HN 사람들은 소프트웨어의 품질을 과대평가한다고 생각합니다. 사람들이 늘 어쩔 수 없이 쓰는, 정말 형편없는 소프트웨어가 (아주) 길게 꼬리를 물고 있어요. 이런 소프트웨어가 형편없는 이유는 대개 물류 서류나 교육구 경비 관리 같은 양식을 작성하도록 돕는 백오피스 관리 소프트웨어이기 때문입니다. AI 네이티브 엔지니어링 팀은 이 긴 꼬리에서 극적인 개선을 만들 수 있어요. 그 소프트웨어를 운영하는 사람들이 무능하거나 손을 놓은 상태라서, AI가 평균 품질 쪽으로 끌어당겨 주기만 해도 크게 나아질 테니까요.
우리 직업에서 가장 불편한 진실 중 하나는, 소프트웨어가 얼마나 형편없든 그걸로 수십억 달러를 벌 수 있다는 점입니다. 바닥이라는 게 말 그대로 없어요.
예전에 겪은 일이 떠오르네요. 택배사가 세 번을 시도하고도 서명을 못 받아서, 배송 누락된 물건(값비싼 사진 프린터)을 발송 창고까지 직접 찾으러 간 적이 있어요.
어쨌든 트럭이 수십 대씩 오가는 거대한 산업용 창고 단지로 차를 몰고 가서 고객 서비스 사무실을 찾았어요.
“30분 걸립니다. 카페에서 기다리시길 권해요.”
“30분이요? 뭐가 30분이나 걸려요? 소포는 전부 여기 있는 거 아닌가요?”
“있죠. 그런데 시스템에서 소포 ID를 조회하는 데 최소 30분, 아마 33분은 걸려요.”
“33분이요!? 잠깐… 말하지 마세요, 제가 맞혀 볼게요. 몇 년에 걸쳐 조금씩 꾸준히 나빠졌죠? 걸리는 시간이 예측 가능하게 점점 늘어나고요, 맞죠?”
“네, 6개월 전에는 27분이었어요! 어떻게 아셨어요?”
“음… 업무에 꽤 발목을 잡지 않나요?”
“그럼요! 뭐든 한없이 오래 걸리고 배송은 전부 지연되고요, … [긴 푸념] …”
“그, 그러시겠네요. 왜 아무도 고치지 않았대요!? 한 줄이면 고치는 건데요!”
“예산이 없어서요!”
그곳은 수십억 달러 규모의 합병을 앞둔 그 나라 최대 물류 회사 중 하나였어요.
그 회사의 핵심 업무 소프트웨어는 기본 키 컬럼에도 데이터베이스 인덱스가 없었어요!
미친 일이죠.
사내 도구의 사용성은 아예 고려 대상이 아닙니다. 우선순위는 경영진이 정합니다. 매일 업무에서 그 도구를 실제로 써야 하는 말단 직원들의 피드백에는 하나같이 관심이 없고, 그 때문에 엄청난 비효율이 생겨도 마찬가지입니다.
그래서 Workforce 같은 회사가 상상할 수 있는 가장 끔찍한 소프트웨어를 팔아서 수십억 달러를 벌 수 있는 겁니다.
보통 그걸 "엔터프라이즈 소프트웨어"라고 부릅니다. 형편없는 이유는 대개 구매하고 예산을 대는 사람이 규정 준수, 보고, 가시성에만 신경 쓰고 정작 그 소프트웨어를 쓸 일은 전혀 없는 부사장급 임원이기 때문입니다.
이건 사실 HN에서 꽤 자주 나오는 주제입니다. 아니, 예전에는 그랬죠. 다른 많은 주제처럼 AI에 밀려 뒷전이 됐네요.
…그리고 이제는 AI 덕분에, 정작 자기들은 쓰지도 않는 관리자들이 원한다고 착각하는 온갖 헛소리 기능 과잉이 들어간 끔찍한 소프트웨어를 훨씬 더 많이 만들어 낼 수 있게 됐죠.
AI가 쓴 글도 비슷해요. AI는 평범함을 뛰어넘지는 못하지만, 형편없는 글이나 코드를 겨우 평범한 수준까지는 끌어올릴 수 있어요.
이런 종류의 콘텐츠는 하나같이 사용자에게 뭘 만들어 줬는지는 얘기하지 않고, 자기네 "출시" 지표(머지된 PR, 코드 줄 수 등)가 얼마나 하늘 높은 줄 모르고 치솟았는지만 얘기해요. 그래서 관심을 갖기가 엄청 힘들어요. 결국 전부 "저는 루프 위에 루프 위에 루프를 얹어서 코드를 엄청 쓰고 토큰도 엄청 쓰는 걸 만든 개발자입니다"로 요약되니까요.
그래도 이 글은 "머지는 5배 늘었는데 리버트 비율은 그대로"라고 적어 놨어요. 이건 적어도 제가 존중하기 시작할 만한 지표예요.
훌륭한 프로덕트 리더라면 누구나 말할 겁니다. 때로는 뭔가를 만들지 않는 것이 고객에게 실제로 좋다고요. 개발 주기가 느리면 결정에 시간을 들이고 조정할 여유가 생깁니다. 코드를 더 많이 내보내는 데 집착하면 사용자에게 오히려 나빠지고, 길게 보면 회사에도 해가 된다고 봅니다.
누구에게나 백로그가 있습니다. 그걸 한 달 만에 다 치우면 어떻게 될까요? 갑자기 무엇을 만들지에 대한 아이디어가 더 좋아질까요? 갑자기 직관적인 디자인이 늘어날까요? 사용자가 늘거나, 같은 사용자가 제품을 두 배로 쓰게 될까요? 대부분의 경우 답은 아닙니다.
AI는 필요할 때 실행할 속도를 줍니다. 하지만 무엇을 어떻게 만들지 아는 일은 여전히 병목으로 남을 겁니다.
이제 진짜 질문은 이거예요. "리버트 비율이 같은 이유가 프로세스가 여전히 같아서인가, 아니면 이제는 포워드 픽스를 더 자주 해서 리버트 비율이 심각도 높은 장애에서만 나오는 건가?"
저희는 주기적으로 "프로젝트 종료 후" 지표 점검을 하는 방식으로 합니다. 확인하는 건 다음과 같아요.
사용자가 새 기능을 (반복해서) 쓰고 있는가
고객 통화에서 그 기능과 관련해 어떤 감정이 나타나는가 (통화 녹취록으로 추출하지만, 이상적으로는 관련 엔지니어가 통화에 직접 참여)
저는 이 글이 재미있어요. 제대로 앞을 내다보는 "AI 네이티브" 엔지니어링 조직이 실제로 어떤 모습일지에 한참 못 미친다고 느끼거든요. 글쓴이는 이걸 일반적인 엔지니어링과 근본적으로 결별한 것처럼 내세우지만, 제 눈에는 그저 AI를 더 쓰는 평범한 엔지니어링일 뿐이에요. 저는 그걸 AI 네이티브라고 보지 않아요.
제가 생각하는 진짜 "AI 네이티브" 엔지니어링은, 사람이 코드 리뷰 같은 일을 어떻게 할 것인가라는 질문이 아예 의미 없는 방식이에요. 일반적인 소프트웨어 엔지니어링의 개념을 모두 명시적으로 내던지고 AI에게 맡기는 거죠. 사람의 일은 오직 AI가 물리적으로 할 수 없는 일을 하는 거예요. 그건 AI가 지금 할 수 있는 일과 필요한 수준 사이의 간극을 메우는 것과는 다른 얘기예요. AI가 해낸 일은 그 자체로 옳은 것으로 간주하도록 말 그대로 강제하고, 사람은 사람으로서 그걸 뒷받침하기만 하는 겁니다.
터무니없게 들린다면, 실제로 터무니없어서 그래요. 우리에게는 아직 그렇게 유능한 AI 시스템이 없어요. 앞으로도 없을지 모르고요. 하지만 그건 중요한 게 아니에요. 현실은, 기존 프로세스와 시스템 위에 AI를 얹는 것만으로 "AI 네이티브" 엔지니어링 조직을 만들려는 시도는 헛수고라는 거예요. AI의 역량이 가속적으로 계속 나아질 거라고 기대한다면 이런 임시방편은 무의미해요. AI가 완전히 인수할 수 있게 될 때까지 아예 AI를 무시하는 편이 낫겠죠. 그게 필연적인 목표니까요, 그렇지 않나요?
그게 가능해질 거라고 믿는다면, 제 짐작으로는 기존 사업을 운영하는 쪽이 아니라 소규모 스타트업이나 진짜 이단아들 사이에서 그 일이 벌어질 거예요. 기존 사업을 하는 사람들은 때가 왔을 때 모든 걸 거는 위험을 감수하기에는 너무 위험 회피적일 테니까요. 지하실에 틀어박힌 어떤 사람이 "제대로" AI를 활용해 진짜 "AI 네이티브" 엔지니어링 조직을 만들 가능성이 더 높아요. 그 사람은 잃을 게 별로 없으니까요.
참고로 이 글을 쓴 회사가 바로 그런 소규모 스타트업 중 하나라고 생각해요. 그건 그렇고, 그렇게 생각하는 사람이 당신만은 아니에요. 꽤 많은 VC와 펀드가 작고 새로운 회사만이 진짜 AI 네이티브가 될 잠재력이 있다고 봐요. 기존 사업은 사람 중심의 기존 프로세스를 유지하려는 조직 관성이 너무 커서, 새 회사만이 진정한 "확장 잠재력", 즉 인력 없이 AI로 규모를 키우는 일을 해낼 수 있다는 거죠.
다 맞는 말이지만 어느 정도는 말장난이라고 생각해요.
대부분의 엔지니어는 "평범한" 엔지니어링 조직에서 일하면서도 발밑이 움직이는 걸 느껴요. 그리고 회사들은 허를 찔리면 시장에서 밀려날 거라고 믿기 때문에, 매출을 끌어올리지는 못하더라도 최소한 보조를 맞출 수 있는 방식으로 AI를 도입하려고 다들 애쓰고 있어요.
경제적 유인에 영향을 받지 않는 입장이라면 이 과도기 상태에 계속 관심을 두지 않아도 되겠지만, 대부분의 사람은 그렇지 않아요.