AI 글은 왜 읽고 나면 무슨 말인지 헷갈릴까

AI는 추상적인 말을 쓰며 그럴듯하고 유려하게 들리지만, 실제로는 앞뒤가 맞지 않는 빈말인 경우가 많습니다. 사람도 마찬가지예요. 일부 정치인이나 학자는 재치 있게 표현하지만, 실제로 뜻을 따져 보면 말이 안 되는 경우가 있습니다.

한동안 Google Gemini가 기술 지원 직원보다 더 좋은 조언을 해 줄 거라 생각했습니다. 크롬북이나 픽셀폰, 안드로이드에 대해 물어보면 적절한 선택 같았죠. 실제로는 때때로 도움이 됐고, 기술 지원으로 해결하지 못한 문제도 몇 개 해결했습니다. 하지만 Gemini가 자기 능력을 넘어서서 시스템 프로그래밍 관점으로 결함을 설명하거나, 안드로이드 코드와 픽셀 하드웨어를 깊이 아는 것처럼 굴 때도 있습니다. 그러면 완전히 말이 안 되는 소리를 쏟아내요. ‘그건 시스템을 제대로 평가한 게 아니라 스타트렉 얘기 같아’라고 지적하면 ‘맞아요, 지적이 옳습니다!’라고 하면서도 아무렇지 않게 계속 말을 이어갑니다. 그래서 LLM이 꾸며낸 내용은 전문 용어에 깊이 가려져 있어, 이미 말도 안 된다는 걸 아는 사람 아니면 의심조차 못 할 때가 있습니다. 그런데 지적하면 LLM은 순순히 인정하죠. 부끄러움이 없다는 건 확실합니다.

사람들은 구호나 유행어, 재치 있는 문장 조각을 좋아하고 AI는 그런 사람들을 따라 학습했습니다. AI가 완벽하지 않으니 그런 표현을 과하게 쓰거나 엉뚱한 곳에 씁니다. AI가 뜨기 전 뉴스나 블로그, 기업 보도자료를 읽어 봐도 AI 특유의 표현이 얼마나 자주 나왔는지 알 수 있어요. 인터넷은 짧고 강한 의견, 재치 있는 한마디, 클릭을 부르는 ‘A가 아니라 B다’ 같은 표현을 핵심 문체로 만들었습니다. AI가 그걸 따라 하는 건 놀랄 일이 아닙니다.

기술 작가로서 제 생각엔 기본 AI 응답이 실제로 좋은 글이 아니라 사람들이 좋은 글이라고 생각하는 특징에 최적화되어 있습니다. ChatGPT는 적어도 한동안 사용자 참여에 최적화됐죠. 목록이 있고, 제목이 있고, ‘결정적 단서’ 같은 재미있는 표현이 있고, 길고 정보가 많으면 잘 쓴 것처럼 보입니다. 이런 특징은 빠르게 찾아내고 선호할 수 있지만, 답변이 독자에게 유용한지는 따지지 않습니다. 독자가 아니라면 무엇이 도움이 되는지 판단하기 어려울 수 있어요.

아니요, 겉보기엔 인상적이지만 실제로는 그리 좋지 않은 코드도 만듭니다. 글과 똑같아요.

아닙니다. AI는 작동은 하지만 허술한 코드를 만들 수 있습니다. 빠르게 돌아가고 결과를 신뢰성 있게 점수화하는 결정적 테스트 묶음이 있어, 에이전트가 반복해서 개선할 수 있기 때문이죠. 하지만 ‘이 코드가 유지보수 가능한가’, ‘우리 사업 맥락에 맞는 기능인가’를 판단하는 테스트는 없습니다. 영어 문장이나 문단이 대상 독자에게 유용한지, 말이 되는지 신뢰성 있게 판정하는 테스트 묶음을 만들 수 있다면 좋은 글에 가까워지도록 반복하는 에이전트도 가능하겠지만, 아직은 그런 게 없습니다.

저는 크게 어려움을 겪지 않습니다. 소프트웨어 개발자이고, 성인이 된 뒤 독일어를 프랑스어보다 더 쉽게 배운 경험과 관련 있을 것 같아요. 전문 초록에 나온 ‘무생물 주어와 생물 동사의 결합’, ‘메서드가 예외를 던진다’, ‘서버가 요청을 받는다’ 같은 표현은 익숙합니다. 또 명사 여러 개가 쌓이는 문장도요. SimpleBeanFactoryAwareAspectInstanceFactory 같은 식이죠. 독일어는 영어보다 긴 구문 의존 관계가 많습니다. 독자는 여러 절을 지나서야 앞에서 시작된 단어와 의미를 연결해야 하는 경우가 있습니다.

