어떻게 프로그래머가 되었죠?

저는 혼자서 공부했습니다. 첫 프로그래밍은 아홉 살 경에 아버지의 TRS-80 모델에서 했었구요. 물론 처음에는 장난 같은 것이었습니다. 화면에 'Hello world'를 띄우는 프로그램을 만들고는 마냥 즐거워 했죠. 그 뒤로 z80 프로세서를 바탕으로 만들어진 몇몇 기종을 거치면서 경험을 쌓았습니다.

공식적인 프로그래밍 코스는 거치지는 않았습니까?

컴퓨터 사이언스를 중심으로 얻은 B.S(Bechelor of Science) 학위를 갖고 있습니다.

매킨토시는 어떻게 사용하게 되었나요?

친한 친구가 IIci를 갖고 있었습니다. 우리는 아미가(Amiga) 상에서 게임을 만들어 보곤 했는데 맥이라는 새로운 기종의 가능성에 반해 버렸습니다. 맥에서 처음 만든 프로그램은 정말 조잡스러운 것으로 심지어 툴박스를 전혀 쓰지 않은 수준이었죠. 그 뒤에, 인사이드 매킨토시 시리즈를 섭렵하면서 차츰 익숙해 지게 되었습니다. 오스트렐리아에 IIsi가 출시된 다음 날 곧바로 구입을 한 뒤로 많은 향상이 이루어 진 것 같습니다.

맥은 윈텔과 상당히 다른 개발환경을 갖고 있는 것 같습니다. 몇 년 전에는 Lightspeed C, Think C, MPW C 같은 것이 주종을 이뤘고, 근자에는 코드워리어 C가 많이 쓰이고 있는데요. 현재 나와 있는 베이직 개발 환경도 상당수 있기는 하지만 리얼베이직을 제외하면 그렇게 만족스러운 성능을 보여 주지는 못 하고 있습니다. 사실 리얼베이직이 만들어져 나온 때와 거의 비슷한 시기에 다른 비주얼 환경이 개발되었지만 출시되자마자 더 이상 지원되지 않고 있기도 합니다. 왜 이런 일이 벌어지는 것 같습니까?

글쎄요. 프로그래밍 랭귀지를 하나 만든다는 것은 사실 상당한 신념을 가져야 되는 일입니다. 대다수 회사들의 엔지니어링 팀은 위지윅 HTML 에디터를 만드는 쪽에 더 치중하는 것 같네요. 그러다 보니 맥 쪽의 개발 환경은 주로 '나홀로 프로그래머'들이 재미삼아 만든 것들이 대부분이죠. 프로그래머들이 개발 환경을 만드는 이유는 크게 두 가지 중 하나인 듯합니다. 먼저, 자신이 정말 만들어 낼 수 있는지 어떤지 재미삼아 해보는 것입니다. 그리고, 새롭게 떠오른 아이디어가 정말 되는지 확인해 보기 위해서입니다. 그러므로, 이들이 만들어 내는 환경은 상업적인 고려는 별로 없죠. 사실, 이들은 자신의 아이디어가 실현되는 순간 그 프로젝트는 관두고 다른 아이디어에 몰두합니다.

저도 그런 나홀로 프로그래머 중의 한 명이었습니다. 그런데, 어느 날 가만히 생각해 보니 이런 식으로 아이디어 사이를 왔다갔다하는 것보다 뭔가 하나라도 제대로 완성하는 것이 좋을 것 같더군요. 다행히 리얼베이직은 광범위한 성격의 프로젝트여서 다양한 아이디어를 다 담아낼 수 있었습니다. 프로그래머 혼자 끄적거려 본 프로그램을 하나의 제품으로 만들어 내려면 제대로 된 회사가 프로젝트를 확실하게 다듬어 주어야 합니다. 대표적인 예가 코드워리어를 만들어 낸 메트로웍스(Metrowerks)죠. 그들은 C/C++ 컴파일러를 나홀로 프로그래머에게 사들여서 멋진 제품으로 바꾸어 내놓았습니다. 물론 어떤 회사가 개인 프로젝트를 사들여 제품화 하는 데는 몇 가지 요소가 고려됩니다. 그 제품이 노리고 있는 틈새시장의 크기와 경쟁 같은 것 말이죠. 그간 맥 플랫폼이 활기가 없어서 프로그래밍 환경 개발도 주춤했습니다.

