AndreaSmalltalkLecture:QnA 10

From 흡혈양파의 인터넷工房
Jump to navigation Jump to search
질문과 답변-10
:Smalltalk과 다른 언어

Smalltalk과 다른 언어

안녕하세요? 김찬홍 안드레아입니다. Smalltalk를 공부하는 입장에서 정남님께서 해 주신 말씀이 저에게도 무척 많은 도움이 되었습니다. 일견 저와 같은 생각을 가지신 부분도 있고 그렇지 않은 부분도 있는데요, 정남님의 글을 인용해서 제 생각을 간단히 적어보도록 할게요.


뉴스 그룹에 가면 꽤 괜찮은 글들이 많이 나옵니다. 전에 가서 보니 스몰톡그룹에서 왜 스몰톡이 상용화 되어서 쓰는게 없나 하는 이유를 쭉 써놓은 게 있는데 일견 맞는 말이 있는 거 같기도 하더군요.. 예를 들자면 독자적인 실행파일을 못 만든다든가, 상용 DB와 연계해서 쓸 방법이 없다든가 원래 목적이 애들용으로 만들어서 그런다든지...


Smalltalk가 주류 언어는 아닙니다. 그러나 위에 정남님께서 지적하신 사항은 절대적인 것이 아니라 다분히 개선될 여지가 있는 것이고, 현재 많은 부분에서 개선이 이루어지고 있습니다.


먼저 독자적인 실행 파일에 관해서는 저기 아래 제가 실행 파일 배포에 대해서 쓴 글에서도 나와있듯이, 이미 Smalltalk가 Windows나 기타 다른 환경에 이식될 때 독립 실행 파일을 만들 수 있도록 되어 있었습니다. 다만 초창기의 경우에는 Smalltalk 가상 기계와 객체들의 본(image)을 통째로 꾸려서 실행파일을 만들었기 때문에 필요없는 부분들이 많았지만, 현재의 경우는 뽑아내기(image stripping) 기법을 사용하여 프로그램에서 사용하지 않는 객체나 갈래(class)들과 각종 개발 환경들은 모두 본에서 뽑아내서 상당히 컴팩트한 실행 파일을 만들어 낼 수 있습니다. Dolphin Smalltalk VisualAge for Smalltalk 등은 이러한 뽑아내기를 지원합니다. 또한 Smalltalk-MT의 경우는 Multi-thread를 지원하고, 다른 Smalltalk들과는 달리 직접 기계어로 번역하여 실행하는 native-compiler를 가지고 있다는 특징이 있습니다. Squeak의 경우는 아직 공부해 보지 않아서 모르겠는데, Smalltalk 코드에 대응하는 C코드를 만들어주기 때문에 독립실행파일이 필요하면 이렇게 해서 만들어진 바탕글을 번역하여 쓰면 될 것입니다. 제가 사용하고 있는 Dolphin Smalltalk에서는 ADK(Application Development Kit)을 사용하여 독립 실행 파일을 만듭니다.


상용 데이터베이스와의 연결 문제에 대해서도 여러 가지 해결 방안이 있습니다. Dolphin Smalltalk와 Smalltalk-MT, VisualAge for Smalltalk는 모두 ODBC를 통해서 DB에 접근할 수 있기 때문에, ODBC 드라이버를 가지고 있다면 얼마든지 관계형 데이터베이스에 접속할 수 있습니다. Dolphin Smalltalk의 경우에는 ActiveX 객체와 접속할 수 있으므로, ADO를 사용할 수 있습니다. 아직까지 ADO를 포장할만한 갈래가 준비되지 않아서 바로 ADO와 접속할 수는 없지만 곧 ADO를 지원하는 꾸러미가 나올걸로 알고 있습니다. 또한 각 Smalltalk 회사들은 나름대로 OODBMS를 지원하는데, 오히려 객체지향 방법론을 제대로 실현하는데 있어서는 이러한 OODB들이 괜찮은 접근법이 될 수 있다고 생각합니다. MineStore의 경우는 Dolphin과 Squeak를 지원하는 대표적인 OODB이며, OmniBase의 경우는 Dolphin에서 지원한다고 알고있습니다. 기타의 경우도 나름대로 OODB를 지원한다고 알고 있습니다. Dolphin Smalltalk에서는 Database Connection과 OmniBase를 통하여 DB에 접근합니다.


