figma·2026년 1월 25일·3분 읽기큐레이션 요약

고정관념에서 벗어나 생각

Claude와 FigJam의 연동으로 텍스트 프롬프트, PRD, PDF, 이미지, 스크린샷, 코드 파일을 편집 가능한 FigJam 다이어그램으로 변환할 수 있다. 이를 통해 AI와의 대화에서 나온 아이디어를 팀이 함께 검토·수정하는 시각적 협업 공간으로 빠르게 옮길 수 있다. Figma는 이 기능이 기획, 디자인, 개발 간의 소통을 줄이고 아이디어를 실행으로 연결하는 데 도움을 준다고 설명한다. ## 대화에서 편집 가능한 다이어그램으로 - Claude의 Figma MCP 앱을 사용하면 작성한 프롬프트나 업로드한 자료를 FigJam 다이어그램으로 만들 수 있다. - PRD를 기반으로 사용자 플로우를 생성해 제품의 전체 여정, 마찰 지점, 예외 상황을 빠르게 파악할 수 있다. - 생성된 결과물은 단순한 이미지가 아니라 FigJam에서 편집 가능한 형태이므로 팀원이 직접 수정하고 확장할 수 있다. - 대화 내용을 복사해 다른 도구로 옮기는 과정과 애플리케이션 간 컨텍스트 전환을 줄인다. ## 시각화로 팀의 사고를 공유 - 다이어그램은 복잡하거나 추상적인 아이디어를 이해하기 쉬운 흐름으로 바꿔 팀의 공통 언어 역할을 한다. - 디자이너는 사용자 여정과 경험 흐름을 시각화할 수 있다. - 제품 관리자는 Gantt 차트로 일정, 의존성, 마일스톤을 정리할 수 있다. - 기획 초기 단계에서 AI가 만든 초안을 바탕으로 문제를 조기에 발견하고 업무 순서를 조정할 수 있다. - FigJam의 공유 캔버스에서 팀원들이 댓글과 반응을 남기며 아이디어를 함께 발전시킬 수 있다. ## 개발 문서와 시스템 구조 시각화 - 엔지니어는 서비스, API, 데이터베이스, 요청·응답 흐름, 의존성을 포함한 시스템 아키텍처를 다이어그램으로 표현할 수 있다. - 기존 기술 문서나 업로드한 코드 파일을 바탕으로 초기 구조를 생성할 수 있다. - 여러 시스템의 패턴을 비교하거나 프런트엔드와 백엔드 간의 공통 맥락을 정리하는 데 활용할 수 있다. - 구현 전에 복잡성과 잠재적 위험을 검토해 개발 과정의 오류를 줄이는 데 도움이 된다. - Claude는 데이터베이스 구조에 적합한 차트 유형과 색상 코드도 제안할 수 있다. ## FigJam을 중심으로 이어지는 작업 흐름 - Claude에서 만든 아이디어를 FigJam으로 옮긴 뒤, Figma Design에서 다듬고 Figma Slides에서 공유할 수 있다. - 필요하면 최종 결과를 코드 구현으로 연결해 아이디어에서 실행까지의 흐름을 이어갈 수 있다. - FigJam은 초기 브레인스토밍뿐 아니라 프로젝트 계획, 시스템 설계, 협업 문서화의 공간으로 활용된다. - Figma는 더 다양한 도형 모음과 커넥터 유형을 추가해 정교한 다이어그램 작성 기능도 개선하고 있다. - Anthropic은 Claude용 MCP 앱을 설계할 수 있는 UI 키트도 제공한다. ## AI가 일회성 도구에서 협업 파트너로 - Claude는 여러 차례의 대화 맥락을 유지하면서 사용자 여정, 우선순위 절충안, 구현 구조를 점진적으로 개선할 수 있다. - 하나의 답만 제시하는 대신 의사결정 트리, Gantt 차트, 시퀀스 다이어그램, 상태 다이어그램 등 목적에 맞는 표현 방식을 제안할 수 있다. - FigJam에 저장된 다이어그램은 팀의 초기 사고 과정과 의사결정을 남기는 공유 자산이 된다. - MCP를 활용하면 시스템 컨텍스트를 다이어그램에 반영해 복잡한 시스템을 함께 이해하는 방식으로 발전할 수 있다. 실무에서는 PRD나 기술 문서를 Claude에 제공해 초안을 만든 뒤, FigJam에서 팀원과 구조·누락·우선순위를 검토하는 방식이 효과적이다. 단, AI가 생성한 흐름과 아키텍처는 초안이므로 실제 요구사항과 시스템 제약을 담당자가 반드시 검증해야 한다.

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

