클라우드 보안은 “방화벽”보다 “IAM”에서 무너진다

IAM 권한 설계 실수는 클라우드 사고의 가장 흔한 시작점입니다. 취약한 서버가 아니라 과도한 권한이 문제의 근원이며, IAM을 대충 설계하면 다음과 같은 사고가 연쇄적으로 터집니다.

• 누군가의 계정/토큰이 유출 → 권한이 넓어서 피해가 커짐
• 임시로 준 Admin 권한이 회수되지 않음 → “영구 Admin”이 조직에 남음
• 와일드카드(*) 정책이 남발 → 신규 서비스가 추가되는 순간 권한이 자동 확장됨
• 서비스 계정 키가 깃헙에 들어감 → 조용히 장기 침투

그래서 오늘은 “이론” 말고, 현장에서 가장 자주 보는 IAM 설계 실수 TOP 10과 예방책을 정리합니다.
(AWS/Azure/GCP 공통으로 적용 가능하게 구성했어요.)

---

IAM 권한 설계 실수를 막는 3대 원칙

1. 최소 권한(Least Privilege): “필요한 일만, 필요한 범위에서, 필요한 시간만”
2. 장기 자격증명 금지(Short-lived 우선): 사람/워크로드 모두 임시 토큰 기반으로
3. 가드레일 + 검증(Guardrails & Verification): “실수해도 망하지 않게” 조직/계정 레벨 안전장치 + 지속 점검

AWS는 IAM 보안 모범사례에서 사람은 IdP 연동(페더레이션)과 임시 자격증명, 워크로드는 IAM Role 기반 임시 자격증명을 권장하고, MFA/정기 리뷰/Access Analyzer 활용 등을 함께 제시합니다. (AWS Documentation)

---

IAM 권한 설계 실수 TOP 10과 예방책 총정리

아래 10개는 “사고 확률이 높고, 피해도 커지는” 조합입니다.

---

TOP 1) Root/Owner 계정 남용 — IAM 권한 설계의 가장 치명적 실수

왜 위험한가

• Root/Owner는 “마지막 열쇠”라서 탈취 시 방어가 거의 불가능해집니다.
• 특히 Root access key(프로그램 접근 키)가 존재하면 유출 리스크가 폭증합니다.

예방책

• AWS: Root 사용자 사용을 최소화하고, 멤버 계정이라면 루트 자격증명 제거/중앙화 같은 접근을 권장합니다. (AWS Documentation)
  또한 AWS는 “루트 사용자 접근 키를 쓰지 말라”는 취지의 보안 가이드를 제공합니다. (AWS Documentation)
• Azure: 최상위 권한(구독 Owner 등)을 “상시 보유”하지 말고, PIM으로 필요할 때만(JIT) 활성화하는 방식이 권장됩니다. (Microsoft Learn)
• GCP: Project Owner/Org Admin 같은 상위 권한을 최소화하고, 실제 운영은 역할 기반으로 분리(아래 TOP 2~3에서 이어짐)

바로 점검 질문: “지금 이 순간에도 누군가가 Root/Owner 권한을 ‘상시’ 들고 있나?”

---

TOP 2) “일단 Admin” (Owner/Contributor/Editor) 권한을 남발한다

왜 위험한가

• 계정이 털렸을 때 “한 기능만” 뚫린 게 아니라, 계정 전체가 뚫린 것처럼 전개됩니다.
• 최소 권한을 하지 않으면, 보안 사고의 피해 범위를 줄일 수 없습니다.

예방책

• AWS: 최소 권한을 권장하고(작업에 필요한 권한만), 성숙도에 따라 넓은 권한에서 점차 줄여가라고 안내합니다. (AWS Documentation)
• Azure: Azure RBAC 모범사례는 “구독 전체에 무제한 권한을 주지 말고, 필요한 범위(scope)에 필요한 역할만”을 명확히 권고합니다. (Microsoft Learn)
• Azure(추가 팁): 구독 Owner는 “최대 3명” 권고가 문서에 들어가 있을 정도로, 소수화가 핵심입니다. (Microsoft Learn)
• GCP: 서비스 계정/사용자에 Owner를 주기 전에 “업무별 역할(역할 묶음)”로 먼저 설계

바로 점검 질문: “Admin 권한이 없으면 일을 못 하는 사람이 몇 %인가?”

---

TOP 3) IAM 정책에 와일드카드(*)를 남발한다

왜 위험한가

• 현재뿐 아니라 미래의 서비스/기능까지 권한이 자동으로 열릴 수 있습니다.
• 특히 Resource *는 “모든 리소스”를 의미할 수 있어 치명적입니다.

예방책

• AWS: Resource 요소에서 와일드카드 사용 시 ARN 세그먼트 내에서 쓰는 것을 권장하는 등, 와일드카드 사용에 주의를 줍니다. (AWS Documentation)
  또한 일부 권한은 Resource:"*"가 필요한 경우가 있지만, 필요한 경우에만 쓰라고 안내합니다. (AWS Documentation)
• AWS(검증 도구): IAM Access Analyzer는 정책을 “IAM 정책 문법 + AWS 모범사례” 기준으로 검증해 경고/오류/제안 사항을 제공합니다. (AWS Documentation)
• Azure: Azure RBAC 문서에도 “커스텀 역할 만들 때 wildcard(*)를 피하고 Actions/DataActions를 명시하라”는 권고가 있습니다. (Microsoft Learn)

바로 점검 질문: “정책 JSON에서 *를 검색하면 몇 줄이 뜨나?”

---

TOP 4) 장기 자격증명 방치 — 클라우드 보안 사각지대

왜 위험한가

• 키는 유출돼도 티가 안 납니다. (침투자가 “정상 호출”처럼 쓰기 쉬움)
• 교체(로테이션) 체계가 없으면 유출 대응이 늦어집니다.

예방책

• AWS: 사람/워크로드 모두 IAM Role 기반 임시 자격증명을 권장합니다. (AWS Documentation)
• GCP: 서비스 계정 키는 “관리 가이드(키 회전/만료/유출 방지)”가 매우 구체적으로 제공됩니다(리포지토리에 올리지 말 것, 임시 위치에 두지 말 것, 정기 로테이션 등). (Google Cloud Documentation)
• GCP(가능하면 더 좋은 선택): Workload Identity Federation은 서비스 계정 키를 대체(키리스)하는 방향으로 소개됩니다. (Google Cloud)
• Azure: Managed Identity는 애플리케이션이 자격증명을 코드/설정에 저장하지 않도록 하는 방식으로 설명됩니다. (Microsoft Learn)

바로 점검 질문: “지난 90일 동안 회전(교체) 안 한 키가 존재하나?”

---

TOP 5) IAM 사용자에게 직접 권한을 붙이고 추적이 안 된다

왜 위험한가

• 인원 이동(입사/퇴사/프로젝트 종료) 때 권한 회수가 누락됩니다.
• 감사/추적이 어렵고, “왜 이 사람이 이 권한을 갖지?”가 계속 쌓입니다.

예방책

• AWS: IdP 연동(페더레이션)을 통한 접근을 권장합니다. (AWS Documentation)
• Azure: Azure RBAC 모범사례는 “사용자에게 직접 역할을 주지 말고, 그룹에 역할을 부여”하라고 권고합니다. (Microsoft Learn)
• Azure: 관리자 역할은 PIM으로 “필요할 때만 활성화(JIT)”가 핵심입니다. (Microsoft Learn)

바로 점검 질문: “개별 사용자에게 직접 붙은 역할(Direct assignment)이 몇 개인가?”

---

TOP 6) IAM 권한 스코프가 너무 넓다 (조직/구독 전체 부여)

왜 위험한가

• 뚫리면 “한 리소스”가 아니라 “전체 구독/프로젝트”가 위험해집니다.
• 실수(삭제/변경)도 범위가 커져서 장애로 직결됩니다.

예방책

• Azure: “넓은 스코프(관리그룹/구독) 대신 리소스 그룹/리소스처럼 좁은 스코프를 쓰라”는 권고가 문서에 명시돼 있습니다. (Microsoft Learn)
• AWS: 정책은 “어떤 Action을 어떤 Resource에 어떤 Condition으로 허용할지”로 최소 권한을 설계하라고 안내합니다. (AWS Documentation)
• GCP: 프로젝트 단위로 권한을 주기 쉬운데, 실제로는 폴더/조직 정책(가드레일)과 함께 “정말 필요한 범위만” 주는 습관이 중요

바로 점검 질문: “왜 이 권한이 ‘구독 전체’여야만 하지?”

---

TOP 7) 크로스계정/외부 공유(Trust/Resource Policy)를 ‘대충’ 열어둔다

왜 위험한가

• 내부 계정이 아니라 외부 계정/인터넷에서 접근 가능해질 수 있습니다.
• 특히 S3 같은 리소스 정책은 “퍼블릭/크로스계정 노출”로 바로 이어집니다.

예방책

• AWS: IAM Access Analyzer는 리소스에 대한 “외부(계정 밖) 접근 경로”를 찾아 보고하는 용도로 설명됩니다. (AWS Documentation)
• AWS: Access Analyzer는 S3 버킷 정책/ACL을 평가해 퍼블릭 또는 크로스계정 접근 가능 리소스를 식별한다고 AWS가 설명합니다. (Amazon Web Services, Inc.)

바로 점검 질문: “우리 리소스 중 ‘외부 계정’이 접근 가능한 게 무엇인지, 한 번이라도 Access Analyzer로 확인했나?”

---

TOP 8) 조직 차원의 “가드레일”이 없다 (계정/프로젝트가 제각각)

왜 위험한가

• 팀이 실수로 위험한 구성을 만들면, 보안팀이 사후에 뛰어다녀야 합니다.
• 멀티계정/멀티프로젝트가 되면 “사후 통제”는 거의 실패합니다.

예방책

• AWS: SCP(Service Control Policy)는 “권한을 부여하는 게 아니라, 조직 내 IAM 사용자/역할이 할 수 있는 행동에 상한(guardrail)을 두는 것”이라고 문서에서 정의합니다. (AWS Documentation)
  SCP 예시는 “어떻게 제한할 수 있는지”만 보여주며, 실제 적용 전 충분한 테스트를 강조합니다. (AWS Documentation)
• AWS: 계정 내부에서 “개발자가 권한을 만들 수 있게 위임”해야 한다면, Permissions Boundary로 최대 권한을 제한하는 패턴이 공식 문서/블로그에 소개됩니다. (AWS Documentation)

바로 점검 질문: “누군가 실수로 ‘모든 리전에 리소스 생성’/‘퍼블릭 공유’/‘Admin 부여’를 해도, 조직 차원에서 막히나?”

---

TOP 9) IAM 서비스 계정이 뭉개져 있다 (하나로 다 쓴다)

왜 위험한가

• 한 서비스 계정이 여러 시스템에 쓰이면, 침해 시 피해가 연쇄로 커집니다.
• “어떤 앱이 어떤 권한을 썼는지” 추적이 어려워집니다.

예방책

• AWS: 워크로드는 IAM Role 기반 임시 자격증명 사용을 권장합니다. (AWS Documentation)
• GCP(WIF): Workload Identity Federation 모범사례는 “과도한 설정은 권한 상승으로 이어질 수 있다”는 점을 경고하고, 서비스 계정과 접근 범위를 최소화하라고 안내합니다. (Google Cloud Documentation)
• Azure: Managed Identity를 활용해 “리소스(앱) 단위”로 권한을 분리하는 방향이 보안/운영 모두에 유리합니다. (Microsoft Learn)

바로 점검 질문: “이 서비스 계정(또는 MI/Role)이 ‘두 개 이상의 앱’에서 공유되고 있나?”

---

TOP 10) “정기 점검/검증”이 없다 (권한은 계속 쌓이는데, 줄이지 않는다)

왜 위험한가

• IAM은 시간이 지날수록 권한이 누적되는 시스템입니다.
• 정기적으로 “안 쓰는 권한/계정/키”를 제거하지 않으면, 침해 가능성이 계속 상승합니다.

예방책

• AWS: IAM 모범사례는 “사용하지 않는 사용자/역할/권한/정책/자격증명을 정기적으로 리뷰하고 제거”하라고 강조합니다. (AWS Documentation)
  또한 Access Analyzer는 CloudTrail 접근 활동을 기반으로 “필요 권한만 담은 정책 템플릿 생성”을 지원한다고 안내합니다. (AWS Documentation)
• AWS: 정책을 저장/배포하기 전 Access Analyzer로 정책 검증을 하라고 문서가 안내합니다. (AWS Documentation)
• Azure: PIM은 특권 권한을 “필요한 시간만” 활성화해 노출 시간을 줄이는 방식으로 소개됩니다. (Microsoft Learn)
• GCP: 서비스 계정 키는 “미사용 키 식별/로테이션/만료” 같은 운영 지침이 공식 문서로 제공됩니다. (Google Cloud Documentation)

바로 점검 질문: “권한 검토(Access review)를 마지막으로 한 게 언제인가?”

---

IAM 권한 설계 실무 템플릿 — 클라우드 보안 체계 잡기

1) 정체성(Identity)을 3종으로 분리

• 사람(Human): 직원/협력사
• 워크로드(Workload): 앱/배치/서버리스/컨테이너
• 외부(External): CI/CD, 파트너 시스템, SaaS 연동

2) 인증 방식(“키” vs “임시 토큰”)을 먼저 결정

• 사람: IdP 페더레이션 + MFA + (가능하면) JIT
• 워크로드: 클라우드 네이티브라면 Role/Managed Identity, 외부라면 Federation(WIF 등)
  • GCP는 WIF로 서비스 계정 키를 줄이는 방향을 안내합니다. (Google Cloud)

3) IAM 역할(Role) 설계는 “업무 단위”로

IAM 권한 설계 실수를 줄이려면 역할 이름 자체가 업무 범위를 드러내야 합니다. 예: Billing-ReadOnly, App-Deploy, DB-Backup-Operator, Security-Audit

4) 스코프를 최대한 좁히고, 조건(Conditions)으로 한 번 더 잠근다

• Azure는 넓은 스코프 대신 좁은 스코프를 명시적으로 권장합니다. (Microsoft Learn)

5) 가드레일(조직 정책) + 지속 검증(Analyzer/Logs)

