Figma Make 공부 정리 | 디자이너가 직접 PR 올리는 게 맞는 건지

Figma 블로그에서 Make 관련 워크플로우 글이 올라와서 읽어봤다. 디자이너가 직접 GitHub에 PR을 올리는 시나리오를 소개하는 글이었는데, “이게 어떻게 가능한 거지?”라는 궁금증에서 공부가 시작됐다.

핸드오프는 늘 디자이너한테 어색한 구간이다. 설명을 어디까지 써야 하는지, 내 의도가 얼마나 전달되는지. 그 구간을 다른 방식으로 접근하는 시도를 보여주는 글이라 흥미로워서 정리해봤다.

1️⃣ 이게 뭐냐?

Figma Make는 실제 코드베이스를 Figma 안에서 연결하고 직접 수정할 수 있는 도구인 것 같다. 글에서 소개된 흐름은 이렇다. 박물관 사이트의 접근성 개선 작업을 예시로, 디자이너가 GitHub 저장소를 Make에 연결하고 새 브랜치를 만든다. 날짜 선택기 컴포넌트를 직접 수정하고, ARIA 라벨이나 포커스 순서 같은 접근성 주석을 달아서 Make 안에서 PR을 올린다. 엔지니어는 리뷰와 최종 승인만 맡는다.

기존 방식과 비교하면 구조가 좀 달라진다. 티켓을 쓰고 백로그에서 대기하다가 엔지니어가 구현하던 흐름이, 디자이너가 직접 변경을 만들고 엔지니어가 검토하는 식으로 역할이 재배치되는 셈이다.

글에서 한 대목이 눈에 들어왔다. 날짜 선택기를 수정하는 도중에 Make가 그 컴포넌트가 사실 세 곳에서 공유되고 있다는 걸 드러냈다는 부분이다. 화면 하나만 고치는 줄 알았던 작업이 코드 구조와 맞닿으면서 더 넓은 맥락이 보인 거다. 디자이너 혼자서는 파악하기 어려운 정보인데, 그걸 작업 흐름 안에서 자연스럽게 마주치게 된다는 게 흥미로웠다.

2️⃣ 내가 든 생각

공부하면서 가장 고민이 생긴 건 “어디까지 책임지는 게 맞냐”는 거였다. 지금까지는 티켓에 최대한 자세하게 쓰고 넘기는 게 디자이너 역할이라고 생각했는데, Make가 제안하는 방향은 한 발 더 들어가는 것 같다. 코드를 직접 수정하는 게 의도를 더 잘 전달하는 방법이 될 수 있다는 거다.

다만 코드를 직접 건드리려면 컴포넌트 구조나 브랜치 전략을 어느 정도는 알아야 할 것 같은데, 그 진입 비용이 얼마나 되는지는 문서만 봐서는 잘 가늠이 안 됐다. “GitHub를 연결하면 된다”는 흐름은 이해했지만, 그게 어느 수준의 개발 지식을 전제로 하는 건지가 궁금하게 남아있다.

👉🏻 인상적으로 남은 건 접근성 주석이 PR에 함께 들어간다는 점이었다. 디자인 의도가 티켓 설명에만 머무는 게 아니라 코드 히스토리에 기록된다는 구조가, 개발을 배우는 입장에서 꽤 의미있게 느껴졌다.

💡 여기서 드는 질문: 디자이너가 PR을 직접 올리는 워크플로우가 자리 잡으면, 디자이너와 엔지니어 각자의 책임 범위는 어떻게 다시 그어지는 걸까?

3️⃣ 어떻게 접근해볼 수 있을까?

공부한 내용 기준으로 생각해보면, Make가 의미 있으려면 디자이너가 코드 구조를 어느 정도 읽을 수 있어야 할 것 같다. 컴포넌트가 어디서 어떻게 쓰이는지, 브랜치를 어떻게 나누는지 같은 기본 개념은 있어야 Make가 드러내는 정보를 의미 있게 받아들일 수 있을 테니까.

React를 공부하면서 “왜 공유 컴포넌트를 쓰는 거지?”라는 질문을 했던 적이 있는데, 이 글에서 그 답의 일부를 반대편에서 보는 것 같았다. 코드 구조가 디자인 결정에도 영향을 준다는 게, 그동안 잘 정리가 안 됐던 부분인데 이번에 조금 선명해진 인상이었다.

⭐️ 마지막으로, 핸드오프를 다시 보며

정리해보니 Make는 “디자이너도 코딩한다”가 아니라 “디자인 의도가 코드 히스토리까지 같이 간다”에 가까운 이야기인 것 같다. 디자인과 개발 사이를 공부하는 지금으로서는, 이 도구가 두 영역 사이를 좁히는 건지 아니면 각자의 자리를 다시 만드는 건지가 아직 잘 안 보인다.

---

참고 원문: Workflow lab: Deploying designs directly with Figma Make