dropbox·2026년 5월 21일·4분 읽기큐레이션 요약

Nova: 코딩 에이전트를 위한 사내 플랫폼을 소개합니다

코딩 에이전트는 코드 작성뿐 아니라 CI 장애 대응, 마이그레이션, 테스트 개선 등 소프트웨어 개발 전반의 반복 업무를 지원할 수 있다. Dropbox는 대규모 모노레포와 Bazel, 사내 인프라에 맞는 실행·검증 환경을 제공하기 위해 개별 도구 대신 클라우드 기반 플랫폼인 Nova를 구축했다. Nova는 대화형 세션과 비동기 자동화 작업을 하나의 인터페이스로 통합하고, 실제 빌드·테스트 결과를 바탕으로 에이전트가 반복적으로 수정하도록 설계됐다. ## 분산된 개발 업무를 통합하는 플랫폼 - 개발 과정에는 디버깅, 의존성 업데이트, 테스트 커버리지 개선, flaky test 수정처럼 반복적이지만 중요한 작업이 많다. - 작업에 따라 상호작용 방식이 다르다. - 개발자가 직접 대화하며 진행하는 대화형 세션 - 에이전트가 백그라운드에서 실행되고 의미 있는 결과만 전달하는 비동기 작업 - Dropbox의 대규모 모노레포는 Bazel의 캐시와 원격 실행, 온프레미스 인프라에 의존한다. - 일반적인 외부 코딩 에이전트는 로컬 개발에는 적합하지만 Dropbox의 저장소 구조와 빌드·검증 경로를 자연스럽게 지원하지 못한다. - 따라서 워크플로마다 별도 AI 도구를 만드는 대신, 실행·검증·컨텍스트 처리를 공통화한 플랫폼을 선택했다. ## Nova의 실행 및 검증 방식 - 각 Nova 세션은 특정 커밋 시점의 Dropbox 코드베이스 스냅샷을 기반으로 격리된 환경에서 실행된다. - 호출자는 다음 정보를 전달할 수 있다. - 기준 커밋 - 수행할 작업 - 작업 후 실행할 검증 명령 - 검증 실패 시 계속 진행할지 여부 - 최대 반복 횟수 - 결과를 게시할 브랜치 - 기본 흐름은 다음과 같다. - 에이전트가 변경 사항 제안 - Bazel 빌드·테스트 등 실제 검증 수행 - 실패 결과를 에이전트에 전달 - 에이전트가 원인을 분석하고 수정 - 정해진 반복 횟수까지 재검증 - 단순히 그럴듯한 패치를 생성하는 데 그치지 않고, 실제 Dropbox 개발 환경에서 변경 사항이 유효한지 확인한다. - 세션은 하나의 브랜치만 사용하고 코드 게시 작업은 에이전트 외부에서 처리한다. - 활성 브랜치와 게시 상태를 예측하기 쉽다. - 테스트 실행, 리베이스 등 후속 자동화를 단순하게 유지할 수 있다. - 여러 브랜치를 에이전트가 직접 관리할 때 발생하는 기준 브랜치 선택 문제를 피할 수 있다. ## 다양한 개발 인터페이스와 확장 기능 - Nova는 여러 코딩 에이전트를 동일한 인터페이스 뒤에서 사용할 수 있도록 확장됐다. - 제공 방식은 다음과 같다. - 웹 UI 기반 대화형 세션 - CLI - API - 로컬 에이전트, 스크립트, 사내 서비스에서 병렬 작업 실행 - 장기 실행 워크플로에 AI 단계를 추가할 수 있는 헬퍼를 제공한다. - 프롬프트 평가, 관측성, 피드백 수집 기능으로 에이전트 성능을 측정하고 개선할 수 있다. - 파일 수정 외에도 로그 수집, 장애 조사, 여러 단계에 걸친 컨텍스트 유지가 필요하므로 다음 확장 기능을 포함한다. - Skills - Plugins - MCP 통합 - 관측성 시스템 접근 ## CI 장애 대응에서 시작한 적용 - Nova는 CI 실패에 대한 수정 제안을 자동화하는 문제에서 출발했다. - 예시 요청은 특정 커밋에서 CI 실패를 조사하고, 관련 Bazel 테스트를 실행하며, 실패 시 최대 5회까지 수정·재검증하는 형태다. - 검증 명령을 호출자가 명시하므로 에이전트가 변경한 코드에 필요한 컴파일·테스트 범위를 구체적으로 지정할 수 있다. - 이 방식은 “변경 제안 → 실제 검증 → 실패 원인 반영”이라는 안정적인 자동화 패턴을 만든다. ## 개발자 주도 세션 - 엔지니어는 Nova 웹 UI에서 로컬 개발을 중단하지 않고 빠른 수정이나 프로토타입을 진행할 수 있다. - Bazel 선택성 도구와 검증 명령을 결합해 변경된 코드와 관련된 컴파일·테스트 대상만 검증할 수 있다. - Slack 대화에서 바로 Nova 세션을 시작하고 해당 스레드의 논의 내용을 컨텍스트로 전달할 수 있다. - 이를 통해 문제 설명이나 팀 내 논의를 에이전트 프롬프트에 수동으로 다시 작성하는 비용을 줄인다. ## Flaky test 자동 수정 - Nova의 대표적인 운영 자동화 사례는 flaky test remediation이다. - Dropbox의 flaky 테스트 탐지 시스템인 Athena와 내부 도구 Deflaker를 결합했다. - Deflaker의 흐름은 다음과 같다. - 테스트가 성공한 사례와 실패한 사례를 수집 - 관련 로그를 Nova에 컨텍스트로 전달 - 에이전트가 가능한 근본 원인을 분석 - 수정안을 제안 - 이는 단순 코드 생성보다 로그 분석, 증거 비교, 원인 추론이 중요한 장기 실행형 워크플로에 해당한다. ## 실용적인 시사점 코딩 에이전트를 도입할 때는 에디터 플러그인 하나를 추가하는 것보다 저장소, 빌드 시스템, 테스트 인프라, 로그와 컨텍스트를 연결하는 플랫폼 설계가 중요하다. 특히 에이전트의 결과를 실제 검증 명령으로 확인하고, 실패 결과를 다시 에이전트에 제공하는 반복 루프와 예측 가능한 브랜치·게시 정책을 갖추는 것이 안정적인 자동화의 핵심이다.

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

