오픈갤러리라는 회사에서 약 6개월 동안(2021.02 ~ 2021.07) 대대적인 Django 서버 정리 작업을 리드하며 진행했던 주요 작업들을 일지 형태로 기록한 포스팅입니다. 장기간 공을 들여 진행했던 작업이니만큼 아카이빙을 해둬야겠다고 생각하였습니다.
1. 이제는 바꿔야 할 때
나는 현재 오픈갤러리라는 IT 회사에서 Django 풀 스택 개발자로 일하고 있다. 2019년에 입사하여 줄곧 Django를 공부해왔고, 2020년 중반기쯤부터는 개인적으로 React를 비롯한 각종 프론트 엔드 공부를 집중적으로 시작하였다. 그런데 프론트 엔드를 공부하며 그 당시에 뼈저리게 느꼈던 부분 중 하나는, 회사가 기술 스택으로 채택하고 있던 Django 풀 스택이 최근 트렌드에 잘 어울리지 않는 듯하다는 것이었다. 프론트 엔드와 백 엔드가 구분되지 않은 구조로 Django의 템플릿 엔진을 그대로 사용하는 순수한 형태의 Django 웹 어플리케이션은 오늘날에 사실상 거의 없었기 때문이다. 이제는 프론트 엔드와 백 엔드가 분리된 구조로 기술 스택을 전환할 필요가 있었다.
물론 여태까지 아무도 기술 스택을 바꿔보자는 생각을 안 했던 것은 아니다. 나와 같은 생각으로 회사의 기술 스택에 대해 문제의식을 가진 개발자분들은 분명 있었다. 다만 그러한 문제의식을 실제로 실천에 옮기는 것은 큰 책임감이 뒤따랐고, 무엇보다 빠른 개발이 중요시되는 스타트업의 특성상 그때는 이러한 프로젝트를 시도하는 것조차 어려운 시기였기 때문에 그 누구도 이러한 큰 작업을 과감하게 진행하기 어려웠을 뿐이다.
이러한 현상을 고급진 표현으로 기술 부채(Technical debt)라고 한다. 장기적인 관점에서 문제를 해결할 수 있는 확장성 있는 솔루션이 아닌 당장의 문제를 해결하기 위한 가벼운 솔루션을 채택함으로써 미래에 해결해야 하는 문제들을 남기는 것을 말한다. 기술 부채는 용어 그대로 금전적인 채무와 비유될 수 있다.
그러나 이제는 그때와 상황이 다르다고 생각했다. 회사가 충분히 안정기에 접어들었고, 더 늦기 전에 이제는 누군가 총대를 메고 크게 한 번 방향을 틀어야 할 때라고 판단했다. 기술 부채를 상환하는 그 누군가가 만약 나라면, 장기적인 측면에서 회사에 상당한 이득을 가져다줄 뿐 아니라 나 스스로의 성장에 있어서도 큰 밑거름이 될 것 같았다.
2. 바꾸면 무엇이 좋은데?
앞서 이러한 기술 스택의 전환이 회사에 상당한 이득을 가져다줄 것이라 하였는데, 구체적으로 어떤 이득을 가져다주는 것일까? 이 질문에 대한 답은 기존 기술 스택의 문제점들에서 찾을 수 있다. 기존 기술 스택은 다음과 같은 문제점들을 갖고 있었다.
먼저, 기술 스택이 오래되어 회사에 맞는 유능한 개발자를 찾는 것이 쉽지 않았다. 채용을 담당하며 여러 지원자분들의 이력서를 보았지만, DRF를 사용하는 사람은 종종 보았어도 순수한 형태의 Django 웹 어플리케이션을 개발해본 사람은 거의 없었다. 오죽하면 우리가 DRF를 사용하는 것으로 오해하고 지원하시는 분들이 많다는 느낌도 받았었다. 회사 입장에서는 그 회사가 사용하고 있는 기술 스택에 유능한 사람을 뽑는 것이 합리적이다. 따라서 오래된 기술 스택을 사용하면 유능한 인재를 놓치기 쉬워진다.
다음으로, 서비스의 사용자의 경험(UX)이 좋지 못하였다. 기존의 서비스는 매 페이지마다 새로운 요청을 서버에게 보내는 오래된 방식을 사용하고 있었다. 이러한 방식은 페이지 전환 성능을 떨어뜨려 사용자의 경험을 크게 해치곤 하였다. 따라서 React와 같은 기술 스택으로 웹 서비스를 구현하여 더 높은 퀄리티의 사용자 경험을 제공할 필요가 있었다.
마지막으로, 추후 앱 개발의 가능성을 염두에 둔다면 API가 다양하게 잘 구현되어 있을 필요가 있었다. 앱 개발을 위해서는 데이터를 제공하는 API의 존재가 사실상 필수인데, 기존의 서비스는 동적인 렌더링을 위한 극히 일부의 API만 구현되어 있었다. 만약 React로 기술 스택을 전환한다면 각각의 데이터 요청을 위한 API는 필연적으로 구현하게 될 것이다. 이를 통해 추후 앱 개발의 가능성까지 내다볼 수 있게 된다.
3. 잠깐, 왜 React인가?
프론트 엔드와 백 엔드로 분리하자는 것까지는 알겠는데, 프론트 엔드의 기술 스택으로 굳이 React를 선택한 이유는 무엇일까? React를 선택한 가장 큰 이유는 명확하다. 그것은 바로 활발한 생태계이다. 현실적으로, 아직까지 React보다 생태계가 활발한 프론트 엔드 기술 스택은 없다. 우리로서는 안정적인 기술 스택의 전환을 위해 빠르게 배우고 문제를 해결할 수 있도록 돕는 활발한 생태계야말로 가장 중요한 조건이었다.
또한 내가 짧지 않은 기간 동안 React라는 기술 스택에 익숙해져 있었던 것도 현실적인 이유로 작용하였다. 이와 같은 대규모의 기술 스택 전환을 이뤄내기 위해서는 새롭게 도입할 기술 스택에 숙련된 인력이 최소한 한 명 이상 필요하다고 생각했다. 그래서 React를 선택하면 동료 개발자분들이 나의 도움을 받아 더 빠르게 학습하고 기술 전환을 이뤄낼 수 있을 것으로 판단하였다.
게다가 React는 Angular보다 훨씬 러닝 커브가 낮고 공식 문서가 읽기 쉽게 잘 정돈되어 있다는 특징이 있다. 효율적인 기술 스택의 전환을 위해서는 나의 도움을 받는 것 외에도 동료 개발자분들이 스스로 잘 학습할 수 있는 환경을 조성하는 것이 매우 중요하였다. 그러한 점에서 Angular보다 다가가기 쉽고 공식 문서가 잘 번역되어 있는 React는 상당히 매력적일 수밖에 없었다.
마지막으로, 당장은 회사의 서비스가 웹 기반이지만 추후 앱 개발을 진행하게 될 수도 있음을 염두에 두었다. 만약 React를 선택한다면 그 지식을 기반으로 추후 React-Native를 아주 빠르게 익힐 수 있다. React-Native는 크로스 플랫폼 앱을 개발하는 데 굉장히 많이 사용되는 React 기반의 앱 개발 기술 스택이다. 기술 스택을 선택함에 있어 최대한 먼 미래까지 고려하려고 노력했던 것 같다.
4. 그러나 대청소가 먼저
React와 Django의 조합으로 기술 스택을 바꾼다는 것은 곧 다양한 API가 제대로 구현되어야 한다는 것을 의미한다. 그러나 이러한 대작업을 진행하려면 기본적으로 먼저 기존 서버의 코드가 잘 정리되어 있다는 전제가 필요하였다. 그러나 지난 기간 동안 빠른 개발에 우선순위가 밀린 탓에, 정리가 잘 되어 있지 못한 코드가 상당히 많았다. 즉, 기술 부채가 눈에 띄게 쌓여 있었던 것이다.
이는 많은 스타트업의 개발자분들이 공감할 만한 이야기일 것이다. 제대로 정리를 하려면 개발 작업을 잠시 멈추고 정리에만 온전히 집중을 해야 하는데, 스타트업의 특성상 빠른 개발이 중요하여 진득한 정리 기간을 갖기 쉽지 않기 때문이다.
문제는 여기서 그치지 않는다. 설령 그러한 정리 작업을 아주 잘 진행했다고 해도 개발자가 아닌 분들의 입장에서는 달라진 게 없기에 본전일 뿐인 것이다. 오히려 정리 작업을 진행하다가 괜히 사소한 거 하나를 잘못 건드려서 잘 되던 것이 안 되면 따가운 시선을 받게 된다. 그래서 많은 스타트업의 개발자분들은 이러한 정리 작업을 쉽사리 진행하지 못하고 있는 것이 현실이다.
이런 식으로 기술 부채가 쌓이고 또 쌓이면, 그 부담은 고스란히 미래의 개발자에게 넘겨진다. 결국 그 부채를 감당할 수 없는 시기가 언젠가는 도래하기 마련이기 때문이다. 오픈갤러리의 경우, 지금이 바로 그때였다.
내가 결심한 기술 스택의 전환을 위해서는 이러한 정리 작업이 먼저 본격적으로 진행되는 것이 중요하였다. 그래서 과감하게 PM분과 대표님께 상황을 설명하며 IT팀의 이러한 계획에 대해 설득을 시도하였고(IT팀 내부에서는 이미 이러한 계획에 대해 전부 동의한 상태였다), 감사하게도 PM분과 대표님께서 우리의 의도를 잘 이해하시고 빠르게 받아들여주셨다. (번외로, 다른 회사에서는 이러한 작업을 하려면 몇 개월을 설득하기도 한다는데, 사소한 부분이지만 굉장히 감동을 먹고 감사함을 느꼈던 포인트였다.) 그래서 본격적으로 2개월(잠정적으로 잡은 것이고, 더 길어질 수 있음을 미리 밝힘) 동안은 모든 개발 작업을 멈추고 서버 정리 작업에 돌입할 수 있게 되었다.
참고로 여기서 말하는 서버 정리 작업이란, 서버의 코드를 전부 살펴서 불필요한 부분은 지우고 필요한 기능들은 개선하는 일련의 모든 작업들을 통틀어 말하는 것이다. 모델링, 코드 컨벤션 및 작성 규칙 통일, 리팩토링 등등 모든 것 말이다. 그동안 눈에 보였던 불편한 부분들을 전부 정리하는 것이다.
그런데 잘 생각해 보면, 설령 기술 스택의 전환을 시도하지 못하게 되더라도 이러한 서버 정리 작업은 어차피 언젠가 해야 하는 작업이었다. 그래서 이러한 작업을 진행하고자 하는 계획을 설득함에 있어서도 더욱 떳떳했던 것 같다. 나와 동료 개발자분들의 성장에도 큰 도움이 될 뿐 아니라, 회사의 IT 시스템이 갖고 있던 큰 빚을 제대로 한 번 상환해줌으로써 장기적인 측면에서 회사의 발전에도 아주 큰 기여를 하게 되는 것이었기 때문이다. 그래서 조금 (많이) 힘들겠지만 감당해보기로 하였다.
