B2B SaaS의 UI/UX를 외부에 맡길지 말지는 "예산이 되는가"의 문제가 아닙니다. 무엇을 맡기고 무엇을 안에 남기느냐의 문제입니다.
전부 맡기면 조직에 아무것도 안 남고, 전부 안에서 하면 지금 구조를 의심하지 못합니다. 가장 좋은 결과는 대개 그 사이에 있습니다.
30초 요약
- •구조를 의심하는 일은 밖이 빠릅니다. 내부는 지금 구조를 당연하게 여기기 쉽습니다.
- •유지와 확장은 안이 빠릅니다. 매일 쓰는 사람이 이깁니다.
- •그래서 IA·핵심 화면은 외부, 반복 화면과 운영은 내부가 현실적인 경계입니다.
- •산출물의 형태를 계약 전에 합의하세요. 이미지만 받으면 구현에서 의도가 흩어집니다.
- •한 번에 전체를 발주하지 마세요. IA 진단만 먼저 하면 나머지 판단이 쉬워집니다.
1. 밖이 잘하는 일, 안이 잘하는 일
밖이 잘하는 것 — 구조를 의심하기
내부 팀은 제품을 가장 잘 압니다. 그게 강점이면서 동시에 약점입니다. 매일 보는 구조는 당연해 보이기 때문입니다. "왜 이 기능이 여기 있죠?"라는 질문을 밖에서 하는 편이 빠르고, 사내 정치에서도 자유롭습니다.
밖이 잘하는 것 — 다른 제품에서 본 패턴
여러 SaaS를 다뤄본 팀은 "이 단계에서 대개 이런 문제가 생긴다"를 압니다. 시행착오를 건너뛸 수 있습니다.
안이 잘하는 것 — 도메인과 예외
업무의 예외 규칙, 고객사별 특수 조건, 규제. 이건 밖에서 절대 못 따라갑니다. 외부가 이걸 다 이해할 때까지 기다리면 비용이 훨씬 커집니다.
안이 잘하는 것 — 이후의 유지
만든 뒤가 훨씬 깁니다. 화면은 계속 늘어나고 규칙은 계속 바뀝니다. 그걸 매번 외부에 맡기면 속도가 안 납니다.
2. 현실적인 경계선
저희가 권하는 기본 배분은 이렇습니다. 조직 상황에 따라 조정하시면 됩니다.
- •외부 — IA 재설계 구조를 새로 짜는 일. 가장 효과가 크고 가장 밖이 잘합니다
- •외부 — 핵심 화면 설계 대시보드와 주요 플로우. 기준이 되는 화면들
- •외부 — 디자인 시스템의 뼈대 규칙과 원칙. 컴포넌트를 전부 만들 필요는 없습니다
- •내부 — 반복 화면 기준 화면이 정해지면 나머지는 안에서 훨씬 빠릅니다
- •내부 — 운영·어드민 업무를 아는 사람이 만들어야 합니다. 다만 원칙은 함께 정합니다
여기서 핵심은 "기준이 되는 것"만 밖에서 만들고 나머지는 안에서 복제하는 구조입니다. 그래야 조직에 역량이 남습니다.
3. 산출물을 계약 전에 합의하세요
가장 자주 생기는 분쟁이 여기서 납니다. "화면 시안"만 받으면 구현 단계에서 의도가 흩어집니다. 최소한 아래는 포함되어야 합니다.
- •구조 문서 — 메뉴 체계, 역할별 접근 범위, 화면 간 이동
- •상태 정의 — 비어 있을 때, 로딩 중, 오류, 권한 없음. 이게 빠지면 개발이 임의로 만듭니다
- •컴포넌트 규칙 — 버튼·입력·표의 종류와 쓰임. 시스템의 씨앗이 됩니다
- •반응형 기준 — 어느 폭에서 무엇이 바뀌는지
상태 정의가 특히 자주 빠집니다. 정상 화면만 그려두면 실제 서비스에서 마주치는 화면의 상당수가 설계 없이 만들어집니다.
4. 한 번에 전체를 발주하지 마세요
전체 고도화를 통으로 맡기면 세 가지 위험이 있습니다. 금액이 커지고, 중간에 방향을 못 바꾸고, 맞지 않는 팀이어도 되돌리기 어렵습니다.
① IA 진단만 먼저 → ② 결과를 보고 범위 결정 → ③ 핵심 화면 → ④ 나머지는 내부
①번만 해도 무엇이 문제인지, 얼마나 큰일인지가 명확해집니다. 그리고 그 과정에서 상대 팀의 일하는 방식을 확인할 수 있습니다. 적은 금액으로 파트너를 검증하는 방법이기도 합니다.
5. 파트너를 고를 때 볼 것
- •SaaS를 다뤄봤는가 — 홈페이지·앱과 설계 원리가 다릅니다. 포트폴리오에 관리자 화면이 있는지 보세요
- •구조를 먼저 묻는가 — 첫 미팅에서 화면 수부터 묻는다면 고도화가 아니라 시안 작업입니다
- •개발 제약을 이해하는가 — 구현 불가능한 설계는 결국 개발자가 임의로 바꿉니다
- •산출물을 미리 보여주는가 — 샘플 문서를 요청해 보세요. 상태 정의가 있는지 확인하시면 됩니다
- •끝난 뒤를 이야기하는가 — 인수인계와 내부 확장 방법까지 말하는 팀이 좋은 팀입니다
자주 묻는 질문
내부 디자이너가 있는데 외부에 맡기면 사기가 떨어지지 않을까요?
역할을 명확히 하면 오히려 반대인 경우가 많습니다. 구조를 의심하는 일은 밖, 이후의 확장과 운영은 안으로 나누면 내부 디자이너는 기준을 얻고 반복 작업에서 벗어납니다. 문제가 되는 건 역할을 안 나누고 같은 일을 두 번 시킬 때입니다.
개발까지 함께 맡기는 게 나을까요?
제품의 지속성을 생각하면 개발은 내부에 있는 편이 좋습니다. 다만 초기이거나 인력이 없다면 함께 진행하고, 그 경우 인수인계 범위를 계약에 명시하세요.
비용은 어떻게 잡아야 하나요?
범위에 따라 크게 달라서 단일 금액을 말씀드리기 어렵습니다. 다만 IA 진단 → 핵심 화면 → 확장 세 단계로 나눠 각각 별도로 판단하시면 예산 통제가 훨씬 쉬워집니다.
정리하면
외주의 성패는 파트너 선택보다 경계를 어떻게 긋느냐에 달려 있습니다.
구조와 기준 화면은 밖에서, 반복과 운영은 안에서. 산출물에 상태 정의가 들어가는지 계약 전에 확인하고, 전체를 통으로 발주하는 대신 IA 진단부터 시작하세요.
함께 읽으면 좋은 글
제품 구조부터 점검이 필요하시면 상담 신청을 남겨주세요. 범위와 예상 기간을 먼저 정리해 드립니다. 진행 방식과 포함 범위는 요금제 페이지에서 확인하실 수 있습니다.
이 글은 EasySpark 허수진 대표의 실무 내용이며, 제품 단계와 조직 구성에 따라 다를 수 있어 결과를 보장하지 않습니다. 우리 제품에 맞는 개선 방향이 궁금하시다면 편하게 상담 신청해주세요.
