자유 및 오픈 소스 소프트웨어 (FOSS)는 AI 개발을 위한 치트 코드입니다. 30년 동안의 이상주의도 이를 주류로 끌어올리지 못했지만, 코딩 에이전트(coding agents)의 1년이 이를 해낼지도 모릅니다.

30년 동안 오픈 소스의 홍보는 다음과 같았습니다: 기술적으로 훌륭하고, 영원히 무료이며, 당신이 완전히 소유한다는 것입니다. 이에 대한 기업 IT 부서의 반응은 이랬습니다:

Eric Raymond은 The Cathedral and the Bazaar 1에서 이 이데올로기적 근거를 가장 명확하게 제시했습니다. 이 에세이는 분산형 오픈 소스 (Open-source) 개발에 지적 프레임워크를 제공했습니다. 그의 핵심 논점은 다음과 같습니다: 바자 (Bazaar) 모델(공개된 코드, 분산된 기여자, 빠른 반복)이 성당 (Cathedral) 모델(중앙 집중식, 통제됨, 완성된 상태로 출시)보다 더 나은 소프트웨어를 만들어낸다는 것입니다. 이를 뒷받침하는 사례는 많습니다: 서버에서의 Linux, Oracle을 대체하는 PostgreSQL, 그리고 오픈 소스 인프라 스택 전체가 그러합니다. Raymond가 해결하지 못한 것, 즉 그 어떤 이상주의로도 해결할 수 없었던 것은 소비 (Consumption) 문제였습니다. 바자 모델에서 생산된 소프트웨어를 전화 지원, 작동하는 SSO (Single Sign-On), 그리고 급여 시스템이 고장 났을 때 책임을 물을 수 있는 실체가 필요한 기업 환경에 도입하는 것은, 애초에 소프트웨어를 구축하는 것과는 근본적으로 다른 문제입니다.

기업들이 실제로 구매하고 있었던 것

기업이 Microsoft Office, Adobe Creative Cloud, 또는 ServiceNow를 위해 6자릿수(억 단위)의 엔터프라이즈 라이선스에 서명할 때, 그들은 소프트웨어에 대해서만 비용을 지불하는 것이 아닙니다. 그들은 다음을 위해 비용을 지불합니다:

• 책임성 (Accountability). 무언가 고장 났을 때 책임질 수 있는 이름이 명시된 실체가 존재합니다. 해당 실체는 계약상의 노출(Contractual exposure)을 가지며, 문제를 해결해야 할 재정적 인센티브를 가집니다.
• 지원 (Support). 제품을 깊이 이해하도록 급여를 받는 실제 사람들이 있으며, 이사회 발표 직전에 시스템이 고장 났을 때 도움을 받을 수 있습니다.
• 문서화 (Documentation). 2019년에 자원봉사자가 다른 프로젝트에 흥미를 느끼고 참여하기 전에 업데이트해 둔 GitHub 위키가 아닙니다. 실제적이고, 최신이며, 특정 버전에 특화된 지침입니다.
• 예측 가능한 업데이트 (Predictable updates). 기존 워크플로와의 호환성이 테스트된 기능 출시. 누군가 급여를 받으며 관리하고, 시장의 요구에 민감하게 반응하는 로드맵입니다.
• 엔터프라이즈 통합 (Enterprise integration). LDAP가 작동합니다. Active Directory가 작동합니다. 귀하의 SSO 제공업체가 작동합니다. 벤더가 이를 직접 구축했거나, 이를 수행한 누군가를 인증했습니다.

FOSS (Free and Open-Source Software, 자유 및 오픈 소스 소프트웨어) 대안들은 종종 순수 기능 면에서는 상용 소프트웨어와 대등했습니다. 하지만 그들이 일관되게 제공할 수 없었던 것은 해당 기능들을 '둘러싼' 지원 구조였습니다. LibreOffice의 LDAP 연동이 제대로 작동하지 않을 때, 그에 대한 해답은 2016년에 올라온 포럼 게시물일 수도 있었습니다. 반면 Microsoft의 제품이 제대로 작동하지 않을 때는 전화를 걸면 되었습니다. 격차는 코드 품질의 문제가 아니었습니다. 그것은 운영상의 책임(operational accountability)의 문제였으며, 운영상의 책임에는 비용이 따릅니다.

전문성 세금 (The Expertise Tax)

이 문제에는 거의 이름 붙여지지 않은 더 세밀한 버전이 있습니다. 바로 '전문성 세금 (expertise tax)'입니다.

