Airbnb / kotlin

2 개의 포스트

airbnb

GraphQL Data Mocking at Scale with LLMs and @generateMock (새 탭에서 열림)

에어비앤비는 LLM과 제품 컨텍스트를 결합한 `@generateMock` 지시어를 도입하여, 수동으로 작성하던 GraphQL 모의 데이터 생성 과정을 자동화하고 혁신했습니다. 이 시스템은 단순한 랜덤 값 생성을 넘어 쿼리 정의, 스키마 주석, 그리고 디자인 목업 이미지까지 컨텍스트로 활용해 실제 서비스 환경과 매우 흡사한 타입 안정적(Type-safe) 데이터를 생성합니다. 이를 통해 개발자는 백엔드 구현을 기다리지 않고도 고품질의 데모와 테스트를 수행할 수 있으며, 쿼리 변경에 따른 모킹 데이터의 관리 부담을 획기적으로 줄였습니다. ### 기존 모킹 방식의 한계와 도전 과제 * **수동 작업의 비효율성:** 수백 줄에 달하는 GraphQL 쿼리에 대응하는 JSON 데이터를 직접 작성하고 수정하는 과정은 매우 번거롭고 실수에 취약합니다. * **병렬 개발의 병목:** 서버 스키마가 확정된 후에도 실제 API가 구현될 때까지 클라이언트 개발자는 UI 테스트를 진행하기 어려워 임시방편(하드코딩, 로컬 프록시 등)에 의존하게 됩니다. * **데이터의 동기화 문제:** 쿼리나 스키마가 진화함에 따라 수동으로 작성된 모의 데이터는 점차 실제 프로덕션 환경과 괴리가 생기며, 이는 테스트 신뢰도 저하로 이어집니다. ### @generateMock 지시어를 통한 선언적 모킹 * **지시어 기반 워크플로우:** 개발자는 `.graphql` 파일의 연산, 프래그먼트, 또는 특정 필드에 `@generateMock` 지시어를 추가하는 것만으로 모의 데이터를 정의할 수 있습니다. * **주요 파라미터 활용:** * `id`: 여러 버전의 모의 데이터를 생성할 때 식별자로 사용하며, 생성된 헬퍼 함수의 이름에 반영됩니다. * `hints`: "파리, 교토로 가는 여행 일정을 포함해달라"와 같이 LLM에게 구체적인 데이터 생성을 지시하는 자연어 가이드를 제공합니다. * `designURL`: 디자인 도구(Figma 등)의 URL을 입력하면 LLM이 실제 디자인 화면의 텍스트와 레이아웃에 부합하는 데이터를 생성합니다. * **로컬 개발 도구 통합:** 에어비앤비의 코드 생성 도구인 'Niobe'와 결합되어, 코드 생성 시 JSON 데이터와 이를 로딩하는 소스 코드(TypeScript, Swift, Kotlin)가 자동으로 빌드 아티팩트에 포함됩니다. ### LLM을 활용한 컨텍스트 중심의 데이터 생성 * **스키마 최적화 주입:** 전체 스키마를 LLM에 전달하는 대신, 해당 쿼리와 연관된 타입 및 인라인 문서 주석만을 추출하여 컨텍스트 윈도우 내에서 효율적으로 처리합니다. * **디자인 시각 정보 반영:** 내부 API를 통해 `designURL`의 스냅샷 이미지를 생성하고 이를 LLM에 전달함으로써, 실제 UI 디자인에 명시된 이름, 주소 등의 콘텐츠와 일치하는 현실적인 데이터를 얻습니다. * **수동 수정 및 보존:** 생성된 JSON 데이터는 개발자가 직접 수정할 수 있으며, 이후 다시 코드를 생성하더라도 Niobe는 사용자가 직접 수정한 내용을 지우지 않고 보존하는 지능적인 병합 기능을 제공합니다. 이러한 접근 방식은 단순히 더 나은 가짜 데이터를 만드는 것을 넘어, 프론트엔드와 백엔드 간의 의존성을 분리하고 개발 생산성을 극대화하는 데 목적이 있습니다. 대규모 GraphQL 환경을 운영하는 조직이라면 스키마 메타데이터와 LLM을 결합하여 테스트 자동화 수준을 한 단계 높이는 이 모델을 참고할 가치가 있습니다.

airbnb

Migrating Airbnb’s JVM Monorepo to Bazel (새 탭에서 열림)

