40년 동안 Smalltalk 개발을 형성해 온 4분할 System Browser는 여전히 탁월한 맥락을 제공하지만, 더 큰 문제는 브라우저 자체가 아니라 이를 둘러싼 도구들이 서로 조합되지 못하는 데 있다.
Pharo Featured
4분할 System Browser는 40년 동안 Smalltalk 개발을 형성해 왔다. 여전히 맥락을 제공하는 데는 훌륭하다. 하지만 진짜 문제는 브라우저 자체가 아니라, 그 주변을 둘러싼 도구들 사이에 조합(composition)이 부족하다는 데 있을지도 모른다.
04 Mar 2026• 7 min read
Smalltalk’s Browser: Unbeatable, Yet Not EnoughSmalltalk은 겉보기에는 “낡아” 보이지만, 알고 보면 많은 경우 _최초_였던 시스템 중 하나다. 현대 IDE에서 당연하게 여기는 많은 것들—라이브 인스펙션, 촘촘한 피드백 루프, 강력한 내비게이션—은 수십 년 전부터 Smalltalk 문화의 일부였다.
그런데도 Smalltalk에서 일하는 일상 경험은 40년 동안 거의 변하지 않은 은유에 여전히 지배된다. 바로 4분할 System Browser다. 이것은 맥락을 제공하는 데 탁월하다. 동시에 더 넓은 UX 문제의 출발점이기도 하다.
Smalltalk-80의 이 스크린샷을 보면 System Browser가 실제로 어떻게 쓰이는지 분명히 볼 수 있다:
Smalltalk-80 system browser and companions
System Browser(또는 _class browser_라고도 한다)는 시스템의 클래스 구조를 탐색하기 위한 것이다. 실제로는 대부분의 Smalltalk IDE에서 주요한 프로그래밍 작업 표면이다.
다음은 현대의 두 가지 구현이다—시대도 다르고 UI 스타일도 다르지만, 바탕에 깔린 은유는 동일하다:
The system browser in Pharo
Glamorous Toolkit의 시스템 브라우저인 "Coder"
어디서나 같은 구조를 볼 수 있다. 겉모습의 차이가 무엇이든 모델은 안정적이다. 이것이 우리가 내부적으로 4분할 브라우저라고 부르는 것이다.
이 은유는 완전한 IDE를 갖춘 사실상 모든 Smalltalk에 존재해 왔다(그리고 그렇다: GemStone이나 GNU Smalltalk처럼 전통적인 IDE가 없는 Smalltalk 시스템도 있다). 이는 칭찬과 비판을 모두 받았다. 놀라운 점은 이것이 대체되지 않았다는 사실이다.
그래서 진짜 질문이 떠오른다:
왜 이 은유는 이렇게 강력한가?
왜 4분할 브라우저는 그렇게 오랫동안 살아남았고, 더 새로운(아마도 더 나은) 은유로 대체되지 않았을까?
Smalltalk에서 프로그래밍은 메시지 전달(message passing)에 관한 것이기 때문에, 코드 패널—메서드 에디터—를 “주” 구성요소로 취급하고 싶어진다:
The method: gravity center of the system browser
그 관점에서 보면, 분명한 “대체물”은 어떤 형태의 message-flow 뷰일 것이다. 즉, 계층이 아니라 경로로서의 동작(behavior)을 탐색할 수 있게 해 주는 도구 말이다.
이 아이디어는 매력적이다. 하지만 프로토타입이 존재하더라도, 사람들의 기본 작업 방식으로 자리 잡는 경우는 드물다. 그리고 그 이유를 해부하다 보면 구현 제약(UI 툴킷, 그래픽스 레이어, 성능)이 탓으로 돌아가곤 한다. 그중 일부는 분명 사실이지만, 더 깊은 이유는 더 단순하다고 생각한다:
메시지를 고립된 요소로 취급하면, 생산적으로 일하기 위해 필요한 맥락을 잃게 된다.
메시지는 메서드이고, 메서드는 구조 안에 존재한다.
클래스는 메시지 전달을 위해 엄밀히 필수는 아니다(Self가 오래전에 이를 보여 주었다). 하지만 클래스는 구조를 만들기 위해 존재한다. 즉, 일관된 맥락 안에서 동작을 묶기 위해 존재한다. 그러니 브라우저를 볼 때는 이렇게도 보아야 한다:
_A method is part of a class, which is part of a package_
당신이 편집하는 것은 클래스의 맥락 안에서 이해될 메시지이며, 다른 클래스들 가까이에 위치하고, 이름, 계층, 협업 관계로 연결되어 있다.
맥락이야말로 System Browser가 여전히 따라잡기 어려운 이유다.
그럼에도 불구하고, 우리 중 많은 사람은 여전히 브라우저가 넘어서는 무엇인가에 의해 대체되어야 한다고 느낀다. 브라우저가 나빠서가 아니라, 실제 프로그래밍 작업이 빠르게 브라우저가 혼자 표현할 수 있는 범위를 넘어선다고 느끼기 때문이다.
예를 들어, 나는 단순한 질문에 답하는 동안 이런 상태가 되었다: 새 settings browser에서 settings label이 어떻게 생성되는가? (그리고 나는 이미 답을 알고 있었다—즉 이것은 “빠른 경로”였다.)
System browsers opened in a Pharo world: A "tsunami" of windows
이렇게 창이 폭포처럼 쏟아질 때, 당신의 문제를 실제로 해결하는 메시지 흐름을 어떻게 이해하겠는가?
OOP 프로그래머로서 우리는 동작을 이해하기 위해 메시지 흐름을 따라가야 한다. 디버깅이 그렇게 중심적인 이유도 바로 그것이다.
나에게 전형적인 세션은 이렇게 보인다:
그렇다, 프로그래밍은 지저분하다.
그리고 여기서 마찰이 생긴다:
System Browser는 프레임을 보여 주지만, 우리는 장면도 이해해야 한다.
프레임은 귀중한 맥락을 담고 있지만, 여러 도구와 여러 번의 점프에 걸쳐 동작이 어떻게 드러나는지에 대한 동적인 “이야기”를 포착하지 못한다.
사람들이 흔히 말하는 “브라우저 문제”는 사실 브라우저 문제가 아니다. IDE 문제다.
System Browser는 더 큰 환경 안의 하나의 도구일 뿐이다: message browsers(senders/implementors), playgrounds, inspectors, debuggers—각각은 그 자체로 하나의 세계다.
그리고 Pharo(그리고 내가 아는 모든 Smalltalk 시스템)에서는 이 도구들이 매끄럽게 조합되지 못한 채 공존한다. 서로 옆에 놓여 있지만, “IDE”라는 말이 암시하는 방식으로 진정으로 _통합_되어 있다는 느낌은 아니다. 그 결과 워크플로는 혼란스러워지기 쉽다. 도구들은 강력하기 때문에 복잡성을 줄이기도 하지만, 작업 집합(working set)을 일관되게 유지하기 어렵기 때문에 복잡성을 늘리기도 한다.
우리 모두 이 문제를 알고 있다. 몇 년 전, Santiago Viana가 우리 팀을 방문해 Pharo에 대한 작은 사용성 연구를 수행했다(당시 그는 UX를 공부 중이었다). 표본 크기는 결론을 내릴 만큼 충분히 크지 않아 과학적으로 확정적이진 않았지만, 그가 찾아낸 마찰 지점들은 매우 현실적으로 느껴졌다:
이 관찰에 동의하기 어렵지 않다. 여기에 몇 가지 반복되는 패턴을 더하고 싶다:
수십 년에 걸쳐 도구는 기능을 축적한다. 비전은 바뀐다. 전체 설계를 재작업하지 않은 채 새로운 개념이 추가된다. 그 결과 도구는 극도로 강력해지지만—점점 더 숙달하기 어려워진다.
코드 에디터 메뉴와 코드 디버깅 메뉴가 함께 있는데... 저게 다 뭐지? 그리고 같은 동작을 수행하면서 왜 이름은 다르게 불릴까?
Pharo(그리고 많은 Smalltalk)에서는 때때로 “같은 world 안에 있다”는 것만으로 충분한 통합이라고 여긴다. 하지만 도구 사이 이동이 충분히 유연하지 않고, 맥락이 함께 따라오지 않는다. 너무 자주 각 도구는 섬처럼 동작한다.
파일 브라우저는... 좋긴 한데, OS가 이미 하나를 주는데 왜 도대체 또 다른 파일 브라우저가 필요한 걸까?
Smalltalk은 _모든 것_이 이미지 안에서 만들어지는 환경으로 설계되었다. 이 철학은 강력하지만—현대 워크플로와 OS 관습(창 관리, 메뉴, 단축키, 외부 도구)과의 마찰도 만든다. 어떤 차이는 Smalltalk 경험에 본질적이지만, 어떤 것은 그저 불필요한 비호환성일 뿐이다.
(이미지는 없지만, Iceberg, 너를 보고 있다)
Pharo가 진화하면서 시스템은 규모와 복잡성 모두에서 성장한다. 초기 Smalltalk 시스템은 이에 비해 아주 작았다. 예를 들어 Smalltalk-80 V2는 223 classes만 있었다. “vanilla” Pharo 14 이미지는 약 10,750개를 포함한다.
정확한 계수 방법이 무엇이든, 자릿수(order-of-magnitude) 차이는 탐색의 경제성을 바꾼다. 내비게이션, 발견 가능성(discoverability), 신호 대 잡음, 그리고 “그냥 좀 찾아보기”의 정신적 비용이 달라진다.
사람들이 흔히 “브라우저 문제”라고 부르는 것은 사실 브라우저 문제가 아니다. IDE 문제다.
그리고 이를 해결하는 데 마법 같은 단일 처방은 없다. 사실 완벽한 해법은 아마 없을 것이다. Pharo는 기존 도구를 강화하고 다듬는 방식으로 반복적으로 개선하는 경향이 있다. 이는 가치 있다—예를 들어 Pharo 13의 Cavrois Organic Window Manager 같은 기능은 분명 마찰을 줄이고 일상을 개선하려는 목적을 가진다.
하지만 점진적 개선만으로는 일상 작업을 지저분하게 만드는 핵심을 완전히 해결하지 못할 것 같은 느낌을 피하기 어렵다. 문제는 정적인 맥락의 부족이 아니다(브라우저는 그 점에서 훌륭하다). 문제는 도구들 사이의 조합 부족과 동적 맥락의 부족이다.
어쩌면 진짜로 빠진 조각은 “더 나은 브라우저”가 아니라, _일(work)_을 표현하는 더 나은 방식일지도 모른다.
내가 동작을 이해하려 할 때, 나는 실제로 “브라우저 안”이나 “디버거 안”에 있는 것이 아니다. 나는 조사의 스레드(thread of investigation) 안에 있다. 내비게이션 단계들의 사슬, 실험, 인스펙트한 객체들, 탐색한 스택 프레임들, 그리고 내려진 결정들로 이루어진 흐름 말이다.
그래서 내가 열어 두고 싶은 질문은 이런 것이다:
workspace를 독립 창들의 집합(그저 함께 공존할 뿐인)으로 보는 대신, 그 스레드를 중심으로 조직된 관련 도구들의 그래프로 취급한다는 것은 무엇을 의미할까?
아직 답은 없다. 하지만 내가 점점 더 확신하는 것은, 우리가 언젠가 “브라우저 문제”를 해결한다면 그것은 4개의 패널을 대체해서가 아닐 것이라는 점이다. 그것은 _장면_을 탐색 가능하게 만드는 방식일 것이다. 프로그래머가 어디로 어떻게 왔는지, 무엇을 시도했는지, 무엇을 배웠는지, 그리고 관련된 모든 도구가 서로 어떻게 연결되는지 추적할 수 있게 해 주는 것.
System Browser는 여전히 훌륭한 프레임이다. 남은 질문은 IDE의 나머지도 같은 강도로 장면을 담아낼 수 있느냐는 것이다.
fediverse에서 이 글 토론하기: https://social.smallworks.eu/notice/B3uUHdRlqilPLAD2Aq
Let's start a blog ------------------ 요즘 블로그를 시작하는 일은 과거로 뛰어드는 것처럼 느껴진다. 지난 20년 동안 많은 것이 바뀌었고, 그때는 블로깅이 새로운 것이었으며 전 세계 사람들이 블로그를 시작하던 시기였다. 이제 모든 것은 즉각적이고 덧없다. 그럼에도 나는 여전히 최고는06 Jan 2026 1 min read
MIND MAP © 2026
