‘문서’로 세상에 도움을 주는 테크니컬 라이터, 강정일

네 번째 인터뷰는 LINE의 테크니컬 라이터 강정일 님과 함께했습니다. 

Q. 정일 님 반갑습니다. 간단한 자기소개 부탁드려요.

A. 안녕하세요. LINE에서 테크니컬 라이터로 일하고 있는 강정일입니다.

Q. 테크니컬 라이터라고 하면 조금 생소하게 느끼시는 분도 계실텐데요. 테크니컬 라이터는 어떤 일을 하나요?

A. 테크니컬 라이터는 사용자가 제품을 쉽게 사용할 수 있게 돕거나, 위험한 상황에 미리 대비할 수 있게 알려주거나, 문제가 생겼을 때 해결하는 방법을 가이드하는 문서를 쓰는 사람입니다. 쉽게 말해 어떤 제품을 사면 보통 동봉되어 있는 제품 매뉴얼 같은 것을 쓰는 사람이죠. 과거에는 이러한 매뉴얼을 쓰는 사람, 즉 매뉴얼 라이터를 테크니컬 라이터라고 불렀습니다. 그러니까 ‘테크니컬 라이터’는 아주 예전부터 있던 직무인 거죠. 최근 소프트웨어 분야에서 이야기하는 테크니컬 라이터는, 조금 더 세부적으로 보자면 API 라이터라고도 할 수 있습니다.

기술 문서 작성뿐만 아니라 이를 위한 효율적인 프로세스를 수립한다든가, 기술 문서를 효율적으로 관리하고 배포하는 방법까지 연구하고 있기 때문에 도큐먼트 엔지니어(document engineer)라고 부르기도 합니다. 저희는 보통 API 라이터나 소프트웨어 테크니컬 라이터라고 저희를 소개합니다.

테크니컬 라이터가 되기까지

Q. 정일 님은 어떤 계기로 테크니컬 라이터가 되신 건가요?

A. 저는 전공이 컴퓨터 공학이나 컴퓨터 과학이 아닌 컴퓨터 교육학이에요. 그러다보니 교육학을 공부할 때 얻은 인문학적 지식과 컴퓨터를 공부하며 얻은 IT 지식을 접목하여 남보다 더 잘할 수 있는 일이 뭐 없을까 많이 고민했거든요.

그런데 그런 고민 중에 첫 직장인 네이버에는 사실 개발 직군으로 입사하게 됐어요. 그렇게 입사해서 신입 사원 연수를 받았고, 연수 중 기술 문서 팀 교육을 들었는데, 이게 꽤 재밌더라고요. 제 고민의 답을 찾은 것 같았어요. 그래서 기술 문서 팀의 교육이 끝나자마자 강의하신 분께 달려가서 이 일을 꼭 해보고 싶다고 말씀드렸어요. 그 요청이 받아들여졌고 그렇게 테크니컬 라이터로서 저의 커리어를 시작하게 된 거죠. 지금 생각해 보면 참 겁이 없었던 것 같기도 하네요. 

Q. 테크니컬 라이터를 하려면 꼭 개발자 출신이어야 할까요? 혹은 그게 아니더라도 어느 정도 소프트웨어 기반 지식이 필요할까요?

A. 저는 ‘No’라고 말하고 싶어요. 개발 지식이 어느 정도 있으면 물론 도움이 되기는 하겠죠. 하지만 이 일을 정말 하고 싶은 사람이라면, 그러한 소양은 갖춰가면 되는 것이라고 생각합니다. 예전에 프로 야구 선수로 활동했던 사람이 어느 순간 개발자로 일하고 있는 모습을 보기도 했거든요. 저는 직업을 정할 때 반드시 사전 지식이 있어야 한다고 생각하지는 않습니다. 정말 하고 싶다면 노력으로 모자란 부분을 채울 수 있거든요. 물론 저는 테크니컬 라이팅 업무를 시작하고 4년 정도 문서를 작성하다 잠시 개발자로 전향해 개발 업무를 맡기도 했으니 개발자 출신이라고 할 수 있을 텐데요. 저희 팀엔 개발자 출신이 아닌 분들도 많이 계십니다.

