TL;DR — 메타(Meta)는 수백만 라인의 안드로이드 코드베이스에서 발생하는 보안 취약점을 해결하기 위해 **기본 보안 프레임워크(Secure-by-Default Frameworks)**와 생성형 AI 기반 코드 수정(AI Codemods) 기술을 결합했습니다. 이를 통해 개발자의 개입을 최소화하면서도 안전하지 않은 OS API를 보안이 강화된 내부 API로 대규모 자동 마이그레이션하는 시스템을 구축했습니다. 배경과 문제 정의 수천 명의 엔지니어가 협업하고 수백만 라인의 코드가 복잡하게 얽힌 메타의 안드로이드 앱 환경에서, 단순한 API 업데이트조차 거대한 도전 과제가 됩니다. 특히 보안 관련 변경 사항은 더욱 까다롭습니다. ...
왜 지금 이게 문제인가 대규모 코드베이스에서 보안 취약점은 복리처럼 쌓인다. 메타(Meta)와 같은 빅테크가 수백만 라인의 안드로이드 코드를 관리할 때, 특정 API의 보안 허점 하나가 수천 개의 호출 지점(Call site)에 퍼져 있는 것은 흔한 일이다. 이를 사람이 일일이 수정하는 것은 불가능에 가깝고, 단순한 정규표현식 기반의 치환은 문맥을 놓쳐 런타임 에러를 유발하기 십상이다. 한국의 ‘네카라쿠배’나 대형 금융 앱 환경도 다르지 않다. 서비스가 고도화될수록 레거시 API는 도처에 깔리고, 보안 컴플라이언스 대응을 위해 수천 개의 클래스를 전수 조사해야 하는 상황이 빈번하게 발생한다. 개발자는 비즈니스 로직 개발보다 보안 패치와 라이브러리 마이그레이션 같은 반복 작업에 더 많은 에너지를 소모하게 된다. ...
광고 랭킹 모델처럼 거대하고 복잡한 머신러닝(ML) 시스템을 운영하다 보면, 엔지니어의 시간 중 상당 부분이 실험 가설 수립, 학습 작업(Training Job) 모니터링, 로그 분석, 그리고 인프라 장애 대응에 소모된다는 것을 알 수 있습니다. 메타(Meta)가 공개한 랭킹 엔지니어 에이전트(Ranking Engineer Agent, 이하 REA)는 이러한 반복적인 ML 실험 사이클을 자율적으로 수행하여 엔지니어링 생산성을 5배 이상 끌어올린 사례를 보여줍니다. 단순히 코드를 짜주는 보조 도구를 넘어, 며칠에서 몇 주씩 걸리는 긴 호흡의 실험 과정을 스스로 관리하는 자율형 에이전트의 구조와 실무적 시사점을 정리했습니다. ...
메타 메신저의 종단간 암호화(E2EE) 환경에서 사용자의 개인정보를 보호하면서도 악성 링크를 사전에 차단하는 기술적 메커니즘인 고급 브라우징 보호(Advanced Browsing Protection, ABP)의 핵심 설계 원칙을 분석한다. 서버가 사용자가 어떤 링크를 클릭했는지 알 수 없게 하면서도 수백만 개의 유해 사이트 목록과 대조하는 이 기술은 프라이버시와 보안이라는 상충하는 가치를 공존시키려는 시도다. 한 줄 요약 — 메타 메신저는 프라이빗 정보 검색(PIR)과 규칙 기반 버킷팅 기술을 활용해 서버에 사용자 데이터를 노출하지 않고도 실시간으로 악성 링크를 탐지한다. ...
왜 지금 이게 문제인가 “GPT-4를 그냥 API로 쓰면 되지 않나?” 많은 기업이 이 질문에서 출발하지만, 넷플릭스는 다른 답을 내렸다. 범용 LLM은 넷플릭스의 콘텐츠 카탈로그, 추천 알고리즘, 사용자 행동 패턴을 모른다. “이 영화가 한국 30대 남성에게 왜 매력적인가"를 GPT-4에게 물어봐야 일반론만 돌아온다. 넷플릭스 AI 플랫폼 팀은 범용 모델을 가져다가 자사 데이터로 **Post-Training(사후 학습)**하는 내부 프레임워크를 구축했다. 이는 단순한 파인튜닝을 넘어, 프로덕션에서 추천·검색·개인화에 직접 투입되는 모델을 대규모로 생산하는 LLM 공장이다. API 의존의 한계: 외부 LLM API는 자사 데이터로 학습되지 않았고, 모델 업데이트 시점을 통제할 수 없으며, 민감한 사용자 데이터를 외부로 보내야 한다. 넷플릭스 규모에서 이 세 가지는 모두 수용 불가능하다. 파인튜닝의 인프라 복잡성: 수십~수백 대의 GPU 노드에서 분산 학습을 돌리는 것은 모델 코드를 짜는 것보다 10배 어렵다. 노드 하나가 죽으면 수일간의 학습이 날아가고, 체크포인팅은 네트워크 대역폭을 잡아먹으며, GPU 메모리 관리는 악몽이다. 한국적 맥락: 쿠팡, 토스, 카카오 같은 데이터 기반 서비스가 “우리만의 LLM을 만들어야 하나"를 고민 중이다. 넷플릭스의 사례는 Pre-training(처음부터 학습)이 아닌 Post-Training(기존 모델 위에 학습)이라는 현실적 경로를 보여준다. 어떻게 동작하는가 넷플릭스의 Post-Training Framework는 세 개의 레이어로 구성된다. ...
왜 지금 이게 문제인가 “PostgreSQL은 스타트업 DB 아닌가?” 많은 한국 개발자들이 대규모 트래픽을 언급할 때 당연하게 NoSQL이나 NewSQL을 먼저 떠올린다. 그런데 세계에서 가장 폭발적으로 성장한 서비스인 ChatGPT가 단일 PostgreSQL 프라이머리 인스턴스를 핵심 데이터 저장소로 사용하고 있다는 사실은 업계의 통념을 정면으로 뒤집는다. OpenAI는 1년 만에 트래픽이 10배 증가하는 상황에서도 PostgreSQL을 포기하지 않았다. 대신 약 50대의 읽기 복제본(Read Replica)을 배치하고, 쓰기 부하가 큰 워크로드만 선별적으로 CosmosDB로 분리하는 전략을 택했다. 결과는 p99 레이턴시 두 자릿수 밀리초, 가용성 99.999%. ...
왜 지금 이게 문제인가 전 세계 인터넷 트래픽의 약 20%가 Cloudflare를 경유한다. 이 거대한 트래픽을 처리하는 핵심 프록시가 NGINX + LuaJIT 조합(내부 코드명 FL1)으로 10년 이상 운영되어 왔다. 그리고 Cloudflare는 이것을 **Rust로 완전히 재작성(FL2)**하는 데 성공했다. “동작하는 코드를 왜 다시 짜는가?“라는 질문에 대한 답은 명확하다. 메모리 안전성의 한계: C/C++ 기반의 NGINX는 버퍼 오버플로우, Use-after-free 같은 메모리 취약점의 온상이다. 보안 회사가 자체 프록시에서 메모리 버그를 내는 것은 존재론적 위협이다. 확장성의 벽: NGINX의 모놀리식 구조 위에 LuaJIT으로 비즈니스 로직을 붙이는 방식은 기능이 늘어날수록 유지보수가 기하급수적으로 어려워졌다. 새 기능 하나를 추가하려면 Lua, C, 설정 파일 세 곳을 동시에 건드려야 했다. 성능 천장: LuaJIT의 GC(가비지 컬렉션)가 예측 불가능한 레이턴시 스파이크를 일으켰고, NGINX의 스레딩 모델은 현대적인 비동기 I/O 패턴과 맞지 않았다. Cloudflare의 재작성은 “Rust가 좋으니까"가 아니라, 기존 시스템의 기술적 부채가 사업적 리스크가 되는 시점에서 내린 결정이다. 100명 이상의 엔지니어가 130개 이상의 모듈을 작성하여 점진적으로 트래픽을 이관한, 대규모 시스템 마이그레이션의 교과서적 사례다. ...