객체란 무엇인가?

컴퓨터/IT학습

lu

luasenvy (luasenvy)

객체

객체란 무엇이며 객체는 또 무엇을 말하는 걸까? '객체'라는 단어 자체의 정의가 궁금 했었다. 일상회화에서도 용례를 찾기가 쉽지 않은데 '개체'처럼 비슷한건 있어도 객체라는 단어가 흔히 쓰이는 경우는 좀 처럼 찾기 힘들었다. 혹시 또 누군가가 이 함정에 빠져 기나긴 시간 고통받질 않기를 바라는 마음으로 이 부족한 생각을 최대한 정리해보도록 하겠다.

국내 현실

아무나 붙잡고 '객체란 것이 도대체 무엇입니까?' 하고 물어본다면 대부분은 말문이 막힐 확률이 높다. 전산업계 관계자로서 대화를 한다면 '아니, 이걸 몰라요?'라는 아니시에이팅도 받아볼 수 있을 것이다. 그러나 침울해 할 필요가 없다. 사실 조금만 파고 들어가면 모두들 말문이 막히게 된다. 정말로 이해하고 아는 사람은 별로 없고 기능적 경험만 해봤을 뿐이기 때문이다.

깊게 파고들면 머리 아프지만 현존하는 모든 것들은 객체라고 말할 수 있다. 프로그래밍의 객체 자료형, 객체, Object 객체, 인터페이스, 클래스, 인스턴스도 마찬가지다. 사실 이 단어 자체가 추상적인 단어이기 때문에 귀에 걸면 귀걸이 코에 걸면 코걸이가 되는 단어이다. 이 문서에서는 이 단어를 예시를 들어 정의하고 프로그래밍에서 정확하게 사용할 수 있는 방법을 제안한다.

실무에서는 객체라고 자주 언급되는 대상으로 클래스와 인스턴스 두가지가 대표적이고 데이터로 사용하는 일반 객체~~나 JSON 객체 정도를 들 수 있다.

1. 저번에 만든 객체를 상속해라.
2. 객체로 반환하니까 forEach 쓰면 오류 난다.
3. DB 객체써서 조회하세요.

예문을 들자면 이런식이다. 클래스인지 인스턴스인지 자료형인지 문맥에 따라 해석해야 하는게 불편하다. 애초에 객체라는 단어 자체가 어떤 개념을 하나 특정하는 단어가 아니다보니 자연스럽게 혼용되어 의사소통에 혼란을 빚는 경우가 많다. 근데 한국사람들은 똑똑해서 그런지 대강 잘 알아듣는다. 인스턴스를 상속한다는 말 자체가 어불성설이라 그런지 클래스를 잘 찾아서 상속하고 작업하는 등 문맥상 생략된 의미를 자연스럽게 파악하기는 한다.

내 생각에 과거 국내에 들어온 번역서들과 구글 번역기 돌리기 바쁘고 퍼나르기 바쁜 블로그들의 콜라보라고 생각한다. 한자화, 명사화, 한글화, 어려운 말 만들기, 기타 등등으로 내가 한국인인데 한국어를 못 읽는 책들도 정말 많았다.

Object

Object는 라틴어 'obicio'가 어원으로 '앞에 던져진 것', '눈 앞에 있는 것' 정도로 해석할 수 있다. '만질 수 있는 대상' 또는 '측정 가능한 대상'으로 의미를 확장해서 이해할 수 있다. 물질적이고 실존하여 측정가능한 대상을 말한다. 그래서 한자 문화권에서는 '손으로 만질 수 있는 물체'라는 뜻으로 손 객_(客)에 몸 체_(體)로 번역되어 '객체'라고 알려졌다.

한자가 골 때리는 것이 손 객_(客)이 손님을 뜻하니 이와 대칭되는 뜻이 주인 주_(主)자를 쓴 '주체'가 된다는 점이다. 측정 가능한 물체의 반대말이 주체라니 벌써부터 골머리가 아프다. 그래서 인스턴스에 대응할 객체라는 단어는 있어도 클래스를 대응할 단어는 없었는지 모르겠다.

추상화와 인스턴스

'설계도와 설계도로 만든 구현체'라는 이 비유는 두 관계를 아주 잘 표현한 비유이다. 너무 잘 만든 표현이라 국내 블로그 아무거나 들어가보면 쉽게 찾아볼 수 있다. 단순히 프로그래밍을 위해서라면 여기까지만 이해해도 전혀 문제 없지만 우리는 여기서 더 들어가보자. 비유에서 설계'도'라는 단어 때문에 서류 같은 물질적 대상이 떠오르지만 이제 '도'를 빼고 한 번 생각해보자. 설계란 실존하지 않는 추상화된 개념적 정리이다.

추상화

