컴맹 : 진화의 시작

최근 생성형 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에 보이지도 않는 숨겨진 ..

최근 터미널에서 동작하는 코딩 에이전트인 Claude Code를 실무에서 유용하게 쓰시는 분들이 정말 많아졌습니다. 파일을 스스로 찾아서 읽고(Read, Glob, Grep), 코드를 수정하고(Edit, Write), 직접 테스트 명령어까지 실행해 보면서(Bash) 오류가 나면 스스로 고쳐나가는 모습을 보면 "이 에이전트 엔진을 그대로 우리 사내 CI/CD 파이프라인이나 운영 자동화 봇, 혹은 백엔드 서비스 안에 심을 수는 없을까?" 하는 생각이 자연스럽게 들곤 합니다.물론 기본 anthropic Client SDK를 써서 직접 Messages API를 호출하고 while 루프로 툴 호출(Tool Use)을 구현할 수도 있긴 합니다. 하지만 막상 실제 파일시스템 탐색, 안전한 코드 패치(Diff 적용),..

최근 사내 인프라 운영 자동화나 기술 지원 워크플로우에 LLM 기반 에이전트를 도입하려는 시도가 부쩍 늘어났습니다. 그런데 막상 프로토타입을 넘어 실제 프로덕션 레벨로 에이전트를 올리려고 하면 고민스러운 지점이 한두 가지가 아닌데요. 거대한 서드파티 프레임워크를 쓰자니 추상화 계층이 너무 두꺼워서 내부 프롬프트나 툴 호출 루프를 디버깅하기가 까다롭고, 반대로 순수 API만 호출해서 직접 에이전트 루프를 짜자니 멀티 에이전트 간 위임(Handoff)이나 입출력 검증(Guardrail), 상태 저장, 그리고 실제 파일시스템과 쉘을 다루는 샌드박스(Sandbox) 격리까지 직접 구현해야 할 인프라 코드가 눈덩이처럼 불어나기 때문입니다.이런 페인 포인트를 해결하기 위해 OpenAI에서 기존 실험적 프로젝트였던 ..

아이들과 함께 게임을 이야기하다가, 혹은 가볍게 사이드 프로젝트로 나만의 3D 월드(맵)를 직접 만들어 보고 싶을 때 가장 먼저 떠오르는 플랫폼이 바로 로블록스(Roblox)일 겁니다. 사실 Unity나 Unreal Engine 같은 상용 게임 엔진을 처음부터 배워서 3D 맵을 깎고 멀티플레이어 전용 서버 인프라까지 직접 구축하려면 배보다 배꼽이 더 커지는 경우가 많거든요.반면 로블록스는 무료 전용 제작 도구인 Roblox Studio 하나로 3D 맵 빌딩부터 실시간 물리 엔진, 멀티플레이어 서버 호스팅, 크로스 플랫폼(PC, Mac, 모바일, 콘솔, VR) 즉시 배포, 심지어 인게임 결제와 현금 정산(DevEx)까지 올인원으로 해결해 줍니다. 개발자는 인프라 걱정 없이 오직 월드 디자인과 게임 로직에만..

로컬 환경에서 Strands Agents나 LangGraph, CrewAI 같은 오픈소스 프레임워크로 AI 에이전트 프로토타입을 만드는 일은 이제 꽤 익숙해졌습니다. 파이썬 스크립트 몇 줄이면 LLM에 도구를 연결하고 그럴듯하게 동작하는 데모를 금방 띄울 수 있거든요.그런데 이 에이전트를 사내 프로덕션 환경으로 올리려고 하면 이야기가 완전히 달라집니다. 여러 사용자의 세션이 섞이지 않도록 런타임을 어떻게 격리할지, 외부 SaaS나 내부 API를 호출할 때 OAuth 토큰과 IAM 권한은 어떻게 안전하게 주입할지, 멀티 턴 대화의 단기·장기 메모리는 어디에 저장할지, 그리고 에이전트가 엉뚱한 도구를 호출하지 못하도록 정책(Policy)과 트레이싱(Observability)을 어떻게 붙일지까지 인프라와 보안..

사내 환경에 생성형 AI를 도입하다 보면 처음에는 단순한 프롬프트 기반의 챗봇이나 RAG 파이프라인으로 시작하지만, 점차 여러 사내 시스템과 MCP(Model Context Protocol) 서버, 외부 API를 넘나들며 스스로 작업을 수행하는 에이전트(Agent) 구조로 발전하게 됩니다. 단일 태스크를 보조하는 수준을 넘어 비즈니스 워크플로우 자체를 위임받는 형태로 진화하는 건데요.문제는 사내에 배포되는 에이전트가 하나둘 늘어날수록 인프라 운영과 보안 거버넌스 측면에서 골치 아픈 상황이 발생한다는 점입니다. 각 에이전트가 어떤 권한으로 사내 DB나 외부 툴을 호출하는지 명확히 추적하기 어렵고, 단발성 세션을 넘어 며칠씩 이어지는 장기 워크플로우의 상태(State)나 사용자별 맥락(Memory)을 유지하..

