우리는 수십 년에 걸쳐 진행되어 온 건축적 변화의 마찰 지점 속에 살고 있으며, 이는 생성형 AI (Generative AI)의 압박 아래 급격히 가속화되었습니다. 수년 동안 소프트웨어 엔지니어링 산업은 편안하고, 어쩌면 나태한 신화에 기반하여 운영되어 왔습니다. 바로 오픈 소스 소프트웨어 (Open Source Software)는 소비하는 데 비용이 들지 않고 유지하는 데 아무것도 필요하지 않은, 무한하고 스스로 갱신되는 공공재라는 믿음입니다.

2026년 6월 말 스위스에서 열린 소프트웨어 엔지니어링의 미래 리트릿 (Future of Software Engineering Retreat)에서의 논의는 훨씬 더 분열되고 긴박한 모습을 그려냈습니다. 우리가 직면해야 할 현실은 냉혹합니다. 오픈 소스는 단순히 진화하고 있는 것이 아닙니다. 구조적 고갈, 공급망 전쟁 (Supply Chain Warfare), 그리고 코드 생성의 산업화에 의해 깎여 나가고 있습니다.

고갈의 경제학 및 제로 비용의 오류

현재 위기의 핵심은 자산 가격 책정과 인간 비용 사이의 근본적인 오해에 있습니다. 디지털 자산의 가격은 배포의 한계 비용(Marginal Cost) — 즉 사실상 제로(0) — 에 수렴해야 한다는 우아한 경제적 논리를 자주 듣게 됩니다. 라이브러리를 복사하는 데 비용이 들지 않는다면, 이론적으로 소프트웨어는 무료여야 합니다.

하지만 이 우아한 이론은 이 모든 것의 중심에 있는 인간의 노동을 숨기고 있습니다. 배포에는 비용이 들지 않지만, 유지보수 (Maintenance)는 믿을 수 없을 정도로 비쌉니다. 현대의 디지털 뱅킹, 클라우드 인프라 (Cloud Infrastructure), 그리고 엔터프라이즈 플랫폼을 지탱하는 보이지 않는 기둥인 핵심 오픈 소스 패키지들의 유지보수자들은 번아웃을 겪고 있으며, 단 한 푼의 기여도 없이 그들의 노동을 소비하는 수십억 달러 규모의 기업들로부터 심리적 괴롭힘에 직면하고 있습니다.

우리는 허용적 라이선스 (permissive licensing)를 착취할 권리로 집단적으로 오해해 왔습니다. 클라우드 시대가 도래하면서 오픈 소스 옹호자들은 MIT 및 Apache 라이선스를 소프트웨어 채택을 위한 궁극적인 승리로 치켜세웠습니다. 그러나 이 허용적 체제는 거대 기업들이 독점적 제국을 건설하는 기반이 되었으며, 이들은 오픈 소스 코드를 가벼운 오케스트레이션 (orchestration)으로 감싸 경제적 가치를 가로채는 동시에 생태계에는 거의 돌려주지 않았습니다. 이는 소수의 운 좋은 이들에게는 후원 시스템이 되고, 나머지 대다수에게는 자선에 의존하는 복지 국가와 같습니다. 물론, 이것은 근본적으로 지속 불가능합니다.

두 가지 압박: 슬롭 (Slop) 풀 리퀘스트와 신뢰의 하락

오픈 소스의 구조적 경제학이 이미 취약했다면, 자동화된 도구의 도입은 만성적인 상태를 급성으로 악화시켰습니다. 이제 메인테이너 (Maintainer)들은 두 가지 전선에서 공격을 받고 있습니다.

슬롭 (Slop)의 산업화

코드를 생성하기 위한 진입 장벽이 제로(0)로 떨어졌습니다. 이는 개인에게 힘을 실어주기도 하지만, 동시에 저장소(repository)의 관문을 경악스러울 정도로 많은 양의 저품질 AI 생성 풀 리퀘스트 (pull requests)로 범람하게 만들었습니다. 한때 코드 작성에 시간을 보냈던 메인테이너들은 이제 자신의 포트폴리오를 게임화하려는 개인들의 자동화된 기여물을 걸러내야 하는, 무보수의 전업 코드 리뷰어가 되어야 하는 처지에 놓였습니다.

