3월 3일
사쿠라는 설명을 잘하고 싶어!
咲良は上手に説明したい！
아직 한국어 번역 일정은 없는 책입니다. 저도 에이전시 인스타에서 책 소개를 보고 알았거든요.
저자인 타키자와 시로(滝沢 志郎)의 이전 작품이 소설이길래, 소설가에게 의뢰해서 쓴 작품인가 했는데, 현직 테크니컬 라이터로 일하면서 이 책을 쓴 것이라고 합니다. 아직 따끈따끈한 책이라 리뷰는 많지 않습니다.
아래는 에이전시 책 소개입니다.
https://www.instagram.com/shinwon.agency/p/DVNErj7CetH/
...태풍으로 각 선로가 멈춰 혼란에 빠진 요코하마역. 승객 대응에 쫓기는 아르바이트 역무원 이시카와 사쿠라의 앞에 한 여성——아사쿠라 히비키가 나타난다. 아사쿠라의 매우 알아듣기 쉬운 설명을 듣고 승객들이 납득하는 모습에 충격을 받은 사쿠라는 아사쿠라처럼 '테크니컬 라이터(전자제품•정밀기기 등의 사용설명서를 작성하는 직업'가 되고자 그녀가 일하는 오래된 매뉴얼 제작사 FTC에 입사하는데...
출판 후 인터뷰 기사는 아래 링크를 참고해주세요.
https://www.gentosha.jp/article/28770/
좀 오래전 졸업한 대학 인터뷰 기사도 있네요.
https://www.toyo.ac.jp/link-toyo/culture/dreams-come-true
3월 6일
Announcing Write the Docs Berlin 2026
https://www.writethedocs.org/conf/berlin/2026/news/welcome/
WTD 포틀랜드와 베를린 컨퍼런스 일정이 확정되었습니다.
포틀랜드는 5월 3일부터 5일까지, 베를린은 9월 6일부터 8일까지입니다.
3월 9일
Women in Technical Communication
https://store.xmlpress.com/product/women-in-technical-communication/
https://www.amazon.in/Women-Technical-Communication-typewriters-touchscreens-ebook/dp/B0GR84F94M
예약 판매중인 책입니다. 정식 출간은 3월 30일입니다. 부제인 "From typewriters to touchscreens: a history by the women who did the work"에서 알 수 있는 것처럼 컴퓨터 시대 이전부터 현대에 이르기까지 테크니컬 커뮤니케이션 분야에 종사하거나 기여한 여성들의 이야기를 다룹니다. 인터뷰 형식인지 아니면 기고 형식인지는 애매하긴 하네요. xmlpress 사이트에서 "Contributors" 항목을 보면 어떤 인물들의 이야기를 다루는지 살펴볼 수 있습니다.
3월 11일
창의적 엔지니어를 위한 기술 문서 작성(Technical Writing) 과정(오프라인)
https://www.sw.or.kr/site/sw/edu/selectEduView.do?eduNo=2107
소프트웨어산업협회에서 진행하는 교육입니다. 찾아보니 이전에도 같은 제목으로 교육을 진행한 적이 있네요.
강사는 오병곤인데, "대한민국 개발자 희망보고서"를 쓴 작가와 같은 분인지는 모르겠습니다.
4월 9일~10일 교육이고, 송파 강의장에서 진행합니다.
3월 12일
Technical writing interview assignments
https://www.reddit.com/r/technicalwriting/comments/1rpziiw/technical_writing_interview_assignments
국내에서는 간혹 테크니컬 라이팅 직무 지원 시 과제를 주는 곳이 있습니다. 과제의 목적은 완성도 있는 문서가 아니라 주어진 조건에서 어떤 고민을 했고, 어떤 과정을 통해 문서를 작성했냐는 것입니다. 제대로 된 기업이라면 인터뷰 시 과제에 대해 그런 것들을 물어볼 겁니다.
간혹, 이런 목적 이외에 프로젝트 수준의 과제를 제시하는 곳이 있습니다. 외국에서는 별도의 과제 비용이 지불되는 것이 아니라면 그런 과제 자체가 문제가 있다는 인식이 있습니다. 국내는 테크니컬 라이팅 직무 관련해서는 그런 곳은 보지 못했지만, POC 단계에서 제품 수준의 결과물을 원하는 곳이 있긴 하더군요.
래딧 게시물 답변 중에도 비슷한 내용이 있어 공유해 봅니다. 여기는 항공우주 분야라 설계도를 제시하고 문서를 작성하는 과제를 인터뷰 시에 30분 정도 라이브로 진행하고 결과물을 가지고 이야기한다고 합니다.
...we do one in person. We provide some made up engineering drawings/schematics and have a prompt. We give about 30 minutes.
The goal of that isn't really to get a polished item. Its to sit down with the person and go over why did they do x, y, z. We are looking at the thought process involved. The other thing we do is ask if you had more time, what kinds of things would you have done differently. Again, just to see what the person was thinking.
We do ask for a writing sample prior to the in person. We limit it to 30 minutes and its on a topic thats obviously not related to our actual business.
To answer your question, I am fine with writing samples, however, they have to be reasonable. If it looks like its something that is applicable for the business (happened a couple times) or ins unreasonable, I just respond that I am withdrawing...
개발자가 블로그도 잘 써야 하나요?
출간 일정은 아직 미정이고 베타 리더를 모집하고 있습니다. 원서는 "Writing for Developers: Blogs that get read", 2025년 1월에 출간된 책입니다. 저도 아직 읽어보지는 않았는데, 시간이 되면 빠르게 읽어보고 리뷰해 보도록 하겠습니다.
3월 20일
Snowflake docs team
I have heard that Snowflake's entire doc team has been laid off. Is that true?
https://www.reddit.com/r/technicalwriting/comments/1rxdqyo/snowflake_docs_team/
사실이라고 합니다. 링크드인을 통해 해당 팀에 속했던 이들이 글을 남겼고, 뉴스 채널에서 회사 측에 공식적으로 확인했다고 하네요.
https://www.businessinsider.com/snowflake-layoffs-strategy-ai-growth-2026-3
State of Docs Report 2026
https://www.stateofdocs.com/2026/introduction-and-demographics
작년(2025년)과 비교했을 때 차이가 있는 부분은 AI 관련 항목들입니다. 점점 더 많은 AI 도구를 사용하고 독자 역시 문서 자체를 읽기보다는 AI 도구를 통한 접근이 늘어나고 있습니다. 아직은 여전히 긍정적인 희망을 가지고 있는 이들이 많지만 내년에도 이 리포트를 볼 수 있을지 슬슬 불안해지긴 합니다.
긍정적인(?) 이유 중 하나는 명확한 가이드라인 없이 AI 도구를 적용하고 있으며 그로 인해 부정확한 정보가 활용되고 있다는 이야기입니다. 물론, 이런 형태는 기술이 보편화되면 충분히 개선될 수 있는 부분이긴 합니다.
...하지만 도입 속도가 관리 체계를 앞지르고 있으며, 이러한 격차는 중요합니다. 대부분의 팀은 가이드라인 없이 AI를 사용하고 있으며, 문서화는 대부분의 콘텐츠보다 훨씬 높은 정확도를 요구합니다. 결국, 잘못된 지침 하나만으로도 사용자의 구현이 실패하고 제품에 대한 신뢰가 무너질 수 있기 때문입니다...
실제 글쓰기에는 AI의 도움을 적게 받는다고 응답하긴 했는데, 응답자 스스로 정보를 숨겼을 가능성도 있습니다. 물론, 언급한 것처럼 글쓰기 이전에 자료 수집이나 검증에서 많은 도움을 받는 건 사실이긴 합니다.
...문서 작성의 병목 현상은 실제로 글쓰기 자체에 있는 것이 아니었습니다. 항상 정보 수집, 변경 사항 감지, 검증 등 초안이 작성되기 전후에 이루어져야 하는 모든 과정에 병목 현상이 있었습니다.
이 섹션의 실무자들이 활용하는 부분은 바로 이것입니다. 작가가 질문하기 전에 필요한 정보를 미리 제시해 주는 에이전트, 출시 전에 오류를 잡아내는 QA 루프, 그리고 그렇지 않았다면 며칠씩 걸렸을 일괄 처리 기능 등이 그것입니다. 하지만 정작 글쓰기 자체는 AI의 도움을 가장 적게 받는 부분입니다. 기술 문서 작성자는 다른 직종에 비해 시간 절약 효과가 가장 적다고 보고하는데, 이는 숙련된 작가들은 이미 글쓰기 속도가 빠르기 때문입니다...
소설이나 문학작품이 아닌 설명문을 굳이 AI로 만들 필요를 느끼지 못한다
살짝 잘못 읽으면 AI가 설명문을 만드는 능력이 부족하다고 오해할 수 있는데, 사용자가 정보를 획득하는 채널 자체가 문서에서 채팅창으로 변경되면서 굳이 문서 형태가 있을 필요가 없다는 이야기입니다.
3월 25일
Announcing Write the Docs Berlin 2026
https://www.writethedocs.org/conf/berlin/2026/
WTD 2026 베를린 일정이 확정됐습니다. 9월 6일부터 8일까지입니다. 가실 분들은 미리미리 계획을.
it’s over
https://www.reddit.com/r/technicalwriting/comments/1s1ox5e/its_over/
...제 동료 중에 코딩 실력이 정말 뛰어난 열정적인 사람이 있는데, 그 친구에게는 좋겠지만 우리 팀의 업무 기준을 너무 높게 잡고 있어요. 솔직히 말해서, 그 친구는 스트레스나 빠른 업무에 대한 부담 없이 테크니컬 라이팅 팀에서 소프트웨어 엔지니어처럼 일하고 싶어서 이 자리를 이용하는 것 같아요. 제가 면접 볼 때는 코드를 읽을 수만 있으면 되고, 직접 작성할 필요는 없었는데, 그는 계속 스크립트를 짜서 작업하고 있어요. 심지어 1년 전에는 릴리스 노트 작성까지 자동화해서 문서 작성자는 AI 출력물을 복사해서 수정하고 고객에게 보여주는 파일에 붙여넣기만 하면 돼요. 최근에 Claude 라이선스 사용 허가를 받았는데, 몇 달은 걸릴 줄 알았던 JIRA를 통해 기능을 문서화하는 기술까지 구현했네요… 그럼 제 역할은 뭐죠? ㅎㅎ...
좀 독특한 케이스인 것 같긴 합니다. 보통은 도큐먼트 엔지니어가 따로 있는데, 글쓴이의 팀에서는 코딩을 좋아하는 누군가가 있어서 자꾸 업무를 자동화하면서 압박을 한다는 느낌입니다. 하여간, 이런저런 자동화로 인해 업무가 줄어드는 것은 좋지만, 역할 자체가 줄어든다는 불안인 거죠. 아직은 AI가 뭔가 뚝딱 해결해 주는 것보다는 누군가 "정말 뛰어난" 사람이 있어야 가능한 작업이구요. 코드 작성 시부터 명세서 기반으로 작성이 된다면 개발자의 의도가 명세서에 드러나는 만큼 문서화 작업에서 테크니컬 라이터가 개발자의 의도를 추가적으로 찾아내야 하는 부담은 줄어들고 역할도 줄어들 수 있을 것 같긴 합니다.
3월 30일
문서쟁이의 클로드코드 실험실
https://brunch.co.kr/magazine/docswithclaude
테크니컬 라이터 피넛버터 님의 브런치 연재글입니다. 다양한 주제로 연재를 하고 있는데, 그 중 하나입니다.
3월 중순부터 글을 올리고 있구요. "현재 재직 중인 회사의 팀에서는 클로드 코드를 이제 막 도입해서 신나게 이리저리 써보는 중이다"라는 설명처럼 아마도 회사에서 지원해주는 계정(또는 개인 계정에 비용 지원)을 사용하는 듯합니다. 때문에 오, 이거 무료인가 하고 개인 계정으로 따라하다가는 큰 손실을 볼 수 있습니다. 환경이 된다면 따라가보시고, 아니면 대충 참고만~
