3개월 병행검증에서 어떤 기능은 세 번밖에 검증되지 않습니다

우리 회사에서 차세대 구축의 마지막 관문은 보통 3개월짜리 병행검증입니다. 그 3개월 동안 매일 도는 처리는 아흔 번쯤 검증되고, 월 단위로 도는 처리는 세 번 검증됩니다. 마지막에는 둘 다 똑같이 “병행검증 완료”로 기록됩니다.

이 글은 그 차이를 조금이라도 줄일 방법이 없을까 하는 이야기입니다.

---

들어가며: 차세대 구축이라는 판

금융권을 비롯한 여러 산업에는 20~30년 된 시스템이 아직 돌아갑니다. C나 코볼로 짜인 것들이고, 지금도 매일 정상적으로 동작합니다. 문제는 다른 데 있습니다. 그 코드를 이해하는 사람이 은퇴하고, 기술 지원이 끊기고, 새로운 요구사항을 얹기가 점점 어려워집니다. 그래서 회사는 이 시스템 전체를 지금의 기술 스택으로 다시 만드는 대형 프로젝트를 시작합니다. 흔히 ‘차세대 시스템 구축’, 줄여서 차세대라고 부릅니다.

저는 그런 조직에서 일합니다. 금융권이고, 20년 넘은 C 프로그램들을 Java와 최신 프레임워크로 다시 만들어 컨테이너 환경 위에서 돌리는 전담 조직입니다.

규모나 기간은 회사마다 다르지만, 제가 겪어 보니 세 가지 공통점이 있습니다.

첫째, 목표가 “지금과 똑같이 동작하는 것”입니다. 사용자에게 새로 생기는 가치가 없습니다. 그래서 프로젝트의 성패는 새 기능이 아니라 **“기존과 결과가 같음을 증명했는가”**로 갈립니다. 이 점이 일반적인 신규 개발과 결정적으로 다릅니다.

둘째, 데드라인이 먼저 정해져 있는 경우가 많습니다. 적어도 국내에서는 그렇습니다. 개별 업무를 분석하기도 전에 오픈 일정이 정해지고, 그 일정은 잘 바뀌지 않습니다. 분석하기 전에 정한 일정을 분석한 뒤에도 지켜야 하는 상황이 자주 생깁니다.

셋째, 명세가 반쪽만 있습니다. 문서가 아예 없다는 뜻은 아닙니다. 회사마다 다르고, 저희만 해도 파일 레이아웃이나 필드 정의 같은 인터페이스 설계서는 있습니다. 외부 기관과 주고받는 규격이니 없을 수가 없죠.

없는 것은 비즈니스 로직 쪽 명세입니다. “이 코드값이면 수수료를 어떻게 계산하는가”, “이 조건에서는 왜 건너뛰는가” — 이런 것은 결국 20년 된 코드 안에만 있습니다. 문서가 있어도 여러 번의 개정을 거치며 현행과 벌어져 있는 경우가 많습니다.

이 차이가 뒤에서 이야기할 검증 문제로 그대로 이어집니다.

규격이 있으니 입력은 만들 수 있습니다. 그런데 로직 명세가 없으니 정답은 정하기 어렵습니다.

---

먼저 깔고 가야 할 제약이 있습니다

본론에 들어가기 전에 몇 가지 제약을 설명해야 합니다. 이걸 빼면 뒤의 이야기가 “그냥 테스트를 더 하면 되는 것 아닌가?”로 읽힐 수 있습니다.

1. 운영 환경과 개발·테스트 환경이 분리되어 있습니다. 당연한 이야기 같지만, 이 분리가 얼마나 엄격한지가 중요합니다. 두 환경은 물리적으로도 망 구성으로도 떨어져 있고, 사이를 오가는 모든 것이 통제됩니다.

2. 테스트 환경에서 실제 이용자 정보를 쓸 수 없습니다. 전자금융감독규정 제13조 제1항 제10호는 “이용자 정보의 조회·출력에 대한 통제를 하고 테스트 시 이용자 정보 사용 금지”를 규정합니다. 부하 테스트처럼 불가피한 경우에만 정보를 변환해서 쓰고 테스트 종료 즉시 삭제해야 합니다. 그리고 그 변환 작업의 공수가 만만치 않습니다.

