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

이제 FigJam은 코딩 에이전트의 화이트보드이기도 합니다 | Figma 블로그

FigJam이 코딩 에이전트의 작업을 시각화하고 팀과 함께 검토하는 협업 공간으로 확장된다. Figma는 `figma-use-figjam`, 확장된 `generate_diagram`, `get_figjam` 등의 MCP 도구와 스킬을 통해 에이전트가 코드베이스와 문서를 분석하고, FigJam에 아키텍처를 작성하며, 팀 피드백을 다시 구현 단계로 전달하도록 한다. 이를 통해 빠른 에이전트 개발로 발생하는 숨은 복잡성을 줄이고, 코딩 전에 설계를 검토할 수 있다는 것이 글의 결론이다. ## 에이전트 개발 속도와 코드 복잡성의 간극 - 에이전트 덕분에 과거 몇 분기 걸리던 기능을 몇 주 만에 구현할 수 있다. - 그러나 사람이 충분히 검토하지 않은 에이전트 생성 PR이 쌓이면 코드베이스에 다음 문제가 생긴다. - 숨은 복잡성 증가 - 기존 구조와 새로운 구현 간의 불일치 - 팀원이 전체 시스템 변화를 파악하기 어려움 - 글의 저자는 이러한 문제를 한눈에 파악하고 논의하기 위해 텍스트 문서보다 시각적인 시스템 표현이 필요하다고 설명한다. ## FigJam과 MCP 도구의 결합 - 기존 `use_figma` MCP 도구는 AI 에이전트가 실제 Figma 컴포넌트를 사용해 디자인을 생성하거나 수정하도록 한다. - `create_new_file`은 에이전트가 새 Figma 파일 안에 디자인을 생성할 수 있게 한다. - 새롭게 확장된 `generate_diagram`은 단순한 다이어그램을 넘어 다음과 같은 복잡한 시각 자료를 생성한다. - 시스템 아키텍처 다이어그램 - ERD(Entity Relationship Diagram) - 서비스 및 데이터 관계 구조 - `figma-use-figjam` MCP 스킬은 에이전트가 FigJam 보드를 직접 읽고 쓸 수 있도록 한다. - `generate-project-plan` 같은 워크플로 스킬은 문서, 코드베이스, 대화 내용을 시각적인 프로젝트 계획으로 변환한다. ## 1단계: 조사와 계획을 시각화 - 먼저 코딩 에이전트가 새 기능에 필요한 맥락을 수집한다. - 관련 MCP 서버 문서 - 코드베이스 구조 - 기존 구현 패턴 - 영향을 받는 서비스와 파일 - 에이전트는 가능한 구현 방안과 트레이드오프를 조사한다. - 이후 작업을 여러 개의 stacked PR로 나누고 테스트 전략을 세운다. - 기존에는 이 결과가 긴 Markdown 문서로 남았지만, 이제 FigJam 보드로 변환할 수 있다. - 보드에는 다음 자료를 함께 배치할 수 있다. - `generate_diagram`으로 생성한 아키텍처 및 ER 다이어그램 - `figma-use-figjam`으로 작성한 노트 - 코드 블록 - 주석과 설계 근거 - 텍스트 중심의 계획보다 팀원이 구조와 대안을 빠르게 비교하고, 적절한 아키텍처를 논의하기 쉬워진다. ## 2단계: 코드 작성 전 협업 - 생성된 FigJam 보드를 팀에 공유해 구현 전에 기술적 피드백을 받는다. - 팀원은 다이어그램 위에서 질문과 결정을 직접 남길 수 있다. - 특정 도구가 디자인 파일 외에 여러 파일 형식을 지원해야 하는가? - `folderId`를 입력받을 것인가? - 새 파일은 사용자의 Drafts 폴더에 생성할 것인가? - 원격 팀도 회의실에서 화이트보드를 사용하는 것처럼 기술 맥락을 공유하고 논의할 수 있다. - 에이전트가 만든 다이어그램도 사람이 검토하는 협업 산출물로 활용된다. ## 3단계: FigJam의 결정을 구현으로 전달 - 리뷰가 끝나면 에이전트가 보드의 결과를 다시 읽어 구현 계획을 갱신한다. - `get_figjam` 도구를 사용하면 다음 정보를 코딩 환경으로 가져올 수 있다. - 아키텍처 다이어그램 - 팀의 결정 사항 - 보드의 주석과 논의 내용 - 과거처럼 다이어그램을 캡처하고 댓글을 수동으로 요약해 에이전트에게 설명할 필요가 줄어든다. - 최종 PR에는 FigJam 보드 링크를 함께 연결해 설계 맥락을 보존할 수 있다. - 아키텍처가 코드 작성 전에 이미 검토되므로 PR 리뷰와 병합이 더 수월해진다. 에이전트에게 구현을 맡기더라도 계획·아키텍처·팀 의사결정은 사람이 먼저 검토하는 흐름을 만드는 것이 중요하다. FigJam과 MCP 도구를 함께 사용하면 에이전트의 빠른 실행력과 팀의 설계 검토를 연결해, 코드 품질과 협업 가시성을 높일 수 있다.

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

software-architectureFigmaAI 에이전트figjam+3

