[오픈갤러리] Django 서버 정리 작업 ② - 서버 구조 개편 및 개발 환경 구축 방법 검토

▎서론

본격적인 서버 정리 작업에 들어가기 전에, React와 Django의 조합으로 기술 스택을 바꾸려면 서버의 구조를 어떻게 개편하고 개발 환경은 또 어떤 식으로 구축할지 등에 대해 미리 한 번 간략하게나마 검토해보기로 하였다. 하지만 예상대로 쉬운 일은 아니었다. 우선 검토 과정에서 고려해야 할 점은 다음과 같이 크게 두 가지였다. 이에 관한 논의 내용은 아래에서 자세히 다루겠다.

 

1. 기존의 서비스는 프론트 엔드와 백 엔드가 분리된 구조가 아니었다.
2. 한 번에 기술 스택을 전부 바꾸는 게 아니라, 점진적으로 새로운 기술 스택을 도입해야 했다.

 

---

▎서버 구조부터 바꿔야

기존의 서비스가 이미 프론트 엔드와 백 엔드가 분리된 구조였고, 프론트 엔드의 기술 스택으로 Vue를 쓰고 있는 상황이었다고 가정해보자. 이러한 상황에서 프론트 엔드의 기술 스택을 React로 바꾸는 것은 그래도 할 만할 것이다(물론 이것도 어렵지만, 뒤에서 설명할 것에 비해서는 상대적으로 그렇다는 것). 그러나 우린 이런 상황이 아니었다. 애초에 프론트 엔드와 백 엔드가 분리된 구조조차 아니었다는 것이다. API 서버를 별도로 두지 않고, 하나의 서버에 Django 웹 어플리케이션을 구축하여 웹 서비스를 제공하고 있었으니 말이다. 그래서 이는 서버를 둘로 분리해야 하는 문제임과 동시에, 하나의 프로젝트를 둘로 분리해야 하는 문제이기도 하였다. 실제로 프론트 엔드와 백 엔드로 분리된 구조에서는 효율적인 유지보수를 위해 프론트 엔드와 백 엔드의 프로젝트를 따로 두는 경우가 많기 때문이다.

 

 

---

▎일괄적 변화가 아닌, 점진적 변화

게다가 중요하게 생각해야 하는 게 하나 또 있었다. 기존 서비스의 규모가 상당히 크기 때문에 이를 한 번에 새로운 기술 스택으로 바꿔버리는 것은 사실상 불가능하다는 것이었다. 따라서 점진적으로 새로운 기술 스택을 도입하는 방법을 생각해봐야 했다. 이 말은 곧 기존의 기술 스택을 유지하면서 새로운 기술 스택을 도입해야 한다는 뜻이었다. 그런데 조금만 생각해봐도 쉽지 않은 일이라는 걸 알 수 있었다. 앞서 말했듯, 이미 서버가 둘로 분리라도 되어 있었으면 그나마 괜찮았을 텐데, 서버의 구조를 바꾸면서 기존의 기술 스택을 유지하라니? 참으로 난감했던 것이다.

 

 

위와 같은 두 가지 고려사항을 염두에 두고, 서버 구조를 어떻게 개편하고 개발 환경은 또 어떻게 구축할지에 대해 신중히 고민하였다. 그 고민의 결과를 아래에 기술한다. 다만 이는 초기에 고민한 결과, 즉 초안일 뿐이었기 때문에 최종적으로는 또 달라질 수도 있다.

 

---

▎서버 구조의 개편 및 개발 환경의 구축

우선 기존의 서비스가 AWS의 Elastic Beanstalk를 이용하고 있기 때문에 이를 기준으로 생각하였다. 기존의 서비스는 하나의 로드 밸런서와 두 개의 인스턴스로 구성된 환경을 사용하는데, 우리는 여기에 두 개의 환경을 추가로 구축할 예정이다. 하나는 ① API 서버를 위한 환경이고, 다른 하나는 ② 정적 파일을 제공하는 프론트 엔드 서버를 위한 환경이다. 아래 그림에서 하늘색으로 칠해진 영역 하나가 환경 하나를 의미한다.

 

 

