Cisco AI 코드 재작성, 무제한 토큰 뒤에 98% 목표를 내걸다

Cisco가 27세 엔지니어에게 무제한 AI 토큰을 제공하고 24개월 안에 레거시 코드의 98%를 재작성하도록 했다는 보도가 나왔다. Cisco AI 코드 재작성은 이례적으로 광범위한 목표와 소규모로 제안된 팀을 결합한다. 그 의미는 Cisco가 무엇을 바꾸려는지, 그리고 그 변경 사항이 제대로 작동함을 어떻게 입증할지에 달려 있다.

Tom’s Hardware가 Fortune의 보도를 인용한 내용에 따르면, 사장 겸 최고제품책임자 Jeetu Patel은 샌프란시스코에서의 대화 이후 전 스타트업 창업자 Padmanabhan Krishnamurthy를 지원했다. 이 과제에는 초기 4주간의 검증 기간이 포함된 것으로 전해진다. 이러한 세부 사항은 독립적으로 검증된 현대화 성과라기보다 실험과 목표를 보여준다.

핵심 긴장은 제한 없는 코드 생성과 책임 있는 소프트웨어 제공 사이에 있다. Amazon은 이미 AI 지원 애플리케이션 업그레이드를 설명하며 유용한 비교 사례를 제공했다. Cisco의 보도된 목표는 변경 생성이 쉬워질 때 소규모 엔지니어링 팀이 얼마나 많은 조직적 책임을 감당할 수 있는지라는 더 넓은 질문을 제기한다.

Cisco AI 코드 재작성은 완료된 마이그레이션이 아니라 목표에서 시작한다

보도된 과제는 경영진의 지원을 보여주지만, Cisco가 소프트웨어를 현대화했다는 사실을 입증하지는 않는다.

Tom’s Hardware의 레거시 코드 과제 보도는 Paddy로 알려진 Krishnamurthy를 제안의 주도 엔지니어로 지목한다. 그는 2인 팀을 제안한 것으로 알려졌다. Patel은 지시를 받고 응답을 생성할 때 AI 모델이 처리하는 텍스트 단위인 토큰을 제한 없이 제공하는 등 이를 지원했다.

보도에 따르면 Krishnamurthy는 이전에 Patel보다 조직상 다섯 단계 아래에서 근무했다. 이 설명은 프로젝트를 도구의 변화만큼이나 책임의 변화로 위치시킨다. 전직 창업자는 기존 엔지니어링 가정에 도전할 여지를 받게 된다.

그 연결고리에는 독립적으로 검증 가능한 인수 이력이 있다. Cisco의 EzDubs 인수 공지에 따르면 거래는 2025년 11월 25일에 완료됐다. Cisco는 EzDubs를 실시간 음성 번역을 전문으로 하는 AI 소프트웨어 기업으로 설명했다. 제시된 인수 근거에는 협업 엔지니어링 인재 확장이 포함됐다.

이 이력은 인수된 스타트업이 Cisco에 합류했다는 설명을 뒷받침한다. 그러나 재작성 제안이나 그 실현 가능성을 독립적으로 검증하지는 않는다. 인수 발표는 Cisco의 레거시 소프트웨어를 전환하기 위한 공개 계획이 아니라 협업 기능에 관한 내용이다.

보도된 과제의 표현도 신중하게 다룰 필요가 있다. 리팩터링은 외부에서 관찰 가능한 동작을 유지하면서 소프트웨어의 내부 구조를 바꾸는 것을 뜻한다. 재작성은 구현을 교체하는 일을 포함할 수 있으며, 서로 다른 설계 선택과 호환성 위험을 초래할 가능성이 있다.

이 용어들은 겹치는 작업을 설명할 수 있지만, 진척도를 측정하는 방식으로 서로 바꿔 쓸 수는 없다. 자동화된 내부 정리는 고객이 의존하는 구성 요소를 교체하는 일과 크게 다르다. 현대화 프로그램은 각 변경이 어느 범주에 속하는지 식별해야 한다.

