현대 코딩 에이전트로 되살린 옛 수학 앱과 새로 만든 앱

 (terrytao.wordpress.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 지원이 끊긴 Java 1.0 수학 애플릿 약 24개를 현대 AI 코딩 에이전트로 JavaScript에 이식하고, 과거에 구현하지 못했던 시각화 도구까지 완성함
  • 기존 애플릿은 몇 시간 만에 복원됐으며, Besicovitch 집합의 컬러 표시 같은 그래픽 개선과 1999년 Allen Knutson과 만든 honeycomb 애플릿의 재구현도 이뤄짐
  • 이식 과정에서 에이전트가 만든 버그는 드래그 처리와 관련된 사소한 문제 1개였고, 반대로 기존 코드의 미확인 버그 2개를 찾아 전체 코드 품질은 비슷한 수준을 유지함
  • 복잡성 때문에 1999년에 포기했던 “Minkowski 공간의 Inkscape” 구상을 몇 시간의 바이브 코딩으로 특수상대성이론 시각화 앱의 알파 버전으로 구현하고, Gilbreath 추측 시각화도 새로 제작함
  • 수학적 논증의 핵심이 아닌 보조 시각화는 LLM 생성 코드의 버그가 미칠 위험이 상대적으로 낮아, 향후 논문의 대화형 보충 자료로 활용할 수 있음

Java 1.0 애플릿의 시작과 중단

  • 1999년부터 기계를 이용해 수학을 연구하고 가르치는 방법에 관심을 두고, 복소해석과 선형대수 강의를 위한 여러 애플릿을 Java 1.0으로 개발함
  • 강의뿐 아니라 honeycomb과 Besicovitch 집합을 비롯한 여러 수학적 대상을 시각화하는 데도 애플릿을 활용함
  • 어느 정도 성과를 거뒀지만 직접 프로그래밍하는 데 많은 시간이 필요했고, 웹 표준이 해당 Java 버전을 지원하지 않게 되면서 애플릿들이 작동하지 않게 됨

AI를 활용한 JavaScript 이식

  • 기존 웹페이지와 블로그 데이터를 유지보수하기 쉬운 저장소로 옮기면서 현대적인 AI 지원을 활용함
  • 실험 삼아 에이전트에게 기존 애플릿을 현재 지원되는 언어로 이식하도록 요청했고, 최종적으로 JavaScript를 선택함
  • 약 24개의 기존 애플릿이 몇 시간 만에 다시 작동했으며 일부 그래픽도 개선됨

새 버그와 기존 코드의 오류 발견

  • LLM 기반 코딩 에이전트가 명백하거나 미묘한 버그를 만들 수 있지만, 이번 이식에서 새로 발견된 문제는 사소한 버그 1개였음
    • 복소해석 애플릿 하나에서 주 영역 밖으로 드래그할 때 원하지 않는 동작이 발생함
  • 반대로 에이전트는 기존 코드에 숨어 있던 미확인 버그 2개를 찾아냈으며, 이를 함께 고려하면 전체 코드 품질은 비슷한 수준임
  • 이 애플릿들은 수학적 논증의 핵심 구성요소가 아닌 보조 시각 자료여서, 버그가 발생하더라도 그에 따른 위험은 상대적으로 낮음

1999년에 포기했던 특수상대성이론 도구

  • 기존 앱 이식이 어렵지 않게 진행되자 새로운 앱 제작도 시도함
  • 1999년 특수상대성이론 시각화 도구로 “Minkowski 공간의 Inkscape”와 같은 구상을 세웠지만, 당시에는 Inkscape도 출시되기 전이었음
  • Java 코드 작성을 시작했으나 복잡성을 감당하기 어려워 프로젝트를 포기함
  • AI 에이전트와 몇 시간 동안 바이브 코딩한 끝에 당시 구상과 일치하는 시공간 다이어그램 애플릿을 구현함
  • 제작 대화 요약도 공개했으며, 반복적인 기술 구현 보고는 편집 과정에서 다수 제거함
  • 현재 앱은 일부 플레이 테스트만 마친 알파 버전으로, LLM 생성 코드 특성상 해결되지 않은 버그와 거친 부분이 남아 있을 수 있어 추가 피드백이 필요함

Gilbreath 추측 시각화

  • Gilbreath 추측 논문에 관한 블로그 글을 작성한 뒤, 논문과 게시물에 첨부할 시각화 도구도 에이전트에게 요청함
  • 몇 시간의 대화를 거쳐 Gilbreath 추측 시각화를 완성함
  • 제작 과정 대화록도 함께 공개했으며, 개발은 큰 어려움 없이 진행됨

논문의 대화형 보충 자료로 활용

  • 향후 논문에 대화형 시각화를 보충 자료로 추가하는 방안을 고려함
  • 이런 시각화는 논문의 핵심 부분에 필수적이지 않으므로, LLM 에이전트와의 안내된 상호작용으로 생성하더라도 오류에 따른 위험을 감수할 수 있는 수준임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • LLM으로 시각화 자료를 만들면서 컴퓨터과학 수업이 크게 개선됐음: https://htmx.org/essays/universities-and-ai/#demos-visualiza...
    늘 원했지만 시간이 없어 만들지 못했던 자료들을 이제 갖추게 됐고, Claude의 도움으로 기존 16비트 교육용 컴퓨터를 보완할 단순한 8비트 컴퓨터도 며칠 만에 설계함: https://bdp.cs.montana.edu/

    • 늘 원했지만 시간이 없었던 부가 기능을 구현하는 건 LLM의 훌륭한 활용처임. 특히 시각화 코드는 완벽한 구조나 유지보수성을 갖출 필요 없이 올바른 시각적 결과만 내면 되고, LLM은 원하는 모습이 될 때까지 반복 수정하는 데 뛰어남
    • 수학 논문을 읽을 때 LLM으로 시각화를 만들고 있음. “이 글의 각 부분을 3Blue1Brown 영상 스타일로 manim을 사용해 시각화하라”고 요청하면 인상적인 결과가 나옴
      덕분에 내용을 더 빨리 소화하고 이전보다 많은 논문을 읽을 수 있게 됨
    • LLM으로 PIL 명령과 매개변수를 작성하고 수정하면서 몇 시간씩 절약함
    • 성적 반영 비율을 바꾼 글을 보면 https://acbart.github.io/2026/04/19/proctored-grades/ 대략 50 대 50 배분으로 보임. 그렇다면 모든 퀴즈에서 40%를 받은 학생도 C-로 과목을 통과할 수 있다는 뜻인가?
    • 마이크로컨트롤러 수업에서 강사가 칠판에 8비트 컴퓨터의 레지스터, 메모리, 명령어를 직접 그려가며 설명했는데, 내부 작동 방식을 이해하는 재미가 컸음
      가르친 내용을 더 많이 시뮬레이션할 수 있으면 좋겠다고 생각했음. 교육은 대상을 구성 요소로 분해하고 상호작용을 살펴보는 과정이므로, 바이브 코딩한 시뮬레이션이 훌륭한 도구가 될 수 있음

  • Terry Tao가 코딩 에이전트로 앱을 만든다면, 이제 필즈상 수상자도 우리처럼 LLM에 Docker 컨테이너가 왜 시작되지 않는지 물어보기까지 한 걸음 남았음

    • LLM 이전에도 전문 소프트웨어를 만드는 필즈상 수상자 Martin Hairer가 있었음: https://en.wikipedia.org/wiki/Martin_Hairer, https://www.hairersoft.com/
    • AI가 모두를 최고 수준으로 끌어올릴 줄 알았는데, 오히려 최고들을 우리 손이 닿는 수준으로 내려놓은 셈임
    • 반대로 코딩 에이전트가 Terry Tao에게 자신이 작업하려는 증명이 필즈상을 받을 만한지 묻는 날을 기다리고 있음

  • 특히 전통적인 소프트웨어 분야 밖에는 잠재적인 소프트웨어 수요가 사실상 무한함. LLM 발전이 오늘 멈추더라도 새로 생긴 소프트웨어 작성 능력을 모두 활용하려면 10년은 걸릴 것이며, 이번 사례가 이를 잘 보여줌

  • “LLM으로 만든 대화형 보조 자료는 논문의 핵심에 필수적이지 않으므로, 에이전트와의 유도된 상호작용으로 이런 시각화를 생성하는 위험은 감수할 만하다”는 결론이 균형 잡혀 있음
    LLM은 도구라서 잘 맞는 일과 그렇지 않은 일이 있으며, 일반적으로 결과를 그대로 믿어서는 안 됨

    • LLM 에이전트의 결과는 늘 검증해야 하지만, AI를 의인화하지 말라고 하면서 신뢰라는 의인화된 표현을 쓰는 건 조금 재미있음. 모델과 실행 도구가 개선되고 효과적인 작업 흐름이 정립되면서 AI에 대한 신뢰는 빠르게 높아지고 있음
      망치는 못에는 믿고 쓰지만 나사에는 쓰지 않는데, 그렇다고 망치를 일반적으로 신뢰할 수 없다고 하지는 않음. AI의 어려움은 무엇이 못이고 나사인지 아직 모른다는 데 있음
      단순히 믿지 말라고 하기보다 이전보다 계획·반복·검토에 더 많은 시간을 써야 하고, 기술·맥락·하위 에이전트 활용법을 익히며, 먼저 비운영·저위험 프로젝트에서 연습하라고 안내하는 편이 유용함. 좋은 작업 흐름과 적합한 용도를 이해하면서 신뢰를 쌓는 게 목표여야 함
    • 이 맥락에서 신뢰가 무엇인지 모르겠음. Donald Knuth를 고용해 모든 코드를 작성하게 해도 버그가 없거나 내 요구에 적합하다고 믿지는 않을 것임
    • AI 낙관론자 중에는 Tao가 수학적 증명에서 LLM을 활용한 발언을 근거로, 이미 시스템이 매우 발전했고 자율적으로 작동한다고 강하게 보는 이들이 많음
    • LLM은 유지보수하기 어렵고 신뢰할 수 없는 끔찍한 코드를 만들어냄. 개인용 장난감 같은 저위험 프로젝트를 바이브 코딩하는 건 괜찮지만, 위험도가 높은 코드에는 분명 적합하지 않음

  • Terry Tao가 코딩 에이전트를 쓰는 모습은 미슐랭 스타 셰프가 전자레인지 즉석식품을 발견하고 진심으로 신나 하는 장면 같음

    • 과거의 요리책을 살펴보며 전자레인지 조리를 진지하게 발전시켰다면 어땠을지 다룬 글이 흥미로웠음: https://malmesbury.substack.com/p/my-journey-to-the-microwav...
    • 미슐랭 스타 셰프도 실제로 전자레인지를 높이 평가함. Marco Pierre White는 전자레인지를 “놀라운 물건”이라 부르며 청어 요리에는 삶거나 굽는 것보다 낫다고 했음: https://www.independent.co.uk/life-style/marco-pierre-white-...
      José Andrés도 전자레인지 오믈렛을 가장 실패하기 어려운 요리로 꼽으며 “인류 역사상 최고의 폭신한 오믈렛”이라고 불렀음: https://www.tasteofhome.com/article/jose-andres-microwave-om...
    • 더 정확한 비유는 Charles와 Henry Greene이 Gamble House에 넣을 섬세한 보석함의 이음새를 고정하려고 기술로 정교한 전용 치구를 만드는 모습임. 손으로 만들 수도 있지만 만들 것이 많은 사람에게 시간은 귀중함
      Tao 같은 거장들은 기술이 그 치구를 만들 수 있음을 보여주고, 기계 제작자들은 보석함용 치구뿐 아니라 치구 제작 기계를 만드는 치구까지 만들 수 있음을 단계적으로 증명하고 있음
    • 초기 전자레인지 즉석식품을 접한 당대의 위대한 셰프들이 남긴 글이나 반응이 있는지 궁금함
    • 전자레인지가 처음 나왔을 때 셰프들도 진심으로 흥분했을 것 같음. 적어도 처음 보면 거의 마법처럼 느껴짐

  • 수학·물리학 분야의 오래된 교육용 Java 애플릿을 실행하는 일은 WebAssembly를 통해 브라우저에서 Java 바이트코드를 구동하는 CheerpJ Applet Runner의 오랜 인기 용도였음
    에이전트가 제대로 현대화해 이 문제를 해결하는 상황을 어떻게 받아들여야 할지 복잡함. 학생들이 현대적이고 접근성 높은 방식으로 콘텐츠와 상호작용할 수 있는 건 분명 좋지만, 상업적으로 중요하지 않더라도 교육 분야 활용은 늘 자부심의 원천이었음: https://chromewebstore.google.com/detail/cheerpj-applet-runn...

  • 분야 전문가가 AI로 자기 분야의 무언가를 재미있게 만드는 글은 늘 즐겁지만, 항상 취미 프로젝트이고 진지한 작업은 아닌 듯함

    • Terry Tao는 최첨단 수학적 발견에 AI를 활용하는 방안을 탐구해 온 수학계의 대표적인 인물 중 하나임. 이번 글은 가벼운 편이지만 핵심 연구에서의 AI 지원에 관해서도 많이 썼음
      https://terrytao.wordpress.com/tag/artificial-intelligence/, https://academy.openai.com/public/blogs/terence-tao-ai-is-re...
    • 대학 교수에게 교육 자료 개발은 업무의 일부인데, 왜 이를 취미 프로젝트라고 보는지 모르겠음
    • 업무에서 Claude Code를 쓰기 시작해 보니, 길어도 5년 안에 현재 형태의 코딩은 진로로서 사라질 가능성이 커 보임
      나는 나이가 있고 필요하면 빠듯하게나마 내일 은퇴할 수도 있지만, 아직 일하지 않고 버틸 자산을 쌓지 못한 25세 조카 같은 젊은 개발자들이 걱정됨. 코드를 직접 작성하는 일은 손으로 제곱근을 계산하거나 활자를 주조하는 일처럼 극소수만 하는 전문 영역이 될 것임
    • “항상”과 “절대”는 지나치게 강한 표현임. 내년 이맘때면 상당히 진지한 AI 활용을 보게 되어 더는 그렇게 말하기 어려울 것이라 예상함
      AI 코딩의 광범위한 활용은 이제 막 시작됐고 모델도 최근에야 진지한 작업이 가능한 수준에 도달함. 이미 실제 활용을 봤지만, 조직 정책·비공개 코드·영업 비밀 때문에 개인 블로그에서 운영 코드 활용을 공개하기 어려운 이유도 많음
    • Tao는 AI를 형식 검증 수학과 수학 문제 해결 아이디어에도 사용하고 있음. 보조 자료라 괜찮다는 말은 해당 시각화가 형식 검증되지 않아 버그가 있을 수 있다는 뜻이며, 논문의 핵심이 아니므로 AI를 별도로 기여자로 표기하지 않아도 된다는 의미일 수도 있음

  • “코드 복잡도가 감당할 수 없을 만큼 커져 프로젝트를 포기했다”는 대목에서 웃었음. Terry Tao조차 너무 복잡해서 작성하지 못하는 코드가 있음
    특정 분야에서는 매우 똑똑하지만 코딩에 진입하지 못했던 많은 사람까지 LLM이 소프트웨어 개발에 참여하게 만들 것이라 크게 기대함

  • Claude로 30년 된 고등학교 독일어 Java 애플릿 게임을 JavaScript로 이식하고, 가짜 Git 이력까지 만들었음: https://github.com/bradfitz/koffer#der-verloren-koffe
    온라인에서도 실행할 수 있음: https://bradfitz.github.io/koffer/js/
    약 30년 전 코드가 다시 살아 움직이는 모습이 멋짐

  • 글의 어색한 첫 문장이야말로 AI가 쓰지 않았다는 증거임. “1999년 Java 1.0으로 복소해석학과 선형대수학 수업용 애플릿을 만들며 벌집 구조나 Besicovitch 집합 같은 수학적 대상을 시각화한 때부터, 기계의 도움으로 수학을 연구하고 가르치는 방법에 관심을 가져왔다”는 문장임

    • 매우 Terence Tao다운 문체임. 짧게 나눌 수 있는 문장을 길게 이어 쓰지만, 독해에는 별다른 영향을 주지 않음
    • 이런 문체가 Claude가 매끈하게 다시 써낸 무미건조한 결과물보다 언제나 나음
답변달기