먼저, API 서버 환경은 api.opengallery.co.kr(가명) 하위 도메인을 사용하고 현재 개발에 사용하고 있는 리포지토리를 그대로 공유하기로 한다. 각 앱의 models.py 파일과 같이 공유해서 참조해야 하는 파일들이 많기 때문이다. 대신, API 서버만을 위한 코드는 최상위 디렉토리에 api/ 디렉토리를 생성하고 그 안에서만 작성하도록 한다. 그리고 동일한 리포지토리이기 때문에 배포 시에도 두 개의 환경(기존 환경, API 서버 환경)에 모두 배포해야 한다. 또한 RDS는 추가로 구축하지 않기 때문에 마이그레이션은 한 번만 일어나도록 강제하는 것이 필요하다. 따라서 API 서버 환경에 대한 배포 시에는 마이그레이션을 수행하지 않도록 세팅을 해준다. 마지막으로, API 서버를 위한 Django 설정 파일을 별도로 작성하고 환경 변수를 제어하여 API 서버 환경에서는 그 파일을 읽어 Django를 실행할 수 있도록 세팅해준다.

 

다음으로, 프론트 엔드 서버 환경은 front.opengallery.co.kr(가명) 하위 도메인을 사용하고 프론트 엔드 개발을 위한 별도의 리포지토리를 생성하기로 한다. 대신 이 환경은 기존 환경이나 새로 구축할 API 서버 환경과 달리 Node.js 기반의 환경이어야 한다. 그래야 React 코드를 번들링 할 수 있기 때문이다. 물론 그 번들링 과정은 CI를 통해 자동화해야 할 것이다. 마지막으로, 기존에 구현되어 있던 페이지들에 대한 링크를 구현할 때는 React가 제공하는 동적 내비게이션이 아닌 HTML의 <a> 태그가 제공하는 기본적인 내비게이션을 이용해야 할 것이다.

 

마지막으로, 기존 환경은 크게 건드릴 부분이 없다. 단지 앞으로 React와 Django를 이용하여 새로 개발할 페이지들에 대한 링크를 구현할 때, 프론트 엔드 서버 환경의 도메인으로 리다이렉트를 시켜주도록 하거나 애초에 링크의 URL에서 도메인을 프론트 엔드 서버 환경의 도메인으로 지정해주면 된다. 그리고 최종적으로 나중에 모든 기술 스택의 전환이 마무리되고 나면, 기존 환경을 파괴시키고 새로 구축한 두 개의 환경만 남긴 뒤 프론트 엔드 서버 환경에 연결된 도메인을 opengallery.co.kr로 바꿔주면 될 것이다.

 

추가적으로, API 서버와 프론트 엔드 서버가 분리되는 것이기 때문에 API 서버에서 CORS를 허용해주기 위한 별도의 세팅도 해줘야 할 것이다. 기본적인 CORS 정책은 다른 오리진의 자원에 접근하는 것을 허용하지 않기 때문이다. 또한 인증 방식의 경우에는 기존의 세션 기반 인증 방식을 일단은 유지해도 괜찮을 것으로 보인다. 세션 ID에 해당하는 세션 쿠키를 일반적인 인증 토큰과 같은 용도로 사용하면 되기 때문이다. 이를 통해 자동 로그인, 로그인 상태 유지, 인증된 API 요청 등의 구현이 가능할 것이다.

 

이후부터의 포스팅은 구체적으로 서버 정리 작업 기간 동안 무슨 작업을 했는지 기술한다. 포스팅 순서는 작업 순서와 정확히 일치하지는 않으며, 최대한 비슷한 유형의 작업들을 한 포스팅에 모아 기술할 것이다.