코딩 에이전트가 무료 소프트웨어를 다시 중요하게 만들 수 있다

source https://www.gjlondon.com/blog/ai-agents-could-make-free-software-matter-again/

굉장히 재밌는 글이네요. 점심시간에 쭉 읽어보시는거 추천드림!!

나는 요즘 바이브 코딩을 정말 많이 하고 있다. 정말, 엄청나게 많이. 최근 Andrej Karpathy가 No Priors 에서 농담처럼 말한 "AI psychosis" 수준까지는 아닐지 몰라도, 아주 멀리 떨어져 있지도 않다. 그런데 바이브 코딩을 할수록 한 가지 생각이 자꾸 떠오른다. AI 코딩 에이전트가 자유 소프트웨어를 그 어느 때보다 중요하게 만들기 직전일 수 있다는 생각이다. 여기서 말하는 건 기업들이 무난하게 쓰는 의미의 오픈소스가 아니다. Stallman이 말한 의미의 자유 소프트웨어다. 사용자가 소프트웨어를 실행하고, 연구하고, 수정하고, 공유할 자유를 주는 소프트웨어 말이다.

이 차이를 아는 사람이 상대적으로 많지 않았던 데다, 설령 알더라도 오랫동안 다소 학술적인 구분처럼 느껴졌다. SaaS가 등장하면서 소프트웨어 자유에 관심을 갖기 더 어려워졌기 때문이다. 대부분의 사람은 자신이 의존하는 소프트웨어의 소스 코드를 애초에 보지도, 만지지도 못했다. 코드는 남의 서버에 있었고, 운영은 벤더가 맡았다. 그래서 현실적인 질문은 자유가 아니라 편의성이 됐다.

하지만 에이전트는 이 상황을 바꾼다. 에이전트가 코드베이스를 읽고, 이해하고, 대신 수정해줄 수 있다면, 소스 코드 접근권은 더 이상 프로그래머만의 상징적 권리가 아니다. 훨씬 더 많은 사람에게 실질적인 능력이 된다. 갑자기, 직접 바꿀 수 있는 소프트웨어와 사정만 해야 하는 소프트웨어의 차이가 정말로 중요해진다.

이건 단순한 추상이 아니다. 최근 나는 AI 에이전트에게 SaaS 앱을 내 용도에 맞게 커스터마이즈하게 해보려 했고, 그 경험은 이 문제가 얼마나 현실적인지 아주 빠르게 보여줬다.

한때 절실했던 자유 소프트웨어, SaaS 시대에 밀려 의미를 잃다

1980년, Richard Stallman은 MIT AI Lab의 프로그래머였고 프린터 문제를 겪고 있었다. 연구실에 새 Xerox 레이저 프린터가 들어왔는데, 계속 용지 걸림이 발생했다. Stallman은 이 문제를 고치고 싶었다. 적어도 출력 작업이 막혔을 때 사용자에게 알려주는 기능이라도 넣고 싶었다. 하지만 Xerox는 소스 코드를 주지 않았다. 그 프린터 소프트웨어는 독점 소프트웨어였다.

겉보기에는 사소한 일처럼 보인다. 하지만 Stallman에게는 전혀 사소하지 않았다.

그는 코드 공유가 당연한 문화 속에서 성장했다. 소프트웨어를 받으면 소스 코드도 함께 받는 게 당연했다. 물론 그래야 하지 않겠는가. 버그를 고치고 기능을 추가하려면 그 외에 무슨 방법이 있겠는가? Xerox 프린터 사건은 그에게 한 가지를 선명하게 각인시켰다. 자신이 의존하는 도구를 연구하거나 수정할 수 없는, 소프트웨어가 잠겨 있는 세계는 사용자가 근본적인 무언가를 잃어버린 세계라는 점이다.

그래서 Stallman은 Free Software Foundation을 설립했고, 이후 40년 동안 자신이 말한 "네 가지 자유"를 전파하는 데 힘썼다.

Freedom 0: 원하는 목적을 위해 프로그램을 실행할 자유
Freedom 1: 프로그램이 어떻게 동작하는지 연구하고, 원하는 대로 바꿀 자유
Freedom 2: 다른 사람을 도울 수 있도록 사본을 재배포할 자유
Freedom 3: 자신이 수정한 버전의 사본을 다른 사람에게 배포할 자유

그는 이렇게 말하곤 했다. "맥주처럼 공짜가 아니라, 표현의 자유에서의 자유다."

