AI를 켰는데, 답은 켜기 전과 똑같았습니다

들어가며 — 한 화면에 뜬 모순된 두 문장

개인적으로 만들어 쓰는 연습용 앱에 AI 기능을 하나 붙였습니다. 그전까지는 제가 짜 넣은 규칙대로만 조언하던 기능인데, 이번에 상황을 AI에게 넘기고 판단을 받아오게 바꿨습니다.

붙이고 나서 늘 하는 확인을 했습니다. 일부러 틀린 키를 넣고 켜 보는 것입니다. 잘 될 때 잘 되는지는 누구나 봅니다. 확인해야 하는 건 안 될 때 무슨 일이 벌어지는가입니다.

결과는 좋았습니다. 앱이 죽지 않았고, 조용히 원래 규칙 기반 조언으로 돌아갔습니다. 콘솔에 에러도 없었고 키가 새지도 않았습니다. 설계대로였습니다.

그런데 화면을 다시 보다가 걸렸습니다. 한 화면에 이렇게 적혀 있었습니다.

코치 · 규칙 기반
지금은 자리를 굳히고 다음 위협을 준비할 때입니다.

코치 엔진
지금 코치는 AI로 돌고 있습니다.

같은 화면입니다. 위에서는 규칙 기반이라고 하고, 아래에서는 AI로 돌고 있다고 합니다. 둘 중 하나는 거짓말입니다.

1. 표시등이 읽고 있던 건 설정이었습니다

제가 시킨 조건은 이랬습니다.

스위치가 켜져 있고, 키가 들어 있고, 한도가 남아 있으면 → “AI로 돌고 있습니다”라고 표시한다.

논리에 오류는 없습니다. 검사도 전부 통과했고요. 그런데 저 조건은 “켜져 있다”의 조건이지 “돌고 있다”의 조건이 아닙니다.

키가 틀리면 켜져 있어도 안 돕니다. 망이 끊겨도 안 돕니다. 서버가 느려 응답이 안 와도 안 돕니다. 한도에 걸려도, 권한이 막혀도 마찬가지고요.

여기에 이 글의 뼈대가 있습니다.

설정은 의도입니다. 그리고 의도는 실패해도 그대로 남습니다.

스위치를 켠 사실은 호출이 실패해도 사라지지 않습니다. 그래서 설정을 근거로 삼은 표시등은 실패한 뒤에도 계속 켜져 있다고 말합니다. 화면이 거짓말을 하기로 마음먹은 게 아니라, 처음부터 다른 것을 보고 말하고 있었던 겁니다.

그리고 이 어긋남은 외부에 무언가를 물어보는 기능을 붙이는 순간 예외 없이 생깁니다. 망이 끼어드는 순간부터 설정과 현실은 언제든 갈라질 수 있으니까요.

2. 폴백은 조용합니다 — 그래서 “AI 별거 없네”로 착지합니다

여기서 얄궂은 대목이 있습니다. 저 앱이 실패했을 때 규칙 기반으로 되돌아간 건 잘 만들어진 동작입니다. 이걸 폴백이라고 부르는데, 요즘 웬만한 도구는 다 이렇게 되어 있습니다. AI 호출이 실패했다고 화면이 멈추거나 빨간 에러를 뿜으면 쓸 수가 없으니까요.

문제는 폴백이 조용하다는 것입니다. 에러도 없고, 경고도 없고, 빈 화면도 없습니다. 그냥 예전 품질의 결과가 나옵니다.

그래서 사용자 쪽에서 보이는 장면은 이렇게 됩니다.

켜기 전에도 답이 나왔습니다.
켠 뒤에도 답이 나옵니다.
두 답이 별로 다르지 않습니다.

여기서 사람이 내리는 결론은 하나로 정해져 있습니다. “AI 붙였는데 별거 없네.”

전에 우리가 AI 도구에 실망하는 이유를 쓰면서 실망의 원인이 대개 기대의 방향에 있다고 했습니다. 오늘 짚는 건 그보다 훨씬 앞쪽, 훨씬 김빠지는 자리입니다.

AI가 실망스러웠던 게 아니라, AI가 답한 적이 없었던 경우가 섞여 있습니다.

이게 왜 무서우냐면, 이 결론은 자기 자신을 굳히는 방향으로 작동하기 때문입니다. 별거 없다고 판단한 사람은 더 안 씁니다. 안 쓰니까 무엇이 잘못 물려 있었는지 영영 모릅니다. 도구는 계속 켜져 있다고 표시하고 있고요.

