3장 정책과 실행계획을 분리한다

방법을 맡길 때 함께 넘어가는 것

리더가 실행을 위임할 때 어려운 문제는 작업 순서를 정하는 일만이 아니다. 수행자가 방법을 바꾸다가 지켜야 할 약속까지 바꾸는 일을 어떻게 알아볼 것인가. 계획대로 진행하기 어려울 때 일정과 범위를 조정할 수는 있다. 그러나 어떤 조정이 실행자의 권한에 속하고 어떤 조정이 새로운 사업 판단을 요구하는지 불분명하면, 조직은 매번 승인을 기다리거나 경계를 넘어선 결과를 뒤늦게 발견한다.

예를 들어 고객 정보 조회 방식을 개선하는 작업을 생각해 보자. 이는 원리를 설명하기 위한 가상 상황이며 실제 고객 사례가 아니다. 실행자는 검색 방식과 작업 순서, 사용할 도구를 바꿀 수 있다. 하지만 편의를 위해 고객 정보를 허용되지 않은 외부 서비스로 보내는 결정은 다른 성격을 갖는다. 방법의 변경이 정보 취급의 경계를 바꾸기 때문이다. 결과가 빨리 나왔다는 사실만으로 그 변경을 수용할 수는 없다.

이 책은 보존해야 할 제약과 권한을 정책에 담고, 그 안에서 선택하는 작업과 방법을 실행계획에 담도록 제안한다. P02 ‘정책과 계획의 분리’의 중심은 문서를 둘로 나누는 데 있지 않다. 수행 방법을 고칠 권한과 허용 경계를 고칠 권한을 구분하고, 각각의 변경을 서로 다른 증거로 판단하는 데 있다. 정책과 계획을 별도 파일에 기록해도 실행자가 양쪽을 함께 완화할 수 있다면 이 구분은 작동하지 않는다.

정책은 경계를 정하고 계획은 경로를 선택한다

2장에서 의도는 달성할 결과와 그 이유를 연결했다. 정책은 그 의도를 따르는 실행이 허용되는 조건, 권한의 범위, 충돌할 때의 우선순위를 정한다. 실행계획은 현재 조건에서 어떤 작업을 어떤 순서로 수행하고 결과를 어떻게 확인할지 정한다. 의도에 비추어 필요한 경계를 정책으로 구체화하고, 그 경계 안에서 목적에 도달할 경로를 계획으로 선택하는 관계다.

어떤 조건이 정책인지는 표현의 단호함으로 판단하기 어렵다. 같은 도구를 사용하라는 문장도 선택의 이유에 따라 달라진다. 현재 팀이 익숙해서 선택했다면 계획의 판단일 수 있다. 계약상 허용된 처리 환경을 유지하기 위한 조건이라면 정책의 판단일 수 있다. 리더는 조건을 어겼을 때 누구의 약속과 위험이 바뀌는지 묻고, 그 변경을 결정할 권한을 배치해야 한다.

구분	정책	실행계획
답할 질문	어떤 조건과 권한 아래에서 실행할 수 있는가	현재 조건에서 어떻게 결과에 도달할 것인가
변경의 근거	위험·약속·사업 조건의 변화와 경계 변경의 영향	작업 증거·의존성·실행 가능성의 변화
변경 권한	해당 위험과 약속을 책임지는 주체	정책 범위 안에서 위임받은 실행 주체
검증의 대상	필요한 경계를 빠뜨리지 않았는지와 실제로 적용되는지	선택한 방법이 실행 가능하며 경계와 결과 기준을 충족하는지
재검토 시점	경계를 정당화한 조건이 달라지거나 예외가 반복될 때	실행 중 새 정보와 장애를 발견할 때

이 구분은 이 책의 설계 제안이다. 정책은 오래 유지하고 계획은 자주 바꾼다는 시간 차이만으로 정의하지 않는다. 정책도 근거가 바뀌면 즉시 재검토해야 하고, 계획의 일부는 여러 실행에서 재사용할 수 있다. 중요한 것은 변경 빈도보다 변경을 정당화하는 이유와 책임이다.

