주방을 더럽히지 않고 맛있는 스파게티 코드만들기
세상을 둘러보면 Product Market Fit(PMF)을 찾는 과정에서 팀내에 엔지니어에게 요구되는 역량중 가장 중요한 역량을 꼽아보라면 아마 빠른 개발과 제품에 감각과 경험 그리고 Maker들간의 의사소통들이 있어요.
최근 주변을 둘러보면 PMF를 찾는 과정에서 Product Manager 시각에서 보았을 때는 그들은 이 기간에는 잘 만드는것이 전혀 중요하지 않고 실험에 집중하고 확장이 불가능한 구조를 만들어도 상관이 없는 스파게티코드를 환영하는 듯하는 분위기에요. 왜냐하면 어차피 90%는 버리게 될것이고 빠르게 제품을 출시해서 유저의 피드백을 빨리 받는게 중요하기 때문이죠.
하지만, 스파게티를 만들어냈을 때 성공하든 실패하는 설거지를 해야하는 건 엔지니어의 몫인데, 초기 작은 프로젝트에서 스파게티를 만드는 과정에서는 정리하는데 있어서 빠르게 처리할 수 있으나 이미 성숙하거나 규모가 큰 프로젝트 상에서의 수 많은 의존성들을 활용하고 이곳 저곳을 더럽혔다면 그 더러워진 주방에서 엔지니어들은 더러워진 주방에서 다른 음식을 오염시키거나 새로운 음식에 이전에 작업한 스파게티 소스가 튀어서 더럽히게 되고 결국 요리하는 모든 엔지니어들에게 자괴감을 선사하게 될 것이 분명해요. 이는 엔지니어의 커리어나 성장 측면에서도 좋지 않아요.
스파게티를 만들어도 다른 요리사들(엔지니어 또는 다른 사일로 조직의 Maker)에게 피해를 끼치지 않고 주방을 깨끗히 사용하면서 빠르게 제품을 출시하는 방법은 없을까요?
이미 방법을 경험을 통해 체득하거나 학교에서 충실히 공부한 모범생분들에게는 진부하고 교과서적인 내용일 수 있겠지만 이번 글에서 위와 같은 문제를 해결하는 방법을 다뤄보고자하며 엔지니어들의 사고방식을 잘 모르는 순수한 Product Manager들에게 좋은 글이 되길 바래보아요.
접점을 최대한 줄이고 추상화하기
위 그래프는 Xu Wang의 “진동 에너지 수확 성능과 임계 결합 강도 간의 관계”에 대한 그래프이며 결합 강도에 따른 수확 공진 전력량을 보여주는데 여기서 우리가 알 수 있는건 스파게티 코드를 작성하더라도 의존성 결합이 강할 수록 제품 출시이후 리펙토링과정이나 제거 또는 기능추가하는데 그 만큼 에너지가 더 많이 든다는 점이에요.
Product Manager의 요구사항에 대해서 의존성들간, 도메인 간의 결합을 어떻게 유지하냐에 따라서 생산성과 유지보수에 대한 엔지니어링의 승패를 가를 수 있는데, 어떻게 하면 이 접점을 느슨하게 가져가며 비즈니스를 빠르게 달성할 수 있을까요?
그 정답의 핵심은 추상화에 있어요.
예를 들어 우리가 물을 급수하는 기계를 만든상태라 가정해보아요.
이 기계는 얼음물, 뜨거운 물을 급수해준다.
Product Manager는 고객이 물뿐만 아니라 다른 음료에 대한 니즈를 분석하고자 실험적으로 오렌지 주스를 급수하는 기능을 출시하려고 해요.
처음에는 그냥 오렌지 주스를 급수해주기로 하고 얼음을 동동 띄운 주스나 뜨거운 ? 주스는 배제하기로 해요.
그렇게 빠르게 붙이고 난 이후에는 오렌지 주스에 대한 유저인터뷰를 통해서 얼음이 포함된 오렌지 주스, 겨울이라 따뜻한 핫초코등과 같은 니즈도 발견하게 되고 엔지니어들은 핫초코, 커피, 포도주스 등등 마구마구 붙이기 시작해요.
그리고 유저 데이터를 분석한 결과 가정에서 사용하는 유저의 경우 물과 커피만 주로 활용하고 패스트 푸드 음식점에서 사용하는 유저들은 주스 종류에 대한 이용률이 높은 것을 확인하고 제품군을 분리하고자 해요.
하지만, 하나의 기계안에서 수 많은 실험과 기능들을 빠르게 붙여나간 나머지 겉으로 보기에는 그냥 나누면 될꺼같지만 기계부품들간에 결합의 복잡도가 너무 높아진 나머지 분리하는데 있어서 엔지니어링 일정 예측 비용이 지나치게 높아진 사실을 발견하게 되는데요. 결국엔 점점 늦어지는 제품출시에 대해서 Product Manager들은 실망감을 금치못하게 돼요.. ㅠ
다시 지금까지 과정을 되돌아봤을 때 이 여정동안 엔지니어가 놓친 포인트를 집어보면 추상화를 하지 않았고 그럴 여유없이 무작정 제품에 스파게티 코드를 작성한 것을 알 수 있다는 점이에요.
그래서 엔지니어는 해결하고자 하는 비즈니스 해결방향을 놓고 이 기존 급수기계 시스템과의 접점을 최소화하고 다른 음료들간에 결합을 최소화하고 각 음료들마다 비즈니스를 빠르게 달성하기 위해서 최소한에 대한 개념을 정의하고 작업하는 것을 추상화라고 해요.
위의 그림과 같이 오렌지주스 제공에 대한 비즈니스 로직을 기계에 냅다 붙이는 것이 아닌 Beverage라는 추상화를 시도하고 난 다음에 물에 대한 기존 구현로직과 순수 오렌지 주스에 대한 구현로직을 작성하게 되는 것이죠.
더 나아가 얼음과 가열에 대한 행위는 모듈화하여 각 음료 구현체에서 필요에 따라 의존성으로 사용하게 됩니다. 따라서 굳이 기계 시스템을 더럽히지 않고도 각 비즈니스 목표를 달 성할 수 있는 것이지요.
만약 얼음량에 대해서도 음료마다 다르게 가져가고 싶다면 위와 마찬가지로 얼음에 대해서도 추상화를 접근할 수 있겠죠.
또한 각 구현체들은 단일책임을 가지고 필요에 따라 재사용가능한 형태로 구현되어있기 때문에 앞서 유저인터뷰를 통해서 유저군 분리에 따른 가정/상업용 제품을 출시하는 데 있어서도 기존 스파게티를 분리하는 엔지니어링 비용은 최소화하고 아래 그림과 같이 목표를 빠르게 현실화 할 수 있어요.
마무리
사실 이 글의 내용들은 너무 진부하기도 하고 학교에서 소프트웨어를 배운 Maker입장에서는 너무나도 기본적인 이야기일 수 있으나, 현업을 둘러보면 이런 기본을 간과하고 제품을 만드는 경우를 보기도 합니다. 이건 집지을 때 지붕 먼저 올리는 것과 똑같죠.
결국 이 세상의 모든 물질들과 추상적인 개념들의 엔트로피는 높아지기 마련이다. 하지만 이 엔트로피가 상승하는 가속도를 최대한 낮추면서 빠르게 제품을 만들어 나가는 것이 엔지니어의 역할이며, 이러한 엔지니어들을 신뢰하고 비즈니스 달성을 위해 앞서 말한 사고(思考)를 할 수 있는 여유를 줄 수 있길 바라며 글을 마무리해 보고자해요.
