맨위로가기

기술 부채

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

기술 부채는 소프트웨어 개발 과정에서 발생하는 개념으로, 현재의 편의를 위해 최적화되지 않은 설계를 선택하여 미래에 추가적인 비용과 문제를 발생시키는 것을 의미한다. 이는 개발 초기 단계의 요구 사항 불충분, 비즈니스 압박, 코드 품질 저하, 문서화 부족 등 다양한 원인으로 발생하며, 프로젝트 지연, 품질 저하, 개발자 스트레스 증가, 기업 경쟁력 약화 등 부정적인 결과를 초래한다. 기술 부채는 해프닝적, 인지된, 목표 기술 부채의 유형으로 분류되며, 미래에 대한 불확실성을 고려하여 신중하게 관리해야 한다.

더 읽어볼만한 페이지

  • 소프트웨어 유지 보수 - 소프트웨어 유지보수
    소프트웨어 유지보수는 개발 후 발생하는 변경 및 수정 활동으로, 소프트웨어 자산 가치 유지 및 시스템 수명 연장에 중요한 역할을 하며, 오류 수정, 기능 개선, 진화, 융합, 지속적인 개선 및 발전 등을 포함하고 수정, 예방, 적응, 완전화 유지보수 등으로 분류된다.
  • 소프트웨어 유지 보수 - 패치 (컴퓨팅)
    소프트웨어나 데이터의 오류 수정, 보안 강화, 기능 추가 등을 목적으로 추가되는 작은 코드나 파일을 패치라고 한다.
  • 은유 - 로제타석
    로제타석은 프톨레마이오스 5세 시대에 제작된 흑색 화강섬록암 돌로, 상형 문자, 민중 문자, 고대 그리스어 세 가지 언어로 동일한 내용이 기록된 기원전 196년 칙령이며, 고대 이집트 문자 해독에 결정적인 역할을 했다.
  • 은유 - 엔디언
    엔디언은 컴퓨터 메모리에 다중 바이트 데이터를 저장하는 방식으로, 큰 단위 바이트가 앞에 오는 빅 엔디언과 작은 단위 바이트가 앞에 오는 리틀 엔디언으로 나뉘며, CPU 종류에 따라 다르지만 빅/리틀 엔디언을 모두 지원하는 바이 엔디언과 2바이트 단위로는 빅 엔디언, 1바이트 단위로는 리틀 엔디언인 미들 엔디언도 존재한다.
  • 안티패턴 - 난독화
    난독화는 프로그램 코드의 가독성을 낮춰 이해를 어렵게 하는 기술로, 역공학을 방지하여 보안을 강화하며 소스 코드와 바이너리 난독화로 구분되고, 코드 분석을 어렵게 만들지만 불가능하게 하지는 않아 다른 보안 기술과 함께 사용된다.
  • 안티패턴 - 도덕적 해이
    도덕적 해이는 원래 보험 가입자의 부도덕한 행위를 지칭하는 용어에서 시작하여, 현재는 정보 비대칭으로 인해 한 당사자의 행동이 다른 당사자에게 해를 끼치는 상황을 의미하며, 금융 위기 등 다양한 분야에서 경제 주체들의 위험한 행동을 유발하는 요인으로 작용한다.
기술 부채
기술 부채 개요
유형고의적 기술 부채
부주의한 기술 부채
원인시간 제약
비즈니스 압박
시장 출시 시간
지식 부족
의사소통 부족
변경 사항의 연쇄 효과
결과유지보수성 저하
예측 불가능한 결과
예상치 못한 지출
낮은 품질
성능 저하
개발자 생산성 저하
보안 취약성 증가
비즈니스 가치 실현 시간 지연
시스템 작동 중단 위험 증가
해결 방법코드 검토
리팩토링
자동화 테스트
소프트웨어 아키텍처 개선
기술 부채 관리 시스템
위험 완화
정기적인 기술 부채 해결
추가 정보
관련 개념소프트웨어 엔트로피
소프트웨어 유지보수
소프트웨어 아키텍처
리팩토링
디자인 패턴
참고 자료Techopedia의 기술 부채 정의
마틴 파울러의 기술 부채
관련 용어디자인 부채, 코드 부채, 테스트 부채, 문서 부채, 인프라 부채

2. 원인