공개 보도는 98% 수치의 근거가 되는 상세 목록을 제공하지 않는다. 또한 완료가 생성된 변경 사항, 승인된 변경 사항, 프로덕션 배포 또는 기존 구현의 폐기를 의미하는지도 설명하지 않는다. 이러한 정의가 없으면 해당 비율은 운영 범위보다 목표를 더 분명하게 전달한다.

일정에도 같은 주의가 적용된다. 2026년 10월 30일에 게시된 보도는 프로젝트 시계가 그날 시작됐음을 입증하지 않는다. 독자는 게시일만으로 정확한 완료 날짜를 계산하지 않아야 한다.

따라서 유용한 출발점은 제한적이다. Cisco의 사장은 명확한 핵심 목표를 가진 공격적인 엔지니어링 실험을 승인한 것으로 보도됐다. 그 실험이 반복 가능한 현대화 프로그램이 될지는 별개의 문제로 남아 있다.

무제한 토큰은 검토와 책임의 부담을 높인다

생성 제한을 없애면 엔지니어링 작업이 쌓이는 위치는 바뀌지만, 변경을 수용하는 데 필요한 작업이 사라지지는 않는다.

무제한 AI 토큰은 눈에 보이는 결과물이 코드이기 때문에 무제한 엔지니어링 역량처럼 들린다. 그러나 생성된 패치, 즉 소스 파일 변경 제안은 여전히 존재 이유가 필요하다. 누군가는 무엇이 바뀌는지, 왜 안전한지, 누가 이를 유지보수할지를 확인해야 한다.

공유 인증 구성 요소를 현대화하는 가상의 사례를 생각해 보자. AI 도구는 더 명확한 코드, 최신 의존성, 추가 테스트를 제안할 수 있다. 하지만 그 제안은 기존 권한 규칙과 지원되는 고객 구성에 비추어 여전히 평가돼야 한다.

이 사례는 Cisco 프로젝트를 설명하는 것이 아니라 예시를 위한 것이다. 그럼에도 그럴듯한 소프트웨어를 생성하는 일과 배포된 동작에 대한 책임을 수용하는 일이 서로 다르다는 점을 보여준다. 더 빠른 초안 작성은 프로그래머 부족을 없애기보다 검토자 부족을 드러낼 수 있다.

엔지니어링 관리자는 즉각적인 압박에 직면한다. 제안된 변경이 팀이 평가할 수 있는 속도보다 빨리 도착하면 검토 대기열이 늘어난다. 그러면 관리자는 작업 범위를 좁힐지, 검토 역량을 늘릴지, 아니면 각 제안에 어떤 근거를 첨부할지 방식을 바꿀지 결정해야 한다.

보안 전문가는 관련된 문제에 직면한다. 이들은 프로세스가 접근 경계를 유지하고 민감한 정보를 적절히 처리하는지 파악해야 한다. 더 깔끔해 보이는 패치도 이전에는 간접적으로 강제되던 가정을 바꿀 수 있다.

제품 책임자는 내부 개선과 고객에게 영향을 주는 변경을 구분해야 한다. 외부 소프트웨어 구성 요소인 의존성을 교체하면 AI 도구가 직접 편집하는 파일을 넘어서는 동작이 나타날 수 있다. 따라서 수용 여부는 단순히 대체안의 매력도가 아니라 주변 시스템에 달려 있다.

이러한 책임은 보고 체계를 가로지르기 때문에 경영진 후원이 중요하다. 소규모 중앙 팀이 접근 방식을 개발할 수는 있지만, 영향을 받는 팀에는 변경을 승인할 방법이 여전히 필요하다. 권한이 불명확하면 성공적인 모든 시연은 누가 그 결과를 수용할지에 대한 협상이 된다.