한동안 이 메시지는 힘을 가졌다. 1990년대에는 Linux, Apache, MySQL, PHP 등 자유 소프트웨어가 폭발적으로 성장했다. 인터넷 대부분을 떠받치게 되는 전체 스택이 여기에 있었다. Red Hat 같은 회사는 이 위에서 실제 비즈니스를 만들 수 있다는 걸 보여줬다. Eric Raymond는 "The Cathedral and the Bazaar"를 쓰며 개방형 개발이 더 나은 소프트웨어를 만든다고 주장했다. Microsoft의 Steve Ballmer는 Linux를 "암"이라고 불렀다. 컴퓨팅의 영혼을 둘러싼 진짜 이념 전쟁처럼 보이던 시절이었다.

그러다 어느 순간, 꽤 따분한 이유로 그 전쟁은 의미를 잃었다.

하지만 그 이야기는 잠시 뒤로 미루자.

"오픈소스"라는 리브랜딩은 코드 공유는 남기고 사용자 권리 철학은 덜어냈다

먼저, 이 글을 조사하면서 나도 처음 알게 된 역사적 사실 하나를 짚고 가자. 지금 벌어지는 일을 이해하는 데 중요하다.

1998년 2월 3일, 한 무리의 사람들이 팔로알토의 Foresight Institute에 모였다. 소프트웨어 단체가 아니라 나노기술 싱크탱크였다. 이 연구소의 사무총장 Christine Peterson은 "free software" 대신 새로운 표현인 "open source"를 쓰자고 제안했다.이유는 실용적이었다. "free software"라고 말할 때마다 사람들이 무료 소프트웨어로 오해했고, 실제 소프트웨어 이야기를 하기 전에 그 차이를 설명하느라 10분을 써야 했기 때문이다.

몇 주 뒤인 1998년 4월 Tim O'Reilly의 "Freeware Summit"에서는 참석자들이 명칭을 두고 토론했고, "sourceware"나 "free software" 같은 대안 대신 "open source"를 9대 6으로 선택했다.

여기서 중요한 건, 이 리브랜딩 과정에서 무엇이 사라졌느냐는 점이다. 같은 달 Eric Raymond와 Bruce Perens는 Open Source Initiative를 공동 설립했고, Raymond는 "Goodbye, 'free software'; hello, 'open source.'"라는 선언문을 발표했다. 그의 핵심 주장은 이랬다. 기존 용어는 기업 쪽 사람들을 불안하게 만든다는 것이다.

Stallman은 1998년 4월 Tim O'Reilly의 "Freeware Summit"에 초대받지 못했다. 새로운 리더십 서사를 굳히는 데 큰 역할을 한 행사였다. Linus Torvalds는 초대받았다. Larry Wall도 초대받았다. Guido van Rossum도 초대받았다. Stallman만 초대받지 못했다.

왜 이게 중요할까? "오픈소스"로의 리브랜딩은 단순한 마케팅 변경이 아니었기 때문이다. 그것은 철학의 절단에 가까웠다. "오픈소스"는 코드 공유 관행은 유지했지만, 사용자가 무엇을 누릴 자격이 있는가라는 윤리적 주장은 정교하게 도려냈다. Stallman의 말처럼 "오픈소스는 개발 방법론이고, 자유 소프트웨어는 사회운동"이다. Raymond 역시 "free software"라는 표현이 혼란을 일으키고 기업들을 불편하게 만든다고 분명히 말했다.

기업 세계는 이를 반겼다. 사용자에게 무엇을 빚지고 있는가라는 질문과 마주하지 않아도, 오픈소스 코드를 쓰고, 오픈소스 프로젝트에 기여하고, 오픈소스 브랜드 정체성을 구축할 수 있었기 때문이다. 오픈소스는 기업이 사용자와의 관계를 전혀 바꾸지 않고도 채택할 수 있는 개발 방법론이 됐다.

SaaS는 라이선스의 허점을 파고들어 수정 사항 공유를 피한 채 성장했다

하지만 자유 소프트웨어를 주류에서 밀어낸 것은 정치나 철학 논쟁이 아니었다. SaaS였다.

자유 소프트웨어의 핵심 라이선스인 GPL은 소프트웨어를 배포받는 사람에게 소스 코드를 함께 제공하도록 요구했다. 여기서 핵심 단어는 "배포"다. 소프트웨어를 배포하지 않고, 자기 서버에서만 돌리면서 웹을 통해 접근만 허용한다면 라이선스는 적용되지 않았다. 자유 소프트웨어를 가져와 수정하고, 그 위에서 비즈니스를 만들면서도, 그 수정 사항을 누구와도 공유하지 않을 수 있었다.