toss·2026년 2월 26일원문

쓰기 쉬운 Toss Front SDK (새 탭에서 열림)

좋은 SDK는 단순히 기능을 제공하는 것을 넘어, 사용자가 올바른 방법으로만 사용하도록 유도하고 휴먼 에러를 구조적으로 방지해야 합니다. 이를 위해 복잡한 내부 로직을 사용자의 ‘의도’를 중심으로 추상화하는 퍼사드(Facade) 패턴을 적용하여, 사용자가 최소한의 코드로도 안정적인 결과물을 만들 수 있는 환경을 구축해야 합니다. 고수준 인터페이스를 통해 대다수의 유즈케이스를 해결하면서도, 특수한 상황을 위한 저수준 인터페이스라는 ‘탈출구’를 마련하는 것이 설계의 핵심입니다. ### 의도 기반의 퍼사드(Facade) 패턴 재정의 - 퍼사드 패턴의 본질은 단순히 복잡한 기능을 숨기는 것이 아니라, 내부 구현을 ‘사용자의 의도(Intent)’를 기준으로 재구성하는 데 있습니다. - "서버를 열고, 핸들러를 등록하고, 에러를 처리한다"는 개별적인 절차를 "서버를 시작한다"는 하나의 자연스러운 목적으로 통합합니다. - 인증, 재시도 로직, 상태 관리, 클린업(Cleanup) 등 인지 부하를 일으키는 요소들을 SDK 내부로 은닉하여 사용자 측의 실수를 원천 차단합니다. ### AWS CDK 사례를 통한 추상화 계층의 이해 - AWS CDK의 L1 구문은 리소스의 모든 속성을 제어하는 저수준(low-level) 인터페이스인 반면, L2 구문은 직관적인 의도 기반의 고수준(high-level) 추상화를 제공합니다. - S3 버킷 생성 시 L1은 모든 세부 설정을 직접 챙겨야 하지만, L2는 자주 쓰이는 옵션을 간단한 프로퍼티로 제공하고 내부적인 변환은 SDK가 담당합니다. - SDK 설계 시에도 이와 같이 복잡한 주변 구성을 자연스러운 API 흐름으로 이어 붙일 수 있도록 설계해야 합니다. ### 파레토 법칙을 적용한 인터페이스 설계 - 전체 사용 사례의 80%에 해당하는 공통 유즈케이스는 고수준 인터페이스(Facade)를 통해 워크플로우를 자동화하여 제공합니다. - 나머지 20%의 특수한 요구사항이나 세밀한 제어가 필요한 상황을 위해 저수준 API인 ‘탈출구(Escape Hatch)’를 함께 유지합니다. - 이러한 이중 구조는 단기적인 개발자 경험(DX) 향상뿐만 아니라, SDK의 장기적인 호환성과 확장성을 보장하는 핵심 전략이 됩니다. ### 편의성과 유연성 사이의 트레이드오프 관리 - 추상화 수준이 높아지면 사용자는 편리해지지만, SDK 내부에서는 더 정교한 오케스트레이션 로직을 관리해야 하는 유지보수 비용이 발생합니다. - 세밀한 제어가 차단될 경우 특정 상황에서 제약이 될 수 있으므로, 고수준 인터페이스에만 의존하지 않고 저수준 조작이 가능한 균형점을 찾는 것이 중요합니다. - 결과적으로 잘 설계된 인터페이스는 사용자가 별도의 가이드 없이도 올바른 패턴을 유지하며 메모리 누수와 같은 장애 상황을 방지하게 합니다. 단순히 "동작하는" SDK를 만드는 단계를 넘어, 사용자가 직관적으로 이해하고 안전하게 사용할 수 있는 "쓰기 쉬운" SDK를 지향해야 합니다. 이를 위해 사용자의 의도를 최우선으로 고려한 추상화 계층을 설계하고, 대다수의 편의성과 소수의 유연성을 동시에 잡을 수 있는 다층적 구조를 도입할 것을 권장합니다.

software-architectureAPI 설계interface-designfrontend+4

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

AI가 개발자의 선택을

