안녕하세요, 시오입니다.
요즘 바이브코딩으로 이것저것 만들어 보고 있는데요. 이것저것 양산하는 시기가 지나면 '이게 진짜 시장에 먹힐까?'에 대한 고민을 하게 되더라고요. 게임에서 야심차게 멋진 스킬을 배워 시전했는데, 정확도 스탯이 낮아서 '공격이 빗나갔다! 효과는 미미했다!'는 알림이 뜨는 것 같은 상황이 반복되고 있기 때문이에요.
아이디어가 있어도 그게 시장에 팔릴만한 제품으로 구체화 하기란 쉽지 않더라고요. 이미 비슷한 또는 더 좋은 제품이 존재하는 경우도 허다했고요. 당연히 빠르게 먼저 만들어보는 방법도 있지만 프로토타입 단계에서 계속 폐기하는 것도 시간 낭비라는 느낌이 들었어요. 그리고 제가 디자이너가 아니다보니, 제품을 직접 빌드하는 단계에서 어떤 디자인이 잘 어울릴지 고민하는 것도 쉽지 않았습니다.
다행히 최근에는 이런 고민을 해결해 주는 도구들이 꽤 많이 생겼어요. 오늘은 뭔가를 무작정 만들어 내기에 앞서 아이디어를 발산하고, 검증하는 단계에 활용할 수 있는 스킬들을 소개해 볼게요.
아이디어를 키우고 검증하기
보통 아이디어가 떠오르면 바로 AI를 두들겨 뭔가를 만들기 시작하는데, 그러면 처음 생각한 프레임에 갇히는 경우가 많습니다. 그래서 구체화하기 전에 사고의 틀을 한 번 넓히는 단계가 있으면 좋지만, 사실 혼자서는 쉽지 않은 일이에요.
그래서 Product-Manager-Skills라는 도구를 써봤습니다. PM들이 쓰는 생각 정리 방법 77개를 Claude Code 스킬로 옮겨둔 것이고, 무료로 이용할 수 있어요. PRD나 로드맵 같은 후반 산출물을 만드는 도구도 포함되어 있지만, 제가 특히 유용하다고 느낀 건 아이디어가 아직 머릿속 한 줄일 때 쓰는 초기 단계 스킬들입니다. 이 단계에서 대부분의 아이디어는 "뭘 만들지"는 있는데 "누구의 어떤 문제인지"와 "틀렸다면 어떻게 알 수 있는지"에는 답하기 어려운 경우가 많아요. 이 라이브러리는 그 비어있는 지점을 질문을 통해 채워줍니다.
1."만들고 싶은 것"이 실제 문제나 기회와 연결되어 있는지를 확인해 준다.
아이디어를 한 줄 던지면 해결책 대신 문제가 무엇인지부터 먼저 검증해 줍니다. 누가, 뭘 하려다, 왜 막히는지를 되묻고, 한 장짜리 캔버스로 정리해 줘요. 혼자 하면 건너뛰기 쉬운 "이게 진짜 문제인가"를 강제로 거치게 됩니다.
2. 내 아이디어가 유일한 답이 아니라는 걸 보여준다
문제 및 기회와 연결된 해결책 후보를 여러 갈래로 펼쳐 줍니다. 첫 아이디어에 집착하게 되기 쉬운데, 이 과정을 거치면 아이디어는 선택지 중의 하나로 보이게 될 수 있어요. 경쟁 제품 리뷰와 포럼 글을 긁어 근거를 붙여주니 직접 고객 인터뷰를 하지 않아도 고객 목소리를 미리 가늠해 볼 수 있습니다.
3. 만들기 전에 "틀렸는지 알 수 있는 기준"과 가장 빠른 테스트 방법을 알려준다
"[기능]을 [대상]에게 주면 [결과]가 날 것이다, [기간] 안에 [지표]로 확인한다"와 같이 검증할 가설과 결과를 만들어 줍니다. 지금 상황을 기준으로 1~2일 스파이크, 랜딩페이지, 클릭형 프로토타입 중 뭔저 시도해보면 좋을지 검토해 주고요. 이렇게 되면 끝없이 만들기만 하는 상태를 막을 수 있는 실패 기준을 확보할 수 있어요.
바로 답을 주지 않고 먼저 묻는다는 게 이 스킬의 핵심이고, 씨앗만 있는 상태에서는 결과물보다 질문이 더 도움이 되더라고요. 저는 이번에 영국 프리미어 리그 경기 스케줄과 선수 정보를 조회할 수 있는 사이트를 만들어 보려고 했는데요.
이 스킬을 돌려보니 이미 존재하는 대안이 있는지를 먼저 확인할 수 있었어요.
그리고 제가 처음에 제안한 아이디어 대신 수요가 실재하는지 검증해 볼 수 있는 방법 선택지를 만들어 주더라고요.
어떻게 보일지 정하기
AI 모델이 디자인하는 방법
클로드나 GPT한테 "이런 서비스 만들어줘"라고 하면 모델은 학습한 데이터와 대화에서 주어진 컨텍스트로 화면을 만들게 됩니다. 컨텍스트는 내가 직접 붙인 프롬프트나 파일, 이미지일 수도 있고 모델이 검색이나 도구로 가져온 것일 수도 있는데요. 어느 쪽이든 텍스트와 이미지 두 형태로 들어가게 됩니다. 코드나 디자인 토큰처럼 정확한 값이 담긴 텍스트는 그대로 반영되고 이미지는 근사치로 반영되는 방식이에요. 이 때 참고할 수 있는 컨텍스트가 비어 있으면 학습되어 있는 데이터의 평균이 결과물로 나오게 됩니다. 바이브코딩 결과물이 다 비슷한 이유가 여기에 있어요.
그래서 하나라도, AI가 명확하게 참고할 수 있는 레퍼런스나 규약이 있으면 디자인을 만드는 데에 도움이 됩니다. 그렇다면 내가 디자이너도 아닌데 어떻게 좋은 레퍼런스를 얻을 수 있을까요?
요즘의 디자인 도구들
어이디어를 검증하는 스킬처럼 디자인 아이데이션을 위해서 사용할 수 있는 다양한 도구들이 있어요. 기존에는 모빈, 드리블 등 여러 레퍼런스 사이트들을 뒤지고 다녔다면 이제는 무드보드 구성마저도 AI의 도움을 받을 수 있습니다. 앤트로픽에서 제공하는 프론트엔드 디자인 스킬도 있지만, 요즘엔 그 종류가 더 다양해졌어요.
예를 들면 대표적인 레퍼런스 사이트인 Mobbin도 MCP를 제공해요. 디자인 레퍼런스들이 모두 코드화가 되어 있는 shadcn같은 방식은 아니긴 합니다. 그래도 내가 필요한 레퍼런스가 있을 때 시각적으로 유사한 레퍼런스를 쉽게 모아볼 수 있다는 건 좋은 일이죠.
| 역할 | 도구 | 비용 |
|---|---|---|
| Mobbin MCP | 실제 앱 화면 62만 장 | 유료 |
| Awwwards-mcp | 수상 사이트 검색, 계측, 디자인 브리프 생성 | 무료 |
| UI UX Pro Max | 스타일·팔레트·UX 규칙 카탈로그 | 무료 |
레퍼런스 도구는 "어떻게 보일지"를 결정하는 데에 도움을 주고 규칙 도구는 "뭘 지킬지"를 정의하는 데에 활용할 수 있어요.
Mobbin이 가장 널리 쓰이지만 유료 플랜이 필요합니다. 무료로 실제 레퍼런스를 가져오는 건 Awwwards-mcp를 사용해 보세요. 정형화되지 않은 디자인 사례들도 많이 가져오기 때문에 다양한 스타일을 익히는 데에도 도움이 됐어요. 무엇보다 레퍼런스를 기반으로 '디자인 브리프'를 만들어주는 기능이 바이브 코딩 결과물을 만드는 데에 꽤 도움이 되더라고요.
UI/UX Pro Max는 레퍼런스 이미지 없이 글로 된 규칙만으로 작동하는 디자인 카탈로그예요. 67개 UI 스타일, 수십 개 팔레트·폰트 페어링, 161개 추론 규칙, UX 가이드라인이 들어 있고, 제품 설명을 넣으면 거기 맞는 스타일·색·타이포를 꺼내 디자인 시스템으로 추천해줍니다. 무료이고, 설치 28만 회로 디자인 스킬 중 압도적 1위예요. 만들어진 결과물은 평범했지만 운영 규칙으로 묶어서 일관성을 잡아주는 데에는 유용한 느낌이었어요.
위에서 이야기한 영국 프리미어 리그의 축구 스케줄을 미리 확인할 수 있는 사이트의 디자인 방향성을 아이데이션 해봤습니다.
먼저 awwwards-mcp를 이용해 축구 티켓, 나이키 앱 같은 에슬레틱 느낌의 레퍼런스를 찾아달라고 했어요. 그랬더니 아래와 같은 느낌을 찾아주더라고요.
그리고 이렇게 찾은 레퍼런스의 배경, 헤드라인, 자간 등의 정보를 기반으로 디자인 브리프가 만들어졌는데, 레퍼런스마다 가져올 것과 버릴 것이 표로 정리돼 있었습니다. 그 다음으로는 UI/UX Pro Max 스킬로 카탈로그화 합니다. 카탈로그를 조합해 크게 3가지 방향의 html 시안을 만들어 큰 느낌을 비교할 수 있게 AI가 만들어 줬어요.
이렇게 하니 제품을 구체화하기 전에 내가 원하는 느낌을 미리 테스트 해보기에 훨씬 도움이 되더라고요.
결정하기 전에 질문하자
위에서 소개한 도구들을 Claude Code에서 돌리면 결과를 바로 주지 않고 먼저 질문을 던진다는 공통점이 있어요. PM 스킬은 상황 질문을 서너 개 물어보고요. Awwwards 쪽도 원하는 아웃풋의 스타일이나 결과 밀도, 뷰포트 같은 걸 처음에 물어봐요.
프롬프트를 넣으면 바로 화면이 나오는 도구들과 다른 점이 여기라고 생각해요. Seed 아이디어만 있는 상태에서는 결과물보다 질문이 더 도움이 되는 것 같아요. 나 혼자만 굳게 믿고 있는 편향이 강화될 위험도 막아주고. 이런 질답 과정이 생각을 정리하는 파트너처럼 작동합니다.
최근에 제작 비용이 0에 수렴한다고는 하지만, AI 슬롭도 많아지는 상황이잖아요. 그렇기 때문에 넘쳐나는 결과물들 사이에서 진짜 유의미한 접근을 빠르게 하는 것이 더욱 중요해 진 것 같아요. 모델이 디자인을 만들어내는 원리를 이해해 보면, 무작정 키워드를 입력해서 디자인을 뽑으라거나 수십장의 레퍼런스를 던지기 전에 필요한 영역을 언어화시키는 것이 더 효율적이겠죠. 모은 화면들의 공통점과 차이를 먼저 말로 뽑게 하면 내가 원하는 방향이 어디서 어긋나는지가 판단하기가 더 쉬워지기도 하고요.
일단 만들고 아니면 폐기하는 방법도 있지만, 초반에 다양한 가능성을 효과적으로 가늠하고 맞는 방법을 빠르게 추려 나가는 것도 중요한 시기인 것 같습니다. 내가 열심히 만든 결과물이 '공격 성공! 크리티컬 임팩트!'가 뜨는 그 날까지, 프로덕트 메이커 모두 파이팅입니다🔥
📮 다음 호 예고
[38호] AI와 일하는 방식도 디자인할 수 있을까
프롬프트를 잘 쓰는 것만으로는 AI 결과물의 품질을 안정적으로 만들기 어렵습니다. 같은 요청을 해도 매번 조금씩 다른 결과가 나오고, 필요한 맥락을 빼먹거나 그럴듯한 가정으로 빈칸을 채워버리기도 하니까요.
그래서 이제는 “AI에게 무엇을 시킬까”보다 “AI가 어떤 순서로 생각하고, 어떤 정보를 참고하고, 어떤 기준으로 스스로 검증하게 할까”를 설계하는 일이 더 중요해지고 있습니다.
다음 호에서는 프롬프트를 넘어 Context, Skill, Agent, Playbook을 어떻게 구성하면 나만의 AI 업무 시스템을 만들 수 있는지, 그리고 실제 업무에 적용할 때 어디서부터 시작하면 좋은지를 살펴보려고 해요.
✉️ 다음 호가 궁금하신 분들은 아래 [구독하기] 버튼을 눌러주세요.
의견을 남겨주세요