0. 시작하기 전에 : 우리 솔직해지자

친구야, 우리 솔직히 말해보자.
앱 만들 때 제일 재밌는 건 UI 예쁘게 뽑는 것이고, 제일 미루는 건 보안이지.

왜냐고? 보안은 잘 해도 티가 안 나고, 못 하면 회사가 없어지는 분야거든.
잘 만든 애니메이션은 "우와 예쁘다" 소리를 듣지만, 잘 짠 암호화 코드는 아무도 칭찬 안 해준다.

근데 말이야. 2020년대 들어서 상황이 완전히 바뀌었어.
한국은 개인정보 보호법이 있고, 유럽 서비스하면 GDPR이 기다리고, 앱스토어에 올리려면 애플의 App Privacy 심사를 통과해야 하고,
구글 플레이는 Data Safety 섹션을 강제로 작성하게 만들어.

이제 보안은 "여유 되면 하는 것"이 아니라 배포의 전제 조건이 된 거야.

코드는 Kotlin / Swift / 일부 JS로 보여줄 거고,
개념 설명은 "전문용어 먼저, 비유 나중" 순서로 갈게. 그래야 나중에 문서 읽을 때 안 헤매거든.

1. 암호화 기초 : 3형제를 구분하자

암호화 얘기하면 사람들이 제일 많이 헷갈리는 게 이거야.
대칭키 · 비대칭키 · 해시. 이 셋은 용도가 완전히 다른데 그냥 "암호화"라고 뭉뚱그려 부르거든.

1-1. 대칭키 암호 (Symmetric) — 자물쇠 하나, 열쇠 하나

잠글 때 쓰는 키와 열 때 쓰는 키가 똑같은 방식이야.
대표 선수는 AES(Advanced Encryption Standard).

장점은 압도적으로 빠르다는 거야.
요즘 CPU에는 아예 AES 전용 명령어(AES-NI, ARM Cryptography Extensions)가 박혀 있어서,
기가바이트급 데이터도 순식간에 처리해.

단점? 키를 어떻게 상대방에게 안전하게 전달하느냐가 영원한 숙제야.
카톡으로 키 보내면? 그 카톡이 털리면 끝이잖아.

그래서 결론은 간단해. AES-256-GCM 쓰면 된다.
GCM은 AEAD(Authenticated Encryption with Associated Data)라서,
누가 암호문을 중간에 한 비트라도 바꾸면 복호화 시점에 예외가 터져. 이게 진짜 중요한 기능이야.

1-2. IV와 Nonce : 재사용하면 죽는다

IV(Initialization Vector) 혹은 Nonce(Number used ONCE).
이름에 이미 답이 있어. 단 한 번만 써야 하는 숫자라고.

같은 키 + 같은 Nonce로 GCM을 두 번 쓰면?
공격자가 두 암호문을 XOR하는 것만으로 평문의 관계를 뽑아낼 수 있고,
심하면 인증 키(H)까지 복구돼서 위조 메시지를 만들 수 있어. 진짜로 치명적이야.

// Android / Kotlin — AES-256-GCM 표준 패턴
import javax.crypto.Cipher
import javax.crypto.SecretKey
import javax.crypto.spec.GCMParameterSpec
import java.security.SecureRandom

object AesGcm {
    private const val TRANSFORM = "AES/GCM/NoPadding"
    private const val IV_SIZE = 12      // GCM 권장: 96비트
    private const val TAG_BITS = 128    // 인증 태그 128비트

    fun encrypt(key: SecretKey, plain: ByteArray): ByteArray {
        val iv = ByteArray(IV_SIZE).also { SecureRandom().nextBytes(it) }
        val cipher = Cipher.getInstance(TRANSFORM)
        cipher.init(Cipher.ENCRYPT_MODE, key, GCMParameterSpec(TAG_BITS, iv))
        val ct = cipher.doFinal(plain)
        return iv + ct            // [IV(12) || ciphertext || tag(16)]
    }

    fun decrypt(key: SecretKey, blob: ByteArray): ByteArray {
        val iv = blob.copyOfRange(0, IV_SIZE)
        val ct = blob.copyOfRange(IV_SIZE, blob.size)
        val cipher = Cipher.getInstance(TRANSFORM)
        cipher.init(Cipher.DECRYPT_MODE, key, GCMParameterSpec(TAG_BITS, iv))
        return cipher.doFinal(ct)  // 변조되면 AEADBadTagException
    }
}

