직무 전환 후, 첫 주 업무는 워드로 작성하던 매뉴얼을 웹 문서로 전환하기 였습니다.

한 번의 제품 출시에 작성해야 하는 매뉴얼은 4가지였는데, 국문·영문·일문 매뉴얼을 제공하고 있기 때문에 총 12개의 워드 파일을 관리해야 하는 구조였습니다. 이전에 FE 개발자로서 일하면서 제품 개발할 때마다 수많은 워드 파일을 관리하는 게 참으로 끔찍한 업무라는 생각을 했었어요. Typst 같은 플랫폼에서 작성하거나 아예 형상관리를 적용하면 관리가 쉬워질거 같다는 생각은 해왔었는데 아쉽게도 당시 문서의 관리 주체가 형상관리에 대한 이해가 부족했고, 새로운 것을 배우기엔 너무 바쁜 환경이었습니다. 그렇게 몇 년이 흘러... 사용자 가이드는 300페이지가 넘는, 문서를 여는 것도 몇십초 기다려야 열리는 부담스러운 파일이 되었습니다.

워드 문서의 문제점​

1. 수정이 힘들다​

저희 제품은 국문·영문·일문 3가지 매뉴얼을 작성해야 하는데요. 내용이 동일하고, 언어만 다른 다국어 워드 파일은 관리가 매우 까다롭습니다.

파일 하나에 300페이지가 넘기 때문에 세 언어에 능통하지 않은 이상 내용을 수정할 때 정말 헷갈립니다. 특히 일본어를 볼 땐, 뭐가 틀렸는지 보기도 힘들어요. 언어마다 길이가 다르기 때문에 국문에서 130 페이지에 있는 내용이 일문에는 137 페이지에 들어가 있기도 하고, 실수하기 딱 좋은 구조입니다. (실제로 웹 문서로 전환하면서 오번역 된 부분도 많이 잡았습니다.)

그리고 이미지를 한 번 교체하려면 3번의 반복 작업을 해야 합니다. 국문 파일을 열어서 교체하고, 영문 파일을 열어서 교체하고, 마지막으로 일문 파일을 열어서 교체하는데 개발을 해왔던 저에게는 워드 파일 열리는 거 기다리고, 페이지 찾아서 수 십개의 이미지를 교체하는 작업을 반복하는 것이 정말 고역이었습니다.

2. 리뷰가 어렵다​

지난 4년간 릴리즈 직전에 문서 오타를 발견해서 재빌드하느라 새벽까지 일했던 경우가 많았는데요. 300페이지 중에 몇 줄씩 찔끔찔끔 수정한 부분만 검수하기가 까다롭기 때문에 발생한 문제였습니다. 놀랍게도 워드에도 리뷰 기능이 있습니다...만 써보면 아실 것 같습니다. 복장 터집니다.

3. 버전 관리가 어렵다​

문서라는 것이 날을 하루 잡아서 작업을 끝내버리면 좋지만 아쉽게도 개발 상황에 따라서 중간중간 작업을 해야하기 때문에 최종 버전이 나올 때까지 여러번 작업을 하는 경우가 많습니다.

최종, 최최종, 최최최종

어떤게 최종인지도 잘 모르겠고, 롤백을 하더라도 어떤 버전으로 롤백해야하는지 일일이 까보지 않으면 보기가 힘든 구조였습니다. 처음 인수인계 받았을 때에는 Git 없이 지금까지 어떻게 관리해왔는지 신기하다는 생각이 들었어요. 비 개발자라도 형상관리를 알아두면 업무 효율을 많이 높일 수 있을 것 같습니다.

회사 생활 4가지 팩트​

1. 프런트엔드 개발자에서 테크니컬 커뮤니케이터로 직무 전환.
2. word로 관리하던 문서를 웹 문서로 전환. 비 개발자를 위한 Git 사용 가이드 제작.
3. CS, VoC 프로세스 개선 프로젝트 참여. 정기 회고 및 CS 리포트 발간 문화 정착.
4. 팀 빌딩을 위한 개발 회고 퍼실리테이팅 및 팀 워크샵 주도.

팩트가 가르쳐준 것​

무조건, 역지사지​

