일부러 두 벌
이 트랙 제목은 스튜디오 사이드바에 적힌 표어야. Ember creates. Avatars remembers. Ember는 만들고 Avatars는 기억한다는 뜻이지. 구호처럼 들리지만 사실은 저장 규칙이야. 아키텍처 문서가 첫 번째 코드 블록에서 풀어서 말해. Ember는 생성물을 처음 저장하는 곳이고, Avatars는 오래 남길 두 번째 사본을 따로 둬. 그래야 Ember가 히스토리를 정리해도 골라 둔 아바타가 사라지지 않아.
Ember는 자기가 만든 모든 것의 첫 사본을 들고 있어. 공급자, 실제 모델, 레퍼런스, Pro 히스토리 행까지 같이. 그리고 Ember는 정리를 해도 돼. 앱들이 남길지 말지 모르는 작업을 보내는 탐색 공간엔 앱마다 보존 정책을 걸 수 있어. 어떤 앱의 만료를 켜면, 정리 작업이 그 앱의 탐색 이미지 중 오래되고 보호 안 된 것의 바이트를 지워. 기록에 남은 출처 정보는 건드리지 않아. 여러 앱을 상대하는 생성 엔진한텐 맞는 정책이야. 내 얼굴한텐 틀린 정책이고.
그래서 두 사본은 목적이 달라. Ember 사본은 생성 히스토리라서 Ember 규칙대로 정리돼. Avatars 사본은 골라 둔 아바타라서 Avatars 규칙대로 남아. 크기를 줄이지도, 다시 인코딩하지도 않아. 발행, 세트, 프로필, 룩, 아직 안 끝난 생성 중 하나라도 그 원본을 쓰고 있으면 보관 처리도 안 돼.
둘 사이의 악수
Avatars가 보내는 이미지 작업은 전부 cwkAvatars에서 온 탐색 작업이라는 표시를 달고 Ember로 가. 메타데이터엔 배치, 작업, 시도 번호도 실려. 받는 쪽이 오래 남을 사본을 쥐었다고 말하기 전까진 Ember가 새 탐색 결과를 보호해. 처음 요청에 넣은 약속은 안 쳐줘. 일이 끝난 뒤에 보내는 확인만 쳐줘. Avatars는 자기 쪽에 원본 바이트와 메타데이터를 확실히 저장한 다음에야 그 확인을 보내. 두 번째 코드 블록은 킷 모듈이 그 규칙들을 직접 적어 둔 부분인데, 그중 하나는 코드가 지킬 수 있는 것보다 더 많이 약속해. 확인이 실패하면 대개는 이미지가 보호된 채로 남아. 근데 Ember가 PATCH를 이미 적용했는데 답이 오다가 연결이 끊기면, 보호는 벌써 풀렸는데도 실패로 읽혀. 그래도 여기선 손해가 없어. 그때쯤이면 Avatars가 이미 단단한 사본을 들고 있거든. 악수를 한 줄씩 짚는 건 트랙 4에서 해.
어느 사본이 중요한지 보여주는 상태가 하나 더 있어. Avatars는 원본을 쥐었는데 Ember 히스토리 기록이 실패했으면, 작업은 history_missing으로 끝나. 단계 이름은 Original saved; history needs repair야. 원본은 저장했고 히스토리만 고치면 된다는 뜻이지. 아키텍처 문서는 이걸 복구 가능한 메타데이터 작업이라고 불러. 생성 비용을 한 번 더 내도 된다는 허락이 아니래. 영수증 하나 빠졌다고 두 번 돈 낼 이유가 되진 않아.
하룻밤에 태어나다
Firelink Birth가 2026-09-29 저녁에 레포를 만들었고, 첫날 밤 작업은 커밋으로 빠르게 줄지어 들어왔어.
| 언제 | 들어온 것 |
|---|---|
| 탄생 | 가족 탄생 템플릿에서 나온 뼈대 |
| 14분 뒤 | 아키텍처와 오래 남는 에셋 저장 기반 |
| 같은 저녁 | 저장되는 배치, 레퍼런스 프로필, 후보 리뷰 |
| 같은 저녁 | 정식 원본 보존, 기존 세트 들여오기, 네이티브 모바일 스튜디오. 제품 0.1.0과 TestFlight 빌드 1 |
| 자정 넘어서 | 스튜디오 구성과 떨어진 레퍼런스 초안. 기존 들여오기를 다시 열지 않는 등록된 사람 들여오기(0.1.2). 라이브러리 이동(0.1.3) |
| 2026-09-30 새벽 | 이미지 전송 폭주 수리와 갤러리 라이트박스(0.1.4) |
뼈대에서 0.1.4까지 세 시간 반이 안 걸렸어. 그날 밤 커밋 중 두뇌 트레일러가 붙은 것들엔 Codex, 모델은 GPT-6라고 적혀 있어.
리뷰 날, 그리고 여러 두뇌
다음 날은 Claude가 이어받았어. 2026-09-30에 Claude Fable 5.1이 이름 붙은 룩, 외모 규칙, 앞 레슨의 워크플로 템플릿, 전달용 export, 자동 경로를 넣었어. 한 시간쯤 뒤엔 스튜디오 자체 Automatic 항목을 Ember 카탈로그 행으로 바꿨어. 저녁엔 생성기마다 카탈로그 행에 적힌 화면비만 쓰게 묶고, 유료 클립 워크플로를 더했고. 그 클립이 iOS 앱 안에서 바로 재생되게 만든 건 Claude Opus 5.5야. 2026-10-06엔 GPT-6가 돌아와서 레퍼런스 10장 기본 상한을 없앴어. 그 뒤로 트레일러가 붙은 커밋은 대부분 Claude Opus 5.5고.
두뇌는 여럿, 계약은 하나야. 세션 사이에 설계를 다시 흥정한 일은 없어. 두 번째 커밋에서 쓴 아키텍처가 계약이고, 하우스 사인은 주인 경계를 바꾸기 전에 그 문서부터 읽으라고 모든 세션에 요구해. 트레일러 덕에 출처가 보여. 어느 두뇌가 어떤 수를 뒀는지 알 수 있고, 모든 수가 같은 문서 앞에서 책임을 져.
태어난 레포는 돌아가는 앱이 아니야
아키텍처 문서의 목적 절이 그 뒤 모든 것에 적용되는 정직 규칙을 정해. 이 문서는 의도한 동작을 정의할 뿐이고, 구현과 전달 증거는 따로래. 태어난 레포는 돌아가는 앱도, 설치된 앱도 아니라고. README는 전달 증거를 따로 한 절에 모아 두고, 항목마다 사실을 나눠 적어. 통과한 테스트, 서빙 중인 웹 빌드, 업로드되고 처리되고 내부 테스트에 배정된 TestFlight 빌드, 그리고 기기 설치는 아직 안 셌다는 것까지. 하우스 사인은 이걸 불변식으로 박아 뒀어. TestFlight 업로드, 처리, 배정, 기기 설치는 각각 다른 사실이야.
이 습관은 일이 빨리 굴러갈 때 제일 중요해. 2026-10-23까지 TestFlight 파이프라인이 커밋한 빌드가 21개야. 파이프라인은 export나 업로드 단계가 통과한 다음에야 빌드 번호를 커밋하고, 어느 쪽이 돌았는지는 커밋 본문에 적어. export만 한 실행도 제목 줄은 똑같고 본문에 Destination: export가 남아. 21개 본문은 전부 Destination: upload야. 그러니까 커밋 하나하나는 네 사실 중 첫째인 업로드의 증거고, 거기서 끝이야. README가 처리와 배정까지 적어 둔 건 그중 몇 개뿐이고. 가족 레포가 어떻게 태어나는지는 Firelink Quest에 있어. 이 퀘스트는 주장 하나하나가 무엇의 증거인지 계속 물어.