앱처럼 우아한 화면전환을 위한 웹 개발자의 발버둥

2025년 7월 28일

NaHCoH

#react
#modal
#stackview
#portal

안녕하세요. 노머스 프론트엔드 팀 황호찬입니다.

노머스에서 개발 중인 프롬 서비스는 다양한 프로젝트들로 구성되어 있으며, 그중 프롬 채널은 프롬 메시지 앱 내에서 웹뷰 형태로 동작하는 화면입니다. 웹뷰 특성상 실제 앱 화면처럼 자연스럽고 매끄럽게 보이기를 바라는 니즈가 있었고, 이에 따라 기획·디자인 팀에서도 “웹이 아닌 앱처럼” 보이도록 만들어달라는 요청이 많았습니다.

이러한 요구사항을 충족시키기 위해 저희는 다양한 방식의 모달 처리와 UI 전환 방식을 실험하고 적용해 왔으며, 이번 글에서는 프롬 채널이 앱처럼 보이기 위해 어떤 개발적 고민과 시도를 거쳤는지 그 과정을 공유드리려 합니다.

앱과 웹의 차이?

모달 방식을 이야기하기 전에, 먼저 왜 프론트엔드 팀이 앱처럼 보이게 하기 위해 고민했는지에 대해 생각해볼 필요가 있습니다.

앱은 기본적으로 하나의 스크린 위에 화면을 쌓아 올리는 스택 기반 구조를 사용합니다. 이 구조에서는 화면 전환 시 부드러운 애니메이션이 자연스럽게 동작하고, 별도의 깜빡임 없이 사용자가 흐름을 이어갈 수 있습니다.
예를 들어, 새로운 화면으로 이동하거나 뒤로 가는 동작에서 슬라이드 인/아웃 전환이 기본으로 제공되며, 이 덕분에 앱은 UX적으로 매우 매끄럽게 느껴집니다.

반면 웹은 본질적으로 history를 기반으로 한 페이지 단위의 이동이 주를 이룹니다. 그 결과 화면 전환 시 순간적으로 전체가 갱신되거나, 전환 효과가 없어서 사용자 입장에서 앱에 비해 다소 뚝 끊기는 듯한 경험을 하게 됩니다. SPA 구조로도 이러한 단점을 보완할 수는 있지만, 앱과 완전히 동일한 경험을 주기 위해서는 별도의 UI/UX 설계와 기술적 구현이 필요합니다.

우리가 사용하는 방식은?

페이지 이동

프롬 채널은 웹뷰로 동작하지만, 본질적으로는 웹 페이지이기 때문에 완전히 페이지 이동이 없을 수는 없습니다.
특히 탭 간 이동처럼 구조적으로 분리된 화면에서는 실제로 페이지 전환이 발생하게 됩니다.
하지만 저희는 SPA의 특징을 살려, 페이지 이동이 마치 앱 내 화면 전환처럼 자연스럽게 느껴지도록 여러 시도를 하고 있고, 하나의 페이지에서 움직이는것 처럼 다양한 렌더링 타이밍과 CSS 전환 효과를 조정하고 있습니다.

인앱 브라우저

프롬 메시지 앱에서는 인앱 브라우저를 통해 웹뷰 화면을 띄우는 방식을 사용하고 있습니다. 이는 단순한 링크 이동이 아니라, 네이티브 앱에서 새로운 웹뷰 화면을 생성해주는 동작으로, 단순히 앱에서 웹으로의 연결이라기보다는 웹뷰에서 새로운 웹뷰를 여는등 새로운 스택을 쌓아야 할 때도 활용됩니다.
예를 들어, 각 채널로 진입할 때마다 인앱 브라우저를 통해 새로운 웹뷰가 열리게 되며, 이를 통해 각 채널이 서로 독립적인 화면 스택으로 관리될 수 있도록 구성하고 있습니다.

모달

이 글의 가장 핵심이 되는 부분이며, 도입부에서 언급했던 웹이 아닌 앱처럼보이기 위한 UI 구조입니다.
저희는 내부적으로 모달로 관리되는 모든 요소들에 대해서 하나의 스택으로 관리하고 있습니다. 다만 모달도 한 종류만 있는게 아니다보니 여러 종류의 모달을 하나의 스택에서 관리하기 위한 여러 노력을 하고 있습니다.

사실 저희가 모달을 구현하는데는 여러가지 고난이 있었는데요, 하나씩 설명해보려고 합니다.

네이티브 앱에서 제공하는것 같은 바텀시트

“네이티브 앱 같은 바텀시트”라는 말이 다소 낯설게 느껴질 수도 있습니다.
사실 저희도 처음에는 단순히 디자인에 맞춰 바텀시트를 구현하면 되는 줄 알았습니다. 그런데 막상 만들어보니 예상치 못한 요구사항이 뒤따랐습니다.
바로, 사용자의 액션에 따라 바텀시트가 자연스럽게 따라다니고, 스와이프 제스처로 닫을 수 있어야 한다는 점이었습니다. 단순히 보여주고 숨기는 수준이 아니라, 앱에서 흔히 볼 수 있는 동적인 바텀시트 인터랙션을 웹에서도 구현해야 했던 것이죠. 다행히도 이런 기능을 미리 잘 구현해둔 라이브러리가 있었고, 해당 라이브러리를 활용해 비교적 수월하게 문제를 해결할 수 있었습니다.

모달이 사라지는 시점에서의 애니메이션 처리