올해 했던 일들은 '협업'이 핵심이었습니다. 개발자로 일할 때에도 협업은 중요했지만, 테크니컬 커뮤니케이터로써의 업무는 협업의 비중이 훨씬 높았습니다. 고객이 바로 내 옆의 동료들이고, 내 결과물이 그들의 업무 효율을 높이는 것이기 때문에 기술을 도입해서 업무가 더 편해지도록 해야했습니다.

내가 문제로 여겼던 일도 상대방에게는 문제가 아닐 수 있고, 문제 정의에서부터 의견이 맞지 않으면 일을 시작조차 할 수 없습니다. 설령 내가 몰아붙여서 시작하더라도 성공적으로 마무리할 수 없습니다.

• 기술보다 먼저인 건 상대방의 기분을 헤아리는 것.
• 진실보다 중요한 건 상대방의 기분을 좋게 해주는 것.

진정으로 하고 싶은 일을 하기 위한 필수 조건이라고 생각합니다. 이제야 사회 생활이 무엇인지... 조금씩 느껴가고 있습니다.

한국의 IT 업계 사람들, 특히 개발자들은 매년, 매 분기, 심하면 매달, 매주 회고를 하는 문화가 있다. 나도 회고를 꽤 좋아하는 편이라 IT계의 거장인 빌 게이츠가 회고록을 책으로 냈다고 했을 때, 빌 게이츠가 생각한 스스로의 인생 평가가 매우 궁금했다. 마이크로소프트의 열혈 팬도 아니고, 빌 게이츠를 좋아하는 마음도 없었는데도 500페이지에 달하는 회고록은 정말 재미있었다. (빌 게이츠는 개발도 잘하고, 사업도 잘하고, 돈도 많고, 글도 잘 써…)

싹수가 남다른 트레이​

*트레이는 게이츠 가족에서 빌 게이츠의 애칭이다.

카드 게임을 통해 나는 아무리 복잡하고 불가사의해 보이는 무엇이라도 결국에는 알아낼 수 있는 경우가 많다는 사실을 배웠다. 세상은 이해할 수 있는 대상이었다.

책은 할머니 댁에서 카드 게임을 하는 빌의 이야기로 시작한다. 가족에 대한 이야기를 정말 세세하게 썼는데, 본인의 유년기와 청년기를 정말 잘 회고한 것 같다. 그의 어린 시절을 이해하고 나니 빌 게이츠라는 사람을 '세계 1위 부자'에서 좀 더 입체적으로 바라볼 수 있었다.

그 나이의 아이들은 부모와 선생님이 모든 답을 알고 있으리라 기대한다. 나는 점차 부모님과 선생님이 그렇지 않다고, 적어도 나를 만족시킬 만한 답을 주지는 못한다고 느꼈다.

그리고 빌 게이츠는 정말 똑똑했다. 아주 어린 시절부터 지식에 대한 확신 수준이 남다르다고 생각했다. 나는 아직도 나 자신에게서 나온 답을 믿기보다는 늘 나보다 성숙한 누군가의 답을 기대하는데 고작 9살의 나이에 저런 수준의 자기 확신이 가능한걸까? 신기했다. 그가 수학을 좋아한 이유도 '수학을 통해 다른 학문을 익히는 법을 깨달을 수 있어서'라고 했는데, 수포자 출신으로서 그 표현 자체가 신선했다. 수학을 배움의 치트키로 써먹었다는 그의 경험담을 들으니 수학을 잘하고 싶다는 마음이 뒤늦게야 뿜뿜했다.

이제 프런트엔드 개발자가 아닙니다..!​

지난 4월, 공식적으로 뉴로클의 테크니컬 커뮤니케이터가 되었습니다. 일주일 간의 휴가를 가지고 직무를 변경했고, PM팀 소속의 테크니컬 커뮤니케이터로 일한지도 100일이 훌쩍 넘었습니다.

링크드인 프로필도 새롭게 바꿨습니다 :)

제 인생에서 꽤 큰 결정이고, 빅 뉴스인데 한 번도 글로 정리해본 적이 없더라고요. 그래서 이번 글에서는 제가 왜 프런트엔드 개발자에서 테크니컬 커뮤니케이터로 직무를 전환했는지, 어떤 일을 하고 있고, 앞으로 무엇을 해보고 싶은지도 함께 정리해보려 합니다.

1만 시간의 법칙은 틀렸다​

1만 시간의 법칙; 어떤 분야의 전문가가 되기 위해서는 1만 시간의 훈련이 필요하다는 법칙

