개발자의 일이관지一以貫之

개발자의 일이관지一以貫之
이것은 파이프가 아니다.
공자께서 말씀하셨다. "삼아! 나의 도는 하나로 관통된다(一以貫之)." 증자는 "예" 하고 주저 없이 대답하였다. 공자께서 나가시자 문인들이 물었다. "무슨 말씀이십니까?" 증자가 말하였다. "선생님의 도는 충(忠)과 서(恕)일 뿐입니다.

- 공자, ⟪논어⟫, 제4편 리인(里仁)편 15장, 김형찬 역, 홍익출판사

역주: 충(忠)은 진실된 마음을 말하고, 서(恕)는 입장을 바꾸어 생각하여 남의 처지를 이해하며 대하는 것이다. 주희는 "진심으로 자기의 최선을 다하는 것이 충"이고, "자기의 마음을 미루어서 남이 바라는 바를 이해한 것이 서"라고 하였다.

공자에게 충서忠恕가 있다면, 개발자에게는 복잡도 관리가 있습니다. 이것이 좋다, 저것이 좋다 한들 프로젝트의 복잡도를 줄이는데 도움을 주지 못한다면 무슨 의미가 있겠습니까? 복잡도를 상대하는 기술은 소프트웨어 개발뿐만 아니라 모든 공학에서 중요합니다. 공학의 심장에는 추상화abstraction가 있습니다.

추상抽象이란 무엇인가?

추상적이다 하면 무언가 알아볼 수 없는 것, 모호한 것을 떠올리기 마련입니다. 그러나 여기서 말할 추상의 의미는 단어 자체에서 오는 근본적인 것입니다. 추상은 뽑을 추抽, 모양 상象 자를 씁니다. 말 그대로 '모양을 뽑아내는 것'입니다. 표준대국어사전의 정의는 다음과 같습니다.

여러 가지 사물이나 개념에서 공통되는 특성이나 속성 따위를 추출하여 파악하는 작용.

예) 정녕 해가 있다면 그것은 당신들이 지금 알고 있는 것이 아니라 그 이름이 가진 어떤 추상일 뿐이오. ⟪이문열, 사람의 아들

- 표준대국어사전, 네이버

복수複數개의 무언가에서 공통점을 찾는 것을 추상화抽象化라고 할 수 있습니다. 한자뿐만 아니라 영어도 비슷합니다. etymonline에서 abstract를 검색하면 다음과 같은 결과가 나옵니다.

late 14c., originally in grammar (in reference to certain nouns that do not name concrete things), from Latin abstractus "drawn away," past participle of abstrahere "to drag away, detach, pull away, divert;" also figuratively, from assimilated form of ab "off, away from" (see ab-) + trahere "to draw," from PIE root *tragh- "to draw, drag, move" (see tract (n.1)).

- etymonline

abstract는 '떼어내다'를 가진 접두어 'ab'와 '끌다, 끌어내다'의 의미를 가진 어근 'tragh'가 합쳐진 라틴어 abstrahere에서 왔습니다. abstract는 떼어내서 끌어내기, 조금 더 살을 붙여보면 '중요하지 않은 부분을 떼어내고 본질만 끌어내기'입니다.

무엇이 중요한가?

제가 생각하기에 예술가들에게 바칠 수 있는 가장 큰 찬사이자 평가는 '새로운 장르를 개척했다'는 것입니다("봉준호라는 새로운 장르의 탄생"). 예술가들은 그들이 생각하기에 사람에게 가장 중요한 것을 표현합니다. 그들은 중요한 것을 가장 효과적으로 표현하기 위해 중요하지 않은 부분을 과감히 잘라내고 중요한 부분을 부각합니다.

《우는 여인》(The Weeping Woman), 파블로 피카소, 1937

피카소는 큐비즘(입방체주의)이라는 새로운 장르의 본격적인 시작을 알린 예술가입니다. 위 그림에서 파블로 피카소는 슬픔의 감정을 효과적으로 전달하기 위해 원근법을 파괴하고 옆 얼굴과 앞 얼굴을 한 장의 캔버스에 합쳐서 그렸습니다. 이 그림이 추상화抽象畫라고 불리는 이유는 원근법을 떼어냄으로써 감정의 전달 효과를 극대화했기 때문입니다.

