AI

331 개의 포스트

figma3분 읽기큐레이션 요약

올바른 방향으로 빠르게 나아가는 방법 | Figma 블로그

AI는 소프트웨어 제작 속도를 크게 높였지만, 빠른 실행이 곧 올바른 제품을 의미하지는 않는다. AI가 만든 결과물을 그대로 받아들이면 기술 부채가 늘고, 평균적인 디자인과 기능에 머물 수 있다. 따라서 좋은 팀은 먼저 무엇을 만들지 충분히 고민하고, 명확한 맥락과 시스템을 제공한 뒤, 자신만의 관점으로 결과물을 다듬어야 한다. ## AI는 실행을 가속하지만 판단을 대신하지 못한다 - AI는 짧은 프롬프트만으로도 완성도 높아 보이는 프로토타입과 코드를 만들어낸다. - 그러나 겉보기의 완성도는 내부 구조, 제약 조건, 시스템 동작 방식까지 올바르다는 뜻이 아니다. - 과거에는 결과물의 세련됨 뒤에 전문가의 의사결정과 트레이드오프가 있었지만, 이제는 AI가 그 빈틈을 임의로 채울 수 있다. - **인지적 항복(cognitive surrender)**은 AI의 출력을 검토 없이 자신의 판단처럼 받아들이는 현상이다. - 첫 번째 결과물이 그럴듯하다는 이유로 바로 출시하지 말고, 문제의 본질과 실제로 만들 가치가 있는 것을 먼저 정의해야 한다. 글에서는 이를 **고려의 의무(consideration imperative)**로 표현한다. ## 맥락과 의도를 먼저 제공해야 한다 - 에이전틱 엔지니어링에서는 개발자의 역할이 코드를 직접 작성하는 것에서 **의도를 명확히 표현하고 검증하는 것**으로 이동한다. - Google의 관련 백서는 다음 요소를 중요한 기반으로 제시한다. - **결정론적 계층**: 테스트, 타입 검사, 검증처럼 매번 동일하게 실행되며 AI의 오류를 잡는 장치 - **고신호 맥락**: 명세, 문서화된 컴포넌트, 설계 원칙 등 에이전트가 의도를 정확히 이해하도록 돕는 정보 - **명확한 인터페이스**: 시스템 각 부분이 어떻게 연결되는지 에이전트가 추측하지 않도록 정의한 계약 - 디자인에서 코드로 전환할 때도 에이전트가 실제 프로덕션 컴포넌트의 구조를 모르면 픽셀을 보고 임의로 재구성할 가능성이 높다. - Figma MCP의 Code Connect처럼 실제 컴포넌트의 코드, props, variants를 제공하면 에이전트가 기존 시스템에 맞는 결과를 만들 수 있다. - 강력한 디자인 시스템은 결정 사항을 재사용 가능한 어휘와 가드레일로 codify해 결과물의 일관성을 높이고 코드와 기술 부채를 줄인다. - 초기에는 명세와 시스템을 준비하는 데 더 많은 시간이 들지만, 장기적으로 유지보수 비용을 낮춘다. ## “괜찮은 결과”는 쉽게 평균이 된다 - AI 모델은 방대한 기존 데이터를 학습했기 때문에 이미 널리 사용된 패턴과 스타일, 즉 **분포 안의 평균적인 결과**를 생성하는 경향이 있다. - 예를 들면 다음과 같은 결과가 반복될 수 있다. - 로고: 단순한 기하학적 형태와 그라디언트 - 발표 자료: 흔한 산세리프 글꼴과 익숙한 레이아웃 - React 컴포넌트: 둥근 모서리의 전형적인 카드 UI - 이런 결과는 틀리지는 않지만 차별성이 부족하다. - AI가 만든 “충분히 좋은” 결과를 반복해서 받아들이면 사용자의 판단 기준이 좁아지고, “무엇이어야 하는가?”보다 “덜 나쁜 선택은 무엇인가?”를 고르게 된다. - AI의 품질이 향상될수록 개인이 과거보다 나은 결과를 만들 수 있지만, 동시에 다른 AI 생성물과 비슷해질 위험도 커진다. ## 제품의 관점은 사람이 결정해야 한다 - AI는 실행과 변형을 빠르게 수행할 수 있지만, 제품의 목적과 차별화된 방향까지 자동으로 결정하게 두어서는 안 된다. - 명확한 의도와 평가 기준이 없으면 모델이 기본값과 평균적인 패턴을 대신 선택한다. - 팀은 AI가 제시한 결과를 출발점으로 활용하되, 왜 이 기능과 디자인이 필요한지, 누구를 위한 것인지, 무엇이 달라야 하는지를 직접 판단해야 한다. - 결국 속도의 핵심은 첫 결과물을 빨리 내는 것이 아니라, 명확한 맥락과 검증 장치를 통해 **올바른 방향으로 빠르게 반복하는 것**이다. AI를 활용할 때는 프롬프트 작성보다 먼저 목표, 제약 조건, 성공 기준을 문서화하는 것이 좋다. 테스트·타입 검사·디자인 시스템·명확한 인터페이스를 갖추고, AI 결과물을 반드시 사람의 관점과 제품 기준으로 검토해야 평균적인 결과와 기술 부채를 피할 수 있다.

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

AI 경제 지도 그리기

AI 기업은 빠르게 해외 시장을 개척하고 있지만, 단순히 여러 국가에서 판매를 시작하는 것만으로는 지속적인 매출 성장을 보장하기 어렵다. Stripe 거래 데이터에 따르면 인도·멕시코·폴란드·UAE처럼 전체 결제 규모 대비 AI 지출 비중이 높은 시장과, 멕시코·한국처럼 성장률이 높은 시장이 새로운 기회로 부상하고 있다. 장기적인 해외 매출을 확보하려면 현지 결제수단, 통화, 언어 등을 제품과 결제 경험에 반영하는 현지화가 핵심이다. ## AI 지출 비중이 높은 시장이 새로운 진출 후보로 부상 - AI 지출 총액이 가장 큰 10개 시장은 미국 등 GDP와 온라인 소비 규모가 큰 국가에 집중됐다. - 단순한 시장 규모 대신, 각국의 전체 Stripe 결제액 중 AI 지출이 차지하는 비중을 비교하면 색다른 유망 시장이 드러났다. - 인도, 멕시코, 폴란드, 아랍에미리트는 전체 온라인 지출 대비 AI 지출 비중이 높은 시장으로 나타났다. - 브라질, 일본, 한국은 AI 지출 총액과 전체 결제에서 차지하는 비중이 모두 높은 시장이었다. - 따라서 시장 규모가 큰 선진국뿐 아니라, AI 수요가 전체 소비에 비해 빠르게 커지는 국가도 우선 검토할 필요가 있다. ## AI 시장은 규모와 관계없이 빠르게 성장 - 2024년까지 AI 지출이 2,000만 달러를 넘은 35개 시장을 분석한 결과, AI 지출의 전년 대비 성장률 중앙값은 약 100%였다. - 미국은 전년 대비 91%, 호주는 61% 성장했다. 대형 시장의 성장률이 중앙값보다 낮더라도 실제 증가액은 상당히 컸다. - 캐나다, 독일, 영국은 이미 큰 시장임에도 높은 성장세를 유지했다. - 한국은 다음 세 가지 조건을 동시에 갖춘 시장으로 평가됐다. - 큰 AI 지출 규모 - 134%의 높은 전년 대비 성장률 - 전체 Stripe 결제액 대비 높은 AI 지출 비중 - 멕시코는 AI 지출이 264% 증가해 가장 두드러진 성장 시장이었다. - 미국과의 지리적 인접성 - 미국 기업의 투자 - 기존 주요 시장보다 낮은 경쟁 밀도 - 전체 소비 대비 높은 AI 지출 비중 - 이런 요인 때문에 멕시코는 초기 거점을 확보하기 좋은 확장 후보로 제시됐다. ## 글로벌 출시만으로는 지속적인 해외 매출이 어렵다 - AI 기업은 제품이 온라인으로 제공되기 때문에 짧은 기간 안에 전 세계 고객을 확보할 수 있다. - 예를 들어 AI 에이전트 플랫폼 Manus는 2025년 초 큰 관심을 받은 뒤 한 달 만에 200개가 넘는 국가와 지역에서 결제를 지원했고, 4개월 만에 9,000만 달러의 연환산 매출 규모에 도달했다. - 그러나 글로벌 판매 가능 국가를 늘리는 것과 실제 해외 매출을 안정적으로 확보하는 것은 별개의 문제다. - Stripe의 상위 100개 AI 기업은 평균적으로 자국 외 시장에서 전체 매출의 48%를 창출하고 있으며, 이를 위해 현지 시장에 맞춘 제품과 결제 경험이 필요하다. ## 현지 결제수단이 전환율과 매출을 높인다 - 가장 빠르게 성장하는 AI 기업들은 일반 AI 기업군보다 평균 2배 많은 현지 결제수단(Local Payment Methods, LPM)을 사용한다. - 관련 분석에 따르면 현지에서 익숙한 결제수단을 제공하면: - 평균 전환율이 7.4% 증가 - 평균 매출이 12% 증가 - AI 디자인 플랫폼 Gamma는 인도의 실시간 결제 시스템인 UPI를 지원한 뒤 인도 내 매출이 22% 증가했다. - Gamma는 현재 미국 외 시장에서 전체 매출의 절반 이상을 얻고 있다. - 국가별로 선호 결제수단이 다르므로, 시장 진출 시 카드 결제만 제공하기보다 현지 계좌이체·전자지갑·실시간 결제망 등을 함께 검토해야 한다. ## 현지 통화와 가격 정책은 구독 매출의 장기 가치를 높인다 - 현지 통화로 가격을 표시하고 결제하게 하면 최초 구매 전환뿐 아니라 구독 고객의 생애가치(LTV)도 개선될 수 있다. - Stripe Adaptive Pricing을 사용하는 구독 기업은 평균적으로: - 최초 전환율 4.7% 증가 - 구독 생애가치 5.4% 증가 - AI 영상 기업 Runway는 Adaptive Pricing 도입 후 구독당 생애가치가 최대 17.7% 증가했다. - 따라서 현지화는 번역에만 국한되지 않고 가격 표시, 환율 적용, 세금·결제 방식, 구독 청구 경험까지 포함해야 한다. ## 실용적인 확장 전략 - 시장 규모만 보지 말고 AI 지출 성장률과 전체 소비 대비 AI 지출 비중을 함께 분석한다. - 초기에는 여러 국가에서 빠르게 판매를 시작하되, 성과가 확인된 시장에는 현지 마케팅과 번역 투자를 확대한다. - 국가별 주요 결제수단과 현지 통화를 지원해 결제 장벽을 낮춘다. - 해외 매출 비중이 커진 뒤에는 해당 시장에 맞는 가격·구독·고객지원 체계를 구축한다. - 글로벌 확장의 다음 단계는 더 많은 국가에 진출하는 것이 아니라, 이미 진출한 시장에 현지 기반을 구축하는 것이다.

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

