You don't 3D print a house. You print your tools.
Vibe coding is to engineering what 3D printing is to making, and that's exactly why it...
vibe coding이 본격적인 소프트웨어 엔지니어링을 대체할 것인지를 두고 반복되는 논쟁이 있다. 양측 모두 질문을 잘못 설정하고 있다. 올바른 참조 대상은 데스크탑 3D 프린터다.
3D 프린팅이 10년 전 대중화됐을 때도 같은 두 진영이 등장했다. 한쪽은 자동차와 집을 온디맨드로 인쇄할 거라 예측했고, 다른 쪽은 장난감이라고 일축했다. 실제로 일어난 일은 달랐다. 3D 프린팅은 제조업을 대체하지 않았다. 맞춤형 공구 제작 비용을 붕괴시켰다. 워크숍의 특정 선반 코너를 위한 브래킷은 예전에는 하나의 프로젝트였다. 지금은 일요일 오후면 된다. 내력벽을 프린트하는 사람은 없다. 지그(jig), 픽스처(fixture), 교체용 손잡이, 당면한 작업에 맞춘 도구를 프린트한다.
vibe coding도 이 프레임으로 봐야 한다.
Photo by Jakub Zerdzicki on Pexels
비유의 정확한 의미 #
프로덕션 시스템 엔지니어링은 여전히 예전 방식으로 작동한다. 분산 트랜잭션, 보안 경계, 멀티 리전 페일오버, 규제 수준의 감사 추적 — 이 중 어느 것도 "vibe-able"해지지 않았다. 제약 조건은 동일하다: 정확성, 처리량, 관찰 가능성, 장애 반경. 그럴듯하게 보이는 잘못된 코드를 작성하는 비용이 0에 가까워졌기 때문에 오히려 기준이 더 높아졌다고도 볼 수 있다.
그러나 예전에는 '무인 지대(no-man's-land)'에 있던 소프트웨어 범주가 있다. 제품으로 패키징하기에는 너무 특수하고, 한 번 쓰기 위해 손으로 작성하기에는 너무 번거롭고, 그렇다고 완전히 건너뛰기에는 너무 중요한 것들이다. 안전 장치가 있어야 했던 내부 스크립트, 1년에 두 번 실행하는 CLI, 현재 스택의 정확한 형태에 묶인 마이그레이션 도구. 이것들이 소프트웨어의 브래킷과 지그였다 — 필요하고 가치 있지만, 예산이 없어서 거의 항상 건너뛰거나 형편없이 만들어졌다.
바로 여기서 vibe coding이 빛을 발한다. 일회성 문제에 산업 수준의 결과를 가져다주는 작업장 도구다. 맞춤형 고품질 도구 제작 비용이 단 한 번의 사용을 위해 만드는 것도 경제적으로 타당한 수준까지 떨어졌다.
실제 사례: Route 53 마이그레이션 #
Route 53 호스팅 존을 한 AWS 계정에서 다른 계정으로 이동해야 하는 상황을 맞닥뜨렸다. 계정 소유권 오류, 결제 통합 등 일반적인 엔터프라이즈 위생 문제였다. Route 53을 아는 사람에게는 간단한 문제다: 호스팅 존을 계정 간에 직접 이전할 수 없다. 소스에서 레코드를 나열하고, 대상에 새 존을 생성하고, 레코드를 재입력한 뒤, 레지스트라의 NS 위임을 전환한다.
각 단계에는 작은 함정이 있다. 에이펙스(apex) NS 레코드와 SOA 레코드는 AWS가 자동 생성하며 import 시 거부된다. ListResourceRecordSets의 페이지네이션은 단순 토큰이 아니라 name, type, set identifier 세 필드 커서를 사용한다. ChangeResourceRecordSets API는 호출당 변경 사항 1000개 상한이 있지만, 더 작은 배치로 나누면 오류 메시지가 훨씬 명확해진다. 프라이빗 존은 VPC 재연결이 필요하며 별도의 문제다. 어느 것도 어렵지는 않다. 그냥 날카로운 엣지들이고, 이 작업을 처음 하는 사람이라면 통계적으로 반드시 맞닥뜨리게 된다.
2023년 이전에는 선택지가 세 가지였다. 콘솔을 통해 수동으로 실행하는 것 — 느리고, 오타가 나기 쉽고, 감사 추적이 없다. AWS CLI 호출을 사용하는 일회성 Bash 스크립트를 작성하는 것 — 더 빠르지만 원하는 안전 점검을 추가할 때마다 한 시간이 더 걸린다. 적절한 내부 도구를 구축하는 것 — 매달 실행하는 팀이라면 정당화되지만, 일회성 작업에는 정당화하기 어렵다.
3D 프린터-for-tools 답변은 네 번째 선택지다: 도구를 구축하는 것이 더 이상 비싸지 않으니, 그냥 제대로 된 도구를 만들면 된다.
스펙 먼저, 그 다음 vibe #
vibe coding에 대해 사람들이 잘못 이해하는 부분이 있다. 모델이 빠르게 작성하기 때문에, 모호한 스펙은 매우 빠르게 많은 양의 자신감 있는 잘못된 코드를 만들어낸다. 규율이 타이핑에서 명세(specification)로 이동한다.
이 도구를 만들어낸 대화는 문제에서 시작했고, 구현은 그 뒤를 따랐다. 무엇을 하려는지를 먼저 기술했다: 레지스트라 이전을 별도의 관심사로 두고 계정 간에 호스팅 존을 안전하게 이동하는 것. 이 대화는 코드가 존재하기 전에 일련의 결정들을 강제했다.
범위: 퍼블릭 호스팅 존만. 프라이빗 존은 교차 계정 VPC 연결이 다른 실패 모드를 가진 다른 문제이고, v1에서 이를 혼용하면 설계가 희석되기 때문에 v2로 이동했다.
신뢰 모델: 오퍼레이터가 어떤 계정과 대화하는지 확인할 때까지 아무것도 변경하지 않는다. STS GetCallerIdentity가 시작 시 소스와 대상 자격 증명 모두에서 실행되고, 계정 ID와 호출자 ARN이 일반 텍스트로 표시되며, 오퍼레이터가 확인한 후 도구가 진행된다.
자격 증명 범위: 명명된 AWS 프로파일과 환경 변수만. 하드코딩된 키, 커스텀 설정 파일 없음. 자격 증명 체인은 SDK의 것이고, 도구는 소스를 선택하기만 한다.
되돌릴 수 있는 상태 유지: 도구는 되돌릴 수 없는 단계 직전에서 멈춘다. 존을 복제하고 기록한 다음 새 네임서버를 출력하고 멈춘다. 레지스트라의 NS 위임 업데이트는 의도적으로 수동 최종 단계로 남겨뒀다. 그것이 컷오버 순간이고, 인간이 그 레버를 당겨야 하기 때문이다.
실패 모드: 어떤 레코드가 건너뛰어지는지(에이펙스 NS, SOA), 어떤 배치 크기를 사용할지(1000이 아닌 100, 더 명확한 오류 메시지가 약간의 추가 호출 횟수보다 낫다), 페이지네이션 처리 방법(단순 "첫 페이지면 충분하겠지"가 아닌 마커 기반 전체 루프).
이 결정들은 TypeScript가 존재하기 전에 산문으로 만들어졌다. 모델은 그 산문을 코드로 변환하는 데 탁월하다. 이 결정들을 대신 내려주는 데는 훨씬 덜 신뢰할 만하다. 스펙 주도 vibe coding은 오퍼레이터가 스펙을 작성하고, 모델이 코드를 작성하고, 오퍼레이터가 충실도를 위해 둘 다 검토하는 것을 의미한다.
Route53 마이그레이션 도구 #
결과물은 AWS SDK v3를 사용한 TypeScript로 작성된 route53-aws-to-aws-transfer라는 CLI다. 구조는 스펙을 그대로 반영한다. 자격 증명 모듈은 명명된 프로파일이나 환경 변수를 해석하고 STS 신원 확인을 실행해 검증된 계정 ID와 호출자 ARN을 반환하여 CLI 레이어가 오퍼레이터에게 확인용으로 보여줄 수 있게 한다. 두 개의 독립적인 자격 증명 해석이 일어난다 — 소스 계정용 하나, 대상용 하나. 이를 혼용하는 것이 가장 흔한 오퍼레이터 실수이고 경계에서 예방하기 가장 쉽기 때문이다.
Route53 모듈은 마이그레이션에 실제로 필요한 SDK 호출들을 래핑한다: 퍼블릭 존으로 필터링된 페이지네이션 존 목록 조회, API가 요구하고 SDK가 추상화하지 않는 세 필드 커서를 사용하는 페이지네이션 레코드 셋 목록 조회, 고유한 호출자 레퍼런스를 사용한 존 생성, 그리고 나머지를 UPSERT 호출로 배치하기 전에 에이펙스 NS와 SOA 레코드를 명시적으로 제거하는 변경 셋 빌더.
오케스트레이션 모듈은 오퍼레이터의 확인된 입력에 대해 이것들을 순서대로 실행하고 구조화된 진행 상황을 내보낸다. CLI 레이어는 대화형 흐름에 @inquirer/prompts를, 계정 ID와 네임서버 목록 강조에 chalk를, 긴 페이지네이션 루프가 정지가 아닌 진행처럼 느껴지게 하는 스피너에 ora를 사용한다.
전체 도구는 약 400줄의 TypeScript다. 한 가지 일을 한다. 내부 플랫폼 팀 도구에서 기대할 만한 안전 장치와 함께. 아마 세 번 실행될 것이고, 그래도 괜찮다. 올바르게 구축하는 비용이 부주의하게 마이그레이션을 한 번 실행하는 비용보다 낮았기 때문이다.
엔지니어링을 운영하는 입장이라면 #
이것이 대표하는 경제적 변화는 개별적으로는 작지만 집계로는 크다. 예전에는 "제대로 구축할 가치가 없었던" 것들의 목록은 방대하다: 데이터 마이그레이션 스크립트, 일회성 ETL 작업, 내부 관리자 CLI, 환경 부트스트랩 도구, 감사 보고서 생성기, 임시 대시보드, 사용 중인 두 SaaS 제품 간의 일회성 통합. 모든 팀에는 수십 개씩 있다. 대부분은 없거나, 수동으로 처리되거나, 기본적으로 부채 형태로 존재한다: Bash, 테스트 없음, 로깅 없음, 누군가의 노트북에서 실행.
CTO나 기술 리드라면, 실질적인 질문은 한 번 구축하는 도구에 어떤 품질 기준을 적용할 것인지다. 저자 자신의 팀에 대한 답은 프로덕션 기준과 동일하다 — 규모 관련 사항을 제외하고. STS 검증, 구조화된 오류 처리, 기저 API가 허용하는 경우의 멱등성, 그리고 무음 실패 없음. 모델은 명세한다면 그 기준을 유지할 수 있다. 명세하지 않으면 절대 유지하지 못한다.
이것은 또한 vibe coding이 개인 취미를 넘어 팀 관행이 되는 지점이다. 아티팩트는 충분히 작아 제대로 검토할 수 있다. 스펙은 충분히 짧아 기록할 수 있다. 경제성은 단 한 명의 엔지니어가 단 한 번 사용할 도구에도 작동한다. 이제 '도구화할 수 없는 중간 지대'에 대한 변명이 없다. 그 범주는 이미 붕괴됐다.
앞으로 #
데스크탑 3D 프린팅이 작업장을 위해 한 일을 vibe coding이 소프트웨어를 위해 하고 있다. 프로덕션 엔지니어링은 여전히 프로덕션 엔지니어링이며, 그것이 요구하는 모든 규율을 포함한다. 소프트웨어가 산업화되면서 잃었던 레이어가 돌아온다: 눈앞의 작업을 위해 필요한 정확한 도구를, 전문가에게서도 존중받을 만한 품질 수준으로 만들 수 있는 능력. 오늘 아침 필요했던 Route 53 마이그레이션 도구를 vibe coding으로 만들어라. 대안은 도구 없이 마이그레이션을 실행하는 것이다. 작업장이 돌아왔다. 도구를 프린트하라.
이 글은 위 출처의 내용을 바탕으로 작성된 초안입니다. 원문의 의견과 정보를 그대로 전달하며, 별도의 견해를 포함하지 않습니다.