techlist.io
KREN

Techlist.io - 한국 테크 블로그 큐레이터

stripe4분 읽기큐레이션 요약

Stripe Radar를 확장해 비즈니스를 더 안전하게 보호하기

Stripe는 AI 기반 사기 방지 도구인 Radar를 모든 지원 결제 수단과 외부 결제 프로세서까지 확장했다. 새로운 기능은 결제 사기뿐 아니라 다중 계정 악용, 종량제 미납, 악성 봇 결제, 플랫폼 입점 사업자 사기까지 실시간으로 탐지·예방하는 데 초점을 둔다. 또한 기업별 맞춤 사기 모델과 분쟁 대응 기능을 제공해, 사기 차단과 오탐 감소를 동시에 추구한다. ## 모든 결제 수단을 아우르는 사기 탐지 - Radar는 은행 자동이체, BNPL, 암호화폐, 디지털 지갑, 실시간 결제, 현금 바우처 등 Stripe가 지원하는 전 세계 결제 수단에 적용된다. - 한 결제 수단에서 탐지된 사기 정보가 네트워크 전체에 공유된다. - 예를 들어 도난 카드에 사용된 IP 주소와 기기 지문이 탐지되면, 은행 결제·지갑·BNPL 거래에서도 해당 정보가 위험 신호로 활용된다. - Affirm, Cash App, Klarna, PayPal을 사용하는 기업에서 5개월 동안 의심 사기가 71% 감소했다. ## 멀티프로세서 거래를 위한 위험 신호 - Stripe 외부에서 처리되는 결제에도 활용할 수 있는 추가 위험 신호를 제공한다. - 카드 네트워크에서 조기 사기 경고가 발생할 가능성을 예측한다. - 기업은 거래를 선제적으로 환불해 분쟁률 상승을 막을 수 있다. - 사기성 차지백으로 이어질 가능성도 예측한다. - 환불, 증거 수집, 분쟁 대응 전략 조정 등에 활용할 수 있다. - 향후 전체 결제 스택에서 사용할 수 있는 신호를 추가할 예정이다. ## 기업별 맞춤 사기 모델 - 기업은 상품 카탈로그, 고객 충성도, 행동 데이터, 구조화된 메타데이터 등 자체적인 위험 신호를 Stripe에 전달할 수 있다. - Stripe의 글로벌 네트워크 데이터와 기업별 데이터를 결합해 맞춤형 모델을 구축한다. - 초기 도입 기업에서는 오탐 증가 없이 기존보다 최소 15% 더 많은 사기를 탐지했다. ## 다중 계정 악용 차단 - 사기 사용자가 여러 계정을 만들어 무료 체험, 프로모션 쿠폰, 도난 카드 사용을 반복하는 행위를 탐지한다. - 가입 시점에 계정을 실시간 평가해 악용이 시작되기 전에 차단할 수 있다. - 과거 사기 사례에서 얻은 기기 지문, IP 주소, 이메일 도메인 등의 네트워크 정보를 활용한다. - AI 기업 가입자의 6분의 1 이상이 다중 계정 악용과 연관된 것으로 나타났으며, ElevenLabs는 하루 약 2,000명의 무료 요금제 악용 사용자를 차단했다. ## 종량제 서비스의 미납 위험 예측 - 종량제 고객이 서비스를 먼저 사용한 뒤 청구 시점에 비용을 지불하지 않는 행위를 탐지한다. - 사용량이 누적되는 동안 미납 가능성을 예측해 청구 전에 개입할 수 있다. - 기업은 위험도에 따라 다음과 같은 조치를 취할 수 있다. - 선불 충전 또는 추가 결제 요구 - 서비스 이용 중단 - 사용 한도 설정 - 수동 검토 ## 악성 봇 결제 탐지 - 자동화된 구매 봇과 고객을 대신해 정상적으로 작동하는 에이전트를 구분하는 기능이다. - Stripe Checkout 결제에 악성 봇일 가능성을 나타내는 0~100점의 봇 점수를 부여한다. - 기업은 이를 활용해 다음과 같은 정책을 적용할 수 있다. - 한정 상품의 자동 구매 차단 - 짧은 시간에 반복되는 고속 주문 검토 - 프로모션 악용 및 구매 한도 우회 방지 ## 플랫폼의 입점 사업자 위험 관리 - 생성형 AI로 위조 신분증, 문서, 웹사이트를 제작하는 사기가 늘면서 플랫폼은 가입 절차의 편의성과 위험 관리 사이에서 균형을 맞춰야 한다. - Radar는 사업자와 거래별 0~100점 사기 점수, AI 기반 위험 사유 설명, 계정 메모와 이력, 분쟁·환불·거절·결제 지표를 제공한다. - 플랫폼은 Stripe 내부뿐 아니라 외부 거래와 사업자 정보까지 종합해 입점 심사와 사후 관리를 할 수 있다. ### 사기성 웹사이트 신호 - 사업자 웹사이트를 실제 사기 분석가처럼 평가한다. - 비정상적으로 저렴한 명품, AI가 생성한 듯한 문구, 철자가 틀린 브랜드 URL 등을 위험 요소로 분석한다. - 온보딩 자동 검증, 수동 심사 대상 선별, 자체 위험 점수 계산에 활용할 수 있다. ### 사기성 사업자 신호 - 은행 계좌, 사업자 정보, 거래 활동, 분쟁 기록 등 Stripe 네트워크의 패턴을 분석해 사업자의 사기 위험을 판단한다. - 플랫폼은 위험 사업자에 대해 지급 보류, 결제 중단, 계정 거부, 지급 준비금 설정, 신원 확인 요청 등을 실행할 수 있다. ### 사업자 채무불이행 위험 신호 - 사업자가 마이너스 잔액을 장기간 유지할 가능성을 예측한다. - 특히 잔액이 60일 이상 마이너스 상태로 남을 위험을 평가한다. - 플랫폼은 고위험 사업자에 대해 지급 일정 조정, 준비금 요구, 추가 심사를 선제적으로 적용할 수 있다. ## 분쟁 대응 기능 확대 - 글의 마지막 부분에서는 더 정교한 증거 자료와 자동화된 증거 라이브러리를 활용해 결제 분쟁에 대응하는 기능을 소개하려 했으나, 제공된 원문은 해당 섹션 제목에서 끝난다. - 따라서 구체적인 분쟁 대응 기능과 성과는 제시된 내용만으로는 확인할 수 없다. ## 실용적인 적용 방향 - 결제 수단이 다양하거나 여러 프로세서를 사용하는 기업은 네트워크 기반 위험 신호를 통합하는 것이 유리하다. - AI·SaaS 기업은 가입 단계의 다중 계정 악용과 사용량 누적 후 미납을 별도로 관리해야 한다. - 플랫폼은 사업자 온보딩 시 웹사이트·계좌·거래·분쟁 데이터를 함께 평가하고, 위험 점수에 따라 지급 보류나 준비금 설정 같은 단계적 조치를 적용하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)
머신러닝fraud-detectionpayment-processingbot-detection+4
google3분 읽기큐레이션 요약

제로 트러스트 집계를 통한 비공개 분석

개인정보 보호형 분석은 개별 기기 데이터를 노출하지 않고 인구 집단의 경향만 파악하기 위한 핵심 수단이다. 이 글은 새로운 격자 기반 암호 프로토콜과 TEE(신뢰 실행 환경)를 결합해, 단 한 번의 메시지 전송만으로 안전한 집계를 수행하는 제로 트러스트 분석 구조를 소개한다. 암호 기술은 원시 데이터의 복호화·재구성을 막고, TEE의 원격 검증은 공개된 코드가 의도대로 실행되는지 확인해 보안을 다층화한다. ## 온디바이스 AI 분석의 필요성 - 모델을 사용자 기기에서 실행해도 실제 성능과 실패 양상을 파악하려면 집단 수준의 분석이 필요하다. - 주요 분석 질문은 다음과 같다. - 특정 지역의 새로운 표현 때문에 번역 모델이 성능 저하를 겪는가? - 특정 조명이나 지역적 환경에서 이미지 분류기의 편향이 나타나는가? - Smart Reply처럼 기술적으로는 맞지만 사용자가 불편해하는 기능의 실제 오류율은 얼마인가? - 연합 분석은 여러 기기의 데이터를 집계하지만, 집계되기 전까지 개별 데이터가 보호되는 별도의 프라이빗 집계 경로가 필요하다. ## 하드웨어 보호와 암호학적 보호 - TEE는 프로세서와 메모리 일부를 격리된 보안 영역으로 만들며, 운영체제나 악성 하이퍼바이저가 손상돼도 내부 데이터를 보호하도록 설계된다. - 원격 검증(attestation)은 enclave에서 실행 중인 펌웨어와 소프트웨어 상태를 하드웨어 기반 암호 지문으로 증명한다. - Google은 Pixel Recorder에서 TEE 기반 차등 개인정보 보호 집계를 사용해 왔다. - 그러나 TEE는 사이드 채널 공격에 취약할 수 있으며, 새로운 취약점이 계속 발견될 가능성이 있다. - 암호 프로토콜은 수학적으로 개별 데이터 복원이 불가능하고 익명화된 집계 결과만 노출된다는 증명 가능한 보장을 제공한다. - 기존 다중 라운드 보안 집계는 기기가 장시간 온라인 상태를 유지해야 해 대규모 활용에 제약이 있었다. ## 제로 트러스트 기반 다층 방어 - 새 시스템은 암호학적 보호와 TEE를 함께 사용해 어느 한 구성요소에 대한 신뢰 의존도를 줄인다. - 암호 계층은 서버 메모리에서 개별 원시 데이터가 복호화되거나 재구성되지 않도록 한다. - 데이터가 오프디바이스에서 평문으로 처리되는 시점은 이미 집계·익명화된 최종 결과를 다룰 때뿐이다. - TEE의 attestation은 참여자들이 실제로 공개된 코드가 올바르게 컴파일되고 실행되는지 검증할 수 있게 한다. - 따라서 TEE가 공격받더라도 암호 계층이 개별 데이터 보호를 유지하는 방어 심층성을 제공한다. ## 한 번의 메시지로 수행하는 암호 집계 - 새로운 프로토콜은 사용자가 데이터를 여러 차례 주고받지 않고 한 번의 메시지로 제출할 수 있게 한다. - 클라이언트는 데이터를 암호화하며, 서버는 암호문을 직접 합산하면서 그 결과가 원래 메시지들의 합과 대응되도록 처리한다. - 암호화 키 역시 집계되므로, 서버가 얻을 수 있는 복호화 키는 개별 값이 아니라 집계값만 복호화할 수 있다. - 클라이언트 일부는 소규모 위원회(committee)를 구성해 집계값을 해제하는 데 필요한 힌트를 보유한다. - 위원회 구성원은 자주 참여하지 않으며, 복호화 권한은 여러 참여자에게 분산된다. - 추가 차등 개인정보 보호 노이즈가 집계값에 적용되어 개인 정보 노출 가능성을 더욱 낮춘다. - 이 구조는 기기가 여러 라운드 동안 온라인 상태로 유지될 필요를 제거한다. ## Android SafetyCore 적용 - SafetyCore는 Android 9 이상에서 동작하는 개인정보 보호형 시스템 서비스다. - 온디바이스 안전 기능이 실제 환경에서 어떤 위협을 탐지하고 어디서 개선이 필요한지 파악하려면 집계 분석이 필요하다. - Google은 Android SafetyCore 팀과 협력해 새 프라이빗 분석 시스템을 적용하고 있다. - 목표는 사용자 콘텐츠를 직접 공개하지 않으면서 탐지 성능과 놓치는 위협 유형 등 집단적 경향을 파악하는 것이다. ## 실용적인 결론 민감한 온디바이스 데이터를 분석할 때는 TEE만 단독으로 신뢰하기보다, 암호학적 집계·차등 개인정보 보호·TEE attestation을 함께 적용하는 것이 바람직하다. 특히 기기가 지속적으로 연결되기 어려운 환경에서는 일회성 메시지 기반 프로토콜이 운영 효율성과 개인정보 보호를 동시에 개선할 수 있다.

