황소

추상화(Abstraction)라는 단어를 처음 접하는 개발자는 아마 없을 것으로 생각한다. 대부분의 개발자들이 객체지향 프로그래밍을 배우는 과정에서 이 단어를 이미 접했을 것이다. 많은 개발자들이 추상화라는 개념을 단지 객체지향 프로그래밍의 도구로 한정해서 생각하는 이유가, 어쩌면 그 때문일지도 모르겠다. 사실, 추상화에 대해서 정확히 알고 있는 개발자는 생각보다 많지 않다. 추상화의 범위는 독자 여러분이 생각하는 것보다 훨씬 더 넓다. 컴퓨터와 프로그래밍에 관련된 모든 것이 추상화의 대상이 될 수 있고, 사실은 이미 추상화된 결과물이다.

추상화(Abstraction)와 추상화(Abstract art)는 우리말로 똑같이 쓰인다. 필자는 피카소의 대표적인 추상화(Abstract art)인 황소 연작을 통해서, 이 책의 주제인 추상화(Abstraction)에 대한 설명을 시작하려고 한다. 이 그림은 스티브 잡스가 애플의 신입사원을 교육할 때 제품 디자인의 교육 자료로 활용한 것으로도 알려져 있다. 이 책에서는 독자 대부분이 개발자일 것으로 가정하고, 조금 더 개발자가 관심을 가질 만한 방향으로 접근할 것이다.

이번 장에서는 ‘추상화(Abstract art)’와 ‘추상화가 만들어지는 과정(이 또한 Abstraction)’을 통해서, ‘추상화(Abstraction)’가 무엇인지 살펴보고, 그 과정을 직접 눈으로 확인하려 한다. 그리고 더 나아가 ‘추상’이라는 개념의 철학적인 의미에 대해서도 생각해 볼 것이다. 추상화(Abstraction)가 무엇인지 좀 더 깊이 알게 된다면, 우리의 코드에 철학이 아주 조금이라도 스며들 것으로 믿는다.


그림1 파블로 피카소, 황소 연작 (Jeremy Coon - Art Institute of Chicago)


추상화와 추상화

우선 추상화(Abstract art)와 추상화(Abstraction)에 어떤 공통점과 차이점이 있는지 살펴보려고 한다. 추상(Abstract)이라는 개념을 공유한다는 것은 확실해 보인다.


추상화(Abstract art)

먼저 추상화(Abstract art, 抽象畫)의 사전적인 정의부터 알아볼 것이다. 만약 어떤 그림이, 대상의 구체적인 형상이 아니라, ‘점’이나 ‘선’, 또는 ‘면’, ‘색’과 같은 조형 요소만으로 표현되어 있다면, 우리는 그것을 추상화(Abstract art)라고 부른다. 머리로는 이해할 수 있지만, 쉽게 피부로 와 닿지는 않을 것이다. 더구나 미술에 큰 관심이 없다면, 왜 그림을 그런 식으로 이상하게 그려야 하는지, 도무지 이해하기 어려울 것이다. 여기에는 역사적인 배경이 있다.

1차 세계대전이 일어나기 직전의 유럽은 이성과 합리주의가 지배하는 세상이었다. 과학과 기술이 엄청나게 발전했고, 이를 통해 유럽 사회는 전에 없던 물질적인 풍요로움을 누리게 되었다. 유토피아가 멀지 않았다고 느끼고 있었을지도 모르겠다. 이 당시 유럽 미술계의 주류로서 활동하던 예술가들은, (1)원근법과 해부학 등의 과학적인 방법을 통해, (2)이성적이고 합리적으로 (3)구체적인 대상을 표현했다. 사실주의의 전통을 따르고 있었다고 말할 수도 있겠다.

그러나 1차 세계대전은 이성과 합리주의를 반성의 대상으로 만들었다. 이와 더불어, 이성과 합리주의를 토대로 했던 기존의 사실주의 미술 역시 반성의 대상이 되어 버린다. 그 결과 예술가들은 사물을 이성적으로 재현하는 대신 주로 감정을 표현하게 된다. 원근법 등의 전통적인 표현 방식에서 벗어나, 사물의 모습을 형태를 해체해서 새롭게 구성하는 등의 새로운 표현 양식이 주목받게 된다. 어쩌면 이것은 전통에 대한 반발로 볼 수도 있고, 이성에 대한 반발로 볼 수도 있을 것이다.

이와 반대로 과학과 이성으로 만들어진 기계 문명과 산업화의 결과가 미술에 영향을 끼치기도 하였다. 산업화에 따른 대량생산은 이성적이고 합리적인 이유 때문에 단순하고 군더더기 없는 설계를 요구했고, 이를 통해 만들어진 이미지들이 가진 아름다움을 새롭게 발견하게 된 것이다. 역설적이게도 산업화가 영향을 끼친 단순하고 군더더기 없는 이미지가 추상미술 시대의 상징이 되고, 이러한 추상미술이 다시 산업에 영향을 주면서 현대 디자인에 영향을 끼치게 된 것이다. 1차 세계대전이 일어나지 않았다면 스마트폰의 생김새가 지금과는 많이 달라졌을지도 모르겠다.

