JS 난독화: 하이브리드 앱의 소스코드는 왜 그대로 노출되는가

개발자 도구로 패키지를 풀고 몇 분만 들여다보면, 결제 검증 로직·API 엔드포인트·프로모션 조건이 거의 그대로 읽히는 경우가 드물지 않습니다. 네이티브 코드(Java/Kotlin/Swift)는 난독화했지만, 정작 앱 로직의 상당 부분을 담당하는 JavaScript 레이어는 무방비로 배포된 것입니다.

문제는 이것이 예외가 아니라, 하이브리드 앱에서 구조적으로 반복되는 패턴이라는 데 있습니다.

왜 이 문제가 하이브리드 앱에서 유독 심각한가

React Native·Cordova·Ionic·Capacitor 같은 하이브리드 프레임워크의 매력은 분명합니다 — 하나의 코드베이스로 iOS·안드로이드를 동시에 커버하고, 웹 개발자 인력을 그대로 활용하며, 배포 주기를 단축합니다. 국내 커머스·핀테크·라이프스타일 앱이 하이브리드를 대거 채택한 이유입니다.

그러나 이 생산성의 이면에 보안 부채가 쌓입니다. 비즈니스 로직이 JS로 작성되면, 그 로직은 최종 사용자의 기기에 사람이 읽을 수 있는 소스에 가까운 형태로 전달됩니다. 결제 흐름, 할인·적립 계산, 인증 토큰 처리, 실험(A/B) 플래그 — 이 모든 것이 텍스트로 존재하는 셈입니다.

• JavaScript는 오늘날 웹을 이루는 핵심 기술 가운데 하나입니다. 공개·비공개 저장소를 통틀어 가장 폭넓게 사용되는 언어 중 하나이며, 개발자 생태계에서도 가장 활발한 참여를 이끄는 언어로 자리 잡았습니다.

• Statista 조사에서도 JavaScript는 가장 널리 사용되는 프로그래밍 언어이자, 가장 배우고자 하는 언어 중 하나로 consistently 언급됩니다.

• 활용 범위도 매우 넓습니다. 하이브리드 모바일 앱은 물론, 클라이언트·서버 측 웹 애플리케이션, 클라우드 기반 로직, 데스크톱 애플리케이션까지 JavaScript는 다양한 환경에서 핵심 실행 레이어로 사용됩니다.

문제는 이 중요한 코드가 대부분 소스에 가까운 형태로 배포된다는 점입니다. 즉, 공격자 입장에서는 읽고 분석하고 수정하기가 상대적으로 쉽습니다. 그래서 지금 하이브리드 앱 보안에서 JavaScript 보호, 특히 Code Obfuscation과 런타임 방어의 결합은 더 이상 선택이 아니라 필수입니다.

JavaScript는 '소스 형태 그대로' 배포된다

문제의 근본 원인은 언어의 배포 방식에 있습니다. 컴파일된 네이티브 바이너리와 달리, JavaScript는 인터프리터가 읽는 소스 형태로 기기에 도달합니다. 압축(minify)이나 번들링은 되어 있어도, 그것은 보안이 아니라 용량·성능 최적화입니다. 압축된 JS는 되돌리기(beautify)가 자동화 도구로 수 초 만에 가능합니다.

공격자에게 이것이 의미하는 바는 명확합니다.

• 앱 번들(APK/IPA) 안에서 JS 파일을 추출해 에디터로 열어 읽습니다.
• 결제 검증·프로모션 조건·인증 흐름 같은 민감 로직을 그대로 파악합니다.
• 값을 바꾸거나 함수를 후킹해 런타임에 동작을 조작합니다 — 예를 들어 "프리미엄 여부" 플래그를 true로 고정하거나, 서버 응답 검증을 우회하는 식입니다.
• 파악한 API 스키마로 자동화 스크립트를 작성해, 수동 조작을 대량 자동화로 확장합니다.

즉, 네이티브 앱이라면 리버스 엔지니어링이라는 '작업'이 필요한 일이, 하이브리드 앱에서는 파일을 여는 것만으로 시작됩니다. 방어의 출발선 자체가 다른 것입니다.

난독화가 하는 일 — 그리고 하지 못하는 일

JS 난독화는 이 노출을 늦추는 1차 방어입니다. 핵심 기법은 다음과 같습니다.

