업무 공유·기록 체계 점검 — 서버팀 관점

전제: 서버팀은 현재 활성 작업이 없음 (#2 서버 Critical 보안 3건 보류 중, 재개 트리거: 서버 파트 정비 완료 통보). 본 점검은 서버 재개 시점에 사각지대가 드러나지 않도록 예방 체계 구축을 중심으로 한다.

A. 현황 실측 — 서버·운영 영역 미비점

A-1. 서버 특수 기록 채널 부재

현재 조직 기록 체계는 기획·개발 문서 작업 중심으로 구축되어 있다. 서버·운영이 재개되면 다음 기록 유형이 기존 채널(대화로그·PD 지시 로그)만으로는 추적 불가능하다:

배포 이벤트 — 언제·어디에(dev/staging/prod)·무엇을·누가 배포했는가. 현재 P24 대화로그 자유 태그로는 배포 이력 교차 검색 불가
DB 스키마 마이그레이션 이력 — 마이그레이션 스크립트 적용 순서·롤백 가능성·데이터 영향 범위. C6 백업 의무의 서버 DB 버전
장애·인시던트 기록 — 탐지 시각·영향 범위·조치·RCA(Root Cause Analysis)·재발 방지책. 현재 🚨_* 공지는 알림용이지 회고용이 아님
API 계약 변경 이력 — Breaking Change 여부·클라이언트 영향·하위 호환 기간. P13 "공용 인터페이스 변경 시 사전 공유" 의무의 실행 채널 부재

A-2. DevOps 자동화 hook 공백

.claude/settings.json 확인 결과, 현재 설치된 hook은 PreToolUse·SessionStart·UserPromptSubmit 3종. 서버 재개 시 필요한 hook이 누락:

PostToolUse 미설치 — Edit/Write 후 자동 linter·검증이 돌지 않음. 서버 코드·config 수정 시 syntax 오류가 다음 턴까지 검출되지 않는 리스크
SessionEnd 미설치 — 세션 종료 시점의 미완료 작업 자동 정리·대화로그 강제 작성이 에이전트 자율에 맡겨져 있음 (C31 자기검증 의존)
Stop hook 미설치 — 에이전트 응답 완료 직후 PD 지시 로그·Live 더미 동기화 상태 검증 자동화 부재 (C27 수동 의존)

A-3. 재해 복구 체계 부재

조직의 모든 자산이 git 단일 SOT(NerdNavisAi 레포)에 집중. 다음 리스크 대응 미비:

원격 저장소 장애 시 SOT 소실 가능성 — GitHub 장애·계정 사고 시 모든 기록 접근 불가. 로컬 클론이 유일한 백업인데 PC별 sync 주기에 따라 불균등
대화로그·메모리 백업 정책 부재 — 공유/대화로그/·memory/ 가 레포와 운명 공동체. 별도 snapshot·스토리지 동기화 미구현
감사 추적 요구 대응 불가 — "누가 언제 어떤 결정을 했는가"는 git blame·대화로그로 재구성 가능하나, tamper-proof 보장 없음 (force push로 history rewrite 가능, C19-2가 방어선이지만 사후 검증 메커니즘 부재)

A-4. 민감 정보 누출 위험 채널 미정의

조직이 단일 세션 + 전 파일 공유 구조. 서버 재개 시 발생할 민감 정보(DB 크레덴셜·API 키·서명키·개인정보) 기록 위치가 사전 정의되지 않음. .gitignore 기반 제외는 있으나 "기록하면 안 되는 것" 명시 가이드 부재.

B. 구체 개선안 (3단 위계 — 팀장 재량 / PM 조율 / PD님 결정)

B-1. 팀장 재량 범위 (즉시 착수 가능, PM 합의 시 진행)

서버 운영 기록 채널 디렉토리 신설 — 공유/운영기록/ 하위에 배포/·DB_마이그레이션/·인시던트/·API_변경/ 4개 서브디렉토리. 파일명 규칙 YYYY-MM-DD_<환경>_<요지>.md. C14-2 변동비 유지 (on-demand 참조)
인시던트 기록 템플릿 정의 — 공유/운영기록/인시던트/_TEMPLATE.md. 필드: 탐지 시각·영향 범위·타임라인·조치·근본 원인(C2)·재발 방지책·관련 커밋. 장애 종료 시점 필수 작성
API 변경 영향 분석 체크리스트 — P13 의무의 서버 측 구체화. Breaking Change 판정 기준·클라이언트 공지 전 필수 확인 항목

B-2. PM 조율 필요 (양팀 영향·hook 추가)

PostToolUse·SessionEnd hook 신설 논의 — .claude/settings.json 수정은 조직 전체 영향. PM·개발팀장·기획팀장 합의 후 scripts/post_tool_validate.sh·scripts/session_end_sync.sh 추가. 효과: C27(Agent 호출 완료 시 로그 갱신 확인)·C29-4(완료 동기화) 자동화
- A. post_tool_validate.sh: Edit/Write 후 .live/ 미반영분 감지 시 경고 출력
- B. session_end_sync.sh: 당일 대화로그 부재·활성 지시 중 갱신 누락 감지 시 경고
민감 정보 기록 금지 가이드라인 — 공유/조직공지/2026-XX-XX_민감정보_기록금지_가이드.md 발행 협의. .gitignore 대상 + 기록 허용 대체 채널(환경변수·비밀 관리자) 명시
서버 재개 체크리스트 사전 작성 — #2 재개 트리거 발동 시 즉시 적용할 온보딩 체크리스트. 위 B-1·B-2 항목 + memory/org/ 선행 검토 + Critical 보안 3건 인수인계

B-3. PD님 결정 필요 (헌법급·외부 영향)

재해 복구 전략 수립 — 조직 레포 원격 이중화(GitHub + NAS 또는 자가 Gitea) 여부. C8 프로덕션 보호 정신의 조직 기록 자산 버전. 비용·운영 부담 때문에 PD님 결정 사안
감사 추적 tamper-proof 수준 결정 — git history rewrite 금지 정책(signed commits 강제·branch protection 강화) 도입 여부. 현재 C19-2가 정성적 방어, 정량적 기술 방어는 PD님 결정

C. 서버 재개 시 예비 제안 (#2 재개 트리거 발동 대비)

서버 Critical 보안 3건 재개 시 선행 필수:

인수인계 패키지 Read 순서 고정 — 재개 시점의 서버팀장이 반드시 Read할 문서 순서를 예비 정의
- A. 공유/대화로그/수상한잡화점/ 중 #서버 태그 검색
- B. 공유/PD_지시_트래킹/개발팀_PD_지시_로그.md 완료 아카이브에서 서버 관련 항목 전수
- C. memory/org/feedback_*.md 중 서버·보안·C8 관련 피드백
Critical 3건 착수 전 체크포인트 기록 — 착수 시점의 서버 상태 스냅샷(버전·config·현재 취약점 범위)을 공유/운영기록/인시던트/ 또는 별도 보안점검/에 기록. 롤백 기준선 확보
클라이언트·기획팀 동기화 사전 통보 — P13 준수. 서버 Critical 수정은 API·데이터 포맷 영향 가능성 있음. 양팀에 변경 범위 사전 공유 → 협의 → 수정 착수 순서 고정
Live 더미 적극 활용 — 서버 관련 .live/ 더미 파일이 현재 없음. 서버 재개 시 설정·regex 변경을 Live 더미에 즉시 기록하여 다른 세션 실시간 추적 보장 (P25)

D. 요약

분류	건수	긴급도
A. 현황 미비점	4건 (서버 특수 채널·hook 공백·재해 복구·민감 정보)	예방 — 서버 재개 전 해결 권장
B-1. 팀장 재량	3건 (기록 채널·인시던트 템플릿·API 체크리스트)	PM 합의 즉시 착수 가능
B-2. PM 조율	3건 (hook 신설·민감정보 가이드·재개 체크리스트)	양팀 합의 필요
B-3. PD님 결정	2건 (재해 복구·감사 추적)	비용·정책 수반
C. 재개 예비	4건	트리거 발동 시 즉시 적용

핵심 관점: 서버팀은 활성 작업 부재 중이지만, 재개 시점의 사각지대는 이미 발생 중. 기록 채널·자동화 hook·재해 복구는 재개 후에 급하게 만들면 C8·C13 위반 리스크 상승. C29 자율 수행 정신에 따라 팀장 재량 범위(B-1)는 PM 합의 후 즉시 착수 제안.

서버팀장 자체 다짐: C23·C29·C30 준수. 본 보고는 병행 호출된 개발팀장·기획팀장·클라이언트팀장·pm-auditor 보고와 교차 검증되어 PM이 통합 판단할 자료.

8.1 KiB Raw Blame History