project-management

8 개의 포스트

google원문

생성형 AI를 활용한 미래 대응 역량 강화를 향하여 (새 탭에서 열림)

구글 리서치는 뉴욕대학교(NYU)와의 협력을 통해 생성형 AI를 활용하여 '미래 역량(future-ready skills)'을 측정하는 연구 프로젝트인 'Vantage'를 공개했습니다. 이 시스템은 AI 아바타와의 대화를 통해 협업, 비판적 사고 등 정량화하기 어려운 인간의 역량을 시뮬레이션 환경에서 평가하며, 연구 결과 AI의 채점 정확도가 인간 전문가 수준에 도달했음을 입증했습니다. Vantage는 현재 구글 랩스(Google Labs)를 통해 영어 버전으로 제공되어 교육 현장에서의 활용 가능성을 탐색하고 있습니다. **미래 역량 측정의 난제와 시뮬레이션의 도입** * 비판적 사고, 협업, 창의적 사고와 같은 미래 역량은 현대 사회에서 필수적이지만, 기존의 표준화된 시험으로는 그 사고 과정이나 상호작용을 포착하기 어렵습니다. * 실제 인간 간의 상호작용을 통해 평가하는 방식은 자원 소모가 크고, 모든 학생에게 동일한 갈등 상황이나 과제를 부여하기 어려워 표준화된 채점이 불가능하다는 한계가 있습니다. * Vantage는 이러한 문제를 해결하기 위해 AI 아바타와 함께 과제를 수행하는 역동적인 다자간 대화 환경(Sandbox)을 구축하여 실제 세계와 유사한 평가 시나리오를 제공합니다. **Executive LLM을 활용한 적응형 평가 엔진** * **Executive LLM의 역할:** 대화의 흐름을 실시간으로 분석하고 평가 루브릭(평가 기준표)에 따라 AI 아바타들을 통제합니다. 사용자가 특정 역량을 드러낼 수 있도록 의도적으로 의견을 반박하거나 갈등을 도입하는 등 동적인 도전을 제시합니다. * **데이터 밀도 최적화:** 단순한 대화에 그치지 않고, 평가에 필요한 핵심 정보를 단시간 내에 이끌어낼 수 있도록 대화를 유도하는 '차세대 적응형 평가 엔진' 역할을 수행합니다. * **AI 평가기(Evaluator):** 대화가 종료되면 AI 평가기가 전체 대화 기록을 분석하여 정밀한 기술 지도(Skill map)와 정성적인 피드백을 제공함으로써, 보이지 않던 인간의 역량 발달 과정을 시각화합니다. **연구를 통한 기술적 타당성 검증** * **대화 유도 능력:** 실험 결과, Executive LLM은 독립적인 AI 모델들보다 대화 흐름을 자연스럽게 유지하면서도 평가에 필요한 기술 관련 정보를 훨씬 더 높은 밀도로 이끌어내는 것으로 나타났습니다. * **채점 정확도:** AI 평가자가 매긴 점수와 NYU 전문가들이 매긴 점수를 비교했을 때, 두 집단 간의 일치도는 인간 전문가들 사이의 일치도와 유사한 수준을 기록했습니다. 이는 AI가 복잡한 인간 역량을 신뢰할 수 있는 수준으로 자동 채점할 수 있음을 의미합니다. * **확장성:** 구글은 스타트업 OpenMic과의 협력을 통해 창의성 및 영어 영문학 과제 등 다른 교과 영역에서도 AI 평가기의 성능을 확인하며 적용 범위를 넓히고 있습니다. **실용적인 시사점** Vantage는 교육자가 학생들의 소프트 스킬을 객관적으로 파악하고 이를 기반으로 맞춤형 수업을 설계할 수 있도록 돕는 강력한 도구가 될 수 있습니다. 기술의 발전으로 정답이 없는 복합적인 문제 해결 능력이 중요해진 만큼, 이러한 AI 기반 시뮬레이션 평가 도구를 학습 과정에 도입하여 학생들에게 안전한 실패와 성장의 기회를 제공할 것을 권장합니다.

github3분 읽기큐레이션 요약

입문자를 위한 GitHub: GitHub 이슈

