생산성을 위해 만든 도구는 왜 자리 잡지 못했을까? (feat. Figma 자동 업로드)

이 게시물은 “이런 자동화를 만들었다”에 대한 기록이 아니다.
오히려 실제 팀 workflow 안에서 자동화가 왜 자리 잡지 못했는지, 그리고 AI와 MCP를 빠르게 붙일 수 있다는 가능성에 집중한 나머지 어떤 과정을 놓쳤는지에 대한 회고에 더 가깝다.

기술적으로는 꽤 만족스러웠지만, 결국 “잘 만든 도구”와 “실제로 사용되는 도구” 사이에는 꽤 큰 간극이 있다는 걸 직접 부딪혀보며 배웠다.

---

최근 내가 속한 팀의 업무 프로세스가 바뀌었다. 디자이너가 모든 화면을 먼저 그려서 넘겨야 시작할 수 있던 개발 방식에서 개발자가 직접 화면을 기획하고 그대로 개발하는 쪽으로 무게가 옮겨갔다. 일단 만들고 개선이 필요한 부분은 디자이너와 함께 다듬는 식이다.

이 과정을 거치다 보니 한 가지 번거로운 작업이 눈에 띄었다. 디자이너가 개발자가 선 개발한 화면을 보고 개선 제안을 하기 위해서는 직접 서비스 콘솔에 로그인하고, 화면을 하나하나 찾아 들어가서 캡처하고 그걸 다시 Figma에 옮겨 그리고 있는 작업이다.

디자인보다 개발이 앞서 가니까 디자인이 거꾸로 완성된 화면을 쫓아가는 구조가 된 셈이었다. 그리고 새 화면이 나올 때마다 이 과정은 통째로 반복됐다.

옆에서 보다가 문득, 이 과정을 자동화해두면 디자이너가 매번 손으로 할 필요 없이 한결 편해지지 않을까 싶었다.

---

💡그래서 만들어봤다.

생각이 여기까지 닿고 나니 그냥 두기엔 조금 아깝다는 생각이 들었다. 작업 자체가 반복적이고 흐름도 단순해서, 자동화하기에 꽤 적합한 영역처럼 보였기 때문이다. 아이디어는 의외로 간단했다.

실행 중인 콘솔 화면을 자동으로 캡처하고, 그 이미지를 Figma로 바로 올려주는 커맨드.
이 정도만 되어도 디자이너가 화면 확인을 위해 개발자와 여러 번 소통하는 과정이나 반복적인 수작업을 꽤 줄일 수 있겠다고 생각했다.

그런데 막상 만들기 시작하니 욕심이 조금 더 생겼다. 어차피 만드는 거라면 단순한 이미지 한 장보다는, 디자이너가 받아서 바로 수정하고 활용할 수 있는 형태로 전달하고 싶었다. 그래서 Figma 공식 MCP를 붙여 실행 중인 화면을 편집 가능한 디자인 레이어 형태로 변환하도록 구성했다.

구현 과정이 순탄하지만은 않았다. 콘솔이 SPA 구조이다 보니 데이터가 비동기로 늦게 렌더링되는 경우가 많았고, 타이밍이 맞지 않으면 빈 화면이 캡처되기도 했다. 그래서 렌더링이 완료될 때까지 기다린 뒤 캡처하도록 처리했다.

또 단순 페이지뿐 아니라 드로어·모달처럼 사용자 액션 이후에 노출되는 화면까지 수집할 수 있어야 했기 때문에, playwright를 도입해 실제 클릭 플로우를 따라가며 화면을 캡처하도록 구성했다.

여기에 그치지 않고, 업로드된 프레임이 기능별 카테고리(정책, 통계, 실시간 대시보드 등)로 자동 정리되도록 했고, 작업이 완료되면 관련 담당자들이 바로 확인할 수 있도록 Slack 알림까지 연결했다.

결국 내가 만들고 싶었던 건 단순한 “캡처 자동화”가 아니라,
“실행 중인 서비스를 디자인 자산으로 변환해주는 흐름”에 가까웠던 것 같다.

그리고 실제로도 그림대로 잘 동작했다. 라우트와 기능명만 넣으면 화면이 편집 가능한 레이어로 Figma에 차곡차곡 쌓였고,

업로드가 끝나면 슬랙으로 알림까지 정확히 날아왔다.

여기까지 구현하고 나니, 디자이너가 매번 반복하던 번거로운 작업을 꽤 많이 덜어줄 수 있겠다는 생각이 들었다.
조금은 자기만족에 가까운 감정이었지만.. 솔직히 꽤 뿌듯했다.

---

만들었지만, 습관은 바꾸지 못했다

여기서부터가 진짜 시작이었다.
도구를 만드는 것과, 그 도구가 실제로 사용되는 건 완전히 다른 문제였다.

가장 먼저 부딪힌 건 속도였다. 화면 하나를 수집하려면 데이터 로딩을 기다리고, 캡처하고, 변환하고, 정리하는 과정까지 포함해 2~3분 정도가 걸렸는데, “커맨드 하나면 끝”이라고 하기엔 그 몇 분이 생각보다 길게 느껴졌다.

