RASP(Runtime Application Self-Protection, 런타임 애플리케이션 자가보호)

1. 개요

가. 정의 및 등장 배경

RASP는 애플리케이션 실행 환경(런타임) 내부에 보안 계측(instrumentation)을 심어, 실제 코드가 실행되는 순간의 데이터 흐름과 실행 컨텍스트를 관찰하여 공격을 탐지·차단하는 보안 기술이다. 방화벽·WAF가 애플리케이션 '바깥'에서 네트워크 요청을 보고 공격 여부를 추정한다면, RASP는 애플리케이션 '안'에서 그 요청이 실제로 어떤 SQL 질의를 만들고 어떤 파일을 열며 어떤 OS 명령을 실행하려 하는지를 직접 보고 판단한다.

RASP가 등장한 근본 배경은 '바깥에서 요청만 보아서는 공격 여부를 확정할 수 없다'는 외곽 방어의 구조적 한계에 있다. WAF는 HTTP 페이로드에서 ' OR 1=1-- 같은 악성 패턴을 추정하지만, 그 요청이 실제로 위험한 SQL이 되는지는 애플리케이션이 파라미터를 어떻게 조립하는지에 달려 있다. 같은 문자열이라도 정상적으로 이스케이프되어 무해할 수도, 그대로 질의에 이어 붙어 치명적일 수도 있다. 즉 공격 성립 여부의 '진실'은 코드가 실행되는 지점에만 존재하며, 외곽 장비는 그 진실을 보지 못한 채 패턴만으로 추정할 뿐이다. RASP는 바로 이 '실행 지점의 진실'을 직접 관측하기 위해 태어났다.

또 하나의 배경은 암호화·우회의 보편화다. 오늘날 트래픽의 대부분이 HTTPS로 암호화되어 외곽 장비가 페이로드를 보려면 별도 복호화가 필요하고, 공격자는 인코딩·난독화·분할 전송으로 시그니처를 끊임없이 우회한다. RASP는 TLS 복호화가 끝난 애플리케이션 내부에서 동작하므로 암호화에 영향받지 않으며, 페이로드가 어떻게 위장되었든 최종적으로 위험한 동작(위험 함수 호출)에 도달하는 순간을 포착한다. 가트너가 2010년대 초 RASP 개념을 제시한 이래, 이 기술은 '애플리케이션이 스스로를 지킨다'는 발상으로 외곽 방어의 사각지대를 메우는 계층으로 자리 잡았다.

나. 필요성

현대 애플리케이션은 수백 개의 오픈소스 라이브러리와 프레임워크가 얽혀 있어 모든 취약점을 소스 수준에서 제거하기 어렵고, 마이크로서비스·API 중심 아키텍처가 보편화되면서 공격 표면이 내부로 깊이 확산되었다. 외곽 WAF만으로는 내부 서비스 간 호출(east-west)이나 역직렬화·SSRF처럼 요청 문자열만으로 판단하기 힘든 공격을 막기 어렵다. RASP는 취약점이 코드에 남아 있더라도 그 취약점이 실제로 악용되는 실행 순간에 개입하여 피해를 차단하므로, 근본 패치가 배포되기 전까지 애플리케이션 자체를 방어선으로 세울 수 있다. 이는 데브섹옵스·제로 트러스트 흐름에서 '방어를 자산(애플리케이션)에 밀착시킨다'는 요구와도 부합한다.

특히 공급망 취약점이 잇따르는 상황에서 RASP의 필요성은 더욱 두드러진다. Log4Shell처럼 널리 쓰이는 라이브러리의 제로데이가 공개되면, 조직은 수백 개 애플리케이션에 흩어진 취약 버전을 즉시 교체하기 어렵다. 이때 RASP는 해당 취약점이 유발하는 '위험한 행위' 자체를 실행 지점에서 차단하여, 패치 적용이 완료될 때까지의 공백을 메우는 런타임 방어선 역할을 한다. 즉 RASP는 '취약점을 없애는' 기술이 아니라 '취약점이 남아 있는 동안 악용을 막는' 보완재로서, SBOM·취약점 관리 체계와 함께 공급망 보안의 실행 시점 통제를 담당한다.