• 식별자 치환: 의미 있는 변수·함수명을 _0x1a2b 같은 무의미한 문자열로 바꿔, 코드의 의도를 감춥니다.
• 문자열 인코딩: API 경로·키·메시지 같은 문자열을 인코딩해, 단순 문자열 검색으로 민감 지점을 찾지 못하게 합니다.
• 제어 흐름 난독화: 실행 경로를 뒤섞어(control-flow flattening), 로직의 흐름을 따라가기 어렵게 만듭니다.
• 데드 코드 삽입: 실행되지 않는 코드를 섞어, 분석 비용을 높입니다.

좋은 JS 난독화 도구를 고를 때 반드시 확인할 점은 다음과 같습니다.

1. 온프레미스(On-premise) 지원 여부. 민감한 코드를 외부 웹 서비스에 업로드하지 않고 사내에서 난독화할 수 있는가. 코드가 특히 민감하다면, 난독화 전까지 코드가 사외로 나가지 않아야 합니다.
2. 빌드 자동화 결합. 빌드 과정에서 자동으로 적용되는가, 매번 수동 개입이 필요한가. 수동 적용은 배포 주기가 빠른 팀에서 반드시 누락됩니다.
3. 하이브리드 특화. 하이브리드 앱의 JS를 보호 프로세스의 일부로 자동 난독화하는가.
   

    

여기서 멈추면 안 됩니다. 난독화는 정적 방어입니다. 아무리 읽기 어렵게 만들어도, 코드는 여전히 실행되어야 하고, 실행되는 순간 그 동작은 관찰 가능합니다. 공격자가 Frida·Xposed 같은 도구로 런타임에 개입하면, 난독화된 코드라도 실행 중의 값과 흐름을 들여다보고 조작할 수 있습니다.

그래서 난독화는 반드시 런타임 보호(RASP)와 결합되어야 합니다 — 앱이 실행되는 순간 후킹·디버깅·계측·변조 시도를 탐지하고 대응하는 계층 말입니다.

흔한 오해 3가지 (FAQ)

"압축(minify)했으니 난독화된 것 아닌가요?"

아닙니다. 압축은 공백·주석 제거와 이름 단축으로 용량을 줄이는 것이며, 자동 도구로 손쉽게 가독성 있게 되돌릴 수 있습니다. 보안 목적의 난독화와는 다른 층위입니다.

"네이티브 부분만 난독화하면 충분하지 않나요?"

하이브리드 앱에서 비즈니스 로직의 상당 부분이 JS에 있다면, 그 JS 레이어가 지금 가장 노출된 표면입니다. 네이티브만 보호한 것은 앞문을 잠그고 뒷문을 열어둔 것과 같습니다.

"난독화만 강하게 하면 되지 않나요?"

난독화는 분석 비용을 높이지만, 런타임 조작 자체를 막지는 못합니다. 정적 방어와 동적 방어는 역할이 다르며, 함께 있어야 완결됩니다.

하이브리드 앱을 위한 실무 체크리스트

• JS 레이어가 담고 있는 민감 로직 목록을 작성했는가 (결제·인증·프로모션·실험 플래그).
• 빌드 파이프라인에 자동 JS 난독화가 결합되어 있는가 (수동 아님).
• 난독화 도구가 온프레미스로 동작하는가, 아니면 코드를 외부로 보내는가.
• 난독화에 더해 **런타임 보호(RASP)**가 후킹·계측·변조를 탐지·차단하는가.
• 난독화 적용 후 성능·크래시 영향을 실측했는가.
  

한국의 하이브리드 앱 환경

국내 커머스·핀테크·라이프스타일 앱은 개발 생산성과 원스토어·구글·애플 동시 배포를 위해 하이브리드(React Native·Flutter 등)를 대거 채택했습니다. 그만큼 JS 레이어에 비즈니스 로직이 몰려 있고, 국내는 안드로이드 점유율이 약 70%대로 높아 디컴파일·번들 추출이 상대적으로 쉽습니다.

특히 카카오페이·네이버페이·토스 같은 간편결제 연동 검증 로직이 JS에 노출되면, 우회·자동화의 출발점이 됩니다. 개인정보보호법(PIPA) 관점에서도, 인증·결제 흐름이 소스 형태로 읽히는 것은 그 자체로 개인정보 유출 리스크와 직결됩니다.

프로몬은 이 문제를 어떻게 다루는가

프로몬은 하이브리드 앱의 JS를 포함한 앱 코드를 소스 수정 없이 난독화하고, Promon SHIELD®의 런타임 자기보호와 결합해 정적·동적 위협을 함께 방어합니다. 난독화가 분석 비용을 높이는 동안, 런타임 보호가 실행 중의 후킹·변조를 차단하는 2중 구조입니다.