OOP의 기원 (feat. 객체와 메시지)

안녕하세요. yeTi입니다.
오늘은 OOP(Object-Oriented Programming) 라는 개념을 만든 Alan Kay 님의 ACM 프로그래밍관련 논문인 The Early History Of Smalltalk 를 읽고 후기를 공유해보고자 합니다.

Introduction

Smalltalk's design—and existence—is due to the insight that everything we can describe can be represented by the recursive composition of a single kind of behavioral building block that hides its combination of state and process inside itself and can be dealt with only through the exchange of messages. Philosophically, Smalltalk's objects have much in common with the monads of Leibniz and the notions of 20th century physics and biology. Its way of making objects is quite Platonic in that some of them act as idealizations of concepts—Ideas_—from which _manifestations can be created. That the Ideas are themselves manifestations (of the Idea-Idea) and that the Idea-Idea is a-kind-of Manifestation-Idea—which is a-kind-of itself, so that the system is completely self-describing— would have been appreciated by Plato as an extremely practical joke [Plato].
...
스몰토크의 설계와 존재는 우리가 설명할 수 있는 모든 것은 상태와 프로세스의 조합을 내부에 숨기고 메시지 교환을 통해서만 처리할 수 있는 단일 종류의 동작 빌딩 블록의 재귀적 구성으로 표현할 수 있다는 통찰력에서 비롯되었습니다. 철학적으로 스몰토크의 객체는 라이프니츠의 모나드 및 20세기 물리학 및 생물학의 개념과 많은 공통점을 가지고 있습니다. 객체를 만드는 방식은 일부 객체가 개념의 이상화, 즉 이데아로 작용하여 표현을 생성할 수 있다는 점에서 상당히 플라톤적입니다. 이데아 자체가 (이데아의) 표상이며, 이데아가 일종의 표상인 이데아 그 자체라는, 그래서 체계가 완전히 자기 설명적이라는 것은 플라톤에게 지극히 실용적인 농담으로 받아들여졌을 것입니다[플라톤].

Though it has noble ancestors indeed, Smalltalk's contribution is a new design paradigm—which I called _object-oriented_—for attacking large problems of the professional programmer, and making small ones possible for the novice user. Object-oriented design is a successful attempt to qualitatively improve the efficiency of modeling the ever more complex dynamic systems and user relationships made possible by the silicon explosion.
...
물론 고귀한 조상도 있지만, 스몰토크의 공헌은 전문 프로그래머의 큰 문제를 해결하고 초보 사용자도 작은 문제를 해결할 수 있도록 한 새로운 디자인 패러다임, 즉 객체 지향이라고 할 수 있습니다. 객체 지향 설계는 실리콘 폭발로 인해 더욱 복잡해진 동적 시스템과 사용자 관계를 모델링하는 효율성을 질적으로 개선하기 위한 성공적인 시도입니다.

개념적으로 어려운 것들이 나타나 온전히 그 뜻을 받아들이기에는 무리가 있습니다.

다만, 현재 저의 수준에서 의미있는 것은 작은 문제를 해결할 수 있도록 한다는 것이 명확한 목표였다는 것입니다.

그러기 위해서 모든 것은 상태와 프로세스의 조합을 내부에 숨기고(캡슐화) 메시지 교환을 통해서만 처리할 수 있는 단일 종류의 동작 빌딩 블록의 재귀적 구성으로 표현할 수 있다는 것입니다.

I. 1960-66—Early OOP and other formative ideas of the sixties

Though OOP came from many motivations, two were central. The large scale one was to find a better module scheme for complex systems involving hiding of details, and the small scale one was to find a more flexible version of assignment, and then to try to eliminate it altogether. As with most new ideas, it originally happened in isolated fits and starts.
...
OOP는 여러 가지 동기에서 비롯되었지만, 두 가지가 핵심이었습니다. 하나는 세부 사항을 숨겨야 하는 복잡한 시스템을 위한 더 나은 모듈 체계를 찾는 것이었고, 다른 하나는 더 유연한 버전의 할당을 찾아서 아예 없애려는 것이었습니다. 대부분의 새로운 아이디어가 그렇듯이, 이 아이디어도 원래는 개별적인 시도에서 시작되었습니다.

