Blog - < 내 문체를 숫자로 바꿔봤다 >

개요

요즘 포스팅에 AI의 도움을 받고 있다. 확실히 빠르고, 표나 비유를 만들어주니 읽기도 편해졌다.
그런데 다 쓰고 나서 읽어보면 묘하게 내 글이 아니었다. 내용은 맞는데 말투가 남의 것이었다!

읽기는 좋은데 내가 쓴 것 같지가 않다. 이게 왜 그런지 설명할 수가 없었다.

문제가 하나 더 있었다. 글 하나 쓸 때마다 말투는 이렇게, 형식은 저렇게, 수식은 이렇게 조심하라고 매번 처음부터 설명하고 있었다.
같은 말을 세 번쯤 반복하고 나니 이건 지시가 아니라 절차라는 생각이 들었다.

그래서 이번엔 글을 쓰는 대신 글 쓰는 절차를 만들었다. 이 글은 그 과정의 기록이다.

이번 글이 답할 질문 — “내 문체”라는 말을 어떻게 남에게(그리고 기계에게) 전달할 것인가?

1. 문제 — “내 말투로 써줘”는 지시가 아니다

처음엔 이렇게 부탁했다. “내 블로그 말투로 써줘.” 결과는 매번 조금씩 달랐다.
당연했다. 나조차 내 말투를 설명하지 못하는데 상대가 알아들을 리가 없다!

내가 아는 건 이 정도였다.

반말로 쓴다 (~다로 끝난다)
느낌표를 좀 쓰는 것 같다
표를 자주 만든다

전부 “~인 것 같다” 였다. 감이지 정보가 아니다.
“좀 쓴다”가 한 편에 두 번인지 스무 번인지에 따라 글의 인상이 완전히 달라지는데, 나는 그 숫자를 몰랐다.

말투를 옮기려면 먼저 말투를 측정해야 한다. 감은 전달되지 않고, 숫자는 전달된다.

다행히 재료는 이미 있었다. 이 블로그에 216편의 글이 쌓여 있었다.

2. 문체를 숫자로 — 161편, 29,004줄을 셌다

먼저 표본을 정했다. 2026년 7월 이전 글 161편만 썼다.
7월 이후 글은 이미 AI 손을 탄 문체라, 그걸 표본에 넣으면 AI가 만든 말투를 AI에게 다시 가르치는 꼴이 된다!

표본을 고를 때 중요한 건 양이 아니라 오염되지 않았는가다.

161편의 front matter를 걷어내고 본문만 모으니 29,004줄이 나왔다. 이제 세면 된다.

무엇을 셌나

문체 실측 결과

“좀 쓴다”고 생각했던 느낌표가 두 줄에 한 번꼴이었다. 감보다 훨씬 많았다!
반대로 이모지는 한 번도 안 썼다. 이건 스스로도 모르고 있었다.

그런데 진짜 수확은 개수가 아니었다. 느낌표와 마침표가 거의 반반이었는데, 아무 데나 섞인 게 아니었다.

문장부호 규칙

이 셋의 구분이 내 문체의 거의 전부였다. 그런데 나는 이걸 의식하고 쓴 적이 없다.

자주 쓰는 단어에서도 하나 나왔다. 기존과 이전에가 128회. 새 걸 배울 때마다 아는 것 옆에 놓고 비교하는 습관이 통계로 드러난 셈이다.

더 쉬운 비유로

감 = “저 사람 걸음이 좀 빠른 것 같아”
측정 = “분당 120보, 보폭 75cm”

첫 번째로는 그 사람 걸음걸이를 흉내 낼 수 없다. 두 번째로는 흉내 낼 수 있다.
성대모사도 똑같다. 잘하는 사람은 “목소리가 비슷하다”가 아니라 “말끝을 올린다, 문장 앞에 숨을 한 번 쉰다” 처럼 규칙으로 잡아낸다.

내가 한 건 내 글에 대고 성대모사 연습을 한 것이다. 대상이 나 자신이었을 뿐이다.

이 수치들을 voice.md 라는 파일 하나로 정리했다. 이제 “내 말투로 써줘” 대신 이 파일을 읽으라고 하면 된다.

3. 구조도 숫자로 — 최근 글이 더 읽히는 이유

여기서 예상 못 한 게 나왔다. 문체는 7월 이전이 내 것인데, 읽기 편한 건 7월 이후 글이었다.
막연히 “요즘 글이 잘 읽히네” 정도로 느끼고 있었는데, 이것도 세어보니 이유가 분명했다.

7월 이후 55편(13,910줄)과 이전 161편을 편당으로 맞춰서 비교했다.