저자의 「바이브 코딩 시대, 저장소 규칙과 개인 취향의 경계」는 공통 규칙을 개인의 선호와 구분하고 위반했을 때의 영향을 기준으로 판단하자고 제안한다.[S38] 이 책의 정책 검토에도 이 관점을 적용할 수 있다. 책임자가 선호하는 방법이라는 이유만으로 변경 금지의 경계가 되어서는 안 된다. 반대로 겉으로는 형식의 선택처럼 보여도 다른 작업의 계약과 검증이 의존한다면 공통 조건일 수 있다. 리더는 무엇을 고정했는지와 함께 그 조건이 보호하는 약속과 변경 비용을 설명해야 한다.

계획을 바꾸는 권한을 구체적으로 위임한다

2장에서 소개한 Intent Engineering은 구현 방법을 의도와 구분해 위임할 것을 제안한다.[S69] 이 책은 그 문제의식을 이어받되 방법이 이미 계약·호환성·정보 취급의 약속인 경우에는 책임자가 정한 제약으로 다룬다. 같은 기술 선택도 탐색 가능한 대안인지 지켜야 할 경계인지에 따라 위임 권한이 달라진다. 의도 문서에서 구현 세부를 줄이는 일과 약속의 제약을 없애는 일을 혼동하지 않는다.

계획 조정 권한을 준다는 말에는 조정 가능한 대상이 들어 있어야 한다. 작업 순서, 담당 실행 주체, 사용 도구를 바꿀 수 있는지 정하고, 그 변경이 다른 작업의 입력이나 완료 기준에 영향을 줄 때 누구에게 알릴지도 정한다. 실행자가 변경 가능한 범위를 알면 경계 안의 작은 조정마다 리더에게 돌아오지 않아도 된다. 리더는 방법의 세부 선택보다 위임 범위와 결과 판정에 집중할 수 있다.

앞의 가상 상황에서 실행자가 대안적인 조회 방식을 찾았다고 하자. 허용된 환경에서 처리하고 기존의 결과 기준을 충족한다면 계획을 조정할 수 있다. 외부 전송이 필요하거나 약속한 정보 범위를 바꾸어야 한다면 정책 판단으로 넘긴다. 이때 실행자는 실행을 막은 조건, 검토한 대안, 경계를 바꾸지 않고 진행할 수 있는 부분을 제시한다. 책임자는 그 정보를 바탕으로 예외를 허용할지, 범위를 줄일지, 중단할지 결정한다.

계획 검증에는 해당 작업의 결과 확인과 정책 준수 확인이 함께 필요하다. 방법을 교체했는데 기존 검증이 사라졌다면 새 계획이 같은 약속을 지킨다고 판단하기 어렵다. 반대로 기존 검사가 특정 구현 방법에만 묶여 있다면 대안에 맞는 검증 방법을 제안할 수 있다. 검사 방법을 바꾸는 권한과 수용 기준을 낮추는 권한도 구분해야 한다. 검사 변경이 동일한 기준을 충분히 확인하는지는 결과 수용 권한을 가진 주체가 판단한다.

공개 구현에서 확인할 수 있는 경계

GitHub의 공식 문서는 저장소 규칙으로 브랜치와 태그의 변경 조건을 정하고, 규칙 편집 권한과 일부 주체의 우회 권한을 설정할 수 있다고 설명한다. 적용 중인 여러 규칙은 함께 작동하며, 집행 상태를 바꾸는 기능도 제공한다.[S16] 이는 제품이 제공하는 구조에 관한 문서 확인이다. 특정 조직이 이 구조를 어떻게 운영했고 어떤 성과를 얻었는지는 여기서 확인하지 않았다.

이 구조에서 얻을 수 있는 해석은 작업 방법과 변경 수용 조건을 따로 관리할 수 있다는 것이다. 실행자가 해결 방법을 선택해도 변경을 수용하는 경계는 별도의 장치에 남길 수 있다. 다만 규칙을 끄거나 우회할 수 있는 권한까지 실행자에게 주면 경계의 효력은 달라진다. 이 책은 자동화의 권한을 정할 때 일반 실행 권한과 규칙 변경·예외 권한을 함께 점검하도록 권한다. 규칙의 존재와 그 규칙이 모든 실행에 적용된다는 사실은 별도로 확인해야 한다.

Anthropic은 2025년 10월 공개 글에서 파일과 네트워크 접근의 범위를 제한하는 실행 환경을 설명했다. 정해진 범위 안에서 에이전트가 작업하고, 경계 밖의 접근은 별도 허용 판단으로 연결하는 구조다.[S17] 여기서 확인한 것은 업체가 설명한 설계이며 이 책에서 도구를 설치하거나 실행해 검증한 결과는 아니다. 업체가 제시한 성과 수치는 이 장의 효과 근거로 사용하지 않는다.

