혹시 이런 경험 있으세요?
동료가 올린 PR 설명을 열었는데 첫 줄이 '이번 변경은 코드베이스의 유지보수성과 확장성을 크게 향상시키는 중요한 개선입니다'예요. 그 아래로는 굵은 글씨 소제목이 네 개 있고, 소제목마다 글머리 기호가 세 개씩 달려 있어요. 마지막엔 '결론적으로'로 시작하는 요약 문단까지 친절하게 붙어 있고요. 내용을 다 읽기도 전에 머릿속에 떠오르는 생각은 하나예요. 아, 이거 AI가 썼구나.
리팩터링, 스트랭글러 피그, 기술 부채 사분면 같은 개념을 정리하고 이름 붙여 온 마틴 파울러가, 블로그 겸 용어 사전인 bliki에 바로 이 현상을 가리키는 항목을 올렸어요. 제목은 LLM Voice예요. 우리말로 옮기면 'LLM 말투' 정도가 되겠네요. 다들 어렴풋이 느끼던 감각에 이름이 생겼다는 게 이번 글의 의미라고 생각해요. 이름이 생기면 팀 안에서 이야기하기가 훨씬 쉬워지거든요. '이 문서 LLM Voice 좀 나는데요?' 한마디면 다 통하니까요.
LLM Voice가 정확히 뭐냐면
쉽게 말해 대형 언어 모델이 쓴 글에 반복해서 나타나는 문체 특징을 묶어 부르는 말이에요. 하나씩 뜯어보면 문법은 다 맞고 오히려 매끄러워요. 그런데 모아 놓으면 묘하게 사람 냄새가 안 나는 글이 되죠. 영어권에서 자주 꼽히는 특징을 몇 가지 들어 볼게요.
- 특정 단어를 지나치게 많이 써요: delve, crucial, robust, seamless, landscape 같은 단어가 유난히 자주 나와요.
- 'X가 아니라 Y다' 구문: 'It's not just a tool, it's a paradigm shift'처럼 대비를 만들어서 극적인 효과를 노려요.
- 꼭 세 개씩 묶어요: 형용사든 예시든 셋씩 나열해요. 빠르고, 안정적이고, 확장 가능한, 이런 식으로요.
- 구조화가 과해요: 짧은 답변에도 소제목, 굵은 글씨, 글머리 기호를 잔뜩 붙여요.
- 끝에서 또 요약해요: 본문에서 한 말을 마지막 문단에서 한 번 더 정리해요.
- 초안은 맡겨도 마지막엔 꼭 내 말로 다시 써요. 특히 첫 문장과 마지막 문장은 직접 쓰는 게 좋아요.
- 프롬프트에 '형용사 빼고, 요약 문단 없이, 변경 사항과 이유만'처럼 구체적인 제약을 걸어요.
- 예전에 내가 쓴 글을 예시로 주고 그 톤을 따라 하게 해요.
- 지워도 뜻이 안 바뀌는 문장은 과감하게 지워요. LLM Voice는 대부분 그런 문장에서 나와요.
(네, 이 글도 소제목이랑 글머리 기호를 쓰고 있다는 거 알아요. 좀 찔리네요.)
한국어도 예외는 아니에요. '다양한', '효율적인', '중요한 역할을 합니다', '~하는 것이 중요합니다', '결론적으로' 같은 표현이 문단마다 나온다면, 한국어판 LLM Voice라고 봐도 되거든요.
왜 이런 말투가 생길까요
원인을 알면 대처법도 보여요. LLM은 엄청난 양의 텍스트를 학습한 뒤 '다음에 올 확률이 가장 높은 단어'를 골라 가며 글을 써요. 그러다 보니 가장 무난하고 평균적인 표현 쪽으로 쏠리기 쉬워요. 여기에 RLHF(인간 피드백 기반 강화학습), 그러니까 사람이 답변에 점수를 매겨서 모델을 다듬는 과정이 더해지는데요. 평가자들은 대체로 정중하고, 구조가 한눈에 보이고, 빠짐없이 정리된 답변에 높은 점수를 주는 편이에요. 그래서 모델은 '친절하고 꼼꼼해 보이는' 스타일을 정답으로 배우게 되죠.
비유하자면 손님 모두의 입맛에 맞추려고 간을 딱 중간으로 맞춘 프랜차이즈 음식 같은 거예요. 맛이 없진 않은데, 한 입 먹으면 어디 맛인지 바로 알잖아요. 그 익숙한 맛이 너무 흔해지면서 독자들이 피로감을 느끼기 시작한 거예요.
개발 현장에서 이게 왜 문제냐면
글이 매끄러우면 그만이지 뭐가 문제냐고 생각할 수도 있어요. 그런데 개발 문서에서는 크게 세 가지가 걸려요.
첫째, 신호 대 잡음비가 떨어져요. 커밋 메시지나 PR 설명은 '무엇을, 왜 바꿨는지'를 빨리 전달하려고 쓰는 글이에요. 그런데 '이 변경은 전반적인 사용자 경험을 향상시킵니다' 같은 문장에는 정보가 하나도 없어요. 리뷰어는 정말 중요한 한 줄을 찾으려고 꾸밈 문장 사이를 뒤져야 하죠.
둘째, 신뢰가 떨어져요. 독자가 'AI가 썼네' 하고 느끼는 순간, 작성자가 이 내용을 정말 이해하고 검토했는지 의심이 들어요. 코드 리뷰에서는 이 의심이 꽤 치명적이에요. 리뷰어는 더 꼼꼼히 봐야 한다는 부담을 느끼고, 작성자는 억울해지거든요.
셋째, 글쓴이의 생각이 사라져요. 기술 블로그나 설계 문서의 가치는 결국 '이 사람은 이 문제를 이렇게 봤구나' 하는 관점에서 나와요. 평균으로 수렴한 문장에는 그런 관점이 들어갈 자리가 없어요.
그럼 LLM을 쓰지 말라는 건가요?
아니에요. 중요한 건 도구를 쓰느냐 마느냐가 아니라 최종 결과물이 누구의 목소리냐예요. 실무에서 바로 써먹을 만한 방법을 몇 가지 정리해 볼게요.
마무리
LLM Voice는 '글이 틀렸다'는 문제가 아니라 '글에 사람이 없다'는 문제예요. AI 덕분에 글 쓰는 비용이 거의 0이 된 지금, 오히려 내 생각이 담긴 문장의 값어치는 더 올라가고 있다고 봐요.
여러분 팀에서는 어떠세요? AI로 쓴 티가 나는 문서나 PR 때문에 곤란했던 적이 있나요? LLM 말투를 피하려고 쓰는 나만의 프롬프트나 습관이 있다면 공유해 주세요.
🔗 출처: Hacker News