모달 컴포넌트를 보여주고 숨기는 시점을 단순히 open과 close로 구분해 구현하려 했을 때, 예상치 못한 문제가 발생했습니다.
open 시점에는 모달이 애니메이션 없이 갑자기 화면에 등장해버렸고,
close 시점에는 애니메이션 없이 곧바로 사라져버리는 문제가 있었습니다.
이는 사용자 경험 측면에서 부자연스러웠고, 앱 같은 느낌과도 거리가 있었습니다.

그래서 저희는 모달의 타입(Dialog, Vaul 등)과는 별개로, 모달의 상태 자체를 mount, open, closing의 3단계로 나누어 관리하기로 했습니다.

✅ mount
- open() 함수가 호출되면 우선 모달은 mount 상태로 추가됩니다.
- 이때 모달은 DOM에 렌더링되긴 하지만 화면에 보이지 않도록 숨겨진 위치에 배치됩니다.

{  
        id: modalId,  
        ...newModal,  
        state: 'mount'  
    }  
]);

✅ open
- requestAnimationFrame을 활용해 다음 프레임에서 open 상태로 변경됩니다.
- 이를 통해 트랜지션 시작점이 보장되며, 모달이 자연스럽게 나타나는 애니메이션이 가능해집니다.

requestAnimationFrame(() => {  
    // 모달을 연다  
    setModalStack((old) => old.map((modal) => (modal.id === modalId ? { ...modal, state: 'open' } : modal)));  
});

✅ closing
- close()가 호출되면 바로 DOM에서 제거(unmount)하지 않고, 먼저 상태를 closing으로 변경합니다.
- 모달은 닫히는 애니메이션을 실행하고, 애니메이션이 끝나는 시점에 맞춰 실제로 unmount 처리됩니다.
- 이 방식은 사용자에게 자연스러운 전환 경험을 제공하면서, 동시에 메모리 누수와 리렌더링 부담도 줄일 수 있는 장점이 있습니다.

setModalStack((old) => old.map((modal) => (modal.id === targetId ? { ...modal, state: 'closing' } : modal)));

setTimeout(() => {  
    setModalStack((old) => old.filter((modal) => modal.id !== targetId));  
}, modal.duration);

이러한 방식은 웹에서 앱스러운 전환 경험을 구현할 때 매우 중요한 포인트였습니다. 단순한 상태 전환이 아니라, 렌더링 타이밍과 UI 흐름을 조율하면서 사용자 경험과 성능을 동시에 고려한 구조라고 할 수 있습니다.

포탈로는 처리되지 않는 리렌더링 이슈

앞서 예시로 보여드린 영상 속 모달 방식은 저희 내부에서는 “스택뷰(StackView)“라고 부르며 사용하고 있습니다.
기술적으로는 portal을 활용해 모달이 실제 DOM 트리상에서는 <body>의 자식 요소로 렌더링되지만, 컴포넌트 단위에서는 모달을 띄우는 컴포넌트 내부에 함께 포함되는 구조였습니다. 이 구조는 초기에는 별다른 문제가 없어 보였습니다. 하지만 기능이 하나 추가되면서 치명적인 이슈가 발생했습니다.

문제 상황: 부모 컴포넌트의 리렌더링 → 모달 강제 종료
어느 날, 모달 내에서의 상태 변경이 우연히 모달을 포함하고 있는 부모 컴포넌트의 리렌더링을 유발하게 되었습니다.

이로 인해
- 부모 컴포넌트가 리렌더링됨 → 자식 컴포넌트(모달 포함)도 리렌더링
- React의 상태 초기화 또는 컴포넌트 트리 재생성으로 인해
- 화면에 있던 모달이 갑자기 사라지는 현상이 발생했습니다
즉, portal로는 분리되어 보이지만, 실제 컴포넌트 트리 상에서는 부모의 영향에서 자유롭지 않았던 것이죠.

해결 방법: 모달의 중앙 집중식 관리
이 문제를 해결하기 위해 모든 스택뷰 모달을 각 컴포넌트에서 직접 관리하는 방식에서 → 앱 최상위 컴포넌트에서 중앙 관리하는 구조로 전환했습니다.
- 실제 모달 컴포넌트는 최상위에서 단 한 번만 렌더링되고, 각종 props나 컨텍스트를 통해 필요한 정보만 주입
- 이렇게 하여 부모 컴포넌트의 리렌더링과 모달이 완전히 분리되었고, 이슈도 깔끔하게 해결되었습니다

 const StackViewRenderer = () => {
     const [stackviewModal] = useAtom(stackviewModalAtom);
 
     const modals = stackviewModal.map((modal) => (
         <ModalBase key={modal.id} state={modal.state}>
             {modal.props.children}
         </ModalBase>
     ));
 
     const portalRoot = document.body;
     return portalRoot ? createPortal(modals, portalRoot) : null;
 };

이런 작업들의 결과로 나온게 프롬 사용자들이 사용하는 커뮤니티 기능 프롬 채널의 화면 이동 흐름입니다.

마치며

사용자에게 보이는 프롬 채널의 화면 전환은 앱에서의 화면 전환처럼 부드럽고 자연스러워 보이지만
하지만 그 아래에서는, 모달의 상태 전환을 정교하게 컨트롤하고, 렌더링 타이밍을 계산하고, 구조적인 리렌더링 문제를 피해가기 위한 프론트엔드 팀의 고민과 시행착오가 있었습니다.

이처럼 보이지 않는 곳에서 열심히 물장구를 치며 균형을 잡고 우아함을 뽐내는 백조처럼,
저희 프론트엔드 팀은 사용자에게는 단순하고 매끄러운 경험을 제공하기 위해 계속해서 기술적인 디테일을 갈고닦고 앞으로도 노력해 나가려 합니다.

감사합니다.