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

Codex·Claude Code·Google Antigravity, 어떤 도구를 선택할까

AI 코딩 도구를 처음 선택한다면 이미 보유한 구독과 익숙한 개발 환경부터 확인하세요. 그다음 실제로 반복하는 오류 수정이나 기능 추가 작업을 맡겨 보고, 결과를 검토하는 시간과 추가 비용을 비교하는 것이 좋습니다. 이용률이 높다는 이유만으로 자신의 프로젝트에도 가장 적합하다고 판단할 수는 없습니다.

이 글은 유료 도입을 고민하는 개인 개발자와 소규모 팀을 위한 선택 가이드입니다. 공식 문서 확인일은 2026년 9월 8일이며, 요금은 미국 달러 표시 기준입니다. 한국 계정의 원화 결제 금액·세금·할인 적용 여부는 확인하지 않았습니다. 기능 설명과 별도로 제시한 평가 방법은 작성자의 제안이며, 세 도구를 직접 실행해 성능을 측정한 후기는 아닙니다.

AI 코딩 도구 점유율 비교: 이용률 통계는 어떻게 읽어야 할까

JetBrains의 Developer Ecosystem Survey 2026에 따르면 업무용 이용률은 Claude Code 39%, Codex 16%, Google Antigravity 6%입니다. 조사 기간은 2026년 5~7월이며 전체 조사에는 전 세계 전문 개발자 15,000명 이상이 참여했습니다. JetBrains 업무용 이용률 조사

이 수치는 전체 시장의 매출이나 유료 구독자 비중이 아닙니다. 여러 도구를 함께 사용하는 상황을 배제한 점유율로 해석하거나, 세 수치를 합쳐 100%로 다시 계산하면 안 됩니다. 비교 대상 세 도구의 순서이며 시장 전체의 상위 3개 순위도 아닙니다.

조사에는 지역·고용 상태·프로그래밍 언어·JetBrains 제품 친숙도에 대한 통계 보정이 적용됐습니다. 다만 해당 문항의 정확한 유효 응답자 수와 복수 응답 설정은 이번 확인 범위에서 확인하지 못했습니다. Google 수치는 Gemini CLI가 아닌 Antigravity이며, 9월의 실시간 이용률을 뜻하지 않습니다.

Codex의 장점과 선택 전 확인할 점

Codex는 CLI와 IDE 확장, 웹 기반 작업 등 여러 환경에서 사용할 수 있습니다. 구독 방식에서는 클라우드 코드 리뷰 같은 연동도 제공되며, API 키 방식은 사용 가능한 기능 범위가 다릅니다. Codex 환경별 기능과 요금

선택 관점에서 볼 장점은 이미 쓰고 있는 ChatGPT 구독의 포함 기능을 개발 작업에도 활용할 수 있다는 점입니다. 추가 결제 전에 현재 계정으로 작은 수정 작업을 진행할 수 있는지 확인하면 도입 판단이 쉬워집니다.

예를 들어 코드 변경 요청에는 수정할 범위, 유지할 동작, 실행할 테스트를 함께 적어 보세요. 결과를 받을 때는 변경 파일과 실패한 검사, 직접 확인하지 못한 부분을 분리해 달라고 요청하는 편이 검토에 도움이 됩니다. 이는 이 글에서 제안하는 활용 방식이며 정확성이나 시간 절감을 실측한 결과는 아닙니다.

팀에서는 도구의 명령 실행 범위, 저장소 접근 권한과 검토 절차가 기존 개발 규칙에 맞는지 평가하세요. 요청이 완료됐다는 설명만으로 병합을 결정하지 말고 실제 변경 내용과 테스트 결과를 확인해야 합니다.

Claude Code의 장점과 선택 전 확인할 점

Claude Code는 코드베이스 읽기, 파일 수정, 명령 실행을 개발 도구와 연결하는 코딩 에이전트입니다. 터미널 외에도 IDE, 데스크톱 앱과 웹에서 사용할 수 있어 CLI 전용 도구로만 설명하면 범위가 좁아집니다. Claude Code 공식 기능 소개