GitHub Issues는 버그·작업·아이디어를 기록하고 협업하는 단위이며, Projects는 이를 시각적으로 구성해 우선순위와 진행 상황을 관리하는 도구다. 두 기능을 함께 사용하면 업무를 빠짐없이 추적하고 팀의 진행 상황을 공유할 수 있다. 글은 이슈 생성부터 Kanban 프로젝트 구성, 사용자 지정 필드·차트·워크플로 설정까지 초보자가 따라 할 수 있는 기본 절차를 설명한다. ## GitHub Issues와 Projects가 필요한 이유 - **Issues**는 버그, 신규 기능, 작업, 아이디어 등 처리해야 할 항목을 공유 공간에 기록한다. - **Projects**는 여러 이슈를 하나의 대시보드에 모아 큰 목표를 작은 작업으로 나누고 관리한다. - 두 기능을 결합하면 다음을 수행할 수 있다. - 업무 우선순위 설정 - 담당자와 진행 상태 공유 - 관련 작업 간 연결 - 팀 전체의 목표와 진행 상황 정렬 ## 첫 번째 Issue 만들기 샘플 저장소나 자신의 저장소에서 다음 순서로 이슈를 생성한다. - **Issues** 탭에서 **New issue**를 선택한다. - 제목에는 처리할 내용을 명확하게 작성한다. - 설명에는 수정하거나 추가해야 할 동작, 기대 결과 등 필요한 정보를 구체적으로 적는다. - 다음 항목을 설정할 수 있다. - **Assignee**: 담당자 지정 - **Labels**: 버그, 기능, 문서 등 분류 - **Type**: 버그나 작업 등의 이슈 유형 지정 - **Projects**: 특정 프로젝트에 이슈 추가 - **Milestone**: 목표 버전이나 일정 단위에 연결 - **Create**를 클릭해 이슈를 생성한다. ## 이슈를 활용한 협업 - 팀원은 이슈에 댓글을 작성해 논의하거나 진행 상황을 공유할 수 있다. - 댓글 입력창에서 `#이슈번호`를 입력하면 다른 이슈와 클릭 가능한 링크로 연결된다. - 관련 작업을 서로 연결하면 의존 관계나 후속 작업을 추적하기 쉽다. - 작업이 완료되면 이슈를 닫아 팀에 해결 사실을 알린다. ## GitHub Project 만들기 Projects는 이슈를 시각적인 작업 보드로 관리하는 기능이다. - 저장소의 **Projects** 탭에서 **New project**를 클릭한다. - 템플릿에서 **Kanban**을 선택한다. - 프로젝트 이름을 입력한다. - 필요하지 않다면 **Bulk import items** 옵션을 해제한다. - **Create project**를 선택한다. - 생성된 프로젝트에는 기본 열이 자동으로 추가되며, 팀의 업무 방식에 맞게 수정할 수 있다. - 프로젝트에는 여러 보기 탭이 제공되므로 보드 형태 등을 전환해 확인할 수 있다. ## 프로젝트 설정과 사용자 지정 프로젝트 우측 상단의 메뉴에서 **Settings**를 열면 다음을 관리할 수 있다. - 프로젝트 접근 권한 - 사용자 지정 필드 생성 및 기존 필드 수정 - 프로젝트 이름과 설명 - README 추가 - 프로젝트 복제 - 프로젝트 공개 범위 - 프로젝트 보드의 전반적인 구성 ## 차트와 인사이트 - **Insights** 메뉴에서 프로젝트 데이터를 바탕으로 차트를 확인하거나 새로 만들 수 있다. - **Configure** 버튼을 사용해 차트의 레이아웃과 표시 방식을 변경할 수 있다. - 차트를 활용하면 작업량, 상태 분포, 진행 추세 등을 시각적으로 파악할 수 있다. ## 워크플로 자동화 **Workflows** 메뉴에서는 프로젝트 항목의 상태를 이벤트에 따라 자동으로 변경하는 기본 워크플로를 설정할 수 있다. - 새 항목이 프로젝트에 추가되면 상태를 `todo`로 지정 - 프로젝트에서 이슈 상태가 변경되면 이슈를 자동으로 닫기 - 이슈가 닫히면 프로젝트 상태를 `Done`으로 변경 이러한 자동화를 사용하면 수동 상태 업데이트를 줄이고 프로젝트 보드의 정보가 실제 진행 상황을 더 잘 반영하도록 만들 수 있다. ## 프로젝트 상태 업데이트 - 프로젝트 화면 상단의 **Add status update**를 선택하면 프로젝트의 건강 상태와 진행 상황을 보고할 수 있다. - 정기적인 상태 업데이트를 남기면 팀원이 현재 진척도와 위험 요소를 쉽게 확인할 수 있다. ## 실용적인 활용 추천 작은 팀이나 개인 프로젝트라도 먼저 이슈를 명확한 제목과 설명으로 작성하고, 담당자·라벨·마일스톤을 일관되게 지정하는 것이 좋다. 이후 Kanban 프로젝트에 이슈를 연결하고 `todo`·진행 중·`Done` 같은 상태와 자동 워크플로를 설정하면 업무 흐름을 간단하고 지속적으로 관리할 수 있다.

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