7월 전후 구조 비교

가독성의 정체가 이 그림에 다 있었다.

번호를 붙여 섹션으로 끊고, 사이에 구분선을 넣고, 섹션마다 핵심 한 줄을 인용으로 뽑고, 비교는 표로.

특히 인용이 24배 차이 난 게 컸다. 예전 글에서 나는 인용을 거의 안 썼는데, 최근 글은 섹션마다 결론을 하나씩 뽑아 세워둔다.
한 섹션을 다 읽고 하나만 기억한다면 무엇인가 — 그걸 미리 정해서 박아두는 것이다!

그래서 결론이 이렇게 정리됐다.

문체는 7월 이전(내 것), 구조는 7월 이후(읽히는 것). 섞어 쓰는 게 맞다.

내 글버릇을 지키는 것과 읽는 사람을 편하게 하는 건 다른 문제였다. 둘을 따로 떼어놓고 나서야 둘 다 챙길 수 있었다.

그림도 세어봤다. 편당 1.5장에서 2.8장으로 늘어 있었다. 그런데 여기서 그냥 넘어가면 안 되는 게 하나 더 나왔다.

시기	편당 이미지	직접 올린 캡처	만들어낸 그림
7월 이전 161편	1.5장	204장 (86%)	0장
7월 이후 55편	2.8장	27장 (18%)	125장 (82%)

장수는 늘었는데 실제 화면이 사라졌다. 예전 글에는 내가 직접 찍은 에러 화면과 로그가 있었는데, 최근 글은 대부분 그려낸 그림이다.
이건 뒤에서 다시 다룬다.

4. 검증 — 빌드를 못 돌리는데 어떻게 확인하나

말투와 구조가 정해졌으니, 이제 쓴 글이 제대로 나오는지 확인할 차례였다.
이 블로그는 Jekyll로 돌아가니 빌드를 한 번 돌려보면 될 일이다. 그런데 작업 중인 PC에 Ruby가 없었다.
설치하면 되지만, 글 하나 검사하자고 환경을 통째로 얹는 건 과했다.

게다가 빌드가 성공해도 못 잡는 게 있다. 수식이 깨진 채로도 빌드는 멀쩡히 통과한다!

빌드 성공은 “에러가 안 났다” 는 뜻이지 “제대로 보인다” 는 뜻이 아니다.

git 히스토리가 곧 사고 기록이었다

막혔다 싶었는데, 생각해보니 자료가 이미 있었다. 내가 그동안 서식이 깨져서 고친 커밋들이다.
git log를 뒤지니 원인까지 적어둔 커밋이 줄줄이 나왔다.

7f6360e — 수식 안에 쓴 중괄호 이스케이프를 kramdown이 먹어버려서, 수식 전체가 LaTeX 원문 그대로 화면에 노출됐다
857b6ba — 코드블록에 넣은 박스 문자(─│┌┐)가 폰트마다 폭이 달라서 정렬이 통째로 어긋났다
db0a49a — 같은 원인으로, 퍼센트 기호 앞의 백슬래시가 먹히자 퍼센트가 LaTeX 주석이 되어 뒷부분이 통째로 사라졌다

세 번째가 제일 무서웠다. 에러도 안 나고, 그냥 글 일부가 조용히 없어진다.

여기서 규칙 하나가 나왔다.

백슬래시 뒤에는 알파벳만 온다. 이 한 줄만 지키면 수식 사고의 대부분이 안 난다.

그래서 빌드 대신 검사기(linter)를 만들었다. 파이썬 한 파일이다.
“빌드가 통과하는가”가 아니라 “내가 예전에 밟았던 지뢰를 또 밟았는가” 를 보는 물건이다.

검사 항목은 실제로 겪은 것만 넣었다. 수식 블록 앞뒤 빈 줄, 표의 열 수, 본문에 섞인 템플릿 문법, 안 닫힌 코드블록, 없는 이미지 경로, 그리고 위의 백슬래시 규칙.
( 나중에 그림을 다루면서 그린 그림이 제대로 됐는지 보는 검사도 여기 붙게 된다 )

만들자마자 나를 세 번 틀렸다고 했다

검사기를 돌리니 멀쩡한 글에서 경고가 쏟아졌다. 세 가지가 오탐이었다.

오탐	원인	수정
제목 `C# - <1>` 이 위험하다	제목의 `#`을 주석 시작으로 오해	앞에 공백이 있을 때만 잡도록
본문에 대제목이 있다	코드블록 안의 파이썬 주석을 제목으로 오해	코드블록 구간을 먼저 걷어내고 검사
60줄 동안 안 끊긴다	소제목을 “끊는 지점”으로 안 셈	소제목도 숨 돌릴 곳으로 인정