다. RASP의 핵심 특징

RASP의 특징은 세 가지로 압축된다. 첫째는 실행 컨텍스트 인식(Context-aware)으로, 네트워크 요청의 겉모습이 아니라 그 요청이 유발한 실제 질의·파일 접근·명령 실행을 보고 판단하므로 오탐이 근본적으로 적다. 둘째는 자가 방어(Self-protection)로, 외부 장비에 의존하지 않고 애플리케이션 스스로가 자신에게 들어온 공격을 인지·대응한다. 셋째는 암호화 무관성·우회 저항성으로, TLS 복호화 이후 내부에서 동작하기에 트래픽 암호화나 페이로드 난독화에 영향받지 않는다. 이 세 특징이 결합해 RASP는 '취약할 수밖에 없는 코드를 실행 시점에 지키는' 애플리케이션 밀착형 최후 방어선이 된다.

이 세 특징은 곧 RASP가 '방어의 위치를 자산에 최대한 가까이 옮겼다'는 점에서 비롯된다. 전통적 보안은 경계(perimeter)에 방어를 집중했지만, 클라우드·마이크로서비스 환경에서는 경계가 흐려지고 공격 표면이 내부로 파편화되었다. RASP는 방어 지점을 네트워크 경계가 아니라 보호해야 할 자산(애플리케이션) 그 자체에 두어, 요청이 어디에서 왔든 '그 요청이 자산 안에서 위험한 일을 하려는 순간'에 개입한다. 이는 '모든 접근을 신뢰하지 않고 자원에 밀착해 검증한다'는 제로 트러스트의 사고와 같은 맥락이며, RASP가 단순한 WAF 대체재가 아니라 보안 아키텍처의 무게중심 이동을 반영하는 기술임을 보여준다.

2. RASP의 전체 구조와 계측 방식

RASP는 특정 장비가 아니라, 애플리케이션 런타임(JVM·.NET CLR·Node.js 등) 내부에 센서(sensor)를 심어 민감한 함수 호출을 가로채는(hooking) 계측 아키텍처로 이해해야 한다. 아래는 요청이 애플리케이션 내부를 흐르며 RASP가 개입하는 전체 구조도이다.

flowchart LR
  C["클라이언트(사용자·공격자)"] --> WAF["WAF(외곽 추정 방어)"]
  WAF --> APP
  subgraph APP["애플리케이션 런타임(JVM·CLR 등)"]
    REQ["요청 처리 로직"] --> SENS["RASP 센서(함수 후킹)"]
    SENS --> SINK["위험 지점(SQL·파일·명령·역직렬화)"]
  end
  SENS -->|정상| SINK
  SENS -->|공격 판정| BLK["차단(예외 발생·요청 중단)"]
  SENS --> LOG["로그·SIEM·대시보드"]

위 구조에서 주목할 점은 RASP가 WAF '다음', 즉 외곽 방어를 통과해 애플리케이션 내부까지 들어온 요청을 대상으로 동작한다는 것이다. WAF가 넓은 그물로 1차로 거른 뒤에도 남는 '정상처럼 보이지만 실제로는 위험한' 요청, 혹은 내부 서비스 간 호출처럼 애초에 외곽을 거치지 않는 트래픽까지, RASP는 자산 내부에서 마지막으로 검증한다. 따라서 RASP와 WAF는 같은 공격을 중복으로 막는 낭비가 아니라, 서로 다른 층위에서 서로의 사각지대를 메우는 직렬 배치로 이해해야 한다.

