스몰토크는 아직 살아있다, Squeak 6.1 릴리스로 돌아보는 '살아있는 프로그래밍'의 원조

2026년에 스몰토크(Smalltalk)의 새 버전 소식이라니, 낯설게 느껴지는 분들 많을 거예요. 오픈소스 스몰토크 구현체인 Squeak(스퀵)이 6.1 버전을 릴리스했거든요. "그 옛날 언어가 아직도 개발되고 있어?"라고 생각할 수 있는데요. 사실 여러분이 매일 쓰는 객체지향 프로그래밍, GUI, MVC 패턴, 심지어 테스트 주도 개발까지, 뿌리를 거슬러 올라가면 전부 스몰토크가 나와요. 그래서 이번 릴리스를 핑계 삼아, 이 살아있는 화석 같은 환경이 대체 뭔지 한번 풀어보려고 해요.

스몰토크가 뭐냐면

스몰토크는 1970년대 제록스 PARC 연구소에서 앨런 케이 팀이 만든 언어예요. "모든 것은 객체다"라는 말을 진짜 문자 그대로 구현한 언어인데요. 숫자 3도 객체고, 클래스도 객체고, 심지어 if문 같은 제어문조차 별도 문법이 아니라 불리언 객체에 메시지를 보내는 방식으로 동작해요. 객체끼리 '메시지'를 주고받으며 프로그램이 굴러간다는 개념이 여기서 나왔고, 이게 이후 거의 모든 객체지향 언어의 원형이 됐어요. 참고로 우리가 아는 GUI, 그러니까 겹치는 창과 메뉴가 있는 화면도 스몰토크 환경에서 처음 만들어졌고, MVC 패턴도 스몰토크에서 태어났어요.

'이미지'라는 독특한 세계

스몰토크에서 제일 신기한 부분은 '이미지 기반 개발'이에요. 이게 뭐냐면요, 우리가 아는 개발은 소스 파일을 편집하고, 빌드하고, 실행하는 과정을 반복하잖아요. 스몰토크는 다르게, 프로그램 코드와 개발 도구와 실행 중인 객체들의 상태가 전부 '이미지'라는 하나의 파일 안에 통째로 들어있어요. 게임의 세이브 파일처럼 환경 전체를 저장했다가 그대로 다시 여는 거죠. 그래서 프로그램을 끄지 않은 채로 실행 중에 코드를 고칠 수 있어요. 에러가 나면 디버거가 뜨는데, 그 자리에서 문제의 메서드를 고치고 '계속 진행'을 누르면 죽었던 프로그램이 살아나서 이어서 돌아가요. 요즘 프론트엔드의 핫 리로드나 REPL 중심 개발이 신기하다면, 스몰토크는 이걸 50년 전에 훨씬 급진적인 형태로 하고 있었던 거예요.

Squeak은 어떤 프로젝트인가

Squeak은 1996년 애플에 있던 앨런 케이 팀이 원조 스몰토크를 부활시켜 오픈소스로 공개한 구현체예요. 이후 30년 가까이 커뮤니티가 꾸준히 유지보수해왔고, 어린이 코딩 교육의 상징인 Scratch 초기 버전도 Squeak 위에서 만들어졌어요. 연구와 산업 쪽으로는 Squeak에서 갈라져 나온 Pharo라는 현대적인 포크도 활발하게 개발되고 있고요. 이번 6.1은 혁신적인 신기능을 쏟아내는 릴리스라기보다 최신 운영체제 호환성과 안정성을 다듬는 성격이 강한데, 반세기 된 시스템이 지금도 macOS와 윈도우, 리눅스에서 잘 돌아가도록 관리되고 있다는 것 자체가 대단한 일이죠.

스몰토크가 남긴 유산

스몰토크 커뮤니티가 소프트웨어 공학에 남긴 흔적은 생각보다 커요. 켄트 벡이 테스트 주도 개발(TDD)과 익스트림 프로그래밍을 다듬은 무대가 스몰토크였고, 최초의 단위 테스트 프레임워크 SUnit이 JUnit의 원형이 됐어요. 리팩토링이라는 개념과 최초의 리팩토링 도구도 스몰토크에서 나왔고, 워드 커닝햄이 만든 최초의 위키도 스몰토크 문화권의 산물이에요. 언어 쪽으로 보면 Ruby와 Objective-C가 스몰토크의 직계 후손이고, '객체는 메시지를 주고받는다'는 관점은 Erlang의 액터 모델 같은 동시성 패러다임과도 맞닿아 있어요.

한국 개발자에게는

솔직히 말하면 실무에서 스몰토크를 쓸 일은 거의 없을 거예요. 하지만 한 번쯤 Squeak 이미지를 내려받아서 만져보는 경험은 추천하고 싶어요. 실행 중인 시스템 전체를 열어보고, 브라우저로 클래스를 뒤지고, 디버거 안에서 코드를 고쳐가며 개발하는 감각은 다른 어디서도 얻기 어렵거든요. 우리가 당연하게 쓰는 도구들이 어떤 사상에서 나왔는지 알게 되면, 지금 쓰는 언어와 IDE를 보는 눈도 달라져요. 면접에서 객체지향을 설명할 때 "메시지 패싱"의 원래 의미를 이야기할 수 있게 되는 건 덤이고요.

정리하면

Squeak 6.1은 단순한 레거시 유지보수가 아니라, 컴퓨팅 역사에서 가장 급진적이었던 아이디어가 아직 살아 숨 쉰다는 증거예요. 여러분은 '실행 중인 프로그램을 멈추지 않고 고치는' 개발 방식, 매력적으로 들리시나요? 아니면 파일과 빌드가 명확히 분리된 지금 방식이 더 낫다고 보시나요?