Q. 정일 님은 테크니컬 라이터에서 개발자로 전향했다가 다시 테크니컬 라이터로 돌아오신 거군요? 다시 돌아오게 된 이유가 궁금합니다.

A. 아름답게 포장하면 이 일이 정말 좋아서 돌아왔다고 말할 수 있을 텐데요. (웃음) 늦게 개발을 시작해서 경쟁이 쉽지 않았어요. 그리고 2년 정도 개발자 입장에서 일해봤으니, 이제 정말로 개발자가 필요한 콘텐츠를 만들 수 있을 것 같다는 생각이 들기도 했고요. 그래서 다시 테크니컬 라이터로 이직을 생각하던 중에, 마침 LG전자에서 서드파티 개발자를 위한 새로운 플랫폼을 제공하려고 개발자 사이트를 준비하고 있는데, 문서 작업을 할 사람이 필요하다는 소식을 듣게 되었습니다. 그래서 지원했고, 그곳으로 가게 되면서 다시 테크니컬 라이터로 일하게 되었습니다.

Q. 테크니컬 라이터라는 직무가 가진 장점은 어떤 게 있을까요? 

A. 표준 문서나 개발 프로세스 표준을 보면 테크니컬 라이팅은 서포팅 카테고리에 있어요. 개발이 메인이고요. 테크니컬 라이터는 앞에 나서서 무언가를 하기보다는 옆에서 보조를 하는 직무입니다. 저도 앞에 나서기보다는 옆에서 지원하는 걸 좋아하는데요. 그래서 이 일이 제 성향에 맞는 것 같습니다. 누군가가 제 도움을 받아 큰 일을 해냈을 때 기분이 좋거든요. 그리고 간접적인 피드백으로 보람을 느끼는 경우도 많습니다. 예를 들면 스택오버플로우 같은 질문 채널이나 어떤 개발 관련 포럼에 LINE 플랫폼과 관련된 질문이 올라왔을 때, 누군가 제가 작성한 문서를 답변 내용의 참조로 걸어두는 경우가 있거든요. 제가 작업한 결과물이 유용하게 사용된 순간인 거죠. 또는 어떤 팀에서 파트너와 협업을 하기 위해 문서가 필요할 때 제가 작성한 문서를 유용하게 사용할 수도 있고요. 이렇게 다른 사람에게 제 문서가 도움이 되었을 때 기분이 매우 좋습니다. 이런 게 이 직무가 가진 매력인 것 같아요.

Q. 이 인터뷰를 보시는 분 중, 정일 님처럼 테크니컬 라이터가 되고 싶은 분도 계실 텐데요. 테크니컬 라이터가 되기 위해서는 어떤 것을 준비해야 할까요?

A. 음… 이러이러한 걸 공부하면 된다고 말씀드리고 싶은데, 제가 그럴 수 있는 자격이 되는지 모르겠어요. 테크니컬 라이터라는 직무를 달고 일한 경험은 오래되었지만, 앞서 말씀드렸듯 저는 테크니컬 라이팅 관련 전공이 아니라 컴퓨터 교육학 전공이라서 대학 시절에 특별히 테크니컬 라이팅과 관련된 과목을 수강한 적도 없고 관련 학위를 이수한 것도 아니거든요. 참고로 국내에는 없지만 해외에는 테크니컬 라이팅과 관련된 전공이 있어요. 해외에서는 테크니컬 라이팅과 관련된 전공을 수료하면 대부분 인문학사 학위(BA)를 줍니다. 카네기 멜론 대학에서 조금 특수하게 이학사 학위(BS)를 주고요. 카네기 멜론 대학 Software Documentation 쪽에 테크니컬 라이팅과 관련된 코스가 있는데요. 그 코스의 커리큘럼을 보시면 어떤 걸 준비해야 하는지 어느 정도 감을 잡을 수 있을 것 같습니다.

테크니컬 라이터는 어떻게 일할까?

Q. 지금은 어떤 일을 하고 계신가요?