원문 읽기(새 탭에서 열림)
제로 트러스트differential-privacyon-device-aifederated-analytics+3
meta4분 읽기큐레이션 요약

SilverTorch: 모델로서의 인덱스 — 추천 시스템을 위한 새로운 검색 패러다임

SilverTorch는 추천 시스템의 검색(retrieval) 단계를 여러 마이크로서비스가 아닌 하나의 통합 신경망으로 재설계한 아키텍처다. ‘Index as Model’ 패러다임을 통해 사용자 임베딩, ANN 검색, 적격성 필터링, 재순위화와 다중 작업 점수화를 하나의 PyTorch 모델에서 처리한다. 그 결과 기존 방식보다 최대 23.7배 높은 처리량과 20.9배 높은 컴퓨팅 비용 효율을 달성하면서도 추천 품질을 개선하고, 100ms 이하의 지연시간 제약을 유지할 수 있다고 설명한다. ## 기존 마이크로서비스 기반 검색의 한계 - 전통적인 추천 검색 시스템은 다음과 같은 서비스 조합으로 구성된다. - 사용자 타워 모델: 사용자의 관심사를 벡터인 사용자 임베딩으로 변환 - 후보 검색·필터링 서비스: 사용자 벡터와 유사한 콘텐츠를 찾고 언어·지역·정책 등을 기준으로 필터링 - 점수화 서비스: 남은 후보의 참여 가능성을 계산하고 순위를 조정 - 오케스트레이터: 각 서비스에 요청을 분산하고 결과를 통합 - 서비스 간 네트워크 왕복과 데이터 직렬화 과정이 100ms 이하의 검색 지연시간을 소모한다. - 사용자 모델, 아이템 인덱스, 필터링 규칙이 서로 다른 시점에 배포되어 버전이 불일치할 수 있다. - 예를 들어 사용자 모델은 v2인데 아이템 인덱스가 v1이면 서로 다른 버전의 임베딩이 비교된다. - ML 엔지니어는 주로 PyTorch를, 인프라 엔지니어는 C++를 사용해 개발 환경과 배포 주기가 분리된다. - Faiss-GPU와 같은 개별 최적화는 특정 서비스만 빠르게 만들 뿐, 서비스 간 데이터 이동과 독립적인 실행 구조라는 근본 문제는 해결하지 못한다. ## Index as Model: 인덱스를 모델 안으로 통합 - SilverTorch는 아이템 인덱스 자체를 모델 내부의 텐서로 표현한다. - 사용자 타워, ANN 검색, 적격성 필터, 점수화 계층을 모두 하나의 PyTorch 신경망에 포함한다. - 사용자의 요청은 단일 모델의 한 번의 forward pass를 거치며 다음 작업을 수행한다. - 사용자 관심사와 유사한 콘텐츠 검색 - 언어·국가·콘텐츠 정책 등에 따른 노출 가능 여부 확인 - 후보 재순위화 - 좋아요·공유·댓글 등 여러 참여 행동의 확률 예측 - 여러 예측값을 결합한 최종 점수 계산 - 하나의 모델 아티팩트와 단일 실행 경로를 사용하므로 구성 요소 간 공동 최적화와 일관된 버전 관리가 가능하다. - 모델 복잡도와 평가 후보 수를 늘리면서도 100ms 이하의 응답시간을 유지하는 것을 목표로 한다. ## 모델 내부의 검색·필터링·재순위화 - ANN 검색 영역은 전체 카탈로그를 모두 확인하지 않고 사용자와 가까운 아이템을 빠르게 찾는다. - 적격성 필터링 영역은 후보가 사용자에게 노출 가능한지 검사한다. - 언어 - 국가 및 지역 - 콘텐츠 정책 - 기타 서비스별 자격 조건 - 다중 작업 재순위화 영역은 여러 참여 행동을 동시에 예측한다. - 좋아요 - 공유 - 댓글 - 예측 결과를 종합해 참여 가능성이 높은 후보를 계산한다. - 일부 연산은 엔지니어가 직접 작성하고, 일부는 역전파를 통해 종단 간 학습할 수 있다. - 런타임에서는 모든 구성 요소가 동일한 `nn.Module`로 취급되므로 검색 모듈과 학습된 재순위화 모델을 자유롭게 조합할 수 있다. ## 모든 단계를 순수 PyTorch 모듈로 재구현 - 기존 ANN 검색, Bloom 인덱스 필터, 신경망 재순위화, 복합 점수화는 주로 독립적인 C++ 서비스로 구현되어 있었다. - 이러한 구현은 안정적이지만 각자 별도의 메모리·자료구조·실행 모델을 사용해 모듈 간 공동 최적화가 어렵다. - SilverTorch는 모든 데이터를 텐서로 표현하고, 모든 로직을 텐서 입력과 텐서 출력으로 통일한다. - 각 구성 요소는 PyTorch의 표준 `nn.Module` 인터페이스를 따른다. - 이를 통해 다음과 같은 최적화가 가능해진다. - 유망한 클러스터를 먼저 선택 - 선택된 클러스터 안에서만 필터링 - 필터를 통과한 후보만 점수화 - ML 엔지니어와 인프라 엔지니어가 서로 다른 계층에서 작업하는 대신 동일한 실행·개발 계층에서 모듈을 구성하고 최적화할 수 있다. ## 성능과 확장성 - 8천만 개 아이템을 대상으로 한 종단 간 평가에서 기존의 강력한 다중 서비스 기준선보다 초당 요청 처리량이 최대 23.7배 높았다. - CPU 기반 솔루션보다 추정 총소유비용(TCO) 효율이 20.9배 개선되었다. - 피드와 동영상 콘텐츠를 제공하는 여러 애플리케이션 제품군에 적용 가능한 규모 확장성을 보였다고 설명한다. - 신경망 재순위화와 다중 작업 점수화를 지연시간 예산 안에서 실용적으로 수행해, 기존 마이크로서비스 구조에서는 적용하기 어려웠던 추천 품질 개선을 가능하게 했다. 실용적으로는 검색 단계의 서비스 수가 많고, 후보 수·모델 복잡도·지연시간 간 충돌이 큰 시스템일수록 SilverTorch와 같은 통합 모델 구조의 효과가 크다. 다만 모든 구성 요소를 PyTorch로 통일하려면 GPU 메모리 관리, 모델 배포 안정성, 디버깅과 장애 격리 같은 운영 과제를 함께 해결해야 한다.

원문 읽기(새 탭에서 열림)
마이크로서비스recommendation-systemsneural-networkspytorch+3
gitlab4분 읽기큐레이션 요약

몇 분 만에 코드베이스 전체의 보안 스캐너 검사 완료