AI는 단순히 코딩 속도를 높이는 도구를 넘어, 개발자가 선택하는 언어·프레임워크·도구 자체를 바꾸고 있다. GitHub의 Octoverse 2025 데이터에 따르면 TypeScript가 2025년 처음으로 Python과 JavaScript를 제치고 가장 많이 사용된 언어가 되었으며, 이는 AI가 복잡한 기술의 사용 장벽을 낮춘 결과로 해석된다. 따라서 조직은 AI의 생산성 향상뿐 아니라, AI가 증폭하는 아키텍처 품질과 기술 선택의 변화까지 관리해야 한다. ## 편의성이 개발자 선택을 바꾸는 과정 개발자는 사용하기 쉽고 마찰이 적은 기술을 반복적으로 선택하며, 이러한 선택이 생태계 전체의 흐름을 바꾼다. - 작업이 편리했던 경험은 기억에 남아 이후의 기술 선택에 영향을 준다. - GitHub 신규 개발자의 **80%가 첫 주 안에 Copilot을 사용**한다. - AI가 보일러플레이트와 문법 오류를 처리하면서, 복잡한 언어를 선택할 때의 비용이 감소했다. - 개발자는 “배우기 쉬운 기술”보다 “목적에 가장 적합하고 AI가 잘 지원하는 기술”을 선택하게 된다. ## TypeScript와 AI 친화적 기술의 성장 Octoverse 데이터는 AI가 실제 기술 채택에 영향을 주고 있음을 보여준다. - 2025년 8월, TypeScript가 GitHub에서 가장 많이 사용되는 언어가 되었다. - TypeScript 사용량은 전년 대비 **66% 증가**했다. - JavaScript 사용량은 **24% 증가**했다. - AI가 생성한 프로젝트에서 Shell 스크립트 사용량은 **206% 증가**했다. - 이는 개발자들이 Bash를 갑자기 선호하게 되었다기보다, AI가 Shell 사용의 문법적·인지적 부담을 줄였기 때문으로 볼 수 있다. ## 강한 타입 시스템이 AI 코드 생성에 유리한 이유 AI는 가능한 코드의 범위가 명확할수록 더 안정적인 결과를 생성할 수 있다. - JavaScript에서는 변수의 타입이 상황에 따라 무엇이든 될 수 있다. - TypeScript에서 `x: string`처럼 타입을 선언하면 문자열이 아닌 연산을 배제할 수 있다. - 이런 제약은 AI가 생성할 수 있는 코드의 공간을 줄이고, 문맥에 맞는 코드를 만들 가능성을 높인다. - 타입 검사는 오류를 줄이는 강력한 안전장치지만, 비즈니스 로직의 정확성까지 보장하지는 않는다. - GitHub의 공개 저장소 중 **110만 개 이상이 LLM SDK를 사용**하고 있어, 생성형 AI 연동은 실험 단계를 넘어 주류가 되었다. ## 빠른 개발과 아키텍처 품질의 균형 AI는 생산성을 크게 높이지만, 잘못된 설계도 더 빠르게 확산시킬 수 있다. - AI는 기존에 정립된 패턴을 따르는 데 강하고, 좋은 구조를 처음부터 설계하는 데는 상대적으로 약하다. - 초기 API 엔드포인트나 컴포넌트를 명확한 구조로 작성하면 이후 생성되는 코드도 그 패턴을 따를 가능성이 높다. - 반대로 불안정한 구조를 먼저 만들면 AI가 이를 반복·확장해 기술 부채를 키울 수 있다. - AI 지원 개발로 처리량이 **20~30% 증가**할 수 있지만, 그만큼 아키텍처의 일관성이 빠르게 무너질 위험도 커진다. ## 개발자와 팀을 위한 실천 방법 - **생성 전에 패턴을 정한다.** API, 컴포넌트, 디렉터리 구조, 오류 처리 방식 등을 먼저 정의한다. - **타입 시스템을 가드레일로 활용한다.** 타입 통과를 완전한 정합성의 증거로 간주하지 않는다. - **AI 생성 코드를 더 엄격하게 테스트한다.** 코드가 자연스럽고 초기 검사를 통과하더라도 테스트와 리뷰를 생략하지 않는다. - **템플릿과 문서를 표준화한다.** AI가 참고할 수 있도록 템플릿 저장소와 명시적인 아키텍처 결정을 제공한다. ## 엔지니어링 리더가 관리해야 할 지표 AI 도입의 성공 여부는 단순한 코드 생성량이나 자동완성 수락률만으로 판단하기 어렵다. - Copilot 사용 지표를 통해 일·주간 활성 사용자, 에이전트 사용률, 추가·삭제된 코드 라인, 언어·모델별 사용 패턴을 확인한다. - 에이전트 사용률은 높은데 특정 팀의 결함이 증가한다면 프롬프트 교육이나 코드 리뷰 기준을 강화해야 한다. - 특정 언어나 모델에서 결함률이 높다면 해당 기술 선택과 사용 방식을 재검토할 수 있다. - Copilot API를 이용하면 사용자 단위 데이터를 기반으로 조직에 맞는 대시보드를 구축할 수 있다. - 개발 속도가 빨라질수록 시니어 엔지니어의 아키텍처 검토와 품질 관리 역량은 더욱 중요해진다. AI를 도입할 때는 “얼마나 많은 코드를 만들었는가”보다 “어떤 구조와 품질의 코드를 만들었는가”를 관리해야 한다. TypeScript 같은 강한 제약의 도구와 명확한 개발 패턴을 기반으로 AI를 활용하고, 테스트·리뷰·품질 지표를 함께 운영하는 것이 실용적인 접근이다.

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

software-architectureTypeScriptPythonJavaScript+4

spotify·2026년 2월 9일원문

더 스마트한 광고를 위한 우리의 (새 탭에서 열림)

