Git

24 개의 포스트

cloudflare원문

아티팩트: Git 방식으로 작동하는 버전 관리 저장소 (새 탭에서 열림)

AI 에이전트가 생성하는 코드와 데이터의 양이 기하급수적으로 증가함에 따라, 기존의 소스 제어 플랫폼은 인간의 작업 속도를 상회하는 대규모 수요를 감당하기 어려워지고 있습니다. Cloudflare는 이러한 문제를 해결하기 위해 AI 에이전트 중심의 분산 버전 관리 파일 시스템인 'Artifacts'를 출시했습니다. Artifacts는 익숙한 Git 프로토콜을 기반으로 하면서도 API를 통해 수백만 개의 리포지토리를 프로그래밍 방식으로 즉시 생성하고 제어할 수 있는 새로운 저장소 프리미티브를 제공합니다. ### AI 에이전트에 최적화된 Git 인터페이스 * AI 모델들이 이미 학습 데이터로 익숙하게 습득한 Git 프로토콜을 그대로 사용하여, 별도의 CLI나 기술 전파 없이도 에이전트가 즉시 소스 제어를 수행할 수 있습니다. * 에이전트 세션마다 독립적인 리포지토리를 할당하거나, 특정 시점에서 수만 개의 포크(Fork)를 생성하여 병렬적으로 작업을 수행하는 것이 가능합니다. * 서버리스 환경과 같이 표준 Git 클라이언트를 사용하기 어려운 곳을 위해 REST API와 네이티브 Workers API를 별도로 제공하여 커밋과 자격 증명 관리를 단순화합니다. ### 단순 소스 제어를 넘어선 상태 관리 도구 * Git의 데이터 모델을 코드 저장뿐만 아니라 세션 프롬프트 히스토리, 샌드박스 상태, 사용자별 설정(Config) 등 시간 흐름에 따른 상태 추적이 필요한 모든 곳에 활용합니다. * Cloudflare 내부적으로는 에이전트 세션마다 Artifacts 리포지토리를 할당하여, 블록 스토리지 없이도 파일 시스템 상태를 영구 저장하고 특정 시점으로의 타임트래블(복구) 기능을 구현하고 있습니다. * 세션 자체를 포크(Fork)하여 동료와 공유하거나, 특정 실험 단계에서부터 다시 작업을 시작하는 등의 협업 워크플로우를 데이터 계층에서 지원합니다. ### Durable Objects와 Zig 기반의 고성능 아키텍처 * Cloudflare의 Durable Objects를 기반으로 설계되어 수천만 개의 독립적인 상태 저장 인스턴스를 확장성 있게 관리할 수 있습니다. * 런타임 효율성을 극대화하기 위해 Git 구현체를 Zig 언어로 작성한 뒤 WebAssembly(Wasm)로 컴파일하여 Cloudflare Workers 환경에서 가볍고 빠르게 동작하도록 구축했습니다. * 기존 외부 Git 저장소(예: GitHub)에서 데이터를 가져오는 `.import()` 기능과 읽기 전용 포크 생성 기능을 통해 복잡한 코드 베이스 위에서도 에이전트가 안전하게 독립적인 작업을 수행할 수 있도록 돕습니다. AI 에이전트가 주도하는 소프트웨어 개발 환경을 구축하고 있다면, Artifacts는 대규모 상태 관리와 버전 제어를 위한 가장 강력한 인프라가 될 것입니다. 현재 유료 Workers 플랜 사용자를 대상으로 프라이빗 베타를 진행 중이며, 5월 초 공개 베타 전환이 예정되어 있으므로 에이전트 세션 관리나 동적 환경 구축이 필요한 팀은 도입을 적극 검토해 보시기 바랍니다.

line원문

AI로 리뷰 정체를 해소하다 - PR 리뷰 지원과 사내 워크숍으로 리뷰 문화 바꾸기 (새 탭에서 열림)