이것이 Cisco AI 코드 재작성 목표의 조직적 의미다. 이 실험은 소규모 팀이 다른 팀이 신뢰할 수 있는 프로세스를 만들 수 있는지 시험한다. 그 결과물에는 재현 가능한 근거, 이해 가능한 변경 경계, 실패를 처리할 명확한 경로가 포함돼야 한다.

기존 유지보수 담당자는 이 과정에서 여전히 핵심적이다. 이들은 왜 어색한 구현이 존재하는지, 또는 어떤 고객 요구사항이 특이한 분기를 설명하는지 아는 경우가 많다. 현재 구현을 바꿔야 한다는 결론으로 이어지더라도 그러한 지식은 유용한 근거다.

문서화는 엔지니어링 역량 문제의 일부가 된다. 팀은 제안된 대체안을 평가하기 전에 설계 결정, 장애 이력, 호환성 요구사항에 접근할 수 있어야 한다. 검색 가능한 엔지니어링 지식 베이스는 코딩 워크플로와 함께 이러한 정보 문제를 해결한다.

그 결과 발생하는 압박은 실험의 양쪽에 모두 가해진다. 소규모 팀은 작업을 검토 가능하게 만들어야 하며, 기존 팀은 반대 의견을 구체적으로 설명해야 한다. 제한 없는 생성도 제도적 경험도 자동적인 답을 제공하지는 않는다.

Amazon의 애플리케이션 업그레이드는 더 좁은 비교 사례를 제공한다

경계가 정해진 마이그레이션은 정의되지 않은 소프트웨어 자산 전체를 포괄하는 비율보다 더 분명한 근거를 제공한다.

Amazon은 AI 지원 현대화의 업계 선례를 제공한다. 이 회사는 2024년 12월 애플리케이션 전환 발표에서 내부 애플리케이션을 Java 17로 업그레이드한 사례를 설명했다. Java는 엔터프라이즈 소프트웨어에 사용되는 프로그래밍 언어이자 런타임이다.

Amazon은 이 작업이 수만 개의 프로덕션 애플리케이션을 포괄했고 4,500명 이상의 개발자 연간 작업량을 절감했다고 밝혔다. 이는 독립 평가가 아니라 회사가 보고한 결과다. 그럼에도 레거시 코드를 재작성하겠다는 일반적 약속보다 더 구체적인 전환을 설명한다.

이러한 구체성은 중요하다. 버전 업그레이드는 식별 가능한 시작 상태와 목표 상태를 제공한다. 검토자는 애플리케이션이 빌드되는지, 예상 동작이 유지되는지, 새 런타임이 요구사항을 지원하는지 검토할 수 있다.

더 광범위한 재작성은 다양한 목표를 결합할 수 있다. 아키텍처 단순화, 의존성 교체, 유지보수성 향상, 폐기된 기능 제거 등이 포함될 수 있다. 동일한 AI 도구가 변경 생성에 도움을 주더라도 각 목표에는 자체적인 수용 기준이 필요하다.

AWS의 Java 업그레이드 워크플로도 명시적인 인간 수용 단계를 유지한다. 문서는 원래 코드를 빌드하고, 전환을 수행한 뒤, 개발자에게 결과를 검증하고 수용하도록 요청하는 과정을 설명한다. 언어 호환성 변경과 추가 의존성 업그레이드를 구분한다.

이 구분은 현대화가 단일 작업인 경우가 드물기 때문에 유용하다. 성공적인 언어 업그레이드가 모든 라이브러리가 최신이라는 사실을 입증하지는 않는다. 빌드 통과도 모든 고객 워크플로가 올바르게 동작함을 보장하지는 않는다.

따라서 Amazon의 사례는 제한적인 결론을 뒷받침한다. AI 지원 전환에는 설명 가능한 경계를 가진 구체적인 엔터프라이즈 활용 사례가 있다. 그러나 이것이 Cisco의 보도된 목표가 달성 가능하다는 사실을 입증하지는 않는다. 또한 아주 작은 구현 팀이 관련된 모든 수용 작업을 독립적으로 수행할 수 있음을 보여주지도 않는다.

