AI는 우리 제품을 모릅니다
냉정히 제품의 상황을 봤을 때, 우리와 동일한 인력으로 AI를 제대로 활용해 디자인과 개발을 한다면 누군가 Joint를 따라잡는 데 걸리는 시간은 넉넉잡아 두 달. 아니, 어쩌면 한 달일지도 모르겠다는 결론이 나왔습니다.
디자이너 한 명이 일주일 안에 랜딩 페이지를 완성하고, PRD 수십 건을 일주일 단위로 갱신할 수 있는 시대입니다. 그 속도라면 Joint 제품의 표면을 한두 달 안에 복제하는 건, 누군가에게는 충분히 가능한 일입니다. 동료들과 밤낮없이 달리고 고객사분들과 함께 키워온 애정이 담긴 제품이, 누군가에겐 "두 달이면 만들겠는데?" 같은 쉬운 먹잇감으로 보이는 게 지금의 현실일지도 모른다는 생각이 머릿속을 떠나지 않았습니다.
가만히 앉아 시대의 흐름을 원망하거나 뒤늦게 따라가는 대신, 저희 나름의 답을 먼저 찾아야 했습니다. 그리고 그 답은 의외로 단순한 질문에서 시작됐습니다.
"AI에게 우리 제품을 제대로 알려준 적이 있었던가?"
그리고 이건 Joint만의 이야기가 아닙니다
지금도 "AI로 일하는 건 아직 낯설다", "우리 회사는 상황이 좀 다르다", "조금 더 지켜본 뒤에 천천히 도입해야지"라고 생각하시는 분이 계실 겁니다. 충분히 이해합니다. 불과 두 달 전까지만 해도 저 역시 그중 한 명이었으니까요.
하지만 시장의 한편에서는 이미 일하는 방식 자체가 완전히 바뀌었습니다. AI에게 PRD 한 줄 써달라고 물어보고 결과물에 감탄하는 수준이 아닙니다. 디자이너가 개발 저장소에서 공용 컴포넌트를 하루 만에 완성하고, 엔지니어는 그 위에 API만 얹으면 제품이 돌아가는 방식으로요. 기획, 디자인, 구현이 분리된 릴레이가 아니라 AI를 경유해 하나로 묶이는 방식으로 바뀌었습니다.
이 글은 그 방식을 1년도 안 된 신생 팀이 어떻게 도입했는지에 대한 기록입니다. 읽으시면서 한 가지만 생각해주시면 좋겠습니다. 지금 우리 팀은 이 중 어디쯤 와 있는가. 그리고 지금 나의 속도와 시장의 속도 사이에는 얼마만큼의 거리가 있는가.
문제는 AI의 한계가 아니었습니다
이미 많이들 경험해보셨겠지만, 컨텍스트 없는 AI는 방향을 잃습니다.
Claude나 GPT에게 "AI Chat 기능 PRD 써줘"라고 요청하면 그럴듯한 문서가 금방 나옵니다. 목적, 배경, 사용자 스토리, 기능 목록, 엣지 케이스까지 분량도 충분하고 형식도 깔끔하죠.
하지만 막상 읽어보면 어딘가 비어 있다는 느낌이 듭니다. 이게 실제로 쓸 수 있는 내용인가 싶어요. 우리 팀이 올해 집중하기로 한 방향과 어긋나거나, 고객이 실제로 호소했던 불편과 동떨어져 있거나, 이미 존재하는 기능과 충돌하는 스펙이 무심코 포함되어 있습니다.
이유는 단순합니다. AI는 우리 목표도, 우리 고객도, 우리가 이미 결정한 것들도 모르니까요.
링크드인 피드만 넘겨봐도 AI에 대한 의견은 극단적으로 갈립니다. 바로 위아래 글에서 누군가는 "채용을 했다면 그건 자동화에 실패했다는 뜻"이라 말하고, 누군가는 "AI는 그저 아부 떠는 기계일 뿐"이라고 말합니다. 완전히 다른 관점이 매일 충돌하죠.
저희가 내린 결론은 이렇습니다. AI가 무력해 보였던 건 AI의 한계가 아니라, 우리가 AI에게 우리 제품을 알려주지 않았기 때문이라는 것. 그렇다면 AI에게 우리 팀처럼 생각할 수 있는 맥락을 어떻게 제공할 것인가, 이게 저희가 풀어야 할 첫 번째 문제였습니다.
파편화된 회사 문서를 한 곳에 모으는 일부터
Joint 팀이 AX 전환을 위해 가장 먼저 풀어야 했던 문제는, 고질적으로 뿌리 깊은 회사의 문서 관리 방식이었습니다.
PD의 디자인과 스펙은 Figma에, 세일즈의 미팅 노트는 Google Drive에, PRD와 내부 자료는 Notion에, 레거시는 Slack에 흩어져 있었습니다. 정보가 필요한 사람은 매번 네 개의 툴을 돌아다녀야 했고, AI는 애초에 이 정보들을 볼 방법조차 없었습니다.
그래서 전 직군이 가장 먼저 진행한 일은, 파편화된 모든 문서를 Markdown 파일로
변환해 GitHub에 Joint Docs 저장소로 취합하는 작업이었습니다. 수백
건의 문서 양식을 바꾸고 옮기는 일은 AI가 '어렵다'라고 말하는 축에 들어가지 않거든요.
저희 저장소의 구조는 대략 이런 모습입니다. Joint Docs, Frontend,
Backend 세 저장소가 같은 위계로 놓여 있고, 그 안에서 디자이너와 엔지니어의
구분 없이 모두가 같은 공간에서 작업합니다. Joint Docs에 팀의 목표와 제품의
스펙, PRD, Task 문서가 모이고, 그 문서를 바탕으로 Frontend와
Backend에서 실제 구현이 이루어지는 구조입니다.
디자이너가 개발 저장소에서 직접 코드를 건드리게 되면 당연히 사고의 여지가 있습니다. 그래서 제가 실수로 잘못 건드리더라도 제품이 망가지지 않도록, 안전한 환경을 세팅해주는 일은 엔지니어분들이 먼저 해주셨습니다. 이 모든 안전장치가 먼저 깔리고 나서야 제가 처음 PR을 올릴 수 있었습니다.
이 과정을 거치고 나니 비로소 디자이너와 엔지니어가 같은 저장소에서 같은 방식으로 일한다는 말이 슬로건이 아니라 실제로 돌아가는 시스템이 되었습니다. 그리고 AI는 이 세 저장소를 자유롭게 오가며 맥락을 읽어냅니다. PRD를 읽고, 기존 컴포넌트를 참고하고, API 스펙을 확인한 뒤 일관된 결과물을 만들어내는 거죠.
팀처럼 생각하는 AI, 그리고 사라진 오버 스펙
팀의 올해 목표, 분기별 달성해야 할 일, 제품의 모든 스펙과 정책, 소중한 VOC와 미팅노트. 이 맥락을 다 쥐고 있는 AI는 우리 팀처럼 생각하며 PRD와 Requirements 문서를 써냈습니다. 사람은 리뷰만 해줘도 될 정도로요. 효용성, 생산성, 속도 어느 측면에서도 유리했습니다.
또 하나의 큰 장점은, 제품을 실행하는 단계에서 가장 흔하게 발생하는 '오버 스펙'이 일어나지 않는다는 점입니다.
직접 디자인이나 개발을 시도하다 보면 예상치 못한 작업이 추가되어 일정이 밀리거나, 서로 이해했던 범위가 달라 준비했던 디자인과 개발자가 준비한 구현이 엇갈리는 경우가 생깁니다. 저희도 얼마 전까지만 해도 스프린트 끝까지 가지 못하고 다음 주로 넘기는 일이 잦았습니다. 디자이너가 생각한 스펙과 엔지니어가 이해한 스펙이 미묘하게 달랐고, 그 차이가 구현 단계에서야 드러났기 때문이죠.
반면 AI로 시작되는 PRD와 Requirements 문서를 기반으로 디자인과 구현이 이어지면, 중간에 잘못된 명령을 내리지 않는 한 서로가 합의한 스펙에서 벗어나는 일이 거의 없습니다. 같은 문서를 각자의 관점으로 읽는 게 아니라, AI가 정리한 단일한 기준점을 함께 보게 되기 때문입니다.
블록을 쌓듯이, 복리처럼 쌓이도록
그렇게 문서가 쌓이기 시작했지만, 이걸 그대로 디자인과 개발로 넘길 수는 없었습니다. 문서는 '무엇을 만들 것인가'에 대한 합의지, '어떻게 만들 것인가'에 대한 지시는 아니니까요.
그래서 저희는 PRD를 기반으로 디자인과 프론트 구현이 한 번에 이어질 수 있는 Task 문서를 만들었습니다. AI가 잘 읽고 실행할 수 있는 형태의, AI를 위한 작업 지시서입니다.
다만 이 Task를 한 번에 거대하게 만들어 "화면 전체를 만들어줘"라고 던지지는 않습니다. 그렇게 하면 AI는 그럴듯해 보이지만 어딘가 어긋난 결과물을 내놓기 쉽고, 어느 지점에서 어긋났는지 되짚어 가기도 어렵거든요.
대신 블록을 쌓듯이 작업합니다. 하나의 기능을 아주 작은 단위로 쪼개고, 짧은 텀으로 싸이클을 반복하는 방식이죠. Task를 작성하고, AI가 구현하고, 결과를 검토하고, 문제가 있으면 다시 Task를 다듬고, 다시 구현하고. 이 싸이클이 한 번 돌 때마다 한 블록이 쌓이고, 그 블록 위에 다음 블록을 올립니다.
구체적인 예를 들어보겠습니다.
최근 저는 'Joint 팀에 문의하기' 기능을 PC와 모바일에 동시에 구현했습니다. 그것도 단 하루 만에요. 디자인 시안부터 PC 모달, 모바일 바텀 시트, 그리고 백엔드가 API만 연결하면 되는 지점까지 모두 하루 안에 마무리됐습니다. 예전 같았으면 디자인 QA와 커뮤니케이션만으로도 며칠이 걸렸을 작업입니다.
제품 어느 화면에서든 사용자가 불편을 느꼈을 때, 그 맥락 그대로 저희 팀에 목소리를 전할 수 있도록 어디에든 붙일 수 있는 공용 컴포넌트로 설계했습니다. 이 기능을 만들면서 저희는 작업을 네 개의 Task로 쪼갰습니다. 먼저 요청이라는 데이터의 뼈대가 되는 support 도메인 패키지를 생성하고, 그 위에 PC용 요청 모달 UI를 만들고, 다음으로 PC 모달과 모바일 바텀 시트를 제품에 연결한 뒤, 마지막으로 백엔드가 API 엔드포인트만 연결하면 즉시 동작하는 상태로 넘겨주는 것으로 마무리했습니다.
왜 이렇게 나누는지가 중요합니다. 처음부터 "PC, 모바일 문의하기 다 만들어줘"라고 AI에게 던졌다면, 결과물은 그럴듯해 보여도 반드시 어딘가 어긋났을 겁니다. 타입 정의가 엉성하거나, 모바일 UX가 PC와 혼재되거나, 공용으로 쓸 수 있어야 할 컴포넌트가 파일 뷰어에만 종속된 형태로 만들어지거나. 그리고 어긋난 지점을 되짚어 가는 일은 처음부터 다시 만드는 것보다 훨씬 오래 걸립니다.
대신 하나의 싸이클이 끝날 때마다 Task 문서 한 장이 남습니다. 다음 싸이클의 AI는 이전 싸이클의 결과물을 이미 읽은 상태로 시작합니다. 매번 백지에서 시작하는 게 아니라, 어제까지의 결정을 딛고 오늘의 블록을 올리는 거죠.
덧붙이자면, 이 기능을 공용 컴포넌트로 만들자는 제안은 사실 저희 팀 엔지니어에게서 나왔습니다. 처음 받은 과제는 "파일 뷰어에 문의하기 기능을 붙여달라"는 단순한 요청이었는데, 스펙을 논의하는 과정에서 "제품 어디서든 쓸 수 있게 공용으로 빼자"는 제안이 돌아왔고, 저는 그 방향을 받아 PC와 모바일 UX를 설계하고 구현까지 가져갔습니다. 기획의 출발점이 어느 직군이든, 더 나은 판단이 나오면 그걸 받아 끝까지 만들어내는 사람이 있으면 된다는 것. 이게 저희 팀이 일하는 방식입니다.
그래서 저희는 이 구조를 복리에 비유하곤 합니다. 한 번의 싸이클에서 쌓이는 맥락은 그 자체로는 크지 않을지도 모릅니다. 버튼 하나, 모달 하나, 작은 플로우 하나. 하지만 그 작은 결과물이 저장소에 남는 순간, 다음 싸이클은 그 위에서 시작합니다. 원금에 이자가 붙고, 그 이자에 다시 이자가 붙듯이, AI가 이해하는 Joint의 맥락은 시간이 지날수록 기하급수적으로 깊어집니다. 그 사이 저희가 한 일은, 싸이클을 멈추지 않은 것뿐입니다.
그래도 사람이 해야 하는 일
다만 분명히 해두고 싶은 게 있습니다. 여기서 말하는 싸이클과 속도는 디자인의 기본을 건너뛰는 방식이 아닙니다. 유저에게 어떤 가치와 사용성을 줄 것인가에 대한 고민은 프로덕트 디자이너가 언제나 지켜야 할 출발점이고, 그 출발점 없이 빠르기만 한 작업은 그저 실패에 도달하는 속도를 높일 뿐이니까요.
제품을 만드는 디자이너라면 본인의 제품에 대한 이해가 있어야, 설계해야 하는 기능과 화면을 어떤 구조로 만들지 단서를 찾을 수 있고 구체적인 난이도 예측이 가능합니다. 데이터가 어디서 오는지, 어떻게 구현되는지 모른 채 그린 화면은 구현 과정이 느려지고, 유저에게 닿기도 전에 힘을 잃습니다. 팀 안에서 다시 꺼내 쓸 수 있는 자산으로 남지도 못합니다.
또한, 디자이너에게 중요하고 사용자 경험으로 이어질 수 있는 디테일이 엔지니어에겐 현재의 우선순위가 아닐 수도 있습니다. 서로 여유가 없는 상황이라면 자연스럽게 무시되고, 영원히 챙겨지지 않는 백로그에 쌓이고, 아무도 해결하지 않습니다. AI는 이 판단을 대신 내려주지 않습니다. '이 방향이 우리 서비스에 맞는가'를 결정하는 일은 여전히 사람이 맡고 있고, 아마 가장 오래 남을 사람의 몫일 겁니다.
두 달은 누군가에게 우리를 복제할 시간
지난 글에서 예고했던 AI Award 이야기는 다음 글로 미루려 합니다. 어떤 상을 받았는가보다, 어떤 방식으로 AI를 디자인과 구현에 녹여내고 있는가를 먼저 나누는 게 의미 있겠다는 생각이 들었거든요.
시장의 변화는 예고 없이 옵니다. 두 달이라는 시간은 누군가에게는 우리를 복제할 시간이지만, 동시에 우리에게는 그 전에 더 멀리 갈 수 있는 시간이기도 합니다. 저희는 후자를 택하기로 했습니다.
이 글이 비슷한 고민을 하고 계신 분들께 조금이라도 도움이 되었으면 합니다. 저희도 완성된 답을 가진 건 아니고, 매일 싸이클을 돌리며 배워가는 중이거든요. 다만 한 발씩 쌓은 기록이 누군가에게는 출발점의 지도가 될 수 있다면, 그것만으로 충분할 것 같습니다.