---
title: "기술 부채 어떻게 상환할까?"
description: "기술 부채는 ‘가장 효과적인 솔루션이 아닌 가장 빠른 솔루션을 선택하면서 발생한 추가 작업 비용’입니다. 이를 잘 관리하면 개발을 진전시키는 데 도움이 되죠. 그러나 기술 부채를 잘 관리하지 못하면 개발 생산성과 비즈니스에 부정적 영향을 미칠 수 있습니다. 이 글은 기술 부채 개념과 유형, 해결 방법, 인포그랩 프로덕트 팀의 기술 부채 관리 방식을 다뤘습니다."
url: https://insight.infograb.net/blog/2024/06/05/technical-debt-return/
source: content/generated/blog/2024-06-05-technical-debt-return.md
---

안녕하세요. 인포그랩 프로덕트 팀에서 백엔드 엔지니어로 근무하는 Andy입니다. 프로젝트를 진행하다 보면 여러 가지 이유로 기술 부채가 쌓이는데요.  기술 부채를 어감상 부정적으로 생각하기 쉽지만 모든 기술 부채가 나쁜 건 아닙니다. 이를 잘 관리하면 개발을 진전시키는 데 도움이 되죠. 그러나 기술 부채를 잘 관리하지 못하면 개발 생산성과 비즈니스에 부정적 영향을 미칠 수 있는데요. 따라서 평소 기술 부채 특징과 관련 모범 관행을 학습하는 건 매우 중요합니다. 이 글에서는 기술 부채 개념과 유형, 해결 방법을 살펴보고, 인포그랩 프로덕트 팀의 기술 부채 관리 방식을 소개하겠습니다.

## 기술 부채 개념과 유형

‘기술 부채(Technical Debt)’ 용어 정의는 1992년 컴퓨터 프로그래머 워드 커닝햄이 고안했습니다. 이는 ‘시간이 더 걸릴 수 있는 더 나은 접근 방식을 취하는 대신 **쉽지만 제한된 솔루션을 선택할 때 필요한, 향후 재작업의 암묵적 비용**’입니다. 또는 ‘가장 효과적인 솔루션이 아닌 가장 빠른 솔루션을 선택하면서 발생한 추가 작업 비용’을 뜻하기도 하죠.

소프트웨어 엔지니어인 크리스 리코미니, 드미트리 리아보이는 『필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생』에서 기술 부채를 이렇게도 설명합니다.

> 금융 부채와 마찬가지로 기술 부채에도 원금과 이자가 있다. **원금은 수정해야 할 원래의 단점**을 의미한다. **이자는 본질적인 단점을 수정하지 않고 코드를 개선할 때 발생하는 비용**을 뜻하며, 차선책을 택해 구현하면서 점차 복잡도가 올라가는 것을 의미한다. 이와 같은 차선책이 계속 복제되고 자리를 잡다 보면 이자도 더 늘어난다. 점점 더 많은 코드가 복잡해지고 결함도 생겨난다.

기술 부채 개념은 시간이 지나면서 더 구체화됐는데요. 2009년 소프트웨어 엔지니어 마틴 파울러는 기술 부채를 2차원 매트릭스로 설명하며, 아래 그림과 같이 유형을 구분했습니다.

![마틴 파울러의 기술 부채 2차원 매트릭스. 출처=마틴 파울러 홈페이지](/img/blog/2024-06-05-technical-debt-return-inline-01.png)
*마틴 파울러의 기술 부채 2차원 매트릭스. 출처=마틴 파울러 홈페이지*

위 그림을 보면 다음과 같은 기준이 있죠.

- Reckless(신중하지 못한), Prudent(신중한)
- Inadvertent(의도하지 않은), Deliberate(의도적인)

위 기준을 중심으로 4가지 기술 부채 유형을 자세히 알아보겠습니다.

### 1. 신중하고 의도적인 기술 부채(Prudent & Deliberate)

이는 팀이 부채를 지고 있다는 걸 알지만 ‘더 빠른 출시 보상이 부채 상환 비용보다 더 큰지’ 여부를 고려한 건데요. 이러한 기술 부채는 개발 속도와 출시일의 트레이드오프를 신중히 고려한, 실용적인 결과입니다. 보편적으로 발생하는 기술 부채 유형이기도 하고요. 신중하고 의도적인 기술 부채는 위 그림에서 “We must ship now and deal with consequences(지금 출시하고, 결과를 처리해야 한다)”에 해당합니다.

### 2. 신중하지 못하고, 의도적인 기술 부채(Reckless & Deliberate)