이 설명에서 얻을 수 있는 해석은 모든 행동을 개별 승인하는 대신, 허용 범위를 먼저 정하고 범위를 넘는 행동을 판단 대상으로 남길 수 있다는 것이다. 다만 접근을 허용하는 경계가 결과의 정확성이나 사업적 타당성까지 보장하지는 않는다. 실행 경계를 정하는 판단과 결과를 수용하는 판단을 연결해야 한다. 이 책의 P02는 이 관계를 조직의 책임으로 확장한 제안이며, 두 제품 사례가 P02의 보편적 효과를 입증한다고 주장하지 않는다.

정책을 바꾸는 변경도 분류한다

데모의 위험 정책은 변경 경로의 등급과 필수 검사를 선언한다. 정책·워크플로·팩토리 자체 코드의 변경은 일반 제품 변경보다 높은 등급으로 분류된다.[S60] 어떤 기능을 구현할지와 그 변경을 받아들일 조건을 다른 대상으로 관리하는 예다.

리더는 정책 파일이 따로 있는지만 볼 것이 아니라 그 파일을 바꾸면 누구의 판단이 필요한지 확인한다. 규칙이 지키는 약속과 정책 변경의 검증이 연결되어야 한다. 경로는 이 구현이 선택한 위험 판별 수단이며 실제 사용자 영향과 항상 일치하는 보편 기준은 아니다. 12장은 이 분류가 병합 판단에 연결되는 조건과 한계를 살펴본다.

실행 계약으로 연결을 유지한다

정책과 계획을 분리하면 어느 정책에 따라 어떤 계획을 실행했는지 다시 연결해야 한다. 연결이 없으면 최신 정책을 읽고 과거 실행을 판단하거나, 새 계획에 이전의 권한이 그대로 적용된다고 오해할 수 있다. 이 책은 P03 ‘실행 가능한 계약’으로 작업에 필요한 입력과 출력, 권한, 완료 증거, 실패 처리를 묶도록 제안한다. 실행 계약은 실행에 적용하는 기준을 식별하고 필요한 순간에 확인할 수 있게 하는 구조다.

계약에는 작업의 목적과 산출물, 적용할 정책의 버전, 계획의 버전, 허용된 조정 범위, 결과 수용의 근거를 연결한다. 진행 중 계획을 바꾸면 새 계획이 보존한 경계와 변경 이유를 남긴다. 정책을 바꾸면 적용을 시작할 시점과 영향을 받는 진행 작업을 결정한다. 긴 실행의 중간에 기준이 바뀌었다면 계속할지, 다시 검증할지, 중단할지를 명시해야 한다. 버전 번호만 남기는 것으로 이 판단을 대신할 수는 없다.

계약의 내용은 실행 주체가 실제로 확인할 수 있어야 한다. 자동 검사로 확인할 조건은 실행과 판정에 연결하고, 해석이 필요한 조건은 판단 책임자와 필요한 증거를 연결한다. 사람과 에이전트가 같은 문장을 읽는다고 같은 판단을 한다고 가정해서는 안 된다. 서로 다른 실행 주체에게 작업을 맡겼을 때 어떤 질문과 경계 해석의 차이가 발생하는지 관찰해야 계약의 부족한 부분을 찾을 수 있다.

예외가 정책을 지우지 않게 한다

정책이 현실을 빠뜨릴 수 있으므로 예외 절차는 필요하다. 그러나 예외를 허용한다는 판단과 정책 전체를 변경한다는 판단은 다르다. 예외에는 대상 작업, 허용할 행동, 이유, 결정 책임자, 종료 조건을 붙인다. 적용 범위가 좁더라도 다른 사용자나 팀이 부담할 위험을 확인해야 한다. 실행자가 자신의 장애를 없애기 위해 다른 주체의 약속을 바꿀 수는 없다.

같은 예외가 반복되면 정책이 지나치게 좁거나 계획에 필요한 능력이 부족할 수 있다. 둘을 구분해야 한다. 허용 환경 안에서도 대안이 있었는데 이를 찾지 못했다면 계획과 실행 능력을 검토한다. 경계를 정한 이유가 이미 달라졌다면 정책을 재검토한다. 예외 승인 횟수만으로 어느 쪽이 잘못됐는지 단정하지 않고, 원인과 영향을 확인할 증거를 모은다.

