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

Diff 라인 성능 개선을 위한 험난한 여정

GitHub는 대규모 풀 리퀘스트에서도 **Files changed** 탭의 반응성과 안정성을 유지하기 위해 단일 해결책이 아닌 여러 최적화 전략을 적용했다. 특히 diff 라인마다 생성되는 DOM 요소, React 컴포넌트, 이벤트 핸들러를 줄여 메모리 사용량과 입력 지연을 낮추고, 가장 큰 변경 사항에는 가상화를 적용해 렌더링 범위를 제한하는 방향을 택했다. 핵심 교훈은 작은 구조적 최적화도 수천 개의 diff 라인에 누적되면 큰 성능 개선으로 이어진다는 것이다. ## 대규모 풀 리퀘스트에서 성능이 어려운 이유 - GitHub의 풀 리퀘스트는 한 줄 수정부터 수천 개 파일과 수백만 줄을 포함하는 변경까지 규모 편차가 매우 크다. - 일반적인 풀 리퀘스트는 빠르게 동작했지만, 대규모 변경에서는 다음 문제가 발생했다. - JavaScript 힙이 극단적인 경우 1GB를 초과 - DOM 노드 수가 40만 개 이상으로 증가 - 페이지 상호작용이 매우 느려지거나 사실상 사용할 수 없게 됨 - 입력 후 다음 화면이 표시되기까지의 시간인 INP가 허용 수준을 초과 - 모든 기능과 브라우저의 기본 동작을 유지하면서 최악의 경우까지 해결하는 단일 기법은 현실적인 한계가 있었다. ## 풀 리퀘스트 규모별 최적화 전략 GitHub는 변경 규모와 복잡도에 따라 서로 다른 전략을 조합했다. - **diff 라인 컴포넌트 최적화** - 대부분의 풀 리퀘스트에서 기본 diff 화면을 빠르게 유지 - 중간 및 대규모 리뷰에서도 브라우저의 기본 `find-in-page` 같은 동작을 보존 - **가상화를 통한 점진적 성능 저하** - 가장 큰 풀 리퀘스트에서는 한 번에 렌더링하는 콘텐츠 양을 제한 - 모든 내용을 동시에 DOM에 올리지 않아 응답성과 안정성을 우선 - **기반 컴포넌트와 렌더링 개선** - 특정 모드에 관계없이 모든 크기의 풀 리퀘스트에 누적 효과를 제공 - 렌더링 구조 자체를 단순화해 메모리와 상호작용 비용을 줄임 ## 초기 목표와 측정 지표 최적화 작업의 목표는 단순히 평균 속도를 높이는 데 그치지 않았다. - JavaScript 힙 크기와 메모리 사용량 감소 - DOM 노드 수 감소 - 평균 INP 개선 - 특히 최악의 사용자 경험을 나타내는 p95와 p99 INP 대폭 개선 - 이를 위해 상태, HTML 요소, JavaScript 코드, React 컴포넌트 수를 전반적으로 줄이는 단순화 전략을 채택 ## v1의 문제: diff 라인당 높은 렌더링 비용 React로 처음 diff 화면을 구현한 v1은 작은 재사용 컴포넌트를 많이 조합하는 구조였다. - unified 뷰의 diff 한 줄에는 최소 약 10개의 DOM 요소가 필요했다. - split 뷰에서는 한 줄당 약 15개의 DOM 요소가 필요했다. - 구문 강조를 적용하면 추가 `<span>` 요소가 더해져 DOM 수가 증가했다. - React 계층에서도 다음과 같은 컴포넌트가 생성됐다. - unified 뷰: 한 줄당 최소 8개 컴포넌트 - split 뷰: 한 줄당 최소 13개 컴포넌트 - 댓글, hover, focus 등 추가 상태가 활성화되면 컴포넌트 수는 더 늘어났다. - 작은 컴포넌트마다 React 이벤트 핸들러를 5~6개씩 연결하는 경우가 많았다. - 결과적으로 diff 한 줄에 20개 이상의 이벤트 핸들러가 붙을 수 있었고, 이를 수천 줄에 적용하면서 비용이 급격히 커졌다. v1의 한 줄당 최소 구조는 다음과 같았다. - DOM 요소 10~15개 - React 컴포넌트 8~13개 - React 이벤트 핸들러 20개 이상 - 다수의 작은 재사용 컴포넌트 이 구조는 일반적인 규모에서는 문제가 없었지만, 데이터 크기가 사실상 제한되지 않는 대규모 풀 리퀘스트에서는 변경 줄 수가 늘수록 INP와 JavaScript 힙 사용량이 함께 악화됐다. ## v2의 방향: 작은 변경을 대규모로 누적 v2에서는 눈에 띄지 않는 HTML 구조까지 점검해 diff 라인당 비용을 줄였다. - 줄 번호 셀에 불필요하게 포함되어 있던 `<code>` 태그를 제거했다. - diff 한 줄에서 DOM 노드 2개를 줄이는 것은 개별적으로는 작은 개선처럼 보인다. - 그러나 10,000줄을 렌더링하면 DOM 노드 20,000개를 제거하는 효과가 발생한다. - 이처럼 줄 단위의 사소한 최적화도 대규모 데이터에서는 메모리 사용량과 렌더링 비용에 크게 누적된다. - 성능 개선에서는 큰 기능 변경만큼 불필요한 태그, 컴포넌트, 이벤트 핸들러를 하나씩 제거하는 작업도 중요하다. ## 실용적인 결론 대규모 목록이나 코드 diff를 렌더링할 때는 처음부터 최악의 데이터 규모를 고려해야 한다. 컴포넌트를 잘게 나누는 구조가 유지보수에는 유리할 수 있지만, 각 요소에 상태와 이벤트 핸들러를 추가하면 수천 개 항목에서 큰 비용이 된다. 따라서 DOM 구조를 단순화하고, 항목별 렌더링 비용을 측정하며, 극단적인 규모에는 가상화를 적용하는 조합이 효과적이다.

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

ReactJavaScriptHTMLweb-performance+3

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

Figma Make에서 더 많은 맥락과 제어력으로 빌드하기 | Figma Blog

Figma Make가 **Make kits**와 **Make attachments**를 통해 디자인 시스템과 실제 프로젝트 자료를 반영한 프로토타입을 생성하도록 개선됐다. Make kits는 코드 패키지나 Figma 라이브러리의 컴포넌트·스타일·토큰과 사용 지침을 제공하고, attachments는 데이터·법률 문구·스크린샷 등 프로젝트별 맥락을 전달한다. 이를 통해 범용적인 초안에서 출발해 반복적으로 수정하는 대신, 실제 제품 구조와 제약에 가까운 결과물을 더 빠르게 만들 수 있다. ## AI 초안이 실제 제품과 어긋나는 문제 - 기존 AI 생성 UI는 레이아웃과 인터랙션은 그럴듯하지만 다음과 같은 문제가 있었다. - 팀의 실제 디자인 시스템 컴포넌트를 사용하지 않음 - 카피가 placeholder로 남음 - 예외 상황과 중요한 edge case가 반영되지 않음 - 프로덕션 코드의 구조와 다른 방식으로 구현됨 - 그 결과 초기 생성 속도는 빨라도, 리뷰 전에 디자인 시스템에 맞게 다시 작성하고 조정하는 데 많은 시간이 필요했다. - Figma는 이 문제의 원인을 생성 품질 자체가 아니라 **팀이 실제 개발에 사용하는 맥락의 부족**으로 설명한다. ## Make kits: 디자인 시스템을 학습시키는 패키지 - Make kit은 디자인 시스템의 컴포넌트나 스타일과, 이를 어떻게 사용해야 하는지 설명하는 세부 가이드라인을 하나의 재사용 가능한 패키지로 결합한다. - 다음과 같은 소스를 사용할 수 있다. - 공개 npm 레지스트리의 JavaScript 패키지 - Figma의 보안 비공개 레지스트리에 저장된 코드 패키지 - Figma 라이브러리의 스타일과 디자인 토큰 - 가이드라인은 단순히 “어떤 컴포넌트가 존재하는가”뿐 아니라 다음까지 전달한다. - 컴포넌트를 어떤 상황에 사용해야 하는지 - 컴포넌트가 어떤 구조와 패턴을 따라야 하는지 - 디자인 시스템의 규칙을 프로토타입에 어떻게 적용해야 하는지 - 따라서 Make는 일반적인 UI 요소를 조합하는 대신, 팀의 코드베이스와 가까운 구조로 프로토타입을 시작할 수 있다. ## Make kits가 팀 협업에 주는 효과 - 폼, 대시보드, 설정 화면, 온보딩 플로우 등 여러 팀이 공유하는 화면에서 일관성이 높아진다. - 여러 팀이 동시에 프로토타입을 제작해도 디자인 시스템에서 벗어날 가능성이 줄어든다. - 리뷰 전에 spacing, 컴포넌트 선택, UI 패턴을 다시 맞추는 작업이 감소한다. - 엔지니어 입장에서는 익숙한 컴포넌트와 코드 패턴을 바로 확인할 수 있다. - “이 부분은 커스텀 구현인가?”와 같은 확인 질문이 줄어들어, 디자인을 코드로 번역하는 시간보다 제안 자체를 검토하고 개선하는 데 집중할 수 있다. - Figma는 향후 Figma 라이브러리의 컴포넌트 구조를 더욱 정확히 재현하는 방향으로 Make kits를 발전시킬 계획이다. ## Make attachments: 프로젝트의 실제 맥락 반영 - 디자인 시스템만으로는 각 프로젝트의 고유한 요구사항을 모두 설명할 수 없다. - 실제 프로젝트에는 다음과 같은 정보가 추가로 필요하다. - 실제 사용자 데이터 - 마이그레이션 제약 - 예외 처리와 edge case - 규정 및 컴플라이언스 요구사항 - 브랜드 콘텐츠와 법률 문구 - Make attachments는 이런 자료를 긴 프롬프트로 요약하지 않고 원본 파일 형태로 Make에 전달한다. - 지원되는 자료에는 다음이 포함된다. - PDF와 Markdown 문서 - CSV·JSON 데이터셋 - 스크린샷과 이미지 - 브랜드 가이드라인 - 법률 문구 - 미디어 파일과 SVG - 코드 및 관련 프로젝트 파일 ## 실제 데이터와 제약을 반영하는 프로토타이핑 - 예를 들어 디지털 제품의 전체 온보딩 플로우를 만들 때는 다음 정보가 동시에 필요할 수 있다. - 실제 사용자 데이터 - 법률상 반드시 표시해야 하는 문구 - 여러 입력 검증 상태 - 정상 흐름 외의 예외 상황 - 첨부 파일 없이 프롬프트만 사용하면 Make가 법률 문구를 임의로 줄이거나, 검증 상태를 단순화하거나, 이상적인 정상 흐름만 생성할 수 있다. - 원본 PDF, 데이터셋, 스크린샷 등을 첨부하면 Make가 프로젝트 자료를 직접 참조하므로, 보다 현실적인 콘텐츠와 제약을 포함한 프로토타입을 만들 수 있다. ## 디자인 시스템과 프로젝트 자료의 결합 - Make kits는 **제품 전반에 공통으로 적용되는 규칙**을 제공한다. - Make attachments는 **특정 프로젝트에만 존재하는 데이터와 제약**을 제공한다. - 두 기능을 함께 사용하면 다음과 같은 흐름이 가능하다. - Make kits로 실제 코드 또는 Figma 라이브러리 기반의 컴포넌트 사용 - attachments로 실제 데이터, 콘텐츠, 법률 요구사항, 시각 자료 반영 - 생성 결과를 프로덕션 구조에 가깝게 유지하면서 프로젝트의 세부 조건까지 검증 - 결과적으로 프로토타입 제작은 “일반적인 UI 초안 생성”에서 “실제 제품 조건을 반영한 탐색과 검증”으로 이동한다. 실무에서는 공통 컴포넌트와 토큰을 Make kit으로 정리하고, 기능별 요구사항·데이터·법률 문구·예외 상태는 attachments로 함께 제공하는 방식이 효과적이다. 이렇게 하면 생성 후 대규모 수정에 쓰는 시간을 줄이고, 초기 단계부터 개발·디자인 리뷰에 적합한 프로토타입을 만들 수 있다.

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

