webhooks

9 개의 포스트

kakao

Vibe Coding하는 비개발자는 개발자인가(3) (새 탭에서 열림)

AI 에이전트는 비개발자에게 단순히 코드를 생성해주는 도구를 넘어, 업무를 실행 가능한 구조로 재정의하게 만드는 동반자다. 글쓴이는 로컬 HTML 도구를 공유 서비스로 확장하고, 스프레드시트·웹훅·환경변수·스킬·MCP 등을 활용하며 입력과 출력, 권한, 보안, 검증 조건을 자연스럽게 고민하게 되었다고 말한다. 결국 중요한 것은 코딩 능력 자체보다 자신의 업무를 AI가 수행할 수 있는 단위와 규칙으로 구조화하는 능력이다. ## 로컬 HTML에서 공유 데이터 도구로 - 초기 도구는 브라우저에서 실행하는 단일 HTML 파일이었다. - 서버와 데이터베이스가 필요 없고 혼자 사용하기에 충분했다. - 다른 사람과 공유하려면 배포 주소, 최신 버전 반영, 데이터 저장 문제가 생겼다. - 정적인 화면을 넘어 다음 요구사항이 발생했다. - 과거 입력값 조회 - 여러 사용자의 데이터 공유 - 상태 변경에 따른 화면 갱신 - 사용자별 조회·수정 권한 관리 - 잘못된 수정의 복구와 데이터 백업 - 정식 데이터베이스는 접근 권한 설계와 운영·보안 부담이 컸다. - 대신 구글 스프레드시트를 공유 데이터 저장소로 활용했다. - 기존 협업 UI와 권한 관리 기능을 이용할 수 있었다. - 수정 이력과 공유 기능도 이미 제공됐다. - Apps Script 코드를 직접 붙여넣는 방식에서 시작해, 이후 `clasp`를 이용한 Apps Script API 기반 배포·실행 방식으로 발전했다. - 핵심 변화는 코드를 많이 작성한 것이 아니라, 데이터 위치·공유 방식·권한·변경 이력을 설계하기 시작했다는 점이다. ## 웹훅 연동과 보안 습관 - AI 에이전트의 도움으로 업무 환경과 연결되는 웹훅 봇을 구현할 수 있게 되었다. - 웹훅 URL과 토큰을 다루면서 다음 보안 원칙을 익히게 됐다. - 비밀값을 코드나 프롬프트에 직접 입력하지 않기 - `.env` 파일에서 환경변수로 읽기 - `.gitignore`로 저장소에 비밀값이 올라가지 않도록 하기 - 로그에 토큰 등 민감정보를 출력하지 않기 - 실제 비밀값 대신 placeholder 사용하기 - 작은 자동화라도 외부 시스템과 연결되는 순간 실행 환경과 접근 권한, 비밀값 관리가 함께 고려되어야 한다. - 보안은 별도의 전문 작업이 아니라 AI에게 코드를 요청할 때마다 반복하는 작업 습관이 되었다. ## 손작업을 명세와 파이프라인으로 바꾸기 - 파일 복사·정리, 문서 변환, 영상 편집, 음성 추출, 요약 등 기존의 수작업도 AI 에이전트에게 맡기기 시작했다. - 사람이 직접 할 때는 감으로 처리하던 작업도 에이전트에게 맡기려면 구체적인 명세가 필요했다. - 대상 입력 파일 - 결과 파일명과 저장 위치 - 기존 파일 덮어쓰기 여부 - 실패 시 중단 조건 - 결과의 정상 여부를 판단하는 검증 기준 - 이 과정에서 반복 업무가 다음과 같은 업무 단위로 분해됐다. - 입력 - 처리 단계 - 출력 - 예외 상황 - 검증 조건 - 자동화의 핵심은 명령어를 아는 것이 아니라, 한 단계가 완료되었다고 판단할 기준과 입력·출력 형식을 정의하는 데 있다. ## 회의록 스킬과 반복 판단의 축적 - 매주 반복되는 회의록 작성 과정에서 일정한 수정 패턴이 발견됐다. - 글쓴이는 Codex와 Claude의 `skill`을 만들어 회의 유형별 규칙을 저장했다. - 회의록의 출력 형식 - 결정사항과 액션 아이템 추출 방식 - PMO 관점에서 확인할 신호 - AI가 독단적으로 결론 내리지 않고 사용자에게 질문해야 하는 경우 - 스킬은 단순한 프롬프트 모음이 아니라 반복되는 판단 기준과 업무 규칙을 저장하는 장치였다. - AI가 초안을 작성하면 최종본과 비교해 개선점을 찾고, 그 결과를 다시 스킬에 반영하는 순환 구조를 만들었다. - 내부 데이터를 정리하다가 대화 기록을 잃어버린 사례도 있었다. - 스킬 파일은 남았지만 대화에 포함된 맥락이 사라져 성능이 일시적으로 저하됐다. - 반복 업무에서는 규칙뿐 아니라 맥락과 사례를 보존하는 것도 중요하다는 점을 보여준다. ## MCP와 스킬을 이용한 GA 리포트 자동화 - 기존에는 구글 애널리틱스(GA) 데이터를 확인하고 여러 대시보드를 만들어 인사이트를 도출하는 과정이 번거로웠다. - GA MCP를 통해 API로 데이터를 가져오고, 스킬로 월간 리포트 형식을 유지했다. - 지난달과 이번 달의 차이를 비교해 변화가 의미 있는지 판단하는 방식으로 리포트가 개선됐다. - MCP는 데이터를 가져오는 통로이고, 스킬은 반복되는 리포트 구조를 유지하는 장치다. - 중요한 것은 단순히 숫자를 요약하는 것이 아니라 다음을 판단하는 것이다. - 어떤 변화가 발생했는가 - 그 변화가 설명할 가치가 있는가 - 추가 조사가 필요한 신호인가 - AI의 분석 결과에 사용자의 업무 맥락을 결합하면 이전에는 발견하기 어려웠던 변화를 준실시간으로 탐지할 수 있다. ## 개발의 경계가 넓어지는 방식 - 변화의 본질은 AI 도구의 개수가 늘어난 것이 아니라, 기존 업무를 다른 구조로 바라보게 된 데 있다. - AI가 만든 결과물 자체보다 AI가 수행할 수 있도록 업무를 설명하는 방식이 중요해졌다. - 앞으로 더 많은 사람이 다음 요소를 일상적으로 고민하게 될 것으로 전망한다. - 입력과 출력 - 권한과 보안 - 반복 작업과 파이프라인 - 완료 조건과 검증 방법 - 이는 모든 사람이 전통적인 개발자가 된다는 뜻은 아니다. - 다만 비개발자의 업무도 점차 쪼개지고, 자동화되고, 실행 가능한 형태로 재정의될 수 있다. AI 에이전트를 효과적으로 활용하려면 “무엇을 만들어 달라”보다 “입력은 무엇이고, 결과는 어떤 형식이어야 하며, 실패와 보안 문제를 어떻게 처리할지”를 구체적으로 정의하는 것이 좋다. 반복되는 수정과 판단을 스킬이나 문서로 축적하고, 민감정보와 작업 맥락을 안전하게 관리하는 습관을 함께 갖추는 것이 실용적인 출발점이다.