'후문은 직경 3cm의 볼트로 채결한다' 라는 설계는 문서 형태의 설계도가 불타 없어진다고 해서 같이 사라지는 것이 아니다. 여행 계획도 여행 설계라고 바꿔 부를 수 있지 않은가? 여행 설계도가 불타 없어져도 우리는 머리속에 있는 설계대로 여행 할 수 있다. '실존하지 않는 추상화된 개념적 정리'이기 때문이다.

이어서 생각해보자. 이 자동차 설계를 토대로 자동차를 만든다고 생각해보자. 후문을 채결할 때 직경 3.00000153cm의 볼트로 채결하여 설계와의 오차가 생겼다. 그래도 우린 변함없이 자동차라고 부를 수 있다. '나 때에는 30cm 나무판자로 채결해도 잘만 끌고 다녔어' 같은 나이브한 유머를 하는게 아니다.

'자동차 설계로 만든 자동차를 달리 뭐라 부르겠는가?' 너무도 당연한 말이지만 조금 더 엄격하게 생각해보자. 만약 문이 하나 없다면? 문이 전부 없다면? 전후방 유리창이 없다면? 핸들이 없다면? 오차가 3.6m라면? 뭐가 얼마나 없으면 더 이상 자동차라고 부를 수 없겠는가? 만약 설계에서 일부를 제외하거나 오차가 큰 것이 자동차라고 부를 수 없다면 왜 0.00000153cm의 오차는 무시되는가? 곰곰이 생각해보면 복잡한 문제이다.

우린 설계와 100% 일치하지 않지만 어느정도 구색을 갖췄으면 그렇다고 인정할 수 있다. 이것은 재미있게도 우리가 평소에 아주 자연스럽게 '추상화'를 이해하고 삶에 적용하고 있다는 이야기이다. 단어나 설명들이 어려울 수 있지만 '핵심적인 공통점을 생각하고 정리하는 것'이 추상화의 전부이다. 이 점을 꼭 기억하고 읽으면 이해하는데 더 도움이 될거라 생각한다.

인스턴스

인스턴스_(instance)는 '사례'라고 직역할 수 있다. '설계를 통해 구현된 하나의 사례'라고 번역하면 정확하지만 기능적인 명사로의 느낌은 부자연스럽다. 구현체라고 부르기에도 뭔가 어색하고 그렇다고 이런 일련의 이야기들을 설명하자니 너무 구구절절하다. 그래서인지 인스턴스라는 단어를 객체라고 퉁쳤는지도 모르겠다.

feat. 이데아론

뭔 프로그래밍 개념 설명하는데 이데아론이냐 라고 한다면 할 말은 없다만 '객체'라고 하는 단어를 표현하기에 이것보다 알맞는 비유를 보지 못했다. 한 때 유튜브를 보다가 연관으로 나온 도올 선생님의 강의중에 이 이데아론을 정말 쉽게 설명한 예가 있었고 프로그래밍과 너무도 유사한 개념이길래 기억에 많이 남았다. 링크를 달고 싶은데 영상을 다시 찾을 수가 없어 가능한한 기억을 더듬어 전달해 보도록 하겠다.

빛 ──> 완벽한 세계 ──> 그림자 │ 벽

1. 완벽한 세계_(이데아): 이상적인 세계 또는 기하학적 세계라고 하는데 여기서는 모든 것이 완벽한_{(이상적인)} 모습으로 있다.
2. 빛: 빛은 이 완벽한 세계에 있는 어떤 존재를 비추는 것으로 그 뒤에 그림자를 만든다.
3. 현실 세계: 현실세계는 이 그림자가 생긴 벽이다.

이해를 위해 필요한건 이 세가지다. 우리가 보고 있는 현실 세계가 사실 이 완벽한 세계의 존재_(설계)가 빛에 투영되어 만들어진 그림자_(구현체)라는 것이다. 완벽한 개는 오직 이데아의 세상에 하나뿐인데 현실세계에 투영된 그림자 중에 어떤놈은 앞집 뽀삐가 되는 것이고 어떤 놈은 옆집 바둑이가 된다는 생각이다.¹

'당신은 개라는 것을 본적이 있습니까?' 보통은 옆집 말티즈 럭키나 우리집 치와와 뽀삐를 생각하며 있다고 답하겠지만 이데아적 물음을 하기 시작하면 참 골치 아픈 물음이 된다. '당신은 우리가 "개"라고 할 때 말하는 "개" 그 자체를 본적이 있습니까?' 질문부터 머리가 띵해진다. 보통같으면 뭔 미친놈인가 하고 화를 내든 도망을 치든 하겠지만 우린 이제 이 문장이 무엇을 말하려는지 이해할 수 있다. '당신은 이데아 세상의 개를 본적이 있습니까?' 우리는 이것이 농담이라 생각해서 웃든지 아니면 '본적이 있을리 없잖아요'라며 답할 수 있게 되었다.

