Latest news & coverage
Articles
서비스를 처음 만드는 디자이너가 반드시 피해야 할 7가지 함정
서비스 프로덕트를 처음 만드는 디자이너에게 가장 필요한 말은 이것입니다. 디자인 잘하는 것보다 끝까지 살아남는 서비스를 만드는 것이 먼저입니다. 디자이너는 누구보다 빠르게 제품을 시각화할 수 있습니다. 아이디어가 떠오르면 피그마를 열고, 몇 시간 안에 그럴듯한 화면을 만들어냅니다. 이 능력이 장점이지만, 동시에 가장 큰 함정이 되기도 합니다. 화면을 만드는 속도가 빠를수록 ‘진짜 필요한 것을 검증하는 속도’는 오히려 느려지기 때문입니다. 실제로 디자이너 출신이 만든 서비스가 초기에 무너지는 패턴은 놀랍도록 비슷합니다. 이 글은 그 패턴들을 일곱 가지로 정리했습니다. 개발 경험이 없거나 적은 디자이너가 노코드·AI 툴로 처음 서비스를 만들 때 가장 자주 마주치는 함정들입니다.
React+Vite에서 Next.js App Router로 갈아탄 이유: 디자이너 빌드 경험기
직접 SaaS를 만들어보기로 했습니다. 관리형 서비스 플랫폼으로, 여러 조직이 가입해서 각자의 팀을 관리하는 구조입니다. 처음엔 이미 익숙한 React+Vite로 내부 테스트 버전을 먼저 만들었습니다. 작동은 잘 됐습니다. 문제는 외부에 공개할 SaaS 버전을 만들 때 시작됐습니다. 로그인한 사람이 어떤 조직 소속인지 판단해서 맞는 화면을 보여줘야 하고, 슈퍼어드민은 전체 조직을 관리하고, 어드민은 자기 조직만, 일반 유저는 서비스 화면만 봐야 했습니다. 내부 테스트 버전 코드를 그대로 쓰려 했는데, 잠깐 로그인 화면이 보였다가 대시보드로 넘어가는 깜빡임이 생겼고, 조직별 URL 구조를 클라이언트에서 처리하는 코드가 점점 복잡해졌습니다. Claude Code로 같이 빌드하면서 이 문제를 파고들다가 결론이 나왔습니다. 이 구조는 React+Vite로 억지로 맞추는 것보다 Next.js App Router로 새로 잡는 게 맞다고요. 이 글은 그 판단의 이유 다섯 가지를 구체적으로 정리한 것입니다.
제품 만드는 사람이 알아야 할 마케팅 지표 완전 정리
제품을 만드는 데 집중하다 보면 마케팅은 나중 문제로 미루게 됩니다. ‘좋은 제품은 알아서 퍼진다’는 말을 믿으며. 하지만 현실에서 훌륭한 제품이 조용히 사라지는 일은 매일 일어납니다. 반대로 평범한 제품이 마케팅 하나로 폭발적으로 성장하는 일도 있습니다. 특히 SaaS나 게임처럼 디지털 제품을 혼자 혹은 소규모로 운영한다면, 개발·디자인·마케팅을 동시에 이해해야 합니다. 마케터를 따로 고용하기 전까지는 본인이 의사결정자이기 때문입니다. 이 글은 디지털 제품을 운영하는 사람이 반드시 알아야 할 마케팅 지표와 전략을 정리합니다. 이론보다는 실제로 숫자를 보고 판단하는 데 바로 쓸 수 있는 내용에 집중했습니다. 유입, 수익, 사용자 활성도, 바이럴, SaaS·게임별 핵심 구조까지 순서대로 정리해보겠습니다.
Figma + AI + MCP: 디자이너의 일상을 바꾸는 Design System 자동화 실전 가이드
디자이너라면 누구나 경험한 적 있을 것입니다. 몇 시간을 들여 완성한 컴포넌트 스펙 문서가 다음 날 디자인 변경으로 이미 낡아버리는 상황. 개발자에게 스펙을 전달했는데 ‘이 여백 수치가 Figma 파일이랑 다른데요?’라는 메시지를 받는 순간. 디자인 시스템을 최신 상태로 유지하는 것 자체가 또 하나의 전담 업무가 되어버린 현실. 이 모든 문제의 근본 원인은 하나입니다. 디자인 도구(Figma)와 AI, 그리고 개발 도구들이 서로 다른 언어를 쓰고 있었다는 것입니다. 사람이 중간에서 데이터를 옮기고, 번역하고, 동기화하는 역할을 떠맡아야 했습니다. MCP(Model Context Protocol)가 이 구조를 바꿉니다. AI 에이전트가 Figma를 직접 읽고, 분석하고, 조작할 수 있게 되면서 디자이너는 반복 작업에서 벗어나 본질적인 창작에 집중할 수 있습니다. 이 글은 그 변화가 실제 현장에서 어떻게 구현되고 있는지를 다룹니다. Figma MCP의 핵심 기능, Uber의 실전 사례 uSpec, 그리고 지금 당장 팀에 도입할 수 있는 다섯 가지 워크플로우 시나리오를 통해 디자인 자동화의 실체를 살펴보겠습니다.
MCP 완전 정복: AI 에이전트 시대의 표준 연결 프로토콜
2024년 말, AI 도구 생태계에 조용하지만 근본적인 변화가 시작됐습니다. Anthropic이 MCP(Model Context Protocol)를 오픈소스로 공개한 것입니다. 이 발표가 처음에는 크게 주목받지 못했지만, 1년이 지난 지금 MCP는 AI 에이전트 인프라의 사실상 표준이 되어가고 있습니다. 왜 MCP가 중요한가를 이해하려면 AI 에이전트가 직면한 근본적인 문제를 먼저 알아야 합니다. AI 모델은 텍스트를 이해하고 생성하는 능력은 뛰어나지만, 외부 세계와 상호작용하는 데 표준화된 방법이 없었습니다. 각 AI 서비스와 각 도구가 독자적인 연동 방식을 구현해야 했고, N개의 AI 서비스와 M개의 도구를 연결하려면 N×M개의 맞춤 통합이 필요했습니다. MCP는 이 문제에 대한 우아한 해답입니다. AI 클라이언트와 도구 제공자 사이에 표준화된 ‘공통 언어’를 만들어, 한 번 구현하면 어디서나 연결되는 구조를 만들었습니다. USB-C가 다양한 기기를 하나의 케이블로 연결하듯, MCP는 다양한 AI 에이전트와 도구를 하나의 프로토콜로 연결합니다. 이 글은 MCP의 작동 원리부터 아키텍처 구성 요소, Local vs Remote MCP의 차이와 효율성 비교, 그리고 실제 도입 시 고려해야 할 실용적 관점까지 종합적으로 다룹니다. 개발자는 물론, AI 도구를 도입하려는 기획자와 의사결정자들도 MCP를 올바르게 이해하고 판단할 수 있도록 작성했습니다.
상업적 이용 가능? 생성형 AI 약관 뒤에 숨겨진 ‘저작권 함정’
지난달, 한 동료 디자이너에게서 DM이 왔습니다. “Midjourney로 만든 이미지 제안서에 넣어도 되죠? 상업적 사용 가능하다고 되어 있는데.” 저는 잠깐 멈칫했습니다. “된다”고 대답하기엔 뭔가 찜찜했고, “안 된다”고 하기엔 근거가 부족했습니다. 결국 “일단 쓰고, 나중에 교체하자”고 했는데 — 돌이켜보면, 이 “일단”이라는 단어가 우리 업계에서 얼마나 자주 쓰이고 있는지 무서울 정도입니다. 속도의 시대, 역설적인 질문 UX 디자이너는 늘 효율과 퀄리티 사이에서 균형을 잡는 설계자입니다. 문제를 정의하고 구조를 짜는 과정에서 기술은 언제나 우리의 든든한 조력자였습니다. 특히 최근의 생성형 AI는 우리가 며칠씩 밤새우며 고민하던 비주얼 결과물을 단 몇 초 만에 그려내며, 디자인의 속도를 완전히 바꾸어 놓았습니다. 하지만 결과물의 생성 속도가 한계치에 다다를수록, 우리는 역설적인 질문을 마주하게 됩니다. “이 이미지, 진짜 써도 되는 건가?” 이건 기술의 질문이 아닙니다. 책임의 질문입니다.
잘 나뉜 사일로가 AI 팀을 강하게 만든다
조직에서 ‘사일로(silo)’는 오랫동안 나쁜 단어였다. 팀 간 소통이 단절되고, 정보가 공유되지 않고, 각자 자기 일만 하는 폐쇄적인 구조. 사일로를 없애야 한다, 협업을 늘려야 한다는 말이 조직 문화 담론의 중심에 있었다. 그런데 AI 에이전트가 일상적인 업무 도구가 되면서 흥미로운 변화가 생기고 있다. 팀원 각자가 자신의 AI 에이전트를 구성하고, 그 에이전트를 중심으로 독립적으로 작업하는 환경이 빠르게 늘고 있다. 개발자는 코딩 에이전트와 함께 일하고, 기획자는 리서치 에이전트와 문서 에이전트를 운용하고, 디자이너는 시안 생성 에이전트를 돌린다. 각자의 AI 에이전트가 각자의 업무 영역을 깊이 파고드는 구조다. 이것은 사일로인가? 그렇다. 하지만 나쁜 사일로가 아니다. 오히려 AI 에이전트 시대에 가장 자연스럽고 효과적인 팀 구조일 수 있다. 문제는 사일로를 없애는 게 아니라, 사일로를 어떻게 잘 설계하고 유지하느냐다.
AI 시대에도 클릭 한 번으론 좋은 서비스가 나오지 않는다
주변을 보면 AI 도구를 적극 활용해서 빠르게 뭔가를 만드는 사람들이 많아졌다. MVP를 며칠 만에 런칭하고, 랜딩 페이지를 몇 시간 만에 완성한다. 외형은 꽤 그럴듯하다.
AI가 디자인을 완성하는 시대, 역설적으로 ‘손맛’이 필살기가 되는 이유
UX 디자이너는 늘 효율과 퀄리티 사이에서 균형을 잡는 설계자입니다. 문제를 정의하고 구조를 짜는 과정에서 기술은 언제나 우리의 든든한 조력자였습니다.
AI 환경 쉽게 이해하기: 모델부터 서비스까지 한 번에 정리
요즘 AI 서비스는 거의 매주 새롭게 등장하고 있습니다. 모델 이름은 계속 바뀌고, 기능은 빠르게 확장되고 있습니다. 그래서 많은 사람들이 이렇게 느낍니다.
AI 시대, UX 디자이너가 개발환경을 알아야 하는 이유
AI 시대, 프로덕트 UX는 부분 역할로는 부족합니다. 과거의 UX 디자인이 사용자가 보는 ‘예쁜 집’을 꾸미는 일이었다면, AI 시대의 UX는 집의 설계도와 배관 구조까지 이해해야 하는 일로 변하고 있습니다.
UX 디자이너의 1 Hour Sprint: 바이브코딩으로 증명하는 설계의 힘
UX 디자이너는 늘 설계의 중심에 서 있습니다. 문제를 정의하고, 사용자 흐름을 설계하며, 인터랙션을 구조화하는 것이 우리의 본업입니다. 하지만 그 과정의 끝에서 우리는 늘 같은 질문을 마주하게 됩니다. “이걸 실제로 구현하면 어떤 느낌일까?” 과거에는 이 질문에 답하기 위해 개발자의 리소스를 기다리거나, 프로토타이핑 툴의 한계 내에서 타협해야 했습니다. 하지만 이제는 멈출 이유가 없습니다. AI와 바이브코딩(Vibe Coding) 방식을 활용하면, UX 디자이너도 1시간 안에 실제 동작하는 프로토타입을 빌드할 수 있기 때문입니다. 이번 콘텐츠에서는 UX 디자이너가 1 Hour Sprint를 통해 문제 정의부터 실제 배포, 그리고 리뷰까지 진행하는 실무적인 프로세스를 정리해 드립니다.