개발 생산성을 저해하는 리뷰 정체 현상을 해결하기 위해 AI 스크리닝 리뷰와 프로세스 체계화를 도입하여 팀의 업무 효율을 극대화한 사례를 소개합니다. 단순히 도구를 사용하는 수준을 넘어 Claude Code의 커스텀 명령어를 활용해 'AI의 1차 점검 후 사람의 최종 판단'이라는 2단계 리뷰 체계를 구축함으로써, 리뷰어의 부담을 줄이고 코드 품질을 안정적으로 유지할 수 있었습니다. 이러한 기술적 장치와 PR 작성 자동화 등의 문화적 노력이 결합될 때 지속 가능한 개발 환경이 만들어진다는 것이 핵심입니다. ## 리뷰 정체와 기술적 부채의 발생 * **특정 인원에게 집중된 리뷰 부하(SPOF):** 소수의 테크 리드나 숙련된 엔지니어에게 리뷰가 집중되면서, 자신의 구현 업무와 리뷰 대응을 병행해야 하는 과부하 상태가 지속되었습니다. * **효율과 품질의 트레이드오프:** 리뷰 속도를 높이면 버그 누락 위험이 커지고, 꼼꼼히 리뷰하면 전체 개발 속도가 늦어지는 딜레마에 빠졌습니다. * **리뷰 대기 시간 증가:** PR이 쌓이면서 구현 담당자가 다음 작업으로 전환하는 데 병목이 발생하고 프로젝트 전체의 리드 타임이 길어지는 문제가 나타났습니다. ## AI 스크리닝 리뷰 시스템의 도입 * **단순 요약의 한계 극복:** 초기에는 AI에 PR 내용을 붙여넣는 방식을 시도했으나, 매번 프롬프트를 입력해야 하는 번거로움 때문에 실무 정착에 실패했습니다. * **Claude Code 커스텀 명령어 활용:** 사내에 도입된 Claude Code를 이용해 리뷰 명령어를 자동화함으로써, 별도의 프롬프트 준비 없이 한 번의 명령으로 정교한 리뷰가 가능해졌습니다. * **2단계 리뷰 프로세스:** AI가 먼저 변경 사항 요약, 영향 범위 분석, 코딩 규칙 위반 여부, 잠재적 버그를 점검하여 리포트를 제공하면, 리뷰어는 이를 바탕으로 최종 판단만 내리는 방식으로 전환했습니다. ## Claude Code를 활용한 리뷰 자동화 디테일 * **단계적 분석 절차:** AI가 단순히 코드만 보는 것이 아니라 `gh` 커맨드로 PR 메타 정보와 코멘트 이력을 가져와 배경지식을 파악하고, 전체 코드베이스의 의존 관계까지 조사하도록 설계했습니다. * **리뷰어용 코멘트 제안:** AI가 지적 사항에 대해 `[must]`, `[want]`, `[imo]` 등의 라벨을 붙여 구현자에게 보낼 코멘트 초안을 작성해 줌으로써 리뷰어의 커뮤니케이션 비용을 절감했습니다. * **체크아웃 및 환경 동기화:** PR 브랜치를 자동으로 체크아웃하고 파일 차분(diff)을 직접 확인하여 분석의 정확도를 높였습니다. ## 선순환을 만드는 PR 작성 자동화와 조직 문화 * **PR 작성 지원:** 리뷰 효율을 높이기 위해 작성 단계부터 AI가 커밋 차분을 분석하여 제목과 배경, 변경 내용을 템플릿에 맞춰 자동으로 작성하도록 자동화했습니다. * **데이터 기반의 정확도 향상:** 충실하게 작성된 PR 설명은 다시 AI 스크리닝 리뷰의 분석 정확도를 높이는 데이터로 활용되어 리뷰 품질의 선순환을 만듭니다. * **지속 개선 구조:** '효율화-정확도 기반-문화 형성-지속 개선'이라는 네 가지 축을 바탕으로 기술과 문화가 조화를 이루는 통합적인 리뷰 환경을 지향합니다. 리뷰 정체 문제를 해결하고 싶다면 단순히 AI에게 "이 코드를 리뷰해줘"라고 요청하는 단발성 시도에서 벗어나야 합니다. Claude Code와 같은 도구를 활용해 팀의 코딩 규칙과 워크플로우를 반영한 **커스텀 명령어를 구축**하고, AI가 1차 스크리닝을 담당하게 하여 사람이 '최종 의사결정'에만 집중할 수 있는 환경을 만드는 것을 추천합니다. 이러한 체계화는 리뷰어의 심리적 부담을 줄일 뿐만 아니라 팀 전체의 개발 속도를 비약적으로 향상시키는 실질적인 해법이 됩니다.

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

