- 기술 부채 개념
- 시간이 더 걸릴 수 있는 더 나은 접근 방식을 취하는 대신 쉽지만 제한된 솔루션을 선택할 때 필요한, 향후 재작업의 암묵적 비용
- 가장 효과적인 솔루션이 아닌 가장 빠른 솔루션을 선택하면서 발생한 추가 작업 비용
- 소프트웨어 엔지니어 마틴 파울러가 구분한 기술 부채 유형
- 신중하고 의도적인 기술 부채(Prudent & Deliberate)
- 팀이 부채를 지고 있다는 걸 알지만 ‘더 빠른 출시 보상이 부채 상환 비용보다 더 큰지’ 여부 고려
- 신중하지 못하고, 의도적인 기술 부채(Reckless & Deliberate)
- 좋은 설계 관행 알고, 실천할 수 있지만 깔끔한 코드를 작성할 시간이 없어 ‘빠르고 지저분하게’ 진행하기로 한 결과
- 신중하되, 의도하지 않은 기술 부채(Prudent & Inadvertent)
- 좋은 소프트웨어를 개발했고, 코드도 깔끔했지만 시간이 지나서야 ‘설계가 어땠어야 한다’는 걸 깨달은 결과
- 신중하지 못하되, 의도하지 않은 기술 부채(Reckless & Inadvertent)
- 기술 부채 해결 방법
- 기술 부채 목록 관리
- 프로젝트 회고해 기술 부채를 목록으로 정리, 공유
- 기술 부채 발생할 때마다, 이 부채 해결에 필요한 작업을 예상되는 노력, 일정과 함께 기록
- 팀에서 기술 부채 해결 여부와 해결 시점 논의, 해결 방안 수립
- 좋은 기술 부채와 나쁜 기술 부채 구분
- 이렇게 기술 부채 구분하면 가장 큰 문제 우선순위 정하는 데 도움이 됨
- 리팩토링
- 업무 수행하면서 필요한 부분 정리, 조금씩 리팩토링
- 대규모 리팩토링할 때 팀에 상황 공유, 기술 부채 위험과 비용 알림
- 테스트 코드 작성
- 코드가 복잡할수록, 리팩토링 규모가 클수록 버그 없이 코드 한 번에 수정키 어려움
- 부작용 방지하려면 테스트 코드 작성
- 품질 표준 설정, 준수
- 품질 표준 설정해 코더가 엉성한 코드 배포 못하도록 함
- 갑작스러운 규정·일정 변경 X
- 개발자 관련 규정 지속 변경, 마감일 바꾸면 기술 부채 피하기 어려움
- 현실적인 일정, 방법론, 작업량을 제공해 기술 부채를 관리하도록 함
- 기술 부채가 항상 나쁘기만 할까?
- 크리스 리코미니, 드미트리 리아보이 저서 『필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생』 “나중에라도 팀이 해결 가능하도록 훈련된 부채라면 이는 ‘좋은 부채’라 할 수 있다”
- But 기술 부채는 비즈니스에 부정적 영향 미칠 수 있으므로 해결해야 함
- 이는 버그로 나타나 사용자 경험 저하
- 기술 부채 악화되면, 개발자가 기존 코드베이스 안에서 작업하기 더 힘듦
- 새 기능 개발, 기존 기능 수정에 시간 쪼개어 쓰느라 소프트웨어 개발 라이프사이클 느려지고, 시장 출시 시기 미뤄짐