개발자에서 기술 작가로 전직하기까지 2년 간의 이야기

남정현

자기 소개

안녕하세요. 어느덧 15년째 건강 보험료를 납부하면서 일하고 있고, 아주 어렸을 적 경력까지 포함하면 어느덧 20년째 IT 업계에서 일하고 있는, 흔히 말하는 "고인물" 소프트웨어 엔지니어 남정현입니다. 아니, 최근에는 엔지니어가 아닌 기술 작가로서 새롭게 인사를 드립니다.

기술 작가란 무엇인가

소프트웨어 엔지니어가 아니라 기술 작가로서 자기 소개를 한다니 의아하게 생각하시는 분들이 많으실 것 같습니다. 이 짧은 소개 한 마디 만으로도 갑자기 주의가 환기되어 저를 유심히 보는 분들도 떠오르네요.

테크니컬 라이터 (좀 더 쉬운 우리말로 "기술 작가"라고 바꾸어 부르겠습니다.) 라고 불리는 직군의 사람들이 무슨 일을 하는지 생각보다 잘 알려지지 않은 것 같습니다. 전면에 드러나는 일 보다는, 주로 완성된 제품을 실제 사용자들에게 인도하면서 같이 전달되는 사용자 가이드를 작성하는 일에 시간을 많이 쓰기 때문일 것입니다.

그러다 보니 소프트웨어 엔지니어 일을 하던 사람이 갑자기 본인을 기술 작가라고 소개하는 것의 거리감은 제법 있는 것 같습니다. 클라우드 컴퓨팅 기술이 본격적으로 산업 전반에 영향을 끼치기 전이라면, 확실히 소프트웨어 엔지니어와 기술 작가는 서로 아주 다른 두 가지 영역이라고 보는 것이 타당했을 것입니다.

하지만 최근에는 이런 경계가 빠른 속도로 옅어지고 있습니다. 소프트웨어 개발자들은 분명 논리적인 체계를 가지고 작동하는 소프트웨어를 만드는 사람이지만, 혼자서 할 수 있는 일의 폭이 작기 때문에 필연적으로 팀을 만들어 협력해야 하며, 팀을 만든다면 자연히 팀원들 사이에 정보를 주고 받을 일이 많아질 수 밖에 없습니다.

이 과정에서 팀 안에는 다양한 직군의 사람들이 협업 하면서 일을 진행하게 되는데, 각자의 직군에서는 일상적으로 사용하는 언어들이 다른 직군의 사람들에게는 생소하게 들릴 수 있습니다. 그런데 이런 생소함이 꼭 완수해야 하는 일에서 걸림돌이 된다면 어떻게 해야 할까요? 특히 이것이 비즈니스와 비즈니스 사이를 잇는 상황이라면 더욱 가볍게 볼 수 없겠죠.

즉, 기술 작가는 복잡한 정보를 독자의 눈높이에 맞추어 다양한 형태의 매체로 알기 쉽게 풀어서 설명해주는 일을 하는 사람입니다. 흔히 작가라고 하면 문학적인 재능이 있어야 한다고 이야기하지만, 기술 작가는 그렇지 않습니다.

기술 작가는 지금까지는 주로 "문서"를 만드는 일에 전념해왔고, 그러다 보니 문서 만을 만드는 사람이라는 고정 관념이 널리 퍼져있었습니다. 뒤에서도 말씀드리겠지만, 이제는 문서 뿐 아니라 다양한 매체로 이런 문제를 해결할 수 있는 것이 중요하다고 말할 수 있습니다.

소프트웨어 엔지니어가 기술 작가로 전향하게 된 이유

소프트웨어 엔지니어로서 일하면서 저는 "무언가를 만든다"는 것에 큰 즐거움과 보람을 느끼며 살아왔습니다.

그러나 소프트웨어 엔지니어로서 문제를 해결하는 소프트웨어를 만드는 것 이전에, 그 소프트웨어를 만들게 된 상황, 배경, 맥락을 설명하고 기록으로 남기는 "문서화"는 생각만큼 많은 투자를 받지 못한다는 것을 스스로도 깨달았을 뿐 아니라, 현장에서 끊임없이 문제가 반복된다는 사실을 여러 번 접했습니다.

