테스트 코드가 새로운 해자(Moat)가 되는 시대
(saewitz.com)-
성공의 역설: 프로젝트가 성장할수록 하위 호환성과 거대한 코드베이스(The Ship of Theseus)라는 짐을 지게 됩니다. 반면 경쟁자는 기존 프로젝트의 API 규격과 문서, 테스트 코드를 AI에 학습시켜 핵심 가치만 추출한 '더 가볍고 현대적인 버전'을 순식간에 만들어낼 수 있습니다.
-
Cloudflare vs Vercel 사례: Cloudflare는 Vercel이 수년간 쌓아온 Next.js의 방대한 문서와 테스트 스위트를 활용해, 단 일주일 만에 Vite 기반의 슬림한 Next.js 호환 런타임을 구축했습니다. (현재 미국 정부 사이트인 cio.gov에도 적용됨)
-
테스트 코드가 곧 자산: 과거에는 코드 자체가 중요했지만, 이제는 '소프트웨어 계약(Contract)'과 '테스트 케이스'가 가장 비싼 자산이 되었습니다. 이를 공개하는 것은 경쟁자가 내 서비스를 그대로 복제해 갈 수 있는 정밀한 설계도를 제공하는 것과 같습니다.
-
SQLite의 선견지명: SQLite는 코드는 공개하되, 소스 코드의 590배에 달하는 방대한 테스트 스위트(9,200만 라인)는 비공개로 유지합니다. 이것이 그들이 오픈소스 생태계를 유지하면서도 상업적 방어력을 갖추는 '해자'가 되었습니다.
-
결론: AI 시대의 상업적 오픈소스 기업들은 '완전한 이타주의(오픈 소스)'와 '비즈니스 생존' 사이에서 결단을 내려야 할 시점에 직면했습니다. 앞으로 많은 프로젝트가 SQLite처럼 테스트 코드를 비공개로 전환하며 독자적인 기술 장벽을 쌓을 것으로 보입니다.
이 관점대로라면, 어쩌면 ADR(Architecture Decision Records)이나 CIR(Change Intent Records) 같은 문서가 코드 그 자체보다도 더 귀하게 대접받을지도 모르겠습니다.
완전 비개발자인데... AI만지는 재미로 코딩 좀 시켜보는데 시키지도 않은, 테스트 코드 잔뜩 만들어서 보관하더니 이런 이유가 있던거군요.
이거 도대체 왜 필요하냐고 물으니 자기가 코드만들때 필요하다며 지우지 말라고하더군요.
SQLite의 접근이 정말 인상적이네요. 코드 590배에 달하는 테스트 스위트를 비공개로 유지한다는 건, 결국 "소프트웨어의 진짜 가치는 동작 명세에 있다"는 뜻이니까요.
실제로 요즘 AI 코딩 도구로 프로젝트를 만들어보면, 기존 프로젝트의 README + API 문서 + 테스트 코드만 있으면 핵심 기능을 놀라울 정도로 빠르게 복제할 수 있습니다. 직접 7개 프로젝트를 운영하면서 느낀 건데, 테스트가 잘 되어있는 프로젝트일수록 역설적으로 복제하기도 쉽더라고요.
다만 Cloudflare vs Vercel 사례에서 간과된 부분이 있는데, "복제"와 "운영"은 완전히 다른 문제입니다. Next.js의 엣지 케이스, 플러그인 생태계, 커뮤니티 의존성까지 재현하려면 테스트 코드만으로는 부족하죠. 결국 해자는 테스트 코드 + 커뮤니티 + 운영 노하우의 조합이 아닐까 싶습니다.
솔로 개발자로 7개 프로젝트를 운영하고 있는데, 이 글이 뼈 아프게 와닿습니다.
AI 코딩 도구 덕에 초기 개발 속도는 미친 듯이 빨라졌지만, 테스트 없이 빠르게 쌓은 코드는 결국 리팩토링 지옥이 되더군요. 특히 여러 서비스를 동시에 운영하다 보면, 테스트가 없는 프로젝트는 기능 하나 건드릴 때마다 다른 곳이 터질까 두려워서 손대기가 무섭습니다.
"테스트 = 해자"라는 비유가 정확합니다. 경쟁자가 코드를 복사할 수는 있어도, 수천 개의 엣지 케이스를 커버하는 테스트 스위트까지 복제하기는 어렵죠. 특히 AI가 코드 생성은 잘 하지만, 의미 있는 테스트 시나리오를 만드는 건 아직 사람의 도메인 지식이 필요한 영역이라는 점에서 더 그렇습니다.
근데 분야에 따라서 테스트 코드가 커버리지가 거의 없는 경우도 있어서, 고민되긴 하더군요. 그쪽은 아직 다른 분야에 비해서 좋은 코드를 잘 못만드는 것 같기도 하고요.
제가 일하는 분야도 그 정도로 극단적인 정도의 분야는 아니긴 한데, AI 분야에서 연구 및 개발하고 있습니다.
일반적으로 많이 사용하는 프레임 워크 외에도 실제 모델을 디플로이하는 타겟 환경이 학습했던 환경과 다른 경우도 있고.
특정 오퍼레이션들이 지원하지 않는다거나 그래서 커스텀 오퍼레이션을 플랫폼별로 만들어야 하는 경우도 있습니다. 이 경우 개발한 환경에서 바로 테스트할 수가 없는 경우도 많습니다.
모델을 직접 모델링하는 경우도 있는데, 특정 데이터를 가지고 테스트 코드를 짤 수 있지만, 데이터셋에 따라서 확률적으로 값들이 변화하고, 특정 시점에 값들이 폭발하거나 하는 현상은 테스트 코드로 커버하기 어렵더라고요.
아마 저보다 더 테스트가 어려운 환경들이 꽤 있지 않을까 싶긴합니다.
단순히 제 생각이지만, Notebook을 쓰는 경우가 많거나 확률적으로 답이 나오는 AI 분야나..게임 Client 분야 등이지 않을까 싶습니다.
이거 저도 주변에 많이 이야기하는 건데, 결국은 나중에 모든 코드를 다 살펴보기 어려울테니 정말 중요한 로직은 무조건 테스트를 하지 않으면 큰일날 것이라고 생각합니다.
글 하단에도 추가되었는데 tldaw도 테스트를 비공개로 돌린다는 얘기가 있었습니다(농담이었다네요)
https://github.com/tldraw/tldraw/issues/8082
SQLite는 어떻게 테스트되는가 를 보시면
SQlite는 완전 공개지만, 소스코드 보다 590배 많은 테스트 코드가 있고 이건 완전 비공개입니다
100% 분기 커버리지에 수백만건의 테스트 케이스가 있고, 10억개가 넘는 변이 테스트를 수행.
"소스보다 테스트"라는 핵심은 정말 맞는 말 같습니다. 다만 오픈 테스트는 하지 않고 오픈 소스만 하는 전략이 유효할지는 모르겠습니다. 소스로부터 테스트항목을 뽑아내는 것 역시 잘할 것 같은데..
Cloudflare, AI로 Next.js를 1주일 만에 Vite로 재구현한 vinext 공개
이 글과 연계되는 것 같습니다. 오픈소스 할때, 테스트 코드 공개에 있어서 이제 보수적이 될 수도 있을 것 같네요.