기술 부채는 소프트웨어 개발의 여러 단계에 걸쳐 다양한 원인으로 발생한다. 주요 원인은 다음과 같이 정리할 수 있다.

단계원인
개발 초기 단계
개발 및 유지보수 단계
리팩토링 및 관리 단계



위 표에서 개발 초기 단계, 개발 및 유지보수 단계, 리팩토링 및 관리 단계에서 발생하는 원인들은 하위 섹션에서 상세히 다루고 있으므로 여기서는 간략하게 언급만 하고 넘어가며, 중복을 피한다.
병렬 개발여러 브랜치에서 병렬 개발을 수행하면 변경 사항을 단일 소스 기반으로 병합하는 데 필요한 작업이 늘어나 기술 부채가 발생한다. 특히 격리된 상태에서 변경 사항이 많을수록 부채는 더욱 커진다.

2. 1. 개발 초기 단계


  • 초기 정의 부족: 개발 초기 단계에서 요구 사항이 명확하게 정의되지 않으면, 개발이 진행되면서 설계를 변경해야 하는 상황이 발생한다.[7] 이는 시간을 절약하기 위해 수행되지만 나중에 다시 작업해야 하는 경우가 많다.
  • 비즈니스 압박: 비즈니스에서 필요한 변경 사항이 완료되기 전에 무언가를 더 빨리 출시하는 것을 고려하여, 해당 미완료 변경 사항과 관련된 기술 부채를 축적한다.
  • 프로세스 또는 이해 부족: 비즈니스에서 기술 부채 개념을 알지 못하고, 그 영향을 고려하지 않고 결정을 내린다.

2. 2. 개발 및 유지보수 단계

소프트웨어는 지속적으로 개선되지만, 이 과정에서 기존 솔루션이 최적화되지 않은 상태로 남을 수 있다. 긴밀하게 결합된 컴포넌트는 함수가 모듈화되지 않아, 소프트웨어가 비즈니스 요구 사항의 변화에 적응할 수 있을 만큼 유연하지 않게 만든다. 테스트 스위트가 부족하면, 빠르고 위험한 땜질 버그 수정을 유발한다.[8] 소프트웨어 문서화가 부족하면, 코드를 이해하고 유지보수하는 데 어려움이 발생한다.[8] 지식이 조직 전체에서 공유되지 않거나, 주니어 개발자가 적절하게 멘토링을 받지 못하면 협업 부족으로 이어진다.

2. 3. 리팩토링 및 관리


  • 지연된 코드 리팩토링: 프로젝트 요구 사항이 발전하면서 코드 일부가 비효율적이거나 편집하기 어려워질 수 있다. 향후 요구 사항을 지원하려면 리팩토링이 필요하지만, 이를 미루면 기술 부채가 커진다.[9]
  • 표준과의 정렬 부족: 업계 표준 기능, 소프트웨어 프레임워크 및 기술을 무시하면 결국 표준과의 통합에 더 많은 비용이 발생한다. 이는 "지연된 리팩토링"과 유사하다.[9]
  • 지식 부족: 개발자가 적절한 코드를 작성하는 방법을 모르면 기술 부채가 발생한다.[9]
  • 소유권 부족: 아웃소싱된 소프트웨어 작업으로 인해 사내 엔지니어링에서 해당 코드를 리팩토링하거나 재작성해야 할 때 기술 부채가 발생한다.
  • 형편없는 기술 리더십: 잘못된 의사 결정은 팀 전체의 생산성을 저하시킨다.
  • 막바지 명세 변경: 갑작스러운 요구사항 변경은 프로젝트 전체에 영향을 줄 수 있지만, 변경 사항을 문서화하고 테스트할 시간이나 예산이 부족하여 기술 부채로 이어진다.[7]
  • 게으름: 직원들이 코드 가독성 및 문서화에 노력을 기울이지 않거나, 관련 인센티브가 없으면 기술 부채가 증가한다.

3. 기술 부채의 유형 (케니 루빈의 분류)

케니 루빈(Kenny Rubin)은 기술 부채를 우연히 발견된 기술 부채, 알려진 기술 부채, 목표 기술 부채의 세 가지 유형으로 분류한다.[10][22]

3. 1. 우연히 발견된 기술 부채

개발 과정에서 예상치 못하게 발견되는 부채이다. 예를 들어, 제품에 새로운 기능을 추가하는 과정에서, 오래전에 팀을 떠난 누군가가 코드에 임시 방편을 구축해 놓았다는 것을 깨닫는 경우가 이에 해당한다.[10]

