피그마 뉴스레터가 짚은 AI 협업…미완성 작업을 공유하는 팀의 조건

ARCH-B

ARCH-B

Figma Blog 기반 · 2026년 10월 12일 · 4분 분량

0

한눈에 보는 핵심요약

피그마의 뉴스레터 18호는 AI를 활용한 브랜드 디자인, 중첩 폴더 개발과 생성 도구·연구 사례를 함께 소개했다. 핵심은 결과물의 매끈함보다 작업 과정의 공유다. 중첩 폴더 팀이 코드 제안과 직무 간 대화로 바꾼 협업을 통해 실제 판단의 조건을 살펴본다.

  • 뉴스레터18호는 AI 협업의 미완성 과정 공유를 주제로 네 사례를 소개했다.
  • 중첩 폴더 팀은 코드 제안·스테이징 피드백과 직무 간 대화로 작업 방식을 바꿨다고 설명했다.
  • 역할의 유연성과 전문성의 경계가 함께 등장하며 새로운 기능 출시나 독립 성과 실험과는 구분된다.
피그마 뉴스레터가 짚은 AI 협업…미완성 작업을 공유하는 팀의 조건
이미지 제공: Figma Blog · 원출처 기사

AI 작업의 사람과 과정을 모은 뉴스레터

피그마는 2026년 9월 9일 뉴스레터 18호에서 완성되지 않은 스케치와 질문을 공유해야 다른 사람이 생각을 발전시킬 수 있다는 주제를 제시했다. AI로 제품과 시각물을 만드는 팀의 뒤편을 소개하는 편집 글이다. 새 제품 하나의 출시나 모든 팀에 적용되는 실험 결과를 발표한 글이 아니라, 협업의 인간적인 측면을 묶어 보여 주는 호다.

소개한 사례는 Figma Make를 활용한 Config 2026의 시각 정체성, 중첩 폴더를 만든 엔지니어·디자이너·제품 관리자의 역할 변화, 생성형 플러그인과 셰이더 개발 과정, AI 정서 지수 연구의 자료 해석이다. 각 사례를 잇는 편집 관점은 완성된 화면을 보여 주는 데서 멈추지 않고 어떤 제안과 대화가 작업을 만들었는지 드러내는 것이다.

중첩 폴더 팀은 코드 제안으로 생각을 시험했다

뉴스레터가 연결한 중첩 폴더 개발 기록에서 팀은 파일 브라우저와 공유 권한, 관리자 제어와 기반 구조를 함께 바꿔야 했다고 설명한다. 처음에는 요구 정의, 디자인과 구현을 순서대로 진행했지만, 프로젝트 중간의 자원 변화와 AI 도구 확산을 계기로 일하는 방식을 바꿨다. 추상적인 요구 토론을 길게 이어가기보다 실제 코드 제안을 만들어 검증했다는 사례다.

엔지니어 이선 애덤스는 프로토타입을 스테이징에 반영한 뒤 제품 관리자 사치 샤의 피드백을 받고 다듬어 최종 배포하는 흐름을 소개했다. 기록에는 불완전한 문구나 기능도 제안을 시험하는 단계에서 허용했다는 설명이 있다. 이는 개발 중의 검증 공간에서 일한 방식이며, 모든 미완성 변경을 운영 환경에 즉시 배포하라는 일반 규칙으로 제시된 것은 아니다.

직무를 넘나들어도 전문성의 경계는 남았다

디자이너 카이 차르니가는 엔지니어가 설계 흐름을 제안하고 자신도 코드 변경을 시도했다고 설명했다. 폴더 공유 권한의 표현에서는 엔지니어가 기술적으로 가능한 흐름을 만들고 UX 라이터가 문구를 다듬으며 디자이너가 시각적 위계를 조정했다. 역할을 한 사람에게 합치는 방식보다 각자의 판단을 같은 작업 위에서 교환한 사례다.

디자이너는 코드 내부의 복잡성을 보고 자신이 맡지 않는 편이 좋다고 판단한 변경도 있었다고 밝혔다. 제품 관리자는 일상 실행을 일부 맡기는 대신 고객의 초기 접근 프로그램과 프로젝트의 전략적 질문에 시간을 썼다. 회사가 공유한 경험이며 속도 향상의 독립적 측정은 아니다. 직무 간 유연성과 어디서 도움을 받아야 하는지 아는 판단이 함께 나타난다.

ARCH.B 분석

초안 공유는 피드백할 대상을 명확하게 만든다

이 뉴스레터에서 읽을 수 있는 협업의 변화는 AI가 결과물을 만들었다는 사실보다 사람이 의견을 낼 대상이 빨리 생겼다는 점이다. 문장으로 설명한 요구는 각자 다르게 이해하기 쉽지만 작동하는 초안에서는 흐름과 권한 표현을 함께 볼 수 있다. 미완성 상태를 공유하는 일은 완성도를 포기하는 선택이 아니라 서로 다른 판단을 작업에 넣을 시점을 앞당기는 방법으로 이해할 수 있다.

다만 초안을 보는 사람이 현재 상태를 최종 결정으로 오해하면 피드백의 목적이 흐려진다. 팀은 어떤 부분을 시험하고 있으며 무엇이 아직 정해지지 않았는지 표시할 수 있다. 코드 제안에서도 예상 동작과 확인할 질문을 붙이면 구현이 빠르다는 이유로 검토가 생략되는 것을 줄인다. 결과물이 실제로 돌아가는지와 제품의 의도가 맞는지는 서로 다른 검증 질문으로 남는다.

ARCH.B 분석

역할 이동의 목적은 판단을 없애는 데 있지 않다

엔지니어가 디자인 의견을 내고 디자이너가 코드를 다루면 이전의 전달 단계를 줄일 여지가 생긴다. 하지만 권한의 기술 조건, 사용자에게 설명할 언어와 화면의 위계는 각각 다른 지식을 요구한다. 폴더 사례에서 여러 사람이 같은 제안을 함께 수정한 장면은 이러한 전문성이 사라지기보다 더 가까운 위치에서 작동한다는 의미로 읽힌다.

다른 팀이 참고할 부분은 특정 직무의 일을 무조건 옮기는 규칙보다 초안의 공유와 피드백 경로다. 작은 제안에서 판단을 나누고 어려운 부분을 원래 전문성에 연결하는 방식이 가능한지 살펴볼 수 있다. 뉴스레터의 다른 브랜드·도구·연구 사례도 각 작업의 과정을 공개하는 같은 편집 주제 아래 있다. 매끈한 결과만 비교하면 보이지 않는 대화와 선택을 검토할 자료로 남기는 것이 이 호의 실무적 함의다.

출처

Figma Blog의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.

Issue no.18: Show your work (새 창)

Share

Related

함께 읽기 좋은 글