클로드 자격증은 어떤 프로그램인가

Claude Certification Program은 Claude를 활용해 업무를 수행하고, 애플리케이션을 개발하며, 기업용 시스템을 설계하는 역량을 역할별로 평가하는 Anthropic의 공식 인증 프로그램입니다. 단순한 교육 수료증이 아니라 감독과 본인 확인이 적용되는 시험을 통과해야 취득할 수 있습니다.

2026년 7월 Anthropic은 기존 Architect Foundations에 Associate Foundations, Developer Foundations, Architect Professional을 추가해 네 가지 자격증 체계를 공개했습니다. 역할은 Associate, Developer, Architect 세 갈래이며 Architect에는 Foundations와 Professional 두 수준이 있습니다. Anthropic의 자격증 프로그램 발표

이 자격증은 Anthropic 자체의 보안·규정 준수 인증과 다릅니다. 개인이 Claude 관련 실무 능력을 증명하는 직무 자격증이며, 조직이 취득하는 ISO나 SOC 인증을 뜻하지 않습니다.

클로드 자격증 네 종류 한눈에 비교

자격증은 서열보다 실제 업무 역할을 기준으로 선택하는 것이 좋습니다. 일상적인 Claude 활용자는 Associate, 코드를 작성하고 시스템을 구현하는 사람은 Developer, 구조와 운영 기준을 설계하는 사람은 Architect가 중심입니다.

아래 가격은 2026년 10월 공식 안내에 표시된 미화 기준이며 파트너 등급 할인 전 금액입니다. 가격과 제공 조건은 바뀔 수 있으므로 등록 전에 공식 페이지에서 다시 확인해야 합니다.

Associate – Foundations: 업무 활용자를 위한 기초 자격증

Associate Foundations는 개발자가 아닌 사람도 선택할 수 있는 실무형 자격증입니다. Claude 제품과 모델을 업무에 맞게 고르고, 프롬프트를 구성하며, 결과의 정확성과 완전성을 확인하는 능력을 평가합니다.

주요 범위는 Prompting과 작업 실행, 출력 평가, Workflow 통합, Projects와 지식 관리, 거버넌스, 위험 판단, 문제 해결입니다. 운영, 마케팅, 프로젝트 관리, 교육, 커뮤니케이션처럼 AI 결과를 업무 산출물에 사용하는 역할에 적합합니다.

Claude를 처음 접하는 단계보다는 기본 기능을 사용해 본 뒤 반복 가능한 업무 흐름을 만들고 결과를 검증할 수 있을 때 준비하는 편이 이해하기 쉽습니다.

Developer – Foundations: API와 Agent 구현자를 위한 자격증

Developer Foundations는 Claude API와 Claude Code를 사용해 실제 기능을 만드는 개발자를 대상으로 합니다. 단순히 API 요청을 보내는 방법보다, 예외 상황에서도 유지되는 Agent와 Workflow를 구현하는 판단이 중요합니다.

학습 범위에는 Token과 Context Window, Prompt 구조, Tool Schema와 Tool Use Loop, Agent Orchestration, MCP, Claude Code 권한과 설정, 평가, 추적, 비용·지연시간, Prompt Injection과 비밀정보 보호가 포함됩니다.

직접 코드를 작성하고 Tool 호출 실패, Context 관리, 평가 기준과 운영 보안을 다루는 역할이라면 Architect보다 Developer가 업무에 더 가까울 수 있습니다.

Architect – Foundations: Claude 솔루션 설계의 기본

Architect Foundations는 Claude 기반 솔루션의 범위와 구조를 정하는 Solution Architect를 위한 자격증입니다. Single-shot, Workflow, Agent 중 어떤 구조가 적합한지 판단하고 모델과 배포 플랫폼, 비용, 평가와 책임 있는 운영을 함께 고려하는 능력을 봅니다.

공식 시험 범위는 Agentic Architecture & Orchestration, Tool Design & MCP Integration, Claude Code Configuration & Workflows, Prompt Engineering & Structured Output, Context Management & Reliability의 다섯 영역으로 구성됩니다. Architect Foundations 공식 안내

기존 CCA-F 학습 흐름을 시작하려면 Agentic Architecture와 Orchestration 기초부터 개념을 정리할 수 있습니다.

Architect – Professional: 기업 규모 설계와 거버넌스

Architect Professional은 복잡한 Claude 시스템을 처음부터 운영 인계까지 설계하는 고급 자격증입니다. 비즈니스 요구를 구조로 바꾸고, 기업 시스템과 통합하며, 보안·안전·평가·비용·신뢰성 기준을 설계할 수 있어야 합니다.

Foundations가 Claude 솔루션의 기본 설계 판단을 다룬다면 Professional은 대규모 통합, Governance, 평가 전략, 이해관계자 합의와 운영 전환까지 범위를 넓힙니다. 실제 AI 시스템의 설계와 배포 경험이 있는 사람에게 더 적합합니다.

Foundations와 Professional은 별도 시험입니다. 공식 FAQ에 따르면 Professional 응시에 Foundations가 형식상 필수는 아니지만, Foundations부터 시작하는 것이 자연스러운 경로로 안내됩니다.

시험은 어떻게 진행되는가

시험은 Pearson Professional Assessments를 통해 온라인 감독 방식이나 Pearson 시험 센터에서 진행됩니다. 응시 전 본인 확인이 필요하며, 합격자는 Credly by Pearson의 디지털 배지를 받을 수 있습니다.

현재 공식 FAQ에서는 시험과 준비 콘텐츠를 영어로만 제공한다고 안내합니다. 감독 시험 중에는 브라우저 번역 도구를 사용할 수 없으므로 기술 용어와 문제 조건을 영어로 읽는 연습이 필요합니다.

시험 시간, 문항 수, 합격 점수와 유효기간은 자격증별 공식 페이지에서 확인해야 합니다. 예를 들어 Architect Foundations 공식 페이지에는 120분, 60문항, 1,000점 환산 기준 720점, 12개월 유효기간이 표시되어 있습니다.

누가 응시할 수 있는가

2026년 10월 공식 FAQ 기준으로 Claude Certification은 Claude Partner Network 소속 조직의 구성원에게 제공됩니다. 등록에는 공식 파트너 조직으로 연결된 회사 이메일이 필요하며 개인 이메일은 사용할 수 없습니다.

비파트너 개인이나 일반 고객이 바로 신청할 수 있는 공개 자격증으로 단정하면 안 됩니다. 조직의 파트너 가입 여부와 본인의 Academy 접근 권한을 먼저 확인해야 합니다. 최소 응시 연령은 18세입니다.

Associate는 개인의 업무 역량을 검증하지만 현재 Claude Partner Network 등급 산정에는 포함되지 않습니다. Developer Foundations와 두 Architect 자격증은 공식 FAQ에서 네트워크 자격 산정 대상이라고 구분합니다. Claude Certification 공식 FAQ

나에게 맞는 자격증 선택 순서

Claude를 문서 작성과 분석, 팀 Workflow에 활용한다면 Associate Foundations가 적합합니다. API와 Claude Code로 기능을 구현하고 운영 품질을 책임진다면 Developer Foundations를 우선 검토합니다.

요구사항을 분석해 Agent, Tool, MCP, Context와 평가 구조를 설계한다면 Architect Foundations가 적합합니다. 여러 시스템과 조직을 연결하고 보안 심사, 거버넌스, 비용과 운영 인계까지 책임진다면 Architect Professional을 고려합니다.

Claude 자체가 낯설다면 먼저 Claude의 제품·API·MCP·Claude Code 구조를 이해한 뒤 역할에 맞는 자격증을 고르는 편이 좋습니다.

공식 준비 경로와 주의할 점

준비의 기준은 각 자격증 페이지에서 제공하는 Exam Guide입니다. Exam Guide의 Domain과 Task Statement가 시험 범위의 기준이며, Anthropic Partner Academy에는 역할별 무료 준비 과정이 제공됩니다.

실제 시험 문제를 복원하거나 공유하는 방식은 사용하지 않습니다. 공개된 Sample Question의 형식을 참고하되, 개념을 새로운 상황에 적용하는 연습과 공식 문서 확인을 중심으로 준비해야 합니다.

가격, 응시 자격, 시험 제공 언어와 정책은 변경될 수 있습니다. 결제 전에 공식 자격증 목록, 해당 시험 페이지, FAQ와 Pearson 예약 화면을 순서대로 확인하세요. Anthropic Partner Academy 자격증 목록

FAQ

EKS 권한 상승을 이해하는 세 가지 경계: Linux·IAM·RBAC

EKS에서 kubeconfig를 다시 만든다고 권한이 생기지는 않습니다. 같은 EC2에서 더 높은 권한의 IAM 주체를 사용할 수 있거나, Pod 접속 권한으로 워크로드의 AWS 권한을 사용할 수 있을 때 의도한 권한 경계가 무너질 수 있습니다. Linux 계정 ec2-user에 조회 권한이 있다는 설명만으로는 EKS 접근 범위를 판단할 수 없습니다.

흐름은 EC2 로그인 계정 → AWS 자격증명 선택 → EKS 인증 → Kubernetes 작업 인가입니다. Pod 접속 뒤에는 컨테이너 프로세스 → 워크로드 자격증명 → AWS API 인가라는 별도의 흐름이 이어집니다. EKS 접근 제어 구조

이 글은 EKS 운영자가 조회 전용 접근과 워크로드 IAM 권한의 경계를 점검하는 구성 예시입니다. 별도 테스트 환경에서 ConfigMap의 서버 측 dry-run과 더미 S3 객체 두 개를 사용합니다. 기존 IRSA·Pod Identity 설정 글과 달리, 사용자에게 허용된 Pod 접속이 어떤 AWS 작업으로 이어지는지에 초점을 맞춥니다.

조회 권한만 있는데 작업 범위가 달라지는 이유

처음에는 조회 전용 역할로 접속했지만, 기본 AWS 프로파일이나 EC2 인스턴스 역할에 더 넓은 클러스터 접근이 허용되어 있으면 설정 변경 뒤 결과가 달라질 수 있습니다. AssumeRole 가능한 역할이 과도한 권한을 가진 경우도 같습니다. 이것은 기존 view 권한이 변한 것이 아니라 다른 인증 주체가 선택된 경우입니다.

실습 전제는 Linux Bash, AWS CLI v2, 클러스터와 호환되는 kubectl, EKS API·STS·S3에 필요한 연결입니다. VIEW_PROFILE과 LAB_PROFILE은 관리자가 미리 준비한 서로 다른 전용 역할 프로파일입니다. 두 프로파일 모두 대상 클러스터의 eks:DescribeCluster가 필요합니다. 역할 프로파일이면 소스 자격증명과 역할 신뢰 관계도 충족해야 합니다. 테스트 사용자는 Access Entry나 IAM 정책을 수정할 권한을 가지지 않도록 합니다.

테스트 네임스페이스 이름은 eks-permission-lab으로 고정합니다. 두 역할의 EKS Access Entry를 각각 lab-view와 lab-operator 그룹에 연결하고, 아래 RBAC를 사용합니다. 다른 접근 정책·RoleBinding·ClusterRoleBinding이 결과를 추가로 허용하지 않는지 먼저 확인하세요. 기존 클러스터의 인증 모드를 이 글의 예제 때문에 바꾸지 않습니다. EKS Access Entry 안내

kubeconfig 갱신과 IAM 인증 주체 변경의 차이

update-kubeconfig는 클러스터 주소와 인증서, AWS 인증 명령을 kubeconfig에 기록합니다. --role-arn은 kubectl 인증에 사용할 역할이고, --assume-role-arn은 클러스터 정보를 가져오는 단계에 사용할 역할입니다. 두 옵션의 목적을 바꾸어 해석하면 안 됩니다. 이 예제는 혼동을 줄이기 위해 역할 옵션 대신 두 개의 명시적인 AWS 프로파일을 사용합니다. update-kubeconfig 옵션

아래 값은 자신의 테스트 환경에 맞게 바꿉니다. 프로파일에는 별도의 role_arn을 설정하고 관리자와 역할 이름을 대조하세요. 다른 STS 세션 ARN이 나왔다는 사실만으로 다른 역할이라고 판정할 수는 없습니다. 자격증명 환경변수가 남은 셸은 사용하지 않습니다. 기본 ~/.kube/config를 덮어쓰지 않도록 전용 경로를 사용합니다.

