객체지향의 근본

https://youtu.be/oKg1hTOQXoY?si=gIJqYToQttL-zIhY

Alan Kay at OOPSLA 1997 - The computer revolution hasnt happened yet

Alan Kay OOPSLA 1997 강연 “The computer revolution hasn’t happened yet” 전문 번역입니다.

Thank you.
감사합니다.
Well, I presume most of you have been up all night.
글쎄요, 여러분 대부분이 밤을 새웠을 거라고 생각합니다.
I can’t imagine ever seeing this many programmers at eight o’clock in the morning.
아침 8시에 이렇게 많은 프로그래머들을 보는 것은 상상도 못했습니다.
I guess this is the largest bathroom I’ve ever given a talk in.
내가 지금까지 강연한 곳 중 가장 큰 화장실인 것 같네요.
That was just a test to see if you could understand me.
그건 여러분이 제 말을 알아들을 수 있는지 테스트한 거였습니다.
I can’t actually understand myself up here.
저도 여기 올라와서 제 목소리를 잘 못 알아듣겠네요.
I actually haven’t been to OOPSLA since the first one and, when I got invited to give this talk, while I was thinking—well, should I go, or should I not, or what should I do, it occured to me that this conference, on this day, is pretty much in the epicenter of the twenty-fifth anniversary of Smalltalk.
사실 첫 번째 OOPSLA 이후로 한 번도 오지 않았는데, 이번 강연 초대를 받고 고민하다가 문득 깨달았습니다. 바로 오늘 이 컨퍼런스가 Smalltalk 25주년 기념의 정중앙에 있다는 사실을요.
The one page interpreter scheme that I wrote out was done just a few weeks ago twenty-five years ago.
내가 한 페이지로 작성한 그 인터프리터 스킴은 정확히 25년 전, 불과 몇 주 전에 완성된 것이었습니다.
The first working version of it was done in a few weeks from now, twenty-five years ago, so this is about in the center and—let me see if I can get our motto up on—could I have that first slide, please?
그것의 첫 작동 버전은 지금으로부터 몇 주 후, 정확히 25년 전에 만들어졌으니, 오늘은 그 한가운데쯤 됩니다. — 우리 모토를 화면에 띄워볼까요? 첫 번째 슬라이드 부탁드립니다.
I’m not gonna give a historical talk, as I finally discharged those obligations in the History of Programming Languages Conference a couple of years ago, but I thought it might be interesting for some of you, who might not have been computing for the last twenty-five or thirty years, to take a two-minute trip.
저는 역사 강연을 하려는 게 아닙니다. 이미 몇 년 전 History of Programming Languages Conference에서 그 의무를 다 마쳤으니까요. 다만 지난 25~30년 동안 컴퓨팅을 경험하지 않은 분들에게는 2분 정도의 짧은 여행이 재미있을 것 같아서요.
I believe that this set of images basically goes back to 1973 and 1974 at Xerox PARC—[they] show some of the first children that we worked with.
이 이미지들은 기본적으로 1973~1974년 Xerox PARC 시절로 거슬러 올라갑니다. 우리가 처음 함께 일했던 아이들 몇 명을 보여주고 있죠.
The music that you’ll hear on this clip was composed by one of the members of our group, Chris Jeffers.
이 클립에서 들리실 음악은 우리 그룹 멤버 중 한 명인 Chris Jeffers가 작곡한 것입니다.
It’s called “The Happy Hacker”, in case you want a theme song.
테마송으로 쓰고 싶으시다면 “The Happy Hacker”라고 합니다.
It’s played in real time FM synthesis that we developed for the Alto computer.
Alto 컴퓨터를 위해 우리가 개발한 실시간 FM 합성으로 연주된 곡입니다.
This is the forerunner of the workstations and the Macintosh without any additional sound synthesis hardware at all, because why should you have that if your computer is designed well.
이것은 워크스테이션과 매킨토시의 선구자였고, 추가 사운드 합성 하드웨어가 전혀 없이도 작동했습니다. 컴퓨터가 제대로 설계됐다면 그런 하드웨어가 왜 필요하겠습니까?
I think you’ll get a little picture of it, but before I turn on that clip, let’s just for the heck of it see how many people are in this room today, who participated in the Xerox PARC Smalltalk experience, between roughly 1971 and 1983.
조금이나마 그 당시 분위기를 느끼실 수 있을 거라 생각합니다. 그런데 클립을 틀기 전에, 재미로 한 번 물어보죠. 오늘 이 자리에는 1971년부터 1983년 사이에 Xerox PARC Smalltalk 프로젝트에 참여했던 분들이 얼마나 계신가요?
Could you stand up? Let’s see if we—how many people are actually here.
일어나 주시겠어요? 실제로 몇 명이나 계신지 봅시다.
Anybody without gray hair?
회색 머리가 아닌 분 계신가요?
Thank you. Okay, let’s roll that, that clip.
감사합니다. 자, 이제 그 클립을 틀어주세요.
Well, that was things as they existed about twenty-five years ago.
자, 그것이 약 25년 전의 모습이었습니다.
The other thing I wanted to do in the beginning part of this talk—I tried to figure out how to work my way into it, and I finally remembered a paper that Dijkstra—I don’t know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano Dijkstras.
강연의 서두에서 하고 싶었던 또 다른 일은—어떻게 시작할까 고민하다가 Dijkstra의 한 논문을 떠올렸습니다. Dijkstra를 직접 만나보신 분은 얼마나 되실지 모르겠지만, 컴퓨터 과학에서 오만함은 ‘nano Dijkstra’ 단위로 측정된다는 건 아실 겁니다.
He once wrote a paper—of the kind that he liked to write a lot of—which had the title On the fact that the Atlantic has two sides.
그가 좋아하던 스타일의 논문 중 하나로, 제목이 “대서양에는 두 개의 해안이 있다는 사실에 관하여”였습니다.
It was basically all about how different the approaches to computing science were in Europe, especially in Holland and in the United States.
그 논문은 기본적으로 유럽, 특히 네덜란드와 미국의 컴퓨팅 과학 접근 방식이 얼마나 다른지에 관한 내용이었습니다.
In the US, here, we were not mathematical enough, and gee, in Holland, if you’re a full professor, you’re actually appointed by the Queen, and there are many other uh important distinctions made between the two cultures.
미국에서는 우리가 수학적으로 충분히 엄격하지 않다고 했고, 네덜란드에서는 정교수가 되면 실제로 여왕이 임명하며, 두 문화 사이에는 그 외에도 많은 중요한 차이가 있다는 것이었습니다.
So, uhm, I wrote a rebuttal paper, just called On the fact that most of the software in the world is written on one side of the Atlantic.
그래서 저는 반론 논문을 썼는데, 제목은 “세계 대부분의 소프트웨어는 대서양 한쪽에서 작성된다는 사실에 관하여”였습니다.
It was basically about that, computers form a new kind of math.
그 논문은 기본적으로 컴퓨터가 새로운 종류의 수학을 형성한다는 내용이었습니다.
You can’t judge them. They don’t really fit well in classical math, and people who tried to do that are basically indulging in a form of masturbation.—Maybe even realizing it.
그것들을 고전 수학으로 판단할 수 없으며, 그렇게 하려는 사람들은 사실상 자위행위나 다름없다는—어쩌면 본인도 알고 있을지도 모를—내용이었습니다.
It was kind of a practical math, that was.
그것은 일종의 실용적인 수학이었습니다.
The balance was between making structures that were supposed to be consistent of a much larger kind than classical math had ever come close to dreaming of attempting, and having to deal with the exact same problems that classical math of any size has to deal with, which is being able to be convincing about having covered all of the cases.
그 균형은 고전 수학이 꿈도 꾸지 못할 정도로 거대한 일관된 구조를 만들면서도, 동시에 어떤 크기의 고전 수학이라도 다뤄야 하는 똑같은 문제—즉 모든 경우를 다 다뤘다는 것을 설득력 있게 증명하는 문제—를 다뤄야 하는 데 있었습니다.
There’s a mathematician by the name of Euler, whose speculations about what might be true formed twenty large books, and most of them were true.
Euler라는 수학자가 있는데, 그가 ‘무엇이 참일 수 있는가’에 대한 추측으로 20권 분량의 큰 책을 썼고, 그 대부분이 실제로 참이었습니다.
Most of them were right. Almost all of his proofs were wrong, and many PhDs in mathematics in the last and this century have been formed by mathematicians going to Euler’s books, finding one of his proofs, showing it was a bad proof, and then guessing that his insight was probably correct, and finding a much more convincing proof.
그 대부분이 옳았습니다. 그의 증명은 거의 모두 틀렸지만, 지난 세기와 금세기의 많은 수학 박사 학위가 Euler의 책을 찾아 그의 증명을 검토하고, 그것이 잘못된 증명임을 밝힌 뒤 “그의 통찰은 아마도 옳았을 것”이라고 추측하며 더 설득력 있는 증명을 찾아내는 과정으로 이루어졌습니다.
So debugging actually goes on in mathematics as well.
즉, 디버깅은 수학에서도 실제로 이루어지고 있다는 것입니다.
I think the main thing about doing OOP work, or any kind of programming work, is that there has to be some exquisite blend between beauty and practicality.
OOP 작업이든 어떤 종류의 프로그래밍 작업이든 가장 중요한 것은 아름다움과 실용성 사이의 절묘한 조화라고 생각합니다.
There’s no reason to sacrifice either one of those, and people who are willing to sacrifice either one of those, I don’t think really get what computing is all about.
그 둘 중 어느 하나라도 희생할 이유는 없으며, 그렇게 희생하려는 사람들은 컴퓨팅이 본질적으로 무엇인지 제대로 이해하지 못했다고 봅니다.
It’s like saying I have really great ideas for paintings, but I’m just gonna use a brush but no paint.
그건 “나는 그림에 대한 정말 훌륭한 아이디어가 있는데, 붓만 쓰고 물감은 안 쓰겠다”라고 말하는 것과 같습니다.
So my ideas will be represented by the gestures I make over the paper—and don’t tell any 20th century artist that, or they might decide to make a videotape of them doing that and put it in a museum.
그래서 내 아이디어는 종이 위에서 하는 몸짓으로 표현될 테고—20세기 예술가에게 이 말을 하지 마세요. 그들은 그 몸짓을 비디오로 찍어 박물관에 전시할지도 모르니까요.
I had this problem figuring out what to talk about.
강연 주제를 정하는 데 이런 문제가 있었습니다.
It’s always difficult because technical people always seem to know so much, but it’s interesting, again, to look at what is actually being done in the world under the name of OOP.
기술자들은 항상 많은 것을 아는 것처럼 보이니 주제를 정하기가 항상 어렵지만, 다시 한 번 세상에서 OOP라는 이름으로 실제로 무엇이 이루어지고 있는지 살펴보는 것은 흥미롭습니다.
I’ve been shown some very, very strange-looking pieces of code over the years by various people, including people in universities, that they have said is OOP code, and written in an OOP language—and actually, I made up the term object-oriented, and I can tell you I did not have C++ in mind.
지난 몇 년 동안 대학 사람들을 포함해 여러 사람들로부터 “이게 OOP 코드다”, “OOP 언어로 작성됐다”라고 하며 보여준 매우 이상한 코드들을 봤습니다. 사실 object-oriented라는 용어는 제가 만들었는데, C++을 염두에 두고 만든 것은 절대 아니었습니다.
An important thing here is—I have many of the same feelings about Smalltalk—and I’m not going to try and do Smalltalk in here, because I think there is one really important thing about Smalltalk, and some of the languages like it that we should pay really, really close attention to—but it has almost nothing to do with either the syntax or the accumulated superclass library.
여기서 중요한 점은—Smalltalk에 대해서도 비슷한 감정을 가지고 있다는 것인데—여기서 Smalltalk를 직접 시연하려는 것은 아닙니다. Smalltalk와 비슷한 언어들이 가진 정말 중요한 한 가지가 있는데, 그것은 문법이나 축적된 슈퍼클래스 라이브러리와는 거의 관계가 없기 때문입니다.
Both of these are taken as being the language, as though it was issued from some gods on Olympus.
둘 다 ‘언어’ 그 자체로 받아들여지는데, 마치 올림푸스 신들이 내려준 것처럼 말입니다.
So I want to talk a little bit more about my personal reaction to OOP when I started thinking about it in the sixties, and instead of making it a historical talk, to try and think about whether these reactions and insights have any place today.
그래서 1960년대에 OOP를 처음 생각했을 때의 제 개인적인 반응에 대해 조금 더 이야기하고 싶고, 역사 강연이 아니라 이 반응과 통찰이 오늘날에도 여전히 의미가 있는지 생각해 보고 싶습니다.
In the sixties things were quite mechanical.
1960년대에는 모든 것이 상당히 기계적이었습니다.
There’s a sense of simple mechanism because computers were as large as this room.
컴퓨터가 이 강연장만큼 컸기 때문에 단순한 기계라는 느낌이 강했습니다.
The one that Ivan Sutherland did Sketchpad on was the size of this room.
Ivan Sutherland가 Sketchpad를 만든 컴퓨터도 이 방 크기였습니다.
It was one of the last computers in the US large enough to have its own roof.
그것은 미국에서 자체 지붕을 가질 만큼 큰 마지막 컴퓨터 중 하나였습니다.
It was the building it was in.
그 컴퓨터 자체가 하나의 건물이었습니다.
But the programs were quite small and they had a lot in common with their mathematical antecedents.
하지만 프로그램은 상당히 작았고, 수학적 선행자들과 많은 공통점을 가지고 있었습니다.
One way of thinking about the semantics of math that was based on logic, is as interlocking gears.
논리에 기반한 수학의 의미론을 생각하는 한 가지 방법은 서로 맞물린 기어로 보는 것입니다.
Everything kind of has to fit together, and if it does, and everything is compatible at the end, you get the final turning of the shaft that you want.
모든 것이 서로 맞물려야 하고, 결국 모든 것이 호환되면 원하는 축의 최종 회전을 얻는 것입니다.
An analogy to these programs of the sixties is a dog house.
1960년대 프로그램에 대한 비유는 개집입니다.
If you take any random boards, nail, and hammer; pound them together and you’ve got a structure that will stay up.
아무 판자나 못, 망치를 가져와서 대충 박으면 서 있는 구조물이 완성됩니다.
You don’t have to know anything, except how to pound a nail to do that.
못을 박는 방법만 알면 됩니다.
Now, somebody could come along and look at this dog house and say, Wow! If we could just expand that by a factor of a hundred we could make ourselves a cathedral.
이제 누군가 그 개집을 보고 “와! 이걸 100배 확대하면 대성당을 만들 수 있겠다!”라고 할 수 있겠죠.
It’s about three feet high. That would give us something thirty stories high, and that would be really impressive.
높이가 3피트 정도니까, 100배 확대하면 30층 높이가 되고, 정말 인상적일 테니까요.
We could get a lot of people in there.
많은 사람들을 수용할 수 있을 테니까요.
The carpenters would set to work blowing this thing up by a factor of a hundred.
목수들은 그걸 100배로 키우는 작업에 착수할 것입니다.
Now, we all know, being engineers and scientists, that when you blow something up by a factor of a hundred, its mass goes up by a factor of a million, and its strength, which is mostly due to cross sections of things, only goes up by a factor of ten thousand.
우리 엔지니어이자 과학자인 우리는 모두 압니다. 무언가를 100배 확대하면 질량은 100만 배 증가하지만, 강도는 대부분 단면적에 의해 결정되므로 1만 배밖에 증가하지 않는다는 것을요.
When you blow something up [by] a factor of a hundred, it gets by a factor of hundred weaker in its ability, and in fact, what will happen to this dog house; it would just collapse into a pile of rubble.
100배 확대하면 강도가 100배 약해지기 때문에, 결국 그 개집은 그냥 무너져 잔해 더미가 될 것입니다.
Then there are two choices you can have when that happens.
그때 두 가지 선택지가 있습니다.
The most popular one is to say, Well, that was what we were trying to do all along.
가장 흔한 선택은 “음, 우리가 원래 하려던 게 바로 이거였어”라고 말하는 것입니다.
Put more garbage on it, plaster it over with limestone, and say…
그 위에 쓰레기를 더 올리고 석회로 회반죽을 바른 뒤 말하죠…