1만 시간을 꾸준히 투자하면 누구라도 특정 분야의 전문가가 될 수 있다는 이야기를 학생때부터 자주 들어왔다. 그러나 이 법칙은 틀렸다. 1만 시간을 주구장창 한다고 전문가 수준에 오를 수는 없다. 핵심은 '1만 시간'이 아니라 '훈련'에 있기 때문이다. 의도적인 행동과 피드백을 통해 개선을 반복하는 것을 꾸준히 해야 전문가가 된다.

저는 문서화를 중요하게 여기지만 사실 문서는 적으면 적을수록 좋다고 생각합니다. 코드를 최소한으로 작성해 효과적으로문제를 해결하는 것이 기술이듯 문서도 최소한으로 작성하면서 필요한 정보를 전달해야 합니다.

지난 3년간 회사의 FE팀 위키를 구축하고 유지보수하며 저만의 문서화 기준이 생겼는데요. 이 글에서는 문서화가 필요한 경우와 필요하지 않은 경우를 구분하는 기준을 제시하고, 실용적인 문서화를 통해 개발 효율성을 높이는 방법을 탐색해 보겠습니다.

덮어놓고 쓰다 보면...​

회사에서는 크게 3가지 방식으로 문서화를 해왔습니다.

1. 코드 주석
2. Pull Request 설명
3. 노션

그중 노션은 시간과 정성을 들여 작성해야 하는 '공식적인 문서' 역할이었는데요. 코드 설계나 구성에 대한 설명, 리팩토링 과정, 에러 핸들링 기록, PoC 상세 내용 등을 기록했습니다. 그렇게 3년 정도 노션에 열심히 문서를 쌓아놓다 보니 몇몇 불편한 부분들이 느껴졌습니다.

경상도 사투리로 '어느 정도 높이까지 올라가는 거예요?'를 말하는 밈이 있다. 난 성장에 대해 생각할 때 항상 이 밈을 떠올린다. 어느 정도 높이까지 올라가야 되는 걸까? 2024년은 성장 속도와 방향성에 대해서 고민이 많았던 한 해였는데 【함께 자라기】는 그런 고민이 있는 사람들에게 일종의 가이드가 되어 줄 수 있는 책인 것 같다.

책에서 말하고자 하는 큰 맥락은 위 세 문장이라고 생각한다. 전하고자 하는 메시지와 글의 순서나 구조가 너무 잘 짜여있어서 많은 문장들이 마음에 와닿았다. 책의 제목은 함께 > 자라기이지만 목차 순서는 자라기 > 함께 인 것도 다 설계된...!

코드만 잘 짜서는 안된다​

책에 반복적으로 나오는 이야기가 있다.

예전에는 소프트웨어 개발 전문성과 사회성은 별개로 치부되어 "프로그래밍 실력은 좋은데 의사소통 능력은 부족하다"든가 하는 이야기를 했다면, 이제는 프로그래밍을 잘한다는 정의 안에 의사소통 능력을 그 일부로 보게 된 겁니다.

전통적으로 컴공, 개발자의 이미지는 GEEK 한 느낌이 있었던 것 같다. 검정 뿔테 안경에 거북목과 사회성 부족으로 사람보다 컴퓨터와의 대화가 더 편한 이미지...? 아직까지도 그런 편견이 박혀 있고, 종종 농담거리로 사용되는 걸 보면 기술적 성장과 사회성을 별개로 생각하는 사람이 아직도 많은 것 같다.

개발자 === 컴퓨터 ?

번역을 잘하려면 외국어뿐만 아니라 모국어도, 아니 모국어를 훨씬 더 잘해야 한다. 개발자는 사람과 컴퓨터 사이의 번역가인데 왜 컴퓨터처럼 커뮤니케이션하는 걸 자랑스럽게 여기는 걸까? 아보카도 있으면 (아보카도를) 6개 사 오라는 말을, 그 맥락을 이해하지 못하는 사람에게 성장을 기대할 수 있을까? 생각해 보니 왜 저자가 프로그래밍 능력에 의사소통을 포함했는지 이해가 되었다.

2024 Lesson Learned​

신뢰는 말이 아니라 행동에서 나온다​