GitLab 19.0의 보안 구성 프로필은 프로젝트별 `.gitlab-ci.yml` 수정 없이 조직 전체에 보안 스캐너를 중앙에서 적용할 수 있게 한다. 이를 통해 SAST, 의존성 스캐닝, 비밀 탐지를 수백~수천 개 프로젝트에 몇 분 안에 배포하고, AI로 빨라진 개발 속도에 따른 보안 적용 누락을 줄일 수 있다. GitLab Ultimate 사용자는 보안 인벤토리에서 여러 프로젝트에 기본 프로필을 일괄 적용해 일관된 보안 검사 범위를 확보할 수 있다. ## 수동 스캐너 설정의 한계 - 프로젝트마다 `.gitlab-ci.yml`을 직접 수정하는 방식은 규모가 작을 때만 관리하기 쉽다. - 조직과 저장소가 늘어나면 다음과 같은 설정 드리프트가 발생한다. - 팀마다 서로 다른 SAST 규칙을 사용한다. - 새 프로젝트에는 의존성 스캐닝을 추가하지만 기존 프로젝트에는 적용하지 않는다. - 파이프라인 수정 과정에서 실수로 보안 스캐너 설정이 삭제된다. - 중앙 현황판이 없으면 어떤 프로젝트가 검사 중인지, 어떤 프로젝트가 누락됐는지 파악하기 어렵다. - AI를 활용한 코드 생성과 빠른 배포로 프로젝트·파이프라인 수가 증가하면서 보안 적용 범위의 격차가 더 커지고 있다. ## 보안 구성 프로필의 개념 - 보안 구성 프로필은 스캐너의 종류와 실행 조건을 중앙에서 정의하는 설정 묶음이다. - 그룹 수준에서 프로필을 한 번 설정한 뒤 여러 프로젝트에 일괄 적용할 수 있다. - 프로젝트별 YAML 파일에 SAST, 비밀 탐지, 의존성 스캐닝을 각각 추가할 필요가 없다. - GitLab은 권장 설정을 반영한 스캐너별 기본 프로필을 제공한다. - 따라서 YAML을 직접 작성하지 않고도 몇 분 안에 조직 전체의 스캐닝을 시작할 수 있다. ## 스캔 트리거와 보안 범위 기본 프로필은 스캐너별로 여러 실행 트리거를 활성화한다. - **머지 리퀘스트 파이프라인** - 열린 머지 리퀘스트 브랜치에 새 커밋이 푸시될 때 자동 실행된다. - 해당 머지 리퀘스트에서 새로 유입된 취약점에 초점을 맞춘 결과를 제공한다. - 기존 취약점으로 인한 불필요한 경고를 줄이고 개발자가 수정해야 할 문제를 명확히 한다. - **기본 브랜치 파이프라인** - 변경 사항이 기본 브랜치에 병합되거나 직접 푸시될 때 실행된다. - 보안 팀이 기본 브랜치의 전체적인 보안 상태를 지속적으로 확인할 수 있다. - **비밀 탐지의 푸시 보호** - 비밀 탐지는 위 두 트리거에 더해 푸시 보호를 제공한다. - 파이프라인 완료를 기다리지 않고 `git push` 과정에서 API 키나 토큰 등을 실시간으로 검사한다. - 비밀이 저장소에 들어가기 전에 푸시를 차단한다. - 이벤트 기반 기능이므로 보안 인벤토리에 일반적인 스캔 날짜가 표시되지 않는다. ## 실제 활용 사례 - **대규모 프로젝트의 검사 범위 표준화** - 보안 팀은 보안 인벤토리에서 모든 프로젝트의 스캐너 적용 여부와 실패 상태를 한눈에 확인할 수 있다. - 여러 프로젝트를 선택한 뒤 기본 프로필을 일괄 적용할 수 있다. - 개별 `.gitlab-ci.yml`을 수정하지 않고도 머지 리퀘스트와 기본 브랜치에서 SAST, 비밀 탐지, 의존성 스캐닝을 실행할 수 있다. - **코드 취약점의 조기 발견** - 개발자가 API 구현 중 안전하지 않은 역직렬화 패턴을 추가하면 SAST가 머지 리퀘스트 파이프라인에서 이를 탐지한다. - 코드가 승인·배포되기 전에 수정할 수 있어 사고 대응보다 훨씬 적은 비용으로 문제를 해결할 수 있다. - **감염된 의존성 차단** - 잠금 파일에서 의존성 버전을 업데이트하면 의존성 스캐닝이 변경된 패키지를 검사한다. - 악성 코드가 포함된 패키지 버전을 병합 전에 탐지해 빌드 서버나 운영 환경에 확산되는 것을 막는다. - **비밀 정보의 저장소 유입 방지** - 개발자가 디버깅 중 API 키를 커밋하려 하면 푸시 보호가 실시간으로 푸시를 차단한다. - 보안 티켓 생성이나 사후 자격 증명 교체가 필요해지기 전에 문제를 해결할 수 있다. ## 적용 방법과 상태 확인 - 보안 구성 프로필은 GitLab Ultimate의 GitLab.com, Self-Managed, Dedicated 환경에서 사용할 수 있다. - 적용 절차: 1. 그룹에서 **Secure > Security inventory**로 이동한다. 2. 적용할 프로젝트를 선택하거나 전체 프로젝트를 선택한다. 3. **Bulk Action > Manage security scanners**를 선택한다. 4. **Apply default profile to all**을 선택한다. - 적용 후 **Tool Coverage** 열에서 상태를 확인할 수 있다. - 녹색 막대: 스캐너가 완전히 활성화됨 - 부분 막대: 일부 트리거만 활성화됨 - 회색 막대: 아직 설정되지 않음 - 기존 `.gitlab-ci.yml` 설정과 프로필 기반 설정은 함께 사용할 수 있다. - 두 설정이 병존하는 전환 기간에는 보안 인벤토리의 상태 표시가 실제 결합 상태를 정확히 반영하지 않을 수 있으므로, 개별 프로젝트의 **Security Configuration** 페이지에서 프로필 상태를 확인하는 것이 권장된다. 조직 규모가 크거나 프로젝트 생성 속도가 빠르다면, 프로젝트별 YAML 관리보다 보안 구성 프로필을 기본값으로 적용하는 편이 효율적이다. 우선 보안 인벤토리에서 적용 누락 프로젝트를 확인한 뒤 기본 프로필을 일괄 적용하고, 이후 부분 적용·실패 상태를 정기적으로 점검하는 방식이 실용적이다.

원문 읽기(새 탭에서 열림)
CI/CDgitlabyamlsast+4
gitlab4분 읽기큐레이션 요약

SBOM 기반 종속성 스캔으로 공급망 위험 줄이기

오늘날 소프트웨어 공급망에서는 직접 선언한 패키지만 확인하는 기존 방식으로는 취약점의 유입 경로와 실제 위험 범위를 파악하기 어렵다. GitLab 19.0의 SBOM 기반 의존성 스캐닝은 직접·간접 의존성을 모두 목록화하고, 취약 패키지가 어떤 경로로 포함됐는지와 애플리케이션에서 실제 사용되는지를 분석한다. 이를 통해 개발자는 병합 전에 문제를 수정하고, 보안팀은 실제 노출 가능성이 높은 취약점부터 대응할 수 있다. ## SBOM 기반 의존성 스캐닝의 동작 방식 - 프로젝트의 서드파티 라이브러리와 패키지를 분석해 CycloneDX 형식의 SBOM을 생성한다. - 생성된 구성 요소를 GitLab Advisory Database와 대조해 알려진 취약점을 탐지한다. - 결과는 다음 위치에 표시된다. - 취약점을 유발한 변경 사항이 포함된 머지 리퀘스트 - 취약점 대시보드 - 보안 보고서 - SBOM과 의존성 스캐닝 보고서는 기계 판독이 가능해 컴플라이언스 보고나 다른 공급망 보안 도구와 연계할 수 있다. ## 전이 의존성의 유입 경로 추적 - 직접 추가한 패키지뿐 아니라 여러 단계로 중첩된 전이 의존성까지 분석한다. - 예를 들어 `library-a → library-b → library-c` 구조에서 `library-c`에 취약점이 있으면, 해당 패키지가 어떤 의존성 체인을 통해 들어왔는지 보여준다. - 취약점이 발견된 패키지를 직접 수정할지, 상위 의존성을 업데이트할지 등 적절한 개입 지점을 판단할 수 있다. ## 실제 코드 사용 여부에 따른 우선순위 지정 - 매니페스트나 빌드 파일에 존재한다고 해서 모든 의존성이 애플리케이션에서 실행되는 것은 아니다. - Java, JavaScript/TypeScript, Python 프로젝트에서는 코드가 취약 패키지를 직접 `import` 또는 `require`하는지 확인한다. - 취약점별로 도달 가능성(reachability) 상태를 표시해 다음을 구분한다. - 애플리케이션 코드가 실제로 사용하는 취약 의존성 - 전이적으로 포함됐지만 코드에서 참조되지 않는 의존성 - 개발팀은 실제 노출 가능성이 높은 취약점에 우선 대응하고, 사용되지 않는 패키지의 문제는 상대적으로 낮은 우선순위로 관리할 수 있다. ## 지속적인 취약점 탐지 - 모든 머지 리퀘스트와 파이프라인 실행 시 의존성을 검사한다. - 새로운 보안 권고가 발표될 때도 분석기를 실행할 수 있다. - 개발이 중단된 프로젝트라도 운영 중이라면 새로운 취약점이 발생할 수 있으므로 지속적인 스캔이 중요하다. ## 지원되는 생태계와 파일 형식 - 이번 릴리스는 24개 이상의 패키지 생태계를 지원하며, 향후 지원 범위가 확대될 예정이다. - 패키지 관리자의 빌드 도구를 재현하기보다 lockfile과 의존성 그래프를 직접 분석하므로 새로운 언어와 파일 형식 지원을 추가하기 쉽다. - 지원되는 lockfile이나 의존성 그래프가 없으면 다음과 같은 매니페스트 파일을 분석한다. - `pom.xml` - `requirements.txt` - Gradle 빌드 파일 - 매니페스트 기반 분석은 직접 의존성만 확인하고 전이 의존성은 파악하지 못할 수 있어, 전체적인 분석 정확도와 범위는 lockfile 기반 방식보다 낮다. - 따라서 가능한 경우 lockfile을 사용하는 것이 권장된다. ## 중앙 집중식 보안 정책 적용 - 프로젝트마다 `.gitlab-ci.yml`을 직접 수정하면 설정 누락, 구성 불일치, 감사 과정의 사각지대가 발생할 수 있다. - GitLab 19.0에서는 보안 구성 프로필을 사용해 의존성 스캐닝을 한 번 설정하고 여러 프로젝트에 적용할 수 있다. - 스캔 실행 정책과 파이프라인 실행 정책을 이용하면 그룹 또는 인스턴스 수준에서 보안 기준을 강제할 수 있다. - 수백 개의 프로젝트에도 각 저장소의 CI 설정을 개별적으로 수정하지 않고 동일한 의존성 검사 정책을 적용할 수 있다. ## 도입 대상과 마이그레이션 - SBOM 기반 의존성 스캐닝은 GitLab Ultimate 고객에게 제공된다. - GitLab.com에서 사용할 수 있으며, GitLab Dedicated와 self-managed 환경에는 표준 릴리스 일정에 따라 제공된다. - 기존 Gemnasium 분석기에서 이전할 때는 전환 기간 동안 두 분석기를 동시에 실행해 결과를 비교할 수 있다. - 신규 도입 팀은 GitLab의 설정 튜토리얼과 기술 문서를 통해 지원 언어, 구성 방식, 고급 옵션을 확인할 수 있다. 실무적으로는 먼저 lockfile을 저장소에 포함하고, SBOM 스캔을 머지 리퀘스트와 정기 파이프라인에 연결하는 것이 좋다. 이후 도달 가능성 정보를 기준으로 실제 코드가 사용하는 취약점부터 우선 처리하고, 조직 전체에는 그룹 또는 인스턴스 수준의 실행 정책으로 스캔을 강제하는 방식이 효과적이다.

원문 읽기(새 탭에서 열림)
gitlabDevSecOpsvulnerability-managementdependency-scanning+4
figma3분 읽기큐레이션 요약

이슈 16호: 프로세스를 믿으세요 | Figma 블로그

