← 목록으로

개발가이드/통합설계.md

문서 A/B 종합 기반 To-Be 위성영상 통합 시스템 모델 설계 보고서

Executive Summary

본 보고서는 문서 A(구성도 중심: AS-IS/To-Be 통합 구성 및 모듈/화면 예시 포함), 문서 B(데이터센터 적용 가능성/구축 관점 분석: 프로토콜 전환·자원·업무방식 비교 포함)를 참조하여, 두 문서의 내용을 통합(To-Be) 관점에서 재구성하고 하나의 To-Be 시스템 모델을 설계한 결과물이다. (현재 시점: 2026-03-05 KST)

핵심 결론은 다음과 같다.

문서 A는 To-Be에서 통합 촬영계획(접수/주문/진행현황/시뮬레이션), 국내위성 통합 수신·전처리(CADU→L0→L1 생성), 통합 DB/스토리지, GAIA 기반 영상관리(검색/분석/보고서/배포/GIS), 통합 모니터링/운영(VDI·관제), 내부망/인터넷망 분리 및 대외활용(다운로드/보안툴/대용량 전송)의 큰 청사진을 제시한다(출처: 문서 A p.2~p.8). 또한 문서 A는 GIS 연계를 OGC 표준(WMS/WPS/WTS) 기반 웹서비스로 기술하며(출처: 문서 A p.4), 수신·전처리 내부 모듈을 Pipe/MQ/REST 수신 + 표준 메시지 변환 + 신규 Processor 확장 구조로 제시한다(출처: 문서 A p.7).

문서 B는 데이터센터 중심화의 “현실 제약”을 구체화한다. 특히 현행 ECL 방식 수신을 데이터센터 적용을 위해 TCP 또는 FTP 기반으로 변경해야 함, DIS는 DRC 카드와의 프로토콜 확인이 필요하고 데이터센터 적용이 어려울 수 있음, 실시간 수신은 로컬(고대역) 네트워크가 필요하며 10G 연결 필요, 위성 수 증가에 따른 CADU/L0/L1 데이터 증가와 동시수신 처리 자원관리 필요, 촬영계획의 직접/간접 방법 비교 및 API 기반 통합 촬영요청 가능성을 제시한다(출처: 문서 B p.1~p.6, p.8).

따라서 To-Be 통합 설계의 “가장 중요한 의사결정 지점(P0)”은 수신 프로토콜 전환(ECL→TCP/FTP)과 DIS 기능 경계 재정의(현장 잔존 vs DC 코어화)이며(출처: 문서 B p.1~p.2, p.8), “확장성과 자동화 수준”에 따라 최소 2가지 시나리오 설계 대안이 타당하다.

• 시나리오 S1(전환 리스크 최소화형): 문서 A/B에서 공통적으로 등장하는 “FTP/TCP 기반 수신 + 중앙 오케스트레이션”을 파일/DB 중심(폴링 포함)으로 빠르게 구현하여 조기 안정화(출처: 문서 A p.5~p.7, 문서 B p.2).
• 시나리오 S2(확장·자동화 극대화형): 문서 A의 “MQ Subscriber/RESTful Receiver/신규 Processor” 구조를 적극 채택하여 이벤트 기반(메시지 큐+워크플로) 처리로 동시 수신/대량 재처리/우선순위 제어를 고도화(출처: 문서 A p.7).

본 보고서는 또한 API/문서화 표준으로 OpenAPI 3.1.1을 적용하여 HTTP API를 형식적으로 명세할 것을 권고한다. OpenAPI는 “HTTP API에 대한 표준적·언어 비종속 인터페이스”를 정의하여 사람과 도구가 API 기능을 이해·활용할 수 있게 한다. HTTP 의미/동작은 RFC 9110(HTTP Semantics)의 표준 의미체계에 맞추어 설계하고 , 보안 전송은 TLS 1.3(RFC 8446) 적용을 기본으로 권고한다. 인증·인가 모델은 OAuth 2.0(RFC 6749) 기반을 권고한다.

