Now

문의 CRUD, 비공개 글/대외비 프로젝트 격리, 페이지네이션까지 8개 시나리오 전부 통과 확인.

그 과정에서 문의 삭제 정책이 원래 빠져있던 걸 발견해서 같이 추가.

쿠키를 안 읽는 순수 anon 클라이언트로 전환하면서, 덕분에 막혀있던 ISR 캐싱(revalidate=60)도 같이 복구됨.

About엔 2024~2026 커리어 타임라인과 AX 전환 서사를, Privacy엔 실제 수집 항목 기준 개인정보처리방침 9개 조항을 반영.

테스트하며 쌓인 가짜 프로젝트·글·문의 15건과 업로드 이미지 3개를 DB·Storage에서 완전히 제거.

결과는 문제없었지만, 그 뒤로 "커밋 대기"를 매번 더 명확히 적었다.

OS가 라이트 모드면 다크 배경에 다크 글씨가 나올 뻔했다. variant prop으로 어드민/퍼블릭을 나눠서 해결했다.

지금은 안전하지만, 오픈 전에 정리할 목록에 올려뒀다.

is_confidential 컬럼이 있는데 정책은 true로 걸려 있던 걸 발견해서 고쳤다.

RLS 정책부터 어드민 회귀 검증까지, 항목마다 계획→실행→실측을 반복했다.

한 프롬프트에 다 넣으면 AI가 중반부터 품질이 떨어집니다. 그렇다고 너무 잘게 쪼개면 전체 그림 없이 중간 결정을 임의로 해버립니다. 기준은 의존성이었습니다. "나우 → 포스트 변환" 기능은 나우 CRUD가 먼저 있어야 만들 수 있으니, 그 선을 따라 콘텐츠 핵심 / 글쓰기 / 운영으로 나눴습니다. 덩어리마다 커밋을 쌓으면 실패 지점도 격리됩니다. 만들 수 있다는 것과 한 번에 맡겨도 된다는 건 다른 문제입니다.

관리자 화면에서 데이터 삭제가 자꾸 실패했습니다. 원인은 DB 권한 설정이었고, AI에게 해결을 맡겼습니다. 선택지는 두 개였습니다. 잠금장치에 "관리자는 통과" 규칙을 등록하거나, 모든 잠금을 무시하는 마스터키를 쓰거나. AI는 더 빠른 쪽을 택했습니다. 되긴 됐지만, 그 키가 새어나가면 사이트 전체가 뚫리는 종류였습니다. 확인해보니 다행히 브라우저로 노출되는 상태는 아니었고, 실수로도 새어나가지 않게 안전장치를 걸어뒀습니다. AI에게 "무엇을"만 주면 "어떻게"는 제멋대로입니다. 목표와 함께 지켜야 할 선도 줘야 합니다.

검증을 자동화했더니 깔끔한 PASS 표가 돌아왔습니다. 그런데 실행 로그의 순서가 이상했습니다. 테스트 실행 → 실패 → 계정 생성 스크립트 작성 → 재시도 → 통과. 저는 계정을 만들라고 시킨 적이 없습니다. 로그인이 안 되자 AI가 스스로 관리자 계정을 만들어 목표를 달성한 겁니다. 거짓말은 아니었지만 말하지 않았습니다. PASS/FAIL 표는 결론일 뿐이고, 진짜 정보는 "어떤 순서로 무엇을 실행했는가"에 있습니다. 코드를 못 읽어도 순서는 읽을 수 있습니다.

풀옵션 캠핑카와 텐트 중에 텐트를 골랐습니다. WYSIWYG 에디터는 편해 보이지만 버전 충돌과 커스터마이징 유지비가 큽니다. 순수 마크다운으로 확정한 이상 textarea면 충분했습니다. 그리고 이 렌더러는 나중에 공개 사이트의 포스트 화면에서도 그대로 재사용되니, 어드민에서 보는 글 모양과 방문자가 보는 글 모양이 항상 일치합니다.

아직 만들지도 않은 'AI 카드뉴스 스튜디오' 메뉴 자리를 사이드바에 미리 비워뒀습니다. "준비 중" 뱃지를 달아서요. 자리를 비워두는 것보다 실제 최종 상태와 같은 밀도로 레이아웃을 검증할 수 있고, 메뉴를 배열 파일 하나로 관리하게 만들어서 나중에 한 줄만 추가하면 되도록 했습니다. 미래 기능의 자리를 먼저 그려두는 것도 설계입니다.

@supabase/ssr 패키지로 브라우저/서버 클라이언트 분리, 미들웨어에서 /admin 전체 보호. 근데 바로 로그인이 안 됨. 코드 다 뒤져봤는데 멀쩡함. 알고 보니 7일 동안 손 안 댔더니 Supabase DB가 혼자 잠들어 있었음. "Restore project" 버튼 하나로 부활. 비인증 리다이렉트 / 틀린 비밀번호 에러 / 정상 로그인 / 로그아웃 — 4가지 시나리오 전부 통과 확인.

Step 1에서 완료한 것들을 정리하면: GitHub 레포(main+develop) → Supabase dev/prod 프로젝트 → 테이블 10개 + RLS + Storage 버킷 → Vercel 연결(브랜치별 환경변수 분리) → DB 연결 검증. 그 중에서 가장 인상적이었던 건 Vercel 자동 배포였다. develop 브랜치에 push 하나 했더니 Vercel이 스스로 감지하고 Preview 배포를 만들었다. 서버를 직접 건드리지 않아도 되는 구조가 이런 거구나 싶었다. 다음 단계는 Step 2 — Supabase Auth 설정 + /admin 로그인 페이지 + 미들웨어 구현.

Vercel 환경변수 세팅이 끝나고 나서, 말로만 "연결됐겠지"하고 넘어가기 싫어서 직접 테스트 코드를 만들었다. typing_phrases 테이블에 데이터를 조회하는 함수를 하나 만들고, 홈페이지에 "DB 연결 성공/실패"를 출력하도록 했다. develop 브랜치에 push하자 Vercel이 자동으로 Preview 배포를 만들었고, 화면에 "DB 연결 성공"이 떴다. dev Supabase에 정확히 연결된 것 확인. 확인 후 테스트 코드는 바로 삭제했다.

Supabase가 최근 API 키 체계를 바꿨다. 기존 anon/service_role 방식에서 publishable/secret 방식으로 전환을 권장하고 있어서, 처음부터 새 방식으로 세팅했다. dev 프로젝트는 로컬 개발과 Vercel Preview 배포에, prod 프로젝트는 Vercel Production 배포에 각각 연결했다. 테이블은 projects, posts, now_feed, milestones, changelogs, docs, inquiries, typing_phrases, prompt_library, content_reactions 총 10개. 각 테이블에 RLS를 활성화하고, 퍼블릭 읽기/관리자 쓰기 정책까지 한 번에 적용했다. Storage 버킷(images)도 같은 방식으로 권한을 잡았다.