테스트 1: 동일 주체 갱신과 다른 역할 전환 비교

아래 명령은 앞 절과 같은 Bash 세션에서 실행합니다. view_k는 조회 역할, lab_k는 제한된 테스트 역할을 사용합니다. 권한 질문만 확인하지 않고 ConfigMap 생성 요청을 --dry-run=server로 보내 인증·인가와 입장 제어를 함께 거칩니다. 객체는 저장하지 않습니다. dry-run 거부가 RBAC 때문인지 입장 정책 때문인지 오류 내용을 구분해야 합니다.

판정 순서는 조회 성공 → 조회 역할의 ConfigMap 생성 Forbidden → 같은 프로파일로 갱신 후에도 Forbidden → 테스트 역할의 dry-run 허용입니다. DNS·TLS·연결 실패, 만료된 로그인, Unauthorized는 권한 제한 성공으로 세지 않습니다. 예상 실패 뒤에도 다음 비교를 진행해야 하므로 수동 명령은 한 줄씩 실행하세요.

실행용 파일 eks-permission-boundary-check.sh의 identity 모드는 같은 순서를 자동 비교합니다. 예상한 Forbidden 문자열과 종료 상태를 함께 확인하고 다른 오류에서는 중단합니다. 임시 kubeconfig와 출력 파일은 종료 시 정리합니다. 파일을 저장한 폴더에서 bash eks-permission-boundary-check.sh identity로 실행할 수 있습니다.

kubectl exec 권한이 AWS 접근으로 이어지는 조건

조회 전용 view와 pods/exec는 다릅니다. exec는 Pod의 특정 컨테이너에서 프로그램을 실행할 수 있게 합니다. 그 프로세스가 워크로드의 AWS 자격증명에 접근할 수 있으면, Pod 역할 범위 안의 AWS 요청도 가능해질 수 있습니다. RBAC는 exec 세션 안에서 어떤 명령만 허용할지를 세밀하게 제한하는 장치가 아닙니다.

아래는 관리자가 준비하는 RBAC YAML입니다. 기존 클러스터의 Access Entry에서 매핑한 그룹 이름과 정확히 맞춰야 합니다. 테스트 역할의 exec는 boundary-demo라는 Pod 한 개로 제한하고 GET·POST 연결 방식에 대응하도록 get과 create를 명시합니다. 실제 Pod 이름도 boundary-demo로 준비합니다. 일반적인 리소스 생성에 resourceNames를 붙이는 방법과 혼동하지 마세요. Kubernetes RBAC와 pods/exec 하위 리소스

YAML은 lab-rbac.yaml로 저장합니다. 대상 네임스페이스가 없으면 관리자가 먼저 kubectl --context "$ADMIN_CONTEXT" create namespace eks-permission-lab으로 생성합니다. 네임스페이스 생성까지 한 번의 서버 dry-run으로 처리하면 뒤의 리소스가 NamespaceNotFound로 실패할 수 있습니다. 관리자가 별도의 관리 컨텍스트에서 kubectl --context "$ADMIN_CONTEXT" apply --dry-run=server -f lab-rbac.yaml로 확인하고, 같은 명령에서 --dry-run=server를 제거해 테스트 구성을 적용합니다. 테스트용 역할로 관리자 준비 작업을 실행하지 않습니다.

IRSA와 EKS Pod Identity의 자격증명 제공 방식

IRSA는 대상 서비스 계정과 OIDC 신뢰 조건이 맞는 웹 ID 토큰을 STS AssumeRoleWithWebIdentity로 교환합니다. 일반 Kubernetes API용 토큰이면 모두 AWS 역할을 사용할 수 있다는 뜻은 아닙니다. audience·subject·신뢰 정책 조건을 확인해야 합니다. IRSA 동작과 격리 조건

EKS Pod Identity는 지원되는 SDK·AWS CLI의 컨테이너 자격증명 공급자와 노드의 Pod Identity Agent, EKS Auth를 통해 임시 자격증명을 제공합니다. 이 토큰을 IRSA와 동일한 STS 호출에 넣는 방식으로 설명하면 부정확합니다. EKS Pod Identity 동작 구조

테스트 Pod에는 두 방식 중 하나만 구성합니다. IRSA는 OIDC 공급자와 서비스 계정 역할 연결, Pod Identity는 지원 컴퓨팅 환경·Agent·연결 설정을 준비합니다. 정적 AWS 키나 별도 프로파일을 주입하지 않고, IMDS 접근도 제한해 노드 역할로 결과가 섞이지 않도록 합니다. 실제 선택된 주체는 Pod 내부의 get-caller-identity로 비교합니다. 토큰·임시키를 출력하거나 EC2로 옮기는 과정은 이 판정에 필요하지 않습니다.

초기 연결 과정은 IRSA 설정 방법과 EKS Pod Identity 구조에서 이어서 확인할 수 있습니다.

테스트 2: Pod 내부의 AWS 권한과 접근 거부 비교

먼저 관리자가 두 더미 객체가 실제로 존재하고, 지정한 버킷 소유자와 리전이 맞는지 확인합니다. allowed/demo.txt만 읽도록 Pod 역할을 구성하고, 버킷 정책·접근 지점·다른 역할 정책이 blocked/demo.txt를 추가로 허용하지 않도록 합니다. SSE-S3를 사용하면 KMS 권한 실패를 S3 권한 실패와 혼동하는 일을 줄일 수 있습니다.

아래에서 조회 역할의 exec는 Forbidden, 테스트 역할의 exec는 허용되는 것이 비교 기준입니다. Pod의 인증 결과는 미리 정한 역할 이름과 대조합니다. get-caller-identity 성공은 해당 주체로 서명한 사실을 보여줄 뿐 S3 권한을 입증하지는 않습니다. 이어서 더미 객체 두 개의 GetObject를 비교합니다.

명령 결과의 실제 ARN·계정 번호는 외부에 공개하지 않습니다. /dev/null은 Linux 컨테이너 안의 다운로드 목적지이므로 더미 객체 내용을 출력하거나 남기지 않습니다. 토큰 원문이나 임시 AWS 키를 조회할 필요가 없습니다.

자동 비교 파일의 pod 모드는 EXPECTED_POD_ROLE_NAME으로 역할 이름을 확인한 다음 허용 객체 읽기와 차단 객체의 GetObject AccessDenied를 비교합니다. 다른 오류는 실패로 처리합니다. AccessDenied 자체도 정책의 원인을 단독으로 증명하지는 않으므로, 객체 존재·소유자·버킷 정책을 함께 대조해야 합니다.

Kubernetes 권한과 AWS 권한을 혼동하지 않는 결과 해석

두 테스트에서 관측하는 것은 서로 다릅니다. 첫 번째는 다른 IAM 인증 주체로 클러스터 작업 범위가 바뀌는지, 두 번째는 허용된 exec로 Pod 역할의 AWS 작업을 수행할 수 있는지입니다. S3 객체를 읽었다고 Kubernetes 관리자 권한이나 AWS 전체 관리자 권한을 얻었다고 결론 내리면 안 됩니다.

kubectl auth can-i --list만으로 모든 EKS 접근 정책 권한을 열거했다고 판단하지 않습니다. 개별 작업 질의와 실제 API 요청 결과를 함께 봅니다. EKS 접근 정책과 RBAC는 서로 허용을 추가할 수 있으므로 한 RoleBinding을 제거한 것만으로 차단이 보장되지는 않습니다. EKS 접근 정책과 권한 확인

서버 측 dry-run은 저장을 생략한 API 요청입니다. 실제 객체 생성 후의 동작, 컨트롤러 처리, 후속 워크로드 실행까지 성공했다는 의미는 아닙니다.

자격증명 접근·역할 전환·exec 권한을 제한하는 방법

공유 EC2에서 조회 전용 운영을 의도한다면 같은 사용자가 접근할 수 있는 인스턴스 역할·AWS 프로파일·SSO 세션·역할 전환 경로까지 점검합니다. 로컬 사용자 이름이나 kubeconfig 파일 하나만 제한해서는 AWS 자격증명 경계를 만들 수 없습니다.

AssumeRole 대상과 신뢰 조건, Access Entry 변경 권한, 접근 정책 연결 권한을 최소화합니다. Pod의 AWS 권한은 객체·작업 범위에 맞게 줄이고, 서비스 계정마다 나눕니다. IRSA나 Pod Identity를 사용해도 과도한 역할 정책이 자동으로 최소 권한이 되는 것은 아닙니다.

exec는 필요한 운영자·네임스페이스·Pod로 제한하고, 가능한 경우 로그와 상태 조회로 대체합니다. Pod 생성·수정, 디버깅용 컨테이너 추가, 노드 접근 등 다른 경로도 함께 검토합니다. exec RoleBinding을 회수하면 새 접속을 다시 확인해야 하며, 이미 열린 세션이나 발급된 AWS 세션까지 즉시 종료된다고 가정하지 않습니다. RBAC 최소 권한 원칙

AWS 정책의 상한과 조건 설계는 Permission Boundary·SCP를 이용한 권한 상승 방지 설계와 연결해 검토하세요.

감사 로그와 재점검 체크리스트

Kubernetes 감사 로그에서는 인증 사용자·그룹, 네임스페이스, Pod 이름, pods/exec 요청과 응답 코드를 봅니다. EKS 관리 API의 Access Entry 변경과 IAM·STS 작업은 CloudTrail에서 확인합니다. S3 객체 읽기를 추적하려면 해당 버킷의 데이터 이벤트 수집을 별도로 구성해야 합니다. 감사 로그가 모든 셸 내부 명령을 기록하는 것은 아닙니다. EKS 제어 플레인 로그 · EKS와 CloudTrail

정리 단계에서는 관리자가 테스트용 lab-operator RoleBinding만 회수하고 새로운 exec 요청이 Forbidden인지 확인합니다. 다른 작업의 RoleBinding을 삭제하지 않습니다. 이어 테스트에 생성한 Pod·서비스 계정·역할 연결·전용 IAM 역할·더미 객체를 식별해 정리합니다. 기존 자원과 공유되는 항목은 삭제 대상에서 제외합니다.

수동 명령에서 만든 로컬 kubeconfig는 아래처럼 명시적인 파일만 제거합니다. 자동 비교 파일은 자신이 만든 임시 파일을 종료 시 정리합니다. 결과 기록에는 역할 별칭·작업·허용/거부·오류 분류만 남기고 실제 ARN이나 토큰은 넣지 않습니다.

FAQ

REA란 무엇인가: 분석 근거를 AI 에이전트에 연결하는 도구

REA(Reverse Engineer Anything)는 소프트웨어를 조사하는 도구와 AI 에이전트를 연결하는 프로젝트입니다. REA가 반환한 코드 위치·명령어·참조 관계 등을 바탕으로 에이전트가 추가 질문을 만들고 동작을 해석합니다. 필요한 경우 별도의 구현과 테스트까지 이어갈 수 있습니다. REA 공식 저장소

중요한 질문은 “무엇이든 복제할 수 있는가”보다 “어떤 근거를 얻고 어느 범위까지 결론을 내릴 수 있는가”입니다. 의사코드를 얻는 일, 기능의 의미를 추론하는 일, 새 구현이 같은 결과를 내는지 확인하는 일은 서로 다른 단계입니다.

이 글은 도입을 검토하는 개발자와 운영자를 대상으로 공식 사례의 범위, 외부 도구 조건, 데이터 흐름과 비용을 정리합니다. 특정 프로그램의 접근 통제나 라이선스를 우회하는 방법을 다루지는 않습니다.

관심을 받는 이유와 기존 도구 대비 차이

REA의 특징은 에이전트가 분석 도구를 호출하고, 나온 근거를 읽고, 다음 조사로 이어가는 흐름을 제공한다는 점입니다. MCP를 통한 연결 외에 CLI로도 분석 기능을 사용할 수 있습니다. REA 프로젝트 소개

기존 분석 도구를 직접 사용하는 사람도 함수와 참조를 따라갈 수 있습니다. REA의 가치는 이 작업을 에이전트의 질문·설명·구현 과정과 연결하는 데 있습니다. 도구 연결이 분석가의 판단이나 분석 엔진 자체를 없애는 것은 아닙니다.