이런 이데아적인 사상의 끝판왕은 바로 수학이라고 할 수 있겠다. 우리 모두 1이란걸 알고는 있지만 실제로 본적이 없다. 1이라는 개념을 활용할 뿐이지 우리가 '1' 이라고 지칭하는 '1'이라는 원형 그 자체를 현실 세계에서 본적이 있을리가 없다.

조금만 더 나아가 생각해보면 원_(circle)이라는 것도 관념적인 것으로 완벽한 원이라는 그 자체를 우리는 본 적이 없다. 모니터에 아름다운 수식으로 이쁘게 그려진 원도 현실 세계에 구현된 객체일 뿐이기 때문이다. 그래서인지 과거에는 이런 이상적인 세상을 완벽한 자와 완벽한 컴파스만으로 모든 것을 표현할 수 있는 기하학적인 세상이라고 말했다고도 한다.

이름

여기서 우리는 인류가 겪은 놀라운 진화중에 하나인 '사물에 이름 붙이기'를 정말 아무런 힘도 들이지 않고 이해하고 있음을 알 수 있다. 단순히 뽀삐, 럭키를 말하는게 아니라 개, 소, 닭, 말, 사람, 숟가락 이런 것들 말이다. 객체들의 공통된 특징을 알아내 '추상화' 한 것이다.

야!!! 개 짓는 소리 좀 안나게 하라!!!

이렇게 다시보면 객체화, 다형성, 런타임 함수 변경 요청등이 녹아있는 이 얼마나 아름다운 문장인가? 우리는 인터페이스, 클래스, 인스턴스를 활용한 추상화와 다형성에 대한 개념을 일상생활에서 너무도 자연스럽게 사용하고 있다. 당연한걸 이해하려고 하다보니 힘들었던 걸까?

프로그래밍과 연결해서 생각해보기

class PerfectDog {
  constructor() {}

  happy() {
    return "bow!";
  }
}

const dog = new PerfectDog();

console.log(dog.happy());

이데아 세상에만 있는 완벽한 개는 오직 완벽한 형태 하나만 존재_{(class Dog {})}하며 현실세계_(런타임)에서 존재_(실행)하지 않는다. 그러나 우리가 빛_(new)을 통하여 그림자를 투영하면_{(const dog = new Dog())} 비로소 현실세계에서 볼 수 있는_{(dog.happy())} 것이다.

기타

JavaScript에서의 객체

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와 같이 문법적 특징을 이용하여 지칭할 수도 있겠지만 문자열로 이루어진 경우에도 사용할 수 있기 때문에 데이터 유형을 지칭하기에는 조금 어색해보인다.

결론

이렇게 정리하고 보니 두 단어의 관계가 명확해진다. 그러나 너무 오랜기간 혼용 되고 이해 없이 남발되어 앞으로도 대화에 있어서 문맥을 추론해야하는 수고가 없어지진 않을 것이다. 그리고 솔직히 말하면 객체라고 뱉어버리면 자연스럽고 편하기는 하다.

1. 저번에 만든 클래스를 상속받아 구현해라.
2. 객체로 반환하니까 forEach 쓰면 오류 난다.
3. DB 커넥션으로 조회하세요.

그렇다고 여기가 북한도 아니고 굳이 한자어나 순우리말을 고집할 필요도 없다. 익숙한 단어를 굳이 바꿔 혼란을 가중시킬 바에는 원어를 그대로 사용하는 것도 방법이라 생각한다. 클래스 정도는 명확하게 구분해주거나 객체에 이름이 있다면 이름으로 부르고 추상클래스, 인터페이스와 같이 특수한 기능으로 명칭이 구분된 것들은 명확하게 이야기 하는 것이 의사전달의 명확성을 위해 더 좋을 거라 생각한다.

글을 작성하면서 상당히 재미있었는데 컴퓨터쪽에서 이 기능을 '객체'라고 지은 사람이 이런걸 다 고려해서 지었을 것 같진 않다. 사람 생각이 비슷해서 그런건지 아니면 극에 달하면 통해서 그런건지 철학과 컴퓨터가 이렇게 연결될 수 있다는 것이 참 흥미로웠다. 전혀 관련 없을 것 같은 리만 제타 함수의 근의 분포를 구하는 식과 양자역학의 에너지 분포를 구하는 식이 나중에 알고 보니 동일했다는 유명한 일화처럼 말이다.

프로그래밍이라기에는 좀 생뚱맞은 글이지만 처음 깨달았을 때 나름 흥미로웠기에 언제 한 번 글을 작성하려고 마음을 먹었었다. 글을 작성하면서도 자료조사를 할 때 비슷한 생각을 한 사람들도 상당히 많다는 걸 알게 된 것도 재미있었다.