3. 2. 알려진 기술 부채

개발팀이 알고 있으며 다양한 방식을 통해 가시화된 부채이다. 케니 루빈(Kenny Rubin)은 이를 인지된 기술 부채라고도 칭한다.[10][22]

3. 3. 목표 기술 부채

개발팀이 인지하고 있으며 해결을 목표로 하는 부채이다.[10][22]

4. 결과

기술 부채는 프로젝트의 성공에 다양한 부정적인 영향을 미친다. 기술 부채의 "이자 지급"은 필요한 유지보수와 프로젝트 다른 사용자들이 유지보수를 하지 않음으로써 발생하며, 상위 프로젝트의 지속적인 개발은 미래에 "부채를 갚는" 비용을 증가시킬 수 있다. 부채는 단순히 완료되지 않은 작업을 완료함으로써 갚을 수 있다.

메이어 매니 레만은 "진화하는 프로그램은 지속적으로 변경되면서 구조가 악화되어 복잡성이 증가한다. 만약 이를 유지하거나 줄이기 위한 작업이 수행되지 않는다면 말이다."라고 말했다.[11]

워드 커닝햄은 "최초 코드를 출시하는 것은 빚을 지는 것과 같다. 약간의 부채는 재작성으로 즉시 갚는 한 개발 속도를 빠르게 한다... 위험은 부채를 갚지 않을 때 발생한다. 제대로 되지 않은 코드에 소비되는 모든 시간은 그 부채에 대한 이자로 계산된다."라고 기술 부채의 위험성을 경고했다.[12]

그래디 부치는 기술 부채를 도시의 인프라에 비유하며, "사용자는 변덕스러운 복잡성, 개선의 지연, 그리고 불충분한 점진적 변화의 결과에 고통받으며, 그러한 시스템을 진화시키는 개발자는 항상 뒤처져 따라잡으려 하기 때문에 양질의 코드를 작성할 수 없다는 고통을 겪는다."라고 설명했다.[1]

4. 1. 프로젝트 지연 및 실패

기술 부채가 쌓이면 유지보수 및 기능 추가에 더 많은 시간이 소요되어 프로젝트가 지연될 수 있다. 부채의 양을 정확히 예측하기 어려워 프로젝트 일정을 관리하기 어려워진다.[11]

기술 부채의 증가는 프로젝트가 마감일을 놓치는 주요 원인 중 하나이다. 부채를 갚는 데 필요한 작업량을 정확하게 예측하기 어렵기 때문이다. 프로젝트에서 완료해야 할 미완료 작업, 즉 부채가 이를 완료할 시간보다 많다는 것을 깨달을 때 마감일을 놓치게 된다. 예측 가능한 릴리스 일정을 갖기 위해서는 개발팀이 항상 미완료 작업(또는 부채)의 양을 작게 유지하기 위해 진행 중인 작업량을 제한해야 한다.[12]

프로젝트에서 제출에 지장이 없을 만큼 충분한 작업이 완료되면, 상당한 양의 기술 부채를 여전히 안고 있는 프로젝트가 릴리스될 수 있다. 이 소프트웨어가 프로덕션 환경에 도달하면, 기술 부채를 해결하기 위한 향후 리팩토링을 구현하는 위험이 크게 증가한다. 프로덕션 코드 수정은 서비스 중단의 위험, 실제 금전적 손실, 그리고 서비스 수준 협약(SLA)을 동반하는 계약의 경우 법적 처벌의 위험을 수반한다. 이러한 이유로, 기술 부채를 프로덕션 환경으로 이전하는 것은 마치 "이자율 증가"와 같이 볼 수 있으며, 이자율이 감소하는 유일한 시점은 배포가 중단되고 폐기될 때이다.[13][14]

4. 2. 품질 저하 및 위험 증가

기술 부채가 있는 상태로 소프트웨어가 출시되면, 프로덕션 환경에서 여러 위험이 증가한다. 프로덕션 코드를 수정하는 것은 서비스 중단, 실제 재정적 손실, 그리고 서비스 수준 협약(SLA)을 포함하는 계약의 경우 법적 처벌의 위험을 수반한다.[11] 이러한 이유로 기술 부채를 프로덕션 환경으로 이전하는 것은 이자율이 높아지는 것으로 볼 수 있으며, 이자율이 낮아지는 유일한 시점은 배포가 중단되고 폐기될 때이다.