React디자인 시스템JavaScriptfigma-make+3

slack·2026년 3월 19일·3분 읽기큐레이션 요약

슬랙이 알림 기능을 어떻게 다시 만들었나 📣

Slack은 알림이 많아서가 아니라 사용자가 알림 설정을 이해하고 통제하기 어려워서 “소음”을 느낀다고 진단했다. 이에 데스크톱과 모바일의 서로 다른 설정 체계를 하나의 모델로 통합하고, 활동 알림과 푸시 알림을 분리했다. 레거시 호환성과 롤백 가능성을 고려한 읽기 시점 마이그레이션, 자동 저장, 클라이언트 간 상태 동기화를 통해 더 예측 가능하고 차분한 알림 경험을 구축했다. ## 알림 소음의 근본 원인 - Slack에서 알림 과부하는 고객 불만의 주요 원인이며, 고객 경험 관련 문의의 상위 3개 요인에 포함됐다. - 참여한 채널 수가 많을수록 사용자는 알림 동작을 더 혼란스럽고 압도적으로 느꼈다. - 문제는 단순히 알림의 양이 아니라, 여러 해에 걸쳐 누적된 레거시 아키텍처에도 있었다. - 데스크톱과 모바일이 서로 다른 선호도 모델을 사용했다. - 모바일의 `nothing`과 데스크톱의 `Off`가 같은 의미가 아니었다. - 설정을 바꿔도 실제 결과를 예측하기 어려웠다. - 알림 대상과 전달 방식이 강하게 결합되어 있었다. - 푸시 알림을 줄이면 인앱 활동 확인까지 포기해야 했다. - 클라이언트 간 설정 동기화가 불안정해 데스크톱과 모바일에서 서로 다른 알림이 발생하거나 설정을 반복해야 했다. - 고급 기능이 여러 메뉴에 흩어져 있어 파워 유저도 전체 설정 구조를 파악하기 어려웠다. ## 하나의 알림 모델로 통합 Slack은 UI만 개편하지 않고 알림의 동작 방식 자체를 재설계했다. - 채널 알림을 세 가지 선택지로 단순화했다. - 모든 새 게시물 - 멘션 - 음소거 - 데스크톱과 모바일의 푸시 알림을 독립적인 켜기/끄기 옵션으로 통합했다. - 모바일에도 “모든 읽지 않은 항목 배지 표시” 같은 고급 제어 기능을 제공했다. - 데스크톱과 모바일의 전역 설정 구조와 문구를 일관되게 정비했다. - 단순화된 선호도 로직을 사용해 여러 클라이언트에서 동일한 상태를 유지하도록 개선했다. ## 선호도 데이터 마이그레이션 기존에는 데스크톱과 모바일 설정이 각각 알림 대상과 푸시 전달을 함께 결정했다. ```text 기존 desktop: everything | mentions | nothing mobile: everything | mentions | nothing ``` 새 모델에서는 활동과 푸시를 분리했다. ```text 변경 후 desktop: everything | mentions desktop_push_enabled: true | false mobile: everything | mentions | nothing ``` - 데스크톱의 `desktop_push_enabled`를 새로 도입해 푸시 알림만 별도로 제어했다. - 기존 사용자의 데이터베이스 값을 일괄적으로 직접 변경하지 않았다. - 잘못된 마이그레이션이나 롤백 문제를 피하기 위한 선택이다. - 새 설정을 기존 값에 기반해 백필했다. - 읽기 시점에 레거시 `Off`를 새로운 의미의 `Mentions + 푸시 비활성화`로 해석했다. - 사용자는 기존과 동일한 경험을 유지하면서도 새로운 분리형 알림 구조를 사용할 수 있었다. - 결과적으로 인앱 배지와 활동 알림은 계속 확인할 수 있고, 실제 방해가 되는 푸시만 별도로 끌 수 있게 됐다. ## 자동 저장과 “무엇을 받을지”와 “어떻게 받을지”의 분리 기존 알림 모달은 변경할 때마다 사용자가 `Save` 버튼을 눌러야 했다. - 저장을 잊으면 설정이 적용되지 않아 사용자가 알림 시스템이 고장 났다고 오해할 수 있었다. - 새 모달은 자동 저장을 적용해 변경 즉시 설정이 반영된다. - 알림 설정을 다음 두 축으로 분리했다. - 어떤 활동을 받을 것인가 - 어떤 방식으로 전달받을 것인가 - 예를 들어 모든 활동을 인앱에서 확인하되, 푸시는 멘션에 대해서만 받는 구성이 가능해졌다. - 데스크톱과 모바일 UI에는 재사용 가능한 React 컴포넌트를 활용해 일관성을 높였다. - 기존 모바일 전용 레거시 UI 코드도 대체해 플랫폼별 동작 차이를 줄였다. ## 크로스플랫폼 일관성 - 프로젝트는 수백 개의 댓글이 달린 기술 논의와 제품·디자인·프론트엔드·백엔드·모바일 팀 간 조율을 필요로 했다. - 핵심 목표는 단순히 같은 화면을 만드는 것이 아니라, 어떤 클라이언트에서 설정해도 동일한 상태와 의미를 갖게 하는 것이었다. - 이 구조를 통해 사용자는 데스크톱에서 바꾼 설정이 모바일에서 다르게 동작하는 문제를 덜 겪게 됐다. Slack의 접근 방식은 알림을 무조건 줄이는 대신, 활동 알림과 푸시 알림을 분리하고 설정 의미를 명확히 하는 데 초점을 둔다. 비슷한 시스템을 설계할 때도 레거시 값을 즉시 덮어쓰기보다 읽기 시점 호환성, 점진적 백필, 독립적인 설정 축, 자동 저장을 활용하는 것이 안전하고 사용자 혼란도 줄일 수 있다.

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

Reactstate-managementdatabase-migrationcross-platform-development+1

toss·2026년 3월 17일원문

소프트웨어 3.0 시대를 맞이하며 (새 탭에서 열림)

