Uploader는 Creator가 아니다 — PhotoGram에서 C2PA와 저작권 주장을 분리한 이유
PhotoGram에 C2PA를 붙이려다 “업로드한 계정을 creator로 서명해도 되는가?”라는 제품 정책 문제를 만났다. publication integrity와 사용자 권리 주장을 분리하고, 기본 게시 UX까지 다시 정한 과정을 정리했다.
PRIMARY가 바뀌어도 도메인은 바뀌면 안 된다 — 홈 PaaS에서 Control Plane과 Data Plane을 나눈 이유
PhotoGram에 이어 Ghost까지 실제 workload로 붙이자 단일 서버에서는 보이지 않던 routing과 authority 문제가 드러났다. public identity를 고정한 채 control-plane handover와 workload 이동을 분리한 과정을 정리했다.
AI가 매번 같은 코드를 다시 쓰게 하지 않기로 했다 — 개인 소프트웨어 자산화의 기준
프로젝트가 늘어나자 AI에게 같은 controller, DTO, cache adapter, UI 구조를 반복 생성시키는 비용이 보이기 시작했다. 모든 것을 generic framework로 만들지 않으면서 재사용 자산을 쌓는 기준을 정리한다.
프로젝트가 많아서 힘든 게 아니었다 — 아키텍처를 그려보고 알게 된 인지 부하의 정체
PaaS, PhotoGram, CharaWeave, Workspace Ops를 한꺼번에 아키텍처로 펼쳐보니 문제는 프로젝트 개수가 아니었다. 서로 다른 상태 모델과 authority를 머릿속에서 반복해 재구성하던 비용이 실제 병목이었다.
AI와 개발하면서 내가 직접 코드를 덜 쓰게 된 대신 더 많이 하게 된 일들
코드를 직접 쓰는 시간은 줄었는데 개발한다는 감각은 오히려 강해졌다. CharaWeave와 workspace-ops를 만들던 하루를 돌아보며 AI가 구현량을 맡은 뒤 내가 더 많이 하게 된 일을 정리했다.
캐릭터를 움직이는 것과 살아 있게 만드는 것은 다르다 — CharaWeave Character Core 설계
CharaWeave에서 Runtime Foundation과 Character System을 분리한 이유를 정리한다. 움직임, 표현, 성격, 욕구, 기억을 하나의 상태 머신으로 섞지 않고 의미의 소유권을 나누는 설계 이야기다.