TECH 으로 돌아가기
TECH HACKER NEWS 오늘 7분 읽기 22 READS

코딩 에이전트에게 인프라를 맡기면 안 되는 이유, 그리고 Neckbeard의 해법

코딩 에이전트에게 인프라를 맡기면 안 되는 이유, 그리고 Neckbeard의 해법
SOURCE IMAGE · HACKER NEWS

코딩 에이전트는 애플리케이션 코드를 잘 다룬다. 하지만 클라우드 인프라를 즉석에서 작성하라고 하면 이야기가 달라진다. 겉보기에는 그럴듯한 HCL(HashiCorp Configuration Language) 코드를 뱉어내지만, 미묘하게 깨져 있거나 기본값이 보안에 취약하고, 비용을 가늠할 수 없는 경우가 대부분이다. Neckbeard는 바로 이 실패 패턴을 겨냥해 만들어진 에이전트 플러그인이다. 이름 그대로 'DevOps/플랫폼/SRE 역할을 대신하는 넥비어드(수염 난 베테랑 엔지니어)'를 표방한다.

역할을 뒤집는다는 발상

Neckbeard의 핵심 아이디어는 에이전트와 결정론적 코드의 역할 분담이다. 에이전트는 애플리케이션을 읽고 그 내용을 설명하는 데만 관여한다. 실제 계획 수립, 인프라 렌더링, 검증은 모두 결정론적인 코드가 담당한다. 즉 에이전트가 인프라를 '지어내지' 않는다. 렌더링의 원천은 테스트를 거친 OpenTofu 모듈 카탈로그이며, 이 카탈로그는 플러그인에 버전 관리된 형태로 번들링되어 있다. AWS, GCP, Azure 중 하나의 클라우드, GitHub Actions 또는 GitLab CI 중 하나의 파이프라인, 서버리스 컨테이너 또는 쿠버네티스 중 하나의 실행 방식을 조합해 결과물을 만들어낸다.

여기서 눈에 띄는 설계 원칙은 카탈로그가 표현할 수 없는 요구사항을 억지로 가장 비슷한 모듈에 끼워 맞추지 않는다는 점이다. 대신 그런 요구사항은 'redis는 워크로드 계약 범위 밖에 있다'와 같이 이름이 붙은 '발견 사항(finding)'으로 명시된다. 억지 구현 대신 한계를 솔직하게 드러내는 방식이다.

비용을 정직하게 말한다

Neckbeard가 스스로 내세우는 또 다른 차별점은 '비용 정직성'이다. HTTP 서비스와 워커, 크론, Postgres로 구성된 참조 애플리케이션을 가장 작은 티어로, 세 개 환경 모두에 대해 Infracost의 실시간 가격으로 산정한 사례가 제시된다. 흥미로운 대목은 Infracost가 아직 Azure Container Apps의 컴퓨팅 비용을 산정하지 못한다는 점을 다루는 방식이다. 낮게 나온 숫자가 거짓말을 하도록 내버려 두는 대신, 리포트는 가격이 매겨지지 않은 모든 리소스를 그대로 나열한다.

이것이 Neckbeard가 말하는 '하우스 스타일'이다. 유휴 상태의 기준 비용(baseline-while-idle), 사용자가 직접 수정할 수 있는 명시적 사용량 가정, 낮음·예상·높음의 세 가지 시나리오, 그리고 출처를 밝히는 푸터가 함께 따라붙는다. 이 비용표는 단순한 숫자가 아니라 의사결정에 가격을 매기는 도구다. 솔로 개발자에게 '아직 쿠버네티스는 필요 없다'고 근거를 들어 말할 수 있는 것도 이 때문이다.

세 번째 판정이 요점이다

인프라 도구들은 자신이 증명한 것보다 더 많은 것을 암시하려는 경향이 있다. Neckbeard는 리포트를 세 가지 판정으로 구분하는데, 정작 중요한 것은 세 번째, 즉 '지원하지 않음(unsupported)' 판정이다. 지원하는 워크로드는 명확히 한정되어 있다. 하나의 이미지, 최대 10개의 HTTP·워커·크론 프로세스, Postgres, 오브젝트 스토리지, 시크릿, 그리고 이미 존재하는 계정·프로젝트·구독으로의 배포까지다. 그 밖의 모든 것은 명시적인 미지원 발견 사항으로 처리된다. 할 수 있는 것과 없는 것의 경계를 흐리지 않겠다는 태도다.

지금은 '온보딩 절반'까지

실무자가 기대 수준을 조정하려면 현재 제품의 범위를 분명히 알아야 한다. 오늘의 Neckbeard가 제공하는 것은 온보딩 절반이다. 리뷰 가능한 인프라 코드, 파이프라인, 비용 추정치, 그리고 사람에게 그대로 넘겨줄 수 있는 부트스트랩 런북이 그 결과물이다. 반면 배포 수명주기(neckbeard release 계열 기능)는 실험 단계이며 런치 플랜에서 게이트 단위로 추적되고 있다. 조직 구조와 가드레일을 다루는 랜딩 존(DESIGN.md의 Path F)은 설계만 되어 있을 뿐 아직 구현되지 않았다. 문서가 강조하듯 정적 검증을 배포가 성공했다는 증거로 받아들여서는 안 된다.

설치와 운용도 비교적 단출하다. 애플리케이션 저장소에서 /neckbeard:analyze를 실행하면 되고, 첫 명령 실행 시 플러그인이 구동하는 작은 Neckbeard CLI가 설치된다. 이 CLI는 sha256으로 검증된 릴리스 바이너리거나, Go가 설치된 환경이라면 go install로 받는다. 비용 추정과 정적 검증에는 이미 보유하고 있을 법한 Infracost, OpenTofu, Checkov를 활용하며, /neckbeard:doctor 명령이 어떤 도구가 빠져 있고 각 도구가 무엇을 해제해 주는지 알려준다. Codex나 Cursor처럼 SKILL.md를 이해하는 다른 에이전트에서도 INSTALL.md를 참고해 쓸 수 있고, 저장소의 Go CLI는 에이전트 없이 단독으로도 모든 기능을 구동한다.

결국 Neckbeard가 던지는 메시지는 단순하다. 인프라의 창의성은 에이전트에게 맡기기에 위험하며, 검증된 모듈과 결정론적 코드가 그 자리를 대신해야 한다는 것이다. 자동화된 인프라 생성 도구에 관심 있는 팀이라면, 화려한 기능 목록보다 '무엇을 하지 않는지'를 명시하는 이 도구의 태도 자체가 참고할 만한 지점이다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://github.com/bealesh/neckbeard
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...