• AWS: SCP(조직 상한) + Permissions Boundary(계정 내부 위임 상한) + Access Analyzer(검증/탐지). 권한 설정과 함께 AWS 비용 폭탄 방지 체크리스트도 점검하면 보안·비용을 동시에 잡을 수 있습니다 (AWS Documentation)
• GCP: 퍼블릭 바인딩(allUsers/allAuthenticatedUsers) 차단 + 키 관리 정책 (Google Cloud Documentation)

---

IAM 권한 설계 실수 점검 체크리스트 (15분 완성)

• Root/Owner 계정 “상시 사용” 여부 확인 (Root 키 존재 여부 포함) (AWS Documentation)
• Admin/Owner/Contributor/Editor 역할 보유자 목록 뽑기 → “왜 필요한지” 적기 (Microsoft Learn)
• 정책에서 * 검색(Action/Resource) → 예외(정당한 필요)만 남기기 (AWS Documentation)
• 장기 키(Access Key/Service Account Key) 목록 + 마지막 사용일 확인 → 미사용 제거/회전 (AWS Documentation)
• (AWS) Access Analyzer로 퍼블릭/크로스계정 접근 리소스 확인 (AWS Documentation)
• (GCP) Cloud Storage IAM에서 allUsers/allAuthenticatedUsers 바인딩 여부 점검 (Google Cloud Documentation)
• (Azure) 구독 Owner 수, 광범위 스코프 역할 부여 여부 점검 (Microsoft Learn)
• (Azure) PIM으로 JIT 전환 가능한 관리자 역할부터 전환. 비용·보안을 통합 관리하려면 FinOps 실전 가이드도 함께 확인 (Microsoft Learn)

---

IAM 권한 설계 FAQ

Q1. 최소 권한(Least Privilege)은 “처음부터 완벽하게” 해야 하나요?

완벽할 필요는 없지만, IAM 권한 설계 실수를 줄이려면 방향은 반드시 최소 권한이어야 합니다. AWS도 초기에는 넓은 권한으로 시작할 수 있지만, 성숙해질수록 권한을 줄여 최소 권한으로 가라고 설명합니다. (AWS Documentation)

Q2. 와일드카드(*)는 무조건 나쁜가요?

“항상 나쁜 것”은 아니지만, 위험도가 커서 기본값으로 쓰면 사고가 납니다.
AWS는 Resource에 *가 필요한 권한이 일부 존재하지만, 필요한 경우에만 사용하라고 안내합니다. (AWS Documentation)
Azure도 커스텀 역할에서 wildcard 사용을 피하고 Actions/DataActions를 명시하라고 권고합니다. (Microsoft Learn)

Q3. AWS에서 권한을 줄이는 가장 빠른 방법은?

Access Analyzer의 “정책 검증”으로 위험한 정책을 잡고, CloudTrail 기반 “정책 생성”으로 실제 사용 권한에 맞게 줄이는 흐름이 현실적입니다. (AWS Documentation)

Q4. GCP에서 서비스 계정 키 파일(JSON)을 깃헙에 올리면 왜 치명적인가요?

서비스 계정 키는 그 자체로 인증 수단이며, 유출 시 해당 서비스 계정으로 API 호출이 가능해질 수 있습니다. Google Cloud는 키를 리포지토리에 올리지 말 것, 정기 회전/만료, 미사용 키 식별 등 구체적인 관리 지침을 제공합니다. (Google Cloud Documentation)

Q5. GCP는 왜 Workload Identity Federation을 자꾸 권장하나요?

키를 배포/보관/회전하는 부담을 줄이고, 외부 IdP 기반으로 단기 토큰을 쓰는 “키리스 접근”을 가능하게 하기 때문입니다. Google Cloud는 WIF가 서비스 계정 키를 대체할 수 있다고 설명합니다. (Google Cloud)

Q6. Azure에서 PIM을 쓰면 뭐가 달라지나요?

관리자 권한을 “상시 보유”하지 않고, 필요할 때만 시간 제한(JIT)으로 활성화해 특권 노출 시간을 줄이고 가시성을 높이는 방향입니다. Azure RBAC 모범사례와 Entra 역할 모범사례 모두 PIM을 권장합니다. (Microsoft Learn)

Q7. Azure에서 Managed Identity를 쓰는 이유는 뭔가요?

앱이 자격증명을 코드/설정에 저장하지 않게 만들어 “시크릿 유출” 리스크를 줄이는 방향입니다. Microsoft 문서에서도 Managed Identity로 Key Vault 등 리소스에 접근할 수 있다고 설명합니다. (Microsoft Learn)

---

AX 100배의 법칙 – 나와 조직의 능력을 100배 높이는 AI 경영의 실제 도서 구매

함께 읽으면 좋은 글:

디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매

(adsbygoogle = window.adsbygoogle || []).push({});

. .

멀티클라우드 vs 하이브리드, 요즘 어디를 가도 이 논의가 빠지지 않습니다.
하지만 현실에서 이 두 전략은 트렌드가 아니라 ‘제약 조건(요건)’의 결과물입니다.

• 요건이 없는데 멀티클라우드를 하면 → 운영 복잡도만 늘고, 비용도 올라가고, 속도도 떨어집니다.
• 요건이 있는데 단일 클라우드를 고집하면 → 규제/지연/리스크/레거시 때문에 결국 뒤늦게 더 비싼 방식으로 땜질하게 됩니다.

이 글은 멀티클라우드 vs 하이브리드 중 “누가 더 좋다”가 아니라, 어떤 요건이면 무엇을 선택해야 후회가 적은지를 딱 정리합니다.

---

1) 멀티클라우드 vs 하이브리드 용어 정리: 두 개념은 축이 다르다

하이브리드 클라우드(Hybrid Cloud)

NIST는 하이브리드 클라우드를 서로 다른 2개 이상의 클라우드 인프라(예: 프라이빗/퍼블릭 등)가 ‘독립적으로’ 존재하면서도, 데이터·애플리케이션 이동(포터빌리티)을 가능케 하는 기술로 ‘연결’된 구성으로 정의합니다. (NIST Computer Security Resource Center)

그리고 미국 연방 CIO Council 가이드에서는 하이브리드 클라우드를 퍼블릭 클라우드 + 프라이빗 클라우드 + 온프렘(온프레미스) 인프라의 ‘의도적 통합’으로 정의하면서, 멀티클라우드는 온프렘 인프라를 포함하지 않는다고 선을 긋습니다. (CIO.gov)

멀티클라우드(Multi-cloud)

같은 가이드에서 멀티클라우드는 “여러 CSP(클라우드 서비스 제공자)의 서비스를 ‘의도적으로’ 통합”하는 것으로 정의하며, “그냥 여기저기 붙인 패치워크”는 진짜 멀티클라우드로 보지 않는다고 말합니다. (CIO.gov)
NSA(미국 국가안보국)도 멀티클라우드를 서로 다른 CSP의 여러 서비스를 함께 사용하는 환경으로 설명합니다.

결론: “하이브리드”와 “멀티클라우드”는 경쟁 개념이 아니라, 축이 다르다

• 하이브리드 = 온프렘(프라이빗) 포함 여부가 핵심
• 멀티클라우드 = CSP(퍼블릭 클라우드) 다중 사용 여부가 핵심

그리고 현실에서는 둘을 동시에 하는 조직도 많습니다. NSA도 조직이 “하이브리드 또는 멀티클라우드, 혹은 둘 다”를 쓰게 되는 경우가 많다고 말합니다.

---

2) 멀티클라우드 vs 하이브리드 2×2 선택 프레임

	CSP 1개면 충분	CSP 2개 이상이 ‘필수’
온프렘(프라이빗) 필요 없음	단일 클라우드(멀티리전/멀티AZ)대부분 조직의 기본값 (AWS vs Azure vs GCP 비교 참고)	멀티클라우드“특정 기능/리스크” 요건이 있을 때
온프렘(프라이빗) 필요함	하이브리드레거시/지연/데이터 레지던시 요건	하이브리드 멀티클라우드가장 비싸고 가장 복잡(정말 ‘요건’일 때만)

이 표의 장점은 단순합니다.
회의에서 “멀티클라우드 vs 하이브리드 — 우리는 왜 필요한가?”가 감정 싸움이 아니라 체크박스가 됩니다.

---

3) 멀티클라우드 vs 하이브리드 요건 8가지로 판단하기

아래 8개 중 ‘Must(필수)’가 하나라도 있으면 멀티클라우드/하이브리드를 검토할 이유가 생깁니다.
반대로 필수 요건이 없으면, 단일 클라우드(멀티리전/DR) 쪽이 거의 항상 더 빠르고 싸고 안전합니다.

---

요건 1) 규제/데이터 레지던시: “어떤 데이터는 반드시 내부/특정 위치에”

• 고객정보/주민정보/의료/금융 등에서 데이터 위치 제한이 있으면, 온프렘 유지가 필요해 하이브리드로 기울기 쉽습니다. (하이브리드는 “온프렘을 유지하며 클라우드로 확장”하는 전형적 이유로 자주 등장합니다.) (CIO.gov)

판단 팁

• “전체 데이터”가 아니라 데이터 등급별(티어별)로 나눠서:
  • Tier 0(절대 외부 반출 불가) → 온프렘/프라이빗
  • Tier 1(암호화/통제 하에 가능) → 퍼블릭 가능
  • Tier 2(일반) → 퍼블릭 우선

---

요건 2) 지연/엣지/공장·매장: “클라우드에 보내면 늦는다”

지연(latency) 때문에 로컬에서 처리해야 하면 하이브리드가 현실적인 답이 됩니다.

• AWS는 Outposts를 AWS 인프라/서비스/API/도구를 고객 온프렘에 확장하는 “완전관리형 서비스”로 설명하며, 저지연·로컬 데이터 처리/저장 같은 요구를 대표 이유로 듭니다. (AWS Documentation)

---

요건 3) 레거시/대규모 전환 비용: “다 못 옮긴다”

CIO Council 가이드는 하이브리드의 강점으로 레거시 애플리케이션을 온프렘에 유지하면서 나머지를 현대화할 수 있다고 설명합니다. (CIO.gov)
즉, “올클라우드”가 전략적으로 맞더라도 순서는 하이브리드가 되는 경우가 많습니다.

---

요건 4) 복원력(리질리언스) / 공급자 리스크: “한 곳이 멈추면 끝나는 구조는 안 된다”

여기서 많이 헷갈리는 포인트가 있습니다.

• 단일 클라우드 멀티리전만으로도 많은 DR 요구를 만족합니다. (자세한 내용은 재해복구 DR 전략 가이드 참고)
• 그럼에도 “정책상/계약상/사업 리스크상” CSP 자체를 분산해야 한다면 → 멀티클라우드(특히 중복형/레던던트)가 됩니다.

CIO Council 가이드는 멀티클라우드/하이브리드 모두에서 아키텍처 유형을 ‘Composite(분산 배치)’와 ‘Redundant(중복 배치)’로 나누어 설명합니다. (CIO.gov)

• Composite: 서비스/업무를 나눠 A는 AWS, B는 Azure 같은 방식
• Redundant: 같은 애플리케이션을 여러 환경에 두어 장애 시 페일오버

현실 팁: “레던던트 멀티클라우드”는 비용과 운영 난이도가 급상승합니다.
Tier 0(결제/로그인/핵심 API)처럼 정말 필요한 일부에만 적용하는 게 일반적으로 안전합니다.

---

요건 5) 특정 클라우드의 ‘독점 기능’이 비즈니스 성과를 만든다

예:

• 데이터/AI는 GCP가 유리,
• Microsoft 365/Entra/Windows/SQL 생태계는 Azure가 유리,
• 특정 인프라/서비스는 AWS가 유리…

이런 상황에서 멀티클라우드의 가장 합리적 형태는 보통 Composite 멀티클라우드입니다. (한 서비스에 여러 클라우드를 억지로 섞기보다, “업무 단위로 분리”)

---

요건 6) 운영/보안 거버넌스: “한 화면에서 통제해야 한다”

멀티클라우드/하이브리드의 핵심 비용은 클라우드 비용이 아니라 운영 복잡도 비용입니다.

NSA는 하이브리드/멀티클라우드에서 발생하는 공통 복잡도로

• 벤더별 운영 학습
• 클라우드 간 데이터 흐름 유지
• 사용자 접근 통제
• 통합 가시성 부족
• 컴플라이언스 유지
• 보안 전문성 부족
  같은 항목을 직접 나열합니다.

즉, “요건”이 아니라 “기분”으로 멀티클라우드를 시작하면 이 복잡도가 그대로 부채가 됩니다.

---

요건 7) 인력/조직 역량: “운영 가능한가?”

CIO Council 가이드는 하이브리드에서 교육/채용 비용 증가, 숙련 인력 풀이 제한이라는 약점을 명확히 적습니다. (CIO.gov)
또한 멀티클라우드/하이브리드에서는 관리 도구가 늘수록 보안 공백 위험이 커질 수 있다는 경고도 합니다. (CIO.gov)

판단 팁

• 플랫폼팀(Cloud Center of Excellence/Platform Engineering)이 없다면
  “멀티클라우드 = 인력 2배”가 아니라, 장애 대응 난이도 3~5배가 됩니다.

---

요건 8) 비용(특히 데이터 이동): “클라우드가 2개면 청구서도 2개가 아니다”

멀티클라우드/하이브리드에서 비용이 커지는 대표 이유는

• 데이터 이동(클라우드 간, 온프렘↔클라우드)
• 중복 운영(로그/보안/모니터링/백업)
• 중복 환경(레던던트)
  입니다.

그래서 비용 최적화 관점에서는 “데이터를 어디에 두고, 어디에서 처리할지”를 먼저 고정해야 합니다. 비용 관리 방법은 클라우드 비용 최적화(FinOps) 가이드에서 자세히 다룹니다.

---

4) “선택”이 아니라 “설계”의 문제로 바꾸는 3가지 질문

회의에서 아래 3가지를 먼저 합의하면, 멀티클라우드/하이브리드는 감이 잡힙니다.