AI 에이전트 사용법 (새 탭에서 열림)

AI 에이전트는 단순한 명령어 수행을 넘어 스스로 목표를 설정하고 실행 단계를 계획하는 자율성을 갖춘 시스템입니다. 효과적인 도입을 위해 작고 반복적인 워크플로우부터 시작하여 에이전트에게 명확한 목표와 구체적인 소유권을 부여하는 것이 중요합니다. 지속적인 피드백과 단계적 자율성 확대를 통해 AI 에이전트를 단순한 도구가 아닌 신뢰할 수 있는 업무 파트너로 발전시킬 수 있습니다. **AI 에이전트의 정의와 작동 원리** * 프롬프트에 즉각 응답만 하는 기존 생성형 AI와 달리, 에이전트는 주어진 목표(Goal)를 달성하기 위해 자율적으로 움직입니다. * '맥락 수집 - 행동 선택 - 도구 활용 - 결과 평가'라는 지속적인 루프를 반복하며 과업을 완수합니다. * 사용자가 일일이 단계를 지시할 필요 없이, 상황에 맞춰 스스로 다음 행동을 결정하는 '에이전시(Agency)' 능력이 핵심적인 차이점입니다. **효과적인 도입을 위한 5단계 전략** * **반복 가능한 워크플로우 선정**: 본인이 이미 잘 이해하고 있는 소규모 프로세스(조사, 일정 관리, 초안 작성 등)에서 시작하여 에이전트의 판단 방식을 관찰합니다. * **익숙한 도구 활용**: 별도의 코딩 없이도 워드 프로세서, 이메일 클라이언트, 프로젝트 관리 앱에 내장된 에이전트 기능을 활용해 진입 장벽을 낮춥니다. * **명확한 소유권과 목표 정의**: "글을 고쳐줘" 같은 모호한 지시 대신 "논리적 공백을 찾고 보충 자료를 제안하라"와 같이 구체적인 성공 기준을 제시하여 의사결정을 돕습니다. * **행동 테스트 및 세분화**: 특정 시나리오를 먼저 테스트하고, 결과에 따라 지침을 수정하거나 예시를 추가하며 에이전트의 행동을 정교하게 다듬습니다. * **단계적인 자율성 확대**: 에이전트가 일관된 결과물을 내기 시작하면 업무 범위를 넓히거나 여러 도구에 걸친 작업을 수행하도록 책임을 점진적으로 위임합니다. **실무에서의 에이전트 활용 사례** * **연구 및 정보 조직**: 여러 소스에서 정보를 지속적으로 수집하고 테마별로 분류하며, 새로운 정보가 들어올 때마다 기존 노트를 업데이트합니다. * **커뮤니케이션 관리**: 이전 대화 맥락을 참조하여 후속 메일을 작성하고, 프로젝트 변화에 따라 회의 아젠다를 실시간으로 업데이트하며 긴 대화 스레드를 요약합니다. * **콘텐츠 제작 지원**: 거친 메모를 개요로 변환하고, 톤과 명확성을 교정하며, 여러 버전에 걸친 피드백을 반영하여 초안을 완성하는 전 과정을 지원합니다. AI 에이전트의 진정한 가치는 모든 일을 한꺼번에 넘기는 것이 아니라, 인간의 감독 하에 세심하게 설정된 프로세스를 통해 실현됩니다. 에이전트가 신뢰할 수 있는 결과를 낼 때까지 통제권을 유지하며 점진적으로 업무 범위를 넓혀가는 방식이 가장 실무적이고 안전한 접근법입니다.

figma3분 읽기큐레이션 요약

역할과 책임은 이제 과거의