GitHub 관심 지표를 도입 근거로 사용할 때는 인기와 적합성을 분리해야 합니다. 스타 수가 많아도 특정 바이너리의 해석 정확도나 자신의 환경에서의 성공률을 알려주지는 않습니다. 도입 판단에는 지원 대상과 근거의 품질이 더 직접적인 기준입니다.

작동 구조: 질문에서 근거와 재구현까지

에이전트는 REA에 대상의 구조나 특정 함수에 대해 질의합니다. REA는 자체 분석 또는 연결된 분석 엔진의 결과를 정리해 반환합니다. 에이전트는 그 결과를 해석하고 추가 조사를 선택합니다. 네이티브 조사에서는 함수·명령어·의사코드·참조를 함께 살펴볼 수 있습니다. 네이티브 분석 안내

의사코드는 분석 엔진이 기계어를 이해하기 쉬운 형태로 표현한 결과일 수 있습니다. 원본 바이트처럼 직접 읽은 값과 같은 수준의 사실로 다루면 안 됩니다. AI의 자연어 설명뿐 아니라 도구의 분석 결과에도 해석과 범위의 한계가 있습니다.

권장 흐름은 질문 범위 설정 → 대상과 버전 식별 → 근거 수집 → 가설 작성 → 반례 확인 → 필요 시 독립 구현 → 결과 비교입니다. 질문을 좁히면 어디에서 추론이 시작되는지 구분하기 쉬워집니다.

도구 연결의 기본 구조는 MCP 서버의 역할을 설명한 글에서 이어서 볼 수 있습니다.

REA가 제공하는 기능과 AI가 추론하는 부분

분석 보고서는 관측값, 도구의 분석 결과, AI의 해석, 실행 비교 결과를 나누어 읽는 편이 좋습니다. REA의 CLI와 MCP는 분석 근거를 반환하는 공통 작업 흐름을 사용합니다. CLI와 Evidence 안내

아래 표는 책임을 구분하기 위한 기준입니다. 최종 설명에 근거 위치를 연결하면 다른 사람이 같은 결론을 재검토하기 쉬워집니다.

대상별 지원 조건: 파일 확장자만으로 판단하지 않기

네이티브 바이너리의 깊은 분석은 Hopper·Ghidra·IDA 등 공급자의 지원 범위에 영향을 받습니다. JavaScript·Electron의 정적 분석과 .NET 메타데이터·CIL 조사는 같은 설치 조건을 요구하지 않습니다. 공식 대상별 지원표

Node.js 요구 조건은 22.x의 22.19 이상, 24.x의 24.11 이상 또는 26 이상으로 안내됩니다. 기능에 따라 추가 도구와 더 높은 런타임 조건이 붙을 수 있으므로, 설치 가능 여부와 원하는 분석 기능의 준비 상태를 따로 확인하세요. 설치와 준비 상태 안내

예를 들어 .NET 단일 파일 배포나 NativeAOT는 일반적인 관리형 어셈블리 조사와 같지 않습니다. 확장자가 DLL 또는 EXE라는 이유로 동일한 분석 경로를 선택하면 안 됩니다. 배포 형식별 분석 경로

공식 사례 1: DX-Ball은 어느 함수까지 확인했나

DX-Ball 사례는 화면의 가로 위치가 좌우 음향 값으로 바뀌는 함수를 추적합니다. 처음 나온 의사코드에 입력과 계산이 충분히 드러나지 않자, 명령어·호출자·상수 바이트를 추가로 읽어 해석을 보완했습니다. DX-Ball 공식 사례

사례에 따르면 재구성한 함수는 원본 x86과 3,205개 입력 조건을 비교했고, 고정된 컴파일 환경과 재배치 처리 조건에서 63바이트가 일치했습니다. REA는 조사 근거를 제공하고 재구성 프로젝트가 구현과 비교를 수행한 구조입니다.

이 결과의 범위는 해당 함수와 제시된 조건입니다. 게임 전체가 자동 복원됐다는 뜻으로 확대할 수 없습니다. 분석 도구의 첫 설명이 불완전할 때, 근거를 교차 확인하는 과정이 왜 필요한지 보여주는 사례로 읽는 것이 적절합니다.

공식 사례 2: Notion의 클립보드 경로 추적

Notion 사례는 데스크톱 패키지에서 페이지에 노출된 API, preload, IPC, 메인 프로세스와 Electron 클립보드 호출을 연결합니다. REA가 소스 범위를 찾고, 에이전트가 해당 위치의 래퍼와 수신 코드를 읽어 경로를 해석합니다. Notion 공식 사례

이 사례의 핵심은 기능을 설명하는 코드 경로입니다. 패키지 버전과 웹 자산의 출처가 구분되어 있으며 일부 결과는 추출한 모듈을 실행한 비교에서 나왔습니다. 이를 전체 데스크톱 UI 동작의 자동 재현이나 Notion 제품 전체 복제로 설명하면 범위가 달라집니다.

Electron 앱 분석을 도입할 때는 “앱 전체를 설명해줘”보다 “특정 동작이 어떤 IPC와 수신 함수로 연결되는가”처럼 범위를 정하는 편이 조사 결과를 평가하기 쉽습니다.

공식 사례 3: TH04의 계산 해석과 컴파일 결과

TH04 사례는 16비트 DOS 실행 파일에서 탄환 방향 계산을 조사합니다. REA의 명령어와 참조를 유지보수 중인 C++ 재구성과 연결하고, 재구성 프로젝트의 컴파일 비교 결과를 함께 제시합니다. TH04 공식 사례

소개된 2,139바이트 일치는 해당 함수를 포함한 탄환 생성 코드 구간의 결과입니다. 설명용으로 단순화한 C++ 조각 자체에 적용되는 숫자가 아니며, 전체 게임의 조작·타이밍·하드웨어 동작과도 구분됩니다.

이미 존재하는 재구성 작업에 REA의 조사를 연결한 부분도 있습니다. 따라서 전체 성과를 REA가 처음부터 단독으로 만들어냈다고 해석하지 않는 것이 중요합니다. 사례를 읽을 때는 도구의 기여와 프로젝트 전체의 작업을 분리하세요.

소스 복원·동작 재현·기능 재구현의 차이

읽기 쉬운 의사코드가 나왔다고 원래 개발자가 작성한 소스가 돌아온 것은 아닙니다. 이름·주석·설계 의도에 관한 설명은 별도 근거가 필요합니다. 반대로 원본 소스와 문장 단위로 같지 않아도 정해진 입력에서 같은 출력을 내는 구현은 만들 수 있습니다.

평가 기준을 먼저 정하세요. 반환값 비교인지, 오류 처리까지 포함한 동작 비교인지, 같은 컴파일 조건의 바이트 일치인지에 따라 필요한 작업이 달라집니다. 일부 입력의 성공을 지원 대상 전체의 정확도로 환산하지 않습니다.

분석 대상이 크거나 난독화와 동적 로딩에 의존한다면 한 번의 정적 결과로 설명 범위를 넓히기 어렵습니다. 직접 관측한 경로와 아직 가설인 경로를 분리한 보고서가 더 유용합니다.

비용·설치·데이터 전달에서 확인할 조건

REA 자체 코드는 MIT로 배포되지만 외부 분석 도구의 라이선스까지 포함하지는 않습니다. 비용은 REA, 분석 엔진, 모델 이용, 분석 컴퓨터 자원과 재검토 시간으로 나누어 계산하세요. REA 라이선스 · 외부 구성요소 고지

공식 설치 과정은 연결할 에이전트와 변경 경로를 제시하고 설정을 적용합니다. MCP 등록과 조사 지침 설치는 분석 엔진 준비와 별개입니다. 프로젝트의 main 문서에 있는 기능이 사용 중인 배포판에도 있는지 함께 확인하는 것이 좋습니다. 설치·업데이트 조건

REA가 로컬에서 분석한다는 사실은 전체 작업이 오프라인이라는 뜻이 아닙니다. 도구 출력이 에이전트와 모델 제공자에게 전달될 수 있습니다. 원본 파일 전송 여부뿐 아니라 코드 조각·문자열·경로가 출력에 포함되는지도 검토하세요. 공식 데이터 처리 FAQ

정적 파일 조사와 대상 실행·상호작용을 구분하세요. 동적 조사에는 실행 계정의 권한과 네트워크 접근이 영향을 줍니다. 분석 출력 속 문장은 조사 대상의 내용으로 취급하고 에이전트의 실행 지시로 받아들이지 않는 구성이 필요합니다.

도구 권한과 입력 처리의 경계는 MCP 서버와 Prompt Injection 보안 설정 글도 함께 참고하세요.

작은 더미 프로그램으로 도입 효과 판단하기

도입 평가에는 직접 만든 작은 프로그램을 사용하는 방법을 권합니다. 예를 들어 숫자 목록을 받아 범위를 검사하고 요약값을 계산하는 더미 프로그램을 준비하세요. 구현을 아는 담당자는 정상값·경계값·오류 입력의 기대 결과를 별도로 보관합니다.

조사 담당자는 먼저 바이너리나 패키지만 보고 입력 조건과 분기를 설명하게 합니다. 이후 기대 결과와 대조해 근거가 맞는 설명, 추론이 빗나간 설명, 추가 질문으로 해결된 부분을 나눕니다. 자동으로 생성된 테스트만 사용하면 구현과 테스트가 같은 오해를 공유할 수 있습니다.

아래는 자체 제작한 대상에 사용할 조사 요청 예시입니다. 특정 상용 프로그램의 기능이나 공식 사례의 코드를 재사용하지 않습니다.

어떤 업무에 REA를 도입할 가치가 있는가

REA는 질문과 완료 기준을 좁힐 수 있는 조사에서 평가하기 좋습니다. 반복적인 근거 수집 시간을 줄이는지, 사람이 추론 오류를 발견하기 쉬워지는지를 함께 살펴보세요.

사용 권한과 결과 공개 범위는 분석 대상별로 정해야 합니다. 프로젝트도 소유하거나 분석 권한이 있는 소프트웨어의 연구·교육·상호운용성 등의 용도를 안내합니다. REA의 배포 라이선스를 대상 프로그램이나 재구성 결과의 권리로 확대 해석하지 않습니다. 프로젝트 이용 원칙

FAQ

Lambda MicroVMs는 어떤 문제를 해결하는가

AWS Lambda MicroVMs는 사용자·작업별로 격리된 실행 환경을 만들고, 필요할 때 중지와 재개를 제어하는 관리형 컴퓨팅 서비스입니다. AI가 생성한 코드 실행이나 사용자별 개발 환경처럼 세션 단위의 격리가 필요한 경우에 적합합니다. 상시 서버를 그대로 옮기기보다는 수명, 접속 경로와 상태 저장 조건부터 비교해야 합니다. Lambda MicroVMs 개요

이 글은 관리형 Lambda MicroVMs의 도입 판단을 다룹니다. Firecracker를 직접 설치하는 방법이나 다른 AWS 서비스 내부의 microVM 구현을 같은 제약으로 취급하지 않습니다. 특히 일반 Lambda 함수의 제한을 MicroVMs에 그대로 적용하면 설계를 잘못 판단할 수 있습니다.

microVM·Firecracker·컨테이너의 관계

microVM은 필요한 장치와 기능을 줄인 경량 가상머신입니다. Firecracker는 Linux KVM을 활용해 microVM을 실행하는 가상머신 모니터입니다. 일반적인 Linux 컨테이너의 호스트 커널 공유와 달리, 하드웨어 가상화를 이용하는 VM 경계를 제공합니다. Firecracker 공식 프로젝트

Lambda MicroVMs에서는 AWS가 제공하는 실행 기반 위에 애플리케이션을 구성합니다. 사용자는 세션을 어떤 환경에 배정할지, 어떤 권한과 네트워크 접근을 허용할지, 결과를 어디에 저장할지를 설계해야 합니다. 관리형이라는 이유로 애플리케이션 수준의 사용자 격리가 자동으로 완성되는 것은 아닙니다.

이미지 생성과 스냅샷 복원으로 시작하는 구조

애플리케이션과 Dockerfile을 Amazon S3에 제공하면 서비스가 환경을 빌드하고 초기화된 상태의 스냅샷을 생성합니다. 새 MicroVM은 이 상태를 복원해 시작합니다. MicroVM의 관리형 기반 운영체제와 Dockerfile의 컨테이너 기반 이미지는 구분해야 합니다. 이미지와 실행 환경의 관계

