[로컬로그 개발기 5] 테스트를 통과한 다음, 실제 사용할 환경에서 확인한 것들

지난 글에서는 같은 관광지가 이틀 일정에 중복되고, 이동시간의 세부 내역이 화면과 저장 과정에서 빠졌던 문제를 다뤘다. 추천 결과를 고친 뒤에도 확인할 것은 남아 있었다. 사용자가 로그인하고, 지도를 열고, 코스를 저장하는 과정이 배포된 서비스에서도 이어지는지 봐야 했다.

우리는 처음에 Android 앱을 제출할 계획이었다. 하지만 앱 심사가 늦어지면서 공모전에는 웹으로 최종 제출했다. 이번 글에서는 그 무렵 웹에서 확인했던 문제와 배포 과정을 돌아보려고 한다. 현재 로컬로그 Android 앱은 구글 플레이에도 출시돼 있다.

기능 목록을 확인하는 것에서 화면을 따라가는 것으로

2026년 9월 20일에는 배포된 웹을 브라우저 자동화 도구인 Playwright로 점검했다. 비로그인 상태에서 홈과 관광지 목록을 살펴보고, 시험 계정으로 로그인한 뒤 여행 조건 입력부터 추천·일정 수정·저장·삭제까지 이어서 확인하는 방식이었다.

여행 날짜와 테마를 고르면 추천이 나오는지만 본 것은 아니다. 검색어를 지웠을 때 전체 목록으로 돌아오는지, 테마를 선택한 채 새로고침해도 그 조건이 유지되는지, 관광지 상세 주소로 바로 들어가도 같은 화면이 뜨는지 확인했다. 웹에서는 앱 안의 버튼뿐 아니라 주소창, 새로고침, 뒤로 가기도 사용자의 이동 경로였다.

이때 홈페이지와 관광지 상세의 진입 방식이 다르다는 점도 발견됐다. 홈에서는 비로그인 사용자에게 로그인을 안내했지만, 상세의 ‘이 장소로 코스 만들기’를 누르면 여행 조건 입력 화면까지 들어갈 수 있었다. 마지막 추천 요청까지 인증을 우회할 수 있다는 뜻은 아니었다. 다만 같은 기능으로 들어가는 두 입구가 서로 다르게 동작하고 있었다.

기능 이름 옆에 체크 하나를 붙이는 것으로는 이 차이가 잘 드러나지 않았다. 어디에서 들어왔고, 로그인은 돼 있었고, 다음 화면에서 무엇을 기대했는지까지 있어야 검사할 대상이 분명해졌다.

목록의 지도는 보이는데 상세의 지도는 안 보였다

같은 점검에서 관광지 상세의 위치 영역에 ‘지도를 불러오지 못했어요.’라는 문구가 나타났다. 반면 관광지 목록의 지도와 추천 결과의 코스 지도는 표시됐다. 카카오 지도를 쓴다는 점은 같아도, 한 화면에서 정상이라고 다른 화면까지 정상인 것은 아니었다.

당시 상세 화면에는 지도를 넣는 iframe 자체가 생성되지 않았다. iframe은 웹페이지 안에 별도의 웹 화면을 담는 틀이다. 지도 그림을 내려받지 못한 것인지, 그 틀을 만들기 전부터 막힌 것인지 구분하려면 화면 문구와 브라우저 상태를 함께 봐야 했다.

그런데 같은 상세 화면을 다섯 번 더 열었을 때는 지도가 정상적으로 떴다. 로그인된 상태에서 실패를 보기는 했지만, 로그인 때문에 발생한다고 확정할 수는 없었다. 콘솔에 한 차례 나타난 null 관련 오류도 발생 조건을 좁히지 못했다. 이 단계에서 단위 테스트가 통과했다는 이유로 지도 문제를 해결했다고 표시할 수는 없었다.

