핸드오프는 PR이다

오랫동안 내 일은 Figma 파일에서 끝났다. redline을 그리고, Dev Mode 링크를 붙이고, 티켓을 쓰고 나면 몇 주 뒤에 비슷하지만 조금씩 다른 빌드가 돌아왔다. 지금은 머지된 PR에서 끝난다. VS Code에서 GitHub Copilot으로 코드베이스를 고치고, 브랜치를 push하고, PR도 직접 올린다. QA는 변경이 develop에 들어간 뒤 SIT에서 만난다.

이 글의 첫 버전은 업계 조사에 기대다 보니 Figma가 실제보다 훨씬 중요해 보였다. 이번 버전은 내가 실제로 일하는 방식이다. 내가 만지는 브랜치, 치는 명령어, QA가 변경을 받아 가는 방법, 개발자와 같은 코드에서 부딪혔을 때 생기는 일. 업계 맥락은 맨 끝에 짧게 남겼다. 우리 팀만 이렇게 일하는 게 아니라는 걸 아는 것도 도움이 되기 때문이다.

화면 하나가 아이디어에서 출시까지 가는 길이다.

사라진 건 파일을 코드로 옮기기 위해서만 있던 것들이다. redline, 스펙 메모, "빌드가 시안과 다르다"는 티켓, 회차 사이의 기다림. Figma에서 모든 상태를 다듬던 일도 없어졌다. 이제 상태는 코드에서 한 번만 다듬는다.

우리는 Git Flow 구조를 쓴다. 유행하는 방식은 아니다. git-flow를 만든 Vincent Driessen도 2020년에 지속 배포를 하는 팀이라면 더 단순한 방식을 쓰라고 했고, Atlassian은 지금 이걸 legacy 워크플로라고 부른다. 그래도 SIT와 UAT 단계가 있는 제품에는 잘 맞는다. 오래 유지되는 브랜치 하나가 환경 하나에 대응하기 때문이다.

브랜치와 환경

