3편까지는 어떤 크래시가 있고 어떻게 막는지를 다뤘다.그런데 운영 중 더 자주 부딪히는 건 이미 크래시가 난 상태에서 원인을 찾는 일이다.특히 막막한 시나리오가 있다.release 빌드, 사용자 단말, Crashlytics에서 받은 native 크래시 로그, 심볼은 stripped 상태.손에 있는 건 이렇게 생긴 시그널 번호와 fault 주소, 그리고 주소만 찍힌 backtrace뿐이다.signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0backtrace: #00 pc 0000000000041a70 /system/lib64/libc.so #01 pc 00000000000123bc /data/app/com.example/lib/arm64/libnat..

얼마 전 운영중인 앱이 native 코드 문제로 런타임에 죽었다.버퍼를 다루는 함수였다.Ghidra로 디스어셈블해 들어가다 __stack_chk_fail 호출 경로를 발견했다.스택 카나리가 buffer overflow를 잡아 죽인 거였다.크래시는 한 곳에서 막는 게 아니라 여러 층에서 걸러진다.카나리가 잡은 건 그중 한 층이었다.이번 편은 나도 공부하면서 그 층들을 정리해본다.미리 말하자면, 이번 편은 가볍게 읽고 넘어가도 된다. 이유는 이 것들을 본 순간 이미 당신의 앱은 죽어있다.본론으로 들어가, 2편에서 본 크래시들(SIGSEGV, SIGABRT, SIGBUS 등)을 막는 방어는 세 층으로 나뉜다.1층은 컴파일러와 런타임이 자동으로 해주는 것. NDK 빌드 시 이미 켜져 있음.2층은 도구로 잡는 것..

native 크래시를 처음 만났을 때 가장 막막했던 건 어디서 났는지가 안 보인다는 점이었다.Java/Kotlin이었으면 NullPointerException이 어느 파일 몇 번 라인에서 났는지 stack trace에 다 찍힌다.native는 signal 11 (SIGSEGV) 같은 시그널 번호와 메모리 주소만 있었다.NDK 코드를 직접 안 짜도 이 로그는 만난다.의존하는 라이브러리가 내부적으로 native면 거기서 터진 게 시그널로 올라온다.이번 편은 그 시그널 종류를 정리해본다.시그널이 뭔지부터native 크래시는 전부 시그널로 옴.그래서 시그널이 뭔지부터 봄.시그널은 Unix 계열 OS가 프로세스에게 뭔가 잘못됐다고 알리는 메커니즘임.Android도 Linux 기반이라 같은 메커니즘을 씀.nativ..

요새 온디바이스 AI 작업을 하고 있다.모델 추론 코드를 iOS와 Android에서 공용으로 쓰려고 native 모듈로 빼는 중.HAL 쪽도 native가 필요.오랜만에 NDK를 다시 만지다 보니 한동안 잊고 있던 것들이 다시 보였다.그래서 정리해봤다. 이번 편은 NDK를 왜 쓰는지, Java/Kotlin과 뭐가 다른지까지이다.NDK를 왜 쓰는가대부분의 Android 개발은 NDK 없이 끝남.화면 그리고 네트워크 호출하고 데이터 다루는 데는 Java/Kotlin만으로 부족함이 없음.그러다 어느 시점에 NDK가 강제되는 상황을 만남.보통 네 가지 중 하나임.첫째는 성능. AI 모델 추론, 미디어 인코딩/디코딩, 암호화 같은 무거운 연산은 JVM 위에서 한계가 있음. TensorFlow Lite, ONNX ..

Play Console에 빨간 경고가 떴음."데이터 수집 안 하는데 왜?"라는 생각부터 들었음.결론부터 말하면 내가 안 해도 SDK가 함.AdMob 하나 붙인 앱이 데이터 보안 선언에서 데이터 유형 네 개를 채우게 된 과정을 정리함.Play Console에 5월 28일까지 조치하라는 경고 알림이 와 있었음.경고 내용은 "사용자 데이터를 수집하거나 공유하는 앱은 데이터 보안 선언에서 모든 데이터 유형을 선언해야 한다"였음.셀카픽은 기기 안의 사진을 점수 매겨 베스트샷을 골라주는 앱임. 서버도 회원가입도 없고 사진을 외부로 보내지도 않음.경고 내용에 단서가 있었음: "데이터 보안(기기 또는 기타 ID 선언되지 않음)"Google Play에 운영 해본 개발자라면 알겠지만, 정책 갱신에도 2, 3일은 족히 걸림..

