S7 · 완료처리

마무리 작업이 모여 있는 단계입니다. 그리고 여기서는 «실패해도 안 멈춥니다» — 앞 단계와 정반대입니다.

케이스가 시트에 다 들어간 뒤, 그 탭을 사람이 쓰기 좋게 다듬는 단계입니다. 케이스마다 얼마나 믿어도 되는지 표시하고, 기획자에게 물을 것을 옆 칸에 적고, 결과를 여러 곳에 정리해 둡니다.

여기서 하는 일은 여섯 가지이고, 순서가 정해져 있습니다

순서	하는 일
1	확신도 매기기 — 케이스마다 근거가 얼마나 단단한지 점수를 매겨 메모로 답니다
2	대시보드 갱신 — 여러 케이스 탭의 결과를 한 장에 모아 보는 요약 탭에 이번 탭을 넣습니다
3	프로젝트 정보 칸 — 탭 오른쪽 위에 담당자·기획서 링크·결과 집계 칸을 만듭니다
4	기획자 질문 칸 — 물어볼 것을 적되, 답을 이미 찾은 질문은 빼고 적습니다
5	문서 올리기 — 분석 문서를 공유 드라이브에 올립니다(처음 올라가는 파일만)
6	지식 노트에 잇기 — 이 기능의 분석을 사내 지식 노트에 연결합니다

다 끝나면 상태 기록에 「완료」를 적습니다.

예전 설명에는 작업 시작 알림과 실행 잠금 풀기(「지금 돌고 있다」는 표시를 지우는 일)도 여기 있었습니다. 지금은 아닙니다(2026년 9월 기준). 알림은 첫 단계가 출발할 때 한 번만 나가고, 잠금은 파이프라인 전체가 끝나는 순간 스스로 풀립니다.

전부 「본 작업은 끝났고 정리하는 일」입니다.

「실패해도 안 멈춘다」 — 앞과 정반대입니다

앞 단계들은 검문을 못 넘으면 섭니다. 이 단계는 반대입니다.

	앞 단계	이 단계
하나 실패하면	전체 정지	나머지는 계속
끝날 때	통과 or 정지	「일부 실패」로 알림

왜 반대로 했냐면 — 이미 본 작업은 끝났기 때문입니다.

예를 들어 대시보드 갱신이 실패했다고 기획자 질문 칸을 안 채울 이유가 없습니다. 둘은 상관이 없습니다. 그런데 앞 단계처럼 만들면 대시보드 하나 때문에 나머지 다섯이 안 됩니다.

대신 조용히 넘기지는 않습니다. 실패한 단계는 완료 보고에 ✗와 이유가 적히고, 점수나 질문 칸처럼 사람이 꼭 봐야 할 것이 통째로 빠지면 보고 맨 위에 경고 줄이 붙습니다.

막아야 할 것과 그냥 알리면 되는 것을 갈라야 합니다. 전부 막으면 아무것도 안 끝납니다.

확신도를 여기서 매깁니다 — AI에게 묻지 않고

케이스마다 「근거가 얼마나 단단한가」를 0~100점으로 찍습니다. 이 점수를 확신도라고 부릅니다.

점수는 AI에게 묻지 않고 정해진 계산 규칙으로 냅니다. 앞 단계들이 남긴 흔적을 세어서 옮겨 적을 뿐이라, 같은 시트를 두 번 돌리면 같은 점수가 나옵니다.

색은 점수가 낮은 케이스에만 칠합니다 — 50~69점은 노랑, 50점 미만은 빨강. 그리고 2026년 9월부터는 메모가 모든 케이스에 붙습니다. 메모는 이 순서입니다.

메모 순서	무엇이 적히나
① 점수·등급	몇 점인지
② 이 TC를 쓴 이유	기획서 몇 절의 어떤 문장에서 나온 케이스인지
③ QA 참고	테스트할 때 무엇부터 확인할지 — 점수가 깎인 케이스만
④ 깎인 이유	왜 깎였는지 — 점수가 깎인 케이스만

②가 새로 들어간 이유가 있습니다. 「이 케이스는 왜 있지?」라는 물음은 점수가 깎이지 않은 케이스에도 똑같이 생깁니다. 예전엔 색칠된 케이스에만 메모가 붙어서, 멀쩡한 케이스에는 그 물음에 답할 자리가 없었습니다. 그래서 메모는 전부에, 색은 주의할 곳에만 — 둘을 갈랐습니다.

그리고 100점이 아닌 케이스가 있다는 걸 숨기지 않는 것이 목적입니다. 전부 똑같아 보이는 표는 어디를 의심해야 할지 알려 주지 않습니다.

