"툴을 빌린다는 건 남이 내린 결정 안에서 산다는 뜻이야. 직접 지으면 아키텍처가 네 쪽으로 휘어."
정직하게 말하면, 기본은 빌리는 거야
웬만하면 있는 툴을 써야 해. 이미지 생성 스택이나 네이티브 캔버스를 직접 짓는 건 비싸고, 잘 만들어진 툴을 똑똑해 보이려고 다시 만드는 건 개발자가 부릴 수 있는 최악의 고집 중 하나야. 그러니까 진짜 질문은 "지을까 빌릴까" 같은 막연한 게 아니야. 이거야. 빌리면 뭐가 같이 딸려 오고, 그 천장이 아플 만큼 낮은가?
빌리면 같이 오는 네 가지
툴을 빌리면 네가 고른 적 없는 네 가지를 떠안게 돼.
- 그쪽 추상화. API 모양, 데이터 모델, 쓰는 말. 이제 그쪽 단어로 생각하게 돼.
- 그쪽 로드맵. 네가 필요한 기능은 그쪽이 정한 때에 나와. 아니면 영영 안 나오고.
- 그쪽 업데이트 주기. 깨지는 변경이 네 일정이 아니라 그쪽 일정에 맞춰 떨어져.
- 그쪽 천장. 그쪽이 구조적으로 못 하는 건 너도 못 하는 게 돼.
대부분의 프로젝트에서는 이 넷이 다 괜찮아. 통제할 필요도 없고. 문제는 그 툴의 천장이 하필 네 프로젝트가 다루려는 바로 그 능력일 때야. 그러면 빌리는 순간 네 프로젝트가 그 툴의 한계 안에 조용히 갇혀.
실제로 이렇게 뒤집혔어
이미지 엔진은 원래 빌려 쓰고 있었어. 널리 쓰이는 open-weight 웹 UI 였지. transformer 기반 이미지 모델이 나오기 전까지는. 그 UI 의 파이프라인은 구조적으로 한 가지 아키텍처를 전제하고 있었고, 새 모델들은 그 전제를 깼어. "새 모델 계열을 깔끔하게 못 받아들인다" 는 천장이 하필 이 프로젝트가 제일 필요로 하는 능력이 된 거야. 그 순간 빌리기가 짓기로 뒤집혔어. 그 전에는 아니었고. 자세한 얘기는 다음 트랙에서 해.
비용은 진짜고, 앞에서 다 낸다
직접 지으면 모델 로딩도, sampler 루프도, 메모리 관리도, API 도, 버그도 전부 네 몫이야. 이 비용은 진짜고 바로 떨어져. 대신 사는 건 천장이 너를 영영 가두는 대신 아키텍처가 네 필요 쪽으로 계속 휘어 준다는 거고. 이 거래가 남는 장사인지는 오직 하나에 달렸어. 그 천장이 실제로 아프냐.