프로세스란 무엇인가

프로세스는 하나의 서비스를 처음부터 끝까지 구성하는 모든 상황과 상호작용의 흐름을 정리하는 과정입니다. 단순히 기능을 나열하는 것이 아니라, 서비스 안에서 발생할 수 있는 다양한 경우의 수를 순서에 따라 체계적으로 구성하여 사용자가 합리적이고 효율적으로 이용할 수 있도록 만드는 설계 구조를 의미합니다. 쉽게 말해, 서비스가 A부터 Z까지 어떤 흐름으로 이어지는지를 논리적으로 제공하는 구조입니다. 이를 통해 사용자는 각 단계에서 무엇을 해야 하는지, 어떤 판단을 내려야 하는지 자연스럽게 이해할 수 있습니다. 기획 문서에서 스토리보드를 작성할 때 논리 흐름을 시각화하는 경우가 많은데, 이 역시 프로세스를 표현하는 방식 중 하나입니다. 

프로세스는 크게 두 가지로 나뉩니다.

• 구조적 프로세스
• 논리적 프로세스

그리고 논리적 프로세스는 구조적 프로세스에 종속됩니다. 구조적 프로세스가 서비스의 전체 틀이라면, 논리적 프로세스는 그 틀 안에서 각 상황별로 어떻게 작동하는지를 정의하는 세부 흐름입니다.
하나의 페이지 안에도 여러 개의 논리 프로세스가 존재할 수 있으며, 예를 들어 회원가입 페이지에서는 입력 완료 여부, 필수 항목 체크 여부, 오류 발생 여부 등에 따라 버튼 활성화나 메시지 노출이 달라집니다. 이러한 요소들이 모두 논리적 프로세스에 해당합니다.

 

구조적 프로세스 설계

구조적 프로세스는 서비스의 전체 틀을 정의하는 설계입니다. 서비스가 어떤 단위로 구성되어 있고, 어떤 순서로 이어지는지를 한눈에 파악할 수 있도록 시각적으로 정리하는 과정입니다. 많은 기획자들이 논리 프로세스는 비교적 잘 작성하지만, 구조적 프로세스를 생략하는 경우가 적지 않습니다. 그러나 구조적 프로세스는 디자이너와 개발자가 서비스의 전체 규모를 이해하는 데 중요한 기준이 됩니다.

예를 들어 회원가입 서비스를 설명한다고 가정해 보겠습니다. 구조적 프로세스 관점에서는 다음과 같이 정의할 수 있습니다.

• 약관 동의 페이지
• 정보 입력 페이지
• 가입 완료 페이지

이처럼 단위 페이지 단위로 구성이 정리되어 있어야 전체 흐름을 빠르게 파악할 수 있습니다.

서비스는 단일 기능으로 이루어지지 않습니다. 가입, 결제, 멤버십, 마일리지, 쿠폰, 고객센터 등 각각의 단위 서비스가 존재하며, 이 각각이 어떤 구조로 구성되어 있는지를 정리해 두어야 전체 서비스의 규모와 범위를 명확히 이해할 수 있습니다. 기능 정의서나 IA 문서를 통해서도 정리는 가능하지만, 내용이 많아질수록 한눈에 파악하기 어려워집니다. 따라서 이를 시각화하여 구조를 명확히 보여주는 작업이 필요합니다.

 

논리 프로세스

논리 프로세스는 서비스의 흐름을 순서도로 표현한 것입니다. 사용자의 액션에 따라 서비스가 어떻게 반응하는지를 시각적으로 정리하는 설계 방식입니다. 논리 프로세스에는 여러 도형이 사용됩니다.

논리 프로세스에는 여러 도형이 사용됩니다.

• 시작 / 종료
• 페이지
• 버튼(BT)
• 판단(YES/NO)
• 처리
• 데이터 저장
• 시간 지연 등

시작과 종료

모든 논리 프로세스에는 반드시 시작과 종료가 각각 하나씩 존재해야 합니다. 시작과 종료가 여러 개로 표현되는 것은 올바른 방식이 아닙니다.

페이지 도형

