오픈소스가 보장하는 소스 검토·수정의 자유는 실제로는 다른 사람이 대신 해줄 가능성에 가까웠고, 전문가조차 자주 쓰는 도구의 코드를 읽고 고칠 시간을 내기 어려웠음
하지만 LLM이 이 비용 구조를 바꾸고 있음. Claude에게 “GitHub의 x/y를 복제해 Z의 작동 방식을 알려줘”라고 하거나 Codex·Claude Code에 체크아웃과 빌드를 맡기면, 예전에는 포기하게 만들던 초기 마찰이 거의 사라짐. 아직 사용 중인 소프트웨어를 습관적으로 수정하진 않지만, 1년 전에는 없던 현실적인 경로가 보임

변화가 빠르게 진행 중이며, “X를 복제해 작동 방식을 알려줘”뿐 아니라 라이선스가 허용한다면 “X가 Y를 구현한 방식을 조사해 Z의 설계 참고 자료로 써줘”도 가능함
작년 12월쯤 Codex를 포크해 가벼운 계획 모드 등을 직접 추가했는데 만족스러웠지만 최신 상태 유지가 번거로웠음. 당시 모델 성능과 Rust 지식도 부족했으나, 변화가 느린 코드베이스였다면 충분히 유지할 만했을 것임
처음으로 개발자 도구 사업을 만들며 이 문제를 고민 중임. 클라우드 에이전트와 샌드박스 플랫폼 https://boxes.dev를 개발하고 있는데, 클라이언트나 전체 스택을 공개해도 개발 속도가 빨라 사용자 수정본의 업데이트가 어렵고 호스팅 영역은 자체 운영 없이는 수정할 수 없음. 그래도 모든 사용자나 에이전트가 코드에 관여하고 서로의 포크를 바탕으로 개인용 수정본을 만드는 유동적인 소프트웨어의 미래는 매력적임

LLM 이전에도 자주 쓰는 도구의 작은 버그를 파고들어 수없이 수정본을 보냈고, 특별한 역량이 필요한 일은 아니었다고 봄
지금은 LLM 기반 기여가 기대 수준을 무너뜨렸는지 예전과 비슷한 수정본도 오랫동안 무시되는 곳이 많지만, 반대로 대응 속도가 빨라진 도구도 있음. LM Studio는 비공개 소스에 버그 추적기만 열어두고 신고된 문제 대부분을 처리하지 않아 더 답답함. 추적기조차 없었다면 사용을 포기했겠지만, 수정될지 모른다는 기대 때문에 계속 사용하고 신고하게 됨

오픈소스의 또 다른 장점은 원 개발자보다 더 많은 사람이 코드를 살펴보면서 개발뿐 아니라 보안·사용성·접근성까지 다양한 역량과 우선순위를 보탤 수 있다는 것임
대부분이 모든 도구를 직접 검토하거나 수정하지는 않았겠지만, 오픈소스를 활용한 개발자들은 작은 버그를 로컬에서 패치하거나 기능을 보완하고, 자체 구현의 출발점으로 모듈을 연구하거나 외부 통신 여부를 훑어보곤 했음. Fortune 500 기업과 YC 스타트업뿐 아니라 비기술 기업, 공공시설, 의료 시스템에서도 이를 봤음
LLM이 마찰을 크게 줄여준다는 데는 동의하지만, 예전에는 코드를 읽을 시간이 없어 오픈소스의 가치가 작았다는 서술에는 동의하기 어려움. 개발자가 직접 읽지 않아도 가치가 있었으며, 코드 읽기는 역사적으로 핵심 작업 중 하나였음

지속적이고 중요한 변화를 만드는 것은 집단적 역량이지만, 이를 구성하려면 개인의 역량도 필요함. 표현의 자유와 비슷한 구조임

냉정히 말하면 대다수에게 오픈소스는 손쉬운 불법 복제 수단이었고, 관리자가 어제 필요했던 기능을 구현하지 않았다고 요구할 명분만 키워준 측면도 있음

개발자 도구의 오픈소스화에는 동의하지만, 설정 파일·옵션·플러그인 없이 글꼴 크기 하나를 바꿀 때도 LLM이 코드를 내려받아 하드코딩된 값을 수정하고 다시 빌드해야 한다는 전제에는 강하게 반대함
LLM이 옵션 대화상자나 설정 파서를 한 번 만들게 하는 편이, 수백만 사용자가 사소한 변경마다 전력과 연산을 쓰는 것보다 훨씬 효율적임. 남에게 필요 없는 개인 맞춤 수정은 좋지만, 범용 기능을 추가하고도 업스트림 반영을 시도하지 않는 태도는 바람직하지 않음

