테리 타오가 AI 코딩 에이전트로 1999년 자바 애플릿을 되살린 이야기

• 테리 타오가 1999년에 만들었던 자바 애플릿들을 AI 코딩 에이전트로 되살렸다는 이야기임

  • 복소해석, 선형대수 수업용 애플릿과 honeycomb, Besicovitch set 같은 수학적 대상 시각화 도구들이 대상임
  • 원래는 Java 1.0으로 직접 짰고, 당시에는 꽤 성공적이었지만 시간이 지나 브라우저가 해당 자바 버전을 지원하지 않으면서 전부 죽은 상태가 됨

• 이번에는 옛 웹페이지와 블로그 데이터를 더 유지보수하기 쉬운 저장소로 옮기는 과정에서 실험을 해봄

  • AI 에이전트에게 옛 애플릿을 현대적으로 지원되는 언어로 포팅해보라고 시킴
  • 최종 선택은 자바스크립트였고, 몇 시간 만에 오래된 애플릿들이 다시 동작하게 됨
  • 일부는 원본보다 그래픽이 나아졌는데, 예를 들어 Besicovitch set 애플릿은 원래 흑백이었지만 새 버전은 컬러가 들어감

• 특히 1999년에 Allen Knutson과 함께 만들었던 honeycomb 애플릿이 살아난 걸 반가워함

  • 이 애플릿은 당시 손으로 코딩하기 꽤 까다로운 축에 속했다고 함
  • 단순 정적 그림이 아니라 상호작용하는 수학 시각화라 포팅 난도가 있었던 셈임

• 품질 면에서도 생각보다 결과가 나쁘지 않았다고 평가함

  • LLM 기반 코딩 에이전트가 뻔하거나 미묘한 버그를 만들 수 있다는 점은 인정함
  • 그런데 약 두 dozen, 즉 스무 개가 넘는 애플릿을 포팅하면서 본인이 찾은 새 버그는 복소해석 애플릿 하나의 드래그 이벤트 문제 정도였음
  • 메인 박스 밖으로 드래그할 때 원치 않는 동작이 생기는 수준의 작은 버그였다고 설명함

• 재미있는 건 에이전트가 원래 코드에 있던 버그도 2개 찾아냈다는 점임

  • 새로 만든 버그가 하나 있었지만, 기존 코드 버그 2개를 발견했으니 코드 품질 면에서는 거의 손익분기였다고 봄
  • 게다가 이 애플릿들은 수학 논증의 핵심 부품이 아니라 보조 시각화 자료라, 버그가 있어도 리스크가 상대적으로 낮음

• 이 성공 이후 아예 새 앱도 만들어봄

  • 테리 타오는 1999년에 특수상대성이론 시각화 도구를 만들고 싶어 했음
  • 본인이 표현한 아이디어는 “민코프스키 공간(Minkowski space)에서의 Inkscape”에 가까웠음
  • 당시에는 Inkscape도 나오기 전이었고, 직접 Java로 시작했지만 코드 복잡도가 너무 커져 포기했다고 함

• 그런데 이번에는 몇 시간의 바이브 코딩으로 그 아이디어를 알파 버전까지 구현함

  • AI 에이전트와 대화하면서 원하던 앱을 생성했고, 대화 요약도 따로 공개함
  • 지루한 기술 구현 보고는 많이 덜어낸 편집본이라고 설명함
  • 본인이 어느 정도 playtest는 했지만, LLM 생성 코드 특성상 아직 버그와 거친 부분이 있을 거라며 피드백을 요청함

• 개발자 입장에서 읽을 만한 지점은 “어떤 작업에 AI 코딩 에이전트가 잘 맞나”임

  • 레거시 UI나 교육용 시각화처럼 결과를 눈으로 확인하기 쉽고, 실패 비용이 낮은 작업에는 효과가 큼
  • 반대로 정확성이 절대적인 핵심 로직이라면 여전히 검증 비용이 중요함
  • 이 사례는 AI 코딩 에이전트를 무작정 제품 핵심에 넣기보다, 낡은 자산을 되살리고 실험용 프로토타입을 만드는 데 먼저 붙여보는 게 현실적이라는 쪽에 가까움

---

기술 맥락

• 여기서 테리 타오가 한 선택은 오래된 Java 1.0 애플릿을 현대 브라우저에서 돌아가는 자바스크립트로 옮기는 거예요. 왜냐하면 자바 애플릿은 웹 표준 변화로 사실상 실행 환경이 사라졌고, 교육 자료로 남기려면 브라우저 네이티브 기술로 다시 만들어야 했거든요.

• AI 코딩 에이전트가 잘 먹힌 이유는 결과 검증 방식이 비교적 명확했기 때문이에요. 수학 시각화 앱은 화면에서 움직임과 상호작용을 직접 확인할 수 있고, 원본 애플릿이라는 비교 대상도 있어요. 그래서 에이전트가 만든 코드를 사람이 빠르게 평가하기 좋아요.

• 리스크 판단도 중요해요. 이 애플릿들은 증명의 핵심이 아니라 보조 시각화 자료라서, 작은 UI 버그가 있어도 치명적인 오류로 이어질 가능성이 낮아요. 그래서 AI가 빠르게 포팅한 뒤 사람이 테스트하며 고치는 방식의 비용 대비 효과가 좋아져요.

• 새 특수상대성이론 앱 사례는 프로토타이핑 쪽 장점을 보여줘요. 예전에는 코드 복잡도 때문에 포기했던 아이디어도, 지금은 에이전트와 몇 시간 대화하면서 알파 버전까지 끌고 갈 수 있어요. 다만 본문에서도 말하듯이 알파라는 이름에 맞게 버그 검증은 여전히 사람 몫이에요.