설계란 무엇인가 III

이 글은 우연히 발견한 오래된^[1] 글, Is Design Dead?가 반가워서 뭔가 쓰려고 했는데, 앞서 썼던 두 개의 글과 라임을 맞추느라 제목을 이따위(?)로 붙였음을 이실직고합니다.

그래서 설계는 죽었는가?

마틴 파울러의 긴 글을 만났을 때, 마치 어릴 적 주고받은 편지를 우연히 발견하고 반가워하는 마음이 들었다. 그의 글 마무리가 그래서 설계는 죽었는가?(So is Design Dead?)이다. 잠시 그의 글을 보자.^[2]

그래서, 디자인은 죽었는가? - So is Design Dead?

전혀 그렇지 않다. 다만 디자인의 성향이 바뀐것이다. XP 디자인은 다음과 같은 기술을 요구한다.

• 코드를 최대한 명확하고 단순하게 유지하려면 부단한 의지
• 필요할때 자신있게 개선시킬수 있는 리팩토링 기술
• 패턴에 관한 훌륭한 지식: 그냥 해결책으로 보는것 뿐만 아니라 언제 그것을 사용하고, 어떻게 차츰 발전시킬지를 날카롭게 판단하여야 한다.
• 현재 내려진 결정이 나중에는 변하게 될수 있다는 것을 알고, 미래의 변화에 항상 눈을 뜨고 디자인을 하는 기술.
• 디자인을 꼭 이해해야 하는 사람에게 코드나 다이어그램 특히 '대화'를 통해서 전달하는 방법을 아는 것.

이런 기술이 두렵게 느껴질수도 있다. 하지만 훌륭한 디자이너(설계자)에게는 항상 고통과 노력이 따른다. XP가 이 고통을 조금도 줄여주지는 않는다 - 나에겐 그랬다. 하지만 XP가 효율적인 디자인을 위한 새로운 길은 가르쳐 주었다고 생각한다. 진화하는(evolutionary) 디자인이 그것이다. 나는 진화를 아주 좋아한다. 만약 진화가 없다면 나도 없는 것이다.(미래는 없는 것이다.)

[출처] 디자인은 죽었는가? Is Design Dead?|작성자 삶은 한번뿐

설계 이야기를 하는데 왜 결론은 온통 XP 이야기일 까 의아해하는 분이 있을 것이다. 2000년 당시 미국의 상황과 한국에서의 XP는 위상이 많이 달랐을 것이다. 한국이라고 똑같이 취급할 수 없는 것이 당시 포털 회사나 인터넷 서비스 회사에 다니고 있었으냐, SI나 솔루션 회사를 다녔느냐에 따라 경험도 천차만별이니까. 아무튼 이 글을 읽는 당시로써는 그다지 공감하지 못했고, XP를 무시할 수 없는 큰 조류쯤으로 취급했다. 그러나 지금은 17년이 흘렀다. 그의 글에 긴 시간이 흐르고 나서야 절대 공감^[3]하는 내 입장에서 한 마디만 하라고 하면...

설계에 최소한의 노력만 하라

읽기에 따라 오해의 소지가 있으니 이 한 줄을 설명하는 긴 글을 쓴다. Micro Service, Docker로 할 수 밖에 없었던 사연에 '어쩔 수 없는 선택'이란 표현이 나온다. 차선책을 의미하는 말이지만, 다시 생각해보면 그것이 최선이었다는 생각이 든다. 전에 쓴 글에도 언급했지만 우리는 특별히 설계란 작업 기간을 두지 않았다. 처음부터 개발 일상의 일부로 들어가도록 설정되었다. 만일 다른 선택지가 있었다면 나는 과거 습관에 끌려서 또 요구사항을 듣는다거나 현행 시스템 파악따위를 하며 사전 설계로 상당시간을 소모했을지 모른다. 단언컨대 그런 짓은 멍청한 인생 낭비다.

게다가 당시 내 입장에서는 설계할 대상이 명확하지도 않았다. 언젠가 중국 회사에 VIP가 방문했을 때 내가 노출된 일이 있다. 설계자라고 소개했더니 무얼 설계하냐고 물었다. 얼른 답이 떠오르지 않아 어물어물했더니, 상대는 뭐 그런 단순한 질문에 답을 못하냐는 표정이었다. 돌이켜 생각해보면 당시엔 나 스스로 조직을 설계하고 있는 것인지, 소프트웨어를 설계하는 것인지, 일하는 방법을 설계하고 있는지 구분이 되지 않아 그랬다. 명쾌하게 답하고 싶었지만 그렇지 못한 상황이 결국 최선을 낳는 배경이었다. 아니, 다년간 기술채무로 나락으로 떨어져 있는 회사에서 시간을 쪼개 설계를 한다는 것이 그리 간단한 문제일까?^[4]

2016년부터 시작한 중국 경험이 없었다면 나는 여전히 지나치게 계획하고 사전에 꼼꼼하게 굴며 귀한 시간을 낭비하는 나쁜 버릇을 지니고 살았을지 모른다. 그 버릇은 사회생활이전에 학교에서부터 배운 듯하다. 아무튼 그 버릇이 나쁘다는 사실을 알고 난 후 작년 한해 '(치밀한) 계획은 개나 주자'를 버릇처럼 입에 달고 살았다. 그런 경험 탓인지 마틴 파울러의 17년 전 결론이 지금의 나에겐 명쾌하게 느껴진다.

