라이너의 펜슬이 잘 굴러갈 팀은 AI 시안이 아니라 리뷰 단위를 먼저 정한 팀이에요

AI 로 디자인 시안을 뽑아주는 도구를 팀에 들이려 할 때 보통 묻는 질문은 "시안이 쓸 만하게 나오나"예요. 라이너의 재이가 쓴 펜슬 제작기를 읽고 나서 저는 그 질문이 두 번째라고 생각하게 됐습니다. 첫 번째 질문은 이거예요. AI 가 명세와 시안과 플로우를 한꺼번에 쏟아냈을 때, 그걸 한 판으로 펼쳐 놓고 정해진 시간 안에 판단할 사람과 기준이 우리 팀에 있나. 펜슬이라는 도구의 성패가 아니라, 이 글이 지나가듯 보여준 발견이 거기 있거든요.

라이너가 말하는 효과: 실험 루프의 병목을 디자인에서 뺀다

출발점은 개인의 AI 활용과 팀의 속도가 다르다는 관찰이에요. 각자 AI 로 자기 태스크를 빨리 끝내는데도 조직의 속도는 기대만큼 빨라지지 않았다는 거죠. 그래서 개발자 제롬과 함께 제품 개발 과정을 펼쳐 봤더니 지표·사용자 보이스에서 가설, 기획, 디자인, 개발, QA, 배포, 결과 확인, 레슨런, 다음 가설로 이어지는 고리가 나왔고, 그중 디자인의 핵심 시안 작업에서만 AI 활용이 유독 적었다는 게 라이너의 진단이에요. 병목이 여기라는 판단이 펜슬의 시작입니다.

펜슬은 별도 제품이 아니라 Skill 이에요. 막연한 가설이나 아이디어를 받아서 대상 사용자, 비교 대상, 성공과 실패를 가를 지표, 통제할 케이스를 하나씩 짚으며 실행 가능한 실험 설계로 다듬고(글에서는 이걸 '샤프닝'이라고 부릅니다), 그다음 UX 를 여러 방향으로 탐색해 HTML 와이어프레임으로 비교한 뒤, 명세·시안·플로우가 연결된 피그마 프로젝트 하나를 만들어 줘요.

시안 하나를 만드는 AI 가 아니라 프로젝트 한 판을 만드는 AI 라는 표현이 글 전체를 관통하고요. 클로드 디자인이나 피그마 메이크 같은 서비스도 살펴봤는데 UI 퀄리티는 좋아졌지만 시안을 만드는 데서 멈추더라는 게 직접 만든 이유로 나옵니다.

이 한 판이 세 겹으로 되어 있다는 점이 중요해요. 무엇을 만들고 어떤 케이스를 고려해야 하는지는 명세로, 그 기획을 실제 UX 와 화면으로 구체화한 결과는 시안으로, 화면과 상태가 어떻게 연결되고 사용자가 어떤 경로로 지나가는지는 플로우로 정리되는데, 셋이 따로 만들어지는 게 아니라 앞에서 샤프닝한 하나의 기획에서 갈라져 나옵니다. 리뷰하는 입장에서 이건 명세를 읽다가 시안을 보고, 시안을 보다가 플로우로 넘어가도 같은 가정 위에 있다는 뜻이에요. 화면 몇 장을 받는 것과 근본적으로 다른 지점이 여기고요.

피그마가 살아남은 이유가 이 글의 진짜 내용이에요

제가 이 글에서 제일 오래 붙들고 읽은 대목은 펜슬의 기능 설명이 아니라, 피그마를 없애려다 실패한 과정이에요. 디자인 시스템만 잘 갖춰져 있으면 AI 가 코드 레벨에서 90% 를 만들고 사람이 10% 를 다듬는 편이 낫다고 꽤 강하게 생각했다는 고백으로 시작합니다. 그런데 막상 피그마 없이 가려니 화면을 하나씩 브라우저에서 열어 보는 방식으로는 전체를 판단할 수 없었고, 화면과 화면 사이의 관계가 보이지 않았고, AI 가 만드는 양이 늘수록 여러 직무의 사람이 그걸 리뷰할 방법이 없었다는 거예요. 테스트용 프로토타입을 코드로 만들던 본인조차 로컬 웹을 띄워 놓고 수치를 바꿔 가며 디자인하고 있었다는 장면이 이 대목에 있습니다.

그러니까 병목이 옮겨간 거예요. AI 가 만들기 시작하면 만드는 시간은 줄어드는데, 만들어진 것을 보고 판단하는 시간은 그대로이거나 오히려 늘어요. 라이너가 결국 필요하다고 결론 낸 것은 새 디자인 툴이 아니라 "AI 가 만들어낸 결과를 사람이 한 판에 펼쳐 놓고 리뷰할 수 있는 프로젝트 구조"였고, 그 구조는 이미 피그마에 있었죠. 피그마가 좋은 디자인 툴이어서가 아니라 좋은 문서 툴이어서 살아남았다는 겁니다.