This was the big hit, and I've not been the same since. I think the reason the hit had such impact was that I had seen the idea enough times in enough different forms that the final recognition was in such general terms to have the quality of an epiphany. My math major had centered on abstract algebras with their few operations generally applying to many structures. My biology major had focused on both cell metabolism and larger scale morphogenesis with its notions of simple mechanisms controlling complex processes and one kind of building block able to differentiate into all needed building blocks. The 220 file system, the B5000, Sketchpad, and finally Simula, all used the same idea for different purposes. Bob Barton, the main designer of the B5000 and a professor at Utah had said in one of his talks a few days earlier: "The basic principle of recursive design is to make the parts have the same power as the whole." For the first time I thought of the whole as the entire computer and wondered why anyone would want to divide it up into weaker things called data structures and procedures. Why not divide it up into little computers, as time sharing was starting to? But not in dozens. Why not thousands of them, each simulating a useful structure?
...
그 이후로 저는 예전과 같지 않았습니다. 그 히트곡이 큰 영향을 미친 이유는 그 아이디어를 다양한 형태로 충분히 많이 접했기 때문에 최종적으로 깨달음에 가까울 정도로 일반적인 용어로 인식했기 때문이라고 생각합니다. 수학 전공은 일반적으로 많은 구조에 적용되는 몇 가지 연산이 있는 추상 대수를 중심으로 공부했습니다. 생물학 전공은 복잡한 과정을 제어하는 단순한 메커니즘과 한 종류의 구성 요소가 필요한 모든 구성 요소로 분화할 수 있다는 개념으로 세포 대사와 대규모 형태 형성에 중점을 두었습니다. 220 파일 시스템, B5000, 스케치패드, 그리고 마지막으로 Simula는 모두 같은 아이디어를 다른 용도로 사용했습니다. B5000의 주요 설계자이자 유타대학교 교수인 밥 바튼은 며칠 전 한 강연에서 이렇게 말했습니다: "재귀적 설계의 기본 원리는 부품이 전체와 동일한 힘을 갖도록 만드는 것입니다." 저는 처음으로 전체를 컴퓨터 전체로 생각했고, 왜 데이터 구조와 프로시저라는 약한 부분으로 나누려고 하는지 궁금해졌습니다. 시간 공유가 시작될 때처럼 작은 컴퓨터로 나누면 어떨까요? 하지만 수십 대는 아니었습니다. 각각 유용한 구조를 시뮬레이션하는 수천 대는 어떨까요?

당시에는 개인 컴퓨터가 활성화되지 않은 상태라 컴퓨터라는 존재도 거대한 물체였던거 같습니다.

그래서 작은 문제를 해결한다는 아이디어가 현 세대 프로그래머들이 생각하는 객체의 단위보다 큰 작은 컴퓨터 단위로 객체로 인지하는 것으로 보입니다.

III. 1970-72—Xerox PARC: The KiddiKomp, miniCOM, and Smalltalk-71

Much of the pondering during this state of grace (before any workable implementation) had to do with trying to understand what "beautiful" might mean with reference to object-oriented design. A subjective definition of a beautiful thing is fairly easy but is not of much help: we think a thing beautiful because it evokes certain emotions. The cliche has it lie "in the eye of the beholder" so that it is difficult to think of beauty as other than a relation between subject and object in which the predispositions of the subject are all important.
...
이 유예 기간 동안 (실행 가능한 구현이 이루어지기 전) 많은 고민은 객체 지향 디자인과 관련하여 "아름답다"는 것이 무엇을 의미하는지 이해하려고 노력하는 것과 관련이 있었습니다. 아름다운 것에 대한 주관적인 정의는 매우 쉽지만 큰 도움이 되지 않습니다. 우리는 어떤 사물이 특정 감정을 불러일으키기 때문에 아름답다고 생각합니다. 진부한 표현이지만 아름다움은 '보는 사람의 눈'에 달려 있기 때문에 주체의 성향이 모두 중요한 주체와 객체 간의 관계 외에는 아름다움을 생각하기 어렵습니다.

객체 지향 디자인에 대한 고민이 표현되어 있습니다.

아름다움이라는 단어를 예시로 주관적인 정의가 실행 가능한 구현에는 도움이 되지 않기 때문에 표현의 의미에 대해 이해하고 노력하는 것이 어렵다고 말하고 있습니다.

표현의 의미에 대해 이해하고 노력하는 것이 어렵다는 표현이 저에게 의미있게 다가왔습니다.

객체지향이라고 하면 흔히 추상화, 상속, 다형성, 캡슐화를 얘기하고 SOLID를 달성하는 것을 얘기합니다. 근본적으로 객체를 어떻게 정의하고 관계를 어떻게 정의할 것 인지에 대해서는 심도있게 다루는 자료를 아직 접하지 못했기 때문입니다.

