Claude는 컴파일러가 아니다: 바이브 엔지니어링의 부상
Claude는 컴파일러가 아니다: 바이브 엔지니어링의 부상
컴파일러가 아닌 수직 통합 리소스로서의 LLM
Claude와 같은 대형 언어 모델(LLM)은 고수준 사양을 저수준 구현으로 단순히 변환하는 컴파일러가 아니다. 대신, 고수준 비즈니스 전략·제품 기획부터 아키텍처·머신 코드에 이르기까지 전체 소프트웨어 스택을 가로질러 작동할 수 있는 수직 통합 리소스 역할을 한다.
전통적인 컴파일러가 레지스터 할당이나 인라인화와 같은 저수준 결정을 엔지니어가 할 필요성을 없애 주는 반면, LLM은 엔지니어가 스택의 모든 계층에서 동시에 결정을 빠르게 반복(iterate)할 수 있게 해준다. 이 변화는 엔지니어의 역할을 "코드 작성"에서 **"바이브 엔지니어링"**으로 옮긴다: 에이전트를 일련의 아키텍처·전략적 결정으로 안내하여 프로덕션 준비가 된 시스템에 도달하도록 하는 과정이다.
사례 연구: 분산 DNS 서버 구축
수직 통합의 힘을 보여주기 위해 Bryan Mikaelian은 exe.dev용 지리적으로 분산된 일관성 있는 DNS 서버 개발 과정을 설명한다. 이 프로젝트는 오리건 주 외부 사용자에 대한 지연 시간을 줄이고 가동 시간 복원력을 높이는 것을 목표로 했다.
개발 프로세스
코드를 직접 작성하는 대신, LLM과의 고주파 피드백 루프를 활용했다:
- 연구 및 계획: LLM을 사용해 표준 분산 DNS 설계 조사, 보안 취약점 탐색, 대체 구현 전략(예: AXFR/IXFR) 평가를 수행했다.
- 반복 프로토타이핑: 여러 에이전트 루프를 동시에 프롬프트하여 전체 시스템(테스트와 적대적 코드 리뷰 포함)을 구축했다.
- 차등 사양 분석: 서로 다른 에이전트(예: Claude vs. Codex)의 구현을 비교함으로써 에이전트가 암묵적으로 만든 핵심 결정을 엔지니어가 식별했다. 이 "차등 사양 분석"을 통해 시스템 동작에 명시적 코딩이 필요한 부분을 밝혀냈다.
- 결정 코딩: 엔지니어는 얻은 인사이트를 "흉터 문서"(scar‑tissue document)라는 간결한 가이드 형태로 정리해, 고수준 목표부터 동시 캐시용 구체적 데이터 타입까지 모든 계층의 중요한 결정을 코딩했다.
기술 구현 상세: 데이터베이스 롤백 처리
차등 분석 과정에서 중요한 결정이 하나 도출되었다: 복제의 "append‑only" 계약을 깨는 데이터베이스 롤백을 어떻게 처리할 것인가. 최종 설계는 모든 행에 "timeline" 필드를 추가했다. 각 동기화 요청에는 엣지 서버의 timeline 값이 포함되며, 값이 일치하지 않을 경우 시스템은 전체 클린 재동기화를 트리거한다.
바이브 엔지니어링 vs. 바이브 코딩
"바이브 코딩"과 "바이브 엔지니어링" 사이에는 근본적인 차이가 있다:
- 바이브 코딩: 작업을 에이전트에 넘겨 모든 결정을 에이전트가 내리게 하여 아이디어를 실현한다. 이는 종종 신뢰성이 낮고 감독이 부족하다.
- 바이브 엔지니어링: LLM을 활용해 스택의 다양한 레벨에서 결정을 빠르게 내릴 수 있게 한다. 엔지니어는 여전히 주요 의사결정자이며, 에이전트를 사용해 설계 공간을 탐색하고 실제로 중요한 결정을 식별한다.
이 모델에서는 엔지니어가 "실제 코드의 극히 일부만" 읽을 수 있지만, 아키텍처 결정을 직접 이끌었기 때문에 시스템에 대한 깊은 이해를 유지하고 시스템 동작을 논리적으로 추론할 수 있다.
커뮤니티 관점 및 반론
Hacker News에서 엔지니어들 간의 토론은 이 접근법에 대한 여러 중요한 우려를 제기했다:
암묵적 결정의 위험
일부 비평가들은 LLM에 결정을 위임하는 것이 위험할 수 있다고 주장한다. @trjordan이 지적한 바와 같이, 에이전트가 "결정 배출"(decision exhaust)이라 불리는, 요청받지 않아도 스스로 내리는 결정들이 숨겨진 실패를 초래할 수 있다. 반면 @cadamsdotcom은 요구사항이 이해되면 확률적 시스템에 맡기기보다 결정론적 코드로 명시화해야 한다고 주장한다.
결정론성 격차
컴파일러는 결정론적이지만 LLM은 확률적이다. @davidpapermill과 @armchairhacker는 동일 프롬프트에 대해 LLM이 서로 다른 결과를 낼 수 있기 때문에 컴파일러처럼 신뢰할 수 없다고 지적한다. 올바름을 보장하려면 엄격한 테스트 스위트나 전면적인 인간 검토가 필요하며, 이는 AI‑지원 개발의 속도 이점을 상쇄할 수 있다.
"코드를 읽지 말라" 논쟁
생성된 코드를 거의 읽지 않는다는 의견은 큰 반발을 일으켰다. @xav_authentique와 @borzi는 코드를 프로덕션에 배포하기 전에 읽지 않는 것은 위험한 관행이며, 마이크로서비스의 무분별한 도입과 같은 과거 트렌드를 재현한다고 경고한다.
DNS 아키텍처 비판
기술적인 관점에서 일부 사용자는 DNS 서버를 새로 만드는 필요성을 의문시했다. @nunez는 기존 도구인 dnsmasq나 unbound가 문제를 해결했을 수 있다고 제안했고, @torginus는 ISP와 기업 VPN이 제공하는 중간 DNS 캐시가 서버 측 전파 속도를 근본적으로 제한하므로 구현 방식과 관계없이 해결하기 어려운 문제라고 지적했다.
요약
Bryan Mikaelian은 Claude와 같은 LLM이 자연어를 코드로 변환하는 단순 컴파일러가 아니라, 엔지니어가 전체 소프트웨어 스택에 걸쳐 고수준 전략·아키텍처 결정을 내릴 수 있게 하는 수직 통합 리소스라고 주장한다.
제목
Claude는 컴파일러가 아니다: 바이브 엔지니어링의 부상