line원문

Claude Code Action: 조직 전반의 코드 품질을 지키는 AI 코드 리뷰 플랫폼화 (새 탭에서 열림)

LINE NEXT는 조직의 성장에 따른 코드 리뷰 품질 편차를 줄이고 개인 단위로 파편화된 AI 도구 활용을 조직 차원의 표준으로 통합하기 위해 Claude Code를 활용한 플랫폼화된 코드 리뷰 시스템을 구축했습니다. GitHub Actions를 기반으로 설계된 이 시스템은 리뷰 기준과 실행 로직을 중앙에서 관리함으로써 수많은 프로젝트에 일관된 품질의 피드백을 신속하게 제공합니다. 결과적으로 개별 팀의 운영 부담은 최소화하면서 보안과 거버넌스가 강화된 자동화된 리뷰 환경을 전사적으로 확산시키는 성과를 거두었습니다. ### AI 코드 리뷰 플랫폼화의 배경과 목적 * **품질 편차 해소:** 조직 규모가 커짐에 따라 리뷰어의 경험과 성향에 따라 달라지는 코드 리뷰의 깊이와 관점을 조직 차원에서 일관되게 유지할 필요가 있었습니다. * **개인 도구의 한계 극복:** 개별 개발자가 로컬에서 AI를 사용할 때 발생하는 리뷰 기준의 상이함, 프로세스 단절, 신규 구성원 온보딩의 어려움을 해결하고자 했습니다. * **DevOps 관점의 표준화:** 파편화된 품질 프로세스를 하나로 묶어 PR(Pull Request) 워크플로에 자연스럽게 녹아드는 '표준 구성 요소'로 재정의했습니다. ### GitHub Actions 기반의 통합 전략 * **기존 흐름 유지:** LINE NEXT의 표준 소스 관리 도구인 GitHub와 CI/CD 도구인 GitHub Actions를 활용하여 개발자의 학습 비용을 낮추고 기존 워크플로에 즉시 통합했습니다. * **인프라 운영 효율화:** DevOps 팀이 공통 GitHub App Runner 환경을 제공함으로써, 각 서비스 팀은 추가 인프라 구성 없이 설정만으로 AI 리뷰를 도입할 수 있게 했습니다. * **접근성 향상:** PR 내에서 `@claude` 멘션만으로 리뷰를 트리거하고, 결과물은 GitHub 댓글이나 리뷰 형태로 즉각 확인하는 직관적인 UX를 제공합니다. ### 호출과 실행을 분리한 설계 구조 (Caller-Executor) * **서비스 리포지터리(Caller):** AI 리뷰의 진입점 역할만 수행하며, 서비스명과 리뷰 타입 등 최소한의 정보만 전달하여 구조적 단순함을 유지합니다. * **중앙 리포지터리(Executor):** 프롬프트 관리, 페르소나 정의, 리뷰 정책, 권한 제어 등 핵심 로직을 집약하여 관리합니다. * **일관성 및 확산성:** 중앙에서 프롬프트를 수정하면 연결된 모든 프로젝트에 즉시 반영되며, 새로운 프로젝트는 표준 워크플로 호출만으로 빠르게 온보딩이 가능합니다. * **보안 강화:** GitHub Apps 기반의 인증과 Secrets 중앙 관리를 통해 외부 AI 호출 시의 보안 권한과 코드 접근 이력을 명확히 추적하고 통제합니다. ### 기술적 제약 극복: 포크(Fork) 기반 PR 처리 개선 * **공식 Action의 한계:** Claude Code Action의 초기 버전은 변경 코드가 `origin` 저장소에 있다는 것을 전제로 하여, 외부 포크 저장소에서 생성된 PR의 차이(diff)를 가져오지 못하는 문제가 있었습니다. * **내부 참조(ref) 활용:** 특정 브랜치를 fetch하는 방식 대신, GitHub가 모든 PR에 대해 자동으로 생성하는 특수한 참조 주소인 `refs/pull/<PR 번호>/head`를 사용하도록 로직을 재설계했습니다. * **결과:** 이 구조적 개선을 통해 내부 브랜치뿐만 아니라 외부 기여자의 포크 PR에 대해서도 중단 없는 AI 코드 리뷰가 가능한 범용적인 플랫폼 환경을 완성했습니다. ### 실용적인 제언 AI 코드 리뷰 도구를 도입할 때는 단순히 개별 리포지터리에 적용하는 것을 넘어, **'호출은 단순하게, 책임은 중앙으로'** 분리하는 아키텍처를 설계하는 것이 중요합니다. 이를 통해 조직 전체의 리뷰 품질을 상향 평준화하고, 보안 정책 변경이나 프롬프트 고도화 시 발생하는 운영 비용을 획기적으로 줄일 수 있습니다.

