build-vs-buy 결정을 어떻게 내립니까?

Question

Accepted Answer

**build vs. buy**는 무언가를 자체 개발할지 기존 제품이나 서비스를 채택할지를 묻습니다. 만들려는 본능은 강하고 종종 틀립니다. 만드는 것의 진짜 비용은 첫 버전뿐 아니라 수년간의 유지보수를 포함합니다. 결정은 그것이 당신의 비즈니스에 *핵심*인지에 달려 있습니다.

## 의사결정 프레임워크

```text
BUY로 기울 때:                      BUILD로 기울 때:
- 당신의 핵심 차별점이 아니다        - 그것이 핵심 가치/차별점이다
- 성숙한 솔루션이 존재한다           - 당신 요구에 맞는 좋은 솔루션이 없다
- 출시 속도가 중요하다               - 깊은 통제/맞춤화가 필요하다
- 유지보수할 전문성이 부족하다       - buy의 장기 비용이 감당 불가하다
- buy의 TCO < build+유지보수         - vendor lock-in이 용납 불가한 위험이다
```

## 구체적인 예시

자체 auth 시스템을 만들지 마십시오. identity는 어렵고, security-critical이며, 당신의 차별점이 아닙니다. 검증된 provider를 buy/integrate하십시오. 추천이 제품을 특별하게 만든다면 핵심 recommendation engine은 *직접* 만드십시오. 당신을 *당신답게* 만드는 것은 build하고, 나머지는 buy하십시오.

## 진짜 비용을 계산하라

팀은 만드는 것을 만성적으로 과소평가합니다. 첫 버전은 생애 비용의 20%입니다. 유지보수, 보안 패치, edge case, on-call이 그것을 압도합니다. 스프린트에 출시할 수 있는 데모가 아니라 수년에 걸친 total cost of ownership을 계산하십시오.

## 함정

"Not invented here"는 이미 해결된 문제를 다시 만들게 하고, 맹목적 buy는 vendor lock-in과 맞지 않는 도구로 이어집니다. 사례별로 신중히 결정하십시오.

## 왜 중요한가

잘못된 것을 자체 구축하면 수년의 엔지니어링 노력이 차별화되지 않는 작업에 소진됩니다.

이것을 제대로 하면 희소한 엔지니어링 시간을 실제로 비즈니스를 이기게 하는 것에 집중하게 됩니다.