모든 FOSS 배포에는 인간의 전문성이라는 숨겨진 비용이 수반됩니다. 이는 일반적인 기술적 전문성이 아닙니다. 해당 특정 소프트웨어에 대한 구체적이고, 어렵게 얻어낸, 밀접한 지식을 의미합니다. 예를 들어, shared_buffers를 설정하기 전에 PostgreSQL의 max_connections 파라미터를 먼저 설정해야 한다는 것, 그리고 그 비율이 귀하의 특정 워크로드에 엄청나게 중요하다는 지식입니다. GIMP의 배치 처리(batch processing) 모드가 대화형 모드와는 다른 스크립트 경로를 필요로 한다는 지식입니다. Nextcloud의 LDAP 연동이 중첩된 그룹에서 실패하는 이유가 관리자 패널 네 단계 깊숙이 숨겨져 기본값이 'off'로 설정된 플래그 때문이며, 이것이 2021년 개발자 포럼에서 단 한 번 언급되었다는 사실을 아는 지식 말입니다.

이것이 FOSS 배포의 '어두운 예술 (dark art)'입니다. 운이 좋다면 어딘가에서 누군가 한 명이 이 문제를 알아냈을 것입니다. 그들은 이에 대해 블로그에 글을 썼을 수도 있습니다. 8년 전에 Stack Overflow 질문에 답변했을 수도 있습니다. 그들의 지식은 세상에 존재하지만, 수천 페이지의 문서, 수천 개의 포럼 스레드, 그리고 "works for me"로 종결된 수천 개의 GitHub 이슈에 흩어져 있습니다. 소프트웨어를 사용하고자 하는 조직은 그 지식을 찾아내고, 평가하고, 올바르게 적용해야 합니다.

과거에는 이를 위해 해당 소프트웨어와 수개월을 보낸 사람이나, 문맥을 암기할 수 있을 만큼 충분히 많은 경험을 쌓은 컨설턴트, 혹은 이 둘 모두가 필요했습니다.

에이전트가 실제로 변화시키는 것

검색 도구와 파일 시스템에 접근할 수 있는 AI 에이전트는 전문 지식 세금 (expertise tax) 문제를 겪지 않습니다. 인간이 겪는 방식과는 다릅니다.

에이전트에게 "우리 Active Directory 환경에 맞춰 Nextcloud를 설치하고 구성하라"는 작업을 부여하면, 에이전트는 문서, 릴리스 노트 (release notes), 알려진 문제 (known issues), 포럼의 고고학적 기록, 그리고 GitHub 이슈 (GitHub issues)를 동시에, 포괄적으로, 지치지 않고 읽어 내려갑니다. 중첩된 그룹 LDAP 플래그에 관한 2021년 포럼 게시물? 찾아내고, 읽고, 적용합니다. 이 정도 규모와 액세스 패턴의 배포에 권장되는 PostgreSQL 튜닝 파라미터 (tuning parameters)? 적용합니다. 네덜란드의 한 개발자가 리버스 프록시 (reverse proxy) 설정에서 모바일 동기화가 실제로 작동하도록 찾아낸 구성? 다음 관리자(에이전트든 인간이든)가 읽을 수 있는 재현 가능하고 문서화된 설정 파일로 완료합니다.

