철도 복합물류 의사결정 플랫폼

해결하려던 문제

화물을 도로에서 철도로 옮기려면 화물역, 환적, 셔틀·하역비, 운송 시간, 탄소배출을 함께 비교해야 하지만 정보가 흩어져 있었습니다. 팀은 이 문제를 “철도 노선 탐색”이 아니라 도로와 철도 대안을 같은 기준으로 비교하고, 나중에 다시 확인할 수 있는 의사결정 문제로 정리했습니다.

인천광역시청에서 울산역까지 철도 복합운송과 도로 운송을 비용·시간·탄소로 비교하고 추천 사유를 보여주는 화면 — 실제 화면출발지·도착지를 넣으면 도로 단독운송과 철도 복합운송을 비용·시간·탄소로 비교하고 추천 사유를 보여주는 화면입니다. 화면은 프런트엔드 담당, 계산과 추천 설명은 데이터·AI 담당 팀원이 만들었습니다. 수치는 모의 계산입니다.

본선에서는 제한된 시간 안에 기획, 데이터·AI, 프런트엔드, 백엔드, 발표 자료를 동시에 완성해야 했습니다. 로컬에서는 연결되던 화면과 API가 배포 후에는 동작하지 않았고, 장시간 작업으로 팀원의 부담도 커졌습니다.

시스템 구성

분석 이력 조회 흐름개념도 · 직접 작성

React 화면Firebase Hosting · 배포 설정은 본인
REST · JSON
분석 이력 APIASP.NET Core · Cloud Run · 본인 개발
분석 이력 테이블
PostgreSQLSupabase · EF Core 조회

본인 담당
협업자·팀원 담당
외부 장비·시스템

운송안 계산(Python 분석 API)과 추천 설명(Gemini)은 팀원 담당입니다. 계산 결과가 저장되면 이력 API가 조회·집계합니다.

담당 범위와 협업

직접 한 일

팀장: 문제 정의, 우선순위와 역할 조정
분석 이력 조회 기능: 목록 검색·상세·주간 요약 REST API (C# · ASP.NET Core · EF Core)
프런트엔드·백엔드 통합 디버깅과 QA
Firebase Hosting 설정과 GitHub Actions 배포 환경변수
UI 디자인·결과보고서 제작 참여

팀원 담당

운송안 계산 로직과 AI 추천 설명 (데이터 분석·AI 담당)
화면 구현과 디자인 (프런트엔드 담당)
백엔드·DB 설계 (백엔드 담당)

주요 판단과 선택 이유

분석 결과를 다시 찾아볼 수 있어야 의사결정 도구라고 봤습니다. 이전 분석을 검색하고 다시 비교할 수 있도록 이력 조회 기능을 맡았습니다.
두 배포 오류는 증상별로 나눠 확인했습니다. 한 가지 원인으로 보고 고치면 다른 하나가 남습니다.
AI 도구의 제안은 실제 설정과 대조한 뒤 적용했습니다. ChatGPT와 Claude Code에 오류 현상만 묻지 않고 Firebase 설정·Vite proxy·API 호출 코드·로컬과 배포 환경의 차이를 함께 제공해 원인 후보와 확인 순서를 받았고, 하나씩 실제 설정과 맞춰 봤습니다.
마감 직전에는 담당 구분보다 완성을 우선했습니다. 한 팀원이 부담 때문에 중도 하차를 고민할 때 작업을 다시 나눴고, 본인은 통합 디버깅·QA·배포를 추가로 맡았습니다.

구현 과정

1. 분석 이력 조회 기능

이전 분석을 찾아 다시 비교할 수 있게 하는 기능입니다. 목록 검색, 접수번호 상세, 주간 요약을 각각 API로 제공했습니다.

API	내용
`GET /api/history`	출발지·도착지 검색, 기간·운송 방식·비용 절감 조건 필터, 비용·탄소 기준 정렬, 페이지네이션 (입력값 검증 포함)
`GET /api/history/{receptNo}`	접수번호로 입력 조건과 결과 JSON 상세 조회
`GET /api/history/summary`	주간 분석 건수, 철도 추천 건수·비율, 평균 비용·탄소 절감률, 최근 분석

분석 건수·평균 절감률 요약 카드와 검색 필터, 분석 경로·추천 결과·절감률이 담긴 분석 기록 목록 화면 — 실제 화면위 API를 쓰는 분석 히스토리 화면입니다. 위쪽 요약 카드는 주간 요약 API, 아래 검색 필터와 목록은 목록 검색 API의 결과입니다. 수치는 모의 계산입니다.

2. 배포 후 두 오류를 서로 다른 원인으로 분리

로컬에서는 문제없던 기능이 Firebase 배포 후 두 군데에서 동시에 실패했습니다.

증상	원인	수정
특정 화면에서 새로고침하면 오류	React 화면 경로를 Firebase가 실제 파일 경로로 찾음	모든 경로를 `index.html`로 보내는 rewrite
화면의 API 요청이 백엔드에 닿지 않음	로컬은 Vite proxy가 백엔드로 넘겨 줬지만, 배포 빌드에는 백엔드 주소가 없음	배포 단계에서 Cloud Run API 전체 주소를 환경변수로 주입

실제로 고친 설정입니다. 위는 firebase.json, 아래는 배포 워크플로입니다.

"rewrites": [
  { "source": "**", "destination": "/index.html" }
]

- run: npm run build
  env:
    VITE_SHIPPING_API_PATH: https://<cloud-run-host>/api/Shipping/recommend
    VITE_HISTORY_SUMMARY_API_PATH: https://<cloud-run-host>/api/history/summary
    VITE_HISTORY_LIST_API_PATH: https://<cloud-run-host>/api/history

수정 후 다시 배포해 화면 접근 → API 호출 → 데이터 저장 → 이력 조회까지 전체 흐름을 점검했습니다.

3. 마감 전 업무 재분배

마감이 가까워지자 특정 업무가 밀렸습니다. 작업을 다시 나눈 뒤 오류가 이어지는 동안에도 진행 상황과 다음 작업을 팀에 계속 공유했습니다.

결과와 검증

조건 입력 → 운송안 분석 → 비용·시간·탄소 비교 → 추천 설명 → 분석 이력 검색·상세 조회로 이어지는 프로토타입을 완성했습니다. 비용·탄소 수치는 공개·가공 데이터로 만든 모의 계산입니다.
결과보고서, 시연 영상, 프런트엔드·백엔드 소스, UI 화면을 본선 기한 안에 네 명이 함께 제출했습니다.
팀원들에게서 “상황 전환이 빠르고, 장시간 작업에서도 집중력을 유지하며 팀원의 부담을 잘 살핀다”는 평가를 받았습니다.