데스크톱 AI 화면을 모바일에서 과감히 제거한 이유

프론트엔드2026년 8월 1일글: 홍서진, Duolabs8분 읽기ai-interface blog blog-series document-rag-series mobile-web model-openai-gpt-5 responsive-ux technical-note

데스크톱에서 잘 작동하는 AI 인터페이스를 모바일 화면에 그대로 줄이면 기능은 남지만 경험은 쉽게 무너집니다. 사이드바, 대화, 참고 문헌을 동시에 보여주는 3단 구조는 넓은 화면에서는 강력하지만 작은 화면에서는 탐색과 스크롤이 서로 경쟁합니다.

듀오랩스는 공개 랜딩의 문서 AI 체험을 모바일에 맞추는 과정에서 두 번 방향을 바꿨습니다. 첫 번째는 입력창을 질문 칩으로 단순화하는 것이었고, 두 번째는 모바일에서 AI 패널 자체를 제거하고 서술형 콘텐츠로 돌아가는 것이었습니다.

데스크톱에서는 3단 구조가 유용했습니다

데스크톱 AI 화면은 세 영역으로 구성했습니다.

┌──────────┬────────────────────┬──────────────┐
│ 대화 목록 │ 질문과 답변          │ 참고 문헌      │
│          │                    │ 근거 원문      │
└──────────┴────────────────────┴──────────────┘

사용자는 답변을 읽으면서 오른쪽에서 근거를 확인하고, 필요하면 이전 대화로 이동할 수 있습니다. 넓은 화면에서는 정보가 동시에 보이는 것이 장점입니다.

문제는 이 구조를 모바일 폭에 넣었을 때입니다.

사이드바를 접고 펼치는 조작이 추가됩니다.
참고 문헌이 별도 레일이나 패널로 밀립니다.
페이지 스크롤과 대화 스크롤이 중첩됩니다.
입력창이 화면 키보드와 공간을 경쟁합니다.
랜딩 페이지를 읽던 사용자가 갑자기 복잡한 도구를 만나게 됩니다.

각 문제는 개별적으로 해결할 수 있지만, 해결용 인터랙션이 늘어날수록 체험의 목적에서 멀어졌습니다.

첫 번째 시도: 입력창을 질문 칩으로 바꿨습니다

모바일에서 자유 입력을 없애고 미리 준비한 질문을 가로 스크롤 칩으로 제공했습니다.

[무엇을 만들 수 있나요?] [진행 방식은?] [운영 지원은?]

칩을 누르면 실제 질의가 실행되므로 키보드를 열지 않고도 AI 답변을 체험할 수 있습니다. 질문 품질을 일정하게 유지하고 빈 입력 상태를 없애는 장점도 있습니다.

하지만 패널의 근본적인 복잡성은 남았습니다. 질문 입력만 단순해졌을 뿐 대화, 참고 문헌, 레일 접기와 중첩 스크롤은 그대로였습니다.

두 번째 결정: 모바일에서는 패널을 제거했습니다

최종적으로 모바일에서는 AI 패널을 숨기고 원래의 서술형 문단을 다시 보여주기로 했습니다. 데스크톱에서는 AI 체험을 유지했습니다.

이 결정은 기능을 포기한 것이 아니라 화면의 목적을 다시 정한 결과입니다.

데스크톱 사용자는 넓은 화면에서 AI와 근거 확인을 체험합니다.
모바일 사용자는 핵심 메시지를 빠르게 읽고 다음 행동으로 이동합니다.
공개 AI 기능 자체는 다른 적절한 진입점에서 제공할 수 있습니다.

반응형 디자인은 모든 화면에 같은 기능을 억지로 배치하는 작업이 아닙니다. 화면 크기와 사용 맥락에 따라 핵심 경험을 선택하는 작업입니다.

서버 HTML을 나누지 않은 이유

모바일과 데스크톱에서 서로 다른 서버 HTML을 만들면 요청 시점에 기기를 판별해야 하고, 브라우저 hydration 결과와 어긋날 위험이 생깁니다.

