코드, 장인정신, 그리고 중첩 폴더의 제작 | Figma 블로그 (새 탭에서 열림)

Figma의 중첩 폴더는 단순한 파일 정리 기능이 아니라 콘텐츠 구조와 권한 모델을 재설계한 대규모 제품 작업이었다. 개발 과정에서 팀은 전통적인 순차형 프로세스 대신 코드로 아이디어를 빠르게 검증하고, 직무 경계를 유연하게 넘나들며, 인수인계를 대화 중심 협업으로 바꾸었다. 그 결과 변화하는 AI·코드 중심 환경에서도 복잡한 기능을 빠르게 구체화하고 출시할 수 있었다.

중첩 폴더가 단순한 기능이 아니었던 이유

• 중첩 폴더는 규모가 커지는 팀이 파일과 프로젝트를 계층적으로 정리하도록 돕는 기능이다.
• 구현 범위는 파일 브라우저에 그치지 않았다.
  • 콘텐츠 구조
  • 관리자 제어
  • 공유 방식
  • 권한 처리
  • 핵심 인프라
• 따라서 기존 모델에 폴더 한 단계만 추가하는 방식이 아니라, Figma의 콘텐츠 및 권한 모델을 근본적으로 재검토해야 했다.

변화한 제품 개발 환경

• 프로젝트 초기에는 일반적인 순차형 개발 방식을 따랐다.
  • 제품팀이 요구사항을 정의
  • 디자인팀이 사용자 경험을 설계
  • 설계가 충분히 정리된 뒤 엔지니어링 시작
• 그러나 개발 중 팀의 자원과 우선순위가 달라졌다.
  • AI 네이티브 기능 개발로 인력이 분산됨
  • Figma Make, MCP 서버, 에이전트 스킬, 코드베이스 프로토타이핑 등이 아이디어를 빠르게 구현하는 수단으로 부상함
• 아이디어는 더 이상 완성된 문서에서만 출발하지 않고, 프로토타입·코드·Slack의 간단한 스케치에서도 시작될 수 있게 되었다.

코드로 먼저 검증하기

• 코드 작성 비용이 낮아지면서 논쟁이나 추상적인 기획을 오래 이어가기보다 실제 구현물을 빠르게 만들 수 있게 되었다.
• 팀은 아이디어를 검증하기 위해 초기부터 pull request(PR)를 생성했다.
• PR은 단순한 최종 코드 리뷰 수단이 아니라 다음을 확인하는 실험 도구로 활용되었다.
  • 기술적으로 가능한지
  • 사용자 경험이 자연스러운지
  • 권한과 데이터 구조에 문제가 없는지
  • 여러 대안 중 어떤 방향이 적절한지
• 실제 동작하는 결과물을 바탕으로 논의하면서 의사결정 속도와 피드백의 구체성이 높아졌다.

직무 경계를 유연하게 바꾸기

• 역할을 엄격히 분리하기보다 문제 해결에 필요한 사람이 해당 영역의 결정을 맡았다.
• 엔지니어가 디자인 관련 결정을 내리고, 디자이너가 직접 코드를 작성하는 등 업무 범위가 서로 겹쳤다.
• 제품 관리자는 일상적인 실행 관리에서 일부 벗어나 더 큰 전략적 질문에 집중했다.
• 이 방식은 각 직무의 전문성을 없애는 것이 아니라, 프로젝트 상황에 따라 책임을 유연하게 배분하는 접근이다.

인수인계 대신 지속적인 대화

• 디자인 완료 후 개발로 넘기는 식의 일방적인 handoff를 줄였다.
• 역할의 경계가 흐려지면서 팀원들은 서로에게 배우는 동시에 자신의 전문 지식을 공유하는 관계가 되었다.
• 평소 각 직무가 독점하던 작업 방식과 판단 기준을 공개함으로써 협업에 필요한 신뢰를 쌓았다.
• 결과적으로 디자인, 제품, 엔지니어링이 단계별로 분리된 프로세스가 아니라 지속적인 대화와 공동 결정에 가까워졌다.

실용적인 시사점

복잡한 기능을 개발할 때는 완벽한 사전 설계만 기다리기보다 작은 PR과 프로토타입으로 가설을 검증하는 것이 효과적이다. 또한 직무별 책임을 고정하기보다 문제의 성격에 따라 역할을 유연하게 조정하고, 인수인계 문서만으로 소통하기보다 실행 과정에서 지속적으로 대화하는 협업 구조를 만드는 것이 중요하다.