가상의 코드 실행 서비스라면 공통 도구는 이미지에 넣고, 사용자별 작업 위치와 접근 권한은 시작 시 정하는 구성이 적합합니다. 이미지 업데이트와 기존 사용자 세션의 교체도 별도 작업으로 계획합니다.

구성 흐름: 애플리케이션 준비 → 이미지 빌드·초기화 → 스냅샷 생성 → 사용자 요청에 맞춘 MicroVM 시작 → 인증된 엔드포인트 접속 → 결과 외부 저장 → 중지 또는 종료.

일반 Lambda 함수와 다른 세션 운영 방식

이벤트 처리 함수는 입력 이벤트를 처리하고 결과를 반환하는 단위로 설계하는 반면, MicroVMs는 사용자 작업 환경을 만들고 수명주기를 제어하는 용도에 초점이 있습니다. 함수 호출 횟수와 사용자 세션 수를 같은 기준으로 계산하지 마세요.

MicroVM마다 전용 엔드포인트가 있으며, 하나의 엔드포인트가 여러 MicroVM으로 자동 부하 분산되지는 않습니다. 사용자와 MicroVM의 매핑, 신규 환경 생성과 불필요한 환경 정리는 애플리케이션에서 다뤄야 합니다. 실행과 동시성 관리

설계 예시로 세션 저장소에 사용자 식별자, MicroVM 식별자와 작업 상태를 연결할 수 있습니다. 사용자가 제출한 MicroVM 식별자만 믿고 토큰을 발급하지 말고, 해당 환경의 소유권을 먼저 확인하는 방식이 좋습니다.

네트워크: HTTPS 진입점과 VPC 송신을 구분하기

인바운드는 서비스 관리 HTTPS 엔드포인트를 통합니다. HTTP/1.1·HTTP/2·WebSocket·gRPC·SSE를 지원하며 기본 대상 포트는 8080입니다. 다른 내부 포트로 전달하려면 포트 지정과 토큰의 허용 포트 범위가 맞아야 합니다. 네트워크와 포트 라우팅

기본 아웃바운드는 인터넷 접근입니다. 사설 DB 등으로 나가는 트래픽은 VPC egress connector로 구성합니다. 커넥터는 실행 시 지정하며 실행 중 교체할 수 없습니다. 이를 EC2처럼 임의의 TCP·UDP 포트를 외부에 개방하는 방식과 혼동하지 마세요.

PrivateLink는 관리 API용 lambda 엔드포인트와 애플리케이션 연결용 lambda-microvm 엔드포인트가 구분됩니다. VPC egress를 설정했다고 인바운드까지 자동으로 사설화되는 것은 아닙니다.

고정 송신 IP가 필요한 설계라면 MicroVM 자체에 고정 공인 IP를 할당한다고 가정하지 말고 VPC 송신 경로를 검토하세요. DNS, 라우팅, 보안 그룹과 외부 목적지의 허용 정책은 별도 점검 대상입니다.

사설 연결의 비용과 관리 범위는 VPC Endpoint 설계 글을 함께 참고하세요.

접속 세션: 토큰·셸·장시간 연결의 제약

애플리케이션 접속 토큰은 MicroVM과 허용 포트, 유효기간에 연결됩니다. 셸은 별도 토큰을 사용하며 시작할 때 SHELL_INGRESS가 연결되어 있어야 합니다. 콘솔의 Connect 기능을 제공하지만, 이를 공인 IP의 22번 포트로 직접 SSH 접속하는 방식으로 설명하면 안 됩니다. 접속 및 셸 인증 · 셸 접근과 접속 오류

장시간 연결에서는 앱 로그인 세션, 접속 토큰, 실제 네트워크 연결, MicroVM 수명을 따로 관리해야 합니다. 토큰을 갱신했다고 이미 끊긴 연결이나 종료된 환경이 복구되는 것은 아닙니다. 재접속 시 기존 작업을 이어받을지 새 작업을 만들지도 정해야 합니다.

연결이 끊기면 토큰 유효기간과 idle 정책을 함께 확인합니다. WebSocket에는 ping/pong 등 연결 유지와 재연결 처리를 설계하되, 지원 프로토콜이라는 사실을 무제한 연결 보장으로 해석하지 마세요. 토큰 만료 시 기존 연결이 끊기는 정확한 시점을 임의의 숫자로 전제하지 않습니다.

수명 8시간과 중지·재개 정책에서 놓치기 쉬운 점

maximumDurationInSeconds는 실행과 일시 중지를 합한 전체 수명이며 최대 28,800초, 즉 8시간입니다. 중지한 시간만큼 만료가 연장되는 구조가 아닙니다. idle 판단은 엔드포인트 트래픽을 기준으로 하므로 외부로만 통신하는 백그라운드 작업은 자동 중지 정책을 별도로 검토해야 합니다. 수명과 idle 정책

재개 시에는 연결 재설정과 자격증명 갱신을 /resume 훅에서 처리합니다. /suspend 훅에서는 쓰기 반영과 연결 정리를 계획하세요. 자동 재개는 첫 요청에 추가 지연을 만들 수 있고 실패 시 502가 반환될 수 있습니다.

가상 예시로 오전에 만든 작업 환경을 오후까지 보존하려면 남은 전체 수명을 계산해야 합니다. 오래 걸리는 작업은 중간 결과를 외부에 저장하고 새 환경에서 이어가는 구조로 설계하는 편이 안전합니다.

CPU·메모리·디스크와 운영체제 조건

Lambda MicroVMs는 ARM64를 지원합니다. x86 전용 실행 파일을 그대로 포함하지 말고 의존성의 아키텍처를 확인하세요. 관리형 기반은 Amazon Linux 2023이며 애플리케이션 컨테이너는 Linux와 대상 아키텍처에 맞아야 합니다. MicroVMs 할당량 · 이미지와 자원 구성

아래는 대표 크기입니다. 메모리 기준값에 따라 CPU가 비례하며 피크 자원은 기준값의 최대 4배입니다. 피크 확대는 디스크 확장이나 세션 수평 확장을 뜻하지 않습니다.

추가 Linux capability 설정은 ALL만 지원하며 VM 내부 경계에 적용됩니다. 이를 호스트 접근이나 임의 커널 교체 권한으로 해석하면 안 됩니다. GPU·중첩 가상화가 필수라면 이 CPU·메모리 구성표만으로 요구를 충족한다고 판단하지 말고, 해당 기능을 명시적으로 제공하는 실행 환경을 후보에 넣으세요.

연결 수·대역폭·계정 할당량을 따로 계산하기

MicroVM당 동시 연결 한도는 1·2·4·8·16 vCPU에 대해 각각 8·16·32·64·128개입니다. RPS 예시는 4 vCPU/8 GB에서 40, 16 vCPU/32 GB에서 160입니다. 이는 성능 보장 수치가 아니라 서비스 한도이며, 중간 크기의 RPS를 임의로 보간하지 마세요. 연결과 요청 한도

엔드포인트 요청·응답 대역폭은 기준 크기의 영향을 받습니다. 기준 2 GB/1 vCPU는 4 MB/s, 8 GB/4 vCPU는 16 MB/s입니다. 이 값을 모든 VPC 송신 트래픽의 한도로 확대 해석하지 않습니다. 엔드포인트 대역폭

계정별 메모리 할당량과 API 호출 한도도 별개입니다. 기본 RunMicrovm은 초당 5회이며 증설 요청 대상입니다. 접속 폭주에 대비해 생성 요청을 큐로 조절하고, 계정의 적용 할당량과 대상 리전 제공 조건을 도입 전에 확인하세요.

산정 예시로 사용자 100명이 각각 연결 두 개를 여는 서비스에서는 사용자 수뿐 아니라 MicroVM 배정 방식과 연결 수를 계산해야 합니다. 다운로드가 많으면 CPU보다 엔드포인트 대역폭이 먼저 병목이 될 수 있습니다.

스냅샷 보존과 영구 데이터 저장은 다르다

이미지 스냅샷에는 초기화된 메모리와 디스크, 파일 디스크립터 등의 상태가 포함됩니다. 이미지 빌드 때 생성한 고유 값은 여러 환경에 복제될 수 있으므로 사용자별 식별자와 비밀정보는 시작 후 설정해야 합니다. 연결도 복원된 값이 있다는 이유만으로 유효하다고 가정하지 마세요. 스냅샷 호환성과 고유 값 처리

자체 기반 이미지에서 OpenSSL을 사용한다면 스냅샷 호환 패치 조건도 확인합니다. AWS가 안내하는 기반 이미지 또는 해당 패키지 조건을 따르고, 이미지에 살아 있는 사용자 세션을 굳혀 넣지 않습니다.

일시 중지 상태 보존은 업무 데이터 백업 정책을 대신하지 않습니다. 완료 결과와 작업 진행 상태는 외부 저장소에 저장하고, 종료 훅 하나에만 마지막 저장을 의존하지 않는 구성이 좋습니다. 새로운 MicroVM이 이전 작업을 이어갈 수 있도록 저장 키와 재시도 규칙을 정하세요.

보안과 운영: 격리 이후에도 남는 책임

빌드 역할과 실행 역할을 구분하고 각각 필요한 S3·로그·업무 서비스 접근만 허용합니다. VM 격리가 있어도 코드에 부여한 IAM 권한으로 가능한 작업은 별도 통제가 필요합니다. IAM 역할과 접근 제어

이미지의 기반 버전이 변경되면 애플리케이션 이미지를 다시 빌드하는 절차를 마련합니다. 운영 로그에는 토큰이나 비밀정보 대신 세션과 실행 환경을 추적할 수 있는 내부 상관관계 값을 기록하는 구성이 좋습니다.

403은 토큰과 허용 포트를, 429는 요청 한도와 재시도를, 502는 애플리케이션 응답과 재개 상태를 우선 확인합니다. 같은 오류 코드라도 앱이 직접 반환한 것인지 서비스 엔드포인트에서 발생했는지 구분하세요. 오류별 점검 안내

EC2·ECS/Fargate·Lambda 함수 중 무엇을 선택할까

다음 표는 제품 순위가 아니라 업무의 성격에 따른 선택 방향입니다. 사용자별 환경 생성과 정리가 핵심인지, 계속 동작하는 서비스 운영이 핵심인지 먼저 구분하세요.

MicroVMs를 선택한다면 세션 매핑·토큰 발급·결과 저장을 포함한 작은 관리 계층이 필요합니다. 기존 컨테이너 서비스를 이미 안정적으로 운영하고 있다면 격리와 중지·재개의 이점이 전환 비용보다 큰지 비교하는 것이 좋습니다.

컨테이너 서비스 선택은 EKS·ECS·Fargate 비교 글에서 이어서 볼 수 있습니다.

비용과 도입 전 판단표

비용은 실행 컴퓨팅, 스냅샷 읽기·쓰기 및 저장, 데이터 전송으로 나눠 봅니다. 실행 중에는 기준 자원 비용과 기준 초과 사용 비용을 고려합니다. 일시 중지 상태에서는 컴퓨팅 비용이 없어도 스냅샷 저장 비용이 남습니다. AWS Lambda 요금

짧은 유휴 시간마다 중지·재개하면 저장 작업과 재개 지연이 늘 수 있습니다. 세션당 총비용은 활성 시간만 아니라 중지 빈도, 저장된 상태 크기, 데이터 전송을 함께 비교하세요. CloudWatch·S3·VPC 구성 등 주변 서비스 비용도 별도로 계산합니다.

지원 리전과 계정 할당량은 도입 대상 환경에서 확인합니다. 일반 Lambda를 사용할 수 있다는 사실만으로 MicroVMs도 같은 조건이라고 가정하지 말고, 선택 리전의 서비스 제공과 실제 할당량을 먼저 확인하세요.

FAQ

AI의 한계는 직업이 아니라 업무 단위로 판단한다

AI가 사람의 직업 전체를 할 수 있는지 묻기보다, 하나의 업무를 입력·처리·출력·책임으로 나누어 판단하는 편이 정확합니다. 같은 보고서 작성도 자료 분류와 초안 생성은 AI가 맡을 수 있지만, 사실 확인과 최종 승인은 사람이 담당할 수 있습니다.