코드가 짧지? 어려운 게 아니야.
어려운 건 "이 key를 어디에 보관하느냐"인데, 그건 3장에서 제대로 다룰게.

1-3. 비대칭키 암호 (Asymmetric) — 공개키 우체통

키가 두 개야. 공개키(Public)와 개인키(Private).
공개키로 잠근 건 개인키로만 열리고, 개인키로 서명한 건 공개키로만 검증돼.

비유하자면 우체통이야.
투입구(공개키)는 누구에게나 열려 있어서 아무나 편지를 넣을 수 있지만,
꺼내는 열쇠(개인키)는 집주인만 갖고 있지.

재밌는 사실: ECC P-256(256비트)의 보안 강도가 RSA 3072비트와 맞먹어.
키가 12배나 짧은데 같은 강도라니, 배터리 아쉬운 모바일에선 당연히 ECC가 유리하지.

1-4. 하이브리드 암호화 : 실제 세상의 정답

그래서 현실은 둘을 섞어 써. 이걸 하이브리드 암호화라고 해.
HTTPS도, 카카오톡 비밀채팅도, PGP 이메일도 전부 이 구조야.

1단계 — 랜덤한 AES 세션키를 하나 만든다 (빠른 대칭키)
2단계 — 실제 데이터는 그 AES 키로 암호화한다
3단계 — AES 키 자체만 상대방 공개키(RSA/ECDH)로 암호화해서 같이 보낸다

이러면 "빠른 속도"와 "안전한 키 전달"을 둘 다 가져가는 거지. 똑똑하지 않아?

1-5. 해시 : 암호화가 아니다!

자, 이건 진짜 중요한 구분이야.
해시(Hash)는 암호화가 아니야. 왜냐하면 되돌릴 수가 없거든.

암호화는 "잠그고 나중에 여는 것"이지만,
해시는 "지문을 뜨는 것"이야. 지문 보고 사람을 복원할 순 없잖아?

해시의 세 가지 성질:
① 일방향성 — 결과에서 입력을 못 구함
② 결정성 — 같은 입력은 항상 같은 출력
③ 충돌 저항성 — 다른 입력이 같은 출력을 내기 어려움

1-6. 비밀번호 저장 : SHA-256도 부족하다

"그럼 비밀번호를 SHA-256으로 해시해서 저장하면 되겠네!"
… 아쉽지만 그것도 부족해. 왜냐면 SHA-256은 너무 빨라서야.

요즘 GPU는 초당 수십억 개의 SHA-256을 계산해.
"password123" 같은 건 0.0001초 만에 깨져. 레인보우 테이블이란 것도 있고.

그래서 비밀번호 전용 해시 함수를 써야 해. 이걸 KDF(Key Derivation Function)라고 불러.

핵심 아이디어는 "일부러 느리게 만들기"야.
사용자는 로그인할 때 0.2초 기다리면 그만이지만,
공격자는 수억 개를 시도해야 하니까 0.2초 × 수억 = 사실상 불가능이 되는 거지.

그리고 Salt는 필수야. 사용자마다 다른 랜덤값을 붙여서 해시하면,
같은 비밀번호를 쓰는 사용자 둘이 있어도 해시값이 달라. 레인보우 테이블이 무력화되지.

2. 안전한 통신 : HTTPS는 시작일 뿐

"저 HTTPS 쓰는데요?"
좋아. 근데 그건 숙제를 시작했다는 뜻이지, 끝냈다는 뜻이 아니야.

2-1. TLS가 실제로 하는 일

TLS(Transport Layer Security)는 세 가지를 보장해:

① 기밀성(Confidentiality) — 중간에서 엿들어도 내용을 모름
② 무결성(Integrity) — 중간에서 바꾸면 들킴
③ 인증(Authentication) — 상대가 진짜 그 서버인지 확인

이 중에서 초보자들이 가장 우습게 보는 게 ③ 인증이야.
근데 사실 ③이 무너지면 ①②는 자동으로 무너져. 왜냐고?

공격자한테 암호화해서 보내는 건 그냥 친절하게 포장해서 배달하는 거니까.

2-2. TLS 핸드셰이크, 진짜 간단히

TLS 1.3 기준으로 이렇게 흘러가:

