19a5-기술사-핵심토픽-서비스

웹크롤링 → 스크래핑 → 개방형 API 비정형 ------------------⇒ 정형

SOAP REST

클라우드 IaaS, PaaS, SaaS

MCP

클라우드 관리 플랫폼

1. 클라우드 관리 플랫폼의 정의 및 필요성
2. 클라우드 관리 플랫폼의 필수 기능
3. 클라우드 관리 플랫폼의 선정 기준과 기대 효과
4. 클라우드 관리 플랫폼 도입시 제언

1. 클라우드 관리 플랫폼의 정의 및 필요성

정의

• 기업의 효율적인 클라우드 운영을 위해 다양한 지원 도구를 제공하는 플랫폼

개념도

• 클라우드 관리 플랫폼
  • 표준화
  • 가시성 확보
  • 비용 절약
  • 인원 절약
  • CI/CD 도구 제공
  • IaC 지원
  • 거버넌스 & 보안

필요성

• 가시성 확보: 사내의 수많은 계정과 리소스를 파악해야 함
• 비용 절약: 불필요한 리소스 발견, 추적
• 거버넌스 & 보안: 전사적 클라우드 권한 관리 필요
• 멀티클라우드 부각
• 전문인력 부족
• 규제,감사 대응: 로그, 준수 현황 관리

2. 클라우드 관리 플랫폼의 필수 기능

구성도

클라우드 관리 플랫폼

• 통합 관리
• 인프라 가시성 확보
• 비용 추적
• CI/CD 도구 제공
• IaC 기능 제공
• 기업 IdP와 연동

필수 기능

구분	필수 기능	설명
표준화	통합 관리	여러 CSP나 계정을 중앙에서 관리할 수 있음
모니터링	인프라 가시성 확보	여러 계정의 리소스들을 쉽게 파악 가능
모니터링	비용 추적	여러 계정의 비용 사용 현황 통합 조회
지원도구	CI/CD 도구 제공	지속적 통합/배포 도구 제공
지원도구	IaC 기능 제공	코드로서의 인프라 관리 가능
거버넌스&인증	기업 IdP 연동	여러 클라우드를 기업의 IdP와 연동해 사용

구분	필수 기능	설명
통합 관리	멀티·하이브리드 클라우드 통합 관리	여러 클라우드와 온프레미스 환경의 계정, 자원, 서비스 현황을 한 곳에서 관리합니다.
통합 관리	자원 가시성	서버, 스토리지, 네트워크, 컨테이너 등 자원의 현황과 사용 상태를 조회합니다.
비용 관리	비용 분석 및 배부	클라우드 사용 비용을 조직, 부서, 프로젝트, 서비스별로 분석하고 배부합니다.
비용 관리	예산 관리 및 비용 알림	예산을 설정하고 초과 가능성 또는 비정상 비용 발생 시 알림을 제공합니다.
비용 관리	비용 최적화	미사용·저사용 자원을 탐지하고 용량 조정, 예약 할인 등의 절감 방안을 제시합니다.
운영 자동화	자원 프로비저닝	표준 템플릿과 승인 절차에 따라 인프라 자원을 자동으로 생성·변경·삭제합니다.
운영 자동화	워크플로우 및 정책 자동화	승인, 배포, 점검, 종료 등의 운영 절차를 정책에 따라 자동화합니다.
보안·거버넌스	사용자·권한 관리	역할 기반 접근 제어(RBAC), SSO 등을 통해 사용자별 접근 권한을 관리합니다.
보안·거버넌스	보안 정책 및 컴플라이언스 관리	보안 설정을 점검하고 정책 위반을 탐지하며 감사 로그와 준수 보고서를 제공합니다.
모니터링	성능·상태 모니터링	자원의 성능, 가용성, 사용량, 장애 상태를 실시간 또는 주기적으로 확인합니다.
모니터링	로그·이벤트·알림 관리	운영 로그와 이벤트를 수집·분석하고, 장애나 임계치 초과 시 담당자에게 알립니다.
연동·지원	외부 시스템 연동	IaC, CI/CD, ITSM, 형상관리, 협업 도구 등 기존 운영 시스템과 연동합니다.
연동·지원	대시보드·보고서·API	운영 현황을 시각화하고 정기 보고서를 생성하며 API를 통해 다른 시스템과 데이터를 연계합니다.

3. 클라우드 관리 플랫폼의 선정 기준과 기대 효과

선정기준

구분	선정기준	설명
통합 관리	멀티·하이브리드 클라우드 지원	AWS, Azure, GCP와 온프레미스 환경을 한 화면에서 통합 관리할 수 있는지 확인합니다.
통합 관리	자원 가시성	계정, 프로젝트, 서버, 컨테이너, 네트워크 등 자원 현황과 관계를 쉽게 파악할 수 있는지 평가합니다.
비용 관리	비용 분석·배부	조직·부서·프로젝트별 비용을 분석하고 태그 기반으로 배부할 수 있는지 확인합니다.
비용 관리	예산·이상 탐지·최적화	예산 초과 알림, 비정상 비용 탐지, 미사용 자원 식별, 절감 권고 기능을 평가합니다.
운영 자동화	프로비저닝·자동화	승인된 템플릿과 정책에 따라 인프라를 자동 생성·변경·삭제할 수 있는지 확인합니다.
운영 자동화	IaC·DevOps 연동	Terraform, Kubernetes, CI/CD, ITSM 도구 등 기존 운영 도구와 연계되는지 검토합니다.
보안·거버넌스	정책·권한 관리	RBAC, SSO, 승인 절차, 정책 적용과 예외 관리 기능을 제공하는지 확인합니다.
보안·거버넌스	컴플라이언스·감사	보안 설정 점검, 규정 준수 모니터링, 감사 로그 및 보고서 생성 기능을 평가합니다.
장애·성능 관리	모니터링·알림	성능, 가용성, 로그, 이벤트를 통합 모니터링하고 적절히 알림을 제공하는지 확인합니다.
도입·운영성	사용 편의성·확장성	관리자와 사용자 모두 쉽게 쓸 수 있는지, 조직·계정·자원 증가에도 안정적으로 운영되는지 봅니다.
도입·운영성	연동성·벤더 종속성	API, 표준 연동, 데이터 추출 기능이 충분한지와 특정 관리 플랫폼에 종속될 위험을 검토합니다.
지원·비용	지원 품질·총비용	기술지원, 구축·교육, 라이선스·운영비를 포함한 전체 비용과 지원 수준을 비교합니다.

