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

에이전트를 활용해 Figma의 내부 시스템을 보호하는 방법 | Figma 블로그

Figma는 SIEM 경보 대응에 AI 에이전트를 도입해 과거 조사 기록 검색, 포렌식 분석, 보안 데이터 질의, 코드 수정과 PR 생성까지 자동화했다. 그 결과 경보의 해결까지 걸리는 시간을 71% 줄였으며, 온콜 엔지니어의 업무를 단순한 정보 수집에서 판단과 검토 중심으로 바꾸었다. 핵심은 기존 업무 흐름을 유지하면서 경보와 조사 지식을 지속적으로 축적·검색하는 시스템을 구축한 것이다. ## 보안 경보 대응의 병목 - Figma의 SIEM인 Panther는 클라우드 인프라, 엔드포인트, SaaS, ID 시스템을 점검한다. - 문제가 감지되면 Slack에 경보를 게시하고 Asana 티켓을 생성한다. - 기존 온콜 엔지니어는 다음 정보를 수동으로 모아야 했다. - 같은 경보가 과거에 발생했는지 - 이전 조사에서 어떤 결론을 내렸는지 - 관련된 Slack 대화가 있는지 - 문제를 해결할 예정인 PR이 존재하는지 - 클라우드 환경과 개발 도구가 빠르게 변하면서 경보의 유형과 대응 방법도 계속 바뀌었다. - 따라서 단순히 경보를 분류하거나 중복 제거하는 것만으로는 업무 부담을 충분히 줄일 수 없었다. ## 검색 시스템에서 에이전트 시스템으로의 확장 - 초기 목표는 새 경보가 발생했을 때 과거 온콜 엔지니어의 판단과 대응 기록을 찾아주는 retrieval layer를 만드는 것이었다. - 이후 시스템은 다음 기능을 수행하는 에이전트 구조로 확장됐다. - 경보 조사 - 보안 데이터 레이크와 감사 로그 질의 - 관련 코드 변경 작성 - PR 생성 - 과거 조사 결과를 기억하고 다음 대응에 활용 - Figma는 코드베이스에서도 에이전트를 활용해 Okta와 AWS 같은 민감한 도구의 설정 변경을 점검하고 있었다. - 그러나 SIEM이 발견하는 광범위한 운영·인프라 문제까지 다루기 위해서는 코드 분석을 넘어선 별도의 시스템이 필요했다. ## RAG 계층: 경보에 기억을 부여하기 - Figma는 AWS Bedrock Knowledge Bases와 Amazon Kendra를 이용해 검색 증강 생성(RAG) 기반의 경보 분류 시스템을 구축했다. - Panther 경보가 발생하면 Lambda 핸들러가 원본 payload를 표준화된 문서로 변환해 Kendra에 색인한다. - 다음과 같은 구조화된 정보를 추출해 검색 속성으로 저장한다. - `p_any_ip_addresses`에서 추출한 IP 주소 - `p_any_usernames` 및 공급자별 사용자 필드의 행위자 정보 - ARN에서 추출한 AWS 계정 ID - 경보 제목, 심각도, 태그, 생성 시각 - 경보 유형, 상태, 조사 맥락의 존재 여부 - 예시 속성에는 `alert_id`, `alert_type`, `severity`, `status`, `created_at`, `has_investigation_context`가 포함된다. ## 의미 검색과 최신성 반영 - 새로운 유사 경보가 발생하면 경보 제목을 주요 검색 벡터로 사용해 Bedrock에 의미 검색을 요청한다. - 검색 질의에는 조사 맥락이 있는 기록만 우선하도록 다음 조건을 추가한다. ```text {경보 제목} has_investigation_context=1 ``` - 경보 제목은 일반적으로 탐지 규칙 이름과 행위자 사용자 이름으로 구성된다. - 단순히 가장 유사한 기록을 찾는 것보다 최근 기록을 우선하도록 검색 결과를 편향시켰다. - 대응 절차와 환경이 계속 변하기 때문에, 6개월 전의 정확히 같은 경보보다 이틀 전에 발생한 유사 경보가 실무적으로 더 유용할 수 있다. - 이를 통해 검색 결과가 현재의 운영 방식과 최신 조사 관행을 더 잘 반영하게 된다. ## Slack 조사 기록의 자동 축적 - `investigation_context`는 온콜 엔지니어가 Slack 경보 스레드에 남긴 조사 결과와 판단을 의미한다. - 조사 내용이 없는 종료 경보는 단순히 “닫혔다”는 사실만 제공하므로 재사용 가치가 낮다. - Figma는 엔지니어가 기존처럼 Slack이나 Asana에 댓글을 남기기만 해도 해당 내용을 자동으로 원래 경보 문서에 추가한다. - 기존 문서의 조사 맥락 배열에 새 댓글을 추가하고, `has_investigation_context` 값을 1로 변경한 뒤 문서를 재색인한다. - 결과적으로 유용한 댓글 하나가 이후 발생하는 모든 유사 경보의 조사 비용을 낮춘다. - 별도의 annotation 도구나 새로운 수동 입력 절차를 요구하지 않고 기존 업무 흐름에서 지식이 축적된다는 점이 중요하다. ## 실용적인 적용 방향 - 처음부터 완전한 자율 에이전트를 만들기보다, 과거 대응 기록을 검색하는 좁은 문제부터 시작하는 것이 현실적이다. - 경보 데이터는 검색 가능한 구조화 필드와 사람이 작성한 조사 맥락을 함께 저장해야 한다. - 최신 대응 기록과 조사 내용이 있는 기록을 우선하는 검색 전략이 필요하다. - 별도의 문서화 작업을 추가하기보다 Slack·티켓 시스템의 기존 댓글을 자동으로 지식화하는 방식이 도입 장벽을 낮춘다. - AI가 분석과 코드 변경을 수행하더라도 PR 검토와 최종 판단은 보안 엔지니어가 맡는 구조가 효과적이다.

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