맥에서 프로그래밍 하는 건 어떤가요? 윈텔에 비해 낫습니까?

좋은 점도 있고 나쁜 점도 있습니다. 윈도우즈 API와 맥의 툴박스를 비교해 보면, 윈도우즈 API는 조금 더 상위 레벨에서 움직인다고 할 수 있습니다. 그래서 윈도우즈 프로그래밍을 하다 보면 OS와 경쟁 관계처럼 되는 경우가 왕왕있죠. 이에 반해 맥 툴박스는 그야말로 하위 레벨에서 움직입니다. 단순한 애플리케이션을 만드는 것도 상당히 까다롭다는 단점은 있지만 그만큼 더 제약없이 만들어 낼 수 있습니다.

놀라운 얘기군요. 대개 도스 프로그래머들이 맥을 비판할 때 OS에 의해 너무 많은 부분이 좌우되어서 제약이 많다고 얘기하는 것 같던데요?

그거야 자기들이 도스에서 만들고 있으니까 그렇게 얘기하는 것 아니겠습니까? 맥 오에스가 윈도우즈에 비해 상당히 더 하위 레벨에서 움직이고 있는 데 반해 도스와 맥 오에스는 개념상의 차이가 크지 않은 것 같습니다. 사실 애플이 매킨토시를 만들 때 마이크로소프트와 긴밀하게 공동작업했다는 사실을 잘 알쟎아요. 조금 이상한 얘기지만 상당수의 윈도우즈 API는 맥 툴박스와 굉장히 비슷한 것 같습니다.

개발자 입장에서 OS X이 어떤 변화를 가져올 것 같나요? 리얼베이직 사용자나 일반유저들에게 있어서 말이죠.

변화는 뭐랄까요... 조금 미묘한 형태로 나타나겠지만 실제 사용자가 느끼기에는 상당한 수준이 될 것입니다. 실제 눈에 보이는 변화외에도 선점형 멀티테스킹 같은 것은 훨씬 더 안정적인 느낌을 주지 않을까 합니다. 제 경험을 얘기해 보자면 윈3.11을 쓰다가 NT를 처음 썼을 때 언뜻 보기에는 별로 달라진 것이 없는 것 같았지만 쓰다 보니 아주 만족스러웠습니다. 멀티테스킹이 가능했으니까요.

애플이 계속해서 살아남을 수 있을까요? 하드웨어-운영체계의 질적인 측면에서 애플의 미래를 어떻게 보고 있는지요? 상업적인 측면에서 애플의 생존 가능성을 평가해주세요.

당연히, 애플은 계속 살아남을 것이고 더욱 성장할 가능성이 큽니다. 리얼베이직은 애플에 대한 지원을 계속해 나갈 작정입니다. 애플의 성공을 좌우하는 가장 중요한 요소는 새롭게 자각한 상업적 감각을 잘 유지할 수 있느냐의 여부인 것 같습니다. 얼마 전까지만 해도 애플은 거대한 '나홀로 프로그래머' 집단 같았습니다. 온갖 소그룹 별로 자신들의 아이디어를 시험해 보기 바빴고 그런 잡동사니들이 정리되지 않은 상태로 플랫폼 전체는 몰락의 길을 걷고 있었죠. 이런 추세가 바뀐 것은 애플이,

'독자적인 것을 만드는 것보다 다른 데서 라이선스 하는 것이 훨씬 더 비용이 적게 들고, 안정적이고, 호환성도 높은 제품을 시장에 빨리 내놓을 수 있다.'

라고 얘기하면서부터입니다.

베이직은 어떤 맥 유저들이 쓴다고 생각하세요? C로 프로그래밍하던 사람들이라고 생각합니까? 아니면 애플스크립트 프로그래머? 아니면 지금은 버려진 하이퍼카드 프로그래머? 그리고 어느 시기에 사용자들이 파일 메이커 프로(File Maker Pro) 같은 데이터베이스를 커스터마이즈하려고 하는 것 같습니까?