Smalltalk는 아이들을 위해서만 만들어진 언어는 아닙니다. 다만 언어의 철학이 '아이들도 쓸 수 있도록 쉽게 만들자'는 것일 뿐입니다. 따라서 이는 '교육용으로 만들어진 파스칼'이 현재의 Delphi의 모태를 이루고 있는 것을 볼 때 그리 설득력이 있어보이는 주장이 아닙니다. 여러분들이 흔히 쓰는 Visual Basic의 전신인 BASIC 역시 컴퓨터 초보자를 교육하기 위해서 만들어졌지만, 8비트 시절에는 훌륭한 운영체계 노릇을 할 수 있도록 방대한 명령어 집합을 가지고 있었습니다.


하지만 제 생각에는 강력하게 미는 회사가 없어서 그런것 같군요.. 솔직히 스몰톡언어 자체로만 보면 깔끔함이라든지 개념은 오히려 자바보다 더 좋죠. 단지 자바와의 차이는 자바는 선이라는 강력한 벤더가 민다는 거고 스몰톡은 대형회사나 유명한 회사가 자사 어플 개발에 쓰지 않는 다는 거죠..


이 문제는 저도 정남님과 같은 생각입니다. 예전에 제가 하드웨어쪽으로 공부할 일이 있어서 Forth라는 언어를 공부했을 때, 그쪽 포럼에 계신 분이 "만약 필립 칸이 Turbo Forth를 만들었다면 Forth의 역사가 다시 쓰여졌을 것이다"라는 말을 하신 적이 있어요. 만약 "Turbo Smalltalk"나 "Visual Smalltalk"(마이크로소프트)가 만들어졌다면 아마 Smalltalk가 무지 발전했을 것입니다. Oracle이나 기타 다른 회사에서 Smalltalk를 가지고 응용 프로그램을 개발한다면 Smalltalk는 상당히 많이 알려지게 될 것입니다. 그런데 불행하게도 Smalltalk는 비주류 언어로써, 단지 객체지향에 대한 개념을 설명할 때 잠시 언급되는 정도로 그치고 있습니다. 이는 특히 우리나라의 경우에 더 심합니다. 유럽의 경우는 아직도 Smalltalk를 사용하는 곳이 많고, 제가 공부하고 있는 Dolphin Smalltalk 역시 영국의 Object-Arts 사에서 개발한 것입니다. 그쪽에는 컴퓨터 잡지에 Smalltalk의 공개용 버전을 배포하고 사람들에게 알리는 모양입니다. 우리나라처럼 Microsoft사의 개발 도구들만이 주류를 이루고 있는 모습과 상당히 비교된다고 할 수 있습니다.


어쨌건 현재 주류로 쓰이는 언어가 C/C++에서 이제는 Sun의 Java로 옮겨가고 있습니다. 그러나 그렇다고 해서 Smalltalk에 전혀 손을 데지 않을 수 없다고 저는 생각합니다. 오히려 Smalltalk가 가지는 그러한 장점을 이용해서 한 명이라도 많은 사람들이 Smalltalk를 공부하고, 그래서 좀 더 올바른 객체지향 개념을 적립할 수 있다면, 그리고 자신의 프로젝트에 활용할 수 있는 살아있는 지식을 배운다면 좋겠습니다. 물론 프로젝트 자체가 Smalltalk로 이루어진다면 참 좋겠지요. :)


