사람이 코드를 안 쓰는 팀 — 3명이 AI로 소프트웨어를 출하하는 법

보안 소프트웨어 기업 StrongDM에는 엔지니어 한 명당 하루 1,000달러어치 AI 토큰을 태우는 팀이 있어요. 단 3명. 그런데 이 팀에는 두 개의 금지 규칙이 있습니다.

"사람이 코드를 쓰지 않는다."
"사람이 코드를 리뷰하지 않는다."

처음 들으면 무책임한 슬로건처럼 들려요. 그런데 이게 농담이 아니라 실제로 프로덕션 소프트웨어를 출하하고 있는 팀의 운영 규칙이라면, 얘기가 달라지죠. Wharton의 Ethan Mollick 교수는 이 "Software Factory"를 두고, 일하는 방식 자체가 바뀌는 초기 신호라고 불러요. 오늘 글은 "AI가 빨라지고 있다"는 뻔한 결론이 아니라, 그 변화 속도를 내 업무에 어떻게 번역해 넣을 것인가에 대한 거예요. oneusefulthing

먼저, 이 흥분을 한 번 식히고 가요

Mollick의 주장은 단순합니다. AI 성능 개선이 지수적(exponential)이라는 거예요. GPQA(대학원 수준 Q&A), GDPval(실무 전문가 대비 AI 성능), Humanity's Last Exam, Pencil Puzzle Bench — 성격이 전혀 다른 네 개 벤치마크가 모두 지수 곡선을 그리고 있고, METR의 "Long Tasks" 평가에서는 AI가 자율로 처리하는 작업 시간이 기하급수적으로 늘어나고 있어요. oneusefulthing +1

여기서 많은 글이 멈춰요. "거봐, 다 바뀐다." 하지만 정직하게 짚을 게 있어요. 일부 분석가는 같은 차트를 보고 이건 지수 곡선이 아니라 로지스틱 S-커브라고 반박합니다. 100점 만점 벤치마크에 지수 곡선을 억지로 피팅하면 언젠가 100%를 뚫고 올라가는 비현실적 예측이 되니까요. 끝없이 가팔라지는 게 아니라, 어느 지점에서 완만해진다는 거죠. splained.substack

그런데 실무자에게는 이 논쟁이 사실 중요하지 않아요. 지수든 S-커브든, 향후 몇 년간 "방향은 위"라는 데는 양쪽 다 동의하거든요. 차이는 곡선의 형태일 뿐, 지금 당장 무언가 시도해봐야 한다는 결론은 똑같습니다. 그래서 차트 논쟁 대신, 이미 곡선을 타고 있는 현장을 보는 게 훨씬 빠릅니다.

Software Factory가 진짜 증명한 것

다시 StrongDM으로 돌아와요. 3명 팀, AI 에이전트가 코드 작성·테스트·배포를 전부 담당, 사람은 코드를 쓰지도 리뷰하지도 않음, 엔지니어 1인당 하루 1,000달러 이상의 토큰 소비. 이 사례에서 사람들이 보통 잘못 가져가는 교훈은 "이제 개발자 3명이면 된다"예요. 그건 핵심이 아니에요. oneusefulthing

진짜 교훈은 사람의 역할이 '실행'에서 '검수 규격 설계'로 이동했다는 거예요. 사람이 코드를 안 본다는 건 검증을 포기했다는 뜻이 아니라, 검증을 테스트·계약·자동 게이트로 옮겼다는 뜻이거든요. 사람은 "무엇이 맞는지"를 정의하고, AI가 "그걸 어떻게 만들지"를 책임지는 분업이죠. 이게 Anthropic의 Dario Amodei가 "엔지니어들이 이제 직접 코드를 거의 쓰지 않는다"고 말한 것과, 같은 변화의 두 얼굴이에요. oneusefulthing

그리고 한 가지 더. StrongDM은 이걸 수십 년이 아니라 수 주 만에 실험으로 세웠어요. 과거 기술 혁명이 조직에 스며드는 데 걸린 시간과 비교하면, 이게 Mollick이 말하는 "변화 속도"의 실체입니다. 표로 보면 감이 와요.

	이전 기술 혁명	지금	그래서 나는?
