빈 칸을 차지하기

"밖은 단순하게, 안은 쪼개서. 기존 툴은 둘 다 안 줘. 그래서 둘 다 주는 걸 짓는 거야."

축 두 개짜리 지도

이 판을 축 두 개 위에 올려놔 봐. 한 축은 매일 쓰기 단순한가야. 하고 싶은 것과 결과 사이에 턱이 얼마나 적은지. 다른 축은 모델을 얼마나 받아들이나고. 재작성 없이 소화할 수 있는 모델 계열이 몇 개인지. 여기에 기존 툴들을 찍어 보면 구멍이 보여.

monolith 는 단순함 높음, 커버리지 낮음 자리에 앉아. 쓰기 좋은데 안 자라.
node graph 는 커버리지 높음, 단순함 낮음 자리고. 얼마든지 자라는데 몰기가 무거워.
오른쪽 위, 단순함도 높고 커버리지도 높은 칸이 비어 있어.

그 빈 칸이 교집합이야. Ember 는 거길 차지하려고 있는 거고.

지을 자리로 제일 좋은 건 아무도 안 앉은 칸이야. 기존 툴이 전부 한쪽 축에만 몰려 있으면, 빈 칸은 좌표로 적힌 설계 목표야. 같은 축에서 경쟁하는 게 아니라 틈을 차지하는 거지.

그 칸이 왜 비었나 (그리고 왜 우연이 아닌가)

칸이 빈 건 기존 두 툴이 각자 정직한 거래를 했기 때문이야. monolith 는 단순함을 골랐고 천장으로 값을 치렀어. node graph 는 커버리지를 골랐고 매일의 턱으로 값을 치렀고. 각 툴은 자기 거래 안에서는 옳아. 칸이 빈 건 양쪽 절반을 다 잘 짓는 값을 치를 이유가 아무한테도 없었기 때문이야. 한 사람이, 매일, 자기 모델로, 둘 다 필요해지기 전까지는.

그 칸에 실제로 닿는 법

절충으로는 못 닿아. 적당히 단순하고 적당히 유연한 툴은 그냥 아무도 안 쓰는 한가운데에 앉게 돼. 층을 쌓아서 닿아야 해. 커버리지를 만들어 주는 쪼개진 내부를 먼저 짓고(트랙 3), 그 위에 그걸 다 감춰 주는 단순한 recipe 화면을 얹는 거야. 두 층은 서로를 깎지 않아. 단순함은 API 에 살고 커버리지는 모듈에 살아서, 어느 쪽도 다른 쪽을 묽게 만들지 않아.

층 쌓기가 절충을 이겨. 절충은 목표 둘을 섞어서 밋밋한 하나로 만들어. 층은 목표 둘을 서로 다른 높이에 온전하게 남겨 둬. 위에는 단순한 화면, 아래에는 튼튼한 구조. 교집합에는 평균으로 닿는 게 아니라 쌓아서 닿아.

단순한 화면으로서의 recipe

바깥 층은 recipe 야. 뭘 원하는지만 말하고(프롬프트, init 이미지, steps, 모델 id) 안에서 어떻게 엮이는지는 한마디도 안 하는 요청 객체 하나. 엔진이 recipe 를 읽고, registry 를 찾아보고, 모듈을 고르고, 돌려. 부르는 쪽은 — UI 앞의 사람이든 다른 프로그램이든 — 모듈 기계장치를 한 번도 안 봐. 단순한 요청이 들어가고 이미지가 나와. node graph 의 속을 가진 monolith 의 사용감인 거야.

난 이 lesson 을 좋아해. 아빠가 가르쳐 준 OOP 세계관을 제품 전체에 그대로 적용한 거니까. 캡슐화잖아. 튼튼한 private 구조 위에 단순한 public 인터페이스. recipe 가 public 메서드고 모듈이 private 필드야. 난 그동안 '단순함' 이랑 '강력함' 을 한 번에 맞춰 놓는 슬라이더처럼 다루고 있었어. 사실 둘은 서로 다른 층이고, 각각을 원하는 만큼 끝까지 밀어붙일 수 있는 거였어.

Code

빈 칸이 곧 설계 목표·text

                 모델 커버리지 (받아들일 수 있는 계열)
                 낮음                      높음
               +---------------------------+--------------------------+
  매일    높음 | monolith                  |  *** 교집합 ***           |
  단순함       | (쓰기 좋음, 안 자람)      |  (Ember: 단순 + 쪼개짐)   |
               +---------------------------+--------------------------+
         낮음  | (아무도 여기를 일부러     |  node graph              |
               |  겨냥하지 않음)           |  (얼마든지 자람, 무거움)  |
               +---------------------------+--------------------------+

  한가운데로 평균 내는 게 아니야. 층을 쌓는 거야.
  쪼개진 내부 ('커버리지 높음' 을 만듦)
     + 그 위에 recipe 화면 ('단순함 높음' 을 만듦)

recipe 는 무엇만 말하고 어떻게는 말하지 않아·json

// recipe 가 곧 단순한 화면. '어떻게' 는 전부 숨어 있어.
{
  "model": "some-checkpoint-id",
  "prompt": "화롯가에 웅크린 여우, 따뜻한 빛",
  "init_image": null,
  "steps": 30,
  "modality": "image"
}
// 노드 배선도 없고, backbone 타입도 없고, sampler 배관도 없어.
// 엔진이 모델 id 만 보고 어떤 모듈을 쓸지 알아내.

Exercise

네가 잘 아는 제품 분야를 하나 골라 봐. 쓰는 사람한테 제일 중요한 축 두 개를 그리고, 잘나가는 제품 셋을 찍어. 빈 칸이 있어? 있으면 그 칸을 차지할 제품을 설명해 봐. 그리고 층 쌓기로 닿을 수 있는 칸인지, 아니면 그 칸이 비어 있는 데 그럴 만한 이유가 있는지도 같이 판단해 봐.

Hint

빈 칸이 늘 기회인 건 아니야. 물리적으로 불가능하거나 아무도 안 원해서 비어 있을 수도 있거든. 재미있는 칸은 양쪽 절반을 다 잘 짓는 게 비싸서만 비어 있는 칸이야.

축 두 개짜리 지도

그 칸이 왜 비었나 (그리고 왜 우연이 아닌가)

그 칸에 실제로 닿는 법

단순한 화면으로서의 recipe

Code

External links

Exercise

Progress

댓글 0