서비스

[랭체인 중간프로젝트] 데이터베이스 구축 및 UI와 알고리즘 산출물 취합

hurwan 2026. 8. 26. 21:42

2026-08-26 작업 요약

작성 목적: 오늘 진행한 RunStop 프로젝트 설계, 팀원 작업물 검토, DB/GIS/알고리즘/DTO 흐름 정리를 프로젝트 기록용으로 요약한다.

1. 오늘 작업 개요

오늘은 RunStop 프로젝트가 단순 기획 단계에서 실제 구현 구조를 정리하는 단계로 넘어가도록, 전체 자료를 다시 확인하고 팀원 산출물을 통합 관점에서 검토하였다.

주요 작업은 다음과 같다.

  • 최신 기획안, GitHub 문서, Jira, Figma, 기존 설계 문서를 기준으로 현재 프로젝트 상태를 재정리하였다.
  • 역할을 프론트, 데이터/알고리즘, 서비스 아키텍처/회색지대 기술로 나누고 각 파트가 먼저 확인해야 할 항목을 정리하였다.
  • DB 구조를 실제 서비스 흐름에 맞게 다시 검토하고, 불필요하거나 아직 확정하기 어려운 테이블을 조정하였다.
  • 프론트 UI 산출물을 확인하면서 백엔드/DB 설계와 충돌할 수 있는 지점을 기록하였다.
  • 팀원이 작성한 알고리즘/API/TMAP 문서를 읽고, RunStop 서비스에서 실제로 주고받을 DTO 흐름으로 다시 정리하였다.
  • 알고리즘이 AI로 모든 것을 대체하는 구조가 아니라, 경로 생성은 검증된 알고리즘과 GIS 기반으로 처리하고 AI는 사용자 조건 해석 또는 추천 랭킹 보조에 사용하는 방향이 더 적절하다고 판단하였다.

2. DB 및 서비스 구조 정리

기존 DB 구조를 그대로 두기보다 실제 기능 흐름을 기준으로 테이블 역할을 다시 보았다.

정리한 주요 테이블은 다음과 같다.

  • users: 사용자 기본 정보, 경험치, 권한
  • user_auths: Google OAuth 인증 정보
  • running_goal: 주간/월간 러닝 목표
  • route_requests: 사용자의 경로 추천 요청
  • route_recommendation: 알고리즘이 생성한 후보 경로
  • route_point: 추천 경로의 주요 지점
  • running_session: 실제 러닝 1회 기록
  • running_trackpoint: 러닝 중 주기적으로 저장되는 GPS 지점

오늘 논의에서 정리한 핵심 결정은 다음과 같다.

  • 현재 범위에서는 Google OAuth 단일 로그인으로 간다.
  • 별도 회원가입 Form이나 계정 찾기 기능은 우선 제외한다.
  • users와 user_auths는 분리해 두어 향후 다른 Provider 확장 가능성은 남긴다.
  • user_profile은 알고리즘 Feature가 아직 확정되지 않았으므로 현재 DB에서는 제외하는 방향으로 정리하였다.
  • route_choice는 별도 테이블로 두기보다 route_requests.selected_recommendation_idx로 선택된 추천 경로를 표현하는 방향이 더 단순하다고 판단하였다.
  • running_session은 사용자와 추천 경로를 직접 참조하도록 하여 기록 조회 시 불필요한 JOIN을 줄인다.
  • 전체 경로는 route_recommendation.geometry에 LineString으로 저장하고, 주요 지점은 route_point.point에 Point로 저장하는 방향을 정리하였다.

3. GIS / PostGIS 정리

RunStop은 경로와 주변 시설을 다루기 때문에 일반 DB 컬럼만으로는 부족하고, PostGIS 기반의 공간 데이터 처리가 필요하다고 정리하였다.

오늘 정리한 기준은 다음과 같다.

  • 기본 좌표 데이터는 GPS 위경도 기준인 EPSG:4326으로 받는다.
  • 거리 계산, Buffer 계산 등 실제 공간 분석이 필요한 경우 EPSG:5179 같은 평면 좌표계 변환을 고려한다.
  • 프론트/백엔드 DTO에서는 { latitude, longitude } 순서로 통일한다.
  • GIS 라이브러리 또는 PostGIS 내부에서는 일반적으로 longitude, latitude 순서가 사용될 수 있으므로 변환 지점을 명확히 해야 한다.
  • 시설 데이터는 Point, 경로는 LineString, 공원 같은 영역 데이터는 Polygon으로 구분한다.
  • 화장실, 편의점, 가로등, CCTV 등 주변 시설은 경로 주변 Buffer를 기준으로 접근성이나 밀도를 계산하는 방식이 적절하다.

4. 프론트 작업물 검토

프론트 산출물을 보면서 화면 구성 자체는 서비스 흐름을 충분히 담고 있다고 보았고, 백엔드/DB와 맞춰야 하는 부분을 따로 기록하였다.

확인한 주요 화면은 다음과 같다.

  • 랜딩 / 로그인
  • 메인 페이지
  • 마이페이지
  • 코스 설정
  • 러닝 조건 설정
  • 조건 확인
  • 추천 코스 비교
  • 코스 상세
  • 실시간 러닝
  • 러닝 기록
  • 러닝 상세

