아기돼지 삼형제와 기술부채
철근이 부족하다고? 일단 되는 대로 지어봐
먼 옛날, 아기 돼지 삼형제가 살았습니다. 아기 돼지 삼형제는 오랫동안 같이 지내던 엄마의 품을 떠나, 독립을 해야 할 시기가 되었습니다. 아기 돼지 삼형제는 비옥하고 먹이가 많은 땅을 찾아, 함께 정착하려고 마음을 먹었습니다. 각자 집을 지을 준비를 하는데, 문제는 집을 지을 방식의 차이였습니다. 각자 생각하는 집짓는 방식이 너무 달랐던 것이죠. 한 명씩 의견을 한 번 들어볼까요? 먼저 첫째의 의견입니다.
"일단 집이라는 개념이 생기는 게 먼저야. 일단 지푸라기로 짓더라도, 기본적으로 보온과 위치 확보라는 최소한의 집으로서의 기능을 할 수 있어. 게다가 지푸라기가 최대한 빨리 확보할 수 있는 자원이며, 집을 만드는 시간도 획기적으로 단축할 수 있지. 보강하는 건 그 이후에 시간을 두고 차근차근히 진행하더라도 말야."
둘째가 말합니다.
"어느 정도 동감해. 하지만 아직 우리가 가진 자원을 잘 판단해야 해. 벽돌로 집을 짓는 게 좋긴 하겠지만 재료를 구하기도 힘들고 시간도 기약할 수 없어. 언제 늑대같은 포식자의 침범이 있을지도 확실히 알 수 없으니, 적어도 여우나 들개의 침입 정도는 막을 수 있는 나무집 정도를 우선 구축하는 게 어떨까?"
마지막, 이야기를 듣던 셋째가 입을 열었습니다.
"설령 많이 늦더라도, 최대한 많은 위험요소를 배제할 수 있어야 한다고 생각해. 지푸라기로 집을 짓든, 나무로 집을 짓든 늑대나 사자가 오면 모두 끝장이라고. 벽돌은 비록 매우 구하기 힘들고 무거워서 집을 짓는 데 시간이 오래걸리지만, 보다 멀리 보고 집을 만들어야 나중에 보강공사를 하지 않아도 되고 확장하기도 편하잖아."
늑대가 벽돌을 부술 순 없죠. 그나저나, 이제 셋이 살려면 확장 공사를 해야겠네요.결과는 어땠을까요? 생각보다 늑대는 굉장히 늦게 도착했습니다. 모든 집의 초기 버전은 완성된 상태였거든요. 그러나 지푸라기와 나무 보강공사까지 마무리될 시간은 아니었나보네요. 늑대는 첫째의 집부터 찾아가며 첫째와 둘째의 건물까지 모두 날려버리지만 셋째의 건물을 부수지 못합니다. 하지만, 이건 결과론적 이야기일 뿐입니다. 돼지의 주장에 틀린 게 있을까요? 적어도 각각의 생각에서 구성된 논리에는 이상이 없습니다. 사실상 모두가 맞는 말을 하고 있는 것입니다. 그러나 이야기의 결말은 모두가 맞지는 않다고 났습니다. 왜일까요? 이 우화는 첫째의 방법이 가지는 기술부채의 위험성을 이야기하고 싶었던 것 같습니다.
기술부채란, 현재의 개발 또는 설계 결정이 나중에 비용이나 문제로 돌아올 수 있다는 것을 의미합니다. 기술부채는 소프트웨어 개발 과정에서 일시적으로 빠른 결과물을 얻기 위해 허용되거나 발생하는 것으로, 나중에 수정하거나 개선해야 할 부분입니다. 주로 '기한이 촉박해서', '잘 몰라서', '자원이 부족해서' 일단 임시방편으로 넘어간다고 볼 수도 있겠습니다.
A와 B, 두 IT회사가 있습니다.
A는 규모가 작은 신생 기업이며, 프로덕트를 최대한 빨리 생산하여 사용자에게 기능을 구현하는 데 무게를 두고 있습니다. 비록 이전에 만들었던 다른 프로덕트들과 DBMS, OS, 언어 등 많은 요소가 다르지만 일단 개발자 개인이 편한 방향으로 빠르게 구현을 해내고 있는 것이죠.
B 회사는 매우 느립니다. 비교적 규모가 큰 기업이기에 프로덕트 구축 전에 수익성 검토, 평판 리스크 등을 모두 고려하기 때문이죠. 하지만 이 회사의 경우 안정성이 높고, 관리 리소스가 많이 소요되지 않습니다. 기존 시스템들과의 호환도 고려했기 때문이겠습니다.
위의 경우, A가 일부의 기술부채를 진 상태에서 효율성을 우선으로 업무한 상태라고 정의할 수 있겠습니다.
단건이고 단기적이라면, 여기서 장점은 A가 월등히 많다고 볼 수 있겠습니다. 그러나 실제로는 고려해야 할 요소가 더 많습니다. A는 앞으로 어떤 프로덕트가 몇 개나 더 생겨날지, 어떤 기능이 더 필요할지 어떻게 다른 프로덕트와 연계해야 할지 끊임없이 대응을 고민해야 할 것입니다. 이때 두 경우는 어떻게 달라질까요? 저렇게 만들어진 프로덕트가 10개, 100개, 1000개가 된다고 가정한다면 A의 연계의 경우의 수는 제곱으로 늘어나며, 운영/개발 등에 필요한 맨먼스도 기하급수적으로 증가하게 되죠. 이건 결코 바람직하지 않습니다. 따라서 A의 경우 주기적으로, 아주 큰 비중을 두고 기존 프로덕트들을 통합하거나, 제거하는 등의 방식으로 전사적 효율성 제고를 끝없이 고민하고 고찰해야 합니다. B와는 다르게 말이죠. 필연적인 선택의 대가입니다.
건물을 짓는 데 있어서 철근이 하나 정도는 빠져도 건물 자체는 무너지지 않을 수도 있겠습니다. 코드 하나가 최적화되어 있지 않아도 전체 시스템에는 크게 오류가 없는 것처럼요. 그러나 이런 부채들이 하나하나 쌓이게 된다면 늑대가 쳐들어 왔을 때, 갑자기 해킹 공격이 들어왔을 때, 혹은 정말 아무런 전조도 없이 갑자기 집이 무너질 수도 있다는 걸 잘 알아야 하는 시기인 것 같습니다. 아주 예전에 만들어진 우화에도 나와있는 지혜인데, 현대를 살아가는 사람들이 모를 리가 없겠죠.