그 문제에 관해서라면, 일반적으로 자신의 작업에 맞는 툴을 고르는것 아닐까요? 그냥 다른 애플리케이션을 단순하게 자동화하는 것이라면 애플스크립트만 쓰는 것이 리얼베이직보다 더 낫습니다. 심하게 일반화해서 얘기하자면 맥 개발 툴은 크게 두 종류로 나뉩니다. 하나는 하위 레벨 툴입니다. 코드워리어 같은 것이 여기에 속하죠. 모든 것이 다 가능하지만 배우기가 너무 어렵다는 단점이 있습니다. 반면, 디렉터 같은 상위 레벨 툴은 배우기는 쉽지만 기능이 매우 제한적입니다. 리얼베이직은 이 둘의 갭을 메꾸어 보고자 만들어진 것입니다. 사용자가 진행하려는 프로젝트가 디렉터 같은 것으로 충분하다면 디렉터만 쓰는 것이 현명할 것입니다. 파일메이커 얘기를 하셔서 말인데요. 파일메이커 프로는 정말 뛰어난 제품이고 사용자가 가진 문제점이 파일메이커만으로 해결된다면 역시 파일메이커만 쓰는 것이 현명한 선택입니다. 그것으로 안 된다고 느낀다면 다른 툴을 찾아 봐야 겠지만요. 리얼베이직 2.0은 데이터베이스와 연계성을 대폭 보강해서 내놓을 예정입니다.

'객체 지향 프로그래밍' 이라는 말이 리얼베이직을 고려하는 사람들에게 겁을 주진 않을까요? 객체 지향 프로그래밍이 어떤 영향을 줄 거라고 봅니까?

사용자는 객체 지향 프로그래밍에 대해 걱정할 필요가 없습니다.기초적인 수준에서는 다 알아서 조정되니까요. 프로그램을 완전하게 사용할 필요가 있을 때 배우면 됩니다. 대개의 유저들은 그냥 주어진 대로 사용하는 것으로도 충분할 겁니다.

리얼베이직은 비쥬얼베이직의 소스코드도 실행되는것 같던데요. 그렇습니까?

당연합니다. 정확히 말하자면 더 훌륭하게 실행 됩니다. 왜냐하면 리얼베이직은 컴파일 언어로 디자인되었고 비쥬얼베이직은 기본적으로 인터프리팅 언어니까요.

그렇다면 윈도우즈 개발자들이 맥 용으로도 자신들의 제품을 내놓을 수 있다는 얘기입니까?

어떻게 아셨죠? 이미 그런 일이 벌어지고 있습니다. 이를 테면 이런 메일이 오고 있습니다.

'우리는 비쥬얼베이직을 이용해서 애플리케이션을 만들고 있는데 맥 유저들에 깊은 관심을 갖고 있다. 그런데 리얼베이직이 맥에서의 비쥬얼베이직에 해당한다던데...'

그리고 리얼베이직 2.0 프로버전은 정말 확실한 크로스플랫폼이 될 예정입니다. 실제 우리 고객 중에는 심지어 비주얼베이직은 사용하지 않고 리얼베이직만 쓰기 시작한 회사도 있습니다. 맥뿐만 아니라 윈도우즈 회사도 말입니다.

맥이 윈도우즈를 돕는 상황을 보는 것은 맥 유져에게는 참 즐거운 일입니다. 베이직과 C는 상당히 다른 방향으로 성장해 왔는데요. 어떤 사람은 베이직이 고급 언어여서 맥을 완전히 컨트롤하는 능력이 C에 비해 떨어진다고 합니다. 속도도 C 코드보다는 늦고 말이죠.