중요한 한계로서, 두 문서는 “그림/구축 방향/기술 검토” 중심이며 정량 SLA, 데이터 분류등급, 권한 매트릭스, 기관별 배포 규정, 외부 계약 SLA 등은 다수 명시되지 않음이다. 따라서 향후 실제 요구사항 명세/인터페이스 정의/보안 요구가 제공되면 본 To-Be 설계는 재작성(정밀화) 되어야 한다.

문서 입력과 요구사항 추출 템플릿

본 절은 문서 A/B를 직접 참조하여, 통합 설계를 위한 요구사항 추출 템플릿을 먼저 제시하고, 해당 템플릿으로 문서 A/B의 확인 가능 내용을 통합 요약(설계 입력값) 형태로 재구성한다. (문서 내 미확인/부재 항목은 ‘명시되지 않음’ 처리)

문서 유형 정리

문서 A는 AS-IS/To-Be 시스템 구성도, GAIA(영상관리) 시스템 개요, 국내위성 통합 수신·전처리 처리 흐름 및 내부 모듈 상세, 운영 화면 예시가 포함된 “아키텍처/구성도 중심 문서”로 해석된다(출처: 문서 A p.1~p.9).

문서 B는 “데이터센터 적용 분석 문서”로서 수신 프로토콜 전환 필요성(ECL→TCP/FTP), DIS/DRC 제약, 데이터 증가/자원관리/전송 고려, 촬영계획 업무 방식(직접/간접) 비교 및 통합 촬영요청 가능성을 제시한다(출처: 문서 B p.1~p.6, p.8).

통합 설계용 요구사항 추출 템플릿

문서 A/B 통합 요약

문서 A 통합 요약(핵심): To-Be는 데이터센터 내부망에 통합 촬영계획 시스템(접수/주문/진행현황/시뮬레이션), 국내위성 통합 수신·전처리(CADU→L0→L1 생성), 통합 DB/통합 스토리지, 영상관리시스템(GAIA), 통합 모니터링/운영을 배치하고, 인터넷망에서 대외활용(검색/신청/다운로드)과 보안툴·대용량 전송을 분리한다(출처: 문서 A p.2). GAIA는 2017년 최초 구축(시스템명 AURORA) 후 2023년 개편(GAIA)되었고, DBMS로 PostgreSQL/PostGIS가 사용된 것으로 기재되어 있다(출처: 문서 A p.3). GIS 연계는 OGC 기반 웹서비스(WMS/WPS/WTS)로 설명한다(출처: 문서 A p.4). 수신·전처리 시스템은 CADU 데이터(위성 원시 데이터 단위)와 L0/L1 산출물 정의 및 파일 유형을 명시하고, 처리서버 수량(22대)을 제시한다(출처: 문서 A p.5). 내부적으로는 작업지시/처리현황 수신, Pipe/MQ/REST 수신, 표준 메시지 변환, 신규 Processor 확장 구조가 제시된다(출처: 문서 A p.7).

문서 B 통합 요약(핵심): 현행 수신은 ECL 방식이며, SW를 전부 데이터센터에 적용하려면 TCP 또는 FTP 방식으로 수신 변경이 필요하다(출처: 문서 B p.1). DIS는 DRC 카드와의 프로토콜 확인이 필요하여 데이터센터 적용이 어려울 수 있다(출처: 문서 B p.1). TCP/FTP 수신은 HW/SW 역할 분리를 통해 SW 전체를 데이터센터에 적용 가능하게 하나, 대용량 영상의 실시간 수신은 로컬 네트워크 연결이 필요하고 “저장 CADU를 FTP로 가져오는 방식”은 원격지여도 가능하다(출처: 문서 B p.2). 데이터는 위성 수 증가에 따라 기하급수적으로 증가하므로 관리정책과 동시간대 수신 처리 H/W 자원관리 방안이 필요하며, 최종 생성 데이터(L1)의 서울센터 전송 방안을 고려해야 한다(출처: 문서 B p.3). 촬영계획은 직접방법(위성별 계획 수립 후 결과 전송)과 간접방법(가용 위성 촬영가능일 확인 후 주문·진행현황 확인)으로 구분되며, 업체가 제공하는 촬영 API 확산으로 통합 촬영요청이 가능하다고 본다(출처: 문서 B p.4~p.6). 또한 데이터센터 DIS가 운영센터 장비와 연결되어 TCP 실시간 수신 및 FTP 다운로드를 수행하려면(실시간은 10G) 네트워크 구축이 필요하다(출처: 문서 B p.8).

