아내는 Dior를 원했다. 나는 대신 200만 줄짜리 데이터베이스를 바이브 코딩하려고 Claude Code에 600달러를 썼다.
아내와 저는 결혼한 지 10년이 되었고, 아내는 결혼기념일 선물로 Dior 가방을 원했습니다.
그런데 저는 아무것도 사지 않았습니다 — AI 실험에 완전히 몰두해 있었기 때문입니다 — 연휴 내내 서재에 틀어박혀 월 $200짜리 Claude Code 구독 3개를 동시에 돌리며, LLM이 200만 줄 규모의 C++ 분산 데이터베이스를 크로스 컴파일하도록 설득하려고 애쓰고 있었습니다.
그리고 그 뒤에 제게 무슨 일이 일어났는지는 아마 짐작하실 수 있을 겁니다. 😂
돌이켜보면, 이것은 최적의 리소스 배분이 아니었습니다.
그래서 저는 그 주말에 두 가지 교훈을 얻었습니다.
첫째: 아내의 말을 들어라. “Happy wife, happy life”는 단순한 구호가 아닙니다. 시스템 안정성 원칙입니다.
둘째: AI는 작고 범위가 잘 정해진 작업에서는 마법처럼 느껴집니다. 하지만 실제 분산 인프라를 맡기면 전혀 다르게 행동합니다.
이 글은 두 번째 교훈에 관한 것입니다.
배경
저는 글을 쓰는 현재 GitHub에서 42K+ stars를 보유한 가장 인기 있는 오픈소스 벡터 데이터베이스인 Milvus의 메인테이너이자 핵심 기여자입니다(~200만 줄의 C++, Go, Python). 이 시스템은 완전한 분산 시스템입니다. 프록시 노드, 쿼리 노드, 데이터 노드, 인덱스 노드가 모두 메시지 큐를 통해 조율됩니다. 제가 담당하는 영역은 스토리지와 인덱싱 계층입니다.
저는 몇 달 동안 Claude Code를 사용해 왔고, 진심으로 깊은 인상을 받았습니다. 토큰 비용 $20로 전체 CLI의 빠진 기능들을 모두 채워 넣었습니다. 하루 만에 쿼리 성능 핫패스를 5배 개선했는데, 그런 최적화는 제가 코드를 충분히 이해해서 손댈 수 있게 되기까지도 일주일은 걸릴 종류였습니다. 잠도 자지 않고 시간당 비용도 청구하지 않는 유능한 주니어 엔지니어가 있는 것처럼 느껴졌습니다.
그래서 저는 진짜 문제를 맡겨보기로 했습니다: 크로스 플랫폼 컴파일.
$600짜리 교훈
수년 동안 Milvus 팀의 그 누구도 크로스 플랫폼 컴파일을 건드리려 하지 않았습니다. 빌드 시스템은 Go, C++, Rust가 뒤섞여 있고, 그 위를 아무도 다시 들여다보고 싶어 하지 않는 수년간 누적된 Conan과 CMake 패치들이 간신히 붙들고 있습니다. Linux에서 실행되게 만드는 것만으로도 이미 고통스럽습니다. Windows와 최신 macOS에서 빌드하는 것은 너무나 악몽 같아서, 팀은 그것을 남의 문제로 취급했습니다.
저는 이제 Claude Code가 있으니 할 수 있다고 생각했습니다.
처음에는 제가 맞는 것처럼 보였습니다. Windows가 컴파일되었고, 저는 어려운 부분은 끝났다고 생각하며 패치를 제출했습니다.
그러자 Linux가 실패했습니다. Linux를 고치니 Mac이 실패했습니다. Mac을 고치니 GPU 환경이 실패했습니다. 모든 수정은 다른 플랫폼에서 두 개의 새로운 문제를 만들어냈고, 패치들은 점점 쌓여갔습니다. 결국 저는 Conan 설정, CMake 스크립트, C++ 호환성 shim, 그리고 제가 알아보지도 못하는 것들까지 건드리는 1000개 파일, 약 10만 줄짜리 패치를 들고 있었습니다.
미칠 것 같았던 부분은 버그가 아니라 루프였습니다. 저는 Claude에게 계속 말했습니다. "꼼수 같은 수정은 하지 마", "깔끔한 해결책을 줘." Claude는 매번 그대로 따랐고, 더 깔끔해 보이는 패치들을 생성했습니다. 그러면 그 깔끔한 패치가 다른 세 플랫폼을 깨뜨렸고, 사이클은 다시 시작되었습니다. 제 .claude/settings.local.json을 들여다보면, 수동으로 승인한 권한 규칙이 147개 있을 것입니다. 그 하나하나가 제가 "이번에는 될 거야"라고 생각했던 순간의 타임스탬프입니다.
저는 Max plan에 $600를 쓰고 휴가 전체를 태워버렸지만, 손에 남은 것은 git reset --hard 명령어 더미뿐이었습니다.
저는 터미널을 멍하니 바라보며, 이 모든 것이 그저 포장이 잘 된 과장 광고였던 건 아닌지 생각했습니다. 그러다 문제는 Claude가 아니라는 것을 깨달았습니다. 그것은 대학원생에게 연구 질문도 정해주지 않고 Nature에 논문을 실으라고 말하는 것과 같았습니다. 저는 "해결됨"이 실제로 무엇을 의미하는지 정의하지도 않은 채 문제를 넘겨준 것이었습니다.
실제로 효과가 있는 것
실패는 Claude의 지능 문제가 아니었습니다. 프로세스의 실패였습니다. 그래서 저는 다른 방식으로 처음부터 다시 시작했습니다.
코드보다 제약 조건이 먼저다. "Windows에서 컴파일되게 만들기"가 아니다. 실제 제약 조건을 명시적으로 적어두는 것이다: 모든 플랫폼에서 유닛 테스트를 통과하고, CI가 모든 곳에서 초록색이며, #ifdef 플랫폼 해킹이 없고, 망가진 의존성을 우회하는 shim도 없어야 한다. 이게 어려운 부분이다 — "완료"가 어떤 모습인지 알아야 하고, 그러려면 무언가를 건드리기 전에 신중하게 생각해야 하기 때문이다. 복잡한 인프라에서는 대부분의 일이 생각하는 데 있다.
코드가 아니라 테스트를 리뷰하라. 나는 테스트 케이스를 작성한다(또는 Claude가 생성하게 한다). 하지만 리뷰하는 것은 구현이 아니라 테스트다. 이 테스트가 Conan 레시피가 ARM에서 올바르게 해석되는지 확인하는가? Docker에서의 CMake 구성을 커버하는가? 나는 그것을 몇 분 만에 평가할 수 있다. 하지만 10,000줄짜리 크로스플랫폼 C++ 패치를 어떤 시간 안에든 자신 있게 리뷰할 수는 없다.
상향식으로, 한 번에 한 계층씩. Claude가 1000개 파일을 바꾸게 두지 마라. 먼저 의존성 버전을 고정하라. 그 제약 조건들이 검증되면 CMake 구성으로 올라가라. 그것이 안정되면 플랫폼별 코드로 올라가라. 각 계층은 위로 올라가기 전에 완전히 검증할 수 있을 만큼 작다.
나는 이 접근 방식으로 크로스플랫폼 빌드를 처음부터 다시 했다. 이틀. 수십 개의 커밋. 각각은 작고, 각각에는 대응되는 테스트가 있었다. #ifdef 해킹은 없었다 — 근본적인 수정은 Conan 레시피를 업데이트하고 서드파티 라이브러리 버전을 올리는 것이었고, 문제를 덮어씌우는 대신 실제 의존성 체인을 고치는 것이었다.
같은 작업. 완전히 다른 결과.
테스트에 대한 통찰은 그 자체로 하나의 요점이 될 가치가 있다: 성숙한 테스트 스위트를 가진 분산 시스템에서 테스트는 곧 명세다. 그 통합 테스트들이 통과한다면 — 내 첫 시도에서 빨간색으로 변했던 47개 전부가 — seal/flush 계약은 온전하고, WAL replay는 올바르며, query node는 여전히 손상 없이 segment를 mmap-load할 수 있다. 나는 그것을 알기 위해 C++를 읽을 필요가 없다.
나는 코드 리뷰를 멈췄다. 테스트 리뷰를 시작했다. 코드는 구현 세부사항이 되었다.
하드웨어를 투입하기
워크플로가 제대로 잡히자 새로운 병목이 나타났다: 나는 그저 앉아서 기다리고 있었다.
Claude Code 세션 하나가 200만 줄짜리 코드베이스를 씹어먹는 것은 빠르지 않다. 각 작업은 실제 시간으로 20~30분이 걸린다. 병목은 지능이 아니었다. 처리량이었다.
그래서 나는 아내에게 “AI agent”를 위한 GPU 달린 서버가 필요하다고 말했다. 그 대화는 당신이 예상하는 딱 그 정도로 흘러갔다. 어쨌든 나는 샀다 — 거기에 내 MacBook과 함께 쓸 Mac Mini도 추가로 샀다. 결국 내게는 세 대의 머신과 여섯 개의 터미널이 생겼고, 각각은 독립적인 Claude Code 세션을 실행하고 있었다.
이것이 가능하게 해주는 것은 git worktree다. 각 세션은 자기만의 작업, 브랜치, 작업 디렉터리를 가지며, 다른 세션들과 완전히 격리된다. 그리고 제약 조건 우선 접근 방식 덕분에 각 브랜치에는 자체 수용 기준이 있으므로, 병렬화는 아주 쉽게 안전해진다: 각 브랜치의 테스트가 독립적으로 통과한다면, 병합은 낮은 리스크다.
크로스플랫폼 빌드의 경우, 이는 한 세션이 Linux ARM Conan 의존성을 해결하고, 하나는 macOS CMake 구성을 고치며, 하나는 Windows MSVC 호환성을 처리한다는 뜻이었다. 모두 간섭 없이 동시에 실행되었다. 예전에는 플랫폼 사이를 오가며 직렬로 컨텍스트 스위칭하던 일이 머신들에 걸친 병렬 실행이 되었다.
이 패턴은 일상 업무에도 일반화된다. 어떤 날이든, 한 세션은 compaction scheduler를 리팩터링하고, 다른 세션은 HNSW search path를 최적화하며, 세 번째 세션은 streaming insert 엣지 케이스를 위한 통합 테스트를 작성한다. 나는 직속 부하들의 상태를 확인하는 매니저처럼 터미널 사이를 오간다. 다만 이 직속 부하들은 커피 브레이크가 필요 없고 sprint planning에 대한 의견도 없다.
진짜 교훈은 바이브 코딩 인프라는 재능에 묶이는 것이 아니라 컴퓨팅에 묶인다는 점이다. 제한 요인은 AI가 얼마나 똑똑한지가 아니라, 얼마나 많은 인스턴스를 병렬로 실행할 수 있는가다. Anthropic은 전체 C compiler를 만들기 위해 16개의 병렬 Claude 인스턴스를 사용했다. 그걸 보니 내 여섯 개 터미널은 소박하게 느껴졌다.
내가 계속 되돌아오게 되는 것
AI는 당신이 눈앞에 놓은 문제를 정확히 해결한다, 그 이상은 아니다. 문제를 잘못 정의하면, 잘못된 대상에 대한 완벽한 해답을 얻게 된다.
"macOS 15에서 컴파일됨" — 한 시간 만에 해결됐다. 하지만 그건 국소 최적해다. 실제 목표는 "해킹 없이 어디서나 컴파일됨"이었다. 이 둘은 서로 다른 문제다. AI가 그걸 알 방법은 없었다. 그건 전적으로 엔지니어의 책임이다.
AI로 자기 자신을 위해 무언가를 만드는 것은 놀라울 정도로 쉽다 — 당신은 자신의 머신, 자신의 엣지 케이스를 알고 있고, "내 환경에서는 동작함"은 달성 가능한 최적화 목표다. 모든 사용자, 모든 플랫폼, 모든 환경에서 동작하는 인프라를 만드는 것은 근본적으로 다르다. 그 간극이 바로 엔지니어링이 여전히 존재하는 곳이다. 인프라 소프트웨어에서 그 간극은 엄청나다.
우리 프로덕션 시스템에서 가장 어려웠던 버그들 — 머지 후 되돌려야 했던 것들 — 은 우리가 시도한 어떤 AI 코드 리뷰 방식으로도 잡히지 않았다. 버그들은 문법적으로는 올바랐다. 문제는 개발자의 암묵적인 가정에 있었고, 그것은 diff에는 보이지 않았으며 주변 코드에도 없었다. 시스템의 동작은 세 가지 다른 컴포넌트가 어떻게 조율되어야 하는지에 대한 멘탈 모델을 가지고 있을 때에만 이해됐다 — 그 모델은 한 개발자의 머릿속에만 존재했고, 어디에도 문서화되어 있지 않았다.
그런 것들은 여전히 시스템을 충분히 이해해서 어떤 질문을 던져야 하는지 아는 인간을 필요로 한다.
세 개의 $200 요금제와 잃어버린 휴가는 내가 한 최고의 투자였다. AI를 사용하는 법을 가르쳐줘서가 아니다. AI를 어떻게 사용하지 말아야 하는지를 가르쳐줬기 때문이다.
도구들은 진짜로 좋다. 항상 빠져 있던 조각은 그 도구들을 둘러싼 workflow였다. 코드 전에 테스트, 테스트 전에 제약 조건, 그리고 그 모든 것을 병렬로 돌릴 수 있을 만큼의 하드웨어. 그게 전부다.
아직 해결되지 않은 문제들
모든 것이 지난 뒤에도 — 실패한 패치, reset 명령어들, 여섯 개의 병렬 터미널 — 해결하기 가장 어려운 문제는 여전히 인간의 문제다.
현재 내겐 두 가지 골칫거리가 있고, 둘 다 깔끔한 해결책이 없다.
첫 번째: 내 아내. 그녀는 합리적인 기대를 가지고 휴가를 시작했다. 그리고 내가 내 인생을 git reset --hard하는 모습을 보며 떠났다. Dior 가방 예산은 서버 요금이 되었다. 이해할 만하게도, 그녀는 내 크로스 플랫폼 빌드 성과에 감명받지 않았다. 나는 아직 "기념일을 분산 시스템 작업에 써버린 것에 대해 사과하는 방법"에 대한 workflow를 찾지 못했다. Claude Code는 여기서는 도움이 되지 않는다. 물어보긴 했다. 꽃과 손편지를 제안했다. 더 구체적으로 말해보라고 했다. 그러자 C++ 개발자의 목소리로 쓴 진심 어린 편지 12가지 변형을 생성했다. 그중 어느 것도 먹히지 않았다.
휴가 내내 vibe-coding을 하면서 관계를 유지하는 문제를 해결한 사람이 있다면, workflow 제안을 매우 환영한다. 😂
두 번째: 이것을 나를 넘어 확장하는 방법. 위의 모든 것 — 제약 조건 우선 접근, git worktree 병렬화, 테스트 우선 리뷰 규율 — 은 현재 내 머릿속과 로컬 설정 안에 있다. 이것을 팀의 일상 workflow로 가져오는 것은 어떤 크로스 플랫폼 빌드보다 어렵다.
이것은 부분적으로는 도구의 문제다. 하지만 대부분은 사람의 문제다. 이런 종류의 workflow는 사물이 어떻게 동작하는지 알아내는 것을 진심으로 즐기는 엔지니어를 필요로 한다 — 실제로 테스트를 먼저 작성하고, 깨끗하고 잘 정의된 제약 조건에서 만족을 느끼며, "그냥 통과하게 만들기"로 지름길을 택하지 않는 사람들. 그런 조합은 생각보다 드물다.
그래서 맞다 — 우리는 채용 중이다.
인프라 vibe coding에 관한 글을 읽고 내가 무엇을 잘못했는지에 대해 즉시 강한 의견을 떠올리는 종류의 엔지니어라면, 바로 당신이 내가 이야기하고 싶은 사람이다.
Milvus는 진정으로 어려운 분산 시스템 문제다: storage engines, indexing pipelines, compaction, replication, failure recovery — 모두 현실 세계의 프로덕션 부하 아래에서. 우리는 데모를 만들고 있는 것이 아니다. 우리는 사람들이 의존하는 인프라를 만들고 있다.
그 수준의 문제를 해결하는 것이 흥미롭게 들린다면, 우리와 함께 만들자.
그리고 기념일 회복 계획은 내가 맡겠다.
저희 채용 공고를 확인하시거나 LinkedIn에서 저에게 직접 연락하실 수 있습니다.
그리고 이 글의 어떤 부분에 동의하지 않으신다면, 오히려 더 좋습니다 — 기꺼이 여러분과 논의하겠습니다.
저희 Slack 커뮤니티에 참여하시거나 Milvus Office Hours 세션을 예약해 주세요 — 분산 시스템, AI 인프라, 또는 저희가 틀렸다고 생각하시는 부분에 대해 언제든 이야기 나누는 것을 환영합니다.
계속 읽기
Zilliz Cloud BYOC Now Available Across AWS, GCP, and Azure
Zilliz Cloud BYOC is now generally available on all three major clouds. Deploy fully managed vector search in your own AWS, GCP, or Azure account — your data never leaves your VPC.
How to Improve Retrieval Quality for Japanese Text with Sudachi, Milvus/Zilliz, and AWS Bedrock
Learn how Sudachi normalization and Milvus/Zilliz hybrid search improve Japanese RAG accuracy with BM25 + vector fusion, AWS Bedrock embeddings, and practical code examples.
Why Not All VectorDBs Are Agent-Ready
Explore why choosing the right vector database is critical for scaling AI agents, and why traditional solutions fall short in production.