개인정보·금융정보를 다루는 회사라면 비슷한 제약이 있습니다. 운영 데이터를 테스트 서버로 내려받아 그대로 쓰는 것은 대부분 허용되지 않습니다.

3. 운영 환경에 프로그램을 반영하려면 시험 완료 확인과 승인을 거쳐야 합니다. 금융권의 프로그램 통제 기준은 운영 반영 전에 테스트와 승인 절차를 거치고, 그 수행 여부를 개발자와 분리된 책임자가 확인하도록 요구합니다. 실무에서는 보통 “완성되지 않은 프로그램은 운영 서버에 올릴 수 없다”로 받아들여집니다.

4. 일정을 바꾸기 어렵습니다. 앞서 말한 대로 오픈 일정이 분석 이전에 정해진 경우가 많습니다. 일정이 고정이고 범위도 고정되어 있다면, 일정이 밀릴 때 결국 줄이게 되는 것은 검증입니다.

---

그래서 병행검증을 합니다

이런 조건에서 “기존과 결과가 같음”을 어떻게 증명할까요? 저희 회사의 공정은 대략 이렇습니다.

기존 업무 분석 및 설계 → 개발 및 테스트 → 통합테스트·성능테스트 → 병행검증(3개월) → 본격 실시

신구 시스템의 결과가 같은지를 실제로 확인하는 단계가 병행검증입니다. 운영 서버 안의 분리된 환경에 차세대 프로그램을 올려 두고, 레거시로 들어오는 실제 입력을 차세대에도 똑같이 흘려 넣습니다. 그리고 양쪽이 만든 산출물과 DB에 남긴 값을 항목별로 대사합니다.

배치라면 수신 파일을 양쪽에 넣고 생성된 결과 파일과 테이블 값을 비교합니다. 온라인이라면 실제 요청을 복제해 차세대에도 보내고 응답 전문과 DB 변경을 비교합니다. 형태는 달라도 원리는 같습니다.

병행검증이 좋은 이유

소프트웨어 테스트에서 어려운 일 중 하나는 “이 입력에 대해 결과가 어떻게 나와야 하는가”를 정하는 것입니다. 차세대 구축에서는 이게 특히 어렵습니다. 앞에서 말한 명세의 비대칭 때문입니다.

입력을 만드는 데 필요한 규격은 있는데, 기대값을 정하는 데 필요한 로직 명세는 없습니다. 기대값을 만들려면 결국 20년 된 코드를 읽어야 하고, 그 해석이 틀리면 테스트도 틀립니다. 잘못된 기대값으로 테스트를 통과시켜 놓고 검증했다고 믿는 것은 재구축에서 꽤 위험한 실패입니다.

병행검증에서는 사람이 기대값을 새로 정의하는 대신, 현재 운영 중인 레거시의 실제 결과를 비교 기준으로 삼을 수 있습니다.

레거시가 항상 옳다는 뜻은 아닙니다. 하지만 재구축의 목표가 현행과 같은 동작을 만드는 것이라면, 현행 시스템의 결과는 등가성을 확인하는 데 가장 현실적인 기준입니다. 사람이 기대값을 일일이 만들 필요가 없고, 그 과정에서 생기는 해석 오류도 줄어듭니다. 테스트 데이터를 별도로 만드는 부담도 적습니다.

그래서 병행검증은 꽤 강력한 수단입니다.

---

그런데 왜 맨 뒤에 있는가

그렇게 좋은 수단이면 개발하는 동안 계속 쓰면 좋겠습니다. 하지만 앞에서 말한 제약 때문에 어렵습니다.

1. 테스트 환경에서 실제 이용자 정보를 쓸 수 없다.
2. 실제 데이터로 검증하려면 결국 실제 입력이 들어오는 환경이 필요하다.
3. 운영 환경에 프로그램을 반영하려면 시험 완료 확인과 승인을 거쳐야 한다.
4. 그래서 프로그램이 어느 정도 완성되고 테스트가 끝난 뒤에야 병행검증을 시작할 수 있다.

하나씩 보면 이상한 규칙이 없습니다. 고객 정보를 테스트 서버에 가져가지 않는 것도 맞고, 검증되지 않은 프로그램을 운영에 올리지 않는 것도 맞습니다.

