toss·2026년 8월 10일·5분 읽기큐레이션 요약

모노리포 희망편, 절망의 리포가 희망의 리포로 부활하기까지 걸린 1년

토스는 100명 이상의 프론트엔드 엔지니어가 여러 제품을 개발하면서도 React 19, Next.js 15 등 동일한 개발환경을 유지하기 위해 모노리포와 의존성 카탈로그를 활용하고 있습니다. 단순히 모노리포를 사용하는 것만으로는 서비스별 의존성 버전 파편화와 느린 설치 속도 문제를 해결할 수 없었기 때문에, 핵심 라이브러리 버전을 표준화하는 카탈로그 전략을 도입했습니다. 그 결과 의존성 규모와 설치 시간이 크게 줄었고, 플랫폼 변경과 최신 기술 도입도 더 안전하고 빠르게 진행할 수 있게 되었습니다. ## 모노리포가 제공한 개발 일관성 - 토스의 모바일 제품 코드는 하나의 모노리포로 통합되어 있습니다. - 모든 서비스가 React, Next.js, TypeScript, 번들러, Linter 등 유사한 버전을 사용하도록 관리되었습니다. - 이를 통해: - React Concurrent Mode, React Server Components 같은 최신 기능을 여러 서비스에서 활용할 수 있습니다. - 서비스 간 공통 코드와 플랫폼 라이브러리를 쉽게 공유할 수 있습니다. - 플랫폼 변경사항을 전체 서비스에 일관되게 전파할 수 있습니다. - 제품이 많아도 동일한 개발환경을 유지해 사용자 경험과 개발자 경험을 함께 개선하는 것이 목표였습니다. ## 모노리포만으로 해결되지 않은 문제 - 서비스마다 React와 각종 라이브러리의 버전이 달라 의존성 트리가 복잡했습니다. - 오래된 서비스는 낡은 개발환경을 계속 사용하게 되어 개발 서버 속도와 API 사용성에서 큰 차이가 났습니다. - 의존성 종류와 버전이 많아 설치에 캐시가 있어도 1분 이상 걸리는 경우가 있었습니다. - 플랫폼 팀은 다양한 React 및 라이브러리 조합을 모두 테스트해야 했기 때문에 공통 라이브러리 변경이 어려웠습니다. - 서비스 개발자도 업데이트 후 문제가 발생할 가능성을 우려해 플랫폼 라이브러리 업데이트를 기피했습니다. - 결과적으로 오래된 의존성이 고착되고, 서비스와 플랫폼 양쪽의 유지보수 비용이 커졌습니다. ## 폴리리포의 한계 - 모노리포를 여러 개의 독립적인 리포지토리로 나누면 각 저장소의 의존성과 설치 부담은 줄어듭니다. - 그러나 다음 문제는 오히려 남거나 심해질 수 있습니다. - 서비스별 개발환경 파편화 - 공통 코드 공유와 업데이트 비용 증가 - 서비스마다 다른 개발 경험 - 플랫폼 변경사항의 일관된 전파 어려움 - 토스는 지속적으로 플랫폼을 유지보수하고 최신화해야 하므로, 폴리리포보다는 기존 모노리포의 의존성 문제를 해결하는 방향을 선택했습니다. ## 핵심 해결책: 의존성 버전 표준화 - 가장 근본적인 문제를 “서비스마다 핵심 의존성 버전이 모두 다르다”는 점으로 정의했습니다. - React, 컴포넌트 라이브러리(TDS), 상태 관리 라이브러리(Jotai), TypeScript, ESLint 등 약 10~20개의 주요 라이브러리를 표준화 대상으로 삼았습니다. - 핵심 의존성 버전을 통일하면: - 설치해야 할 의존성의 종류와 개수가 줄어듭니다. - 모든 서비스에서 비슷한 개발 경험을 제공합니다. - 플랫폼 라이브러리의 테스트 환경이 단순해집니다. - Breaking change에 대응하는 코드 변환 스크립트나 호환성 레이어를 만들기 쉬워집니다. - 서비스 개발자가 검증된 최신 라이브러리로 업데이트할 유인이 커집니다. - 대부분의 개발자는 “React가 필요하다”고 결정할 뿐 특정 버전을 직접 선택할 필요는 없다는 점도 표준화의 근거가 되었습니다. ## 카탈로그를 통한 버전 관리 - 토스는 서비스에서 권장하는 표준 라이브러리 버전 집합을 **카탈로그(Catalog)**라고 정의했습니다. - pnpm이나 Yarn의 카탈로그 기능을 사용해 모노리포의 공통 버전을 선언합니다. ```yaml catalog: react: ^18.2.0 jotai: ^2.18.1 ``` - 각 서비스는 `catalog:` 프로토콜로 버전을 참조합니다. ```json { "dependencies": { "react": "catalog:", "jotai": "catalog:" } } ``` - 안정 버전과 실험 버전을 별도 카탈로그로 관리할 수도 있습니다. ```yaml catalogs: stable: react: ^18.2.0 jotai: ^2.18.1 beta: react: ^19.1.0 jotai: ^2.20.1 ``` - 이후 서비스는 `catalog:stable`처럼 특정 카탈로그를 선택할 수 있습니다. - React, Next.js, TypeScript, TDS, 토스 앱 SDK 등 핵심 개발 라이브러리부터 카탈로그에 편입했습니다. ## 카탈로그 도입과 운영 방식 - 카탈로그 패키지는 릴리즈 전에 주요 사용 사례를 테스트 페이지로 검증했습니다. - 신규 서비스는 최신 카탈로그를 자동으로 참조하도록 스캐폴딩했습니다. - 개발자가 `yarn add`로 직접 패키지를 추가해도 카탈로그 버전을 사용하도록 했습니다. - 실수로 카탈로그를 사용하지 않는 경우를 CI에서 자동 검출했습니다. - 기존 서비스는 코드 오너와 함께 의존성을 카탈로그 참조 방식으로 일괄 마이그레이션했습니다. - 카탈로그 버전을 변경할 때는 기존 카탈로그를 직접 수정하지 않고 새 버전을 발행했습니다. - 일부 서비스에서 먼저 검증 - 안정성 확인 - 전체 서비스가 새 카탈로그로 수동 마이그레이션 - 업그레이드 비용을 낮추기 위해 코드 수정 스크립트와 AI Skill도 제공했습니다. ## 카탈로그 적용 후의 성과 - 서비스별 의존성 버전이 통일되면서 전체 의존성 규모가 크게 감소했습니다. - Yarn PnP의 `.pnp.cjs` 파일 크기: - 96MB → 15MB - 약 84% 감소 - 개발 서버 실행 시간: - 26.7초 → 20.3초 - 약 23% 개선 - 전체 의존성 설치 시간: - 528.4초 → 249.9초 - 약 52% 감소 ## 검증된 의존성과 구조적 개선 - 카탈로그에 포함된 패키지는 최소 한 개 이상의 서비스에서 동작을 검증해야 하므로 사용 신뢰도가 높아졌습니다. - 패키지 간 의존성도 엄격하게 관리할 수 있게 되었습니다. - 예를 들어 A 패키지가 B의 v1에 의존하는데 서비스가 B의 v2를 사용하는 식의 불일치를 예방할 수 있습니다. - 어떤 서비스가 어떤 버전을 사용하는지 파악하기 쉬워져 패키지 개발자가 대규모 구조 개선을 추진하기 수월해졌습니다. - 그 결과 RSC, TypeScript 7, Rspack, E2E 테스트 같은 급진적인 기술 개선도 비교적 빠르고 안정적으로 도입할 수 있었습니다. - 플랫폼 패키지의 개선사항이 서비스에 전달되는 경로가 표준화되어, 서비스가 최신 플랫폼의 혜택을 더 빠르게 받을 수 있는 기반도 마련되었습니다. ## 실용적인 결론 모노리포의 효과를 극대화하려면 저장소를 하나로 합치는 것만으로는 부족합니다. 핵심 의존성의 버전을 카탈로그로 표준화하고, CI 검증·자동 마이그레이션·단계적 릴리즈를 함께 운영해야 서비스 간 일관성, 설치 성능, 플랫폼 업데이트 속도를 동시에 개선할 수 있습니다.

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

