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

 

p.28
가장 심각한 기술 부채 문제는 소프트웨어를 회사의 핵심 자산으로 간주하지 않는 회사와 조직에서 발생하는 경향이 있다.

소프트웨어를 핵심 자산으로 보지 않으면 품질에 투자하지 않는다. 그러면 기술 부채는 빠른 속도로 쌓인다.
소프트웨어가 시장 경쟁력에 닿아 있는 회사라면 반드시 핵심 자산으로 봐야 한다. 소프트웨어 품질은 기업의 생존과 직결된다.

 

p.32
기술 부채는 소프트웨어 프로세스의 일부로, 그 프로세스 안에서 발생한다.
따라서 열악한 프로세스는 더 많은 부채로 이어질 수 있다.
마찬가지로 기술 부채도 제품의 일부다.
버그, 기능, 취약점 등과 마찬가지로 감지돼야 하고 우선순위를 정해서 제거해야 한다.
기술 부채는 많은 시스템 장애 또는 문제의 원인이 되기 때문에 혼자서 대응하고 해결할 문제가 아니다. 이런 기술 부채는 잘못된 코딩, 잘못된 설계, 요구 사항, 테스트 또는 문서 부족 등 우리의 결정이 미래에 어떤 영향을 미칠지 생각하지 않을 때 발생한다.

 

p.37
요구 사항 부채는 제품에 가치를 더하지 않는 요구 사항을 우선시해서 구현할 때 발생한다.
제품에 가치를 더하지 않는 요구 사항이 결국은 제품 기능으로 출시되지만, 고객이나 사용자로부터 외면받는(따라서 고객과 사용자는 구매 의사가 없는) 상황이다. 특정 소프트웨어의 기능 중 20%가 실제 사용량의 80%를 차지한다면 나머지 80%의 기능은 꽤 불필요하다는 뜻이다.
요구 사항을 우선순위에 올린다는 것은 결국 다른 요구 사항을 무시하거나 구현하지 않겠다는 결정과도 같다. 요구 사항 부채 중 일부는 우선순위에 밀려 구현되지 않았던 요구 사항(예를 들면 규제 관련 요구 사항 등)의 중요성을 나중에 가서 깨닫기 때문에 발생하기도 한다.

나머지 80% 기능은 종종 고객이 아니라 조직을 위해 존재한다.
사용률이 1%도 안되는 기능들은 실제 고객을 위해서가 아니라 조직의 성과를 위해서 만들어질 수 있다.
새로운 요구사항이 왔을 때 이런 식으로 스스로에게 질문해 보는 건 어떨까?
"이 기능이 없으면 고객이 우리를 떠날까?"

 

p.52
기술 부채는 보통 편의를 중시한 잘못된 선택에서 발생한다.
성숙한 소프트웨어 개발은 편의성 대신 의식적으로 코딩 표준과 설계 규칙 또는 가이드라인을 만들어 프로젝트의 발전을 도모하고 개념적 무결성을 제공해야 한다.
이를 위해 리드 개발자, 팀 리더, 소프트웨어 아키텍트는 효과적인 설계 규칙을 만들 수 있는 능력을 핵심 스킬로써 가지고 있어야 한다.

 

p.130
테스트 부족으로 나타나는 첫 번째 증상은 새로운 제품 기능이 기존 제품 기능을 주기적으로 망가뜨리는 버그의 증가와 수정 사항이나 새로운 제품 기능을 제공하는 데 드는 시간이 길어지는 민첩성의 상실이다.
적절한 테스트 없이는 일부 기능이 제대로 작동하지 않는 상태에서 망가진 코드가 버그와 함께 출시되는 것을 피할 수 없을 것이다.
이런 상황에서 버그를 찾고 수정하는 것은 더 많은 시간이 걸릴 것이다. 이 두 가지는 소프트웨어 출시 비용을 어김없이 증가시킨다.
개발자는 보통 이런 증상을 처음부터 알아채지는 못한다. 프로덕트 매니저가 사용자로부터 버그와 망가진 제품 기능에 대한 피드백을 받고 나서야 이 피드백은 소프트웨어 관리자와 개발자에게 전달된다. 이 긴 피드백 루프는 버그 수정에 드는 시간과 고객의 불만을 모두 증가시킨다. 충분한 테스트가 없었던 상황이기 때문에 개발자는 버그의 정확한 원인을 찾는 데 많은 시간을 소비하게 되고 결국 개발 속도와 민첩성이 저하된다.
테스트는 코드를 자주 변경해도 제품 기능을 망가뜨리지 않는다는 확신을 준다.

