요약
Cuis는 단순함과 강력함을 목표로 삼은 무료 Smalltalk-80 개발 환경입니다.
Cuis 공식 사이트의 소개입니다. 후안 불레티치와 커뮤니티가 함께 만들며, 어떤 플랫폼으로도 옮길 수 있고 빠르고 효율적이라는 점도 내세웁니다.
왜 중요한가
- Smalltalk-80 계열이 올해도 새 안정판과 정기 모임으로 이어지고 있습니다.
- 코드 에이전트로 데스크톱을 다시 설계한 Blueprint 발표처럼 새로운 개발 방식도 시험하고 있습니다.
핵심 내용
- 6월 1일에 안정판 Cuis 7.8이 나왔습니다.
- 개발 환경에는 인스펙터(객체 내부를 들여다보는 도구), 자동 완성, 클래스 브라우저가 들어 있습니다.
- 사이트 화면에서는 벡터 그래픽, SVG, TrueType 글꼴, 유니코드 지원을 보여 줍니다.
- 10월 14~16일 아르헨티나 로사리오에서 열린 Smalltalks 2026에는 Cuis 관련 발표가 8건 잡혀 있었습니다.
- 앨런 케이와 댄 잉걸스, 존 말로니가 2007년에 남긴 호평도 사이트에 실려 있습니다.
HN 반응
- Squeak에서 갈라져 군더더기를 덜어 낸 덕분에 시스템 전체를 이해하기 쉽다는 호평이 많았고, 라이브러리가 부족하다는 지적도 있었습니다.
- 토론은 Smalltalk가 어린이 교육용에서 출발한 역사와, 상속이 객체 지향의 핵심인지를 둘러싼 논쟁으로도 번졌습니다.
Squeak, Pharo와 같은 VM이라 속도는 똑같이 빠릅니다. 라이브러리가 조금 부족하긴 하지만, 저한테는 오픈 소스에 기여할 기회이기도 합니다.
지금은 (Pocketbase와 lighttpd를 곁들여) 대부분 정적인 웹사이트를 Cuis로 만들고 있습니다. 전반적으로 경험이 좋습니다.
이런 걸 안 쓴 지 한참 됐는데요.
이거 포크인가요? Squeak나 Pharo와 비교해 Cuis의 가장 큰 장점은 뭔가요?
제가 알기로 Cuis는 Squeak에서 갈라져 나온 환경이고, "잡동사니"를 전부 걷어냈습니다. 말하자면 Squeak을 덜어낸 버전입니다. Pharo도 처음에는 Squeak을 덜어낸 버전이었고요.
저는 다른 어떤 Smalltalk(Squeak, Pharo, VA, Dolphin)보다 Cuis에서 일을 끝내기가 더 쉽고 빨랐습니다.
UI 때문인가요, 라이브러리 때문인가요? API가 더 쓰기 편한가요?
Cuis는 현대 Smalltalk로 들어가는 가장 쉬운 입구입니다. 다른 것들은 하나같이 엄청나게 많은 것이 들어 있습니다(좋은 것들이긴 한데, 양이 많습니다). Cuis는 최소한만 남기고 덜어내는 방식을 택했습니다. 위에서 아래까지 전부 꽤 쉽게 이해할 수 있습니다.
역사 링크에 자세한 설명이 있지만, 간단히 비유하자면 이렇습니다.
Pharo와 Cuis는 거의 같은 시기에 Squeak에서 갈라져 나왔습니다.
Squeak = Debian
Pharo = Arch
Cuis = Alpine
Cuis는 철저하게 단순화했기 때문에, 시스템이 그만큼 작아서 탐색하고 이해하기가 훨씬 쉽습니다.
Cuis가 Morphic을 다시 설계한 방식은 정말 훌륭합니다. 모든 것이 하드웨어 가속 벡터 그래픽입니다. 글꼴까지도 그렇게 그립니다. 그래서 확대하든 축소하든 회전시키든 선명함이 유지됩니다.
그래도 Pharo에도 멋진 게 있습니다. fuel(객체 직렬화)과 soil(완전한 객체 지향 데이터베이스)을 Cuis로 이식하면 좋겠습니다. 그리고 가장 큰 것, seaside도요.
하지만 둘 중 하나만 골라야 하는 문제는 아닙니다. 한쪽에서 배우고 하는 것의 99%는 다른 쪽에도 그대로 적용됩니다. 다만 이제 막 시작한다면 저는 단연 Cuis를 추천합니다(Cuis를 계속 쓰지 않을 거라는 뜻은 아닙니다).
Cuis의 렌더링이 정말 하드웨어 가속인가요? 보기 좋은 건 맞는데, 전부 CPU로 하는 소프트웨어 렌더링이라고 알고 있었어요.
처음 시제품은 순수하게 이미지 안에서 도는 Smalltalk로 구현했는데, 이를 처리하는 VM 플러그인이 실사용된 지 벌써 1년이 훨씬 넘었습니다.
개발 경험이 요즘 AI 지원 워크플로와 잘 맞나요? 코딩 에이전트 덕분에 소프트웨어 프로젝트를 가지고 놀기 위한 진입 장벽이 크게 낮아졌고, 저도 궁금했던 Smalltalk 관련 재미있는 아이디어가 몇 가지 있거든요.
그렇다는 댓글을 봤어요. 코딩 에이전트가 실행 중인 환경을 직접 수정할 수 있다는 건 판을 바꿀 만한 일인데, 저도 아직 제대로 감이 오지는 않네요.
AI는 제 취향은 아니지만, 어쨌든요. 매달 온라인으로 "멋진 작품 보여주기" 모임이 열리는데, 가장 최근 모임은 어떤 분이 AI로 Cuis 안에 GNOME 데스크톱 비슷한 자기만의 Morphic 세계를 만든 이야기였어요.
https://youtu.be/HPcCg66tdrM?is=ErVqY5BvzofE9uQ4
VM을 공유한다는 건 좋은 장점이죠. 특히 성능이 주된 트레이드오프가 아니라면요.
저는 거의 20년 전에 처음 배운 프로그래밍 언어가 Ruby였습니다. 나중에 Seaside 덕분에 인기를 얻던 Smalltalk를 접했을 때는 문법이 훨씬 깔끔하고 쉬워서 믿기지 않을 정도였습니다. 하지만 이미지 모델은 받아들이기 힘들었고, 그걸 활용할 수 있는 사람들에게는 최대 장점이라는데도 저는 끝내 감을 잡지 못했습니다. GUI가 독자적인 세계라서 제가 쓰던 시스템과 이질적으로 느껴지는 것도 늘 싫었습니다. 예전에 문법을 조금 확장한, Coral이라는 이름이었던 것 같은 헤드리스 버전이 있었고, 다른 스크립트 언어처럼 셸에서 평범하게 쓸 수 있었던 걸로 압니다. 지금도 남아 있는지는 모르겠지만, 더 대중적이고 접근하기 쉬운 언어가 되도록 이 길을 더 탐구하거나 밀어붙이지 않은 것이 저는 늘 의아했습니다.
멋지고 아름다워 보여요! 다른 Smalltalk들은 봐도 꽤 주눅이 들었는데, 이건 멋지면서도 반겨 주는 느낌이네요.
Scratch 1.4에서 쓰이는 걸 본 뒤로는 Smalltalk 소식을 한 번도 못 들었는데, 이렇게 오랜만에 다시 마주치니 반갑네요.
여기서 나온 슬라이드와 발표를 공개할지 궁금하네요.
https://smalltalks2026.fast.org.ar/talks
대부분 모르는 사실인데, Smalltalk는 원래 어린이 교육용 언어였고 Logo와 같은 시기의 동료 격입니다. (이전 댓글들에서 알게 됐는데) Logo가 더 먼저 나왔다고 하더군요.
"Smalltalk는 순수한 객체 지향 프로그래밍 언어로, 1970년대에 교육용, 특히 구성주의 학습을 위해 만들어졌지만 나중에는 비즈니스에서도 쓰이게 되었다."
https://en.wikipedia.org/wiki/Smalltalk
Smalltalk의 핵심 개발자 중 한 명인 앨런 케이는 Smalltalk가 시스템을 만드는 아이디어를 부트스트래핑하는 데 좋다는 점도 높이 평가받았다고 말했습니다. 그는 이 강연의 58:50부터 그 주제를 다룹니다.
앨런 케이, OOPSLA 1997 - 컴퓨터 혁명은 아직 일어나지 않았다 https://www.youtube.com/watch?v=oKg1hTOQXoY&t=3530s
“제가 보기에 Smalltalk가 제록스 PARC를 벗어나 세상에 나왔을 때 일어난 가장 안타까운 일은, 여러 면에서 사실상 변화가 멈췄다는 것입니다. 제록스 PARC에서는 약 10년 동안 주요 버전이 네 개, 완전히 다른 버전의 언어가 있었습니다. 그리고 그 버전들 안에서도 의미 있는 릴리스가 수십, 수십 번 있었습니다. 우리가 Smalltalk에서 가장 좋아했던 점은 그것이 할 수 있는 일이 아니라, 시스템을 만드는 방법에 대한 다음 세대의 아이디어를 부트스트래핑하기에 아주 좋은 수단이었다는 사실이라고 생각합니다. 그런데 Smalltalk가 상업화되면서 그것이 사실상 끝나 버렸습니다. 아델과 데이브가 쓴 그 유명한 블루 북에 Smalltalk 인터프리터를 만들고 이 과정을 직접 시작할 수 있는 실제 코드가 들어 있었는데도, 그것을 활용한 사람은 거의 없었습니다. 활용한 대학도 거의 없었고, 활용한 상업 기관도 거의 없었습니다. 그들이 놓친 것은, 제가 오늘 여러분께 전하고 싶은 가장 깊은 이야기인데, 우리는 아직 시스템을 어떻게 설계해야 하는지 모른다는 것입니다. 그러니 제발 우리가 모르는 것을 종교로 만들지 맙시다. 우리에게 필요한 것은 무엇이 중요한지 끊임없이 생각하고 또 생각하는 일입니다. 그리고 우리의 시스템은 다음 단계의 추상화에 다다랐을 때 우리를 그곳으로 데려가 주어야 합니다. 제가 Smalltalk에 대해 가장 자랑스러워하는 것, 제 입장에서는 거의 유일하게 자랑스러운 것은, 세상에 나오기 전까지 자기 이전 버전을 없애는 데 아주 뛰어났다는 점입니다. 우리가 Smalltalk 작업에 다시 뛰어든 이유 중 하나는, 저는 16년 동안 프로그래밍 언어 작업을 하지 않다가 몇 년 전에 Squeak이라고 부르는 프로젝트를 시작했는데, 이것은 세상에 공짜 Smalltalk를 선물하려는 시도가 아니라 Smalltalk보다 훨씬 나은 무언가를 위한 부트스트래핑 메커니즘을 선물하려는 시도입니다. 그러니 Squeak을 만지작거릴 때는 부디 부디 그런 관점에서... 이 망할 물건 스스로의 메커니즘을 이용해 다음 버전을 만들어서 이것을 어떻게 구식으로 만들 수 있을지 생각해 보십시오.”
원래 Smalltalk-72는 어린이 교육에 초점을 맞췄지만, Smalltalk-76을 만들 때는 앨런 케이와 댄 잉걸스가 원하는 바가 달랐습니다. 앨런은 계속 어린이에 초점을 두고 싶어 했고, 댄은 고급 프로그래머를 위한 언어 위에 어린이용 언어를 구현하면 된다고 주장했습니다. 수십 년 뒤 Smalltalk-76을 충실히 따른 Squeak Smalltalk 위에 EToys가, 이어서 Scratch가 구현되면서 댄이 옳았음이 입증되었습니다.
이런 혼란 때문에 저는 1981년 8월호 Byte 잡지에서 Smalltalk를 처음 읽었을 때 답답했습니다. 도무지 이해가 안 됐는데, 그때 이미 여러 프로그래밍 언어를 배운 상태였고 그중 어느 것도 웬만큼 능숙해지는 데 두 시간 넘게 걸린 적이 없었습니다. 그런데 아이들이 쓰는 언어를 두고 제가 애를 먹고 있었던 겁니다?!? 나중에 Smalltalk-72와 -80의 차이를 알게 됐고, Byte의 글들은 이미 아는 사람에게는 이해가 되지만 처음 배우는 사람에게는 도움이 안 되는 내용을 설명하고 있었다는 것도 알게 됐습니다. 그 뒤로 Smalltalk의 모든 변종은 제가 가장 좋아하는 프로그래밍 방식이 되었습니다.
또 스스로 순수한 객체 지향이라고 불렀는데도 초기 버전에는 상속이 없었죠.
요즘 객체 지향 프로그래밍은 거의 전적으로 상속 계층과 연결되어 있잖아요.
어쩌면 상속은 처음 구상했던 만큼 객체 지향의 중심이 아닌지도 모르겠어요.
중심이 아니에요. 객체 지향에 여러 갈래가 있다는 걸 모르는 쪽이 바로 OOP를 싫어하는 사람들이에요. 대개 한 가지 방식만 배워서, 당연히 전부 그런 줄 알죠.
원래 VB와 Self도 상속을 지원하지 않는 잘 알려진 사례예요.
또 The Art of the Metaobject Protocol에서 영감을 받은 Lisp 시스템 대부분은 구조체에 붙은 현재 동작을 바꿀 때 상속 대신 멀티메서드에 초점을 맞추는 경향이 있어요.
Self에도 상속이 있어요. 오히려 Smalltalk보다 훨씬 전면적으로 씁니다. 그리고 원래 VB는 객체 지향이 아니고요.
일부 프로토타입 기반 언어는 상속 대신 위임을 쓰기 때문에, Self도 그럴 거라고 생각하는 사람들이 있습니다. 차이는 미묘합니다. 하지만 말씀하신 대로이고, 마리오 월츠코가 말했듯이 "Self는 Smalltalk와 같되 그 성격이 더 강한 것"입니다. 상속도 위임도 없지만 그래도 공유하는 방식은 갖춘 언어들도 있었습니다.
프로토타입 기반 상속은 또 다른 문제예요.
원래 VB는 분명 OOP였어요. 특히 VB 4에서 VBX가 COM으로 대체된 뒤로는요.
저는 가끔 "싫어해요". 정확히는 OOP의 한 가지 맛, 보통 "모든 것은 클래스여야 한다"는 자바식 맛만 배운 사람들 때문에요. 그런 사람들은 모든 걸 그 스타일에 억지로 끼워 넣고, 상속이 꼭 있어야 한다고 우겨요. 이미 많은 사람이 "상속보다 합성"이라는 교훈을 얻었고, 비교적 최근에 나온 가장 인기 있는 언어 중 하나인 Rust는 상속도 클래스도 아예 없는데도요. "setter만 있으면 어디서든 전부 변경한다"는 스타일도 그렇고요.
그 교조적인 자바식 OOP, 그리고 디자인 패턴을 Python 같은 다른 언어로 1대 1로 옮기겠다며 언어의 특성과 설계상의 선택을 무시하는 발상까지... 하, 정말 골칫거리예요.
그럴 때 제 경계심이 올라가요. 그 사람이 OOP를 어떻게 이해하고 있는지, 그저 유행어만 던지는 건지 아니면 자기가 하는 말을 실제로 아는 건지 아주 면밀히 살피기 시작해요.
앨런 케이가 이 용어를 만든 이래로 그 뜻이 불분명해진 데서 비롯된 일이겠죠.
https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
이른바 OOP 언어를 쓸 때 저는 일부러 상속을 피해요. 사실 그게 OOP에서 가장 나쁜 부분이라고 생각하고요. 어쨌든 저는 객체 지향의 정의에 상속을 넣지 않는 편이에요.
18년 된 추천사라니, 귀여운 연출이네요.