기술부채란 무엇이며 어떻게 예방, 해결할 수 있는가?

앱 개발 프로젝트를 진행하다 보면 ‘기술 부채’라는 개념을 알게 됩니다. 개발자와의 미팅, 혹은 사전에 앱 개발 비용과 관련된 정보를 찾다 보면 “기술 부채로 작업에 시간이 더 필요하다.”라는 얘기를 심심치 않게 마주하는데요. 오늘은 앱 개발 비용의 난제 중 하나인 기술 부채를 비개발자가 쉽게 이해할 수 있도록 자세히 안내해 드립니다.

✍️ 이 글의 순서

• 기술 부채란?
• 기술 부채를 구분하는 4가지 방법
• 기술 부채를 최소화하려면 어떻게 해야 할까
• 기술 부채 걱정된다면, ‘위시켓’하세요.

기술 부채란?

기술 부채란 개발자 워드 커닝햄이 1992년에 사용한 표현으로, ‘빠르게 개발하기 위해 나중에 처리하도록 미뤄 둔 기술적 문제’를 의미합니다. 회계상에서 나중에 갚아야 할 돈을 ‘부채’로 표현하는 것처럼, 나중에 수정해야 하지만 일단 개발을 원활히 진행하기 위해 미뤄 둔 개발 과제입니다.

어감이 좋진 않지만, 기술 부채가 항상 나쁜 것만은 아닙니다. 기업이 부채를 통해 투자를 확대하고 이후 부채를 갚아 나가면서 성장하는 것처럼, 기술 부채 역시 잘만 활용하면 빠르게 개발하여 새로운 기능이나 서비스를 선보일 수 있습니다. 다만 부채 때문에 ‘파산’하지 않도록, 기술 부채 역시 신중하고 조심스럽게 관리할 필요가 있습니다.

기술 부채를 구분하는 4가지 방법

기술 부채에는 여러 종류가 있습니다. 일반적으로 기술 부채는 ‘설계, 코드, 테스트, 인프라’로 나누어 구분합니다.

1. 설계를 제대로 하지 않았을 때 : 설계 부채

설계 단계에서 적절하게 설계하지 않았거나, 설계에서의 결함을 미처 수정하지 못해서 생긴 기술 부채를 의미합니다.

2. 좋은 품질의 코드를 작성하지 않았을 때 : 코드 부채

실제 개발 시 코드를 작성할 때 시간이나 예산이 부족하여 양질의 코드를 작성하지 않았을 때 생기는 기술 부채를 의미합니다.

3. 충분한 테스트를 수행하지 않았을 때 : 테스트 부채

개발 과정에서 테스트를 충분히 수행하지 않았거나, 테스트를 수행했어도 불완전하게 결함을 수정했을 때 발생하는 기술 부채입니다.

4. 인프라가 충분히 구축되지 않았을 때 : 인프라 부채

시스템 운영을 위한 서버나 데이터베이스 등 개발 및 운영을 위한 인프라를 충분히 구축하지 않았을 때 생기는 기술 부채입니다.

기술 부채는 주로 빠르게, 그리고 낮은 비용으로 개발할 때 발생합니다. 하지만 시간이 지나면 빚을 갚아야 하듯이, 기술 부채 역시 시간이 지나면 처리해야 할 문제로 되돌아옵니다. 중요한 건 이 기술 부채의 대가가 상상했던 것보다 더 혹독하다는 점입니다.

예를 들어 코드 부채의 경우 당장은 문제가 없을지 몰라도 시스템을 유지·보수·업그레이드할 때 엄청난 비용이 들어갑니다. 인프라 부채 역시 앱의 초기 버전은 빠르게 출시할 수 있지만 시스템 규모를 확장하거나 사용자 수가 증가할 경우 성능 저하나 서버 장애 등의 문제가 발생할 수 있습니다. 그렇다면, 처음부터 기술 부채가 쌓이지 않게 예방하고 잘 관리하는 방법에는 어떤 것들이 있을까요?

기술 부채를 최소화하려면 어떻게 해야 할까

이처럼 양날의 칼이 될 수 있는 기술 부채를 최소화하려면, 먼저 기술 부채의 원인을 파악해야 합니다. 기술 부채의 원인에는 크게 1) 개발자 2) 개발 팀 3) 서비스 팀 4) 기술이 있습니다.