1) 클라이언트가 "나 이런 암호 스위트 지원해" + 키 교환용 공개값(ECDHE)을 보냄
2) 서버가 스위트를 고르고, 자기 공개값 + 인증서를 보냄
3) 클라이언트가 인증서 체인을 검증 (신뢰할 수 있는 CA가 서명했나? 도메인 맞나? 만료 안 됐나?)
4) 양쪽이 각자 세션키를 계산 — 세션키는 네트워크를 절대 지나가지 않음
5) 이후 모든 통신은 AES-GCM 등으로 암호화

2-3. 중간자 공격(MITM)이 실제로 일어나는 방식

MITM이 뭔지 감이 잘 안 오지? 실제 시나리오를 보자.

여기서 중요한 포인트. B 시나리오는 실제로 매일 일어나.
보안 연구자든, 리버싱하는 사람이든, 경쟁사 분석하는 사람이든 다 이 방법을 써.

2-4. 인증서 피닝(Certificate Pinning)

그래서 나온 게 피닝이야.
"나는 OS가 신뢰하는 CA 전부를 믿지 않겠다. 내가 지정한 이 인증서(또는 공개키)만 믿겠다"는 선언이지.

피닝에는 두 종류가 있어:

실무에선 SPKI 피닝이 정답이야. 그리고 반드시 백업 핀을 하나 더 넣어둬.

<!-- Android: res/xml/network_security_config.xml -->
<network-security-config>
    <!-- 전역: 평문 HTTP 전면 차단 -->
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>

    <domain-config>
        <domain includeSubdomains="true">api.myapp.com</domain>
        <pin-set expiration="2026-12-31">
            <!-- 현재 운영 인증서 공개키 -->
            <pin digest="SHA-256">base64PrimaryPinHere=</pin>
            <!-- 백업 키 (필수!) -->
            <pin digest="SHA-256">base64BackupPinHere=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

// Android: OkHttp로 피닝 (코드 레벨)
val pinner = CertificatePinner.Builder()
    .add("api.myapp.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
    .add("api.myapp.com", "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=") // backup
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(pinner)
    .connectTimeout(15, TimeUnit.SECONDS)
    .build()

2-5. iOS는 ATS가 지켜준다

iOS는 ATS(App Transport Security)가 기본으로 켜져 있어.
평문 HTTP는 기본 차단, TLS 1.2 이상 + Forward Secrecy 암호 스위트 + SHA-256 인증서를 요구해.

iOS 14부터는 Info.plist에서 피닝을 선언적으로 할 수도 있어:

<key>NSAppTransportSecurity</key>
<dict>
  <key>NSPinnedDomains</key>
  <dict>
    <key>api.myapp.com</key>
    <dict>
      <key>NSIncludesSubdomains</key><true/>
      <key>NSPinnedLeafIdentities</key>
      <array>
        <dict>
          <key>SPKI-SHA256-BASE64</key>
          <string>base64PinHere=</string>
        </dict>
      </array>
    </dict>
  </dict>
</dict>

2-6. 통신 보안 추가 체크포인트

· HSTS — 서버가 "나한테는 무조건 HTTPS로만 와"라고 선언하는 헤더. 웹뷰 쓸 때 특히 중요.
· Certificate Transparency — 잘못 발급된 인증서를 공개 로그로 탐지하는 체계. 지금은 사실상 필수.
· 토큰은 헤더로 — URL 쿼리스트링에 토큰 넣지 마. 서버 액세스 로그, 리퍼러, 브라우저 히스토리에 다 남아.
· 재생 공격 방어 — 중요 요청엔 타임스탬프 + nonce를 넣고 서버에서 검증.
· API 응답 최소화 — 필요 없는 필드는 아예 내려주지 마. 앱에서 숨기는 건 숨기는 게 아니야.

3. 보안 저장소 : 키를 어디에 둘 것인가

자, 이제 1장에서 미뤄뒀던 최종 보스가 나왔어.
"암호화 키를 어디에 보관할 것인가?"

이건 암호학에서 가장 오래되고 가장 어려운 문제야.
왜냐면 키를 보호하려면 또 다른 키가 필요하고, 그 키를 보호하려면 또… 무한 루프거든.

3-1. 절대 하면 안 되는 것들 (명예의 전당)

3-2. 하드웨어 보안의 세계 : TEE, SE, Secure Enclave

현대 스마트폰에는 메인 CPU와 물리적으로 분리된 보안 영역이 있어.

핵심 개념이 뭐냐면 — 키가 이 영역 밖으로 절대 나오지 않는다는 거야.

앱은 "이 데이터 암호화해줘"라고 요청만 하고, 결과만 받아.
키 자체는 만져볼 수도 없어. 심지어 루팅해도 못 꺼내.

이게 왜 대단하냐면, 기존 방식은 "키 파일을 잘 숨기기" 게임이었는데
이제는 "키가 애초에 소프트웨어 영역에 존재하지 않는" 구조가 된 거야. 게임의 룰이 바뀐 거지.

3-3. Android Keystore 실전

Android는 AndroidKeyStore라는 특수한 Provider를 제공해.
여기서 키를 만들면 키 원본(raw bytes)을 앱이 가져올 수 없어. 오직 Cipher 객체로 사용만 가능해.

// Android: 하드웨어 보안 키 생성
import android.security.keystore.KeyGenParameterSpec
import android.security.keystore.KeyProperties
import javax.crypto.KeyGenerator

fun createOrGetKey(alias: String): SecretKey {
    val ks = KeyStore.getInstance("AndroidKeyStore").apply { load(null) }
    (ks.getEntry(alias, null) as? KeyStore.SecretKeyEntry)?.let { return it.secretKey }

    val spec = KeyGenParameterSpec.Builder(
        alias,
        KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
    )
        .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
        .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
        .setKeySize(256)
        // 생체인증/화면잠금 해제 후에만 사용 가능
        .setUserAuthenticationRequired(true)
        .setUserAuthenticationParameters(30, KeyProperties.AUTH_BIOMETRIC_STRONG)
        // 새 지문이 등록되면 키 자동 무효화 (매우 중요)
        .setInvalidatedByBiometricEnrollment(true)
        .apply {
            // Android 9+ 전용 보안칩 사용 시도
            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) setIsStrongBoxBacked(true)
        }
        .build()

    val kg = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore")
    kg.init(spec)
    return kg.generateKey()
}

