필즈상을 받은 수학자 테런스 타오가 2026년 7월, 자신의 블로그에 조용히 글 하나를 올렸습니다. 그는 1999년에 직접 작성해 두었던 Java 1.0 애플릿 스무 개 남짓을 꺼내 들었습니다. 당시 웹 브라우저가 Java를 지원하던 시절에나 돌아가던 코드들이었습니다. 그것을 현대 JavaScript로 옮기는 데 걸린 시간은 "몇 시간"이었습니다. 그리고 버그는 단 한 건, 그마저도 경미했습니다.

숫자 자체보다 더 눈길을 끄는 것은 타오가 이 작업을 묘사한 방식입니다. 그는 "LLM 에이전트와의 안내된 상호작용"이라고 썼습니다. 스스로 코드를 쳐 내려간 것도, 외주 개발자에게 넘긴 것도 아니었습니다. 대화를 이끌어 가는 사람이 타오 자신이었고, 구현을 채워 넣는 쪽이 에이전트였습니다. 이 역할 분담 방식은 소프트웨어 개발 바깥에 있는 사람들에게도 적용됩니다.

27년 묵은 코드를 꺼낸 이유

그 안에는 특수상대성이론을 시각화한 앱도 있었고, 길브레스 추측을 탐구하는 대화형 도구도 포함되어 있었습니다. 타오가 이것들을 다시 꺼낸 것은 자신이 최근 발표한 수학 논문을 독자들이 직접 만지며 탐색할 수 있도록 보완 자료를 만들기 위해서였습니다.

특수상대성 앱도 "몇 시간의 바이브 코딩" 끝에 완성되었다고 타오는 적었습니다. 길브레스 추측 시각화 도구도 마찬가지로 "또 다른 몇 시간의 대화" 뒤에 나왔습니다. 이 작업에서 AI는 원본 코드에 숨어 있던 버그 두 개를 스스로 찾아냈습니다. 타오는 전체적인 코드 품질이 "상쇄되는 수준"이었다고 평가했는데, 이 말은 곱씹을 필요가 있습니다. 인간이 짠 코드와 에이전트가 전환한 코드 사이에 품질 격차가 거의 없었다는 뜻입니다.

여기서 타오가 한 일의 구조를 분해해 보면 흥미롭습니다. 그는 데이터 모델과 사용자 인터페이스를 어떻게 나눌 것인지, 백엔드에서 어떤 기준점을 고정할 것인지와 같은 고수준의 설계 판단을 직접 내렸습니다. AI는 "낮은 수준의 구문과 구현 문제"를 채웠습니다. 설계는 타오가, 문법은 에이전트가. 그는 이것이 중요하다고 강조했습니다.

전문가가 도구를 쥐면 무엇이 달라지는가

이 사례를 "AI가 개발자를 대체한다"는 방향으로 읽으면 중요한 것을 놓칩니다. 타오는 수십 년의 수학 연구 경험과 1999년의 프로그래밍 경험을 동시에 가진 사람입니다. 그가 에이전트와 나눈 대화의 질은 그 배경 없이는 성립하지 않습니다. "프로그래밍 경험과 도메인 전문성이 필수적"이라는 그의 표현은 겸손이 아니라 작업의 조건을 기술한 것에 가깝습니다.

이 지점에서 반대쪽 입장도 정직하게 들어야 합니다. 코딩 에이전트를 쓰면 누구나 타오처럼 몇 시간 안에 앱을 만들 수 있다는 결론은 섣부릅니다. 프로그래밍 배경이 전혀 없는 사람이 에이전트에게 막연한 지시를 내릴 때 나오는 결과물은 타오의 경우와 다를 가능성이 높습니다. 무엇을 검증해야 하는지, 버그가 있을 때 어디를 의심해야 하는지, 설계가 잘못됐을 때 어느 지점에서 방향을 틀어야 하는지를 판단하는 능력은 에이전트가 채워 주지 않습니다. 특히 복잡한 도메인 지식이 결합된 도구일수록 이 판단력의 비중은 커집니다.