1. 온프렘을 남겨야 하는 ‘법/정책/지연’ 요건이 있는가?
2. CSP를 2개 이상 써야 하는 ‘필수’ 요건이 있는가? (기능/리스크/계약)
3. 그 요건이 적용되는 범위는 ‘전체’인가, ‘일부 시스템(Tier 0~3)’인가?

범위가 “전체”가 아니라 “일부”라면, 정답은 보통 혼합형입니다.

• 코어 일부만 하이브리드/멀티클라우드
• 나머지는 단일 클라우드 표준화

---

5) 현실적인 도입 방식: “통제면부터 통합”하고, 워크로드는 천천히

멀티클라우드/하이브리드를 하는 조직들이 공통으로 겪는 고통은 “운영 도구가 찢어지는 것”입니다.
그래서 성공 확률이 높은 순서는 대체로 이렇습니다.

1단계: ‘통제면(Control Plane)’을 먼저 통합

예: 정책/거버넌스/자산 인벤토리/보안/운영을 한 방향으로 묶기

• Azure Arc는 온프렘·멀티클라우드·엣지 리소스를 Azure에 연결해, Azure에서 일관된 멀티클라우드/온프렘 관리 플랫폼으로 거버넌스·운영을 단순화한다고 설명합니다. (Microsoft Learn)
• Azure의 Cloud Adoption Framework 문서도 Azure Arc를 기반으로 하이브리드/멀티클라우드 아키텍처를 확장 가능하게 구현하고, 분산 환경 전반에서 거버넌스/보안/운영을 통합하는 접근을 설명합니다. (Microsoft Learn)

2단계: ‘하이브리드 기반’을 깔아두기(필요한 조직이라면)

• AWS는 하이브리드 클라우드를 “마이그레이션 진행, DR/비즈니스 연속성, 저지연, 글로벌 확장” 같은 목표에서 시작할 수 있다고 정리합니다. (AWS Documentation)
• AWS 하이브리드 가이드도 Outposts 같은 서비스를 통해 클라우드~온프렘~엣지까지 일관된 경험을 제공한다고 말합니다. (AWS Documentation)

3단계: 워크로드를 ‘도메인 단위’로 분리해 멀티클라우드 적용

여기서 중요한 원칙은:
“한 애플리케이션을 3개 클라우드에 걸쳐 쪼개지 말고, 도메인/업무 단위로 분리”입니다.
(레던던트 멀티클라우드는 정말 필요한 Tier 0만)

---

6) Kubernetes/플랫폼 레이어로 ‘중립화’하려는 경우의 현실

“쿠버네티스로 올리면 클라우드가 바뀌어도 쉬운 거 아닌가?”
이 질문의 정답은 “반은 맞고, 반은 틀립니다.” (관련 비교는 EKS vs AKS vs GKE 비용 비교 참고)

• 맞는 점: 배포 단위(컨테이너)와 일부 운영 방식이 표준화됩니다.
• 틀린 점: 네트워크, IAM, 로드밸런서, 데이터, 관측성, 보안, 비용 모델은 여전히 클라우드 종속입니다.

그래서 Google은 Anthos를 하이브리드/멀티클라우드 환경에서 일관된 애플리케이션 배포 플랫폼으로 소개합니다. (Google Cloud)
(단, 이런 “플랫폼 레이어”도 도입·운영 자체가 프로젝트가 되므로, 요건과 역량이 먼저입니다.)

---

7) 멀티클라우드 vs 하이브리드 도입 전 레드 플래그 7가지

아래 중 2개 이상이면, 멀티클라우드/하이브리드를 “전사 확산”하기 전에 범위를 줄이거나, 먼저 기반부터 다져야 합니다.

1. “우리가 왜 멀티클라우드를 하는지” 한 문장으로 말 못한다
2. RTO/RPO(복구 시간/복구 시점) 목표가 없다
3. 계정/구독/프로젝트 구조(조직 구조)가 정리돼 있지 않다
4. 통합 로그/모니터링/경보 체계가 없다
5. 태그/비용 귀속(쇼백/차지백)이 없다
6. 운영 자동화(IaC)가 없다
7. 멀티클라우드인데 보안/권한 체계가 “각자도생”이다 (NSA가 지적하는 대표 복잡도 중 하나가 접근 통제/가시성 부족입니다.)

---

8) 멀티클라우드 vs 하이브리드 결론: 요건의 조합이 정답이다

• 멀티클라우드 vs 하이브리드 판단에서 온프렘이 필요 없고, CSP도 1개면 된다 → 단일 클라우드(멀티리전/DR)
• 온프렘이 필요 없지만, CSP 2개가 ‘필수’다 → 멀티클라우드(대부분 Composite) (CIO.gov)
• 온프렘이 필요하고, CSP는 1개면 된다 → 하이브리드(Outposts/Arc 등으로 통제력 강화) (AWS Documentation)
• 온프렘도 필요하고, CSP도 2개 이상이 ‘필수’다 → 하이브리드 멀티클라우드(가장 비싸고 복잡하니, Tier 0 중심으로 제한)

---

자주 묻는 질문 (FAQ)

Q1. 멀티클라우드와 하이브리드의 가장 큰 차이는 뭔가요?

핵심은 축이 다릅니다.

• 하이브리드는 온프렘/프라이빗 + 퍼블릭을 섞는 개념(온프렘 포함 여부)이 핵심이고, NIST도 서로 다른 클라우드 인프라가 연결된 구성으로 정의합니다. (NIST Computer Security Resource Center)
• 멀티클라우드는 서로 다른 CSP를 2개 이상 쓰는 개념이 핵심입니다. (CIO.gov)

Q2. 하이브리드가 곧 멀티클라우드인가요?

아닙니다. CIO Council 가이드는 하이브리드를 온프렘까지 포함한 통합으로 정의하면서, 멀티클라우드는 온프렘 IT 인프라를 포함하지 않는다고 구분합니다. (CIO.gov)

Q3. “진짜 멀티클라우드”는 뭘 의미하나요?

CIO Council 가이드는 멀티클라우드를 여러 CSP 서비스를 ‘의도적으로 통합’한 것으로 정의하고, “패치워크처럼 임시로 붙인 구성”은 진짜 멀티클라우드로 보지 않는다고 말합니다. (CIO.gov)

Q4. 멀티클라우드/하이브리드의 가장 큰 단점은 뭐예요?

운영 복잡도입니다. NSA는 멀티 환경에서 벤더별 운영 학습, 클라우드 간 데이터 흐름, 접근 통제, 통합 가시성 부족, 컴플라이언스 유지, 보안 전문성 부족 같은 어려움을 직접 나열합니다.

Q5. AWS Outposts는 하이브리드에 어떤 의미가 있나요?

AWS는 Outposts를 AWS 인프라/서비스/API/도구를 온프렘으로 확장하는 완전관리형 서비스로 설명하며, 저지연·로컬 데이터 처리/저장 같은 하이브리드 요구를 대표 이유로 듭니다. (AWS Documentation)

Q6. Azure Arc는 멀티클라우드에도 쓸 수 있나요?

Microsoft는 Azure Arc가 온프렘·멀티클라우드·엣지 리소스를 Azure에 연결해 일관된 멀티클라우드/온프렘 관리 플랫폼을 제공한다고 설명합니다. (Microsoft Learn)
또한 Azure Arc 기반의 하이브리드/멀티클라우드 랜딩존 접근도 공식 문서로 제공됩니다. (Microsoft Learn)

Q7. Anthos는 어떤 조직에 의미가 있나요?

Google은 Anthos를 하이브리드/멀티클라우드 환경에서 일관된 애플리케이션 배포/현대화 플랫폼으로 소개합니다. (Google Cloud)
다만 플랫폼 레이어 도입 자체가 프로젝트이므로 “요건(필수)”과 “운영 역량”을 먼저 확인하는 게 안전합니다.

AX 100배의 법칙 – 나와 조직의 능력을 100배 높이는 AI 경영의 실제 도서 구매

함께 읽으면 좋은 글:

디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매

(adsbygoogle = window.adsbygoogle || []).push({});

. .

재해복구 DR 전략을 세울 때 가장 흔한 실패는 이거예요.

기술(스냅샷, 복제, 이중화)부터 고르고
나중에 “우리 RTO/RPO가 뭐였지?”를 묻는 것.

반대로 성공하는 팀은 순서가 정반대입니다.

1. 업무가 버틸 수 있는 시간/데이터 손실 한계를 먼저 정하고(RTO/RPO)
2. 그 목표를 만족하는 DR 전략(아키텍처)을 고르고
3. 마지막에 도구/서비스(AWS/Azure/GCP)를 끼워 넣습니다.

오늘 글은 이 “역산 설계”를 그대로 따라갈 수 있게 만든 실무 가이드입니다.

---

1) RTO/RPO/MTD: 재해복구 DR 전략의 핵심 용어 정리

RTO(Recovery Time Objective)

NIST 용어집 기준으로 RTO는 “복구 단계에 있을 수 있는 전체 시간(그 이상이면 조직의 미션/업무에 악영향)”을 뜻합니다. (NIST Computer Security Resource Center)

RPO(Recovery Point Objective)

NIST 용어집 기준으로 RPO는 “장애 이후 데이터가 복구되어야 하는 시점(포인트)”입니다. 쉽게 말해 “얼마나 과거까지 롤백해도 괜찮나”예요. (NIST Computer Security Resource Center)

MTD(Maximum Tolerable Downtime)

NIST SP 800-34에서는 MTD를 “업무/미션 중단을 조직이 감내할 수 있는 총 시간”으로 설명합니다. (NIST Publications)
실무적으로는 이런 관계로 이해하면 편합니다.

• MTD(조직이 버틸 수 있는 최대치) ≥ RTO(IT가 목표로 하는 복구 시간)
• RTO는 MTD를 만족시키기 위한 “IT 측 목표치”로 잡는 경우가 일반적입니다. (NIST Publications)

---

2) 백업 vs DR vs 고가용성(HA): 재해복구 설계의 첫 구분

Azure의 개념 문서는 BCDR 맥락에서 RTO/RPO를 정의하면서, 비즈니스 연속성/고가용성/재해복구를 구분해 설명합니다. (Microsoft Learn)
이를 실무 언어로 바꾸면 이렇습니다.

• 백업(Backup): 데이터 되돌리기(랜섬웨어/실수 삭제/데이터 손상에 강함). 보통 RTO가 길어질 수 있음. DB 백업 전략은 관리형 DB 선택 가이드 참고.
• 고가용성(HA): “죽지 않게” 버티기(단일 장애/존 장애 등). RTO는 짧지만 ‘데이터 논리 오류’는 그대로 복제될 수 있음.
• DR(재해복구): “큰 사고(리전 장애/대규모 장애)에서도 서비스 재개”가 목표. RTO/RPO 목표를 만족시키도록 전체를 준비.

정리하면, HA는 ‘멈춤 최소화’, 백업은 ‘되돌리기’, DR은 ‘재시작 계획’입니다. 셋은 서로 대체가 아니라 조합이에요.

---

3) RTO/RPO를 어떻게 정할까: DR 전략 수립 5단계

Azure Well-Architected(재해복구 전략) 문서는 업무 가치와 기대치에 맞춰 명확한 RTO/RPO 타깃을 도출하라고 안내합니다. (Microsoft Learn)
이걸 실무 플로우로 바꾸면 아래 5단계가 가장 무난합니다.

1) 장애 시나리오를 3개로 고정한다

RTO/RPO는 “무슨 사고” 기준인지가 없으면 의미가 흐려집니다.

• 시나리오 A: 데이터 손상/오삭제/랜섬웨어(복구 포인트가 중요)
• 시나리오 B: 단일 리전 장애(다른 리전에서 서비스 재개)
• 시나리오 C: 클라우드/네트워크 대규모 장애(대체 경로/수동 운영까지 포함)

2) 시스템을 “업무 중요도 티어”로 나눈다

예: Tier 0(결제/로그인), Tier 1(핵심 API), Tier 2(리포트/배치), Tier 3(내부관리).

3) 티어별로 RTO/RPO를 숫자로 박는다(예: 15분/1시간/24시간)

정성(“빠르게”)이 아니라 정량(“30분”)으로 고정해야 아키텍처가 정해집니다.

4) “현재 우리 실력”으로 가능한 실제 RTO/RPO를 측정한다

대부분 여기서 갭이 나옵니다.
문서상의 RTO/RPO가 아니라 실제로 복구해본 RTO/RPO를 기준으로 해야 합니다.

5) 갭을 비용으로 환산해 “구간 선택”을 한다

RTO/RPO를 줄일수록(더 빡세질수록) 비용이 늘어납니다.
그래서 아래 DR 전략 4단계(모델) 중 어디로 갈지 결정하게 됩니다.

---

4) RTO/RPO에 따라 DR 전략은 4단계로 갈린다

AWS는 클라우드 DR 옵션을 Backup & Restore → Pilot Light → Warm Standby → Multi-site Active/Active 형태의 단계로 정리해 설명합니다. (AWS Documentation)
(이 4단계는 업계에서 가장 널리 쓰이는 DR 모델이기도 합니다.)

아래 표는 실무에서 “설계 판단”에 바로 쓰기 좋게 정리한 버전입니다.

RTO/RPO 목표별 추천 DR 모델(실무용 맵)

목표 수준(예시)	RTO	RPO	추천 DR 전략	비용/운영 난이도
1단계: 복구가 느려도 됨	8~48시간	4~24시간	Backup & Restore (AWS Documentation)	비용↓ / 운영↓
2단계: “서비스는 살려야”	1~4시간	15~60분	Pilot Light (Amazon Web Services, Inc.)	비용↗ / 운영↗
3단계: “꽤 빨리” 복구	10~60분	1~15분	Warm Standby (AWS Documentation)	비용↑ / 운영↑
4단계: 거의 무중단에 가까움	수분~수십분	수초~수분	Multi-site Active/Active (Amazon Web Services, Inc.)	비용↑↑ / 운영↑↑

숫자 구간은 “흔한 예시”이고, 실제는 워크로드/조직 역량에 따라 달라집니다.
중요한 건 RTO/RPO가 빡셀수록 ‘항상 켜져 있는 것’이 많아져서 비용이 급상승한다는 점입니다.

---

5) RTO/RPO로 역산하는 재해복구 DR 설계 공식