IV. 1972-76—The first real Smalltalk (-72), its birth, applications, and improvements

Of course, the whole idea of Smalltalk (and OOP in general) is to define everything intensionally. And this was the direction of movement as we learned how to program in the new style. I never liked this syntax (too many parentheses and nestings) and wanted something flatter and more grammar-like as in Smalltalk-71. To the right is an example syntax from the notes of a talk I gave around then. We will see something more like this a few years later in Dan's design for Smalltalk-76. I think something similar happened with LISP—that the "reality" of the straightforward and practical syntax you could program in prevailed against the flights of fancy that never quite got built.
...
물론 스몰토크(그리고 일반적으로 OOP)의 전체 아이디어는 모든 것을 의도적으로 정의하는 것입니다. 그리고 이것이 새로운 스타일로 프로그래밍하는 방법을 배우면서 우리가 나아갈 방향이었습니다. 저는 이 구문(괄호와 중첩이 너무 많음)이 마음에 들지 않았고, Smalltalk-71에서처럼 좀 더 평평하고 문법적인 것을 원했습니다. 오른쪽은 제가 그 무렵에 했던 강연의 노트에 있는 예제 구문입니다. 몇 년 후 Dan이 설계한 Smalltalk-76에서 이와 비슷한 것을 보게 될 것입니다. LISP에서도 비슷한 일이 일어났다고 생각합니다. 프로그래밍할 수 있는 간단하고 실용적인 구문이라는 '현실'이 공상적인 공상보다 우세했던 것이죠.

머리속에 바로 인식되는 문장이 있었습니다.

의도적으로 정의하는 것입니다.

바로 안영회 대표님께서 말씀해주셨던 객체지향의 정의가 떠올랐습니다.

I define.

결국 객체 지향이 의미하는 바는 설계자가 전지적인 시점에서 의도적으로 세계를 정의해나가는 것입니다.

Smalltalk-74 (sometimes known as FastTalk) was a version of Smalltalk-72 incorporating major improvements which included providing a real "messenger" object, message dictionaries for classes (a step towards real class objects), Diana Merry's bitblt (the now famous 2D graphics operator for bitmap graphics) redesigned by Dan and implemented in microcode, and a better, more general window interface. Dave Robson while a student at UC Irvine had heard of our project and made a pretty good stab at implementing an OOPL. We invited him for a summer and never let him go back—he was a great help in formulating an official semantics for Smalltalk.
...
Smalltalk-74(FastTalk라고도 함)는 실제 "메신저" 객체 제공, 클래스용 메시지 사전(실제 클래스 객체를 향한 한 걸음), 댄이 재설계하고 마이크로코드로 구현한 다이애나 메리의 bitblt(비트맵 그래픽을 위한 현재 유명한 2D 그래픽 연산자), 더 나은 일반 창 인터페이스 등 주요 개선 사항이 포함된 Smalltalk-72의 버전이었습니다. UC 어바인에 재학 중이던 데이브 롭슨은 우리 프로젝트에 대해 들어본 적이 있었고, OOPL을 구현하는 데 꽤 능숙했습니다. 우리는 그를 여름방학에 초대했고, 그는 Smalltalk의 공식적인 의미론을 공식화하는 데 큰 도움을 주었습니다.

그리고 또 하나의 키워드가 나옵니다. 메시지

"Object-oriented" Style

Even the way we taught children (cf. ahead) reflected this way of looking at objects. Not too surprisingly this approach has considerable bearing on the ease of programming, the size of the code needed, the integrity of the design, etc. It is unfortunate that much of what is called "object-oriented programming" today is simply old style programming with fancier constructs. Many programs are loaded with "assignment-style" operations now done by more expensive attached procedures.
...
우리가 아이들을 가르치는 방식(앞부분 참조)도 이러한 객체를 바라보는 방식을 반영했습니다. 이 접근 방식은 프로그래밍의 용이성, 필요한 코드의 크기, 디자인의 무결성 등과 상당한 관련이 있습니다. 안타깝게도 오늘날 "객체 지향 프로그래밍"이라고 불리는 것의 대부분은 더 멋진 구조를 가진 오래된 스타일의 프로그래밍에 불과합니다. 많은 프로그램에는 이제 더 비싼 첨부 프로시저를 통해 수행되는 "할당 스타일" 연산이 가득합니다.