그 질문에 대한 답은 두 가지로 나누어서 해야 할 것 같습니다. 먼저, 순수하게 언어 그 자체적인 측면에서 볼 때 리얼베이직은 C보다 더 많은 장점이 있습니다. 리얼베이직은 진정한 dynamic-length string, 배열 한계 점검 기능, 가비지 컬렉션(garbage collection), 선점형 멀티테스킹 등을 지원합니다. 이런 특징들이 있기 때문에 같은 크기의 코드라면 C가 더 빠르게 실행되는 것입니다. 하지만 C 코드가 훨씬 더 충돌을 잘 일으킵니다. 결국 C 언어로 충돌에 대한 방비책을 일일이 마련하다 보면 아마 리얼베이직 코드의 실행속도와 거의 비슷해질 것입니다. 그리고 버전 3이 나올 때 쯤이면 속도차도 거의 없어질 것으로 생각합니다. 또한 리얼베이직은 훨씬 더 풍부한 윈도우즈, controls, 클래스들을 제공합니다.

그리고 전통적인 고급 언어 환경들이 기존의 한계를 하나 둘 뛰어넘고 있는 것이 근자의 추세입니다. 속도 면에서나, 기능면에서나 플러그-인 아키텍춰를 지원함으로써 상당한 향상이 이루어지고 있습니다. 리얼베이직이라고 예외는 아니죠. 리얼베이직도 자체 플러그-인 포맷을 지원하므로 여러 기능을 매끄럽게 첨가할 수 있습니다. 플러그-인을 만드는 개발자는 새로운 메쏘드(methods), 클래스, 그리고 controls를 만들어서 완벽하게 연계시킬 수 있습니다. 하이퍼카드가 XCMD/XFCN을 이용해서 풍부한 기능 확장을 해 왔던 것처럼 말이죠. 리얼베이직 프로그램은 또한 XCMD/XFCN도 쓸 수 있습니다. 리얼베이직 프로그램은 CFM(Code Fragment Manger)을 바로 불러 쓸 수도 있고, 맥 툴박스를 완벽하게 포함시킬 수도 있습니다. 리얼베이직은 자체적인 애플 이벤트를 위한 루틴을 갖고 있지만 애플스크립트를 이용하는 것이 더 편리할 수도 있습니다. 그런데, 이 점도 걱정이 없습니다. 리얼베이직은 애플스크립트도 지원하니까요.

플러그-인과 XFCN은 프로그래밍 언어의 성장에 있어 매우 중요한 것이 사실입니다. 현재까지 나와 있는 리얼베이직 용 XFCN 중 대표적인 것을 소개해 주세요.

우리는 리얼베이직 자체의 플러그-인 포맷을 지원합니다. 대표적인 것이라면 퀵 드로우3D 지원, 자바 지원을 위한 것들을 들 수 있습니다.

맥 사용자층이 얇다는 점이 장애 요인으로 작용하진 않나요?

글쎄요. 그건 어떻게 보느냐에 달려 있습니다. 플랫폼을 판단하는 데 있어 유저 베이스의 크기만을 기준으로 판단해서는 안됩니다. 오히려 얼마나 많은 양의 소프트웨어를 팔수 있느냐가 훨씬 중요하죠. 그런 면에서, 맥 마켓은 윈도우즈 마켓보다 훨씬 더 매력적입니다. 왜냐하면 맥 개발환경은 아직 완전히 성숙한 상태가 아니니까요. 윈도우즈 쪽이었다면 비쥬얼베이직의 명성에 완전히 짓눌렸을 것입니다. 그리고 제 생각에는 리얼베이직을 이용해서 프로그래밍할 때 플랫폼 제한성은 별로 걱정할 필요없습니다. 리얼베이직 2의 프로 버전은 윈도우즈까지 아우르는 완벽한 크로스플랫폼을 지원할 예정이니까요. 그리고 앞으로 나올 버전은 더욱 많은 플랫폼을 지원할 예정입니다.

최근 사용해 본 프로그램중 Sigerson이라는 아주 유용한 Sherlock 관련 유틸리티가 있습니다. 인터페이스도 훌륭하고 기능도 탁월해서 매우 흡족하게 쓰고 있는데요. 그런데 "About..." 박스에 보니 리얼베이직으로 만들었다고 되어 있더군요.

고급 언어로는 '본격적인' 소프트웨어를 개발할 수 없다고 생각하는 사람은 가능한 어렵게 일을 하는 수밖에 없다고 믿고 있는 사람들입니다. 그런 논조의 글을 쓴 컬럼니스트의 생각은 이런 식이죠.