기대효과

구분	기대효과	설명
비용 효율화	클라우드 비용 절감	미사용·저사용 자원을 식별하고 적정 용량 조정, 예약 할인 적용 등을 통해 불필요한 비용을 줄입니다.
비용 효율화	비용 가시성 및 책임성 향상	부서·프로젝트·서비스별 사용 비용을 분석·배부하여 비용 발생 원인과 책임 주체를 명확히 합니다.
운영 효율화	운영 업무 자동화	자원 생성·변경·삭제, 승인, 배포, 점검 등의 반복 업무를 자동화하여 운영 시간을 단축합니다.
운영 효율화	통합 관리 체계 구축	멀티·하이브리드 클라우드 자원을 하나의 화면에서 관리하여 관리 복잡도를 낮춥니다.
보안·거버넌스	보안 통제 강화	표준 보안 정책과 접근 권한을 일관되게 적용하고, 정책 위반 사항을 빠르게 탐지·조치합니다.
보안·거버넌스	감사 및 규제 대응력 향상	감사 로그, 자산 현황, 보안 점검 결과를 체계적으로 관리하여 내부 감사와 규제 대응을 지원합니다.
안정성·품질	장애 대응 신속화	통합 모니터링과 알림을 통해 장애 징후를 조기에 발견하고 대응 시간을 줄입니다.
안정성·품질	서비스 품질 향상	자원 사용량과 성능을 지속적으로 분석·최적화하여 서비스 가용성과 사용자 경험을 높입니다.
의사결정	데이터 기반 의사결정 지원	비용, 사용량, 성능, 보안 데이터를 대시보드와 보고서로 제공하여 투자·운영 의사결정을 지원합니다.
조직 역량	운영 표준화 및 협업 강화	표준 템플릿, 승인 절차, 역할 기반 권한을 적용해 운영 방식의 일관성을 높이고 부서 간 협업을 촉진합니다.

4. 클라우드 관리 플랫폼 도입시 제언

개방형 API

1. 개방형 API의 정의 및 필요성
2. 개방형 API의 시스템 구성도와 구성요소
3. 개방형 API의 2가지 구조(SOAP, REST)별 특징 비교와 SOAP의 4가지 구성요소
4. 개방형 API 도입시 유의사항

1. 개방형 API의 정의 및 필요성

정의

• 서비스의 기능, 데이터를 서비스 외부에서도 자유롭게 사용할 수 있도록 공개된 인터페이스

개념도

• 개방형 API
  • 공개된 인터페이스
  • 서비스의 기능/데이터 제공
  • 자유로운 활용

필요성

• 수요 증가: 기술 발전에 따라 개방형 API 수요 증가

• 산업 효율성 제고: 기능과 데이터를 개방해 산업 혁신

• 외부 개발자 참여: 사내 리소스 절약

• 서비스 제공자는 API를 공개해서 수요자의 요구를 만족시킴

• 수요자가 API를 활용해 기능을 개발하면 내부 리소스 절약 가능

2. 개방형 API의 시스템 구성도와 구성요소

구성도

API 개발자 포탈 API Gateway

• Cache
• 인증/인가 API 관리자 포탈

구성요소

포털

• API 개발자 포탈: 사용 신청
• API 관리자 포탈: 신청 관리 트래픽 대응
• API Gateway: API 엔드포인트 제공, 사용량 측정
• Cache: 트래픽 피크를 대비 보안
• 인증: API 남용 방지
• 인가: API의 공개 수준 관리 가능

3. 개방형 API의 2가지 구조(SOAP, REST)별 특징 비교와 SOAP의 4가지 구성요소

항목	SOAP	REST
인터페이스	WSDL	HTTP 메서드와 URI
트랜잭션	ACID 보장 가능	트랜잭션 대응 안 함
캐시	캐시 활용 어려움	캐시 활용 쉬움
보안	WS-Security, SSL	SSL, HTTPS
필요 대역폭	비교적 큰 대역폭 필요	SOAP보다 적은 대역폭 필요
문법	XML	XML, JSON, 혹은 평문 메시지도 전송 가능
사용처	금융, 결제, 레거시 시스템	현대 웹, 모바일 서비스 등

• SOAP는 REST에 비해 엄격한 표현 방식과 풍부한 기능을 지원함
• 현대 웹 환경에서는 SOAP의 풍부함보다 REST의 단순함 선호

SOAP와 REST 비교: https://www.redhat.com/ko/topics/integration/whats-the-difference-between-soap-rest

구성요소

Envelope: 메시지 최상위 요소. Header, Body 포함 Header: 인증, 보안, 트랜잭션 등 추가 정보를 담음. 생략 가능 Body: 실제 요청 내용이나 응답을 담음, Fault를 포함할 수 있음 Fault: 에러 발생시 Body안에 포함되는 에러 정보와 메시지 표현

• SOAP는 REST에 비해 복잡하고 캐시 처리가 어려움
• 개방형 API는 불특정 다수의 개발자가 사용하게 되므로 간결한 REST 방식이 유리함

4. 개방형 API 도입시 유의사항

• 보안, 개인정보

• 법, 정책

• 인터페이스 정의

• API 문서화

• 고객센터 운영

• 외부 의존성 관리

• 버전 관리

• 외부 개발자들이 편하게 사용할 수 있도록 API 문서, 버전, 의존성을 관리해야 함

• 안전한 제공을 위해 보안, 법, 정책등을 고려하고 문의 대응용 고객센터 운영도 필요

클라우드 관리 플랫폼

필요한 이유: 다양한 CSP(멀티클라우드)

멀티클라우드 → 벤더종속성 피하기 → 확장성 단점: 보안 (다 열어줘야함), 통합운영 어려움

클라우드 구축 유형: public, private, hybrid.

클라우드 관리 플랫폼의 필수 기능, 선정 기준, 기대 효과 정리

• 두음:
• 종결어: 솔루션
• 키워드:
• 목적: 이기종 클라우드의 자원을 단일 창구로 관리하기 위한 관리 솔루션

구성도

I. 통합 자원관리체계, 클라우드 관리 플랫폼의 개요