monorepoReactTypeScriptdependency-management+3

toss·2026년 8월 3일·4분 읽기큐레이션 요약

DS와 MLE가 함께 일하는 법

토스뱅크는 DS와 MLE 사이의 역할 경계를 사람이나 파일이 아닌 명시적인 인터페이스로 정의하면서 ML 모델 배포 협업을 개선했습니다. 노트북 전달 방식에서 `.py` 파일 공유를 거쳐, 전처리·추론·후처리를 구현한 모델 패키지를 `pip install`로 배포하는 구조로 발전했습니다. 여기에 모노레포, 공통 추상화, CI, AI 코딩 스타일 규칙을 결합해 배포 속도와 일관성을 높였습니다. ## 노트북 전달 방식의 한계 - Phase 0에서는 DS가 주피터 노트북에서 학습과 추론 코드를 모두 작성하고, MLE가 이를 바탕으로 서빙 코드를 처음부터 다시 작성했습니다. - 라이브러리, 설정 파일, 소스 코드가 흩어져 있어 실행 환경을 재현하기 어려웠습니다. - 노트북에서 동작하던 전처리나 설정을 MLE가 다르게 해석하는 문제가 발생했습니다. - 모델 수가 늘어날수록 파일 요청과 커뮤니케이션 비용이 크게 증가했습니다. - 역할의 경계가 코드가 아니라 사람 사이에 있었기 때문에 책임과 작업 범위가 불명확했습니다. ## `.py` 파일로 추론 로직 분리 - Phase 1에서는 DS가 노트북에서 핵심 추론 로직을 별도의 `.py` 파일로 분리했습니다. - 노트북은 학습과 실험에 집중하고, 실제 모델 로직은 코드 파일로 관리했습니다. - MLE 리뷰와 CI 검증을 거치도록 하면서 DS의 의도를 더 정확히 보존할 수 있었습니다. - 그러나 모델마다 함수 이름이 `predict()`, `run()`, `inference()` 등으로 달라 인터페이스가 통일되지 않았습니다. - 서빙 환경으로 코드를 옮길 때 환경 차이로 수정이 필요했고, 로깅·메트릭·에러 처리를 공통으로 적용하기도 어려웠습니다. - 노트북에서 전역 설정을 변경한 코드가 여러 모델이 실행되는 서빙 프로세스에 영향을 주는 문제도 있었습니다. ## 인터페이스를 통한 역할 분리 - Phase 2에서는 `commons-ml-model` 패키지에 모델의 표준 구조를 정의했습니다. - 추상화 클래스가 다음 세 가지 인터페이스를 제공합니다. - `pre_process`: 입력 데이터 전처리 - `inference`: 모델 추론 - `post_process`: 결과 후처리 - DS는 위 메서드의 구현체를 작성하고 모델을 하나의 패키지로 배포합니다. - MLE는 해당 패키지를 설치해 서비스에 연결하므로 코드를 직접 복사하거나 재작성하지 않습니다. - 추상화 클래스가 추론 전후에 공통으로 다음 기능을 처리합니다. - 요청 추적을 위한 `trace_id` - 추론 시작·완료 로그 - 실행 시간 측정 - 메트릭 기록 - 결과적으로 DS는 모델 동작에 집중하고, MLE는 서비스 인프라와 운영 기능을 담당하게 됐습니다. - 공통 관측 기능을 추상화 클래스 한 곳에서 수정하면 모든 모델에 일괄 적용할 수 있습니다. ## 모노레포와 `uv` 워크스페이스 - 여러 모델 패키지와 공통 추상화 패키지를 하나의 저장소에서 관리했습니다. - `uv` 워크스페이스를 사용해 DS와 MLE가 같은 코드베이스에서 작업하고 리뷰할 수 있도록 했습니다. - 공통 인터페이스 변경과 모델 패키지 수정이 하나의 PR에서 함께 이뤄졌습니다. - CI, 버전 관리, 배포 정책을 저장소 단위로 통일할 수 있었습니다. - 공통 패키지 변경이 모든 모델에 영향을 줄 수 있다는 위험도 존재합니다. - 모델과 패키지가 늘면서 빌드가 느려졌고, Poetry에서 `uv`로 전환해 빌드 속도를 약 3~5배 개선했습니다. ## AI 시대의 코드 스타일 통일 - AI가 코드를 작성하면서 같은 기능도 예외 처리, 네이밍, enum 사용 방식 등이 사람마다 달라지는 문제가 생겼습니다. - 인터페이스가 같더라도 코드의 세부적인 작성 방식이 달라 리뷰 비용이 증가했습니다. - 팀 규칙 모음인 `pfmls-stylepack`을 도입해 AI가 코드 작성 단계부터 팀 컨벤션을 따르도록 했습니다. - Hook을 활용해 네이밍, 예외 처리, 고정값과 enum 사용 기준 등을 자동 적용했습니다. - 규칙이 적용된 코드에는 그 이유를 표시해 리뷰어가 변경 의도를 쉽게 파악하도록 했습니다. - 협업 표준을 두 층위로 나눴습니다. - 구조 표준화: 인터페이스로 담당 범위와 코드 형태 통일 - 스타일 표준화: 컨벤션으로 구현 방식과 코드 결 통일 ## 도입 과정에서 얻은 교훈 - 인터페이스는 너무 엄격하면 DS의 모델별 커스터마이징을 막고, 너무 느슨하면 다시 구현 방식이 제각각이 될 수 있습니다. - 초기에는 가이드 문서를 제공하고 DS와 MLE가 첫 모델을 페어로 함께 만드는 방식이 효과적입니다. - 공통 라이브러리는 한 번의 수정으로 전체 모델에 개선을 적용할 수 있지만, 반대로 전체 모델에 장애를 전파할 수도 있습니다. - 기존 모델 패키지를 참고 코드로 제공하면 새로운 구성원의 러닝 커브를 줄일 수 있습니다. - AI 활용이 늘어날수록 기능의 책임뿐 아니라 코드 작성 방식까지 명시적으로 관리해야 합니다. 실무적으로는 모델 배포 과정에서 “누가 무엇을 한다”를 문서로만 정의하기보다, 추상화 클래스와 패키지 구조로 강제하는 것이 효과적입니다. 먼저 전처리·추론·후처리 같은 최소 인터페이스를 정하고, 공통 로깅·메트릭·CI를 그 바깥에 배치하는 방식부터 시작하는 것을 추천합니다.

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

