개발자 도구는 오픈 소스여야 한다

5년 전, 제가 만났던 대부분의 소프트웨어 엔지니어들은 자신들을 위해 직접 작성한 프로그램이 없다고 했습니다. (저는 Tailscale이 엔지니어들의 삶에 어떻게 적용될 수 있는지 이해하려 하면서 이 질문을 자주 던졌습니다.) 매일 하루 종일, 엔지니어들은 다른 사람이 만든 프로그램을 사용해서 다른 사람을 위한 프로그램을 만듭니다. 우리 중 다수는 설정 파일이나 플러그인, 확장 기능을 통해 사용하는 프로그램을 맞춤화했고, 많은 경우 우리가 다른 사람들을 위해 작성한 프로그램의 사용자로서도 그것들을 사용했습니다. 그래서 누군가에게 자신이 자신들을 위해 무엇을 만들었는지 물어보고 그들의 블로그 뒤에 숨겨진 맞춤형 소프트웨어, 혹은 홈 자동화 시스템이나 홈랩(homelab)에 대해 듣는 것은, 기성품처럼 거의 적당한 크기의 정적 사이트 생성기나 Zigbee 가전제품에 대한 이야기를 듣는 것보다 항상 특별하고 흥미로운 경험이었습니다.

이러한 상황은 저에게 매우 자연스럽게 다가왔습니다. 수년 동안 저는 자신들을 위해 많은 소프트웨어를 작성해 왔고, 그 보상은 언제나 의문스러웠습니다. 하루에 제가 쓸 수 있는 양에는 한계가 있었기 때문입니다. 항상 더 중요한 일들이 남아있었고(직장에서 무언가 잘못된 일이 있었다), 1년 후에 프로젝트를 다시 돌아와 유지보수를 하는 것은 늘 엄청난 고통이었습니다. 제 경력 중에는 모든 맞춤형 소프트웨어를 버리고 가장 평범한 환경을 사용해서 코드를 만들어냈던 해들이 많았습니다. 구글에서 엔지니어로 일하던 초기 시절에는 개인용 컴퓨터조차 소유하지 못했습니다.

그때가 과거였습니다. 지금은 상황이 다릅니다.

소프트웨어를 개인화하는 방법

오늘날 소프트웨어는 놀라울 정도로 쉽게 개인화할 수 있습니다. 이 모든 것을 가능하게 하는 에이전트(agent)에게 줄 수 있는 일반적인 프롬프트 범주가 두 가지 있습니다:

• <소프트웨어>의 소스 코드를 다운로드하여 로컬에서 빌드합니다. <에이전트가 사용하는 메모리 내용>을 수정하여 이 소프트웨어의 향후 모든 변경 사항은 소스를 변경하고 현재 버전을 대체한다는 것을 알게 합니다. 변화의 원래 동기를 버전 관리 시스템(version control)에 기록합니다.

그리고, 더 중요한 것은: <software>의 상위 변경 사항을 가져와 모든 로컬 변경 사항을 그 위에 리베이스(rebase)하는 프롬프트를 실행하는 나이틀리 크론 작업(nightly cron job)을 설정하는 것입니다. 소프트웨어가 의도한 대로 작동하는지 확인하고 현재 버전을 교체해야 합니다.*

여기에는 에이전트가 특정 사용 사례를 위해 코드를 짜는 것뿐만 아니라, 변경 사항을 상위 릴리스와 동기화하는 프로세스 자체를 자동으로 관리할 수 있다는 인식이 담겨 있습니다. 이는 에이전트가 두 가지 측면에서 소프트웨어 맞춤 설정의 투자 대비 수익(ROI)을 변화시킨다는 것을 의미합니다. 즉, 개인화 작업을 시작하기가 훨씬 쉬워지고, 계속 진행하기도 훨씬 쉬워집니다.

위에서 언급된 소프트웨어 편집을 위한 두 프롬프트에 대한 또 다른 놀라운 점은 이를 에이전트에 직접 구축할 수 있다는 것입니다. 에이전트 자체가 오픈 소스이기만 하다면 프로그래밍조차 필요하지 않습니다. 이 두 프롬프트를 스킬(skill, 즉 에이전트가 발견할 수 있는 어딘가에 배치된 텍스트 지침)에 로드할 수 있습니다. 저희는 이를 Shelley에 구축했기 때문에, 이제 Shelley를 편집하고 싶다면 서문이나 타이머를 설정할 필요조차 없습니다. 그것이 알아서 처리해 줍니다. “Shelley의 UI를 고대비로 만들어줘”와 같은 프롬프트를 입력하기만 하면 에이전트가 개인화됩니다.