기술 작가로서, 저는 Google이 Gmail에 ‘글쓰기 도움’ 기능을 내놓았을 때 정말 실감했습니다. 제가 쓴 거의 모든 문장에 ‘더 간결하게 쓰세요’, ‘이어지는 문장을 줄이세요’ 같은 제안이 떴어요. 농담이 아니라 문장당 평균 1.3개씩 제안이 나왔습니다. 거의 전부 별로였어요. 영어 글쓰기 교과서의 보조 규칙을 문장마다 무작정 적용하고, 문장 호흡이나 핵심 단어 강조, 감정 조절 같은 더 깊은 요소는 전혀 신경 쓰지 않는 느낌이었습니다. 최첨단 모델에서도 비슷한 일이 일어나는 것 같아요. 미세 조정 과정에서 어떤 보상 점수가 간결하게 쓰고 군더더기와 긴 문장을 피하라고 하지만, 글 전체의 흐름을 보는 균형은 없는 거죠.

기술 작가로서 저는 기본 AI 응답이 실제로 좋은 글이 아니라 사람들이 좋은 글이라고 생각하는 특징에 맞춰져 있다고 봅니다. 제 추측으로는 수년간의 RLHF가 평가자가 첫인상으로 글을 잘 썼다고 느끼는지에 최적화됐습니다. 목록과 제목이 있고, ‘결정적 단서’ 같은 재치 있는 표현이 있고, 길고 정보가 많으면 잘 쓴 것처럼 보이니까요. 하지만 이런 특징만으로는 그 답변이 독자에게 유용한지 알기 어렵습니다. 독자가 아니라면 무엇이 도움이 되는지 판단하기 어려울 수 있습니다.

이해한다는 걸 어떻게 시험하죠? 마르코프 연쇄 텍스트처럼 단어 뜻은 다 압니다. LLM 텍스트에서는 문장 뜻도 알지만, 글 전체가 무슨 말인지는 모를 때가 있습니다. 기존 지식에 따라 달라질 수 있겠죠. 인간도 LLM과 비슷하고, 관련 지식이 없는 사람은 컴퓨터가 만든 엉성한 글을 그대로 익혀서 실제 지식인 줄 착각할 수 있습니다. 반면 이미 알고 있던 사람은 새로 배운 내용이 기존 지식과 충돌해 거부할 수도 있고요.

정확해요. AI는 클릭 낚시와 반응을 유도하는 콘텐츠를 엄청나게 학습했습니다.

제 생각엔 연구소들이 문장 자체에는 오래전부터 신경을 덜 썼습니다. 지금은 올바른 도구를 호출하는 데 자원을 쏟고 있죠. 결국 연구소는 인간이 주 사용자가 아니게 되길 바라며, AI가 혼자서 또는 다른 AI와 함께 자율적으로 일하기를 원합니다. 다른 에이전트는 글을 어떻게 쓰는지 신경 쓰지 않을 테니까요. 언젠가는 사람이 읽기 좋은 문장에 최적화된 보조 모델이 나올 수도 있겠지만, 연구소들은 코딩 모델의 유용성에 대해 인간이 곧 중요하지 않게 될 거라고 착각하는 듯합니다. 저는 에이전트와 하위 에이전트를 위한 티켓 시스템을 쓰는데, 티켓이 거의 읽을 수 없어서 싫습니다. 티켓을 제가 선호하는 문체로 쓰게 하면 성능이 떨어져요. 이 읽기 힘든 문체가 AI끼리 소통하려고 설계된 것처럼 느껴집니다. 학습 과정에서 AI가 대부분의 피드백을 생성하기 때문일지도 모르고요.

인간 언어와 달리 프로그래밍 언어는 경계가 엄격하게 정해져 있어서 LLM이 훨씬 잘합니다. 수학도 마찬가지예요.