line

AI는 QA를 대체하지 않았다, 대신 확장했다 (새 탭에서 열림)

생성형 AI는 QA를 대체하기보다 분산된 품질 정보를 구조화하고 QA의 사고 범위와 영향력을 확장한다. LINE Album QA는 AI를 단순한 문서 작성 도구가 아니라 Jira, Slack, 테스트 도구, 사용자 리뷰와 연결된 품질 워크플로로 재설계했다. 그 결과 AI는 반복적인 수집·분석·초안 작성을 담당하고, QA 엔지니어는 리스크 판단과 최종 의사 결정에 집중하게 됐다. ## QA의 본질은 테스트 실행이 아닌 품질 설계 - QA 엔지니어는 기획, 개발, 테스트, 릴리스 전 과정에서 품질 관점을 제공한다. - 기획 단계에서는 잠재 리스크를 식별하고, 개발 단계에서는 변경 사항의 영향 범위를 분석한다. - 릴리스 이후에는 사용자 리뷰와 운영 데이터를 제품 개선으로 연결한다. - 따라서 QA는 단순한 테스트 수행자가 아니라 제품 생명 주기를 연결하는 **품질 설계자(quality architect)**에 가깝다. - 생산성을 결정하는 핵심 요소는 테스트 속도보다 다음 정보를 얼마나 빠르게 구조화하고 맥락화하는가에 있다. - 기획·기술 문서 - Slack 논의와 의사 결정 - Jira 이슈와 작업 티켓 - 자동화 테스트 스크립트와 실행 로그 - 다국어 사용자 리뷰와 피드백 ## AI를 대화 도구에서 품질 워크플로로 전환 - 초기에는 AI를 문서 요약, 테스트 케이스 초안 작성, 버그 리포트 정리 등에 활용했다. - 그러나 사람이 정보를 수집해 AI에 입력해야 했기 때문에 개인 생산성 향상 이상의 효과에는 한계가 있었다. - LINE Album QA는 Jira 이슈 생성, PR 병합, 테스트 실행, 사용자 리뷰 수집 같은 품질 이벤트에 AI가 자동으로 반응하도록 운영 체계를 구축했다. - 현재 30개 이상의 워크플로가 운영되며, AI는 정보를 분석하고 구조화하는 품질 시스템의 일부로 작동한다. - QA 엔지니어는 정리 작업보다 결과를 기반으로 리스크를 판단하고 필요한 검증을 수행하는 데 집중한다. ## 스케줄링 기반 자동화 - 정해진 시간에 반복 실행하며 정기적인 품질 데이터를 수집·요약한다. - 주요 활용 사례: - App Store·Google Play 리뷰의 이슈 분류 및 요약 - API 자동화 테스트 결과 분석 및 Slack 공유 - UI 자동화 테스트 결과 리포트 생성 - 주간 QA 활동과 주요 이슈 보고서 작성 - QA가 여러 시스템에서 데이터를 직접 모으는 시간을 줄이고, 구조화된 결과를 바탕으로 판단할 수 있게 한다. ## 웹훅 기반 이벤트 트리거 - 품질 관련 이벤트가 발생하는 즉시 분석을 시작한다. - 주요 활용 사례: - PR 병합 후 코드 변경 내용과 잠재 영향 범위 요약 - Slack 논의 스레드 종료 후 의사 결정 회의록 생성 - 자동화 테스트 결과 업로드 후 실행 통계 분석 및 시각화 - 중요한 품질 신호를 정기 보고까지 기다리지 않고 빠르게 인지할 수 있다. ## 자동화된 QA 업무 흐름 - UI 자동화 테스트는 MagicPod으로 Android·iOS 테스트를 실행하고, 결과를 Jira와 Slack에 공유한다. - 테스트 실패 시 AI가 플레이키 테스트 여부와 실패 원인을 분석한다. - Pytest 기반 API 테스트도 동일하게 실행 결과를 Jira와 Slack에 자동 반영한다. - 데일리 스크럼 전에는 테스트 현황, 미해결 이슈, QA 확인 필요 항목, Jira 멘션을 자동으로 정리한다. - 앱 리뷰는 긍정·부정 여부를 분류하고 일본어·한국어로 번역·요약한 뒤 일별·월별로 공유한다. - QA 엔지니어는 집중 업무 시간에 자동 수집된 정보를 활용해 품질 계획과 테스트 전략을 수립한다. - AI가 데이터를 수집·분석하는 동안 QA는 최종 판단, 수동·자동 테스트, 워크플로 개선을 담당한다. ## AI와 테스트 케이스 설계 - 2026년 기준 전체 테스트 케이스의 약 90%는 AI가 초안을 생성한다. - 단순히 요구 사항만 입력하면 일반적인 정상 흐름과 예외 케이스는 만들 수 있지만, 제품의 실제 맥락과 과거 결함을 반영하기 어렵다. - 이를 보완하기 위해 다음 정보를 AI의 입력 맥락으로 연결했다. - 기능 명세와 개발 티켓 - 변경 배경 - 과거 Jira 이슈 - 테스트 이력 - 반복적으로 발생한 결함 패턴 - 오케스트레이터 에이전트와 5개 서브 에이전트가 역할을 나누어 테스트 설계를 수행한다. - **Plan-Analyzer**: 기획 문서, 기능 설명, 이미지에서 기본 흐름 분석 - **Dev-Analyzer**: 개발 티켓과 구현 정보 분석 - **TestCase-Generator**: 정상·예외·경계값·플랫폼 차이·우선순위를 반영한 테스트 생성 - **TestCase-Validator**: 요구 사항 커버리지, 추적 가능성, Given/When/Then 형식, 플랫폼 커버리지 검증 - **Quality-Inspector**: 이전 피드백과 품질 평가를 반영해 다음 실행의 개선점 축적 - 과거에 실제로 발생한 결함 패턴까지 참고해 명세에 없는 유사 결함 시나리오도 확장한다. - 검증 결과가 부족하면 생성 단계로 피드백을 보내는 반복 루프를 통해 실행 가능한 테스트 케이스로 다듬는다. ## 실용적인 결론 AI 도입의 핵심은 테스트 케이스를 많이 생성하는 데 있지 않고, 기획·개발·운영·사용자 피드백을 연결해 품질 판단에 필요한 맥락을 자동으로 제공하는 데 있다. 효과적인 QA 자동화를 위해서는 AI를 개별 도구로 사용하기보다 품질 이벤트를 감지하고 분석·공유하는 워크플로로 통합해야 하며, 최종 리스크 판단과 의사 결정은 QA가 담당하는 구조가 바람직하다.