monorepo머신러닝CI/CDPython+4

figma·2026년 7월 23일·4분 읽기큐레이션 요약

에이전트를 활용해 취약점에 앞서가는 Figma의 방법 | Figma 블로그

Figma는 하나의 보안 정책을 기반으로 AI 에이전트를 코드 작성, 풀 리퀘스트(PR) 리뷰, 과거 코드 감사에 활용한다. 핵심은 단순히 취약점을 많이 찾는 것이 아니라, 정밀도(실제 취약점 비율)와 재현율(실제 취약점 탐지 비율)을 함께 관리해 개발자의 신뢰를 확보하는 것이다. 특히 모든 PR에 적용되는 리뷰 시스템과 사람의 피드백·기존 취약점 재검증을 통해 정책을 지속적으로 개선한다. ## 에이전트 보안의 세 가지 적용 단계 - **코드 생성 단계**: 개발자가 코드를 작성하는 과정에서 취약점을 예방한다. - **PR 리뷰 단계**: 변경된 코드를 검토해 배포 전에 문제를 탐지하고 수정하도록 한다. - **과거 코드 감사 단계**: 오래된 모노레포 전체를 점검해 이미 배포된 취약점을 찾는다. - 세 단계 모두 다음 내용을 포함한 공통 정책을 사용한다. - 신뢰 경계 - 조직이 허용한 위험 - 과거 판단의 선례(precedent) ## 정밀도와 재현율을 함께 측정 - **정밀도(precision)**: - 에이전트가 보고한 결과 중 실제 취약점의 비율이다. - 높을수록 오탐(false positive)이 적다. - **재현율(recall)**: - 실제 존재하는 취약점 중 에이전트가 찾아낸 비율이다. - 높을수록 미탐(false negative)이 적다. - 취약점을 많이 보고하는 것만으로는 충분하지 않다. - 오탐이 많으면 개발자가 도구의 결과를 무시하게 된다. - 반대로 정밀도만 높이고 탐지 범위를 줄이면 중요한 취약점을 놓칠 수 있다. ## PR 리뷰를 먼저 구축한 이유 Figma는 코드 생성이나 전체 저장소 감사보다 개선 주기가 빠른 PR 리뷰부터 만들었다. - **보편성**: 모든 PR이 리뷰 대상이 된다. - **셀프서비스 구조**: 에이전트가 PR에 직접 댓글을 달고, 작성자가 해당 결과에 답변한다. - **양방향 측정**: - 정밀도는 작성자의 thumbs up/down 평가와 설명으로 측정한다. - 재현율은 이미 취약점이 있었던 커밋에 리뷰어를 다시 실행해 놓친 문제를 세는 방식으로 측정한다. - 이렇게 수집한 피드백은 에이전트가 따르는 보안 정책 개선에 반영된다. ## 여러 모델을 병렬로 사용 - Figma는 서로 다른 취약점을 놓치는 모델을 함께 사용한다. - Claude Code의 Opus 4.8, xhigh 노력 수준 - Codex의 GPT-5.6 Sol, high 노력 수준 - 어느 한 모델이라도 문제를 보고하면 결과를 상위 단계로 전달한다. - PR 하나의 리뷰 비용은 중앙값 약 0.50달러이며, 대부분의 PR에는 보고할 문제가 없어 비용이 크게 증가하지 않는다. - Figma는 이 비용이 버그 바운티 지급이나 사용자 피해를 예방하는 효과에 비해 충분히 낮다고 판단한다. ## 실제로 탐지한 취약점 사례 - 복잡한 취약점: - 주입된 샌드박스 객체가 호스트 영역의 `Function` 생성자에 접근할 수 있음을 추론했다. - 이를 통해 데스크톱 클라이언트에서 코드 실행으로 이어지는 경로를 찾아냈다. - 일반적인 접근 제어 취약점: - 송장 조회 API가 호출자가 전달한 송장 ID만 확인하고 소속 조직을 검증하지 않았다. - 인증된 사용자가 ID만 알면 다른 조직의 송장을 읽을 수 있는 IDOR(Insecure Direct Object Reference) 문제였다. - 해결책은 송장 조회 시 인증된 사용자의 조직에 속하는지 함께 확인하는 것이다. ## 초기 도입과 신뢰 확보 - Anthropic이 Claude Code Security Reviewer를 공개한 2025년 8월, Figma는 즉시 도입했다. - 처음에는 개발자 PR 댓글이 아닌 Slack과 Datadog로만 결과를 보내는 shadow mode로 운영했다. - 리뷰어는 두 단계로 동작했다. - 잠재적 취약점 탐색 - 적대적 검토를 통한 오탐 필터링 - 실제 보안 사고를 재현했을 때 근본 원인을 거의 그대로 찾아냈고, 애플리케이션 보안과 인프라 설정 오류 등 여러 영역에도 잘 일반화됐다. - 그러나 첫 주에는 27개 결과 중 4개만 유효해 정밀도가 약 15%에 불과했다. - Figma는 개발자에게 노출하기 위한 기준으로 70% 정밀도를 설정했다. - 10개 중 7개가 유효해야 개발자가 결과를 읽을 것이라는 실용적 기준이다. - 2주간의 관찰 기간 동안 정밀도가 70% 이상이고 심각한 오탐이 없을 때까지 PR 댓글을 보류했다. - 이를 위해 최근 8주간의 PR에 리뷰어를 다시 실행하고, 보안팀이 오탐을 직접 분류했다. - 과거 사례를 기반으로 에이전트가 따라야 할 정책을 작성했다. - 여기서 **선례(precedent)**는 특정 상황에서 어떤 보고가 유효하거나 유효하지 않은지 설명하는 구체적인 사례다. ## 실용적인 결론 AI 보안 에이전트를 도입할 때는 처음부터 모든 개발자에게 결과를 노출하기보다 shadow mode로 운영하며 정밀도를 먼저 확보하는 것이 좋다. 모든 PR에 적용하고, 사람의 결과 평가와 알려진 취약점 재검증을 분리해 수집하면 신뢰성과 탐지력을 함께 개선할 수 있다.

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