메이어 매니 레만은 "진화하는 프로그램은 지속적으로 변경되면서, 구조가 악화되어 복잡성이 증가한다. 만약 이를 유지하거나 줄이기 위한 작업이 수행되지 않는다면 말이다."라고 말했다.[11] 워드 커닝햄은 "최초 코드를 출시하는 것은 빚을 지는 것과 같다. 약간의 부채는 재작성으로 즉시 갚는 한 개발 속도를 빠르게 한다... 위험은 부채를 갚지 않을 때 발생한다. 제대로 되지 않은 코드에 소비되는 모든 시간은 그 부채에 대한 이자로 계산된다."라고 기술 부채의 위험성을 경고했다.[12]

그래디 부치는 기술 부채를 도시의 인프라에 비유하며, "사용자는 변덕스러운 복잡성, 개선의 지연, 그리고 불충분한 점진적 변화의 결과에 고통받으며, 그러한 시스템을 진화시키는 개발자는 항상 뒤처져 따라잡으려 하기 때문에 양질의 코드를 작성할 수 없다는 고통을 겪는다."라고 설명했다.[1]

4. 3. 개발자 및 조직에 미치는 영향

기술 부채는 개발자와 조직 전체에 부정적인 영향을 미친다.
개발자 스트레스 증가 및 이직률 증가형편없이 설계된 코드는 개발자의 스트레스를 높이고, 결국에는 회사를 떠나게 만들 수 있다.[14] 특히, 우수한 개발자를 구하기 어려운 한국 IT 기업의 현실을 고려하면, 이는 기업에 큰 손실로 이어진다.
생산성 저하기술 부채는 기능 개발 속도를 늦춘다.[14] 경쟁이 치열한 IT 업계에서, 이는 기업의 경쟁력을 떨어뜨리는 주요 원인이 된다. 시간이 지날수록 잘 설계된 경쟁 제품이 기능을 따라잡기 쉬워진다.[14]
예측 불가능성 증가코드의 복잡성이 증가하면, 개발 일정을 정확하게 예측하기 어려워진다.[14] 이는 프로젝트 마감일을 놓치는 주요 원인이 된다.[14]

워드 커닝햄은 기술 부채를 "제대로 작성되지 않은 코드에 소비되는 모든 시간은 그 부채에 대한 이자로 계산된다."라고 비유했다.[12] 메이어 매니 레만은 "진화하는 프로그램은 지속적으로 변경되면서, 구조가 악화되어 복잡성이 증가한다. 만약 이를 유지하거나 줄이기 위한 작업이 수행되지 않는다면 말이다."라고 언급하며 기술 부채의 위험성을 경고했다.[11]

그래디 부치는 기술 부채를 도시의 낡은 인프라에 비유하며, "사용자는 변덕스러운 복잡성, 개선의 지연, 그리고 불충분한 점진적 변화의 결과에 고통받으며, 그러한 시스템을 진화시키는 개발자는 항상 뒤처져 따라잡으려 하기 때문에 양질의 코드를 쓸 수 없다는 고통을 겪는다."라고 설명했다.[1]

4. 4. 기술 부채와 관련된 인물


  • 워드 커닝햄(Ward Cunningham): 1992년에 기술 부채라는 개념을 처음 제시했다.[12] 그는 최초 코드를 출시하는 것을 빚을 지는 것에 비유하며, 약간의 부채는 개발 속도를 높일 수 있지만, 갚지 않으면 위험이 커진다고 설명했다.
  • 메이어 매니 레만(Meir Manny Lehman): 진화하는 프로그램의 복잡성 증가에 대한 법칙을 제시했다.[11] 그는 프로그램이 지속적으로 변경되면서 구조가 악화되고 복잡성이 증가한다고 언급했다.
  • 조슈아 케리에프스키(Joshua Kerievsky): '설계 부채'라는 개념을 통해 아키텍처 부주의의 위험성을 강조했다.[13]
  • 그래디 부치(Grady Booch): 도시 개발과 소프트웨어 개발을 비교하며, 리팩토링 부족이 기술 부채로 이어진다고 설명했다.[1]
  • 주네이드 알리(Junade Ali): 기술 부채를 해결하지 않으면 경쟁력 약화, 개발자 스트레스 증가, 생산성 저하 등의 문제가 발생한다고 경고했다.[14]