AI의 성능은 업무 조건에 따라 달라집니다. 공개된 문서를 정해진 형식으로 요약하는 일과, 조직의 암묵적 맥락을 이해해 예외를 승인하는 일은 난이도와 위험이 다릅니다. 따라서 모델 이름이나 점수만으로 자동화 범위를 결정하면 안 됩니다.

NIST AI RMF는 AI가 지원할 구체적인 업무, 지식의 한계, 사람이 결과를 사용하는 방법과 감독 책임을 정의하도록 안내합니다. NIST AI RMF Core

AI가 비교적 잘하는 일

AI는 입력과 성공 기준이 분명하고 결과를 빠르게 확인할 수 있는 업무에 적합합니다. 문서 요약, 내용 분류, 정해진 항목 추출, 초안 작성, 형식 변환, 코드 설명과 반복적인 비교 작업이 대표적입니다.

검색·계산·데이터베이스·업무 시스템 같은 도구를 연결하면 모델이 기억에만 의존하지 않고 외부 결과를 사용할 수 있습니다. 정해진 절차를 따르는 Workflow는 단계와 분기 조건이 명확한 작업에, Agent는 필요한 단계가 사전에 고정되기 어려운 탐색형 작업에 더 적합합니다.

다만 잘한다는 말은 항상 정확하다는 뜻이 아닙니다. 입력 범위, 허용 도구, 출력 형식과 완료 조건을 정하고 실제 업무 사례로 평가해야 합니다.

AI에게 그대로 맡기기 어려운 일

AI는 사실과 그럴듯한 설명을 항상 구분하지 못하며, 입력에 없는 조직의 사정이나 사람의 의도를 자동으로 알 수 없습니다. 최신 정보가 필요한데 검색 수단이 없거나 근거가 불완전하면 답변의 표현이 자연스러워도 내용은 틀릴 수 있습니다.

법적 책임, 인사 결정, 의료·안전 판단, 큰 금액의 승인처럼 오류 피해가 큰 업무는 모델 출력만으로 종결하면 안 됩니다. 가치 충돌을 조정하고 결과에 책임지는 역할도 사람이나 명확한 조직 절차가 맡아야 합니다.

새로운 예외 상황, 서로 모순되는 근거, 실제 시스템 변경처럼 되돌리기 어려운 행동도 주의가 필요합니다. AI가 초안을 만들거나 선택지를 비교할 수는 있지만, 권한 행사와 최종 결정은 별도 통제가 필요합니다.

AI 단독·사람 검토·사람 전담으로 나누는 기준

업무 분리는 AI 사용 여부를 이분법으로 정하는 작업이 아닙니다. 위험과 검증 방법에 따라 자동화 수준을 세 단계로 정하고, 같은 업무 안에서도 단계마다 담당을 다르게 배치합니다.

낮은 위험의 반복 업무부터 시작하고, 검토 결과와 실패 사례가 쌓일 때만 자동화 범위를 넓히는 방식이 안전합니다.

자동화 전에 확인할 네 가지 질문

첫째, 틀렸을 때 피해가 얼마나 큰지 확인합니다. 둘째, 정답이나 허용 범위를 기계 규칙 또는 사람이 빠르게 확인할 수 있는지 봅니다. 셋째, 업무에 필요한 맥락이 문서와 데이터로 제공되는지 확인합니다. 넷째, AI가 읽기·작성·삭제 중 어떤 권한까지 가져야 하는지 정합니다.

오류 비용이 낮고 검증이 쉬우며 필요한 맥락이 충분하고 권한이 제한적이면 자동화에 유리합니다. 반대로 하나라도 위험이 크다면 사람 검토, 승인 단계, 읽기 전용 도구 또는 자동 중단 조건을 추가합니다.

판단이 애매하면 처리량보다 실패 비용을 먼저 비교합니다. 시간 절감이 예상되더라도 잘못된 승인이나 데이터 변경 한 번의 복구 비용이 더 크다면 자동 실행 범위를 줄여야 합니다.

사람의 검토가 실제 통제가 되려면

사람이 마지막에 승인 버튼만 누른다고 효과적인 감독이 되는 것은 아닙니다. 검토자는 원본 근거, AI가 수행한 작업, 불확실한 부분과 변경 결과를 이해할 수 있어야 합니다. 검토할 시간과 거부 권한도 필요합니다.

검토 지점은 위험이 커지기 직전에 둡니다. 외부 발송, 데이터 삭제, 비용 발생, 권한 변경과 같이 되돌리기 어려운 행동은 실행 전에 승인받고, 낮은 위험의 읽기 작업은 사후 표본 검사로 운영할 수 있습니다.

NIST는 사람과 AI의 역할과 책임을 명확히 구분하고, 배포 환경과 유사한 조건에서 성능을 평가하며 운영 중 행동을 관찰하도록 제시합니다. 인간 검토도 정확도와 처리 시간, 놓친 오류를 함께 측정해야 합니다.

실무 도입 순서: 작은 업무부터 경계를 넓힌다

먼저 반복 빈도가 높고 실패 피해가 낮은 업무 하나를 선택합니다. 입력 범위와 기대 출력, 금지 행동, 중단 조건을 적고 과거 사례로 기준 성능을 측정합니다.

다음으로 AI 출력에 근거 표시, 구조화된 형식, 불확실할 때의 보류 상태를 포함합니다. 도구를 연결할 때는 읽기 권한부터 시작하고, 외부 변경은 승인 단계와 감사 기록을 둡니다.

운영 중에는 성공률만 보지 말고 잘못된 확신, 누락, 과도한 사람 의존, 비용과 지연시간을 함께 봅니다. 관련 설계는 Reliability와 Human Oversight 설계에서 더 자세히 확인할 수 있습니다.

AI는 어느 방향으로 발전하고 있는가

첫 번째 방향은 텍스트 답변을 넘어 이미지·음성·영상과 화면을 함께 이해하고 다루는 멀티모달 능력의 확장입니다. 두 번째는 검색, 코드 실행, 파일과 업무 시스템을 사용하는 도구 활용입니다. 세 번째는 여러 단계의 목표를 계획하고 중간 결과를 확인하는 Agent형 실행입니다.

능력이 커질수록 평가와 통제의 중요성도 커집니다. Agent는 여러 번 도구를 호출하며 상태를 바꾸기 때문에 한 번의 정답 평가만으로 충분하지 않습니다. 작업 완료 여부, 경로의 안전성, 비용, 중단과 복구 능력을 함께 측정해야 합니다.

Anthropic은 예측 가능한 절차에는 Workflow를, 필요한 단계 수를 미리 정하기 어려운 문제에는 Agent를 고려하되 단순한 방식으로 해결되지 않을 때만 복잡성을 늘리라고 설명합니다. Building Effective Agents

발전 속도보다 중요한 것은 재평가 가능한 경계다

AI 능력은 빠르게 변하지만 모든 영역이 같은 속도로 발전하지 않습니다. OECD AI Capability Indicators도 언어, 추론, 사회적 상호작용, 로봇 조작 등 서로 다른 능력을 나누어 평가합니다. OECD AI Capability Indicators

따라서 오늘의 업무 분류를 영구 규칙으로 만들지 않습니다. 모델, 도구, 데이터와 규제가 바뀔 때 같은 테스트 세트로 다시 평가하고, 성능이 좋아져도 책임과 권한 구조는 별도로 검토합니다.

좋은 AI 도입의 목표는 사람을 최대한 제거하는 것이 아니라, 기계가 잘하는 반복과 탐색을 맡기고 사람이 목표·예외·책임에 집중하도록 업무를 다시 설계하는 것입니다.

FAQ

EKS 업그레이드, 어떤 클러스터부터 진행할까

EKS 업그레이드는 지원 종료가 가까운 클러스터부터 시작하되, 목표 버전에서 제거되는 API와 노드 운영체제 호환성을 함께 확인해야 합니다. 표준 지원 종료는 비용과 업그레이드 정책이 달라지는 경계이고, 연장 지원 종료는 해당 버전을 계속 유지할 수 없는 경계입니다.

이 글은 EKS 1.31~1.36을 운영하거나 해당 구간을 순차적으로 업그레이드하는 담당자를 대상으로 합니다. 모든 신규 기능을 나열하기보다 기존 배포를 막을 수 있는 API·AMI·런타임·스토리지 변경을 중심으로 정리합니다.

운영 계획표에는 현재 버전, 목표 버전, 지원 종료일, 필요한 중간 단계, 영향을 받는 구성, 담당자와 전환 창구를 기록합니다. 여러 클러스터를 운영한다면 같은 노드 이미지와 Add-on 조합을 사용하는 비운영 클러스터를 먼저 전환하는 구성이 적합합니다.

버전별 EOS 일정표: 표준 지원과 연장 지원

Amazon EKS의 지원 기간은 EKS 출시일부터 표준 지원 14개월, 이후 연장 지원 12개월입니다. Kubernetes 커뮤니티의 지원 종료와 EKS 지원 종료는 같은 날짜가 아닙니다. 아래 날짜는 UTC 기준입니다. EKS 버전 수명주기와 공식 일정표

일정표에서 자신의 버전을 찾은 뒤 표준 지원 종료일과 연장 지원 종료일을 각각 작업 계획에 반영합니다. 작업 직전에는 링크의 최신 일정과 해당 리전에서 제공되는 버전을 확인합니다.

연장 지원 비용과 자동 업그레이드 정책

EXTENDED 정책에서는 표준 지원이 끝난 버전을 연장 지원 기간에 유지할 수 있으며 클러스터 시간당 추가 비용이 발생합니다. STANDARD 정책에서는 표준 지원 종료 후 자동 업그레이드 대상이 됩니다. 기본 정책에 의존하기보다 클러스터별 설정을 확인하세요. 클러스터 업그레이드 정책

연장 지원 종료 후 자동 업그레이드의 정확한 시각을 운영자가 선택할 수는 없습니다. 자동 처리에 맡기기보다 애플리케이션과 노드의 전환 일정을 먼저 잡는 편이 운영 영향을 통제하기 쉽습니다.

비용 판단에는 연장 지원 클러스터 수와 유지 시간뿐 아니라 노드 교체 중 임시 증설, 테스트 환경, 운영 작업 비용도 포함합니다. 실제 단가는 Amazon EKS 요금에서 확인하고, 버전 유지 비용과 전환 비용을 같은 기간으로 비교합니다.

비용 항목의 기본 구성은 EKS 비용 구조 정리에서 이어서 볼 수 있습니다.

사전 점검: 현재 버전과 Upgrade Insights 확인

아래는 조회 명령입니다. AWS CLI가 구성되어 있고 EKS 조회 권한과 대상 클러스터에 연결된 kubectl 컨텍스트가 있어야 합니다. YOUR_CLUSTER와 YOUR_REGION을 자신의 값으로 바꾼 뒤 현재 컨텍스트가 대상 환경인지 먼저 확인합니다.

Upgrade Insights는 제거 예정 API 등 업그레이드 준비 상태를 확인하는 출발점입니다. 결과가 양호해도 외부 컨트롤러와 애플리케이션 동작까지 보장하는 것은 아니므로 각 제품의 지원 버전과 배포 구성을 함께 점검합니다. Cluster Insights 사용 방법

실행 중인 객체 외에도 저장소의 Helm 차트, 배포 파일, 배치 작업과 외부 자동화가 호출하는 API를 살펴봅니다. 평소 실행되지 않는 월간 작업은 현재 Pod 목록만으로 찾기 어렵습니다.

1.31 → 1.32: 제거 API와 인증 호출 확인

1.32에서는 FlowSchema와 PriorityLevelConfiguration의 flowcontrol.apiserver.k8s.io/v1beta3 API가 제거됩니다. 이 API를 사용하는 배포 정의와 클라이언트를 v1으로 전환해야 합니다. Kubernetes API 제거 및 이전 안내

또한 익명 API 접근은 healthz·livez·readyz로 제한됩니다. 인증 없이 다른 경로를 호출하던 상태 점검 도구는 401 응답의 영향을 확인해야 합니다. ServiceAccount의 kubernetes.io/enforce-mountable-secrets 주석은 폐기 예정 상태이므로 제거된 API와 구분해서 다룹니다. EKS 1.32 변경 사항

