기술 부채에 관해 설명하고 이를 비즈니스와 접목시키고 그에 관한 해결 방법에 관한 책
- 언제 갚을지 모르는 상태에서 부주의하게 많은 기술 부채를 가져서는 안된다!!
- 기술 부채의 발생 원인: 요구 사항, 설계/아키텍처, 구현, 테스트, 배포, 문서, 사회적 원인 등 다양한 이유가 존재한다
- 기술 부채의 영향: 버그, 품질, 소프트웨어 처리 속도 저하로 나타난다
- 기술 부채의 비용은 상대적 변경 비용 확인을 통해 수치화가 가능하다
- 언제 부채를 상환해야 하는가? → 꼭 갚아야 할 때 ( 즉, 인지한 시점 )
- 요구 사항 기술 부채
- 원인
- 관련된 모든 이해 관계자와 대화하지 않은 채 요구 사항이 도출되는 경우
- 실제 고객의 필요에 대한 이해 부족으로 잘못된 요구 사항이 도출되는 경우
- 해결 방법
- 요구 사항에 대한 좋은 프로세스를 만드는 것
- 좋은 도구로 요구 사항 및 기능 요청을 관리하는 것
- 기능을 개발하는 이유와 검증 가능한 증거를 제시하면 더욱 좋다
- 설계 및 아키텍처 부채
- 아키텍처 부채는 기술 부채 중 가장 큰 부분을 차지한다
- 원인
- 잘못된 클래스 관심사 분리
- 얽힌 의존성
- 코드 복사를 통한 재 사용
- 시급한 제품 기능 구현 및 버그 수정에만 집중하는 현상 → 전체 구조와 무결성이 미치는 영향이 고려되지 않는 경우
- 불안정한 스펙
- 수치화 방법
- 정적 의존성, 진화 의존성(동시에 같은 커밋에서의 변경)을 찾아낸다
- 설계 구조 행렬(DSM)을 생성하여 확인한다 → tools: DV8, Lattix, Siverthread
- 반드시 모든 커밋에 이슈 ID를 기록하자!!
- 해결 방법
- 좋은 설계 원칙 ( ex: SOLID ) 를 지켜 개발해야 한다
- 모듈성 위반 및 순환 의존성이 존재한다면 해결하려고 노력해라
- 아키텍처 루트(가장 많은 변경이 있는 파일 그룹) 의 설계를 최적화하라
- 좋은 아키텍처는 낮은 전파 비용(PC)과 높은 분리 수준(DL)을 가진다
- 구현 부채
- 원인
- 프로토타입이 바로 제품이 되는 경우
- 오래된 기술을 선택했을 때
- 해결 방법
- 깨끗하고 일관성있는 코드베이스를 위해 규칙을 만들고 그것을 따르도록 강제하는 것
- 코드 포맷팅을 지키도록 강제하는 것
- 똑같은 일을 두 번 하지 말것! ( DRY 원칙을 준수할 것 )
- 해당 업계가 많이 사용하는 언어나 라이브러리를 이용하려고 노력할 것
- 하나의 커밋 ( 코드 리뷰 범위 ) 는 롤백이 가능한 범위여야 하고 10~20분 사이여야 한다
- 테스트 부채
- 원인
- 모든 모듈의 모든 코드라인이 실행되어야 하나, 불충분한 테스트 그 자체가 부채
- 에러가 날 케이스는 테스트하지 않은 경우
- 이미 알고 있는 시스템(인프라) 영역을 테스트
- 가장 가치가 높고 위험성이 큰 영역의 테스트가 빠진 경우
- 해결 방법
- 제품의 성숙도가 낮다면 단위 테스트 위주로 진행하면서 성숙도가 높아지면 통합, 기능 테스트를 추가해 보자
- 75% 이상의 커버리지를 목표로 작업해야 한다
- 구현된 코드에 근거하여 테스트를 수정해서는 안된다
- 테스트를 최대한 자동화하여 시간 소모를 줄여야 한다
- 배포 부채
- 원인
- 잠재적인 문제를 감지하는 지표 및 관찰 가능한 지표 부족
- 변경을 테스트 할 시스템 환경 부재
- 배포와 롤백의 수동 프로세스 의존
- 배포 속도 관리 불가
- 해결 방법
- 프로덕션, 프리-프로덕션, 개발 로 이루어진 3단계 개발 환경이 존재해야 한다
- 각종 지표를 수집하고 모니터링 할 수 있는 시스템 구축
- 배포 및 롤백 프로세스 적립
- 킬 스위치 또는 기능 토글 ( featureFlag ) 가 있으면 좋다
- 문서 부채
- 문서화는 작성 비용보다 공유 비용의 가치가 클 때만 작성해야 한다
- 간결한 정리 형식을 이용하여 작성해야 하고, 결정을 내린 문서에는 근거가 있어야 한다
- 최신화는 출시 주기에 맞추어 작업하라 → 잦은 최신화는 오히려 신뢰도를 낮춘다
- 문서화 수요는 회사가 커질 수록 더 발생한다
- 일관성이 없거나 잘못된 문서보다는 차라리 없는게 더 유용하다
- 문서화 중요도: 설계 → 코드 ( 코드 내에 설명 추가 ) → 테스트 → UI
- 문서의 내용은 문서가 다루는 코드에 가깝게 유지해야 한다
- 머신 러닝(데이터 집약) 시스템 부채
- 반드시 모델 별 성능 및 정확도 비교를 통해 가장 유용한 모델을 선택해야 한다
- 선택한 모델에 대한 명확한 근거가 문서화 되어야 한다
- 데이터 셋
- 테스트, 훈련, 검증의 서브셋으로 분리하여 운영되어야 한다
- 로깅 및 버전화를 하여 문제가 발생했을 경우 재현이 가능해야 한다
- 팀 관리 및 사회적 부채
- 대부분 의사소통 및 관리의 문제에서 시작된다
- 밀접하게 연결된 컴포넌트는 지속적으로 소통하는 팀에 의해 개발되어야 한다
- 기여하는 바 없이 공동의 이득을 취하는 무임 승차자는 제거되어야 한다
- 가장 많이 발견되는 부채 유형
- 타임 워프: 무언가에 대한 결정이 충분한 의사소통 없이 일어나고 추가 조정이 발생한다
- 인지 거리: 요구 사항이 명확하게 전달되지 않아 버그가 있는 프로젝트를 제공하게 된다
- 데브옵스 충돌: 개발자와 운영 담당자 간의 의견 충돌
- 해결 방법
- 아키텍트 또는 프로젝트 매니저는 커뮤니티를 만들고 각 팀이 서로 가까워 질 수 있게 노력해야 한다
- 아키텍트는 팀원을 적극적으로 코칭하고 개발 난제를 이해해야 한다
- 팀과 프로세스에 전문 의사소통 중재자를 도입해 인지 거리를 좁혀야 한다
- 인프라 코드를 포함한 코드베이스 통합을 통해 개발, 운영의 거리를 좁혀야 한다
- 팁
- 엔지니어링: 인류에 기여하는 과학 지식을 현실적인 문제에 적용해 비용 대비 효율적인 해결책을 만드는 것