제가 자주 가는 카페에는 알바생이 두 명이 있는데 한 명은 눈치가 없고, 한 명은 눈치가 저 세상급입니다.

사실 눈치 없는 직원은 제가 주문할 때 저를 쳐다보지도 않아요. 포스기만 쳐다보며 "주문하시겠어요? 매장이세요, 포장이세요?"라고 맨날 똑같이 물어봅니다.

눈치빠른 직원은 저랑 아이컨택부터 시작하죠. 제 손에 작업 중인 노트북이 들려 있으면 "머그컵에 드리면 될까요?"라고 물어보고, 제가 짐이 많아 보이면 "자리 먼저 잡고 천천히 주문하러 오셔도 됩니다."라고 먼저 제안해요.

이 두 직원을 AI에 빗댄다면 한 명은 컨텍스트(Context)를 제대로 활용하고 있고 한 명은 그러지 못하고 있어요. 이 ‘눈치 빠른 AI’를 만드는 스킬인 ‘컨텍스트(Context)’가 바로 오늘의 주제이자, 4부작의 마지막 주제입니다.

1. 컨텍스트(Context)란?

우리는 지난 HITL편 끝에서 궁금증을 하나 가지고 끝났죠. AI가 사람에게 도와달라고 손드는 이유의 상당수가 '확신이 없어서'인데, 'AI가 애초에 상황을 제대로 알고 있었다면 손을 들 일이 없었을텐데'하는 질문이었어요.

예를 들어서 "김민수한테 전화걸어"라는 사용자의 요청이 있었을 때, AI는 그 '김민수'가 회사 '김민수'인지 고등학교 동창 '김민수'인지 알 수가 없어서 되물을거예요. 그런데 사용자가 어제부터 오늘까지 회사 '김민수'랑 이메일에서 계속 이야기하고 있는 상황이라는 걸 AI가 알고 있었다면? 굳이 손들지 않고 "회사 '김민수'에게 요청하시는 것 맞죠?"라고 먼저 짚었을거예요.

이렇게 AI가 답변에 참고할 수 있는 ‘지금 이 순간의 상황’을 컨텍스트(Context)라고 부릅니다. 컨텍스트가 없으면 AI는 사람에게 도와달라고 손을 듭니다.

2. ‘기억력 좋은 AI’와 ‘눈치 빠른 AI’는 달라요.

그런데 컨텍스트라고 하면 많은 사람들이 착각하는게 있습니다.

아니요. 그건 컨텍스트가 아니라 메모리(Memory)입니다. 둘은 완전히 다른데 똑같다고 오해하시는 분들이 많습니다.

메모리는 '기억을 꺼내오는 것'이에요. ChatGPT에 “나는 채식주의자야”라고 말해두면, 나중에 식당을 추천할 때 그걸 참고하죠.

컨텍스트는 '지금 이 순간을 알아채는 것'이에요. 유저가 지금 어떤 화면을 보고 있는지, 방금 뭘 하다 왔는지, 지금이 몇 시인지, 어디에 커서를 멈추고 있는지와 같은 것들이요. 유저가 입으로 또는 텍스트로 요청하지 않은 그 나머지의 실시간 상황을 AI가 스스로 읽어내는 것입니다.

카페로 치면 이래요.

3. AI에게 쥐여줄 수 있는 컨텍스트의 2가지 종류와 구현 방법

그럼 기획자는 어떻게 AI에게 컨텍스트를 전달해 줄 수 있을까요? 그 컨텍스트의 종류에 따라 2가지 방식이 있습니다.

기획자는 "우리 서비스에서 AI가 더 눈치 빠르려면, 어떤 실시간 정보를 읽어야 하는가?"를 판단해서 아래 두 가지 중 하나의 방식으로 설계해야 합니다.

A. 눈에 보이는 컨텍스트 — 보이는 화면

첫 번째는 유저가 눈앞에서 직접 보고 있는 시각적 맥락 컨텍스트입니다. 이때에는 실시간으로 화면을 공유하거나 올려받는 방식으로 컨텍스트를 전달합니다. 즉, AI가 실시간 화면을 읽어야만 요청을 처리할 수 있는 상황에서 유저가 지금 보고 있는 화면을 AI가 함께 보게 만드는 방식입니다. 

이 방식은 유저가 지금 눈앞의 무언가에 대해 도움을 요청하는 순간에 쓰면 좋습니다. 예를 들어 AI에게 "이 계약서 요약해줘", "이 화면에서 뭘 눌러?" 같은 요청을 하는 경우에요.

이 방식은 직관적이기도 하고 이미 제공되고 있는 서비스들이 많아서 참고하기 좋습니다. 예를 들어 아래와 같은 대표적인 서비스들이 있어요.

Google Gemini의 Live

B. 눈에 안 보이는 컨텍스트 — 안 보이는 데이터

