Dropbox

19 개의 포스트

dropbox.tech

태그로 필터

dropbox

범용 콘텐츠 처리 플랫폼 Riviera가 AI와 그 너머를 위해 어떻게 진화했는가 (새 탭에서 열림)

Dropbox의 콘텐츠 처리 플랫폼 Riviera는 파일 미리보기 서비스에서 출발해 Search, Replay, Sign, Dash 등 여러 제품이 공유하는 범용 변환 플랫폼으로 발전했다. 핵심 설계는 파일별·제품별 파이프라인을 따로 만드는 대신, PDF 변환·페이지 이미지 생성·텍스트 추출 같은 작은 변환 작업을 재사용 가능한 플러그인으로 조합하는 것이다. AI 제품의 확산으로 문서와 미디어를 일관된 형태로 준비하는 수요가 커지면서, Dropbox는 Riviera의 기능을 외부 개발자와 설계 파트너에게 API와 Model Context Protocol 도구로 공개했다. ## 미리보기 문제에서 시작된 플랫폼 - Dropbox는 300개가 넘는 파일 형식을 지원하며, 각 형식에서 썸네일, 전체 미리보기, 추출 텍스트, 스트리밍 매니페스트, 메타데이터 등 다양한 결과물을 생성해야 했다. - 파일 형식과 출력물마다 별도 서비스를 만들면 다음 문제가 발생한다. - 동일한 변환 로직이 여러 서비스에 중복됨 - 의존성, 패키지 버전, 설정이 서로 달라짐 - 유지보수와 운영 부담이 커짐 - Riviera는 모든 미리보기를 독립적인 기능으로 보지 않고, 재사용 가능한 작은 변환 단계의 조합으로 정의했다. - 예를 들어 PowerPoint 미리보기는 다음처럼 처리할 수 있다. - PowerPoint를 PDF로 변환 - PDF의 각 페이지를 이미지로 변환 - 생성된 이미지를 Dropbox 화면에서 표시 - PDF를 이미지로 바꾸는 단계는 PDF 자체의 미리보기나 다른 페이지 이미지 생성 작업에도 재사용할 수 있다. ## 조정과 실행을 분리한 아키텍처 - Riviera의 중앙 구성 요소는 변환 요청을 수집하고, 작업을 조합하며, 적절한 백엔드 워커에 분배한다. - 중앙 계층은 다음 기능을 담당한다. - 요청 유효성 검증 - 변환 작업 구성 - 결과 캐싱 - 중복되거나 잘못된 작업 차단 - 각 백엔드 워커는 특정 변환 유형을 담당한다. - 기능별로 독립적인 유지보수와 확장이 가능함 - 특정 변환의 처리량에 맞춰 개별적으로 확장할 수 있음 - 새로운 파일 형식이나 변환 유형을 추가할 때 핵심 인프라를 수정하는 대신 플러그인을 추가하면 된다. - 현재 Riviera는 100개가 넘는 변환 기능을 제공하며, 초당 수십만 건의 변환을 처리한다. - 이 구조 덕분에 핵심 플랫폼은 안정적으로 유지하면서 지원 파일 형식과 제품 기능을 계속 확장할 수 있었다. ## 여러 제품이 공유하는 변환 라이브러리 - Riviera는 처음에는 전담 Previews 팀이 운영하는 내부 서비스였지만, 다른 팀들도 동일한 콘텐츠 처리 문제를 겪고 있다는 사실이 드러났다. - 예를 들어 미리보기용으로 만든 160×160 썸네일은 머신러닝 팀의 이미지 정규화에도 활용할 수 있었다. - 같은 결과물을 여러 소비자가 사용하면 변환을 한 번만 수행하면 됨 - Search 팀은 문서를 검색 인덱싱에 적합한 형태로 준비하기 위해 Riviera를 도입했다. - Sign, DocSend, Replay 같은 제품도 기존 변환 기능을 재사용했다. - 이후 Dropbox는 플러그인 모델을 제품 팀에 개방했다. - Riviera 팀은 핵심 아키텍처를 관리 - 각 제품 팀은 필요한 변환 플러그인을 추가 - 추가된 플러그인은 다른 팀도 사용할 수 있는 공유 자산이 됨 ## Replay가 보여준 플러그인 모델의 효과 - 동영상 리뷰 제품인 Replay는 동영상 트랜스코딩과 조작이라는 복잡한 처리 작업이 필요했다. - Riviera의 미디어 변환 기능을 활용함으로써 Replay 팀은 동영상 처리 인프라를 처음부터 구축하지 않아도 됐다. - 제품 팀이 변환 기능을 요청하면 Riviera가 기존 기능을 노출하거나 새 플러그인을 추가하는 방식이 정착됐다. - 그 결과 기존에는 수개월이 걸릴 수 있었던 기능을 수주 안에 출시할 수 있었고, 새로운 플러그인이 추가될수록 다음 제품의 개발도 빨라졌다. ## Dash와 AI가 만든 새로운 요구 - AI 모델이 문서에 답변하거나 보고서를 요약하려면 먼저 문서가 모델이 처리할 수 있는 일관된 형태로 변환되어야 한다. - 필요한 전처리에는 다음 작업이 포함된다. - 텍스트 추출 - 스캔 문서의 페이지 인식 - 메타데이터 추출 - 다양한 파일 형식의 통일된 표현으로 변환 - 이러한 작업은 본질적으로 AI 모델 자체의 문제가 아니라 콘텐츠 변환 문제이며, Riviera가 기존부터 해결해 온 영역이다. - Dash 팀은 Riviera가 이미 지원하던 수백 가지 파일 형식과 변환 기능을 활용해 별도의 문서 처리 시스템을 새로 만들 필요를 줄였다. - Riviera는 미리보기와 미디어 처리뿐 아니라 검색, 문서 자동화, AI용 콘텐츠 준비에도 적용되는 기반 계층으로 확장됐다. ## 외부 개발자를 위한 공개 - Dropbox는 Riviera에서 축적한 콘텐츠 변환 기능을 API와 Model Context Protocol 도구 형태로 개발자 생태계와 설계 파트너에게 제공하기 시작했다. - 활용 사례로는 다음과 같은 작업이 제시된다. - 콘텐츠 관리 시스템 구축 - 문서 처리 워크플로 자동화 - 파일 검색용 인덱싱 - AI 애플리케이션용 문서 전처리 - 핵심 가치는 제품마다 변환 인프라를 새로 구축하지 않고, 검증된 공통 플랫폼을 이용할 수 있다는 점이다. Riviera의 사례는 대규모 콘텐츠 처리를 제품별 기능이 아니라 재사용 가능한 변환 조합과 플러그인 플랫폼으로 설계해야 한다는 점을 보여준다. 특히 AI 애플리케이션을 만들 때 모델 개발에만 집중하기보다, 다양한 파일을 안정적으로 추출·정규화·변환하는 기반을 먼저 확보하는 것이 실용적인 접근이다.

dropbox

DSPy를 활용해 Dash 채팅에서 AI 평가를 더 나은 응답으로 전환한 방법 (새 탭에서 열림)

