TheArtandScienceofSmalltalk:Chapter 03
- 제 3 장 스몰토크 입문
스몰토크 입문
앞서 객체 지향 프로그래밍의 일반적인 특징들을 살펴보고 관련된 개념과 용어를 어느 정도 설명했으니 이제 우리의 관심사인 객체 지향 언어, 스몰토크를 살펴보자.
이전에 C, Pascal 또는 COBOL 과 같은 재래식 언어로 프로그래밍한 경험이 있다면 프로그램을 생성하는 과정에 익숙할 것이다. 텍스트 에디터를 이용해 프로그램을 작성하고, 컴파일러를 이용해 컴파일하며, 호출했을 라이브러리 루틴에서 연계를 위해 링커를 이용하고, 마지막으로 컴퓨터에서 직접 실행하기까지 과정에 익숙해질 것이다. 프로그래밍의 디버깅을 위해 디버거를 이용해왔을지도 모른다. 하지만 지금쯤 어느 정도 짐작하겠지만 스몰토크에서는 상황이 다르다.
스몰토크는 하나의 통합된 시스템이다. 스몰토크에서는 프로그램을 개발, 디버깅, 실행하는 데에 필요로 하는 모든 것이 하나의 패키지에 포함되어 있다. 이번 장의 목적은 이러한 의미를 설명하고 시스템의 주요 부분을 소개하는 데에 있다. 제 1부의 나머지 장들은 이번 장에 소개된 개념에 따라 구성된다.
스몰토크 시스템의 역사
스몰토크는 1970 년대 초, 미국 캘리포니아에 위치한 Xerox Palo Alto Research Center 에서 개발되었다. 본래는 연구 시스템으로서 윈도우 기반(window-based) 사용자 인터페이스의 사용을 포함해 많은 새로운 기능들을 포함했다. 당시에 이용할 수 있는 것이 없었기 때문에 스몰토크는 고유의 윈도우 시스템을 구현하였는데, 그 중 나머지는 오늘날에도 여전히 남아 있다! 당시 스몰토크는 Xerox 컴퓨터에서만 실행되었다. 오늘날 스몰토크는 산업 표준의 상업 및 과학용 언어이다. 이용할 수 있는 경쟁적인 구현(competing implementations)의 수가 많이 있으며, 다양한 플랫폼에서 실행된다. 이러한 시스템들 중 다수는 Xerox PARC 의 Smalltalk-80 시스템을 기반으로 한다. 본 저서는 한 가지 특정한 스몰토크 구현, 즉 ParcPlace Systems 의 VisualWorks 를 중점으로 한다.
스몰토크 시스템의 구조
스몰토크라는 용어는 종종 세 가지를 지칭한다: 프로그래밍 언어; 클래스의 라이브러리; 그리고 개발 환경. 개념적으로는 별개이나 이 세 가지가 사실상 매우 상호의존적임을 볼 수 있을 것이다. VisualWorks 를 포함해 시중에 판매되는 모든 스몰토크는 이 세 가지 요소들을 포함한다. 물론 스몰토크들 간에 차이점들이 있긴 하나 일반적으로 실제 언어들은 거의 동일하고, 클래스 라이브러리들은 유사한 반면 개발 환경은 가장 다양하다는 사실을 발견할 것이다. 따라서 다음 페이지에 실린 다이어그램은 아래를 표시한다.
- '스몰토크' = 하나의 언어 + 하나의 클래스 라이브러리 + 하나의 개발 환경
스몰토크 언어 자체는 매우 작다. C 혹은 심지어 BASIC 과 비교하더라도 거의 별 다른 게 없다. 기본적으로 스몰토크는 변수를 정의하고, 객체를 그 변수로 할당하며, 객체에게 메시지를 전송하도록 해준다. 제 4장은 스몰토크 언어를 완전히 설명하는 데에 초점을 둔다. 다른 대부분의 언어들과 달리 상대적으로 전체 스몰토크 언어를 쉽게 알 수 있음을 발견할 것이다.
스몰토크에서는 거의 모든 것이 객체이고 (숫자, 문자열, 프로세스를 포함해 모두), 거의 모든 것이 (산술, 테스트, 루핑, 입력과 출력 포함) 객체로 메시지를 전송함으로써 이루어진다. 하지만 언어 자체는 이러한 객체나 메시지 중 어느 것도 정의하지 않는다. 대신 모든 것을 비롯해 다른 수 많은 것들이 언어에 동반되는 표준 클래스 라이브러리에서 정의된다.
클래스 라이브러리는 스몰토크 시스템의 핵심이다. 이것은 수백 개의 재사용 가능한 클래스를 제공하여 당신이 작성하는 모든 스몰토크 프로그램에서 사용하게 될 것이다. 이것은 당신이 보통 컴퓨터 언어의 일부로 생각하는 기본 기능을 모두 제공한다. 숫자는 클래스 라이브러리에서 정의된 객체이므로 산술 연산은 숫자로 메시지를 전송함으로써 이루어진다. 부울 값 또한 클래스 라이브러리에서 정의되므로 조건부 분기(conditional branch)는 booleans 로 메시지를 전송하여 이루어진다. 클래스 라이브러리는 루핑을 지원하는 데이터 구조를 구현하는 객체와 (컬렉션), 입력 및 출력 연산을 제공하는 객체를 포함한다.
스몰토크 클래스 라이브러리는 스몰토크 언어를 이용해 구현된다. 자신만의 클래스를 빌드하는 방식과 동일하게 빌드된다. 언어 자체와 달리 클래스 라이브러리는 매우 광범위하다. 스몰토크로 다년간 프로그래밍을 하면서 그 전체를 알지 못할 수도 있다. 스몰토크 시스템은 클래스 라이브러리에 대한 모든 소스 코드를 포함하기 때문에 이는 전혀 문제가 되지 않는다. 이러한 이점이 의아해 보일지도 모르겠다. 결국 대부분의 C 프로그래머들은 컴파일러에 (그리고 볼 수 있듯이 에디터, 디버거, 윈도우 시스템...) 대한 소스 코드를 피하기 마련이다! 이러한 소스 코드의 존재는 엄청난 양의 세부적 내용을 무서울 정도로 눈에 보이도록 만들지만 시스템이 어떻게 정확히 작동하는지 볼 수 있도록 해주기도 한다. 어떤 타입의 조건부 분기를 지원하는지 기억할 수 없다면 검색이 가능하다. 클래스 라이브러리에서 연산의 특정 미묘한 차이를 이해해야 할 필요가 있다면 그것이 정확히 어떻게 구현되는지를 볼 수 있다. 무시무시하게 들리는가? 별로 그렇지도 않다...
클래스 라이브러리에 대한 소스 코드는 스몰토크 개발 환경을 통해 시각적으로 만들어진다. 이는 브라우저, 인스펙터, 디버거, 사용자 인터페이스 생성기(generator), 기타 툴의 집합으로 구성된다. 이러한 툴은 시스템이 어떻게 작동하는지에 대해 매우 명확한 관점을 제공한다-사용하는 방법을 알고 있다면 말이다. 이 책의 대부분은 이러한 점과 관련해 독자에게 도움이 되고자 작성되었다. 개발 환경을 이용해 클래스 라이브러리를 살펴볼 수 있을 뿐만 아니라 자신만의 코드를 생성, 실행, 디버깅할 수도 있다. 스몰토크에서는 개발 환경의 일부로 제공되지 않은 툴을 사용해야 하는 경우가 극히 드물다. 개발 환경은 클래스 라이브러리에서 클래스를 이용해 구현된다. 사실 개발 환경에 대한 코드 자체가 라이브러리의 일부이다. 프로그래머는 라이브러리의 소스 코드를 이용할 수 있기 때문에 개발 환경의 소스 코드 또한 이용할 수 있다. 이는 두 가지 결과를 낳는다. 첫째, 스몰토크에서 애플리케이션을 빌드하는 방식을 완전하게 보여주는 예를 제공한다. 둘째, 개발 환경에서 무언가가 작동하는 방식이 마음에 들지 않으면 원칙상 그것을 변경할 수 있다.
그렇다면 우리에겐 무엇이 남았는가? 스몰토크라 불리는 언어가 남아 있다. 이것은 매우 작으며, 할 수 있는 일이 거의 없는 것이 사실이다. 스몰토크에서 작성되는 것은 기능의 표준 라이브러리를 제공하는 클래스 집합이다. 그러한 클래스들을 이용해 빌드되는 것은 스몰토크 프로그래머에게 강력한 개발 환경을 제공하는 툴의 집합이다. 사실 스몰토크로 프로그래밍 시 당신의 과제는 그 시스템을 가져와 당신이 원하는 방식대로 바꾸기 위해 확장하는 것이다. 다른 언어에서와 달리 당신과 시스템 사이에 '벽'이 존재하지 않는다. 시스템 자체의 개발자들이 즐기는 유연성과 기회가 당신에게도 똑같이 부여될 것이다.
스몰토크 시스템의 구현
C, Pascal, 또는 다른 많은 언어에서 프로그래밍할 때는 보통 완료된 프로그래밍이 자신의 컴퓨터 하드웨어에서 곧바로 실행되는 것으로 (비록 운영체제의 힘을 빌리긴 하지만) 생각한다. 하지만 스몰토크는 가상 머신(VM)이라는 개념을 도입하는데, 이는 스몰토크 프로그램과 실제 컴퓨터 사이에 위치한다. 가상 머신은 스몰토크 개발 툴과 당신의 스몰토크 프로그램이 실행되는 이상화된 스몰토크 컴퓨터의 일종으로 생각하면 되겠다. VM은 가상 이미지와 (VI, 또는 단순히 이미지) 연관해 작동한다. 이미지는 가상 머신의 메모리와 동등한 것으로 생각할 수 있다. 이미지는 개발 툴, 스몰토크 코드 라이브러리, 그리고 자신의 프로그램이 실제로 상주하는 곳이다. 다음 페이지에 소개된 다이어그램이 이러한 구조를 보여준다.
스몰토크 프로그램을 컴퓨터 하드웨어로부터 분리시키는 것이 바로 스몰토크를 서로 다른 플랫폼들 간에 쉽게 이식이 가능하도록 만드는 방법이다. 각 플랫폼은 (워크스테이션, PC, 매킨토시 등) 고유의 VM 버전을 실행 가능 파일 형태로 갖고 있다. 하지만 VM 에 의해 구현되는 가상 컴퓨터는 동일하기 때문에 VM 의 구현부에서는 동일한 이미지 파일이 실행될 것이다. 플랫폼들 간 프로그램을 이식하기 위해서는 이미지를 단순히 복사하면 된다! 이러한 일관성을 확보하기 위해 VM 은 고유의 기본 연산 집합을 구현하는데, 산술, 논리 및 I/O 연산이 이에 포함된다. 이러한 연산들은 당신의 컴퓨터가 실제로 런타임 시 실행할 수 있는 연산으로 해석된다. 본래는 인터프리터(interpreter)가 이러한 업무를 맡았지만 최소한 VisualWorks 에서는 증분 컴파일러에 의해 실행되어 더 빠른 코드를 제공한다.
시스템이 상주하는 파일
스몰토크 시스템은 위에서 설명한 바와 같이 여러 다수의 파일에 상주한다. 이는 다음 페이지의 다이어그램에 표시되어 있다. 이러한 파일들은 시스템을 유지시킬 뿐만 아니라 당신의 프로그램도 유지하므로 명확히 이해하는 것이 도움이 된다.
가상 머신은 당신의 컴퓨터가 지원하는 포맷으로 된 실행 가능한 프로그램이다. 이는 주로 oe20(또는 VisualWorks 의 오래된 버전을 갖고 있다면 st80)라 불리는 고유의 파일에 상주한다. 하지만 가상 이미지는 여러 타입으로 된 파일들에 분할되어 있다.
가장 중요한 파일의 타입은 image 파일이다. 이것은 특정 시간에서 가상 이미지에 있는 모든 코드와 데이터의 바이너리 형태로 된 스냅숏이다. 이미지 파일은 전체 이미지를 포함하기 때문에 일반적으로 크기가 몇 메가바이트로 되어 있다. VisualWorks 에는 표준 '기반' 이미지 파일이 따라오는데, 이 파일은 전체 클래스 라이브러리와 개발 환경을 포함한다. 이는 주로 visual.im 와 같이 불린다. VisualWorks 를 시작할 때 VM은 이미지 파일을 컴퓨터의 메모리 내에서 그것을 작업할 수 있는 곳에 로딩한다. 프로그래밍을 하는 동안 메모리 내 이미지는 항시 변화한다. 원할 때마다 이것을 다시 파일로 저장할 수 있으므로 (시스템이 .im을 추가할 이름을 이용하여) 자신만의 이미지 파일을 생성 가능하다. 이미지 파일은 이미지에 모든 것을 포함하기 때문에 자신의 이미지 파일 중 하나를 이용해 VisualWorks 를 재시작할 경우 윈도우 개방(windows open), 프로그램 실행(program running) 등 자신이 저장하던 당시 전체 환경의 상태를 재생성할 것이다. 이는 매우 유용한 기능이다. 디스크 공간이 충분하다면 이미지를 자주 저장해야 하는데 (매 30분마다 또는 중요한 변경 내용이 있을 때마다) 작업을 저장하는 편리한 방법이기 때문이다.
단, 유일하게 이미지 파일에 저장되지 않는 것이 소스 코드이다. 이는 클래스 라이브러리의 소스와 자신의 프로그램의 소스에도 적용된다. 표준 클래스 라이브러리의 소스 코드는 (다시 말해, 기본 이미지 파일에 대한 소스 코드) sources 파일에 저장된다. 이는 텍스트 파일로서 (당신이 읽게 될 일은 거의 없지만) visual sources라고 부르기도 한다. 시스템은 시작 시 전체 sources 파일을 로딩하지 않는다. 대신 당신이 살펴보아야 할 특정 메서드의 소스를 얻어야 할 때마다 파일로 접근한다. 소스 코드는 실행해야 할 메서드를 위해 필요한 것이 아니다. 사실 시스템은 sources 파일 없이도 만족스럽게 실행될 것이다-당신이 코드를 분명히 살펴볼 수가 없을 뿐이다.
당신이 작성하는 메서드와 클래스에 대한 소스 코드는 sources 파일에 보관되지 않는다. 대신 changes 파일에 보관된다. 이는 이미지에 당신이 추가하거나 변경한 내용에 대한 모든 소스 코드를 보관하는 텍스트 파일이다. 각 이미지 파일에는 하나의 changes 파일이 존재하며, 주로 <name>.changes 라고 (PC에선 .cha) 부르는데 <name>은 자신이 이미지 파일에 붙여준 이름이 위치한다. Sources 파일과 changes 파일은 이미지에 대한 모든 소스 코드를 유지한다.
Sources 파일과 마찬가지로 changes 파일 또한 VisualWorks 가 시작될 때 완전히 로딩되지 않는다. 대신 시스템이 당신의 메서드 중 하나에 대한 소스 코드가 필요할 때마다 접근한다. 하지만 절대로 작성되지 않는 sources 파일과는 달리 changes 파일은 시스템 내 어떤 내용이든 수정할 때마다 작성된다. 자신의 이미지를 저장할 때 뿐만이 아니라 항상 발생한다. 또한 changes 파일에서는 메서드의 새 버전이 오래된 버전을 오버라이드하지 않는다. 단순히 끝에 추가될 뿐이다. 즉, changes 파일은 시스템에 당신이 변경하거나 추가한 내용의 완전한 히스토리를 형성함을 의미한다. VisualWorks 는 이를 이용해 충돌에서 회복하거나 자신의 기존 코드 버전으로 돌아갈 수 있도록 해주는 툴을 몇 가지 제공한다.
여기서 흥미를 끄는 마지막 파일 종류로 file-in 파일이 있다. 앞에서 전체 이미지를 이미지 파일로 저장하여 작업을 저장하는 것이 가능하다고 언급한 바가 있다. 시스템의 전체 상태의 스냅숏을 생성하는 매우 간편한 방법이지만, 작은 코드 조각을 가령 다른 사람에게 전달하기 위해 저장하기에는 그다지 편리한 방법이 되지 못한다. 이에 부응하기 위해 VisualWorks 는 당신이 요청한 코드만 구분된 파일에 작성하는 file-out 메커니즘을 제공한다. File-ins는 텍스트 파일로서 스몰토크 소스 코드를 저장하나, 보통 VisualWorks 시스템 외부에서는 편집할 일이 없을 것이다. File-ins를 이용해 개발자들 간 코드를 공유할 수 있다. 이 파일은 기반 이미지(base image)로부터 자신의 이미지를 재빌드해야 하는 경우-이미지 손상 시 때 종종 발생-매우 중요하다. 자신의 이미지를 저장할 뿐만 아니라 코드를 정기적으로 (안정적 상태일 때마다) file-out하는 것은 좋은 생각이다.
스몰토크는 언어, 클래스 라이브러리, 개발 환경으로 구성된 완전한 시스템이다. 이 세 가지는 가상 이미지라 불리는 데에 포함되어 있는데, 이 이미지는 자신의 컴퓨터에서 실행되는 실행 가능(executable) 프로그램인 스몰토크 가상 머신의 최상위에서 실행된다. 전체 가상 이미지는 파일로 저장하여 후에 복구할 수 있다. 당신의 코드는 이미지 내에 또는 당신이 생성한 file-in 파일에 상주한다.
스몰토크에서 프로그래밍하는 과정은 스몰토크 언어, 그리고 클래스 라이브러리가 당신이 원하는 일을 행하도록 확장하기 위한 개발 환경으로 구성된다. 이와 관련된 내용은 곧 살펴볼 것이다. 우선 다음으로는 스몰토크 언어의 세부 내용을 살펴보겠다.