<div id="readability-page-1" class="page"><div>
 Written by
 KimCoding

 
 
 on&nbsp;<time datetime="2019-09-19 00:00:00 +0900">September 19, 2019</time>
 
 

 <h2>설계의 중요성을 설명하기가 왜 어려웠을까?</h2>
 

 <img src="https://coderk.github.io/assets/images/new/photo-1515187029135-18ee286d815b.jpg" alt="사람들이 강의실에 모여있고, 가운데에 있는 여자가 무언가를 설명하는 그림" loading="lazy">

<blockquote>
 설계가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 
일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.
<cite>- Clean Archictecture, 21P</cite>
</blockquote>

돌아가는 행위(외부 품질)만 중시하고, 설계(내부 품질)를 등한시하면 유지 보수 비용이 증가할 거라는 믿음은 기술 부채라는 메타포를 만들었다. 내 주변의 개발자 중에서 이를 모르는 사람은 거의 없다.

Clean Archictecture의 저자, Robert C. Martin은 설계(Archictecture)의 중요성을 설득하는 책임은 개발팀에게 있다고 말한다. 그에게 이는 장인 정신의 문제다. 문제를 잘 아는 사람이, 문제를 잘 모르는 사람을 설득할 수밖에 없다는 점에서 공감한다.

<blockquote>
 따라서 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 
소프트웨어 개발팀이 마땅히 책임져야 한다. 
이러한 책임을 다하려면 싸움판에 뛰어들어야 하며, 
더 정확히는 ‘투쟁’해야 한다.
<cite>- Clean Archictecture, 20P</cite>
</blockquote>

그럼에도 현실에서 이 문제를 풀기가 어려웠던 이유는, 설계가 비즈니스에 기여하는 바를 실증하는 논거를 만들기가 어려웠기 때문이다.

비즈니스 이해관계자에게 비즈니스 논리는 대체로 선명하고, 이성적이고, 성실하다. 이에 반해 기술 논리는 모호하고, 감성적이고, 게으르다. 이 때문에 기술 논리는 비즈니스 논리 앞에서 자주 무력해졌다. 상황은 긴박한데 꽃구경을 가자는 이야기 정도로 취급을 받기 십상이다. 눈에 잘 보이지 않는다. 문제가 터지기 전까지는 문제라는 걸 느끼지 못한다.

느려지는 속도를 개인의 시간으로 메우다가, 진흙탕에 빠져있음을 몸으로 느끼는 상황이 왔을 때는 이미 늦다. 기술 부채가 커질수록 청산에 드는 수고 역시 커지지만 왜 그런지 비즈니스 논리에는 여유가 없다. 이런 상황에서는 과거의 부채를 청산할 여력 자체가 없다. 악화가 악화를 부른다. 악순환이다.

악순환에 빠져있음을 증명하려면 기술 부채라는 녀석을 눈에 보이는 무언가로 만들어 그것이 가진 비즈니스 가치를 증명해야 한다. 데이터가 필요하다. 데이터를 수집하려면 프로세스를 장악해야 한다. 개발 과정에 흔적을 남기고, 흔적을 수거해서 정보를 얻어야 하니까. 프로세스를 장악하려면? 동료의 신뢰를 얻어야 하고 설득을 해야 한다. 어느 정도의 지적 권위도 필요하다. 그 자체로 어려운 일이다. 연습하는 시간도 필요하다. 그런데 비즈니스 논리는 항상 긴박하다.

무언가 잘못되어 가고 있음을 직감하지만, 그 느낌을 실증하기가 어려운 이유는 이 때문이었다. 투쟁에서 이기려면 증명을 해야 하는데, 증명을 하는 데에는 대단히 많은 에너지와 시간을 들여야 한다. 시간을 확보하려면 투쟁을 해야 한다. 투쟁에서 이기려면 증명을 해야 한다. 돌고 돈다.

조직의 상층부로 갈수록 기술보다는 비즈니스 논리에 가까워지는데, 안타깝게도 의사결정권자가 비즈니스 논리에 가까울수록 이 문제는 더 풀기가 어렵다. 설득에 대한 책임은 조직의 계층 구조에서 밑바닥에 있는 자들의 것이 되어 버리기 때문이다. 이야기가 바닥에서만 돌 뿐, 위로 뻗어가지 못한다.

상황은 어렵지만, 실무자의 입장에서 이 악순환의 연결고리를 끊을 수 있는 방법은 없는 시간이라도 쥐어짜내는 것뿐이라는 생각에 도달했다. 어떤 식으로든 부채를 가시화하고 근거를 만들어서 주장을 하는 것 외에 다른 방법이 있을까? 아무 일도 하지 않으면 아무것도 바꿀 수 없다. Clean Archictecture에서 저자가 말하는 투쟁은 이런 맥락의 이야기일 것이다.

QA 과정에서 발견한 버그의 유형을 목록화하고 기술 부채와의 연관성을 추적한다. 기술 부채를 관리하는 백로그를 만들고 규모를 추정하여 수치화를 할 수도 있다. 새로운 기능을 구현함에 있어 기술 부채로 인해서 발생한 지연 일정을 수치화하여 보고하는 것도 하나의 방법이다.