airbnb

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

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) 내에 수용함으로써 신규 결제 수단 추가에 드는 비용을 획기적으로 낮출 수 있습니다.

discord

디스코드 패치 노트: 2025년 8월 4 (새 탭에서 열림)

Discord의 2025년 8월 4일 패치 노트는 성능, 검색, 키보드·입력 처리, 미디어 다운로드, 플랫폼 연동과 다양한 UI 버그 수정을 다룬다. 특히 Android 키보드 동작, Tumblr 임베드, 스레드 검색, 대용량 계정의 성능, Mac Spotlight·Apple Handoff 지원이 주요 변경 사항이다. 일부 수정 사항은 플랫폼별로 순차 배포 중일 수 있다. ## 주요 기능 개선 - 채널별 고정 메시지 최대 개수가 **50개에서 250개**로 증가했다. - 통화 중 Desktop의 User Settings 버튼을 누르면 바로 **Voice & Video 설정**으로 이동한다. - Tumblr 콘텐츠 전반에 대한 임베드가 지원된다. - 일반 Tumblr 링크뿐 아니라 Tumblr 외부 도메인에 호스팅된 사이트도 지원한다. - 스레드 검색 기능이 추가됐다. - 스레드 내부 메시지를 검색할 수 있다. - 검색어의 `in:` 필터로 스레드 이름을 자동완성할 수 있다. ## Android 키보드 및 미디어 처리 - Android에서 이모지 키보드, 갤러리, 시스템 키보드 간 상호작용을 개선했다. - 앱을 다시 foreground로 전환할 때 키보드가 메시지를 가리던 문제를 수정했다. - 멀티태스킹 및 폴더블 기기에서 키보드가 화면을 과도하게 가리던 문제를 해결했다. - 다른 플랫폼의 임베드 이미지와 동영상 다운로드 안정성을 높였다. - 다운로드 실패가 줄어든다. - `@jpeg.bin.jpg`처럼 잘못된 확장자를 가진 파일이 생성되는 문제를 수정했다. ## 대규모 사용 계정의 성능 개선 - 극도로 많은 데이터를 사용하는 계정에서 발생하던 앱 실행 지연과 성능 저하를 개선했다. - 다음 영역을 중심으로 최적화했다. - GDM 검색 - DM 정리 - 대량의 친구·관계 작업 처리 - 일반 사용자보다 관계 수와 메시지가 매우 많은 파워 유저에게 효과가 클 것으로 보인다. ## macOS 및 Apple 플랫폼 연동 - macOS Spotlight에서 Discord 서버나 채널 이름을 검색해 해당 채널로 바로 이동할 수 있다. - Apple 기기 간 Handoff를 지원한다. - 한 기기에서 보던 채널을 다른 Mac, iPad, iPhone의 Dock이나 앱 전환기에서 이어서 열 수 있다. ## 검색 및 탐색 관련 수정 - iOS 검색 필터 제안이 선택한 필터와 무관한 결과를 표시하던 문제를 수정했다. - 예를 들어 사용자 검색 중 채널 이름이 표시되는 문제가 해결됐다. - Desktop 검색 자동완성에서 카테고리 이름 정렬이 어긋나던 문제를 수정했다. - 사용자명 자동완성이 첫 번째 일치 항목만 과도하게 고정하던 동작을 완화했다. - Desktop 알림을 클릭해도 앱으로 제대로 이동하지 않던 문제를 해결했다. - 채널 설정에서 뒤로 가기 제스처가 채팅 화면까지 지나치게 이동하던 문제를 수정했다. ## 서버·역할·권한 기능 - Role Settings의 역할 우클릭 메뉴에 **Delete Role** 기능을 추가했다. - 모바일 Role Settings에서 역할 정렬이 다시 작동한다. - 권한 없이 초대 링크를 만들려고 할 때 표시되는 안내 문구를 더 구체적으로 변경했다. - 초대 수락 버튼에 다시 초대를 수락할 사용자명이 표시된다. - 조건에 맞지 않는 짧은 서버 템플릿 이름을 입력하면 오류가 표시된다. - Server Onboarding을 닫은 뒤 다른 화면으로 이동했다 돌아와도 해제 상태가 유지된다. - Student Hubs의 생략 부호 메뉴가 다시 작동한다. - Desktop에서 대기 중인 친구 요청이 사용자 프로필에 다시 표시된다. ## UI 및 시각적 버그 수정 - Invite permission required 모달의 “Got It” 버튼 정렬을 수정했다. - Server Tag 미리보기에서 아바타 뒤에 표시되던 blurple 배경을 제거했다. - Clips 팝업, 사용자 프로필, User Settings 등의 여백과 패딩 문제를 해결했다. - Desktop 시스템 트레이 아이콘이 업데이트 후 숨겨지던 문제를 수정했다. - 채널 사이드바 구분선을 클릭하면 폭이 미세하게 늘어나던 문제를 해결했다. - 모바일 Server Onboarding의 배경 그라데이션 색상 문제를 수정했다. - 모바일의 공식 계정 `OFFICIAL` 배지와 부스트 아이콘 정렬을 조정했다. - iOS에서 이모지 상세 화면과 메시지 미리보기의 이모지가 잘리던 문제를 해결했다. - PiP 설정이 PiP 창 뒤에서 열리던 문제를 수정했다. - 서버 검색 아이콘, 서버 발견 아이콘, 역할 간격 등 다양한 정렬 문제를 보완했다. ## 메시지·언어·날짜 표시 수정 - 일본어가 채널 이름에서 올바르게 표시되지 않던 문제를 수정했다. - Burmese Unicode 텍스트가 전송 중 변형되거나 삭제되던 문제를 해결했다. - 이벤트 설명의 마스킹 링크가 모바일에서 제대로 렌더링되지 않던 문제를 수정했다. - Mod View의 날짜가 설정과 관계없이 `MM/DD/YYYY` 형식으로 표시되던 문제를 해결했다. - 일부 리액션 이모지가 빈칸으로 표시되던 일시적 문제를 수정했다. - Android와 iOS의 커스텀 상태 입력창 정렬을 개선했다. - 음성 메시지의 볼륨 슬라이더가 사라지지 않던 문제를 해결했다. 이번 업데이트는 새로운 대형 기능보다는 검색·입력·탐색 경험과 플랫폼별 안정성 개선에 초점을 맞춘 릴리스다. 특히 스레드를 자주 사용하는 사용자는 `in:` 검색을 활용하고, 대규모 서버나 많은 DM을 관리하는 사용자는 성능 개선 여부를 확인해볼 만하다.