두번째는 유저 눈에는 안 보이지만, 폰이나 앱 시스템에 쌓여 있는 백그라운드 맥락(메시지, 위치, 시간, 사진첩 등) 컨텍스트입니다. 이때에는 기기 안의 정보(Local Data)를 공유하거나 올려받는 방식으로 이 컨텍스트를 전달받습니다.

이 방식은 유저가 굳이 말 안 해도, 알아서 챙겨주면 놀라운 순간에 쓰면 좋습니다. "엄마한테 온 메시지에 답장해줘"라는 요청에는 굳이 물어보지 않아도 엄마와의 직전 대화를 참조해야겠죠? "지금 퇴근할건데 집 도착 예정시간 남편한테 보내줘"라는 요청이면 굳이 물어보지 않아도 현재 내 위치를 참조해서 시간을 계산하는거죠.

다만 이 방식은 좀 더 세심한 기획적인 접근이 필요합니다. “내 대화를 다 볼거라고? 내 위치도 항상 체크하고?”라는 민감한 소리가 바로 나오니까요. (아래 단락에서 구체적인 설계 포인트를 짚어볼 예정이에요.)

4. 하지만 컨텍스트를 서버로 보낼 때 부딪히는 '3가지 벽'

다만 여기서 치명적인 문제가 발생합니다. 이 글을 읽는 기획자분들이 만드는 서비스는 대부분, OpenAI나 Google이 제공하는 ChatGPT, Gemini같은 클라우드 AI 모델을 가져다 쓰고 있을거예요. 

유저 폰에서 수집한 실시간 컨텍스트(화면이든 로컬 데이터인 위치, 메시지든)를 저 멀리 있는 AI 서버로 매번 보내서 판단을 받아오려고 하면 3가지 큰 벽에 부딪힙니다.

첫째는 비용의 벽입니다. 유저의 화면을 실시간으로 계속 서버로 보낸다고 생각해봐요. 화면은 1초에도 몇 번씩 바뀌죠. 이걸 매번 AI에게 보내 처리하면 토큰 비용이 눈덩이처럼 불어나요. 

두번째는 속도의 벽이에요. 서버는 멀리 있어요. 정보를 보내고, AI가 생각하고, 답변을 돌려받는데 시간이 걸려요. 눈치라는 건 즉각적이어야 하는데, “방금 뭐 보고 있었죠?”에 3초 뒤에 답하면 이미 눈치가 아니에요.

마지막 세번째는 보안의 벽이에요. 이게 제일 커요. 유저의 화면엔 비밀번호, 카카오톡 대화, 계좌번호가 다 떠 있을 수 있어요. 이 민감한 걸 전부 남의 서버로 보낸다고요? 유저가 기겁하죠. 개인정보 문제로 서비스가 통째로 막혀요. 

5. '3가지 벽'을 넘는 기술, 안심하고 쓰게 하는 UX

따라서 기획자는 AI에게 눈치를 줄 때 두 가지를 함께 설계해야 해요. 3가지 벽을 넘어설 기술적 해법과, 유저가 안심하고 쓰게 만드는 UX 안전장치입니다.

A. 기술적인 해법

기술과 여건이 허락된다면 가장 좋은 방식은 앞서 얘기한 온디바이스 모델을 사용하는 방법이에요. 민감 데이터를 다루는 가장 확실한 방법은 아예 밖으로 안 내보내는 것이니까요.

온디바이스 모델은 쉽게 말하면 'AI를 서버가 아니라 내 폰 안에 넣는 것'이에요.

지금까진 AI가 저 멀리 큰 서버에 살았어요(이걸 클라우드에 있다고 하죠). 질문하면 네트워크 타고 갔다가 답이 돌아왔죠. 온디바이스 AI는 작고 가벼운 AI를 기기 안에 직접 심어요. 그럼 정보가 밖으로 안 나가요. 세 개의 벽도 한 번에 풀려요. — 서버로 안 보내니 공짜에 가깝고(비용), 기기 안에서 바로 처리하니 즉각적이고(속도), 민감정보가 폰 밖으로 안 나가니 안전(보안)하죠.

대신 트레이드오프가 있어요. 폰 안에 들어갈 만큼 작은 AI이어야 해서 서버의 거대한 AI만큼 똑똑하진 않아요. 그래서 요즘 서비스들은 가벼운 일은 폰 안 AI가, 무거운 일은 서버 AI가 나눠 맡는 식으로 써요. 애플 인텔리전스도 이 구조예요. 간단한 요약은 폰 안의 약 30억 개짜리 작은 모델이 처리하고, 복잡한 건 애플의 보안 서버로 넘겨요. 

우리 서비스 플로우가 복잡해서 전체 플로우를 온디바이스 모델로 구현하기 어렵다면, 민감 정보를 다루는 부분만 로컬의 경량 온디바이스 모델이 처리하고, 그 정제본을 클라우드 모델에 올리는 방법도 고민해볼 수 있어요. (‘정제 게이트웨이’라고 불러요.)

B. UX적 안전장치 설계

