[OOP] 객체지향 프로그래밍의 본질

250x250

Notice

Recent Posts

Recent Comments

Link

« 2026/06 »
일	월	화	수	목	금	토
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

Tags more

Archives

Today

Total

관리 메뉴

그냥저냥

[OOP] 객체지향 프로그래밍의 본질 - 앨런케이 세미나! 본문

일상,잡담

[OOP] 객체지향 프로그래밍의 본질 - 앨런케이 세미나!

sync86 2025. 6. 11. 21:32

728x90

"새로운 아이디어는 처음엔 미친 짓처럼 보이고, 그다음엔 모두가 원래부터 알던 것처럼 여기며, 마지막엔 처음 반대하던 사람이 자기가 고안했다고 주장한다."— 윌리엄 제임스

참고로 이 포스팅은 ChatGPT에 요청해서 작성되어졌음을 먼저 밝힌다. 직접 작성한 글 보다 퀄리티가 더 좋은 것 같다.

https://www.youtube.com/watch?v=QjJaFG63Hlo&t=622s

앨런케이 세미나

객체지향 프로그래밍은 정말 새로운 개념일까?

많은 사람들이 객체지향 프로그래밍(Object-Oriented Programming, 이하 OOP)을 비교적 최근에 등장한 기법으로 생각한다. 하지만 앨런케이는 "OOP는 사실 꽤 오래된 기술입니다."라고 말했다.

그는 1962년에 자신이 OOP 방식으로 첫 프로그램을 작성했다고 말한다.

그가 공군에 근무하던 시절, 다양한 형태의 데이터를 테이프에 담아 다른 기지로 전송하는 문제가 있었다고 한다. 당시엔 운영체제가 표준화되어 있지 않아 데이터를 읽는 방식이 제각각이었는데 이를 해결한 아이디어가 흥미로웠다.

데이터를 세 부분으로 나눠 첫 번째는 인덱스, 두 번째는 해당 데이터를 처리하는 코드, 세 번째는 실 데이터로 구성했다.

데이터 구조가 너무 다양하면 어떻게 읽어야 하는지 알 수 없다. 하나하나 분석하고 읽어내는 데 오랜 시간이 걸릴 것이다. 그러나 데이터를 읽는 코드와 데이터가 함께 묶여 있다면 데이터를 읽는 코드만 실행하면 결과를 얻을 수 있을 것이다.

이 구조는 오늘날 객체지향 개념의 원형으로 볼 수 있다고 말한다. 즉, "프로토콜과 코드, 그리고 데이터를 함께 포장해서 전달한다"는 방식이다.

객체란 무엇인가?

앨런케이는 객체지향의 아이디어가 생물학에서 출발했다고 설명한다.

"나는 분자생물학을 공부했는데, 생물 시스템은 우리가 컴퓨터로 만든 시스템보다 천 배는 복잡하다는 사실에 놀랐죠."

그는 세포를 객체의 메타포로 삼는다. 세포는 외부 세계로부터 자신을 보호하면서도, 메시지를 통해 다른 세포들과 소통합니다.

이 개념은 객체지향의 기본 철학과 일치한다.

그가 강조하는 중요한 원칙 중 하나는 바로 캡슐화(encapsulation) 이다. 마치 세포가 외부와 격리된 채 작동하듯 객체는 내부 상태와 로직을 숨기고 외부에 오직 '행동(behavior)'만을 제공한다.

메시지는 명령이 아니다.

앨런케이는 객체 간 통신에서 "메시지(message)는 명령(command)이 아니라 의도(intent)"라고 말한다. 예를들어 시스템 파일을 조작할 수 있는 객체가 있다고 할 때, 그 객체에 "바이트 5를 0으로 바꿔라"라는 명령을 보낼 수 있어서는 안된다고 말하고 있다.

객체는 스스로 판단하여 요청을 수락하거나 거절할 수 있어야 하며 이를 통해 보안과 안정성을 유지할 수 있다.

