UX 기획자에게 Computational Thinking이 필요한 이유

 

서비스를 기획하고 설계하다 보면 개발자와의 커뮤니케이션에서 벽을 느낄 때가 종종 있습니다.

 

 

 

"이 화면에서는 어떤 기준으로 정렬해야 하나요?"

 

"이 데이터의 필수값은 무엇인가요?"

 

"해당 정보는 어떤 형식으로 저장되어야 하나요?"

 

 

 

 

이런 질문이 꼬리에 꼬리를 물면,

 

분명 간단한 기능이라 생각했는데 구현은 예상보다 훨씬 복잡해집니다.

 

UX 기획 실무에서 이런 일은 흔합니다.

 

그렇다면 왜 이런 간극이 생길까요?

 

 

 

이 질문에 대한 실마리는 'Computational Thinking'이라는 개념에서 찾을 수 있다고 생각합니다.

 

'코딩'을 위한 기술이 아니라, 문제를 논리적이고 효율적으로 해결하는

 

'사고방식'으로서의 Computational Thinking은 UX 기획자에게 강력한 무기가 될 수 있습니다.

 

 

 

이번 글에서는 Computational Thinking이 무엇인지 간략히 살펴보고,

 

기획 관점에서 왜 '파라미터(Parameter)'를 이해하는 것이 중요한지에 대해 이야기해 보겠습니다.

 

---

 

왜 기획자에게 Computational Thinking 이 필요한가?

 

Computational Thinking(CT)은 컴퓨터 과학자처럼 문제에 접근하고 해결하는 사고방식을 의미하는데,

 

보통 4가지 핵심 요소로 설명합니다.

 

• 분해 (Decomposition): 문제를 더 작고 관리 가능한 단위로 쪼갬
• 패턴 인식 (Pattern Recognition): 유사한 문제 간 공통점을 파악함
• 추상화 (Abstraction): 핵심이 아닌 요소는 덜어내고 본질에 집중함
• 알고리즘 (Algorithm): 해결 과정을 단계적으로 정의함

 

이 중에서도 기획자에게 가장 중요한 '추상화(Abstraction)'라고 생각합니다.

 

 

 

현실의 복잡한 요구사항을 시스템이 이해할 수 있는 구조로 바꾸는 일,

 

그 중심에는 바로 ‘파라미터(Parameter)’에 대한 이해가 있습니다.

 

 

---

 

기획자의 언어, '파라미터'로 화면과 시스템 연결하기

 

기획자의 핵심 업무는 눈에 보이는 '화면'과, 눈에 보이지 않는 '시스템'을 논리적으로 연결하는 것입니다.

 

이 과정을 Computational Thinking 관점에서 풀어보겠습니다.

 

 

사용자 화면: List, Detail, Form

 

이전 글 "와이어프레임의 80%는 List, Detail, Form으로 정리된다"에서도 다루었듯,

 

기획자가 다루는 대부분의 화면은 세 가지 유형으로 단순화할 수 있습니다.

 

• List: 여러 데이터 항목을 목록 형태로 보여주는 화면 (ex. 공지사항 목록, 상품 목록)
• Detail: 목록에서 특정 항목을 선택했을 때 그에 대한 상세 정보를 보여주는 화면 (ex. 공지사항 내용, 상품 상세)
• Form: 새로운 데이터를 생성하거나 기존 데이터를 수정하기 위해 정보를 입력하는 화면 (ex. 글쓰기, 회원가입)

 

이것이 기획자가 설계하는 '사용자 인터페이스'의 세계입니다.

 

 

시스템의 데이터: Entity와 Attribute(파라미터)

 

반대로, 시스템의 내부는 Entity와 Attribute라는 구조로 구성됩니다

 

• Entity (엔티티): 저장하려는 데이터의 '개념' 또는 '실체' (ex. 회원, 상품, 주문, 쿠폰)
• Attribute (속성): 해당 엔티티가 가지는 구체적인 '데이터 항목' 또는 '정보' (ex. 회원의 '이름', '이메일', '가입일')

 

바로 이 'Attribute'가 기획자가 이해해야 할 시스템의 핵심 '파라미터(Parameter)'입니다.

 

이 파라미터들이 모여 하나의 'Entity'를 정의하고, 시스템은 이 파라미터들을 기반으로 동작하기 때문입니다.

 