이는 악순환을 만듭니다. 심리적, 심지어 정서적 부담으로 인해 메인테이너들은 프로젝트의 공개 기여를 완전히 차단하게 됩니다. 이는 의도치 않게, 결국 프로젝트를 물려받아 지속해 나갈 차세대 정당한 메인테이너들의 길을 끊어버리는 결과를 초래합니다.

신뢰 지형의 급격한 변화

우리는 더 이상 오픈 소스 신뢰성의 전통적인 지표를 신뢰할 수 없습니다. 프로젝트 성숙을 위한 타임라인이 붕괴되었습니다. 바이럴(viral)한 AI 에이전트 열풍에 힘입어, 커밋 기록(commit history)이 고작 3주에 불과함에도 불구하고 라이브러리들이 몇 주 만에 GitHub 스타 수 만 개를 기록하며 급증하고 있습니다. 또한 악의적인 PR(Pull Request)을 제기하는 비용이 믿기지 않을 정도로 저렴해졌습니다. 에이전트들은 매일 새로운 공격 벡터(attack vectors)를 찾아내고 있으며, 이는 소프트웨어가 안전하고 보안이 유지된다는 신뢰를 뒷받침하는 메인테이너(maintainer)들의 작업을 매우 어렵게 만듭니다. 이를 종합해 보면, 오픈 소스의 신뢰 모델이 심각하게 저하된 상황에 직면해 있습니다.

라이선싱의 역설: 자유에서 착취로

현대 소프트웨어 공학의 구조적 취약성은 이를 보호하기 위해 우리가 설계한 법적 프레임워크와 밀접하게 연관되어 있습니다. 현재의 라이선스 모델은 의도치 않게 추출 경제(extraction economy)를 만들어냈으며, 이는 "허용적 (permissive)" 오픈 소스 라이선스(MIT 및 Apache 등)와 카피레프트 (copyleft) 계약(GPL 등)을 구분 짓는 근본적인 철학에 대한 중대한 재평가를 강요하고 있습니다.

역사적 합의는 허용적 라이선싱을 광범위한 소프트웨어 채택을 위한 궁극적인 촉매제로 옹호해 왔습니다. 마찰을 줄이고 준수(compliance) 장벽을 제거함으로써, MIT 및 Apache와 같은 라이선스는 코드가 전 세계적으로 전파될 수 있도록 허용했습니다.

하지만 이러한 마찰 없는 배포는 양날의 검이 되었습니다. 한 리트릿(retreat) 참가자는 허용적 라이선싱이 심각한 집단적 실수였다고 언급했습니다. 이는 세계 최대 기업들이 자원봉사자의 노동력을 잠식할 수 있게 하는 법적 메커니즘으로 작용하여, 독립적인 메인테이너들을 수십억 달러 규모의 기업 인프라를 지탱하는 무보수 기둥으로 변질시켰기 때문입니다.

그 대안인 제한적 또는 이중 라이선스 (dual-licensing) 모델은 종종 완전히 다른 종류의 운영 실패를 야기합니다:

조달 병목 현상 (The procurement bottleneck). 비상업적 이용 또는 "취미 활동가에게는 무료"와 같은 조항을 통해 코드를 보호하려는 시도는 종종 프로젝트 채택에 사형 선고와 같은 역할을 합니다. 한 실무자는 프로젝트를 수익 창출이 불가능한 용도로만 제한하는 것이 성장을 완전히 마비시켰다고 공유했습니다. 기업 개발자들은 도구의 유용성이 부족해서가 아니라, 라이선스 변경이 엔지니어들이 도저히 감당하기 거부하는 복잡한 기업 조달 검토와 행정적 서류 작업을 촉발했기 때문에 도구를 완전히 포기했습니다.

기업의 보이콧 (The corporate boycott). Akka가 매출 1억 달러 이상의 조직을 대상으로 하는 라이선스로 전환한 사례처럼 이중 라이선스 임계값을 신중하게 조정하더라도, 기업들은 규정 준수 대신 관례적으로 보이콧을 선택합니다. 인용된 한 사례에서는, 어떤 기업이 오픈 소스 커뮤니티에 비용을 지불하는 선례를 남기지 않기 위해, 충분히 지불할 능력이 있음에도 불구하고 중요한 의존성(dependency)을 명시적으로 포기하기로 결정했습니다.

