The Building Block Economy

Mitchell Hashimoto

빌딩 블록 경제

원문은 Mitchell Hashimoto님이 에 게재했습니다. 이 블로그 구독하기

소프트웨어를 만들고 대규모 채택을 이끌어내는 가장 효과적인 방법은 더 이상 완성도 높은 메인라인 앱이 아니라, 다른 사람들이 질보다 양을 추구하며 만들도록 가능하게 하고 장려하는 빌딩 블록을 통해서다.1

  • Ghostty, 18개월 만에: 매일 100만 건의 macOS 업데이트 확인.
  • libghostty, 2개월 만에: 매일 수백만 명의 사용자.2

비슷한 성장 궤적은 다른 “빌딩 블록” 기술에서도 볼 수 있다: Pi Mono, Next.js, Tailwind 등.

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

이 글은 AI의 도움 없이 직접 손으로 작성했다. 나는 AI를 사랑하고 많이 활용하지만, 이런 콘텐츠만큼은 개인적으로 선을 긋는다. 내 개인 블로그에는 나의 진솔한 생각과 감정이 담기길 바란다.

임포트가 늘고 있다

나는 이들이 사용되는 방식을 설명하기 위해 “빌딩 블록”이라는 용어를 쓴다. 오늘날 이들이 조립되는 방식이 과거 수십 년과는 매우 다르기 때문이다. “라이브러리”나 “프레임워크”라는 용어를 쓰지 않는 이유는 그 범위가 “애플리케이션”에까지 확장되기 때문이다(예를 들어 Ghostty GUI 앱은 그 위에 커스텀 패치를 올린 포크가 그 어느 때보다 많아졌는데, 정말 멋진 일이다).

오늘날의 공장은 에이전틱하다3. 이는 당신의 감정이나 기분과 관계없이 객관적 사실로 말하는 것이다. 이 공장들에서 나오는 것의 99%가 완전히 쓰레기라고 주장할 수는 있지만, 쏟아져 나오는 엄청난 양 자체는 부정할 수 없다. 그 수치는 기술 스택과 산업을 가리지 않고 도처에 있으며 부인할 수 없다.

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

물론 인간도 항상 이렇게 해왔다. 내 커리어 내내 인간 소프트웨어 개발자들은 검증된 원시 요소(primitive) 위에 구축하는 것을 선호해 왔다. 하지만 컴포넌트 조각들을 그저 붙이기 위해서라도 충분히 잘 이해해야 한다는 자연스러운 진입 장벽이 생태계를 제한할 만큼 높았다. 이제 그 장벽은 사라졌다.

엑스포트가 늘고 있다

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

여기에는 부정적인 측면도 있다. 부정적인 측면은 충분히 명백하다고 생각해 많은 시간을 할애하지는 않겠지만, 존재한다는 것은 인정하고 싶다. 보안 취약점, 불안정성, 하중을 지탱하는 시스템이 어떻게 작동하는지에 대한 전반적인 이해 부족 등이 그것이다.

하지만 긍정적인 측면도 엄청나게 많다:

  • 품질 기준이 낮아진다. 폭넓은 사용자층이 쓰는 메인라인 애플리케이션은 모든 기능을 다른 모든 기능과 저울질해야 한다. 어떻게 상호작용하는지, 장기적인 비전에 맞는지, 수백만 사용자를 위해 유지보수할 수 있는지 등이다. 한 명에서 수백 명을 대상으로 하는 팩토리 산출물은 이런 것을 신경 쓸 필요가 없다. 그 결과 더 빠르고 느슨하게 출시할 수 있다.

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

  • 유지보수 부담이 줄어든다. 기능 요청에 “사양합니다”라고 말하는 것이 그 어느 때보다 쉬워졌다. 생산 수단의 핵심적인 부분을 제공하고 있기 때문이다. 슬롭 요청에 대한 나의 고충은 매우 공개적이어서 “no machine”까지 만들 정도였지만, “거절”에 대해 날이 갈수록 죄책감을 덜 느끼고 있다.

  • R&D가 외주화된다. 이제 메인테이너로서 다른 사람들이 무엇을 하는지 보고, 동작하는 개념 증명(PoC)을 확인한 뒤, 무엇을 메인라인으로 가져올지 결정하는 것이 훨씬 쉬워졌다. 말은 훨씬 줄고 실행은 훨씬 늘었다. 그리고 다른 사람들이 실행하는 동안 당신은 최고의 아이디어를 골라낼 수 있다(이는 공평하다. 당신은 빌딩 블록을 제공하고 그들은 아이디어를 제공하는 셈이니까).