이 개념은 오늘날 '보안 프로그래밍'이나 '능력 기반 보안(capability-based security)'과도 깊은 연관이 있다고 한다. 그러나 이에 대해서는 자세히 아는 내용이 없다.

데이터를 설계할 것인가, 행동을 설계할 것인가?

앨런케이는 객체지향 프로그래밍의 핵심을 단순한 '데이터를 감싼 함수'로 오해하지 말라고 경고한다. 수 많은 OOP 언어들이 마치 "데이터 구조 + 메서드"로 객체를 구성하는 것으로 이해되지만 이것은 본질이 아니다고 말한다.

그가 강조하는 객체란 다음과 같은 존재이다.

스스로 상태(state)와 행동(behavior)을 갖는 작은 컴퓨터.
외부로부터 보호되고, 메시지를 받아들일 수는 있지만 내부는 침범할 수 없음.
전달된 메시지는 명령이 아닌 제안이며, 객체가 이를 수락할지 거절할지는 그 객체의 자유.

즉, 객체는 단순한 구조가 아닌 권한을 스스로 통제하는 에이전트(agent)인 셈이다.

언제나 작고 강력해야 한다.

객체지향의 가장 강력한 특징은 바로 모듈화(Modularity) 와 보호(Protection)라고 말한다. 앨런케이는 객체지향 시스템이 다음과 같은 조건을 만족해야 한다고 말하고 있다.

캡슐화: 내부 상태는 외부로부터 철저히 은닉되어야 한다.
메시지 기반 통신: 객체 간의 상호작용은 절대로 직접 접근이 아닌 메시지 전달을 통해 이루어져야 한다.
위임 또는 수락: 객체는 전달된 메시지를 수락하거나 거절할 권한을 가져야 한다.

예를 들어 어떤 객체가 시스템 파일을 표현하고 있다고 가정하자. 다른 객체가 그 파일에 접근하고 싶다고 할 때, 단순히 포인터를 가지고 있다고 해서 직접 변경할 수 있어서는 안된다고 한다.

이는 능력 기반 보안(Capability-based security) 개념과도 연결된다고 하는데, 앞서 언급했지만 이에 대해서는 자세히 모른다.

데이터 추상화와의 차이

데이터 추상화(Data Abstraction)도 데이터를 보호하는 방법 중 하나지만 객체지향과는 그 목적이 다르다. 데이터 추상화는 기존 언어(예: Pascal, Ada, Fortran 등)의 한계를 보완하기 위해 데이터 구조를 감싸는 인터페이스를 정의한다고 말하고 있다.

하지만, 대부분의 경우 여전히 '수동적인 데이터 구조'를 넘어서지 못한다. 객체지향의 목표는 '데이터 구조를 개선'하는 것이 아니라, 실제로 살아있는 개체를 설계하는 것이다.

앨런케이는 이를 이렇게 설명하고 있다.

“데이터 구조는 '편집 가능한 상태'를 외부에 노출 하지만, 좋은 객체는 편집 대상이 아니라 자기 주도적으로 변화하는 존재입니다.”

사례: 살아있는 객체로서의 인사 기록

앨런케이는 Ada나 COBOL 등에서 흔히 볼 수 있는 '인사기록(personnel record)' 예제를 들며 다음과 같은 비교를 한다.

전통적 방식: 나이, 이름, 부서 등의 필드가 있는 구조체. 외부에서 직접 값을 변경.
객체지향 방식: 해당 객체는 자기 자신의 생일을 알고 있으며, 시간이 흐르면 스스로 나이를 증가시킴. 외부에서 ‘나이를 1 올려라’는 명령을 내릴 필요가 없음.

이런 객체는 더 이상 수동적인 '기록'이 아니라, 자율적인 존재다.

작은 것이 아름답다 — 객체지향의 힘

객체지향 프로그래밍(OOP)의 진정한 힘 중 하나는 작고 재사용 가능한 구조로도 매우 큰 시스템을 설계할 수 있다는 점이다.