RASP 처리의 출발점은 '계측(Instrumentation)'이다. 보안 센서를 애플리케이션의 위험 함수(JDBC 질의 실행, Runtime.exec, 파일 입출력, 역직렬화 등) 진입부에 심어 두고, 그 함수가 호출되는 순간 인자(argument)와 호출 스택을 검사한다. 핵심은 '요청의 어느 입력값이 이 위험 함수의 인자로 흘러 들어왔는가(taint tracking, 오염 추적)'를 아는 것이다. 사용자 입력이 아무런 정제 없이 SQL 질의 문자열로 흘러들어 문법 구조를 바꾼다면, RASP는 이를 인젝션으로 확정하고 실행 직전에 차단한다. 외곽 장비가 '이 문자열은 수상하다'고 추정하는 것과 달리, RASP는 '이 입력이 실제로 질의 구조를 바꾸었다'는 사실로 판정하므로 정확도가 높다.

가. 계측(Instrumentation) 방식 — 에이전트·라이브러리·하이브리드

RASP를 관통하는 첫 번째 설계 결정은 '어떻게 애플리케이션 내부에 센서를 심을 것인가'이다. 에이전트(Agent) 방식은 자바의 -javaagent 옵션이나 JVMTI, .NET의 프로파일링 API를 이용해 바이트코드를 기동 시점에 재작성(instrument)하여 위험 함수에 후킹 코드를 자동 삽입한다. 애플리케이션 소스를 전혀 고치지 않고도 적용되며 커버리지가 넓어 상용 RASP의 주류를 이룬다. 다만 런타임·프레임워크 버전에 민감하고, 바이트코드 조작이 드물게 호환성 문제를 유발할 수 있다.

라이브러리·SDK 방식은 개발자가 보안 라이브러리를 의존성에 추가하고 코드에서 명시적으로 호출하거나 필터·인터셉터로 연결한다. 개입 지점을 개발자가 통제하므로 예측 가능하지만, 적용 범위가 개발자가 연결한 지점에 한정되고 코드 수정이 필요하다. 하이브리드 방식은 에이전트로 폭넓게 자동 계측하되 핵심 트랜잭션은 SDK로 정밀 보강하여 두 방식의 장점을 결합한다. 실무에서는 레거시·서드파티 코드가 많아 소스 수정이 어려운 환경일수록 에이전트 방식을, 보안 요구가 매우 높은 금융 핵심 거래 경로일수록 하이브리드를 택하는 경향이 있다.

계측 방식의 선택은 단순한 기술 취향이 아니라 운영 조직의 책임 경계와 배포 모델을 가르는 결정이다. 에이전트 방식은 운영·보안팀이 애플리케이션 기동 옵션만 바꾸면 적용되므로 개발팀의 코드 변경 없이 '보안팀 주도'로 전개할 수 있는 반면, 바이트코드 재작성이 개발팀이 의도하지 않은 동작을 유발하면 책임 소재가 모호해진다. 라이브러리 방식은 개발팀이 의존성과 호출 지점을 직접 관리하므로 '개발팀 주도'의 데브섹옵스 문화에 적합하지만, 수백 개 마이크로서비스 전반에 일관되게 적용하려면 공통 보안 라이브러리의 버전 거버넌스가 전제되어야 한다. 따라서 조직은 애플리케이션 포트폴리오의 기술 다양성과 팀 구조를 함께 고려해 계측 전략을 수립해야 한다.

나. 탐지 지점(Interception Point)과 오염 추적

두 번째 핵심 원리는 '어디를 가로채서 무엇을 근거로 판단하는가'이다. RASP는 애플리케이션에서 외부 자원과 맞닿는 '싱크(sink)'—DB 질의 실행, OS 명령 실행, 파일 시스템 접근, URL 연결(SSRF 관련), 객체 역직렬화, 스크립트 평가(eval) 등—를 집중 계측한다. 그리고 HTTP 파라미터·헤더·쿠키 같은 '소스(source)'에서 들어온 신뢰할 수 없는 입력이 중간 정제 없이 싱크에 도달했는지를 오염 추적(taint tracking)으로 따라간다.