터미널을 자주 사용하는 개발자라면 기존 명령 실행과 코드 탐색 흐름에 자연어 요청을 추가하는 방식부터 평가할 수 있습니다. 익숙한 편집기에서 변경 내용을 확인하고 필요한 부분만 직접 조정할 수 있는지가 중요한 선택 기준입니다.

비용 측면에서는 로그인 방식이 중요합니다. ANTHROPIC_API_KEY가 설정된 환경은 구독 대신 API 인증과 과금이 적용될 수 있습니다. 구독을 결제했다는 사실과 지금 실행 중인 세션이 구독 한도를 사용한다는 사실을 구분하세요. Claude Code 구독 연결과 API 과금 구분

이 글의 평가 예제에서는 오류 원인을 설명하는 능력뿐 아니라 수정 범위를 지키는지, 테스트 실패를 숨기지 않는지, 재요청 없이 검토할 수 있는 결과를 주는지를 함께 기록하도록 제안합니다.

Google Antigravity의 장점과 선택 전 확인할 점

Google Antigravity는 독립형 앱을 중심으로 에이전트 작업을 관리하며 IDE 확장도 제공합니다. Google의 2026년 8월 안내에는 VS Code, Visual Studio, JetBrains, Zed, Xcode 연동이 소개되어 있습니다. 일부 환경은 미리보기이므로 지원 버전과 조직 계정 사용 조건을 함께 확인해야 합니다. Antigravity 앱과 IDE 확장 안내

개발자가 평가할 지점은 작업을 맡기는 화면과 변경 내용을 직접 살펴보는 편집기가 얼마나 편리하게 연결되는가입니다. 독립형 앱으로 전체 작업을 관리하고 익숙한 IDE에서 세부 코드를 검토하는 방식을 선호한다면 후보에 넣을 수 있습니다.

이 글에서 비교하는 제품은 Google Antigravity입니다. Google은 별도로 Antigravity CLI도 소개하고 있으며 Gemini CLI 사용자에게 이전을 안내합니다. 예전 Gemini CLI의 요청 한도나 가격을 Antigravity 통계·요금에 그대로 적용하면 안 됩니다. Google 개발 도구 구분과 이전 안내

계정에서 선택할 수 있는 모델은 별도로 확인하세요. 이번 확인에서는 Antigravity 가격 소개와 상세 플랜 문서의 외부 모델 제공 설명이 일치하지 않아, 특정 외부 모델을 무료로 쓸 수 있다고 단정하지 않았습니다.

같은 개발 작업으로 비교하는 실전 선택 기준

비교 예제로 가상의 동아리 장비 대여 앱을 생각해 보겠습니다. 반납 날짜가 대여 날짜보다 빠른데도 신청이 저장되는 문제가 있다고 가정합니다. 세 도구에 같은 시작 코드와 요구사항을 제공하고 날짜 검증과 테스트를 추가하게 합니다. 실제 서비스나 고객 정보를 사용하지 않는 새 더미 상황이며 이 예제를 실행해 얻은 측정값은 없습니다.

공통 요청은 다음처럼 작성할 수 있습니다. ‘날짜 검증 오류를 재현하고 필요한 부분만 수정해 주세요. 기존 정상 신청은 유지하고, 반납일이 빠른 경우와 날짜가 비어 있는 경우를 확인해 주세요. 실행한 테스트와 실행하지 못한 검사를 구분해 설명해 주세요.’ 프로젝트별 테스트 명령과 동작 조건은 자신의 환경에 맞춰 바꿔야 합니다.

각 도구는 같은 코드 상태에서 새 작업을 시작하고 같은 시간·비용 예산을 적용하세요. 선택 모델, 버전, 실행 권한도 기록합니다. 제공 모델이 서로 다르면 같은 모델의 성능 실험이 아니라 각 제품 구성을 비교한 결과로 표시해야 합니다.