이건 가정이 아니었다. 대표적 사례로는 AWS가 Elasticsearch 같은 프로젝트를 기반으로 관리형 서비스를 제공한 일이 있다. 이 일은 가치 포착, 기여, 라이선스 조건을 둘러싼 공개적 논쟁으로 이어졌다. SaaS 모델에서는 소프트웨어를 배포하지 않는 한 GPL의 카피레프트 의무가 발동하지 않는 경우가 많기 때문에, 소스 공유 요구를 비껴갈 수 있다.

이후 무슨 일이 벌어졌는지는 숫자가 말해준다. 2010년대를 지나 2020년대로 오면서 오픈소스 사용 데이터에서 퍼미시브 라이선스의 비중은 점점 더 커졌다.

이를 고치려는 시도도 있었다. AGPL(Affero GPL)은 SaaS의 허점을 막기 위해 설계됐다. AGPL 소프트웨어를 수정한 뒤 네트워크를 통해 제공하면 소스 코드를 공개해야 했다. 강력한 발상이었다. 실제로 Google은 오늘날 Google 내부에서 AGPL 코드를 금지하는 광범위한 공개 정책을 유지하고 있다. Drew DeVault의 주장대로라면,

Google의 반 AGPL 입장은 단순한 법적 예방책이 아니라 전략이었다.

"더 넓은 커뮤니티에서 AGPL 사용을 꺼리게 함으로써 Google은 아무 의무 없이 자사 필요에 맞게 가져다 쓸 수 있는 자유 소프트웨어와 오픈소스 소프트웨어의 풀을 더 크게 만들고자 한다."

AGPL의 제한적인 채택은 이후 즉흥적 대안의 연쇄를 낳았다. MongoDB는 Server Side Public License로 전환했다. Redis Labs는 2018년 여러 Redis 모듈을 Commons Clause 계열 라이선스로 옮겼고, Redis 역시 나중에 핵심 Redis를 이중 소스 공개 라이선스로 바꾼 뒤 Redis 8에서 AGPL을 추가했다. HashiCorp는 Terraform을 Business Source License로 전환했다. Elastic은 Apache에서 SSPL/ELv2로 옮긴 뒤 다시 AGPL을 추가했다. 이런 전환은 모두 근본 문제를 확인해줬지만, 완전히 해결하지는 못했다.

그리고 솔직히 말해 사용자 관점에서는 소프트웨어 자유라는 질문 자체가 더 이상 중요하지 않게 됐다. 소프트웨어가 남의 서버에서 돌아가면 소스 코드를 갖고 있어도 별 도움이 되지 않기 때문이다. 수정한 버전을 직접 돌릴 수가 없다. 애초에 어떤 버전이든 내가 돌리는 게 아니기 때문이다. Salesforce가 돌리고, Google이 돌리고, 또 누군가가 돌린다. 네 가지 자유는 이론이 돼버렸다.

한동안은 이런 교환이 괜찮아 보였다. SaaS는 압도적으로 편리했다. 설치할 필요도 없고, 업데이트는 자동이며, 어디서든 접속할 수 있고, 보안 패치와 백업, 서버가 새벽 3시에 죽었을 때의 대응도 다른 누군가가 맡아준다. 그래서 자유 소프트웨어 논쟁은 서서히 배경으로 밀려났다. 추가 완전히 편의성 쪽으로 기울었고, 나를 포함한 대부분은 그 거래를 받아들였다.

그러다 AI가 등장하면서 나는 그 선택을 후회하기 시작했다.

내 Sunsama 워크플로는 의욕 있는 사용자조차 막아서는 폐쇄형 SaaS의 한계를 보여준다

나는 작업 관리에 Sunsama를 쓴다. 좋은 제품이고, 실제로 만족스럽게 사용하고 있다. 하지만 내가 만들고 싶은 워크플로 하나가 있었고, Sunsama는 그걸 사실상 불가능하게 만들고 있었다.

워크플로는 단순하다. Twitter를 스크롤하다가 나중에 반응하거나 살펴보고 싶은 트윗을 보면, 그러니까 나중에 읽고 싶은 기사이든, 서부 개척 광부 분위기의 정신 나간 AI 툴이든, 그걸 Sunsama에 작업으로 저장해두고 싶다. 그래야 언젠가 하게 될 다른 20억 가지 일들 사이에서 일정을 잡을 수 있기 때문이다.

Sunsama에는 iOS 공유 시트 연동이 있지만, iOS에서는 그 기능이 여러 번 탭해야 하는 깊숙한 곳에 숨어 있고, 작동 방식도 마음에 들지 않는다:

첫째, 이렇게 만들어지는 작업은 사실상 URL 하나에 iOS가 트윗에서 끌어온 제목만 붙는 수준이다. 기본 공유 동작이 만들어내는 "tweet from @dril" 같은 허접한 제목 대신, LLM이 "미디어 측정 관련 질문에 @누구누구에게 답글 달기" 같은 작업 제목을 생성해주면 얼마나 좋겠는가.

둘째, 이 작업들에 라벨을 붙이거나 분류하는 것도 자동화할 수 없다. 건강 관련 트윗은 #health 카테고리로, 채용 관련 트윗은 #recruiting으로 들어가길 원한다. 하지만 공유 시트는 모든 걸 그저 내 inbox에 던져 넣을 뿐이다.

하지만 내 선호는 중요하지 않다. Sunsama가 제품에 넣어주기로 한 기능 외에는, 이 워크플로에 LLM 기반 지능을 추가할 방법이 없기 때문이다. Sunsama 팀이 작업 자동 분류 AI 기능을 출시하면 좋다. 출시하지 않으면 나는 방법이 없다. 기능 요청을 넣고 2032년에 다시 확인해보는 수밖에 없다.

이건 역량의 문제가 아니다. 나는 코드를 안다. 마음만 먹으면 작업 관리 시스템을 처음부터 직접 만들 수도 있다. 제약은 기술 전문성이 아니라 시간과 주의력이다. 나는 직업이 있고, 삶이 있다. 내가 Sunsama를 쓰는 이유 자체가 작업 관리 소프트웨어를 유지보수하는 일을 하고 싶지 않아서다.

이게 전형적인 SaaS 거래다. 편의성을 얻는 대신 통제권을 포기한다.

그래도 워크플로를 만들어보려 했고, 닫힌 레이어 하나하나가 단순한 아이디어를 위태로운 해킹으로 바꿔놨다

공식 지원 여부와 상관없이, 나는 그 하찮은 작은 위젯이 갖고 싶었다. 그래서 실제로 만들어보기로 했다. Codex 앞에 앉아 이렇게 말했다. iOS Twitter 공유 시트에 버튼 하나를 만들고, 누르면 적절한 라벨이 붙은 트윗 작업이 Sunsama에 추가되게 해달라고.

간단해 보이지 않는가? 에이전트는 내가 원하는 바를 즉시 이해했다. 전체 구조도 한눈에 파악했다. iOS Shortcut이 공유된 URL을 받아 작은 서버리스 함수를 호출하고, 그 함수가 트윗 내용을 추출한 뒤 LLM에 넘겨 똑똑한 작업 제목을 만들고, 마지막으로 올바른 카테고리로 Sunsama에 작업을 생성하는 식이다.

개념적으로는 20분짜리 프로젝트다. 하지만 실제로는 폐쇄형 소프트웨어의 문제를 하나씩 체험하는 가이드 투어가 됐다.

1단계: Sunsama에는 공식 API가 없다. 2026년인데도 말이다. API를 요청하는 그들의 feature request page는 2019년 12월부터 열려 있었고, 사용자들은 거기서 API를 만들어달라고 애원하고 있다. 최근 한 댓글 작성자는 "창업자들이 정말 거의 6년 동안 이 티켓을 무시해온 건가요!? 한심하네요"라고 썼다. 그러니 내 에이전트가 아무리 똑똑해도, 작업을 프로그래밍 방식으로 생성할 공식 경로는 없다.

다행히도 Robert Niimi라는 Sunsama 사용자가 충분히 답답함을 느낀 끝에 Sunsama 내부 API를 리버스 엔지니어링했고, 그 결과를 오픈소스로 공개했다. sunsama-relay라는 self-hosted REST API relay와, Claude가 직접 쓸 수 있도록 만든 mcp-sunsama라는 MCP server다. 덕분에 내 에이전트도 Sunsama 작업을 만들 수는 있다. 하지만 그건 한 집요한 사람이 자기 시간을 들여 인증 흐름을 리버스 엔지니어링하고 그 결과를 무료로 공개했기 때문이다. 그의 작업이 없었다면 나는 아마 그냥 포기했을 것이다.

2단계: 인증 수단이 실제 비밀번호다. 공식 API가 없으니 API 키도, OAuth 토큰도 없다. 비공식 API는 실제 Sunsama 이메일과 비밀번호로 인증한다. 즉, 내 서버리스 함수는 내 진짜 자격 증명을 저장해야 한다. 이것도 SaaS 모델의 직접적인 결과다. Sunsama는 이런 사용 사례를 예상하지도, 공식적으로 허용하지도 않았기 때문에, 들어가는 유일한 방법은 평문 수준의 내 신원을 들고 정문으로 들어가는 것뿐이다.

