AI 글쓰기 전문성이 안 나온 이유 — 검사기가 아니라 재료였다

증상 — 자동으로 쓴 글 68건 중 64건에 기술 어휘가 한 개도 없었다

우리는 회사가 그날 실제로 한 작업을 소셜 계정에 매일 한 편씩 올립니다. 사람이 쓰지 않고 파이썬 스크립트와 AI 에이전트가 씁니다. 목적은 홍보 문구가 아니라 기록입니다. 무엇을 어떻게 고쳤는지가 남아야 읽는 사람이 우리 실력을 짐작할 수 있다고 봤습니다.

그런데 나오는 글이 계속 밋밋했습니다. 회사 대표의 표현을 그대로 옮기면 「기술 블로그 수준으로 가자고 했는데 왜 죄다 평문 설명뿐이고, 쓰는 용어조차 전문 용어나 전문적인 개념이 없느냐」였습니다. 같은 지적이 2026년 8월 31일에도 한 번 나왔습니다. 그때는 소재 유형이 원인이라고 답했고 그 답 자체는 맞았지만, 이 질문에 대한 답은 아니었습니다.

같은 지적이 두 번 나오면 첫 번째 답이 틀렸거나, 맞았지만 질문을 비껴갔다는 뜻입니다. 그래서 인상을 버리고 수를 셌습니다. 그때까지 올린 글은 68건이었고, 그중 기술 어휘가 한 개도 없는 글이 64건이었습니다. 비율로는 94퍼센트입니다.

94퍼센트는 우연으로 설명하기 어려운 수입니다. 어쩌다 몇 편이 쉬운 말로 나온 것이 아니라, 전체가 한 방향으로 눌려 있다는 신호입니다. 눌린 것이라면 누르는 힘이 어딘가에 있어야 합니다. 이 글은 그 힘을 엉뚱한 데서 찾다가 두 번 헛짚고 세 번째에 찾은 기록입니다.

처음 의심한 것 — 출력 단계의 어휘 검사기

파이프라인 맨 뒤에는 어휘 검사기가 있습니다. 글이 다 만들어진 다음, 밖으로 나가면 안 되는 표현이 섞였는지 보고 걸리면 되돌려 보내는 장치입니다. 원래는 우리 저장소에서만 통하는 이름이 밖으로 새어 나가는 상황을 막으려고 만들었습니다.

이 검사기가 반려하는 목록에는 크론·파싱·스키마·엔드포인트·인덱스·파라미터·브랜치·롤백·폴백·셀렉터 같은 낱말이 들어 있었습니다. 여기에 더해 파이썬 파일 이름 전부, 괄호를 붙인 함수 표기, 하이픈이나 밑줄이 들어간 식별자도 전부 반려 대상이었습니다.

목록을 다시 읽고 나니 답이 나온 것 같았습니다. 기술 글에서 쓰고 싶은 말이 정확히 그 목록 안에 있었기 때문입니다. 스케줄러 이야기를 하려면 크론을 말해야 하고, 응답 구조 이야기를 하려면 스키마를 말해야 합니다. 그 말을 쓰면 반려되니 글이 평문으로만 나온다 — 앞뒤가 맞는 설명이었습니다.

여기까지가 우리가 세운 첫 가설입니다. 원인은 검사기이고, 검사기를 풀면 전문성이 올라온다. 그럴듯했기 때문에 위험했습니다. 그럴듯한 가설은 확인을 건너뛰게 만듭니다.

그 가설을 무엇으로 확인했나

확인 수단은 두 가지를 잡았습니다. 성격이 다른 두 방향에서 같은 가설을 찔러 보려는 의도였습니다.

• 첫째, 반려 로그를 셉니다. 검사기가 원인이라면 반려 기록이 쌓여 있어야 합니다. 이건 가설이 참일 때 반드시 남는 흔적을 찾는 방향입니다
• 둘째, 반응 데이터를 다시 잽니다. 검사기를 풀 만한 근거가 있는지 보려면, 기술 어휘가 든 글이 실제로 더 좋은 반응을 받는지 확인해야 합니다

두 번째 수단은 방법을 조금 설명해야 합니다. 우리는 같은 계정이 올린 글끼리 짝을 지어 비교합니다. 짝짓기는 비교하고 싶은 조건 하나만 다르고 나머지 조건은 최대한 같은 두 대상을 붙여 놓는 방법입니다. 계정이 다르면 팔로워 수가 다르고 주제가 다르니, 계정을 고정하지 않고 평균만 비교하면 계정 차이를 재고 앉아 있게 됩니다.