최초 답변 속도보다 검토 가능한 수정이 나오기까지의 전체 시간을 보세요. 빠르게 답해도 누락과 재수정이 많으면 실제 작업 비용은 커질 수 있습니다.

무료·유료 요금제 비교: 결제하면 무엇이 달라질까

아래는 개인용 중심의 미국 달러 비교표입니다. 월간 결제와 연간 선결제를 구분했으며, 무료 체험 가격은 일반 요금에 섞지 않았습니다. 한국 결제 화면의 통화·세금·할인이 반영된 청구액은 별도 확인해야 합니다.

Codex 가격은 OpenAI 공식 가격 안내, Claude 가격은 Claude 개인 요금제 안내를 기준으로 정리했습니다. Claude Code는 유료 플랜에 포함되며 무료 Claude 채팅과 같은 조건으로 이해하면 안 됩니다. Claude Code 포함 범위

Antigravity 무료 플랜은 공식 가격 안내, Google AI Pro의 미국 월 요금은 2026년 8월 Google 공식 안내의 갱신 가격, Ultra는 2026년 5월 Google 공식 요금 개편에서 확인했습니다. Google One 가격 페이지에서 금액이 추출되지 않아 날짜가 명시된 공식 안내로 보완했습니다.

같은 5배·20배라는 이름도 회사마다 기준이 다릅니다. 가격이 같거나 배수가 같다고 실제 작업 횟수까지 같아지는 것은 아닙니다. 자주 쓰는 작업이 어느 한도에서 막히는지를 기록한 뒤 상위 구독의 필요성을 판단하세요.

구독료와 API 비용은 어떻게 다를까

구독은 정해진 기간에 포함된 기능과 사용 범위를 구매하는 방식입니다. API 사용량 과금은 실제 요청에서 소비한 사용량에 따라 비용이 달라지는 방식입니다. 유료 구독을 보유했다고 개발 환경의 모든 API 호출이 포함되는 것은 아닙니다.

Codex의 API 키 사용은 API 요금을 따릅니다. Plus·Pro의 포함 한도를 넘긴 뒤 추가 크레딧을 구매하는 경로도 있습니다. Codex 추가 사용과 API 결제

Claude의 구독 사용과 Console의 API 비용은 분리됩니다. API 크레딧 자동 충전을 켜 둔 경우 잔액이 낮아질 때 추가 구매가 발생할 수 있습니다. Claude 구독·Console 결제 구분

Antigravity는 Pro·Ultra에서 기본 한도를 넘긴 사용에 AI 크레딧을 사용할 수 있습니다. AI Credit Overages의 Never는 자동 크레딧 사용을 막고, Always는 기본 한도 소진 후 크레딧을 사용하도록 하는 설정입니다. Antigravity 초과 사용 설정

예산은 ‘구독 고정비 + 추가 사용료 + 별도 API 비용 + 필요한 실행 환경 비용’으로 나누어 기록하면 됩니다. 같은 사용분을 추가 크레딧 비용과 API 비용에 중복 계산하지 않도록 청구 경로별로 정리하세요. 사람의 검토 시간은 현금 청구액과 별도 지표로 기록하는 것이 비교하기 쉽습니다.

결제 전 확인할 사용 한도·추가 과금·해지 조건

결제 직전에는 결제 주기, 첫 청구 금액, 다음 갱신일, 추가 크레딧 사용 여부를 확인하세요. 월 환산 가격으로 표시된 연간 구독은 매달 그 금액만 결제하는 방식과 다릅니다. 체험 할인도 종료 후 요금과 함께 비교해야 합니다.

Claude는 해지 후 현재 결제 기간까지 이용할 수 있으며 다음 결제를 피하려면 갱신 최소 24시간 전에 취소하도록 안내합니다. 일반적으로 환불은 제한되지만 예외가 있고, 앱스토어 결제는 처리 경로가 달라집니다. Claude 해지·환불 안내