그런데 이 규칙들을 그대로 적용하면 가장 좋은 검증을 가장 늦게 시작하게 됩니다. 누가 잘못해서 이렇게 된 건 아닙니다. 공정 자체가 그렇게 되어 있습니다.

---

그래서 생기는 세 가지 문제

첫째, 검증 범위를 우리가 정하지 못합니다

병행검증은 실제로 들어온 데이터를 그대로 흘려보냅니다. 그래서 자주 발생하는 케이스는 확실히 잡습니다.

그런데 3개월 동안 해당 조건이 한 번도 들어오지 않았다면, 그 조건을 타는 코드는 병행검증에서 한 번도 실행되지 않습니다. 검증을 통과한 게 아니라 검증할 기회 자체가 없었던 겁니다.

재구축에서 빠뜨리기 쉬운 것도 이런 부분입니다. 코드의 메인 흐름은 여러 번 보지만, 구석에 있는 예외 처리 한 줄은 놓치기 쉽습니다. 규격에 코드값이 열 개 정의되어 있는데 실제로는 두세 개만 들어온다면, 나머지 일곱 개를 제대로 구현했는지는 병행검증만으로 알 수 없습니다.

병행검증에서 어떤 케이스를 만나게 될지는 우리가 정할 수 없습니다.

둘째, 발생 빈도에 따라 검증 횟수가 크게 달라집니다

3개월 병행검증에서 실제 실행 횟수를 세어 보면 이렇습니다.

배치라면 월마감·수수료 정산 같은 것들이고, 온라인이라면 드물게 호출되는 API나 특정 시기에만 오는 전문이 여기에 해당합니다.

마지막에는 모두 “병행검증 완료”라고 기록됩니다. 하지만 한두 번 맞았다는 것과 아흔 번 맞았다는 것은 같은 수준의 검증이라고 보기 어렵습니다.

더구나 저빈도 처리 중에는 로직이 복잡하거나 금액·정산·대외보고처럼 한 번의 오류가 큰 영향을 만드는 업무도 있습니다. 적게 발생한다고 덜 중요한 것은 아닌데, 실제 데이터만 기다리고 있으면 이런 처리는 자연스럽게 검증 횟수가 적어집니다.

셋째, 결함이 고칠 시간 없을 때 나옵니다

병행검증은 공정상 본격 실시 직전입니다. 여기서 불일치가 발견되면 고칠 시간이 많지 않습니다.

그리고 저희가 직전에 오픈한 업무에서 병행검증 중 발견된 불일치의 원인은 대부분 비즈니스 로직 일부 누락이었습니다. 구조 자체가 잘못된 경우는 많지 않았습니다. 레거시 코드에는 있는데 새 코드로 옮기지 않은 분기가 대부분이었습니다.

누락은 찾기가 어렵습니다. 있는 코드가 잘못된 것은 테스트해서 찾을 수 있지만, 없는 코드는 무엇이 빠졌는지를 알아야 찾을 수 있습니다. 그런데 그 “있어야 할 것의 목록” 역할을 해 줄 로직 명세가 없습니다. 인터페이스 설계서는 어떤 필드가 들어오는지는 알려 주지만, 그 필드로 무엇을 해야 하는지는 알려 주지 않습니다.

그래서 이런 문제는 병행검증까지 살아남기 쉽고, 결국 일정 압박이 가장 심할 때 발견됩니다.

---

문제는 이관 단위와 검증 단위가 다르다는 데 있습니다

이관은 프로그램 단위로 합니다. 프로그램 하나를 운영에 적용하는 것이 한 번의 이관이고, 승인도 보통 이 단위로 이뤄집니다.

그런데 실제 테스트는 그보다 작은 단위로 합니다. 저희 프로그램 하나에는 실행 단위가 적게는 10개, 많게는 20~30개 들어 있습니다. 통합테스트도 성능테스트도 각각의 실행 단위를 기준으로 진행합니다. 온라인이라면 서비스 하나 안에 있는 개별 거래코드나 전문도 비슷할 겁니다.

프로그램은 하나지만 그 안의 검증 상태는 전부 다를 수 있습니다.

그리고 현실에서는 이미 그런 일이 생깁니다. 원칙대로라면 모든 단위의 통합테스트가 끝난 뒤 병행검증에 들어가야 합니다. 하지만 일정이 부족하면 중요한 것부터 통합테스트와 성능테스트를 하고, 나머지 단위는 테스트를 다 끝내지 못한 상태에서 병행검증 기간에 들어가는 경우가 있습니다.

