Foundations - 07. 빌드 vs 구매 vs 조달

직접 요리할까, 배달시킬까 — 빌드 vs 바이 vs 조달

식당을 운영한다고 하자. 메뉴 하나를 추가할 때 세 가지 길이 있다. 첫째, 재료부터 직접 요리한다 — 시간과 솜씨가 필요하지만 내 입맛대로 완벽하게 만든다. 둘째, 완성된 음식을 배달시킨다 — 빠르고 전문가가 만들어 품질이 보장되지만, 내 입맛에 안 맞을 수 있고 가게가 문을 닫거나 가격을 올리면 선택지가 줄어든다. 셋째, 반조리 밀키트를 사서 마지막만 완성한다 — 핵심 소스는 남이 만들었지만 내가 손을 대고, 레시피를 고칠 수도 있다.

소프트웨어 아키텍처에서도 같은 세 갈래가 있다. 직접 구현(build), 상용 소프트웨어·SaaS를 사서 쓰기(buy), 오픈소스를 가져와 맞춤(조달·adopt). 어느 쪽이든 무료가 아니다 — 각각 다른 종류의 비용을 치른다. 문제는 "뭘 사고 뭘 만들까"가 아니라 "무엇이 우리의 시그니처 메뉴인가"를 가리는 일이다.

이 비유의 한계: 요리는 한 번 만들면 끝이지만, 소프트웨어는 유지보수와 업그레이드가 지속된다. "배달 음식"은 한 번이지만 소프트웨어 "바이"는 지속적 관계다 — 라이선스 갱신, 버전 업그레이드 강제, 호환성 변화가 따라온다.

직접 만들기(build) — 완벽한 제어의 대가

직접 구현하면 요구사항에 정확히 맞는 시스템을 만들 수 있다. 결제 로직, 권한 모델, 데이터 파이프라인 — 비즈니스의 핵심이 되는 부분은 직접 짜는 게 자연스럽다. 제어가 완벽하고, 변경이 자유롭고, 외부 의존이 없다.

대가는 시간과 인력이다. 직접 만든 건 직접 유지보수해야 한다. 결제 모듈을 직접 짜면, PG사 API가 바뀔 때마다, 새로운 결제 수단이 나올 때마다, 보안 패치가 필요할 때마다 그 코드를 고칠 사람이 필요하다. 만든 팀이 떠나면 그 코드는 레거시가 된다. "직접 만들면 싸다"는 건 계산에서 유지보수 비용이 빠져 있을 때만 성립한다.

직접 만들어야 하는 것의 기준은 단순하다 — 그것이 비즈니스의 차별적 경쟁력이 되는가. 추천 알고리즘이 우리 서비스를 경쟁사와 가르는 핵심이라면, 그건 직접 만든다. 반면 PG사 연동은 차별성이 없다 — 누구나 같은 API로 같는 일이다.

사서 쓰기(buy) — 벤더 종속의 무게

상용 소프트웨어나 SaaS를 쓰면, 남이 만들고 유지보수하는 시스템을 가져다 쓴다. 인증(Auth0), 결제(Stripe), 모니터링(Datadog), 메시징(Confluent Cloud) — 이런 영역은 전문 업체가 훨씬 잘 만든다. 그들의 핵심 역량이니까. 빠르게 도입할 수 있고, 보안·컴플라이언스를 업체가 책임진다.

대가는 벤더 종속(vendor lock-in)이다. 단골 식당에 종속되는 것과 같다 — 그 가게의 메뉴가 바뀌거나 가격이 오르거나 문을 닫으면, 내 메뉴도 흔들린다. SaaS가 가격 정책을 바꾸면 내 비용 구조가 바뀐다. API가 breaking change를 내놓으면 내 코드를 고쳐야 한다. 서비스가 종료되면 이전해야 한다. 벤더의 로드맵이 내 비즈니스 요구와 어긋나면, 내가 벤더를 기다리게 된다.

벤더 종속을 완전히 피하면서 SaaS를 쓰는 건 현실적으로 어렵다 — 종속은 SaaS의 본질이다. 현실적인 전략은 종속의 정도를 관리하는 것이다. 데이터 이식성(내 데이터를 내가 export할 수 있는가), 대체 가능성(비슷한 서비스가 있는가), 추상화(벤더 API를 직접 호출하지 않고 인터페이스 뒤에 숨기는가)으로 종속 깊이를 가늠한다. Richards와 Ford는 에서 아키텍처 특성을 기준으로 make-or-buy를 판단하라고 조언한다 — 그 구성요소가 요구하는 품질 속성(보안 규준, 데이터 주권, 확장성)이 상용 서비스로 충족되는지 먼저 따져야 한다.

오픈소스(조달·adopt) — 반조리의 자리

오픈소스는 직접 만들기와 사서 쓰기 사이의 중간 지대다. 핵심 소스는 커뮤니티가 만들지만, 내가 가져와 맞추고, 필요하면 고치고, 기여할 수도 있다. Spring Framework, Kafka, PostgreSQL, Redis — 인프라의 상당 부분을 오픈소스로 채우는 게 업계 표준이다.

오픈소스의 장점은 벤더 종속이 없다는 것이다 — 소스가 공개되어 있어 내가 유지보수할 수 있고, 커뮤니티가 건강하면 버그 수정과 발전이 빠르다. 하지만 "무료"가 아니다. 통합 비용, 업그레이드 추적, 보안 취약점 패치, 커뮤니티 동향 파악에 인력이 든다. 그리고 커뮤니티가 죽으면 — 업데이트가 멈추고 취약점이 방치되면 — 그 프로젝트는 우리 짐이 된다. 반조리 밀키트도 유통기한이 있고, 조리법이 바뀌면 다시 익혀야 한다.

