AI 코딩 에이전트, 27년 묵은 코드를 몇 시간 만에 되살렸다

1999년, 한 젊은 수학자가 밤을 새워가며 자바(Java)로 시각화 프로그램을 짰습니다. 복소해석학과 선형대수를 학생들에게 보여주기 위한 작은 애플릿(applet)들이었죠. 그런데 세월이 흘러 브라우저가 옛 자바를 버리자, 그 프로그램들은 한순간에 먹통이 되어버렸습니다. 그렇게 죽어 있던 코드가, 2026년 7월 어느 날 몇 시간 만에 되살아났습니다. 그것도 세계 최고의 수학자 중 한 명이 직접 겪은 일이라면, 이 이야기는 그냥 넘길 […]

필즈상 수학자가 직접 목격한 ‘부활’의 현장

주인공은 필즈상(Fields Medal) 수상자인 테런스 타오(Terence Tao) UCLA 교수입니다. 수학계에서 그의 이름은 곧 권위 그 자체죠. 그런 그가 지난 7월 11일 자신의 블로그에 올린 글은, 화려한 신기술 예찬이 아니라 오래된 서랍을 정리하다 벌어진 소박한 실험담에 가깝습니다. 타오 교수는 낡은 웹페이지와 블로그 데이터를 좀 더 관리하기 쉬운 형태로 옮기던 중, AI 에이전트에게 27년 전 자바 애플릿들을 현대 언어인 자바스크립트(JavaScript)로 옮겨달라고 요청했습니다.

여기서 ‘에이전트’라는 말이 낯설 수 있습니다. 쉽게 말하면, 사람이 한 줄 한 줄 타이핑하는 대신 목표만 알려주면 스스로 코드를 쓰고 고치는 자동화된 개발 조수라고 보면 됩니다. 결과는 놀라웠습니다. 스무 개가 넘는 애플릿이 단 몇 시간 만에 되살아났고, 일부는 오히려 원본보다 나아졌습니다. 흑백이던 베시코비치 집합(Besicovitch set) 시각화는 컬러로 바뀌었고, 1999년 앨런 넛슨(Allen Knutson)과 함께 짰던 그 까다로운 허니컴(honeycomb) 애플릿도 다시 숨을 쉬기 시작했습니다.

흥미로운 대목은 코드 품질에 대한 그의 담담한 평가입니다. AI가 만든 코드에는 크고 작은 버그가 숨어 있다는 것이 개발자들의 오랜 걱정거리였죠. 그런데 타오 교수의 경험은 그 통념을 정면으로 비껴갑니다.

“스무 개가 넘는 애플릿을 옮기는 과정에서 사소한 버그 하나밖에 찾지 못했습니다. 오히려 에이전트는 제가 몰랐던 원본 코드의 버그 두 개를 찾아냈고, 결국 코드 품질 면에서는 득실이 없는 셈이 되었습니다.”

테런스 타오, 블로그 ‘What’s new’ (2026년 7월 11일)

AI가 실수를 만들어내기는커녕 사람이 25년 넘게 눈치채지 못한 오류를 잡아냈다는 이야기입니다. 비유하자면, 오래된 집을 수리하러 온 인부가 벽지만 새로 바른 게 아니라 그동안 아무도 몰랐던 배관 누수까지 짚어준 셈입니다. 물론 타오 교수 스스로도 선을 긋습니다. 이 애플릿들은 수학 논증의 핵심 부품이 아니라 어디까지나 보조적인 시각 자료이기에, 설령 버그가 남아 있어도 위험 부담이 낮다는 점을 분명히 했죠.

“몇 시간 만에”라는 말의 무게, 그리고 데이터의 반박

이 이야기에서 가장 마음을 흔드는 것은 기술이 아니라 시간입니다. 타오 교수는 1999년에 이미 특수상대성이론 시각화 도구를 구상했습니다. 그의 표현을 빌리면 ‘민코프스키 공간(Minkowski space)에서 돌아가는 잉크스케이프(Inkscape)’ 같은 도구였죠. 하지만 코드의 복잡도가 감당할 수 없을 만큼 커지자 그는 프로젝트를 접었습니다. 그렇게 27년간 묻혀 있던 꿈을, 그는 이번에 ‘바이브 코딩(vibe coding)’이라 불리는 방식으로 단 두어 시간 만에 완성했습니다. 바이브 코딩이란, 세세한 설계도를 그리기보다 AI와 대화하듯 방향만 잡아주며 결과물을 빚어내는 요즘의 개발 풍경을 가리키는 말입니다.

