처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
Hacker News 2026.07.01 36

객체지향이 '클래스'라고요? — 그 단어를 만든 앨런 케이의 반전 고백

Hacker News 원문 보기

도입: 정작 만든 사람이 후회한다고요

"객체지향 프로그래밍(OOP)"이라는 말, 개발 배우면서 수없이 들어보셨을 거예요. 보통 우리는 OOP를 "클래스를 만들고, 상속하고, 캡슐화하는 것"이라고 배우죠. 그런데 정작 이 "객체지향"이라는 단어를 처음 만든 사람인 앨런 케이(Alan Kay)는 2003년에 이런 취지의 말을 남겼어요. "내가 옛날에 '객체'라는 말을 만든 걸 후회한다. 그 단어 때문에 사람들이 정작 더 중요한 개념을 놓치고, 덜 중요한 것(객체 그 자체)에만 집중하게 됐으니까."

충격적이죠? 단어를 만든 사람이 "너희가 이해하는 건 내가 말한 게 아니다"라고 한 거예요. 그럼 케이가 진짜로 말하고 싶었던 객체지향은 뭐였을까요?

핵심: 진짜 알맹이는 '메시징'이었다

케이는 객체지향의 본질을 세 가지로 정리했어요.

첫째, 메시징(messaging). 둘째, 상태의 지역적 보존·보호·은닉(각 객체가 자기 데이터를 스스로 감추고 지키는 것). 셋째, 극단적인 늦은 바인딩(extreme late-binding). 이 중에서도 케이가 가장 중요하다고 강조한 건 첫 번째, 메시징이에요.

메시징이 뭐냐면요. 우리는 보통 객체지향을 "객체 A가 객체 B의 메서드를 호출한다"고 이해하잖아요. 그런데 케이의 관점은 미묘하게 달라요. "객체 A가 객체 B에게 메시지를 보낸다"는 거예요. 핵심 차이는 이거예요. 메시지를 받은 B가 그 메시지를 어떻게 처리할지는 전적으로 B가 알아서 결정한다는 점이죠. 보내는 쪽은 "이걸 좀 해줘"라고 부탁만 할 뿐, B 내부가 어떻게 생겼는지, 어떤 방식으로 처리하는지 전혀 몰라도 돼요.

케이가 든 비유가 인상적이에요. 그는 객체를 생물의 세포인터넷에 연결된 컴퓨터에 비유했어요. 우리 몸의 세포 수십조 개는 서로의 내부를 직접 헤집지 않아요. 화학 신호(메시지)를 주고받으며 협력하죠. 인터넷의 컴퓨터들도 마찬가지예요. 상대 컴퓨터의 메모리를 직접 만지는 게 아니라, 메시지(패킷)를 주고받으며 통신하잖아요. 케이가 꿈꾼 객체지향은 바로 이런 거였어요. 수많은 독립된 작은 컴퓨터들이 메시지로만 소통하는 시스템.

'늦은 바인딩'은 또 뭐냐면요

세 번째로 강조한 "극단적인 늦은 바인딩"도 풀어볼게요. 바인딩이란 "이 호출이 실제로 어떤 코드로 실행될지 결정하는 시점"을 말해요. 늦은 바인딩은 그 결정을 최대한 미뤄서, 프로그램이 실제로 돌아가는 순간에 정한다는 뜻이에요.

왜 이게 중요할까요? 결정을 늦출수록 시스템이 유연해지거든요. 프로그램을 멈추지 않고도 부품을 갈아 끼우거나 새 기능을 붙일 수 있어요. 마치 인터넷이 켜진 채로 새 서버가 계속 추가되는 것처럼요. 케이는 "거대한 시스템을 멈추지 않고 계속 자라게 하려면, 모든 걸 미리 단단히 고정하면 안 된다"고 봤어요. 그래서 캡슐화(상태 은닉)도 중요했던 거예요. 각 객체가 자기 속을 꽁꽁 숨겨야, 바깥을 건드리지 않고 그 객체만 바꿔 끼울 수 있으니까요.

업계 맥락: 우리가 배운 OOP는 어디서 왔나

재밌는 건, 오늘날 대부분의 개발자가 떠올리는 OOP는 케이가 만든 Smalltalk보다 C++이나 Java가 퍼뜨린 버전에 가깝다는 거예요. 이쪽은 클래스, 상속, 타입 시스템 같은 "구조"를 강조하죠. 반면 케이가 말한 "메시징과 늦은 바인딩" 정신은 오히려 Erlang의 액터 모델, 마이크로서비스 아키텍처, 심지어 REST API 같은 곳에서 더 또렷하게 살아 있어요.

생각해보면 마이크로서비스가 딱 케이의 비전이에요. 각 서비스가 자기 데이터를 감추고(상태 은닉), 서로 HTTP 메시지로만 소통하고(메시징), 한 서비스를 멈추지 않고 다른 걸 교체할 수 있죠(늦은 바인딩). 그러니까 우리는 "클래스 OOP"는 코드 안에서, "메시징 OOP"는 시스템 아키텍처에서 각각 따로 쓰고 있는 셈이에요.

한국 개발자에게 주는 시사점

이 이야기가 주는 교훈은 분명해요. 객체지향을 '클래스 문법'으로만 이해하면 절반만 본 거예요. 진짜 알맹이는 "독립된 부품들이 서로의 내부를 모른 채, 메시지로만 협력하게 만드는 설계 사고"거든요.

실무에 적용하면 이렇게 돼요. 클래스를 짤 때 "이 객체가 자기 상태를 충분히 잘 숨기고 있나? 바깥에서 내부를 직접 만지게 열어두진 않았나?"를 늘 자문해보세요. 객체 간 결합을 느슨하게(loose coupling) 유지하라는 흔한 조언이, 사실은 케이의 메시징 철학과 정확히 같은 말이에요. 그리고 마이크로서비스나 이벤트 기반 아키텍처를 설계할 때도, "우리는 지금 거대한 객체지향 시스템을 만들고 있구나"라고 생각하면 설계 결정이 한결 명료해져요.

마무리

핵심 한 줄은 이거예요. "객체지향의 본질은 클래스가 아니라 메시징이다." 단어를 만든 사람이 직접 한 말이니, 한 번쯤 곱씹어볼 가치가 충분하죠.

여러분은 객체지향이라고 하면 가장 먼저 무엇이 떠오르시나요? 클래스와 상속인가요, 아니면 메시지를 주고받는 독립된 객체들인가요? 케이의 관점으로 보면 우리가 쓰는 코드가 좀 달라 보이지 않나요?


🔗 출처: Hacker News

이 뉴스가 유용했나요?

TTJ 코딩클래스 정규반

월급 외 수입,
코딩으로 만들 수 있습니다

17가지 수익 모델을 직접 실습하고, 1,300만원 상당의 자동화 도구와 소스코드를 받아가세요.

144+실전 강의
17개수익 모델
4.9수강생 평점
정규반 자세히 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.