짝을 지은 다음에는 부호검정을 씁니다. 부호검정은 각 짝에서 어느 쪽이 이겼는지만 세고 이긴 폭은 버리는 방법입니다. 반응 수는 몇몇 글이 크게 튀어 평균을 끌고 가기 때문에, 폭을 버리고 승패만 세면 그 왜곡에서 자유롭습니다. 대신 얻는 답이 「얼마나 좋은가」가 아니라 「더 좋은 쪽이 어디인가」로 좁아집니다.

이 두 수단으로 잰 결과가 둘 다 첫 가설과 반대로 나왔습니다.

알리바이 하나 — 검사기는 두 번밖에 반려하지 않았다

반려 로그를 열었습니다. 검사기가 실제로 글을 되돌려 보낸 기록은 2회였습니다. 그것도 우리 저장소 안에서만 쓰는 짧은 낱말 하나를 잡은 건이었습니다. 기술 용어를 막아서 글이 밋밋해졌다면 반려가 수십 건은 쌓여 있어야 하는데, 그런 기록이 없었습니다.

여기서 구조가 뒤집혔습니다. 막는 장치는 거의 작동하지 않았고, 대신 지시문이 일하고 있었습니다. 에이전트가 글을 쓰기 전에 읽는 지시문에는 이런 문장 두 줄이 들어 있었습니다. 하나는 「권위는 어려운 말이 아니라 검증 가능한 구체성에서 나온다」였고, 다른 하나는 「이름이 아니라 하는 일로 적으면 전문 용어 없이도 구체적일 수 있다」였습니다.

두 문장 다 틀린 말이 아닙니다. 오히려 좋은 조언입니다. 문제는 이 조언을 읽은 에이전트가 검사기에 걸리기 한참 전에 스스로 평문을 고른다는 데 있었습니다. 반려가 2회뿐인 이유가 바로 이것입니다. 걸릴 문장이 애초에 만들어지지 않았습니다.

차단이 아니라 지시가 일을 하고 있었습니다. 모델은 지시문을 읽고 미리 평문으로 씁니다. 그래서 반려 기록만 보면 검사기는 무죄로 보입니다.

이건 자동화를 손볼 때 자주 놓치는 자리입니다. 우리는 「무엇을 막았나」를 로그로 남기지만 「무엇을 아예 시도하지 않게 만들었나」는 어디에도 안 남습니다. 앞쪽 지시문이 조용히 만든 결과를 뒤쪽 검사기의 로그에서 찾으면 영원히 못 찾습니다.

알리바이 둘 — 검사기를 풀면 반응이 올라가나?

반려가 2회뿐이라는 사실만으로 검사기를 풀 수는 없습니다. 지시문 두 줄을 지우고 검사기를 열면 전문 용어가 늘긴 하겠지만, 그게 좋은 선택인지는 별개 질문입니다. 그래서 반응 데이터를 다시 쟀습니다. 표본은 43,049건이었습니다.

표에서 눈에 걸리는 자리는 위 두 줄입니다. 기술 어휘 축은 전체 표본에서 516건 대 522건이고, 개발 계정만 추린 표본에서는 355건 대 355건으로 정확히 반반입니다. 차이 중앙값도 둘 다 0입니다. 기술 용어는 반응을 올리지도 내리지도 않았습니다.

아래 두 줄과 비교하면 성격 차이가 분명합니다. 줄바꿈을 넉넉히 준 글은 899건 대 682건으로 이겼고 차이 중앙값이 +4입니다. 돈과 수치를 넣은 글은 609건 대 465건에 +1입니다. 이 두 축은 방향이 있습니다. 기술 어휘 축에는 방향이 없습니다.

통계 수치가 유의하게 나오긴 했습니다. 다만 그 유의성은 방향이 아니라 꼬리 크기에서 나왔습니다. 평균 차이가 -12로 음수인데, 이건 크게 진 글 몇 편이 만든 값입니다. 승패가 반반이면서 평균만 음수라는 건 「기술 어휘가 반응을 깎는다」가 아니라 「가끔 크게 지는 글이 있다」는 뜻입니다.