Spotify는 광고 비즈니스의 다양한 구매 채널 간에 발생하는 의사결정 로직의 파편화 문제를 해결하기 위해 멀티 에이전트 아키텍처를 도입했습니다. 기존의 하드코딩된 워크플로우 대신, 광고주의 의도를 이해하고 공유된 신호를 바탕으로 추론하는 '프로그래밍 가능한 의사결정 계층'을 구축하여 모든 채널에서 일관된 최적화를 달성하고자 합니다. 이를 통해 복잡한 비즈니스 제약 조건을 유연하게 처리하고, 기존 광고 서비스들을 에이전트가 활용하는 도구로 재정의함으로써 시스템 전반의 운영 효율성을 극대화하는 것이 이 글의 핵심입니다. ### 기존 워크플로우의 구조적 한계와 파편화 * **채널별 로직 불일치:** 동일한 백엔드 인프라를 공유함에도 불구하고 Direct, Self-Serve, Programmatic 등 각 구매 채널별로 의사결정 로직과 휴리스틱이 다르게 구현되어 동작의 불일치가 발생합니다. * **중복 구현과 기술 부채:** 예산 할당이나 인벤토리 선택과 같은 핵심 로직이 각 채널 및 사용자 접점(Spotify Ads Manager, Salesforce, Slack 등)마다 중복 구현되어 관리 비용이 증가하고 로직의 변질(Drift)이 일어납니다. * **의도 계층(Intent Layer)의 부재:** 기존 시스템은 "브라질 내 도달 범위 극대화 및 비디오 인벤토리 보호"와 같은 복합적인 목표를 이해하고 이를 실행 가능한 도구 호출 순서로 변환하는 능력이 부족했습니다. ### 멀티 에이전트 기반 의사결정 계층의 도입 * **모듈형 에이전트 구조:** 복잡하고 확률적인 광고 로직을 정적인 규칙 엔진(Rules Engine)에 가두는 대신, 상황에 따라 추론하고 실행하는 독립적인 에이전트들의 집합으로 구성했습니다. * **공유 신호 기반 최적화:** 모든 에이전트는 인벤토리, 오디언스, 성능 이력 등 동일한 기저 신호를 공유하며 광고주의 목표와 Spotify의 비즈니스 제약 조건을 동시에 고려하여 최적의 경로를 찾습니다. * **기존 서비스의 도구화:** 기존 광고 서비스들을 처음부터 다시 만드는 대신, 에이전트가 목적에 따라 호출하여 사용할 수 있는 '도구(Tools)'로 활용함으로써 오케스트레이션 성능을 높였습니다. ### 에이전트 중심 설계를 위한 기술적 패러다임 전환 * **API 설계의 변화:** 단순히 데이터를 생성하고 수정하는 CRUD 방식에서 벗어나, 에이전트가 특정 기능을 실행하기 위해 직관적으로 이해하고 사용할 수 있는 '도구 중심 API'로 재설계했습니다. * **행동 중심의 평가:** 전통적인 유닛/통합 테스트를 넘어, 에이전트가 내린 결정이 비즈니스 목표에 부합하는지 확인하는 '행동 평가(Behavioral Evaluation)' 체계를 구축했습니다. * **추론 과정의 관측성:** 시스템 성능 지표뿐만 아니라 "에이전트가 왜 그런 결정을 내렸는가"에 대한 추론 과정을 추적하여 투명성을 확보했습니다. * **자율성을 제어하는 가드레일:** 입력값 검증 수준을 넘어 반자율적인 에이전트의 결정이 비즈니스 규칙과 안전 가이드라인 내에서 유지되도록 하는 가드레일 메커니즘을 도입했습니다. 복잡한 비즈니스 로직이 여러 플랫폼에 흩어져 있다면, 이를 개별 서비스로 관리하기보다 통합된 '의사결정 엔진'으로서의 에이전트 플랫폼을 구축하는 것이 장기적인 유지보수와 기능 확장 면에서 유리합니다. Spotify는 이를 미디어 플래닝(Media Planning) 영역에 우선 적용하여 복잡한 변수 속에서도 일관된 최적화 성능을 증명하고 있습니다.

software-architectureAI 에이전트머신러닝API 설계+3

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

GitHub Copilot의 에이전