웹 또는 모바일 환경에서 하나의 페이지를 표현할 때 사용하는 도형입니다. 예를 들어 사용자가 이벤트 페이지에 진입했다면, 그 페이지 자체를 하나의 도형으로 표현합니다. 단, 단순 얼럿 메시지처럼 별도 페이지로 보기 어려운 요소는 이 도형을 사용하지 않습니다.

버튼(BT)

BT는 Button의 약자입니다. 사용자가 클릭을 통해 서비스와 상호작용하는 지점을 의미합니다. 버튼은 단순 UI 요소가 아니라, 사용자와 시스템을 연결하는 커넥션 역할을 합니다. 사용자가 버튼을 클릭하면 데이터가 저장되거나, 다음 페이지로 이동하거나, 특정 결과가 출력됩니다. 이 연결 지점을 논리 프로세스에서 BT로 표시합니다.

판단 도형 (YES / NO)

판단 도형은 흐름이 분기되는 지점입니다. 여기서 중요한 점은, YES와 NO가 단순히 긍정과 부정을 의미하지 않는다는 것입니다. 논리 프로세스에서 YES는 정상적인 흐름, NO는 비정상적인 흐름 또는 예외 상황을 의미합니다.

예를 들어 이벤트 참여 여부 판단에서

• 아직 참여하지 않은 사용자의 참여 → YES (정상 흐름)
• 이미 참여한 사용자의 재참여 시도 → NO (예외 흐름)

이처럼 YES는 항상 긍정적인 결과가 아니라 정상 흐름을 의미합니다.

수평형과 수직형

논리 프로세스는 수평으로 작성할 수도 있고 수직으로 작성할 수도 있습니다. 어느 방식이 정답은 아닙니다. 중요한 것은 일관성입니다. 하나의 기획서에서 수평을 정상 흐름, 수직을 예외 흐름으로 정했다면 문서 전체에서 동일한 기준을 유지해야 합니다. 혼용되면 보는 사람이 혼란을 느낄 수 있습니다.

 

논리 프로세스의 중요성

화면 설계는 경우에 따라 생략될 수 있지만, 논리 프로세스는 반드시 포함되어야 합니다. 개발자는 화면보다 먼저 로직을 이해해야 하기 때문입니다. 논리 프로세스는 서비스가 어떻게 작동하는지를 설명하는 핵심 도구입니다.

프로세스 설계 포인트

프로세스를 설계할 때는 다양한 요소를 고려해야 합니다.

• 연령

• 성별

• 사용자 유형 (초보자, 헤비 유저)

• 운영 정책

• 지역적 특성

이러한 특성에 따라 동일한 서비스라도 설계 방식이 달라질 수 있습니다.

또한 워딩, 표현 방식, 긍정/부정 문구 사용 여부 등도 사용자 경험에 영향을 미칩니다.
최근에는 UX 라이팅이 별도 영역으로 다뤄지지만, 프로세스 설계 단계에서 함께 고민해야 할 요소입니다.

다만 모든 요소를 과도하게 반영하면 로직이 복잡해집니다.
기획이 복잡해질수록 개발과 QA 과정도 복잡해지고, 오류 가능성이 높아집니다.

따라서 프로세스는 간결하고 명확하게 설계하는 것이 중요합니다.

 

프로세스의 2단계 정의

프로세스는 두 단계를 거쳐 설계해야 합니다.

• 1단계: 완벽성을 기한 프로세스
• 2단계: 분산 및 간소화를 통한 프로세스

1단계 – 완벽성을 기한 프로세스

처음에는 가능한 모든 상황과 요소를 고려하여 완전한 프로세스를 설계합니다.
초보나 중급 단계에서는 복잡한 예외 상황까지 모두 포함해 설계하는 과정이 중요합니다.

이를 통해 전체 흐름을 정확히 이해하고, 서비스의 깊이를 확보할 수 있습니다.

2단계 – 분산 및 간소화

완전한 프로세스가 정리되면, 이를 기반으로 분산시키고 간소화합니다. 이 과정은 사용자와 개발자 모두에게 이점을 제공합니다.

사용자 측면

• 사용자 액션 감소
• 진입 장벽 감소
• 편의성 향상

개발 측면

• 로직 단순화
• 코드 안정성 향상
• 유지보수 용이
• 개발 기간 단축

결국 이 접근은 사용자 편의성과 개발 효율성을 동시에 높이기 위한 전략입니다.