무엇이 핵심 자산인가

세 갈래를 놓고 고르는 기준은 하나로 귀결된다 — 이것이 우리 비즈니스의 핵심 자산인가, 아니면 부속인가. 핵심 자산은 직접 만든다. 부속은 사거나 오픈소스로 채운다. Newman은 에서 서비스 경계를 정할 때 "이 서비스가 비즈니스의 차별성을 담는가"를 기준으로 삼아야 한다고 본다 — 차별성이 없는 부속(인증, 알림, 결제 연동)을 직접 만드는 건, 경쟁력을 만드는 데 쓸 인력을 부속에 쏟는 것이다.

식당으로 돌아가면, 시그니처 메뉴의 소스 레시피는 비밀이고 직접 만든다. 하지만 밥·김치·수저는 사 와도 된다 — 그것들이 식당의 정체성을 결정하지 않으니까. 소프트웨어도 마찬가지로, "우리만의 것"과 "누구나 쓰는 것"을 가르는 것이 make-or-buy의 출발점이다.

설계 사례 — 인증·결제·추천의 make-or-buy 결정

한 스타트업이 세 가지 기능의 make-or-buy를 결정한다고 하자. 각 기능에 대해 "이것이 우리 비즈니스의 핵심 자산인가, 부속인가"를 묻는다.

flowchart TD
    Start["기능 X"] --> Q1{"비즈니스 차별성이<br/>있는가?"}
    Q1 -->|"있다 (경쟁 우위)"| Build["직접 구현 (Build)"]
    Q1 -->|"없다 (공통)"| Q2{"검증된 서비스가<br/>있는가?"}
    Q2 -->|"있다 (Auth0, Stripe)"| Buy["사서 쓰기 (Buy)"]
    Q2 -->|"제한적" | Q3{"오픈소스가<br/>건강한가?"}
    Q3 -->|"그렇다"| Adopt["오픈소스 채택 (Adopt)"]
    Q3 -->|"아니다"| Build

세 기능에 이 트리를 적용한다:

기능	차별성?	검증된 서비스?	결정	이유
인증	없음	Auth0, Firebase Auth	Buy	보안·컴플라이얼스(OAuth, MFA)를 전문가에게 맡김
결제	없음	Stripe, Toss	Buy	PG사 연동·정산·웹훅을 직접 짜면 유지보수만 늘음
추천 알고리즘	있음	—	Build	추천 품질이 쇼핑몰의 경쟁 우위 — 남의 알고리즘에 의존하면 차별성 없음

// Buy: 인증 — Auth0 SDK를 어댑터 뒤에 숨김
public class Auth0Authenticator implements Authenticator {
    private final Auth0Client client;   // Auth0 SDK

    public UserInfo verify(String token) {
        DecodedJWT jwt = client.verify(token);   // Auth0가 검증
        return new UserInfo(jwt.getSubject(), jwt.getClaim("email").asString());
    }
}
// 추후 Firebase로 바꾸면 이 어댑터만 교체 — 도메인은 모름

// Build: 추천 — 우리 알고리즘을 직접 구현
public class RecommendationEngine {
    public List<Product> recommend(CustomerId customerId) {
        PurchaseHistory history = repo.findHistory(customerId);
        return collaboratorFilter(history, similarCustomers(20));
        // 이 알고리즘이 경쟁 우위 — 외부 서비스에 맡기지 않음
    }
}

인증은 Auth0에 맡기면서도, Auth0 SDK를 도메인에 직접 노출하지 않는다 — Authenticator 인터페이스 뒤에 숨긴다(어댑터 패턴). 언제든 Firebase로 바꿀 수 있다. 반면 추천은 직접 짠다 — 추천 품질이 경쟁 우위이므로, 외부 서비스의 블랙박스 알고리즘에 의존하면 차별성이 사라진다.

이 결정이 고정이 아닌 점도 중요하다. 스타트업 초기에는 인증을 직접 짰을 수 있다(비용 절감). 하지만 사용자가 늘고 보안 요구가 높아지면(2FA, 소셜 로그인, 감사 로그), 직접 구현의 유지보수 비용이 Auth0 월 사용료를 초과한다 — 그때 Buy로 전환한다. 핵심 자산 목록은 주기적으로 재검토한다.

직접 만드는 것과 사는 것의 경계는 움직인다

한 가지 주의할 점이 있다. 핵심 자산의 범위는 고정이 아니다. 스타트업 초기엔 결제를 직접 짜는 게 핵심처럼 보일 수 있지만, 비즈니스가 자리 잡으면 결제는 "누구나 쓰는 것"으로 밀려나고, 다른 것이 핵심이 된다. 반대로, 사서 쓰던 것이 한계에 부딪히면 직접 만드는 쪽으로 옮겨간다 — SaaS 모니터링이 우리 규모에선 비싸거나 기능이 모자라면, 오픈소스 기반으로 자체 구축하는 식이다.

그래서 make-or-buy는 한 번의 결정이 아니라 주기적 재검토의 대상이다. 핵심 자산 목록을 정기적으로 들여다보고, "이게 여전히 우리가 직접 만들어야 할 것인가"를 묻는다. 식당의 시그니처 메뉴도 손님 입맛이 바뀌면 바뀐다 — 고정된 메뉴판에 매달리면 경쟁에서 밀린다.

---

참고

• Richards, Ford — (O'Reilly, 2020), Ch.3 (아키텍처 특성 기반 make-or-buy 판단) — 접근 2026-07-15
• Newman, Sam — (2nd ed, O'Reilly, 2021), Ch.2 (서비스 경계와 핵심 자산) — 접근 2026-07-15