3단계: iOS의 벽. 나는 Codex로 서버리스 함수를 만들었다. 트윗 추출, LLM 기반 제목 생성, Sunsama 작업 생성까지 포함해서. 실제로 동작도 했다. 하지만 이제 Twitter 공유 시트에서 실행할 수 있도록 이걸 iOS Shortcut과 연결해야 했다. Codex가 iOS Shortcut을 프로그램으로 생성해줄 수 있었을까? 아니다. Apple은 개발자가 앱 동작을 노출할 수 있도록 App Intents를 문서화해뒀지만, 임의의 최종 사용자 Shortcut을 프로그램으로 생성할 수 있는 공개 API나 파일 형식은 문서화해 제공하지 않는다. 그래서 나는 여전히 Shortcuts 앱을 열고, 비주얼 빌더를 탭해가며, 각 액션을 하나씩 수동으로 추가해야 했다. 내 에이전트는 200줄짜리 TypeScript 서버를 몇 초 만에 쓸 수 있지만, 5단계짜리 iOS Shortcut 하나는 자동화하지 못한다. iOS는 BSD 위에 구축됐고 많은 오픈소스 구성 요소를 쓰고 있음에도, 자유 소프트웨어와는 정반대에 있는 시스템이다.

결과적으로 "동작하는" 솔루션이 실제로 요구하는 것은 이렇다.

내가 직접 배포하고 호스팅해야 하는 서버리스 함수
제목 생성을 위한 Anthropic API 키
환경 변수에 저장된 내 실제 Sunsama 비밀번호
언제든 깨질 수 있는 비공식 리버스 엔지니어링 API에 대한 의존성
내가 손으로 직접 만든 iOS Shortcut(게다가 iOS에서 shortcut 액션이 계속 불투명한 오류 메시지와 접근 불가능한 로그만 남긴 채 실패해서, 터무니없을 정도로 고통스러운 디버깅을 거친 뒤에야 만들 수 있었다)
트윗 임베드 메타데이터를 가져오기 위한 Twitter/X의 oEmbed 엔드포인트

결국 이건 동작한다. 트윗을 공유하면 몇 초 뒤 Sunsama에 제목이 잘 붙은 작업이 생기고, 나는 이미 이 기능을 꾸준히 쓰고 있다.

하지만 그 대가를 보라.

우회책 여섯 겹, 서로 다른 인증 메커니즘 세 가지, 낯선 사람의 리버스 엔지니어링 프로젝트에 대한 의존성, 이제 내가 책임져야 하는 인프라, 그리고 버전 관리도 공유도 할 수 없는 수작업 iOS Shortcut이 필요했다.

이걸 Sunsama와 iOS가 자유 소프트웨어인 경우와 비교해보자. 에이전트가 소스 코드를 읽고, 작업 데이터 모델을 이해한 뒤, 기본 공유 시트 동작을 내 취향에 맞게 수정하면 끝이다. Codex에게 10분이면 된다. 리버스 엔지니어링도 없고, 회색지대 API도 필요 없다.

AI 에이전트는 이제 코딩하지 못하는 사람을 대신해 소프트웨어 자유를 행사할 수 있다

Stallman의 원래 주장은 분명 실제적이고 정당한 약점이 있었다. 비판자들이 수십 년간 정확히 지적해온 부분이다. 실행하고, 연구하고, 수정하고, 재배포하는 네 가지 자유는 소스 코드를 읽고 수정할 수 있는 능력을 전제로 한다. 하지만 대다수 컴퓨터 사용자에게 그런 능력은 없다.

이 비판은 여러 차례 제기돼 왔다. Protesilaos Stavrou는 이를 설득력 있게 정리했다. 자유 소프트웨어 라이선스만으로는 사용자가 진정으로 자유로워지지 못한다. 그 자유를 실제로 행사할 전문성이 없기 때문이다. 결국 이 운동은 법적 요구사항과 코드에 초점을 좁혔고, 사실상 대상 독자를 기술 애호가로 한정해버렸다. Mahmoud Mazouz도 비슷한 주장을 했다. 소스 코드가 공개돼 있어도, 그것을 빌드하고 이해하고 수정하는 실제 비용은 대부분의 사람에게 너무 크다는 것이다. 네 가지 자유는 프로그래머를 위해 쓰였고, 대부분의 사람은 프로그래머가 아니다.

하지만 에이전트는 이 구도를 완전히 뒤집는다.

