🐸🎨
전제는 실제 사고 세 건이었다
만든 창이 그대로 내보내서 생긴 사고가 이미 세 번 있었다 — 근거 없이 그려진 개구리 도면, 표지와 안 맞는 크림색 브랜드, 학원 첫 화면에 잘못 들어간 ETL·JWT 같은 기술 용어. 셋 다 같은 원인이었다: 만든 사람이 자기 결과물을 그대로 내보냈다.
🔄👥
근거 — 교차검수 구조로 풀었다
창을 새로 늘리지 않고, 이미 있는 두 역할이 서로의 결과물을 본다 — 한쪽이 만든 걸 다른 쪽이 보고, 그 반대도 마찬가지다. 판단이 갈리면 검증 담당에게 올린다.
⏸️📋
한계 — 지금은 표본 검수뿐이다
지금 당장은 만드는 라인과 요청·반응 API까지만 갖췄고, 모든 카드를 교차검수하지는 못한다 — 담당자가 표본만 골라 본다. 요청량이 늘어 병목이 되면 그때 전용 검수 창을 연다는 계획만 세워뒀고, 아직 그 창은 안 열었다 — 노는 창을 미리 만들지 않는다는 원칙 때문이다.
한 줄로:
이 기록은 실제 사고 세 건이 만든 사람의 자기검수 실패였다는 것, 교차검수로 푼 방식, 아직 표본검수 단계라는 한계까지 남긴 구현 기록이다.
출처: docs/김조교_1억/35_지식창고_요청응답_정본.md §8 (실제 사고 사례: 개구리 도면·크림색 브랜드·ETL·JWT)