실제 맞춤화 예시: Shelley와 Meat

저는 지난 한 달 동안 개인적으로 가지고 놀아온 프로젝트가 있습니다: meat.dev. 이 프로젝트의 원리는 에이전트들이 코드를 작성할 때, 제가 그것을 읽어본 후에야 저희의 중요한 시스템에 푸시한다는 것입니다. 기반 모델(underlying models)이 개선되면서 제가 찾는 것도 바뀌었습니다. 지난 20년간 코드 검토를 해온 인간들은 항상 엣지 케이스(edge cases)에서 어려움을 겪었습니다: 에러 보고서가 유용한 정보를 제공하는지; nil-check가 처리되는지 등입니다. (우리 모두 그렇죠. 코드를 작성할 때, 저는 최악의 위반자 중 한 명입니다.) 검토자로서 제 역할 중 하나는 이러한 세부 사항을 찾는 것이었습니다. 지난 6개월 동안, 저는 더 이상 그러한 엣지 케이스를 위해 읽을 필요가 없다는 것을 발견했습니다: 모델들은 단순한 정확성(rote correctness) 면에서 인간보다 훨씬 부지런합니다. 그들의 에러는 아키텍처, 예상치 못한 사용 사례, 테스트 환경이 그들에게 피드백하지 않는 시각적 출력 등에 국한됩니다. 이는 제가 검토하는 코드 라인의 대부분이 그다지 유용하지 않다는 것을 의미합니다. 그래서 저는 diff를 받아서 LLM을 사용하여 중요하지 않은 부분을 제거하는 도구를 만들었습니다. 저는 import 블록이나 nil-check, 또는 에러 핸들링 등을 거의 볼 필요가 없게 되었으니, 제가 '본질(meat)'에 집중할 수 있도록 화면에서 치워주세요.

저는 이 도구가 마음에 드는데, 두 가지 단점이 있습니다: 첫째, 저는 좋은 UI를 가진 Shelley에서 diff를 읽는 것을 좋아하지, 터미널에서는 싫어합니다. 둘째, LLM이 diff를 소화하고 최소화하는 데 몇 분이 걸리며, 저는 기다리고 싶지 않습니다. 그래서 이상적으로는 meat을 커맨드 라인에서 실행하기보다는, Shelley에 내장시키고 커밋이 생성되는 즉시 백그라운드에서 전처리되게 하고 싶습니다. 놀랍게도 단 하나의 프롬프트로 그것을 할 수 있었습니다:

Shelley에 meat.dev를 구축해 주세요. 최신 버전을 PATH에 설치해 주세요. Shelley가 git 커밋을 생성할 때, 해당 커밋에 대해 백그라운드에서 meat 처리를 시작해 주세요. meat을 위해 Shelley의 Diffs 뷰에 토글 스위치를 추가해 주세요. 만약 커밋이 아직 처리 중이라면, 사용자에게 '처리 중'임을 알려주세요.

이 단일 프롬프트만으로 Shelley에 살을 붙이는 것뿐만 아니라, 제가 세션으로 돌아와 diff를 검토하기 전에 백그라운드에서 커밋을 적절하게 전처리할 수 있게 되어 모델을 기다리며 diff가 줄어들기를 기다릴 필요가 없어졌습니다. 모델이 내린 유일한 불운한 선택은 토글 버튼에 🥩 이모지를 사용했다는 것입니다.

VS Code extensions API에 이것을 연결하려고 하거나 vimdiff에 넣으려고 한다고 상상해 보세요!

물론 가능하겠지만, 커밋이 나타나는 즉시 전처리를 시작하는 장치는 거의 불가능할 겁니다. 저는 파일 시스템을 듣고 meat 도구의 캐시를 제공하여 사용자 정의 API가 사용할 수 있는 아웃-오브-밴드(out-of-band) meatd를 구현하는 것이 더 좋을 것 같습니다. 왜냐하면 확장 및 구성 지점이 올바른 형태가 아니기 때문입니다.

그리고 이것이 클래식한 구성/사용자 정의와 에이전트 기반 개인화 사이의 근본적인 차이점입니다. 훨씬 더 많은 것을 할 수 있습니다. 에이전트는 소스를 이해하고 사용자가 염두에 둔 특정 작업에 맞게 변경하는 어려운 작업을 수행할 것입니다. 우리가 사용하는 소프트웨어는 개인화가 적용될 때 훨씬 더 강력해집니다. 필요한 것은 원본 코드(source code)뿐입니다.

