spotify·2026년 3월 12일원문

에이전틱 개발 이야기: Spotify x Anthropic Live | Spotify Engineering (새 탭에서 열림)

Spotify와 Anthropic은 소프트웨어 개발의 패러다임이 AI 에이전트 중심으로 급격히 이동하고 있으며, 이는 단순한 도구의 변화를 넘어 조직의 인프라와 개발 문화 전반의 혁신을 요구한다고 강조합니다. 특히 Spotify의 배경 코딩 에이전트 'Honk'의 사례를 통해 수천 개의 저장소에 걸친 복잡한 마이그레이션을 자동화하는 등 실질적인 대규모 에이전트 운용 전략을 제시했습니다. 결론적으로 미래의 개발 환경은 인간 중심의 IDE에서 에이전트 중심의 터미널 기반 상호작용으로 변화하며, 개발자의 역할은 코드 작성자에서 에이전트 결과물에 책임을 지는 관리자로 진화할 것입니다. **에이전트 중심 개발로의 전환과 기술적 변곡점** * Anthropic의 Opus 4.5 모델 출시를 기점으로 Spotify 내부 엔지니어들의 작업 방식에 뚜렷한 변화가 관찰되었습니다. * 개발자들이 IDE(통합 개발 환경) 앞에 머무는 대신, 터미널에서 에이전트와 직접 소통하며 명령을 내리는 시간이 비약적으로 증가했습니다. * 이는 AI를 단순한 보조 도구가 아닌, 개발 워크플로우의 핵심 주체로 인식하기 시작했음을 시사합니다. **Spotify의 코딩 에이전트 'Honk'와 Slack 기반 워크플로우** * Spotify는 'Honk'라는 이름의 배경 코딩 에이전트를 구축하여 Slack 메시지만으로 작업을 지시할 수 있는 환경을 마련했습니다. * Honk는 결정론적인 단순 코드 마이그레이션을 넘어, 수천 개의 리포지토리에 걸친 복잡하고 대규모인 소프트웨어 변경 작업을 수행합니다. * 개발자들이 Slack에서 문제를 논의하다가 Honk를 멘션(@Honk)하여 즉시 해결책을 실행하도록 하는 에이전트 친화적 협업 모델이 정착되었습니다. **대규모 AI 확장을 위한 컨텍스트 엔지니어링** * 엔터프라이즈 규모에서 Claude와 같은 모델을 효과적으로 활용하기 위해선 복잡한 시스템보다 표준화되고 재현 가능한 설정이 중요합니다. * Claude MD 설정이나 도메인 특화 스킬 정의 등 단순하면서도 명확한 '컨텍스트 엔지니어링'이 에이전트의 성능을 좌우합니다. * Spotify의 개발자 포털인 Backstage는 MCP(Model Context Protocol)를 통해 수동 워크플로우를 대체하며 에이전트 우선 플랫폼으로 진화하고 있습니다. **에이전트 시대의 거버넌스와 책임** * 에이전트가 인간의 리뷰 속도보다 빠르게 코드를 생성하고 배포함에 따라 새로운 병목 현상과 거버넌스 문제가 발생하고 있습니다. * 중요한 것은 코드의 생성 주체(인간 vs 에이전트)가 아니라 '결과물' 중심의 사고방식이며, 최종 결과에 대해 책임을 지는 주체는 여전히 인간이어야 합니다. * 에이전트가 생성한 출력물에 대한 투명한 검토 체계와 책임 소재를 명확히 하는 것이 대규모 도입의 핵심입니다. **소프트웨어 생명주기 전체로의 확장** * 2025년까지의 변화가 코드 생성에 집중되었다면, 향후 에이전트의 역할은 유지보수, 코드 삭제 등 개발자가 기피하는 '번거로운 작업' 전반으로 확장될 것입니다. * Anthropic은 내부적으로 'Ant-fooding'이라 불리는 테스트 문화를 통해 Claude Code와 Cowork 같은 제품을 지속적으로 고도화하며 개발 수명 주기 전반을 자동화하고 있습니다. 성공적인 에이전트 도입을 위해서는 기술적 복잡성에 매몰되기보다, 조직 내 리포지토리 전반에 걸쳐 일관된 컨텍스트를 제공할 수 있는 표준화된 인프라를 먼저 구축해야 합니다. 또한, 에이전트가 생성한 방대한 코드의 품질을 관리할 수 있도록 인간의 역할을 '작성'에서 '검증 및 책임'으로 재정의하는 조직적인 준비가 필요합니다.

slackclaudecontext-engineeringai-infrastructure+4

naver·2025년 11월 25일원문

네이버 TV (새 탭에서 열림)

네이버 엔지니어링 데이에서 발표된 이 내용은 로컬 LLM인 Ollama와 오픈소스 mcp-agent를 활용하여 프로젝트 자동화의 수준을 한 단계 높인 실무 사례를 다룹니다. 빌드 실패 분석부터 크래시 로그 요약, Slack 알림까지의 과정을 AI가 스스로 판단하고 수행하는 '협력자'로서의 모델을 제시하며, 이를 통해 개발자가 반복적인 모니터링 업무에서 벗어나 고차원적인 문제 해결에 집중할 수 있음을 보여줍니다. **로컬 기반 LLM 및 에이전트 활용 아키텍처** - Ollama를 활용하여 로컬 환경에 LLM을 구축함으로써 사내 보안 문제를 해결하고 데이터 유출 걱정 없이 분석 환경을 조성합니다. - 오픈소스인 mcp-agent(Model Context Protocol)를 도입하여 AI 모델이 단순한 텍스트 생성을 넘어 외부 도구 및 데이터와 실시간으로 상호작용하도록 설계합니다. - 단순 스크립트 기반 자동화와 달리, AI 에이전트가 상황을 인지하고 적절한 도구를 선택해 작업을 수행하는 유연한 워크플로우를 구현합니다. **지능형 빌드 실패 분석 및 크래시 모니터링** - 빌드 과정에서 발생하는 방대한 양의 에러 로그를 AI가 즉시 분석하여 실패의 근본 원인을 파악하고 요약합니다. - 앱 실행 중 발생하는 크래시 로그를 실시간으로 모니터링하고, 코드 변경 이력 등을 대조하여 해당 문제를 해결하기에 가장 적합한 담당자(Assignee)를 자동으로 매칭합니다. - 비정형 데이터인 로그 메시지를 의미론적으로 해석함으로써 기존 키워드 매칭 방식의 한계를 극복합니다. **Slack 연동을 통한 자동화된 리포팅 체계** - AI가 분석한 빌드 결과와 크래시 요약 내용을 Slack API를 통해 개발 팀 채널에 실시간으로 공유합니다. - 리포트에는 단순히 에러 메시지만 전달하는 것이 아니라, AI가 제안하는 해결 방안과 우선순위 등을 포함하여 팀의 의사결정 속도를 높입니다. - Slack 내에서 LLM과 대화하며 추가적인 로그 분석이나 세부 사항을 질의할 수 있는 대화형 자동화 환경을 제공합니다. **AI 자동화 도입 시 고려사항 및 한계** - LLM과 MCP의 조합이 강력하지만 모든 문제를 해결하는 만능 도구는 아니며, 결과값의 할루시네이션(환각 현상)에 대한 검증 프로세스가 병행되어야 합니다. - 자동화가 복잡해질수록 AI가 도구를 잘못 선택하거나 잘못된 분석을 내놓을 가능성이 있으므로, 단계적인 도입과 신뢰도 테스트가 필수적입니다. **실용적인 제언** 로컬 LLM을 활용한 자동화는 보안이 중요한 사내 프로젝트에서 비정형 데이터 분석 업무를 획기적으로 줄여줍니다. 특히 MCP와 같은 최신 프로토콜을 적극적으로 활용하여 LLM이 실제 개발 도구들과 긴밀하게 연결될 수 있도록 설계하는 것이 성공적인 AI 자동화 도입의 핵심입니다.

slackAI대규모 언어 모델자동화+4

figma·2025년 7월 31일·3분 읽기큐레이션 요약

듀오링고 메소드:

