개발자라면 마주치는 기술 부채, 꼭 다 갚아야 하나요?

개발자라면 누구나 한 번쯤 기술 부채를 마주친 적이 있을 것입니다. 개발자와 협업이 잦은 디자이너나 기획자들 중에서도 ‘기술 부채로 인해 작업에 예상보다 더 많은 시간이 필요할 것 같다’라고 말하는 개발자를 보신 분이 많을 텐데요. 과연 기술 부채란 무엇이며, 어떻게 해결할 수 있는 것일까요? 오늘은 개발자, 혹은 모든 IT 서비스의 숙명이라고 할 수 있는 기술 부채에 대해 살펴보겠습니다.

기술 부채란?

기존 서비스에 기능을 추가할 때, 개발자는 보통 두 가지 방법 중에서 고민을 하게 됩니다. 하나는 약간 지저분하지만 빠르게 개발하는 것이며, 다른 하나는 시간은 더 걸리지만 깔끔하게 개발하는 것인데요. 워드 커닝햄(Ward Cunningham)은 이러한 문제를 ‘부채(Debt)’에 빗대어 설명하였습니다.

회계 상의 부채는 일종의 빚을 의미합니다. 돈을 빌리면 빠르게 투자를 진행할 수도 있지만, 재무적인 압박을 받고 이자를 지불해야 합니다. 기술 부채도 이와 비슷하다는 것인데요. 지저분한 방식으로 빠르게 개발하면, 회계상의 부채와 마찬가지로 압박을 받게 됩니다. 그리고 추후 새롭게 기능을 개발할 때 추가로 필요한 시간은 부채에 대한 이자인 셈이죠.

그러나 부채가 무조건 부정적인 것만은 아닙니다. 기업은 부채를 통해 더 많은 투자를 집행하고, 시장점유율을 높일 수 있습니다. 개인 역시 대출을 통해 살아갈 집을 구하기도 하죠. 이와 마찬가지로 기술 부채도 개발자가 새로운 기능을 빠르게 선보이는 데 있어서 중요한 역할을 하기도 합니다.

기술 부채가 발생하는 이유

사실 기술 부채의 정의만 살펴보면 쉽게 납득되지 않기도 합니다. 처음부터 깔끔한 코드로 빠르게 개발하면 된다는 생각이 들 수도 있다는 것이죠. 물론 빠르게 개발하면서 깔끔한 코드를 작성하는 것이 개발자의 실력이라고 할 수 있으며, 많은 개발자가 이를 위해 노력하고 있는데요. 그럼에도 불구하고 기술 부채는 필연적으로 발생하기 마련입니다.

(1) 개인에 의해 발생하는 기술 부채: 성장하는 개발자

우선 기술 부채는 개발자의 역량이 부족할 때 발생할 수 있습니다. 그러나 역량이 부족해서 기술 부채가 발생했다는 것은, 동시에 개발자가 성장하고 있음을 의미하기도 합니다. 예를 들어 이제 막 개발을 시작한 사람이 아무리 최선을 다해서 코드를 작성해도, 현업 개발자에게는 지저분한 코드로 보일 수 있습니다. 어떤 코드를 ‘부채'로 인식한다는 것은 어떤 것이 깔끔한 코드인지 인식하고 있다는 말과 같은 것이죠.

저 역시 마찬가지입니다. 저는 예전의 제가 작성한 코드를 볼 때면 항상 부끄러운 감정이 듭니다. 스스로 변명해 보자면 당시에는 최선을 다해서 개발했던 코드임에도 불구하고, 다시 보니 매우 지저분해 보이는 것입니다. 몇 년 전의 코드뿐만 아니라, 심지어 한 달 전에 작성한 코드마저 부채로 느껴지는 경우도 있죠. 결국 현재 제가 마주한 기술 부채는 제가 만든 것이고, 이는 제가 부족했기 때문입니다. 그러나 부족함을 느낀다는 것은, 그만큼 성장했기에 가능한 것이라고 생각합니다.

사실 이런 부채는 비단 개발자에게만 해당되는 것이 아닙니다. 기획자도 자신이 예전에 만든 기획서가 부족하다고 느낄 수 있으며, 자신의 예전 기획 때문에 새로운 기획을 추가하는 데 어려움을 겪기도 하는데요. 기획자, 디자이너, PM 등 직무에 관계없이 성장하는 사람이라면 누구나 과거 자신의 결과물에 대해 부족함을 느낍니다. 결국 누군가 부채를 마주했다는 것은 그만큼 성장해서 이전보다 더 좋은 방식에 대해 잘 알게 되었다는 것일 수도 있습니다.

(2) 팀에 의해 발생하는 기술 부채: 협업하는 팀

개발자가 기술 부채를 최소화할 만큼 성장했다고 하더라도, 부채는 얼마든지 발생할 수 있습니다. 왜냐하면 개발자마다 깔끔하다고 생각하는 코드나 선호하는 개발 방식이 다르기 때문인데요. 어떤 개발자는 A 방식을, 어떤 개발자는 B 방식을 선호할 수 있습니다. 그리고 두 방식은 서로 다른 장단점을 갖고 있는 경우가 많죠.

