컴맹 : 진화의 시작

최근 터미널에서 동작하는 코딩 에이전트인 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을 공개했습니다. 처음 발표 당시에는 사이버 보안 ..

쿠버네티스(EKS) 환경에서 애플리케이션 파드를 운영하다 보면 S3 버킷에 파일을 업로드하거나 DynamoDB, SQS 같은 AWS 리소스를 호출해야 하는 경우가 정말 많습니다. 초창기에는 파드 내부 환경 변수에 IAM User의 Access Key와 Secret Key를 직접 주입해서 쓰기도 했고, 귀찮다는 이유로 아예 EKS 워커 노드(EC2)의 IAM Role에 S3나 DynamoDB 권한을 통째로 넣어버리는 경우도 종종 있었거든요.하지만 워커 노드에 권한을 몰아주면 그 노드 위에 뜨는 모든 파드가 동일한 권한을 공유하게 되어 최소 권한 원칙(Least Privilege)이 완전히 깨지게 됩니다. 이를 해결하기 위해 등장한 표준 방식이 바로 쿠버네티스의 ServiceAccount와 AWS IAM R..

GitHub Actions를 이용해 애플리케이션을 빌드하고 도커(Docker) 이미지를 AWS ECR(Elastic Container Registry)에 푸시하는 파이프라인은 실무에서 가장 흔하게 구성하는 CI 워크플로우 중 하나입니다. 예전에는 이를 위해 AWS IAM User를 생성하고, 거기서 발급받은 AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY를 GitHub Repository Secrets에 등록해 두고 사용하는 경우가 많았습니다.하지만 이렇게 만료 기간이 없는 고정 자격 증명(Long-lived credentials)을 발급해 두면 보안 감사를 위해 주기적으로 키를 교체(Rotation)해 줘야 하는 운영 부담이 따릅니다. 게다가 프로젝트와 리포지토리가 늘어날수록 ..

2010년부터 지금까지 스택오버플로우(Stack Overflow)에 올라온 월별 신규 질문 추이를 쿼리로 뽑아봤다. 그래프에는 지난 16년간 소프트웨어 엔지니어링 씬의 이야기가 고스란히 담겨 있는데 재밌다.1/ 2010년부터 2014년 3월까지는 그야말로 폭발적인 상승기였다. 2010년 초에 월 4만 5천 건 수준이던 질문 수는 매년 무섭게 치솟더니 2014년 3월에 월 20만 7천 건으로 역사상 최고점을 찍었다. 스마트폰 보급과 함께 iOS와 안드로이드 앱 생태계가 열렸고, AWS를 필두로 한 클라우드 전환과 Node.js, Angular, React 같은 모던 웹 프레임워크가 쏟아져 나오던 시기다. 전 세계적으로 개발자 인구가 급증했는데, 새로운 기술을 쓰다 막히면 물어볼 곳이 스택오버플로밖에 없었으..

테라폼(Terraform)을 처음 로컬 환경에서 실행해 보면 프로젝트 디렉터리에 terraform.tfstate라는 파일이 생성되는 것을 볼 수 있습니다. 혼자서 간단한 테스트 인프라를 띄울 때는 이 로컬 상태 파일만으로도 큰 문제가 없지만, 실무에서 여러 명의 엔지니어가 협업하거나 CI/CD 파이프라인을 통해 인프라를 배포하기 시작하면 이야기가 달라집니다.누군가 본인의 노트북에서 리소스를 수정했는데 다른 팀원의 로컬에는 구버전의 tfstate가 남아 있다면 인프라 상태가 꼬여버릴 수밖에 없거든요. 게다가 tfstate 파일 안에는 DB 패스워드나 각종 시크릿 같은 민감한 데이터들이 평문으로 기록되기 때문에 이를 Git 저장소에 그대로 커밋해서 공유할 수도 없는 노릇입니다.그래서 AWS 환경에서 테라폼을..

쿠버네티스 클러스터를 운영하다 보면 노드를 어떻게 효율적으로 늘리고 줄일지가 늘 숙제로 남습니다. 오랫동안 표준처럼 쓰이던 Cluster Autoscaler(CA)는 클라우드 벤더의 오토스케일링 그룹(AWS로 치면 ASG와 Managed Node Group)에 강하게 묶여 있다 보니, 파드가 필요로 하는 스펙에 딱 맞는 인스턴스를 즉각적으로 띄우는 데 한계가 있었거든요. 인스턴스 타입별로 노드 그룹을 잘게 쪼개서 관리해 보신 분들이라면 그 고통을 잘 아실 겁니다 (...)이런 불편함을 해결하기 위해 등장한 것이 바로 Karpenter입니다. 이미 많은 곳에서 도입해 사용하고 계시겠지만, 의외로 초기 버전(Provisioner 시절)의 개념에만 머물러 있거나 kubernetes-sigs/karpenter ..

