RBI란?

서론

아무리 보안 솔루션을 잘 깔아도, 사용자가 악성 사이트를 한 번 잘못 클릭하면 감염이 시작되는 경우가 많습니다.
브라우저는 각종 스크립트, 플러그인, 미디어를 실행하는 복잡한 프로그램이라 공격 표면도 넓습니다.

이 문제를 근본적으로 줄이기 위해 나온 개념이 바로 RBI(Remote Browser Isolation, 원격 브라우저 격리) 입니다.
이 글에서는 보안을 처음 배우는 개발자도 이해할 수 있도록, RBI가 무엇이고, 어떻게 동작하며, SWG/WAF와 어떤 관계가 있는지 살펴보겠습니다.

1. RBI란 무엇인가?

1.1 RBI의 정의

RBI(Remote Browser Isolation) 은 말 그대로 브라우저를 사용자 PC가 아닌 원격 환경에서 실행하고, 그 결과만 사용자에게 전달하는 기술입니다.

쉽게 말해:

• 위험할 수 있는 웹 페이지를 내 컴퓨터에서 직접 여는 것이 아니라
• 클라우드나 격리된 서버에서 대신 열고
• 나는 그 화면(렌더링 결과)만 영상/DOM 스트림 형태로 전달받아 보는 방식입니다.

이렇게 하면:

• 웹 페이지 안에 악성 스크립트나 익스플로잇이 있어도
• 실제로 공격이 실행되는 환경은 격리된 원격 브라우저이기 때문에
• 사용자 PC에 직접적인 피해가 가는 것을 크게 줄일 수 있습니다.

1.2 왜 RBI가 나왔을까?

기존 보안 솔루션만으로는 다음과 같은 한계가 있었습니다.

• 시그니처 기반 안티바이러스: 이미 알려진 악성 코드만 잘 막음
• SWG/프록시: URL/카테고리/평판 기반 차단, "모르는 신규 사이트"에는 약할 수 있음
• 브라우저 취약점: 제로데이(알려지지 않은 취약점)는 탐지 전에 악용될 수 있음

RBI는 이런 문제를 "탐지" 중심이 아니라, 실행 환경 자체를 분리하는 방식으로 접근합니다.

• "악성인지 아닌지 100% 확신하긴 어렵다" →
  "그럼 그냥 위험할 수 있는 것들은 다 격리된 곳에서 실행시키자"

라는 발상입니다.

2. RBI는 어떻게 동작할까?

RBI 솔루션의 기본 흐름은 다음과 같습니다.

1. 사용자가 브라우저에서 어떤 사이트에 접속
2. 요청이 RBI 서버(클라우드/온프레미스) 로 전달
3. RBI 서버 쪽에서 가상 브라우저 세션을 생성
4. 해당 브라우저가 실제로 웹 페이지를 로드하고 실행
5. 결과 화면(렌더링 결과)을 사용자에게 스트리밍 또는 변환된 DOM 형태로 전달

사용자 PC에서 보는 화면은:

• 말 그대로 "원격 데스크톱"처럼 영상 스트림으로 그려질 수도 있고
• 또는 안전하게 변환된 HTML/이미지로 재구성되어 전달될 수도 있습니다.

핵심은:

• 실제 코드 실행은 원격 환경에서만 일어나고
• 사용자에게는 그 "결과"만 온다는 점입니다.

3. RBI의 유형

RBI 구현 방식에는 여러 가지가 있지만, 크게 다음과 같이 나눌 수 있습니다.

3.1 픽셀 스트리밍 방식

• 원격 브라우저에서 렌더링한 화면을 동영상/이미지 스트림으로 전송
• 사용자는 입력(마우스/키보드)만 보내고, 화면은 받아서 보여줌
• 장점:
  • 컨텐츠가 로컬로 내려오지 않기 때문에 보안성이 매우 높음
• 단점:
  • 네트워크/지연 시간에 따라 UX가 떨어질 수 있음

3.2 DOM 미러링/변환 방식

• 원격 브라우저에서 페이지를 분석한 뒤
• 안전하다고 판단되는 요소만 걸러서 사용자 브라우저에 전달
• 예를 들면:
  • 자바스크립트를 제거하거나 제한
  • 위험한 태그/속성 제거
• 장점:
  • 사용자 경험이 더 자연스럽고, 인터랙션이 부드러움
• 단점:
  • 변환 로직이 복잡하고, 100% 완벽한 변환이 어려울 수 있음