gitlab원문

Git 2.53.0 (새 탭에서 열림)

Git 2.53.0 버전은 대규모 저장소 관리 효율성을 높이고 데이터 무결성을 강화하는 데 초점을 맞춘 업데이트를 선보였습니다. 이번 릴리스의 핵심은 부분 클론(Partial Clone) 환경에서의 기하급수적 재패킹 지원과 히스토리 재작성 시 유효한 서명을 선별적으로 보존하는 기능의 도입입니다. 이를 통해 개발자와 운영자는 대규모 프로젝트를 관리할 때 성능 최적화와 보안 신뢰성을 동시에 확보할 수 있게 되었습니다. ## 부분 클론 환경의 기하급수적 재패킹(Geometric Repacking) 지원 * 전통적인 'all-into-one' 재패킹 방식은 모든 객체를 하나의 패크파일로 합쳐 조회 성능은 좋지만, 대규모 저장소에서는 작업 시간이 지나치게 길어지는 단점이 있습니다. * 이를 보완하는 '기하급수적 전략'은 패크파일들의 크기를 일정 비율(두 배 이상)로 유지하며 필요한 부분만 결합하지만, 그동안 부분 클론 환경의 '프로미서(promisor)' 패크파일을 제대로 처리하지 못하는 기술적 한계가 있었습니다. * Git 2.53에서는 기하급수적 재패킹 시 프로미서 패크파일을 별도로 구분하여 관리하도록 개선되었습니다. 이를 통해 부분 클론을 사용하는 저장소에서도 데이터 손상 위험 없이 효율적인 객체 관리가 가능해졌습니다. ## 유효한 커밋 서명만 보존하는 git-fast-import 개선 * 저장소 히스토리를 대량으로 재작성하는 `git-fast-import` 명령어에 `--signed-commits` 옵션의 새로운 모드인 `strip-if-invalid`가 추가되었습니다. * 기존에는 히스토리를 재작성할 때 서명을 일괄 삭제하거나 무효한 서명을 그대로 남겨둬야 했으나, 이제는 재작성으로 인해 내용이 바뀐 커밋의 서명만 골라 삭제할 수 있습니다. * 이 기능 덕분에 히스토리 재작성 과정에서 변경되지 않은 객체들의 유효한 서명은 안전하게 보존할 수 있어, 데이터의 무결성을 유지하는 데 큰 도움이 됩니다. ## 저장소 구조 분석 도구(git-repo-structure)의 데이터 수집 강화 * 저장소의 성능 특성을 파악하기 위해 도입된 `git repo structure` 명령어가 이제 도달 가능한 객체들의 상세 크기 정보를 제공합니다. * 커밋, 트리, 블롭, 태그 등 각 객체 유형별로 압축 해제 시 크기(Inflated size)와 실제 디스크 점유 크기(Disk size)를 모두 확인할 수 있습니다. * 이는 외부 도구 없이도 네이티브 명령어를 통해 대규모 저장소의 구조적 부하를 진단하고 하드웨어 자원 계획을 세우는 데 유용하게 활용됩니다. 대규모 저장소를 운영하거나 히스토리 정제 작업을 빈번하게 수행하는 팀이라면 이번 Git 2.53.0 업데이트를 적극 권장합니다. 특히 부분 클론을 활용한 CI/CD 환경에서 기하급수적 재패킹을 통해 성능을 최적화하고, 히스토리 수정 시에도 유효한 서명을 유지함으로써 보안 수준을 한 단계 높일 수 있습니다.