RPO 설계 공식: “데이터 보호 주기”를 먼저 정한다

• RPO가 15분이면: 최소 15분보다 촘촘한 백업/복제가 있어야 합니다.
• RPO가 0에 가까우면: 동기(또는 준동기) 복제 + 설계적 일관성까지 고려해야 합니다(난이도와 비용이 확 올라갑니다).

RTO 설계 공식: “복구 절차의 합”이 RTO를 만든다

RTO는 그냥 “서버 켜는 시간”이 아니라 보통 아래 합입니다.

• 장애 감지/선언 시간 + 사람 호출/승인 시간
• 인프라 기동 시간(네트워크/컴퓨트/DB)
• 데이터 복구/재동기화 시간
• 애플리케이션 배포/설정 적용 시간
• 트래픽 전환(DNS/LB) + 검증(스모크 테스트) 시간

정리하면, RTO를 줄이려면:

• 사람 의존(수동)을 줄이고 자동화해야 하고
• 항상 준비된 리소스(웜/핫)가 많아져야 합니다.

---

6) 랜섬웨어·오삭제까지 고려한 백업 DR 전략 핵심 3가지

DR을 설계할 때 요즘은 “리전 장애”만 보면 반쪽짜리입니다.
실제 사고는 랜섬웨어/권한 탈취/실수 삭제가 더 자주 터지니까요.

1) 백업은 ‘불변(Immutable)’이 되어야 한다

AWS Backup의 Vault Lock 문서는 일정 시점 이후 백업 볼트가 immutable(변경/삭제 불가)가 된다고 설명합니다. (AWS Documentation)
즉, “백업이 있어도 공격자가 지우면 끝”인 문제를 줄이는 장치입니다.

2) 백업은 단일 리전에만 두지 않는다(교차 리전/교차 계정)

AWS Backup은 교차 리전 백업 복사(cross-Region copy) 설정 흐름을 공식 문서로 제공합니다. (AWS Documentation)
실무에서는 “운영 계정과 다른 계정에 백업을 보관”하는 형태를 많이 씁니다(권한 사고 격리).

3) “백업 시스템 자체”도 DR 관점으로 본다

Google Cloud의 Backup and DR Service는 중앙 관리형 백업/복구 서비스이며, 악의적 또는 우발적 삭제로부터 백업 데이터를 보호한다고 설명합니다(단일/멀티리전 언급 포함). (Google Cloud)

---

7) 클라우드별 재해복구 DR 구현 예시: AWS·Azure·GCP

여기서는 “RTO/RPO 목표”를 먼저 두고 클라우드별로 어떤 서비스 조합이 자연스러운지 예시를 들어볼게요. AWS·Azure·GCP 전반적인 비교는 AWS vs Azure vs GCP 비교 2026을 참고하세요.

---

예시 1) RTO 24시간 / RPO 24시간: “가장 현실적인 저비용 시작점”

추천 모델: Backup & Restore

• 핵심: 백업 주기(=RPO) + 복구 절차(=RTO) 문서화
• 장점: 비용이 낮고 시작이 쉽다.
• 단점: 복구는 느릴 수 있다.

구현 포인트

• 백업 스케줄/보관 정책
• 복구 리허설(정기 테스트)로 “진짜 RTO”를 측정
• 백업 불변성(Vault Lock 등) 검토 (AWS Documentation)

---

예시 2) RTO 1시간 / RPO 5~15분: “대부분 SaaS가 여기서 승부”

추천 모델: Warm Standby 또는 Pilot Light + 빠른 데이터 복제

AWS/Azure 모두 이 구간에서 “복제 기반 DR” 서비스가 실무적으로 자주 선택됩니다.

• AWS Elastic Disaster Recovery(DRS)는 “RPO seconds, RTO minutes”를 전면에 내세웁니다. (Amazon Web Services, Inc.)
• Azure Site Recovery(ASR)는 조직의 RTO/RPO 목표를 맞추는 데 도움을 주며, Hyper-V의 경우 복제 주기가 30초까지 낮아질 수 있다고 설명합니다(대상/구성에 따라 다름). (Microsoft Learn)

포인트: 이 단계부터는 “백업만”으로는 RPO를 맞추기 어려워져서, 지속 복제(continuous replication) 같은 접근이 들어오는 경우가 많습니다. (Microsoft Learn)

---

예시 3) RTO 수분~수십분 / RPO 수초~수분: “진짜 DR이 비싸지는 구간”

추천 모델: Multi-site Active/Active

AWS는 이 전략을 “두 개 이상의 독립된 사이트에서 동시에 요청을 처리하는 Active/Active”로 설명합니다. (Amazon Web Services, Inc.)

이 구간의 현실

• 비용이 급증합니다(리소스를 “두 군데에서 상시 운영”).
• 운영 난이도가 크게 올라갑니다(데이터 일관성/충돌/분산 트랜잭션/관측성 등).
• 그래서 보통 Tier 0 일부(예: 결제/인증)만 Active/Active로 가고, 나머지는 Warm Standby로 섞는 “혼합형”이 많습니다.

---

8) RTO/RPO 기반 재해복구 DR 설계 템플릿

(1) 워크로드별 목표 정의 표

시스템	중요도	장애 시나리오	목표 RTO	목표 RPO	현재 RTO/RPO	갭(리스크)	선택 전략
결제	Tier 0	리전 장애	15분	1분	2시간/15분	큼	Warm/Active
로그인	Tier 0	권한 탈취	30분	5분	미측정	큼	Backup+불변
관리자	Tier 2	리전 장애	24시간	24시간	12시간/24시간	작음	Backup&Restore

(2) DR 실행(runbook) 최소 구성

• 장애 선언 기준(누가/언제/어떤 조건에서)
• 복구 절차 단계(순서가 핵심): 데이터 → 앱 → 트래픽 → 검증
• 롤백/재난 해제 절차
• 테스트 계획(분기 1회, 최소 연 2회는 권장)

---

9) 비용을 낮추면서 RTO/RPO를 줄이는 6가지 레버

1. 티어링: 전 시스템을 Tier 0로 만들지 말기(비용 폭탄 방지 — 클라우드 비용 최적화(FinOps) 입문 참고) (Microsoft Learn)
2. 혼합형 DR: 핵심만 Warm/Active, 나머지는 Backup/Pilot
3. 자동화: 수동 승인/수동 배포 제거(사람이 RTO를 늘립니다)
4. 트래픽 전환 설계: DNS/LB 전환을 문서화하고 반복 훈련
5. 백업 불변성/격리: 랜섬웨어 대응(삭제 불가 + 다른 계정/리전) (AWS Documentation)
6. 테스트로 측정: 목표 RTO/RPO는 “종이”가 아니라 “리허설 결과”로 관리

---

자주 묻는 질문 (FAQ)

Q1. RTO와 RPO 차이를 한 문장으로 말하면?

• RTO는 “얼마나 빨리 서비스/시스템을 복구해야 하는가”이고, NIST 정의로는 “복구 단계에 있을 수 있는 전체 시간”입니다. (NIST Computer Security Resource Center)
• RPO는 “얼마나 최근 시점까지 데이터가 복구돼야 하는가”이며, NIST 정의로는 “장애 후 데이터가 복구되어야 하는 시점”입니다. (NIST Computer Security Resource Center)

Q2. MTD는 뭐고 왜 필요하죠?

NIST SP 800-34는 MTD를 “업무 중단을 감내할 수 있는 총 시간”으로 설명합니다. (NIST Publications)
RTO는 보통 이 MTD를 넘지 않게 잡는 IT 목표치라서, 경영진/업무부서와 합의할 때 MTD가 기준점이 됩니다.

Q3. DR 전략(Backup/Pilot/Warm/Active-Active)은 뭘 기준으로 고르나요?

AWS는 클라우드 DR 옵션을 Backup & Restore, Pilot Light, Warm Standby, Multi-site Active/Active로 정리해 설명합니다. (AWS Documentation)
실무에서는 목표 RTO/RPO가 빡셀수록 더 “항상 준비된(상시 운영)” 자원이 필요해서 비용이 증가합니다.

Q4. 백업만 잘하면 DR은 필요 없나요?

보통은 아닙니다. 백업은 데이터 복구에 강하지만, 서비스 재개(RTO)를 빠르게 보장하려면 복제/대기 환경/자동 전환 등 DR 설계가 필요합니다. (BCDR에서 RTO/RPO를 기준으로 전략을 고르라고 하는 이유가 여기 있습니다.) (Microsoft Learn)

Q5. 클라우드에서 RTO/RPO를 빨리 맞추는 서비스 예시가 있나요?

• AWS Elastic Disaster Recovery는 “RPO seconds, RTO minutes”를 내세웁니다. (Amazon Web Services, Inc.)
• Azure Site Recovery는 복제를 통해 목표 RTO/RPO를 맞추는 데 도움을 주며, Hyper-V 복제 주기가 30초까지 가능하다고 설명합니다. (Microsoft Learn)

Q6. 랜섬웨어까지 고려하면 무엇이 핵심인가요?

백업이 “있다”보다 백업이 지워지지 않는다(불변성)가 중요해졌습니다. AWS Backup Vault Lock은 일정 시점 이후 백업 볼트를 변경/삭제할 수 없게 하는 불변성을 설명합니다. (AWS Documentation)
Google Cloud Backup and DR Service도 백업 데이터의 악의적/우발적 삭제 방지를 강조합니다. (Google Cloud)

---

AX 100배의 법칙 – 나와 조직의 능력을 100배 높이는 AI 경영의 실제 도서 구매

함께 읽으면 좋은 글:

디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매

(adsbygoogle = window.adsbygoogle || []).push({});

. .

AI 에이전트 카오스가 시작됐습니다. 2022년 ChatGPT의 등장이 단순한 질문-답변의 시대를 열었다면, 2026년은 자율 AI 에이전트가 우리의 받은편지함, 계약서, 일정, 코드까지 직접 관리하는 시대로 접어들었습니다. 그 한가운데에 있는 두 이름이 바로 Anthropic의 Claude Cowork와 오픈소스 진영의 OpenClaw입니다.

(본 글은 AI 에이전트 수준 검증을 위해 100% AI로 작성된 글입니다. 내용에 대해 살펴보시지요)

---

1. AI 에이전트 시대의 시작점: ChatGPT에서 OpenClaw까지

“2022년 ChatGPT와의 순진한 질의응답에서 시작된 것이 이제는 실존적 논쟁이 됐다.” 4년 만에 우리가 도달한 자리는 단순한 챗봇이 아니라, 사용자의 시스템에 직접 접근해 반복 업무를 수행하는 자율 에이전트의 시대입니다.

이 변화의 폭발점에는 두 사건이 겹쳐 있습니다. 하나는 Anthropic이 출시한 Claude Cowork — 법률 업무를 자동화하는 AI 에이전트 — 이고, 또 하나는 같은 시기에 GitHub에서 폭발적으로 확산된 OpenClaw입니다. AI 에이전트 카오스는 결국 기술적 가능성과 경제적 충격, 거버넌스 공백이 동시에 부딪치며 만들어진 결과물입니다. 젠슨 황의 CES 2026 키노트에서 강조된 Agentic AI 흐름이 본격 산업 충격으로 이어진 셈입니다.

---

2. OpenClaw 폭발적 성장: 48시간 만에 GitHub 100,000 stars

AI 에이전트 카오스의 기술적 상징은 단연 OpenClaw입니다. 오스트리아 개발자 Peter Steinberger가 2025년 11월 Clawdbot이라는 이름으로 처음 공개한 이 오픈소스 프로젝트는, Moltbot을 거쳐 OpenClaw로 리브랜딩한 뒤 짧은 기간 안에 GitHub 역사상 가장 빠른 성장세를 보였습니다.

2.1. 숫자로 보는 OpenClaw 확산 속도

• 2026년 3월 2일 기준 GitHub 스타 247,000개, 포크 47,700개
• 피크 구간 기준 100,000 스타 도달까지 48시간 미만 — GitHub 역사상 최단 기록 중 하나
• 로컬 머신에서 직접 실행되는 오픈소스 자율 AI 에이전트
• Telegram·Discord 같은 메시징 플랫폼이 주된 사용자 인터페이스

2.2. OpenClaw가 실제로 하는 일

OpenClaw가 매력적인 이유는 추상적인 데모가 아니라 실제 일상 업무를 자동화한다는 점입니다. 대표적인 활용 사례는 다음과 같습니다.

• 받은편지함 분류와 자동 회신
• 콘텐츠 큐레이션과 요약
• 여행 일정 계획과 예약 보조
• 로컬 시스템 접근이 필요한 반복 업무

도구에게 더 많은 권한을 줄수록 더 강력해지지만, 동시에 위험도 함께 커집니다. 결국 이 균형이 모든 도입 결정의 분기점입니다.

---

3. Anthropic Cowork와 SaaSpocalypse: 에이전트 AI의 시장 충격

Anthropic이 발표한 Claude Cowork는 계약서 검토와 NDA 분류 같은 법률 업무를 AI 에이전트에게 맡기는 서비스입니다. 발표 직후 시장의 반응은 즉각적이었습니다 — legal-tech와 SaaS(서비스형 소프트웨어) 업체들의 주가가 큰 폭으로 빠지면서 일부 매체는 이 사건을 SaaSpocalypse(사스 종말)라고 부르기 시작했습니다.

이번 사건이 단지 개발자 커뮤니티의 이야기가 아니라, 자본 시장과 산업 구조까지 흔드는 사건이라는 점이 확인된 순간입니다. SaaS 비즈니스 모델은 지난 10년간 IT 업계의 표준이었기 때문에, “AI 에이전트가 같은 일을 더 싸게 한다면 우리는 무엇을 팔아야 하는가”라는 질문은 더 이상 미룰 수 없게 됐습니다.

---

4. Anthropic의 OpenClaw 차단: 4월 4일 정오에 일어난 일

갈등이 한층 격해진 분기점이 2026년 4월 4일에 있었습니다. Anthropic은 같은 날 정오(태평양 시간) 이후 Claude 구독자가 OpenClaw를 비롯한 서드파티 하네스에 자신의 Claude 구독 한도를 사용할 수 없도록 정책을 변경했습니다.

4.1. 사용자 비용 최대 50배 증가