GitHub Copilot의 에이전트 기능은 단순한 코드 자동완성보다 시스템 설계, 리팩터링, 마이그레이션, 다중 파일 변경을 지원하는 협업 도구로 활용할 수 있다. 다만 Copilot이 개발자의 판단을 대체하는 것은 아니며, 개발자는 제안된 구조와 변경 사항을 검토하고 반박할 수 있어야 한다. 핵심은 기능 구현 전에 아키텍처 경계와 영향 범위를 분석하도록 Copilot을 활용하는 것이다. ## 시스템 설계와 모듈 분해 - 코드를 바로 작성하기보다 먼저 다음 영역의 경계를 식별한다. - 도메인 로직 - 데이터 접근 계층 - 인터페이스와 컨트롤러 - 모듈 간 상호작용 - Copilot에 서비스 구조를 분석하도록 요청하면 다음 문제를 발견하는 데 도움을 받을 수 있다. - 모듈 경계와 계층 간 결합 - 비동기 처리 및 트랜잭션 관련 위험 - 중복 로직과 책임 혼재 - 테스트 가능성과 관측성 문제 - 헥사고날 아키텍처와 계층형 아키텍처를 비교하게 하고, 현재 코드베이스의 제약 조건에 맞는 선택과 트레이드오프를 설명하도록 할 수 있다. - 이 과정에서 Copilot은 자동완성 도구가 아니라 설계 리뷰어처럼 활용된다. ## 의존성 역전 기반의 모듈형 서비스 구축 - 도메인, 컨트롤러, 리포지토리를 독립적인 모듈로 나누도록 요청할 수 있다. - 의존성 역전을 적용하면 상위 수준의 도메인 로직이 특정 데이터베이스나 인프라 구현에 직접 의존하지 않게 된다. - Copilot은 다음과 같은 결과물을 생성할 수 있다. - 도메인 모델 인터페이스 - 리포지토리 추상화 - 도메인 서비스를 호출하는 컨트롤러 - 각 모듈의 책임, 가정, 계약을 설명하는 Markdown 문서 - 초급 개발자는 실제 서비스 설계 패턴을 학습하고, 숙련 개발자는 반복적인 기본 코드 작성 시간을 줄일 수 있다. ## 태깅 기능 추가 시 고려할 아키텍처 영향 - “노트에 태그 추가”는 단순한 기능처럼 보이지만 여러 계층에 영향을 준다. - 데이터 모델링 방식부터 결정해야 한다. - 노트에 태그를 직접 내장할지 - 정규화된 태그 테이블을 만들지 - 다대다 관계를 사용할지 - 검색 기능에서는 태그가 색인, 필터링, 검색 관련성에 어떤 영향을 주는지 검토해야 한다. - API에서 태그를 독립적인 리소스로 노출할지, 내부 구현 세부사항으로 둘지도 결정해야 한다. - 검증 규칙과 불변식을 어느 계층에서 강제할지 명확히 해야 한다. - 마이그레이션 방식과 배포·롤백 전략도 함께 설계해야 한다. - Copilot에 먼저 영향 범위를 분석하게 하면 다음 항목을 확인할 수 있다. - 태그와 노트의 관계 - 스키마 마이그레이션 필요성 - 검색 및 캐시·색인 영향 - 검증 로직 변경 - 테스트와 외부 API 소비자에 대한 영향 - 잠재적인 회귀 문제 ## 다중 파일 변경과 일관된 구현 - 설계가 끝난 뒤에는 도메인 모델, 스키마, 리포지토리, 컨트롤러를 하나의 의도로 연결해 구현하도록 Copilot에 요청할 수 있다. - 테스트와 문서도 함께 갱신하게 하고, 각 변경 사항을 diff 형태로 제시하도록 하면 검토가 쉬워진다. - 예시로 태그를 JSON 배열로 저장하는 스키마 변경, `Tag`와 `Note` 인터페이스 추가, 컨트롤러에서 태그 추가 서비스를 호출하는 코드가 제시된다. - 에이전트 모드의 장점은 한 파일의 코드 생성이 아니라 여러 파일에 걸친 변경을 조정하고 일관성을 유지하는 데 있다. ## 안전한 스키마 마이그레이션 - 중요한 것은 SQL 문법 자체보다 변경을 운영 환경에 안전하게 적용하는 전략이다. - 마이그레이션은 다음 조건을 고려해야 한다. - 기존 클라이언트와 호환될 것 - 변경을 되돌릴 수 있을 것 - 높은 부하에서도 안전할 것 - 의존 시스템에 변경 사항이 투명하게 전달될 것 - Copilot에게 마이그레이션을 작성하게 하기 전에 호환성, 가역성, 부하 상황을 기준으로 설계를 검토하게 하는 것이 바람직하다. ## 실용적인 활용 방식 Copilot에게 곧바로 “코드를 작성하라”고 요청하기보다, 먼저 구조 분석과 영향 범위 파악을 시킨 뒤 구현·테스트·문서화까지 단계적으로 진행하는 방식이 효과적이다. 생성된 결과는 반드시 개발자가 계약, 마이그레이션, 회귀 가능성, 운영 환경의 위험을 직접 검토해야 한다.

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

software-architectureTypeScriptgithub-copilotAPI 설계+3

airbnb·2026년 1월 12일원문

현지인처럼 결 (새 탭에서 열림)

