텐센트 프로덕션 시스템 SiriusDeliver는 현재 매달 18,240건의 데이터 웨어하우스 작업을 자율 AI 에이전트로 처리하고 있다. 성공률 87.2%, 작업당 소요 시간 228분 → 23분, 엔지니어 투입 시간 95분 → 11분. 리서치 논문이 아니다. 프로덕션 수치다. Agentic SDLC를 분석한 dev.to의 심층 리포트가 이 데이터를 공개했을 때, 나는 이걸 '가능성'이 아니라 '현재'로 읽었다.
같은 시기, 다른 팀 리드가 자신의 백로그 전체를 5명의 AI 에이전트에게 넘기는 실험을 진행했다. 실제 레포, 실제 CI, 실제 머지 버튼. 일주일 후 결과는 이렇다. PR 23개 오픈, 14개 머지, 3개 48시간 내 리버트, 1건 스테이징 테이블 삭제 직전 아찔한 근접 사고, 6개는 아직 열려 있다. 재앙도 아니고 기적도 아니다. 하지만 이 숫자 안에 팀 리빌딩의 핵심 단서가 다 들어 있다.
무엇이 됐고, 왜 됐나
머지된 14개 PR을 보면 패턴이 선명하다. 명확한 스키마가 있는 CRUD 엔드포인트, 스펙이 문서화된 데이터 마이그레이션, 기존 코드의 테스트 커버리지 추가, 디펜던시 범프, 30개 파일에 걸친 기계적 리팩터. 공통점은 하나다. 어려운 부분이 '결정'이 아니라 '타이핑'인 작업들이었다.
스펙이 명확하면 에이전트는 인간 팀원보다 빠르고, 27번째 파일에서 오타를 내지 않는다. 테스트 에이전트는 6개월째 "나중에 하자"로 미뤄왔던 테스트를 그냥 다 써버렸다. 에고도 없고, 더 좋은 아이디어를 피칭하지도 않는다. 그냥 쓴다.
무엇이 깨졌고, 왜 깨졌나
리버트된 3개와 아찔한 근접 사고는 구조적으로 같은 모양이었다. 마이그레이션 클린업 에이전트는 특정 컬럼이 nullable인 이유를 몰랐다. 야간 배치잡이 그 null을 의존하고 있었다. 에이전트가 작성한 모든 라인은 개별적으로 옳았다. 결정이 틀렸을 뿐이고, diff에는 그게 전혀 드러나지 않았다.
더 치명적인 패턴은 이거다. 코드와 테스트를 같은 에이전트가 썼을 때, 둘은 서로에게 동의하지 현실에 동의하지 않는다. 에이전트가 자기 잘못된 멘탈 모델에 맞춰 테스트를 쓰면, 테스트는 통과한다. 이건 모델 품질 문제가 아니다. 구조 문제다. 그래서 코드 에이전트와 테스트 에이전트는 반드시 분리해야 한다.
진짜 병목은 어디로 이동했나
실험 후 팀 리드가 내린 결론은 예상 밖이었다. "나는 일주일치 일을 절약한 게 아니라, 이동시켰다." 병목이 '코드 작성'에서 두 곳으로 옮겨갔다.
첫 번째는 스펙이다. 스톨된 6개 PR은 에이전트가 멍청해서 멈춘 게 아니다. 티켓이 사람이라면 문맥으로 해석했을 한 문장짜리였기 때문이다. 저명세 작업은 에이전트가 잘못 처리하지 않는다. 자신 있게 틀리게 처리한다. 이게 더 나쁘다.
두 번째는 리뷰다. PR 23개를 읽는 건 물리적으로 많다. 더 문제는 에이전트 코드는 문법이 아니라 결정 안에 버그가 숨어있다는 것이다. 사람의 diff에는 의도가 담겨 있다. 에이전트의 diff에는 출력만 담겨 있다. 라인당 리뷰 피로도가 인간 코드보다 높다.
Agentic SDLC 연구는 이걸 Verification Tax(검증 세금)라고 이름 붙였다. 에이전트는 10배 빠르게 코드를 생성할 수 있다. 하지만 그 코드가 8배 더 많은 리뷰 시간을 요구하고, 통합 실패를 5배 더 많이 만들고, 기술 부채를 3배 쌓는다면 처리량 이득은 증발한다. 생성 속도만 측정하면 안 된다. 파이프라인 전체를 측정해야 한다.
팀 리드가 지금 설계해야 할 것
이 세 가지 데이터 포인트(텐센트 수치, 5에이전트 실험, Agentic SDLC 프레임워크)를 합치면 팀 리빌딩의 기준이 나온다. 에이전트 도입 후 팀 구조를 어떻게 재설계할지, 구체적으로 정리하면 이렇다.
① 에이전트 소유권 영역을 명문화하라. 에이전트가 잘하는 건 정해져 있다. 스펙이 문서화된 마이그레이션, 테스트 백필, 기계적 리팩터, 디펜던시 관리. '지루한 80%'다. 이 영역을 명시적으로 에이전트 레인으로 선언하라. 판단이 필요한 작업이 그 레인으로 흘러들어가는 순간, 자신 있는 오류가 생산된다.
② 스펙 작성을 팀의 1등 업무로 올려라. 지금까지 티켓 품질은 '개발 속도'에 영향을 줬다. 에이전트 시대에는 '오류 발생률'에 직결된다. 저명세 티켓은 에이전트에게 자신감 있게 틀릴 권한을 주는 것과 같다. 스펙 템플릿을 만들고, 수락 기준을 명시하고, 에이전트에게 넘기기 전 스펙 게이트를 두어라.
③ 코드와 테스트는 절대 같은 에이전트에게 맡기지 마라. 이건 협상 불가다. 에이전트 파이프라인을 설계할 때 구현 에이전트와 테스트 에이전트를 분리하는 건 선택이 아니라 품질 보장의 최소 조건이다. Agentic SDLC 연구가 소개한 구글/MIT/스탠퍼드의 SMART 시스템도 같은 이유로 서브 에이전트를 역할별로 분리한다.
④ 리뷰어를 '블래스트 레디우스'로 재정의하라. 에이전트 코드 리뷰는 문법 검토가 아니다. "이 변경이 볼 수 없는 영향 반경을 에이전트가 얼마나 이해하고 있는가"를 판단하는 작업이다. auth 변경이 퍼미션 체크에 미치는 영향, 마이그레이션이 야간 배치에 미치는 영향 같은 것들. 이걸 볼 수 있는 사람이 리뷰해야 한다. 그 사람이 없으면 머지하지 않는다.
⑤ PQC(Production-Qualified Change)를 팀 생산성 지표로 쓰라. PR 수, 커밋 수, 코드 라인 수는 에이전트 시대에 의미를 잃는다. 에이전트가 하루에 PR 50개를 열 수 있다. 의미 있는 숫자는 하나다. 리뷰 통과, 통합 테스트 통과, 보안 스캔 통과, 배포 후 인시던트 없음. 이 네 개를 다 넘은 변경의 수. 이걸 달러당, 리뷰어 시간당으로 추적하기 시작하면 팀의 진짜 처리량이 보인다.
개발자 역할이 실제로 어떻게 바뀌나
'타이핑 코딩은 끝났다'는 마이크로소프트 디스팅귀시드 엔지니어의 발언은 자극적이지만, 반은 맞고 반은 오해를 부른다. 코딩이 없어지는 게 아니다. 코딩의 어려운 부분이 비로소 드러나는 것이다.
dev.to의 분석이 정확하게 짚은 것처럼, AI는 구현 비용을 낮춘다. 구현이 싸지면 가치는 판단으로 이동한다. "이걸 만들어야 하나?", "이 로직은 어디에 있어야 하나?", "무엇이 깨질 수 있나?", "이게 6개월 후에도 말이 되나?" 이 질문들에 답할 수 있는 사람이 필요하다. AI가 그 답이 좋은지 나쁜지를 판단하려면, 사람이 먼저 판단의 기준을 갖고 있어야 한다.
그래서 아이러니하게도, 에이전트 시대에 시스템 기초는 더 중요해진다. N+1 쿼리, 레이스 컨디션, 퍼미션 누수, 레이트 리미팅 부재. AI는 문법적으로 완벽하고 구조적으로 위험한 코드를 아무 표정 없이 생성한다. 이걸 캐치하려면 프레임워크 지식이 아니라 시스템이 어떻게 작동하는지를 알아야 한다.
팀 리빌딩 관점에서 이건 채용 기준의 변화를 의미한다. 빠르게 타이핑하는 사람보다, 스펙을 정밀하게 쓸 수 있는 사람, 에이전트가 못 보는 블래스트 레디우스를 볼 수 있는 사람, AI 생성 코드를 주니어 개발자 PR처럼 꼼꼼하게 검토할 수 있는 사람이 팀에 필요하다.
정직한 결론
5에이전트 실험을 한 팀 리드의 마지막 문장이 이 모든 걸 압축한다. "AI는 일처럼 느껴지던 부분을 지웠고, 실제 일인 부분만 남겼다. 이게 위협이냐 선물이냐는 당신이 타이핑에서 가치를 만들었냐, 결정에서 가치를 만들었냐에 달려 있다."
팀 리드로서 내가 지금 설계해야 할 건 코드가 아니다. 에이전트가 안전하게 달릴 수 있는 레인, 사람이 집중해야 할 게이트, 그리고 그 두 개를 연결하는 스펙의 품질이다. 에이전트는 도구가 맞다. 하지만 그 도구를 팀 구조 안에 제대로 심는 건, 여전히 사람의 설계 문제다.