9월 23일에는 실제 카카오 연결 계정으로 로그아웃부터 다시 시작했다. 카카오 인증 후 홈으로 돌아오고, 월정교와 파도소리길의 상세 지도에서 큰 지도를 열었다가 돌아오는 흐름을 확인했다. 상세 페이지를 새로고침한 뒤 목록 지도와 MY 화면도 확인했다.

로그인 한 번으로 끝내지 않고 지도 왕복과 새로고침까지 이어서 확인했다

이 과정에서 지도 타일과 위치 마커가 실제로 표시됐고, 새로고침 뒤에도 연결 계정이 유지됐다. 해당 점검에서 수집된 콘솔 오류는 없었다. 다만 앞선 간헐 오류의 원인까지 찾아 제거했다는 의미는 아니다. 기존 계정으로 확인한 흐름이 통과한 것이며, 신규 가입이나 모든 기기에서의 동작까지 포함하지는 않았다.

로그인 버튼과 로그인 상태 복원은 다른 일이었다

로그인에는 버튼을 눌러 인증하는 과정 외에, 다시 접속했을 때 이전 상태를 복원하는 과정도 있다. 로컬로그는 저장된 인증 정보를 읽고 서버에 현재 사용자 정보를 요청해 로그인 상태를 확인한다. 화면에 토큰이 남아 있다는 사실만으로 사용자를 로그인 상태로 둘 수는 없다.

별도의 코드 점검에서는 이 복원 과정의 오류가 확인됐다. 인증 정보를 갱신한 뒤 사용자 정보를 다시 요청했는데도 서버가 401을 반환하면, 토큰이 남아 있는 경우 복원 오류가 계속 유지됐다. 401은 그 요청을 인증된 사용자 요청으로 받아들이지 못했다는 응답이다.

수정에서는 인증 갱신 후 재시도한 요청인지를 구분했다. 그 요청도 401이면 비로그인 상태로 복원을 마무리하도록 했다. 토큰을 폐기할지는 인증 갱신 실패를 처리하는 쪽에서 맡고, 일시적인 연결 오류나 서버 오류의 처리는 유지했다. 모든 오류를 같은 로그아웃 처리로 바꾸는 방식은 아니었다.

이 조건은 자동 테스트로 확인할 수 있지만, 실제 카카오 인증 화면을 거쳐 돌아오는 과정은 별도로 봐야 했다. 코드에서 오류 상태를 다루는 검사와 브라우저에서 로그인·새로고침을 따라가는 검사가 서로 다른 빈틈을 맡고 있었다.

검증이 끝났다는 말과 배포됐다는 말 사이

그 무렵 나는 작업 상태를 확인하면서 “배포는 된 건지?”라고 물었다. 답은 아직 아니라는 것이었다. 개발 작업 폴더에서는 관광지 테마와 입장료 처리 변경을 검증했지만, 운영 DB는 이전 상태였고 변경 파일도 배포되지 않은 시점이었다.

개발 환경에서 잘 보이는 결과가 사용자에게도 보이려면 몇 가지가 함께 움직여야 했다. Flutter 웹을 새로 빌드해 배포하고, 서버에도 변경된 코드를 올려야 했다. 기존 DB에 분류 정보를 보충하는 마이그레이션도 적용해야 했다. 마이그레이션은 이미 저장된 DB를 다음 버전의 구조나 데이터 상태로 옮기는 작업이다.

운영에 적용하기 전에는 별도 PostgreSQL DB에서 변경을 적용하고 기존 자료가 보존되는지 검사했다. 배포 직전 운영 DB를 파일로 내보낸 뒤, 그것을 또 다른 빈 DB에 복구하는 확인도 진행됐다. 백업 파일이 있다는 데서 끝내지 않고 실제로 복구할 수 있는지 살펴본 것이다.

당시 복구 검증에서는 원본과 복구본의 35개 테이블에 대해 행 수와 데이터 비교값이 일치했다. 다만 이 사본은 같은 서비스의 DB 저장 공간에 보관한 것이었다. 외부에 암호화해 보관하는 백업까지 마친 상태는 아니었고, 그 부분은 남은 작업으로 구분했다.

