지금 팀에서 AI 에이전트를 어떻게 쓰고 있나요?
솔직히 물어보겠습니다. CLI 열고, 프롬프트 붙여넣고, 결과 기다렸다가, 브랜치 확인하고, 다시 처음부터 반복—이게 지금 팀의 에이전트 워크플로우 전부라면, 아직 에이전트를 '도구'로만 쓰고 있는 겁니다. 문제는 이 방식이 특정 임계점을 넘으면 무너진다는 겁니다. 배경에서 돌아가야 하고, 이벤트에 반응해야 하고, 병렬로 스케일해야 하는 순간—채팅 세션 기반 에이전트는 한계가 드러납니다.
에이전트를 인프라로 보는 시각의 전환
dev.to에 소개된 Kelos 프로젝트는 이 문제를 정면으로 다룹니다. Kubernetes 네이티브 에이전트 오케스트레이션 프레임워크인 Kelos의 핵심 아이디어는 단순합니다. AI 코딩 에이전트를 채팅 세션이 아니라 인프라 워크로드로 선언하는 것입니다.
구체적으로는 네 가지 프리미티브로 구성됩니다. Task(에이전트 작업 단위), Workspace(레포 컨텍스트), AgentConfig(지침·스킬·MCP 서버 통합 패키지), TaskSpawner(GitHub 이슈·PR·크론 스케줄 등 외부 이벤트 트리거). 워크플로우는 YAML로 선언되고, 클러스터가 지속적으로 실행합니다. dependsOn으로 체이닝이 가능해서 단일 프롬프트 실행이 아닌 다단계 파이프라인을 구성할 수 있습니다.
흥미로운 지점은 Kelos 자체가 이 방식으로 자기 개발에 에이전트를 활용하고 있다는 겁니다. 이슈 트리아지, 구현 플랜 생성, 버그 수정, PR 피드백 대응—항상 켜져 있는 TaskSpawner들이 이 작업을 처리합니다. 에이전트가 완벽하지 않고 피드백과 수정이 여전히 필요하다는 점도 명시합니다. 하지만 그게 요점이기도 합니다. 운영 가능한 시스템을 만드는 것, 즉 검사하고 개선하고 진화시킬 수 있는 워크플로우를 갖추는 것이죠.
에이전트를 인프라에 넣기 전에 반드시 짚어야 할 보안
Kelos식 접근이 매력적으로 들린다면, 도입 전에 냉정하게 봐야 할 게 있습니다. 보안 설계입니다.
dev.to의 또 다른 글은 DevOps 에이전트 구축 시 실제 시니어 테스터 관점의 보안 감사 결과를 다룹니다. 핵심 지적은 이겁니다. 개발자들이 신뢰할 수 없는 웹훅 페이로드를 그대로 CLI 명령어로 파이핑하고 있다는 것. Datadog 알림이 오면 alert_payload.get("pod_name")을 그대로 kubectl logs에 넘기는 식입니다.
이 글에서 제시하는 하드닝 파이프라인은 네 단계입니다:
- HMAC 서명 검증: 인바운드 웹훅의 진위 확인
- 엄격한 입력 유효성 검사: Pydantic 스키마 + 정규식으로
pod_name이 정말 Kubernetes 파드 이름인지 확인 (CLI 플래그가 아닌지) - 실행 샌드박싱: 바이너리 절대 경로 사용,
--구분자로 CLI 플래그 주입 차단 - 출력 트런케이션: LLM에 넘기는 데이터를 최대 2000자로 제한
특히 Argument Injection은 조용한 킬러입니다. --selector=app=database 같은 파드 이름이 들어오면, 의도와 전혀 다른 범위의 로그를 덤프할 수 있습니다. 알림 폭풍 DoS 문제도 있습니다. 클러스터가 재시작되며 Datadog에서 500개 알림이 동시에 오면, 에이전트가 500개 Python 프로세스와 1000개 kubectl 명령어를 동시에 실행합니다. Redis Token Bucket 같은 레이트 리미터가 없으면 클러스터 자체가 위험합니다.
자동 복구 기능을 일찍 붙이지 말라는 조언도 중요합니다. OOMKilled 감지 시 파드를 자동 재시작하는 게 그럴듯해 보여도, 에이전트는 하위 의존성 컨텍스트를 모릅니다. DB 마이그레이션 중인 파드를 눈 감고 재시작하면 어떻게 될지 생각해보세요.
AI 코드 리뷰도 같은 논리다: 단일 도구 의존은 위험
에이전트 인프라화와 같은 맥락에서 볼 수 있는 게 AI 코드 리뷰 도구 선택입니다. dev.to의 CodeRabbit 대안 비교 글에서 2026년 독립 벤치마크 결과가 눈에 띕니다. 309개 PR 대상 테스트에서 CodeRabbit은 완전성 1/5, 깊이 2/5를 기록했습니다. 실제 버그 감지율은 44%. 반면 Greptile은 82%였습니다.
이 수치가 의미하는 건 단순히 "어떤 도구가 더 좋냐"가 아닙니다. 리뷰 도구를 단일 신뢰 소스로 삼을 수 없다는 것입니다. CodeRabbit은 빠른 합성 에러, 보안 취약점, 스타일 위반은 잘 잡습니다. 하지만 의도 불일치, 성능 함의, 크로스 서비스 의존성은 자주 놓칩니다.
또 주목할 점은 GitHub Copilot의 진화입니다. 2026년 3월 기준 완전한 에이전틱 아키텍처로 전환되어, 코드 리뷰 시 관련 파일을 읽고 디렉토리 구조를 파악하며 레퍼런스를 추적합니다. 단순 diff 분석이 아닌 아키텍처 컨텍스트를 반영한 리뷰가 가능해졌다는 뜻입니다. 에이전트 기반 리뷰와 정적 분석 도구(SonarQube, DeepSource)를 조합하는 레이어드 접근이 실질적으로 필요한 이유입니다.
팀 리드가 설계해야 할 세 가지 레이어
세 기사를 관통하는 메시지를 정리하면 이렇습니다. 에이전트를 팀 인프라 시민으로 운영하려면 다음 세 레이어가 필요합니다.
1. 오케스트레이션 레이어: 에이전트 작업을 선언적으로 정의하고, 버전 관리하고, 트리거 기반으로 실행합니다. Kelos처럼 Kubernetes를 쓰든, 다른 방식을 쓰든, 핵심은 "채팅 세션"이 아닌 "선언형 워크플로우"입니다.
2. 보안·경계 레이어: 에이전트에게 최소 권한만 줍니다. 읽기 전용으로 시작하고, 쓰기 작업은 인간 승인 게이트를 거칩니다. 인바운드 입력은 반드시 검증합니다. 자동 복구는 충분한 컨텍스트와 신뢰가 쌓인 뒤에 붙입니다.
3. 품질 검증 레이어: AI 생성 코드와 AI 리뷰 결과 모두 단일 도구를 맹신하지 않습니다. 에이전틱 리뷰 + 정적 분석의 조합, 그리고 리뷰 결과를 시간이 지나며 평가하는 피드백 루프가 필요합니다.
지금 당장 할 수 있는 것
Kelos는 Kubernetes 클러스터와 상당한 설정 비용을 요구합니다. 내일 당장 모든 팀에 맞는 선택은 아닐 수 있습니다. 하지만 핵심 개념—에이전트 작업을 YAML로 선언하고, 트리거로 자동화하고, 파이프라인으로 체이닝하는—은 지금 팀 워크플로우에 점진적으로 도입 가능합니다.
시작점을 제안하자면: 가장 반복적이고 낮은 위험도의 에이전트 작업 하나를 골라보세요. 이슈 트리아지, PR 설명 초안 생성, 린트 오류 자동 수정 같은 것들입니다. 그걸 선언형으로 정의하고, 입력을 검증하고, 출력을 모니터링하세요. 이 작은 루프를 안정적으로 운영하는 데 성공한 팀이, 다음 단계로 나아갈 수 있습니다.
"AI가 나를 대체한다"는 공포도, "AI가 다 해준다"는 낙관도 모두 틀렸습니다. 에이전트는 운영 가능한 시스템으로 설계될 때 비로소 팀의 실질적인 일원이 됩니다.