컴맹 : 진화의 시작

테라폼으로 인프라를 운영하다 보면 선언적(Declarative) 리소스 정의만으로는 해결되지 않는 순간들이 꼭 찾아옵니다. 특정 변수나 스크립트 파일 해시가 바뀌었을 때 다른 리소스를 강제로 재생성(Replace)하고 싶다거나, S3 버킷에 정적 웹 에셋을 업로드한 직후 CloudFront 캐시 무효화(Invalidation)를 실행하고 싶을 때, 혹은 배포 직후 DB 마이그레이션용 Lambda 함수를 한 번 호출해야 하는 상황이 대표적이죠.과거에는 이런 요구사항이 생기면 거의 공식처럼 null_resource와 local-exec 프로비저너(Provisioner) 조합을 꺼내 들곤 했습니다. 하지만 이 방식은 실무 CI/CD 파이프라인에서 꽤 많은 골칫거리를 만듭니다. 아무 일도 하지 않는 껍데기 리소..

평소 ChatGPT나 Codex를 업무에 활용하다 보면 가장 아쉬운 순간이 있습니다. 바로 내가 프롬프트를 입력하고 답변을 받는 그 순간에만 AI가 동작한다는 점인데요. 예를 들어 금요일 배포 일정을 앞두고 슬랙(Slack) 채널에서 오가는 QA 이슈를 계속 추적해야 한다거나, 고객사 피드백이 올라올 때마다 관련 GitHub 이슈와 코드를 대조해 수정 초안(Draft PR)을 준비해 두어야 하는 상황이라면 매번 대화창을 열고 컨텍스트를 다시 설명하는 과정 자체가 꽤 번거로운 일이 됩니다.결국 우리가 진짜로 원하는 건 질문에 단발성으로 답하고 멈추는 챗봇이 아니라, 내가 노트북을 덮거나 다른 회의를 들어간 사이에도 백그라운드에서 맡겨진 업무의 맥락을 유지하며 알아서 진행 상황을 챙겨주는 상시 작동형 에이전..

터미널에서 Claude Code를 띄워두고 인프라 코드나 애플리케이션을 작성하다 보면, 기존에 제공되던 확장 기능만으로는 살짝 아쉬운 순간들이 찾아옵니다. 예를 들어 프롬프트 입력창 바로 위에 현재 세션의 컨텍스트 윈도우 사용량 추이를 실시간 차트로 띄워두고 싶다거나, 실수로라도 rm -rf나 git push --force 같은 위험한 명령어가 실행되기 직전에 실제 영향 범위(삭제될 파일 목록과 용량, 날아갈 커밋 내역 등)를 별도 사이드 패널(Pane)로 먼저 보여주고 승인 버튼을 누르게 만들고 싶은 경우 말이죠.기존에도 settings.json에 정의하는 Hook이나 SKILL.md 기반의 Skill, 그리고 외부 도구를 연결하는 MCP 서버가 있었지만, 이들은 모두 Claude Code 프로세스 외..

실무에서 이미 운영 중인 AWS 계정에 뒤늦게 테라폼(Terraform)을 도입해야 하는 이른바 브라운필드(Brownfield) 환경을 마주할 때가 종종 있습니다. 처음부터 테라폼으로 깔끔하게 프로비저닝된 인프라라면 좋겠지만, 현실에서는 웹 콘솔(ClickOps)이나 일회성 스크립트로 급하게 찍어낸 수십, 수백 개의 리소스가 이미 돌아가고 있는 경우가 대부분이거든요.과거에 테라폼 v1.5에서 선언형 import 블록과 -generate-config-out 플래그가 도입되었을 때만 해도 꽤 큰 진전이 있었습니다. 하지만 막상 대량의 리소스를 코드로 가져오려고 하면 여전히 답답한 병목이 남아 있었는데요. 바로 "클라우드에 어떤 리소스가 어떤 ID로 존재하는지"를 테라폼 스스로 찾아내지 못한다는 점이었습니다...

