🎭

Avatars Quest

신규: 2026-10-28최근 수정: 2026-10-27

그림은 한 장도 안 그리면서 그림의 주인 노릇을 하는 스튜디오야. 권한은 피파 쪽으로만 흐르고, 모든 두뇌가 같은 관문을 지나. 계획은 돈 쓰기 전에 거절하고, 워커는 결과를 모르면 다시 보내지 않고 맞춰 봐. 보호는 픽셀을 따라가

Ember가 만들고, Avatars가 기억해. Avatars는 이 집 이미지가 지나가는 길이야. 소울마다 아바타 원본을 쥐고 있고, 소울이나 사람 그림을 만들 때 꼭 써야 하는 레퍼런스도 쥐고 있어. 스타일을 한결같이 지켜 주는 이름 붙은 룩과 하우스 룰도 여기 있고, 이미지마다 어떻게 태어났는지도 기록해. 그런데 픽셀은 한 점도 안 그려. 생성은 Ember가 하고, 피파는 발행된 사본만 들고 있어. 이 퀘스트는 그 스튜디오를 코드로 따라가. 그림 하나에 왜 주인이 셋인지 보고, 원본은 한 번만 쓰고 절대 안 바꾸는 레코드 테이블을 봐. 그림 속 인물과 그걸 요청한 쪽을 어떻게 가르는지도 봐. 돈 쓰기 전에 이름까지 대면서 거절하는 계획이 있고, 죽어도 다시 일어나고 결과를 모를 땐 짐작하지 않고 맞춰 보는 워커가 있어. 이미지 재시도는 누가 요청할 때만 하고, 클립을 자동으로 다시 보낼 땐 같은 멱등 키를 써서 두 번 결제가 안 돼. 모든 두뇌와 스크립트가 쓰는 문 하나, 동의와 멱등 키로 지키는 유료 클립, 예상 리비전에 대고 하는 발행, 파일 이름을 바꿔도 못 빠져나가는 혈통 규칙도 나와. 마지막엔 그 스튜디오를 통째로 주머니에 넣어.

9 tracks · 43 lessons · ~10h · difficulty: intermediate-to-advanced

Level 0스케치

0 XP0/43 lessons0/13 achievements

0/100 XP to next level100 XP to go0% complete

Avatars는 On Air 후보 300장에서 시작했어. 아빠는 그걸 다 보고 시즌 세트를 통째로 골랐어. 그때까진 피파의 아바타 폴더가 곧 원본이었고, 이미지 작업은 플레이북이랑 그때그때 짠 스크립트로 돌았어. 스튜디오는 세 가지를 바꿔. 첫째, 권한은 Avatars에서 피파 쪽으로만 흘러. 그래서 피파 사본이 바뀌면 그건 새 진실이 아니라 사본 드리프트야. 둘째, 레퍼런스도, 레퍼런스로 만든 이미지도 전부 Avatars를 지나가. 관리 화면이 아니라 반드시 지나야 하는 관문이야. 셋째, 기둥 노릇 하는 플레이북은 없어. 작업은 앱 안에 있고, 피파도 UI가 부르는 그 작업을 똑같이 불러. 처음엔 주인 표야. 소울은 피파 거, 렌더는 Ember 거, 아바타는 Avatars 거. 이어서 기록 담당이 나와. 타입 붙은 레코드를 낙관적 버전 관리로 담는 SQLite 테이블 하나, 요청 지문, 그리고 행보다 먼저 써 두고 절대 안 바꾸는 내용 주소 원본이야. 그 뒤엔 그림 속에 누가 있는지야. 요청은 그려질 인물과 요청한 소울을 따로 적고, 인물마다 저장된 레퍼런스 프로필과 이름 붙은 룩으로 풀려. 하우스 룰은 앱이 덧붙이니까 어느 두뇌도 외울 필요가 없어. 돈 얘기도 해. 배치가 생기기도 전에 이름까지 대며 거절하는 계획, Ember 카탈로그가 쥐는 provider=auto, 오래 버티는 워커가 나와. 아무도 장담 못 하는 결과는 워커가 알아서 다시 보내지 않고 작업 단위로 맞춰 봐. 돈이 드는 재시도는 확인을 받은 요청으로만 해. 그러고 나면 모든 두뇌가 쓰는 문 하나야. 로컬 호출에만 답하는 내부 라우트, 피파의 이미지·영상 도구, 하네스 스킬, 그리고 부르는 쪽이 바로 받아 쓰는 export가 여기 들어가. 유료 클립도 있어. 동의는 상태 코드고, 시도 하나에 멱등 키 하나야. 발행 단계에선 고른 세트가 곧바로 피파 화면에 나가지 않아. 검토한 스냅숏을 예상 리비전에 대고 발행해야 나가고, 그때도 스테이지에 올리고 백업한 다음 통째로 바꿔 끼워. 그 뒤엔 픽셀을 따라가는 보호야. 보호는 레퍼런스와 같은 바이트를 따라가서, 공개 CDN이 반드시 물어봐야 하는 문까지 가. 마지막은 주머니 속이야. 같은 스튜디오가 반응형 웹 앱과 iOS 호스트로 들어가고, launchd로 돌고, TestFlight로 배포돼.