Where does the special efficiency of object-oriented design come from? This is a good question given that it can be viewed as a slightly different way to apply procedures to data-structures. Part of the effect comes from a much clearer way to represent a complex system. Here, the constraints are as useful as the generalities. Four techniques used together—persistent state, polymorphism, instantiation, and methods-as-goals for the object—account for much of the power. None of these require an "object-oriented language" to be employed—ALGOL 68 can almost be turned to this style—an OOPL merely focuses the designer's mind in a particular fruitful direction. However, doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming.
...
객체 지향 설계의 특별한 효율성은 어디에서 오는 것일까요? 이는 데이터 구조에 프로시저를 적용하는 약간 다른 방식으로 볼 수 있다는 점에서 좋은 질문입니다. 그 효과의 일부는 복잡한 시스템을 훨씬 더 명확하게 표현하는 방법에서 비롯됩니다. 여기서 제약 조건은 일반성만큼이나 유용합니다. 영구 상태, 다형성, 인스턴스화, 객체에 대한 목표로서의 메서드 등 네 가지 기법이 함께 사용되는데, 이 기법들이 많은 부분을 차지합니다. 이 중 어느 것도 "객체 지향 언어"를 사용할 필요는 없으며(ALGOL 68은 거의 이 스타일로 전환할 수 있습니다), OOPL은 단지 디자이너의 마음을 특정한 유익한 방향으로 집중시킬 뿐입니다. 그러나 캡슐화를 올바르게 수행한다는 것은 단순히 상태를 추상화하는 것뿐만 아니라 프로그래밍에서 상태 지향 은유를 제거하겠다는 약속입니다.

객체 지향 설계의 효율성은 복잡한 시스템을 훨씬 더 명확하게 표현하는 방법이라고 합니다. 그러기 위해서 행하는 추상화는 현실세계를 적절한 상태를 가진 데이터 구조와 프로시저로 표현한다는 것이라고 이해가 되지만 상태 지향 은유는 어떤 것을 표현하는 것인지 잘 모르겠습니다.

I believe that the much smaller size of a good OOP system comes not just by being gently forced to come up with a more thought out design. I think it also has to do with the "bang per line of code" you can get with OOP. The object carries with it a lot of significance and intention, its methods suggest the strongest kinds of goals it can carry out, its superclasses can add up to much more code-functionality being invoked than most procedures-on-data-structures. Assignment statements—even abstract ones—express very low-level goals, and more of them will be needed to get anything done. Generally, we don't want the programmer to be messing around with state, whether simulated or not. The ability to instantiate an object has a considerable effect on code size as well. Another way to think of all this is: though the late-binding of automatic storage allocations doesn't do anything a programmer can't do, its presence leads both to simpler and more powerful code. OOP is a late binding strategy for many things and all of them together hold off fragility and size explosion much longer than the older methodologies. In other words, human programmers aren't Turing machines—and the less their programming systems require Turing machine techniques the better.
...
저는 좋은 OOP 시스템의 크기가 훨씬 작아진다는 것은 단순히 신중한 설계를 강요받는다고 해서 얻어지는 것이 아니라고 생각합니다. OOP를 통해 얻을 수 있는 '코드 한 줄당 효과'와도 관련이 있다고 생각합니다. 객체에는 많은 의미와 의도가 담겨 있고, 메서드는 객체가 수행할 수 있는 가장 강력한 종류의 목표를 제시하며, 슈퍼클래스는 대부분의 프로시저 온 데이터 구조보다 훨씬 더 많은 코드 기능을 호출할 수 있습니다. 할당 문은 추상적이라 할지라도 매우 낮은 수준의 목표를 표현하며, 어떤 작업을 수행하려면 더 많은 할당 문이 필요합니다. 일반적으로 프로그래머는 시뮬레이션 여부와 관계없이 상태를 엉망으로 만드는 것을 원하지 않습니다. 객체를 인스턴스화하는 기능은 코드 크기에도 상당한 영향을 미칩니다. 이 모든 것을 다른 방식으로 생각해보면, 자동 저장소 할당의 후기 바인딩이 프로그래머가 할 수 없는 일을 하지는 않지만, 이 기능이 있으면 더 간단하고 강력한 코드를 만들 수 있습니다. OOP는 많은 것들에 대한 후기 바인딩 전략이며, 이 모든 것을 함께 사용하면 이전 방법론보다 훨씬 더 오래 취약성과 크기 폭발을 억제할 수 있습니다. 다시 말해, 인간 프로그래머는 튜링 머신이 아니며, 프로그래밍 시스템에 튜링 머신 기술이 덜 필요할수록 더 좋습니다.

