AI 코딩 에이전트는 소스 코드를 읽고 수정할 수 있게 되면서, 자유 소프트웨어의 가치와 사용자 자유를 다시 실질적인 문제로 만들고 있다.
소프트웨어 이야기꾼
메뉴
게시일 2026년 3월 28일 2026년 3월 28일 작성자 George London
나는 요즘 바이브 코딩을 정말 많이 하고 있다. 정말, 엄청나게 많이. Andrej Karpathy가 최근 _No Priors_에서 농담처럼 말한 “AI psychosis” 수준까지는 아닐지 몰라도, 그렇다고 아주 멀리 떨어져 있는 것도 아니다.[1] 그런데 바이브를 탈수록 어떤 생각이 자꾸 반복해서 떠오른다. 즉 AI 코딩 에이전트가 자유 소프트웨어를 그 어느 때보다도 더 중요하게 만들려 하고 있을지도 모른다는 생각이다. 기업식으로 무미건조하게 말하는 오픈 소스를 뜻하는 게 아니다. 내가 말하는 것은 Stallman의 의미에서의 자유 소프트웨어, 즉 사용자가 그것을 실행하고, 연구하고, 수정하고, 공유할 자유를 주는 소프트웨어다.
이 구분을 알고 있던 비교적 소수의 사람들에게조차도, 오랫동안 그것은 대부분 학술적인 문제처럼 느껴져 왔다. SaaS는 소프트웨어 자유에 관심을 갖기 어렵게 만들었다. 애초에 대부분의 사람들은 자신이 의존하는 소프트웨어의 소스 코드를 보지도, 만져보지도 못했기 때문이다. 코드는 다른 누군가의 서버에 있었고, 운영은 공급업체가 처리했으며, 실질적인 질문은 자유가 아니라 편의성이 되었다.
에이전트는 이 상황을 바꾼다. 에이전트가 코드베이스를 읽고, 이해하고, 당신을 대신해 수정할 수 있다면, 소스 코드에 대한 접근은 프로그래머를 위한 상징적 권리에서 훨씬 더 많은 사람을 위한 실질적 능력이 된다. 갑자기 바꿀 수 있는 소프트웨어와, 사정만 해야 하는 소프트웨어의 차이가 정말로 중요해지기 시작한다.
그리고 나는 이것을 추상적으로만 생각하는 것이 아니다. 나는 최근 AI 에이전트에게 SaaS 앱을 나 대신 맞춤화해 보라고 시도했는데, 그 경험은 이 문제 전체를 아주 빠르게, 아주 구체적으로 만들어 버렸다.
1980년, Richard Stallman[2]은 MIT AI Lab의 프로그래머였고, 프린터 문제를 겪고 있었다. 연구실은 새로운 Xerox 레이저 프린터를 들여왔는데, 계속 종이가 걸렸다. Stallman은 이 문제를 고치고 싶었다. 최소한 인쇄 작업이 막혔을 때 사용자에게 알리는 기능이라도 추가하고 싶었다. 하지만 Xerox는 그에게 소스 코드를 주지 않았다. 프린터 소프트웨어는 독점 소프트웨어였다.
이것은 사소한 일처럼 보인다. Stallman에게는 사소한 일이 아니었다.
그는 코드 공유가 규범이던 컴퓨팅 문화 속에서 성장했다. 소프트웨어를 받으면 소스 코드도 함께 받았다. 당연히 그래야 했다. 그렇지 않으면 버그를 어떻게 고치고 기능을 어떻게 추가하겠는가? Xerox 프린터 사건은 그에게 어떤 사실을 결정적으로 각인시켰다. 소프트웨어가 잠겨 있고, 자신이 의존하는 도구를 연구하거나 수정할 수 없는 세계는, 사용자가 근본적인 무언가를 잃어버린 세계라는 것이었다.
그래서 Stallman은 Free Software Foundation을 설립했고, 이후 40년 동안 자신이 “네 가지 자유”라고 부른 것을 전도했다.
그는 이렇게 말하곤 했다. “맥주처럼 공짜라는 뜻이 아니라, 표현의 자유에서의 자유다.”
한동안 이 메시지는 반향을 일으켰다. 1990년대에는 자유 소프트웨어가 폭발적으로 성장했다. Linux, Apache, MySQL, PHP — 인터넷 대부분을 구동하게 된 전체 스택이 여기에 속했다. Red Hat 같은 회사들은 그 위에 실제 비즈니스를 세울 수 있다는 것을 보여주었다. Eric Raymond는 “The Cathedral and the Bazaar”를 쓰고, 개방형 개발이 더 나은 소프트웨어를 만든다고 주장했다. Microsoft의 Steve Ballmer는 Linux를 “암”이라고 불렀다. 그것은 컴퓨팅의 영혼을 둘러싼 진짜 이념 전쟁처럼 느껴졌다.
그러다 조용히, 그리고 꽤 지루한 이유 때문에, 그 전쟁은 무의미해졌다.
하지만 그 이야기는 잠시 후 다시 하자.
먼저, 이 글을 조사하기 전에는 나도 몰랐던 역사의 한 조각을 이야기하겠다. 지금 벌어지는 일을 이해하는 데 중요하다.
1998년 2월 3일, 한 무리의 사람들이 Palo Alto의 Foresight Institute에 모였다. 소프트웨어 조직이 아니라 나노기술 싱크탱크였다. 연구소의 사무총장 Christine Peterson은 “free software”를 새로운 용어인 “open source”로 바꾸자고 제안했다.[3] 그녀의 이유는 실용적이었다. “free software”라고 말할 때마다 사람들은 그것을 무료 소프트웨어라는 뜻으로 받아들였고, 실제 소프트웨어 얘기를 하기도 전에 10분 동안 차이를 설명해야 했기 때문이다.
몇 주 뒤, Tim O’Reilly가 1998년 4월에 주최한 “Freeware Summit”에서 참석자들은 이름을 두고 토론했고, “sourceware”나 “free software” 같은 대안보다 “open source”를 9대 6으로 선택했다.[4]
중요한 것은 이 리브랜딩 과정에서 무엇이 사라졌는가이다. Eric Raymond와 Bruce Perens는 같은 달 Open Source Initiative를 공동 설립했고, Raymond는 “Goodbye, ‘free software’; hello, ‘open source.’”라는 선언문을 발표했다. 그의 핵심 주장은 이랬다. 기존 용어는 기업형 사람들을 불안하게 만든다는 것이다.[5]
Stallman은 1998년 4월 Tim O’Reilly의 “Freeware Summit”에 초대받지 못했다. 이 행사는 새로운 리더십 서사를 굳히는 데 도움을 주었다. Linus Torvalds는 초대받았다. Larry Wall도 초대받았다. Guido van Rossum도 초대받았다. Stallman은 아니었다.[4]
왜 이것이 중요할까? “오픈 소스”로의 리브랜딩은 단순한 마케팅 변경이 아니었기 때문이다. 그것은 철학적 절단이었다. “오픈 소스”는 코드 공유 관행은 유지했지만, 사용자가 무엇을 _마땅히 받아야 하는가_에 대한 윤리적 주장은 외과적으로 제거했다. Stallman의 표현대로, “오픈 소스는 개발 방법론이고, 자유 소프트웨어는 사회 운동이다.”[6] Raymond는 “자유 소프트웨어”라는 표현이 혼란을 주고 기업형 사람들을 불안하게 만든다고 노골적으로 말했다.[5]
기업 세계는 이것을 아주 좋아했다. 사용자가 무엇을 _받아야 하는가_라는 문제와 씨름할 필요 없이, 오픈 소스 코드를 사용하고, 오픈 소스 프로젝트에 기여하고, 오픈 소스 브랜드 정체성을 만들 수 있었기 때문이다. 오픈 소스는 기업이 사용자와의 관계를 전혀 바꾸지 않고도 채택할 수 있는 개발 방법론이 되었다.
하지만 자유 소프트웨어를 वास्तव में 주변부로 밀어낸 것은 정치적이거나 철학적인 논쟁이 아니었다. 그것은 SaaS였다.
GPL — 핵심적인 자유 소프트웨어 라이선스 — 은 소프트웨어를 _배포_받는 사람 누구에게나 소스 코드를 공유하도록 요구했다. 핵심 단어는 “배포”다. 소프트웨어를 배포하지 않고, 그냥 자기 서버에서 돌리면서 사람들이 웹을 통해 접근하게만 한다면, 그 라이선스는 적용되지 않았다. 자유 소프트웨어를 가져와 수정하고, 그 위에 비즈니스를 만들고, 수정 내용을 누구와도 공유하지 않을 수 있었다.
이것은 가상의 이야기가 아니었다. 눈에 띄는 사례 중 하나는 AWS가 Elasticsearch 같은 프로젝트를 중심으로 관리형 서비스를 제공한 것이었고, 이는 가치 포착, 기여, 라이선스 조건을 둘러싼 매우 공개적인 분쟁을 촉발했다.[7] SaaS 모델 안에서는 소프트웨어가 배포되지 않는 한 GPL의 카피레프트 의무가 종종 발동하지 않기 때문에, 소스 공유 요구사항은 우회될 수 있다.[8]
그다음에 무슨 일이 일어났는지는 숫자가 말해준다. 2010년대 내내, 그리고 2020년대에 들어와서도, 오픈 소스 사용 데이터에서 퍼미시브 라이선스는 점점 더 지배적인 위치를 차지하게 되었다.[9]
이 문제를 고치려는 시도는 있었다. AGPL(Affero GPL)은 SaaS 허점을 막도록 설계되었다. AGPL 소프트웨어를 수정하고 그것을 네트워크를 통해 제공한다면, 소스 코드를 공유해야 했다.[8] 강력한 아이디어였다. 너무 강력해서 Google은 지금 Google 내부에서 AGPL 코드를 금지하는 광범위한 공개 정책을 유지하고 있다.[10] Drew DeVault가 주장했듯이,
Google의 반-AGPL 입장은 단순한 법적 예방 조치가 아니라 전략적이었다. “더 넓은 커뮤니티에서
AGPL 사용을 억제함으로써 Google은 자신들의 필요를 위해 아무 의무 없이 가져갈 수 있는 자유 및 오픈 소스 소프트웨어의 더 큰 집합을
만들기를 바란다.”
AGPL의 제한된 채택은 즉흥 대응의 연쇄를 낳았다. MongoDB는 Server Side Public License로 전환했다. Redis Labs는 2018년에 여러 Redis 모듈을 Commons Clause 스타일 라이선스로 옮겼고, Redis는 이후 핵심 Redis를 이중 source-available 라이선스로 옮긴 뒤 Redis 8에서 AGPL을 추가했다. HashiCorp는 Terraform을 Business Source License로 전환했다. Elastic은 Apache에서 SSPL/ELv2로 갔다가 다시 AGPL을 추가했다. 각각의 전환은 근본 문제를 확인시켜 주었지만, 완전히 해결하지는 못했다.[11]
그리고 솔직히 말해? 사용자 관점에서 소프트웨어 자유라는 질문은 그냥 중요하지 않게 되었다. 소프트웨어가 다른 누군가의 서버에서 실행될 때는, 소스 코드를 가지고 있어도 별 도움이 되지 않는다. 수정한 자기 버전을 실행할 수 없다. 애초에 어떤 버전이든 당신이 _실행_하는 것이 아니기 때문이다. Salesforce가 실행하고, Google이 실행하고, 누군가가 실행한다. 네 가지 자유는 이론적인 것이 되었다.
한동안은 그 거래가 괜찮아 보였다. SaaS는 엄청나게 편리했다. 설치할 필요 없고, 자동 업데이트가 되고, 어디서나 접근할 수 있고, 보안 패치와 백업과 서버가 새벽 3시에 죽었을 때의 대응까지 다른 누군가가 처리한다. 그래서 자유 소프트웨어 논쟁은 배경으로 밀려났다. 진자는 결정적으로 편의성 쪽으로 기울었고, 우리 대부분은 — 나를 포함해 — 그 거래를 받아들였다.
그러다 AI가 나에게 구매 후회를 안겨주기 시작했다.
나는 작업 관리를 위해 Sunsama를 사용한다. 좋은 제품이고 정말 마음에 든다. 하지만 내가 만들고 싶은 워크플로가 하나 있었고, Sunsama는 그것을 사실상 불가능하게 만들고 있었다.
워크플로는 단순하다. 내가 Twitter를 스크롤하다가 나중에 반응하고 싶은 트윗을 보게 되면 — 나중에 읽고 싶은 글이든, 시도해 보고 싶은 정신 나간 서부 개척 유정 개발자 테마의 AI 도구든 — 그것을 Sunsama에 작업으로 저장해서, 언젠가 하고 싶은 다른 200억 가지 일들 사이에서 일정에 배치하고 싶다.
Sunsama에는 iOS 공유 시트 연동이 있지만, iOS는 그것을 여러 번 탭해야 하는 뒤쪽에 숨겨 놓고, 나는 그 동작 방식도 마음에 들지 않는다.
첫째, 그것이 만드는 작업은 사실상 URL 하나에 iOS가 트윗에서 끌어온 제목이 붙은 것뿐이다. 나는 기본 공유 동작이 만들어내는 “@dril의 트윗” 같은 쓰레기 제목 대신, “미디어 측정에 대한 질문에 @누구누구에게 답하기” 같은 작업 제목을 LLM이 생성해 주면 좋겠다.
둘째, 나는 이 작업들에 자동으로 라벨을 붙이거나 분류할 수 없다. 건강 관련 트윗은 #health 카테고리로 가고, 채용 관련 트윗은 #recruiting으로 가게 하고 싶다. 하지만 공유 시트는 모든 것을 그냥 받은편지함으로 던져 넣는다.
하지만 내 선호는 중요하지 않다. Sunsama가 자기 제품 안에 넣어 주기로 결정한 것 이상으로는 이 워크플로에 LLM 기반 지능을 추가할 수 없기 때문이다. Sunsama 팀이 작업을 자동 분류하는 AI 기능을 출시하면 좋다. 그렇지 않으면 나는 운이 없는 것이다. 기능 요청을 제출하고 2032년에 다시 확인하는 것 외에는 할 수 있는 일이 없다.
이것은 기술의 문제가 아니다. 나는 코드를 작성할 줄 안다. 원한다면 처음부터 나만의 작업 관리 시스템을 만들 수도 있다. 제약은 기술 전문성이 아니라 시간과 주의력이다. 나는 직업이 있고, 삶이 있다. 내가 Sunsama를 사용하는 이유 자체가 작업 관리 소프트웨어를 유지보수하는 사업에 뛰어들고 싶지 않기 때문이다.
이것이 전형적인 SaaS 거래다. 편의성을 얻고, 통제권을 포기한다.
공식 지원이 있든 없든, 나는 그 하찮고 멍청한 작은 위젯을 원했다. 그래서 실제로 만들어 보기로 했다. Codex와 함께 앉아서 이렇게 말했다. iOS Twitter 공유 시트에 버튼 하나를 만들어서, 제대로 라벨링된 트윗-작업을 내 Sunsama에 추가해 줘.
간단하지 않은가? 에이전트는 내가 원하는 것을 즉시 이해했다. 전체 구조도 파악했다. iOS Shortcut이 공유된 URL을 잡고, 작은 서버리스 함수를 호출하고, 그 함수가 트윗 내용을 추출하고, 그것을 LLM에 넘겨 똑똑한 작업 제목을 생성한 다음, 올바른 카테고리와 함께 Sunsama에 작업을 생성하는 구조 말이다.
개념적으로 이것은 20분짜리 프로젝트다. 실제로는, 폐쇄형 소프트웨어의 모든 문제가 무엇인지 보여주는 가이드 투어가 되었다.
계층 1: Sunsama에는 공식 API가 없다. 2026년인데도. API에 대한 그들의 기능 요청 페이지는 2019년 12월부터 열려 있었고, 사용자들은 그것을 애원하고 있다. 최근 한 댓글 작성자는 이렇게 썼다. “창립자들이 정말 거의 6년 동안 이 티켓을 무시해 온 건가요!? 한심하네요.” 그러니 내 에이전트가 아무리 똑똑해도, 작업을 프로그램적으로 생성할 수 있는 공인된 방법은 없다.
하지만 운 좋게도, Robert Niimi라는 Sunsama 사용자가 충분히 답답함을 느껴 Sunsama 내부 API를 리버스 엔지니어링했고, 그 결과를 오픈 소스로 공개했다. sunsama-relay라는 셀프 호스팅 REST API 릴레이와, Claude가 직접 사용할 수 있도록 mcp-sunsama라는 MCP 서버를 만든 것이다. 그래서 내 에이전트는 Sunsama 작업을 생성할 수는 있다. 하지만 그것도 오직 한 집요한 사람이 자기 시간을 들여 인증 흐름을 리버스 엔지니어링하고 결과를 공짜로 공개했기 때문에 가능한 일이다. 그의 작업이 없었다면, 나는 아마 그냥 포기했을 것이다.
계층 2: 인증은 당신의 실제 비밀번호다. 공식 API가 없으니 API 키나 OAuth 토큰도 없다. 비공식 API는 당신의 실제 Sunsama 이메일과 비밀번호로 인증한다. 그러니 내 서버리스 함수는 내 진짜 자격 증명을 저장해야 한다. 이것은 SaaS 모델의 직접적인 결과다. Sunsama는 이 사용 사례를 예상하거나 승인한 적이 없으므로, 안으로 들어가는 유일한 길은 평문 신원을 들고 정문으로 들어가는 것뿐이다.
계층 3: iOS의 벽. 나는 Codex로 서버리스 함수를 만들었다. 트윗 추출, LLM 기반 제목 생성, Sunsama 작업 생성까지 포함했다. 작동했다. 하지만 이제 그것을 iOS Shortcut에 연결해서 Twitter 공유 시트에서 실행할 수 있어야 했다. Codex가 그 iOS Shortcut도 프로그램적으로 만들어 줄 수 있었을까? 아니다. Apple은 개발자가 앱 동작을 노출할 수 있도록 App Intents를 문서화해 두었지만, 임의의 최종 사용자 Shortcut을 프로그램적으로 생성할 수 있는 공개 API나 파일 형식은 문서화해 두지 않았다.[12] 그래서 나는 여전히 Shortcuts를 열고, 시각적 빌더를 탭탭 누르며, 각 동작을 손으로 추가해야 했다. 내 에이전트는 200줄짜리 TypeScript 서버를 몇 초 만에 쓸 수 있지만, 5단계짜리 iOS Shortcut 생성은 자동화할 수 없다. iOS는 (BSD 위에 구축되고 많은 오픈 소스 구성 요소를 사용함에도 불구하고) 자유 소프트웨어의 정반대다.
결과: “작동하는” 해결책이 실제로 요구하는 것은 다음과 같다.
결국, 작동은 한다. 나는 트윗을 공유하고 몇 초 뒤 Sunsama에 제목이 잘 붙은 작업을 받을 수 있고, 실제로 자주 쓰고 있다.
하지만 무엇이 필요했는지 보라.
우회책 여섯 겹, 서로 다른 인증 메커니즘 세 가지, 낯선 사람의 리버스 엔지니어링 프로젝트에 대한 의존성, 이제 내가 책임져야 하는 인프라, 그리고 버전 관리도 공유도 할 수 없는 손수 만든 iOS Shortcut.
이것을 Sunsama와 iOS가 자유 소프트웨어인 경우와 비교해 보자. 에이전트가 소스 코드를 읽고, 작업 데이터 모델을 이해하고, 기본 공유 시트 동작을 내 취향대로 수정하면 끝이다. Codex에게 10분이면 되고, 리버스 엔지니어링도 회색지대 API도 필요 없다.
Stallman의 원래 주장은 진짜로, 정당한 약점 하나를 갖고 있었다. 비판자들이 수십 년 동안 정확히 지적해 온 부분이다. 네 가지 자유 — 실행, 연구, 수정, 재배포 — 는 소스 코드를 읽고 수정할 수 있는 능력을 전제한다. 대다수의 컴퓨터 사용자에게는 그런 능력이 존재하지 않는다.
이 비판은 여러 번 제기되었다. Protesilaos Stavrou는 이를 잘 정리했다. 자유 소프트웨어 라이선스만으로는 사용자가 그 자유를 행사할 전문성이 없을 경우 진정으로 자유로워지지 못하며, 이 운동은 법적 요구사항과 코드에 초점을 좁힘으로써 사실상 기술 애호가들로 청중을 제한하게 되었다는 것이다. Mahmoud Mazouz도 관련된 주장을 했다. 소스 코드가 이용 가능하더라도, 그것을 빌드하고 이해하고 수정하는 실질적 비용은 대부분의 사람에게 너무 높다는 것이다. 네 가지 자유는 프로그래머를 위해 쓰였고, 대부분의 사람은 프로그래머가 아니다.
에이전트는 이것을 완전히 뒤집는다.
AI 코딩 에이전트가 실제로 무엇인지 생각해 보자. 그것은 비기술적 사용자를 대신해 기술적 자유를 행사할 수 있는 중개자다. 당신이 Claude나 Codex에게 “내 작업 관리자가 내가 저장한 트윗을 자동으로 분류하게 해 줘”라고 말할 때, 당신은 대리인을 통해 자유 1, 즉 연구하고 수정할 자유를 행사하고 있는 것이다. 코드베이스를 이해할 필요도 없다. GraphQL 스키마가 뭔지 알 필요도 없다. 원하는 바를 설명하기만 하면 되고, 에이전트가 그 기술적 자유를 대신 행사한다.
이것은 소프트웨어 자유를 추상적 권리에서 실질적 능력으로 연결하는 다리가 된다. 네 가지 자유는 언젠가 누군가가 코드를 읽게 될 것이라는 전제하에 항상 쓰여 있었다. 2026년에 이르러, 마침내 그것을 읽을 수 있는 무언가가 생겼고, 당신을 대신해 그렇게 할 수도 있게 되었다.
이것이 내 Sunsama 상황에 갇힌 비기술적 사람에게 무엇을 의미하는지 생각해 보라. 오늘날 그 사람에게는 선택지가 전혀 없다. 우회책을 코딩할 수도 없고, API를 리버스 엔지니어링할 수도 없다. 기능 요청을 제출하고 6년을 기다릴 수 있을 뿐이다. 그게 전부다. 그 사람과 소프트웨어의 관계는 순전한 의존 관계이며, 소프트웨어가 그 사람에게 필요한 일을 해주지 않으면 그냥… 참고 살아야 한다. 거의 맞지만 완전히 맞지는 않는 딱딱한 SaaS 도구와 싸워 본 사람이라면 누구나 이 감정을 뼛속까지 안다.
이제 그 사람에게 에이전트를 주자. 소프트웨어가 자유롭고 오픈 소스라면, 에이전트는 코드베이스를 읽고, 데이터 모델을 이해하고, 사용자가 필요로 하는 정확한 수정을 해낼 수 있다. 우회책이 아니다. 해킹도 아니다. 한 사람의 구체적 필요에 맞춘, 소프트웨어 동작 방식 자체에 대한 실제 수정이다. 단 한 줄의 코드도 쓸 수 없던 사람이 이제 사실상 최고 수준의 파워 유저가 되는 것이다. 그들의 에이전트가 그렇게 할 수 있기 때문이다.
하지만 소프트웨어가 독점 SaaS라면? 에이전트는 내가 부딪힌 것과 똑같은 벽에 부딪힌다. 소스 코드가 없다. API는 있을 수도 있지만, 거의 확실하게 속도 제한과 제한된 지원 작업이 따라붙는다. 그렇지 않다면 아예 들어갈 길이 없다.
이것은 소프트웨어 자유를 지난 수십 년보다 훨씬 덜 학술적이고 훨씬 더 실질적으로 관련 있는 문제로 만든다. 나에게만 그런 것이 아니다 (그리고 나에게는 매우 중요하다!). 점점 더 모든 사람에게, 기술적으로 숙련된 사람이든 아니든, 그런 문제가 된다. 네 가지 자유는 이론적 권리에서 “내 에이전트가 10분 만에 이 문제를 해결해 줬다”와 “이 바보야, 이 완전한 얼간아. 네가 네 문제를 스스로 해결할 수 있다고 생각하냐?” 사이의 실질적 차이로 바뀐다.
다른 사람들도 이 점들을 연결하기 시작했다. 다만 각도는 조금씩 다르다.
2026년 1월, OneUptime의 Nawaz Dhandala는 AI 에이전트가 어떻게 오픈 소스 소프트웨어에 폐쇄형 대안보다 “극복 불가능한 우위”를 주는지에 대해 썼다. 에이전트는 공급업체가 허용한 API에 제한되지 않고 실제 소스 코드를 읽고, 이해하고, 수정할 수 있기 때문이다. 그의 프레이밍은 유용하다. 이제 질문은 “우리가 이것을 맞춤화할 전문성이 있는가?”가 아니라 “우리가 우리 소프트웨어 스택에 대한 완전한 통제권을 원하는가?”가 된다는 것이다.
Martin Alderson도 비슷한 주장을 했다. 과거에는 돈을 내고 SaaS 도구를 찾았을 많은 것들을, 이제는 에이전트에게 “몇 분 안에, 내가 원하는 정확한 방식으로” 해결하게 한다는 관찰이다. 그는 유지보수 반론도 다루는데 (나는 이것이 중요하다고 생각한다), 즉 에이전트는 유지보수 비용을 극적으로 낮추며, 회사용 내부 도구를 만들고 떠나버린 그 한 명의 엔지니어와 달리 “에이전트는 떠나지 않는다”고 말한다.
John Loeber는 2026년 2월 이 논의를 확장했다. 그는 “사용자 데이터의 대규모 귀환”이 수많은 분절된 서비스에서 한곳으로 일어날 것이라고 예측했다. 데이터를 로컬에 두면 AI가 훨씬 더 유용해지기 때문이다. 그는 이것이 “오픈 소스 가치에 엄청나게 희망적”이며, “독점 소프트웨어에는 약세”라고 불렀다.
심지어 Vitalik Buterin도 의견을 보탰다. 그는 2025년 7월 글에서, 퍼미시브 라이선스를 선호하던 입장에서 카피레프트를 선호하는 쪽으로 옮겨갔다고 썼다. “0이 아닌 수준의 개방성만이 세계가 결국 하나의 행위자가 모든 것을 통제하는 상태로 수렴하지 않게 하는 유일한 방법”이라는 것이다. Ethereum을 만든 사람이 퍼미시브 라이선스에 대한 합의가 틀렸다고 말한다면, 적어도 귀를 기울일 가치는 있다.
그래서 여기서 나는 이렇게 말하고 싶어진다. 답은 분명하고, 우리 모두가 셀프 호스팅 오픈 소스 소프트웨어로 전환해서 우리의 컴퓨팅 자유를 되찾아야 한다고.
하지만 나는 그렇게 말하지 않을 것이다. 실제로 셀프 호스팅을 해본 적이 있고, 그것의 비용이 무엇인지 알기 때문이다.[13]
셀프 호스팅은 보안 업데이트, 백업, SSL 인증서, DNS, 그리고 SaaS 공급업체가 대신 처리해 주는 모든 운영 오버헤드를 당신이 책임진다는 뜻이다. 그리고 나는 이미 시간이 부족하다. 내가 Sunsama를 쓰는 이유 자체가 시간을 더 잘 관리하려는 것이기 때문이다. 할 일 목록에 “셀프 호스팅 인프라 유지보수”를 추가하는 것은 약간 본말이 전도된 일이다.
또 하나, 주목할 만한 불안한 반론도 있다. CEU 관련 2026년 워킹 페이퍼(“Vibe Coding Kills Open Source”)는 바이브 코딩이 사용자-유지관리자 피드백 루프를 끊어 오픈 소스에 해를 끼칠 수 있다고 주장한다.[14] Tailwind CSS의 제작자 Adam Wathan은 Tailwind 사용량이 늘었음에도 2023년 초 이후 문서 트래픽이 약 40% 감소했고, 매출은 약 80% 줄었으며, 엔지니어링 팀의 75%가 방금 해고되었다고 보고했다.[15] Terraform을 만든 Mitchell Hashimoto는 품질 낮은 AI 생성 기여가 밀려드는 데 대응해, 외부 PR을 닫는 것을 고려 중이라고 공개적으로 말했고, 이후 Ghostty를 보증 기반 기여 모델로 옮겼다.[16]
에이전트가 그것을 만들어내는 생태계를 지원하지 않으면서 오픈 소스 소프트웨어를 소비한다면, 전체 구조는 붕괴한다. Stallman의 네 가지 자유는 사용자가 무엇을 받아야 하는지를 말해 준다. 하지만 유지관리자가 무엇을 받아야 하는지에 대해서는 아무 말도 하지 않는다. 그 공백은 어쩌면 자유 그 자체보다 더 중요해질지도 모른다.
그래서 나는 답이 단순히 “모든 것을 다시 직접 돌리자”는 것이라고 생각하지 않는다. SaaS 모델은 실제 문제들을 해결했고, 나는 그 이점을 포기하고 싶지 않다. 그리고 오픈 소스 생태계에는 지속 가능성 문제가 있으며, 에이전트는 그것을 더 좋아지기 전에 더 악화시킬 수도 있다.
내가 생각하는 것은, 자유 소프트웨어의 맞춤화 이점을 유지하면서도 SaaS의 편의성을 보존하는 새로운 모델이 필요하다는 점이다. 그것이 정확히 어떤 모습일지는 아직 모르겠다. 어쩌면 오늘날보다 훨씬 더 급진적으로 개방적이고 확장 가능한 SaaS 제품일 수도 있다. 진짜 플러그인 시스템, 완전한 API 커버리지, 사용자 데이터 위에서 사용자 정의 코드를 실행할 수 있는 능력을 가진 형태 말이다. 아니면 2027년쯤에는 Claude나 Codex가 소프트웨어를 작성하는 것뿐 아니라 호스팅하고 운영하는 것까지 할 수 있게 될지도 모른다.
솔직히 말해, 아직 미정이다. 업계는 아직 이 문제를 풀지 못했다. 하지만 수요는 곧 아주 커질 것이라고 생각한다. 에이전트가 폐쇄형 소프트웨어의 비용을 극도로 눈에 띄게 만들 것이기 때문이다.
또 나는 앞으로 1~2년 사이에 사람들이 소프트웨어를 평가하는 방식에 의미 있는 변화가 나타날 것이라고 생각한다. “내 에이전트가 이것을 완전히 맞춤화할 수 있는가?”는 보통 사람들이 실제로 묻게 되는 질문이 될 것이다. 지금 우리가 “모바일 앱이 있나?” 혹은 “Slack과 연동되나?”를 묻는 것과 같은 방식으로 말이다.
나는 확실히 “전환 비용” 덕분에 계속해서 사용자에게 수상한 UX와 딱딱한 워크플로를 강요할 수 있다고 가정하며 먹고사는 레거시 SaaS의 CTO가 되고 싶지는 않다.
John Gilmore는 유명하게도 “인터넷은 검열을 손상으로 해석하고 그것을 우회한다”고 말했다.[17] 나는 폐쇄형 소프트웨어에 대해서도 이와 비슷한 버전을 곧 보게 될 것이라고 생각한다. 에이전트가 사람들이 도구와 상호작용하는 주된 방식이 되면서, 그들은 비자유 소프트웨어를 손상으로 — 사용자와 사용자가 원하는 것 사이에 놓인 장애물로 — 해석하고 그것을 우회할 것이다. 어떤 때는 그것이 Robert Niimi가 Sunsama에 대해 했던 것처럼 API를 리버스 엔지니어링하는 것을 뜻할 것이다. 어떤 때는 에이전트가 즉석에서 가벼운 오픈 소스 대체물을 만들어 내는 것을 뜻할 것이다. 어떤 때는 단지 사용자를 대신해 “데이터별 다운로드” 같은 GDPR 스타일 요청을 제출하고, 처음부터 완전히 맞춤화된 대체물을 재구축하는 것을 뜻할 것이다.
Upwave의 CTO로서 내 역할에서도, 나는 우리 소프트웨어를 인간이 사용하는 시대가 저물고 있다고 가정하고 있으며, AI 에이전트가 가능한 한 쉽게 통합할 수 있는 능력(그리고 사용자가 선호하는 방식으로 그렇게 할 수 있는 능력)을 구축하는 쪽으로 회사를 이끌고 있다. 우리는 아직 사용자가 우리 서버에서 실행되는 분석 코드나 데이터 파이프라인을 직접 수정하게 할 계획은 없지만, 솔직히… 어쩌면 그래야 할지도 모르겠다.
나는 진정한 “7 powers” 스타일의 해자가 없는 SaaS 회사의 CTO가 되는 것도 절대 원하지 않을 것이다. 강한 네트워크 효과, 독점 데이터셋(Upwave의 강점이다), 규제 포획 같은 것이 말이다. 사용자를 플랫폼에 붙들어 두는 유일한 것이 편의성과 전환 비용이라면, 곤란하다. 에이전트가 전환 비용을 0에 가깝게 붕괴시키려 하고 있기 때문이다.
전체적으로 보아, 나는 자유 소프트웨어의 진자가 다시 흔들리려 한다고 생각한다. 사람들이 갑자기 소프트웨어 자유의 교회로 개종해서가 아니다. 그들은 단지 자기 에이전트가 실제로 자신을 도와주길 원하고, 소프트웨어가 잠겨 있으면 에이전트는 도와줄 수 없기 때문이다.
나는 Sunsama를 정말 좋아한다. 바꾸고 싶지 않다. 하지만 자유롭고 오픈 소스인 소프트웨어였다면 내 에이전트가 내 트윗-투-태스크 문제를 10분 만에 해결할 수 있었으리라는 것을, 아주 구체적으로 볼 수 있게 되었다. 그런데 실제로는 나는 폐쇄된 시스템 여섯 겹 주위에 Rube Goldberg 기계를 짓느라 오후 한나절을 보냈다. 그리고 그것은 내가 어떤 소프트웨어에 의존할 의향이 있는지에 대한 생각을 바꾸어 놓는다.
2075년으로 돌아가, 메카-Ben Franklin은 우리에게 이렇게 상기시켜 주었다.
““필수적인 Liberty를 조금의 일시적 [Operational Hosting Convenience]와 바꾸려는 자는 Liberty도 [Operational Hosting Convenience]도 가질 자격이 없다.”
에이전트형 코딩 시스템의 불가피한 발전이 곧 우리가 더 이상 둘 중 하나를 선택하지 않아도 되는 세상을 만들기를 바란다.
[1] Business Insider, 2026년 3월 23일, Andrej Karpathy의 최근 No Priors 출연과 그가 농담처럼 자신의 과도한 AI 사용을 묘사한 내용을 보도: https://www.businessinsider.com/andrej-karpathy-nervous-ai-tokens-2026-3
[2] 이 역사에서 두드러지게 등장하는 Stallman과 Eric Raymond 모두 내가 옹호하지 않는 개인적 행동의 전력이 있다. 하지만 자유 소프트웨어의 내용과 역사를 논하면서 그들의 역할을 인정하지 않을 수는 없으므로, 여기서는 아이디어와 역사에 집중하고 사람들에 대해서는 각자가 스스로 판단하도록 두겠다.
[3] Open Source Initiative 역사 (“Coining Open Source,” 1998년 2월 3일, Palo Alto; Christine Peterson이 용어 제안): https://opensource.org/history
[4] 1998년 Freeware Summit에 관하여: 참석자 명단, 명명 논쟁, “open source”에 대한 9대 6 투표, Stallman의 비초청, Bruce Perens의 불참 결정은 Sam Williams의 Free as in Freedom, 11장(O’Reilly)에 기록되어 있다: https://www.oreilly.com/openbook/freedom/ch11.html. Wendy Liu 인용 출처: “Freedom Isn’t Free,” Logic Magazine (2018): https://logicmag.io/failure/freedom-isnt-free/
[5] Eric S. Raymond, “Goodbye, ‘free software’; hello, ‘open source'” (1998년 2월): https://www.catb.org/~esr/open-source.html
[6] Stallman의 “오픈 소스는 개발 방법론 / 자유 소프트웨어는 사회 운동”이라는 구도: https://www.gnu.org/philosophy/open-source-misses-the-point.en.html
[7] AWS와의 라이선스 충돌 및 AWS의 대응에 대한 Elastic의 글: https://www.elastic.co/blog/why-license-change-aws 및 https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/
[8] AGPL의 네트워크 사용 논리 / ASP 허점 맥락: https://opensource.org/blog/gnu-affero-gpl-version-3-and-the-asp-loophole
[9] 라이선스 추세 증거의 예시: RedMonk (2013) “Quantifying the shift toward permissive licensing” https://redmonk.com/dberkholz/2013/04/02/quantifying-the-shift-toward-permissive-licensing/ 및 Revenera 2021 컴플라이언스 보고서 요약(스캔된 코드베이스에서 퍼미시브 라이선스가 다수): https://www.revenera.com/about-us/press-center/revenera-releases-2021-findings-on-open-source-license-compliance
[10] Google의 AGPL 정책(공개적으로 문서화된 내부 금지): https://opensource.google/docs/using/agpl-policy/
[11] 라이선스 변경 출처: MongoDB SSPL 발표 https://www.mongodb.com/company/newsroom/press-releases/mongodb-issues-new-server-side-public-license-for-mongodb-community-server ; Redis 모듈/Commons Clause (2018) https://redis.io/blog/redis-labs-modules-license-changes ; Redis 이중 source-available (2024) https://redis.io/blog/redis-adopts-dual-source-available-licensing ; Redis의 AGPL 추가 (2025) https://redis.io/blog/agplv3/ ; HashiCorp BSL (2023) https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license ; Elastic의 2021년 및 2024년 라이선스 게시물 https://www.elastic.co/blog/licensing-change 및 https://www.elastic.co/blog/elasticsearch-is-open-source-again
[12] Apple App Shortcuts/App Intents 문서: https://developer.apple.com/documentation/appintents/app-shortcuts
[13] 나는 한때 Megabus의 제한적인 게스트 와이파이를 우회하는 방법에 대한 블로그 글 전체를 쓴 적이 있다. EC2 인스턴스를 가난한 사람의 VPN처럼 설정하는 방식이었다. 내 유일한 준바이럴 게시물이었다. 나는 셀프 호스팅 라이프스타일을 권하지 않는다.
[14] “Vibe Coding Kills Open Source” (CEU 관련 저자들, 2026): https://arxiv.org/html/2601.15494v1
[15] Adam Wathan 2026년 1월 GitHub 댓글 (트래픽, 매출, 엔지니어링 팀 해고): https://api.github.com/repos/tailwindlabs/tailwindcss.com/issues/comments/3717222957
[16] Mitchell Hashimoto가 외부 PR 폐쇄를 고려 중이라고 말한 글: https://x.com/mitchellh/status/2018458123632283679 및 Ghostty의 병합된 보증 기반 모델 PR: https://github.com/ghostty-org/ghostty/pull/10559
[17] John Gilmore 인용문의 역사적 출처: https://quoteinvestigator.com/2021/07/12/censor/
게시 위치 블로그태그 ai, programming
이전 글 Claude Code를 WordPress에 연결하기: 공유 마찰 낮추기
이메일 주소는 공개되지 않습니다.필수 입력 항목은 * 로 표시됩니다.
댓글 *
이름 *
이메일 *
웹사이트
Δ
검색:
WordPress로 자랑스럽게 제공 | 테마: Libre, 제작 Automattic.