Gmail이 ‘Google shipped their’를 ‘Google shipped its’로 바꾸라고 제안합니다. 저는 기능을 만든 Google 사람들을 말하고 싶어서 ‘their’를 쓴 건데, 제안은 얼굴 없는 기업만 남깁니다. ‘feature or whatever’는 기능 이름이 뭔지 잘 모르고 굳이 찾아볼 생각도 없다는 뜻이라 붙였는데, 제안은 그걸 지우라고 합니다. ‘gmail’을 ‘Gmail’로 고치라는 건 그러려니 합니다. 또 ‘I wrote, it had useful tips’를 ‘I wrote received useful tips’로 고치라는데, 쉼표를 지우면 호흡이 달라져서 ‘썼다’는 단어에서 독자가 멈추지 않게 되고, 글을 쓴 것과 유용한 팁을 받은 것 사이에 모호함이 생깁니다. 특히 이 제안은 이해하기 어렵습니다. 이렇게 고치면 제 문장도 제가 못 알아보겠어요. 이런 식의 제안이 계속돼서 이제는 메모장에 이메일을 쓴 뒤 Gmail에 붙여넣습니다.

작가이자 소프트웨어 엔지니어로서, LLM 결과물의 문제는 두 분야에서 같습니다. 국소적인 목표는 달성하지만 여러 요소를 동시에 챙기기 어렵습니다. 사람이 대화 중에도 인물이 총을 들고 있다는 걸 기억하는 일은 쉬운데, LLM은 단어가 묘사하는 현실을 공간적으로 이해하는 구조가 없어서 그 사실을 잊습니다. 대신 잘 기억하면 다른 인물의 남부 억양을 잊거나 어색한 비유를 만들기도 합니다. 프로그래밍에서는 더 잘 드러나지만 문제는 같습니다. 의미를 서로 엮어 이해하지 못하고, 실제 세계와 LLM의 맥락 안에만 있는 세계 사이에 마찰이 있습니다.

반대로 너무 흔한 단어 조합만 쓰면 상투적인 말투가 되고, 그것도 읽고 싶은 사람은 없습니다.

맞아요. 그래서 글쓰기는 창작 활동입니다.

이해를 어떻게 시험하는지는 모르겠지만, 저는 LLM을 개발에 많이 쓰고 대화를 계속 보면서 방향을 잡는 사람으로서 말 뒤의 뜻을 파악하고 적절히 행동할 수 있습니다. 다른 사람들은 링크된 글을 보고 ‘AI 문체’라고 외치지만, 제가 읽을 때는 그런 특징을 의식하지도 못한 채 내용을 받아들인 적도 많습니다. 사람들이 일부러 그런 특징을 찾으며 목소리를 높이는 건 아닌가 싶어요.

논문을 대충 훑어봤는데, 다른 얘기를 하는 것 같습니다. 특정 생각을 표현하는 방식은 여러 가지이고, 긴 표현이 더 명료하고 짧은 표현은 헷갈릴 수 있죠. 이해받는 게 중요하면 사람은 때때로 말을 길게 합니다. 하지만 LLM에는 문맥 창이 있고, 다른 조건이 같다면 길게 쓰는 건 문맥을 잡아먹습니다. 모델이 강화학습으로 추론을 잘하도록 학습된다면 짧은 표현을 쓰는 게 효과적일 수 있어요. 간결함은 공짜로 문맥 창을 늘리는 것과 비슷하니까요. 물론 실제로 공짜는 아닙니다. 명료함과 문맥 용량을 맞바꾸는 거죠. 때로는 ‘길고 명확한 표현’과 ‘짧고 모호한 표현’ 중 하나를 골라야 합니다. 간결함을 우선하면 모호해질 가능성도 커집니다. 물론 LLM이 가끔 장황한 것도 맞아요. 사용자를 기쁘게 하려고 추가 지식과 통찰을 덧붙이도록 학습되기도 하니까요. 이건 논문 내용과 모순되지 않는다고 봅니다. 보너스 정보를 잘 덧붙이는 훈련과 제한된 문맥 창을 알뜰히 쓰는 추론 훈련이 같이 이루어지면, 약간 압축적이고 헷갈리는 문체로 글을 많이 쓸 수 있습니다.

글쓰기에서 문장 호흡은 정말 중요합니다. 소리 내어 말하는 방식은 머릿속으로 읽는 방식과 다를 때가 많아요. 말로 표현할 때는 생각을 만들고, 언어로 옮기고, 시각이나 소리로 전달하는 세 단계가 있습니다. 읽기는 언어로 옮기는 단계만 공유하지만, 정보를 받아들이면서 내용을 정리하는 과정도 더해집니다. 그래서 글은 정보를 정리한 다음 이해할 수 있도록 구성해야 합니다. 사람은 단어를 직선으로 보지만 정보를 직선으로 받아들이지는 않아요. 많은 문학적 농담도 이 원리로 작동하죠. ChatGPT나 Gemini는 구성과 표현 사이의 이런 상호작용을 이해하지 못합니다. 정보를 직선으로 처리하고 구성하고 표현해요. A 다음에 B, 그다음 C가 오는 식이죠. A에서 C로 먼저 갔다가 A와 C에 비스듬히 연결된 B로 되돌아가는 식은 못합니다. 언어가 실제로 쓰이는 방식에 대한 이해가 부족한 겁니다.