에어비앤비는 4.5년에 걸쳐 수천만 라인의 Java, Kotlin, Scala 코드로 구성된 대규모 JVM 모노레포를 Gradle에서 Bazel로 성공적으로 이전했습니다. 이번 마이그레이션을 통해 빌드 속도는 3~5배, IDE 동기화 및 배포 속도는 2~3배 향상되었으며, 개발자 만족도(CSAT)가 38%에서 68%로 크게 올랐습니다. Bazel의 밀폐성(Hermeticity)과 원격 실행 기능을 활용하여 대규모 코드베이스에서도 안정적이고 확장 가능한 빌드 시스템을 구축한 것이 핵심 성과입니다. **Gradle에서 Bazel로 전환한 이유** * **빌드 속도의 혁신:** Bazel의 원격 빌드 실행(RBE)을 통해 수천 개의 작업을 병렬로 처리하며, 'Build without the Bytes' 기능을 도입하여 필요한 아티팩트만 다운로드함으로써 대역폭 소모를 줄였습니다. * **빌드 안정성 및 밀폐성:** Gradle과 달리 샌드박스 환경을 제공하여 빌드 작업이 지정된 입력 외의 파일 시스템(예: /tmp 디렉토리)에 접근하는 것을 차단하고, 환경 차이로 인한 빌드 실패를 방지했습니다. * **통일된 인프라 구축:** 에어비앤비 내의 웹, iOS, Python, Go 등 다양한 언어의 레포지토리를 Bazel로 단일화하여 원격 캐싱, 로깅, 변경된 타겟 계산 로직을 공유할 수 있게 되었습니다. **단계적 마이그레이션과 개념 증명(PoC)** * **Viaduct 플랫폼 선정:** 에어비앤비에서 가장 크고 복잡한 서비스 중 하나인 GraphQL 모놀리스 'Viaduct'를 첫 타겟으로 선정하여, 가장 까다로운 케이스에서 성능 이점을 증명했습니다. * **공존 전략:** 초기에는 개발자가 Gradle과 Bazel 중 선택해서 사용할 수 있도록 두 시스템을 병렬로 운영하여 서비스 중단 위험을 최소화했습니다. * **개발자 설득:** 단순한 성능 향상을 넘어, 초기 단계에서 발생한 버그와 통합 문제를 해결하여 개발자들이 자발적으로 Bazel을 선택하도록 유도했습니다. **자동 빌드 파일 생성 및 유지보수** * **커스텀 생성기 개발:** Bazel 빌드 파일(BUILD)을 수동으로 관리하는 불편을 줄이기 위해 소스 코드의 패키지와 임포트 구문을 분석하여 의존성 그래프를 그리는 자동 생성기를 구축했습니다. * **Gazelle의 영감:** Go 언어의 Gazelle 도구에서 아이디어를 얻었으나, JVM 언어의 특성과 성능 요구사항을 맞추기 위해 캐싱 기능을 포함한 자체 도구로 발전시켰습니다. * **CI 통합:** 모든 커밋 전에 자동 생성기를 실행하여 Gradle과 Bazel의 빌드 그래프가 항상 일치하도록 유지했습니다. **IDE 사용자 경험 개선** * **IntelliJ 동기화 최적화:** 대규모 모노레포에서 Gradle 동기화가 최대 40분까지 소요되던 문제를 Bazel의 병렬 분석과 'Query Sync(실험적 기능)' 도입을 통해 3~10분 수준으로 단축했습니다. * **IntelliJ Aspect 활용:** Bazel의 Aspect 기능을 사용하여 프로젝트 구조 정보를 추출함으로써 IDE가 소스 코드와 의존성을 더 효율적으로 이해하도록 돕습니다. **성공적인 전환을 위한 교훈** 대규모 마이그레이션에서 가장 중요한 것은 **성능에 대한 집착**과 **개발자 경험(DevEx)에 대한 투자**입니다. 빌드 속도가 빨라지면 개발자들은 자연스럽게 새로운 도구를 수용하게 되며, 특히 IntelliJ와 같은 IDE와의 매끄러운 통합이 프로젝트의 성패를 좌우합니다. 또한 빌드 파일 생성과 같은 반복적인 작업을 자동화하여 개발자가 시스템 환경 설정이 아닌 코드 작성에만 집중할 수 있는 환경을 조성하는 것이 필수적입니다.