제품 개발 이후, 그 바깥의 AI - 버그 잡는 디자이너

안녕하세요. 채널톡 프로덕트 디자이너 페이입니다.

모든 제품 조직에서 생기는 회색지대를 비개발자인 프로덕트 디자이너가 AI로 해결해본 여정을 자세히 소개해보려 합니다.

문제 정의: 사소한 버그들의 무덤

"폰트 사이즈를 조금만 키우고 싶은데, 다들 바쁘시네 .. 너무 사소한 이슈라 조금 죄송하기도 하고... 어쩌지?"

이 글을 클릭하신 디자이너분들, 모두 이런 생각해보신 적 있으시죠?

디자인 시스템을 아무리 잘 잡아도 실제 프로덕트에서는 크고 작은 UI 오류들이 쌓이기 마련입니다.

크리티컬한 버그는 당연히 개발자분들이 바로 잡아주십니다. 하지만 간격이 1px 어긋나거나, 컬러가 명세와 미묘하게 다르거나, 특정 상황에서만 텍스트가 잘리거나... 이 모든 것들은 개발자에게 하나씩 전달하기엔 너무 사소하고, 그렇다고 그냥 두기엔 전반적인 제품 퀄리티가 떨어져 보이는 이슈들이에요.

이런 이슈들은 티켓을 올리면 우선순위에 밀려 몇 달째 백로그에 쌓여 있기 일쑤였어요. 디자이너 입장에서는 계속 눈에 밟히고, 개발자 입장에서는 기능 개발이 더 급한 상황. 모두 공감하실거라 생각합니다.

일단 해보기 #1. 시작은 아이콘 하나였어요

온 세상에 AI 바람이 불기 시작하던 작년 여름으로 거슬러 올라가보았습니다.

당시 채널톡의 사내용 AI인 팀 ALF를 만들고 있던 저는 수정 아이콘 하나를 바꾸고 싶었는데, 함께 일하는 스쿼드의 개발자들이 너무 바쁜 상황이었어요. 마침 개발자들이 Codex를 써보고 있던 참이었는데, 개발 리드가 저한테 직접 아이콘을 수정해보라며 Codex에 초대해 주셨어요.

좋은 기회라는 생각에 냅다 해보겠다고 했습니다. 정신없는 AI 시대 속에서 자기효능감을 얻기 위해 뭐라도 시작한 거죠.

사실 비개발자들에게 가장 큰 진입장벽은 Github 연동일 것이라고 생각해요. 저 또한 그랬답니다. 그래서 헤매는 시간을 줄이기 위해 매뉴얼을 보고 직접 따라하기보단, 개발자분들의 적극적인 도움을 받았어요. Codex에 Github 초대를 받아 연결하면 쉽게 접속할 수 있습니다. (이때 회사 레포에 속해 있어야 하니 꼭 사전 허가를 받아야 합니다.)

연결을 완료한 뒤 아주 광활한 프롬프트 창이 눈앞에 나타났고, 어떤 명령어를 넣어야 할지 머리가 하얘지는 기분이었어요.

그래서 Codex에게 설명했습니다! 무엇을? 나의 무지함을요.

나는 어떤 기능의 디자이너이고, 코딩을 잘 모른다는 배경을 설명하고 시작했어요. 그리고 원하는 수정사항을 설명할때, 컴포넌트 이름을 넣어 최대한 상세히 쓰려고 노력했습니다. 그러자 Codex가 열심히 돌아가기 시작했어요.

처음엔 개인적으로 연습 삼아 Codex로 PR을 여러 개 올려봤습니다. 사실 프롬프트를 어떻게 잘 쓰는지에 대한 관심보다, 이 문제를 일단 해결해야겠다는 욕심이 더 컸던 것 같아요. 그러니 당연히 잘 될 때도 있었고, 안 될 때도 있었죠.

처음으로 Codex가 뱉어낸 PR은 대참사. 프론트 개발자분의 꼼꼼한 리뷰 아니었으면 큰일 날 뻔 했습니다. (팀 ALF의 메시지 스트림을 수정해야 하는데, 채널톡 데스크의 전체 메시지 스트림을 건들인 거예요.) 지금은 웃으며 쓰지만(?) 당시엔 정말 등줄기가 오싹했답니다.

이후 개발자 분들의 조언을 얻어 정확한 위치를 추가해 다시 요청한 뒤에야 성공했습니다. 바이브 코딩에서 프롬프트의 중요성을 다시 한 번 깨달았던 계기였어요.

이렇게 Codex와 함께한 UI 수정은 명확하지 못한 프롬프트로 인해 정확도가 떨어지고, 해결까지 꽤 오랜 시간이 걸렸던 문제로 업무 루틴으로 자리 잡지는 못했어요.

디자이너가 직접 코드를 수정하는 것에 한 걸음 다가섰다는 의의를 얻은 채 사내에서 본격적으로 Cursor를 쓰게 되며 저만의 작은 프로젝트가 종료되었습니다.

이제 이것을 가드닝이라고 부르자

그리고 이번에는 영역을 넓혀 디자인 팀 전체가 실험을 시작했습니다. 전사적으로 Cursor를 사용하면서 공식적으로 디자인 팀이 접근할 수 있도록 커서 계정과 깃헙 권한도 받았어요.

저희는 이것을 가드닝 이라고 부르고 지속해보기로 했습니다. 시각적인 제품의 퀄리티를 책임져야 하는 디자이너인 만큼, 제품에 있는 잡초들을 뽑는 정원사가 되기로 한 것입니다.

