대상과 조건 그리고 자기 속도에 부합하는 조건 만들기
한국의 마틴 파울러가 되기
페벗 김진호 님의 <조건, 시간과 속도>란 글은 영감을 주는 글입니다. 물론, 건축을 전혀 모르는 나에겐 생소한 상황들을 배경으로 쓰인 글이지만 묘한 여운을 주었습니다. 그래서, 처음 글을 보고 난 뒤 며칠 후에 다시 읽어 보며 받은 영감을 사용해 내 쓰임에 맞는 글로 기록합니다.
어쩐 일인지 아래 문단은 읽고 또 읽게 되었습니다.
건축을 이루는 여러 가지 조건들이 있다. 조건은 대상이라고 해도 좋다. 대상들이 조건을 만들기 때문이다. 재료, 날씨, 사람, 돈, 시간, 공법 ... 모든 것이 조건이며 대상이 된다. 나 자신의 몸과 마음도 역시 하나의 조건이며 대상이다.
대상들이 조건을 만든다
나를 잡아 끄는 이유가 뭘까 한참 생각해 보니 '건축'이라는 맥락을 벗어나면 답이 금방 나왔습니다.
조건은 대상이라고 해도 좋다. 대상들이 조건을 만들기 때문이다.
자연스럽게 객체 지향이 나를 찾아왔습니다. 그래서, 이 글도 '한국의 마틴 파울러가 되기'에 넣는 것이죠. 프로그래밍에 푹 빠져 살던 1999년 마틴 파울러가 쓴 UML Distilled를 쓰고 선배 권유로 인터넷에 UML 강좌를 올린 일이 있습니다. 강좌를 올린 사이트가 문을 닫으면서 강좌 내용은 인터넷으로 급속도로 퍼져 나갔습니다. 암튼, 이 글은 영감을 주신 김진호 님의 원문과 달리 '객체 지향'을 다루면서 머릿속에 담아 두었던 생각을 끄집어내는 계기가 될 듯합니다.
객체 지향 관점을 투영하여 아래 문장을 읽으면
조건은 대상이라고 해도 좋다. 대상들이 조건을 만들기 때문이다.
저는 다음과 같이 활용 혹은 번역할 수 있었습니다.
객체가 실행하기 위한 조건은 의존성(dependecies)이라고도 한다. 조건은 대상으로 식별한 다양한 객체들의 조합이다.
하나씩 풀어 봅니다.
대상(對象) 대신 객체
어떤 면에서 프로그래밍 기술은 컴퓨터에 대한 의존을 낮추고 추상적인 표현력을 키우는 방식으로 발전해 왔습니다. 기계어에서 프로그래밍 언어가 나온 것도 그러하고, 클라우드 세상을 만든 배경에는 가상화(virtualization) 기술과 네트워크로 엮인 프로그램을 하나로 돌아가게 하는 분산 프로그래밍 기술이 있습니다. 지난 시간에 다룬 '현실과 시스템의 불일치'라는 주제도 그러고 보면 끊임없이 그 '불일치'를 줄이는 방향으로 인류가 진보의 방향으로 나아가는 듯도 보입니다.
제가 느슨하게 '객체 지향'이라 부르는 일종의 프로그래밍 기법이자 설계 기법도 마찬가지입니다. '객체 지향'에 대한 정의는 뒤로 미루고, 이 글에서는 객체 지향 역시 '추상적인 표현력을 높이는 프로그래밍 기술'이라는 점만 분명히 하겠습니다.
객체는 대상이라는 말로 치환해도 그 의미가 크게 훼손되지는 않습니다. 표준국어대사전에서 '대상'의 뜻을 찾아보겠습니다.
색을 칠한 내용을 인용하면, '객체 지향의 객체'와 의미가 잘 통합니다. 프로그래머(혹은 설계자)가 관심의 대상을 개념(설계)이나 언어(프로그래밍)로 표상한 것이 바로 객체니까요.
의존성은 객체가 실행하기 위한 조건
이런 대상들이 모여 조건을 이룬다는 김진호 님의 '건축에서의 인식'과 마찬가지로 프로그래밍 세계에서도 이런 대상 혹은 객체들이 모여 조건을 이룹니다. 조건이란 특정 객체가 구동하기 위한 조건을 말합니다. 이런 조건이 반복적으로 드러나는 잘 알려진 패턴이 두 개 있습니다.
소프트웨어나 앱을 구동할 때 요구사항이 명시되는 경우를 보신 일이 있을 것입니다. 그리고 프로그래머면 모를 수가 없는 의존성(Dependencies)이 있습니다. 내가 가져다 쓸 대상(객체)이 있다면 반드시 선행해야 하는 작업이라는 점에서 '조건'입니다. 이러한 조건을 정형화한 dependency injection이라는 설게 패턴이 있을 정도입니다.
조건은 보통 다수의 대상으로 이뤄진다는 사실을 아는 프로그래머들은 이 정도 설명이면 아래 문장에서 제가 받은 영감이 어떻게 프로그래밍 맥락의 의미로 치환되는지 감을 잡을 수 있을 것이란 생각이 듭니다.
건축을 이루는 여러 가지 조건들이 있다. 조건은 대상이라고 해도 좋다. 대상들이 조건을 만들기 때문이다. 재료, 날씨, 사람, 돈, 시간, 공법 ... 모든 것이 조건이며 대상이 된다.
대상을 깊게 만나자
여기서 이야기를 어느 방향으로 진행할까 잠시 고민을 했습니다. 두 가지 큰 갈림길이 머릿속에 있기 때문이죠. 그중에서 김진호 님의 인용문이 주는 영감을 따라가는 쪽을 택하겠습니다. 최초 인용문에서 마지막 문장이 있습니다.[1]
나 자신의 몸과 마음도 역시 하나의 조건이며 대상이다.
보통 '객체 지향'을 다룰 때 '나 자신의 몸과 마음'은 조건이나 대상으로 다루지 않았습니다. 이 글을 쓰면서는 어떤 태도를 취할까 고민에 빠져 봅니다. 생각이 분명하지 않아 다시 페벗 님의 다음 문단을 인용합니다.
나는 건축을 통해 대상을 '깊게 만나는 것'을 선호한다. 그래서 '정성스럽게 일에 집중'하려고 한다. 그 시간을 온전히 대상에 집중하고 대상을 만나려고 하는 것이다. 대상과 깊이 만날 때, 말로 표현하기 어려운 평화로움과 행복감이 생겨난다.
일을 좋아하는 저 역시 일을 하며 대상을 '깊게 만나는 것'을 선호합니다. 그런데, 과거에 '객체 지향'을 할 때는 그렇지 못했던 듯도 합니다. 그래서 이 글이 반성의 시간을 줄 수도 있고, 새로운 창발을 불러올 수도 있다는 기대를 하게 됩니다.
기술 부채를 어떻게 대할 것인가?
하지만, 현실은 대상을 깊게 만나지 못하게 하는 듯합니다.
대상을 깊이 만나지 못하게 하는 조건들이 있다. 건축에서 대상을 온전하게 만나지 못하게 하는 가장 강력한 조건을 꼽자면, '돈'과 '시간'이다. 둘은 사실 같은 것의 다른 측면을 말한다고 볼 수 있다. '돈'과 '시간'의 조건을 세게 걸면 대상과의 깊은 만남이 어려워진다.
프로그래밍 세계에서도 '돈'과 '시간' 문제로 대상을 온전하게 만나지 못해 발생한 결과를 '기술 부채'라고 부릅니다.
오호... 페벗 님의 글이 기술 부채 대응에 대한 영감을 줄 수 있을까요?
대상을 만나는 데는 적당한 자기 속도가 누구나에게 있다. 자기 몸과 마음을 핸들링할 수 있는 속도를 넘어서면 대상을 온전하게 만날 수 없게 된다. 경험이 쌓이고 시간이 쌓이면 일정이상 속도가 빨라지고 만날 수 있는 대상의 범위도 점점 넓어진다.
위 문장은 개인 차원과 조직(팀) 차원으로 나눠볼 수 있을 듯합니다.
자기 속도를 알고 있는가?
저는 TDD를 익히기 전까지는 내 개발 속도를 알지 못했습니다. 버거운 덩어리의 일을 나누지 않고 프로그램을 작성하는 일에 대해 문제의식이 없었습니다. 그러나, 지금 생각해 보면 그렇게 하면 긴장감과 압박감을 느낄 가능성이 높은 동시에 통제감과 편안함을 느끼기는 어렵습니다. 그런 노력이 필요하냐에 대한 생각 차이를 다룬 글을 최근 요즘IT에 올리기도 했습니다.
그 글에서 인용한 Kent Beck의 그래프와 같이 통제감을 인식하려면 반드시 자기 속도를 아는 일이 필요합니다.
자기 속도를 아는 사람이 팀에 있다면 그는 리더 후보가 됩니다. 자기 속도를 모르는 사람이 리더가 되려고 들면 서로 약속을 지키자는 절차를 강조할 수밖에 없습니다. '납기', '계약' 등이 강조되는 프로젝트 관리 맥락에서 일하게 됩니다. 그러나 문제는 자기 속도를 모르는 프로그래머들로 구성된 경우 실제로 약속을 지킬 수가 없어서 품질을 훼손하게 됩니다. 개인 차원에서 '기술 부채'가 쌓인 코드를 내놓습니다.
대가(大家)의 조건
아래 문단을 보며 '전문 분야에서 뛰어나 권위를 인정받는 사람'을 뜻하는 대가라는 표현이 떠올랐습니다.
건축에서 대상을 깊이 만나기 위해서 '돈'과 '시간'의 조건을 내가 감당할 수 있는 적당한 수준으로 제외시키는 것이 내 방식이다. 건축 방식은 개인적인 것이기도 하지만, 문화적이고 사회적인 것이기 때문에 생명력을 얻기 위해서는 긴 시간이 필요한 듯하다.
인용한 글은 추가적인 영감을 주면서 과거에 썼던 몇 개의 글을 소환합니다. 첫 번째는 역시 건축의 대가를 다룬 <프랭크 게리가 기한과 예산을 맞추는 법>입니다. 페벗 님의 글과 상황은 다르겠지만 비슷한 맥락의 이야기로 볼 수 있습니다. 두 번째는 <축적의 시간>에서 우리나라에는 대규모 프로젝트 파이낸싱 환경에서 개념 수준의 아키텍처를 조율할 역량을 아직 축적하지 못했다는 지적이 떠오릅니다.
주석
[1] 제가 익숙했던 생각의 흐름을 버리고, 우선 페벗님 문장이 주는 자극을 따라 새로운 이야기가 창발 하기를 기대하며 씁니다.