aws-bedrockAI 에이전트TypeScriptRAG+4

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

Slack AI: 멀티 클라우드로 가는 길

Slack AI는 초기 SageMaker 기반 운영에서 출발해 Amazon Bedrock으로 이전하며, 수동적인 GPU·용량 관리에서 관리형·다중 클라우드 오케스트레이션으로 발전했다. 이 과정의 목표는 단순히 최신 LLM을 도입하는 것이 아니라, GPU 부족과 지역 장애에도 견디면서 엔터프라이즈 수준의 보안·성능·신뢰성을 유지하는 것이었다. 특히 부하 테스트, 품질 비교, 점진적 트래픽 전환을 통해 고객 영향 없이 마이그레이션을 완료한 점이 핵심이다. ## SageMaker 기반 초기 아키텍처 - 2023년 초 Slack은 AWS SageMaker를 LLM 서빙의 출발점으로 선택했다. - SageMaker는 다음 요구사항을 충족했다. - 보안성과 FedRAMP 준수 - 모델 가용성과 제어권 - Escrow VPC를 활용한 제로 지식 환경 - Slack의 데이터는 외부에 노출되지 않았고, 모델 제공업체의 비공개 가중치에도 Slack이 접근할 수 없었다. - 글로벌 가용성을 위해 여러 AWS 리전에 컨테이너를 배포했다. - 운영팀은 리전 간 IAM 역할, 모델 엔드포인트 라우팅, 용량 계획, 자동 확장을 직접 관리해야 했다. ## 자체 운영에서 발생한 비용 - **확장 지연** - 인스턴스 초기화 시간이 길어 즉각적인 확장이 어려웠다. - **GPU 부족** - A100, H100 같은 고성능 NVIDIA GPU를 필요한 시점에 확보하기 어려웠다. - **과잉 프로비저닝** - 피크 시간대 SLA를 맞추기 위해 유휴 리소스를 미리 확보해야 했다. - 2024년 초에는 On-Demand Capacity Reservations와 cron 기반 사전 확장으로 문제를 완화했지만, 엔지니어링 리소스가 인프라 조정 업무에 과도하게 투입됐다. - 결국 Slack은 수동 조정이 아니라 자동화된 용량 확보가 필요하다고 판단했다. ## SageMaker의 모델 출시 지연 - AWS가 관리형 LLM 서비스인 Bedrock을 우선적으로 발전시키면서, SageMaker 기반 커스텀 서빙 환경은 최신 모델 도입에서 뒤처지기 시작했다. - Escrow VPC에서 Anthropic 모델을 호스팅하는 방식은 Bedrock보다 모델 업데이트와 최적화 적용이 수주에서 수개월 늦었다. - AI 기능 품질이 경쟁력과 직결되는 Slack에는 이러한 지연이 큰 문제가 됐다. ## Amazon Bedrock으로의 전환 - 2024년 중반 Slack은 FedRAMP Moderate 인증과 필요한 보안 수준을 갖춘 Bedrock으로 이전했다. - 전환의 주요 이점은 다음과 같다. - 개별 GPU 인스턴스와 엔드포인트를 직접 확장하지 않아도 되는 운영 단순화 - 최신 모델을 공개 직후 빠르게 사용 가능 - 사용 패턴에 따른 비용·용량 최적화 - 예측 가능하고 지연 시간에 민감한 채널 요약에는 **Provisioned Throughput(PT)**를 사용했다. - 간헐적이고 예약 실행되는 Recap 작업에는 **On-Demand(OD)**를 사용해 유휴 용량 비용을 줄였다. ## Model Unit 기반 용량 관리 - Bedrock의 용량은 GPU 인스턴스가 아니라 **Model Unit(MU)**로 측정된다. - 각 MU는 분당 토큰 수로 표현되는 일정한 처리량을 제공한다. - Slack은 하드웨어 세부사항 대신 필요한 토큰 처리량에 집중할 수 있게 됐다. - 마이그레이션 위험을 줄이기 위해 먼저 Provisioned Throughput 환경을 이전하고, On-Demand 환경은 후속 단계로 진행했다. ## 무중단 마이그레이션 전략 - **규정 준수 검토** - Legal, Security, FedRAMP 승인을 받은 뒤 운영 트래픽을 전환했다. - **용량 검증** - 다양한 트래픽 패턴에서 SageMaker와 동일한 성능을 내는 MU 수를 부하 테스트로 산정했다. - **품질 비교** - A/B 테스트와 평가 프레임워크로 모델 출력 품질과 지연 시간을 나란히 비교했다. - **점진적 롤아웃** - 기능 플래그를 사용해 트래픽을 단계적으로 이동했다. - 문제가 발생하면 즉시 이전 환경으로 롤백할 수 있도록 구성했다. - 대규모 부하 테스트와 shadow request를 통해 기존 환경과의 성능 패리티를 확인했고, 고객에게 영향을 주는 장애 없이 전환을 완료했다. ## Bedrock 도입 이후의 운영 개선 - 엔지니어들은 GPU 수명주기, 엔드포인트 관리, 용량 예약 대신 모델 성능과 기능 품질에 집중할 수 있게 됐다. - 최신 모델을 더 빨리 적용하면서 AI Search에 고도화된 추론 모델을 신속히 도입했고, 더 정교하고 맥락에 맞는 답변을 제공할 수 있었다. - 인프라 운영은 다음과 같이 단순화됐다. - Slack이 필요한 quota를 요청 - AWS가 MU를 프로비저닝 - Slack이 해당 용량으로 트래픽을 처리 - 수요가 발생한 뒤 대응하는 방식에서, 몇 주 앞을 내다보고 용량을 예약하는 전략적 예측 방식으로 전환했다. - Slack이 강조한 운영 원칙은 **먼저 측정하고, 점진적으로 이전하며, 지속적으로 모니터링하는 것**이다. ## 남은 효율성 문제 - Provisioned Throughput은 안정적이고 예측 가능한 워크로드에는 효과적이었지만 모든 트래픽에 최적은 아니었다. - 미국 동부·서부 지역의 업무 시작 시간처럼 특정 시간대에 AI 요약과 검색 요청이 급증하는 패턴을 처리하려면 높은 MU 기본 용량을 유지해야 했다. - 그 결과 피크 시간대 성능을 보장하는 대신, 사용량이 낮은 시간에는 일부 용량이 유휴 상태로 남는 과잉 프로비저닝 문제가 여전히 존재했다. ## 실용적인 결론 LLM 인프라를 확장할 때는 직접 GPU를 운영하는 것보다 관리형 서비스가 모델 접근성과 운영 효율을 크게 높일 수 있다. 다만 서비스 이전은 단순한 엔드포인트 교체가 아니라, 부하·품질·규정 준수 검증과 점진적 롤백 체계를 포함한 통제된 마이그레이션으로 진행해야 한다.

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

