인류 발전은 추상화 덕분
추상화는 복잡한 개념을 숨겨 간단하게 만드는 특징이 있고, 이러한 특징은 인간이 더욱 고등한 생각을 가능하도록 돕는다. 모든 생명체에는 수명이라는 것이 있듯 인간도 마찬가지다. 그래서 자신 인생의 모든 경험을 그대로 후대에 전달할 수 없다.
만약 선대의 인간이 겪었던 경험을 그대로 100% 손실 없이 전달해야만 지식이 전수될 수 있었다면 어떻게 되었을까? 100년 동안 겪은 경험을 전수받기 위해 100년 동안 설명해야 한다고 생각해 보라. 후대의 지식은 기껏해야 선대의 지식과 1:1 대응이 될 뿐이고, 인간은 여느 동물들과 다를 바 없는 삶을 살았을 것이다.
그런데 우리는 어떻게 수천년에 걸친 시행착오를 받아들이고 더 나은 세상을 구축하는 데 때로는 책 몇 권이면 충분하기도 할까? 내 결론은 추상이다. 인간은 일반화된 경험과 추상화한 지식을 전달하면서 100년간의 학습내용을 100년동안 전달하지 않아도 되게 만들어 문명을 발전시켰다.
하지만 이러한 추상화에는 양면성이 존재한다. 인간이 경험을 문자나 언어라는 매체를 통해 100% 전달하는 것이 아니라, '일반화'하거나 '중요한 부분을 추상화'시켜 지식을 전달한다는 성질은 귀납과 매우 비슷한 특징을 가진다. 귀납이 지식을 개척하는 동시에 사실을 숨기는 성질이 있는 만큼, 추상화된 정보를 기반으로 의사결정을 하거나 추상적인 개념을 바탕으로 사고를 발전시키는 일에는 큰 위험이 따르기도 한다(ref1).
우리가 얼마나 많은 것을 추상적으로 받아들이고 있는지를 느끼기 위해 '도덕'이라는 개념을 예로 들어보자. 우리 모두가 도덕이라는 ‘의미론적 표현’을 공유하고, 도덕에 대해 마치 아는 것처럼 말하고 행동한다. 하지만 사람들마다 가지는 도덕의 구체적인 기준은 다르다. 뿐만 아니라 시간에 따라 변화하기까지 한다. 십자군 전쟁은 당시 도덕적이었을 것이고, 마녀 사냥도 당시에는 도덕적인 행위였을 것이다. 후배에게 조언을 건네는 행위도 꼰대라고 폄하되지만, 기성세대에서는 사회 유지를 위해 꼭 필요한 도덕적 행위였을지 모른다. 이처럼 추상적으로 공유되는 개념들의 구체적인 내용은 시대, 문화, 개인에 따라 달라 오해와 갈등의 원인이 되기도 한다.
추상화에 대한 오해 해명
미술관에 걸린 추상화를 떠올려보자. 피에트 몬드리안의 작품을 보며 많은 사람들은 "이게 왜 대단한 거지? 그냥 색칠한 네모 칸 아닌가?"라고 생각한다. 눈앞의 풍경을 그대로 옮겨 놓은 듯한 사실적인 그림은 즉각적으로 이해하고 감탄할 수 있지만, 선과 색으로만 이루어진 추상화 앞에서는 무엇을 느껴야 할지 막막해진다. 도대체 '무엇을' 그렸는지 알 수 없기 때문이다.
몬드리안의 나무 추상화
더 본질만, 더 특징만 남기려고 하는 과정이다(ref5).
'객체(object)가 아닌 분위기(mood)를' 표현하는 과정이다(ref6).
미술관에 걸린 피에트 몬드리안의 작품을 떠올려 보자. 워낙 유명한 작품이지만, 사실 "이게 왜 대단한 거지? 그냥 색칠한 네모 칸 아닌가?"라고 생각하는 것이 훨씬 일반적인 반응이다. 눈앞의 풍경을 그대로 옮겨 놓은 듯한 사실적인 그림은 즉각적으로 이해하고 감탄할 수 있지만, 선과 색으로만 이루어진 추상화 앞에서는 무엇을 느껴야 할지 막막해진다. 도대체 '무엇을' 그렸는지 알 수 없기 때문이다.
수학에서도 마찬가지이다. 친구에게 '함수'라는 개념을 설명해야 할 때, 다짜고짜 "함수란 집합 X의 각 원소에 대해 집합 Y의 원소가 오직 하나씩 대응하는 관계야"라고 말하면 상대방은 고개를 갸웃거릴 것이다. 하지만 "음료수 자판기를 생각해봐. 1000원짜리 버튼(입력)을 누르면 콜라(출력)가 하나 나오지? 이렇게 입력 하나에 출력 하나가 정해지는 규칙, 그게 바로 함수야"라고 구체적인 예시를 들면 금세 이해한다. 이처럼 우리는 추상적인 정의나 일반식보다 구체적인 사례를 접했을 때 훨씬 직관적이고 편안하게 느낀다.
하지만 추상화의 본질은 '어려움'이나 '모호함'이 아니라 '핵심 추출'에 있다. 복잡한 대상에서 불필요한 세부사항을 걷어내고 가장 본질적인 특징과 구조만을 남기는 과정, 마치 원액을 짜내듯 '증류(distill)'하는 과정인 셈이다. 몬드리안은 나무의 구체적인 잎사귀나 가지의 형태가 아닌, 수직과 수평의 구조적 긴장감과 색의 조화라는 '본질'을 추출해냈다. 수학의 함수 정의 역시 세상의 수많은 '입력-출력' 관계를 관통하는 단 하나의 '핵심 규칙'을 담아낸 것이다. 꼭 학문에 국한되는 이야기는 아니다. 테슬라의 수석 엔지니어 안드레 카파시(Andrej Karpathy)는 기업의 의사결정에서 적절한 추상을 찾아내는 일론 머스크가 ‘증류(distill)에 탁월하다’고 표현했고(ref7), 또다른 기업가 이건희는 추상화란 ‘본질에 대해 고민하는 과정’이라고 표현했다(ref8).
결국 추상과 구체는 소통의 목적과 대상에 따른 효율성의 트레이드오프(trade-off) 관계에 있다. 비전문가에게는 구체적인 예시가 이해를 돕는 가장 빠른 길이지만, 해당 개념에 대한 배경지식과 고민을 공유하는 집단 내에서는 추상적인 표현이 훨씬 더 빠르고 정확한 소통 도구가 된다. 미술사적 맥락을 이해하는 사람에게 몬드리안의 작품은 장황한 설명 없이도 조형의 본질에 대한 깊은 통찰을 전달하며, 수학자들 사이에서는 수많은 예시를 나열할 필요 없이 단 하나의 일반식으로 완벽한 소통이 가능해진다. 몬드리안 작품을 감상하는 사람에게 오히려 구체적인 나무의 형태를 보여주면 작품 해석의 자율성을 침해하는 일이 될 수도 있고, 수학자들 사이에서 음료수 자판기 이야기는 핵심 내용으로 빠르게 이동하지 못하게 가로막는 불필요한 사족이 된다. 스타트업에서는 추상화의 강력한 특징을 살려 자신들이 정의한 수많은 단어로 소통하는 것을 볼 수 있고, 이 단어 각각이 함의하는 구체적인 내용을 오해 없이 더 정확히 공유하기 위해 문화를 만들기도 한다. 사람들은 이를 알아들을 수 없어 판교 방언이라고 부르지만 말이다. 즉, 특정 집단에 속해 추상적 개념을 더 잘 공유할수록 오해 가능성은 상대적으로 낮아지고 효율성이 높아진다.
컴퓨터 과학으로 본 추상화의 가치와 미래
컴퓨터 과학은 추상화의 위력을 가장 명확하게 보여주는 분야다. 프로그래밍 언어의 발전사는 곧 추상화 수준의 상승사라고 할 수 있다. 가장 낮은 수준의 어셈블리 언어부터 C언어, 그리고 파이썬까지, 각 언어는 서로 다른 추상화 수준을 제공한다.
예를 들어, '두 변수의 값을 바꾸기'라는 간단한 작업을 생각해보자. 파이썬에서는 단 한 줄로 표현할 수 있다: A, B = B, A. 기호가 나타내는 의미론적으로 "둘이 자리를 바꿔"라고 말하는 것과 유사한 수준의 추상화다.
반면 하지만 C언어는 그렇게 단순하게 표현할 수 없다. C언어에게는 이렇게 명령해야 한다. ‘자, 일단 종이 C를 가져와, 종이 C에다가 A에 적혀 있는 숫자를 옮겨 적어, 그러면 이제 종이 A의 숫자를 지우고 B에 적혀 있는 숫자를 A에 옮겨 적어. 그러면 이제 마지막으로 종이 C에 적혀 있던 숫자를 B에 옮겨 적어’ 라고 명령해야 한다. 위 예제 코드에서는 아래와 같이 드러나 있다. temp = A; A = B; B = temp;. 더 구체적인 단계들을 명시해야 하는 것이다.
어셈블리의 상황은 훨씬 좋지 않다. 훌륭한 추상화 덕분에 잊고 살았지만, 이세상 모든 컴퓨터의 연산장치들은 동시에 수십개의 값들조차 외우고 있기 어려워한다. 연산장치가 값을 써둘 수 있는 공간에는 s1, s2, s3, t1, t2, t3 … 따위의 이름이 붙어 있다. 이들 하나하나에 직접 접근해 명령해 주어야 한다. 게다가 컴퓨터는 원래 덧셈 뺄셈 수준밖에 못 한다. 모든 기능들을 덧셈과 뺄셈을 이용해 구현해 주어야 하는 것이다. 위 예제 코드에서는 아래와 같이 드러나 있다. 사실 쳐다보기도 싫다.
add $t1,$t1,$s2
lw $t0,0($t1) #a[i]
L3: beq $s3,$s1,incc
add $t1,$t1,$s3
lw $t2,0($t1) #a[j]
slt $t3,$t0,$t2
beq $t3,$0,swap
L4: addi $s3,$s3,4
...
swap:
sw $t0,0($t1)
sub $t1,$t1,$s2
sw $t2,0($t1)
j L4
C
복사
분명히 앞서 “추상적인 내용이 이해하기 어려운 것이 아님”을 설명해야 하는 상황이었는데, 이것도 보면 구체적인 것이 훨씬 어려워 보인다. 왜 그럴까? 추상화는 최적화가 어려워지는 등 오해를 만들지만 복잡성을 은닉하기 때문이다. 파이썬이 A, B = B, A라는 우아한 표현 뒤에는 실제로 C언어나 어셈블리 수준에서 일어나는 복잡한 과정들이 숨겨져 있다. 하지만 대부분의 경우 우리는 그 세부사항을 알 필요가 없다. 마치 자동차를 운전할 때 엔진의 내부 구조를 모르더라도 아무런 문제가 없는 것처럼 말이다. 하지만 동시에 이는 개발자의 세세한 제어 범위를 박탈하는 결과를 가져오고 의도치 않은 동작이나 오해를 만들어내기도 한다.
python 에서 나무를 그려내는 방법
어셈블리에서 나무를 그려내는 방법
내가 나무 1만 그루가 심겨져 있는 숲을 그린다고 쳐 보자. 파이썬이라는 도구로 그림을 그린다면, 몬드리안이 그려 놓았던 나무 그림 중 가장 추상화된 뼈대들을 가지고 세상을 도장찍듯 그려나갈 수 있다. 반면 C언어라는 도구로 그림을 그리는 사람도 있다. 이 사람들은 나무가 어떤 것인가? 에 대한 물음부터 해소해야 할지도 모른다. 어셈블리라는 도구로 그림을 그리는 사람도 있다. 이 사람들은 나무 줄기에 달려 있는 이파리 하나하나를 모두 그려넣고, 줄기의 생김새를 하나하나 모두 정의하고, 줄기들과 이파리들을 하나하나 나무에 붙여서 나무 하나를 정성스럽게 그려내는 일을 해야 할지도 모른다. 이파리를 하나하나 그릴 수 있기 때문에 도장찍듯 나무를 그려내는 사람들보다 훨씬 느리지만 훨씬 더 디테일하게 제어할 수 있다. 이것도 복잡도와 오해가능성의 트레이드오프라고 볼 수 있겠다.
추상적인 것들이 가치를 만드는 방향으로
나무 1만그루가 심겨진 숲처럼 거시적인 시스템을 구현해내야 하는 오늘날, 어셈블리와 C를 직접 다루는 사람들이 적은 이유가 여기 있다. 딥러닝과 같이 아주 복잡한 개념들을 다루기 위해 어셈블리나 C 언어가 아닌 파이썬을 사용하는 이유도 비슷한 맥락이라고 해석할 수 있다(ref14). 지식이 복잡해지고 정교해질수록 복잡함을 가려놓고 새로운 차원의 복잡성을 가진 학문을 발전시킬 수 있는 시스템들이 새로운 가치를 만들기도 한다.
20년 전 어셈블리는 컴퓨터전공의 필수과목이었지만 2021년 현재에는 제외된 학교가 대다수인 이유도 여기 있다. 최근 몇년간 컴퓨터공학을 뿌리로 한 다양한 학과들이 나타난다. 우리 학교만 해도 데이터사이언스, 인공지능, 지능기계전자공학이라는 이름으로 많이 생겨났다. 몇 년 전까지만 해도 학교에는 컴퓨터공학과밖에 없었다는 사실과 크게 대조되는 모습이다. 더 과거로 몇 년 전까지만 거슬러 올라가도 컴퓨터공학과는 전산학과라고 불렸다.
학과 이름은 과거 컴퓨터로 할 수 있는 가장 복잡한 일들을 ‘계산하는 일(전산)’ 쯤으로 여겼음을 내포한다. 그렇다면 미래는 어떨까? 미래의 프로그래밍은 인간의 추상에서 일어날지도 모른다. 우리는 별다른 생각을 않고 컴퓨터에게 ‘두 개의 통에 들은 숫자를 바꿔 줘!’ 라고 명령하고 싶을지도 모른다. 하지만 ‘바꿔 줘!’는 굉장히 추상화된 명령이다. 대한민국의 모든 사람은 ‘바꾸다’라는 개념에 대해 비슷한 관념을 가지는 전문가 집단인 셈이다. 인간이 ‘A 와 B 에 들어있는 값을 바꾸기’ 라고 말하면 그에 맞는 코드를 만들어낸다거나 하는 것처럼 말이다. 오늘날 이런 기술들이 속속 등장하며 많은 프로그래머들이 이것이 프로그래머를 대체하네 마네 갑론을박을 벌이지만 생각보다 결과는 자명하다. 추상화의 관점에서, 추상화가 사람 수준까지 올라가려는 노력의 일환으로 보인다. 당연히 그 기술이 점점 좋아진다면 사람의 추상과 컴퓨터의 추상을 번역해주는 일을 맡았던 전통적인 프로그래머의 수요가 줄어드는 것이다.
추상적 사고 능력을 활용한 학습 전략
첫 번째 전략: 전문가 집단에 빠르게 진입하기
그렇다면 이제 나무를 스케치하는 방법은 무시하고 그냥 나무 도장을 잔뜩 모아 도화지에 찍어내기만 하면 될 것인가. C언어와 어셈블리는 가치없고 파이썬이 장땡일까. 프로그래머는 이제 직장을 잃고 나뒹굴게 될까? 나는 그렇다고 보지 않는다. 인류가 그러했듯 어떤 분야의 추상적 개념 위에 올라타 빠르게 학습하려면 먼저 그 개념을 공유하는 전문가 집단의 일원이 되어야 빛을 발한다. 이는 단순히 용어를 외우는 것이 아니라, 그들이 왜 그런 추상화를 선택했는지, 어떤 문제를 해결하려 했는지를 이해하는 과정이다.
몬드리안의 추상화 ⟪나무⟫를 더 재미있게 이해하기 위해서는 작가가 어떤 생각을 가지고 나무들을 바라보며 나무들의 공통점을 무엇이라고 생각했을지, 내가 지금 바라보고 있는 나무뿐 아니라 온 세상의 나무들의 공통점이 무엇인지, 이것들을 하나의 도화지 안에 그려 넣으려면 어떻게 해야 하는지 먼저 고민해 보는 편이 낫다. 그러면 ⟪나무⟫로부터 은은한 감동을 느낄 수 있는 - 추상적 표현을 공유하는 - ‘전문가 집단’에 들어간 셈이라 볼 수 있지 않을까.
프로그래밍도 마찬가지다. 객체지향 프로그래밍의 '상속'이라는 개념을 배울 때, 단순히 "부모 클래스의 속성을 자식 클래스가 물려받는 것"이라고 암기하는 것은 별 도움이 되지 않는다. 대신 "왜 개발자들이 코드 재사용을 위해 이런 개념을 만들었을까?", "실제 프로젝트에서 어떤 문제를 해결하는가?"를 고민해보면, 자연스럽게 그 추상화의 가치를 이해하게 된다.
두 번째 전략: 추상화의 한계와 가능성 파악하기
모든 추상화는 무언가를 숨긴다. 따라서 때로는 다음을 끊임없이 질문해야 한다:
•
이 추상화는 무엇을 숨기고 있는가?
•
숨겨진 부분 때문에 어떤 오해가 생길 수 있는가?
•
내 목적에 더 적합한 다른 추상화는 없는가?
•
이 추상화 위에 어떤 더 높은 수준의 개념이 구축되어 있는가?
예를 들어, 파이썬을 배우며 "리스트는 여러 값을 저장하는 자료구조"라고 이해했다면, 한 걸음 더 나아가 "메모리에서는 실제로 어떻게 저장될까?", "왜 특정 연산은 빠르고 다른 연산은 느릴까?"를 탐구해볼 수 있다. 이렇게 저수준으로 나아가는 질문들은 단순한 호기심이 아니라, 더 나은 프로그램을 작성하기 위한 통찰로 이어진다.
정리하며
추상화는 인류가 한정된 수명 안에서도 끊임없이 진보할 수 있게 한 핵심 능력이다. 선조들의 100년 경험을 100년에 걸쳐 전수받는 대신, 책 몇 권의 추상화된 지혜로 압축해 전달받을 수 있기에 우리는 더 먼 곳을 바라볼 수 있게 되었다. 미술의 추상화가 사물의 본질을 드러내듯, 수학의 일반화가 무수한 현상의 규칙을 하나로 표현하듯, 프로그래밍의 추상화가 복잡한 시스템을 다룰 수 있게 하듯, 추상화는 각 분야에서 인간의 인지적 한계를 극복하게 해주는 도구다. 우리가 마주하는 모든 지식은 필연적으로 누군가의 추상화를 거친 것이다.
중요한 것은 추상화된 정보가 쉽고 강력하지만 어렵고 오해가능성을 내포하기도 한다는 점이다. 그래서 이 추상화를 두려워하거나 맹목적으로 받아들이는 것이 아니라, 그 본질을 이해하고 적절히 활용하는 것이 추상화를 다루는 기본적인 태도가 아닐까 싶다. 추상화의 계단을 올라가며 더 넓은 시야를 갖추되, 필요할 때는 구체적인 세계로 내려와 검증하고 확인하는 유연함을 갖추는 것이 중요하다고 본다. 이것이 빠르게 배우면서도 깊이 이해하는 사람들의 습관이라고 생각한다.
parse me
1.
None
from
2.
•
우리가 무언가에 이름을 붙이는 습관도 세세한 면을 기억하기 귀찮아하기 때문일지 모른다.
to
2.
3.
8.
10.
supplementary
4.
참고
2.
None
9.
None
10.
None
11.
None
13.
None