3-4. 봉투 암호화 (Envelope Encryption)

방금 나온 개념, 중요하니까 따로 설명할게. 실무 패턴의 핵심이거든.

DEK (Data Encryption Key) — 실제 데이터를 암호화하는 키. 랜덤 생성, 자주 교체 가능.
KEK (Key Encryption Key) — DEK를 암호화하는 키. Keystore/Enclave 안에 거주.

흐름은 이래:

1) 랜덤 DEK 생성 (메모리에만 존재)
2) DEK로 데이터 암호화 → 파일/DB에 저장
3) Keystore의 KEK로 DEK를 암호화(wrap) → 암호화된 DEK도 함께 저장
4) 메모리의 평문 DEK는 즉시 폐기

복호화할 땐 반대로 KEK로 DEK를 풀고, DEK로 데이터를 풀어.

왜 이렇게 번거롭게 하냐고?
키 교체(rotation)가 쉬워지기 때문이야.
KEK를 바꿔야 할 때 수십 GB의 데이터를 다시 암호화할 필요 없이, 작은 DEK만 다시 감싸면 끝나거든.

3-5. Jetpack Security와 그 이후

Android에는 EncryptedSharedPreferences, EncryptedFile이라는 편한 래퍼가 있었어.
내부적으로 Keystore + Tink를 써서 자동으로 암호화해주는 라이브러리지.

// androidx.security:security-crypto (Deprecated 상태 유의)
val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

val prefs = EncryptedSharedPreferences.create(
    context, "secure_prefs", masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)
prefs.edit().putString("refresh_token", token).apply()

3-6. iOS Keychain 실전

iOS의 Keychain은 OS가 관리하는 암호화된 데이터베이스야.
앱이 삭제돼도 남아있을 수 있고(설정에 따라), 아이클라우드 동기화도 선택 가능해.

Keychain에서 가장 중요한 건 접근성(Accessibility) 속성이야.

민감한 토큰이라면 ThisDeviceOnly 계열을 써야 해.
그래야 아이튠즈/아이클라우드 백업을 통해 다른 기기로 복원되지 않거든.

// Swift: Keychain 저장 + Secure Enclave 연동
import Security
import LocalAuthentication