우리는 이 검사기를 풀 조건을 미리 문서에 적어 뒀습니다. 기술 어휘가 반응을 유의하게 올린다는 결과가 나오면 푼다는 조건이었습니다. 재실측 값은 전체 표본에서 0.974였고 개발 계정 표본에서는 0.960이었습니다. 그 조건에서 한참 멀었습니다. 그래서 검사기는 유지했습니다.

여기까지 두 번 헛짚었습니다. 검사기는 거의 작동하지 않았고, 풀 근거도 없었습니다. 원인은 다른 데 있었습니다.

진짜 원인 — 재료 창고에 코드가 한 건도 없었다

막는 쪽이 아니라 넣는 쪽을 봤어야 했습니다. 그래서 이미 올린 68건이 각각 어떤 재료에서 나왔는지 출처별로 셌습니다.

코드에서 온 재료가 0건입니다. 가장 최근 8건은 더 노골적이었습니다. 전부 업무 매뉴얼과 남의 사업 조사록, 규칙 문서였습니다. 셋 다 산문입니다.

이 네 종류가 각각 무엇을 담는지 적어 보면 왜 전문성이 안 나왔는지가 바로 보입니다.

• 결정 기록에는 「무엇을 고치기로 했나」가 있습니다. 결론과 근거는 있지만 동작은 없습니다
• 조사록에는 「남이 어떻게 하나」가 있습니다. 우리 손으로 만든 것이 아닙니다
• 업무 매뉴얼에는 「어떤 순서로 하나」가 있습니다. 절차이지 원리가 아닙니다
• 「이건 이렇게 돌아간다」를 담은 재료는 한 종류도 없었습니다

없는 것을 쓰라고 지시문에 적으면 모델은 지어내거나 뭉갭니다. 지어내면 사실이 틀리고, 뭉개면 「무언가를 고쳤습니다」 같은 문장이 나옵니다. 우리가 읽으면서 밋밋하다고 느낀 글이 정확히 후자였습니다.

즉 세 겹으로 눌려 있었습니다. 지시문이 평문을 권했고, 검사기가 뒤에서 한 번 더 좁혔고, 무엇보다 쓸 재료에 작동 원리가 없었습니다. 앞의 두 겹만 손보면 재료 없는 자리에서 어려운 말만 늘어날 뿐입니다. 값 하나가 여러 층에서 정해질 때 판정이 어떻게 뒤집히는지는 같은 이름이 여러 층을 가리킬 때 생긴 오판 기록에 따로 적어 뒀습니다.

고친 방법 — 설명만 뽑고 코드 본문은 가져오지 않았다

재료 창고에 코드를 넣기로 했습니다. 대상은 이 파이프라인을 돌리는 파이썬 파일과 회사 자동화 스크립트입니다. 다만 코드를 통째로 넣지는 않았습니다.

코드 본문 대신 모듈과 함수에 붙은 설명만 뽑습니다. 파이썬 표준 도구로 파일 구조를 읽어 설명 부분만 떼어 오는 방식이라, 실제 구현 줄은 창고에 들어가지 않습니다. 우리가 쓰려는 것은 「이 코드가 무슨 문제를 어떻게 푸는가」이지 코드 자체가 아니기 때문입니다. 이렇게 확보한 소재가 71건이었습니다.

글을 쓸 때 쓰는 질문 틀도 이 재료 전용으로 따로 만들었습니다. 세 문항입니다. 이 문제를 보통 어떻게 푸는지, 그 방식이 어디서 깨지는지, 그래서 우리가 쓴 방법은 무엇이고 무엇으로 확인했는지.

여기에 한 줄을 더 넣었습니다. 개념어는 피하지 말라는 지시입니다. 짝짓기·중앙값·부호검정·멱등처럼 그 분야가 실제로 쓰는 말은 쓰고, 처음 나올 때 한 줄로 풀라고 적었습니다. 이 글에서 부호검정을 설명한 문단이 그 규칙을 따른 결과입니다.

이 지점이 세 번째 원인이었습니다. 검사기가 막는 대상은 개념이 아니라 우리 저장소의 이름과 구현 은어인데, 그 구분이 지시문에 없었습니다. 구분이 없으니 에이전트는 안전한 쪽으로 기울어 개념어까지 함께 버렸습니다.

창고에서 빼는 파일도 정했습니다. 로그인과 자격 증명을 다루는 파일, 차단 규칙 파일은 애초에 소재가 아닙니다. 여기에 우리를 차단한 계정을 추적하는 파일과 올린 답글을 회수하는 파일도 뺐습니다. 그건 성과가 아니라 흉터입니다.