소프트웨어 개발은 명시적 코딩(1.0)과 데이터 기반 학습(2.0)을 거쳐, 자연어 프롬프트가 프로그램이 되는 '소프트웨어 3.0' 시대로 진입하고 있습니다. 하지만 강력한 LLM 모델이라도 실질적인 업무를 수행하기 위해서는 모델의 능력을 제어하고 연결하는 '하네스(Harness)'라는 도구적 환경이 필수적이며, 이를 설계하는 데 있어 기존 소프트웨어 1.0의 계층형 아키텍처 원칙은 여전히 유효한 가이드가 됩니다. 결국 미래의 개발은 전통적인 설계 원칙을 유지하면서도, 에이전트가 인간과 소통하며 의사결정을 내리는 'Human-in-the-Loop(HITL)' 모델을 결합하는 방향으로 진화할 것입니다. **소프트웨어 3.0과 하네스의 필요성** - 안드레 카파시는 소프트웨어 3.0을 자연어로 된 프롬프트가 코드를 대신하는 시대로 정의하며, 이것이 이전 세대의 패러다임을 흡수할 것이라고 예측했습니다. - 하지만 LLM 단독으로는 코드베이스를 읽거나 데이터베이스에 접근하는 등의 실질적인 작업을 수행할 수 없다는 한계가 있습니다. - 이를 해결하기 위해 등장한 것이 '하네스(Harness)' 개념으로, 앤스로픽의 'Claude Code'처럼 모델이 도구(Skills)를 사용하고 외부와 통신하며 에이전트로 동작하게 만드는 실행 환경을 의미합니다. **계층형 아키텍처로 매핑한 에이전트 구조** - **슬래시 커맨드(Slash Command) = 컨트롤러(Controller):** `/review`, `/refactor`와 같은 명령어는 사용자 요청을 받아 적절한 워크플로우를 실행하는 서비스의 진입점 역할을 합니다. - **서브 에이전트(Sub-agent) = 서비스 계층(Service Layer):** 여러 기술(Skills)을 조합해 특정 비즈니스 로직을 완수하며, 독립적인 컨텍스트를 유지하는 단위입니다. - **기술(Skills) = 도메인 컴포넌트:** 단일 책임 원칙(SRP)에 따라 코드 리뷰, 테스트 생성 등 명확한 한 가지 기능만 수행하는 가장 작은 단위의 기능 모듈입니다. - **MCP(Model Context Protocol) = 인프라/어댑터:** 외부 API나 DB와의 연결을 추상화하여 내부 로직이 외부 시스템의 구현 상세를 몰라도 동작하게 돕습니다. - **CLAUDE.md = 프로젝트 헌장:** 기술 스택, 코딩 컨벤션 등 프로젝트의 변하지 않는 근간 원칙을 정의하며 시스템의 안정성을 보장합니다. **에이전트 설계에서 경계해야 할 안티패턴** - **God Sub-agent:** 하나의 서브 에이전트가 너무 많은 역할과 권한을 가지게 되면 관리 효율이 떨어지므로 적절한 분리가 필요합니다. - **기능 편애(Feature Envy):** 특정 기술이 자신의 역할 범위를 벗어나 다른 기술의 데이터나 프롬프트에 과도하게 의존하는 경우입니다. - **프롬프트 중복:** 동일한 프롬프트 내용이 여러 기술에 중복되어 포함될 경우 유지보수가 어려워지므로 공통화가 필요합니다. **에이전트만의 핵심 차별점: 질문하는 능력(HITL)** - 전통적인 소프트웨어는 예외 상황에서 미리 정의된 에러를 던지지만, 3.0 시대의 에이전트는 `UserAskQuestion` 기술을 통해 모호한 상황에서 사용자에게 직접 질문을 던질 수 있습니다. - 에이전트는 삭제나 배포처럼 되돌리기 어려운 작업, 혹은 여러 대안 중 선택이 필요한 고위험 상황에서 인간의 판단을 구하는 'Human-in-the-Loop' 구조를 가집니다. - 반면, 관습적으로 처리 가능한 일이나 안전한 반복 작업은 질문 없이 자율적으로 수행함으로써 효율성과 안정성 사이의 균형을 맞춥니다. 소프트웨어 3.0 시대에 적응하기 위해서는 모든 로직을 명시적으로 작성하려는 강박에서 벗어나야 합니다. 대신 계층 분리, 추상화, 단일 책임 원칙과 같은 전통적인 소프트웨어 공학의 정수를 에이전트 설계에 투영하여, LLM을 단순한 자동완성 도구가 아닌 신뢰할 수 있는 협력자로 구축하는 능력이 핵심 경쟁력이 될 것입니다.

React대규모 언어 모델쿠버네티스TypeScript+4

line·2026년 3월 9일원문

엔터프라이즈 LLM 서비스 구축기 2: 에이전트 엔지니어링 (새 탭에서 열림)

엔터프라이즈 LLM 서비스를 구축함에 있어 복잡한 최신 기술을 무작정 도입하기보다, 서비스의 본질에 집중하여 불필요한 기술을 덜어내는 '소거법' 기반의 아키텍처를 설계했습니다. 실전 운영 결과, 파인 튜닝 대신 RAG를, 기계적 청킹 대신 '검색 후 자르기' 전략을, 그리고 복잡한 워크플로 대신 단순한 ReAct 구조를 채택함으로써 96.1%라는 높은 응답률과 시스템 안정성을 동시에 확보할 수 있었습니다. 이는 화려한 기술적 기교보다 제한된 비용과 속도 안에서 최적의 효율을 찾는 것이 실제 서비스 환경에서 더 효과적임을 입증합니다. ### 지식 주입 방식의 선택: 파인 튜닝 제외와 RAG 채택 * 파인 튜닝은 새로운 지식(Fact)을 주입하기보다 답변 스타일(Style)을 조정하는 데 훨씬 효율적이며, 지식 주입 정확도는 상대적으로 낮다는 연구 결과를 바탕으로 RAG를 주력 기술로 선정했습니다. * 제품 문서가 수시로 갱신되는 환경에서 파인 튜닝은 매번 데이터셋을 재구성하고 교차 검수해야 하는 막대한 유지보수 비용이 발생하지만, RAG는 원본 문서 업데이트만으로 즉각적인 대응이 가능합니다. * 실험 결과, 소규모 데이터셋을 통한 파인 튜닝은 모델이 이미 학습한 방대한 기존 지식의 벽을 넘지 못하고, 질문 형식이 조금만 바뀌어도 오답을 내놓는 한계를 보였습니다. ### 문맥 보존을 위한 전략: 청킹 없는 '검색 후 자르기' * 기존 RAG의 기계적 청킹(Pre-split)은 문맥 상실의 문제를 야기하므로, 각 문서의 주제가 명확하고 분량이 적은 서비스 특성을 고려해 문서를 통째로 임베딩하는 역발상을 적용했습니다. * 사용자 질문이 들어오면 관련 문서를 통째로 찾은 뒤, 마크다운 헤더(##) 기준으로 분할하고 경량 LLM 필터를 통해 질문과 관련 있는 섹션만 정밀하게 추출하는 '검색 후 자르기(Post-split)' 프로세스를 구축했습니다. * 이 방식은 질문의 맥락을 이미 알고 있는 상태에서 문서를 자르기 때문에, 정보의 희석 없이 모델에게 가장 필요한 핵심 조각들만 선별하여 전달할 수 있다는 장점이 있습니다. ### 효율적인 행동 구조: 복잡한 워크플로 대신 ReAct 방식 * '계획 후 실행(Plan-and-execute)'이나 '멀티 에이전트' 구조는 시스템 복잡도와 응답 지연(Latency)을 높일 뿐, 실제 답변 품질에서의 체감 성능 향상은 크지 않았습니다. * 특히 멀티 에이전트 구조는 전문가 간의 질문 배분 과정에서 추가적인 LLM 호출 비용이 발생하고, 여러 도메인이 섞인 질문에서 정보가 누락되는 취약점을 보였습니다. * 정제된 컨텍스트와 적절한 도구가 주어진다면 모델 스스로 추론하고 행동하는 ReAct 루틴만으로도 복잡한 논리적 순서를 충분히 구현할 수 있음을 확인하여, 시스템을 단순하게 유지했습니다. 성공적인 AI 에이전트 구축의 핵심은 유행하는 기술을 좇는 '덧셈'이 아니라, 서비스의 본질에 맞는 기술만 남기는 '뺄셈'에 있습니다. 현재 발생하는 답변 실패 원인의 절반 이상이 기술적 결함이 아닌 '참조 문서의 부재'에서 기인한다는 점을 고려할 때, 모델 아키텍처를 복잡하게 만들기보다는 AI가 학습하고 참조할 '교과서(원본 문서)'의 품질을 높이는 것이 성능 향상을 위한 가장 확실하고 실용적인 투자입니다.

React데이터베이스 설계쿠버네티스PostgreSQL+4

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

6,000만 건