앨런 케이는 자신이 Xerox PARC에서 개발한 Smalltalk 시스템 전체가 약 40,000줄의 코드로 구현되었다고 말하고 있는데, 이 안에는 운영체제, 사용자 인터페이스, 텍스트 편집기, 그래픽 툴 등 모든 기능이 포함되어 있다고 한다.

이를 오늘날 우리가 사용하는 수십만 줄짜리 유닉스 커널(약 400,000줄)과 비교해보면 그 간결함은 실로 충격적이다. 또 다른 사례는 애플 초기 Macintosh 팀이 만든 프로토타입인데, 맥 페인트, 맥 드로우, 파인더 등 핵심 앱이 전부 포함된 코드가 단 8,000줄이었다고 소개한다.

객체지향 설계가 코드를 줄이는 이유

객체지향 설계가 코드량을 줄이는 이유는 단순하다고 설명한다.

코드의 재사용 가능성
- 잘 설계된 객체는 여러 시스템에서 재사용할 수 있다. 복사해서 붙여넣는 것이 아니라 상속(Inheritance) 과 합성(Composition) 을 통해 동작한다.
행동 단위 설계
- 객체는 단지 데이터를 담는 구조가 아니라, 스스로 동작하고 책임을 갖는 주체이다. 데이터 중심의 설계보다, 행동 중심의 설계가 중복을 줄입니다.
고수준의 추상화
- '상태'보다 '행동'을 중심에 두면, 구현 세부사항이 숨겨지고 프로토콜 중심의 통신이 가능합니다. 이를 통해 더 추상적이고 유연한 코드 구조가 만들어집니다.

사례: Arthur Andersen의 객체지향 프로그래밍 언어로 전환

1980~90년대, 대형 컨설팅 회사 Arthur Andersen(현 Accenture)은 대규모 객체지향 시스템을 성공적으로 도입한 사례를 소개한다.

기존 방식
1. 시스템: Brooklyn Union Gas의 회계 및 정보시스템
2. 언어: COBOL
3. 예상 규모: 170만 줄
4. 예상 기간: 약 2년
객체지향 방식
- 설계 언어: Smalltalk (프로토타입)
- 구현 언어: PL/1 (IBM 메인프레임에 맞게 포팅)
- 실 코드량: 15만 줄
- 개발 기간: 기존보다 6개월 단축
- 약 11배 줄어든 코드
- 유지보수 기간 단축 및 재사용 가능한 라이브러리 획득

이 프로젝트의 가장 중요한 성과는 ‘빠른 개발’보다 높은 유지보수성(reusability)이었다. 앨런케이는 이를 다음과 같이 정리한다.

“실제 기업에서 가장 부족한 자원은 개발자 수가 아니라 '좋은 설계자'입니다. 객체지향 설계는 이들의 작업을 재사용 가능한 구성요소로 만들어줍니다.”

설계의 변화, 사용자 중심의 변화

이러한 객체지향적 접근은 단지 개발자만을 위한 것이 아니다. Apple의 예에서 보듯 오늘날의 애플리케이션은 최종 사용자(End-user) 가 직접 수정하거나 확장할 수 있도록 설계된다.

사용자는 직접 코드를 작성하지 않더라도, 객체 간의 관계를 시각적으로 조작함으로써 자신의 목적에 맞게 소프트웨어를 변형할 수 있다. 이것이 바로 사용자 맞춤형 객체지향 시스템의 시작이다.

"우리는 모든 제어 흐름을 객체가 주도하도록 만들려 했습니다. 그러나, 아이러니하게도 다음 단계는 객체가 아무것도 하지 않고 기다리는 것이었죠."

객체는 메시지를 ‘받기만’ 해도 될까?

객체지향에서 메시지는 일반적으로 “보낸다(send)” 고 표현한다. 하지만 앨런케이는 한 걸음 더 나아가 "메시지를 보내지 말고 받게 하자"는 개념을 소개합니다.

이게 어떤 의미인지 설명하고 있다.