monorepoAI 에이전트코드 리뷰claude-code+3

gitlab·2026년 6월 10일·4분 읽기큐레이션 요약

GitLab: 에이전틱 엔지니어링 시대를 위해 설계되다

GitLab은 AI 코딩의 속도를 늦추기보다, 에이전트가 대규모로 활동해도 통제와 보안을 유지할 수 있는 통합 인프라가 필요하다고 주장합니다. 이를 위해 에이전트 규모의 소스 코드 관리, 전체 SDLC를 이해하는 컨텍스트 그래프, 보안·거버넌스, 작업 오케스트레이션, 유연한 구매 모델을 제공하겠다고 발표했습니다. 결론적으로 GitLab은 인간과 에이전트가 동일한 플랫폼에서 계획·개발·배포·감사를 수행하는 “에이전틱 엔지니어링” 플랫폼을 지향합니다. ## AI 코딩의 확산과 관리되지 않은 혼란 - 조사 대상 1,500명 이상의 개발자와 기술 리더 중: - 조직의 91%가 AI 코딩 도구를 2개 이상 사용 - 54%는 3개 이상 사용 - 일부 고객의 코드베이스는 1년 만에 최대 5배 성장 - 그러나 기존 소프트웨어 생명주기는 인간의 작업 속도를 전제로 설계되어 에이전트 규모의 병렬 작업을 감당하기 어렵습니다. - 주요 문제: - 에이전트가 코드만 알고 전체 SDLC 맥락은 이해하지 못함 - 대규모 모노레포나 여러 저장소에서 컨텍스트가 부족해 작업이 중단됨 - 코드·의존성·배포 변경 속도가 거버넌스보다 빨라짐 - 좌석 수와 크레딧을 미리 구매해야 하는 고정형 계약이 AI 사용량 변동에 맞지 않음 - 응답자의 73%는 코드 유지보수를 걱정했으며, 전체 SDLC에서 생산성 향상을 체감한 비율은 21%에 불과했습니다. ## GitLab의 에이전틱 인프라 구조 GitLab은 소스 코드 관리, CI/CD, 거버넌스, 배포를 하나의 플랫폼에서 제공하며, 현재 5,000만 명 이상의 사용자와 10만 개 조직이 사용한다고 설명합니다. - **모터 시스템**: 소스 코드 관리, 파이프라인, 배포 등 실제 실행 담당 - **신경 시스템**: 에이전트와 개발자가 올바른 판단을 내리도록 전체 맥락 제공 - **면역 시스템**: 모든 작업에 보안과 거버넌스 적용 - **오케스트레이션 시스템**: 전체 생명주기의 작업을 계획하고 조율 - 이 네 요소는 사람이 작업하든 에이전트가 작업하든 동일하게 작동하도록 설계됩니다. ## 차세대 SCM과 에이전트 규모의 동시성 기존 Git은 수백 명의 개발자가 병렬로 작업하는 환경에는 적합하지만, 각 개발자가 수백 개의 에이전트를 실행하는 상황에서는 한계가 발생합니다. - **클론 비용**: 에이전트가 파일 하나를 읽기 위해 저장소 전체를 복제하며, 재시도마다 비용이 반복됨 - **동시성 붕괴**: 수천 개의 세션이 인간 중심으로 설계된 백엔드에 몰려 병목과 불안정성이 발생 - **격리 부족**: 에이전트가 계정과 브랜치 공간을 공유해 작업이 섞이고, 폐기나 추적이 어려움 - GitLab은 Git 프로토콜과의 호환성 및 감사 가능성은 유지하면서, 에이전트 전용 백엔드와 인터페이스를 갖춘 차세대 SCM을 비공개 베타로 공개했습니다. - 초기 내부 테스트 결과: - 토큰 사용량 최대 2배 감소 - 실제 실행 시간 최대 50배 단축 - 네트워크 트래픽 최대 1,000배 감소 ## GitLab Orbit: 전체 SDLC를 연결하는 컨텍스트 그래프 에이전트는 코드를 작성하는 능력에 비해 코드 주변의 시스템과 생명주기를 파악하는 능력이 부족합니다. 이로 인해 잘못된 작업을 반복하거나, 겉보기에는 올바르지만 나중에 되돌려야 하는 결과를 만들 수 있습니다. - **GitLab Orbit**은 코드, 작업 항목, 파이프라인, 배포, 운영 신호를 하나의 실시간 그래프로 연결합니다. - 에이전트는 분산된 정보가 아니라 GitLab의 원천 데이터를 기반으로 추론할 수 있습니다. - 개발자는 Data Explorer를 통해 동일한 그래프를 조회하고 변경 사항이나 장애 원인을 추적할 수 있습니다. - 초기 내부 테스트에서 Orbit을 사용한 에이전트는: - 응답 속도 최대 11배 향상 - 비용 효율 최대 4.5배 향상 - 환각 최대 45배 감소 - Compare the Market의 A/B 테스트에서는 그래프 기반 에이전트가 코드 리뷰 댓글의 정확한 위치를: - 70%의 확률로 지정 - RAG 방식은 58% - 이 테스트는 실제 머지 리퀘스트 79건을 대상으로 진행됐으며, 그래프 기반 컨텍스트가 일반적인 검색 기반 방식보다 높은 정확도를 보였습니다. - Orbit은 현재 공개 베타 단계입니다. ## 에이전트 보안과 거버넌스 GitLab은 에이전트가 코드와 운영 환경에 직접 영향을 미치는 상황을 고려해, 에이전트 자체를 관리하는 기능도 발표했습니다. - 에이전트의 신원과 권한을 관리 - 정책을 적용해 허용 가능한 행동 범위 제한 - 모든 에이전트 작업을 감사 로그로 추적 - 위험한 작업에 승인 절차 적용 - 에이전트용 보안 및 거버넌스 기능은 비공개 베타로 제공될 예정입니다. ## GitLab Duo Agent Platform의 오케스트레이션 - GitLab Duo Agent Platform은 에이전트가 개발자의 작업 흐름을 중단하지 않고 다음 작업을 수행하도록 조율합니다. - 이슈 처리 - 코드 리뷰 - CI/CD 파이프라인 문제 수정 - 플랫폼은 소스 코드, 컨텍스트, 보안 정책을 연결해 단순 코드 생성이 아닌 전체 개발 생명주기 자동화를 목표로 합니다. - 해당 플랫폼은 2026년 1월부터 정식 제공되고 있습니다. ## GitLab Flex와 새로운 구매 방식 - AI 도입 속도와 사용량은 조직마다 크게 달라 기존의 고정된 좌석·크레딧 계약으로 예측하기 어렵습니다. - GitLab Flex는 실제 AI 도입 방식과 사용 패턴에 맞춰 구매할 수 있는 유연한 라이선스 모델입니다. - 현재 주문을 받고 있습니다. ## 실용적인 결론 AI 코딩 도구를 도입하는 것만으로는 에이전틱 엔지니어링의 생산성을 확보하기 어렵습니다. 대규모 동시성을 처리하는 SCM, 전체 SDLC 컨텍스트, 세밀한 권한·감사·승인 체계, 작업 오케스트레이션을 함께 구축해야 하며, GitLab은 이를 하나의 통합 플랫폼으로 제공하려는 전략을 제시하고 있습니다.

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

