4편에서는 결제 증빙, 알림, 채팅, PWA, 보안처럼 실제 운영을 위해 다듬었던 부분을 정리해봤습니다. 이번에는 앱 기능 자체보다, 만든 앱을 실제 서비스처럼 공개하기 위해 했던 부가 작업들을 적어보려고 합니다.
처음에는 앱만 잘 만들면 끝이라고 생각했습니다. 예약도 되고, 관리자 페이지도 있고, 모바일에서도 어느 정도 동작하면 바로 쓸 수 있을 줄 알았습니다. 그런데 막상 외부에서 접속할 수 있게 만들려고 하니까 로그인, 도메인, 배포, 검색 색인 같은 작업이 따로 필요했습니다.
먼저 구글 로그인을 붙여봤습니다. 일반 회원가입만 있어도 되긴 했지만, 사용자가 매번 이메일과 비밀번호를 입력하는 것보다 구글 계정으로 바로 로그인하는 게 더 편할 것 같았습니다. 그래서 Google OAuth를 추가해봤습니다.
처음에는 버튼만 붙이면 바로 될 줄 알았습니다. 그런데 실제로 해보니까 생각보다 잘 안 됐습니다. 로컬에서는 되는 것 같은데 배포 환경에서는 안 되거나, 버튼이 제대로 렌더링되지 않거나, 모바일 브라우저에서 버튼이 잘리는 문제가 있었습니다. 특히 Google Identity Services는 등록된 도메인과 redirect 설정이 맞지 않으면 바로 막혀서, 승인된 origin과 callback 흐름을 계속 확인해야 했습니다.
그래서 구글 로그인은 단순히 프론트에 버튼을 붙이는 작업이 아니라, 서버에서 토큰을 검증하고, 배포 도메인을 OAuth 설정에 맞추고, 브라우저별 렌더링 문제까지 같이 봐야 했습니다. 처음에는 로그인 버튼 UI 문제인 줄 알았는데, 실제로는 OAuth 설정, 쿠키, 도메인, 브라우저 정책이 다 연결되어 있었습니다.
카카오 로그인도 추가해봤습니다. 한국 사용자에게는 카카오 로그인이 익숙하기 때문에 넣어두면 접근성이 좋아질 것 같았습니다. 그런데 카카오 로그인도 redirect URI 때문에 많이 막혔습니다. 개발할 때 쓰는 주소와 실제 배포 주소가 다르면 로그인이 실패했고, callback 이후 세션을 앱으로 넘기는 부분도 맞춰야 했습니다.
처음에는 redirect URI를 고정값처럼 넣어봤는데, 배포 환경이 바뀌면 다시 문제가 생겼습니다. 그래서 실제 요청이 들어온 host를 기준으로 redirect URI를 처리하도록 수정했습니다. 이렇게 바꾸니까 로컬과 배포 환경 차이 때문에 생기던 문제를 줄일 수 있었습니다.
도메인 연결도 해봤습니다. 배포 플랫폼에서 제공하는 기본 주소로도 접속은 가능했지만, 실제 서비스처럼 보이려면 도메인이 필요했습니다. 도메인을 연결하면서 DNS 설정, HTTPS 적용, 프론트와 백엔드 주소 분리 같은 부분을 확인했습니다. 이때부터는 “코드가 동작한다”와 “서비스처럼 접속된다”가 다른 문제라는 걸 느꼈습니다.
검색 노출도 신경 써봤습니다. 앱을 만들었는데 검색했을 때 아무것도 안 나오면 외부에서 찾기 어렵기 때문에 Google Search Console에 등록해봤습니다. 처음에는 그냥 사이트 주소만 넣으면 되는 줄 알았는데, 실제로는 소유권 확인, sitemap.xml, robots.txt, 색인 요청 같은 작업이 필요했습니다.
소유권 확인을 위해 구글에서 제공하는 인증 파일을 추가하고, 검색 엔진이 어떤 페이지를 읽어야 하는지 알려주기 위해 sitemap.xml도 만들었습니다. 그리고 검색을 막지 않도록 robots.txt도 정리했습니다. 처음에는 이런 파일들이 별로 중요하지 않을 줄 알았는데, 검색 노출을 하려면 기본 설정이 꽤 중요했습니다.
색인 작업을 하면서도 바로 검색 결과에 뜨지는 않았습니다. 등록했다고 즉시 반영되는 게 아니라, 구글이 페이지를 크롤링하고 색인할 때까지 시간이 필요했습니다. 그래서 Search Console에서 색인 요청을 하고, 사이트맵이 정상적으로 읽히는지 확인했습니다. 이 과정에서 앱도 결국 웹 서비스이기 때문에 검색 엔진이 이해할 수 있는 구조가 필요하다는 걸 알게 됐습니다.
배포 후에는 캐시 문제도 많이 겪었습니다. 코드를 수정했는데 실제 사이트에서는 예전 화면이 계속 보이는 경우가 있었습니다. 처음에는 배포가 안 된 줄 알았는데, 알고 보니 브라우저 캐시나 서비스 워커 캐시가 남아 있는 문제였습니다. 그래서 서비스 워커 캐시 버전을 올리고, HTML이나 JS 파일은 너무 오래 캐시되지 않도록 설정을 바꿨습니다.
특히 PWA를 적용하면 장점도 있지만, 캐시 관리가 더 중요해졌습니다. 사용자는 앱처럼 빠르게 접근할 수 있지만, 개발자는 업데이트가 제대로 반영되는지 계속 신경 써야 했습니다. 기능을 고쳤는데 사용자가 예전 파일을 보고 있으면 실제로는 버그가 고쳐지지 않은 것처럼 보이기 때문입니다.
이 과정에서 느낀 점은, 앱을 만드는 것과 앱을 공개하는 것은 다른 단계라는 것이었습니다. 예약 기능을 만들고 관리자 페이지를 만드는 건 제품의 핵심 기능을 구현하는 일이었습니다. 하지만 OAuth, 도메인, 검색 색인, 배포 설정, 캐시 처리는 그 제품을 실제 사용자가 접근할 수 있는 서비스로 만드는 일이었습니다.
처음에는 부가 작업이라고 생각했지만, 실제로는 서비스 완성도에 큰 영향을 주는 부분이었습니다. 로그인이 안 되면 사용자는 시작도 못 하고, 도메인이 불안정하면 신뢰가 떨어지고, 검색에 안 잡히면 찾기 어렵고, 캐시가 꼬이면 수정한 기능이 반영되지 않습니다.
이번 프로젝트를 하면서 단순히 기능을 만드는 것뿐만 아니라, 실제 서비스처럼 운영되기 위해 필요한 주변 작업들도 경험해볼 수 있었습니다. OAuth 설정, 도메인 연결, 검색 색인, 배포 환경 차이, 캐시 문제까지 직접 부딪혀보면서 웹앱을 공개하는 과정이 생각보다 넓다는 걸 알게 됐습니다.
다음에는 이 프로젝트를 전체적으로 돌아보면서, 처음 생각했던 것과 달랐던 점, 가장 오래 걸렸던 부분, 그리고 다시 만든다면 다르게 설계하고 싶은 부분들을 정리해보려고 합니다.