측정 측면에서도 교훈이 있다. 절감된 개발자 시간의 추정치는 가정된 대체 프로세스에 달려 있다. 그 추정치는 배포된 애플리케이션, 승인된 변경, 지속적인 운영 성과와 함께 제시될 때 더 많은 정보를 제공한다.

Cisco의 실험도 이와 비슷하게 구체적인 보고의 혜택을 받을 수 있다. 초기 작업량에 대한 설명은 팀이 반복 가능한 전환을 시험하는지, 더 광범위한 재설계를 탐색하는지 드러낼 것이다. 둘 다 가치 있을 수 있지만 불확실성의 성격은 다르다.

엔터프라이즈 구매자에게 이 구분은 공급업체 주장을 해석하는 방식에 영향을 준다. 내부 시연은 특정 환경에서 특정 프로세스에 대한 근거다. 지원되는 고객 기능에는 유지보수, 문서화, 장애 처리에 관한 추가 약속이 필요하다.

경쟁 압력은 속도만큼이나 근거와 관련이 있다. AI 현대화를 논의하는 기업들은 무엇을 전환했는지와 수용이 어떻게 이뤄졌는지를 점점 더 설명해야 한다. 극적인 헤드라인 비율은 명확히 경계가 설정된 결과보다 유용한 정보를 적게 제공한다.

이 비교는 Cisco 이야기를 현실에 맞게 유지한다. 이 이야기의 의미는 공격적인 경영진 후원이 AI 지원 엔지니어링의 범위를 확장할 수 있는지 시험하는 데서 나온다. Amazon의 경험은 그 실험을 미리 결론내리지 않으면서 맥락을 제공한다.

98% 수치는 유용한 지표가 되기 전에 정의가 필요하다

현대화 비율은 독자가 무엇이 완료로 집계되는지 알 때에만 의미를 갖는다.

비율에는 분모, 즉 진척도를 측정하는 기준이 되는 전체 수량이 필요하다. 이 과제에서 그 수량은 소스 코드 줄 수, 리포지터리, 애플리케이션 또는 선택된 구성 요소일 수 있다. 보도 내용은 어느 해석이 적용되는지 명확히 하지 않는다.

이러한 선택은 매우 다른 진척도 그림을 만들 수 있다. 파일을 재포맷하면 유지보수성을 바꾸지 않고도 많은 소스 코드 줄에 영향을 줄 수 있다. 반면 작지만 핵심적인 구성 요소를 교체하려면 비교적 적은 코드에만 영향을 미치더라도 광범위한 검증이 필요할 수 있다.

완료 기준도 그만큼 중요하다. 제안된 변경 사항을 생성하는 것은 중간 단계다. 이를 소스 리포지터리에 반영하는 것은 또 다른 단계이며, 배포하고 기존 구현을 폐기하려면 추가 작업이 필요하다.

그렇다고 98%라는 목표가 본질적으로 불합리한 것은 아니다. 다만 공개된 설명만으로 그 목표를 평가하기 어렵다는 뜻이다. 독자가 이를 엔지니어링 예측으로 해석하려면 범위와 승인 정의가 필요하다.

리팩터링이라는 표현은 또 다른 측정 과제를 만든다. 리팩터링의 핵심은 동작 보존이지만, 기존 테스트는 자신이 포괄하는 동작만 검사한다. 테스트가 성공했다고 해서 테스트되지 않은 모든 조건이 그대로 유지됐음을 입증할 수는 없다.

이 간극이 검토와 운영 중 관찰이 중요한 이유를 설명한다. 기존 동작이 의도치 않게 사라지는 회귀는 자동화 테스트 시나리오에 포함되지 않은 영역에서 나타날 수 있다. 신뢰는 개별 검사를 결정적 증거로 취급하기보다 여러 증거를 결합할 때 형성된다.