Airbnb는 전 세계 220개 이상의 국가에서 결제 편의성을 높이고 전환율을 개선하기 위해 14개월 만에 20개 이상의 지역 결제 수단(LPM)을 성공적으로 도입했습니다. 이를 위해 기존의 모놀리식 시스템을 도메인 주도 서비스 체계로 현대화하고, 다양한 결제 방식을 표준화된 인터페이스로 처리할 수 있는 기술적 기반을 마련했습니다. 결과적으로 복잡한 지역별 결제 환경을 추상화함으로써 확장성 있는 글로벌 결제 플랫폼을 구축하고 비즈니스 성장을 가속화했습니다. **현지 결제 수단(LPM) 도입의 전략적 가치** * **다양한 결제 수단 수용:** 신용카드 외에도 국가별 디지털 지갑(M-Pesa), 실시간 계좌 이체(Pix, UPI), 지역 결제망(Cartes Bancaires) 등 사용자에게 익숙한 수단을 제공합니다. * **접근성 및 전환율 증대:** 신용카드 보급률이 낮은 시장의 잠재 고객을 확보하고, 결제 단계에서의 이탈(friction)을 줄여 예약 전환율을 높입니다. * **체계적인 선정 프레임워크:** 전 세계 300개 이상의 결제 옵션 중 상위 75개 시장을 분석하고, 여행 서비스 적합도와 시장 점유율을 고려해 우선순위가 높은 20여 개를 선정했습니다. **결제 플랫폼 현대화 및 MST 프레임워크** * **서비스 지향 아키텍처(LTA):** 모놀리식 구조를 도메인 주도 아키텍처로 전환하여 결제 처리, 정산, 장부 관리 등 기능을 독립적인 서비스로 분리했습니다. * **커넥터 및 플러그인 구조:** 새로운 결제 서비스 제공업체(PSP)를 연동할 때 코드 재사용성을 높이고 시장 진입 시간을 단축하기 위해 플러그인 방식의 아키텍처를 채택했습니다. * **멀티스텝 트랜잭션(MST):** 업체마다 제각각인 결제 단계를 표준화하기 위해 MST 프레임워크를 도입했습니다. 리다이렉션이나 추가 인증이 필요한 경우 이를 'ActionPayload'로 규격화하여 처리합니다. **세 가지 표준화된 결제 흐름 모델** * **리다이렉트(Redirect) 흐름:** 네이버페이나 GoPay처럼 사용자를 외부 앱이나 웹사이트로 이동시켜 결제를 완료한 후, 다시 에어비앤비로 돌아와 토큰 기반으로 최종 확정하는 방식입니다. * **비동기(Async) 흐름:** Pix나 Blik과 같이 사용자가 QR 코드를 스캔하거나 푸시 알림을 통해 외부에서 결제하면, PSP가 에어비앤비에 웹훅(Webhook) 통보를 보내 상태를 업데이트하는 방식입니다. * **직접(Direct) 흐름:** 애플페이나 특정 로컬 카드처럼 에어비앤비 인터페이스 내에서 직접 결제 정보를 입력하고 실시간으로 처리하는 표준적인 방식입니다. **결제 오케스트레이션 및 데이터 무결성** * **외부 세션 제어:** 타사 앱 전환 시 발생하는 세션 핸드오프와 동기화 문제를 해결하기 위해 견고한 결제 오케스트레이션 로직을 설계했습니다. * **웹훅 기반 상태 관리:** 비동기 결제의 경우, 사용자 화면의 상태와 실제 결제 완료 상태를 일치시키기 위해 안정적인 웹훅 수신 체계를 구축했습니다. * **시장별 최적화:** 한국의 네이버페이처럼 높은 점유율을 가진 수단을 우선 도입하여 현지 사용자의 결제 경험을 네이티브 수준으로 개선했습니다. 글로벌 확장을 준비하는 엔지니어링 팀은 결제 시스템 설계 시 처음부터 '추상화'와 '표준화'에 집중해야 합니다. 지역별 결제 수단은 기술적 구현 방식이 모두 다르지만, 이를 리다이렉트, 비동기, 직접 흐름으로 범주화하여 공통 프레임워크(MST) 내에 수용함으로써 신규 결제 수단 추가에 드는 비용을 획기적으로 낮출 수 있습니다.

software-architecture마이크로서비스api-integrationwebhooks+3

woowahan·2025년 12월 5일원문

기획부터 개발까지 전부 직접 했습니다 – 우테코 7기 크루 서비스 론칭! | 우아한형제들 기술블로그 (새 탭에서 열림)

우아한테크코스 7기 크루들이 기획부터 디자인, 개발 및 운영까지 전 과정을 직접 수행하며 실제 사용자를 위한 서비스를 성공적으로 론칭했습니다. 이번 프로젝트는 단순한 기술 습득을 넘어 개발자가 왜 기획과 디자인에 참여해야 하는지, 그리고 사용자 피드백이 아키텍처와 도메인 설계에 어떤 영향을 미치는지 몸소 체험하는 과정이었습니다. 결과적으로 크루들은 2주 단위의 스프린트와 실시간 모니터링, 배포 환경 구축 등 실무에 근접한 경험을 통해 현장 중심의 문제 해결 역량을 갖춘 개발자로 성장했습니다. **개발자 중심의 기획과 협업 문화의 정착** - 우아한테크코스는 레벨 3, 4 과정을 통해 개발자가 직접 기획과 디자인을 포함한 서비스의 전주기를 책임지는 팀 프로젝트를 진행합니다. - 기술적인 구현뿐만 아니라 말하기, 글쓰기 교육을 병행하여 팀원 간의 의견 조율 및 설득 등 소프트 스킬의 중요성을 강조합니다. - 아키텍처 설계와 같은 기술적 결정이 팀의 목표와 사용자의 가치에 어떻게 부합해야 하는지 고민하며 개발자의 역할을 확장했습니다. **픽잇(Pickeat): 취향과 제약을 반영한 협업형 식사 선택 서비스** - "아무거나"라는 답변 뒤에 숨겨진 기피 음식과 다이어트 등의 제약 사항을 실시간 투표로 해결하여 최적의 식당을 추천합니다. - 위치 정보 기반의 식당 자동 조회 및 템플릿 기능을 도입하여 반복되는 회식이나 미팅 시 의사결정 속도를 높였습니다. - 데모데이와 홍보를 통해 받은 피드백을 바탕으로 UI와 백엔드 도메인 구조를 유연하게 재설계하며 사용자 중심의 반복적인 개선 과정을 거쳤습니다. **보따리(Bottari): 실시간 동기화 기반의 상황별 체크리스트** - 출근, 여행, 이사 등 다양한 상황에 맞춘 템플릿 기반 리스트 생성과 팀 단위의 실시간 협업 체크 기능을 제공합니다. - 단순한 기능 구현을 넘어 사용자가 물건을 잊지 않게 돕는 알림 타이밍과 체크 상태 동기화 등 사용자 경험(UX)의 세부 요소를 정밀하게 다듬었습니다. - '기술은 문제를 해결하는 도구'라는 철학 아래 사용자가 안심하고 기억을 맡길 수 있는 흐름을 구현하는 데 집중했습니다. **커피빵(Coffee Bread): 웹소켓 기반의 실시간 내기 미니게임** - 가위바위보보다 더 큰 재미와 긴장감을 주기 위해 실시간 미니게임과 가중치 적용 룰렛 시스템을 도입한 서비스입니다. - 웹소켓(WebSocket) 기술과 분산 환경이라는 기술적 난제를 극복하며 실시간 상호작용이 끊김 없이 이루어지도록 개발했습니다. - 게임의 공정성과 재미를 위해 룰렛 알고리즘을 수차례 수정하고, 실제 사용자들의 피드백을 반영해 밸런스를 최적화했습니다. 이 서비스들은 단순한 교육용 프로젝트를 넘어 실제 배포와 운영을 거치며 기술적 완성도를 높였습니다. 개발자가 기획 단계부터 깊이 관여할 때 사용자에게 더욱 가치 있는 프로덕트가 탄생한다는 점을 시사하며, 실무적인 문제 해결 역량을 키우고 싶은 주니어 개발자들에게 좋은 협업의 귀감이 됩니다.

