- 모든 사용자가 같은 화면을 보면, 처음 온 사람은 헤매고 오래 쓴 사람은 이미 아는 내용 때문에 답답해합니다.
- 화면을 사용자에 맞춰 바꾸면 실제로 도움이 됩니다. 다만 왜 이렇게 보이는지 설명할 수 있어야 하고, 사용자가 끌 수 있어야 합니다.
- 화면을 바꾸는 목적은 사용자가 일을 끝내도록 돕는 데 있어야 하며, 구매 버튼을 누르도록 속이는 데 써서는 안 됩니다.
기존 웹사이트와 앱은 어디에서 멈춰 있을까
좋은 가게는 처음 온 손님과 단골을 다르게 대합니다. 처음 온 손님은 안내가 필요하고 단골은 빠른 처리를 원합니다. 그런데 대부분의 앱은 모든 사람에게 같은 화면을 보여 줍니다. 그러니 신규 사용자는 헤매고 기존 사용자는 답답할 수밖에 없습니다.
모든 사람에게 같은 흐름(Flow)을 쓰는 앱은 만들기는 쉽지만 쓰기는 어렵습니다. 초보자에게는 안내가, 숙련자에게는 지름길이, 위험한 건에는 추가 확인 단계가 필요합니다.
모두에게 똑같은 웹과 앱은 사용자가 시스템을 자기 역할에 맞춰 알아서 해석하게 만듭니다. 신입 직원은 수많은 메뉴 앞에서 막막해하고, 자주 쓰는 사용자는 같은 설명을 매번 거쳐야 하며, 언어, 시력, 기기에 제약이 있는 고객은 자신을 염두에 두지 않고 설계된 사용자 여정(Journey)에 갇힐 수 있습니다. 기존의 개인화는 대개 배너나 추천 상품만 바꿉니다.
적응형 AI 제품(Adaptive AI Product)은 여기서 더 나아가 순서, 단계, 설명, 도움말을 맥락에 맞게 조정합니다. 그래도 제품을 배우기 쉽고 예측 가능하게 유지하려면 경계가 있어야 합니다. 사용자는 무엇이 왜 바뀌었는지 알 수 있어야 하고, 시스템이 기억한 내용을 고칠 수 있어야 하며, 언제든 표준 화면으로 돌아갈 수 있어야 합니다.
| 기존 방식 | 새로운 AI 제품 방식 |
|---|---|
| 세그먼트를 미리 나누고 몇몇 위치의 콘텐츠만 교체 | 현재 맥락을 보고 설명, 도구, 자동화 수준을 동적으로 고르되, 사용자가 그 조정을 보고 통제할 수 있게 함 |
적응형 제품은 이벤트, 프로필, 규칙, 기능 플래그(Feature Flag)를 연결해야 하고, 언제나 작동하는 기본값(Default)을 갖춰야 합니다. AI는 상황에 맞는 도움을 고르는 일을 돕지만, 권한, 가격, 핵심 구성 요소는 예측 가능한 규칙 아래 두어야 합니다.
기업이 쓸 수 있는 새로운 기능
제대로 된 개인화는 이 사람이 막 시작했는지, 이미 능숙하게 쓰는지에 맞춰 순서와 설명을 조정하는 것입니다. 왜 이 화면이 보이는지 언제든 설명할 수 있어야 하고, 사용자가 원하면 언제든 전체 화면으로 돌아갈 수 있어야 합니다.
프로젝트의 모습
시스템에는 누구나 끝까지 마칠 수 있는 핵심 여정(Core Journey)이 먼저 있고, 그 위에서 맥락에 따라 도움을 늘리거나 줄입니다. 초보자를 위한 온보딩, 숙련자를 위한 간소화된 화면, 업종별 설명 같은 것입니다. 중요한 버튼의 위치를 수시로 바꿔서는 안 되며, 부담을 확실히 덜어 주는 지점만 골라 조정해야 합니다.
가능한 기능
적응형 온보딩, 동적 입력 양식, 상황별 도움말, 다음 행동 추천(Next-best Action), 역할별 작업 공간, 선호 설정 기억, 접근성 모드, 초기화 및 표시 이유 안내 화면(Reset/Why-this UI) 같은 기능을 넣을 수 있습니다. 사용자는 시스템이 기억하는 데이터를 보고 통제할 수 있어야 하고, 원하지 않는 조정은 받지 않겠다고 선택할 수 있어야 합니다.
기술과 데이터
데이터 계층에는 이벤트 추적(Event Tracking), 사용자·프로필 저장소, 기능 플래그, 동의(Consent) 관리가 들어갈 수 있습니다. 규칙과 모델을 함께 써서 변형(Variant)을 고르고, 실험 플랫폼(Experimentation Platform)으로 효과를 측정합니다. 중요한 기능에는 AI가 멈췄을 때, 신규 사용자 데이터가 아직 적을 때, 사용자가 기억하는 데 동의하지 않았을 때도 작동하는 기본값이 있어야 합니다.
얻는 효과와 도입할 이유
신규 사용자는 더 빨리 배우고, 숙련된 사용자는 더 짧게 일을 끝내며, 고객지원팀은 역할에 맞지 않는 화면 때문에 생기던 문의를 덜 받습니다. 기업은 여러 버전을 따로 만드는 대신 실제 사용 행동을 보고 경험을 다듬을 수 있습니다. 다만 그 가치는 작업 성공률(Task Success)과 사용자의 이해도를 측정할 때 드러나며, 앱 체류 시간이나 클릭 수만으로는 알 수 없습니다.
- 점진적 안내(Progressive Guidance)는 숙련도에 따라 설명의 양을 조절합니다.
- 동적 도구 모음(Dynamic Toolset)은 현재 상태와 권한에 맞는 작업만 엽니다.
- 생성형 UI(Generative UI)는 작업에 맞는 데이터 구조나 요약을 만들며, 아무 제한 없이 레이아웃을 무작위로 만들어 내지 않습니다.
- 선호 설정 제어(Preference Control)로 사용자가 기억된 내용을 고치고 기본값으로 돌아갈 수 있습니다.
가상 사례
실제로 쓰이는 모습
여행 계획 앱이 초보자에게는 안내 질문과 자세한 설명을 보여 줍니다. 자주 쓰는 사용자는 목표를 짧게 말하면 고칠 수 있는 일정을 받습니다. 이동에 제약이 있는 가족에게는 확인 단계가 하나 더 붙습니다.
가상 사례로, 프로젝트 관리용 웹 애플리케이션을 회사 대표, 관리자, 신입 직원이 함께 씁니다. 대표는 예외 사항과 내려야 할 결정을, 관리자는 작업 대기열과 의존 관계를 보고, 신입 직원은 단계별 안내를 받습니다. 모두 같은 기록을 쓰며 화면 보기를 서로 바꿀 수 있습니다.
사용자가 추천을 자주 거절하거나 자꾸 뒤로 돌아가면, 시스템은 조정 수준을 낮추고 혼자 조용히 결론 내리는 대신 무엇을 원하는지 묻습니다. 아직 데이터가 없는 신규 사용자라면 나이, 기기, 위치처럼 틀릴 수 있는 신호 하나만 보고 역할을 짐작하지 않고, 팀이 설계해 둔 기본 여정(Default Journey)을 씁니다.
Adaptation Budget
시스템이 무엇을 바꿀 수 있는지, 무엇은 고정해야 하는지, 사용자가 어떻게 되돌아갈 수 있는지 정합니다.
탐색 메뉴나 중요한 작업을 바꾸기 전에 콘텐츠와 안내부터 조정합니다.
범위, 위험, 성과 측정 방법
개발팀 참고 · 기술 지표
Personalization은 사용자를 특정 방향으로 유도하거나 Filter Bubble을 만들 수 있습니다. 가격, 권한, 약정에 관한 부분은 공개하지 않은 채 조정하지 못하게 막아야 합니다. Task Completion, Error, Undo, Help Request, User Control과 그룹 간 결과 차이를 측정하고, 실험 때문에 Accessibility가 떨어지지 않았는지 확인합니다.
개인화는 필터 버블을 만들거나 경험을 예측할 수 없게 만들 수 있습니다. 그래서 기본값, 설명, 개인정보 보호, 접근성 테스트가 필요합니다.
개발팀 참고 · 기술 지표
추적할 지표: Task Success by Segment, Time-to-Proficiency, Preference Correction, Accessibility Error, Retention
- Discover: 실제 업무를 따라가며 일반 사례와 예외 사례를 모읍니다.
- Assist: AI가 초안을 쓰거나 추천하고, 통제는 사람이 계속 맡습니다.
- Act: 테스트 세트를 통과한 뒤 도구(Tool)를 하나씩 엽니다.
- Scale: 모니터링, 대체 경로(Fallback), 비용, 책임자가 갖춰지면 확대합니다.
실행 취소(Undo)와 도움 요청이 늘거나, 일부 사용자 그룹의 작업 완료가 줄거나, 고객지원팀이 사용자에게 화면을 설명하지 못하게 되면 조정 기능을 한발 물려야 합니다. 어떤 변형이든 핵심 여정을 망가뜨리지 않고 끌 수 있어야 합니다.
BUSINESS & PRODUCT READINESS
좋은 개인화는 설명할 수 있고, 통제할 수 있으며, 제품을 예측 가능하게 유지합니다
맥락 지도(Context Map)를 만들어 사용자가 직접 알려 준 정보, 관찰한 행동, 시스템이 추측한 내용을 나누십시오. 유형마다 동의, 보관 기간, 신뢰도가 달라야 합니다. 영향을 제한하려면 탐색 메뉴나 작업보다 안내와 콘텐츠부터 조정하십시오.
개발팀 참고 · 기술 지표
Default Experience와 원래 설정으로 되돌리는 방법을 정합니다. Segment별 테스트, Accessibility 테스트, 데이터가 아직 없는 Cold Start 테스트를 모두 합니다. Preference Correction도 측정하십시오. 사용자가 시스템을 자주 고쳐야 한다면 Personalization이 오히려 부담을 만들고 있다는 신호입니다.
사용자가 직접 제공한 데이터, 관찰할 수 있는 데이터, 시스템이 추론한 데이터를 나누는 맥락 지도를 만들고, 각각의 보관 기간과 보관 이유를 정하십시오. 그다음 적응 한도(Adaptation Budget)를 정해 여정마다 바뀔 수 있는 부분의 수를 제한하면, 사용자에게 익숙한 화면을 지키고 테스트 부담도 줄일 수 있습니다.
개발팀 참고 · 기술 지표
모든 Adaptive Rule에는 Owner, Hypothesis, Metric, Default, Rollback이 있어야 합니다. 사용자가 막힌다는 증거가 있는 Moment 한두 곳, 예를 들어 Onboarding이나 긴 Form에서 시작하십시오. 앱 전체를 한꺼번에 바꾸면 어느 부분이 효과를 냈고 어느 부분이 혼란을 일으켰는지 알 수 없습니다.
시스템은 무엇을 바꿀 수 있는가
사용자가 이유를 볼 수 있는가
메모리는 언제 만료되는가
기본값만으로도 모든 기능이 작동하는가
통제권을 빼앗지 않으면서 사용자를 돕는 똑똑한 기능을 설계합니다
DNA Maker는 제품팀과 함께 맥락·선호·적응 지도(Context/Preference/Adaptation Map)를 만들고, 무엇은 바뀔 수 있고 무엇은 고정해야 하는지 넘지 말아야 할 선을 정합니다. 개인화가 파워 유저나 모으기 쉬운 데이터에만 기대지 않도록 숙련도가 다른 여러 사용자를 인터뷰합니다.
UX팀은 초보자부터 자주 쓰는 사용자까지 아우르는 변형 프로토타입을 만들고, 설명과 제어 기능을 넣어 직접 시험해 볼 수 있게 합니다. 테스트에서는 참여도만 보지 않고 작업 성공률, 혼란 정도, 접근성을 봅니다.
DNA Maker는 역할과 맥락 조사를 진행하고, 어느 지점은 고정하고 어느 지점은 조정할지, 사용자가 어떻게 통제할지를 담은 적응형 경험 지도(Adaptive Experience Map)를 그립니다. 실제로 필요한 데이터·이벤트 모델, 동의, 메모리를 개발하기 전에 여러 변형의 프로토타입으로 사용자가 이해하는지부터 테스트합니다.
솔루션에는 적응형 웹·모바일 앱, 프로필·선호 설정 센터, AI 안내, 기능 플래그, 실험 대시보드가 들어갈 수 있고, 사용자 그룹별로 나눈 평가도 함께 갖춥니다. 신규 사용자가 늘 고객지원팀에 물어보게 되는 페이지가 하나 있다면, 그 페이지로 작은 실험을 하고 성공률, 사용자의 확신, 실행 취소 횟수를 측정할 수 있습니다.
저희는 적응형 웹·모바일 앱, 프로필·동의 센터, 메모리, 동적 지시문(Dynamic Instructions), 스키마 기반 생성형 UI, 실험·평가 플랫폼을 개발할 수 있습니다. 아키텍처는 모델 교체를 지원하고, 준비가 덜 되었을 때는 AI를 끌 수 있게 설계합니다.
사용자의 수준 차이가 커서 하나의 흐름으로는 모두에게 맞지 않는다면, DNA Maker가 조정할 순간을 1~2곳만 골라 먼저 시험해 본 뒤 시스템 전체에 개인화를 넣도록 돕습니다.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
맥락에 따라 바뀌는 화면, 메모리, 정해진 틀 안에서의 생성, 접근성을 이야기할 때 쓰는 용어입니다. 사용자가 조정 내용을 얼마나 알고 통제할 수 있는지, 데이터가 부족할 때 어떤 기본값을 쓰는지 물을 때 활용하십시오.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| Adaptive UI | 규칙에 따라 맥락에 맞춰 바뀌는 화면. 사용자가 주요 기능의 위치와 동작을 계속 예측할 수 있도록 바뀌는 범위를 제한하고 기본값을 두는 방식 | 초보자에게는 안내가 더 보입니다. | 어느 부분은 바뀌고 어느 부분은 고정됩니까? |
| Dynamic Profile | 프로필 상태에 따라 바뀌는 지시문과 도구 묶음. 시간에 따라 바뀌는 맥락까지 담으므로 출처, 최신성, 권한, 시스템이 잘못 이해한 정보를 사용자가 고칠 방법을 함께 갖춰야 하는 구성 | 사용자가 여행 모드를 고르면 일정 계획 도구가 열립니다. | 프로필은 누가 정합니까? |
| Memory | 시스템이 여러 번의 사용에 걸쳐 맥락을 기억하는 데 쓰는 데이터. 작업에 도움이 되는 것만 분명한 보관 기간을 두고 저장하며, 위험을 통제하려고 선호, 사실, 대화 기록을 나눠 두는 데이터 | 사용자의 동의를 받아 식이 제한을 기억합니다. | 사용자가 보고, 고치고, 지울 수 있습니까? |
| Guided Generation | AI의 결과물을 정해진 구조 안에 머물게 하는 방식. 생성 전에 구조, 선택지, 규칙을 AI에 주어 품질을 고르게 하고, 중요한 지점에서 사람이 검토할 여지를 남기는 방식 | 일정이 날짜별 활동 목록 형태로 돌아옵니다. | 데이터가 빠진 경우도 스키마가 처리합니까? |
| Accessibility | 다양한 사람이 쓸 수 있게 하는 설계. 나중에 덧붙이지 않고 색상, 글꼴, 키보드 조작, 스크린 리더부터 쉬운 언어까지 처음부터 설계에 넣고 실제 사용자와 테스트해야 하는 영역 | 스크린 리더와 큰 글자를 지원합니다. | AI가 UI를 바꾼 뒤에도 접근성 기준을 통과합니까? |
더 읽을거리(원문 자료): https://developer.apple.com/documentation/foundationmodels/adding-intelligent-app-features-with-generative-models