Duolingo Math 팀은 디자인과 엔지니어링을 분리해 순차적으로 넘기는 전통적인 핸드오프 대신, 처음부터 함께 아이디어를 만들고 프로토타입을 반복 검증하는 방식을 택한다. 디자이너·엔지니어·PM이 실시간으로 협업하며 실제 작동하는 경험을 바탕으로 결정하기 때문에, 새로운 제품에서도 빠르게 방향을 찾고 완성도를 높일 수 있다. 핵심은 완벽한 설계를 먼저 확정하는 것이 아니라, 만들고 보여주고 수정하는 과정을 팀 전체의 공동 작업으로 만드는 데 있다. ## 선형적인 핸드오프의 한계 - 디자인에서 엔지니어링으로 작업을 한 번에 넘기는 방식은 제품 개발이 실제로 진행되는 방식과 맞지 않는다. - 특히 Duolingo Math처럼 새로운 학습 모듈과 게임을 처음부터 만들어야 하는 팀은 기존 템플릿이나 검증된 청사진을 활용하기 어렵다. - 상호작용과 애니메이션이 많은 기능은 문서나 정적인 화면만으로 구현 난이도와 사용자 경험을 정확히 판단하기 어렵다. - 따라서 디자인과 엔지니어링이 초기 단계부터 지속적으로 연결되어야 한다. ## 초기 단계부터 함께 아이디어 구상 - 디자이너가 혼자 작업을 시작하지 않고, 디자이너·엔지니어·제품 관리자가 공유된 FigJam 파일에서 함께 아이디어를 낸다. - 방향이 정해지면 디자이너가 Figma에서 화면과 동작, 모션을 구체화한다. - 엔지니어도 이 단계에 적극 참여해 복잡한 상호작용과 애니메이션을 미리 검토한다. - 구현하기 어려운 부분은 Figma 댓글 등으로 조기에 지적해 불필요한 설계 수정을 줄인다. - Jira를 Figma와 직접 연결해 도구 간 맥락 전환을 줄이고, 디자인과 개발 작업의 흐름을 유지한다. ## 빠른 프로토타이핑과 반복 실험 - 디자인 시안에 합의한 뒤 엔지니어가 Duolingo 디자인 시스템의 컴포넌트를 활용해 초기 프로토타입을 빠르게 만든다. - 디자이너와 엔지니어가 작동하는 프로토타입을 만든 후 팀 회의에서 직접 테스트하고 피드백을 받는다. - Slack 채널에서 디자이너는 Figma 파일을, 엔지니어는 구현된 프로토타입을 공유하며 질문과 의견을 주고받는다. - 각 기능마다 다음 순환을 반복한다. - 프로토타입 제작 - 팀 테스트 - 피드백 수집 - 수정 및 재검증 - Duolingo의 “말로 설명하기보다 직접 보여준다(show don’t tell)”는 원칙에 따라, 아이디어의 타당성을 논의만 하지 않고 실제 경험으로 확인한다. - 프로토타입은 설계를 미리 완성하기 위한 결과물이 아니라, 제품이 실제로 어떻게 느껴지는지 확인하고 핵심 결정을 내리기 위한 도구다. ## 함께 다듬고 출시하기 - 지속적인 협업을 통해 개발 중에도 빠르게 의사결정을 내리고 기능을 다듬을 수 있다. - 속도가 중요할 때는 애니메이션을 단순화하는 등 기능을 핵심 경험 위주로 축소한다. - 교육용 게임의 시장 적합성을 확인할 때도 처음부터 완성도 높은 게임 두 개를 만드는 대신, 단순한 디자인과 최소한의 메커니즘을 가진 게임부터 빠르게 제작했다. - 어떤 기능을 우선할지 미리 정한 뒤, 일곱 가지 프로토타입을 반복적으로 제작하며 사용자에게 어떤 경험이 반응을 얻는지 확인했다. - 이 방식은 대규모 기능을 장기간 개발한 뒤 실패하는 위험을 낮추고, 초기 학습을 제품 방향에 빠르게 반영하게 한다. ## 실무에 적용할 때의 시사점 - 디자인 완료 후 개발을 시작하기보다, 초기 기획부터 디자이너와 엔지니어를 함께 참여시킨다. - 정적 시안보다 작동하는 작은 프로토타입을 우선 제작한다. - 기능별로 짧은 제작·테스트·수정 주기를 운영한다. - 속도와 학습이 중요한 초기 단계에서는 부가 기능보다 핵심 사용자 경험에 집중한다. - 협업 도구를 연결하고 공유 채널을 마련해 작업 맥락과 피드백을 실시간으로 유지한다.

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

slackFigma디자인 시스템figjam+3

datadog·2024년 9월 23일원문

장애 회고 작성을 지원하기 위해 비용, 품질, 안전성 측면에서 LLM 활용을 최적화한 방법 (새 탭에서 열림)

장애 해결 후 포스트모템(장애 회고록)을 작성하는 과정은 조직의 학습과 복구 능력 향상을 위해 필수적이지만, 엔지니어들에게는 상당한 시간과 노력이 드는 번거로운 작업입니다. 이를 해결하기 위해 Datadog은 Bits AI에 LLM을 도입하여 정형화된 장애 메타데이터와 슬랙의 비정형 대화 데이터를 결합해 포스트모템 초안을 자동 생성하는 기능을 구현했습니다. 이 프로젝트는 단순한 자동화를 넘어, 환각 현상을 억제하고 엔지니어가 직접 내용을 검토하며 학습하는 '인간 중심의 통제권'을 유지하는 데 초점을 맞추었습니다. ### LLM 기반 포스트모템 도입 시 직면한 과제 * **데이터 정확성 및 환각(Hallucinations):** LLM은 문법적으로는 완벽해 보이지만 사실이 아닌 내용을 그럴듯하게 생성하는 경향이 있습니다. 팩트가 생명인 장애 보고서에서 이러한 비결정론적 특성을 제어하는 것이 가장 큰 과제였습니다. * **비용, 속도, 품질의 트레이드오프:** GPT-4와 같은 고성능 모델은 정확도가 높지만 GPT-3.5에 비해 비용이 최대 50배 비싸고 생성 속도가 느려, 사용자 경험과 운영 비용 사이의 균형점이 필요했습니다. * **학습 과정의 훼손 방지:** AI가 완성된 결과물을 그대로 제공하면 엔지니어가 장애 원인을 깊이 파고드는 학습 기회를 놓칠 수 있습니다. 따라서 AI는 '작성 보조 도구'로서 초안을 제공하고 최종 판단은 인간이 하도록 설계해야 했습니다. * **보안 및 개인정보 보호:** 장애 데이터에는 민감한 정보나 비밀번호 등이 포함될 수 있으므로, LLM에 데이터를 전달하기 전 이를 사전에 필터링하는 보안 레이어가 필수적이었습니다. ### 정확도 향상을 위한 기술적 해결책 * **커스텀 API 및 데이터 정제 프레임워크:** 슬랙 대화와 장애 관리 앱에서 데이터를 추출한 뒤, 민감 정보를 제거하고 구조화하여 LLM이 처리하기 쉬운 형태로 변환하는 전용 API를 개발했습니다. * **정형·비정형 데이터의 결합:** 수동으로 입력된 장애 메타데이터(정형)뿐만 아니라, 장애 당시의 급박한 상황이 담긴 슬랙 대화 내용(비정형)을 함께 분석하여 문맥적으로 더 정확한 초안을 생성하도록 했습니다. * **프롬프트 엔지니어링 및 파라미터 튜닝:** 100시간 이상을 투입해 프롬프트 구조를 반복 수정했으며, 모델의 온도(Temperature) 설정을 낮추어 출력의 일관성을 높이고 무작위성을 줄였습니다. * **점진적 검증 프로세스:** 포스트모템 작성을 돕기 전, 먼저 짧은 '장애 요약 기능'을 구현하여 모델의 성능을 테스트하고 여기서 얻은 인사이트를 긴 문서 작성 기능에 피드백하는 방식을 취했습니다. ### 모델 출력 평가 및 피드백 루프 * **정성적/정량적 평가 병행:** 기존에 사람이 작성한 포스트모템과 AI가 생성한 초안을 정확성, 간결성, 유용성 등의 항목으로 비교하는 설문 조사를 실시하여 품질을 지속적으로 개선했습니다. * **사용자 피드백 반영:** 초안 생성 과정에서 엔지니어가 수정하는 내용을 추적하여, 어떤 부분이 부족하고 어떤 정보가 더 보강되어야 하는지 데이터 기반으로 파악하고 있습니다. LLM을 이용한 포스트모템 작성 지원은 엔지니어의 업무 부담을 줄여주는 동시에, 장애로부터 배우는 조직 문화를 더욱 공고히 하는 강력한 도구가 될 수 있습니다. 다만, AI의 결과물을 맹신하기보다는 엔지니어가 비판적으로 검토할 수 있는 '초안' 단계로 활용하는 것이 시스템의 신뢰성과 교육적 가치를 유지하는 핵심입니다.

slack대규모 언어 모델datadog데이터 사이언스+4

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