discord

디스코드 소셜 SDK 업데이트 및 (새 탭에서 열림)

Discord Social SDK는 게임 안에 Discord 기반 소셜 기능을 통합해 플레이어 간 연결과 커뮤니케이션을 강화하는 무료 개발 도구다. 2025년 3월 출시 이후 Rich Presence, 콘솔 지원, 콘텐츠 조정, DM 제어, 웹훅, 요청 시간 초과 설정 등이 추가됐다. Rust 사례에서는 게임 내 채팅과 친구 간 협업이 증가했으며, Discord는 초기 파트너 피드백을 바탕으로 SDK와 문서를 개선하고 있다. ## Discord Social SDK의 주요 업데이트 - **Rich Presence 개선** - 활동 카드에 사용자 지정 버튼을 추가할 수 있다. - 게임 초대나 특정 게임 기능으로 연결되는 상호작용을 확장할 수 있다. - **Unity·Unreal 콘솔 지원** - 콘솔 환경을 위한 패키징과 문서가 개선됐다. - 다양한 플랫폼에서 SDK를 통합하기 쉬워졌다. - **콘텐츠 조정 기능** - 게임 내 소셜 기능에 콘텐츠 조정 기능을 통합하고 관리하는 방법이 추가 문서로 제공된다. - 커뮤니케이션 기능을 운영할 때 필요한 관리 체계를 지원한다. - **플레이어 커뮤니케이션 제어** - 게임 내 DM 제어 기능이 강화됐다. - 플레이어가 자신의 커뮤니케이션 선호도를 보다 세밀하게 설정할 수 있다. - 온라인 상태나 게임 플레이 정보의 공개 범위도 조정할 수 있도록 개선됐다. - **계정 연동 상태 관리** - 사용자가 Discord 계정 연결을 해제하거나 애플리케이션 권한을 철회하면 웹훅 알림을 받을 수 있다. - API 요청에 대해 설정 가능한 타임아웃을 지정할 수 있다. ## Rust에 적용한 통합 사례 - **배경** - Facepunch Studios는 Rust의 초기 Social SDK 파트너였다. - Rust는 출시 10년 이상 된 게임으로, 2,000만 장 이상의 판매량과 주간 활성 사용자 100만 명 이상을 보유하고 있다. - **목표와 과제** - 게임 안의 플레이어와 게임 밖의 친구가 더 쉽게 소통하도록 만드는 것이 목표였다. - 기존 플레이어층이 크고 안정적인 상황에서, Facepunch가 처음으로 게임 내 소셜 기능을 도입하는 프로젝트였다. - 기존 게임 경험을 해치지 않으면서 플레이어가 자연스럽게 새 기능을 사용하도록 유도해야 했다. - **적용한 기능** - **통합 친구 목록**을 통해 게임 내 친구와 Discord 친구를 함께 확인할 수 있게 했다. - **크로스 플랫폼 메시징**으로 게임을 종료하거나 Alt-Tab하지 않고도 친구와 대화할 수 있게 했다. - Discord 계정을 게임에 연결한 플레이어에게 독점적인 게임 내 보상을 제공했다. - **결과** - 계정 연동 보상은 초기 사용자를 확보하는 계기가 됐다. - 기능을 직접 사용해 본 플레이어들은 이후에도 소셜 기능을 지속적으로 이용했다. - Rust의 게임 내 채팅 활동이 크게 증가했고, 플레이어들이 친구와 팀을 구성해 플레이하는 흐름이 강화됐다. ## 초기 파트너십을 통한 개선 - Rust 등 초기 통합 사례에서 얻은 피드백을 바탕으로 SDK를 보완했다. - 플레이어가 자신의 게임 플레이 상태를 누가 볼 수 있는지 제어할 수 있도록 했다. - Discord 계정이 없는 플레이어도 기능 이용 과정에서 일관된 경험을 하도록 고려했다. - 계정 접근 문제와 연동 과정의 오류를 해결하기 위한 지원과 문서도 개선했다. ## GDC 2025에서 소개된 개발자 사례 - Discord는 GDC 2025에서 게임 개발자와 파트너를 위한 발표와 세션을 진행했다. - Discord의 규모와 게임 생태계가 강조됐다. - 월간 활성 사용자 약 2억 명 - 매월 20억 시간 이상의 게임 활동 - SUPERVIVE 개발사 Theorycraft Games는 Discord를 커뮤니티 개발과 플레이테스트의 중심 플랫폼으로 활용한 과정을 소개했다. - Discord Social SDK를 통해 다음과 같은 기능을 구현했다. - Discord 친구를 게임의 기존 소셜 그래프에 통합 - Discord Rich Presence를 활용한 파티 초대 - 플레이어 간 연결과 커뮤니케이션 개선 - 커뮤니티 피드백과 게임 개발 프로세스 연계 게임 개발자는 Social SDK 도입 시 단순한 계정 연동보다 친구 목록, 메시징, 초대, 상태 공개 설정을 게임의 핵심 플레이 흐름에 자연스럽게 연결하는 것이 좋다. 또한 Rust 사례처럼 독점 보상으로 초기 사용을 유도하되, 개인정보 제어·계정 해제·콘텐츠 조정·Discord 미가입자 지원까지 함께 설계해야 지속적인 사용으로 이어질 가능성이 높다.

