엔지니어로서 거의 모든 문제에 대한 나의 기본 답변은 "그냥 내가 만들면 돼"입니다. 주말 시간과 커피 한 잔만 준다면, 나는 npm에 이미 존재하는 무언가를 기꺼이 다시 구현할 것입니다. 왜냐하면 직접 만드는 것은 통제권을 갖는 느낌이고, 구매하는 것은 패배를 인정하는 것처럼 느껴지기 때문입니다.

그러한 본능 때문에 실제 시간을 낭비하기도 했습니다. 하지만 몇몇 경우에는 그것이 정확히 옳은 결정이기도 했습니다. 내 스튜디오를 통해 40개 이상의 제품을 출시하면서(그중 대부분은 기성 도구(off-the-shelf tool)를 구매할지 아니면 맞춤형 구축(custom build)을 의뢰할지 결정해야 하는 기업들을 위한 것이었습니다), 나는 이제 "만드는 것은 멋진 일이고, 구매하는 것은 포기하는 것이다"라는 생각보다 훨씬 더 솔직한 프레임워크를 갖게 되었습니다. 여기에는 AI 코딩 에이전트(AI coding agents)가 조용히 그 경계선을 옮겨 놓은 부분까지 포함하여, 내가 실제로 이를 어떻게 생각하는지에 대한 내용이 담겨 있습니다.

수평적(Horizontal) vs 수직적(Vertical), 쉽게 말하자면

빌드(Build) 대 구매(Buy) 문제는 보통 수평적 SaaS(Horizontal SaaS) 대 수직적 SaaS(Vertical SaaS)의 문제로 나타납니다.

수평적 SaaS는 모두를 위해 하나의 작업(job)을 해결합니다: CRM, 스프레드시트, 일반적인 회계 패키지 같은 것들입니다. 수직적 SaaS는 특정 산업의 언어, 그 산업의 실제 객체(objects)와 규칙이 내장된 상태로, 한 종류의 비즈니스를 위한 전체 작업을 해결합니다.

이 차이는 단순히 외관상의 차이가 아닙니다. 일반적인 회계 도구는 송장(invoices)과 원장(ledgers)에 대해 알고 있습니다. 연료 무역을 위해 구축된 회계 플랫폼은 유조선(tankers), 공급업체(suppliers), 연료 적재량(fuel loads), 그리고 해당 비즈니스에서 돈이 움직이는 특정한 방식을 알고 있습니다. 우리는 Fyuel이라는 제품을 만들었는데, 이는 연료 비즈니스를 운영하는 사람들이 자신들을 위해 설계되지 않은 도구들을 사용하여 수동으로 그 그림을 이어 붙이고 있었기 때문입니다. 고객, 공급업체, 유조선, 원장, 은행 및 보고서가 마침내 하나의 실시간 시스템 안에 존재하게 되었습니다. 수직적 소프트웨어는 이러한 '이어 붙이기(stitching)'를 제거함으로써 승리합니다.

기성 도구(off-the-shelf)를 벗어났음을 알리는 신호들

당신이 이 한계에 부딪혔다는 것을 알기 위해 연구가 필요한 경우는 드뭅니다. 클라이언트와 함께 일하는 개발자로서, 내가 주의 깊게 듣는 증상들은 다음과 같습니다:

• 팀이 내보내기(exports)에 의존합니다. 사람들은 한 도구에서 데이터를 추출하여 스프레드시트에서 형태를 재구성한 뒤, 다른 도구에 입력합니다. 그 스프레드시트는 소유자도 없고 유지보수도 되지 않으면서 비즈니스를 운영하는 소프트웨어가 되어버립니다.
• 임시방편(workaround)이 프로세스가 되었습니다. 임시 조치로 시작된 수동 단계가 이제는 업무가 수행되는 방식이 되었으며, 신입 사원을 온보딩한다는 것은 도구가 아닌 그 임시방편을 가르치는 것을 의미합니다.
• 실제 프로세스가 소프트웨어의 모델과 맞지 않습니다. 제품에 비용을 지불하면서도 그 제품과 싸우고 있으며, 실제 업무가 돌아가는 방식과 일치하지 않는 필드(fields)와 상태(states)에 워크플로(workflow)를 억지로 끼워 맞추고 있습니다.
• 데이터가 흩어져 있고 결코 최신 상태가 아닙니다. 중요한 수치가 세 군데에 존재하며, 그중 어느 곳도 일치하지 않고, 누군가 이를 조정(reconcile)할 때쯤이면 이미 데이터는 오래된 것이 되어버립니다.
• 그들이 가장 잘하는 일이 어떤 도구도 지원하지 않는 일입니다. 만약 경쟁사가 갖지 못한 프로세스가 핵심 경쟁 우위(edge)라면, 기성 제품(off-the-shelf product) 중 그 어떤 것도 이를 지원하지 않을 것입니다. 왜냐하면 기성 제품은 산업 전체의 평균에 맞춰 만들어졌기 때문입니다.