Dropbox는 Dash chat 에이전트의 최종 답변만 평가하지 않고, 의도 파악·검색·도구 사용·근거 선택·다중 턴 대응까지 전체 실행 과정을 평가했습니다. 이후 사람의 평가 데이터를 활용해 LLM 평가자(judge)를 보정하고, DSPy의 GEPA·MIPROv2로 평가자와 에이전트 시스템 프롬프트를 최적화했습니다. 그 결과 불완전한 답변을 줄이고 토큰 사용량도 낮추면서 답변 품질을 유지할 수 있었습니다. ## 에이전트 평가가 어려운 이유 - 전통적인 검색 평가는 단일 결과의 관련성을 주로 측정하지만, 에이전트는 여러 단계의 의사결정을 수행합니다. - 평가 대상에는 다음 과정이 모두 포함됩니다. - 사용자의 의도 해석 - 문서·메시지·회의 기록 등 적절한 컨텍스트 수집 - 검색 및 문서 읽기 같은 도구 사용 - 여러 출처의 정보 종합 - 직접 답변, 추가 검색, 요약, 명확화 질문 중 적절한 선택 - 대화가 여러 턴에 걸쳐 진행될 수 있으므로 최종 답변뿐 아니라 피드백 반영과 재검색 과정도 평가해야 합니다. - 따라서 답변 품질, 의도 이해, 컨텍스트 선택, 도구 사용, 근거성, 지시 준수, 과업 완료 여부를 পৃথ도로 분석해야 실패 원인을 찾을 수 있습니다. ## 사람의 평가로 LLM judge 보정 - 내부 채팅 샘플과 에이전트 trace 로그를 수집하고, 사람이 다음 다섯 가지 차원을 평가했습니다. - 사용자 의도 추종 - 의미적 관련성 - 도구 호출 품질 - 지시사항 준수 - 컨텍스트 선택 - 평가자는 먼저 의도와 컨텍스트가 적절했는지 확인한 뒤 검색·검색 결과 활용·도구 행동을 검토했습니다. - 이후 최종 답변이 선택된 근거에 의해 뒷받침되는지, 관련성·근거성·완전성·지시 준수 여부를 평가했습니다. - 일부 지표는 1~5점으로 점수화하고, 함께 다음 정보를 기록했습니다. - 점수의 근거가 되는 reasoning note - 오래된 근거, 누락된 컨텍스트, 근거 없는 주장, 불완전한 답변, 개인화 실패 등의 failure code - 점수는 결과를 요약하지만, 평가 메모와 실패 코드는 문제가 발생한 위치와 원인을 보여줍니다. - 이 데이터는 judge 프롬프트 보정뿐 아니라 디버깅, 오류 분석, 개선 로드맵 수립, 우선순위 결정에도 활용됐습니다. ## DSPy를 이용한 평가자 개선 - 목표는 LLM judge의 점수가 사람의 판단과 더 일치하도록 만드는 것이었습니다. - judge는 단순히 답변에 점수를 매기는 것이 아니라 다음과 같은 정해진 절차를 따라야 했습니다. - 사용자의 의도 추론 - 대화 내용 검토 - 에이전트 trace와 지원 근거 확인 - 컨텍스트 선택과 도구 사용 분석 - 점수·실패 코드·평가 메모 작성 - DSPy를 최적화 도구로 사용하고, GEPA와 MIPROv2를 알고리즘으로 활용했습니다. - 알고리즘은 사람의 라벨이 있는 예제에서 프롬프트 변경안을 자동으로 제안하고 테스트했습니다. - 지원한 최적화 방식에는 다음이 포함됩니다. - judge 지침을 처음부터 새로 작성 - 기존 평가 행동을 유지하면서 다른 기반 모델에 맞게 조정 - 특정 실패 유형을 집중적으로 수정하는 타깃 최적화 - 이렇게 최적화된 judge는 이후 채팅 에이전트 자체의 시스템 프롬프트를 개선하는 평가 신호로 사용됐습니다. ## 평가에서 에이전트 개선으로 이어지는 피드백 루프 - 전체 과정은 다음 순환 구조로 구성됩니다. - 사람의 라벨이 judge를 보정 - 개선된 judge가 대규모 평가 신호 생성 - 평가 신호가 에이전트 프롬프트와 행동 개선에 사용 - 이 구조를 통해 사람의 평가를 모든 대화에 직접 적용하지 않고도 에이전트를 반복적으로 최적화할 수 있었습니다. - 최종적으로 불완전한 답변이 크게 줄었고, 답변 품질을 떨어뜨리지 않으면서 토큰 사용량도 절감했습니다. 실무적으로는 에이전트 개선 전에 평가자의 신뢰성을 먼저 검증해야 합니다. 최종 점수만 수집하기보다 trace, 평가 이유, 실패 유형을 함께 기록하고, 사람의 라벨과 DSPy 같은 자동 최적화 도구를 결합하면 평가를 지속적인 품질 개선 시스템으로 전환할 수 있습니다.

dropbox

Dropbox가 MCP와 Dash를 활용해 디자인에서 코드로 이어지는 보안 격차를 해소하는 방법 (새 탭에서 열림)

Dropbox는 보안 위협 모델과 실제 코드 구현 사이의 단절을 MCP, 기초 언어 모델, Dash를 결합해 해결하고자 했다. 시스템은 코드 리뷰 시 관련 위협 모델을 자동으로 검색하고, 문서에 정의된 보안 요구사항이 코드에 반영됐는지 비교한다. 분석 결과 구현 PR의 12%만 원래 보안 검토와 연결되어 있었으며, 보안 지식을 코드 리뷰 시점에 자동으로 제공하는 것이 핵심 해결책으로 제시된다. ## 설계와 코드 사이의 보안 격차 - 보안 검토에서는 잠재적 위험, 공격 가능성, 필요한 보호 조치를 위협 모델에 기록한다. - 그러나 개발이 시작되면 위협 모델은 위키나 문서 시스템에 남고, 구현 코드는 별도의 PR에서 관리된다. - 명시적인 링크가 없으면 코드 리뷰어가 과거의 보안 요구사항을 확인하기 어렵다. - Dropbox의 분석 결과: - 구현 PR 중 원래 설계 검토 및 위협 모델을 연결한 비율은 **12%**에 불과했다. - 검증된 79개 쌍 중 **54%**는 보안 검토 후 한 달이 지나서야 PR이 생성됐다. - 보안 검토부터 PR 생성까지의 중앙값은 약 **5주**였다. - 일부 지연은 **11개월 이상**이었다. - 검토 후 2주 이내에 생성된 PR은 **29%**뿐이었다. ## 기존 보안 도구의 한계 - 정적 분석 도구는 코드에 특정 보안 제어가 존재하는지 확인할 수 있다. - 하지만 해당 제어가 설계 검토에서 합의한 요구사항과 일치하는지는 판단하기 어렵다. - 정적 분석은 코드의 패턴은 검사하지만, 설계 의도와 이전에 결정된 보안 맥락은 알지 못하기 때문이다. - 개발자에게 설계 문서와 PR을 직접 연결하도록 요구하거나 알림 봇을 사용하는 방식도 지속적인 준수에 의존한다. - 설계 검토의 약 **15%**는 코드가 먼저 작성된 뒤 사후적으로 진행됐다. - 따라서 자동화 시스템은 기존 검토와 코드를 연결하는 것뿐 아니라, 보안 검토가 필요할 가능성이 있는 작업을 개발 중 조기에 식별하는 역할도 할 수 있다. ## Dash와 MCP를 활용한 컨텍스트 연결 - Dash는 여러 연결된 애플리케이션의 문서를 색인하므로, 기존 위협 모델과 엔지니어링 문서를 통합적으로 검색할 수 있다. - Dropbox는 코드가 리뷰에 제출될 때 관련 위협 모델을 자동으로 검색하도록 시스템을 구축했다. - MCP(Model Context Protocol)는 AI 에이전트가 Dash가 색인한 문서에 접근하도록 하는 연결 계층이다. - 보안 검토 에이전트는 Dash의 MCP 서버를 통해 위협 모델과 관련 문서를 검색하고 읽는다. - 별도의 소스 시스템별 맞춤 통합 없이 여러 컨텍스트를 하나의 에이전트 세션에 결합할 수 있다. ## 요구사항과 구현 코드의 비교 - 코드 리뷰가 시작되면 에이전트는 관련 위협 모델과 보조 문서를 가져온다. - 기초 언어 모델은 문서에 기록된 보안 요구사항과 변경된 코드를 함께 분석한다. - 예를 들어 위협 모델이 특정 엔드포인트에 인증을 요구한다면, 실제 코드가 인증을 강제하는지 판단할 수 있다. - 기존 정적 분석과 달리 단순히 취약한 코드 패턴을 찾는 것이 아니라, **설계 단계의 보안 결정이 구현에 반영됐는지**를 검토한다. - 결과를 별도의 보안 절차가 아니라 개발자가 이미 사용하는 코드 리뷰 과정에 제공하는 것이 중요한 설계 원칙이다. ## 실용적인 결론 보안 검토 문서를 별도로 잘 작성하는 것만으로는 충분하지 않다. 해당 문서의 요구사항이 코드가 검토되는 시점에 자동으로 노출되고 구현과 비교되어야 하며, 이를 위해 조직의 기존 문서 검색 시스템과 MCP 기반 AI 에이전트를 코드 리뷰 흐름에 통합하는 접근이 효과적이다.