A. 소프트웨어 라이프 사이클이라는 것이 있는데요. 그 사이클을 보면 개발 프로세스 상에서 제품이 출시되기 전과 출시된 후에 각각 필요한 문서가 있습니다. LINE의 테크니컬 라이터는 개발 프로세스 이후에 산출되는 문서를 주로 작성하고 관리합니다. 서드파티 개발자를 위한 API 레퍼런스나 개발자 가이드 같은 것을 작성하고, 또 LINE 엔지니어링 블로그에 발행되는 글도 감수하고 있습니다. 

저희 팀 리더 분이 업무를 소개할 때 이용하는 그래프가 있는데요. 소프트웨어 개발 프로세스를 비롯한 다양한 관점에서 어떤 기술 문서가 언제 작성되고 배포되는지 보여주는 그래프입니다. 표의 X축은 시간, Y축은 문서 배포 대상이나 범위를 의미합니다. 세로로 그어진 빨간 점선이 소프트웨어의 출시 시점입니다. 가로로 된 빨간 점선은 문서 공개 범위의 구분선인데요. 이 선을 기준으로 아래 쪽에 있는 문서는 내부용, 위 쪽에 있는 문서는 외부용으로 주로 사용합니다. 앞서 말씀드렸듯, LINE의 테크니컬 라이터는 주로 제품 출시 이후에 산출되는 문서 관련 작업을 수행하기 때문에 외부용 문서에 우선 순위를 두고 있습니다. 문서 작업 프로세스와 관련된 부분이 그래프에서 녹색으로 표시되어 있으니 참고하시면 좋을 것 같네요.

소프트웨어 개발 프로세스에서 기술 문서가 작성되고 배포되는 시점을 나타낸 그래프
(그래프와 그래프에 대한 설명은 인터뷰이가 인터뷰 후 별도로 보충해 주었습니다.)

Q. 현재는 Clova와 관련된 문서 작업을 하고 계신다고요?

A. 네. 외부 개발자를 위한 문서, 파트너 전용 문서는 물론 내부용 문서까지 다루고 있습니다. 

Q. 그러한 문서의 원천 소스는 주로 해당 제품을 개발한 개발자가 만들게 될 텐데요. 개발자가 문서를 어느 정도 수준까지 작성하고 테크니컬 라이터에게 넘기게 되는 건가요?

A. 문서 작성 프로세스에 대해 질문을 정말 많이 하시는데요. 테크니컬 라이터가 어느 수준으로 문서 작성을 지원하는지에 따라 프로세스가 조금씩 달라지기는 합니다. 초안은 대개 개발자가 작성해 주시고요. 테크니컬 라이터가 초안을 받아 문서 구조를 변경하고, 내용을 검토하고 표현을 수정합니다. 그 이후 개발자의 리뷰를 통해 기술 검토를 받고 동료 테크니컬 라이터의 리뷰를 통해 문장 표현, 문서 구조, 스타일 등에 대한 검토를 받죠. 이렇게 받은 피드백을 테크니컬 라이터가 반영하고 문서를 배포합니다. 

Q. 혹시 잘 모르는 기술에 대한 문서를 써야 하는 상황에서는 어떻게 하시나요?

A. IT 분야는 신기술이 계속 나오기 때문에 컴퓨터 관련 전공을 했다고 하더라도 모든 기술에 대해 잘 알 수는 없어요. 그래서 관련 지식이나 정보를 공부하는 시간을 확보해야 합니다. 내용을 잘 이해하지 못하면 함께 작업하는 개발자의 시간을 많이 뺏게 되거든요. 이 일을 하면서 공부를 참 많이 하게 되는 거 같아요.

Q. 개발자는 API 레퍼런스 문서를 작성할 때 Doxygen이나 Javadoc 등을 많이 사용하는데요. 이렇게 소스 코드 기반으로 생산되는 문서도 다루시나요?

