디자이너가 Cursor로 UI 버그를 직접 고치기 시작했다 — 채널톡 '가드닝' 실전기
"폰트 사이즈를 조금만 키우고 싶은데, 다들 바쁘시네 .. 너무 사소한 이슈라 조금 죄송하기도 하고..."
이 글을 클릭한 디자이너라면 한 번쯤은 해봤을 생각이에요. 디자인 시스템을 아무리 잘 잡아도 실제 프로덕트에서는 크고 작은 UI 오류들이 쌓이거든요.
크리티컬한 버그는 당연히 개발자분들이 바로 잡아주죠. 근데 간격이 1px 어긋나거나, 컬러가 명세와 미묘하게 다르거나, 특정 상황에서만 텍스트가 잘리거나 하는 것들은요? 개발자에게 하나씩 전달하기엔 너무 사소하고, 그냥 두기엔 전반적인 제품 퀄리티가 떨어져 보이는 애매한 영역이에요. 티켓을 올리면 우선순위에 밀려 몇 달째 백로그에 쌓여 있기 일쑤였습니다. 디자이너는 계속 눈에 밟히고, 개발자는 기능 개발이 더 급한 상황. 사소한 버그들의 무덤이에요.
채널톡 프로덕트 디자이너 페이(배민주)가 이 문제를 AI로 직접 해결해봤어요.
시작은 아이콘 하나였다
온 세상에 AI 바람이 불기 시작하던 작년 여름 이야기예요.
당시 채널톡의 사내용 AI인 팀 ALF를 만들고 있던 페이는 수정 아이콘 하나를 바꾸고 싶었는데, 함께 일하는 스쿼드의 개발자들이 너무 바빴어요. 마침 개발자들이 Codex를 써보고 있던 참이었는데, 개발 리드가 직접 아이콘을 수정해보라며 Codex에 초대해 줬답니다.
냅다 해보겠다고 했어요. 정신없는 AI 시대 속에서 자기효능감을 얻기 위해 뭐라도 시작한 거죠.
비개발자에게 가장 큰 진입장벽은 Github 연동이에요. Codex에 Github 초대를 받아 연결하면 접속할 수 있는데, 회사 레포에 속해 있어야 하니까 꼭 사전 허가를 받아야 합니다.
연결을 완료하고 아주 광활한 프롬프트 창이 눈앞에 나타났을 때, 어떤 명령어를 넣어야 할지 머리가 하얘졌다고 해요.
그래서 Codex에게 설명했어요. 뭘? 나의 무지함을요. "나는 어떤 기능의 디자이너이고, 코딩을 잘 모른다"는 배경을 깔고, 원하는 수정사항을 컴포넌트 이름까지 넣어 최대한 상세히 썼어요.
처음엔 개인적으로 연습 삼아 PR을 여러 개 올려봤습니다. 잘 될 때도 있었고, 안 될 때도 있었죠.
첫 PR은 대참사였어요. 팀 ALF의 메시지 스트림을 수정해야 하는데, 채널톡 데스크의 전체 메시지 스트림을 건들인 거예요. 프론트 개발자분의 꼼꼼한 리뷰 아니었으면 큰일 날 뻔했습니다. (지금은 웃으며 쓰지만 당시엔 등줄기가 오싹했다고요.)
개발자분들의 조언을 얻어 정확한 위치를 추가해 다시 요청한 뒤에야 성공했어요. 바이브 코딩에서 프롬프트의 정확성이 얼마나 중요한지 뼈저리게 깨달은 계기였습니다.
Codex와의 UI 수정은 명확하지 못한 프롬프트로 인해 정확도가 떨어지고 시간도 오래 걸려서 업무 루틴으로 자리 잡지는 못했어요. "디자이너가 직접 코드를 수정하는 것에 한 걸음 다가섰다"는 의의만 남긴 채 프로젝트가 종료됐습니다.
'가드닝'이라고 부르기로 했다
이번에는 영역을 넓혀 디자인 팀 전체가 실험을 시작했어요. 전사적으로 Cursor를 사용하면서 공식적으로 디자인 팀에게 커서 계정과 깃헙 권한이 주어졌거든요.
이것을 '가드닝'이라고 부르고 지속해보기로 했어요. 시각적인 제품의 퀄리티를 책임져야 하는 디자이너인 만큼, 제품에 있는 잡초들을 뽑는 정원사가 되기로 한 겁니다. Cursor의 Agent 기능을 통해 디자이너가 직접 코드를 수정해서 PR을 올려보는 거예요.
5단계 워크플로우 — Kill Bug부터 머지까지
1단계: Kill Bug 트리아지. 채널톡은 엔지니어분들이 만든 킬버그(Kill Bug)라는 자동화 워크플로우를 쓰고 있어요. 제품 피드백이나 버그 제보가 들어오면 팀 채팅 스레드에 킬버그를 소환하면 Linear에 티켓이 자동 등록됩니다. 이슈가 흩어지지 않고 한 곳에 모이는 게 핵심이에요.
Linear 티켓에는 현재 상태 스크린샷, 기대 스펙(디자인 명세), 재현 조건을 꼼꼼히 적어둬요. 나중에 Cursor Agent에게 전달할 컨텍스트가 되거든요. 여러 번의 시행착오를 거치며 배운 건, AI에게 "이거 고쳐줘"라고 하는 것과 "이 컴포넌트의 width가 A인데 디자인 명세상으로는 B여야 해"라고 하는 건 결과가 완전히 다르다는 거예요.
2단계: Plan 모드로 계획 먼저 짜기. Cursor를 켜서 Plan 모드로 놓고 "이 버그를 어떻게 고칠지 계획을 짜줘"라고 먼저 요청합니다.
처음에는 이 단계를 건너뛰고 바로 Agent에게 수정을 요청했는데, 엉뚱한 파일을 건드리거나 한 군데 고치면 다른 데가 깨지는 경우가 생겼어요. 팀 리드에게 조언을 얻어 Plan 모드를 먼저 거치기 시작하니 한 번에 해결해주는 경우가 많아졌다고 합니다. Plan 모드에서는 수정할 컴포넌트 파일 위치, 스타일이 하드코딩인지 디자인 토큰인지, 변경이 다른 컴포넌트에 영향을 줄 수 있는지 등을 먼저 확인해요.
3단계: Linear 댓글로 Cursor Agent 호출. 채널 팀에서는 GitHub PR과 Linear 티켓이 연동되어 있어요. Linear 티켓 댓글에서 @Cursor를 멘션하면 Agent가 해당 티켓을 읽고 코드를 수정한 뒤 PR을 올려줍니다.
실제로는 이렇게 써요: ``` @cursor KnowledgeStatSection 컴포넌트의 헤더 영역 패딩이 명세와 다름. 현재: padding 16px 20px 개선: padding 12px 16px 관련 파일: KnowledgeStatSection.styled.ts 디자인 토큰 기준으로 수정해. ```
Agent가 관련 파일을 탐색하고 정확한 위치를 찾아서 수정 후 PR을 생성해줘요.
4단계: PR 확인. Agent가 올린 PR은 직접 확인해요. 코드를 완전히 이해하지는 못해도, 변경된 줄 수가 너무 많다거나 전혀 관계없어 보이는 파일이 포함되어 있다면 뭔가 잘못된 거잖아요. 변경 사항이 시각적으로 잘 반영되었는지, 변경 범위가 합리적인지 정도는 디자이너도 판단할 수 있어요.
5단계: 개발자 리뷰 및 머지. PR이 준비되면 해당 기능 담당 개발자에게 리뷰를 요청합니다. 채널 팀은 2명의 개발자 리뷰가 필수이고, 디자이너에게 머지 권한은 없어요. 한 번에 안 되거나 구조가 까다롭다면 개발자분들이 코멘트를 달아주고, 알려준 방법대로 다시 Cursor에게 시키면 됩니다. PR이 머지되면 Linear 티켓이 자동으로 Done 처리되고, 오랫동안 쌓여 있던 백로그가 하나씩 사라져요.
여기서 포인트가 하나 있어요. Cursor가 시킨 것을 잘 수행하지 못한다면 시간을 낭비하지 말고 바로 개발자에게 넘기거나 과감히 티켓을 포기하라는 거예요. 가드닝은 언제까지나 부가적인 업무니까요.
잡초가 사라지기 시작했다
디자인 팀원들이 가드닝으로 해결한 이슈들 중 일부예요. 큰 기능 변경 없이 순수하게 스타일과 레이아웃만 수정한 것들인데, 개발자에게 요청했다면 반 이상은 아직도 백로그에 잠들어 있었을 거예요.
이 경험에서 가장 크게 배운 건 기술적인 게 아니었다고 합니다. "코드를 몰라도 더 나은 사용자 경험을 위해 코드를 고칠 수 있다"는 것. AI가 코드를 써주고, 개발자가 최종 확인해 주니까, 디자이너는 그 사이에서 "어떤 문제가 있고 어떤 경험으로 개선해야 하는지"를 가장 잘 아는 사람으로서 역할을 하면 되는 거예요.
두 번째 배움은 더 실용적이에요. AI 덕분에 실행의 허들이 낮아진 만큼 일단 해보는 자세가 중요하다는 거예요. AI를 잘 쓰는 방법을 먼저 완벽히 공부하고 시작하려 했다면 아직도 시작 못 했을 거라고 하더라고요. "일단 이 문제를 해결해야겠다"는 욕심 하나로 시작했고, 그러다 보니 방법을 자연스럽게 익히게 됐다고요.
여러분 팀에도 몇 달째 백로그에 쌓인 UI 버그 티켓이 있나요? 첫 PR이 대참사여도 괜찮아요. 두 번째부터는 좀 나아지니까요.