검토하면서 남긴 주요 의견은 다음과 같다.

  • 로그인은 Google OAuth 하나로 단순화하는 것이 현재 범위에 맞다.
  • 메인 페이지에는 이번 주 또는 이번 달 목표 달성률을 보여줄 수 있다.
  • 추천 코스가 어떤 기준으로 추천되는지 화면에서 설명할 필요가 있다.
  • 코스 설정에서 필수 경유지 개수 제한이 필요할 수 있다.
  • 자연어 입력과 빠른 선택 조건이 어떤 차이를 갖는지 정리해야 한다.
  • 러닝 기록에는 거리, 시간, 평균 페이스뿐 아니라 완주율이나 만족도도 고려할 수 있다.
  • 실시간 러닝 화면은 GPS 연결 상태, 이동 거리, 남은 거리, 페이스, 운동 시간, 일시정지 기능이 필요하다.
  • 프론트에 있는 알림 설정, 즐겨찾기, 목표 표시 방식은 백엔드/DB 정책과 맞춰야 한다.

5. 알고리즘 문서 검토 및 정리

알고리즘 폴더의 팀원 작업물을 확인하고, RunStop 경로 추천 흐름을 다시 정리하였다.

확인한 흐름은 다음과 같다.

  1. 사용자가 출발지, 목적지, 거리, 조건을 입력한다.
  2. 백엔드가 TMAP 보행자 경로 API를 호출한다.
  3. 여러 후보 경로를 생성한다.
  4. TMAP 응답 좌표를 서비스 공통 Route 형식으로 변환한다.
  5. 경로를 GIS LineString으로 변환한다.
  6. 경로 주변 시설과 환경 데이터를 분석한다.
  7. 거리, 경사, 화장실, 편의점, 공원, 가로등, CCTV 등의 Feature를 만든다.
  8. Hard Constraint를 먼저 검사한다.
  9. Soft Constraint는 점수화한다.
  10. 사용자 중요도 가중치를 적용한다.
  11. 최종 점수를 계산한다.
  12. 유사한 경로를 제거한다.
  13. 최종 Top 3 후보를 반환한다.

검토하면서 느낀 핵심은, 알고리즘 문서의 흐름은 좋지만 “AI가 어디에 들어가는가”, “사용자 중요도가 어느 단계에서 어떻게 적용되는가”를 더 명확히 해야 한다는 점이다.

현재 방향은 다음과 같이 잡는 것이 적절하다고 보았다.

  • 경로 생성 자체는 Dijkstra, A*, K-Shortest Path, TMAP API, GIS 분석을 기반으로 한다.
  • AI는 모든 경로를 직접 생성하는 역할보다는 자연어 조건을 구조화하거나, 후보 경로의 개인화 랭킹을 보조하는 역할로 두는 것이 낫다.
  • 사용자가 선택한 경로와 만족도 피드백은 향후 개인화 추천 모델의 학습 데이터로 사용할 수 있다.

6. DTO 흐름 정리

알고리즘/API/TMAP 문서를 읽은 뒤, 프론트와 백엔드가 실제로 주고받을 데이터 흐름을 DTO 기준으로 다시 정리하였다.

6.1 프론트 추천 요청

POST /api/routes/recommend

{
  "start": {
    "latitude": 37.543,
    "longitude": 127.044
  },
  "end": {
    "latitude": 37.543,
    "longitude": 127.044
  },
  "wayPoints": [
    {
      "name": "편의점",
      "coordinate": {
        "latitude": "float",
        "longitude": "float"
      }
    }
  ],
  "routeType": "LOOP",
  "targetDistanceKm": 7.0,
  "distanceTolerance": 10,
  "requirements": {
    "toilet": true
  },
  "weights": {
    "distance": 5,
    "elevation": 4,
    "toilet": 5,
    "store": 2,
    "park": 3,
    "night": 5
  }
}

6.2 Backend에서 TMAP으로 요청

프론트 요청을 TMAP API가 요구하는 형태로 변환한다.

{
  "start": {
    "latitude": 37.543,
    "longitude": 127.044
  },
  "end": {
    "latitude": 37.543,
    "longitude": 127.044
  },
  "waypoints": [
    {
      "latitude": 37.545,
      "longitude": 127.047
    }
  ]
}

6.3 TMAP 응답을 Backend 공통 형식으로 변환

{
  "routeId": 101,
  "distanceKm": 7.1,
  "coordinates": [
    {
      "latitude": 37.5430,
      "longitude": 127.0440
    },
    {
      "latitude": 37.5432,
      "longitude": 127.0445
    }
  ]
}

이후 Backend에서는 해당 좌표 배열을 LineString으로 변환하고, 주변 시설과 경사도 등 Feature를 계산한다.

6.4 프론트에 추천 후보 응답

{
  "success": true,
  "data": {
    "exactMatch": true,
    "routes": [
      {
        "routeId": 101,
        "distanceKm": 7.1,
        "conditionScore": 89.7
      }
    ]
  },
  "message": "추천 코스 조회가 완료되었습니다."
}