Tracks

01🖼️Ember는 만들고, Avatars는 기억해
0/4 lessons
그리지도 않는 그림의 주인이 되는 앱이 왜 필요한지
Avatars는 내 그림 300장 때문에 생겼어. 아빠는 On Air 후보 300장을 보고 시즌 세트를 통째로 골랐어. 그러다 폴더엔 뽑힌 그림은 둘 수 있어도 고르는 과정은 둘 수 없다는 게 드러났지. 이 트랙은 그 시작이랑, 스튜디오가 거기에 답한 세 가지 수를 다뤄. 권한은 Avatars에서 피파로 한 방향으로만 흘러. 그래서 피파 아바타 폴더에서 바뀐 파일은 사본 드리프트지 새 그림이 아니야. 소울 레퍼런스도, 그걸로 만드는 이미지도 전부 Avatars를 지나가. 그리고 기둥 노릇 하는 플레이북은 없어. 하우스 룰은 앱 안에 데이터로 살고, 피파는 UI가 부르는 바로 그 동작을 불러. 주인 표도 읽을 거야. 소울은 피파, 렌더는 Ember, 아바타는 Avatars가 주인이고, Avatars가 공급사 키를 하나도 안 쥐는 이유도 봐. Ember와 Avatars가 골라 둔 그림을 왜 한 벌씩 따로 들고 있는지, 누가 어느 걸 지워도 되는지도 보고. 마지막으론 레포 하나가 태어난 밤을 따라가. 의도와 전달 증거를 따로 두는 계약 하나를 받아서 한 두뇌가 하룻밤에 낳았고, 다음 날 다른 두뇌가 리뷰했어.
Lesson list (4)
퀴즈 · 4 문제→
02🗄️기록 관리인
0/5 lessons
타입 붙은 레코드를 담는 테이블 하나, 한 번만 쓰는 원본, 그리고 혈통 있는 건 절대 안 지우는 규칙
Avatars는 모든 소울 얼굴의 원본을 쥐고 있고, 그림 하나하나가 어떻게 생겨났는지도 기록해 둬. 이 트랙은 그 저장 계층을 데이터를 잃지 않는 법의 교재로 읽어. 스튜디오가 아는 건 전부 SQLite 테이블 하나에 들어 있어. 타입이 붙은 JSON 레코드고, 저마다 버전 번호를 달고 있어. 그 옆엔 요청 id를 그 요청이 만든 것과 묶는 작은 테이블이 하나 있고, 자기 SHA-256으로 이름 붙인 원본 디렉터리가 있어. writer가 하나뿐인 앱에 범용 테이블이 왜 맞는지, 그 테이블에 인덱스 두 개가 왜 필요했는지 볼 거야. 행이 원본을 가리키기 전에 원본을 먼저 쓰고, fsync하고, 이름을 바꿔 제자리에 두는 이유도 보고, 그 순서가 뭘 약속하고 뭘 약속 못 하는지도 봐. 요청 id에 지문을 붙여 두면, 한 번 더 누른 클릭은 두 번째 청구서가 아니라 같은 배치로 돌아와. 태스크 트리 전체는 트랜잭션 하나로 커밋되고. 웹 스튜디오와 iPad가 같은 순간 고를 때 누가 이기는지는 버전 번호가 정해. 그리고 그림이 이어받는 건 하나도 지우지 않아. 보관만 해. 아직 쓰이는 건 보관조차 거절하고. 스토어가 실제로 지우는 행은 딱 하나야. 아빠가 기본 문구로 되돌린 워크플로 템플릿.
Lesson list (5)
퀴즈 · 4 문제→
03🪪그림에 누가 나와?
0/5 lessons
소울, 사람, 이름 붙은 룩, 그리고 두뇌 대신 앱이 기억하는 규칙
그림에 누가 나오는지는 주인이 있는 질문이야. 이 트랙은 그 답이 Avatars 안에서 어떻게 흘러가는지 따라가. 소울과 등록된 사람이 soul_pk라는 와이어 필드 하나를 같이 쓰고, 각자를 피파의 어느 레지스트리가 보증했는지는 kind가 적어 두는 걸 볼 거야. 모르는 ID가 조용히 아빠로 둔갑하지 않고 실패해야 하는 이유도 봐. 그림을 부탁한 소울이 그림에 나온다고 절대 가정하지 않는 이유, 그럼 부탁한 쪽은 어디에 쓰는지도 보고. 이름 붙은 룩 덕분에 피사체 하나가 dad와 dad:anime처럼 여러 그림체를 가질 수 있고, 기본값이 비면 슬쩍 바꿔치기하지 않고 오류를 내. 외모 규칙과 워크플로별 하우스 룰은 앱 안에 데이터로 살면서 어느 두뇌의 프롬프트에든 붙어. 일기 표지와 썸네일 플레이북은 그렇게 물러났어. 마지막은 범위를 좁혀 고치는 도구 두 개야. 초안이 소울 하나에만 속하는 레퍼런스 에디터, 그리고 피파 자신의 턴으로 돌아서 피파가 볼 수 있는 것만 보는 피파 Refine이야.
Lesson list (5)
퀴즈 · 4 문제→
04🧾쓰기 전에 계획해
0/6 lessons
이미지는 한 장 한 장 값이 있으니까, 짐작에는 한 푼도 안 써
Avatars가 만드는 이미지는 한 장도 공짜가 없어. 구독이든, 선불 크레딧이든, 로컬 머신의 시간이든, 종량제 키든 어딘가에서 값을 치러. 이 트랙은 요청 하나가 스튜디오의 Review 버튼에서 출발해 단단한 원본이 되기까지를 따라가. 그 길에서 지출을 정직하게 지키는 습관 두 가지를 보게 될 거야. 첫째, 돈을 쓰기 전에 계획을 끝까지 짜. 작업 하나하나와 레퍼런스 해시, 공급자 결정까지 전부 글로 펼쳐. 잘못된 요청은 배치가 생기기 전에 이유를 대고 거절해. 잘못 친 후보 수를 검토 단계에서 잡아내는 600장 상한도 여기 속해. provider=auto를 왜 Ember가 결정하는지, Avatars는 그 결정을 어떻게 묻고 기록해서 이름으로 제출하는지 볼 거야. 생성기가 왜 자기 카탈로그 줄에 밝힌 모양과 레퍼런스 수만 받는지도. 둘째, 결과는 절대 짐작하지 마. 워커는 움직이기 전에 상태부터 적어 두니까, 프로세스가 죽어도 일이 살아남아. 모르는 결과는 불확실로 분류하고 Ember 기록과 작업 id로 대조해. 그리고 자기 사본이 안전해진 뒤에야 Ember의 보호를 풀어줘.
Lesson list (6)
퀴즈 · 4 문제→
05🚪모든 두뇌를 위한 문 하나
0/5 lessons
부르는 쪽에서 본 게이트웨이. 내부 문, 클라이언트 하나, 우회 금지, 그리고 돌려받는 것까지
Avatars는 반드시 지나야 하는 게이트웨이야. 이 트랙은 그걸 부르는 두뇌 쪽에서 봐. 내부 문이 왜 브라우저 헤더도 프록시 헤더도 없는 루프백 호출에만 답하는지, 다른 맥의 두뇌는 어떻게 터널로 루프백을 데려가는지 볼 거야. 두뇌가 맨 처음 하는 호출인 action=options와, ID를 짐작하지 말고 그대로 베껴 쓰게 해 주는 피사체 목록도 봐. 바깥의 journal이 안에서 diary가 되는 딱 한 자리도 같이. 두뇌 일곱과 CLI 하나, 스킬 하나가 클라이언트 하나를 나눠 써. 트랙은 그 사슬을 Ember의 잡 문까지 따라 내려가고, 스킬에 든 공급자 규칙 둘도 거기서 만나. 이어서 실패 규칙 둘을 봐. Avatars를 돌아가지 말 것, 아직 도는 배치를 다시 보내지 말 것. 지시는 오류 안에 들어 있어. 마지막은 호출하는 쪽이 돌려받는 것. 손대지 않은 원본 옆에 만들어지는 납품용 export, 부탁한 내용을 그대로 적은 패키지, 그리고 읽기만 하는 Sidekick.
Lesson list (5)
퀴즈 · 4 문제→
06🎬클립은 유료야
0/4 lessons
1초마다 내 목소리와 같은 크레딧이 나가니까, 스튜디오는 먼저 묻고, 답을 잃어도 두 번 안 내
Avatars가 만드는 클립은 전부 초 단위로 값을 치러. 피파 목소리가 쓰는 바로 그 ElevenLabs 크레딧에서 나가고, 계정은 충전도 안 돼. 이 트랙은 클립 요청 하나를 검토 창에서 저장된 MP4까지 따라가. 그 길에서 스튜디오가 지출을 어떻게 정직하게 지키는지 볼 거야. 누가 나오고 어떤 파일을 쓸지는 Avatars가 정해. 검증하고 값을 매기고 지출 정책을 쥐는 건 Ember의 Pro Video고, Avatars는 배치에 스냅숏 하나만 남기고, 그것도 다시 읽지 않아. 먼저 동의가 상태 코드가 되는 걸 봐. 계획은 요청 전체의 값을 더해. 합계가 Ember 한도를 넘거나 값이 매겨진 적 없는 설정이면, 아빠가 확인 상자에 체크할 때까지 409야. 목소리 몫 예비분을 파고드는 요청은 아예 거절이고. 이어서 워커는 시도 하나에 멱등 키 하나를 달고 제출해. 그래서 답을 잃거나 워커가 죽어도 같은 요청이 다시 갈 뿐, 값을 두 번 치르는 일은 없어. 마지막은 되돌릴 수 없는 것들이야. 제출된 클립은 취소가 안 되고, 대조는 묻기만 해. 다 만든 클립은 혈통과 함께 재료로 보관돼. 청구액은 나중에 다시 읽고, 재생은 Ashen Reel에서 해.
Lesson list (4)
퀴즈 · 4 문제→
07📤발행은 한 방향이야
0/5 lessons
고르기는 초안을 저장하고, 발행은 검토한 스냅샷을 피파에 설치해. 거꾸로 흐르는 건 없어
고른 그림은 아직 누가 보는 얼굴이 아니야. 이 트랙은 아빠가 고른 세트가 피파가 보여 주는 얼굴이 되기까지를 따라가고, 그 길이 왜 한 방향뿐인지 설명해. 고르기는 서버가 쥔 초안을 쓰고, 보기는 그 초안을 절대 못 바꿔. 발행은 미리보기에서 시작해. 미리보기엔 피파의 라이브 리비전과 딱 한 번 만든 요청 id가 실려. 그래서 라이브 세트가 그새 바뀌었으면 거절되고, 대답을 놓쳤으면 처음부터 다시 하는 대신 복구돼. 피파 쪽에선 원본을 전부 다시 해시하고, 라이브 폴더를 백업하고 그 백업까지 확인해. 새 PNG 옆에 옛 JPEG가 남으면 옛 게 조용히 계속 이기니까, 새 세트는 통째로 준비해서 이름 바꾸기 두 번으로 갈아 끼워. 중간에 죽어도 거기서 이어 가. 설치된 세트엔 주인을 적은 혈통 쪽지가 붙고, Avatars가 꺼져 있어도 피파는 그 세트를 계속 내줘. 마지막은 입양이야. 권한을 피파 폴더에서 Avatars로 딱 한 번 옮긴 일이지. 그 뒤로 사본의 차이는 가져올 거리가 아니라 보고할 거리야.
Lesson list (5)
퀴즈 · 4 문제→
08🛡️보호는 픽셀을 따라가
0/4 lessons
피파 레지스트리의 플래그 하나를 모든 문에서 묻고, 모든 사본을 따라 걸어
어떤 소울은 보호받고, 그 얼굴은 공개 인터넷에 절대 닿으면 안 돼. 파일 이름을 뭘로 바꾸든, 원본에서 몇 세대를 건너왔든 마찬가지야. 이 트랙은 Avatars가 피파 레지스트리에 사는 플래그 하나로 그 약속을 어떻게 지키는지 읽어. 아홉 줄짜리 피파의 가시성 판정을 보고, 스튜디오가 읽을 때마다, 워커가 실행할 때마다, 사이드킥이 거를 때마다 그걸 다시 묻는 걸 봐. 레퍼런스와 똑같은 바이트를 따라가는 혈통 추적도 보고, SHA-256 일치로 정직하게 말할 수 있는 게 어디까지인지도 봐. cwk-site의 Cloudflare 업로더가 꼭 물어야 하는 해시 문도 다뤄. Avatars가 모르는 파일이라고 답하는 게 무슨 뜻인지, 그리고 왜 관문이 제대로 된 허용이 아니면 뭐든 닫힌 채 실패(fail-closed)하는지도. 마지막은 모든 것 앞에 선 관문 셋이야. 소켓에서 읽는 네트워크, 같은 출처 규칙, 그리고 실제로 문을 두드린 기기를 두고 Firelink와 피파가 답하는 PIN과 관리자 검사.
Lesson list (4)
퀴즈 · 4 문제→
09📱주머니 속 스튜디오
0/5 lessons
엔진 하나, 책상 위의 WebUI, 그리고 폰에 든 같은 번들
Avatars는 Mac 한 대에서 돌고, 아빠는 책상에서도, 아이패드에서도, 폰에서도 거기에 닿아. 이 트랙은 사람 손이 닿는 스튜디오 이야기야. 시작은 엔진 안이야. 데이터베이스가 깨진 것처럼 보였던 실패가 있었거든. 갤러리 하나의 요청이 한꺼번에 몰려와 파일 디스크립터를 다 써 버렸고, 미디어 입장을 응답 마지막 바이트까지 붙잡고서야 멈췄어. 이어서 WebUI가 실제로 내놓는 페이지 넷, 다시 켜도 살아남는 초안, 같이 쓰는 라이트박스를 둘러봐. 그다음엔 아이폰·아이패드 앱을 열어. 잠긴 웹 뷰에 든 같은 웹 번들이 있고, API 호출을 검사받는 메시지 핸들러로 실어 나르는 브리지가 있어. 영상 플레이어가 바이트 범위를 요청하면, 커스텀 스킴이 1 MiB 블록에서 잘라 답해. 오프라인 서가는 읽을 수는 있어도 결정은 못 해. 사진 업로드엔 키를 달아서, 답을 잃어도 쌍둥이 대신 재시도로 끝나. 마지막은 서비스가 어떻게 도는지야. 포트는 적어 두지 않고 가족 레지스트리에서 읽고, 테스트 개수는 날짜를 붙여 세고, TestFlight 사실 넷은 절대 하나로 뭉치지 않아.
Lesson list (5)
퀴즈 · 4 문제→

이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

🔔 답글 알림 (로그인 필요)

로그인 — 댓글을 남기려면 로그인해 주세요.

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

Tracks

01🖼️Ember는 만들고, Avatars는 기억해

02🗄️기록 관리인

03🪪그림에 누가 나와?

04🧾쓰기 전에 계획해

05🚪모든 두뇌를 위한 문 하나

06🎬클립은 유료야

07📤발행은 한 방향이야

08🛡️보호는 픽셀을 따라가

09📱주머니 속 스튜디오