프로세스가
당신의 안도감을 결정한다
보이지 않는 흐름을 가시화하는 법
회의가 끝났다. 결정은 내려졌고, 기능도 정의되었고, 일정도 공유되었다.
그런데 이상하게 불안했다. 이유는 단순했다. 다음 단계가 예측되지 않았기 때문이다.
"이번에는 얼마나 걸릴까요?"
대기업에서 내부 투자를 받아 시스템을 개발하는 프로젝트를 다룰 때, 가장 많이 들었던 질문이다.
규모가 큰 조직일수록 사업 기획부터 심의, 계약, 개발, 검증까지 촘촘한 프로세스가 존재한다.
관여하는 부서만 네다섯 곳이 넘고, 각 부서가 서로 다른 기준과 다른 언어로 같은 과제를 평가한다.
이 상황에서 "얼마나 걸리느냐"는 기능에 대한 질문이 아니다. 불안에 대한 질문이다.
사람은 오늘 해야 할 업무량이 많아서 힘든 것이 아니라, 앞으로 얼만큼 해야 될지, 언제 끝날지 ‘몰라서’ 힘들다.
복잡한 게 아니라, 예측 불가능한 것이다
많은 사람들이 말한다. "B2B ¹⁾는 복잡해서 힘들다."
하지만 내가 현장에서 본 문제는 복잡함이 아니었다. 예측 불가능성이었다.
SOP²⁾는 있는데, 실제 업무와 맞지 않는다.
문서는 존재하지만 어디에 있는지 아무도 모른다.
예상 소요 시간은 경험 많은 선배에게 물어봐야 알 수 있다.
특정 담당자가 회신해야 다음 단계가 시작되고, 그 사람이 출장이면 전체 일정이 멈춘다.
리더십이 바뀌면 기준도 바뀐다.
이것은 복잡한 것이 아니다. 이것은 사람 중심 운영 구조다.
프로세스가 문서로 존재해도, 실제로는 사람이 시스템의 역할을 하고 있는 상태.
"그건 김 과장님이 알아." "이건 팀장님이 승인해줘야 해." "예전에는 이렇게 했었어."
이 조직에서 흐름은 시스템에 있지 않고 사람의 기억 속에 있다.
여기서 한 가지 더 드러나는 현실이 있다.
사람들은 프로세스라고 하면 선형적인 흐름을 떠올린다.
A 다음에 B, B 다음에 C. 하지만 실제 B2B 환경의 업무 프로세스는 그런 깔끔한 선이 아니다.
어디로 튈지 모르는, 여러 갈래로 엉켜 있는 끈.
착종(錯綜)형 프로세스에 가깝다.
승인이 반려되면 두 단계 전으로 돌아가고,
중간에 다른 부서의 검토가 끼어들고, 예외 케이스가 발생하면 프로세스 자체가 분기한다.
이 현실을 직시하지 않으면, 아무리 깔끔한 프로세스를 문서로 정의해도 현장에서 작동하지 않는다.
프로세스는 통제가 아니라 안도감이다
프로세스라는 단어를 들으면 많은 사람들이 관료주의적 절차나 불필요한 형식을 떠올린다.
하지만 이 글에서 말하는 프로세스는 그런 종류의 것이 아니다.
프로세스란 '다음에 무엇을 해야 하는지'가 명확하게 설계된 상태를 뜻한다.
그 상태가 확보되면 사람은 안도한다. 지금 내가 어디에 있는지 보이고, 다음 단계가 무엇인지 명확하고,
예상 일정이 가시화되어 있고, 대체 경로가 존재한다면 사람은 과도하게 방어적으로 행동하지 않는다.
원칙 3에서 다뤘던 F45의 안도감을 기억해 보자. 스튜디오에 도착하면 오늘의 운동이 이미 정해져 있다.
무엇을 할지 고민하는 데 에너지를 쓰지 않으니, 45분의 전부를 실행에 쏟을 수 있었다.
그 안도감의 정체는 프로세스였다.
프로세스는 사람을 통제하는 장치가 아니다.
예측 가능성을 만드는 장치이며, 예측 가능성이 생길 때 사람은 비로소 안도감을 느낀다.
UX 디자이너는 왜 여기까지 봐야 하는가
"그건 UX 디자이너의 일이 아니지 않나?"
이 질문은 자주 나온다. 프로세스 설계, 조직 간 판단 흐름, 이해관계자 조율.
이런 것들은 전통적으로 PI(Process Innovation) ³⁾나 경영 컨설턴트의 영역으로 여겨져 왔다.
UX 디자이너에게 기대되는 일은 화면을 설계하고, 사용성을 검증하고, 프로토타입을 만드는 것이라고 생각하는 사람이 여전히 많다. 하지만 현장에서는 이런 일이 벌어진다. 화면을 설계하기 위해 사용자를 관찰하고 인터뷰하다 보면, 표면적인 불편함 뒤에 있는 진짜 문제가 드러난다. 원칙 4에서 이야기했던 것처럼, 구매 담당자가 "승인 과정이 번거롭다"라고 말했지만 실제 문제는 기록이 휘발되는 구조였고, 건설 현장의 작업자가 "사진 전송이 불편하다"라고 했지만 실제 문제는 심리적 저항감이었다.
이런 맥락의 문제를 발견했을 때, UX 디자이너는 두 가지 선택지가 있다.
"이건 내 영역이 아니니 화면만 고치겠다"라고 할 수 있다. 하지만 그러면 진짜 문제는 그대로 남고, 화면을 아무리 개선해도 사용자의 불만은 반복된다. 결국 전체 흐름을 봐야 한다. 업무가 어떤 경로로 흘러가고, 어디서 병목이 생기며, 어떤 판단이 누구의 책임 아래 있는지. 이 흐름을 파악하지 않으면 화면 설계 자체가 허공에 뜬다.
이것은 역할의 확장이 아니라, 화면을 제대로 설계하기 위한 전제 조건이다.
전체 흐름을 보지 않으면 부분의 설계가 어긋난다. 그래서 UX 디자이너가 프로세스까지 보게 되는 것이다.
물론 프로세스의 모든 것을 UX 디자이너가 담당하는 것은 아니다. 조직 경험 전체를 설계하는 일은 AX(Agent Experience)⁴⁾나 EX(Employee Experience), 변화관리 전문가의 영역과 겹친다. 하지만 진짜 문제가 조직의 판단 흐름에 있다면, 거기까지 들여다보고 설계에 반영하는 것도 때로는 필요하다.
경계에 서서 "여기까지만 내 일"이라고 선을 긋는 순간, 표면적인 개선만 반복하게 된다.
전체 흐름을 놓치면 결국 꼬인다
UX에서 가장 자주 벌어지는 오류가 있다.
결과물(Output)은 설계하면서, 그 결과물에 도달하는 흐름(Flow)은 설계하지 않는 것이다.
대시보드를 만든다고 하자. 어떤 데이터를 보여줄지, 차트의 형태는 무엇으로 할지를 논의한다. 하지만 그 대시보드에 데이터가 어떤 경로로 도달하는지, 누가 입력하고 검증하는지, 잘못된 값이 들어왔을 때 어떤 단계에서 걸러지는지는 논의되지 않는 경우가 많다. 데모에서는 매끄럽게 작동하지만, 현장에 투입되면 일주일 안에 "이 숫자가 왜 이렇게 나왔는지 모르겠다"는 혼란이 시작된다.
온보딩도 마찬가지다. 온보딩 프로그램은 조직의 첫 UX다.
잘 설계되어 있다면, 신규 구성원은 "이 조직은 이렇게 움직이는구나"를 빠르게 이해한다. 하지만 온보딩이 단순한 교육 세션에 그친다면, 신규 구성원은 선배에게 물어보고, 슬랙을 뒤지고, 예전 문서를 복사하는 과정을 반복한다. 이것은 학습이 아니라 비효율의 반복이다.
이런 문제들의 공통점이 있다. 전체 흐름을 보지 않고 부분만 설계했기 때문에 발생한다는 것. 전체 흐름을 먼저 가시화하면, 비로소 무엇을 디지털 서비스로 담을 수 있고, 무엇은 담을 수 없는지가 드러난다.
조직 문화의 문제, 개발 제약사항, 부서 간 이해관계, 시스템 간 연계 불가능성. 이런 것들은 화면으로 해결되지 않는다. 하지만 그것을 확인하는 것 자체가 설계의 출발점이다. 기능으로 구현이 유효한 것들을 가려낸 뒤에야, IA ⁵⁾를 설계하고 사용자의 프로세스를 개선할 수 있다.
AI는 워크플로우의 어디에 들어가야 하는가
이 문제는 AI가 업무 프로세스에 들어오면서 한 차원 더 복잡해졌다.
AI가 조직에 도입될 때, 논의는 대부분 이렇게 시작된다.
"이 업무를 AI로 자동화할 수 있을까?" 하지만 이 질문에는 중요한 전제가 빠져 있다. 자동화한다는 것은 기존에 인간이 수행하던 판단을 AI에게 위임한다는 뜻이다. 그렇다면 그 판단이 워크플로우 ⁶⁾ 전체에서 어떤 위치에 있는지, 앞뒤로 어떤 단계와 연결되어 있는지를 먼저 파악해야 한다.
대규모 AI 도입 프로젝트에서 20개 넘는 과제를 동시에 검토한 적이 있다. 설비 이상 감지, 데이터 분류, 문서 자동화 등 과제는 대부분 "AI로 효율화하겠다"는 목표를 갖고 출발했다. 하지만 가장 먼저 한 일은 바로 AI가 적용된 서비스를 만드는 것이 아니었다. 각 업무의 현재 워크플로우를 가시화하는 것이었다. 데이터가 어디에서 생성되어 어디로 흘러가는지를 추적하고, AI가 개입할 수 있는 지점과 반드시 인간이 판단해야 하는 지점을 구분하고, 그중에서 AI를 적용했을 때 가장 효율이 높을 구간을 선정해야 했다.
하나의 AI로 모든 업무를 해결한다는 것은 환상이다. 워크플로우를 태스크 단위로 쪼개고, 각 태스크에서 AI가 할 수 있는 것과 할 수 없는 것, 기술적 제약이 존재하는지를 확인해서 커버리지를 파악해야 한다. AI를 잘 도입하는 조직과 그렇지 못한 조직의 차이는 알고리즘의 정확도가 아니라, 워크플로우 전체를 가시화하고 그 위에 AI의 역할을 배치하는 능력에 있다.
워크플로우 다이어그램이라는 공통 언어
그래서 UX에서는 화면을 그리기 전에 워크플로우 다이어그램⁷⁾을 먼저 그린다.
앞서 언급한 투자 심의 프로세스에서 경험한 것이 정확히 이것이었다. 과제를 기획하는 부서, 비용을 검토하는 부서, 개발 공수를 산정하는 부서, IT 거버넌스를 담당하는 부서. 각각이 서로 다른 기준으로 같은 과제를 평가하고 있었다. 더 흥미로운 것은, 같은 의미를 서로 다른 용어로 부르는 경우가 빈번했다는 점이다. 레거시 시스템에서 쓰이던 명칭과 현재 조직에서 쓰는 명칭이 다르고, 부서마다 동일한 개념을 다른 단어로 지칭한다. 그래서 워크플로우를 가시화하기 전에 먼저 프로토콜 ⁹⁾을 확인하는 것. 다시 말해, 각 단계를 어떤 용어로 부르고, 어떤 기준으로 판단하는지를 맞추는 것이 선행되어야 한다.
이 상태에서 화면을 먼저 그리면, 각 부서가 자기 관점에서만 화면을 평가하고 누구도 만족하지 못하는 결과물이 나온다. 여러 관점에서 전체 프로세스를 가시화한 뒤에야, 부서 간 관점 차이를 구조적으로 정리할 수 있었다. 워크플로우 다이어그램은 단순한 순서도가 아니다. 서로 다른 관점을 가진 이해관계자들이 하나의 흐름 위에서 대화할 수 있게 만드는 공통 언어다.
워크플로우 다이어그램이 존재하면 세 가지가 달라진다.
첫째, 공백이 드러난다. "이 단계에서 저 단계로 넘어갈 때 누가 책임지는가?"라는 질문이 자연스럽게 발생한다.
둘째, 중복이 보인다. 같은 데이터를 서로 다른 부서에서 각각 입력하고 있는 비효율이 가시화된다.
셋째, 기능으로 담을 수 있는 것과 담을 수 없는 것이 구분된다. 이 구분이 되어야 IA 설계가 가능하고, 앞으로 프로덕트가 어떤 방향으로 발전해야 하는지 로드맵을 그릴 수 있다.
그리고 한 가지가 더 있다. 숨어 있던 프로세스가 발견된다.
워크플로우를 가시화하다 보면, 조직 내 누구도 명시적으로 인지하지 못했던 업무 흐름이 드러나는 경우가 있다. 공식 프로세스에는 존재하지 않지만, 현장에서는 반복적으로 수행되고 있는 일.
예를 들어, 생산 라인에서 앞 공정의 물량이 차면 다음 공정으로 자동 이관되는 것이 시스템상의 흐름이다. 대시보드의 막대그래프에서도 그렇게 보인다. 그런데 실제 현장에서는 자동으로 넘기지 않았다. 담당자가 메신저나 전화로 다음 공정 담당자에게 직접 확인한 뒤에야 이관이 이루어지고 있었다. 시스템에는 없는 단계가 사람 사이에 존재하고 있었던 것이다. 또 다른 예로, 시스템 장애가 발생했을 때 어떤 시스템이 원인인지를 추적할 수 있는 구조가 없어서, 모든 시스템 담당자가 참여하는 단체 채팅방에서 "혹시 우리 쪽 문제인가요?"를 돌아가며 확인하는 방식으로 원인을 찾고 있었다.
이런 히든 플로우(Hidden Flow)⁸⁾는 공식 문서에는 없지만 실제로는 업무의 일부이며, 이것을 발견하는 것 자체가 프로세스 개선의 중요한 출발점이 된다.
삶의 프로세스
이 원리는 조직에만 해당되지 않는다.
우리의 하루도 하나의 워크플로우다. 어떤 메일을 먼저 확인할 것인가, 어떤 회의에 에너지를 쏟을 것인가, 퇴근 후 한 시간을 운동에 쓸 것인가 아이와의 시간에 쓸 것인가. 이 판단들이 매번 처음부터 이루어진다면, 하루가 끝날 때쯤 남는 것은 피로뿐이다. 원칙 1에서 이야기했던 "잘 살고 있는데도 흔들리는" 상태가 바로 이것이다.
반대로, 자신만의 프로세스가 설계되어 있는 사람은 다르다. 아침 루틴이 정해져 있고, 업무의 우선순위 기준이 있으며, 퇴근 후의 에너지 배분 원칙이 있다. 프로세스가 잡혀 있으니 판단 에너지가 절약되고, 절약된 에너지가 진짜 중요한 결정에 쏠린다.
여기서 한 걸음 더 나가 보자. 루틴이 잡혀 있고, 에너지를 중요한 곳에 쏟을 수 있게 되었다면?
그다음 질문은 이것이다. 그 에너지를 어디에 쏟을 것인가.
그 방향이 정의되어 있지 않으면, 루틴은 효율적이지만 목적지가 없는 상태가 된다.
조직에서는 이 문제를 OKR¹⁰⁾로 해결한다. 목표(Objective)를 먼저 정의하고, 그 목표가 달성되었는지를 확인할 수 있는 핵심 결과(Key Result)를 설정한다. 그리고 모든 활동을 이 기준에 맞춰 정렬한다. 목표와 연결되지 않는 활동은 아무리 바쁘더라도 성과가 아니다.
삶에도 같은 구조가 적용된다. 내가 올해 이루고 싶은 것은 무엇인가. 그것이 이루어졌다는 것을 어떤 기준으로 확인할 것인가. 지금 하고 있는 활동들은 그 목표와 실제로 연결되어 있는가. 우리는 조직의 프로세스는 분석하면서, 정작 자신의 삶에는 이 정도의 설계를 적용하지 않는 경우가 많다.
이것이 이 책이 말하는 Self UX다. 제품의 사용자 경험을 설계하듯, 자신의 삶의 경험을 설계하는 것.
프로세스로 판단 에너지를 확보하고, 확보된 에너지를 명확한 목표에 정렬시킬 때,
비로소 흔들리지 않는 방향이 만들어진다.
프로세스는 자유를 빼앗는 것이 아니다.
프로세스는 불필요한 판단을 줄여줌으로써, 정말 중요한 판단에 집중할 자유를 만들어 준다.
전체를 보는 것이 부분을 살리는 법이다
프로세스는 업무를 늘리는 장치가 아니다. 예측 가능성을 만드는 장치다. 그리고 그 프로세스를 설계하려면, 전체 흐름을 먼저 봐야 한다. 전체를 보지 않으면 부분이 꼬인다. 전체를 본 뒤에야, 무엇을 디지털 서비스로 담을 수 있는지, 무엇은 화면 밖에서 해결해야 하는지, 어디에 AI를 배치해야 하는지가 보인다. 그 위에 IA를 설계하고, 사용자의 흐름을 개선하고, 프로덕트의 방향을 잡는 것. 이것이 UX가 화면을 넘어서하는 일이다.
원칙 4에서 우리는 구조(IA)에 집중해야 한다는 것을 확인했다. 원칙 5에서 한 걸음 더 나아간다.
그 구조를 세우려면, 먼저 흐름 전체를 볼 수 있어야 한다.
Invisible to Visible. 보이지 않는 것을 보이게 만드는 일이 모든 설계의 출발점이다.
그렇다면 그 흐름 안에서, 모든 단계를 유지해야 할까. 모든 기능이 필요한가.
진짜 해결해야 할 '일'은 무엇인가. 다음 원칙에서 다룬다.
사람의 선택과 행동을 설계합니다. 비즈니스, 기술, 사람 — 셋의 교차점에서 일합니다.
Invisible to Visible. © Novah
주석
¹⁾ B2B(Business to Business) — 기업 간 거래를 위한 제품·서비스 영역. 다수의 이해관계자, 복잡한 승인 체계, 데이터 거버넌스 등 조직 단위의 의사결정 구조가 설계의 핵심 변수가 된다.
²⁾ SOP(Standard Operating Procedure) — 표준 운영 절차. 업무 수행의 일관성을 위해 문서화한 절차 기준. SOP가 존재한다고 해서 실제 업무가 그대로 흘러가는 것은 아니며, SOP와 현실의 괴리가 프로세스 설계의 출발점이 되는 경우가 많다.
³⁾ PI(Process Innovation) — 프로세스 혁신. 조직의 업무 프로세스를 분석하고 재설계하는 전문 영역. 전통적으로 경영 컨설팅의 영역으로 여겨져 왔으며, UX 디자인과는 별도의 직군으로 구분된다. 다만 디지털 제품 설계 과정에서 두 영역이 겹치는 지점이 점점 늘어나고 있다.
⁴⁾ AX(Agent Experience) / EX(Employee Experience) — AX는 AI 에이전트와 인간이 협업하는 경험을 설계하는 영역으로, 최근 AI 도입이 확산되면서 주목받고 있는 개념이다. EX는 임직원의 업무 경험 전반을 설계하는 영역이다. 두 개념 모두 전통적 UX의 범위를 넘어서는 조직 차원의 경험 설계에 해당한다.
⁵⁾ IA(Information Architecture) — 정보 설계. 원칙 4에서 다뤘듯, 제품 내에서 정보의 조직, 분류, 탐색 구조를 설계하는 뼈대에 해당한다.
⁶⁾ 워크플로우(Workflow) — 조직 내에서 업무가 처리되는 전체 흐름. 누가 어떤 단계에서 어떤 정보를 기반으로 판단을 내리고, 그 판단이 다음 단계에 어떤 영향을 미치는지를 포함하는 구조적 개념이다. 사용자 여정(User Journey)이 한 사람의 경험 흐름을 다루는 반면, 워크플로우는 조직 전체의 판단 흐름을 다룬다. 다만 B2B 환경에서는 임직원(업무 담당자)을 대상으로 사용자 여정을 적용하는 경우도 있다.
⁷⁾ 워크플로우 다이어그램(Workflow Diagram) — 업무나 서비스의 전체 흐름을 시각화한 도구. 각 단계에서 누가 어떤 판단을 내리고, 어떤 데이터가 이동하며, 어떤 조건에서 분기가 발생하는지를 구조적으로 표현한다.
⁸⁾ 히든 플로우(Hidden Flow) — 공식 프로세스 문서에는 정의되어 있지 않지만, 현장에서 실제로 반복 수행되고 있는 비공식 업무 흐름. 시스템 간 연동 부재로 인한 수기 검증, 부서 간 비공식 조율 등이 대표적이다. 워크플로우를 가시화하는 과정에서 이런 히든 플로우가 발견되며, 이것을 식별하는 것 자체가 프로세스 개선의 핵심 출발점이 된다.
⁹⁾ 프로토콜(Protocol) — 이 글에서의 프로토콜은 통신 규약이 아니라, 조직 내에서 동일한 개념을 어떤 용어로 부르고, 어떤 기준으로 판단하는지에 대한 합의를 뜻한다. 부서마다 같은 의미를 다른 단어로 지칭하는 경우가 빈번하며, 이 용어의 불일치가 해소되지 않으면 워크플로우 가시화 자체가 어려워진다.
¹⁰⁾ OKR(Objectives and Key Results) — 목표와 핵심 결과. 조직이나 개인이 달성하고자 하는 목표(Objective)를 먼저 정의하고, 그 목표의 달성 여부를 측정할 수 있는 구체적인 핵심 결과(Key Results)를 설정하는 프레임워크. 인텔에서 시작되어 구글 등 글로벌 기업에서 채택한 목표 관리 방법론이다. 모든 활동이 목표와 정렬되어 있는지를 점검하는 데 핵심적인 기준을 제공한다.