그렇다면 이 사례는 아무 시사점이 없는 것일까요. 그렇지도 않습니다. 어디에 전문성이 있느냐에 따라 코딩 에이전트는 전혀 다른 도구가 됩니다. 타오에게 부족했던 것은 최신 JavaScript 문법이었습니다. 그는 에이전트에게 정확히 그 부분만 맡겼습니다. 수십 년 축적한 수학 지식과 1999년에 직접 짰던 코드의 구조 파악은 타오 쪽에 있었습니다. 이 분업이 작동했습니다.

비슷한 분업이 가능한 곳은 순수 개발 분야 바깥에도 있습니다. 예를 들어 특정 산업에서 오래 일한 사람이 자신의 업무 흐름을 도구로 만들고 싶을 때입니다. 그 사람에게 부족한 것은 코드 문법이지, 업무의 논리 구조가 아닙니다. 타오의 구도와 비슷합니다.

기획자·1인 사업자가 점검할 세 가지

지금 코딩 에이전트를 외주 대체재로 바라보는 시각과, 자신의 전문성을 실행 도구로 전환하는 수단으로 바라보는 시각은 출발점이 다릅니다. 전자는 에이전트가 얼마나 많은 것을 해주는지를 기준으로 삼고, 후자는 자신이 무엇을 알고 있는지를 기준으로 삼습니다.

타오의 사례에서 실질적으로 응용 가능한 것을 추려보면 이렇습니다.

첫째, 지금 반복하는 업무 중 "도구가 있었으면" 하는 지점을 한 가지 찾아보는 일입니다. 데이터를 정리하는 방식, 클라이언트에게 보내는 보고서의 형식, 재고나 일정을 관리하는 방식 같은 것들입니다. 이것을 에이전트에게 직접 물어보기 전에 먼저 자신의 언어로 설명할 수 있는지를 확인해야 합니다. 설명할 수 없으면 에이전트도 만들 수 없습니다.

둘째, 시간 기대치를 조정하는 일입니다. 타오가 몇 시간 만에 완성했다는 사실은 맥락 없이는 오해를 낳습니다. 그는 원본 코드를 본인이 직접 썼고, 도메인을 수십 년간 연구했으며, 어떤 결과물이 나와야 하는지 정확히 알고 있었습니다. 이 조건이 없다면 같은 시간 내에 같은 품질이 나오지 않을 수 있습니다. 그렇더라도 외주를 발주하고 수정 사이클을 반복하는 것보다 빠를 가능성은 여전히 있습니다. 단, 중간에 무엇을 결정해야 하는지는 자신이 파악하고 있어야 합니다.

셋째, 실패 지점을 먼저 상상해 보는 일입니다. 에이전트가 만들어 준 코드에서 무엇이 틀렸는지를 확인할 능력이 없다면 결과물을 그대로 쓰는 것은 위험합니다. 타오가 "버그 한 건"을 발견할 수 있었던 것은 그가 결과물을 검증할 수 있었기 때문입니다. 검증 능력이 없는 분야에서는 결과물에 대한 책임을 에이전트에게 넘길 수 없습니다.

사업 전략을 논하는 책들이 오래전부터 강조해 온 것이 있습니다. 자신이 실제로 아는 것과 모르는 것을 구분하지 않으면 도구가 늘어날수록 혼란도 커진다는 것입니다. 코딩 에이전트도 이 원칙에서 벗어나지 않습니다.

타오가 1999년의 코드를 꺼낸 것은 지금의 도구로 당시의 아이디어를 독자에게 다시 전달하기 위해서였습니다. 목적이 분명했고, 자신이 이미 알고 있는 것이 무엇인지도 분명했습니다. 에이전트는 그 사이의 빈칸을 채웠습니다. 1인 사업자나 기획자가 같은 일을 하려면 먼저 자신이 채워야 할 빈칸과 에이전트에게 맡길 빈칸을 구분해 두어야 합니다. 그 구분이 선행되지 않으면 아무리 강력한 에이전트도 시간을 절약해 주는 도구가 되기 어렵습니다.