1/ 구글의 플래그십 모델 Gemini 4 Argon이 일반에 공개됐다. 운 좋게 얼리 액세스(Early Access) 권한을 얻어 며칠 전부터 써보고 있었는데 아주 훌륭하다.2/ 관전 포인트는 속도와 토큰량이다. 이전부터 늘 하던 말이지만, 나 같은 범인에게는 이미 모델의 기본 성능이 작업의 대세에 큰 영향을 주지 않는다(촘촘한 검증 루프는 계속 필요하지만). 그렇다면 남은 건 결과물을 받아보는 속도와 얼마나 많은 요청을 처리할 수 있는가 하는 토큰량이다.3/ 처리되는 속도는 당연히 Flash 모델 대비해서는 더디지만, 중요한 의사결정을 할 수 있고 Flash 모델을 오케스트레이션 하며 지시를 내리기 충분하다. 그리고 토큰도 미디움으로 사용했을 때 감당할 수준이다.4/ 개인적으로 “원샷 프롬프트로 어디..

한빛미디어 서평단 활동을 위해서 책을 협찬받아 작성된 서평입니다 AI가 스스로 코드를 찍어내는 시대에 과연 개발자의 가치는 어디로 향해야 하는가라는 질문은, 최근 기술 생태계를 관통하는 가장 무겁고도 본질적인 화두입니다. 저는 이번 책을 단순히 인공지능 도구를 다루는 기술 지침서가 아니라, 기계가 구현을 가속할수록 더욱 빛을 발해야 하는 인간 엔지니어의 존재 이유와 사고방식을 다시 정의하는 사색적인 길잡이로 해석했습니다.코드를 넘어 질문으로 향하는 엔지니어: 『AI 시대의 엔지니어링 전략』을 읽고인공지능이 복잡한 알고리즘을 순식간에 작성하고 버그를 찾아내는 광경을 보며, 수많은 개발자들이 형언하기 어려운 위기감을 토로합니다. 어제까지 갈고닦던 코드 구현 기술이 하룻밤 사이에 대체 가능한 노동으로 전락하..

올해 Google I/O Connect는 베를린, 벵갈루루, 상해에서 열렸습니다. Google I/O Connect는 구글의 연례 최대 행사인 Google I/O의 세계 거점 행사입니다. 저는 이번에 GDE 자격으로 구글의 지원을 받아 상해 행사에 참석할 수 있었는데요. 방문이 예정된 시기에 태풍 '돌핀'이 상해를 강타하면서 걱정도 많았습니다. 실제로 일정보다 조금 일찍 떠난 다른 분들은 숙소에 갇혀있었다는 이야기도 들을 수 있었습니다. 개인적으로 중국 방문은 7년 전 베이징에 이어 이번이 두 번째였습니다.숙소는 도심 외곽 느낌의 장소에 잡혔습니다. 행사장까지는 대략 버스로 20분 정도 이동한 것 같습니다. 행사에 참석한 APAC GDE를 위해 버스가 제공됐기에 행사장을 편하게 오갈 수 있었어요. 시간 ..

한빛미디어 서평단 활동을 위해서 책을 협찬받아 작성된 서평입니다 한빛미디어에서 제게 꼭 필요한 책이 나왔습니다. 바로 AI도 모르는 글쓰기: 초안을 완성으로 바꾸는 AI 협업 글쓰기 입니다. 인공지능이 몇 초 만에 그럴듯한 보고서를 뚝딱 만들어내는 세상입니다. 질문 한 줄만 입력하면 정교한 문장과 매끄러운 단어가 폭포수처럼 쏟아지는데, 아이러니하게도 현업에서 일하는 수많은 직장인들은 여전히 글쓰기 앞에서 깊은 갈증과 피로감을 느낍니다. 저도 그렇습니다. 소셜 미디어를 넘어 기술 블로그 등에 AI로 작성된 글을 보면 바로 피로감이 올라오거든요. AI로 문서의 양은 폭증했지만, 정작 마음을 움직이거나 명확한 행동을 이끌어내는 '알맹이 있는 글'은 더욱 찾기 힘들어졌기 때문입니다. 오늘 소개할 책은 이러한 ..

전에 스케일링 후 출혈 글을 썼는데 많은 분들이 읽어주셔서 누군가에게 도움이 될까 싶어 이번 에피소드를 작성해 본다. 2019년도에 스케일링받고 출혈을 겪은 이후에 같은 병원에서 사랑니를 발치했다. 교수님께 덜덜 떨면서 스케일링 때 이런 일이 있었다고 이야기드렸더니, 사랑니 발치는 꿰매는 거라서 문제없다고 대수롭지 않게 말씀하셨던 기억이 난다(저한테는 지옥 같은 시간이었는데요...?? 이렇게 쿨하시다니). 하지만 역시 교수님. 그날 왼쪽 위아래 사랑니 두 개를 뽑고도 실제로 아무 문제 없이 넘어갔었다. 문제가 없었다고 고통이 없었던 건 아니다. 그날 결심했다. 오른쪽 위아래 사랑니는 평생 가져가기로... ^^인간을 망각의 동물이라고 하던가. 7년 정도 지나니까 사랑니 발치가 정확히 어떤 고통이었는지 잊어..