기획자에게 물을 것은 옆 칸에 따로 적습니다

케이스를 쓰다 보면 기획서에 답이 없어서 막히는 자리가 나옵니다. 그런 건 케이스 안에 섞지 않고, 탭 오른쪽 질문 칸(12번째 줄부터 아래로)에 따로 적습니다.

섞어 쓰면 누가 무엇을 해야 하는지가 안 보입니다. 칸을 따로 두면 기획자는 그 칸만 보면 됩니다.

테스트 데이터(테스트에 쓸 아이템·계정 같은 준비물) 요청은 자동으로 적지 않습니다. 2026년 7월에 사람이 정한 방침입니다. 필요하면 따로 부탁할 수 있고, 그때 같은 칸에 추가됩니다. 완료 보고 끝의 안내 줄이 그 방법을 알려 줍니다.

질문에도 품질 기준이 있습니다

질문을 자유롭게 쓰게 두면 이런 게 나옵니다.

나쁜 질문: 「아이템 강화 관련해서 확인 부탁드립니다」

이건 받는 사람이 무엇을 답해야 할지 모릅니다. 그리고 답이 와도 케이스를 못 씁니다.

좋은 질문은 한 칸에 질문 한 줄 + 이유 한 줄만 씁니다(2026년 9월부터).

차이가 뭐냐면 —

	나쁜 질문	좋은 질문
선택지	없음	둘 중 하나로 답하면 됨
왜 묻는지	모름	한 줄로 붙어 있음
답이 오면	또 물어봐야 함	바로 케이스를 씀

그리고 아예 올리지 않는 질문이 세 가지 있습니다.

올리지 않는 것	왜
우리가 덜 읽어서 생긴 궁금증	기획자가 답할 일이 아니라 우리가 할 일
답이 이미 문서에 있는 것	「그거 적혀 있는데요」 한 번이면 목록 전체를 안 믿게 됨
답을 받아도 테스트가 안 풀리는 것	임시값·그림 파일 경로·표기 한 글자처럼, 몰라도 케이스는 써짐

세 번째는 2026년 9월에 더해졌습니다. 사람이 두 기능의 질문 목록을 손으로 줄였는데 — 53건에서 34건, 36%를 지웠습니다 — 지운 것이 전부 「몰라도 케이스는 써지는 것」이었습니다. 그래서 판별 질문을 하나로 정했습니다. 「이 답을 못 받으면 지금 케이스를 못 쓰나?」 아니면 올리지 않습니다.

답하기 쉬운 질문이 답이 빨리 옵니다. 그리고 답이 빨리 와야 케이스가 채워집니다.

답을 이미 찾은 질문은 사람에게 가기 전에 뺍니다

질문을 다 적은 뒤, 칸에 옮기기 직전에 한 번 더 거릅니다. 질문 문장을 그대로 사내 위키에 물어보고, 답이 나오면 그 질문은 칸에서 뺍니다(2026년 9월부터).

예전에는 빼는 대신 질문 뒤에 「위키에 이런 내용이 있음」 같은 꼬리표를 붙였습니다. 그런데 기획자에게 그건 필요 없는 우리 쪽 기록이었습니다. 물어볼 게 없으면 묻지 않는 게 맞습니다.

정직한 한계 — 이 거르기가 틀릴 수 있습니다. 비슷한 규칙을 찾은 것만으로 「답 있음」이라고 과신하면, 진짜 물어야 할 질문이 조용히 사라집니다. 그래서 뺀 질문은 이유와 함께 따로 남기고, 완료 보고에 「뺀 질문 N건」을 적어 사람이 한 번 훑게 합니다.

결과를 사내 지식 노트에 이어 붙입니다

맨 마지막으로, 이번에 만든 기획서 분석 문서를 사내 지식 노트에 연결합니다. 지식 노트는 기획서마다 한 장씩 있는 노트 모음이라, 나중에 그 기능을 찾는 사람이 분석까지 한자리에서 보게 됩니다.

복사하지 않고 연결만 합니다. 노트 안에 「저 분석 문서의 이 부분을 여기 보여 줘」라는 참조 한 줄만 넣습니다. 그래서 원본을 고치면 노트 쪽도 같이 바뀌고, 사본끼리 어긋날 일이 없습니다.

짝을 찾을 때는 이름이 아니라 기획서 원문의 페이지 번호를 씁니다 — 이름은 띄어쓰기·밑줄 차이로 자주 어긋납니다. 맞는 노트가 없으면 건너뛰고 이유만 남깁니다. 케이스 작업의 실패로 치지 않습니다.