한 사람의 25년 묵은 좌절이 하룻저녁에 풀렸다는 이야기는 분명 감동적입니다. 그러나 냉정한 분석가라면 여기서 한 걸음 물러서야 합니다. 한 명의 천재적 수학자가 겪은 성공담이, 과연 현장의 평범한 개발자들에게도 그대로 적용될까요. 이 지점에서 최근의 데이터는 사뭇 다른 표정을 짓고 있습니다.

낙관론의 근거는 충분합니다. 맥킨지(McKinsey)가 2026년 초 150개 기업 개발자 4,500명을 조사한 결과에 따르면, 반복적인 코딩 작업 시간이 46% 줄었고 개발자 한 명당 주당 3.6시간을 아낀 것으로 나타났습니다. API 연동이나 판에 박힌 코드 생성 같은 영역에서는 최대 81%의 시간 절감이 보고되기도 했습니다. 타오 교수의 애플릿 이식처럼, 창의성보다 반복이 지배하는 작업에서 AI는 확실한 위력을 발휘할 수밖에 없습니다.

문제는 반대편의 숫자입니다. 개발자 약 800명을 추적한 업레벨(Uplevel)의 조사에서는, AI 코딩 도구 도입 이후 초기의 속도 향상이 41%나 늘어난 버그 발생률에 의해 상쇄되었습니다. 더 뼈아픈 대목은 개발자들의 착각입니다. 무려 95%가 스스로 생산적이라고 느끼면서도, 실제로는 더 낮은 품질의 코드를 내놓고 있었다는 것이죠. 개발자의 66%는 ‘AI가 내놓은, 거의 맞지만 어딘가 어긋난 답’을 가장 큰 골칫거리로 꼽았고, 45%는 AI가 짠 코드를 디버깅하는 편이 자기 코드를 고치는 것보다 더 오래 걸린다고 답했습니다.

같은 기술을 두고 왜 이렇게 상반된 그림이 그려질까요. 답은 타오 교수가 무심코 남긴 한 문장에 숨어 있습니다. 그는 애플릿이 ‘핵심 부품이 아니’라서 위험이 낮다고 했습니다. 뒤집어 말하면, AI 코딩의 성패는 기술의 우열이 아니라 ‘어디에 쓰느냐’에 달려 있다는 뜻입니다. 실패해도 큰 탈이 없는 보조 도구라면 축복이 되지만, 서비스의 심장부를 맡기는 순간 그 41%의 버그는 재앙이 될 수밖에 없죠.

결론 및 마무리

타오 교수의 이야기가 특별한 이유는, 그것이 AI 예찬론도 회의론도 아니기 때문입니다. 그는 그저 오래 미뤄둔 숙제를 마침내 끝낸 사람의 홀가분함을 기록했을 뿐입니다. 그리고 바로 그 담백함 속에 이 기술의 본질이 있습니다.

우리는 흔히 AI가 ‘무엇을 할 수 있느냐’를 묻습니다. 하지만 진짜 물어야 할 질문은 ‘무엇을 맡겨도 괜찮으냐’입니다. 27년간 죽어 있던 애플릿을 되살리는 일, 접어두었던 아이디어에 다시 불을 붙이는 일. 이렇게 실패의 대가가 크지 않은 영역에서 AI는 사람의 오랜 갈망을 현실로 바꾸는 도구가 됩니다.

어쩌면 앞으로의 승부처는 더 똑똑한 AI를 만드는 경쟁이 아닐지도 모릅니다. 오히려 AI에게 맡길 일과 사람이 끝까지 붙들어야 할 일의 경계를 얼마나 냉정하게 그어내느냐, 그 판단력이 개인과 조직의 실력을 가르는 새로운 기준이 될 수밖에 없습니다. 도구는 이미 우리 손에 쥐어졌습니다. 이제 남은 질문은 기술이 아니라, 그것을 쥔 사람의 몫입니다.