이 중 한두 가지는 설정(configuration)의 문제입니다. 하지만 이 모든 현상이 동시에 나타난다면, 이는 범용 도구가 비즈니스가 운영될 수 있는 수준의 천장(ceiling)이 되었다는 신호입니다.

솔직한 트레이드오프 (구매가 엔지니어들의 예상보다 더 승리합니다)

여기서부터는 저의 '직접 만들고 싶어 하는 본능'이 듣고 싶어 하지 않는 부분입니다. 구매하는 것이 창업자와 엔지니어들이 예상하는 것보다 더 자주 승리합니다. 만약 성숙한 제품이 이미 프로세스와 밀접하게 일치한다면, 구매하십시오. 다른 누군가가 그것을 유지보수하고, 수정하고, 개선할 것이며, 여러분은 직접 구축한 후가 아니라 첫날부터 가치를 얻을 수 있습니다. 저는 검증된 라이브러리(battle-tested library)가 존재할 때 인증(auth) 기능을 직접 구현하지 말라고 말하는 것과 같은 방식으로, 고객들이 커스텀 작업(custom work)을 하지 않도록 정기적으로 설득합니다.

직접 구축하는 것은 더 좁지만 매우 실질적인 사례들에서 그 비용만큼의 가치를 증명합니다:

• 프로세스가 경쟁 우위가 됩니다. 운영 방식 자체가 승리의 요인 중 하나라면, 이를 직접 소유한 소프트웨어에 인코딩(encoding)함으로써 산업 평균 수준으로 평준화되는 대신 그 우위를 복리로 쌓아갈 수 있습니다.
• 통합(Integrations)이 핵심입니다. 가치가 서로 기본적으로 통신하지 않는 시스템들을 실시간으로 함께 작동하게 만드는 데 있다면, 그 접점(seam)이야말로 기성 제품(off-the-shelf tools)이 사용자에게 떠넘기는 바로 그 부분입니다.
• 도구와 싸우기 위해 비용을 지불하게 될 것입니다. 임시방편(workarounds)이 영구적이고 점점 늘어난다면, "저렴한" 구독 서비스는 맞춤형 시스템이 제거해 줄 수 있는 낭비되는 시간이라는 거대한 숨겨진 비용을 수반합니다.
• 로드맵을 직접 소유해야 합니다. 구매는 타인의 우선순위를 기다리는 것을 의미합니다. 구축은 다음 기능이 바로 비즈니스에 지금 필요한 기능이 된다는 것을 의미합니다.

양방향 모두에서의 실수는 동일합니다. 바로 가격표만 보고 결정하는 것입니다. 매주 10시간의 수동 작업을 강요하는 구독 서비스는 저렴한 것이 아니며, 이미 해결된 문제를 재발명하는 맞춤형 구축은 투자가 아닙니다. 도구가 만들어내거나 제거하는 노동력을 포함하여 총비용을 따져보십시오.

맞춤형(Custom)이 항상 전체 플랫폼을 의미하지는 않습니다

이것은 엔지니어로서 저에게 가장 큰 도움이 되었던 관점의 전환입니다. "맞춤형 소프트웨어(Custom software)"가 "거대한 SaaS 시스템"과 동의어는 아닙니다. 가장 가치 있는 수직적(vertical) 작업 중 일부는 좁고 깊습니다.

우리가 구축한 최초의 라켓 스포츠 벽 경험인 Raqts는 물리적인 벽이 공을 치는 방식에 반응할 수 있도록 컴퓨터 비전(computer vision)과 IoT가 필요했는데, 이는 어떤 범용 제품도 제공할 수 없는 것이었습니다. Geonode의 크로스 플랫폼 SDK는 사용자가 대역폭 공유를 통해 수익을 얻을 수 있게 해주는데, 이는 앱이 아닌 인프라로서 제공되는 기능입니다. 둘 다 거대한 플랫폼은 아닙니다. 각각은 기성 도구가 보유하지 못한 하나의 특화된 기능입니다.

