"AI야, 네 글 너무 밤티나" 18년 기록을 AI 스킬로

세션 소개

우아한형제들 기술 블로그 글 약 530편과 기술 블로그 10년, 우아한테크코스 8년(합쳐서 18년)의 기록으로 글 작성부터 검수까지 하는 스킬을 만든 이야기입니다. AI 티가 나는 글은 사람이 썼더라도 독자가 읽기를 꺼린다는 문제의식에서 출발합니다. 1부는 유영경(테크니컬 라이팅 코치), 2부는 조은현(웹 프런트엔드 개발자), 3부는 임동준(우아한테크코스 프런트엔드 코치) 님이 맡았습니다.

핵심 내용

ADR과 RFC 문서 구성

결정을 남기는 ADR과 의견을 구하는 RFC는 형식이 정해져 있어 AI로 초안 작성부터 검토까지 하기 쉽고, 기술 블로그와 책으로 넘어가면 난도가 크게 오릅니다. 스킬을 처음 만든다면 이런 정형화된 문서부터 시작하기를 권했습니다.

ADR (Architecture Decision Record, 아키텍처 결정 기록)

구성	쓰는 내용
`#` 제목	결정을 한 문장 명령형으로
`## Status`	제안, 승인, 기각 같은 결정 상태
`## Context`	결정이 필요한 배경과 제약
`## Decision`	확정한 결정을 단정형으로
`## Consequences`	좋아지는 점과 감수할 점
`## Alternatives`	검토한 대안과 고르지 않은 이유

RFC (Request for Comments, 의견 요청 문서)

구성	쓰는 내용
`#` 제목	내용을 파악할 수 있는 제목
`## 요약`	제안 내용을 짧게
`## 주요 문의 및 논의 사항`	리뷰어에게 묻고 싶은 점. 질문마다 리뷰어가 의견을, 작성자가 답변과 반영 여부를 적음
`## 과제 설명`	배경, 목표, 해결 방안, 고려한 대안
`## 수행 일정/계획`	일정과 단계
`## 부록`	참고 자료

검수 스킬 개발 과정

기술 블로그 글은 저자 조직의 1차 검수와 테크니컬 라이팅 코치의 2차 검수를 거쳐 발행하고, 코치는 일주일에 약 2편을 검수합니다. 가장 자주 남긴 의견은 도입부(배경, 대상 독자, 읽고 얻을 것) 누락과 제목·본문 불일치였고, 올해 초 이 검수를 Claude 스킬로 옮기기 시작했습니다.

재료: 교육 자료, 직접 쓴 책, 강의 자료, 영상. 기존 검수 결과와 원본 문장을 맵핑해 정밀 검수를 시도했고, 'LLM 모델' 같은 겹말, 지시어 반복, 번역 투를 잘 잡음
지침 충돌: 명확성을 위해 단정 표현을 쓰라고 하자 추측이어야 할 문장까지 단정형으로 고침
결과: WordPress 글 주소만 넣으면 검수 댓글까지 달고, 검토 업무 시간을 약 67% 절감
공개: 저자용 최소 품질 점검 스킬부터 공개. 사람 냄새 나는 부분까지 잡는 문제가 있어 항목 상당수를 선택 수정으로 둠. 이후 개발자들과 회사 공식 스킬, 오픈 소스 공개 준비. 정형 문서, 기술 블로그(참고·리서치형, 경험 공유형), 도서로 나눠 유형별·역할별 지침 8개 작성

문서 검수 스킬 예

검수 스킬은 문서를 여섯 갈래로 나눠 봅니다.

구분	점검 규칙
표기	같은 개념에 표기가 둘 이상이면 하나로 통일
	약어는 처음 나올 때 풀어 씀
	외래어는 외래어 표기법을 따름
	제품명, 서비스명은 공식 표기 그대로
	코드, 명령어, 파일명은 인라인 코드로
	숫자와 단위 표기 방식을 문서 안에서 통일
문장	한 문장에는 한 가지 내용만
	주어와 서술어 호응 확인
	번역 투 표현(~에 대해, ~을 통해) 순화
	지시어 대신 대상 이름
	피동 표현은 능동으로
	습관적인 접속사 줄이기
	같은 뜻 반복(중복 표현) 정리
문단	한 문단이 다섯 문장을 넘고 주제가 둘이면 지적
	30자 이하 문장이 한 문단에 셋 이상 이어지면 지적
	문단 첫 문장에 핵심
	앞 문단과 연결이 끊기면 지적
	한 문단에 예시가 연달아 나오면 하나만
구조	도입부에서 배경, 주제, 대상 독자, 읽고 얻을 것을 알 수 있게
	결론 먼저, 제목만 읽어도 주제를 알 수 있게
	소제목은 내용을 요약하는 말로
	목록 항목은 같은 형식으로
	표와 그림이 나오기 전에 설명 문장 추가
사실	수치, 인용, 고유 명사는 저자 확인
	출처 없는 인용 확인
	버전, 날짜는 원문과 대조
	추측을 사실처럼 쓴 문장 지적