두 문서 통합 분석과 상충사항 해결안

본 절은 문서 A/B의 공통점·차이점·상충사항을 정리하고, 통합 To-Be 설계에서의 우선순위(P0/P1/P2) 및 해결 방안을 제시한다.

공통점·차이점·상충사항 정리 표

통합 설계 원칙

통합 To-Be 모델은 “EA 관점의 일관된 산출물”이 필요하므로, 엔터프라이즈 아키텍처 프레임워크로 TOGAF 적용이 합리적이다. TOGAF는 기업 아키텍처 표준으로서 핵심 개념/실무 가이드를 제공한다. 또한 설계 표현은 UML을 사용하면 아키텍처/컴포넌트/프로세스를 표준적으로 문서화할 수 있다.

통합 To-Be 시스템 설계

본 절은 “문서 A/B 통합 요약”을 근거로 통합 To-Be 아키텍처, 컴포넌트 다이어그램, DFD, 주요 인터페이스 명세, ERD 초안, 그리고 시나리오 기반 대안(S1/S2)을 제시한다.

원문 문서의 핵심 구조 시각자료

아래 이미지는 사용자가 제공한 원문 문서 중 To-Be 및 프로토콜 전환 논의를 대표하는 페이지이다.

(출처: 문서 A p.2)

(출처: 문서 B p.1)

통합 To-Be 컴포넌트 아키텍처

기본 통합안

아래 Mermaid 다이어그램은 문서 A의 To-Be 통합 블록(통합 촬영계획, 통합 수신·전처리, 통합 DB/스토리지, GAIA, 모니터링/운영, 인터넷망 대외활용)과 문서 B의 전환 제약(TCP/FTP, 10G)을 반영하여 논리 컴포넌트 구조로 재구성한 것이다(출처: 문서 A p.2, p.5~p.7 / 문서 B p.2, p.8).

flowchart TB
  subgraph Internet["인터넷망/대외"]
    ExtPortal["대외활용 포털\n(검색/신청/다운로드)"]
    ExtSec["보안툴(웹보안/캡처방지 등)\n(세부항목: 명시되지 않음)"]
    ExtAuth["대외 사용자 인증\n(2차 인증: 문서 A에 블록 존재)"]
    ExtDB["외부 DB(명시되지 않음)"]
    ExtStore["외부 스토리지(명시되지 않음)"]
  end

  subgraph DMZ["DMZ/연계구간"]
    ApiGW["API Gateway/Reverse Proxy\n(WAF/RateLimit: 권고)"]
    FileGW["대용량 전송/반출 게이트웨이\n(승인·검역·감사: 권고)"]
    Audit["감사로그 수집/보관"]
  end

  subgraph DC["데이터센터 내부망(핵심)"]
    Plan["통합 촬영계획/주문\n(접수/주문/진행현황/시뮬레이션)"]
    OrbitWx["궤도(TLE)/기상 예측 수집/저장"]
    VendorAPI["해외 위성사 주문 API 연계\n(업체별 어댑터)"]
    RxAPI["통합 DIS/PMS API\n(작업지시/현황수신)"]
    RxUI["통합 DIS/PMS UI\n(Dashboard/Viewer/설정)"]
    Orch["처리 오케스트레이터\n(큐/우선순위/재처리)"]
    ProcPool["L0/L1 Processor Pool\n(복호화, LP/SARP 등)"]
    MetaDB["메타데이터 DB\n(PostgreSQL/PostGIS 등)"]
    ObjStore["통합 스토리지\n(CADU/L0/L1/보고서)"]
    GAIA["GAIA 영상관리\n(검색/분석/보고서/배포/GIS)"]
    Mon["통합 모니터링\n(대시보드/통계/알람)"]
    Ops["운영도구/VDI/관제"]
    Dist["배포 시스템\n(군/기관/대외)"]
  end

  subgraph Ground["현장(운영센터/수신소)"]
    Modem["수신장비/모뎀\n(CADU 생성)"]
    Link["전송\nTCP(실시간) / FTP(저장 다운로드)"]
  end

  ExtPortal --> ExtSec --> ExtAuth --> ApiGW
  ApiGW --> Plan
  ApiGW --> GAIA
  Plan --> OrbitWx
  Plan --> VendorAPI
  VendorAPI --> Plan

  Modem --> Link --> RxAPI
  RxAPI --> Orch --> ProcPool --> ObjStore
  ProcPool --> RxAPI
  ObjStore --> GAIA --> Dist

  GAIA --> FileGW --> ExtStore
  Plan --> Audit
  ExtPortal --> Audit
  GAIA --> Mon
  Ops --> Mon