Alan Kay OOPSLA 1997 강연 “The computer revolution hasn’t happened yet” 전문 번역 계속입니다.
(이전 부분에서 이어집니다. 한 문장씩 영어 원문 → 한국어 번역 형식으로 제공합니다.)
Yes, we were really trying to do pyramids, not gothic cathedrals.
그래, 우리가 진짜 하려던 건 피라미드였지, 고딕 대성당이 아니었어.
That, in fact accounts for much of the structure of modern operating systems today.
사실 그것이 오늘날 현대 운영 체제 구조의 상당 부분을 설명해 줍니다.
Or, you can come up with a new concept, which the people who started getting interested in complex structures many years ago did.
또는 새로운 개념을 떠올릴 수도 있는데, 수년 전 복잡한 구조에 관심을 갖기 시작한 사람들이 그랬습니다.
They called it architecture.
그들은 그것을 ‘건축(architecture)’이라고 불렀습니다.
Literally, the designing and building of successful arches.
말 그대로, 성공적인 아치(arch)를 설계하고 만드는 것입니다.
A non-obvious, a non-linear interaction between simple materials to give you non-obvious synergies, and a fast multiplication of materials.
단순한 재료들 사이의 명백하지 않은, 비선형적인 상호작용으로 명백하지 않은 시너지를 만들어내고, 재료의 급속한 증식을 가져오는 것입니다.
It’s quite remarkable to people when I tell them that the amount of material in a cathedral, which is an enormous, physical structure, is less than the amount of material that was put into the Parthenon.
사람들에게 대성당—거대한 물리적 구조물—에 들어간 재료의 양이 파르테논 신전에 들어간 재료의 양보다 적다고 말하면 상당히 놀라워합니다.
The reason is that it’s almost all air, and almost all glass.
그 이유는 거의 대부분이 공기이고, 거의 대부분이 유리이기 때문입니다.
Everything is cunningly organized in a beautiful structure to make the whole have much more integrity than any of its parts.
모든 것이 아름다운 구조로 교묘하게 조직되어, 전체가 그 어떤 부분보다도 훨씬 더 큰 완전성을 갖게 만듭니다.
That’s the other way you can go, and part of the message of OOP was, that, as complexity starts becoming more and more important, architecture’s always going to dominate material.
그것이 또 다른 선택지이고, OOP의 메시지 중 하나는 복잡성이 점점 더 중요해질수록 건축(architecture)이 항상 재료(material)를 지배하게 된다는 것이었습니다.
And in fact, the sad fact, I think, about OOP, is people didn’t get interested in architecture because of the beauty of it.
사실 OOP에 대한 슬픈 사실은, 사람들이 건축의 아름다움 때문에 건축에 관심을 갖게 된 것이 아니라는 점입니다.
They’re only starting to get interested in architecture now, when the Internet is forcing everybody to do it.
그들은 이제야 인터넷이 모두를 강제하고 있을 때에야 건축에 관심을 갖기 시작했습니다.
That’s pretty pathetic.
그건 꽤 한심한 일이죠.
(여기까지가 dog house → cathedral 비유의 마무리 부분입니다. 강연은 이제 OOP의 본질, 복잡성, 그리고 컴퓨터 혁명이 아직 일어나지 않은 이유로 자연스럽게 이어집니다.)


  감사합니다. 여러분 대부분이 밤을 새우셨을 거라 짐작합니다. 아침 8시에 이렇게 많은 프로그래머들을 볼 수 있을 거라고는 상상도 못 했네요. 제가 강연해 본 화장실 중에서 가장 큰 곳인 것 같습니다. 제 말을 이해할 수 있는지 알아보기 위한 농담이었습니다. 사실 저도 여기서 제 말이 잘 안 들리네요. 저는 첫 번째 OOPSLA 이후로 참석하지 않았습니다. 이 강연에 초대받았을 때 갈지 말지, 가서 무엇을 할지 고민했습니다. 그리고 오늘 이 회의가 스몰토크 25주년의 한가운데에 있다는 사실이 떠올랐습니다. 제가 작성했던 한 페이지 분량의 인터프리터 스킴은 25년 전, 바로 몇 주 전에 완성되었습니다. 첫 번째 작동 버전은 25년 전 이맘때쯤, 지금으로부터 몇 주 뒤에 완성되었죠. 지금이 딱 그 중간 지점입니다. 첫 번째 슬라이드를 띄워주시겠습니까? 역사적인 강연을 하고 싶지는 않습니다. 몇 년 전 프로그래밍 언어 역사 회의에서 그런 의무를 다 마쳤기 때문입니다.

  그러나 지난 25년이나 30년 동안 컴퓨팅을 하지 않은 분들을 위해 2분 정도의 짧은 여행을 하는 것이 흥미로울 것이라 생각했습니다. 이 이미지들은 기본적으로 1973년과 1974년의 제록스 파크로 거슬러 올라갑니다. 우리가 함께 작업했던 첫 번째 아이들의 모습을 보여줍니다. 이 클립에서 들으실 음악은 우리 그룹 멤버 중 한 명인 크리스 제퍼스가 작곡한 것입니다. 테마곡이 필요하시다면 이 곡의 제목은 행복한 해커입니다. 이 곡은 우리가 알토 컴퓨터를 위해 개발한 실시간 FM 합성으로 연주되었습니다. 이것은 워크스테이션과 매킨토시의 선구자격인 기기로, 추가적인 사운드 합성 하드웨어가 전혀 없었습니다. 컴퓨터가 잘 설계되었다면 굳이 그런 것이 필요할 이유가 없기 때문입니다. 클립을 틀기 전에 재미삼아 1971년에서 1983년 사이 제록스 파크 스몰토크 경험에 참여했던 분들이 오늘 이 방에 몇 분이나 계신지 확인해 보겠습니다.

  그래서 일어서 주시겠습니까? 흰머리가 없는 분도 계신가요, 감사합니다. 이제 그 클립을 틀어주세요. 25년 전 상황은 대략 저러했습니다. 이 강연의 초반부에서 하고 싶은 또 다른 이야기가 있습니다. 어떻게 이야기를 풀어갈지 고민하다가 마침내 다익스트라의 논문이 떠올랐습니다. 여러분 중 다익스트라를 만나본 분이 얼마나 될지 모르겠지만 컴퓨터 과학에서의 오만함은 나노 다익스트라 단위로 측정된다는 농담을 아실 겁니다. 그는 예전에 대서양에는 두 개의 면이 있다는 사실에 대하여라는 제목의 글을 쓴 적이 있습니다. 그 글은 유럽, 특히 네덜란드와 미국의 컴퓨터 과학 접근 방식이 얼마나 다른지에 대한 것이었습니다. 미국에서는 수학적이지 못하고 네덜란드에서는 정교수가 되려면 여왕의 임명을 받아야 한다는 등 두 문화 사이의 중요한 차이점을 다루었습니다.

  그래서 저는 세계 대부분의 소프트웨어는 대서양의 한쪽에서 쓰여졌다는 사실에 대하여라는 반박 논문을 썼습니다. 저도 수학 학위가 있었기 때문에 컴퓨터가 새로운 종류의 수학을 형성한다는 내용이었습니다. 컴퓨터는 고전적인 수학에 잘 들어맞지 않습니다. 그것을 고전 수학에 억지로 맞추려는 사람들은 스스로 깨닫지 못할 수도 있지만 무의미한 행위에 빠져 있는 것입니다. 컴퓨터는 일종의 실용적인 수학이었습니다. 그것은 고전 수학이 꿈꾸었던 것보다 훨씬 더 큰 규모로 일관된 구조를 만드는 것과, 모든 경우를 다루었다는 확신을 주어야 하는 고전 수학의 동일한 문제를 해결하는 것 사이의 균형이었습니다. 오일러라는 수학자가 있었는데, 그가 사실일 것이라 추측한 내용들은 20권의 방대한 책으로 구성되어 있고 대부분 사실이었습니다. 하지만 그의 증명은 거의 다 틀렸습니다. 지난 세기와 이번 세기의 많은 수학 박사들은 오일러의 책에서 잘못된 증명을 찾아내고 그의 통찰력이 옳았을 것이라 추측하며 훨씬 더 설득력 있는 증명을 찾아내는 과정에서 탄생했습니다. 수학에서도 디버깅이 일어나는 것입니다. 객체 지향 작업이나 모든 종류의 프로그래밍 작업에서 가장 중요한 것은 아름다움과 실용성 사이의 정교한 조화가 있어야 한다는 것입니다. 둘 중 어느 하나도 희생할 이유가 없습니다.

  그러나 둘 중 하나를 기꺼이 희생하려는 사람들은 컴퓨팅이 진정 무엇인지 이해하지 못한다고 생각합니다. 그것은 마치 그림에 대한 아주 멋진 아이디어가 있지만 물감 없이 붓만 사용해서 아이디어를 표현하겠다고 말하는 것과 같습니다. 20세기 예술가들에게 그런 말을 하지 마세요. 그들이 당신의 그런 모습을 비디오로 찍어 박물관에 전시할지도 모릅니다. 저는 항상 무엇을 이야기할지 정하는 것에 어려움을 겪습니다. 기술자들은 항상 너무 많은 것을 알고 있는 것 같기 때문입니다. 세상 밖에서 객체 지향이라는 이름으로 실제로 행해지는 것을 다시 살펴보는 것은 흥미롭습니다. 저는 수년 동안 대학에 있는 사람들을 포함한 여러 사람들로부터 객체 지향 언어로 쓰여졌다는 아주 이상한 형태의 코드를 보아왔습니다. 객체 지향이라는 용어는 제가 만들었는데, 저는 C++를 염두에 두고 만든 것이 절대 아니라고 말씀드릴 수 있습니다. 저는 스몰토크에 대해서도 이와 동일한 감정을 많이 가지고 있습니다. 스몰토크 언어나 문법, 혹은 축적된 슈퍼클래스 라이브러리가 마치 올림포스의 신들이 내려준 것처럼 여겨지지만 사실 우리가 정말 주의를 기울여야 할 중요한 것은 그것들과 거의 관련이 없습니다.

  그래서 저는 60년대에 객체 지향에 대해 생각하기 시작했을 때의 제 개인적인 반응에 대해 조금 더 이야기하고 싶습니다. 역사적인 이야기가 아니라 이러한 반응과 통찰력이 오늘날에도 여전히 유효한지 생각해 보기 위해서입니다. 슬라이드가 잘 안 넘어가네요. 다음 빈 슬라이드로 넘어가 주세요. 60년대에는 모든 것이 아주 기계적이었습니다. 물론 컴퓨터가 이 방만큼 컸기 때문에 단순한 기계 메커니즘이라는 느낌이 강했습니다. 이반 서덜랜드가 스케치패드를 개발한 컴퓨터는 이 방만한 크기였고 지붕을 따로 가져야 할 만큼 큰 미국 내 마지막 컴퓨터 중 하나였습니다. 컴퓨터 자체가 하나의 건물이었습니다.

  그러나 프로그램들은 아주 작았고 수학적인 선행 개념들과 공통점이 많았습니다. 논리에 기초한 수학의 의미론을 생각하는 한 가지 방법은 맞물려 돌아가는 톱니바퀴와 같습니다. 모든 것이 서로 맞아야 하고 모든 것이 끝에서 호환될 때 당신이 원하는 최종적인 축의 회전을 얻게 됩니다. 현실 세계의 비유를 들어보겠습니다. 슬라이드를 두 장 뒤로 돌려주세요. 60년대의 프로그램들에 대한 비유로 개집을 들 수 있습니다. 무작위로 판자를 가져다가 못과 망치로 두드려 박으면 서 있을 수 있는 구조물이 만들어집니다. 못을 박는 방법만 알면 다른 것은 몰라도 됩니다. 누군가 이 개집을 보고 이것을 백 배로 키우면 대성당을 만들 수 있겠다고 말할 수 있습니다. 1미터 정도 높이의 개집을 키워 30층 높이의 건물을 만들면 정말 인상적일 것이고 많은 사람을 수용할 수 있을 것입니다.

  그래서 목수들은 이 구조물을 백 배로 부풀리는 작업에 착수할 것입니다. 엔지니어와 과학자인 우리는 어떤 것을 백 배로 키우면 질량은 백만 배로 늘어나지만 주로 단면적에 기인하는 강도는 만 배밖에 늘어나지 않는다는 것을 알고 있습니다. 어떤 것을 백 배로 부풀리면 그것을 지탱하는 능력은 백 배 정도 약해집니다. 이 개집을 키우면 어떻게 될까요? 그냥 돌무더기로 무너져 내릴 것입니다. 이런 일이 발생했을 때 두 가지 선택을 할 수 있습니다. 가장 대중적인 선택은 애초에 우리가 하려던 것이 이거였다고 말하는 것입니다. 그 위에 쓰레기를 더 얹고 석회암으로 덧발라서 고딕 성당이 아니라 피라미드를 지으려 했다고 우기는 것이죠. 저는 이것이 오늘날 현대 운영 체제 구조의 상당 부분을 설명한다고 생각합니다. 아니면 복잡한 구조에 관심이 있는 사람들이 오래전에 시도했던 것처럼 새로운 개념을 생각해 낼 수도 있습니다.

  그래서 그들은 이것을 아키텍처라고 불렀습니다. 말 그대로 성공적인 아치들을 설계하고 짓는 일입니다. 단순한 재료들 사이의 명백하지 않은 비선형적인 상호작용이 명백하지 않은 시너지를 내고 재료의 가치를 엄청나게 곱해줍니다. 거대한 물리적 구조물인 샤르트르 대성당에 들어간 재료의 양이 파르테논 신전에 들어간 재료의 양보다 적다는 사실을 말해주면 사람들은 아주 놀랍니다. 그 이유는 대성당이 거의 모두 공기와 유리로 이루어져 있기 때문입니다. 모든 것이 아름다운 구조 속에서 교묘하게 조직되어 부분의 합보다 전체가 훨씬 더 높은 무결성을 가지게 됩니다. 객체 지향의 메시지 중 일부는 복잡성이 점점 더 중요해질수록 아키텍처가 항상 재료를 지배한다는 것이었습니다. 객체 지향에 관한 슬픈 사실은 사람들이 그 아름다움 때문에 아키텍처에 관심을 갖지 않았다는 것입니다. 인터넷이 모두에게 그것을 강요하고 있는 지금에서야 그들은 아키텍처에 관심을 갖기 시작했습니다. 꽤나 안타까운 일입니다.

  그래서 저는 아서 케슬러의 창조의 행위라는 훌륭한 책에서 가져온 은유를 사용할 것입니다. 소설가였다가 말년에 인지 과학자가 된 케슬러는 배움이 무엇인지에 대한 훌륭한 책을 썼습니다. 그는 배움이란 전에 없던 것이 우리 안에 생겨나는 것이기 때문에 그 자체가 창조적인 행위라고 깨달았습니다. 그는 평면 위를 기어 다니는 개미로 생각을 비유했습니다. 이 경우에는 분홍색 평면입니다. 분홍색 평면 위에서 할 수 있는 일은 많습니다. 목표를 가질 수도 있고 방향을 정할 수도 있고 앞으로 나아갈 수도 있지만 기본적으로 항상 분홍색 맥락 안에 머무르게 됩니다. 고정된 맥락 안에서의 발전은 거의 항상 최적화의 한 형태입니다. 만약 당신이 실제로 새로운 것을 생각해 냈다면 그것은 분홍색 평면의 규칙이나 맥락의 일부가 아니었을 것입니다.

  그래서 창조적인 행위란 일반적으로 자신이 속한 동일한 맥락에 머무르지 않는 것을 의미합니다. 그는 부모님과 학교에서 수년 동안 주의 깊게 가르침을 받았음에도 불구하고 가끔씩 파란색 아이디어를 떠올리게 된다고 말합니다. 샤워를 할 때나 조깅을 할 때, 혹은 무방비 상태로 쉬고 있을 때, 갑자기 당신이 궁금해하고 생각하던 것이 마치 다른 것인 양 완전히 다른 시각으로 다가올 때가 있습니다. 케슬러는 이에 대한 감정적 반응이 기본적으로 세 가지 형태로 나타난다고 말했습니다. 농담을 할 때는 하하, 과학을 할 때는 아하, 예술을 할 때는 아라는 감탄사로 나옵니다. 각각의 경우에 아주 비슷한 일이 일어나기 때문입니다. 농담은 당신을 예측 가능한 길로 이끌다가 갑자기 그것이 전혀 다른 것에 관한 것임을 드러내며 공격적인 웃음을 폭발시킵니다. 과학도 이와 비슷한 느낌을 가지고 있어서 눈앞에 있었던 사실을 과학에서 발견했을 때 그것이 일종의 농담처럼 느껴져 웃기 시작할 때가 많습니다. 위대한 예술은 우리가 어떤 맥락에 있다고 생각하든 간에 다른 맥락이 존재한다는 것을 일깨워주기 위해 존재합니다. 예술은 항상 우리를 현재의 맥락에서 끌어내어 다른 맥락을 인식하게 해줍니다.

  그러나 파란색 생각을 하려면 파란색 무언가가 있어야 한다고 그는 지적했습니다. 이것은 하나의 분야에 과도하게 전문화된 사람들에게서 종종 간과되는 부분입니다. 전문화한다는 것은 기본적으로 최적화만 할 수 있는 정신 상태에 자신을 밀어넣는 것입니다. 다른 맥락을 시작하려면 여러 가지 다양한 것들을 배워야 합니다. 수년 동안 제 머리를 때렸던 몇 가지 큰 깨달음을 빠르게 말씀드리겠습니다. 이것은 우리가 데이터 추상화라고 부르는 것의 가장 오래된 형태로 알려져 있기 때문에 흥미로우실 겁니다. 1961년 이전으로 거슬러 올라갑니다. 저는 1961년에 공군에 있었고 그때 이것을 보았습니다. 당시에는 제대로 된 운영 체제가 없었고 공군 훈련 사령부는 다양한 종류의 기록이 담긴 테이프를 공군 기지 간에 보내야 했습니다. 예전에는 카드 이미지였던 것들이 테이프가 도입되면서 점점 더 복잡한 형식으로 바뀌었는데, 어떻게 이 모든 것을 처리할 수 있을지가 문제였습니다.

  그래서 장교들은 당시 프로그래밍을 하지 않았기 때문에 거의 확실하게 한 사병이 다음과 같은 아이디어를 생각해 냈습니다. 이 사병은 이 테이프의 세 번째 레코드 부분에 특정 유형의 모든 레코드를 배치하고, 중간인 두 번째 부분에는 세 번째 부분의 형식들을 어떻게 다루는지 아는 모든 프로시저를 넣자고 제안했습니다. 그리고 첫 번째 부분에는 그 프로시저들을 가리키는 포인터를 넣자고 했습니다. 처음 10개 정도의 포인터는 읽기, 쓰기, 필드, 인쇄와 같이 표준화된 어휘로 만들고, 나중에 고유한 포인터들을 추가할 수 있게 했습니다. 1961년 당시 테이프를 읽기 위해 해야 할 일은 이 거대한 레코드의 앞부분을 코어 스토리지로 읽어 들이고 포인터를 통해 프로시저로 직접 점프하는 것뿐이었습니다. 프로시저들은 이미 거기에 있었습니다.

  그러나 이것을 인터넷의 HTML과 비교해 보시길 바랍니다. 인터넷의 HTML은 브라우저가 자신의 형식을 이해해야 한다는 것을 전제로 하기 때문에 암흑기로 되돌아간 것과 같습니다. 이것은 MS DOS 이후 최악의 아이디어 중 하나일 것입니다. 정말 유감스러운 일입니다. 아마도 물리학자들이 컴퓨터를 가지고 놀기로 결정했을 때 벌어진 일일지도 모르겠습니다. 지금 인터넷에서 무슨 일이 일어나고 있는지 볼 수 있습니다. 현재 인터넷에서는 브라우저 전쟁이라는 두 개의 완전히 무의미한 전쟁이 벌어지고 있습니다. 이것은 복잡한 시스템을 구축하는 방법을 이해하지 못했다는 것을 증명하거나, 단순히 영토를 확장하려는 더 조잡한 시도에 불과합니다. 마이크로소프트는 후자에 속한다고 의심됩니다. 1961년에 공군 하사가 알고 있던 방법을 따른다면 브라우저는 필요 없습니다. 그냥 읽어 들이면 됩니다. 데이터는 자신에게 필요한 모든 것들과 함께 이동해야 하며, X 윈도우 같은 것 이상으로 복잡한 것이 필요하지 않습니다.

  그래서 기본적으로 거기에 있는 모든 지식을 분산시킬 수 있어야 합니다. 실제로 사람들이 점점 더 복잡하고 다루기 힘든 HTML 형식들을 발견함에 따라 인터넷은 그 방향으로 움직이기 시작하고 있습니다. 이것은 매 세대마다 반복되는 실수 중 하나이며 결코 올바른 방법이 아닙니다. 이 방식은 공군에 고급 언어가 도입되기 전에 이루어진 훌륭한 아이디어였고, 코볼이 표준화되면서 공군에서 밀려났습니다. 이반 서덜랜드의 스케치패드는 종종 그것이 어떤 것인지 보여주는 영화로 소개되었지만 오늘은 상영하지 않겠습니다. 그것은 수행할 수 있는 능력의 개념에서 거의 충격적일 정도로 엄청나게 정교했으며 객체 지향 시스템과 매우 흡사했습니다. 클래스와 서브클래스에 대한 실제 개념을 가지고 있었고 공군 훈련 사령부 버전보다 훨씬 더 강력한 다형성 개념도 포함하고 있었습니다.

  그러나 제가 이 아이디어를 세 번인가 네 번 정도 본 후에야 시뮬라를 이해하게 되었습니다. 우리는 시뮬라가 알골인 줄 알았고, 그 테이프 더미는 케이스 웨스턴 리저브 대학교와 노르웨이의 시뮬라 발명가인 니가드와 달에 의해 조작된 첫 번째 시뮬라라는 사실이 밝혀졌습니다. 그것은 1966년에 이해할 수 없는 문서와 함께 배포되었습니다. 훌륭하지만 낯선 아이디어를 네 번이나 각기 다른 형태로 접하게 되면 마침내 강한 인상을 남기게 되는 것 같습니다. 새로운 것에 직면했을 때 여러분에게는 두 가지 선택권이 있습니다. 이 기술적인 진보를 받아들여 현재 하고 있는 일을 더 나은 방식으로 처리하기 위해 계속 사용할 수도 있습니다. 그것은 분홍색 평면에 머무르는 것입니다.

  그러나 이것은 더 나은 옛날 것이 아니라 거의 새로운 것이고, 이 새로운 것이 도대체 무엇이 되려 하는지 궁금해할 수도 있습니다. 만약 그렇게 한다면 그다지 최적화할 수 없는 무언가를 단순히 최적화하는 것을 넘어서 엄청난 이점을 얻을 가능성이 있습니다. 시뮬라는 데이터 구조와 프로시저의 세계에서 나왔고, 그런 관점에서 본다면 기존의 특성을 많이 가지고 있었습니다. 하지만 컴퓨팅 상태와 프로시저의 관계를 맺어주는 방식은 매우 유용했으며 알골 60의 자기 변수라고 부르는 것보다 훨씬 낫고 일반적이었습니다. 새로운 것이라면 도대체 어떤 종류의 새로운 것인지에 대한 다른 질문이 생깁니다. 제 학부 전공 중 하나는 분자 생물학이었고, 오늘날 형태 발생학이라고 부르는 배아학과 세포 생리학 모두에 특별한 관심을 가지고 있었습니다. 왓슨의 유전자의 분자 생물학이라는 책이 1965년에 막 출간되었습니다. 아주 훌륭한 책이며 여전히 출판되고 있습니다.

  그러나 수많은 개정판을 거치면서 오늘날의 책과 1965년의 책 사이에 공통된 단어는 관사 정도일 것입니다. 유전자라는 단어는 여전히 남아있겠지만 지금은 완전히 다른 의미를 갖습니다. 이 책에서 왓슨이 했던 일 중 하나는 살아있는 전체 생명체에 대한 최초의 분석을 시도한 것이었고 그것이 대장균이었습니다. 그 안을 들여다보면 복잡성에 압도됩니다. 팝콘 같은 것들은 약 5천 개의 원자로 이루어진 단백질 분자입니다. 물과 칼슘, 칼륨 이온 같은 작은 분자들을 제거하면 전체 질량의 약 70퍼센트를 차지합니다. 나머지 30퍼센트는 형태적으로 상호 작용하는 약 1억 2천만 개의 구성 요소를 가지고 있습니다. 이 각각의 구성 요소는 상당한 양의 정보를 전달합니다.

  그래서 이를 생각하는 간단한 방법은 패턴 매처가 있고 패턴이 성공적으로 일치하면 어떤 일들이 일어나는 시스템과 비슷하게 작동한다는 것입니다. 거기에 관여하는 상태는 약 100기가바이트이고, 오늘날 데스크탑 100대 정도에 불과하지만 계산량으로 보면 여전히 꽤 인상적입니다. 이 구조에서 가장 흥미로운 점은 병렬로 처리된다는 점을 고려할 때 계산 속도가 오늘날의 컴퓨터와 심각하게 경쟁할 만하다는 것입니다. 예를 들어 팝콘 크기의 입자 중 하나가 자기 길이만큼 이동하는 데 단 2나노초밖에 걸리지 않습니다. 원자를 테니스공 크기라고 시각화하면 단백질 분자 하나는 폭스바겐 자동차 크기 정도이고 그것이 2나노초 만에 자기 길이만큼 움직이는 것입니다. 그것은 우리 규모로는 약 2.4미터입니다. 이것은 빛의 속도의 4배에 해당합니다.

  그래서 화학이 어떻게 작동하는지 궁금하셨다면 바로 이것이 이유입니다. 생명체 내부의 열적 동요는 너무나도 격렬해서 컴퓨터의 도움을 받아도 상상조차 할 수 없을 정도입니다. 무언가를 죽이기 전까지는 그 안에서 아무것도 볼 수 없습니다. 완벽하게 활동이 흐릿한 상태로 존재하기 때문입니다. 좋은 조건에서는 대장균 하나가 완전히 스스로를 복제하는 데 15분에서 18분밖에 걸리지 않습니다. 박테리아에 대해서는 오늘날 훨씬 더 많은 것들이 알려져 있습니다. 우리 몸의 세포 크기는 박테리아의 약 1500배이고, 1억 2천만 개가 아닌 약 600억 개의 구성 요소를 가지고 있습니다. 우리 몸에는 10조에서 13조 개 어쩌면 그 이상의 세포들이 있습니다. 그럼에도 불구하고 9개월의 임신 기간 동안 세포 분열은 50번밖에 일어나지 않습니다. 아기를 만드는 데 50번의 세포 분열이면 충분합니다.

  그러나 실제로 곱해보면 40번 정도만 필요하다는 것을 깨닫게 됩니다. 여분의 세포 분열은 배아 발달 과정에서 유기체 전체에 적합하지 않은 많은 세포들이 죽기 때문에 존재합니다. 과도하게 증식시키고 테스트하고 다듬는 과정을 통해 이루어집니다. 그리고 이 각각의 구조들은 엄청난 생물량 속에 묻혀 있습니다. 생물학이라는 파란색 맥락을 가진 사람에게 컴퓨터와 같은 것은 결코 특별히 복잡하거나 크거나 빠르거나 작거나 멍청하게 여겨질 수 없습니다. 나폴레옹이 사용했던 것처럼 프랑스 전역을 가로지르는 기계식 신호기와 같은 기술 형태를 사용하고 있기 때문입니다.

  그래서 여기서 관점의 전환은 기계적인 것에서 출발합니다. 개집은 100배로 확장하기 어렵고 시계도 100배로 확장하기 어렵습니다. 반면에 세포는 100배뿐만 아니라 1조 배로도 확장됩니다. 어떻게 그들이 그렇게 하는지, 그리고 복잡한 시스템을 구축하기 위해 이 아이디어를 어떻게 적응시킬 수 있는지가 질문입니다. 이것은 아주 간단한 문제인데, C++는 여전히 이것을 이해하지 못하고 있습니다. 아무리 간단하고 강력한 아이디어라도 수많은 사람들이 오해하게 만들 수 있습니다. 이런 객체의 내부가 전체의 계산에 영향을 미치는 요소가 되도록 절대 허용해서는 안 됩니다. 이것은 이야기의 일부일 뿐입니다. 세포막은 무언가를 안에 유지하는 것만큼이나 대부분의 것을 밖으로 차단하기 위해 존재합니다. 객체에 대한 우리의 많은 혼란은 서양 문화에서 아주 명확한 명사와 동사를 가진 언어를 사용한다는 사실에서 비롯됩니다.

  그래서 우리가 프로세스를 나타내는 단어들은 형편없고 객체를 생각하는 것이 훨씬 더 쉽습니다. 저는 객체 지향이라는 용어를 만든 것에 대해 지난 20년 동안 깊이 사과해 왔습니다. 그 용어가 잘못 적용되기 시작하자마자 훨씬 더 프로세스 지향적인 용어를 사용했어야 했다고 깨달았습니다. 일본어에는 서양에서 객체라고 부르는 것들 사이의 공간, 즉 우리가 사물의 지금 이 순간에 집중하느라 보지 못하는 중간의 물질을 뜻하는 마라는 흥미로운 단어가 있습니다. 일본어는 사물들이 어떻게 관련되는지를 바라보는 프로세스 지향적인 방식을 가지고 있습니다. 중요한 것을 표현하는 데 필요한 단어의 크기를 보면 항상 알 수 있습니다. 마는 아주 짧지만 우리는 일본인들이 말하는 것을 근사하게 표현하기 위해 중간에 있는 혹은 그보다 더 긴 단어를 사용해야 합니다.

  그러나 외부와 내부 사이에 인터페이스가 존재하도록 캡슐화하고 나면 객체가 무엇이든 할 수 있게 만들 수 있다는 깨달음은 특정 개인의 공으로 돌릴 수 없습니다. 그것은 스케치패드, 공군 훈련 사령부 파일 시스템, 시뮬라의 씨앗에 이미 존재했기 때문입니다. 그 이유는 단순합니다. 캡슐화한 것은 바로 하나의 컴퓨터이기 때문입니다. 당신은 설계 공간을 분할함으로써 당신이 작업하고 있는 강력한 도구를 잃지 않는 컴퓨터 과학에서 아주 강력한 일을 해낸 것입니다. 데이터와 프로시저 중심 언어의 버그가 바로 이것입니다. C++나 자바 같은 언어의 가장 치명적인 점은 프로그래머를 돕는다고 생각하면서 최대한 예전 방식처럼 보이게 하지만, 사실은 프로그래머가 이 새로운 은유의 진정 강력한 점을 이해하기 어렵게 만들어서 그들에게 끔찍한 해를 끼친다는 것입니다.

  그래서 시분할 시스템을 만들던 사람들은 이 점을 이미 파악하고 있었습니다. 1965년 버틀러 램슨의 논문은 시분할 시스템에서 사용자에게 제공하고 싶은 것이 지금의 가상 머신이라고 불리는 것이라는 내용이었습니다. 그것은 자바 가상 머신과는 다르며, 물리적 컴퓨터와 가장 유사한 형태를 모든 사람에게 개별적으로 제공하는 것입니다. 유닉스는 그런 감각을 가지고 있었습니다. 그 시스템의 가장 큰 문제점은 프로세스를 유지하는 데에만 약 2천 바이트의 오버헤드가 발생했다는 것입니다. 유닉스에서 단순히 3이라는 숫자를 프로세스로 만드는 것은 아주 어려웠습니다. 3비트에서 수천 바이트로 늘어나기 때문에 스케일링에 문제가 생깁니다. 향후 25년 동안 생물학적 은유가 이길 것이라고 결정하고, 우리가 실제로 필요로 하는 모든 규모에서 실용적이 되도록 충분히 헌신해야 합니다. 생물학은 할 수 없지만 우리는 할 수 있는 한 가지 속임수가 있습니다. 세포에서 DNA를 꺼내는 것입니다.

  그래서 우리는 낭포성 섬유증과 같은 시스템 질환을 훨씬 더 쉽게 치료할 수 있습니다. 오늘날 일부 사람들의 낭포성 섬유증은 변형된 감기 바이러스를 감염시켜 폐에 감염을 일으키는 방식으로 치료됩니다. 결함이 있는 낭포성 섬유증 유전자는 감기 바이러스에 들어있고, 이 감기 바이러스는 폐렴처럼 폐를 파괴할 만큼 강하지 않지만 폐의 모든 세포에 그 유전자의 복사본을 삽입할 만큼은 강합니다. 그것이 바로 효과를 발휘합니다. 일단 시작된 유기체의 DNA를 재프로그래밍하는 것은 아주 복잡한 방법입니다. 객체 지향을 인터넷에 도입하려는 사람들을 보면서 아직 이 사실을 깨달은 사람을 보지 못했다는 것이 놀랍습니다. 적어도 모든 객체는 URL을 가져야 하고 인터넷의 모든 객체는 IP를 가져야 합니다. 그것들은 물리적 하드웨어를 비트에 맞춰 추상화한 것을 훨씬 더 잘 나타냅니다. 이것은 객체가 기본적으로 서버와 같으며 다형성이라는 개념이 이런 서버들의 클래스에 대해 생각하는 방법이라는 초기 통찰입니다.

  그러나 우리는 이제 이 시스템을 구축해야 하고 곧 그것을 성장시켜야 한다는 사실을 아직 크게 직면하지 못했습니다. 아기를 15센티미터 성장시키는 것은 매우 쉽습니다. 그들은 평생 동안 10번 정도 그렇게 성장하며 유지보수를 위해 아이를 분해할 필요가 없습니다. 하지만 747 비행기를 키우려고 한다면 믿을 수 없는 문제에 직면하게 됩니다. 고치거나 바꾸거나 100년 동안 살게 놔두는 것이 아니라 단지 인공물을 처음 만드는 것만이 유일한 목적이었던 단순하고 기계적인 세계에 있기 때문입니다. 언어 외부에서 개발을 강요하는 언어를 여전히 사용하는 사람이 얼마나 됩니까? 자바처럼 빠르더라도 컴파일하고 다시 로드하고 실행해야 하는 시스템을 여전히 사용하는 사람들은 손을 들어보세요. 복잡한 시스템을 구축하는 데 있어 기존에 존재하는 것들과의 상호 운용성 가능성을 이해하려는 상황에서 그것은 막다른 길일 수밖에 없습니다.

  그래서 저는 약 30년 전 아파넷의 설계 원칙을 공식화하기 위해 시스템 설계 회의에 참석했던 30명의 대학원생 중 한 명이었습니다. 아파넷은 인터넷이 되었고 1969년경부터 실행되기 시작한 이래로 약 1억 배 이상 성장했습니다. 이것은 8자리의 엄청난 증가입니다. 그리고 최근에 래리 로버츠와 이야기를 나눴는데, 오늘날 인터넷에는 원래의 아파넷에 있었던 물리적 원자가 단 하나도 남아있지 않고 원래의 아파넷에 있었던 코드 한 줄도 남아있지 않습니다. 물론 아파넷에 IBM 메인프레임이 있었다면 사실이 아니었을 겁니다. 이 시스템은 1억 배 성장했고 모든 원자와 비트를 변경했지만 한 번도 멈출 필요가 없었습니다. 그것이 바로 우리가 더 작다고 생각하는 것들에 완벽하게 적용해야 할 은유입니다. 프로그래밍을 작게 생각할 때 여러분의 프로그램이 그렇게 커지고, 고딕 대성당이 아니라 피라미드가 되는 이유입니다. 다음 슬라이드로 넘겨주세요.

  그래서 60년대의 시뮬라와 더불어 가장 훌륭한 단일 언어이자 그만큼 심오한 통찰을 가진 또 다른 중요한 언어는 리스프입니다. 1962년에 출판된 책의 13페이지를 보면 리스프의 자기 반영 모델이 자신으로 쓰여진 반 페이지 분량의 코드가 있습니다. 리스프 의미론의 중요한 세부 사항과 리스프 인터프리터를 만드는 지침이 그 반 페이지 안에 다 들어있습니다. 자바에서 일어나고 있는 일 중 가장 슬픈 것이 바로 이 메타 반사적 측면이 없다는 것입니다. 자바가 처음 등장했을 때 저는 우리가 제록스 파크에서 했던 것처럼 멀티 플랫폼이 되는 바이트 코드 접근 방식을 대중화시킨다고 생각했습니다. 그것은 새로운 아이디어가 아니라 60년대로 거슬러 올라가는 아이디어입니다. 자바를 보면서 도대체 어떻게 메타 시스템 없이, 실행 중에 새로운 것을 로드하는 기능조차 없이 모든 변화와 수정, 적응, 상호 운용성 요구 사항을 견뎌낼 수 있을지 의아했습니다.

  그러나 사람들이 이것을 어떤 큰 희망으로 채택했다는 사실은 제가 MS DOS 이후로 개인적으로 가장 고통스럽게 느끼는 점입니다. 그것은 사람들이 더 큰 그림이 무엇인지 이해하지 못했다는 실패를 나타냅니다. 메타 프로그래밍의 개념을 보는 다양한 관점이 있습니다. 특정 구현은 실용적인 선택을 내리는 것이며 이러한 선택들은 모든 경우를 포괄할 수 없을 가능성이 높습니다. 그래서 우리는 지저분한 것들을 숨기고 동일한 개념을 다루는 여러 가지 방법을 가져야 합니다. 언어 자체가 자신의 구조를 더 많이 볼 수 있을수록 단일 구현의 폭정으로부터 더 자유로워질 수 있습니다. 이것은 매우 적은 사람들만이 실용적인 형태로 고민하고 있는 가장 중요한 문제 중 하나입니다. 이 메타 기술이 아무도 무시할 수 없을 만큼 중요해지는 이유 중 하나는 앞으로 5년, 10년 뒤에 인터넷에서 실제로 어떻게 상호 운용할 것인가 하는 문제 때문입니다.

  그래서 저는 마이크로소프트가 인터넷을 장악할 수 없을 것이라 생각합니다. 인터넷은 너무나 방대하고 아이디어를 제공하는 사람들이 너무 많습니다. IBM이나 마이크로소프트 방식의 해결책은 요구되지도 않고 가능하지도 않다는 것을 깨달을 만큼 사람들은 충분히 정교해질 것입니다. 수십 개의 서로 다른 객체 시스템들이 나타날 것이고 이미 나타나고 있습니다. 의미론은 매우 비슷하지만 실용적인 세부 사항은 아주 다를 것입니다. URL이 무엇인지, HTTP 메시지가 무엇인지, 객체와 객체 지향 포인터가 무엇인지 생각해 본다면, 모든 객체 지향 언어가 그것이 어디서 만들어졌든 관계없이 세계의 어떤 객체에 대한 자신의 로컬 포인터를 내면화할 수 있다는 것이 명백해질 것입니다. 내부를 볼 수 없다는 것이 핵심입니다. 이런 태도를 취함으로써 의미론적 상호 운용성이 즉시 가능해집니다.

  그래서 이것은 모든 것을 바꿀 것이며 자바 빈즈나 코바 같은 것들은 충분하지 않을 것입니다. 어느 시점에서는 객체들이 스스로 무엇을 할 수 있다고 생각하는지 실제로 발견하기 시작해야 하기 때문입니다. 이것은 프로그래밍 언어가 아니라 프로토타이핑 언어에 가까운 범용 인터페이스 언어로 이어질 것입니다. 객체들이 자신이 할 수 있는 일에 대한 깊은 정보를 교환하고 다른 객체들과 안전하게 실험하여 다양한 메시지에 어떻게 반응하는지 볼 수 있게 해줍니다. 이것이 향후 10년 내에 자동화해야 할 중요한 사안이 될 것입니다. 이 훌륭한 책을 읽은 분이 얼마나 되나요? 그들이 이 책을 썼을 때 저는 그들에게 전화해서 10년 동안 쓰여진 최고의 책이지만 왜 리스프 중심적이고 폐쇄적인 방식으로 썼느냐고 물었습니다. 리스프 문화를 모르면 읽기 아주 어려운 책이지만 지난 몇 년 동안 나온 어떤 책보다 객체 지향에 대한 가장 실용적이고 심오한 통찰력을 담고 있습니다.

  그래서 이 책을 강력히 추천합니다. 대중적인 객체 지향 커뮤니티가 이해할 수 있도록 이 책을 다시 쓰는 분이 있다면 누구에게라도 제가 다음 풍선 여행의 기회를 드리겠습니다. 인류를 위한 위대한 봉사가 될 것입니다. 70년대부터 전 세계 대부분에서 일어난 일은 추상 데이터 타입이었습니다. 프로그래밍에 대한 할당 중심의 사고 방식에 머무르는 것입니다. 제가 이 슬라이드를 만들었을 때 C++는 지평선 위의 작은 점에 불과했고 아무도 진지하게 받아들이지 않는 농담 같은 것이었습니다. 다음 슬라이드로 넘겨주세요. 제가 가장 좋아하는 C++ 이야기가 있습니다. 애플에는 정말 우연하게도 핑크라고 불리는 대단한 운영 체제가 있었습니다. 개발 중인 이 새로운 운영 체제에는 두 가지 흥미로운 특징이 있었습니다. 하나는 항상 2년 안에 완성될 것이라는 점이었고, 다른 하나는 효율성을 위해 C++로 개발된다는 것이었습니다.

  그러나 수년에 걸쳐 정말 훌륭한 운영 체제 설계자들을 알고 지냈지만, 핑크 팀보다 10배 높은 지능을 가진 사람들이 만들었어도 2년 안에 제대로 된 운영 체제를 완성한 경우는 본 적이 없습니다. 스몰토크는 너무 느리니까 쓰지 말자고 했지만 절대 작동하지 않는 운영 체제에 10년을 낭비하는 것보다 더 비효율적인 것은 없습니다. 사실 가장 최악인 것은 작동하는 것처럼 보이는 운영 체제입니다. 물을 발견한 것이 누구인지는 모르겠지만 물고기는 아니었다는 맥루한의 명언을 인용해 봅시다. 그는 우리를 물고기라고 불렀고 물은 우리의 믿음 체계이자 맥락을 의미했습니다. 우리 분야에서 겪는 특정한 어려움과 인류 일반의 어려움 모두를 야기하는 단 하나의 원인을 꼽으라면, 그것은 단일한 관점을 취하고 그것을 종교처럼 맹신하는 것입니다. 스몰토크에도 이런 일이 일어났습니다.

  그래서 19세기 독일 철학자 쇼펜하우어의 멋진 인용구를 소개합니다. 모든 아이디어는 세 가지 단계를 거친다. 첫째, 미치광이의 짓이라고 비난받는다. 둘째, 내내 완전히 뻔한 것이었다고 여겨진다. 마지막 단계는 처음에 비난했던 사람들이 자신들이 그것을 발명했다고 주장하는 때이다. 그때가 바로 종교적인 단계에 접어드는 시점입니다. 제록스 파크에서 나온 스몰토크에 일어난 일 중 저에게 가장 고통스러웠던 것은 많은 측면과 목적에서 스몰토크의 변화가 멈췄다는 것입니다. 제록스 파크에서는 약 10년의 기간 동안 완전히 다른 네 가지 주요 버전의 언어가 있었고 수십 개의 중요한 릴리스가 있었습니다. 우리가 스몰토크에 대해 가장 좋아했던 것은 그것이 무엇을 할 수 있느냐가 아니라 시스템 구축 방법에 대해 우리가 가진 다음 아이디어 세트를 부트스트랩하는 데 얼마나 훌륭한 도구였느냐 하는 점입니다. 스몰토크가 상업화되면서 그 과정은 사실상 멈췄습니다.

  그러나 스몰토크 인터프리터를 만들고 스스로 이 과정을 시작하기 위한 실제 코드가 담긴 유명한 블루북이 있었음에도 불구하고 이 이점을 활용한 대학이나 상업 기관은 거의 없었습니다. 오늘 여러분과 소통하고 싶은 가장 깊은 내용은 우리가 아직 시스템을 설계하는 방법을 모른다는 사실입니다. 그러니 제발 우리가 모르는 것을 종교로 만들지 맙시다. 우리가 해야 할 일은 끊임없이 생각하고 무엇이 중요한지 숙고하는 것입니다. 우리는 시스템이 다음 수준의 추상화에 도달하도록 허용해야 합니다. 스몰토크에 대해 제가 개인적으로 유일하게 자랑스러워하는 점은 세상에 나오기 전까지 이전 버전의 자신을 제거하는 데 너무나도 훌륭했다는 것입니다. 16년 동안 프로그래밍 언어 작업을 하지 않다가 몇 년 전에 스퀵이라는 프로젝트를 시작한 이유 중 하나도 세상에 스몰토크보다 훨씬 나은 것을 위한 부트스트랩 메커니즘을 제공하려는 시도였습니다.

  그래서 스퀵을 다룰 때는 제발 다음 버전의 자신을 얻기 위한 자체 메커니즘을 사용하여 이 언어를 어떻게 구식으로 만들 수 있을지 그 관점에서 생각해 보시기 바랍니다. 파란색 생각들을 찾아보세요. 이 강연을 어떻게 마무리할까 고민하다가 제가 좋아하는 파이프 오르가니스트인 E. 파워 빅스와 관련된 이야기가 떠올랐습니다. 그는 17세기와 18세기 방식의 연주로 파이프 오르간에 대한 관심을 부활시켰고 우리 모두에게 엄청난 영향을 미쳤습니다. 제 친한 친구가 40년대와 50년대에 수년 동안 그의 조수였습니다. 그는 지금 80대인데 저녁을 먹을 때면 우리는 항상 그에게 빅스의 이야기를 해달라고 조릅니다. 빅스가 방송을 위해 사용했던 오르간은 하버드의 부시 라이징어 박물관에 있는, 이도 저도 아닌 작고 보잘것없는 오르간이었습니다.

  그러나 그 오르간으로 모든 종류의 음악이 연주되었습니다. 어느 날 이 조수가 빅스를 대신해 연주해야 했고 어떤 곡을 연주할지 물었습니다. 빅스는 세자르 프랑크의 웅장한 곡을 프로그램해 두었다고 말했습니다. 그 곡은 역대 가장 크고 가장 시끄러운 오르간과 가장 큰 대성당을 위해 만들어진 19세기 교향곡 형식의 작품이었습니다. 조수는 어떻게 이 작고 보잘것없는 오르간으로 그 곡을 연주할 수 있냐고 물었습니다. 그러자 빅스는 그저 웅장하게 연주하게, 그냥 웅장하게 연주하라고 대답했습니다. 미래가 다가올 때 거기에 머무는 방법은 항상 현재 보이는 것보다 시스템을 더 웅장하게 연주하는 것입니다. 와우, 와우, 와우. 좋은 아침입니다.