GitHub Copilot 코드 리뷰(CCR)는 출시 이후 사용량이 10배 증가해 GitHub 전체 코드 리뷰의 5건 중 1건 이상을 차지하고 있다. GitHub는 단순히 많은 댓글을 생성하는 대신 정확성·신호·속도를 기준으로 실제로 도움이 되는 리뷰를 제공하는 방향으로 발전시켰다. 저장소 맥락을 탐색하고 이전 리뷰를 기억하는 에이전트형 아키텍처와 개선된 UX를 통해, 개발자가 더 빠르고 자신 있게 풀 리퀘스트를 병합하도록 지원한다. ## Copilot 코드 리뷰의 성장과 목표 변화 - 2025년 4월 초기 출시 이후 사용량이 10배 증가했다. - 현재 GitHub에서 수행되는 코드 리뷰의 20% 이상을 Copilot 코드 리뷰가 담당한다. - 초기 목표는 가능한 한 철저한 리뷰를 제공하는 것이었지만, 실제 개발자들이 원하는 것은 다음과 같은 고신호(high-signal) 피드백임을 확인했다. - 중요한 로직 및 유지보수성 문제를 우선적으로 지적 - 문제의 원인과 해결 방법을 함께 설명 - 풀 리퀘스트를 빠르게 다음 단계로 진행하도록 지원 - 댓글에 대한 thumbs-up·thumbs-down 반응과 실제 병합 전 수정 여부를 지속적으로 분석해 품질을 개선했다. ## 정확성: 중요한 문제를 찾아내기 - Copilot은 사소한 스타일 문제보다 영향이 큰 로직 오류와 유지보수성 문제에 집중한다. - 정확성은 두 가지 방식으로 평가한다. - 알려진 코드 문제를 포함한 내부 테스트 - 실제 풀 리퀘스트에서 수집한 운영 데이터 - 주요 운영 지표는 다음과 같다. - 개발자 피드백: 댓글이 유용했는지에 대한 긍정·부정 반응 - 실제 수정 여부: 지적된 문제가 병합 전에 해결되었는지 확인 - 목표는 리뷰를 대충 끝내도록 하는 것이 아니라, 신뢰할 수 있는 문제를 빠르게 수정하게 하는 것이다. ## 신호: 댓글 수보다 유용성이 중요하다 - 코드 리뷰에서 댓글이 많다고 품질이 높은 것은 아니다. - Copilot은 문제뿐 아니라 권장 수정 방법까지 제시하는 댓글을 고신호 피드백으로 간주한다. - 71%의 리뷰에서는 실행 가능한 피드백을 제공하고, 나머지 29%에서는 불필요한 지적을 하지 않고 아무 댓글도 남기지 않는다. - 고신호 문제를 더 확실하게 식별할 수 있게 되면서 리뷰당 평균 댓글 수는 약 5.1개로 증가했다. - 댓글 수가 늘었음에도 리뷰 재작업(churn)이나 품질 기준은 악화되지 않았다. - 즉, “침묵이 잡음보다 낫다”는 원칙 아래 확실하지 않은 문제는 지적하지 않는다. ## 속도와 분석 깊이의 균형 - Copilot은 풀 리퀘스트가 열린 직후 신뢰할 수 있는 1차 리뷰를 제공하는 것을 목표로 한다. - 다만 더 깊은 추론에는 더 많은 계산 시간이 필요하므로 속도와 정확성 사이에 의도적인 절충이 있다. - 더 발전된 추론 모델을 적용한 결과: - 긍정적인 개발자 피드백이 6% 증가 - 리뷰 지연 시간은 16% 증가 - GitHub는 즉각적이지만 잡음이 많은 리뷰보다, 조금 늦더라도 실제 문제를 발견하는 리뷰가 더 가치 있다고 판단한다. - 지연 시간은 계속 줄이되, 고신호 피드백을 희생하지 않는 방향으로 개선하고 있다. ## 저장소 맥락을 이해하는 에이전트형 아키텍처 - 새로운 시스템은 저장소를 탐색하고 코드의 로직, 아키텍처, 불변 조건을 파악할 수 있다. - 에이전트형 구조로 전환한 뒤 긍정적인 피드백이 초기 기준 8.1% 증가했다. - 주요 개선점은 다음과 같다. - **읽는 즉시 문제를 기록**: 리뷰 마지막에 결과를 정리하는 방식이 아니라 분석 중 발견한 문제를 바로 유지해 초기 발견을 잊지 않는다. - **리뷰 간 메모리 유지**: 각 풀 리퀘스트를 고립된 이벤트로 처리하지 않고, 코드베이스에서 발견한 패턴과 맥락을 이후 리뷰에도 활용한다. - **장기 풀 리퀘스트에 계획 적용**: 긴 변경 사항을 검토하기 전에 명시적인 리뷰 계획을 세워 컨텍스트 손실을 줄인다. - **관련 이슈와 풀 리퀘스트 참조**: 코드만 보면 정상처럼 보이지만 프로젝트 요구사항과 맞지 않는 미묘한 문제까지 발견한다. ## 리뷰 결과를 쉽게 탐색하는 UX - **다중 라인 댓글** - 한 줄에 댓글을 고정하는 대신 관련된 논리적 코드 범위에 연결한다. - 문제가 발생한 전체 맥락과 수정 범위를 더 쉽게 이해할 수 있다. - **댓글 클러스터링** - 동일한 패턴의 오류를 여러 개의 댓글로 반복하지 않고 하나의 일관된 피드백 단위로 묶는다. - 풀 리퀘스트 타임라인의 복잡성과 인지 부담을 줄인다. - **배치 자동 수정** - 개별 댓글을 하나씩 처리하지 않고 같은 유형의 로직 오류나 스타일 문제를 한 번에 수정한다. - 반복적인 컨텍스트 전환을 줄이고 수정 작업을 빠르게 끝낼 수 있다. ## 조직 차원의 활용 - 12,000개 이상의 조직이 모든 풀 리퀘스트에 Copilot 코드 리뷰를 자동으로 실행하고 있다. - General Motors는 Copilot이 풀 리퀘스트 리뷰와 요약을 처리해 팀이 더 복잡한 업무에 집중할 수 있다고 평가했다. - WEX에서는 AI 지원 리뷰를 기본값으로 도입하면서 조직 전체의 Copilot 사용이 확대되었다. - WEX 개발자의 약 3분의 2가 Copilot을 사용하고 있으며, 가장 활발한 기여자들도 포함된다. 실무적으로는 Copilot의 댓글 수를 최대화하기보다, 실제로 수정할 가치가 있는 문제를 선별하는 보조 리뷰어로 활용하는 것이 적절하다. 개발자는 AI 피드백을 최종 판단으로 간주하기보다 thumbs-up·thumbs-down과 수정 결과를 통해 팀의 코드 리뷰 기준을 계속 조정해야 한다.

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

ReactAI 에이전트github-copilot코드 리뷰+4

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

전 세계 AI 기회 확장: GitHub

GitHub와 Andela는 AI 도구를 별도 교육 과정이 아니라 실제 프로덕션 개발 업무에 통합하는 방식으로 글로벌 개발자의 AI 활용 역량을 높였다. 2년간 Andela의 550만 명 네트워크를 대상으로 협력했고, AI Academy를 통해 3,000명의 엔지니어가 GitHub Copilot을 교육받았다. 사례에서 AI는 단순한 코드 생성보다 레거시 시스템 파악, 테스트 작성, 리팩터링 준비, 의사결정 지원을 통해 개발자의 자신감과 생산성을 높이는 데 효과적이었다. ## 지역에 따른 AI 학습 기회의 격차 - 아프리카, 남미, 동남아시아 등에는 뛰어난 개발자가 많지만 최신 기술, 멘토링, 학습 경로에 대한 접근성은 지역과 고용주에 따라 크게 다르다. - 불안정한 인터넷 연결, 고성능 컴퓨팅 부족, 클라우드 도구와 데이터 비용 등이 AI 학습을 어렵게 만든다. - 기존 교육 콘텐츠는 안정적인 인터넷과 충분한 자원을 전제로 하며, 지역 언어·문화·업무 환경을 충분히 반영하지 못하는 경우가 많다. - 비정규직이나 계약직 개발자는 재교육에 투자할 시간과 경제적 여유가 부족할 수 있다. - 저렴한 도구 접근성, 지역에 맞는 학습 과정, 커뮤니티 중심 생태계가 없으면 AI 발전이 기존의 기술 격차를 확대할 수 있다. ## 실제 업무 안에서 AI를 학습하는 방식 - 중견 개발자가 프로덕션 업무를 중단하고 AI를 실험하기는 현실적으로 어렵기 때문에, 학습은 기존 업무 흐름 안에서 이루어져야 한다. - 단순히 조직 전체에 AI 도구를 배포하고 자율적인 실험을 맡기는 것만으로는 충분하지 않다. - 어떤 직무가 AI의 효과를 크게 얻는지, 어떤 업무를 대상으로 하는지, 코드 리뷰와 품질 기준을 어떻게 바꿀지 명확히 해야 한다. - Andela는 개발자의 담당 업무와 AI 활용 가능성을 기준으로 참여자를 선정하고, 실제 운영 중인 시스템에 맞춰 직무와 교육 과정을 설계했다. - GitHub Copilot을 IDE, 풀 리퀘스트 리뷰, 리팩터링 작업에 직접 적용해 실제 제약 조건 속에서 효과를 평가했다. - 교육은 이상적인 연습 문제가 아니라 개발자가 실제로 유지보수해야 하는 시스템과 업무를 기반으로 구성됐다. ## 레거시 시스템 이해와 안전한 변경 - AI를 활용했을 때 가장 먼저 나타난 효과는 코드 작성 속도보다 낯선 시스템에 빠르게 적응하는 능력이었다. - 브라질의 시니어 엔지니어 Daniel Nascimento는 변경 전에 프로젝트의 목적, 아키텍처, 강점과 취약점을 파악하는 데 AI를 활용했다. - 테스트 커버리지가 부족한 레거시 코드에서는 리팩터링 전에 AI로 단위 테스트를 생성해 기존 동작을 보호할 경계를 만들었다. - 개발자들이 활용한 방식은 다음과 같다. - 기존 동작을 파악하기 위한 테스트 생성 - 복잡한 제어 흐름을 명확하게 만드는 리팩터링 초안 작성 - 시스템 경계와 구성 요소를 이해하기 위한 다이어그램 구상 - AI가 생성한 결과는 정리되지 않았거나 미묘한 오류를 포함할 수 있으므로, 개발자의 검토와 품질 관리가 여전히 필수적이다. ## 생산성보다 중요한 자신감과 판단력 - 몇 주간 실제 시스템에 AI를 적용한 개발자들은 다음과 같은 변화를 보고했다. - 익숙하지 않은 시스템에 더 빠르게 온보딩 - 모호하고 복잡한 업무를 맡는 데 대한 자신감 향상 - 환경 설정과 반복 작업에 쓰는 시간 감소 - 비즈니스 맥락과 실제 영향에 집중할 수 있는 시간 증가 - Daniel은 GitHub Copilot 사용 후 생산성이 약 50% 향상됐다고 평가했다. - 다만 효과의 핵심은 단순히 더 많은 코드를 빠르게 생성하는 데 있지 않고, 개발자가 시스템을 이해하고 더 나은 결정을 내릴 시간을 확보하는 데 있다. - AI는 개발자의 이해와 책임을 대체하지 않으며, 복잡한 프로덕션 환경에서는 검토·테스트·리팩터링 역량과 함께 사용해야 한다. ## 실무 적용을 위한 시사점 - AI 교육은 일회성 자격증 과정이 아니라 실제 담당 시스템과 업무에 연결해야 한다. - 모든 개발자에게 동일한 방식으로 배포하기보다 AI 효과가 큰 역할과 문제를 먼저 선정하는 것이 좋다. - 코드 생성뿐 아니라 테스트 작성, 레거시 분석, 문서화, 온보딩 등 초기 효과가 큰 영역부터 적용할 수 있다. - AI 도구의 도입 성과는 코드 생산량만이 아니라 시스템 이해 속도, 변경 안정성, 개발자의 판단력과 자신감까지 함께 평가해야 한다. - 지역별 인프라와 경제적 제약을 고려한 접근성 높은 교육·도구 지원이 글로벌 AI 격차를 줄이는 데 중요하다.

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