시나리오 기반 대안 설계

권고: “P0 제약(프로토콜 전환, DIS 경계)”이 최우선이므로, 일반적으로 S1로 조기 안정화 후 S2로 점진 고도화(단계적 전환)가 리스크-가치 균형이 좋다(출처: 문서 B p.1~p.3).

데이터 흐름도 DFD

문서 A의 CADU→L0→L1 흐름(출처: 문서 A p.5)과 문서 B의 주문/진행현황·전송 고려(출처: 문서 B p.3~p.6)를 통합한 상위 DFD는 다음과 같다.

flowchart LR
  U1["내부 사용자"]
  U2["대외 사용자"]
  P1["P1 통합 촬영계획 주문"]
  P2["P2 궤도 TLE 기상 예측 수집 저장"]
  P3["P3 수신 전처리 오케스트레이터"]
  P4["P4 L0 L1 Processor Pool"]
  P5["P5 GAIA 영상관리"]
  P6["P6 대외활용 포털"]
  D1["D1 촬영요청 주문 진행현황 DB"]
  D2["D2 궤도 기상 DB"]
  D3["D3 통합 스토리지 CADU L0 L1"]
  D4["D4 처리현황 이벤트 DB"]
  D5["D5 카탈로그 메타데이터 DB"]
  V1["위성사 업체 API"]
  G1["현장 수신장비 모뎀"]
  K1["기관 군 내부 배포"]

  U1 -->|"촬영요청 승인 조회"| P1
  U2 -->|"신청 조회"| P6
  P6 -->|"API 호출"| P1
  P1 --> D1
  P1 --> P2
  P2 --> D2
  V1 --> P1
  P1 --> V1
  G1 -->|"CADU 전송 TCP FTP"| P3
  P3 -->|"작업지시"| P4
  P4 -->|"산출물"| D3
  P4 -->|"상태 로그"| D4
  D3 --> P5
  P5 --> D5
  P5 -->|"배포"| K1
  P5 -->|"대외 반출"| P6

주요 인터페이스 명세 초안

API는 HTTP 기반 표준 의미체계(RFC 9110) 준수를 권고한다. 또한 API 문서화는 OpenAPI 3.1.1 적용을 권고한다.

데이터 모델 ERD 초안

문서 A의 데이터 단위(CADU/L0/L1) 및 처리/현황/카탈로그(출처: 문서 A p.5, p.8), 문서 B의 주문·진행현황(출처: 문서 B p.4~p.6)을 반영하여 최소 ERD를 제시한다.

