01 / SYSTEM INTEGRATION

배송잇다

서버의 경로가
비행의 흐름이 되기까지.

배송 경로와 비행 상태를 연결한 드론 관제 프로젝트. Unity 시뮬레이터의 서버 연동과 경로 실행·장애물 대응을 담당했습니다.

프로젝트: 2026 · 팀 프로젝트
팀 구성·역할: 6명 · 부팀장
개인 담당: Unity·서버 연동, 경로 실행, 궤적·렌더링 개선

소스 저장소 핵심 구현 보기 ↓

배송잇다 프로젝트 실제 서비스 화면 — 배송잇다 실제 실행 화면Unity 도시 장면, 관제 지도와 드론 카메라를 함께 보여 주는 실행 화면입니다. 시뮬레이션 주문의 관제 UI이며 실제 운영 배송 화면은 아닙니다.

01OVERVIEW

반복할 수 있는 비행 환경을 만들다.

실제 기체 비행은 장소와 공역, 안전 조건에 영향을 받습니다. 배송 흐름을 반복해 살펴볼 수 있도록 Unity 시뮬레이터를 서버의 경로·상태 흐름에 연결했습니다.

직접 구현·수정

REST 경로를 Unity 좌표로 해석해 실행하고, 비행 상태를 서버에 전송했습니다. 경로 교체 후에도 실제 궤적을 유지하고, 고속 이동 중 장애물 대응과 도시 렌더링을 개선했습니다.

팀 구성요소와의 연동

백엔드 경로 생성, AI 판정, 사용자 앱과 관제 UI는 팀의 구성요소입니다. 시뮬레이터의 입력·출력과 실행 상태가 이 흐름에 연결되는 부분을 맡았습니다.

경로·궤적 변경 내역 렌더링·카메라 변경 내역

02DATA FLOW

경로는 REST로, 상태는 WebSocket으로.

백엔드가 경로를 만들고 Unity가 경로를 해석·실행합니다. 경로 요청과 비행 상태 보고는 서로 다른 통신 흐름으로 구분했습니다.

방향·역할	계약	처리 내용
Unity → route-serviceREST REQUEST	`GET /api/routes/{orderId}` `POST /api/routes/{orderId}/plan`	경로 조회. 필요할 때 경로 생성 요청.
route-service → UnityREST RESPONSE	`waypoints · sequence`	순서 정렬 후 위경도를 Unity 좌표로 변환해 실행.
Unity → route-serviceWEBSOCKET	`/ws/flight/{orderId}`	위치·고도·상태·진행률·기체 ID·배터리 전송.

서버는 수신 JSON을 PositionUpdate로 파싱해 routeService.updatePosition으로 전달합니다. 주문 식별자는 연결 URL에, 기체 식별자는 메시지에 포함됩니다.

코드에서 확인한 전송 필드 보기

lat · lng · altitudeM · status
progressPct · droneId · batteryPct

전송 계약에는 speed 필드가 없습니다. HUD에 표시되는 속도와 서버에 보내는 필드를 구분합니다.

Unity 연동 코드 좌표 변환 코드 서버 수신 처리

관제 지도에 표시된 경로와 함께 실행되는 Unity 시뮬레이터 — 경로와 시뮬레이터의 연결출발지·목적지·이동 경로와 시뮬레이터를 함께 볼 수 있습니다. 이 화면만으로 GPS 정확도나 경로 최적성을 측정한 것은 아닙니다.

Unity HUD와 관제 지도가 함께 표시된 비행 중 화면 — 비행 상태 표시Unity HUD와 관제의 상태 표시 화면입니다. Unity 임무 진행률과 관제 배송 진행률은 서로 다른 값입니다.

03ENGINEERING

응답을 기다리는 동안에도
이동은 계속되고 있었다.

문제

고정 1초·35m 탐지 기준은 속도가 빨라질수록 대응 여유가 부족했습니다. 서버의 우회 응답을 기다리는 동안 이동이 계속되면 장애물에 접근하거나 얇은 충돌체를 지나칠 수 있었습니다.

판단

응답 시간만 줄이는 대신, 로컬의 이동 단계에서도 정지 판단이 필요했습니다. 속도·시간 간격·제동거리를 반영해 검사 범위를 결정하고 한 단계 이동량을 제한했습니다.

구현

진행 구간과 기체 주변의 충돌을 검사합니다. NonAlloc 탐지 버퍼가 가득 찬 경우 보수적으로 정지하고, 서버 응답이 실패하면 임의의 정상 경로를 만들지 않고 대기합니다. 새 계획 경로와 이미 이동한 궤적도 별도로 유지합니다.