/////

- 앞서 번역해 드린 앨런 케이 강연의 각 흐름이 품고 있는 핵심적인 함의를 설명해 드리겠습니다 [1]. 강연의 첫 부분에서 연사는 스몰토크의 25주년을 언급하며 자신이 이룩한 과거의 성취를 기념하는 것을 넘어 객체지향의 본질을 다시 생각해보자는 화두를 던집니다 [1]. 이는 단순히 오래된 기술을 회고하는 것이 아니라 현재의 프로그래밍 환경이 초창기의 훌륭한 통찰을 잃어버렸음을 암시하는 도입부 역할을 합니다 [1, 2].

- 그래서 제록스 파크 시절의 알토 컴퓨터와 아이들의 프로그래밍 경험을 보여주는 것입니다 [2]. 당시 시스템이 추가 하드웨어 없이도 훌륭하게 작동했음을 강조하며 훌륭한 아키텍처와 설계가 근본적으로 얼마나 강력한 힘을 발휘하는지 그 함의를 전달합니다 [2].

- 그러나 많은 사람들은 컴퓨터 과학을 기존의 고전 수학처럼 엄격하고 정적인 틀에 맞추려고 노력했습니다 [3, 4]. 연사는 컴퓨팅이 고전 수학이 아니라 실용적이고 거대한 구조를 만들어내는 새로운 종류의 수학이라고 정의하며 프로그래밍은 아름다움과 실용성 사이의 정교한 균형을 찾는 과정임을 시사합니다 [4, 5].

