# AI 때문에 테크니컬 라이터를 해고하거나 채용하지 않은 사람들에게 > Clean Markdown view of GeekNews topic #25880. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25880](https://news.hada.io/topic?id=25880) - GeekNews Markdown: [https://news.hada.io/topic/25880.md](https://news.hada.io/topic/25880.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-17T01:33:12+09:00 - Updated: 2026-01-17T01:33:12+09:00 - Original source: [passo.uno](https://passo.uno/letter-those-who-fired-tech-writers-ai/) - Points: 4 - Comments: 2 ## Topic Body - "AI가 인간 **기술 문서 작성자**를 대체할 수 있다는 믿음"으로 채용을 중단하거나 해고한 결정이 **심각한 실수**임을 경고 - **AI가 생성한 문서**는 지능이나 공감 능력이 없으며, **제품의 진실과 맥락을 담지 못하는 빈 껍데기**에 불과함 - 기술 문서 작성자는 **사용자 공감, 정보 수집, 명확한 전달**을 통해 제품을 이해 가능하게 만드는 핵심 인력임 - **AI 보조 도구와 정책을 결합한 ‘증강된 기술 문서 작성’** 이 생산성을 높이는 현실적 대안 - **AI는 소음을 만들지만, 인간은 신호를 만든다** - 기술 문서 작성자의 복귀와 재고용을 촉구함 --- ### 기술 문서 작성자를 대체한 AI 의존의 문제 - AI로 인해 기술 문서 작성자(Technical Writer)를 해고하거나 채용하지 않은 결정은 **큰 실수**임 - AI가 작성한 문서에만 의존하면 **전문가의 감독과 맥락 이해가 결여된 결과물**이 됨 - 개발자에게 문서 작성 부담을 전가하는 것은 **문서의 본질을 오해한 행위** - 기술 문서는 단순한 산출물이 아니라 **제품의 진실(product truth)** 을 담는 핵심 구성 요소 - 소프트웨어는 완성되지 않았고, 자명하지 않으며, 단순하지 않기 때문에 **문서 없이는 사용 불가** - 기술 문서 작성자는 **정보 수집, 명확한 표현, 사용자 중심의 서술**을 통해 제품을 연결함 ### AI 생성 문서의 한계 - AI가 생성한 문서는 **지능이 없고 비전이 결여**되어 있음 - 수백만 토큰을 학습해도 **문서 전략 수립, 구조화, 재사용 설계**를 수행할 수 없음 - **예외 상황, 미묘한 경계, 미완성의 긴장감**을 포착하지 못해 내용이 공허함 - **법적 책임**은 AI가 아닌 인간에게 남음 - 잘못된 지침으로 피해가 발생하면 **책임은 관리자나 기업에 귀속** - AI 모델은 해고하거나 법정에 세울 수 없으며, **책임 회피가 불가능** - AI가 문서를 생성하려면 **기존의 고품질 맥락(context)** 이 필요함 - RAG, Cursor 규칙, Claude Skills 등은 모두 **기술 문서 작성의 연장선** - 문서 작성자를 해고하면 **AI가 학습할 기반 데이터 자체가 사라짐** ### 기술 문서 작성자와 AI의 협업 가능성 - **AI 도구와 교육을 제공**하면 기술 문서 작성자의 생산성이 크게 향상됨 - AI 정책을 통해 품질을 보호하면서 **AI와 협업하는 미래형 문서 작성 환경** 구축 가능 - 이미 일부 기술 문서 작성자들이 **AI를 활용해 작성·편집·출판을 자동화**하는 사례 존재 - **AWS CEO Matt Garman**도 인간을 대체하기보다 **보조하는 방향의 생산성 향상**을 인정 - [본인도 AI를 적극 활용](https://passo.uno/ai-tech-writer-examples/)하고 있으며, 여러 기술 문서 작성자들이 AI를 활용한 **문서 자동화 도구 개발**에 참여 중 : [톰 존슨](https://idratherbewriting.com/) , [CT 스미스](https://docsgoblin.com/) , [사라 디튼](https://sdeaton.com/) - 기업은 기술 문서 작성자와 함께 **AI 전략을 수립하고 실험할 시간과 자원**을 제공해야 함 - 기술 문서 작성자는 **제한된 자원으로 효율을 극대화하는 능력**을 이미 보유 - 적절한 도구와 기회를 주면 **AI를 문서 품질 향상에 활용**할 수 있음 ### 재고용과 인식 전환의 요청 - AI가 인간의 역할을 완전히 대체했다는 **잘못된 전제**를 버려야 함 - 기술 문서 작성은 단순한 단어 조합이 아니라 **전문가 인터뷰, 제품 이해, 맥락 해석**을 포함 - 기술 문서 작성자는 **사치가 아닌 필수 인력**으로, 제품을 **사용 가능하게 만드는 번역자** 역할 수행 - 그들이 없으면 제품은 **자기 자신을 설명하지 못하거나 거짓된 정보**를 전달 - **AI는 무한한 소음을 만들지만, 인간은 의미 있는 신호를 만든다**는 결론으로 마무리 - 해고된 Technical Writer를 **다시 불러들이고, 함께 일할 것을 촉구**함 ## Comments ### Comment 49477 - Author: coremaker - Created: 2026-01-19T15:37:02+09:00 - Points: 1 AI 냐 사람이냐 문제가 아니라, "사용자 공감, 정보 수집, 명확한 전달" 을 할 수 있냐 없냐가 관건 이겠네요. ### Comment 49359 - Author: neo - Created: 2026-01-17T01:33:12+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46629474) - 나는 전문적으로 **문서 작성**을 하는 사람임 하지만 실제 내 일은 관찰하고, 듣고, 이해하는 것임 독자의 **불안과 혼란**을 깊이 이해해야 좋은 글을 쓸 수 있음 외국의 대중교통 시스템을 경험할 때마다 지역 교통 안내서를 수정함 독자의 입장에서 혼란을 직접 체험하며 글을 개선함 공감이 내 일을 움직이는 엔진임 수년간 사람들과의 신뢰 관계를 통해 정보를 모으는 **인프라**를 구축했음 AI는 이미 기록된 것만 다루지만, 나는 직접 세상에 나가 질문함 이민청 경험을 수집하는 도구를 만들고, 변호사와 전문가 수백 명을 인터뷰했음 AI는 데이터에 의존하지만, 나는 내 데이터를 직접 사냥함 AI가 이런 일을 대신할 수 있다고 믿는 건 직업에 대한 모욕적인 오해임 - 요즘은 많은 산업이 **독점화**되어 있어서 품질이 중요하지 않게 됨 대중교통 문서가 형편없어져도 수익이 바로 줄진 않음 하지만 기술 작가를 해고하면 예산은 즉시 줄어듦 소프트웨어도 마찬가지임 — 진입 장벽이 높아 “이건 별로야, 내가 더 나은 걸 만들겠어”라고 말하기 어려움 - 코딩도 똑같음 코드는 컴퓨터가 읽는 **문서**임 컴퓨터는 상식이 없으니 모든 이해는 프로그래머에게 달려 있음 LLM이 문법적으로 맞는 문장을 만든다고 해서 좋은 문서를 쓰는 건 아님 마찬가지로, 컴파일되는 코드를 만든다고 해서 사용자가 원하는 프로그램을 만드는 건 아님 - 이 말에 완전히 공감함 나는 “**기술에는 영혼이 필요함**”이라는 표현으로 같은 생각을 전함 기술 문서, UI, 제품 모두 인간적인 감각이 스며들어야 가치가 생김 - 당신의 글은 AI가 흉내 내려 하지만 결코 닿지 못하는 **명료한 표현력**을 보여줌 AI가 사람을 대체하려는 야망은 모욕적임 우리는 모든 걸 기록하지 않음 — 상식적인 것일수록 기록되지 않지만, AI에겐 그런 데이터가 꼭 필요함 - 잘 쓴 글에 감사함. 그게 바로 요점이기도 함 - 나는 기술 작가들을 해고한 회사의 직원은 아니지만, 우리 회사도 같은 일을 겪었음 작가들이 AI에 의존하다 보니 결과가 **끔찍**했고, 스스로는 거의 쓸 수 없었음 시장에서 좋은 기술 작가를 찾기 어렵고, 포트폴리오가 좋아도 실제로는 형편없는 경우가 많음 결국 개발자에게 문서를 맡기게 됨 — 하지만 개발자는 그걸 경력에 넣기 싫어함 반쯤이라도 괜찮은 작가를 해고하면 사업을 망치는 일임 AI는 README나 config처럼 **패턴이 일정한 데이터**에는 강하지만, 제품 문서처럼 고유한 콘텐츠에는 약함 - AI가 잘하는 문서는 있음 — 아무도 읽지 않는, 단지 **컴플라이언스용** 문서임 이런 문서들은 CPU 같은 기본 용어만 정의하고, 정작 중요한 도메인 용어는 빠져 있음 접근할 수 없는 문서 참조, 코드와 안 맞는 UML, 오래된 서명, 제각각의 스크린샷 등으로 가득함 형식도 제멋대로라서, 이런 문서는 우울한 QA 매니저 외엔 아무도 안 읽음 - 나는 LLM으로 README를 생성하게 했는데, 보기 좋고 읽기 쉬움 대신 **구체적인 예시**를 많이 넣어주면 AI가 더 잘 도와줌 - 그래도 이런 문서는 다른 LLM들이 읽음 /s - 최고의 기술 작가는 단순히 제품을 문서화하지 않음 실제 사용자처럼 행동하며 **사용성 문제**를 찾아냄 엔지니어와 1:1 인터뷰로 필요한 정보를 끌어내는 능력이 있음 AI는 이런 역할을 잘 수행하지 못함 - 이런 피드백은 팀 전체가 참여해야 함 내부에서도 처음 보는 콘텐츠에 대한 **첫인상 피드백**이 매우 중요함 하지만 많은 조직은 부서 간 피드백 문화를 막음 그 결과, 마케팅용 기술 콘텐츠가 모호하고 의미 없는 경우가 많음 - AI가 최고 수준의 작가를 대체하긴 어렵지만, **평균 이하의 작가**보다는 나을 수 있음 많은 프로젝트가 문서가 없거나 엉망이기 때문임 - 훌륭한 기술 작가는 조용히 **사용성 레이더**처럼 작동함 복잡한 워크플로를 가장 먼저 문제로 인식함 - 물론 이런 문제를 기술 작가가 발견한다면, **PM은 뭘 하고 있었나** 하는 의문도 생김 - 기술 작가는 QA나 PM과 역할이 겹치기도 함 종종 Python 같은 언어를 다룰 줄 아는 기술적 감각도 있음 - AI가 기술 작가를 대체할 수는 있겠지만, **좋은 대체재**는 아님 최고의 문서를 가진 회사는 여전히 인간 작가를 둘 것임 많은 사람이 “누구나 글을 쓸 수 있다”고 착각하지만, 실제로는 그렇지 않음 (관련 글: [Nobody Can Write](https://deborahwrites.com/blog/nobody-can-write/)) 기술 작가는 UX와 테스트에도 기여하며, API 명명 규칙의 불일치도 가장 먼저 발견함 AI는 보조 도구로는 쓸 만하지만, **편집 없이 그대로 내보내는 건 위험함** - 품질이 중요하지 않은 시장에서는 AI 대체가 더 빨리 일어남 관련 논의는 [이 댓글](https://news.ycombinator.com/item?id=46631038) 참고 - “좋은 문서? 미안하지만 내가 줄 수 있는 건 ‘쓸모는 조금 있는 수준’뿐임”이라는 밈이 떠오름 - 그래도 완전히 **없는 문서보단 낫다**면, AI의 역할은 의미 있음 - 최고의 기술 작가는 **인류학자**처럼 제품팀, 엔지니어, 사용자 사이의 다리를 놓음 이런 관점 덕분에 제품 자체가 개선됨 - 나도 FAANG에서 일하지만, 요즘 기술 작가들이 해고되고 있음 개발자에게 문서 작성이 떠넘겨지고, “AI로 하라”는 지시만 남음 이게 과연 **약속된 미래**인지 의문임 - AI는 이미 존재하는 통찰을 **종합(synthesis)** 하는 데는 도움 되지만, 사람 사이의 문화적 간극을 감지하는 감각은 없음 - 나는 2026년에 글쓰기와 **커뮤니케이션 능력**을 더 키우려 함 이런 기술은 쉽게 대체되지 않음 스스로 익히면 사고방식이 바뀌고, 인생의 다른 영역에도 도움이 됨 인간의 **스킬 업그레이드**가 사라지는 게 진짜 손실임 - 맞음, 스스로 배우면 읽는 것도 덜 지루해짐 LLM의 **획일적인 문체**는 금방 질림 장기적으로 보면 속도 향상이 기술 저하를 상쇄하지 못할 수도 있음 - 처음엔 제목이 헷갈렸음 “AI를 사용하다 걸려서 해고된 작가에게 보내는 편지”인 줄 알았음 글 전체가 언어적으로 **모호**해서 오히려 인간 작가에 대한 신뢰가 줄었음 나도 영어문학과 CS를 전공했고, 박사과정 학생들에게 글쓰기를 가르쳤으며, 지금은 회사 문서를 직접 관리함 - 하지만 요즘 AI로 대체된다는 기사들이 워낙 많아서, 두 번째 해석(“AI로 교체된 작가에게”)이 더 자연스러움 - 보험회사를 보면 배울 점이 있음 그들은 AI로 **정당한 청구를 거절**할 이유를 찾음 법정에서는 “소프트웨어 버그”라며 책임을 회피함 이런 변명이 표준이 되지 않길 바람 - LLM이 앞으로 계속 **개선될 것**으로 기대해야 하는가? 많은 글이 현재의 한계를 영원한 것으로 전제함 발전 가능성을 무시하는 건 **근시안적**으로 느껴짐 - “누가 개선을 기대하느냐”는 질문이 더 중요함 기대 수준은 사람마다 다름 - LLM은 실제로 제품을 써보며 설명이 틀렸다는 걸 **깨닫지 못함**