ReactAIgithub-copilotrefactoring+3

cloudflare·2026년 2월 24일원문

AI로 일주일 만에 Next. (새 탭에서 열림)

Cloudflare의 한 엔지니어가 AI 모델을 활용해 단 일주일 만에 Next.js를 Vite 기반으로 재구현한 'vinext'를 공개했습니다. vinext는 Next.js의 복잡한 빌드 아키텍처와 타 플랫폼 배포 시 발생하는 파편화 문제를 해결하기 위해 등장했으며, 기존 Next.js 코드를 그대로 유지하면서도 최대 4배 빠른 빌드 속도와 57%의 번들 크기 감소를 달성했습니다. 이는 AI를 활용해 기존 프레임워크의 API 표면을 완전히 새롭게 구현함으로써 서버리스 환경에서의 배포 효율성을 극대화한 사례입니다. ### 기존 Next.js 배포 및 개발 환경의 문제점 * Next.js는 Turbopack이라는 독자적인 툴체인을 사용하기 때문에, Cloudflare나 AWS Lambda 같은 서버리스 환경에 배포하려면 빌드 결과물을 해당 플랫폼에 맞게 재가공하는 복잡한 과정이 필요합니다. * 기존의 해결책인 OpenNext는 Next.js의 빌드 결과물을 역공학(Reverse-engineering)하여 대응해왔으나, 프레임워크 버전 업데이트 시 구조가 변경되면 대응이 늦어지거나 기능이 깨지는 등 취약한 구조를 가집니다. * 로컬 개발 환경은 Node.js에서 실행되는 반면 실제 배포는 에지 런타임에서 이루어지는 불일치 문제로 인해, Durable Objects나 AI 바인딩 같은 플랫폼 전용 API를 개발 단계에서 테스트하기가 매우 어렵습니다. ### Vite 기반의 완전한 재구현, vinext * vinext는 Next.js의 출력물을 수정하는 방식이 아니라, Vite 위에서 Next.js의 API 표면(라우팅, SSR, RSC, Server Actions, 미들웨어 등)을 처음부터 다시 구현한 클린 구현체입니다. * 사용자는 기존의 `app/`, `pages/` 디렉토리와 `next.config.js`를 그대로 사용할 수 있으며, 스크립트에서 `next`를 `vinext`로 바꾸는 것만으로 즉시 교체가 가능한 'Drop-in replacement' 형태를 지향합니다. * Vite의 환경 API(Environment API)를 활용하여 특정 플랫폼에 종속되지 않는 빌드 결과물을 생성하며, 향후 Rust 기반 번들러인 Rolldown이 도입되면 더 높은 성능 향상이 기대됩니다. ### 성능 지표 및 Cloudflare 최적화 기능 * 33개의 라우트를 포함한 앱 기준 벤치마크 결과, Next.js 16 대비 빌드 시간은 약 4배 단축되었고 클라이언트 번들 크기(Gzip 기준)는 57% 감소하는 성과를 보였습니다. * `vinext deploy` 명령어를 통해 소스 코드에서 Cloudflare Workers로 즉시 배포가 가능하며, Cloudflare KV를 활용한 캐시 핸들러를 통해 ISR(Incremental Static Regeneration) 기능을 기본적으로 제공합니다. * 개발 단계부터 실제 배포 환경과 동일한 `workerd` 런타임에서 앱이 구동되므로, 플랫폼 전용 기능을 별도의 워크아라운드 없이 로컬에서 완벽하게 테스트할 수 있습니다. ### 생태계 협력 및 향후 전망 * vinext 코드의 약 95%는 순수 Vite 기반으로 작성되어 있어 특정 호스팅 업체에 종속되지 않으며, Vercel을 포함한 타 플랫폼으로의 이식도 매우 용이한 구조입니다. * 현재 이 프로젝트는 실험적인 단계(Experimental)로 대규모 트래픽에서의 검증이 더 필요하지만, 이미 1,700개 이상의 테스트를 통과하며 안정성을 확보해 나가고 있습니다. * Cloudflare는 타 호스팅 제공업체들과 협력하여 이 툴체인을 확장할 계획이며, 오픈 소스 커뮤니티의 참여를 통해 다양한 배포 타겟을 확보하고자 합니다. **결론:** vinext는 현대적인 빌드 도구와 AI의 결합이 프레임워크의 구조적 한계를 얼마나 빠르게 극복할 수 있는지 보여주는 사례입니다. 성능 최적화와 서버리스 배포 편의성을 동시에 잡고자 하는 개발자들에게 유망한 대안이 될 것으로 보입니다.

ReactCloudflare Workers서버리스vite+4

spotify·2026년 2월 19일원문

Spotify 앱을 출시하는 방법: 내부 (새 탭에서 열림)