No. 61 (Rust and Blue), 마크 로스코, 1953

보이는 것보다 보이지 않는 것, 형상보다 감정이 중요하다면 형상을 완전히 없애버릴 수 있지 않을까요? 마크 로스코는 그의 그림 앞에서 눈물을 흘리는 사람이 많다는 것으로 유명합니다. 화가 본인은 관람객의 눈물을 다음과 같이 해석했습니다.

난 색채나 형태에는 관심이 없다.
대신 비극, 아이러니, 관능성, 운명같은 인간의 근본적인 감정을 표현하는 것에만 흥미 있다.
내 그림 앞에서 우는 사람은 내가 그것을 그릴 때와 같은 종교적 경험을 하고 있는 것이다.

- 마크 로스코 (색면화가 마크 로스코의 생애)

그는 인간의 근본적인 감정을 그림에 담아내기 위해 현실의 이미지를 떼어내면서 완전히 새로운 장르를 개척했습니다. 본인이 아무리 추상화가가 아니라고 주장한들 그는 위대한 추상화가입니다.

공학과 추상화

추상화는 예술에 국한하지 않습니다. 사실 모든 것에 있습니다. 사람은 무엇인가를 파악하는데 기본적으로 추상화를 활용합니다. 지금도 눈에 보이는 모든 것에 추상화를 적용하고 있습니다. 여백과 글자를 구분해서 인식하는 과정도 추상화를 활용합니다.

이것이 정말 글자입니까? 아닙니다. 특정한 방식으로 모여있는 선들에 글자라는 이름을 붙인 것 뿐입니다. 선이 정말로 선입니까? 아닙니다. 점들이 특정한 방식으로 모여있을 뿐입니다. 점은 정말로 점입니까? 아닙니다. 디스플레이의 픽셀일 뿐입니다. 픽셀은 정말 픽셀입니까? 아닙니다. RGB색을 낼 수 있는 발광체의 군집일 뿐입니다. 정말 이것이 발광체의 군집입니까? 아닙니다... 모든 것은 결국 추상화를 통해 만들어진 생각입니다. 이것은 파이프가 아닙니다.

《이미지의 배반》(La trahison des images), 르네 마그리트, 1929

추상화가 모든 것에 있다는 말도 사실 거짓말입니다. 추상화는 당신의 마음 속에 있습니다. 당신 마음의 문제입니다. 깃발이 바람에 흔들리는 것처럼 보인다면, 흔들리는 것은 깃발이 아니라 당신의 마음입니다.

정말 끝도없이 내려갈 수 있습... 사실 다행스럽게도 끝은 있습니다. 양자역학에 따르면 물질의 최소 크기가 정해져 있기 때문입니다(카를로 로벨리의 ⟪보이는 세상은 실재가 아니다⟫ 참고). 여하튼 결국에는 양자 단위까지 내려갈 것입니다.

아래는 이와 관련해서 학부 시간에 가장 기억에 남았던 장표입니다. 한양대학교 이인환 교수님의 컴퓨터구조 강의 자료에서 발췌했습니다.

추상화와 복잡도 관리

그래서, 추상화가 복잡도 관리와 무슨 관련이 있는지...?

개발자들은 복잡한 코드를 이해하기 쉬운 관점으로 바라볼 수 있는 방법이 있다면 이를 더 손쉽게 다룰 수 있다는 것을 알게 됐다.

- 조영호, ⟪오브젝트⟫, 추천사(이일민 씀), 위키북스, 2019

덜 중요한 부분을 숨기고 더 중요한 부분만 남긴다면 코드를 이해하기 쉽게 작성할 수 있습니다.

