안 무너지는 법
기능은 누구나 만든다 — AI 좀 만지면.
production 에서 안 깨지게 박는 *판단* 5 원리.
합의는 진실이 아니다.
왜 순진한 방법이 깨지나같은 LLM 본체 위 페르소나가 다 동의해도, 본체 차원 환각은 5명·22명에게 동시에 일어난다. '다들 그렇다더라' 는 환각을 줄이는 게 아니라 증폭한다.
규칙으로 딱 떨어지는 영역(형식 검증)은 닻이 단단하지만, 서술·해석처럼 룰로 안 떨어지는 영역은 닻이 물렁하다 — 거긴 등급·교차모델로 보완할 뿐 만능이 아니다.
- 01합의를 신뢰원으로 두지 않는다 — 합의 위에 모순 탐지를 얹고, 도메인 규칙을 어기면 동의 여부와 무관하게 reject
- 02검증자도 AI라 검증의 검증은 무한루프 → 등급 + 만장일치 게이트 + 재시도 시 *다른 모델* 교차
- 03최종 닻은 모델 바깥에 — 고정 규칙 / 사람 / 현실 신호(사용자 반응). 어딘가 AI가 아닌 것에 닿아야 멈춘다
흔히 '에이전트 합의 = 환각 방지' 로 단순화한다. 본체 공유 환각은 합의로 못 잡는다 — 모델 바깥에 닻을 내려야 멈춘다는 게 핵심.
비용과 품질은 위험도로 가른다.
왜 순진한 방법이 깨지나최고 모델 고정은 원가가 수익성을 잠식하고, 최저 모델 고정은 품질이 미달한다. 둘 다 틀린 질문 — '어디가 틀리면 피해가 큰가' 로 갈라야 한다.
'어디가 치명적인가' 의 분류 자체가 사람 판단이다. 잘못 분류하면 싼 데서 새거나 비싼 데서 낭비한다.
- 01저비용 우선 처리 → 실패·품질 미달일 때만 상위 모델로 자동 승급(cascade)
- 02치명 단계(첫 단계·승인 게이트)는 처음부터 강한 모델 강제 — 거기 오염은 하류 전체로 번지므로
- 03모델을 설정으로 추상화 → 교체 시 코드 변경 0, 공급자 장애 시 무중단
비용 절감을 모델 다운그레이드로 푸는 게 흔한 함정 — 핵심·학습 경로가 오염되면 영구다. 비용은 빈도·위험도로 푸는 문제지 품질을 깎는 문제가 아니다.
프론트 필터링은 격리가 아니다.
왜 순진한 방법이 깨지나화면은 사용자 컴퓨터에서 돈다. 서버가 A·B 데이터를 다 내려주고 화면이 B를 '숨기' 면, 개발자도구나 직접 요청으로 B가 그대로 보인다.
회귀가 커버하는 시나리오만큼만 보장된다. 안 짠 경로는 안 잡힌다 — 그래서 새 누수 경로를 발견할 때마다 케이스로 적립한다.
- 01모든 쿼리에 테넌트 키를 *서버에서* 강제 — 클라이언트 입력과 무관하게
- 02cross-tenant(A가 B를 봄) 시나리오를 자동 회귀로 매 변경마다 점검 — 1개라도 실패면 배포 금지
- 03권한 통과 경로는 별도 인증, 일반 권한으론 경계를 못 넘게
'서버에서 막아야지' 는 누구나 안다. 실제로 자동 회귀로 *매 변경마다 증명*하고 누수를 1건도 0으로 두는 곳은 드물다.
조용히 나는 사고가 진짜 사고다.
왜 순진한 방법이 깨지나에러를 운영자에게 안 띄우고, 사람이 안 보는 경로(새 가입·새벽·결제 콜백)에서 나는 사고는 사용자가 알려줄 때까지 모른다.
자동 감지도 '무엇을 볼지' 미리 정한 만큼만 본다. 상상 못 한 경로는 결국 사용자가 처음 친다 — 그걸 다음 회귀로 흡수한다.
- 01사람 눈이 안 닿는 경로일수록 시스템이 *자동으로* 잡게 강제 — 검증·알림·회귀로
- 02결제는 단일 신뢰원(알림 하나)에 의존 금지 — 동기 확인 + 사후 대조 다경로로 유실을 흡수
- 03사고 진단은 단일 축 금지 — 데이터·사용자 흐름·이벤트를 동시에 본다
보이는 사고는 누구나 고친다. *안 보이는 경로를 시스템이 강제로 비추게* 만드는 게 1인 운영의 진짜 차이.
사고가 반복되면 원인은 하나가 아니다.
왜 순진한 방법이 깨지나한 번 고쳤는데 또 터지면 단일 원인 착각이다. 매번 다른 놈이 같은 증상을 낸다 — 하나씩 잡으면 끝없이 반복된다.
sweep 도 '아는 원인' 까지다. 새 원인은 또 한 번 터져야 보인다 — 그래서 매 사고를 룰로 적립하는 것 자체가 방어다.
- 01단일 fix 후 'OK' 금지 — 가능한 원인을 전부 동시에 정리(다축 sweep) + 일정 시간 모니터링
- 02사고를 회고로 끝내지 않고 *영구 룰로 시스템화* → 다음 같은 사고를 자동 회피
- 03잘못된 신호('자원 더 사면 되지')에 휘둘리면 근본은 그대로 둔 채 시간만 날린다
사고 자체가 아니라 *사고 → 영구 룰 → 자동 회피* 로 시스템화하는 것. 6개월 뒤 같은 사고가 안 나는 비결이자 1인 운영의 무기.
결제 사고는 한 축으로 진단되지 않는다.
왜 순진한 방법이 깨지나DB 의 결제 row 가 정상이라도 사용자는 권한이 안 풀린다. UX 흐름이 정상이라도 환불 이벤트는 안 도달한다. 한 축만 보면 매번 root 가 다른 데서 나온다.
결제사 API 변경은 사후 통지 — 우리가 먼저 알 수 없다. 변경 감지 후 빠르게 흡수하는 운영 루틴이 더 중요.
- 01사고 진단 표준 3축 강제 — DB row 상태 + UX 흐름 재현(새로고침·뒤로가기·모바일) + webhook 도달·검증·반영
- 02결제 시 idempotent 강제 — orderId/paymentKey 로 dedup, 재요청 시 같은 결과
- 03결제사 API 버전 업데이트마다 webhook 검증 패턴 재점검 — v1 HMAC 헤더 → v2 payload secret 같은 변화 흡수
결제는 단일 신호 의존이 가장 위험한 영역. 다축 진단을 *시스템 표준*으로 만들어 둬야 새 사고에서도 빠르게 root 가 나온다.
피드백은 ID 두 개로 묶어야 라벨이 정확하다.
왜 순진한 방법이 깨지나timestamp 기반 매칭은 30분 안에 여러 결과가 섞이면 정확도가 깨진다. 멀티테넌트·동시 실행 환경에서 라벨 정확도가 떨어지면 학습 데이터 자체가 오염된다.
ID 가 끊기는 경로(이메일 회신·외부 챗 통합)에선 timestamp fallback 이 결국 필요 — 그 때마다 정확도 trade-off.
- 01전송물 ID(delivery_id) 로 강매칭 — 작성자 아닌 admin·승인자도 정확한 평가 대상으로 연결
- 02대화 ID(conversation_id) 이중 anchor — stream done 이벤트 메타에서 받아 본문에 박음
- 03저장 응답에 matched=1/0 명시 — 실패 시 silent success 차단
라벨 정확도가 학습 데이터 정확도 → SFT/DPO 품질 → 다음 페르소나 학습 성패. 작은 ID 두 개의 차이가 6개월 후 모델 품질의 차이.
작업 중인 영역은 같은 레포 안이라도 침범하지 않는다.
왜 순진한 방법이 깨지나'모놀리스 안 서브디렉토리니까' 핑계로 같은 레포 다른 영역을 건드리면 머지 충돌이 폭발한다. 영역 경계는 폴더가 아니라 *현재 누가 작업 중인가* 다.
협업 시 영역 경계가 모호한 경우 있음 — 'A 와 B 가 공유하는 lib' 같은 곳. 그건 사전 합의 필요.
- 01작업 시작 전 '이 변경은 어느 영역인가' 명시적으로 확인
- 02사토시가 영역명 언급하면 그 영역 전체 read-only — 같은 레포 안 다른 폴더도 별 영역
- 03위반 발생 시 즉시 모든 push·배포 중단 → 위반 커밋 명세 + 사토시 결정 대기
병렬 협업이 깨지는 가장 흔한 곳. *코드 충돌은 사후 fix 비용이 협의 비용보다 훨씬 크다* — 영역 약속이 신뢰의 토대.
끝났다고 보고하기 전에 직접 확인한다.
왜 순진한 방법이 깨지나'올렸습니다'·'반영했습니다' 보고가 실제는 안 된 경우, 운영자가 직접 들춰야만 발견한다. 모든 비용·시간 손실이 이 갭에서 나온다.
모든 flow 손 검증은 시간이 늘어난다 — 자동화 테스트로 일부 흡수하지만 새 path 는 결국 사람 손.
- 01완료 보고 전 curl·grep·브라우저 중 하나는 반드시 실행 — 보지 않은 결과 보고 금지
- 02백엔드 wire-up 검증 — fetch → response → DB row 까지 실제 동작 확인
- 03데모 폴백·하드코드 값 박혀있는지·dead table(INSERT 0) 아닌지 점검
발견 책임이 운영자한테 옮겨가면 클라우드 API 비용 + 운영자 시간 = 이중 손실. early discovery 가 cost 의 핵심.
staging 검증은 건너뛸 수 없다.
왜 순진한 방법이 깨지나로컬 → 직행 prod 는 회귀 누락 폭탄. 시식회 없이 본 매장에 새 메뉴 올리는 것과 같다. 한 번 통과하면 다음에도 건너뛰게 되는 게 가장 위험.
staging 이 prod 와 똑같지 않다 — 일부 외부 의존(LLM 호출·결제사 sandbox) 은 prod 만 가능. 100% 보장 불가.
- 01로컬 수정 → staging push → 회귀·health·journal error 0건 확인 → 그 다음 prod
- 02staging .env 가 prod 보다 작아 100% 커버 못 한다는 한계는 인정 — 그래도 절반 잡힌다
- 03프로세스 위반이 한 번 허용되면 관행화 — 단일 위반에서 즉시 alarm
build-to-deploy 사이의 안전망. *시식회를 한 번이라도 빼면* 결국 본 매장에서 사고로 잡힌다 — 운영 안정성의 가장 기본.
내부 메커니즘은 사용자에게 안 보인다.
왜 순진한 방법이 깨지나모델 ID·raw cost·뉴런 raw 텍스트를 UI 에 노출하면 '엔지니어 도구' 느낌. AX SaaS 는 'AI 가 알아서' 메타포지션이라 이게 노출되면 차별점이 무너진다.
BYOK 같은 일부 케이스는 raw 노출이 transparency 강점이 됨 — 타겟이 다르면 정반대 전략.
- 01`gemini-2.5-flash` → `⚡ 빠름 (15초, 저렴)` 같은 친화 라벨 변환
- 02`$0.0023` → `₩2,500` 회사 청구 단위로 변환
- 03backend response 에서 배포 직전 strip — model_id·cost·raw_region 삭제
경쟁사(Cursor)는 raw 노출이 강점이지만 우리는 비개발자·회사 owner 타겟. 같은 노출이 누구한테는 trust, 누구한테는 noise.
긴 처리는 청크 + 회로차단으로 쪼갠다.
왜 순진한 방법이 깨지나큰 prompt 한 번에 = timeout 폭탄. 부분 실패가 전체 fail 로 번지면 사용자 무한 대기. 단일 호출 보장 X — 쪼갬 + circuit breaker 가 표준.
부분 실패 시 사용자에게 '어느 청크가 빠졌나' 명확히 전달 어려움 — 각 청크 작은 헤더로 책임 분리.
- 01큰 처리는 N개 청크 병렬 호출 — 부분 실패는 핵심 키 누락만 fail, 비핵심 누락은 성공분만 COMPLETED
- 02분량 미달 키는 chunk-continuation 으로 회귀 호출 — 누적 후 최종 반환
- 03client 는 즉시 202 받고 polling — 운영자 timeout 0
LLM 비용 증가 + 응답 품질 보장이 필요한 모든 시스템에 적용 — 동기 호출 단일 보장 시대는 끝났다.
톤은 컴포넌트가 아니라 사이트 와이드 SSoT 다.
왜 순진한 방법이 깨지나한 페이지만 매거진 톤 = 다른 페이지가 어색하게 떠 있음. typography 는 컴포넌트별 결정이 아니라 사이트 단일 진실원이 결정해야 한다.
자동 paragraph split 이 문맥 무시 시 어색 — 일부 edge case 는 backend prompt 에서 `\n\n` 명시 강제.
- 01drop-cap·호흡 줄바꿈·ornament divider·italic 강조 등 모든 결을 단일 CSS SSoT 로 박음
- 02AI 응답 text 는 그대로 받고 — frontend 가 setRichText() 로 일관 변환 (paragraph split·키워드 자동 wrapping)
- 03외부 CDN font 폐기 — self-host 영구. 동일 결을 동일 환경에서 동일하게 보장
초고가 콘텐츠 구매층은 스타일 일관성으로 *프리미엄감* 인지. 사이트 한 페이지만 톤 깨지면 전체 신뢰도 하락.
수동 등록 없이 파일만 놓으면 시스템이 발견한다.
왜 순진한 방법이 깨지나plugin.json 마켓플레이스 등록이 표준이지만 — 실제로는 수정 후 등록 → 재시작 → 확인 루프가 자기진화를 막는다. 자동 발견이 안 되면 실험 속도가 10배 떨어진다.
경로 복잡(중첩 깊음) 시 스캔 비용 선형 증가 — namespace 충돌은 별도 검증.
- 01`.agents/skills/` 같은 경로 규칙만 고정 + 파일명→스킬명 자동 매핑
- 02설정 단 1회로 scan base 정의 후 런타임 재스캔 — 추가 = 즉시 활성, 삭제 = 즉시 제거
- 03새 plugin = 새 파일, 새 파일 = 다음 세션부터 자동
*등록 절차가 없는 게 자기진화 핵심*. plugin.json 쓰는 건 누구나 한다 — 차이는 '수정 후 즉시 활성' 인가 '재시작 후 활성' 인가.
메모리를 파일 구조로 저장하고 런타임에 컴파일한다.
왜 순진한 방법이 깨지나에이전트 지시를 단일 CLAUDE.md 한 파일로 두면 — 수정 단위가 크고 변경 추적이 안 된다. 폴더 구조로 쪼개고 런타임에 컴파일하면 변경이 git diff 로 잡힌다.
300+ 파일 매 세션 read = IO 비용 존재. 원본 수정 후 컴파일 지연 가능 — 캐시 + 변경 감지로 보완.
- 01뉴런 폴더 = 뇌 영역(brainstem·limbic·cortex·sensors) 고정, 각 파일 = 하나의 규칙
- 02compile 스크립트가 모든 파일 읽고 단일 마크다운으로 병합 → 다음 prompt 에 주입
- 03.neuron 파일 변경 감지 → 자동 재컴파일 → 즉시 반영 (impedance 0)
'내가 뭘 바꿨는가' 가 명확해서 교정 루프가 빠르다. *규칙을 파일로 만드는 것 자체가 학습 속도의 차이* — 1인 운영의 무기.