초보 개발자 입장에서는:

• "방법은 조금씩 달라도, 결론은 위험한 코드는 내 PC에서 직접 실행되지 않는다" 정도만 기억하면 충분합니다.

4. RBI vs SWG vs WAF

이미 WAF와 SWG를 공부했으니, RBI가 어디에 위치하는지 비교해 보면 이해가 더 쉽습니다.

4.1 보호 대상과 관점

• WAF:
  • 보호 대상: 웹 서버/서비스
  • 관점: 외부 사용자의 요청 중 공격을 막음
• SWG:
  • 보호 대상: 조직 내부 사용자/네트워크
  • 관점: 사용자가 나가는 웹 트래픽을 필터링
• RBI:
  • 보호 대상: 사용자 단말(PC/브라우저)
  • 관점: "어떤 사이트든 열 수는 있지만, 실제 실행은 격리된 곳에서 하자"

4.2 보안 접근 방식의 차이

• WAF/SWG:
  • "위험한 요청/사이트를 탐지해서 차단하자"
• RBI:
  • "위험할 수도 있지만, 굳이 완벽히 구별하려고 애쓰기보다는
    애초에 로컬에서 실행하지 말고 격리된 곳에서 실행하자"

정리하면:

• WAF/SWG는 필터링/탐지 중심
• RBI는 격리/분리 중심

5. RBI가 유용한 시나리오

5.1 알 수 없는 외부 사이트 접속이 많은 환경

예를 들어:

• 영업/마케팅 팀이 매일 새로운 사이트를 검색하고 열어보는 경우
• 지원/CS 팀이 고객이 보내준 각종 링크를 확인해야 하는 경우

이런 상황에서는:

• "이 링크가 안전한지 아닌지"를 매번 완벽하게 판단하기 어렵습니다.
• RBI를 사용하면, 모든 브라우징을 격리된 환경에서 처리할 수 있습니다.

5.2 고보안/규제 산업

• 금융, 공공, 방산, 의료 등
• 단말 보안이 특히 중요한 환경에서는

RBI를 통해:

• 웹을 사용하면서도 단말 감염 가능성을 크게 낮출 수 있습니다.

5.3 개발자/보안팀의 분석 작업

보안팀이나 리서처가:

• 의심스러운 사이트/피싱 페이지를 분석해야 할 때

RBI 환경에서 사이트를 열면:

• 로컬 환경이 감염될 위험 없이
• 웹 페이지의 동작을 관찰할 수 있습니다.

6. 초보 개발자가 알아두면 좋은 RBI 포인트

6.1 사용자 경험(UX)과의 트레이드오프

RBI는 보안을 크게 높여주지만, 다음과 같은 UX 이슈가 있을 수 있습니다.

• 지연 시간 증가
• 일부 복잡한 웹 애플리케이션의 호환성 문제
• 동영상/오디오 스트리밍 품질 저하

그래서 실무에서는:

• "모든 사이트를 RBI로 열지"
• "위험도가 높은 카테고리만 RBI로 열지"

등을 정책으로 세밀하게 조정합니다.

6.2 개발 시 고려할 점

개발자로서 알아두면 좋은 점:

• 사용자가 RBI를 통해 우리 서비스에 접속할 수도 있습니다.
• 이때:
  • 일부 스크립트/기능이 제한될 수 있고
  • 세션/쿠키/스토리지 동작 방식이 약간 달라질 수 있습니다.

그래서:

• 보안이 중요한 고객사가 많은 서비스라면,
  RBI 환경에서도 서비스가 잘 동작하는지 테스트해 보는 것이 좋습니다.

마무리

이 글에서는 초보 개발자의 관점에서 RBI가 무엇인지, 왜 등장했는지, SWG/WAF와 어떻게 다른지를 정리해 보았습니다.

핵심을 다시 정리하면:

• RBI는 브라우저를 원격 격리 환경에서 실행하고, 결과만 사용자에게 보여주는 기술
• "위험한 코드를 아예 내 PC에서 실행하지 않는다"는 철학에 기반
• WAF/SWG가 필터링/탐지 중심이라면, RBI는 격리/분리 중심

앞으로 보안 공부를 이어가면서:

• WAF(서버 보호)
• SWG(사용자/조직 보호)
• RBI(단말/브라우저 보호)

이 세 가지를 서로 연결해서 보면,
웹 보안을 훨씬 입체적으로 이해할 수 있게 될 것입니다.