AI와 에이전트 도구의 발전으로 디자인과 개발 workflow가 빠르게 결합되고 있다. 하지만 제작 속도보다 중요한 것은 올바른 방향을 선택하고, 실제로 가치 있는 결과물을 출시하는 판단력이다. 이 글은 Figma의 MCP, Weave, 디자인-코드 왕복 작업 등을 통해 속도·맥락·완성도를 함께 높이는 방법을 소개한다. ## 빠른 제작보다 중요한 출시 판단 - AI는 제품 아이디어와 결과물을 빠르게 만들어 주지만, 잘못된 방향으로 빠르게 나아갈 위험도 키운다. - “충분히 괜찮은 결과물”에 머무르지 않고, 경쟁 제품과 차별화되는 결과를 만들려면 무엇을 출시할지 판단하는 능력이 필요하다. - Figma의 Chief Product Officer Yuhki Yamashita는 AI 시대의 제품팀이 터널 비전을 피하고, 사용자와 제품에 실질적인 가치를 주는 방향을 검증해야 한다고 설명한다. ## MCP로 디자인 맥락을 코드에 연결 - Model Context Protocol(MCP)은 에이전트형 코딩 도구가 Figma 파일과 디자인 시스템의 정보를 활용하도록 해준다. - 코드 작성 도구가 컴포넌트, 스타일, 레이아웃 등 디자인 의도를 직접 참고할 수 있어 디자인과 구현 사이의 불일치를 줄인다. - Figma MCP 서버는 디자인 결정이 코드가 작성되는 환경으로 전달되도록 하며, 결과적으로 실제 구현물이 원래 디자인에 더 가까워진다. - 디자이너와 개발자는 MCP가 제공하는 맥락을 더 구조화하고 명확하게 관리할수록 에이전트의 결과 품질을 높일 수 있다. ## Figma Weave를 활용한 시각 자산 제작 - Figma Weave는 영상, 사진, 일러스트레이션, 3D 효과 등 다양한 시각 작업에서 AI 이미지 생성과 정밀한 편집을 지원한다. - 단순히 프롬프트 하나로 이미지를 생성하는 것이 아니라, 시각적 언어와 제작 규칙을 반복적으로 적용하는 workflow가 중요하다. - 두 개의 참고 이미지만으로도 전체 자산 라이브러리를 확장할 수 있으며, 20개 이상의 workflow 템플릿이 이를 지원한다. - 주요 작업 방식은 다음과 같다. - 이미지 생성 - 기존 이미지 편집 - 프롬프트의 구조와 의도 조정 - 여러 자산에 일관된 스타일 적용 - 반복 가능한 시각 제작 프로세스 구축 ## 디자인과 코드의 왕복 작업 - 오늘날 팀은 캔버스에서 코드를 만들고, 코드에서 다시 캔버스로 돌아오는 방식으로 작업한다. - 디자인과 개발이 분리된 순차 과정이 아니라 서로 영향을 주고받는 반복 루프로 변하고 있다. - 실제 제품 상태를 디자인 캔버스로 가져오면 디자이너가 정적인 목업이 아니라 실제로 출시될 화면과 상호작용을 다듬을 수 있다. - 이러한 왕복 작업은 다음 효과를 준다. - 디자인과 코드 사이의 간극 축소 - 구현 결과에 대한 빠른 피드백 - 제품 상태와 예외 상황을 디자인에 반영 - 개발 속도를 유지하면서도 완성도 향상 ## 실무 workflow와 생산성 팁 - Figma MCP를 활용해 비디오 export flow의 문제를 점검하고, 실제 제품 상태를 캔버스에 반영하는 사례가 소개된다. - 팀이 빠르게 제작할수록 디자인과 코드가 서로 다른 방향으로 움직일 가능성도 커지므로, 두 환경을 연결하는 장치가 중요하다. - Figma Make를 자주 사용하는 사용자를 위해 크레딧을 효율적으로 사용하고 작업 속도를 높이는 7가지 팁도 제공된다. - AI 도구의 활용도는 단순 사용 횟수보다 프롬프트 품질, 맥락 제공, 반복 가능한 프로세스 설계에 좌우된다. AI 도구를 도입할 때는 생성 속도만 평가하지 말고, 디자인 맥락이 코드까지 전달되는지, 결과를 반복적으로 개선할 수 있는지, 실제 출시 가치가 있는지를 함께 검토하는 것이 좋다. Figma MCP와 Weave 같은 도구를 활용하되, 최종 방향과 품질 기준은 사람이 명확히 관리해야 한다.

원문 읽기(새 탭에서 열림)
FigmaAI모델 컨텍스트 프로토콜design-to-code+2
aws4분 읽기큐레이션 요약

AWS 주간 요약: 이스탄불의 AWS 로컬 영역, 오픈 소스 ExtendDB, Kiro Web 등 (2026년 5월 25일) | Amazon Web Services

AWS는 이번 주 지역 인프라 확장, 보안·AI 개발 편의성 강화, 오픈소스 생태계 확대에 집중했다. 특히 튀르키예 이스탄불 Local Zone은 데이터 주권과 낮은 지연 시간이 중요한 기업에 새로운 아키텍처 선택지를 제공하며, SageMaker의 OpenAI 호환 API와 ExtendDB는 기존 애플리케이션의 AWS 이전 및 데이터 계층 이식성을 높인다. 또한 Kiro Web, Secrets Manager Agent 개선, SDK 재시도 정책 변경 등 개발·운영 효율을 높이는 업데이트도 소개됐다. ## 이스탄불 AWS Local Zone 개설 - AWS가 튀르키예 이스탄불에 새로운 Local Zone을 개설했다. - AWS 리전의 인프라를 대도시와 사용자 가까이에 배치해 다음을 지원한다. - 단일 자릿수 밀리초 수준의 지연 시간 - 특정 국가 내 데이터 저장·처리 - 금융, 정부, 통신, 의료 분야의 데이터 레지던시 및 규정 준수 - 튀르키예 기업은 데이터를 국경 안에 저장하고 백업하면서, 지연 시간에 민감한 워크로드를 이스탄불에서 실행할 수 있다. - 이스탄불 Local Zone은 AWS 리전과 연결되므로, 자체 데이터센터를 운영하지 않고도 Local Zone과 리전을 결합한 하이브리드 애플리케이션을 구성할 수 있다. - Local Zone은 하드웨어, 전력, 네트워크, 운영 체계 측면에서 높은 수준의 인프라 투자가 필요한 서비스다. ## 보안 및 운영 업데이트 - **AWS Security Hub Extended** - 통합 가능한 파트너 보안 솔루션이 21개로 확대됐다. - 엔드포인트 보호, CSPM, 위협 인텔리전스 등 9개 보안 영역을 다룬다. - AWS 및 서드파티 도구의 보안 탐지 결과를 Security Hub에서 통합·우선순위화할 수 있다. - 별도 커스텀 통합을 줄여 엔터프라이즈 보안 운영을 단순화한다. - **Secrets Manager Agent 개선** - 애플리케이션 시작 시 시크릿을 미리 가져오는 pre-fetch 기능이 추가됐다. - 요청 시 시크릿을 조회하면서 발생하던 콜드 스타트와 지연 시간을 줄일 수 있다. - IAM 역할을 맡아 시크릿을 조회할 수 있어, 서로 다른 권한 경계를 가진 워크로드 간 에이전트 공유가 쉬워졌다. - **AWS SDK 및 CLI 재시도 동작 변경** - 일시적 오류와 API throttling에 더 효과적으로 대응하도록 기본 재시도 로직이 개선됐다. - 더 지능적인 백오프 전략이 적용된다. - 별도 설정 변경 없이 프로덕션 애플리케이션의 복원력을 높일 수 있다. ## AI 개발 및 모델 이전 편의성 - **SageMaker AI의 OpenAI 호환 API** - SageMaker 추론 엔드포인트를 OpenAI API와 호환되는 방식으로 호출할 수 있다. - 기존 OpenAI용 SDK나 애플리케이션 코드를 크게 수정하지 않고 SageMaker로 전환할 수 있다. - 애플리케이션에서 엔드포인트 주소만 변경해 여러 모델 제공자나 AWS 인프라를 활용할 수 있다. - OpenAI 기반 프로토타입을 비용과 확장성을 고려한 SageMaker 환경으로 이전하는 장벽을 낮춘다. - **Amazon Bedrock 프롬프트 최적화 및 마이그레이션 도구** - 프롬프트를 자동으로 조정해 모델 성능을 개선한다. - 서로 다른 파운데이션 모델 사이에서 프롬프트를 이전하는 작업을 지원한다. - 프로덕션 AI 서비스의 프롬프트 품질을 반복적으로 개선하는 데 유용하다. - **Kiro Web** - AWS의 AI 기반 개발 환경 Kiro를 웹 브라우저에서 사용할 수 있게 됐다. - 데스크톱 IDE 설치 없이 스펙 기반 개발, AI 채팅, 에이전트 기능을 이용할 수 있다. - 다른 컴퓨터에서 빠르게 검토하거나 프로토타입을 제작하고, 팀에 Kiro 워크플로를 소개하기 쉬워졌다. ## ExtendDB와 데이터 계층의 이식성 - AWS가 **ExtendDB**를 오픈소스로 공개했다. - DynamoDB API와 데이터 모델을 사용하면서, 실제 저장소는 다른 백엔드 시스템으로 구성할 수 있는 어댑터다. - 주요 활용 사례는 다음과 같다. - 로컬 개발 및 테스트 환경에서 실제 AWS 연결 없이 DynamoDB API 사용 - 저장소 계층을 직접 제어해야 하는 환경 - DynamoDB 호환 의미론을 유지하면서 특정 백엔드에 종속되지 않는 구조 - 데이터 접근 계층의 이식성을 높이고, 개발·테스트 환경 구축 비용을 줄이는 데 도움이 된다. ## 서버리스 로컬 개발 개선 - AWS SAM CLI가 CloudFormation Language Extensions를 로컬에서 지원한다. - 로컬 개발 및 테스트 과정에서 다음과 같은 CloudFormation 기능을 사용할 수 있다. - 트랜스폼 - 동적 참조 - 기타 CloudFormation 언어 확장 기능 - 로컬 환경과 실제 배포 환경 사이의 기능 차이를 줄인다. - SAM 기반 서버리스 애플리케이션에서 로컬 테스트로 재현하기 어려웠던 엣지 케이스를 더 안정적으로 검증할 수 있다. ## 컨테이너 이미지 및 생태계 변경 - Amazon ECR Public에서 Bitnami 컨테이너 이미지가 제거될 예정이다. - ECR Public에서 Bitnami 이미지를 가져오는 워크로드는 영향을 받을 수 있다. - Bitnami 자체 레지스트리에서는 이미지가 계속 제공된다. - 운영 중인 이미지 참조를 Bitnami 레지스트리로 변경하고, 제거 일정과 마이그레이션 절차를 확인해야 한다. ## 예정된 AWS 행사 - AWS Summit Amsterdam: 5월 27일 개최 - AWS Summit Bangkok: 5월 28일 개최 - AWS Summit Milan: 5월 28일 개최 예정 - 클라우드·AI 세션, 실습, 네트워킹 등을 제공하며 유럽과 동남아시아 개발자 및 고객을 대상으로 한다. 실무적으로는 ECR Public의 Bitnami 이미지 의존성을 먼저 점검하고, OpenAI 호환 SageMaker API와 Secrets Manager Agent pre-fetch를 기존 서비스에 적용할 수 있는지 검토하는 것이 좋다. 튀르키예에서 서비스를 운영하거나 데이터 레지던시가 중요한 경우에는 이스탄불 Local Zone을 활용한 리전-Local Zone 아키텍처도 고려할 만하다.

원문 읽기(새 탭에서 열림)
AIAWSamazon-bedrock서버리스+4
github3분 읽기큐레이션 요약

초보자를 위한 GitHub: VS Code에서 Git과 GitHub 시작하기