최근 LLM을 활용해 단순한 챗봇을 넘어 여러 도구를 호출하고 스스로 작업을 완수하는 AI 에이전트(Agent)를 프로덕션 환경에 도입하려는 시도가 정말 많아졌습니다. 하지만 막상 실무에서 에이전트 시스템을 바닥부터 설계하다 보면 꽤 까다로운 문제들과 마주하게 되는데요. 예를 들어, 단일 프롬프트에 수십 개의 툴(Tool)과 복잡한 절차를 우겨 넣다 보니 컨텍스트 윈도우가 금방 터져버린다거나, LLM의 자유도가 너무 높아서 반드시 정해진 순서대로 실행되어야 하는 결제·승인 파이프라인에서 엉뚱한 동작을 하는 문제가 생기는 거죠.게다가 로컬에서 프로토타입으로 만든 에이전트를 실제 운영 환경에 배포하려고 하면 세션(Session) 상태 관리부터 멀티 에이전트 간 위임, 트레이싱(Tracing), 그리고 "프롬..

요즘 사내 개발 조직이나 운영 팀에서 Claude Code나 웹 기반의 claude.ai를 안 쓰는 곳을 찾기가 더 힘들 정도가 되었습니다. 하지만 개인 터미널이나 1:1 채팅창에서 AI를 쓰다 보면 필연적으로 아쉬운 순간이 찾아오는데요. 예를 들어 프로덕션 장애가 터져서 여러 엔지니어가 Slack 채널에 모여 원인을 분석하고 있는데, 정작 AI에게 로그 분석이나 코드 수정을 시키는 과정은 각자의 로컬 터미널에서 따로따로 일어나다 보니 맥락이 단절되는 문제가 생기는 거죠.누군가 Claude에게 질문해서 얻은 결과를 복사해서 다시 Slack 스레드에 붙여넣고, 다른 팀원이 거기에 첨언하면 또 복사해서 프롬프트로 넘기는 식의 비효율이 반복되기 마련입니다. 게다가 기존에 제공되던 레거시 Claude in Sl..

AWS Lambda를 사용해 웹 애플리케이션이나 API 백엔드를 구축해 보신 분들이라면, 한 번쯤은 "그냥 로컬에서 돌리던 Express나 Fastify 서버를 그대로 올릴 수는 없을까?" 하는 아쉬움을 느껴보셨을 겁니다. 기존 Lambda는 본질적으로 S3 객체 업로드나 SQS 메시지 유입 같은 단일 이벤트를 처리하기 위한 함수형 모델(handler(event, context))로 출발했기 때문인데요.이 위에서 일반적인 HTTP 웹 서버를 돌리려다 보니 아키텍처적인 마찰과 비용 비효율이 꽤 컸습니다. 요청 하나당 실행 환경(Execution Environment) 하나가 통째로 점유되어 트래픽이 조금만 튀어도 콜드 스타트(Cold Start)가 연쇄적으로 발생한다거나, DB 쿼리나 외부 LLM API ..

EKS 환경에서 노드 오토스케일러로 Karpenter를 운영하다 보면, 버전을 올릴 때마다 단순히 새로운 기능만 추가되는 게 아니라 기존의 Disruption(노드 회수 및 교체) 동작 방식이나 메트릭 레이블이 은근히 바뀌는 경우가 있습니다. 특히 운영 환경에서 Node Auto Repair를 켜두었거나, GPU 워크로드를 위해 ODCR(On-Demand Capacity Reservations)을 꽉 채워서 쓰고 계신 분들이라면 이번 릴리즈를 꽤 반갑게 보실 텐데요.최근 릴리즈된 Karpenter v1.15.0(Upstream Core 및 AWS Provider 통합 릴리즈)에서는 비정상 노드를 강제로 내리던 Node Auto Repair가 드디어 Graceful(Voluntary) Disruption ..

실무에서 대규모 레거시 코드베이스를 리팩토링하거나 수십 개의 파일이 얽혀 있는 인프라/애플리케이션 코드를 에이전트에게 맡기다 보면, 모델의 추론 깊이(Reasoning Depth)나 한 번에 생성할 수 있는 출력 토큰 한계에 부딪히는 경우가 종종 있습니다. 컨텍스트 윈도우 자체는 넓어졌더라도 한 번의 턴에서 뱉어낼 수 있는 출력이 64K 토큰 수준에 머물러 있으면, 긴 호흡의 작업(Long-horizon task)을 처리할 때 중간에 호흡이 끊기거나 단계별로 프롬프트를 계속 쪼개서 이어 붙여야 하는 번거로움이 생기거든요.이런 복잡한 엔지니어링과 장기 추론 워크플로우를 겨냥해 Google DeepMind에서 새로운 프론티어 모델인 Gemini 4 Argon을 공개했습니다. 처음 발표 당시에는 사이버 보안 ..