PostGIS로 주변 정상을 탐색하고 GPS 정상 인증과 산행 기록을 관리하는 백엔드를 개발했습니다. 회원·정상·산행 서비스를 MSA로 구성하고 데이터베이스를 분리했으며, 산행 사진은 MinIO 객체 스토리지에 저장합니다.
SCOPE
담당 업무 및 개발 내용
회원 인증, 위치 기반 정상 탐색, GPS 정상 인증과 산행 기록·사진 관리 기능을 개발했습니다. Gateway와 도메인별 서비스를 구성하고 Database per Service 방식으로 데이터 소유권을 분리했습니다.
정상 탐색
PostGIS 공간 검색
서비스 구조
MSA · 개별 DB
산행 사진
MinIO 객체 저장
01 / ARCHITECTURE
시스템 구성과 처리 흐름
도메인별 서비스와 데이터 소유권
클라이언트정상 탐색 · 산행 기록
Gateway도메인별 요청 라우팅
개별 서비스회원 · 정상 · 산행
서비스별 DBExposed · PostGIS
Gateway가 요청을 도메인 서비스로 전달하고 각 서비스는 자신의 데이터베이스를 관리합니다. 산행 서비스는 정상 서비스의 HTTP API로 기준 좌표를 조회하며, 사진 원본은 MinIO에 보관합니다.
02 / IMPLEMENTATION
주요 기능과 설계
기능별 처리 흐름과 문제 해결 과정, 설계 이유와 구현 결과를 소개합니다.
FEATURE 01 구현 완료
GPS 정상 인증
GPS 정확도와 정상까지의 거리를 기준으로 산행 인증을 처리합니다.
GPS 정상 인증 처리 흐름
GPS 검사정확도 ≤ 50m
정상 조회HTTP로 좌표 조회
거리 계산정상까지 ≤ 100m
기록 저장KST 일일 중복 검사
PROBLEM
문제
오차가 큰 위치 정보나 같은 정상의 반복 인증이 산행 기록에 반영되지 않도록 인증 기준이 필요했습니다.
SOLUTION
해결
GPS 정확도 50m 이하, 정상과의 거리 100m 이내 조건을 서버에서 검사했습니다. 같은 정상은 한국 시간 기준 하루 한 번 인증하도록 제한하고 산행 기록과 방문 집계를 함께 저장합니다.
설계 이유와 트레이드오프
정상 조회는 DB 트랜잭션 밖에서 처리
정상 서비스의 응답을 기다리는 동안 DB 트랜잭션을 유지하지 않도록 구성했습니다. 다만 정상 서비스에 장애가 발생하면 인증 요청도 영향을 받으므로 서비스 간 의존성을 고려해야 합니다.
인증 시점의 정상 정보 보관
정상 이름·고도·지역을 산행 기록에 스냅샷으로 저장했습니다. 기록 조회에 필요한 서비스 간 호출을 줄이고 당시 정보를 유지하는 대신 기준 데이터가 바뀌어도 과거 기록에 자동 반영되지는 않습니다.
VALIDATION
구현 결과와 테스트
서비스 테스트로 산행 기록·방문 집계 생성, GPS 정확도 기준 초과 시 거절, 같은 날짜 중복 인증 거절과 날짜 변경 후 재인증을 점검했습니다.
FEATURE 02 구현 완료
정상 공간 탐색
이름, 지도 영역과 반경 조건으로 정상을 탐색합니다.
정상 공간 탐색 처리 흐름
탐색 조건이름 · 영역 · 반경
정상 서비스조회 조건 구성
PostGIS공간 함수 · GiST
후보 응답거리 기준 정렬
PROBLEM
문제
위도·경도 값을 보관하는 것에서 나아가 지도에 표시할 정상과 현재 위치 주변의 정상을 찾아야 했습니다.
SOLUTION
해결
PostGIS의 GEOGRAPHY 좌표와 GiST 인덱스를 사용했습니다. ST_DWithin으로 반경 내 후보를 찾고 ST_Distance로 거리순 정렬을 구현했습니다. 누락된 고도는 별도 배치로 보완합니다.
설계 이유와 트레이드오프
공간 조회는 데이터베이스에서 처리
좌표 데이터를 애플리케이션으로 가져와 모두 계산하는 대신 공간 조건을 DB 조회에 적용했습니다. 거리 단위와 좌표계, 인덱스가 사용되는 조회 형태를 함께 고려해야 합니다.
고도 보완과 조회 요청 분리
외부 고도 API 호출은 별도 배치로 실행하고 기존 고도가 있는 데이터는 유지합니다. 조회 요청의 외부 API 의존성을 줄이는 대신 배치 진행 상태와 실패 처리를 관리해야 합니다.
VALIDATION
구현 결과와 테스트
이름·지도 영역·주변 반경 조회와 거리순 정렬을 구현했습니다. 누락 고도 보완의 요청 처리와 외부 HTTP 연동에는 테스트를 작성했습니다.
FEATURE 03 구현 완료
서비스·DB 분리
회원, 정상과 산행 기록의 책임을 나누고 서비스별 데이터베이스를 구성했습니다.
서비스·DB 분리 처리 흐름
API 요청Gateway 라우팅
개별 서비스회원 · 정상 · 산행
데이터 접근자신의 DB만 사용
서비스별 DBID 참조 · 데이터 분리
PROBLEM
문제
회원 정보, 정상 기준 데이터와 사용자 산행 기록은 변경 이유와 조회 목적이 달라 각 도메인의 책임을 명확하게 나누고 싶었습니다.
SOLUTION
해결
MSA와 Database per Service 구조를 적용해 각 서비스가 자신의 데이터를 관리하도록 구성했습니다. 다른 서비스의 데이터는 논리적인 ID로 참조하고 필요한 상세 정보는 HTTP API로 조회합니다.
설계 이유와 트레이드오프
다른 서비스의 DB에 직접 접근하지 않기
서비스 간 테이블 조인이나 외래 키로 결합하는 대신 API와 식별자로 연동합니다. 변경 범위와 데이터 소유권이 명확해지는 대신 네트워크 지연, 서비스 장애와 데이터 일관성을 별도로 다뤄야 합니다.
기록 조회에 필요한 정보는 스냅샷으로 저장
산행 기록에 필요한 정상 정보를 인증 시점에 저장해 조회 시 서비스 간 호출을 줄였습니다. 데이터 중복을 허용하는 대신 과거 기록의 의미를 유지하는 방식입니다.
VALIDATION
구현 결과와 테스트
Gateway 라우팅, 서비스별 영속성 계층과 데이터베이스 분리, 정상 API를 통한 산행 인증 연동을 구현했습니다.
FEATURE 04 구현 완료
회원·사진 관리
회원 인증과 산행 사진의 저장·조회 기능을 구현했습니다.
회원·사진 관리 처리 흐름
회원 인증JWT · 토큰 회전
산행 기록요청 회원 소유 확인
MinIO사진 원본 저장
산행 DB메타데이터 관리
PROBLEM
문제
회원 인증을 관리하고 산행 기록에 사진을 연결하면서 파일 원본과 기록 정보를 함께 다룰 저장 구조가 필요했습니다.
SOLUTION
해결
회원 서비스에 JWT와 리프레시 토큰 회전을 적용했습니다. 사진 원본은 MinIO에, 메타데이터는 산행 서비스 DB에 저장하며 조회에는 Pre-signed URL을 사용합니다. 업로드 후 DB 저장이 실패하면 객체 삭제를 시도합니다.
설계 이유와 트레이드오프
파일 원본과 메타데이터 분리
파일은 객체 저장소에 보관하고 기록과 연결되는 정보는 DB에서 관리합니다. 두 저장소가 하나의 트랜잭션으로 묶이지 않으므로 저장 실패에 대한 보상과 남은 객체 정리가 필요합니다.
기존 비밀번호 해시와의 호환
새 비밀번호는 Argon2id로 인코딩하고 기존 BCrypt 해시도 검증할 수 있도록 구성했습니다. 인코딩 방식을 변경할 때 기존 계정의 로그인을 유지하는 데 초점을 맞췄습니다.
VALIDATION
구현 결과와 테스트
비밀번호 인코딩 테스트로 Argon2id 생성과 BCrypt 검증·업그레이드 판정을 점검했습니다. 산행 목록에 대표 사진과 사진 개수를 포함하는 조회 로직에도 테스트를 작성했습니다.
03 / RESULTS & TESTING
개발 결과와 테스트
PeakLog 개발 결과
항목
결과
핵심 기능
정상 탐색, GPS 정상 인증, 산행 기록·사진 관리
데이터 구조
서비스별 DB 분리, 정상 정보 스냅샷, MinIO 원본·DB 메타데이터 분리
기능 테스트
GPS 정확도, 일일 중복 인증, 날짜 변경, 비밀번호 해시 호환, 사진 요약 조회
개발 환경
Docker·k3s 기반 구성 및 Android 앱 연동 경험
04 / REFLECTION
개발 회고와 개선 방향
회고
등산 기록이라는 하나의 기능도 정상 데이터 조회, 위치 판정, 기록 저장과 사진 관리로 이어졌습니다. 서비스를 분리하면서 코드 구조뿐 아니라 데이터 소유권과 호출 실패의 영향을 함께 설계해야 한다는 점을 배웠습니다. 조회에 필요한 정보를 스냅샷으로 보관하는 등 서비스 간 의존성을 줄이는 방법도 적용했습니다.
NEXT / 향후 계획
향후 개선 방향
서비스 간 인증 전달과 사진 저장 실패 복구를 보완하고, 앱에서 정상 탐색부터 기록 조회까지 이어지는 통합 테스트를 추가할 계획입니다. 이후 업적과 랭킹 기능으로 산행 기록의 활용 범위를 넓히려 합니다.