AI 코딩 에이전트가 실제로 무엇인지 생각해보라. 비기술 사용자를 대신해 기술적 자유를 행사할 수 있는 중개자다. Claude나 Codex에게 "내 작업 관리자가 저장한 트윗을 자동 분류하게 해줘"라고 말하는 순간, 당신은 대리인을 통해 Freedom 1, 즉 연구하고 수정할 자유를 행사하는 셈이다. 코드베이스를 이해할 필요도 없다. GraphQL 스키마가 무엇인지 알 필요도 없다. 원하는 바를 설명하기만 하면, 에이전트가 그 기술적 자유를 대신 행사한다.

이건 소프트웨어 자유를 추상적 권리에서 실질적 능력으로 이어주는 다리다. 네 가지 자유는 항상 언젠가 누군가가 코드를 읽을 것처럼 쓰여 있었다. 그리고 2026년, 마침내 그것을 읽을 수 있는 무언가가 생겼고, 당신을 대신해 행동할 수도 있게 됐다.

내가 겪은 Sunsama 같은 상황에 갇힌 비기술 사용자를 생각해보자. 지금 그들에게는 선택지가 없다. 우회책을 코딩할 수도 없고, API를 리버스 엔지니어링할 수도 없다. 기능 요청을 넣고 6년을 기다리는 것뿐이다. 그게 전부다. 이들이 소프트웨어와 맺는 관계는 순전한 의존이다. 소프트웨어가 자신에게 필요한 일을 해주지 않으면, 그냥... 참고 살아야 한다. 거의 맞지만 딱 맞지는 않는 경직된 SaaS 도구와 씨름해본 사람이라면 이 감각을 뼛속까지 안다.

이제 그 사람에게 에이전트를 줘보라. 소프트웨어가 자유롭고 오픈소스라면, 에이전트는 코드베이스를 읽고, 데이터 모델을 이해하고, 사용자가 필요로 하는 정확한 수정을 해낼 수 있다. 우회책이 아니다. 꼼수가 아니다. 한 사람의 구체적인 필요에 맞춘, 소프트웨어 동작 방식 자체의 실제 수정이다. 단 한 줄의 코드도 쓸 수 없던 사람이 사실상 최고 수준의 파워 유저가 되는 것이다. 그의 에이전트가 그렇게 될 수 있기 때문이다.

반대로 소프트웨어가 독점형 SaaS라면 어떤가? 에이전트는 내가 부딪힌 바로 그 벽에 막힌다. 소스 코드가 없다. API가 있을 수도 있지만, 거의 확실하게 rate limit이 걸려 있고 지원하는 작업도 제한적일 것이다. 그 외에는 들어갈 길이 없다.

이 때문에 소프트웨어 자유는 예전보다 훨씬 덜 학술적이고, 훨씬 더 실질적인 문제가 됐다. 나에게만 그런 것이 아니다. 물론 나에게는 매우 중요하다. 하지만 점점 더 모든 사람에게, 기술 숙련도와 상관없이 중요해지고 있다. 네 가지 자유는 더 이상 이론적 권리가 아니라, "내 에이전트가 10분 만에 해결해줬다"와 "이 멍청한 바보야. 네 문제를 네가 직접 해결할 수 있을 거라고 생각했나?" 사이를 가르는 실질적 차이가 된다.

에이전트가 개방성의 가치를 높인다는 징후는 이미 여러 사상가의 논의에서 드러난다

다른 사람들도 서로 다른 각도에서 이 점들을 연결하기 시작했다.

2026년 1월, OneUptime의 Nawaz Dhandala는 글을 통해 AI 에이전트가 오픈소스 소프트웨어에 폐쇄형 대안 대비 "넘을 수 없는 우위"를 부여한다고 주장했다. 에이전트는 공급업체가 허용한 API에만 묶이지 않고 실제 소스 코드를 읽고, 이해하고, 수정할 수 있기 때문이라는 것이다. 이 문제 제기는 유용하다. 이제 질문은 "이걸 우리 입맛에 맞게 고칠 전문성이 있나?"가 아니라 "우리 소프트웨어 스택을 완전히 통제하길 원하는가?"가 됐다.

Martin Alderson도 비슷한 주장을 펼쳤다. 예전 같으면 돈을 내고 SaaS 도구를 찾았을 많은 일들을 이제는 에이전트에게 맡겨 "몇 분 안에, 내가 원하는 정확한 방식으로" 해결한다고 했다. 그는 또 중요한 반론인 유지보수 문제도 짚는다. 즉, 에이전트는 유지보수 비용을 극적으로 낮추며, 사내 도구를 만들어 놓고 회사를 떠나버린 어느 엔지니어와 달리 "에이전트는 떠나지 않는다"는 것이다.

