VisualPro Tech Brief
우주 시스템은 나중에 보안을 덧댈 수 없습니다
ECSS-E-ST-80C와 IEEE P3536이 보안을 설계 요건으로 끌어올렸다
우주 시스템 보안 | 수명주기 · 설계 단계 표준 | 업계 동향 브리프
ECSS-E-ST-80CIEEE P3536IEEE P3349CCSDS SDLSNIST IR 8270
01개요 (TL;DR) — 우주 보안이 ‘설계 요건’이 된 두 개의 사건
우주 시스템 보안은 오랫동안 운용 단계의 문제로 다뤄졌습니다. 지상국 접근통제, 링크 암호화, 이상 징후 감시 — 발사 이후에 지키는 일이었습니다. 최근 2년 사이 그 전제가 바뀌었습니다. 보안이 설계·개발 단계의 요건으로 올라왔고, 그것을 규정한 표준이 두 개 생겼습니다.
ECSS-E-ST-80C 「Space engineering — Security in space systems lifecycles」는 2024년 7월 1일 발효했습니다. 유럽우주표준화협력체(ECSS)의 엔지니어링 브랜치 표준으로, 우주·지상·발사·지원 4개 세그먼트 전체를 대상으로 최초 정의부터 폐기까지 수명주기 전 구간에 보안 요구사항을 규정합니다.
IEEE P3536 「Standard for Space System Cybersecurity Design」은 2026년 3월 26일 IEEE SA 표준위원회의 승인을 받았습니다. 위성 제조·운용 주체가 설계 단계에서 사이버보안을 내장하도록 규정한 최초의 국제 기술표준으로, 지상계·우주비행체·링크·통합계층에 걸친 컴포넌트 수준의 설계 프로세스를 정의합니다.
시스템을 어떻게 설계하느냐로 공격의 범주 자체를 배제한다 — 설계된 적 없는 시스템에 감시와 패치를 덧대는 것이 아니라.
— Gregory Falco, IEEE 우주 시스템 사이버보안 워킹그룹 의장 (Cornell University)
두 표준의 성격은 다릅니다. ECSS는 유럽 우주 프로젝트에서 계약상 준거 표준으로 인용되는 체계이고, IEEE P3536은 자체 강제 수단이 없는 자발적 표준입니다. 확산은 계약 요건·보험·규제·수출통제를 통해 이뤄집니다. 이 차이를 구분하지 않으면 대응 우선순위를 잘못 잡습니다.
02왜 지금인가 — 우주 보안을 설계 단계로 끌어올린 3가지 변화
1수명주기 전체가 규정 범위에 들어왔다수명주기 규정
ECSS-E-ST-80C가 다루는 것은 운용 보안이 아니라 수명주기 보안 관리입니다. 보안 기능(정보보호관리체계 등)의 구현, 설계 정보의 보호, 그리고 보안 위험평가에 근거한 민감정보 식별과 그에 상응하는 보호 표시·조치를 요구합니다. 적용 대상은 비밀 취급 정부 사업에 국한되지 않고 비밀이 아닌 미션에도 적용됩니다.
동시에 범위 밖도 명확합니다. 정식 시스템 보안 인가(System Security Accreditation) 절차는 이 표준의 범위가 아니며, 조직의 기존 보안 정책과 충돌하는 기업 보안 제약을 부과하지도 않습니다. 프로젝트 특성에 맞춘 테일러링이 허용됩니다.
2보안이 설계 단계로 이동했다 (Secure by Design)설계 단계 이동
IEEE P3536은 사이버보안 통제를 다섯 영역에 걸쳐 정의합니다 — 지상 시스템, 우주 비행체, 둘을 잇는 링크 세그먼트, 그리고 임무를 묶는 API·데이터 링크·시험 환경을 포괄하는 통합 계층, 여기에 단말기·태블릿·기지국·항법 및 원격탐사 응용을 다루는 사용자 세그먼트가 다섯 번째 소위원회로 추가됐습니다.
주목할 점은 대상 범위입니다. 대형 국가 위성만이 아니라 모듈형 COTS 기반 시스템, 큐브샛, 소형위성 버스까지 기술 사양을 제공합니다. 상업 우주의 진입 장벽이 낮아진 만큼, 보안 설계 요건도 그 층위로 내려온 것입니다.
3우주 보안 표준 지형이 한꺼번에 두꺼워졌다표준 지형 확대
같은 IEEE 워킹그룹(S2CY)에서 IEEE P3349 「Standard for Space System Cybersecurity」가 통제(controls) 관점으로 병행 개발되고 있고, 미국에서는 NIST IR 8270(상업 위성 운용을 위한 사이버보안 입문)이 CSF 적용 방법을 제시합니다. 링크 계층은 CCSDS SDLS(우주 데이터 링크 보안 프로토콜)가, 위협 지식체계는 Aerospace Corporation의 SPARTA가 담당합니다.
이 표준들이 공통적으로 요구하는 것은 하나로 수렴합니다. 자산을 식별하고, 위협을 도출하고, 위험을 평가하고, 대응책을 요구사항으로 만들고, 그것이 구현·검증되었음을 증거로 남길 것. 자동차·국방에서 TARA라고 부르는 그 흐름입니다.
03두 표준이 실제로 요구하는 것
ECSS-E-ST-80C 요약
| 항목 | 내용 |
|---|
| 정식 명칭 | Space engineering — Security in space systems lifecycles |
| 발효 | 2024년 7월 1일 |
| 적용 세그먼트 | 우주 · 지상 · 발사 · 지원 (우주선, 발사체, 탑재체, 관련 지상 인프라) |
| 수명주기 범위 | 최초 정의부터 폐기(decommissioning)까지 전 구간 |
| 핵심 요구 | 보안 기능 구현(ISMS 등), 수명주기 보안 관리, 설계 정보 보호, 보안 위험평가 기반 민감정보 식별 및 보호 표시·조치 |
| 적용 대상 | 비밀 취급 정부 사업 및 비밀이 아닌 미션 모두 |
| 범위 밖 | 정식 시스템 보안 인가(Accreditation) 절차, 조직 보안 정책과 충돌하는 기업 보안 제약 |
| 테일러링 | 프로젝트 특성에 따라 허용 (ECSS-S-ST-00 지침) |
IEEE P3536이 나누는 다섯 영역
| 영역 | 포함 범위 | 분석에서 다뤄야 할 것 |
|---|
| 지상 시스템 | 관제 센터, 지상국, 운용 네트워크 | 접근 통제 침해, 명령 위조, 내부자 위협 |
| 우주 비행체 | 위성 버스, 탑재 소프트웨어, 온보드 버스 | 명령 수용 로직, 소프트웨어 업로드 경로, 안전 모드 |
| 링크 세그먼트 | 업링크·다운링크, 중계 | 재밍, 스푸핑, 리플레이, 암호 운용 |
| 통합 계층 | API, 데이터 링크, 시험 환경 | 인터페이스 신뢰 경계, 시험 환경에서의 자산 노출 |
| 사용자 세그먼트 | 단말기, 태블릿, 기지국, 항법·원격탐사 응용 | 최종 사용자 단말 경유 침투, 응용 데이터 무결성 |
혼동하기 쉬운 두 쌍 첫째, IEEE P3349와 P3536은 다른 표준입니다. 같은 워킹그룹(S2CY)에서 나오지만 P3349는 무엇을 갖출 것인가(통제), P3536은 어떻게 설계할 것인가(절차)를 규정합니다. 하나는 규범적, 하나는 절차적입니다.
둘째, ECSS-E-ST-80C와 ECSS-Q-ST-80C는 번호가 같아 보이지만 완전히 다른 표준입니다. E는 엔지니어링 브랜치(보안), Q는 제품보증 브랜치(소프트웨어 제품보증)입니다. 문서를 인용할 때 브랜치 문자를 반드시 확인해야 합니다.
04우주 프로그램에는 이미 분석 체계가 있다 — 이제 보안이 그 옆에 선다
우주 개발은 신뢰성·안전성 분석을 가장 오래, 가장 엄격하게 해 온 분야입니다. ECSS-Q-ST-30-02C는 FMEA/FMECA의 원칙과 요구를 규정하고, 고장모드를 심각도와 발생 확률의 결합 척도인 criticality로 분류하도록 합니다. ECSS-Q-ST-40 계열은 위험(hazard) 분석의 원칙·프로세스·요구를 정의합니다.
여기에 E-ST-80C와 P3536이 더하는 것은 새로운 분석 기법이 아니라 새로운 원인 축입니다. 지금까지의 고장 원인은 무작위 고장과 설계·제조 결함이었습니다. 이제 의도를 가진 공격자가 원인 축에 추가됩니다.
| 기존 분석 (ECSS Q 브랜치) | 새로 요구되는 보안 활동 | 공유되는 것 |
|---|
| FMEA / FMECA (Q-ST-30-02C) | 위협 시나리오의 영향 평가 | 동일한 기능·구조 분해 |
| 위험(hazard) 분석 (Q-ST-40 계열) | 보안 위험평가 | 위험 식별·등급화 절차 |
| FTA · 신뢰성 해석 | 공격 경로(attack path) 분석 | 사상 전개 논리와 최소 컷셋 |
| 요구사항 분해·추적 | 보안요구 분해·추적 | 요구 계층과 설계 반영 |
| 검증 증거 패키지 | 보안 대응책의 유효성 증거 | 심사·검토 대응 근거 |
문제는 이 두 축이 서로 다른 도구에 놓일 때 발생합니다 안전 분석은 신뢰성 팀의 FMECA 문서에, 보안 분석은 별도의 위협 분석 시트에 있으면 — 같은 위성을 두 번 모델링하게 되고, 보안 침해가 유발하는 미션 손실이 FMECA에 반영되지 않습니다. 반대로 안전 설계가 만든 중복 구조가 공격자에게 어떤 의미인지도 검토되지 않습니다.
우주 시스템에서 이 누락의 비용은 다른 도메인보다 큽니다. 접촉 기회가 제한되고, 물리적 접근이 불가능하며, 임무 수명이 10년을 넘습니다. 설계 단계에서 잡지 못한 것을 나중에 잡을 여지가 좁습니다. 두 표준이 하필 ‘설계’를 지목한 이유가 여기 있습니다.
05VisualPro는 어떻게 지원하나
하나의 구조 트리, 다섯 개의 분석구조 공유
FMEA·FTA·HARA·TARA·STPA가 동일한 시스템 구조 DB를 공유합니다. 위성 버스·탑재체·지상국·링크를 하나의 구조 트리에 올리면, IEEE P3536이 나눈 다섯 영역이 같은 트리의 하위 노드가 됩니다. 신뢰성 분석과 보안 분석이 하나의 모델을 참조합니다.
TARA — 자산에서 보안요구까지표준 대응
자산 식별 → 위협 시나리오 도출 → 위험 산정 → 대응책 → 보안요구의 흐름을 도구 안에서 수행하고 추적합니다. ECSS-E-ST-80C가 요구하는 보안 위험평가와 민감 자산 식별, IEEE P3536의 설계 프로세스가 요구하는 산출물이 이 흐름 위에 놓입니다.
분석 간 추적성 (디지털 스레드)핵심 가치
위협 ↔ 대응책 ↔ 보안요구 ↔ 검증 항목, 그리고 고장모드 ↔ 영향 ↔ 심각도 ↔ 설계 조치가 단일 DB에서 연동됩니다. 설계 변경이나 신규 위협이 들어오면 관련 분석이 함께 갱신되어, 검토 대응 시점에 살아 있는 추적성을 제시할 수 있습니다.
MCP 기반 AI 에이전트 연동AI 연동
FMEA·FTA·HARA·TARA·STPA를 지원하는 MCP(Model Context Protocol) 기능으로 Claude 등 AI 에이전트가 VisualPro와 직접 통신합니다. 후보 위협·위험원 식별부터 스코어링 초안까지 대화형으로 수행하고, 분석자는 검증과 판단에 집중합니다.
06자주 묻는 질문 (FAQ)
Q1IEEE P3536은 지켜야 하는 강제 요건인가요?
아닙니다. P3536은 자발적 표준이며 자체적인 강제 수단이 없습니다. 실효성은 발주 계약의 요건화, 보험사의 인수 조건, 규제기관의 참조, 수출통제 체계를 통해 생깁니다. 반면 ECSS-E-ST-80C는 유럽 우주 프로젝트에서 계약상 준거 표준으로 인용되는 체계이므로 성격이 다릅니다. 유럽 사업 진입을 검토한다면 ECSS 쪽이 먼저이고, P3536은 설계 프로세스의 국제 기준선으로 참고하는 것이 순서에 맞습니다.
Q2ECSS-E-ST-80C와 ECSS-Q-ST-80C는 같은 표준인가요?
아닙니다. 번호는 같아 보여도 브랜치가 다릅니다. E-ST-80C가 보안(엔지니어링 브랜치), Q-ST-80C는 소프트웨어 제품보증(제품보증 브랜치)입니다. 실무에서 자주 혼동되는 지점이므로, 문서를 인용하거나 계약 요건을 검토할 때 브랜치 문자를 반드시 확인해야 합니다.
Q3자동차 사이버보안(ISO/SAE 21434) 경험이 우주에 전이될까요?
방법론의 흐름은 그대로 전이됩니다. 자산 식별 → 위협 시나리오 → 위험 평가 → 대응책 도출 → 추적성 확보라는 골격을 TARA와 우주 보안 표준이 공유합니다. 다른 것은 세그먼트 구성(지상·링크·궤도·사용자), 접촉 기회의 제약(가시 구간과 대역폭), 임무 수명(10년 이상), 그리고 준거 표준 체계입니다. 새로 익힐 것은 분석 방법이 아니라 도메인 제약과 표준 지형입니다.
Q4VisualPro가 ECSS 서식 산출물을 그대로 내주나요?
정확히 말씀드리면, VisualPro가 표준 서식으로 산출하는 것은 AIAG-VDA FMEA, ISO 26262 HARA(ASIL), ISO/SAE 21434 TARA, FTA입니다. ECSS-Q-ST-30-02C의 FMECA는 항목 구성과 criticality 산정 방식이 달라 항목 매핑이 필요합니다. 다만 분석의 실체 — 구조 분해, 고장모드, 영향, 심각도, 대응책, 추적성 — 는 동일한 DB에서 관리되므로, 프로젝트 서식에 맞춘 출력 정의는 도입 단계에서 협의해 구성합니다.
07지금 시작하십시오 (Next Step)
우주 시스템에서 안전과 보안은 더 이상 다른 단계의 일이 아닙니다. ECSS-E-ST-80C는 수명주기 전체에, IEEE P3536은 설계 단계에 보안을 못 박았습니다. 그리고 두 표준이 요구하는 산출물은 이미 하고 계신 신뢰성·안전 분석과 같은 구조 위에서 만들어져야 비용이 통제됩니다. 자동차·국방·항공·로봇·반도체에서 검증된 VisualPro로, 위협 분석과 고장 분석을 하나의 구조 위에서 잇는 준비를 시작하십시오.
위협 분석과 고장 분석을 하나의 구조 위에서 — VisualPro와 함께하는 우주 보안 표준 대응.
참고 자료: ECSS, “ECSS-E-ST-80C — Security in space systems lifecycles” (2024-07-01) · CYSAT News, “IEEE Approves First Space Cybersecurity Design Standard” (2026-07-10) · IEEE SA, “P3349 — Standard for Space System Cybersecurity” · NIST IR 8270 · ECSS-Q-ST-30-02C FMEA/FMECA
우주 시스템 보안은 오랫동안 운용 단계의 문제로 다뤄졌습니다. 지상국 접근통제, 링크 암호화, 이상 징후 감시 — 발사 이후에 지키는 일이었습니다. 최근 2년 사이 그 전제가 바뀌었습니다. 보안이 설계·개발 단계의 요건으로 올라왔고, 그것을 규정한 표준이 두 개 생겼습니다.
ECSS-E-ST-80C 「Space engineering — Security in space systems lifecycles」는 2024년 7월 1일 발효했습니다. 유럽우주표준화협력체(ECSS)의 엔지니어링 브랜치 표준으로, 우주·지상·발사·지원 4개 세그먼트 전체를 대상으로 최초 정의부터 폐기까지 수명주기 전 구간에 보안 요구사항을 규정합니다.
IEEE P3536 「Standard for Space System Cybersecurity Design」은 2026년 3월 26일 IEEE SA 표준위원회의 승인을 받았습니다. 위성 제조·운용 주체가 설계 단계에서 사이버보안을 내장하도록 규정한 최초의 국제 기술표준으로, 지상계·우주비행체·링크·통합계층에 걸친 컴포넌트 수준의 설계 프로세스를 정의합니다.
두 표준의 성격은 다릅니다. ECSS는 유럽 우주 프로젝트에서 계약상 준거 표준으로 인용되는 체계이고, IEEE P3536은 자체 강제 수단이 없는 자발적 표준입니다. 확산은 계약 요건·보험·규제·수출통제를 통해 이뤄집니다. 이 차이를 구분하지 않으면 대응 우선순위를 잘못 잡습니다.
동시에 범위 밖도 명확합니다. 정식 시스템 보안 인가(System Security Accreditation) 절차는 이 표준의 범위가 아니며, 조직의 기존 보안 정책과 충돌하는 기업 보안 제약을 부과하지도 않습니다. 프로젝트 특성에 맞춘 테일러링이 허용됩니다.
주목할 점은 대상 범위입니다. 대형 국가 위성만이 아니라 모듈형 COTS 기반 시스템, 큐브샛, 소형위성 버스까지 기술 사양을 제공합니다. 상업 우주의 진입 장벽이 낮아진 만큼, 보안 설계 요건도 그 층위로 내려온 것입니다.
이 표준들이 공통적으로 요구하는 것은 하나로 수렴합니다. 자산을 식별하고, 위협을 도출하고, 위험을 평가하고, 대응책을 요구사항으로 만들고, 그것이 구현·검증되었음을 증거로 남길 것. 자동차·국방에서 TARA라고 부르는 그 흐름입니다.
둘째, ECSS-E-ST-80C와 ECSS-Q-ST-80C는 번호가 같아 보이지만 완전히 다른 표준입니다. E는 엔지니어링 브랜치(보안), Q는 제품보증 브랜치(소프트웨어 제품보증)입니다. 문서를 인용할 때 브랜치 문자를 반드시 확인해야 합니다.
우주 개발은 신뢰성·안전성 분석을 가장 오래, 가장 엄격하게 해 온 분야입니다. ECSS-Q-ST-30-02C는 FMEA/FMECA의 원칙과 요구를 규정하고, 고장모드를 심각도와 발생 확률의 결합 척도인 criticality로 분류하도록 합니다. ECSS-Q-ST-40 계열은 위험(hazard) 분석의 원칙·프로세스·요구를 정의합니다.
여기에 E-ST-80C와 P3536이 더하는 것은 새로운 분석 기법이 아니라 새로운 원인 축입니다. 지금까지의 고장 원인은 무작위 고장과 설계·제조 결함이었습니다. 이제 의도를 가진 공격자가 원인 축에 추가됩니다.
우주 시스템에서 이 누락의 비용은 다른 도메인보다 큽니다. 접촉 기회가 제한되고, 물리적 접근이 불가능하며, 임무 수명이 10년을 넘습니다. 설계 단계에서 잡지 못한 것을 나중에 잡을 여지가 좁습니다. 두 표준이 하필 ‘설계’를 지목한 이유가 여기 있습니다.
우주 시스템에서 안전과 보안은 더 이상 다른 단계의 일이 아닙니다. ECSS-E-ST-80C는 수명주기 전체에, IEEE P3536은 설계 단계에 보안을 못 박았습니다. 그리고 두 표준이 요구하는 산출물은 이미 하고 계신 신뢰성·안전 분석과 같은 구조 위에서 만들어져야 비용이 통제됩니다. 자동차·국방·항공·로봇·반도체에서 검증된 VisualPro로, 위협 분석과 고장 분석을 하나의 구조 위에서 잇는 준비를 시작하십시오.