Google One은 구독 취소와 환불을 별도로 안내하며 국가·구매 경로에 따라 조건이 달라집니다. AI 크레딧 자동 충전도 별도 설정이므로 확인해야 합니다. Antigravity의 ‘보유 크레딧 사용’과 Google One의 ‘새 크레딧 자동 구매’는 다른 동작입니다. Google One 구독 취소와 환불 · AI 크레딧 자동 충전 관리

Codex를 이용하는 ChatGPT 구독의 해지·환불 세부 조건은 이번에 확인한 공식 가격 문서만으로 확정하지 못했습니다. 따라서 다른 서비스의 취소 기한을 동일하게 적용하지 않았습니다. 결제한 계정의 구독 관리 화면에서 다음 청구일·취소 적용 시점·환불 안내를 확인해야 합니다.

요청 횟수만으로 세 서비스의 한도를 비교하기도 어렵습니다. 모델과 작업 복잡도에 따라 소비가 달라지므로 남은 한도, 갱신 시각과 실제 작업 결과를 함께 기록하세요.

입문자·개인 개발자·팀별 추천 선택 기준

입문자는 현재 이용 가능한 무료 범위나 이미 결제한 구독에서 작은 작업부터 시작하는 편이 좋습니다. 결과를 이해하고 잘못된 수정을 찾아낼 수 있는지 확인한 뒤 사용량을 늘리세요. 처음부터 세 도구를 모두 구독할 필요는 없습니다.

개인 개발자는 반복 업무 하나를 정해 비교하세요. 오류 수정이 대부분이라면 재현과 회귀 테스트를, 화면 개발이 많다면 변경 내용을 확인하고 수정하는 흐름을 중요하게 보면 됩니다. 한도 부족이 실제 작업을 자주 중단시키는지 기록하면 상위 구독과 추가 사용 중 무엇을 검토할지 판단하기 쉽습니다.

팀은 개인용 구독료만으로 총비용을 계산하지 않아야 합니다. 좌석 수, 관리 기능, 저장소 접근 범위, 코드 보관 정책, 퇴사자 접근 회수와 실제 사용료를 확인해야 합니다. 조직용 제공 방식은 각 공급자의 현재 계약 조건에 따라 별도로 비교하세요.

두 도구를 함께 쓰려면 역할이 나뉘는지부터 보세요. 하나는 변경 초안 작성에, 다른 하나는 검토 보조에 쓰는 설계를 검토할 수 있습니다. 다만 두 AI가 같은 결론을 냈다는 사실만으로 정확성을 보장할 수 없으며 테스트와 사람의 검토는 계속 필요합니다.

FAQ

PVC 용량 확장이 안 될 때 먼저 비교할 세 가지

PVC의 요청 용량을 늘렸다면 PVC spec의 요청값, 연결된 PV의 용량, 애플리케이션이 사용하는 파일시스템 용량을 차례로 비교하세요. 요청이 저장된 것과 볼륨·파일시스템 확장이 끝난 것은 서로 다른 상태입니다. kubectl get pvc의 CAPACITY 열만으로 요청 반영 여부를 판단하지 않는 것이 좋습니다.

이 글은 기존 볼륨이 Bound 상태이고, 용량 증설을 요청한 뒤 반영되지 않는 상황을 다룹니다. 새 PVC가 처음부터 Pending인 경우의 일반적인 생성 장애와 구분합니다. 공식 문서 확인일은 2026년 9월 9일입니다. 아래는 직접 만든 가상 보관용 볼륨 예제입니다.

확장 전제 조건: StorageClass와 드라이버부터 확인하기

StorageClass의 allowVolumeExpansion이 true인지 확인하세요. 이 설정만으로 모든 스토리지가 확장되는 것은 아니며 드라이버와 파일시스템도 지원해야 합니다. PVC 확장은 용량 증가를 위한 기능으로, 이미 할당된 볼륨 축소에 사용하지 않습니다. StorageClass 확장 조건

이 글의 YAML은 일반 EKS EC2 워커 노드에서 표준 Amazon EBS CSI Driver를 사용하는 테스트 환경을 전제로 합니다. 드라이버 설치, 필요한 IAM 권한, 노드 배치 조건과 이미지 다운로드 경로가 준비되어야 합니다.