John Loeber는 2026년 2월 이 논의를 확장하며 "수많은 파편화된 서비스에 흩어진 사용자 데이터가 한곳으로 되돌아오는 대규모 회귀"를 예측했다. 데이터를 로컬에 둘수록 AI의 효용이 극적으로 커지기 때문이라는 설명이다. 그는 이를 두고 "오픈소스의 가치에는 엄청나게 희망적"이고, "독점 소프트웨어에는 부정적"이라고 평가했다.

심지어 Vitalik Buterin도 이 논의에 가세했다. 그는 2025년 7월, 허용적 라이선스를 선호하던 입장에서 카피레프트 지지로 돌아섰다고 밝히며, "어느 한 주체가 결국 모든 것을 통제하는 방향으로 세계가 수렴하지 않게 만드는 유일한 길은, 어느 정도든 개방성을 유지하는 것"이라고 썼다. 이더리움을 만든 사람이 허용적 라이선스에 대한 기존 합의가 틀렸다고 말한다면, 적어도 귀 기울일 가치는 있다.

추세가 다시 개방적인 방향으로 돌아설 수는 있겠지만, 편의성과 유지보수 비용 문제는 여전히 중요한 요소로 남아 있다

여기서 "답은 분명하다, 이제 모두 self-hosted 오픈소스 소프트웨어로 갈아타고 컴퓨팅의 자유를 되찾자"고 말하고 싶을 수도 있다.

하지만 나는 그렇게 말하지 않겠다. 실제로 self-hosting을 해본 적이 있고, 그 대가가 무엇인지 알기 때문이다.

self-hosting은 보안 업데이트, 백업, SSL 인증서, DNS, 그리고 SaaS 벤더가 대신 처리해주던 온갖 운영 부담을 직접 책임진다는 뜻이다. 그리고 나는 이미 시간이 부족하다. 내가 Sunsama를 쓰는 이유 자체가 시간을 더 잘 관리하기 위해서다. 할 일 목록에 "내 self-hosted 인프라 유지관리"를 추가하는 건 애초의 목적을 꽤 무색하게 만든다.

주목할 만한 불편한 반론도 있다. CEU 관련 2026년 워킹페이퍼인 "Vibe Coding Kills Open Source"는 바이브 코딩이 사용자와 유지관리자 사이의 피드백 루프를 끊어 오픈소스를 해칠 수 있다고 주장한다. Tailwind CSS의 창시자 Adam Wathan은 Tailwind 사용은 늘었는데도 2023년 초 이후 문서 트래픽이 약 40% 줄었고, 매출은 약 80% 감소했으며, 엔지니어링 팀의 75%를 막 해고했다고 밝혔다. Terraform을 만든 Mitchell Hashimoto는 AI가 생성한 저품질 기여가 쏟아지자 외부 PR을 닫는 방안을 검토하고 있다고 공개적으로 말한 뒤, Ghostty를 보증 기반 기여 모델로 전환했다.

에이전트가 오픈소스 소프트웨어를 소비만 하고 그 생태계를 떠받치는 주체들을 지원하지 않는다면, 결국 시스템 전체가 무너진다. Stallman의 네 가지 자유는 사용자가 무엇을 누려야 하는지는 말해준다. 하지만 유지관리자가 무엇을 보장받아야 하는지는 말해주지 않는다. 어쩌면 그 공백이 자유 그 자체보다 더 중요해질 수도 있다.

그래서 내 생각에 답은 단순히 "다시 모든 걸 직접 운영하자"가 아니다. SaaS 모델은 실제 문제들을 해결했고, 나는 그 이점을 포기하고 싶지 않다. 게다가 오픈소스 생태계에는 지속가능성 문제가 있고, 에이전트는 그것을 나아지게 만들기 전에 먼저 더 악화시킬 수도 있다.

내가 생각하는 방향은, 자유 소프트웨어의 커스터마이징 이점을 유지하면서 SaaS의 편의성도 보존하는 새로운 모델이 필요하다는 것이다. 그것이 정확히 어떤 모습일지는 아직 모르겠다. 어쩌면 지금보다 훨씬 더 개방적이고 확장 가능한 SaaS 제품일 수도 있다. 진짜 플러그인 시스템, 완전한 API 커버리지, 그리고 내 데이터 위에서 커스텀 코드를 실행할 수 있는 능력을 갖춘 형태 말이다. 아니면 2027년쯤에는 Claude나 Codex가 소프트웨어를 작성하는 것뿐 아니라 호스팅하고 운영하는 것까지 해낼지도 모른다.