검증

2026-09-07에 저장된 최종 PlayMode XML에서 17개 통과·실패 0을 확인했습니다. 얇은 벽 앞 정지·재개, 급회전, 경로 교체, 실제 궤적 유지 등을 포함합니다.

과거 로컬 시뮬레이터 검증 기록15m/s·dt 0.02s, 100m/s·dt 0.02s와 0.5s 조건이 포함됩니다. 이번 웹페이지 제작 중 재실행한 결과가 아니며, 실제 기체의 운용 속도나 안전성을 보장하는 수치가 아닙니다.

문제·수정 기록 이동 구간 검사 코드 테스트 조건 저장된 테스트 결과 발췌 ↗

관제 UI에 우회 비행 상태와 회피 구역이 표시된 Unity 화면 — 시뮬레이터의 장애물 대응 상태시뮬레이션에서 우회 비행 상태와 회피 구역이 표시된 장면입니다. 실제 기체 자동 회피나 YOLO 검출 성공을 입증하는 화면은 아닙니다.

04OPTIMIZATION

도시는 유지하고,
그리는 단위를 바꾸다.

건물·도로 요소별로 분리된 렌더러를 공간 타일과 재질 기준으로 묶었습니다. 원본 Scene과 충돌체는 보존하고, WebGL 빌드 Scene에 결합을 적용하는 방식입니다.

동일 Scene의
활성 MeshRenderer 수

9,972→669

같은 검증에서 삼각형 199,632개와 충돌체 9,969개는 유지됐습니다. 렌더러 개수의 변화이며 FPS나 draw call 개선율로 해석하지 않습니다.

최적화 전 도시 Scene의 검증 카메라 화면 — 타일 결합 전2026-09-07 · 동일 Scene·카메라의 저장된 원본.

최적화 후 동일 도시 Scene의 검증 카메라 화면 — 타일 결합 후2026-09-07 · 렌더링과 충돌체 보존 비교.

카메라는 구독 중일 때만 캡처

하나의 Unity 런타임에서 관제와 드론 카메라를 연결했습니다. 패널 구독 상태에 따라 캡처를 제어하고, RenderTexture·Texture2D·배열을 재사용합니다. 해상도가 바뀌거나 종료될 때는 리소스를 정리합니다.

최적화 기록 도시 렌더링 코드 카메라 캡처 코드 검증 로그 발췌 ↗

05EVIDENCE

화면이 보여 주는 범위까지.

관제 시연, 도시 데이터, 실제 촬영 영상의 분석 결과를 구분해 정리했습니다. Docker Compose는 서비스와 DB의 실행 구성을 보여 주는 근거이며, GCP 전체 주문 시나리오의 운영 검증과는 구분합니다.

클릭하면 YouTube 플레이어를 불러옵니다. 자동 재생하지 않습니다.

YouTube에서 시연 보기 서비스 실행 구성

건물 형태와 경로가 표시된 Unity 도시 화면 — 지도·도시 환경VWorld·OpenStreetMap 출처 표기가 포함된 실제 Unity 화면입니다. 건물과 경로의 시각화 범위를 보여 줍니다.

실제 드론 촬영 영상에서 주황색 착륙 패드를 탐지한 결과 — 실제 촬영 영상의 오프라인 분석녹화 영상을 YOLOv8n 착륙 패드 모델에 입력한 결과입니다. 0.93은 해당 프레임의 모델 신뢰도이며 전체 정확도가 아닙니다. 실기체 직접 제어·자율 착륙·실시간 장애물 회피와는 구분합니다.

06REFLECTION

서버 응답과 이동 상태를
함께 검증하는 일.

경로 응답이 올바르더라도 응답을 기다리는 동안의 이동은 별도 문제였습니다. 통신 계약과 함께 대기·정지·재개 상태를 살펴보는 것이 시스템 연동의 핵심임을 배웠습니다.

새 계획이 과거의 실제 이동 기록을 덮지 않도록 구분했습니다. 관제에서 보여 주는 선이 무엇을 의미하는지까지 명확해야 구현 결과를 해석할 수 있었습니다.

협업에서의 역할

6명 팀의 부팀장으로 Jira에서 담당 업무와 진행 상태를 확인하고, 연동 중 막힌 부분을 공유했습니다. 팀의 API와 상태 계약을 기준으로 시뮬레이터 변경 범위를 맞췄습니다.

다음 프로젝트 · 백엔드·공공데이터