개념
금융 QA가 다른 도메인과 다른 한 가지
대부분의 도메인에서 QA 절차는 조직이 스스로 정한다. 금융에서는 규정이 절차의 뼈대를 먼저 정한다. 프로그램을 운영에 올리기 전에 누가 시험하고 누가 승인하는지, 전산원장을 고칠 때 누가 이중으로 확인하는지, 재해복구 전환을 몇 번 훈련하는지가 행정규칙에 적혀 있다. 모듈 40의 의료기기가 "제출해야 할 증거"를 규정한다면, 금융은 "평소에 지켜야 할 통제" 를 규정하고 검사·감사로 확인한다.
규제가 왜 이렇게 촘촘한지는 숫자가 설명한다. 국회에 제출된 금융감독원 자료에 따르면 2020년부터 2025년 5월까지 국내 금융권 전산장애는 1,763건, 피해 금액은 약 295억 원이었다. 연도별로 2020년 238건에서 2024년 392건으로 매년 늘었고, 2025년에는 5개월 만에 170건이었다. 업권별로는 은행 577건, 증권 475건 순이었다. 원인은 프로그램 오류와 시스템·시설·설비 장애가 72.9% 를 차지했다(프로그램 오류 722건).
QA에게 이 숫자의 의미는 분명하다. 금융 전산장애의 가장 큰 원인이 프로그램 오류 이고, 그것은 대부분 시험과 변경 통제가 막아야 할 영역이다. 증권사 주문 접수 장애 한 건이 수십억 원 피해로 이어진 사례도 있다.
규제의 층 — 법·규정·시행세칙·가이드
| 층 | 예 | 성격 | QA가 보는 방식 |
|---|---|---|---|
| 법률 | 전자금융거래법, 신용정보법 | 의무와 책임의 근거 | 사고 시 책임 구조 |
| 행정규칙(규정) | 전자금융감독규정 (금융위원회 고시) | 안전성 확보 의무의 기준 | 통제 요건 |
| 시행세칙 | 전자금융감독규정시행세칙 (금융감독원장) | 규정이 위임한 세부 사항 | 구체 절차 요건 |
| 가이드·해설 | 금융보안원 가이드, 업권 협회 가이드 (예: 금융투자협회 프로그램 통제 가이드라인) | 해석·권고·실무 예시 | 실무 기준 문서의 원천 |
| 내부 규정 | 회사 IT 내부통제 규정 | 위 내용을 조직에 맞게 구체화 | QA 절차서의 상위 문서 |
2025년 2월 5일 시행된 전자금융감독규정 개정은 클라우드 이용 절차 합리화, 망분리 규제 완화 같은 큰 변화를 담았고, 이후 시행세칙 개정으로 금융회사 내부망 SaaS 이용이 확대되는 등 조문이 자주 바뀐다(레슨 5). 그래서 금융 QA의 기준 문서에는 반드시 근거 조문과 판(고시 번호·시행일) 을 적는다.
프로그램 통제 — 개발·시험·운영의 분리
전자금융감독규정 제29조(프로그램 통제)는 금융회사가 프로그램의 등록·변경·폐기 절차를 금융감독원장이 정하는 사항을 포함해 수립·운용하라고 한다. 시행세칙과 해설에서 구체화되는 요지를 QA 절차로 옮기면 다음과 같다.
| 요지 | QA 절차에서의 구현 | 시험·점검 방법 |
|---|---|---|
| 변경이 필요하면 해당 프로그램을 개발·시험 시스템에 복사한 뒤 변경 | 운영 직접 수정 금지, 변경은 저장소의 브랜치·시험 환경에서만 | 운영 반영 이력과 저장소 커밋 대조 — 저장소에 없는 운영 변경 0 |
| 프로그램 접근은 업무 담당자로 제한 | 저장소·배포 도구 권한 관리 | 권한 목록 정기 검토 기록 |
| 처리 정보의 기밀성·무결성·가용성을 고려해 충분한 시험 후 책임자 승인 을 받아 운영 반영 | 시험 완료 기준, 배포 승인 게이트 (모듈 38 레슨 5) | 배포 건별 시험 결과·승인자·승인 시각 추적 |
| 프로그램 반출·실행 프로그램 생성·운영 등록은 해당 프로그램 담당자가 아닌 사람 (전산자원 관리자 등)이 수행 | 개발자는 운영 배포 권한 없음, 배포는 파이프라인 또는 별도 담당 | 배포 실행자 ≠ 커밋 작성자 점검 |
| 변경 전후 내용 기록·관리 | 변경 이력, 배포 기록 보존 | 임의 배포 건의 변경 전후 비교 가능성 |
| 등록·변경·폐기의 적정성에 대한 제3자 검증 | 코드 리뷰·QA 검증·변경 승인 위원회 | 검증자 ≠ 작성자 |
이 조항은 모듈 37 레슨 3의 변경 지원, 모듈 35 레슨 3의 역할 독립성과 같은 발상이다. 차이는 법적 의무 라는 점이다. 금융감독원 검사에서 "개발자가 운영 서버에 직접 배포한 기록"이 나오면 개별 결함이 아니라 통제 미비로 지적된다.
DevOps·GitOps(모듈 39 레슨 4) 환경에서도 이 요건은 충족할 수 있다. 오히려 증거를 남기기 쉽다.
[프로그램 통제 요건 ↔ 파이프라인 구현]
개발·시험 분리 개발·시험 클러스터와 운영 클러스터 분리, 운영 네임스페이스 쓰기 권한은 배포 에이전트만
충분한 시험 후 승인 PR 검증·회귀·릴리스 전 검증 통과 + 변경 승인 기록 (필수 승인자: 서비스 책임자)
담당자 외 운영 등록 운영 배포는 GitOps 에이전트가 수행, 배포 저장소 병합 권한은 개발자에게 없음
변경 전후 기록 배포 저장소 커밋 이력 = 변경 전후 매니페스트, 이미지 다이제스트
제3자 검증 배포 저장소 PR 에 QA·운영 승인 필수 (CODEOWNERS)QA가 챙길 한 가지는 긴급 변경 이다. 장애 대응 중 긴급 패치는 절차를 줄이게 되는데, 규정은 긴급이라고 통제를 면제하지 않는다. 긴급 변경의 사후 시험·사후 승인 절차와 기한을 정하고, 그것이 실제로 이행됐는지 주기 점검한다.
전산원장 통제와 거래 통제
전산원장 은 고객 계좌·잔액·거래 내역처럼 금융거래의 기준이 되는 데이터다. 제27조(전산원장 통제)는 장애·오류 등으로 전산원장을 변경해야 할 때의 별도 통제 절차 — 변경 권한자 지정, 변경 전후 자동 기록 등 — 를 요구하고, 제28조(거래통제 등)는 사고 위험도가 높은 거래를 책임자 승인 거래 로 처리하고 전산원장·주요 정보 등 중요 작업 시 책임자 이중 확인 을 요구한다.
QA 관점에서 이 조항들은 두 종류의 시험 대상을 만든다.
| 대상 | 시험 |
|---|---|
| 원장 보정 기능 (운영자 도구) | 권한 없는 사용자의 보정 불가, 보정 전후 값 자동 기록, 보정 사유 필수, 이중 확인 없이 반영 불가, 기록 수정·삭제 불가 |
| 책임자 승인 거래 | 승인 대상 거래 조건(금액·유형) 경계값, 승인 전 거래 미반영, 승인 거절 시 원상, 요청자와 승인자 동일인 불가 |
원장 보정 기능은 자주 쓰이지 않아서 시험도 자주 빠진다. 그런데 장애가 났을 때 가장 급하게 쓰이는 기능이고, 여기서 결함이 나면 장애 위에 원장 오류가 겹친다. 레슨 2의 원장 불변식 시험과 함께 회귀 세트에 넣는다.
비상대책 — 훈련을 시험으로 다룬다
제23조(비상대책 등)는 비상대책 수립과 연 1회 이상 비상대응훈련 을 요구하고, 지정된 금융회사에는 주전산센터와 일정 거리 이상 떨어진 재해복구센터 구축과 매년 1회 이상 재해복구전환훈련 을 요구한다.
훈련은 흔히 "올해도 했다"는 보고서로 끝난다. 모듈 39 레슨 7의 장애 주입 관점으로 보면 재해복구전환훈련은 정상 상태 가설이 있는 시험 이어야 한다.
[재해복구전환훈련 — 시험 설계]
정상 상태 정의: 핵심 업무(계좌 조회·이체·카드 승인) 성공률, 응답 시간
가설: 주센터 차단 후 목표 복구 시간(RTO) 안에 재해복구센터에서 핵심 업무 재개
복구 시점 목표(RPO) 기준으로 원장 데이터 손실 없음
판정: - 전환 소요 시간 측정 (선언 시각 → 첫 정상 거래)
- 원장 정합성: 전환 직전 확정 거래가 재해복구센터 원장에 모두 존재 (레슨 2 대사)
- 대외 연계: 금융결제원·카드사·한국은행 등 대외기관 연결 전환 확인
- 복귀 전환(재해복구센터 → 주센터)까지 수행
기록: 목표 대비 실측, 실패 항목, 개선 조치와 다음 훈련 확인 항목"복귀 전환까지 수행"이 자주 빠진다. 재해복구센터로 넘어가는 것만 훈련하고 돌아오는 것을 훈련하지 않으면, 실제 재해 후 복귀 과정에서 두 번째 장애가 난다. 대외 연계 도 금융 특유의 약점이다. 내부 시스템은 넘어갔는데 대외기관 회선·인증서·접속 IP 등록이 주센터 기준으로만 되어 있으면 핵심 업무가 재개되지 않는다.
취약점 분석·평가 — QA가 기여하는 곳
제37조의2는 총자산 2조 원 이상이고 상시 종업원 300명 이상인 금융회사 등에 연 1회 이상(홈페이지는 6개월에 1회 이상) 전자금융기반시설의 취약점 분석·평가를 실시하고, 결과에 따른 이행계획을 수립·시행하도록 한다. 평가는 정보공유·분석센터, 정보보호 전문 서비스 기업 등 지정된 전문기관이 수행하고, 제거할 수 없는 취약점은 최고경영자 승인 을 받으며, 이행 결과를 보고한다.
취약점 분석·평가 자체는 보안 조직의 일이지만, QA가 기여할 곳이 두 군데 있다.
| 지점 | QA 역할 |
|---|---|
| 조치 확인 | 취약점 조치 후 재시험 과 기능 회귀. 보안 패치가 업무 기능을 깨뜨리지 않았는지 |
| 반복 취약점 예방 | 같은 유형의 취약점(입력 검증·인증 우회·권한)이 매년 나오면 개발 단계 검증 기준 으로 편입 (모듈 38 레슨 2의 에이전트 스킬, 모듈 16 레슨 5~6) |
두 번째가 더 중요하다. 연 1회 평가에서 발견되는 것은 이미 운영에 1년 가까이 있던 취약점이다. 매년 같은 부류가 나온다면 평가가 아니라 개발 프로세스가 원인 이다.
규제 기준 문서를 관리하는 법
금융 QA의 기준 문서는 조문을 그대로 옮기지 않고, 조문 → 통제 → 시험·점검으로 번역해 관리한다. 모듈 34의 "규제가 규격을 부른다" 추적 방식이 금융에서도 쓰인다.
[규제 요건 추적표 — 발췌]
근거 (판) 통제 ID 통제 내용 검증 방법 주기 증거 위치
전자금융감독규정 §29 (2025-4호) PC-03 운영 반영 전 충분한 시험·책임자 승인 배포 건별 게이트 기록 점검 상시 게이트 결정 기록
같은 조 + 시행세칙 PC-05 담당자 외 운영 등록 배포 실행자 ≠ 커밋 작성자 점검 월 점검 보고서
§27 LD-01 원장 보정 전후 자동 기록·권한자 지정 원장 보정 기능 회귀 시험 LD-T-01~12 릴리스 회귀 결과
§23 BC-02 재해복구전환훈련 연 1회 훈련 시험 설계·결과·개선 확인 연 훈련 보고서
§37의2 VA-01 취약점 조치 확인 재시험 조치 건별 재시험·회귀 조치 시 재시험 기록규정이 개정되면 근거 열로 영향받는 통제를 찾는다. 이 표가 없으면 개정 때마다 전체 절차서를 다시 읽어야 한다.
실무에서 왜 필요한가
금융권 QA·테스트 조직은 검사와 감사를 정기적으로 받는다. 검사에서 지적되는 것은 대개 "시험을 안 했다"가 아니라 "시험했다는 증거와 승인의 연결이 없다", "통제가 규정대로 운영되지 않았다" 다. 규정 조문을 절차와 증거로 번역해 둔 QA 조직은 검사 대응이 자료 조회로 끝나고, 그렇지 않은 조직은 검사 기간마다 몇 주씩 자료를 만든다.
금융 차세대·클라우드 전환 프로젝트가 늘면서(레슨 3·5) 이 번역 능력의 수요가 커졌다. 특히 DevOps·GitOps를 도입하려는 금융회사에서 "파이프라인으로도 프로그램 통제 요건을 충족할 수 있다"를 증거 구조로 보여줄 수 있는 QA 는 도입의 핵심 조력자가 된다. 진입장벽이 높고 가이드라인이 엄격해 시니어의 도메인 지식이 높게 평가되는 대표적인 분야다.