토스의 속도와 품질, 상용 도구로 충분한가 — 토션(Tossion)

토션(Tossion)은 흩어진 자동화·수동 테스트 결과와 테스트 케이스를 하나의 플랫폼에서 연결하고, QA 조직이 필요한 기능을 직접 빠르게 확장하기 위해 만든 테스트 관리 플랫폼입니다. 테스트 런에는 당시의 테스트 케이스와 판정 근거를 스냅샷으로 보존해 과거 결과의 신뢰성을 확보하고, AI·PR 분석·실기기 자동화까지 하나의 흐름으로 통합했습니다. 토스는 상용 TCM의 기능을 사용하는 데 그치지 않고, 빠른 개발 속도와 품질 기준에 맞춰 플랫폼 자체를 계속 진화시키는 것을 목표로 합니다. ## 흩어진 테스트 정보를 하나의 기록으로 통합 - 기존에는 자동화 테스트 결과, 매뉴얼 테스트 결과, 테스트 케이스와 판단 근거가 서로 다른 곳에 흩어져 과거 결과를 확인하는 데 시간이 걸렸습니다. - 토션의 기본 구조는 **프로젝트 → 스위트 → 섹션 → 테스트 케이스**이며, 섹션은 트리 구조로 관리됩니다. - 테스트 케이스는 제품 변화에 따라 수정·삭제되지만, 테스트 런은 당시 검증 내용을 보존하기 위해 별도로 축적됩니다. - 테스트 런을 생성할 때 테스트 케이스를 단순 참조하지 않고 다음 정보를 복사해 독립적인 행으로 저장합니다. - Assignee - Test Step - Description - 테스트 런의 각 행에는 상태 변경 이력이 쌓이며, 누가 언제 어떤 Version에서 어떤 판단을 했는지 확인할 수 있습니다. - 섹션을 직접 선택한 테스트 케이스에는 Type·Platform 등의 필터를 적용하지 않습니다. 명시적인 선택이 자동 조건보다 우선하기 때문입니다. ## 테스트 런의 스냅샷과 변경 이력 - 테스트 런은 **Active → Completed → Closed** 상태로 진행됩니다. - Closed 시점에 테스트 케이스, 코멘트, 자동화 결과를 스냅샷으로 저장합니다. - 이후 원본 테스트 케이스가 수정되거나 삭제되어도 종료된 테스트 런의 화면과 리포트는 변하지 않습니다. - 이를 통해 “지난달에는 무엇으로 검증했는가”라는 질문에 당시 상태 그대로 답할 수 있습니다. ## 빠른 피드백을 반영하는 협업 기능 - Assignee별로 전체 테스트 수와 남은 테스트 수를 보여 주는 진척도 차트를 제공합니다. - Status, Type, Assignee, Version, Platform, RNR, History 등 실제로 필요한 필드만 추가·유지합니다. - 여러 사용자가 같은 테스트 런을 동시에 사용할 수 있도록 다음 기능을 제공합니다. - 현재 접속 중인 사용자 아바타 표시 - 사용자별 색상 구분 - 편집 중인 테스트 케이스와 Description 잠금 - 창을 닫거나 연결이 끊기면 잠금 자동 해제 - 다른 사용자의 Status 변경을 새로고침 없이 반영 - 핵심은 기능의 규모보다 사용자 요청을 개발·배포·활용하는 시간이 짧다는 점입니다. ## 상용 TCM 대신 직접 만든 플랫폼 - 토스의 빠른 개발 속도에서는 품질 검증도 같은 속도로 변화해야 하며, 품질이 속도의 희생양이 되어서는 안 됩니다. - 상용 도구는 제공 업체가 정한 기능과 로드맵 안에서만 사용할 수 있습니다. - 토스가 필요로 한 것은 정해진 기능을 제공하는 도구가 아니라, 새로운 요구를 즉시 추가할 수 있는 플랫폼이었습니다. - 이를 기반으로 다음 기능을 직접 추가했습니다. - 릴리즈 PR 분석 - AI 기반 테스트 케이스 생성 - 실기기 회귀 테스트 실행 - 자동화 결과를 수동 테스트 케이스별로 기록 ## 릴리즈 PR 분석과 QA 범위 결정 - RC 빌드나 릴리즈 마일스톤에 포함된 PR을 모두 수집해 QA 라벨이 있는 PR과 없는 PR로 나누어 분석합니다. - QA 라벨이 있는 PR은 검증 관점을 정리하고, 라벨이 없는 PR은 정말 QA 검증이 필요 없는지 다시 확인합니다. - 분석 목적은 기능 요약이 아니라 “이번 릴리즈에서 반드시 확인해야 할 항목”을 찾는 것입니다. - QA 서버의 Agent가 토션에 등록된 작업을 주기적으로 확인하고, 작업을 받으면 서버에 로그인된 AI를 실행합니다. - 수백 개의 PR을 한 번에 처리하지 않고 여러 묶음으로 나누어 병렬 분석합니다. - AI 결과는 다음과 같은 규칙으로 검증합니다. - 화면명이나 구체적인 조건이 없는 모호한 문장 - PR 제목을 그대로 옮긴 요약 - 함수명이 그대로 남은 설명 - 재현 단계·기대 결과·실패 증상·판단 근거가 빠진 테스트 케이스 - 부적합한 결과는 AI가 다시 분석합니다. - 병합된 PR 수와 분석 결과 수를 대조해 누락된 PR이 있으면 해당 항목만 재처리합니다. - 과거 장애가 발생한 파일 목록과 이번 PR의 변경 파일을 비교해 위험도를 조정합니다. - 결과는 묶음 단위로 토션에 저장해 중단 시에도 완료된 분석을 보존하고, 재실행할 때 이미 처리한 PR은 건너뜁니다. - 최종적으로 추려진 항목은 Sprint 테스트 런의 범위와 검증 근거가 됩니다. ## AI 기반 테스트 케이스 생성 - 기능 개발 속도를 사람이 따라가기 어렵기 때문에 AI가 테스트 케이스를 생성해 토션에 등록합니다. - AI는 “자산 > 계좌 연결 > 은행 선택”처럼 경로를 출력하고, 토션이 이를 실제 섹션 트리로 변환합니다. - 기존 섹션이 있으면 재사용하고, 없으면 중간 단계를 포함해 새로 생성합니다. - 결과의 신뢰성을 확보하기 위해 세 겹의 검증을 적용합니다. 1. AI가 누락된 분기·에러 상황·경계값을 스스로 재검토 2. 표기 규칙, 테스트 케이스 번호, 화면 누락, 요구사항 반영 여부를 스크립트로 검증 3. 별도의 AI가 테스트 계획을 작성해 범위와 위험 요소, 적용할 테스트 기법을 정의 - 테스트 계획과 실제 테스트 케이스를 비교해 다음을 확인합니다. - 계획에는 있지만 테스트 케이스에 없는 항목은 누락 - 테스트 케이스에는 있지만 계획에 없는 항목은 범위 이탈 - 화면 중심으로만 테스트하면 상태 전이처럼 화면에 드러나지 않는 테스트 축을 놓칠 수 있습니다. - 따라서 테스트 계획에서 상태 전이, 경계값 등 필요한 테스트 기법을 먼저 지정하고, 테스트 케이스가 이를 모두 포함하는지 확인합니다. - AI의 토션 접근은 화면이 아닌 CLI로 제한하고, 환경 차이로 인한 설치·런타임·경로 문제를 줄이기 위해 단일 실행 파일로 배포합니다. ## 토션에서 실기기 회귀 테스트 실행 - 신규 기능은 사람이 직접 검증하고, 안정화된 테스트 케이스는 회귀 자동화 대상으로 편입합니다. - 토션의 실행 화면에서 다음 항목을 선택해 바로 테스트를 시작합니다. - 대상 기기 - 빌드 - 실행 범위 - 결과를 연결할 테스트 런 - QA 서버의 러너는 Android·iOS 실기기를 관리하며, 스스로 토션에 등록되지만 관리자 승인 전에는 작업을 받지 않습니다. - 러너는 주기적으로 연결된 기기 상태를 보고하므로 실행 가능한 기기를 화면에서 확인할 수 있습니다. - 토션이 발급한 빌드를 설치해 실행함으로써 어떤 빌드에서 나온 결과인지 명확히 유지합니다. - 전체 회귀 또는 특정 섹션만 선택해 실행할 수 있습니다. - 테스트 중에는 시나리오별 통과·실패 여부, 실행 시간, 오류 메시지가 실시간으로 기록됩니다. - 결과는 시나리오가 아니라 **스텝 단위**로 저장됩니다. - 상태 - 소요 시간 - 오류 메시지 - 해당 시점의 스크린샷 - 시나리오 단위 영상 - 실행 결과를 특정 테스트 런에 연결하면 자동화 결과가 수동 테스트 기록의 각 테스트 케이스에 직접 반영됩니다. ## 자동화 결과를 테스트 케이스와 연결 - 별도 자동화 리포트에 “200건 중 3건 실패”라고만 표시하면 어떤 수동 테스트 케이스가 실패했는지 사람이 다시 대조해야 합니다. - 이를 해결하려면 양방향 연동이 필요합니다. - 테스트 케이스를 자동화 코드로 변환 - 자동화 결과를 다시 테스트 케이스별 기록으로 저장 - 토션은 자동화 결과를 테스트 케이스 한 건 단위까지 내려보내 수동 검증 기록과 자동화 실행 결과를 같은 맥락에서 확인할 수 있도록 설계되었습니다. - 제공된 글은 이 자동화 코드 생성 기능의 상세 구현 설명 직전에서 끝납니다. 토션의 핵심은 테스트 관리, AI 분석, 테스트 생성, 실기기 자동화를 각각 분리하지 않고 하나의 테스트 런과 테스트 케이스 흐름으로 연결한 데 있습니다. 유사한 플랫폼을 구축할 때도 먼저 결과의 스냅샷·이력 보존을 설계하고, 이후 AI와 자동화를 기존 기록 구조에 연결하는 방식이 실용적입니다.

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