두 그림의 실패는 똑같습니다. 다른 것은 화면이 무엇을 보고 말했는가뿐입니다.

3. 개인이 만든 앱만의 이야기가 아닙니다

제 이야기는 혼자 만든 작은 앱에서 나왔지만, 구조는 업무 도구에서 그대로 반복됩니다. 공통 조건은 딱 하나입니다 — 연결이 끼어 있고, 실패했을 때 대신 답해 줄 무언가가 있는 경우.

사내 문서를 연결해 둔 챗봇이, 권한이 걸린 폴더를 조용히 건너뛰고 일반 지식으로 답합니다. 화면에는 여전히 그 문서함이 연결되어 있다고 표시됩니다.
검색 기능을 켜 두고 물었는데 실제 검색은 돌지 않고, 모델이 이미 알고 있던 내용으로 답합니다. 문장은 오히려 더 매끄럽습니다.
자동화 워크플로 중간의 AI 단계가 실패했는데, 뒤 단계가 기본값을 물고 그대로 끝까지 흘러갑니다. 실행 기록에는 성공으로 남습니다.
특정 모델을 골라 뒀는데 한도나 부하 때문에 다른 것이 대신 답합니다. 고른 이름은 화면에 그대로 있습니다.

네 장면 모두 에러가 나지 않습니다. 그리고 네 장면 모두 결과물이 그럴듯합니다. 티가 나는 건 실패가 아니라 품질인데, 품질은 원래 들쭉날쭉하니까 의심의 대상이 되지 않습니다.

조직 단위로 올라가면 이게 더 안 보입니다. “AI 도입했는데 효과가 없다”는 말이 올라올 때 우리는 보통 두 가지를 의심합니다. 사람이 안 쓰거나, 도구가 별로거나. 세 번째 가능성 — 켜졌다고 표시된 채로 안 돌고 있었을 가능성 — 은 아무도 의제에 올리지 않습니다. 화면이 이미 잘 돌고 있다고 말해 줬기 때문입니다.

4. 무엇을 보고 답했나, 그리고 애초에 답하기는 했나

이 블로그에서 비슷한 자리를 한 번 다뤘습니다. AI가 무엇을 보고 답했는지 아무도 알려주지 않는다는 글이었죠. 자료를 연결해 두면 실제로 무엇이 넘어갔는지 화면에 안 나온다는 이야기였습니다.

겹쳐 보이지만 다른 층입니다. 선을 그어 두겠습니다.

그 글에서 AI는 돌았습니다. 다만 반쪽짜리 재료를 보고 돌았고, 무엇을 봤는지가 화면에 없었습니다. 빠진 것은 근거입니다.
오늘 이야기에서 AI는 아예 안 돌았습니다. 그런데 화면은 돌고 있다고 적어 뒀습니다. 빠진 것은 실행 자체입니다.

한 문장으로 줄이면 이렇습니다. 그 글은 “무엇을 보고 답했나”를 물었고, 오늘은 그보다 한 칸 앞의 “애초에 답하기는 했나”를 묻습니다.

순서가 중요합니다. 근거를 아무리 잘 검증해도, 답한 주체가 다르면 그 검증은 엉뚱한 것을 보고 있는 셈이 되니까요.

AI가 ‘없습니다’라고 하면 그건 못 찾았다는 뜻이라고 썼던 글과도 같은 계열입니다. 셋 다 화면에 없는 것에 관한 이야기입니다. 무엇을 못 찾았는지, 무엇을 못 읽었는지, 무엇이 실패했는지 — 이 셋은 공통적으로 말해 주지 않으면 없는 것처럼 보입니다. 그리고 잘 만들어진 도구일수록 이것들을 매끄럽게 감춥니다.

5. 그래서 무엇을 하면 되나

넷으로 나눠 적겠습니다. 앞의 둘은 오늘 당장 할 수 있는 일입니다.

첫째, 상태 표시를 믿지 말고 답에게 출처를 물어봅니다. 켜졌다는 표시는 설정을 읽은 것이고, 출처는 결과에 붙어 나옵니다. “이 답, 어디서 나온 거야 — 검색했으면 링크, 문서를 봤으면 파일 이름과 어느 대목인지 같이 줘.” 출처가 안 붙어 나오면 그 기능이 안 돌았을 가능성부터 셉니다. 이건 도구를 뜯어보지 않고 화면에서 할 수 있는 확인입니다.