컴포넌트 스프린트의

워싱턴 포스트는 디자인과 개발이 분리된 채 진행되던 컴포넌트 제작의 문제를 해결하기 위해 약 10일간의 ‘컴포넌트 스프린트’를 도입했다. 디자이너와 개발자가 처음부터 한 쌍으로 참여하고, 관련 팀의 의견을 단계별로 반영해 기술적 제약과 실제 사용 맥락을 함께 고려한다. 이 방식은 디자인 시스템 컴포넌트를 더 빠르고 일관되게 제작하면서도, 팀 전체의 공동 소유 의식을 높이는 것이 핵심이다. ## 디자인 주도·개발 주도 방식의 한계 - 초기 WPDS(The Washington Post Design System)는 컴포넌트 성격에 따라 제작 주체가 달랐다. - `select`, `radio`, `checkbox`처럼 시각적 설계가 중심인 요소는 디자인 주도로 제작했다. - `carousel`, `input search`처럼 기술적 복잡성이 큰 요소는 개발 주도로 제작했다. - 한쪽 팀이 주도하면 다른 팀의 전문 지식이 늦게 반영되어 일정 지연과 타협이 발생했다. - 개발자는 디자인 단계에서 기술적 한계를 뒤늦게 지적하거나, 구현보다 세부적인 시각 요소에 집중하도록 압박받을 수 있었다. - 디자이너는 자신의 사용 사례가 충분히 고려되지 않거나, 이미 존재하는 컴포넌트를 알지 못해 별도 솔루션을 만들기도 했다. - 그 결과 디자인 시스템에는 잦은 오버라이드와 즉석에서 판단해야 하는 기능·변형 요청이 누적됐다. ## 컴포넌트 스프린트의 운영 원칙 - 모든 컴포넌트마다 스프린트를 시작하며, 일반적으로 약 10일 동안 진행한다. - 디자이너와 개발자가 처음부터 끝까지 프로세스를 이끄는 담당자로 짝을 이룬다. - 핵심 담당자 외에도 관련 팀의 의견을 수집해 폐쇄적인 순차 작업을 개방적이고 협력적인 과정으로 바꾼다. - 프로세스는 대체로 다음 단계로 구성된다. - 킥오프 - 콘셉트 정의 - 디자인과 구현 - 개선 및 다듬기 - 문서화 - 모든 참여자가 초기에 요구사항과 기술적 제약을 공유하므로, 후반부의 재작업과 오해를 줄일 수 있다. ## 킥오프: 영향도와 노력으로 우선순위 정하기 - 매주 30분 회의에서 Jira의 후보 컴포넌트 티켓을 검토한다. - 각 아이디어를 예상 영향도와 필요한 노력의 관점에서 비교해 우선순위를 정한다. - 아이디어 보드는 단순한 목록이 아니라 다음 정보를 축적하는 협업 공간으로 활용한다. - 이해관계자의 비동기 피드백 - Slack에서 논의된 관련 정보 - 비슷한 아이디어의 묶음 - 사업 목표와의 연관성 - 시각화된 영향도-노력 매트릭스에서는 원의 크기로 투표 수나 인기도를 표현하고, 색상으로 연관된 사업 목표를 구분한다. - 우선순위가 결정되면 디자인 시스템 팀에서 디자이너와 개발자를 각각 배정한다. - 두 담당자를 초기 단계부터 정함으로써 프로세스 전반의 지속적인 커뮤니케이션을 보장한다. ## 콘셉트 정의: 범위와 목표 합의하기 - 스프린트 시작 시 전체 팀과 함께 약 2시간의 회의를 진행한다. - FigJam에서 다음 내용을 공동으로 정리한다. - 컴포넌트의 목표 - 필수 요구사항 - 작업 범위 - 기술적 요구사항 - 검토가 필요한 가정과 쟁점 - 회의 마지막 15분은 결과 검토에 사용한다. - 기술 담당자와 비기술 담당자가 같은 공간에서 의견을 남기므로, 서로 다른 관점의 기대치를 조기에 맞출 수 있다. - 이 단계에서는 구체적인 디자인 세부사항보다 문제의 범위, 사용 목적, 구현 조건을 먼저 합의한다. - FigJam을 활용하면 특정 직군이 논의를 독점하지 않고, 참여자 모두가 요구사항을 명확히 할 수 있다. ## 실용적인 적용 방향 컴포넌트 제작을 한 팀에 일괄 위임하기보다, 디자이너와 개발자를 초기부터 공동 책임자로 배치하는 것이 효과적이다. 또한 영향도·노력 기반 우선순위 보드와 공개적인 요구사항 문서를 운영하면 불필요한 컴포넌트 중복과 후반 재작업을 줄일 수 있다.

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

slackFigma디자인 시스템figjam+3

figma·2023년 12월 6일·4분 읽기큐레이션 요약

슬랙래시부터 토글

2023년의 디지털·하이브리드 업무 환경은 새로운 행동과 감정을 만들어냈고, 이를 표현할 새로운 업무 용어도 낳았다. 이 글은 Slack, Zoom, 협업 도구, 멀티태스킹과 관련된 현상을 유머러스한 신조어로 정리하며, 변화한 업무 문화를 이해하고 적응하는 언어를 제시한다. 결국 바쁜 업무 환경을 완전히 없애기보다, 그 안의 불합리함과 재미를 인식하고 더 현명하게 일하자는 메시지다. ### 업무 완성도와 반복 개선 - **Fidelity Fluency** - 프로젝트에 필요한 완성도 수준을 판단하는 능력이다. - 초기 아이디어 스케치에 과도한 시간을 쓰지 않고, 실제 영향력에 맞춰 디테일을 조절한다. - 불필요한 픽셀 단위 수정과 낭비를 줄이는 실무적 감각을 의미한다. - **WIP Waltz** - 진행 중인 작업을 끊임없이 수정하고 반복하는 과정을 춤에 비유한 표현이다. - 매 단계마다 새로운 관점과 개선 사항이 생기지만, 동시에 또 다른 수정 라운드가 시작된다. ### 원격 협업에서 발생하는 순간들 - **Icebroken** - 온라인 회의의 아이스브레이킹에서 지나치게 개인적인 이야기를 꺼내 어색해지는 상황이다. - 친밀감을 만들려던 시도가 오히려 ‘TMI’로 이어지는 순간을 풍자한다. - **Screenshare Scramble** - 화면 공유 직전이나 도중에 민감하거나 부끄러운 브라우저 탭을 급히 숨기는 행동이다. - Zoom 화면에 무엇이 나타날지 모르는 긴장감과 허둥거림을 표현한다. - **Zoombie** - Zoom 회의에 접속해 있지만 실제로는 거의 참여하지 않는 사람을 뜻한다. - 카메라 앞에는 존재하지만 정신적으로는 여러 회의와 화면 공유에 지친 상태다. - **Zoom Zen** - 명확한 안건, 원활한 음소거·해제, 시간 내 종료가 모두 이루어진 이상적인 화상회의 상태다. - 드물지만 회의가 효율적이고 만족스럽게 끝났을 때의 평온함을 의미한다. ### 메시지와 알림의 과부하 - **Keyboard Cardio** - 이메일과 Slack 메시지를 빠르게 입력하고 처리하는 일을 격렬한 유산소 운동처럼 표현한 말이다. - 실제 운동 효과보다는 메시지 작성이 유발하는 긴장과 스트레스를 농담처럼 강조한다. - **Slack-lash** - Slack 알림과 메시지가 한꺼번에 쏟아져 놀라고 압도되는 순간이다. - 디지털 메시지의 폭발적인 유입을 갑작스러운 반동이나 ‘채찍질’에 비유한다. - **Workplace Whack-a-Mole** - 업무, 알림, 이메일이 끊임없이 나타나 이를 계속 처리해야 하는 상황이다. - 하나를 끝내면 곧바로 다른 일이 튀어나오는 업무 환경의 피로와 혼란을 묘사한다. ### 멀티태스킹과 디지털 산만함 - **Toggle Tax** - 여러 업무 사이를 전환할 때 발생하는 인지적 비용이다. - 작업을 바꿀 때마다 집중력을 다시 끌어올려야 하므로, 멀티태스킹이 생산성을 떨어뜨릴 수 있음을 암시한다. - **Tab Tsunami** - 브라우저 탭이 지나치게 많이 열려 화면과 집중력을 모두 압도하는 상태다. - 수많은 정보와 작업을 동시에 붙잡으려는 디지털 업무 습관을 거대한 파도에 비유한다. ### 디자인 시스템과 협업 문화 - **Style Guide Safari** - 스타일 가이드 안에서 색상, 서체, 컴포넌트 등을 탐색하는 과정을 정글 탐험처럼 표현한 말이다. - 디자인 시스템이 풍부하고 복잡할수록 원하는 규칙을 찾아다니는 경험이 모험처럼 느껴질 수 있다. - **Sudden Heavy Stamping** - 협업 중 자신의 아이디어에 갑자기 여러 개의 +1, 하트, 스탬프가 몰리는 순간이다. - 실시간 협업 도구에서 사회적 인정과 즉각적인 피드백을 받는 기쁨을 뜻한다. - **UI Lock Ness Monster** - 다음 업데이트에 포함될 것이라는 소문만 무성하고 실제로는 계속 등장하지 않는 UI 기능이다. - 오랫동안 기대되지만 실현되지 않는 기능을 전설 속 괴물에 빗댄 표현이다. ### 글이 제시하는 업무 문화의 풍경 - 이 용어들은 새로운 기술 자체보다, 기술을 사용하는 과정에서 생긴 감정과 습관을 포착한다. - Zoom 피로, Slack 알림, 화면 공유 불안, 멀티태스킹 비용처럼 디지털 업무의 문제를 유머로 표현한다. - 동시에 비동기 업무, 팬데믹 이후의 업무 전환, 몰입 중심의 업무 방식 등 변화한 일하는 방식을 반영한다. - 이러한 표현은 업무의 혼란을 개인의 실패로만 보지 않고, 많은 사람이 공유하는 문화적 경험으로 바라보게 한다. 업무 효율을 높이려면 `Toggle Tax`를 줄이도록 작업 전환을 최소화하고, `Zoom Zen`을 위해 회의 안건과 종료 시간을 명확히 정하는 것이 좋다. 또한 `Fidelity Fluency`처럼 업무 목적에 맞는 완성도만 추구하면 불필요한 수정과 디지털 과부하를 줄일 수 있다.

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

