AWS 기술 블로그
AWS IoT Core를 활용한, ‘우아한형제들’의 실외배달 로봇과 클라우드 리소스의 안전한 연결 구축기
이 블로그는 고객-점주 사이에서 이루어져야 하는 빠른 배달을 만들어내기 위한 실외 배달로봇을 운영하는 로봇배달 서비스를 개발하기 위해 어떻게 하면 안전한 배달 서비스를 구성할 수 있을지에 대한 우아한형제들의 고민을 담고 있습니다. 우아한형제들은 2025년 2월부터 강남논현 비마트에 자체개발한 배달로봇인 딜리(Dilly)를 투입하여 고객이 주문한 물품들을 배달하고 있습니다. 딜리가 배달을 수행하기 위해서는 고객의 주문이 비마트에서 수행되는 과정에서, 정보가 전달되는 통신 과정에서의 안전성을 확보하는 데에도 관심을 쏟고 있습니다.
이를 위해, 본 블로그에서는 AWS IoT Core를 중심으로 1) 안전한 통신을 만들어 내기 위한 보안 문제를 다루면서, 2) 배달로봇의 고도화를 위해 필요한 데이터 수집/분석, 3) 로봇의 관제를 위한 서비스를 구성하는 인프라를 구성한 방법을 간략히 소개합니다. 우아한형제들은 AWS IoT Core의 Fleet Provisioning, IoT Rule, Credential Provider를 활용하여 Amazon S3, Amazon DynamoDB, Amazon CloudWatch를 안전하게 연동함으로써 로봇의 실시간 상태 파악과 다양한 문제들을 빠르게 해결하기 위한 관제 서비스를 제공하고 있습니다. 본 블로그는 우아한형제들의 경험을 기반으로 다양한 IoT에 적용이 가능한 IoT Core 기반의 안전한 클라우드 연동 방법을 설명합니다.
실외 배달로봇과 클라우드의 연결 과정에서의 보안
로봇 배달 플랫폼은 Amazon VPC를 통해 클라우드 내부에서의 통신만 다루면 되는 MSA로 볼 수 없고, 실외를 이동하면서 클라우드 내의 리소스들을 사용해야 합니다. 이러한 과정에서 어떻게 하면 다수의 로봇들이 안전한 연결 구성을 다룰 수 있을지는 아주 중요한 문제였고, 이를 좀 더 구체화 한다면 아래와 같은 문제들이 존재합니다.
1. 생산된 로봇을 안전하게 등록하고 관리하는 문제
대규모 실외 배달로봇 플랫폼을 운영할 때, 생산된 로봇을 안전하게 등록하고 관리하는 문제는 서비스의 보안과 운영 효율성을 결정하는 핵심 과제입니다. 로봇이 현장에 지속적으로 배포되므로, 관리자의 수동적인 조치 없이도 로봇이 클라우드 서비스에 안전하게 자동 등록되는 ‘제로 터치(Zero-Touch) 등록’ 메커니즘을 확보하는 것이 매우 중요합니다. 하지만, 자동 등록 과정에만 집중한다면 신뢰성 검증 없이 로봇이 무단으로 연결되는 것을 방지하기 어렵기 때문에 보안을 고려한 검증 방식이 필수적인 요소입니다. 또한, 배달 서비스에서는 수많은 로봇을 효율적으로 통제해야 하므로, 로봇의 사양이나 역할에 따라 미리 정해진 그룹으로 묶어 메시징 및 정책을 관리할 수 있는 체계가 필요합니다. 이와 동시에, 특정 로봇에 문제가 발생했을 경우 개별 로봇 단위로 등록 관리를 진행하고 네트워크에서의 세밀한 관리 및 격리를 달성하는 유연성도 확보해야 합니다.
2. 외부에서 다니는 로봇들 간의 격리 수준 달성 필요
아래는 대규모 로봇 관제 시스템에서 로봇을 관리할 때, 고려해야 하는 문제들을 실외 배달로봇 수백 대가 동시에 운용되는 상황을 예로 들어 설명합니다.
- 개별 로봇 격리: 로봇 A가 자신의 위치, 배터리 잔량, 임무 상태 등의 정보를 특정 토픽(예:
<robotId>/topic/status)에 발행(Publish)할 때, 다른 로봇 B가 이 토픽을 구독(Subscribe)하여 로봇 A의 상태를 들여다보거나, 로봇 A의 제어 토픽(예:<robotId>/topic/command)에 잘못된 명령을 발행하는 것을 근본적으로 방지해야 합니다. 즉, 하나의 로봇의 상태나 제어 메시지가 다른 로봇에 전파되지 않도록 개별 로봇 수준의 강력한 보안 격리가 필요합니다. - 서버 통합 관리: 반면에 중앙 관제 서버는 모든 로봇의 데이터를 수신하여 실시간 상태 파악, 모니터링, 데이터 분석 및 관제를 수행해야 합니다. 서버는 수백 대 로봇의
+/topic/status와 같은 모든 상태 데이터를 안전하고 안정적으로 수신해서 관리할 수 있어야 합니다. - 비용 효율성: 이 모든 메시지 송수신 과정에서 클라우드 리소스를 효율적으로 사용하여 운영 비용을 최소화해야 합니다. 로봇이 클라우드로 직접 데이터를 송수신할 때 발생하는 연결 및 메시지 처리 비용을 고려하여, 서버로의 안정적인 데이터 전송과 집계를 달성해야 합니다.
3. 단순 메시지 송수신에서 벗어나 실시간 스트림과 동적으로 리소스를 제공할 수 있는 수단
배달로봇은 개별 단위에서 자율주행 기능을 갖춘 로봇이지만, 배달 서비스에서는 다수의 배달 수요에 맞춰 관리되어야 하는 군체로서 동작할 수 있어야 합니다. 이 과정에서 서로가 가진 정보를 교환하여, 실시간으로 발생하는 사고나 시작되는 공사로 인한 여러 이벤트를 일종의 집단지성으로 관리하고 활용할 수 있어야 합니다. 이는 지도 데이터뿐 아니라 경로 정보까지 포함하며, 서비스 등록과 배달 수행에 필요한 데이터를 모바일 네트워크를 통해 외부망에서 동작하는 로봇이 안전하고 검증된 수단으로 클라우드에 전송해야 함을 의미합니다. 이것이 AWS IoT Core를 중심으로 실외 배달로봇과 S3·DynamoDB·CloudWatch 등의 클라우드 리소스를 안전하게 통합함으로써 해결이 가능합니다.
IoT 클라우드 연동 플랫폼 개요
본 섹션에서는 IoT 클라우드 연동 플랫폼이 1) IoT Core를 중심으로 안전하게 IoT 기기를 클라우드에 등록하는 방법, 2) IoT 기기와 클라우드 서비스를 안전하게 연결하여 통신하는 방법, 그리고 3) 리소스별 AWS IAM 역할(Role)들을 개별적으로 인증하여 임시키를 발급함으로써 클라우드 리소스를 안전하게 제공하는 방법을 설명합니다.
1. 안전한 로봇 자동 등록
- IoT 기기 등록에는 Fleet Provisioning 템플릿을 사용하며, 등록 절차의 보안 강화를 위해 Pre-Provisioning Hook을 활용한 자체 2단계 검증 과정을 거칩니다.
- 이 검증을 통과한 로봇만 AWS에 의해 디바이스 인증서가 발급됩니다.
- 등록된 디바이스들은 Thing Group을 통해 그룹으로도 관리가 가능하면서도, 단일 Thing Name과 인증서 단위로도 관리할 수 있습니다.
2. AWS IoT Core 연결 및 메시징
- 등록이 완료된 IoT 기기는 AWS IoT Core에 클라이언트로서 안전하게 연결됩니다. 이 과정에서 IoT Core Policy를 통해 서로 다른 로봇들이 주고 받는 데이터가 발생하지 않도록 관리합니다.
- 로봇 사양에 따라 디바이스 그룹을 나누어 토픽 기반 Pub/Sub 메커니즘을 효율적으로 활용합니다.
- IoT Core 메시지 전달 과정에서 백엔드 서비스(예: EC2 Auto Scaling Group 또는 ECS)로의 비용 효율적인 메시지 전달을 위해 AWS IoT Core Rules Engine을 사용하여 메시지를 Amazon Simple Queue Service (Amazon SQS)로 라우팅하여 로봇의 상태 정보들을 단일 subscription으로 해소하고, 이를 다른 백엔드 서비스로 Kafka를 통해 전달함으로써, 클라우드의 여러 서비스들이 최신의 정보들을 이벤트로 활용 가능하도록 합니다.
3. 클라우드 리소스 접근 제어
- 각 IoT 기기는 Fleet Provisioning을 통해 발급받은 Device Certificate를 기반으로 인증된 로봇을 IoT Core와 연동합니다.
- 로봇이 안전하게 S3, DynamoDB, CloudWatch와 같은 필요한 클라우드 리소스에 접근할 수 있도록 IoT Core의 Credential Provider를 사용합니다.
- 보안 강화를 위해 리소스별, 로봇별 접근 권한을 분리하도록 각각 다른 IAM 역할을 할당하여 세밀한 접근 통제를 구현합니다.
이러한 구조를 통해 로봇의 실시간 상태 파악, 데이터 수집/분석, 관제 서비스 구성 등 로봇 배달 플랫폼의 핵심 기능을 안전하고 효율적으로 구현합니다.
로봇과 클라우드 연동 과정
로봇과 클라우드 연동을 위해서는 아래와 같이 3단계의 연동 과정을 거칩니다.
- 단계 1: Fleet Provisioning을 통한 로봇의 등록
- 단계 2: IoT Rule을 통한 AWS Resource로의 포워딩 규칙 정의
- 단계 3: Role Alias를 이용한 리소스별 접근 권한 제한 및 임시 인증키 발급
사전 준비사항
솔루션을 배포하기 위해서는 아래와 같은 사항을 미리 준비해야 합니다.
- AWS account
- AWS S3, DynamoDB, IAM role에 대한 기본 지식
- 리소스(Thing Group, Role Alias, IoT/IAM Policy 등) 관리 수단 — 우아한형제들은 Terraform으로 관리하였으나, 본 글을 처음 따라하시는 분께는 AWS Console이 가장 쉽고, 자동화가 필요하시면 AWS CLI v2 또는 Terraform / CDK 등을 사용하실 수 있습니다.
- 클레임 인증서 — 별도의 외부 도구로 생성하지 않고 AWS IoT Core가 발급한 인증서를 그대로 사용합니다.
- 클레임 인증서를 사전 탑재한 IoT 디바이스 또는 시뮬레이터 — Fleet Provisioning 클라이언트는 자체 구현이 가능하나, AWS IoT Device SDK v2 for Python 사용을 권장합니다.
- 리소스 단위의 IAM role을 생성
단계 1: Fleet Provisioning 템플릿 및 Provisioning Hook 생성
대규모 실외 배달로봇과 같은 IoT 환경에서 안전하고 효율적인 ‘제로 터치(Zero-Touch) 등록’을 달성하기 위해 Provisioning by Claim 방식을 선택했습니다. 이 방식은 생산된 모든 로봇에 공통된 일회성 클레임 인증서(Claim Certificate)를 미리 심어 출고하고, 로봇이 이 인증서를 사용하여 AWS IoT Core에 처음 연결을 시도하게 합니다.
Provisioning by Claim 방식을 채택한 주요 이유는 다음과 같습니다.
- 대규모 자동화 등록(Zero-Touch): 수백 대의 로봇을 관리자가 수동으로 등록하는 것은 비효율적입니다. Provisioning by Claim은 로봇이 자체적으로 등록 프로세스를 시작하도록 하여, 대규모 장치 배포 시 관리 개입을 최소화하는 ‘제로 터치’ 환경을 구현하는 데 가장 적합합니다.
- 보안 강화 (Pre-Provisioning Hook 연동): 클레임 인증서만으로는 신뢰성을 보장할 수 없으므로, 등록 절차의 보안 강화를 위해 Pre-Provisioning Hook을 활용한 자체 2단계 검증 과정을 거칩니다. 이 훅(Hook)은 로봇이 최종 등록되기 직전에 실행되는 AWS Lambda 함수로, 로봇의 시리얼 번호나 기타 정보를 검증하여 신뢰할 수 있는 로봇만 최종 등록되도록 합니다. 이 검증을 통과한 로봇에게만 AWS에 의해 고유한 디바이스 인증서가 발급됩니다.
Fleet Provisioning 템플릿과 Provisioning Hook의 역할
Fleet Provisioning 템플릿: 등록 과정에서 생성할 클라우드 리소스(Thing, Certificate, Policy)를 정의하는 청사진입니다.
- 템플릿에는 기기의 고유 식별자인
RobotId와 같은 정보를 동적으로 전달받을 파라미터가 정의됩니다. - 등록 성공 시 Thing과 Certificate가 생성 및 활성화되도록 리소스 항목이 명시됩니다. 템플릿을 통해
RobotId를 ThingName으로,Serial을 속성(Attribute)으로 설정하고, 기기가 속할Thing Group을 지정하여 등록과 동시에 초기 관리가 가능하게 합니다.
{
"Parameters": {
"RobotId": { "Type": "String" },
"Serial": { "Type": "String" }
},
"Resources": {
"certificate": {
"Properties": {
"CertificateId": { "Ref": "AWS::IoT::Certificate::Id" },
"Status": "Active"
},
"Type": "AWS::IoT::Certificate"
},
"thing": {
"OverrideSettings": {
"AttributePayload": "DO_NOTHING",
"ThingGroups": "DO_NOTHING"
},
"Properties": {
"AttributePayload": {
"Serial": { "Ref": "Serial" }
},
"ThingGroups": [ "<thing-group-name>" ],
"ThingName": { "Ref": "RobotId" }
},
"Type": "AWS::IoT::Thing"
}
}
}위 템플릿에서 OverrideSettings를 DO_NOTHING으로 지정한 의도는, 동일한 RobotId로 재-provisioning이 발생하더라도 기존 Thing의 AttributePayload와 ThingGroups 설정을 덮어쓰지 않도록 하여 운영 중 의도치 않은 속성 변경을 방지하기 위함입니다.
Provisioning Policy 템플릿: Provisioning 템플릿을 생성한 후, claim certificate를 사용하기 위해 아래와 같은 정책을 적용합니다. 아래 ARN에서 <provisioning-template-name>은 실제로 생성한 Fleet Provisioning 템플릿의 이름으로 치환해야 합니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [ "iot:Publish", "iot:Receive" ],
"Effect": "Allow",
"Resource": [
"arn:aws:iot:ap-northeast-2:<ACCOUNT_ID>:topic/$aws/certificates/create/*",
"arn:aws:iot:ap-northeast-2:<ACCOUNT_ID>:topic/$aws/provisioning-templates/<provisioning-template-name>/provision/*"
]
},
{
"Action": "iot:Subscribe",
"Effect": "Allow",
"Resource": [
"arn:aws:iot:ap-northeast-2:<ACCOUNT_ID>:topicfilter/$aws/certificates/create/*",
"arn:aws:iot:ap-northeast-2:<ACCOUNT_ID>:topicfilter/$aws/provisioning-templates/<provisioning-template-name>/provision/*"
]
},
{
"Action": "iot:Connect",
"Effect": "Allow",
"Resource": "*"
}
]
}Pre-Provisioning Hook: Fleet Provisioning 프로세스 중간에 삽입되는 사용자 정의 보안 검증 단계입니다.
- 로봇이 클레임 인증서로 Provisioning을 요청하면, 이 Hook이 먼저 호출되어 로봇의 신뢰성을 검증합니다.
- 2단계 검증의 구성은 다음과 같습니다. (1) 클레임 인증서의 신뢰성 검증: AWS IoT Core가 클레임 인증서의 유효성을 자체적으로 확인합니다. (2) Lambda 기반 비즈니스 검증: Hook이 AWS Lambda를 호출하여 클레임 인증서에 포함된 정보 및 요청 파라미터(시리얼, RobotId 등)에 대한 등록 중복 여부 및 비정상 등록 여부를 확인합니다.
- Lambda는
allowProvisioning: true와 함께 필요 시parameterOverrides를 반환하여 후속 단계의 파라미터를 보정할 수 있으며, 거부 시allowProvisioning: false를 반환하면 디바이스 인증서가 발급되지 않고 등록이 거부됩니다. - 자체 2단계 검증을 통해 신뢰성이 확인된 로봇에게만 AWS가 최종 Device Certificate를 발급하고, Thing을 생성하는 후속 프로세스가 진행됩니다.
이러한 구조를 통해 우아한형제들은 대규모 로봇 플랫폼에서 자동화(Zero-Touch)와 보안 검증이라는 두 가지 핵심 요구사항을 모두 충족하며 로봇을 클라우드에 안전하게 통합할 수 있습니다.
단계 2: IoT Rule을 통한 AWS Resource로의 포워딩 규칙 정의
이 단계의 핵심은 개별 로봇의 강력한 격리를 달성하면서도 중앙 관제 서버가 모든 로봇의 데이터를 집계할 수 있도록 통신 정책을 분리하고, 대규모 메시징 처리에 대한 비용 효율성을 확보하는 것입니다.
1. 로봇 및 서버별 차별화된 IoT Core Policy 적용
안전한 통신 격리 및 데이터 집계를 위해 로봇(Thing)들 사이에 격리된 IoT Core Policy를 적용합니다.
- 로봇 Policy: 개별 로봇이 다른 로봇의 데이터에 접근하는 것을 원천적으로 차단하기 위해, 로봇에게는 오직 자신의 고유한 Topic에 대해서만 Publish(발행) 및 Subscribe(구독) 권한을 부여합니다. 위의 provisioning 템플릿을 통해 등록한
RobotId를${iot:ClientId}로 두고, 이 값이 IoT Core에 등록된 ThingName과 동일하도록 하였습니다. 이를 통해, 특정 로봇은 자신에 해당하는 토픽에만 접근 가능하도록 클라이언트 ID를 토픽 이름에 포함하였습니다. 이를 통해 개별 로봇 수준의 강력한 보안 격리가 달성됩니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowConnectWithThingName",
"Effect": "Allow",
"Action": "iot:Connect",
"Resource": "arn:aws:iot:ap-northeast-2:<ACCOUNT_ID>:client/${iot:Connection.Thing.ThingName}",
"Condition": {
"Bool": { "iot:Connection.Thing.IsAttached": "true" }
}
},
{
"Sid": "AllowPublishToOwnTopics",
"Effect": "Allow",
"Action": "iot:Publish",
"Resource": [
"arn:aws:iot:ap-northeast-2:<ACCOUNT_ID>:topic/${iot:ClientId}/topic/*",
"arn:aws:iot:ap-northeast-2:<ACCOUNT_ID>:topic/${iot:ClientId}/connection"
],
"Condition": {
"Bool": { "iot:Connection.Thing.IsAttached": "true" }
}
},
{
"Sid": "AllowReceiveFromOwnTopics",
"Effect": "Allow",
"Action": "iot:Receive",
"Resource": [
"arn:aws:iot:ap-northeast-2:<ACCOUNT_ID>:topic/${iot:ClientId}/topic/*"
],
"Condition": {
"Bool": { "iot:Connection.Thing.IsAttached": "true" }
}
},
{
"Sid": "AllowSubscribeToOwnTopicFilters",
"Effect": "Allow",
"Action": "iot:Subscribe",
"Resource": [
"arn:aws:iot:ap-northeast-2:<ACCOUNT_ID>:topicfilter/${iot:ClientId}/topic/*"
],
"Condition": {
"Bool": { "iot:Connection.Thing.IsAttached": "true" }
}
}
]
}위 정책에서 ${iot:ClientId}와 ${iot:Connection.Thing.ThingName}은 런타임에 동일한 값이지만, 그 약속이 어떻게 강제되는지를 구체적으로 살펴보면 다음과 같습니다.
- Connect Statement —
${iot:Connection.Thing.ThingName}을 사용하는 이유: 위 매핑(RobotId ==${iot:ClientId}== ThingName)이 실제로 강제되는 anchor는 Connect 단계입니다. 이 Statement의 Resource로 AWS 측 검증값인${iot:Connection.Thing.ThingName}을 사용함으로써, 인증서가 attach된 Thing의 이름과 MQTT CONNECT 패킷의 ClientId가 정확히 일치하는 경우에만 연결이 허용됩니다. 정상 발급된 다른 인증서로 타 로봇의 ClientId를 사용하여 연결을 시도하면, 이 변수가 해소되지 않아 묵시적으로 차단됩니다. - Publish / Subscribe / Receive Statement —
${iot:ClientId}가 안전한 이유: 토픽 ARN에는 우아한형제들 내부 식별자인${iot:ClientId}를 그대로 사용합니다. Connect 단계에서 ClientId가 이미 ThingName과 일치하도록 검증되었고 MQTT 세션 동안 ClientId가 변경 불가능하기 때문에, 이 표기는 ThingName 사용과 동일한 격리 효과를 제공합니다. 동시에 정책 코드 상에서 “우리 시스템이 부여한 RobotId/ClientId”와 “AWS 레지스트리에 등록된 ThingName”이라는 두 개념을 명시적으로 구분할 수 있어, 시스템 경계가 코드 수준에서 self-documenting됩니다. - 모든 Statement —
iot:Connection.Thing.IsAttached: true조건: 인증서가 Thing에 attach된 상태에서만 정책이 효력을 갖도록 명시적으로 강제합니다. 기술적으로는${iot:Connection.Thing.ThingName}변수의 해소 자체가 attach를 요구하므로 부분적으로 중복 검사이지만, 운영 관점에서는 인증서를 detach하는 즉시 해당 세션의 모든 작업 권한이 사라지도록 보장하므로, 인증서 폐기·재발급 대응이 권한에 즉각 반영됩니다.
2. IoT Rule Engine을 활용한 데이터 포워딩 및 비용 최적화
위에서 언급되지 않은 서버 Policy는 서버가 직접 IoT Core의 구독자(subscriber)가 될 경우에 한해 필요하게 됩니다. 하지만, 이러한 직접적인 구독 방식은 너무 많은 IoT Core의 메시지를 발생시켜 비용을 증가시킬 수 있습니다. 이에 우리는 비용 효율성을 극대화하기 위해, AWS IoT Core의 Rules Engine을 사용하여 메시지를 서버로 직접 전달하는 대신 Amazon SQS와 같은 중간 리소스로 라우팅합니다. 이를 통해 다수의 백엔드 subscriber 연결을 단일 IoT Rule로 통합하여 IoT Core 메시지 비용을 줄이고, SQS 기반 pull 모델로 백엔드의 부하·처리 비용을 분리할 수 있습니다.
- 비용 효율적 메시지 집계: IoT Rule을 정의하여 모든 로봇의 상태 정보(
+/telemetry)를 단일 Subscription으로 해소합니다. 이렇게 수집된 메시지를 Rule Action을 통해 Amazon SQS로 일괄 포워딩하여, 백엔드 서비스가 Amazon SQS에서 필요한 데이터를 Pull(가져오기) 방식으로 처리하게 합니다. - 서버 부하 분산 및 이벤트 활용: Amazon SQS로 라우팅된 로봇의 상태 정보들은 백엔드 서비스로 Kafka 등을 통해 전달되어, 클라우드의 여러 서비스들이 최신의 정보를 이벤트로 활용 가능하도록 합니다. 이로써 중앙 서버는 수백 대의 로봇과 직접 연결하여 발생하는 부하와 메시지 처리 비용을 최소화하고, 안정적이고 비동기적인 데이터 전송 및 집계 시스템을 구축할 수 있습니다. Amazon SQS는 점대점(point-to-point) 모델이라 다수 인스턴스에 동일 메시지를 fan-out 전달하지는 못합니다. 우아한형제들에서는 이를 자체 broker layer를 통해 보완하였으며, 내부 구현 상세는 본 글의 범위를 벗어납니다. 단순히 동일한 fan-out 효과만 필요한 경우 Amazon MSK를 사용하면 포워딩 룰만으로 동일한 효과를 기대할 수 있습니다.
- 데이터 필터링: IoT Rule의 쿼리문을 활용하여 필요한 데이터만 선별적으로 포워딩할 수 있습니다. 예를 들어, 사용자 속성에 특정 값이 존재하면서 메시지 페이로드에 특정 필드가 존재할 경우의 로봇 데이터만 Amazon SQS로 전달하도록 설정하여, 불필요한 메시지 처리를 줄이고 비용을 절감할 수 있습니다.
SELECT *, timestamp() as receptionTimestamp
FROM '+/telemetry'
WHERE get(get_user_properties('user_prop'), 0)='prop1'
AND payload_type='type'위 SQL에서 get(get_user_properties('user_prop'), 0)의 의미는 다음과 같습니다. MQTT5의 User Properties는 동일 key의 중복 값을 허용하기 때문에 get_user_properties() 함수는 해당 key에 대한 값들의 배열을 반환합니다. 따라서 첫 번째 값을 추출하기 위해 get(..., 0) 패턴을 사용합니다.
단계 3: Role Alias를 이용한 리소스별 접근 권한 제한 및 임시 인증키 발급
이 단계는 IoT Core에 성공적으로 등록되고 연결된 로봇이 AWS 내부의 S3, DynamoDB, CloudWatch와 같은 클라우드 리소스에 안전하게 접근할 수 있도록 권한을 부여하는 방법을 다룹니다. 핵심은 AWS IoT Core의 Credential Provider를 활용하여 로봇에게 필요한 리소스에만 접근 가능한 임시 인증키(Temporary Credentials)를 발급하는 것입니다.
1. 리소스별 IAM 역할 생성 및 최소 권한 원칙 적용
로봇이 접근해야 하는 클라우드 리소스별로 각각 다른 IAM 역할(Role)을 생성하고, 최소 권한(Least Privilege) 원칙에 따라 필요한 권한만을 부여하여 접근 권한을 세밀하게 제한합니다.
- S3 전용 Role: 로봇의 로그 데이터나 임무 데이터를 업로드할 특정 S3 버킷에 대해서만
s3:PutObject권한 등을 부여하여 데이터 저장소에 대한 쓰기 권한을 제한합니다. - CloudWatch Logs 전용 Role: 로봇의 실시간 로그를 기록하기 위해
logs:CreateLogGroup,logs:CreateLogStream,logs:PutLogEvents등의 권한을 부여합니다. - DynamoDB 전용 Role: 지도 데이터나 설정값을 읽기 위한
dynamodb:GetItem등의 권한을 부여하여 데이터베이스에 대한 읽기 권한을 제한합니다.
로봇이 CloudWatch에 로그를 기록하기 위해 생성하는 IAM 역할의 예시는 다음과 같습니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:PutRetentionPolicy"
],
"Resource": "arn:aws:logs:*:*:log-group:/log-group-name*"
}
]
}2. AWS IoT Core의 Credential Provider와 Role Alias를 통한 임시 인증키 발급
로봇이 클라우드 리소스에 직접 접근할 때 영구적인 인증키를 사용하는 것은 보안상 위험합니다. 따라서 AWS IoT Core의 Credential Provider 기능을 사용하여 임시 자격 증명을 획득합니다.
- Role Alias (역할 별칭): 미리 생성한 IAM 역할을 가리키는 별칭(Alias)을 IoT Core에 등록합니다. 이 별칭은 로봇이 요청할 IAM 역할을 식별하는 데 사용됩니다.
- 인증 및 임시 키 발급: IoT Core에 Fleet Provisioning을 통해 발급받은 Device Certificate로 인증된 로봇은 연결 시 이 Role Alias를 사용하여 Credential Provider에 임시 보안 자격 증명(Access Key ID, Secret Access Key, Session Token)을 요청합니다. AWS STS(Security Token Service)는 요청을 수락하고, 로봇이 Role Alias가 참조하는 IAM 역할을 맡을 수 있도록 하는 임시 인증키를 발급합니다.
- 리소스 접근: 로봇은 발급받은 임시 인증키를 사용하여 S3, DynamoDB, CloudWatch와 같은 AWS 리소스에 직접 접근하여 데이터를 업로드하거나 다운로드합니다. 이 임시 키는 유효 기간이 짧기 때문에(일반적으로 1시간), 키가 탈취되더라도 위험이 최소화됩니다.
- 로봇은 인증키를 주기적으로 갱신하여, 리소스 사용이 끊어지는 시간을 최소화할 수 있습니다.
구체적인 호출 형태는 다음과 같습니다. 로봇은 자신의 Device Certificate를 mTLS 클라이언트 인증서로 사용하여 IoT Credential Provider 엔드포인트에 HTTPS GET을 호출합니다.
GET https://<account-specific-prefix>.credentials.iot.ap-northeast-2.amazonaws.com/role-aliases/<role-alias-name>/credentials
Headers:
x-amzn-iot-thingname: <RobotId>
Client auth: mTLS with Device Certificate응답으로 받은 임시 자격 증명을 AWS SDK 또는 직접 호출 시 서명에 사용하면, Role Alias가 가리키는 IAM Role의 권한 범위 안에서 S3·DynamoDB·CloudWatch에 접근할 수 있습니다.
이러한 Role Alias 기반의 임시 인증키 발급 메커니즘을 통해, 각 로봇에게 필요한 최소한의 권한만을 동적으로 부여함으로써 클라우드 리소스에 대한 접근 통제 및 보안이 획기적으로 강화됩니다.
결론
본 블로그는 우아한형제들이 실외 배달로봇 딜리(Dilly)를 활용한 배달의민족 로봇 배달 서비스를 운영함에 있어, AWS IoT Core를 핵심 플랫폼으로 채택하여 어떻게 안전하고 효율적인 관제 시스템을 구축했는지에 대한 경험을 공유했습니다. AWS IoT Core는 단순한 IoT 기기 연결을 넘어, 로봇 배달 서비스의 근간이 되는 안정성과 보안성을 획기적으로 강화하는 중요한 역할을 수행했습니다.
AWS IoT Core의 우수성 및 서비스 안정성 기여:
- 자동화된 보안 등록 (Zero-Touch Provisioning): Provisioning by Claim 방식과 Pre-Provisioning Hook을 활용한 자체 2단계 검증을 통해, 현장에 지속적으로 배포되는 로봇이 관리자 개입 없이도 클라우드에 안전하게 자동 등록되도록 했습니다. 이는 대규모 로봇 운영의 효율성을 극대화하는 동시에 무단 연결을 방지하여 보안성을 높입니다.
- 강력한 개별 격리 및 효율적 집계: IoT Core Policy를 통해 개별 로봇 간의 메시지 송수신을 원천적으로 차단하여 보안 격리 수준을 달성했습니다. 동시에, IoT Rules Engine을 사용하여 모든 로봇의 데이터를 Amazon SQS로 일괄 포워딩함으로써 중앙 서버의 부하를 최소화하고, 안정적인 데이터 집계 및 운영 비용 최적화를 실현했습니다.
- 세밀한 클라우드 리소스 접근 통제: 영구 인증키 대신 Credential Provider와 Role Alias를 통해 S3, DynamoDB, CloudWatch 등 필요한 클라우드 리소스에 대해서만 최소 권한의 임시 인증키를 동적으로 발급합니다. 이 구조는 키 탈취 위험을 최소화하고, 각 로봇에게 필요한 권한만을 부여하여 플랫폼 전반의 보안을 획기적으로 강화합니다.
요약하자면, 우아한형제들의 로봇 배달 플랫폼은 AWS IoT Core의 Fleet Provisioning, IoT Rule, Credential Provider라는 핵심 기능을 유기적으로 결합하여, 안전한 자동 등록(Zero-Touch + 보안 검증) · 개별 로봇의 강력한 격리 · 클라우드 리소스에 대한 임시 인증키 기반 접근 통제라는 세 가지 축을 통해 자동화·보안 검증·격리·접근 통제의 네 가지 핵심 요구사항을 모두 충족했습니다. 이러한 AWS IoT Core 기반의 견고한 아키텍처는 배달의민족 로봇 배달 서비스가 수많은 로봇을 안전하고 효율적으로 관제하며, 고객들에게 신뢰할 수 있는 서비스를 제공할 수 있는 근본적인 안정성을 보장합니다.
참고 자료
- AWS IoT Core — Provisioning devices that don’t have device certificates (Fleet Provisioning by Claim)
- AWS IoT Core — Pre-Provisioning Hook
- AWS IoT Core — Thing policy variables
- AWS IoT Core — Security best practices
- AWS IoT Core — Rules Engine SQL functions
- AWS IoT Core — Authorizing direct calls to AWS services (Credential Provider)
저자 소개
 |
김병오 Tech Lead & Architect, 우아한형제들 김병오님은 우아한형제들 로보틱스 Lab 리더입니다. 로봇을 통한 배달 서비스를 실현하는 것을 목표로 사업성을 갖춘 로봇배달이 라이더와 공존하며 점주님들과 고객의 불편을 해소하는 수단으로써 일상에 정착할 수 있도록 하고 있으며, IoT와 자율주행 기술과 프론트엔드와 백엔드에 대한 지식 및 시스템 노하우를 토대로 학습을 통해 개선되는 기술 고도화 루프를 형성하기 위해 노력하고 있습니다. |