Figma Make를 통한 시간 절약 측정 | Figma 블로그

Figma 데이터 과학팀은 Figma Make가 디자인 작업을 얼마나 단축하는지 측정하기 위해 100명 대상의 무작위 대조 실험(RCT)을 설계했다. 그 결과 전체 디자인 작업은 20% 빨라지고 16% 쉬워졌으며, 특히 PM은 작업 시간이 23% 단축되고 난이도가 37% 낮아지는 가장 큰 효과를 보였다. 기존 A/B 테스트나 로그 기반 인과 추론만으로는 작업 복잡도와 사용자 경험 같은 교란 요인을 충분히 통제하기 어려워 RCT가 선택됐다. ## AI 시간 절감 측정의 어려움 - AI가 반복적·기계적인 업무를 대신하면 팀이 더 중요한 작업에 집중할 수 있지만, 실제 절감 시간과 효율 개선 지점을 정량화하기는 어렵다. - 작업 완료 시간에는 AI 사용 여부 외에도 다음과 같은 교란 요인이 영향을 준다. - 근속 기간 - 경력과 숙련도 - 작업의 복잡성 - 개인의 주관적인 디자인 경험 - 이런 요인을 통제하지 않으면 생산성 향상이 AI 때문인지, 다른 조건 때문인지 구분하기 어렵다. ## 기존 방법의 한계 ### 온라인 A/B 테스트 - 한 그룹에는 Figma Make를 제공하고 다른 그룹에는 제공하지 않는 방식이다. - 무작위 배정으로 사용자 특성의 차이는 어느 정도 줄일 수 있다. - 그러나 사용자마다 수행하는 작업이 달라 작업 난이도와 유형을 동일하게 맞추기 어렵다. - 따라서 두 그룹의 완료 시간 차이가 AI 효과인지, 과제 차이 때문인지 판단하기 어렵다. ### 로그 데이터 기반 인과 추론 - AI 기능을 사용한 작업과 사용하지 않은 작업의 평균 소요 시간을 비교하는 방식이다. - **성향 점수 매칭(PSM)**은 각 작업이 AI 사용 조건에 속할 확률을 계산해 비교하지만, 모든 교란 요인이 로그에 기록되어 있어야 한다. - 익명화된 사용자 ID만으로는 사용자의 주관적인 디자인 숙련도나 경험을 알 수 없어 PSM 적용에 한계가 있다. - **도구 변수(IV)** 방법은 AI 사용 여부에 영향을 주면서 작업 속도에는 다른 방식으로 영향을 주지 않는 변수가 필요하다. - 하지만 Figma 로그에는 이러한 조건을 만족하는 유효한 도구 변수가 없었다. ## 무작위 대조 실험을 선택한 이유 - RCT는 인과적 효과를 측정하는 표준적인 방법으로, 데이터 수집 단계에서 교란 요인을 직접 통제할 수 있다. - 연구에서는 다음 세 가지 요소를 결합했다. - **무작위 배정:** 참가자를 실험군과 대조군에 나누어 개인별 차이를 양쪽에 대체로 균등하게 분산 - **동일한 과제:** 모든 참가자가 같은 작업을 수행하게 해 과제 속성의 영향을 제거 - **실험 진행 관리:** 숙련된 연구팀이 실험을 감독해 수행 과정의 변동과 통계적 오류를 줄임 - 제품 디자이너와 PM이 일상적인 디자인 업무에서 Figma Make를 사용할 때 얻는 시간 절감 효과를 측정하기 위해 Figma 안팎의 사용자 연구팀과 협력했다. ## 연구 대상과 실험 도구 - 여러 AI 도구를 동시에 허용하면 어떤 도구가 시간 절감에 기여했는지 구분하기 어려워, 연구 대상 AI를 Figma Make 하나로 제한했다. - Figma Make는 사용자 기반이 크고 다양한 디자인 작업에 활용될 수 있어 연구 도구로 선정됐다. - 참가자는 총 100명으로 구성됐다. - 제품 디자이너 50명 - 제품 관리자 50명 - 표본 수는 GitHub Copilot 무작위 대조 실험 등 기존 연구에서 관찰된 효과 크기를 참고해 산출했다. - 이후 통계적으로 유의미한 효과를 탐지할 수 있도록 검정력 분석(power analysis)을 수행해 최종 표본 규모를 결정했다. ## 관찰된 효과 - 전체적으로 Figma Make 사용 시: - 디자인 작업이 **20% 더 빨라짐** - 작업이 **16% 더 쉬워짐** - 직군별로는 PM의 효과가 가장 컸다. - 작업 시간 **23% 단축** - 작업 난이도 **37% 감소** 실무에서 AI의 생산성 효과를 검증하려면 단순한 사용 로그 비교보다, 동일한 과제와 무작위 배정을 포함한 통제된 실험이 더 신뢰할 만하다. 특히 AI 도입 효과를 직군별로 비교하려면 사용자 특성뿐 아니라 과제 복잡도와 실험 진행 방식까지 함께 표준화하는 것이 중요하다.

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

