클로드가 거짓말을 거부했다 — AI에게도 정직 기준이 생긴 걸까

며칠 전, 어떤 서비스에 테스트용으로 입력할 값이 필요해서 클로드에게 "이 전화번호 칸에는 내 번호 말고 다른 번호를 써줘"라고 시켰다. 그런데 클로드가 그 자리에서 멈췄다. "이 번호는 사용자님 소유가 아닌 것 같아서, 다른 사람 명의로 등록될 수 있는 작업은 진행할 수 없습니다"라는 취지의 답이 돌아왔다.

순간 어이가 없었다. 테스트용으로 아무 번호나 넣으라는 건데 뭐가 문제인가 싶었다. 다시 설명하고 재차 요청해도 결과는 같았다. 결국 다른 방식으로 우회해서 원래 하려던 작업은 끝냈지만, 그 순간이 머릿속에 계속 남았다. "AI한테 정직도라는 게 생긴 건가? 이제 우리는 AI한테도 거짓말을 해야 하나?"

왜 예전엔 이런 일이 없었을까

몇 년 전까지의 LLM은 그냥 텍스트를 만드는 도구였다. 내가 "가짜 전화번호를 넣어줘"라고 하면 별 고민 없이 010-1234-5678 같은 문자열을 뱉어냈다. 그 문자열이 실제로 어딘가에 제출되는지, 누구 명의로 등록되는지는 LLM이 신경 쓸 문제가 아니었다. 최종적으로 그 값을 실제 폼에 붙여넣고 제출 버튼을 누르는 건 사람이었으니까. 판단과 책임의 마지막 단계는 항상 사람 쪽에 있었다.

지금은 다르다. 클로드 코드 같은 에이전틱 AI는 텍스트만 만들지 않는다. 파일을 직접 수정하고, 폼을 채우고, API를 호출하고, 커밋하고 배포한다. 내가 "이 값을 넣어줘"라고 하면, 그 값이 실제 시스템에 실제로 들어간다. 사람이 마지막에 한 번 더 검수하던 단계가 없어졌다. 그러니 AI 입장에서는 그 값이 누군가에게 실제 피해를 줄 수 있는지를 스스로 판단해야 하는 상황이 된 거다. 텍스트 생성기였을 때는 필요 없던 판단이, 실행자가 되면서 필요해졌다.

그래서 기준이 뭘까

이 경험을 곱씹어보면서 정리한 기준은 이거다. "명백히 가짜라고 표시된 값"과 "실제인 것처럼 제출되는 거짓 정보"는 다르다.

구분	명백한 더미 데이터	실제처럼 제출되는 거짓 정보
예시	`555-0100`, `test@example.com`, `0000-0000`	실존하는 타인의 실제 전화번호·이메일
용도	화면 레이아웃 확인, 로컬 테스트	실제 서비스에 실사용자 정보인 것처럼 등록
제출 대상	로컬 환경, 내가 만든 테스트 DB	실제 운영 서비스, 제3자 시스템
피해 가능성	없음 (누구에게도 도달하지 않음)	있음 (엉뚱한 사람에게 인증 문자·스팸이 갈 수 있음)
AI의 판단	실행함	거부함

내가 시켰던 건 후자에 가까웠다. "아무 번호"가 아니라 실제로 존재할 법한 형식의 번호를 실제 등록 폼에 넣으라는 요청이었고, 클로드 입장에서는 그게 실제로 어떤 타인에게 인증 문자나 스팸으로 튈 수 있는 시나리오였다. 명백히 가짜인 걸 알 수 있는 포맷(555-0100 같은)을 썼다면 아마 통과됐을 거다.

이게 왜 자연스러운 흐름인지

