소프트웨어를 만들고 대규모 채택을 얻는 가장 효과적인 방식이 이제는 고품질 메인라인 앱 자체가 아니라, 다른 이들이 양보다 질이 아니라 질보다 양을 만들 수 있게 하는 빌딩 블록을 만드는 일이라는 주장.
2026년 4월 7일
소프트웨어를 만들고 대규모 채택을 얻는 가장 효과적인 방식은 이제 더 이상 고품질 메인라인 앱이 아니라, 다른 사람들이 질보다 양을 만들어낼 수 있도록 가능하게 하고 장려하는 빌딩 블록을 만드는 것이다.1
비슷한 성장 궤적은 다른 "빌딩 블록" 기술들에서도 볼 수 있다: Pi Mono, Next.js, Tailwind 등.
이를 직접 경험하고, 다른 생태계에서도 목격하면서, 상업적이냐 비상업적이냐와 무관하게 오늘날 제품 및 소프트웨어 개발의 실천을 바라보는 내 관점은 근본적으로 바뀌었다.
이 글은 AI의 도움 없이 손으로 직접 썼다. 나는 AI를 아주 좋아하고 많이 사용하지만, 이런 종류의 콘텐츠에서는 개인적으로 선을 긋는다. 내 개인 블로그는 내 진짜 생각과 감정을 반영하길 바란다.
나는 이것들이 사용되는 방식을 설명하기 위해 "빌딩 블록"이라는 용어를 쓴다. 오늘날 그것들은 과거 수십 년과는 아주 다른 방식으로 조립되고 있기 때문이다. 나는 "라이브러리"나 "프레임워크"라는 용어를 쓰지 않는다. 왜냐하면 그 범위가 "애플리케이션"까지도 확장되기 때문이다(예: Ghostty GUI 앱은 그 위에 맞춤형 패치를 얹은 포크가 그 어느 때보다 많아졌는데, 이건 정말 멋진 일이다).
오늘날의 공장은 agentic하다.3 나는 이것을, 이에 대해 당신이 어떤 감정을 갖고 있든, 객관적 사실로 말한다. 이 공장들에서 나오는 것의 99%가 완전한 쓰레기라고 주장할 수는 있겠지만, 쏟아져 나오는 엄청난 양 자체는 부정할 수 없다. 그 수치는 기술 스택과 산업 전반에 걸쳐 어디에나 있고, 부인할 수 없다.
AI는 모든 것을 처음부터 만드는 데도 괜찮지만, 품질이 높고 문서화가 잘 되어 있으며 검증된 구성 요소들을 이어 붙이는 데는 정말로 능하다. 그리고 특별히 다르게 지시하지 않는 한, AI는 가능할 때 이런 방식을 선호한다. 이것이 오늘날 소프트웨어의 "빌딩 블록"적 본질이다. 우리는 그 어느 때보다도 기성 부품을 집어 와서 서로 이어 붙이고 있다.
물론 인간도 늘 이렇게 해왔다. 내 경력 전체를 통틀어, 인간 소프트웨어 개발자들은 검증된 기본 요소 위에 구축하는 방식을 선호해 왔다. 하지만 그 구성 요소 조각들을 충분히 이해해서 그저 대충 이어 붙이기만 하는 데도 진입 장벽이 높았기 때문에, 생태계의 규모에는 제한이 있었다. 이제 그 장벽은 사라졌다.
이 공장들에서 나오는 것은 물론 소프트웨어다. 아주 많은 소프트웨어.
여기에는 부정적인 면도 있다. 나는 그 부정적인 면들이 충분히 자명하다고 생각해서 많은 시간을 들이진 않겠지만, 그것들이 존재한다는 점은 인정하고 싶다. 보안 취약점, 불안정성, 하중을 떠받치는 시스템이 어떻게 동작하는지에 대한 전반적인 이해 부족 같은 것들이다.
하지만 긍정적인 면도 아주 많다:
품질 기준이 더 낮다. 다양한 대규모 사용자층이 사용하는 메인라인 애플리케이션은 모든 기능을 다른 모든 기능과 저울질해야 한다. 서로 어떻게 상호작용하는가? 장기적 비전에 부합하는가? 수백만 사용자를 위해 이것을 내가 유지할 수 있는가? 1명에서 수백 명의 사용자를 겨냥한 공장 산출물은 이런 점을 신경 쓸 필요가 없다. 그 결과 더 빠르고 더 느슨하게 출시할 수 있다.
인지도가 더 높다. 메인라인 애플리케이션은 모든 것을 할 수 없다. 보통은 가장 많은 사용자가 필요로 하고 실제로 사용하는 사례에 최적화된다. 공장 산출물은 아주 작은 사용자 단면에 최적화될 수 있고, 그 결과 이 사용자들은 그 빌딩 블록에 대한 인식을 갖게 된다. 나는 이것을 Ghostty에서 크게 보고 있다. 아주 틈새적인 커뮤니티들이 터미널을 얻게 되고 있다.
유지보수 부담이 더 낮다. 이제는 기능 요청에 "사양하겠습니다"라고 말하기가 그 어느 때보다 쉽다. 당신은 생산 수단의 핵심 일부를 제공하고 있기 때문이다. 엉성한 요청들과 관련한 내 어려움은 매우 공개적이고, 심지어 나는 "no machine"도 만들었지만, 동시에 "안 됩니다"라고 말하는 것에 대해 날이 갈수록 점점 덜 미안해지고 있다.
연구개발이 외주화된다. 이제 유지관리자 입장에서는 다른 사람들이 무엇을 하고 있는지 보고, 작동하는 개념 증명을 확인하고, 무엇을 메인라인으로 다시 가져올지 결정하는 일이 훨씬 쉬워졌다. 말은 훨씬 적고 실제 구현은 훨씬 많다. 그리고 다른 사람들이 구현해 나가는 동안 당신은 최고의 아이디어만 골라 가져올 수 있다(이건 공정하다. 당신은 빌딩 블록을 내어주고 있고, 그들은 자기 아이디어를 내어주고 있기 때문이다).
이것은 내가 소프트웨어와 제품 개발을 바라보는 방식을 바꾸고 있다.
나는 빌딩 블록을 만들고 그 위에서 돌아가는 애플리케이션이나 포크를 장려하는 일에 훨씬 더 의도적으로 임하고 있다. 나는 이것이 더 행복한 커뮤니티, 더 큰 커뮤니티, 그리고 궁극적으로 더 나은 메인라인 소프트웨어로 이어진다고 생각한다.
고품질 애플리케이션이 사라지고 있는 것은 아니다. 그리고 빌딩 블록 개발자들이 직접 만드는 고품질 애플리케이션도 사라지고 있는 것은 아니다. 대부분의 소프트웨어 범주에서는, 개인화된 엉성한 소프트웨어를 원하지 않고 다듬어져 있으며 잘 유지보수되고 잘 지원되는 애플리케이션을 원하는 다수 집단이 언제나 존재할 것이라고 나는 생각한다.
오히려 나는 빌딩 블록 경제 덕분에 메인라인 애플리케이션이 더 안정적이고, 기능 집합 면에서도 더 목적의식 있게 되어가고 있다고 생각한다. 안정성은 훨씬 더 크고 다양한 사용자 집단에서 나온다. 기능 집합은 대규모로 외주화된 연구개발 생태계에서 나온다. 메인라인 애플리케이션은 여전히 신중하고, 품질이 높고, 잘 유지보수되지만, 특정한 집단을 위한 것이다.
그 다음 자연스럽게 따라오는 분명한 질문은 이것이 상업화에 무엇을 의미할 수 있느냐이다. 비공개 소스의 상업용 소프트웨어는 엄청난 불리함에 처해 있는 것처럼 보인다. 그리고 실제로 그렇다.
에이전트는 비공개이고 상업적인 소프트웨어보다 공개적이고 무료인 소프트웨어를 더 기꺼이 선택할 것이다. 이 글을 쓰는 시점에서 이것은 객관적 사실이다. 인기 모델들에 대해 실험을 수행하는 독립 연구소들은, 다양한 상황에서 모델이 상업용보다 공개적이고 무료인 대안을 선택한다는 사실을 반복해서 발견해 왔다. 지금까지는 그렇다.
하지만 여기서 나는 구체적인 답을 갖고 있지 않다. 제품 및 소프트웨어 개발과는 달리, 나는 지금 직접 상업화 가능한 제품을 만들고 있지 않기 때문이다. 생각은 있다. 그리고 모든 어려운 문제와 마찬가지로, 답은 미묘한 결을 가질 것이라고 생각한다. 하지만 이 주제에 대해 권위 있게 말하는 듯한 착각을 주고 싶지 않으므로, 이 부분은 피하려고 한다. 내가 직접 해보고 더 배우게 되면, 더 많이 공유하겠다.
나는 다시 한번, 이 도전이 분명히 존재한다는 점만 인정하고자 한다.
우리를 둘러싼 모든 것을 빌딩 블록과 소프트웨어 공장이 지배하고 있다는 사실을 받아들여야 하고, 그에 따른 결과를 받아들이고 내면화해야 한다.
우리는 반대 방향으로 달아나 그것에 맞서 싸우는 거점을 만들 수도 있고, 아니면 혼돈에 우리 자신을 완전히 맡길 수도 있다. 나를 아는 사람들은 내가 행동 면에서는 훨씬 덜 극단적이고, 맥락에 따라 다른 의견을 갖고 있다는 것을 안다.
중요한 점은 전환이 이미 일어났다는 것이다. 우리는 그 안에서 살고 있다.
다만 빌딩 블록 자체는 보통 높은 품질, 견고함, 그리고 잘 갖춰진 문서를 필요로 한다. ↩
Ghostty에는 실질적인 추적 기능이 없기 때문에 정확한 수치를 얻는 일은 당연히 어렵다. 우리는 macOS용 업데이트 파일 확인의 집계치를 볼 수 있다. Linux 쪽은 전혀 보이지 않는다. libghostty에도 추적 기능은 없지만, libghostty를 통합한 도구들은 추적 기능이 있을 수 있고 실제로 집계치를 우리와 공유해 왔다. ↩
여기서 내가 "agent"라는 용어를 쓰는 것은, 단순히 도구에 접근할 수 있는 대규모 언어 모델이 루프 안에서 작동하는 것을 뜻하기 위함이다. 사람들은 내가 마케팅 용어를 써서 과장하거나 귀엽게 보이려 한다고 생각하곤 하지만, 나는 이것을 구체적이고 널리 받아들여지는 정의로 사용하고 있다. ↩
2026년 4월 7일
© 2026 Mitchell Hashimoto.