dropbox

코드 생성을 넘어: AI 에이전트 시대의 엔지니어링 생산성을 다시 생각하다 (새 탭에서 열림)

Dropbox는 AI 코딩 도구가 코드 작성 속도는 높였지만, 리뷰·CI·테스트·배포·운영을 새로운 병목으로 만들었다고 설명합니다. 따라서 생산성의 핵심은 코드 생성량이 아니라 전체 개발 생명주기가 더 많은 변경을 안정적으로 흡수하고 고객 가치로 전환하는 능력입니다. Dropbox는 코딩 에이전트 플랫폼, 새로운 생산성 지표, 교육과 가드레일을 통해 AI 중심의 개발 운영 모델을 구축하고 있습니다. ## 코파일럿에서 자율형 에이전트로 - 초기 AI 코딩 도구는 코드 설명, 스니펫 생성, 질의응답 등으로 엔지니어 옆에서 작업을 보조하는 코파일럿 역할을 했습니다. - 에이전트는 범위가 정해진 작업을 받아 다음 과정을 수행할 수 있습니다. - 코드베이스 조사 - 파일 수정 - 테스트 실행 - 실패 원인 분석과 재시도 - 사람이 검토할 수 있는 결과물 생성 - 엔지니어는 여전히 요구사항, 아키텍처, 품질, 배포에 대한 최종 책임을 집니다. - 에이전트 도입으로 여러 작업을 병렬로 진행하고, 반복적인 구현 업무를 위임할 수 있게 됐습니다. - 반면 코드와 풀 리퀘스트가 빠르게 증가하면서 코드 리뷰, 테스트 인프라, 검증, 릴리스 조정, 운영 시스템에 부담이 커졌습니다. ## Nova: Dropbox의 에이전트 플랫폼 - Nova는 자연어로 작업을 설명하면 통제된 환경에서 AI 코딩 에이전트를 실행할 수 있는 Dropbox의 내부 플랫폼입니다. - Nova의 핵심 가치는 모델 자체보다 다음과 같은 주변 시스템에 있습니다. - 코드베이스와 내부 개발 관행에 대한 컨텍스트 - 안전한 실행 환경 - 기존 개발 워크플로와의 통합 - 검증 절차와 사람의 최종 리뷰 - Nova가 생성한 변경은 작업 정의, 에이전트 실행, 결과 검증, 사람의 승인이라는 구조화된 흐름을 거칩니다. - 현재 Dropbox 풀 리퀘스트의 약 12분의 1이 Nova를 통해 생성되고 있습니다. - 기능 개발뿐 아니라 다음과 같은 고수고 작업에도 활용됩니다. - 마이그레이션 - 불안정한 테스트 수정 - 버그 조사 - 의존성 업데이트 - 시스템 유지보수 작업 ## 코드량이 아닌 제품 전달 속도 측정 - AI로 PR 생성량이 늘어나면 단순한 PR 처리량은 생산성을 충분히 설명하지 못합니다. - 함께 측정해야 할 지표는 다음과 같습니다. - 코드 리뷰 대기 및 처리 시간 - CI 비용과 처리 지연 - 재작업 비율 - 결함 비율 - 테스트의 첫 실행 성공률 - 최종적으로 고객에게 전달되는 가치 - Dropbox는 생산성을 네 단계로 나눠 측정합니다. - **Fuel**: AI 도구가 실제로 사용되는 정도 - **Adoption**: 팀의 개발 워크플로가 얼마나 변화했는지 - **Output**: AI가 실제 프로덕션 작업에 기여한 정도 - **Impact**: 아이디어가 고객 가치로 전환되는 시간과 제품 전달 속도의 개선 - 생산성 향상은 속도만으로 판단할 수 없으며, 품질과 신뢰성을 유지하는지가 중요합니다. - 코드 생성이 빨라져도 결함과 재작업이 늘어난다면 실질적인 생산성 향상으로 볼 수 없습니다. ## 엔지니어링 업무 방식의 변화 - 에이전트가 구현을 더 많이 담당하면서 엔지니어의 역할은 다음 영역으로 이동합니다. - 문제와 의도 정의 - 요구사항과 코드베이스 맥락 정리 - 생성된 변경 검토 - 아키텍처 및 품질 판단 - 최종 결과에 대한 책임 - 도구만 배포한다고 에이전트 방식이 정착되지는 않습니다. - Dropbox는 실습 교육, 해커톤, 부트캠프, 워크플로 사례 공유, 동료 주도 학습 등을 활용해 팀의 적응을 지원합니다. - 팀마다 도입 속도와 필요한 안전장치가 다릅니다. - 고위험 시스템은 더 강한 검증과 명확한 가드레일이 필요합니다. - 격리되거나 위험도가 낮은 코드 영역은 더 빠르게 자동화할 수 있습니다. - 모든 작업을 에이전트로 처리하는 것이 목표가 아니라, 효과가 큰 영역에서 안전하고 반복 가능한 방식으로 사용하는 것이 목표입니다. ## AI가 옮겨 놓은 병목 - AI는 소프트웨어 개발의 병목을 제거하기보다 다른 단계로 이동시킵니다. - 코드 생성이 빨라질수록 다음 영역이 새로운 제약이 됩니다. - 리뷰 처리 용량 - 테스트와 검증 - 릴리스 조정 - 운영 및 장애 대응 - 따라서 조직은 모델이나 코드 생성 기능만 강화할 것이 아니라 다음 시스템에 투자해야 합니다. - 풍부한 코드베이스 컨텍스트 - 에이전트 오케스트레이션 - 품질 관리와 거버넌스 - 개발 워크플로 통합 - 결과와 고객 영향을 측정하는 체계 - 경쟁력은 누구나 접근할 수 있는 기반 모델보다, 그 모델을 실제 조직의 개발 과정에 연결하는 내부 시스템에서 나온다는 것이 글의 결론입니다. 실무적으로는 AI 도구 도입량보다 리뷰 지연, 테스트 성공률, 결함·재작업, 배포 리드타임, 고객 가치 전달 속도를 함께 추적하는 것이 중요합니다. 작은 범위의 반복 업무부터 에이전트를 적용하고, 사람의 승인과 명확한 안전장치를 포함한 워크플로로 확장하는 접근이 적절합니다.

dropbox

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에 컨텍스트로 전달 - 에이전트가 가능한 근본 원인을 분석 - 수정안을 제안 - 이는 단순 코드 생성보다 로그 분석, 증거 비교, 원인 추론이 중요한 장기 실행형 워크플로에 해당한다. ## 실용적인 시사점 코딩 에이전트를 도입할 때는 에디터 플러그인 하나를 추가하는 것보다 저장소, 빌드 시스템, 테스트 인프라, 로그와 컨텍스트를 연결하는 플랫폼 설계가 중요하다. 특히 에이전트의 결과를 실제 검증 명령으로 확인하고, 실패 결과를 다시 에이전트에 제공하는 반복 루프와 예측 가능한 브랜치·게시 정책을 갖추는 것이 안정적인 자동화의 핵심이다.

dropbox

불변 블롭 저장소 Magic Pocket의 저장 효율성 개선 (새 탭에서 열림)