그러다 보니 IT 업계에서 일하는 모두가 한 목소리로 "문서화가 중요해"라고 마치 약속이라도 한 듯 누구나 같은 말을 하는 모습을 어디서나 접합니다. 하지만, 그토록 중요하다는 "문서화"는 결코 제대로 해결된 적이 없습니다. 왜 일까요?

제가 보기에 문서화는 소프트웨어를 만들 때 들여야 하는 에너지와 시간을 기준으로 봤을 때 적어도 70% 내외의 에너지와 시간을 들여야 의미 있는 결과물을 만들 수 있기 때문이라고 생각합니다.

여기에 더해 정말 안타까운 사실은, 문서화 작업으로 만들어진 결과물도 소프트웨어와 마찬가지로 가치가 시간이 지날 수록 하락하기 때문에, 지속적인 유지 보수가 뒷받침되어야 한다는 점입니다.

다시 말해, 소프트웨어를 만드는 과정과 이 과정을 거치면서 비용을 들이는 것 만큼 문서화에도 투자해야 우리가 생각하는 이상적인 모습을 마주할 수 있는 것입니다.

저는 이런 문제를 가만히 두고 보는 것이 항상 마음에 걸렸고 늘 안타까웠습니다. 소프트웨어를 "잘 만드는 것"은 차고 넘칠 만큼 충분하게 논의가 되어왔지만 왜 유독 문서화를 포함한 정보 전달은 잘 다루어지지 못하는 가에 대한 안타까움이 항상 있었습니다.

그래서, 소프트웨어 엔지니어로서의 기술적 역량을 충분히 보유하고 있으면서, 이런 문제를 집중해서 다룰 수 있는 역할을 하는 사람이 있다면 지금보다 더 나은 환경을 만들 수 있지 않을까? 하는 기대로 평소에 문서화와 정보 전달을 위한 노력에 많은 시간을 써왔습니다. 그리고 최근에는 이 방면에 온전히 집중할 수 있도록 기술 작가로서 본격적인 업을 시작하게 되었습니다.

달라진 것, 달라지지 않은 것

소프트웨어 엔지니어로서 일을 할 때는 요구 사항에 맞추어 "동작하는 소프트웨어"를 만드는 것이 중요한 목표였습니다. 기술 작가로 일하는 지금은 "이해하기 쉬운 콘텐츠"를 만드는 것이 중요한 목표가 되었다는 점입니다.

누가 콘텐츠를 읽거나 접할 것 인지를 생각해보고, 그 사람이 어떤 상황에서 무엇 때문에 콘텐츠를 접하고 있을 것 인지를 상상하며, 어떻게 하면 그 사람에게 최선의 결과를 가져다 줄 것 인지를 고민하며 콘텐츠를 만드는 것입니다.

소프트웨어를 만들 때는 요구 사항에 맞게 동작하며, 예외적인 입력 값이 주어지더라도 사용자에게 손해가 없도록 안전하게 소프트웨어를 만들고, 사용자가 원하는 목표를 신속하고 효율적으로 달성할 수 있도록 도와주는 것과는 확실히 다른 목표라고 할 수 있습니다.

사용자가 "원하는 것을 이룰 수 있도록" 해준다는 점에 있어서 둘은 다른 듯 보이지만 하나의 공통된 목표를 지향하고 있으며, 서로 분리되지 않고 긴밀하게 연결되어야 할 것입니다. 그런 맥락에서, 일을 하는 "방법"에는 분명한 변화가 찾아왔지만, 목적지에 도착하는 것에는 여전히 변함이 없다고 생각합니다.

때로는 글 뿐만 아니라 고도화된 방법으로 정보를 추출하고 가공할 수 있는 일을 해낼 수 있다면 그것이 꼭 글의 형태로 고정되어야 할 이유가 없습니다. 몇 가지 예를 들어보죠.

글 뿐만이 아니라 동영상도 정보 교환에서 중요한 수단이라고 생각합니다. (사내 VOD 라이브러리인 OvenTV)
글 뿐만이 아니라 동영상도 정보 교환에서 중요한 수단이라고 생각합니다. (사내 VOD 라이브러리인 OvenTV)

저는 사내 기술 세미나에서 공유되는 값진 엔지니어들의 지식을 자산화 할 목적으로, 매번 세미나가 있을 때마다 직접 영상을 촬영하고, 동영상을 편집하여 지속적으로 콘텐츠를 올리고 공유하고 있습니다. 이 과정에서 콘텐츠를 알리기 위해 다양한 노력을 기울입니다.

