병원별 웹 구축에 seed 저장소를 재사용하고 배포를 자동화한 과정

부스트리의 병원별 웹은 병원마다 사이트를 만들어 따로 배포하는 구조였습니다. 처음에는 병원이 하나 늘 때마다 서버 요청 코드를 다시 짜고, 컴포넌트와 디자인 설정도 처음부터 다시 해야 했습니다.

병원마다 디자인과 일부 설정은 달라도, 관리자에서 설정한 메뉴를 보여 주고 서버 API로 데이터를 가져오는 부분은 모두 같았습니다. 이 같은 작업을 사이트마다 되풀이하는 게 번거로웠습니다.

그래서 동료 프론트엔드 개발자와 공통 부분을 seed 저장소로 묶었습니다. seed 저장소는 병원별 웹을 시작할 때 쓰는 공통 프로젝트이고, 병원별 사이트는 이 저장소를 클론한 뒤 병원 디자인에 맞게 고쳐서 만들었습니다.

공통 컴포넌트와 구현 범위는 둘이 같이 정했습니다. 배포는 병원마다 따로 해야 했기 때문에 파트너 명칭만 넣으면 대상을 찾아 배포하도록 자동화했습니다.

공통 기반과 병원별 사이트 제작

먼저 동료와 공통으로 필요한 컴포넌트를 정하고, shadcn으로 쓸 것과 직접 만들 것을 나눴습니다. 필요한 컴포넌트는 둘이 나눠 구현했습니다.

seed 저장소에는 공통 컴포넌트, 관리자 메뉴 설정, 서버 API 연동을 넣었습니다. 그다음부터는 병원 단위로 작업을 나눠, 각자 seed 저장소를 클론해 맡은 병원의 디자인에 맞게 고쳤습니다.

파트너 명칭 기반 배포

저는 프론트엔드 쪽 AWS 설정을 맡았고, GitHub Actions 배포 흐름을 다음처럼 만들었습니다.

1. 개발자가 배포할 파트너 명칭을 입력합니다.
2. 입력한 명칭으로 AWS 리소스를 조회합니다.
3. 해당 파트너의 ECS를 찾아 Docker 이미지를 배포합니다.

배포는 개발자가 직접 실행했고, 이전 버전으로 되돌려야 할 때는 ECS 롤백 기능을 쓸 수 있게 했습니다.

새 병원 사이트는 seed 저장소를 클론해 그 병원 디자인에 맞게 고치는 방식으로 만들었습니다. 메뉴 설정과 서버 API 연동은 다시 구현하지 않고 공통 기반을 그대로 씁니다.

배포는 병원이 달라도 파트너 명칭만 넣으면 같은 방식으로 실행되고, 필요하면 ECS 롤백으로 이전 버전으로 되돌릴 수 있습니다.