코딩 에이전트의 클라우드 인프라 생성에 견적서와 검증을 붙인 Neckbeard

코딩 에이전트에 붙여 쓰는 플러그인 Neckbeard가 공개됐다. 애플리케이션 저장소를 읽어 클라우드 인프라를 만들어내되, 결과물을 사람이 리뷰할 수 있는 형태로 내놓고 월 예상 청구서를 함께 붙인다. 저장소는 GitHub의 bealesh/neckbeard다.

출발점은 코딩 에이전트의 잘 알려진 습관이다. 애플리케이션 코드는 능숙하게 다루면서 인프라에 대해서는 근거 없이 자신만만하다. "이 앱을 AWS에 올려줘"라고 하면 그럴듯해 보이는 HCL이 수백 줄 쏟아지고, 그 안에는 전 세계에 열린 보안 그룹과 별표가 박힌 IAM 정책이 들어 있다. 비용이 얼마인지는 아무도 모른다. 모델이 거짓말을 하는 게 아니라, 청구서를 한 번도 본 적이 없어서 그렇다.

Neckbeard는 이 일을 둘로 쪼갠다. 사람은 OpenTofu 모듈 카탈로그를 관리한다. 각 모듈은 버전이 붙고 변경마다 CI에서 테스트되며, 하나의 워크로드 형태로 범위가 제한된다. 컨테이너 이미지 하나, 최대 열 개의 HTTP·워커·크론 프로세스, Postgres, 오브젝트 스토리지, 시크릿이 그 범위다. 에이전트는 저장소를 읽어 앱이 무엇을 필요로 하는지 파악하고, 코드만으로는 답할 수 없는 질문을 사람에게 던진 뒤, 그 답을 카탈로그 입력값에 매핑한다.

그 사이의 처리는 전부 결정적 Go 코드다. 플래너가 해시로 검증되는 blueprint.yaml을 작성하고, 렌더러는 그 파일의 순수 함수로 동작한다. 다시 생성할 때 사람이 손댄 파일은 덮어쓰지 않는다. 에이전트가 인프라를 새로 지어내는 경로 자체가 없다. 앱에 Redis가 필요하면 없는 모듈을 즉석에서 만들지 않고, 카탈로그가 아직 Redis를 다루지 않는다는 finding을 이름 붙여 남긴다.

설치는 Claude Code 기준으로 마켓플레이스 등록과 플러그인 설치 두 줄이면 끝난다. 첫 명령을 실행할 때 플러그인이 구동하는 소규모 CLI가 함께 깔리는데, sha256으로 검증된 릴리스 바이너리이거나 Go가 있으면 go install로 받는다. SKILL.md를 읽는 도구라면 Codex나 Cursor에서도 쓸 수 있다. /neckbeard:analyze는 Dockerfile, 노출 포트, 환경변수, 헬스 엔드포인트, Procfile, settings.py가 DATABASE_URL을 읽는 지점까지 훑는다. 결과물인 app-profile.yaml에는 모든 사실에 파일과 줄 번호가, 모든 추론에 신뢰도가, 모든 가정에 표시가 붙는다. 예상 트래픽, 감내할 다운타임, 기존 Postgres를 쓸지 새로 만들지, 워커의 용도 같은 질문이 이어지고, 답이 하나라도 비어 있으면 플래닝 단계로 넘어가지 않는다.

비용은 Infracost로 실제 가격을 조회한다. HTTP 서비스, 워커, 크론, Postgres로 구성된 동일한 참조 앱을 최소 티어로 세 환경에 올렸을 때의 값을 보여주는 식이다. Infracost가 아직 Container Apps 컴퓨팅 가격을 매기지 못하는 부분은 낮은 숫자로 얼버무리지 않고, 가격을 못 낸 리소스를 총액 옆에 그대로 나열한다. 유휴 상태의 기준선과 사용량을 분리하고, 사용량 가정은 편집 가능한 곳에 적어 두고, 낮음·예상·높음 세 시나리오와 숫자 출처를 함께 제시한다. 혼자 개발하는 사람이 Kubernetes를 요청하면 이 표가 먼저 "아직은 아니다"라고 말해준다.