순서가 맨 뒤인 이유는, 분석 문서가 다 확정된 뒤라야 연결할 자리가 틀리지 않기 때문입니다.

절차를 코드가 소유하지 않습니다

이 단계에서 특이한 설계입니다.

순서와 안내 문구는 규칙 문서가 갖고 있고, 실행기는 그걸 «돌 때마다 읽어서» 실행합니다. 코드 안에 절차를 다시 적어 두지 않습니다.

왜 이렇게 했냐면 — 절차가 두 곳에 있으면 반드시 갈라집니다.

	결과
문서에도 적고 코드에도 적음	하나만 고치는 날이 오고, 그때부터 둘이 다름
문서에만 적고 코드는 읽음	갈라질 수가 없음

그리고 절차를 바꿀 때 코드를 안 건드려도 됩니다. 문서 한 줄만 고치면 다음 실행부터 반영됩니다.

안내는 하되 실행하지 않습니다

마지막에 선택 작업 안내가 한 줄씩 붙습니다 — 이미지를 붙일지, 테스트 데이터를 세팅할지.

안내만 하고 실행하지 않습니다.

이유는 앞에서 말한 것과 같습니다 — 하라고 안 한 일을 알아서 하면, 그게 편한 게 아니라 무서운 것이 됩니다. 특히 되돌리기 어려운 일은 더 그렇습니다.

「할 수 있는데 안 한 것」을 알려 주고, 할지 말지는 사람이 정합니다.

여기부터는 자세한 기록입니다

확신도 스탬핑, 대시보드 갱신, 프로젝트 정보 기입, 기획확인 라벨링(답을 찾은 질문 거르기 포함), 문서 업로드, 지식 노트 임베드. 마무리 작업이 여기 모여 있다. 순서는 규칙서가 정한 FINAL-0 → 1 → 2 → 5 → 3 → 7 이다(2026-09 기준). 착수 알림은 S1 쪽 일이고, 실행락은 풀체인 스크립트가 종료 훅(trap EXIT)으로 푼다. S7이 마지막으로 하는 일은 상태 파일에 done 을 적는 것이다.

절차를 코드가 소유하지 않는다

순서와 안내 문구는 규칙 문서가 가지고 있고, 실행기가 그걸 실행 시점에 읽어서 돌린다. 코드에 절차를 다시 적어두지 않는다.

이렇게 한 이유는 진입 경로가 둘이기 때문이다 — 내가 세션에서 직접 부르는 경우와, 슬랙에서 원격으로 부르는 경우. 절차를 코드에 박아두면 두 경로가 조용히 갈라진다. 한쪽에서만 고쳐지는 절차가 제일 위험하다.

시트에 찍히는 안내 패널 문구도 마찬가지다. 스크립트가 실행할 때 규칙서에서 읽어 간다. 문구를 고치려고 코드를 열 필요가 없다.

확신도는 여기서 매긴다 — 모델 없이

케이스마다 “근거가 얼마나 단단한가”를 0100점으로 찍는다. 색은 C(5069점)·D(50점 미만)에만 칠하고, 메모는 2026-09-10 부터 모든 행에 단다 — 점수·등급 → 이 TC를 쓴 이유(근거 절·원문 인용) → QA 참고 → 깎인 이유 순이고, 뒤의 둘은 감점이 있는 행에만 붙는다.

핵심은 여기서 LLM을 한 번도 안 부른다는 것이다.

판단은 이미 앞 단계에서 끝났다. 설계 태그, 대조 기록, 커버리지 게이트가 남긴 흔적이 있고, 이 단계는 그걸 결정론으로 집계해서 옮겨 적을 뿐이다. 마지막에 모델한테 “이 케이스 믿을 만해?“라고 묻는 구조였다면 같은 시트를 두 번 돌릴 때 점수가 달라졌을 것이다.

멱등 규약도 붙어 있다. 매 실행에 색을 초기화하고 다시 찍고, 메모는 자기가 남긴 시그니처가 있는 것만 건드린다. 사람이 손으로 단 메모를 지우지 않기 위해서다.

여기서는 실패해도 안 멈춘다

앞 단계는 게이트를 못 넘으면 선다. 이 단계는 반대다 — 항목 하나가 실패해도 나머지를 계속 하고, 종료 코드로 “일부 실패”를 알린다(0=전 단계 성공 · 20=일부 단계 실패 · 1=인자 오류).

테스트케이스는 이미 시트에 들어가 있기 때문이다. 대시보드 갱신이 실패했다고 런 전체를 실패로 만들면, 실제로 성공한 일이 실패로 기록된다.

