"기술을 잘 모른다"는 감각이 오히려 무기다
테크니컬라이가 기술과 제품에 대해 질문하는 접근법
"XX와 YY를 QQQ에서 MM하면 NN될 수 있긴 하죠. "
15년 전, 처음 테크니컬라이터 겸 기술지원 엔지니어로 입사했을 때 회의실에서 가장 자주 들리던 말의 형태다. 조사와 동사의 어미만 제거하면, 이게 한국어 회의인지 낯선 외국어 회의인지 구분하기도 어렵다.
제품 개발팀이나 QA팀과 마주한 모든 회의에서, 나는 발언은 고사하고 사람들이 하는 말을 받아 적느라 고개를 들 새도 없었다 (받아 적으면서도 무슨 말인지 몰랐다). 경청한다는 메시지를 주기 위해 고개를 가끔 끄덕거리며 회의 시간을 어떻게든 버텼다. 나름 영어도 좀 할 줄 알고, 나름 컴퓨터 좀 만졌었는데, 이게 무슨 꿔다 놓은 보리자루인가 싶었다.
질문 조차 할 수 없다.
질문이라는 건 대상에 대한 최소한의 이해가 있어야 떠오르는데, 그때의 나는 무엇을 모르는지도 알지 못했다. 이렇게까지 기술을 잘 모르는 내가 이 일을 해도 되나, 그런 생각이 들지 않는 날이 드물었다.
그렇게 1년이 흘렀다.
칡흑 같은 어둠 속에서 앞으로 나가기 위해 손을 더듬어가며, 옆 동료에게 용기 내어 가끔 물어가다 보니 희미한 빛이 보이기 시작한다. 이제 저 개발자가 하는 말도 얼추 이해가 된다. '이게' 이랬었는데, 문제가 생겨서 '저렇게' 변경한다는 거구나. '이게'에 대한 실체 파악이 가능하고, '저렇게'에 대한 그림이 그려진다.
이런 감정은 비단 테크니컬라이터뿐 아니라 새로운 인더스트리에 입사하는 누구나 겪는 심정일 것이다. 다만, 테크니컬라이터는 제품에 대해 제일 잘 아는 사람인양 멋들어지게 조직화된 글을 쓰고, 이를 '공식적인' 문서로 박제해야 한다는 점에서 이 고통이 조금 더 섬세하게 다가온다.
기술을 모두 이해할 필요는 없다.
테크니컬라이터를 포함한 모든 비개발자는 개발자 앞에서 작아지는 순간을 자주 경험한다. 그들 앞에서 나는 늘 ‘더 모르는 사람’이기 때문이다. 하지만 이 감각은 제품의 구현에 대해서만 그렇다는 점을 분명히 인식할 필요가 있다.
‘내가 너만큼 개발을 잘하고 기술을 잘 알면, 내가 왜 개발자가 아니라 이 일을 하고 있겠어’라는 태도는 꽤 중요하다. 이 문장에는 ‘인정’과 ‘당당함’이라는, 어찌 보면 상반된 두 가지 태도가 동시에 담겨 있다.
첫째, 나는 너만큼 잘 모른다는 사실을 인정해야 한다.
둘째, 이렇게 잘 모르는 것이 당연하다는 점에서는 당당해야 한다.
내가 너만큼 잘 모른다는 것을 인정하지 않고, 어설프게 아는 척하다가 그들로부터 아무런 지식도 배우지 못한다. 서로 시간만 낭비하고 돌아오게 된다. 그들의 시간도 소중하고 내 시간도 소중하다. 나는 정보를 수집해 구조화하고, 이해 가능한 언어로 정리하는 전문가지만, 이 제품과 기술은 처음 접한다는 사실을 스스로 먼저 인정해야 한다.
이런 태도를 항시 가지고 일을 대하면, 개발자나 기획자 앞에서 괜히 움츠러들지 않는다. 그리고 오히려 이 '모른다'는 감각을 계속 유지해야 테크니컬라이터로서 살아남을 수 있다.
모른다는 감각이 왜 중요한가
개발자에게는 너무 익숙해서 더 이상 의식하지 않는 지점들이 있다. 여러 번 만들고, 여러 번 설명해 온 기능 앞에서는 어디가 어려운지 체감하기 어렵다. 하지만 테크니컬라이터는 그 익숙함의 바깥에 서 있기 때문에, 자연스럽게 걸리는 지점을 발견한다.
처음 제품을 접하는 사람의 시선은 내부자에게는 쉽게 사라진다. 설정 하나, 용어 하나, 흐름 하나가 왜 필요한지를 묻는 감각은 시간이 지날수록 흐릿해진다. 그래서 “여기서 막히는데요”라고 말할 수 있는 사람은 팀 안에서도 많지 않다.
이때 느끼는 ‘잘 모르겠다’는 감각은 결함이 아니다. 그 감각은 사용자가 실제로 마주하게 될 난이도를 가장 먼저 감지하고 있다는 신호다. 테크니컬라이터는 바로 그 지점에서, 문서를 쓰기 시작한다.
Domain Knowledge를 획득하는 4단계 접근법
모르는 것에 대해서 당당하자고 주장했지만, 이 말을 곡해해서는 안된다. "내가 모르는 것은 당연하니 내가 이해할 수 있게 여기 나오는 내용을 모조리 제 기준에 맞게 설명해 주세요"의 모드는 파멸을 초래한다.
경험상 나는 다음과 같은 네 단계 접근을 추천한다.
Step 1. 일단 사내에서 구할 수 있는 자료는 모두 구해서 읽어본다.
보통 IT회사의 개발팀은 문서화에 취약하다. 별도의 테크니컬라이터가 존재하거나 개발팀장이 문서화의 중요성을 아는 사람이 아니라면 대부분 지식은 개발자의 머릿속에 존재한다. 하지만 그럼에도 불구하고 제품을 시장에 팔아먹기 위해서 받아야 하는 최소한의 인증 등의 절차로 인해, 제품의 변경사항이나 신제품의 기능에 대해 기재해 놓은 문서가 어딘가에는 존재할 것이다. 사내 위키나 컨플루언스 등을 뒤져 문서화에 필요한 제품 버전과 일정, 제품의 변경 사항, 버그 픽스 범위 등을 대략적으로라도 파악한다.
Step 2. 구글링이나 AI에게 물어본다.
개발자에게 다짜고짜 찾아가기 전에 일단 모르는 어휘와 용어에 대해서 서치를 반드시 해본다. 대다수 회사의 제품은 오픈소스나 업계 표준 기술 위에서 만들어지기 때문에, 기본 개념은 외부 자료로 충분히 학습 가능하다. 그렇기에 미리 인터넷으로 용어의 뜻 정도는 스스로 독학할 수 있다면 하는 게 좋다.
Step 3. 팀장이나 가까운 동료에게 물어본다.
(이 단계는 내가 속한 회사의 부서 구조에 따라서 필요 여부가 달라질 수 있다. 테크니컬라이터가 개발팀 소속이 아닌 경우에 한해서 유효하다)
이렇게 1단계와 2단계를 통해 '무엇을 알아야 하는지'에 대한 감이 잡혔다면, 공개된 자료와 문서만으로는 내가 이해가 어려운 부분이 무엇인지도 대략 파악이 되었을 것이다. 그러면 이걸 바로 개발자에게 들고 가기보다는, 내 부서의 직속 팀장 또는 팀 내 관련 경험을 가진 동료에게 "혹시 이러이러한 게 뭔지 아세요, 이번 제품 업데이트 내역에 있던데 무슨 말인지 잘 모르겠어서요"라고 물어본다.
이 단계가 필요한 이유는, 개발팀이 이미 우리 팀에 관련 지식을 전달했던 히스토리가 있을 수도 있으며 또는, 내가 입사하기 전에 우리 팀의 동료가 관련 프로젝트를 진행한 경험을 가지고 있을 수 있기 때문이다.
회사는 한 유기체이지만 팀 간에 비용과 예산은 따로 집행되기에, 부서 간의 비용인 시간과 인적 자원의 활용을 가급적 서로 줄이는 편이 좋다. 또한, 서로 비개발자의 처지이기에 나와 유사한 입장에서 제품을 보는 시각의 설명을 듣는 것도 제품 이해에 도움이 되는 건 덤이다.
그리고 심적으로도 다른 팀보다 차라리 우리 팀 동료에게 내 부족한 모습을 보이는 게 마음이 편한 건 두 말할 것도 없다.
Step 4. 개발자에게 묻는다.
그렇다. 이제야 개발자에게 질문한다. 아마 처음 IT회사에 입사한 신입 비개발자나 테크니컬라이터들은 이 step 4를 가장 먼저 선택하는 경우가 많을 것이다. 하지만 내 경험에 의하면, 이 기능을 가장 잘 알고 있을 수밖에 없을 것 같은 바로 그 개발자를 찾아가서 물어봐도 내가 원하는 답을 얻지 못한 경우가 꽤 많았다.
앞서 설명한 것처럼 개발자는 제품의 가장 한가운데 앉아서 제품을 바라보고 있기 때문에 제품의 사용자가 제품을 바라보는 관점 하고는 많이 다르다. 즉 개발자에게 물어야 할 질문과 내가 다른 팀에게 묻거나 알아서 해결해야 할 질문이 따로 있다.
예를 들어, "XX기능이 여기에 왜 들어갔나요?"는 담당 개발자도 잘 모르는 경우가 많다. 그냥 위에서 개발하라고 했으니 했을 것이다. 이런 건 개발팀 리드나 제품 기획팀에 물어봐야 할 수도 있다.
"XX 이 1.0 버전에서는 이렇게 바뀌었고 이번에 출시되는 2.0에는 이러하게 바뀐다고 되어있던데, 맞을까요?" 또는, "새 버전에 들어간 YY기능의 동작 방식이 정확하게 어떤 component에 영향을 주는지 잘 모르겠는데 설명 좀 해주실 수 있을까요?"
정도의 질문이 개발자에게 하는 질문으로 적합한데, 이 대화가 가능하려면 YY기능이 무엇인지의 정의 정도는 이미 내가 습득해서 대략적으로라도 알고 있어야 개발자와 대화가 가능하다.
맺으며
"기술을 잘 모른다"는 감각이 오히려 무기가 될 수 있는 직업이 테크니컬라이터다. 마치 시대정신을 가진 '기자'가 상대를 취재하듯이 테크니컬라이터는 제품에 대한 사전조사를 충분히 미리 하고, 내가 상대에게 무엇을 물어볼지 고민하고, 그리고 다른 사람도 궁금해할 지점을 캐치해서 날카롭게 물어보는 기술이 중요하다.
