객체지향의 본질은 메시지, 앨런 케이가 말한 진짜 OOP
객체지향을 공부하면 늘 상속·캡슐화·다형성 세 단어부터 외우게 됩니다.
그런데 정작 “객체지향(OOP)“이라는 말을 만든 앨런 케이는 그 셋을 핵심으로 꼽지 않았습니다.
핵심부터 말씀드릴게요. 앨런 케이가 말한 진짜 OOP의 본질은 객체가 아니라 객체 사이에 오가는 메시지입니다. 클래스를 어떻게 나누느냐보다 객체들이 서로 무엇을 주고받느냐가 먼저라는 얘기죠.
이 글을 끝까지 읽으시면 왜 그가 “객체지향이라는 이름을 후회한다”고까지 말했는지, 그 관점이 우리 코드를 어떻게 바꾸는지 감이 잡히실 거예요.
앨런 케이는 왜 “OOP”라는 이름을 후회했을까?
앨런 케이는 1970년대 제록스 파크에서 Smalltalk를 만든 사람입니다. “객체지향 프로그래밍”이라는 용어 자체가 그의 입에서 나왔어요.
그런데 2003년, 한 개발자가 이메일로 “객체지향이 뭐냐”고 묻자 그는 이렇게 답했습니다.
“나는 ’객체’라는 단어를 쓴 걸 후회한다.
사람들의 관심을 덜 중요한 개념으로 몰아버렸기 때문이다. 진짜 큰 아이디어는 ’메시징’이다.“
처음 이 문장을 보면 좀 당황스럽죠. 우리가 배운 객체지향은 늘 “객체를 잘 설계하는 법”이었으니까요.
케이가 보기에 진짜 중요한 건 객체 내부가 아니었습니다. 객체들이 메시지를 주고받으며 이루는 관계와 상호작용, 그게 시스템의 본질이라는 거죠.
그는 프로그램을 생물학적 세포에 비유했습니다. 세포 하나하나는 자기 안을 꽁꽁 숨기고 오직 화학 신호(메시지)로만 소통하죠. 인터넷도 마찬가지예요. 수많은 컴퓨터가 각자 독립적으로 돌아가면서 메시지만 주고받습니다.
메시지 중심 사고는 뭐가 다를까?
“메서드를 호출한다”와 “메시지를 보낸다”는 비슷해 보이지만 관점이 다릅니다.
메서드 호출은 “이 객체의 이 함수를 실행해”에 가깝습니다. 보내는 쪽이 받는 쪽의 내부를 어느 정도 알고 있어야 하죠.
반면 메시지는 “이걸 처리해줘, 방법은 네가 알아서”에 가깝습니다. 보내는 쪽은 결과만 원할 뿐, 상대가 어떻게 처리하는지는 몰라도 됩니다.
아래 예시를 보실게요. 할인 계산을 각 회원 등급 객체에게 “메시지”로 위임하는 코드입니다.
protocol Member {
func discountedPrice(for price: Int) -> Int
}
struct Gold: Member {
func discountedPrice(for price: Int) -> Int { price * 80 / 100 }
}
struct Silver: Member {
func discountedPrice(for price: Int) -> Int { price * 90 / 100 }
}
// 보내는 쪽은 등급별 계산법을 전혀 모릅니다.
let members: [Member] = [Gold(), Silver()]
for m in members {
print(m.discountedPrice(for: 10000))
}
// 출력: 8000
// 출력: 9000호출하는 쪽 코드에는 if문도, 등급 이름도 없습니다.
“할인가 계산해줘”라는 메시지만 보낼 뿐, 실제 계산은 각 객체가 책임집니다. 새 등급이 생겨도 호출부는 손대지 않아도 되죠.
이게 케이가 말한 메시징의 힘입니다. 객체를 잘게 쪼개는 게 목적이 아니라 결합을 느슨하게 만드는 소통 방식이 핵심이에요.
그럼 캡슐화·다형성은 필요 없나요?
아닙니다. 오히려 반대예요.
메시징을 진지하게 받아들이면 캡슐화와 다형성은 저절로 따라옵니다.
객체가 메시지로만 소통하려면 내부 상태는 숨겨야 합니다. 그게 캡슐화죠. 같은 메시지에 객체마다 다르게 반응하는 것, 그게 다형성이고요.
이 개념들은 외워야 할 규칙이 아니라 메시지 중심으로 설계하면 자연스럽게 나오는 결과입니다.
문제는 순서예요. 많은 분들이 “클래스부터 잘 나누자”로 시작합니다. 그러면 객체는 잔뜩 생기는데 서로 내부를 훤히 들여다보는, 이름만 객체지향인 코드가 나오기 쉽습니다.
케이의 관점은 순서를 뒤집습니다. “이 객체는 어떤 메시지에 응답해야 하지?“를 먼저 묻는 거죠.
언제 이 관점을 쓰고, 언제 힘을 빼야 할까?
메시지 중심 설계가 늘 정답은 아닙니다. 상황에 맞게 쓰는 게 중요해요.
| 상황 | 판단 |
|---|---|
| 요구사항이 자주 바뀌는 도메인 로직 | 메시지 중심으로 위임 구조를 짜면 유리 |
| 협력하는 객체가 많은 복잡한 흐름 | 결합도를 낮추는 데 큰 효과 |
| 단순한 데이터 변환·계산 스크립트 | 굳이 객체로 감싸지 말고 함수로 |
| 성능이 극도로 중요한 구간 | 과한 추상화는 오히려 부담 |
정리하면 이렇습니다.
- 협력과 변경이 많은 곳일수록 메시지 관점이 빛납니다.
- 단순하고 고정된 로직은 힘을 빼는 게 낫습니다.
- “객체를 나누는 것”이 아니라 “소통을 설계하는 것”이 목적임을 기억하세요.
면접에서는 이렇게 물어봅니다
Q. 앨런 케이가 말한 객체지향의 본질은 무엇인가요?
객체 자체가 아니라 객체 사이에 오가는 메시지입니다. 케이는 객체를 독립적으로 소통하는 세포에 비유했고 상속·캡슐화보다 메시징을 더 큰 아이디어로 봤습니다.
Q. 메시지 중심 설계가 실무에서 어떤 이점을 주나요?
호출하는 쪽이 상대의 내부 구현을 몰라도 되므로 결합도가 낮아집니다. 그 결과 새 타입이 추가돼도 호출부를 고치지 않아 변경에 강한 구조가 됩니다.
객체지향이 어렵게 느껴졌다면, 클래스 다이어그램을 그리기 전에 “이 객체들은 서로 무슨 말을 주고받지?“를 먼저 떠올려 보세요.
관점 하나 바꿨을 뿐인데 코드가 한결 단단해지는 걸 느끼실 거예요. 오늘도 좋은 설계 하시길 응원합니다!