예컨대 SQL 인젝션 판정에서 RASP는 단순히 질의 문자열에 OR 1=1이 있는지를 보지 않는다. 대신 사용자 입력이 질의의 '데이터' 영역이 아니라 '구조(문법)' 영역을 바꾸었는지를 질의 파싱으로 확인한다. 정상적으로 바인딩 변수(prepared statement)에 묶인 입력은 아무리 악성 문자열이어도 구조를 바꾸지 못하므로 통과시키고, 문자열 연결로 구조가 바뀐 경우에만 차단한다. 이 방식은 '값' 자체가 아니라 '문맥상 역할'로 판단하므로, WAF가 어쩔 수 없이 겪는 '악성처럼 생겼지만 실은 정상인 입력'에 대한 오탐을 크게 줄인다.

오염 추적의 정밀도는 곧 RASP 탐지 품질을 좌우한다. 신뢰할 수 없는 소스에서 들어온 데이터에 '오염(taint)' 표식을 붙이고, 그 데이터가 변수 복사·문자열 연결·함수 전달을 거쳐 싱크에 도달할 때까지 표식이 전파되도록 런타임이 추적한다. 중간에 적절한 검증·이스케이프·인코딩 함수를 거치면 표식을 해제(sanitize)하여 더 이상 위험으로 보지 않는다. 이 전파·해제 규칙을 얼마나 정교하게 모델링하느냐에 따라 오탐·미탐이 갈리므로, 상용 RASP는 주요 프레임워크·라이브러리의 정제 함수 목록을 사전에 내장하고 지속적으로 갱신한다. 그러나 커스텀 정제 로직이나 비표준 데이터 흐름은 추적이 끊길 수 있어, 조직 고유의 정제 패턴을 룰로 보강하는 튜닝이 필요하다.

다. 동작 모드 — 모니터링과 차단

세 번째 축은 '탐지한 공격을 어떻게 처리할 것인가'이다. 모니터링(Monitoring)·탐지 모드는 공격을 탐지해 로그·알림만 남기고 요청은 통과시킨다. 도입 초기, 오탐으로 정상 거래가 막히는 사고를 피하기 위해 일정 기간 이 모드로 관측하는 것이 정석이다. 차단(Blocking)·보호 모드는 공격 판정 시 해당 위험 함수 호출에 예외를 발생시키거나 요청 처리를 중단하여 피해를 실제로 막는다. 차단 방식도 '해당 작업만 거부'할지 '세션·요청 전체를 종료'할지 세분화할 수 있으며, 가상 패치처럼 특정 CVE에 대한 핀포인트 룰을 즉시 배포하는 운영도 가능하다. 실무에서는 WAF와 마찬가지로 탐지 모드로 충분히 튜닝한 뒤 신뢰 수준이 확보된 룰부터 차단으로 전환하는 점진적 성숙 과정을 따른다.

차단의 방식에도 설계 판단이 개입한다. 위험 함수 호출에 예외를 던져 '해당 작업만' 실패시키면 애플리케이션이 이를 정상 오류처럼 처리해 서비스를 지속할 수 있으나, 공격자가 반복 시도로 다른 경로를 탐색할 여지가 남는다. 반대로 요청·세션 전체를 즉시 종료하면 방어는 강력하지만 오탐 시 정상 사용자의 거래가 통째로 끊긴다. 따라서 성숙한 운영은 위험도에 따라 차단 강도를 차등화한다. 예컨대 원격코드실행으로 이어질 수 있는 역직렬화·명령 삽입은 세션 종료로 강하게 대응하고, 상대적으로 영향이 제한적인 경로 조작 시도는 해당 작업만 거부하며 로깅을 강화하는 식이다. 이처럼 RASP는 '탐지할 수 있다'를 넘어 '어떻게 대응할 것인가'를 서비스 특성에 맞춰 설계하는 정책의 문제다.

라. RASP 도입·운영 라이프사이클