• 개념: 멀티클라우드 자원 통합관리 솔루션

• 특징: (1) 이기종 클라우드 통합제어 (2) 프로비저닝·과금 자동화

• 이기종 클라우드 통합관리로 운영효율 향상

II. 클라우드 관리 플랫폼의 구성도 및 구성요소

가. 클라우드 관리 플랫폼의 구성도

[사용자 포털]
     ↓
[CMP 코어 엔진]
  ├─[프로비저닝 관리]
  ├─[비용 관리]
  ├─[모니터링·거버넌스]
     ↓
[Public Cloud]  [Private Cloud]  [Hybrid/Edge]

• 포털-코어엔진-멀티클라우드 계층구조

나. 클라우드 관리 플랫폼의 구성요소

구분	구성요소	설명
자원관리	프로비저닝 엔진	자원 자동 배포·회수
자원관리	오케스트레이션	워크로드 배치 자동화
운영관리	비용관리(FinOps)	사용량 기반 과금 최적화
운영관리	모니터링	성능·가용성 실시간 감시
보안거버넌스	접근제어(IAM)	사용자 권한 통합관리
보안거버넌스	컴플라이언스	정책 준수 자동 검증

• 자원·운영·보안거버넌스 3범주로 구성

III. 클라우드 관리 플랫폼 추가정보

구분	내용	비고
관련기술	FinOps 결합한 비용최적화 확대	최신 트렌드
비교	단일클라우드 콘솔 대비 통합관리 우위	멀티클라우드 대응
시사점	벤더종속 완화, 운영 표준화 기여	도입효과

• FinOps 결합, 벤더종속 완화 추세

개방형 API

• API의 목적: 표준화된 데이터/기능 연동을 하기 위함

I. 표준 인터페이스 공개형, 개방형 API의 개요

• 개념: 외부에 공개된 표준 프로그램 접속 규격

• 특징: (1) 인증기반 접근 통제 (2) 표준 프로토콜 활용

• 외부개발자에 기능·데이터 개방 제공

II. 개방형 API의 구성도 및 구성요소

가. 개방형 API의 구성도

[Client/외부개발자]
      │ Request
      ▼
[API Gateway] ── 인증/인가 ──▶ [OAuth Server]
      │
      ▼
[Backend Service] ──▶ [DB/Data]
      │
      ▼
[Response] → [Client]

• Gateway 경유 인증 후 서비스 호출

나. 개방형 API의 구성요소

구분	구성요소	설명
접근제어	API Gateway	요청 라우팅·트래픽 관리
접근제어	인증서버(OAuth)	토큰기반 권한 검증
관리체계	API 포털	개발자 등록·문서 제공
관리체계	API 키/버전관리	호출단위 식별·이력관리
연동규격	REST/JSON	경량 표준 통신방식
연동규격	SDK/문서	개발 편의성 지원

• 접근제어·관리체계·연동규격 3범주

III. 개방형 API 추가정보

구분	내용	비고
표준	OAuth2.0, OpenAPI(Swagger)	업계 표준규격
관련기술	마이크로서비스 연동 확대	MSA 트렌드
시사점	생태계 확장, 보안위협 병존	정책적 관리 필요

• 표준화·생태계 확장, 보안 병행 필요

SOAP

I. XML 기반 메시지 교환 프로토콜, SOAP의 개요

• 개념: XML기반 웹서비스 메시지 교환 표준 프로토콜

• 특징: (1) 플랫폼·언어 독립적 통신 (2) 표준화된 오류처리 체계

• XML 메시지로 이기종 시스템간 표준통신

II. SOAP의 구성도 및 구성요소

가. SOAP의 구성도

[Client]
   │ SOAP Request(XML)
   ▼
[Envelope]
 ├─[Header] : 인증/트랜잭션 정보
 └─[Body]
     ├─[Message] : 요청 데이터
     └─[Fault]   : 오류 정보
   │ HTTP/SMTP 전송
   ▼
[Server/Web Service]

• Envelope 내 Header·Body 계층구조

나. SOAP의 구성요소

구분	구성요소	설명
메시지구조	Envelope	메시지 최상위 루트 요소
메시지구조	Header	인증·보안 등 부가정보
메시지구조	Body	실제 요청/응답 데이터
메시지구조	Fault	오류코드 및 메시지 전달
프로토콜	WSDL	서비스 인터페이스 정의
프로토콜	UDDI	서비스 등록·검색 저장소

• 메시지·프로토콜·처리 3범주로 구성

III. SOAP 추가정보

구분	내용	비고
비교	REST 대비 무겁고 엄격한 표준	보안·트랜잭션 강점
관련기술	WS-Security로 전자서명 지원	금융권 주로 채택
시사점	레거시 연동·엄격보안 요구시 적합	MSA에선 REST 선호

• REST 대비 무겁지만 보안·표준성 우수

REST

I. 자원기반 아키텍처 스타일, REST의 개요

• 개념: HTTP 기반 자원 중심 API 설계 스타일

• 특징: (1) URI로 자원 식별·표현 (2) Stateless 요청 처리

• 자원을 URI·HTTP메서드로 조작하는 아키텍처

II. REST의 구성도 및 구성요소

가. REST의 구성도

[Client] --HTTP Request(Method+URI)--> [Server]
   ^                                       |
   |<---- Response(Resource+상태코드) ------|
   
자원(Resource) --URI--> 식별
행위(Method: GET/POST/PUT/DELETE) --> 처리
표현(JSON/XML) --> 전송

• 클라이언트-서버간 무상태 자원 요청·응답

나. REST의 구성요소

구분	구성요소	설명
자원	URI	자원 고유 식별자
자원	Resource	처리 대상 데이터
행위	HTTP Method	CRUD 매핑 동작
행위	Stateless	세션정보 미유지
표현	Representation	JSON·XML 표현형식
표현	HATEOAS	응답 내 링크 포함

• 자원·행위·표현 3요소로 구성

III. REST 추가정보

구분	내용	비고
성숙도	Richardson 성숙도 모델 4단계	HATEOAS가 최상위
비교	SOAP 대비 경량·단순 프로토콜	XML 종속 없음
시사점	MSA 통신표준으로 활용 확대	API 설계 핵심원칙

• 성숙도모델 기반 단계적 발전