스포티파이는 Jira 중심의 복잡하고 분절된 릴리스 관리 프로세스를 개선하기 위해 자체 개발 포털인 Backstage 기반의 '릴리스 매니저 대시보드(Release Manager Dashboard)'를 구축했습니다. 이 도구는 10개 이상의 시스템에서 데이터를 통합하여 릴리스 매니저의 인지 부하를 줄이고, 안드로이드, iOS, 데스크톱 등 각 플랫폼의 릴리스 상태를 한눈에 파악할 수 있게 합니다. 결과적으로 스포티파이는 데이터 중심의 빠른 의사결정 체계를 갖추게 되었으며, 릴리스 과정에서 발생할 수 있는 휴먼 에러를 최소화했습니다. ### Jira 중심 프로세스의 한계와 새로운 도구의 탄생 * 기존에는 모든 릴리스 정보가 Jira 티켓에 흩어져 있어, 릴리스 매니저가 수많은 탭을 오가며 상태를 확인해야 하는 컨텍스트 스위칭 문제가 심각했습니다. * 새로운 대시보드는 컨텍스트 스위칭 최소화, 인지 부하 감소, 빠르고 정확한 의사결정 지원을 목표로 설계되었습니다. * 이를 통해 모바일 릴리스 프로세스에 대한 기본 지식만 있다면 누구나 직관적으로 상황을 이해할 수 있는 환경을 조성했습니다. ### 통합된 데이터와 트랙 중심의 관리 * 플랫폼(Android, iOS, Desktop)과 버전의 조합을 '트랙(Track)'으로 정의하고, 각 트랙을 독립적이면서도 통합적으로 관리합니다. * **트랙별 필수 데이터:** 릴리스 상태(State), 릴리스 차단 버그(Blocking Bugs), 회귀 테스트 통과 여부(Sign-off), 최신 릴리스 후보(RC) 빌드 및 앱스토어 업로드 상태 등을 포함합니다. * **품질 및 사용량 지표:** Crash 발생률, ANR(응답 없는 앱), 곡당 CPU 예외 사항, DAU(일일 활성 사용자 수) 등 실시간 품질 지표를 함께 모니터링합니다. * **미할당 버그 관리:** 특정 버전에 할당되지 않았거나 우선순위가 없는 버그들을 별도로 표시하여, 릴리스를 방해할 수 있는 잠재적 요소를 사전에 분류하고 담당 팀을 지정합니다. ### Backstage 기반의 에코시스템과 직관적인 UI * 스포티파이의 내부 개발자 포털인 Backstage의 플러그인(React, TypeScript 기반)으로 개발되어 기존 개발 도구들과의 UI/데이터 일관성을 유지합니다. * **신호등 시스템:** 상태를 초록색(준비 완료), 노란색(대기/경고), 빨간색(오류/즉각 조치 필요)으로 시각화하여 즉각적인 상황 판단을 돕습니다. * 상세 정보가 필요한 경우 클릭 한 번으로 앱 빌드나 크래시 상세 리포트 등 관련 플러그인으로 바로 연결되는 드릴다운(Drill-down) 구조를 갖췄습니다. ### 백엔드 아키텍처 및 성능 최적화 * 약 10개의 기존 시스템으로부터 데이터를 수집하고 통합하는 API 게이트웨이 역할을 수행하는 백엔드 서비스를 구축했습니다. * 초기 버전은 매번 대규모 쿼리를 실행하여 속도가 느리고 비용이 높았으나, 5분 단위의 데이터 사전 집계(Pre-aggregation)와 캐싱 기술을 도입해 최적화했습니다. * 이를 통해 대시보드 로딩 시간을 8초로 단축하고, 운영 비용을 획기적으로 낮추면서도 높은 신뢰성을 확보했습니다. ### 단계별 릴리스 모니터링 상세 * **Production(운영):** 이미 배포된 버전의 크래시 지표와 지난 24시간 동안의 DAU 추이를 모니터링하여 배포 후 예기치 못한 문제를 감시합니다. * **Current(현재):** 배포 대기 중인 버전의 상태를 집중 관리합니다. ITGC(IT 일반 통제) 테스트 통과 여부와 데이터 손실 임계치 준수 여부 등을 확인하여 최종 배포 가능 여부를 결정합니다. * **Upcoming(차기):** 다음 릴리스 버전을 미리 준비하며, 해당 단계에서 불필요한 섹션은 비활성화하여 현재 집중해야 할 정보와 구분합니다. 복잡한 마이크로서비스 환경이나 멀티 플랫폼 앱을 운영하는 조직이라면, 흩어진 릴리스 데이터를 하나로 모으는 전용 대시보드 구축이 필수적입니다. 특히 Backstage와 같은 내부 개발 포털을 활용해 도구 간 데이터 일관성을 확보하고 시각적인 상태 지표(초록/노랑/빨강)를 도입하면, 릴리스 관리의 효율성을 극대화하고 배포 안정성을 크게 높일 수 있습니다.

ReactCI/CDTypeScriptjira+4

cloudflare·2026년 1월 30일원문

Cloudflare 플랫폼에서 수직적 마 (새 탭에서 열림)

Cloudflare는 단일 도메인 내에서 여러 독립적인 Cloudflare Workers를 특정 URL 경로에 매핑하여 팀별로 자율성을 보장하는 '버전별 마이크로프론트엔드(VMFE)' 템플릿을 발표했습니다. 이 방식은 기존의 수평적 마이크로프론트엔드와 달리 경로별로 전체 기술 스택을 분리함으로써, 팀이 프레임워크 선택부터 배포 파이프라인까지 독립적으로 제어할 수 있게 합니다. 결과적으로 사용자에게는 하나의 매끄러운 서비스로 보이지만, 내부적으로는 여러 팀이 서로의 간섭 없이 독립적으로 기능을 개발하고 배포할 수 있는 환경을 제공합니다. ### 수직적 마이크로프론트엔드(VMFE)의 정의와 이점 * **경로 기반의 독립성**: `/blog`, `/docs`, `/dash`와 같은 URL 경로별로 개별 Worker를 할당하며, 각 경로는 프레임워크, 라이브러리, CI/CD 파이프라인을 포함한 전체 스택을 독립적으로 소유합니다. * **기술 선택의 유연성**: 마케팅 페이지에는 Astro를 사용하고 대시보드에는 React를 사용하는 등, 서비스의 특성에 가장 적합한 도구를 팀별로 자유롭게 선택할 수 있습니다. * **배포 리스크 감소**: 모놀리식 구조에서 발생하던 '한 팀의 오류로 인한 전체 배포 중단' 문제를 해결하며, 특정 기능의 업데이트나 롤백이 다른 서비스에 영향을 주지 않습니다. ### URL 기반의 정교한 라우팅 구조 * **세분화된 관리**: 단순한 최상위 경로뿐만 아니라 `/dash/product-a`와 `/dash/product-b`처럼 세부 경로별로 다른 Worker를 매핑하여 대규모 애플리케이션 내의 개별 제품군을 독립적으로 관리할 수 있습니다. * **코드 공유 제로**: 각 경로는 서로 코드를 공유하지 않는 완전히 독립된 프로젝트로 운영되어 프로젝트 간의 의존성을 완벽히 차단합니다. * **실제 적용 사례**: Cloudflare는 이미 자사 대시보드에 이 전략을 적용하고 있으며, 사용자가 대시보드에서 ZeroTrust 제품으로 이동할 때 실제로는 별개의 프로젝트로 라우팅되도록 구현했습니다. ### 사용자 경험을 통합하는 기술적 전략 * **CSS View Transitions**: 서로 다른 Worker 간의 이동 시 발생하는 브라우저의 흰색 공백(interstitial loading state)을 방지하고, 내비게이션 바와 같은 공통 요소를 화면에 유지시켜 SPA(Single Page Application)와 같은 부드러운 전환 효과를 제공합니다. * **Speculation Rules API**: 사용자가 다음에 방문할 가능성이 높은 경로를 브라우저가 미리 사전 페치(prefetch)하거나 사전 렌더링하도록 설정하여, 멀티 페이지 아키텍처임에도 불구하고 즉각적인 페이지 로딩 속도를 구현합니다. * **시각적 일관성**: CSS의 `view-transition-name` 등을 활용하여 기술적인 구현 세부 사항(여러 개의 Worker 사용)을 사용자에게 노출하지 않고 단일한 애플리케이션 경험을 유지합니다. 독립적인 개발 속도와 일관된 사용자 경험이라는 두 마리 토끼를 잡고 싶은 성장하는 조직에게 이 VMFE 아키텍처는 매우 강력한 솔루션입니다. Cloudflare가 제공하는 새로운 Worker 템플릿과 최신 브라우저 API(View Transitions, Speculation Rules)를 결합하면, 기술적 복잡성을 관리하면서도 고성능의 웹 애플리케이션을 구축할 수 있습니다.

ReactCloudflare Workersastromicrofrontends+3

gitlab·2026년 1월 14일원문

플로우 이해하기: 멀티 (새 탭에서 열림)

GitLab Duo Agent Platform의 '플로우(Flows)'는 여러 전문 AI 에이전트가 협업하여 복잡한 개발 과업을 자율적으로 수행하는 멀티 에이전트 워크플로우 시스템입니다. 사용자와 대화하며 협력하는 개별 에이전트와 달리, 플로우는 특정 이벤트에 의해 트리거되어 백그라운드에서 분석부터 실제 구현 및 결과 도출까지 엔드 투 엔드(end-to-end) 작업을 독립적으로 처리합니다. 이를 통해 개발자는 반복적인 파이프라인 관리나 단순 구현 업무에서 벗어나 보다 고차원적인 설계에 집중할 수 있는 자율형 자동화 환경을 구축할 수 있습니다. ### 에이전트와 플로우의 차이 및 주요 특징 * **자율성:** 에이전트가 사용자와 상호작용하며 실시간으로 도움을 준다면, 플로우는 사용자를 대신해 독립적으로 워크플로우를 완수하는 데 초점을 맞춥니다. * **플랫폼 통합:** 별도의 외부 인프라 구축 없이 GitLab 플랫폼의 컴퓨팅 자원에서 직접 실행되는 내장형 시스템입니다. * **비동기 및 이벤트 기반:** 멘션(@), 담당자 할당, 리뷰어 지정 등의 이벤트로 트리거되며, 작업이 진행되는 동안 개발자는 다른 업무를 중단 없이 수행할 수 있습니다. * **기본 및 커스텀 옵션:** GitLab이 직접 관리하는 생산 준비 완료 단계의 '기본 플로우'와 팀의 특정 요구에 맞춰 구성하는 '커스텀 플로우'를 모두 지원합니다. ### 커스텀 플로우의 활용과 트리거 방식 * **팀 맞춤형 자동화:** 조직 고유의 보안 정책 검토, 특정 기술 스택에 맞춘 코드 리뷰, API 문서 자동 생성 등 범용 AI가 해결하기 어려운 구체적인 워크플로우를 자동화할 수 있습니다. * **다양한 실행 경로:** 이슈나 머지 리퀘스트(MR)에서 `@flow-name`으로 멘션하거나, `/assign @flow-name` 명령어를 통해 담당자 또는 리뷰어로 지정하는 즉시 실행됩니다. * **실제 활용 사례:** 핀테크 기업의 경우 컴플라이언스 플로우를 구축하여, 모든 MR에 대해 PCI-DSS 위반 여부를 스캔하고 보안 코딩 표준 준수 여부를 확인한 뒤 자동으로 보고서를 게시하도록 설정할 수 있습니다. ### YAML 기반의 플로우 설계 및 구성 요소 * **구조적 정의:** 플로우는 YAML 구성을 통해 정의되며 구성 요소(Components), 프롬프트(Prompts), 라우터(Routers), 도구 모음(Toolsets)으로 이루어집니다. * **에이전트 컴포넌트:** 워크플로우의 각 단계를 담당할 에이전트의 유형과 동작 방식을 정의하며, 특정 AI 모델의 행동 지침을 프롬프트 ID로 연결합니다. * **강력한 도구 연결:** `get_issue`, `create_commit`, `create_merge_request`와 같은 GitLab API 도구를 에이전트에게 부여하여 실제로 코드를 수정하고 저장소에 반영할 수 있는 권한을 제공합니다. * **전문성 주입:** 프롬프트 템플릿 내에 도메인 지식(예: 여행 예약 시스템의 특수성)과 코드 표준을 명시하여 AI가 조직의 맥락에 맞는 최적의 결과물을 내놓도록 정교하게 제어합니다. 단순한 코드 생성을 넘어 복잡한 프로세스의 완전 자동화를 목표로 한다면, 팀 내에서 가장 반복적으로 발생하는 작업부터 커스텀 플로우로 전환해 보길 권장합니다. 처음에는 GitLab에서 제공하는 기본 플로우로 기능을 탐색한 뒤, 점진적으로 팀의 정책이 반영된 YAML 정의 플로우를 확장해 나가는 것이 생산성 향상에 가장 효과적입니다.

