흥미로운 Tidy First 고찰
<Kent Beck의 Design Play가 무슨 말인가> 편을 페북에 공유하자 페벗인 Raymond Hyuksoo Jang님이 다음과 같은 댓글을 주셨다.
사실 Tidy Fist가 책으로 나오면 볼 생각으로 가끔 Kent Beck이 쓰는 글을 훑기는 하지만 제대로 이해하려는 노력을 하지는 않았는데, 페벗님이 링크로 전해주신 글은 시간을 들여 한번 읽어 보고 싶었다. <Tidy First? Daily Empirical Software Design & Why It Works>라는 글의 저자 ULYANA PALIYCHUK는 나와는 제법 다른 백그라운드를 가진 사람으로 보였다.
Ulyana is a writer with a marketing background, experienced in research and fact-checking. She likes to write about digital tech and innovation and is keen on traveling, music, and coffee.
Software design is an exercise in human relationships.
Kent Beck의 글을 인용한 이 문장(소제목)은 내가 대략 10 년쯤 전에 두 번째로 펼쳐든 XP Explained에서 그가 원칙으로 제시한 인간성(humanity)에 대한 장을 읽을 때의 충격을 떠올리게 했다. 마침 점심시간에 산책을 하며 XP를 읽는다는 동료에게 그 소감을 말한 일이 있었다.
나도 모르게 사람들이 내는 성과에 초점을 맞추느라 사람을 소외시키는 내 생각과 행동의 바탕을 완전히 바꿔야 한다는 충격을 느꼈다. 우리는 성과를 내도록 의무감에 쌓이기 이전에 있는 그대로의 사람이라는 사실을 먼저 상기해야 한다.
위 글은 XP 내용이 아니라 10여 년 전에 내가 느낀 충격에 대한 기억을 지금에 떠올려 본 현재 나의 해설이다. 기술 문제라는 자기규정에 갇히지 않는다면 우리가 일하는 과정은 결국 인간의 상호작용이란 점을 받아들일 수 있다. 그와 관련한 문구를 찾을 수 있다.
성공적 대화를 돕는 그림 응용하기
일단, 원문에서 아래 단락을 인용한다.
At first glance, software development has little to do with social relationships. It is about coupling, cohesion, power laws, refactoring, etc. — the code. But is it? Viewing software design through the prism of human relationships, we can narrow the scope to exploring the interactions between the tech people (geeks) and non-geeks.
그리고 내가 이 글에 대한 이해를 성공적 대화를 돕는 그림을 응용해서 표현해 본다.
기술자(Geek)들이 coupling, cohesion, refactoring 등을 기술자가 아닌 사람에게 '중요하다'라고 설명하는 경우가 종종 있다. 어떻게 내 의도를 전달할 수 있을까? 소통 가능한 대화를 실행하는 일은 생각보다 어렵다.
이런 사회적 전달이 중요하다는 믿음을 가진 사람만이 동기가 생겨 도달할 수 있는 경지라고 할 수도 있다. 누가 말이 통하지 않는 사람과 즐겨 대화를 하려고 하겠는가? 나는 소통의 스킬 이전에 입장과 동기 같은 것들이 갖춰줘야 한다고 믿는다. 그게 인간의 상호작용의 바탕이다. 너무나 내 주장으로 흘러가기 전에 다시 원문으로 돌아가 보자.
따로 또 같이 - loosely coupled
나는 아래 그림을 보자마자 Kent Beck의 창의성과 핵심만 뽑아내는 표현력에 감탄하며 입가에 미소를 띠지 않을 수 없었다.
그리고 나는 반사적으로 loosely-coupled를 떠올리지 않을 수 없었다. loosely-coupled는 유기체를 조직화하는 힘이자 따로 또 같이 일할 수 있는 구성 방법이다. C는 Changer를 뜻하며, 기술자가 아닌 사람들이 보기에는 마법사 같은 존재다. 그들을 믿고 기다려야 하는 W는 아마도 개발팀의 주요 이해관계자일 것이다. 그리고 선으로 묘사된 부분은 관계를 의미하는 듯하다.
(아마도 시간과 비용을 제공하며) Changer들을 기다려준 이들은 기대감에 대한 만족 여부에 따라 관계의 신뢰와 긴장이 변화할 것이다. 그리고 개발자 내부의 관계를 설명할 때, 내 머릿속에서는 '정치'란 단어가 떠오르고 과거에 이를 묘사했던 나의 글을 찾을 수 있었다.
자신의 개선 제안에 많은 동료들이 지지를 보내자 노력을 아끼지 않습니다. 민주적 소통 절차는 분명하게 협업에 탄력과 활기(?)를 불어넣습니다. 한국 문화를 고려하면 민주적 소통 진행에 있어 꼭 필요한 요소는 디지털 기록입니다. 이때, 지지를 받은 동료는 광장에서 동료들에게 자신의 주장을 관철하기 위해 기록을 남기는 수고를 마다하지 않습니다. 독자분들께 민주적 소통 절차를 인지시켜 드리기 위해 일부러 광장이라는 은유를 사용했습니다. 느껴지시나요? 왜 활기가 필요한지? 공감하시나요? 왜 민주적이라 표현했는지?
프로그래머 자신과의 관계
아래 문장을 볼 때는 Kent Beck의 독창성을 느끼게 한다.
그리고 최근에는 점수(漸修)라는 종교적 개념과 XP의 유사점을 풀어낸 <나만 잘하면 전체가 나아지는 XP> 편이 떠올랐다. 인간성이라는 원칙을 믿고 따른다면 우리가 바꿀 수 있는 것은 나 자신의 말과 행동뿐이다. 다른 사람에게 의사소통이나 솔선수범을 통해 영향을 끼칠 수는 있지만, 우리가 원하는 대로 그들을 바꿀 수는 없다. 아니 바꿔서는 안 된다.
이때 가장 먼저 챙겨야 할 사람은 바로 나 자신이다. 프로그래머로써의 임무가 아니라 개성을 갖춘 나 말이다. 2019년 흥미롭게 읽었던 <관계를 읽는 시간>이라는 책이 있다. 그 책에는 인간관계로 고생하는 사람들을 상담해 온 전문가가 자신이 경계 설정의 중요성을 설파한다.
나는 이런 자기 인식을 통해 정서적 안정감을 갖췄을 때 다른 이들과도 그들의 개성(자아)을 인정하며 건강한 상호작용을 할 수 있다고 믿는다. 사실 XP의 '인간성' 원칙이 나에게 전해준 충격이 10 년이 흐르는 동안 어떻게 발전해왔는가에 대한 글일 수도 있다.
그리고, Kent Beck의 다른 문장을 보면서 계속해서 그의 사상의 근저를 XP에서 찾는 일도 나의 경험에 근거한다.
About tidying
그리고 Kent Beck은 압도적인 복잡도의 코드를 수정해야 할 때 느끼는 두려움에 대처하는 노하우를 말한다.
XP에서 배워 오랫동안 설파하고 다니던 '아기 발걸음'에 대한 이야기와 크게 다르지 않다. 다만, 내가 쓴 글들은 새로운 일과 막막한 일을 풀어가는 방법에 대해 주로 썼고, Kent Beck은 코드 변경을 인간적으로 (나에게 큰 상처를 주지 않고) 해낼 수 있는 방법에 초점을 맞춘 차이가 있다.
그리고 그는 눈에 보이는 기능(behavior) 변경과 눈에 보이지 않는 구조의 상호작용에 대해 설명한다. 이 지점에서 다시 한번 프로그래머 자신과의 관계에 대해 떠올리지 않을 수 없다.
XP에서 Kent Beck이 언급한 인간성을 구성하는 요소는 기본적인 안전, 성취감, 소속감, 성장, 친밀감 같은 것들이 있다. 그림에서 붉은색 선으로 표기한 상호작용이 압박감과 좌절로 흐를 수 있다는 생각을 한다 예를 들어 주어진 시간이 촉박하면 구조 개선이 필요한 줄 알면서도 어쩔 수 없이(?) 보이는 기능 위주로 수정하며 내면에 상처를 방치할 수 있다. '기술 부채'에 대한 글을 쓴 이유도 그런 현상을 자주 보아온 탓이다.
하지만 인간적인 상호작용을 통해 우리는 프로그래머로써 점진적으로 붉은색 선을 압박감에서 노는 듯한 일로 바꿔갈 수 있다. '노는 듯한'이란 표현은 아마도 얼마 전 썼던 'Design Play'의 영향이 아닐 수 없다. 이를 통해서 우리는 압박을 극복하며 '기본적인 안전'을 경험할 수 있고, 그 과정에서 기다리는 사람들과 '소속감'을 향상할 수 있다. 그리고, 아이디어가 발전하면 전에 없던 구조를 만들어내는 과정에서 '성장'을 느낄 수 있고, '성취감'을 얻는다. 그 과정에서 아이디어를 공유하는 상대가 생긴다면 '친밀감'도 느낄 것이다.
빠른 피드백 루프의 힘
Kent Beck은 구조와 행위의 상호작용에서 한쪽에 치우치는 실수가 벌어질 수 있다고 지적하면서, 그에 대한 해법으로 피드백 루프(a rapid iteration should exist in all of the above feedback loops)안에 잦은 반복이 있어야 한다고 강조한다.
나는 릴리즈의 힘을 믿는다. 소프트웨어 개발이 인간적인 상호작용의 일종이라고 믿는다면 개발을 둘러싼 이해관계자들이 함께 합의할 수 있는 기반이 필요하다. 그것이 코드만으로 이뤄질 수는 없다. 각자의 입장에서 경험하고 이해할 수 있는 어떤 소통 장치가 필요하다.
하지만, 릴리즈가 되지 않고서는 기술자가 아닌 사람들이 자신에게 소프트웨어 수정 내용이 무엇을 말하는지 어떻게 할 수 있나?
원문과는 조금 다른 결론
원문에서는 Kent Beck의 Tidying First에 대해 조금 더 설명하고 결론에 도달한다. 전체적인 흐름에 대해서는 동의하지만, 경험이 뒤따르지 않아 충분히 이해했다고 말하지는 못하겠다.
그래서 조금 다르게 내 소감으로 결론을 내린다. 나는 상충관계가 드러나는 협의체를 만들려고 노력한다. 건강한 긴장으로 상호이익을 추구하고 공동의 목표를 향해 나아갈 수 있는 협업 기반이라고 믿는다. 하지만, 결정이 난 후에는 각자의 영역에서 안정감을 갖고 조화를 스스로 만들 수 있도록 위임한다. 당장은 비효율이 보이더라도 '지속 가능성'에 무게를 둔다면 그렇게 해야 한다.
이 글을 쓰기 직전 통화한 내용과 일맥상통에 흥미롭다는 생각이 든다. 나는 함께 일하는 사업 파트너와 대화를 하면서도 이러한 협업 방식을 떠올리는 대화를 했기 때문이다. 크로스보더 물류 현장에서 주요한 쓰임새(Use Case)에 대한 결정은 커머스를 하는 파트너가 결정하고, 어떤 구조로 가져갈 것인지에 대한 결정권을 나에게 주는 구조라면 상품화할 수 있는 IT 제품이 만들어진다는 나의 믿음을 그에게 통화로 말한 것이다.
다시 말해서 나는 Kent Beck이 언급한 프로그래머 나 자신과의 관계 정립부터 온전히 유지하고, 그렇게 바운더리를 인정한 개체의 조직화라는 자연의 모양새를 고스란히 유지하면, 다층으로 짜여진 기업체와 기업 연합을 만들 수 있다는 생각을 믿는다.