EKS Auto Mode는 provisioner가 ebs.csi.eks.amazonaws.com으로 다르며, 이 예제의 ebs.csi.aws.com과 구분해야 합니다. EBS 볼륨을 Fargate Pod에 마운트하는 예제로도 사용할 수 없습니다. EKS EBS CSI 사용 조건

실제 데이터가 있는 환경은 복구 가능한 백업과 변경 시간을 먼저 정하세요. 이 글의 명령은 자신의 namespace·PVC·Pod 이름으로 바꿔야 하며, 샘플을 기존 운영 PVC에 그대로 적용하지 마세요.

샘플 YAML: 확장 가능한 테스트 볼륨 만들기

가상의 보관 앱에서 3Gi 볼륨을 7Gi로 늘리는 상황입니다. 아래 파일을 pvc-expand-demo.yaml로 저장하세요. 실제 EBS 볼륨을 생성하므로 실행하면 스토리지 비용이 발생할 수 있습니다.

Namespace, StorageClass, PVC와 확인용 Pod를 함께 구성합니다. 이름이 같은 리소스가 이미 있으면 다른 테스트 이름을 사용하세요. 이미지 태그도 자신의 테스트 환경에서 사용 가능한 버전인지 확인해야 합니다.

WaitForFirstConsumer는 소비 Pod의 배치 조건을 고려해 볼륨 생성을 진행하는 설정입니다. PVC만 만들고 기다리는 경우와 구분하세요. Retain은 PVC 삭제 시 볼륨이 자동 삭제되는 위험을 줄이기 위한 예제 선택이며, 남은 볼륨은 별도 정리가 필요합니다.

StorageClass와 PVC의 연결 원리는 기존 CSI·PersistentVolume 구조 글에서 확인할 수 있습니다. 여기서는 생성 이후의 확장 점검에 집중합니다.

초기 상태 확인 후 PVC 요청 용량만 변경하기

먼저 다음 명령으로 예제를 적용하고 Pod가 준비되는지 확인합니다. 대기 시간이 끝났다고 곧바로 확장 장애로 판단하지 마세요. 이미지 다운로드·노드 배치·볼륨 연결 문제가 없는지 describe의 이벤트를 먼저 읽어야 합니다.

초기 PVC가 Bound이고 /archive에 볼륨이 마운트된 다음에 증설을 요청합니다. 초기 용량이 보이는 상태를 기록해 두면 확장 전후 비교가 쉽습니다.

확장용 YAML과 적용 명령: 3Gi에서 7Gi로

아래 내용은 독립적으로 생성하는 Kubernetes 리소스가 아니라 PVC에 적용할 merge patch입니다. pvc-expand-to-7gi.yaml로 저장한 뒤 다음 섹션의 patch 명령에 사용하세요.

필드 하나만 바꿔 실제 PVC의 요청 용량을 증가시키는 방식입니다. Git이나 Helm에서 PVC를 관리한다면 선언 원본에도 같은 요청값을 반영해 상태가 어긋나지 않게 하세요.

PV의 capacity를 먼저 수동 변경하지 마세요. Kubernetes가 이미 용량을 맞춘 것으로 판단해 필요한 자동 확장 처리가 진행되지 않을 수 있습니다. PVC를 통한 확장과 PV 직접 수정 주의사항

요청이 저장됐는지 확인하고 이벤트 읽기

patch 명령이 성공해도 확장이 완료된 것은 아닙니다. 아래 조회에서 REQUEST가 7Gi인지 먼저 보고 CAPACITY와 조건을 비교하세요. API 요청이 거부됐다면 권한, ResourceQuota, 정책 또는 확장 허용 설정부터 확인합니다.

이벤트의 시각과 메시지를 함께 읽으세요. Resizing·FileSystemResizePending 등의 표시 여부와 문구는 버전·드라이버·진행 시점에 따라 다를 수 있습니다. 조건이 비어 있다는 이유만으로 성공이나 실패를 확정하지 마세요.