VS Code는 Git과 GitHub 기능을 통합해 편집기를 벗어나지 않고 저장소 초기화, 브랜치 관리, 변경 사항 검토, 커밋과 푸시를 수행하게 해준다. 이 글은 Git과 GitHub의 차이를 설명하고, VS Code에서 로컬 폴더를 Git 저장소로 만들고 변경 사항을 GitHub에 올리는 초보자용 흐름을 단계별로 안내한다. 이를 통해 도구 간 전환을 줄이고 개발 작업의 생산성을 높일 수 있다. ## Git, GitHub, VS Code의 관계 - **GitHub**는 코드 저장소를 호스팅하는 서비스다. - **Git**은 소스 코드의 변경 이력을 관리하는 프로그램이다. - Git은 명령줄뿐 아니라 VS Code 같은 편집기에서도 사용할 수 있다. - VS Code는 Git 기능을 내장하고 있어 GitHub와 연계된 버전 관리 작업을 편리하게 수행할 수 있다. - 실습을 위해 Git과 VS Code를 먼저 설치해야 한다. ## 폴더를 Git 저장소로 초기화 - VS Code에서 **Explorer → Open Folder**를 선택해 코드가 들어 있는 폴더를 연다. - 왼쪽의 **Source Control** 아이콘을 클릭한다. - **Initialize Repository**를 선택하면 해당 폴더에 로컬 Git 저장소가 생성된다. - 하단 왼쪽에서 현재 브랜치 이름을 확인할 수 있으며, 기본 브랜치는 보통 `main`이다. - Command Palette에서 **Git: Rename Branch**를 실행해 브랜치 이름을 변경할 수 있다. - macOS: `Shift-Command-P` - Windows/Linux: `Ctrl-Shift-P` ## 파일 추적과 스테이징 - 저장소를 초기화하면 기존 파일 옆에 `U` 표시가 나타난다. - `U`는 **Untracked**, 즉 아직 Git이 추적하지 않는 파일이라는 뜻이다. - 파일 옆의 `+` 버튼을 클릭하면 해당 파일이 스테이징된다. - **CHANGES** 옆의 `+` 버튼을 누르면 변경된 모든 파일을 한 번에 스테이징할 수 있다. - 스테이징된 파일은 `A`로 표시된다. - `A`는 파일이 추가되었지만 아직 커밋되거나 GitHub에 업로드되지는 않았다는 의미다. ## 커밋 생성 - Source Control 패널 상단의 입력란에 변경 내용을 설명하는 커밋 메시지를 작성한다. - 필요하면 Copilot 아이콘을 사용해 커밋 메시지를 생성할 수 있다. - **Commit** 버튼을 누르면 스테이징된 변경 사항이 로컬 Git 저장소에 기록된다. - 커밋은 변경 사항을 GitHub에 업로드하는 것과는 다르며, 이후 별도의 푸시 작업이 필요하다. ## 브랜치 생성과 전환 - 주요 기능을 개발할 때는 `main` 브랜치에서 직접 작업하기보다 별도 브랜치를 만드는 것이 권장된다. - Command Palette에서 **Git: Create Branch…**를 실행한다. - 예를 들어 `new-features` 같은 브랜치 이름을 입력한다. - VS Code는 새 브랜치를 생성한 뒤 자동으로 해당 브랜치로 전환한다. - 현재 브랜치는 화면 하단 왼쪽에서 확인할 수 있다. ## 코드 변경 사항 확인 VS Code의 편집기 여백인 **gutter**는 코드 변경 유형을 시각적으로 표시한다. - 초록색 선: 새로 추가된 코드 - 파란색 표시: 기존 코드가 수정된 부분 - 빨간색 화살표: 코드가 삭제된 부분 - 변경된 파일은 Source Control 패널의 **CHANGES** 아래에 표시된다. - 파일에 마우스를 올리면 다음 작업을 수행할 수 있다. - 파일 열기 - 변경 사항 폐기 - 변경 사항 스테이징 - CHANGES 영역에서도 여러 파일의 변경 사항을 한꺼번에 검토하거나 스테이징할 수 있다. ## diff로 변경 내용 비교 - Source Control 패널에서 파일 이름을 클릭하면 변경 전후를 나란히 비교하는 diff 화면이 열린다. - diff 화면에서는 어떤 코드가 추가·수정·삭제되었는지 확인할 수 있다. - 오른쪽 위의 `…` 메뉴에서 **Inline View**를 선택하면 변경 전후 내용을 하나의 화면에서 볼 수 있다. - Inline View에서는 diff 화면 안에서 직접 코드를 수정할 수도 있다. ## 실용적인 작업 흐름 - VS Code에서 폴더를 연다. - Git 저장소를 초기화한다. - 기능별 브랜치를 만든다. - 코드를 수정하고 Source Control에서 변경 사항을 검토한다. - 필요한 파일을 스테이징한다. - 의미 있는 커밋 메시지와 함께 커밋한다. - 이후 변경 사항을 GitHub에 반영하려면 푸시 작업을 수행한다. 이 글은 제공된 내용 기준으로 diff 확인 단계 이후에서 본문이 중단되어 있으며, GitHub 원격 저장소 연결과 실제 푸시 절차는 포함되어 있지 않다.

원문 읽기(새 탭에서 열림)
githubGitversion-controlvisual-studio-code+3
github4분 읽기큐레이션 요약

GitHub, Gartner® 매직 쿼드런트™ 엔터프라이즈 AI 코딩 에이전트 부문에서 3년 연속 리더로 선정

코드 생성이 쉬워지면서 소프트웨어 개발의 병목은 코드 작성에서 리뷰·보안·거버넌스·배포로 이동했으며, GitHub는 이를 해결하려면 소프트웨어 개발 생명주기(SDLC) 전반에 AI 에이전트가 필요하다고 주장합니다. GitHub Copilot은 이슈 처리부터 코드 리뷰와 배포까지 지원하는 에이전트형 기능을 확장하고 있으며, Gartner의 2026년 보고서에서 3년 연속 ‘Leader’로 선정됐습니다. GitHub는 특히 실행 역량, 네이티브 통합, 보안·거버넌스 기능에서 강점을 보였다고 설명합니다. ## 코드 생성에서 소프트웨어 결과물 조율로 - 개발자는 더 이상 Copilot에 단순히 함수 작성을 요청하는 데 그치지 않고, 이슈를 에이전트에 할당한 뒤 작업을 맡길 수 있습니다. - 에이전트는 코드 작성뿐 아니라 관련 작업을 수행하고, 개발자는 결과를 검토·수정·승인하는 역할에 집중합니다. - Gartner는 2028년 비동기 AI 코딩 에이전트가 소프트웨어 엔지니어링 팀 생산성을 30~50% 향상할 것으로 전망했습니다. - 이는 2025년 AI 코드 보조 도구가 제공할 것으로 예상된 0~20%의 생산성 향상보다 큰 폭입니다. - 생산성 향상을 실현하려면 코드 생성뿐 아니라 계획, 테스트, 리뷰, 보안, 거버넌스까지 AI가 관여해야 한다는 것이 GitHub의 주장입니다. ## 엔터프라이즈 규모로 확산되는 GitHub Copilot - GitHub Copilot은 현재 14만 개 조직에서 사용되며, 전년 대비 사용자·조직 기반이 거의 3배로 증가했습니다. - 전체 성장률은 전년 대비 100%를 넘었고, 많은 사용자가 여러 AI 모델을 함께 활용하고 있습니다. - GitHub Copilot CLI 사용량도 전월 대비 거의 두 배씩 증가하고 있다고 설명합니다. - GitHub는 이러한 지표가 기업들이 Copilot을 단순 코드 자동완성 도구가 아니라 복합적인 개발 플랫폼으로 활용하고 있음을 보여준다고 평가합니다. ## Gartner ‘Leader’ 선정과 평가 - Gartner는 2026년 Enterprise AI Coding Agents Magic Quadrant에서 12개 공급업체를 평가했습니다. - 평가는 크게 다음 두 기준을 바탕으로 이뤄졌습니다. - 실행 역량(Ability to Execute) - 비전의 완성도(Completeness of Vision) - GitHub는 실행 역량 부문에서 가장 높은 위치에 배치됐으며, 3년 연속 Leader로 선정됐습니다. - Gartner가 말하는 Leader는 다음 특징을 갖춘 업체입니다. - 강력한 제품 실행력과 시장 방향을 형성할 수 있는 명확한 비전 - 편집기 내부를 넘어 계획·테스트·코드 리뷰·워크플로 자동화까지 지원하는 에이전트 기능 - 개발자와 기업 모두에게서 확보한 시장 반응 - 확장되는 생태계와 지속 가능한 비즈니스 모델 - 엔터프라이즈급 보안, 거버넌스, 운영 성숙도 ## GitHub Copilot의 차별화 요소 - **모델과 사용 환경의 선택권** - 여러 공급업체의 AI 모델을 지원합니다. - 코드 에디터, IDE, CLI뿐 아니라 GitHub 웹·데스크톱·모바일 앱에서도 Copilot을 사용할 수 있습니다. - **SDLC 전반의 통합** - 개발 시작 단계의 코드 작성에만 머물지 않습니다. - 이슈, 풀 리퀘스트, 코드 리뷰, GitHub Actions 등 개발 및 배포 과정 곳곳에 Copilot을 통합합니다. - **기업용 통제 기능** - 조직이 AI 사용 현황을 관찰하고 감사할 수 있도록 지원합니다. - AI가 생성하거나 수정한 코드의 사용을 보안 정책과 거버넌스 체계 안에서 관리할 수 있도록 합니다. - GitHub는 이러한 기능이 GitHub 플랫폼 내부의 네이티브 통합과 결합되어 기업 환경에서 AI 개발을 관리하기에 유리하다고 주장합니다. ## 앞으로의 계획 - 개발자가 사용하는 모든 GitHub 표면에서 에이전트형 워크플로를 더욱 확장할 예정입니다. - 여러 모델을 더 폭넓게 제공하고, 작업에 적합한 모델을 자동으로 선택하는 지능형 라우팅을 강화할 계획입니다. - 단순히 코드가 어떻게 생성되는지만이 아니라 GitHub에서 소프트웨어가 실제로 어떻게 개발·검토·배포되는지에 기반해 Copilot 성능을 개선하려 합니다. - 핵심 방향은 개발 생명주기 전체를 연결하는 AI-native 소프트웨어 개발 환경을 구축하는 것입니다. Gartner의 Leader 선정은 GitHub Copilot의 엔터프라이즈 경쟁력을 보여주는 지표지만, Gartner도 특정 업체나 최고 등급 업체만을 선택하라고 권고하지 않는다고 명시합니다. 따라서 도입을 검토할 때는 모델 선택권, 기존 저장소·CI/CD와의 통합성, 보안 및 감사 기능, 실제 팀의 리뷰·배포 프로세스 개선 효과를 함께 평가하는 것이 바람직합니다.

원문 읽기(새 탭에서 열림)
github-copilot코드 리뷰github-copilot-cliagentic-workflows+4
grammarly4분 읽기큐레이션 요약

연봉 협상 이메일 작성법: 형식과 예시

