2026년 5월 2일에 『Agentic Coding: 생성 AI 시대의 시스템 개발 입문』이라는 단독 저서를 출간했습니다. 생성 AI × 시스템 개발 정보가 인터넷상에 단편적인 것들뿐이라 곤란해하는 분, 에이전트 사용법을 어디서부터 배워야 할지 모르는 분, 그리고 자신은 괜찮더라도 팀원에게 전달할 책이 없는 분들을 위한 책입니다.

본 기사는 그 홍보……가 아니라, 집필 중에 AI 에이전트를 어떻게 사용했고, 무엇을 버렸는지에 대한 이야기입니다. 결론부터 말씀드리면, 금방 쓸 수는 없었습니다. 아래 내용은 강연 자료에 내용을 추가한 것입니다.

집필 중, 필자는 계속 딜레마를 안고 있었습니다.

"AI에게 시스템 개발을 맡깁시다"라고 쓰고 있는 책의 원고를, AI에게 맡기지 않는다. 이 태도는 도리에 맞지 않습니다. 독자 입장에서는 "네가 직접 써라"라는 말로 끝나버릴 이야기일 것입니다.

한편으로는, LLM(Large Language Model)이 출력한 문장은 AI스러운 느낌이 들어 쓸모가 없다는 감각도 있었습니다. 개인적인 신념에 가깝습니다만, 그대로 책으로 만들 수는 없습니다.

그렇다면, 어디까지라면 맡길 수 있을까요. 모순을 안은 채로 그 선을 찾는 과정이 되었습니다.

해외판 유행어 대상 중 하나가 "슬롭(Slop, 오물)"으로 결정되었습니다. "AI 슬롭(AI Slop)"과 같이 사용되는 단어로, 압도적인 양에 비해 내용이 얕은 콘텐츠를 비꼬는 말입니다.

그렇다면, 문장에서의 AI Slop이란 구체적으로 무엇일까요. 필자는 세 가지 층위가 있다고 생각합니다.

첫 번째는 어휘입니다. "구조", "발판", "꽂히다", "효과적이다", "두다" 등의 빈출 단어와 em dash(—)가 대표적인 예로 꼽힙니다. 두 번째는 구문입니다. Markdown의 강조와, 콜론이 붙은 불렛 포인트(- hogehoge: fugafuga)가 잘 알려져 있습니다.

세 번째는 구성인데, 이것이 가장 까다롭습니다. 장·절에서 서브타이틀을 남용하는 습관, 뒷내용이 궁금해지는 어중간한 마무리(클리프행어), 작성자의 극론이나 경향에 대해 과도하게 조정을 가해버리는 바이아스(Bias)의 결여, 그리고 이전 이야기로부터 예상 가능한 지점에 깔끔하게 착지해 버리는 LLM의 예측 가능성이 이에 해당합니다.

어휘나 구문은 눈에 보이기 때문에 고칠 수 있습니다. 하지만 구성은 그렇게 쉽게 고칠 수 없습니다.

여기서 한 번 멈춰 설 필요가 있었습니다. 그 AI스러운 느낌을 지우려는 노력은 누구를 위한 것인가.

"품질 개선"인가, 아니면 "론더링(Laundering, 세탁)"인가. 왜 AI스러운 느낌을 지우고 싶은지 자문해 보니, "책임을 지기 위해서"라는 답과 "외주 흔적을 지우기 위해서"라는 답이 모두 나왔습니다.

후자라면 독자에게 불성실한 태도일 것입니다. 이 선긋기는 마지막까지 필자 안에서 풀리지 않았습니다. 다만, 적어도 "지우기만 하면 좋은 문장이 된다"는 것은 검증을 통해 알게 되었습니다.

세상에는 탈취(탈취/제거)를 위한 Skills가 있습니다.

blader/humanizer는 Wikipedia:Signs of AI writing에 기반하여, AI 출력에서 빈출되는 패턴을 33가지 관점에서 탐지하고 자연스러운 문장으로 수정하는 Skill입니다. k16shikano/japanese-tech-writing은 일본어 기술 문서를 쓰게 하거나 퇴고하게 하기 위한, 일본어 문장 규범 Skill입니다.

집필 중에는 자체적인 Skill·Command도 시험해 보았고, Linter도 시험해 보았습니다. textlint-rule-preset-ai-writing입니다.

결론적으로, Linter는 채택할 수 없었습니다.