제품 개발 조직에서 역할과 책임의 경계가 점점 흐려지고 있다. 디자이너뿐 아니라 PM, 개발자, 마케터 등 다양한 직군이 디자인과 프로토타이핑에 참여하며, 응답자의 64%가 두 개 이상의 역할을 수행한다고 답했다. 이러한 변화는 협업과 의사결정을 빠르게 만들지만, 도구의 과잉과 역할 혼선이라는 새로운 문제도 낳고 있다. ## 제품팀의 역할 경계가 흐려지는 현상 - Figma는 Factworks와 Fusion Hill을 통해 51건의 정성 인터뷰와 1,199명 대상 설문을 진행했다. - 응답자의 64%가 자신을 두 개 이상의 역할로 인식했으며, 3분의 1 이상은 세 개 이상의 역할을 수행한다고 답했다. - 비디자이너의 56%는 적어도 하나의 디자인 관련 업무에 “많이” 또는 “매우 많이” 참여한다고 응답했다. - PM이 프로토타입을 만들고, 개발자가 초기 디자인을 검토하며, 마케터와 콘텐츠 담당자가 Figma 파일에 직접 의견을 남기는 방식이 일반화되고 있다. ## 디자인은 디자이너만의 업무가 아니다 - 비디자이너의 디자인 관련 업무 참여는 전년보다 10% 증가했다. - PM의 70%가 저충실도 목업이나 와이어프레임을 만들고 있으며, 59%는 인터랙티브 프로토타이핑도 수행한다고 답했다. - 제품 개발자 4명 중 1명은 최근 새로운 디자인 도구를 도입했다. - 아직 디자인 도구를 사용하지 않는 사람 중 42%는 1년 안에 사용할 계획이라고 밝혔다. - 마케터는 소셜 미디어용 시각 자료를 만들고, PM은 디자이너의 작업을 기다리기 전에 아이디어를 시각화하는 식으로 업무가 확장되고 있다. ## 역할 중첩이 협업을 개선하는 방식 - PM이 초기 아이디어를 목업으로 만들면 디자이너가 더 일찍 방향을 조정하고 불필요한 수정 왕복을 줄일 수 있다. - 개발자가 구현 전에 Figma 목업을 검토하면 기술적 제약이나 실현 가능성 문제를 조기에 발견할 수 있다. - 초기 시각화는 문제와 해결책에 대한 공통 이해를 형성하고, 직군 간 커뮤니케이션을 구체화한다. - 절약된 시간은 사용자 조사, 전략 수립, 디자인 시스템 유지·확장, 전문 역량 강화에 재투자할 수 있다. - 다만 역할 확장이 전문 디자이너의 가치를 대체한다기보다, 각 직군이 더 효과적으로 협업하기 위한 수단으로 활용되어야 한다. - 이를 위해서는 팀 내 신뢰 관계, 이른 단계의 비전 정렬, 새로운 도구를 배우는 동료에 대한 개방성이 중요하다. ## 도구 확산과 AI가 역할 변화를 가속한다 - 응답자의 72%는 AI 도구를 역할 변화의 가장 큰 원인으로 꼽았다. - Figma Make, Claude Code, GitHub Copilot 등을 활용하면 몇 가지 프롬프트만으로 프로토타입이나 실행 가능한 코드를 빠르게 만들 수 있다. - Notion, Figma Buzz, Airtable 같은 도구는 마케팅 자산 제작과 프로젝트 관리도 간소화한다. - 기술이 특정 직군의 전유물이 되기보다, 여러 직군이 직접 결과물을 만들 수 있도록 진입 장벽을 낮추고 있다. ## 도구 과잉이 만드는 마찰 - 역할 변화의 결과로 더 많은 소프트웨어를 사용하게 되었다고 답한 응답자는 71%였다. - 조사 대상은 스프레드시트, 프로젝트 관리, 그래픽 디자인, 코딩 보조 등 16개 도구 범주를 사용했다. - 제품팀은 평균 7.6개 범주의 도구를 함께 사용하고 있어, 개별 도구의 효과가 분산될 수 있다. - 새로운 도구가 빠르게 등장하면서 구성원이 이를 모두 학습하고 업무 흐름에 통합하기 어려워지고 있다. - 따라서 도구를 무조건 추가하기보다 팀의 협업 방식과 목적에 맞는 도구를 선택하고, 중복되는 워크플로를 줄이는 접근이 필요하다. 역할의 경계가 사라지는 흐름은 피하기보다 효과적으로 관리해야 한다. 각 직군이 초기 단계에서 시각화와 프로토타이핑에 참여하도록 장려하되, 전문성을 존중하고 도구 수를 체계적으로 관리하면 협업 속도와 제품 품질을 함께 높일 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

리니어 방식: 주