결국 같은 프로그램 안에서도 어떤 단위는 병행검증을 처음부터 하고, 어떤 단위는 한두 달 늦게 합류합니다.

“검증이 끝난 것만 운영에 올린다”는 원칙에도 현실에서는 이미 예외가 생기고 있습니다.

이걸 비판하려는 건 아닙니다. 오히려 이 현실적인 타협을 처음부터 일정과 절차에 반영할 수 있지 않을까 생각했습니다.

---

검증이 끝난 단위부터 먼저 넣으면 어떨까

지금은 통합테스트가 늦어진 단위가 뒤늦게 병행검증에 합류합니다. 반대로 해 볼 수 있습니다. 개발과 테스트가 끝난 단위부터 먼저 병행검증에 투입하는 겁니다.

둘 다 프로그램 안의 실행 단위가 서로 다른 시점에 병행검증에 들어간다는 점은 같습니다. 다른 건 늦어진 결과로 그렇게 되느냐, 처음부터 그렇게 계획하느냐입니다.

먼저 끝난 단위는 3개월이 아니라 46개월 동안 검증할 수 있습니다. 월 단위 처리는 3번이 아니라 56번 돌릴 수 있고, 결함도 마지막에 몰리지 않고 조금 더 일찍 발견할 수 있습니다.

여기서 걸리는 건 ‘미완성 프로그램’이라는 점입니다

관리자 입장에서 “아직 개발이 다 안 된 프로그램을 운영 환경에 올린다”고 하면 당연히 불안합니다. 그래서 실행 여부를 기준으로 다시 볼 필요가 있습니다.

지금 허용되고 있는 것은 위쪽이고, 막혀 있는 것은 아래쪽입니다. 그런데 실행 여부만 놓고 보면 순서가 뒤집혀 있는 것처럼 보입니다.

실행 경로에서 확실하게 빠져 있는 미개발 단위는 어떤 입력도 처리하지 않습니다. 반면 테스트가 끝나지 않았지만 활성화되어 있는 단위는 실제 입력을 처리합니다. 물론 두 번째가 안전하려면 정말로 실행되지 않는다는 보장이 있어야 합니다.

그 보장만 만들 수 있다면, “미완성 프로그램”이라는 이름 때문에 더 안전한 쪽을 막고 있는 셈은 아닌지 한 번쯤 따져볼 만합니다.

이 방식이 되려면 두 가지가 필요합니다

1. 미개발 단위가 실행되지 않는다는 것을 시스템적으로 보장해야 합니다.

배치라면 Job이 스케줄에 등록되지 않으면 실행되지 않고, 온라인이라면 라우팅이 열리지 않으면 호출되지 않습니다. 다만 “아마 실행되지 않을 것”으로는 부족합니다. 어떤 단위가 활성화되어 있고 어떤 단위가 비활성화되어 있는지 명시적으로 관리하고, 필요한 경우 그 상태를 확인할 수 있어야 합니다.

2. 병행검증 환경이 레거시에 영향을 주지 않아야 합니다.

이건 원래도 병행검증의 전제지만, 더 일찍 프로그램을 올리려면 더 중요해집니다.

• 외부 기관 통신은 애플리케이션 설정이 아니라 네트워크 수준에서 차단
• 레거시 DB는 계정 권한 자체를 읽기 전용으로
• 산출물 경로는 레거시와 물리적으로 분리
• 알림·메일·문자는 전부 차단하거나 별도 채널로
• 레거시와 공유하는 채번 시퀀스를 소비하지 않도록 주의

마지막 항목 같은 것은 특히 조심해야 합니다. 바로 장애가 나지 않고 나중에 감사나 정산 과정에서 드러날 수도 있기 때문입니다.

차세대 쪽에서 무슨 문제가 생겨도 현재 운영 중인 레거시에는 영향이 없어야 합니다.

일찍 넣으면 무엇이 달라질까

병행검증은 실제로 들어오는 데이터를 그대로 사용합니다. 그래서 발생 빈도가 높은 흐름은 검증 기간이 늘어날수록 비교 횟수도 많이 늘어납니다. 하루에 수만 건이 흐르는 처리가 잘못되면 많은 거래가 영향을 받을 수 있는데, 이런 흐름은 기간을 늘렸을 때 추가로 얻는 검증 횟수도 큽니다.