연구는 또한 속도가 빠르다는 느낌을 측정된 생산성과 동일시하지 말라고 경고한다. METR의 개발자 생산성 실험은 익숙한 오픈소스 프로젝트에서 246개 작업을 수행한 경험 많은 개발자 16명을 조사했다. 2025년 초의 AI 도구 사용을 허용했을 때 완료 시간은 19% 증가했다.

그럼에도 참가자들은 도구가 작업을 더 빨리 끝내는 데 도움이 됐다고 믿었다. 이 결과는 체감 편의성과 측정된 납품 속도를 별도로 평가해야 하는 이유를 보여준다. 이는 Cisco의 결과를 예측하거나 이후 AI 도구에도 동일한 한계가 있다고 입증하는 것은 아니다.

METR는 이후 그 구분을 강조했다. 2026년 2월의 실험 설계 업데이트에서는 참가자 구성과 작업 선택이 달라져 새로운 측정치를 해석하기 어려웠다고 설명했다. 연구진은 속도 향상이 타당할 수 있다고 보면서도, 이용 가능한 증거만으로는 향상 폭을 정확히 확정할 수 없다고 경고했다.

종합하면 이러한 결과는 AI 코딩에 대한 보편적 판결보다 신중한 측정을 뒷받침한다. 도구 역량은 변하고, 작업마다 서로 다른 제약이 드러난다. 익숙한 오픈소스 유지보수에서 나온 결과를 대기업의 현대화 프로그램에 그대로 적용할 수는 없다.

Cisco에 중요한 질문은 전체 과정이 개선되는지 여부다. 생성 속도가 빨라져도 검토와 수정에 절약한 시간이 소모된다면 가치는 제한적일 것이다. 반대로 상당한 양의 코드를 의도적으로 그대로 둔다 해도 신뢰할 수 있는 프로세스라면 가치를 제공할 수 있다.

따라서 신뢰할 만한 평가는 활동과 결과를 구분해야 한다. 제안된 패치는 활동을 보여주고, 승인된 변환은 검토를 거친 진척도를 보여준다. 안정적인 배포와 유지보수 부담 감소는 작업이 목적을 달성했다는 더 강력한 증거를 제공한다.

무제한 토큰은 실험의 잠재적 제약 하나를 제거한다. 하지만 이러한 측정 문제를 해결하지는 않는다. Cisco가 인상적인 시연과 지속 가능한 엔지니어링 개선을 어떻게 구분할지 설명할 때, 보고된 목표는 더 많은 정보를 제공하게 된다.

소규모 팀에도 조직의 지식에 대한 접근은 필요하다

이 실험의 가장 강력한 형태는 재설계의 자유와 기존 소프트웨어가 현재처럼 동작하는 이유에 대한 접근을 결합하는 것이다.

인력 구성 이야기는 단순한 세대 간 해석을 유도한다. 젊은 창업자가 대규모 조직이 받아들여 온 가정에 도전한다는 것이다. 이 틀은 보도된 기회 변화는 포착하지만, 어느 엔지니어링 판단이 옳은지는 입증할 수 없다.

젊음이 자동으로 건전한 아키텍처를 낳지는 않으며, 근속 기간이 길다고 해서 기존 구현을 보존해야 한다는 근거가 자동으로 생기는 것도 아니다. 유의미한 구분은 제안이 검토를 견디는지 여부다. 소규모 팀에는 아이디어를 시험할 충분한 자유와 결과를 해석할 충분한 맥락이 모두 필요하다.

보도된 Krishnamurthy의 창업자 경력은 이러한 조직적 질문과 관련이 있다. 스타트업 경험은 좁게 배정된 과업보다 전체 문제에 주목하도록 장려할 수 있다. 그렇다고 변경의 영향을 받는 시스템을 이해하는 일을 대체할 수는 없다.

조직의 지식은 겉으로 보이는 비효율을 설명할 수 있다. 특이한 재시도 순서는 특정 운영 조건을 수용하기 위한 것일 수 있다. 중복된 검사는 오래된 통합을 보호할 수 있다. 이는 Cisco 소프트웨어에서 확인된 기능이 아니라 가상의 예시다.

