마이크로컨트롤러 수업에서 강사가 칠판에 8비트 컴퓨터의 레지스터, 메모리, 명령어를 직접 그려가며 설명했는데, 내부 작동 방식을 이해하는 재미가 컸음
가르친 내용을 더 많이 시뮬레이션할 수 있으면 좋겠다고 생각했음. 교육은 대상을 구성 요소로 분해하고 상호작용을 살펴보는 과정이므로, 바이브 코딩한 시뮬레이션이 훌륭한 도구가 될 수 있음

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

AI가 모두를 최고 수준으로 끌어올릴 줄 알았는데, 오히려 최고들을 우리 손이 닿는 수준으로 내려놓은 셈임

반대로 코딩 에이전트가 Terry Tao에게 자신이 작업하려는 증명이 필즈상을 받을 만한지 묻는 날을 기다리고 있음

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

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

LLM 에이전트의 결과는 늘 검증해야 하지만, AI를 의인화하지 말라고 하면서 신뢰라는 의인화된 표현을 쓰는 건 조금 재미있음. 모델과 실행 도구가 개선되고 효과적인 작업 흐름이 정립되면서 AI에 대한 신뢰는 빠르게 높아지고 있음
망치는 못에는 믿고 쓰지만 나사에는 쓰지 않는데, 그렇다고 망치를 일반적으로 신뢰할 수 없다고 하지는 않음. AI의 어려움은 무엇이 못이고 나사인지 아직 모른다는 데 있음
단순히 믿지 말라고 하기보다 이전보다 계획·반복·검토에 더 많은 시간을 써야 하고, 기술·맥락·하위 에이전트 활용법을 익히며, 먼저 비운영·저위험 프로젝트에서 연습하라고 안내하는 편이 유용함. 좋은 작업 흐름과 적합한 용도를 이해하면서 신뢰를 쌓는 게 목표여야 함

이 맥락에서 신뢰가 무엇인지 모르겠음. Donald Knuth를 고용해 모든 코드를 작성하게 해도 버그가 없거나 내 요구에 적합하다고 믿지는 않을 것임

AI 낙관론자 중에는 Tao가 수학적 증명에서 LLM을 활용한 발언을 근거로, 이미 시스템이 매우 발전했고 자율적으로 작동한다고 강하게 보는 이들이 많음

LLM은 유지보수하기 어렵고 신뢰할 수 없는 끔찍한 코드를 만들어냄. 개인용 장난감 같은 저위험 프로젝트를 바이브 코딩하는 건 괜찮지만, 위험도가 높은 코드에는 분명 적합하지 않음

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

더 정확한 비유는 Charles와 Henry Greene이 Gamble House에 넣을 섬세한 보석함의 이음새를 고정하려고 기술로 정교한 전용 치구를 만드는 모습임. 손으로 만들 수도 있지만 만들 것이 많은 사람에게 시간은 귀중함
Tao 같은 거장들은 기술이 그 치구를 만들 수 있음을 보여주고, 기계 제작자들은 보석함용 치구뿐 아니라 치구 제작 기계를 만드는 치구까지 만들 수 있음을 단계적으로 증명하고 있음

초기 전자레인지 즉석식품을 접한 당대의 위대한 셰프들이 남긴 글이나 반응이 있는지 궁금함

전자레인지가 처음 나왔을 때 셰프들도 진심으로 흥분했을 것 같음. 적어도 처음 보면 거의 마법처럼 느껴짐

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

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

대학 교수에게 교육 자료 개발은 업무의 일부인데, 왜 이를 취미 프로젝트라고 보는지 모르겠음

업무에서 Claude Code를 쓰기 시작해 보니, 길어도 5년 안에 현재 형태의 코딩은 진로로서 사라질 가능성이 커 보임
나는 나이가 있고 필요하면 빠듯하게나마 내일 은퇴할 수도 있지만, 아직 일하지 않고 버틸 자산을 쌓지 못한 25세 조카 같은 젊은 개발자들이 걱정됨. 코드를 직접 작성하는 일은 손으로 제곱근을 계산하거나 활자를 주조하는 일처럼 극소수만 하는 전문 영역이 될 것임

“항상”과 “절대”는 지나치게 강한 표현임. 내년 이맘때면 상당히 진지한 AI 활용을 보게 되어 더는 그렇게 말하기 어려울 것이라 예상함
AI 코딩의 광범위한 활용은 이제 막 시작됐고 모델도 최근에야 진지한 작업이 가능한 수준에 도달함. 이미 실제 활용을 봤지만, 조직 정책·비공개 코드·영업 비밀 때문에 개인 블로그에서 운영 코드 활용을 공개하기 어려운 이유도 많음

Tao는 AI를 형식 검증 수학과 수학 문제 해결 아이디어에도 사용하고 있음. 보조 자료라 괜찮다는 말은 해당 시각화가 형식 검증되지 않아 버그가 있을 수 있다는 뜻이며, 논문의 핵심이 아니므로 AI를 별도로 기여자로 표기하지 않아도 된다는 의미일 수도 있음

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

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

매우 Terence Tao다운 문체임. 짧게 나눌 수 있는 문장을 길게 이어 쓰지만, 독해에는 별다른 영향을 주지 않음