Linear는 모든 사용자가 각자 업무 방식을 설계하도록 방치하기보다, 특정 목적에 최적화된 “의견이 분명한 소프트웨어”를 제공해야 한다고 주장한다. 명확한 기본값과 단순한 개념으로 사용자의 학습 부담을 줄이고, 프로세스 논쟁보다 실제 제품 개발에 집중하게 만드는 것이 목표다. 다만 모든 결정을 고정하는 것은 아니며, 작은 단위에는 강한 원칙을 적용하고 큰 구조에는 고객 피드백을 반영하면서 의견을 계속 발전시킨다. ## 의견이 분명한 소프트웨어란 무엇인가 - 특정 사용 사례를 위해 설계된 소프트웨어로, 여러 분야에 두루 적용되는 범용 도구와 구별된다. - Linear의 목적은 팀이 더 나은 제품을 만들도록 돕는 협업형 이슈 추적·프로젝트 관리다. - 사용자가 각자 워크플로를 만들도록 유연성만 제공하면 조직이 성장할수록 방식이 제각각이 되어 혼란이 생길 수 있다. - 따라서 “무엇이든 가능한 도구”보다 “가장 좋은 기본 방식”을 제시하는 것을 중시한다. ## 원자적 단위에서 강한 기본값 만들기 - 프로젝트, 팀처럼 누구나 이해할 수 있는 일반적인 용어를 사용해 학습 곡선과 전문 용어 부담을 낮춘다. - 사용자가 매뉴얼을 읽지 않아도 바로 시작할 수 있도록 설계한다. - 반드시 하나의 정답만 강제하는 것이 아니라, 사용자가 자연스럽게 따를 수 있는 기본값을 제공한다. - 라벨과 마감일을 이슈의 속성으로 두는 것처럼, 세부적인 기능·구조에서는 강한 제품 의견을 적용한다. - 반면 프로젝트와 같은 상위 개념은 회사마다 조직 구조가 다르므로 고객 피드백을 더 적극적으로 반영한다. - 핵심 목표는 프로세스의 세부 사항을 끝없이 조정하는 시간을 줄이고, 실제 구축 작업에 빨리 진입하게 하는 것이다. ## 제품 부채를 전략적으로 감수하기 - 제품 부채는 단순히 잘못 작성된 코드인 기술 부채와 다르다. - 기능 범위나 완성도를 의도적으로 줄여 단기 목표를 달성하고, 나중에 사용자 피드백이나 추가 리소스라는 비용을 치르는 선택으로 본다. - 모든 기능을 처음부터 완벽하게 만들기보다, 사용자 경험에 미치는 영향과 “이자율”을 따져 부채를 선택적으로 감수한다. - Linear의 설정 화면은 기능, 환경설정, 섹션을 계속 추가해 왔지만 전체 경험을 재설계하지는 않은 사례다. - 설정 화면은 핵심 업무 흐름을 좌우하는 영역이 아니므로, 당장 전면 개편하지 않아도 비용이 비교적 낮다고 판단했다. - 여기서 말하는 지름길은 품질을 무조건 낮추는 것이 아니라, 초기 구현의 범위를 줄이는 방식에 가깝다. ## 강한 원칙도 계속 발전시키기 - 스타트업의 제품 개발은 고정된 레시피를 따르는 일이 아니라 실험과 반복의 과정이다. - 사용자의 반발이 두려워 기존 경험을 영원히 유지하면 제품이 변화할 수 없게 된다. - 사용자의 업무 흐름에 큰 영향을 주는 변경은 신중해야 하지만, 모든 기능을 절대 바꿀 수 없도록 만드는 것은 바람직하지 않다. - 강한 의견은 처음부터 완벽한 규칙으로 고정하는 것이 아니라, 실제 사용과 피드백을 통해 수정할 수 있어야 한다. - 즉, 원칙은 강하게 유지하되 구현과 사용자 경험은 필요에 따라 실험하고 바꿀 수 있어야 한다. 팀이 제품을 설계할 때는 모든 것을 자유롭게 설정하게 하기보다, 핵심 사용 사례에 맞는 명확한 기본값을 먼저 제공하는 것이 효과적이다. 다만 세부 기능에는 일관된 의견을 적용하되 조직 구조나 업무 방식처럼 회사마다 다른 영역은 고객 피드백에 열어 두고, 감수한 제품 부채는 장기적으로 상환할 계획을 함께 세우는 것이 좋다.

원문 읽기(새 탭에서 열림)
figma2분 읽기큐레이션 요약

Config 2021

