루미르 SAR 데이터 플랫폼
Sentinel + LumirX 검색·저장·분석·요청 통합 — 사내 위성 데이터 풀스택 서비스 (3 레이어)
사용자 요청이 프론트 → 데이터·운영 플랫폼(NestJS) → InSAR 분석 플랫폼(FastAPI)을 좌→우로 거치고, InSAR 결과가 데이터·운영 플랫폼으로 되돌아와 사용자에게 응답되는 흐름. 데이터·운영 플랫폼(NestJS)은 InSAR 분석 플랫폼(FastAPI)에서 InSAR 데이터를 API로 받아와 저장·중계합니다. 실선(주황)=정방향 요청, 점선=응답·데이터 환류. 한 사람이 3 레이어를 풀스택으로 묶고 있습니다.
Sentinel과 LumirX 위성 데이터를 사내에서 검색·저장·분석·요청까지 한 사이클로 처리할 통합 서비스가 부재했습니다. 데이터 저장(NAS+CDSE), InSAR 분석(SNAP·ISCE2·MintPy), 사용자 진입 프론트엔드가 각각 분리되어 있어 사용자가 위치 요청만으로 분석 결과까지 받기 어려운 구조였습니다.
3 레이어 통합 서비스를 본인이 단독으로 설계·구축하고 있습니다. 데이터·운영 플랫폼(sar-data-retrieval, NestJS 모노레포 + CDSE + NAS PoC + DDD 5-layer) + InSAR 분석 플랫폼(lumir-linux-snap, 5종 도구 다중 스택 + 다중 agent 워크트리) + 프론트 레이어(sar-search-and-analyzer, Next.js + 지도 + AOI + 분석 요청 UI). 모두 AI native 100%로 진행합니다.
ISCE2 도입으로 분석 처리 속도를 확보해 날씨·계절 무관 지표 변위 데이터 서비스화가 가능한 단계에 진입했습니다. 사용자가 지도에서 위치를 요청하면 저장된 분석 데이터를 즉시 제공하거나, 없으면 신규 처리 후 제공하는 흐름을 한 사람이 풀스택으로 묶고 있다는 점이 핵심입니다.
3 레이어 모든 코드 단독 (sar-data-retrieval 5개 영역 전부, lumir-linux-snap 도구 평가·운영, sar-search-and-analyzer 프론트엔드 전부). 통합 비전 설계 본인.
각 레이어의 일부 패턴은 외부 인계입니다 — Plan/Current 환경 분리(파트장)·일부 SAR 도메인 지식(AI 사고 파트너 도움).
면접 Q&A 준비
Q.3 레이어가 어떻게 한 서비스로 통합되나요?+
Q.한 사람이 3 레이어를 동시 운영할 수 있는 이유는?+
Q.각 레이어의 본인 기여와 외부 인계 영역은?+
Q.외부 노출이 있나요?+
- ·통합 완성 시점 (분석→데이터·운영→프론트 end-to-end)
- ·사내 사용자 수
- ·지원 위성 수 (현재 Sentinel-1 + LumirX 예정)
3 레이어 각각 자세히
통합 박스가 묶은 각 레이어를 깊이 풀어 봅니다. 외부 검색·공유 시 깊은 링크가 도착하는 위치이기도 합니다.
Sentinel SAR 검색·분석 백엔드
NestJS 모노레포 + CDSE + NAS PoC + DDD 5-layer + snap 통합 (AI native)
기존에 존재하지 않는 날씨·계절 무관 지표 변위 데이터 제공 플랫폼 + Sentinel SAR 검색·다운로드·메타데이터 통합 백엔드가 필요했습니다. snap 처리 결과를 사용자 위치 검색 가능한 형태로 제공할 서비스 레이어도 필요했습니다.
NestJS 모노레포 (sentinel-retrieval + ai-processing) + CDSE API + NAS(SMB2 vs 직접 FS) PoC + SLC 도메인 모델링 + DDD 5-layer + snap 별도 레포 통합 레이어를 구축했습니다. AI native 진행으로 예측 보일러플레이트 시점만 도메인 구조를 일부 수정했습니다.
3 레이어 통합 서비스의 데이터·운영 플랫폼을 담당합니다. 사용자 위치 요청에 분석 데이터를 즉시 제공하거나 신규 처리 후 제공할 수 있는 구조의 기초가 됩니다.
Sentinel-1 InSAR 처리 파이프라인
5종 도구 다중 스택 + InSAR 결과 API(외부 플랫폼 전달) · 정부 공동 지표변위 모니터링
정부 공공기관 공동 지표변위 모니터링 사업에서 SNAP 단독 파이프라인은 처리 속도 한계로 실시간 서비스화가 불가능했습니다. ASC 단독 SBAS의 LOS 1D 한계, 단일 건물 hot-spot 식별을 위한 최소 2 yr stack 요구도 풀어야 했습니다.
5종 도구 다중 스택 (SNAP 12 + SNAPHU 2.0.3 + MintPy 1.6.2 + StaMPS PSI + ISCE2 2.6.3)을 운영했습니다. 오버엔지니어링 방지 원칙 + AI 사고 파트너로 도구 평가 + 다중 Claude Code agent 워크트리 (agent 1~4 병렬 + gpt_isolated wrapper + handoff 시스템)를 갖췄습니다. PSI 분석은 coreg를 자기완결화(-W slc)해 ifg/unwrap을 우회하도록 정리하고, 단위테스트는 통과하지만 실런에서만 드러나는 실버그 7건을 잡아 실데이터 end-to-end(velocity.h5)까지 검증했습니다. 그 위에 처리 결과를 외부 3D 플랫폼으로 전달하는 FastAPI 운영 레이어(/xyz/* 시계열·/aoi/assess·/baseline/perp)를 직접 설계했고, 무거운 처리 전에 적합성을 초 단위로 진단하는 사전점검 엔드포인트 + 재부팅 자동기동(Docker)·디스크 풀 자동 이관(systemd 타이머)까지 운영 하드닝을 맡았습니다.
ISCE2 도입으로 처리 속도를 확보해 3 레이어 통합 서비스의 InSAR 분석 플랫폼이 가능해졌습니다. 광교산 시루봉 -17.30 mm/yr (GNSS 검증) + PSI 5,143,119 PS + 5m DEM TC + 사업 보고서 v1~v4를 AI native로 작성 시간이 0에 가까웠습니다. 이후 분석 대상을 광교산에서 죽전·송도로 넓히고 새만금 AOI까지 준비했으며, 송도 매립지에서는 PSI 45,081 PS로 -17.9~+16.5 mm/yr 침하를 실운영으로 검출해 대시보드에 적재했습니다. 또한 외부 플랫폼이 요구한 'XYZ 좌표 시계열'을 전달하면서, 풀 시계열 일괄 응답(81MB·13s)을 시점 스냅샷 바이너리 + 점클릭 분리로 재설계해 1.1MB·0.56s로 줄였습니다 — DB 쿼리는 73ms라 병목이 직렬화·전송임을 측정으로 진단한 뒤 페이로드 구조를 바꾼 결과입니다.
측정 대상인 지표·지각 변위는 석사 전공(지각변동·GNSS)입니다. 다만 SAR 처리 도구·파이프라인(SNAP·MintPy·StaMPS 등)은 입사 후 AI를 사고 파트너 삼아 익힌 직군 확장 영역입니다 — 도메인 판단은 연구 배경에서, 처리 구현은 AI 가속으로.
Sentinel SAR 검색·요청 프론트엔드
지도 기반 SAR 데이터 검색·다운로드·InSAR 분석 요청
사내에서 위성 데이터를 지도에서 검색·요청하고 InSAR 분석까지 요청하는 통합 프론트 서버가 필요했습니다. 데이터·운영 플랫폼과 InSAR 분석 플랫폼을 묶어주는 사용자 진입점입니다.
Next.js (App Router) + Plan/Current 환경 분리 패턴 + (sar) 도메인(user·admin 페이지) + Next.js Route Handler BFF로 구성된 프론트엔드입니다. BFF가 데이터·운영 플랫폼(sar-data-retrieval)과 InSAR 분석 플랫폼을 호출해 검색·다운로드·분석 요청을 한 진입점에 묶습니다.
지도 기반 AOI 폴리곤 설정 + 카탈로그 검색 + InSAR 분석 요청까지 가능한 사용자 UI 기획·구현이 진행 중입니다. 데이터·운영 플랫폼·InSAR 분석 플랫폼과의 인터페이스 정합이 핵심 작업입니다.
현재는 Plan(mock) 모드로 백엔드 의존 없이 단독 동작합니다. Plan/Current 환경 분리 패턴은 파트장에게서 인계받았습니다.