discord

게임 개발자 플레이북: 세 (새 탭에서 열림)

Discord의 게임 개발자 플레이북은 커뮤니티 운영에 절대적인 “모범 사례”가 있기보다, 각 서버의 목적과 이용자에 맞게 다른 커뮤니티의 아이디어를 변형해야 한다고 강조합니다. 성공 여부는 회원 수보다 실제 참여와 대화 수준으로 판단해야 하며, 서버 탐색 기능을 통해 다양한 사례를 참고할 것을 권장합니다. 이 글은 Fortnite, Rocket League, Deep Rock Galactic의 공식 서버를 사례로 들지만, 제공된 내용에서는 Fortnite 서버 운영 방식과 게임 세계관 연계 사례가 중심적으로 소개됩니다. ## 커뮤니티 운영의 기본 원칙 - 모든 서버에 동일하게 적용되는 정답은 없으며, 커뮤니티의 목적과 이용자 특성에 맞게 구조를 설계해야 합니다. - Discord의 **Server Discovery**를 활용해 비슷한 주제의 서버뿐 아니라 게임과 무관한 서버에서도 운영 아이디어를 얻을 수 있습니다. - 회원 수보다 중요한 지표는 다음과 같은 실제 참여도입니다. - 회원 간 대화 빈도 - 채널 활동량 - 커뮤니티에 지속적으로 기여하는 정도 - 서버는 개설 이후에도 커뮤니티의 성장과 요구에 맞춰 계속 진화해야 합니다. - 플레이테스트, 얼리 액세스, 출시 전 단계 등 개발 과정별로 서버의 역할과 운영 방식도 달라질 수 있습니다. ## Fortnite 서버의 명확한 구조 Fortnite 서버는 대규모 회원을 보유하면서도 신규 이용자가 서버에서 무엇을 얻을 수 있는지 쉽게 이해할 수 있도록 구성된 사례로 소개됩니다. - 서버의 주요 카테고리는 뉴스, LFG, 토론, 버그 정보·신고, 커뮤니티 지원 등 여러 기능별 영역으로 나뉩니다. - 카테고리와 채널을 무작정 늘리기보다, 이용자가 목적에 맞는 공간을 빠르게 찾을 수 있도록 구성합니다. - 대규모 서버일수록 정보 구조가 단순하고 예측 가능해야 신규 이용자의 진입 장벽을 낮출 수 있습니다. ### 뉴스와 공지 - **News** 카테고리는 Fortnite와 관련된 여러 업데이트를 한곳에 모으는 역할을 합니다. - `#announcements`는 Discord에서만 전달하는 고유 공지에 사용합니다. - 다른 채널은 웹훅을 통해 공식 웹사이트나 소셜 미디어의 소식을 수집할 수 있습니다. - 다만 자동 게시에만 의존하지 말고, Discord 이용자에게 맞춘 독창적인 공지를 직접 작성하는 것이 좋습니다. ### LFG와 음성 채널 - **LFG(Looking for Group)** 카테고리는 함께 플레이할 팀원을 찾는 공간입니다. - Fortnite의 플레이리스트와 게임 모드별로 채널을 나누어 이용자가 자신의 플레이 목적에 맞는 곳을 선택하게 합니다. - 이용자는 원하는 팀원의 조건과 플레이 정보를 게시한 뒤 음성 채널에서 함께 게임을 시작할 수 있습니다. - 게임 모드가 다양할수록 LFG 채널을 세분화하면 매칭과 대화의 효율이 높아집니다. ### 토론 채널 - **Discussion** 카테고리는 특정 주제별 대화를 지원합니다. - 주제는 충분히 구체적이어야 하지만, 지나치게 많은 채널로 나누어 신규 이용자를 혼란스럽게 만들지 않아야 합니다. - 채널 분류는 이용자의 실제 대화 목적과 커뮤니티에서 반복적으로 발생하는 논점을 기준으로 정하는 것이 효과적입니다. ### 버그 정보와 신고 - 알려진 문제를 별도 채널에서 정리해 이용자가 이미 보고된 버그를 먼저 확인할 수 있도록 합니다. - 새로운 버그를 신고하는 방법을 단계별 안내문으로 제공합니다. - 게임 모드별로 신고 채널을 나누면 피드백을 분류하고 검토하기 쉬워집니다. - 신고 양식을 미리 제공하면 다음 정보를 일관되게 수집할 수 있습니다. - 문제가 발생한 게임 모드 - 재현 절차 - 발생 상황과 오류 내용 - 관련 이미지나 영상 - 일관된 템플릿은 이용자와 운영팀 모두의 처리 부담을 줄입니다. ### 커뮤니티 지원 - 이용자끼리 서로 질문에 답하고 문제를 해결할 수 있는 채널을 마련합니다. - 봇과 외부 지원 도구를 활용하면 반복적인 질문에 자동으로 답하거나, 중요한 피드백을 지원팀으로 전달할 수 있습니다. - Zendesk와 Helpshift처럼 Discord에서 플레이어 지원을 확장할 수 있는 서비스도 활용할 수 있습니다. ## Discord를 게임 세계관의 확장 공간으로 활용 Fortnite는 Discord를 단순한 공지·채팅 공간이 아니라 게임 세계관의 일부처럼 운영한 사례로 제시됩니다. - 게임의 스토리와 마케팅 캠페인을 서버 아이콘, 배너, 역할, 봇 메시지 등에 반영할 수 있습니다. - 이렇게 하면 이용자는 Discord에서도 게임의 사건과 단서를 경험하게 됩니다. - 서버 자체가 게임의 분위기와 서사를 전달하는 “확장된 게임 공간”으로 기능할 수 있습니다. ### 시즌 출시 전 미스터리 캠페인 Chapter 2 Season 2 출시 당시 Fortnite는 “Top Secret” 테마를 활용해 Discord에서 이용자의 추측과 참여를 유도했습니다. - 서버 아이콘과 배너를 비밀 조직인 Agency의 손 모양 로고로 변경했습니다. - 일부 이용자에게 무작위로 보이는 `redacted` 역할을 부여했습니다. - 실제로는 새 시즌과 관련된 정답에 근접한 추측을 한 이용자를 운영자가 수동으로 선정했습니다. - 선정된 이용자에게는 별도 경고 없이 역할을 부여해 비밀 임무에 선택된 듯한 느낌을 만들었습니다. - 커스텀 Agency 봇이 `#season-theories` 채널에서 해당 이용자가 “활성화되었다”고 공개적으로 알렸습니다. - 해당 역할을 가진 이용자는 회원 목록에서 별도로 표시되어 다른 이용자에게 호기심과 FOMO를 유발했습니다. ## 실용적인 적용 방향 - 서버를 채널 모음이 아니라 게임의 플레이 경험과 연결된 공간으로 설계합니다. - 공지, 팀원 모집, 토론, 버그 신고, 지원 기능을 이용자의 실제 행동 흐름에 맞춰 분리합니다. - 대규모 커뮤니티에서는 명확한 분류와 신고 템플릿을 우선적으로 마련합니다. - 출시나 시즌 업데이트 때는 역할, 봇, 배너, 이벤트를 활용해 세계관 기반의 참여형 캠페인을 구성할 수 있습니다. - 다른 서버의 구조를 그대로 복사하기보다, 자신의 게임과 커뮤니티에 맞게 변형하는 것이 중요합니다.