코드 검사, DB 반영, 실제 웹 확인은 각각 다른 완료 조건이었다

재점검 후 배포를 요청했고, 9월 23일 웹과 서버에 변경이 반영됐다. 배포된 웹 파일이 검증한 빌드와 같은지 확인하고, 운영 DB의 버전과 기존 관광지·테마 자료의 보존 여부도 대조했다. 서버가 켜졌다는 확인에 더해, 의도한 변경이 올라갔는지 확인한 셈이다.

배포 후에는 웹을 새로고침해 카카오 로그인 상태가 유지되는지, 황성공원 상세에 보충한 테마가 표시되는지 살펴봤다. 지도 타일과 마커, 큰 지도에서 상세로 돌아오는 동작도 다시 확인했다. 다만 입장료 파서의 변경을 배포했다고 모든 기존 요금이 곧바로 다시 정리된 것은 아니었다. 새 코드의 적용과 오래된 데이터의 보정은 따로 확인해야 했다.

공모전에는 웹을 제출했고, 앱 출시는 이어갔다

초기 목표는 Android 앱을 구글 플레이에 올리는 것이었다. 하지만 앱 심사가 지연됐고, 공모전에는 웹으로 최종 제출했다. 9월의 작업 중에는 Android 출시와 RAG 관련 개선을 보류하고 웹 점검을 우선한 시점도 있었다.

제출 형태가 웹으로 바뀌면서 확인해야 할 사용 환경도 분명해졌다. 설치한 앱 안에서 화면을 이동하는 것뿐 아니라, 링크로 곧바로 들어오고 브라우저를 새로고침하고 로그인 화면을 왕복하는 흐름을 점검해야 했다. 작은 화면에서 가로로 넘치지 않는지도 웹에서 확인했다.

앱 쪽에도 별도의 준비가 있었다. Android 배포 준비 과정에서는 업로드용 키로 서명한 AAB 파일, 앱 식별자와 버전, 개인정보처리방침과 계정 삭제 요청 페이지 등을 점검했다. AAB는 구글 플레이에 올리는 앱 배포 파일이다. 파일을 만드는 것과 스토어에 제출하는 것, 심사를 거쳐 설치할 수 있게 되는 것은 각각 다른 단계였다.

현재는 구글 플레이의 로컬로그 페이지에서 앱을 설치할 수 있다. 공모전에 웹으로 제출했던 결정과 이후 Android 앱 출시는 그렇게 이어졌다. 당시의 앱 작업 보류가 프로젝트에서 Android를 포기했다는 뜻은 아니었다.

다음에는 ‘어디까지 확인했는지’를 먼저 적어두고 싶다

이번 과정을 돌아보면 ‘로그인 확인’, ‘지도 확인’, ‘배포 완료’라는 말이 너무 넓었다. 로그인 버튼이 동작한 것인지 새로고침 뒤에도 상태가 유지된 것인지, 목록 지도인지 상세 지도인지, 개발 환경인지 운영 환경인지에 따라 확인한 내용이 달랐다.

다시 한다면 검수 항목을 사용자 행동으로 짧게 적어둘 것 같다. ‘로그아웃 → 카카오 로그인 → 상세 지도 왕복 → 새로고침’처럼 출발 조건과 확인할 결과가 보이면, 수정 뒤에 무엇을 다시 해야 하는지도 분명해진다. 배포를 마쳤다는 보고에도 그때 확인한 화면과 남은 항목을 함께 남기고 싶다.

다음 편에서는 로컬로그를 만들며 도움이 됐던 판단과 아쉬웠던 선택을 돌아보려고 한다. 처음 해결하려던 여행의 문제와 실제로 만든 결과 사이에 무엇이 남았는지도 정리해 보려 한다.

이전 편 · 실제로 코스를 만들어 보니 설계에서 놓친 것이 보였다