req system constraints

시스템 요구조건

기준일: 2026-05-20 본 문서는 요구조건 식별서의 시스템 구축 요구사항을 기록한다.

Infrastructure

1. 시스템은 클라우드 기반 중앙 허브를 통해 복수의 엣지 공장을 단일 관제 체계로 통합 관리할 수 있어야 한다.
2. 데이터 수집·처리·보존·조회를 담당하는 중앙 관제 환경은 운영망과 분리된 별도 영역으로 구성되어야 한다.
3. MVP/데모 구성은 비용 최적화를 위해 NAT Gateway, RDS, Redis 등 일부 단일 구성을 허용한다. Production 또는 Phase 2 이상 운영에서는 복수 가용영역 기반으로 SPOF를 최소화하는 구성을 목표로 한다.
4. 제어망과 데이터/관제망은 네트워크 레벨에서 물리적으로 분리되어야 한다.
5. 공장 센서 데이터를 클라우드로 실시간 수집·저장·처리할 수 있는 데이터 파이프라인을 갖추어야 한다.
6. 모든 사용자 및 관리자 진입점은 암호화된 보안 통신을 통해서만 접근 가능해야 한다.

Server

1. 운영형 엣지 Spoke는 다중 노드로 구성되어 단일 노드 장애 시에도 서비스를 무중단으로 유지해야 한다.
2. 테스트베드형 Spoke는 운영형과 동일한 워크로드를 VM 환경에서 검증할 수 있어야 한다.
3. 각 공장 Spoke는 허브와의 네트워크 단절 상황에서도 로컬 기능을 유지해야 한다.
4. 중앙 관제 환경의 데이터 처리·조회·전달 컴포넌트는 본사 관제 담당자가 위험 상태를 안정적으로 확인할 수 있도록 무중단을 지향하는 형태로 운영되어야 한다.
5. 시스템은 구성 요소별 장애 발생 시 사전 정의된 복구 목표 시간(RTO) 이내에 서비스를 재개하고, 주요 저장소는 복구 시점 목표(RPO) 5분 이내를 충족할 수 있는 구조를 갖추어야 한다.

Network

1. 허브와 각 공장 Spoke 간 제어 통신은 암호화된 전용 채널(VPN)을 통해야 하며 관제 접근망과 분리되어야 한다.
2. 공장 현장 데이터는 인증된 안전한 메시지 채널을 통해 클라우드로 전송되어야 한다.
3. 수집된 원본 데이터는 자동으로 변경 불가능한 보존 저장소에 적재되어야 한다.
4. 본사 관제 화면 접근은 CloudFront/HTTPS를 기본으로 하고, WAF/IP 제한은 보안 강화 선택 구성으로 검토되어야 하며, 운영 관리 진입점과 도메인·접근 경로가 분리되어야 한다.

Container

1. 시스템은 선언적 GitOps 방식으로 모든 공장의 컨테이너 워크로드를 중앙에서 배포·동기화·롤백할 수 있어야 한다.
2. 엣지 노드는 스토리지 장애에 대비한 데이터 복제 기능을 갖추어야 한다.
3. 시스템은 노드 이상을 자동으로 감지하고 워크로드를 대체 노드로 이전(Failover)할 수 있어야 한다.
4. 테스트베드형 공장은 모의 데이터를 발행하여 전체 파이프라인을 검증할 수 있어야 한다.
5. 본사 관제 담당자용 Dashboard는 컨테이너 형태로 중앙 관제 환경의 클라우드에서 운영되어야 한다.

Common

1. 소프트웨어 빌드·배포 파이프라인은 수동 개입 없이 자동화되어야 한다.
2. 각 공장별 배포 설정과 중앙 관제 환경의 형상은 버전 관리 시스템에서 독립적으로 관리되어야 하며, 공장 추가 시 기존 구조를 변경하지 않고 확장 가능해야 한다.

시스템 감사

1. 시스템은 공장에서 수집된 모든 원본 데이터를 변경 불가능한 형태로 전량 보존하여 감사 추적이 가능해야 한다.
2. 동일한 원본 데이터가 중복으로 수신되더라도 처리 결과가 이중으로 저장되지 않아야 한다.
3. 원본 데이터는 가공 결과(처리 데이터)가 삭제된 이후에도 독립적으로 보존되어 재처리 및 일간 보고서 근거로 활용 가능해야 한다.
4. 본사 관제 담당자의 주요 조회·열람 행위는 사후 분석이 가능한 형태로 기록되어야 한다.
5. 데이터 유형별 보존은 hot-store와 S3 장기 보존을 분리한다. 단기 조회 hot-store는 HISTORY#STATE 목표 2시간(마지막 문서화된 운영값 48시간)과 GRAPH#5M 48시간 기준이며, 원본·처리 결과·일간 보고서의 장기 보존 기간은 S3 lifecycle 정책으로 관리한다.

시스템 보안

1. 본사 관제 Dashboard는 운영 클러스터의 관리 API에 직접 접근할 수 없어야 하며, 사용자별 조회 범위로 제한된 데이터 조회 전용 인터페이스만을 통해 운영되어야 한다.
2. 제어망과 관제망은 네트워크 및 권한 경계로 완전히 분리되어야 한다.
3. 자동화 파이프라인(CI)은 운영 클러스터에 직접 명령을 실행할 수 없어야 하며, 반드시 GitOps 채널을 통해서만 클러스터 상태 변경이 이루어져야 한다.
4. 인증 정보(Secret, Access Key, Token 등)는 코드 저장소 및 문서에 포함되어서는 안 된다.

보안솔루션

1. 공장 제어망과 본사 관제 접근망은 별도의 보안 채널로 분리 운영되어야 한다.
2. 본사 관제 Dashboard 접근은 Cognito 기반 사용자 인증 체계로 보호되어야 하며, WAF와 MFA는 운영 보안 정책에 따라 강화 구성으로 적용한다.
3. 각 공장 IoT 장치는 개별 인증서 기반으로 인증되어야 하며 타 공장 데이터 채널에 접근할 수 없어야 한다.
4. 인증된 본사 관제 사용자라 하더라도 자신에게 허용된 공장 외의 공장 데이터에는 접근할 수 없어야 한다.

Metric 정의

1. 시스템은 각 공장의 환경 센서(온도·습도·기압)와 AI 기반 이상 감지 결과(화재·낙하·구부러짐·이상소음)를 주기적으로 수집해야 한다.
2. 시스템은 각 공장의 인프라 상태(노드 자원, 워크로드 상태, 장치 가용성)와 데이터 수집 지연 정보를 주기적으로 수집·모니터링해야 한다.
3. 시스템은 센서 데이터, AI 결과, 인프라 상태, 파이프라인 상태를 종합하여 공장별 위험 수준을 정량적인 안전 점수로 산출해야 한다.
4. 산출된 안전 점수는 100점 만점 기준으로 100에 가까울수록 안전, 0에 가까울수록 위험을 의미해야 한다.

관련 문서

• 사업 배경과 목표
• 모니터링·서비스 확장
• Safety Score 모델
• 인증과 RBAC
• 시스템 아키텍처