연봉 협상 이메일은 채용 제안을 받은 뒤, 수락하기 전에 보상 조건을 조정하기 위해 보내는 서면 반대 제안이다. 시장 급여 데이터와 정량화된 성과를 근거로 구체적인 금액을 제시하되, 요구가 아닌 협력적인 논의로 표현하는 것이 핵심이다. 기본급이 어렵다면 보너스, 휴가, 원격근무, 조기 연봉 재검토 등 전체 보상 패키지를 협상할 수 있다. ## 연봉 협상 이메일의 역할 - 채용 제안 이후 급여나 보상 조건의 변경을 논의하는 이메일이다. - 구두 협상보다 생각을 정리하고 근거와 성과를 명확히 제시하기 쉽다. - 채용 담당자나 관리자 내부에서 검토·공유할 수 있는 기록으로 남는다. - 개인적인 경제 사정보다는 직무에 제공할 가치와 시장 수준을 중심으로 작성해야 한다. ## 이메일 작성 전 준비 ### 시장 급여 조사 - 동일한 직무, 경력 수준, 지역을 기준으로 급여를 조사한다. - Glassdoor: 특정 회사의 급여 정보 확인 - LinkedIn Salary: 산업·지역별 직무 비교 - Payscale: 경력과 기술 수준에 따른 세부 정보 - 미국 노동통계국(BLS): 규제 산업의 신뢰할 수 있는 기준 - 협상 금액은 개인적으로 필요한 금액이 아니라 시장이 해당 역할에 지급하는 수준을 반영해야 한다. ### 목표 금액 설정 - 조사한 시장 범위를 바탕으로 구체적인 금액 또는 좁은 범위를 정한다. - 협상 여지를 두기 위해 자신이 수용할 수 있는 범위의 상단에 가깝게 제시한다. - 예를 들어 제안이 8만 5천 달러이고 시장 범위가 9만 5천~10만 달러라면, 9만 7천~10만 달러를 제안할 수 있다. ### 성과 기반 가치 제시 - 자신을 뒷받침할 성과를 2~3개 선정한다. - “경험이 많고 더 받아야 한다”처럼 추상적인 표현은 피한다. - 온보딩 기간 30% 단축, 고객 유지율 향상처럼 결과를 수치로 표현한다. - 성과가 회사의 매출, 효율성, 비용 절감, 고객 유지 등 어떤 사업적 효과를 만들었는지 연결한다. ## 전체 보상 패키지 협상 기본급이 고정되어 있거나 목표에 가까운 경우에는 다른 조건을 협상할 수 있다. - 사이닝 보너스 - 추가 유급휴가(PTO) - 원격 또는 하이브리드 근무 - 조기 성과 평가 및 연봉 재검토 - 교육·전문성 개발 예산 기본급 외 조건은 회사가 상대적으로 유연하게 조정할 수 있으며, 전체 보상 가치를 높이는 데 도움이 된다. ## 이메일 작성 단계 ### 명확한 제목과 도입 - 제목은 이메일 목적이 즉시 드러나게 작성한다. - `Job Offer – [이름] – [직무명]` - `Compensation discussion – [이름]` - 모호하거나 지나치게 캐주얼한 제목은 피한다. - 제안에 감사하고 해당 직무와 회사에 대한 기대를 1~2문장으로 표현한다. - 불필요한 인사말보다 본론으로 빠르게 진입한다. ### 시장 데이터와 경력으로 근거 제시 - 먼저 해당 직무의 시장 급여 범위를 제시한다. - 이어서 자신의 핵심 기술, 책임 범위, 구체적인 성과를 연결한다. - 예시는 다음과 같은 구조다. - “유사 직무의 시장 범위는 X~Y달러입니다.” - “저의 관련 경험과 특정 성과를 고려하면 Z달러에 가까운 급여가 제공하는 가치에 부합한다고 생각합니다.” - 임대료, 생활비, 개인 부채 등 개인 재정 사정은 협상 근거로 사용하지 않는다. ### 반대 제안 금액을 명확히 제시 - “조금 더 높은 금액” 대신 구체적인 숫자나 좁은 범위를 말한다. - “기본급을 X달러 수준으로 논의할 수 있을까요?”처럼 협의의 형태로 표현한다. - 명확한 숫자는 자신감을 보여 주고 채용 담당자가 내부적으로 검토하기 쉽게 만든다. - “더 받을 수 있을까요?”처럼 지나치게 모호한 표현은 피한다. ### 협력적인 마무리 - 해당 직무에 대한 관심을 다시 강조한다. - 보상 패키지를 추가로 논의하고 싶다는 의사를 밝힌다. - 양측에 적합한 합의를 찾을 수 있다는 긍정적이고 열린 태도를 유지한다. - 압박하거나 최종 통보처럼 들리는 표현은 피한다. ## 보내는 시점 - 정식 서면 채용 제안을 받은 뒤, 수락하거나 서명하기 전에 보낸다. - 구두로만 제안을 받았다면 서면 제안을 기다린 뒤 협상한다. - 서면 제안을 받은 후에는 대체로 1~2영업일 안에 답하는 것이 적절하다. - 이 시점은 회사도 협상을 예상하고 제안 조건을 조정할 가능성이 가장 높은 때다. ## 실용적인 추천 시장 범위를 먼저 조사하고, 회사에 미친 영향을 보여 주는 정량적 성과 2~3개를 준비한 뒤 구체적인 목표 금액을 제시하는 것이 좋다. 기본급이 조정되지 않으면 보너스, 휴가, 근무 방식, 조기 연봉 재검토 등 전체 보상 조건으로 협상 범위를 넓혀라.

원문 읽기(새 탭에서 열림)
grammarlyprofessional-communicationsalary-negotiationcompensation+2
grammarly3분 읽기큐레이션 요약

불합격 이메일에 답장하는 방법과 예시

채용 거절 이메일에 답장하는 것은 결과를 바꾸기보다 전문성을 보여주고 향후 관계를 유지하는 데 의미가 있습니다. 결정에 감사하고, 면접에서 논의한 구체적인 내용을 언급하며, 필요하다면 부담 없는 피드백 요청이나 향후 기회에 대한 관심을 표현하는 것이 좋습니다. 감정을 정리한 뒤 24~48시간 안에 짧고 정중하게 회신하되, 자신을 다시 설득하거나 실망을 장황하게 설명하는 것은 피해야 합니다. ## 채용 거절 이메일의 의미 - 지원자에게 채용 절차를 더 진행하지 않겠다는 사실을 알리는 이메일입니다. - 지원서 제출 후, 초기 심사 후, 면접 후 등 다양한 단계에서 발송됩니다. - 자동화된 짧은 메시지일 수도 있고, 채용 담당자나 면접관의 개인적인 평가가 담긴 메시지일 수도 있습니다. - 답장 방식은 회사와의 상호작용 수준, 거절 시점, 향후 관계 유지 의사에 따라 달라집니다. ## 거절 결정 인정하기 - 첫 문장에서 채용 결과를 직접 인정합니다. - 예: “결정 사항을 알려주셔서 감사합니다.” - “후속 조치를 위해 연락드립니다”처럼 결과에 이의를 제기하는 듯한 모호한 표현은 피하는 것이 좋습니다. - 결과를 받아들이는 태도는 방어적이지 않고 자신감 있게 보여야 합니다. ## 감사의 뜻을 구체적으로 표현하기 - 면접 기회와 채용 담당자의 시간을 정중하게 감사히 표현합니다. - 단순한 “검토해주셔서 감사합니다”보다 면접에서 논의한 프로젝트, 팀의 목표, 회사의 업무 방식 등 구체적인 내용을 한 가지 언급하면 진정성이 높아집니다. - 개인적인 경험을 짧게 포함하면 답장이 더 기억에 남을 수 있습니다. ## 선택적인 피드백 요청 - 여러 차례 면접을 진행했거나 실질적인 대화를 나눈 경우 피드백을 요청할 수 있습니다. - 예: “가능하시다면 향후 지원을 개선하는 데 도움이 될 만한 피드백을 부탁드립니다.” - 답변을 강요하지 않도록 “가능하시다면”, “부담이 되지 않는다면”처럼 선택권을 남겨야 합니다. - 초기 단계의 자동 거절에는 피드백 요청을 생략하는 편이 적절합니다. ## 향후 기회를 열어두는 표현 - 회사에 실제로 계속 관심이 있다면 향후 유사한 포지션에 고려해달라고 표현할 수 있습니다. - 예: “향후 제 경력과 맞는 기회가 있다면 다시 고려해주시면 감사하겠습니다.” - 더 이상 관심이 없다면 회사와 팀의 앞날을 기원하는 짧은 인사만으로 충분합니다. - 답장의 목적은 채용 결정을 다시 설득하는 것이 아니라 긍정적인 인상을 남기는 것입니다. ## 답장 시점과 형식 - 결과를 받은 뒤 몇 시간 동안 감정을 정리하고, 24~48시간 안에 회신하는 것이 권장됩니다. - 즉시 반응하기보다 차분한 문장을 작성할 시간을 갖는 것이 좋습니다. - 가능하면 기존 이메일 스레드에 답장합니다. - 전체 분량은 짧은 두세 문단 정도가 적절합니다. - “Best regards”, “Sincerely”와 같은 전문적인 맺음말을 사용합니다. - 자동 발송이 분명하거나 회사와 거의 상호작용하지 않았다면 답장하지 않아도 됩니다. ## 상황별 답장 방식 - **초기 단계에서 거절된 경우** - 감사와 향후 유사한 기회에 대한 고려 요청만 간단히 작성합니다. - 접촉이 적었던 만큼 긴 답장은 오히려 과도해 보일 수 있습니다. - **면접 후 거절된 경우** - 면접에서 만난 팀과 논의한 특정 프로젝트나 주제를 언급합니다. - 회사에 대한 지속적인 관심과 향후 기회에 대한 의사를 표현할 수 있습니다. - **피드백을 원하는 경우** - 실질적인 면접 과정을 거친 지원자에게 적합합니다. - 요청은 짧고 선택적으로 제시하며, 답변이 없어도 괜찮다는 분위기를 유지합니다. ## 피해야 할 실수 - 자신을 다시 채용하도록 장황하게 설득하지 않습니다. - 실망감, 억울함, 결과에 대한 불만을 길게 설명하지 않습니다. - 거절 결정을 번복해달라고 직접 요구하지 않습니다. - 모든 회사에 동일한 문구를 보내기보다 면접에서 나온 구체적인 내용을 한 가지씩 반영합니다. - 지나치게 긴 이메일로 채용 담당자에게 부담을 주지 않습니다. 실용적으로는 감사, 구체적인 언급, 향후 기회 또는 선택적 피드백 요청, 정중한 마무리의 네 요소만 담아 2~3개 문단으로 작성하면 됩니다.

원문 읽기(새 탭에서 열림)
professional-communicationemail-writingemail-etiquettejob-search+1
line4분 읽기큐레이션 요약

ODW #7: 세 가지 방법으로 토큰 소비량 40% 절감! ADK를 이용한 컨텍스트 엔지니어링

