AI한테 글쓰기를 시켜본 분이라면 한 번쯤 느끼셨을 거예요. 내용은 분명 괜찮은데 어딘가 모르게 '아, 이거 AI가 썼구나' 싶은 순간이 있거든요. 최근 한 개발자가 이 문제를 정면으로 파고든 글을 올렸는데요, 주제가 아주 구체적이에요. Claude가 유독 'load-bearing'이라는 단어를 입에 달고 산다는 거죠. 원래는 건축에서 '하중을 받치는 벽이나 기둥'을 가리키는 용어인데, Claude는 이걸 '이 함수가 시스템의 핵심이다', '이 가정이 무너지면 전체가 무너진다' 같은 은유로 코드 리뷰든 기술 문서든 가리지 않고 끼워 넣어요. 한두 번 보면 꽤 멋진 표현인데, 매번 나오니까 슬슬 거슬리기 시작하는 거예요.
AI는 왜 말버릇이 생길까요
이게 뭐냐면, LLM(대규모 언어 모델)은 결국 '다음에 올 단어의 확률'을 예측하는 기계거든요. 그런데 학습 마지막 단계에서 사람의 피드백으로 모델을 다듬는 과정(RLHF라고 불러요)을 거치면서, 좋은 평가를 받았던 특정 표현의 확률이 유독 높아지는 일이 생겨요. 원래는 수많은 표현 중 하나였던 단어가 어느 순간 모델 입장에서 '정답 같은 단어'로 굳어버리는 거죠. 연구자들은 이걸 모드 붕괴(mode collapse)라고 부르는데, 쉽게 말해 모델의 표현 다양성이 몇 개의 선호 패턴으로 쪼그라드는 현상이에요. GPT 계열이 'delve(파고들다)'를 남발한 탓에 학술 논문 초록에서 이 단어의 사용 빈도가 갑자기 치솟았다는 분석이 나왔던 것과 같은 맥락이에요.
'그 단어 쓰지 마'가 안 통하는 이유
그럼 프롬프트에 'load-bearing이라는 단어를 쓰지 마'라고 적으면 되지 않냐 싶으실 텐데요, 여기에 함정이 있어요. '분홍 코끼리를 생각하지 마세요'라는 말을 들으면 오히려 분홍 코끼리부터 떠오르잖아요. 모델도 비슷해요. 금지하려는 단어를 프롬프트에 적는 순간 그 단어가 컨텍스트(모델이 참고하는 대화 내용) 안에 존재하게 되고, 관련 토큰의 확률이 오히려 자극받을 수 있거든요. 부정 지시는 모델이 지시를 이해하고 따라주길 기대하는 방식인데, 확률 기계 입장에서는 눈앞에 보이는 단어가 그냥 강한 힌트가 되어버리는 거예요.
그럼 어떻게 다스려야 할까요
실전에서 통하는 접근은 대체로 이런 것들이에요. 첫째, '쓰지 마' 대신 '이렇게 써'를 주는 거예요. 금지어 목록보다 원하는 문체의 예시 문장 몇 개를 직접 보여주는 편(few-shot 예시라고 해요)이 훨씬 잘 먹혀요. 둘째, 생성이 끝난 뒤 코드로 걸러내는 후처리예요. 어차피 확률을 100% 통제할 수는 없으니, 파이프라인 마지막에 특정 표현을 찾아 다른 말로 바꿔주는 스크립트를 한 겹 두는 거죠. 셋째, API 레벨에서 특정 토큰의 확률 자체를 깎아버리는 logit bias 같은 기능을 쓰는 방법도 있어요. 프롬프트로 설득하는 게 아니라 아예 주사위 눈금을 조작하는 셈이라 가장 확실한데, 지원 여부는 모델과 API마다 달라요.
사실 Claude만의 문제는 아니에요
이런 시그니처 표현은 모델마다 다 있어요. 긴 줄표(—)를 남발한다거나, '그건 X가 아니라 Y입니다' 같은 대구 문장을 반복한다거나 하는 것들이요. 그래서 역설적으로 이런 말버릇이 'AI가 쓴 글'을 감별하는 단서로 쓰이기도 해요. 모델 회사들이 벤치마크 점수는 열심히 올리는데, 문체의 다양성 같은 건 숫자로 측정하기 어렵다 보니 상대적으로 방치된 영역이기도 하고요.
우리한테는 어떤 의미일까요
한국어 출력에도 똑같은 문제가 있어요. '~라고 볼 수 있습니다', '결론적으로' 같은 표현이 유독 반복되는 걸 느껴보신 분 많을 거예요. LLM으로 콘텐츠를 만드는 서비스를 운영한다면, 시스템 프롬프트에는 원하는 문체의 긍정적 가이드를 넣고 금지 표현은 후처리 코드로 거르는 이중 구조를 추천해요. 프롬프트 한 방으로 해결하려다 밤새는 것보다 훨씬 건강한 설계거든요.
정리하면, AI의 말버릇은 버그라기보다 학습 방식이 만들어낸 체질에 가깝고, 말로 타이르기보다 구조로 다스리는 게 정답이라는 얘기예요. 여러분이 발견한 AI 특유의 말버릇은 뭐가 있나요? 그리고 그걸 어떻게 고치셨나요?
🔗 출처: Hacker News