좋은 OOP 시스템은 신중한 설계를 강요받는다고 해서 얻어지는 것이 아니라고 말합니다.

OOP는 많은 것들에 대한 후기 바인딩 전략이며, 이 모든 것을 함께 사용하면 이전 방법론보다 훨씬 더 오래 취약성과 크기 폭발을 억제할 수 있습니다.

후기 바인딩은 검색해보니 동적 바인딩(Dynamic Binding)과 동일한 의미로 보입니다. Java에서 동적 바인딩은 runtime시에 객체의 특성을 정의할 때 사용합니다.

동적 바인딩을 사용해야 더 간결하고 강력한 코드를 만들 수 있다고 얘기하는데요. 스스로 이해를 하기 위해서는 좀 더 시간이 필요합니다.

Smalltalk and Children

객체 지향을 배우는 입장에서 공부의 방향성을 알 수 있는데 도움이 많이 된 섹션입니다.

The connection to literacy was painfully clear. It isn't enough to just learn to read and write. There is also a literature that renders ideas. Language is used to read and write about them, but at some point the organization of ideas starts to dominate mere language abilities. And it helps greatly to have some powerful ideas under one's belt to better acquire more powerful ideas [Papert 70s]. So, we decided we should teach design. And Adele came up with another brilliant stroke to deal with this. She decided that what was needed was an intermediary between the vague ideas about the problem and the very detailed writing and debugging that had to be done to get it to run in Smalltalk. She called the intermediary forms design templates.
...
문해력과의 연관성은 고통스러울 정도로 분명했습니다. 단순히 읽고 쓰는 법을 배우는 것만으로는 충분하지 않습니다. 아이디어를 표현하는 문학도 있습니다. 언어는 읽고 쓰는 데 사용되지만, 어느 순간 아이디어의 조직화가 단순한 언어 능력을 지배하기 시작합니다. 그리고 더 강력한 아이디어를 더 잘 얻기 위해서는 강력한 아이디어를 정리해두는 것이 큰 도움이 됩니다[페이퍼 70년대]. 그래서 우리는 디자인을 가르쳐야겠다고 결정했습니다. 그리고 아델은 이 문제를 해결하기 위해 또 다른 기발한 아이디어를 떠올렸습니다. 그녀는 문제에 대한 막연한 아이디어와 이를 스몰토크에서 실행하기 위해 수행해야 하는 매우 상세한 작성 및 디버깅 사이의 중개자가 필요하다고 결정했습니다. 그녀는 그 중개자를 양식 디자인 템플릿이라고 불렀습니다.

문해력

프로그래머가 아닌 성인에게 스몰토크를 가르친 경험에서 초기 자료는 아이들보다 빠르게 이해했지만 정작 프로그래밍을 하지 못하는 문제를 문해력과 관련이 있다고 말하고 있습니다.

당시의 충격은 링크드인에 기록해 두었습니다.

지금까지 설계를 잘하기 위해서 부족한 기술적인 요소들을 채우기 위해 한걸음씩 정진하고 있었습니다. 그런데 학부과정에서도 가이드 받지 못했던 문해력이 설계를 하는데 도움이 된다는 것은 그 동안 프로그래밍을 바라보던 관점에 대한 의구심으로까지 퍼지게 되었습니다.

But not enough to satisfy us. As Adele liked to point out, it is hard to claim success if only some of the children are successful—and if a maximum effort of both children and teachers was required to get the successes to happen. Real pedagogy has to work in much less idealistic settings and be considerably more robust. Still, some successes are qualitatively different from no successes. We wanted more, and started to push on the inheritance idea as a way to let novices build on frameworks that could only be designed by experts. We had good reason to believe that this could work because we had been impressed by Lisa van Stone's ability to make significant changes to SHAZAM (the five or six page Smalltalk animation tool done by relatively expert adults). Unfortunately, inheritance—though an incredibly powerful technique—has turned out to be very difficult for novices (and even professionals) to deal with.
...
하지만 그것만으로는 만족할 수 없습니다. 아델이 지적했듯이, 아이들 중 일부만 성공하고 그 성공을 위해 아이들과 교사 모두의 노력이 최대한 필요하다면 성공이라고 말하기 어렵습니다. 실제 교육학은 훨씬 덜 이상주의적인 환경에서 작동해야 하며 훨씬 더 견고해야 합니다. 하지만 일부 성공은 성공하지 못한 것과 질적으로 다릅니다. 저희는 더 많은 것을 원했고, 전문가만이 설계할 수 있는 프레임워크를 초보자도 구축할 수 있는 방법으로 상속 아이디어를 추진하기 시작했습니다. 비교적 전문가가 만든 5~6페이지 분량의 Smalltalk 애니메이션 도구인 SHAZAM에 상당한 변화를 가져온 Lisa van Stone의 능력에 깊은 인상을 받았기 때문에 이 아이디어가 성공할 수 있다고 믿을 만한 충분한 이유가 있었죠. 안타깝게도 상속은 매우 강력한 기술이지만 초보자는 물론 전문가도 다루기 매우 어려운 것으로 밝혀졌습니다.