이 결정의 충격은 컸습니다. 그동안 Claude Code 구독료 안에서 OpenClaw를 함께 사용하던 수천 명의 사용자가, 하루아침에 별도 API 요금을 부담해야 했고, 일부 사용자는 월간 비용이 기존 대비 최대 50배까지 늘어나는 상황에 놓였습니다. Hacker News에 공유된 Anthropic 고객 이메일이 이 소식을 처음 확산시켰습니다.

4.2. 오픈소스 진영의 반발

OpenClaw 창시자 Peter Steinberger는 2026년 2월 OpenAI에 합류한 상태였는데, Anthropic의 결정을 두고 “오픈소스 개발자에 대한 배신”이라고 강하게 비판했습니다. 한쪽에서는 비용 통제를 명분으로(2026년 AI 트렌드 6가지도 함께 참고), 다른 쪽에서는 오픈 생태계의 자유를 명분으로, 이 갈등은 정책과 라이선스 싸움으로 빠르게 번지고 있습니다.

---

5. AI 에이전트 시장이 만드는 새로운 변종: NanoClaw, Claude Code Channels

OpenClaw 차단 이후 곧바로 새로운 시도가 등장했습니다. 보안 이슈를 보완한 NanoClaw는 OpenClaw의 가장 큰 보안 문제 중 하나를 해결했다고 알려졌고, Anthropic은 곧이어 Claude Code Channels를 발표해 Telegram과 Discord에서 직접 Claude에 메시지를 보낼 수 있도록 했습니다. 이는 사실상 OpenClaw의 핵심 가치 제안을 Anthropic이 공식 채널로 흡수한 형태입니다.

여기에 Claude Code 소스 유출 의혹까지 더해지면서, AI 에이전트 카오스는 단순한 기술 경쟁이 아니라 거버넌스, 보안, 비즈니스 모델이 동시에 흔들리는 복합 사건이 됐습니다.

---

6. 한국 IT 업계가 AI 에이전트 시대에 주목해야 할 5가지

이 변화는 미국 시장에서 시작됐지만, 한국 기업과 개발자에게도 의미가 작지 않습니다. 다음 5가지를 꼭 확인해 두시길 권합니다.

1. SaaS 비즈니스 재정의 — Cowork 사례는 “AI 에이전트가 같은 가치를 더 싸게 만들 수 있는 영역”을 시장이 즉시 가격에 반영한다는 신호입니다.
2. 법률·반복 업무 자동화 도입 — 계약 검토, NDA 분류 등은 한국 기업도 즉시 시도할 수 있는 영역입니다.
3. 구독 정책 리스크 — Claude·OpenAI 구독에 의존한 워크플로우는 정책 변경 한 번에 비용이 수십 배 늘 수 있습니다. 이중화 전략이 필요합니다.
4. 오픈소스 거버넌스 — OpenClaw처럼 중앙 통제가 없는 도구는 사내 도입 시 보안·법무 검토가 선행돼야 합니다.
5. 로컬 실행 에이전트의 부상 — 데이터 주권과 규제 측면에서 한국은 로컬 실행형 에이전트가 오히려 유리할 수 있습니다.

---

7. 에이전트 AI와 AGI: 정말 가까워졌을까

AGI(범용 인공지능) 도달에 대한 우려도 다시 떠오르고 있습니다. Claude Cowork와 OpenClaw처럼 시스템에 직접 접근하는 자율 에이전트가 등장하면서, “강력한 자율 에이전트가 곧 AGI에 가까워지는 것 아닌가”라는 질문이 더는 학계의 사변이 아니라 기업 의사결정 변수에 들어오기 시작했습니다.

다만 진짜 쟁점은 “AGI 도달 여부”(자세한 내용은 하사비스 vs 아모데이 AGI 전망 비교 참고)가 아니라, 지금 당장 발생하고 있는 일자리 영향과 거버넌스 공백입니다. 이 변화의 진짜 비용은 미래의 AGI가 아니라, 오늘의 SaaS·법률·고객지원 산업에서 이미 청구되고 있다는 진단입니다.

---

8. AI 에이전트 카오스 시대를 맞는 우리의 자세

정리하면 2026년의 AI 에이전트 시장은 세 가지 축으로 움직이고 있습니다. 첫째, OpenClaw 같은 오픈소스가 빠르게 확산되며 기술 진입 장벽을 낮추고 있고, 둘째, Anthropic의 정책 변경처럼 상용 사업자가 비용·통제 카드를 쥐고 흔들고 있으며, 셋째, SaaSpocalypse처럼 시장이 즉각 가격으로 반응하고 있습니다.

지금 한국 기업과 개발자에게 필요한 것은 어느 한쪽에 줄을 서는 결정이 아니라, 변화의 속도와 방향을 빠르게 학습하고 작은 단위로 실험을 시작하는 것입니다. 한 달 뒤에 어떤 도구가 표준이 될지 아무도 단언할 수 없는 시기일수록, 직접 만져보고 비교한 사람만이 다음 라운드에서 살아남을 수 있습니다. AI 에이전트 카오스는 이미 시작됐습니다.

---

AI 에이전트 카오스 FAQ: 자주 묻는 질문

Q1. OpenClaw는 정확히 어떤 도구인가요?

OpenClaw는 오스트리아 개발자 Peter Steinberger가 만든 오픈소스 자율 AI 에이전트입니다. 2025년 11월 Clawdbot이라는 이름으로 처음 공개됐고, 로컬 머신에서 직접 실행되며 Telegram·Discord 같은 메시징 플랫폼을 인터페이스로 사용합니다.

Q2. Claude Cowork와 OpenClaw는 경쟁 관계인가요?

출발점은 다릅니다. Claude Cowork는 Anthropic이 출시한 상용 법률 업무 자동화 에이전트이고, OpenClaw는 누구나 가져다 쓸 수 있는 오픈소스 프레임워크입니다. 다만 두 도구가 같은 사용자층을 두고 경쟁하면서, 결국 Anthropic이 OpenClaw에 대한 Claude 구독 사용을 차단하는 결정으로 이어졌습니다.

Q3. SaaSpocalypse는 무엇을 의미하나요?

Anthropic Cowork 발표 직후 legal-tech와 SaaS 기업들의 주가가 큰 폭으로 빠진 사건을 가리키는 신조어입니다. 이 사건이 자본 시장에 즉각 반영된 첫 사례로 평가됩니다.

Q4. 한국에서도 OpenClaw를 쓸 수 있나요?

오픈소스이므로 GitHub에서 누구나 내려받아 사용할 수 있습니다. 다만 사내 도입 시에는 데이터 보안, 사내 네트워크 정책, 그리고 사용 중인 LLM 제공자(예: Claude 또는 OpenAI)의 정책 변경 위험을 함께 검토하는 것을 권장합니다.

Q5. Anthropic이 OpenClaw 사용자를 다시 허용할 가능성은 있나요?

현재 시점 기준으로 Anthropic은 4월 4일 차단 정책을 유지하고 있습니다. 다만 이후 Claude Code Channels처럼 공식 채널을 확장하는 움직임이 있어, 향후 정책이 변동될 가능성은 열려 있습니다.

---

참고 글: Claude, OpenClaw and the new reality: AI agents are here — and so is the chaos (VentureBeat, 2026-04-06)

AX 100배의 법칙 – 나와 조직의 능력을 100배 높이는 AI 경영의 실제 도서 구매

함께 읽으면 좋은 글:

디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매

(adsbygoogle = window.adsbygoogle || []).push({});

. .

CES 2026 관전 포인트를 한 문장으로 요약하면, “AI가 더 이상 ‘기능’이 아니라 제품·서비스·산업 운영 방식 자체를 재설계하는 중심축으로 올라왔다”는 흐름입니다. CTA(Consumer Technology Association) 역시 이번 CES 2026을 AI, Robotics만이 아니라 Digital Health, Energy, Mobility, Enterprise, Quantum까지 함께 묶어 큰 그림을 제시했습니다.

그리고 전체적인 트렌드를 감 잡는 데는, 의외로 CES Innovation Awards 수상작 카테고리 분포가 직관적인 힌트가 됩니다. 전시는 방대하지만 “어디에 무게가 실렸는지”는 카테고리 숫자에서 먼저 보이기 때문입니다.

다만 CES는 워낙 전시가 크고 방대해서, 관심사에 따라 서로 완전히 다른 CES를 보게 됩니다. 저는 CES를 일종의 “코끼리” 같은 행사라고 생각합니다. 각자가 만지는 부위가 다르면 결론도 달라지니까요. 아래 관전 포인트는 지극히 개인적인 관점에서 정리한 것이며, 여러분이 다르게 보셨다면 그 또한 정답입니다.

---

CTA가 짚은 CES 2026의 확장 축: AI·로봇을 넘어 ‘산업 전반’으로

CTA가 CES 2026의 핵심 축으로 꼽은 영역은 다음과 같습니다.

• AI
• Robotics
• Digital Health
• Energy
• Mobility
• Enterprise
• Quantum

이 구성 자체가 시사하는 바는 명확합니다. CES가 ‘소비자 전자 전시’라는 프레임을 유지하면서도, 실질적으로는 산업·인프라·엔터프라이즈 의제를 점점 더 전면에 세우고 있다는 신호로 볼 수 있습니다.

---

CES Innovation Awards 카테고리로 보는 CES 2026의 무게 중심

카테고리별 수상한 기업이 많았던 주요한 카테고리 그리고 관심이 가는 수상작 카테고리(제공된 집계 기준)는 아래와 같습니다.

• AI: 46
• Digital Health: 41
• Smart Home: 31
• Vehicle Tech & Advanced Mobility: 27
• Home Appliances: 26
• Sustainability & Energy Transition: 25
• Robotics: 17
• XR & Spatial Computing: 12
• Beauty 10 / Fashion 7 / Pet & Animal Tech 6 / Food 5

이 숫자 분포만 봐도 CES 2026의 큰 그림이 어느 정도 드러납니다. AI가 가장 큰 축으로 올라선 상태에서, 원래부터 전통적인 많은 수상작들이 분포하였던 디지털 헬스·스마트홈 이외에도 모빌리티·에너지 전환이 강하게 동행하고, 로보틱스는 “데모”를 넘어 실사용 로드맵이 논의되는 단계로 확장되었다는 것을 볼 수 있었답니다.

---

CES 2026 관전 포인트 10가지 (개인 관점)

아래 1~8은 “관전 포인트”로, 9~10은 관전평이라기보다 CES를 통해 논의되거나 확인된 “현실적인 관점”으로 정리했습니다.

---

1) 생성형 AI → 에이전트 AI 전환: “말”보다 “일”을 하게 만드는가

CES 2026을 통해 확인한 올해 AI 트렌드는 AI 에이전트, 디지털 트윈, 온디바이스 AI입니다. 이는 작년까지는 대화형 생성형 AI가 중심이었다면 이를 넘어, 이제 무게중심이 “업무/생활 실행”으로 이동하고 있다는 것을 보여주었다는 점입니다.

전시 관점에서 핵심 체크포인트는 하나입니다. “앱/기기별 AI”가 아니라, 기기와 서비스를 가로지르는 개인 에이전트(디지털 트윈)가 얼마나 자연스럽게 오케스트레이션하는가입니다.

예를 들어 레노버는 Qira(개인 AI 슈퍼 에이전트/디지털 트윈) 콘셉트처럼, 개인의 여러 기기와 데이터를 묶어 실행까지 이어지는 구조를 전면에 내세웠습니다. 많은 가전회사들도 이러한 테마의 전시를 같이 진행하였는데요, 삼성전자에서 선보인 냉장고 데모에서 볼 수 있듯이 소비자가 말로하면 가전이 직접 실행하는 것이 아주 자연스러워졌다는 대목이었습니다.

---

2) 피지컬 AI/로보틱스: “데모용”을 넘어 “현장 투입” 로드맵이 있나

휴머노이드/로봇은 CES 2026에서 메인 어트랙션 급으로 올라왔고, 단순 시연을 넘어 생산·공급망·현장 투입 시점을 함께 제시하는 사례가 강하게 부각되었습니다. 이 대목의 압권은 바로 Boston Dynamics의 Atlas 공개와 DeepMind 협업 발표 같은 흐름은, 로보틱스가 “멋진 데모”에서 “현장 투입 가능한 산업”으로 넘어가는 분위기를 보여주었다는 부분이었습니다.

가정용에서도 LG 전자가 CLOiD를 ‘제로 레이버 홈’ 비전의 상징으로 전면 배치하면서, 로봇을 단품이 아니라 집안 워크플로를 움직이는 에이전트로 포지셔닝한 점이 인상적입니다. 물론 휴머노이드 로봇의 50% 이상이 중국 기업이었고, 유니트리를 포함하여 상당한 중국 기업의 로봇 제조 역량은 이번 전시에서 빼놓을 수 없는 위협의 요소로도 읽혀졌습니다.

---

3) 산업 AI·디지털 트윈: ‘소프트웨어 정의 공장/현장’이 주류로

Siemens는 CES 키노트/전시에서 Digital Twin Composer를 핵심 런치로 내세우며, 디지털 트윈과 실시간 실세계 데이터 연결(Omniverse 라이브러리 기반 시뮬레이션 포함)을 전면에 둡니다. “산업 AI 혁명”을 말이 아닌 제품/플랫폼으로 끌고 온 셈입니다.

이 흐름은 공장에만 머물지 않고 에너지·인프라로 확장됩니다. Commonwealth Fusion Systems·NVIDIA·Siemens가 디지털 트윈으로 핵융합 설비를 시뮬레이션하는 협력을 전한것처럼, 산업 AI가 “현실 세계 시스템”으로 깊숙이 들어간다는 맥락을 보여주었습니다.

---

4) 자율주행: ‘인지’에서 ‘추론(reasoning)’으로, 그리고 ‘오픈 생태계’로

NVIDIA는 CES에서 Alpamayo(오픈 모델·시뮬·데이터셋)를 전면에 두며 자율주행을 추론 기반(설명가능성 포함) 경쟁으로 끌어올렸습니다. 자율주행의 중심이 “보는 능력(인지)”에서 “판단의 논리(추론)”로 이동하는 흐름이 더 선명해졌다는 의미입니다.

