오래된 SW 엔지니어의 평생 공부

J님이 생각하고 있던 문제의 경우는 기존 서비스에서 필요한 부분을 추출하여 신규 서비스에 적용하여 활용할지가 초기에 공유한 고민이었다. 신규로 서비스 제공하려고 하는 것은 국내의 경우 판매 사이트가 없어 영업부서 분들이 Excel, 이메일, 전화를 할용하여 진행되던 것을 서비스화 하여 이를 기존 서비스와 연동하고 또한 이를 제품으로서도 판매하려고 하는 것이었다.

이야기를 나누다 보니 결국 신규로 확장 구현하시는 모듈과 기존의 시스템을 어떻게 연계할 것인가에 대한 고민이 크셨던 것 같다. 특히, 기존 시스템은 회사에서 활용하고 계신 시스템이라 크게 변동이 일어나지 않기를 바라시는 것으로 파악되었다. 그러면서도 신규로 개발되는 시스템과의 효과적인 연동에서 수정이 많이 발생될 것으로 파악하시면서 결국 가장 중요하게 생각하시는 수정 용이성(modifiability)에 집중하시는 것이 중요하다고 생각이 되었다.

논의하면서 J님이 얻는 아키텍처적 결정은 Flux 혹은 MVVM 모델로 가져가는 것이었다. 이는 J님도 알고 계셨던 MVC에서 로직 처리의 흐름을 한방향으로 가져가게 한다는 추가 아이디어를 공유함으로서 많은 에너지를 얻으신 것 처럼 보였다. 기존 서비스와 추가 서비스의 구조와 시나리오를 보았을 때에는 MVC와 같은 구조에 빗대어 보는 것이 이해가 쉬웠다. 신규로 서비스를 추가하려는 것이 기존 서비스를 View가 되고,  신규로 추가하려는 서비스가 Model과 Controller 역할을 하는 것으로 파악되었다. 그렇다면, 기존 서비스는 고정하고 우리 서비스는 계속 변하더라도 영향이 덜 받는 구조로 만들어야 한다고 함께 판단하게 되였다.

Legacy System. 저희 회사에서도 종종 기존의 시스템으로 다루기 어려운 것이라는 느낌이 강하지만, 결국은 담당하고 있는 저희들은 Asset이기도 하다. 하지만, 여기에 숨겨진 Debt가 어떤 것인지 몰라 두려움을 느끼게 하기도 하는 것 같다. 결국은 우리가 집중해야 할 곳이 어디인지 찾고, 그 부분에 대해서 어떻게 대응할 것인지 판단하는 것이 Legacy System을 Asset으로 만드는 방법이라고 아닐까 생각한다.

iOS를 기반으로 사진을 편집하는 기능을 포함하는 앱을 개발하는 D의 사례를 살펴 보자. 이 분은 본인 포함 3명이 개발을 하는 팀인데, 스크럼기반으로 스프린트를 운영하면서 요구 사항들을 지속적으로 앱에 적용하고 있었다. 이미 리팩토링을 통해서 구조를 개선을 하였지만, 여전히 새로운 요구 사항에 대한 중복 코드가 늘고 유연하게 대처 안되고 비즈니스 로직 분리하여 추상화 중복 코드 제거하고 싶어 하였다. 궁극적으로는 시장 릴리즈 이후 품질 이슈나 QA 중 예상치 못한 이슈를 최소화 하시고 싶어했다.

원 포인트 세션 중에 문제를 구체화 하고 날카롭게 하는 것이 필요해 보였다. 이야기 할 수록 이상했던 부분은 어떻게 해야 할지 다 알고 계신 것이 보였다. 문제 중 하나는 Undo/Redo하면서 중복 호출되는 코드의 상세 사항으로 들어 갈 수록 이 부분을 리팩터링하면서 효율화 하고 싶다는 것을 알 수 있었다. 즉, 해야 할일에 대해서는 이미 알고 있어 보였다. 즉, 관련 부분을 추상화하고, 중복 코드도 제거하여 향후 코드 파악이쉽고, 추가 요구사항에 대응이 용이하게 하는 것이다. 하지만, "실행"하는 것이 문제였다. 여러 이야기가 있었지만 본인 포함 3명의 개발자로 신규 요구 사항을 스프린트 내에서 소화하고 이러한 부분을 함께 진행하시는 것에 부담이라는 것이다. 이러한 상황이라면 어떻게 할 수 있을까?

우리는 "작게 해볼 수 있는 것"을 찾아 보게 되었다. 작게 나누어 해볼 수 있는 방법에 대해 이야기 나누었다. 그러면서도, 제품으로 적용되어 진행 될 수 있도록 하는 것이 목표였다. 이렇게 하기 위해서 중복되더라도 작게 개선해 가는 방법에 대해서 상세하게 이야기를 나눴다. 개선해야 하는 객체들이 여러가지가 있었는데, 변경하는 도중에는 개선한 것과 개선하지 않은 객체들이 중복해서 존재하지만 개선이 되어 가는 방법에 대해서 이야기 나누었다. 이렇게 하기 위해서 이 작게 나뉜 리팩터링 작업을 스크럼의 백로그(Backlog)로 만드는 방법에 대해서 이야기 나누었다. 그러기 위해서, 이해 관계자(Stakeholder)와 이를 공유하는 것도 이야기 나누었다. 이러한 논의를 통해 D는 좀 더 자신감을 얻었다. 