대신 동일한 마크업을 제공하고 CSS 미디어 쿼리로 표시할 콘텐츠를 선택했습니다.

.ai-experience { display: block; }
.mobile-story { display: none; }

@media (max-width: 767px) {
  .ai-experience { display: none; }
  .mobile-story { display: block; }
}

초기 HTML 구조가 같으므로 hydration이 안정적이고, 반응형 전환도 CSS가 담당합니다. 다만 숨겨진 AI 패널이 불필요한 요청이나 무거운 초기화를 실행하지 않도록 클라이언트 동작은 별도로 지연시켜야 합니다.

자동 포커스가 페이지를 움직였습니다

AI 입력창에 자동 포커스를 주자 페이지가 로드된 직후 해당 섹션으로 스크롤되는 문제가 생겼습니다. 전체 화면 앱에서는 입력창 자동 포커스가 편리할 수 있지만, 긴 랜딩 안에 포함된 상시 섹션에서는 사용자의 읽기 위치를 빼앗습니다.

자동 포커스를 제거하고 사용자가 패널을 직접 선택했을 때만 입력 상태로 들어가도록 바꿨습니다.

다음 질문이 판단 기준이 됩니다.

사용자가 이 페이지에 들어온 목적이 곧바로 입력하는 것인가, 먼저 내용을 읽는 것인가?

후자라면 자동 포커스는 편의가 아니라 방해가 될 수 있습니다.

CTA는 체험 뒤에 배치했습니다

데모를 경험한 직후가 서비스에 대한 관심이 가장 높은 시점이라고 보고 상담 CTA를 패널 뒤에 배치했습니다. 모바일에서는 전화처럼 기기에서 바로 실행 가능한 동작만 보여주고, 데스크톱에서는 적합한 문의 동작을 유지했습니다.

CTA는 항상 눈에 띄는 위치보다 사용자가 가치를 이해한 직후에 놓이는 편이 자연스럽습니다.

제거한 구현도 실험 자산입니다

질문 칩 구현은 최종 모바일 화면에서 사용하지 않았지만 완전히 폐기하지 않았습니다. 작은 휴대전화에는 복잡했어도 태블릿이나 별도의 체험 화면에서는 유용할 수 있기 때문입니다.

실험 코드를 남길 때는 다음 조건이 필요합니다.

현재 제품 경로에서는 실행되지 않습니다.
다시 사용할 조건과 이유가 기록되어 있습니다.
유지보수 부담이 크지 않습니다.
사용되지 않는 분석 이벤트와 스타일은 정리합니다.

단순히 아까워서 남기는 코드와 재사용 가능성을 명확히 기록한 실험 자산은 다릅니다.

모바일 AI UI 체크리스트

페이지 스크롤과 패널 스크롤이 중첩되지 않나요?
키보드가 열렸을 때 답변과 입력창을 함께 볼 수 있나요?
사이드바와 참고 문헌을 조작하기 위해 너무 많은 단계가 필요하지 않나요?
자유 입력 대신 추천 질문이 더 적합한가요?
자동 포커스가 사용자의 초기 위치를 바꾸지 않나요?
숨긴 컴포넌트가 백그라운드에서 무거운 작업을 실행하지 않나요?
기능을 제거했을 때 핵심 메시지가 더 잘 전달되지는 않나요?

듀오랩스가 보는 관점

반응형 UX의 목표는 데스크톱 기능을 한 픽셀도 빠뜨리지 않고 축소하는 것이 아닙니다. 사용자가 해당 화면에서 해야 할 일을 가장 적은 방해로 완료하게 하는 것입니다.

AI 기능은 눈에 띄지만 언제나 주인공일 필요는 없습니다. 작은 화면에서 설명을 읽는 편이 더 빠르고 명확하다면, AI 패널을 과감히 덜어내는 것이 더 나은 AI UX일 수 있습니다.

보너스 글에서는 기능 구현보다 먼저 배포 문서와 실제 실행 명령이 일치해야 하는 이유, 그리고 마이그레이션 드리프트를 다루겠습니다.