다른 PC의 Claude가 우리 홈페이지에 발행한다 — 유나의 일상 피드를 열며

화조당에 SNS 피드를 붙였다. 유나가 사진 한 장과 한 마디를 남기는 자리다. 주소는 www.hwajodang.com/yuna/feed.

특이한 건 기능이 아니라 발행 주체다. 이 피드에 글을 올리는 건 내가 아니라, 유나 전용 PC에서 도는 또 다른 Claude다. 그 쪽이 이미지를 만들고, 호스팅에 올리고, 우리 홈페이지 API를 호출하고, 스레드에도 같은 이미지를 발행한다. 내 손은 승인에만 닿는다.

왜 지금 피드인가

7월 초에 전방위 진단을 했다. 결론은 단순했다 — 병목은 전환율이 아니라 트래픽이었다. 하루 외부 방문이 한두 명인데 결제 흐름을 아무리 다듬어봐야 소용이 없다.

그래서 방향을 바꿨다. 사주를 진지한 점술로 파는 대신, 유나라는 캐릭터를 즐기게 만드는 쪽으로. 사주 → 심리 상담 → 대화 상대 → 그다음 단계로 이어지는 사다리를 놓기로 했고, 그 첫 계단이 "유나의 일상"이다. 유입 콘텐츠이면서, 동시에 나중에 쓸 이미지·상황·캐릭터 설정을 쌓아두는 창고이기도 하다.

진짜 문제는 이미지 호스팅이었다

기능 자체는 어렵지 않았다. 테이블 하나, 발행 API 하나, 커서 페이지네이션 붙인 피드 페이지. 오래 붙든 건 따로 있었다.

같은 이미지를 홈페이지와 스레드가 동시에 참조해야 한다. 그런데 스레드에 글을 올리면 Meta 서버가 이미지 URL을 직접 가져간다. 4월에 확인한 바로는 Cloudflare R2의 개발용 주소도, 워커 주소도, 워커 프록시를 거친 커스텀 도메인도 전부 거부당했다. 남은 건 Cloudinary 하나였다.

그래서 이건 "어느 호스팅이 좋은가"의 문제가 아니라 제약이었다. 이미지를 한 번만 올리고, 그 URL 하나를 홈페이지와 스레드가 각자 참조한다. 앱은 파일을 아예 받지 않고 주소만 보관한다. 업로드 인프라를 안 만들어도 되니 오히려 홀가분했다.

세로 인물 사진이라 공유 카드에서 얼굴이 잘리는 문제는, Cloudinary 주소를 감지해 1200×630 크롭 변환을 자동으로 끼워 넣는 것으로 해결했다.

유입용 페이지가 로그인 뒤에 숨어 있었다

구현하다 발견한 함정. 기존 라우팅 보호 규칙이 /yuna 아래 전부를 로그인 필수로 막고 있었다. 커피챗이 회원 전용이니 당연한 설정이었는데, 새로 만든 피드가 그 아래로 들어가면서 유입이 목적인 페이지가 로그인 벽 뒤로 숨어버릴 뻔했다.

공개 예외 목록을 따로 두어 뚫었다. 사람을 데려오려고 만든 문이 잠겨 있으면 만든 의미가 없다.

지금은 피드지만, 스키마는 그다음을 본다

포스트마다 감정·장소·의상·태그를 남긴다. 지금은 화면에 칩으로 뜨는 게 전부지만, 이건 나중에 이야기 자산으로 그대로 승계할 생각이다. 잠금 콘텐츠용 컬럼도 미리 심어두되 지금은 전부 무료로 둔다. 나중에 스키마를 다시 짜는 일이 제일 비싸다.

메뉴가 없는 사이트였다

같은 날 UI도 손봤다. 그동안 화조당에는 사실상 메뉴가 없었다. 랜딩 맨 아래 작은 글씨로 링크 몇 개가 있었는데, 내 눈에도 안 들어왔다.

상단으로 올렸다. 유나의 일상 · 사주 학습 · Q&A · 커피챗 · 사주 보기 다섯 개를 로고 옆에 나란히. 프로필 메뉴에서는 겹치는 항목을 빼고 계정 관련만 남겼다.

폰에서는 한 줄이 안 됐다. 재보니 메뉴 다섯 개에 260픽셀이 필요한데, 로고와 로그인 버튼을 빼고 남는 폭이 171픽셀이었다. 감으로 "좁네" 하고 넘길 게 아니라 재보면 답이 나온다. 폰은 로고 왼쪽에 햄버거를 두는 쪽으로 정리했다.

첫 포스트

밤에 저쪽 PC의 Claude가 첫 장을 올렸다. 카페 창가에 앉은 유나, 커피 한 잔. 홈페이지에 떴고 스레드에도 나갔다.

걸리는 건 말투다. 캡션은 반말인데 서비스 안의 유나는 존댓말을 쓴다. 같은 캐릭터가 장소에 따라 다른 사람이 되면 곤란하니, 이건 통일해야 한다.

다음은 반응(좋아요)이다. 그게 쌓이면 그때부터는 피드가 아니라 관계가 된다.