기술부채에 대한 고찰

먼저 기술 부채가 무엇인지 알아보자.

기술 부채를 풀이해보면 미래보다 현재를 더 중요시하다보니 만들어진 결과에서 발생되는 개념이다.

개발 과정에 더 좋은 솔루션이 있음에도 소요 시간이 더 오래걸리다보니 현재 상황에 맞게 더 좋지 못한 방향을 선택하거나,

데드라인에 급박하여 빠르게 만드는 과정에서 저품질의 코드를 만드는 것들이 모두 기술 부채이다.

개인적으로는 이 단어가 참 잘 만들어졌다고 생각한다.

부채는 '빚' 을 의미하는 단어이며 빚에는 이자가 붙는다.

실제 경제 활동에서도 대출을 받을때 이자의 무서움을 잊어버리면 큰 위험을 감수할 수도 있다.

그럼 개발에서 기술부채의 이자가 붙는건 어떤 것을 의미할까?

상황은 너무나도 다양할 수 있다.

급한 마음에 코드를 복붙(Ctrl+C,V)하면서 만들어진 중복코드로 인해 유지보수가 어려워져 개발 비용이 증가 될 수 있고,

후임자가 코드를 파악하는데 어려움을 겪을 수도 있다.

또는 스타트업에서 빠르게 제품을 출시하기 위한 기술스택을 차용했는데 서비스가 잘되면서 트래픽이 빠르게 늘어났다.

트래픽이 늘어나면서 기술스택과 인프라를 점검하고 필요한 부분을 재설계해야하는데 미루다보니 트래픽에 의해 자꾸 서버가 다운될 수도 있다.

두가지 예시를 들었지만 서비스와 조직, 기술 환경에 따라 정말 다양한 형태의 예시와 사례들이 있을것이고,

어떤 형태로든 이자가 눈덩이만큼 불어나 큰 피해를 줄 수 있는 계기가 될 수도 있다.

'기술 부채를 애초에 안만들면 되잖아?' 라는 질문이 뒤따라올 수 있지만,

감히 개인적인 경험에 의해 단언한다면 불가능한 이상적인 것이라 생각한다.

기술부채를 만들지 않으려면 애초에 처음부터 '잘' 만들면 된다.

잘만들기 위한 조건으로는 요구사항을 만들기 위해 충분한 기술력과 인적 자원, 시간이 있으면 된다.

그렇지만 대게 시간상의 이유로 기술부채가 생기는 것 같다.

서비스와 조직 환경에 의해 데드라인(마감일)이라는 것이 생길 수 밖에 없다.

(물론 토이 프로젝트나 회사 내부에서만 자유롭게 사용할 목적이라면 급박한 데드라인이 없다! 라고도 할 수 있지만

월급을 받는 직장인이든 창업자이든 학생이든 사람의 시간은 유한하기에 기회비용이 발생할 수 밖에 없어 이것도 데드라인의 일종이라고 주장해보겠다.)

보통은 타부서 혹은 팀원과 협업을 하다보니 서로 손발이 맞으려면 어느정도 기대에 맞게 산출물을 만들어주어야한다.

요구사항이 무엇이든지 뚝딱뚝딱 제시간내에 만들어지면 정말 좋겠지만,

제작 과정에서 발생한 이슈 혹은 클라이언트의 요구사항이 변할 수도 있으며

보유한 인적자원과 기술력의 제약으로 한계가 있을 수 있다.

그렇기에 제작과정에서 더 나은 솔루션이 있음에도 불구하고

현재 상황에 알맞는 적절한 선택지를 찾아 만들게 되고 아쉬운점은 언젠가 나중에 챙기자가 되는 것이다.

그리고 설령 제시간내에 최적의 솔루션을 찾아 기술부채 없이 만들었다고 하더라도 또 하나의 이유가 있다.

첫번째 주된 이유로는 '시간이 부족' 해서 였다면,

두번째 이유로는 '시간이 흐르면서' 기술부채가 만들어진다.

기술은 계속 발전하며 트렌드도 뒤바뀌고 운영하는 서비스가 커지고 확장되며 요구사항이 변할 수도 있다.

그렇기에 만들어진 제품(혹은 서비스)은 결국 언젠가는 레거시(Legacy)가 되어버리는 것이다.

결국 제품은 식물과 같이 끊임없이 보살펴주어야 한다.

이렇게 기술부채가 무엇인지도 알아보고

이자가 쌓이면 안좋은 일을 겪을 수도 있고

그렇다고 꼭 최선의 솔루션을 찾아갈 수도 없는 것을 알게 되었다.

그럼 개발자로서 기술부채에 대해 어떤 생각을 가지고 접근하면 좋을까?

십여년동안 나름 다양한 환경에서 개발 커리어를 쌓으며 다양한 조직과 사람들과 함께 협업을 해보았다.

누군가는 집요할정도로 아키텍쳐에 관심이 많고 클린코드를 추구하기도 하며

누군가는 '그깟거 알게 뭐야, 일단 빨리 만들고 오픈하는게 중요하지' 라고도 하며

누군가는 위의 둘 사이에서 상황을 조율하며 최적점과 타협점을 찾아 결과물을 만들어내려한다.

나 역시 상황에 따라 위의 모두 입장이 되본적도 있었다.

지극히 개인적인 깨달음에 의하면 위의 세번째의 '누군가' 와 같이 일하는 것을 지향하는게 옳다고 생각한다.

현재 목표와 상황에 집중하되

기술 부채의 무서움을 인지하고

어느정도의 방향성을 열어두고 챙길 수 있게끔 정리를 해두는 것이다.

경험과 가치관에 따라 정답이란게 없지만 올바른 방향을 계속 고민하며 추구해야하는 어려운 영역이라 생각한다.

그렇지만 개발자로서 이것을 언제나 인지하고,

기술에만 집중하는 것이 아닌 전반적인 상황을 이해하고 방향을 이끌어나갈 수 있는 것은 큰 메리트가 될 수 있다고 생각한다.