여기까지를 회귀 검사 7건으로 묶었습니다. 창고가 비었는지, 빼기로 한 파일이 실제로 빠지는지, 코드 본문이 새지 않는지, 문법이 깨진 파일이 들어와도 버티는지, 사건 재료 하한을 지키는지, 전용 질문 틀이 붙는지를 각각 확인합니다.

열자마자 무엇이 새어 나올 뻔했나

창고를 연 직후에 소재 71건을 전수로 훑었습니다. 새 재료가 들어왔으니 한 번 보자는 정도였는데, 여기서 두 종류가 걸렸습니다.

먼저 8건에 다른 사람의 계정 이름이 그대로 들어 있었습니다. 코드 설명은 그 파일이 다루는 대상을 실명으로 적어 근거를 남기기 때문입니다. 밖으로 나가면 우리가 그 사람들을 훑고 있다는 자백이고, 당사자에게는 동의 없이 공개된 프로파일링입니다.

다음으로 2건에 채널별 성과 수치가 들어 있었습니다. 이건 우리 영업 파이프라인의 원가표에 해당합니다. 경쟁사에게는 지도이고 우리에게는 약점 고백이라 공개 대상이 아닙니다.

하필 우선순위 1위 소재가 두 가지를 다 가진 파일이었습니다. 그리고 그 시각 오전 10시 40분 정기 실행이 정확히 그 소재로 글을 쓰고 있었습니다. 초안 생성 단계였고 경과 시간은 1분 6초, 발행은 아직 0건이었습니다. 중단 스위치를 누르고 실행 중인 프로세스를 세웠습니다. 이미 올라간 68건은 그대로였습니다.

여기서 중요한 판단을 하나 했습니다. 이걸 출력 검사기로 막으려 하지 않았습니다. 검사기에는 백분율 표기를 잡는 규칙이 있지만, 모델이 「열 건 중 한 건」이라고 풀어 쓰면 그대로 통과합니다. 표현을 막는 방식은 언제나 우회로가 남습니다.

그래서 소재 단계에서 뺐습니다. 애초에 재료로 들어오지 않으면 어떤 표현으로도 나갈 수 없습니다. 같은 교훈을 자산 재료에서 이미 한 번 배웠습니다. 그때는 경로 필터를 통과한 다음 본문이 새어 나온 사례가 12건이었습니다.

이 조치로 소재는 71건에서 61건으로 줄었고, 우선순위 1위도 다른 파일로 바뀌었습니다. 새 1위는 판매 서비스를 6개 축으로 채점하는 코드인데, 그 채점을 122번 쓰는 동안 한 번도 검증하지 않았다는 자기비판을 담고 있습니다. 회귀 검사 4건을 추가했고 전체 160건이 통과했습니다.

지금 상태와 아직 판정하지 못한 것

정리하면 이렇습니다. 처음 의심한 어휘 검사기는 실제 반려가 2회뿐이라 범인이 아니었고, 그 검사기를 풀 근거도 43,049건 재실측에서 나오지 않았습니다. 원인은 소재 창고에 작동 원리를 담은 재료가 0건이었다는 데 있었고, 코드 설명만 뽑는 창고를 새로 열어 61건을 확보했습니다.

아직 답이 없는 부분을 그대로 적습니다. 이 창고에서 나온 글이 실제로 전문적으로 읽히는지는 우리가 판단하지 않습니다. 발행한 뒤 별도 채점기가 잽니다. 그 채점기는 표본 3건이 쌓이기 전까지 판정을 내리지 않으므로, 지금은 판정 불가 상태입니다.

한 가지 더 남습니다. 지시문 두 줄과 어휘 검사기는 그대로 두기로 했는데, 재료가 좋아진 뒤에도 같은 압력이 남아 있는지는 다시 재야 합니다. 이번에 확인한 것은 「재료가 없을 때는 앞뒤 조절이 소용없다」까지입니다.

같은 종류의 자동 글쓰기 파이프라인이 밋밋한 결과만 낸다면, 대개 문제는 문장 규칙이 아니라 그 앞의 재료에 있습니다. 반응 데이터로 글의 형식을 판정한 다른 기록은 스레드 반응 유형을 짝지어 잰 글에 있고, 회사 업무에 이런 파이프라인을 얹는 문제는 상담으로 문의 주시면 어디서부터 재료를 확보해야 하는지 같이 봅니다. 이 글은 SGK Studio가 썼습니다.