제가 유별난 건지 모르겠지만, 거의 어떤 모델이든 AI가 만든 글을 이해하기 어렵다고 느끼진 않습니다. 잘난 척하거나 빈정대려는 건 아니고요. 은유를 많이 쓰고, 뭔가를 암묵적으로 가리키면서 독자가 그 상황을 이미 봤다고 가정하는 일이 많긴 합니다. 그래도 그냥 읽고 옛날식 표현 몇 개를 알면 대체로 의미가 통합니다. 많은 사람이 AI가 쓴 글을 제대로 읽지 않는 것 같아요. 제가 본 사람들 중에는 완전한 문장으로 질문하지 않고, 돌아온 문장을 읽지 않고, 중간의 대화 흐름이나 도구 호출도 확인하지 않은 채 메시지가 다른 뜻인 것처럼 반응하는 경우가 많았습니다. 논문을 읽기 전에 하는 말이지만, 개인적으로나 팀 단위로 여러 실험을 해 봐서 결과가 궁금합니다. 읽고 나서 덧붙이자면, 정말 흥미로웠어요. 제가 해 본 ‘공학과 소통 방식’ 실험에서도 비슷한 점을 봤습니다. 논문 대부분은 맥락 안에서 모델이 인간 언어 쪽으로 이동하는 현상을 다루지만, 인간이 모델 언어를 따라가는 효과는 훨씬 작다고 합니다. 로컬 모델과 최첨단 Claude로 몇 년간 대화해 본 결과, 일상 건강 상담부터 깊은 공학·연구 주제까지 답변은 대체로 정보 밀도에 맞춰지는 듯했습니다. 논문 실험은 이미 접한 적 있지만 결론은 잘 짚었다고 생각합니다.

LLM 강화학습은 에이전트가 검증 가능한 결과를 통과할 때까지 ‘추론’하게 해서 작업 성능을 높입니다. 그러다 보니 언어는 다른 사람이나 대상에게 전달되지 않은 채, 한 과업의 좁은 기준에 맞춰집니다. 반면 인간의 글쓰기와 소통은 대체로 다른 인간을 향하고, 상대가 이해하지 못하면 고치고 다시 쓰는 과정을 거칩니다. 수학을 하는 사람도 다른 사람이 검토할 수 있어야 하고, 글은 다른 사람이 이해해야 한다는 조건 속에 있습니다. 이런 과정이 빠지면 언어가 뒤틀리고 압축됩니다.

저는 ‘엉성한 입력이 엉성한 출력을 만든다’는 설명을 지지합니다. 흥미로운 건 LLM이 통계적으로는 진실만이 문법적이라는 걸 증명한 셈이라는 거예요. 대체로 틀리는 방법이 맞는 방법보다 훨씬 많으니 가장 흔한 형태가 맞는 쪽에 가깝다는 거죠. 하지만 사람도 거짓말하거나 사람을 속이려고 빈약한 논리를 일관되게 쓰곤 합니다. 좋은 글쓰기의 일부는 의미 없는 말을 의미 있어 보이게 만드는 기술이고, 이런 수법은 오래됐어요. 온라인 잡글부터 문학, 진지한 논픽션과 과학 글까지, 자기 프레임워크를 팔고 돈을 벌려는 글을 잔뜩 학습하면 논리를 속이려는 말투는 따라 하면서도 실제로 설득하려는 목적은 없는 문장이 평균적인 결과로 나올 수 있습니다. 사람은 대화 상대의 동기를 짐작하며 그런 말의 어느 부분에 수사적 속임수가 있는지 살핍니다. 동기가 없는 LLM은 그런 수법을 여기저기 무작위로 씁니다. 요즘 AI 발전은 도구를 둘러싼 발전이 큰데, 모델을 계속 만들고 출력이 길어져 글이 엉뚱해지지 않도록 짧은 결과물로 채우는 과정이라고 봅니다. 기호 AI가 돌아오고 있고, 그 모르타르는 무작위 단어 연상일 뿐이죠. 제가 이상하게 들릴지 모르지만, 조르주 바타유는 이런 점을 봤다고 생각합니다…

