1998년, 에릭 S. 레이먼드는 오픈소스 소프트웨어 개발의 근본적인 텍스트인 “성당과 시장”-을 발표했다. 그는 이 글에서 소프트웨어를 만드는 두 가지 방식을 상세히 설명했다:

• 성당 모델-은 철저히 계획되고, 폐쇄적이며, 소수의 개발자 팀이 관리한다.
• 시장 모델-은 개방적이고, 투명하며, 커뮤니티 중심으로 운영된다.

시장 모델은 인터넷 덕분에 가능해졌다. 인터넷은 분산된 협업과 배포를 가능하게 했고, 더 많은 사람들이 코드에 기여하고 피드백을 나눌 수 있게 되어 더 좋고 안전한 소프트웨어가 탄생했다. 레이먼드는 “눈이 충분히 많다면, 모든 버그는 얕아진다”고 썼으며, 이것이 바로 ‘리누스의 법칙’이다.

“성당과 시장”에 담긴 이 아이디어들은 이후 25년간의 오픈소스 혁신과 전성기를 이끄는 데 일조했다.

그런데 인터넷이 소통의 비용을 낮춰 시장 모델을 탄생시켰듯, AI는 코드의 비용을 낮추며 기이하고, 방대하고, 뒤죽박죽 이어 붙인 소프트웨어로 가득한 새로운 시대를 열고 있다.

세 번째 모델을 소개한다: 윈체스터 미스터리 하우스.

컴퓨터 역사 박물관-에서 남동쪽으로 10마일도 채 되지 않는 곳에 ‘윈체스터 미스터리 하우스’라는 건축학적 기이함-이 자리하고 있다.

남편과 시어머니가 세상을 떠난 후, 사라 윈체스터는 막대한 재산을 손에 쥐게 되었다. ‘윈체스터 연발 총기 회사’의 지분과 그로부터 쏟아지는 배당금 덕분에 사라는 편안한 생활을 누리는 것은 물론, 자신이 원하는 열정을 마음껏 좇을 수 있었다. 그 열정은 바로 건축이었다.¹

사라가 저택을 지은 것은 유령을 들이기 위해서가 아니었다². 그녀는 건축이 좋았기 때문에 지었다. 자격증도, 정식 교육도 없이, 심지어 여성에게(아무리 부유한 여성이라도) 건축을 직업으로 삼을 길이 없던 시대에, 사라는 자신의 집에 온 힘을 쏟았다. 자격증의 부재는 열정과 사실상 무한한 자금으로 메워나갔다.

사라는 자신이 원하는 것을 지었다. “전성기에 이 저택은 약 500개의 방을 갖추고 있었다.” 오늘날에는 약 160개의 방, 2,000개의 문, 10,000개의 창문, 47개의 계단, 47개의 벽난로, 13개의 욕실, 6개의 주방이 남아 있다. 벽과 천장은 조각된 목재로 장식되어 있고, 스테인드글라스가 곳곳에 가득하다. 공사는 계획되고, 완성되고, 중단되고, 허물어지고, 다시 지어지기를 반복했다.

그것은 결코 목적 없는 작업이 아니었다. 오히려 곳곳에 실용적인 혁신이 담겨 있었다. 버튼식 가스 조명, 초기 형태의 인터폰 시스템, 증기 난방, 실내 정원이 그 예다. 오늘날 관람객들을 신기하게 만드는 특이한 구조들도 대부분은 사라의 건강을 위한 실용적인 배려(매우 낮은 단차의 계단)이거나, 지금은 쓰이지 않는 기능적 설계(온실의 과잉 수분을 빼내는 트랩 도어)이거나, 1906년 지진 피해를 급히 보수한 흔적들이다.

윈체스터는 1922년에 세상을 떠났다. 그로부터 9개월 후, 저택은 관광 명소가 되었다.

오늘날, 많은 프로그래머들이 바로 사라 윈체스터다.

Claude Code의 공개된 GitHub 활동 그래프

우리는 사라 윈체스터만큼 부유하지 않지만, 코드가 이토록 저렴해진 지금, 그럴 필요도 없다.

조던 알버츠는 최근 이를 잘 보여줬다. 그는 클로드 코드가 기여한 것으로 표시된 공개 깃허브 커밋 데이터를 수집하고 시각화-했다. 위 차트가 바로 그의 데이터로, 클로드는 3월까지도 가속을 이어가는 것처럼 보인다³.

다만 개인별 사용량을 파악하기는 어렵기 때문에, 나는 대리 지표를 찾아 나섰고, 아래 차트에서 답을 찾았다:

클로드 코드 커밋당 평균 순 추가 라인 수

오퍼스 4.5와 에이전트 팀 기능을 가능하게 한 최근 작업 이후, 클로드가 커밋당 추가하는 평균 순 라인 수-는 이제 커밋당 1,000줄-로 안정적이고 꾸준하게 유지되고 있다⁴.

커밋당 1,000줄의 코드는 인간 프로그래머가 하루에 작성하는 양보다 약 2자릿수가 더 많다 (역주: 약 100배).

인간의 기준치를 검색해보면, 프레드 브룩스의 《맨먼스 미신》을 인용하며 뛰어난 엔지니어도 하루에 누적 10줄 정도의 코드-를 작성한다고 주장하는 글들을 많이 찾을 수 있다⁵. 더 깊이 찾아보면 10줄보다 높은 수치도 나오지만, 일반적으로 100줄을 넘지는 않는다.

나는 간단한 계산을 해봤다. 레디스는 10만 줄의 코드로 이루어져 있는데, 내가 10년 동안 그중 최소 7만 줄을 작성했다. 나는 주 5일을 넘겨 일한 적이 없고 매년 한 달씩 휴가를 떠나니, 한 달에 22일씩 11개월을 일한다고 가정하면:

70000 ÷ (22 × 11 × 10) ≈ 하루 29줄

10줄과 크게 다르지 않다. 하루에 300~500줄을 작성하는 날도 있지만, 많은 작업이 코드를 다시 짜고 버그를 고치는 데 들어갔을 것이고, 그러면 수년에 걸쳐 같은 줄을 반복해서 다시 작성한 셈이다. 그렇더라도 이 점은 감안해야 한다고 생각한다. 그러고 보면 《맨먼스 미신》은 꽤나 정확한 책이다.

이 댓글이 달린 지 6년 후, (현재) 클로드는 커밋당 1,000줄의 코드를 Push하고 있다.

그렇다면 이 저렴한 코드로 우리는 무엇을 하는가?

안타깝게도, 다른 모든 것들은 비용도, 속도도 거의 그대로다. 피드백은 저렴해지지 않았다. 시장 모델에서 소프트웨어 개발을 이끌었던 “눈들”은 AI의 속도를 따라잡지 못하고 있다.

AI가 생성하는 코드의 속도에 맞춰 움직일 수 있는 피드백의 원천은 단 하나뿐이다: 바로 자기 자신. 프롬프트를 입력하는 것도 당신이고, 결과물을 검토하는 것도 당신이다. 테스터를 모집하거나, 설문조사를 돌리거나, 디자인 파트너를 관리할 필요가 없다. 그냥 원하는 것을 만들고, 만든 것을 직접 쓰면 된다.

그리고 실제로 많은 개발자들이 저렴한 코드로 바로 그런 일을 하고 있다: 자신의 열정과 취향, 그리고 필요에 이끌려, 자기 자신을 위한 독특한 도구들을 만들어내고 있다.

어디서 들어본 이야기 같지 않은가?

스티브 예기의 개스타운-은 윈체스터 미스터리 하우스다. 믿을 수 없을 만큼 독특하고 방대하며, 은유(metaphors)와 임시방편(hacks)으로 가득하다. 스티브에게는 완벽한 도구다.

제프리 에마뉴엘의 에이전트 플라이휠-도 윈체스터 미스터리 하우스다. 토큰맥서-들 중 상당수는 자신의 의존성을 러스트로 다시 짜야겠다고 결심하는데, 제프도 그중 하나다. 그의 “프랑켄수트”에는 SQLite, Node, btrfs, Redis, Pandas, NumPy, JAX, Torch의 러스트 재작성본이 포함되어 있다.

필립 제일리거는 지난주 이 패턴을 포착하며 이렇게 썼다: “모두가 소프트웨어 공장을 짓고 있다.” 그런데 이는 소프트웨어를 넘어선다. 개리 탄의 개인 AI 위원회 gstack-은 대부분 마크다운으로 지어진 윈체스터 미스터리 하우스다.

어디를 봐도 윈체스터 미스터리 하우스가 있다.

각각의 윈체스터 미스터리 하우스는 독특하다. 철저히 개인화되어 있다. 코딩 에이전트와 사용자 사이의 촘촘한 피드백 루프는 개발자의 욕망을 그대로 반영한 소프트웨어를 만들어낸다. 대개 문서화가 되어 있지 않다. 외부인에게는 난해하기 그지없다.