RASP는 도입 시점보다 도입 이후의 운영이 성패를 가른다는 점에서 WAF와 닮았으며, 실무 정착 절차는 대체로 다음 흐름을 따른다.

1. 대상 선정·계측 적용: 보호 가치가 높은 애플리케이션을 선별하고, 에이전트/라이브러리 방식으로 센서를 기동 환경에 적용한다. 이때 런타임·프레임워크 버전 호환성을 먼저 검증한다.
2. 성능 베이스라인 측정: 센서 적용 전후의 응답시간·CPU·메모리를 부하 테스트로 실측하여 오버헤드가 수용 범위인지 확인하고, 과부하 경로는 계측 범위에서 제외한다.
3. 탐지 전용 모드 운영: 룰을 차단이 아닌 로깅만으로 일정 기간 가동해, 실제 트래픽에서 어떤 정상 동작이 룰에 걸리는지(오탐 후보)를 관측한다.
4. 오탐 튜닝·차단 전환: 관측된 오탐을 분석해 정제 규칙·예외를 조정하고, 신뢰 수준이 확보된 룰부터 위험도에 맞는 차단 강도로 순차 전환한다.
5. 지속 갱신·연계: 신규 CVE·공격 트렌드에 맞춰 룰을 갱신하고, 로그를 SIEM·SOAR와 연계해 탐지에서 대응까지 자동화하며 센서 버전을 형상관리로 추적한다.

이 순환에서 핵심은 WAF와 마찬가지로 '차단을 서두르지 않는 것'이다. 검증 없이 전면 차단부터 걸면 정상 거래가 막혀 서비스 신뢰가 무너지고, 운영팀은 센서를 통째로 꺼버리는 최악의 선택으로 내몰린다. RASP 역시 '설치하면 끝'이 아니라 지속 튜닝과 성능 관측이 전제된 운영형 통제로 다루어야 한다.

3. RASP의 탐지·대응 처리 흐름과 방어 대상

RASP가 실제로 공격을 어떻게 포착하는지, 하나의 요청이 내부에서 판정되는 프로세스 세부도를 본다.

sequenceDiagram
  participant U as 사용자·공격자
  participant A as 애플리케이션 로직
  participant R as RASP 센서
  participant D as 위험 지점(DB·OS·파일)
  U->>A: HTTP 요청(입력값 포함)
  A->>A: 비즈니스 로직 수행
  A->>R: 위험 함수 호출 가로채기(hook)
  R->>R: "오염 추적·문맥 분석(입력→구조 변경?)"
  alt 공격으로 판정
    R-->>A: "예외 발생·호출 차단"
    R->>R: 로그·알림(SIEM)
  else 정상
    R->>D: 원래 작업 수행
    D-->>A: 결과 반환
  end

가. 주요 방어 대상 공격

RASP가 특히 강점을 보이는 영역은 요청 문자열만으로는 판단이 어려운 실행 시점 공격이다. SQL 인젝션은 앞서 설명한 질의 구조 변경 여부로, OS 명령어 삽입(Command Injection)은 Runtime.exec·ProcessBuilder 호출 인자에 사용자 입력이 흘러들었는지로 판정한다. 경로 조작(Path Traversal)은 파일 접근 함수에 ../가 포함된 사용자 입력이 도달했는지, SSRF는 외부 연결 대상 URL이 사용자 입력으로 결정되는지를 본다. 특히 안전하지 않은 역직렬화(Insecure Deserialization)는 페이로드가 암호화·난독화되어 WAF로는 탐지가 매우 어렵지만, RASP는 역직렬화 과정에서 위험한 클래스(gadget)가 로딩·실행되는 순간을 직접 포착할 수 있다.