"AI 문장의 특징"을 기계적으로 쳐내면, 인간다운 문장이 되는 것이 아니라, 단순히 다른 바이아스를 가진 문체가 됩니다. 예를 들어 한자의 닫힘/열림(간지) 통일이나, "것(もの, こと)"의 박멸 같은 것입니다. 안티 패턴을 기계적으로 첨삭한 결과, 오히려 단조로운 문장이 되어 버렸습니다.

애초에 LLM은 LLM 나름대로 인간다움(이라기보다 기계 번역스러움)을 고려하여 출력하고 있습니다. 즉, AI Slop의 특징을 전부 지우면 오히려 위화감이 커질 가능성이 있습니다. 슬랭을 너무 의식하면 오히려 말하기 어려워지는 것과 마찬가지입니다.

다음에 시도한 것이 유저 하네스(User Harness)의 개념으로 매핑하는 것입니다. 하네스란, 에이전트가 좋은 출력을 낼 수 있도록 정돈하는 입력과 평가의 메커니즘 일체를 가리키는 말입니다.

생성에 필요한 정보를 feedforward, 평가에 필요한 정보를 feedback이라고 한다면, 전자는 "자신의 흉내를 내게 하는 것", 후자는 "Skills를 통한 리뷰·수정"이 됩니다.

먼저 feedforward는 단순합니다.

문체나 구성은 @watany의 공개 기사나 강연 슬라이드를 읽고 이해하여, 참고하여 집필할 것

Qiita를 포함하여 공개 자료가 200개 정도 있으므로, Claude Code와 같은 Web search tool에 맡깁니다. 어떻게 모방할지에 대한 수단은 LLM 측에서 결정하게 합니다. 컨텍스트(Context)가 걱정된다면, 이해한 후에 조사 결과를 파일로 만들게 하고 /clear를 하면 끝납니다.

다음으로 피드백(Feedback)으로서, 리뷰 프롬프트를 새겨 넣었습니다.

오탈자·표기 오류·문법 오류가 있습니까?
이 <문장> <표현>을 간결하게 만들 대안을 생각해 주세요
앞뒤 장·절과 정합성이 맞지 않는 점을 지적해 주세요

이러한 프롬프트들을 하나의 스킬(Skills)로 뭉쳐 놓으면, 누락되는 부분이 생기는 것처럼 느껴집니다. 감각적인 이야기이므로 반만 믿고 들어주세요.

그렇다면 어떻게 되었을까요? 결과는, 비슷한 문체는 되지만, 좋은 문장은 되지 않는다였습니다.

이 결과가 가장 뼈아팠습니다. 문체의 모방은 성공했는데, 다시 읽어보니 재미가 없는 것입니다.

왜 비슷함에도 불구하고 좋지 않은 것일까요? 기술서의 문장에는 실용적으로 세 가지 층위가 있다고 필자는 생각하게 되었습니다 (어디까지나 개인적인 견해입니다).

첫 번째는 어휘입니다. 빈도가 높은 어휘, 혹은 잘 사용되지 않는 어휘가 여기에 해당합니다. 두 번째는 문장의 리듬으로, 한 문장의 길이, 구두점의 위치, 말의 완급을 가리킵니다. 세 번째는 문장의 골격으로, 무엇을 쓸 것인가, 무엇을 쓰지 않을 것인가, 어떤 순서로 이야기할 것인가입니다.

하네스(Harness)로 모방할 수 있었던 것은 주로 어휘였고, 리듬은 부분적이었으며, 골격에 이르러서는 거의 모방하지 못했습니다.

LLM에는 일단 있는 그대로 쓰게 합니다. GPT 5.6이나 Claude Fable 5의 프롬프트 가이드를 읽어보면, 지키게 할 절차를 줄이는 것이 베스트 프랙티스(Best Practice)로 권장되므로, 처음부터 제약을 두지 않는 편이 좋습니다.

금지하고 싶은 어휘는 리뷰를 통해 검출합니다. 다만, 기계적으로 깎아내면 문장도 기계적으로 변하기 때문에, 지적하는 수준에 머무는 것도 방법입니다. 참고로 "AI 같은 문장을 찾아줘"라는 지시는 무의미했습니다. 너무 추상적이어서 아무것도 나오지 않습니다.

리듬도 우선은 있는 그대로 쓰게 합니다. 그 후에 소리 내어 읽습니다.

