설계란 무엇인가 II

요즘 글쓰는 것이 즐겁다. 이런 시절이 길지 않기 때문에 최대한 뽑아야(?) 할 것 같다. 구인공고 올리려고 백년만에 들어간 트위터에서 마틴 파울러의 excellent post란 표현을 보고 링크를 눌렀는데,  글쓰려는 욕구를 자극하는 글감이 등장했다.

마틴 파울러의 한 트윗

마틴 파울러가 칭찬한 글에서 글쓰기를 자극한 구절은 바로 아래 단락 제목이다.

engineering decision-making is a socially constructed activity

내 번역은 이렇다.

엔지니어링 의사결정은 함께 구축하는 행위이다.

매력적인 표현이다. 글을 더 읽기 전에 생각해봤다. 대략 아래와 같은 것들을...

• 엔지니어링 의사결정이 설계인가?
• 사회적으로Socially^[1]란 표현이 사람들의 상호작용만 말하는가?

그리고, popit에 썼던 글들을 떠올리며 연관성을 찾아보았다. 모르는 사람이 쓴 생소한 글을 보자마자 매력을 갖는 이유는 아마도 내안의 공감일테니까. 그래서, popit 에 쓴 글을 찾아서 관련 내용을 발췌해봤다.

몇 시간 후에 함께 모여 M이 그린 그림을 봤다. 두 장을 그렸다. 한 장은 화장실에서 나를 만나기 전에 그린 그림이고, 다른 한장은 그 후에 그렸다고 한다. 전자는 짐작으로 그리고, 후자는 두 사람이 짠 코드를 확인하고 그린 그림이었다. 나중에 M은 회고를 하며 그들이 자기 생각과 비슷하게 구현했을 것으로 짐작했다고 한다. 화장실에서 내 말을 듣고, 코드를 확인하기 전까지는. 이 경험을 통해 소통의 중요성에 대해 다시 한번 느꼈다고 고백했다.

'설계란 무엇인가?' 에서

함께 만드는 과정이 드러난다. 짐작으로 만든 결과물을 동료와 소통을 통해 개선하는 과정이 있다. 그리고 개선의 시작은 일상에서 던져진 동료의 조언에 반응하여 개발자 사이에서 서로 코드와 생각을 나누는 과정에서 오해를 찾아 고치는 일로 마무리 되었다. 뒤이어서 함께 회고를 하는 과정에서 자신의 인지의 폭(소통의 중요성에 대해 다시 한번 느꼈다고 고백)도 넓어졌음을 확인했다.

다음으로 찾은 내용은 함께할 필요성을 강조하는 부분이다. 빠른 변화에 대응하려면 조직을 작은 조직으로 나누고, 작은 조직이 독립적 결정을 할 수 있어야 한다. 전체 조직입장에서 보면 병렬로 의사결정 하는 형태가 된다. 함께Socially를 실현하는 또 다른 모습이다. 함께란 모두가 한시간과 공간에 엮이는 모습을 고집할 필요가 없고, 일사분란한 군대식 움직임을 보일 필요도 없다.

운좋게도 나에게 마이크로 서비스 아키텍처를 주문했던 두 분의 훌륭한 경영자가 있었다. 둘 다 개발자 출신은 아니지만, 빠른 시장 대응(Time to market)을 위해서는 소수가 독립적으로 판단하고 개발하는 조직이 필요하다는 데에 초점을 두고 있었다. 한 분은 이를 마이크로 셀이라고 표현했다. 린(Lean)이나 애자일 관련 자료를 찾아보면 이론적으로 마이크로 셀을 구축하는 방법론은 어렵지 않게 찾을 수 있다. 그러나, 우리가 일할 대상은 모두 감정과 생각이 있는 사람들이다. 그래서 일원화된 방식^[3]으로 성공을 기대하는 것은 어리석은 일이다. 그래서, 각자 조직에 맞는 방법을 찾아 끊임없이 시도해야 한다.

'마이크로 서비스 구축 경험 공유'에서

조금 다른 형태의 함께도 찾았다. 빨리 만들기를 기대하는 비즈니스(혹은 그쪽 사람) 욕구와 개발팀의 이해가 충돌하는 상황이다. 비즈니스는 빠른 출시를 원하지만, 그렇게 하면 코드 품질이 떨어지고 중복이 발생한다. 반면에 시간을 더 주면 개발팀에는 유리할 수 있으나 비즈니스 기회를 잃을 수 있다. 갈등을 해소하며 함께Socially 구축해가야 하는 이런 상황은 흔히 겪을 수 있는 일상의 모습이다.

한편, 애자일에서 말하는 PO(Product Owner) 즉, 비즈니스를 다루는 사람이면서 동시에 개발팀 일원이라는  실행하기 난해한 역할은 이런 상황을 배경으로 탄생했을지도 모르겠다.

기술력이 높지 않는 상황에서 빨리 만들기 까지 했으니 새로운 요구사항에 맞춰 기존 프로그램을 고치지 못하는 일이 발생했다. 예를 들어, 로그인과 인증을 담당하는 Account 모듈^[6]이 레거시 데이터 소스가 달라 단시간에 두 가지 방식을 모두 지원하게 코드 수정을 못하는 일이 생겼다. 우리 결정은 단순했다. 출시 속도(Time-to-market)를 우선시하는 것이다. 데이터 소스에 따라 두 개 버전을 만들면 빠르게 개발할 수 있다.