그리고 매월 제가 속한 팀에서는 정기적으로 타운 홀 미팅을 진행합니다. 팀 내에 속한 각 셀과 태스크 포스 들은 각자의 성과를 공유하고, 우리 팀 뿐 아니라 회사 내의 다른 팀과 자회사들을 위한 기능, 제품, 서비스를 출시하기도 합니다. 이 때 새로운 소식을 취합하여 전사 직원들을 대상으로 누구나 정보를 읽을 수 있도록 소식지를 발행하는 일을 합니다.

회사 구성원들을 대상으로 발행하는 뉴스레터
회사 구성원들을 대상으로 발행하는 뉴스레터

또한 콘텐츠를 만들거나, 어딘 가로 이동하는 과정에서 만들어지는 다양한 문서, 이미지, 영상 등의 콘텐츠는 모두 디지털로 저장되는 자산입니다. 디지털로 저장되는 정보는 당연히 개발자가 만드는 코드를 이용하여 처리를 자동화하고, 통찰을 얻을 수 있을 것입니다.

기술 작가로서 문서화 엔지니어링을 위한 애플리케이션 개발도 합니다.
기술 작가로서 문서화 엔지니어링을 위한 애플리케이션 개발도 합니다.

뿐만 아니라 콘텐츠를 분석하고 가공하기 위한 자동화 작업에 프로그래밍 능력을 활용할 수 있다면, 그 가치는 매우 높을 것입니다.

한정된 인원과 시간이 가끔 걸림돌이 되긴 하나, 저는 기술 작가로 일하는 지금도 여전히 개발자로서 역량을 아낌없이 투자하고 있으며, 동시에 발전시켜 나가고 있습니다.

이처럼 기술 작가는 누구에게나 열려있고, 어느 한 쪽을 꼭 선택해야 하는 문제가 아닌 다양한 직군이 한 데 어울려 자유롭게 일할 수 있는 새로운 직업이라고 저는 자신 있게 말할 수 있습니다.

기술 작가로서 뿌듯했던 기억

아직은 기술 작가로서 어떤 일을 할 것 인지를 치열하게 고민하던 중, 스스로의 정체성을 확립하고 일하는 방법을 규정할 수 있도록 도와주었던 중요한 프로젝트 두 가지가 있었습니다.

두 프로젝트 모두 데브시스터즈 사내 구성원을 위한 내부 서비스 프로젝트였습니다. 그 중 하나는 소프트웨어 엔지니어를 위한 자동화 기능을 제공하는 서비스였으며, 다른 하나는 전사 규모로 진행되는 타운 홀 미팅을 고도화 하는 방송 플랫폼이었습니다. 편의 상 전자를 Cargo, 후자를 DevTalk 이라고 칭하도록 하겠습니다.

Cargo 개발자용 가이드
Cargo 개발자용 가이드

Cargo 프로젝트를 진행하는 동안에는 문서화 사이트를 어떻게 제작하여 공유하는 것이 좋을지, 도구와 방법론 적인 관점에서 실력을 가다듬고 최적화 할 수 있는 소중한 시간이었습니다. 당시 제 목표와 의지를 실현할 수 있도록 도와주셨던 인프라 셀의 동료 팀원께 받은 도움은 정말 큰 힘이 되었습니다.

DevTalk 사용자 (시�청자)용 가이드
DevTalk 사용자 (시청자)용 가이드

그 후 DevTalk 프로젝트에서는 한층 더 폭이 넓어진 독자 층 (방송 시청자, 방송 스탭)을 대상으로 어떻게 해야 의미 있는 사용자 가이드를 만들 수 있을 것 인가에 대한 고민을 할 수 있었던 시기였습니다.

그리고 제품을 만드는 과정에서 언제 기술 작가가 참여해서 콘텐츠를 저작 하는 것이 좋은지, 어떻게 피드백을 주고 받는 것이 좋은 지를 학습할 수 있었던 소중한 시간이었습니다. 무엇보다도, 이 프로젝트에서 저는 회사 전체에 저를 "기술 작가"로서 알릴 수 있었던 데뷔 프로젝트였기에 뜻 깊은 시간이었습니다.