앞서 소개했던 피카소의 황소 연작을 주의 깊게 살펴보자. 우선 마지막 그림을 먼저 보겠다. 이 그림은 단순한 선 몇 개로 황소의 특징을 나타내고 있다. 위에서 추상화는 선과 같은 조형 요소만으로 표현되어 있다고 했으니, 이 그림은 추상화(Abstract art)의 조건을 충족한다고 할 수 있을 것이다. 이에 비해 첫 번째 그림은 꽤 구체적이고 세밀하게 황소의 형상이 묘사되어 있다. 연속된 그림 각각을 살펴보면, 첫 번째 그림은 추상화(Abstract art)라고 보기에 어렵지만, 단계가 진행될수록 점점 추상화(Abstract art)에 가까워지고 있는 것을 볼 수 있을 것이다. 우리는 이러한 과정을 추상화(Abstraction, 抽象化)라고 부른다.


추상화(Abstraction)

드디어 추상화(Abstraction, 抽象化)가 무엇인지 자세히 알아볼 차례가 되었다. 앞으로 괄호 안에 별도의 영문을 표기하지 않는다면 추상화(Abstraction)를 말하는 것이다. 추상화를 한마디로 설명하자면, ‘추상적인 것으로 되게 한다’는 것이다. 추상적인 것으로 되게 한다는 말의 의미를 이해하기 위해서는 당연히 ‘추상’이 무엇인지부터 알고 있어야 한다. 추상(Abstract 또는 Abstract image, 抽象)이라는 말은 여러 사물이나 개념에서 공통되는 특성이나 속성을 뽑아내어 만들어진 결과를 말한다. 추(抽)라는 한자가 ‘빼다’ 또는 ‘뽑다’라는 뜻을 가지고 있다는 것을 안다면, 쉽게 이해할 수 있을 것이다. 추상(Abstract)이 뽑아내어 만들어진 결과라면, 추상화(Abstraction)는 뽑아내는 과정을 말하는 것임을 알 수 있다. 공통되는 특성이나 속성이 아닌 것을 버리는 과정이라고 표현할 수도 있을 것이다.

추상화(Abstraction)에 대한 이러한 해석은 많은 개발자들이 사용하고 있는 의미와 조금 다른 것처럼 느껴질 수 있다. 이것은 앞서 말한 것처럼 개발자들이 주로 객체지향 프로그래밍의 도구로 추상화라는 용어를 사용하기 때문이다. 이 때의 추상화는 부모 클래스나 인터페이스에 구체 클래스들의 공통적인 특징을 집약하는 과정을 말한다. 하지만 꼭 클래스가 아니더라도 추상화의 대상이 될 수 있다. 우리는 바로 다음 장에서부터 다른 무엇이 추상화될 수 있는지 살펴볼 것이다. 이를 통해 우리의 생각 속에 굳어 있는 추상화의 대상을 넓힐 것이다. 추상화의 대상을 넓힌 이후에는 추상화가 어떻게 이루어지는지를 살펴볼 것이다. 그 다음에는 프로그래밍과는 전혀 상관없어 보이는 주변 삶 속에서 추상화의 도구를 찾아볼 것이다.

이제 피카소의 황소 연작의 그림을 하나씩 자세히 살펴보자. 첫 번째 황소 그림으로부터 마지막 황소 그림으로 진행되는 과정은 분명 추상화의 과정으로 볼 수 있다. 황소의 공통되는 특성과 속성을 뽑아내는(또는 빼내는) 과정이기 때문이다. 반대로 어떤 황소만 특별하게 가지고 있던 속성을 제거하는 과정으로 보는 것도 가능하다.

이번엔 모든 그림을 한눈에 담아보자. 연작에 포함된 각각의 그림은 황소의 특징을 추상화 해가는 과정이다. 그런데 그 각각의 작품을 모아 놓고 한꺼번에 보면, 전체가 모여 또 하나의 그림이 된다. 이처럼 독립된 그림들이 모여 있는 것도 또 하나의 작품이라고 볼 수 있을 것이다. 그렇다면 이렇게 각각의 그림을 모아 놓은 ‘황소 연작’이라는 그림 역시 추상화(Abstract art)일 것이다. 다시 말해 이 연작은 추상(Abstract)을 추상화(Abstraction)한, 추상화(Abstract art)인 것이다.


추상(Abstract)과 구상(Figurative)

