개념
제약이 먼저 있고 시험 계획이 나중이다
일반적인 제품 조직에서는 시험 계획을 세우고 그에 맞는 환경을 만든다. 공공·대기업 내부망 환경에서는 순서가 반대다. 환경이 먼저 주어지고, 그 안에서 가능한 시험 계획을 만든다. 클라우드 계정을 못 만들고, 외부 SaaS 를 못 붙이고, 운영 데이터를 반출하지 못하고, 인터넷에서 도구를 내려받지 못하는 상태가 출발점이다.
이 상황에서 QA 가 할 수 있는 최악의 대응은 두 가지다. 하나는 "환경 때문에 못 한다"로 끝내는 것이고, 다른 하나는 제약을 무시한 계획서를 써서 착수 후에 전부 수정하는 것 이다. 필요한 것은 착수 시점에 제약을 목록으로 만들고, 각 제약에 대해 대안 또는 감수 결정을 붙이는 일 이다. 이 레슨은 그 목록을 만드는 방법이다.
망분리의 형태와 최근 변화
망분리는 업무망과 인터넷망을 분리해 외부 위협의 내부 유입을 막는 통제다. 크게 두 형태로 나뉜다.
| 형태 | 구성 | 시험 환경에 미치는 영향 |
|---|---|---|
| 물리적 망분리 | 업무용·인터넷용 PC 와 회선을 따로 둔다 | 시험 수행자가 자리에서 두 대를 오간다. 자료 이동은 망연계 장비를 거친다 |
| 논리적 망분리 | 가상화로 한 단말에서 두 환경을 쓴다(서버 기반·클라이언트 기반) | 성능·입출력 제약이 시험 도구 실행에 영향을 준다 |
국내 공공 부문에서는 이 통제의 틀이 바뀌는 중이다. 국가정보원이 데이터 중요도에 따라 보안 통제를 차등 적용하는 「국가 망 보안체계(N²SF)」 로의 전환을 추진 하고 있고, 데이터를 기밀(C)·민감(S)·공개(O) 로 분류해 등급별로 다른 통제를 적용하는 방식이다. 2025년에 가이드라인이 공개됐고, KISA 가 과학기술정보통신부와 함께 2026년 도입 지원사업 을 추진하는 등 실제 적용이 진행되고 있다.
이 전환의 시행 시점, 기존 망분리 조항의 폐지 여부, 기관별 적용 의무의 범위는 2차 보도로만 확인되므로 이 레슨은 조문·시행일을 쓰지 않는다 — 원문 확인 대상이다. 사업에 적용할 때는 국가정보원과 KISA 가 공개한 가이드라인 원문, 그리고 해당 기관의 보안 담당 부서가 적용 중인 현행 기준 을 직접 확인한다. 기관마다 적용 시점이 다르다.
QA 에게 이 변화의 의미는 실용적이다. "우리 시험 환경이 어느 등급의 데이터를 다루는가"가 통제 수준을 결정하는 질문이 된다. 종전처럼 "내부망이니 무조건 막힘"이 아니라, 등급에 따라 허용 범위가 달라질 수 있다. 그래서 착수 시점의 질문이 바뀐다 — "인터넷이 되나요"가 아니라 "우리가 다루는 데이터는 어느 등급이고, 그 등급에서 무엇이 허용되나요" 다.
금융권의 망분리 규제와 클라우드 이용 절차는 성격이 다르고 레슨 s2-m41-l05 가 따로 다룬다. 이 레슨은 공공·기업 내부망 일반을 대상으로 한다.
외부가 끊기면 드러나는 것들
내부망 시험의 가장 큰 가치는 운영과 같은 단절 조건에서 시스템을 돌려 본다는 것 이다. 개발자 PC 에서는 인터넷이 되므로, 외부 의존이 있는 줄도 모르고 넘어간 코드가 많다. 내부망에 올리면 그것이 한꺼번에 드러난다. 점검 목록으로 고정해 둔다.
[정적 자원] 외부 CDN 의 스크립트·스타일·글꼴 — 차단되면 화면이 깨지거나 기능이 죽는다
폴백이 있는가, 아니면 전부 내부에 두었는가
[글꼴] 웹 글꼴 로딩 실패 시 대체 글꼴로 레이아웃이 어긋나는가
[지도·외부 API] 지도, 주소 검색, 공휴일 조회, 환율 — 내부망 대체 수단이 있는가
[인증서 검증] OCSP·CRL 조회가 외부로 나가면 차단돼 응답이 지연되거나 실패한다 (타임아웃 확인)
[시각 동기] 외부 NTP 차단 시 내부 시각 서버를 쓰는가. 서버 간 시각 차이는 얼마인가
[업데이트] OS·라이브러리·백신 패턴·브라우저의 갱신 경로 — 내부 저장소가 있는가
[텔레메트리] 제품·라이브러리가 외부로 보내는 통계·오류 보고가 지연을 만드는가
[메일·알림] 외부 메일 발송 경로, 문자·푸시 중계인증서 검증과 텔레메트리가 특히 은밀하다. 둘 다 차단되면 오류가 아니라 지연 으로 나타난다. 화면이 30초 걸리는데 원인이 로그에 없다면 여기를 먼저 본다. 시험 방법은 단순하다. 외부로 나가는 요청을 잡아 목록으로 만들고(네트워크 캡처 또는 프록시 로그), 그 목록의 각 항목이 차단됐을 때 무슨 일이 일어나는지 확인한다. 이 목록을 만드는 작업 자체가 산출물 이고, 검수와 운영 이관에서 그대로 쓰인다.
시험 환경 구성 — 무엇을 어디에 두는가
내부망 시험 환경을 설계할 때 결정해야 하는 것은 네 가지다.
1. 환경 층 수 개발 / 단위시험 / 통합시험 / 성능 / 운영전(스테이징) 중 무엇을 둘 것인가
내부망은 자원이 한정적이라 층을 줄여야 하는 경우가 많다
2. 운영 유사도 서버 대수·이중화·네트워크 구간·보안 장비가 운영과 얼마나 같은가
다른 점을 목록으로 만들고, 각 차이가 어떤 시험을 무효화하는지 적는다
3. 외부 연계 처리 실제 연계 / 시험용 연계 / 모의 서버 중 어느 것을 쓰는가 (연계 기관별로)
4. 도구 반입 시험 도구·라이브러리를 내부망에 어떻게 들여오는가, 승인은 누가 하는가2번의 "차이 목록"이 이 표의 핵심 산출물이다. 시험 환경이 단일 서버인데 운영이 이중화라면, 세션·파일 저장소·캐시 관련 시험 결과는 운영에 그대로 적용되지 않는다(레슨 1). 이 사실을 문서에 적어 두는 것과 적지 않는 것은 검수와 하자 판정에서 결과가 다르다. 차이를 숨기면 나중에 QA 가 책임지고, 적어 두면 조직이 함께 감수한 결정이 된다.
4번은 리드 타임이 길다. 오픈소스 도구 하나를 들여오는 데도 보안성 검토와 반입 승인이 필요한 기관이 많다. 착수 첫 주에 필요한 도구 목록과 각각의 용도·출처·라이선스 를 정리해 신청한다. 이것이 늦으면 시험 설계는 끝났는데 실행할 도구가 없는 상태가 된다.
시험 데이터 — 반입·반출 통제
내부망에서 가장 민감한 주제다. 원칙은 두 방향 모두 통제된다는 것이다.
반입(밖 → 안). 외부에서 만든 시험 데이터·문서·도구를 내부망에 들여오는 경로다. 망연계 장비나 승인된 매체를 거치며, 대개 신청 → 검토 → 승인 → 이동 → 기록 절차가 있다. QA 가 알아 둘 것은 1회 처리량과 소요 시간 이다. 수백 MB 의 시험 데이터를 매일 옮겨야 하는 계획은 성립하지 않는다.
반출(안 → 밖). 더 엄격하다. 시험 결과·로그·화면 캡처를 밖으로 가져가려면 승인이 필요하고, 개인정보나 업무 데이터가 포함된 것은 대개 불가 다. 여기서 실무적으로 중요한 함정이 있다 — 결함 보고서에 붙인 화면 캡처와 로그 다. 습관적으로 캡처를 붙이면 그 안에 실명·주민등록번호·계좌번호가 담긴다. 내부 결함 관리 시스템이 내부망에 있으면 문제가 덜하지만, 외부 SaaS 를 쓰는 사업에서는 사고가 된다. 결함 보고 시 캡처 마스킹 규칙을 착수 시점에 정한다.
운영 데이터를 시험에 쓸 수 없을 때의 대안은 세 갈래다.
| 방식 | 내용 | 한계 |
|---|---|---|
| 비식별·마스킹 사본 | 운영 데이터에서 식별 정보를 치환·삭제 | 절차 승인이 필요하고, 마스킹이 참조 무결성을 깨뜨릴 수 있다 |
| 합성 데이터 생성 | 업무 규칙에 맞는 데이터를 만들어 낸다 | 실제 데이터의 편향·이상값·과거 데이터의 지저분함을 재현하지 못한다 |
| 부분 추출 | 특정 기간·조직만 추출 | 대량 처리·집계 시험에 부족하다 |
실무에서는 섞어 쓴다. 기능 시험은 합성 데이터, 대량·성능 시험은 규모만 맞춘 합성 데이터, 데이터 이행 검증은 비식별 사본 이 흔한 배치다. 어느 쪽이든 QA 가 놓치면 안 되는 것은 참조 무결성과 업무 규칙 만족 이다. 마스킹으로 조직 코드가 깨지거나 합성 데이터의 전표 차대가 맞지 않으면, 그 데이터로 한 시험은 실패 원인을 데이터 탓으로 돌리며 시간을 잃는다. 데이터 세트에도 문서 세트처럼 버전과 생성 절차 기록 을 붙인다.
대량 동시 접속 — 현실의 제약
공공 시스템에는 평소와 완전히 다른 부하가 몰리는 날이 있다. 개학·수강신청, 연말정산, 청약, 원서 접수, 재난지원금 신청 같은 것이다. 이 부하는 평균이 아니라 특정 시각에 집중 된다. 오전 9시 정각에 몇 분간 몰리고 끝나는 형태다.
성능 시험 기법 자체는 성능 모듈이 다룬다. 여기서 다루는 것은 내부망·공공 환경에서 이 시험이 어디까지 가능한가 다. 현실의 제약은 이렇다.
· 부하 발생기를 돌릴 자원이 내부망에 없다 (클라우드 부하 도구를 쓸 수 없다)
· 시험 환경이 운영보다 작다 — 결과를 그대로 외삽할 수 없다
· 외부 연계 기관은 시험 부하를 받아 주지 않는다 (모의 서버로 대체해야 한다)
· 운영 환경 부하 시험은 서비스 중단 시간에만 가능하고, 그 시간은 짧다
· 실제 사용자 행동(로그인 → 조회 → 신청 → 결제)의 비율 자료가 없다그래서 계획은 목표를 낮추는 것이 아니라 질문을 바꾸는 것 으로 시작한다. "운영 규모에서 3만 명 동시 접속을 견디는가"는 답할 수 없는 질문이다. 답할 수 있는 질문은 이렇다.
1. 병목이 어디인가 작은 환경에서도 병목의 위치는 대개 같다 (DB 잠금, 특정 쿼리, 외부 연계)
2. 선형적으로 늘어나는가 부하를 단계적으로 올리며 응답 시간 곡선의 꺾이는 지점을 찾는다
3. 한계에서 어떻게 깨지는가 느려지는가, 오류를 내는가, 데이터가 틀어지는가 — 마지막이 가장 위험하다
4. 보호 장치가 동작하는가 대기열, 접속 제한, 회로 차단, 자동 확장이 설계대로 동작하는가
5. 피크 뒤에 회복하는가 부하가 빠진 뒤 정상 상태로 돌아오는 시간3번이 QA 가 가장 강하게 주장해야 할 항목이다. 과부하에서 느려지는 것은 감수할 수 있지만, 과부하에서 중복 신청이 저장되거나 번호가 중복 채번되면 그것은 성능 문제가 아니라 데이터 무결성 사고다. 피크 부하 시험의 판정 기준에 응답 시간뿐 아니라 데이터 정합성 검증 을 반드시 넣는다.
4번의 대기열도 자주 빠진다. 대기열을 도입해 놓고 대기열 자체의 동작(순번 보장, 새로고침 시 순번 유지, 이탈 처리, 대기열 우회 가능 여부)을 시험하지 않는 경우가 많다. 대기열 우회 가능 여부 는 청약·접수처럼 공정성이 걸린 시스템에서 치명적이다.
실무에서 왜 필요한가
내부망 사업에서 일정이 무너지는 가장 흔한 원인은 개발 지연이 아니라 환경과 데이터와 도구가 제때 준비되지 않는 것 이다. 반입 승인 2주, 시험 데이터 비식별 승인 3주, 연계 기관 시험 일정 조율 4주 같은 리드 타임이 직렬로 쌓이면, 시험 실행 가능 시점이 계획보다 한 달 뒤가 된다. 이 리드 타임을 착수 첫 주에 목록으로 만들어 역산하는 것이 이 레슨에서 가장 실용적인 부분이다.
차이 목록을 문서로 남기는 것도 같은 이유다. 시험 환경과 운영의 차이는 없앨 수 없는 경우가 대부분이고, QA 의 역할은 없애는 것이 아니라 그 차이가 어떤 시험을 무효화하는지 밝히고 대안 또는 감수 결정을 받아 두는 것 이다. 이 기록은 운영 사고가 났을 때 "왜 시험에서 못 잡았는가"에 대한 답이 되고, 하자 판정에서도 근거가 된다(모듈 56 레슨 3).