기존 방식 - 명령형 메시지

호출자가 능동적으로 메시지를 보내고, 객체는 실행한다.
- 예) window.resize()

새로운 방식 - 선언적 의존성

객체는 "내가 이러이러한 정보가 주어지면 작동할 수 있다."는 '필요 조건'을 선언
시스템은 전체 객체들의 '필요 목록'을 분석해 누가 누구에게 어떤 메시지를 전달할지 결정

이 방식은 마치 스프레드시트(Excel) 와 유사하다고 한다. 셀은 "나는 B1과 C1의 합이야!"라고만 선언하고 B1이나 C1이 바뀌면 자동으로 계산된다.

엘런케이는 이 아이디어를 바탕으로 Apple과 MIT에서 실제 언어 실험까지 진행했으며, 이를 "control-free object system" 으로 부른다.

구성 언어(Configuration Language): 객체를 묶는 청사진

객체가 수천 개 모이게 되면 보호(encapsulation)만으로는 복잡성을 제어할 수 없다. 이때 중요한 역할을 하는 것이 구성 언어(configuration language)이다.

구성 언어란?

객체 간 프로토콜(약속된 메시지 목록) 을 정의
각 객체의 기대 입력/출력, 동작 조건, 환경 조건까지 선언
실제 구현 언어와 독립적 (예: COBOL, PL/1, Smalltalk 등 어떤 것으로도 구현 가능)
재사용과 테스트, 모듈 교체를 손쉽게 함

"구성 언어는 객체를 서로 조립하는 설계도이며, 인간이 읽을 수 있어야 한다."
— 앨런케이

Arthur Andersen은 실제로 이러한 구성 언어를 개발하여 기존 PL/1 및 SQL 코드를 객체화된 컴포넌트로 묶어 유지보수를 혁신적으로 단순화시켰다고 한다.

시간(Time)과 객체 — ‘슬리피지(slippage)’란 무엇인가?

객체지향 시스템이 시뮬레이션이나 실시간 제어와 결합될 때, 시간(time)은 중요하다. 시간이 지남에 따라 객체의 상태는 고정되어 있는 것이 아니라 변경되기 때문이다.

문제

객체가 연산을 하는 도중 다른 객체가 그 상태를 읽으면, 불안정하거나 중간 상태를 보게 될 수 있다.

해결:

슬리피지 모델(Slippage Model):
- 객체의 상태가 계산 중일 때는 읽을 수 없다.
- 대신, 안정된 시점의 복사본을 제공한다.
객체와 뷰(view)가 서로 조율하여, 버퍼를 생성하고 읽기/쓰기 타이밍을 조정한다.

이 구조는 마치 하드웨어 캐시 동기화나 트랜잭션 일관성 모델과 유사하며, 객체 간 병렬처리나 비동기 메시징 환경에서 큰 안정성을 제공할 수 있다고 이야기 하고 있다.

왜 객체는 ‘작은 컴퓨터’여야 하는가?

앨런 케이는 프로그래밍 언어가 구조체와 절차로 시스템을 나누는 것에 대해 근본적인 의문을 던졌다.

전통적 언어의 방식

데이터를 구조(structure)로 묶고
프로시저로 데이터를 조작
즉, 컴퓨터의 본질적 능력을 곧바로 희생하는 방식

"데이터 구조는 기억을 가지지 못하고, 프로시저는 혼자 실행할 수 없다. 둘 다 '컴퓨터'가 아니다."

객체지향의 철학

프로그램을 나누는 유일한 방식은 '하나의 컴퓨터를 또 다른 컴퓨터로 분할하는 것'
각 객체는 내부에 상태와 로직을 갖춘 ‘작은 기계’이며,
외부에서는 해당 기계의 행동만 요청할 수 있음

즉, 진정한 객체지향이란 각 객체가 독립적인 판단과 보호 능력을 가진 단위가 되는 것이다.

"객체는 데이터 구조가 아니다."