HATEOAS는 “Hypermedia As The Engine Of Application State”의 약자로, REST 아키텍처의 성숙도를 나타내는 핵심 제약조건 중 하나예요.

핵심 개념

API 응답 안에 현재 자원과 관련된 다음 행동(링크)들을 함께 담아 보내는 방식입니다. 클라이언트는 서버가 미리 문서화한 URI를 하드코딩해서 호출하는 게 아니라, 응답에 포함된 링크를 따라가며 애플리케이션 상태를 전이시킵니다.

예시

주문 조회 API를 호출하면 이런 응답이 옵니다:

{
  "orderId": 123,
  "status": "PLACED",
  "amount": 50000,
  "_links": {
    "self": { "href": "/orders/123" },
    "cancel": { "href": "/orders/123/cancel" },
    "payment": { "href": "/orders/123/payment" }
  }
}

주문 상태가 “PLACED”일 때는 “cancel”과 “payment” 링크가 오지만, 상태가 “SHIPPED”로 바뀌면 “cancel” 링크는 응답에서 빠지는 식입니다. 클라이언트는 이 링크 유무만 보고 “지금 취소가 가능한지”를 판단할 수 있어요.

왜 중요한가 (REST 성숙도 모델 관점)

Richardson 성숙도 모델에서 REST는 4단계로 발전합니다:

• Level 0: 단일 URI, HTTP를 터널처럼 사용 (RPC 스타일)
• Level 1: 자원별로 URI 분리
• Level 2: HTTP 메서드(GET/POST/PUT/DELETE)를 의미에 맞게 사용
• Level 3: HATEOAS 적용 — 응답에 하이퍼미디어 링크 포함

Level 3까지 가야 “진짜 REST”라고 보는 시각이 많고, 실제로 완전한 HATEOAS를 구현하는 API는 드뭅니다(대부분 Level 2에서 멈춤). 클라이언트-서버 결합도를 낮추고 API 진화를 유연하게 만든다는 장점이 있지만, 구현 복잡도가 높아지고 클라이언트도 링크 기반 탐색 로직을 짜야 한다는 부담이 있습니다.

기술사 시험 답안에서는 “REST 성숙도 최상위 단계, 자기서술적 링크로 클라이언트-서버 결합도 완화” 정도로 요약하면 좋습니다.

IPS(Indoor Positioning System)

I. 실내측위체계, IPS의 개요

• 개념: 실내 공간서 사물 위치 추정 기술

• 특징: (1) GPS 음영지역 위치 파악 (2) 다양한 센서·신호 융합

• GPS 미작동 실내서 정밀 위치측정

II. IPS의 구성도 및 구성요소

가. IPS의 구성도

[신호원(Beacon/AP/센서)]
        ↓ 신호수신
[단말(스마트폰/태그)]
        ↓ 신호세기·거리 측정
[측위엔진(알고리즘 처리)]
        ↓ 위치좌표 산출
[응용서비스(내비/자산추적)]

• 신호수집→연산→서비스 순차 처리

나. IPS의 구성요소

구분	구성요소	설명
인프라	BLE 비콘	저전력 근거리 신호 송출
인프라	Wi-Fi AP	기존망 활용 신호 측정
측위기술	삼변측량	신호세기 기반 거리계산
측위기술	핑거프린팅	사전 신호맵 매칭
단말/SW	측위엔진	좌표 연산 알고리즘
단말/SW	지도매칭	건물 도면과 위치 정합

• 인프라·측위기술·단말SW 3범주 구성

III. IPS 추가정보

구분	내용	비고
관련기술	UWB로 정밀도 cm급 향상	최신 트렌드
비교	GPS 대비 실내 정확도 우수	옥외는 GPS 유리
시사점	물류·의료·쇼핑몰 자산추적 활용	실무 적용 확대

• UWB 고도화, 산업현장 적용 증가

BLE(Bluetooth Low Energy)

• 저전력 블루투스 통신 규격으로, 기존 블루투스보다 전력 소모를 크게 줄인 근거리 무선통신 기술입니다.
• 실내측위에서는 비콘(Beacon)이 주기적으로 신호를 송출하고, 단말이 그 신호세기(RSSI)를 측정해 거리를 추정하는 방식으로 활용됩니다.
• 장점: 저전력·저비용으로 배터리 수명이 길고 구축이 쉬움. 단점: 신호세기 기반이라 다중경로·장애물에 취약해 오차가 큼(보통 수 m 단위).

UWB(Ultra-Wideband)

• 매우 넓은 주파수 대역(GHz 단위)에 걸쳐 짧은 펄스 신호를 사용하는 무선통신 기술입니다.
• 신호의 도달 시간(ToF, Time of Flight)을 정밀하게 측정해 거리를 계산하기 때문에 신호세기 기반 방식보다 훨씬 정확합니다.
• 장점: cm 단위의 높은 정밀도, 다중경로 간섭에 강함. 단점: 전용 앵커·태그 장비 필요로 구축 비용이 상대적으로 높고 전력 소모도 BLE보다 큼.

한줄 비교: BLE는 “저비용·저전력이지만 정확도는 m급”, UWB는 “정확도는 cm급이지만 구축비용이 높음”이라고 보면 됩니다. 그래서 물류창고처럼 대략적 위치면 충분한 곳은 BLE, 정밀 추적이 필요한 공장 자동화나 스마트 병원 등에는 UWB가 주로 쓰입니다.

Wi-Fi AP(Access Point)

• 유선 네트워크와 무선 단말을 연결해주는 무선 접속 장치입니다. 흔히 회사나 건물에 설치된 공유기·무선랜 장비를 떠올리면 됩니다.
• 실내측위에서는 새로운 장비를 추가로 설치하지 않고, 건물에 이미 깔려 있는 기존 Wi-Fi AP를 신호원으로 활용한다는 점이 특징입니다.

측위 방식

• 단말(스마트폰 등)이 주변 여러 AP에서 오는 신호세기(RSSI)를 수집
• 이를 미리 구축해둔 “위치별 신호 지도(라디오맵)“와 비교해 현재 위치를 추정하는 핑거프린팅(Fingerprinting) 방식이 대표적
• 또는 여러 AP와의 거리를 계산해 위치를 구하는 삼변측량 방식도 사용 가능

장단점