묵독(Silent reading)도 괜찮지만, 작은 소리로라도 입 밖으로 내뱉는 것이 효과적입니다. 소리 내어 읽지 않고 반복해서 읽다 보면, 위화감이 마모되어 버리기 때문입니다. "나는 이런 표현을 쓰는가?", "이야기의 흐름에 위화감은 없었나?", "단어 선택은 타당한가?"라고 자문하며 읽습니다.

낭독은 LLM에 국한되지 않고, 아이디어가 막혔을 때 효과적입니다. 리듬 개선 계열의 스킬(Skill)도 있기는 하지만, LLM다움은 경감될지언정 위화감을 지울 수 없기 때문에 현재로서는 사용할 계획이 없습니다.

골격에 대한 접근은 대체로 두 가지 패턴이 있었습니다.

하나는, 컨셉을 전달하고 LLM에게 쓰게 한다 → "이런 게 내 문장일 리가 없잖아!" → 반발하는 대로 다시 쓴다 → LLM에게 고치게 한다 → "이런 게 내 문장일 리가 없잖아!" (이하 생략), 라는 반발 구동 방식입니다. 이 방법은 지칩니다.

다른 하나는, 일단 휘갈겨 쓴 메모 수준의 재료를 바탕으로 LLM이 초안을 작성하게 하고, 순서를 재배치하거나 과부족을 수정하는 과정을 사람과 LLM이 턴제(Turn-based)로 반복하는 방법입니다. 골격을 스스로 쥐고 진행하는 만큼, 이쪽이 소모가 적었습니다.

본서에는 에이전트(Cline)의 조작 모습을 실황 형식으로 화면 캡처와 함께 소개하는 파트가 있습니다. PART 3의 바이브 코딩(Vibe Coding, 자연어 지시만으로 만들어내는 개발 스타일)과, PART 5부터 PART 7의 에이전틱 코딩(Agentic Coding, 에이전트를 개발 공정에 편입시키는 진행 방식) 부근입니다.

여기서 캡처를 통해 문장을 생성시켜 보았는데, 꽤 혹독한 결과가 나왔습니다. 매 조작마다 캡처하는 것이 아니기 때문에, 중간이 비어 있는 부분에 대해 의도하지 않은 스토리를 창작해 버립니다. 다만, OCR적으로 캡처의 글자를 추출해 주는 것은 평범하게 편리했습니다.

이미지의 캡션(Caption)을 만들게 하는 것은 그럭저럭 괜찮은 결과였습니다. 이 역시 의도하지 않은 스토리를 창작한다는 점은 같지만, 설명을 한 줄로 요약하는 것이 의외로 어렵기 때문에, 적중률이 낮더라도 시도해 볼 가치는 있었습니다.

우선 대량의 문장을 출력하는 것과 서적으로서의 품질 사이에는 격차가 있습니다. 이 격차를 메울 은탄환(Silver bullet)은 찾을 수 없었습니다.

한편, LLM이 내놓은 표현이 더 나은 경우도 있습니다. 그럴 때는 솔직하게 채택합니다. 분하지만 말입니다.

또한, 문장을 수정하기 위한 어휘를 갖추고 있으면 LLM에게 지시하기 쉬워집니다. 예를 들어, 단어와 단어, 혹은 다른 품사 간의 자연스러운 조합을 가리키는 "연어(Collocation)"나, "왜냐하면 ~이기 때문이다"와 같이 대응하는 표현이 올바르게 조합되어 있는지를 보는 "호응(Correspondence)"입니다. 지적의 해상도가 높아집니다.

그리고 가장 큰 교훈은, 테크닉에 집착할 바에는 직접 손을 움직여 쓰거나, LLM 출력물을 통해 빠르게 실패 사례를 파악하는 편이 낫다는 것이었습니다. 프롬프트(Prompt)나 스킬(Skills)에 공을 들이기보다, Opus 4.6이나 Fable 같이 문장력이 높은 모델을 사용하는 것이 더 효과적입니다. 리뷰는 프롬프트를 세밀하게 나누어 적절히 실행하고, 결과는 이슈(issue) 등에 기록해 두도록 합시다.

AI 에이전트라도 기술서는 금방 쓸 수 없다. 이것이 필자의 결론입니다.

참고로 이 기사는 저의 문체를 증류(Distillation)한 Skills로 Opus 5에게 쓰게 하고, 제 책의 문체를 증류한 Skills를 사용하여 Fable로 수정한 것입니다. AI 같지 않나요? 에이전트에게 집필을 맡길 수 없다는 것은, 결국 바로 이런 의미입니다.