slackFigma디자인 시스템사용자 인터페이스+3

figma·2023년 12월 6일·3분 읽기큐레이션 요약

커리어 전환의 기술 | Figma

커리어 피벗은 반드시 직업을 완전히 바꾸는 극적인 전환일 필요가 없으며, 관점·역할·환경을 조정하는 작은 변화도 큰 결과를 만들 수 있다. 이 글은 제품 개발 분야의 창작자 6명이 경험한 피벗을 재구성(reframe), 복귀(boomerang), 자기 탐색(unfolding), 확장(stretch), 급격한 전환(hard left), 경험의 결합(blend)으로 나누어 설명한다. 공통적으로 피드백을 받아들이고, 낮은 위험의 실험을 거치며, 기존 경험을 새로운 방식으로 활용하는 것이 성공적인 전환의 핵심이다. ## 커리어 피벗을 바라보는 관점 - 피벗은 삶과 커리어에서 반복적으로 일어나는 방향 전환이다. - 기술 업계에서는 ‘빠르게 움직이고 과감히 바꾸는 것’이 강조되지만, 실제 커리어 변화는 점진적 조정부터 완전한 전환까지 다양한 형태를 가진다. - 피벗의 목적은 단순히 직함을 바꾸는 것이 아니라 다음을 찾는 데 있다. - 기존 기술을 더 효과적으로 활용하기 - 관심사와 직업의 접점 넓히기 - 새로운 환경에서 영향력 키우기 - 자신에게 맞는 일의 방식 발견하기 ## 관점을 바꾸는 재구성(Reframe) 재구성은 직업이나 분야를 완전히 바꾸지 않고, 문제를 바라보고 전달하는 방식을 바꾸는 피벗이다. - UX 라이터 Ry Reid는 핀테크 기업 고객지원에서 UX 라이팅으로 전환한 뒤, Pinterest와 Spotify에서 글쓰기 역량을 쌓았다. - Uber Eats에서는 문서와 글로 아이디어를 설득하려 했지만, 아이디어가 제대로 받아들여지지 않았다. - 승진에서 탈락한 뒤 디자인 매니저에게 “아이디어를 설명하지 말고 시각화해보라”는 조언을 받았다. - Ry는 펜과 종이로 대략적인 화면을 만들고, 이후 Google Slides로 시안을 제작해 Slack에 공유했다. - 디자이너와 프로덕트 매니저가 즉시 반응했고, 제안한 UX가 실제 방향으로 채택되었다. - 핵심은 라이터가 디자이너가 된 것이 아니라, 글 중심의 커뮤니케이션에 저충실도 시각화를 추가해 영향력을 확장한 것이다. - 최종적인 픽셀 단위 완성도는 전문 디자이너의 역할이지만, 좋은 아이디어를 시각적으로 제안하는 일은 누구나 시도할 수 있다. ### 재구성이 필요한 신호 - 현재 일을 좋아하지만 같은 문제에 계속 부딪히는 경우 - 승진이나 성장의 정체가 오래 지속되는 경우 - 불편하지만 동시에 기대감을 주는 조언을 받은 경우 ### 재구성을 실행하는 방법 - 승진 탈락이나 비판적인 피드백을 방어적으로만 받아들이지 않는다. - 자신의 직무와 인접한 분야의 멘토에게 조언을 구한다. - 처음부터 큰 변화를 시도하지 말고, 펜·슬라이드·간단한 프로토타입처럼 실패 비용이 낮은 방식으로 실험한다. - 익숙하지 않은 방법을 시도할 때 느끼는 불편함 자체를 변화의 신호로 받아들인다. ## 익숙한 회사에서 새로운 역할을 맡는 복귀(Boomerang) 복귀는 이미 알고 있는 회사로 돌아가거나, 익숙한 조직 안에서 완전히 다른 역할을 맡는 방식이다. - 회사와 조직문화에 대한 이해를 유지하면서 직무는 크게 바꿀 수 있다. - 새로운 분야를 처음부터 시작해야 하는 위험을 줄이고, 기존 네트워크와 신뢰를 활용할 수 있다. - 글에 소개된 Erica Simunovic은 로스앤젤레스의 애드테크 기업 Tatari에서 처음에는 피플 오퍼레이션을 이끌었다. - 이후 제품 디자인 부트캠프를 수료하고 약 5년 뒤 같은 회사로 돌아와 디자이너로 일하게 되었다. - 이 사례는 회사는 그대로 유지하되 전문 분야를 HR에서 디자인으로 전환하는 피벗을 보여준다. ## 글에서 제시하는 다른 피벗 유형 - **자기 탐색(Unfolding)**: 외부 직함보다 자신의 관심과 정체성을 깊이 탐색하며 새로운 방향을 발견하는 방식 - **확장(Stretch)**: 기존 역량을 바탕으로 새로운 기회와 책임에 도전하는 방식 - **급격한 전환(Hard left)**: 기존 경력과 전혀 다른 분야로 크게 방향을 바꾸는 방식 - **경험의 결합(Blend)**: 여러 직무 경험, 기술, 관계망을 조합해 새로운 역할이나 사업을 만드는 방식 작은 시각화 실험처럼 낮은 위험의 변화를 먼저 시도하고, 인접 분야의 사람에게 피드백을 구하는 것이 실용적인 출발점이다. 현재의 직무를 버리기 전에 기존 경험을 새로운 방식으로 재구성할 수 있는지 살펴보면, 더 안전하면서도 영향력 있는 커리어 전환을 설계할 수 있다.

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

slackFigma사용자 경험프로덕트 디자인+2

figma·2023년 10월 24일·3분 읽기큐레이션 요약

Figma의 데이터 사이언스 및

