길이 -> 표면적 -> 부피
얼마 전 프로그래머를 위한 범주론에서 함수 합성의 유용성에 대한 글을 읽고 깊은 인상을 받았습니다.
계층적인 분해와 재합성의 과정은 컴퓨터가 우리에게 강요하는 것은 아닙니다. 이는 인간이 할 수 있는 생각의 한계를 반영하는 것입니다. 우리의 뇌는 한 번에 적은 수의 개념만 받아들일 수 있습니다. 이와 관련되어 가장 많이 언급되는 심리학 논문은 우리가 생각할 수 있는 정보 청크의 수는 7 ± 2 라는 내용의 마법의 수 칠, 더하거나 빼기 이(The Magical Number Seven, Plus or Minus Two)입니다. 인간의 단기 기억에 대한 세부 사항은 다를 수 있지만, 우리 모두 그게 한정돼있다는 것은 알고 있습니다. 핵심은 우리가 잡탕처럼 섞인 객체 혹은 스파게티처럼 얽힌 코드는 이해하기 어렵다는 것입니다. 한 마디로 프로그램이 보기 좋으라고 구조를 잘 짜는 것이 아닌 우리의 뇌의 효율적인 이해를 위해 구조를 잘 짜야한다는 것입니다. 우리는 종종 어떤 코드를 보고 우아하거나 아름답다고 말하지만, 이는 쉽게 말하자면 그냥 한정된 인간의 생각이 잘 처리할 수 있다는 것을 의미합니다. 우아한 코드는 우리의 정신적인 소화 체계가 잘 이해할 수 있도록 적합한 사이즈와 적절한 숫자의 청크를 만듭니다.
그래서 프로그램 합성의 적절한 청크는 뭘까요? 표면적은 부피가 늘어나는 속도보다 느립니다. (저는 이 비유를 좋아하는데 왜냐하면 기하학적으로 표면은 사이즈의 제곱의 값과 같이 늘어나고, 사이즈의 세제곱 값을 가지는 부피보다는 느리게 늘어나기 때문입니다) 면적은 청크를 합성하기 위해 알아야 할 정보라고 볼 수 있습니다. 그리고 부피는 그것을 구현하기 위해 알아야 할 정보라고 볼 수 있습니다. 아이디어는 이렇습니다. 청크가 구현되면 우리는 이것의 구현을 잊고 다른 청크와 어떻게 작동하는지에만 집중할 수 있습니다. 객체 지향 프로그래밍에서는 이 표면이 객체의 클래스 정의 또는 추상 인터페이스입니다. 함수형 프로그래밍에서는 함수의 선언이 표면이 되겠습니다. (많이 생략했지만, 요지는 변함없습니다.)
사실, 내용은 모듈화에 관한 내용이 실린 책에서 많이 언급하는 내용이었지만, 길이와 표면적, 부피 단위로 정보량이 증가한다는 비유가 잘 와닿았던 것 같습니다.
작업을 하거나, 작업에 관한 대화를 할때에도 층위에 따른 정보량의 차이를 많이 느끼는 것 같습니다. 거칠게 대응 시키자면, 다음과 같이 연결할 수도 있을 것 같습니다.
- 왜 하는가 -> 길이
- 무엇을 하는가 -> 표면적
- 어떻게 하는가 -> 부피
그래서 앞의 두개를 빼놓고 '어떻게'에 관해서만 이야기를 듣거나 말하는 경우에는, 정보량이 많아서 목적이 무엇인지 정리하기가 힘들고, 무엇이 문제인지 되묻는 경우가 많은 것 같습니다.
짝프로그래밍을 하다보면 특히, 서로 생각하는 것과 보고 있는 것이 달라서, 의견을 말하다 보면 맥락 전환이 자주 일어납니다. 이때에도 '어떻게'에 관한 이야기로 시작하면 소통이 매우 힘들어지는 것 같습니다. 체크리스트를 통해서 정보량을 잘 관리하고, 새로운 맥락이 출현하면 리스트에 올려놓고, 충분히 집중할 수 있을때 처리하는 등의 전략을 잘 지켜야 겠다는 생각이 듭니다.
