금융권 4-eyes 배포 — 이론과 *실제로 작동하는* 패턴 사이의 갭

금융권 IT 감사관이 자주 묻는 한 줄 — "배포에 4-eyes 통제가 적용되어 있나요?"

답이 예 라고 하면 끝나지 않는다. 다음 질문은 어떻게 다. 거기서 실제 작동하는 패턴 과 서류상의 패턴 이 갈라진다.

이 글은 6개 은행 IT 팀에서 본 실제 작동하는 패턴 4가지다.

서류상 4-eyes 가 멈추는 이유

가장 단순한 4-eyes 구현 — 모든 production 배포가 2명의 명시적 승인 후 트리거. 이게 작동하지 않는다. 이유 셋:

1. 야간 배치 가 깨지면 02:00 에 fix 배포 필요. 두 번째 사람이 깨어 있지 않음.
2. hot fix 가 5분 안에 들어가야 하는데 두 번째 사람의 response time 이 분 단위.
3. 4-eyes 룰을 피하는 우회 (bypass token, emergency override) 가 남용 되어 오히려 4-eyes 가 약화됨.

패턴 1 — 시간대 분할 4-eyes

업무 시간 (09~18) — 표준 4-eyes. 야간 / 주말 — 비상 운영자 1명 + post-hoc 검토.

시간대        | 사전 승인 | 사후 검토
─────────────┼───────────┼──────────
09~18 평일    | 2명      | 0
야간 / 주말   | 1명      | 다음 영업일 09:00 까지

사후 검토 가 빠지면 야간 운영이 그냥 1-eye. 이걸 놓치는 곳 이 많음.

패턴 2 — 변경 등급별 4-eyes

모든 배포가 같은 통제를 받지 않음. 변경의 위험도 에 따라 4-eyes 강도 가 다름.

등급 | 변경 종류                       | 통제
────┼─────────────────────────────────┼─────────────────────────
S   | 코어 결제 / 잔고 / 인증           | 2명 + 보안팀 + CTO
A   | 일반 비즈니스 로직                | 2명
B   | UI / 비즈니스 외 backend         | 1명 + 자동 검증
C   | 정적 자산 / 문서                 | 자동 머지 후 사후 검토

변경 등급 자동 분류 가 핵심. 사람이 매번 등급을 매기면 항상 가장 낮은 등급 으로 표시됨.

패턴 3 — 암묵적 4-eyes — PR 리뷰 + 배포자

PR 리뷰어가 첫 번째 eye, 배포 트리거 사람이 두 번째 eye. 두 사람이 다른 사람 이면 4-eyes 만족.

git log:
  PR author:    alice
  PR reviewer:  bob       ← 첫 번째 eye
  PR approver:  bob       
  Deploy:       charlie   ← 두 번째 eye, alice 또는 bob 과 달라야

이 패턴이 서류 + 운영 둘 다 만족 시키는 가장 매끄러운 패턴. 다만 감사관이 받아들이는지 가 은행마다 다름. 금감원 감사 사례에서 두 번 채택, 한 번 거부.

패턴 4 — 기계 + 사람 4-eyes

자동 검증 시스템이 첫 번째 eye, 사람이 두 번째 eye. 자동 검증이 명시적 통제 권한 을 가져야 하고, 그 통제 권한 이 별도 audit trail 을 가져야 함.

1. 자동: 정적 분석 + 보안 스캔 + 회귀 테스트 → 통과 시 *기계 승인 stamp*
2. 사람: PR 리뷰 + 명시적 승인
3. 배포: 두 stamp 모두 있어야 가능

이 패턴은 정밀하지만 인프라 무거움. 자동 검증이 깨지면 전체 배포가 멈춤 — 자동 검증 자체가 높은 가용성 을 가져야 함.

6 은행의 실제 채택

은행 | 채택 패턴              | 결과
────┼───────────────────────┼─────────────────────────────
A   | 패턴 1 (시간대)        | 운영 가능, 사후 검토 누적이 문제
B   | 패턴 2 (등급)          | 만족, 등급 자동 분류가 결정적
C   | 패턴 1 + 패턴 2        | 가장 깔끔, 비용 큼
D   | 패턴 3 (암묵)          | 감사관 거부, 패턴 2 로 전환
E   | 패턴 4 (기계+사람)     | 인프라 부담, 결국 패턴 2 로 후퇴
F   | 패턴 1 + 패턴 3        | 운영 가능, 감사 한 번 통과

가장 자주 통과한 패턴은 패턴 2 (변경 등급별). 가장 자주 거부된 패턴은 패턴 3 (암묵) — 감사관 입장에서 명시성 이 부족.

핵심 — 명시성

위 4 패턴의 공통점 — 명시성. 4-eyes 가 무엇인지, 언제 어떻게 적용되는지 가 코드 / 정책 / 도구에서 명시 되어야 함. 사람의 선의 나 관행 에 의존하면 감사 통과 못 함.

"4-eyes 적용 중" 이라는 답만으로 감사를 통과할 수 있나

금융 / 공공 배포 통제 감사에서 4-eyes 를 적용한다 는 답만으로는 통과하지 못한다. 어떻게 의 답이 위 4 패턴 (시간대 / 변경 등급 / 암묵 / 기계+사람) 중 어느 것인지 명시되지 않으면, 다음 감사에서 "개선 권고" 또는 "부적합" 이 나올 가능성이 크다. IT 운영 책임자가 지금 확인할 것은 하나 — 우리 4-eyes 가 코드 / 정책 / 도구 어디에 명시 되어 있는가.