AI 사용 평가 — 캠핑 모니터 PostgreSQL 컷오버와 멀티에이전트 거버넌스 회고

AI 사용 평가 — workspace/pypy 캠핑 모니터 + CLAUDE.md/에이전트 운영

날짜: 2026-04-21
관찰자: Meta 역할 메인 에이전트
근거 자료: 메모리(user_jai, feedback_*, project_camping_*), CLAUDE.md, .claude/agents/*, 이번 컷오버 세션 진행 흐름

---

0. 평가 범위

이 문서는 다음 두 영역에서 사용자(jai)가 AI(Claude Code)를 어떻게 활용하는지 관찰한 결과를 정리한다.

1. 실무 활용 사례: ~/workspace/pypy/interpark_camping/의 SQLite → PostgreSQL 컷오버 (2026-04-15 자연어 제어 보류 결정 → 2026-04-20 PG 환경 구축 + 17:42 사고 → 2026-04-21 09:00 컷오버 완료)
2. 거버넌스 설계: CLAUDE.md와 .claude/agents/*의 서브에이전트 체계, 모드 분류, 보고서 양식

코드 품질 평가가 아니라 사람-AI 협업 패턴의 평가다.

---

1. 잘하는 점 (계속하기)

1-1. 위험 인지와 안전망 배치

• 컷오버 같은 운영 전환 작업에 사전 다운타임 합의(5~10분 OK), 백업 여러 겹(state.db.bak_phase2/before_xticket_reset/cutover_), 분리 보존 전략*(*_pg.py → 컷오버 후 *_sqlite.py.bak)을 자연스럽게 한다.
• "사용자가 적어서 그냥 해도 돼" 처럼 트레이드오프를 본인이 판단해서 명시적으로 알려준다 — AI가 "위험할까요?" 물을 필요를 줄여준다.

1-2. 사고로부터 배워서 룰로 굳힘

• 17:42 사고(미리 db.py를 psycopg2로 바꿔서 monitor가 매 10초 크래시) 후 단순 복구로 끝내지 않고 feedback_cutover_code_deploy.md를 메모리에 저장 → 다음 마이그레이션에서 같은 실수 안 하도록 룰화.
• 이런 "사고 → 룰" 변환이 4건 누적된 메모리(feedback_* 4개) 자체가 AI 협업의 메타 학습이 잘 되고 있다는 증거.

1-3. 권한 절제 (least privilege)

• project_camping_monitor_nlp.md: a45hvn 봇으로 캠핑 config 자연어 편집 가능하게 하려다 "권한 많이 주지 말자"로 보류. 편의보다 보안 경계 유지를 선택했다.
• 컷오버 시 1DIRBL2y 패스워드도 localhost(127.0.0.1:5433)만 바인딩해 외부 노출 없음.

1-4. 명확한 의사결정 입력 + 모호함 회피

• 자연어 요청이 보통 짧지만 핵심 의사결정 정보를 함께 준다("사용자 적어서 OK", "그냥 해도 돼", "외부 포트 열어서 DBeaver"). AI가 추측할 여지를 줄여준다.
• CLAUDE.md에도 명시 — "사용자 질문이 모호하면 추측하지 말고 먼저 물어본다"를 양방향 룰로 둠.

1-5. 거버넌스 설계의 일관성

• CLAUDE.md / 메모리 / .claude/agents/* 세 층이 서로를 참조한다.
• 모드 분류(Full/Light/Direct) — CLAUDE.md + feedback_work_mode.md 모두에 기록
• PM/Reviewer/Dev/Debug/Refactor/Meta 각각의 역할이 보고서 양식까지 통일됨
• "Reviewer가 PM 산출물을 독립 검증" — 자기 평가의 함정을 차단하는 조직 설계가 들어가 있음. 일반 사용자가 이 깊이까지 거버넌스를 설계하는 경우는 드물다.

1-6. 학습 목적의 일관된 천명

• 모든 에이전트 정의에 "AI 학습/백엔드 실습이 근본 목적"이 반복됨 → 단기 산출물에 매몰되지 않게 하는 자기 정렬 장치.
• Meta 에이전트의 존재 자체가 "산출보다 학습"의 의지 표현.

---

2. 개선 여지 (다듬기)

2-1. 사전 점검을 자동화하지 않음 (← 17:42 사고의 진짜 원인)

관찰: 17:42 사고는 "psycopg2가 /usr/bin/python3에 없다"는 환경 사실을 사람이 떠올렸어야 하는데 잊었기 때문에 발생. 이번 컷오버에서도 사전 점검을 메인 에이전트가 매번 떠올려야 했다.

개선 제안:
- interpark_camping/scripts/preflight.sh 같은 검증 스크립트를 한 번 만들어두면 다음 마이그레이션에서 사람의 기억에 의존하지 않는다.
- 검증 항목: 인터프리터 위치, 모듈 존재(python -c "import X"), 컨테이너 healthy, 디스크 여유, 백업 디렉토리 존재.
- AI에게 "preflight 만들어둘까?" 묻지 않아도 되도록, 사고 사후처리 시 rule + script 두 가지를 함께 만드는 패턴으로 굳히면 좋다.

2-2. 거버넌스 우회 — Full 모드인데 PM/Reviewer 생략

관찰: 이번 컷오버는 명백히 Full 모드 작업(여러 파일, 운영 전환, 검증 필수)이지만 메인 에이전트가 PM/Reviewer를 호출하지 않고 직접 진행. 메모리에 절차가 있다는 이유로 PM의 PLAN.md 단계도 건너뜀.

개선 제안:
- 두 가지 길:
- (a) Full 모드의 정의를 더 좁혀 "신규 PLAN이 필요한 경우만"으로 좁히고, 컷오버처럼 절차가 이미 있는 작업은 별도 모드("Procedure" 모드)로 분류
- (b) 메모리에 절차가 있어도 PM이 PLAN.md를 그 메모리 기반으로 한 번 더 정리하는 단계를 강제
- (a)가 실용적. 모드 정의가 실제 작업 흐름과 어긋나면 거버넌스가 형식이 된다.

2-3. Meta의 산출물 회수 경로 미정의

관찰: Meta가 learnings/에 학습자료를 누적하지만, 그 자료가 다음 작업의 PM 단계에 어떻게 다시 입력되는지 명세가 없다. 메모리(MEMORY.md 인덱스)와 learnings/는 분리돼 있어 PM이 자동으로 참조하기 어렵다.

개선 제안:
- PM 에이전트 정의에 "PLAN 작성 전 learnings/ 관련 주제 검색" 단계 추가.
- 또는 learnings의 핵심 결론은 메모리(feedback_*)로도 동기화 (현재 부분적으로만 일어남).

2-4. 컷오버 시각 슬립의 의사결정 비대칭

관찰: 컷오버 04:00 → 09:00로 미뤄짐. 사용자는 "아침에 그냥 해도 돼"로 결정했지만 그 사이의 트레이드오프(누적 데이터 차이, 사용자 수, 다른 라이브 트래픽)를 AI가 정량화하지 않음.

개선 제안:
- 컷오버 시각 변경 같은 시점 결정에서 AI가 한 줄 정량 데이터를 먼저 제시: "지난 09:00~10:00 평균 텔레그램 메시지 N건, 마지막 events 추가는 X분 전". 사용자의 빠른 판단을 도와주되 결정권은 사용자에게.

2-5. 외부 가시성 부재

관찰: 컷오버 진행 중 외부 사용자(텔레그램 봇 사용자)에게 다운타임 알림 없음. 이번에는 1분 10초라 OK였지만 룰이 없으면 다음 마이그레이션에서 영향이 클 수 있다.

개선 제안:
- 1분 이상 다운타임 예상 시 봇이 정지 직전 마지막 메시지로 안내. 컷오버 체크리스트의 "0단계"로 추가.

2-6. 메모리의 "현재 사실" 검증 단계 없음

관찰: 메모리에 "anaconda3에 psycopg2 있음"이라는 가정이 적혀 있고, 이번에 운 좋게 사실이었다. 만약 anaconda 환경이 변경됐다면 또 다른 사고로 이어질 수 있다.

개선 제안:
- CLAUDE.md의 "before recommending from memory" 섹션을 메모리 사용 시 항상 적용하도록 — 추천하기 전에 grep/체크 한 번. 특히 "환경 사실"(설치된 모듈, 서비스 인터프리터 등)은 명령 한 줄로 확인 가능하니 비용이 거의 없다.

---

3. 사용 패턴 분석 (관찰)

3-1. AI를 "단계 수행자"로 쓰는가, "공동 의사결정자"로 쓰는가

사용자는 후자에 가깝다. 결정의 책임은 본인이 지되, AI에게 옵션 제시 + 트레이드오프 정리를 요구한다. DBeaver 외부 접근 질문도 "가능한지" + "어떻게 하는 게 가장 안전한지" 옵션을 기대한다.

→ AI 측 대응: 단답("가능합니다") 대신 옵션 표 + 추천 + 비용을 기본 형식으로 두면 잘 맞는다.

3-2. 학습 의지가 강함, 그러나 시간은 부족

• Meta 에이전트, learnings/, 메모리의 feedback_* — 모두 학습 누적용 인프라.
• 그러나 실제 작업 흐름에서 학습자료를 요청 후 보고 끝내는 경향이 있을 수 있음(아직 데이터 부족). 학습자료가 다음 작업에 자동 인입되지 않으면 단순 아카이브가 된다.

→ AI 측 대응: 학습자료를 만들 때 "다음 작업에서 어디서 어떻게 참조될지" 한 줄을 항상 마지막에 추가. 또는 메모리에 1줄 요약본을 동기화.

3-3. 일정·운영 측면에 대한 인식이 분명

• 다운타임 시각, 사용자 활동량 같은 운영 컨텍스트를 의사결정에 자주 끌어옴 ("새벽이라 OK", "사용자 적어서 OK").
• 보안에도 동일한 인식 — Docker 격리, 권한 절제, 외부 노출 신중.

→ AI 측 대응: 운영/보안 컨텍스트를 의사결정 입력에 포함시킬 때 사용자가 명시 안 해도 AI 측에서 한 번 짚어주는 게 잘 맞는다 ("패스워드 노출 위험 있음").

3-4. 추상화/구조에 민감

• 서비스 분리(gateway / nanoclaw), 파일 분리(*_pg.py 보관), 디렉토리 표준(work/, archive/, learnings/) 등 — 구조가 망가지는 것을 싫어함 (user_jai.md 기반).
• 이번 컷오버에서도 SQLite 백업본을 *_sqlite.py.bak 명명 규칙으로 일관되게 둠.

→ AI 측 대응: 새 파일 만들 때 기존 명명 규칙을 먼저 확인. 임의 생성하면 정리 부담을 사용자에게 떠넘김.

---

4. 거버넌스 설계 자체에 대한 평가

4-1. 강점

• 6개 에이전트 + 명확한 역할 분리: PM(계획) / Reviewer(독립 검증) / Dev(구현) / Debug(에러 추적) / Refactor(정리) / Meta(학습 누적). 회사 조직론 수준의 분리.
• 보고서 표준 양식: 모든 에이전트가 전체 목표 / 수행 내용 / 결과 / 발견 사항 / 다음 단계 제안 동일 형식. 메인 에이전트가 정보 추출 비용 ↓.
• 모드 3분류: 모든 작업을 풀 워크플로우 강제하지 않음 → 거버넌스 비용 조절 가능.
• 위반 감지 → 메인 보고: PM이 직접 차단하지 않고 메인에게 보고. 권한 분리로 사람 관찰 여지 확보.

4-2. 약점

• 모드 정의의 운용상 어긋남 (2-2 참조).
• 에이전트 호출의 자율성 vs 강제성 경계 모호: "필요 시 호출"이 너무 많다. Reviewer "Full 모드에서는 필수"는 강제, Refactor는 PM 판단 — 기준이 헷갈림.
• archive/ 운영 미숙: PM이 완료 선언 후 work/ → archive/ 이동 요청한다고 했지만, 실제 archive/ 사용 빈도 / 검색 패턴 / 이동 자동화 여부 불명. 이번 컷오버는 work/도 안 거침.
• Meta가 메인 역할 겸하기 시작: 이번처럼 Meta 에이전트를 별도로 호출하지 않고 메인이 Meta 형식으로 작성하는 경우가 늘면 Meta 에이전트의 존재 가치 약화.

4-3. 한 줄 결론

거버넌스는 잘 설계됐지만, 작은 작업 + 정해진 절차가 있는 작업에서 우회되는 경향. 모드 분류를 더 정교하게 하면 (예: "Procedure" 모드 추가) 운용과 정의 사이 갭이 줄어든다.

---

5. 다음 작업에 적용할 한 가지

만약 한 가지만 바꾼다면 2-1 (preflight 스크립트화).
- 효과: 사고 재발 방지가 사람의 기억에 의존하지 않음.
- 비용: 스크립트 1개, 30분 이내 작성.
- 부수 효과: 다음 마이그레이션(예: 다른 SQLite DB → PG, 또는 PG → 클라우드 RDS)에서 동일 패턴 재사용.

---

6. 연관 학습 자료

• learnings/techniques/python_동시성과_성능.md — 이번 컷오버에서 SQLite lock 문제로 시작된 동시성·성능 일반 학습.
• 메모리: feedback_cutover_code_deploy.md, project_camping_pg_migration.md.