'마이크로 서비스 구축 경험 공유'에서

이 정도만 살펴보자. 길어졌으니 정리해보자. John Allspaw의 글에서 다음 표현을 보고 발생한 공감이 어디에서 비롯한 것인지 과거 글에서 찾아보았다.^[2]

engineering decision-making is a socially constructed activity

불확실에 대응하는 전략

그 다음에 눈에 띄는 내용이 있었다.

“the strategy for causing the best change in a poorly understood or uncertain situation within the available resources”

John Allspaw는 poorly와 best를 뒤이어 강조했다. 이해가 부족하고(pooly understood) 불확실한 상황(uncertain situation)은 특수 상황이라기 보다는 늘상 벌어지는 보편 상황이다. 소프트웨어 개발 경험이 있다면 누구나 겪었을 일이기 때문에 굳이 장황하게 설명하지 않겠다. 모두 각자의 인지만큼 알고 있을테니.

마이크로 서비스 구축 경험 공유란 글이 위 표현에 대한 구체적인 사례일 수 있다. 정답이 아니라 전략을 다루는 측면으로 요약해보면 아래와 같다.

• 체질부터 개선하자
  • 뭔가 다 정해진 뒤에 개발하려는 습성을 고치는 일을 결과물보다 우선해서 시작한다
  • 한달 정도는 결과가 안나와도 신뢰를 쌓고, 기민함을 배양하도록 개발 과정을 설계한다
• 기술이 비즈니스에 우선하지 않게 하자
  • 출시 속도를 높이기 위해 기술적 통일성은 일단 포기한다
• 비즈니스 생존을 위해 기술 부채를 감당하자
  • 리팩토링 역량이 갖춰지기 전까지는 동일 기능이 여러 버전으로 있어도 허용한자

설계는 정답을 찾는 것이 아니다

John Allspaw가 인용한 글에 설계의 정의라고 불러도 좋을 그림이 있었다.

출처: http://mcfunley.com/choose-boring-technology

하지만, 그림을 제시한 글에서도 이를 정답으로 제시한 것이 아니었다. 게다가 이를 인용한 John Allspaw도 다음과 같이 말한다.

engineering (as an activity) does not have “correct” solutions to problems

설계는 어쩌면 정답을 찾는 것이 아닐 수 있다. 우리는 항상 불확실함과 자원 부족이라는 필연적인 조건하에서 개발할 수밖에 없기 때문이다. 여러분도 '만약 우리 팀에 개발자 두 명만 더 있었더라면' 혹은 '한 달만 여유가 주어졌더라면' 하는 생각을 품어본 기억이 있지 않은가? 하지만, 현실은 늘 그런 부족함을 우리에게 선사한다. ^[3]

마틴 파울러가 칭찬한 글을 읽기보다는 인상적인 어구에 대한 공감을 구체화 하고, 이를 글로 썼다. 그 과정에서 '설계란 무엇인가?'에 대한 대답이 정답으로 제시되는 것보다는 다양한 양상을 보여주는 편이 좋겠다는 생각이 들었다. 그리고, 함께(Socially) 소통하며 서로에게 긍정적 자극을 줄 수 있다면 그보다 좋을 수는 없을 것이다. 그래서, 설계란 무엇인가 시리즈를 연재한다.

함께의 전혀 다른 측면

너무 길어질까봐 앞서 함께Socially의 의미를 돌아볼 때 인용하지 않은 부분이 있다.

두 개발자가 UML에 능통한지 어떤지는 모르지만, 그리면서 위와 같이 설명했기에 쉽게 이해했다. 그리고, 자신들의 의견을 말했다. 우리 셋은 모두 공감하고 상쾌한 기분으로 마무리를 했다. 내 입장에서는 고작 5~10분을 투자하고, 개발에 작은 기여나마 할 수 있었고 공감 과정에서 얻은 기쁨은 놀라울 정도였다. 놀라운 상쾌함의 가장 큰 이유는 아마도 열렬히 일하는 이들과 함께 하는 과정에서 비롯된 것이라 믿는다. 그리고 두번째는 자연스러운 흐름(flow)속에서 적기에 딱 필요한 만큼만 하는 가벼운(lean) 설계 행위였기 때문이다. (개발도 하기 전에 억지로 짜내기 하는 식의 설계와 대비하면 쉽게 이해할 수 있다.)

'함께 그리고 가볍게 하는 소프트웨어 설계의 즐거움'에서

여기서는 전혀 다른 관점을 볼 수 있다. 설계란 함께 구축하며 정답에 가까워지려고 노력하는 과정이기도 하지만, 개발자는 그 안에서 살아간다. 곧 삶의 많은 순간이 어쩌면 설계로 채워질 수도 있다.

주석

[1] 함께란 우리말로도 '사회적으로'란 딱딱한 말을 대신할 수 있어서 다른 곳에서는 '함께'라고 쓴다.

[2] 내가 쓴 글이 아니지만 100% 공감하는 글인 Micro Service, Docker로 할 수 밖에 없었던 사연에서 설명한 과정은 어쩌면 함께 구축하는 행위(a socially constructed activity)에 대한 전형적인 설명일 수도 있다.

[3] 역설적으로 그 부족함이 우리 역량을 높여주기도 하지만 말이다.