A. 네. 다만, Doxygen이나 Javadoc은 보통 소스 코드에 있는 주석(comment)을 이용하여 문서를 생산하는 도구이기 때문에 문서 작업을 하려면 테크니컬 라이터가 소스 코드까지 직접 수정해야 합니다. 보통 이런 경우엔 GitHub를 이용해서 개발자와 협업하는데요. 간혹 다른 사람이 자신의 소스 코드에 직접 작성하는 걸 꺼리는 분도 있습니다. 이럴 때는 최소한 API 레퍼런스의 업계 표준 양식 정도는 맞출 수 있도록 가이드합니다.

Q. 기술 문서는 어떻게 작성해야 하는지에 대한 규칙이나 가이드를 어디서 정의하나요?

A. IBM이나 예전 Sun Microsystems처럼 문서화 잘하기로 유명한 기업에서 일하던 전문 테크니컬 라이터들이 ‘이런 기술 문서는 이러한 형태로 작성하는 것이 좋다’고 가이드한 문서와 책이 많이 있습니다. 저희도 그것을 참고하고 있어요. 팀 동료인 전정은 님이 최근에 문서 엔지니어링과 API 문서화에 관한 글을 작성하면서 테크니컬 라이터 톰 존슨(Tom Johnson)을 언급했는데요. 그 분이 블로그에 올린 테크니컬 라이팅을 위한 기본 서적을 소개하는 글을 보면 도움이 될 것 같습니다.

Q. 문서 작업을 하기 위한 다양한 도구가 있을 것 같은데요. 정일 님이 사용하는 문서 작업 도구가 궁금합니다.

A. 처음 입사했을 때, 저는 Microsoft Word를 사용했어요. 그런데 Microsoft Word로 작성된 콘텐츠는 재사용하기가 어려웠습니다. 그때 당시에는 Windows 환경이 아니면 Microsoft Word로 작성된 문서를 보거나 편집하기 어렵기도 했고요. 다양한 형식으로 변환하기에 좋은 도구는 아니었습니다.

그래서 다음으로는 IBM에서 만든 DITA나 DocBook이라는 포맷을 사용했는데요. 두 포맷 모두 XML 기반으로 문서를 체계적으로 만들고 관리할 수 있었습니다. 재사용도 가능하고 Java처럼 상속이라는 개념을 가지고 있기도 했고요. 이 포맷을 사용하면 하나의 문서를 만들어 여러 형식으로 변환할 수 있어 편리했죠. 하지만 문서를 작성할 때 개발자가 초안을 작업하거나 리뷰를 해야 하는데 그러기 위해서는 앞서 말한 XML 포맷을 이해하고 익혀야 했습니다. 그건 비용이 너무 많이 드는 일이었습니다.

IBM DITA와 DocBook

그래서 그 이후에는 워드프레스나 미디어위키concrete5 같은 MySQL 베이스의 CMS(Content management system)로 넘어갔어요. 웹 환경에서 콘텐츠를 WYSIWYG 방식으로 저작하고 관리했죠. 그런데 이런 도구는 사용자와 콘텐츠 양이 많아지면 점점 느려지는 단점이 있었습니다. 가장 최근에는 마크다운과 같은 템플릿 언어를 이용한 SSG(Static Site Generator)가 유행하고 있어요. 지금 진행하고 있는 Clova 문서화 프로젝트에서는 GitBook을 사용하고 있고요. 참고로 저희 팀 내에서는 다양한 SSG를 사용하고 있습니다. CMS와 협업 도구가 SSG와 GitHub으로 바뀐 이후에는 ATOM이나 Visual Studio Code를 문서 저작 및 빌드 도구로 쓰고 있습니다.

Q. 테크니컬 라이터의 관점에서 국내에 문서화가 잘 되어 있는 프로젝트는 어떤 게 있나요?

A. 한국어로 잘 되어 있다고 생각한 문서가 문득 떠올랐는데, 다시 생각해 보니 국내가 아니고 MSDN이네요? (웃음) 국내에서는 소프트웨어 분야의 테크니컬 라이팅이라는 게 이제야 막 정착되고 있는 중이라 제가 보기에는 아직 사례가 많지 않은 것 같습니다. 우리가 모자란 부분을 인지하고 외국의 좋은 점을 받아들이려고 노력하는 게 중요할 거 같아요. 참고로 GitHub에는 문서화가 잘된 곳의 목록을 공유하는 저장소(beautiful-docs)도 있더군요.