• 장점: 기존 인프라 재활용 가능 → 별도 비콘 설치 비용 절감, 이미 많은 건물에 AP가 조밀하게 깔려 있음
• 단점: 정확도가 낮은 편(보통 3~5m 오차), 사전에 라디오맵을 구축·갱신하는 작업이 필요해 유지보수 부담이 있음

BLE/UWB와 비교하면: Wi-Fi AP는 “기존 인프라 재사용형”, BLE는 “저비용 전용 비콘형”, UWB는 “고정밀 전용 장비형”으로 구분할 수 있습니다.

Q. 핑거프린팅은 BLE, UWB에서는 안 쓰는거지?

아니요, 그렇지 않습니다. 핑거프린팅은 신호세기(RSSI)를 활용하는 방식이라면 BLE에서도 흔히 사용됩니다. 다만 UWB는 원리상 잘 쓰이지 않는 게 맞습니다. 기술별로 정리하면 이렇습니다.

BLE — 핑거프린팅 사용 O

• BLE도 Wi-Fi처럼 RSSI(신호세기) 기반이기 때문에, 공간을 격자로 나눠 각 지점의 신호세기 패턴을 미리 수집해두고 매칭하는 핑거프린팅 방식이 널리 쓰입니다.
• 다만 삼변측량(거리 기반) 방식도 함께 쓰이며, 실제로는 두 방식을 혼합하는 경우가 많습니다.

UWB — 핑거프린팅 거의 사용 X

• UWB는 애초에 신호의 도달시간(ToF)을 정밀 측정해서 거리를 직접 계산하는 방식이라, RSSI 기반의 통계적 매칭인 핑거프린팅을 쓸 이유가 없습니다.
• 즉 UWB는 “물리적 거리 측정”이 핵심이라 삼변측량(Trilateration)이나 TDoA(도달시간차) 방식이 주로 쓰입니다.

정리하면

기술	주요 측위 방식
Wi-Fi AP	핑거프린팅 (RSSI 기반)
BLE	핑거프린팅 + 삼변측량 (RSSI 기반)
UWB	삼변측량 / TDoA (ToF 기반, 핑거프린팅 X)

정확도가 필요 없고 인프라 재활용이 중요한 Wi-Fi·BLE는 “패턴 매칭형(핑거프린팅)“이, 정밀도가 핵심인 UWB는 “물리량 직접 계산형”이 어울린다고 이해하시면 됩니다.

IPS를 활용하는 서비스

구분	서비스	설명
유통·물류	공항/백화점 내비	매장·게이트 길안내
물류	자산·재고추적	창고내 물품위치 실시간관리
산업	스마트팩토리	작업자·설비 위치관리
의료	병원 환자·장비추적	응급대응·동선최적화
마케팅	근접마케팅(O2O)	매장내 쿠폰·알림 푸시
안전	재난대피 유도	실내 대피경로 안내

• 유통·산업·의료·안전 등 全산업 확산

멀티클라우드

I. 복수 CSP 혼합운영체계, 멀티클라우드의 개요

• 개념: 2개 이상 CSP 조합 IT자원 운영전략

• 특징: (1) 벤더종속 탈피 (2) 워크로드별 최적CSP 선택

• 복수 CSP 조합으로 유연성·안정성 확보

II. 멀티클라우드의 구성도 및 구성요소

가. 멀티클라우드의 구성도

        [통합관리계층: CMP/오케스트레이션]
        /          |            \
   [AWS]         [Azure]        [GCP]
   IaaS/PaaS     IaaS/PaaS      IaaS/PaaS
        \          |            /
        [공통 네트워크/보안/데이터 연동]

• CMP 통해 이기종 CSP 통합관리

나. 멀티클라우드의 구성요소

구분	구성요소	설명
관리계층	CMP	복수 클라우드 통합관리
관리계층	오케스트레이션	자원배치 자동조율
연동계층	API 게이트웨이	CSP간 표준화 연동
연동계층	데이터 동기화	CSP간 데이터 일관성
보안계층	통합IAM	계정·권한 통합관리
보안계층	암호화·키관리	데이터 보호 일원화

• 관리·연동·보안 3계층 구조

III. 멀티클라우드 추가정보

구분	내용	비고
비교	하이브리드클라우드 대비 CSP간 조합 중심	온프레미스 결합無
관련기술	쿠버네티스 기반 이식성 확보 확대	컨테이너 표준화
시사점	장애분산·비용최적화, 관리복잡도 증가	거버넌스 필요

• CSP조합 유연성, 관리복잡도는 과제

멀티클라우드 (필요성, 시스템 요구사항, 주요 기술)

I. 다중 클라우드 조합운영, 멀티클라우드의 개요

• 개념: 복수 CSP 조합해 IT자원 운영 전략

• 특징: (1) 벤더종속 탈피 (2) 서비스별 최적조합

• 가용성·비용·보안 목적 채택 확산

II. 멀티클라우드의 구성도 및 구성요소

가. 멀티클라우드의 구성도

        [사용자/애플리케이션]
                │
        [통합관리계층(CMP)]
        ┌───────┼───────┐
     [AWS]    [Azure]   [GCP]
        └───────┼───────┘
           [온프레미스/엣지]

• CMP 통해 이기종 클라우드 통합제어

나. 멀티클라우드의 구성요소 (시스템 요구사항)

구분	구성요소	설명
가용성	이중화 아키텍처	장애시 자동 페일오버
가용성	SLA 관리체계	CSP별 서비스수준 관리
상호운용성	API 표준화	CSP간 인터페이스 통일
상호운용성	데이터 이식성	워크로드 자유이동 보장
보안	통합 IAM	계정·권한 일원화 관리
보안	데이터 암호화	전송·저장 구간 보호

• 가용성·상호운용성·보안 3대 요구사항

III. 멀티클라우드 추가정보 (주요 기술)

구분	내용	비고
관리기술	CMP로 이기종 클라우드 통합제어	CloudHealth 등
이식기술	컨테이너·K8s기반 워크로드 이식	Anthos, ARO
자동화기술	IaC로 코드기반 인프라 프로비저닝	Terraform 등

• 컨테이너·IaC 기반 CSP중립 기술 확산

공공부문의 민간 클라우드 활용

I. 공공기관 IT자원 아웃소싱, 공공부문의 민간 클라우드 활용의 개요

• 개념: 공공기관이 민간 클라우드서비스 도입·이용