물론 말은 쉽다. 세상의 많은 일은 몰라서 못하는 게 아니다. 나 또한 네이버에서 일을 하면서 이 투쟁을 완성하지 못했으니까. 그럼에도 조금씩, 조금씩 두들기다 보면 언젠가는 저 벽을 허물 수 있지 않을까.



</div></div>

Huns.me

설계가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 
일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.
- Clean Archictecture, 21P
돌아가는 행위(외부 품질)만 중시하고, 설계(내부 품질)를 등한시하면 유지 보수 비용이 증가할 거라는 믿음은 기술 부채라는 메타포를 만들었다. 내 주변의 개발자 중에서 이를 모르는 사람은 거의 없다.
Clean Archictecture의 저자, Robert C. Martin은 설계(Archictecture)의 중요성을 설득하는 책임은 개발팀에게 있다고 말한다. 그에게 이는 장인 정신의 문제다. 문제를 잘 아는 사람이, 문제를 잘 모르는 사람을 설득할 수밖에 없다는 점에서 공감한다.
따라서 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 
소프트웨어 개발팀이 마땅히 책임져야 한다. 
이러한 책임을 다하려면 싸움판에 뛰어들어야 하며, 
더 정확히는 ‘투쟁’해야 한다.
- Clean Archictecture, 20P
그럼에도 현실에서 이 문제를 풀기가 어려웠던 이유는, 설계가 비즈니스에 기여하는 바를 실증하는 논거를 만들기가 어려웠기 때문이다.
비즈니스 이해관계자에게 비즈니스 논리는 대체로 선명하고, 이성적이고, 성실하다. 이에 반해 기술 논리는 모호하고, 감성적이고, 게으르다. 이 때문에 기술 논리는 비즈니스 논리 앞에서 자주 무력해졌다. 상황은 긴박한데 꽃구경을 가자는 이야기 정도로 취급을 받기 십상이다. 눈에 잘 보이지 않는다. 문제가 터지기 전까지는 문제라는 걸 느끼지 못한다.
느려지는 속도를 개인의 시간으로 메우다가, 진흙탕에 빠져있음을 몸으로 느끼는 상황이 왔을 때는 이미 늦다. 기술 부채가 커질수록 청산에 드는 수고 역시 커지지만 왜 그런지 비즈니스 논리에는 여유가 없다. 이런 상황에서는 과거의 부채를 청산할 여력 자체가 없다. 악화가 악화를 부른다. 악순환이다.
악순환에 빠져있음을 증명하려면 기술 부채라는 녀석을 눈에 보이는 무언가로 만들어 그것이 가진 비즈니스 가치를 증명해야 한다. 데이터가 필요하다. 데이터를 수집하려면 프로세스를 장악해야 한다. 개발 과정에 흔적을 남기고, 흔적을 수거해서 정보를 얻어야 하니까. 프로세스를 장악하려면? 동료의 신뢰를 얻어야 하고 설득을 해야 한다. 어느 정도의 지적 권위도 필요하다. 그 자체로 어려운 일이다. 연습하는 시간도 필요하다. 그런데 비즈니스 논리는 항상 긴박하다.
무언가 잘못되어 가고 있음을 직감하지만, 그 느낌을 실증하기가 어려운 이유는 이 때문이었다. 투쟁에서 이기려면 증명을 해야 하는데, 증명을 하는 데에는 대단히 많은 에너지와 시간을 들여야 한다. 시간을 확보하려면 투쟁을 해야 한다. 투쟁에서 이기려면 증명을 해야 한다. 돌고 돈다.
조직의 상층부로 갈수록 기술보다는 비즈니스 논리에 가까워지는데, 안타깝게도 의사결정권자가 비즈니스 논리에 가까울수록 이 문제는 더 풀기가 어렵다. 설득에 대한 책임은 조직의 계층 구조에서 밑바닥에 있는 자들의 것이 되어 버리기 때문이다. 이야기가 바닥에서만 돌 뿐, 위로 뻗어가지 못한다.
상황은 어렵지만, 실무자의 입장에서 이 악순환의 연결고리를 끊을 수 있는 방법은 없는 시간이라도 쥐어짜내는 것뿐이라는 생각에 도달했다. 어떤 식으로든 부채를 가시화하고 근거를 만들어서 주장을 하는 것 외에 다른 방법이 있을까? 아무 일도 하지 않으면 아무것도 바꿀 수 없다. Clean Archictecture에서 저자가 말하는 투쟁은 이런 맥락의 이야기일 것이다.
QA 과정에서 발견한 버그의 유형을 목록화하고 기술 부채와의 연관성을 추적한다. 기술 부채를 관리하는 백로그를 만들고 규모를 추정하여 수치화를 할 수도 있다. 새로운 기능을 구현함에 있어 기술 부채로 인해서 발생한 지연 일정을 수치화하여 보고하는 것도 하나의 방법이다.
물론 말은 쉽다. 세상의 많은 일은 몰라서 못하는 게 아니다. 나 또한 네이버에서 일을 하면서 이 투쟁을 완성하지 못했으니까. 그럼에도 조금씩, 조금씩 두들기다 보면 언젠가는 저 벽을 허물 수 있지 않을까.

설계의 중요성을 설명하기가 왜 어려웠을까?

댓글