지금까지 추상에 대해서 알아보았다. 앞으로 좀 더 깊이 있는 논의를 해야 하기 때문에, 추상의 반대 개념이라고 할 수 있는 구상(Figurative)에 대해서도 설명하고자 한다. 일반적으로, 구상을 추상으로 만드는 과정이 추상화(Abstraction)이고, 추상인 것을 구상으로 만드는 과정은 반대로 구상화(Figuration)라고 할 수 있을 것이다. 개발자들에게는 구상이라는 표현보다는 구체(Concrete)라는 표현이 조금 더 익숙할 것이다. 이러한 구체화(Concretization)의 과정은, 개발자들에게는 주로 구현(Implementation)이라는 표현으로 불린다.

아마도 코딩의 8할은 추상화와 구체화일 것이다. 유연하게 추상화된 인터페이스를 설계하거나, 구체 클래스를 리팩토링해서 추상화한다. 아니면 누군가 추상화해놓은 인터페이스를 구현하거나, 다른 추상 클래스를 상속해서 구체화하는 일을 매일 반복하고 있을 것이다. 앞으로 좀 더 자세히 설명하겠지만, 알고리즘을 구현하는 것도 추상화이고, 변수를 만드는 것, 변수와 함수의 이름을 짓는 것 역시 추상화다. 심지어 야근을 마치고 퇴근하는 길에 ‘죽겠네’라고 탄식하는 것 마저도 추상화다.

마지막으로 한번 더 황소 연작을 살펴보자. 이번에는 이 그림을 그림 대신 어떤 코드로 생각하고, 황소를 설계하고 구현한 피카소의 의도를 읽어보자. 어쩌면 연작이 진행되는 과정이 황소 오브젝트에 대한 리팩토링으로 보일 수도 있을 것이다. 마지막 그림이 황소 인터페이스처럼 보일 수도 있다. 그렇다면 그 황소 인터페이스를 구체화할 수도 있겠다. 첫 번째 황소와는 다른 디테일을 가진, 다른 그 어떤 황소라고 해도 새로 구현할 수 있을 것이다. 이제 피카소의 그림이 붕어빵 틀처럼 보인다.


당장은 쓸모 없지만...

지금부터는 우리 자신이 개발자라는 생각을 버리고, 프로그래밍과 전혀 관계없어 보이는 이야기를 좀 해볼까 한다. 물론 정말로 아무 관계가 없는 것은 아니다. 필자는 여러분이 이 책을 통해서, 프로그래밍과 전혀 관련이 없어 보이는, 세상과 삶 속에 감추어진 추상화의 도구를 찾을 수 있기를 바란다. 단순히 인문학을 통해서 추상화를 배우는 것이라고 생각해도 좋다. 추상화는 컴퓨터를 위해서 하는 것이 아니라, 인간을 위해서 하는 것이라는 사실을 생각하면서 이 책을 읽어 주었으면 한다. 다음에 설명하는 두 가지 주제는 그 맛보기이다.


시뮬라크르와 시뮬라시옹

이 장의 나머지 부분에서는 추상 및 구상과 연관해서 생각할 수 있는 다른 개념들을 살펴볼 것이다. 이 개념들은 추상 또는 구상과 비슷해 보이지만, 조금 자세히 살펴보면 다른 점이 있다. 먼저 시뮬라시옹과 시뮬라크르를 알아보자. 이 개념은 ‘장 보드리야르’라는 프랑스 철학자가 [시뮬라크르와 시뮬라시옹]이라는 책에서 처음 언급한 개념이다. 장 보드리야르는 이 책에서 시뮬라크르와 시뮬라시옹을 다음과 같이 설명하고 있다.

  • 시뮬라크르(프랑스어: simulacre)는 존재하지 않지만 존재하는 것처럼, 때로는 존재하는 것보다 더 생생하게 인식되는 것들을 말하며, 시뮬라시옹(프랑스어: simulation)은 시뮬라크르가 작용하는 것을 말하는 동사이다.

머릿속에 아이유를 떠올려보자. 이 책을 읽고 있는 독자 대부분이 아이유를 본 적이 있을 것이다. 아마 직접 아이유를 만났던 것은 아니고, TV와 인터넷에서 보았을 것이다. 그렇다면 그때 우리가 보았던 아이유는, 아이유의 실체가 아니라 기호화되어 복제된 이미지다. 다시 말해 미디어가 만들어낸 기호인 것이다. 이처럼 기호화되어 복제된 아이유를 시뮬라크르라고 부른다. 또한 TV에서 아이유를 보는 것은, 아이유의 실체를 시뮬라시옹(시뮬레이션)하는 것이 된다.

어쩌면 음반 제작자나 방송 제작자는 다수의 사람들이 보는 아이유의 특징 중 공통적인 성질을 뽑아내어 추상화한 다음(기호화하여), 그것을 음반이나 방송 프로그램으로 제작(복제한다)하는 것 같다. 우리가 TV에서 아이유를 보는 과정과, 인터페이스를 설계하고 구체 클래스를 만드는 과정은 묘하게 닮아 있는 것 같다.