aws-bedrock대규모 언어 모델model-servinggpu+3

daangn·2025년 12월 23일원문

당근페이 AI Powered FDS로 가는 여정: 룰엔진구축부터 LLM 적용까지 (새 탭에서 열림)

당근페이는 급변하는 이상거래 패턴에 유연하게 대응하기 위해 룰엔진 중심의 FDS를 구축하고, 최근에는 LLM을 결합하여 탐지 정교화와 모니터링 효율성을 극대화하고 있습니다. 초기 룰엔진은 조건, 규칙, 정책의 계층 구조로 설계되어 실시간 탐지와 제재를 가능하게 했으며, 여기에 LLM 기반의 맥락 분석을 더해 검토 시간을 단축하고 판단의 일관성을 확보했습니다. 금융 보안 규제를 준수하면서도 최신 AI 모델을 실무에 적용해 사용자 자산을 보호하는 선도적인 FDS 운영 사례를 제시합니다. **유연한 탐지를 위한 룰엔진의 구조** * 룰엔진은 조건(빌딩 블록), 규칙(조건의 조합), 정책(규칙의 묶음)의 3단계 계층 구조로 설계되어 레고 블록처럼 탐지 로직을 조립할 수 있습니다. * '가입 후 N일 이내', '송금 횟수 N건 이상'과 같은 개별 임계값을 자유롭게 변경하며 새로운 사기 패턴에 즉각적으로 대응할 수 있는 환경을 마련했습니다. * 이벤트 유입 경로는 즉시 차단이 필요한 '동기 API'와 대량의 이벤트를 실시간으로 분석하는 '비동기 스트림'으로 분리하여 처리 효율을 높였습니다. **룰엔진 기반의 위험 평가 및 사후 처리** * 유입된 모든 거래 이벤트는 설정된 정책과 규칙에 따라 위험 평가를 거치며, 그 결과에 따라 LLM 평가, 고객 서비스팀 알람, 유저 제재 등의 후속 조치가 자동 수행됩니다. * 시스템 도입 후 실시간으로 규칙을 추가하거나 변경하며 사기 트렌드를 빠르게 반영한 결과, 금융 및 수사기관으로부터의 사기 관련 정보 요청 건수가 유의미하게 감소했습니다. * 탐지 로직의 유연화는 단순 차단을 넘어 시스템 전반의 유저 상태 동기화까지 통합적으로 관리할 수 있는 기반이 되었습니다. **LLM 도입을 통한 지능형 FDS로의 진화** * 기존의 수동 검토 방식은 건당 5~20분이 소요되고 담당자마다 판단 결과가 달라질 수 있는 한계가 있어, 이를 해결하기 위해 LLM을 통한 맥락 분석 기능을 도입했습니다. * 전자금융업의 망분리 규제 문제를 해결하기 위해 '혁신금융서비스' 지정을 받았으며, AWS Bedrock의 Claude 3.5 Sonnet 모델을 활용해 보안과 성능을 모두 잡았습니다. * BigQuery의 사기 이력을 Redis에 캐싱하고, 이를 구조화된 프롬프트(XML 태그 및 JSON 형식)에 결합하여 LLM이 사기 여부와 그 근거를 일관되게 평가하도록 설계했습니다. 효율적인 FDS 운영을 위해서는 룰 기반의 명확한 통제와 AI 기반의 유연한 맥락 분석이 조화를 이루어야 합니다. 특히 LLM을 실무에 적용할 때는 규제 준수를 위한 기술적/행정적 준비와 함께, AI가 정교한 판단을 내릴 수 있도록 단계별로 명시적이고 구조화된 프롬프트를 설계하는 과정이 무엇보다 중요합니다.

aws-bedrockAI대규모 언어 모델redis+5