이걸 뭐하러 설명하는가?
객체란 무엇이며 객체는 또 무엇을 말하는 걸까? 객체라는 단어의 어원이 궁금 했었다. "참 할 일도 없다"라 생각이 들겠지만 한 번 생긴 물음에는 마침표를 찍어야 하지 않겠는가?
일상회화에서도 용례를 찾기가 쉽지 않다. 개체처럼 비슷한건 있어도 객체라는 단어는 흔히 쓰이지는 않는다. 혹시 또 누군가가 이 함정에 빠져 기나긴 시간 고통받질 않기를 바라는 마음으로 이 부족한 생각을 최대한 정리해보도록 하겠다.
국내 현실
아무나 붙잡고 "객체란 것이 도대체 무엇입니까?" 하고 물어본다면 대부분은 말문이 막힐 확률이 꽤 높다. IT 산업 종사자의 직함으로 대화한다면 아니, 이걸 몰라요? 라는 아니시에이팅을 받아볼 수 있을 확률이 더 높아지는데 사실 조금만 파고 들어가면 마찬가지로 말문이 막히게된다. 실제로는 아는 사람이 별로 없고 기능적 경험만 해보았고 이해하지는 못했기 때문이다.
깊게 파고들면 머리 아프지만 현존하는 모든 것들은 객체라고 말할 수 있다. 프로그래밍의 객체 자료형, 객체, Object 객체, 인터페이스, 클래스, 인스턴스도 마찬가지다. 사실 이 단어 자체가 추상적인 단어이기 때문에 귀에 걸면 귀걸이 코에 걸면 코걸이가 되는 단어이다. 이 문서에서는 이 단어를 예시를 들어 정의하고 프로그래밍에서 정확하게 사용할 수 있는 방법을 제안한다.
업계에서는 객체라고 자주 언급되는 대상으로 클래스와 인스턴스 두가지가 대표적이고 일반 객체 정도를 앞을 생략해 그냥 객체라고 지칭한다.
- 저번에 만든 객체를 상속받아 구현해라.
- 객체로 반환하니까 forEach 쓰면 오류 난다.
- DB객체로 조회하세요.
예문을 들자면 이런식이다. 클래스인지 인스턴스인지 자료형인지 문맥에 따라 해석해야 하는게 불편하다. 애초에 객체라는 단어 자체가 어떤 개념을 하나 특정하는 단어가 아니다보니 자연스럽게 혼용되어 의사소통에 혼란을 빚는 경우가 많다. 근데 한국사람들은 똑똑해서 그런지 대강 잘 알아듣는다. 인스턴스를 상속한다는 말 자체가 어불성설이라1 클래스를 잘 찾아서 상속하고 작업하는 등 문맥상 생략된 의미를 자연스럽게 파악하기는 한다.
내 생각에 과거 국내에 들어온 번역서들과 구글 번역기 돌리기 바쁘고 퍼나르기 바쁜 블로그들의 콜라보라고 생각한다. 한자화, 명사화, 한글화, 어려운 말 만들기, 기타 등등으로 내가 한국인인데 한국어를 못 읽는 책들도 정말 많았다.
이런 현상은 비단 프로그래밍 분야만의 문제가 아니라 대한민국 판떼기 전체가 그런 느낌이다. 이걸 잘못됐다고 비난할 생각은 없다. 적어도 돈이 목적이라 한들 국내에 소개시켜주려는 아가페적 사랑을많든 적든 담았지 않았겠는가? 더 하면 정말 잡소리가 되어버리니 그만하고 다시 본론으로 돌아가자.
Object (객체)
어원에 대해서는 너무 길어서 줄이자면 만질 수 있는 대상을 말한다. 특징은 실존하고 물질적이라는 것이다. 마땅한 단어가 없었는지 한자어로 손 객자에 몸 체를 쓰는 한자어로 알려졌다. 객관적으로 관찰측정이 가능한 물체라고 생각하면 된다.
손 객자가 손님을 뜻하니 반대말은 주인 주자를 써서 주체가 된다. "주체적으로 좀 살아라" 할 때의 그 주체 맞다. 단어를 이렇게 풀어놓고 보면 자연스럽게 한 가지가 떠오를 것이다.
클래스와 인스턴스
설계도와 설계도로 만든 구현체라는 이 비유는 두 관계를 아주 잘 표현한 직관적인 비유이다. 너무 잘 만든 표현이라 국내 블로그 아무거나 들어가보면 쉽게 찾아볼 수 있는 표현이다. 단순히 프로그래밍을 위해서라면 여기까지만 이해해도 전혀 문제 없지만 우리는 여기서 더 들어가보자.
위 비유에서 "설계도"라는 단어는 이해를 돕기 위해 사용되었는데 여기서 자꾸 서류같은 물질적 대상이 떠오르게 하는 "도"를 빼고 이야기 해야 더 깊게 이해할 수 있다. 설계란 실존하지 않는 추상화된 개념적 정리이다. 자동차 설계와 이 설계를 기반으로 제작한 자동차로 구분해서 생각해보면 더 명확하게 이해할 수 있을 것이다. 여기서 주체는 설계이고 객체는 자동차가 된다.
"후문은 직경 3cm의 볼트로 채결한다" 라는 것은 문서 형태의 물질적 대상이 없다고 해서 없어지는 것이 아니다. 출근 계획도 출근 설계라고 바꿔 부를 수 있지 않은가? 설계라는 것은 실존하지 않는 추상적 개념이다.
이어서 생각해보자. 이 자동차 설계를 토대로 자동차를 만든다고 생각해보자. 후문을 채결할 때 직경 3.00000153cm의 볼트로 채결하여 오차가 생겼다 하더라도 우린 변함없이 자동차라고 부를 수 있다.
"자동차 설계로 만든 자동차를 달리 뭐라 부르겠는가?" 너무도 당연한 말이지만 조금 더 엄격하게 생각해보자. 만약 문이 하나 없다면? 전부 없다면? 전후방 유리창이 없다면? 핸들이 없다면? 뭐가 얼마나 없으면 자동차라고 부를 수 없겠는가?
우린 설계와 100% 일치하지 않지만 어느정도 구색을 갖췄으면 그렇다고 인정한다. 이것은 재미있게도 우리가 평소에 아주 자연스럽게 추상화를 이해하고 사용하고 있다는 이야기이다. 이 점을 꼭 기억하고 문서를 읽으면 이해해 더 도움이 될거라 생각한다.
인스턴스
Instance는 사례라고 직역할 수 있다. 클래스를 통해 만든 사례... 틀린말은 아니지만 기능적인 명사로는 느낌이 부자연스럽다. 그렇다고 이런 일련의 이야기들을 설명하자니 너무 구구절절하다. 그래서인지 인스턴스라는 단어를 객체라고 퉁쳤는지도 모르겠다.
설계를 토대로 만들어진 하나의 구현체하나의 사례 위 예시에서는 만들어진 자동차를 인스턴스라고 생각하면 된다.
feat. 이데아론
뭔 프로그래밍 개념 설명하는데 이데아론이냐 라고 한다면 할 말은 없다만 "객체"라고 하는 단어를 표현하기에 이것보다 알맞는 비유를 보지 못했다.
한 때 유튜브를 보다가 연관으로 나온 도올 선생님의 강의중에 이 이데아론을 정말 쉽게 설명한 예가 있었고 프로그래밍과 너무도 유사한 개념이길래 기억에 많이 남았다. 링크를 달고 싶었는데 영상은 다시 찾을 수가 없었고 가능한한 기억을 더듬어 전달해 보도록 하겠다.
빛 ──> 완벽한 세계 ──> 그림자 │ 벽
- 완벽한 세계이데아: 이상적인 세계 또는 기하학적 세계라고 하는데 여기서는 모든 것이 완벽한이상적인 모습으로 있다.
- 빛: 빛은 이 완벽한 세계에 있는 어떤 존재를 비추는 것으로 그 뒤에 그림자를 만든다.
- 현실 세계: 현실세계는 이 그림자가 생긴 벽이다.
이해를 위해 필요한건 이 세가지다. 우리가 보고 있는 현실세계가 사실 이 완벽한 세계의 존재설계가 빛에 투영되어 만들어진 그림자구현체라는 것이다. 완벽한 개는 오직 이데아의 세상에 하나인데 투영된 그림자 중에 어떤놈은 앞집 뽀삐가 되는 것이고 어떤 그림자는 옆집 바둑이가 되는 것이다.2
당신은 개라는 것을 본적이 있습니까? 보통은 옆집 말티즈 럭키나 우리집 치와와 뽀삐를 생각하며 있다고 답하겠지만 이데아적 물음을 하기 시작하면 참 골치 아픈 물음이 된다. 당신은 우리가 "개"라고 할 때 칭하는 "개" 그 자체를 본적이 있습니까? 질문부터 머리가 띵해진다. 보통같으면 뭔 미친놈인가 하고 화를 내든 도망을 치든 하겠지만 우린 이제 이 문장이 무엇을 말하려는지 이해할 수 있다. 당신은 이데아 세상의 개를 본적이 있습니까? 우리는 이것이 농담이라 생각해서 웃든지 아니면 "본적이 있을리 없잖아요" 라며 답할 수 있게 되었다.
이런 이데아적인 사상의 끝판왕은 바로 수학이라고 할 수 있겠다. 우리 모두 1이란걸 알고는 있지만 실제로 본적이 없다. 1이라는 개념을 활용할 뿐이지 우리가 "1" 이라고 지칭하는 완벽한 "1" 그 자체를 현실세계에서 본적이 있을리가 없지 않겠는가?
조금만 더 나아가 생각해보면 원이라는 것도 관념적인 것으로 완벽한 원을 우리는 볼 수 없다. 모니터에 아름다운 수식으로 이쁘게 그려진 원도 까고 보면 LED를 이루는 소재가 몇 피코미터 정도는 분자의 결합이라든지 순서라든지 어그러진 부분이 있지 않겠는가? 그래서인지 과거에는 이런 이상적인 세상을 완벽한 자와 완벽한 컴파스만으로 모든 것을 표현할 수 있는 기하학적인 세상이라고 말했다고도 한다.
이름
여기서 우리는 호모 사피언스가 겪어온 놀라운 진화중에 하나인 사물에 이름 붙이기를 정말 아무런 힘도 들이지 않고 이해하고 있음을 알 수 있다. 단순히 뽀삐, 럭키를 말하는게 아니라 개, 소, 닭, 말, 사람, 숟가락 이런 것들 말이다. 객체들의 공통된 특징을 알아내 추상화 한 것이다.
야!!! 개 짓는 소리 좀 안나게 하라!!!
이렇게 다시보면 객체화, 다형성, 런타임 함수 변경 요청등이 녹아있는 이 얼마나 아름다운 문장인가? 우리는 인터페이스, 클래스, 인스턴스를 활용한 추상화와 다형성에 대한 개념을 일상생활에서 너무도 자연스럽게 사용하고 있다. 당연한걸 이해하려고 하다보니 힘들었던 걸까?
프로그래밍과 연결해서 생각해보기
class PerfectDog {
constructor() {}
happy() {
return "bow!";
}
}
const dog = new PerfectDog();
console.log(dog.happy());
이데아 세상에만 있는 완벽한 개는 오직 완벽한 형태 하나만 존재class Dog 하며 현실세계런타임에서 존재실행하지 않는다. 그러나 우리가 빛new을 통하여 그림자를 투영하면const dog = new Dog() 비로소 현실세계에서 볼 수 있는dog.happy() 것이다.
결론
설계와 구현체, 주체와 객체, 클래스와 인스턴스 이렇게 풀어 놓고 보면 두 단어의 관계가 명확해진다. 그러나 너무 오랜기간 혼용 되어서, 객체라는 단어를 이해하지 못한 사람들이 남발하여, 그리고 솔직히 말하자면 익숙해서 인지는 몰라도 말로 할 때 객체라고 뱉어버리면 자연스럽고 편하기는 하다.
- 저번에 만든 클래스를 상속받아 구현해라.
- 객체로 반환하니까 forEach 쓰면 오류 난다.
- DB 커넥션으로 조회하세요.
북한도 아니고 굳이 한자어를 고집할 필요도 없지만 그렇다고 익숙한 단어를 굳이 바꿔 표현하자니 어색하다. 클래스 정도는 명확하게 구분해주는 것이 의사전달의 명확성을 위해서 더 좋다고 생각한다.3
const obj = { value: 1 };
console.info(typeof obj); // object
console.info(obj.constructor); // [Function: Object]
console.info(obj.__proto__); // [Object: null prototype] {}
이런 현상은 자바스크립트의 일명 일반 객체Plain Object를 만나게 되면 한 층 더 골치가 아파지는데 분명 객체가 맞고 부르기도 object라고 부른다. typeof, constructor, __proto__ 모두 확인해보아도 Object라고 나오지만 우리가 흔히 사용하는 클래스와 인스턴스의 개념이 아닌 것처럼 보인다.
const arr = []; // new Array();
const obj = {}; // new Object();
이것은 편의상 데이터로 다루듯이 문법이 축약된 영향인데 위 코드는 주석에 표시한 것처럼 인터프리터가 실행할 때에는 new Class() 로 변환되어 실행된다. 이렇게 풀어 놓고 보면 문자열이나 숫자처럼 리터럴 데이터를 지칭하는 특정 단어가 아닌 객체라고 부르는 것을 이해할 수 있고 선언한 arr, obj 변수들이 주소값으로 다루어지는 이유도 자연스럽게 이해할 수 있게 된다.
명확히 지칭하기 위해서 데이터 객체 또는 JSONObject, JSONArray 라고 문법적 특징까지 포함하여 부르는 경우 있다. 실무에서는 배열과 객체라고 부르는 것이 일반적이라 대화할 때 주의해야 한다.
마치며
애초에 객체라고 이름을 지은 사람이 이걸 다 고려해서 지었을 것 같진 않다. 사람 생각이 비슷해서 그런건지 아니면 극에 달하면 통해서 그런건지 철학과 컴퓨터가 이렇게 연결될 수 있다는 것이 참 흥미로웠다.4 객체지향 프로그래밍 언어를 다루는 사람이라면 객체가 무엇인지는 이해하고 있어야 하지 않을까?
프로그래밍 치고 좀 생뚱맞은 글이긴 했지만 이걸 처음 깨달았을 때 나름 재미가 있었기에 언제 한 번 글을 작성하고 싶다 생각했었다. 글을 작성하기로 하면서 자료조사를 할 때 비슷한 생각을 한 사람들도 상당히 많다는 걸 알게 되어 감회가 새롭기도 했다.