Smalltalk는 정말 단순히 언어자체를 연구하거나 쓰는 쪽은 꽤 됩니다만. 상업성은 없다고 생각하는 것 같아요... 저도 스몰톡 공부할때 꽤 좋은건 많은 느낌이 드는데 막상 뭔가를 하려고 하면 할게 없다는 거죠... X와 연계해서 쓰기도 힘들고 , 윈도객체와 연동하기도 좀 그렇고 쓸만한 객체를 모아놓은 그런 것도 없고 CORBA지원명세 언어에는 있는데 바인딩 클래스는 없고... 간단한 그래픽 뷰어를 만들려 해도 결국 씨를 다시 써야 되니... 웹쪽으로 쓰면 좋을것 같기도 한데.. 서버와 연동해서 쓸 방법이 없고.... 결론은 언어는 괜찮은데 환경을 더 보강 해야 한다는 거죠.. 여러모로 씨와는 반대되는 언어 입니다.... 씨가 환경이 강력해서 지금도 많이 쓰는걸 보면 환경이 언어 자체보다 더 중요한건지... 씨는 대표적인 못만든 언어인데... 스몰특은 잘 만들어으면서도 별로 안쓰이는걸 보면.... 이상 잡담이었습니다.....


네. 정곡을 찌르는 지적을 해 주셨습니다. 처음 Smalltalk를 접한 게 약 3년 전의 일이었습니다. 그 때는 그저 그러려니 하고 넘어갔습니다. 제가 그 때 쓴 Smalltalk는 "Smalltalk Express"라고 하여, 실행파일도 아예 만들 수 없었고, 기초적인 GUI 도구가 있었을 따름입니다. 물론 Smalltalk를 이루고 있는 개발 환경들과 외부 DLL을 부를 수 있는 기술들이 있었지만, 그 당시에는 별로 Smalltalk에 관심이 없었습니다. 그도 그럴 것이 32비트인 Windows 95/98 체계에서 16비트의 Smalltalk를 쓴다는 것이 영 기분이 내키지 않아서일 것입니다.


그러나 98년 말에 Dolphin Smalltalk를 알게 되면서부터 저는 조금씩 달라지기 시작해습니다. 다만 99년에 국책 프로젝트 수행 문제 때문에 6개월 동안 Smalltalk를 공부하지 못한게 무지 아쉽지만, 결국에는 결심을 굳히고 Dolphin Smalltalk의 상용 버전을 구입하게 되었습니다. 정말 기분이 좋더군요. 공개용으로 나와 있는 Smalltalk보다 상용으로 만들어진 것이 훨씬 완성도가 있었습니다. 현재 자료실에 있는 Dolphin Smalltalk 2.1은 공개용입니다. 98년에 만들어진 Smalltalk환경입니다. 따라서 Dolphin Smalltalk 2.1만을 보게 되면 충분히 실망할 수도 있다고 생각합니다. 그렇지만 어디를 가서도 공개용으로 만들어진 개발 환경이 이와 같은 여러 가지 강력한 기능을 가지고 있는 환경은 매우 드물다고 생각합니다.


그러나 Dolphin Smalltalk 3.0을 구입해서 써 보니, 정말 '와~'하는 감탄사가 나오더군요. Windows98에 있는 대부분의 컨트롤을 지원하고 있었고, 알아보기 쉬운 개발 환경과 막강한 디버깅 기능은 저를 매료되게 만들었습니다. 또한 LiveUpdate 기능으로 Smalltalk 환경 자체를 패치해 주는 기능은 정말 압권이었습니다. 저는 아예 Database Connection, ADK, Web Development Kit, Socket Connection의 꾸러미를 함께 구입했습니다. 이렇게 함께 구입하면 가격이 매우 저렴하기 때문인데, 하나하나 공부하고 있습니다. 플러그-인 프로그램을 설치하면 Dolphin Smalltalk로 에플릿을 만들 수 있습니다. 물론 ADK를 사용해서 실행파일을 만들어 배포할 수도 있겠지요.


