meta·2026년 3월 13일원문

패치 미 이프 유 캔: 기본부터 안전한 안드로이드 앱을 위한 AI 코드모드 (새 탭에서 열림)

Meta는 수백만 줄의 코드와 수천 명의 엔지니어가 얽혀 있는 대규모 환경에서 모바일 보안 취약점을 효율적으로 해결하기 위해 '기본 보안 기반(Secure-by-default)' 프레임워크와 생성형 AI를 결합한 전략을 채택했습니다. 잠재적으로 위험할 수 있는 Android OS API를 안전한 프레임워크로 감싸 개발자가 자연스럽게 보안 경로를 선택하게 유도하고, 기존의 방대한 레거시 코드는 AI를 통해 자동으로 마이그레이션하는 것이 핵심입니다. 이 시스템을 통해 Meta는 엔지니어의 개입을 최소화하면서도 수십억 명의 사용자를 보호할 수 있는 대규모 보안 패치를 성공적으로 수행하고 있습니다. ### 대규모 모바일 환경의 보안 한계와 과제 * 수백만 줄의 코드와 수천 명의 엔지니어가 협업하는 환경에서는 단순한 API 업데이트조차 막대한 리소스가 소요되는 작업이 됩니다. * 특히 모바일 보안의 경우, 특정 유형의 취약점이 수많은 앱 코드 곳곳에 반복적으로 나타나기 때문에 이를 수동으로 일일이 수정하는 것은 불가능에 가깝습니다. * 빌리언(Billion) 단위의 사용자를 보유한 다수의 앱을 운영하면서 일관된 보안 수준을 유지하는 것이 가장 큰 엔지니어링 도전 과제입니다. ### '기본 보안 기반(Secure-by-default)' 프레임워크 구축 * 취약할 가능성이 있는 Android OS API를 직접 사용하는 대신, 보안 기능이 내장된 래퍼(Wrapper) 프레임워크를 설계했습니다. * 개발자가 보안 지식이 부족하더라도 가장 쉽고 직관적으로 사용할 수 있는 구현 방식이 곧 가장 안전한 경로가 되도록 인터페이스를 최적화했습니다. * 프레임워크 수준에서 보안을 강제함으로써 개발 단계에서 발생할 수 있는 보안 실수를 원천적으로 차단합니다. ### 생성형 AI를 통한 대규모 코드 마이그레이션 자동화 * 새로운 보안 프레임워크를 도입하더라도 기존의 방대한 레거시 코드를 전환하는 데 따르는 비용을 절감하기 위해 생성형 AI 기술을 활용합니다. * AI가 기존 코드를 분석하여 보안 패치를 자동으로 제안하고, 이를 검증하여 실제 코드베이스에 적용하는 워크플로우를 구축했습니다. * 이를 통해 코드 소유자인 엔지니어의 업무 부담을 최소화하면서도 전체 시스템의 보안 기술 부채를 빠르게 해소할 수 있게 되었습니다. 대규모 서비스를 운영하는 기업이라면 보안 문제를 개별 개발자의 주의력에 맡기기보다, 프레임워크를 통해 '보안이 쉬운 환경'을 만들고 생성형 AI로 전환 비용을 낮추는 Meta의 전략을 참고할 수 있습니다. 특히 자동화된 보안 패치 시스템은 대규모 인프라를 관리하는 보안 팀에게 강력한 효율성을 제공할 것입니다.

code-migration생성형 AI자동화API 설계+3

figma·2020년 12월 16일·4분 읽기큐레이션 요약

피그마 내부 이야기: 엄

