2025년 6월 27일·7분
앨런 케이의 핵심 아이디어: Smalltalk, GUI와 소프트웨어 시스템
Alan Kay의 Smalltalk과 초기 GUI 뒤에 숨은 핵심 아이디어와 그것들이 어떻게 소프트웨어를 상호작용하는 객체들의 시스템으로 보는 관점을 형성했는지 살펴봅니다.
Alan Kay의 Smalltalk과 초기 GUI 뒤에 숨은 핵심 아이디어와 그것들이 어떻게 소프트웨어를 상호작용하는 객체들의 시스템으로 보는 관점을 형성했는지 살펴봅니다.
앨런 케이는 단순한 프로그래밍 역사 속 이름이 아닙니다. 우리가 컴퓨터에 대해 갖는 많은 일상적 가정—“창(window)”이 무엇인지, 소프트웨어가 왜 대화형이어야 하는지, 프로그램을 협력하는 부분들의 집합으로 어떻게 구성할지—는 그가 (제록스 PARC의 팀들과 함께) 밀어붙인 아이디어들에 의해 형성되었습니다.
이 글은 잡다한 지식이 아닌 개념에 관한 글입니다. 코드를 알 필요도 없고, 희귀한 기술적 세부 사항을 둘러보는 글도 아닙니다. 대신, 소프트웨어를 이해, 변경, 학습하는 방식에 계속 등장하는 몇 가지 사고 모델에 집중할 것입니다.
첫째, Smalltalk: 단순한 프로그래밍 언어가 아니라 탐구와 학습을 장려하는 통합 작업 환경이었습니다.
둘째, GUI(그래픽 사용자 인터페이스): 창, 아이콘, 메뉴—명령을 지시하는 대신 직접 조작하는 대화형 소프트웨어.
셋째, 시스템 사고: 소프트웨어를 코드 파일의 더미가 아니라 피드백 루프를 가진 상호작용하는 부품들의 집합으로 보는 관점입니다.
케이를 고독한 천재로 미화하지도 않을 것이고, 하나의 ‘정답’ 패러다임이 모든 것을 해결한다고 주장하지도 않을 것입니다. 어떤 아이디어는 훌륭하게 작동했고, 어떤 것은 오해받았으며, 어떤 것은 충분히 널리 퍼지지 못했습니다.
목표는 실용적입니다: 글을 읽고 나면 현대 앱과 코드베이스를 볼 때 ‘왜 그렇게 느껴지는지’가 더 명확해지고, 다음 프로젝트에 무엇을 빌려올 수 있을지 판단하는 감을 갖게 될 것입니다.
앨런 케이는 힘은 있지만 비싸고 일반 사람들에게는 무관심했던 컴퓨팅 문화 속으로 들어갔습니다. 당시 컴퓨터는 공유 인프라처럼 다뤄졌습니다: 시간을 예약하고 작업을 제출한 뒤 결과를 기다렸습니다. 그 모델은 모든 것을 규정했습니다—프로그램의 형태, 누가 사용할 수 있는지, 그리고 ‘성공’이 무엇인지까지.
많은 사용자에게 컴퓨팅은 기계에 작업을 넘기고(종종 펀치카드나 대기열 터미널을 통해) 나중에 출력물을 받는 과정이었습니다. 무언가 잘못되면 탐색하거나 직접 살펴보지 못했고, 다시 제출하고 또 기다려야 했습니다. 탐구는 느렸고, 컴퓨터는 생각을 돕는 도구라기보다 원격 서비스 같았습니다.
케이의 목표는 단순히 ‘더 작은 컴퓨터’가 아니었습니다. 그것은 다른 관계였습니다: 컴퓨터를 어린이와 비전문가도 아이디어를 탐구하고 쓰고 시뮬레이션하고 그리며 만들 수 있는 개인 매체로 만드는 것. 이를 위해서는 즉시성이 필요했습니다. 사용자는 자신의 행동이 어떤 결과를 내는지 즉시 보고 빠르게 수정하며 창작의 흐름을 유지해야 했습니다.
그런 변화를 추구하려면 하드웨어, 소프트웨어, 상호작용 설계를 함께 실험할 공간이 필요했습니다. 제록스 PARC 같은 연구소는 새로운 디스플레이, 새로운 입력 장치, 새로운 프로그래밍 모델을 장기 베팅으로 펀딩했습니다. 목표는 기능을 하나 출시하는 것이 아니라 새로운 컴퓨팅 사용 방식을 발명하는 것이었습니다.
컴퓨터가 학습 및 창작 기계가 되려면 사용성은 사후 고려가 될 수 없습니다. 인터페이스는 발견, 피드백, 이해 가능한 동작을 지원해야 합니다. 그 초점은 케이를 소프트웨어의 ‘상호작용 감각’—클릭, 편집, 탐색할 때 무엇이 일어나는지—이 소프트웨어 구조와 긴밀히 연결된 시스템으로 이끌었습니다.
앨런 케이는 ‘사무 작업을 더 빠르게 하는 법’으로 시작하지 않았습니다. 그는 다른 질문에서 시작했습니다: 어린이가 책처럼 휴대할 수 있는 개인용 컴퓨터를 가지고 아이디어를 탐구하고 만들며 경험으로 배우면 어떨까? 그 생각이 다이나북이었고, 제품 사양이라기보다 개인용 컴퓨팅의 북극성 같은 개념이었습니다.
다이나북은 경량이고 배터리로 구동되며 항상 이용 가능하다고 상상되었습니다. 하지만 가장 중요한 단어는 ‘휴대성’이 아니라 ‘개인적(personal)’이라는 점이었습니다. 이 컴퓨터는 노트나 악기처럼 사용자에게 속하는 것이어야 했습니다—단순히 조작하는 것이 아니라 시간이 지나며 사용자가 형태를 만들어가는 도구이어야 했습니다.
동일하게 중요한 것은 ‘학습 가능성’이었습니다. 케이의 목표는 메뉴 뒤에 컴퓨팅을 숨기는 것이 아니라 사람들이 점차적으로 저자가 되도록 하는 것이었습니다.
다이나북의 ‘킬러 앱’은 읽기, 쓰기, 그리기, 음악 작곡, 과학 실험 시뮬레이션, 상호작용 스토리 만들기 등이었습니다. 프로그래밍을 전문가 전용의 전문직이 아닌 또 다른 문해력 형태로 다루었습니다.
이 관점은 ‘좋은 소프트웨어’의 의미를 바꿉니다. 학습 도구는 만지작거리기를 초대하고, 빠른 피드백을 주며, 다시 시도하는 것이 안전하게 느껴지도록 설계되어야 합니다.
여기서 Smalltalk와 초기 GUI가 자리합니다. 사용자가 창작하도록 하려면 직접 조작, 즉각적인 결과, 실험이 자연스럽게 느껴지는 환경이 필요합니다. Smalltalk의 라이브한 인터랙티브 시스템과 GUI의 시각적 은유는 같은 목표를 지원했습니다: 아이디어와 작동하는 결과물 사이의 거리를 줄이는 것.
다이나북은 ‘태블릿을 예견’한 것이 아니라 컴퓨팅과의 새로운 관계를 제안한 것이었습니다: 사고와 창작을 위한 매체. 많은 기기가 이를 근사할 수 있지만 이 비전은 특정 스크린 크기나 하드웨어 설계가 아니라, 특히 학습자를 권한 부여하는 것에 관한 것입니다.
사람들이 ‘Smalltalk’을 들으면 종종 프로그래밍 언어를 떠올립니다. 그러나 케이의 팀은 그것을 더 큰 것으로 보았습니다: 언어, 도구, 사용자 경험이 하나로 설계된 완전한 작업 시스템이었습니다.
간단히 말해, Smalltalk는 모든 것이 객체인 시스템입니다. 화면의 창, 당신이 입력하는 텍스트, 클릭하는 버튼, 계산하는 숫자—각각이 객체이며 당신이 어떤 동작을 하길 요청할 수 있습니다.
Smalltalk는 실습으로 배우도록 설계되었습니다. 코드를 작성하고 컴파일한 뒤 작동을 기다리는 대신, 실행 중인 객체를 검사하고 현재 상태를 보고 변경하며 즉시 새로운 아이디어를 시험해볼 수 있었습니다.
그런 즉시성은 프로그래밍을 탐구로 바꿨습니다. 단순히 파일을 생산하는 것이 아니라 실행 중인 세계를 형태화하는 것이었습니다. “이게 뭐지?”, “무엇을 담고 있나?”, “조금 손대면 무슨 일이 일어날까?”라는 호기심을 장려했습니다.
Smalltalk의 개발 도구는 별도의 애드온이 아니었습니다. 브라우저, 인스펙터, 디버거, 편집기는 같은 객체 기반 우주 안의 일부였습니다. 도구들은 동일한 매체 안에서 만들어졌기 때문에 시스템 내부를 이해했습니다.
그 긴밀한 통합은 ‘소프트웨어 작업’의 느낌을 바꿨습니다: 먼 소스 코드를 관리하는 것 같지 않고, 대신에 당신이 만드는 시스템과 직접 상호작용하는 느낌이었습니다.
문서를 열어둔 상태에서 편집하는 것을 생각해 보세요—서식 변경이 즉시 적용되고, 검색, 재배열, 실행 취소를 빌드 없이 할 수 있는 상태. Smalltalk는 프로그램에 대해 그런 즉시성을 목표로 했습니다: 실행 중인 것을 편집하면 결과를 바로 보고 계속 움직일 수 있습니다.
케이가 가장 유용하게 제시한 사고 모델은 ‘클래스와 상속’이 아닙니다. 객체를 작은 독립 컴퓨터로 보는 생각입니다: 객체는 자신의 상태(지금 알고 있는 것)를 보유하고, 누군가 무엇을 하라고 요청하면 스스로 어떻게 응답할지 결정합니다.
각 객체를 다음과 같이 생각해보세요:
이 프레이밍은 ‘데이터가 어디에 저장되나?’에서 ‘누가 이 문제를 책임지나?’로 초점을 옮기기 때문에 실용적입니다.
흔한 혼동은 객체를 단지 필드 몇 개와 보조 함수를 붙인 고급 자료 레코드로 보는 것입니다. 그 관점에서는 프로그램의 다른 부분이 내부를 자유롭게 들여다보고 조작합니다.
케이의 관점은 시스템의 **행위자(actors)**에 가깝습니다. 객체의 서랍을 들여다보지 않습니다. 요청을 보내고 객체가 자신의 상태를 관리하도록 둡니다. 그 분리는 핵심입니다.
메시지 전달은 단순히 요청/응답입니다.
카페를 상상해보세요: 당신은 주방에 들어가서 직접 요리하지 않습니다. “샌드위치 만들어 주세요”라고 주문하고 “여기 있습니다” 또는 “빵이 다 떨어졌습니다”라는 대답을 받습니다. 카페가 주문 처리 방법을 결정합니다.
소프트웨어 객체도 마찬가지입니다: “총합을 계산해라”, “저장해라”, “자기 자신을 렌더해라” 같은 메시지를 보내고 객체는 응답합니다.
다른 부분들이 메시지에만 의존하면 객체 내부를 바꿔도(알고리즘을 바꾸거나 저장 방식을 교체하거나 캐싱을 추가해도) 호출자들을 대대적으로 고칠 필요가 없습니다.
경계에서의 안정적인 합의와 내부의 자유가 결합되어 시스템이 부서지지 않고 성장할 수 있습니다.
사람들은 흔히 ‘객체지향 프로그래밍’을 ‘클래스 사용’과 동의어로 취급합니다. 이는 이해할 만합니다—대부분의 언어가 클래스 다이어그램과 상속 트리로 OOP를 가르치니까요. 하지만 케이의 원래 강조는 달랐습니다: 대화하는 조각들로 생각하라는 것입니다.
클래스는 청사진입니다: 무엇을 알고 무엇을 할 수 있는지를 설명합니다.
**인스턴스(객체)**는 그 청사진에서 만들어진 구체적 실체입니다.
메서드는 객체가 메시지를 받았을 때 수행하는 동작입니다.
상태는 객체가 현재 기억하고 있는 데이터입니다; 시간이 지나며 바뀔 수 있습니다.
Smalltalk는 일관된 객체 모델을 대중화하는 데 기여했습니다: 모든 것이 객체이며 객체와 상호작용하는 방식이 일관적이라는 것. 또한 메시지 전달을 강하게 장려했습니다—다른 객체의 내부를 직접 건드리지 않고 메시지를 보내 그들이 스스로 처리하게 합니다.
이 스타일은 **지연 바인딩(late binding)**과 자연스럽게 결합합니다(동적 디스패치). 런타임에 어떤 메서드가 메시지를 처리할지 결정되므로 유연성이 높아 호출자를 고치지 않고 행동을 바꿀 수 있습니다.
실용적 규칙: 상호작용을 중심으로 설계하세요. “어떤 메시지가 있어야 하는가?”와 “누가 이 상태를 책임지는가?”를 물어보세요. 객체들이 깔끔하게 협력하면 클래스 구조는 부수적으로 단순해지고 변경에 더 유연해집니다.
GUI는 소프트웨어를 사용하는 감각을 바꿨습니다. 명령을 외우는 대신, 가리키고, 옮기고, 열고, 즉시 결과를 보는 방식입니다. 창, 메뉴, 컨트롤은 물리적 객체를 다루는 느낌에 가깝게 만들었고—추상적 지시보다는 직접 조작을 강조했습니다.
그 ‘물건 같은 느낌’은 객체 모델과 자연스럽게 대응됩니다. 잘 설계된 GUI에서는 보이고 상호작용할 수 있는 거의 모든 것이 객체로 취급될 수 있습니다:
이는 단순한 프로그래밍 편의가 아니라 개념적 다리입니다. 사용자는 ‘이 창을 옮겨라’, ‘그 버튼을 클릭하라’고 생각하고, 소프트웨어는 실제로 그런 행동을 수행할 수 있는 객체들로 구축됩니다.
클릭, 입력, 드래그가 발생하면 시스템은 이벤트를 생성합니다. 객체지향 관점에서 이벤트는 객체에게 보내는 메시지입니다:
객체들은 그 메시지를 다른 객체로 전달할 수 있습니다(“문서에게 저장하라고 알려라”, “창에게 다시 그리라고 알려라”), 그리고 그 연결이 이해 가능한 상호작용의 사슬을 만듭니다.
UI가 가시적 상태를 가진 지속적인 객체들로 구성되기 때문에, 이것은 일회성 명령을 실행하는 경험이 아니라 작업 공간에 들어가는 느낌을 줍니다. 창을 열어두고 도구를 배치하며 문서로 돌아와 계속 작업할 수 있습니다. GUI는 볼 수 있는 객체들 간의 대화가 이루어지는 일관된 환경이 됩니다.
Smalltalk의 가장 독특한 아이디어 중 하나는 문법 특징이 아니라 *이미지(image)*였습니다. 프로그램을 ‘소스 코드를 컴파일해 앱으로 만드는 것’으로 보지 않고, 실행 중인 객체들의 세계로 다룬 것입니다. 저장하면 살아 있는 환경 전체를 저장할 수 있었습니다: 메모리의 객체들, 열린 도구들, UI 상태, 현재 작업 상태.
이미지 기반 시스템은 영화의 한 프레임을 멈추고 대본뿐 아니라 세트와 배우들의 정확한 위치까지 저장하는 것과 같습니다. 다시 시작하면 작업을 중단한 그 자리로 돌아갑니다—도구는 그대로 열려 있고 객체들은 여전히 메모리에 있으며 변경은 이미 진행 중입니다.
이는 촘촘한 피드백 루프를 지원했습니다. 동작을 바꾸고 즉시 시험해보고 관찰한 뒤 개선할 수 있습니다—‘빌드, 재시작, 데이터 재로딩, 화면으로 다시 이동’이라는 정신적 초기화 없이도요.
동일한 원칙은 현대의 ‘vibe-coding’ 워크플로우에서도 보입니다: 평범한 언어로 변경을 설명하고 즉시 미리보기하며 반복할 수 있을 때 시스템을 더 빨리 배우고 흐름을 유지할 수 있습니다. Koder.ai 같은 플랫폼은 앱 빌드를 대화형 루프로 바꾸어(계획, 조정, 미리보기) 실제로 유지 가능한 코드를 내보낼 수 있게 합니다.
사람들이 좋아하는 이미지의 반향은 다음에서 볼 수 있습니다:
이것들이 Smalltalk 이미지와 동일하진 않지만, 목표는 같습니다: 아이디어와 결과 사이의 거리를 가능한 짧게 유지하는 것.
실행 중인 세계 전체를 저장하면 어려운 문제가 생깁니다. ‘진실’이 가변 상태에 살게 되면 재현성이 떨어질 수 있습니다. 이미지를 배포하는 것은 앱, 데이터, 환경의 경계를 흐릴 수 있어 복잡합니다. 특정 상호작용의 순서와 누적된 상태에 의존하는 버그는 디버깅을 더 어렵게 만듭니다.
Smalltalk의 선택은 더 빠른 학습과 반복이 그 대가를 감수할 가치가 있다고 보는 것이었고, 그 선택은 지금도 많은 팀이 개발자 경험을 생각하는 방식에 영향을 줍니다.
앨런 케이가 소프트웨어를 말할 때, 그는 종종 그것을 코드 더미가 아닌 시간을 두고 상호작용하는 많은 부분들로 보았습니다.
시스템은 어느 단일 구성요소로 정의되지 않습니다. 시스템은 관계로 정의됩니다—누가 누구에게 말하는가, 무엇을 요청할 수 있는가, 그리고 그 대화가 반복될 때 무엇이 발생하는가.
몇 개의 단순한 구성 요소도 반복과 피드백을 더하면 복잡한 동작을 만들어냅니다. 틱을 울리는 타이머, 상태를 갱신하는 모델, 다시 그리는 UI는 각각 간단할 수 있습니다. 이들을 합치면 애니메이션, 실행 취소/재실행, 자동 저장, 알림, 그리고 ‘그게 왜 바뀌었지?’ 같은 순간들이 생깁니다.
시스템 사고가 실용적인 이유는 바로 이것입니다: ‘A가 바뀌면 B가 반응하고 C가 촉발되는’ 루프를 찾고, ‘사용 10분 후에는 무슨 일이 일어나는가?’ 같은 시간 축을 보는 데 도움을 줍니다.
시스템에서는 인터페이스가 구현보다 더 중요합니다. 한 부분이 다른 부분과 명확한 메시지(‘카운트 증가’, ‘렌더’, ‘이벤트 기록’)로만 상호작용할 수 있다면 내부를 바꿔도 전체를 다시 작성할 필요가 없습니다.
이는 케이의 메시지 전달 강조와 가깝습니다: 다른 부분을 직접 제어하지 않고 요청하고 응답을 받는 방식입니다.
세 객체를 상상해보세요:
시간에 따른 흐름:
clicked를 보낸다.increment를 보낸다.changed(newValue)를 보낸다.changed를 듣고 다시 렌더링한다.record("increment", newValue)를 받는다.어떤 구성요소도 다른 구성요소의 내부를 들여다볼 필요가 없습니다. 동작은 대화에서 생겨납니다.
앨런 케이는 단순하지만 다소 급진적으로 들리는 아이디어를 밀어붙였습니다: 소프트웨어는 강력함뿐 아니라 배우기 쉬워야 한다. ‘영리한’ 설계는 종종 제작자의 만족을 최적화하는데, 그 결과 숨겨진 요령과 밀집된 추상화로 일반 사용자가 의례를 외우게 만듭니다.
케이는 단순함을 중요하게 여겼습니다. 초보자가 빠르게 이해할 수 있는 개념은 팀이 가르치고 공유하고 기반 위에 구축할 수 있습니다.
많은 소프트웨어가 사용자를 단순한 조작자로 대합니다: 올바른 버튼을 누르면 출력이 나온다. 케이의 목표는 사고 도구에 더 가까웠습니다—탐구를 초대하고 시행착오를 지원하며 사람들이 정신적 모델을 만들 수 있게 하는 도구입니다.
이것이 그가 대화형 시스템을 중요하게 여긴 이유입니다. 시스템이 즉각적이고 의미 있게 반응하면 학습이 사용의 일부가 됩니다.
케이는 종종 학습을 강제 조건으로 사용했습니다—때로는 사용자를 어린이로 상상하기도 했습니다. 개념을 직접 조작하고 검사하며 손쉽게 설명할 수 있다면 모든 사람에게 더 잘 작동할 가능성이 큽니다.
이는 ‘아이들을 위해 디자인하라’는 뜻이 아닙니다. 오히려 설명 가능성을 품질 검사로 삼으라는 의미입니다: 시스템이 스스로의 논리를 드러낼 수 있는가?
학습 용이성은 제품 기능입니다. 다음으로 설계할 수 있습니다:
대가는 초보자의 만족뿐만 아니라 더 빠른 온보딩, 적은 지원 요청, 사람들이 제품을 자신 있게 확장할 수 있는 능력입니다—바로 케이가 소프트웨어로 증폭하고자 했던 ‘사용자 주체성’입니다.
케이의 작업이 ‘오늘 우리가 쓰는 모든 것’을 발명한 것은 아니지만, 많은 사람들이 사람을 위한 소프트웨어를 만드는 방식에 강한 영향을 주었습니다.
현대 관행의 많은 부분이 Smalltalk와 제록스 PARC 문화가 구체화하고 대중화한 아이디어를 반영합니다:
원래 비전의 일부는 현대에 그대로 이어지지 않았습니다:
눈을 가늘게 뜨고 보면 많은 현재 패턴이 메시지 전달과 운율을 맞춥니다: 컴포넌트 기반 UI(React/Vue), 이벤트 기반 앱, 심지어 HTTP나 큐를 통한 마이크로서비스도 그러합니다. 동일하진 않지만 케이의 핵심 사상(상호작용하는 부품으로서의 시스템)이 현대 제약 아래에서 재해석되고 있음을 보여줍니다.
역사에서 실무로의 실용적 다리를 원한다면, 마지막 섹션(참조: /blog/practical-takeaways)은 이러한 영향들을 즉시 사용할 수 있는 설계 습관으로 바꿔줍니다.
케이의 작업은 철학적으로 들릴 수 있지만 아주 실용적인 습관으로 번역됩니다. Smalltalk를 쓸 필요도, 심지어 ‘OOP를 한다’고 선언할 필요도 없습니다. 목표는 성장하면서도 이해 가능한 소프트웨어를 만드는 것입니다.
시작할 때(또는 리팩터링할 때) 시스템을 함께 일하는 역할들의 집합으로 묘사해보세요:
이렇게 하면 ‘클래스를 써야 하니까 클래스를 만든다’는 식의 논쟁에서 벗어나 책임에 집중할 수 있습니다.
데이터베이스 테이블이나 클래스 계층을 논하기 전에 메시지를 정의하세요—한 부분이 다른 부분에게 무엇을 요청하는가.
유용한 연습: 하나의 사용자 동작에 대한 짧은 ‘대화’를 쓰세요:
그다음에 이러한 역할을 어떻게 구현할지(클래스, 모듈, 서비스) 결정하세요. 이것이 케이가 강조한 메시지 전달 중심의 접근입니다: 동작이 먼저고 구조는 그 결과입니다.
케이는 라이브 시스템에서 변경의 효과를 빠르게 볼 수 있기를 원했습니다. 현대 팀에서 이는 보통 다음을 의미합니다:
무엇이 바뀌었는지, 그것이 도움이 되었는지 알 수 없다면 당신은 눈을 가리고 비행하는 것입니다.
채팅 기반 워크플로(예: Koder.ai)를 사용한다면 동일한 조언이 적용됩니다: 프롬프트와 생성된 출력은 반복을 빠르게 하는 수단이지만 경계를 명확히 하고 스냅샷/롤백과 소스 코드 내보내기 같은 안전장치를 두어 시스템이 시간이 지나도 이해 가능하도록 유지하세요.
이 글이 공감됐다면 다음을 탐구해보세요:
이 주제들은 단순한 향수가 아니라 취향을 개발하는 방법입니다: 학습 가능하고 적응 가능하며 시스템으로서 일관된 소프트웨어를 만드는 취향 말입니다.
앨런 케이는 컴퓨터를 대기열에 넣어 처리하는 작업이 아니라 학습과 창작을 위한 대화형 개인 매체로 보아야 한다고 주장했습니다.
이 관점은 오늘날 우리가 당연하게 여기는 즉각적인 피드백, 조작 가능한 인터페이스, 작업 중에 탐색하고 수정할 수 있는 소프트웨어에 대한 기대를 직접적으로 형성했습니다.
다이나북은 학습과 창작을 위해 설계된 휴대형 개인 컴퓨터의 비전이었습니다(읽기, 쓰기, 그림, 시뮬레이션 등).
핵심은 ‘그가 태블릿을 예견했다’는 점이 아니라 ‘사용자를 단순한 조작자가 아닌 창작자로 보는 컴퓨팅의 본질’을 정의했다는 점입니다.
Smalltalk에서는 언어, 도구, UI가 하나의 일관된 환경으로 결합되어 있었습니다.
실무적으로는 실행 중인 객체를 검사하고 동작을 바꾸고 대화형으로 디버그할 수 있어, 반복적인 빌드/재시작 없이 아이디어와 결과 사이 거리를 크게 줄여줍니다.
케이의 핵심 아이디어는 ‘클래스와 상속’이 아니라 독립적인 행위자(객체)들이 메시지를 주고받는 것입니다.
설계 관점에서 이는 호출자가 객체의 내부 구조가 아니라 어떤 메시지를 보낼 수 있는지에 의존하도록 만듭니다.
흔한 오해는 OOP를 ‘클래스와 상속’으로만 보는 것입니다. 이는 도구 중 하나일 뿐이며 과도하게 사용되기 쉽습니다.
케이의 관점에 따른 실무 규칙:
GUI는 소프트웨어를 ‘무언가를 조작하는 경험’으로 바꿉니다(창, 버튼, 아이콘 등). 이는 각 UI 요소를 상태와 동작을 가진 객체로 보는 모델과 자연스럽게 결합됩니다.
사용자의 클릭·드래그·키 입력은 객체로 보내지는 이벤트(메시지)로 볼 수 있고, 객체들은 그 메시지를 필요에 따라 다른 객체에게 전달할 수 있습니다.
Smalltalk *이미지(image)*는 실행 중인 세계 전체를 저장하는 개념입니다: 메모리의 객체들, 열린 도구들, UI 상태, 현재 작업 상태까지 포함합니다.
이점:
단점:
시스템 사고는 시간에 따른 동작(피드백 루프, 연쇄 반응, 누가 누구와 대화하는가)에 집중하게 합니다.
실무적으로는 명확한 인터페이스(메시지)를 만들고 숨겨진 의존성을 줄이는 설계로 이어집니다. 즉, 애플리케이션을 독립적인 구성 요소들이 상호작용하는 것으로 보는 것입니다.
다음 절차를 따르는 메시지 우선 설계를 시도해 보세요:
그다음에 클래스를 만들지, 모듈로 할지, 서비스를 분리할지 결정하세요. 또한 /blog/practical-takeaways에 있는 체크리스트를 참고하면 실무 적용에 도움이 됩니다.
현대 도구들 가운데 케이의 목표와 공명하는 것들:
이들은 Smalltalk 이미지와 동일하진 않지만, 변화와 학습 비용을 낮추려는 같은 목표를 추구합니다.