고민 :
지금 웹 에이전시를 다니는 3년차 UX/UX 디자이너입니다. 프로덕트 디자이너로 전향하려 하는데 에이전시 경험밖에 없어요. 스타트업과 에이전시는 많이 다르다고 들었는데 그렇다면 저의 에이전시 경험은 전혀 쓸모가 없는걸까요?
란란의 답 :
① 아뇨. 그렇지 않습니다. 다만 쓸모가 달라질 수는 있어요.
왜냐면 ‘에이전시’와 ‘스타트업’은 비즈니스 모델이 달라 그에 따른 필요 역량이 다르거든요. 그래서 이 차이를 아는게 굉장히 중요합니다. 하나씩 알아볼께요.
② '디자이너'라면 기본으로 갖춰야 하는 핵심 능력은 동일해요.
에이전시든 스타트업이든 디자인을 업으로 삼는 사람이라면 공통적으로 갖춰야 하는 핵심 능력이 있어요. 바로 ‘정보를 시각화하여 타겟에게 잘 전달하는 능력’이에요. 요리로 치면 밀키트를 잘 만드는 사람과 즉석 요리를 잘 하는 사람은 요리하는 방식은 다르지만 ‘요리를 할 줄 아는 능력’은 똑같이 가지고 있어야 하는 것과 같아요.
③ ‘에이전시’와 ‘스타트업’은 필요한 역량이 달라요.
하지만 에이전시와 스타트업에서 필요한 디자이너의 역량은 다른데 그 차이를 알려면 비즈니스 모델의 차이를 알아야 해요. 원인이 여기에 있거든요.
[에이전시]
회사 운영 방식 : 자사 서비스가 아닌 타사 서비스의 제작과 운영을 대신 해주는 곳이에요. 클라이언트가 계속 바뀌고 그에 따라 제작해야 하는 서비스나 제품도 계속 바뀌죠.
하지만 클라이언트가 바뀌고 서비스나 제품이 바뀌어도 디자이너의 할일은 크게 바뀌지 않아요.
서비스 제공 방식과 그에 따른 책임 : 완성품을 클라이언트에게 ‘납품’ 하기 때문에 결과물 자체가 서비스에요. 그래서 클라이언트는 서비스 품질을 평가할 때 구조의 완성도와 디자인 완성도를 많이 봐요. 또한 완료 시점이 명확하고 전달해야 하는 결과물도 정해져 있어서 한 번 만들 때 손 볼 필요 없는 수준의 완성도를 요구받아요.
디자이너의 기획 관여도 : 에이전시는 *워터풀 형태로 일하는게 일반적이에요. 그래서 서비스 정책, 화면 기획, 시장과 사용자 분석은 별도 파트가 담당하고 디자이너는 ‘이미 결정된 기능과 가치를 타겟 사용자에게 시각적으로 전달하는 역할’에 집중해요. 에이전시의 수익은 대부분 프로젝트 수주에서 나와요. 즉, 클라이언트가 무언가를 요청하면 그 요구사항을 정해진 기간 내에 만들고 납품하는 방식이죠. 그래서 프로젝트 시작 전에 요구사항 범위(스콥이라고 하죠), 작업 범위(화면 수), 마감일, 예산, 산출물 종류(아웃풋) 이런걸 확정해요. 기획이 이미 정해진 상태로 프로젝트가 시작되는 경우가 대부분이에요. 기획은 프로젝트 초기 단계에서 클라이언트와 기획파트가 먼저 끝내는거죠. 일정이 매우 중요하기 때문에 리스크를 최소화 하기 위해 업무를 완벽히 분할하고 고정시켜요. 이런 구조 때문에 디자이너가 기획에 참여할 수 없어요.
(*워터풀 업무 방식이란? 프로젝트 진행에 꼭 필요한 각 단계를 폭포수처럼 순차적으로 진행하는 업무 방식을 말해요. 요구사항 정의, 분석, 기획, 디자인, 개발, 테스트와 같은 단계를 이전 단계가 완료된 후에야 다음 단계로 넘어갈 수 있어요.)
에이전시 UX/UI 디자이너에게 요구되는 역량 : •
계속해서 바뀌는 다양한 도메인에 빠르게 적응하고 그에 맞춰 표현하는 역량
•
시각적으로 미려한 결과물을 만들어내는 역량
•
완료 시점에 산출물 형태로 결과값을 만들어내는 역량
•
납품한 결과물을 클라이언트 조직 내에서 잘 쓸 수 있도록 잘 정리하는 역량
•
트렌드를 읽고 반영할 수 있는 역량
[스타트업(인하우스)]
회사 운영 방식 : 스타트업은 외부 클라이언트를 위한 프로젝트가 아니라 ‘우리 서비스/제품’을 직접 만들고 성장시키는 조직이에요. 한 번 만들고 끝나는 게 아니라 시장 반응을 보며 계속 개선해야 하죠.
특히나 스타트업의 경우 투자 시리즈에 따라 제품 성숙도가 다른데 그에 따라 디자이너의 할일도 달라져요. 예를 들어 이제 막 제품을 만들기 시작하는 단계라면 핵심 문제를 정의하고 최소 기능(MVP)를 빠르게 설계해 시장에 내놓는 역할을 해야 해요. 이 시기에 디자이너가 디자인 시스템을 만든다거나 디자인의 디테일에 집착하는 건 비효율적일 수 있어요. 제품을 시장에 내놓고 사용자들의 반응을 보는 단계라면 사용자 행동 데이터를 기반으로 기능의 성능을 검증하고 개선 방향을 찾는 역할을 해야 해요. 이 시기에 미세한 UI 디테일에 시간을 과하게 쓰는건 사용자 행동 검증의 속도를 늦추게 될 수 있어요. 시장성은 검증했고 서비스를 안정화시키는 단계라면 정책, 기술, 구조, 운영, 브랜딩까지 고려해 제품을 견고하게 다듬는 역할이 필요해요. 이 시기엔 디자인 시스템 정비, UI 디테일 개선, 브랜드 일관성 확보같은 ‘품질 강화 작업’이 오히려 필수적이에요.
서비스 제공 방식과 그에 따른 책임 : 완성된 결과물을 납품하는 것이 아니라 ‘지속적으로 운영, 개선’해야 해요. 그래서 기능 하나, 정책 하나가 전체 비즈니스 성과에 어떻게 영향을 주는지를 명확히 알고 있어야하죠. 또한 완벽하게 만든다고 시간을 너무 많이 써버리면 시장 검증 시기를 놓쳐 회사 생존에 문제가 생길수도 있어요.
그렇기에 스타트업에서의 완성도는 빠르고 정확하게 문제를 해결하는 정도를 말하는 경우가 많아요. 즉, 구조적, 미적 완성도 보다는 문제 해결의 적합성, 사용자 반응, 지표 개선이 완성도의 기준이 되는거죠.
스타트업 디자이너의 기획 관여도 : 회사마다 다르거나 한 회사 안에서도 팀마다 다르긴 하지만 조직이 *애자일 업무 방식을 차용할 수 있어요. 그렇다면 디자이너가 기획에 깊게 관여할 수 있죠. 이런 경우 디자이너는 사용자, 데이터, 비즈니스 세 가지를 모두 읽어야 해요. 물론 모든 스타트업이 그렇진 않아요. 아직도 많은 스타트업이 에이전시처럼 워터풀 구조로 일해요. (참고로 스타트업은 자사 서비스/제품을 만들기에 인하우스로 분류되는데 이 얘긴 따로 다룰께요.)
(*애자일 업무 방식이란? 짧은 주기로 반복적인 개발과 피드백을 반복하는 업무 방식이에요. 모든 기능을 한 번에 만들기 보다는 조금씩 만들어서 시장에 내보이고 고객 피드백을 받아 개선하는게 특징이에요. 그래서 기획과 디자인과 개발이 언제나 함께 긴밀하게 논의하고 협의해요.)
스타트업의 UX/UI 디자이너 또는 프로덕트 디자이너에게 요구되는 역량 : •
사용자의 변화, 데이터의 흐름, 비즈니스의 성장 그래프를 꾸준히 관찰하고 반영할 수 있는 역량
•
서비스 정책, 시장 구조, 기술 제약, 내부 상황을 이해하여 반영하는 역량
•
완벽하지 않아도 핵심 기능을 빠르게 출시하고 시장 반응을 검증하는 역량 (이걸 PMF를 찾는다고 표현해요)
•
화면 단위가 아니라 사용자 플로우, 수명 주기 단위로 제품을 설계하는 역량
•
기능 출시 후 지표를 지반으로 분석하고 반복 개선하는 역량
④ 그렇다면 에이전시 경험은 어디에 쓸모가 있을까요?
에이전시는 짧은 시간에 다양한 도메인을 빠르게 이해하고 수준 높은 결과물을 내야하기에 에이전시 출신 디자이너들은 보통 아래 역량에 강해요.
제품에 대한 적응이 빨라요 : 클라이언트와 제품이 계속 바뀌는 환경에서 일했기 때문에 새로운 도메인, 새 기능, 새 프로젝트를 빨리 파악하는 능력이 있어요. 이는 곧 진행중인 프로젝트에 빠른 투입이 가능하게 해줘요.
화면을 만들어내는 속도가 빨라요 : 요구사항이 정해진 상태에서 구조를 잡고 제한된 시간 안에 구현까지 빠르게 이어가는 실행력이 뛰어나요. 대부분의 에이전시는 촉박한 일정 속에서 완성도 높은 결과물을 요구받기 때문에 자연스럽게 생기는 강점이에요. 이 강점은 ‘아이디어를 빠르게 실현하여 시장에 내놓아야 하는 상황’에서 빛을 발해요.
정리를 잘 해요 : 원본 파일, 다양한 컴포넌트도 ‘납품 대상’이에요. 그래서 타인이 바로 활용할 수 있는 형태로 산출물을 구조화하고 정리하는 능력이 뛰어나요. 이는 곧 함께 일하는 동료들, 특히 개발자들의 업무 효율을 높여줘요.
UI 완성도가 높아요 : 시각적 완성도가 서비스 품질 평가 기준이 되는 환경에서 일했기 때문에 디테일, 톤앤매너, 레이아웃 완성도가 전반적으로 높아요. 그래서 미려한 결과물을 사용자에게 보여줄 수 있고 이는 곧 제품의 완성도를 높이는 역할을 해요.
⑤ 그렇다면 에이전시 경험만 있는 디자이너가 스타트업의 프로덕트 디자이너가 되기 위해서는 어떤 역량을 보완해야 할까요?
에이전시 경험이 강점이 되는 부분이 많지만, 스타트업은 완성도 있는 화면을 만드는 것보다 ‘지속적인 문제 해결과 성능 개선’에 가까운 사고방식과 스킬셋을 요구해요. 그래서 아래 역량을 보완하면 전향이 훨씬 자연스럽고 빠르게 이루어져요.
데이터를 읽고 해석하는 능력 : 스타트업은, 아니 정확히 말하자면 디자이너가 기획에 참여하려면 ‘왜 이 기능이 필요한가’를 숫자와 사용자 행동을 근거로 설명해야 해요. 에이전시는 기획 파트가 이 부분을 맡는 경우가 많기 때문에 디자이너가 직접 데이터를 읽고 문제를 설정하는 연습이 필요해요. 사용자 행동 데이터, 주요 전환 지표, 퍼널 흐름과 이탈률과 같은 데이터를 보고 ‘사용자에게 어떤 문제가 생겼는지’를 파악할 수 있어야 하고 ‘그 이유는 무엇인가’를 유추할 수 있어야 해요.
서비스 정책과 시스템 로직을 이해하는 능력 : 기획을 하려면 화면만 이해해서는 안 돼요. 화면 뒤에서 어떤 정책이 돌아가고 있는지 알아야 제대로 된 개선과 설계가 가능해요. 결제나 환불 정책, 정산 방식이나 배송 방식, 추천/매칭 알고리즘, 필터나 정렬 규칙, 운영팀의 업무 플로우 등과 같은 정책을 이해하지 못하면 화면만 바꿔도 해결이 안 되는 문제에 계속 부딪히게 돼요.
사용자 여정을 끝까지 보는 능력 (화면 기반이 아닌 플로우 기반 사고 능력): 에이전시는 화면 단위, 페이지 단위로 일하는 경우가 많아요. 프로젝트 범위가 크면 디자이너들끼리 화면을 분담하여 작업하기도 하죠. 하지만 스타트업은 사용자가 처음 들어와서 목표 행동을 하고 다시 찾아오기까지의 전체 흐름을 설계해야 해요. 즉, 페이지가 아닌 플로우, 수명주기 단위로 문제를 정의하고 해결해야하죠. 예를 들어 <가입 → 탐색 → 기능 사용 → 전환 → 재방문>과 같은 흐름을 보고 설계하는거죠. 이는 곧 ‘퍼널의 이해’와도 연결돼요.
빠른 실험과 검증 능력 : 스타트업은, 특히 초기 스타트업은 완벽한 디자인 보다는 빠른 시장 검증을 우선해요. (그렇다고 디자인이 미려하지 않아도 된다는 뜻은 또 아니에요.) 그래서 디자이너는 가설을 세우고, 최소 기능으로 검증하고, 지표를 보고, 개선을 반복하는 이 사이클을 이해해야 참여할 수 있어요. 화면을 잘 만드는 역할에서 문제를 찾고 해결하는 역할로 확장되는 지점이에요.
비즈니스 목표를 이해하고 사용자 경험을 연결하는 능력 : 에이전시는 클라이언트 요구사항이 곧 목표지만 스타트업은 비즈니스 지표가 목표에요. 예를 들어 가입 전환율을 3%에서 5%로 올린다거나, 재방문율을 10% 증가시킨다거나, 상담 전환율을 개선시킨다거나 하는 비즈니스 지표를 말해요. 디자이너는 이 목표를 기준으로 ‘사용자의 어떤 경험을 개선해야 이 지표가 오를까?’를 고민할 수 있어야 해요.
협업 방식의 변화에 적응하는 능력 (애자일/스크럼) : 스타트업마다 다르긴 하지만 많은 스타트업은 애자일 방식으로 일해요. 디자인팀, 개발팀 이렇게 나뉘기 보다는 특정 기능을 기준으로 디자이너, 개발자, PM/PO가 한 팀이 되는 목적 조직의 형태가 많죠. 이 방식으로 일하는 조직에서는 디자이너가 모든 협업자와 직접 소통하고 의사결정을 해야해요. 또한 화면을 다 만들고 주는게 아닌 계속해서 함께 논의하기 때문에 ‘완성된 화면을 보여준다’는 개념보다는 ‘진행중인 화면을 계속해서 공유한다’는 개념으로 협업하게 돼요.
⑥ 결론
스타트업마다 일하는 방법도 다르고 투자 시리즈에 따라 중요한 역량도 다르기 때문에 에이전시 경험은 스타트업으로 이직할 때 무척이나 쓸모 있어요. 절대 쓸모없지 않아요.
다만 ‘좀 더 기획에 참여하고 싶다’면 위에서 제시한 역량을 갖추는게 좋아요. 그래야 스타트업을 가더라도 주도권을 가지고 사용자 경험을 설계 및 디자인하는 프로덕트 디자이너가 될 수 있거든요.
아참! 정말 중요한 말을 안했네요.
에이전시에서 스타트업으로 옮긴 모든 디자이너는 이 역량들을 ‘한꺼번에’ 갖춘 상태로 오지 않아요. 세상 그 누구도 이 역량을 한 번에 만들 수 없어요. 지금 중요한건 ‘나에게 무엇이 필요한가’를 아는 것 그 자체에요. 그러니 조급해할 필요도, 불안해할 필요도 없어요. 하나씩 해나가도 충분해요. 저도 그렇게 했는걸요.
보너스) 체크리스트
어떤 역량을 갖춰야 할지 좀 더 정확히 알고 싶다면 아래 질문에 답해보세요.
체크리스트에서 절반 이상을 체크할 수 없어도 좌절할 필요 없어요. 에이전시 구조에서는 애초에 배울 기회가 없던 영역이니 자연스러운 현상이에요. 그 공백을 이제 하나씩 메우면 되는거에요. 저도 차근 차근 메웠답니다. 혼자서 너무 어렵고 막막하다면 란란클래스를 찾아주세요. 그 공백을 위해 존재하는 클래스이니까요.
하나씩 노력하여 어느새 모두 답을 할 수 있다면 이미 ‘왜’를 설계할 수 있는 디자이너에요. 당신은 어디든 갈 수 있어요. 더 많은 기회와 영향력을 펼치러 떠나보세요! 건승을 기원합니다.
■ 문제 정의 / 데이터 기반 사고 확인
“이 기능을 왜 만들어야 하는지”를 명료하게 설명할 수 있나요?
내가 설계한 화면이 어떤 지표에 영향을 주는지 명확히 알고 있나요?
기능 개선 아이디어를 낼 때 ‘가설 → 데이터 → 검증 흐름’으로 말할 수 있나요?
“보여주기 좋은 디자인”과 “실제 사용자 행동을 바꾸는 디자인”의 차이를 예를 들어 설명할 수 있나요?
■ 사용자 플로우 / 수명주기(Lifecycle) 이해
사용자가 ‘가입 → 탐색 → 기능 사용 → 전환 → 재방문’ 하는 전체 흐름을 설명할 수 있나요?
특정 화면이 이 흐름 중 어디에 위치하고, 어떤 역할을 해야 하는지 말할 수 있나요?
화면이 아닌 플로우 단위로 문제를 정의하는 경험이 있나요?
■ 정책 이해
우리 제품 내의 필터링 규칙과 같은 기술 정책을 이해하고 설명할 수 있나요?
우리 서비스의 환불 정책과 같은 운영 요소를 이해하고 설명할 수 있나요?
■ MVP / 빠른 실험·검증 능력
•
“지금 상황에서 최소 기능(MVP)을 만든다면 어떤 기능부터 만들지” 설명할 수 있나요?
•
디자인 완성도보다 시장 검증 속도가 우선되는 상황에서 적절히 판단할 수 있나요?
■ 비즈니스 목표와 연결된 사고
내가 만든 화면이 가입/전환/이탈/재방문 중 어떤 지표에 영향을 주는지 추적할 수 있나요?
디자이너가 해결해야 할 문제를 비즈니스 목표 기준으로 우선순위를 정할 수 있나요?
“이 기능의 성공 기준”을 스스로 정의할 수 있나요?
■ 협업 능력
PM, 개발자와 대화할 때 핵심 기준(지표·정책·제약) 으로 이야기할 수 있나요?
작업중이던 화면을 수시로 팀원들과 공유할 수 있나요?
이해관계자에게 내가 만든 UX/UI의 이유를 설명할 수 있나요?