또한 Mercedes‑Benz CLA에 AI-defined driving을 시연/적용하는 레퍼런스를 제시하면서, 완성차 OEM과 플랫폼 기업의 결합 구도도 한층 명확해졌습니다. 지금까지 테슬라가 폐쇄형 생태계를 지향하였다면 이번 엔비디아의 Alphamayo의 경우 iOS와 안드로이드에 대비될 정도로 자율주행에 있어 오픈 생태계의 등장을 알리는 신호탄이자 실제 이런 플랫폼이 적용된 자동차가 1Q에 출시할 정도로 현실적인 내용이 되었답니다.

---

5) 스마트홈/가전의 다음 단계: ‘Ambient AI(공간지능)’와 ‘AI 동반자’ 경쟁

삼성은 LVCC 대형 부스 대신 Wynn의 전용 공간에서 ‘Your Companion to AI Living’ 테마로 AI 동반자 경험(엔터테인먼트·홈·케어)을 큐레이션하는 전시 전략을 택했습니다. “제품 나열”보다 “경험 연출”에 방점을 찍은 방식입니다.

LG 역시 ‘Affectionate Intelligence(공감지능)’를 전면에 두고, CLOiD를 포함한 제로 레이버 홈을 동기화된 생태계로 보여주는 방식이었습니다.
결국 관전 포인트는 “AI가 기기마다 들어갔는가”가 아니라, 집이라는 공간에서 AI가 얼마나 자연스럽게 작동하는가(Ambient AI)로 이동하지 않았나 생각됩니다.

AI 기술이 상당 수준으로 올라오면서 스마트홈 역시 다시 활기를 되찾는 분위기를 엿볼 수 있었습니다. 기존 스마트홈의 부족한 2%를 AI가 채워주었다고 할까요? 앞으로 스마트홈 분야 또한 고객들에게 더 많이 침투되기를 기대해봅니다.

---

6) 스마트글라스/웨어러블 재부상: “AI의 새 폼팩터”가 되나

CES 2026에서는 AI 글라스가 단순 콘셉트를 넘어 제품·가격·모델(번역/요약/기록 등)로 구체화되는 전시가 늘었습니다. 예로 XGIMI MemoMind, Solos AirGo V2 같은 제품이 거론되었습니다.

또한 CTA가 Accessibility Stage에서 스마트글라스·로보틱스·음성 홈 어시스턴트 등을 다루도록 구성한 점 역시, 글라스가 “실사용 시장”으로 들어간다는 신호로 해석할 여지도 있는 것 같습니다.

---

7) 중국 기업 존재감: ‘숫자’보다 ‘프라임 스팟’과 ‘데모 밀도’가 관전 포인트

등록 기준 집계에서 중국은 942개 참가사, 한국은 853개로 소개됩니다(미국 다음 규모). 다만 CES 현장에서는 단순 참가 숫자만큼이나 전시장 내 위치(프라임 스팟)와 데모 밀도가 체감 존재감을 좌우합니다.

이를 대변하듯, 삼성의 LVCC 센트럴홀 이탈로 생긴 자리를 TCL이 빠르게 차지해 “AiMe Land”를 구성한 점은 전시장 권력 지형 변화를 보여주는 사례로 언급됩니다. 동시에 “로봇이 메인 어트랙션이 되었고 중국 쪽 혁신이 강했다”는 현장 관찰도 이어지며, 중국 기업의 존재감은 점점 더 “현장에서 체감되는 방식”으로 나타나는 흐름입니다.

원래부터 중국 기업들은 CES 현장을 B2B 영업의 장으로 잘 활용하고 있었습니다. 특히 South관처럼 중국색 일색이었던 전시 공간도 많았답니다. 그러나 최근 로봇뿐만 아니라 가전, 특히 로봇청소기나 드론과 같은 이미 글로벌 1등인 회사들이 주류로 등장하면서 중국 기업의 존재감은 이미 우리나라를 위협하고, 넘어서는 느낌을 지울 수가 없는 상황이 된 것 같습니다.

---

8) 산업현장/중장비까지 AI 확장: ‘물리 세계’ 자동화가 본류로

Caterpillar가 NVIDIA와의 확장 파트너십 및 Cat AI Assistant(음성 기반 인터페이스) 등을 발표하는 흐름은, CES가 더 이상 ‘소비자 기기’만의 무대가 아니라 산업·건설·중장비 자동화의 쇼케이스로 기능하고 있음을 보여줍니다.

즉, CES의 AI는 이제 “개인 생산성”에서 끝나지 않고, 물리 세계의 운영 자동화로 본류가 이동하고 있습니다. 이 또한 CES 2025까지도 계속된 흐름이었지만 이제 AI 기술의 성숙도가 산업현장의 변화를 더욱더 빠르게 이끌어 가겠다는 느낌이 들었습니다. 현장 작업자들도 이제는 일상에서 ChatGPT 등을 활용하면서 각자만의 AI에 대한 이미지를 가지고 있으니까요.

---

9) 엔터프라이즈 AI 도입의 병목: CFO vs CIO 갈등이 ‘공식 의제’가 됨

9번은 관전평이라기보다, CES를 통해 확인된 현실적인 관점 중 하나인데요. 생성형 AI가 본격화되면서 우리 기업에도 다양한 AX 활동이 진행되고 있는 것은 다들 공감하실 것입니다. 이러한 엔터프라이즈 AI 도입의 병목이 ‘기술’만이 아니라 ‘의사결정 구조’라는 점을 확인할 수 있었습니다.

CES 공식 키노트 세션에서도 McKinsey–General Catalyst 대담이 편성됐고, 실제로 “CEO가 CFO와 CIO 사이에서 무엇을 듣느냐” 같은 갈등 프레이밍이 논의 되었습니다. 이는 AI 투자가 경영의 아젠다가 되었으며, 단순한 IT 지출이 아니라, 비용·리스크·거버넌스·조직 운영을 동시에 건드리는 의제가 되었다는 뜻입니다.

이는 글로벌뿐만 아니라 우리나라에서도 이러한 현상을 다양한 곳에서 목격되고 있는 상황입니다. 원래 IT는 지원부서의 하나로 CEO 입장에서는 큰 이슈만 일으키지 않으면 된다는 인식을 가지고 있었지만 경영의 중심으로 AI가 들어오면서 이를 두고 디지털을 다루는 부서가 그 중심을 가져갈 것인지, 아니면 전통적인 경영자 측근이라 할 수 있는 HR, 전략, 재무 등에서 중심을 가져갈 것인지, 아니면 수익을 벌어들이니 각 회사의 본원적 경쟁력이라 할 수 있는 사업부서에서 그 중심을 가져갈 것인지가 논의를 넘어 조직 개편에 이르는 등 그 헤게모니 싸움이 본격화되고 있다는 부분입니다.

---

10) ‘AI 워싱’과 프라이버시 역풍: AI는 어디까지 ‘쓸모’가 있나

또 하나의 관점은 AI 워싱(AI Washing)과 프라이버시 역풍입니다. 소비자/프라이버시 단체가 ‘Worst in Show’로 AI 탑재 가전/도어벨/AI 컴패니언 등을 비판하는 흐름이 나오며, AI의 과잉 탑재와 데이터 수집이 리스크로 부상했습니다.

주요 미디어에서도 “AI가 뭐든지 붙는” 과열을 풍자하는 기사들이 나왔고, 이는 기업 입장에서 차별화(실용성)와 신뢰(프라이버시)를 동시에 증명해야 하는 압력이 될 수도 있을 것 같습니다. 그러나 분명한 것은 AI를 빼고 앞으로 나아갈 수는 없다는 점입니다.

---

정리: CES 2026의 큰 그림은 “에이전트·현장·신뢰”로 수렴한다

CES 2026을 관통하는 흐름을 제 방식으로 묶으면 다음 세 문장으로 정리됩니다.

• AI는 “대화”에서 “실행”으로 옮겨가며, 에이전트/디지털 트윈등 사용자 경험이 중심이 되고, 확장된다.
• 로보틱스·산업 AI·자율주행은 “데모”에서 “투입 로드맵”으로 이동하며, 현장(물리 세계) 자동화가 본류가 된다.
• 동시에 AI 워싱과 프라이버시 역풍이 커지면서, 기업은 실용성과 신뢰를 같이 증명해야 한다.

여러분의 CES 2026은 어떤 모습이었나요? 저도 다양한 리포트를 또 보면서 학습해 나가겠습니다.

---

AX 100배의 법칙 – 나와 조직의 능력을 100배 높이는 AI 경영의 실제 도서 구매

함께 읽으면 좋은 글:

디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매

(adsbygoogle = window.adsbygoogle || []).push({});

. .

CES 2026 AMD가 던진 한 문장: AI Everywhere for Everyone

CES는 늘 “다음 세대”를 미리 보여주는 무대였지만, CES 2026 AMD가 강조한 메시지는 유독 선명했습니다. AI는 더 이상 개념이나 실험실 데모가 아니라, 실제 산업과 일상에서 움직이며 작동하는 ‘움직이는 지능(intelligence in motion)’이 되었고, 그 변화의 속도는 이제 “가속”이라는 말로도 부족하다는 진단이었습니다.

기조연설에서 AMD CEO 리사 수(Lisa Su) 박사가 던진 핵심은 단순히 “AI가 중요하다”가 아니었습니다. AMD는 AI를 ‘누구나’ ‘어디서나’ 쓰게 만드는 컴퓨팅 기반을 만들겠다고 선언했고, 그 비전을 한 문장으로 압축한 표현이 바로:

“AI Everywhere for Everyone”

즉, 클라우드·PC·엣지(Edge)까지 모든 컴퓨팅 플랫폼에 AI를 통합해 AI를 보편화하겠다는 전략입니다. 그리고 이 비전은 말이 아니라 구체적인 하드웨어 로드맵(Helios/MI455, Ryzen AI 400)과 개방형 소프트웨어(ROCm), 그리고 산업 리더들과의 협력 사례(OpenAI, Luma AI, Blue Origin 등)로 연결되어 제시됐습니다.

---

왜 지금 ‘요타 스케일(Yotta Scale)’인가

CES 2026 AMD가 가장 강하게 밀어붙인 프레임은 “요타 스케일 컴퓨팅”입니다. 요지는 단순합니다. AI 사용자가 폭발적으로 늘면서, AI를 굴리는 ‘컴퓨팅 수요’가 기존 인프라의 상상을 벗어난 규모로 튀어 올랐다는 것.

• ChatGPT 이후 AI 사용자는 수백만 → 10억+으로 확대됐고
• AI가 휴대폰·인터넷처럼 필수 요소가 되면 활성 사용자는 50억+까지 갈 수 있으며
• 컴퓨팅 수요는 2022년 약 1 제타플롭(Zettaflop) → 2025년 100 제타플롭+로 커질 수 있다고 전망됩니다.
• 그리고 이 혁신 속도를 감당하려면 향후 5년 동안 10 요타플롭(Yotta Flops)+가 필요하다는 주장까지 연결됩니다.

여기서 “요타”는 숫자 감각을 깨뜨립니다. 1 요타플롭 = 1 뒤에 24개의 0이 붙는 연산 규모이고, 10 요타플롭은 2022년 대비 10,000배 수준이라는 설명이 이어집니다.

그래서 AMD의 결론은 이렇게 정리됩니다. AI를 어디에나 구현하려면 클라우드(전 세계 지능 공급) + PC(개인화·생산성) + 엣지(실시간 결정), 이 3축이 동시에 AI-ready가 되어야 하고, 이를 위해서는 GPU/CPU/NPU/맞춤형 가속기까지 전 스펙트럼의 컴퓨팅 엔진을 모두 갖춘 기업이 필요하다는 것. AMD는 바로 그 “풀 스택 컴퓨팅 엔진”을 자신들의 차별점으로 제시합니다.

---

클라우드 AI의 핵심: Helios 랙 스케일 + Instinct MI455

요타 스케일의 “본진”은 결국 클라우드입니다. 가장 큰 모델이 훈련되고, 수십억 사용자에게 지능이 전달되는 곳이기 때문입니다. AMD는 현시점에서의 포지셔닝도 함께 강조합니다.

• 주요 클라우드 제공업체들이 AMD EPYC CPU를 사용하고 있으며
• 상위 10개 AI 기업 중 8개가 Instinct 가속기로 모델을 구동하고 있다는 점을 전면에 둡니다.

그리고 이번 CES 2026에서 가장 큰 하드웨어 발표로 연결된 것이 바로 차세대 랙 스케일 플랫폼 ‘Helios’와 그 중심인 Instinct MI455(및 MI455X)입니다.

Helios가 노리는 것: 랙 단위를 ‘하나의 컴퓨터’로 만들기

AMD가 말하는 요타 스케일 AI 인프라의 조건은 3가지로 읽힙니다.

1. 세대 교체에 맞춰 진화 가능한 개방형·모듈식 랙 설계
2. 수천 개 가속기를 하나의 통합 시스템으로 묶는 고속 네트워킹
3. 배포가 쉬운 턴키(turnkey) 솔루션

Helios는 이 조건을 “랙 레벨”에서 구현한 플랫폼으로 소개됩니다.

MI455X 핵심 스펙(공개 내용 기준)

Helios의 시작점은 MI455X GPU입니다. 발표 내용의 숫자들은 매우 공격적입니다.

• 2nm 및 3nm 공정 기반
• 3,200억(320B) 트랜지스터 (MI355 대비 70% 증가)
• 12개의 2nm/3nm 컴퓨팅·I/O 칩렛
• 432GB HBM4
• 차세대 3D 칩 스태킹(3D chip stacking) 기반 연결

즉, “칩렛 + HBM4 + 3D 패키징”을 총동원해 대형 모델/대형 배치/대규모 병렬에 유리한 구조를 만들었다는 메시지입니다.

Venice EPYC(젠6) + Pensando 네트워킹까지 ‘트레이 단위’로 통합

Helios는 GPU만 던져놓는 설계가 아니라, EPYC CPU와 네트워킹 칩까지 컴퓨팅 트레이에 묶는 형태로 설명됩니다.

