API × Back Office Decision

서비스는 “무엇”, 액션은 “어디로”

서비스 목록의 항목을 눌렀을 때 현재 화면의 영역 또는 다른 페이지로 이동해야 한다면, 이동 방식은 서비스 타입이 아니라 액션 타입으로 표현합니다.

한 줄 결론
API는 action.type으로 설계하고, BO에서는 이를 기획자가 이해하기 쉬운 “클릭 시 이동” 항목으로 보여주는 것이 좋습니다.

두 가지 질문을 분리합니다

SERVICE TYPE으로 이동 결정

서로 다른 개념이 묶입니다

  • 배송 서비스는 항상 같은 곳으로 가야 함
  • 노출 위치마다 이동이 달라지면 예외가 생김
  • 가짜 서비스 타입이 늘어날 수 있음
ACTION TYPE 권장

내용과 행동을 따로 바꿉니다

  • 같은 배송 서비스도 위치별 이동 설정 가능
  • 기획자가 이동 목적을 직접 확인 가능
  • 새 이동 방식도 자연스럽게 추가 가능

왜 액션 타입이 더 나을까요?

1
같은 서비스를 다르게 연결할 수 있습니다.
메인에서는 배송 혜택 영역으로, 검색 결과에서는 배송 상세 페이지로 연결할 수 있습니다.
2
BO 화면이 기획자의 의도와 일치합니다.
서비스 종류를 바꾸는 대신 “클릭 시 이동”을 직접 선택하므로 설정 결과를 예측하기 쉽습니다.
3
잘못된 조합을 시스템이 막을 수 있습니다.
영역 이동이면 영역을, 페이지 이동이면 페이지만 필수로 받습니다.

기획자에게는 배너 비유가 가장 정확합니다

설명 문장
기획자가 서비스 버튼의 이동 방식을 설정하는 것은 쇼핑몰 배너의 내용을 바꾸는 것이 아니라, 배너를 클릭했을 때 연결될 위치를 설정하는 것과 같습니다. 서비스는 “무엇을 보여주는가”, 액션은 “클릭하면 어디로 이동하는가”이므로 별도로 관리해야 합니다.
예시 1 · 가장 추천

쇼핑몰 배너 연결

배너 내용: 여름 할인전
클릭 시 연결: 이벤트 상세 페이지

같은 배너도 상품 영역, 상세 페이지, 외부 프로모션 페이지로 연결할 수 있습니다. BO에서 기획자가 실제 수행하는 작업과 가장 유사합니다.

예시 2 · 직관적

리모컨 단축 버튼

버튼 이름: 영화 보기
버튼 동작: 넷플릭스 실행

다른 앱을 연결해도 버튼 이름과 실행 동작을 별도로 관리할 수 있습니다. 버튼의 이름·내용은 서비스, 눌렀을 때 실행되는 기능은 액션입니다.

예시 3

내비게이션 즐겨찾기

“집”이라는 이름과 실제 목적지는 별개입니다. 목적지를 바꿔도 즐겨찾기의 역할은 유지되므로 이동 대상 분리를 설명하기 좋습니다.

예시 4 · 보조 비유

POS 메뉴 가격

가격을 바꿔도 김치찌개가 다른 메뉴가 되지 않는다는 점은 같습니다. 다만 가격은 단순 값이고 액션은 실행 동작이므로 핵심 비유로는 덜 정확합니다.

추천 순서
  1. 쇼핑몰 배너 — BO 업무와 가장 유사
  2. 내비게이션 즐겨찾기 — 이동 대상 분리를 설명하기 좋음
  3. 리모컨 단축 버튼 — 이름과 실행 동작의 분리가 직관적
  4. POS 메뉴 가격 — 대상과 설정값 분리에는 좋지만 가격은 액션이 아님

BO에서는 이렇게 보여주세요

‘액션 타입’이라는 개발 용어는 노출하지 않습니다.

배송 혜택

DOM ID 직접 입력보다 등록된 영역 선택을 권장합니다.

영역 이동을 선택하면

등록된 영역 선택 필드만 보여줍니다. 대상 영역이 없으면 저장을 막습니다.

페이지 이동을 선택하면

페이지 검색·선택 필드만 보여줍니다. URL 직접 입력보다 페이지 ID 연결이 안전합니다.

API에서는 이렇게 저장합니다

type ServiceAction =
    | { type: 'anchor'; anchorId: string }
    | { type: 'page'; pageId: string };

interface Service {
    id: string;
    name: string;
    serviceType?: ServiceType; // 실제 비즈니스 분류가 있을 때만
    action: ServiceAction;     // 클릭 동작의 유일한 기준
}
피하기

선택 필드를 늘어놓는 구조

anchorId?와 pageId?를 함께 두면 둘 다 없거나 둘 다 있는 잘못된 데이터가 생길 수 있습니다.

권장

종류별 필수값을 묶는 구조

anchor에는 anchorId, page에는 pageId만 허용해 오류를 미리 막습니다.

서비스 타입은 언제 쓰나요?

배송 · 멤버십 · 이벤트처럼 실제 비즈니스 분류가 있을 때 사용합니다. 이 경우에도 서비스 타입은 표시·권한·분석에 사용하고, 이동은 오직 action.type으로 결정합니다. 서비스 종류와 이동 방식이 제품 정책상 영원히 1:1인 경우만 예외지만, 이때도 분리해 두는 편이 변경에 안전합니다.