루미르 SAR 데이터 플랫폼
Sentinel + LumirX 검색·저장·분석·요청 통합 — 사내 위성 데이터 풀스택 서비스 (3 레이어)
사용자 위치 요청이 프론트 → 저장 → 분석 레이어를 거쳐 결과로 돌아오는 흐름. 가운데 세로축(주황)이 정방향 요청, 오른쪽이 응답·결과 저장, 왼쪽이 외부 데이터 공급원. 한 사람이 3 레이어를 풀스택으로 묶고 있습니다.
Sentinel과 LumirX 위성 데이터를 사내에서 검색·저장·분석·요청까지 한 사이클로 처리할 통합 서비스가 부재했습니다. 데이터 저장(NAS+CDSE), InSAR 분석(SNAP·ISCE2·MintPy), 사용자 진입 프론트엔드가 각각 분리되어 있어 사용자가 위치 요청만으로 분석 결과까지 받기 어려운 구조였습니다.
3 레이어 통합 서비스를 본인이 단독으로 설계·구축하고 있습니다. **저장 레이어**(sar-data-retrieval, NestJS 모노레포 + CDSE + NAS PoC + DDD 5-layer) + **분석 레이어**(lumir-linux-snap, 5종 도구 다중 스택 + 다중 agent 워크트리) + **프론트 레이어**(sar-search-and-analyzer, Next.js + 지도 + AOI + 분석 요청 UI). 모두 AI native 100%로 진행하며, [[집비치기-him]]에서 검증한 4-Layer + CQRS + 한글 메서드명 패턴을 회사 백엔드 설계에 역전이 중입니다.
ISCE2 도입으로 분석 처리 속도를 확보해 *날씨·계절 무관 지표 변위 데이터 서비스화*가 가능한 단계에 진입했습니다. 사용자가 지도에서 위치를 요청하면 저장된 분석 데이터를 즉시 제공하거나, 없으면 신규 처리 후 제공하는 흐름을 한 사람이 풀스택으로 묶고 있다는 점이 핵심입니다.
3 레이어 모든 코드 단독 (sar-data-retrieval 5개 영역 전부, lumir-linux-snap 도구 평가·운영, sar-search-and-analyzer apps/web 전부 + 백엔드 설계 문서). 통합 비전 설계 본인.
각 레이어의 일부 패턴은 외부 인계입니다 — Plan/Current 환경 분리(파트장)·일부 SAR 도메인 지식(AI 사고 파트너 도움). sar-search-and-analyzer 백엔드(apps/api·worker·crawler)는 CLAUDE.md 설계 문서 단계이며 실제 구현은 다음 Phase입니다.
면접 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 시스템)를 갖췄습니다. 그 위에 처리 결과를 외부 3D 플랫폼으로 전달하는 FastAPI 운영 레이어(`/xyz/*` 시계열·`/aoi/assess`·`/baseline/perp`)를 직접 설계했고, 무거운 처리 전에 적합성을 초 단위로 진단하는 사전점검 엔드포인트 + 재부팅 자동기동(Docker)·디스크 풀 자동 이관(systemd 타이머)까지 운영 하드닝을 맡았습니다.
ISCE2 도입으로 처리 속도를 확보해 3 레이어 통합 서비스의 분석 처리 레이어가 가능해졌습니다. 광교산 시루봉 -17.30 mm/yr (GNSS 검증) + PSI 5,143,119 PS + 5m DEM TC + 사업 보고서 v1~v4를 AI native로 작성 시간이 0에 가까웠습니다. 또한 외부 플랫폼이 요구한 'XYZ 좌표 시계열'을 전달하면서, 풀 시계열 일괄 응답(81MB·13s)을 시점 스냅샷 바이너리 + 점클릭 분리로 재설계해 1.1MB·0.56s로 줄였습니다 — DB 쿼리는 73ms라 병목이 직렬화·전송임을 측정으로 진단한 뒤 페이로드 구조를 바꾼 결과입니다.
SAR 도메인은 본인 직군(웹 개발) 외 영역입니다. AI 사고 파트너 없이는 진입이 불가능했을 영역으로 평가합니다 (3단계 직군 확장의 표본 사례).
Sentinel SAR 검색·요청 프론트엔드 (풀스택 준비)
지도 기반 SAR 데이터 검색·다운로드·InSAR 분석 요청
사내에서 위성 데이터를 지도에서 검색·요청하고 InSAR 분석까지 요청하는 통합 프론트 서버가 필요했습니다. 저장 레이어와 분석 레이어를 묶어주는 사용자 진입점입니다.
Next.js (App Router) + Plan/Current 환경 분리 패턴 + (sar) 도메인 (user·admin 페이지) + Next.js Route Handler BFF를 갖췄습니다. 현재는 apps/web 단독 운영이며, 모노레포(pnpm + libs/*)는 향후 백엔드(apps/api·worker·crawler) 추가 대비 사전 셋업입니다. CLAUDE.md에 4-Layer Clean Architecture + CQRS + 한글 메서드명 백엔드 설계 문서를 본인이 직접 작성했고, 집비치기에서 검증한 패턴을 가져왔습니다.
지도 기반 AOI 폴리곤 설정 + 카탈로그 검색 + InSAR 분석 요청까지 가능한 사용자 UI 기획·구현이 진행 중입니다. 백엔드 개발과 기획이 동시 진행되어 혼선을 막는 인터페이스 설계가 핵심 작업입니다.
현재 코드는 apps/web 단독입니다 (apps/api·worker·crawler 미구현). 모노레포는 향후 백엔드 추가 대비 사전 셋업이며, 백엔드 4-Layer는 CLAUDE.md 설계 문서 단계입니다. UI 기획·백엔드 설계가 동시 진행 중이라 인터페이스 정합이 중요한 시점입니다.