Dropbox의 엑사바이트급 불변(Immutable) 블록 저장소인 'Magic Pocket'은 데이터 무결성과 효율적인 확장을 위해 설계된 핵심 인프라입니다. 최근 새로운 데이터 배치 서비스인 'Live Coder' 도입 과정에서 볼륨이 채 5%도 채워지지 않는 심각한 파편화 문제가 발생하여 스토리지 오버헤드가 급격히 증가하는 위기를 맞았습니다. 이를 해결하기 위해 Dropbox 엔지니어링 팀은 기존의 안정 상태 압축 방식을 넘어, 저밀도 볼륨을 집중적으로 재구성하는 다각적인 전략을 통해 스토리지 효율을 이전 수준보다 더욱 개선하는 데 성공했습니다. **불변 스토리지 구조와 공간 회수 메커니즘** * Magic Pocket은 데이터를 한 번 쓰면 수정하지 않는 불변 방식을 채택하고 있어, 사용자 데이터가 삭제되거나 수정되어도 기존 데이터는 즉시 지워지지 않고 볼륨 내에 그대로 남습니다. * 이러한 특성상 시간이 지남에 따라 실제 데이터보다 더 많은 디스크 공간을 점유하는 '파편화'가 발생하며, 이를 관리하지 않으면 스토리지 오버헤드가 기하급수적으로 늘어납니다. * 공간 회수는 가비지 컬렉션(참조되지 않는 데이터 식별)과 압축(Compaction)이라는 두 단계로 이루어지며, 압축은 유효한 데이터만 골라 새 볼륨에 옮겨 적고 기존 볼륨을 퇴거시키는 방식으로 수행됩니다. * 데이터 가용성을 위해 에러저 코딩(Erasure Coding)을 사용하여 복제 방식보다 적은 비용으로 결함 허용 능력을 유지합니다. **신규 서비스 도입으로 인한 저밀도 볼륨 문제** * 배경 쓰기 증폭을 줄이기 위해 도입된 'Live Coder' 서비스가 예상치 못하게 할당량의 5% 미만만 채워진 수많은 저밀도 볼륨을 생성하는 부작용을 일으켰습니다. * Magic Pocket의 볼륨은 고정된 크기를 가지기 때문에, 데이터가 적게 들어있어도 전체 용량을 점유하게 되어 실제 저장된 바이트 대비 물리적 디스크 소비량이 급등했습니다. * 기존의 압축 방식은 데이터 분포가 비교적 균일한 상태를 가정하고 설계되었기에, 엑사바이트 규모에서 발생한 대량의 저밀도 볼륨을 빠르게 정리하기에는 역부족이었습니다. **기존 L1 압축 전략의 동작과 한계** * 기존의 L1 전략은 거의 다 채워진 '호스트 볼륨'의 빈 공간에 파편화된 '공여 볼륨(Donor)'의 데이터를 채워 넣는 방식입니다. * 이 방식은 단순하고 메타데이터 업데이트 비용이 적지만, 한 번의 실행으로 회수되는 공간이 제한적이라는 단점이 있습니다. * 데이터 밀도가 극도로 낮은 볼륨이 대량으로 존재하는 상황에서는 L1 전략의 처리 속도가 파편화 속도를 따라잡지 못해 스토리지 비용을 실시간으로 절감하기 어려웠습니다. **실용적인 결론 및 권장 사항** 대규모 불변 스토리지 시스템을 운영할 때는 데이터의 배치 로직 변화가 스토리지 효율에 미치는 영향을 실시간으로 모니터링하는 것이 필수적입니다. 특히 데이터 밀도가 급격히 변하는 이례적인 상황에 대비하여, 단순히 빈 공간을 채우는 방식의 압축뿐만 아니라 저밀도 볼륨들을 한데 묶어 대량으로 정리할 수 있는 유연한 압축 전략을 병행 구축하는 것이 인프라 비용 최적화의 핵심입니다.

dropbox

개발 속도 향상을 위한 모노레포 크기 줄이기 (새 탭에서 열림)

Dropbox는 87GB에 달하던 서버 모노레포 크기를 20GB로 약 77% 줄여 개발자 속도와 CI 효율성을 획기적으로 개선했습니다. 이 과정에서 Git의 기본 델타 압축 알고리즘이 특정 디렉토리 구조에서 비효율적으로 작동한다는 점을 발견했으며, GitHub 팀과 협력하여 최적화된 리팩(Repack) 설정을 적용해 저장소 용량 한계 문제를 해결했습니다. 결과적으로 1시간 이상 걸리던 클론 시간을 15분 미만으로 단축하며 운영상의 리스크를 제거했습니다. ### 대규모 모노레포 성장이 유발하는 운영 병목 - 저장소 크기가 87GB를 넘어서면서 초기 개발 환경 구축을 위한 클론 시간이 1시간을 초과했고, 이는 매번 신규 클론을 수행하는 CI(지속적 통합) 파이프라인의 성능 저하로 이어졌습니다. - 코드 데이터는 매일 20~60MB씩 증가하며 GitHub Enterprise Cloud의 하드 리밋인 100GB에 근접해 가고 있었으며, 이는 단순한 코드 양의 증가라기보다 저장 방식의 구조적 결함에 의한 현상이었습니다. - 내부 동기화 시스템의 타임아웃 발생 빈도가 높아지는 등 저장소 크기 자체가 엔지니어링 루프 전체를 느리게 만드는 핵심 원인이 되었습니다. ### Git 델타 압축 알고리즘과 디렉토리 구조의 충돌 - Git은 파일 간의 차이점(Delta)만 저장하여 용량을 줄이는데, 비교 대상 파일을 선정할 때 파일 경로의 '마지막 16자'만을 참조하는 휴리스틱 방식을 사용합니다. - Dropbox의 다국어(i18n) 파일 구조는 `i18n/[언어코드]/LC_MESSAGES/[파일명].po` 형태였는데, 언어 코드가 경로 중간에 있어 Git은 서로 다른 언어의 동일 파일명을 가진 파일들을 비교 대상으로 묶었습니다. - 내용이 전혀 다른 언어 간의 파일을 비교하다 보니 압축 효율이 극도로 낮아졌고, 아주 작은 번역 수정에도 불필요하게 큰 팩(Pack) 파일이 생성되는 결과로 이어졌습니다. ### GitHub 서버 측 리팩 최적화를 통한 문제 해결 - 실험적 플래그인 `--path-walk`를 사용하면 파일 경로 전체를 탐색해 압축 효율을 극대화할 수 있음을 로컬 테스트로 확인했으나, 이는 GitHub 서버의 비트맵 및 델타 아일랜드 최적화 기능과 호환되지 않았습니다. - 로컬에서 최적화하여 푸시하더라도 GitHub 서버가 전송 시 자체 설정으로 다시 팩을 구성하기 때문에, GitHub 지원팀과 협력하여 서버 측 리팩 설정을 조정하는 방식을 택했습니다. - Git이 더 넓고 깊게 유사성을 검색할 수 있도록 `window`와 `depth` 매개변수를 각각 250으로 상향 조정한 공격적인 리팩을 수행하여, 데이터 손실 없이 저장소 크기를 20GB 수준으로 압축하는 데 성공했습니다. ### 대규모 저장소 관리를 위한 제언 - 모노레포의 크기가 비정상적으로 급증한다면 단순한 바이너리 파일 유입뿐만 아니라, Git의 델타 압축 메커니즘과 현재의 디렉토리 구조가 상충하고 있지는 않은지 점검해야 합니다. - 저장소 최적화는 클라이언트 단의 노력만으로는 한계가 있으며, 호스팅 서비스(GitHub 등)의 서버 측 리팩 설정과 인프라 호환성을 반드시 고려하여 전략을 수립해야 합니다.

dropbox

DSPy를 사용하여 Dash의 관련성 판별기를 최적화한 방법 (새 탭에서 열림)