• 특징: (1) 예산절감형 탄력적 자원활용 (2) 보안인증 기반 안전성 확보

• 민간자원 활용해 효율성·보안성 확보

II. 공공부문의 민간 클라우드 활용의 구성도 및 구성요소

가. 공공부문의 민간 클라우드 활용의 구성도 (서비스 활용 절차)

[수요조사]→[사업계획 수립]→[사업자 선정]
   →[이용신청]→[계약체결]→[서비스 이용]
   →[모니터링·운영]→[계약종료·전환]

• 수요조사부터 운영까지 단계적 절차

나. 공공부문의 민간 클라우드 활용의 구성요소 (클라우드 기본설계과정)

구분	구성요소	설명
요구분석	현행시스템 분석	기존 IT자원 현황파악
요구분석	요구사항 정의	기능·비기능 요구도출
설계	아키텍처 설계	서비스유형·구조 결정
설계	보안설계	접근통제·암호화 설계
구축	환경구성	클라우드 자원 프로비저닝
구축	검증·이관	테스트 후 시스템전환

• 요구분석-설계-구축 3단계로 진행

III. 공공부문의 민간 클라우드 활용 추가정보 (서비스유형 및 평가기준)

구분	내용	비고
IaaS	서버·네트워크 자원제공	인프라 유연성 평가
PaaS	개발·실행환경 제공	개발생산성 평가
SaaS	완성형 SW 제공	기능적합성 평가

• 자원-플랫폼-SW 계층별 평가기준 상이

CSAP, 클라우드 서비스 보안 인증

CSAP는 2026년 하반기에 없어지기로 예정되어 있다고 함.. 문제 안나올듯.

I. 클라우드서비스 보안인증제, CSAP의 개요

• 개념: 공공 클라우드서비스 보안기준 적합성 인증제도

• 특징: (1) 국가·공공기관 공급 필수관문 (2) 상/중/하 등급제 운영

• KISA 심사, 공공 클라우드 진입 안전성 검증

II. CSAP의 구성도 및 구성요소

가. CSAP의 구성도

[정책기관: 과기정통부]
      ↓ 제도 총괄
[인증기관: KISA] ← [평가기관: KAIT 등]
      ↓ 인증 심사/발급
[인증위원회] → 인증 여부 심의
      ↓
[신청인(CSP)] → 준비→평가→인증 3단계
      ↓
[이용자: 국가·공공기관] → 인증된 서비스 이용

• 정책·인증·평가·이용 4주체 협업구조

나. CSAP의 구성요소

구분	구성요소	설명
인증유형	IaaS	인프라 서비스 인증
인증유형	SaaS/DaaS	SW·데스크톱 서비스 인증
등급체계	상등급	최고 민감도 시스템용
등급체계	중/하등급	일반·경량 시스템용
운영주체	인증기관(KISA)	인증서 발급·관리
운영주체	평가기관(KAIT 등)	보안기준 심사수행

• 인증유형·등급·운영주체 3범주 구성

III. CSAP 추가정보

구분	내용	비고
최근동향	국정원 검증체계와 단일화 추진	2026.4 개편안
최근동향	공통요건 ISMS로 이관 검토	2027.7 시행예정
시사점	무역장벽 논란·글로벌CSP 진입완화	국내CSP 경쟁심화

• 형식적 인증→실질적 검증 패러다임 전환

공공부문 민간 클라우드 활용 (CSAP 폐지 관련 반영)

Why(배경) → What(정책 변화) → How(추진방안/전망) 흐름으로 N2SF·CSAP개편·공공클라우드전환을 하나의 스토리로 연결

---

전체 구조 조감도

공공부문 민간 클라우드 활용
 │
 ├─ [층위 1] 목표: 디지털플랫폼정부, 2030년 공공시스템 100% 클라우드 전환
 │
 ├─ [층위 2] 추진 축 3가지 (서로 맞물려 최근 개편됨)
 │    ├─ ① 망분리 체계        : 물리적 망분리 → N2SF(제로트러스트 기반)
 │    ├─ ② 보안인증/검증 체계 : CSAP 상/중/하 등급제 → 국정원 단일 검증체계
 │    └─ ③ 클라우드 이용 절차 : 도입가능목록 기반 관리
 │
 └─ [층위 3] 공통 배경(Why) : 이중검증 부담, 화재 등 인프라 리스크,
                              AI행정 수요 증가, 글로벌 정합성(통상) 요구

이 세 축은 “공공기관이 얼마나 쉽고 안전하게 민간 클라우드를 쓰게 할 것인가” 라는 하나의 정책 목표 아래 동시에 진행되는 개편이라는 점이 핵심 포인트입니다.

---

1. Why — 개편 배경 (3줄 요약 + 상세)

한 문장 요약: “인증의 늪(이중검증) + 인프라 리스크(화재) + 정책목표(AI행정, 2030 완전전환) + 대외정합성(통상마찰) 이 겹치며 기존 체계의 구조적 한계가 노출됨”

배경 축	내용
절차적 비효율	CSAP(과기정통부) 취득 후 국정원 보안검증까지 이중으로 거쳐야 하는 구조 → 중소 SaaS 기업의 시간·비용 부담
인프라 리스크	국가정보자원관리원 화재 등 → 자체 구축 중심 체계의 이중화·재해복구 한계 노출 → 민간 클라우드의 가용성·복원력 재조명
정책 목표 압박	2030년 공공시스템 100% 클라우드 전환 목표 대비, 인증 병목이 정책 이행 걸림돌로 지적
보안 패러다임 변화	원격/재택, AI 행정 확산으로 “물리적 망분리” 전제 자체가 업무 실효성과 충돌 → 제로트러스트로 전환 압력
대외 정합성	물리적 망분리·국내 특유 인증체계가 해외 우수 SaaS·빅테크 진입을 저해한다는 통상 마찰 소지 지적

---

2. What — 정책 변화 3축 (Before/After 비교)

축 ① 망분리 체계 — 국가 사이버보안 기본지침 개정 (2026.5.1 시행)