AI 티	과장 수식어(혁신적인, 획기적인) 지적
	'~하는 것이 중요합니다' 같은 빈말 지적
	대구, 셋 나열 습관 지적
	문단 끝 요약 문장 반복 지적

이 표는 스킬 파일을 그대로 옮긴 것이 아니고 스킬에 넣은 지침 내용을 요약한 것입니다.

AI 티 나는 문체

기존 검수 기준에 없던 AI 티를 자주 만나면서, 사람이 쓰지 않았다는 느낌이 강한 표현을 따로 걸러 내기로 했습니다. AI 티를 문장 구조와 표현 두 갈래로 나눕니다.

문장 구조: 대조형, 순서 예고형, 그럴듯한 이유, 분열문, 단문 나열
표현: 추상 표현, 부풀린 평가, 문장 부호, '이, 그, 해당' 같은 지시어

유형	예문
대조형	이 도구는 단순히 로그를 모으는 도구가 아니라 장애 원인을 찾는 도구입니다.
분열문	배포할 때 특히 유의할 점은 환경 변수 설정입니다.
단문 나열	TDD를 처음 적용했습니다. 테스트부터 짜는 게 어색했습니다. 속도도 느렸습니다.
추상 표현	리팩터링은 과거의 나와 마주하는 일입니다. 낡은 코드를 손에 쥐고, 더 나은 구조로 나아가는 입구에 서는 것입니다.

자주 쓰는 단어나 어휘는 코드로 감지하기도 합니다.

그 밖의 패턴: 줄표와 가운데 점(Windows에서 입력하기 어려워 예전에는 쉼표나 '와/과'를 씀), 생각의 근육·결·축 같은 추상 어휘, 내용을 포괄하지 못하는 문장형 제목, 내용 없이 거창한 마무리
남은 고민: 여러 저자가 쓴 글에서 AI 문장만 골라 고칠지, 너무 짧게 끊긴 단문을 다시 이을지, 대조형 문장을 몇 개까지 둘지를 프로그램으로 정할 수 있는지

초안 점검 스킬 공개본

검수 스킬 중 최소 품질 점검 부분이 Claude Code 플러그인으로 공개되어 있습니다. 저장소: young-twc/techwriting-tools

techwriting-min-check 요약

외부 공개 전에 작성자가 초안을 스스로 점검하는 스킬입니다. 글이 최소선을 넘었는지만 보고, 글의 완성도나 설득력, 문체 취향은 판정하지 않습니다.

설치와 실행

/plugin marketplace add young-twc/techwriting-tools
/plugin install techwriting-check@techwriting-tools
/techwriting-check:techwriting-min-check <파일 경로, Google Docs 링크, 본문>

.md, .txt, .docx 파일, 붙여넣은 본문, Google Docs 링크를 받습니다. 결과는 채팅에 나오고 원본 옆에 <원본 이름>_점검.md로도 저장됩니다.

점검 항목 18개

구분	항목
1부: 구조와 틀	문서 목적, 대상 독자, 제목 명확성, 문서 구조
2부: 표현과 세부	민감 정보, 용어 약어 풀이, 용어 일관성, 번역 투, 겹말, 형식 일관성, 코드 표현 형식, 링크 무결성, 맞춤법 및 외래어 표기, 출처 표기, 저작권, 비문, 인증/시크릿 정보 노출, 미완성 흔적 잔존

판정

항목마다 통과 또는 보완 필요로 판정하고, 걸린 항목은 등급을 매깁니다.
P0(필수 수정): 목적·독자를 알 수 없음, 제목 없음, 민감 정보나 인증 정보 노출, 출처 없는 인용·통계·이미지, 오탈자, 작성 중 흔적. 하나라도 있으면 통과하지 못합니다.
P1(권장 수정): 독자 이해를 방해하는 항목. 고치지 않아도 통과합니다.
P2(선택 수정): 이해에는 문제없지만 다듬으면 좋은 항목.
판정이 애매하면 통과로 봅니다. 본문만 받아 링크나 저작권을 확인할 수 없으면 확인 불가로 따로 표시합니다.

2부: 탐지기와 블라인드 테스트

개발자 4명이 탐지기로 규칙 준수를 검사하고 블라인드 테스트로 독자 반응을 확인하며 스킬을 다듬었습니다. 규칙만 적어 주면 AI가 자주 놓쳐서, 문장 모양으로 잡을 수 있는 항목은 코드로 옮겼습니다.