PV 이름은 PVC의 spec.volumeName에서 확인한 실제 값으로 다음 명령의 <pv-name>을 교체하세요. 실제 PV 이름이나 오류 로그를 외부에 공유할 때는 운영 식별자를 제거해야 합니다.

CSI 단계에서 멈췄다면 컨트롤러와 스토리지 오류 확인하기

요청은 커졌는데 PV 용량이 그대로라면 볼륨 확장 처리 구간을 조사하세요. 단, PV 표시만으로 공급자 측 처리 상태를 확정하지 말고 CSI 로그와 실제 스토리지 상태도 대조합니다.

표준 EBS CSI 설치에서는 컨트롤러의 csi-resizer와 ebs-plugin 로그가 점검 대상입니다. 아래 리소스·컨테이너 이름은 일반적인 설치 예시이므로 실제 Pod 목록과 컨테이너 이름부터 확인하세요. 다른 CSI 드라이버는 해당 배포의 이름으로 바꿔야 합니다.

권한 오류라면 CSI 컨트롤러가 사용하는 자격 증명을 확인하고, 용량 제한이나 볼륨 변경 중이라는 오류라면 해당 스토리지의 제한과 현재 변경 상태를 확인합니다. 애플리케이션 Pod에 더 강한 IAM 권한을 주는 방식으로 해결하려 하지 마세요.

EBS CSI는 PVC의 새 크기에 따른 볼륨 확장을 지원합니다. 구체적인 오류는 설치된 드라이버 버전과 구성에 맞춰 확인하세요. EBS CSI 기능 및 문서

볼륨은 커졌는데 df가 그대로라면 파일시스템 점검하기

Filesystem 볼륨은 저장 장치 확장 이후 파일시스템 반영 단계가 필요할 수 있습니다. 실행 중 확장과 재마운트 필요 여부는 드라이버·파일시스템 조건에 따라 판단해야 하며, 무조건 Pod부터 삭제하는 방식은 피하세요. 파일시스템 확장 조건

먼저 올바른 Pod와 컨테이너에서 PVC가 연결된 경로를 보고 있는지 확인합니다. 루트 경로의 df 결과는 컨테이너의 임시 파일시스템일 수 있습니다. 샘플에서는 /archive를 지정합니다.

PV는 커졌지만 FileSystemResizePending이 지속된다면 Pod가 배치된 노드의 CSI node plugin과 kubelet 관련 오류를 조사하세요. 재마운트가 필요하다는 근거가 확인된 뒤 워크로드 복제본·데이터 일관성·중단 영향을 검토하고 재시작 여부를 결정합니다.

Raw Block 볼륨은 df로 확인하는 파일시스템 예제와 다릅니다. 또한 파일시스템 용량은 단위와 메타데이터 때문에 요청 숫자와 화면 표시가 정확히 일치하지 않을 수 있습니다. 애플리케이션의 별도 저장 한도도 구분해서 확인하세요.

증상별 판단과 완료 확인·정리 기준

완료 판단은 요청값 하나로 끝내지 않습니다. 요청한 크기와 PV·PVC 상태를 확인하고, 실제 마운트 경로의 용량과 애플리케이션의 읽기·쓰기가 정상인지 검증하세요. 아래 표는 진단 방향이며 확정 원인을 뜻하지 않습니다.

테스트가 끝나면 Pod·PVC·Namespace와 테스트 StorageClass의 사용 여부를 확인해 정리하세요. 예제의 Retain 정책에서는 PVC 삭제 후에도 PV와 실제 EBS 볼륨이 남을 수 있으므로 연결 해제·데이터 보존 필요성을 확인한 뒤 각각 정리해야 합니다. 리소스를 자동 삭제하는 정리 명령은 포함하지 않았습니다.

확장 실패를 이유로 운영 PVC를 삭제하거나 finalizer를 제거하지 마세요. 현재 할당된 용량보다 줄이는 변경을 일반적인 복구 방법으로 사용해서도 안 됩니다.

FAQ