Figma의 데이터 과학팀과 사용자 조사팀은 알림 문제를 정량 데이터와 정성적 사용자 의견으로 함께 분석했다. 그 결과 알림 클릭률보다 앞선 단계인 “알림을 아예 받지 못하는 문제”가 가장 큰 개선 기회임을 발견했다. Figma는 이를 해결하기 위해 새로운 알림 유형을 추가하고, 누가 언제 알림을 받아야 하는지 재검토하는 실험을 시작했다. ## 정량 데이터와 정성 조사의 결합 - 데이터 과학은 대규모 사용자 행동을 통해 **무슨 일이 일어나는지(What)** 보여준다. - 사용자 조사는 사용자가 왜 그렇게 행동하는지 **이유(Why)** 를 파악하는 데 도움을 준다. - 수치만으로는 사용자의 동기와 맥락을 알기 어렵고, 인터뷰만으로는 전체 사용자에게 나타나는 패턴을 확인하기 어렵다. - 두 방법을 함께 사용하면 각 분석의 한계를 보완해 더 완전한 제품 이해가 가능하다. - 두 팀은 이를 날실과 씨실을 엮어 천을 만드는 과정에 비유했다. ## Figma 알림 퍼널과 문제 정의 - Figma 알림은 이메일, Slack, 모바일, 파일 브라우저·시스템 트레이·데스크톱 알림 등 여러 경로로 전달된다. - 알림 유형에는 댓글, 댓글 답글, 댓글 반응, 파일·팀·프로젝트 초대, 편집 초대, 멘션 등이 있다. - 사용자가 알림과 상호작용하려면 다음 단계를 통과해야 한다. - 알림 대상이 될 수 있음 - 알림을 받음 - 알림을 확인함 - 알림과 상호작용함 - 활동 팀은 어느 단계에서 사용자가 가장 많이 이탈하는지, 어떤 단계에 투자해야 하는지 알지 못했다. - 분석 결과 가장 큰 문제는 많은 사용자가 알림을 열지 않는 것이 아니라 **알림 자체를 받지 못하고 있다는 점**이었다. ## 협업형 분석 프로세스 구축 - Caitlin Hudon과 Jennifer Sanders는 FigJam에서 팀 전체 브레인스토밍을 진행했다. - 팀은 알림을 받은 사용자, 열어본 사용자, 클릭한 사용자의 비율과 현재 상태를 공유했다. - 이후 다음과 같은 질문을 함께 정리했다. - 분기별로 어떤 지표를 개선할 것인가? - 새로운 알림 유형이 필요한가? - 현재 데이터만으로 알 수 없는 것은 무엇인가? - 질문을 데이터 과학으로 답할지, 사용자 조사로 답할지 각자의 전문 영역에 따라 나누었다. - 두 연구자는 각자 프로젝트를 진행하면서도 지속적으로 소통하고, 공통된 질문과 발견을 맞춰 갔다. - 이런 지속적인 동기화와 결과 종합에 충분히 투자하는 것이 단순히 두 연구 결과를 나열하는 것보다 중요했다. ## 행동 데이터가 보여준 것과 사용자 조사가 밝혀야 한 것 - 데이터 분석은 알림 퍼널의 각 단계에서 사용자가 얼마나 줄어드는지 파악하는 데 적합했다. - 특히 알림 수신 여부와 실제 상호작용 사이의 차이를 수치로 확인할 수 있었다. - 사용자 조사는 사용자가 알림을 받지 못하거나 활용하지 않는 상황의 맥락과 기대를 이해하는 데 사용됐다. - 사용자는 자신의 행동 이유를 항상 정확히 설명하지 못할 수 있으므로, 인터뷰 결과를 행동 데이터와 함께 검증해야 했다. - 정량 결과와 정성적 설명을 결합해 팀은 단순한 클릭률 개선이 아닌 알림 전달 구조 자체를 개선해야 한다고 판단했다. ## 발견을 제품 개선으로 연결 - 활동 팀은 알림을 통해 팀원 간 연결과 협업을 강화하는 것을 목표로 했다. - 가장 큰 개선 영역은 기존 알림의 클릭을 유도하는 것보다 다음 문제를 해결하는 데 있었다. - 적절한 사용자가 알림을 받지 못하는 문제 - 필요한 상황을 포괄하지 못하는 알림 유형 - 알림을 받을 시점과 대상이 적절하지 않은 문제 - 이후 팀은 여러 알림 실험을 시작했다. - 사용자의 주요 불편을 해결하기 위한 새로운 알림 유형도 출시됐다. ## 실용적인 결론 제품 문제를 분석할 때 퍼널의 마지막 행동만 보지 말고, 사용자가 그 단계에 도달하기 전 어디에서 이탈하는지 확인해야 한다. 대규모 행동 데이터로 문제의 범위를 파악한 뒤, 사용자 조사로 원인과 맥락을 보완하고, 두 결과를 공동으로 종합하는 방식이 효과적이다.

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

slackfigjamuser-research데이터 사이언스+2

datadog·2023년 6월 1일원문

2023-03-08 사건: 우리의 사건 대응에 대한 심층 분석 | Datadog (새 탭에서 열림)

Datadog은 2023년 3월 발생한 사상 첫 글로벌 서비스 장애를 겪으며 자사의 장애 대응(Incident Response) 프로세스와 문화를 실전에서 검증했습니다. 수백 명의 엔지니어가 투입된 이번 사태를 통해 Datadog은 "직접 만든 사람이 직접 운영한다(You build it, you own it)"는 원칙과 비난 없는 사후 분석(Blameless Postmortem)의 중요성을 다시 한번 확인했습니다. 이 글은 전례 없는 대규모 장애 상황에서 유연한 의사결정과 체계적인 협업 시스템이 어떻게 복구를 견인했는지에 대한 기술적 기록을 담고 있습니다. **Datadog의 장애 모니터링 및 대응 체계** * **소유권 기반 모델:** 모든 엔지니어링 팀은 자신이 구축한 서비스의 운영을 직접 책임지며, 24시간 모니터링 경보에 몇 분 내로 응답해야 하는 "You build it, you own it" 모델을 따릅니다. * **대역 외(Out-of-band) 모니터링:** 플랫폼 자체가 중단될 경우를 대비해 인프라 외부에서 API를 호출하여 사용자 관점에서 상태를 체크하는 별도의 독립적인 모니터링 시스템을 운영합니다. * **Slack 기반 협업:** 장애 발생 시 전용 앱이 Slack 채널을 자동으로 생성하며, 관련 없는 엔지니어도 자유롭게 참여하여 도움을 줄 수 있는 개방적인 환경을 조성합니다. **고심도 장애(High-Severity) 관리 및 역할 분담** * **장애 지휘관(Incident Commander):** 대규모 장애 시 숙련된 시니어 엔지니어가 투입되어 전체 대응을 진두지휘하며, 복구 전략과 커뮤니케이션을 총괄합니다. * **전담 커뮤니케이션 팀:** 고객 지원 매니저와 경영진이 포함된 별도 팀이 구성되어 외부 고객 및 비즈니스 이해관계자에게 정확한 상태 정보를 전달합니다. * **지속적인 훈련:** 장애 선언 문턱을 낮게 설정하여 일상적으로 장애 대응 프로세스를 연습하며, 모든 엔지니어는 6개월마다 필수 리프레시 교육을 이수해야 합니다. **자율성과 비난 없는 조직 문화** * **절차보다 사람 우선:** 고정된 복구 매뉴얼은 복잡한 시스템의 변화 속도를 따라갈 수 없으므로, 엔지니어가 현장에서 상황에 맞는 최선의 판단을 내릴 수 있도록 자율권을 부여합니다. * **비난 없는 문화(Blameless Culture):** 장애의 원인을 개인의 실수가 아닌 시스템의 결함으로 간주하여, 엔지니어가 압박감 속에서도 창의적인 해결책을 찾을 수 있도록 지원합니다. * **강화된 사후 분석:** 모든 고심도 장애 이후에는 자동화된 알림을 통해 상세한 포스트모템 작성을 독려하며, 이를 통해 유사 장애의 재발을 방지합니다. **3월 8일 글로벌 장애 타임라인 및 초기 진단** * **장애 트리거(06:00 UTC):** systemd 업데이트가 시작되면서 예상치 못한 인프라 연쇄 반응이 발생했습니다. * **신속한 감지(06:03~06:18 UTC):** 장애 발생 3분 만에 모니터링 시스템이 문제를 감지했고, 15분 이내에 고심도 장애로 격상되었습니다. * **원인 파악(07:20~11:36 UTC):** 쿠버네티스(Kubernetes) 노드 실패가 글로벌 장애의 핵심 원인임을 식별했으며, 최종적으로 '무인 업데이트(Unattended upgrades)'가 트리거였음을 밝혀냈습니다. * **인프라 복구(12:05~19:00 UTC):** EU1 및 US1 리전의 컴퓨팅 용량을 순차적으로 복구하고 재발 방지를 위한 완화 조치를 적용하여 전체 인프라를 정상화했습니다. 대규모 시스템을 운영하는 조직이라면 고정된 대응 매뉴얼에 의존하기보다 엔지니어의 자율성을 존중하고, 장애를 학습의 기회로 삼는 비난 없는 문화를 구축하는 것이 중요합니다. 특히 플랫폼 전체가 마비되는 최악의 상황을 대비해 인프라 외부에서 독립적으로 작동하는 '대역 외 모니터링' 체계를 반드시 갖출 것을 추천합니다.

slack쿠버네티스datadog자동화+4

figma·2023년 3월 14일·3분 읽기큐레이션 요약

