소개
GraphQL을 사용한 테스트 및 프로토타입 제작을 위한 유효하고 현실적인 mock 데이터를 생성하는 것은 수년간 업계 전반에 걸쳐 지속적인 과제였습니다. Mock 데이터는 작성하고 유지 관리하기 번거롭고, 임의 값 생성 및 필드 수준 스터빙과 같은 프로세스 개선 시도는 테스트 데이터를 현실적이고 의미 있게 만드는 데 필요한 중요한 도메인 컨텍스트가 부족하여 실패합니다. 이 수동 작업에 소요되는 시간은 궁극적으로 대부분의 엔지니어가 집중하고 싶어하는 기능 구축 시간을 빼앗습니다.
이 게시물에서는 Airbnb가 GraphQL 유효성 검사, 풍부한 제품 및 스키마 컨텍스트, LLM을 결합하여 설득력 있고 타입 안전한 mock 데이터를 생성하고 유지 관리함으로써 GraphQL 데이터를 mocking하는 방식을 어떻게 재구상했는지 살펴보겠습니다. 우리 솔루션은 엔지니어가 모든 작업, fragment 또는 필드에 추가할 수 있는 간단한 새로운 GraphQL 클라이언트 지시문인 @generateMock을 중심으로 합니다. 이 접근 방식은 엔지니어가 쿼리가 진화함에 따라 수동으로 mock을 작성하고 유지 관리할 필요성을 없애 제품 구축에 집중할 시간을 확보합니다.
주요 과제
Airbnb 제품 엔지니어와의 미팅 및 내부 설문 조사 결과를 분석한 후 GraphQL mocking에 대한 가장 일반적인 문제점을 세 가지 주요 과제로 요약했습니다.
이러한 문제는 Airbnb에만 국한된 것이 아니라 업계 전반에서 흔히 발생합니다. 임의 값 생성기 및 로컬 필드 리졸버와 같은 도구가 약간의 지원을 제공할 수 있지만 고품질 데모, 빠른 제품 반복 및 안정적인 테스트를 위한 현실적이고 의미 있는 데이터를 생성하는 데 필요한 도메인 지식과 컨텍스트가 부족합니다.
목표
Airbnb에서 이러한 문제를 해결하기 위해 세 가지 핵심 목표를 설정했습니다.
@generateMock: 스키마 + 컨텍스트 + LLM = 마법
엔지니어를 로컬 포커스 루프에 유지하면서 mock 데이터를 생성하기 위해 엔지니어가 주어진 GraphQL 작업, fragment 또는 필드에 대한 mock 데이터를 자동으로 생성하는 데 사용할 수 있는 새로운 클라이언트 GraphQL 지시문인 @generateMock을 도입했습니다.
이 지시문은 엔지니어가 생성된 mock 데이터를 사용자 정의하는 데 사용할 수 있는 몇 가지 선택적 인수를 허용하며, 지시문 자체는 다른 mock 변형을 생성하기 위해 다른 입력 인수로 반복될 수 있습니다.
id: mock에 사용할 식별자 및 생성된 도우미 함수 이름에 사용할 식별자입니다. @generateMock 지시문을 반복하여 여러 mock을 생성할 때 유용합니다.
hints: mock이 어떻게 보여야 하는지에 대한 추가 컨텍스트 또는 지침입니다. 예를 들어 힌트는 "바르셀로나, 파리 및 교토에 대한 여행 항목을 포함합니다."일 수 있습니다. 내부적으로 이 정보는 LLM에 제공되며 생성된 mock 데이터의 모양과 필드가 얼마나 빽빽하게 채워지는지에 큰 영향을 미칩니다.
designURL: mock 데이터를 렌더링할 화면의 디자인 mock업 URL입니다. 이 인수를 지정하면 LLM이 일치하는 이름, 주소 및 기타 유사한 콘텐츠를 생성하여 디자인과 일치하는 mock 데이터를 생성하는 데 도움이 됩니다.
Airbnb에서 엔지니어는 Niobe라는 명령줄 도구를 사용하여 GraphQL 쿼리 및 fragment에 대한 코드를 생성합니다. .graphql 파일을 로컬에서 수정 한 후 엔지니어는 이 코드 생성기를 실행한 다음 생성된 TypeScript/Kotlin/Swift 파일을 사용하여 GraphQL 요청을 보냅니다. @generateMock을 사용하여 mock 데이터를 생성하려면 엔지니어는 지시문을 추가한 후 Niobe 코드 생성을 실행하기만 하면 됩니다. 다른 GraphQL 변경을 수행한 후와 마찬가지로 말이죠.
코드 생성 중에 Niobe는 각 @generateMock 지시문에 대한 실제 mock 데이터가 포함된 JSON 파일과 데모 앱, 스냅샷 테스트 및 단위 테스트에서 mock 데이터를 로드하고 사용하는 함수를 제공하는 소스 파일을 모두 생성합니다. 아래 Swift 코드에 표시된 것처럼 mockMixedStatusIndicators() 함수는 InboxSyncQuery의 루트 Data 유형에서 생성됩니다. JSON 데이터를 수동으로 로드하지 않고도 엔지니어가 mock을 사용할 수 있도록 mixed_status_indicators에 대해 생성된 mock 데이터로 채워진 인스턴스화된 유형에 대한 액세스를 제공합니다.
엔지니어는 생성된 mock JSON 데이터를 자유롭게 수정할 수도 있습니다. 아래에서 보듯이 Niobe는 후속 생성 호출에서 수정 사항을 덮어쓰지 않습니다.
Mock 데이터는 어떻게 생겼을까요?
LLM에 제공하는 컨텍스트는 데모에서 사용할 수 있을 만큼 현실적인 데이터를 생성하는 데 중요합니다. 이를 위해 Niobe는 다음 정보를 수집하여 LLM에 전달되는 컨텍스트에 포함합니다.
Mock되고 있는 쿼리/fragment/필드(즉, @generateMock으로 표시된 필드 및 해당 종속성)의 정의입니다.
쿼리되는 GraphQL 스키마의 하위 집합과 인라인 주석으로 존재하는 관련 문서입니다. 이 정보를 통해 LLM은 mock되고 있는 쿼리에서 사용되는 유형을 추론할 수 있습니다. 중요한 것은 전체 스키마가 아니라는 것입니다. 전체 스키마를 포함하면 컨텍스트 창이 과부하될 가능성이 높기 때문입니다. Niobe는 스키마를 탐색하고 쿼리를 해결하는 데 필요하지 않은 유형 및 필드와 추가 공백을 제거합니다.
designURL 내에 지정된 디자인 문서의 이미지 표현에 대한 URL(있는 경우)입니다. Niobe는 내부 API와 통합하여 디자인 문서에서 제공된 노드의 스냅샷 이미지를 생성합니다. API는 이 스냅샷을 스토리지 버킷에 푸시하고 Niobe에 제공하는 URL을 제공하며, 사용 방법에 대한 특수 지침과 함께 LLM에 제공합니다.
@generateMock에 지정된 추가 힌트입니다.
mock 데이터가 생성되고 있는 플랫폼(예: "iOS", "Android" 또는 "Web")(스타일 구체성을 위해)입니다.
LLM이 필요한 경우 선택할 수 있는 Airbnb에서 호스팅되는 이미지 URL 목록과 각 URL에 대한 짧은 텍스트 설명입니다. 이렇게 하면 LLM이 존재하지 않는 이미지 URL을 hallucinating하는 것을 방지하고 mock 데이터에 프로토타입 제작 또는 데모 시 런타임에 올바르게 로드할 수 있는 유효한 URL이 포함되도록 보장합니다.
이 모든 정보는 Gemini 2.5 Pro에 대해 미세 조정된 프롬프트로 통합됩니다. 내부 테스트에서 이 구성이 비슷한 품질의 mock 데이터를 생성하면서 비슷한 모델보다 훨씬 빠르게 수행된다는 사실과 함께 100만 토큰 컨텍스트 창 때문에 이 모델을 선택했습니다. 이 접근 방식을 사용하면 응용 프로그램에 로드될 때 아래와 같이 매우 설득력 있는 결과를 생성하는 매우 현실적인 JSON mock을 생성할 수 있습니다.
오른쪽 스크린샷의 데이터는 매우 현실적으로 보이지만 자세히 살펴보면 데이터가 실제로 mock이라는 것을 알 수 있습니다. 모든 사진은 LLM에 제공하는 시드 데이터 세트에서 가져온 것입니다.
작동 방식
엔지니어가 Niobe CLI를 사용하여 GraphQL 파일에 대한 코드를 생성하면 Niobe는 아래 순서도에 표시된 것처럼 이 프로세스의 마지막 단계로 mock 생성을 자동으로 수행합니다.
@generateMock 지시문에 designURL이 포함되어 있으면 Niobe는 URL을 검증하여 node-id를 포함하는지 확인한 다음 내부 API를 사용하여 해당 특정 노드의 이미지 스냅샷을 생성합니다. API는 이 스냅샷을 스토리지 버킷에 푸시하고 Niobe에 해당 URL을 제공합니다.
다음으로 CLI는 디자인 스냅샷 URL을 포함하여 위의 섹션에 설명된 모든 컨텍스트를 집계하고 LLM에 보낼 프롬프트를 만듭니다. 그런 다음 이 프롬프트는 Gemini 2.5 Pro 모델로 전송되고 결과는 CLI에 진행률 표시기를 표시하기 위해 클라이언트에 다시 스트리밍됩니다.
mock JSON 응답이 LLM에서 수신되면 Niobe는 GraphQL 스키마, 클라이언트 GraphQL 문서 및 JSON 데이터를 graphql NPM 패키지의 graphqlSync 함수에 전달하여 이 데이터에 대한 유효성 검사 단계를 수행합니다.
유효성 검사에서 오류가 발생하는 경우(예: LLM이 잘못된 enum 값을 hallucinating하거나 필수 필드를 채우지 못한 경우) Niobe는 이러한 오류를 집계하고 초기 mock 데이터와 함께 LLM에 다시 제공합니다. 이 재시도 메커니즘은 본질적으로 유효하지 않은 mock 데이터를 "자체 복구"하고 수정하는 데 사용됩니다.- 이 단계는 mock 데이터를 안정적으로 생성하는 데 중요합니다. LLM을 기존 GraphQL 인프라 내에 배치함으로써 이 유효성 검사 단계를 통해 일련의 안전 장치를 적용하고 파이프라인 끝에서 생성된 mock 데이터가 완전히 유효하다는 강력한 보증을 제공할 수 있습니다. 이는 ChatGPT와 같이 GraphQL 인프라 외부의 도구를 사용하여서는 불가능합니다.- 마지막으로 mock 데이터가 유효성 검사를 받으면 Niobe는 응용 프로그램 코드에서 mock을 로드하기 위한 함수를 제공하는 동반 소스 파일과 함께 JSON 파일에 씁니다.
@respondWithMock: 클라이언트 개발 차단 해제
@generateMock으로 현실적인 mock 데이터를 생성하는 것 외에도 클라이언트 엔지니어가 백엔드 서버 구현을 기다리지 않고도 기능에 대해 반복할 수 있도록 지원하고 싶었습니다. 두 번째 지시문인 @respondWithMock은 @generateMock과 함께 작동하여 이를 가능하게 합니다.
이 지시문이 있으면 Niobe는 mock 데이터와 함께 생성되는 코드를 변경하여 이 주석에 대한 추가 세부 정보를 포함합니다. 런타임 시 GraphQL 클라이언트는 이를 사용하여 생성된 mock 데이터를 로드한 다음 서버의 데이터 대신 mock 응답을 원활하게 반환합니다. 이를 통해 클라이언트 엔지니어는 구현되지 않은 필드를 쿼리할 때 로컬에서 mock된 데이터를 쉽게 사용할 수 있으므로 서버 구현을 기다리는 데서 스스로 벗어날 수 있습니다. 이 게시물의 앞부분에 있는 받은 편지함 화면의 스크린샷은 실제로 이러한 두 지시문으로 생성하고 iOS 시뮬레이터에서 Airbnb 앱을 실행하여 찍은 실제 스크린샷입니다. 수동 mocking, 프록시 처리 또는 응답 수정이 필요하지 않습니다!
@respondWithMock은 개별 필드에 지정할 수도 있습니다. 쿼리 자체가 아닌 쿼리 내의 필드에 사용하면 GraphQL 클라이언트는 @respondWithMock으로 주석 처리된 필드를 제외한 서버의 모든 필드를 실제로 요청한 다음 나머지 필드에 대해 로컬에서 mock된 데이터를 패치합니다. 프로덕션 및 mock 데이터의 하이브리드를 생성하고 클라이언트 엔지니어가 기존 쿼리에서 새로운(구현되지 않은) 필드에 대해 개발할 수 있도록 합니다. 엔지니어는 이 지시문을 반복하고 쿼리 입력 변수를 사용하여 런타임에 특정 생성된 mock을 반환할지 여부를 결정할 수도 있습니다. 아래와 같이 말이죠.
스키마 발전: Mock이 진실성을 유지하도록 하기
마지막으로 해결한 문제는 시간이 지남에 따라 쿼리가 발전함에 따라 mock이 쿼리와 동기화 상태를 유지하는 문제였습니다. Niobe는 @generateMock 지시문을 통해 생성된 mock 데이터를 관리하므로 해당 mock 데이터를 유지 관리하는 데 스마트할 수 있습니다. mock 생성의 일부로 Niobe는 각 생성된 JSON 파일에 두 개의 추가 키를 포함합니다.
코드 생성이 실행될 때마다 Niobe는 기존 mock의 해시가 GraphQL 문서를 기반으로 현재 해시와 다른지 여부를 확인합니다. 일치하면 해당 유형에 대한 mock 생성을 건너뜁니다. 반면에 해시 중 하나가 변경되면 Niobe는 LLM에 제공된 컨텍스트에 기존 mock을 포함하고 수정 방법에 대한 지침과 함께 해당 mock을 지능적으로 업데이트합니다.
Niobe는 변경되지 않고 여전히 유효한 필드에 대한 기존 mock 데이터를 불필요하게 수정하지 않는 것이 중요합니다. 그렇게 하면 엔지니어가 JSON에 적용한 수동 조정이 덮어쓰여지거나 이 데이터를 사용하는 기존 테스트가 중단될 수 있기 때문입니다. 이를 방지하기 위해 LLM에 쿼리에서 변경된 내용에 대한 diff를 제공하고 관련 없는 필드에 대한 가짜 변경을 방지하고 해당 diff에 집중하도록 프롬프트를 조정했습니다.
마지막으로 각 클라이언트 코드베이스에는 코드가 제출될 때 mock 버전 해시가 최신 상태인지 확인하는 자동화된 검사가 포함되어 있습니다. 이는 생성된 모든 mock이 쿼리가 시간이 지남에 따라 진화함에 따라 동기화 상태를 유지한다는 보장을 제공합니다. 엔지니어가 이러한 유효성 검사 실패를 발견하면 로컬에서 코드 생성을 다시 실행하기만 하면 됩니다. 수동 업데이트는 필요하지 않습니다.
결론
"@generateMock은 로컬 개발 속도를 크게 높였고 로컬 데이터 작업을 훨씬 더 즐겁게 만들었습니다." — 선임 소프트웨어 엔지니어
GraphQL 스키마, 제품 컨텍스트 및 UX 디자인에 의해 알려지는 고도로 컨텍스트화된 LLM을 기존 GraphQL 도구에 직접 통합함으로써 엔지니어가 수동으로 mock을 작성하고 유지 관리할 필요성을 없애면서 유효하고 현실적인 mock 데이터를 생성할 수 있는 기능을 잠금 해제했습니다. @generateMock 및 @respondWithMock의 지시문 기반 접근 방식을 통해 엔지니어는 서버 구현이 완료되기 전에 클라이언트를 구축하는 동시에 집중 루프에 유지하고 쿼리가 발전함에 따라 mock 데이터가 동기화 상태를 유지하도록 보장할 수 있습니다.
지난 몇 달 동안 Airbnb 엔지니어는 @generateMock을 사용하여 iOS, Android 및 웹에서 700개 이상의 mock을 생성하고 병합했으며 곧 백엔드 서비스에 대한 내부 지원을 출시할 계획입니다. 이러한 도구는 엔지니어가 테스트 및 프로토타입 제작을 위해 GraphQL 데이터를 mocking하는 방식을 근본적으로 변경하여 mock 데이터를 만들고 유지 관리하는 대신 제품 기능 구축에 집중할 수 있도록 했습니다.
감사의 말씀
@generateMock 지원을 웹 및 Android 클라이언트에 제공하는 데 기여한 Raymond Wang과 Virgil King, 디자인 검토에 참여하고 지원 인프라를 구축하고 사용 피드백을 제공한 Airbnb의 다른 많은 엔지니어와 팀에게 특별한 감사를 드립니다.
이러한 유형의 작업에 관심이 있으십니까? 여기에서 공개된 역할을 확인하십시오.
원문 보기