우선 API 접근 주체와 사용 경로를 목록화하고, 인증정보를 명시한 상태 점검으로 전환합니다. 권한을 넓히기 전에 필요한 API와 읽기 권한만 정하는 것이 좋습니다.

1.32 → 1.33: AL2 노드와 Endpoints 의존성 점검

EKS 최적화 Amazon Linux 2 AMI는 1.32가 마지막 지원 Kubernetes 버전입니다. 1.33 노드로 전환할 때는 AL2023 또는 요구 조건에 맞는 다른 지원 이미지로 이동하는 계획이 필요합니다. Endpoints는 1.33에서 폐기 예정으로 지정되며 즉시 제거되는 것은 아닙니다. EKS 1.33 변경 사항

AL2023 전환은 Kubernetes 버전 숫자만 바꾸는 작업으로 다루지 않습니다. 사용자 지정 시작 템플릿, 노드 초기화 설정, 보안 에이전트와 DaemonSet의 운영체제 지원을 함께 살펴봅니다. AL2023 노드 전환 안내

새 노드 그룹을 소규모로 추가하고 애플리케이션 배치, 이미지 다운로드, 로그 수집과 볼륨 연결을 점검한 뒤 이동 범위를 늘리는 방법을 고려하세요. Endpoints를 직접 읽는 자체 도구는 EndpointSlice 지원 여부를 별도로 확인합니다.

1.33 → 1.34: containerd와 CSI 구성 확인

EKS 1.34 출시 구성에는 containerd 2.1이 포함됩니다. VolumeAttributesClass는 storage.k8s.io/v1으로 안정화되므로 이를 사용하는 CSI 드라이버와 보조 컨테이너의 API 호환성을 확인합니다. EKS 1.34 변경 사항

컨트롤 플레인 버전을 올렸다는 사실만으로 기존 노드의 런타임도 바뀌었다고 판단하면 안 됩니다. 실제 사용할 AMI와 노드의 런타임 버전을 비교하고, 사설 이미지 저장소 인증과 보안 도구의 런타임 연동을 확인합니다.

스토리지 기능을 사용하는 서비스에서는 새 Pod의 볼륨 연결과 재배치 후 읽기·쓰기를 확인합니다. VolumeAttributesClass를 사용하지 않는 서비스에 해당 기능을 업그레이드 필수 작업으로 추가할 필요는 없습니다.

1.34 → 1.35: cgroup v1과 사용자 지정 kubelet 옵션

1.35의 kubelet은 기본적으로 cgroup v1 노드에서 시작을 거부합니다. AL2023은 기본 cgroup v2이지만 수동 변경한 노드는 별도 확인이 필요합니다. Fargate는 AWS 안내에 별도 동작이 명시되어 있으므로 같은 조치를 일괄 적용하지 않습니다. EKS 1.35 노드 변경 사항

사용자 지정 AMI에서는 제거된 --pod-infra-container-image 옵션도 확인합니다. 1.35는 containerd 1.x를 지원하는 마지막 버전이므로 다음 단계 전에 2.x 전환을 준비합니다.

노드가 Ready가 되는지만 보지 말고 모니터링·보안 에이전트의 CPU와 메모리 지표 수집이 유지되는지 살펴봅니다. cgroup 경로에 의존하는 도구라면 노드 운영체제와 함께 지원 범위를 확인하세요.

1.35 → 1.36: gitRepo·IP 표기·SELinux 볼륨

1.36에서는 gitRepo 볼륨이 영구 비활성화됩니다. 해당 Pod는 API가 받아들여도 kubelet 실행 단계에서 실패할 수 있으므로 init container 또는 git-sync 등으로 전환합니다. 기본 제공 API의 IP·CIDR 검사도 강화됩니다. EKS 1.36 변경 사항

SELinux enforcing 환경에서 볼륨을 공유한다면 레이블과 seLinuxChangePolicy를 확인합니다. 앞의 변경 사항은 사용 중인 볼륨 유형과 보안 설정에 따라 영향이 달라집니다.

배포 정의를 검색할 때 gitRepo 사용, 앞자리 0이 붙은 IP, 네트워크 주소와 맞지 않는 CIDR 표기를 함께 찾습니다. 기존 객체가 남아 있다는 이유만으로 재배포도 성공한다고 판단하지 말고 새 객체 생성과 변경 경로를 점검합니다.

실행 순서: 한 단계씩 컨트롤 플레인과 노드 정렬

EKS 마이너 버전은 한 단계씩 올립니다. 예를 들어 1.32에서 1.35로 이동하려면 1.33과 1.34를 거칩니다. 각 단계의 호환성을 확인한 뒤 다음 단계로 넘어가세요. EKS 클러스터 업그레이드 절차

기본 흐름은 호환성 준비 → 컨트롤 플레인 → 노드 교체 → 구성요소 정렬 → 서비스 점검입니다. Add-on은 현재와 목표 버전을 함께 지원하는 중간 버전이 필요할 수 있으므로 모든 Add-on을 무조건 마지막에 갱신하는 규칙으로 적용하지 않습니다.

관리형·자체 관리 노드는 컨트롤 플레인 업그레이드와 별도로 갱신합니다. Auto Mode는 관리 노드를 자동으로 갱신하는 흐름이 있으므로 배포 방식을 먼저 구분합니다. Fargate의 기존 Pod도 새 버전 반영을 위한 재배포 계획이 필요합니다.

노드 교체 계획은 EKS 워커 노드 설계 전략, 구성요소 관리 방식은 EKS Add-on과 Helm 설치 차이를 함께 참고하세요.

업그레이드가 멈출 때: 증상별 점검표

컨트롤 플레인 업데이트에는 연결 서브넷에서 최대 5개의 여유 IP가 필요할 수 있습니다. 노드 교체용 용량과 Pod IP 여유는 별도로 계산합니다. 컨트롤 플레인 사전 조건

노드 배출이 막히면 PDB와 실제 가용 복제본을 먼저 확인합니다. 강제 옵션은 서비스 가용성 요구를 무시할 수 있으므로 기본 해결책으로 사용하지 않습니다. 관리형 노드 업데이트 동작

완료 판단과 복구 계획: 롤백 조건까지 준비

완료 기준은 클러스터 버전 표시 외에도 새 Pod 배포, DNS 조회, 외부 트래픽, 볼륨 읽기·쓰기, 로그·지표 수집으로 정합니다. 정기 작업이 있다면 평소 실행 주기와 별도로 주요 동작을 확인하는 계획을 세웁니다.

EKS는 인플레이스 업그레이드 완료 후 7일 이내 이전 마이너 버전으로 롤백할 수 있습니다. 대상 버전이 지원 중이어야 하며 연장 지원 버전으로 돌아가려면 EXTENDED 정책이 필요합니다. 연장 지원 종료에 따른 자동 업그레이드는 롤백 대상이 아닙니다. 롤백 지원 조건과 절차

버전 롤백은 데이터 복원이 아닙니다. Add-on과 노드도 방식별 조치가 필요하고 새 버전 전용 기능이 롤백을 막을 수 있습니다. 배포 정의와 데이터 백업, 애플리케이션 되돌리기 절차는 별도로 준비합니다.

FAQ

먼저 알아야 할 진단 순서

문제를 해결할 때는 AWS 콘솔의 Target Health만 바로 수정하려고 하면 안 됩니다. Controller가 Kubernetes 리소스를 정상적으로 읽었는지부터 확인해야 원인을 빠르게 좁힐 수 있습니다.

권장 순서는 Controller 상태 → Ingress 또는 Service 이벤트 → TargetGroupBinding → EndpointSlice → AWS Target 등록 → Health Check → Security Group입니다. 앞 단계가 실패하면 뒤 단계의 리소스는 생성되지 않거나 불완전하게 남습니다.

Controller가 AWS 리소스를 만드는 흐름

AWS Load Balancer Controller는 Kubernetes API에서 Ingress, Service 또는 지원되는 Gateway API 리소스를 감시합니다. 선언된 상태를 읽고 AWS API를 호출해 Load Balancer, Listener, Rule, Target Group, Security Group 같은 리소스를 구성합니다.

Ingress의 L7 경로는 일반적으로 ALB로 구현되고, type: LoadBalancer Service의 L4 경로는 NLB로 구현됩니다. Controller는 변경을 계속 감시하며 실제 AWS 구성을 선언된 상태에 맞춥니다. 따라서 관리 중인 AWS 리소스를 콘솔에서 직접 수정하면 이후 조정 과정에서 되돌아갈 수 있습니다.

TargetGroupBinding의 역할

TargetGroupBinding은 Kubernetes Service와 AWS Target Group의 관계를 표현하는 Custom Resource입니다. 기존 Target Group을 Service에 연결할 때 직접 만들 수도 있고, Controller가 Ingress·Service·Gateway를 처리하면서 같은 Namespace에 자동으로 만들 수도 있습니다.

이 리소스가 존재한다는 사실만으로 연결이 정상이라는 뜻은 아닙니다. serviceRef의 이름과 포트가 실제 Service와 맞는지, Service에 준비된 Endpoint가 있는지, Controller 이벤트에 등록 실패가 기록됐는지 함께 확인해야 합니다.

증상과 확인 위치 구분

화면에 보이는 증상에 따라 처음 확인할 위치가 달라집니다. 아래 표는 원인을 단정하는 표가 아니라 조사 시작점을 고르는 기준입니다.

ALB 또는 NLB가 생성되지 않을 때

먼저 Controller Deployment와 Pod가 정상인지 확인합니다. 이어서 Ingress 또는 Service의 Events를 보면 AWS API 권한 부족, 유효하지 않은 Annotation, Subnet 선택 실패, Webhook 오류 같은 조정 실패 이유를 확인할 수 있습니다.

ingressClassName과 Controller의 감시 범위가 일치하는지 확인합니다. Controller의 cluster-name 설정이 실제 Cluster 이름과 다르면 Subnet 검색도 실패할 수 있습니다. 인터넷 공개와 내부용 구분, 서로 다른 AZ의 Subnet 수, 사용 가능한 IP도 함께 봐야 합니다.

Subnet 자동 검색 규칙은 Controller 버전에 따라 달라질 수 있습니다. 명시적인 Subnet 설정을 사용하지 않았다면 현재 설치 버전의 role tag와 reachability 기준을 확인해야 합니다.

Target이 등록되지 않을 때

Target Group이 만들어졌지만 등록 대상이 없다면 Kubernetes 쪽 연결부터 확인합니다. Ingress backend가 가리키는 Service 이름과 포트, Service selector와 Pod label, EndpointSlice에 표시되는 주소와 준비 상태가 일치해야 합니다.

ip 모드에서는 Pod IP가 Target이 되므로 AWS Load Balancer에서 해당 Pod IP로 접근할 수 있어야 합니다. instance 모드에서는 Worker Node와 NodePort가 Target 경로에 포함됩니다. Service 유형과 포트 구성이 이 경로에 맞아야 합니다.

TargetGroupBinding 이벤트에 등록 권한 오류가 있다면 Controller가 사용하는 IAM Role을 확인합니다. 단순 조회 권한만으로는 부족하며, 대상 등록과 해제에 필요한 Elastic Load Balancing API 권한이 있어야 합니다.

Target Health가 unhealthy일 때

대상이 등록됐다면 Target Health의 reason code를 먼저 확인합니다. Target.ResponseCodeMismatch는 응답 코드가 성공 조건과 다르고, Target.Timeout은 제한 시간 안에 응답하지 못했으며, Target.FailedHealthChecks는 연결 또는 응답 처리에 실패했다는 뜻입니다.

애플리케이션의 실제 Health Check 경로가 인증 없이 빠르게 응답하는지 확인합니다. 리디렉션이나 인증 응답을 정상으로 사용할 계획이라면 성공 코드 범위를 의도에 맞게 설정해야 합니다. 단순히 성공 범위를 넓혀 오류를 숨기지 말고 반환 코드의 원인을 먼저 확인해야 합니다.

Target Type과 네트워크 점검

instance 모드는 ALB가 NodePort를 통해 Node로 들어간 뒤 Pod로 전달합니다. ip 모드는 ALB가 Pod IP로 직접 전달합니다. 같은 Health Check 실패라도 실제 확인해야 할 대상과 포트가 달라집니다.