Dropbox는 검색 및 답변 서비스인 Dash의 핵심 기능인 '관련성 판단 모델(relevance judge)'을 최적화하기 위해 DSPy 프레임워크를 도입했습니다. 기존의 수동 프롬프트 엔지니어링 방식에서 벗어나, 인간의 평가 점수와 모델 점수 간의 차이를 최소화하는 체계적인 최적화 루프를 구축함으로써 더 저렴한 오픈 소스 모델에서도 고성능을 유지할 수 있게 되었습니다. 결과적으로 모델 교체 시 발생하는 성능 저하 문제를 해결하고, 대규모 데이터 처리를 위한 비용 효율성과 신뢰성을 동시에 확보했습니다. **인간 평가 기반의 성능 측정 체계** * 관련성 판단 모델은 쿼리와 문서의 연관성을 1~5점 척도로 할당하며, 이를 인간 평가자의 점수와 비교하여 성능을 측정합니다. * 주요 평가지표로 NMSE(Normalized Mean Squared Error)를 사용하며, 이는 AI 점수가 인간의 판단에서 얼마나 벗어나는지를 0~100 사이의 수치로 나타냅니다. * 단순 점수 외에도 프로덕션 환경에서의 안정성을 위해 JSON 출력 형식이 올바른지, 구조적 가이드라인을 준수하는지를 엄격히 관리합니다. **고비용 모델에서 효율적인 모델로의 이식** * 초기에는 성능이 뛰어난 OpenAI의 o3 모델을 사용했으나, 서비스 규모가 확장됨에 따라 수천 배 더 많은 데이터 처리를 위한 비용 절감이 필요해졌습니다. * 상대적으로 저렴한 gpt-oss-120b 모델로 이전을 시도했으나, 기존 고성능 모델에 최적화된 프롬프트가 그대로 작동하지 않아 성능 저하가 발생했습니다. * 이를 해결하기 위해 수동으로 프롬프트를 수정하는 대신, DSPy를 통해 특정 모델에 최적화된 프롬프트를 자동 생성하는 방식을 선택했습니다. **DSPy와 GEPA를 활용한 프롬프트 최적화** * DSPy의 GEPA(Generalized Evaluation-based Prompt Adaptation) 옵티마이저를 사용하여 모델이 인간과 다른 판단을 내린 지점을 분석하고 피드백을 생성합니다. * 모델의 예측 점수와 인간의 점수 차이, 그리고 인간의 작성 이유(Rationale)를 결합하여 구체적인 피드백 루프를 구성합니다. * 피드백 과정에서 특정 키워드에 과적합(Overfitting)되지 않도록 일반적인 규칙을 도출하며, "최신성을 과소평가함"이나 "키워드 일치에 과도하게 비중을 둠" 같은 구체적인 오류 패턴을 수정합니다. * 이 최적화 루프는 '평가-피드백-프롬프트 수정-재평가' 과정을 반복하며 목표 지표인 NMSE를 최소화하는 최적의 프롬프트를 찾아냅니다. **결론 및 권장사항** LLM 시스템을 프로덕션 수준으로 확장할 때 가장 큰 장애물은 모델 변경이나 프롬프트 수정 시 발생하는 예기치 못한 성능 저하입니다. Dropbox의 사례처럼 DSPy와 같은 프레임워크를 활용해 프롬프트 엔지니어링을 '체계적인 최적화 프로세스'로 전환하면, 모델 이식성을 높이고 운영 비용을 획기적으로 낮추면서도 품질을 일정하게 유지할 수 있습니다. 특히 대규모 관련성 평가가 필요한 시스템이라면 수동 튜닝 대신 측정 가능한 지표 중심의 자동화된 최적화 루프를 구축하는 것을 권장합니다.

dropbox

LLM을 활용한 인간 (새 탭에서 열림)

Dropbox Dash는 검색 관련성(Relevance)을 높이기 위해 소수의 고품질 인간 라벨링 데이터를 LLM을 통해 대규모로 증폭시키는 하이브리드 학습 전략을 채택하고 있습니다. 이 방식은 LLM을 '교사 모델'로 활용하여 수백만 개의 학습 데이터를 생성하고, 이를 통해 실시간 서비스에 적합한 효율적인 랭킹 모델을 구축하는 데 목적이 있습니다. 결과적으로 인간의 판단력과 AI의 확장성을 결합하여 RAG(검색 증강 생성) 시스템의 답변 품질을 결정짓는 핵심 요소인 검색 정확도를 극대화했습니다. ## Dash 검색 순위 모델과 학습 방식 * Dash는 수작업으로 조정된 규칙이 아닌, XGBoost와 같은 머신러닝 기법을 활용하여 검색 결과의 순위를 결정합니다. * 모델은 검색어와 문서 쌍에 대해 1점(관련 없음)부터 5점(매우 관련 있음)까지의 점수를 부여하는 관련성 라벨을 학습하며, 점수가 높은 문서가 상단에 배치되도록 가중치를 조정합니다. * 기업 내 수억 개의 문서 중 LLM이 답변 생성에 사용할 최적의 소수 문서만 선별해야 하므로, 랭킹 모델을 학습시키는 데이터의 품질이 RAG 시스템 전체의 성능을 좌우합니다. ## 기존 라벨링 방식의 한계와 LLM 도입의 필요성 * **사용자 행동 데이터:** 클릭이나 이탈 정보는 유용하지만, 기존 순위에 영향을 받거나 데이터가 불균등하게 분포되는 편향성 문제가 있습니다. * **인간 라벨링:** 숙련된 검토자가 직접 점수를 매기는 방식은 가장 정확하지만, 비용이 많이 들고 확장이 어려우며 기업의 민감한 내부 데이터를 외부 인력이 검토하기 어렵다는 보안 이슈가 존재합니다. * **LLM 평가:** LLM은 인간보다 비용이 저렴하고 일관성이 있으며, 대규모 후보군을 다국어로 신속하게 처리할 수 있습니다. 또한 정의된 규정 준수 범위 내에서 고객 콘텐츠를 분석할 수 있는 장점이 있습니다. ## 인간과 LLM의 협업을 통한 데이터 증폭 과정 * **검증 및 보정:** 먼저 인간 검토자가 소규모의 고품질 데이터셋을 라벨링합니다. 이 데이터는 LLM의 프롬프트와 매개변수를 미세 조정하고 성능을 검증하는 '골드 표준'으로 사용됩니다. * **데이터 증폭:** 성능이 검증된 LLM은 인간의 노력을 수백 배로 증폭시켜 수십만에서 수백만 개의 관련성 라벨을 생성합니다. 인간이 LLM을 가르치고, LLM이 대규모 학습 데이터를 생산하는 구조입니다. * **오프라인 학습과 온라인 서빙:** 실시간 검색 시 LLM을 직접 사용하면 지연 시간(Latency)과 비용 문제가 발생합니다. 따라서 LLM은 오프라인에서 '교사'로서 대량의 데이터를 생성하고, 실제 서비스에서는 이 데이터를 학습한 가볍고 빠른 모델(XGBoost 등)이 검색 순위를 계산합니다. ## 실용적인 결론 성공적인 AI 검색 시스템을 구축하기 위해서는 단순히 최신 LLM을 사용하는 것에 그치지 않고, 검색 모델의 학습 데이터를 어떻게 확보할 것인지가 중요합니다. Dropbox Dash의 사례처럼 **"인간의 가이드라인 → LLM의 대규모 라벨링 → 경량 모델의 학습 및 서빙"**으로 이어지는 파이프라인을 구축하면 품질, 비용, 속도라는 세 가지 토끼를 동시에 잡을 수 있습니다.

dropbox

저비트 추론이 효율 (새 탭에서 열림)