Java용 GitHub Copilot SDK 사용하기

Ed Burns는 Microsoft와 GitHub 기술에 자바다운(idiomatic) 개발 경험을 제공하는 Principal Software Engineer입니다. 1997년부터 자바를 사용해 왔으며, 클라이언트·서버·클라우드·AI 등 다양한 영역에서 활동해 왔습니다. ### Ed Burns의 역할 - Microsoft와 GitHub 기술 생태계에 자바 관용적 개발 경험을 도입하는 업무를 담당합니다. - Principal Software Engineer로서 기술 방향과 개발 경험 개선에 기여합니다. ### 자바 경력과 전문 분야 - 1997년부터 자바를 다뤄 온 숙련된 개발자입니다. - 다음과 같은 폭넓은 영역에서 경험을 쌓았습니다. - 클라이언트 애플리케이션 - 서버 애플리케이션 - 클라우드 기술 - 인공지능(AI) ### 실용적인 결론 이 글은 특정 기술이나 방법론을 설명하기보다는 Ed Burns의 경력과 전문성을 소개하는 약력입니다. 자바가 클라이언트부터 AI까지 다양한 기술 영역에서 활용되어 왔다는 점을 보여줍니다.

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

GitHub 법무팀이 Copilot CLI를 활용해 업무 흐름을 간소화한 방법

GitHub 법무팀은 엔지니어가 아니어도 Copilot CLI를 활용해 반복적인 법무 업무를 자동화하고, 자신의 판단 기준을 반영한 도구를 직접 만들 수 있음을 보여준다. 계약서 작성·검토와 DMCA 통지 분석 같은 업무를 평문 지침, 정책 자료, 템플릿으로 구조화해 일관성과 처리 속도를 높였다. 다만 AI는 법률적 판단을 대체하는 것이 아니라, 사람이 최종 검토하는 의사결정 지원 시스템으로 활용됐다. ## 반복 업무를 AI 도구로 전환한 배경 - 법무팀의 업무에는 유사 계약 검토, 반복적인 법률 질의 응답, 기존 가이드 재활용 등 반복 작업이 많았다. - 구성원들은 전통적인 프로그래밍 경험이 부족했지만, 자신의 업무 방식과 판단 기준은 명확히 알고 있었다. - Copilot CLI에 자연어로 원하는 기능을 설명하고 저장소와 연결하면서, 프롬프트를 일회성으로 사용하는 대신 재사용 가능한 내부 도구로 발전시켰다. - 지침과 자료를 저장소에서 관리해 버전 관리, 일관성 확보, 협업이 가능해졌다. ## `terms-ai`: 계약 작성 스타일 가이드 구축 - Ngandu Kasuku는 데이터·인프라·제품 통합 관련 파트너십 계약이 급증하자 계약 작성 도구 `terms-ai`를 만들었다. - 저장소에 다음 자료를 정리했다. - AI 작업 지침 - 계약 작성 리소스 - 업무 흐름 - 기존에 승인된 계약서 - 평문 중심의 계약 작성 원칙을 내부 스타일 가이드로 만들었다. - 불필요하게 고어체인 법률 용어를 줄임 - 더 명확하고 읽기 쉬운 문장 사용 - 계약 전반에 동일한 문체와 기준 적용 - 기존 파트너와의 과거 계약 및 승인된 문서를 참고해 새 계약서나 부속합의서 초안을 작성할 수 있게 했다. - 민감한 계약서와 내부 정보는 공개 저장소에 포함하지 않고, 접근 제어가 적용된 내부 환경에 보관했다. - 결과적으로 계약 검토와 작성 시간이 약 절반으로 줄었고, 조항의 일관성과 개인의 작성 스타일 반영 수준이 향상됐다. - 핵심은 AI가 단순히 초안을 생성한 것이 아니라, 변호사의 경험과 판단 방식을 도구에 내장했다는 점이다. ## DMCA 통지 분석을 위한 평문 기반 워크플로 - Jesse Geraci는 DMCA 통지를 처리하기 위해 소스 코드를 빠르고 정확하게 분석해야 하는 문제에서 출발했다. - 처음에는 팀원들이 각자 작성하던 일회성 프롬프트를 다음과 같은 반복 가능한 지침으로 정리했다. - DMCA 통지 분류 - 코드 비교 - 라이선스 확인 - 우회 행위 검토 - 분석 결과 보고서 작성 - 전통적인 소스 코드 대신 다음과 같은 평문 파일을 중심으로 워크플로를 구성했다. - 업무 절차 지침 - 정책 및 법률 참고 자료 - 보고서 템플릿 - 변호사가 가진 언어 구성 능력과 법률적 방법론을 구조화된 업무 로직으로 활용했다. - 고객용과 변호사용 분석 모드를 분리했다. - 고객용: 빠른 결과와 에스컬레이션 권고 제공 - 변호사용: 심층 검토와 양측 주장 분석 제공 - 외부 데이터 소스를 연동하면서 팀이 재사용할 수 있는 표준 워크플로로 확장됐다. ## 데스크톱 앱과 재사용 가능한 법무 에이전트 - 초기 평문 워크플로는 이후 사전 정의된 법무 작업을 실행하는 데스크톱 앱으로 발전했다. - 앱 자체를 구축하려면 상당한 코드가 필요했지만, 실제 업무 동작을 바꾸는 지침은 여전히 Markdown과 자연어로 편집할 수 있다. - DMCA 코드 분석을 넘어 다음 업무로 범위가 확대됐다. - 계약서 검토 - NDA 분류 - 위험 평가 - 컴플라이언스 점검 - 답변 초안 작성 - 내부적으로는 다음과 같은 재사용 가능한 스킬과 에이전트로 업무를 나눌 수 있다. - 접수 및 초기 분류 - 플레이북 기준 대조 - 위험 점수 산정 - 증거 검증 - 에스컬레이션 경로 결정 - 보고서 조립 - 기술적 구현이 복잡해져도 법무팀은 읽기 쉬운 Markdown을 통해 AI의 동작과 기준을 직접 통제할 수 있다. ## 인간의 법률 판단을 중심에 둔 AI 활용 - 법무 Copilot은 변호사를 대체하는 시스템이 아니라 구조화된 의사결정 지원 도구다. - AI 활용의 목적은 다음과 같다. - 법률 분석의 일관성 향상 - 판단 과정의 투명성 확보 - 반복 업무의 확장성 강화 - 사람이 중요한 쟁점과 최종 판단에 집중하도록 지원 - 조직은 완벽한 상용 솔루션이나 전문 개발자를 기다리지 않고, 먼저 자신의 방법론·기준·결과 형식을 명확히 정의할 수 있다. 작게는 반복되는 계약 검토나 자료 분류처럼 시간을 가장 많이 빼앗는 업무 하나를 골라, 자연어 지침과 내부 자료를 재사용 가능한 워크플로로 정리하는 것이 현실적인 시작점이다. 단, 민감한 자료에는 접근 제어를 적용하고, AI 결과는 반드시 담당자의 검토와 승인을 거치도록 설계해야 한다.

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

말을 잘하는 AI를 넘어: 사용자가 원하는 방식으로 말하는 Kanana-o 만들기

제공된 내용에는 본문이 포함되어 있지 않고, 제목·작성자 정보·페이지 내비게이션만 있습니다. 따라서 Kanana-o 음성 생성 고도화 과정의 핵심 주장이나 기술적 세부 사항을 정확히 요약할 수 없습니다. ### 확인 가능한 정보 - 글 제목: **Beyond AI That Speaks Well: Making Kanana-o Speak the Way Users Want** - 관련 한국어 제목: **잘 말하는 AI를 넘어, 원하는 대로 말하는 AI로: Kanana-o 음성 생성 고도화 과정** - 작성자: martin.gale, abigail.r, edwin.ai - 본문 대신 다음·이전 글 링크와 검색 메뉴만 제공됨 본문 내용을 추가로 보내주시면 요청하신 형식에 맞춰 섹션별로 한국어 요약을 작성하겠습니다.

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

