레거시 이관은 보통 많은 인력이 필요한 작업이다. 그런 큰 이관 작업을 주니어 개발자 한 명과 AI에게 맡긴다는 이야기가 개발자들에게 좋은 신호로만 들리지는 않는다. Cisco가 27세 엔지니어에게 무제한 AI 토큰을 지원하며 레거시 코드 리팩터링을 맡겼다. 눈길을 끄는 숫자는 98%다. 다만 이 숫자는 달성률이 아니다. 2026년 10월 30일 Fortune 기사에서 기자가 서술한 ‘24개월 안에 레거시 코드 98% 리팩터링’이라는 최종 목표다. 함께 등장하는 4주는 전체 작업의 완료 기한이 아니라 접근법을 증명하기 위한 기간이다.[1]
이 소식에서 구분해야 할 것은 지원 결정, 목표, 검증된 결과다. 토큰 사용의 제약을 풀었다는 사실만으로 대규모 코드 전환의 품질이나 경제성이 입증되지는 않는다. 원문으로 확인할 수 있는 사실과 개발 조직이 참고할 점을 나눠 살펴보자.
핵심 요약
98%는 Fortune 기자가 서술한 24개월 목표이며, 4주는 접근법 증명 기간이다. 대상 제품과 코드베이스, 98%의 산정 기준, 사용 모델과 토큰 비용, 실제 검증 방법, 4주 결과와 이후 진행 성과는 검토한 자료에 공개돼 있지 않다.[1] CXOTalk의 95%와 70%는 별도 인터뷰의 회사 목표로, Paddy의 실험과 같은 프로그램인지 알 수 없다.[2] 실무적으로 주목할 지점은 코드 생성 이후의 검증·테스트·리뷰다.
27세 엔지니어에게 무엇을 맡겼나?
레거시 코드를 소규모 팀으로 다시 작성할 수 있다는 제안에, 경영진이 토큰 지원과 실험 기회를 준 것이다. Fortune 보도에 따르면 Cisco 사장 겸 최고제품책임자 Jeetu Patel은 샌프란시스코 사무실에서 Padmanabhan Krishnamurthy, 별칭 Paddy와 대화하다 이 제안을 접했다. Patel은 이후 소규모 라운드테이블 디너에서 이 일화를 전했다. Paddy는 두 사람으로 구성된 팀으로 작업할 수 있다고 봤고, Patel은 리팩터링을 위해 무제한 토큰을 제공했다고 말했다.[1]
Paddy는 일반적인 신입 개발자와는 배경이 다르다. 실시간 번역 스타트업 EzDubs의 공동창업자로, 인수를 통해 Cisco에 합류했다. Cisco 공식 발표상 EzDubs 인수 완료일은 2025년 11월 25일이다. 따라서 이 사례를 ‘경험 없는 주니어에게 회사 전체 코드를 맡겼다’고 단순화하면 창업·개발 경험이라는 맥락이 빠진다.[1][3]
그렇다고 전직 창업자라는 이력이 결과를 보증하는 것도 아니다. 기사에서 확인되는 것은 제안과 지원, 증명 기간과 장기 목표다. 이 정보만으로 두 사람이 Cisco의 모든 제품을 교체할 수 있다거나, 기존 개발 조직을 대체할 수 있다고 결론 내릴 수는 없다.
98%와 4주를 어떻게 읽어야 하나?
98%는 장기 목표의 크기이고, 4주는 그 목표를 향한 접근법을 증명하는 기간이다. Fortune 기자는 24개월 내 98% 리팩터링을 최종 목표로 서술하지만, 어떤 측정 단위로 계산하는지는 설명하지 않는다. 코드 줄 수인지, 저장소나 서비스 수인지, 기능 범위인지도 확인한 원문으로는 알 수 없다.[1]
어떤 제품과 코드베이스가 대상인지도 확인되지 않는다. ‘Cisco의 레거시 코드’라는 표현을 곧바로 Cisco 전체 소스코드와 같은 뜻으로 읽어서는 안 된다. 또한 코드 내부 구조를 바꾸는 리팩터링과 시스템을 다시 만드는 재작성은 검토해야 할 변경 범위가 다를 수 있다. 이 사례에서 각각의 경계를 어떻게 정했는지도 공개된 설명만으로는 분명하지 않다.
| 구분 | Fortune 보도 [1] | CXOTalk 인터뷰 [2] |
|---|---|---|
| 레거시 목표 | 24개월 내 98% 리팩터링 | 2년 내 95% 제거·리팩터링이라는 도전적 목표 |
| 별도 수치 | 4주 동안 접근법 증명 | 인터뷰 기준 다음 해 말까지 제품의 70%를 AI로 전부 작성한다는 목표 |
| 해석 한계 | 98% 달성이나 4주 완료를 뜻하지 않음 | Fortune 실험과 같은 프로그램인지 확인되지 않음 |
Paddy가 어떤 모델을 쓰는지, 토큰을 얼마나 소비하는지, 비용이 얼마인지도 확인되지 않는다. 실제로 어떤 테스트와 승인 절차를 적용했는지, 4주 동안 무엇을 입증했는지, 이후 어느 범위까지 진행했는지도 확인한 자료에 없다. 따라서 아직 성공이나 실패를 판단할 근거는 부족하다.[1]
CXOTalk의 95%와 70%는 같은 이야기인가?
같은 프로그램이라고 확인할 수 없으므로 별도 인터뷰의 회사 목표로 읽어야 한다. Patel은 CXOTalk에서 2년 내 레거시 코드 95%를 제거하고 리팩터링하는 것을 도전적 목표로 설명했다. Fortune의 98%와 숫자가 다르지만, 대상과 산정 기준이 연결돼 있지 않아 목표가 수정됐다고 단정할 근거도 없다.[2]
70%는 측정 대상부터 다르다. 발언은 ‘제품의 70%를 AI로 100% 작성한다’는 목표이지, ‘전체 코드의 70%를 AI가 작성한다’는 뜻이 아니다. 제품별 규모가 다른 상황에서 두 표현을 바꾸어 쓰면 의미가 달라진다. 이 역시 인터뷰에서 제시한 목표이며, 달성 결과를 발표한 것은 아니다.[2]
무제한 토큰이면 비용 관리도 사라지나?
아니다. 특정 실험의 무제한 지원과 조직 전체의 예산 운영은 구분해야 한다. CXOTalk에서 Patel은 초기 4~6개월에는 AI 사용에 익숙해지도록 토큰 비용을 걱정하지 말라고 했으며, 사용 증가 이후에는 관리 장치를 마련하려 했다고 설명했다.[2]
이어 관리자별 토큰 예산과 tokenomics 애플리케이션을 통한 사용량·이상 소비 파악, 성과 없이 과도하게 소비하는 에이전트를 멈추는 킬스위치 구상을 설명했다. 이는 예산 관리 체계로 옮겨가는 전환 계획의 맥락이다. 전사 적용을 마쳤다는 뜻은 아니다. 이 설명만으로 Paddy 개인의 지원 조건이나 실제 지출도 알 수 없다.[2]
독자가 참고할 기준은 토큰의 양보다 검토를 통과한 변경에 들어간 비용이다. 생성 비용이 낮아져도 검토와 수정이 길어지면 전체 작업은 저렴해지지 않을 수 있다. 실무에서는 토큰 사용량뿐 아니라 사람의 리뷰 시간, 재작업, 배포 후 결함도 함께 기록하는 편이 좋다.
코드가 빨리 나오면 다음 병목은 어디인가?
검증·테스트·리뷰로 이동할 수 있으며, 별도 PubHub 사례가 이를 구체적으로 보여 준다. 2026년 10월 28일 게시된 Cisco 공식 글은 문서 배포 플랫폼 PubHub를 다시 만드는 과정에서 코드가 사람의 검토 속도보다 빠르게 쌓였다고 설명한다. 이 프로젝트는 Paddy 건과 다른 프로젝트이며, 그 성과를 98% 목표의 실적으로 합칠 수 없다.[4]
PubHub 팀은 15개가 넘는 저장소에 걸친 기존 구조를 AI로 문서화하고 전문가가 검토했다고 밝혔다. 생성 코드에는 사람의 리뷰를 유지하면서, 로컬 및 PR 리뷰 에이전트로 검토를 보조했다. 테스트에서는 운영 버전과 새 버전이 만든 수만 페이지를 비교하고, 브라우저 기반 업무 흐름을 자동 점검했다고 설명한다. 최종 승인 책임은 사람에게 남겼다.[4]
이 사례를 특정 모델만 고르면 전환을 마칠 수 있다는 뜻으로 읽어서는 안 된다. 코드를 빨리 만드는 단계와 기존 동작을 보존했음을 입증하는 단계는 다르다는 점이다. Patel 역시 CXOTalk에서 코드 생성 이후 리뷰가 병목이 될 수 있으며, 평가 체계와 경계 조건 테스트의 품질이 중요해진다고 말했다.[2]
레거시 현대화 실무 체크리스트: 무엇부터 확인할까?
범위와 합격 기준을 먼저 정하고, 작은 변경 단위로 검증해야 한다. 아래는 편집부의 일반적인 실무 제안이다. Paddy의 실험이 실제로 실행한 절차를 설명하는 것이 아니다.
- 범위·분모·동작 동등성: 대상 저장소와 제품, 제외 영역을 적고 진행률의 분모를 고정한다. 기존과 같아야 할 출력·오류 처리·성능과 의도적으로 바꿀 동작을 구분한다.
- 기존 동작 기준선과 테스트: 정상 입력뿐 아니라 빈 값, 경계값, 외부 서비스 장애, 재시도 상황을 확보한다. 기존 결과를 기준선으로 삼아 회귀·경계·장애 테스트를 수행한다.
- 작은 PR과 소유자 승인: 검토 가능한 크기로 나누고 변경 이유와 영향 범위를 남긴다. AI의 자체 점검으로 승인을 대신하지 않고 코드 소유자가 판단한다.
- 보안 점검: 권한 확대, 시크릿 노출, 민감정보 전송, 새 의존성의 취약점과 라이선스를 확인한다. 에이전트의 접근 권한도 작업에 필요한 범위로 제한한다.
- 단계 배포와 롤백: 제한된 환경과 트래픽부터 적용하고 오류·지연·데이터 변화를 관찰한다. 코드뿐 아니라 데이터 변경도 되돌릴 수 있는지 확인한다.
- 토큰 및 리뷰 비용: 모델별 사용량과 비용, 리뷰 시간, 수정 횟수를 함께 기록한다. 생성된 코드량보다 승인·배포된 변경의 비용과 결함을 본다.
- 주니어-시니어 페어링: 주니어의 도구 활용과 새로운 접근을 시니어의 도메인 지식·장애 경험에 연결한다. 설계 이유와 승인 책임도 함께 학습하게 한다.
주니어 개발자는 덜 필요해지는가?
Patel의 입장은 반대다. 그는 CXOTalk에서 AI가 초급 업무를 수행한다고 초기 경력 직원이 필요 없어지는 것은 아니라며, Cisco가 초기 경력 채용을 가속하고 있다고 말했다. 경험자가 쌓은 패턴 인식과 초기 경력자의 AI 친화적 접근을 결합하는 데 가치를 둔 것이다.[2]
따라서 이 소식을 ‘27세 한 명의 생산성’으로만 읽으면 조직 운영의 핵심이 빠진다. 새로운 접근을 제안할 기회를 주되, 기존 제품의 제약을 아는 사람과 검증 책임을 연결해야 한다. Cisco의 98%는 아직 확인된 성과가 아니라 목표다. 앞으로 판단에 필요한 것은 더 큰 생성량이 아니라 대상 범위, 동작 보존의 증거, 승인·배포 결과, 그리고 그 과정의 총비용이다.