특히 두 번째가 뜨끔했다. 검사하는 쪽이 코드블록을 구분 못 하고 있었다..

검사기를 만들 때 진짜 일은 규칙을 짜는 게 아니라, 멀쩡한 걸 틀렸다고 하지 않게 만드는 것이다.

경고가 남발되는 검사기는 아무도 안 본다. 그럼 없느니만 못하다!

제대로 도는지 확인하려고 일부러 함정 7개를 심은 가짜 초안을 만들어 돌려봤다. 6개가 잡혔다.
못 잡은 하나는 수식 블록 뒤에 빈 줄이 없는 경우였고, 그 검사를 추가해서 7개를 채웠다.

5. 과거의 나를 검사했더니 31건

이제 216편 전체에 돌려봤다. 에러 31건이 나왔다. 전부 내가 올린 글이다..

유형	건수
배너 설정 누락	17
본문에 템플릿 문법 노출	5
표의 열 수 어긋남	2
코드블록이 안 닫힘	2
작성자 누락	2
백슬래시 줄바꿈	2
파일명에 공백	1

몇 개는 실명으로 남긴다.

2026-07-17-blog.md — 코드블록이 안 닫혀 있다. 86번째 줄 이후 본문이 전부 코드로 렌더링되는 중이다
2025-04-25-typescript.md — 표 안에 유니온 타입을 그대로 썼더니 세로줄이 열 구분자로 먹혀서 표가 통째로 문단이 됐다
2024-12-13-bootcamp .md — 파일명에 공백이 들어가 있다 (bootcamp 뒤를 잘 보자)

가장 뜨끔한 건 바로 앞 편이었다.

2026-08-13-blog-search.md — 검색 기능을 고치며 배운 걸 정리한 글인데, 본문에 템플릿 문법이 5곳 그대로 노출됐다. 게다가 예시로 적은 제목이 글의 목차로 새어 들어가서 섹션 번호가 6번 → 8번 → 7번 → 8번 순으로 붙어 있었다

검색이 왜 원하는 글을 못 찾았는지 분석한 글이, 정작 자기 목차가 어긋난 걸 몰랐다.

이걸 발견하고 좀 웃었다. 그리고 이게 검사기를 만들길 잘했다는 가장 확실한 증거였다.
사람 눈은 자기가 쓴 글을 잘 못 본다. 이미 아는 내용이라 읽는 게 아니라 기억을 재생하기 때문이다..

( 참고로 이 31건은 이번에 고치지 않았다. 이번 작업 범위가 아니었고, 목록이 있으니 언제든 손댈 수 있다 )

6. 스킬로 묶기 — 절차를 파일로

마지막은 이걸 다음에도 쓸 수 있게 만드는 일이었다. 절차 하나와 파일 세 개로 정리했다.

절차와 파일 구성

이 중 2단계가 핵심이다. 규칙을 아무리 잘 적어놔도 내가 무슨 생각을 했는지는 어떤 파일에도 없다.
그래서 초안을 쓰기 전에 반드시 묻게 했다. 이 주제를 어떻게 느꼈는지, 어디가 헷갈렸는지, 무엇과 비교하고 싶은지.

묻지 않고 쓴 글은 내 글이 아니다. 규칙은 말투를 흉내 낼 뿐, 생각까지 만들어내면 그건 거짓말이 된다.

실제로 이 글도 그 절차대로 나왔다. 분량, 핵심 메시지, 버그를 실명으로 쓸지, 시작한 계기, 마지막 심정 — 전부 먼저 답한 다음에 초안이 나왔다.

옮기다가 두 번 더 깨졌다

이 스킬을 다른 환경에서도 쓰려고 압축해서 꺼내는데, 여기서 또 두 개가 나왔다.

검사기가 기준 위치를 잘못 잡았다. 자기 파일 위치에서 세 단계 위를 블로그 폴더로 추측하고 있었는데, 스킬을 다른 데로 옮기니 그 추측이 깨져서 이미지가 전부 없다고 나왔다. 현재 작업 폴더 기준으로 바꿔서 해결했다
압축 파일의 경로 구분자. 윈도우 기본 압축 명령이 경로를 역슬래시로 적는데, 이건 압축 파일 규격에 어긋나서 다른 운영체제에서 폴더 구조가 뭉개진다. 파이썬으로 다시 만들어 정슬래시로 넣었다

옮기고 나서야 드러나는 버그가 있다. 한 곳에서만 돌려보고 다 됐다고 하면 안 된다!

7. 그림은 만들기 전에 물어본다