이건 정말 답답합니다. AI에게 뭔가 바꾸라고 하면 README 파일에 그 내용을 잔뜩 넣어 버려요. ‘이 프로젝트는 일부러 이런 걸 한다’ 같은 설명은 최근 맥락에만 필요하고 다른 상황에는 필요 없는데요. 이제는 AI가 글을 쓰지 못하게 하고 제가 놓친 점만 말하게 합니다. 산문을 수정해 달라고 하면 글을 망쳐서 결국 거의 전부 다시 써야 하기 때문입니다.

‘전적으로 옳은 말씀입니다. 불필요하게 길게 설명하지 말았어야 했네요.’ (미안합니다. Claude 탓입니다.)

업무에서 AI 코딩을 두 가지 방식으로 씁니다. 버릴 수도 있는 시제품은 거의 바이브 코딩으로 만들고, 에이전트가 막히거나 화면이 이상해 보일 때만 가끔 직접 손봅니다. 실제 운영 코드에서는 계속 개입해 에이전트가 만든 코드를 검토하고 수정합니다. 그러다 보니 엉성한 시제품 코드와 유지보수 가능한 운영 코드 모두 경험했는데, 시제품이 예상보다 오래 살아남으면 에이전트가 퇴행을 만들거나 변경을 계속 반복하는 지점에 이릅니다. 유지보수 가능한 코드에서는 그런 일이 훨씬 덜합니다. 제 경험으로는 구조가 잘 잡힌 코드베이스에서 LLM이 더 빠르고 효과적이며 오류도 적습니다.

제 모국어에서는 ‘baseline system state transition latency validation’이 문법적으로 한 단어였을 겁니다. 영어에서는 가끔 그 점이 그립네요. 피곤할 때 ‘baseline system state transitions latency validation’을 보면, 없던 s를 본 것처럼 뜻이 달라져서 실제 s가 있었는지 다시 읽게 됩니다. ‘baselinesystemstatetransitionlatencyvalidation’처럼 붙여 쓰는 편이 오히려 덜 헷갈려요. 한 단어로 한 가지를 뜻한다고 알고 있으니 눈이 구성 요소를 순서대로 훑으며 의미를 파악할 수 있거든요. 조금 느릴지는 몰라도, ‘baseline system state transition latency validation’이라고 띄어 쓴 표현을 읽는 것보다 이해는 빠릅니다. 눈은 사실 단어를 여러 조각으로 끊어 읽고, 어떤 것이 한 덩어리인지 먼저 파악한 다음 무슨 덩어리인지 알아갑니다. 편집: HN에서 굵은 글씨를 지원했다면 예시를 더 잘 보여 줄 수 있었을 텐데, 지원하는지 모르겠네요.

전적으로 동의합니다. 언어는 우리가 생각하는 방식의 일부지만 전부는 아닙니다. 우리는 신체와 생물학적 기반을 갖고 있고 LLM은 그렇지 않죠. 언어는 소프트웨어지만 하드웨어도 중요합니다. 그래도 LLM은 언어가 얼마나 중요한지 보여 줍니다. 언어는 이미 있는 생각을 전달하는 수단에 그치는 게 아니라 생각을 구성하는 요소이기도 합니다. 여러 면에서 LLM은 인간의 인지가 우리가 접할 수 있는 언어와 개념에 영향을 받는다는 구조주의·후기구조주의 이론을 강하게 뒷받침한다고 생각합니다.

LLM은 ‘시스템 1’식으로 글을 씁니다. 깊이 이해하지 않고 그냥 흘려 읽을 때 더 만족스러운 문장이라고 느끼기 쉽고, 실제로 무슨 말인지 파고들면 무너집니다. 요즘 LLM을 열렬히 지지하는 사람들은 결과물을 꼼꼼히 읽거나 검토할 필요가 있다는 말에 유난히 짜증을 내는 경우가 많다고 느꼈습니다. 또 LLM의 낮은 품질을 정당화하는 독특한 관점도 갖고 있고요. LLM이 코드를 특정 방식으로 짜는 건 그 방식이 모델 자신에게 가장 좋기 때문이라고 주장하는 사람들도 있습니다. 마치 인간이 코드를 건드리면 LLM이 만들어 둔 섬세한 균형이 깨지기라도 한다는 듯하죠. 이건 이상한 생각입니다. 이 사람들은 자신이 만나는 LLM을 신비한 방식으로 행동하는 초지능 신처럼 여기고, 그 계획에 의문을 제기하면 망쳐 버릴 수 있다고 생각하는 것 같아요.