AI 모델의 규모가 조 단위 파라미터로 급격히 팽창함에 따라 메모리, 연산 자원, 에너지 수요가 폭증하고 있습니다. 저정밀도(Low-bit) 추론은 모델의 수치 정밀도를 낮춰 메모리 점유율을 줄이고 연산 속도를 획기적으로 높이는 핵심 기술로, 대규모 모델을 상용 환경에서 경제적으로 구동하기 위한 필수 요소입니다. 하드웨어의 가속 기능을 최대로 활용하는 양자화 기법을 통해 기업은 사용자에게 더 빠르고 효율적인 AI 서비스를 제공할 수 있습니다. ### 현대 모델 아키텍처와 연산 비용의 상관관계 * **어텐션 기반 구조의 연산 부하**: Dropbox Dash와 같은 서비스에서 쓰이는 모델은 텍스트, 이미지, 비디오를 처리하기 위해 대량의 행렬 곱셈을 수행하며, 특히 선형 레이어(MLP, 임베딩)와 어텐션 메커니즘에서 대부분의 연산 자원이 소모됩니다. * **하드웨어 가속기 활용**: NVIDIA의 Tensor Core나 AMD의 Matrix Core는 이러한 행렬 연산을 전용 지시어(MMA)로 처리하여 일반 CUDA 코어보다 훨씬 높은 성능을 냅니다. * **정밀도에 따른 성능 스케일링**: 하드웨어 특성상 수치 정밀도를 절반으로 줄이면 초당 부동 소수점 연산량(FLOPS)이 약 두 배로 증가하여 처리량(Throughput)이 직접적으로 향상됩니다. ### 양자화 기술의 작동 원리와 성능 이점 * **메모리 및 에너지 효율화**: 16비트 데이터를 8비트나 4비트로 변환(양자화)하면 메모리 사용량이 절반 이하로 줄어들며, 데이터 이동과 연산에 필요한 전력 소비도 크게 절감됩니다. * **비트패킹(Bitpacking)**: 4비트와 같은 저비트 형식은 하드웨어에서 기본 데이터 타입으로 지원하지 않는 경우가 많아, 여러 개의 저비트 요소를 uint8이나 int32 같은 표준 타입으로 묶어서 처리하는 과정이 필요합니다. * **처리량 최적화**: 정밀도를 낮추면 동일한 시간 내에 더 많은 행렬 연산이 가능해지므로, 대규모 사용자 요청을 처리해야 하는 서비스 환경에서 지연 시간을 단축하고 비용을 절감할 수 있습니다. ### 양자화 포맷의 유형과 하드웨어 제약 * **이진(Binary) 및 삼진(Ternary) 가중치의 한계**: 이론적으로는 극도로 높은 에너지 효율을 제공하지만, 현재의 GPU 아키텍처(Tensor Core 등)와 잘 맞지 않아 실제 산업 현장에서는 채택률이 낮고 모델 품질 유지도 어렵습니다. * **MXFP(Microscaling Format)의 등장**: 기존 양자화가 소프트웨어 기반의 역양자화에 의존했다면, 차세대 표준인 MXFP는 하드웨어 레벨에서 직접 저비트 데이터를 관리하고 스케일링하여 하드웨어 가속 효율을 극대화합니다. * **워크로드별 맞춤 최적화**: 서비스의 특성에 따라 지연 시간(Latency)이 중요한지, 혹은 대량 처리(Throughput)가 중요한지에 따라 적합한 양자화 포맷과 하드웨어 세대가 달라집니다. 양자화는 단순히 모델 크기를 줄이는 것을 넘어, 하드웨어 성능을 한계까지 끌어올리는 전략적 도구입니다. 최신 GPU의 FP4 지원이나 MXFP 같은 표준 포맷을 적극 활용하면, 모델의 정확도를 유지하면서도 운영 비용을 획기적으로 낮출 수 있습니다. 따라서 모델 배포 시에는 타겟 하드웨어가 지원하는 가속 비트 수와 양자화 형식을 사전에 면밀히 검토하는 것이 권장됩니다.

dropbox

AI 및 엔지니어링 생산성에 (새 탭에서 열림)

Dropbox는 AI 도구를 단순한 실험을 넘어 비즈니스 가치 창출을 위한 핵심 전략으로 채택하고 있으며, 이를 통해 엔지니어링 생산성의 비약적인 향상을 꾀하고 있습니다. 최근 개최된 경영진 라운드테이블을 통해 AI 도입이 코드 리뷰와 디버깅 등 개발 전반의 효율을 높이는 동시에, 품질 유지와 비즈니스 성과 연결이라는 새로운 도전 과제를 제시하고 있음을 확인했습니다. 결과적으로 성공적인 AI 전환을 위해서는 기술적 도입뿐만 아니라 리더십의 조율과 조직적 프레임워크의 변화가 반드시 병행되어야 한다는 결론을 도출했습니다. ### AI를 통한 Dropbox의 생산성 가속화 전략 * **전사적 우선순위 설정:** AI 도입을 단순한 풀뿌리 수준의 실험이 아닌 회사 차원의 핵심 과제로 격상하여 리더십의 지지를 확보하고, 새로운 도구 도입을 위한 계약 및 승인 절차를 대폭 간소화했습니다. * **자체 AI 플랫폼 구축:** 대규모 다국어 모노레포(Monorepo)라는 특수한 환경에 맞추기 위해 기성 AI 도구에만 의존하지 않고, 풀 리퀘스트(PR) 빌드 실패 시 AI가 자동으로 수정안을 제안하는 자체 도구를 개발하여 운영 중입니다. * **데이터 기반의 성과 추적:** 엔지니어당 월간 PR 처리량(Throughput)을 핵심 지표로 설정하여 AI 도구 활용도가 높은 그룹의 생산성이 월등히 높음을 확인했으며, 내부 설문을 통해 개발자들의 긍정적인 감성 지표 변화를 모니터링하고 있습니다. * **개발자 자율성 부여:** 팀별로 최적의 도구를 선택할 수 있는 유연성을 제공하여 도입 과정에서의 마찰을 줄이고, 소프트웨어 개발 생애 주기(SDLC) 전반에서 AI가 자연스럽게 스며들 수 있도록 지원합니다. ### AI 시대의 엔지니어링 리더십과 조직 운영 * **균형 잡힌 생산성 관리:** AI로 인한 속도 향상이 코드 품질 저하나 장기적인 유지보수 비용 상승으로 이어지지 않도록 생산성과 품질 사이의 엄격한 균형 감각이 요구됩니다. * **리더십 정렬과 규범화:** 기술 리더십은 효과적인 AI 사용 규범을 설정하고 집행하는 중추적인 역할을 수행해야 하며, AI 배포 속도에 대해 경영진과 명확한 공감대를 형성해야 합니다. * **인적 역량의 공식적 평가:** AI 활용 능력을 엔지니어의 경력 개발 프레임워크(Career Framework)에 공식적으로 포함시켜 조직의 전략적 방향성을 명확히 하고, 비개발 직군의 생산성 향상으로도 그 범위를 확장하고 있습니다. ### 향후 과제 및 실무적 제언 * **유휴 용량의 전략적 재투자:** AI가 확보해 준 엔지니어링 여력을 기술 부채 해결, 시스템 마이그레이션, 서비스 신뢰성 강화 등 고부가가치 영역에 우선적으로 투입해야 합니다. * **비즈니스 성과와의 직접 연결:** 단순히 "코딩 속도가 빨라졌다"는 지표를 넘어, 향후에는 생산성 향상이 실제 비즈니스 결과물과 제품 출시 속도(Velocity)에 어떻게 기여하는지 직접적으로 매핑하는 운영 모델을 구축하는 것이 핵심입니다.

dropbox

엔지니어링 VP 조 (새 탭에서 열림)