상속은 매우 강력한 기술이지만 다루기 어렵다고 밝혀졌다고 합니다.

이는 백기선님의 이펙티브 자바에서도 객체의 상속에 대해 다음과 같이 얘기했습니다.

상속받은 클래스에서 필드를 추가하면 추이성을 절대 지킬 수 없고, 구현한 코드에 따라 무한루프나 리스코프 치환법칙이 위배되는 경우가 있기도 합니다.
이럴 때는 Composition pattern을 적용하여 문제를 해결할 수 있습니다.

그리고 테스트 주도 개발(TDD)에서도 기능의 확장에 대해 다음과 같이 설명합니다.

자바 오퍼레이션에 대한 두 번째 구현을 추가하려면 어떻게 해야 할까?
공통되는 오퍼레이션을 담고 있는 인터페이스를 만들면 됩니다.

이를 보면 후대에 지속적으로 상속을 사용하지 않는 아이디어들이 상속의 기능을 대체하고 있다는 느낌을 받습니다.

Should we even try to teach programming? I have met hundreds of programmers in the last 30 years and can see no discernible influence of programming on their general ability to think well or to take an enlightened stance on human knowledge. If anything, the opposite is true. Expert knowledge often remains rooted in the environments in which it was first learned—and most metaphorical extensions result in misleading analogies. A remarkable number of artists, scientists, philosophers are quite dull outside of their specialty (and one suspects within it as well). The first siren's song we need to be wary of is the one that promises a connection between an interesting pursuit and interesting thoughts. The music is not in the piano, and it is possible to graduate Juilliard without finding or feeling it.
...
프로그래밍을 가르쳐야 할까요? 저는 지난 30년 동안 수백 명의 프로그래머를 만났지만, 프로그래밍이 일반적인 사고 능력이나 인간 지식에 대한 계몽적인 자세에 미치는 영향에 대해 뚜렷한 영향을 발견할 수 없었습니다. 오히려 그 반대의 경우가 더 많았습니다. 전문 지식은 종종 처음 학습한 환경에 뿌리를 두고 있으며, 대부분의 은유적 확장은 오해의 소지가 있는 유추를 낳습니다. 상당수의 예술가, 과학자, 철학자들은 자신의 전문 분야 외에는 상당히 둔감합니다(심지어는 그 분야 내에서도 의심되는 경우도 있습니다). 우리가 경계해야 할 첫 번째 사이렌의 노래는 흥미로운 추구와 흥미로운 생각 사이의 연결을 약속하는 노래입니다. 음악은 피아노에 있지 않으며, 그것을 찾거나 느끼지 않고 줄리아드를 졸업 할 수 있습니다.

프로그래밍이라는 도구보다 문제를 해결하는 사고력이 보다 가치있다고 말하는듯 합니다.

Tools provide a path, a context, and almost an excuse for developing enlightenment, but no tool ever contained it or can dispense it. Cesare Pavese observed: to know the world we must construct it. In other words, we make not just to have, but to know. But the having can happen without most of the knowing taking place.
...
도구는 깨달음을 얻기 위한 경로와 맥락, 그리고 거의 모든 핑계를 제공하지만, 그 어떤 도구도 깨달음을 포함하지도 않고, 깨달음을 대신할 수도 없습니다. 세자레 파베제는 세상을 알기 위해서는 세상을 구성해야 한다고 말했습니다. 다시 말해, 우리는 단순히 소유하는 것이 아니라 알기 위해 만들어야 합니다. 그러나 대부분의 앎이 이루어지지 않은 상태에서 소유는 일어날 수 있습니다.

앞서 문단과 같이 도구에 제한되지 말고 세상을 알아야 한다고 얘기합니다.

요즘 ChatGPT가 대두되면서 도구의 자동화라는 측면에서 일맥상통하다는 느낌을 받습니다.