Config 2021의 핵심 메시지는 제품 개발에서 실패, 지연, 갈등 같은 “엉킨 순간”을 피하기보다 성장의 재료로 받아들여야 한다는 것이다. 프로젝트가 중단되거나 팀 내 마찰이 생겨도 이를 개인적 실패로 해석하지 말고, 기록·대화·성찰을 통해 다음 작업과 더 나은 협업으로 전환해야 한다. ## 실패와 좌절을 새로운 관점에서 바라보기 Shopify의 Shanique Shields는 1년 반 동안 진행한 기능이 롤백된 경험을 소개한다. 처음에는 자신의 실패라고 느꼈지만, 프로젝트에서 잠시 거리를 둔 뒤 이를 학습의 기회로 재해석할 수 있었다. - **실패를 개인적인 평가로 받아들이지 않기** - 피드백이나 기능 변경은 작업자의 능력보다 이해관계자와 고객의 관점 차이에서 비롯될 수 있다. - **과정을 문서화하기** - 출시되지 않은 작업이라도 디자인 의도, 의사결정 과정, Figma 댓글과 메모를 보존한다. - 기록은 다음 프로젝트에서 개선점을 찾게 하고, 다른 디자이너가 참고할 수 있는 작업 아카이브가 된다. - **프로젝트에서 얻을 것을 의식하기** - 새로운 기술, 사업 영역에 대한 이해, 다른 직군과의 협업 경험 등 프로젝트를 통해 얻는 성장을 명확히 파악한다. - **다음 작업을 새로운 출발점으로 삼기** - 실패감에 머무르기보다 다음 업무의 공동 목표를 세우고 팀의 동기를 다시 끌어올린다. ## 솔직한 대화와 주의 깊은 경청 Headspace의 Frank Bach는 팀의 갈등을 방치하지 말고 투명한 대화로 해결해야 한다고 강조한다. 강한 팀 문화와 프로세스가 있어도 의사소통이 끊기면 문제가 쌓일 수 있기 때문이다. - 갈등 상황에서 자신의 입장을 최대한 투명하게 설명한다. - 상대방의 말을 실제로 이해하려는 태도로 듣는다. - 어려운 대화라도 객관적이고 솔직하게 시작해야 한다. - 마찰을 무시하면 문제가 해결되지 않고 더 커지므로, 용기를 내어 직접 다룬다. - 일이 잘 풀렸을 때는 동료, 팀, 디자이너로서의 기회에 감사하는 태도도 중요하다. ## 지속 가능한 팀 문화를 만드는 태도 Config 2021에서는 팀 문화 전환과 확장 가능한 프로세스도 다뤘지만, 실제 업무에서는 예상치 못한 장애와 인간적인 갈등이 언제든 발생한다는 점을 전제로 한다. - 완벽하게 정리된 프로세스만으로 모든 문제를 예방할 수는 없다. - 실패와 충돌을 숨기기보다 학습 가능한 경험으로 공개적으로 다룬다. - 개인의 감정적 회복과 팀 차원의 목표 재정렬을 함께 진행한다. - 기록과 솔직한 대화를 통해 어려운 경험을 조직의 지식으로 전환한다. 실무에서는 프로젝트가 중단되거나 갈등이 생겼을 때 즉시 자책하거나 회피하기보다, 잠시 거리를 두고 과정을 기록한 뒤 당사자들과 사실 중심으로 대화하는 것이 좋다. 그렇게 하면 실패한 결과도 개인과 팀의 성장 자산으로 남길 수 있다.

원문 읽기(새 탭에서 열림)
figma4분 읽기큐레이션 요약

쇼피파이에서 협업을