팀을 최대한 활용하는 방법 |

팀의 잠재력을 끌어내려면 관리자가 목표, 회의, 역할, 성장 기회를 설계해 구성원이 주도적으로 일할 수 있는 환경을 만들어야 한다. 핵심은 목표를 소수의 우선순위로 좁히고, 회의를 꼭 필요한 경우에만 운영하며, 직책보다 좋은 아이디어와 실험을 중시하는 것이다. 팀의 성공은 구성원이 몰입하고 성장할 수 있는 업무 환경을 만드는 관리자의 성공과도 연결된다. ## 목표는 세 가지 우선순위로 좁힌다 - 구성원에게 분기나 반기 초에 자신이 이루고 싶은 목표를 먼저 작성하게 한다. - 처음에는 10~15개의 목표가 나올 수 있지만, 최종적으로는 **세 가지 핵심 우선순위**만 남긴다. - 목표를 줄이는 과정에서 실제 기간 안에 달성할 수 있고, 높은 완성도로 수행할 수 있는 일에 집중하게 한다. - 목표는 회사의 가장 중요한 전략적 과제와 연결해야 한다. - “무엇을 할 것인가”뿐 아니라 목표가 만들어낼 **영향을 구체적·정량적으로 표현**하도록 돕는다. - 확정된 목표를 다른 리더들과 공유해 조직 전체의 정렬과 책임감을 높인다. ## 회의는 반드시 필요한 순간에만 연다 - Work & Co.는 하루에 한 번 아침 체크인만 진행한다. - 전날 완료한 일 - 당일의 다음 단계 - 필요한 협업 사항 - 나머지 시간은 방해 없이 개인 작업이나 공유 파일 기반 협업에 사용한다. - 회의가 많아질수록 집중해서 결과물을 만들 시간이 줄어들기 때문에, Slack이나 FigJam으로 해결할 수 있는 사안은 회의로 만들지 않는다. - 회의를 줄이기 어렵다면 회의 목적과 진행 방식을 더 명확하게 설계해야 한다. ## 발언이 적은 사람도 참여할 수 있는 회의 구조를 만든다 - Twitch는 Amazon식 6쪽 문서 회의 형식을 하이브리드 업무에 맞게 적용했다. - 참석자는 회의 전에 공유 문서를 읽고, 10~15분 동안 질문과 의견을 문서에 주석으로 남긴다. - 이후 회의에서는 문서에 달린 의견을 중심으로 논의한다. - 즉흥적으로 말하는 데 익숙한 사람만 유리한 ‘자유 발언식 회의’의 문제를 줄인다. - 문서, FigJam 스탠드업 등 구성원이 편한 방식으로 생각을 표현하게 하면 참여의 형평성과 회의의 효율이 높아진다. ## 직책보다 좋은 아이디어를 가치 있게 만든다 - 역할이 모호하면 업무 충돌과 영역 다툼이 생길 수 있다. - 반대로 직무를 지나치게 상세하게 규정하면 새로운 업무나 혁신적인 아이디어가 등장할 여지가 줄어든다. - Oura Ring은 모든 캠페인과 프로젝트를 실험으로 간주한다. - 좋은 아이디어는 강한 가설에서 시작하고, 결과를 측정한 뒤 다음을 결정한다. - 확대할지 - 반복 적용할지 - 중단할지 - 새로운 아이디어를 내는 일을 특정 직무의 책임으로 제한하지 않고 모두의 책임으로 본다. - 구성원이 새로운 일을 시도하거나 기존 역할의 경계를 잠시 넘는 것을 허용하면 아직 존재하지 않는 중요한 역할과 기회도 발견할 수 있다. - 영향력을 만들려는 시도를 조직이 과도하게 막지 않는 것이 중요하다. ## 경력 대화를 시각화하고 함께 설계한다 - 경력은 직선적인 승진 경로가 아니라 다양한 방향으로 움직일 수 있다. - 관리자는 구성원이 가능한 경로와 미래의 선택지를 상상하도록 도와야 한다. - 특히 원격 근무 환경에서는 우연한 만남이나 비공식 네트워킹이 줄어들기 때문에 의도적인 경력 대화가 더 중요하다. - 글에서는 이를 “경력 대화를 스토리보드로 구성하기”라는 방식으로 제시하지만, 제공된 내용에는 구체적인 실행 방법까지 이어지지 않는다. 구성원에게 많은 일을 맡기는 것보다 중요한 것은 무엇을 하지 않을지 결정하도록 돕는 일이다. 목표를 소수로 제한하고, 회의를 정교하게 운영하며, 누구나 아이디어를 실험할 수 있게 만들면 팀의 자율성·집중력·성장 가능성을 함께 높일 수 있다.

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

slackFigmafigjamproduct-management+2

figma·2022년 3월 29일·2분 읽기큐레이션 요약

Figma의 새로운 소식:

2022년 3월 Figma 업데이트의 핵심 주제는 다양한 환경에서 더 자유롭고 포괄적으로 협업할 수 있도록 접근성과 유연성을 높이는 것이었다. FigJam의 iPad 지원, 아랍어·히브리어·우르두어 등 오른쪽에서 왼쪽으로 쓰는 언어 지원, 모든 글꼴에서의 위·아래 첨자 처리, Slack 알림 연동이 추가됐다. 이를 통해 장소와 기기, 언어, 협업 방식의 제약을 줄였다. ## FigJam iPad 앱으로 아이디어 발상 확장 - FigJam을 iPad에서 사용할 수 있게 됐다. - 브라우저 알림이나 여러 탭의 방해 없이 아이디어를 스케치하고 정리할 수 있다. - 장소에 관계없이 다음 작업을 수행할 수 있다. - 아이디어 스케치 - 브레인스토밍과 구상 - 보드에 주석 추가 - iPad에서 작업한 내용을 데스크톱에서 이어서 편집할 수 있어 기기 간 작업 흐름이 자연스럽게 연결된다. - Figma 앱스토어에서 이용 가능하다. ## 오른쪽에서 왼쪽으로 쓰는 언어 지원 - Figma와 FigJam이 RTL(right-to-left) 텍스트를 지원한다. - 지원 대상에는 다음과 같은 언어가 포함된다. - 아랍어 - 히브리어 - 우르두어 - 글로벌 사용자가 자신의 문자 방향에 맞춰 디자인하고 협업할 수 있게 됐다. - 국제적인 제품과 콘텐츠를 설계할 때 언어 방향 때문에 발생하던 제약을 줄였다. ## 모든 글꼴에서 위·아래 첨자 사용 - 기존에는 선택한 글꼴이 위 첨자나 아래 첨자 글리프를 제공하지 않으면 해당 문자를 사용하기 어려웠다. - 이제 Figma가 글꼴에 해당 글리프가 없을 때 합성 글리프(synthetic 또는 faux glyph)를 자동으로 생성한다. - 합성 글리프는 현재 글꼴의 스타일에 맞춰 다음과 같이 조정된다. - 글자 크기 축소 - 기준선 위 또는 아래로 위치 이동 - 주변 글자와 어울리도록 배치 - 따라서 별도의 특수 글꼴을 찾지 않아도 수식, 각주, 단위 표기 등에 위·아래 첨자를 사용할 수 있다. ## Slack을 통한 Figma 협업 알림 - 새로운 Slack 앱 연동을 통해 Figma 파일, 팀, 프로젝트의 변경 사항을 Slack에서 확인할 수 있다. - 알림 수신 방식은 다음과 같이 선택할 수 있다. - 실시간 알림 - 시간별 요약 - 일일 요약 - 활용 예시는 다음과 같다. - 프로젝트별 Slack 채널에 여러 Figma 파일을 연결 - 누군가 파일에 댓글을 남겼을 때 프로젝트 구성원에게 알림 - 협업자가 많은 파일을 위한 전용 알림 채널 운영 - 별도로 Figma를 열지 않아도 팀의 진행 상황을 공유할 수 있어 하이브리드 근무 환경에 적합하다. ## 실용적인 활용 iPad 사용자는 이동 중에도 FigJam에서 아이디어를 기록하고 데스크톱에서 구체화할 수 있다. 다국어 제품을 만드는 팀은 RTL 지원을 활용해 실제 사용자 환경에 가까운 화면을 설계하고, Slack 연동을 설정하면 댓글과 협업 진행 상황을 팀 채널에서 지속적으로 공유할 수 있다.

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

slackFigmafigjamtypography+3

figma·2022년 2월 7일·3분 읽기큐레이션 요약

FigJam과 함께한 시간: 베타