func saveToken(_ token: Data, account: String) throws {
    // 생체인증 없이는 접근 불가하도록 ACL 설정
    var error: Unmanaged<CFError>?
    guard let access = SecAccessControlCreateWithFlags(
        nil,
        kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
        .biometryCurrentSet,   // 생체정보 변경 시 자동 무효화
        &error
    ) else { throw error!.takeRetainedValue() as Error }

    let query: [String: Any] = [
        kSecClass as String:            kSecClassGenericPassword,
        kSecAttrService as String:      "com.myapp.auth",
        kSecAttrAccount as String:      account,
        kSecValueData as String:        token,
        kSecAttrAccessControl as String: access
    ]

    SecItemDelete(query as CFDictionary)   // 중복 방지
    let status = SecItemAdd(query as CFDictionary, nil)
    guard status == errSecSuccess else { throw KeychainError.save(status) }
}

// Swift: Secure Enclave에 키 생성 (P-256, 추출 불가)
func createEnclaveKey(tag: String) throws -> SecKey {
    let access = SecAccessControlCreateWithFlags(
        nil,
        kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
        [.privateKeyUsage, .biometryCurrentSet],
        nil
    )!

    let attributes: [String: Any] = [
        kSecAttrKeyType as String:       kSecAttrKeyTypeECSECPrimeRandom,
        kSecAttrKeySizeInBits as String: 256,
        // 이 한 줄이 핵심: 키가 Secure Enclave 내부에서만 존재
        kSecAttrTokenID as String:       kSecAttrTokenIDSecureEnclave,
        kSecPrivateKeyAttrs as String: [
            kSecAttrIsPermanent as String:    true,
            kSecAttrApplicationTag as String: tag.data(using: .utf8)!,
            kSecAttrAccessControl as String:  access
        ]
    ]

    var error: Unmanaged<CFError>?
    guard let key = SecKeyCreateRandomKey(attributes as CFDictionary, &error) else {
        throw error!.takeRetainedValue() as Error
    }
    return key
}

3-7. 크로스플랫폼은 어떡하지?

React Native, Flutter 쓰는 친구들도 많지? 정리해줄게.

4. 실무에서 진짜 터지는 것들

이제 좀 더 실전적인 얘기를 해보자.
이론은 알겠는데 "그래서 뭐부터 고쳐야 하냐"가 궁금하잖아.

4-1. 인증 토큰 관리

모바일 앱에서 가장 많이 다루는 비밀은 인증 토큰이야.

Refresh Token Rotation + 재사용 탐지, 이 조합이 진짜 강력해.
공격자가 토큰을 훔쳐서 쓰면, 정상 사용자가 다음에 갱신할 때 "어? 이거 이미 쓴 토큰인데?" 하고 걸려.
그 순간 둘 다 로그아웃시키면 돼. 사용자는 불편하지만 계정은 지킨 거지.

4-2. 루팅 · 탈옥 탐지

루팅된 기기에서는 앱의 방어가 크게 약해져.
Frida 같은 도구로 런타임에 함수를 후킹해서 로직을 바꿀 수 있거든.

그래서 탐지를 하긴 하는데, 완벽한 탐지는 불가능하다는 걸 인정하고 시작해야 해.
탐지 코드를 우회하는 건 공격자 입장에서 그냥 또 하나의 단계일 뿐이야.

현실적인 접근
· 탐지되면 앱을 죽이지 말고 서버에 신호를 보내 위험 점수를 올린다
· 고위험 기능(송금, 결제)만 선택적으로 제한한다
· 최종 판단은 항상 서버에서 한다

Android는 Play Integrity API, iOS는 DeviceCheck / App Attest를 쓰면
플랫폼 차원의 무결성 증명을 서버가 검증할 수 있어. 자체 탐지 코드보다 훨씬 신뢰도가 높아.

4-3. 화면 보안

의외로 놓치기 쉬운 부분이야.

· 스크린샷 / 화면 녹화 차단 — Android는 WindowManager.LayoutParams.FLAG_SECURE
· 앱 전환 화면(Task Switcher) 가리기 — 백그라운드 진입 시 블러 뷰 오버레이
· 클립보드 — 비밀번호 필드는 복사 방지, 복사했다면 일정 시간 후 자동 삭제
· 키보드 캐시 — 민감 입력란은 textNoSuggestions / isSecureTextEntry

