AI는 똑똑해졌는데, 기본이 안 되면 도입은 망가진다
아침에 나가려는데 날씨를 물었다. 평소엔 3초면 끝나는 질문이다.
오늘은 답이 길었다. 지역이 엉뚱했고, 체감 온도는 숫자만 던져놓고, “비 올 확률”은 말이 바뀌었다.
그래서 다시 물었다. 다른 표현으로.
이번엔 더 확신 있게 틀렸다.
타이머도 비슷했다. “25분”이라고 말했는데 2분짜리가 걸렸다.
리마인더는 아예 사라졌다. 설정해 둔 줄 알았는데, 아무 것도 오지 않았다.
그 순간 깨닫는다. 모델이 똑똑해졌는지 아닌지는 중요하지 않다. 기본 동작이 흔들리면, 사람은 ‘도구’가 아니라 ‘혼란’을 경험한다.
그리고 그 혼란을 기본값으로 밀어붙이는 순간, 반감이 시작된다.
(Computerworld의 Gemini 3년 회고를 읽으며 든 느낌도 비슷했다. 기능이 늘어도 기본이 흔들리면 신뢰가 무너진다. 참고자료)
기본이 흔들리면, 강제는 독이 된다
팀에서 AI 도입이 실패하는 장면은 의외로 화려하지 않다. 거창한 자동화가 폭발하는 게 아니라, 사소한 기본에서 삐끗한다.
- 짧은 질문에 답이 들쭉날쭉하고
- 같은 요청인데 결과가 매번 달라지고
- 실패했을 때 “그래서 내가 뭘 해야 하지?”가 비어 있다
이 상태에서 “이제부터는 이걸 기본으로 씁니다”를 선언하면, 조직은 두 가지로 갈린다.
한쪽은 억지로 적응하고, 다른 쪽은 조용히 회피한다.
그 사이에 업무는 늘어난다. 기능이 늘어서가 아니라, 확인과 재시도가 늘어서.
기본이 흔들릴 때는 강제보다 먼저 대체 경로와 후퇴 버튼이 있어야 한다.
내가 위키에 남기는 메모(세 문장)
첫 줄은 이거다. “반드시 맞아야 하는 기본 동작이 뭐냐.” 나는 “잘하면 좋겠다”가 아니라 “이건 반드시 맞아야 한다”를 먼저 적는다. 날씨/타이머/리마인더처럼 짧고 반복되는 기본 동작은, 한 번 틀리면 다음부터는 질문 자체가 줄어든다. 사람들이 도구를 안 쓰게 된다.
둘째 줄은 우회로다. “틀리면 어디로 돌아가냐.” 기본이 흔들릴 때는 멋진 해결책이 아니라 우회로가 필요하다. 예를 들어, 일정/리마인더는 원본 캘린더를 진실의 원천으로 두고(거기서만 수정), AI는 제안만 하게 둔다. 타이머/알림은 OS 기본 기능으로 돌아갈 수 있게 한다. 실패했을 때 돌아갈 자리가 있으면 불만이 ‘사고’로 자라지 않는다.
셋째 줄은 강제 범위다. “어디까지는 기본값, 어디부터는 절대 기본값 금지.” 나는 강제를 “전사 적용”으로 시작하지 않는다. 기본값으로 밀어붙일 범위와 물러날 범위를 문장으로 가른다. 예를 들어, 요약/초안은 기본값으로 두되, 예약/결제/발송 같은 ‘되돌리기 어려운 버튼’은 절대 기본값으로 두지 않는다. 기본이 안정화되기 전까지는, 강제보다 선택권이 우선이다.
결정 기준(3개)
되돌리기 되돌리기가 30분(예시 임계값) 안에 안 되면, 기본값으로 밀면 안 된다. 그건 기능 문제가 아니라 사람의 심리 문제다. “망해도 돌아갈 수 있다”가 있어야 시도한다.
대체 경로 대체 경로가 없으면, 작은 오류도 큰 장애가 된다. 대체 경로는 ‘성능이 같은 대안’이 아니라 ‘기능을 줄인 안전 모드’여도 된다.
불만 폭발 지점 불만은 무작위로 폭발하지 않는다. 기본 동작 중에서도 “자주 쓰는 것”과 “되돌리기 어려운 것”에서 먼저 터진다. 그 두 축이 겹치는 기능은 강제 대상이 아니다.
기본이 흔들릴 때, 도입 설계는 여기서 시작한다
기본 동작의 품질이 흔들리는데도 “이제는 된다”는 표정으로 밀어붙이면, 사람들은 금방 학습한다. ‘안 쓰는 게 낫다’로.
그래서 도입 설계의 첫 질문은 “무슨 기능을 넣을까”가 아니라 “기본이 흔들릴 때 어디로 돌아갈까”여야 한다.
그리고 한 번 기대를 올려놓고 못 맞추면, 기술팀만의 문제가 아니다. 조직 구조까지 흔들린다.
나쁜 소식은 기본을 만들기 어렵다는 거고, 좋은 소식은 기본만 잡으면 나머지는 천천히 올려도 된다는 거다.
참고자료
- Computerworld — Google’s Gemini, 3 years in: Is this the future we wanted?
- https://www.computerworld.com/article/4136922/google-gemini-3-years.html
- Computerworld — Jack Dorsey shrinks Block to ‘intelligence‑native’ model, cutting 4,000 jobs
- https://www.computerworld.com/article/4138423/jack-dorsey-shrinks-block-to-intelligence%e2%80%91native-model-cutting-4000-jobs.html
실전 적용
기본 동작이 흔들릴 때 팀이 제일 자주 하는 실수는 “좀 더 써보면 익숙해질 거예요”로 밀어붙이는 거다. 익숙해지는 건 사용자가 아니라 ‘회피하는 법’이다. 실전에서는 화려한 기능보다, 기본이 삐끗했을 때 사람들이 어떤 행동을 하게 되는지(반복 질문, 재시도, 손으로 되돌리기)를 먼저 고쳐야 한다. 아래는 내가 도입 초기에 실제로 붙여두는 장치들이다. 문서로 교양 있게 쓰기보다, 당장 다음 주에 사고를 덜 내게 만드는 목적.
- 기본 동작을 “짧은 질문 세 개”로 고정해 둔다: 날씨/타이머/리마인더처럼 팀마다 다르게 쓰는 걸 하나로 맞추고, 이 세 개가 흔들리면 전면 확대를 멈춘다.
- 실패를 숨기지 말고 표지판을 단다: “지금은 불안정합니다” 같은 안내보다, 어디서부터가 불안정한지(예: 일정 생성/수정/삭제 중 무엇)를 한 줄로 적어 둔다.
- 대체 경로를 ‘원본 시스템’으로 정한다: 캘린더는 캘린더에서만 수정, 타이머는 OS 기본 타이머로 돌아가게. AI는 제안/초안까지만.
- 확정(되돌리기 어려운) 동작은 기본값에서 빼놓는다: 발송/예약/결제 같은 버튼은 “항상 마지막에 한 번 더 확인”이 붙게 만든다.
- 불만을 수집하는 창구를 하나로 묶는다: 채팅방에 흩어지면 감정만 남는다. 짧은 양식(언제/무슨 말/무슨 결과)으로 모으게 한다.
- “안 쓰는 사람”을 방치하지 않는다: 안 쓰는 이유가 대개 ‘무서움’이거나 ‘몰라서’다. 그 이유를 해결하지 못하면 조직이 두 갈래로 갈라진다.
흔한 함정은 이 두 가지다. 둘 다 초기엔 성과처럼 보인다.
- 함정 1) 재시도를 사용자의 몫으로 남겨두기: 반응이 없으면 더 누르고, 더 누르면 더 망가진다.
- 함정 2) “기본은 나중에”라고 미루기: 기본이 무너지면, 추가 기능은 도입을 돕는 게 아니라 변명만 늘린다.
댓글
댓글 쓰기