Google Play Console에서 Android 개발자 인증 관련 메일이 왔다. 2025년 8월에 발표된 제도가 Play Console에 실제 등록 UI로 열렸길래, 앱 개발자 입장에서 뭘 해야 하는지만 추려서 정리했다.핵심 3줄2026년 9월부터 브라질·싱가포르·인도네시아·태국에서는 등록 안 된 앱은 인증 안드로이드 기기에 설치할 수 없다. 한국 포함 나머지는 2027년 이후.Play 스토어에만 배포하면 자동 등록이라 거의 할 게 없다.Play 외부(사이드로딩·제3자 스토어)로도 배포한다면 직접 등록해야 한다.왜 이 제도가 생겼나 (짧게)Google 발표문은 "Play 외부 사이드로딩 소스의 멀웨어가 Play 대비 50배 이상"이라는 숫자를 근거로 든다. 이 격차의 상당 부분은 Play의 권한 심..

1편에서 양자화로 모델을 92% 줄였고, 2편에서 프루닝과 지식 증류까지 실험해봤다. 경량화는 끝났다.그러면 주제인 온디바이스는?Python에서 77.88% 나온 INT8 모델이 Android 단말에서도 같은 정확도와 속도를 낼지, 직접 올려봤다.프레임워크 선택내가 고른 건 LiteRT(구 TensorFlow Lite)다. 이유는 단순했다. 학습을 Keras로 했으니 변환이 .tflite 한 번으로 끝나고, INT8 양자화된 모델을 그대로 들고 올 수 있고, GPU Delegate까지 바로 붙는다. 선택이라기보다는 기본값이었다.선택지를 비교하긴 했다. Android 모바일 배포에서는 LiteRT / ONNX Runtime / ExecuTorch 셋이 주로 꼽힌다.구분LiteRTONNX RuntimeExe..

지난번에 INT8 양자화로 크기를 92% 줄여봤다. INT8로 바꾸니까 크기 75% 줄고, 속도 4배 빨라지고, 정확도는 그대로였다. 너무 잘 돼서 의심스러울 정도였다.그래서 다른 경량화 기법도 해보기로 했다. 프루닝이랑 지식 증류. 둘 다 이름은 많이 들어봤는데 직접 해본 적은 없었다.결론부터 말하면, 양자화만큼 쉽지 않았다. 프루닝은 50%를 날리고도 오히려 느려졌고, 지식 증류는 정확도 13%p를 내줬다. 두 기법이 왜 교과서대로 안 가는지, 그리고 그럼 언제 써야 하는지 정리했다.프루닝: 불필요한 가중치 잘라내기프루닝은 별거 없다. 딥러닝 모델의 가중치 중에서 값이 작은 것들은 결과에 별로 영향을 안 준다. 그러니까 그냥 0으로 만들어버리자. Pruning이라는 단어 자체가 "가지치기"라는 뜻이다..

작년부터 온디바이스 AI에 관심이 많았다. 딥페이크 탐지 프로젝트에서 모델을 단말에 올리려고 경량화를 시도해봤고, 보이스피싱 탐지는 Qwen 경량 모델까지 써봤지만 온디바이스를 목표로 한 연구 단계에서 멈췄다. 하드웨어 제약이 너무 컸다. 딥페이크 쪽은 결국 클라우드로 돌렸다.그때 양자화, 프루닝, 지식 증류를 직접 실험해봤다. 어디까지 줄일 수 있는지, 정확도는 얼마나 버틸 수 있는지 확인하고 싶었다.당시엔 정리만 해두고 글로 올리진 않았다.그런데 최근에 상황이 바뀌었다. 구글이 온디바이스용 경량 모델 Gemma 4(E2B/E4B)를 내놓고, KV 캐시를 6배 압축하는 TurboQuant까지 발표했다. 경량화가 다시 화두다.그때 정리해둔 걸 공유해보려 한다. 이번 글은 양자화다.양자화가 뭔데숫자 정밀도..

내가 만든 MCP 서버는 AI가 보내는 파라미터를 검증하고 있을까?코드를 열어봤다. 하나도 안 하고 있었다.nworks는 LINE WORKS API를 CLI와 MCP(Model Context Protocol) 서버로 감싸는 도구다.v1.1.0에서 기능은 거의 완성됐고, 다국어 README 정리하고 Glama에 등록하면서 마무리하는 중이었다.그 즈음 별도로 MCP 보안 프록시를 설계하고 있었다. MCP 프로토콜의 보안 구조를 조사하면서 공격 표면들을 정리하는데, 자연스럽게 의문이 들었다. 내가 만든 nworks는 괜찮은가?괜찮지 않았다.먼저 — AI가 secret을 받으면 안 된다본격적인 보안 패치 전에 구조적으로 잘못된 게 하나 있었다.v1.1.0까지 nworks_setup 도구는 clientSecret..