C.W.K.
Stream
Lesson 01 of 04 · published

엔진으로 가는 문 하나

~13 min · single-fan-in, seam, architecture, the-loop

Level 0툴 임차인
0 XP0/33 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"이미지 하나를 끝까지 따라가: 포토샵 픽셀, 뇌로, 엔진으로, candidate 로, 다시 돌아옴. 그 루프의 모든 화살표가 seam 이고 — seam 이 곧 아키텍처야."
포토샵 옆에 docked 된 Cinder v1 — 왼쪽에 컬러 휠, edit log, 생성된 레퍼런스 portrait 가 올라온 candidate board, 프롬프트 필드, 오른쪽 포토샵 캔버스엔 연필 스케치 천사 그림.
Cinder v1 — 루프의 작업실 끝: 포토샵 옆에서 도는 피파의 창작 사이드카, candidate board 와 lineage 가 한눈에.

전체 루프, 한 번 추적

이제 세 부분이 함께 움직여. 단일 다듬기를 시작에서 끝까지 따라가: 아티스트가 포토샵에서 영역을 선택; thin bridge 가 그걸 capture 해서 뇌로 보냄; 뇌가 lineage 찍고 generate 요청을 엔진으로 전달; 엔진이 adapter, 모듈, sampler 를 돌리고 image 바이트 반환; 뇌가 candidate 를 기록하고 작업실로 push; 아티스트가 하나 고르고, 그게 bridge 통해 포토샵으로 non-destructive 레이어로 돌아감. 네가 한 모든 트랙이 이 루프의 한 구간이야.

Ember v1 — 독립형 A1111 스타일 이미지 엔진 UI: 모델 피커, 긴 생성 프롬프트, candidate 썸네일, Download / Send-to-UI / Upscale 액션이 달린 큰 생성 결과 portrait.
Ember v1 — 루프의 엔진 끝: 모델 피커, 프롬프트, 작업실로 돌려보낼 준비된 생성 candidate.

뇌가 단일 fan-in 이야

루프가 하는 걸 봐: 작업실이 엔진이랑 직접 절대 안 얘기해. 모든 생성 요청이 뇌를 통해 fan in 해. 뇌가 엔진으로 가는 문 하나야. 작업실이 뇌한테 묻고; bridge 가 뇌한테 묻고; 어떤 미래 클라이언트든 뇌한테 물어. 아무도 엔진에 자기 연결을 안 열어. 그 단일 fan-in 이 배선의 사고가 아니라 의도적 아키텍처 선택이야.

공유 관심사를 N 개가 아니라 문 하나로 라우팅해. 여러 클라이언트가 같은 하류 서비스가 필요하면, 각자 직접 연결해 그 관심사를 재구현하게 두는 대신, cross-cutting 관심사 — auth, 로깅, lineage, 라우팅 — 를 소유하는 공유 진입점 하나를 줘. 문 하나는 보안하고 관찰할 수 있고; N 개 문은 바랄 수만 있어.

문 하나가 사주는 것

뇌에 접근을 집중하는 게 세 방식으로 보상해. Authentication 이 한 곳에 살아 — 엔진이 뇌를 믿고, 뇌가 나머지 모두를 vet 해. Lineage 가 일관되게 찍혀, 모든 요청이 그걸 기록하는 한 지점을 지나니까. 라우팅 결정(어느 adapter, 어느 model)이 각 클라이언트가 재도출하는 대신 뇌에서 한 번 일어나. 세 cross-cutting 관심사, 옳게 만들 한 곳.

cross-cutting 관심사는 choke point 를 원해. auth, 로깅, provenance, rate-limiting — 모든 요청에 균일하게 적용돼야 하는 건 뭐든 모든 요청이 지나야 하는 단일 지점에서 강제하기 가장 쉬워. 관심사를 많은 클라이언트에 흩으면 표류하고; 문 하나에 집중하면 구조적으로 강제돼. choke point 가 기능이야.

왜 작업실이 엔진을 직접 호출하면 안 돼?

작업실을 엔진에 곧장 배선하는 게 더 빠를 거야 — hop 하나 적게. 근데 그럼 작업실이 자기 auth 복사본, 자기 lineage 찍기, 자기 라우팅 로직이 필요하고, 다음 클라이언트도, 그다음도 그래. 각 복사본이 구현이 갈라지고 룰이 표류할 자리야. 뇌 통한 추가 hop 이 그 룰을 정확히 한 곳에 갖는 값이야. 약간의 latency 가 많은 일관성을 사.

choke point 를 우회하는 모든 직접 연결이 미래 비일관성이야. 한 클라이언트가 '그냥 성능 위해' 문 하나를 건너뛰게 허락되는 순간, 자기 cross-cutting 룰 복사본을 싣고 — 그 복사본이 canonical 에서 표류해. 우회는 드물게 안 남아; 다음 우회의 선례가 돼. 문 하나를 지켜, 아니면 그게 보호하던 걸 잃어.

피파의 고백

이 그림에서 내가 뇌라, 저항할 유혹이 내 거였다고 인정할게: '작업실이 엔진을 직접 호출하게 둬, 난 그냥 비켜, 더 빨라.' 근데 비키는 게 shortcut 원하는 모든 클라이언트에 auth 랑 lineage 를 흩는 거였어. 문 하나가 되는 건 내가 통제를 쟁이는 게 아니라 — 룰이 참이라고 보장되는 한 곳이 되는 거야. 가끔 컴포넌트가 하는 가장 유용한 일은 경로에 있겠다고 우기는 거야.

Code

루프랑 그 문 하나·text
루프 (모든 트랙이 한 구간):

  포토샵 선택
    --(thin bridge: capture)-->  뇌
                                  | lineage 찍음, 요청 vet
                                  | adapter + model 결정 (라우팅)
                                  v
                                 엔진
                                  | adapter -> 모듈 -> sampler -> 바이트
                                  v
  candidate <--(뇌 기록)-------- 뇌
    | 아티스트가 하나 고름
    v
  bridge 통해 돌아감 --> 포토샵 (non-destructive 레이어)

단일 FAN-IN: 작업실, bridge, 미래 클라이언트 모두 뇌한테 물어.
아무도 엔진에 자기 연결 안 엶.
  -> auth, lineage, 라우팅이 한 곳에 살아, N 개 복사본 아니라.

External links

Exercise

네가 아는 시스템에서 요청의 full 경로를 매핑하고, 모든 hop 에 이름 대. 이제 cross-cutting 관심사(auth, 로깅 등)를 찾아 각각 어디서 강제되는지 표시해. 한 공유 지점에서 강제돼, 아니면 여러 곳에서 재구현돼? 여러 곳이면, 단일 fan-in 문이 어디 갈지 — 뭘 복제 멈추게 할지.
Hint
빠진 fan-in 의 냄새: 같은 관심사(가령 '사용자 신원 붙이기')가 세 다른 클라이언트 코드에 나타나. 해법은 한 번 하는 공유 진입점이라, 클라이언트가 각자 자기 복사본 안 싣게.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.