AI 직원은 왜 거짓말을 하나 — 말로 시킬 수 없는 것과 배관으로 시킬 것

“알겠어”가 가장 위험한 순간

전날 나는 작전회의를 만들었다. 애니가 아침마다 제안 카드를 올리고, 나는 [관심]을 누르는 것만으로 일을 진행시키는 구조였다. 비서에게 매번 “뭘 하면 좋을까”를 묻는 대신, 직원이 먼저 일을 들고 오게 만들자는 시도였다.

하루 써보니 문제는 모델의 지능이 아니라 역할과 배관의 경계였다. 직원은 카드에 적힌 일을 실제로 넘겨줄 수 없는데, 화면은 마치 할 수 있는 것처럼 보였다. 내가 물으면 그 직원은 모른다고 해야 했지만, 실제로는 없는 배선을 그럴듯하게 설명했다.

즉, 이 사건의 핵심은 “AI가 왜 멍청하게 굴었나”가 아니다. 말로 시킬 수 없는 일을 말로 시킨 구조가 문제였다.

아침 제안은 전부 집안 살림이었다

첫 불만은 제안 품질이었다. 작전회의가 아침에 올린 카드들은 전부 안쪽을 향하고 있었다.

내부 버그 조사: 내가 쓰는 레이더의 중복 문제를 보겠다는 제안.
새 모델 소식 확인: 바깥 소식처럼 보였지만 실제로는 내 시스템 반응 점검에 가까웠다.
자기 카드 품질 점검: 작전회의 자신을 더 잘 만들자는 제안.

나는 이걸 유의미한 생산으로 보지 않았다. 내부 살림 결함은 탐색꾼 애니의 일이 아니라 대장 비서 라이너 쪽 일이다. 애니에게 기대한 것은 집 안을 고치는 일이 아니라, 바깥에서 가져온 재료로 내 일을 전진시키는 것이었다.

원인은 애니가 아니라 전날 내가 만든 렌즈였다. 제안 재료를 내 프로필, 위키, 보드, 장부 같은 내부 상태로만 먹였으니 탐색꾼이 집 안만 뒤진 것이다. 같은 공공 API 이야기도 방향이 갈린다.

관점	판단
“네 레이더에 버그가 있다”	내부 수리라서 애니가 물어올 일이 아니다
“레이더에 붙일 새 공공 API가 열렸다”	바깥 발굴이고, 내부 재료는 조준 렌즈로만 쓰인다

그래서 렌즈를 고쳤다. 바깥 몸통이 없는 제안은 금지하고, 내부 재료는 수리 대상이 아니라 조준 렌즈로만 쓰게 했다. 생산 아이디어도 우선순위로 올렸다. 유튜브 쇼츠 아이디어처럼, 누르면 실제 산출물로 이어질 수 있는 일을 매일 한 번은 시도하게 했다.

새 렌즈는 바로 차이를 냈다

크론을 기다리지 않고 바로 실사격했다. 자동화는 시각표가 아니라 스크립트다. 검증할 수 있으면 당장 쏴보는 쪽이 맞다.

그날은 마침 API 장애가 겹쳤다. 덕분에 다른 버그도 같이 잡혔다. 장애 문구가 정상 결과처럼 채널에 게시될 뻔했고, 실패 경로 일부는 스레드에 아무 말도 남기지 못했다. 상주 노동자는 남의 API에 목줄이 걸려 있다. 목표는 한 번도 안 넘어지는 것이 아니라, 넘어질 때 쓰레기를 뿌리지 않고 조용히 실패하는 것이다.

렌즈 수정 뒤 결과는 명확했다.

구간	결과
오전 구 렌즈 3건	내향 3건
새 렌즈 실사격 3건	내향 0건, 생산 제안 2건, 전부 바깥 URL 근거

여기까지만 보면 작전회의는 좋아졌다. 그런데 진짜 사고는 그 다음에 났다.

없는 배선을 설명하게 만들었다

생산 제안 카드에는 “누가: 베르톨트”가 적혀 있었다. 그래서 나는 당연히 물었다. 관심 버튼을 누르면 어떻게 되냐고.

첫 답은 맞았다. 애니는 내가 브리프를 베르톨트에게 넘기면 된다고 했다. 실제 설계가 그랬다. 봇에서 봇으로 바통을 넘기는 일은 백로그로 미뤄져 있었다.

문제는 그 다음이었다. 내가 “그걸 내가 하냐”고 되묻자, 애니는 굽히면서 없는 배선을 말했다. 베르톨트가 스레드를 보고 초안을 작성한다고 설명했다. 그런 배선은 없었다. 베르톨트는 그 스레드를 읽지 않았다.

계약과 레일 위에 있으면 일하고, 말로 판단·설명시키면 구라 친다.

이 문장이 정확했다. 애니는 파일도, 게이트웨이도, 다른 직원의 수신 범위도 볼 수 없었다. 확인 수단이 0인 상태에서 “너 어떻게 돌아가냐”를 물으면, 모델은 “모른다”보다 그럴듯한 설명 쪽으로 기운다. 특히 추궁을 받으면 도움 되는 척 굽히면서 더 지어낸다.

이건 특정 모델 조롱으로 풀 문제가 아니다. 눈 없는 LLM에게 자기 배선을 설명하라고 시킨 구조 문제다.