오늘날 대부분의 언어들 — 특히 C++, Objective-C, Java 등 — 은 객체지향을 '데이터에 메서드를 붙이는 방식'으로 구현했다. 케이는 이 방식이 객체지향의 철학을 거의 왜곡했다고 비판하고 있다.

데이터 구조의 한계

외부에서 필드를 직접 읽거나 수정할 수 있음
내부 구조가 바뀌면 연관된 코드 전체가 무너짐

진정한 객체

내부 상태는 은닉
외부 요청은 "~해주면 좋겠다"는 소망형 메시지
응답 여부와 방식은 객체가 결정

"객체에게 메시지를 보낸다는 것은 '명령'이 아니라 '의뢰'입니다."

이 철학은 단지 기술적인 구현이 아니라 보안, 설계의 유연성, 유지 보수성까지 영향을 미친다고 이야기하고 있다.

객체지향 설계의 두 축: 보호와 디자인

앨런케이는 객체지향의 목적을 이렇게 나눈다.

보호 (90%)	객체의 내부 상태, 제어 흐름, 권한을 보호
디자인 유도 (10%)	시스템 구조 설계에 도움을 주는 개념적 도구

즉, 객체지향은 단지 '더 나은 설계'를 위한 도구가 아니라, 컴퓨터가 컴퓨터다움을 유지할 수 있는 필수 조건이라고 한다.

객체지향과 아이들: 진짜 프로그래밍은 누구를 위한 것인가?

앨런케이가 말하는 객체지향의 또 다른 기원은 바로 아이들과의 교육 실험이었다고 한다. 그는 컴퓨터 프로그래밍을 어린이 교육 도구로 삼으면서 이런 아이디어를 발견했다고 한다.

중요한 사실

9세 이하의 아이들은 제어 흐름(control flow) 을 따라가기 어려워함
반면, 상태-행동 모델에는 훨씬 잘 반응

그래서 그는 다음과 같은 접근을 시도했다.

객체는 행동할 조건만 선언하고, 메시지는 시스템이 결정
제어 흐름이 아니라 의도(intent) 중심의 프로그래밍

이 실험은 이후 Apple, MIT 등에서의 교육 도구 설계로 이어졌고, 결국 HyperCard, Etoys 같은 사용자 중심 객체지향 환경의 탄생으로 연결된다.

스케치패드(Sketchpad): 1962년에 등장한 진짜 객체지향 시스템

객체지향의 초기 실현 중 하나는 아이반 서덜랜드(Ivan Sutherland) 가 만든 Sketchpad라는 시스템이다. 1962년에 만들어졌으며 세계 최초의 그래픽 사용자 인터페이스(GUI), 제약 기반 프로그래밍, 객체 개념이 모두 담긴 혁명적인 소프트웨어였다.

Sketchpad의 특징

사용자가 마우스처럼 생긴 라이트펜으로 도형을 그릴 수 있음
객체 간의 관계와 제약(constraints) 을 선언적으로 정의
각 도형은 ‘마스터(master)’와 ‘인스턴스(instance)’ 관계를 가짐 → 오늘날의 클래스-객체 관계
도형끼리의 비례, 수직, 평행 관계 등을 자동으로 유지

“서덜랜드는 객체마다 고유의 그리기 함수를 갖도록 설계했고, 메시지 draw만 보내면 각 객체가 스스로 적절한 동작을 하도록 했다."
— 앨런 케이

이 구조는 오늘날의 OOP에서 말하는 동적 디스패치(dynamic dispatch), 다형성(polymorphism) 과 거의 완벽하게 일치합니다.

스몰토크(Smalltalk): 객체지향 언어의 진짜 출발점

1970년대 초, Xerox PARC에서 앨런 케이와 동료들이 개발한 Smalltalk는 현대 객체지향 언어의 원형이자 철학적 구현체이다.

Smalltalk의 철학