system-architectureAIfigjamclaude+3

toss·2025년 12월 10일원문

레거시 정산 개편기: 신규 시스템 투입 여정부터 대규모 배치 운영 노하우까지 (새 탭에서 열림)

토스페이먼츠는 20년 동안 운영되어 온 레거시 정산 시스템의 한계를 극복하기 위해 대대적인 개편을 진행했습니다. 거대하고 복잡한 단일 쿼리 기반의 로직을 객체지향적인 코드로 분산하고, 데이터 모델링을 집계 중심에서 거래 단위로 전환하여 정산의 정확성과 추적 가능성을 확보했습니다. 이를 통해 폭발적인 거래량 증가에도 대응할 수 있는 고성능·고효율의 현대적인 정산 플랫폼을 구축하는 데 성공했습니다. ### 거대 쿼리 중심 로직의 분할 정복 * **문제점:** 수많은 JOIN과 중첩된 DECODE/CASE WHEN 문으로 이루어진 거대한 공통 쿼리가 모든 비즈니스 로직을 처리하고 있어 유지보수와 테스트가 매우 어려웠습니다. * **도메인 및 기능 분리:** 거대 쿼리를 분석하여 도메인별, 세부 기능별로 카테고리를 나누는 분할 정복 방식을 적용했습니다. * **비즈니스 규칙의 가시화:** 복잡한 SQL 로직을 Kotlin 기반의 명확한 객체와 메서드로 재구성하여, 코드상에서 비즈니스 규칙이 명확히 드러나도록 개선했습니다. * **점진적 전환:** 기능을 단위별로 분할한 덕분에 전체 시스템 개편 전이라도 특정 기능부터 우선적으로 새 시스템으로 전환하며 실질적인 가치를 빠르게 창출했습니다. ### 데이터 모델링 개선을 통한 추적 가능성 확보 * **최소 단위 데이터 관리:** 기존의 집계(Sum) 기반 저장 방식에서 벗어나 모든 거래를 1:1 단위로 관리함으로써, 오류 발생 시 원인 추적을 용이하게 하고 데이터 재활용성을 높였습니다. * **설정 정보 스냅샷 도입:** 계산 결과와 함께 당시의 계약 조건(수수료율 등)을 스냅샷 형태로 저장하여, 시간이 지나도 과거의 정산 맥락을 완벽히 복원할 수 있게 했습니다. * **상태 기반 재처리:** 거래별로 독립적인 상태를 기록하는 설계를 통해, 장애 발생 시 전체 재처리가 아닌 실패한 건만 선별적으로 복구할 수 있도록 효율화했습니다. ### 고해상도 데이터 대응을 위한 DB 최적화 * **파티셔닝 및 인덱스 전략:** 정산일자 기준의 Range 파티셔닝과 복합 인덱스를 활용해 데이터량 증가에 따른 조회 성능 저하를 방지했습니다. * **조회 전용 테이블 및 데이터 플랫폼 활용:** 실시간 조회가 필요한 핵심 기능은 전용 테이블로 대응하고, 복잡한 어드민 통계는 고성능 데이터 플랫폼에 위임하여 시스템 부하를 분산했습니다. ### 배치 시스템 성능 극대화 * **I/O 횟수 최소화:** 배치 실행 시점에 가맹점 설정 정보를 전역 캐시에 로드하여 반복적인 DB 조회를 제거했습니다. * **Bulk 조회 및 처리:** Spring Batch의 `ItemProcessor`에서 개별 건별로 I/O가 발생하지 않도록 Wrapper 구조를 도입하여 묶음 단위(Bulk)로 조회하도록 개선했습니다. * **멀티 스레드 활용:** `AsyncItemProcessor`와 `AsyncItemWriter`를 도입하여 단일 스레드 제약을 극복하고 처리 속도를 비약적으로 향상시켰습니다. 이번 개편은 단순히 기술적인 스택을 바꾸는 것을 넘어, 레거시 시스템에 숨겨진 복잡한 비즈니스 맥락을 명확한 도메인 모델로 추출해냈다는 점에서 큰 의미가 있습니다. 대규모 트래픽과 복잡한 정산 규칙을 다루는 시스템이라면, 데이터를 최소 단위로 관리하고 I/O 최적화와 캐싱을 적극적으로 활용하는 아키텍처를 검토해볼 것을 추천합니다.