기획자의 핵심 역할은 바로 이 둘을 연결(Binding)하는 것입니다.

 

즉, 어떤 Entity의 어떤 Attribute(파라미터)들을 가져와서 List, Detail, Form이라는 UI 형태로 보여주고 조작할지를

 

모순 없이, 일관되게 설계하는 것입니다.

 

 

---

 

 

실전 예시: '쿠폰 서비스' 기획하기

 

예를 들어 ‘쿠폰 서비스’를 기획한다고 가정해봅시다.

 

사용자용 화면(FO)과 관리자용 화면(BO) 두 가지가 필요하겠죠.

 

1. FO (Front Office): 일반 사용자가 쿠폰을 받고, 내역을 확인하고, 사용할 수 있는 화면
2. BO (Back Office): 관리자가 쿠폰을 생성(발급)하고, 사용 현황을 관리할 수 있는 화면

 

이때 Computational Thinking을 적용해 봅시다.

 

 

Step 1. 추상화 - 쿠폰의 속성(파라미터) 정의

 

먼저 '쿠폰'이라는 Entity가 어떤 파라미터(Attribute)로 구성되어야 하는지 정의해야 합니다.

 

• Entity: 쿠폰 (Coupon)
• Attributes (Parameters):
  • 쿠폰 ID: (시스템이 식별하기 위한 고유값)
  • 쿠폰명: (사용자에게 보여줄 이름)
  • 할인 유형: (정액 할인, 정률 할인)
  • 할인 값: (1,000원, 10%)
  • 최소 주문 금액: (ex. 20,000원 이상 구매 시 사용 가능)
  • 발급 일시: (쿠폰이 생성된 시간)
  • 만료 일시: (쿠폰을 사용할 수 있는 마지막 시간)
  • 쿠폰 상태: (사용 가능, 사용 완료, 기간 만료)
  • 발급 대상: (모든 회원, 특정 등급 회원)

 

이 파라미터 정의가 명확하고 상세할수록, 개발자는 시스템을 더 견고하게 설계할 수 있습니다.

 

 

 

Step 2.  UI와 파라미터 연결

 

정의된 파라미터를 바탕으로 FO와 BO의 화면을 설계합니다.

 

• BO (관리자 화면)
  • 쿠폰 생성 (Form): 관리자는 위에서 정의한 쿠폰명, 할인 유형, 할인 값 등의 파라미터를 모두 입력하여 새로운 쿠폰(Entity)을 생성합니다.
  • 쿠폰 관리 (List): 쿠폰 ID, 쿠폰명, 만료 일시, 쿠폰 상태 등을 목록으로 보여줍니다.

 

• FO (사용자 화면)
  • 내 쿠폰 (List):사용자가 보유한 쿠폰 목록을 보여줍니다. 이때 관리자 화면과 달리 쿠폰명, 최소 주문 금액, 만료 일시 등 사용자에게 필요한 파라미터만 선별하여 보여줍니다. '기간 만료' 상태인 쿠폰은 흐리게 처리하는 등의 규칙도 이곳에서 정의합니다.
  • 쿠폰 상세 (Detail): 쿠폰을 선택하면 모든 사용 조건을 상세히 보여줍니다.

 

여기서 핵심은 하나의 파라미터(ex.만료 일시)가 모든 화면에서 일관되게 정의되고 적용되어야 한다는 점입니다.

 

 

만약 기획 단계에서 이 파라미터에 대한 정의와 규칙이 모호하다면,

 

각 화면의 정보가 서로 맞지 않거나 로직이 꼬이는 문제가 발생하게 됩니다.

 

 

---

 

 

정리하며, 기획자에게 필요한 사고방식

 

Computational Thinking은 기획자에게 ‘코딩 능력’을 요구하지 않습니다.

 

대신, 문제를 데이터 관점에서 바라보는 눈을 기릅니다.

 

 

우리가 설계하는 파라미터 하나하나가 곧 시스템의 규칙이 됩니다.

 

 

기획자가 시스템의 구조와 흐름을 정확히 이해하고 설계할 때,

 

단순한 화면 설계를 넘어, 개발자와의 커뮤니케이션도 원활해지고

 

서비스 전체의 완성도도 올라가게 됩니다.

 

 

기획자는 시스템의 아키텍트입니다.

 

그리고 그 시작은, 파라미터를 제대로 바라보는 데서 출발합니다.