예를 들어 어떤 서버 개발자는 NodeJS를 선호하고, 어떤 서버 개발자는 Spring을 선호합니다. 웹 개발자 중에서는 Tailwind와 같은 아토믹(atomic) 스타일링을 선호하는 사람이 있는 반면, 시맨틱 (semantic) 스타일링을 좋아하는 사람도 있습니다. 이처럼 크게는 개발 언어와 프레임워크부터, 작게는 라이브러리나 탭 간격까지 많은 선택지에서 개발자의 선호가 갈릴 수 있는데요. 각 선택에 장단점은 있을 수 있으나, 대부분의 경우 무조건적인 정답은 없습니다.

사실 혼자 개발하는 경우에는 개인적인 선호가 기술 부채로 발전하지 않습니다. 그러나 많은 서비스는 여러 개발자에 의해 개발되고, 함께 일하다 보면 다른 사람이 작성한 코드를 변경하거나 활용해야 하는 경우가 생기기 마련입니다. 이때 해당 코드의 구조가 자신의 가치관과 다르거나 익숙하지 않은 방식인 경우, 생산성을 저해하는 부채로 받아들여지는 것입니다.

(3) 서비스에 의해 발생하는 기술 부채: 발전하는 서비스

실력 있는 개발자들이 동일한 선호와 규칙을 갖고 작업하더라도 서비스가 발전하는 과정에서 기술 부채가 발생할 수 있습니다. 예를 들어 현재 페이지처럼 콘텐츠를 보여주는 화면을 개발한다고 가정해 봅시다. 만약 첫 기획의 목표가 콘텐츠만 보여주는 페이지라면, 개발 팀은 깔끔한 코드로 빠르게 개발할 수 있을 것입니다. 그러나 조회 수, 좋아요, 댓글, 공유하기, 관련 콘텐츠 보여주기 등의 기능이 하나씩 추가되다 보면 처음 설계한 코드로 깔끔하게 개발하지 못하게 되는 경우가 생기게 됩니다. 개발팀은 새로운 기능을 포함한 코드를 다시 깔끔하게 작성할 수도 있으나, 기존의 설계를 수정하는 데에는 추가적인 시간이 필요합니다.

서비스 발전에 따른 기술 부채는 최근에 많은 스타트업이 도입하고 있는 애자일 방법론에서 더욱 쉽게 발생합니다. 애자일 방식은 처음부터 완성된 서비스와 기능을 제공하지 않고, 동작 가능한 정도로 신속하게 개발하고 실험하는 과정을 추구하는데요. 만약 처음부터 모든 기능이 포함된 페이지를 개발한다면 깔끔하게 개발할 수 있겠지만, 이는 애자일 방법론에서 추구하는 방식이 아닙니다. 결국 애자일 방법론을 추구하거나, 발전하는 서비스를 운영하고 있다면 기술 부채를 마주할 수밖에 없는 것입니다.

(4) 기술에 의해 발생하는 기술 부채: 변화하는 기술

실력 있는 개발팀이 통일된 규칙으로 깔끔한 서비스 코드를 수정한다고 하더라도 기술 부채는 발생할 수 있습니다. 바로 개발팀이 사용하는 기술 자체가 변화하기 때문인데요. 예를 들어 몇 년 전만 하더라도 웹 프론트엔드 영역에서는 jQuery가 대세였습니다. 여전히 많은 서비스에서 jQuery를 사용하고 있지만, 현재는 리액트나 뷰 등을 사용하는 곳이 많죠. 그렇게 시간이 지나면서 리액트 개발자의 수가 증가하고 생태계가 활발해지면서, 많은 기업이 자사 서비스의 기술 스택을 jQuery에서 리액트와 같은 다른 라이브러리/프레임워크로 변경하기 시작했습니다.

이렇게 과도기에 있는 서비스의 코드에는 jQuery도 들어있고, 리액트도 들어있을 것입니다. 서비스에 적용된 모든 코드를 한 번에 바꾸는 경우도 있지만, 시간과 예산이 한정적인 스타트업에게는 쉽지 않은 일이죠. 이런 상황에서 새로운 기능을 추가할 때, 기존에 jQuery로 작성되어 있는 코드는 기술 부채가 됩니다. 개발자는 jQuery를 리액트로 변경한 후에 작업을 이어나갈 수도 있고, 빠른 기능 추가를 위해 일단 새로운 기능만 리액트로 개발할 수도 있습니다.

이처럼 기술 스택의 변화는 기술 부채를 만들어냅니다. 예시와 같이 라이브러리나 프레임워크가 바뀌는 경우가 아니라, 단순히 동일한 라이브러리의 버전이 업그레이드되는 경우에도 이 같은 기술 부채는 얼마든지 발생할 수 있습니다.

기술 부채를 최소화하는 방법

앞서 말한 대로 기술 부채 자체를 원천적으로 막을 수는 없습니다. 그러나 기술 부채가 새로운 기능 추가에 병목이 되는 만큼 부채를 최소화하기 위한 노력이 필요한데요. 기술 부채를 최소화하기 위한 방법으로는 다음과 같은 것들이 있습니다.