discord

디스코드 패치 노트 (새 탭에서 열림)

Discord는 2024년 12월 5일 성능, 안정성, 사용성 개선과 버그 수정을 포함한 패치 노트를 공개했다. 모바일 프로필 개편, iOS 미디어 선택기 성능 향상, Unicode 15.1 이모지 및 애니메이션 WebP 지원이 주요 변경 사항이다. 또한 앱 개발자를 위한 Webhook Events가 추가됐으며, 이번 업데이트 이후 패치 노트는 겨울 휴가로 잠시 중단되고 2025년 2월 초 재개될 예정이다. ### 모바일 프로필과 미디어 성능 개선 - 모바일 사용자 프로필과 프로필 편집 화면을 데스크톱과 유사한 디자인으로 개편했다. - 최신 디자인 시스템을 적용해 레이아웃과 시각적 일관성을 개선했다. - iOS 미디어 선택기의 이미지 로딩 시간을 대부분의 상황에서 90% 이상 단축했다. - Discord 내부 카메라로 촬영한 뒤 미디어 선택기를 열 때 발생하던 빈 화면도 많은 경우 제거했다. ### 이모지와 이미지 형식 지원 확대 - Unicode 15.1 이모지를 지원해 새로운 이모지를 사용할 수 있게 됐다. - Unicode 15.1 지원은 이전 버전과 완전히 호환되지 않으므로, 다른 사용자에게 이모지가 빈 상자나 대체 문자로 보이면 클라이언트 업데이트가 필요하다. - 데스크톱과 웹 앱에서 임베드 및 즐겨찾기에 애니메이션 WebP를 지원한다. - 애니메이션 이모지를 GIF 대신 WebP 형식으로 요청하도록 변경해 파일 크기와 앱 성능을 개선했다. - Bluesky URL에 대한 임베드도 정상적으로 지원한다. ### 앱 개발자를 위한 Webhook Events - 앱이 Gateway 연결을 직접 유지하지 않고도 이벤트를 받을 수 있는 Webhook Events를 출시했다. - 실시간 지연 시간이 중요하지 않은 앱은 복잡한 Gateway 연결 관리 없이 이벤트를 수집할 수 있다. - 관련 기능은 Discord 개발자 문서에서 확인할 수 있다. ### 프로필·서버·설정 관련 버그 수정 - 프로필 배너가 지정한 영역대로 제대로 잘리지 않던 문제를 수정했다. - 모바일 프로필 화면에서 Shop과 설정 알림 점의 위치가 일관되지 않던 문제를 해결했다. - 프로필 길이가 길 때 `Send Message`, `Add Friend` 버튼이 제대로 표시되지 않던 문제를 수정했다. - 프로필에서 사용자를 차단할 때 실수 방지를 위한 확인 절차를 추가했다. - 역할을 한 번에 30명 초과 사용자에게 추가하려 할 때 조용히 실패하던 동작을 수정하고, 작업을 최대 30명으로 제한했다. - 역할 추가·삭제 후 역할 이름이 잘못 표시되던 UI 문제를 해결했다. - 데스크톱 서버 목록 하단이 잘못된 어두운 상자로 렌더링되던 문제를 수정했다. - Nitro 선물 화면의 라이트 테마 버튼, Android 버튼 아이콘과 배경, 모바일 Nitro 설명 문구 등의 표시 문제를 개선했다. - 단축 URL이 올바르게 미리보기되지 않던 문제와 프로필의 게임 스트리밍 제목이 비어 보이던 문제를 수정했다. ### 채팅과 메시지 입력 개선 - DM 알림 사이를 이동할 때 메시지 초안이 다른 DM으로 옮겨가던 문제를 수정했다. - 멘션이 사용자 이름 대신 사용자 ID로 표시되던 문제를 해결했다. - iOS에서 멘션이 아닌 `@` 뒤의 텍스트가 무시되던 문제를 수정했다. - 전체 화면 Text in Voice에서 텍스트 자동 완성으로 이모지를 추가할 수 있도록 개선했다. - 입력창과 타이핑 표시기가 겹치거나 하단 여백이 사라지는 문제를 해결했다. - 새 DM 화면에서 첨부 파일을 열 때 UI가 비정상적으로 늘어나던 문제를 수정했다. - 스레드 생성 중 이모지 선택기를 열면 화면이 응답하지 않던 iOS 문제를 해결했다. - iOS에서 스레드를 열 때 메시지 작성자가 아닌 스레드 생성자의 프로필이 열리던 문제를 수정했다. - 메시지 전달 입력창의 테마, 읽지 않은 멘션 표시기의 배경색, 온보딩 바 정렬 문제도 수정했다. ### Activities와 앱 권한 화면 - 일부 서버의 Activities에서 사용자 이름이 잘못 표시되던 문제를 해결했다. - 앱 승인 화면에서 스크롤바가 없는 위젯인데도 스크롤해 수락하라는 안내가 표시되던 문제를 수정했다. ### 음성·영상 통화 개선 - 음성 제어 버튼의 원형 배경이 사라지던 문제를 수정했다. - 데스크톱에서 Push to Talk와 Voice Activity를 전환한 뒤 Voice Activity가 다시 활성화되지 않던 문제를 해결했다. - Android에서 다른 앱을 화면 공유할 때 마이크가 작동하지 않던 문제를 수정했다. - 통화 화면의 Activity 버튼 크기와 겹침 문제를 개선했다. - iOS 앱 특정 버전에서 화면 공유가 실패하던 문제를 수정했으며, 해당 문제의 사용자는 최신 버전으로 업데이트해야 한다. - iOS 스피커 모드 통화 중 근접 센서가 화면을 꺼버리던 동작을 방지했다. - 모바일 통화 종료 후 평가 모달이 조작되지 않던 문제를 해결했다. - 통화 상태 표시 아이콘의 모서리 둥글기도 일부 조정했다. 이번 패치는 새 기능 추가와 함께 모바일·iOS·Android별 UI 및 통화 문제를 폭넓게 다룬 업데이트다. 특히 미디어 선택기 성능 개선, WebP 지원, Unicode 업데이트가 체감 효과가 큰 변경이므로 모든 플랫폼에서 최신 Discord 클라이언트로 업데이트하는 것이 좋다.