• Venice EPYC CPU: 2nm 공정, 최대 256개 Zen 6 코어
  • 이전 세대 대비 메모리 및 GPU 대역폭 2배로 랙 스케일에서 GPU에 데이터 공급을 극대화했다는 포지셔닝
• 네트워킹: 800GbE급 Pensando(Volcano, Selina 등 언급) 기반 초고대역폭·초저지연

“랙 안의 72개 GPU가 단일 컴퓨팅 장치처럼”

Helios 구조 설명에서 인상적인 포인트는 연결 방식입니다.

• 랙 내 72개 GPU가
• 이더넷 터널링 기반의 고속 초가속기 링크 프로토콜로 연결되어
• 단일 컴퓨팅 장치처럼 동작할 수 있다는 서술이 등장합니다.

또한 Helios 랙 여러 개(수천 개 규모)는 산업 표준 초이더넷 NIC와 Pensando 프로그래밍 가능 DPU로 연결되며, DPU가 GPU 작업 일부를 오프로드해 성능을 더 끌어올린다고 설명됩니다.

Helios 물리 설계: OCP 개방형 랙 와이드 표준 + Meta 협력

Helios는 Meta와 협력해 개발된 OCP(Open Compute Project) 개방형 랙 와이드 표준을 기반으로 하는 더블 와이드 설계로 소개되며, 랙 무게가 거의 7,000파운드에 달한다고 언급됩니다. 즉, 데이터센터 운영 관점에서 서비스 용이성·제조 용이성·신뢰성을 최적화하려는 방향이 강조됩니다.

성능 지표(발표 기준)

Helios 랙 한 대 기준으로 공개된 지표는 다음과 같이 정리됩니다.

• 18,000개+ CDNA5 GPU 컴퓨팅 유닛
• 4,600개+ Zen 6 CPU 코어
• 최대 2.9 엑사플롭스(Exaflops) 성능
• 랙당 31TB HBM4
• 260TB/s 스케일 대역폭

그리고 “성능 도약”을 이렇게 요약합니다.

• MI355가 이전 세대 대비 최대 3배 추론 처리량을 제공했다면
• MI455는 더 나아가 광범위 모델/워크로드에서 최대 10배 성능을 제시한다는 것.

Helios는 “올해 말 출시 예정”으로 언급되며, AI 성능의 새 기준을 세울 것으로 기대된다는 톤으로 마무리됩니다.

---

OpenAI 협력: 에이전트 컴퓨팅이 요구하는 인프라의 방향

키노트의 전개가 흥미로웠던 이유는, AMD가 하드웨어 스펙만 늘어놓지 않고 “왜 이 정도가 필요해졌는가”를 OpenAI와의 대화로 풀어냈다는 점입니다. 무대에는 OpenAI 공동 설립자이자 사장인 그렉 브록만(Greg Brockman)이 등장합니다.

그가 던진 메시지를 한 줄로 요약하면 이렇습니다. AI는 ‘질문-답변’에서 끝나지 않고, 앞으로 ‘며칠 동안 일하는 에이전트 워크플로우’로 넘어간다.

“모델 능력의 기하급수적 발전 = 유용성의 기하급수적 확대”

브록만은 ChatGPT가 오랜 준비 끝에 등장한 결과였고, 이제 AI는 단순 텍스트 상자를 넘어 헬스케어, 신생아 관리처럼 개인적이고 중요한 영역까지 들어왔다고 말합니다. 엔터프라이즈에서는 Codex 같은 모델이 소프트웨어 엔지니어링을 바꾸고 있으며, “올해는 엔터프라이즈 에이전트가 본격화될 것”이라는 전망도 이어집니다.

에이전트 시대의 컴퓨팅: 저지연과 초고처리량, 두 체제가 공존한다

OpenAI 관점에서 미래 컴퓨팅 환경은 “인간의 주의(attention)와 의도(intent)가 가장 귀한 자원”이 되는 세계이며, 그래서 컴퓨팅은 두 가지 모드가 필요하다고 정리합니다.

• 사람이 관여할 때는 초저지연(low latency) 상호작용
• 백그라운드에서는 지속 실행되는 초고처리량(high throughput) 에이전트 컴퓨팅

즉, “빠른 반응성”과 “거대한 처리량”이 동시에 필요해진다는 뜻이고, 이 요구가 곧 MI455/Helios 같은 랙 스케일 전략으로 연결됩니다.

컴퓨팅 제약과 성장의 상관: “컴퓨팅이 곧 경쟁력”

브록만은 OpenAI가 지난 몇 년 동안 컴퓨팅 사용량을 매년 3배씩 늘렸고 매출도 3배 증가했다고 언급하며, 새로운 모델/기능이 나올 때마다 내부적으로도 컴퓨팅 확보 경쟁이 있을 정도로 compute constrained 상태라는 취지의 설명을 덧붙입니다. 나아가 향후 GDP 성장까지 “어디에 얼마나 컴퓨팅이 있느냐”가 좌우할 수 있다는 관점도 제시됩니다.

AMD와 OpenAI의 “공동 설계”

핵심은 이 문장입니다. MI455와 Helios가 OpenAI 엔지니어링 팀 피드백을 통해 긴밀히 협력하며 개발되었다는 점. 즉, 단순 고객-공급자 관계가 아니라, “에이전트 워크로드가 요구하는 리소스 균형”을 함께 맞춰가는 그림으로 제시됩니다.

---

MI400 포트폴리오와 ROCm: “개방형”이 성능이 되는 시대

AMD는 Helios/MI455를 “정점”으로 두고, 그 아래를 MI400 시리즈 포트폴리오로 촘촘히 채웁니다. 방향성은 명확합니다. 클라우드 하이퍼스케일 훈련부터 엔터프라이즈 배포, 주권 AI, 슈퍼컴퓨팅까지 “환경이 다르면 폼팩터도 달라야 한다”는 것.

• Helios: 하이퍼스케일 훈련 + 랙 스케일 분산 추론
• Instinct MI440X GPU: 엔터프라이즈 배포에 초점. 기존 데이터센터 인프라에서 쓰기 쉬운 컴팩트 8GPU 서버 구성에서 리더십 훈련/추론 성능
• MI430X 플랫폼: 주권 AI 및 슈퍼컴퓨팅처럼 “정확도”가 중요한 환경을 겨냥. 과학 데이터 타입과 AI 데이터 타입을 함께 다루는 하이브리드 컴퓨팅 강조

그리고 이 포트폴리오를 가능하게 하는 기술 기반으로 칩렛(chiplet)이 반복해서 등장합니다. “워크로드에 맞는 컴퓨팅”을 만들 수 있다는 논리입니다.

ROCm: AI 시대에 ‘소프트웨어 스택’은 선택이 아니라 생존

AMD가 개방형 생태계를 강하게 주장하는 지점은 ROCm입니다. 발표의 톤은 단호합니다.

• AI의 미래는 개방형 인프라 + 공유 기술 표준을 중심으로 업계가 협력할 때 가속된다.
• AMD는 하드웨어·소프트웨어·솔루션 생태계 전반에서 개방성을 제공하는 유일한 회사라는 포지셔닝을 취한다.
• ROCm은 “업계에서 가장 성능이 뛰어난 AI용 개방형 소프트웨어 스택”이라고 정의된다.
• PyTorch, vLLM, SGLang, Hugging Face 등 상위 오픈소스 프로젝트에서 기본 지원되며, 모델 허브/프레임워크/도구를 출시 당일부터 지원한다고 강조한다.

정리하면, AMD는 “하드웨어만 좋은 회사”가 아니라, 개발자가 ‘바로 쓰게 만드는’ 소프트웨어 스택을 AI 승부처로 끌어올립니다.

---

Luma AI: 3D·비디오 생성이 ‘산업’이 되는 순간

AI가 텍스트를 넘어서 산업을 바꾸는 순간을 보여주는 파트너로, Luma AI가 무대에 오릅니다. CEO이자 공동 설립자인 아밋 자인(Amit Jain)은 Luma의 미션을 “세상을 이해하고 시뮬레이션하며 개선하는 멀티모달 일반 지능”으로 설명합니다.

Ray 3: “추론 비디오 모델”이라는 프레임

발표에서 Ray 3는 다음과 같이 소개됩니다.

• 세계 최초의 추론 비디오 모델
  • 단순 생성이 아니라, 픽셀과 지연 시간을 먼저 고려하고 “무엇을 생성할지” 결정할 수 있다는 설명
• 세계 최초로 4K 및 HDR 생성 지원
• 광고·미디어·엔터테인먼트 기업과 개인 창작자까지 폭넓게 사용
• 2025년 말에는 90분 장편 영화 제작에 사용하는 등 대규모 배포가 진행 중

여기서 중요한 통찰은 “제어(control)”입니다. 고객들은 정밀한 제어를 원했고, Luma는 제어가 더 나은 프롬프트가 아니라 더 높은 지능에서 나온다는 결론에 도달했다고 말합니다.

Ray 3 Modify: ‘세계 편집(World Editing)’의 시대

Ray 3 위에 구축된 Ray 3 Modify는 실사 또는 AI 푸티지를 가져와 원하는 만큼 바꾸는 세계 편집 기능을 제공하며, 이로 인해 인간의 동작·타이밍·방향 자체가 프롬프트가 되는 하이브리드 인간-AI 프로덕션이 가능해진다는 서사가 이어집니다.

2026년은 “에이전트의 해”

Luma는 2026년을 에이전트의 해로 선언하며, “작업의 일부”가 아니라 엔드투엔드 작업 전체를 수행하는 에이전트로 진화할 것이라고 봅니다. 멀티모달 에이전트 데모에서는 스크립트를 가져와 시각화하고, 장편 비디오를 분석하며, 캐릭터·장면·스토리의 일관성을 유지한 채 필요한 순간에만 편집하는 방향이 제시됩니다.

AMD 선택 이유: 추론 경제성과 TCO

Luma가 AMD를 선택한 이유는 명확히 “경제성”으로 연결됩니다.

• 멀티모달 워크로드는 텍스트 모델보다 수백~수천 배 더 많은 토큰을 소비할 수 있다.
• 예시로, 10초 비디오가 100,000 토큰이 될 수 있는 반면 일반 LLM 응답은 200~300 토큰 수준이라는 대비가 제시됩니다.
• 그래서 TCO(총소유비용)와 추론 경제성이 비즈니스에 절대적으로 중요하며, Luma는 AMD와의 협력을 통해 스택에서 최고의 TCO를 달성했다고 말합니다.
• 또한 2026년에 AMD 파트너십을 10배 확장할 예정이며, MI455X의 랙 스케일 솔루션과 메모리 인프라가 “세계 시뮬레이션 모델” 구축에 필수라고 연결합니다.

---

AI PC 시대: Ryzen AI 400·Ryzen AI Max·Halo 그리고 로컬 에이전트

AMD는 “클라우드만이 AI가 아니다”라는 관점을 AI PC로 확장합니다. AI PC는 단순한 도구가 아니라 사용자의 작업 방식을 학습하고, 습관에 적응하며, 오프라인에서도 빠르게 작업을 수행하는 능동적 파트너가 되어가고 있다는 설명입니다.

MI500 로드맵까지: 성능 향상은 계속된다

AMD는 차세대 MI500 시리즈도 개발 중이라고 밝히며,

• CDNA6 아키텍처
• 2nm 공정
• HBM4e
• 2027년 출시를 통해 지난 4년간 AI 성능 1,000배 증가 달성을 목표로 한다는 로드맵이 제시됩니다.

Ryzen AI 400 시리즈: “60 TOPS”로 확장되는 AI PC 라인업

이번 CES에서 AI PC 쪽 핵심 발표는 Ryzen AI 400 시리즈 프로세서입니다.

• Zen 5 CPU (최대 12 고성능 코어)
• RDNA 3.5 GPU (16 코어)
• XDNA2 NPU (최대 60 TOPS)
• 더 빠른 메모리 속도 지원
• 첫 제품은 “이달 말부터 출하”, 연중 120개+ AI PC에 탑재 예정이라는 로드맵

AMD는 자신들이 AI PC 변곡점을 “일찍” 주도했다는 히스토리도 함께 강조합니다(온칩 AI 엔진 통합, Copilot+ x86 PC 등). 또한 Ryzen AI Max로 2000억(200B) 매개변수 모델을 로컬에서 실행할 수 있는 단일 칩 x86 플랫폼을 만들었다는 주장도 포함됩니다.

Liquid AI: 로컬 AI 에이전트를 위한 ‘가벼운 모델’의 필요

AI PC가 진짜 일하려면 하드웨어만큼 중요한 것이 “장치에서 돌아갈 만큼 효율적인 모델”입니다. 이 맥락에서 Liquid AI가 소개됩니다. MIT에서 분사한 파운데이션 모델 회사로, 트랜스포머가 아닌 Liquid Foundation Models(LFM)를 구축해 품질 저하 없이 계산 비용을 줄이겠다는 목표를 제시합니다. 가치 제안은 3가지로 정리됩니다.

• 개인정보 보호(Privacy)
• 속도(Speed)
• 연속성(Continuity) (온라인/오프라인을 넘나드는 일관된 경험)

LFM 2 / LFM 2.5

• LFM 2는 “타이니 클래스(tiny class)”에서 가장 진보된 모델로 소개되며 12억(1.2B) 파라미터 규모
• 명령 수행(instruction-following) 능력이 동급 및 더 큰 모델 사이에서도 매우 우수하다고 설명
• LFM 2.5 인스턴스는 특정 모델 대비 더 나은 명령 수행을 장치에서 제공한다고 언급
• 총 5가지 모델 인스턴스(챗/인스트럭트/일본어 강화/비전-언어/경량 오디오-언어)가 공개되며 AMD Ryzen AI의 CPU/GPU/NPU에 최적화되었다는 점을 강조

LFM 3: 멀티모달 + 100ms 미만 지연

• 텍스트·비전·오디오 입력을 처리하고, 10개 언어로 오디오 및 텍스트 출력을 제공하도록 기본 멀티모달로 설계
• 시청각 데이터에 대해 100ms 미만 지연 시간을 제시