그래서, 여러분이 만일 마틴 파울러의 결론을 이해할 수 있다면 일상에 참고하시길 바라며, 잘 이해가 가지 않는 분은 내 정리를 참고하시길 권한다.

• 설계는 코딩하기 직전에 무엇을 어떻게 짜야할지 떠오르지 않을 때, 어떻게 해야 할지 떠오를 정도까지만 하시라.
• 그리고, 리팩토링을 통해 지속 설계를 하시라. Continuous Deployment의 CD 말고, Continuous Design^[5]

리팩토링은 그 과정에서 필연적으로 설계 혹은 설계 개선을 수반한다. 당연한 사실인데, 설계와 개발을 구분하던 과거 관행 탓에 어색하게 느껴지긴 한다.

나의, 우리의 설계 방식

하지만, 설계를 배워본 일이 없는 동료들은 어떻게 할 것인가? 가장 좋은 방법은 선배/사수나 실력이 나은 동료들에게 알음알음으로 배우는 식이다. 이미 그런 것들을 잘 소화하는 분들이라면 이 글이 큰 도움이 되지 않을 것이다. 그런데 그렇지 않은 개발자들이 있어 그들에게 설계란 말 자체를 설명하고, 그들이 직전에 짠 코드를 예로 코드 개선을 도운 사례를 글로 쓴 것이 바로 '설계란 무엇인가'이다. 설계에 익숙치 않은 동료들에게 내 식대로 필요한 내용을 전파하려던 시도를 다룬 글이다. 바로 사전에 나오는 설계의 정의가 아니라 내 목소리고 그리고 행동으로 나오는 설계에 대한 정의가 필요하다. 그리고, 일상에서 실천이 필요하다.

이와 다르게 누구도 혼자 풀기 어려운 난해한 문제를 함께 풀어가는 설계 일화를 다룬 내용이 지난 주 연재한 객체지향적인 Go 프로그래밍이란? 이다. 이들 글이 여러분에게 주는 시사점은 무엇일까?

팀으로 일하다 보면 대개의 경우 동료들과 함께 어울러져야 한다. 누구는 무언가 칠판에 그리기 좋아할 것이고, 코드를 보지 않고 말만 해서는 잘 못알아 듣는 동료도 있다. 어떤 친구는 직접 만나 대화하기를 즐기지만 또 누군가는 github같은 공유 공간에서 코드와 함께 간편하게 의견을 나누길 바랄 것이다. 개발자라면 결국 내 일상인 동료들과 부대끼면서 일상으로 벌어질 수 있는 사건 혹은 작업 방식들 안에 설계 행위가 녹아들어가게 해야 한다. 내 이야기는 TV에서 보는 드라마 정도라면, 일상에선 여러분의 이야기를 만들어야 한다.

과거에(어쩌면 어딘가에선 지금도) 화면 설계서와 ERD를 정도를 그려놓고 설계를 다 했다는 태도를 보이는 사람들이 있었다. 현실적으로 화면 설계서야 서비스 혹은 UI 기획자가 그려주는 것이 도움을 줄 수는 있지만, 한번 그리고 끝나는 경우는 없다. 계속해서 고쳐야 할테니 화면 설계서는 초기 설계 정도에 그친다. 그 후엔 좀더 간편한 의사소통 방식을 따르기 마련이다. 더구나 ERD 따위는 없어도 무방하다. 어차피 코딩하려면 데이터모델은 나온다. 물론 효율을 위해 데이터 모델링에 탁월한 사람이 초기 뼈대를 잡아줄 수는 있겠다. 그러나, 결국 일상의 변화를 수용하다보면 개발자가 데이터 모델을 소화하고 수정해야 한다. 그 과정에 필연적으로 설계가 들어간다. 설사 그게 설계인지 모르고 했더라도 말이다.

결론

마틴파울러의 글에 영감을 받아 앞서 내용이 정리된 것을 보고, 글을 쓰기를 잘했다는 생각이 든다.

• 설계는 코딩하기 직전에 무엇을 어떻게 짜야할지 떠오르지 않을 때, 어떻게 해야 할지 떠오를 정도까지만 하시라.
• 리팩토링을 통해 지속 설계Continuous Design를 하시라.

그리고, 여러분 자신과 조직을 위한 설계 방식을 가급적 습관이나 일상행위로 만드시라. 그게 엄두가 나지 않는다면 리팩토링 시간을 늘리시라. 혹시 리팩토링 할 시간이 없다면, 요구사항 분석이나 설계한다고 낭비하는 시간을 무조건 줄여서 시간을 확보하시라. 갑절로 돌아온다.

주석

[1] 원문은 2000년 7월 처음 발행되었다.

[2] 긴 영문 글을 번역해주신 분이 있어 원문 대신 j6040148님의 블로그를 인용했다.

[3] 글이 다룬 맥락이 현재 내 상황과는 너무 달라 내용 전체를 공감한다는 뜻보다는 골자에 대해 절절하게 공감한다는 의미다.

[4] 물론, 그 VIP는 단기 성과에만 관심있는 전문 경영인이라 '설계'란 작업을 하잖은 실무로 여겼을 것이라 짐작하기에 내가 비난하는 대상은 VIP가 아니라 '설계를 그렇게 보는 생각'이다.

[5] 어법에 맞나 구글에서 찾아봤더니 무려 이미 쓰고 있는 말이다. https://en.wikipedia.org/wiki/Continuous_design