「できません」ではなく「何を外しますか」

목표

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

왜 중요한가

착수 첫 주에 정한 범위는 둘째 주부터 샌다. 합의문은 서랍에 있고, 읽어 봐도 이 요청이 그 문장에 해당하는지가 애매하다. 규칙을 차례 있는 파일로 적고 판정기를 돌리면 "왜 이건 안 되나요" 에 규칙 하나를 보여 주면 되고, 규칙이 잘못됐으면 규칙을 고치면 된다. 사람을 설득하는 대신 파일을 고치는 대화가 된다. 어떤 규칙에도 걸리지 않은 요청은 범위 밖이 아니라 판단 보류다. 걸리지 않은 것을 자동으로 밖으로 밀면 규칙의 빈틈이 영영 드러나지 않는다. 보류 목록이 곧 다음 회의의 안건이다. 전제도 같다. 회의에서 들은 말을 전제로 계획을 세우고 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와 RFC 8174는 규칙 문장의 강도를 낱말로 못박는 방법을, RFC 3339는 날짜 표기를, 파이썬 datetime 문서는 날짜 계산을 설명합니다.

착수 꾸러미 펼치기

/root/scope/gen_engagement.py 를 만들어 실행해 /root/scope/requests.json(25건), /root/scope/baseline.json(작업 10건·예산 30일), /root/scope/sow.md 를 만드세요.

착수 때 손에 쥐는 것은 요청 목록과 합의된 작업 목록과 합의문입니다. 펼친 뒤 sow.md 의 여섯 줄을 먼저 읽으세요 — 다음 단계의 규칙이 전부 거기서 나옵니다.

합의문을 규칙으로 옮기기

/root/scope/scope_rules.json 에 규칙을 차례대로 적으세요. 규칙마다 id(유일)·effect(in 또는 out)·match(system·action·tag 중 하나 이상)·reason(열 자 이상)을 넣습니다. 규칙 다섯 개 이상이어야 하고, 요청 25건에 걸었을 때 안·밖·보류가 모두 한 건 이상 나와야 합니다.

좁은 규칙을 위에 둡니다. 개인정보가 닿는 작업은 어느 시스템이든 밖이므로 맨 위에 오고, 시스템 단위 규칙은 그 아래입니다. 모든 요청을 덮으려 하지 마세요 — 걸리지 않은 것은 밖이 아니라 보류이고, 보류 목록이 규칙의 빈틈을 보여 줍니다.

안·밖·보류로 가르기

/root/scope/judge.py 를 만들어 요청마다 먼저 맞는 규칙으로 판정하고 /root/scope/verdicts.json 을 쓰게 하세요. 어느 규칙도 맞지 않으면 verdict 는 undecided 이고 rule 은 null 입니다.

요청을 규칙 목록 위에서부터 걸어 처음 맞는 규칙에서 멈춥니다. 끝까지 걸리지 않으면 보류입니다 — 밖으로 밀지 마세요. verdicts 는 요청 id 오름차순으로 정렬하고, counts 에 세 가지를 각각 셉니다.

조건이 모두 맞을 때만 잡기

match 에 action 과 tag 를 더해 조건이 모두 맞을 때만 규칙이 요청을 잡게 하세요. tag 는 요청의 tags 에 그 값이 들어 있으면 맞는 것입니다. 판정에는 결정한 규칙의 id 를 그대로 적습니다.

조건을 OR 로 다루면 좁은 규칙이 넓은 규칙처럼 굴어 우선순위가 무너집니다. 규칙에 적힌 조건만 보고, 적히지 않은 조건은 아무 값이나 통과시키세요. 채점기는 좁은 규칙과 넓은 규칙의 차례를 바꿔 가며 우선순위가 지켜지는지 봅니다.

전제 원장 만들기

/root/scope/assumptions.json 에 전제를 다섯 개 이상 적으세요. 전제마다 id·owner·statement(열다섯 자 이상)·if_broken(열다섯 자 이상)·verify_how(열 자 이상)·verified_on(YYYY-MM-DD)·valid_days(1 이상 365 이하)를 넣습니다. 기준일 2026-09-17 을 놓고 볼 때 이미 만료된 전제와 아직 유효한 전제가 각각 하나 이상 있어야 합니다.

깨지면 무엇이 무너지는가를 적어 보면 어떤 전제는 틀려도 아무 일이 없고 어떤 전제는 그 위에 계획 전체가 올라가 있다는 것이 드러납니다. 주인이 없는 전제는 기간이 지나도 아무도 확인하지 않으니 owner 를 반드시 적으세요. 확인일과 유효 기간은 전제마다 다르게 둡니다.

확인이 만료된 전제 찾기

/root/scope/assumptions.py 를 만들어 --ledger --as-of --out 으로 만료 여부를 판정하고, 기준일 2026-09-17 로 돌려 /root/scope/expired.json 을 만드세요. 만료일은 확인일에 valid_days 를 더한 날이고, 기준일이 만료일을 넘어야 만료입니다.

만료 경계를 하루 어긋나게 계산하는 실수가 흔합니다. 만료일 당일은 아직 유효하고, 그 다음 날부터 만료입니다. 결과에는 전제마다 계산한 만료일도 함께 적어야 고객이 언제까지 유효한지 볼 수 있습니다.

무엇을 빼겠습니까

새로 들어온 범위 밖 요청 RQ-021-NEW 에 대한 교환표를 /root/scope/tradeoff.json 에 적으세요. drop 은 baseline 의 작업 중 priority 가 must 가 아닌 것들이고, 합이 added_days 이상이면서 그중 아무거나 하나를 빼면 모자라야 합니다. question 은 뺄 작업의 id 를 모두 담은 한 문장이고 물음표로 끝납니다.

넉넉하게 많이 빼자고 하면 고객은 우리가 일을 줄이려 한다고 느낍니다. 큰 작업부터 담다가 합이 비용을 넘으면 멈추고, 그 묶음에서 빼도 되는 것이 있는지 다시 훑으세요. 반드시 해야 하는 작업은 교환 대상이 아닙니다.

범위와 전제를 보고하기

/root/scope/scope_report.md 에 ## 합의한 범위와 판정 결과 ## 판단이 보류된 요청 ## 전제와 만료된 확인 ## 무엇을 빼겠습니까 네 절로 적으세요. 판정 세 종류의 건수, 보류된 요청 id, 만료된 전제 id 와 그것이 깨지면 무엇이 무너지는지, 교환표의 숫자가 모두 나와야 합니다.

보고서는 손으로 쓰지 말고 verdicts·expired·tradeoff 세 파일에서 만들어 내세요. 보류 목록을 숨기지 마세요 — 보류가 다섯 건이면 규칙에 빈틈이 다섯 개라는 뜻이고, 그대로 보고하면 고객이 함께 채워 줍니다.