물론 발생 빈도가 곧 중요도라는 뜻은 아닙니다. 1년에 한 번 실행되더라도 큰 금액을 다루거나 규제·정산과 연결된 처리는 훨씬 중요할 수 있습니다. 이런 저빈도 케이스는 실제 데이터가 나타나기를 기다리는 방식만으로는 부족하고, 통합테스트에서 별도로 다뤄야 합니다.

병행검증 기간이 길어졌을 때 얻는 것은 횟수뿐만이 아닙니다.

• 월초와 월말, 분기말, 연휴 앞뒤, 영업일과 비영업일처럼 서로 다른 시기를 더 많이 지나갑니다.
• 3개월 동안 없었던 값이 4개월째 들어오는 식으로 드문 입력을 만날 가능성도 높아집니다.
• 불일치를 발견하고 고친 뒤 다시 실제 데이터로 확인할 시간이 늘어납니다.

제가 병행검증을 일찍 시작해 보고 싶은 가장 큰 이유는 마지막 항목입니다. 결함을 오픈 직전에 찾는 것보다, 고칠 시간이 있을 때 찾는 편이 낫습니다.

물론 공짜는 아닙니다. 병행검증을 앞당기려면 통합테스트와 환경 준비도 앞당겨야 하고, 그 일을 할 사람은 지금 다음 업무를 개발하고 있습니다. 달력에 시간이 있다는 것과 사람에게 시간이 있다는 것은 다릅니다.

병행검증에서 나오지 않는 건 통합테스트로 만들어야 합니다

검증 기간을 아무리 늘려도 끝까지 나타나지 않는 케이스는 있습니다. 규격에는 정의되어 있지만 실제로는 몇 년에 한 번 들어오는 코드값이나, 특정 조건이 겹쳐야만 타는 예외 분기가 그렇습니다.

이런 건 병행검증 기간을 조금 늘리는 것으로 해결되지 않습니다. 3번 실행되던 것을 5번 실행해 봐야, 그 다섯 번에 필요한 조건이 한 번도 없으면 결과는 같습니다.

그래서 병행검증과 통합테스트가 맡는 영역은 다릅니다.

통합테스트에 어떤 데이터를 만들지도 이 기준으로 생각할 수 있습니다. 정상 흐름은 병행검증에서 실제 데이터로 훨씬 많이 확인합니다. 그렇다면 사람이 공들여 만들어야 할 것은 병행검증에서 만나기 어려운 입력입니다. 규격에 정의된 코드값 전체, 금액과 날짜의 경계, 특정 조건의 조합, 그리고 C와 Java가 값을 다르게 다룰 수 있는 부분 같은 것들입니다.

앞에서 말한 로직 누락도 이런 구석에서 나오기 쉽습니다.

그래서 일정이 밀렸다고 통합테스트를 일괄적으로 줄이는 것은 위험합니다. 병행검증과 겹치는 정상 흐름을 줄이는 것과, 병행검증으로 확인할 수 없는 케이스를 줄이는 것은 전혀 다른 이야기입니다.

---

이건 규제 문제일까, 회사 기준의 문제일까

이 부분은 저도 처음 생각했을 때와 결론이 달라졌습니다. 처음에는 “이렇게 하려면 규제를 바꿔야 하는 것 아닌가”라고 생각했는데, 관련 기준을 찾아보니 적어도 제가 확인한 범위에서는 조금 달랐습니다.

규제에서 요구하는 것은 분명합니다.

• 테스트 환경에서 실제 이용자 정보를 사용할 수 없다.
• 운영 환경에 반영하기 전에 시험과 승인 절차를 거쳐야 한다.
• 그 수행 여부를 개발자와 분리된 책임자가 확인해야 한다.

반면 금융권의 프로그램 통제 기준을 보면 관련 기준과 절차, 승인 책임자의 범위 등을 내규로 정하도록 되어 있습니다. 그래서 제가 궁금해진 것은 이것입니다.

지금 프로그램 하나로 보고 있는 이관 단위를, 실제 검증 단위에 맞게 더 작게 나눌 수 있을까?

