위키피디아의 정의에 따르면 기술 부채(technical debt, design debt, code debt)는 현 시점에서 더 오래 소요될 수 있는 더 나은 접근방식을 사용하는 대신 쉬운(제한된) 솔루션을 채택함으로써 발생되는 추가적인 재작업의 비용을 반영하는 소프트웨어 개발의 한 관점이다.
기술 부채를 완전히 없이 가면 좋겠지만 현실적으로 약간의 타협을 하면서 갈 수 밖에 없다. 최악의 경우에는 계속 기술 부채를 안고 가다가 어느 순간 안고치면 더이상 나아갈 수 없는 상황이 생기기도 한다. 이번에 Yocto 업그레이드를 하다가 이 경우를 만났고 덕분에 엄청나게 일정이 지연되었다. 프로젝트 일정상 어쩔 수 없이 기술 부채를 안고 가는 경우에는 잘 기록해 놓았다가 최대한 빨리 그것을 해결해야 한다.
프로젝트를 진행하가다 보면 개발팀에서는 일정을 맞추려고 하고 리뷰하고 최종적으로 넣는 입장에서는 아키텍처적인 부분이나 기술적으로 문제가 되는 부분은 해결하고 오라고 하는 경우가 많다. 이런 경우 상당수 매니지먼트에 보고를 하고 소프트웨어를 많이 경험해보지 못한 특히 일정 관리 중심의 매니저들은 프로젝트 일정을 맞추도록 기술 부채를 안고 가도록 허가하는 경우가 상당수이다. 안타깝게도 필자가 겪은 거의 모든 매니지먼트는 그랬다. 지금도 그러고 있다.
최근에 Yocto 업그레이드를 dunfell에서 kirkstone으로 올리는 작업을 팀 동료들이 진행했다. 이전에 zeus에서 dunfell로 버전업을 할 때 boost를 이전 버전을 사용하도록 업그레이드를 하지 않았다. 이유는 vsomeip v2 의존성 때문이였다. 커다란 기술 부채를 하나 남겨놓고 그 뒤로 관리는 하지 않았다.
중간에 운이 좋게 특정 개발팀에서 boost 버전 높은 것이 필요하다고 해서 vsomeip와 함께 버전을 올리는 작업을 하다가 vsomeip 개발팀에서 다른 프로젝트 일정이 바쁘다는 이유로 중단이 되었다. 두번째 기회를 놓친 것이다.
그리고 결국 kirkstone으로 업그레이드 하는데 무조건 boost 버전을 높여야 하는 경우가 발생했고 연이어 vsomeip 버전도 2에서 3으로 올리는 작업을 동시에 할 수 밖에 없었다. 이것 때문에 거의 2달이 소모되었다. 이유는 vsomeip2에서 3으로 갈때 하위 호환성을 지원하지 않고 이것을 사용하는 다른 많은 컴포넌트도 변경해야했기 때문이다.
만약에 처음에나 두번째 기회였을 때 바꿨더라면 그만큼 사용하는 컴포넌트도 적었을 것이고 그래서 조금 업그레이드가 빨라졌지 않았을까 하는 후회는 든다.
이제는 프로젝트를 관리하는 입장에서 기술 부채를 잘 정리하고 최대한 빨리 하나씩 해결하는데 노력을 해야겠다는 생각이 든다. 더구나 이제는 플랫폼을 잘 만들려고 하는 입장이다 보니 더더욱 그렇다. 안타깝게도 부팅가능한 minimal한 이미지를 만드는데 상당히 많은 컴포넌트가 의존성으로 딸려오는 상황이다. 개발팀이 알고 했는지 모르겠지만 결국에는 이것도 기술 부채중 하나라고 생각한다.
이렇게 알려진 또는 알려지지 않은 기술 부채들을 잘 정리해서 리스트업해 놓고 개발팀에게 최대한 빨리 해결하도록 푸시를 해야할 것 같다. 다시 정리하자면 기술 부채를 한없이 가지고 가면 더 큰 화가 되서 돌아온다. 당장은 안고 가더라도 잘 정리해놓고 최대한 빨리 해결하는게 해야한다.
'Development' 카테고리의 다른 글
| 채용 (Hiring)에 관한 이야기 (현 회사 기준) (0) | 2024.04.07 |
|---|---|
| 대학생들이 독일에서 일하는 개발자에게 많이 하는 질문에 대한 답변 (0) | 2024.01.13 |
| M1 IPAD Pro에서 터미널(shell + git) 개발 환경 구축하기 (0) | 2023.10.10 |
| The Linux Graphics Stack (0) | 2023.09.24 |
| 독일 소프트웨어 개발 회사에서의 진급 체계 및 승진 조건 (0) | 2023.09.16 |