늘 그렇듯 댓글 대부분이 제목만 보고 답하니 결론을 인용합니다. 강화학습에서 길이 페널티를 주면 문법적 특징에 직접 영향을 줄 수 있다는 개념 증명입니다. 모델에게 압축해서 쓰라고 직접 지시하거나, 구문 변형이 가능하다고 알려 준 건 아닙니다. 페널티가 더 짧은 표현을 선호하는 경향을 만들어 냈습니다. 검증 가능한 보상이 인간다운 소통과 정확성을 분리해, 모델이 새롭지만 이해하기 어려운 언어 분포로 수렴할 수 있다고 봅니다. 모델과 학습을 만져 본 사람에게는 상식처럼 들리지만, 누군가 이를 수치로 확인했다는 점은 좋습니다. 이 현상은 Claude 기본 문체에서만 보이고, 프롬프트를 주면 다른 식으로 쓸 수 있다는 점도 덧붙이고 싶습니다.

문법 규칙을 규범이 아니라 기술의 관점에서 보면 ‘맞다’와 ‘틀리다’에 빠지기 쉽습니다. 가장 중요한 건 의도를 전달하는 일입니다. AI는 아직 의도를 가질 수 없어요. 영어 문장이 어려운 사람에게 AI 편집기가 도움이 될 수는 있겠지만, 저는 가끔 독특하고 ‘틀린’ 표현이 있어도 사람이 쓴 편한 영어를 거의 언제나 더 읽고 싶습니다. 문법을 아무리 잘 지켜도 읽기 어려운 영어는 좋은 문장이 아니고, AI는 읽기 어려운 영어를 자주 씁니다.

논문에서 언급하지 않은 표현 중 하나가 놀랍습니다. LLM은 타동사를 목적어 없이 쓰는 걸 좋아하는데, 사람이 그렇게 쓰는 경우는 거의 못 봤습니다. 문장이 묘하게 모호해지거나 아예 이해하기 어려워질 수 있고, 정확성이 중요한 기술 문서에서는 더 거슬립니다. 무슨 뜻인지 추측할 수는 있겠지만, 독자나 사용자가 추측해야 하는 문서라면 뭔가 크게 잘못된 거죠. 예를 들어 ‘사용자가 버튼을 누르면 폼이 제출한다’ 같은 표현입니다. ‘폼이 데이터를 제출한다’처럼 목적어를 넣거나, ‘폼이 제출된다’라고 써야 합니다.

그렇다면 정확성을 높일 건가요, 이해도를 높일 건가요? ‘company’는 참가자 다섯 명으로 이루어진 모임을 뜻할 수도 있어서 행동 주체가 될 수 있지만, corporation은 보통 사물입니다. 영어를 직업적으로 다루는 사람이라면 ‘the corporation announced their financial report last weekend’를 이해할 수는 있겠지만, 제가 아는 한 their의 올바른 용법은 아닙니다. 무생물의 관계를 나타낼 때 corporations employees처럼 s를 붙이는 것도 틀린다고 알고 있습니다. 그렇다고 ‘the employees of the corporation went to…’라고 쓰면 조금 지나치게 격식을 차린 말처럼 들리긴 합니다.

서로 모순되는 목표를 동시에 최적화하는 건 늘 어렵고, 이런 문제가 어떤 식으로든 새어 나옵니다. 기본적인 지시 학습도 글을 조각조각 쓰게 만들면서 전형적인 보조 응답 구조가 글에 묻어날 수 있어요. 예를 들어 인물이 앞에서 한 말을 되풀이하는 서술이 지나치게 많아지는 식입니다. 예전 모델도 이런 버릇이 있었죠. 보조 모델에 미리 문장을 넣는 방식으로 줄일 수 있는데, 최첨단 모델에서 이 기능을 없앤 건 안타깝습니다. 자연스러운 언어를 최적화하면 더 자연스럽게 들리는 법을 배우겠죠.

규범 문법과 기술 문법의 차이입니다. 기술 문법은 사람들이 실제로 언어를 어떻게 쓰는지 설명하죠. 그 맥락에서 they를 쓰는 게 틀린 건 누군가 그렇게 해야 한다고 정했기 때문일 뿐입니다. 스웨덴어로 ‘우리 집으로 가자’는 문법적으로 맞지만 실제로는 잘 쓰지 않고, ‘내가 있는 곳으로 가자’는 표현은 문법적으로 틀렸지만 실제로 쓰입니다.