datadog원문

LLM을 활용한 대규모 악성 풀 리퀘스트 탐지 (새 탭에서 열림)

Datadog은 AI 코딩 어시스턴트의 도입으로 급증한 코드 작업량과 이로 인한 보안 취약점 문제를 해결하기 위해, LLM 기반의 실시간 코드 리뷰 시스템인 'BewAIre'를 구축했습니다. 이 시스템은 기존의 정적 분석 도구가 탐지하기 어려운 공격자의 의도와 교묘한 난독화 패턴을 추론하여, 매주 수만 건에 달하는 풀 리퀘스트(PR)를 실시간으로 검사합니다. 이를 통해 보안 팀의 리뷰 피로도를 대폭 줄이면서도 높은 정확도로 악성 코드 삽입을 차단하는 성과를 거두고 있습니다. **AI 시대의 코드 보안 위협과 한계** * **급증하는 코드량과 공격 표면:** AI 어시스턴트 활용으로 매주 약 10,000개의 PR이 생성되면서 보안 팀이 검토해야 할 범위가 기하급수적으로 늘어났습니다. * **정적 분석의 한계:** 기존 SAST 도구는 정해진 규칙 기반으로 작동하여, 정상적인 의존성 업데이트나 권한 변경으로 위장한 지능형 공격(예: tj-actions 해킹)의 '의도'를 파악하지 못합니다. * **교묘한 난독화 기법:** 공격자들은 Base64 인코딩을 사용해 악성 스크립트를 숨기거나, 신뢰할 수 있는 봇 계정을 도용하여 보안 검사를 우회하는 전략을 사용합니다. **LLM 기반 보안 시스템 'BewAIre'의 구조** * **데이터 전처리 및 컨텍스트 강화:** 모든 PR의 코드 차이점(Diff)을 추출하고 작성자 정보, 저장소 유형 등의 메타데이터를 결합하여 모델이 분석할 수 있는 형태로 정규화합니다. * **의도 중심의 추론(Inference):** LLM은 단순한 문법 검사를 넘어 수정 사항 뒤에 숨겨진 의도를 분석하며, 특정 변경이 악의적인지 아니면 정상적인 패턴인지 분류합니다. * **실시간 경보 체계:** 분석 결과는 Datadog 보안 신호로 변환되어 대시보드에 즉시 반영되며, 위험도가 높은 경우 보안 엔지니어에게 즉각적인 알림(Paging)을 전송합니다. **실전 검증을 통한 성능 및 성과** * **높은 탐지 정확도:** 수백 개의 PR 데이터셋을 테스트한 결과 99.3% 이상의 정확도를 기록했으며, 실제 발생했던 tj-actions 및 Nx 공격 사례를 100% 탐지해냈습니다. * **낮은 오탐률(False Positive):** 프롬프트 엔지니어링과 데이터 튜닝, 안전한 패턴에 대한 억제 규칙을 적용하여 오탐률을 0.03% 수준으로 유지하며 개발 속도 저하를 방지했습니다. * **맥락 제한 극복:** 모델의 컨텍스트 제한으로 인한 성능 저하를 방지하기 위해 데이터를 효율적으로 정제하고 프롬프트를 최적화하는 기술적 노하우를 적용했습니다. 대규모 개발 환경에서 보안을 유지하려면 인간 리뷰어의 피로도를 줄여줄 수 있는 지능형 자동화 도구가 필수적입니다. LLM을 보안 리뷰에 도입할 때는 단순한 코드 분석을 넘어 작성자의 의도와 주변 맥락을 함께 파악하도록 설계해야 하며, 이를 기존의 보안 모니터링 워크플로우에 통합함으로써 실질적인 방어 체계를 구축할 수 있습니다.

line원문

3년 차 앱 개발자가 일하는 순서를 공유합니다 (새 탭에서 열림)

