소닉파이 개발자 샘 애런, 라이브 코딩과 Tau5 개발에서 얻은 AI 에이전트 활용 교훈

핵심 메시지

• 샘 애런은 프로그래밍이 업무 도구로만 인식되는 사회적 통념을 바꾸고, 읽고 쓰기처럼 인간 표현의 수단으로 자리잡아야 한다고 주장한다.
• 라즈베리파이 교육용으로 2주 만에 만든 소닉파이는 '연주(play)'와 '쉬기(sleep)' 두 함수에서 출발해 아이들의 질문에 맞춰 매주 기능을 붙여 나갔다.
• 교육과정에 동시성이 없다는 이유로 가르칠 수 없게 되자, 그는 이름만 바꾼 'live loop'를 만들어 아이들이 동시성을 자연스럽게 쓰게 했다.
• 후속 프로젝트 Tau5는 얼랭·엘릭서 백엔드와 브라우저 프런트엔드를 결합하고, 샌드박스된 Lua에 MCP 서버를 붙여 AI 에이전트가 시스템을 조작할 수 있게 했다.
• 그는 LLM이 항상 자신을 속이려 한다고 가정하고 코드를 반드시 읽으며, 방향이 어긋나면 되돌리지 말고 지워버리는 방식으로 작업했다고 말한다.

쉽게 이해하기

강연은 강연자가 직접 코드로 음악과 영상을 만들어 내는 라이브 공연으로 시작한다. 그가 사용한 소프트웨어는 무료 오픈소스인 소닉파이(Sonic Pi)로, 원래 무대 공연이 아니라 아이들에게 코딩을 가르치려고 만든 도구다. 샘 애런은 프로그래밍에 대한 사회적 인식이 완전히 잘못돼 있다고 말한다. 영화 속 해킹 장면이 우스꽝스러운 것도, 파티에서 '프로그래머'라고 소개하면 주변이 조용해지는 것도 같은 문제라는 것이다.

그는 읽고 쓰기를 법률 문서와 종교 문헌에만 쓰는 세상을 상상해 보라고 묻는다. 프로그래밍이 주로 비즈니스 용도로만 쓰이는 현실도 마찬가지라는 것이다. 그의 작업은 프로그래밍을 인간 표현의 도구로 확장하려는 시도이며, 그 계보는 배비지의 해석기관을 보고 음악을 만드는 악기를 상상했던 에이다 러브레이스까지 거슬러 올라간다고 그는 설명한다.

소닉파이는 케임브리지 대학에서 라즈베리파이가 나오던 시기에 시작됐다. 석 달 안에 언어를 설계하고 학교와 교사를 찾아 수업 계획까지 만들어 평가해야 하는 일정이었다. 그래서 그는 2주 만에 만들 수 있는 가장 단순한 것을 목표로 삼았고, 첫 버전은 음을 연주하는 play와 기다리는 sleep 두 함수뿐이었다. 이후 아이들의 반응에 맞춰 매주 새 버전을 만들며 수업 진도와 기능을 함께 키워 나갔다.

가장 큰 어려움은 언어 설계가 아니라 아이들을 계속 흥미롭게 만드는 일이었다. 그 과정에서 상징적인 장면이 나온다. 한 학생이 두 개의 반복문을 겹쳐 쓰고 왜 드럼과 베이스가 동시에 들리지 않느냐고 물었지만, 동시성은 교육과정에 없어 가르칠 수 없다는 답이 돌아왔다. 그가 학생에게 열여덟 살이 되어 대학에 가면 배울 수 있다고 말하자 아이는 그 자리에서 흥미를 잃었다. 그는 교육 시스템을 바꾸기는 어려워도 프로그래밍 언어를 바꾸는 건 어렵지 않다며 'live loop'라는 새 반복문을 만들었고, 이름만 다를 뿐 아이들은 동시성 프로그램을 쓰게 됐다.

다음 단계로 그는 학교가 더 이상 앱 설치를 원하지 않고 웹 기반을 원한다는 현실, 그리고 예제 코드 저장소를 열려면 샌드박스가 필요하다는 보안 문제에 부딪혔다. 그 해법으로 얼랭·엘릭서 백엔드와 크롬 프런트엔드를 묶은 자체 구조를 만들고, 샌드박싱이 쉬운 Lua를 실행 언어로 택했다. 이 흐름에서 나온 것이 Tau5로, 하이드라 기반 비주얼과 크로미움 개발자 도구, 텔레메트리 대시보드, 엘릭서 REPL을 한데 담고 있다.

AI 에이전트는 이 개발 과정에서 등장한다. 그는 한동안 관심을 두지 않다가 클로드 코드의 오푸스 4를 써 보고 쓸 만하다고 판단했고, Lua 샌드박스에 MCP 서버를 붙여 에이전트가 코드를 실행하게 했다. 이어 DOM 읽기, 자바스크립트 평가, 네트워크 정보, 로그 접근까지 도구를 늘리자 개발 속도가 크게 올라갔다. 다만 이 개발용 MCP 서버는 제품 버전에서 모두 제거되며, 에이전트는 리눅스 가상머신 안에서만 돌린다고 그는 못 박는다. 로컬 머신에서 직접 돌리는 것은 위험하니 그만두라는 것이다.

가장 어려웠던 작업은 30년 된 C++ 신시사이저 슈퍼콜라이더를 웹 오디오 워클릿으로 옮기는 일이었다. 브라우저의 제약 때문에 스레드 생성도, 메모리 할당도, main 진입점도, 심지어 출력조차 쓸 수 없었다. 그는 이를 '속이 보이지 않는 병 안에서 배를 조립하는 일'에 비유하며, LLM의 도움으로 겨우 해냈다고 말한다. 동시에 그는 LLM이 늘 자신을 속이려 한다고 가정해야 하고, 산출된 코드를 반드시 읽어야 하며, 조금이라도 방향이 어긋나면 되돌리려 하지 말고 지우고 다시 시작하는 편이 낫다는 교훈을 남긴다.

주요 인사이트

• 교육과정이라는 제약을 정면으로 부수는 대신 언어 설계로 우회한 'live loop' 사례는, 도구 제작자가 가진 힘이 어디에 있는지 보여준다.
• 동시성이 어려운 이유는 개념 자체가 아니라 가변 상태를 다루는 언어 설계 탓이라는 주장은, 밴드 연주 비유로 설명될 만큼 직관적이다.
• 어린이 코드 저장소의 보안 문제와 AI 에이전트의 샌드박싱 문제가 결국 같은 설계로 풀린다는 관찰은 실용적인 통찰이다.
• 에이전트에게 시스템 내부를 들여다볼 수단(로그·DOM·런타임)을 더 많이 줄수록 유용성이 올라갔다는 경험은 도구 설계에 시사점을 준다.
• '형식은 있으나 내용이 없다'는 표현으로 LLM 생성물과 자신의 연주를 구분한 대목은, 창작에서 AI를 어디까지 쓸지에 대한 하나의 기준선을 제시한다.
• LLM이 동시성 버그를 타이머로 '고쳐' 놓은 일화는, 코드를 읽지 않으면 통과해 버릴 수 있는 오류의 전형이다.

자주 묻는 질문

관련 AI 소식