← 전체 글 보기

수동 등록을 끝내다: AWS IoT Fleet Provisioning + X.509로 로봇 온보딩 자동화

로봇 Agent를 제품으로 운영하려면, 기능보다 먼저 등록/인증/배포가 자동화되어야 한다.

직접 로봇을 등록하고 인증서를 수동으로 넣는 방식은 초기 데모 단계에서는 빠르지만, 운영 단계에서는 장애와 비용의 시작점이 된다.

이 글은 수동 프로비저닝을 AWS IoT Fleet Provisioning + X.509 구조로 바꾸기 위해 어떤 기준으로 결정을 내렸는지 정리한 실무 기록이다.

문제 정의

당시 핵심 문제는 세 가지였다.

  1. 로봇 생성 시 수동 등록이 필요해 운영 비용이 커진다.
  2. 앱 서버가 메시지 중계까지 떠안아 트래픽 병목이 커진다.
  3. 식별자(F-CODE)는 변경/중복 가능성이 있어 단독 신뢰가 어렵다.

결국 목표는 명확했다.

어떤 로봇이든 ROS + Python 환경만 있으면, 사람 개입 최소로 등록/인증/연결이 끝나는 체계를 만드는 것.

제약 조건

설계에 영향을 준 제약은 다음과 같았다.

이 제약 때문에 “기능 확장"보다 “운영 단순화와 복구 가능성"을 우선했다.

핵심 의사결정

1) 식별자를 단일 키에 의존하지 않는다

F-CODE는 비즈니스 상 의미가 있지만, 영구 식별자로 쓰기에는 위험했다.

그래서 식별 계층을 분리했다.

이렇게 분리하면 비즈니스 식별자가 바뀌어도 인증/운영 체계는 유지된다.

2) 수동 등록 대신 Fleet Provisioning 자동화로 간다

등록 플로우를 아래처럼 단순화했다.

  1. 임시 인증서 발급(짧은 TTL)
  2. 템플릿 기반 디바이스 속성/권한 주입
  3. 서버에서 등록 검증 후 디바이스 인증서 발급
  4. 발급 인증서로 IoT Core 연결 및 메시지 송신 시작

핵심은 “등록할 때마다 사람 손으로 권한과 속성을 맞추지 않도록” 만드는 것이었다.

3) 인증 로직을 ROS 런타임에서 분리한다

인증서 등록이 ROS 프로세스에 과도하게 묶이면 장애 대응이 어렵다.

그래서 인증/등록 동작은 별도 모듈(향후 CLI)로 분리하는 방향을 택했다.

4) 메시징은 앱 서버 집중에서 단계적으로 분리한다

실시간 메시징과 스트림 처리까지 앱 서버가 모두 담당하면, 기능이 늘어날수록 병목이 구조적으로 커진다.

그래서 브로커 분리와 오토스케일 가능성을 초기에 검토하고, 선정 기준을 QoS/세션복구/모니터링/클라이언트 호환성 중심으로 재정의했다.

실행 플로우 상세

Fleet Provisioning을 실제 운영에 올릴 때는 등록 성공보다 오탐 방지가 더 중요했다. 등록 요청을 받으면 아래 순서로 검증했다.

  1. 제조/출고 메타데이터 유효성 확인
  2. 허용 모델/펌웨어 버전 확인
  3. 재등록 장비인지 확인(중복 장비 차단)
  4. 인증서 발급 후 즉시 권한 최소화 정책 적용

특히 AWS IoT Fleet Provisioning의 claim 기반 방식은 공용 자격이 섞이기 쉬워, claim credential 사용 로그를 별도 감사 채널로 분리했다.

운영 지표와 경보 기준

운영 중에는 아래 지표를 고정해 추적했다.

장애 대응에서는 절대값보다 증가 속도를 먼저 본다. 예를 들어 실패 건수가 작아도 10분 내 급증하면 템플릿/정책 변경 회귀일 가능성이 높다.

실패 시 복구 런북

프로비저닝 실패를 기능 장애와 분리하려면 복구 절차가 문서화되어 있어야 한다.

핵심은 “왜 실패했는지"를 로그에서 바로 설명 가능한 형태로 남기는 것이다.

결과와 현재 상태

아직 모든 항목이 완성된 것은 아니다. 하지만 “무엇을 자동화하고, 무엇을 분리해야 운영이 가능해지는지"에 대한 기준은 확정됐다.

다음 글 예고

다음 글: 앱 서버 병목에서 MQTT 브로커 분리까지: 무엇을 기준으로 선택했는가

참고 및 인용

참고: AWS IoT Fleet Provisioning은 claim 인증서 기반 대량 디바이스 온보딩 절차를 공식 가이드로 제공한다. Provisioning devices that don’t have device certificates

참고: AWS IoT X.509 인증서 모델은 디바이스 인증/권한 정책 분리를 위한 기본 전제다. X.509 client certificates

시리즈