윈체스터 미스터리 하우스는 방대하다. 개발자의 필요에 이끌려 이 도구들은 끊임없이 영역을 넓혀가며, 새로운 함수와 새로운 저장소의 형태로 계속해서 영토를 합병한다. 작업은 거의 항상 추가적이다. 필요할 때 코드가 추가되고, 버그는 그 자리에서 패치되며, 수많은 부속물들이 그대로 남는다. 코드가 공짜인데 굳이 쳐낼 이유가 없다.

그리고 윈체스터 미스터리 하우스를 짓는 일은 즐거워야 한다. 코딩 에이전트는 모든 것을 사이드퀘스트로 만들고, 우리는 기꺼이 그 여정에 합류한다. 완벽한 워크플로를 만드는 일은 많은 개발자들의 열정이기에, 우리는 계속해서 밀어붙인다.

윈체스터 미스터리 하우스는 독특하고, 방대하고, 재미있다. 그런데 이것이 우리가 시장 모델을 버리고 있다는 뜻일까?

우리 모두가 자신의 미스터리 하우스를 돌보는 데 빠져들면 어떻게 될까? 자유 시간을 오로지 자신만을 위한 도구를 만드는 데 쏟다 보면, 공유 프로젝트에는 손을 놓게 될까? 시장을 버리게 될까?

아마 그렇지는 않을 것이다. 지금 시장은 북적이고 있다 (packed). 다만 좋은 의미에서는 아니다.

코드가 저렴해지면서, 사람들은 이력서를 채우거나 자신이 원하는 기능을 구현하려는 목적으로 에이전트가 작성한 기여물을 오픈소스 저장소에 마구잡이로 쏟아붓고 있다. 다니엘 스텐버그는 형편없는 제출물이 홍수처럼 밀려들어 리뷰어의 여력을 갉아먹자, curl의 버그 바운티를 종료-했다. 사태가 너무 심각해진 나머지, 깃허브는 최근 풀 리퀘스트 기여를 비활성화하는 기능-을 추가했다.

체감상으로는 좋은 기여도 늘고 있는 것 같다. 다만 슬롭(slop, 쓰레기 같은 기여물)에 묻혀버릴 뿐이다. 참고로, curl 커밋 수는 에이전트 시대에 들어 극적으로 증가-했다. 그리고 사람들은 자신이 만든 것을 공유하고 있다. 덤키의 최근 분석-에 따르면, 지난 분기에 패키지와 저장소 수가 모두 증가하고 있다.

코드가 이토록 저렴한 지금, 미스터리 하우스와 시장 모두를 위한 여력은 충분하다. 새로운 과제는 밀려드는 홍수를 관리할 시스템과 프로세스를 만드는 것이다. 소프트웨어 안에서 버그를 찾을 눈-이 필요한 게 아니라, 버그가 소프트웨어에 닿기 전-에 잡아낼 눈이 필요하다.

여러 면에서 이것은 시장 모델 시대의 정반대다. 인터넷은 피드백과 공동 조율을 더 빠르고, 더 쉽고, 더 저렴하게 만들었다. 시장 모델은 피드백의 처리량은 높지만(많은 눈들), 수정의 지연 시간은 상대적으로 길다(이슈 제기, 토론, PR 제출, 리뷰 대기 등).

반면 코딩 에이전트는 구현을 빠르게 만들지만, 피드백과 조율은 그대로다. 윈체스터 미스터리 하우스 모델은 피드백 루프를 한 사람으로 압축함으로써 이 문제를 우회한다. 지연 시간은 거의 제로에 가깝지만, 처리량은 오직 자기 자신뿐이다. 공동 작업을 근간으로 하는 시장 모델은 이 방법을 채택할 수 없다. 시장에서의 코딩 에이전트는 혼란을 만들어낸다. 인간의 속도에 맞춰 구축된 조율 인프라에 기계 속도의 구현이 충돌하는 것이다. 바로 그래서 메인테이너들은 익사할 것 같은 기분을 느끼는 것이다.

우리에게는 새로운 도구, 새로운 기술, 새로운 관습이 필요하다.

코딩 에이전트는 코드의 비용을 너무나 극적으로 낮춰버렸고, 우리는 소프트웨어 개발의 새로운 시대로 접어들고 있다. 인터넷이 오픈소스 소프트웨어를 촉발한 이후 이 정도 규모의 변화는 처음이다. 변화는 빠르게 찾아왔고, 속도를 늦출 기미도 없다. 그러나 윈체스터 미스터리 하우스 프레임워크를 되돌아보면, 몇 가지 교훈을 얻을 수 있다고 생각한다.