Figma nested folders 공부 정리 | 코드를 제안서로 쓴다는 것

Figma 블로그에 nested folders 출시에 관한 글이 올라왔다. 처음엔 기능 안내 글인 줄 알았는데, 읽어보니 기능 자체보다 이걸 만드는 과정 이야기가 훨씬 많았다. 읽다가 중간에 “code as proposal”이라는 표현이 나오는데, 이 부분에서 잠깐 멈췄다.

코드를 제안서로 쓴다는 게 무슨 의미인지 정리하고 싶어서 좀 더 꼼꼼히 읽어봤다.

1️⃣ 이게 뭐냐?

nested folders는 Figma 안에서 폴더 안에 폴더를 만들 수 있는 기능이다. 파일 브라우저와 공유 권한 시스템이 함께 재정비됐다고 나온다. 팀이 커질수록 파일이 뒤섞이는 문제를 해결하는 방향인데, 기능 자체는 어렵지 않게 이해됐다.

블로그에서 더 길게 다룬 건 이 기능을 만드는 과정이었다. 팀은 요구사항을 먼저 논의하고 설계하는 순서 대신, 직접 PR을 올려 아이디어를 검증하는 방식을 선택했다. 글에서 나오는 표현으로는 “코드가 저렴해진 시대에 이론 토론 대신 직접 빌드했다”는 맥락이다.

역할도 유연하게 섞였다. 엔지니어가 폴더 공유 플로우를 목업으로 그렸고, 디자이너는 PR을 2~3개 작성했다. PM은 일상적인 실행 결정에서 빠져나와 고객 관련 질문에 집중했다. 블로그 표현으로는 “핸드오프를 대화로 바꿨다”고 정리한다.

실무 리듬도 변했다. 주간 버그 배시, 크로스펑셔널 동기화, 실시간 페어링 같은 공유 루틴이 생겼다. 구조가 협업 방식을 만든 게 아니라, 공유 리듬을 먼저 만든 다음 협업 방식이 따라온 것 같다는 인상이었다.

2️⃣ 내가 든 생각

디자이너 입장에서 읽으면서 흥미로웠던 건 “핸드오프를 없앤다”는 목표를 세운 게 아니라, 협업 방식을 바꾸다 보니 결과적으로 그렇게 됐다는 흐름이었다. 목표가 아니라 부산물처럼 생긴 변화였다.

“code as proposal”이라는 개념이 계속 머릿속에 남았다. 완성된 결과물을 전달하는 게 아니라, 방향을 잡은 초안을 코드로 내놓고 거기서 논의를 시작하는 방식이다. 코드가 커뮤니케이션 도구 역할을 하는 것인데, 이게 어떤 방식으로 느껴지는지는 문서만 본 입장에서는 아직 잘 모르겠다는 생각이 들었다.

👉🏻 특히 궁금했던 건 디자이너가 PR을 올릴 때의 기대 수준이었다. 실제로 동작하는 코드인지, 아니면 방향만 잡은 스케치에 가까운 코드인지에 따라 진입 장벽이 많이 달라질 것 같다. 블로그에서는 그 기준을 명확하게 설명하지 않아서 이 부분이 계속 걸렸다.

💡 여기서 드는 질문: 이 협업 방식은 팀원이 서로 코드와 디자인 언어를 어느 정도 공유하고 있어야 가능한 건지, 아니면 PR이라는 구조 자체가 그 격차를 줄여주는 건지 불분명했다.

3️⃣ 이걸 공부하면서 연결된 것

프론트엔드를 배우면서 디자이너-개발자 경계 어딘가에 있는 상태가 어색하게 느껴질 때가 있다. 완전히 어느 쪽에도 속하지 못하는 느낌이다. 그런데 이 글을 읽다 보니 그 중간 지점을 의도적으로 만든 팀이 있다는 게 좀 달리 보였다. 어정쩡함이 약점이 아니라, 협업의 조건이 될 수도 있을 것 같다는 생각이 들었다.

공부한 내용 기준으로는, 이런 방식이 잘 작동하려면 도구보다 먼저 리듬과 신뢰가 있어야 할 것 같다. 공유 루틴이 먼저 생기고 나서 역할 경계가 흐려졌다는 게 그 순서를 보여주는 것 같다.

⭐️ 마지막으로, 이 글을 공부하며 남은 인상

정리해보니 nested folders 출시 얘기라기보다, 코드와 디자인이 만나는 방식에 관한 팀 실험기에 가까웠다. 결과물보다 과정을 더 길게 쓴 것도 그 방향인 것 같았다. 공부 끝에 남은 건 “핸드오프를 없애면 어떻게 될까”가 아니라, “어떻게 없어지게 됐을까”라는 질문이었다.

---

참고 원문: Code, craft, and the making of nested folders