Claude는 컴파일러가 아니다: vibe-engineering으로 분산 DNS 서버 만든 후기

TL;DR Highlight

에이전트 여러 개로 구현을 비교했더니 일주일 만에 분산 DNS 서버를 냈다

Who Should Read

코딩 에이전트에 큰 설계를 맡기면서 어디까지 직접 결정하고 이해해야 할지 고민하는 백엔드 개발자

Core Mechanics

Claude는 컴파일러보다 넓게 일한다
- 컴파일러는 소스에서 바이너리까지 맨 아래 한 층만 맡는다.
- Claude는 전략·제품·아키텍처·코드·기계어까지 층을 가로질러 다룬다.
- 필자는 이를 한 번 맡기고 끝내는 vibe-coding과 구분해 vibe-engineering이라 부른다.
DNS 전파 지연이 문제의 출발점이었다
- exe.dev VM은 너무 빨리 떠서 DNS 전파를 기다리는 시간이 길었고, 가끔 몇 분이 걸렸다.
- 자체 DNS 서버를 만들었지만 리전을 늘리자 오리건에서만 DNS를 서빙해 다시 병목이 됐다.
- 배포 때마다 짧은 DNS 장애도 났다.
사람이 큰 방향을 정하고 LLM이 조사했다
- 허브앤스포크, append-only 복제, 엣지 영속화 같은 상위 결정은 팀이 직접 정했다.
- LLM에게 표준 설계, DNS 함정, 보안 사례, 장애 시나리오, 테스트 전략을 조사시켰다.
에이전트 여러 개에 같은 걸 만들게 하고 차이를 비교했다
- 동시 에이전트 루프로 테스트와 적대적 코드 리뷰까지 포함해 전체를 구현시켰다.
- 완성본끼리 비교하니 에이전트가 묻지 않고 각자 다르게 내린 중요한 결정이 많았다.
- 이 비교와 가이드 보강을 총 세 번 반복했다.

Community Reactions

컴파일러는 결정적이라 비유가 안 맞는다는 의견
- 컴파일러는 대체로 결정적인데 LLM은 아니라는 지적이 있었다.
- 모든 코드를 리뷰하면 속도 이득이 줄고, 테스트만 믿으면 사람의 감독이 없다는 딜레마를 말한 댓글이 있었다.
코드를 안 읽는 건 불안하다는 의견
- 프로덕션에 배포할 코드를 읽지 않는 건 이해하기 어렵다는 댓글이 있었다.
- 직접 수정하기 어렵다면 이해한 게 아니라는 반론도 있었다.
암묵적으로 넘긴 결정이 문제일 수 있다는 의견
- 분산 시스템 전문가가 timeline 방식과 전체 DNS 구조를 검토해 주면 좋겠다는 댓글이 있었다.
- 에이전트에 암묵적으로 넘긴 결정이 나중에 더 중요해질까 걱정된다는 의견이었다.
DNS 설계 자체에 의문을 제기한 댓글
- 리졸버 캐시 때문에 서버 쪽에서 전파 지연을 못 없앤다는 지적이 있었다.
- dnsmasq나 unbound 같은 기존 도구, 애니캐스트 IP 앞 와일드카드 DNS로 풀 수 없었냐는 질문도 있었다.

How to Apply

에이전트가 알아서 정한 결정 목록 뽑기
- 오늘 최근 에이전트가 만든 코드 하나를 골라, 요청하지 않았는데 에이전트가 내린 설계 결정을 나열시켜라.
- 나열된 것 중 중요한 것만 골라 직접 결정을 내려라.
같은 스펙으로 에이전트 2~3개 돌려 비교하기
- 새 모듈을 만들 때 같은 스펙을 에이전트 둘 이상에 주고 결과물을 따로 만들게 하라.
- 새 에이전트에게 결과물들의 의미 있는 차이를 뽑게 해서 스펙에 반영하라.
결정 문서를 짧게 쌓아 저장소에 두기
- 중요하다고 확인된 결정만 몇 줄로 요약해 에이전트용 문서로 저장소에 커밋하라.
- 다음 에이전트 작업 때 이 문서를 먼저 읽게 하라.
배포 전에 섀도 모드와 E2E 테스트 붙이기
- 프로덕션 트래픽을 복제해 새 구현과 비교만 하는 섀도 모드를 먼저 켜라.
- 단위 테스트와 E2E 테스트를 함께 두고 롤아웃하라.

Try It

복사해서 바로 해보기

# Claude나 ChatGPT에 붙여넣기 (원문 방법의 간이 버전: 구현 간 차이 분석)

아래는 같은 스펙으로 서로 다른 에이전트가 만든 구현 {{구현A}}, {{구현B}}이다.

스펙:
{{스펙}}

구현 A:
{{구현A}}

구현 B:
{{구현B}}

지시:
1. 두 구현이 서로 다르게 결정한 지점을 모두 나열해라. 특히 스펙에 없는데 에이전트가 임의로 정한 것에 집중해라.
2. 각 차이마다 장단점과 장애 시 영향을 써라.
3. 내가 직접 정해야 할 결정 5개를 우선순위로 골라 질문 형태로 달라.

이어서 해 볼 것: 내 답변을 한두 줄 가이드 문서로 정리시키고, 다음 구현 요청에 그 문서를 붙여라.

Terminology

vibe-engineering에이전트에 통째로 맡기는 vibe-coding과 달리, 사람이 중요한 결정을 계속 내리며 에이전트의 범위를 조절하는 방식이다.

mechanical sympathy하위 계층이 실제로 어떻게 돌아가는지 알고 설계에 반영하는 감각이다. 자동차 엔진을 아는 레이서가 더 빠르게 모는 것과 비슷하다.

append-only 복제기존 데이터는 고치지 않고 뒤에만 계속 붙이며 복제하는 방식이다. 일기장에 줄만 이어 쓰는 것과 같다.

shadow mode새 시스템을 실제 응답에는 쓰지 않고 병렬로 돌려 결과만 비교하는 배포 방식이다.