LY Corporation의 워크숍은 AI 에이전트의 비용 증가와 응답 정확도 저하를 해결하기 위해 컨텍스트 엔지니어링을 소개한다. 핵심은 LLM에 전달하는 프롬프트, 도구 정의, 대화 이력, 외부 데이터를 무조건 많이 제공하는 것이 아니라 작업에 필요한 고품질 정보만 적절한 형태로 선별하는 것이다. ADK의 구조화 스키마, AgentTool, MCP 도구 필터링을 활용하면 토큰 사용량을 줄이면서도 장시간 실행 에이전트의 정확도를 개선할 수 있다. ## 사내 AI 활용 확대에 따른 문제 - Claude Code, Cline, ADK 등 AI 도구의 사용자가 늘면서 토큰 소비량이 급증했다. - 프롬프트에 명시한 지시를 AI가 무시하거나 중요한 정보를 누락하는 문제가 발생했다. - 대화가 길어질수록 AI가 이전 맥락에 묻혀 엉뚱한 답변을 생성하기도 했다. - 주요 원인은 LLM에 전달되는 컨텍스트를 체계적으로 관리하지 않았기 때문이다. - 토큰 증가 요인에는 다음이 포함된다. - AI 사용 인구 증가 - 원하는 결과를 얻기 위한 반복 작업 - 싱글 에이전트에서 멀티 에이전트로의 확장 - 단발성 작업에서 장시간 실행 작업으로의 변화 - MCP 도구 정의 자체가 차지하는 토큰 - 컨텍스트 최적화 기법의 확산 부족 ## 컨텍스트 부패와 토큰 관리 - LLM 사용 비용은 입력과 출력에 사용된 총 토큰 수를 기준으로 산정된다. - 장시간 실행되는 에이전트에서는 대화 이력과 중간 결과가 계속 축적된다. - 현재 작업과 관계없는 정보가 컨텍스트에 남으면 중요한 신호가 노이즈에 묻힌다. - 이로 인해 컨텍스트 윈도 압박, 관련성 저하, 응답 정확도 하락이 발생한다. - 해결책은 필요한 정보만 추려 LLM에 전달하는 것이다. ## 컨텍스트 엔지니어링의 개념과 원칙 컨텍스트 엔지니어링은 에이전트가 사용하는 모든 문맥 정보를 설계하고 최적화하는 방법이다. - 관리 대상은 세 가지로 나뉜다. - **정적 컨텍스트**: 시스템 프롬프트, 도구 정의 - **동적 컨텍스트**: 사용자 메시지, 대화 이력, RAG 데이터 - **장기 컨텍스트**: 장시간 실행 중 축적되는 정보와 세션 상태 - 핵심 원칙은 “고품질 신호를 가진 최소한의 토큰 집합”을 찾는 것이다. - 정보를 너무 적게 주면 AI가 추측에 의존한다. - 정보를 지나치게 많이 주면 비용이 증가하고 핵심 정보가 묻힌다. - 따라서 작업에 필요한 수준으로 구체적이면서도 불필요한 정보는 제거해야 한다. - 프롬프트 엔지니어링이 지시문 작성에 초점을 둔다면, 컨텍스트 엔지니어링은 프롬프트뿐 아니라 도구, 데이터, 이력, 상태까지 포함해 전체 입력 환경을 최적화한다. ## ADK를 활용하는 이유 Google의 오픈소스 AI 에이전트 프레임워크인 ADK는 컨텍스트 엔지니어링을 팀 단위로 적용하기에 적합하다. - 개인의 CLI 숙련도에 의존하지 않고 팀의 지식을 에이전트 설계에 반영할 수 있다. - UI, API 서버, 평가 기능, 멀티 에이전트 구성을 제공한다. - 에이전트를 조합하고 도구처럼 호출할 수 있어 컨텍스트를 분리하기 쉽다. - 컨텍스트 엔지니어링을 위한 9개 핵심 컴포넌트를 조합해 사용할 수 있다. ## 주요 ADK 컴포넌트 실습에서는 다음 세 가지 기능을 중심으로 설명한다. - **Structuring Data** - 입력과 출력을 특정 JSON 스키마로 강제한다. - 에이전트 간 데이터 전달 형식을 명확히 한다. - 불필요한 자연어 설명을 줄여 토큰 사용량을 절감한다. - **AgentTool** - 다른 에이전트를 함수나 도구처럼 호출한다. - 하위 에이전트의 내부 도구와 중간 컨텍스트를 호출자에게 노출하지 않는다. - 최종 결과만 반환해 상위 에이전트의 컨텍스트 누적을 막는다. - **MCP Toolset의 `tool_filter`** - MCP 서버가 제공하는 도구 중 필요한 도구만 선택한다. - 예를 들어 Jira 티켓 검색에는 `jira_search`, 상세 조회에는 `jira_get_issue`만 허용할 수 있다. - 불필요한 도구 정의를 제거해 토큰 비용과 LLM의 판단 부담을 줄인다. ## Jira 주간 보고서 에이전트: v1의 문제 v1은 하나의 에이전트가 Jira 티켓 검색, 개별 티켓 상세 조회, 분석, 보고서 작성을 모두 수행하는 구조다. - 단일 에이전트에 Jira 관련 도구를 모두 제공한다. - 티켓마다 상세 정보를 가져와 같은 컨텍스트에 계속 축적한다. - 티켓 수가 증가할수록 컨텍스트가 커지고 컨텍스트 부패가 발생한다. - 여러 도구의 정의와 중간 결과가 함께 전달되어 토큰 사용량이 커진다. - 장시간 작업에서 중요한 티켓 정보와 불필요한 이전 정보가 섞일 가능성이 높다. ## Jira 주간 보고서 에이전트: v2의 개선 v2는 역할을 분리한 2-에이전트 구조로 변경했다. - **루트 에이전트** - Jira 티켓 목록을 검색한다. - 개별 티켓 분석 에이전트를 호출한다. - 각 분석 결과를 Markdown 표 형태의 주간 보고서로 집계한다. - **개별 티켓 분석 에이전트** - 하나의 Jira 티켓만 담당한다. - `issue_key`를 입력으로 받고 `report`를 구조화된 출력으로 반환한다. - Jira 상세 조회 도구인 `jira_get_issue`만 사용할 수 있다. - 사실만 포함하고 추측은 금지하도록 지시된다. - `AgentTool`을 통해 하위 에이전트의 내부 처리 과정은 루트 에이전트에 노출하지 않는다. - `input_schema`와 `output_schema`로 에이전트 간 데이터 형식을 제한한다. - `tool_filter`로 각 에이전트가 실제로 필요한 MCP 도구만 사용하게 한다. - 결과적으로 티켓별 상세 분석 컨텍스트가 루트 에이전트에 불필요하게 누적되는 것을 줄인다. AI 에이전트를 설계할 때는 프롬프트를 길게 작성하는 것보다 어떤 정보를 언제, 어떤 형식으로 전달할지 먼저 설계하는 것이 중요하다. 특히 작업을 하위 에이전트로 분리하고, 입력·출력 스키마와 도구 필터를 적용하면 비용과 정확도를 함께 개선할 수 있다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델AI 에이전트쿠버네티스모델 컨텍스트 프로토콜+3
toss3분 읽기큐레이션 요약

Cross Functional 기술 문제 풀기 위한 역량 성장 Tip

조직이 커질수록 각 팀이 맡은 일은 잘 수행해도 팀과 팀 사이의 공백이 커지며, Cross Functional 기술 문제가 발생합니다. 이런 문제는 회의·보고·리스크 관리 같은 조율만으로 해결되지 않으며, 문제를 재정의하고 구조화해 실제 실행으로 전환해야 합니다. 토스의 TPM은 공식 권한보다 문제 정의력, 구조화 능력, 영향력과 실행력을 바탕으로 복합적인 문제를 끝까지 해결하는 역할을 합니다. ## 조직 성장과 함께 커지는 경계의 문제 - 팀별 책임과 전문성이 높아질수록 팀의 경계 밖 문제가 늘어납니다. - 인프라, 제품, 데이터, 보안, 운영 이슈가 서로 얽혀 한 조직만으로 해결하기 어렵습니다. - 단기 대응과 장기 구조 개선이 충돌합니다. - 중요하지만 공식 Owner가 없는 회색지대가 생깁니다. - 각 팀이 최선을 다해도 전체 최적화가 이뤄지지 않을 수 있습니다. ## 조율만으로 해결되지 않는 이유 - 회의를 더 자주 열고 진행 상황을 공유해도 문제의 본질은 남을 수 있습니다. - 리스크 목록이나 일정표에는 결정 구조의 공백, 모호한 책임, 충돌하는 우선순위가 잘 드러나지 않습니다. - 핵심은 관리의 밀도를 높이는 것이 아니라, 문제를 해결 가능한 구조로 바꾸는 것입니다. - 먼저 “진짜 병목은 무엇인가”, “누가 빠져 있는가”, “어떤 결정이 비어 있는가”를 물어야 합니다. ## TPM에게 필요한 핵심 역량 ### 문제를 다시 정의하는 힘 - 일정 지연이나 협업 속도 저하 같은 표면적 현상에 머물지 않습니다. - 지연의 원인, 비어 있는 의사결정, 불명확한 Owner, 반복되는 조직 구조의 문제를 찾아냅니다. - 증상을 관리하는 대신 해결해야 할 문제 자체를 다시 설정합니다. ### 모호함을 구조로 바꾸는 힘 - 무엇을 결정해야 하는지 명확히 합니다. - 가능한 선택지와 책임자를 정리합니다. - 문제를 실행 가능한 단위로 쪼개고 우선순위와 순서를 만듭니다. - 복잡한 문제를 여러 사람이 함께 다룰 수 있는 단순한 구조로 바꿉니다. ### 전략적 판단력 - 일시적인 이슈인지 반복될 구조적 문제인지 구분합니다. - 팀 내부 해결이 가능한지, 조직 차원의 개입이 필요한지 판단합니다. - 지금 개입해야 하는 문제와 관찰해도 되는 문제를 나눕니다. - 해결했을 때 조직의 실행 수준 자체를 높일 수 있는 문제에 집중합니다. ### 실행으로 전환하는 힘 - 실제로 움직여야 할 사람을 명확히 합니다. - 선행 결정과 Blocker를 정리합니다. - 모호한 논의를 결정 포인트로 바꾸고 담당자가 결론을 내리게 합니다. - 합의된 액션 플랜을 실제 행동으로 연결합니다. ### 공식 권한 없이 영향력을 만드는 힘 - 직함이나 지시가 아니라 신뢰와 판단력으로 참여를 이끌어냅니다. - 각 팀의 맥락과 제약을 이해하고 서로 다른 언어를 번역합니다. - 필요한 경우 불편한 대화를 열어 우선순위와 책임 문제를 드러냅니다. ### 사람과 구조를 함께 보는 시각 - 기술 문제가 역할 정의, 팀 구조, 운영 방식에서 비롯될 수 있음을 고려합니다. - 프로세스 개선만으로 충분한지, 역할 재설계나 리더십 개입이 필요한지 판단합니다. - 사람과 시스템을 분리하지 않고 함께 바라봅니다. ## 자율성이 낮은 조직에서의 단계적 접근 - **작은 문제부터 해결하기:** 분명한 병목 하나를 구조적으로 해결해 신뢰를 쌓습니다. - **조율에 구조화를 더하기:** 회의를 진행하면서 결정 사항, 의존성, 병목을 함께 드러냅니다. - **작은 범위에서 Owner 명확히 하기:** 담당자, 의사결정권자, 완료 기준을 구체화합니다. - **사례로 역할 증명하기:** 역할을 설명하기보다 Owner 없는 문제를 해결하고 반복 병목을 줄인 실적을 만듭니다. ## 주의할 점 - 조율은 중요하지만 목적이 아니라 문제 해결을 위한 수단이어야 합니다. - 공식 권한이 없어도 신뢰와 구조화 능력으로 영향력을 만들 수 있습니다. - 조직에 이상적인 역할 모델을 한 번에 강요하기보다 현재 환경에서 작동하는 작은 성공 사례부터 만들어야 합니다. 결국 Cross Functional 기술 문제를 풀기 위해서는 일정과 회의부터 관리하기보다 문제를 다시 정의해야 합니다. 진짜 병목, 누락된 사람과 책임, 실행을 가로막는 구조를 찾아 작은 범위에서부터 바꾸는 것이 실용적인 출발점입니다.