figma

마이크로소프트, 피 (새 탭에서 열림)

Microsoft Dynamics 365 for Talent 디자인팀은 Figma API와 웹훅을 활용해 디자인-개발 핸드오프를 자동화했다. 디자이너가 파일의 새 버전을 저장하면 자동으로 Pull Request가 생성되고, 디자인·개발팀의 검토와 승인 후 변경 사항이 제품에 반영된다. 그 결과 기존 업무 흐름을 약 70% 줄이고, 디자이너와 엔지니어가 각자의 핵심 업무에 더 집중할 수 있게 됐다. ## 대규모 조직에서 발생한 디자인 핸드오프 문제 - Microsoft는 사내 해커톤인 **OneWeek**를 매년 개최하며, 직원들이 기존 업무에서 벗어나 업무 개선 아이디어를 실험하도록 지원한다. - Dynamics 365 for Talent 팀은 Fluent Design System을 확장하면서 새로운 기능보다 시각적 디자인 요소를 확장하고 정교화하는 데 집중했다. - 디자이너와 엔지니어 비율을 약 **1:10**으로 유지하려 했지만, 디자인 변경 사항을 개발에 전달하는 과정이 병목이 됐다. - 디자이너는 작은 변경 사항을 반영하기 위해 요청을 설명하고 우선순위를 확보해야 했고, 엔지니어는 대규모 기업 업무 속에서 각 요청의 처리 순서를 조정해야 했다. - 이 때문에 단일 디자인 요소를 실제 제품에 배포하는 데 **최대 일주일 이상**이 걸리기도 했다. ## Figma API를 활용한 OneWeek 프로젝트 - 팀은 Figma를 적극적으로 사용하고 있었기 때문에, Figma의 웹 기반 API가 핸드오프 문제를 해결할 수 있다고 판단했다. - OneWeek 기간 동안 디자인 파일의 변경을 개발 워크플로와 연결하는 자동화 시스템을 구축했다. - 핵심은 Figma 파일의 변경을 감지하는 **Figma 웹훅(webhook)** 이었다. - 디자이너가 파일의 새 버전을 저장하면 웹훅이 이를 감지하고 후속 개발 프로세스를 자동으로 시작한다. ## 변경 사항을 Pull Request로 자동 전환 - 새 디자인 버전이 저장되면 자동으로 디자인·개발팀의 검토를 위한 **Pull Request**가 생성된다. - 양 팀은 Pull Request를 통해 변경 내용을 확인하고 승인할 수 있다. - 승인된 변경 사항은 엔지니어가 커밋하고 제품에 반영한다. - 기존처럼 디자이너가 개별 요청을 전달하고 엔지니어가 수동으로 우선순위를 정하는 대신, 디자인 변경이 코드 협업 흐름에 직접 연결된다. - 디자인 파일의 버전 관리와 코드 리뷰 프로세스를 결합해 책임과 승인 절차도 명확해졌다. ## 자동화가 가져온 효과 - 팀에 따르면 새로운 프로세스는 전체 업무 흐름을 **약 70% 단축**할 수 있었다. - 디자이너는 반복적인 설명과 요청 조율보다 디자인 작업에 더 많은 시간을 쓸 수 있게 됐다. - 엔지니어는 단순한 핸드오프 처리에서 벗어나 개발과 기술적 문제 해결에 집중할 수 있었다. - 디자인 변경 사항의 배포 속도가 빨라져, 조직 규모가 큰 환경에서도 디자인 시스템을 효율적으로 확장할 수 있는 기반이 마련됐다. 디자인과 개발 사이의 반복적인 전달 업무가 병목이라면, 디자인 도구의 API·웹훅을 코드 저장소 및 Pull Request 흐름과 연동하는 방식을 고려할 만하다. 특히 자동화만 도입하기보다 버전 저장, 검토, 승인, 커밋까지의 책임과 절차를 함께 정의해야 효과를 안정적으로 유지할 수 있다.

figma

Figma 플랫폼을 소개합니다 (새 탭에서 열림)