집행 부담 (The enforcement burden). 일부 순수주의자들에게는 어떠한 라이선스 제한도 행정적 책임(liability)을 유발합니다. 이러한 관점에서 상업적 제한을 추가하는 것은 유지 관리자(maintainer)를 집행자로 만들며, 창의적 표현 행위를 법적 잡무로 변질시킵니다.

소프트웨어 재구현을 통한 우회 (Bypassing by reimplementing software). 이는 윤리적으로 의심스러울 뿐만 아니라(비록 이에 동의하지 않는 이들도 있겠지만), 실무적인 문제도 존재합니다. 재구현에는 시간과 비용이 소요되며, 새로운 보안 또는 신뢰성 문제를 야기할 수도 있습니다.

업계는 수정이 자유로운 소프트웨어와 소비 시점에 무료인 소프트웨어 사이의 구분을 대체로 무너뜨렸습니다. 이는 흔히 '무료 맥주(free beer)'와 '표현의 자유(free speech)'의 차이로 설명되곤 합니다.

오픈 소스 정의(Open-source definition)는 본래 전통적인 자유 소프트웨어(free software)가 비즈니스 친화적이지 않다고 판단되었기 때문에 등장했습니다. 비즈니스 친화성에만 전적으로 최적화함으로써, 우리는 기업의 후원이 근본적인 구조적 의무가 아닌 선택적인 자선으로 취급되는 풍경에 도달했습니다.

이러한 위기를 심화시키는 것은 방향을 바로잡으려는 유지 관리자(Maintainer)들에게 가해지는 정서적, 심리적 고통입니다. 핵심적인 역할을 하는 프로젝트가 방어적인 라이선스 변경(defensive licensing shift)을 단행할 때, 커뮤니티의 반응은 빈번하게 적대적입니다. 유지 관리자들은 수년간 지원해 온 바로 그 생태계로부터 심각한 평판 저하와 심리적 반발에 직면합니다. 우리는 라이선스를 변경하는 것은 공격 행위로 간주되는 반면, 라이선스를 착취하는 것은 표준적인 비즈니스 관행으로 간주되는 환경에 처해 있습니다.

생태계 붕괴와 유지 관리자 인센티브의 위기

우리는 생태계가 붕괴할 수도 있는 지점에 와 있습니다. 프로젝트를 유지하기 위한 인센티브는 사라지고 있으며, 일자리와 관련된 광범위한 산업적 압박은 가장 의욕적이고 열정적인 소프트웨어 개발자들조차 오픈 소스(Open Source)에 참여하는 것을 어렵게 만들고 있습니다.

이기적인 행위자들이 공공 자원을 끌어다 씀으로써 공공 자원이 고갈되는 현상을 설명하는 '공유지의 비극 (Tragedy of the commons)'은 이러한 논의에서 자주 인용되는 개념입니다. 언뜻 보기에 이는 실제 사례로서 아주 좋은 예시입니다. 하지만 이 개념이 도움이 되기는 하지만, 여기서 적용했을 때 작용하고 있는 비대칭성(asymmetry)을 설명하거나 고려하지 못합니다. 첫째, 만약 오픈 소스 소프트웨어가 일종의 공유지라면, 그것은 누구나 마음대로 가져다 쓸 수 있는 자연적으로 발생하는 자원이 아닙니다. 그것은 순수하게 커뮤니티 정신으로 행동하는 사람들에 의해 구축되고 유지되는 것입니다. 둘째, 추출(extraction) 과정이 즉각적인 상업적 인센티브를 가진 행위자들에 의해 놀라운 규모로 일어나고 있습니다.

오픈 소스의 이전 시대가 대체로 개발자 커뮤니티의 존재와 상호 이익이라는 감각에 의해 유지되었던 반면, 오늘날 소프트웨어의 경제 구조는 가치가 추출된 후, 그것을 처음 존재하게 했던 생태계로 다시 환원될 방법 없이 포획(captured)되는 구조를 가지고 있습니다.

스펙(Spec) 대 코드(Code): 우리는 여기서 어디로 가야 하는가?

이러한 모든 압박의 결과로, 우리는 하나의 급진적인 논제(thesis)가 등장하는 것을 목격하고 있습니다. 즉, 오픈 소스의 미래는 코드가 아니라 스펙(specification)이 될 것인가 하는 점입니다.