태초에 모든 것이 시작할 때는 0과 1밖에 없었습니다. 그리고 0과 1의 형상에서 중요한 개념들을 뽑아내 단어를 붙여 어셈블리어를 만들었습니다. 단어와 숫자를 연결해서 문statement을 만들고, 여러 줄의 문statement이 나타내는 개념을 뽑아내 이름을 붙인 것들을 함수라고 불렀습니다.

0과 1을 이해하기 쉬운 관점으로 바라보기 위해 어셈블리어가 탄생했습니다. 어셈블리어를 이해하기 쉬운 관점으로 바라보기 위해 고급 프로그래밍 언어들이 탄생했습니다, 다시 이들을 바탕으로 새로운 언어들이 탄생했고 지금도 탄생하고 있습니다. 어떨 때는 기존의 언어를 더 추상화해서(Python), 어떨 때는 기존의 언어들보다 추상레벨을 낮추면서(Go) 이전의 언어들의 부족한 부분을 채워나가고 있습니다.

이들이 탄생한 근본적인 목적은 코드의 복잡도를 줄이기 위함입니다.

복잡도란 무엇인가

이제 복잡도를 명확하게 정의할 때가 된 것 같습니다. 복잡도를 정의하기 위해서는 먼저 정보에 대해서 정의해야 합니다. 정보란 무엇입니까?

'정보'라는 말은 오늘날 아주 다양한 의미로 쓰이고 있는데, 그 때문에 과학적 용법에서도 혼란이 생겨났습니다. 하지만 정보의 과학적 개념은 1948년 미국의 수학자이자 공학자인 엔지니어 클로드 섀넌Claude Shannon이 분명하게 했는데요, 아주 간단합니다. 정보란 어떤 것의 가능한 대안들의 수를 측정한 것입니다.

- 카를로 로벨리, 정보, 정의되지 않은 생각,보이는 세상은 실재가 아니다⟫, 쌤앤파커스, 2018, p234.

클로드 섀넌은 '정보 이론'이라는 새로운 장르를 구축한 천재 과학자입니다. 정보 이론을 바탕으로 카지노에서 돈을 쓸어담은 괴짜 과학자이기도 합니다(윌리엄 파운드스톤의 ⟪머니 사이언스⟫ 참조).

섀넌은 정보를 '어떤 것의 가능한 대안들의 수를 측정한 것'이라 정의했습니다. 여기서는 편의상 정보 대신 '정보량'이라는 단어를 사용하겠습니다.

정보량이란 어떤 것의 가능한 대안들의 수를 측정한 것

정보량이 많다는 것은 '가능한 대안들의 수'가 많다는 것입니다. '가능한 대안들의 수'가 많다는 것은, '어떤 것'의 후보군이 크다는 것이고, 이는 '어떤 것'의 실재를 파악하기 힘들다는 것, 즉 잘 모른다는 것입니다.

확률과 정보량의 관계

𝑁을 가능한 대안들의 수라고 합시다. 주사위는 6개의 경우가 있으므로 주사위의 정보량 𝑁은 𝟔 입니다. 마찬가지로 생일의 정보량 𝑁은 𝟑𝟔𝟓 입니다.

𝑆라고 쓰는 '섀넌 정보'의 정의는 𝑁(가능한 대안들의 수)에 밑이 2인 로그를 취한 것입니다. 이것을 조금만 가공하면 bit가 됩니다.

𝑆=𝘭𝘰𝘨𝑁

𝘭𝘰𝘨(𝟔) = 2.584962..., 𝘭𝘰𝘨(𝟑𝟔𝟓) = 8.511752... 입니다. 𝑁=𝟔인 정보량을 표현하려면 3bit가 필요하고 𝑁=𝟑𝟔𝟓인 정보량을 표현하려면 9bit가 필요합니다. 당연하게도 𝑁=𝟐𝟓𝟔인 정보량을 표현하려면 정확히 8bit, 즉 1byte가 필요합니다.

위 공식에 장난을 조금 쳐서,

𝑆=𝘭𝘰𝘨𝑁
𝑆=-𝘭𝘰𝘨(𝑁⁻¹)
𝑆=-𝘭𝘰𝘨(𝟣/𝑁)

어떤 확률에 음의 로그를 취하도록 변형합니다. 확률에 음의 로그를 취하면 이에 관한 정보량을 기술하기 위해 필요한 bit의 개수가 나옵니다. 확률이 낮으면(=가능한 대안들의 수가 많으면) 정보량이 늘어납니다.

엔트로피를 이용한 객체 지향 프로그램의 복잡도 척도

정보 이론에서 엔트로피란 '정보량의 평균'을 말합니다. 여기서 엔트로피란 열역학의 엔트로피와 동일합니다. 엔트로피가 높으면 복잡도가 높고, 엔트로피가 낮으면 복잡도가 낮습니다.

어려운 단어가 등장하는 것 같지만 고등학교 1학년 수학 수준으로 이해할 수 있는 내용입니다. 정보량의 평균은 평균의 정의에 따라 '(정보량 * 확률)의 총 합'이라고 말할 수 있습니다. 다음과 같은 확률질량함수 𝒑ᵢ에 대해서,

sum-probability-function

개별 확률의 정보량은 -𝘭𝘰𝘨(𝒑ᵢ) 입니다. 𝑆=-𝘭𝘰𝘨(𝟣/𝑁)에서 𝟣/𝑁의 자리에 𝒑ᵢ를 대입했을 뿐입니다.

정보량의 평균은 '(정보량 * 확률)의 총 합'이므로, 엔트로피는 -𝘭𝘰𝘨(𝒑ᵢ)에 확률을 곱해 모두 더한 것과 같습니다.

확률을 곱하고 → -𝒑ᵢ𝘭𝘰𝘨(𝒑ᵢ)

모두 더합니다

sum-probability-function

이제 정보 엔트로피의 정의를 통해 복잡함이 무엇인지 알 수 있습니다. 복잡하다는 것은 '정보량이 많은 것'이고, 정보량이 많다는 것은 '어떤 것의 가능한 대안들의 수'가 많다는 것이고, 어떤 것의 가능한 대안들의 수가 많다는 것은 어떤 것이 될 수 있는 '후보군이 크다'는 것이고, 후보군이 크다는 것은 '경우의 수가 많다'는 것입니다.

복잡하다는 것은 고려해야 할 경우의 수가 많다는 것입니다.

엔트로피를 가지고 말장난을 한 것이 아닙니다. 실제로 엔트로피를 이용한 객체지향 프로그램의 복잡도 척도를 제시한 논문이 있습니다.

좋은 설계란

해결 방법은 간단하다. TheaterAudienceTicketSeller에 관해 너무 세세한 부분까지 알지 못하도록 정보를 차단하면 된다.

- 조영호, ⟪오브젝트⟫, 설계 개선하기, 위키북스, 2019, p18

어떤 정보를 가지고 있으면 정보량을 고려하지 않아도 됩니다. 누군가의 생일을 알고 있다면 𝑁=𝟑𝟔𝟓인 정보량도 무섭지 않습니다. 정보를 가지고 있으면 필요한 정보량이 적고, 필요한 정보량이 적다는 것은 모르는 부분이 적다는 것입니다.

1년이 단 이틀이라면 어떨까요? 사랑하는 사람의 생일이 생각나지 않더라도(ㅜㅜ) 𝑁=𝟐인 정보량만 상대하면 되니 훨씬 마음이 편합니다.

마찬가지로 클래스가 클래스 사용자에게 최소한의 정보만 노출하면 사용자의 마음이 편합니다. 애초부터 정보를 차단해서 사용자가 선택할 수 있는 경우의 수를 적게 만들면 복잡하지 않은 설계가 됩니다.

아이러니하게도 정보 기술(IT) 분야의 설계를 잘 하기 위해서는 정보를 차단해야 합니다.

새로운 관점으로 경우의 수를 줄이자

결국 복잡도를 줄인다는 것은 경우의 수를 줄인다는 것입니다.
공학에서 어떤 기술의 쓸모에 관한 최종적인 판단 기준은 경우의 수를 얼마나 줄일 수 있는가에 있습니다.

이것으로 관통합니다.

(원문보기)

-->