개발 환경, 배포 환경 및 CI CD에 대한 개선 과정

🚧 Under Construction 👷

Introduction

Octodocs 팀은 사용자 경험 향상은 물론, 일관된 코드 품질 유지와 개발자 친화적인 쾌적한 개발 환경 조성을 위해 많은 노력을 기울였습니다. 멀티 레포에서 모노레포로의 전환, GitHub Actions를 활용한 CI/CD 구축, Docker와 Docker Compose의 도입까지—우리는 어떤 변화를 거쳤을까요?

말을 거창하게 적었지만, 사실 그렇게까지 거창한 내용은 없다. 단순히 우리가 어떤 환경을 통해 프로젝트를 개발해왔는지 그 발전과정을 적고, 어떤 지점에서 문제를 느껴 새로운 도구를 도입했고, 현재 인프라 세팅이 어떻게 되어있는지, 어떤 방향으로 발전할 수 있는지에 대한 내용을 확인할 수 있다.

멀티레포 방식과 기본적인 CI/CD

맨 처음 프로젝트를 시작할 떄에는 별 생각 없이 분리된 멀티레포 방식을 사용했었음 (react + vite + ts / nest)
PR을 통한 코드 병합과정에서 기본적인 검사과정 (빌드, 린트, 단위테스트) 이 필요하다고 느낌
그래서 기본적인 CI를 Github Actions를 통해 구성함
추가적으로, PR을 올릴 때 Assignee와 Reviewer 지정을 까먹는 경우가 많아서 이것을 자동화하는 액션 스크립트 또한 도입

슬슬 협업이 힘들어지는데...

멀티레포로 작업을 하다보니, 개발되는 API에 대한 응답 형식 공유가 너무 어려웠음
특히, FE/BE 둘 다 타입스크립트를 사용하지만, 그 장점을 살리고 있지 못함. 멀티레포 방식이라서 서로의 타입을 참조할 수 없음.
응답 형식 공유를 위한 문서화에 추가 공수가 들어가는게 너무 귀찮고 아쉬움 (우리는 한정된 6주라는 시간 내에 최적의 결과물을 뽑아내야 하는데)

모노레포 방식으로 변경 및 스웨거 도입

그래서 모노레포 방식을 도입함. turbo를 사용했고, 이와 관련해서 위키 문서가 따로 작성되어 있음 https://github.com/boostcampwm-2024/web15-OctoDocs/wiki/monorepo%EB%A1%9C-%EB%B3%80%EA%B2%BD
또한, 모노레포 도입으로 기존 존재하던 CI/CD의 변경이 필요했음. 전체적인 프로젝트 디렉터리 구조가 완전히 바뀌었기 때문임.
모노레포를 도입하긴 했지만, 모노레포의 특장점은 잘 살리지 못했음. 공유되는 타입을 분리해서 따로 두고, 이를 각각 참조하는 방식으로 변경했어야 했는데, 기능 구현 쳐내기 너무 바빴다...
다음 프로젝트때는 미리 다 세팅하고 해야겠다고 다짐했음
백엔드 API 문서도 따로 작성하다가, 스웨거를 도입하여 구현과 함께 문서를 작성하도록 개선했음. 하나의 PR 사이클에서 문서화까지 하고 날리게되니 확실히 문서가 누락되는 일이 줄어듦
NCP에서 기본으로 제공하는 마이크로 인스턴스에 개발서버를 띄우니, 스웨거를 통해 바로바로 API 호출을 해보고 결과 형식을 알 수 있어서 개발 편의성이 증가함

평화로운 어느날 갑자기 찾아온

우리 팀은 MacOS 와 Windows를 섞어서 사용하고, 배포 환경은 Linux라서 OS가 달라서 생기는 문제가 종종 발생함. 환경변수 관련이라던지, 런타임의 동작이라던지...
개발환경 자체를 동일하게 맞출 소요가 있었음.
또한, 개발용 DB를 sqlite3에서 Postgres로 전환하고 Redis를 붙이게 되면서, 개발환경에 대한 설정 공수가 늘어나게 됨.
이를 빠르게 설정할 수 있고, 통일된 개발환경을 갖출 수 있는 도구가 필요했다.

Docker 도입과 Docker-compose를 활용한 인프라

딱 떠오르는게 Docker 였음. compose까지 도입해서, 일괄적으로 모든 인프라를 명령어 하나로 설정할 수 있도록 해두었다.
근데 마냥 좋은 것은 아니었음. 도커 런타임 자체도 OS 별로 동작이 달랐음.
특히, HMR과 Hot-reload를 설정하는 과정에서, 각 OS의 파일 변경 시스템 콜이 달라 Windows에선 개발환경이 정말 불편해지는 현상이 있었음.
이를 해결하기 위해 각 레포에서 폴링 옵션을 통해 현재 디렉터리를 감시하도록, 파일 시스템 단 설정이 필요했음.
*nix가 최고야...

Still Incomplete...

아직까지 완벽하지 않다. 더 나아가야 할 지점이 많음.
현재 인프라 설정은 모든것을 항상 새로 빌드하도록 되어있음. 특히 이건 CI/CD 관점에서는 최악의 접근임.
도커의 장점 중 하나인 가벼움을 전혀 활용하지 못하는 형태임. 코드가 바뀌면 새로 빌드하는 과정 자체는 필요하긴 하지만, 전체 인프라를 다 내리고 다시 올릴 필요는 없다.
Github Actions를 통해 코드 변경이 이뤄진 레포의 이미지만 다시 빌드하고, 동작 중인 compose에서 해당 이미지만 교체하여 다시 실행하도록 수정이 필요함.
더 나아가면, Blue-Green 방식의 무중단 배포까지 이뤄질 수 있도록 개선하면 좋을듯 함.