안경원 CRM을 혼자 만들면서 배운 것들

회사에서 안경원 고객 관리 프로그램을 기획부터 배포까지 혼자 만들었다.

처음에는 이력서에 쓸 경험을 정리하려고 적어둔 메모였다. 그런데 돌아보니, 작업하면서 어떤 문제를 만났고 무엇을 기준으로 선택했는지에 대한 기록이기도 했다.

어떤 기술을 썼는지보다, 그 과정에서 생긴 개발 기준을 남겨두려고 한다.

요구사항과 개발 범위

안경원 센터마다 원하는 기능이 달랐다. 그렇다고 모든 요청을 그대로 받아들이면 개발 범위가 계속 늘어나고, 프로그램이 해결하려는 문제도 흐려질 수 있었다.

그래서 요구사항을 A, B, C 그룹으로 나누고, 여러 센터에서 공통으로 효용을 얻을 수 있는 기능부터 개발했다. 표현은 달라도 본질적으로 같은 요청은 하나의 기능으로 묶었다.

이렇게 정리하니 무엇을 먼저 만들고 어디까지 구현할지가 명확해졌고, 일정도 이전보다 안정됐다.

사용 환경도 처음부터 고려했다. 현장에서 PC와 태블릿을 함께 사용했기 때문에, 어느 한쪽에서만 편한 프로그램이 되어서는 안 됐다.

이 과정에서 배운 건, 요청을 많이 구현하는 것만큼이나 서로 다른 요청에서 공통의 문제를 찾아내는 일이 중요하다는 점이다.

데이터 마이그레이션과 타입 설계

기존에 사용하던 안경원 프로그램의 데이터를 새 프로그램으로 옮기는 작업도 했다.

여기서 크게 느낀 건 데이터 타입을 처음부터 신중하게 정해야 한다는 점이다. 값을 저장할 수 있다고 해서, 나중에 활용하기에도 좋은 데이터가 되는 건 아니었다.

숫자로 계산해야 하는 값과 문자열로 보관해야 하는 값을 구분하고, 각 필드가 어떤 의미를 갖는지 스키마에 일관되게 반영해야 했다. 이 기준이 모호하면 통계를 만들거나 데이터를 가공할 때 부담이 돌아왔다.

이후에는 해당 데이터를 활용해 Python으로 근시 예측 알고리즘도 만들었다. 데이터를 단순히 보관하는 데서 끝나는 것이 아니라 분석과 예측에 사용하게 되니, 초기 설계의 중요성이 더 크게 느껴졌다.

스키마는 지금 데이터를 넣기 위한 구조이면서, 나중에 그 데이터를 어떻게 사용할지를 결정하는 기준이기도 했다.

서버 개발과 운영

MongoDB는 초기 개발 속도를 높이는 데 도움이 됐다. 다만 기능이 늘어나면서 aggregation 코드도 점점 복잡해졌다.

처음에 편하게 개발할 수 있다는 것이, 이후의 복잡도까지 해결해준다는 뜻은 아니었다. 데이터를 어떻게 조회하고 가공할지에 대한 설계는 결국 별도로 필요했다.

서버 구성은 당시 규모에 맞춰 단순하게 가져갔다. 서버를 여러 대로 늘리는 대신, 하나의 서버에서 PM2로 같은 애플리케이션을 서로 다른 포트에 실행했다. Nginx는 각 포트의 프로세스로 요청을 전달하도록 구성했다.

중요했던 건 더 큰 구조를 미리 갖추는 것이 아니라, 현재 필요한 구성을 혼자 운영할 수 있는 수준으로 유지하는 것이었다.

백업도 직접 구성했다. 당시 사용하던 Atlas 프리티어 환경에서는 자동 백업을 이용하지 못해, EC2에 백업 스크립트를 두고 cron으로 매일 실행했다. 백업 파일은 비공개 S3 버킷에 저장했다.

기능을 만드는 것과 별개로, 데이터를 어떻게 보관하고 지킬지도 개발 범위에 포함된다는 걸 배웠다.

코드가 커지면서 느낀 구조의 필요성

Node.js 서버 코드가 커지면서 NestJS 같은 프레임워크가 왜 필요한지 이해하게 됐다.

처음에는 기능을 구현하는 데 집중했지만, 코드가 늘어날수록 파일과 역할을 어떻게 나눌지가 중요해졌다. 특히 테스트 코드를 작성하려고 보니, 기능이 동작하는 것과 기능을 분리해서 검증할 수 있는 것은 다른 문제였다.

프론트엔드에서도 비슷한 고민을 했다. React 컴포넌트는 단순히 파일을 작게 나누는 것보다, 관련된 기능을 한곳에 모으고 다른 기능에 대한 의존을 줄이는 것이 중요했다.

컴포넌트 하나를 수정하거나 떼어낼 때 주변 코드까지 연쇄적으로 바뀐다면, 분리되어 있어도 독립적이라고 보기는 어려웠다.

서버와 프론트엔드를 만들며 공통으로 느낀 건, 코드 구조는 보기 좋게 정리하기 위한 것이 아니라 변경과 검증을 쉽게 만들기 위한 것이라는 점이다.

데이터 갱신과 홈페이지 기술 선택

TanStack Query를 사용하면서는 캐시를 얼마나 오래 유지할지뿐 아니라, 화면의 데이터를 언제 다시 가져와야 하는지도 중요하게 느꼈다.

최신 데이터가 중요한 화면과 상대적으로 변경이 적은 화면을 같은 기준으로 다루기는 어려웠다. 화면마다 필요한 최신성에 맞춰 데이터 갱신 기준을 정할 필요가 있었다.

홈페이지는 처음에 Next.js의 SSG로 만들었다가 Astro로 전환했다.

당시 구현에서는 JavaScript로 동적으로 생성되는 일부 콘텐츠가 네이버 검색에 제대로 노출되지 않는 문제를 겪었다. 그렇다고 SSR 방식으로 바꾸기에는 서버 운영 비용이 부담스러웠다.

순수 HTML과 JavaScript로 만드는 방법도 고려했지만, 빌드 파일의 해시와 브라우저 캐시를 직접 관리하는 부담이 있었다. 이런 조건을 함께 고려해 Astro를 선택했다.

이 경험에서 중요한 건 어느 프레임워크가 더 좋으냐가 아니었다. 필요한 결과를 얻으면서, 배포와 유지보수의 부담을 어디까지 감당할 수 있느냐가 선택의 기준이었다.

결국 남은 개발 기준

server, ai, front, app 레포지토리를 혼자 관리하면서 가장 크게 배운 건, 기술 선택에는 현재의 조건이 함께 들어가야 한다는 점이다.

요구사항을 모두 구현할 수는 없었고, 처음부터 서버를 여러 대 운영할 필요도 없었다. 익숙한 기술이라고 모든 상황에 적합한 것도 아니었고, 새로운 기술이라고 반드시 도입할 이유가 생기는 것도 아니었다.

결국 필요한 것은 트래픽, 비용, 개발 인력, 유지보수 부담을 함께 보고 선택하는 일이었다.

아직 배울 것은 많다. 그래도 기준 하나는 생겼다.

최신 기술을 많이 붙이는 것보다, 지금 해결해야 할 문제에 필요한 만큼의 기술을 선택하는 것.

이 프로젝트에서 가장 오래 남을 배움은 그 기준인 것 같다.