앞의 기술적 해법이 '벽'을 넘는 얘기였다면, 이건 결이 조금 달라요. 기술로 아무리 안전하게 처리해도, 유저 입장에선 '내 위치를, 내 메시지를 가져간다'는 사실 자체가 불안하거든요. 특히 위치나 메시지 같은 기기 안의 데이터(Local Data)를 컨텍스트로 올려받을 때는, 이 불안을 덜어주는 UX 설계가 필수예요.

첫째로, 끄고 되돌릴 수 있는 기능을 넣어주세요. "언제든 끌 수 있다"는 감각만으로도 민감도가 확 낮아져요. 그리고 참조한 원본은 쓰고 나면 남기지 않는다는 원칙을 가져가는게 좋아요. 원본을 보유하고 있기 보다 다음 요청 때 또 필요하면 그때 다시 읽는 방식인거죠.

둘째로, 권한 스코핑도 필요해요. 예를 들어 사진첩에 대한 접근이 필요하면 사진첩 전체 접근 권한을 요구하지 않고 유저가 고른 사진에만 접근하도록 하는거죠.

셋째로, 권한은 한 번에 몰아받지 않고 실제로 그 기능을 쓰는 순간에 물어봐주세요. 앱을 켜자마자 "위치 접근을 허용하시겠어요?"라고 던지면 유저는 이유를 몰라 거절해요. "집 도착 시간 보내기"를 누른 그때 물어보면, 유저가 왜 필요한지 납득한 상태라 허용률도 높고 덜 불쾌해요.

마지막으로 유저가 권한을 거절했을 때도 앱이 동작해야 해요. 위치를 안 주면 "목적지를 직접 입력해주세요" 로 자연스럽게 넘어갈 수 있는 설계가 필요합니다. 권한을 거절했더니 서비스가 먹통이 되면 유저는 “오, 보안이 철저한 서비스네”라고 생각하는게 아니라 “서비스 완전 별로네”라는 나쁜 기억만 남겨요.

6. 천재 AI도 눈앞의 쪽지 하나엔 장사 없습니다.

다시 처음의 두 알바생 이야기로 돌아가 볼게요.

눈치 없는 직원이 지식이 부족한 건 아니었어요. 메뉴판도 완벽하게 외웠고, 어떤 음료든 척척 만들죠. 그런데도 매번 건조하게 "매장이세요, 포장이세요?"를 묻는 이유는 딱 하나예요. 눈앞의 손님을 안 봤기 때문이에요. 손에 든 노트북, 지친 표정, 많은 짐 — 그 '지금 이 순간'의 신호를 못 읽은 거죠.

AI도 똑같아요. 백과사전을 통째로 외운 AI도, 눈앞의 포스트잇을 못 보면 엉뚱한 답을 합니다. 아무리 똑똑한 모델을 붙여도, 유저가 지금 무엇을 보고 있고 방금 뭘 하다 왔는지를 못 읽으면 결국 "회사 김민수예요, 동창 김민수예요?"를 되묻는 눈치 없는 직원이 되고 말아요.

그래서 컨텍스트 설계란, 결국 AI에게 그 '포스트잇'을 어떻게 쥐여줄지 정하는 일이에요.

어떤 실시간 정보를 읽게 할지(화면? 위치?), 그걸 어디서 처리할지(서버? 온디바이스?), 그리고 민감한 정보를 어떻게 안전하게 다룰지 — 이 결정들이 모여 '눈치 빠른 AI'와 '눈치 없는 AI'를 가릅니다.

7. 4부작을 마치며 — 네 개의 조각이 만드는 AI 서비스

네 편에 걸쳐 우리는 AI 서비스를 이렇게 조립했어요.

한 장면으로 합쳐볼게요. 유저가 "김민수한테 방금 그 파일 보내줘"라고 말했다고 가정해 볼게요. 잘 설계된 AI라면

유저는 한 문장을 던졌을 뿐인데 네 개의 설계가 동시에 움직인 거예요. 그리고 이 네 가지 중 AI가 얼마나 똑똑한지에 관한 건 하나도 없어요. 전부 "AI를 언제, 무엇을, 어디까지 하게 둘 것인가"를 정한 결정이죠

좋은 AI 서비스는 똑똑한 모델을 붙여서 완성되는 게 아니라, 그 모델이 일할 '자리'를 설계하는 데서 완성돼요. 그리고 그 자리를 정하는 사람이 바로 기획자입니다.

4부작을 함께 읽어주셔서 감사합니다.

📮 다음 호 예고

[28호] 무엇이든 만들 수 있다면, 무엇을 만들 것인가

누구나 같은 AI로 무엇이든 빠르게 만들 수 있게 되자, 세상은 그럴듯하지만 평범한 것으로 넘쳐나기 시작했습니다. 요즘 말하는 'AI 슬롭(slop)'이죠. 만들기가 쉬워질수록 '무엇을·왜 만들 것인가'라는 오래된 질문은 오히려 더 무거워집니다. 실행이 흔해진 시대에 중요해진 것들을 살펴보고, AI가 대신할 수 없는 나만의 강점을 찾아봐요!