AI 숙련도는 최종 목표가 아니다 | Figma 블로그

AI 도구를 잘 다루는 능력은 중요하지만, 그것만으로는 AI 시대의 성공을 보장할 수 없다. 더 중요한 역량은 개인의 생산성 향상을 팀 전체의 속도로 확장하고, 다양한 의견을 모아 결정을 내리며, 실험과 실패를 안전하게 공유하는 협업 능력이다. 결국 AI의 가치는 한 사람이 10배 빠르게 일하는 데보다 팀 전체가 함께 더 빠르고 현명하게 움직이는 데 있다. ## AI 활용 능력 이상의 역량 - 제품 개발자 90% 이상이 AI 활용 능력을 미래의 성공에 필수적이라고 답했다. - AI 도구 숙련도는 채용, 업무 속도, 자신감 향상에 직접적인 도움을 준다. - 그러나 AI가 업무 방식을 바꿀수록 다음과 같은 역량의 중요성이 더 커진다. - 팀이 함께 사용할 수 있는 시스템 구축 - 적절한 사람들과 아이디어를 주고받는 능력 - 공동의 목표를 향해 협력하는 능력 ## 내부 제품 빌더가 되기 - AI 도구를 개인용으로만 사용하지 말고, 팀 전체가 활용할 수 있는 내부 도구로 전환해야 한다. - 예시는 다음과 같다. - 프로토타이핑 에이전트 - 브랜드 플러그인 - 공유 프롬프트 라이브러리 - 누구나 사용할 수 있는 프로토타이핑 도구 - Figma 연구팀은 AI를 활용해 설문 데이터를 탐색할 수 있는 인터랙티브 웹사이트를 만들었다. - 데이터와 맥락이 개인의 컴퓨터나 머릿속에만 머무르지 않게 했다. - AI를 개인 생산성 도구가 아니라 팀의 협업 역량을 확장하는 수단으로 활용했다. - Figma Brand Studio는 Figma Make로 이미지 효과 생성기를 제작했다. - 팀원이 사진이나 디자인에 브랜드에 맞는 질감을 클릭 한 번으로 적용할 수 있었다. - 핵심은 팀의 업무에서 반복되거나 막히는 지점을 발견하고, AI로 마찰을 줄이는 것이다. - 한 사람이 10배 빠르게 일하는 것보다 팀 전체가 함께 10배 빠르게 움직이는 편이 더 큰 효과를 낸다. ## 수많은 선택지에서 결정으로 이끌기 - AI는 짧은 시간에 수십 개의 방향과 결과물을 만들어내므로, 생성 자체보다 선택과 의사결정이 어려워진다. - 효과적인 의사결정을 위해서는 프로젝트 책임자뿐 아니라 다음 사람들을 참여시켜야 한다. - 반대 의견이나 새로운 관점을 가진 사람 - 과거의 맥락과 조직의 경험을 아는 사람 - 잠재적 위험을 발견할 수 있는 전문가 - 한 팀이 AI로 내부 앱을 빠르게 만들었지만, 직원들이 접근해서는 안 되는 회사 프로젝트 정보가 노출되는 문제가 발생했다. - 데이터 거버넌스 전문가를 초기 단계부터 참여시켰다면 예방할 수 있었던 사례다. - 회의 전에 이해하기 쉬운 선택지를 제공해야 한다. - 프로토타입의 각 흐름을 설명하는 Loom 영상 - 방향별 동작을 보여주는 주석이 달린 FigJam 파일 - 회의에서는 단순한 설명보다 트레이드오프를 비교하고 결정을 내리는 데 집중해야 한다. - 발언하지 않은 사람의 의견을 요청한다. - 모호한 추천은 구체적으로 되묻는다. - 논의를 진전시키는 질문을 한다. - 회의가 끝나기 전에 결정사항과 다음 단계를 확인한다. ## 나쁜 아이디어도 공유하기 - AI 활용 속도는 개인과 조직 사이에서 서로 다르게 나타난다. - 20%는 개인 기여자가 조직의 지원 없이 앞서가고 있다고 답했다. - 27%는 리더십이 AI 도입을 밀어붙이지만 팀이 따라가기 어려워한다고 답했다. - 팀원마다 AI를 접한 시점과 숙련도가 달라, 방치하면 역량 격차가 계속 커질 수 있다. - 앞선 사람만 계속 실험하면 다른 구성원은 AI 활용법을 배우기보다 뒤처지는 상황에 놓인다. - 따라서 아직 다듬어지지 않은 아이디어나 실패한 시도도 공유할 수 있는 환경이 필요하다. - 실험 결과를 공개적으로 나누면 개인의 경험이 팀의 학습 자산이 되고, AI 도입 속도 차이를 줄일 수 있다. AI 도구를 배우는 데 그치지 말고, 팀이 함께 사용할 수 있는 도구와 프로세스를 만들고, 다양한 이해관계자를 참여시켜 의사결정을 구조화하는 것이 좋다. 또한 완성된 결과만 공유하기보다 실패와 미숙한 아이디어까지 안전하게 나누는 문화를 구축해야 AI의 효과를 조직 전체로 확장할 수 있다.

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

GitLab은 왜 ‘Open Weights and American AI Leadership’ 서한에 서명했나

GitLab은 고객 선택권, 데이터 프라이버시, AI 모델 중립성을 강화하기 위해 ‘Open Weights and American AI Leadership’ 서한에 서명했다. 오픈 웨이트 모델은 비용·배포 환경·데이터 주권에 대한 통제력을 높이고, AI 안전성과 혁신을 촉진한다고 본다. GitLab은 개방형 모델과 독점 모델을 함께 지원하는 멀티모델·클라우드 중립적 DevSecOps 환경을 지향한다. ## 오픈 웨이트 모델을 지지하는 이유 - 오픈 웨이트 모델은 개발팀이 모델을 직접 선택하고 운영할 수 있게 한다. - 특정 클라우드나 AI 제공업체에 종속되지 않아 고객의 선택권과 협상력을 높인다. - 모델을 직접 배포할 수 있어 비용, 보안, 데이터 저장 위치를 조직의 요구에 맞게 관리할 수 있다. - 필요한 경우 외부 네트워크와 분리된 에어갭 환경에서도 모델을 운영할 수 있다. - 다양한 모델 제공업체가 경쟁하면 혁신과 보안 수준이 향상될 수 있다. ## 파운데이션 모델과 오픈 웨이트 모델의 조합 - 파운데이션 모델은 범용적인 성능과 폭넓은 활용 사례에서 강점을 보인다. - 오픈 웨이트 모델은 다음과 같은 통제력을 제공한다. - 모델 실행 위치 선택 - 비용 최적화 - 데이터 레지던시 관리 - 소스 코드와 전략적 지식재산 보호 - GitLab은 두 유형의 모델 중 하나만 선택하기보다, 업무와 보안 요구에 따라 함께 사용할 수 있어야 한다고 설명한다. ## GitLab의 모델·클라우드 중립 전략 - GitLab은 소프트웨어 개발 생명주기를 조율하는 DevSecOps 플랫폼으로서 팀의 업무 흐름에 여러 AI 모델을 연결한다. - 특정 클라우드나 단일 AI 모델 제공업체에 조직이 묶이지 않도록 하는 것이 핵심이다. - 모델 선택권이 실질적으로 유지되려면 AI 모델 시장 자체가 개방적으로 운영되어야 한다. - 이는 기업이 보안·개인정보·경쟁상의 위협으로부터 코드와 전략적 IP를 보호하는 데 중요하다. ## 개방성과 AI 안전성에 대한 입장 - GitLab은 안전하고 보안이 강화된 AI 생태계 구축에 개방성이 중요한 역할을 한다고 본다. - 오픈 웨이트 모델의 개발·배포·사용을 보장하는 정책을 지지한다. - 다만 모든 모델에 무제한 자유를 부여하기보다 다음과 같은 접근을 제안한다. - 위험 수준에 따른 비례적 안전장치 - 실제 악용 사례를 겨냥한 도구와 규제 - 혁신과 고객 선택권을 과도하게 제한하지 않는 정책 - 개방형 모델과 독점 모델이 성능과 가치로 경쟁하는 환경이 바람직하다고 주장한다. ## 실용적인 시사점 기업은 단일 AI 모델이나 클라우드에 의존하기보다, 업무별로 적합한 모델을 선택하고 보안·비용·데이터 위치를 함께 통제할 수 있는 멀티모델 전략을 검토하는 것이 좋다. GitLab의 서명은 이러한 모델 중립성과 오픈 웨이트 생태계에 대한 지지를 정책적·제품 전략적으로 확인한 것이다.

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

