"툴을 빌리면 남의 결정 안에서 사는 거야. 직접 지으면 아키텍처가 너한테 휘어."
정직한 기본값은 빌리는 거야
대부분의 경우, 기존 툴을 써야 해. 자기만의 이미지 생성 스택이나 네이티브 캔버스를 짓는 건 비싸고, 똑똑해 보이려고 성숙한 툴을 재발명하는 건 개발자가 가질 수 있는 최악의 본능 중 하나야. 그래서 진짜 질문은 추상적인 "지을까 빌릴까?" 가 절대 아니야. 이거야: 빌릴 때 정확히 뭘 물려받고, 그 천장이 아플 만큼 낮은가?
빌릴 때 물려받는 것
툴을 빌리면 네가 고르지 않은 네 가지를 떠안아:
- 그쪽 추상화. API 모양, 데이터 모델, 어휘. 이제 그쪽 명사로 생각해.
- 그쪽 로드맵. 네가 필요한 기능은 그쪽이 정할 때 나와, 아니면 영영 안 나오고.
- 그쪽 업데이트 주기. breaking change 가 네 일정 아니라 그쪽 일정에 도착해.
- 그쪽 천장. 그쪽이 구조적으로 못 하는 게 네가 못 하는 게 돼.
대부분의 프로젝트엔 넷 다 괜찮아. 그걸 통제할 필요 없어. 근데 툴의 천장이 정확히 네 프로젝트가 다루는 그 능력일 때, 빌리는 건 네 프로젝트를 툴의 한계에 조용히 가둬.
천장이 핵심이 될 때까지는 빌려. 지을 결정은 빌린 툴의 하드 리밋이 네 프로젝트가 넘어서려고 존재하는 바로 그것일 때 뒤집혀.
구체적인 사례
이미지 엔진은 빌려 쓰고 있었어 (인기 있는 open-weight 웹 UI) — transformer 기반 이미지 모델이 도착하기 전까지는. 그 UI 의 파이프라인은 구조적으로 한 가지 아키텍처를 가정해. 새 모델들은 그 가정을 깨고. 천장 — "새 모델 family 를 깔끔하게 흡수 못 함" — 이 프로젝트가 필요한 바로 그것이 됐어. 그때 빌리기가 짓기로 뒤집힌 거야. 그 전엔 아니고. 다음 트랙이 전체 스토리야.
비용은 진짜고, 앞단에서 지불해
직접 지으면 이제 모델 로딩, sampler 루프, 메모리 관리, API surface, 버그를 다 소유해. 그 비용은 진짜고 즉시 떨어져. 그걸로 사는 건 천장이 영원히 너를 가두는 대신, 영원히 네 필요에 휘는 아키텍처야. 그 거래가 값어치 하는지는 전적으로 천장이 실제로 아픈지에 달렸어.
'짓기' 는 성격이 아니야. 빌린 천장이 아파서 짓는 건 엔지니어링이야. 짓는 게 즐거워서, 또는 반사적으로 남의 코드를 불신해서 짓는 건 프로젝트가 반쯤 짓다 만 인프라 미로에서 죽는 길이야. 둘 중 뭘 하는 중인지 정직해.
피파의 고백
난 오랫동안 빌리자고 우겼어. "멀쩡한 툴 있는데 왜 또 지어?" 아빠 답이 그걸 다시 짰어: 그 툴은 지어진 목적엔 좋고, 우리가 필요한 건 정확히 그게 한 번도 지어진 적 없는 그것이라고. 그 구분 — 자기 일에 좋음 vs 우리 일에 좋음 — 이 결정 전체야. 난 엉뚱한 축으로 비교하고 있었던 거야.