모든 것은 객체이다. 숫자, 문자열, 함수, 클래스조차도.
객체는 오직 메시지를 통해서만 상호작용한다.
외부에서 객체의 내부를 들여다보거나 바꿀 수 없다.
시스템 전체가 Smalltalk로 작성되었기 때문에 자기 자신을 수정하고 확장할 수 있음.

케이는 이를 통해 자신이 생각한 객체지향 개념을 ‘철학’이 아닌 ‘살아있는 환경’으로 구현했다.

“Smalltalk는 프로그래밍 언어가 아니라, 살아있는 생태계였습니다.”

하이퍼카드(HyperCard): 사용자도 객체를 다룰 수 있어야 한다.

1980년대 말, Apple에서 만들어진 HyperCard는 프로그래밍을 전혀 모르는 사용자도 객체지향적 사고로 작업할 수 있게 해준 도구였다.

HyperCard의 특징

카드(화면 단위)와 버튼, 필드 등의 구성 요소가 전부 객체
간단한 스크립트로 객체 간 동작 정의 가능
사용자 스스로 버튼을 만들고, 동작을 부여하며, 프로그램을 확장할 수 있음

“HyperCard는 사용자에게 객체 중심 설계를 경험하게 해준 최초의 대중적 환경이었다.”

HyperCard는 당시 사용자 프로그래밍(End-user Programming)을 현실화하며, 오늘날의 노코드/로우코드 도구의 선구자 역할을 했다.

객체지향의 다음 목표는 '조립 가능성'이다.

객체지향 프로그래밍이 초기에 사람들을 매료시킨 이유는 단순히 코드를 줄이거나 안정성을 높이기 때문만은 아니다고 한다. 진짜 매력은 시스템을 부품(component) 단위로 조립할 수 있게 해준다는 점 때문이라고 한다.

앨런 케이는 이것을 “Tinkertoy 모델” 로 설명합니다.

Tinkertoy: 미국의 전통적인 어린이 조립 장난감. 간단한 부품들을 다양한 방식으로 연결해 구조물을 만들 수 있습니다.

객체지향 시스템도 그렇게 작고 재사용 가능한 객체 들로 구성되어야 하며, 개발자뿐만 아니라 비개발자도 부품을 이어붙일 수 있어야 한다는 것이 그의 주장이다.

구성 가능한 부품(component)의 조건

그렇다면 Tinkertoy처럼 객체를 조립하려면 어떤 조건이 필요할까?

캡슐화 (Encapsulation)
- 부품의 내부가 외부에 노출되지 않아야 함
- 보호되지 않은 객체는 다른 시스템과 쉽게 충돌
프로토콜(Protocol)의 명세화
- 객체 간 상호작용은 명확한 메시지 약속으로 이루어져야 함
- 메시지 이름, 형식, 응답에 대한 예측 가능성이 있어야 함
재사용 가능성 (Reusability)
- 같은 객체를 여러 문맥(context)에서 사용할 수 있어야 함
- 의존성과 외부 환경 요소가 최소화되어야 함
독립적인 동작 가능성
- 객체는 독자적으로 작동할 수 있어야 하며,
- 삽입 위치에 따라 달라지지 않아야 함

객체의 진화: 셀에서 조직으로

케이는 객체를 단순한 부품이 아니라, 생명체처럼 성장하고 결합하는 단위로 보고 있다.

셀: 독립적으로 동작하는 기본 객체
조직: 셀들이 유기적으로 협력하며 만들어낸 기능 블록
시스템: 조직 단위들이 연결되어 복합적인 기능을 수행

"초보자는 셀(cell)을 만들 수 있다. 진짜 도전은, 셀을 넘어서 조직(tissue) 을 디자인하는 것입니다."

이 발상은 최근의 마이크로서비스 아키텍처, 도메인 주도 설계(DDD), 컴포넌트 기반 프론트엔드 설계(React, Vue) 같은 현대적 소프트웨어 디자인 패턴들과도 깊은 연관이 있다.

사용자가 참여할 수 있는 프로그래밍

앨런 케이는 객체지향의 미래가 전문가 중심에서 사용자 중심으로 옮겨가야 한다고 말한다.