디지털 도구, 인간의 표현: Config 2026의 시각적 아이덴티티 | Figma 블로그

Config 2026의 시각적 정체성은 AI 시대의 강력한 디지털 도구와 인간의 창의적·불완전한 표현을 함께 보여주는 데 초점을 맞췄다. Figma Brand Studio는 아이디어가 변형되고 확장되는 과정을 글리프, 생성형 텍스처, 동적인 구성으로 표현했다. 그 결과 디지털 화면부터 샌프란시스코 Moscone Center의 대형 조형물과 공간 연출까지 일관되면서도 인간적인 브랜드 경험을 만들었다. ## 인간과 AI의 협업을 표현한 세 가지 원칙 - **진화(Evolution)** - 아이디어를 그대로 완성하는 대신 remix, reinterpret, reinvent 과정을 거쳐 새로운 결과를 만든다는 개념이다. - 하나의 형태가 변형되고 증식하는 모습을 시각 시스템에 반영했다. - **유동성(Fluidity)** - 디자인, 코드, 프로토타입 사이를 오가며 다양한 지점에서 작업을 시작하는 현대적 제작 방식을 나타낸다. - 고정된 순서보다 반복과 순환을 강조한다. - **조화(Harmony)** - 생성형 도구로 빠르게 탐색하더라도 최종 판단에는 인간의 관점과 감각이 필요하다는 의미다. - AI의 정교함과 사람의 의도적인 불완전성을 함께 유지했다. ## 글리프로 아이디어의 변형과 확장을 시각화 - Config의 핵심 시각 요소는 스케치처럼 보이거나, 생성형 이미지처럼 유기적이거나, 선명한 기하학 형태를 가진 **글리프**였다. - 입자 형태의 글리프는 아이디어가 계속 생성되고 퍼지는 과정을 상징했다. - 반대로 깔끔한 직사각형은 충분히 정리되고 완성된 아이디어를 나타냈다. - 글리프는 약 14피트 높이의 폼 조형물로 제작되어 Moscone Center 외부와 행사 공간의 장면을 구성했다. - 결과물은 다소 엉뚱하고 개성 있어 보이면서도 프로그램으로 생성된 듯한 디지털 특성을 동시에 지녔다. ## AI로 만든 불완전한 텍스처 - 팀은 Figma Make로 원하는 로파이 효과를 도구화하고, 다음 세 가지 핵심 텍스처를 제작했다. - 낙서 같은 선화 - 흐릿한 그라디언트 - 타원형 입자 - 이미지를 도구에 입력해 예측하기 어렵고 손으로 그린 듯한 구성을 생성했다. - 완벽하고 자동화된 시각물 대신 작은 오류와 불규칙성을 남겨 인간적인 느낌을 강조했다. - 수백 명의 발표자 사진에는 디더링 도구를 적용했다. - 모든 사진에 일관된 스타일을 빠르게 적용했다. - 미세한 점묘 효과가 디지털 코드처럼 보이면서도 손으로 만든 질감을 더했다. - 흐릿한 형태와 거친 점 텍스처는 키노트 무대, 영상, 행사장 애니메이션 등 여러 접점에서 활용됐다. ## 정적인 디자인과 모션의 병행 제작 - 팀은 정적 그래픽을 먼저 완성한 뒤 애니메이션으로 넘기는 방식 대신, 정적 자산과 모션 자산을 동시에 개발했다. - 디자인과 모션이 서로 영향을 주는 반복적인 협업 구조를 취했다. - 초기 글리프가 실제로 움직이는 모습을 확인하면서 형태의 가능성을 새롭게 발견하는 등, 애니메이션 자체가 디자인 탐색의 도구로 기능했다. - 이를 통해 Config의 그래픽은 단순한 장식이 아니라 아이디어가 살아 움직이고 변형되는 과정을 보여주는 시스템이 됐다. ## 실용적인 시사점 AI를 활용한 브랜드 디자인에서도 결과물을 지나치게 매끈하게 만드는 것보다, 의도적인 불완전성과 인간의 판단을 남기는 것이 차별화에 도움이 된다. 또한 글리프·텍스처·모션처럼 재사용 가능한 시각 요소를 시스템화하면 디지털 콘텐츠와 오프라인 공간 전반에 일관된 경험을 효율적으로 확장할 수 있다.

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

기업이 ‘상품 미수령’ 분쟁에서 승소하는 데 도움이 되는 증거 분석

“상품 미수령(Product not received)” 분쟁에서 승소율을 높이는 가장 중요한 요소는 주문 이행을 구체적으로 입증하는 증거다. 실물 상품은 배송 완료 상태, GPS 위치, 수령 서명이 효과적이었고, 디지털 상품은 실제 이용·소비 로그와 서비스 제공 기록이 유효했다. 특히 Stripe를 통해 처리한 전액 환불 증빙은 디지털 상품 분쟁의 승소율을 크게 높였다. ### 분석 범위와 방법 - Stripe는 16주 동안 발생한 100만 건의 분쟁 증거 패킷을 분석했다. - 배송 확인, GPS 배송 지도, 수령 서명, 디지털 이용 로그, 환불 기록 등 특정 증거가 포함된 경우와 그렇지 않은 경우의 승소율을 비교했다. - 아래 수치는 인과관계라기보다 각 증거와 높은 승소율 사이의 상관관계를 보여준다. ### 실물 상품: 배송 증거가 승소율을 크게 높임 - 배송 확인 정보를 제출한 분쟁은 해당 정보가 없는 경우보다 승소율이 **27%포인트 높았다**. - 배송 기사가 상품을 스캔한 위치를 보여주는 **GPS 배송 지도**를 추가하면 승소율이 15%포인트 더 상승했다. - **수령 서명**까지 포함하면 추가로 2%포인트 상승했다. - 배송 확인, GPS 지도, 수령 서명을 모두 제출한 분쟁은 배송 증거가 없는 경우보다 승소율이 총 **44%포인트 높았다**. - 많은 기업이 배송 정보를 제출하지 못하는 이유는 배송 시스템과 분쟁 대응 시스템이 분리되어 있어 주문과 배송 상태를 수동으로 연결해야 하기 때문이다. ### 배송 증거는 제출 시점이 중요함 - 추적 번호를 제출하더라도 제출 시점에 상품이 아직 배송 중이면, 해당 번호는 상품이 발송되었다는 사실만 보여줄 수 있다. - 배송 완료가 확인된 뒤 증거를 제출한 경우 승소율은 배송 확인 증거가 없는 경우보다 **27%포인트 높았다**. - 반대로 상품이 배송 중일 때 추적 정보를 제출한 경우 상승폭은 **2%포인트**에 그쳤다. - 고객이 배송 도착 전에 분쟁을 제기할 수 있으므로, 대응 기한이 허용한다면 배송 완료 후 증거를 제출하는 것이 유리하다. - 배송 완료 전에 제출해야 한다면 다음 내용을 함께 제시하는 것이 좋다. - 주문이 아직 약속된 배송 기간 안에 있다는 자료 - 배송 지연 또는 운송 중 상태를 보여주는 기록 - 결제 시 고객이 동의한 예상 배송일 ### 디지털 상품: 실제 이용·소비를 입증해야 함 - 디지털 상품은 배송 대신 고객이 실제 상품이나 서비스를 이용했다는 증거가 필요하다. - 스트리밍, 다운로드, 로그인, 콘텐츠 접근 등을 보여주는 **디지털 활동·사용 로그**가 포함된 분쟁은 그렇지 않은 경우보다 승소율이 **10%포인트 높았다**. - JSON 형식의 분석·텔레메트리 로그처럼 특정 고객이 특정 상품을 이용한 사실을 보여주는 자료가 효과적이다. - 계정 생성, 서비스 활성화, 권한 부여 등을 증명하는 **서비스 제공 기록**은 승소율을 **8%포인트 높였다**. - 단순히 “서비스에 접근할 수 있었다”는 기록보다, 고객이 실제로 구매한 콘텐츠를 재생·다운로드·사용했다는 구체적 증거가 더 강력하다. ### Stripe 환불 증빙의 효과 - 고객이 이미 환불받았더라도 환불과 카드 분쟁이 비슷한 시기에 처리되면 분쟁이 제기될 수 있다. - 디지털 상품 분쟁에서 **Stripe를 통해 처리한 전액 환불** 증거를 제출한 경우 승소율이 증거가 없는 경우보다 **63%포인트 높았다**. - 스토어 크레딧 등 다른 방식으로 환불한 경우 승소율 상승폭은 **6%포인트**에 불과했다. - 카드 발급사는 결제 처리업체와 카드 네트워크에 남은 환불 기록을 직접 확인할 수 있지만, 외부 방식의 환불은 같은 수준으로 검증하기 어렵기 때문이다. ### Stripe Smart Disputes의 자동화 - Smart Disputes는 분쟁 유형에 맞춰 배송 기록, 이용 로그, 환불 정보 등을 자동으로 조합해 증거 패킷을 만든다. - 배송업체와 운송장 번호를 제공하면 배송 상태, 시각, 위치 등 전체 이행 기록을 자동으로 수집할 수 있다. - 고객과의 커뮤니케이션이나 추가 문서를 직접 첨부하면 자동 생성된 자료와 함께 통합된다. - 분쟁의 네트워크, 지역, 카드 발급사, 사유 코드에 따라 증거의 내용과 구성을 최적화한다. - 기한 내 별도 조치를 하지 않아도 마감 전에 증거를 대신 제출해 기한 누락을 방지한다. - 이미 Stripe를 사용 중인 기업은 별도 통합 없이 이용할 수 있다. 실무적으로는 분쟁이 발생할 때마다 추적 번호만 제출하기보다, 배송 완료·위치·서명까지 포함한 자료를 제출하고, 디지털 상품은 특정 고객의 실제 이용 로그를 보존하는 것이 좋다. 환불이 필요할 때는 가능한 한 결제 처리업체를 통해 환불하고, 배송·이용·환불 데이터를 분쟁 시스템과 연결해 자동으로 증거를 생성할 수 있도록 구성하는 것이 권장된다.

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