FigJam은 원격 근무 확산으로 커진 협업·소통 수요에 대응해 탄생했으며, Figma는 완벽한 제품을 한 번에 만들기보다 베타 출시 후 사용자 피드백을 바탕으로 발전시키는 방식을 택했다. 제품의 방향과 우선순위는 내부 여러 팀과 실제 사용자들의 지속적인 의견을 통해 결정됐다. 그 결과 FigJam은 장기 비전을 유지하면서도 빠르게 개선되는 협업 제품으로 정식 출시 단계(GA)에 도달했다. ## 원격 근무가 만든 온라인 화이트보드의 필요성 - Figma는 원격 근무를 시작하며 사람들이 온라인 공간에서 더 많은 시간을 보내는 상황을 경험했다. - 사용자들은 Figma를 디자인 작업뿐 아니라 사람들과 연결되고 소통하는 공간으로도 활용했다. - 브레인스토밍, 팀 아이스브레이커, 사교 활동 등 비업무적 협업 수요도 커졌다. - Figma 내부에서도 함께 모일 수 있는 디지털 공간이 필요했기 때문에 FigJam 개발에 전사적인 추진력이 붙었다. ## 협업을 촉진하는 제품 관리 방식 - Figma에서는 좋은 아이디어와 결정이 특정 직책의 사람에게서만 나온다고 보지 않는다. - 제품 관리자의 역할을 최종 결정자라기보다, 여러 직군이 더 나은 결정을 내리도록 돕는 촉진자로 정의한다. - PM, 디자이너, 엔지니어뿐 아니라 지원, 영업, 마케팅 팀도 제품 아이디어와 우선순위 결정에 참여한다. - “혼자서는 위대한 제품을 만들 수 없다”는 원칙에 따라 제품 개발 자체를 협업 과정으로 운영했다. ## 베타 출시로 완벽주의를 극복하다 - FigJam은 Figma의 두 번째 제품이었기 때문에 기존 제품과 같은 수준의 완성도와 유지보수성을 확보해야 한다는 부담이 있었다. - 모든 것을 완벽하게 결정하려다 출시가 늦어질 위험이 있었다. - 이를 해결하기 위해 베타로 먼저 출시하고, 실제 사용자 반응을 바탕으로 제품을 반복 개선했다. - 베타는 단순한 시험판이 아니라 장기적인 제품 비전을 유지하면서도 변화하는 요구에 빠르게 대응하는 방법으로 활용됐다. ## 결정적인 문제부터 해결한 우선순위 설정 - 모든 세부 사항을 오래 논의하기보다, 다음 단계의 결정을 막는 핵심 문제를 먼저 해결했다. - 초기에는 Figma와 FigJam의 관계, 두 제품을 통합할지 별도 애플리케이션으로 만들지 등이 중요한 쟁점이었다. - 결정이 필요한 사안은 우선 판단한 뒤 이해관계자와 사용자에게 피드백을 받아 조정했다. - 알파 테스트에서 수집한 요청은 다음과 같이 분류했다. - 최초 출시 전에 반드시 해결해야 할 문제 - 초기 출시 이후 빠르게 추가할 기능 - 예를 들어 스티키 노트 작성자 표시 기능은 출시 필수 항목으로 분류했고, 타이머 기능은 후속 개선 항목으로 미뤘다. ## 알파 테스터와 지속적인 사용자 피드백 - 개발팀은 수백 명의 알파 테스터가 참여한 공동 Slack 공간을 운영했다. - 테스터들은 사용 중 발견한 문제와 개선 아이디어를 지속적으로 공유했다. - 출시 후에도 신규 기능을 먼저 사용하는 사용자 패널을 두고 적극적으로 의견을 수집했다. - 사용자 피드백은 Slack, 고객 지원 채널, Twitter 등 다양한 경로에서 얻었다. - 제품 결정의 기준은 기능 자체가 아니라 실제 FigJam 사용자가 필요로 하는 문제를 해결하는지 여부였다. ## FigJam 개발에서 얻은 방식 - 회사 차원의 명확한 목표가 있으면 새로운 제품도 짧은 기간 안에 여러 팀의 역량을 결집해 개발할 수 있다. - 초기부터 모든 답을 확정하기보다, 중요한 구조적 문제를 먼저 결정하고 나머지는 사용자의 반응을 보며 조정하는 것이 효과적이다. - 베타 출시는 불완전함을 감수하는 전략이 아니라, 실제 사용 환경에서 제품을 학습시키는 개발 과정이 될 수 있다. - 다양한 직군과 사용자로부터 아이디어를 얻고, 이를 출시 필수 기능과 후속 기능으로 구분하면 속도와 품질을 함께 관리할 수 있다. 실무적으로는 제품의 장기 방향은 분명히 유지하되, 초기에는 핵심 가설을 검증할 수 있는 수준으로 출시하고 실제 사용자 피드백을 우선순위 결정에 직접 반영하는 접근이 유용하다.

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

slackFigma사용자 경험figjam+3

figma·2021년 10월 27일·3분 읽기큐레이션 요약

빌드 비하인드:

Figma는 FigJam의 플러그인·위젯 생태계를 외부 개발자에게 개방하며 새로운 협업과 창작 가능성을 넓히고 있다. 개발자 Tru Narla는 위젯 제작 경험을 바탕으로 사운드보드 위젯을 만들었고, 작은 아이디어를 실제로 출시하는 과정에서 커뮤니티와 스트리밍의 도움을 얻었다. 그녀는 앞으로 인터랙티브 피아노와 멀티플레이어 게임 등으로 FigJam의 상호작용성을 확장하고자 한다. ## Soundboard 위젯의 목적 - Tru Narla는 Square의 소프트웨어 엔지니어로 일하며, 개인 프로젝트와 프로토타이핑에도 Figma를 자주 사용한다. - 그녀가 만든 **Soundboard**는 FigJam 보드에 재미있는 소리를 추가하는 위젯이다. - 향후 사용자가 직접 오디오를 녹음하거나 미리 준비된 소리를 선택하는 기능을 추가하고 싶어 한다. - 기존에 오디오 중심의 FigJam 위젯이 거의 없다는 점에서 아이디어를 얻었다. ## 문서와 커뮤니티를 통한 개발 - 공식 문서를 읽고 데모 프로젝트를 따라 하면서 개발을 시작했다. - 초기에는 시행착오를 반복하며 기능을 구현했다. - 위젯 API의 제약으로 오디오 녹음 기능을 넣을 수 없어 프로젝트 범위를 축소했다. - 비공개 Slack 채널에서 다른 위젯 개발자들과 코드를 공유하고 버그를 함께 해결한 것이 큰 도움이 됐다. - 위젯 개발은 예상보다 쉽고 재미있었으며, 제한적인 부분이 있어도 현재 제공되는 기능만으로 다양한 프로젝트를 만들 수 있다고 평가했다. ## 아이디어를 실행하고 출시한 계기 - Tru는 이전에도 사이드 프로젝트를 자주 시작했지만 완성하거나 출시하지 못한 경우가 많았다. - 비공개 위젯 개발자 커뮤니티에서 다른 사람들의 작업을 보며 동기를 얻었다. - 자신이 직접 사용할 만한 것을 만들고 싶다는 생각으로 사운드 관련 프로젝트를 시작했다. - 개발 과정을 Twitch에서 스트리밍한 것이 프로젝트를 끝까지 완성하는 데 도움이 됐다. - 아이디어가 떠오르면 바로 메모하고, Twitter와 일상생활에서 영감을 얻는다고 설명했다. ## FigJam에서 확장되는 상호작용 - 다음 프로젝트로 사용자가 건반을 클릭해 소리를 내거나, 키보드 단축키로 특정 음을 연주할 수 있는 **인터랙티브 피아노**를 개발 중이다. - 장기적으로는 구현 난도가 높은 멀티플레이어 게임도 만들고 싶어 한다. - FigJam의 플러그인과 위젯이 협업 보드에 재미와 상호작용을 더하는 방식에 주목한다. - 개발·시스템 설계를 위한 코드 임베드 기능에도 관심이 있으며, 코드 설명이나 튜토리얼을 FigJam에 작성하는 활용을 기대한다. - 실행 가능한 코드를 샌드박스에서 직접 보여주는 기능도 있으면 유용할 것이라고 제안한다. ## 개방형 플랫폼의 가능성 - FigJam이 외부 개발자에게 API를 공개하면서 개인 개발자도 새로운 도구를 제작하고 배포할 수 있게 됐다. - 다른 개발자들의 플러그인과 위젯이 다시 새로운 아이디어를 자극하는 선순환이 형성되고 있다. - Tru는 Figma와 FigJam에 아직 개발되지 않은 가능성이 많다는 점을 가장 기대되는 부분으로 꼽는다. - Figma Community를 통해 다양한 위젯과 플러그인을 공유하고 탐색할 수 있다. 작은 기능의 프로토타입이라도 직접 사용해 보고 싶은 문제에서 출발해 빠르게 만들고 공개하는 것이 좋은 출발점이다. 공식 문서뿐 아니라 개발자 커뮤니티와 공개 과정을 활용하면 기술적 제약을 줄이고 프로젝트를 완성할 가능성을 높일 수 있다.

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