Dropbox Dash는 파편화된 기업 내 데이터를 통합하여 사용자에게 최적화된 답변을 제공하기 위해 인덱스 기반의 '컨텍스트 엔진(Context Engine)'과 지식 그래프를 핵심 기술로 활용합니다. 단순히 데이터를 검색하는 것을 넘어 멀티모달 이해와 데이터 간의 관계 모델링을 통해 고도화된 업무 맥락을 파악하며, MCP(Model Context Protocol)가 가진 성능적 한계를 독자적인 최적화 기법으로 해결했습니다. 이를 통해 보안과 권한 관리를 유지하면서도 매우 빠르고 정확한 에이전트 경험을 제공하는 것이 기술적 결론입니다. ### 컨텍스트 엔진의 구조와 데이터 처리 * **커넥터와 정규화**: 수많은 서드파티 앱의 API 제약과 권한 체계(ACL)를 처리하는 맞춤형 크롤러를 통해 데이터를 수집하고, 이를 마크다운 형식으로 정규화하여 관리합니다. * **멀티모달 콘텐츠 이해**: 단순 텍스트 추출을 넘어 이미지(CLIP 및 멀티모달 모델), 오디오(전사), 비디오(장면 추출 및 이해)에 대한 심층 분석을 수행하여 인덱싱합니다. * **지식 그래프 모델링**: 문서, 회의, 인물 간의 관계를 그래프 형태로 연결하여 단순 검색 이상의 맥락 정보를 생성하며, 이를 통해 앱 간 경계를 넘나드는 지능형 정보를 제공합니다. * **하이브리드 검색**: 어휘 검색을 위한 BM25와 의미론적 검색을 위한 밀집 벡터(Dense Vector) 저장소를 동시에 사용하여 검색 품질을 극대화하고, 최종 결과에 대해 개인화된 랭킹을 적용합니다. ### 인덱스 기반 검색(Indexed Retrieval)의 채택 이유 * **페더레이션 방식과의 차이**: 실시간으로 외부 API를 호출하는 페더레이션 방식은 구현이 쉽고 데이터가 신선하지만, 속도가 느리고 회사 전체 공유 데이터에 접근하기 어렵다는 단점이 있습니다. * **성능과 실험 가능성**: 인덱스 기반 방식은 데이터를 미리 처리해두기 때문에 응답 속도가 매우 빠르며, 오프라인 환경에서 다양한 랭킹 실험을 통해 검색 정확도(Recall)를 지속적으로 개선할 수 있습니다. * **구축 비용 감수**: 높은 저장 비용과 맞춤형 커넥터 개발의 복잡성에도 불구하고, 풍부한 데이터 세트 구축과 정교한 검색 품질을 위해 인덱스 기반 접근법을 선택했습니다. ### MCP의 한계 극복과 에이전트 최적화 * **컨텍스트 부패 방지**: MCP 도구 정의가 컨텍스트 창(Context Window)을 과도하게 점유하여 발생하는 성능 저하 문제를 해결하기 위해 약 10만 토큰 수준으로 컨텍스트를 제한하고 관리합니다. * **응답 속도 개선**: 일반적인 MCP 에이전트가 여러 도구를 호출할 때 발생하는 지연 시간(최대 45초)을 줄이기 위해, 원본 인덱스에 직접 접근하여 수 초 내에 결과를 반환하도록 설계했습니다. * **슈퍼 툴(Super Tool) 개념**: 개별 앱마다 도구를 정의하는 대신, 전체 인덱스를 아우르는 '슈퍼 툴' 인터페이스를 구축하여 모델이 추론해야 할 도구의 개수를 줄이고 효율성을 높였습니다. 기업용 AI 에이전트를 구축할 때는 실시간 API 호출 방식보다는 비용이 들더라도 데이터를 직접 인덱싱하고 지식 그래프화하는 것이 검색 품질과 속도 면에서 유리합니다. 특히 MCP와 같은 최신 프로토콜을 도입할 때는 도구 정의가 컨텍스트 창을 잠식하지 않도록 '슈퍼 툴' 형태의 추상화 계층을 고려하는 것이 실무적으로 권장됩니다.

dropbox

Dropbox Dash의 실시간 (새 탭에서 열림)

Dropbox Dash는 흩어져 있는 업무 데이터를 통합하여 실시간으로 답변과 검색 결과를 제공하는 AI 도구이며, 이 시스템의 핵심은 머신러닝 모델에 필요한 데이터 신호인 '피처(Feature)'를 관리하고 전달하는 피처 스토어입니다. 수만 개의 문서 중 가장 관련성 높은 정보를 순위화하기 위해 드롭박스는 온프레미스와 클라우드가 결합된 하이브리드 인프라 위에서 초저지연 읽기와 실시간 데이터 업데이트가 가능한 독자적인 피처 스토어를 구축했습니다. 결과적으로 이 시스템은 수천 개의 피처를 병렬로 조회하면서도 100ms 미만의 응답 속도를 유지하여 사용자에게 최적화된 검색 경험을 제공합니다. ### 하이브리드 인프라를 위한 설계 목표와 요구사항 * **복합적인 인프라 환경 대응:** 저지연 통신을 위한 온프레미스 에코시스템과 대규모 데이터 처리를 위한 Spark 기반 클라우드 환경을 동시에 지원해야 했습니다. * **대규모 병렬 조회 처리:** 사용자 쿼리 하나당 수천 건의 피처 룩업(Lookup)이 발생하므로, 엄격한 지연 시간 예산 내에서 막대한 병렬 읽기를 처리할 수 있는 구조가 필요했습니다. * **실시간성 확보:** 사용자의 최근 행동(문서 열람, 채널 참여 등)이 몇 초 내에 다음 검색 결과에 반영될 수 있도록 빠른 데이터 수집 파이프라인이 요구되었습니다. * **통합 프레임워크 구축:** 실시간 스트리밍과 배치 처리를 통합하여 엔지니어가 아이디어 단계부터 실제 배포까지 빠르게 진행할 수 있는 환경을 목표로 했습니다. ### Feast와 Dynovault를 활용한 아키텍처 설계 * **Feast 프레임워크 채택:** 피처 정의와 인프라 구현을 분리하고 모듈화된 어댑터 생태계를 가진 Feast를 선택하여 인프라 복잡성을 추상화했습니다. * **Dynovault 활용:** 드롭박스 자체 개발 DynamoDB 호환 스토리지인 Dynovault를 온라인 저장소로 사용하여 공용 인터넷 호출 없이 약 20ms의 클라이언트 지연 시간을 달성했습니다. * **관측 가능성 강화:** 작업 실패 모니터링, 데이터 신선도 추적, 데이터 계보(Lineage) 가시성 등을 추가하여 안정적인 운영 기반을 마련했습니다. ### Go 언어 재작성을 통한 성능 최적화 * **Python SDK의 한계 극복:** 초기 Python 기반 구현에서는 JSON 파싱 속도와 GIL(Global Interpreter Lock)로 인해 동시성 처리에 병목이 발생했습니다. * **고성능 서빙 레이어 구축:** 서빙 레이어를 Go 언어로 재작성하고 가벼운 고루틴(Goroutine)과 공유 메모리를 활용하여 동시성 성능을 극대화했습니다. * **지연 시간 단축:** 최적화 결과 p95 기준 지연 시간을 25~35ms 수준으로 유지하며, 초당 수천 개의 요청을 처리할 수 있는 확장성을 확보했습니다. ### 효율적인 데이터 신선도 유지 전략 * **계층화된 수집 방식:** 복잡한 연산이 필요한 데이터는 메달리온 아키텍처(Medallion architecture) 기반의 배치 수집을, 실시간 신호는 스트리밍 방식을 병행합니다. * **지능형 변경 감지:** 모든 데이터를 매번 다시 쓰는 대신 변경된 레코드만 온라인 스토어에 기록하는 방식을 도입했습니다. * **비용 및 성능 최적화:** 변경 감지 기술을 통해 쓰기 작업량을 수억 건에서 백만 건 미만으로 줄여 업데이트 시간을 단축하고 인프라 부하를 최소화했습니다. 이러한 드롭박스의 접근 방식은 기성 제품을 그대로 사용하기보다 오픈소스를 활용해 내부 인프라에 최적화된 형태로 커스터마이징하는 것이 대규모 AI 서비스 운영에 얼마나 중요한지를 잘 보여줍니다. 특히 성능 병목 지점을 정확히 파악하여 서빙 레이어를 Go로 전환한 결정은 지연 시간에 민감한 실시간 랭킹 시스템 구축 시 고려해 볼 만한 전략입니다.