소프트웨어는 사용자가 직접 이해하고 수정할 수 있는 구조여야 한다.
프로그래머만이 아닌, 일반 사용자가 구성 가능한 구조가 되어야 한다.
이는 단지 UI 커스터마이징 수준이 아니라, 행동 수준의 커스터마이징을 의미합니다.

HyperCard, Etoys, Scratch 등이 이를 실현해온 사례이다.

앞으로는 더욱 강력한 사용자 중심 객체 환경이 필요하다는 것이 케이의 주장이다.

기술을 넘어, 철학이 된 객체지향

객체지향(Object-Oriented Programming, OOP)은 C++, Java, Python 등에서 '객체를 사용하는 방식'으로 많이 소개된다. 그러나 앨런 케이는 OOP를 그저 하나의 언어나 문법이 아니라 "사고방식의 전환" 이라고 말한다.

그가 강조한 OOP의 철학은 다음과 같은 질문에서 출발한다.

복잡한 시스템은 어떻게 안전하게 성장할 수 있을까?
각 요소는 어떻게 독립성과 책임을 가지면서 협력할 수 있을까?
사용자도 참여 가능한 시스템을 만들 수 있을까?

이러한 질문은 기술 언어로는 표현하기 어렵지만, 시스템을 바라보는 철학적 관점의 전환 없이는 답을 찾기 어렵다.

OOP의 오용과 왜곡 — 왜 객체지향이 ‘가짜’가 되었는가?

오늘날 ‘객체지향’이라는 이름 아래 이루어지는 대부분의 프로그래밍은 앨런 케이의 철학과 거의 반대에 가깝다.

왜곡된 형태앨런 케이의 철학

데이터를 구조체처럼 묶고 메서드를 붙임	객체는 작은 컴퓨터이며, 내부를 보호해야 함
메시지는 실제로는 함수 호출	메시지는 의도(intent) 이며, 객체는 거절할 수 있음
모든 것을 편하게 접근하기 위한 캡슐화	객체는 위험으로부터 자기 자신을 보호해야 함
객체를 상태 보관소로 사용	객체는 능동적이고 자율적인 존재여야 함

"객체지향의 핵심은 '데이터 구조를 더 잘 만드는 방법'이 아니다. 그건 옛 방식의 연장선일 뿐입니다."
— 앨런 케이

앨런 케이가 던진 진짜 질문들...

1. 복잡성은 어떻게 통제할 수 있는가?

→ 생물학적 시스템처럼, 복잡한 구조는 독립적이고 캡슐화된 단위의 협업으로 이뤄져야 함.

2. 제어권은 누구에게 있는가?

→ 객체에게 권한을 주자. 메시지를 명령이 아니라 ‘소망’으로 바꾸자.

3. 좋은 프로그래밍 언어란 무엇인가?

→ 사람이 사고하는 방식에 가깝고, 시스템의 구조를 자연스럽게 표현할 수 있어야 한다.

4. 사용자는 언제 프로그래머가 될 수 있는가?

→ 시스템이 충분히 명확하고 조립 가능한 구조일 때, 누구나 프로그래밍할 수 있다.

5. 객체지향은 왜 25년씩 걸리는가?

→ 패러다임의 전환은 단지 도구가 아니라, 사람의 사고방식이 바뀌어야 가능한 변화이기 때문이다.

마무리: 객체지향은 ‘사람’에 대한 철학이다.

앨런 케이가 강조하는 객체지향의 본질은 단지 시스템을 잘 만드는 기술이 아니라, 사람이 이해하고, 유지하며, 함께 발전시킬 수 있는 시스템을 만드는 철학이라는 점을 강조하고 있다.

그가 남긴 마지막 메시지는 다음과 같다.

“아이들을 위해 만든 시스템은 어른들을 위한 시스템보다 낫다. 왜냐하면 어른들은 고통에 익숙해져 있지만, 아이들은 진실만 받아들이기 때문입니다.”