설계란 결국 번역인가?
설계: 생각을 ‘차려’ 물질로 만드는 힘
이제 질질 끌어온 물음에 대해 따져서 풀이를 내놓을 때가 되었다고 마음을 먹었습니다. 페북으로 <모델링에 대한 메타 인지: 모델링이라는 생각 차림법>을 소개할 때 페벗 이순석 님의 댓글이 만들어 준 질문입니다.
댓글을 읽는데 다 소화하기도 전에 이런 질문이 솟았습니다.
설계란 결국 번역인가?
각자의 고유한 생각차림법
시간이 흐르고 다른 글을 쓸 때도 같은 질문을 다시 떠올렸는데 여전히 생각이 명확하지 않았습니다. 그렇더라도 지금까지 이해한 바를 기록하고 노출하는 일이 유익하다는 생각이 들었습니다. 다시 페벗님 댓글을 보자 결심하기를 잘했다는 생각이 들었습니다. 그러고 나서 의식을 흐름에 맞춰 타이핑을 계속했는데, 마음에 들게 정리가 되지 않아 우선 현재 할 수 있는 수준으로 먼저 일단락하기로 합니다.
지난 글에서 아래 이미지를 이미 인용했으면서도 각자의 고유한 '생각 차림법'에 대해서는 분명하게 인지하지 못했습니다. 서로 인식이 다르다는 점에만 초점을 맞춘 것이죠.[1]
생각 차림법은 결국 개성의 산물이거나 적어도 개성과 일대일 대응을 이룰 것입니다. 개성이라고 하면 저는 자주 인용하는 저희 아들을 멀리서 물끄러미 바라볼 때 그의 고유함에 대해 느끼는 감정이 우선합니다. '기억이란 개별화하여 가치를 부여하는 과정'이라는 박문호 박사님의 설명도 생각 차림법이 개인마다 고유함을 지지합니다.
현상적 세계와 물리적 세계를 구분하기
그리고 페벗님의 매듭말[2]에서 그 형식에 있어 객관이 필요한 물리 세계와 다르다는 의미를 읽을 때는 자동적으로 <현상적 세계와 물리적 세계를 구분하기>를 떠올립니다.[3]
그래서, 현상적 세계와 물리적 세계를 구분한다는 말은 프로그래밍 맥락에서는 자신의 생각과 선호하는 방법이 주관적이란 사실을 분명하게 인식하는 일에서 시작해야 할 듯합니다. 거기에서 출발해 스스로가 공동체에 유익하다고 믿는 방법으로 확산해 나가는 길에 설계가 쓰인다고 여겨집니다.
어떻게 공동체에 유익하다고 믿는 방식을 확산할 것인가?
자, 그렇다면 확산은 어떻게 할 수 있을까요? 확산을 고려할 때 생각은 크게 두 방향으로 발산해 나아갈 수 있습니다. 하나는 이미 <자기중심에서 팀 중심으로 확대하기>에서 썼던 방식입니다. 그리고 Kent Beck의 책 <Tidy First?>를 번역하면서 익숙해진 '인간관계 속의 활동'이라고도 할 수 있겠죠.
출처: https://youtu.be/XmsyvStDuqI?si=F-TTtul-LOFauUMn다른 하나는 물리적 구현이 가능한 방식으로 나아가야 한다는 점입니다. 설계란 결국 생각을 차려서 물질로 만들어 냈을 때 사회적 가치가 증명됩니다. 제 선호와 무관하게 우리는 모든 결과에 대해 돈을 매개로 가치 평가받는 세상에 살고 있으니까요.
두 개의 축에 대해 이름을 붙이는 일이 쉽지 않습니다. 아마도 제 머릿속에서 그 경계가 아직 어슴푸레한 탓인 듯합니다. 일단 두 축을 '소통'과 '가치'로 나눠보겠습니다.
마음이 움직이지 않으면 논리는 소용없다
소통 축의 존재 이유는 누군가의 주관적 생각을 다른 사람이 이해하고 받아들이지 않으면 협업이 어렵고, 인간 활동은 대체로 언어를 활용해 마음을 움직이는 일에 기초하기 때문입니다. 배경이 있는 주장인데, 먼저 묻따풀을 하며 배운 '녀겨서 니르기'라는 말의 본질적 기능에 대한 이해입니다.
그리고 그 말의 꼴뿐만 아니라 까닭과 흐름이 있어야 하고 동시에 마음을 움직일 수 있어야 한다는 사실은 <당신이 옳다>를 이해하려고 노력한 꾸역꾸역의 시간이 없었다면 알 수 없는 지식이었습니다.
이에 대해서는 부연하고픈 내용들이 있지만, 다른 하나의 방향성부터 먼저 설명해 봅니다. 두 번째 축은 바로 가치인데요.
소프트웨어는 두 가지 방식으로 가치를 만든다
역시 번역 과정에서 썼던 <소프트웨어는 두 가지 방식으로 가치를 만든다> 내용을 활용할 수 있습니다. <Tidy First?>에서 Kent Beck은 동작 수정과 구조 개선(그림에서 '설계'라 표기)을 가치 생산 방식으로 대별합니다. 동작 수정은 개발자가 아니더라도 눈에 보이고 사용할 수 있기에 참여와 소통이 가능합니다. 하지만, 개인의 주관보다는 만드는 이들 사이에서 합의한 기능 집합이 시장에서 가치를 증명하며 점차 커져 갑니다. 이런 방식을 MVP(Minimum Viable Product)라고 하지만, 개념적으로 그러할 뿐 MVP 단위로만 코드가 성장하지는 않습니다.
그리고, 개발자들만 볼 수 있는 코드의 형상이 있습니다. <Tidy First?>가 다루는 대상이지만, 이는 개발자들 사이의 '인간관계 속의 활동'의 결과와 서비스 운영 과정에서 하드웨어와 네트워크 구성 위에서 벌어진 사용자 이벤트에 따른 대응 활동에 따라 앞으로 나아갑니다.
계산 가능한 것으로 나아가게 해야 생존하는 팀
여기서 결론에 도달하기 위해 다시 한번 <생명의 위대함에 대하여...>에서 인용했던 이순석 님의 글을 활용합니다.
위 포기말을 소프트웨어 설계 맥락에서 읽으면 의미가 더욱 분명해집니다. 소프트웨어는 가치를 획득하려면 반드시 '계산 가능한 결과'를 내놓아야 합니다. 그리고, 소프트웨어를 생산하는 조직도 생명을 획득하려면 계속해서 계산 가능한 결과를 내놓아야 합니다. MVP의 Viable이란 단어도 이러한 의미를 내포하고 있습니다.
계산의 차원과 분별을 구조화하는 관점
앞서 언급한 주관에 따른 서로 다른 생각차림법을 가진 사람들이 협업을 하려면 번역이 필요합니다. 서두에 언급한 페북 대화에서 '번역'이란 말을 듣자 기계적으로 떠올랐던 4+1 view의 기원을 찾아보았습니다. 그랬더니 View model을 찾을 수 있었습니다.
View의 정의가 관련된 관심사 집합(a related set of concerns)에 상응하는 관점(perspective)이라고 합니다. 이들 사이의 번역이 설계라고 할 수 있을 듯합니다. 한편 흥미롭게도 이순석 님의 다른 페북 글에 등장하는 분별과 차원을 각각 'view'와 'perspective'에 일대일대응시킬 수 있을 듯합니다.
동일한 대상에 대한 분별할 수 있는 서로 다른 생각(인식)들의 가짓수로 정량화할 수 있다. 그런 분별은 세상을 읽는 차원을 기반으로 계산 가능하다.
그래서, 설계란 결국 번역인가?
만족스러운 정리는 아니지만, 이 글을 시작으로 정의를 해나가려고 씁니다. 설계란 결국 번역인 듯합니다. 그런데 무엇과 무엇의 번역이냐? 먼저 번역 이전에 일군의 관점을 구성하는 요소들과 그 관계를 계산 가능한 차원에 준하게 표현하는 일에서 시작할 듯합니다. 이는 어쩌면 모델링을 보는 또 다른 정의가 될 듯합니다. 그 결과물이 관심사가 다른 사람들 혹은 다른 관점이나 차원으로 표현할 수 있을 때, 이들 사이에 번역이 필요해집니다. 그래야 그러한 관심사를 모두 아우르는 계산 가능한 결과에 도달하기 용이하기 때문이죠.
주석
[1] 나눠서 푼다는 Divide and Conquer의 약점을 새로운 관점에서 다시 확인합니다. 더불어 제가 쓴 글을 다시 읽으며 확인하는 일의 유용함을 또 확인합니다.
[2] <한국말 말차림법>에서 제안한 어구에 대한 토박이 말입니다. 왜 매듭말인지는 <언어에 대한 일반이론>에서 일부 답을 얻을 수 있습니다.
[3] 이런 현상이 몇 년을 지식 덕후로 살아온 현상인 듯합니다.
지난 설계: 생각을 ‘차려’ 물질로 만드는 힘 연재
1. 내가 아닌 다른 사람은 모델링을 왜 하게 되는가?
4. 설계가 잘 쓰이려면 독자와 쓰임새가 분명해야 한다
7. Event Driven의 기원과 현실적인 활용 방법
8. 모델링에 대한 메타 인지: 모델링이라는 생각 차림법
