AI를 더 쓰는 문제가 아니다.
있는 것이 서로 연결되어 있지 않다.

네 갈래 조사가 서로 다른 데서 출발했는데 같은 모양을 발견했다. 왼쪽에 있는 것은 이미 만들어져 돌고 있고, 오른쪽에서 필요한데, 가운데가 끊겨 있다. 새로 만들 것보다 이을 것이 먼저다.

이 그림이 세 질문의 답을 한 번에 설명한다. 큐레이션이 빈약한 것도, 판단이 시간 나열에 머문 것도, 사용자 소리가 안 보이는 것도 능력이나 기술의 문제가 아니다. 만들어놓은 것을 서로 연결하지 않았기 때문이다.

그리고 이것이 좋은 소식이기도 하다. 다섯 곳 중 세 곳은 새 모델도, 새 인프라도, 외부 비용도 필요하지 않다. 저장 한 줄, 호출 한 번, 테이블 하나 옮기기다.

피드백 데이터를 찾다가 장바구니 테이블을 열었더니 나온 숫자다. 이미 있는 데이터이고 쿼리 한 번으로 보인다. 아무도 안 보고 있었다.

처음 수치는 최근 월이 불리한 편향이 있었다. 그래서 생성 후 경과일을 고정한 코호트로 다시 계산했다. 7일 코호트는 8월까지 완전 관측되므로 절단이 없다. 거기서도 하락이 그대로다.

3월과 4월 사이에서 끊긴다. 계절 요인도 아니다. 전년 같은 달과 비교하면 2025-08 58.0%에서 2026-08 29.3%로 28.7포인트 빠졌다. 데이터 인공물 가능성도 세 가지 확인해 모두 배제했다.

이게 이번 분석에서 가장 중요한 발견이다. 사진을 한 장도 넣지 않은 빈 프로젝트가 1.9%에서 28.4%로 폭증했다. 이들의 주문율은 0.1%다. 즉 분모에 주문할 리 없는 껍데기가 대량으로 섞여 들어왔다.

빈 프로젝트를 제외하고 다시 계산하면 하락 폭이 줄어든다.

보고할 때 두 숫자를 분리해야 한다. "반 토막"은 계측 오염이 포함된 값이고, 실제 사용자 이탈은 18.5포인트다. 그래도 작은 수가 아니다.

그리고 빈 프로젝트의 출처를 한 칸으로 특정했다. 네이티브 앱의 특정 유입 경로 하나다. 7월 빈 프로젝트 9,436건 중 8,516건(90%)이 거기서 나왔고, 그 경로만 프로젝트 수가 4.9배로 늘면서 빈 비율이 5.3%에서 76.5%가 됐다. 같은 앱의 다른 경로는 0.1%로 정상이다. 앱이 사진 선택 전에 프로젝트 껍데기를 먼저 만드는 동작으로 보인다. 앱 코드 확인이 필요하다.

이건 나쁜 소식이 아니다. 지표 오염이므로 고치면 숫자가 정상으로 돌아온다. 그리고 그동안 우리가 봐 온 전환율이 실제보다 나쁘게 보였다는 뜻이다.

편집완료율에서 가장 선명하게 갈린다.

웹은 편집완료율이 사실상 유지되는데 네이티브는 무너졌다. 그리고 이 기간에 구성비까지 역전됐다. 2026년 2월에 웹 72 대 모바일 28이었는데 7월에는 웹 41 대 모바일 59다. 즉 무너진 쪽의 비중이 커졌다.

이 방향은 앞서 나온 신호 결손과 정확히 맞물린다. 품질·음식 신호가 웹은 100%인데 네이티브는 0%였다. 두 발견이 서로 다른 조사에서 독립적으로 나왔고 같은 곳을 가리킨다.

반대로 아닌 것으로 판명된 축도 있다. 디자인은 상위 10개 중 9개가 광범위하게 빠져서 특정 디자인 문제가 아니다. 사진 수 구간에서는 21~100장 구간이 −23.9포인트로 가장 크게 빠졌다. 핵심 구간이 가장 많이 빠졌다는 뜻이다.

추천 서버 커밋을 월별로 세어 하락 시점과 대조했다. 하락이 시작된 4월에 커밋이 49개로 폭증한다. 1월 3개, 2월 10개, 3월 22개, 4월 49개, 5월 26개, 6월 38개, 7월 4개다.

내용이 문제다. Flask에서 FastAPI로 넘어간 뒤의 정합성 버그픽스였다. 4월 16일 하루에 13개 커밋이 몰렸고 그중에 "포토북 클러스터링 IndexError 및 무한루프 수정", "page 응답에 필드 유지"가 있다. 응답 필드가 누락되어 있었다는 뜻이다. 4월 17~20일에는 "Flask 원본과 1:1 정합"이 나오는데 여기서 맞춘 것이 디자인 선택 코드다. 즉 그 시점까지 디자인 선택 결과가 원본과 어긋나 있었다.

다만 상관관계이고 인과는 증명되지 않았다. 이 후보는 웹이 15.6포인트 빠진 것을 설명하지만 네이티브 집중을 설명하지 못한다. 구독 포토북 출시는 5월 하순부터라 시점이 늦어 시작 원인은 아니고 심화 요인일 수 있다.

원인 후보 순위는 이렇게 정리됐다. ①FastAPI 전환 정합성 결손 ②네이티브 신호 결손 ③빈 프로젝트 유입 경로 ④구독 리소스 경합. 다음 확인 순서는 네이티브 신호 결손이 언제 시작됐는지(로그 76일치로 확인 가능), 빈 프로젝트 경로의 앱 동작, 그리고 4월 배포 전후 동일 입력의 추천 결과 비교다.

별개로 확인한 것이다. 입력 사진 수와 최종 배치된 사진 수를 비교했더니 경로와 설정에 따라 갈렸다.

이미지 정리를 켠 요청에서만 손실이 난다. 끄면 0%, V3는 애초에 호출이 없어 0%다. 원인이 중복·저품질 정리 함수 하나로 확정됐다.

문제는 정리 자체가 아니라 지울 수 있는 양에 상한이 없다는 것이다. 제거 예산이 "현재 장수 − 최소 보존 장수"이고 최소 보존 장수가 21장이다. 즉 650장을 올리면 629장까지 지울 수 있다. 실제로 그런 일이 일어났다.

650장을 올린 사람이 27장만 담긴 포토북을 받았다. 세 건 모두 같은 입력이라 결과를 보고 다시 시도한 흔적으로 읽힌다.

맥락을 하나 더 놓으면 사용자 64.2%가 이미지 정리를 끄는 쪽을 고른다. 손실 데이터를 함께 보면 끄는 선택이 합리적이었다고 볼 수도 있다.

대응은 규칙 수정이라 간단하다. 제거 비율 상한(예: 입력의 30% 이내), 대량 삭제 고지, 입력 규모별 중복 임계 조정이다. 다만 손실률 0%가 좋은 것도 아니다. 중복이 그대로 실린 책이 될 수 있어 되돌아온 사진 수와 짝지어 봐야 방향이 정해진다.

지적은 정확했다. AWS 리소스를 전수 확인했다. 람다 45개, DynamoDB 16개, S3 86버킷과 저장소 전체 검색 결과 앱스토어·구글플레이 리뷰 수집, 만족도 설문, SNS 수집이 하나도 없다. 인앱 리뷰 요청 코드조차 없다.

그런데 이미 쌓여 있는 것은 적지 않다. 포토북만 필터링한 실측이다.

마지막 줄이 가장 강력한 소스다. 결제된 포토북의 최종 편집본이 남아 있어서 "AI가 이렇게 추천했는데 사용자가 이렇게 고쳤다"는 쌍이 이미 존재한다. 리뷰나 CS는 말한 사람만 남지만 이것은 모든 구매자가 남긴다. 어떤 사진을 뺐고 어떤 디자인을 바꿨는지가 그대로 보인다. 저장 횟수 필드도 있어서 필드 하나로 편집 노동량이 읽힌다.

정리하면 채널이 없는 게 아니라 아무도 포토북 관점으로 보지 않은 상태다. 새로 만들지 않고 지금 켤 수 있는 지표가 세 개 있다.

• 편집완료율과 주문전환율 — 위 급락 신호. 빈 프로젝트를 분리해서 봐야 한다
• 저관여 구간 비중 — 아래 정정 항목 참조
• 저별점 원문과 CS 편집·제작불량 추이 — 리뷰 저장 한 줄을 붙이면 자동 집계된다

이 검토 중간에 "재추천을 많이 누르는 것은 불만족의 신호"라고 판단했다. 로그에서 프로젝트당 중앙값 11회, 상위 10%가 184회, 최다 3,948회가 나왔기 때문이다. 실측 결과 반대였다.

많이 뽑은 쪽이 더 완주하고 더 산다. 이탈은 많이 시도한 쪽이 아니라 한두 번 해보고 떠난 쪽에 몰려 있다. 즉 재추천 횟수는 불만족 지표가 아니라 관여도 지표다.

그래서 지표 정의를 바꿨다. 봐야 할 것은 재추천 횟수 자체가 아니라 저관여 구간(1~2회)의 비중 추이다. 그 비중이 커지면 초기 인상에서 잃고 있다는 뜻이다. 표본이 절단되어 있어 구간 간 상대 비교만 유효하다.

이 정정이 중요한 이유가 하나 더 있다. "많이 다시 뽑게 만드는 것"이 반드시 나쁜 경험은 아닐 수 있다. 편집기에서 여러 안을 돌려보는 것이 관여의 형태일 수 있다. 그렇다면 개선 방향은 재추천을 줄이는 게 아니라 처음 한두 번에 떠나지 않게 만드는 것이다.

조사에서 나온 것 중 가장 쓸모 있는 사실이다. 프로젝트 코드 하나가 네 곳에서 같은 값으로 쓰인다. 추천 요청 로그, 장바구니 테이블, 편집 이력 디렉토리 이름, 주문 상세다. 위 재추천 정정도 이 조인으로 얻었다.

이게 되면 추천 품질을 결과로 판정할 수 있다. 지금은 디자인 미적용률 46.5%나 사진 손실률 8.5% 같은 중간 지표만 있고, 그것이 매출이나 만족으로 이어지는지는 아무도 모른다. 연결 자체는 이미 되어 있고 파이프라인만 만들면 된다. 편집 이력 파서는 과거 화질 연구 때 만든 것을 재활용할 수 있다.

착수 전에 하나 확정해야 한다. AI 추천 원본을 어디서 복원하느냐다. 최종 저장본에 남는지, 아니면 추천 로그의 응답과 조인해야 하는지가 미확인이다. 이게 비교 설계의 관건이다.

결론부터. 지금은 불가능하다. 능력이 없어서가 아니라 세 조각이 동시에 비어 있어서다.

• 사진 쪽 테마 신호가 0%다. 이미지 4만 장 실측에서 테마 보유율 0.00%. 필드는 100% 전송되는데 값이 전부 비어 있다. 6월 로그 20만 줄에서도 0건이라 레거시로 빠진 게 아니라 처음부터 채운 적이 없다
• 디자인 쪽 테마 라벨이 0%다. 디자인 6만 8천 건 전수 스캔에서 태그 실값 0개. 2025~26년에 58.9%가 갱신됐는데도 비어 있어 채우는 프로세스 자체가 없다
• 둘을 잇는 배관이 일반 포토북에서 끊겨 있다. 구독은 앱이 이미지 분석 서버를 직접 불러 결과 전체를 실어 보내는데, 일반은 백엔드가 레거시 경로를 부르고 거기는 테마를 아예 실행하지 않는다

테마가 0%인 이유는 한 군데가 아니라 상류 세 단이 모두 비어 있어서다. 분석 경로가 테마를 실행하지 않고, 분석 결과 테이블 스키마에 테마 칸이 없고, 백엔드는 키만 보내고 값은 비운다. 맨 끝만 고쳐도 채울 값이 없다.

반면 품질·음식·해시 세 신호는 사정이 다르다. 상류가 이미 갖춰져 있고 전달 단계에서만 새고 있다. 그래서 훨씬 싸다. 게다가 클라이언트별로 완전히 갈린다.

같은 백엔드 경로인데 갈리므로 원인이 백엔드 분기에 있다. 이 말은 품질 기반 로직이 지금 웹 사용자에게만 부분적으로 작동한다는 뜻이다. 위 급락의 후보 중 하나로 이걸 지목한 이유다.

그런데 한 가지는 이미 준비되어 있다. 디자인 카탈로그 테마 8종이 실제로 운영 중이다. 심플일상·여행·커플웨딩·가족·아기돌잔치·시즌기념일·반려동물·팬북. 디자인팀 제작 도구도 이 체계를 쓰고 있다. 문제는 원본이 운영 데이터베이스 한 곳에만 있고 분석 창고에도 없어서 추천 서버가 볼 수 없다는 것이다. 라벨을 새로 만드는 일이 아니라 옮기는 일이다.

사진 쪽 테마 5개 클래스가 8종 중 5종을 직결로 덮는다. 심플일상·시즌기념일·팬북 세 종은 대응 신호가 없어 별도 처리가 필요하다.

하지 말아야 할 것 하나. 색이나 톤으로 테마를 자동 분류하려는 시도는 안 된다. 811장 실측에서 채도·밝기·색상차의 구분력이 전부 1 미만(0.57~0.73)이었다. 우리 템플릿 자체가 색으로 테마를 구분하지 않는다. 씬 30권 중 21권이 흰 배경이고 평균 채도가 0.054다.

사내에 Compass라는 초개인화 추천·검색 시스템이 구축되어 있다. 사용자 특성 저장소 + 상품 특성 저장소 + 매칭엔진 3층 구조이고, 시스템 개요 문서가 예시 상품으로 포토북을 첫 번째로 명시한다. 우리가 큐레이션을 새로 만들면 정면으로 겹친다.

이미 실데이터로 가동 중인 것이 상당하다.

• 사용자 페르소나 2,043행 — 여행 18.8%, 가족 15.6%, 아기 15.2%, 팬덤 13.3%, 커플 10.9%
• 포토북 커버 1,441장이 이미 분석·임베딩 완료 — 무드 톤, 스타일 태그, 계절성, 이벤트 신호가 채워져 있다
• 스타일 태그 21종, 계절성 22종 — 미니멀·빈티지·럭셔리 같은 축이 이미 정의돼 있다
• 디자인 그룹 코드 편입이 승인됐다 — 포토북 디자인 코드를 동일 설계로 넣기로 6월에 확정됐고 8,817건 실측까지 끝났다

다만 스냅스 이식은 미착수이고 7월부터 후순위로 연기됐다. 매칭엔진은 규칙 가중합이고(내용 유사도 0.30 + 성과 0.25 + 세그먼트 적합 0.20 + 템플릿 선호 0.15 + 계절 0.10) 아직 실서빙 전이다. 추천 산출물은 0건이다.

역할 경계가 자연스럽게 갈린다. "어떤 테마를 고를까"는 Compass에 얹을 수 있다. 추천 API에 스냅스 서비스와 편집기 표면 구분이 이미 예약되어 있다. 반면 "고른 테마 안에서 사진을 어떻게 배치할까"는 우리가 계속 갖는다. Compass에 클러스터링과 레이아웃 기능이 없다.

결합 방식도 깔끔하다. 클라이언트가 Compass에서 디자인 후보를 받아 지금처럼 우리 추천 API에 실어 보내면 된다. 우리 API 시그니처가 바뀌지 않는다. 지금 사람이 고르는 그 자리를 Compass가 채우는 구조다.

가장 값싼 다음 수는 페르소나 테이블 읽기 권한을 받는 것이다. 그것만으로 회원 페르소나에 근거한 디자인 기본값 제안이 가능해진다.

테마 신호가 0%인 상태에서도 할 수 있는 것이 있다. 커버 사진 자동 선정을 일반 포토북으로 확장하는 것이 첫 타깃으로 적절하다.

• 구독 포토북의 커버 점수 로직이 이미 완성돼 있고 신·구 스키마 양쪽 파싱까지 되어 있다
• 디자인 테마 라벨이 필요 없다. 사진 신호만 채우면 붙는다
• 로그에 사용자가 실제로 쓴 커버가 남아 있어 일치율 검증이 바로 된다
• 지금 일반 포토북 커버는 얼굴 면적 순위로 뽑고, 얼굴이 하나도 없으면 완전 무작위다

정직하게 덧붙이면, 지금 신호로 가능한 목록에 "디자인을 골라준다"는 없다. 인물 중심 책 판정, 약식 커버 후보 좁히기, 페이지 밀도 제안, 판형 선호 추정, 씬 분할, 부분 중복 제거까지다.

파이프라인에서 "판단"이 일어나는 지점을 55개 세고 종류를 분류했다. 이 분포가 답을 말해준다.

기존 판단 중 LLM이 대체해서 이길 지점은 하나도 없다. 품질 65점 컷이나 해밍거리 15는 숫자 하나 비교다. LLM을 넣으면 느려지고 흔들리기만 한다. 조건부로 분류된 8개조차 "규칙을 대체"가 아니라 "규칙에 의미 신호를 공급"하는 형태였다.

그러니 답은 마지막 칸이 0인 것에 있다. 지금 파이프라인에는 의미 판단이 아예 없다. LLM은 기존 것을 바꾸는 도구가 아니라 비어 있는 칸을 채우는 도구다.