1) 개발자

: 개발자의 역량이 부족하여 기술 부채가 발생할 수 있습니다.

2) 개발 팀

: 여러 개발자가 함께 협업할 때, 다른 사람이 작성한 코드를 변경하거나 활용하는 과정에서 생산성의 저하가 일어나며 기술 부채가 발생할 수 있습니다.

3) 서비스 팀

: 개발 팀이 깔끔하게 코드를 작성하더라도, 여러 서비스를 추가하거나 발전시키는 과정에서 설계를 수정하는 등 기술 부채가 발생할 수 있습니다.

4) 기술

: 개발팀이 사용하는 기술 자체가 변화할 경우 기술 부채가 발생할 수 있습니다.

여기까지 보면, 기술 부채를 최소화하기 위해서는 먼저 개인과 팀 단위로 노력해야 한다는 사실을 알 수 있습니다. 다만 개인 단위에서 노력할 일은 결국 ‘개발 실력 증진’밖에 없으므로, 팀 단위에서 해야 할 일들을 알아 두는 것이 좋습니다.

개발자 간 ‘규칙(Convention)’ 설정

앞서 말했듯이 개발 팀 단위에서 생기는 기술 부채는 결국 개발자마다 언어나 기술 스택, 디렉토리 구조나 개발 스타일이 다르기 때문에 발생하는 경우가 많습니다. 이를 예방하기 위해서는 개발자 간의 규칙, 즉 컨벤션을 설정하면 됩니다. 개발 규칙을 서로 합의한다면 작성한 코드를 보다 쉽게 이해할 수 있고, 더 좋은 품질의 코드를 작성할 수 있습니다. ‘코드 리뷰’ 같은 방법을 이용하여 서로의 개발 스타일을 확인하는 것도 추천드립니다.

리팩터링(Refactoring) 및 테스트 코드 작성

지저분한 코드를 깔끔하게 수정하는 것을 가리켜 리팩터링이라고 합니다. 사실, 기술 부채에서 대부분의 원인은 ‘코드 부채’에 있기 때문에, 리펙터링을 주기적으로 실시해 주면 기술 부채를 미리 예방할 수 있습니다.

다만 리팩터링을 자주 실시할 경우 또 다른 문제가 발생할 수 있습니다. 코드를 자주 변경하다 보면 그만큼 서비스 전체에 영향을 끼칠 수 있습니다. ‘코드 작성 – 리팩터링 – 버그 확인 – 코드 작성 – 리팩터링…’과 같은 과정을 거치다 보면 개발자들도 자연스레 리팩터링 자체를 꺼리게 됩니다.

이러한 문제를 피하기 위해 테스트 코드를 작성하는 것이 좋습니다. 테스트 코드란 기능을 수행하는 코드가 실제로 잘 작동하는지 확인하는 코드를 의미하며, 테스트 코드를 통해 어떤 상황에서도 오류나 버그가 거의 일어나지 않는 ‘단단한’ 코드를 작성할 수 있습니다. 이 때문에 테스트 코드부터 작성해 개발을 실시하는 ‘테스트 주도 개발(TDD; Test Driven Development)’ 방법론이 현재 주목받고 있기도 합니다.

🔗 ‘테스트 주도 개발’ 방법론 자세히 알아보기 >

기술 부채 걱정된다면, ‘위시켓’하세요.

기술 부채와 같은 복잡한 문제를 고민하지 않고 앱을 개발하려면 위시켓을 이용해 보시길 추천드립니다. 위시켓에서는 각 프로젝트에 1:1 전담 매니저가 배정되어, 기술 부채를 포함한 다양한 개발 이슈를 예방 및 대응하고 있습니다. 기술 부채에 의한 리스크 발생에 대비해 미팅부터 사후 관리까지 원스톱으로 지원하죠.

전문가가 아니면 기술 부채에 따른 리스크를 감지하기 어려울 수 있습니다. 하지만 크게 걱정할 필요는 없습니다. 개발을 잘 알지 못해도 믿을 수 있는 위시켓 매니저가 여러분의 프로젝트의 A to Z를 함께합니다. 앱 개발을 계획 중이라면, 아래 링크를 통해 위시켓의 서비스를 경험해 보세요.