그 영향

이것이 내가 소프트웨어와 제품 개발을 바라보는 방식을 바꾸고 있다.

나는 빌딩 블록을 만들고 그 위에 애플리케이션이나 포크가 만들어지도록 장려하는 데 훨씬 더 의도적으로 임하고 있다. 이것이 더 행복하고 더 큰 커뮤니티, 그리고 궁극적으로 더 나은 메인라인 소프트웨어로 이어지고 있다고 생각한다.

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

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

방 안의 코끼리: 상업화

뒤따르는 당연한 질문은 이것이 상업화에 어떤 의미를 가질 수 있는가이다. 클로즈드 소스 상용 소프트웨어는 엄청난 불리함에 처한 것처럼 보인다. 그리고 실제로 그렇다.

에이전트는 클로즈드 상용 소프트웨어보다 개방적이고 무료인 소프트웨어를 훨씬 더 쉽게 선택할 것이다. 이 글을 쓰는 시점에서 이는 객관적인 사실이다. 인기 모델들에 대해 실험을 진행한 독립 연구소들은 다양한 상황에서 모델이 상용 대안보다 개방적이고 무료인 대안을 선택한다는 것을 반복적으로 발견했다. 적어도 지금까지는.

하지만 나는 여기에 대해 구체적인 답을 갖고 있지 않다. 제품 및 소프트웨어 개발과 달리, 지금 당장 상업화 가능한 제품을 직접 만들고 있지 않기 때문이다. 생각은 있지만, 모든 어려운 문제와 마찬가지로 답은 미묘하다고 생각한다. 하지만 이에 대해 권위 있게 말하는 듯한 인상을 주고 싶지 않으므로 이 부분은 피하려 한다. 직접 실행해보고 더 배우게 되면 더 공유하겠다.

나는 다시 한번 이 도전 과제가 명백히 존재한다는 점을 인정할 뿐이다.

전환은 이미 일어났다

우리는 빌딩 블록과 소프트웨어 공장이 우리 주변의 모든 것을 지배한다는 사실을 받아들이고, 그에 따른 결과를 받아들이고 내면화해야 한다.

우리는 반대 방향으로 달려가 그것에 맞서 싸우는 은신처를 만들 수도 있다. 혹은 완전히 혼돈에 몸을 맡길 수도 있다. 나를 아는 사람들은 내가 행동에 있어 훨씬 덜 극단적이며 맥락에 따라 다른 의견을 가지고 있다는 것을 안다.

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

각주

  1. 다만 빌딩 블록 자체는 보통 고품질이고 견고하며 문서화가 잘 되어 있어야 한다.

  2. Ghostty에는 실질적인 트래킹이 없으므로 정확한 수치를 얻는 것은 당연히 어렵다. macOS의 경우 집계된 업데이트 파일 확인 수는 볼 수 있다. Linux에 대해서는 전혀 가시성이 없다. libghostty에는 트래킹이 없지만 libghostty를 통합한 도구들에 트래킹이 있을 수 있으며, 그들이 집계 수치를 우리와 공유해 주었다.

  3. 나는 여기서 “에이전트”라는 용어를 단순히 도구에 접근할 수 있는 루프 안의 대형 언어 모델을 의미하는 것으로 사용한다. 사람들이 내가 마케팅 용어를 써서 과장하거나 귀엽게 보이려 한다고 생각할 때도 있지만, 나는 이를 특정하고 널리 받아들여지는 정의로 사용하고 있다.

이 글은 muse-spark-1.2-contributor 모델을 사용해 번역했습니다.

댓글