6.5 코스 상세 조회

GET /api/routes/{routeId}

{
  "success": true,
  "data": {
    "routeId": 101,
    "routeName": "서울숲 순환 코스 A",
    "distanceKm": 7.1,
    "estimatedMinutes": 48,
    "elevationGain": 34,
    "conditionScore": 89.7,
    "facilities": {
      "toilets": [
        {
          "name": "서울숲 공중화장실",
          "distanceFromRoute": 32,
          "latitude": 37.543,
          "longitude": 127.044
        }
      ],
      "stores": [
        {
          "name": "CU 서울숲점",
          "distanceFromRoute": 45,
          "latitude": 37.544,
          "longitude": 127.045
        }
      ]
    },
    "routeCoordinates": [
      {
        "latitude": 37.543,
        "longitude": 127.044
      }
    ],
    "recommendReasons": [
      "목표 거리와 유사합니다.",
      "누적 상승고도가 낮습니다.",
      "야간 조명 인프라가 풍부합니다."
    ]
  }
}

7. 오늘 만든 산출물

오늘 작업하며 남긴 주요 산출물은 다음과 같다.

  • DB/GIS 구조 정리
  • 서비스 아키텍처 및 역할 분리 정리
  • 프론트 산출물 검토 기록
  • 알고리즘/API/TMAP 문서 검토 기록
  • DTO 처리 흐름 정리 PDF
  • 프론트 UI 리뷰 HTML
  • 멘토님에게 질문할 항목 정리

특히 docs/02_프로젝트_설계/알고리즘 폴더에서는 팀원 작업물을 읽고 그대로 두는 것이 아니라, 실제 프론트/백엔드/알고리즘 연결 흐름으로 다시 정리하였다.

8. 남은 확인 사항

아직 확정되지 않았거나 다음에 더 확인해야 할 부분은 다음과 같다.

  • PostGIS 사용 방식과 좌표계 변환 처리
  • 거리 계산 시 EPSG:4326과 EPSG:5179를 어떤 시점에 변환할지
  • route_requests.element_conditions를 JSON으로 둘지 명시 컬럼으로 나눌지
  • 사용자 조건 가중치를 1~5 단계로 받을지, 내부 점수로 변환할지
  • 경유지 개수 제한과 순서 지정 방식
  • 자연어 입력 결과를 어떤 JSON Schema로 제한할지
  • 조건에 맞는 경로가 없을 때의 응답 방식
  • TMAP API 호출 횟수, 비용, timeout, 실패 처리
  • 대량 공간 데이터 조회 시 Bounding Box 또는 Buffer 기반 1차 필터링 방식
  • Python Worker를 둘 경우 Node.js와의 요청/응답 구조
  • 러닝 기록의 완주율, 칼로리, 구간별 페이스 계산 기준

9. 정리

오늘 작업의 핵심은 팀원들이 만든 자료를 단순히 모아두는 것이 아니라, 실제 서비스가 동작하기 위해 필요한 연결 규격으로 다시 정리한 것이다.

특히 DB, GIS, TMAP, 알고리즘, 프론트 화면은 각각 따로 보면 괜찮아 보여도 실제 구현에서는 DTO와 좌표계, 경로 저장 방식, 추천 응답 구조가 어긋나면 통합이 어려워질 수 있다.

그래서 오늘은 다음 기준을 중심으로 정리하였다.

  • 서비스에서 실제로 저장해야 하는 데이터는 무엇인가
  • 프론트가 보내고 받아야 하는 JSON은 어떤 형태인가
  • TMAP 응답을 우리 서비스 Route 형식으로 어떻게 바꿀 것인가
  • 경로와 시설을 PostGIS에서 어떻게 다룰 것인가
  • 알고리즘과 AI의 역할을 어디까지로 나눌 것인가
  • 팀원 작업물과 현재 DB/백엔드 설계 사이의 충돌 지점은 무엇인가

결과적으로 2026-08-26 기준 RunStop은 기획 아이디어를 넘어서, 구현을 시작하기 위한 DB 구조, DTO 흐름, 알고리즘 처리 단계, 프론트와의 연결 지점까지 상당 부분 구체화된 상태로 볼 수 있다.

'서비스' 카테고리의 다른 글

[랭체인 중간프로젝트] 데이터베이스 설계 병합 전 체크  (0) 2026.08.31
[랭체인 중간프로젝트] 서버 구조 및 DB, 워커, 인터페이스 준비  (0) 2026.08.30
[랭체인 중간프로젝트] 서버 아키텍처 준비 - 이식성을 고려한 설계 01  (1) 2026.08.29
[랭체인 중간프로젝트] 노드와 파이썬 워커, 알고리즘 구현부 추상화  (0) 2026.08.29
[랭체인 중간프로젝트] 프로젝트 기반 설계 구조 생성  (0) 2026.08.26

'서비스'의 다른글

  • 현재글[랭체인 중간프로젝트] 데이터베이스 구축 및 UI와 알고리즘 산출물 취합

관련글

티스토리툴바