하나의 코드베이스로 여러 웹 앱 만들기
여러 개의 웹 앱을 하나의 코드베이스에서 만들고 배포한 방법을 정리합니다. 특히 한 번 빌드한 앱을 고객사마다 다른 주소로 띄운 방법을 다룹니다.
지금까지는 주로 뒤쪽(백엔드·인프라) 이야기였습니다. 이번 편은 사용자가 직접 보는 화면(프론트엔드) 쪽입니다.
서비스를 여러 개로 나누니, 화면도 한 개가 아니었습니다.
- 로그인을 전담하는 앱(2편에서 이야기한 인증 사이트)
- 제품 화면 앱이 여러 개
이 앱들은 서로 다르지만, 겹치는 부분이 많았습니다. 디자인(버튼·입력창 같은 공통 요소)이 같고, 로그인 처리 방식도 같습니다. 이걸 앱마다 따로 만들면 같은 코드를 계속 복제하게 됩니다.
공용 창고를 두었습니다
백엔드에서 했던 것과 같은 선택을 화면에서도 했습니다. 앱은 여러 개지만, 코드는 한 레포에 두었습니다.
여러 매장에 비유할 수 있습니다. 매장(앱)은 여러 곳이지만, 공용 창고와 공용 주방을 함께 씁니다. 버튼·입력창 같은 공통 요소, 로그인 처리 같은 공통 기능은 공용 패키지로 빼서 모든 앱이 같은 것을 가져다 씁니다.
- 공통 디자인 요소를 한 번 고치면 모든 앱에 반영됩니다.
- 로그인 처리도 한 곳에만 두고 각 앱이 불러 씁니다.
- 그러면서도 앱은 각각 독립적으로 빌드·배포됩니다. 한 앱을 고쳐도 다른 앱을 다시 배포할 필요는 없습니다.
이 구조를 만들어 주는 도구(Turborepo, pnpm)가 "어떤 앱이 어떤 공용 패키지를 쓰는지"를 추적해서, 바뀐 부분과 연관된 앱만 다시 빌드해 줍니다.
빌드에 박으면 안 되는 것
여기서 4편의 온프레미스 이야기와 다시 만났습니다.
화면 앱(SPA)은 보통 한 번 빌드해서 완성된 파일 묶음을 만들고, 그걸 배포합니다. 문제는 이 앱이 백엔드 API 주소를 알아야 한다는 점입니다. 그런데 그 주소가 고객사마다 다릅니다. 우리 클라우드는 우리 주소를 쓰지만, 온프레미스는 고객사 안의 주소를 씁니다.
API 주소를 빌드할 때 코드에 박아 버리면, 고객사 수만큼 앱을 다시 빌드해야 합니다. 이건 곧 무너집니다.
붕어빵 틀에 가게 주소를 미리 새겨서 굽는 것과 같습니다. 가게가 늘 때마다 틀을 새로 파야 합니다. 대신 빵은 한 번만 굽고, 구운 뒤에 주소 스티커를 붙이면 틀 은 하나로 충분합니다.
그래서 주소 같은 환경별 설정을 빌드에 박지 않고, 앱이 켜질 때 읽는 "설정 쪽지"로 뺐습니다. 앱은 한 번만 빌드하고, 설치되는 환경에 맞는 설정 쪽지만 갈아 끼웁니다. 같은 앱이 환경에 따라 다른 주소를 바라보게 됩니다.
캐시가 옛 설정 쪽지를 들고 있었다
설정 쪽지 방식에도 함정이 있었습니다. 화면 파일은 빠른 응답을 위해 CDN(콘텐츠 전송망)에 캐시됩니다. 그런데 캐시는 설정 쪽지까지 함께 캐시해 버렸습니다.
설정을 바꿔도 CDN이 옛날 쪽지를 계속 내주는 일이 생겼습니다. 새 주소로 바꿨는데 앱은 여전히 옛 주소를 바라봤습니다.
해결은 단순했습니다. 다른 파일은 캐시하되, 설정 쪽지만은 "캐시하지 말 것"으로 표시했습니다. 앱이 켜질 때마다 항상 최신 쪽지를 읽도록요.
이것도 앞선 사고들과 같은 결입니다. "빠르게 하려고 캐시한다"는 좋은 기본값이, 자주 바뀌어야 하는 파일에는 독이 되었습니다. 기본값이 항상 맞는 건 아니라는 점을 또 배웠습니다.
마무리
- 화면 앱이 여러 개여도, 겹치는 부분이 많으면 공 용 패키지로 빼서 한 레포에 두는 편이 낫습니다. 앱은 각각 독립적으로 배포합니다.
- 환경마다 다른 값(API 주소 등)은 빌드에 박지 않습니다. 한 번 빌드하고, 켤 때 읽는 설정으로 분리하면 고객사가 늘어도 다시 빌드하지 않습니다.
- 캐시는 빠르지만, 자주 바뀌는 설정 파일에는 캐시를 꺼야 합니다.
- 백엔드든 프론트든 결국 같은 원칙이었습니다. 공통은 한곳에 모으고, 환경 차이는 가장자리에서 흡수한다.
다음 편에서는 만드는 단계에서 운영하는 단계로 넘어가며 바뀐 것들을 적어 보겠습니다. 버전을 붙이고, 배포를 자동화하고, 무엇이 도는지 들여다보게 된 이야기입니다.