소프트웨어 품질을 높이기 위해서 테스트 코드는 필수다.
테스트 코드가 존재한다고 꼭 품질이 좋은 소프트웨어가 되는 건 아니다.
설계 품질이 좋아야 테스트 코드의 품질 또한 좋아진다.
도메인 로직이 분산되어 있고, 역할과 책임이 불분명한 상태라면 테스트 코드 또한 저품질 상태가 된다.
즉, 테스트하기 어려운 코드는 대부분 설계 품질이 나쁘다는 걸 방증한다.

 

p.157
테스트가 모든 잠재적 오류를 잡아낼 수는 없다.
테스트로 할 수 있는 일은 시스템 작동을 시뮬레이션하고 소프트웨어에서 생성된 결과가 정확한지 확인한 다음, 에지 케이스와 데이터베이스를 사용할 수 없는 상황 등의 예외 조건을 확인하는 것이다.
더구나 대규모 시스템은 많은 외부 서비스에 의존하기 때문에 잠재적인 문제의 모든 조합을 샅샅이 찾아내 테스트하는 것은 불가능하다.

 

p.176
궁극적으로 우리는 독자가 문서를 계속 사용하기를 원한다. 그 이유 중 하나는 독자가 문서를 사용해야 원래 문서를 작성한 사람을 찾아가 이것저것 물어보면서 귀찮게 하지 않기 때문이다.
잘 작성된 문서는 실질적인 힘이 된다. 하지만 모호하게 쓰인 문서는 그냥 나쁜 것보다 더 나쁘다.

 

p.180
문서화가 필요하다는 첫 번재 증상은 경험 많은 개발자가 시스템에 대한 같은 질문에 계속해서 답하는 상황이다.
새로운 팀원이 사무실에 입부러 오는 이유 역시 그런 정보를 위키나 이슈 트래커 등 어디에서 찾아야 하는지 모르기 때문이다. 경험에 비추어 볼 때 만약 여러명에게 똑같은 정보를 몇 번이고 설명한다면 그게 바로 문서화를 시작할 때다.

 

p.229
사일로 효과 (silo effect)
프로젝트가 사일로화된 조직으로 나뉘고 그런 사일로끼리 거의 교류가 없는 상태를 생각해보자.
사일로화된 조직이 서로 의존하는 산출물에 관해 작업하는 경우, 충분하지 않은 대인 상호 작용은 문제를 일으킬 수 있다.
어떤 팀은 다른 팀이 직면한 어려움(일부 성능 문제 등)을 인지하지 않은 채 자체적으로 시스템을 최적화해버려서 새로운 문제가 생길 수도 있다.

 

p.258
많은 관리자와 경영진이 소프트웨어를 유틸리티 혹은 비용 부문으로 간주하기 때문에 기술 부채를 줄이기 위해서 리팩터링에 투자하자고 주장하는 것은 어려울 수 있다.
리팩터링은 즉각적인 가치를 보여주지 않기 때문이다. 기술 부채를 줄이는 것은 장기적인 투자를 하는 것이다.
앞에서 언급했듯이 이 투자의 비용은 즉각적이고 구체적인 반면, 이점은 장기적이고 불확실하다.
장기적 이점에 집중하는 것이 너무나도 어려운 이유는 인간은 하나의 종으로서 장기적 욕구보다 단기적 필요와 욕구에 훨씬 더 많은 관심을 기울이는 경향을 지니기 때문이다.

 

p.287
마지막 중요한 교훈은 '측정할 수 없으면 관리할 수 없다.'이다. 피터 드러커 같은 경영 전문가는 이것을 수십 년간 강조해왔고 여러분도 들어본 적이 있을 것이다.
축적된 기술 부채 문제에 대한 가시성 부족이 프로젝트를 망치는 경우가 많기 때문에 기술 부채는 측정으로 시작돼야 한다.
측정을 통해 문제를 식별할 수 있고, 정기적인 측정을 통해 부채를 관리하고 처음부터 부채를 피하는 것 또는 최소한 그 최악의 결과를 피하는 것이 개발 프로세스의 자연스럽고 정상적인 일부가 된다.

 

키워드

 

적용할 점

• 기술 부채 시각화 하기
• 기술 부채 비용 측정 하기, 비용 측정 방식은 google sheet로 관리
• 기술 부채는 장기적인 투자이다. 천천히 꾸준하게 진행하기
• 설계 프로세스 및 가이드라인 구축
• 개발 프로세스 체계화 하기