LINE에서 테크니컬 라이터로 일한다는 것

Q. 다른 회사도 LINE처럼 테크니컬 라이팅 팀이 있나요?

A. 독립적인 팀 단위로 있는 경우는 많지 않고, 개발 팀 내부에 테크니컬 라이터가 1명 정도 포함되는 정도인 것 같아요. 테크니컬 라이터 없이 개발자에게 직접 쓰게 하거나 외주를 주는 경우도 많죠. 제가 이전에 다녔던 회사에는 테크니컬 라이팅 조직이 연구소와 사업부 쪽에 각각 있었는데요. 제가 속했던 연구소 쪽에선 개발자 대상 기술 문서를 작성했고, 사업부 쪽에선 일반 사용자 대상 제품 매뉴얼을 작성했습니다.

Q. 테크니컬 라이터로서 일하기에 LINE이 가진 장점은 무엇일까요?

A. 개인적으로 국내에서 외부 개발자를 위해 플랫폼을 공개하는 회사가 많다고 생각하지 않습니다. 그런데 LINE은 그러한 플랫폼을 굉장히 많이 가진 곳이죠. 그만큼 문서의 중요성을 잘 아는 회사이기 때문에, 테크니컬 라이터로서 얻을 수 있는 기회가 많다고 생각합니다. 프로젝트가 크다 보니 작업하는 문서의 볼륨도 크고, 제가 작성한 문서를 보는 사람도 많아서 보람도 많이 느끼고 일할 맛도 납니다.

그리고 다양한 것을 시도해 볼 수 있어요. 볼륨이 큰 문서를 다루다 보면 문서를 생산하는 데에서 그치는 것이 아니라 문서의 버전 관리를 어떻게 할 것인지, 작성한 문서를 독자에게 어떻게 배포할 것인지 등등 고민해야 할 것이 많거든요. 이때 새로운 도구를 사용해 보거나 콘텐츠 관리 전략을 바꾸는 등 도전적인 시도를 해 볼 수 있어서 정말 좋습니다.

Q. 앞으로 정일 님이 꼭 해보고 싶은 일이 있을까요?

A. 테크니컬 라이팅과 관련된 공부를 더 해보고 싶어요. 국내에서 업무를 병행하며 공부할 수 있는 곳이 있는지 찾아보기도 했는데요. 그중 ‘문헌정보학’ 관련 공부를 하면 정보를 좀 더 체계적으로 관리하는 방법을 배울 수 있을 것 같더라고요. 테크니컬 라이터는 문서를 생산하는 역할뿐 아니라 생산된 콘텐츠를 어떻게 관리하고 유통하는지에 대한 지식도 있어야 해서, 앞으로 그런 분야의 공부를 좀 더 하고 싶습니다.

Q. 마지막으로 한 말씀 부탁드립니다.

소프트웨어 분야의 테크니컬 라이터를 뽑는 채용 공고가 예전에는 북미나 유럽 지역에 편중되어 있었는데요. 최근에는 국내를 비롯한 아시아 지역의 기업에서도 많이 올라오고 있습니다. 물론 그중엔 일반 사용자를 위한 테크니컬 라이터를 고용하는 공고도 있겠지만, API 라이터도 있을 겁니다. 저와 같은 사람이 늘고 있다는 건, 매력적인 소프트웨어 플랫폼이 국내를 비롯한 아시아 지역에서 많이 개발되고 있다는 걸 의미한다고 생각합니다. 이런 긍정적인 현상이 지속되길 바라고요. 앞으로 한국을 포함한 아시아의 소프트웨어 분야에서 테크니컬 라이터가 더욱 활발히 활동할 수 있는 시대가 오면 좋겠습니다.

마지막으로, 인터뷰 기회를 주신 Developer Relations팀, 항상 의지가 되어주는 팀 동료, 그리고 좋은 업무 환경을 제공해 준 회사에 감사드립니다.

Related Post