Raymond의 저서 The Cathedral and the Bazaar [1]의 일곱 번째 교훈은 다음과 같습니다: 사용자를 공동 개발자 (co-developers)로 대우하라. 지난 30년 동안 기업용 FOSS 사용자들은 그 열망에 부응할 수 없었습니다. 그들은 버그 리포트 (bug reports)를 제출할 수는 있었지만, 패치 (patches)를 만들 수는 없었습니다. 그 격차는 의지의 문제가 아니라 기술적 깊이의 문제였습니다. 에이전트는 그 격차를 완전히 무너뜨립니다. 에이전트를 사용하여 Nextcloud를 배포하는 기업은 기능적으로 공동 개발자가 됩니다. 에이전트가 소스 코드를 읽고, 확장 아키텍처 (extension architecture)를 이해하며, 사양에 맞는 작동하는 통합 (integrations)을 만들어내기 때문입니다. Raymond는 또한 Linus의 법칙 (Linus's Law)을 만들기도 했습니다: "충분한 눈(eyeballs)이 있다면, 모든 버그는 얕다." 제약 조건은 결코 눈의 개수가 아니었습니다. 그것은 눈이 찾아낸 것에 대해 조치를 취할 수 있는 인간의 역량이었습니다. 에이전트는 수정 사항을 직접 작성할 수 있는 눈입니다.

에이전트는 설정(configuration) 단계에서 멈추지 않습니다. 만약 FOSS(Free and Open Source Software, 자유 오픈 소스 소프트웨어) 소프트웨어에 귀하의 기업이 필요로 하는 기능이 누락되어 있다면 — 예를 들어, 컴플라이언스(compliance, 규정 준수) 보고서를 위한 특정 내보내기 형식이나, 사고 관리 시스템(incident management system)과의 웹훅(webhook) 통합 같은 기능 말입니다 — 에이전트는 직접 플러그인을 작성할 수 있습니다. 소스 코드가 공개되어 있기 때문입니다. 에이전트는 코드를 읽고, 확장 아키텍처(extension architecture)를 이해하며, 사양(specification)에 맞는 작동하는 코드를 생성할 수 있습니다. (지난 10년 동안 "언제 X를 지원하나요?"라는 질문을 받아온 모든 오픈 소스 프로젝트 메인테이너(maintainer)들은 방금 무언가 꿈틀거리는 것을 느꼈을 것입니다.)

저의 nanobot 구현체는 nanobot, claude-mem, lossless-claw, OpenClaw에서 마음에 들었던 기능들, 다운로드한 OpenClaw 기술, 그리고 효율성을 위한 지속적인 미세 조정(tweaks)이 결합된 영광스러운 프랑켄슈타인의 괴물과 같습니다. 유튜브에서 언급된 FOSS 프로젝트를 보면, 휴대폰으로 포크(fork)하여 탐색할 복사본을 만들거나, 저의 코드 에이전트를 해당 프로젝트로 지정하여 코드를 이해하고 관련 개념을 '저의' 시스템에 통합하도록 요청할 수 있습니다... 설령 저의 시스템이 다른 프로그래밍 언어를 사용하고 다른 사용 사례(use case)를 위한 것이라 할지라도 말입니다. 키워드 및 시맨틱 검색(semantic search, 의미론적 검색)을 갖춘 지속성 메모리(persistent memory), 개별적인 성격과 기술을 가진 여러 개의 Discord 채널, 상태 확인(health check) 및 보안 강화, 모델 라우팅(model routing), 그리고 지원 스크립트(예: 저의 모든 과거 Claude 세션 프롬프트와 응답을 원문 텍스트와 벡터 임베딩(vector embeddings) 형태로 지속성 메모리에 백필(backfill)하기)와 같은 기능들을 추가하는 것은 에이전트가 무엇을 할 수 있는지, 그리고 그들의 약점을 어떻게 보완할 수 있는지에 대해 더 많이 배울 수 있는 훌륭한 방법이었으며, 저는 단 몇 분 만에 타인의 뛰어난 작업물을 활용하여 이를 수행할 수 있었습니다. 저의 4,000줄 규모의 nanobot 코드는 몇 주간의 실험과 확장을 거쳐 약 25,000줄 정도로 성장했지만, 제가 원하는 대로 작동하며(현재로서는), OpenClaw의 400,000줄보다는 훨씬 작습니다(저는 OpenClaw에 반대하는 것이 아닙니다. 저는 2013년형 MacBook을 사용 중이라 크기를 작게 유지하려 노력했을 뿐입니다). OpenClaw와 그 기술들, 그리고 nanobot조차도 제가 시간과 주의를 기울이는 대가로 직접 포크하여 제 용도에 맞게 수정할 수 있었던 FOSS 프로젝트들입니다.

FOSS (Free and Open Source Software)의 기업 도입에 있어 실질적인 장벽은 결코 이데올로기의 문제가 아니었습니다. 그것은 전문 지식(expertise)에 대한 접근성 문제였습니다. 에이전트(Agents)는 인력(headcount)이 아닌 컴퓨팅 자원(compute)의 비용으로 제공되는 '온디맨드 전문 지식'입니다.

이는 미묘하지만 중대한 변화입니다. 상용 소프트웨어 벤더들은 제품에 내장된 전문 지식에 대해 부분적으로 비용을 청구해 왔습니다. 즉, 사려 깊은 기본 설정(defaults), 호환성 테스트, 현재 UI와 실제로 일치하는 도움말 문서, 그리고 제품의 생산적이고 안전한 사용을 위한 분석, 보고 및 보안 가드레일(security guardrails) 등이 그것입니다. 에이전트는 이러한 기능들이 포함되지 않은 소프트웨어 위에 해당 계층들을 공급할 수 있습니다.

비즈니스 모델의 재정립 (The Business Model Reckoning)

그렇다면 이것이 소프트웨어 기업들에게 무엇을 의미할까요?

가장 취약한 곳은 오픈 소스가 제공할 수 없었던 것들에 비용을 청구하며 FOSS를 기반으로 구축된 기업들입니다. Linux를 가져와 엔터프라이즈급으로 만들고 지원(support)과 인증(certification)에 비용을 받는 Red Hat의 모델은 그 시대에 믿을 수 없을 정도로 효과적이었습니다. 하지만 그 시대는 끝나가고 있습니다. 에이전트가 1차 지원(first-tier support) 상호작용의 대부분을 처리하고, 인간 중개자 없이 구성 변경을 적용하며 에러 로그를 해석할 수 있게 될 때, 가격 책정(pricing)에 대한 논의는 근본적으로 변화합니다.

동일한 논리가 엔터프라이즈 소프트웨어 지도 전반에 파급됩니다:

• **지원 중심의 소프트웨어 기업(Support-led software businesses)**은 에이전트가 1차 및 2차 지원을 범용화(commoditize)함에 따라 해자(moat)를 잃게 됩니다.
• **복잡한 FOSS 스택을 중심으로 구축된 구현 컨설팅(Implementation consulting)**은 컨설턴트가 며칠과 프로젝트 계획을 소요하던 일을 에이전트가 몇 시간 만에 복제할 수 있게 되면서 희소성 프리미엄을 잃게 됩니다.
• 운영자에게 FOSS 도구 실행법을 가르치는 교육 및 인증(Training and certification) 프로그램은, 단 몇 분 만에 단돈 몇 푼으로 스스로를 그리고 사용자들을 즉석에서 효과적으로 교육하는 에이전트로부터 압박을 받게 됩니다.
• **차별점이 미미한 상용 소프트웨어(Commercial software with thin differentiators)**는 이제 에이전트 기반의 지원 계층이 결합된 FOSS 대안들과 직접적인 경쟁에 직면하게 됩니다.

누가 승리할까요? 그 그림은 단순히 "모두가 패배한다"는 것보다 훨씬 더 흥미롭습니다.

FOSS 유지관리자(maintainers)들은 이전에는 결코 가질 수 없었던 영향력(leverage)을 얻게 됩니다. 에이전트(agents)가 의존하는 프로젝트들, 즉 도처에서 에이전트에 의해 구성되고 확장되며 배포되는 핵심 코드들은 중추적인 인프라(backbone infrastructure)가 됩니다. 운영을 위해 전문 지식이 필요하다는 이유로 무시되었던 프로젝트들은 전문 지식의 장벽이 사라짐에 따라 훨씬 더 널리 배포될 수 있습니다. 주요 프로젝트의 유지관리자들은 과거 자유 소프트웨어 재단(Free Software Foundation)이 꿈만 꿀 수 있었던 협상력, 즉 실제적이고 광범위한 기업적 의존성을 확보하게 됩니다. Raymond는 오픈 소스 커뮤니티를 기프트 컬처(gift cultures) [1]라고 설명했는데, 이는 통제하거나 판매하는 것이 아니라 당신이 무엇을 기부하느냐에 따라 명성이 쌓이는 문화를 의미합니다. 지난 30년 동안 세상에 코드를 기부해 온 유지관리자들은 이제 AI 기반 기업용 컴퓨팅(AI-enabled enterprise computing)의 토대가 되었습니다. 기부가 되돌아온 것입니다. 단지 30년의 시간과 추론 엔진(inference engine)이 필요했을 뿐입니다.

매니지드 서비스 제공업체(Managed service providers)들은 번창합니다. 관리형 PostgreSQL을 실행하는 AWS, 관리형 Kubernetes를 실행하는 Google Cloud, 모든 계층에서 관리형 인프라를 실행하는 Cloudflare 등은 소프트웨어를 판매하는 것이 아닙니다. 그들은 그 위의 운영 계층(operational layer)을 판매합니다. 에이전트는 이를 제거하지 않습니다. 오히려 에이전트는 기반이 되는 FOSS의 채택을 가속화하며, 결과적으로 더 많은 매니지드 서비스 사용을 유도합니다.

그리고 살아남는 소프트웨어 기업들은 진정한 해자(moats)를 가진 기업들입니다. 즉, 독점적 데이터(proprietary data), 네트워크 효과(network effects), 하드웨어 통합(hardware integration), 또는 그 어떤 FOSS 구성으로도 복제할 수 없는 워크플로 고착화(workflow lock-in)를 가진 기업들입니다. 실제로 소유하지 않은 전문 지식에 대해 비용을 청구했던 제품들은 압박을 받게 될 것입니다. 진정으로 대체 불가능한 무언가에 대해 비용을 청구했던 제품들은 괜찮을 것입니다.

가격 책정의 함의 (The Pricing Implications)