Cursor의 Agent 기능을 통해 디자이너가 직접 코드를 수정해서 PR을 올려보는 거예요!

일단 해보기 #2. Cursor로 Linear 티켓과 연동해요

[1단계: Kill Bug 트리아지 — Linear에 티켓 등록하기]

채널톡은 엔지니어 분들이 만들어주신 킬버그(Kill Bug)라는 자동화 워크플로우 도구를 사용하고 있습니다. 제품 피드백이나 버그 제보가 들어오면, 팀 채팅 스레드에 킬버그를 소환하면 돼요. 그러면 이슈 관리 툴인 Linear에 티켓이 자동 등록됩니다. 이슈가 흩어지지 않고 한 곳에 모이는 게 핵심이에요.

Linear 티켓에는 현재 상태 스크린샷, 기대 스펙 (디자인 명세), 재현 조건 (특정 해상도에서만 발생하는지, 특정 데이터일 때만 발생하는지 등)을 꼼꼼히 적어둡니다. 나중에 Cursor Agent에게 전달할 컨텍스트가 되거든요.

여러 번의 시행착오를 거치며 배운 점은, 티켓에 요구사항을 잘 써두는 것이 중요하다는 거예요. AI에게 "이거 고쳐줘"라고 하는 것과, "이 컴포넌트의 width가 A인데, 디자인 명세 상으로는 B여야 해." 라고 하는 건 결과가 완전히 달랐기 때문입니다.

[2단계: Plan 모드로 계획 먼저 짜기]

그다음, Cursor를 켜서 Plan 모드로 놓고 계획을 짭니다. "이 버그를 어떻게 고칠지 계획을 짜줘"라고 먼저 요청하는 거예요.

처음에는 이 단계를 건너뛰고 바로 Agent에게 수정을 요청했는데, 그러면 엉뚱한 파일을 건드리거나, 한 군데 고치면 다른 데가 깨지는 경우가 생겼습니다.

그래서 팀 리드에게 조언을 얻어 Plan 모드로 계획을 짠 후 실행해보았는데, 한 번에 해결해주는 경우가 많아졌어요. 그래서 그 후부터는 작은 단위의 이슈라도 꼭 Plan 모드로 먼저 계획을 짠 후에 그 계획을 @Cursor 에게 시킵니다.

(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을 생성해줘요. 리니어에 PR이 엮여서 올라가기 때문에 이슈 트랙킹을 할 수 있는 장점도 있습니다.

[4단계: PR 확인하기]

Agent가 올린 PR은 직접 확인합니다. 코드를 완전히 이해하지는 못해도, 변경된 줄 수가 너무 많다거나 전혀 관계없어 보이는 파일이 포함되어 있다면 뭔가 잘못된 거예요. 그럴 때는 다시 Agent에게 "이 파일은 왜 수정됐어?"라고 물어보면 됩니다.

(변경 사항들이 시각적으로 잘 반영되었는지, 변경 범위가 합리적인지 정도는 디자이너도 판단할 수 있어요!)

[5단계: 개발자 리뷰 및 머지하기]

PR이 준비되면 해당 기능을 담당하시는 개발자에게 리뷰를 요청합니다. 저희는 2명의 개발자의 리뷰를 무조건 받아야 하고, 디자이너들에게 머지 권한은 없기 때문에 이 단계가 중요해요.

한 번에 잘 안 되거나 구조가 까다롭다면, 개발자분들이 달려와서 코멘트를 달아주십니다. 그리고 알려주신 방법대로 다시 Cursor에게 시켜요. 이렇게 리뷰를 받아 PR이 머지되면 Linear 티켓이 자동으로 Done 처리되고, 오랫동안 쌓여 있던 백로그가 하나씩 사라집니다.

이때 포인트는 Cursor가 시킨 것을 잘 수행하지 못한다면, 시간을 낭비하지 말고 바로 개발자에게 넘기거나 과감히 티켓을 포기해요. 가드닝은 언제까지나 부가적인 업무니까요!

실제 결과

첨부한 스크린샷은 디자인 팀원들이 가드닝으로 해결한 이슈들 중 일부인데요, 큰 기능 변경 없이 순수하게 스타일과 레이아웃만 수정한 것들입니다. 아마 개발자에게 요청했다면 우선순위에 밀려 반 이상은 아직도 백로그에 잠들어 있었을 거라고 생각해요.

이렇게 채널 디자인팀은 제품 백로그, 즉 잡초들이 하나씩 사라질 수 있는 환경을 구축하고 있답니다.

마무리

이 경험에서 가장 크게 배운 건 기술적인 것이 아니라, “코드를 몰라도 더 나은 사용자 경험을 위해 코드를 고칠 수 있다"는 것입니다.

AI가 코드를 써주고, 개발자가 최종 확인해 주시기 때문에,

디자이너는 그 사이에서 "어떤 문제가 있고, 어떤 경험으로 개선해야 하는지"를 가장 잘 아는 사람으로서의 역할을 해야 한다고 생각해요.

그리고 두번째로 배운 것은 AI 덕분에 실행의 허들이 낮아진 만큼, 일단 해보는 자세가 중요하다는 겁니다. 아마 AI를 잘 쓰는 방법을 먼저 완벽히 공부하고 시작하려 했다면, 아직도 시작 못 했을 것 같아요. 저는 "일단 이 문제를 해결해야겠다"는 욕심 하나로 시작했고, 그러다 보니 자연스럽게 방법을 익히게 됐어요.

혹시 여러분 팀에도 몇 달째 백로그에 쌓인 UI 버그 티켓이 있으신가요? 생각보다 어렵지 않으니 한 번 도전해 보세요!