구분	Before	After (N2SF)
명칭	국가 정보보안 기본지침	국가 사이버보안 기본지침
원칙	제40조, 일률적 물리적 내부망·인터넷망 분리	정보 등급(기밀C·민감S·공개O) + 도메인 구분 기반 유연 통제
성격	절대적 차단(이분법)	보안통제 충족을 조건으로 한 유연 운용(제로트러스트 지향)
세부기준	-	「국가 망 보안체계(N2SF) 보안가이드라인 1.0」
적용대상 확대	각급기관 중심	정보화사업 수주업체, 클라우드 서비스 제공자 등도 국정원 협조요청 의무 부담
클라우드 연계	-	「클라우드컴퓨팅 도입 가능 목록」 제도 신설(제24조의3·4), 목록 등재 서비스만 이용 가능

축 ② 보안인증/검증 체계 — CSAP 개편 (2026.4.20 발표, 2027.7 시행 예정)

구분	Before	After
소관	과기정통부(CSAP, 민간·공공 통합) + 국정원(보안검증, 공공) 이원 운영, 순차 이중 절차	민간: 과기정통부(ISMS 자율인증) / 공공: 국정원(클라우드 보안검증) 단일 트랙
등급	상/중/하 3등급제 (2023년 도입)	등급제 폐지
민간 공통요건	CSAP 별표1~3	ISMS로 이관, 자율 규정화
공공요건	CSAP 별표4	국정원 ‘클라우드 보안검증’으로 통합·재설계
중복 해소	민간인증 취득 후 공공검증 별도 진행	민간인증(ISMS) 인정 항목은 공공검증 시 중복 면제
거버넌스	-	‘민관 검증심의위원회’ 신설(공정성·타당성 심의)
경과조치	-	유예기간 중 취득한 CSAP는 유효기간 5년 그대로 인정

축 ③ 이용 절차/관리 체계

• 「클라우드컴퓨팅 도입 가능 목록」제도로 이용기관은 사전 검증된 목록 내에서만 서비스 선택 → 사후관리형에서 사전목록관리형으로 전환
• 조달청 디지털서비스몰 등 조달 체계와 연계 지속

---

3. How — 추진 로드맵 & 향후 전망

2023.01 ── 국가 클라우드 컴퓨팅 보안 가이드라인 제정
2023    ── CSAP 상/중/하 등급제 도입
2026.04 ── CSAP 개편안(국정원 단일검증화) 공동 발표 (과기정통부·국정원)
2026.05 ── 국가 사이버보안 기본지침 개정·시행 (N2SF 도입) ★이미 시행됨
2026 상반기 ─ 국가 클라우드컴퓨팅 보안가이드라인 등 하위지침 개정 예고 (진행중)
2026~2027 ── 1년 유예기간 (기존 CSAP 유효기간 5년 인정)
2027.07 ── 국정원 클라우드 보안검증 단일체계 본격 시행 (예정)
2030    ── 공공시스템 100% 클라우드 전환 목표

향후 쟁점(전망 서술 시 활용)

• 국내 CSP의 선투자 형평성 vs 해외 빅테크(AWS·MS 등)의 무임승차 논란
• 중소 SaaS 기업: ISMS가 사실상 의무화되며 부담이 완전히 사라지진 않음(생존 요건화)
• 통상 이슈와 맞물린 외산 클라우드 문호 확대 속도 조절 필요
• ‘검증 완화’가 아니라 ‘검증 효율화’라는 정부 해명과, 업계의 ‘사실상 규제완화’ 해석 간 온도차

---

4. 답안 작성 템플릿 (서술형 뼈대)

1. 개념정의: 공공부문 민간 클라우드 활용의 정의, 법적 근거(클라우드컴퓨팅법·전자정부법)
2. 추진배경(Why): 이중검증 비효율 + 인프라 리스크 + 정책목표(2030) + 대외정합성
3. 최근 정책변화(What): 3축(망분리 N2SF / 인증검증 CSAP개편 / 이용절차 도입목록) 표로 정리
4. 기대효과: 절차 간소화, 비용절감, 보안 실효성 강화, 글로벌 정합성
5. 이슈 및 과제: 형평성, 통상, 중소기업 부담, 과도기 리스크(세부기준 미확정)
6. 향후 전망/제언: 로드맵 기반 단계별 대응방안 제시

---

주의: 2026.4월 발표된 국정원 클라우드 보안검증의 세부 평가항목·ISMS 클라우드 모듈 세부기준은 2026년 내 하위지침 개정을 통해 확정 예정이며 아직 공식 확정되지 않았습니다. 시험 직전 국정원·과기정통부 발표자료로 최신 확정 여부를 재확인하시길 권합니다.

소프트웨어 기능 안전

I. 안전무결성 확보체계, 소프트웨어 기능 안전의 개요

• 개념: SW결함으로 인한 위험 예방·완화 체계

• 특징: (1) 위험기반 안전무결성 등급 적용 (2) 생명주기 전반 안전활동 수행

• 결함 위험 사전예방 위한 체계적 접근

II. 소프트웨어 기능 안전의 구성도 및 구성요소

가. 소프트웨어 기능 안전의 구성도

[위험원 분석]→[안전요구사항 도출]→[SIL 결정]
      ↓
[안전 설계·구현]→[검증·확인(V&V)]→[안전성 평가]
      ↓
        (변경관리·피드백 루프)

• 위험분석부터 평가까지 순차적 안전확보

나. 소프트웨어 기능 안전의 구성요소

구분	구성요소	설명
분석단계	위험원 분석(HARA)	잠재 위험요소 식별
분석단계	SIL 결정	안전무결성 등급 산정
개발단계	안전요구사항관리	추적성 기반 요구 관리
개발단계	결함허용설계	이중화·페일세이프 적용
검증단계	검증·확인(V&V)	설계 대비 구현 검증
검증단계	안전성 평가	인증 위한 종합 평가

• 분석·개발·검증 3단계로 구성

III. 소프트웨어 기능 안전 추가정보

구분	내용	비고
표준	IEC 61508 기반 산업표준	자동차는 ISO 26262
관련기술	AI기반 결함예측 적용 확대	최신 트렌드
시사점	인증비용 증가, 안전성 신뢰도 향상	도입 트레이드오프

• IEC 61508 중심 표준화·AI 접목 추세

HARA (Hazard Analysis and Risk Assessment) 시스템/소프트웨어가 유발할 수 있는 위험원(Hazard)을 식별하고, 그 위험의 심각도·발생빈도·회피가능성을 분석해 위험 수준을 평가하는 절차예요. 기능안전 개발의 가장 앞단에서 수행되며, 여기서 나온 결과가 다음 단계인 SIL 산정의 입력값이 됩니다.

