합성 트랜잭션
더 많은 작업
- Synthetic Transaction; 합성 트랜잭션, 합성 거래, 합성 모니터링(synthetic monitoring)
- 실제 사용자가 아니라 스크립트로 만든 가짜 사용자 거래를 정해진 주기로 시스템에 보내, 가용성·응답 성능·기능이 기대대로 작동하는지를 능동적으로 점검하는 기법
실제 사용자가 불편을 겪고 신고하기 전에 문제를 먼저 알아내려는 것이 목적이다. 예를 들어 5분마다 여러 지역에서 로그인 → 상품 검색 → 장바구니 담기 → 결제 직전 단계까지 진행하는 스크립트를 돌려, 어느 단계에서 실패하거나 느려지는지 기록하고 기준을 넘으면 경보를 낸다. 사용자가 없는 새벽 시간대나 아직 공개하지 않은 서비스도 점검할 수 있다는 점이 강점이다.
클라우드 모니터링 서비스가 대표적인 구현이다. 예를 들어 마이크로소프트의 Application Insights 가용성 테스트(availability test)는 전 세계 여러 지점에서 일정 간격으로 웹 요청을 보내 응답 여부와 응답 시간을 측정하고, 응답이 없거나 느리면 경보를 보낸다. 대상 애플리케이션을 고칠 필요가 없고, 외부에 공개된 HTTP·HTTPS 엔드포인트와 REST API라면 내가 의존하는 외부 서비스도 점검할 수 있다.
CISSP 6.2는 합성 트랜잭션을 벤치마크와 함께 보안 통제 테스트 기법의 하나로 든다. 가용성도 보안 목표이므로, 서비스가 정상 동작하는지 상시 확인하는 것은 보안 통제의 운영 효과성을 확인하는 일이 된다.
| 구분 | 합성 모니터링(synthetic monitoring) | 실제 사용자 모니터링(RUM, Real User Monitoring) |
|---|---|---|
| 방식 | 능동(active). 스크립트가 거래를 만들어 보낸다 | 수동(passive). 실제 사용자의 브라우저·앱에서 측정값을 모은다 |
| 트래픽이 없을 때 | 점검 가능 | 측정할 것이 없다 |
| 문제 발견 시점 | 사용자가 겪기 전에 발견할 수 있다 | 사용자가 이미 겪은 뒤에 보인다 |
| 결과의 일관성 | 같은 경로·같은 조건이라 추세 비교와 기준선 관리에 좋다 | 기기·회선·지역이 제각각이라 편차가 크다 |
| 대표성 | 스크립트로 만든 경로만 본다 | 실제 사용 경로 전체를 본다 |
| 주 용도 | 가용성 경보, SLA 측정, 배포 후 확인, 경쟁 벤치마크 | 실제 체감 성능 분석, 사용 패턴 파악 |
두 방식은 보완 관계이다. 합성 모니터링으로 "지금 서비스가 살아 있는가"를 빠르게 알고, RUM으로 "실제 사용자는 어떤 경험을 하는가"를 본다. APM 도구는 보통 두 기능을 함께 제공한다.
| 종류 | 내용 | 예 |
|---|---|---|
| 단일 요청(가용성 확인) | 한 URL이나 API에 요청을 보내 응답 코드·응답 시간·인증서 유효성을 확인 | 홈페이지 응답, 헬스 체크 엔드포인트 |
| 다단계 거래(트랜잭션 스크립트) | 브라우저 자동화로 여러 화면을 이어서 실행 | 로그인 → 조회 → 이체 확인 화면 |
| API 시나리오 | 여러 API 호출을 순서대로 실행하고 응답 내용을 검증 | 토큰 발급 → 주문 생성 → 주문 조회 → 취소 |
| 데이터베이스·백엔드 거래 | 정해진 질의나 배치 작업을 실행해 결과와 소요 시간을 확인 | 테스트 계정 조회, 대기열 처리 확인 |
| 점검 대상 | 합성 트랜잭션 | 기대 결과 |
|---|---|---|
| 로그인 흐름 | 정상 계정으로 로그인 후 로그아웃 | 성공하고, 세션이 로그아웃 후 무효화된다(세션 관리) |
| 다중 인증 | 1차 인증만 통과한 상태로 보호 페이지 접근 | 거부된다 |
| 계정 잠금 | 틀린 비밀번호를 정해진 횟수 넘게 입력 | 계정이 잠기고 경보가 발생한다 |
| 접근통제 | 일반 사용자 토큰으로 관리자 API 호출 | 접근 거부 응답과 감사 로그가 남는다 |
| 탐지·경보 체계 | 무해한 테스트 문자열(예: 안티바이러스 시험용 파일)이나 미리 정한 의심 행위 재현 | SIEM·보안 관제에 경보가 정해진 시간 안에 도착한다 |
| 인증서·암호 설정 | TLS 연결 시도 | 인증서 만료 전 경보, 약한 프로토콜 거부 |
| 백업·장애 조치 | 대체 사이트 엔드포인트에 같은 거래 실행 | 대체 경로도 정상 응답(재해 복구 준비 상태 확인) |
보안 경보 경로를 정기적으로 시험하는 것은 "경보가 오지 않는 것"이 "공격이 없는 것"인지 "탐지 체계가 고장 난 것"인지 구분하게 해 준다. 공격 기법 자체를 자동 재현해 탐지 여부를 보는 것은 침해 공격 시뮬레이션의 영역이다.
- 기준선(baseline): 정상 상태에서 합성 거래의 응답 시간·성공률을 측정해 둔 값이다. 이후 측정값이 기준선에서 크게 벗어나면 장애, 성능 저하, 또는 공격(서비스 거부, 악성 변경)의 신호로 본다.
- 벤치마크(benchmark): 같은 거래를 다른 시점(배포 전후), 다른 환경(지역·회선), 또는 목표치(SLA, SLO)와 비교하는 것이다. 보안 패치나 설정 변경 뒤 성능이 허용 범위 안인지 확인하는 데도 쓴다.
- CISSP 개요의 "Synthetic transactions/benchmarks"는 이렇게 "만든 거래로 측정하고, 기준과 비교한다"는 한 묶음의 기법을 뜻한다. 구성 표준을 뜻하는 CIS 벤치마크 같은 보안 기준선과는 용어가 겹치지만 맥락이 다르다.
- 운영 환경에서 실행하므로 테스트 계정, 테스트 상품, 테스트 결제 수단을 따로 두고 실제 거래·정산·통계에 섞이지 않게 표시한다.
- 테스트 계정은 최소 권한으로 만들고 자격 증명을 안전하게 보관한다. 스크립트에 비밀번호를 평문으로 넣지 않는다.
- 개인정보가 들어간 실제 고객 데이터를 스크립트에 쓰지 않는다.
- 화면이 바뀌면 스크립트가 깨지므로 변경 관리 절차에 합성 거래 갱신을 포함한다.
- 실패 경보가 너무 잦으면 무시되기 시작한다. 재시도 규칙과 여러 지점 동시 실패 조건을 둔다.
이름이 비슷한 합성 데이터(synthetic data)는 실제 데이터의 통계적 특성을 흉내 내어 만든 데이터로, 주로 개인정보 보호나 AI 학습에 쓴다. 합성 트랜잭션은 거래(행위)를 흉내 내는 모니터링·테스트 기법이다. 합성 트랜잭션 스크립트가 합성 데이터를 입력값으로 쓸 수는 있지만 두 개념은 별개이다.
- 합성 트랜잭션은 능동(active) 모니터링, RUM은 수동(passive) 모니터링이다. "실제 사용자가 없을 때도 서비스 가용성을 확인하는 방법"은 합성 트랜잭션이다.
- 사용자가 장애를 겪기 전에 발견하는 것이 목적이다. "사용자 불만 접수 전에 성능 저하를 탐지"하는 문제에서 고른다.
- 기준선이 있어야 이상 여부를 판단할 수 있다. 측정보다 기준선 수립이 먼저다.
- 합성 트랜잭션은 정해진 경로만 시험한다. 실제 사용 경로 전체를 보려면 RUM이나 로그 검토를 함께 써야 한다.
- 합성 데이터(데이터 생성 기법)와 혼동하지 않는다.