안녕하세요. 한국기술교육대학교 BCSD Lab에서 FrontEnd 개발을 담당하고 있는 김대관입니다.
이번에 새로운 프로젝트를 맡게되어 프로젝트에 대한 개발 기록을 블로깅을 통해 남겨보려고 합니다.
많이 부족하지만 저의 성장을 위해 자세히 써보는 걸 노력하겠습니다(?)
먼저 프로젝트에 대해 설명해보겠습니다.
이번 프로젝트는 현재 서비스 중인 “한기대 사람들 - 코인”이라는 프로젝트에서 사용 중인 전체적인 라이브러리 변경과 로그인 방식 변경, API 관리에 대한 구조를 전체적으로 변경할 예정입니다.
왜 리팩토링이 아닌 리코드를?
위 내용을 보고 “있는 코드를 더 개선하는 작업인데 어째서 리팩토링을 하지 않고리코드라고 하지?” 라는 의문이 드셨을 것 같습니다.
저도 함께하는 팀원과 이야기하면서 “왜 리코드임?” 이라는 질문을 했었습니다.
저는 팀원이 준 글을 읽고 단번에 우리가 왜 리팩토링이 아닌 리코드로 방향을 잡고 진행했는지 이해할 수 있었습니다.
처음에 저희가 프로젝트를 리코드를 하겠다고 했을 때, 코인 PL님께 전달했을 때 리코드보다는 리팩토링을 하는게 어떠냐고 하셨습니다.
회사에서는 실제로 다시 만드는 “리코드” 보다는 현재 프로젝트에서의 코드를 개선하는 작업인 “리팩토링”을 더 많이 한다.
제가 생각해도 서비스를 운영하는 회사 운영에 있어서 코드의 개선보다는 서비스가 얼마나 잘 돌아가고 지속 운영이 가능한 것인가가 더 중요할 것입니다.
결국 서비스는 수입 생기는 요소이기 때문이죠!
리코드를 진행하고 배포했을 때 서비스에 문제가 생기면?
지금도 서비스에 돌아가는 것에 문제가 없는데? 굳이?
라는 문제에 부딪혀 레거시를 한방에 없애고 새로운 기술을 프로젝트에 도입하고 설계하는 엔지니어들의 꿈은 현실이란 벽에 부딪힐 것입니다.
하지만 저희는 해당 내용을 이미 알고 있었기에 설득하기로 하였습니다.
리팩토링이 아닌 리코드를 해야하는 이유를 말입니다.
2년간 방치된 라이브러리 버전
프론트엔드의 생태계의 변화는 정말 빠릅니다.
빠른 생태계의 변화가 프론트엔드 환경이 성장하고 있다는 좋은 신호이겠지만, 장점은 곧 단점이 됩니다.
프로젝트가 기술의 변화에 대응하지 못하게 된다면, 다른 회사보다 뒤쳐지게 될 것이고 코드의 버전 문제로 새로운 기능을 추가하지 못하거나 개발속도가 늦어지는 등 회사입장에서 손해가 일어날 수 있을 것입니다.
그렇기에 꾸준히 업데이트 하지 않은 부분에 대한 업보를 청산하고 이를 방지하기 위한 대책을 마련하고, 앞으로의 프로젝트 라이브러리 버전을 안정적으로 유지하기를 약속드리고 리코드가 미래를 보았을 때,더 효율적일 것이라고 주장하였습니다.
결론적으로 기술의 부채에 대한 문제
기술의 부채란 간단하게 말하자면 빚입니다. 과거 작성된 코드에 대한 빚을 갚는 것입니다.
예를 들어, 과거에 작성된 코드를 우리가 이렇게
물론 기술의 부채를 해결하는 방법은 리팩토링, 테스트코드 등 다양한 방법이 있지만, 앞에서도 말씀드렸든 2년간의 공백은 쉬운 부분이 아니었습니다.
2년간의 코드를 리팩토링 하는 건 좋은 경험이 아닐까 생각하지만, 실상 다 뜯어보면 결국에는 새로운 코드로 대체하기보다는 구조를 뜯어야할 정도입니다.
비동기 라이브러리를 2가지 사용하고 있으며 훅 또한 제대로 분류되있지 않았고요.
Router 버전, React 버전… 여러가지 등등 앞으로의 유지보수가 어려워질 가능성이 농후했습니다.
저희들의 합당한 이유로 리팩토링이 아닌 리코드로 진행하기로 하였습니다.
그렇게 저희는 리코드를 시작하게되었습니다!
현재도 진행하고 있지만 기록과 함께 저의 개발기록을 남겨보겠습니다.
여러분들도 한번 기술의 부채에 대한 고민도 해보시면 좋을 것 같습니다 :)
참고:
개발자라면 마주치는 기술 부채, 꼭 다 갚아야 하나요? | 요즘IT
일본 1위 배달 앱, 바닥부터 다시 짠다 - Recode 프로젝트
2022-LINE-engineering-site