검증은 세 단계로 나뉘고, 세 번째까지 보여주는 것을 원칙으로 한다. V0는 문법과 정책 검사로 Checkov와 kubeconform이 담당한다. Checkov가 건너뛴 항목에는 예외 없이 이유가 기록되는데, 이유 없는 스킵은 보안 태세에 대한 거짓말이기 때문이다. V1은 인증된 plan, V2는 실제 배포 검증이며 둘 다 클라우드 자격증명이 필요하다. 자격증명이 없는 동안 두 단계는 NOT EXERCISED로 남는다. tofu validate를 통과했다는 사실이 배포 성공을 뜻한 적은 없다는 문제의식이 깔려 있다.

환경은 상태를 각자 가진 세 개로 격리되고, 티어 프리셋이 트래픽과 가용성, 복구 목표, 실제로 운영할 인원까지 명시한다. 프리셋 값은 모두 노출되어 카탈로그가 테스트한 범위 안에서 덮어쓸 수 있고, 범위를 벗어나면 승인 대신 표시가 붙는다. 파이프라인은 GitHub Actions든 GitLab CI든 하나의 내부 모델에서 나온다. 테스트, 빌드, 스캔(Trivy가 HIGH와 CRITICAL을 차단), 푸시가 기본이고 풀 리퀘스트에서는 읽기 전용 아이덴티티로 plan을, main에서는 쓰기 아이덴티티로 apply를 돌리며 프로덕션은 환경 보호 뒤에 둔다. 정적 클라우드 키는 어디에도 없고 전 구간이 OIDC 페더레이션이다. 렌더링된 파이프라인이 AWS_SECRET_ACCESS_KEY를 언급하기만 해도 빌드가 실패한다. 네트워크는 기본이 프라이빗이고, 시크릿 값은 Neckbeard나 그 상태, git 히스토리를 거치지 않으며 운영자가 이름만 채워 넣는 방식이다. 티어가 요구하면 관리형 WAF 규칙이 켜진다. 비용 통제는 두 가지로 나뉘어 서로 혼동되지 않는다. monthly_budget_alert는 환경별 실제 클라우드 예산을 만들어 알림을 보내고, monthly_ceiling은 리소스가 생기기 전이라는 한계가 강제될 수 있는 유일한 지점에서 실제로 거부한다.

지원 범위는 AWS, GCP, Azure와 GitHub Actions, GitLab CI, 그리고 서버리스 컨테이너(Cloud Run, ECS Fargate, Container Apps)와 Kubernetes(EKS, GKE, AKS)의 조합 12개 경로다. 정적 매트릭스는 모든 PR에서 CI로 돌고, 서로 무관한 세 개의 픽스처 앱이 처음부터 끝까지 온보딩된다. 실제 배포는 AWS/GitHub과 Azure/GitHub 조합에서 실제 데이터베이스 검사까지 포함해 통과했다. GCP 라이브 배포와 GitLab 레인, Kubernetes, 프로모션, 복구 훈련은 아직 검증되지 않았다.

실무적으로 눈여겨볼 지점은 실패를 다루는 방식이다. 라이브 실행에서 깨진 것들은 공개 findings ledger에 쌓이고, 거기서 다시 카탈로그로 흘러 들어간다. 첫 실제 배포에서 열 건이 나왔고 그중 다섯 건은 같은 날 오후에 모듈 수정으로 이어졌다. Azure와 GitLab의 머지 리퀘스트 조합처럼 페더레이션이 되지 않는 경로는 파이프라인이 그 사실을 소리 내어 말한다. 저녁 하나를 날리는 방식으로 실패하지 않겠다는 설계다.

다만 아직 pre-alpha다. 라이브 배포와 업데이트, 롤백은 서버리스 컨테이너에서만 검증됐고 Kubernetes와 GitLab, GCP 라이브 경로는 구현은 되어 있으나 실행된 적이 없다. 카탈로그가 다루지 않는 워크로드 형태는 지원 대상이 아니며, 그 경계는 모듈을 지어내는 대신 finding으로 드러난다.