Figma는 TypeScript의 `strictNullChecks`를 도입해 `null`·`undefined`로 인한 런타임 오류를 컴파일 단계에서 줄이고 코드 유지보수성을 높였다. 약 1,162개 파일과 4,000개 이상의 오류가 있는 대규모 코드베이스였지만, 제품 개발을 중단하지 않고 파일 단위의 점진적 허용 목록 방식으로 마이그레이션했다. 이 사례는 기존 코드베이스의 타입 안전성을 높일 때 전면 전환보다 점진적이고 지속 가능한 전략이 효과적임을 보여준다. ## `strictNullChecks`가 해결하는 문제 - 기본 TypeScript 설정에서는 대부분의 값이 `null`이 될 수 있어 다음과 같은 대입이 허용된다. ```ts var v: Vector = { x: 1, y: 2 } v = null ``` - `strictNullChecks`를 활성화하면 `null`을 허용하는 타입을 명시적으로 선언해야 한다. ```ts var nullableVector: Vector | null = { x: 1, y: 2 } nullableVector = null ``` - 컴파일러는 제어 흐름 분석을 통해 값이 `null`인지 확인한 뒤 안전하게 사용할 수 있는지 검사한다. - `if (v)` 같은 조건문을 통과하면 `v`의 타입을 `Vector | null`에서 `Vector`로 좁혀, 안전하지 않은 프로퍼티 접근을 방지한다. - 그 결과 `cannot access .name of undefined`와 같은 오류를 컴파일 단계에서 발견할 수 있다. ## 오류 감소와 코드 유지보수성 향상 - Figma의 과거 장애 데이터에 따르면, 심각도가 높은 일부 프로덕션 장애는 strict null checks를 적용했다면 배포 전에 발견할 수 있었다. - 타입에 `null` 가능성이 명시되면 “이 시점에 파일 정보가 로드되어 있는가?” 같은 질문에 코드 자체가 답을 제공한다. - 함수가 `Vector`만 받는지, `Vector | null`도 받을 수 있는지 타입으로 명확히 표현할 수 있다. - null 처리 로직이 암묵적인 관례가 아니라 타입 시스템에 드러나므로 코드 이해와 변경이 쉬워진다. ## 대규모 레거시 코드베이스의 난점 - Figma는 TypeScript 2.0에서 `strictNullChecks`가 도입되기 전에 TypeScript를 사용하기 시작했다. - 기존 JavaScript 코드에 타입을 점진적으로 추가한 프로젝트에서는 null이 기본적으로 허용되는 경우가 많다. - 설정을 한 번에 켜자 약 1,162개 TypeScript 파일에서 4,000개 이상의 오류가 발생했다. - 한 오류를 수정하면 그 수정으로 인해 새로운 오류가 드러나는 연쇄적인 문제가 있었다. - 마이그레이션 중 코드베이스도 376,000줄에서 464,000줄로 증가했기 때문에, 일반적인 개발을 멈추지 않는 전략이 필요했다. ## 전면 중단 방식의 한계 - 모든 엔지니어가 기존 업무를 멈추고 마이그레이션에 참여하는 방식이다. - 마이그레이션 작업은 병렬화에 한계가 있어 모든 인력을 투입해도 효율적이지 않다. - 당시 제품 개발을 중단하면 사업 모멘텀을 잃을 수 있었다. - 조직과 팀 규모가 커질수록 여러 팀의 업무를 동시에 조정하기도 어려워진다. ## 오류를 장기간 병행 수정하는 방식의 한계 - strict null checks를 실제 빌드 규칙으로 활성화하지 않고 CI에서만 오류를 점진적으로 수정하는 방식이다. - 기존 개발 흐름을 거의 방해하지 않는다는 장점이 있다. - 그러나 강제되지 않는 상태에서는 새 코드가 계속 오류를 추가할 수 있다. - 오류를 수정하는 속도보다 새 오류가 생기는 속도가 빠르면 전체 진척도가 오히려 후퇴한다. - Figma는 이러한 방식이 오류를 줄이는 속도가 오류 유입 속도보다 빠를 때만 적절하다고 평가했다. ## 파일 단위의 점진적 허용 목록 - Figma가 선택한 방식은 strict null checks를 통과한 파일을 허용 목록에 하나씩 추가하는 것이다. - 코드베이스를 두 번 컴파일한다. - 전체 파일은 기존처럼 strict null checks 없이 컴파일한다. - 허용 목록에 포함된 파일은 strict null checks를 켠 상태로 컴파일한다. - 이를 통해 마이그레이션이 완료된 파일은 엄격한 타입 검사를 받으면서도, 아직 수정되지 않은 파일은 기존 개발 흐름을 유지할 수 있다. - Figma는 VS Code 팀의 유사한 마이그레이션 도구에서 출발해 자체 코드베이스의 특성에 맞게 확장했다. - 이 전략은 제품 개발을 중단하지 않고도 마이그레이션 진행 상황을 명확히 관리할 수 있게 한다. 기존 TypeScript 프로젝트에 strict null checks를 도입할 때는 설정을 한 번에 켜기보다, 파일·모듈 단위의 허용 목록과 별도 컴파일 구성을 활용하는 것이 현실적이다. 특히 새 코드가 계속 추가되는 조직에서는 “언젠가 고치기”보다 통과한 영역을 즉시 엄격한 규칙으로 보호하는 방식이 효과적이다.

원문 읽기(새 탭에서 열림)

code-migrationTypeScriptJavaScriptstrict-null-checks+1