개선 속도	무어의 법칙: 2년마다 2배	AI 벤치마크: 연간 10배 이상metr	준비할 시간이 짧다 — 분기 단위로 다시 본다
대체 단위	직업 단위 (1950년 이후 사라진 직업: 엘리베이터 오퍼레이터 1개)oneusefulthing	"작업 단위"로 재편 — 코딩·리서치·콘텐츠technologyreview	'내 직업'이 아니라 '내 작업'을 쪼개 점검
조직 실험	수십 년에 걸쳐 점진 적용	Software Factory처럼 수 주 만에 급진 실험oneusefulthing	완벽한 도입보다 작은 실험을 먼저
자기개선	기계가 기계를 만들되 설계는 인간	AI가 다음 세대 AI를 직접 개선 (RSI)oneusefulthing	릴리즈 노트에 안테나를 세운다

마지막 줄의 RSI(재귀적 자기개선)는 아직 가장 추상적인 항목이에요. 다만 빈말은 아닌 게, OpenAI는 최신 모델을 두고 "자기 자신을 만드는 데 기여한 최초의 모델"이라고 발표했고, 구글 딥마인드의 Demis Hassabis도 주요 연구소들이 이 피드백 루프를 닫으려 적극 작업 중이라고 확인했어요. 이 루프가 실제로 닫히는 순간, 위 표의 '개선 속도'가 한 칸 더 올라갑니다. oneusefulthing

내 업무로 번역하기 — 무엇을 넘길 수 있나

"그래서 나는 뭘 해야 하나"가 이 글의 본론이에요. StrongDM을 흉내 내 "사람이 코드 안 본다"를 따라 할 필요는 전혀 없어요. 대신 같은 원리를 작은 단위로 적용하면 됩니다. 핵심 판별 질문은 딱 하나예요.

이 작업을 "프롬프트 → 결과물 → 검토"의 3단계로 쪼갤 수 있는가?

쪼개진다면 에이전트 후보예요. 그리고 위에서 본 교훈대로, 여기서 진짜 일은 '검토' 단계의 기준을 미리 글로 적어두는 것입니다. "무엇이 합격인가"를 정의하지 않은 채 AI에 넘기면, 결과물을 일일이 다시 손보느라 오히려 느려져요. 합격 기준을 먼저 적고, 그 기준에 맞으면 통과시키세요. 이게 StrongDM이 "리뷰를 안 한다"고 말할 수 있는 비결의 축소판이에요. oneusefulthing

이번 주에 돌려볼 AI-only 스프린트

가장 빠른 학습법은 작게라도 직접 굴려보는 거예요. 팀이든 혼자든 1~2주짜리 "AI-only 스프린트"를 한 번 설계해보세요. 코딩일 필요 없어요 — 리서치, 보고서 초안, 디자인 시안, 어떤 영역이든 됩니다. oneusefulthing

1. 대상 작업 1개를 고른다
   위의 판별 질문("프롬프트→결과물→검토로 쪼개지는가")을 통과하는, 반복적이고 정의가 비교적 명확한 작업 하나만 고르세요. 욕심내지 마세요.
2. 합격 기준을 먼저 글로 적는다
   "이 결과물이 합격이려면 갖춰야 할 조건"을 3~5줄로 적으세요. 이게 당신의 '리뷰 게이트'예요. 코드라면 테스트, 글이라면 체크리스트가 그 역할을 합니다.
3. 그 작업만큼은 직접 손대지 않는다
   스프린트 기간 동안 해당 작업은 오직 에이전트에게만 맡기세요. 직접 고치고 싶은 충동이 들 때마다, 그건 프롬프트나 합격 기준을 보강하라는 신호로 받아들이세요.
4. 토큰 비용과 시간을 기록한다
   StrongDM이 1인당 하루 1,000달러를 쓰면서도 성립하는 이유는, 그게 사람 시간보다 싸기 때문이에요. 당신도 "얼마 써서 무엇을 절약했나"를 숫자로 남기면 다음 의사결정이 쉬워집니다.
5. 분기마다 '변화 속도'를 다시 잰다
   Mollick의 진짜 메시지는 특정 기술이 아니라 속도예요. METR Time Horizons, GPQA 같은 지표와 주요 기업의 AI 채택·모델 릴리즈 발표를 분기에 한 번 훑는 루틴을 만드세요. 한 번 통과 못 한 작업도 다음 분기엔 통과할 수 있어요. metr

이 다섯 단계의 묘미는, 곡선이 지수든 S-커브든 상관없이 당신이 이기는 쪽에 선다는 거예요. AI가 더 좋아지면 당신의 스프린트는 더 쉬워지고, 덜 좋아지면 당신은 이미 한계선을 데이터로 알고 있죠. 어느 쪽이든 추측이 아니라 경험이 남아요.

더 깊이 파고 싶다면