범용 콘텐츠 처리 플랫폼 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 애플리케이션을 만들 때 모델 개발에만 집중하기보다, 다양한 파일을 안정적으로 추출·정규화·변환하는 기반을 먼저 확보하는 것이 실용적인 접근이다.

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

Sightlines 1호: Config에서 얻은 인사이트 | Figma 블로그

AI 시대에도 좋은 리더십의 기본과 디자인의 본질은 변하지 않는다. 리더들은 AI를 제품·팀·업무 시스템에 통합하면서도 품질을 유지하는 방법을 실험하고 있으며, 속도보다 중요한 것은 인간의 판단력과 협업이라고 강조한다. 자동화로 생산량이 늘어날수록 좋은 결과를 선별하는 ‘취향(taste)’과 세밀한 완성도가 핵심 경쟁력이 된다. ## AI 시대의 리더들이 고민하는 과제 - AI를 제품, 조직, 업무 프로세스에 어떻게 도입할지 아직 대부분의 리더가 탐색 중이다. - AI가 제공하는 빠른 제작 속도를 활용하면서도 품질 저하를 막아야 한다. - AI 이전의 전문성, 팀 구조, 협업 방식 중 무엇을 유지하고 무엇을 바꿀지 재검토하고 있다. - 변화의 방향을 리더 자신도 완전히 알지 못하는 상황에서 팀을 이끌어야 한다. ## 변하지 않는 리더십의 기본 - 좋은 리더의 핵심 역량은 AI 시대에도 크게 달라지지 않는다. - 호기심이 많고 비판적으로 사고하는 사람들로 팀을 구성해야 한다. - 빠르게 결과를 만드는 것보다 높은 완성도와 장인정신에 대한 기준을 유지해야 한다. - 리더는 모든 세부 사항을 직접 통제할 수 없으므로, 신뢰할 수 있는 인재를 채용하고 권한을 위임해야 한다. ## 초보자의 관점으로 실험하기 - 리더와 팀원 모두 기존 방식이나 전문성에만 의존하지 않고 원칙부터 다시 검토해야 한다. - AI 도구를 단순히 도입하는 데 그치지 말고, 실제 프로토타입을 만들며 가능성과 한계를 확인해야 한다. - 리더도 팀과 함께 직접 실험하며 변화 과정을 경험해야 한다. - 새로운 도구를 좇기보다 어떤 문제를 해결하려는지, 고객과 인간에게 어떤 가치를 주는지를 먼저 판단해야 한다. ## 개인 작업보다 중요해진 협업 - AI 도구는 사람을 혼자 작업하는 흐름으로 끌어갈 수 있지만, 리더들은 오히려 협업을 강화하고 있다. - 작업물을 공개하고, 팀 전체가 피드백과 비평을 주고받아야 한다. - 여러 사람이 결과물을 함께 검토하고 최선의 방향을 논쟁하는 과정이 품질을 높인다. - 협업은 단순한 업무 분담이 아니라 판단 기준을 공유하고 결과의 완성도를 높이는 방식이다. ## 자동화 시대의 핵심 경쟁력은 ‘취향’ - AI로 누구나 빠르게 많은 결과물을 만들 수 있게 되면서 결과물의 양 자체는 차별점이 되기 어렵다. - 무엇이 좋은지 판단하고, 불필요하거나 수준 낮은 결과를 과감히 제거하는 편집 능력이 중요해진다. - 한동안 낮은 품질의 디자인이 많아질 수 있지만, 뛰어난 작업은 결국 드러난다는 전망이 제시된다. - 창작자의 상상력, 판단력, 편집 능력은 자동화하기 어려운 인간 고유의 역량으로 남는다. ## 인간 중심 디자인과 세부 완성도 - 도구 자체를 따라가기보다 최종 사용자인 인간을 중심에 두어야 한다. - 디자인은 고객에게 기업이 얼마나 세심하게 신경 썼는지를 보여주는 수단이다. - 작은 세부 사항까지 정교하게 다듬으면 고객에게 논리적 만족을 넘어 감정적 반응을 이끌어낼 수 있다. - AI 시대에도 인간을 이해하고 배려하는 태도와 세심한 품질 관리가 중요하다. AI를 활용할 때는 속도와 생산성만 추구하기보다, 실험·협업·비판적 검토를 함께 운영하는 것이 바람직하다. 특히 팀은 AI가 만든 결과를 그대로 받아들이지 말고, 인간의 취향과 판단력으로 선별하고 다듬는 체계를 갖춰야 한다.

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

워크플로우 랩: Figma Make로 디자인을 직접 배포하기 | Figma 블로그