상품화 된 소프트웨어 제품을 개선하는 것에 대해서 "달려가는 기차의 바퀴를 바꾸는 일"이라는 비유를 들은 적이 있다. 상황의 어려움도 있지만, 문제와 관련된 다양한 리스크가 많기 때문 일 것이다. 이를 위해서는 우리가 리스크에 대한 걱정을 줄이는 것이 중요하다. 이 부분을 통해 자신감이 높아지는데 도움이 되기 때문이다. 또한, 이렇게 우리가 걱정되는 것이 있다면 작게 시도해 보고 실패하고 계속해서 시도하면서 우리가 개선하는 것에 대해서 학습하는 것이 효과적이다. 수백kg에 해당하는 펀치를 한번에 받아 내는 것 보다는 수백g의 작은 펀치를 여러 번 나눠 맞는 것이 끝까지 살아 남는데는 더 나은 선택이기 때문이다.

요즈음 데이브 스노든의 커네빈(Cynefin) 프레임워크 책[1]을 다시 읽고 있다. 커네빈은 명확(Clear), 복합(Complicated), 혼돈(Chaos), 복잡(Complex)의 네 가지 영역 중 어느 하나에 속할 때 취할 수 있는 적절한 조치가 있다. 이는 아래 그림에서도 잘 설명되어 있다.[2]. 

하지만, 나는 아포리아/혼란(Aporia/Confused) 영역에 대해서는 다른 곳에서 설명을 듣지 못했다. 이부분을 커네빈 책에서는 4개의 커네빈(Cynefin) 영역에서 자신이 어디에 위치해야 할지 모르는 상태로 정의하고, 결정을 내리거나 적절한 조치를 취하기가 어려운 상태라고 한다.
  
커네빈 책[1]에서는 이와 관련해서 2가지 옛날 이야기를 한다. 하나는 곤과 우의 치수 이야기와 도덕경의 무지용(無之用)을 언급하며 설명한다.  
  
중국 고대 신화인 곤과 우의 치수 이야기에서 곤은 10년 동안 강을 따라 정교한 둑 시스템을 구축했다. 곤의 접근 방식은 통제와 통치, 질서를 강조하는 유교적 방식으로 종국에는 황하의 물살을 통제할 수 없었기 때문에 모든 둑은 실패로 돌아갔다. 반면에 곤의 아들 우는 물의 흐름을 엄걱하게 통제하려는 대신 "물을 주인으로 모시고 물의 길"을 따르는 방식으로 접근했다. 즉, 그는 전문가인 농부들과 함께 일하고, 서민들과 함께 자고, 먹으며 그 상황과 풍경을 이해하고자 노력했다. 즉, 하나의 둑 대신 복잡한 관개 수로 시스템을 구축해서 황하와 평행하게 이어지는 많은 제방으로 구성되어 홍수로 범람한 물을 활용할 수 있었다고 한다.  
  
도덕경 11장의 무지이위용(無之以爲用)은 크리스토퍼 알렉산더의 Nature of Order의 15개 속성 중에서 The void와 연결하여 이해할 수 있다. 즉, 없는것/비어 있는 것이 (실용적으로) 사용된다는 의미로 이해할 수 있다. 어렵겠지만, 책에서 무위(無爲)로 받고 치수 이야기로 빗대어 설명한다.
  
데이브 책의 8장에서는 아포리아/혼돈 상태에서 가능한 행동을 무위(無爲)로 언급하는데, "행동하지 않는 행동" 또는 "노력하지 않는 행동"으로 이이기 한다. 다시 물의 흐름을 통제하려 하기보다는 '물의 흐름을 따르는' 자연주의적 접근으로 가장 자연스럽고 수월한 행동이 나타날 수 있도록 의식적인 무위(無爲)라고 설명한다.  
  
어려운 이야기이다. 하지만, 간단히 이야기 하면 행동 계획을 세우기 어려운 상황이면 아무것도 하지 않거나 흘러가는데로 잠시 둘 필요가 있다는 것으로도 해석할 수 있겠다. 앞에 그림에서도 보면 조금더 명확해 지기 까지 낭떨어지를 따라 떨어지거나 태풍을 따라 날아가 볼 수도 있을 것이다. 하지만, 어딘가로 떨어질지 관찰하고 실험해야 할 것이다.   
  
즉, 이러한 상황이라면 무력해 지지 말고, 내가 모른다는 것에 익숙해지고 무위를 실행해야 할 상황임을 인식하고 매듭을 지어 보는, 그리고 비워 보는, 흘러가는데로 두어 보는 접근법도 가능하겠다.  

참고 문헌
[1] Dave Snowden et. al., "Cynefin® - weaving sense-making into the fabric of our world," Cognitive Edge Pte Ltd, Oct. 26, 2020
[2] Vige 버전 Cynefin Framework, https://static1.squarespace.com/static/5c4713ea1137a655bbd36a6b/t/61822121bb1fdd6e8a670005/1635918132167/Cynefin-EBB-Full.png