(1) 개발자 간의 규칙(컨벤션, Convention) 설정

기술 부채를 최소화하기 위한 가장 중요하면서도 쉬운 방법 중 하나는 개발자 간의 규칙을 설정하는 것입니다. 언어나 기술 스택은 물론, 프로젝트의 디렉토리 구조나 개발 스타일에 있어서 합의가 필요하다는 뜻인데요. 합의된 규칙이 없는 상태로 개발을 진행한다면 코드는 개발자의 수만큼 다양해지고, 이는 곧 기술 부채로 돌아오게 됩니다.

규칙이라고 해서 무조건 많은 제약사항을 강제해야 한다는 뜻은 아닙니다. 어디까지 통일된 방식으로 개발하고, 어디까지 개인의 자율로 둘지 합의가 필요하다는 의미인데요. 이런 합의가 있다면 다른 개발자가 작성한 코드를 보다 쉽게 이해할 수 있게 됩니다.

그리고 개발자들이 합의 과정을 거치는 대표적인 방법 중 하나가 바로 ‘코드 리뷰'입니다. 코드 리뷰는 코드가 실제 제품에 반영되기 전에 서로의 개발 스타일을 확인하고 의견을 나누는 과정으로 대부분 깃허브(Github)를 통해 진행됩니다. 다른 개발자의 코드를 보며 더 깔끔하다고 판단되는 방식이나, 자신이 이해하지 못한 부분에 대해 이야기하는 방식이죠. 물론 탭 간격과 같은 기본적인 코딩 스타일이나 간단한 문법 같은 경우는 프리티어(prettier)나 린트(lint)와 같은 도구를 사용하여 자동적으로 반영되게끔 만드는 경우가 많습니다.

(2) 리팩터링(Refactoring)

사실 기술 부채를 청산하는 가장 대표적인 방식은 코드를 깔끔하게 수정하는 것입니다. 만약 부채가 있고, 그것이 부담이 된다면 빚을 갚으면 됩니다. 이처럼 업무 속도를 크게 저해할 정도로 기술 부채가 쌓였다고 판단되면, 지저분하다고 생각되는 코드를 깔끔하게 변경하면 되는 것이죠. 이렇게 결과의 변경 없이 코드의 구조를 재조정하는 것을 소프트웨어 분야에서는 ‘리팩터링'이라고 부릅니다.

(3) 테스트 코드 작성

리팩터링을 하면 기술 부채를 해결할 수 있으나, 결과의 변경 없이 기존의 코드를 재설계하기란 생각보다 어렵습니다. 특히 코드가 지저분할수록 리팩터링의 난이도가 높아지는데요. 지저분한 코드는 예상치도 못한 버그를 발생시키기 때문입니다. 특정 코드가 영향을 주는 범위가 넓으면 수정 과정에서 서비스 전체가 먹통이 되는 경우가 생기고, 이런 상황이 반복되면 개발자들도 점차 리팩터링을 꺼려 하게 되는 것이죠.

이런 문제를 최소화하기 위한 대표적인 방법이 바로 ‘테스트 코드'입니다. 테스트 코드란, 기능을 수행하는 코드가 실제로 잘 작동하는지 확인하는 시나리오 같은 것인데요. 테스트 코드가 잘 구축되어 있다면 리팩터링을 진행할 때 두려워하지 않아도 됩니다. 다른 곳에 영향을 주는지 전전긍긍할 필요 없이, 테스트 코드를 돌려보면 되는 것이죠. 만약 테스트 코드가 실패하면, 실패한 부분만 찾아가서 고치면 됩니다. 최근에는 기능을 개발할 때, 아예 테스트 코드부터 작성하는 테스트 주도 개발(TDD, Test Driven Development) 방법론이 떠오르고 있기도 합니다.

가장 중요한 것은 소통과 협업

위에서 언급한 것 외에도 기술 부채를 감소시킬 수 있는 방법은 많습니다. 그러나 이러한 일련의 과정도 당장의 개발 속도를 늦출 수 있는데요. 결국 현재 서비스와 회사의 상황을 잘 고려하여 선택하는 것이 중요합니다.

기업이 빚을 갚는데만 신경 쓰면 성장하지 못하고 시장에서 도태됩니다. 반대로 빚으로 성장하다 보면 나중에 이자를 내지 못해 파산할 수도 있죠. 마찬가지로 어떤 개발자는 기술 부채를 보면 자신의 마음에 들 때까지 수정하려고 합니다. 그리고 어떤 PM은 당장의 개발 속도만 중시하기도 하는데요. 우리는 그 사이에서 서로 소통하며 현재 상황을 파악할 수 있어야 합니다.

다시 말씀드리자면, 기술 부채를 완전히 피하기는 어렵습니다. 그러나 이왕 갖고 있는 부채라면, 여러분과 서비스의 성장을 촉진시킬 수 있는 연료로 잘 활용해 보는 것은 어떨까요?

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.