플러그인 구조는 확장성이 높고, 널리 쓰이는 플러그인을 본체에 흡수할 수도 있어 직접 만든 개발자 도구에도 이 방식을 적용했음

설정 변경은 한 번으로 끝나야 함. LLM이 대부분을 대신하더라도 도구가 빌드 체인과 반복적인 맞춤 수정을 관리해야 하는 부업 프로젝트가 되는 것은 원하지 않음

빌드가 빠르다면 상수와 설정 매개변수를 바꾸는 일은 크게 다르지 않음
다만 모듈성은 병합 충돌을 줄이므로 계속 중요하며, 잘 모듈화된 시스템은 플러그인 구조와 비슷해질 수 있음. AI는 처리 방법이 명확한 작은 호환성 문제를 해결할 가능성이 높음. Linux 장치 드라이버를 트리 내부에 두듯 API가 바뀌면 AI가 호출부를 고치게 할 수 있고, 컴파일 시간 검사는 AI에 직접적인 피드백을 제공함

근거 없는 희망이지만, 10년 뒤에는 이런 비판이 “가정마다 메인프레임을 두려고 방 하나씩 낭비할 셈인가?”라는 과거의 우려처럼 들릴 수도 있음

개발자 도구 회사에서 일했고 직접 CEO도 해봤는데, 오픈소스와 사업 성공을 함께 달성하기는 매우 어려움
대표적으로 예전에 근무했던 Sendmail은 수백만 달러를 투자받고도 인프라 회사에 매각돼 투자자에게 투자금의 극히 일부만 돌려줬음. 고객인 개발자와 운영자는 소프트웨어를 직접 실행하고 필요한 기능도 추가할 수 있어 공급자가 필요 없다고 여기며, 실제로 맞는 경우도 많음
AI 코딩 도구가 등장하면서 공개된 소스를 바탕으로 상용 제품의 “충분히 괜찮은” 버전을 빠르게 만들 수 있어 문제가 열 배쯤 심해짐. 개인과 스타트업에는 무료이고 수익성 있는 기업에는 유료인 라이선스도 흥미롭지만, 일부 기업은 바로 그 조건 때문에 해당 도구를 금지함

코드가 온라인에 공개되면 누군가는 라이선스와 무관하게 통째로 가져가거나 명세를 바탕으로 핵심을 재구현할 가능성이 큼
과거부터 쌓은 명성 같은 배포 우위를 확보하지 못했다면 지금은 오픈소스를 만들기 힘든 시기임

매일 밤 업스트림 변경을 가져와 로컬 수정본을 리베이스하고 자동 교체한다는 발상은 악몽에 가까움
신뢰하기 어려운 행위자가 매일 소프트웨어를 다시 만들면 아침마다 작업 흐름이 망가질 위험이 생김. AI는 요청의 취지보다 글자 그대로를 따르는 데 능해서, 파일명이 빠졌다고 고치면 글자 크기 4로 넣고 잘 보이게 하라고 하면 다음에는 54로 키울 수 있음. 일반적인 AI 개발처럼 사람이 변경을 검토하고 시험하는 것은 괜찮지만, 개요도 모른 채 매일 자동 적용하는 것은 문제를 자초함

자동 리베이스는 하지 않지만 코드를 벤더링해두고 원하는 주기에 직접 업데이트함

적어도 비용을 미리 알 수 있다는 장점이 있음. 아니, 다시 생각해보니 그것도 아님

다소 이상적이지만 좋은 부분도 있음. 단일 약 800MHz 코어와 512MB RAM으로 Linux를 구동하는 Kobo에서 개인용 앱을 만들었음
시력이 나빠져 긴 Claude 세션 동안 노트북 화면을 벗어나고 싶어, 승인 요청을 Kobo로 전송하는 보조 도구를 만들기 시작했음. 이후 훅을 이용한 Claude·Codex 권한 보조 도구뿐 아니라 SDK 전체, HN 클라이언트, RSS 검색·리더, 심층 조사와 ElevenLabs API를 활용하는 오디오북 생성기까지 모두 기기에서 실행되도록 만들었음
이제 LLM 사용자는 Clara BW와 다른 각자 Kobo의 세부 차이에 맞춰 이를 수정할 수 있고, 코딩 에이전트가 있어도 처음부터 만드는 것보다는 훨씬 적은 작업이 들 것으로 기대함 https://github.com/BandarLabs/Cobalt