monorepoAI 에이전트CI/CDgitlab+4

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

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

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

meta·2026년 4월 9일원문

포크에서 벗어나기: Meta가 50개 이상의 유스케이스에서 WebRTC를 현대화한 방법 (새 탭에서 열림)

메타는 대규모 오픈소스 프로젝트인 WebRTC를 커스터마이징하여 사용하며 겪었던 '포크 트랩(Forking Trap)'을 해결하기 위해, 최신 업스트림 버전과 내부 최적화 버전을 동시에 실행할 수 있는 듀얼 스택 아키텍처를 구축했습니다. 이를 통해 50개 이상의 유즈케이스에서 안전하게 A/B 테스트를 수행하며 성공적인 마이그레이션을 마쳤고, 결과적으로 성능 향상과 바이너리 크기 최적화 및 보안 강화를 달성했습니다. 현재 메타는 이 구조를 바탕으로 모노레포 환경에서도 업스트림의 최신 업데이트를 지속적으로 반영하며 기술적 부채 없이 서비스를 운영하고 있습니다. **포크 트랩과 모노레포 환경의 도전 과제** * 오픈소스 프로젝트를 내부적으로 포크하여 오래 사용하면 업스트림과의 격차가 벌어져 최신 기능을 반영하기 어려워지는 '포크 트랩'이 발생합니다. * 빌리언 단위의 사용자를 보유한 서비스에서 대규모 라이브러리를 한 번에 교체하는 것은 리스크가 크기 때문에, 구버전과 신버전을 동시에 실행하며 검증할 수 있는 A/B 테스트 역량이 필수적이었습니다. * 하지만 메타의 모노레포 환경과 정적 링크(Static Linking) 방식에서는 동일한 라이브러리의 두 버전을 동시에 포함할 때 '단일 정의 원칙(ODR)' 위반으로 인한 수천 개의 심볼 충돌 문제가 발생했습니다. **심(Shim) 레이어와 듀얼 스택 아키텍처** * 애플리케이션과 WebRTC 구현체 사이에 프록시 역할을 하는 '심(Shim) 레이어'를 구축하여 통합된 API를 제공했습니다. * 애플리케이션은 버전과 무관한 심 API를 호출하고, 심 레이어는 런타임 설정(Flavor)에 따라 레거시 또는 최신 구현체로 호출을 전달합니다. * 모든 라이브러리를 복제하는 대신 최하위 레이어에서 심을 구현함으로써, 바이너리 크기 증가폭을 예상치(38MB) 대비 약 87% 감소한 5MB 수준으로 억제했습니다. **심볼 충돌 해결과 하위 호환성 유지** * 자동화된 네임스페이스 재명명(Renamespacing) 스크립트를 통해 `webrtc::` 네임스페이스를 각 버전에 맞게 `webrtc_legacy::`, `webrtc_latest::` 등으로 분리했습니다. * 네임스페이스 외부에 존재하는 글로벌 C 함수와 변수들은 버전별 식별자를 추가하여 충돌을 방지했습니다. * 기존 코드의 수정을 최소화하기 위해 C++의 `using` 선언을 활용하여, 외부 호출부에서는 여전히 기존 네임스페이스를 사용하는 것처럼 보이게 하면서 내부적으로는 올바른 버전에 연결되도록 설계했습니다. **런타임 버전 디스패치 및 관리** * 템플릿 기반의 헬퍼 라이브러리를 사용하여 중복 로직을 줄이고 버전별 특화 동작을 정의했습니다. * 앱 시작 시점에 결정되는 글로벌 플래그(Enum)를 통해 어떤 WebRTC 버전을 사용할지 동적으로 결정합니다. * 패치 관리의 복잡성을 해결하기 위해 모노레포 내에서 업스트림 버전을 주기적으로 가져오고 내부 패치를 반복적으로 적용하는 워크플로우를 정립했습니다. 대규모 오픈소스 프로젝트를 운영할 때 직접적인 포크보다는 이와 같은 모듈식 아키텍처와 자동화된 네임스페이스 관리를 도입하는 것이 기술적 고립을 막는 효과적인 전략이 될 수 있습니다. 이는 특히 안전한 배포와 지속적인 업스트림 동기화가 중요한 대규모 시스템에서 실무적인 해법을 제시합니다.