- 그래서 객체지향이라는 단어를 처음 만들었을 때 오늘날의 문법이나 라이브러리에 집착하는 형태를 의도한 것이 아니라고 비판합니다 [6, 7]. 본질은 문법이 아니라 시스템을 구성하는 철학에 있는데 현대의 프로그래머들이 도구의 겉모습에만 매몰되어 있다는 뼈아픈 함의를 담고 있습니다 [7].

- 그러나 과거의 기계적인 사고방식인 개집 짓기 비유를 통해 단순한 코드를 무작정 키우는 것의 위험성을 경고합니다 [8, 9]. 개집을 백 배 크게 만들면 무너져 내리듯이 단순한 절차지향적 코드를 거대하게 키우면 현대의 운영 체제들처럼 쓰레기 더미가 된다는 것을 의미합니다 [9].

- 그래서 거대한 복잡성을 다루기 위해서는 재료보다 아키텍처가 훨씬 더 중요하다는 사실을 역설합니다 [10]. 샤르트르 대성당처럼 훌륭한 구조는 최소한의 재료로 최고의 무결성을 만들어내며 객체지향의 진짜 목적도 이처럼 복잡성을 우아하게 통제하는 구조를 짜는 데 있음을 암시합니다 [10].

- 그러나 사람들은 고정된 분홍색 평면 위에서 최적화만 하려는 경향이 있습니다 [11]. 연사는 창조적인 배움을 위해 기존의 맥락을 벗어나는 파란색 아이디어가 필요하다고 말하며 개발자들이 하나의 언어나 익숙한 패러다임에 갇혀 새로운 통찰을 얻지 못하는 현실을 지적합니다 [12, 13].