software-architectureAndroid분산 시스템monitoring+4

toss·2025년 11월 13일원문

100년 가는 프론트엔드 코드, SDK (새 탭에서 열림)

토스페이먼츠는 결제 연동의 복잡성을 해결하기 위해 SDK를 제공하고 있으며, 최근 V1의 한계를 극복하고 안정성과 확장성을 극대화한 V2 SDK를 구축했습니다. 가맹점의 다양한 런타임 환경과 예측 불가능한 요구사항에 대응하기 위해 단순한 기능 구현을 넘어 체계적인 아키텍처와 모니터링 시스템을 도입했습니다. 결과적으로 개발자에게는 쉬운 연동 경험을, 비즈니스에는 견고한 신뢰성을 제공하는 결제 생태계를 완성했습니다. **SDK 개발의 특수성과 V1의 한계** * **환경의 의존성:** SDK는 가맹점의 코드 내에서 실행되므로, 가맹점의 호출 빈도나 네트워크 상태에 직접적인 영향을 받습니다. 일례로 사용량 분석을 위해 추가한 로그 코드가 특정 가맹점의 잦은 호출과 맞물려 네트워크 병목 현상을 일으키고 서비스 전체를 다운시키는 사례가 발생했습니다. * **런타임 예측 불가능성:** 가맹점에서 잘못된 데이터 타입(예: String 대신 Number)을 전달할 경우 `startsWith` 같은 표준 메서드에서 에러가 발생하는 등, 일반적인 프론트엔드 개발보다 훨씬 방어적인 코딩이 요구됩니다. * **커뮤니케이션의 접점:** SDK는 단순히 API를 호출하는 도구가 아니라 가맹점 개발자와 만나는 기술적 창구이며, 가맹점의 수많은 커스텀 요구사항을 수용해야 하는 복잡성을 안고 있습니다. **안정성 확보를 위한 테스트와 모니터링** * **촘촘한 테스트 체계:** 로직 검증을 위한 300개 이상의 단위 테스트와 다양한 유즈케이스를 반영한 500개 이상의 E2E 통합 테스트를 통해 코드 수준의 안정성을 확보했습니다. * **Global Trace ID:** 프론트엔드부터 백엔드까지 결제 전 과정을 하나의 식별자로 추적하는 체계를 도입하여, 장애 발생 시 시스템 레이어 전체를 쉽게 파악할 수 있도록 했습니다. * **모니터링 CLI:** 배포 전후의 결제 성공률을 가맹점 및 런타임 환경(OS, 브라우저, 웹뷰 등)별로 비교 분석하는 자체 도구를 개발했습니다. 이를 통해 특정 환경에서 발생하는 결제 중단 현상을 실시간으로 탐지하고 즉각 대응합니다. **확장성을 위한 레이어드 아키텍처** * **조립 가능한 구조:** 특정 가맹점만을 위한 예외 처리가 `if`문으로 산재되어 코드 복잡도가 올라가는 문제를 해결하기 위해, 기능을 레고 블록처럼 독립적으로 구성했습니다. * **3계층 분리:** "변경의 원인"을 기준으로 코드의 경계를 명확히 나누어 관리합니다. * **Public Interface Layer:** 가맹점과 약속한 인터페이스를 검증하고 도메인 언어로 번역하는 역할 * **Domain Layer:** 핵심 비즈니스 로직과 결제 정책을 담당하는 중심부 * **External Service Layer:** 서버 API나 Web API 등 외부 의존성과의 통신을 담당하는 계층 * **관심사 격리:** 이러한 계층화를 통해 가맹점별 커스텀 요구사항이 추가되더라도 기존의 핵심 로직에 영향을 주지 않고 특정 블록만 교체하거나 확장할 수 있는 유연성을 확보했습니다. 성공적인 SDK 개발을 위해서는 단순히 편리한 기능을 제공하는 것을 넘어, 타사의 코드 환경에서도 견고하게 동작할 수 있는 방어적인 설계와 문제 발생 시 즉시 원인을 파악할 수 있는 관측성(Observability) 확보가 필수적입니다. 가맹점별 특이 케이스를 코드 전반에 흩뿌리기보다는, 명확한 레이어 구분을 통해 비즈니스 로직과 커스텀 로직을 분리하는 설계 원칙을 권장합니다.