55개 중 정상 가동 32개, 부분 6개, 미실행 17개다. 미실행 17개가 전부 클러스터링과 분석 타입 결정이다. 즉 챕터 분리 단계가 라이브 경로에 아예 없다.

코드로 확인했다. 서비스 레이어는 한 함수만 부르고, GPS·시간 챕터 분리는 다른 함수 안에만 있는데 그 함수를 아무도 호출하지 않는다. 실제로 도는 코드는 이것뿐이다.

정렬 기준조차 촬영시각이 아니다. 촬영시각 분기는 코드에 있지만 도달하지 않는다. 실제로 쓰이는 것은 파일명에서 추정한 날짜이거나 업로드 시각이다. 촬영시각 보유율 자체도 V4 69%, V3 55%에 그친다.

정리하면 "사진은 거의 시간의 나열"이라는 진단은 정확한데, 그 시간조차 촬영시각이 아니고 챕터라는 개념이 결과에 없다. 시스템 문서에 적힌 국내 12시간·해외 7일 분리, 제주 예외, 거주지 제거는 전부 호출되지 않는 코드다. 문서를 정정해야 한다. 그대로 두면 팀이 계속 잘못된 전제로 판단한다.

좋은 소식은 그 모듈이 멀쩡히 구현돼 있고 호출만 안 된다는 것이다. LLM을 붙이기 전에 이 복구가 먼저다. 다만 페이지 수가 바뀌면 가격이 바뀌므로 A/B와 변동 상한이 필수다.

그리고 하나 더. 추천 서버는 이미지 분석 서버를 호출하지 않는다. 외부 통신은 토큰 인증과 이미지 다운로드뿐이다. 모든 신호는 클라이언트가 채워 보내야만 존재한다. 지능화의 실제 1순위는 LLM이 아니라 이 배관이다.

입력 가용성을 판정 기준에 넣으면 지금 당장 가능한 것은 세 개이고 전부 오프라인이다. 셋을 합쳐 하루 GPU 34분, 가동률 2.4%라 기존 스테이지 서버 하나로 추가 비용이 0이다.

• 리뷰·VOC 분석 — 입력이 원래 텍스트라 신호 문제가 없다. 리뷰 배치가 이미 돌고 있어 태깅 한 단계만 추가하면 된다. 착수 비용이 가장 낮다
• 운영 로그 진단 — 이번 조사에서 사람이 한 분석의 자동화다
• 편집 이력 진단 — 추천안과 사용자 최종본의 차이를 사유로 분류한다. 임계값을 무엇으로 고칠지 알려주는 유일한 경로다

반대로 신호를 확보한 뒤에야 가능한 것이 세 개다. 챕터 의미 라벨과 제목, 표지 카피, 디자인 테마 추천이다. 최소 성립 조건은 테마와 촬영시각이다. 참고로 제목 슬롯은 이미 데이터 모델에 있고 지금은 빈 문자열로 나간다. 채울 칸이 준비되어 있다.

지연 계산도 해뒀다. 챕터 라벨은 출력이 길어 3.7초로 추정되는데 전권 추천 응답이 이미 3.5초라 동기로는 못 붙인다. 별도 엔드포인트로 비동기 분리해야 한다. 설계 원칙은 응답 계약을 건드리지 않는 것이다. LLM이 죽어도 추천은 지금과 똑같이 동작해야 한다.

절대 하지 말 것도 명확해졌다. 편집기 실시간 재추천 경로(하루 3~6만 건, 232밀리초), 디자인 매칭·좌표·해상도 계산, 결정적 시드 지점, 그리고 디자인 미적용 46.5%를 LLM으로 푸는 시도다. 원인이 빈 조합 49%와 중복회피 규칙 51%라서 LLM이 없는 디자인을 만들 수는 없다. 그건 규칙 작업이고 별도 트랙이다.

마지막으로 하나 더 못 박아 둔다. 죽은 코드 위에 LLM을 얹지 말 것. 시스템 문서만 읽고 GPS 클러스터링에 LLM을 붙이면 실행되지 않는 경로에 기능을 붙이는 셈이다. 착수 전에 호출 그래프와 신호 보유율을 확인하는 절차가 필요하다.

세 질문의 답이 하나의 순서로 모인다. 측정을 먼저 켜고, 끊긴 배관을 잇고, 있는 규칙을 복구하고, 그 다음에 LLM이다.