이는 좋은 설계 관행을 알고, 실천할 수 있지만 깔끔한 코드를 작성할 시간이 없어 ‘빠르고 지저분하게’ 진행하기로 한 결과인데요. 이러한 기술 부채는 팀이 출시일 압박을 받을 때 생기고요. 고객의 긴급한 요구사항을 맞춰야 할 때, 예기치 못한 장애로 기능을 급히 수정해야 할 때 충분한 설계 없이 개발하다 이 부채가 발생할 수도 있습니다. 신중하지 못하고, 의도적인 기술 부채는 위 그림에서 “We don’t have time for design(설계할 시간이 없다)”에 해당합니다.

### 3. 신중하되, 의도하지 않은 기술 부채(Prudent & Inadvertent)

이는 좋은 소프트웨어를 개발했고, 코드도 깔끔했지만 시간이 지나서야 ‘설계가 어땠어야 한다’는 걸 깨달은 결과입니다. 이러한 기술 부채는 성장 과정에서 자연스럽게 나타나죠. 예를 들어, 웹 애플리케이션을 개발할 때, 초기 설계 단계에서 모든 데이터를 단일 데이터베이스(DB)에 저장하도록 구현했는데요. 당시에 최적의 선택이었더라도 나중에 DB 부하가 커져 분산 DB로 전환해야 하면 이 부채가 생긴 걸로 볼 수 있습니다. 신중하되, 의도하지 않은 기술 부채는 위 그림에서 “Now we know how we should have done it(‘우리가 어떻게 해야 했는지’ 이제 알겠다)”에 해당합니다.

### 4. 신중하지 못하되, 의도하지 않은 기술 부채(Reckless & Inadvertent)

이는 잘 몰라서 발생한 결과인데요. 위 그림에서 “What’s layering?(계층화가 뭐야?)”에 해당합니다.

## 기술 부채 해결 방법

![출처=픽사베이](/img/blog/2024-06-05-technical-debt-return-inline-02.png)
*출처=픽사베이*

기술 부채가 항상 나쁜 건 아닙니다. 크리스 리코미니, 드미트리 리아보이는  『필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생』에서 “나중에라도 팀이 해결 가능하도록 훈련된 부채라면 이는 ‘좋은 부채’라 할 수 있다”고 설명하죠. 아울러 **기술 부채를 적절히 관리하면 개발을 진전**시키는 데 도움이 됩니다.

그러나 기술 부채는 비즈니스에 부정적 영향을 미칠 수 있으므로 해결해야 하는데요. 이는 버그로 나타나 사용자 경험을 저하할 수 있습니다. 아울러 기술 부채가 악화하면, 개발자가 기존 코드베이스 안에서 작업하기 더 힘들어지고요. **새로운 기능을 개발하고, 기존 기능을 수정하는 데 시간을 쪼개어 쓰느라 소프트웨어 개발 라이프사이클이 느려지고, 시장 출시 시기가 미뤄질 수 있죠.** 그렇다면 기술 부채를 어떻게 관리, 해결하면 좋을까요? 

(아래 내용은 미국 소프트웨어 기업 Asana, 크리스 리코미니와 드미트리 리아보이 저서 『필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생』, 웹 개발자 출신이자 캐나다 웹 디자인 기업 Norlink 대표 리앤 민튼의 Splunk 기고 글, 래티스 주식회사 공동 창업자이자 CPO 이재하 님(필명 ‘호박너구리’)의 요즘 IT 기고 글에서 제언한 방법을 모아 정리했습니다.)

### 1. 기술 부채 목록 관리

프로젝트를 회고해 기술 부채를 목록으로 정리, 공유합니다. 아울러 기술 부채가 발생할 때마다, 이 부채를 해결하는 데 필요한 작업을 예상되는 노력, 일정과 함께 기록하고요. 또 팀에서 기술 부채 해결 여부와 해결 시점을 논의하고, 해결 방안을 수립합니다. 이는 기술 부채를 계획적으로 해결하는 데 도움이 됩니다. 한편, 90일 이상 해결되지 않은 기술 부채는 ‘중요한 부채’로 취급해야 하고요.

### 2. 좋은 기술 부채와 나쁜 기술 부채 구분

좋은 기술 부채와 나쁜 기술 부채를 구분합니다. 이렇게 기술 부채를 구분하면 가장 큰 문제의 우선순위를 정하는 데 도움이 되죠. 참고로 기술 부채 때문에 애플리케이션이 장애를 일으키거나 보안 결함이 노출되면, 이러한 문제를 먼저 해결해야 합니다. 

### 3. 리팩토링

업무를 수행하면서 필요한 부분을 정리하고 조금씩 리팩토링합니다. 간혹 대규모로 리팩토링해야 할 때도 있는데요. 이때 팀에 상황을 공유하고 기술 부채 위험과 비용을 알립니다. 또 해결책을 제안하고, 함께 대안을 논의하며 트레이드오프를 따져보고요.

### 4. 테스트 코드 작성