software-architecture옵저버빌리티TypeScriptelasticsearch+3

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가 만든 다이어그램은 초안이므로 기술적 정확성과 일정의 현실성은 담당자가 반드시 확인해야 한다.

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

software-architectureFigmafigjamReact+4

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

피그마의 엔지니어

Figma는 엔지니어링 팀이 커져도 협업 방식과 핵심 문화를 유지하기 위해 팀의 가치를 명문화했다. 이 가치는 이상적인 목표가 아니라 팀이 이미 실천한다고 판단한 행동 기준이며, 각 가치에는 다른 선택을 포기하는 트레이드오프가 포함된다. 특히 조기 소통과 팀 구성원 간의 성장을 통해 개인의 성과보다 지속 가능한 협업을 중시한다. ## 엔지니어링 가치를 만든 이유 - 팀이 확장될수록 기존의 협업 방식과 문화를 유지하기 어려워진다. - 자신과 비슷한 사람만 채용하는 ‘단일문화(monoculture)’를 피하면서도 중요한 업무 방식을 보존해야 했다. - 모든 구성원이 행동, 우선순위, 프로세스, 팀 전통, 회사의 경쟁력과 미래에 대해 논의한 뒤 네 가지 가치를 정리했다. - 가치는 “좋은 코드를 작성하자”처럼 누구나 반대하기 어려운 추상적 문구가 아니라, 실제 의사결정에 사용할 수 있는 구체적인 기준이어야 한다. - 각 가치에는 포기하는 것이 있다. 즉, 가치가 무엇을 우선하는지뿐 아니라 무엇을 감수하는지도 분명히 해야 한다. ## 일찍, 자주 소통하기 - 코드 리뷰 시점까지 기다리지 말고 설계 문서, 제품 사양, 아키텍처 초안 등을 작업 초기에 공유한다. - 문제를 혼자 해결한 뒤 결과를 발표하기보다, 여러 사람이 함께 방향을 검토하도록 한다. - 초기 공유를 통해 잘못된 가정을 빠르게 발견하고, 큰 비용을 들이기 전에 방향을 수정할 수 있다. - 미완성 작업을 공유하는 문화를 만들면 도움을 요청하기 쉬워지고, 공유하는 사람과 동료 모두에게 자연스러운 학습 기회가 생긴다. - 소통 방식이 반드시 정해진 절차일 필요는 없다. 어떤 경우에는 코드 자체가 가장 효과적인 의사소통 수단이며, 단순한 버그 수정에는 여러 사전 논의가 필요하지 않다. - 조기 공유는 다른 사람의 의견을 실제로 받아들일 때만 효과가 있다. 의견 충돌이 생겨도 일찍 공유하면 방향 전환 비용을 줄일 수 있다. - 모든 의견을 폭넓게 듣는 대신 의사결정이 느려지고, 논의와 조율에 많은 시간이 걸릴 수 있다는 트레이드오프가 있다. ## 팀을 성장시키기 - 자신의 성공만이 아니라 주변 동료의 성공과 행복을 함께 우선한다. - 팀을 돕는다는 것은 회사의 성과를 위해 자신을 희생하는 것이 아니라, 지속 가능한 방식으로 동료 엔지니어를 성장시키는 것을 뜻한다. - 기술 발표, 온보딩 멘토링, 새로운 기술 학습 장려 등 지속적인 학습과 성장을 지원한다. - 피드백은 사람을 공격하지 않고 아이디어와 작업에 초점을 맞춰야 한다. - 모욕적이거나 상대를 깎아내리는 말은 효과적인 피드백이 아니며, 다양한 의견을 안전하게 제시할 수 있는 포용적 문화를 만들어야 한다. - 구성원 간의 긍정적이고 존중하는 관계를 통해 서로를 더 나은 엔지니어로 만든다. - 이 가치의 핵심은 경쟁에서 개인이 앞서는 것이 아니라, 함께 일하는 사람들이 더 나아지도록 돕는 ‘팀 중심’의 성공이다. 팀의 가치는 벽에 걸어두는 선언문보다 실제 설계 공유, 피드백, 멘토링, 의사결정에서 반복적으로 적용되는 기준이어야 한다. 조직에 도입할 때는 추상적인 구호보다 구체적인 행동과 감수할 트레이드오프까지 함께 정의하는 것이 좋다.

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

software-architecturecollaboration코드 리뷰software-engineering+2