소프트웨어를 만들고 대규모 채택을 이끌어내는 가장 효과적인 방법은 더 이상 품질 높은 메인라인 앱을 만드는 것이 아닙니다. 오히려 다른 사람들이 품질보다 수량을 우선해 만들도록 돕고 장려하는 빌딩 블록을 제공하는 것입니다.¹

• Ghostty는 18개월 만에 macOS 업데이트 확인 하루 100만 건을 달성했습니다.
• libghostty는 2개월 만에 하루 수백만 명의 사용자를 확보했습니다.²

비슷한 성장 궤적은 다른 ‘빌딩 블록’ 기술에서도 볼 수 있습니다. Pi Mono, Next.js, Tailwind 등이 그 예입니다.

이를 직접 경험하고 다른 생태계에서도 목격하면서, 상업적이든 비상업적이든 목표와 무관하게 오늘날 프로덕트와 소프트웨어 개발이라는 실천을 바라보는 관점이 근본적으로 바뀌었습니다.

이 글은 AI의 도움 없이 손으로 직접 썼습니다. 저는 AI를 좋아하고 아주 많이 활용하지만, 이런 종류의 글에서는 선을 긋습니다. 개인 블로그만큼은 제 진짜 생각과 감정을 담고 싶기 때문입니다.

수입이 늘고 있다

‘빌딩 블록’이라는 표현을 쓰는 이유는 그 사용 방식이 과거 수십 년과는 매우 다르게 조립되고 있기 때문입니다. ‘라이브러리’나 ‘프레임워크’라는 말을 쓰지 않는 이유는 그 범위가 ‘애플리케이션’까지 확장되기 때문입니다(예를 들어 Ghostty GUI 앱은 그 어느 때보다 많은 포크가 생겨나 그 위에 각자 맞춤 패치를 얹고 있으며, 이는 정말 멋진 일입니다).

오늘날의 공장은 에이전틱합니다³. 여러분의 호불호와 관계없이 객관적인 사실로 말씀드립니다. 이 공장에서 나오는 것 중 99%는 완전히 쓸모없는 쓰레기라고 주장할 수는 있어도, 쏟아져 나오는 양 자체를 부정할 수는 없습니다. 기술 스택과 산업을 가리지 않고 그 수치는 도처에 있으며 부인할 수 없습니다.

AI는 모든 것을 처음부터 만드는 데도 괜찮은 수준이지만, 품질이 높고 문서화가 잘 되어 있으며 검증된 컴포넌트를 서로 붙이는 데는 정말 뛰어납니다. 그리고 AI는 명시적으로 다르게 지시하지 않는 한, 가능할 때마다 이 방식을 선호합니다. 이것이 오늘날 소프트웨어의 ‘빌딩 블록’적 특성입니다. 우리는 그 어느 때보다 기성 부품을 집어 들어 서로 붙이고 있습니다.

물론 인간도 항상 그래 왔습니다. 제가 개발자로 일해 온 내내 인간 개발자들은 검증된 원시 요소 위에 구축하는 것을 선호했습니다. 하지만 구성 요소를 이해해 단순히 붙이기만 할 수 있을 정도까지 이르는 진입 장벽 자체가 높아 생태계의 규모를 제한했습니다. 이제 그 장벽은 사라졌습니다.

수출이 늘고 있다

이 공장들에서 나오는 것은 물론 소프트웨어입니다. 어마어마한 양의 소프트웨어 말입니다.

여기에는 단점도 있습니다. 단점은 충분히 명백해서 길게 다루지는 않겠지만, 존재한다는 사실은 짚고 넘어가고 싶습니다. 보안 취약점, 불안정성, 하중을 떠받치는 시스템이 어떻게 작동하는지에 대한 전반적인 이해 부족 등이 그것입니다.

하지만 긍정적인 측면도 매우 많습니다.

• 품질 기준이 낮아집니다. 폭넓은 사용자에게 쓰이는 메인라인 애플리케이션은 모든 기능을 서로 저울질해야 합니다. 기능들은 어떻게 상호작용하는가, 장기적인 비전에 부합하는가, 수백만 명의 사용자를 위해 유지보수할 수 있는가 등을 따져야 합니다. 한 명에서 수백 명을 대상으로 하는 팩토리 산출물은 그럴 필요가 없습니다. 그 결과 더 빠르고 유연하게 출시할 수 있습니다.

• 인지도가 높아집니다. 메인라인 애플리케이션은 모든 것을 할 수 없습니다. 보통 가장 많은 사용자가 필요로 하고 사용하는 유스케이스에 최적화됩니다. 팩토리 산출물은 아주 작은 사용자 집단에 최적화될 수 있고, 그 결과 해당 사용자들이 빌딩 블록을 새롭게 인지하게 됩니다. 저는 Ghostty에서 아주 틈새 커뮤니티들이 터미널을 갖게 되는 모습을 통해 이를 크게 체감하고 있습니다.