효율적인 협업과 코드 리뷰를 위해 개발 프로세스를 세분화하고 작업 단위를 최소화하는 것이 핵심입니다. 기획 시뮬레이션부터 PoC(Proof of Concept), 그리고 리뷰어를 배려한 PR(Pull Request) 작성까지 이어지는 체계적인 워크플로우를 통해 작업의 예측 가능성을 높이고 팀 내 신뢰를 구축할 수 있습니다. 궁극적으로 작고 명확한 단위로 일하는 습관은 본인의 히스토리 관리와 팀의 전체 생산성 향상에 기여합니다. ### 기획 리뷰와 동작 시뮬레이션 * 기획서의 목적과 작동 방식을 명확히 이해하고, 실제 코드를 작성하듯 데이터 흐름과 화면 전환, 예외 상황(Edge Case)을 머릿속으로 시뮬레이션합니다. * 이 과정에서 사용자 경험을 위한 개선 아이디어나 의문점이 생기면 기획자와 즉시 소통하여 요구 사항을 확정합니다. * 복잡한 기능은 다이어그램이나 화살표를 활용해 전체적인 구조와 데이터 흐름을 시각화하여 큰 그림을 먼저 그립니다. ### 협업 효율을 높이는 작업 가시화 * 그려둔 작업 흐름을 바탕으로 Jira 에픽(Epic)과 하위 이슈들을 생성하여 전체 작업을 눈에 보이게 쪼갭니다. * 중요도가 높거나 여러 명이 관여하는 작업의 경우, 티켓을 확정하기 전 동료들에게 개발 방향 콘셉트를 공유하여 피드백을 받습니다. * 사전 공유 단계를 거치면 추후 리뷰 단계에서 발생할 수 있는 대규모 수정을 미연에 방지하고 불필요한 논쟁을 줄일 수 있습니다. ### PoC를 통한 규모 검토와 셀프 피드백 * 본격적인 개발 전 프로토타이핑(PoC)을 진행하며 예상치 못한 문제나 누락된 시나리오가 없는지 점검합니다. * PoC 단계의 코드 양을 확인하여(저자 기준 400줄), 변경 사항이 너무 많다면 주제별로 티켓을 분리하거나 하위 작업(Sub-task)으로 세분화합니다. * "내가 이 PR을 리뷰한다면 부담스럽지 않을까?"라는 질문을 스스로 던지며 리뷰어가 이해하기 쉬운 적정 규모로 작업을 조정합니다. ### 리뷰어 중심의 구현 및 PR 작성 * 의미 있는 단위로 커밋을 쪼개고, 인터페이스 정의 후 구현체를 작성하는 등 논리적인 순서로 코드를 쌓아 올립니다. * PR 작성 시에는 목적, 원인, 영향 범위, 테스트 방법 등을 상세히 기록하며, 필요시 동작 영상을 첨부하여 리뷰어의 이해를 돕습니다. * 작고 명확한 PR은 문제가 발생했을 때 원복(Revert)이 쉽고, 리뷰어에게 '읽기 편한 코드'라는 신뢰를 주는 효과가 있습니다. 이러한 워크플로우를 정착시키면 개발 기간 산정의 정확도를 높일 수 있습니다. 특히 Jira의 시간 기록 기능을 활용해 '최초 추정 시간'과 '실제 소요 시간'을 비교하고 기록하는 습관을 들이면, 본인의 개발 속도를 객관적으로 파악하고 더욱 정교한 일정 관리가 가능해집니다. 환경에 맞춰 이 프로세스를 유연하게 적용해 보시길 권장합니다.

slack3분 읽기큐레이션 요약

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 재사용을 결합하면 빌드 시간과 클라우드 비용을 동시에 줄일 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

코드 변경 시 기기

