개발자를 위한 기술 부채 실무 가이드

소프트웨어 프로젝트의 성공을 위해 알아야 할 기술 부채의 모든 것

니일 언스트 , 릭 캐스만 , 줄리엔 디레인 저자(글) · 오정민 번역

위키북스 · 2025년 01월 21일

책 소개

소프트웨어 생애 주기 전체에 걸친 기술 부채의 실질적 영향을 다양한 예시와 사례 연구를 통해 살펴보자!

소프트웨어의 기술 부채는 개발자가 프로젝트 초기 단계에서 단기적 편의성을 위해 쉬운 선택을 하거나 부적절한 기술 결정을 내릴 때 발생하며, 이는 이후에 막대한 비용과 많은 노동이 드는 해결책을 필요로 하게 된다. 이 책은 기술 부채를 예방하고, 원인을 파악하고, 이를 제거하는 방법에 대한 실질적인 조언을 제공한다. 특히, 소프트웨어 생애 주기 전반에 걸쳐 기술 부채가 미치는 실질적 영향을 중점적으로 다루며, 보잉에서 엑스(구 트위터)에 이르는 다양한 기업들의 사례와 예시를 통해 이를 구체적으로 설명한다.

기술 부채는 대부분의 반복적 개발 과정에서 자연스럽게 발생한다. 그러나 부채를 방치하면 시간이 지날수록 점점 더 복잡하고 관리하기 어려운 상황에 이르게 된다. 그 결과 개발자들은 새로운 기능을 추가하기보다는 버그 수정에만 모든 노력을 쏟게되고, 이는 궁극적으로 고객이 가장 원하는 새로운 기능을 제공하지 못하게 되는 상황으로 이어진다. 이에 저자들은 기술 부채를 어떻게 모니터링하고 측정해야 하는지, 그리고 언제, 어떻게 이를 상환해야 하는지를 구체적으로 설명한다.

이 책은 기술 부채가 가지고 있던 기존의 정의를 확장해 요구사항 부채, 구현 부채, 테스트 부채, 아키텍처 부채, 문서 부채, 배포 부채, 그리고 사회적 부채까지 다각적으로 분석한다. 또한 기술적 논의 사이에 실제 현장에서의 경험을 담은 '실무자의 목소리'를 포함하여 독자들에게 실질적이고 적용 가능한 통찰을 제공한다.

작가정보

저자(글) 니일 언스트

브리티시컬럼비아 주에 위치한 빅토리아 대학교의 컴퓨터과학 조교수이다.

저자(글) 릭 캐스만

하와이 대학교 정보기술관리학과의 데니&앨사 루이 명예 석좌교수이자 카네기 멜런 대학교 소프트웨어 엔지니어링 연구소의 객원 연구원이다. 그는 소프트웨어 아키텍처 분석 방법론인 ATAM(Architecture Tradeoff Analysis Method, 아키텍처 절충 분석 기법)과 아키텍처 분석 도구인 타이탄(Titan) 및 DV8 개발에 참여했다.

저자(글) 줄리엔 디레인

트위터(현, 엑스)의 스태프 소프트웨어 엔지니어이자 개발자가 더 나은 코드를 작성할 수 있도록 지원하는 코드 분석 플랫폼인 코드 인스펙터(Code Inspector)의 창립자이다. 줄리엔은 트위터 외에도 아마존 웹서비스, 카네기 멜런 대학교 소프트웨어 엔지니어링 연구소, 그리고 유럽우주국(European Space Agency)에서 근무한 경력이 있다.

번역 오정민