만약 객체 지향 개발자가 이 책을 여기까지 읽었다면, 구체화된 클래스 인스턴스가 시뮬라크르 같다는 느낌을 가질지도 모르겠다. 반면에, 그것이 시뮬라크르의 정의와는 잘 맞지 않는 것 같은 느낌도 들 것이다. 시뮬라크르는 실체가 아니고 가짜라고 하는 것 같은데, 객체지향 개발자에게는 그 시뮬라크르야 말로 실제로 존재하는 것이기 때문이다. 만약 그가 자바 개발자라면, 위의 설명을 이렇게 바꿔 말할지도 모르겠다.

  • 인터페이스는 메모리에 존재하지 않지만, 코드상에서는 구체화된 인스턴스(시뮬라크르)보다 생생하게 인식되는 것이며, 클래스의 인스턴스화(Instantiation)는 인스턴스가 작용하는 것을 말하는 동사이다.

그는 인터페이스의 메소드를 호출하는 코드를 보고 있지만, 인터페이스는 실체가 아니고 ‘인스턴스화 된’ 또는 ‘인스턴스화 될’ 객체가 실체라는 말일 것이다. 잠시만 책을 읽는 것을 멈추고 생각을 해보자. 지금 이 설명이 맞는 말인가?


이데아(Idea)와 그림자

시뮬라크르와 시뮬라시옹, 또는 추상과 구상 (또는 구체) 개념은, 아주 오래된 철학과도 연관되어있다. 이제 플라톤 시대로 거슬러 가보자. 그곳에서 우리는 ‘이데아’라는 개념을 찾을 수 있다. 플라톤은 이데아에 대해서 다음과 같이 설명했다.

  • 이데아는 현상 세계 밖의 세상이며 이데아는 모든 사물의 원인이자 본질이다. 그리고 물질세계에서 우리가 마주치는 사물들은 이데아의 그림자일 뿐이다.

만약 어떤 사람이 평생 동안 동굴에 몸이 묶인 채로 갇혀 있었고, 동굴 벽에 비친 바깥세상의 그림자만을 보았다고 생각해보자. 그는 자신이 보고 있는 것의 본질이 따로 있고, 자신이 보고 있는 것은 허상일 뿐이라는 사실을 전혀 알 수 없다. 플라톤에 따르면, 우리가 현실에서 보는 모든 것들은 이데아를 복사한 허상이다.

혹시라도 여러분 중에 아이유를 직접 만난 독자가 있다고 해도, 그것은 그저 아이유의 허상을 만난 것뿐이다. 아이유의 이데아가 있기 때문에 아이유가 존재한다. 아이유의 본질로 만들어진 그림자, 즉 아이유라는 인간을 통해 우리는 그녀의 모습을 보고 노래를 들을 수 있다. 그런 아이유를 기호화해서 복제하면 우리가 일반적으로 TV와 음반에서 만나는 아이유의 시뮬라크르가 된다. 이 책은 개발자를 위한 책이므로, 인터페이스를 이데아라고 생각해 보자. 인터페이스 대신 클래스라고 보아도 좋다. 그렇다면 코드 세계에서 동굴에 비친 그림자는, 아마도 인스턴스화 된 오브젝트일 것이다. 자, 이 설명은 말이 되는가?

지금까지의 설명을 조금은 혼란스럽게 느끼고 있을 것으로 생각한다. 아니, 굉장히 많이 혼란스러울 것이다. 어쩌면 혼란스럽다는 표현보다는 불편하다는 표현이 더 정확할지도 모르겠다. 하지만 불편함은 당연하고 자연스러운 것이며, 불편함이야 말로 이 책의 진짜 목표이다. 필자는 독자 여러분에게 혼란스러움과 불편함을 전달하기 위해 이 책을 썼다. 예술가가 되는 일이 쉬울 것이라고 생각하지는 않았을 것이라고 믿는다. 복잡하게 섞여 있고 꼬여 있는 여러 개념들을 여러분의 머릿속에서 스스로 정리해보기 바란다. 그 과정에서 공통되는 특성이나 속성을 뽑아내야 한다. 그것은 추상화 그 자체일 수도 있고, 추상화를 하기 위한 도구를 만드는 과정일 수도 있다.

이것은 동굴 벽에 비친 그림자를 보면서 앉아있는 대신, 일어나서 동굴 밖으로 나오는 과정이다. 몸을 묶고 있는 끈을 풀고 다리에 힘을 주어 일어나는 과정이다. 쉽지 않겠지만 동굴 밖으로 나와 보면, 그곳에는 개발자를 예술가로 거듭나게 하는 도구가 있다. 그곳에 추상화가 있다.