다음은 익숙함의 문제였다. 아무리 편한 프로세스라도 손에 익기 전까지는 잘 사용되지 않는다는 걸 이때 체감했다. 기존 방식이 이미 익숙한 상태이다 보니, 새 커맨드는 “있다는 건 알지만 굳이 쓰지는 않는” 애매한 위치에 머물게 됐다.

그리고 가장 어려웠던 건 마지막 지점이었다.
정작 결과물을 받아야 하는 디자이너 입장에서는, 자동으로 생성된 결과물이 완전히 실무 친화적인 형태는 아니었던 것이다.

편집 가능한 레이어 형태로 넘기긴 했지만, 실제로 개선안을 작업하려면 결국 디자이너 기준에 맞게 화면을 다시 정리해야 했다. 자동 변환된 레이어 구조와 실제 디자인 작업 방식 사이에 간극이 있었기 때문이다.

결국 “이 상태로는 바로 쓰기 어렵다”는 디자이너의 피드백을 받게 됐고, 실제 작업에서는 기존처럼 직접 화면을 구성하는 방식이 더 자연스럽게 사용되는 경우가 많았다. 실제로도 신규 화면이 나올 때 간헐적으로 활용되는 정도에 머물렀고, 기존 workflow를 완전히 대체하는 수준까지 이어지지는 못했다.

돌이켜보면, 내가 가장 공들여 만들었던 “편집 가능한 레이어 변환” 기능이 실제로는 디자이너의 작업 시간을 크게 줄여주지 못했던 셈이다.

---

무엇이 잘못됐을까?

방치된 커맨드를 보면서 한참을 곱씹었다. 새로 넘길 화면도 당분간 없어서, 이 커맨드는 지금도 조용히 잠들어 있다.
그런데 계속 돌이켜보니 진짜 문제는 속도도, 익숙함도 아니었던 것 같다. 그 둘은 결과였을 뿐이고 원인은 훨씬 앞에 있었다.

나는 “무엇이 필요한지” 묻기 전에, “해결책”부터 만들어버렸다.

망치를 먼저 만들어 놓고 그다음에 박을 못을 찾으러 다닌 셈이었다. 디자이너가 실제로 어떤 형태의 결과물을 원하는지, 자동 변환된 레이어가 기존 작업 방식을 정말 자연스럽게 대체할 수 있는지를 만들기 전에 먼저 물어봤어야 했다.

더군다나 디자이너는 멀리 있는 사용자가 아니라, 이미 같은 화면을 함께 다듬고 있던 협업자였다. 그런데도 그 과정 없이 도구부터 만들다 보니, 기능은 잘 동작했지만 실제 workflow 안으로는 충분히 들어가지 못했다.

지금 다시 만든다면 순서를 완전히 반대로 갈 것 같다.

먼저 디자이너에게 무엇이 가장 번거로운지, 어떤 형태여야 실제로 수고가 줄어드는지를 물어보고, 가장 작은 형태로 하루치만 만들어 한 명에게 먼저 써보게 했을 것이다. 그리고 그때 “이거 진짜 편한데요?”라는 반응이 나왔을 때, 그 다음에야 자동화·정리·슬랙 알림 같은 기능들을 붙였을 것 같다.

결국 필요한 건 거대한 자동화보다, 먼저 검증하는 과정이었다.
나는 그 순서를 정확히 반대로 시작했던 셈이다.

---

그래도 남은 건 있다.

결과적으로는 기대했던 만큼 자리 잡지 못한 자동화였지만, 그렇다고 후회가 남는 작업은 아니다.
오히려 두 가지를 꽤 크게 얻었다.

하나는 기술적인 자산이다. 실행 중인 화면을 Figma 레이어로 변환하고, SPA의 렌더 시점을 기다렸다가 캡처하고, 결과를 카테고리별로 정리하는 흐름까지 — 이 과정에서 만든 것들은 다음에 비슷한 문제가 생겼을 때 다시 꺼내 활용할 수 있다.

그리고 다른 하나는, 어쩌면 너무 당연해서 잠시 놓치고 있었던 부분이었다.
AI와 MCP를 활용하면 머릿속 아이디어를 빠르게 형태로 만들 수 있다는 점에 꽤 몰입해 있었던 것 같다.

“이 정도면 분명 편해질 텐데?”라는 확신이 너무 앞서다 보니, 정작 가장 먼저 확인했어야 할 workflow와 사용성 검증을 뒤로 미뤄버렸다.

결국 이번 자동화 과정에서 부족했던 건 구현 능력보다도, 문제를 충분히 함께 정의하는 과정이었다.

다음번에는 자동화부터 만들기보다, 먼저 실제 사용하는 사람들에게 어떤 방식이 가장 불편한지, 무엇이 실제로 시간을 줄여주는지를 먼저 물어보게 될 것 같다.

그리고 가장 작은 형태로 빠르게 검증한 뒤, 정말 필요하다는 확신이 들 때 비로소 자동화를 붙여나갈 것이다.
어쩌면 좋은 자동화는 “많이 만든 것”보다, 정말 필요한 지점을 정확히 건드리는 것에 더 가까운지도 모르겠다.