소규모 팀에서는 한 사람이 계획을 바꾸고 정책 예외도 판단할 수 있다. 이때 필요한 것은 직책을 추가하는 일보다 어떤 권한으로 무엇을 바꾸었는지 구분하는 일이다. 다만 한 사람이 놓친 조건을 같은 사람이 계속 수용할 위험은 남는다. 변경의 영향이 크거나 복구가 어려운 경우에는 별도의 검토를 배치할지 판단해야 한다. 권한을 분리하는 정도는 결과의 영향과 검토 비용에 맞춰 정한다.

경계를 유지하는 비용도 검토한다

정책과 계획의 분리는 연결 관계를 관리하는 비용을 만든다. 정책의 변경을 실행 계약에 반영해야 하고, 검증 장치가 정책과 어긋나지 않는지도 확인해야 한다. 오래된 기준이 남거나 서로 충돌하는 정책의 적용 순서가 불분명하면 실행자는 문서를 더 읽고도 결정하지 못할 수 있다. 따라서 리더는 정책마다 책임자와 재검토 조건을 정하고, 충돌을 발견했을 때 판단할 경로를 유지해야 한다.

탐색 작업에는 세밀한 계획을 미리 확정하기 어려운 경우가 있다. 이 경우에도 접근 가능한 정보, 허용 자원, 외부에 할 수 있는 약속의 경계는 정할 수 있다. 계획에는 무엇을 알아내려는지와 어떤 관찰 뒤에 다음 작업을 정할지를 담는다. 모든 실험을 완성품의 계약으로 묶으면 학습을 방해할 수 있다. 탐색 결과의 수용 기준과 제품 결과의 수용 기준을 구분해야 한다.

반복할 이유가 적고 영향이 작으며 되돌리기 쉬운 작업에는 별도 정책 체계를 만드는 비용이 더 클 수도 있다. 이 책은 모든 작업에 같은 문서와 승인 절차를 적용하도록 권하지 않는다. 기존 기준을 참조하는 짧은 작업 기록으로 충분한지 먼저 판단한다. 반대로 실행자가 여러 팀의 정보와 자원에 접근하거나 같은 작업을 반복한다면, 경계와 권한을 유지하는 비용을 감수할 이유가 커진다.

리더는 무엇을 관찰할 것인가

P02의 유용성을 확인하려면 계획을 바꾼 뒤에도 정책 준수의 검증이 유지되는지 살핀다. 검증 누락, 경계 해석의 반복 질문, 권한 밖 변경, 예외가 끝난 뒤에도 남은 권한을 기록한다. 계획 조정에 걸린 판단 대기와 정책 관리에 새로 들어간 부담도 함께 본다. 경계 위반이 드러나지 않았다는 사실만으로 효과를 확정하지 않는다. 검사가 놓친 조건과 보고되지 않은 예외도 검토할 필요가 있다.

P03은 입력·권한·증거가 실제로 다음 수행과 수용 판단에 쓰였는지 확인한다. 기록이 많아졌는데 질문과 재작업의 이유를 설명하지 못한다면 계약의 구조를 줄이거나 바꾸어야 한다. 리더가 유지할 핵심은 방법을 개선할 자유와 약속을 변경할 책임의 연결이다. 계획을 위임한 뒤에도 결과의 수용과 정책 변경의 책임은 식별할 수 있어야 한다.

원서의 목적 중심 리더십과 규제 환경이라는 주제에 비추어 보면, 이 장의 재고찰 질문은 의도를 전달한 뒤 변경 권한과 판정 책임을 어떻게 유지할 것인가이다. 현재의 대응은 공개 목차를 기준으로 한 주제 연결이며 『More Effective Agile』의 해당 본문을 대조하거나 세부 논증을 평가한 결과가 아니다. 대조 범위는 원서 주제 연결의 범위에 남긴다.

다음 장은 이 관계를 수행·검증·운영 관찰의 반복으로 연결한다. 정책과 계획의 구분은 한 번의 위임을 명확하게 한다. 의도 실행 루프는 그 실행에서 얻은 증거로 다음 위임의 기준을 고치게 한다.

출처와 검토

[S16], [S17], [S38], [S60], [S69]. 공개 자료의 확인 범위와 한계는 출처 대장, 주요 주장의 성격과 검토 사항은 자료 확인 범위에 기록한다. 사례의 조직 성과, 실행 검증, 패턴 효과는 확인하지 않았다.