솔직히 말하면 아직 TBD다. 업계도 아직 답을 찾지 못했다. 하지만 수요는 곧 아주 크게 터져 나올 것이라고 본다. 에이전트가 폐쇄형 소프트웨어의 비용을 극도로 선명하게 드러내기 시작할 것이기 때문이다.

다음 소프트웨어 구매 기준은, 내 에이전트가 이 소프트웨어를 실제로 내 필요에 맞게 바꿀 수 있느냐가 될 것이다.

또 앞으로 1~2년 사이 사람들의 소프트웨어 평가 방식에 의미 있는 변화가 생길 것이라고 본다. "내 에이전트가 이걸 완전히 커스터마이즈할 수 있나?"는 지금 우리가 "모바일 앱이 있나?" 또는 "Slack과 연동되나?"를 묻듯, 일반 사용자도 실제로 던지는 질문이 될 것이다.

특히 "전환 비용" 덕분에 계속해서 불안한 UX와 경직된 워크플로를 사용자에게 강요할 수 있다고 믿는 레거시 SaaS의 CTO가 되는 일은 결코 바라지 않을 것이다.

John Gilmore는 "인터넷은 검열을 손상으로 해석하고 그것을 우회한다"고 유명하게 말했다. 나는 곧 폐쇄형 소프트웨어에서도 이와 비슷한 일이 벌어질 것이라고 본다. 에이전트가 사람들이 도구와 상호작용하는 주된 방식이 되면, 에이전트는 비자유 소프트웨어를 사용자와 사용자가 원하는 것 사이에 놓인 장애물, 즉 손상으로 해석하고 그것을 우회하려 할 것이다. 때로는 Robert Niimi가 Sunsama를 위해 했듯 API를 리버스 엔지니어링하는 방식이 될 것이다. 때로는 에이전트가 그 자리에서 가벼운 오픈소스 대체재를 만들어낼 수도 있다. 또 어떤 경우에는 사용자를 대신해 "데이터를 내려달라"는 GDPR식 요청을 제출하고, 처음부터 완전히 맞춤형 대체 시스템 전체를 재구축하는 방식이 될 수도 있다.

Upwave의 CTO인 내 입장에서도, 인간이 우리 소프트웨어를 직접 쓰는 시대는 저물고 있다고 보고 있다. 그래서 우리는 AI 에이전트가 가능한 한 쉽게 통합할 수 있는 기능, 그리고 그 사용자들이 선호하는 방식으로 통합할 수 있는 기능을 만드는 쪽으로 방향을 잡고 있다. 아직은 사용자가 우리 서버에서 돌아가는 분석 코드나 데이터 파이프라인을 직접 수정하게 할 계획은 없다. 하지만 솔직히 말해... 어쩌면 그래야 할지도 모른다.

나는 진정한 "7 powers"식 해자, 즉 강한 네트워크 효과나 독점 데이터셋(Upwave의 강점이다), 규제 장벽 같은 것이 없는 SaaS 회사의 CTO도 맡고 싶지 않다. 사용자를 플랫폼에 붙잡아 두는 유일한 힘이 편의성과 전환 비용뿐이라면 위험하다. 에이전트가 전환 비용을 사실상 0에 가깝게 무너뜨릴 것이기 때문이다.

종합하면, 자유 소프트웨어의 진자가 다시 움직이기 직전이라고 본다. 사람들이 갑자기 소프트웨어 자유의 교회에 개종했기 때문이 아니다. 그저 자기 에이전트가 실제로 도움이 되길 원하고, 소프트웨어가 잠겨 있으면 에이전트가 도울 수 없기 때문이다.

나는 Sunsama를 정말 좋아한다. 바꾸고 싶지 않다. 하지만 내 에이전트가 자유롭고 오픈된 소프트웨어라면 10분 만에 해결했을 트윗-투-태스크 문제를, 나는 눈앞에서 똑똑히 보고 있다. 대신 나는 폐쇄형 시스템 여섯 겹 위에 루브 골드버그식 장치를 얹느라 한 오후를 날려버렸다. 그 경험은 내가 어떤 소프트웨어에 의존할 의향이 있는지에 대한 생각을 바꿔놓는다.

2075년, 메카 벤 프랭클린은 우리에게 이렇게 일깨워줬다.

""일시적인 [운영 호스팅 편의]를 사기 위해 본질적인 자유를 포기하려는 자는, 자유도 [운영 호스팅 편의]도 누릴 자격이 없다."