반복되는 데이터 변경을 배포에서 분리하기

랜딩 페이지는 가능한 한 단순하고 독립적으로 운영하고 싶었습니다. 초기에는 별도의 관리 기능을 만드는 것보다 정적 데이터로 시작하는 편이 팀의 상황에도 잘 맞았습니다.

하지만 운영을 시작한 뒤 데이터의 변경 주기가 달라지면서, 처음 선택한 관리 방식을 다시 검토할 필요가 생겼습니다.

처음에는 JSON으로 충분했습니다

스타러커스 랜딩 페이지에는 처방이 가능한 병원 목록이 필요했습니다. 처음에는 이 정보를 JSON 파일로 관리했습니다.

당시 팀에는 병원 정보를 전담해서 관리할 별도의 운영 인원이 없었습니다. 결국 개발자가 정보를 전달받아 반영해야 했기 때문에, 데이터 관리 기능이나 어드민 화면을 따로 만드는 것보다 JSON 파일을 수정하는 편이 단순했습니다.

병원 정보가 많지 않고 변경도 드물다면 이 방식으로 충분하다고 판단했습니다. 랜딩 페이지 역시 다른 제품 기능과 연결하지 않고 독립적으로 배포할 수 있었습니다.

운영을 시작한 뒤 상황이 달라졌습니다. 처방 병원이 거의 매달 추가되면서 JSON 파일을 수정하는 일이 일회성 변경이 아니라 반복되는 작업이 됐습니다.

병원 한 곳을 추가하기 위해 파일을 변경하고, 내용을 확인한 뒤 랜딩 페이지를 다시 배포해야 했습니다. 배포 과정이 어렵지는 않았지만 화면이나 기능이 바뀌지 않았는데도 데이터 변경 때문에 전체 페이지를 다시 배포하고 있었습니다.

이때 문제는 JSON이라는 형식 자체보다 병원 정보의 변경 주기였습니다. 처음 예상했던 것보다 데이터가 자주 바뀌면서, 코드와 함께 관리하는 방식의 불편이 커지고 있었습니다.

일반적인 API 서버와 어드민 화면을 만들 수도 있었습니다. 하지만 운영 인원이 별도로 없는 상황에서 관리 화면까지 만드는 것은 해결하려는 문제보다 구조를 크게 만드는 일처럼 느껴졌습니다.

랜딩 페이지 하나를 위해 백엔드 서버를 별도로 운영하는 것도 피하고 싶었습니다. 페이지는 계속 독립적으로 배포하되, 자주 바뀌는 병원 정보만 코드 밖에서 관리하는 방법이 필요했습니다.

그래서 AWS Amplify를 통해 병원 정보를 조회하고, 데이터는 DynamoDB에 저장하도록 구성했습니다. 병원 정보를 수집하고 등록하는 작업을 위한 도구도 함께 두었습니다.

이후에는 병원 목록이 변경돼도 랜딩 페이지를 다시 빌드하고 배포할 필요가 없어졌습니다. 별도의 어드민 시스템을 만드는 대신, 반복되는 데이터 변경만 페이지의 배포 과정에서 분리한 것입니다.

처음부터 JSON으로 관리한 것이 잘못된 선택이었다고 생각하지는 않습니다. 당시의 팀 구성과 예상했던 변경 빈도를 고려하면 가장 단순한 방법에 가까웠습니다.

다만 운영을 시작한 뒤 같은 변경이 반복된다면, 처음의 선택을 계속 유지하는 것이 여전히 단순한 방법인지는 다시 살펴볼 필요가 있었습니다.

처음에는 단순했던 방식도 운영 상황이 달라지면 더 이상 단순하지 않을 수 있었습니다.

이 경험 이후에는 초기 구조를 정할 때 완성된 운영 환경을 미리 만들기보다, 현재 팀이 감당할 수 있는 방식으로 시작하되 반복되는 변경이 생기는 지점을 살펴보게 됐습니다.

필요한 것은 큰 백엔드가 아니라, 자주 바뀌는 병원 정보를 코드에서 분리해 페이지를 다시 배포하지 않고도 관리할 수 있게 만드는 일이었습니다.