Dolphin Smalltalk의 경우는 Windows 운영체계의 기능을 수용하고, 모든 Windows의 API를 호출할 수 있을 뿐만 아니라, cdecl, stdcall, safecall과 같은 방식의 호출 관행을 지원하는 외부 DLL 함수를 사용할 수 있습니다. 2.1버전부터 조금씩 지원해 오던 COM/OLE 기능을 확장하여 3.0에서는 ActiveX 컨트롤을 불러와서 사용할 수 있게 되었습니다. 따라서 별도의 추가 비용 없이 GIF, JPG, MP3 등 운영 체계가(정확히는 Internet Explorer와 Windows Media Player가) 지원하는 파일 표시 기능들을 그대로 사용하고 있습니다. 정말 이는 저를 Smalltalk에 빠져들게 만들었습니다.


네, 분명히 지금의 Smalltalk환경은 C/C++이나 소위 '한다'하는 회사들이 밀고 있는 다른 언어들과는 비교가 안 될 정도로 빈약합니다. 이는 Forth에서도 마찬가지였었습니다. 그러나 결국 Forth는 내장 제어 시스템용 언어로밖에는 쓰이기가 힘든 실정이었고, 또한 그런 패러다임을 가지고 있었습니다. 그러나 Smalltalk는 Forth와는 좀 다른 상황을 가지고 있습니다. 시스템 자체가 GUI를 탄생하게 한 터라서, MS-DOS에서 돌아가는 Smalltalk/V 의 경우에도 자체적인 창 관리 시스템을 가지고 있었습니다. 일터(workspace)에서 객체들에게 지시(message)를 내림으로써 객체들과 대화하고 갈래 씻줄 탐색기(Class Hierarchy Browser)에서 Smalltalk에 어떤 갈래가 있는지를 검사하고 새로운 갈래를 만들며, 벌레잡이로 실시간 디버깅을 수행할 수 있습니다. 길수 탐색기(Method Browser)를 사용하여 특정 조건에 맞는 길수들을 연계 참조할 수 있으며, 각각의 Smalltalk 개발 회사들마다 제공하는 독특한 개발 도구들을 사용하면 응용 프로그램을 만들기에 부족함이 없는 환경이라고 감히 말하고 싶습니다. C/C++, Java, Delphi가 할 수 있는 일 중에 70%는 Smalltalk로 할 수 있고, Visual Basic에서 할 수 있는 일 중에는 90%를 Smalltalk가 할 수 있습니다. 물론 단순히 '할 수 있다'가 아니라 '더 잘 할 수 있다'는 말입니다.


분명히 Smalltalk의 발전 속도는 느립니다. 그러나 Squeak, Smalltalk-MT, Dolphin Smalltalk는 각자 나름대로의 영역에서 꾸준히 발전해 오고 있으며, Dolphin Smalltalk의 경우에는 Windows 운영 체계에서 제공하는 최신 기술들을 대부분 그대로 소화해 내고 있습니다. Object-Arts의 대여섯명밖에 안 되는 직원들과 Dolphin Community를 이루고 있는 Smalltalker들의 노력으로 Dolphin Smalltalk는 공히 비주얼베이식에 필적할만한 개발 환경을 가지게 되었습니다. 현재 DirectX 꾸러미의 Pre-release 버전이 출시되어 있으므로, 조만간 DirectX를 사용한 응용 프로그램들도 만들 수 있을 것입니다.