어느 날, 회사에서 서비스 개발을 멈추기로 했다라는 글에서 한 번 정리했는데 올해 초, 애자일 업무 방식을 도입하기 위해 2개월 간 많은 분들과 치열하게 논의하는 시간을 가졌었다. 논의 할 때, 서로 반대되는 의견을 다룬 적이 많았는데 어떤 사람의 말은 신뢰할만했던 반면, 어떤 사람의 말은 전혀 신뢰하기 어려웠다. 평소 그 사람의 행동이 그 사람의 말에 힘을 실어준다는 것을 느낀 것이다.

말하는 것은 쉽고, 행동하는 것은 어렵다. 사람들이 내 말을 듣게 하려면 평소에 내 말을 직접 실천하는 사람이 되어야한다.

얼마전 읽은 책 『코드와 살아가기』는 1978년부터 20년이 넘도록 소프트웨어 엔지니어 및 컨설턴트로 일한 엘런 울먼의 에세이이다. 책에는 작가가 컴퓨터에 기본으로 설치된 윈도우를 삭제하고, 리눅스를 설치하는 부분이 있다. 리눅스를 설치하며 윈도우 운영체제가 얼마나 사용자의 자유를 제한하고 있는지 느끼는 부분을 보며 그동안 컴공 필수 과목으로만 생각해왔던 '운영체제'에 대해서 다시 생각해보게 되었다.

나는 태어나서 처음 접한 운영체제가 윈도우였고, 거의 20년이 넘는 시간동안 컴퓨터에 대한 지식 없이 사용해오면서 컴퓨터 === 윈도우라고 생각해왔다. 그런데 소프트웨어 개발자로 일하게 되면서 고객사에서 윈도우, 맥 뿐만 아니라 다양한 환경에서 컴퓨터를 활용하는 것을 보면서 리눅스에 대해 관심을 갖게 되었다. 그러던 차에 길벗 출판사에서 글또 10기 멤버를 대상으로 책을 지원해주는 이벤트에 당첨되어 리눅스 입문서를 읽어보게 되었다.

글또에서 책 읽기​

글또는 글쓰기 모임이지만 '책 읽기'와 궁합이 잘 맞는다고 생각한다. 읽는 것을 좋아하는 사람들이 보통 쓰는 것도 좋아하기 때문이다. (나 또한 읽는 것을 좋아하는 만큼 쓰는 것도 좋아한다.)

이번에는 글또 덕분에 550여 페이지에 달하는 두꺼운 책을 한달에 걸쳐 완독할 수 있었다. '책읽었또'에서 매일 읽은 책을 인증하는 방식이 두꺼운 책을 꾸준히 읽을 수 있게 하는데 도움이 되었다.

덕분에 즐겁게 읽을 수 있었다

아이유의 노래 '첫 이별 그날 밤'을 듣다가 '처음'에 대해 생각하게 되었습니다. 입사 후 저의 첫 커밋, 첫 PR(Pull Request)이 생각났어요. 처음 PR을 작성하고, approve를 받아 메인 코드 베이스에 머지했던 그날은 드디어 사회에서 1인분을 하는 사람이 되어간다는 기분에 설레는 마음이 가득했던 것 같습니다.

입사 후 첫 3주동안에는 회사 제품을 사용해보고, 제품 코드를 리딩하는 업무를 진행했습니다. 약 3년정도 진행중인 프로젝트여서 코드 베이스가 크고 복잡했는데요. 가장 먼저 눈에 들어온 부분은 코드 컨벤션이었습니다.

...오잉?! 컨벤션의 상태가...!​

가장 처음 작업했던 것은 커밋 메시지를 자동화하고, PR 템플릿을 만든 일이었습니다. 프로젝트를 빠르게 개발하는 것이 가장 중요했던 시기라서 제가 입사하기 전에는 문서화 작업이 많이 부족했는데요. 코드 리뷰를 구두로 진행하고, PR에 관련 작업에 대한 설명이 대부분 없었습니다.

예를들면 이런식...

약 2,000 라인이 넘는 changes임에도 불구하고, PR에 아무런 설명이 없었어요. 3년간의 히스토리를 아무런 기록 없이 넘겨받으려니 엄청 막막했습니다. 그래서 PR에 대한 템플릿을 만들어 최소한으로 남겨놓아야할 정보들을 기록할 수 있도록 만들었어요.

역사적인 첫 PR🥳