Shopify는 Figma 파일을 팀 간 협업의 공용 작업 공간으로 활용하기 위해, 프로젝트 상태와 산출물을 일정한 구조로 정리하는 템플릿을 사용한다. 이 템플릿은 GSD(Get Sh*t Done)의 **Think–Explore–Build** 프로세스를 기반으로 하며, 실제로 구현할 결과물을 가장 앞에 배치해 필요한 정보를 빠르게 찾도록 설계됐다. 핵심은 파일마다 예측 가능한 구조와 상태 표시를 적용해 디자인·제품·엔지니어링 팀의 커뮤니케이션 비용을 줄이는 것이다. ## 일관된 파일 구조가 필요한 이유 - Figma는 협업을 쉽게 만들지만, 시간이 지나면서 파일과 산출물이 많아지면 다음과 같은 문제가 생긴다. - 어떤 디자인이 최신인지 파악하기 어렵다. - 특정 레이아웃이 승인됐는지 알기 어렵다. - 실제 구현 대상과 사용자 테스트용 프로토타입을 구분하기 어렵다. - 제품 관리자, 엔지니어, 다른 디자이너가 필요한 정보를 찾기 어렵다. - Shopify는 팀마다 다른 파일 정리 방식을 사용하는 문제를 해결하기 위해 공통 템플릿을 만들었다. - 일정한 형식은 여러 팀이 파일을 탐색할 때 기대할 수 있는 공통 규칙을 제공하고, 프로젝트 초기 설정 시간도 줄여준다. ## GSD 프로세스와 템플릿의 페이지 순서 - Shopify의 GSD 프레임워크는 세 단계로 구성된다. - **Think**: 문제와 배경을 이해한다. - **Explore**: 다양한 해결책을 탐색한다. - **Build**: 선택한 해결책을 구체화하고 출시한다. - 템플릿의 페이지는 이 순서와 반대로 구성된다. - 가장 중요한 구현 준비 상태의 결과물을 파일 앞부분에 둔다. - 사용자가 파일을 열었을 때 최근 작업과 실행 가능한 결과를 먼저 확인할 수 있다. - 새 파일을 만들 때는 표지와 프로젝트 개요를 먼저 작성한 뒤, Think 섹션의 정보를 채우는 방식으로 시작한다. - Explore 단계에서는 필요한 만큼 페이지를 만들고 자유롭게 실험한다. - Build 단계에 들어가면 Explore에서 선택된 페이지나 레이아웃을 Build 섹션으로 이동한다. ## 표지: 프로젝트의 현재 상태를 한눈에 표시 - 새 Figma 파일을 만들 때 표지를 먼저 구성한다. - 표지에는 다음과 같은 정보를 담는다. - 프로젝트명 - 담당 팀 - 프로젝트 상태 - Figma 프로젝트의 그리드 보기에서도 파일을 쉽게 식별할 수 있다. - 프로젝트가 진행될 때마다 상태 표시를 갱신해야 현재 단계가 혼동되지 않는다. ## 프로젝트 개요: 배경과 담당자 연결 - 개요 페이지에는 프로젝트를 이해하는 데 필요한 추가 정보를 제공한다. - 포함할 수 있는 내용은 다음과 같다. - 관련 문서와 리서치 링크 - 프로젝트 브리프 - 피드백을 줄 담당자 - 질문이나 문의를 전달할 연락처 - 필요에 따라 섹션과 항목을 추가하거나 삭제할 수 있다. - Figma 문서에 문서 링크나 Slack 프로필 링크를 붙여 넣으면 관련 앱을 바로 열 수 있어 탐색 과정이 단순해진다. ## Think: 문제 공간과 프로젝트 기반 정리 - Think 섹션은 탐색을 시작하기 전에 문제와 맥락을 정리하는 공간이다. - 다음과 같은 자료를 모을 수 있다. - 사용자 플로우 - 고객 여정 지도 - 잡 스토리(job story) - 디자인 스프린트 결과물 - 과거 디자인이나 영감을 위한 스크린샷 - 관련 외부 문서 링크 - 이 단계의 목적은 해결책을 바로 결정하는 것이 아니라, 탐색에 필요한 정보를 한곳에 모아 프로젝트의 기반을 만드는 것이다. ## Explore: 다양한 아이디어를 실험하고 피드백 수집 - Explore는 여러 해결책을 넓고 깊게 시도하는 작업 공간이다. - 협업과 댓글, 피드백이 가장 활발하게 발생하는 영역으로 활용한다. - 효과적인 정리를 위해 다음 규칙을 적용할 수 있다. - 태블릿·모바일처럼 기기나 화면 형태가 다르면 별도 페이지로 나눈다. - 탐색 결과와 사용자 플로우에 제목을 붙여 내용을 명확히 한다. - 진행 상태를 나타내는 배지를 추가한다. - 새 페이지마다 날짜를 기록해 최신 작업인지 확인할 수 있게 한다. - 사용자 테스트용 프로토타입은 별도 페이지로 관리한다. - 스티키 노트로 메모, 아이디어, 피드백, 후속 작업을 기록한다. - 이 단계에서는 가능한 접근법을 많이 시도한 뒤, 피드백을 바탕으로 구현할 방향을 좁혀 간다. ## Build: 선택된 결과물을 구현 단계로 이동 - Build는 탐색을 마친 뒤 적절한 해결책을 구체화하고 출시 및 피드백으로 연결하는 단계다. - Explore에서 검토한 여러 시안 중 실제로 진행할 페이지나 레이아웃만 Build 섹션으로 이동한다. - 이를 통해 실험 중인 아이디어와 구현 대상으로 확정된 결과물을 명확히 분리할 수 있다. - 파일 앞부분에 Build 관련 결과물이 배치되므로 다른 직군도 현재 구현 대상과 프로젝트 진행 상황을 빠르게 파악할 수 있다. 팀 단위로 Figma를 운영한다면 표지, 개요, Think–Explore–Build 섹션을 기본 템플릿으로 정하고, 날짜·상태 배지·담당자·관련 링크를 의무적으로 기록하는 방식이 실용적이다. 특히 Explore의 자유로운 실험 공간과 Build의 확정 산출물을 분리하면 최신 디자인과 구현 대상을 찾는 데 드는 커뮤니케이션 비용을 크게 줄일 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

디자인 도구를 평가하는 방법 | Figma 블로그