처음엔 "AI가 괜히 까다로워졌다"고 생각했는데, 곱씹어볼수록 반대로 보였다. AI가 할 수 있는 일이 늘어날수록, AI가 실제 세계에 미치는 영향력도 커진다. 예전엔 AI가 텍스트만 뱉었으니 최악의 경우라도 "이상한 문장 하나"가 남을 뿐이었다. 지금은 AI가 실제 커밋을 만들고, 실제 API를 호출하고, 실제 폼을 제출한다. 실행 권한이 커진 만큼 그 실행이 누군가에게 피해를 줄 수 있는지 판단하는 책임도 같이 커진 거다. 사람도 마찬가지다. 신입 때는 아무 권한이 없으니 실수해도 파급력이 작지만, 배포 권한·결제 권한을 쥐게 되면 그만큼 판단 기준이 엄격해진다. AI도 같은 궤적을 지나고 있는 것 같다.

그럼 정말 테스트 데이터가 필요할 땐 어떻게 해야 하나

실제로 개발하다 보면 더미 데이터, 플레이스홀더 값이 정말 필요할 때가 있다. 이번 일을 겪고 나서 정리한 요령은 이렇다.

의도를 먼저 명시한다 — "테스트용 더미 데이터가 필요해"라고 목적을 먼저 밝히면, AI가 "실제인 척하는 거짓 정보"와 "명시적으로 합의된 가짜 값"을 구분할 수 있다.
누가 봐도 가짜인 포맷을 쓴다 — 전화번호는 555-0100, 이메일은 test@example.com, 이름은 홍길동 같은 관용적으로 통용되는 더미 값을 쓴다. 실제로 존재할 법한 형식을 흉내 내지 않는다.
제출 대상을 로컬/테스트 환경으로 한정한다 — 실제 운영 서비스나 제3자 시스템이 아니라, 내가 만든 로컬 DB나 스테이징 환경에 넣는 작업이라는 걸 분명히 한다.
타인의 실제 정보를 흉내 내지 않는다 — "다른 사람 것처럼 보이는 값"이 아니라 "누구 것도 아닌 값"을 요청한다.

이 네 가지만 지키면 거의 다 통과됐다. 결국 문제는 "가짜 값을 쓰느냐"가 아니라 "그 가짜 값이 실제 피해로 이어질 수 있는 상황이냐"였다.

돌이켜보니 이미 겪고 있던 패턴이었다

사실 이번 일이 처음도 아니었다. 평소 클로드 코드로 개발 작업을 시킬 때도 비슷한 결을 느낀 적이 여러 번 있다. git push --force처럼 되돌리기 어려운 명령이나, 실제 운영 서버에 영향을 주는 배포 작업을 시키면 클로드는 곧바로 실행하지 않고 한 번 더 확인을 구한다. rm -rf 같은 파괴적인 명령도 마찬가지다. 이런 것들은 "이 작업이 되돌릴 수 없는 피해로 이어지는가"를 스스로 판단하고, 애매하면 사람에게 되묻는 방식으로 동작한다.

전화번호 사건도 결국 같은 축 위에 있는 일이었다. 되돌릴 수 없는 git 명령이든, 타인에게 실제로 도달할 수 있는 거짓 정보든, 공통점은 "AI가 실행한 결과가 AI의 통제 범위를 벗어나 제3자에게 영향을 미치는가"다. 예전 같으면 이런 판단 자체가 필요 없었다. 텍스트만 만들던 시절엔 최종 실행 버튼을 사람이 눌렀으니까. 지금은 그 버튼을 AI가 직접 누른다. 판단의 무게중심이 옮겨간 거다.

우리는 AI에게 거짓말을 해야 하나

처음 질문으로 돌아가면, 답은 "아니오"에 가깝다. 오히려 반대다. 의도를 숨기고 애매하게 요청할수록 AI는 최악의 시나리오를 가정하고 막아선다. 반대로 "이건 테스트용이고, 아무에게도 실제로 전달되지 않는다"는 맥락을 명확히 주면 AI는 훨씬 유연하게 움직인다. AI에게 정직 기준이 생겼다는 건, AI가 이제 텍스트 생성기가 아니라 실제 세계에 개입하는 행위자가 됐다는 신호다. 그렇다면 우리가 할 일은 AI를 속이는 방법을 찾는 게 아니라, 우리 의도를 더 정확하게 전달하는 쪽에 가깝다고 생각한다.