이해가 안 되는 건 모델이 시간이 지날수록 왜 더 나빠졌느냐는 겁니다. Claude가 전보다 글을 훨씬 이상하고 이해하기 어렵게 쓰기 시작한 시점이 뚜렷이 기억나요. 그전에는 여전히 아주 잘 쓰진 않아도 어느 정도 괜찮았는데요.

흥미로운 관찰이네요. 언어가 존재하는 이유인 ‘왜’와 언어가 구성되는 방식인 ‘어떻게’를 비교하는데, 전자가 더 중요하다는 건 맞습니다. 젊을 때 프로그래밍 언어를 공부한 뒤 문법을 더 잘 이해하게 됐어요. 단어가 문장 안에서 어떤 종류에 속하는지, 문장의 객체가 무엇인지 생각하게 되면서 더 명확하게 읽고 쓰게 됐습니다. 저는 당신과 약간 다른 쪽인 것 같지만 크게 다르진 않아요. 의도를 한 치의 의심 없이 표현하는 정확한 문장을, 맥락이나 사회적 합의에 기대야 이해되는 쉬운 문장보다 훨씬 좋아합니다. 한 친구가 열린 표현과 모호한 설명을 자주 썼는데, 혼란과 오해에서 힘을 느껴서 그랬던 것 같아요. 예를 들어 ‘가게에 뛰러 갈게’라고 하면 뭘 살 거냐고 물었을 때 ‘산다고는 안 했고, 가게까지 달리기만 할 거야’라고 답하는 식이죠. 여러 뜻 중 어떤 게 의도였는지 독자가 추측해야 한다면, 아무리 문장이 쉽게 읽혀도 소통은 실패한 겁니다.

저는 지금 LLM을 가장 열렬히 지지하는 사람들이 결과물을 자세히 읽거나 검토하지 않는 걸 가장 열렬히 지지하는 사람들과 겹친다고 봅니다. 그렇다고 모두가 그렇다는 뜻은 아니죠. 저도 LLM을 적극 지지합니다. 1980년대 후반 이미지 인식용 신경망을 처음 구현했고, 지금은 코딩 등 여러 작업에 매일 LLM을 씁니다. 단순한 데이터 연동처럼 중간 코드의 품질이 별로 중요하지 않은 경우가 아니면 이른바 바이브 코딩은 잘 하지 않습니다. 도구 호출을 하나씩 승인하거나 거부하고, 잘못되면 이유를 설명하고, 필요하면 중간에 끊어 방향을 바꿉니다. 직접 코드를 고치고 그 사실도 알려 줍니다. 그래도 LLM은 정말 유용합니다. 현실적으로 많은 주니어 개발자보다 더 유용할 때도 있어요. 개발의 여러 중요한 측면에서 인간 개발자가 LLM을 따라잡기 힘든 것도 사실입니다. 하지만 그렇다고 지금 숙련된 인간이 설 자리가 없다는 뜻은 아닙니다. 여기서 어긋나는 건 AI 결과물이 저품질이라는 평가가 지나치게 단순하다는 점입니다. 자연어 글쓰기 품질은 원문에서 말한 이유들 때문에 다르게 나타나고, 저품질이라는 비판 중 일부는 사람이 쉽게 이해하기 어려울 만큼 압축됐다는 뜻이기도 합니다. 코드 품질은 프롬프트에 크게 좌우되고요. 좋은 글과 코드를 막는 큰 요인 중 하나는 인간이 만든 학습 데이터인데, 거기에는 조지 칼린의 관찰에 들어맞는 사람들이 절반이나 있다는 점입니다.

영어 원어민의 게으름, 특히 서쪽에 사는 사람들의 게으름은 오래전부터 경고받았죠. (기분 나쁘게 듣지 마세요.) 그렇다면 글쓰기 도구는 정확성, 일반적인 용법, 독자가 이해할 가능성 중 무엇에 집중해야 할까요? 러시아와 중국 동료들이 영어로 쓴 문장에서 관사를 빼먹어도 무슨 뜻인지는 이해할 수 있었습니다.

