팀에 합류한 초반에도 그랬지만 유난히 근 한 달간 내가 있는 조직의 문서화에 고민이 많았다. 개인적으론 우리 문서 품질이나 관리면에 아쉬운 점이 많아서 테크니컬 라이팅(이하 TW)에 관심을 갖다가, 테크니컬 라이터들 또는 그런 업무를 하는 사람들의 모임이 있길래 슬쩍 참석해봤다.
나는 모임에 가기 전 이런 고민이 있었다.
- 개발 가이드 문서는 얼마나 자세히 작성해야하는가?
- 문서 최신화는 얼마나 자주하는게 좋은가?
- 문서 스타일은 어떻게 정하는 건가?
- 나아가 TW의 전문가들은 과연 어떤 고민을 하는가? 발전된 AI에 의해 직업이 위협받는다는 생각도 할까?
밋업은 2개 세션 진행 후 Q&A겸 네트워킹으로 진행됐다.
1. AI 시대에 더욱 중요해지는 글쓰기
이 세션의 발표자는 개발자, 테크니컬라이터를 오가며 sw분야의 문서 라이팅 경력을 쌓은 분이셨다.
이 세션에선 LLM과 RAG얘기가 많이 나온다.
LLM - 대규모 언어 모델
RAG - 검색 증강 생성. 그냥 LLM을 보완(사용자 입력이 들어오면 외부 문서를 검색해 모델에 더 풍부한 데이터를 학습시킴)해 더 좋은 결과를 내는 하나의 패러다임이라 이해하면 될 것 같다.
아래 아키텍처를 보면 1,2,3번에서 외부 자료를 검색해오고 4번에서 LLM에 유저의 입력+외부자료를 같이 인풋으로 넣는다. 그리고 5번에서 LLM이 외부자료에 의해 더 향상된 대답을 도출한다~는 식이다.
이런 내용을 얘기했다.
- RAG는 언어모델 보완해줌.
- 대신 맞지 않는 답을 맞는 것처럼 답(할루시네이션 현상)하지 않도록 검색 최적화가 필수임 -> 데이터 가공, 분류가 잘 돼있어야됨
- 즉, 기존 글쓰기(사람에게 보여줌)과 다르게 AI가 분류를 잘 할 수 있는 TW가 필요함 짚어주심
- TW시 언어모델이 정보의 타당성을 판단할 순 없으므로 이를 잘 구성해 제공하는 것에 집중해보자.
- 결국 우리가 쓴 컨텐츠를 언어모델이 학습해 검색에 제공됨
- RAG의 성능 = 컨텐츠의 품질 (이걸 어떻게 지키는진 추가자료 제공해주실 예정)
- 제대로 글쓰기 하지 않으면?
- 문서 모순 생김 (결과 정확도 하락)
- 사람 & LM 모두 만족시킬 수 있는 글쓰기?
- 두 벌의 문서를 만들기보단 고품질의 완전한 문서 만들자.
- 그러려면?
- 명확성, 정확성
- 구조화된 데이터 - 표, 리스트, 소제목 … (LM도 이렇게 해주면 정보를 더 수월하게 추출함. 사람&LM 둘 다 '패턴'을 파악했을 떄 효율적인 파악이 가능함)
- 맥락, 배경정보 제공
- 문서 최신화
- 개발자 시절 경험 공유: 기획초기부터 참여해 용어정리, 스타일가이드 정립 -> 문서가 코드를 나타낼 정도로 정리하심
- AI끼리의 훈련 효과?
- 에코 챔버, 오버 피팅 현상 -> 결국 사람이 있어야 보정이 가능
- RAG실제로 구현하거나 접하는 방법?
- 개발자들 힘을 빌리기
- 노션 Q&A기능 소개해주심 (기능: 질문 시 문서 기반 답변을 줌. 노션 쓰고있지 않을때도 사용가능. 문서 보안을 고려해 답변 가능.)
- 글쓰기의 확장은 어디로?
- 프롬프트 엔지니어링(=디자인)
- 문장을 어떻게 논리적으로 쓸 것인지의 관점에서 ‘엔지니어링’이라고 함
- AI가 더 잘 이해할 수 있는 문장 템플릿 = 프로그램처럼 볼 수 있음
- 상품화(ex. 브라우저 GenAI 플러그인)
- 마무리
- AI의 답변은 결국 사람의 입력에 의존함. 곧 입력으로 제공하고자 하는 문서 품질이 중요함
- RAG가 성공적으로 구현되려면 검색 최적화가 필수적이라고 볼 수 있음. (글쓰기에 들인 공이 날이 갈 수록 중요해질 것이다~)
테크니컬 라이터는 발전된 AI에 회의적이고 반감가지지 않을까? 싶었는데 의외로 그 반대였다.
오히려 AI를 잘 활용해 문서 품질을 높이고, 문서 검색의 정확도가 중요한 이 직군엔 RAG검색이 그걸 도와주고 반대로도 좋은 품질의 문서를 통해 RAG최적화를 도모하고 있었다!
RAG의 성공적인 구현이 곧 TW스킬에 의존한다는 것이란 시각이 흥미로웠고,
이 세션 전엔 조직에서 그냥 돈 써서 RAG 도입하면 실무자가 문서 찾고 읽는데 드는 피로감 줄어드는거 아닌가?싶었는데 결국 잘 짜여진 컨텐츠가 아니면 지속적인 좋은 효과를 내긴 어렵겠단 생각이 들었다.
이걸로 내가 TW를 좀 자세히 들여다보는게 헛짓거리(?)가 아니겠단 생각도 들었다ㅋ;
2. 글로벌 스타일 가이드
이 세션의 발표자는 거의 1세대 테크니컬 라이터셨다. 여러 국가에서 제품 가이드 문서를 만들면서 정리해온 글로벌 스타일 가이드에 대해 얘기해주셨다. (근무하시는 기업, '다온'의 TW 블로그: https://blog.naver.com/alldaon2024)
기본 글로벌 스타일, Plain Writing 스타일에대해 소개해주셨는데(아래 내용은 소개 중 일부임) 개인적으론 구두법이 제일 골 때렸다.
기본 글로벌 스타일:
- 폰트: 고딕체가 대세임(심미성)
- 이탤릭체: 책 제목, placeholder 표현
- 제목에 Installing -> Install로 변경함(지시어로 써야 직관적임)
- 약어의 대소문자: 예전->PMP, 현재-> portable media player(대문자가 전문성을 확실히 표현하지 못한다고 생각해서 ㅋㅋ) / - - Monospace - 예제 코드 의미
- 구두법:
- 영국식: ‘A', ’B’ and ’C’. -> 따옴표, 쉼표/온점 위치
- 미국식: “A," ”B,” and “C.” -> 쌍따옴표, 쉼표/온점 위치
- 한국식: ‘A', ’B’ 및 ‘C.’ -> 영국식인데 온점위치만 미국식
- 2인칭 현재시제/능동태 씀: When you click A, B appears (B will appear이라고 안 함)
- 대표 복수(성차별): A man ~~ click his/her ~~~ -> People ~~
- SI 표기규정도 국문에 그대로 적용됨 (물질의 단위표현, 숫자 표현 등)
Plain Writing 스타일
- 굳이 어려운 말&화려하기만 한 긴 문장으로 표현 X -> 쉬운 말, 잘 구조화된 문장을 쓴다.
- 부정적인 용어 X -> 가능한 쪽을 부각시킨다.
- TW is a writing of ... -> TW writes ... 식으로 동사 중심으로 줄여 말해라
TW의 글로벌 버전은 생각치 못했는데 덕분에 지금껏 그냥 지나쳤던 서식들에 어떤 약속이 있었는지 알게됐다.
그 외 Q&A에서..
- sw개발 시 용어 정리, 문서를 코드화가능 수준까지 정리하는 시점은 언제? 최소한 기획이 정립된 후를 추천.
- 어떤 조직의 경우 피쳐컴플릿(기능 개발을 완전히 종료하는 시점)이 있어서 그 이후에 문서화를 진행함.
- 사내용 GenAI를 직접 만들 경우 필요한 권한이 있는 문서에 접근해 훈련은 가능함. 이 때, AI에 미리 구체적인 페르소나를 부여(=맥락 설명의 효과) 해줄 경우 더 정확한 정보를 뽑아내주기도 함.
- 테크니컬 라이터 간 협업 시 피어 리뷰는 많이 할 수록 좋음. 스타일 가이드가 있어도 늘려나가고 수정하는게 중요함. 한번 하는 건 어렵지만 하고나면 수월해짐
- 일관성있는 글쓰기의 구체적인 방법? 용어집 정의하기. 스타일 가이드 정의하기. (시간이 지나면 가이드도 업데이트할 순 있으나 글쓰기 스타일을 미리 약속한다는 포인트가 중요한 듯)
마무리
TW의 기본을 살짝 엿봤는데 정말 별걸 다 정하는구나.. 공이 많이 들겠구나, 하지만 그만큼 항상 일관성있는&잘 조직된 문서가 나오겠구나 싶었다. 우리 팀은 이렇게 세밀하게까진 아니더라도 문서 찾고 읽는데 피로감이 줄 정도는 됐음 좋겠단 생각이 들었고,
그 외엔 실무자들이 전해주는 팁들, TW의 커리어에 관한 얘기들이 재밌었다.
다만, 가이드 문서를 얼마나 자세히 작성해야하는지, 얼마나 자주 최신화해야하는지는 조직내에서 협의하기 나름인 것 같다. (애자일 방법론에 따르는 조직이더라도 조직 별 스프린트 주기는 다를테니 문서 관리 시점도 다를 것이기때문)
스타일을 어떻게 맞춰야하는지는 '다들 많이 쓰는' 스타일 가이드(ex. 구글, ms 문서 가이드)를 차용해 써보고 조직에 맞게 계속 바꿔나가는 작업이 필요할 것 같다.
테크니컬 라이팅 정보를 얻었던 카페: https://cafe.naver.com/tcnkorea
TCN - Technical Comm... : 네이버 카페
Technical Communicator Network - TCN 공식 커뮤니티입니다.
cafe.naver.com
댓글