실전에서 RASP의 가치를 입증한 대표 사례가 Log4Shell(CVE-2021-44228)이다. 2021년 말 Apache Log4j의 JNDI 조회 취약점이 공개되자, 공격자들은 ${jndi:ldap://...} 문자열을 ${${lower:j}ndi: 처럼 잘게 쪼개 WAF 시그니처를 빠르게 우회했다. 그러나 RASP는 문자열의 겉모습이 아니라 애플리케이션이 실제로 외부 LDAP/RMI 서버로 JNDI 조회를 시도하거나 원격 클래스를 로딩하려는 '행위' 자체를 실행 지점에서 차단할 수 있어, 난독화 변종과 무관하게 동일하게 대응했다. 이는 '패턴이 아니라 행위로 막는' RASP의 본질을 상징적으로 보여준 사건으로 자주 인용된다(다만 커버리지는 계측된 경로에 한정되므로, RASP가 모든 변종을 자동으로 막는다고 단정할 수는 없다).

한 요청의 처리 과정을 구체화하면 이해가 분명해진다. 사용자가 게시판 검색창에 제품명'); DROP TABLE users;--을 입력했다고 하자. 애플리케이션이 이 값을 바인딩 없이 질의 문자열에 이어 붙이면, JDBC 실행 직전 RASP 센서가 호출을 가로채 원래 질의의 문법 구조(토큰 트리)와 사용자 입력이 삽입된 뒤의 구조를 비교한다. 입력으로 인해 DROP TABLE이라는 새로운 문장 구조가 생겨났음을 확인하면, RASP는 이를 인젝션으로 확정하고 질의 실행에 예외를 던져 DB에 닿기 전에 중단시킨 뒤, 원본 입력·호출 스택·매칭 룰을 로그로 남긴다. 외곽 WAF가 '수상한 문자열'로 추정하는 것과 달리, RASP는 '질의 구조가 실제로 바뀌었다'는 사실로 판단한다는 점이 결정적 차이다.

나. RASP와 유사·연계 기술 비교

RASP는 단독으로 완결되지 않으며 인접 기술과의 역할 구분이 중요하다. 아래 표는 비교 정리이되, 차이가 생기는 이유를 함께 이해해야 한다.

구분	동작 위치·시점	판단 근거	주 목적	RASP와의 관계
WAF	앱 바깥·요청 시점	요청 페이로드 패턴	외곽 공격 차단	폭넓은 1차 방어, 상호 보완
RASP	앱 내부·실행 시점	실제 실행 컨텍스트·오염 추적	실행 시점 공격 차단	정밀 최후 방어
SAST	개발 단계·정적	소스코드 분석	배포 전 취약점 발견	사전 제거(예방)
DAST	테스트 단계·동적	외부 모의공격 응답	배포 전 취약점 발견	사전 발견(예방)
IAST	테스트 단계·계측	내부 계측(RASP와 동종)	테스트 중 취약점 발견	계측 기술 공유, 목적 상이

가장 혼동되는 것이 IAST(Interactive Application Security Testing)와의 관계다. IAST는 RASP와 동일한 계측·오염 추적 기술을 쓰지만, 목적이 다르다. IAST는 QA·테스트 단계에서 취약점을 '발견·보고'하는 데 쓰이고, RASP는 운영 단계에서 공격을 '차단'하는 데 쓰인다. 즉 같은 엔진을 테스트에 쓰면 IAST, 운영 방어에 쓰면 RASP가 되는 셈이다. 많은 상용 제품이 하나의 계측 엔진으로 IAST와 RASP를 모두 제공하는 이유가 여기에 있다.

WAF와 RASP의 결정적 차이는 '바깥에서 추정하는가, 안에서 확인하는가'이다. WAF는 모든 요청을 넓게 1차로 거르지만 애플리케이션 내부 로직을 알지 못해 오탐·미탐이 불가피하다. RASP는 좁지만 깊게, 실제 실행 결과로 판단해 정확도가 높다. 둘은 경쟁이 아니라 다층 방어(Defense in Depth) 관계로, WAF로 외곽을 넓게 막고 RASP로 핵심 트랜잭션을 정밀 보강하며, 여기에 SAST/DAST/IAST 같은 개발 단계 통제가 더해질 때 애플리케이션 보안이 완결된다.

4. 심화 — 표준·시장 동향과 ADR로의 확장

최근 애플리케이션 보안 시장에서 RASP는 독립 제품에서 관측가능성(observability)과 결합한 런타임 보안 플랫폼으로 재편되고 있다. 가트너는 RASP의 실행 지점 가시성 개념을 확장하여 ADR(Application Detection and Response, 애플리케이션 탐지·대응)를 신흥 범주로 제시하는데, 이는 애플리케이션 런타임에서 수집한 공격·행위 데이터를 EDR·XDR과 연계하여 탐지에서 대응까지 자동화하려는 흐름이다. 즉 RASP가 '막는' 데서 나아가, 공격의 전후 맥락을 추적하고 보안 운영(SOC)과 연결되는 방향으로 진화하고 있다.

시장에서는 Contrast Security, Imperva(구 Prevoty), Dynatrace, Waratek 등 상용 솔루션과 함께 OpenRASP 같은 오픈소스 구현이 자바·.NET·PHP 등 다양한 런타임을 지원하며 저변을 넓혀 왔다. 특히 많은 제품이 하나의 계측 엔진으로 테스트 단계의 IAST와 운영 단계의 RASP를 함께 제공하는데, 이는 'Shift-Left(개발 중 발견)'와 'Shift-Right(운영 중 방어)'를 단일 기술 축으로 연결하려는 시장의 방향성을 보여준다. 다만 폴리글랏 마이크로서비스가 보편화되면서 언어별 센서를 일관되게 운영하는 거버넌스가 새로운 과제로 떠올랐다.

표준·규제 측면에서도 RASP의 위상이 올라가고 있다. OWASP는 RASP를 애플리케이션 방어 기술로 소개하며, 역직렬화·인젝션 등 OWASP Top 10 위협에 대한 런타임 완화책으로 언급한다. 또한 PCI DSS v4.0은 결제 페이지의 변조 탐지와 실행 시점 보호를 강화하는 방향으로 개정되어, RASP류 런타임 보호가 컴플라이언스 대응 수단으로 재조명되고 있다. 클라우드 네이티브 환경에서는 컨테이너·서버리스 런타임 안에 경량 센서를 심어 워크로드 보안(CWPP)과 결합하는 시도가 늘고 있으며, 바이트코드 계측의 대안으로 eBPF 기반 런타임 가시성을 활용해 커널 수준에서 애플리케이션 행위를 관찰하는 접근도 부상한다.

예상 출제 방향으로는 ▲WAF와 RASP의 동작 원리·판단 근거 차이를 설명하고 다층 방어 설계를 제시하라 ▲RASP의 계측 방식(에이전트 vs 라이브러리)의 트레이드오프를 논하라 ▲Log4Shell 등 사례로 RASP의 강점과 한계를 논하라 ▲IAST·DAST·SAST·RASP를 생애주기(SDLC) 관점에서 비교하고 데브섹옵스 통합 방안을 제시하라 등이 유력하다.

5. 고려사항 및 시사점(기술사 관점)

RASP를 성공적으로 정착시키려면 '제품 도입'이 아니라 '성능·안정성·운영 프로세스'의 균형 관점에서 접근해야 한다. 기술사 답안에서는 다음의 트레이드오프와 전략을 함께 논해야 한다.

• 성능 오버헤드와 안정성의 균형: RASP는 애플리케이션 내부에서 함수 호출마다 검사를 수행하므로 지연·CPU 부담이 발생한다. 일반적으로 한 자릿수 % 수준의 오버헤드로 알려져 있으나 트래픽 특성·계측 범위에 따라 편차가 크므로, 반드시 부하 테스트로 실측하고 핵심 경로만 선별 계측하는 전략이 필요하다. 바이트코드 조작이 애플리케이션 안정성에 영향을 줄 수 있으므로, 장애 시 보안보다 가용성을 우선할지(페일오픈) 보안을 우선할지(페일클로즈)를 서비스 특성에 맞춰 명확히 정의해야 한다.

• 커버리지의 한계 인식: RASP는 계측된 런타임·함수에 한해서만 방어하므로, 네이티브 코드·미계측 프레임워크·외부 호출은 사각지대로 남는다. 따라서 RASP를 만능 방어로 오인하지 말고, WAF(외곽)·시큐어 코딩·SAST/DAST(사전 제거)와 결합한 다층 방어의 한 계층으로 자리매김해야 한다. RASP가 있다는 이유로 코드 보안을 소홀히 하면 오히려 위험이 누적된다.

• 언어·프레임워크 종속성과 운영 부담: RASP는 JVM·.NET 등 특정 런타임에 강하게 결합되어, 폴리글랏(다언어) 마이크로서비스 환경에서는 언어별 센서를 각각 관리해야 하는 부담이 있다. 런타임·프레임워크 업그레이드 시 센서 호환성을 지속 검증해야 하며, 센서 버전·룰을 형상관리(Policy as Code) 체계 안에서 추적 가능하게 유지해야 감사·변경관리가 성립한다.

• 데브섹옵스·관측가능성과의 통합: RASP는 개발 단계의 IAST와 계측 엔진을 공유하므로, 'Shift-Left(사전 발견)'와 'Shift-Right(운영 방어)'를 하나의 기술 축으로 잇는 접점이 된다. RASP 로그를 SIEM·SOAR·XDR과 연계하면 탐지에서 대응까지 자동화(플레이북)가 가능하고, ADR 흐름과 결합해 공격의 전후 맥락을 추적할 수 있다. CI/CD 파이프라인에서 센서 배포·룰 검증을 자동화하는 것이 운영 성숙의 핵심이다.

• 점진적 적용과 오탐 최소화 전략: RASP는 WAF보다 오탐이 적지만 0은 아니다. 신규 룰·센서는 반드시 탐지 전용 모드로 충분히 관측해 정상 업무가 막히지 않음을 확인한 뒤 차단으로 전환하고, 차단 범위(해당 작업만/세션 전체)를 위험도에 따라 차등 적용해야 한다. 검증 없는 전면 차단은 정상 거래를 막아 운영팀이 센서를 꺼버리는 최악의 선택으로 내몰 수 있다.

• 연계 기술 및 전망: RASP는 제로 트러스트의 '자산 밀착 방어' 원칙과 부합하며, CWPP·eBPF·ADR과 융합하며 런타임 보안 플랫폼으로 수렴하고 있다. 생성형 AI를 활용한 공격 자동 변형이 늘수록, 겉모습이 아닌 '행위'로 판단하는 RASP의 가치는 커질 전망이다. 다만 계측 기반 판정의 근거를 운영자가 이해·감사할 수 있도록 설명가능성과 로깅 체계를 함께 설계하는 것이 향후 과제로 남는다.

참고자료

• OWASP, "Runtime Application Self-Protection", https://owasp.org/www-community/controls/Runtime_Application_Self_Protection
• Gartner, "Application Detection and Response (ADR)" 및 "Runtime Application Self-Protection", https://www.gartner.com/en/information-technology/glossary/runtime-application-self-protection-rasp
• MITRE, "CVE-2021-44228 (Log4Shell)", https://nvd.nist.gov/vuln/detail/CVE-2021-44228
• PCI Security Standards Council, "PCI DSS v4.0", https://www.pcisecuritystandards.org/

---

한 줄 요약: RASP는 애플리케이션 런타임 내부에 센서를 심어 사용자 입력이 위험 함수의 실행 구조를 바꾸는 순간을 오염 추적으로 포착·차단하는 자가보호 기술로, 암호화·난독화에 무관하게 실행 지점의 '행위'로 판단해 오탐이 적으나 성능 오버헤드·언어 종속·커버리지 한계가 있어 WAF·SAST/DAST와 결합한 다층 방어의 정밀 계층으로 운영해야 한다.