코드가 복잡할수록, 리팩토링 규모가 클수록 버그 없이 코드를 한 번에 수정하기란 어렵습니다. 부작용을 방지하려면 테스트 코드를 작성해야 하는데요. 리팩토링하고 테스트 코드를 실행했을 때 문제가 있으면 그 부분만 수정하면 됩니다. 이로써 리팩토링을 안전하게 진행할 수 있죠.

### 5. 품질 표준 설정, 준수

품질 표준을 설정해 코더가 엉성한 코드를 배포하지 못하도록 합니다. 그러면 우발적인 기술 부채를 더 쉽게 피할 수 있고요. 기술 부채를 더 용이하게 관리할 수 있습니다.

### 6. 갑작스러운 규정·일정 변경 X

개발자 관련 규정을 지속적으로 변경하거나, 마감일을 바꾸면 기술 부채를 피하기 어렵습니다. 현실적인 일정, 방법론, 작업량을 제공해 기술 부채를 관리할 수 있도록 합니다.

## 인포그랩 프로덕트 팀의 기술 부채 관리 방식

인포그랩 프로덕트 팀은 코드 리뷰, 리팩토링 기간 운영, 백로그 정리, 회고를 주기적으로 진행하며 기술 부채를 관리하는데요. 구체적인 내용을 각각 살펴보겠습니다.

### 1. 코드 리뷰

![GitLab MR을 활용한 코드 리뷰 내용](/img/blog/2024-06-05-technical-debt-return-inline-03.png)
*GitLab MR을 활용한 코드 리뷰 내용*

프로덕트 팀은 코드 리뷰를 두 가지 방식으로 진행합니다. 첫째, 개발이 완료되면 GitLab에서 해당 개발 건의 Merge Request(MR)를 활용해 리뷰를 받는데요. 이 과정에서 잘못된 도메인 선정을 지적하고, 코드를 더 깔끔하게 작성하도록 피드백하죠. 프로덕트 팀 소프트웨어 엔지니어들은 리뷰 내용을 반영해 문제를 개선하며 기술 부채를 해소합니다.

둘째, 팀 회의에서 코드를 공유하며 리뷰를 받습니다. 프로덕트 팀은 매주 두 차례 팀 회의를 진행하는데요. 이 자리에서 엔지니어들은 각자 발견한 새로운 기술이나 에러 사항 또는 코드 리팩토링 내용을 공유합니다. 이로써 자기가 작성한 코드를 논리적으로 설명하고요. 동료들의 피드백을 받아 문제를 바로 잡으며 기술 부채를 줄이죠.

### 2. 리팩토링 기간 운영

![GItLab에 생성한 리팩토링 이슈](/img/blog/2024-06-05-technical-debt-return-inline-04.png)
*GItLab에 생성한 리팩토링 이슈*

프로덕트 팀은 리팩토링 기간을 운영하며, 이 기간에 코드를 전체적으로 가다듬습니다. 이는 주기적이지 않고, 팀에 여유가 있을 때 진행하는데요. GitLab에 리팩토링 이슈를 생성하고, 구체적인 리팩토링 내용과 할 일 목록을 작성하며 리팩토링을 진행하죠. 이 과정에서 기존에 작성한 코드를 세분화해 코드를 더 깔끔하게 개선합니다.

### 3. 백로그 정리와 회고

![Figma에서 정리한 백로그 목록](/img/blog/2024-06-05-technical-debt-return-inline-05.png)
*Figma에서 정리한 백로그 목록*

프로덕트 팀은 우선순위에 밀려 진행하지 못한 개발 건을 Figma로 관리합니다. 이를 토대로 다음 버전을 준비할 때 신규 개발 건과 우선순위를 비교하고 개발 여부를 결정하는데요. 이로써 기술 부채를 지속적으로 상기하고, 조금씩 없애나가죠.

이 밖에 팀에서 회고를 진행, 부족한 점과 개선할 점을 논의하고요. 이 또한 백로그로 정리해 지속적으로 기술 부채를 의식하며 관리합니다.

## 맺음말

어느 개발팀이든 기술 부채는 필연적으로 마주치기 마련입니다. 기술 부채를 무조건 나쁘게 생각하고 스트레스를 받으며 이를 한 번에 다 해결하는 건 무리가 있고요. 이러한 접근 방식은 시간이 지나 기술 부채가 더 쌓였을 때 더 괴로울 수 있죠. 물론 ‘기술 부채가 어쩔 수 없는 것’이란 생각에 이를 안이하게 대처해서도 안 됩니다. 개발 생산성과 비즈니스에 부정적 영향을 미칠 수 있으니까요. 기술 부채의 불가피성을 인정하되, 지혜롭게 이를 관리하고 피해를 최소화하도록 모범 관행을 학습하고요. 우리 조직에 맞는 기술 부채 관리 방식을 확립해 개발 생산성과 품질, 비즈니스 성과를 향상하는 데 기여해야 합니다.