The first is fluency, which in part is the process of building mental structures that disappear the interpretation of the representations. The letters and words of a sentence are experienced as meaning rather than markings, the tennis racquet or keyboard becomes an extension of one's body, and so forth. If carried further one eventually becomes a kind of expert—but without deep knowledge in other areas, attempts to generalize are usually too crisp and ill formed.
...
첫 번째는 유창성인데, 이는 부분적으로 표현의 해석이 사라지는 정신 구조를 구축하는 과정입니다. 문장의 글자와 단어가 표시가 아닌 의미로 경험되고, 테니스 라켓이나 키보드가 몸의 연장선이 되는 등의 경험을 하게 됩니다. 더 나아가면 결국 일종의 전문가가 되지만, 다른 분야에 대한 깊은 지식이 없으면 일반화하려는 시도는 대개 너무 선명하고 잘못 형성됩니다.

The second path is towards taking the knowledge as a metaphor than can illuminate other areas. But without fluency it is more likely that prior knowledge will hold sway and the metaphors from this side will be fuzzy and misleading.
...
두 번째 길은 지식을 다른 영역을 조명할 수 있는 은유로 받아들이는 것입니다. 그러나 유창하지 않으면 사전 지식이 주도권을 쥐고 이쪽의 은유는 모호하고 오해의 소지가 있을 가능성이 더 높습니다.

학습의 수준을 단순하게 안다라는 것을 넘어서, 유창하게 사용할 수 있을 때 전문가가 될 수 있다고 얘기합니다.

The "trick," and I think that this is what liberal arts educations is supposed to be about, is to get fluent and deep while building relationships with other fluent deep knowledge. Our society has lowered its aims so far that it is happy with "increases in scores" without daring to inquire whether any important threshold has been crossed. Being able to read a warning on a pill bottle or write about a summer vacation is not literacy and our society should not treat it so. Literacy, for example, is being able to fluently read and follow the 50 page argument in Paine's Common Sense and being able (and happy) to fluently write a critique or defense of it. Another kind of 20th century literacy is being able to hear about a new fatal contagious incurable disease and instantly know that a disastrous exponential relationship holds and early action is of the highest priority. Another kind of literacy would take citizens to their personal computers where they can fluently and without pain build a systems simulation of the disease to use as a comparison against further information.
...
유창하고 깊은 지식을 쌓으면서 다른 유창하고 깊은 지식과 관계를 맺는 것이 교양 교육의 '요령'이고, 이것이 바로 교양 교육의 목적이라고 생각합니다. 우리 사회는 지금까지 목표를 너무 낮춰서 중요한 문턱을 넘었는지 굳이 묻지 않고 '점수 상승'에 만족하고 있습니다. 약병에 적힌 경고문을 읽거나 여름방학에 대한 글을 쓸 수 있는 것은 문해력이 아니며, 우리 사회가 이를 그렇게 취급해서는 안 됩니다. 예를 들어, 리터러시는 페인의 상식』의 50페이지에 달하는 논증을 유창하게 읽고 따라갈 수 있으며, 이에 대한 비평이나 변호를 유창하게 작성할 수 있는 능력입니다. 20세기의 또 다른 종류의 리터러시는 새로운 치명적인 전염성 난치병에 대한 소식을 듣고 재앙적인 기하급수적 관계가 있으며 조기 조치가 최우선이라는 것을 즉시 알아차릴 수 있는 것입니다. 또 다른 종류의 리터러시는 시민들이 개인용 컴퓨터로 이동하여 유창하고 고통 없이 질병에 대한 시스템 시뮬레이션을 구축하여 추가 정보와 비교하는 데 사용할 수 있는 것입니다.

다시 한번 놀라운 느낌을 받습니다.

해당 글이 쓰여진 시점은 1972-76년입니다. 그러나 현 시점의 한국 사회에서 만연한 점수 상승에 만족하는 문제를 지적하고 있습니다.

이를 보면 미국의 교육과 한국의 교육이 가치있게 생각하는 것의 갭이 50년이 발생한것으로 느껴집니다.

문해력이란 글을 읽고 쓰는데에 그치는 것이 아니라 지식을 깊이있게 습득하고 서로 다른 지식간에 관계를 맺어 자신만의 생각을 만들어내는 능력이라고 설명하고 있습니다.

여기서 회사 동료인 오은범님의 질문이 생각납니다.

ChatGPT가 문해력을 가지고 있지 않을까요?