- 그래서 1961년 공군의 데이터 테이프 처리 방식을 예로 들며 브라우저가 모든 형식을 알아야 하는 현재의 인터넷 환경이 오히려 과거보다 퇴보했음을 꼬집습니다 [14, 15]. 데이터와 그것을 다루는 프로시저가 함께 묶여서 이동해야 한다는 진정한 캡슐화의 원형이 이미 과거에 존재했음을 보여주는 함의입니다 [15, 16].

- 그러나 이런 훌륭한 아이디어들을 사람들은 단순한 최적화 도구로만 치부했습니다 [17]. 스케치패드나 시뮬라 같은 초창기 기술들이 품고 있던 혁신을 기존 방식을 개선하는 데만 쓰지 말고 완전히 새로운 패러다임으로 받아들여야 함을 강조합니다 [17-19].

- 그래서 연사는 생물학적 비유인 대장균과 세포의 이야기를 꺼냅니다 [20, 21]. 세포는 수백억 개의 구성 요소가 서로의 내부를 모른 채 엄청난 속도와 규모로 상호작용하는데 이것이 바로 완벽하게 작동하는 이상적인 객체지향 시스템의 모습이라는 함의를 담고 있습니다 [20, 22-24].

- 그러나 서양 언어의 명사 중심적인 사고방식 때문에 우리는 객체를 정적인 사물로 오해하게 되었습니다 [24]. 일본어의 마라는 개념처럼 객체 내부의 상태보다는 객체와 객체 사이의 과정과 메시지 교환에 집중해야 함을 역설하며 객체지향이라는 용어 자체를 만든 것을 후회한다는 깊은 성찰을 보여줍니다 [24, 25].