내가 만드는 브랜치는 feature/*뿐이다. 릴리스 브랜치와 main 머지는 개발자 몫이다. 머지는 merge commit으로 해서, 히스토리에 브랜치가 하나하나 남는다.

QA가 SIT 상황을 아는 방법

푸터에 빌드 해시를 띄우지는 않는다. 배포 알림과 팀 채널로 안다. develop에 무언가 머지되어 배포되면 QA는 거기서 소식을 듣는다. 테스트 중에 나온 수정은 별도 브랜치로 따로 올린다. Git Flow에서는 릴리스 브랜치가 생긴 뒤 그 릴리스의 버그는 릴리스 브랜치에서 고치고 develop에도 다시 반영한다. 그 전이라면 다른 변경처럼 develop으로 들어간다. 어느 쪽으로 갈지는 릴리스가 어디까지 왔느냐에 달렸다.

평소 변경 하나가 어떻게 흘러가는지, 실제로 치는 명령어와 함께 적었다. 수정은 대부분 Copilot이 하지만, Git은 여전히 내 몫이다.

명령어보다 중요한 습관이 두 가지 있다. 리뷰어가 충돌을 발견하기 전에, PR을 올리기 전에 develop과 맞춰 둔다. 그리고 PR은 화면 하나, 수정 하나로 작게 유지한다. 그래야 리뷰어가 실제로 읽을 수 있다.

develop과 맞출 때는 develop을 내 브랜치에 merge한다(git merge origin/develop). rebase는 히스토리를 다시 쓰고 force push가 필요해서, 아무도 pull하지 않은 내 브랜치에서만 쓴다. 알아 두면 좋은 함정이 하나 있다. rebase 중에는 충돌 편집기의 "ours"와 "theirs"가 생각과 반대로 표시된다.

repo가 알려 주지 않으면 Copilot은 우리 디자인 시스템을 모른다. 그래서 .github/copilot-instructions.md가 있다. 특정 폴더에만 적용되는 .instructions.md 파일도 둘 수 있다. agent mode는 요청마다 이 파일들을 읽고, 2025년 8월부터는 Copilot 코드 리뷰도 같은 파일을 읽는다. 변경을 이끄는 규칙이 곧 그 변경을 리뷰하는 기준이 된다.

UI 작업에서 가장 중요한 규칙은 지루할 만큼 구체적이다. 새로 만들기 전에 기존 컴포넌트를 쓴다. hex 값이나 픽셀 간격 대신 토큰을 쓴다. 로딩, 빈 화면, 에러 상태를 빠뜨리지 않는다. 공유 비즈니스 로직을 건드리면 PR에 분명히 적는다. 다른 브랜치에서 누군가 이미 고치고 있는 코드라면 손대기 전에 알려 준다.

Figma의 역할은 작아졌다

아이데이션, 그리고 가끔 기존의 디테일한 컴포넌트를 Figma MCP로 불러오는 일이다. 그러면 Copilot이 추측하지 않고 실제 스펙을 보고 만든다. 설정은 VS Code의 MCP 설정에 Figma 원격 서버 항목 하나를 추가하면 끝이다. 2026년 10월 기준으로 Figma는 이 서버를 아직 beta로 두고 있고, 엔터프라이즈 조직이라면 관리자가 먼저 Copilot에서 MCP 서버를 허용해 줘야 한다.

아무도 잘 적지 않지만, 실제로 꼬이는 건 이 부분이다.

실제 사례

페이먼트 작업을 할 때, 결제 내역 페이지와 지급 승인 화면이 같은 로직을 공유하고 있었다. 나는 한쪽 화면의 문제를 고치고 있었고, 개발자는 다른 쪽 화면 때문에 같은 로직을 고치고 있었다. 각자의 수정은 그 자체로는 문제가 없었다. 그런데 둘이 합쳐지자 부딪혔다. 공유 로직이라서, 한 화면을 고치면 다른 화면의 동작이 조용히 바뀔 수 있었다.

충돌에는 세 종류가 있고, 그중 눈에 띄는 건 하나뿐이다.

페이먼트 사례는 세 번째로 시작했고, 자칫하면 두 번째 상태로 출시될 뻔했다.

내가 실제로 하는 방법

충돌을 푸는 게 아니라 미리 막는다. instructions 파일 중 하나에, 내가 고치려는 코드가 다른 브랜치에서 이미 작업 중이면 Copilot 에이전트가 코드를 쓰기 전에 먼저 경고하라고 적어 두었다. 경고가 뜨면 그 부분을 누가 맡을지 정한다. 개발자가 맡으면 나는 그 부분에 손대지 않는다. 개발자가 작업을 끝내고 develop에 머지하면, 내가 pull을 받고 나서 그 부분과 연결된 작업을 시작한다. 두 변경이 같은 시간에 겹치지 않으니 충돌 편집기를 열 일도 없다.

우리는 CODEOWNERS를 쓰지 않아서, 이런 경계를 repo가 강제하지는 않는다. 그 역할은 경고와 그 뒤에 나누는 짧은 대화가 한다. 그리고 모든 PR은 머지 전에 여전히 두 명의 승인이 필요하다.

예전에 QA는 빌드를 Figma와 비교하는 데 시간을 많이 썼다. 간격이 몇 픽셀 어긋났다, 회색이 다르다, hover 상태가 빠졌다. 이런 버그는 같은 화면을 두 번 만들었기 때문에 생겼다. 한 번은 Figma에서, 한 번은 코드로. 디자이너가 UI를 직접 쓰면 이 종류의 버그는 대부분 사라진다.

그래서 QA의 프로세스는 짧아졌고, 범위는 넓어졌다. 변경이 develop에 들어가면 SIT에서 받아, 나와 에이전트가 약한 부분에 시간을 쓴다. 기능 엣지 케이스, SIT의 실제 데이터와 연동, 같은 로직을 쓰는 다른 화면의 회귀, 접근성, 기기별 동작. 위의 페이먼트 사례가 바로 지금의 QA가 잡기 좋은 버그다.

루프

디자이너가 UI를 쓰면 QA가 어떻게 바뀌는지 수치로 공개한 곳은 없다. World Quality Report 2025-26은 테스터의 시간이 테스트 스크립트 작성에서 리스크 분석과 테스트 전략으로 옮겨 간다고 정리하는데, 내가 보는 것과 같은 방향이다. 다만 이 부분은 측정이 아니라 관찰이다.

내가 하지 않는 일이 있다. 릴리스나 핫픽스 브랜치를 만들지 않고, main에 머지하지 않고, 개발자와 먼저 합의하지 않은 채 공유 비즈니스 로직을 바꾸지 않는다. 새 컴포넌트는 개발자를 거친다. Copilot 리뷰는 1차 검토일 뿐, 승인이 아니다.

이렇게 일하는 게 나만은 아니다. 한국 애드테크 회사 버즈빌은 2026년 9월에 디자이너 PR 6개월치를 공개했다. 432건이었고, 디자인팀 참여율은 17%에서 100%가 됐고, 들여다볼 핸드오프가 남지 않아 Figma Dev Mode 좌석은 23개에서 3~4개로 줄었다. Figma의 2026 AI 리포트에 따르면 개발 업무를 하는 디자이너는 1년 사이 21%에서 41%로 두 배가 됐다. 하지만 공개된 사례는 거의 모두 PR마다 preview로 테스트하는 스타트업 이야기이고, 대부분 Claude 계열 도구를 쓴다. 공용 SIT와 UAT 단계를 거치고 QA가 루프 안에 있는 Copilot 워크플로는 기록된 곳이 거의 없다.

다른 디자이너에게 하고 싶은 말

어려운 건 Git이 아니다. 판단 세 가지가 어렵다. 이 브랜치를 rebase해도 되는가, 아니면 누가 이미 pull했는가. 이 충돌은 내가 풀어도 되는가, 아니면 로직의 문제인가. 지금 SIT에 올라간 게 정말 내 변경인가. 예전에는 디자인 파일이 디자인 결정을 담았다. 지금은 PR이 담고, 그 PR이 머지되는 코드가 담는다.