slackFigmafigjamAPI+4

figma·2021년 6월 15일·3분 읽기큐레이션 요약

효과적인 브레인스토

효과적인 브레인스토밍은 회의 중 아이디어를 많이 내는 데서 끝나지 않고, 사전 준비와 참여 환경 조성, 아이디어 발산, 실행 가능한 결과 정리까지 이어지는 과정이다. 참가자들이 판단받지 않고 자유롭게 제안하면서도 최종적으로는 공동의 목표에 맞는 구체적 다음 단계로 수렴하도록 설계해야 한다. ## 1. 사전 준비와 계획 - 참가자에게 초대 이유와 기대되는 기여를 미리 알린다. - 캘린더 초대나 Slack 메시지에 회의 목적과 배경을 간단히 적는다. - 사전 읽을거리, 브리프, 관련 Figma 파일을 공유해 참석 전에 맥락을 맞춘다. - 주요 협력자나 이해관계자와 미리 아이디어를 검토한다. - 사전에 우려 사항을 파악할 수 있다. - 관련자들이 과정에 참여하고 있다고 느끼게 한다. - 브레인스토밍은 회의 자체뿐 아니라 회의 전후의 활동까지 포함한다. ## 2. 소개와 기대치 조율 - 아이스브레이커로 참가자들이 창의적인 상태에 들어가도록 돕는다. - 동물 그리기나 협업자 카드 작성처럼 짧고 부담 없는 활동을 활용할 수 있다. - 회의의 참여 규칙을 참가자들과 함께 정한다. - Slack 사용이 허용되는지 - 회의 중 완전한 집중이 필요한지 - 발언과 피드백은 어떤 방식으로 할지 등을 합의한다. - 진행자는 열린 분위기와 포용적인 환경을 만들어야 한다. - 브레인스토밍의 목표와 한계를 명확히 설명한다. - 좋은 아이디어가 많이 나와도 모든 아이디어를 실제로 사용하지는 않는다는 점을 미리 알린다. ## 3. 아이디어 생성 - 매번 새로 구성하기보다 브레인스토밍 템플릿을 ‘레시피’처럼 활용하고, 목적과 참가자에 맞게 수정한다. - 빈 캔버스에서 시작하는 부담을 줄인다. - “어떻게 하면 ~할 수 있을까?” 같은 질문으로 시작한다. - 간단한 연습 문제를 먼저 제시한다. - 예를 들어 원, 사각형, 삼각형을 그리게 해 누구나 참여할 수 있다는 자신감을 준다. - 팀이 공유할 기준점, 즉 ‘북극성’을 설정한다. - “X를 해결하고 Y를 얻는다”처럼 문제와 기대 결과를 한 문장으로 정리한다. - 최종 목표를 시각화하면 아이디어가 공동 목표와 연결된다. - 과감하고 엉뚱한 아이디어도 환영한다. - 가장 대담한 아이디어를 낸 사람에게 스티커, 셀카봉, 커피 기프트카드 같은 작은 보상을 줄 수 있다. - 아이디어를 많이 발산하는 단계에서는 판단을 늦추고, 자유로운 제안을 장려한다. ## 4. 결과물과 성과 공유 - 브레인스토밍이 실패한다고 느끼는 주요 이유는 아이디어 발산 단계에서 실행 가능한 다음 단계로 넘어가기 어렵기 때문이다. - 많은 아이디어를 내는 ‘확산’ 이후에는 추구할 아이디어를 좁히는 ‘수렴’ 단계가 필요하다. - 제안된 아이디어를 있는 그대로 받아들이지 말고 질문을 통해 구체화한다. - 왜 필요한가? - 어떤 문제를 해결하는가? - 실제로 어떻게 구현할 수 있는가? - 각 아이디어를 처음에 정한 북극성과 비교해 평가한다. - 회의 결과물과 논의된 방향을 공유해 참석자들이 아이디어가 어떻게 다음 단계로 이어지는지 알 수 있도록 한다. 브레인스토밍을 준비할 때는 명확한 사전 안내, 참여 규칙, 구체적인 목표, 발산과 수렴을 모두 포함한 진행 구조를 마련하는 것이 좋다. 특히 회의가 끝난 뒤 어떤 아이디어를 선택하고 누가 무엇을 할지까지 연결해야 창의적인 논의가 실제 성과로 이어진다.

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

slackFigmafigjamdesign-thinking+1

figma·2021년 5월 12일·2분 읽기큐레이션 요약

Config 2021

이 글은 Config 2021에서 소개된 팀 문화 변화 사례를 통해, 협업적이고 포용적인 디자인 문화를 만들려면 취약함을 솔직하게 드러내고 서로의 경험을 존중해야 한다고 말한다. 개인의 감정과 필요를 공유하는 투명성, 누구나 참여할 수 있는 공동의 공간과 자원, 다양한 관점을 끌어들이는 협력이 신뢰와 포용성을 강화한다는 결론이다. ## 취약함을 받아들이는 팀 문화 - 업무와 개인 생활의 경계가 흐려진 상황에서는 구성원이 자신의 감정과 필요한 지원을 솔직하게 말할 수 있어야 한다. - Figma 리서치팀은 1:1 대화와 수시 확인 외에도 매일 Slack 스탠드업을 운영했다. - 당일 집중할 업무를 공유한다. - 운동, 취미, 가족과의 시간 등 업무 외에 자신에게 활력을 주는 활동도 함께 이야기한다. - 이 방식은 구성원이 일과 삶의 균형을 지키도록 돕고, 서로를 더 깊이 이해하게 만든다. - 동료를 단순히 경청하는 데서 그치지 않고, 상대의 감정·경험·생각을 표현할 공간까지 마련하는 것이 중요하다. - 항상 괜찮은 척하지 않아도 된다는 점을 인정할 때 팀의 심리적 안전감이 높아진다. ## 모두가 참여할 수 있는 공간 만들기 - Bitcoin 디자인 커뮤니티의 Johns Beharry와 Christoph Ono는 기술 전문성이 부족한 사람에게 Bitcoin 디자인이 배타적으로 느껴질 수 있다는 피드백을 받았다. - Bitcoin의 접근성 확대라는 취지와 달리, 전문 용어나 기술 중심 자료가 진입장벽이 될 수 있음을 인식했다. - 이를 해결하기 위해 여러 형태의 공동 공간과 학습 자원을 구축했다. - 초보자와 경험 많은 디자이너가 교류하는 Slack 그룹 - 작업물을 공유하고 협업하는 GitHub - 자료를 모은 리소스 허브 - 초기 작업과 어려움을 논의하는 주간 커뮤니티 콜 - 모범 사례와 학습 내용을 담은 오픈소스 Bitcoin Design Guide - 자료는 특정 문화, 지역, 언어, 지리적 배경에 한정되지 않도록 설계했다. - 목표는 전문 지식을 과시하는 공간이 아니라, 누구나 질문하고 대화에 참여할 수 있는 “친절한 공간”을 만드는 것이었다. ## 다양성을 위한 협업 - 디자인은 본질적으로 다양한 경험과 관점이 결합되는 협업 활동이다. - 더 많은 사람이 디자인 과정에 참여하면 접근성과 포용성이 높은 결과물을 만들 가능성이 커진다. - 조직이나 개인이 혼자 모든 문제를 해결할 수 없으므로, 커뮤니티와 공유 자원을 활용해야 한다. - 투명한 대화와 열린 참여 구조는 팀 내부뿐 아니라 외부 협력자에게도 신뢰를 형성한다. 팀 문화를 개선하려면 구성원이 힘든 상태를 숨기지 않아도 되는 분위기를 만들고, 정기적인 체크인과 감정 공유를 일상적인 업무 방식에 포함하는 것이 좋다. 동시에 초보자도 접근할 수 있는 공유 문서·커뮤니티·학습 공간을 마련해 다양한 배경의 사람들이 실제 의사결정과 디자인 과정에 참여하도록 해야 한다.

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

slackFigma오픈 소스github+2