monorepoc++ab-testingwebrtc+4

gitlab·2026년 4월 9일원문

GitLab 파이프라인 로직이 엔지니어링 문제를 해결하는 5가지 방법 (새 탭에서 열림)

GitLab의 파이프라인 실행 모델은 모노레포, 마이크로서비스, 다중 환경 배포와 같은 현대적인 엔지니어링 복잡성을 해결하기 위해 설계되었습니다. 부모-자식 파이프라인, DAG(Directed Acyclic Graph), 멀티 프로젝트 트리거 등의 기능을 조합하면 단순히 빌드 속도를 높이는 것을 넘어 조직의 표준을 강제하면서도 병목 현상을 줄이는 확장 가능한 CI/CD 시스템을 구축할 수 있습니다. 결과적으로 이러한 구성 가능한 패턴들을 이해하고 활용하는 것이 효율적인 소프트웨어 배포의 핵심입니다. **모노레포 최적화를 위한 부모-자식 파이프라인과 DAG 실행** - 특정 서비스의 변경사항이 발생했을 때만 관련 파이프라인이 실행되도록 '부모-자식 파이프라인'을 구성하여 불필요한 전체 재빌드를 방지합니다. - `trigger: include`와 `strategy: depend`를 사용하여 부모 파이프라인이 자식 파이프라인의 결과에 의존하게 함으로써, 상위 수준에서 전체 서비스의 상태를 한눈에 파악할 수 있습니다. - `needs` 키워드를 활용한 DAG(비순차적 실행) 모델을 적용하면, 동일 단계(stage)의 다른 작업이 끝나기를 기다리지 않고 의존성이 해결되는 즉시 다음 작업을 시작하여 파이프라인 실행 시간을 획기적으로 단축합니다. - 각 서비스가 독립적인 설정 파일을 가질 수 있어 조직적 분리가 용이하며, 한 서비스의 설정 오류가 전체 모노레포 시스템을 중단시키지 않도록 격리합니다. **마이크로서비스 간 연동을 위한 멀티 프로젝트 파이프라인** - 서로 다른 리포지토리에 존재하는 프론트엔드와 백엔드 간의 의존성 문제를 해결하기 위해 '멀티 프로젝트 트리거'를 사용하여 파이프라인을 연결합니다. - 프론트엔드 파이프라인에서 API 계약(Contract) 아티팩트를 생성하고, 이를 백엔드 파이프라인 트리거 시 전달하여 서비스 간 정합성을 자동으로 검증합니다. - `$CI_JOB_TOKEN`을 활용한 Jobs API 호출을 통해 다른 프로젝트의 아티팩트를 안전하게 가져올 수 있으며, 이를 통해 통합 테스트의 자동화 수준을 높입니다. - 업스트림 파이프라인 뷰에서 연결된 다운스트림 파이프라인의 상태를 실시간으로 확인할 수 있어, 서비스 간 변경 사항이 미치는 영향에 대한 가시성을 제공합니다. GitLab이 제공하는 이러한 파이프라인 로직은 단순한 빌드 도구를 넘어 복잡한 아키텍처를 관리하는 강력한 오케스트레이션 엔진 역할을 합니다. 대규모 모노레포를 운영하거나 서비스 간 의존성이 복잡한 마이크로서비스 환경이라면, DAG를 통한 속도 최적화와 멀티 프로젝트 트리거를 통한 통합 검증 체계를 우선적으로 도입할 것을 권장합니다.

monorepoCI/CD마이크로서비스DevOps+4

dropbox·2026년 3월 25일원문

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

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 등)의 서버 측 리팩 설정과 인프라 호환성을 반드시 고려하여 전략을 수립해야 합니다.

monorepo데이터베이스 설계CI/CDgithub+4

dropbox·2026년 2월 11일원문

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)에 어떻게 기여하는지 직접적으로 매핑하는 운영 모델을 구축하는 것이 핵심입니다.

monorepoAIclaude-codesoftware-development-lifecycle+4

daangn·2026년 1월 15일원문

당근페이 백엔드 아키텍처가 걸어온 여정. Money라는 하나의 작은 프로젝트부터 수십 개의 서비스를 하나의… (새 탭에서 열림)