개인화된 소프트웨어의 시대

사전 에이전트 개발 비용은 복잡한 소프트웨어가 대규모 구성 파일, 확장 시스템 및 플러그인 시스템을 포함하여 배포하는 것이 합리적이라는 것을 의미했습니다. Vim과 같은 적당한 프로젝트의 핵심 코드는 거대하고 난해하며, 사람이 소화하는 데 몇 주가 걸립니다. 기본적으로 줄 번호를 인쇄하기를 원한다는 이유로 엔지니어가 코드베이스를 학습하여 자신만을 위해 추가할 것이라는 생각은 비합리적입니다. 다른 사람들과 공유할 수 있도록 설계하는 것이 더 좋으며, 이는 많은 사용자에게 분산(amortizing)함으로써 구현 비용을 정당화합니다. 코드베이스의 기능이 증가함에 따라, 확장 또는 플러그인 시스템을 분리할 수 있는 공통 추상화를 찾는 것이 합리적입니다.

이제 코드를 학습하고 변경하는 비용이 극적으로 낮아졌습니다. 에이전트가 무거운 작업을 처리합니다. 단일 사용자(프로그램이 실행되는 조건이 매우 제한적임을 의미)의 경우, 최고 수준의 에이전트는 이제 한 번에 기능을 추가할 수 있습니다. 단일 사용자 소프트웨어의 경우, 신중한 코드 검토의 필요성은 종종 “작동하는 것처럼 보이는가?”로 대체될 수 있습니다.

그 결과, 개인화 가능한 소프트웨어는 플러그인 시스템이나 설정 파일이 필요하지 않습니다. 텍스트 편집기의 글꼴 크기를 변경하고 싶습니까? 에이전트에게 소스를 주고 그렇게 하라고 지시하면 됩니다. 만약 그것이 하드코딩된 값이라면 찾아서 수정할 것입니다. 만약 하드코딩된 비트맵 글꼴이라면 다른 것을 다운로드하여 대체하거나, Monobit을 사용하여 직접 만들어 줄 것입니다! 손쉽게 엄청난 능력을 사용할 수 있습니다.

소프트웨어 제품의 전체 카테고리가 재구축되어야 한다

개인화된 소프트웨어는 소규모 팀에도 잘 적용됩니다. 엔지니어링 팀이 왜 매우 구성 가능한 작업 관리자(또는 CMS나 CRM)를 구매하고, 그것을 학습하고 설정하는 데 시간을 쓰고, 그들의 팀을 한계까지 비틀어야 할까요? 원하는 기능만을 공통 빌딩 블록에서 조립할 수 있는데 말입니다?

사전에 발생하는 고정 비용과 소프트웨어 개인화에 따른 지속적인 비용이 모두 사라졌습니다.

지금 읽고 있는 이 블로그는 Tiptap 같은 라이브러리를 커스터마이징하는 것보다 조립하고 개인화하기가 더 쉬웠기 때문에 Shelley로 작성된 맞춤형(bespoke) 소프트웨어입니다. 오늘날 기업에서 최종 사용자 제품이 의미를 가지려면, 개인화 가능해야 합니다. 이는 우리가 소스 코드를 필요로 한다는 것을 의미합니다.

Codex와 Claude Code의 차이점

Shelley에 적용되어 그것을 개인화 가능하게 만든 이 동일한 기술 기반 기법은 Pi 같은 다른 오픈 소스 에이전트에도 사소하게 적용될 수 있습니다. (너무나도 쉬워서 Pi가 왜 자체적으로 확장 시스템을 필요로 하는지 의문이 들 정도입니다. 소스 코드가 곧 확장 시스템입니다.) 토큰이 훨씬 더 많이 필요하겠지만, 여러분은 동일한 것을 오픈 소스 에이전트인 Codex에도 할 수 있습니다.

하지만 벽에 부딪힐 수 있는 곳은 Claude Code입니다. 이는 클로즈드 소스(closed-source) 소프트웨어이므로 개인화할 수 없습니다. Claude Code에는 구식의 커스터마이징 훅(customization hooks)들이 많이 있습니다. 바라건대, 에이전트가 작동하기를 원하는 방식이 그들의 훅에 맞기를 바랍니다. 그렇지 않다면, 개인화할 수 있는 에이전트로 전환하세요.