두 개의 프로젝트를 마치고 난 후, 제가 작성한 가이드가 실제로 문제 해결에 도움이 되었다는 피드백, 시스템과 서비스를 이해할 때 도움이 되었다는 피드백을 접할 수 있었고, 그 순간 제가 이 일을 올바른 방향으로 잘 해 나가고 있다는 것을 알 수 있어 행복했습니다.

기술 작가가 되실 여러분들을 위하여

기술 작가는 엔지니어 뿐 아니라, 특정 분야와 기술에 관심이 있다면, 본인이 인문학을 전공했든, 이공계를 전공했든 상관없이 누구나 도전할 수 있는 영역이라고 생각합니다.

저는 앞에서 "문서"를 만드는 일을 하는 사람이라는 "고정 관념"이 있다고 말했습니다.

문서를 기술 작가가 제작할 수 있는 하나의 제품이라고 본다면, 문서를 만들기 위해 인문학적 접근이 필요할 수도 있고, 공학적 접근이 필요할 수도 있는 것입니다.

그리고 "제품"이라면 "문서"만이 최종 결과물이라고 정해 놓을 이유 또한 없습니다. 즉, 저는 이 분야가 특정 분야의 전유물이라고 생각하지 않습니다.

그러므로 '나는 엔지니어여서 문서를 쓰는 것이 소질이 없다'고 한정 지을 이유가 없고, 인문 계열 전공이라서 '기술을 몰라 문송하다'는 말을 할 이유도 없습니다. 각자가 집중하고 만들어낼 수 있는 결과는 고유한 가치를 지니며, 모두가 소중한 자산이 됩니다.

옛 속담 중에 "구슬이 서 말이라도 꿰어야 보배다"라는 말이 있듯, 기술 작가에 출신은 중요하지 않다고 생각합니다. 자신의 전공, 적성에 연연하지 마시고 팀 동료, 그리고 새로 들어오는 팀원들을 위해 작게 실천할 수 있는 것부터 조금씩 문서를 써보세요! 틀림없이 누군가는 여러분에게 감사할 것이고, 피드백도 아끼지 않을 겁니다.

앞으로의 계획

우리 회사는 **<쿠키런: 킹덤>**의 기록적인 성공과 함께 전세계에서 사랑 받는 IP (지적 재산)을 보유한 회사가 되었다고 생각합니다. 당연히 같이 일하는 사람들이 한국어를 사용하는 사람만 있다고 가정하는 것도 그래서 더는 맞지 않는 말이라고 생각합니다.

정보를 누구에게나 손쉽게 전달할 수 있으려면, 독자가 한국어 만을 사용할 것이라는 가정에서 벗어나 어떻게 하면 효율적으로 여러 언어로 콘텐츠를 번역해서 출시할 것 인지에 대한 고민도 자연스럽게 하게 됩니다.

제품을 접하는 고객들을 위한 다국어 작업도 중요하지만, 우리 회사 구성원들을 위한 다국어 정보 공유는 어떻게 하는 것이 좋을 지에 대한 고민이 나날이 깊어지고 있습니다.

멀지 않은 시일 내에 저는 이 고민을 포함하여 나날이 커지고 있는 회사의 규모에 맞는 비즈니스 테크니컬 라이팅을 효과적으로 수행할 수 있는, 테크니컬 라이팅 내의 세부적인 역할, 직군에 대한 고민도 구체적으로 해보고 싶습니다.

그리고 고민이 끝날 무렵, 제 자리 옆에 앉아 같이 머리를 맞대고 기술 작문 활동을 고민하는 동료들이 함께 하는 모습을 상상해봅니다.

덧붙임

기술 작가로서 일을 시작할 무렵, 라인 (LINE)에서 기술 작가로 일하신다는 분들의 글과 영상을 보며 방향성을 잡고 큰 힘을 얻을 수 있었습니다.

그 외에도 딱 맞아 떨어지지는 않지만, 테크니컬 라이팅이라는 큰 분야를 이해하는데 도움이 될 만한 커뮤니티에 참여하고, 여러 강의를 보면서, 이 분야에서 일하는 분들이 어떤 일을 하고, 무엇을 중요하게 생각하는지 알아갈 수 있었습니다.

그 때 제가 도움받았던 자료들 가운데 몇 가지를 골라 기술 작가로 도전하시는 분들을 위해 공유드립니다.

블로그

YouTube 영상

온라인, 오프라인 교육

커뮤니티

컨퍼런스

© 2024 Devsisters Corp. All Rights Reserved.