물론 저는 모든 일을 Smalltalk로 처리하려고 하지는 않습니다. 정남님께서도 말씀하셨듯이 C언어가 강한 부분이 분명히 있습니다. C가 널리 쓰일 때에도 사람들은 필요할 때 어셈블리 언어를 사용해서 코딩을 했습니다. Smalltalk를 쓸 때도 저는 이런 기분으로 프로그램을 만듭니다. 분명히 C가 강한 부분이 있다면, 이런 부분들은 DLL로 만들어서 Smalltalk와 연결을 시켜버립니다. 공부를 좀 더 해서 COM 부품을 만들어 낼 수 있다면 Smalltalk에 꽂아서 바로 객체로 사용할 수도 있을 것입니다. Dolphin Community의 "lan Bartholomew"는 "Smalltalk는 복잡한 부품들을 서로 이어주는 나사와 같은 존재"라고 했습니다. 저도 이 말에 동감합니다. 처음부터 모든 걸 C++을 써서 개발하는 것보다는 Smalltalk에서 필요한 객체들과 프로그램의 뼈대를 만들어 놓고, 필요할 때 DLL이나 외부 인터페이스를 통해서 이러한 것들을 구현해 내면 훨씬 빠른 생산성을 보장할 수 있습니다. Java 언어가 왜 JNI와 같은 규격을 만들었는지를 생각해 보면 쉽게 이해할 수 있으리라고 생각합니다. "오직 Smalltalk!"를 주장하는 시스템은 살아남을 수 없습니다. 그건 Smalltalk가 비주류 언어이기 때문이기도 하지만, 그만큼 다른 것들과의 친화력이 중요하다는 말입니다. 물론 Delphi처럼 굳이 파스칼을 쓰면서 C/C++을 쓸 필요가 없는 언어의 경우에는 상당한 장점을 가지고 있습니다만, 불행하게도 Smalltalk만으로는 모든 것을 해결해내지 못합니다. 그래서 Smalltalk는 다른 것들을 충분히 활용할 수 있도록 발전해 온 것이라고 생각합니다.


그런데 여기서 한 가지 정남님에게 여쭙고 싶은 것은, Smalltalk 환경을 비교하실 적에 과연 공정했느냐 하는 겁니다. 저는 상용 Smalltalk 시스템을 사용하기 때문에 감히 단언합니다. 현재 나와 있는 상용 Smalltalk와 Delphi나 Visual Basic, JBuilder 등의 개발 도구들은 어깨를 나란히 할 수 있을 정도의 자격이 있습니다. 물론 Enterprise Edition처럼 방대한 기능을 제공하는 Smalltalk는 매우 드물기는 합니다만, 적어도 Windows의 응용 프로그램 개발은 충분히 비교할 수 있는 대상이라고 생각합니다. 공개용 Smalltalk들의 환경이 정비되지 않은 것은 오히려 당연한 것일지도 모릅니다. Borland에서 공급하는 C++ 컴파일러의 경우에 주변 환경이 뭐가 있었습니까? 아무것도 없었습니다. 이런 걸 보면 공개용 Smalltalk와 상용 개발 도구를 비교한다는 건 공정하지 못하다고 생각합니다.


아직까지 Smalltalk가 걸어가야 할 길은 많습니다. 그러나 Smalltalk는 그 시스템과 언어가 가지는 끈질기고 독특한 생명력과 객체지향이라는 철학을 바탕으로해서 앞으로도 꾸준히 발전을 해 나갈 것입니다. 제가 여기서 Smalltalk 강좌를 연재하는 것도, 제가 배운 것들을 정리하여 알려드리고자 하는 목적도 있지만, Smalltalk로도 충분히 응용 프로그램 개발이 가능하고, 특히 프로그래밍을 공부하는 사람들이 보다 더 논리적인 틀 속에서, 공개용으로 나와 있는 훌륭한 개발도구를 자유롭게 사용하면서 프로그래밍의 기법들을 터득할 수 있었으면 좋겠다는 것입니다.


그게 잘 될지는 모르게습니다만, 중단하지 않고 꾸준히 글을 올릴 수 있는 저의 의지가 허락한다면, 힘들고 괴로운 일만은 아닐 거라고 생각합니다.


그럼 긴 글 읽어주셔서 감사합니다. 그리고 정남님께는 특별히 감사 드립니다. 그럼 안녕히 계세요.


Notes