당근페이 백엔드 아키텍처는 서비스의 급격한 성장과 조직의 확장에 발맞춰 계층형, 헥사고날, 그리고 클린 아키텍처 기반의 모노레포 형태로 끊임없이 진화해 왔습니다. 초기에는 빠른 기능 출시를 위해 단순한 구조를 채택했으나, 비즈니스 복잡도가 증가함에 따라 의존성 관리와 코드 응집도를 높이기 위해 구조적 제약을 강화하는 방향으로 발전했습니다. 결과적으로 아키텍처는 기술적 부채를 해결하는 수단을 넘어, 대규모 팀이 협업하며 지속 가능한 성장을 이뤄낼 수 있는 기반이 되었습니다. ### 초기 성장을 견인한 계층형 아키텍처 (Layered Architecture) * **빠른 실행력 중심:** 2021년 당근페이 출시 초기, 송금 서비스의 신속한 시장 진입을 위해 `Controller-Service-Repository`로 이어지는 직관적인 3계층 구조를 사용했습니다. * **성장통의 발생:** 서비스가 커지면서 송금, 프로모션, FDS 등 다양한 기능이 하나의 계층에 뒤섞였고, 서비스 간 순환 참조와 강한 결합이 발생해 코드 변경의 영향 범위를 예측하기 어려워졌습니다. * **기술 부채의 축적:** 모든 비즈니스 로직에 프레임워크 기술(Spring)이 깊숙이 침투하면서 테스트 작성이 까다로워지고, 순수 도메인 로직만 분리해 관리하기 어려운 구조적 한계에 직면했습니다. ### 구조적 제약을 통한 응집도 향상 (Hexagonal Architecture) * **외부 구현과의 분리:** 도메인 규칙을 중심에 두고 UI, DB, 외부 API 등 인프라 영역을 포트와 어댑터를 통해 분리하여 프레임워크에 의존하지 않는 POJO 중심의 설계를 지향했습니다. * **모듈 역할의 세분화:** 프로젝트를 핵심 규칙을 담은 `domain`, 사용자 시나리오 단위의 `usecase`, 실제 입출력을 담당하는 `adapter` 모듈로 재구성하여 의존성 방향을 한곳으로 모았습니다. * **재사용성과 테스트 용이성:** 유스케이스 단위로 로직이 응집되면서 REST API뿐만 아니라 이벤트 컨슈머, 배치 잡 등 다양한 진입점에서 동일한 비즈니스 로직을 안전하게 재사용할 수 있게 되었습니다. ### 규모 확장에 대응하는 클린 아키텍처와 모노레포 * **모노레포 도입의 배경:** 머니, 포인트, 빌링 등 도메인이 늘어남에 따라 여러 저장소를 관리하는 비용이 증가했고, 이를 효율적으로 통합 관리하기 위해 하나의 저장소에서 여러 서비스를 운영하는 모노레포 구조를 채택했습니다. * **계약 기반의 모듈 분리:** 각 도메인을 `contract(인터페이스)`와 `impl(구현체)` 모듈로 쪼개어 의존성 규칙을 강제했습니다. 다른 모듈은 `contract`만 참조하게 하여 불필요한 내부 구현 노출을 차단했습니다. * **빌드 성능 및 생산성 최적화:** Gradle의 `api`와 `implementation` 구성을 활용해 컴파일 시점의 의존성을 제어함으로써, 대규모 프로젝트임에도 불구하고 빌드 시간을 단축하고 변경 영향도를 최소화했습니다. 아키텍처에는 정답이 없으며, 조직의 규모와 비즈니스의 현재 단계에 가장 적합한 형태를 선택하는 것이 중요합니다. 당근페이의 사례처럼 초기에 과도한 설계를 지양하되, 서비스 성장 속도에 맞춰 구조적 제약을 단계적으로 도입함으로써 기술 부채를 통제하고 개발 생산성을 유지하는 전략을 권장합니다.

monoreposoftware-designspring-frameworkhexagonal-architecture+2

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

monorepoKotlinJavajvm+4

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

E2E 파이프라인

Slack은 E2E 테스트 파이프라인에서 프론트엔드 변경이 없어도 매번 프론트엔드를 빌드하는 비효율을 발견했다. Git 변경 감지와 기존 빌드 산출물 재사용을 도입해 프론트엔드 빌드 횟수를 60% 줄이고, 전체 파이프라인 시간을 약 10분에서 2분으로 단축했다. 그 결과 개발자 대기 시간과 AWS S3 저장 비용을 줄였을 뿐 아니라 E2E 테스트의 플래키함도 개선됐다. ## 프론트엔드 빌드가 병목이 된 이유 - Slack의 대규모 모노레포에서는 병합 전 전체 스택을 검증하기 위해 E2E 테스트를 실행했다. - 기존 파이프라인은 다음 순서로 동작했다. - 코드 변경 후 브랜치 푸시 - 프론트엔드 빌드: 약 5분 - QA 환경 배포 - 200개 이상의 E2E 테스트: 약 5분 - 프론트엔드와 무관한 백엔드·데이터베이스·서비스 변경에도 프론트엔드를 새로 빌드했다. - 매주 수천 번의 빌드가 발생했고, 빌드 하나당 AWS S3에 약 1GB의 데이터가 저장됐다. - 이 중 절반가량은 실제 프론트엔드 변경이 없어 중복 산출물에 해당했다. ## Git diff를 이용한 조건부 빌드 - 현재 브랜치와 `main`의 최신 공통 커밋을 기준으로 `git diff`의 3-dot 표기법을 사용했다. - 변경 내역에 프론트엔드 관련 파일이 포함된 경우에만 새 프론트엔드 빌드 작업을 실행했다. - 프론트엔드 변경이 없으면 빌드를 완전히 건너뛰고 기존 산출물을 사용했다. - 추적 파일이 10만 개가 넘는 모노레포에서도 Git의 변경 감지는 약 몇 초 안에 완료됐다. ## 기존 빌드 산출물과 내부 CDN 재사용 - 새 빌드가 필요하지 않은 경우 AWS S3에 저장된 기존 프론트엔드 빌드를 탐색했다. - 현재 Production에서 사용 중인 비교적 최신 빌드를 선택해 테스트에 활용했다. - 내부 CDN이 해당 프론트엔드 정적 파일을 제공하도록 구성했다. - 이를 통해 PR마다 새 빌드를 생성하지 않으면서도 최신 상태에 가까운 프론트엔드 자산으로 E2E 테스트를 수행했다. ## 대규모 환경에서의 자산 관리 - 수백 개의 PR이 매일 병합되므로 재사용할 빌드가 충분히 최신인지 판단해야 했다. - S3의 파일명 규칙과 저장 구조를 활용해 빌드 산출물의 최신성, 일관성, 검색 성능을 관리했다. - 변경 여부 판단과 적절한 빌드 산출물 탐색을 평균 3초 이내에 처리했다. - 결과적으로 전체 테스트 흐름에서 프론트엔드 빌드 단계를 효율적으로 제거할 수 있었다. ## 성능과 비용 개선 - 불필요한 프론트엔드 빌드 빈도를 60% 줄였다. - AWS S3 중복 저장 데이터를 매월 수 테라바이트 규모로 절감했다. - 클라우드 컴퓨팅 비용과 개발자의 파이프라인 대기 시간을 줄였다. - 기존 Webpack 개선으로 평균 빌드 시간이 10분에서 5분으로 줄어든 데 이어, 이번 최적화로 약 2분까지 단축했다. - 전체 E2E 파이프라인 시간은 평균 10분에서 2분으로 감소했다. ## 예상하지 못한 효과 - 프론트엔드 빌드 과정과 자산 전달 방식이 단순해지고 일관되면서 E2E 테스트의 플래키함이 감소했다. - 월별 측정 결과 테스트 실패의 불안정성이 가장 낮은 수준까지 개선됐다. - 오래된 여러 시스템의 레거시 코드를 조사하는 과정에서 기존 동작을 재발견하고 향후 개선 과제도 발굴했다. ## 실용적인 결론 CI/CD 파이프라인에서는 모든 단계를 무조건 실행하기보다 실제 변경 범위와 필요한 검증 수준을 기준으로 조건부 실행을 설계하는 것이 효과적이다. 특히 Git 변경 감지, 빌드 산출물 캐싱, CDN 재사용을 결합하면 빌드 시간과 클라우드 비용을 동시에 줄일 수 있다.

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