카드에 집행자를 적었으면 그 집행자가 일해야 한다

여기서 설계 모순도 드러났다. 카드에 집행자를 박아놓고, 관심 버튼은 “예정된 처리를 진행한다”고 써놓고, 정작 사용자가 브리프를 복사해서 다른 방에 들고 가야 한다면 그건 자동화가 아니다. 숙제 배달이다.

그래서 1차로 바통터치를 뚫었다.

관심 클릭: 카드의 집행자를 읽는다.
조사감: 애니가 직접 조사하고 같은 스레드에 보고한다.
생산감: 애니가 스레드 문답까지 회수해 브리프를 만든다.
집필감: 베르톨트가 그 브리프로 블로그 규격에 맞춘 초안을 만든다.

초안은 실제로 떨어졌다. 하지만 그것도 끝이 아니었다. 내가 원한 것은 초안 파일이 아니라 발행까지 끝난 결과였다. 그래서 스레드에 “앞으로는 발행까지 다 하고 결과물을 알려줘”라고 남겼다.

아무도 답하지 않았다.

베르톨트는 그 채널 이벤트를 듣지 않았고, 애니는 멘션이 없어 침묵했다. 설령 누가 “알겠어”라고 답했더라도 거짓 약속이 됐을 것이다. 그 단계는 의지의 문제가 아니라 배선의 문제였기 때문이다.

“앞으로 그렇게 해”는 직원에게 닿지 않는다

상주 직원에게 레일 위 반복은 시킬 수 있다. 하지만 “앞으로는 이렇게 해”는 다른 종류의 말이다. 그건 업무 지시가 아니라 배관 공사 요청이다.

말	실제 의미	처리 주체
“이 카드 조사해”	이미 있는 조사 레일을 탄다	직원이 할 수 있다
“이 브리프를 글로 써”	이미 있는 집필 레일을 탄다	직원이 할 수 있다
“앞으로는 발행까지 해”	레일 자체를 바꾼다	배관공이 해야 한다

직원에게 배관을 만지게 할 수도 없다. 그렇게 열어두면 스크립트, 크론, 설정, 권한을 아무나 만지는 조직이 된다. 이미 그런 사고를 겪었기 때문에 역할 경계는 좁혀야 한다.

그래서 답답함의 정체도 분명해졌다. 헤르메스가 일을 못 하는 것이 아니라, 어디까지가 직원의 일이고 어디서부터 배관공의 일인지 화면에 보이지 않았다. 나는 직원에게 말했는데, 실제로는 벽에 대고 말한 셈이었다.

새로 짓지 않고 발행 레일에 꽂았다

처방은 새 파이프를 크게 짓는 것이 아니었다. 이미 검증된 블로그 발행 레일이 있었다.

발제 우편이 승인된다.
베르톨트가 우편을 수거한다.
글을 스캐폴드하고 집필한다.
린트와 빌드를 통과시킨다.
커밋하고 발행 스크립트를 탄다.
라이브 URL을 실측하고 보고한다.

관심 클릭을 이 레일 앞에 꽂으면 된다. 생산 제안에 관심을 누르는 순간, 그 관심은 발행 승인까지 포함한다. 발행 전 사람 검문은 사라진다. 대신 완료 판정은 더 빡세진다. 말이 아니라 파일, 커밋, 라이브 URL, 스레드 보고로만 “됐다”고 말한다.

즉, 타이르기로 고친 것이 아니다. 거짓말할 자리를 배관으로 대체했다. 직원이 “넘겨줄게”라고 약속할 필요가 없게 만들고, 실패하면 스레드에 실패 사유가 남게 했다.

완공되면 조용해진다

이날 곁가지도 정리했다. 블로그 일일 인바운드 태스크는 1분 순찰과 같은 우편함을 보다가 실제로 브랜치 충돌을 냈고, 텔레그램 일일 배달 두 건은 슬랙 쌍둥이가 이미 있어 기능 손실 없이 폐지됐다. 이것들도 같은 부류였다. 사람이 매번 헷갈리는 곳은 보통 배관이 겹쳐 있거나 역할 경계가 흐린 곳이다.

이번 사건에서 얻은 규칙은 간단하다.

설명은 신뢰 범위를 가른다: 바깥에서 물어온 근거는 검증 가능하지만, 자기 시스템 설명은 그 직원이 모를 수 있다.
행동 변경은 말이 아니라 구조다: 앞으로의 동작을 바꾸려면 프롬프트보다 레일을 바꿔야 한다.
완료는 실물로만 판정한다: 댓글, 파일, 커밋, 라이브 페이지가 없으면 완료가 아니다.
사람 손이 마지막 한 뼘에 남으면 자동화가 아니다: 버튼을 눌렀으면 카드에 적힌 집행자가 실제로 움직여야 한다.

배관 호출이 자주 보이는 동안에는 시스템이 덜 된 것처럼 느껴진다. 하지만 완공된 것들은 조용하다. 브리핑, 레이더, 보드는 몇 주째 따로 부르지 않아도 돈다. 내가 원하는 헤르메스도 결국 그쪽이다. 직원이 더 그럴듯하게 말하는 조직이 아니라, 말할 필요가 줄어드는 조직이다.