그러한 설명은 가능한 한 검증 가능한 요구사항이 되어야 한다. 그렇지 않으면 현대화는 과거의 결정을 기억하는 사람을 찾는 데 의존하게 된다. 이유를 기록하면 새 구현은 필요한 동작을 보존하면서도 원래 설계에 도전할 수 있다.

반대 방향의 의무도 중요하다. 기존 팀은 문서화된 요구사항과 검토 없이 살아남은 관행을 구분해야 한다. 이의 제기는 실패 조건이나 승인 기준을 식별할 때 실행 가능한 것이 된다.

바로 이 지점에서 경영진의 지원은 엔지니어링 판단을 대체하지 않으면서 도움이 될 수 있다. 리더십은 접근 권한을 부여하고, 소유권 분쟁을 해결하며, 평가 시간을 보호할 수 있다. 하지만 열정만으로 정확성을 입증하거나 마감일을 증거의 대체물로 만들 수는 없다.

따라서 소규모 팀의 가장 가치 있는 기여는 대량의 대체 코드가 아니라 반복 가능한 프로세스일 수 있다. 그 프로세스는 제안된 변환을 관련 요구사항 및 명확한 승인 경로와 연결할 것이다. 그러면 다른 팀도 절차를 다시 구축하지 않고 유사한 작업을 평가할 수 있다.

이 가능성은 제안된 인력 규모를 해석하는 방식을 바꾼다. 소규모 팀은 변환 방법을 개발하고 도입을 조율할 수 있다. 이는 그 사람들만으로 모든 테스트, 보안, 지원 및 유지보수 책임을 맡을 수 있다고 주장하는 것과는 다르다.

또한 이 이야기가 초급 수준 고용에 관해 말해주는 범위도 제한한다. 인수된 창업자에게 이례적인 책임을 맡기는 것이 일반적인 채용 패턴을 입증하지는 않는다. 이 사례는 노동시장 결과가 아니라 특정 경영 판단에 관한 증거를 제공한다.

개발자에게 실질적인 시사점은 생성된 코드를 둘러싼 작업에 있다. 초안 작성이 쉬워져도 요구사항을 이해하고, 트레이드오프를 설명하며, 증거를 확립하는 일은 여전히 필요하다. 프로젝트가 조직 경계를 넘는 변경을 시도할 때 이러한 책임은 더 뚜렷해진다.

더 넓은 범위의 지식 노동자에게 이에 상응하는 것은 맥락에 대한 접근이다. AI 시스템은 그럴듯한 답을 만들 수 있지만 이전 결정이 중요했던 이유를 놓칠 수 있다. 유용한 자동화에는 그 이유를 찾아내고 불확실성을 드러내는 방식이 필요하다.

그러므로 Cisco의 실험은 조직 학습에 대한 시험이기도 하다. 소규모 팀이 흩어진 지식을 재사용 가능한 승인 증거로 전환할 수 있다면 전망은 개선된다. 프로젝트가 경험 많은 유지보수 담당자를 더 빠른 결과물의 장애물로만 취급한다면 전망은 약화된다.

파일럿 증거, 프로덕션 승인 및 유지보수 부담을 지켜보라

다음으로 유용한 업데이트는 무엇이 평가를 통과했는지, 누가 이를 승인했는지, 그 이후 어떤 일이 있었는지를 설명하는 내용일 것이다.

Cisco AI 코드 재작성은 향후 몇 달 동안 구체적인 증거를 통해 평가하기 쉬워질 것이다. 보도된 4주간의 검증 기간은 독자에게 단기적인 기준점을 제공한다. 그러나 보도 내용은 정확한 시작일을 확정하거나 공개 발표를 약속하지는 않는다.

첫 번째 신호는 파일럿의 범위와 결과에 대한 설명이다. 독자는 식별 가능한 작업량, 명시된 변환 목표 및 승인 기준을 찾아야 한다. 이러한 세부 사항은 팀이 더 큰 목표를 대표하는 대상을 시험했는지 보여줄 것이다.