monorepoCI/CDGitcdn+4

figma·2023년 8월 28일·4분 읽기큐레이션 요약

Figma를 빠르게 유지하기

Figma는 2018년 한 대의 MacBook으로 운영하던 성능 테스트 체계가 제품과 조직의 성장으로 한계에 이르자 전면적인 개편을 추진했습니다. 플러그인, FigJam, Dev Mode 등 기능이 늘고 코드베이스가 복잡해지면서 기존의 소수 대형 파일 테스트만으로는 성능 회귀를 조기에 발견하기 어려워졌습니다. 이에 Figma는 모든 코드 변경을 대상으로 실제 하드웨어에서 병렬 성능 테스트를 실행하고, 10분 이내에 결과를 제공하는 확장 가능한 시스템을 목표로 삼았습니다. ## 한 대의 MacBook으로 시작한 성능 테스트 - 2018년 Figma는 한 대의 MacBook에서 동일한 테스트 시나리오를 반복 실행했습니다. - 테스트 결과와 실행 시간은 약 한 시간 간격으로 공유 대시보드에 기록됐습니다. - 당시에는 소수의 대형 디자인 파일만으로도 주요 성능 문제를 확인할 수 있었습니다. - 문서 렌더러 구조를 개선하고 WebAssembly 관련 버그를 해결하면서 Figma의 성능을 약 3배 향상시킨 사례도 있었습니다. - 작은 조직에서 단일 컴퓨터로 테스트하는 방식은 단순하고 비용이 낮다는 장점이 있었습니다. ## 제품과 조직의 성장으로 드러난 한계 - 5년 동안 코드베이스가 커지고 다음과 같은 기능이 추가됐습니다. - 플러그인 - Community 기능 - FigJam - Dev Mode - 수많은 제품 업데이트 - 기존에 사용하던 몇 개의 대형 디자인 파일은 늘어나는 기능과 예외 상황을 충분히 대표하지 못했습니다. - 기능별로 세밀한 성능 테스트를 작성하는 것이 이상적이었지만, 엔지니어와 매니저가 400명 이상으로 늘면서 모든 변경 사항을 한 사람이 추적하기 어려워졌습니다. - 성능 테스트 대상과 코드 변경이 많아지면서 단일 노트북만으로는 출시 전 성능 회귀를 안정적으로 발견할 수 없었습니다. - 원격 근무가 시작된 뒤에도 사무실에 있던 MacBook은 계속 테스트를 실행했고, 결국 2020년 10월 과열됐습니다. - 다른 노트북으로 같은 환경을 재현하려 했지만 테스트가 원활하게 실행되지 않아 새로운 시스템이 필요해졌습니다. ## 세밀한 성능 테스트의 필요성 - **세밀한 성능 테스트(granular performance test)**는 특정 기능이나 사용 패턴을 대규모 조건에서 검증하는 테스트입니다. - 예를 들어 Figma는 다음과 같은 상황을 시뮬레이션할 수 있습니다. - 100명의 협업 편집자가 동시에 파일을 편집 - 여러 사용자가 레이어를 이동 - 동시에 새로운 텍스트 입력 - 사용자가 빠르게 화면을 패닝 - 이런 테스트는 특정 기능의 성능 영향을 정확하게 파악하는 데 유용합니다. - 하지만 기능 수와 엣지 케이스가 계속 증가하면 모든 기능을 수동으로 테스트하는 방식은 조직 규모에 맞게 확장되지 않습니다. ## 새 성능 테스트 시스템의 목표 - Figma는 시스템을 처음부터 다시 설계하며 세 가지 문제를 해결하려 했습니다. - 성능에 영향을 줄 수 있는 기능의 증가 - 테스트 하드웨어 운영의 어려움 - 신뢰할 수 있는 성능 지표의 부족 - 메인 모노레포에 제출되는 **모든 코드 변경**을 테스트해 성능 회귀를 개발 초기에 발견하는 것을 목표로 삼았습니다. - 사용자가 버그를 보고한 뒤 대응하는 대신, 기능이 배포되기 전에 성능 문제를 예방하려 했습니다. - Figma 사용자는 하루에도 여러 시간 제품을 사용하기 때문에 작은 지연도 작업 흐름에 큰 영향을 줄 수 있다고 판단했습니다. - 성능을 기능 개발 이후의 사후 대응이 아니라 개발 과정에 포함되는 품질 기준으로 다루려 했습니다. ## 병렬 실행과 10분 성능 가드레일 - 테스트 대기 시간을 줄이기 위해 여러 테스트를 동시에 실행하는 **병렬 실행(parallel runs)**을 핵심 전략으로 채택했습니다. - 기존 CI에서도 클라우드 러너를 이용한 병렬 테스트를 이미 활용하고 있었습니다. - 성능 테스트 역시 수십 개의 스트레스 시나리오를 동시에 실행해야 목표 시간을 달성할 수 있었습니다. - 성능 가드레일 검사는 개발 흐름을 방해하지 않도록 **10분 이내**에 완료되어야 한다는 기준을 세웠습니다. - 모든 풀 리퀘스트를 실제 하드웨어에서 테스트하려면 피크 시점에 동일한 성능의 테스트 러너 약 100대가 필요했습니다. - 따라서 새로운 체계는 단순히 테스트 수를 늘리는 것이 아니라, 하드웨어를 효율적으로 운영하고 결과를 빠르게 수집하는 구조여야 했습니다. ## 실용적인 결론 성능 테스트는 제품과 조직이 작을 때는 단일 장비와 소수의 대표 시나리오만으로도 충분할 수 있지만, 기능·코드·팀 규모가 커지면 자동화와 병렬화가 필수입니다. 특히 사용자 경험에 직접 영향을 주는 성능은 출시 후 모니터링하는 것보다 모든 코드 변경 단계에서 회귀를 차단하는 가드레일로 운영하는 편이 효과적입니다.

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

monorepoCI/CDwebassemblyperformance-testing+2