bazel옵저버빌리티CI/CD모델 컨텍스트 프로토콜+4

slack·2025년 11월 6일·4분 읽기큐레이션 요약

더 나은 소프트웨어를 만들기

빌드가 60분씩 걸리면 코드 변경에 대한 피드백이 늦어져 개발 생산성이 크게 떨어진다. Slack은 Bazel과 전통적인 성능 최적화 원칙인 캐싱·병렬화를 결합해 빌드 시간을 개선했다. 핵심은 빌드를 명확한 입력·출력 단위의 그래프로 모델링하고, 재사용 가능하고 병렬 실행 가능한 작은 작업으로 나누는 것이다. ## 빌드를 방향성 비순환 그래프로 모델링 - 백엔드와 프런트엔드는 서로 독립적으로 개발·배포될 수 있으며, 각각 필요한 소스 파일에만 의존한다. - 빌드 구성 요소와 배포 산출물 사이의 의존성은 방향성 비순환 그래프(DAG)로 표현된다. - 특정 Python 파일이 변경되면 백엔드만 다시 빌드하고, TypeScript 파일 변경 때문에 백엔드까지 재빌드하지 않도록 의존성을 정확히 정의할 수 있다. - 그래프로 빌드를 표현하면 애플리케이션 코드와 동일하게 다음 최적화를 적용할 수 있다. - 이미 수행한 작업의 결과를 저장해 다시 계산하지 않기 - 여러 컴퓨팅 자원에 작업을 분산해 동시에 처리하기 ## 캐싱을 통한 불필요한 작업 제거 - 캐시는 입력값과 결과값을 연결해 동일한 입력에 대한 작업을 한 번만 수행하도록 한다. - 예를 들어 `factorial(n)`은 입력 `n`에 따라 결과가 항상 같으므로 `functools.cache`를 적용할 수 있다. - 빌드 캐싱이 올바르게 작동하려면 작업이 다음 조건을 만족해야 한다. - **Hermetic**: 명시적으로 전달된 입력만 사용해 결과를 생성해야 한다. - **Idempotent**: 동일한 입력에 대해 항상 동일한 결과를 내야 한다. - 캐시 성능은 전체 호출 중 캐시에서 결과를 가져오는 비율인 캐시 적중률(hit rate)에 좌우된다. ## 작업 단위를 작게 나눠 캐시 적중률 높이기 - 이미지 목록 전체와 변환 목록 전체를 입력으로 받는 `process_images()`에 캐시를 적용하면, 이미지 하나만 추가돼도 전체 입력이 바뀐 것으로 간주된다. - 이 방식은 캐시 키가 지나치게 크고 거칠어, 작은 변경에도 모든 작업을 처음부터 다시 수행해야 한다. - 대신 이미지 하나에 변환 하나를 적용하는 `process_image(image, transform)`처럼 더 작은 단위에 캐시를 적용할 수 있다. - 그러면 새로 추가되거나 변경된 이미지·변환 조합만 처리하고, 이미 계산한 조합은 캐시에서 재사용할 수 있다. - 상위 수준 API는 유지하면서 내부 작업 단위만 세분화하는 방식이 성능과 재사용성을 높인다. ## 병렬화를 통한 작업 분산 - 이미지 처리처럼 서로 독립적인 작업은 여러 CPU 코어나 프로세스, 네트워크상의 다른 컴퓨팅 노드로 분산할 수 있다. - 병렬 실행을 위해서는 다음 조건이 필요하다. - 작업의 입력과 출력이 명확하게 정의되어야 한다. - 입력과 출력을 스레드·프로세스·네트워크 경계 너머로 전달할 수 있어야 한다. - 작업이 어떤 순서로 완료되거나 실패할지 보장할 수 없으므로 결과 처리 규칙을 명확히 해야 한다. - 예시의 스레드 기반 구현은 이미지 결과가 입력 순서와 다르게 반환될 수 있다. - 결과 순서 보장 여부는 API 계약의 일부이며, 사용자가 허용할 수 있는 동작인지 사전에 결정해야 한다. ## 병렬화에서도 작업 단위의 크기가 중요 - 작업 수가 적고 각각의 작업이 너무 크면 사용 가능한 컴퓨팅 자원에 충분히 분산하지 못한다. - 반대로 작업을 지나치게 잘게 나누면 작업 전달·관리 오버헤드가 커질 수 있다. - 적절한 작업 크기와 개수의 균형은 문제마다 다르므로 API와 빌드 단위를 설계할 때 함께 고려해야 한다. - 캐싱과 병렬화 모두 입력·출력이 명확하고 독립적인 작은 작업 단위를 필요로 한다. ## Bazel 빌드로 원칙 확장 - Bazel은 빌드를 방향성 비순환 그래프 형태의 **타깃(target)** 으로 정의한다. - 각 타깃에는 다음 세 가지 핵심 요소가 있다. - 빌드 단계의 입력이 되는 의존 파일 - 빌드 단계가 생성하는 출력 파일 - 입력을 출력으로 변환하는 명령어 - 이러한 명시적 정의를 바탕으로 변경된 타깃만 다시 빌드하고, 결과를 캐시하며, 서로 독립적인 타깃을 병렬 실행할 수 있다. - 따라서 빌드 시스템의 성능 개선은 단순히 더 빠른 도구를 도입하는 문제가 아니라, 코드 성능 최적화와 마찬가지로 작업의 경계와 의존성을 설계하는 문제다. 빌드 시간을 줄이려면 먼저 의존성과 입출력을 명확히 정의하고, 변경 범위가 작은 작업 단위로 빌드를 나누는 것이 좋다. 그 위에 hermetic·idempotent한 작업을 캐시하고 독립 작업을 병렬화하면, 대규모 프로젝트에서도 불필요한 재빌드를 줄이고 개발자 피드백 속도를 높일 수 있다.

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

bazelTypeScriptPythoncaching+4

airbnb·2025년 8월 13일원문

에어비앤비 (새 탭에서 열림)

에어비앤비는 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와의 매끄러운 통합이 프로젝트의 성패를 좌우합니다. 또한 빌드 파일 생성과 같은 반복적인 작업을 자동화하여 개발자가 시스템 환경 설정이 아닌 코드 작성에만 집중할 수 있는 환경을 조성하는 것이 필수적입니다.

bazelKotlinJavamonorepo+4