탐지기: 사전 탐지기(스킬 안)는 AI가 고치기 전 의심스러운 곳에 맞춤법 검사기처럼 밑줄 표시. 사후 탐지기(스킬 밖)는 고친 결과가 고칠 곳을 고쳤는지, 남길 곳(인용 등)을 남겼는지, 확인할 곳을 작성자에게 넘겼는지 채점. 결과 문장이 매번 달라 글자 비교는 제외
실패 사례: '저는' 개수만 세던 사후 탐지기가 잘 고친 글을 감점하고 전부 지운 글을 통과시킴. 1인칭 문장이 연달아 나올 때만 잡게 고치고 직접 확인한 문장은 고정해 둠
블라인드 테스트: 초안 5편을 네 버전(초안, 스킬 없이, 스킬 적용, 사전 탐지기(?) 제외)으로 만들어 순위 평가. 초안이 최하위였지만 스킬 적용본과 스킬 없이 고친 글의 평균 순위가 거의 같음
원인과 대응: 다듬기 규칙 28개에 걸린 곳을 전부 고쳐 문장이 짧고 딱딱해짐. 지침 첫 줄을 "목표는 읽기 좋은 글이다"로 바꾸고, 보조 AI들의 수정안 중 메인 AI가 골라 반영하며, 작성자에게 물을 내용은 확인 항목으로 남기게 함

차이는 고친 글을 원고와 나란히 놓았을 때 드러났습니다. 같은 원고를 스킬 없이 2가지 방식, 스킬로 1가지 방식으로 5번씩 고치게 한 결과입니다.

확인 항목	스킬 없이	스킬 적용
초안 5편의 비유 96개	절반 넘게 사라짐	10개 중 8개 남김
남길 곳(비유, 인용)	20% 안팎만 남음	모두 남김
확인할 곳(모호한 문장)	작성자에게 한 번도 묻지 않음	5번 모두 작성자 확인 필요 항목에 올림
원고에 없는 숫자	10번 중 6번 지어냄	언급 없음

요즘 모델은 프롬프트 한 줄로도 잘 고치지만 고치면 안 되는 곳은 혼자 지키지 못하므로, 스킬을 만들 때 지킬 곳의 정답표도 함께 준비하기를 권했습니다.

3부: 코드, 사람, LLM 협업

우아한테크코스 8년 경험을 200~300페이지 책으로 묶으며 AI를 썼는데, 같은 시나 산문도 AI가 썼다고 알리면 7점 척도에서 평균 0.8~1점 떨어진다는 연구가 있습니다. 그래서 인지심리학이 글쓰기에서 보는 세 가지 테스트를 기준으로 코드, 사람, LLM의 협업을 실험했습니다.

테스트	내용	맡은 협업
Thinking 테스트	처음 쓸 때의 생각. 문장이 엉성해도 생각이 좋으면 읽고 싶어짐. 가장 중요	사람과 LLM
Language 테스트(?)	생각을 적절한 어휘로 표현하는 능력. 공개된 글쓰기 스킬 대부분이 집중하는 영역	코드와 LLM
Memory 테스트	저자의 경험을 생각과 표현에 연결하는 능력

코드와 LLM: LLM은 결과가 매번 다르고 긴 글의 뒤쪽을 놓쳐서, 글자 수, 문장 수, 중복 표현, 거슬리는 키워드(리듬, 결)는 코드로 셈
교체 매핑: 노력이 드는 맥락의 '여정' → '과정', '시간', '노력'처럼 맥락별로 정해 책 원고의 100개 이상 표현을 30초~1분 만에 교체
eval 테스트 코드: Anthropic 문서가 첫 단계로 꼽는 명확한 성공 기준을 검증하고 유지할 표현도 지정. 어떤 어휘가 AI 냄새인지는 사람이 판단
사람과 LLM: 어원, 장면 묘사, 비유, 질문으로 생각을 전개. LLM이 서구권 콘텐츠를 많이 학습해 한자 어원 풀이에서 사람 냄새가 나는 경우가 많음(예: '학습'을 學과 習으로 풀어 미션 중심 학습 설명). 표현은 공통 스킬, 장별 의도와 생각 전개는 장마다 만드는 일회용 스킬로 분리
평가 척도: 2(원하는 수준), 1(애매함), 0(탈락). 5점 척도는 날마다, 모델마다 결과가 달라 줄임
합성 독자(LLM과 LLM): Hugging Face에 NVIDIA가 공개한 한국인 페르소나 데이터셋(Nemotron-Personas-Korea, 통계청 기반 100만 명, 관계별 700만 개 이상)에서 독자를 골라 인터뷰하듯 피드백 수집. 그냥 LLM에 요청할 때보다 나은 결과

AI 티 줄이는 팁

초안은 먼저 말로 쓰고, 검수는 그다음에 합니다. 이 순서로 쓰면 AI 티가 덜 납니다.

임동준 님이 마지막으로 공유한 방법입니다. 타이핑으로 쓰면 눈에 보이는 표현과 문장을 따라 쓰게 되는 경우가 많습니다. 말로 쓰면 입력부터 자기 어휘와 표현, 생각하는 방식이 담기고, 말하면서 Thinking 테스트도 깊어집니다. 쓴 글을 소리 내어 읽어 보면 맞는지 아닌지도 바로 판단할 수 있다고 합니다.

원고와 테크니컬 라이팅 스킬은 기술 블로그로 공개할 예정이고, 우아한테크코스 홈페이지에서도 관련 원고를 볼 수 있다고 안내했습니다.

참고 링크

Hugging Face: 공개된 AI 모델과 데이터셋을 찾아보고 직접 실행해 볼 수 있는 플랫폼