안 무너지는 법.

5인 페르소나가 같은 GPT-4.1 본체를 공유하면, 모델 차원의 편향 / 환각이 5명에게 동시에 일어난다. '5명이 다 그렇다더라' = 환각 5배 증폭 가능.

• 01Grand Master 페르소나가 4 의견 사이 모순 자동 detection — 합의가 너무 일치하면 의심하게 만든다
• 02사주 도메인 keyword 강제 검증 (오행 / 십성 / 격국 / 신살) — 본체 환각이 도메인 룰을 깨면 reject
• 03사장님 reaction (별점 ≥4 / ≤2) → 다음 분석 자동 학습 시그널. 환각 답을 반복하면 시스템이 그 chain 을 우회
• 04동일 질문 reroll 시 무조건 다른 모델 strain — Claude / Gemini / GPT 교차로 답을 받아서 일치하는 부분만 채택

에이전트 6 stage 가 순차로 돌면 step 2 환각이 step 3 의 input 으로 들어가 환각이 누적된다. 마지막 결과물은 사실 1단계 답에서 멀어진다.

• 01Quality-Checker 가 매 step 결과를 A / B / C / F 등급 매김 — C 이하면 step 재실행 또는 chain abort
• 02Approval-Gatekeeper = 3명 병렬 검증 (Quality + Health + Compliance) 만장일치 후에만 다음 step 진입
• 03별점 ≤ 2 가 들어오면 그 chain 의 fingerprint 를 bomb 신호로 기록 → 다음 같은 chain 자동 우회
• 04chain step 2~N 만 무료 모델 (Nemotron) 허용, root step 은 절대 premium 모델 강제 (학습 오염 차단)

cascade routing 으로 비용 절감하다 보면 자율진화 path 까지 무료 모델로 떨어진다. Nemotron 9B 같은 모델이 잘못된 학습 데이터를 생성하면 → 뉴런 영구 오염 → 회사 전체에 잘못된 패턴이 누적.

• 01agent-improver / auto-fix / chain root step / NeuronFS promote = 4 path 는 forceFree 영구 금지 (2026-04-27 사고 후 룰 박음)
• 02비용 모니터링은 OK — 어떤 path 가 얼마 쓰는지 가시화. 단 강제 다운그레이드는 X
• 03비용 절감은 cron 빈도 조절 / 임계값 조정으로 해결 (모델 다운그레이드 X)
• 04premium 모델 강제 path 를 코드 상수로 분리 → reviewer 가 PR 에서 한눈에 확인

회사별 격리 뉴런이 universal 로 승격될 때, 사람 이름 / 사업자번호 / 결제 정보 / 내부 도메인이 그대로 넘어가면 회사 B 에서 회사 A 의 비즈 시크릿이 노출된다. 일본 기업 / 의료재단은 즉시 계약 파기.

• 01universal 자동 승격 보수적 임계값 — counter ≥ 10 + dopamine ≥ 1 + bomb 0 동시 만족만
• 02승격 직전 PII auto-redact — 사람 이름 / 사업자번호 / 카드번호 / 내부 도메인 / 전화번호 6 패턴 자동 마스킹
• 03proprietary tier 는 자동 절대 X — 사토시 수동 큐레이션만
• 04일본 기업 / 민감 클라이언트는 brain_client_co{id} 디렉토리 자체에서 격리 (universal 승격 후보에서도 제외)
• 05cross-tenant 자동 회귀 테스트 66/66 PASS 유지 — 코드 변경 PR 마다 자동 검증

결제 완료 → webhook 도착 전 사용자가 페이지 새로고침 → DB 미반영 → 권한 부여 실패 → 사용자 화남. 또는 환불 후에도 리포트 계속 보임.

• 01paymentKey 별 secret 매칭 — webhook signature 가 아니라 raw_response 의 secret 직접 비교 (Toss v2 표준)
• 02event_id dedup — 같은 이벤트 두 번 도착해도 한 번만 처리
• 03환불 시 access_until = now() 강제 + 리포트 hide 검증 (단순 status 변경 X)
• 04rate-limit 5/min/IP + audit log 풀 트랜잭션 — 비정상 패턴 자동 차단
• 05결제 사고 진단 3축 — DB row 정상 ≠ 사고 해결. UX flow + webhook secret 매칭 까지 봐야

React 컴포넌트가 useEffect 로 fetch 후 client filter → 개발자 도구 Network 탭에서 raw response 보면 다른 회사 데이터 다 노출. 또는 API endpoint 직접 호출.

• 01모든 쿼리에 company_id WHERE 절 서버 강제 (RLS) — 클라이언트 input 무관
• 02super_admin 통과 path 별도 인증 — 일반 user role 로는 cross-tenant 절대 X
• 03javascript-obfuscator 프론트 빌드 — reverse engineering 어려움
• 04audit log 풀 트랜잭션 — 누가 / 언제 / 무엇을 / 어떤 권한으로 봤는지 100% 기록 (PIPA Art.35-21 compliant)
• 05cross-tenant 회귀 테스트 자동화 — PR 마다 66 케이스 통과 필수

프로덕션 사고는 매번 다른 형태로 일어난다고 생각하지만, 실제로는 5-6 패턴이 반복된다. 회고 안 적으면 6 개월 후 같은 사고 또 일어남.

• 015/11 pet payment — 3축 진단 표준 (DB + UX + webhook secret 매칭) 영구 룰
• 024/30 MySQL OOM 6회 → 영구 해결 (튜닝 + staging stop + swappiness + journald cap) — RAM 100MB / disk 3.4GB 회수
• 034/29 signup 흰화면 → codemod 자동 import 제거 영구 금지 룰
• 044/10 cafe24 → 해외접속 차단 발견 (DB IP 오진 정정) → 다음 CI 사고 진단 표준
• 054/2 VPS 죽음 → SSH / sshd 설정 영구 X 룰 + SSH_ASKPASS 방식만 허용

0→1 시기에 기능을 빨리 박고 싶은 욕망. 경계면 (auth / tenant / schema / response contract / metrics) 이 흔들리는데도 기능 추가로 진행 → 6 개월 후 전부 리팩토링.

• 01서버가 프론트 의도 강제 — auth / role / tenant 는 서버에서. 프론트 필터 / 숨김으로 권한 처리 X
• 02권한·테넌트 경계 한 군데서 정의 — company_owner / admin / user 의미가 layer 마다 다르면 즉시 fix 우선순위 P0
• 03스키마 baseline + migration single source of truth — fresh setup 에서 현재 앱 재현 가능해야
• 04프론트/백엔드 응답 계약 고정 — 필드명 / enum / route / role value mismatch 가 기능 추가 전 정리
• 05보이는 값 = 실제 값 — 대시보드 / billing / trial / balance / usage 가 실제 DB 정책과 일치 (추정치 / 하드코딩 / 이름만 revenue 인 가짜 값 절대 X)