ReactAI 에이전트gitlabTypeScript+4

toss·2026년 1월 7일원문

디자인 시스템 다시 생각해보기 (새 탭에서 열림)

디자인 시스템은 성장에 따라 경직되기 마련이며, 시스템이 제품 팀의 변화하는 요구사항을 제때 수용하지 못할 경우 팀은 시스템을 우회하거나 파편화된 코드를 생성하게 됩니다. 토스의 디자인 시스템(TDS)은 디자인 시스템을 통제 수단이 아닌 '하나의 제품'으로 정의하고, 수요자의 니즈에 따라 유연하게 대응할 수 있는 설계 구조를 지향합니다. 이를 위해 단순함과 유연함을 동시에 잡을 수 있는 하이브리드 API 전략을 도입하여 일관성과 생산성을 모두 확보하는 해결책을 제시합니다. ### 시스템의 경직성과 파편화 문제 * 조직이 커지고 제품이 다양해지면 기존 시스템의 제약 내에서 해결할 수 없는 UI 요구사항이 빈번하게 발생합니다. * 제품 팀은 빠른 해결을 위해 피그마 컴포넌트를 해제(detach)하거나 라이브러리 코드를 복제(fork)하여 로컬에서 수정해 사용하게 됩니다. * 이러한 우회 방식은 시스템 업데이트와의 연결을 끊어버려 UI 불일치를 초래하고, 장기적으로 디자인 시스템의 핵심 가치를 무너뜨립니다. * 결국 디자인 시스템이 팀의 속도를 늦추는 장애물이 되지 않으려면, 강력한 규칙보다 '우회할 이유를 줄이는 유연한 설계'가 필요합니다. ### 확장성을 고려한 컴포넌트 API 패턴 비교 * **Flat 패턴**: 내부 구조를 숨기고 모든 변형을 props로 처리하는 방식입니다. 사용이 직관적이고 간결하지만, 예외적인 요구사항이 늘어날수록 props가 기하급수적으로 증가하여 유지보수가 어려워집니다. * **Compound 패턴**: 하위 컴포넌트(Header, Body, Footer 등)를 제공하여 사용자가 직접 조합하는 방식입니다. 시스템이 예측하지 못한 레이아웃도 유연하게 구현할 수 있으나, 코드량이 늘어나고 구조에 대한 학습 비용이 발생한다는 단점이 있습니다. * 두 패턴은 상충하는 장단점을 가지고 있으므로, 단순히 하나의 패턴을 강요하는 것은 사용자의 이탈을 막기에 부족합니다. ### TDS의 하이브리드 전략과 Primitive 레이어 * TDS는 단순하고 빈번한 케이스를 위한 **Flat API**와 복잡한 커스텀을 위한 **Compound API**를 동시에 제공합니다. * 사용자는 별도의 커스텀이 필요 없을 때는 간결한 Flat 형식을 선택하고, 세밀한 제어가 필요할 때는 Compound 형식을 선택하여 시스템 내부에서 문제를 해결할 수 있습니다. * 디자인 시스템 팀은 관리 효율을 위해 **Primitive(기초 단위)** 레이어를 먼저 구축합니다. * 내부적으로는 동일한 Primitive 컴포넌트를 공유하면서 외부로 드러나는 API만 두 가지 형태로 노출함으로써, 유지보수 부담을 최소화하면서도 사용자 경험을 극대화합니다. 디자인 시스템은 팀을 가두는 울타리가 아니라 안전하게 안내하는 가드레일이 되어야 합니다. 중앙에서 모든 것을 통제하려 하기보다, 규칙에서 벗어난 예외 상황까지 시스템 안에서 지원할 수 있는 유연한 설계를 갖출 때 진정한 일관성을 유지할 수 있습니다.

React디자인 시스템scalabilitycomponent-api-design+3

toss·2025년 12월 23일원문

세금 환급 자동화 : AI-driven UI 테스트 자동화 일지 (새 탭에서 열림)

토스인컴의 복잡한 세금 환급 서비스 QA를 위해 1명의 매니저가 AI를 팀원으로 활용하여 4~5명 규모의 자동화 성과를 낸 과정을 다룹니다. AI 에이전트에게 코드 작성과 설계를 맡기고 사람은 문제 정의와 검증에 집중함으로써, 5개월 만에 35개의 고난도 E2E 테스트 시나리오를 성공적으로 구축하고 운영화했습니다. 이 실험은 기술적 난도가 높은 환경에서도 AI와의 협업을 통해 자동화 효율을 극대화할 수 있음을 입증했습니다. **AI 자동화 도입 배경과 도구 구성** * 복잡한 환급 플로우(15~20단계)와 빈번한 UI/정책 변경, 외부 연동 시스템의 불안정성 때문에 전통적인 수동 자동화 방식으로는 대응이 불가능했습니다. * 메인 개발자인 Claude Sonnet 4.5를 비롯해 Cursor(IDE 페어 프로그래밍), Codex(코드 분석) 등 각기 다른 강점을 가진 AI 도구들을 조합하여 사용했습니다. * AI를 SDET 에이전트(설계), 문서화 전문가(기록), Git 마스터(형상 관리)라는 세 가지 페르소나로 분리하여 역할 분담을 명확히 했습니다. **기술적 문제 해결과 아키텍처 고도화** * **Page Object Model(POM) 도입:** 중복 셀렉터 문제를 해결하고 유지보수성을 높이기 위해 AI와 협업하여 모든 페이지 요소를 객체화하는 POM 구조를 설계했습니다. * **React 타이밍 이슈 해결:** 요소가 화면에는 보이지만 이벤트 핸들러가 바인딩되지 않아 발생하는 클릭 실패를 해결하기 위해, UI 안정화와 상호작용 준비 상태를 분리해 감지하는 'Interaction Readiness' 전략을 구현했습니다. * **Fallback 클릭 로직:** 표준 클릭 실패 시 키보드 엔터 입력, 자바스크립트 직접 클릭 순으로 시도하는 안전한 클릭 함수를 만들어 테스트의 견고함을 높였습니다. * **동적 약관 처리:** 서비스별로 상이하고 복잡한 약관 동의 플로우를 AI가 자동으로 감지하고 처리하도록 설계하여, 약관이 변경되어도 테스트가 중단되지 않는 구조를 만들었습니다. **운영 효율화를 위한 협업 시스템 구축** * **문서화 및 일지 자동 생성:** 매일 커밋 기록을 기반으로 AI가 회고 일지와 가이드 문서를 작성하게 하여, 수십 분이 걸리던 기록 업무를 1~2분 내외의 검토 수준으로 단축했습니다. * **메신저 기반 리포팅 루프:** 테스트 결과, 실패 지점 스크린샷, 오류 로그(EventID 등)를 사내 메신저에 자동으로 연동하여 개발팀과의 빠른 논의가 가능하도록 환경을 조성했습니다. * **테스트 격리 및 리팩토링:** 수천 줄의 단일 파일을 분리하고 테스트 데이터(userNo) 충돌 방지 로직을 도입하여 자동화 품질을 관리 가능한 수준으로 끌어올렸습니다. 단순히 AI에게 코드를 짜게 하는 수준을 넘어, 아키텍처 설계와 운영 프로세스 전반을 AI와 함께 고민하는 'AI-First' 접근 방식은 리소스가 제한된 환경에서 QA 품질을 혁신적으로 높일 수 있는 실질적인 해법이 됩니다. 6개월간의 여정은 AI를 도구가 아닌 실제 팀원으로 대우할 때 자동화의 본질인 '안정적인 반복 실행'을 달성할 수 있음을 보여줍니다.

ReactAIAI 에이전트claude+5