둘째, 한 번은 일부러 틀리게 해 봅니다. 제가 이 문제를 잡은 방법이 이것 하나였습니다. 키를 틀리게 넣거나, 연결을 잠깐 끊거나, 권한 없는 자료를 물어보는 겁니다. 그리고 그때 화면이 뭐라고 하는지를 봅니다.

화면이 아무 말도 안 하고 답만 계속 나온다면, 그 도구는 실패를 조용히 삼키고 있습니다. 앞으로 나오는 결과에 그 가능성을 얹어 두고 써야 합니다.
화면이 “지금은 이렇게 답하고 있습니다”라고 바꿔 말한다면, 그 도구의 상태 표시는 믿어도 됩니다.

30초짜리 점검이고, 도구를 고를 때 성능 비교보다 실질적인 판단 재료가 됩니다.

셋째, 만드는 쪽이라면 근거를 갈아 끼웁니다. 상태 표시의 조건을 “켜져 있나”에서 “마지막 답이 실제로 어디서 나왔나”로 바꿉니다. 그리고 폴백했으면 숨기지 말고 그렇게 말하게 합니다. 제가 고친 문장은 이랬습니다.

지금 코치는 규칙 기반(오프라인)으로 돌고 있습니다.
⚠ 켜져 있지만 지금 조언은 규칙 기반입니다 — 아직 응답 전이거나, 호출이 실패해 되돌아갔습니다.

고치고 나서 얻은 게 하나 더 있었습니다. 사용자가 키가 틀렸다는 사실을 알 수 있게 됐습니다. 원래대로였으면 “켰는데 왜 답이 예전이랑 똑같지” 하고 영영 몰랐을 일입니다. 정직한 표시는 사용자를 불안하게 만드는 게 아니라, 고칠 수 있게 만듭니다.

넷째, 조직이라면 도입 점검표에 한 줄을 넣습니다. “쓰고 있는가” 옆에 “돌고 있는가”를 둡니다.

로그인 수나 사용 횟수는 사람이 켰다는 사실을 셀 뿐이고, 그건 앞에서 본 그 설정과 같은 종류의 숫자입니다. 실제로 물어봐야 할 건 따로 있습니다. 연결해 둔 자료가 실제로 읽히고 있는지, 실패한 호출이 몇 건인지, 그 실패가 사용자에게 보였는지.

어제 규칙을 실행되는 형태로 내려놓는 이야기를 썼는데, 이것도 같은 성질입니다. 안 돌고 있다는 사실이 누군가의 성실함이 아니라 화면에 의해 드러나야 합니다.

여기서 한 번 데인 결함은 주의가 아니라 장치로 막는다고 썼던 글과 헷갈릴 수 있는데, 층이 다릅니다. 그 글은 결과물이 틀렸을 때 그것을 걸러 내는 장치였고, 오늘은 결과물이 맞든 틀리든 그것을 누가 만들었는지를 화면에 띄우는 일입니다. 검사는 나온 물건을 보고, 상태 표시는 그 물건을 만든 손을 봅니다.

마무리 — 켜는 건 우리가 하고, 도는 건 도구가 합니다

AI를 일에 붙이는 일이 흔해졌습니다. 그런데 붙이고 나서 생기는 문제는 대개 AI 성능 문제가 아닙니다. 연결부가 정직한가의 문제입니다. 연결됐다고 표시했는데 실은 아니었다든가, 읽고 있다고 했는데 안 읽고 있었다든가 하는 것들이요.

그리고 이건 코드를 몰라도 잡을 수 있는 종류의 문제입니다. 필요한 건 읽는 실력이 아니라 화면을 한 번 의심하는 습관이니까요. 저도 코드를 뜯어서 잡은 게 아니라, 틀린 키를 한 번 넣어 보고 화면에 뜬 두 문장이 서로 안 맞는 걸 눈으로 봐서 잡았습니다.

켜는 것까지가 우리 일입니다. 도는 것은 도구의 일이고요. 그런데 우리는 켠 사실을 근거로 돌고 있다고 믿습니다. 화면이 그렇게 적어 줬기 때문에.

오늘 쓰시는 AI 기능 중에 연결해 둔 것이 하나라도 있다면, 한 번만 일부러 틀리게 해 보십시오. 화면이 그때 뭐라고 하는지가, 그 도구를 얼마나 믿어도 되는지를 알려줍니다.

본문의 사례는 필자가 개인적으로 만들어 쓰는 연습용 앱에서 나온 것이며, 특정 기업·클라이언트와 무관합니다. 해석과 현장 관점은 박상훈의 견해입니다.