생성형 AI 네이티브 프로덕트 설계 원칙

 

지금까지는 기존 서비스에 AI 기능을 하나씩 붙이는 작업을 주로 해왔는데, 최근 처음부터 AI를 전제로 설계하는 신규 프로덕트 기획에 참여하게 됐습니다.
"기존 화면에 AI를 끼워 넣는 것"과 "처음부터 AI 네이티브로 설계하는 것"은 완전히 다른 작업이라는 걸 이 과정에서 확실히 느꼈어요.
이번 글에서는 이 프로젝트를 하면서 정리한 설계 원칙들을 공유해보려고 합니다.

 

원칙 1: 입력의 자유도를 화면이 먼저 감당해야 한다

기존 화면은 사용자가 정해진 필드에 정해진 형식으로 입력하는 걸 전제로 만들어져 있습니다.
AI 네이티브 화면에서는 사용자가 뭐든 자유롭게 입력할 수 있다는 걸 전제로 설계해야 해요.
저희가 처음 만든 시안은 여전히 "정해진 질문에 답하는" 폼 형태였는데, 실제 사용자 테스트에서 사람들이 예상 밖의 방식으로 입력하는 걸 보고 다시 설계를 갈아엎었습니다.
결국 자유 입력창을 기본으로 두고, 그 아래에 자주 쓰는 표현 몇 가지를 예시로 보여주는 방식으로 바꿨는데, 이렇게 하니 사용자가 무엇을 입력해야 할지 헤매는 시간이 확연히 줄었어요.

 

원칙 2: 결과물은 항상 "다음 행동"을 제시해야 한다

기존 화면은 결과를 보여주면 끝이었지만, AI 네이티브 화면에서는 결과가 항상 완벽하지 않다는 걸 전제로 설계해야 합니다.
결과를 보여준 다음, 사용자가 "이걸 수정해달라", "다르게 다시 해달라", "이 부분만 자세히 알려달라" 같은 후속 행동을 쉽게 취할 수 있어야 해요.
저희는 모든 결과 화면에 "다시 만들기", "이 부분만 수정" 버튼을 기본으로 붙였는데, 이 버튼의 사용 빈도가 예상보다 훨씬 높았습니다.
사용자들은 첫 결과를 그대로 받아들이기보다, 조정해가면서 원하는 결과를 만들어가는 걸 자연스럽게 기대하고 있었어요.

 

원칙 3: 불확실성을 화면 구조로 표현한다

앞서 UX 라이팅 글에서 다뤘던 내용과 비슷한데, 이번엔 문구가 아니라 화면 구조 자체로 불확실성을 표현하는 방법을 고민했습니다.
확신이 낮은 결과는 시각적으로도 다르게 보이도록, 배경색을 살짝 다르게 하고 "검토가 필요합니다"라는 아이콘을 붙이는 식으로 디자인했어요.
이렇게 하니 사용자가 굳이 문구를 다 읽지 않아도, 어떤 결과를 더 신경 써서 봐야 하는지 한눈에 구분할 수 있게 됐습니다.

 

원칙 4: 되돌릴 수 있는 것과 없는 것을 명확히 구분한다

AI가 자율적으로 여러 단계를 처리하는 기능이 늘어나면서, 이 원칙이 특히 중요해졌습니다.
저희 프로덕트에서는 AI가 초안을 만드는 것까지는 자유롭게 진행되지만, 실제로 발송하거나 확정하는 단계에서는 항상 사용자의 명시적인 확인을 받도록 설계했어요.
이 원칙을 화면 구조에도 그대로 반영해서, 되돌릴 수 없는 액션 버튼은 항상 색상과 위치를 다르게 배치하고, 클릭 전에 한 번 더 확인하는 모달을 거치도록 통일했습니다.

 

원칙 5: 로딩 상태를 "일하고 있다는 증거"로 디자인한다

응답 시간이 기존 화면보다 훨씬 길어지는 게 AI 네이티브 프로덕트의 특징입니다.
저희는 단순한 스피너 대신, 지금 어떤 작업을 하고 있는지를 단계별로 보여주는 로딩 화면을 설계했어요.
"자료를 찾고 있어요" 다음에 "답변을 정리하고 있어요"처럼 단계가 바뀌는 걸 보여주니, 같은 대기 시간인데도 사용자가 느끼는 답답함이 줄어드는 걸 사용자 테스트에서 확인했습니다.

 

원칙 6: 실패를 사용자의 실수가 아니라 시스템의 한계로 표현한다

AI가 답을 못 찾거나 실패하는 상황에서, 문구와 화면 모두 "당신이 잘못 입력해서"가 아니라 "지금 시스템이 이 부분을 잘 못 한다"는 톤으로 설계해야 합니다.
저희 초기 시안은 실패 화면에 "입력을 다시 확인해주세요"라고 적어뒀는데, 사용자 인터뷰에서 "제가 뭘 잘못했는지 모르겠다"는 답답함이 계속 나왔어요.
문구를 "이 부분은 저희 기능이 아직 부족해요. 다른 방식으로 다시 물어봐 주시겠어요"로 바꾸고 나서야 이 답답함이 줄었습니다.

 