dropbox

미래를 구축하다: Dropbox (새 탭에서 열림)

드롭박스는 2025년 여름 인턴십 프로그램을 통해 43명의 인턴과 함께 AI 기반 통합 검색 도구인 '드롭박스 대시(Dropbox Dash)'를 비롯한 핵심 서비스의 성능과 인프라를 혁신했습니다. 엔지니어링 중심의 이번 기수들은 12주간 멘토링과 실무 프로젝트에 참여하며, 특히 AI 모델의 신뢰성 강화와 다국어 검색 지원 등 드롭박스의 차세대 기술 역량을 끌어올리는 데 기여했습니다. 결과적으로 이번 프로그램은 인턴들에게는 실질적인 기술적 성장을, 기업에는 레거시 시스템 현대화와 운영 효율화라는 실용적 성과를 동시에 안겨주었습니다. ### 드롭박스 대시와 AI 기술 고도화 * **다국어 검색 지원 확대**: 통합 검색 플랫폼(USP)에 언어 감지 파이프라인을 통합하여 리플레이(Replay) 등 드롭박스 제품 전반에 걸쳐 20개 이상의 언어를 지원하는 네이티브 검색 환경을 구축했습니다. * **ML 모델 모니터링 시스템(AI Sentinel)**: 머신러닝 엔지니어가 수동으로 확인하던 모델 배포 상태를 실시간으로 가시화하는 시스템을 개발하여 배포의 신뢰성을 높이고 반복 주기를 단축했습니다. * **커넥터 플랫폼 최적화**: 대시의 데이터 저장소에서 최신 정보에 직접 접근할 수 있는 도구를 빌드하여, 외부 시스템의 데이터를 매번 다시 다운로드하지 않고도 최신 메타데이터 기반으로 모델을 학습시킬 수 있게 했습니다. * **문서 미리보기 및 웹 자동화**: 대시 내에서 문서를 즉시 미리 볼 수 있는 UI와 대화형 AI 기능을 통합하고, 폼 채우기나 교정 등의 반복 업무를 자동화하는 모듈형 AI 에이전트를 개발했습니다. ### 인프라 성능 및 데이터 효율화 * **스토리지 코어(Magic Pocket) 지연 시간 단축**: 디스크 재시작 시 발생하는 쓰기 지연 문제를 해결하기 위해 스토리지 상태를 추적하는 캐시와 성능이 저하된 볼륨을 제외하는 필터링 옵션을 추가하여 검색 결과의 정확도를 높였습니다. * **파일 시스템 메타데이터 리팩토링**: 레거시 파일 이력 추적 시스템을 현대화하여 메타데이터 인프라를 단순화하고 운영 비용을 대폭 절감했습니다. * **대규모 데이터 분석 최적화**: Databricks 쿼리와 ETL 파이프라인의 고비용 패턴을 식별하는 추천 시스템을 구축하고, 500TB 규모의 모바일 이벤트 로그를 최신 데이터 레이아웃 기술인 '리퀴드 클러스터링(Liquid Clustering)'으로 마이그레이션했습니다. ### 개발자 경험 및 운영 도구 개선 * **AI 기반 코드 마이그레이션**: 특정 폴더나 유형에 대해 코드 마이그레이션을 자동화하고 결과가 성공적일 경우 자동으로 Pull Request를 생성하는 도구를 제작하여 대규모 마이그레이션 작업을 효율화했습니다. * **지능형 지표 감지 시스템(Vortex2)**: 고정된 임계값 대신 데이터의 계절성과 변화 패턴을 학습하는 적응형 이상 탐지 기법을 도입하여 알림 피로도를 줄이고 장애 대응 속도를 개선했습니다. 이러한 인턴들의 성과는 드롭박스가 단순한 파일 저장소를 넘어 AI 중심의 워크플로우 플랫폼으로 진화하고 있음을 보여줍니다. 특히 대규모 마이그레이션 자동화나 인프라 수준의 지연 시간 최적화와 같은 실무적인 기술 해결책은 엔지니어링 팀의 생산성을 직접적으로 높이는 실용적인 결론을 도출했습니다.

dropbox

Dash가 더 스마트한 AI를 위해 (새 탭에서 열림)

Dropbox Dash는 단순한 검색 시스템을 넘어 사용자의 의도를 이해하고 실행하는 에이전트형 AI로 진화하면서, 모델에 제공되는 정보를 정교하게 관리하는 '컨텍스트 엔지니어링'을 핵심 전략으로 채택했습니다. 단순히 많은 정보를 제공하는 것이 아니라 모델이 추론하고 행동하는 데 꼭 필요한 정보만을 선별하여 전달함으로써, AI의 '분석 마비' 현상과 토큰 낭비를 방지했습니다. 결과적으로 이러한 전략적 컨텍스트 관리는 모델의 판단 속도와 작업 정확도를 동시에 높이는 성과를 거두었습니다. ### 도구 정의의 최소화와 통합 인터페이스 구축 * 모델에게 너무 많은 API 호출 선택지를 주면 판단 속도가 느려지고 정확도가 떨어지는 현상이 발생했습니다. 이를 해결하기 위해 개별 서비스(Confluence, Jira, Google Docs 등)의 검색 도구를 하나로 묶은 '유니버설 검색 인덱스' 기반의 단일 도구를 구축했습니다. * Model Context Protocol(MCP)을 활용하여 도구 설명을 간결하게 유지함으로써, 모델의 컨텍스트 창(Context Window)이 사용자 요청이라는 본연의 목적에 더 많이 할애되도록 설계했습니다. * 하나의 일관된 인터페이스를 통해 정보를 검색하게 함으로써 모델의 계획 수립 과정을 단순화하고 효율성을 극대화했습니다. ### 지식 그래프를 통한 맥락적 데이터 필터링 * 단순히 여러 API에서 데이터를 가져오는 것에 그치지 않고, 검색된 결과 중 가장 관련성 높은 정보만 모델에 전달되도록 필터링 시스템을 강화했습니다. * 통합 인덱스 위에 사람, 활동, 콘텐츠 간의 관계를 연결한 '지식 그래프'를 구축하여 사용자별 맞춤형 순위 산출이 가능하게 했습니다. * 모델이 런타임에 방대한 정보를 직접 분석하는 대신, 이미 관계가 정립된 고가치 정보만 수신함으로써 추론의 질을 높이고 성능 저하를 방지했습니다. ### 복잡한 작업을 위한 전담 에이전트 도입 * 검색 쿼리 생성과 같이 복잡한 지침과 예시가 필요한 작업은 메인 모델의 컨텍스트 창을 과도하게 점유하는 문제를 일으켰습니다. * 이를 해결하기 위해 메인 에이전트는 전체적인 계획만 세우고, 구체적인 쿼리 작성은 별도의 '전담 에이전트'에게 위임하는 구조를 도입했습니다. * 역할 분담을 통해 메인 모델은 복잡한 세부 사항에 매몰되지 않고 전체 작업의 흐름에 집중할 수 있으며, 각 에이전트는 자신에게 할당된 컨텍스트 내에서 최적의 결과를 도출합니다. 효과적인 에이전트형 AI를 구축하기 위해서는 무조건 많은 데이터를 입력하기보다 모델이 처리해야 할 정보의 양과 질을 전략적으로 제어해야 합니다. 도구의 통합, 지식 그래프 기반의 정교한 필터링, 그리고 전문 에이전트로의 역할 분담은 성능 향상과 비용 절감을 동시에 달성할 수 있는 실무적인 context engineering 방안이 될 것입니다.