노션 페이지 지원 배경
나두아이오는 인터페이스, 데이터베이스, 워크플로우 등의 다양한 서비스를 지원한다. 그중에서도 인터페이스는 노코드/로우코드 툴이다. 웹빌더 기반으로 웹 서비스를 제작하고 호스팅 할 수 있다. 이때 장점 중 하나는 호스팅이 쉽다는 점이다. 간편 호스팅의 장점을 극대화할 수 있는 방법 중 하나는 외부에서 만들어진 걸 우리 서비스로 배포할 수 있게 하는 것이다. 이에 따라 대표적으로 많이 사용되는 ‘노션 페이지’ 기반의 홈페이지를 지원하기로 하였다. 이와 관련해 고민했던 내용과 의사결정의 기준이 되었던 부분들을 정리해보았다.
노션 페이지 지원 방식 결정
1. 노션 ‘컴포넌트’ 추가
그림처럼 인터페이스(Interface)의 앱(App)은 여러 페이지(Page)를 가지고, 각 페이지는 여러개의 컴포넌트(Component)로 구성된다. 노션 홈페이지를 우리 서비스에서 지원한다면 앱 / 페이지/ 컴포넌트 레벨에 추가하는 시나리오를 생각해볼 수 있다. 별도의 ‘노션 전용 앱’ 혹은 ‘노션 전용 페이지’ 형태로 제공할 수도 있지만 아래와 같은 이유로 컴포넌트 레벨에 추가하기로 결정하였다.
- 노션 기능이 추가됨으로써 기존의 서비스 로직에 영향을 미치지 않는다.
- ‘노션 전용 앱’, ‘노션 전용 페이지’와 같이 기존 로직에 분기를 태우면 관리 복잡도가 증가하고 확장성이 떨어질 것이다.
- 현재 독립적으로 확장이 용이한 단위는 컴포넌트다. 노션 지원을 중단해야 하는 경우 특정 컴포넌트만 제거하면 된다.
- 기존 컴포넌트와 호환된다. 노션 컴포넌트는 컴포넌트 중 하나일 뿐이다. 즉 다른 컴포넌트들과도 같이 사용할 수 있다는 것을 의미한다.
2. 노션 페이지 전환 방식
먼저 각 노션 페이지를 인터페이스의 어떤 개념에 매칭할지가 고민이었다. 만약 ‘노션 페이지 = 인터페이스 페이지’ 개념으로 호환한다면 노션 내부에 연결된 모든 페이지에 매칭되는 인터페이스 페이지를 생성해야 한다. 노션 홈페이지를 지원하는 목적 중 하나는 간편 호스팅의 장점을 극대화하면서도 우리 서비스 상에서 0-1으로 만들어야 하는 번거로움을 줄이기 위함이다. 그런데 제작 동선이 늘어나게 되면 이 또한 진입장벽을 낮추는 데 기여할 수 없다. 따라서 페이지 전환은 노션 컴포넌트 안에서 이뤄져야 한다.
기존 컴포넌트 구현 방식과 한계
에디터는 개발을 위한 몇가지 원시(primitive) 요소들을 제공한다. 사용자는 이를 가지고 개발을 진행하기 때문에 일관된 경험을 주기 위해서는 컴포넌트 역시 정해진 규칙 안에서 상호작용 하도록 구현되어야 한다.
<주요 원시 요소>
- 컴포넌트
- 데이터
- 컴포넌트 변수 (컴포넌트에 바인딩된 데이터를 의미한다.)
- 전역 변수
- 이벤트 핸들러
- 스크립트
<노션 컴포넌트 구현 방식>
노션 컴포넌트가 기존의 컴포넌트 메커니즘을 따라 구현되면 아래와 같을 것이다.
- N: 노션 컴포넌트
- Global State(전역 변수)
- URL Query, 현재 페이지 정보 등은 전역 변수에 저장된다.
- 노션 컴포넌트의 Props
- homePageId: 기본 페이지로 인식할 노션 페이지 아이디다.
- currentPageId: 이를 기반으로 현재 출력할 노션 페이지가 결정된다. homePageId보다 우선순위가 높다.
- onPageClick: 노션 페이지가 클릭되었을 때 호출되는 이벤트 핸들러다.
- 노션 컴포넌트의 State(컴포넌트 변수)
- clickedPageId: 현재 클릭된 노션 페이지 아이디다. 이는 컴포넌트 외부에서 notionComponent.clickedPageId와 같이 접근해서 쓸 수 있도록 컴포넌트에 바인딩된다. (*onPageClick의 파라미터로 넘어갈 수도 있지만 일반적으로 파라미터가 없는 이벤트 핸들러를 기준으로 설명하기 위함이다.)
<노션 컴포넌트에 쿼리 기반의 라우팅 적용>
실제로는 에디터 상에서 UI로 수행되는 부분들이지만 데이터를 중심으로 재구성했다. 각 색상이 동일한 것은 변수 참조 관계다.
- homePageId: 기본 노션 페이지 아이디를 설정한다.
- currentPageId: page.params.notionId에는 URL 쿼리에서 notionId 값이 파싱된 값이 저장된다. 이를 변수로 참조한다.
- onPageClick: 노션 페이지가 클릭되면 URL의 notionId 쿼리를 선택된 페이지(clickedPageId)로 업데이트한다. (*실제로는 UI로 NavigateAction의 파라미터만 설정한다. NavigateAction은 내부적으로 호출된다.)
정리하자면 onPageClick으로 URL을 변경하고, 변경된 currentPageId를 기준으로 노션 페이지가 새로 출력되는 원리다.
이 다음부터는 화면 진입 후 초기 스크립트를 실행해 URL의 notionId 쿼리가 homePageId로 업데이트된 이후를 전제한다.
<사용자 동작에 따른 페이지 전환 과정 – 1, 2>
사용자가 노션 페이지를 클릭하면 컴포넌트 내부에서 clickedPageId 상태를 업데이트하고, onPageClick가 호출된다.
<사용자 동작에 따른 페이지 전환 과정 – 3, 4, 5>
NavigateAction이 실행되면서 클릭된 페이지를 기준으로 URL이 변경된다. 변경된 URL을 기준으로 global state가 업데이트 되고, 이는 노션 컴포넌트의 pageId prop에도 반영된다.
<사용자 동작에 따른 페이지 전환 과정 – 6>
변경된 pageId를 기준으로 노션 페이지가 재출력된다.
결과적으로 사용자가 이해해야 할 개념이 많다는 걸 확인할 수 있다. 이는 LCNC 빌더의 숙명적인 허들인데, 이제 이를 컴포넌트 레벨로 어느정도까지 위임할 것인지는 제공하려는 사용자 경험에 달렸다. 여기서 주안점은 사용자 동선을 최소화하는 것이다.
사용자 경험 개선을 위한 동선 단축 방안
- 컴포넌트 외부에서 전달받도록 설계한 값들을 모두 컴포넌트 내부에서 처리한다.
- 이는 곧 컴포넌트 안에서 URL 쿼리를 직접적으로 바라본다는 말인데, 이에 따라 쿼리 키값을 컴포넌트 단위의 예약어로 관리해 사용자에게 노출시킬 필요가 있다. 사용자가 쓰려는 쿼리 키값과 특정 컴포넌트 내부에서 쓰는 쿼리 키값이 충돌할 수 있기 때문이다.
- homePageId는 homePageUrl로 변경한다.
- 사용자가 노션 URL에서 페이지 아이디를 인식하는 것조차 허들이라고 생각했다. 전체 URL을 받아 노션 페이지 아이디를 파싱해서 사용한다.
이로써 사용자 동선은 ‘노션 컴포넌트 추가하기 – 노션 페이지 주소 붙여넣기’, 두 단계로 줄어들었다.
여기서 한 단계 더 줄일 수 있다. 노션 컴포넌트와 관련한 프리셋을 템플릿으로 만들어 사용자가 ‘컴포넌트가 필요하다’는 개념을 인지할 필요 없이 템플릿으로 시작하고, 노션 URL을 복붙해서 사용하도록 할 수 있다.
현재 설계의 한계 및 향후 개선 방향
노션 컴포넌트의 첫 버전 설계에서는 사용자 경험을 단순화하는 데 중점을 두었다. 이를 위해 컴포넌트가 homePageUrl prop만을 입력받도록 하여 사용자의 동선을 최소화했다. 그러나 이 접근 방식에는 몇 가지 한계가 있다.
- 제한된 사용자 제어: 컴포넌트가 내부적으로 많은 기능을 처리하면서, 사용자의 세부적인 제어 가능성이 줄어들었다.
- 유연성 부족: 현재 내부적으로 처리되는
currentPageId나onPageClick같은 기능들을 사용자가 직접 관리하고 싶을 수 있다.
향후 개선 방향으로는 다음과 같은 사항들을 고려할 수 있다.
- 사용자 요구에 따라 더 많은 prop을 외부에서 받을 수 있도록 컴포넌트를 확장한다.
- 에디터 상에서 복잡한 설정을 쉽게 할 수 있는 UI/UX 개선을 고려한다.
- 사용자 피드백을 지속적으로 수집하여 버전을 업그레이드하며 기능을 확장한다.
이러한 접근 방식을 통해, 초기 버전의 단순함을 유지하면서도 점진적으로 더 많은 사용자 요구사항을 수용할 수 있는 유연한 컴포넌트로 발전시킬 수 있을 것이다. 컴포넌트 설계는 사용자 요구사항에 따라 지속적으로 진화해야 한다. 이번 글에서는 그 시작이 되는 노션 컴포넌트 버전 1의 설계 과정과 고민들을 상세히 기록해보았다.
<관련 컨텐츠 바로가기>
솔루션의 비즈니스 가치를 고민하며 성장하는 개발자 김지후입니다.
—김지후, SW엔지니어 @ 나두모두