요약
시스코가 27세 엔지니어에게 AI 토큰을 무제한으로 주고 레거시 코드 재작성을 맡겼습니다.
시스코의 지투 파텔 사장 겸 최고제품책임자가 포천에 전한 사례입니다. 그는 패디라고 불리는 파드마나반 크리슈나무르티에게 토큰을 마음껏 쓰라고 했고, 이를 경력 초기 인재가 필요한 이유로 들었습니다.
왜 중요한가
- 레거시 코드(오래되어 고치기 힘든 기존 코드) 정비를 대규모 조직이 아닌 2인 팀에 맡겨 보겠다는 시도입니다.
- 경영진이 신입급 채용의 근거로 경험자가 던지지 않는 질문과 새로운 시각을 내세운다는 점이 드러납니다.
핵심 내용
- 패디는 2인 팀으로 재작성하겠다고 제안했고, 증명할 시간으로 4주를 받았습니다.
- 최종 목표는 24개월 안에 레거시 코드의 98%를 리팩터링(동작은 유지한 채 구조를 고치는 일)하는 것입니다.
- 패디는 2023년 공동 창업한 실시간 번역 스타트업 이지덥스가 2025년 인수되면서 시스코에 합류했습니다.
- 파텔은 다섯 직급 아래에서 전략과 먼 일을 하던 그를 직접 찾아냈다고 말했습니다.
- 포천은 조시 쿠슈너, 알론 첸, 윌아이엠도 경력이 짧은 인재를 찾는다며 비슷한 흐름으로 묶었습니다.
HN 반응
- 일부 이용자는 언어 이식이 AI에 잘 맞는 일이라며, 콜드퓨전 사이트를 5만 줄 분량의 자바로 일주일 만에 옮긴 경험을 전했습니다.
- 반면 시스코는 옛 사이트처럼 화면을 비교해 검증하기 어렵고 보안 문제도 잦았다는 회의론이 나왔습니다.
저희는 얼마 전에 Claude Code로 오래된 ColdFusion 사이트를 Java Spring으로 옮겼는데, 결과가 놀랄 만큼 좋았습니다. Java 코드로 5만 줄 정도 되는데, 엔지니어 한 명이 월 200달러짜리 Claude 요금제로 일주일쯤 짬짬이 해냈습니다. 적어도 최근 십이 년 동안 하자는 얘기는 계속 나왔지만 시간을 낸 적이 없었습니다. 손으로 했다면 엔지니어 12~18개월 치 작업이었을 겁니다.
그 엔지니어는 번역 과정에서 브라우저 연동으로 새 사이트와 옛 사이트를 자동으로 비교하게 했습니다. 결과가 너무 좋아서, 새 사이트의 배경색을 바꿔야 했습니다. 원래 사이트와 워낙 똑같다 보니 자기가 지금 새 사이트를 테스트하는 게 맞는지, 모르고 옛 사이트를 보고 있는 건 아닌지 불안했기 때문입니다. 코딩, 개발자 테스트, 테스터 테스트, 배포까지 전부 2주가 안 걸렸습니다. 운영한 지 4~6주 됐는데 문제가 보고된 적은 없습니다.
월정액 요금제를 어떻게 상업적인 작업에 쓰고 계신 건가요? 약관을 그냥 무시하시는 게 아니라면요.
150명이 넘는 조직은 앤트로픽에 API 요금을 내야 한다는 얘기를 본 적이 있는데, 영국에서 우리가 약관을 살펴봤을 때는 Pro나 Max 같은 월정액 요금제에서는 업무용·상업용 사용이 어떤 식으로든 허용되지 않는다고 아주 분명하게 적혀 있었습니다. 그런 용도라면 API 토큰이나 상업 약관이 적용되는 기업용 요금제 같은 걸 써야 하고요.
저희가 8명짜리 조직이라는 점이 달라지는 게 있나요? 제가 알기로는 저희 사용이 허용되는 걸로 아는데, 아니라면 알려 주세요.
좋아요, 엔지니어 인건비를 20만 달러로 치면, 이 작업에서 비용 기준으로는 생산성이 천 배쯤, 시간 기준으로는 26배 넘게 올랐다는 말씀이신 거죠?
실제로 생산성이 오른 건 아니에요. 그 프로젝트는 AI가 나오기 전에는 할 만한 가치가 없었으니까요. 1700년대에 사람 200명이 손으로 터널을 파던 것과 2000년대에 기계로 터널을 뚫는 걸 비교하는 거나 마찬가지예요. 그걸 두고 생산성이 올랐다고는 하지 않잖아요. 꿈만 같던 프로젝트를 기술이 가능하게 만든 거죠.
여기서 투입은 돈과 엔지니어의 노동입니다. 이 새로운 자동화 덕분에 둘 다 훨씬 적게 듭니다. 얼마나 적게 드는지, 예전에는 경제성이 없던 프로젝트가 이제는 아주 싸게 먹힐 정도입니다.
결과물이 예전에 들었을 비용만큼의 가치는 없다는 말씀이라면 맞는 얘기입니다. 하지만 그 가치 판단을 바꿔서 프로젝트를 경제적으로 해낼 수 있게 만든 것이 바로 생산성 향상입니다.
구체적인 숫자는 비꼬는 거긴 한데요, 20만 달러짜리 엔지니어를 1천 달러짜리 구독으로 대체할 수 있고 곧 잘릴 텐데, 그럼 생산성은 19만 9천 달러만큼 떨어진 것 아닌가요?
말 그대로 노동의 산출물이 거의 가치 0이 된 거잖아요?
생산성은 여러 방식으로 잴 수 있어요. 신고전파 경제학자들은 방법이 하나뿐이라고 하겠지만요.
이 경우만 해도, 소프트웨어를 한 언어에서 다른 언어로, 한 프레임워크에서 다른 프레임워크로 옮기는 게 애초에 가치가 있기는 한가요?
예를 들어 제가 1,000달러어치 불법 마약을 만들었다고 해 봐요. 멀쩡하게 살던 어른을 중독된 범죄자로 만들 수도 있는 물건이에요. 그럼 제 생산성은 어떻게 재야 하죠?
그런데 구독이 일을 한 건 아니잖아요. 구독이 새로운 지식 노동자를 마법처럼 만들어 낸 건 아니에요. 창고에 놓인 잔디깎이가 저절로 풀을 깎지 않는 것과 같아요. 노동의 산출물 가치는 오히려 엄청나게 치솟았어요. 그 개발자를 자르면 Claude는 누가 쓰죠?
진짜 문제는 신입 개발자들이에요. 이제는 손으로 일일이 코드를 치고, 테스트하고, 리뷰하면서 그 과정에서 코딩을 배울 인력을 한 무리나 뽑아야 할 이유가 없어졌으니까요.
제가 자르지 않고 남겨 둔 10%의 개발자들이 쓰겠죠. 소프트웨어가 제게 실제로 얼마나 필요하겠어요?
어쨌든 제 논리에 허점이 있다는 건 알아요. 그냥 사고 실험이었어요.
AI 도구가 경쟁의 판을 평평하게 만든다고 생각하는 분이 많은데, 저희는 그렇지 않았습니다. 이 번역을 한 사람은 나머지 개발자 4명을 합친 것보다 티켓을 더 많이 처리합니다. 쉬운 티켓만 골라서 그런 것도 아니고요. 게다가 다른 개발자들은 안 하는 주 6시간짜리 회의까지 소화하면서요.
말씀하신 논점이 의미가 없다고 생각하진 않아요. 다만 이 대화는 바로 그 상위 10% 개발자에 관한 얘기예요. 이런 작업을 하는 사람은 해고되는 쪽이 아니에요.
인프라가 더 늘어난 것을 생산성이 오른 결과라고 말하는 건 말 그대로 흔한 일입니다.
"추구할 가치가 없었다"고 하셨는데, 이건 "추구하기엔 비용이 너무 컸다"로 바꿔 말할 수도 있습니다. 쓸 수 있는 역량이 훨씬 커지면 더 많은 일을 할 수 있게 됩니다. 이는 여러 분야에서 마찬가지입니다.
저희 경우는 지난 십 년 동안 더 우선순위가 높은 일이 계속 있어서 이 기술 부채를 안은 채로 지내 왔던 겁니다.
그런데 여기서 생산성의 단위가 뭔가요? 전에 시도된 적도 없고 앞으로도 다시 없을 이 작업 하나를 끝내는 데 걸린 시간인가요? 그것도 괜찮지만 경제적으로는 흥미로울 게 없습니다.
결국 경제 분석에는 화폐 단위를 써야 합니다. 투자 수익을 얼마나 더 빨리 거둘 수 있는지, 어느 규모에서 그런지가 문제죠. 이 분석이 계속 잡히지 않는 건, 사람들이 작업의 실행뿐 아니라 정의 자체도 LLM에게 맡길 수 있다고 믿기 때문입니다(수단과 목적은 뚜렷하게 구분되지 않으니, 아주 사소한 의미에서는 그 믿음이 맞을 수밖에 없긴 합니다).
"이 작업에서는"이라는 단서가 정말 중요합니다. 요구 사항은 이미 정해져 있었고, 십 년 동안 사업적으로 우선순위가 아니었던 일이니까요.
맞는 말씀입니다. 다만 이 글은 기존 코드를 현대화하는 기사 아래에 달린 답글이라는 점을 기억해 주세요.
물론이죠, 하나의 사례일 뿐이에요.
시스코는 검증할 때 이런 호사를 누리지 못할 것 같네요.
한 언어나 플랫폼에서 다른 쪽으로 옮기는 건 AI가 아주아주 잘하는 일이라서 좋은 활용처 같습니다. 먼저 포괄적인 테스트 스위트를 만든다면 가산점이 있고요.
물론 새 버그가 생기겠지만, 옛 코드에도 이미 버그가 잔뜩 있을 가능성이 높고 업데이트하기도 어려울 겁니다(처음 만든 사람들은 이미 떠났고 문서는 낡았고 등등). 그러니 이 상황에서 벗어나는 최선의 방법일 수 있습니다. 다만 이후에 제대로 된 지원이 따라야 1년 뒤에 똑같은 처지가 되지 않습니다(이게 어려운 부분입니다).
CEO의 호들갑스러운 발언은 좀 거슬리지만, 아이디어 자체가 나쁘지만은 않습니다.
시스코는 지난 몇 년간 보안 문제가 끊이지 않았습니다. CVE가 수백 건, 어쩌면 수천 건이고, 기기를 하드코딩된 비밀번호와 숨겨진 계정이 있는 채로 출하하는 걸로 잘 알려져 있죠.
얼마나 심했으면 암스테르담에서 열린 최근 글로벌 행사 기조연설(유튜브에 있습니다)에서 CEO인지 CTO인지, 기억이 안 나네요, 첫 몇 분 안에 과거의 보안 문제를 사과하면서 연설을 시작했습니다.
이번 일로 이 추세가 멈출 것 같지는 않습니다.
솔직히 말해서 Claude는 제 레거시 코드의 취약점을 여러 개 짚어 줬어요. 저만 그런 건 아닐 거고요.
당신이 바로 2028년의 개발자군요: https://youtu.be/uYG1TAzexdo
이 영상은 그분이 말한 내용과 아무 상관이 없습니다. 그분은 자기가 작성하는 코드에 대해 추가 정보를 배우는 데 쓴다고 말한 겁니다. 그런데 AI 버튼 누르는 것 말고는 아무것도 못 하는 사람이 나오는 꽤 따분한 영상을 올리셨네요. 결론은 이사회와 CEO들이 이제 직원 1만 5천 명이 하던 일을 하게 될 거라는 건가 봅니다.
참고로, AI를 대놓고 싫어하는 사람이 AI 없이는 자기 생각을 전달하지 못한다는 게 웃기네요.
그럼 Claude가 더 잘하겠네요.
저는 Abliterated GLM으로 코어 라우터 펌웨어 하나를 뽑아서 BGP 파싱 코드를 리버스 엔지니어링하는 데 150달러쯤 썼습니다. Ghidra에서 그 C/C++ 코드가 쏟아져 나오는 걸 보니 꽤 섬뜩하더군요. 그런데 악용할 수 있는 건 전혀 찾지 못했습니다. 이 코드는 최근 몇 년 사이의 CVE까지 포함해 워낙 실전에서 시달려서, 적어도 메모리 관리 수준에서는 안전하게 만들려고 엔지니어링 규율을 쏟아부은 것 같습니다. 하지만 이런 코드를 유지하는 비용은 어마어마할 테고, 다른 제품과 인터페이스 전체로 이게 확장되리라고는 생각하지 않습니다. 저는 전적으로 재작성 쪽입니다.
물론 Ghidra에서 나오는 코드는 원본 소스 코드보다 훨씬 나쁘다는 점은 알아 두세요. 변수 이름 같은 뻔한 것 말고도 템플릿이나 매크로 같은 복잡한 언어 기능은 되돌려지지 않습니다.
(제가 댓글을 잘못 이해한 거고, "섬뜩하다"가 코드 자체를 가리킨 게 아니라면 모르겠지만요.)
섬뜩했던 건, 모든 가능한 메시지가 절대 넘치지 않는 버퍼에 항상 복사되도록 하고, 해제와 할당도 안전하지 않은 방식으로 일어나지 않도록 하려고 메모리 규율을 엄청나게 지켜야 했다는 점입니다. 누군가 이런 검사를 강제하느라 막대한 노력을 쏟았는데, 더 안전한 언어였다면 이걸 자동으로 강제해 줬을 겁니다. 지금은 컴파일러 계층이나 도구가 대신 해 줄 수도 있겠지만, 그렇다 해도 지난번 CVE들이 나올 때는 없었던 겁니다. 그리고 도구가 있더라도 모든 코드에 쓰고 있진 않을 것 같습니다. 여러 결정이 BGP 파싱에 필요한 버퍼 크기에 아주 특화돼 보였거든요.
저는 이 작업 대부분을 수동적으로 지켜보기만 했는데, 느낌은 이랬습니다. "어, 검사 없는 복사네. 이거 악용될 수도 있겠는데, 공격 표면 쪽으로 네 단계 바깥인가, 아 아니네, 여기 명시적인 검사가 있어서 다 막혀 있네" 하는 걸 N번 반복하는 식이었습니다.
추신: 나중에 GLM에게 생각을 정리해 달라고 해서 여기에 올릴지도 모르겠습니다.
Abliterated GLM 5.3이 한 말은 이렇습니다. 약점을 구체적으로 나열하는 내용은 빼 달라고 요청했고, 제가 살펴본 시간 안에 찾은 문제는 전부 악용할 수 없는 것이었다는 점을 강조해 둡니다. 더 분석했다면 아무것도 못 찾았으리라는 뜻은 아닙니다. 이걸 붙여 넣으면 안 된다고 생각하실까 봐 덧붙이면, 이 모델을 쓸 수 있는 사람이라면 몇 시간 안에 이 결과를 전부 재현할 수 있습니다. 그리고 GLM 5.3도 가끔 틀립니다.
https://gist.github.com/matthewdgreen/38430b5e91780b70fdb5e9ea03921f7f
컴파일러는 증명 가능하게 불가능한 경우라면 검사를 없앨 수 있다는 건 아시죠? 그러니 소스 코드에는 두 군데 모두 검사가 있었을 수 있습니다. 아니면 저는 10년 전 IBM에서 파이버 채널 펌웨어의 파서를 만들 때 버퍼와 메시지 크기에 C의 static_assert를 썼는데, 그때도 clang 정적 분석기가 함수 사이에서 "이게 너무 작으면 어떡하지" 같은 분석을 해 줬다고 99% 확신합니다. 팬텀 타입이나 그냥... 구조체/클래스로 불변식(예를 들어 검사를 이미 마쳤다는 사실)을 순전히 컴파일 시점에 강제할 수도 있습니다. 네 단계 위에 있던 검사가 검증을 수행하는 사소한 구조체의 인라인 생성자였을 수도 있고요. 디스어셈블리만으로는 실제 소스가 어떻게 생겼는지 전혀 짐작할 수 없습니다.