성공적인 시연은 성과와 한계를 모두 드러낼 때 사례를 더 강하게 뒷받침할 것이다. 예를 들어 어떤 변경에 사람의 수정이 필요했는지 보고하면 프로세스의 실제 요구사항을 파악하는 데 도움이 된다. 이는 Cisco가 무엇을 공개할지에 대한 예측이 아니라 증거 기준이다.

새로 생성된 코드만 보여주는 데모는 더 약한 근거를 제공할 것이다. 호환성이나 승인을 설명하지 않은 채 결과물만 입증하기 때문이다. 장기 목표는 독립형 예시를 만드는 일이 아니라 기존 소프트웨어를 변경하는 일과 관련되므로 이 차이는 중요하다.

두 번째 신호는 프로덕션 납품 프로세스에 대한 승인이다. 독자는 책임 있는 팀이 범위가 제한된 변환을 승인하고 배포했다는 확인을 찾아야 한다. 이전 버전을 복원하는 정의된 방식인 롤백 절차는 프로그램이 실패를 어떻게 다루는지도 더 명확히 할 것이다.

이 신호는 실험을 운영 책임과 연결하기 때문에 현대화 사례를 강화할 것이다. 영향을 받는 팀이 단지 감탄하는 것이 아니라 작업을 평가할 수 있음을 보여줄 것이다. 그래도 승인은 해당 배포의 범위 안에서 해석해야 한다.

반대로 배포 없이 반복되는 시연은 핵심 질문을 해결하지 못한 채 남긴다. 프로세스는 유용한 제안을 생성할 수 있지만 승인 요건을 충족하는 데 어려움을 겪을 수 있다. 그러한 결과는 모든 변환에 가치가 없음을 입증하는 대신 납품 제약을 식별하게 된다.

세 번째 신호는 배포 후 유지보수 부담이다. 독자는 후속 수정, 지원 수요, 기존 구현을 폐기할 수 있는지에 관한 증거를 지켜봐야 한다. 이러한 결과는 현대화가 작업을 줄이는지, 아니면 단지 다른 곳으로 옮기는지 보여준다.

안정적으로 유지되고 향후 유지보수를 단순화하는 변경은 프로젝트의 전제를 뒷받침할 것이다. 광범위하고 반복적인 개입이 필요한 변경은 이를 약화시킬 것이다. 어느 결론도 첫 번째 대체 구현이 얼마나 빨리 등장했는지에만 근거해서는 안 된다.

이러한 신호는 AI 현대화 주장을 평가하는 기업 구매자에게도 더 나은 틀을 제공한다. 공급업체에 제안된 변경과 배포된 변경, 그리고 배포된 변경과 지속 가능한 개선을 구분해 제시하도록 요구하라. 어떤 작업량이 보고된 결과를 냈는지 이해할 수 있을 만큼 충분한 세부 정보를 요청하라.

엔지니어링 리더에게 즉각적인 행동은 조직 내에서 범위가 제한된 유지보수 문제를 검토하는 것이다. 기존 승인 기준을 확립하고, 그 제약을 이해하는 사람을 식별하며, 배포까지 이르는 전체 경로를 측정하라. 생성 속도와 함께 검토 및 수정 노력을 비교하라. 다른 곳에서 결과를 반복하는 데 제약이 될 가정을 기록하라. Cisco AI 코드 재작성은 경영진의 지원과 제한 없는 실험이 소프트웨어 현대화를 어디까지 확장할 수 있는지 시험한다는 점에서 주목할 가치가 있다. 궁극적인 중요성은 초기 흥분 이후에도 무엇이 신뢰할 수 있게 남는지에 달려 있다. 다음 업데이트가 나오면 구체적인 질문을 하라. 어떤 승인된 변경이 소프트웨어의 유지보수를 더 쉽게 만들었으며, 그 판단을 뒷받침하는 증거는 무엇인가?