# S7 · 완료처리 > 절차는 규칙 문서가 소유하고 실행기는 그걸 읽어 돌립니다. 여기서는 실패해도 멈추지 않습니다. - 수치: try/continue - 사람이 보는 화면: https://aitryed.com/ko/built/tc-team/s7/ - 반대 언어: https://aitryed.com/en/built/tc-team/s7/index.md - 이 사이트 안내(AI용): https://aitryed.com/ko/llms.txt --- **마무리 작업이 모여 있는 단계입니다. 그리고 여기서는 «실패해도 안 멈춥니다» — 앞 단계와 정반대입니다.** 케이스가 시트에 다 들어간 뒤, 그 탭을 **사람이 쓰기 좋게 다듬는** 단계입니다. 케이스마다 얼마나 믿어도 되는지 표시하고, 기획자에게 물을 것을 옆 칸에 적고, 결과를 여러 곳에 정리해 둡니다. ## 여기서 하는 일은 여섯 가지이고, 순서가 정해져 있습니다 | 순서 | 하는 일 | |---|---| | 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월부터).
GOOD

강화 10단계에서 실패하면 9단계로 내려가나요, 그대로인가요?
실패했을 때 단계가 어떻게 돼야 맞는지 알아야, 실패하는 경우를 확인할 수 있습니다.

차이가 뭐냐면 — | | 나쁜 질문 | 좋은 질문 | |---|---|---| | 선택지 | 없음 | **둘 중 하나로 답하면 됨** | | 왜 묻는지 | 모름 | **한 줄로 붙어 있음** | | 답이 오면 | **또 물어봐야 함** | **바로 케이스를 씀** | 그리고 **아예 올리지 않는 질문**이 세 가지 있습니다. | 올리지 않는 것 | 왜 | |---|---| | 우리가 덜 읽어서 생긴 궁금증 | 기획자가 답할 일이 아니라 우리가 할 일 | | 답이 이미 문서에 있는 것 | 「그거 적혀 있는데요」 한 번이면 목록 전체를 안 믿게 됨 | | 답을 받아도 테스트가 안 풀리는 것 | 임시값·그림 파일 경로·표기 한 글자처럼, 몰라도 케이스는 써짐 | 세 번째는 2026년 9월에 더해졌습니다. 사람이 두 기능의 질문 목록을 손으로 줄였는데 — 53건에서 34건, 36%를 지웠습니다 — 지운 것이 전부 「몰라도 케이스는 써지는 것」이었습니다. 그래서 판별 질문을 하나로 정했습니다. **「이 답을 못 받으면 지금 케이스를 못 쓰나?」** 아니면 올리지 않습니다. **답하기 쉬운 질문이 답이 빨리 옵니다.** 그리고 답이 빨리 와야 케이스가 채워집니다. ## 답을 이미 찾은 질문은 사람에게 가기 전에 뺍니다 질문을 다 적은 뒤, 칸에 옮기기 **직전에** 한 번 더 거릅니다. 질문 문장을 그대로 **사내 위키**에 물어보고, 답이 나오면 그 질문은 **칸에서 뺍니다**(2026년 9월부터). 예전에는 빼는 대신 질문 뒤에 「위키에 이런 내용이 있음」 같은 꼬리표를 붙였습니다. 그런데 기획자에게 그건 필요 없는 우리 쪽 기록이었습니다. **물어볼 게 없으면 묻지 않는 게** 맞습니다. **정직한 한계** — 이 거르기가 틀릴 수 있습니다. 비슷한 규칙을 찾은 것만으로 「답 있음」이라고 과신하면, 진짜 물어야 할 질문이 **조용히** 사라집니다. 그래서 뺀 질문은 이유와 함께 따로 남기고, 완료 보고에 「뺀 질문 N건」을 적어 **사람이 한 번 훑게** 합니다. ## 결과를 사내 지식 노트에 이어 붙입니다 맨 마지막으로, 이번에 만든 **기획서 분석 문서**를 사내 지식 노트에 연결합니다. 지식 노트는 기획서마다 한 장씩 있는 노트 모음이라, 나중에 그 기능을 찾는 사람이 분석까지 한자리에서 보게 됩니다. **복사하지 않고 연결만** 합니다. 노트 안에 「저 분석 문서의 이 부분을 여기 보여 줘」라는 **참조 한 줄**만 넣습니다. 그래서 원본을 고치면 노트 쪽도 같이 바뀌고, 사본끼리 어긋날 일이 없습니다. 짝을 찾을 때는 이름이 아니라 기획서 원문의 **페이지 번호**를 씁니다 — 이름은 띄어쓰기·밑줄 차이로 자주 어긋납니다. 맞는 노트가 없으면 **건너뛰고 이유만 남깁니다.** 케이스 작업의 실패로 치지 않습니다. 순서가 맨 뒤인 이유는, 분석 문서가 다 확정된 뒤라야 연결할 자리가 틀리지 않기 때문입니다. ## 절차를 코드가 소유하지 않습니다 이 단계에서 특이한 설계입니다. **순서와 안내 문구는 규칙 문서가 갖고 있고, 실행기는 그걸 «돌 때마다 읽어서» 실행**합니다. **코드 안에 절차를 다시 적어 두지 않습니다.** 왜 이렇게 했냐면 — **절차가 두 곳에 있으면 반드시 갈라집니다.** | | 결과 | |---|---| | 문서에도 적고 코드에도 적음 | 하나만 고치는 날이 오고, **그때부터 둘이 다름** | | **문서에만 적고 코드는 읽음** | **갈라질 수가 없음** | 그리고 절차를 바꿀 때 **코드를 안 건드려도 됩니다.** 문서 한 줄만 고치면 다음 실행부터 반영됩니다. ## 안내는 하되 실행하지 않습니다 마지막에 **선택 작업 안내**가 한 줄씩 붙습니다 — 이미지를 붙일지, 테스트 데이터를 세팅할지. **안내만 하고 실행하지 않습니다.** 이유는 앞에서 말한 것과 같습니다 — **하라고 안 한 일을 알아서 하면, 그게 편한 게 아니라 무서운 것**이 됩니다. 특히 **되돌리기 어려운 일**은 더 그렇습니다. 「할 수 있는데 안 한 것」을 알려 주고, **할지 말지는 사람이 정합니다.** ## 여기부터는 자세한 기록입니다 확신도 스탬핑, 대시보드 갱신, 프로젝트 정보 기입, 기획확인 라벨링(답을 찾은 질문 거르기 포함), 문서 업로드, 지식 노트 임베드. 마무리 작업이 여기 모여 있다. 순서는 규칙서가 정한 FINAL-0 → 1 → 2 → 5 → 3 → 7 이다(2026-09 기준). 착수 알림은 S1 쪽 일이고, 실행락은 풀체인 스크립트가 종료 훅(`trap EXIT`)으로 푼다. S7이 마지막으로 하는 일은 상태 파일에 `done` 을 적는 것이다. ## 절차를 코드가 소유하지 않는다 순서와 안내 문구는 **규칙 문서가 가지고 있고, 실행기가 그걸 실행 시점에 읽어서 돌린다.** 코드에 절차를 다시 적어두지 않는다. 이렇게 한 이유는 진입 경로가 둘이기 때문이다 — 내가 세션에서 직접 부르는 경우와, 슬랙에서 원격으로 부르는 경우. 절차를 코드에 박아두면 두 경로가 조용히 갈라진다. **한쪽에서만 고쳐지는 절차가 제일 위험하다.** 시트에 찍히는 안내 패널 문구도 마찬가지다. 스크립트가 실행할 때 규칙서에서 읽어 간다. 문구를 고치려고 코드를 열 필요가 없다. ## 확신도는 여기서 매긴다 — 모델 없이 케이스마다 "근거가 얼마나 단단한가"를 0~100점으로 찍는다. 색은 C(50~69점)·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) — 우리 쪽 대조 근거나 출처 꼬리표는 붙이지 않는다. **수치를 물을 때는 후보값을 붙인다.**
BAD