미국 USC에서 사회학과 중국학을 전공하고, 미국, 중국, 한국, 일본의 IT 업계에서 다양한 프로덕트 개발과 애자일 코칭 경험을 쌓았다. 일본에 거주하며 브로드컴 탄주 랩스(Broadcom Tanzu Labs, 구 피보탈 랩스(Pivotal Labs))에서 딜리버리 리드로서 한국과 일본을 비롯한 아시아태평양 지역의 주요 기업들을 대상으로 애자일 및 린 프로덕트 개발, 밸런스 팀 육성, 조직 문화 개선을 지원하는 컨설팅을 해왔다. 이러한 경력을 바탕으로, 현재 일본에 본사를 둔 비카인드랩스 LLC의 한국법인 대표이사 및 프로덕트 디렉터로 활동하고 있다.

목차

• ▣ 01장: 서론
  1.1 기술 부채란 무엇인가?
  1.2 메타포를 넘어서
  1.3 이번 장을 마치며
  1.4 이 책의 개요
  
  ▣ 02장: 기술 부채의 중요성
  2.1 기술 부채의 발생
  2.2 기술 부채에 어떻게 접근해야 하는가
  2.3 기술 부채의 실질적인 결과
  2.4 기술 부채 관리의 중요성
  2.5 미래의 기술 부채에 대응하는 것의 어려움
  2.6 기술 부채의 이점
  2.7 부채 발생이 허용되는 경우: 갚지 않아도 될 때
  2.8 이번 장을 마치며
  
  ▣ 03장: 요구 사항 부채
  3.1 요구 사항 부채 식별하기
  __3.1.1 요구 사항 부채의 원천
  __3.1.2 요구 사항 부채 찾아내기
  3.2 요구 사항 부채 관리하기
  3.3 요구 사항 부채 피하기
  __3.3.1 요구 사항 도출
  __3.3.2 요구 사항 수집에 대한 새로운 접근 방식
  __3.3.3 요구 사항 기록하기
  3.4 이번 장을 마치며
  
  ▣ 04장: 설계 및 아키텍처 부채
  4.1 설계 부채 식별하기
  __4.1.1 설계 부채의 수치화
  __4.1.2 관련된 정보 수집하기
  __4.1.3 수집한 정보 분석
  4.2 설계 부채 관리하기
  4.3 설계 부채 피하기
  4.4 이번 장을 마치며
  사례 연구 A: 브라이트스퀴드
  
  ▣ 05장: 구현 부채
  5.1 코드에서 기술 부채 식별하기
  __5.1.1 코딩 스타일
  __5.1.2 비효율적인 코드
  __5.1.3 오래됐거나 단계적으로 제거됐거나 안전하지 않은 함수 또는 프레임워크 사용
  __5.1.4 코드 복사: 똑같은 일을 두 번 하지 말 것
  5.2 구현 부채 관리하기
  __5.2.1 코드 분석기 사용
  __5.2.2 코딩 가이드라인 정의
  __5.2.3 새로운 언어 특징 사용
  5.3 구현 부채 피하기
  __5.3.1 언어와 라이브러리를 현명하게 선택하기
  __5.3.2 효과적인 코드 리뷰
  __5.3.3 코드베이스에서 지표를 수집하고 분석하기
  5.4 이번 장을 마치며
  
  ▣ 06장: 테스트 부채
  6.1 테스트는 어떻게 기술 부채와 연관되는가
  6.2 테스트에 대한 인식 증가
  6.3 테스트의 부족성과 필요성 식별하기
  __6.3.1 민첩성 상실과 버그의 증가
  __6.3.2 테스트 수준
  __6.3.3 적절한 수준의 테스트
  6.4 테스트 활동 관리하기
  __6.4.1 테스트 대상은 무엇인가?
  __6.4.2 코드 커버리지 측정
  6.5 테스트 부채 피하기
  __6.5.1 테스트 주도 개발의 채택
  __6.5.2 테스트 실행의 유지와 분석
  __6.5.3 테스트 자동화
  __6.5.4 수동 테스트 피하기
  6.6 이번 장을 마치며
  사례 연구 B: 트위터
  
  ▣ 07장: 배포 부채
  7.1 배포 부채 식별하기
  __7.1.1 증상 1: 프로덕션에서 즉시 발견되는 버그
  __7.1.2 증상 2: 배포 몇 주 후에 발견되는 버그
  __7.1.3 증상 3: 롤백 불가능
  __7.1.4 배포 프로세스에서 기술 부채를 구성하는 요소
  7.2 배포 부채 관리하기
  __7.2.1 배포 환경의 분리
  __7.2.2 관찰가능성으로 문제 해결하기
  __7.2.3 비기능적 지표의 추적…
  __7.2.4 …그리고 기능적 지표의 추가
  7.3 배포 부채 피하기
  __7.3.1 자동화된 점진적 배포
  __7.3.2 지속적인 통합 파이프라인에 배포 통합하기
  __7.3.3 배포 프로세스 정립
  __7.3.4 새로운 제품 기능에 킬 스위치 구현하기
  7.4 이번 장을 마치며
  
  ▣ 08장: 문서 부채
  8.1 문서화를 해야 하는 이유
  __8.1.1 독자를 위해 써라
  __8.1.2 반복하지 말라
  __8.1.3 모호함을 피하라
  __8.1.4 정리 형식을 사용하라
  __8.1.5 결정을 내린 근거를 기록하라
  __8.1.6 문서를 최신 상태로, 하지만 너무 최신은 아니게 유지하라
  __8.1.7 문서 적합성을 리뷰하라
  8.2 문서 부채 식별하기
  __8.2.1 문서화 수요 예측
  __8.2.2 문서화에 관련된 문제 인식
  __8.2.3 문서화해야 하는 내용
  __8.2.4 문서 부채가 문제가 되는 이유
  8.3 문서 부채 관리하기
  __8.3.1 코드를 작성하면서 문서화도 진행
  __8.3.2 다이어그램은 어떨까?
  __8.3.3 코드와 테스트, 문서를 모두 함께 작성
  8.4 문서 부채 피하기
  __8.4.1 추적성
  __8.4.2 출시 프로세스의 일부로서의 문서 품질 확인
  8.5 설계 및 기술 부채의 문서화
  8.6 이번 장을 마치며
  사례 연구 C: 과학 연구용 소프트웨어
  
  ▣ 09장: 머신러닝 시스템의 기술 부채
  9.1 배경
  9.2 머신러닝 부채 식별하기
  __9.2.1 설계상의 선택
  __9.2.2 통합 부채
  __9.2.3 설명가능성
  __9.2.4 시스템 구성
  __9.2.5 테스트
  9.3 머신러닝 부채 관리하기
  __9.3.1 더 간단한 접근
  __9.3.2 탐색 실험 중의 버전 관리
  __9.3.3 교차 기능 팀
  9.4 머신러닝 부채 피하기
  9.5 이번 장을 마치며
  
  ▣ 10장: 팀 관리와 사회적 부채
  10.1 사회적 부채의 정의
  10.2 사회적 부채 식별하기
  10.3 사회적 부채 관리하기
  10.4 사회적 부채 피하기
  10.5 이번 장을 마치며
  
  ▣ 11장: 비즈니스 사례 만들기
  11.1 지표를 통한 기술 부채 식별
  __11.1.1 기술 부채로 인한 경제적 영향의 수치화
  __11.1.2 기술 부채 구제 방법의 정당화
  11.2 경영진의 대응 방법
  __11.2.1 고기능 팀의 구성
  __11.2.2 가치 흐름에 초점 맞추기
  11.3 기술자들과 경영진의 방향성 일치
  __11.3.1 리얼 옵션 개념의 적용
  __11.3.2 소프트웨어 설계 움직임 추적
  11.4 이번 장을 마치며
  사례 연구 D: 안전 필수 시스템
  
  ▣ 12장: 결론

기본정보

ISBN	9791158395612
발행(출시)일자	2025년 01월 21일
쪽수	344쪽
크기	173 * 235 * 26 mm / 739 g
총권수	1권
시리즈명	위키북스 IT Leaders 시리즈