글 안에도 같은 문장이 있어요. "AI가 만드는 속도가 빨라질수록, 사람이 모든 과정을 직접 만드는 것이 아니라 중요한 부분을 빠르게 확인하고 판단하는 것이 더 중요해진다고 생각했습니다." 저는 이 문장이 펜슬의 기능 목록보다 훨씬 중요한 결론이라고 봅니다. 확인하고 판단하는 일이 중요해졌다는 건, 그 일을 할 사람과 시간과 기준이 새로 필요해졌다는 말이니까요.

저는 이게 이 도구의 효용을 판단하는 기준이 된다고 봐요. 펜슬이 만드는 단위가 화면이 아니라 프로젝트인 건 AI 가 똑똑해서가 아니라, 리뷰하는 사람이 프로젝트 단위로만 판단할 수 있기 때문이거든요. 도구의 출력 단위는 리뷰어의 판단 단위에 맞춰지는 거고, 그 단위를 정해 두지 않은 팀에서는 아무리 좋은 시안이 나와도 쌓이기만 합니다.

리뷰에 드는 시간은 글에 없어요. 만드는 쪽 이야기는 자세한데, 그 한 판을 보고 버릴 것과 남길 것을 가르는 데 사람이 얼마나 쓰는지는 숫자로 나오지 않습니다. 이 도구의 진짜 비용은 아마 거기 있을 거고, 그건 라이너가 아니라 도입하는 팀이 직접 재야 하는 숫자예요.

실제로 작동하는 조건

성공담에는 늘 생략된 조건이 있는데, 이 글은 비교적 정직하게 적어 놨어요. 기능 구현 화면이나 일반적인 프로덕트 UI, 그러니까 이미 많은 서비스에서 반복돼 패턴화된 UI 를 만들고 그 안에서 상태와 케이스를 구성하는 일에는 꽤 강하고, 랜딩 페이지처럼 브랜드의 미감이나 독창적인 비주얼이 중요한 지면에서는 아직 상당히 약하다는 게 글의 자체 평가예요. 복잡하거나 기존 패턴을 벗어나는 프로젝트에서는 사람이 더 다듬어야 하고, 플로우를 연결하거나 여러 상태를 일관되게 구성하는 데도 어색한 부분이 남아 있다고요.

이 조건을 뒤집어 읽으면 전제가 하나 나와요. 디자인 시스템이 이미 있고, 그게 AI 가 읽을 수 있는 형태로 존재해야 한다는 것. "디자인 시스템이 잘 갖춰져 있다면"이라는 가정이 글의 첫 실험부터 깔려 있었잖아요. 시스템이 피그마 라이브러리로만 있고 코드 컴포넌트와 어긋나 있는 팀이라면, 펜슬 같은 도구는 패턴화된 UI 조차 우리 제품처럼 안 그려 줄 겁니다.

만든 사람의 구성도 조건이에요. 재이와 개발자 제롬 두 사람이 결과물을 하나씩 체크하며 만들었고, 사내 해커톤에서 2등을 했고, 지금은 베타에 가까운 상태로 사내에서 자유롭게 쓰이는 중입니다. 일부 PE(Product Engineer) 가 펜슬로 먼저 디자인한 뒤 거기서 결정된 UX 로 개발을 진행한다는 게 실제 사용 장면이고요. 이건 성공 사례라기보다 아직 진행 중인 실험이고, 글도 완전한 루프는 아니라고 스스로 말합니다. 그 정직함이 이 글을 믿게 만드는 부분이기도 하죠.

루프의 어디까지를 도구가 덮고 있는지도 봐야 해요. 라이너가 그리는 그림은 지표와 사용자 인터뷰에서 신호를 발견하고, 가설을 세우고, 기획과 디자인으로 구체화하고, 개발해 내보내고, 결과를 확인해 레슨런을 얻고, 그게 다음 가설로 이어지는 루프예요. 그런데 지금 펜슬이 실제로 하는 일은 그 앞쪽 절반, 가설에서 피그마 프로젝트까지입니다. 배포 뒤의 결과를 읽고 레슨런을 다시 한 판에 써 넣는 뒤쪽 절반은 아직 사람 손이고, 글도 완전한 루프는 아니라고 적어 두었죠. 도입하는 팀은 이 도구가 루프를 만들어 준다고 기대하기보다, 루프의 앞 절반을 빠르게 하는 대신 뒤 절반의 부담이 늘어난다고 계산하는 편이 정확할 겁니다.