디자인과 개발의 핸드오프는 일방향일 필요가 없으며, 디자이너가 Figma Make에서 실제 코드베이스를 직접 수정하고 PR까지 이어지는 작업 흐름을 제안한다. 작은 접근성·사용성 개선을 티켓과 백로그에 맡기지 않고 디자이너가 직접 처리하면, 엔지니어는 대규모 아키텍처 작업에 집중하면서도 제품의 완성도를 높일 수 있다. Figma Design, Figma Make, Figma agent, GitHub 연동을 활용해 캔버스에서 검토하고 코드로 반영하는 것이 핵심이다. ## 작은 개선이 백로그에 묻히는 문제 - “간격을 조금 줄여 달라”거나 “스크린 리더가 잘못 읽는다”와 같은 수정은 중요하지만 규모가 작아 우선순위 경쟁에서 밀리기 쉽다. - 디자이너가 요구사항을 티켓으로 작성하면 엔지니어가 의도를 해석해야 하므로, 스크린샷과 설명을 주고받는 과정에서 디자인의 뉘앙스가 손실된다. - 그 결과 엔지니어는 실제 구현보다 디자이너의 결정을 번역하는 데 시간을 쓰게 된다. - 글에서는 이러한 문제를 해결하기 위해 디자이너가 저위험·고완성도 작업을 처음부터 끝까지 맡는 방식을 제안한다. ## MOSF 웹사이트의 접근성 개선 사례 - 가상의 박물관인 ‘Museum of Speculative Futures(MOSF)’가 사례로 등장한다. - 엔지니어는 대규모 정보 구조 재작성에 집중해야 하고, 디자이너는 웹사이트의 접근성 문제를 해결하려 한다. - PM은 엔지니어가 구조 개편 같은 고난도 작업을 계속 담당하고, 디자이너가 세부적인 접근성·사용성 개선을 직접 처리하도록 역할을 나눈다. - 목표는 기술적으로 동작하는 수준을 넘어, 다양한 사용자가 실제로 편리하게 사용할 수 있는 웹사이트를 만드는 것이다. ## 캔버스에서 사용자 피드백 수집 - 디자이너는 수정 전에 현재 경험을 점검하기 위해 Figma Design의 Figma agent를 사용한다. - 첫 방문자, 재방문 회원, 스크린 리더 사용자 등 여러 합성 페르소나를 생성하고 사이트를 탐색하게 한다. - 합성 페르소나는 실제 사용자 조사나 대면 테스트를 대체하지 않지만, 초기에 명백한 마찰을 발견해 후속 사용자 조사에 집중할 여지를 만든다. - 탐색 결과 다음과 같은 문제가 확인된다. - 전시 페이지의 내비게이션 라벨이 모호함 - 주요 행동 유도 버튼(CTA)이 눈에 잘 띄지 않음 - 날짜 선택기가 한눈에 이해하기 어려움 - 검색 결과가 없을 때 빈 화면만 표시됨 - 각각은 대규모 기능 변경은 아니지만, 여러 문제가 누적되면 사이트의 접근성과 사용성이 크게 떨어질 수 있다. ## 팀 검토를 거친 디자인 수정 - 디자이너는 에이전트가 발견한 문제를 바탕으로 디자인을 수정한다. - 이후 디자이너, 엔지니어, PM이 캔버스에서 변경 사항을 함께 검토한다. - 검토 대상에는 방문 페이지의 더 명확한 라벨, 눈에 잘 띄는 CTA, 사용하기 쉬운 날짜 선택기 등이 포함된다. - 디자인 단계에서 팀의 합의를 먼저 확보하므로, 코드 수정 이후에 요구사항을 다시 해석하거나 되돌리는 일을 줄일 수 있다. ## Figma Make로 실제 코드에서 작업 - 디자이너는 프로덕션 코드와 연결된 Figma Make를 사용해 캔버스의 수정 사항을 실제 코드에 반영한다. - 기존처럼 티켓을 생성해 백로그에 넣고 엔지니어가 나중에 구현하기를 기다리지 않는 것이 핵심이다. - Figma Make, GitHub 연동, 주석과 리뷰 기능을 통해 디자인 변경을 코드 변경으로 연결하고 팀 검토를 이어간다. - 최종적으로 작업은 풀 리퀘스트(PR) 단계까지 진행되며, 디자이너가 캔버스에서 시작한 개선을 병합 가능한 코드 변경으로 전달한다. - 이 방식은 엔지니어의 책임을 없애는 것이 아니라, 엔지니어가 코드 품질과 구조를 검토하는 동안 디자이너가 세부적인 사용자 경험 개선을 주도하도록 역할을 재배치한다. 작은 접근성·사용성 개선은 별도 티켓으로 쌓아두기보다, 디자이너가 실제 코드에서 직접 수정하고 엔지니어와 PR 리뷰를 진행하는 편이 효율적이다. 다만 합성 페르소나의 결과는 초기 탐색용으로 활용하고, 중요한 접근성 판단은 실제 사용자 조사와 기술 검증으로 보완하는 것이 바람직하다.

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

버전 업으로 빌드가 깨졌을 때 GitLab이 해결해 줍니다

GitLab의 Dependency Scanning Auto-Remediation은 취약한 의존성을 자동으로 업그레이드하고, 버전 변경으로 빌드가 깨지면 AI가 코드까지 수정하는 기능이다. 수정 사항은 동일한 머지 리퀘스트에서 검토되며, 기존 승인 절차와 감사 기록을 그대로 따른다. 이를 통해 개발자가 보안 취약점 수정에 직접 많은 시간을 쓰지 않고도 컴플라이언스 기한 내에 대응할 수 있다는 것이 글의 결론이다. ## 의존성 보안 백로그가 증가하는 이유 - 취약하거나 오래된 외부 컴포넌트는 OWASP Top 10에 포함되는 대표적인 위험 요소다. - Maven 생태계 조사에 따르면 최신 릴리스에 유입되는 취약점의 약 63%가 직접 의존성이 아닌 전이적 의존성에서 발생했다. - 취약점 수정은 기능 개발과 경쟁하는 수작업이어서, 특히 PCI-DSS와 FedRAMP의 30일 기한을 넘기는 고위험 취약점이 생기기 쉽다. - 의존성 업데이트 8건 중 약 1건은 호환성이 깨지는 변경을 포함하며, “하위 호환”으로 표시된 업데이트도 실제 프로젝트의 빌드를 깨뜨릴 수 있다. - AI를 활용한 익스플로잇 개발과 무기화가 빨라지면서 취약점을 장기간 방치할 위험도 커지고 있다. ## 취약점 발견부터 수정까지 자동화 - SBOM 기반 의존성 스캐닝이 수정 가능한 취약점을 발견하면, GitLab이 가장 가까운 안전 버전으로 올리는 머지 리퀘스트를 자동 생성한다. - 적절한 수정 버전이 없으면 무리하게 변경하지 않고 취약점을 보고서에 유지한다. - 자동 생성된 머지 리퀘스트는 전용 서비스 계정으로 작성되어 변경 주체를 추적할 수 있다. - 취약점의 심각도, 허용할 업데이트 범위(패치·마이너·메이저)를 설정할 수 있다. - 특정 취약점에 대해서는 취약점 보고서에서 사용자가 직접 자동 수정을 실행할 수도 있다. ## AI 기반 breaking change 해결 - 버전 업그레이드 후 파이프라인이 실패하면 GitLab Duo Agent Platform이 자동으로 원인을 분석한다. - 분석 대상에는 다음이 포함된다. - 파이프라인 오류 메시지 - 의존성의 변경 로그 - 프로젝트 코드에서 해당 의존성을 사용하는 방식 - AI는 같은 머지 리퀘스트 안에서 필요한 애플리케이션 코드 수정 커밋을 추가한다. - 수정 후에도 파이프라인이 통과하지 않으면 자동으로 중단하고, 분석 결과를 머지 리퀘스트에 남겨 개발자가 이어서 처리할 수 있게 한다. - 지원 생태계는 Bundler, Maven, Gradle, 주요 Python 및 JavaScript/TypeScript 패키지 관리자이며, Rust와 Go 지원도 예정되어 있다. ## 검토와 감사 절차를 유지하는 자동화 - 자동 수정은 절대로 자체적으로 병합되지 않는다. - 모든 변경은 기존 리뷰어 승인과 브랜치 보호 규칙을 거친다. - 머지 리퀘스트에는 다음 정보가 명시된다. - 어떤 취약점을 해결하는지 - 어떤 버전으로 업데이트하는지 - 빌드를 통과시키기 위해 AI가 제안한 코드 변경 - 변경 내용, 승인자, 승인 과정이 감사 기록으로 남아 보안 및 규제 대응에 활용할 수 있다. - 자동화는 조직 자체의 파이프라인에서 실행되므로 기존 접근 제어와 승인 게이트를 상속한다. ## 자동화 폭주를 막는 안전장치 - 쿨다운 기간을 설정해 모든 파이프라인마다 새로운 수정 작업이 생성되는 것을 방지한다. - 닫힌 머지 리퀘스트는 더 최신 수정 버전이 등장하지 않는 한 다시 만들지 않는다. - 프로젝트 또는 그룹 단위 구성 프로필로 조직의 위험 허용 수준에 맞게 정책을 관리할 수 있다. - 기능은 현재 퍼블릭 베타이며 GitLab.com에서 제공되고, GitLab Self-Managed와 Dedicated에도 순차적으로 적용된다. - 자동 버전 업데이트는 GitLab Ultimate에 추가 비용 없이 포함된다. AI 기반 breaking change 해결은 GitLab Duo Agent Platform의 무료 체험 또는 Ultimate에 포함된 GitLab Credits로 이용할 수 있다. ## 실용적인 적용 권장 사항 - 먼저 패치·마이너 업데이트만 허용해 자동화 범위를 제한하고, 안정화 후 메이저 업데이트로 확대하는 것이 안전하다. - AI가 작성한 코드도 반드시 일반 코드 리뷰와 테스트를 거쳐야 한다. - PCI-DSS나 FedRAMP처럼 기한이 명확한 환경에서는 고위험 취약점과 전이적 의존성을 우선 대상으로 삼는 것이 효과적이다.

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