예전에 https://news.ycombinator.com/item?id=48849015라는 댓글이 있었지만, 밝음과 어둠의 구도에는 동의하지 않음
“해커 언어”와 “블럽 언어” 사이의 진짜 긴장은 사용자가 언어 자체를 수정할 것으로 기대하는가에 있음. 개발자 도구도 마찬가지로 해커는 Emacs처럼 바꿀 수 있는 환경을 선호하지만, 기업은 프로그래머가 적응해야 하는 표준 IDE를 선호함
합리적인 사람은 세상에 자신을 맞추지만 비합리적인 사람은 세상을 자신에게 맞추려 하므로 모든 진보가 후자에게 달렸다는 격언처럼, Paul Graham이 비블럽 언어를 쓰는 창업자를 선호한 이유도 Lisp 자체보다 이런 성향일 수 있음. 환경을 바꾸려면 먼저 이해해야 하므로, 처방을 따라 쓰는 복잡하고 기능 많은 기계보다 단순하고 보편적인 도구 집합을 추구하게 됨

포크와 수정이 쉽도록 개발자 도구를 관리해왔기에 매력은 이해하지만, 이 구상은 지나치게 이상적임
개발자도 일반 사용자처럼 도구가 그냥 작동하길 원함. 업스트림 기능이 로컬 변경과 병합 충돌은 없어도 사용자 경험 측면에서 충돌한다면 릴리스마다 해결해야 함. 현재 에이전트는 대략적인 방향은 맞춰도 내가 원하는 사용자 경험을 정확히 포착하지 못하며, 초개인화가 목적이라면 결과도 정확히 원하는 모습이어야 함
중요한 작업 중 “작동하는 듯함”이 깨졌을 때 작업을 멈추고 에이전트에게 도구 수리를 맡겨야 하며, 다시 실패할 수도 있음. 여러 사람이 같은 결과물을 보는 사회적 개발자 도구에서는 화면과 동작이 모두에게 동일한 것 자체가 교육·감사·검증의 중요한 기준이 됨. 일부 범주에서는 초개인화가 가능하겠지만 보편화까지는 거리가 멂

개발자 도구 업그레이드는 벤더링한 라이브러리 업데이트처럼 자동이나 작업 도중에 할 일이 아님
AI가 보통 병합 충돌을 처리할 수 있고 업스트림 변경이 크면 로컬 변경을 다시 작성하게 할 수도 있음. 유지가 너무 어려우면 버려도 되는 부가 기능에 특히 잘 맞을 것임

고장이 없더라도 업스트림 UI 변경 때문에 프로그램 모습이 매일 달라진다면 피곤할 것임. 자동 반영은 보안·버그 수정에 더 적합함
UI를 바꾸지 않는 기능 개선은 받아올 만하지만, 새 기능이 생긴 사실조차 모르면 실제로 사용할지도 의문임. 다만 작업 흐름을 잘 구성해 이전 바이너리로 언제든 되돌릴 수 있다면 위험을 줄일 수 있음

LLM이 작업을 쉽게 해주더라도, 도구 설정에 반드시 필요한 의존성으로 만들지는 않았으면 함
가중치를 공개한 모델조차 완전한 오픈소스가 아니며, 소스 없이 백엔드 바이너리만 가진 것과 비슷함. 편의를 위해 쓰는 것은 좋지만 LLM을 오픈소스 소프트웨어와 상호작용하는 주된 방식으로 정상화하고 싶지는 않음

에이전트로 도구를 맞춤 수정하다 문제가 생기면 사용자가 해결해야 하므로 이 구상에 반대함. 은행 앱이나 소프트웨어 구성 분석 도구에서 실명 대신 별명을 쓰도록 수정했다가 망가지면 누가 책임지고 고칠지 불분명함

고장까지 나지 않더라도 익숙하지 않은 코드베이스에 사용자와 LLM이 미묘한 버그나 취약점을 넣을 수 있으며, 이를 발견할 사용자도 단 한 명뿐임

AI에 고장 난 부분을 알려주고 고치게 하는 편이 고객 지원에 문의하는 것보다 나을 때가 많지만, 실패하면 문제가 됨
당장은 개발자 밖으로 일반화하기 어려울 수 있음. 개발자는 병합 충돌을 이해하고 AI에 문제를 더 정확히 전달할 수 있기 때문임. 다만 관심 있는 사람이 배우기 어려운 기술은 아니며, AI가 자동으로 처리하지 못하는 충돌이라면 업스트림에 큰 변화가 생겼다는 뜻일 가능성이 큼
스스로 빠져나올 수 없을 만큼 문제가 커진 사람을 돕는 직업도 생길 것이며, 그 비용을 낼 수 없다면 직접 배우는 계기가 될 것임