erDiagram
  USER ||--o{ USER_ROLE : has
  ROLE ||--o{ USER_ROLE : assigns

  CAPTURE_REQUEST ||--o{ ORDER : generates
  ORDER ||--o{ ORDER_STATUS : transitions

  ORDER ||--o{ RECEPTION_SESSION : leads_to
  RECEPTION_SESSION ||--o{ CADU_ASSET : contains
  CADU_ASSET ||--o{ PROCESSING_JOB : triggers
  PROCESSING_JOB ||--o{ PROCESSING_EVENT : logs
  PROCESSING_JOB ||--o{ PRODUCT_L0 : outputs
  PROCESSING_JOB ||--o{ PRODUCT_L1 : outputs

  PRODUCT_L1 ||--o{ CATALOG_ITEM : indexed_as
  CATALOG_ITEM ||--o{ DOWNLOAD_REQUEST : requested_by

  PRODUCT_L1 ||--o{ REPORT : referenced_by
  REPORT ||--o{ DISTRIBUTION_PACKAGE : packaged_into

  USER {
    string user_id
    string name
    string org
    string status
  }
  ROLE {
    string role_id
    string role_name
  }
  CAPTURE_REQUEST {
    string req_id
    string aoi_geom
    datetime requested_from
    datetime requested_to
    string priority
    string requester_id
  }
  ORDER {
    string order_id
    string vendor_id
    string vendor_order_id
    datetime submitted_at
    string state
  }
  CADU_ASSET {
    string cadu_id
    string sat_name
    datetime received_at
    string storage_uri
    int size_bytes
  }
  PROCESSING_JOB {
    string job_id
    string job_type
    datetime created_at
    string state
    string processor_node
  }
  PRODUCT_L0 {
    string l0_id
    string storage_uri
    datetime generated_at
  }
  PRODUCT_L1 {
    string l1_id
    string storage_uri
    datetime generated_at
  }
  CATALOG_ITEM {
    string item_id
    string product_id
    string spatial_index
    string temporal_index
    string access_level
  }
  REPORT {
    string report_id
    string title
    datetime created_at
    string classification
  }

메타데이터 표준(옵션)

문서 A가 “카탈로그 뷰/검색”을 포함하고(출처: 문서 A p.8), 대외 활용까지 고려한다면, 위성영상 자산 메타데이터 구조를 표준화하는 것이 장기적으로 유리하다. STAC은 지리공간 자산 메타데이터의 구조와 질의를 표준화하려는 “스펙 패밀리”로 정의되며, OGC도 STAC 표준군을 공개한다. 다만, 발주/운영기관의 표준 채택 정책은 문서에 명시되지 않음이므로 옵션으로 제시한다.

비기능 요구사항

본 절은 성능/보안/가용성/확장성/운영·모니터링 요구를 정량 목표로 제시하며, 문서에서 확인되지 않는 항목은 ‘명시되지 않음’으로 표기한다. 단, 문서 B는 “실시간 수신 10G”라는 정량 조건을 명시한다(출처: 문서 B p.8).

비기능 요구사항 표

이행 계획

본 절은 문서 A/B의 현실 제약을 고려해 마일스톤, 리스크, 검증·테스트, 전환(마이그레이션)을 제시한다. 특히 P0는 수신 전환(ECL→TCP/FTP)과 동시수신 처리 자원관리, 데이터 폭증 대응이다(출처: 문서 B p.1~p.3).

단계별 마일스톤 및 타임라인

gantt
  title To-Be 통합 시스템 이행 예시 2026-03-05 KST
  dateFormat  YYYY-MM-DD
  axisFormat  %m/%d

  section 기획
  착수 요구구체화         :a1, 2026-03-10, 42d
  section PoC
  P0 PoC TCP FTP 10G DIS 경계 :a2, after a1, 28d
  section 설계
  상세설계 OpenAPI DB 운영      :a3, after a2, 42d
  section 구현
  개발 통합 S1 MVP              :a4, after a3, 112d
  section 검증/전환
  성능 보안 운영 리허설          :a5, after a4, 56d
  병행운영 절체                  :a6, after a5, 42d

주요 리스크와 대응(우선순위 포함)

검증·테스트 전략

API는 HTTP 의미체계(RFC 9110) 기반으로 상태코드/메서드 준수를 검증하고 , API 정의서는 OpenAPI 3.1.1 스키마 검증을 통해 품질을 확보한다.

테스트는 최소한 다음을 포함해야 한다.

기능(E2E): 촬영요청→주문→수신→L0/L1→등록/카탈로그→검색→보고서→배포를 E2E 시나리오로 검증(출처: 문서 A p.2, p.5 / 문서 B p.4~p.6).

성능: 실시간 수신 10G 조건에서 지속 수신 및 동시수신 상황을 부하로 재현(출처: 문서 B p.8).

보안: TLS 1.3 적용 여부(암호강도/취약 설정), OAuth2 토큰 흐름 및 권한(RBAC) 검증.

표준 적합성: WMS/WMTS/WPS 요청·응답 기본 적합성 검증.

전환(마이그레이션) 전략

권고 전환 전략은 “기술 전환(P0) → 기능 통합 → 운영 절체” 순서의 단계적 접근이다.

• 1단계(P0): 수신 프로토콜 전환(ECL→TCP/FTP) 및 DIS 경계 재정의(출처: 문서 B p.1~p.2).
• 2단계: S1(MVP)로 통합 촬영요청(간접방식)·오케스트레이션·카탈로그·GAIA 연계를 안정화(출처: 문서 A p.2, p.7 / 문서 B p.6).
• 3단계: 수신량 증가/자동화 KPI가 확인되면 S2(이벤트 기반)로 단계 전환(출처: 문서 A p.7).

데이터 마이그레이션(무엇을 옮길지): CADU/L0/L1 원본 및 메타데이터/카탈로그 항목(출처: 문서 A p.5, p.8). 다만 “보관기간/이관범위/파기정책”은 명시되지 않음이므로, 착수 단계에서 정책을 먼저 확정해야 한다(출처: 문서 B p.3).

산출물과 책임·검토 기준

본 절은 To-Be 설계를 “PDF/감리/검토가 가능한 산출물 세트”로 정리한다. 역할/조직명은 문서에 명시되어 있지 않으므로 역할 기반(Owner/Reviewer)으로 제시한다.

TOGAF는 표준/가이드/템플릿 라이브러리를 통해 EA 산출물 구성을 지원한다. UML은 시스템 표현을 위한 국제 표준 명세로, 다이어그램 기반 문서화를 정합화한다.

산출물 목록 표

실제 문서 제공 시 재작성 조건 명시

본 보고서는 제공된 두 문서가 “구성도/기술 검토” 중심이어서, 다음 정보가 다수 명시되지 않음 상태로 남아 있다.

• 데이터 분류등급/반출 등급 정책, 권한 매트릭스, 감사로그 보관기간
• 기관별 배포 규정 및 대외 다운로드 통제 기준
• 외부 위성사/업체 API의 SLA/에러코드/버전 정책
• 성능 목표(응답시간/처리시간/처리량) 정량 SLA

따라서 요구사항 명세서, 인터페이스 정의서, 보안 요구서, 운영 SLA가 추가 제공되면 본 To-Be 설계(아키텍처/DFD/ERD/NFR/이행계획)는 해당 근거에 맞추어 재작성(정밀화) 되어야 한다.

참고 표준·프레임워크

• TOGAF(The Open Group) 표준/가이드: https://www.opengroup.org/togaf
• UML 2.5.1(OMG) 표준: https://www.omg.org/spec/UML/2.5.1
• OpenAPI Specification 3.1.1: https://spec.openapis.org/oas/v3.1.1.html
• HTTP Semantics(RFC 9110): https://www.rfc-editor.org/rfc/rfc9110
• TLS 1.3(RFC 8446): https://www.rfc-editor.org/rfc/rfc8446
• OAuth 2.0(RFC 6749): https://www.rfc-editor.org/rfc/rfc6749
• OGC WMS / WMTS / WPS 표준:
• WMS: https://www.ogc.org/standards/wms
• WMTS: https://www.ogc.org/standards/wmts
• WPS: https://www.ogc.org/standards/wps
• STAC(OGC/커뮤니티) 표준:
• STAC Spec: https://stacspec.org/
• OGC STAC: https://www.ogc.org/standards/stac
• KISA ISMS-P 제도/기준(한국어):
• 제도 안내: https://isms.kisa.or.kr/main/ispims/intro/
• 인증 기준/고시 안내: https://isms.kisa.or.kr/main/ispims/notice/
• TLE 포맷(공식 문서 예: CelesTrak): https://celestrak.org/NORAD/documentation/tle-fmt.php

(원문 문서 출처: 사용자 제공 문서 A=구성도.pdf, 문서 B=분석.pdf, 페이지 표기는 본문에 기재)

×