Security Group에서는 Load Balancer에서 backend의 Health Check 포트까지 허용되는지 확인합니다. Network ACL, Pod 보안 정책, 애플리케이션 수신 주소와 포트도 확인해야 합니다. 컨테이너가 localhost에만 바인딩되어 있으면 외부 Health Check가 도달하지 못할 수 있습니다.

readinessProbe와 Load Balancer Health Check는 목적과 실행 주체가 다릅니다. 둘의 경로와 성공 기준이 크게 다르면 Kubernetes에서는 준비된 Pod가 AWS에서는 unhealthy로 표시될 수 있으므로 운영 기준을 맞추는 것이 좋습니다.

진단 명령 모음

아래 명령은 구조 이해를 위한 더미 예시입니다. Namespace와 리소스 이름, TARGET_GROUP_ARN 환경변수는 자신의 환경에 맞게 설정해야 합니다.

명령 결과에 실제 리소스 식별자나 네트워크 정보가 포함될 수 있으므로 블로그나 외부 채널에 공유하기 전 반드시 마스킹해야 합니다.

실전 점검 순서

첫째, Kubernetes Events와 Controller 로그에서 최초 오류를 찾습니다. 둘째, Service selector와 EndpointSlice로 실제 backend가 존재하는지 확인합니다. 셋째, TargetGroupBinding이 올바른 Service와 Target Group을 연결하는지 확인합니다.

넷째, AWS Target Health의 state와 reason code를 확인합니다. 다섯째, 애플리케이션에서 Health Check 경로를 직접 호출해 응답 코드와 시간을 확인합니다. 마지막으로 Target Type에 맞춰 NodePort 또는 Pod IP 경로와 Security Group을 점검합니다.

이 순서를 따르면 Kubernetes 선언 문제, Controller 권한 문제, AWS 리소스 생성 문제, 애플리케이션 응답 문제를 섞지 않고 단계별로 분리할 수 있습니다.

참고 공식문서

주요 사실 확인에 사용한 공식 문서입니다.

FAQ

Pod IP 할당 실패인지 먼저 확인하기

EKS에서 Pod가 생성되지 않는다면 먼저 노드에 배치됐는지 확인하세요. 배치 전 FailedScheduling과 배치 후 네트워크 준비 실패는 진단 대상이 다릅니다. IP 할당 관련 메시지가 확인되면 실제 Pod용 서브넷의 주소, 노드 한도, Prefix 공간, CNI의 AWS API 호출 상태를 순서대로 좁혀갑니다.

이 글은 Amazon VPC CNI를 사용하는 일반 EKS EC2 Linux·IPv4 환경을 대상으로 합니다. Fargate, Auto Mode, Windows, IPv6 및 Calico 네트워킹 교체 환경에는 아래 명령과 판단을 그대로 적용하지 않습니다. Security Groups for Pods와 다중 인터페이스 사용 시에는 추가 인터페이스 구조도 확인해야 합니다.

ContainerCreating은 kubectl이 보여주는 상태이며 이것만으로 IP 부족을 뜻하지 않습니다. FailedCreatePodSandBox도 여러 원인으로 발생하므로 이벤트 본문에서 IP 할당 관련 오류를 확인해야 합니다. Kubernetes Pod 상태와 이벤트 진단

공식 문서 확인일은 2026년 9월 9일입니다. 아래는 Bash 계열 셸에서 사용하는 진단용 조회 명령 예시입니다. kubectl context와 AWS CLI 계정·리전을 먼저 맞추고 읽기 권한을 준비하세요. YOUR_로 시작하는 값은 자신의 확인 대상 값으로 교체합니다. PowerShell에서는 특히 JSONPath 인용부호 처리를 사용하는 버전에 맞춰 조정해야 합니다.

VPC CNI가 Pod IP를 할당하는 구조

기본 VPC CNI 구성에서는 노드에 연결한 ENI의 VPC 주소를 Pod에 사용합니다. 개별 보조 IP 모드와 Prefix 모드는 주소를 확보하는 단위가 다릅니다.

서브넷 주소 공간 → 노드 ENI → 개별 보조 IP 또는 Prefix → Pod IP. 이 흐름에서 ipamd가 주소 풀을 관리합니다. 이 구조는 기본 단일 인터페이스 구성의 이해를 위한 요약입니다. Amazon VPC CNI 주소 관리

서브넷이 충분해도 노드 한도에 걸릴 수 있고, Prefix 공간이 있어도 API 호출이 실패할 수 있습니다. 어느 단계가 막혔는지 나누어야 같은 Pending 상태에서도 맞는 조치를 선택할 수 있습니다.

첫 점검: 해당 노드의 aws-node와 로그 확인

문제 Pod의 NODE 값을 확인한 뒤 같은 노드에서 실행되는 aws-node를 찾습니다. 클러스터 전체 로그보다 장애 노드와 발생 시점을 맞추어 확인하세요. YOUR_AWS_NODE_POD는 첫 조회 결과의 Pod 이름으로 교체합니다.

describe 결과에서 이미지 버전, Ready 상태, 재시작과 환경변수를 확인합니다. --previous는 컨테이너가 재시작했고 이전 로그가 남아 있을 때만 사용할 수 있습니다.

kubectl logs에 IPAM 로그가 모두 나오는 것은 아닙니다. AWS_VPC_K8S_CNI_LOG_FILE이 파일 출력이면 설정된 수집 경로나 노드의 /var/log/aws-routed-eni/ipamd.log를 확인하세요. 컨테이너 내부 기본 경로는 /host/var/log/aws-routed-eni/ipamd.log입니다. IPAM 로그 저장 위치

조회 결과를 공유할 때는 계정·리소스 식별자를 제거하세요. 이 글은 실제 운영 로그를 사용하지 않습니다.

서브넷에 사용할 IP가 충분한가?

노드의 providerID에서 EC2 인스턴스를 식별하고 연결 ENI의 서브넷을 조회하세요. custom networking을 사용하면 Pod용 ENI가 노드의 기본 서브넷과 다른 서브넷에 있을 수 있습니다.

custom networking은 ENIConfig로 Pod용 서브넷 등을 지정합니다. 기능이 켜져 있다면 ENIConfig와 노드의 연결 설정도 대조하세요. ENIConfig 리소스 종류를 찾지 못하면 기능 사용 여부부터 확인합니다. Pod용 서브넷 선택

AvailableIpAddressCount는 사용할 수 있는 IPv4 주소 개수이며 연속된 /28 블록 수가 아닙니다. ENI나 Prefix로 이미 확보한 주소는 Pod에 배정하기 전이어도 서브넷의 가용 주소와 별도로 봐야 합니다. 서브넷 조회 필드

ENI 결과의 Subnet을 YOUR_SUBNET_ID로 넣어 각각 조회합니다. Prefix 목록과 개별 IP 배열도 구분하세요. ENI 조회 필터와 Prefix 필드

ENI·주소 한도와 maxPods 구분하기

Too many pods가 나오면 스케줄러가 보는 Pod 수 한도를 확인합니다. 반면 노드 배치 후 IP 할당 실패는 주소 확보 경로를 확인해야 합니다. CPU·메모리 부족으로 인한 배치 실패도 별도 원인입니다.

YOUR_INSTANCE_TYPE은 노드 조회 결과의 유형으로 교체하세요. AWS 조회는 유형의 기본 네트워크 한도를 보여줍니다. 실제 ENI와 Prefix는 앞 절 결과와 대조합니다. PrivateIpAddresses 배열 길이가 Prefix 안의 모든 Pod 주소를 포함한다고 가정하면 안 됩니다.

Prefix 모드는 주소 슬롯 사용 방식을 바꾸며 ENI 최대 수 자체를 늘리지는 않습니다. 관리형 노드 그룹의 AMI 지정 여부 등에 따라 maxPods 설정 방법이 다릅니다. 임의로 숫자만 높이지 말고 allocatable 값과 지원 조건을 확인하세요. Prefix와 최대 Pod 수 설정

노드 추가는 서브넷에 충분한 주소가 있는지 확인한 뒤 선택해야 합니다. 주소가 부족한 같은 서브넷에 노드를 더 만들면 해결이 되지 않을 수 있습니다.

Prefix Delegation을 켰는데도 실패하는 이유

IPv4 Prefix 할당에는 연속된 /28 공간이 필요합니다. 가상의 서브넷에 40개 여유 IP가 있어도 주소가 흩어져 있다면 필요한 블록을 확보하지 못할 수 있습니다. 이 숫자는 원리를 설명하기 위한 가정입니다.

InsufficientCidrBlocks가 보이면 연속 공간 부족을 검토하세요. 새 서브넷이나 Prefix용 CIDR 예약이 선택지입니다. 예약은 기존 사용 중 주소를 즉시 이동시켜 빈 블록을 만드는 기능은 아닙니다. Prefix 전제와 주소 단편화

Linux IPv4 Prefix는 VPC CNI 1.9.0 이상, Nitro 기반 노드 등의 조건을 확인해야 합니다. 최소 기능 버전이 현재 클러스터의 권장 버전을 의미하지는 않습니다. ENABLE_PREFIX_DELEGATION 설정과 실제 노드 조건을 함께 확인하세요.

아래 set env 명령은 --list를 붙인 조회입니다. 값 할당을 추가하지 말고 조회용으로 사용하세요. 실제 Pod 환경변수는 describe pod 결과와도 비교합니다.

Warm Pool 설정이 IP 사용량에 미치는 영향

CNI는 새 Pod를 위해 여유 주소를 준비하므로 실행 중 Pod 수와 확보 주소 수가 다를 수 있습니다. 노드당 평상시 Pod 수와 한 번에 늘어나는 Pod 수를 함께 보고 조정하는 것이 좋습니다.

Prefix 모드에서는 WARM_IP_TARGET 또는 MINIMUM_IP_TARGET을 지정하면 WARM_PREFIX_TARGET보다 우선합니다. 확보 단위 때문에 실제 여유 주소가 IP 목표와 딱 맞지는 않을 수 있습니다. Prefix Warm Pool 설정

MINIMUM_IP_TARGET은 전체 확보 주소의 하한입니다. 이를 지정하고 WARM_IP_TARGET을 생략하면 추가 할당에 영향을 줄 수 있으므로 버전별 안내를 확인하세요. 최소 확보 주소 설정

큰 여유 값은 서브넷 소모를 늘리고 너무 작은 값은 급격한 확장 때 추가 요청을 늘릴 수 있습니다. 정답 숫자를 고정하기보다 실제 Pod 증가량과 API 오류·주소 사용량으로 판단하세요.

IP 여유가 있어도 실패할 때: 권한·API·CNI 상태

같은 시각의 CNI 로그에서 UnauthorizedOperation·AccessDenied는 권한 경로, throttling·RequestLimitExceeded는 호출 제한, timeout은 DNS·연결 경로 등을 점검하는 단서입니다. 한 줄만으로 원인을 확정하지는 않습니다.

CNI의 IAM 역할은 애플리케이션이나 조회 명령 실행자의 역할과 다를 수 있습니다. IRSA·Pod Identity·노드 역할 중 실제 사용 방식을 확인하세요. 관리형 Add-on이 없다는 조회 오류가 나더라도 자체 관리 방식의 aws-node가 설치되어 있을 수 있습니다.

인터넷 접근을 제한한 환경에서는 EC2 API를 위한 Endpoint·보안 그룹·DNS를 확인합니다. 자격증명 방식에 따라 STS 또는 EKS Auth 접근도 필요할 수 있습니다. Private EKS 서비스별 Endpoint

aws-node 자체가 Ready가 아니면 이미지 다운로드·초기화 이벤트부터 확인하세요. 주소가 충분해도 CNI가 정상 기동하지 않으면 주소 할당이 진행되지 않을 수 있습니다.

Pod Identity 연결 목록에는 실제 IAM 역할이 생략됩니다. 연결이 있으면 associationId를 YOUR_ASSOCIATION_ID로 바꿔 상세 조회하세요. Pod Identity 연결 조회의 반환 범위

증상별 진단표와 조치 선택

아래 표는 관찰값을 연결하는 진단 제안입니다. 변경 전 오류 시각, 노드·서브넷, CNI 설정과 한도를 기록하세요. 재시작만으로 주소 고갈·단편화·권한 부족이 해결된다고 가정하지 마세요.