::cta::

## 참고 자료

1. 크리스 리코미니, 드미트리 리아보이 저, 장현희 역. 『필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생』
2. [Martin Fowler. "Technical Debt Quadrant." Martin Fowler’s Bliki](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html)
3. [이재하. "개발자들이 꼭 알아야 할 기술 부채 관리법." 요즘IT](https://yozm.wishket.com/magazine/detail/1331/.)
4. [Asana. "What is technical debt? How to pay it off (with examples)"](https://asana.com/ko/resources/technical-debt)
5. [Leanne Mitton. "Technical Debt & How To Manage It". Splunk](https://www.splunk.com/en_us/blog/learn/technical-debt.html)
6. [Wikipedia. "Technical debt"](https://en.wikipedia.org/wiki/Technical_debt)

::faq::

- q: 기술 부채란 무엇인가요?

    a: 기술 부채(Technical Debt)는 시간이 더 걸리는 나은 방법 대신 쉽지만 제한된 해법을 고를 때 생기는, 향후 재작업의 암묵적 비용입니다. 이 용어는 1992년 프로그래머 워드 커닝햄이 고안했습니다. 크리스 리코미니와 드미트리 리아보이는 기술 부채에도 금융 부채처럼 원금과 이자가 있다고 설명하는데, 원금은 고쳐야 할 원래의 단점이고 이자는 그 단점을 고치지 않고 차선책을 쌓으며 늘어나는 복잡도 비용입니다.

- q: 기술 부채에는 어떤 유형이 있나요?

    a: 2009년 마틴 파울러는 신중한지(Prudent)·신중하지 못한지(Reckless), 의도적인지(Deliberate)·의도하지 않았는지(Inadvertent)를 기준으로 기술 부채를 네 유형으로 나눴습니다. 출시 보상과 상환 비용을 따져 지는 신중하고 의도적인 부채가 가장 흔하고, 출시 압박에 설계 없이 서두르면 신중하지 못하고 의도적인 부채가 생깁니다. 처음엔 최선이던 단일 DB 설계를 나중에 분산 DB로 바꿔야 하는 경우는 신중하되 의도하지 않은 부채이고, 잘 몰라서 생긴 부채는 신중하지 못하고 의도하지 않은 부채입니다.

- q: 기술 부채는 항상 나쁜가요?

    a: 그렇지 않습니다. 크리스 리코미니와 드미트리 리아보이는 나중에라도 팀이 해결할 수 있도록 훈련된 부채는 좋은 부채라고 설명하며, 기술 부채를 적절히 관리하면 개발을 진전시키는 데 도움이 됩니다. 다만 관리하지 못한 부채는 버그로 나타나 사용자 경험을 떨어뜨리고, 기존 코드베이스에서 작업하기 어렵게 만들어 개발 라이프사이클과 시장 출시를 늦출 수 있습니다.

- q: 기술 부채는 어떻게 관리하고 해결하나요?

    a: Asana, 크리스 리코미니·드미트리 리아보이, Splunk 기고, 요즘IT 기고의 제언을 모으면 여섯 가지 방법이 있습니다. 기술 부채를 해결에 필요한 노력·일정과 함께 목록으로 관리하고(90일 이상 해결되지 않은 부채는 중요한 부채로 취급), 좋은 부채와 나쁜 부채를 구분해 장애나 보안 결함을 일으키는 부채부터 해결합니다. 또 업무 중 조금씩 리팩토링하고, 테스트 코드로 리팩토링을 안전하게 하며, 품질 표준을 세워 지키고, 개발 관련 규정과 일정을 갑자기 바꾸지 않아야 합니다.

- q: 인포그랩 프로덕트 팀은 기술 부채를 어떻게 관리하나요?

    a: 2024년 당시 인포그랩 프로덕트 팀은 코드 리뷰, 리팩토링 기간 운영, 백로그 정리, 회고로 기술 부채를 관리했습니다. 개발이 끝나면 GitLab Merge Request로 리뷰를 받고, 매주 두 차례 팀 회의에서도 코드를 공유해 피드백을 받았습니다. 팀에 여유가 있을 때 GitLab 이슈로 리팩토링 기간을 운영했고, 우선순위에 밀린 개발 건은 Figma 백로그로 관리하며 다음 버전 계획 때 신규 개발 건과 비교해 처리 여부를 정했습니다.

::faq-end::

::button::[우리 코드베이스의 기술 부채를 데이터로 관리하고 싶으신가요? DevOps 전문가, 인포그랩과 상담하세요!](https://insight.infograb.net/contact/)::