[스타트업 개발자] 이건 그냥 임시로 해둔거에요
#10 기술 부채(Technical debt)란?
기술부채란 20여년 전에 Ward Cunningham이 IT경험이 풍부하지 않은 이해관계자에게 "왜" 리팩토링이 필요한지 설명하기 위해 만들어진 개념이다. 테스트 부채, 요구사항 부채, 문서화 부채 등등 여기 저기서 소프트웨어 개발 주기 중 나타날 수 있는 모든 종류의 노력들을 부채라고 표현할 수 있다. 이러한 현상으로 인해 기술 부채라는 개념이 의미가 희석되는 경향을 보인다. 단순히 특정 기능을 아직 구현을 못했음에도 불구하고 "기능 부채" 라고 해야 하는가?
신규 기능을 눈깜빡할사이에 개발하고 버그가 발견되면 순식간에 고쳐진다고 해서 "우리 개발팀은 최고야" 라고 생각하기는 어렵다. 기술 부채가 계속 쌓인다면 홍수가 나면 겉보기엔 평온하다가 결국 댐이 터지듯이 한꺼번에 문제가 터질 수 밖에 없다. 스타트업같이 작은 조직에서 소위 만능 은탄환처럼 여겨지는 애자일 개발 방법론을 적용한다고 해서 기술 부채에서 자유로울 수 없다. 교통사고가 발생할 때 빠른 속력일수록 피해가 많은 것과 같이 빨리 개발한다고 안전 장치를 하지 않고 무작정 달린다면 애자일 방법론일지라도 교통사고가 발생할 수 밖에 없다.
기술 부채의 종류를 나타낸 그림[1]
그렇다면 기술 부채를 해결하기 위해서는 어떻게 해야되는가? 안타깝게도 기술 부채는 눈에 띄지 않는다. 보이지 않는 부분까지 해결하기 위해서는 다음과 같은 것을 생각해볼 필요가 있다.
첫번째로, 부채의 인식과 그 원인을 분석하는 것이다.
TODO 리스트와 같이 기술 부채와 관련된 목록을 작성하여 기존 백로그에 포함하여 관리하는 것이다. 일반적으로 백로그에는 앞으로 개발할 신규 기능들만 포함하고 있다. 그러나 리스크를 지닌 기술 부채도 같이 관리를 해야 한다. 이 중 가장 핵심은 팀 전체가 기술 부채가 가져올 수 있는 부작용을 충분히 인지하여야 한다는 것이다.
자동화된 테스트, 지속적 통합을 사용해야 한다.
소프트웨어의 변경 주기는 점점 빨라지는데 일일히 모든 테스트를 진행하기는 여간 만만치 않다. 그러므로 자동화할 수 있는 부분은 자동화시키는 것이 좋다. 요새는 직접 빌드 서버를 구축하고 스크립트를 작성하지 않더라도 이러한 테스트나 통합 빌드 환경을 제공해주는 서비스가 많으므로 적극 이용하는 것을 권장한다.
아키텍쳐에 신경을 쓰자
정적 코드 분석 도구를 통해 커버리지 100%를 이뤘다고 치자. 물론 말도 안되는 소리다.
과연 기술 부채가 없다고 할 수 있을까? 아키텍쳐는 기술 부채에서 큰 비중을 차지하고 있다. 대부분의 논문, 아티클도 아키텍쳐 리뷰에 대한 중요성을 강조[2]하고 있다.
당연히 LIVEO도 기술 부채에 관한 문제를 겪었던 경험이 있다. 두 플랫폼 간 개발 속도차이로 인해 공식적인 코드 리뷰 작업 없이 두 가지 브랜치로 서버를 구축했었다. 같은 기능을 중복해서 개발하는 것은 물론 1+1이니 버그의 숫자도 더 많았다. 통합을 뒤로 미룰수록 부채가 발생했던 것이다. 현재는 피어 코딩 및 리뷰를 통해 해당 문제는 감소하였다.
대부분의 기술 부채는 일정 압박으로 인해 발생한다. 그렇지만 일정에 맞추기 위해 더 빠르게 달릴수록 더 크게 넘어지는 사고가 발생하는 꼴이다. 코드 리뷰 중에 필자가 꽤 자주 했던 말이 있다.
아.. 이거 그냥 임시로 해둔거에요
소프트웨어 개발할 때만큼은 한국인의 무조건 빨리빨리를 버려두자.
[1] Maurício F., Gustavo A. Oliva and Marco A. Gerosa, "Are the Methods in Your Data Access Objects (DAOs) in the Right Place? A Preliminary Study", Managing Technical Debt (MTD) 2014 Sixth International Workshop on, pp. 47-50, 2014.
[2] Damian A. Tamburri, Philippe Kruchten, Patricia Lago and Hans van Vliet, "What is social debt in software engineering?", Cooperative and Human Aspects of Software Engineering (CHASE) 2013 6th International Workshop on, pp. 93-96, 2013.
이 포스트들은 스타트업에 종사하시는 현업 개발자 분들, 스타트업을 하고자 하는 학생분들과 경험을 나누고자 쓰고자 합니다. 저의 얇은 경험으로부터 교훈을 얻는 초기 창업자분들, 한 수 가르쳐주시려는 분들이 읽어주면 보람찰 것 같습니다. 잘못된 점은 말씀해주시면 독자 여러분들과 의논하여 수정하도록 하겠습니다.
LIVEO
Software engineer
마경욱