5. 가정

기술 부채는 현재의 편의를 위한 설계가 당장의 비용은 줄이지만, 미래에 추가적인 비용을 발생시킨다는 가정에 기반한다. 이러한 전제는 미래에 대한 가정을 포함한다.[1]

5. 1. 미래에 대한 불확실성

미래는 불확실하기 때문에, 오늘날 인식되는 기술 부채가 실제로 미래에는 절약으로 보일 수도 있다. 부채 시나리오가 더 가능성이 높다고 여겨지지만, 이러한 불확실성은 설계 결정을 더욱 복잡하게 만든다.[1]

기술 부채를 평가할 때는 일반적으로 직원의 작업 시간만을 고려하지만, 훈련, 라이선스, 도구, 서비스, 하드웨어, 기회 비용 등 설계 결정으로 인해 발생하거나 연기된 다른 비용도 포함하여 종합적으로 평가해야 한다.[1]

미래에 대한 가정은 다음과 같다.[1]

  • 제품이 실제로 미래 비용을 발생시킬 만큼 오래 유지된다는 것
  • 미래의 사건이 편의적인 설계가 만들어지자마자 "장기적인" 설계를 무효화하지 않는다는 것
  • 미래의 발전으로 인해 재작업이 현재의 가정보다 더 비싸지지 않는다는 것

참조

[1] 서적 Refactoring for Software Design Smells Morgan Kaufmann 2014-11
[2] 웹사이트 Definition of the term "Technical Debt" (plus, some background information and an "explanation") https://www.techoped[...] 2016-08-11
[3] 간행물 Managing Technical Debt 2012-05
[4] 웹사이트 Technical Debt – Bad metaphor or worst metaphor? http://ronjeffries.c[...] 2015-11-10
[5] 웹사이트 Averting a 'Technical Debt' Crisis https://www.linkedin[...] 2016-04-07
[6] 간행물 Managing technical debt in software engineering (dagstuhl seminar 16162) https://drops.dagstu[...] 2016
[7] 서적 Proceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement Association for Computing Machinery 2018-10-11
[8] 서적 Refactoring for Software Design Smells: Managing Technical Debt https://books.google[...] Elsevier Science 2014-11-11
[9] 서적 Managing Software Debt: Building for Inevitable Change (Adobe Reader) https://books.google[...] Addison-Wesley Professional 2010-12-10
[10] Citation Essential Scrum. A Practical Guide to the Most Popular Agile Process Addison-Wesley 2013
[11] 간행물 Laws of Software Evolution Revisited http://dl.acm.org/ci[...] 2014-11-19
[12] 웹사이트 The WyCash Portfolio Management System http://c2.com/doc/oo[...] 1992-03-26
[13] 서적 Refactoring to Patterns Addison-Wesley
[14] 서적 Mastering PHP Design Patterns {{!}} PACKT Books https://www.packtpub[...] Packt Publishing Limited 2017-12-11
[15] 서적 Refactoring for Software Design Smells Morgan Kaufmann 2014-11
[16] 웹사이트 Definition of the term "Technical Debt" (plus, some background information and an "explanation") https://www.techoped[...] 2016-08-11
[17] 간행물 Managing Technical Debt 2012-05
[18] 웹사이트 Technical Debt – Bad metaphor or worst metaphor? http://ronjeffries.c[...] 2015-11-10
[19] 웹사이트 Averting a 'Technical Debt' Crisis https://www.linkedin[...] 2016-04-07
[20] 서적 Refactoring for Software Design Smells: Managing Technical Debt https://books.google[...] Elsevier Science 2014-11-11
[21] 서적 Managing Software Debt: Building for Inevitable Change (Adobe Reader) https://books.google[...] Addison-Wesley Professional 2010-12-10
[22] Citation Essential Scrum. A Practical Guide to the Most Popular Agile Process Addison-Wesley 2013
[23] 서적 Refactoring for Software Design Smells Morgan Kaufmann 2014-11
[24] 웹인용 Definition of the term "Technical Debt" (plus, some background information and an "explanation") https://www.techoped[...] 2016-08-11
[25] 저널 Managing Technical Debt 2012-05


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com