Figma는 GitHub 릴리스 브랜치에 병합되는 코드가 회사가 관리하는 신뢰할 수 있는 기기에서 변경되었음을 보장하기 위해, 커밋 서명과 Okta Device Trust 인증서를 결합했다. GitHub의 기본 커밋 서명 검증만으로는 개인 GPG 키, OAuth·PAT·SSH 키, 웹 UI/API를 통한 위조 커밋을 충분히 차단할 수 없다고 판단했다. 이에 회사 기기의 보안 상태를 반영하는 X.509 인증서로 커밋을 서명하는 자체 검증 체계를 구축했다. ## 프로덕션 코드와 릴리스 브랜치의 위험 - GitHub 릴리스 브랜치는 프로덕션에 배포되는 코드의 기준점이므로 공격자의 주요 표적이다. - 개발자 수와 배포 빈도가 증가하면서 악성 코드가 프로덕션에 유입될 수 있는 공격 표면도 커졌다. - Figma는 Pull Request에 작성자와 다른 엔지니어의 승인을 모두 요구하는 “이중 통제(dual-control)”를 적용하고 있었다. - 그러나 공격자가 세션 자격 증명, 개인 액세스 토큰(PAT), OAuth 토큰, SSH 키를 탈취하면 정상적인 계정 보안 절차를 우회해 코드를 변경할 가능성이 남아 있었다. ## GitHub 커밋 서명 검증의 한계 - GPG 커밋 서명은 커밋 작성자의 정당성을 증명하고 GitHub에 녹색 “Verified” 표시를 제공한다. - 하지만 개발자가 등록한 개인 GPG 키를 회사가 통제하거나 특정 기기에 연결하기 어렵다. - GitHub 웹 UI와 API에서 생성된 커밋은 GitHub의 웹 플로우 GPG 키로 서명되어 자동으로 검증된다. - 따라서 OAuth 앱, 세션, PAT, SSH 키가 탈취되면 공격자가 GitHub에서 “Verified” 상태의 악성 커밋을 만들 수 있다. - 장기 액세스 토큰은 Okta SSO나 커밋 서명 검증이 적용되는 신뢰 경계 밖에서 사용될 수 있어, 토큰 사용량을 별도로 감시해야 하는 부담이 생긴다. - Figma는 이러한 활동을 수동 모니터링하는 대신, 기기 신뢰 정보를 커밋 서명에 직접 포함하는 방식을 선택했다. ## Okta Device Trust 인증서 - Figma의 Endpoint Security Baseline은 최신 브라우저와 macOS, 활성화된 악성코드 방어 소프트웨어 등 여러 보안 조건을 요구한다. - Figma는 2022년 말부터 Amazon Private CA를 사용해 회사 MacBook에 X.509 Okta Device Trust 인증서를 발급했다. - 인증서는 JAMF를 통해 배포되며 15일마다 갱신된다. - 인증서 발급 시점에 노트북이 Endpoint Security Baseline을 충족했다는 사실을 증명한다. - Okta Identity Engine을 이용해 AWS, Stripe, Snowflake 같은 민감한 서비스에 기기 신뢰 정책을 적용할 수 있다. - 이 인증서는 Okta 로그인에만 한정되지 않고, X.509 인증서로 데이터를 서명할 수 있는 모든 작업에서 기기 신뢰를 증명하는 데 활용할 수 있다. ## X.509 인증서로 Git 커밋 서명 - Figma는 기존의 Device Trust 인증서를 Git 커밋 서명에도 사용할 수 있는지 검토했다. - Git은 S/MIME 방식으로 X.509 인증서를 사용해 커밋을 서명할 수 있다. - GitHub가 제공하는 `smimesign` 유틸리티는 macOS 키체인이나 Windows 인증서 저장소에 있는 인증서와 키를 사용해 Git 커밋을 서명한다. - 기본 설정 예시는 다음과 같다. ```sh git config commit.gpgsign true git config gpg.format x509 git config gpg.x509.program smimesign git config user.signingkey <your_x509_key_id> ``` - 이 설정을 적용하면 Git은 지정된 X.509 키를 이용해 모든 커밋에 서명한다. - 다만 Figma의 인증서는 15일마다 갱신되므로 서명 키가 계속 바뀐다. - 따라서 개발자가 매번 새로운 인증서 ID를 수동으로 설정하지 않도록, Git이 최신 인증서를 동적으로 찾는 별도 처리가 필요했다. ## 실용적인 결론 GitHub의 “Verified” 표시는 커밋의 무결성만으로는 충분하지 않다. 민감한 코드 변경을 보호하려면 커밋 서명 키를 회사가 관리하는 기기와 연결하고, 기기의 보안 상태를 인증서 발급 조건에 포함하는 방식이 효과적이다. Figma의 접근법은 SSO·2FA·PR 승인 절차를 대체하기보다, 기기 기반 신뢰 검증을 추가해 코드 변경의 출처를 더욱 강하게 제한한 사례다.

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