SIL (Safety Integrity Level, 안전무결성수준) HARA 결과를 바탕으로 “이 시스템/기능은 얼마나 엄격한 안전조치가 필요한가”를 등급화한 것입니다. 보통 4단계(예: IEC 61508 기준 SIL 1~4)로 나뉘며, 숫자가 높을수록 요구되는 안전무결성(결함허용, 검증 엄격도, 이중화 수준 등)이 높아집니다.

• ISO 26262(자동차 분야)에서는 이와 유사한 개념으로 **ASIL(A~D)**을 사용합니다.
• 관계: HARA → 위험도 도출 → SIL/ASIL 등급 결정 → 등급에 맞는 안전설계·검증 활동 수행

정보관리기술사 답안에서는 “HARA로 위험을 식별하고, 그 결과에 따라 SIL을 산정하여 요구되는 안전조치 수준을 결정한다”는 흐름으로 연결지어 서술하면 좋습니다.

IEC 61508

SIL, 등급(1~4),

이거어케외우지

I. 기능안전 국제표준, IEC 61508의 개요

• 개념: 전기전자 안전시스템 기능안전 표준

• 특징: (1) SIL 등급별 안전요구 정의 (2) 전주기 안전생명주기 적용

• 위험기반 안전등급 통한 기능안전 확보

II. IEC 61508의 구성도 및 구성요소

가. IEC 61508의 구성도

[개념단계]→[범위정의]→[위험분석]
   → [안전요구사항 명세]
   → [설계/구현(HW·SW)]
   → [설치/시운전]
   → [운용/보전]→[폐기]
        ↑________________|
        (전주기 피드백 및 검증)

• 개념~폐기까지 안전생명주기 순환구조

나. IEC 61508의 구성요소

구분	구성요소	설명
생명주기	위험분석	위험원 식별·평가
생명주기	안전요구사항명세	안전기능 요구 정의
SIL체계	SIL 1~4 등급	위험도별 안전수준
SIL체계	PFD/PFH 지표	고장확률 정량기준
관리체계	기능안전관리	조직·절차 전주기 관리
관리체계	검증/확인(V&V)	설계 적합성 검증

• 생명주기·SIL체계·관리체계 3범주 구성

III. IEC 61508 추가정보

구분	내용	비고
구성	Part1~7 요구사항·지침 체계	일반~응용지침
파생표준	ISO26262(차량), IEC61511(공정)	산업별 특화
적용동향	고신뢰 시스템 SIL4 요구증가	자율화 확산 영향

• 산업별 파생표준으로 적용범위 확대

PFD와 PFH는 IEC 61508에서 SIL(안전무결성수준)을 정량적으로 결정하는 두 가지 고장확률 지표입니다. 어떤 지표를 쓰는지는 안전기능의 **운전모드(demand mode)**에 따라 갈립니다.

1. 개념 및 관계 구조

전체 체계를 먼저 보면:

안전기능 운전모드
   ├─ 저요구모드(Low demand mode) → PFD(avg) 사용
   │    예: 연1회 이하로 작동하는 비상정지 인터록
   └─ 고요구/연속모드(High demand / Continuous mode) → PFH 사용
        예: 상시 작동하는 안전계장, 연1회 초과 요구

• PFD (Probability of Failure on Demand): 요구가 발생했을 때 안전기능이 “실패할 확률” — 무차원 값 (0~1 사이 확률). 정확히는 평균값인 PFDavg를 사용합니다.
• PFH (Probability of Failure per Hour): 시간당 위험한 고장이 발생할 확률 — 단위: 1/hour (시간당 고장률).

즉 PFD는 “요구시점 기준 실패 확률”, PFH는 “단위시간당 고장 발생 빈도”로, 측정 단위와 적용 모드 자체가 다릅니다.

2. 왜 두 지표가 필요한가 (설계 함의)

• 저요구모드 시스템은 평상시 대기 상태이므로, 실제 요구가 왔을 때 얼마나 자주 실패하는가가 중요 → 확률(PFD) 기반.
• 고요구/연속모드 시스템은 계속 동작 중이므로, 시간당 위험 고장 발생 빈도가 실질적 위험도를 좌우 → 고장률(PFH) 기반.
• 두 지표는 하드웨어 고장률(λ), 진단범위(DC, Diagnostic Coverage), 테스트 주기(proof test interval), 이중화 구조(1oo1, 1oo2, 2oo3 등)를 반영한 계산식으로 산출되며, 이 계산 결과가 위 표의 SIL 구간에 들어가는지로 등급이 확정됩니다.

디지털 트윈

I. 물리·가상 실시간 연동체계, 디지털 트윈의 개요

• 개념: 물리객체를 가상공간에 실시간 복제

• 특징: (1) 실시간 데이터 동기화 (2) 시뮬레이션 기반 예측분석

• 물리-가상 연동으로 예측·최적화 지원

II. 디지털 트윈의 구성도 및 구성요소

가. 디지털 트윈의 구성도

[물리객체(Physical)]
   ↕ (센서/IoT 데이터 수집)
[데이터 연동계층(Connectivity)]
   ↕ (실시간 동기화)
[가상모델(Virtual Twin)] → [시뮬레이션/분석] → [피드백 제어]
   ↑______________________________________________|

• 물리객체↔가상모델 양방향 실시간 순환

나. 디지털 트윈의 구성요소

구분	구성요소	설명
데이터수집	IoT센서	물리객체 상태 실시간 수집
데이터수집	엣지컴퓨팅	현장 데이터 전처리
모델링	3D모델	물리객체 형상 시각화
모델링	물리시뮬레이션	동작·환경 물리법칙 반영
분석·제어	AI/빅데이터 분석	이상탐지 및 예측
분석·제어	피드백 제어	분석결과 물리객체 반영

• 수집·모델링·분석제어 3범주 구성

III. 디지털 트윈 추가정보

구분	내용	비고
표준	ISO 23247 제조분야 표준	국제표준 정립중
관련기술	메타버스와 결합 확대	가상공간 활용 확장
시사점	장애예지·비용절감 효과	제조·도시·의료 적용

• 제조 중심에서 전산업 확산 추세