제 말을 정확히 설명해 주셨네요. 언어의 목적은 의미를 전달하는 것이고, 제가 Google에 their를 쓴 것도 회사가 무생물이라는 관념을 일부러 거부하고 사람들을 가리키려는 의도였습니다. 그 부분을 고치면 글의 목소리와 개성이 바뀝니다. LLM 글이 읽기 어려운 것도 그런 이유예요. 언어 규칙은 따르지만, 정확성보다 정보 전달이 중요하고 언어는 혼란스럽게 변한다는 사실을 받아들이지 못하니까요.

코드는 유지보수하기 아주 쉽습니다. 다만 인간이 유지보수할 수 없을 뿐이죠.

‘그들의’가 맞는 표현은 아닐 것이라는 말에 대해: 맞는 표현입니다. 집합명사와 문법적 수의 환유적 병합을 보세요. ‘corporation’s financial report’처럼 회사의 재무 보고서라고 말할 수도 있습니다. 특정 교과서의 지나치게 세세한 규칙에 집중하는 것 같아요. 다른 사람들이 말했듯 규범 문법과 기술 문법의 차이입니다. 기술 문법은 언어가 실제로 어떻게 쓰이고 변화하는지를 설명하므로 언제나 더 낫습니다. 규범 문법은 언어가 변하지 않고 정확히 기술할 수 있다고 가정합니다. 실제 언어의 규칙을 완전히 배우려면 대학에서 여러 해 공부해야 하고, ‘무생물은 소유격 ’s를 쓸 수 없다’처럼 간단하지 않습니다. 규범 문법은 학교 교육이나 기준을 익힐 때는 쓸모 있지만, 지나치게 마음에 담아 두는 사람도 많아요.

이건 이해하기 어렵네요.

이 얘길 들으니 31년쯤 전 Windows 95 시절에 처음 Microsoft Word를 썼던 때가 생각납니다. 문법 검사기가 여기저기 밑줄을 그었죠. ‘수동태를 쓰지 마세요!’ 같은 조언을 말입니다. 그래도 당시에는 더 찾아보고 받아들일지 결정할 수 있는 조언이었어요. AI의 결과를 교정용으로만 써도 그대로 받아들이는 사람이 많습니다.

저는 책을 못 읽습니다. 두 문단 전에 무슨 말이 나왔는지 잊어버리거든요. 글을 빨리 훑어 읽는 사람은 AI 글을 덜 힘들어할 것 같습니다. 사실 LLM이 만든 글은 훑어 읽기가 거의 불가능해요. 너무 장식적이고, 의미가 글 전체에 얇게 퍼져 있어서 문단에서 ‘중요한’ 문장만 골라 읽을 수가 없습니다.

이 패턴을 저도 많이 봤는데 정말 별로예요. 사람이 이렇게 쓰지는 않죠.

이런 점을 알아차린 사람이 저뿐이 아니라 다행입니다. 사람이 이해하기 어려운 글을 쓰면 대개 너무 장황합니다. 어려운 단어, 너무 많은 단어, 긴 문장, 괄호 속 설명 같은 것들이요. 하지만 LLM은 특이하게 너무 압축해서 글을 어렵게 만듭니다. ‘원시인’ 같기도 하고 ‘미친 과학자’ 같기도 해요. Claude와 Codex는 코드가 무엇을 하는지, 수정 사항이 무엇인지 설명하려고 자기들만의 전문 용어를 만들어 내기도 합니다. 거슬리지만, 제가 단순한 문장을 못 알아보는 건가 걱정했어요.

대체로 동의하지만 좀 더 미묘한 문제라고 생각합니다. 언어는 시간이 지나며 변하고, 언어 변화에서 잘 알려진 경향 중 하나는 불규칙한 특징을 더 규칙적으로 일반화하려는 겁니다. 영어 동사 중에는 목적어를 받거나 받지 않는 두 방식 모두 자연스러운 것이 많아요. ‘내가 문을 열었다’, ‘문이 열렸다’, ‘문이 열렸다’처럼요. 이런 변화는 LLM 이전부터 있었고, 특히 전문 용어에서 흔했습니다. 깐깐한 사람은 ‘컴파일러가 코드를 컴파일할 때까지 기다려라’고 해야 한다고 하겠지만, 개발자들은 ‘코드가 컴파일될 때까지 기다려’라고도 하죠. 특정 동사의 쓰임이 사회적으로 자리 잡았다면 가끔 쓰는 건 괜찮다고 봅니다. 문제는 LLM이 그 표현을 지나치게 많이 쓰고 여기저기 뿌린다는 거예요. ‘X가 아니라 Y다’ 같은 표현도 사람 글에서는 가끔 괜찮지만, 너무 반복되면 진부해지는 것처럼요.