- 그래서 자바나 씨플플 같은 언어들이 프로그래머들에게 옛날 방식을 유지하게 해주면서 오히려 새로운 은유의 강력함을 깨닫지 못하게 방해한다고 강하게 비판합니다 [26]. 객체는 데이터를 담는 상자가 아니라 그 자체로 완벽하게 독립적인 하나의 컴퓨터가 되어야 한다는 것이 진정한 캡슐화의 함의입니다 [25, 26].

- 그러나 우리는 여전히 아기를 키우는 것처럼 자연스럽게 시스템을 성장시키지 못하고 비행기를 조립하듯 멈추고 고치고 다시 컴파일하는 기계적 방식에 머물러 있습니다 [27]. 인터넷이 한 번도 멈추지 않고 1억 배나 성장한 것처럼 우리의 소프트웨어 시스템도 살아있는 생명체처럼 동적으로 진화해야 한다는 방향성을 제시합니다 [28, 29].

- 그래서 리스프가 가진 자기 반영 모델의 위대함을 칭찬하며 언어 스스로 구조를 파악하고 수정할 수 있는 메타 프로그래밍 능력이 필수적이라고 말합니다 [29, 30]. 이런 능력이 없는 시스템은 앞으로 다가올 인터넷의 거대한 상호 운용성 요구를 절대 감당할 수 없음을 암시합니다 [31, 32].

- 그러나 단일한 관점을 종교처럼 맹신하는 태도는 혁신을 가로막는 가장 큰 장애물입니다 [33]. 스몰토크조차 상업화되면서 발전을 멈추고 하나의 종교가 되어버렸다는 사실을 고백하며 우리가 만든 도구에 스스로 갇히는 우를 범해서는 안 된다는 뼈아픈 교훈을 전합니다 [33, 34].

- 그래서 마지막으로 시스템을 디자인하는 완벽한 방법을 우리는 아직 모른다는 사실을 인정하자고 제안합니다 [35]. 지금 당장의 한계에 얽매이지 말고 미래를 대비하여 항상 현재 보이는 것보다 훨씬 더 웅장하게 시스템을 연주하라는 파이프 오르간 연주자의 일화로 원대한 아키텍처를 향한 도전을 촉구하는 함의로 강연을 마무리합니다 [36, 37].