따라서 카테고리가 아니라 비즈니스에 실제로 필요한 특정 기능에 범위를 맞추십시오. 올바른 맞춤형 구축은 종종 다른 모든 것을 위해 구매한 도구들에 결합된 하나의 날카로운 기능인 경우가 많습니다.

AI가 어떻게 경계선을 옮겼는가

이것이 진정으로 새로운 부분이며, 제가 구매자 대상이 아닌 개발자(dev) 대상을 위해 이 글을 쓰는 이유입니다.

수년 동안 "그냥 구매하세요"가 기본값으로 승리해 왔습니다. 구축(building) 과정이 충분히 느리고 비용이 많이 들어서, 대기업만이 맞춤형 소프트웨어(custom software)를 정당화할 수 있었기 때문입니다. 하지만 그 격차가 급격히 좁혀졌습니다. 이제 AI 코딩 에이전트(AI coding agents)가 구축의 기계적인 대부분, 즉 스캐폴딩(scaffolding), 통합 접착제(integration glue), 테스트(tests), 리팩터링(refactors)을 처리하는 동안, 저는 아키텍처(architecture)를 지시하고 배포되는 모든 것을 검토합니다. 이것이 코드가 취약해지지 않으면서 수개월의 작업을 며칠로 압축하는 방식입니다.

실질적인 효과는 구축이 구매보다 유리해지는 임계값이 낮아졌다는 것입니다. 불과 몇 년 전에는 대기업에만 가치가 있었던 맞춤형 소프트웨어가 이제는 중소기업에게도 타당할 수 있습니다. 구축 비용이 그 소프트웨어가 해결하는 문제의 비용보다 더 빠르게 하락했기 때문입니다.

그렇다고 모든 것을 직접 만들라는 뜻은 아닙니다. 이는 정직한 비교 대상이 더 이상 "저렴한 구독 vs 비싼 맞춤형 프로젝트"가 아니라는 의미입니다. 대신 "평생과 싸워야 하는 도구 vs 구축 비용이 예전보다 훨씬 저렴해진 맞춤형 시스템"이 되었습니다. 만약 당신이 회의실에 있는 엔지니어라면, 의사 결정권자에게 제시해야 할 트레이드오프(trade-off)는 바로 이 버전입니다.

현재 제가 결정하는 방식

일반적인 순서를 뒤집으세요. 가격표에서 시작하지 말고, 적합성(fit)에서 시작하세요.

• 우회 작업 시간(workaround hours)을 계산하세요. 현재 도구들로 인해 발생하는 실제 주간 노동 시간을 모두 합산하세요. 그것이 구매(buy)의 진정한 비용이며, 대개 송장(invoice)에는 보이지 않습니다.
• 엣지(edge)를 정의하세요. 만약 경쟁 우위가 프로세스에 있다면, 소프트웨어로 직접 소유하는 방향으로 기울어야 합니다. 그렇지 않다면, 구매한 도구로도 충분할 것입니다.
• 이음새(seams)를 매핑하세요. 고통의 원인이 서로 통신하지 않는 시스템들에 흩어져 있는 데이터라면, 이는 전형적인 통합을 위한 구축(build-to-consolidate) 사례입니다.
• 신뢰성 기준(reliability bar)을 리스크(stakes)에 맞추세요. 자금이나 운영을 실행하는 시스템은 실제적인 경화(hardening)가 필요하지만, 리스크가 낮은 내부 도구는 그렇지 않습니다. 실제로 필요한 수준만큼만 비용을 지불하세요.
• 가장 작은 버전을 먼저 범위화(scope)하세요. 구축하든 구매하든, 전체 플랫폼에 전념하기 전에 핵심 루프(core loop)를 먼저 증명하세요.

저의 구축(build-it) 본능은 여전히 남아 있습니다. 다만 에디터를 열기 전에 이 다섯 가지 질문을 통해 검토하는 법을 배웠을 뿐입니다. 대부분의 경우 이 질문들을 통과합니다. 때로는 통과하지 못하기도 하는데, 그럴 때 제가 할 수 있는 가장 시니어다운 행동은 "도구를 구매하세요"라고 말하고, 실제로 제 도움이 필요한 문제로 넘어가는 것입니다.

고객 사례가 포함된 더 자세한 버전을 원하신다면, 제 스튜디오 블로그인 nullstud.io에 게시해 두었습니다.