12월 2일
AWS 클라우드 리드 블로거 윤석찬 님의 페이스북 게시물입니다.
두 번째 게시물부터 읽어서 몰랐는데, 약간 연재물 느낌이네요. 지난 11월 23일에 첫 번째 글이 올라오고 27일에 두 번째 글이 공개됐습니. 작은 규모의 조직에서는 블로그 게시물을 혼자 쓰고 혼자 검수하고 혼자 발행하는데, 좀 더 체계적이고 큰 조직에서는 어떻게 활용하는지 엿볼 수 있는 글입니다.
(업데이트) 윤석찬 님 블로그에 계속 업데이트되고 있네요. 여기에 추가로 모을 필요는 없을 것 같습니다 ~~
https://channy.creation.net/blog/1966
- 첫 번째 글
집에서 가끔 쫄면을 직접 해 먹고 있다. 면뿐만 아니라 양배추, 당근, 사과를 듬뿍 잘게 썰어서 넣고 양념장에 비비면 일품이다. 그런데, 다 먹고 나면 항상 후회되는 점이 있었다. 매번 맛있는 면을 먼저 먹다 보니, 마지막에 안 먹은 채소들이 남는다. 그래서, 언제부터 인가 면과 채소를 같은 비율로 의도적으로 먹기 시작했다. 그래야 마지막에 채소만 먹는 고역이 사라지기 때문이다.
운동, 업무, 인생에서도 마찬가지다. 좋아하는 것만 하다 보면, 귀찮고 하기 싫은 일은 계속 밀리게 된다. 누군가 "뭔 생각을 해. 그냥 해."라고 했던 것처럼... 곁들어지는 단순하고도 귀찮은 일을 미루지 않고 함께 해 내야만, 한 단계 성숙할 수 있다.
회사 공식 블로그 글 쓰기도 마찬가지다. 개인 블로그처럼 한번 쓰고 끝났다 하면 좋겠지만, 계속 담당자들의 피드백과 수정을 거듭하는 지난한 과정을 거친다. 그래야 좋은 글이 나온다. 글로벌 회사의 블로거가 된지 5년이다. 앞으로 그 이야기를 써 보려한다.
- 두 번째 글
회사 블로그 작가가 된지 5년이 되었다. 지금껏 200여 개를 넘게 썼다. 혼자 쓰는 게 아니라, 서비스팀에서 신규 기능 출시를 담당하는 제품 매니저, 제품 마케팅 매니저, 두서너 명의 소프트웨어 개발자 등 적어도 6명 이상과 두 달가량 협업한 결과물이다. 그냥 다른 회사 블로그처럼 해당 제품 매니저 (혹은 임원)이 쓰면 되지, 왜 굳이 이런 복잡한 과정을 거치는지 의문을 제기하는 사람도 많다.
뉴스 블로그 작가들은 제품 팀이 아니라 고객의 편에서 글을 쓴다. 200개가 넘는 모든 클라우드 서비스에 전문가는 없다. 우리는 초보자의 관점에서 출시될 기능을 먼저 써본 후, 있는 그대로 솔직 담백하게 소개한다. 신규 기능의 첫번째 사용자로서 독자들이 할 수 있는 것만, 군더더기 없이 꼭 필요한 정보만 알리기 위해 노력한다. 제품팀에서 주는 마케팅 미사어구를 배제하고, 실현되지 않은 미래의 약속들은 하지 않는다. 독자들에게는 솔직하고, 핵심적이면서도 짧은 글이 가장 강력하다.
역시 페이스북 글입니다. Angel Lounge 공동 창업자 황병선 님의 글인데요, "개발자 문서 전문가"라는 직업을 과거형을 써서 살짝 가져와보았습니다. 물론 어떻게 해야 살아남을지에 대한 이야기가 더 중요한 부분이긴 하지만, "있었는데"라는 과거형에 상처를 받아서 ^^
12월 8일
테크니컬 라이터 피넛버터 님의 브런치 연재글입니다. 오늘 첫 글이 올라왔습니다.
제목처럼 테크니컬 라이터에 대한 이야기를 나눌 예정이라고 합니다. IT 업계에서 12년간 기술지원, 테크니컬 라이터로 일했고 유학을 떠나 테크니컬 커뮤니케이션으로 대학원을 다닌 후 다시 한국에 돌아와 테크니컬 라이터로 일하고 있다고 합니다. 국내에서 정식으로 "테크니컬 커뮤니케이션"을 전공하고 테크니컬 라이터로 일하는 분이 많이 않아서 유익한 정보를 만날 수 있을 것 같네요.
(참고로 1화 배경 사진은 우크라이나 체르니우치 국립대학이라고 합니다. 테크니컬 커뮤니케이션 전공은 없는 학교이고, 유럽 대학 스톡 이미지로 많이 사용되는 이미지라고 하네요).
https://brunch.co.kr/brunchbook/technicalwriter
이전에는 "40대 엄마의 IT회사 재취업기"라는 제목으로 브런치 연재글을 올리기도 했습니다(닉네임으로 보면 같은 분이 아닐까 싶습니다).
https://brunch.co.kr/brunchbook/ineedtogetajob
역시 같은 아이디로 요즘 IT에 개발자 영어 관련된 콘텐츠를 연재하고 있네요.
https://yozm.wishket.com/magazine/@byteminds/
12월 9일
21 Lessons from 14 Years at Google
내용 중 글쓰기의 중요성에 대해 언급한 내용이 있어 가져와 보았습니다. 테크니컬 라이터가 문서를 작성하면서 기술의 공백을 찾을 수 있는 것은 테크니컬 라이터의 시야가 넓어서가 아니라 글쓰기의 특징이 그러하기 때문이 아닌가 싶기도 합니다. 글쓰기가 아니더라도 다른 동료(또는 AI)와의 대화를 통해서도 이런 능력을 발휘할 수 있구요. 면접 준비를 하면서 AI를 활용하는 것도 비슷한 맥락이 아닐까 싶네요.
https://news.hada.io/topic?id=24909
https://addyo.substack.com/p/21-lessons-from-14-years-at-google
(번역은 GeekNews가 잘 되어 있어서 가져왔습니다).
글쓰기는 명확성을 강제함. 무언가를 더 잘 학습하는 가장 빠른 방법은 가르치려 시도하는 것
- 글쓰기는 명확성을 강제하며, 개념을 다른 사람에게 설명할 때 - 문서, 발표, 코드 리뷰 코멘트, 심지어 AI와 채팅 - 자신의 이해에서 공백을 발견함
- 무언가를 다른 사람에게 읽기 가능하게 만드는 행위가 자신에게 더 읽기 가능하게 만듦
- 이는 외과의사가 되는 법을 가르쳐서 배운다는 의미는 아니지만, 전제는 소프트웨어 엔지니어링 영역에서 대체로 참
- 이는 지식을 나누는 관대함만이 아니라 이기적인 학습 해크(hack) 이기도 함 - 무언가를 이해한다고 생각하면 간단히 설명을 시도하고, 막히는 곳이 이해가 얕은 곳
- 가르치는 것은 자신의 정신 모델을 디버깅하는 것
12월 30일
토스페이먼츠의 Open API 생태계
Toss Makers Conference 25 발표를 바탕으로 재구성된 내용이라고 합니다.
https://toss.tech/article/payments-legacy-4
토스페이먼츠 테크니컬 라이터 Juyeon Han 님이 이 글을 다음과 같이 소개하고 있습니다. "문서를 제품으로 바라보고"라는 표현이 인상적이어서 기록으로 남겨봅니다.
이 글에 담긴 개발자 경험(DX)의 대부분—연동 문서, 샌드박스, API 로그 조회—은 문서를 제품으로 바라보고 FE 개발자, 디자이너, 테크니컬 라이터가 모여 DX 팀을 구성해 만든 결과물이에요. 특히, 가맹점 개발자 경험의 수호자로 테크니컬 라이터들이 PM 역할을 하며 주도적으로 만들어온 것들입니다.