figma·2025년 10월 5일·3분 읽기큐레이션 요약

ChatGPT 브레인스토밍을

ChatGPT의 새로운 Figma 앱은 대화 중 나온 아이디어와 첨부 파일을 분석해 FigJam 다이어그램으로 변환해준다. 손그림, PDF, PRD, 기술 문서 등을 바탕으로 플로차트·시퀀스 다이어그램·상태 다이어그램·간트 차트 등을 만들고 수정할 수 있어, 개인 브레인스토밍을 팀 협업용 산출물로 빠르게 발전시키는 것이 핵심이다. 이 기능은 Figma MCP 서버를 기반으로 하며, 글 작성 시점에는 EU 외 지역의 로그인한 ChatGPT 사용자에게 제공된다. ## ChatGPT 브레인스토밍을 FigJam으로 변환 - ChatGPT 대화 내용을 바탕으로 적절한 FigJam 다이어그램을 추천하고 자동 생성한다. - 사용자는 프롬프트에 Figma 앱을 직접 언급할 수 있다. - 예: “Figma, 이 스케치로 다이어그램을 만들어줘.” - 사진, 손그림, PDF 등의 파일을 업로드해 다이어그램 생성에 참고시킬 수 있다. - 현재 지원되는 다이어그램 유형은 다음과 같다. - 텍스트 기반 플로차트 - 시퀀스 다이어그램 - 상태 다이어그램 - 간트 차트 - 생성된 결과는 FigJam에서 팀원들과 공유하고 반복적으로 수정할 수 있다. ## 디자인 아이디어를 빠르게 발전시키기 - 냅킨이나 화이트보드에 그린 임시 스케치를 공유 가능한 FigJam 파일로 변환한다. - ChatGPT에 다이어그램 수정, 주제 확장, 다른 시각화 방식 제안을 요청할 수 있다. - 복잡한 문서와 맥락을 업로드하면 ChatGPT가 첫 번째 다이어그램 초안을 작성한다. - 디자이너는 아이디어를 손쉽게 디지털 산출물로 바꾼 뒤 팀 리뷰와 협업을 진행할 수 있다. ## 기술 아키텍처와 시스템 설계 시각화 - 기술 문서와 화면 캡처를 업로드해 소프트웨어 아키텍처 다이어그램을 생성하거나 갱신할 수 있다. - 기술 블로그와 사례 연구를 바탕으로 여러 기술 접근법을 비교하는 구조도를 만들 수 있다. - 웹페이지 스크린샷을 분석해 관련 React 컴포넌트 구조를 다이어그램으로 표현할 수도 있다. - 분산된 코드와 문서, 팀별로 나뉜 지식을 하나의 시각적 모델로 통합해 시스템 설계 논의와 기술 의사결정을 돕는다. - 생성된 다이어그램을 바탕으로 엔지니어들이 실시간으로 협업할 수 있다. ## 제품 기획과 사용자 흐름 정리 - 권한 관리처럼 여러 선택지가 있는 문제를 옵션별 다이어그램으로 만들어 장단점을 비교한다. - PRD를 업로드해 사용자 여정이나 기능 플로차트를 생성한다. - 제품·디자인·엔지니어링 요구사항을 입력해 출시 일정을 간트 차트로 구성한다. - ChatGPT에서 개인적으로 여러 아이디어를 탐색한 뒤 FigJam에서 팀과 함께 우선순위와 실행 계획을 조율할 수 있다. ## Figma MCP 서버 기반 통합 - 이 기능은 Figma MCP 서버를 기반으로 동작한다. - MCP 서버는 원격 접근을 지원하며, 사용자가 작업 중인 맥락을 Figma 작업 환경으로 연결한다. - 따라서 ChatGPT의 분석 능력과 FigJam의 멀티플레이어 협업 기능을 결합할 수 있다. - 글 작성 시점에는 로그인한 ChatGPT 사용자 중 EU 외 지역 사용자에게 제공되며, 향후 더 많은 기능과 다이어그램 유형이 추가될 예정이다. 실무에서는 먼저 ChatGPT에 원문 자료나 스케치를 제공해 초안을 만들고, FigJam에서 사실관계·구조·표현을 검토한 뒤 팀 협업 자료로 다듬는 방식이 가장 효과적이다. AI가 만든 다이어그램은 초안이므로 기술적 정확성과 일정의 현실성은 담당자가 반드시 확인해야 한다.

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

ReactFigmafigjamchatgpt+4

figma·2025년 6월 24일·3분 읽기큐레이션 요약

캔버스, 코드를 만나다

Figma의 코드 레이어는 디자인 캔버스와 실제 코드를 하나의 작업 공간에서 결합하려는 시도다. React 기반 코드를 일반 Figma 레이어처럼 이동·복제·리사이즈하고, AI 또는 내장 IDE로 편집할 수 있게 해 디자인의 자유로운 탐색성과 코드의 강력한 기능을 함께 제공한다. 이를 위해 Figma는 캔버스 모델, 웹 기반 코드 편집기, 디자이너와 개발자의 협업 방식을 통합하는 하이브리드 접근법을 택했다. ## 디자인 캔버스와 코드의 충돌 - Figma 캔버스는 객체를 자유롭게 배치하고 수정하는 2D 공간이다. - 반면 코드는 디렉터리와 파일로 구성된 계층적 파일 시스템을 전제로 한다. - 이 차이 때문에 다음과 같은 문제가 발생한다. - 캔버스에서 코드 레이어를 복제하면 새 인스턴스를 만들 것인지, 코드의 분기본을 만들 것인지 결정해야 한다. - 코드의 원본이 캔버스인지 파일 시스템인지 명확히 해야 한다. - 시각적 레이어와 실제 코드 파일의 위치를 어떻게 연결할지 정해야 한다. - Figma는 코드의 구조를 캔버스에 그대로 강요하기보다, 코드가 Figma의 공간적 작업 방식에 맞도록 설계했다. ## 코드를 새로운 캔버스 기본 요소로 구현 - 코드 레이어는 일반 레이어처럼 다음 작업을 지원한다. - 자유로운 이동과 크기 조절 - 부모 레이어 변경 - 오토 레이아웃 스택에 배치 - 다른 레이어와 동일한 방식의 중첩 - 코드 레이어를 복제하면 별도의 코드 포크가 생성된다. - 따라서 Git 브랜치를 따로 만들지 않고도 `Option` 키를 누른 채 드래그해 여러 코드 버전을 나란히 비교할 수 있다. - 이러한 방식은 디자인에서 흔한 빠른 복제와 실험, 버전 비교를 코드에도 적용한다. ## React와 Figma 컴포넌트의 결합 - Figma는 컴포넌트 모델과 React의 컴포넌트 모델이 유사하다는 점에서 React를 선택했다. - 두 시스템 모두 재사용 가능한 구성 요소를 조합해 화면과 애플리케이션을 만든다. - React의 props는 Figma의 컴포넌트 속성과 연결된다. - 개발자가 코드에서 속성을 정의하면 디자이너는 Figma 화면에서 다음과 같은 컨트롤로 값을 조정할 수 있다. - 토글 - 슬라이더 - 드롭다운 - 결과적으로 코드 컴포넌트도 일반 Figma 컴포넌트처럼 시각적으로 재사용하고 변형할 수 있다. ## AI와 직접 편집을 함께 지원하는 IDE - 코드 레이어는 AI만으로 생성하고 수정할 수 있지만, 사용자가 직접 코드를 편집할 수 있는 환경도 필요했다. - Figma는 웹 기반의 내장 IDE를 만들기 위해 CodeMirror를 핵심 편집 엔진으로 채택했다. - CodeMirror의 확장 구조를 활용해 다음 기능을 제공할 수 있다. - 색상 테마 - 찾기 및 바꾸기 - 줄 번호 - Figma 환경에 맞춘 편집 동작 - 기본 편집기의 실행 취소·다시 실행 동작은 Figma의 자체 멀티플레이어 undo 스택과 통합하기 위해 교체했다. - 이를 통해 코드 편집도 Figma의 다른 작업과 일관된 협업 및 실행 취소 경험을 제공하도록 했다. ## 코드 레이어 설계에서 해결해야 할 세 가지 과제 - Figma는 코드 레이어를 구축하며 다음 문제를 핵심 과제로 삼았다. - 코드 레이어와 컴포넌트를 기존 Figma 생태계에 자연스럽게 통합하기 - 강력하면서도 쉽게 사용할 수 있는 웹 IDE 제공하기 - 디자이너와 개발자가 동시에 작업할 수 있는 멀티플레이어 협업 지원하기 - 전체 방향은 코드의 엄격한 구조를 그대로 가져오는 것이 아니라, Figma의 시각적이고 실험적인 작업 방식을 유지하면서 코드의 표현력을 추가하는 데 있다. 코드 레이어는 디자인 파일 안에 단순히 코드를 삽입한 기능이 아니라, 코드를 Figma의 레이어와 컴포넌트 모델에 맞춰 재구성한 기능이다. 디자인을 한 번의 클릭으로 코드 레이어로 바꾸고, AI나 직접 코딩으로 상호작용을 추가할 수 있으므로 디자이너와 개발자가 같은 캔버스에서 더 빠르게 실험할 수 있다는 점이 핵심이다.

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

Reactmultiplayer-collaborationcode-editorcodemirror+2