system-architecture데이터베이스 설계Kotlinrefactoring+3

datadog·2025년 8월 12일원문

규모를 줄여 100배 향상한 실시간 프로세스 메트릭 효율성 (새 탭에서 열림)

Datadog은 프로세스 및 컨테이너 모니터링 시스템의 실시간 데이터 처리 방식을 '호스트 구독(Host Subscription)' 기반 모델로 전환하여 확장성 문제를 해결했습니다. 사용자가 현재 화면에서 보고 있는 특정 호스트(최대 50개)에 대해서만 2초 간격의 고빈도 수집을 활성화함으로써, 전체 트래픽 볼륨을 100배 줄이고 인프라 비용을 98% 절감하는 성과를 거두었습니다. 이 글은 불필요한 데이터 수집을 최소화하면서도 사용자 경험과 시스템 효율성을 동시에 개선한 기술적 여정을 다룹니다. ## 기존 실시간 데이터 수집의 한계 * **전체 활성화 방식의 비효율성:** 기존에는 테넌트 내 한 명의 사용자만 페이지를 조회해도 해당 테넌트 전체 인프라의 모든 호스트에서 2초 간격의 데이터 수집이 시작되었습니다. 이로 인해 초당 수백만 개의 프로세스 데이터가 유입되는 부하가 발생했습니다. * **수평적 확장 불가능:** 실시간 정렬 기능을 제공하기 위해 테넌트의 모든 데이터를 단일 서버의 메모리에 보관해야 했습니다. 이는 시스템을 수평적으로 확장하는 것을 불가능하게 만들었으며, 서버 사양을 높이는 수직적 확장에만 의존하게 했습니다. * **리소스 낭비:** 실제 사용자가 한 번에 확인하는 프로세스는 약 50개 내외임에도 불구하고, 보이지 않는 수만 개의 프로세스 데이터를 실시간으로 수집하고 처리하는 비효율이 존재했습니다. ## 사용자 가시성 중심의 설계 전환 * **실시간 수집 대상의 최소화:** 사용자가 보고 있는 화면에 노출된 프로세스가 실행 중인 호스트에 대해서만 실시간 모드를 활성화하도록 전략을 수정했습니다. * **데이터 용도 분리 및 정렬 로직 최적화:** 2초 간격의 실시간 데이터는 화면 갱신에만 사용하고, 10초마다 수행되는 정렬 작업에는 일반적인 10초 간격 데이터를 활용하도록 변경했습니다. * **시스템 단순화:** 실시간 뷰와 히스토리 뷰에서 동일한 정렬 로직을 사용할 수 있게 되어 시스템 복잡성이 줄어들었고, 고빈도 메트릭을 메모리에 상주시켜야 할 필요성도 사라졌습니다. ## 호스트 구독 모델 및 필터링 최적화 * **호스트 구독(Host Subscription) 도입:** 사용자가 현재 보고 있는 호스트 목록을 추적하고, 이 상태를 Kafka를 통해 인테이크(Intake) 서비스와 라이브 서버 간에 공유합니다. * **조기 필터링(Early Filtering):** 구독 정보를 바탕으로 데이터 수집 단계(Intake)에서부터 필요한 데이터만 선별하여 처리합니다. 이는 Datadog 에이전트와 백엔드 서버 모두의 부하를 줄이는 핵심 기여를 했습니다. * **성능 개선 결과:** 개념 증명(PoC) 단계에서 이미 라이브 데이터 서버의 메모리 사용량은 85%, CPU 사용량은 33% 감소했으며, 이는 시스템 전체의 안정성 향상으로 이어졌습니다. 대규모 인프라 모니터링 환경에서 모든 데이터를 실시간으로 수집하는 것은 막대한 비용과 확장성 문제를 야기합니다. 사용자의 가시성 범위 내로 수집 대상을 제한하고 데이터의 용도(갱신 vs 정렬)에 따라 수집 빈도를 이원화하는 접근 방식은 리소스 효율성을 극대화하면서도 고성능 실시간 뷰를 제공할 수 있는 실용적인 해결책이 됩니다.

system-architecture데이터베이스 설계datadogApache Kafka+4