작은 사용법에도 눈이 갔어요. 프로젝트를 시작할 때 한 판을 만드는 것 말고도 작업 중간에 "네비게이션 일괄 교체해줘", "코드 기반으로 디자인을 최신 버전으로 바꿔줘", "토큰 적용해줘" 같은 세세한 수정을 펜슬로 처리한다고 나옵니다. 저는 이쪽이 오히려 오래 남을 가치라고 봐요. 코드가 앞서가고 피그마가 뒤처지는 건 디자인 시스템을 운영하는 팀이라면 다 겪는 만성 질환인데, 코드 기준으로 피그마를 따라오게 만드는 명령이 된다면 생성보다 동기화가 이 스킬의 본업이 될 수도 있거든요.

도입한다면 어디서부터, 무엇을 조심해서

첫 적용 범위는 글이 강하다고 인정한 곳으로 좁히는 게 맞아요. 패턴화된 기능 화면, 상태와 케이스가 많은 설정·목록·폼 류. 브랜드가 드러나는 지면은 처음부터 빼고요. 그리고 도구를 붙이기 전에 리뷰 쪽을 먼저 정해야 합니다. 한 판이 나오면 누가 보는지, 얼마 만에 보는지, 무엇을 기준으로 버리는지. 라이너에서는 디자이너가 정리된 피그마로 리뷰하고 PE 가 여러 UX 시안을 살펴보는 흐름이 자리 잡았는데, 그 흐름이 없는 팀에서는 한 판이 그냥 큰 파일로 남습니다. 측정도 미리 정해 두는 편이 좋아요. 글이 목표로 삼는 건 한 사이클의 길이니까, 시안이 예쁜지가 아니라 가설에서 배포까지 걸린 날짜와 한 판에서 버려진 시안의 비율을 재면 됩니다.

버리는 지점도 앞으로 당기는 게 좋아요. 펜슬은 기획이 잡히면 UX 를 여러 방향으로 탐색해 HTML 와이어프레임으로 먼저 비교하게 하는데, 리뷰어 입장에서는 여기가 가장 싼 폐기 지점이에요. 와이어프레임 단계에서 방향을 하나로 줄여 두면 뒤에 나오는 명세·시안·플로우 한 판이 그만큼 가벼워지고, 반대로 여기서 판단을 미루면 한 판이 세 방향치로 불어나 리뷰 시간이 그대로 세 배가 됩니다.

아이디어가 어디서 오는지에 대한 관찰도 도입 순서에 쓸 만해요. 정식으로 기획이 시작되는 순간보다 슬랙에서 누군가 툭 던진 한마디에서 프로젝트가 시작되는 경우가 훨씬 많다는 것, "이거 한번 바꿔보면 어때요?", "이 지표 이상한데요?", "이거 유저들이 불편해하지 않을까요?" 같은 말들이 흩어져 있다가 시간이 지나 프로젝트가 된다는 것. 그래서 슬랙 스레드에서 펜슬을 태그하면 그 자리에서 한 판을 만들어 주는 시도를 하고 있고요. 저는 이 시도가 편리한 만큼 조심스럽다고 봐요. 다음 문단의 이유 때문에요.

조심할 것도 하나 있어요. 글은 가설 도출, 기획, 코딩, QA 가 이미 AI 가 잘 하거나 잘 할 것으로 보이는 영역이라고 전제하는데, 저는 가설 도출까지 같은 줄에 놓는 건 동의가 안 됩니다. 코딩과 QA 는 결과를 검증할 수 있지만, 가설은 누가 세웠느냐가 곧 레슨런의 주인이 누구냐를 정하거든요. 지표에서 신호를 찾고 가설을 만드는 일까지 에이전트에게 넘기면 루프는 빨라져도 팀이 배우는 건 줄어들 수 있어요. 샤프닝 단계에서 대상 사용자와 지표를 짚는 질문에 사람이 먼저 답을 써 보고, 그 뒤에 펜슬을 돌리는 순서를 규칙으로 두는 편이 낫다고 봅니다. 슬랙에서 툭 던진 한마디가 곧바로 한 판이 되는 편의가, 가설을 세우는 사람을 없애는 방향으로 가지 않게요.

펜슬은 "AI 가 디자인을 대신한다"의 사례가 아니라 "AI 가 만들면 병목은 리뷰로 옮겨간다"의 사례예요. 디자인 시스템이 코드로 존재하고, 한 판을 정해진 시간 안에 판단할 리뷰어와 기준이 있는 팀이라면 이 도구는 실험 루프를 실제로 짧게 만들 겁니다. 둘 중 하나가 없는 팀이라면, 먼저 만들어야 할 건 스킬이 아니라 리뷰 단위예요.