1통제의 네 요소
통제는 목표에서 벗어나는 일을 막거나 찾아내거나 바로잡는 장치와, 그 장치가 작동했다는 기록으로 이뤄진다. 이 트랙은 통제 하나를 네 요소로 적는다.
| 요소 | 뜻 | Launchpad 예 |
|---|---|---|
| 통제 목표(control objective) | 막으려는 일을 한 문장으로 적은 것 | 승인 없는 변경이 main에 들어가지 않는다 |
| 통제 활동(control activity) | 목표를 지키려고 하는 일. 사람이 하거나 시스템이 한다 | main의 규칙 세트가 승인 1명 없이는 병합을 막는다 |
| 증적(evidence) | 통제 활동이 실제로 있었음을 다른 사람이 확인할 수 있는 기록 | gh ruleset view 결과, PR의 리뷰 기록 |
| 검토(review) | 증적을 정해진 주기로 확인하고 결과를 남기는 일 | 매주 만들어지는 통제 점검 이슈와 결정 기록 댓글 |
통제 활동은 작동하는 시점에 따라 셋으로 나뉜다. 한 통제 목표에 세 종류를 함께 두면, 예방 통제가 우회된 경우를 탐지 통제가 찾고 교정 통제가 되돌린다.
| 종류 | 작동 시점 | GitHub에서 | 모듈 |
|---|---|---|---|
| 예방 통제(preventive) | 일이 일어나기 전 | 규칙 세트의 승인 요구와 필수 검사, CODEOWNERS, 변경 요청 양식 | B1, B2 |
| 탐지 통제(detective) | 일이 일어난 뒤 | 기준선 차이 보고, 릴리스 추적 보고의 빈 곳, 주간 통제 점검 | B1, B3, B4 |
| 교정 통제(corrective) | 찾아낸 뒤 | 사후 변경 요청, 되돌리기 PR, 사후 리뷰, 권한 회수, 규칙 수정 | B1, B2, B4 |
2참조하는 틀: COSO와 3선 모델
내부통제의 표준 틀은 미국 트레드웨이 위원회 후원 조직 위원회(COSO)가 2013년에 개정한 내부통제 통합 프레임워크(Internal Control – Integrated Framework)다. 다섯 구성요소와 17개 원칙으로 이뤄지며, 트랙 B의 모듈은 그중 아래 원칙에 해당한다.
| COSO 구성요소 | 관련 원칙 | 트랙 B에서 |
|---|---|---|
| 통제 환경(control environment) | 원칙 3: 구조, 보고 체계, 권한과 책임을 정한다 | B1 결정 권한 표, B2 저장소 역할과 우회 권한 |
| 위험 평가(risk assessment) | 원칙 9: 중요한 변화를 식별하고 분석한다 | B1 변경 요청의 영향 분석 |
| 통제 활동(control activities) | 원칙 10~12: 통제 활동을 정하고, 기술에 대한 일반 통제를 정하고, 정책과 절차로 배치한다 | B1 변경 통제 절차, B2 규칙 세트, B3 커밋·릴리스 규칙 |
| 정보와 의사소통(information & communication) | 원칙 13~14: 관련 정보를 쓰고 내부에 전달한다 | B3 릴리스 추적 보고 |
| 모니터링 활동(monitoring activities) | 원칙 16~17: 지속적 평가와 개별 평가를 하고, 결함을 평가해 전달한다 | B4 주간 통제 점검과 분기 보고 |
누가 통제를 운영하고 누가 점검하는지는 내부감사인협회(IIA)가 2020년 7월에 발표한 3선 모델(Three Lines Model)로 나눈다. 이전의 3중 방어선(Three Lines of Defense) 모델을 고친 것이며, 이사회 같은 감독 기구(governing body), 경영진, 내부감사를 구분한다.
| 역할 | 하는 일 | Launchpad에서 |
|---|---|---|
| 1선 (first line) | 제품과 서비스를 만들며 위험을 직접 관리한다 | 개발자와 PM. 규칙 세트 아래에서 일하고, 예외가 생기면 기록한다 |
| 2선 (second line) | 위험 관리, 품질, 준법에 관한 전문 지원과 점검을 한다 | 품질·보안 담당이나 다른 팀의 PM. 주간 통제 점검 이슈를 검토한다 |
| 3선 (third line) | 통제의 효과를 독립적으로 확인해 감독 기구에 보고한다 | 내부감사. 분기 보고의 점검을 같은 데이터로 다시 수행한다 |
네 명뿐인 Launchpad 팀처럼 1선과 2선을 다른 사람에게 맡기기 어려운 팀도 있다. 3선 모델은 1선과 2선의 역할을 합치거나 나눌 수 있다고 본다. 합친 경우에는 점검 결과를 팀 밖의 사람이 볼 수 있게 남기는 것으로 독립성을 보완한다.
3모듈 구성
| 모듈 | 답하는 질문 | 산출물 | 시간 |
|---|---|---|---|
| B1 기준선과 변경 통제 | 합의한 범위·일정·원가 기준선이 언제, 누구의 승인으로, 어떤 영향 분석을 거쳐 바뀌었는가 | 변경 요청 양식, 기준선 파일과 CODEOWNERS, 변경 통제 절차서, 기준선 차이 보고 | 180분 |
| B2 저장소 통제 | 승인 없이, 검사를 통과하지 않고 기본 브랜치에 들어가는 변경을 막았는가. 막았다는 것을 지금 보일 수 있는가 | main 규칙 세트, 통제 매트릭스, 접근 권한 점검 | 180분 |
| B3 추적성과 감사 증적 | 이번 릴리스의 변경 하나하나가 어떤 요구에서 왔고, 누가 검토하고 승인했고, 어떤 검사를 통과했는지 5분 안에 답할 수 있는가 | 릴리스 추적 보고, 증적 보존 규칙 | 180분 |
| B4 통제 점검 자동화 | 통제가 매주 실제로 지켜지는지, 예외는 몇 건이고 누가 승인했는지 사람이 찾아보지 않고 알 수 있는가 | 통제 점검 워크플로, 분기 통제 점검 보고 | 180분 |
B1은 Level 1의 Launchpad 사례(업무 6건, 2026년 10~11월)를, B4는 2단계의 Orbit 사례를 PR 단위로 다시 쓴다. 모듈은 순서대로 듣는다. B2의 규칙 세트는 B1의 CODEOWNERS를 강제하고, B3의 추적 보고는 B2의 설정이 남긴 결과를 읽고, B4는 B2와 B3의 점검을 매주 자동으로 돌린다.
4선행 학습
| Level 1 실습 | 트랙 B에서 쓰는 것 |
|---|---|
| 실습 9 PR과 커밋 읽기 | 닫는 키워드, closingIssuesReferences, reviewDecision, gh pr checks |
| 실습 12 범위 변경과 종료 | 범위 변경 기록(LP-07), 시작 기록과 종료 기록의 비교 |
| 실습 18 브랜치 | pm-data 브랜치의 평일 Project 스냅숏, 저장소 이벤트 API의 90일 한계 |
| 실습 26 적합성 검사 | process-map.sh --rules의 규칙 파일 형식, 4-eyes 검사 |
| 실습 29 개선 확인과 정기 분석 | 예약 실행 워크플로를 저장소에 설치하는 절차, .github/pm-kit/ 폴더 |
실습 13·14의 일정 기준선과 획득가치(BAC 112h)도 B1에서 다시 쓴다. Level 1의 작업 폴더(~/gh-pm-lab)와 pm-lab/env.sh를 그대로 쓴다.
cd ~/gh-pm-lab source pm-lab/env.sh gh --version
설치된 gh에 gh ruleset과 gh attestation 명령이 있어야 한다. gh ruleset --help가 도움말을 보여 주지 않으면 gh를 새 버전으로 올린다. 이 트랙의 명령, 옵션, 출력 형식은 gh 2.101.0의 소스로 확인했다.
5요금제와 공개 범위에 따른 제약
통제 기능은 저장소의 공개 여부, 소유자(개인 계정 또는 조직), 요금제에 따라 쓸 수 있는 범위가 다르다. 아래 표는 2026년 10월 GitHub Docs의 “누가 이 기능을 쓸 수 있는가” 항목 기준이다. 요금제 구성은 바뀔 수 있으므로 도입 전에 해당 문서를 다시 확인한다.
| 기능 | 쓸 수 있는 범위 | 모듈 |
|---|---|---|
| 보호된 브랜치(protected branches) | 공개 저장소: GitHub Free, GitHub Free for organizations. 공개·비공개 저장소: GitHub Pro, GitHub Team, GitHub Enterprise Cloud, GitHub Enterprise Server | B2 |
| 코드 소유자(CODEOWNERS) | 보호된 브랜치와 같다 | B1, B2 |
| 저장소 규칙 세트(repository rulesets) | 공개 저장소: Free, Free for organizations. 공개·비공개 저장소: Pro, Team, Enterprise Cloud | B2 |
| 조직 규칙 세트(organization rulesets) | Team(2025년 6월부터)과 Enterprise 요금제의 조직 | B2 |
| 규칙 세트의 평가(evaluate) 상태 | GitHub Enterprise. 그 밖에는 적용(active)과 꺼짐(disabled)만 쓴다 | B2 |
| 병합 큐(merge queue) | 조직이 소유한 공개 저장소, Enterprise Cloud 조직이 소유한 비공개 저장소. 개인 계정의 저장소는 쓸 수 없다 | B2 |
| 배포 환경(environments)과 배포 보호 규칙 | 공개 저장소: 모든 현재 요금제. 비공개·내부 저장소의 환경, 환경 비밀값, 배포 브랜치 제한: Pro, Team, Enterprise. 필수 리뷰어(required reviewers)와 대기 시간(wait timer)은 Free, Pro, Team에서는 공개 저장소에만 쓸 수 있다 | B2 |
| 산출물 증명(artifact attestations) | 공개 저장소: 모든 현재 요금제. 비공개·내부 저장소: Enterprise Cloud. Bronze, Silver, Gold 같은 이전 요금제는 쓸 수 없다 | B3 |
| 조직 감사 로그(audit log) REST API | Enterprise Cloud 조직. Enterprise Cloud 문서 기준으로 감사 로그는 최근 180일의 사건을 보여 주고, Git 사건(push, clone 등)은 7일만 남는다 | B3 |
| 저장소 이벤트 API | 모든 저장소. 최근 90일, 최대 300건 (실습 18) | B3 |
Level 1의 실습 저장소(gildong/launchpad-pm-lab처럼 개인 계정이 소유한 저장소)는 공개로 두면 규칙 세트, CODEOWNERS, 배포 환경의 필수 리뷰어, 산출물 증명을 무료로 실습할 수 있다. 비공개로 두려면 GitHub Pro 이상이 필요하고, 그래도 필수 리뷰어와 비공개 산출물 증명은 쓸 수 없다. 병합 큐, 조직 규칙 세트, 감사 로그 API는 개인 계정 저장소에서 실습할 수 없으므로 이 트랙에서는 명령과 확인할 필드만 다룬다. 개인 계정 저장소의 협업자는 모두 쓰기 권한을 받으며, 읽기·분류·관리 같은 역할을 나누려면 조직 저장소가 필요하다.
6키트 파일
| 파일 | 하는 일 | GitHub 접속 | 모듈 |
|---|---|---|---|
baseline-diff.sh | 기준선 스냅숏과 현재 스냅숏의 차이(업무 추가·제외, 목표일, 공수, 반복, 마일스톤 마감)를 작업일로 보고하고 변경 대장과 대조한다 | 아니요 | B1 |
control-matrix.sh | 규칙 세트 JSON과 협업자 JSON으로 통제 매트릭스를 만든다 | 아니요 | B2 |
release-trace.sh | 릴리스에 들어간 PR 목록으로 추적 보고를 만들고 빈 곳을 표시한다 | 아니요 | B3 |
pr-event-log.sh | 병합된 PR을 사례로 삼는 이벤트 로그(CSV)를 만든다 | 예 (--from-json이면 아니요) | B4 |
four-eyes.sh | PR 단위 로그로 4-eyes 원칙을 전수 점검하고 예외 기록을 대조한다 | 아니요 | B4 |
templates/ISSUE_TEMPLATE/change-request.yml | 변경 요청 이슈 양식 | - | B1 |
templates/CODEOWNERS.example, templates/change-control.md | 기준선 파일의 코드 소유자 예시, 변경 통제 절차서 양식 | - | B1 |
templates/ruleset-main.json | 기본 브랜치 규칙 세트를 만드는 REST 요청 본문 | - | B2 |
templates/workflows/control-check.yml, templates/control-report.md | 주간 통제 점검 워크플로, 분기 통제 점검 보고 양식 | - | B4 |
예시 데이터는 samples/의 b-로 시작하는 파일이다. Launchpad의 기준선과 10월 30일 스냅숏, 변경 대장, 규칙 세트와 협업자, M1 릴리스의 PR과 업무, Orbit의 PR 단위 이벤트 로그와 통제 규칙이 있다. 저장소의 실제 값으로 바꿔 실행하는 명령은 각 모듈에 있다.
참고 자료
- COSO, Internal Control — Integrated Framework (2013). IIA, The IIA's Three Lines Model: An update of the Three Lines of Defense (2020)
- ISO 10007:2017 Quality management — Guidelines for configuration management. ISO/IEC 27001:2022 Information security management systems — Requirements (부속서 A)
- AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (SOC 2 공통 기준 CC8.1)
- ANSI/EIA-748 Earned Value Management Systems. PMI, A Guide to the Project Management Body of Knowledge 6판(2017)의 4.6 통합 변경 통제 수행
- Rogers, Blenko, “Who Has the D? How Clear Decision Roles Enhance Organizational Performance”, Harvard Business Review (2006년 1월). Nygard, “Documenting Architecture Decisions” (2011)
- Conventional Commits 1.0.0, Semantic Versioning 2.0.0, SLSA v1.0
- GitHub Docs: 규칙 세트, 보호된 브랜치, 코드 소유자, 배포 환경, 병합 큐, 산출물 증명, 규칙 REST API
- GitHub CLI 매뉴얼: gh ruleset check, gh attestation verify
- 통제 목표, 통제 활동, 증적, 검토를 Launchpad의 예로 하나씩 말할 수 있다.
- 예방·탐지·교정 통제가 각각 어느 모듈에서 나오는지 확인했다.
- 실습 저장소의 공개 여부와 요금제로 B2의 어느 기능을 실습할 수 있는지 확인했다.
- 키트에
baseline-diff.sh,control-matrix.sh,release-trace.sh,pr-event-log.sh,four-eyes.sh가 있다.
마치며...
통제는 막는 장치 하나로 끝나지 않는다. 목표를 문장으로 적고, 그 목표를 지키는 설정이나 절차를 두고, 작동했다는 기록을 남기고, 그 기록을 정해진 주기로 확인해야 다른 사람에게 통제가 있다고 말할 수 있다. 트랙 B의 네 모듈은 이 순서를 기준선, 저장소 설정, 추적 기록, 자동 점검에 차례로 적용한다. B1에서는 Launchpad의 일정·원가 기준선을 파일로 고정하고, 10월 30일의 Project와 비교해 승인 기록이 없는 변경을 찾는다.