3번에서 미뤄뒀던 이야기다. 그림이 편당 1.5장에서 2.8장으로 늘었는데, 직접 찍은 화면은 86%에서 18%로 줄었다.

처음엔 그냥 좋은 신호인 줄 알았다. 그림이 늘었으니까. 그런데 예전 글을 다시 열어보니 아니었다.
거기엔 헬스체크가 끊기던 순간의 진짜 로그가 있었다. 지금 다시 봐도 그때 상황이 바로 떠오른다.
반면 최근 글의 그림은 예쁘긴 한데, 내가 실제로 본 화면은 하나도 없었다..

그려낸 그림은 내가 이해한 것을 보여준다. 찍은 화면은 실제로 일어난 일을 보여준다. 둘은 대체재가 아니다.

트러블슈팅 글에서 이건 꽤 심각한 문제다. 에러 화면 없이 “이런 에러가 났다”고 쓰면 그건 증언이지 증거가 아니다!

질문 하나로 갈랐다

그래서 절차에 규칙을 하나 넣었다. 그림이 필요할 때마다 먼저 이걸 묻는다.

그림 요청과 생성의 갈림

그리고 묻는 시점이 중요했다. 초안을 다 쓰고 나서 “이미지 있으면 주세요”는 늦다.
그때쯤이면 이미 그림 없이 말이 되게 글을 써버린 뒤라, 나중에 사진을 넣어도 겉돈다.

이미지 요청은 초안 전에. 목차를 잡을 때 “여기엔 실제 화면이 있어야 한다”를 같이 정한다.

요청도 두루뭉술하면 원하는 게 안 온다. 그래서 무엇이 찍혀 있어야 하는지까지 적게 했다.

나쁜 요청 — “에러 화면 있으면 주세요”
좋은 요청 — “헬스체크가 끊길 때 터미널 로그, 스택이 3까지 쌓인 순간이 보이는 걸로 한 장”

없다고 하면 억지로 만들지 않는다. 개념 그림으로 바꾸거나 → 빼거나 → 그 대목을 덜어낸다.
없는 화면을 그려서 채우는 건 안 하기로 했다. 그건 없는 증거를 만드는 일이다.

검사기에 한 줄 더

그림을 그리다 보니 새 사고가 생겼다. 글자가 그림 밖으로 나가서 잘렸다. 눈으로는 잘 안 보인다.

그래서 검사기에 두 가지를 붙였다. 그림 파일이 제대로 된 형식인지, 그리고 요소가 그림 경계를 넘지 않는지.
아직 안 받은 이미지 자리에 남겨둔 표시가 그대로 있으면 그것도 잡게 했다. 그건 덜 끝난 글이라는 뜻이니까.

절차 문서에 “확인해라”라고 적어두면 안 지켜진다. 기계가 보게 해야 지켜진다.

정리

감은 전달되지 않는다. “내 말투”를 옮기려면 먼저 세어야 한다. 161편 29,004줄을 세니 느낌표는 편당 11.6줄이었고, 이모지는 0회였다
세고 나서야 규칙이 보인다. 느낌표·마침표·말줄임을 어디에 쓰는지는 의식한 적 없는 규칙이었는데, 통계로 드러났다
표본은 양보다 오염 여부. AI가 다듬은 글을 표본에 넣으면 AI 말투를 AI에게 되먹이게 된다
문체와 구조는 다른 문제다. 문체는 예전 글이 내 것, 구조는 최근 글이 읽힌다. 따로 떼어놓으니 둘 다 챙길 수 있었다
빌드 성공은 제대로 보인다는 뜻이 아니다. 수식은 깨진 채로도 빌드를 통과한다
git 히스토리가 최고의 검사 규칙 재료였다. 내가 고쳤던 커밋이 곧 “또 밟을 지뢰” 목록이다
검사기의 진짜 일은 오탐을 없애는 것. 경고가 남발되면 아무도 안 본다
자기 글은 눈으로 못 잡는다. 216편에서 31건이 나왔고, 그중엔 바로 앞 편의 어긋난 목차도 있었다
그림은 늘리되 실물부터. 실물이 있는 자리를 그려서 채우면 증거가 증언으로 바뀐다. 요청은 초안 전에, 구체적으로
지키게 하려면 기계가 보게 한다. “확인해라”라고 적어둔 규칙은 안 지켜졌고, 검사기에 넣은 규칙만 지켜졌다

한줄 평

내 글버릇을 처음으로 숫자로 봤다. 느낌표를 이렇게 많이 쓰는 줄도, 이모지를 한 번도 안 쓴 줄도 몰랐다!