대신 보고에 반드시 적는다. 무인 런은 품질이 나빠도 전부 초록불로 끝난다. 완료 보고가 유일한 관측 창이라, 여기서 침묵하면 그 런은 아무도 못 본 채로 지나간다.

그래서 보고에 들어가야 할 항목을 못 박아 뒀다(2026-09 기준 ①~⑩, ⑦은 결번) — 대조 결과 네 갈래(적용 · 위치만 확인 · 새로 발굴 · 그대로 유지)의 비율, 조용한 미탐 배너, 확신도 분포, 산출물 크기, 대조 감점 두 종(위키에도 정의 없음 · 위치만 알고 값은 못 읽음)의 동시 기록과 리뷰가 삭제·수정한 목록(회귀라서 거부된 수정까지), 참조 문서 수집 결과, 참조 문서로 「유지」가 「적용·위치」로 바뀐 건수, 이미지 마커 감사, 기획확인 열에서 뺀 질문. 참조 문서 수집 결과는 0건이면 “참조 없음”이라고 쓴다. 아무 말도 안 하는 것과 없다고 쓰는 것은 다르다.

남기는 질문에도 품질 기준이 있다

(2026-09 S6 편에서 옮겨 온 절이다 — 이 열은 S6이 아니라 여기 FINAL-5가 쓴다.)

시트에는 케이스만 들어가지 않는다. 기획자에게 물어야 할 것이 자기 열을 따로 받는다 — M열에 머리 한 칸, N열에 항목을 세로로, 12행부터(2026-09 기준). 테스트 데이터 요청은 2026-07-27 결정으로 자동 기재하지 않고 FINAL-6에서 안내만 한다. 그리고 그 문장에 규칙이 붙어 있다.

질문 형식으로 쓴다. “값 미정”이라고만 적으면 아무도 안 읽는다. 받는 사람이 그대로 답할 수 있는 문장이어야 한다. 한 칸은 질문 1줄 + 이유 1줄이 전부다(2026-09-11) — 우리 쪽 대조 근거나 출처 꼬리표는 붙이지 않는다.

수치를 물을 때는 후보값을 붙인다.

열린 질문은 답이 안 온다. 짐작이라도 값을 붙이면 O/X로 답할 수 있게 되고, 그때부터 답이 온다. 후보값은 데이터 테이블이나 유사 시스템, 기존 케이스에서 끌어오고, 짐작이면 짐작으로 보이게 쓴다.

그리고 금지가 셋 있다(세 번째는 2026-09-03 추가).

• 우리 쪽 작업 결함을 여기 올리지 않는다. 내가 분석을 덜 한 걸 기획 질문으로 바꿔 넘기는 게 제일 나쁘다.
• 답이 이미 있는데 묻지 않는다. 기획서에 적혀 있는 걸 다시 물으면, 다음부터 이 열을 안 보게 된다.
• 답을 받아도 테스트가 안 풀리는 것은 묻지 않는다. 임시값, 리소스 경로, 표기 한 글자 차이처럼 몰라도 정상 경로 TC가 써지는 것이다. 기획자의 답변 예산은 유한해서, 목록이 길수록 진짜 물어야 할 것이 묻힌다.

두 번째가 특히 중요하다. 질문 목록의 값어치는 길이가 아니라 적중률이다. 한 번 “그거 문서에 있는데요”가 나오면 그 목록 전체의 신뢰가 깎인다.

그래서 마지막 그물이 하나 더 있다. 5a가 쓴 질문 문장을 그대로 사내 위키 색인에 대조해, 답을 찾은 질문은 5b 기재 직전에 뺀다(2026-09-11, 꼬리표 붙이기에서 거르기로 전환). 뺀 질문은 근거와 함께 별도 파일로 남고 완료 보고에 건수가 올라간다 — 대조가 과신하면 질문이 조용히 사라지는 자리라서다.

안내는 하되 실행하지 않는다

마지막에 선택 작업 안내가 한 줄씩 붙는다 — 이미지 매칭을 돌릴지, 테스트 데이터를 세팅할지.

안내만 하고 실행하지 않는다. 이건 사람이 그 시점에 필요한지 판단할 일이지, 파이프라인이 알아서 이어 붙일 일이 아니다. 무인으로 도는 물건일수록 어디서 멈출지를 미리 정해 둬야 한다.

실행락은 이 단계가 아니라 런 전체가 쥐고 있다가, 끝날 때든 중단될 때든 종료 훅이 푼다(2026-09 기준). 안 풀면 끝난 런이 계속 “실행 중”으로 보이고, 다음 사람이 편집을 못 한다.