원문 읽기(새 탭에서 열림)
cross-functional-collaborationproblem-solvingorganizational-designtechnical-program-management+2
figma3분 읽기큐레이션 요약

Figma Make 크레딧을 더 효율적으로 사용하는 7가지 팁 | Figma 블로그

Figma Make에서 크레딧을 효율적으로 사용하려면 긴 프롬프트를 반복하기보다 초기 설계와 변경 범위를 명확히 해야 한다. 첫 프롬프트에 프로젝트의 목표·맥락·제약·완료 기준을 충분히 담고, 이후에는 필요한 부분만 구체적으로 수정하는 방식이 효과적이다. 단순한 시각 변경이나 데이터 수정은 AI에 다시 요청하기보다 Edit 도구나 소스 코드 직접 편집을 활용하는 것이 좋다. ## 초기 프롬프트에 프로젝트의 기준점 담기 - 첫 프롬프트는 단순한 요청이 아니라 프로젝트의 전체 브리프처럼 작성한다. - 다음 내용을 구체적으로 포함한다. - 프로젝트의 목표 - 사용 맥락 - 필요한 UI 요소와 동작 - 기술적·기능적 제약 - 최종적으로 “완료”라고 판단할 기준 - 초기 구조가 탄탄할수록 이후에 잘못된 구현을 되돌리는 비용과 크레딧 사용량이 줄어든다. - 대규모 프로젝트는 다음 순서로 나누는 것이 효과적이다. 1. 화면과 컴포넌트의 전체 구조 설계 2. 기능과 상호작용 구현 3. 콘텐츠 입력 및 시각적 세부 조정 - 구조는 프로젝트가 진행될수록 변경하기 어려우므로 가장 먼저 확정하는 것이 좋다. ## 후속 프롬프트는 변경 범위를 좁혀 작성하기 - 첫 프롬프트 이후의 요청은 전체 프로젝트를 다시 설명하는 것이 아니라 변경 사항(delta)을 전달하는 방식으로 작성한다. - 좋은 후속 프롬프트는 다음 세 가지를 포함한다. - 무엇을 바꿀지 - 어떻게 바꿀지 - 무엇은 그대로 유지할지 - “다시 해줘”, “뭔가 이상해”처럼 모호한 요청보다 다음처럼 대상과 위치를 명시한다. - “캘린더 컴포넌트를 수정해줘” - “이 화면에 새로운 상태를 추가해줘” - “`tokens.ts` 파일을 수정해줘” - 서로 관련된 수정이 같은 컴포넌트나 로직에 집중되어 있다면 한 번에 묶는 편이 효율적이다. - 반대로 관련 없는 변경을 하나의 프롬프트에 섞으면 Make가 의도를 해석하는 비용이 커지고 결과도 불안정해질 수 있다. - 특정 파일, 컴포넌트, 상태를 지정하면 Make가 탐색해야 할 범위가 줄어들어 크레딧을 절약할 수 있다. ## 작은 시각 변경은 Edit 도구로 처리하기 - 간격 조정, 요소 삭제, 텍스트 변경처럼 결과가 거의 완성된 상태에서의 작은 수정은 AI 프롬프트보다 Edit 도구가 빠르다. - 이런 작업을 매번 프롬프트로 요청하면 새로운 설계 문제를 해결하는 것이 아니라 기존 결과를 조금씩 조정하는 데 크레딧을 소비하게 된다. - 직접 편집이 적합한 예시는 다음과 같다. - 여백이나 간격 변경 - 특정 UI 요소 제거 - 문구 수정 - 이미 구현된 컴포넌트의 단순한 스타일 조정 ## 소스 코드에서 동적 콘텐츠 수정하기 - 미리보기 화면에서 직접 수정하기 어려운 동적 콘텐츠는 소스 코드에서 값을 변경하는 편이 효율적이다. - `Go to source`를 사용해 관련 코드로 이동한 뒤 실제 데이터가 정의된 부분을 수정한다. - 반복 컴포넌트 안의 텍스트나 같은 폴더의 목록에서 가져오는 데이터 변경에 특히 유용하다. - **⌘F** 단축키로 코드를 검색해 특정 태그나 콘텐츠를 빠르게 찾을 수 있다. - 우선 `App.tsx`를 확인하고, 해당 코드가 없다면 컴포넌트 폴더의 다른 `.tsx` 파일을 살펴보면 된다. ## 실용적인 작업 원칙 처음에는 프로젝트 구조와 제약을 충분히 설명하고, 이후 요청은 한 번에 하나의 명확한 변경에 집중하는 것이 좋다. 단순한 수정은 Edit 도구나 소스 코드에서 직접 처리하고, AI는 새로운 구조·기능·상호작용처럼 직접 구현하기 복잡한 작업에 사용하는 방식이 크레딧과 시간을 모두 절약한다.

원문 읽기(새 탭에서 열림)
사용자 경험ReactTypeScriptfigma-make+3
figma3분 읽기큐레이션 요약

누구나 만들 수 있을 때 중요한 것 | Figma 블로그

AI로 누구나 제품을 빠르게 만들 수 있는 시대에는 구현 속도보다 무엇을 만들지 정하는 방향성이 더 중요하다. 좋은 팀은 여러 가능성을 동시에 탐색하고, 실제에 가까운 프로토타입으로 비교한 뒤, 선택한 방향을 반복적으로 다듬어 자신만의 결과물로 만든다. 결국 경쟁력은 속도·방향·완성도를 함께 갖추는 데서 나온다. ## 속도보다 방향이 중요해진 이유 - 과거에는 아이디어를 실제 제품으로 구현하는 능력과 코딩 역량이 큰 차별점이었다. - AI와 새로운 제작 도구로 상상과 구현 사이의 간격이 거의 사라지면서, 빠르게 만드는 능력은 기본 조건이 되었다. - 빠른 실행은 잘못된 방향으로 달리는 문제를 가릴 수 있다. - 모두가 빠르게 만들 수 있다면 차별점은 “얼마나 빨리 만들었는가”가 아니라 “무엇을 만들 가치가 있다고 판단했는가”가 된다. ## 첫 아이디어에 매몰되는 문제 - 초보 빌더는 첫 아이디어를 선택한 뒤 개선과 반복에 집중하기 쉽다. - 이 과정은 출발점을 재검토하지 않는 **국소 최적화(hill-climbing)**와 비슷하다. - 초기 선택에 따라 이후 의사결정이 결정되는 경로 의존성이 생길 수 있다. - AI 에이전트는 사용자의 첫 요청을 빠르고 친절하게 발전시키지만, 더 나은 대안을 스스로 제시하거나 터널 비전을 깨뜨리지는 못할 수 있다. - 결과적으로 아이디어를 깊게 발전시키기는 하지만, 애초에 가장 좋은 아이디어였는지는 검증하지 못한다. ## 넓게 탐색하되 실제 경험까지 검증하기 - 숙련된 팀은 먼저 선택지를 넓게 펼친다. - 서로 겹치지 않으면서 전체 가능성을 포괄하는 **MECE(Mutually Exclusive, Collectively Exhaustive)** 방식으로 방향을 정리하고 장단점을 비교한다. - 반대로 2x2 매트릭스나 와이어프레임처럼 추상적인 자료만으로는 실제 사용자 경험에 대한 확신을 얻기 어렵다. - 효과적인 방법은 여러 방향을 동시에 탐색하면서 각각을 충분히 구체화하는 것이다. - AI를 활용하면 하나의 문제에 대해 여러 인터랙티브 프로토타입을 병렬로 제작하고, 각 방향을 실제 제품처럼 비교할 수 있다. - 팀원과 AI가 함께 프로토타입을 사용하고 피드백을 나누면 추상적인 아이디어가 아니라 구체적인 경험을 기준으로 판단할 수 있다. - 이는 순차적이고 분리된 작업 방식에서 벗어나, 여러 사람이 여러 방향을 동시에 실험하는 협업 방식이다. ## 평균적인 결과를 넘어 자신만의 제품 만들기 - 누구나 빠르게 만들 수 있게 되면 제품은 검증된 패턴과 일반적인 디자인으로 수렴하기 쉽다. - AI는 통계적으로 성공 가능성이 높은 UI와 기능을 제안하지만, 그것이 반드시 깊이 고민된 제품 경험을 의미하지는 않는다. - 사용자가 AI의 첫 결과물을 그대로 받아들이면 제품은 서로 비슷하고 무난해진다. - 진짜 위험은 능력 부족이 아니라 첫 제안에 수동적으로 동의하고, “그럴듯해 보인다”는 이유로 멈추는 태도다. - 기억에 남는 제품은 기능적으로 작동하는 것에서 끝나지 않고, 제작자의 명확한 관점과 의도를 드러낸다. - 이를 위해 각 결정을 다시 질문하고, 불필요한 요소를 제거하며, 여러 번 수정하고 다듬어야 한다. - 완성도 높은 결과를 만드는 일은 타고난 감각만의 문제가 아니라, 반복적으로 보고 판단하고 개선하는 훈련의 결과다. ## 지금 중요한 세 가지 역량 - **속도**: 아이디어를 빠르게 실험하고 프로토타입으로 구현한다. - **방향**: 여러 가능성을 비교해 만들 가치가 있는 문제와 해법을 선택한다. - **완성도와 장인정신**: AI가 만든 기본 결과를 넘어 제품의 의도와 개성을 구체화한다. - 최고의 팀은 이 세 가지를 서로 맞바꾸지 않고, 빠르게 움직이면서도 신중하게 선택하고 집요하게 개선한다. 실무에서는 하나의 아이디어를 곧바로 개발하기보다 여러 방향의 프로토타입을 병렬 제작하고, 실제 사용자 경험을 비교한 뒤 선택하는 방식이 효과적이다. AI의 결과물은 출발점으로 활용하되 그대로 받아들이지 말고, 제품의 목적과 차별성이 분명해질 때까지 반복적으로 수정하는 것이 좋다.

원문 읽기(새 탭에서 열림)
AI사용자 경험프로덕트 디자인product-development+2