팀에 맞는 디자인 도구를 고를 때는 기능 비교나 리뷰만으로 결정하지 말고, 팀 규모·분산 환경·업무 방식·협업 상대를 기준으로 체계적으로 평가해야 한다. 도구 선정은 제품 출시나 디자인 스프린트처럼 하나의 프로젝트로 관리하고, 준비·탐색·기준 수립·후보 선정·테스트·최종 결정의 단계를 거치는 것이 효과적이다. 충분한 사전 조사와 실제 업무 테스트를 진행하면 도입 이후의 혼란과 비용을 줄일 수 있다. ## 도구 선정을 하나의 프로젝트로 관리 - 도구 변경을 즉흥적인 구매가 아니라 제품 출시나 디자인 스프린트와 같은 프로젝트로 취급한다. - 팀의 분기별 계획에 평가 작업을 포함하고, 담당자와 일정을 명확히 정한다. - 조직이 복잡할수록 한 번에 전환하기보다 단계적인 도입 계획이 필요하다. ## 일정과 의사결정 구조 마련 - 전체 과정에는 대략 한 달을 배정할 수 있다. - 약 2주: 준비와 조사 - 약 2주: 짧은 실제 프로젝트에서 후보 도구 테스트 - 프로젝트 관리 도구에 작업 일정을 등록하고, 최종 마감일을 정한다. - 특정 도구가 충분히 우수하다는 결론이 일찍 나면 모든 후보를 끝까지 검토할 필요는 없다. - 디자이너뿐 아니라 프로젝트 승인자, 개발자, 제품 관리자, 마케팅 등 영향을 받는 이해관계자를 사전에 참여시킨다. ## 교차 기능 워킹 그룹 구성 - 도구 선정과 도입을 함께 담당할 공식 그룹을 만들 수 있다. - 여러 팀의 구성원이 참여하면 각 조직의 요구사항과 우려를 균형 있게 반영할 수 있다. - 정기적인 짧은 회의와 전용 Slack 채널 등을 활용해 질문과 피드백을 모은다. - 평가가 끝난 뒤에도 이 그룹은 교육, 전환, 문제 해결을 지원하는 역할을 할 수 있다. ## 평가 과정과 사용 경험 기록 - 일정, 의사결정, 공식 피드백을 공유 문서에 기록한다. - 기능 목록뿐 아니라 실제 업무에서 도구가 어떻게 작동했는지에 대한 자유로운 의견도 남긴다. - 문서에는 사용 중 편했던 점, 막혔던 순간, 기존 워크플로와의 충돌 등을 구체적으로 적는다. - 새 도구를 도입하면 초기 적응 기간이 필요하므로, 도입 후 몇 주 동안 생산성이 일시적으로 낮아질 수 있음을 이해관계자에게 미리 알린다. ## 팀의 상황과 우선순위 정의 - 후보 도구를 비교하기 전에 팀이 실제로 해결하려는 문제가 무엇인지 합의한다. - 다음과 같은 조건을 점검한다. - 팀 규모와 성장 속도 - 구성원의 근무 장소와 원격근무 비중 - 신규 인력 온보딩 빈도 - 다른 직군과의 협업 방식 - 대규모 팀은 공유 라이브러리와 디자인 시스템을 통한 일관성과 확장성을 중시할 수 있다. - 빠르게 성장하는 팀은 신규 구성원이 쉽게 배우고 업무에 참여할 수 있는지가 중요하다. - 원격 팀은 실시간 협업과 커뮤니케이션 기능을 우선적으로 고려할 가능성이 높다. ## 현재 도구의 문제점 파악 - 기존 도구에서 불편한 점을 막연하게 나열하지 말고, 문제가 발생하는 구체적인 순간을 기록한다. - 예를 들어 개발자 핸드오프, 디자인 리뷰, 파일 공유, 협업 과정에서 어디가 끊기는지 확인한다. - 디자이너 외에도 개발자, 제품 관리자, 마케터에게 의견을 받아 직접 보이지 않던 문제를 발견한다. - 현재 도구의 단점을 파악해야 새 도구가 반드시 해결해야 할 요구사항을 정의할 수 있다. ## 평가 기준을 주제별로 정리 - 수집한 요구사항을 몇 가지 핵심 주제로 묶어 후보 도구를 평가한다. - 글에서 제시한 주요 주제 중 하나는 **생산성**이다. - 개인 작업뿐 아니라 스프린트 계획, 디자인 리뷰, 개발자 핸드오프까지 전체 흐름을 살핀다. - 이미 효율적인 업무와 개선이 필요한 업무를 구분한다. - 새 도구가 기존 워크플로에 자연스럽게 통합되는지 확인한다. - 이후 후보 도구는 이러한 기준에 따라 비교하고, 소수의 최종 후보를 선정한 뒤 실제 단기 프로젝트에서 테스트해야 한다. 도구의 “최고 기능”보다 우리 팀의 협업 방식과 문제를 얼마나 잘 해결하는지가 더 중요하다. 이해관계자를 일찍 참여시키고, 실제 업무를 기준으로 일정 기간 테스트한 뒤, 도입 후 적응 비용까지 고려해 결정하는 것이 현실적인 방법이다.

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