그리고 “능동적(proactive) 에이전트” 데모가 이어집니다. 사용자가 스프레드시트 작업 중일 때, 에이전트가 다가오는 영업 회의를 감지하고 대신 참석 제안을 하며, 단순 전사를 넘어 이메일까지 분석해 답장 초안을 만드는 흐름을 오프라인 로컬에서 수행한다는 시나리오입니다. Liquid AI는 2026년 Zoom과 협력해 이를 Zoom 플랫폼에 도입할 예정이라고 언급합니다.

Ryzen AI Max: 크리에이터·게이머·개발자용 “통합 메모리” 승부수

Ryzen AI Max는 다음 스펙으로 소개됩니다.

• Zen 5 CPU 16코어
• RDNA 3.5 GPU 40 컴퓨팅 유닛
• XDNA2 NPU 최대 50 TOPS
• CPU/GPU/NPU가 공유하는 최대 128GB 통합 메모리 아키텍처

발표 내용상, 프리미엄 노트북에서 최신 MacBook Pro 대비 AI 및 콘텐츠 제작 앱에서 더 빠르고, 소형 워크스테이션에서는 NVIDIA DGX Spark 대비 더 저렴한 가격으로 유사 성능을 제공하며, GPT-OSS 모델 실행 시 달러당 최대 1.7배 더 많은 토큰을 생성한다는 설명이 포함됩니다. 또한 Windows와 Linux를 모두 기본 지원해 개발 편의성을 강조합니다.

Ryzen AI Halo: “손에 맞는” 로컬 AI 개발 플랫폼

AMD는 로컬 AI 배포를 위한 레퍼런스 플랫폼 Ryzen AI Halo도 발표합니다.

• “세계에서 가장 작은 AI 개발 시스템”
• 최대 2000억 파라미터 모델을 로컬 실행
• 최상급 Ryzen AI Max + 128GB 통합 메모리
• 최신 ROCm 스택과 오픈소스 개발 도구 사전 로드
• 올해 2분기 출시 예정

---

World Labs와 공간 지능: 3D 세계를 “몇 분”으로 당기는 기술

AI의 다음 전선으로 “공간 지능(spatial intelligence)”이 제시됩니다. 무대에는 World Labs 공동 설립자이자 CEO인 페이페이 리(Fei-Fei Li)가 등장하고, 언어 지능의 발전은 컸지만 인간에게 더 중요한 것은 지각과 행동을 연결하는 공간 지능이라고 강조합니다.

World Labs는 이 공간 지능을 현실화하기 위해 설립되었고, Marble이라는 모델 데모가 제시됩니다.

Marble: 몇 장(심지어 한 장)의 이미지로 3D/4D 세계 생성

전통적인 3D 구축이 레이저 스캐너나 복잡한 소프트웨어를 요구했다면, World Labs는 GenAI로 데이터에서 3D·4D 구조를 학습하는 모델을 만든다는 접근입니다. 모델에 몇 장의 이미지만 주면:

• 누락된 디테일을 채우고
• 물체 뒤를 예측하며
• 풍부하고 일관된 탐색 가능한 3D 세계를 만든다고 설명합니다.

AMD 오피스 리모델링 데모: MI325X + ROCm

특히 흥미로운 데모는 AMD 실리콘밸리 오피스를 휴대폰 카메라로 촬영한 몇 장의 이미지로 3D 공간을 만들고, 그 공간을 이집트 스타일 등으로 리모델링하면서도 기하학적 일관성을 유지하는 시나리오입니다. 이때 사용된 인프라로 MI325X와 ROCm이 언급됩니다.

World Labs는 AMD와의 파트너십이 최근 시작됐음에도, 실시간 프레임 생성 모델이 MI325X에서 1주 만에 실행되었고, Instinct와 ROCm을 통해 몇 주 만에 성능을 4배+ 개선할 수 있었다고 말합니다.

여기서 결론은 분명합니다. 공간 지능은 3D 구조·움직임·물리학을 이해해야 하므로 메모리, 대규모 병렬 처리, 매우 빠른 추론이 필요하고, MI450 같은 플랫폼은 더 큰 세계 모델 훈련과 실시간 반응성을 가능하게 할 것이라는 전망으로 이어집니다.

---

헬스케어 혁신: 신약 개발·정밀의학·게놈 데이터의 폭발

키노트의 헬스케어 파트는 “AI의 가치가 결국 생명을 구하는 것으로 측정된다”는 메시지로 전개됩니다. 그리고 세 회사의 사례가 연결됩니다: AppSci, Illumina, AstraZeneca.

AppSci: 생성형 AI + 합성 생물학으로 약을 “설계”하는 시대

AppSci CEO 션 맥클레인(Sean McClain)은 기존 시행착오 중심의 약물 발견과 달리, 생성형 AI와 합성 생물학으로 원하는 생물학적 특성을 가진 후보를 “처음부터 설계”할 수 있다고 말합니다. 주요 목표 질병으로는

• 남성형 탈모(androgenic alopecia)
• 자궁내막증(10명 중 1명 여성에게 영향)

이 제시되고, AMD 투자 후 1년 만에 추론을 확장해 단 하루에 100만+ 약물을 스크리닝할 수 있게 되었다는 성과가 소개됩니다. 또한 MI355의 메모리가 생물학을 더 풍부한 맥락에서 다뤄 더 나은 발견 모델을 만드는 데 도움이 될 것이라는 설명이 이어집니다.

Illumina: DNA라는 ‘30억 문자’의 세계, 그리고 데이터 폭발

Illumina CEO 제이콥 테이슨(Jacob Thaysen)은 DNA를 생명의 청사진으로 설명하며, 인간 게놈이 30억 문자로 이루어진 “20만 페이지 책”에 비유될 만큼 정확도가 중요하다고 강조합니다. 또한 Illumina의 시퀀서가 매일 생성하는 데이터가 매우 방대해, AMD와의 관계가 필수적이며, AMD FPGA와 EPYC 프로세서를 활용해 데이터를 통찰로 변환한다고 말합니다.

생성형 AI + 게놈 + 단백질체학의 결합은 생물학 이해를 바꾸고, 신약 발견을 넘어 예방과 조기 치료로 이어져 수명과 건강수명 개선에 기여할 것이라는 전망도 제시됩니다.

AstraZeneca: “AI는 생산성이 아니라 혁신”

AstraZeneca의 분자 AI 책임자 울라 엔크비스트(Ulla Enksvist)는 AI를 혁신의 도구로 정의합니다. 수십 년의 실험 데이터를 학습한 생성형 AI로 수백만 후보를 가상 평가하고, 가장 유망한 것만 실험실로 가져가는 접근입니다. 그 결과:

• 후보 약물을 50% 더 빠르게 제공
• 임상 성공률도 높이는 방향으로 진화하고 있다고 설명합니다.

AstraZeneca는 AMD와 협력해 인실리코(in-silico) 흐름을 확장하고, 대규모 데이터 세트 처리와 워크플로우 최적화를 추진한다고 언급됩니다.

헬스케어 파트는 “sick care(사후 치료)”에서 “preventative care(예방)”로, 나아가 재생 생물학/의학(regenerative biology and medicine)으로 가는 방향성으로 정리됩니다.

---

물리적 AI: 로보틱스와 우주 탐사에서의 ‘결정적 로컬 컴퓨팅’

AI가 현실 세계로 들어오는 순간, 요구사항은 급격히 바뀝니다. 물리적 AI는 “느리면 안 되고, 틀리면 안 되는” 환경이 많습니다. 그래서 발표는 반복해서 로컬에서 빠르고 결정적(deterministic)인 컴퓨팅을 강조합니다.

Generative Bionics: 인간 중심 휴머노이드 로봇 ‘Gen 1’

Generative Bionics CEO 다니엘라 푸치(Daniela Pucci)는 “인공 에이전트가 인간 세계를 이해하려면 인간 같은 몸으로 경험해야 하는가?”라는 질문에서 출발해, iCub/ErgoCub/IronCub 같은 플랫폼을 만들어왔다고 소개합니다.

Gen 1에서 가장 큰 차별점은 촉각(tactile)입니다.

• 몸 전체에 분산된 촉각 피부(tactile skin)가 압력·접촉·의도를 감지
• 촉각을 “주요 지능의 원천”으로 끌어올린다는 메시지
• 공장 협업, 헬스케어 보조 등 사람과의 안전한 상호작용을 겨냥

또한 Gen 1은 2026년 하반기 상업 제조 예정이며, 선도 철강 제조업체를 포함한 산업 파트너와 함께 안전이 중요한 환경에 배치될 것이라고 언급됩니다. 이 과정에서 AMD는 Ryzen AI Embedded, VersaLay iEdge 같은 엣지 플랫폼부터 시뮬레이션/훈련/대규모 개발용 CPU/GPU까지 엔드투엔드 아키텍처를 제공하는 파트너로 설명됩니다.

Blue Origin: 달 영구 거주(Lunar Permanence)와 Versal 2 비행 컴퓨터

Blue Origin의 달 영구 거주 담당 수석 부사장 존 칼루리스(John Kalouris)는 목표를 “달 영구 거주 확립”으로 정의하며, 이를 위해 반복 가능하고 저렴한 운영이 필요하다고 말합니다.

우주는 궁극의 엣지 환경입니다. 비행 컴퓨터는 “차량의 심장”이고, 질량·전력·방사선 등 제약 속에서 신뢰성과 탄력성을 가져야 합니다. AMD 임베디드 아키텍처는 질량과 전력 절감, 방사선 환경 고려 측면에서 장점이 있다는 서사가 이어집니다.

특히 Blue Origin은 AMD와 Versal 2를 비행 컴퓨터 스택에 쓰는 논의를 시작한 지 몇 달 만에 개발 비행 컴퓨터에 통합 가능한 장치를 제공받았고, 이 스택으로 달 착륙 시뮬레이션을 성공적으로 수행해 수개월 일정을 단축했다고 말합니다. 이 컴퓨터는 2028년 초 우주비행사를 달에 착륙시킬 Mark 2 착륙선에 동력을 공급할 예정이라는 언급도 포함됩니다.

또한 AI는 우주비행사에게 코파일럿 역할을 하고, 착륙 지점 식별·위험 탐지 등에서 실시간 엣지 컴퓨팅이 중요하다는 메시지가 이어집니다. 달 뒷면 전파 천문학 시나리오도 연결되며, 통신 지연을 극복하기 위해 엣지 AI가 탐사 최적화를 돕는 그림이 제시됩니다.

---

과학·슈퍼컴퓨팅·교육: Genesis 미션과 AI 인재 파이프라인

AMD는 HPC(고성능컴퓨팅)에서의 리더십도 전면에 배치합니다. 전통 HPC와 AI의 융합을 추진하고 있고, 세계에서 가장 빠른 슈퍼컴퓨터, 에너지 효율 시스템 등에 동력을 공급한다고 강조합니다. 예시로는:

• 핀란드 Lumi: 기후 모델 업데이트 시간 85%+ 단축
• ENI: 배터리/연료 개발
• Oak Ridge National Labs(Exascale): 예측 정확도 99% 수준의 시뮬레이션 언급
• Lawrence Livermore El Capitan: 바이러스 변이/진화 모델링을 통한 팬데믹 대응 가속

Genesis 미션: AI·슈퍼컴퓨팅·양자의 융합

AMD는 미국 DOE 및 국립 연구소와 함께 Genesis 미션에 참여한다고 소개합니다.

• Lux 컴퓨터: “올해 초 가동 예정”인 과학 전용 AI 팩토리
• Discovery: 2028년 계획된 차기 플래그십 슈퍼컴퓨터

또한 미국 차원의 AI 전략(규제 장벽 제거, 인프라/에너지 확보, AI 외교/수출 프로그램)과 연결되며, 교육 이니셔티브로 “대통령 AI 챌린지”가 언급됩니다.

교육: AI Education Pledge와 학생·커뮤니티 확장

AMD는 AI 교육 서약을 지원하며 1억 5천만 달러를 투자했고, 전 세계 800개+ 교육·연구 협력을 구축 중이며, 올해 15만 명+ 학생에게 무료 온라인 AI 과정을 제공할 계획이라고 말합니다.

또한 Hack Club과 진행한 전국 AI·로보틱스 캠페인, 해커톤 우승팀 Team Armtender(AI 로봇 바리스타) 사례가 소개됩니다. 이 팀은 AMD 개발자 클라우드(MI 300X GPU)에서 비전-언어 모델을 훈련했고, 로봇 팔은 Ryzen AI 노트북에서 3대 카메라로 로컬 실행된다고 설명됩니다. AMD는 팀원 각자에게 2만 달러 교육 보조금을 수여했다고 언급됩니다.

---

결론: AMD가 그리는 다음 10년의 AI 지도

CES 2026에서 AMD는 “AI가 중요하다”는 메시지를 넘어, AI가 보편재가 되기 위해 필요한 컴퓨팅의 크기(요타 스케일)와 이를 감당하기 위한 플랫폼 단위 혁신(Helios/MI455), 그리고 개방형 소프트웨어(ROCm)를 한 프레임으로 묶었습니다.

여기에 OpenAI의 에이전트 컴퓨팅, Luma AI의 멀티모달 생성 워크로드, World Labs의 공간 지능, 헬스케어·로보틱스·우주 탐사·과학 슈퍼컴퓨팅까지 연결하면서, AMD의 전략은 결국 이렇게 요약됩니다.

• AI는 클라우드에만 있지 않다. 클라우드·PC·엣지 전체가 AI 플랫폼이 된다.
• 컴퓨팅 수요는 상상을 초월한다. 그래서 랙 스케일/요타 스케일이 필요하다.
• 성능은 하드웨어만이 아니라 소프트웨어(ROCm)와 생태계에서 완성된다.
• 가장 큰 혁신은 단독이 아니라, 업계 리더와의 공동 혁신으로 빠르게 현실이 된다.

AMD가 그린 그림은 “더 큰 숫자”의 경쟁이라기보다, AI를 전 산업과 일상에 ‘실제로 배포 가능한 형태’로 만드는 인프라 경쟁에 가깝습니다. 그리고 CES 2026은 그 로드맵을 상당히 구체적인 형태로 공개한 자리였습니다.

---

AX 100배의 법칙 – 나와 조직의 능력을 100배 높이는 AI 경영의 실제 도서 구매

함께 읽으면 좋은 글:

디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매

(adsbygoogle = window.adsbygoogle || []).push({});

. .