요청에 따라 전문화된 코드를 생성할 수 있는 LLM(대규모 언어 모델)의 등장으로, 기업의 엔지니어링 팀들은 수천 줄에 달하는 거대한 외부 의존성(dependencies)을 끌어다 쓰는 것의 유용성에 대해 의문을 제기하기 시작했습니다. 만약 외부 라이브러리를 사용하는 것이 관리 불가능한 공급망 리스크(supply chain risk)와 끝없는 패치(patching)의 순환을 초래한다면, AI를 사용하여 필요한 정확한 기능적 파편(functional fragments)만을 로컬의 '안전 버블(safety bubble)' 안에 구현하는 것이 경제적으로 논리적인 선택이 됩니다.

• '전통적인' 모델 -> 외부 코드 라이브러리 소비 -> 공급망 리스크 및 유지보수 상속
• 부상하는 모델 -> 오픈 스펙(specification)/아이디어 학습 -> AI가 생성한 로컬 재구현(re-implementation)

하지만, 이러한 '재구현' 논제에는 한계가 있습니다. 우선, 여기서 언급되는 생성형 AI 활용의 인상적인 사례 중 상당수는 매우 명확하고 상세한 테스트 하네스(test harness)나 매우 명확한 스펙(specification)이 존재하는 것들을 기반으로 했다는 점에 주목할 가치가 있습니다.

단순한 정적 사이트 생성기(static site generator)는 AI가 한 시간 안에 만들어낼 수 있지만, 암호화 라이브러리(cryptographic libraries)나 브라우저 불가지론적(browser-agnostic) UI 프레임워크와 같은 복잡한 엔지니어링 작업은 자동화된 모델이 완전히 재앙적인 상황으로 무너지지 않고 신뢰성 있게 복제하기에는 엄청난 수준의 엔지니어링 엄밀성(engineering rigor)을 요구합니다.

게다가, 이는 참조 라이브러리의 원작자에게 돌아갈 공로(credit)를 부정하는 일이기도 합니다. 상업적 목표를 가진 조직에게는 이것이 우선순위가 아닐 수 있지만, 만약 그 인정(recognition)이 메인테이너(maintainer)의 동기부여라면, 그것이 사라질 때 어떤 일이 벌어질까요?

공유 코드 라이브러리를 완전히 포기하고 로컬의 파편화된 코드베이스(codebases)를 택하는 것은 엘리트 계층의 분열을 초래할 위험이 있습니다. 즉, 정교한 로컬 AI 아키텍처를 실행할 수 있는 하드웨어와 금융 자본을 가진 이들과, 소프트웨어를 전혀 갖지 못하게 될 이들 사이의 분열입니다.

소프트웨어 엔지니어와 아키텍트를 위한 질문들

이러한 지형을 헤쳐나가기 위해, 엔지니어링 팀은 수동적인 소비를 넘어 더 어렵고 의도적인 질문들을 던지기 시작해야 합니다:

우리의 의존성 발자국(dependency footprint)은 어느 정도인가? 단 200줄의 로직만 있으면 해결될 문제를 풀기 위해 20,000줄 규모의 제3자 라이브러리(third-party library)를 가져오고 있지는 않은가? 만약 그렇다면, 우리는 해당 의존성의 보안 및 유지보수 수명 주기(maintenance lifecycle)를 책임질 준비가 되어 있는가?

유지보수자(maintainers)와의 관계를 어떻게 정의할 것인가? 우리의 프로덕션 시스템이 자원봉사자나 아주 작은 팀이 관리하는 오픈 소스 도구에 의존하고 있다면, 우리가 실질적인 보답을 제공할 메커니즘은 무엇인가? 우리는 기업 차원의 후원(corporate patronage)을 통해 적극적으로 참여하고 있는가, 아니면 무료로 엔터프라이즈급 지원을 기대하는 소비자로서 행동하고 있는가?

명세(specification)와 실행(execution) 사이의 경계선을 어디에 그을 것인가? 향후 프로젝트를 진행할 때, 오픈 소스에서 아키텍처 패턴과 명세를 참고해야 하는가, 아니면 실제 바이너리(binaries)를 그대로 가져와 사용해야 하는가?

향후 몇 달간의 가이드라인

우리가 이 에이전트 시대(agentic era)로 더 깊이 진입함에 따라, 엔지니어링 조직은 오픈 소스에 대해 방어적이면서도 매우 의도적인 태도를 취해야 합니다: