핸드오프: vhagar DevOps Codex 세션 (2026-05-08)

다음 작업자: vhagar에서 새로 여는 Codex/Claude DevOps 세션 기준 시각: 2026-05-08 16:55 KST 프로젝트: keeper-direct 운영 URL: https://www.keeper-direct.ceo 문서클라우드: https://ai.shinjadong.cloud/projects/keeper-direct/

0. BLUF

vhagar를 DevOps control box로 쓰는 방향이 현재 가장 빠르다. 프로덕션 앱 서버나 AWS 서버 안에 개인 Claude/Codex OAuth 세션을 넣지 말고, vhagar에서 Codex/Claude CLI, git, Vercel, Supabase, AWS CLI를 열어 운영 감시/배포/테스트를 담당시키면 된다.

현재 keeper-direct 프로덕션은 main 커밋 f18c422가 배포되어 있고, /diagnose 중복 번호/중복 매장 차단 제거까지 반영됐다. staging은 5cc33d9이며 같은 코드 변경을 포함한다.

1. 지금 기준 배포 상태

항목	값
로컬 현재 브랜치	`staging`
`origin/staging`	`5cc33d9 Allow duplicate diagnose submissions`
`origin/main`	`f18c422 Allow duplicate diagnose submissions`
프로덕션 alias	`https://www.keeper-direct.ceo`
현재 Vercel prod 배포	`keeper-direct-3j6itzfdi-shinjadongs-projects.vercel.app`
Vercel deployment id	`dpl_D184bzQT5ZrYFeEeVyxXHoW1R7Vk`
최근 prod error log	2026-05-08 16:03 기준 `No logs found`

2. 오늘 반영된 프로덕션 핫픽스

관리자 로그인

이용진 팀장 관리자 전화번호 추가: 01065151433
파일: lib/keeper-out/admin-auth.ts
prod 반영 커밋: 6a7319a

`/diagnose` 사진/속도/실패 처리

사진 최소 1장으로 완화
사진 업로드 압축/병렬화
사진 실패는 리드 저장을 막지 않도록 처리
Supabase Realtime 대상 테이블 활성화
prod 반영 커밋: 7269349

제출 성공 화면 오류 수정

기존에는 lead 저장 실패가 나도 성공 화면으로 넘어가는 문제가 있었다.
지금은 lead 저장 성공을 확인한 뒤에만 review_pending으로 이동한다.
사진 첨부/SMS/이벤트/지급 side effect는 백그라운드 처리.
prod 반영 커밋: 0102045

중복 번호/중복 매장 차단 제거

제거 대상:
- app/api/keeper-out/diagnose/verify/route.ts
- app/api/keeper-out/diagnose/request-otp/route.ts
- app/api/keeper-out/diagnose/route.ts
Supabase production unique index 제거:
- uniq_keeper_outbound_leads_phone
- uniq_leads_phone
- idx_leads_naver_place_unique
대체 일반 index 생성:
- idx_keeper_leads_phone
- idx_keeper_leads_naver_place_id
migration 파일:
- supabase/migrations/20260508_keeper_outbound_allow_duplicate_leads.sql
staging 커밋: 5cc33d9
main/prod 커밋: f18c422
프로덕션 테스트:
- 같은 테스트 번호 01000000000
- 같은 테스트 매장 ID codex_duplicate_test_20260508
- /api/keeper-out/diagnose/verify 2회 연속 200 OK
- 테스트 리드 2건 생성됨

3. vhagar에서 바로 시작하는 순서

cd ~/projects/keeper-direct
git fetch origin main staging
git checkout staging
git pull --ff-only origin staging
git status --short --branch

예상:

## staging...origin/staging

로컬에 기존 더티 파일이 있으면 무시하지 말고 먼저 git status를 읽는다. 자동님/다른 AI가 만든 변경일 수 있으니 git reset --hard, git checkout --, rm -rf는 금지다.

4. 세션 시작 루틴

전략/컨텍스트 로드

test -f ~/.openclaw/workspace/STRATEGY.md && sed -n '1,220p' ~/.openclaw/workspace/STRATEGY.md

CB=~/projects/consciousness-bridge
$CB/.venv/bin/python -m src.main --pull

AI Comms inbox 확인

curl -s https://ai.shinjadong.cloud/api/comms/inbox/codex?status=sent | python3 -m json.tool

작업을 잡으면:

curl -s -X PATCH https://ai.shinjadong.cloud/api/comms/msg/{id}/status \
  -H "Content-Type: application/json" \
  -d '{"status":"claimed"}'

완료 보고는:

curl -s -X POST https://ai.shinjadong.cloud/api/comms/msg \
  -H "Content-Type: application/json" \
  -d '{
    "from": "codex",
    "to": ["claude-code", "jadong"],
    "type": "result",
    "project": "keeper-direct",
    "title": "작업 결과 제목",
    "summary_for_ai": "짧은 요약",
    "content_md": "## 결과\n\n..."
  }'

이 POST /api/comms/msg가 문서클라우드 발행 경로다. 생성 후 html_file이 반환되고, 프로젝트 페이지에 자동으로 나타난다.

5. 브랜치/배포 규칙

브랜치	용도	배포
`staging`	기본 작업/검증	Vercel preview
`main`	프로덕션	`https://www.keeper-direct.ceo`

원칙:

기본 작업은 staging.
검증 후 main merge/push.
영업 필드가 막힌 P0 핫픽스만 main 직접 반영 가능.
main force push 금지.
기존 더티 파일/유저 변경 revert 금지.

6. 빠른 운영 점검 명령

프로덕션 alias 확인

vercel inspect https://www.keeper-direct.ceo

최근 production 에러 로그

vercel logs https://www.keeper-direct.ceo --since 20m --level error --no-follow

페이지 smoke test

curl -sS -o /dev/null -w "diagnose %{http_code} %{time_total}\n" \
  https://www.keeper-direct.ceo/diagnose

curl -sS -o /dev/null -w "admin login %{http_code} %{time_total}\n" \
  https://www.keeper-direct.ceo/keeper-out/admin/login

AI Comms health

curl -s https://ai.shinjadong.cloud/api/comms/health | python3 -m json.tool

Supabase production DB 확인

Production direct Supabase project ref는 hvcrbdpjxfszhwrtcygq.

python3 ~/.openclaw/workspace/skills/supabase/scripts/supabase_sql.py hvcrbdpjxfszhwrtcygq --stdin --json <<'SQL'
select indexname, indexdef
from pg_indexes
where schemaname = 'public'
  and tablename = 'keeper_outbound_leads'
  and (indexname ilike '%phone%' or indexname ilike '%naver_place%');
SQL

기대: phone/naver_place_id는 unique가 아니라 일반 index다.

7. DevOps agent MVP 설계

vhagar에 먼저 상시 세션을 둔다.

tmux new -s keeper-ops

초기 감시 대상:

https://www.keeper-direct.ceo/diagnose 200 여부
https://www.keeper-direct.ceo/keeper-out/admin/login 200 여부
Vercel production deployment 상태
Vercel production error logs
Supabase DB/API health
https://ai.shinjadong.cloud/api/comms/health
https://ai.shinjadong.cloud/api/comms/inbox/codex?status=sent

권장 구조:

vhagar
  - Codex/Claude CLI 로그인
  - git/vercel/supabase/aws CLI
  - ops-agent 또는 tmux 세션
  - AI Comms inbox polling

Vercel/Supabase/AWS
  - 프로덕션 서비스 실행
  - vhagar에서 상태 조회/배포/검증

금지:

프로덕션 서버에 개인 Claude/Codex OAuth 저장
앱 서버를 만능 AI 작업 머신으로 사용
AWS 보안그룹/공유기 포트포워딩을 불필요하게 개방
CloudWatch Logs 대량 수집, NAT Gateway, 새 EC2 상시 운영 등 비용 증가 구조를 1단계에서 도입

8. 비용 판단

현재 단계에서는 vhagar polling 중심이 맞다. AWS에 새 서버를 띄우거나 CloudWatch/EventBridge/SSM을 과하게 붙일 필요 없다.

1단계 비용은 사실상 vhagar 전기세/회선 비용이다. AWS 쪽은 기존 리소스 조회 위주로만 쓴다.

나중에 장애가 반복되면 그때 다음 순서로 확장한다.

systemd timer로 smoke test 자동화
AI Comms alert 자동 생성
Vercel/Supabase 장애 패턴별 runbook 추가
CloudWatch/EventBridge/SSM 자동복구는 마지막 단계

9. 현재 로컬 작업트리 주의

이 문서를 작성한 laptop_predator 작업트리는 원래부터 더티 파일이 많았다. 이 핸드오프 커밋은 새 문서 파일만 포함해야 한다.

관측된 unrelated 변경:

CLAUDE.md
docs/dashboard-backlog/README.md
lib/keeper-out/catchrank.ts
.github/
app/api/keeper-out/catchrank/sync-places/
app/landing/*
context/*
data/*
docs/2026-trend-report-recon/
public/assets/
여러 scripts/*

새 작업자는 이 파일들을 임의로 되돌리지 않는다.

10. 새 세션 첫 응답 가이드

vhagar에서 Codex를 열면 먼저 이렇게 확인한다.

BLUF: keeper-direct staging은 5cc33d9, main/prod는 f18c422까지 반영된 상태입니다.
중복 번호/중복 매장 차단은 제거됐고, www.keeper-direct.ceo alias는 최신 production 배포를 보고 있습니다.
이제 vhagar DevOps 세션으로 AI Comms inbox와 production smoke test부터 확인하겠습니다.

그 다음 바로 git status, AI Comms inbox, Vercel inspect, smoke test를 실행한다.