Prefix 전환은 새 노드 그룹을 준비해 검증하는 방안을 비교하세요. AWS도 새 노드 그룹과 기존 워크로드의 안전한 이동을 권장합니다. Prefix 전환 시 노드 교체

변경 후 새 Pod가 IP를 받고 Ready가 되는지 확인합니다. 이어서 필요한 DNS·서비스·외부 연결을 점검하세요. IP 확보와 애플리케이션 통신은 별도의 완료 조건입니다.

재발 방지와 다른 네트워크 구성의 검토 시점

서브넷별 가용 주소, 노드별 Pod 증가량, CNI 주소 할당 오류를 같은 시간축으로 보세요. 총 여유 IP 알람만으로 단편화를 탐지할 수 없으므로 Prefix 할당 오류도 함께 관찰하는 것을 권합니다.

여유 기준에는 배포 시 추가 복제본, 노드 교체와 자동 확장의 동시 용량을 포함하세요. 피크 수치를 확인하지 않고 절감률이나 권장 여유량을 고정하지 않는 것이 좋습니다.

IPv4 주소 계획 자체가 제약이라면 custom networking과 IPv6를 비교할 수 있습니다. CNI 교체 전에 기존 구성의 주소 설계 대안을 검토하세요. 주소 부족 시 custom networking 검토

Calico 정책만 추가하면 Pod 주소 할당 방식은 바뀌지 않습니다. 최근 Calico 도입 판단 글이 도구 선택을 다룬다면, 이번 글은 VPC CNI를 유지한 상태에서 장애 원인을 좁히는 데 집중합니다.

FAQ

EKS에서 Calico가 꼭 필요할까? 먼저 보는 선택 기준

일반적인 EKS EC2 환경에서 Calico는 필수 구성 요소가 아닙니다. 필요한 통신 제어를 VPC CNI 정책으로 구현할 수 있다면 이를 우선 검토하고, 기존 Calico 정책 활용이나 별도 Pod 주소 공간이 필요한 경우에 도입 범위를 넓히는 것이 이 글의 권장 순서입니다.

이 글은 EKS 도입·운영 담당자가 네트워크 도구를 선택하는 데 필요한 판단 기준을 다룹니다. 설치 완료를 보여주는 실습이 아니라 구성 선택과 검증 계획을 위한 초안이며, 공식 문서 확인일은 2026년 9월 9일입니다. Calico의 기본 개념을 반복하기보다 EKS에서 달라지는 지원 조건과 운영 부담에 집중합니다.

VPC CNI와 Calico의 역할: 정책 추가와 네트워킹 교체

CNI는 Pod가 네트워크에 연결되는 구성을 담당하고, IPAM은 사용할 IP 주소를 관리합니다. 정책 엔진은 그 통신을 허용하거나 차단합니다. Calico를 설치했다는 사실만으로 이 세 역할이 모두 Calico로 바뀌었다고 판단할 수 없습니다.

VPC CNI와 Calico 정책을 함께 쓰면 Pod 주소 할당과 VPC 연결은 AWS 구성을 유지합니다. Calico 네트워킹을 선택하면 별도 IPAM과 오버레이를 사용하는 구성이 가능합니다. 아래 비교도는 역할 구분을 위한 개념도이며 패킷이 처리되는 정확한 순서를 나타내지는 않습니다. Calico EKS 구성 안내

기본 정책 개념은 Calico NetworkPolicy와 네트워크 보안 구조에서 확인하세요. 이번 글에서는 해당 개념을 EKS 구성 선택에 적용합니다.

VPC CNI의 NetworkPolicy로 충분한 경우

가상의 예약 서비스에서 프런트엔드는 예약 API에만 접근하고, 다른 업무의 Pod는 API에 접근하지 못하게 하려는 요구를 생각해 보세요. 필요한 제어가 Pod·네임스페이스 선택과 IP·포트 범위에 해당한다면 표준 NetworkPolicy를 먼저 검토할 수 있습니다.

현재 AWS 문서에는 표준 NetworkPolicy뿐 아니라 클러스터 범위의 ClusterNetworkPolicy도 안내되어 있습니다. 따라서 중앙 정책이나 클러스터 전체 차단이 필요하다는 이유만으로 Calico가 유일한 선택이라고 볼 수 없습니다. AWS의 ClusterNetworkPolicy는 networking.k8s.aws API를 사용하므로 표준 NetworkPolicy와 이식성도 구분하세요.

확인한 AWS 문서는 표준·관리자 정책을 함께 사용하는 조건으로 VPC CNI 1.21.0 이상을 제시합니다. 이는 표준 NetworkPolicy가 해당 버전에서 처음 등장했다는 뜻이 아닙니다. EC2 Linux 노드 등 적용 조건과 설치 버전의 기능을 함께 확인하세요. VPC CNI 정책 종류와 지원 조건

정책 객체를 생성하는 것과 정책 엔진을 활성화하는 것은 다릅니다. 또한 시작 시 기본 허용하는 standard 모드와 기본 차단하는 strict 모드의 차이를 검토해야 합니다. strict 모드는 DNS 등 필수 통신을 허용하는 준비가 필요합니다. VPC CNI 정책 활성화와 시작 모드

VPC CNI를 유지하면서 Calico 정책을 추가하는 경우

이미 온프레미스에서 Calico 정책을 관리하고 있고 EKS에서도 같은 정책 API와 검토 절차를 유지하려는 팀이라면 정책만 추가하는 방식을 검토할 수 있습니다. 이것은 도입 판단 예시이며 서로 다른 환경에서 정책 파일이 수정 없이 동작한다는 보장은 아닙니다.

Calico의 GlobalNetworkPolicy는 네임스페이스에 한정되지 않는 정책 리소스이며 order, selector, Allow·Deny 등의 필드로 동작을 정의합니다. 필요한 필드를 현재 VPC CNI 기능과 항목별로 비교하세요. 이름이 비슷한 정책도 평가 순서와 적용 대상이 같다고 가정하지 않는 것이 좋습니다. Calico GlobalNetworkPolicy 정의

도입 검토표에는 필요한 기능 이름, 오픈소스 또는 상용 제품 여부, 지원 버전, 담당자를 함께 기록하는 것을 권합니다. 특정 보안·관측 기능이 Calico 전체 제품에서 동일하게 제공된다고 가정하면 비용과 구현 범위를 잘못 산정할 수 있습니다.

Pod IP 부족 때문에 Calico로 교체해야 할까?

IP 부족은 서브넷에 주소가 없는 상황과 노드가 더 이상 Pod IP를 확보하지 못하는 상황을 나누어 보아야 합니다. 가령 서브넷에는 공간이 있지만 노드별 밀도에 막힌 상황과, 서브넷 주소 자체가 소진된 상황은 같은 해결책으로 다루기 어렵습니다.

Prefix Delegation은 ENI에 주소 묶음을 할당해 노드당 Pod 밀도를 높이는 방식입니다. IPv4에서는 연속된 /28 공간이 필요하므로 빈 주소 총량이 있어도 단편화로 실패할 수 있습니다. 서브넷의 전체 주소 공간을 늘리는 기능은 아닙니다. Prefix Delegation과 주소 단편화

custom networking은 Pod에 사용할 별도 서브넷과 주소 공간을 구성하는 VPC CNI의 선택지입니다. IPv4 부족이라면 이 방식과 IPv6 설계를 먼저 비교할 수 있습니다. AWS는 아직 IPv6를 사용할 수 없는 IPv4 부족 상황에서 custom networking을 검토하도록 안내합니다. custom networking 선택 기준

Calico 정책만 추가하면 IP 할당 방식은 그대로입니다. 별도 Pod 주소 대역을 통한 VPC 주소 소모 완화는 Calico 네트워킹을 선택할 때 검토할 수 있는 효과입니다. Calico 네트워킹 선택 기준

Calico 네트워킹으로 교체하면 달라지는 통신 구조

Calico 오버레이를 선택하면 Pod 주소가 VPC에서 직접 라우팅되는 기존 구조와 달라집니다. 외부 서비스가 Pod IP를 직접 목적지로 쓰는지 먼저 조사하세요. 클러스터 밖에서 도달하지 못하는 주소를 로드밸런서 대상으로 등록하면 정상 연결을 기대하기 어렵습니다. AWS에서 Calico 오버레이를 선택할 때의 외부 접근 제한

Tigera의 EKS 안내는 제어 평면이 Calico Pod로 연결을 시작할 수 없는 제약을 설명합니다. Admission webhook처럼 제어 평면에서 접근해야 하는 구성은 별도 설계가 필요합니다. 문서의 hostNetwork 우회 방안도 신뢰 가능한 구성 요소에 대한 선택지이므로 일괄 적용하지 말고 노드 포트와 정책 경계를 검토하세요. Calico EKS 제어 평면 연결 주의사항

실무 검증에서는 로드밸런서 대상 유형과 헬스 체크, 외부 API로 나가는 NAT 경로, 반환 트래픽, DNS, MTU를 하나의 통신 목록으로 묶는 것을 권합니다. 짧은 요청뿐 아니라 큰 응답과 장시간 연결도 시험 항목에 포함하면 경로 변경의 영향을 확인하기 쉽습니다.

EKS 실행 환경과 AWS 지원 범위 확인하기

설치 가능한 구성과 AWS가 지원하는 구성은 구분해야 합니다. 아래는 확인일 기준 AWS 안내를 요약한 표입니다. 일반 EC2 노드에서 대체 CNI를 선택한다면 공급업체 지원 또는 내부 장애 대응 역량을 확보하는 것이 필요합니다. EKS 대체 CNI 지원 범위

정책 충돌과 적용 예외: 설치 전에 확인할 사항

Calico를 정책 엔진으로 선택할 때 VPC CNI의 정책 기능을 동시에 켜지 않도록 구성해야 합니다. Tigera는 두 정책 엔진의 충돌을 명시합니다. 같은 트래픽을 두 엔진이 관리하면 허용·차단 원인을 구분하기도 어려워집니다.

VPC CNI와 Calico 정책을 조합하는 설치 안내에는 ANNOTATE_POD_IP=true와 aws-node의 Pod patch 권한 요구가 있습니다. IPv6 Pod에서 ENABLE_V4_EGRESS=true인 경우의 Calico 정책 적용 제한도 확인해야 합니다. Calico 정책 구성의 권한·IPv6 조건

또한 AWS는 Pod에 보안 그룹이 연결된 경우 해당 트래픽이 Calico 정책 집행 대상에 포함되지 않는다고 안내합니다. Security Groups for Pods와 Calico를 조합할 때 모든 트래픽에 두 통제가 중첩된다고 가정하면 안 됩니다. Calico와 Pod 보안 그룹 주의사항

가상의 예약 서비스 검증에서는 허용된 프런트엔드 접근, 다른 업무 Pod의 차단, DNS 조회, 외부 결제 연동용 더미 API 접근을 각각 구분하는 것을 권합니다. 기대 결과를 먼저 적고 허용과 차단을 모두 확인해야 정책의 목적을 판단할 수 있습니다.

운영 전환 전에 검증할 통신과 복구 기준

아래 표는 신규 검증 환경에서 사용할 제안입니다. 실제 운영 전환 절차는 현재 설치 방식과 버전에 맞춰 별도로 작성해야 합니다. 특히 CNI 교체를 기존 aws-node 삭제 한 단계로 취급하지 마세요. 새 환경에서 경로를 확인한 뒤 워크로드를 옮기는 방안을 우선 비교하는 것이 좋습니다.

검증 결과에는 연결 성공 여부 외에도 지연, 오류율, 노드 자원 사용량과 정책 로그를 남기세요. 전환 전후의 요청 크기와 부하 조건을 맞춰야 성능 비교가 의미를 갖습니다. Calico 도입만으로 속도 향상이나 비용 절감을 단정할 수 없습니다.

최종 도입 판단표: 필요한 범위만 선택하기

도입 결정은 도구 이름보다 현재 해결하지 못하는 요구사항을 중심으로 내리는 것이 좋습니다. 아래 표는 앞서 확인한 기능과 지원 조건을 바탕으로 정리한 설계 제안입니다. 정책 요구와 주소 설계 요구가 함께 있으면 두 항목을 따로 평가하세요.

FAQ