그리고 그렇게 나눈 단위별로 시험 완료 기준과 승인 절차를 만들 수 있을까. 제가 찾아본 기준에서는 프로그램 전체의 개발이 끝난 뒤에만 병행검증을 시작해야 한다는 요구까지는 확인하지 못했습니다.

그렇다고 검증 단위별 적용이 바로 가능하다는 뜻도 아닙니다. 업권별 규정도 다르고 회사 내규도 다릅니다. 결국 감사나 내부통제 부서와 확인해야 합니다.

제가 여기서 말하고 싶은 것은 “규제 때문에 안 된다”와 “우리 회사 절차상 안 된다”는 구분할 필요가 있다는 것입니다. 저도 처음에는 둘을 같은 것으로 생각했습니다.

물론 실제로 단위를 잘게 나누면 다른 문제가 생깁니다. 승인을 더 자주 받아야 할 수 있습니다. 승인 책임자가 매번 붙어야 한다면 관리 부담이 늘어납니다. 같은 성격의 단위를 묶어서 승인할 수 있는지 같은 방식도 같이 고민해야 합니다.

또 같은 프로그램을 여러 번 운영 환경에 반영하는 것처럼 보일 수 있습니다. 다만 병행검증 중 불일치가 발견되면 같은 프로그램을 수정해서 다시 올리는 일은 지금도 발생합니다. 순차 적용을 하면 그 횟수가 더 늘어날 수 있다는 문제에 가깝습니다.

이 부분은 기술만으로 결정할 수 있는 문제가 아닙니다.

---

그래도 남는 문제

병행검증은 결국 실제 데이터가 보여 주는 것까지만 볼 수 있습니다. 끝내 나타나지 않는 케이스는 기간을 늘려도 확인할 수 없습니다. 그 부분은 통합테스트가 채워야 하는데, 통합테스트에서는 사람이 기대값을 정해야 합니다. 비용이 많이 드는 이유도 여기 있습니다. 이 비용까지 없앨 수 있는 방법은 아닙니다.

그리고 하나 더 밝혀 둘 것이 있습니다. 이 글에서 제안한 방식은 아직 저희가 실행해 본 것이 아닙니다. 지금 진행 중인 업무는 이미 정해진 일정대로 흘러가고 있어서, 이건 다음 업무를 앞두고 정리해 본 생각에 가깝습니다. 그러니 “이렇게 하면 됩니다”가 아니라 **“이렇게 해 보려고 합니다”**로 읽어 주시면 좋겠습니다.

---

마무리

병행검증은 재구축에서 매우 유용한 검증 방법입니다. 사람이 기대값을 하나하나 새로 만들지 않아도 되고, 실제 운영에서 들어오는 입력으로 현행 시스템과 직접 비교할 수 있기 때문입니다.

그런데 우리는 프로그램 전체가 준비될 때까지 기다렸다가 마지막 3개월에 이 검증을 몰아서 합니다. 그러면 매일 도는 처리는 아흔 번 확인하지만, 월 단위 처리는 세 번밖에 확인하지 못합니다.

지금의 3개월이라는 기간 자체를 늘리기는 어려울 수도 있습니다. 하지만 준비된 단위부터 먼저 시작하는 것은 검토해 볼 수 있습니다. 그러면 자주 발생하는 흐름을 더 오래 확인할 수 있고, 여러 달력 조건을 지나볼 수 있고, 무엇보다 불일치를 발견한 뒤 수정해서 다시 확인할 시간이 생깁니다.

병행검증에서 잘 나오지 않는 저빈도·예외 케이스는 통합테스트에서 의도적으로 만들어 확인하면 됩니다.

그리고 사실 프로그램 안의 단위들이 서로 다른 시점에 병행검증에 들어가는 일은 이미 벌어지고 있습니다. 지금은 일정이 늦어진 결과로 그렇게 됩니다. 그렇다면 다음에는 반대로, 준비된 것부터 먼저 넣는 방식으로 설계해 볼 수 있지 않을까 생각합니다.

지금 우연히 생기고 있는 예외를, 다음에는 처음부터 계획에 넣어 보자는 이야기입니다.

---

참고: 전자금융감독규정 제13조 제1항 제10호 / 금융권 프로그램 통제 관련 기준. 업권과 회사에 따라 적용되는 세부 기준이 다를 수 있으며, 실제 적용 가능 여부는 각 조직의 내규와 감사·내부통제 기준을 함께 확인해야 합니다.