안 됩니다 대신 무엇을 빼겠습니까

목표

범위 안팎을 판정하는 규칙을 차례 있는 파일로 굳히고 판정기를 만든다. 전제마다 깨졌을 때의 결과와 확인 방법과 유효 기간을 적은 원장을 두고 만료된 확인을 찾아낸다. 범위 밖 요청에는 거절문이 아니라 교환표로 답한다.

왜 중요한가

착수 첫 주에 정한 범위는 둘째 주부터 샌다. 합의문은 서랍에 있고, 읽어 봐도 이 요청이 그 문장에 해당하는지가 애매하다. 규칙을 차례 있는 파일로 적고 판정기를 돌리면 "왜 이건 안 되나요" 에 규칙 하나를 보여 주면 되고, 규칙이 잘못됐으면 규칙을 고치면 된다. 사람을 설득하는 대신 파일을 고치는 대화가 된다.
어떤 규칙에도 걸리지 않은 요청은 범위 밖이 아니라 판단 보류다. 걸리지 않은 것을 자동으로 밖으로 밀면 규칙의 빈틈이 영영 드러나지 않는다. 보류 목록이 곧 다음 회의의 안건이다.
전제도 같다. 회의에서 들은 말을 전제로 계획을 세우고 3주 뒤에 그것이 틀렸다는 것을 알게 되는데, 그때는 이미 그 위에 일정이 얹혀 있다. 전제마다 깨지면 무엇이 무너지는지와 확인 방법과 유효 기간과 주인을 적어 두면, 기간이 지난 전제가 목록으로 떠오른다.
채점기는 여러분이 적어 낸 숫자를 믿지 않는다. 매번 다른 규칙과 요청으로 여러분의 판정기를 실제로 돌려 판정과 근거 규칙을 대조하고, 전제 원장에는 경계 날짜를 넣어 만료 판정을 확인한다.

단계

1. /root/scope/gen_engagement.py 를 만들어 실행해 requests.json(25건)·baseline.json(10건, 예산 30일)·sow.md 를 만드세요.
2. 합의문을 읽고 /root/scope/scope_rules.json 에 규칙을 차례대로 적으세요. 규칙마다 id·effect·match·reason 을 넣고, 좁은 규칙을 위에 둡니다.
3. /root/scope/judge.py 를 만들어 요청마다 먼저 맞는 규칙으로 안·밖·보류를 가르고 verdicts.json 을 쓰게 하세요.
4. match 에 action 과 tag 를 더해 조건이 모두 맞을 때만 규칙이 잡게 하세요. 판정에는 어느 규칙이 결정했는지도 적습니다.
5. /root/scope/assumptions.json 에 전제 다섯 개 이상을 적으세요. 전제마다 statement·if_broken·verify_how·verified_on·valid_days·owner 를 넣습니다.
6. /root/scope/assumptions.py 를 만들어 --as-of 기준으로 만료된 전제를 찾아 expired.json 을 쓰게 하세요.
7. 새로 들어온 범위 밖 요청 RQ-021-NEW 에 대한 교환표를 /root/scope/tradeoff.json 에 적으세요.
8. /root/scope/scope_report.md 에 네 절로 보고하세요.

참고

• 요청 항목: {"id", "title", "system", "action", "tags": [...], "est_days", "from"}. system 은 wms·crm·billing·bi, action 은 read·fix·change·build·train 입니다.
• 규칙 파일: {"rules": [{"id": …, "effect": "in"|"out", "match": {"system"?: …, "action"?: …, "tag"?: …}, "reason": …}]}. match 의 조건이 모두 맞아야 그 규칙이 요청을 잡습니다. tag 는 요청의 tags 에 그 값이 들어 있으면 맞는 것입니다. 목록의 차례가 우선순위이고 먼저 맞는 규칙이 이깁니다.
• 판정 실행 계약: python3 /root/scope/judge.py --rules <규칙> --requests <요청> --out <판정 JSON> 은 한 줄 요약을 표준출력에 내고 종료 코드 0 으로 끝납니다. 입력을 읽을 수 없으면 3 입니다.
• 판정 JSON: {"counts": {"in", "out", "undecided"}, "verdicts": [{"id", "verdict", "rule"}]}. verdicts 는 요청 id 오름차순이고, rule 은 결정한 규칙의 id 이며 보류면 null 입니다.
• 전제 원장: {"assumptions": [{"id", "owner", "statement", "if_broken", "verify_how", "verified_on": "YYYY-MM-DD", "valid_days": 정수}]}.
• 만료 실행 계약: python3 /root/scope/assumptions.py --ledger <원장> --as-of <YYYY-MM-DD> --out <결과 JSON>. 만료일은 확인일 + valid_days 이고, 기준일이 만료일을 넘어야 만료입니다(만료일 당일은 아직 유효).
• 만료 JSON: {"as_of", "items": [{"id", "expires_on", "expired"}], "expired": [id...], "valid": [id...]}. items 는 id 오름차순입니다.
• 교환표: {"request_id", "added_days", "dropped_days", "drop": [{"id", "est_days", "reason"}], "question"}. 빼자고 제안하는 작업의 합이 새 요청의 비용 이상이어야 하고, 그 묶음에서 아무거나 하나를 빼면 모자라야 합니다. priority 가 must 인 작업은 교환 대상이 아닙니다. question 은 뺄 작업의 id 를 모두 담은 한 문장이고 물음표로 끝납니다.
• 흔한 실수: 걸리지 않은 요청을 밖으로 밀기, 넓은 규칙을 위에 두어 좁은 규칙이 영영 안 걸리기, 만료 경계를 하루 어긋나게 계산하기, 교환표에 must 작업을 넣기.
• 전제 기준일 2026-09-17, 유효 기간을 날 단위로 세는 방식, 교환표의 최소성 조건은 이 실습의 가정입니다. 표준이 정해 주는 것이 아니라 팀이 합의해 파일에 적어 두는 값입니다.
• 참고 문서: [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.html)와 [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174.html)는 규칙 문장의 강도를 낱말로 못박는 방법을, [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339.html)는 날짜 표기를, [파이썬 datetime 문서](https://docs.python.org/3/library/datetime.html)는 날짜 계산을 설명합니다.

단계 8개

1. 착수 꾸러미 펼치기
2. 합의문을 규칙으로 옮기기
3. 안·밖·보류로 가르기
4. 조건이 모두 맞을 때만 잡기
5. 전제 원장 만들기
6. 확인이 만료된 전제 찾기
7. 무엇을 빼겠습니까
8. 범위와 전제를 보고하기