Figma는 디자인 파일을 다른 도구·스크립트·웹 앱과 연결하는 **Figma Platform**을 공개하며, 전문 디자인 도구 최초의 웹 API를 지향했다. API를 통해 디자인 데이터를 실시간으로 읽고, 댓글을 주고받고, 이미지로 렌더링할 수 있어 조직 맞춤형 협업 자동화가 가능해진다. 이를 기반으로 디자인을 고립된 파일이 아니라 조직 전체가 공유·검색·활용하는 개방형 데이터로 전환하는 것이 글의 핵심 결론이다. ## Figma Platform의 목표 - Figma를 외부 도구, 사내 스크립트, 웹 애플리케이션과 연결하는 플랫폼을 제공한다. - 기존 데스크톱 디자인 도구는 운영체제, 로컬 파일 경로, 특정 소프트웨어 버전에 종속되어 통합이 어려웠다. - Figma는 웹 기반이므로 서로 다른 컴퓨터나 웹 서비스에서도 디자인의 최신 상태에 접근할 수 있다. - 기업은 조직별 업무 방식에 맞춘 검색, 공유, 모니터링, 자동화 도구를 직접 만들 수 있다. ## 초기 Web API의 세 가지 기능 - **디자인 파일 읽기** - 디자인을 개방형 JSON 형식으로 제공한다. - 도형, 텍스트, 컴포넌트, 프로토타입 링크, 전환 효과, 제약 조건 등 디자인을 구성하는 트리 구조를 확인할 수 있다. - 파일 URL에 포함된 고유 키를 사용해 특정 디자인의 실시간 스냅샷을 가져온다. - **댓글 읽기·쓰기** - 외부 서비스가 Figma 디자인의 댓글을 조회하거나 작성할 수 있다. - 디자인 검토와 협업 프로세스를 다른 업무 도구와 연결할 수 있다. - **이미지 렌더링** - 전체 파일 또는 파일의 일부를 JPG, PNG, SVG 등 표준 이미지 형식으로 변환한다. - 별도의 수동 내보내기 없이 외부 서비스에서 최신 디자인 이미지를 활용할 수 있다. ## 개방형 웹 API가 제공하는 장점 - 특정 운영체제나 설치된 디자인 프로그램에 의존하지 않는다. - 별도의 독점 플러그인 언어나 프레임워크 대신 일반적인 웹 개발 기술을 사용할 수 있다. - 잘 정의된 API를 사용하므로 사내 자동화와 외부 서비스 통합을 빠르게 구현할 수 있다. - 통합 기능을 유지·보수하고 최신 상태로 업데이트하기가 상대적으로 쉽다. - 디자인 데이터를 이미지뿐 아니라 구조화된 정보로 활용할 수 있어 새로운 형태의 협업 도구를 만들 수 있다. ## 실제 활용 사례: Uber와 GitHub - **Uber** - 여러 도시에 분산된 디자인 팀의 작업을 조직 전체에 보여주기 위해 API를 활용했다. - 진행 중인 디자인을 사무실 TV에 실시간으로 표시하는 피드를 만들고 있다. - Dribbble과 유사한 내부 디자인 저장소에서 프로젝트를 탐색하는 기능도 계획했다. - **GitHub** - 아이콘 제작 과정 일부를 자동화해 반복 작업을 줄이고 효율성을 높였다. - 이러한 사례는 API가 단순한 파일 내보내기를 넘어 조직 내부의 가시성, 검색, 자동화 문제를 해결할 수 있음을 보여준다. ## 오픈소스 프로젝트와 외부 통합 - Figma는 커뮤니티가 활용할 수 있도록 여러 데모 프로젝트를 오픈소스로 공개했다. - 예시: - Figma 디자인 맞춤법 검사기 - 생성형 아트 도구 - 디자인을 Ethereum 블록체인에 기록하는 방법 - Avocode, Haiku, Zeplin, Pagedraw 등 다른 디자인·개발 도구와의 통합도 강화했다. - 플랫폼의 가치는 Figma가 모든 기능을 직접 제공하는 데보다 커뮤니티와 기업이 각자의 문제를 해결하는 데 있다. ## 향후 공개 예정 기능 - **Webhooks** - 파일이나 팀에 연결해 디자인 변경 이벤트를 콜백 형태로 전달한다. - 디자인 업데이트를 감지해 외부 시스템을 자동으로 갱신할 수 있다. - **Write API** - 초기 버전은 주로 디자인 데이터를 읽는 데 초점을 맞췄다. - 이후 외부 애플리케이션이 Figma 디자인 자체를 수정할 수 있는 쓰기 API를 제공할 계획이다. - **Extensions** - 인앱 확장 기능은 강력하지만 품질, 안정성, 예측 가능성을 떨어뜨릴 수 있다. - Figma는 개발자 자유와 제품 안정성을 함께 확보할 수 있는 모델을 마련한 뒤 확장 기능을 도입하려 했다. - 당시에는 구체적인 출시 일정이 정해지지 않았다. ## 대규모 협업에서 해결하려는 문제 - 디자인은 UI 디자이너만 사용하는 산출물이 아니라 카피라이터, 엔지니어, 연구자, 마케터, 경영진 등 여러 부서가 함께 다루는 정보가 되었다. - 전통적인 데스크톱 도구에서는: - 파일을 내보내고 업로드해야 공유할 수 있다. - 원본이 변경되면 공유된 파일이 즉시 오래된 버전이 된다. - 경영진이 실시간 작업을 보고 의견을 남기기 어렵다. - 엔지니어가 필요한 최신 에셋을 찾는 데 많은 시간을 쓴다. - 다른 팀이 이미 해결한 문제와 해결책을 발견하기 어렵다. - Figma API는 조직 전체에서 디자인을 실시간으로 공유하고, 검색하고, 모니터링하는 맞춤형 워크플로를 구축하는 기반이 된다. Figma Platform은 디자인 도구를 폐쇄적인 제작 환경에서 개방형 협업 플랫폼으로 확장하려는 시도다. 실제 도입 시에는 API로 최신 디자인 조회·렌더링·댓글 연동부터 시작하고, Webhooks와 자동화 기능을 결합해 사내 디자인 검색 및 배포 시스템으로 발전시키는 접근이 실용적이다.