카이스트 김대식 교수 | (1부) “인공지능 시대에 애플의 움직임이 없는 이유” 처음 듣는 챗GPT 이야기에 따르면 ChatGPT의 답변은 기존 지식을 기반으로 가장 자연스러운 문장을 만들어내는 능력은 있지만 자신만의 생각으로 전환하는 능력은 없습니다.

그렇기 때문에 ChatGPT가 문해력을 가졌다고는 볼 수 없습니다.

The reason, therefore, that many of us want children to understand computing deeply and fluently is that like literature, mathematics, science, music, and art, it carries special ways of thinking about situations that in contrast with other knowledge and other ways of thinking critically boost our ability to understand our world.
...
따라서 많은 사람들이 아이들이 컴퓨팅을 깊고 유창하게 이해하기를 바라는 이유는 문학, 수학, 과학, 음악, 예술과 마찬가지로 컴퓨팅이 다른 지식이나 다른 사고 방식과는 대조적으로 상황에 대한 특별한 사고 방식을 담고 있어 세상을 이해하는 능력을 크게 향상시키기 때문입니다.

컴퓨팅을 잘하기 위해서는 특별한 사고 방식으로 세상을 이해하는 능력을 향상시키기 때문이라고 합니다.

그리고 이를 달성할 수 있는 방법은 앞서 지속적으로 언급하고 있는 문해력입니다.

V. 1976-80—The first modern Smalltalk (-76), its birth, applications, and improvements

We could see that the "pushing" style of Smalltalk could eventually be replaced by a "pulling" style that was driven by changes to values that different methods were based on. This was an old idea but Thinglab showed how the object-oriented definition could be used to automatically limit the contexts for event-driven processing. And we soon discovered that "prototypes" were more hospitable than classes, and that multiple inheritance would be well served if there were classes for methods that knew generally what they were supposed to be about (inspired by Pat Winston's 2nd order models).
...
우리는 Smalltalk의 "푸시" 스타일이 결국 다른 메서드의 기반이 되는 값의 변경에 의해 구동되는 "풀링" 스타일로 대체될 수 있음을 알 수 있었습니다. 이것은 오래된 아이디어였지만 Thinglab은 객체 지향 정의를 사용하여 이벤트 중심 처리를 위한 컨텍스트를 자동으로 제한할 수 있는 방법을 보여주었습니다. 그리고 곧 클래스보다 '프로토타입'이 더 적합하며, 메서드가 일반적으로 무엇을 해야 하는지 알고 있는 메서드에 대한 클래스가 있으면 다중 상속이 잘 지원된다는 사실을 알게 되었습니다(Pat Winston의 2차 주문 모델에서 영감을 얻었습니다).

객체 지향 정의를 사용하여 이벤트 중심 처리를 위한 컨텍스트를 제한한다고 합니다.

저는 이 문장을 보고 가장 처음에 언급되었던 객체와 객체간 소통할 수 있는 메시지를 이벤트 중심 처리라는 문장으로 표현했다고 느꼈고,

객체와메시지라는 두 단어가 객체 지향을 이해하는 가장 기본적인 개념이라는 느낌을 받았습니다.

결론

[The Early History Of Smalltalk]을 읽으면서 느낀점은 살아있는 정보를 접하는 생동감이 주는 몰입과 지식에서 지식의 습득에서 나아간 이해의 폭을 넓힐 수 있었던 것입니다.

개발활동을 하면서, 아니면 일상 생활에서도 빠르고 간편하게 지식을 얻는 방법은 검색을 통하여 정리된 지식을 받아들이는 형태입니다.

이러한 지식의 습득 방식은 지식을 효율적으로 득할 수는 있더라도 그 지식이 만들어진 맥락은 알 수 없어 다음 단계로 진전할 수 있는 힘을 가질 수 없습니다.

그리고 OOP(Object-Oriented Programming)에 대한 지식의 폭을 넓히고 싶어 읽게된 논문에서 그 동안 전달받았던 지식의 언급이 아닌,

프로그래밍을 위한 설계를 잘하기 위해서는 문해력과 비판적 사고가 필요하다고 얘기하고 있는 부분에서 공부의 방향성을 점검해 볼 수 있는 계기가 되었고,

객체라는 개념으로 풀고 싶었던 궁극적인 문제는 복잡한 시스템을 단일 세포와 세포간 신호를 전달하는 체계와 같이 단순한 구성의 집합체로 표현하고자 함이었다는 것을 알 수 있었습니다.

앨런 케이의 생각이 궁금한 분들께 읽어보시기를 추천드립니다.