원칙 7: 개인화의 경계를 사용자가 직접 조절하게 한다

AI 네이티브 프로덕트는 사용자의 이전 행동을 학습해서 점점 더 맞춤화된 결과를 보여주는 방향으로 가기 쉽습니다.
그런데 이 개인화가 지나치면, 사용자가 "얘가 나에 대해 뭘 알고 있는 거지"라는 불편함을 느낀다는 걸 사용자 인터뷰에서 반복적으로 확인했어요.
한 사용자는 저희 서비스가 과거 대화 내용을 너무 자연스럽게 참조하는 걸 보고 "감시받는 느낌이 든다"고 표현하기도 했습니다.
그래서 저희는 설정 화면에 "이전 대화를 기억하지 않기" 옵션을 눈에 잘 보이는 위치에 넣고, 개인화 수준을 사용자가 직접 낮추거나 끌 수 있게 만들었어요.
편의성과 프라이버시 사이의 균형을 기술이 알아서 정하는 게 아니라, 그 결정권을 사용자에게 돌려주는 게 맞다는 결론에 도달했습니다.

 

원칙 8: 팀의 협업 방식 자체도 다시 설계해야 한다

이 원칙은 화면 설계 원칙은 아니지만, 앞선 일곱 가지를 실제로 지키려면 반드시 따라와야 하는 부분이라 같이 정리하고 싶습니다.
기존에는 기획자가 화면 설계를 먼저 끝내고 디자이너에게 넘기고, 디자이너가 작업을 마치면 개발자에게 넘기는 순차적인 흐름이 흔했습니다.
AI 네이티브 프로덕트에서는 이 순서가 잘 안 맞았어요.
불확실성을 화면 구조로 표현하려면 디자이너가 모델의 확신도 데이터를 미리 알아야 했고, 되돌릴 수 있는 액션과 없는 액션을 구분하려면 개발자가 초기 설계 단계부터 참여해야 했습니다.
그래서 저희는 기획, 디자인, 개발이 매주 한 번씩 화면 초안을 같이 놓고 리뷰하는 자리를 프로젝트 초반부터 고정으로 만들었어요.
처음엔 회의가 늘어난 것 같아 부담스러웠는데, 나중에 보니 이 회의 덕분에 뒤늦게 갈아엎는 일이 오히려 줄었습니다.

 

원칙을 적용하면서 만난 내부 반발

이 원칙들을 실제로 적용하는 과정이 순탄하지만은 않았습니다.
특히 원칙 4(되돌릴 수 있는 것과 없는 것을 구분한다)를 적용하려고 하니, 개발팀에서 "그러면 모든 액션에 확인 모달을 다 붙여야 하냐"는 반발이 나왔어요.
확인 단계가 늘어나면 사용자 경험이 오히려 번거로워질 수 있다는 우려였는데, 저도 타당한 지적이라고 생각했습니다.
그래서 저희는 모든 액션에 확인 모달을 붙이는 대신, 되돌릴 수 없는 액션의 목록을 먼저 좁게 정의하고 그 목록에만 예외적으로 확인 절차를 두는 방식으로 절충했어요.
이 목록을 정하는 과정에서 기획, 디자인, 개발이 함께 앉아서 "이 액션이 정말 되돌릴 수 없는가"를 하나씩 따져봤는데, 의외로 처음 생각했던 것보다 되돌릴 수 없는 액션의 수가 적었습니다.
이렇게 범위를 좁혀서 적용하니, 원칙은 지키면서도 개발팀의 부담과 사용자의 불편을 동시에 줄일 수 있었어요.

 

설계 원칙을 정리하고 나서 느낀 것

이 여덟 가지 원칙을 정리하고 나니, 결국 AI 네이티브 설계라는 게 화면을 예쁘게 만드는 문제가 아니라 "불확실성을 사용자에게 어떻게 정직하게 넘길 것인가"의 문제라는 생각이 들었습니다.

기존 UX 원칙에서 벗어난 새로운 법칙을 만든 게 아니라, 오히려 "사용자를 존중하는 설계"라는 기본으로 더 깊이 돌아간 느낌이었어요.
다만 이 원칙들을 지키려면 디자이너, 개발자, 기획자가 훨씬 초기 단계부터 함께 논의해야 한다는 부담도 분명히 있습니다.

 

이 프로덕트는 아직 정식 출시 전이라, 이 원칙들이 실제 사용자 반응에서 얼마나 통할지는 더 지켜봐야 합니다.
그래도 지금까지의 파일럿 테스트에서는 반응이 나쁘지 않아서, 조심스럽게 기대를 걸고 있어요.

출시 이후 실제 데이터가 쌓이면, 이 여덟 가지 원칙 중 어떤 게 실제로 유효했는지 다시 검증해서 정리해보려고 합니다.