테라폼(Terraform)으로 인프라를 운영하다 보면 코드 구조만 바꾸고 실제 클라우드 리소스는 그대로 유지해야 하는 상황이 생각보다 자주 발생합니다. 단일 파일로 관리하던 리소스를 모듈(Module) 내부로 옮긴다거나, 콘솔에서 수동으로 만든 리소스를 테라폼으로 가져온다거나, 혹은 더 이상 테라폼으로 관리하지 않고 상태(State) 파일에서만 안전하게 빼내야 하는 경우들이죠.과거에는 이런 작업을 할 때 로컬 터미널에서 terraform state mv, terraform import, terraform state rm 같은 명령형(Imperative) CLI 커맨드를 직접 입력하곤 했습니다. 혼자서 작은 프로젝트를 관리할 때는 큰 문제가 없지만, 팀 단위로 GitOps 및 CI/CD 파이프라인(Atla..

테라폼(Terraform)으로 AWS RDS나 Secrets Manager 같은 리소스를 프로비저닝하다 보면 누구나 한 번쯤 겪게 되는 고질적인 보안 고민이 있습니다. 바로 데이터베이스 마스터 패스워드나 API 토큰 같은 민감 정보(Secret)가 terraform.tfstate 파일에 평문(Plaintext)으로 고스란히 기록된다는 점입니다.물론 변수나 출력값에 sensitive = true 옵션을 주면 터미널의 plan이나 apply 콘솔 출력에서는 (sensitive value)로 마스킹 처리가 되긴 합니다. 하지만 이건 어디까지나 화면 출력만 가려줄 뿐이거든요. 실제 S3 버킷 등에 저장된 tfstate 파일을 열어보면 생성된 패스워드가 평문 JSON 문자열로 그대로 들어 있어서, ISMS-P 인..

리눅스 서버를 운영하다 보면 예고 없이 찾아오는 치명적인 커널 취약점 공지 때문에 등골이 서늘해지는 순간이 있습니다. 최근 공개된 CVE-2026-98432가 바로 그런 사례인데요. 리눅스 커널의 IPv4 TCP 핸드셰이크 처리 과정에서 발생하는 Use-After-Free(UAF) 취약점으로, 별도의 인증 없이 원격에서 네트워크 패킷만으로 커널 패닉(DoS)이나 최악의 경우 root 권한의 원격 코드 실행(RCE)까지 유발할 수 있어 CVSS 9.8(Critical)이라는 높은 점수를 받았습니다.더 까다로운 점은 취약점이 공개된 직후에도 Red Hat(RHEL), Ubuntu는 물론이고 AWS의 Amazon Linux 2023(AL2023) 기본 커널(6.1 계열)과 Amazon Linux 2에 즉시 적..

요즘 보안 이슈 터지는 기업들을 보면서 손가락질하는 사람들이 많은데, 다르게 생각하면 오히려 그들은 기술력 있는 기업이다. 지금 털렸는지도 모르는 곳이 수두룩빽빽일테니까 말이다. 적어도 그들은 여러 장치를 통해 이상징후를 찾아낸 게 아닌가. 😕전에 다녔던 회사 중의 하나는 내가 입사한 지 얼마 안 돼서 아주 오래된 (여러 프리랜서의 손을 탄) 코드가 SQL 인젝션을 맞았다. 맞다. 백엔드 개발자 기술 면접 질문 1번으로 등장해서 아이스 브레이킹 용도로 사용한다는 그 SQL 인젝션 말이다. 아 왜 내가 입사하자마자 이런 일이 벌어지는지. 🫠아 근데 멍청한 해커 놈이 sleep 쿼리를 때려준 덕분에 발견됐다. 라라벨도 없는 순수 체급의 PHP였는데…. 아무튼, 그렇게 멍청한 쿼리를 날려주지 않았더라면(…..

스타트업이나 IT 기업에서 클라우드 인프라를 운영하다 보면, 서비스가 성장하면서 어느 날 갑자기 피할 수 없는 거대한 산을 마주하게 되는 경우가 있습니다. 바로 ISMS(정보보호 관리체계) 및 ISMS-P(정보보호 및 개인정보보호 관리체계) 인증과 정보보호 공시 의무입니다.보통 전년도 매출액이 크게 늘었거나, 서비스 트래픽(일평균 이용자 수)이 급증했거나, 혹은 코스닥 상장(IPO)과 신규 비즈니스 인허가를 준비하는 시점에 보안팀이나 인프라팀으로 이 과제가 떨어지곤 하는데요. 막상 자료를 찾아보면 2016년이나 2018년 시절의 오래된 PDF 문서(예컨대 ISMS-P가 102개 항목이던 시절이나 간편인증 도입 이전 기준)가 검색 상단에 걸려 있어서 혼선을 겪는 경우가 꽤 많거든요.게다가 2024년 하반기..

악마의 변호인(devil's advocate)을 좋아한다. 악마의 변호인은 의도적으로 반대 의견을 제시해서 집단적 사고의 폐단을 막는 역할을 한다. 한마디로 모두가 YES라고 말할 때 NO라고 하는 사람이다. 무거운 공기가 감도는 회의실에서 모두가 고개를 끄덕일 때 첫 번째로 반대 의견을 꺼내는 건 결코 쉬운 일이 아니다. “나만 이해 못 한 건 아니겠지?”“나를 이상하게 생각하지 않겠지?”“내 부족함이 드러나는 건 아니겠지?” 등등. 이런 불안감 속에서도 누군가 용기 내어 반대 의견을 던지면 그때부터 회의실의 분위기가 바뀌고 활발한 의견 교류가 시작된다. 이렇게 공기를 바꿔주는 사람이 좋다. 갇혀있는 생각을 깨부수고 확산적 사고를 자극하는 것. 내가 이런 부류의 사람들을 좋아하는 이유다.그런데 요즘 사..

최근 생성형 AI로 이미지나 짧은 영상을 만들어 보신 분들이라면 한 번쯤 공통적으로 겪어보셨을 답답함이 있을 겁니다. 프롬프트 한 줄로 4~8초짜리 멋진 클립 하나를 뽑아내는 건 이제 어렵지 않은데, 정작 이걸 이어 붙여서 하나의 완결된 스토리를 만들려고 하면 앞선 샷의 캐릭터 얼굴이 미묘하게 달라진다거나, 조명이 갑자기 튄다거나, 배경음악과 대사를 맞추기 위해 외부 편집 도구를 여러 개 오가야 하는 문제가 생기거든요.단발성 에셋 생성을 넘어 실제 프로덕션 레벨의 워크플로우를 하나의 환경에서 처리할 수 있도록 Google에서 선보인 AI 크리에이티브 스튜디오가 바로 Google Flow(flow.google.com)입니다. 단순히 영상만 뽑아내는 도구가 아니라 Veo 3.1, Gemini Omni, Na..

화상 회의(Google Meet, Zoom 등)나 대면 미팅을 진행할 때 AI 기반 회의록 요약 도구를 써보고 싶어도, 사내 보안 규정이나 대외비 아키텍처 문서·계약서 유출 우려 때문에 클라우드 SaaS 도구를 도입하지 못하는 경우가 많습니다. 회의 오디오와 스크립트 전체가 외부 클라우드 서버로 전송되는 구조 자체가 기업 환경에서는 꽤 큰 부담이기 때문이죠.그렇다고 회의 중에 직접 상세한 회의록을 타이핑하거나 질문이 나올 때마다 과거 프로젝트 폴더와 문서를 일일이 뒤적거리다 보면, 정작 중요한 논의 흐름을 놓치기 일쑤거든요. "이건 확인해보고 다시 공유드릴게요(circle back)"라며 후속 회의를 또 잡아야 하는 비효율도 자주 발생합니다.이런 문제를 해결하기 위해 Google AI Edge 팀이 Ap..

EKS 환경을 구축하고 외부 트래픽을 클러스터 내부로 라우팅할 때 가장 표준적으로 사용하는 컴포넌트가 바로 AWS Load Balancer Controller입니다. 과거에는 ALB Ingress Controller라는 이름으로 불렸던 이 컨트롤러는 쿠버네티스의 Ingress 매니페스트를 선언하기만 하면 AWS Application Load Balancer(ALB)를 자동으로 생성하고 연결해 주어서 무척 편리하죠.하지만 기본 설정 그대로 프로덕션 환경에 도입했다가는 크게 두 가지 고전적인 문제에 직면하게 됩니다. 첫 번째는 쿠버네티스에 생성하는 Ingress 리소스마다 AWS ALB가 1:1로 각각 생성되면서 발생하는 비용 낭비와 쿼터(Quota) 고갈 문제입니다. 게다가 작업자가 실수로 Ingress를..

EKS 환경에서 Prometheus, Kafka, Elasticsearch나 각종 데이터베이스 같은 Stateful 워크로드를 운영하다 보면 영구 스토리지(Persistent Volume) 설계가 비용과 안정성에 직결되는 순간을 자주 마주하게 됩니다. 클러스터를 처음 구축할 때 별다른 고민 없이 기본 생성되어 있는 gp2 StorageClass(레거시 in-tree 프로비저너인 kubernetes.io/aws-ebs 기반)를 그대로 사용하는 경우가 꽤 많거든요.하지만 Kubernetes 1.23부터 CSIMigration이 기본 활성화되고 인트리(in-tree) 드라이버가 공식적으로 제거 수순을 밟으면서, 이제는 AWS EBS CSI Driver(ebs.csi.aws.com)를 필수로 구성해야 합니다. ..

이전에 블로그에서 Karpenter의 v1 API 전환부터 Disruption Budget을 활용한 노드 교체 제어, 그리고 NodeOverlay를 통한 스케줄링 시뮬레이션까지 Self-managed Karpenter를 실무에 도입하고 운영하는 방법을 다뤄봤었는데요. Karpenter가 기존 Cluster Autoscaler(CA)의 한계를 극복하고 노드 프로비저닝 속도와 비용 최적화를 비약적으로 끌어올려 준 것은 분명하지만, 클러스터를 운영하는 엔지니어 입장에서는 여전히 신경 써야 할 숙제들이 남아 있습니다.대표적으로 EKS 컨트롤 플레인 버전을 올릴 때마다 VPC CNI, CoreDNS, kube-proxy, EBS CSI Driver, AWS Load Balancer Controller, 그리고 K..

프로덕션 환경에서 Amazon EKS 클러스터를 운영하다 보면 가장 흔하게, 그리고 꽤 당황스럽게 마주치는 장애 중 하나가 바로 서브넷 IP 고갈(IP Exhaustion)과 노드당 최대 파드 수(maxPods) 제한 문제입니다. 분명 워커 노드의 CPU와 메모리 사용률은 20~30% 남짓으로 여유가 넘치는데도 신규 파드가 Pending이나 ContainerCreating 상태에서 멈춰버리고, 클러스터 오토스케일러(또는 Karpenter)가 불필요하게 노드를 계속 증설하거나 더 이상 서브넷에 남은 IP가 없어 스케일 아웃마저 실패하는 상황이 벌어지거든요.이 문제는 EKS의 기본 네트워크 플러그인인 Amazon VPC CNI(aws-node)가 파드에 VPC의 실제 Secondary Private IPv4..

이전 포스팅([AWS] EKS IRSA 동작 원리와 Terraform 구성)에서는 워커 노드의 IAM Role을 파드들이 무분별하게 공유하는 보안 문제를 해결하기 위해 IRSA(IAM Roles for Service Accounts)와 IMDSv2 Hop Limit 설정을 다루어 보았는데요. 단일 클러스터나 소규모 환경에서는 IRSA만으로도 충분히 훌륭한 최소 권한 통제가 가능합니다.하지만 실무에서 EKS 클러스터 개수가 수십 개로 늘어나거나 블루/그린 방식으로 클러스터를 주기적으로 교체하는 멀티 클러스터 아키텍처를 운영하다 보면 IRSA의 구조적인 한계에 부딪히는 경우가 있습니다. 클러스터를 만들 때마다 고유한 IAM OIDC Identity Provider를 생성하고 관리해야 할 뿐만 아니라, IAM..

운영 중인 EKS 클러스터의 버전을 주기적으로 업그레이드하다 보면, 마이너 버전 하나를 올리는 과정인데도 은근히 신경 써야 할 기본값(Default) 변경이나 Breaking Change들이 숨어 있는 경우가 있습니다. 얼마 전 Amazon EKS에서도 쿠버네티스 1.37 버전(코드네임 Garhwal)이 정식 출시되어 표준 지원(Standard Support) 대상에 포함되었는데요.이번 EKS 1.37 릴리즈 노트를 자세히 살펴보면, 기존 워크로드의 마운트 동작에 직접적인 영향을 줄 수 있는 SELinux 마운트 라벨링 기본 활성화(GA)부터 EKS Auto Mode의 Consolidation 기본 정책 변경, 그리고 Kubelet 설정 및 레거시 메트릭 제거까지 사전에 반드시 짚고 넘어가야 할 내용들이..

쿠버네티스(Kubernetes) 클러스터를 처음 구축하고 나면 가장 먼저 마주하게 되는 네트워크상의 특징이 하나 있습니다. 바로 클러스터 내의 모든 Pod가 별도의 제약 없이 서로 자유롭게 통신할 수 있다는 점인데요. 쿠버네티스의 기본 네트워크 모델 자체가 NAT 없이 모든 Pod 간 통신이 가능하도록 설계되어 있기 때문입니다.개발 환경이나 단일 서비스만 올라가는 작은 클러스터에서는 이런 구조가 굉장히 편리합니다. 하지만 하나의 EKS 클러스터에 여러 팀의 워크로드가 함께 올라가는 멀티 테넌트(Multi-tenant) 환경이거나, 결제/정산처럼 민감한 데이터를 다루는 마이크로서비스가 함께 동작하는 운영 환경에서는 이야기가 달라지죠.만약 외부와 연결된 프론트엔드 Pod 하나가 취약점으로 인해 침해당했을 때..

오랫동안 Amazon EKS 클러스터를 운영해 오셨다면, 새로운 작업자나 CI/CD 파이프라인용 IAM Role에 클러스터 접근 권한을 부여할 때 kube-system 네임스페이스의 aws-auth ConfigMap을 수정하던 방식이 익숙하실 텐데요. kubectl edit configmap aws-auth -n kube-system 명령으로 YAML 문자열 형태의 mapRoles나 mapUsers를 직접 편집하다가 들여쓰기(indentation) 실수 한 번에 클러스터 전체 접근 권한이 꼬여버리는 아찔한 경험을 해 보신 분들도 계실 겁니다.게다가 기존 aws-auth 방식에는 구조적인 아쉬움이 꽤 많았습니다. 클러스터를 최초 생성한 IAM 주체(Creator)는 aws-auth에 보이지도 않는 숨겨진 ..