인벤토리 슬롯 최대 개수 미정

GOOD

인벤토리 슬롯 최대 개수가 몇 개인가요? 500개인가요?

열린 질문은 답이 안 온다. 짐작이라도 값을 붙이면 **O/X로 답할 수 있게** 되고, 그때부터 답이 온다. 후보값은 데이터 테이블이나 유사 시스템, 기존 케이스에서 끌어오고, **짐작이면 짐작으로 보이게 쓴다.** 그리고 금지가 셋 있다(세 번째는 2026-09-03 추가). - **우리 쪽 작업 결함을 여기 올리지 않는다.** 내가 분석을 덜 한 걸 기획 질문으로 바꿔 넘기는 게 제일 나쁘다. - **답이 이미 있는데 묻지 않는다.** 기획서에 적혀 있는 걸 다시 물으면, 다음부터 이 열을 안 보게 된다. - **답을 받아도 테스트가 안 풀리는 것은 묻지 않는다.** 임시값, 리소스 경로, 표기 한 글자 차이처럼 몰라도 정상 경로 TC가 써지는 것이다. 기획자의 답변 예산은 유한해서, 목록이 길수록 진짜 물어야 할 것이 묻힌다. 두 번째가 특히 중요하다. 질문 목록의 값어치는 길이가 아니라 **적중률**이다. 한 번 "그거 문서에 있는데요"가 나오면 그 목록 전체의 신뢰가 깎인다. 그래서 마지막 그물이 하나 더 있다. 5a가 쓴 질문 문장을 그대로 사내 위키 색인에 대조해, **답을 찾은 질문은 5b 기재 직전에 뺀다**(2026-09-11, 꼬리표 붙이기에서 거르기로 전환). 뺀 질문은 근거와 함께 별도 파일로 남고 완료 보고에 건수가 올라간다 — 대조가 과신하면 질문이 조용히 사라지는 자리라서다. ## 안내는 하되 실행하지 않는다 마지막에 선택 작업 안내가 한 줄씩 붙는다 — 이미지 매칭을 돌릴지, 테스트 데이터를 세팅할지. **안내만 하고 실행하지 않는다.** 이건 사람이 그 시점에 필요한지 판단할 일이지, 파이프라인이 알아서 이어 붙일 일이 아니다. 무인으로 도는 물건일수록 **어디서 멈출지를 미리 정해 둬야** 한다. 실행락은 이 단계가 아니라 런 전체가 쥐고 있다가, 끝날 때든 중단될 때든 종료 훅이 푼다(2026-09 기준). 안 풀면 끝난 런이 계속 "실행 중"으로 보이고, 다음 사람이 편집을 못 한다.