이번 편이 만지는 곳: 운영(서버운영/모니터링)과 마케팅. 프론트는 Vercel, AI 백엔드(FastAPI)는 컨테이너로 배포하고, 검색과 AI 답변 양쪽에서 발견되게 만든다.
안전해진 서비스를 이제 세상에 내놓는다. 이번 편의 목표는 세 가지다. 프론트(Next.js)는 Vercel로, AI 백엔드(FastAPI)는 컨테이너로 실제 배포해 접속 주소를 얻고, 로그로 장애를 잡고, AI 시대에 발견되는 페이지로 만드는 것. 처음 쓰는 Claude Code 기능은 대화창 없이 명령 한 줄로 도는 헤드리스 모드와, PR에 멘션만으로 자동 리뷰가 붙는 /install-github-app이다.
배포 — git push 하면 자동으로 올라간다
프론트(Next.js)는 Vercel에 연결하면 git push가 곧 배포다. AI 백엔드(FastAPI)는 컨테이너로 만들어 어디든(Render나 Railway, Fly, 자체 서버 등) 올린다. 그리고 이 운영 단계에서 데이터베이스를 로컬 PostgreSQL에서 Supabase(관리형 PostgreSQL에 인증과 저장소까지)로 옮긴다. 같은 PostgreSQL이라 그동안 쌓은 마이그레이션이 그대로 돈다. 전체 흐름은 이렇다.
SEO와 AEO — 검색 상위와 AI 답변에 인용
요즘 사람들은 구글에만 묻지 않는다. AI에게도 묻고 답을 얻는다. 그래서 발견되는 길이 두 갈래다.
- SEO(Search Engine Optimization: 검색엔진 최적화)는 구글 검색 결과 상위에 뜨게 하는 것이다.
- AEO(Answer Engine Optimization: 답변엔진 최적화)는 ChatGPT나 Claude 같은 AI 답변에 인용되게 하는 것이다.
메타데이터(Title과 Description, 그리고 링크를 공유할 때 미리보기를 만드는 Open Graph)는 페이지의 명함이다. Schema.org의 구조화 데이터(JSON-LD)와 llms.txt는 기계, 즉 검색봇과 AI에게 페이지 구조를 알려 준다. 우리 서비스가 AI 답변에 인용되려면, 페이지를 기계가 이해하기 좋게 질문과 답 구조로 다듬어야 한다.
따라하기 1 — Vercel 배포와 로그 디버깅
프론트(Next.js)는 Vercel에, AI 백엔드(FastAPI)는 컨테이너로 배포하고,
운영 데이터베이스를 Supabase로 옮겨 연결 환경 변수를 설정해 줘.
(첫 배포가 실패하면) 배포 로그에서 진짜 원인 한 줄을 찾아 알려 줘.첫 배포는 거의 항상 실패한다. 환경 변수 하나가 빠졌거나 빌드 설정이 안 맞아서다. 그때 로그를 읽을 줄 모르면 손을 못 댄다. 그래서 첫 배포 실패는 버그가 아니라 가장 좋은 교보재다. "로그의 어느 줄이 원인인가? 환경 변수 누락인가, 빌드 오류인가?"를 함께 읽는다.
따라하기 2 — PR 자동 리뷰 (@claude)
/install-github-app그다음 GitHub에서 PR(Pull Request: 코드 병합 요청)을 열고 코멘트에 @claude 이 변경 리뷰해 줘를 단다. CI(Continuous Integration: 지속적 통합)가 실패하면 이렇게 고친다.
/autofix-pr
CI가 실패한 부분을 자동으로 고쳐 줘.PR에 리뷰 코멘트가 자동으로 달리는지 본다. 달린 코멘트를 한데 모아 반영할 땐 /pr_comments로 가져온다.
따라하기 3 — 발견되는 페이지 만들기
이 페이지에 SEO 메타데이터와 Open Graph, Schema.org(JSON-LD), robots.txt, llms.txt를
추가해 줘. AEO 관점에서 핵심 내용을 질문과 답 구조로 다듬어 줘.robots.txt는 검색봇에게 어디를 봐도 되는지 알려 주는 파일이고, JSON-LD는 페이지 내용을 기계가 읽기 쉬운 데이터로 적어 두는 형식이다. 메타데이터가 들어갔는지, 핵심 내용이 AI가 인용하기 좋은 형태인지 본다. 발견성은 코더가 약한 분야라, 마케팅과 SEO 스킬로 메타 문구와 구조를 한 번 다듬으면 모르는 분야를 스킬로 메우는 경험을 할 수 있다.
따라하기 4 — 헤드리스로 빌드 진단
(터미널에서) cat build-error.txt | claude -p "이 빌드 에러의 원인과 한 줄 수정안만 알려 줘"여기서 터미널은 대화창이 아니라 명령을 한 줄씩 입력하는 검은 창(명령 줄, CLI)이다. 대화창 없이 명령 한 줄로 진단이 나오는지 본다. 이렇게 하면 Claude Code를 자동화 파이프라인 안에 끼워 넣을 수 있다.
띄워서 확인 — 에이전트가 한 일을 검증한다
"배포 완료"라는 말이 곧 성공은 아니다. 첫 배포는 거의 늘 실패하고, 에이전트는 그 원인을 로그 깊숙이 남겨 둔다. 그러니 결과 화면이 아니라 로그를 본다. 어느 줄이 진짜 원인인지 함께 읽고, 운영과 개발의 환경 변수가 정말 나뉘었는지 확인하고, 배포된 주소에 직접 접속해 첫 요청이 통과하는지 본다.
배포된 주소에 접속해 핵심 화면이 뜨는지 확인하고, 배포 로그가 보이는지,
메타데이터가 적용됐는지 점검해 줘.- 접속 가능한 주소가 나왔는가?
- 장애 시 로그를 읽을 수 있는가?
- 환경 변수가 개발과 운영으로 분리됐는가?
- 메타데이터와
llms.txt가 들어갔는가?
한 겹 더 — 사람이 마지막에 승인하기
배포가 성공하면 자동으로 @claude가 PR을 리뷰하도록 GitHub Action 워크플로를 만들어 줘.
(단, 사람이 최종 승인하는 게이트는 남겨 둬.)PR마다 자동 리뷰가 돌되, 사람 승인이 마지막에 남아 있는지 본다. 자동화는 사람을 빼는 게 아니라, 사람이 봐야 할 지점에 집중하게 만드는 것이다.
기본 서비스가 떴다. 다음 편에서는 재료를 붙인다. 파일 업로드와 외부 API 연동, 그리고 그것들이 죽었을 때의 대비를 배운다.