은행 앱 켤 때 앱 전환 화면이 뿌옇게 나오는 거, 그게 이 처리야.
별거 아닌 것 같지만 어깨너머 훔쳐보기(shoulder surfing)와 스크린샷 유출을 막아줘.

4-4. 난독화와 그 한계

Android는 R8/ProGuard, iOS는 컴파일러 최적화 + 서드파티 도구를 써.

# build.gradle — 릴리스 빌드 필수 설정
buildTypes {
    release {
        minifyEnabled true        // 코드 축소 + 난독화
        shrinkResources true      // 미사용 리소스 제거
        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'),
                      'proguard-rules.pro'
        debuggable false          // 절대 true로 두지 말 것
    }
}

난독화는 클래스/메서드 이름을 a, b, c로 바꾸는 것이 주 기능이야.
문자열 상수는 기본적으로 그대로 남아. 그래서 API 키를 숨기는 용도로는 부족해.

4-5. 딥링크와 웹뷰

이 둘은 앱의 "열린 문"이라서 신경 써야 해.

딥링크
· Android는 App Links(assetlinks.json 검증), iOS는 Universal Links를 써서 도메인 소유권 검증을 거쳐
· 커스텀 스킴(myapp://)은 다른 앱이 가로챌 수 있어서 민감한 용도로 부적합
· 딥링크 파라미터는 항상 검증. 그대로 URL 로딩하면 오픈 리다이렉트 취약점이 돼

웹뷰
· setJavaScriptEnabled(true)는 정말 필요할 때만
· setAllowFileAccess(false), setAllowFileAccessFromFileURLs(false)
· addJavascriptInterface는 네이티브 권한을 JS에 노출하니 극도로 주의
· 로드할 URL은 화이트리스트 검증 필수

4-6. 서드파티 SDK와 공급망

요즘 앱은 의존성이 수백 개야. 그중 하나만 악성이어도 끝이지.

· 의존성 최소화 — 기능 하나 때문에 거대 SDK 넣지 말기
· 버전 고정 — 1.2.+ 같은 동적 버전은 재현 불가능하고 위험
· 취약점 스캔 — OWASP Dependency-Check, GitHub Dependabot 등 자동화
· 권한 감사 — SDK가 요구하는 권한이 과한지 확인

5. 가장 중요한 원칙 하나

여기까지 왔으면 이제 이 말이 이해될 거야.

사용자의 손에 있는 앱은 사용자가 완전히 통제할 수 있어.
메모리를 읽을 수도, 함수를 바꿔치기할 수도, 네트워크를 조작할 수도 있어.

그래서 앱에서 하는 모든 검증은 "UX를 위한 힌트"일 뿐이야.
진짜 보안 결정은 100% 서버에서 다시 해야 해.

게임 업계에 유명한 말이 있어. "클라이언트를 믿으면 치터가 왕이 된다."
앱도 똑같아. 클라이언트를 믿으면 리버서가 왕이 되는 거지.

6. 배포 전 체크리스트

자, 실전 투입 직전에 한 번씩 훑어보는 리스트야.
프린트해서 모니터 옆에 붙여놔도 좋아.

암호화

통신

저장

빌드 & 운영

7. 마무리 : 보안은 문화다

여기까지 읽느라 고생했어. 진짜로.

마지막으로 하고 싶은 말은 이거야.
보안은 기능이 아니라 문화라는 것.

"보안 스프린트" 한 번 돌리고 끝나는 게 아니야.
새 기능 만들 때마다 "이거 누가 악용하면 어떻게 되지?"를 한 번씩 생각하는 습관,
그게 100줄짜리 보안 라이브러리보다 훨씬 강력해.

그리고 완벽한 보안은 세상에 없어.
목표는 "뚫리지 않는 앱"이 아니라 "뚫기엔 비용이 너무 큰 앱"이야.

공격자도 사람이고, 시간과 노력을 계산해.
얻을 것보다 들일 노력이 크면 다른 먹잇감을 찾아 떠나거든.

혹시 혼자 하기 버겁다면, 재능넷 같은 플랫폼에서
모바일 보안 리뷰나 펜테스트 경험이 있는 개발자에게 도움을 받는 것도 충분히 합리적인 선택이야.
사고 한 번 터지고 대응하는 비용에 비하면 비교도 안 되게 저렴하니까.

그럼 오늘도 안전한 코드 짜자. 화이팅! 🔐