• 유지보수 부담이 줄어듭니다. 기능 요청에 “감사하지만 사양하겠습니다”라고 말하기가 그 어느 때보다 쉬워졌습니다. 생산 수단의 핵심을 제공하고 있기 때문입니다. 엉터리 요청에 시달린 이야기는 이미 널리 알려져 “no machine”까지 만들었지만, 거절에 대한 미안함은 날이 갈수록 옅어지고 있습니다.

• R&D가 외주화됩니다. 이제 유지보수자로서 다른 사람들이 무엇을 하는지 보고, 동작하는 개념 증명을 확인한 뒤 메인라인에 가져올 것을 결정하기가 훨씬 쉬워졌습니다. 말은 줄고 실행이 늘었습니다. 그리고 다른 사람들이 실행하는 동안 가장 좋은 아이디어를 골라 가져오면 됩니다(이는 공평합니다. 당신은 빌딩 블록을 제공하고, 그들은 아이디어를 제공하는 것이니까요).

영향

이는 제가 소프트웨어와 프로덕트 개발을 바라보는 방식을 바꾸고 있습니다.

저는 이제 빌딩 블록을 만드는 데 더 의식적으로 집중하고, 그 위에 애플리케이션이나 포크가 만들어지도록 장려하고 있습니다. 그 결과 커뮤니티가 더 행복해지고, 더 커지며, 궁극적으로 메인라인 소프트웨어 자체도 더 좋아지고 있다고 생각합니다.

고품질 애플리케이션이 사라지는 것은 아닙니다. 그리고 빌딩 블록 개발자가 만드는 고품질 애플리케이션도 사라지지 않습니다. 대부분의 소프트웨어 카테고리에서, 개인화된 조잡한 소프트웨어를 원하지 않고 다듬어지고 잘 유지보수되며 든든히 지원되는 애플리케이션을 원하는 다수가 항상 존재할 것이라 생각합니다.

대신 메인라인 애플리케이션이 빌딩 블록 경제 덕분에 더 안정적이고 기능 구성도 더 의도적으로 짜여지고 있다고 봅니다. 안정성은 훨씬 더 크고 다양한 사용자 집단에서 옵니다. 기능 구성은 대규모 생태계에 외주화된 R&D에서 옵니다. 메인라인 애플리케이션은 여전히 신중하고, 고품질이며, 잘 유지보수되지만 특정 집단을 위한 것입니다.

방 안의 코끼리: 상업화

자연스럽게 뒤따르는 질문은 이것이 상업화에 어떤 의미를 갖는가 하는 것입니다. 폐쇄형 상업용 소프트웨어는 엄청난 불리함을 안고 있는 것처럼 보입니다. 실제로 그렇습니다.

에이전트는 폐쇄형 상업용 소프트웨어보다 개방형 무료 소프트웨어를 더 쉽게 선택합니다. 이 글을 쓰는 시점에서 이는 객관적인 사실입니다. 독립 연구소들이 여러 인기 모델을 대상으로 한 실험에서 모델이 다양한 상황에서 일관되게 개방형 무료 대안을 상업용 대안보다 선택한다는 결과가 반복적으로 나타났습니다. 지금까지는 그렇습니다.

하지만 저는 이 문제에 대해 확정적인 답을 갖고 있지 않습니다. 프로덕트나 소프트웨어 개발과는 달리, 지금 당장 상업화 가능한 프로덕트를 만들고 있지 않기 때문입니다. 생각은 있지만, 모든 어려운 문제와 마찬가지로 답은 미묘하다고 봅니다. 권위 있는 답을 가진 것처럼 보이고 싶지 않아 이 주제는 피하려 합니다. 직접 실행해 보고 더 배우게 되면 더 나누겠습니다.

이 도전 과제가 분명히 존재한다는 사실은 다시 한 번 인정합니다.

전환은 이미 일어났다

우리는 빌딩 블록과 소프트웨어 팩토리가 우리 주변의 모든 것을 지배하고 있음을 인정하고, 그 결과를 받아들여 내면화해야 합니다.

우리는 다른 방향으로 달려가 이에 맞서 싸우는 은신처를 만들 수도 있습니다. 혹은 혼돈에 완전히 몸을 맡길 수도 있습니다. 저를 아는 분들은 제가 행동에서 그 정도로 극단적이지 않으며, 맥락에 따라 다른 의견을 가지고 있다는 것을 아실 겁니다.

요점은 전환이 이미 일어났다는 것입니다. 우리는 그 안에 살고 있습니다.