'고급언어 환경은 아마츄어 프로그래머들이 더 많은 소프트웨어를 양산해 내는 데 도움을 줄 것 같다.'

그 다음에는 이런 말이 뒤따라 나옵니다.

'만약 #!$#를 잘 알지 못한다면 친구나 자기 자신을 위한 것 외에는 소프트웨어를 만들면 안 된다. 제대로 하려면 무엇이든 직접 만들어야 한다. 절대 다른 애플리케이션이 당신 프로그램의 버튼을 만들게 해서는 안 된다. 절대 팝업메뉴를 드랙 앤 드랍(Drag and Drop)만으로 만들어서는 안된다. 무엇이든 직접 코딩해야 한다!'

제 생각에는 모든 사람이 자신의 창조성을 충분히 표현하게 하는 것이 의미가 있습니다. 아마도 Sigerson은 리얼베이직이 없었다면 개발되기 힘들었을 것입니다.

리얼베이직은 이미 상당수 유저를 확보하고 있고, 이들은 매우 액티브하게 활동하는 것 같습니다. 여기저기 리얼베이직 유저들이 운영하는 게시판을 힘들지 않게 찾아볼 수도 있죠. 그런 활동이 리얼베이직의 성공에 어느 정도 중요하다고 보는지요? 혹시 직접 참여해 본 적도 있습니까?

물론 그분들은 매우 중요한 존재입니다. 그분들은 열정적으로 리얼베이직을 전도하고 있습니다. 또한 리얼베이직 활용에 있어 발생하는 문제를 스스로 해결해주는 역할을 하고 있기도 합니다. 저 또한 리얼베이직 메일링 리스트에 가급적 자주 참여하려 하고 있습니다. 아무도 해결하지 못 한 문제에 대한 답을 제시하기도 하고, 그분들이 제기한 문제점을 잘 살펴서 향후 출시될 리얼베이직에서 첨가해야 될 기능들을 결정하려고 하고 있습니다.

대부분의 베이직 프로그래머들은 가비지 컬렉션(Garbage Collection)이라는 괴물과 맞닥뜨리게 됩니다. 이것 때문에 프로그램이 까닭없이 죽어버리곤 하는데요. 유독 베이직에서 이 문제가 자주 발생하는 것 같습니다. 베이직만 이런 문제를 갖고 있는 것이 맞는지요, 그리고 리얼베이직은 가비지 컬렉션을 어떤 식으로 접근하고 있습니까?

그건 아마도 예전의 느린 컴퓨터 상에서 베이직을 실행했기 때문에 생긴 문제라고 생각합니다. 또한 그건 베이직만이 유일한 가비지 컬렉션을 갖춘 언어였다는 점과도 관련이 있습니다. 즉, 사용되지 않고 있는 객체를 정리하기 위해서 힙(heap) 전체를 주기적으로 스캔해야 하기 때문에 얘기하신 그런 문제점이 나타납니다. 리얼베이직은 점진적인 가비지 컬렉터(progressive garbage collector)를 사용합니다. 가비지 컬렉션을 가급적 실행 시간 전체에 걸쳐 골고루 분산시키는 것이죠. 따라서 문제는 최소화됩니다.

마지막 질문입니다.개발자의 한 명으로서 애플사의 사용자와 개발자에 대한 태도를 어떻게 평가합니까? 애플이 작업에 도움을 주는 경우도 있는지요? 애플이 개발자들을 어떤 식으로 도와야 할까요?

제가 보기에는 애플이 이제서야 개발자와 사용자들의 의견에 귀를 기울이는 것 같습니다. 이 점은 애플 제품 라인과 운영체계가 발전되어가는 방향을 보면 알 수 있습니다. 우리 리얼소프트는 애플사와 매우 긴밀한 관계를 맺고 있습니다. 덕분에 리얼 베이직은 여러 가지 신기술을 신속하게 첨가해 나가고 있는 것이죠. 제가 애플 성공의 정답을 얘기할 수는 없는 것 같고 그저 최근의 제품 전략을 잘 유지해 나가기만을 바랄 뿐입니다. 옛날처럼만 하지 않으면 됩니다.