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

워드 문서의 문제점​

1. 수정이 힘들다​

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

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

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

2. 리뷰가 어렵다​

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

3. 버전 관리가 어렵다​

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

최종, 최최종, 최최최종

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

Docs to Code​

워드는 이제 안녕! 👋 본격적으로 웹 문서화하기로 방향을 결정 한 후 한 일은 다음과 같습니다.

1. 플랫폼 선정(Docusaurus)
2. 워드 내용 이전
3. 다국어 적용
4. 이미지 통합
5. 스크립트 적용

Docusaurus 선정 이유​

여러 플랫폼 PoC를 진행하여 최종적으로 Docusaurus를 선정했습니다. 이유는 다음과 같습니다.

• Blog와 Docs 형태로 분리되는 구조
• 다양한 플러그인 제공
• Meta에서 개발하여 지속적으로 관리되는 오픈소스
• 방대한 커뮤니티

Vitepress, Rspress, Mkdocs 등 다른 SSG 를 살펴보았는데 아무래도 첫 웹 문서 전환이다보니 가장 안전한 플랫폼을 선택하게 되었습니다. Vitepress는 이후 다른 제품의 매뉴얼을 제작할 때 사용해보았는데 Docusaurus보다 깔끔하고, 가벼운 문서에 적합한 느낌입니다.

포스트 형태가 구분되면서 txt 파일로 따로 관리되고 있던 릴리스 노트도 웹 문서에 포함시킬 수 있게 되었습니다. (관리 리소스 -1 ✌️)

빠르게 워드 이전하기​

워드 내용을 이전할 때에는 하나씩 붙여넣기 하기보다는 pandoc 으로 docx파일을 markdown으로 변환했습니다.

pandoc -f docx {입력 파일.docx} -t markdown -o {출력 파일.md}

# -f : 입력 파일 형식
# -t : 출력 파일 형식
# -o : 결과물

스크립트​

개발의 장점은 변수나 함수를 사용해서 반복되는 작업을 줄이는 것에 있습니다. 처음 개발을 배울 때, 변수를 쓰면 100번 할 일을 1번만 하면 된다는 점이 제일 와 닿았었는데요. 문서 전환에서도 제품명이나 회사명, 기능명처럼 고유한 정보들을 변수 처리해두어 일괄 수정이 쉽도록 했습니다.

이미지 크기를 일괄적으로 제어한다거나 제공 국가에 따라 노출하면 안되는 정보를 가린다거나 할 때의 공수를 크게 줄일 수 있었습니다.

어려웠던 것들​

개인 블로그도 Docusaurus를 쓰고 있으니까 큰 어려움 없이 진행될 줄 알았는데 생각지 못했던 문제들이 있었습니다.

1. 배포​

제품 특성상 오프라인 환경에서도 웹 매뉴얼을 제공해야하고, 외부 노출이 되면 안되기 때문에 클라우드 배포가 아닌 제품에 탑재하는 방식으로 배포해야 했습니다.

Docusaurus는 SPA이므로 JS 번들 파일이 웹 서버를 거치며 실행되어야 hydrate 되며 제대로 보이게 됩니다. 그래서 로컬에서 file: 로 실행하는 것이 아닌 http: 프로토콜을 거쳐야하는 것이죠. 웹 문서는 만들었는데 서빙을 어떻게 해야할지 몰라서 백엔드 개발자분과 여러번 실험을 한 끝에 최종적으로 nginx로 서빙하는 것으로 마무리지었습니다.

배포 부분은 개발 지식이 조금 필요해서 생각보다 어려움이 있었어요.

2. 용량 최적화​

다국어 문서에서 중복되어 사용되던 이미지를 하나로 줄이며 용량이 1/3로 줄었지만 그럼에도 여전히 용량 문제는 있었습니다. 매뉴얼을 워드에서 pdf로 추출해서 제공하는 시절에는 몰랐는데 삽입된 이미지 하나하나의 용량이 커서 최종 빌드본 용량이 매우 큰 문제가 있었습니다.

cwebp를 사용해 이미지를 webp 형식으로 변환했고, 795MB에서 160MB까지 용량을 줄였습니다. 이 때 사용한 스크립트로 간단한 데스크톱 앱을 만들었는데 이는 다른 포스트에서 다룰 예정입니다.

3. pdf 추출​

인터넷이 제공되지 않는 환경에서도 매뉴얼을 제공해야하기에 웹 문서를 제공하더라도 pdf를 추출하여 제공해야 했습니다. docusaurus-prince-pdf 플러그인을 사용해서 pdf를 추출하긴 했지만 섬세한 줄바꿈 같은 것들이 불가능해서 조금 아쉬움은 남습니다.

그리고 pdf 추출 방식이 굉장히 개발 친화적인 느낌이라 비개발자가 업무 인수인계를 받는다면 꽤 난이도가 있을 것 같아서 좀 더 좋은 방법을 찾아야하는 과제처럼 느껴지는 부분입니다.

느낀 점​

생각지 못했던 어려움들은 있었지만 FE 개발 업무를 하면서 늘 하고 싶었던 문서 형상 관리를 제대로 해보고, 실제로 많은 개선을 이뤄내서 좋았습니다. 그리고 웹 문서가 탑재된 버전이 출시된 이후 비즈팀에서 반응이 좋아서 놀랍기도 했어요. 진작 할 걸! 신규 입사자분들이 제품 사용할 때, 웹 문서를 사용하는 걸 보면 흐뭇합니다☺️

이제 뭘 Git에 올려볼까?​

즐겨보는 웹툰에서 개발자가 다른 직무의 업무를 할 때, 모든 것을 Git에 올리려 할 것이라는 장면을 봤을 때 너무 공감이 되어 웃겼는데요 ㅋㅋㅋㅋ

근데 진짜 고객문의 깃에 올려주시면 안될까요 고객님?

아무튼 4년간 묵혀왔던 답답한 업무 병목을 해낸 테크티컬 라이터로서의 첫 업무! 만족도 100점!!

워드를 웹 문서로 전환하거나 형상 관리 도입을 고민하고 계신 분들께 이 글이 많은 도움이 되었으면 좋겠습니다.

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

팩트가 가르쳐준 것​

무조건, 역지사지​

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

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

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

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

중요한 것은 선의(善意)​

동료 평가에서 매년 빠짐없이 들었던 피드백이 있습니다.

"커뮤니케이션 스타일이 직설적이다."

처음엔 고쳐보려고 했는데, 지금은 그렇지 않습니다. 직설적임을 인정하고, 스타일은 유지하되 관점을 바꾸었습니다.

듣기 좋은 소리를 하는 것보다 "상대방이 듣고 싶어 하는 말을 하는 것"이 중요합니다. 내가 하는 말은 "당신을 위해 하는 말이고, 당신을 진심으로 돕고 싶다"는 태도로 다가가면 직설적인 말투도 충분히 수용될 수 있다는 것을 알게 되었습니다.

"아니, 근데"로 첫 마디를 시작하지 않는 것만으로도 대화가 풀립니다. 상대의 의견을 먼저 확인하고 나서 하고싶은 말을 꺼내는 것만으로 사람들은 마음의 문을 엽니다. 간단하지만 실천하기는 정말 어렵습니다.

Next Step​

25년도에는 다양한 업무를 했습니다. 마음 한 구석에는 "이렇게 여러 곳에 발을 걸쳐놓는 게 옳은 일일까? 내가 작년에 했던 직무 전환 선언은 스스로 잡부가 되기로 한 것일까?"라는 불안감도 있었습니다. 아마 테크니컬 라이터로서의 전문성이 부족하다는 생각이 들어서겠지요. 불안감을 자동화나 프로세스 구축 등의 잔기술로 해소해보려고 했던 것 같아서 조금 반성했습니다.

부딫혀보기​

불안함을 떨쳐내기 위한 방법은 시도하는 것 뿐입니다. 세상에 내가 좋은 테크니컬 라이터일까요? 라고 물어보는 방법 뿐...

26년에는 테크니컬 라이터 버전의 이력서도 작성하고, 면접도 시도해 볼 생각입니다. 부족하다면 노력해보면 되고, 충분하다면 당당하게 재미있게 살면 될 것 같습니다.

일단 이력서를 쓰기로 마음먹은 순간부터 테크니컬 라이터로 쌓아야할 경험들이 생각나고, 업무에서 더 집중해야할 부분들도 보이기 시작했습니다.

AI로 대체될 직업​

최근 MS에서 공개한 논문¹에는 AI와 "협업"하게 될 가능성이 가장 높은 직업군 상위 40개 안에 테크니컬 라이터와 웹 개발자가 포함되어 있습니다.

AI는 초안 작성, 문서 정리, 반복적인 설명을 잘 하지만 제품 맥락 이해, 내부 이해관계자 조율 등의 업무는 아직 사람을 대체하기 힘들기 때문에 직군이 완전히 대체되기보다는 AI와 협업하는 형태로 업무의 형태가 변화할 가능성이 크다는데요. 단순 맞춤법 검사기나 번역기를 넘어 AI를 더 똑똑하게 활용하는 것이 2026년의 과제가 될 것 같습니다.

AI가 대체할 수 없는 능력​

1년 동안의 경험이 말해주는 저는 "스타 플레이어가 아니고, 조직을 움직이게 하는 사람"입니다.
많은 사람들이 덜 고통받는 구조를 만들고, 일이 돌아가는 시스템을 만드는 역할을 잘 합니다.

아직은 진짜 어느 조직에서든 "잘 할 수 있다"고 말하기에는 자신감이 부족한 거 같아서, 조금 더 경험해보고 실험해보며 역량을 키우는 노력이 필요할 것 같습니다.

AI 대체할 수 없는 능력 2​

데이터만 주면 AI가 뭐든 카피해가는 시대에, 한 가지 카피할 수 없는 것이 있다면 바로 "태도"입니다.

조금 서툴더라도 포기하지 않고, 본인의 일을 즐기며 끝까지 책임지는 것. 남들에게 자랑하고 싶을 정도로 본인의 일에 애정을 갖는 것. 하고 싶은 일을 하기 전에 먼저, 주어진 일을 최선을 다해 마치는 것.

그런 태도를 가진 인턴분들을 보며, 혹은 가지지 못한 인턴분들을 볼 때에도 다시금 되새기게 됩니다. 조직에서 대체 될 수 없는 사람은 좋은 태도를 가진 사람이 아닐지...

싹수가 남다른 트레이​

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

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

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

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

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

잘 하는 사람이 열심히 하면?​

그해 여름, 나는 한 사람이 어떤 분야에서 어떻게 최고가 될 수 있는지에 대해 많은 생각을 했다. 다른 사람들보다 20퍼센트 더 뛰어나려면 무엇이 필요할까? 타고난 재능은 어느 정도 작용하고 헌신적인 노력은 또 얼마나 중요한가? 전날보다 오늘 더 나은 성과를 내기 위해 매일 끊임없이 집중하고 고심하며 얼마나 오랜기간 노력을 기울여야 최고의 경지에 오를 수 있는 걸까?

가장 인상 깊었던 부분은 타고난 재능이 있음에도 남들과 비교하며 나태하기는커녕, 진짜 하루하루 열심히 살아가는 그의 삶의 태도였다. 정말 매 순간 치열하게 살아왔다는 게 한 문장 한 문장에서 느껴진다.

학업에 집중하지 못했던 어린 시절부터 자기만의 캐릭터를 구축해 나가고, 스스로의 재능을 발견하는 모습, 눈 떠 있는 모든 시간을 프로그래밍에 쏟아붓는 모습 등. '세계 최고 부자'를 목표로 산 게 아니라, 진짜 본인의 열정을 집요하게 좇으며 사는 태도가 감명 깊었고, 배우고 싶었다.

내가 60살쯤 내 삶을 돌아본다면 총 몇 페이지나 쓸 수 있을까? 아마 100페이지를 채우기도 힘들지도… 열심히 살아온 만큼 돌아볼 것도 많아 500페이지를 꽉꽉 채울 수 있지 않았을까?

그 시절 개발 이야기​

1960년대에 처음 컴퓨터를 접하고 그 열정을 불태우던 시기를 아직도 생생하게 기억하는 게 신기했는데, 그 부분을 읽으면서는 1960~70년대의 컴퓨터 환경을 엿볼 수 있어 재미있었다.

빌 게이츠가 열심히 썼던 알테어 8800

책을 다 읽고 넥슨컴퓨터박물관에 가서 직접 천공카드와 알테어 8800을 보고 왔는데 감회가 남달랐다. 베이직 예제 코드를 한 번 따라 쳐보면서 '도대체 이걸로 어떻게 개발을 한 걸까…'싶었고, 그 시절 선배 개발자들에 대한 존경심이 더 깊어졌다.

특히 마이크로소프트를 처음 창업하던 부분을 읽을 때는 스타트업 재직자로서 공감 가는 부분이 많았다. 50년 전 이야기인데도 요즘 스타트업들과 크게 다르지 않다는 점이 신기했다.

하지만 이제 우리는 전혀 모르는 사람들을 고용하면서 그들에게 뉴멕시코로 이주해 18개월밖에 안 된, 미래가 불투명한 회사에 운명을 맡길 것을 요구하고 있었다. 다소 부담스러운 일이 아닐 수 없었다. 초기에 채용된 그들을 보며 마이크로-소프트가 비로소 진짜 회사처럼 느껴지기 시작했다. 그가 그 사진관에 데려간 '가족'은 우리 회사의 총원 12명 가운데 11명이었다.

초기 멤버들을 '가족'이라고 표현한 것도 굉장히 의외의 따뜻한 모먼트였다.

초기 MS 멤버들

요즘 스타트업처럼 열댓 명 남짓한 직원들과 함께 찍은 단체 사진이 귀엽게 느껴졌다. 회사의 덩치가 점점 커지던 시절, 초기 구성원들은 어떤 기분이었을까 궁금해졌다. 레이크사이드에서 시작했던 프로젝트성 작업들을 이어오다가 회사를 스케일업하면서 또 다른 국면의 경영적 어려움을 느꼈을 텐데, 그 계기와 이후 어떤 방식으로 회사를 운영했는지도 더 알고 싶어졌다.

2편을 기대하며...​

『소스 코드: 더 비기닝』은 빌 게이츠의 자서전 3부 중 1편에 불과하다. 300페이지쯤 대학에 입학하고, 책의 마지막에서야 겨우 마이크로소프트 창업 이야기가 나온다.

나는 인생의 대부분을 앞날에 집중하면서 살았다. 지금도 대부분의 시간을 수년후에나 이뤄질, 어쩌면 아예 이뤄지지 않을지도 모르는 획기적인 도약을 모색하는 일에 쓰고 있다. 하지만 나이가 들면서 점점 과거를 돌아보게 된 것도 사실이다. 기억들을 하나씩 꿰맞춰 나가는 과정은 나 자신을 더 잘 이해하는 데 도움이 된다. 어른이 되어 깨달은 경이로운 한 가지는 세월과 배움을 모두 걷어내고 보면 나라는 존재의 많은 부분이 이미 처음부터 갖춰져있었음을 알 수 있다는 사실이다. 여러모로 나는 여전히 할머니 댁의 식탁에 앉아 할머니가 패를 돌리길 기다리던 여덟살 짜리 아이와 같다. 정신을 바짝 차리고 모든 것을 이해하게 되길 열망하는 어린 아이가 여전히 내 안에 남아 있다.

책의 초반에 이야기했던 카드 게임이 다시 등장하며 마무리되는데, 빌 게이츠 삶의 1부를 관통하는 키워드는 '배움'이 아닐까 싶었다. 정답은 내 안에 있고, 그것을 계속 발견해 나가는 여정.

그리고 패가 좋든 나쁘든, 잘하면 이길 수 있는 것처럼 내 손에 좋은 패가 있든 나쁜 패가 있든, 그저 열심히 살아봐야겠다.

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

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

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

FAQ​

"뉴로클에서 테크니컬 커뮤니케이터로 일하고 있는 김세원입니다." 라고 자기소개를 하면, 거의 100%의 확률로 돌아오는 질문이 있습니다.

테크니컬??? 커뮤니케이터?? 그게 뭐에요?​

처음에는 저 스스로도 명확하게 대답하기 어려웠습니다. '프런트엔드 개발자'만큼 명확하게 정의할 수 있는 직무도 아니었기 때문입니다.

저희 회사에는 '테크니컬 커뮤니케이터'라는 직무는 없는 직무였는데요. 제가 직무 전환을 희망하며 만들어낸 직무입니다. 직무명 후보로 '테크니컬 라이터, 문서 엔지니어, 테크 에반젤리스트' 등 다양한 명칭이 있었고, 회사와 상의하여 제가 정의한 일과 가장 밀접한 직무명을 골랐어요.

회사에서 하는 일​

테크니컬 커뮤니케이터는 문서를 매개로 기술과 사람을 이어줍니다.

2024년 12월 타운홀 미팅에서 테크니컬 커뮤니케이터로서의 제 역할을 소개했습니다.

1. 외부向: 기술적인 이해도를 기반으로 비개발자, 비전문가도 이해할 수 있는 글 작성
2. 내부向: 개발자 간 기술적 소통을 원활히 하기 위한 문서화

3년 간 프런트엔드 개발자로 일하며 팀의 개발 문서 작성을 많이 해왔습니다. 개발자 시절부터 문서화와 정리의 중요성을 체감했고, 노션 정리를 취미처럼 하면서 테크니컬 라이터가 하는 일의 가치를 어렴풋이 느꼈어요.

암묵지를 형식지로 끌어올리는 일, 즉 머릿속에만 있던 지식을 구조화해 공유하는 일입니다.

머리로만 알고 있던 지식을 글로 정리해두면, 공유할 수 있고, 결과적으로는 조직의 지식 수준을 높여줍니다. 구성원들이 쉽게 지식을 작성하고, 공유할 수 있는 환경을 만들어 주는 것이 테크니컬 라이터의 역할이라고 생각해요. 그리고 이제는, 그 일을 남는 시간에 취미처럼 하는 것이 아니라 메인 직무로 하고 있어요.

꼭 직무 전환을 해야만 했을까?​

직무 전환은 결코 가볍게 내린 결정이 아니었습니다.

2024년 하반기 동안 커리어 방향성에 대해 깊이 고민했습니다. 팀 내 기술적 과제들이 더 이상 흥미롭지 않았고, 트렌드를 쫓는 일도 점점 버겁게 느껴졌어요.
성장하려면 결국 좋아하는 일을 하기보다는 견딜 수 있는 일을 해야한다¹는 말을 책에서 읽고, 생각했어요. 나는 무엇을 견딜 수 있을까?

동료 피드백을 기반으로 '내가 잘 하는 일'을, 지금까지 했던 일을 돌아보며 '내가 좋아하는 일'을 정리했습니다. 그리고 지금 '내가 할 수 있는 일'까지 조합하여 커리어의 방향성을 재 설정했습니다. 이 과정에서 리드와 대표님과도 충분히 상의했고, 그래서인지 주변에서는 “뭐 하는 일인지는 잘 모르겠지만, 왠지 잘할 것 같아!”라며 제게 근거없는 자신감을 심어주기도 했습니다. 😄

미래​

새로운 도전에 응원해주신 분들도 많았지만, ‘개발을 그만두는 것’에 대해 걱정해주는 분들도 계셨습니다.
AI 시대에 글쓰기가 쉽게 대체되는 일이 아니냐는 우려도 있었죠.

하지만 저는 테크니컬 커뮤니케이터라는 역할이 단순히 문서를 작성하는 것 이상이라고 생각합니다.
개발 경험을 바탕으로 디지털 문서 환경을 설계하고 자동화하는 문서 엔지니어링, 비즈니스 이해를 바탕으로 맥락 있는 기술 커뮤니케이션을 설계하는 테크니컬 라이터의 일은 GPT가 쉽게 대체할 수 없는 영역입니다.

그리고 지금은, 개발자라고 해서 AI의 대체 걱정이 없는 시대도 아닙니다.
결국 중요한 건 내가 이 자리에서 만들 수 있는 가치가 무엇인지 고민하며,
저만의 방식으로 테크니컬 커뮤니케이터라는 직무를 구체화하고 성장시켜나가는 일이라고 생각합니다.

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

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

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

프로페셔널 프로그래머가 되려면?​

코드 작성을 잘한다고, 특정 기술을 잘 안다고해서 전문가가 되는 것은 아니다. 개발자는 소프트웨어를 만들어 고객에게 제공하는 사람이고, 소프트웨어 제작뿐만 아니라 운영까지 잘 해야한다.

디버깅을 잘 해야 프로!​

소프트웨어 운영의 큰 부분 중 하나는 '디버깅'이라고 생각한다. 버그가 리포트되면, 빠르게 문제를 파악하고 해결해야 한다. 그러나 나는 디버깅을 잘 못한다. 에러 문의가 들어오면 긴장감에 심장이 두근두근 거리고, 허둥지둥 헤매기 일쑤였다. 나에게 있어서 전문가로 거듭나기 위해서 넘어야 할 큰 산은 디버깅이었다.

디버깅 마인드셋​

인프콘 강연의 핵심은 다음과 같다.

디버깅 실력을 향상시키기 위해서는 
무작정 코드에 뛰어들 것이 아니라(시간을 투자하는 것이 아니라) 
키보드에서 손을 떼고 생각해보는 시간(의도적인 훈련)이 필요하다. 

그렇다면 나는 왜 디버깅을 못할까?​

강의를 듣다보니 내가 디버깅 마인드셋이 없었다는 사실을 깨달았다. 디버깅을 잘 못하는 이유는 다음과 같다.

1. 문제 정의를 하지 않는다.

   일단 해당 문제가 발생한 코드로 가서 무작정 console.log를 찍어가며 문제를 파악할 때가 많았다.

2. 코드를 수정하면서 문제를 파악한다.

   코드를 직접 수정하면서 문제를 구체화하는데 운이 좋으면 빨리 해결할 수 있었지만 운이 나쁘면 하루종일 고생하기도 했다.

3. 디버깅 도구를 제대로 활용하지 않는다.

   js에도 debugger가 있는데 절대 활용하지 않았다.

알고리즘 문제를 풀 때에도 무조건 코드를 작성하려고 하지말고 생각을 먼저 해봐야한다.
그런데 나는 알고리즘 문제를 풀 때에도, 디버깅을 할 때에도 침착하게 앉아서 상황을 살펴보고, 깊이 생각해보는 과정이 전혀 없었던 것 같다. 문제 정의가 없으니 정상 동작에 대한 정의도 매우 단편적이고, 때로는 그런 해결이 사이드이펙트를 유발하기도 했다.

디버깅 과정 시각화

디버깅 고수 따라잡기​

회사 동료들과 인프런 영상을 함께 보고 이야기를 나눴던 내용이다. 디버깅을 잘한다고 생각했던 분은 대략 위의 과정을 거치셨고, 그 중에서도 '사이드이펙트 조사'가 정말 중요하다고 말씀해주셨다. 처음 발견했던 단편적인 문제가 해결되었다고 끝이 아닌 것이다. 특히, 이 과정에 대해 회귀 테스트를 작성해놓으면 큰 도움이 되는 것 같다.

이 일련의 과정을 실천하기 위해서 디버깅 노트 템플릿을 만들어보았다. < src=/en/assets/images/note1-16c15cc6c38469e7049bf2cc2b4b26f2.jpg description="디버깅 노트 템플릿" />

먼저 목표 시간을 정하고, 주어진 시간동안 무엇을 할 건지 목표를 세운다. 그 다음 내 생각을 노트에 적고, 정해진 시간이 되면 짧은 회고를 작성한다.

할 수 있다! 디버깅 YES I CAN!​

실제로 이 노트 템플릿대로 디버깅을 해보았는데 생각보다 효과가 좋았다.

나의 첫 디버깅 노트

버그를 재현해보며 특이 동선을 발견했고, 그 동선에서 힌트를 얻어서 원인이 RTK Listener에서 업데이트 해주는 부분이라는 것을 발견했다. 평소 디버깅을 생각하면 머리가 깜깜해지고, 어느 순간 길을 잃는데 이 템플릿에 맞춰서 생각하니 그 과정들이 정리가되는 느낌이라 좋았다.

바로 훈련의 효과가 나타나는 건가...? 싶었다. 문제를 구체화 해보는 것에 대해서 긍정적인 경험이어서 앞으로도 이 템플릿을 활용해보려고 한다. 다음 버그 드루와

노트 없이도 자연스럽게 디버깅 마인드 셋을 갖추는 그날까지...!

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

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

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

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

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

모든 게 중요해지면 결국 아무것도 중요하지 않게 된다​

문서가 쌓이면서 검색이 어려워지고, 최신 문서와 오래된 문서가 제대로 정리되지 않아 어떤 정보가 신뢰할 만한지 파악하기도 어려웠습니다.

코드는 계속 변경되는데 문서가 그 속도를 쫓아가지 못하면 그 문서는 더 이상 유용하지 않게 됩니다. 문서도 프로젝트 코드처럼 계속 관리해주어야 하는데 그러지 않으면 어느 순간 정리에 엄두가 안 날 정도로 문서가 쌓이게 되더라고요.

영원히 끝나지 않는 문서​

회사에서는 문서 작성에 할애할 시간이 부족하기도 합니다. 기능 구현할 것은 많고, 코드 리뷰도 해야 하고, 회의 준비도 해야 하고, 면접에도 들어가야 하고,... 문서 작성은 항상 우선순위가 낮아질 수밖에요.

충격. 2년째 작성 중인 문서, 실존!

어떤 문서는 영원히 완성되지 않기도 합니다.

어떤 기준으로 문서를 작성해야 할까?​

📝 문서화가 필요한 경우​

1. 코드와 관련 없는 정보 : 팀 소개나 회고, 회의록 등 코드와 직접적인 연관이 없는 문서는 노션이 적합합니다.
2. 최신화가 필요 없는 정보 : 기술 소개 문서처럼 한 번 작성해 놓고 동료들과 공유해야 하는 경우, 문서를 작성해 두면 좋습니다. 기술 결정 사항(당시 기술을 선택한 이유, 장단점, 논의 사항) 같은 정보도 코드 주석에 구구절절 설명하기에는 길어지는 경향이 있기 때문에 github의 issue나 discussion 기능을 활용해 기록해 놓고 코드 주석에 url만 첨부하는 방식도 좋았습니다.
3. 비정기적이지만 반복되는 업무 : 개발환경 세팅방법 같은 경우, 정기적으로 하는 업무는 아니지만 가끔씩 할 때 참고할 수 있는 문서가 있으면 좋습니다.
4. 코드만으로 전달이 어려운 개념 : 도메인 지식이나 제품의 특성에 대한 설명, 까다롭게 구현된 코드의 비하인드 등 코드만으로 이해하기 어려운 정보는 문서화가 필요합니다.

문서를 작성하기 전에 문서화가 필요한 정보인지 아닌지 파악이 어렵다면 인수인계 관점으로 생각해 보세요!

• 신규 입사자가 들어왔을 때, 이 문서를 보고 업무를 진행할 수 있을까?

• 내가 팀에 없을 때 코드만 보고 다른 사람이 문맥을 파악할 수 있을까?

• 이 문서는 내가 아니어도 유지보수가 가능한가?

🗑️ 문서화가 필요하지 않은 경우​

1. 자주 바뀌는 정보 : 코드 구성, UI 세부사항 등에 대한 정보는 굳이 노션으로 작성할 필요가 없습니다. 코드가 변경될 때마다 문서도 함께 변경해 줄 것이 아니라면 작성하지 않거나, 가능한 코드와 가까운 곳(ex. 주석)에 정보를 기록하세요. 이런 정보에 대해 문서화가 필요하다면 자동화가 가능한지를 우선적으로 살펴보는 것이 좋습니다. API 문서는 Swagger, ReDoc과 같은 도구를 활용해 자동 생성하면 코드 변경을 즉각적으로 반영할 수 있어 문서의 신뢰도를 높여줍니다.
2. 자동화 도구를 활용할 수 있는 경우 : 컨벤션은 문서로 서술하는 것보다 Prettier, ESLint 같은 도구를 활용해 강제하는 것이 더 효과적입니다. 코드를 작성할 때마다 매번 컨벤션 문서를 참조하지 않아도 되고, 도구를 적용하면 휴먼 에러가 줄어들기 때문입니다. 규칙을 정할 때에도 자동화할 수 있는지 고려해 보세요.
3. 코드로 전달할 수 있는 정보 : 함수명이나 변수명이 충분히 명시적이어서 코드만으로도 의도를 전달할 수 있다면 문서화하지 않습니다.

사실 대부분의 문서는 필요 없다고 생각합니다. 유지보수를 제대로 하지 못해 잘못된 정보를 담고 있거나 애초에 완성되지 못한 문서는 있느니만 못하거든요.

문서만큼은 미니멀리즘!​

문서는 개발을 거들 뿐, 문서를 위한 문서를 만드는 것은 피해야합니다.

• 필요없는 문서는 삭제하고
• 문서의 목적과 예상 독자를 생각하고
• 가능하면 코드 변경을 즉각 반영할 수 있도록 하고 (자동화 할 수 있다면 자동화)
• 정기적으로 유지보수 하고
• 가능하면 코드만으로 의도를 명확히 전달할 수 있도록 노력합시다.

이제는 '문서화 언젠가는 꼭 해야하는데...'라는 부채감에서 벗어나 '필요한 문서만 최소한으로 유지'하는 방향으로 전환할 때입니다. 문서는 많을수록 좋은 것이 아니라, 필요한 만큼, 정확한 정보를 담고 있을 때 가치가 있습니다.

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

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

코드만 잘 짜서는 안된다​

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

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

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

개발자 === 컴퓨터 ?

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

알아서 착하자​

IT업계 특유의 독성 말투도 사회성 결여의 결과물이라고 생각한다. "악의는 없다. 경제적으로 커뮤니케이션 하는 것일 뿐이다. 받아들이는 사람이 너무 감성적이라 그렇다. F인 사람들이랑은 협업하기 힘들다." 와 같은 변명이 지금까지는 통해왔던 것 같다.

지적 능력이 뛰어난 프로그래머들의 성과를 구분하는 것은 사회적 능력입니다.

사회성도 프로그래머의 능력에 포함된다면 일잘러가 되기 위해서는 알아서 착해야 할 것이다.

때론 비논리적일 수도 있다​

가장 와닿았던 문장은 남을 설득하기 위해 논리성과 객관성을 버리라는 것이었다. 나도 회사에서 협업을 하고, 종종 남을 설득해 보며 몸소 체험한 인사이트를 잘 정리된 문장으로 보니 굉장히 공감이 갔다.

남을 설득하려면 논리성과 객관성에 대한 환상을 버려야 합니다. 그래야 현실적으로 설득이 가능합니다. 내가 설득하고 싶은 상대를 자주 만나서 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명 방식을 선호하는지 이해해야 합니다. 출발은 결국 내가 설득하려는 사람에게서 하는 것입니다. 자료에서 출발하는 것이 아닙니다.

비단 개발자만이 아니라 다른 직종의 사람들도 하는 실수다. 어떤 방법론이 정말 훌륭하고, 도입만 하면 문제를 해결할 수 있는데 왜 사람들이 안 따라 줄까? 사람들이 너무 수동적이고 보수적이라서, 내가 자료를 더 그럴싸하게 만들지 못해서 그런 것이 아니다. 아직 듣는 사람의 마음이 열리지 않았고, 아직 그만큼의 신뢰를 쌓지 못했기 때문이다.

부부간의 문제, 부모 자녀 간의 문제를 다루는 예능 같은 걸 보면 서로 신뢰가 바닥인 상태에서는 전문가가 어떤 솔루션을 내려도 통하지 않는다. 가장 먼저 해야 할 건 상대방을 믿어주는 것이었다.

그래서 사회성을 키우는 과정(사람을 대하는 것)은 때론 비논리적이고, 불가해할 수 있다.

나는 공원의 나무? 숲의 나무?​

공원의 나무는 숲 속의 나무에 비해서 키가 작은 편이다. 우리 집 앞의 작은 공원의 나무보다 도쿄 신주쿠 쿄엔의 나무가 훨씬 크게 자라기도 하고, 관악산의 나무보다 유럽 숲 속의 나무가 크게 자란다.

어느 정도 높이까지↗︎ 자라는 것보다 더 중요한 건 내가 속한 환경이 마음에 드는지일 것 같다. 집 앞의 공원으로 만족할 수 도 있고, 아마존의 울창한 밀림정도 되야 만족할 수도 있다. 내가 어디서 자라고 싶은지 먼저 생각해보면 얼마나 자랄 수 있을지 가늠이 갈지도 모른다. 어디에서 누구와 함께 자라고 싶은가?

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

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

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

규칙을 지키려면 시스템을 만들어야한다.​

올해 4분기에는 프런트엔드 채용 면접에 참여하면서 다양한 개발자들을 만났다. 가지각색의 개성이 있는 분들이었는데 개중에는 '문서화'를 중요하게 생각하는 분들도 있었다. 팀으로 프로젝트를 진행할 때, 본인이 좀 더 시간을 투자해서 꼼꼼하게 주석을 달거나 문서화를 한다는 분이 계셨는데 그 얘기를 들으며 지속가능성이 떨어진다는 생각이 들었다.

나도 입사 초반에는 주석도 달고, 노션에도 남기고, 엑셀에도 기록하는 등 문서화에 신경을 썼었지만 입사 후 3년이 지나 되돌아보니 최신화되지 않은 문서가 너무나 많았다. 코드를 작성하는 속도가 문서화 속도보다 빠르고, 모든 구성원이 문서화'만' 담당하는 것이 아니기 때문에 필연적으로 그렇게 될 수 밖에 없는 것 같다.

코드를 작성하면 문서를 꼭 작성하자는 규칙은 쉽게 지키기 어렵다. 그래서 노션으로 줄줄 설명하는 문서보다는 테스트 코드를 작성해 테스트 케이스에 명세를 기술하고, 테스트를 통해 코드와 문서간의 간극을 줄이는 시스템을 도입했다.

가독성 있고, 일관된 코드 스타일을 유지하기 위해 prettier와 eslint를 사용하는 것처럼 문서와 코드 사이의 차이를 줄이기 위해서는 규칙을 정하는 게 아니라 자동화된 시스템을 만들어야한다.

성장은 책임에서부터​

WITH GREAT POWER THERE MUST ALSO COME GREAT RESPONSIBILITY

큰 힘에는 큰 책임이 따른다

상반기에 3년간 함께했던 백엔드 팀의 리드분이 퇴사하셨다. 나와 같은 나이고, 같은 회사에서 커리어를 시작하셨는데 어느 순간부터 엄청나게 성장하셔서 회사에서 중요한 역할을 하고 계셨기에 기억이 남는다. 그 분이 해주셨던 이야기 중 하나가 "어떤 일에 내가 책임지고 해결한다는 태도를 가져보세요"였다. 그 분도 리드 역할을 맡으면서 책임지는 태도를 장착하셨고, 죽이되든 밥이되든 내가 책임지고 해결한다는 마인드로 일하셨기 때문에 그만큼 단기간에 성장하셨던 것이다. 이 분 한 명만의 이야기가 아니다. 회사에서 만난 분들 중 '이 사람처럼 일하고 싶다. 이 사람 처럼 성장하고 싶다.'라는 생각이 드는 사람들은 다들 이렇게 일하고 계셨다.

성장은 무슨 강의를 듣고, 어떤 컨퍼런스에 가고, 얼마나 많은 책을 읽는지에서 오는 것이 아니라 책임지는 태도에서부터 시작하는 것 같다.

Compile 2025​

코드를 실행하기 전에 컴파일을 해야한다. 컴파일 과정에서 타입 체크도 하고, 에러를 잡아내기도 한다. 2025년을 'run' 하기 전에 컴파일 과정을 거쳐보자.

Type Check​

나의 성격과 가치관이 추구하는 목표와 잘 맞는지 점검

2022년 회사에서 발표한 자기소개 내용

2022년 회사에서 발표한 자기소개 내용 중 한 페이지이다. 2024년 회사 송년회에서 '테크니컬 커뮤니케이터'로서 직무전환을 알리는 발표에서 '내가 잘 할 수 있고, 남들에게도 필요한 일'을 하고 싶어서 직무 전환을 결심했다고 이야기했었는데 그 이후 회사 동료분께 메세지를 하나 받았다. "예나 지금이나 세원님께서 뉴로클에서 하고 싶은 일이 동일한 게 신기하다"며 앞으로도 응원한다는 내용의 따듯한 응원의 메세지를 보내주셨는데 나도 잊고 있던 발표자료라 놀랐다.

2024년 상반기까지 내가 하고 싶은 것과 잘 할 수 있는 것, 잘 해내야하는 것들이 잘 안맞아서 고민의 시간을 가졌는데 그게 아마 'type error' 표시였던 것 같다ㅋㅋ! 테크니컬 커뮤니케이터로 직무를 전환하며 큰 방향의 타입은 어느정도 맞추지 않았을까 싶다.

Optimization​

개선하지 않아도 살 수는 있지만 개선하면 좋을 습관 점검

올해 초, ⎡인생샷 뒤의 여자들⎦이라는 책을 읽고 인스타그램을 완전히 지웠다. 약 10년만에 인스타그램에서 자유로워진 것이다!

나의 집중력을 도둑맞지 않기 위한 결정이었는데, 아직도 개선해야할 집중력 도둑 습관들이 남아있어서 2025년에는 이런 습관들을 개선하고 싶다.

A라는 일을 하려고 브라우저를 켜면 눈에 B, C, D가 들어와서 링크를 타고 타고 웹의 세계에 부유하다 보면 어느 순간 A는 까맣게 잊혀진다. 불과 어제도 이런 순간을 겪었고, 앞으로 다른 분들과 접점이 많아질 예정이라 개선이 시급하다.

Dependency Check​

삶에서 의존하고 있는 것, 불필요하게 의존하는 것 점검

사용하지 않거나 기존 코드와 충돌하는 의존성 라이브러리는 제거해야한다.

더 이상 만나지 않거나 내 삶을 어지럽게 하는 사람들과의 관계도 한번쯤 점검해봐야한다. 그런 관계중에 나와 가장 많이 부딪치고, 나를 힘들게 하지만 떼어내기 힘든 관계는 바로 '가족'이다. 2024년에는 금전적으로 좀 해결해보려고 시도해봤으나 안 맞는 건 어쩔 수 없는 것 같다... 최대한 빨리 물리적으로 떨어지는 것을 목표로 해야겠다.

그리고 회사 동료들에게도 상당부분 의존하고 있는 것 같다. 24년에는 유독 제품팀 분들의 퇴사가 많았는데 특히 리드를 맡았던 분들이 떠날 때에는 나도 덩달아 흔들렸다. 나는 혼자서도 잘 하고 있다고 생각했었는데 알게 모르게 사람에게 의지하고 있었고, 그 분들의 퇴사를 계기로 주변 사람들에게 좀 더 감사하고 잘 하자는 마음을 먹었다. 사내에서 또 하나 목표하고 있는 게 있다면 나도 의존할만한 사람이 되는 것이다. 서로 의지하면서 위기에 더 단단해지는 팀, 회사를 만들고 싶다.

회고의 추상화​

2024년 회고는 이전과는 템플릿을 조금 달리해보았다. 사실 작년 회고처럼 썼다가 다 갈아엎었다.
회고란 결국 지난 1년을 통해서 유의미한 '인사이트'를 뽑아내야한다고 생각했기 때문이다. 올해는 사건 나열식 회고글이 아닌 깨달음과 그 깨달음에 영향을 준 사건들을 위주로 2024년을 추상화해보았다.

개발의 재미있는 점은 인생에 비유해도 찰떡같이 들어맞는다는 것. 프로그램을 만드는 방법을 배운 것이 아니라 인생을 살아가는 데 도움이 되는 멘탈 모델을 배운 것인지도 모른다. 직무는 전환하지만 개발을 놓지 않기를 바라며 2025년을 실행해본다.

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

글또에서 책 읽기​

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

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

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

리눅스와의 재회​

학부생 시절, 리눅스의 명령어를 달달외워 시험보는 과목이 있었다. 그땐 운영체제에 대한 이해 없이 시험을 위해 CLI 명령어를 외웠다보니, 리눅스에 대한 첫인상은 부정적이었다. 검정색 프롬프트에 대한 궁금증과 두려움을 갖고 있었기 때문에 공부를 미뤄왔는데 책 첫 페이지의 베타 학습단 후기를 보면서 용기를 얻을 수 있었다.

단순하게 명령어를 외우고 리눅스 사용법을 익히는 책이 아니라, 운영체제에 대해 잘 모르는 사람도 운영체제를 이해하고 리눅스라는 새로운 운영체제를 배울 수 있도록 설명에 공을 들였습니다. - 베타 학습단 후기 중

명령어를 전부 외우는 것이 목적이 아니라 리눅스를 매개로 운영체제에 대한 이해를 높이는데 좋겠다는 생각이 들었고, 실제로 책을 읽으면서도 컴퓨터에 대한 이해도가 높아지는 것을 느꼈다.

아이폰 북; 스콧 켈비, 테리화이트 저. 에이콘 출판. 2009

마치 스마트폰을 처음 사용하시는 노인 분들이 스마트폰 사용법을 책으로 배우는 느낌이 들었는데, 명령어 입력 방법/파일 여는 방법/파일 삭제 방법 등 기본적인 컴퓨터 사용법을 다시 배우는 것 같았다. 새로운 문물이 아닌 몇 십년 전 과거의 컴퓨터 사용법을 배우고 있다니...

좋아! 이걸로 편하게 움직일 수 있겠어!

나루토의 록리가 수련을 위해서 일부러 무거운 모래주머니를 차고 있었던 것처럼, 나도 컴퓨터를 더 잘 다루기 위해 마우스 사용을 제한하는 기분이 들기도 했다.

책의 구성​

일단 책은 2개의 파트로 나뉘어져 있다. 파트 1에서는 리눅스에 대한 이해를, 그리고 파트 2에서는 리눅스를 활용하는 법을 상세히 다루는데 단순히 명령어를 달달 외우는 식으로 배웠던 대학 수업과 비교했을 때 나에게 훨씬 잘 맞는 구성이었던 것 같다.

일단 목차만 봐도 책이 다루는 내용이 대략 어떤 것인지 파악할 수 있어서 너무 좋았고, 흐름이 명확해서 많은 양에 압도당하지 않고 읽어낼 수 있었다고 생각한다.

그리고 단순 명령어 설명도 지루하게 풀어내는 것이 아니라 설명이 매우 잘 쓰여있어서 읽으면서 감탄했던 기억이 있다. 대학생 때, 이런 책이 있었다면 수업이 좀 더 즐거웠을지도 모르겠다.

sudo 가 이런 역할이었구나?!​

개발 환경을 구성하거나 할 때, 생각없이 복사했던 명령어들이 이제는 무슨 역할을 하는지 알게 되었다. apt 명령어는 아파트가 아니라 'Advanced Packaging Tool'의 약자로, 리눅스 배포판의 패키지 관리 시스템이고, curl과 같은 패키지를 다운로드 받을 수 있게 한다.

sudo 명령어는 'super user do'의 줄임말로, 일반 사용자가 root 권한을 가진 사용자로 명령을 실행할 수 있게 해주는 명령어인데 작업하다가 뭐 문제가 생겨서 검색해보면 항상 sudo 명령을 사용한 명령어를 쳤던 기억이 난다. 이게 어떤 의미인지 제대로 몰랐는데, 리눅스의 파일 시스템과 유저 시스템, 사용자 권한 시스템을 이해하니 어떤 명령어인지 확 와닿아서 좋았다. sudo외에도 root 사용자 권한을 주는 방법으로 su 명령어와 runuser 명령어도 있다는 것을 알게 되었다.

명령어의 나열 형식으로 되어있었다면 금방 지루해졌을텐데 이 명령어들을 사용한 예제가 함께 있어서 끝까지 흥미를 잃지 않고 읽을 수 있었고, 이해에도 도움이 되었다. 그리고 각 장의 마지막에는 '요약'과 '연습문제'가 있어서 읽은 내용을 다시 한번 정리하고 복습한 것도 좋았다. 한 장에 적혀있는 수 많은 정보중에서 내가 꼭 기억해야할 중요한 정보들이 무엇인지 요약해서 알려주는 것 같아서 나중에 복습할 땐 이 요약과 연습문제만 훑어보면 될 것 같다!

이러다 코딩 천재...?​

처음엔 두려움 반, 궁금증 반으로 읽기 시작했던 책인데 책을 덮을 때쯤에는 표지의 이미지처럼 '이러다 코딩 천재...?'하는 욕심도 슬쩍 생겼다. 누가 그렸는지는 몰라도 진짜 잘 그린 것 같다ㅋㅋㅋ!

중간에 Bash 명령어가 나오는 부분에서는 'Bash 문법도 JS만큼이나 근본없구나... 이걸 누가쓰지..?' 싶은 생각이 들었는데 이제 리눅스에 대한 두려움은 다 떨쳐버렸으니 명령어도 직접 쳐보고 실전에 적용해보면서 익히는 시간을 가지면 좋을 것 같다.

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

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

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

예를들면 이런식...

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

역사적인 첫 PR🥳

PR template​

## 작업내역

<!-- 작업내역을 작성해주세요. -->

## 이슈

<!-- 이슈 사항을 작성해주세요. -->

## 고민

<!-- 코드리뷰 시 같이 고민해 봐야 할 사항을 작성해주세요. -->

🎯[Jira](https://)

제가 처음 약식으로 작성한 템플릿인데요. 이 템플릿은 신규 입사자분들이 들어오실 때마다 수정을 거쳐 지금의 형태를 갖추게되었습니다. 약 3년동안 PR템플릿도 이렇게나 발전했네요!

<!-- PR 컨벤션 https://www.notion.so/ -->

# Info

- 관련 문서 : []()
- Jira Ticket : [NRT-](https://)
- 필수 리뷰어 : @
- BE branch : master

# Changes

## 변경 타입

<!-- PR이 어떤 유형의 작업인지 작성자/리뷰어가 한 눈에 파악할 수 있도록 타입을 선택해주세요. -->
<!-- 복수 선택도 가능하지만 PR 크기가 충분히 작지 않다는 의미일 수 있습니다. 한 번 더 검토해주세요! -->

- [ ] 버그 수정
- [ ] 기능 추가
- [ ] 리팩토링
- [ ] 개발 환경 설정
- [ ] 문서 업데이트
- [ ] 테스트 코드 추가
- [ ] 기타 (아래에 설명해주세요)

기타 설명:

### 주요 변경 사항

<!-- 새로 추가된 기능, 수정된 버그, 리팩토링 내용 등 변경 사항을 작성해주세요. -->

## 스크린샷(optional)

<!-- 작업 전후 비교 등의 스크린샷이 있으면 변경사항을 파악하기 수월해집니다. -->
<!-- 이미지를 Drag & Drop 하면 추가됩니다. -->

## 체크포인트

<!-- 해당 PR에서 중점적으로 봐주셨으면 하는 것들을 작성해주세요. -->
<!-- 이 PR이 영향을 미치는 다른 부분이나 기능이 있다면 명시해주세요. -->

# PR Checklist

- [ ] 1. 내 컴퓨터 환경에서 잘 동작함.
- [ ] 2. 브라우저 개발자 도구의 console.log 에러를 확인함.
- [ ] 3. 코드 내의 불필요한 eslint disabled 처리가 없음.
- [ ] 4. 코드 내의 오타가 없음.
- [ ] 5. 새로운 기능에 대한 단위 테스트를 작성하고 실행함.

<!-- 올린 PR은 제일 먼저 스스로 확인해보고 셀프 리뷰를 남겨보세요. -->
<!-- Label 지정 부탁드립니다~! -->

우선, 해당 룰을 세팅하게 된 논의 과정을 기록해 놓은 노션 문서를 주석에 링크하여 논의에 참석하지 않은 분들도 히스토리를 파악할 수 있게 해놓았습니다. PR을 되도록이면 작은 크기로 가져가자는 의미에서 하나의 PR에는 하나의 변경사항만 담겨있는지 인지하기 위한 체크박스를 추가했어요. 그리고 PR을 오픈하기 전에 체크리스트의 항목들을 확인해서 혹여나 놓치는 부분이 없도록 해두었어요. 코드 리뷰 문화를 정착시키기 위해서 코드 리뷰에 들어가는 오버헤드를 줄여야 했고, 최대한 리뷰어를 배려하는 형태로 발전되었습니다.

commitizen​

제가 입사하면서 팀의 컨벤션을 하나하나 다시 세팅하기 시작했는데요. 컨벤션의 핵심은 자동화라는 것을 이때 처음 깨달았던 것 같습니다. 열심히 논의해서 10개의 컨벤션을 정했는데, 자동화가 되지 않으면 이걸 다 기억하기도 힘들고 매번 지적하고 고치는 작업도 쉬운 일이 아니었어요.

그래서 커밋할 때에는 컨벤션 도입의 비용을 줄이고, 통일성을 맞추기 위해 자동화 라이브러리 commitizen을 활용했습니다. commitizen을 글로벌로 설치하여 사용할 수도 있지만, 프로젝트에 설치하여 저희만의 커밋 컨벤션을 적용했어요.

const custom = require("@digitalroute/cz-conventional-changelog-for-jira/configurable");

module.exports = custom({
  jiraMode: true,
  maxHeaderWidth: 64,
  maxLineWidth: 100,
  jiraPrefix: "NRT",
  skipScope: true,
  types: {
    feat: {
      description: "로직 추가, 변경, 삭제 등의 기능 작업",
      title: "feat",
    },
    refact: {
      description: "동작은 동일하나 내부 로직이 변경된 리팩토링",
      title: "refact",
    },
    bugfix: {
      description: "의도된 동작과 다르게 구현된 버그 수정",
      title: "bugfix",
    },
    typo: {
      description: "오타 수정, 번역, 주석 추가 등 로직과는 무관한 타이핑 작업",
      title: "typo",
    },
    style: {
      description: "로직이 아닌 스타일 변경",
      title: "style",
    },
    test: {
      description: "테스트코드 작성",
      title: "test",
    },
    chore: {
      description: "그 외 작업",
      title: "chore",
    },
  },
});

title과 그에따른 description을 설정하여 feat과 refact의 차이를 일일이 기억할 필요가 없도록 했고, jiraMode를 true로 설정하여 JIRA 이슈와 연동할 때 대소문자에 신경 쓰지 않도록 했습니다.

실제 사용 예시

커밋 명령어를 작성하면 위와 같이 커스터마이징한 커밋 메세지를 볼 수 있습니다.

좋은 개발 문화를 위한 1보👣​

문서화의 중요성을 가장 크게 느끼는 지점은 프로젝트에 새로 합류한 팀원이 있을 때가 아닌가 싶은데요. 제가 당시 신규 입사자의 입장이어서 더 크게 느꼈던 것 같습니다.

돌아보니 좋은 개발 문화에 타인을 배려한 이런 작업들도 중요한 부분이라는 생각이 드네요. 제가 생각하는 좋은 개발 문화를 주도적으로 도입한 경험은 지금도 회사에서 일할 때 좋은 영향을 미치는 것 같습니다.

노래를 듣다가 별안간 문서화의 중요성을 상기하게 되네요.

수고했어 PR~ 고생했지 나의 PR~ 🎶

CSS의 작동방식​

CSS는 주로 inline, internal, external 세 가지 방식으로 작성할 수 있습니다.

inline CSS​

<p style="color: blue; font-size: 16px;">이 문장은 파란색과 16px 크기입니다.</p>

태그의 style 속성에 직접 CSS를 작성하는 방식입니다.

장점​

• 간단한 적용
• 별도의 CSS 파일이 필요 없음: CSS 파일을 추가로 로드할 필요가 없어서, 네트워크 요청을 줄여 초기 로딩 시간을 약간 단축할 수도 있습니다.
• 특정 요소에 스타일 우선순위 제공: 인라인 스타일은 CSS 규칙 중에서 최우선으로 적용됩니다. 외부 스타일시트에서 스타일이 덮어씌워지는 문제를 방지할 수 있습니다.

단점​

• 재사용성이 떨어짐
• 유지보수가 어려움: 스타일을 한 곳에서 관리하기 어려워 일회성으로 사용되는 경우가 아니라면 권장하지 않습니다.

internal CSS​

<head>
  <style>
    p {
      color: green;
      font-size: 18px;
    }
  </style>
</head>
<body>
  <p>이 문장은 녹색과 18px 크기입니다.</p>
</body>

HTML 문서 내부에 <style> 태그를 사용하여 CSS를 작성하는 방식입니다.

장점​

• 가독성: 컴포넌트와 스타일 로직이 분리되어 가독성이 높아집니다.

단점​

• 유지보수가 어려움: 여러 문서에 동일한 스타일을 적용하려면 모든 문서에 동일한 CSS를 작성해야 하므로 유지보수가 어렵습니다.

external CSS(CSS-in-CSS)​

<!-- HTML 파일 -->
<head>
  <link rel="stylesheet" href="styles.css" />
</head>
<body>
  <p>이 문장은 외부 CSS 파일에서 스타일을 적용받습니다.</p>
</body>

/* styles.css 파일 */
p {
  color: red;
  font-size: 20px;
}

별도의 css 파일을 작성하고, link 태그로 HTML 문서에 연결하는 방식입니다.

장점​

• 재사용성: 여러 문서에서 동일한 스타일을 적용할 때 유용합니다.
• 유지보수가 쉬움: 스타일을 한곳에서 관리할 수 있어 유지보수가 쉽습니다.
• 효율성: Sass나 Less와 같은 CSS 전처리기를 사용하면 CSS를 더 효율적으로 작성할 수 있습니다.

CSS 전처리기와 후처리기​

CSS-in-CSS 스타일에서 언급했던 Sass나 Less는 CSS 전처리기 입니다. CSS 전처리기는 변수 선언, 중첩, Mixin, 함수 등의 고급 기능을 사용하여 반복을 줄이고, 가독성을 높여줍니다.

후처리기는 벤더 프리픽스를 추가해주어 크로스 브라우징 문제를 해결해주고, 폴리필을 추가해 구형 브라우저에서도 잘 동작할 수 있도록 해주는 역할을 해요. PostCSS 등이 대표적인 후처리기이고, Autoprefixer와 cssnano 같은 플러그인을 설정하면 CSS 파일을 더 작은 크기로 최적화하고 브라우저 호환성을 높이며, 유지보수와 확장성 또한 강화할 수 있습니다.

https://2024.stateofcss.com

2024년에 가장 많이 사용된 전처리기/후처리기 순위인데요. Sass와 PostCSS의 빈도가 높네요.

전처리기와 후처리기는 언제, 어떻게 동작하는 걸까?​

빌드 시점에 전처리기를 사용하여 Sass나 Less 파일을 CSS 파일로 변환하고, CSSOM이 생성된 이후에 후처리기가 동작합니다.

CSS-in-JS​

앞서 소개한 방식들 중 어떤 방식을 선택하더라도 CSS가 파싱되어 렌더트리가 생성되는데요. CSS를 파싱하는 동안에는 JS의 실행이 차단되기 때문에 CSS 적용 방식이 렌더링 성능에 영향을 미칩니다. CSS-in-JS는 이런 문제를 해결해주는데요. CSS모델을 문서레벨이 아니라 컴포넌트 레벨로 추상화하고, 중복 및 의존성을 줄여 유지보수를 쉽게 합니다. JS코드 내에서 CSS를 작성하고 관리하는 방식으로, Styled components, Emotion 등이 있습니다.

https://2024.stateofcss.com

위 통계에 있는 CSS 모듈은 정확히 말하면 CSS-in-JS 방식은 아닙니다. external CSS 방식과 비교하면, js에서 파일을 import 해서 사용하는 방식¹이기 때문에 통계에 들어간게 아닐까 싶네요. css 모듈은 선택적으로 컴포넌트 className에 스타일 적용이 가능하지만, CSS-in-JS처럼 동적으로 스타일을 적용할 수 없습니다. 아래는 동적으로 스타일을 적용하는 예시입니다.

import styled from "styled-components";

const Button = styled.button`
  background-color: ${(props) => (props.primary ? "blue" : "gray")};
  color: white;
  padding: 10px;
  border: none;
  border-radius: 5px;
`;

장점​

• gloabl namespace를 신경쓸 필요 없음: CSS로 컴파일할 때, 고유이름 생성되기 때문에 클래스 이름 충돌 문제가 없습니다.
• JS와 CSS 상태 공유
• CSS 로드 우선순위 이슈가 없음
• 동적 스타일링: css 문법을 거의 그대로 사용하면서도 스타일링을 동적으로 처리할 수 있습니다. 덕분에 테마 적용도 쉽습니다.
• SSR(서버사이드 렌더링) 최적화: 서버사이드 렌더링을 통해 초기 HTML에 필요한 스타일만 삽입해 사용자에게 빠르게 보여줄 수 있습니다. 초기 로딩 속도를 향상하는 데 이점이 있습니다.

단점​

• 런타임 생성 오버헤드 발생: 런타임에 스타일을 계산하고 생성하는 과정에서 발생하는 오버헤드가 있습니다.
• 번들 크기가 커짐: js 번들의 크기가 커져서 초기 로딩 속도에 영향을 미칠 수 있습니다.
• 브라우저에 캐싱되지 않음: 스타일이 js에서 동적으로 생성되기 때문에 CSS가 캐시되지 않아 동일한 스타일이라도 매번 재생성되는 오버헤드가 발생합니다.

Zero-runtime CSS-in-JS​

제가 처음 Zero-runtime CSS-in-JS를 접한 계기는 Material UI 버전 업그레이드 공지²였습니다. 진행중인 프로젝트의 성능을 최적화 할 수 있는 방법을 찾다가 Zero-runtime CSS-in-JS를 알게 되었어요. Material UI v6에서는 Pigment CSS를 도입해 CSS를 런타임이 아닌 빌드 타임에 추출하는 방식으로 클라이언트 사이드의 재계산을 피하고, 번들 크기를 줄일 수 있다고 합니다.

import { styled } from "@pigment-css/react";

const Heading = styled("div")({
  fontSize: "4rem",
  fontWeight: "bold",
  padding: "10px 0px",
});

function App() {
  return <Heading>Hello</Heading>;
}

장점​

• CSS 파싱 문제 해결: 런타임에 스타일을 생성하는 것이 아니라 빌드 시점에 스타일을 추출하여 정직 CSS파일처럼 사용할 수 있습니다. 이를 통해 불필요한 JS 로딩으로 인한 성능 저하를 방지합니다.
• 낮은 러닝커브:사용법은 styled-components와 비슷합니다. DX적으로는 이점을 유지하면서 성능을 향상시킬 수 있습니다.

단점​

• 빌드 시간 증가
• 개발 환경에서의 어려움: 빌드 타임에 스타일을 생성하기 때문에 테스트를 작성해야한다거나 실험을 해야할 때 어려움이 있을 수 있습니다.

Utility-first CSS​

Utility-first CSS는 HTML 요소에 직접 스타일을 적용하는 방식입니다. 미리 정의된 유틸리티 클래스 text-center, p-2 등을 사용하여 스타일을 적용하고, 대표적인 프레임워크로 tailwindCSS가 있습니다.

<button class="bg-blue-500 text-white px-4 py-2 rounded">Click me</button>

CSS-in-JS와 달리 정적 CSS 클래스 기반으로 스타일을 적용하기 때문에 런타임 오버헤드가 없습니다.

장점​

• 높은 재사용성
• 개발 속도 향상: CSS를 따로 작성할 필요가 없기에 개발속도가 빠릅니다.
• 런타임 오버헤드 없음
• 브라우저 캐싱: 정적 CSS 파일이 브라우저에 캐싱되어 성능이 최적화됩니다.

단점​

• 코드 가독성 저하: 클래스 순서를 일관되게 지키지 않으면 가독성이 떨어질 수 있습니다.
• 러닝커브: 초기 클래스 명명 규칙을 익히는데 시간이 걸릴 수 있습니다.

결론​

전통적 스타일링 방식부터 Utility-first CSS까지 다양한 스타일링 방법을 살펴보았습니다. 겉핥기식이었지만 각 방식의 장단점을 정리할 수 있었습니다. CSS 라이브러리에 대해서는 그냥 유행인 것들을 따라서 써보는 식으로 찍먹해왔는데, 이제는 성능적인 측면을 고려해야겠다는 생각이 들었습니다.

Vim is a highly configurable text editor built to make creating and changing any kind of text very efficient. It is included as "vi" with most UNIX systems and with Apple OS X.¹

Vim은 "Vi IMproved"의 준말로, 원래 UNIX 시스템에서 사용되던 Vi 편집기를 개선한 텍스트 편집기 입니다. 1991년에 v1.14가 처음 공개되었습니다.²

vim 실행 화면

터미널에 vi를 입력하면 Vim이 실행됩니다.

vim을 배우고 싶었던 이유​

출처 https://xkcd.com/378/

어디에선가 vim에 익숙해지면 마우스 없이 모든 명령어를 처리할 수 있고, 생산성이 극대화된다는 말을 들었습니다. 저는 리눅스 환경에 익숙하지 않아서 검은 터미널 화면에 빽빽하게 타이핑하며 개발하는 것에 대한 환상이 있었고, 한 번 배워보고 싶었어요. 그리고 뭔가 '진짜' 개발자처럼 보이잖아요...!

Vimtutor로 시작하기​

터미널에서 vimtutor를 입력하면 Vim에 내장된 튜토리얼을 시작할 수 있습니다.

===============================================================================
=    빔 길잡이 (VIM Tutor) 에 오신 것을 환영합니다    -      Version 1.7      =
===============================================================================

     빔(Vim)은 이 길잡이에서 다 설명할 수 없을 만큼 많은 명령을 가진
     매우 강력한 편집기입니다. 이 길잡이는 빔을 쉽게 전천후 편집기로 사용할
     수 있도록 충분한 명령에 대해 설명하고 있습니다.

     이 길잡이를 떼는 데에는 실습하는 데에 얼마나 시간을 쓰는 가에 따라서
     25-30 분 정도가 걸립니다.

     이 연습에 포함된 명령은 내용을 고칩니다. 이 파일의 복사본을 만들어서
     연습하세요. (vimtutor 를 통해 시작했다면, 이미 복사본을 사용하는
     중입니다.)

     중요한 것은, 이 길잡이가 직접 써보면서 배우도록 고려되어 있다는 것입니다.
     명령을 제대로 익히려면, 직접 실행해보는 것이 필요합니다. 내용을 읽는
     것만으로는, 명령을 잊어버리게 될 것입니다.

     자 이제, Caps Lock(Shift-Lock) 키가 눌려있지 않은지 확인해보시고, j 키를
     충분히 눌러서 Lesson 1.1이 화면에 가득 차도록 움직여봅시다.

무려 한국어 튜토리얼이 있어 놀랐습니다! 약 7챕터의 레슨으로 구성되어있고, 한 챕터에는 실습 예시와 요약이 함께 있습니다.

내용은 그렇게 어렵지 않았고 설명에 적혀있는대로 30분 정도면 충분히 학습할 정도의 분량이었어요.

특징​

메모장이나 VSCode 같은 일반 텍스트 편집기와 비교했을 때, 가장 큰 차이점은 모드 기반의 편집입니다. vim 관련 meme을 검색해봤을 때 흔하게 나오는 게 "How do I exit Vim?"이라는 질문인데요, Vim은 Noraml모드, Insert모드, Command모드, Visual모드 등 여러 모드를 가지고 있습니다. 종료하려면 일반모드에서 :q를 입력하면 되는데, GUI가 익숙한 저는 시작부터 적응이 어려웠습니다.

타이핑을 하기 위해서는 i를 눌러 Insert모드로 전환해야 하고, 타이핑한 것을 저장하려면 esc를 눌러 Normal모드로 전환한 후 다시 :를 눌러 Command모드로 전환한 뒤 :wq(저장 후 종료) 같은 명령어를 입력해야 합니다. 그리고 Visual 모드는 마치 마우스로 드래그하는 효과와 같은 기능을 하는데 v를 누르면 커서가 있는 위치부터 텍스트를 선택합니다.

다양한 명령어가 있는데 시험공부 하듯이 외우는 것보다 vimtutor를 통해 직접 사용해보면서 배우는 것이 더 효과적입니다.

vim 사용으로 10x 개발자 되기...?!​

그래서 과연 생산성이 10배 빨라졌을까요...?

vim을 사용해보기로 결심한 후에 FEconf 라이트닝 톡에서 vim을 4년, Neovim을 1년 7개월 간 사용하신 프론트엔드 개발자분의 세션을 들었습니다. 그 분을 보니 vim 사용이 어떤 면에서 좋은지 느낌이 오더라고요. .vimrc 파일을 개인에게 맞게 최적화 해서 테마, 플러그인, 단축키 등을 설정할 수 있는데 개인에게 어떻게 최적화 하는지에 따라서 생산성을 높일 수 있을 것 같았습니다.

조성진님의 '저는 vim을 사용하는 프론트엔드 개발자 입니다.' 세션

위의 사진은 배경화면 투명도를 줄여서 화면 전환 없이 코드 작성하며 결과물을 확인하도록 커스텀한 세팅입니다. 이런식으로 활용할 수 있다는 것이 신박했어요. 그리고 vim은 VSCode와 비교했을 때, 매우 가볍고 컴퓨터 리소스를 적게 사용하기 때문에 vim 사용으로 절약한 리소스로 로컬 LLM을 돌리는 등 컴퓨터 자원을 조금 더 효율적으로 사용할 수 있습니다.

이외에도 vim 사용에 익숙해지면 어느 OS 환경에서든 써먹을 수 있고, 손을 많이 움직일 필요없이 빠르게 작업할 수 있다는 장점이 있습니다. 여러모로 극한의 상황에서 개발을 할 때 유용할 것 같다는 생각이 들었습니다.

Vim 정복에 실패한 개발자의 솔직한 고백​

글의 제목에 :q!를 적어놓은 이유는... Vim에 입문하자마자 강제 종료 해버렸다는 것을 표현하고 싶었습니다😅 vimtutor를 통해 기본적인 명령어를 익히고, 블로그 포스팅 할 때 사용중인 zed 에디터를 vim 모드로 설정해서 사용하는 중인데요. 매일 사용하는 게 아니면 금방 잊어버려서 매번 명령어를 검색해야하는 번거로움을 겪고 있습니다. 이걸로 개발하려면 한동안은 생산성은 오히려 저하되겠더라구요.

엄청나게 많은 명령어들을 체화하고 익숙해질 자신이 없었습니다. 컴퓨터 리소스가 그렇게 아까운 환경도 아니고, 상당히 부지런한 성격이라 vim을 정복해서 효율성을 극대화 하겠다는 그런 간절함도 별로 없었던 게 vim과 다시 데면데면해진 주된 원인인 것 같아요.

같이 일하던 동료분 중에 엑셀 초고수 동료분이 있었는데 군대에서 행정업무를 하던 시절 온갖 단축키를 외운 것이 비결이라고 하시더라구요. 제가 Vim에 적응하려면 입대정도는 해야... 되지 않을까? 하는 생각이 들었습니다.

그놈의 진짜 개발자

웃자고 넣은 이미지인데, 제 마음속 한 구석에는 '진짜' 개발자 처럼 보이고 싶은 욕망이 있었던 것 같습니다. 나에게 맞게 최적화하고, 극한의 효율을 추구하는 그런 능력을 조금 더 키워보고 싶었었나봐요. 몇 달동안 묵혀두었던 Vim에 대한 글을 쓰게 되었는데요. 글을 쓰면서 어떤 기술을 사용하지 않는다고 스스로를 진짜가 아니라고 생각할 필요는 없다고 느꼈습니다. 오늘을 기점으로 Vim에 적응하지 못했다는 것을 시원하게 인정하고, 제 마음속의 짐을 내려놓아보려구요!

어느 날 아침 문득, 정말이지 맹세코 아무런 계시나 암시도 없었는데 불현듯, 잠에서 깨어나는 순간 나는 이렇게 부르짖었다. "그래, 이렇게 살아서는 안 돼! 내 인생에 나의 온 생애를 다 걸어야 해. 꼭 그래야만 해!"

모순, 양귀자

요 근래에 정말 재미있게 읽었던 소설의 첫 문장입니다. 글또 10기 OT가 끝나고 문득, 정말이지 맹세코 아무런 계시나 암시도 없었는데 불현듯, '그래, 이렇게 살아서는 안 돼! 내 인생에 나의 온 생애를 다 걸어야 해. 꼭 그래야만 해!'라고 생각했어요. (부르짖지는 않았음...)

처음 개발자를 꿈꾼지 5년이 지났고, 프런트엔드 개발자로 봉급을 받은지 3년이라는 시간이 지났습니다. 사랑의 유효기간은 900일¹이라고 하죠? 요즘은 어쩐지 프로그래머로서의 열정도 사라지고, 커리어 권태기가 온 것 같아요. 그래서 '글또 10기 시작'이라는 핑계로 제 프로그래밍 인생에 저의 온 생애를 다 걸어보자는 비장한 다짐을 해보려고 합니다. 글또는 어쩌면 프로그래머로서 열심히 살아보기 위한 수단일지도 모르겠네요😁

글또 10기에 이루고 싶은 것​

1. 글을 매개로 한 공부 - 글을 쓰기 위해서라도 열심히 공부하고, 성장하는 제가 되고 싶어요
2. 기술적 취향 및 관심사 찾기 - 제가 어떤 글을 쓰는지 살펴보다보면 제 기술적 취향과 관심사를 찾을 수 있을 것 같아요
3. 다양한 사람들을 만나보면서 고정관념, 편견 부수기 혹은 강화하기

저는 사실 제가 어떤 걸 좋아하는 개발자인지, 어떤 걸 잘할 수 있는 사람인지 잘 모르겠어요. 9기 활동하면서 다국어 시스템이나 조직문화 개선에 대한 글을 쓸 때 참 재미있었는데 10기에는 기술적인 글들을 좀 더 써보면서 내가 어떤 부분을 좋아하고, 잘할 수 있는지 찾아보고 싶습니다.

액션 아이템 - 활동 로그​

지금부터라도 나는 내 생을 유심히 관찰하면서 살아갈 것이다. 되어 가는 대로 놓아두지 않고 적절한 순간, 내 삶의 방향키를 과감하게 돌릴 것이다. 인생은 그냥 받아들이는 것이 아니라 전 생애를 걸고라도 탐구하면서 살아가야 하는 무엇이다. 그것이 인생이다.......

모순, 양귀자

소설 속 주인공은 '삶을 유심히 관찰하며 탐구하듯 살아야한다. 그것이 인생이다.' 라고 말하는데 저도 말뿐인 다짐이 아니라 실천하기 위해서 탐구적인 자세를 좀 더 가져가 볼까 합니다. 그래서 엉성하지만 앞으로 6개월간의 대략적인 계획을 미리 해볼 수 있는 템플릿을 만들어보았어요.

소재가 없어서 패스를 쓰는 것만은 피하고 싶어서 '언젠간 쓰겠지...'하고 쌓아두었던 글 소재들을 일단 넣어놨어요. 계획대로 되지 않는 것이 인생이기 때문에 '꼭 해내고야 말겠다!'는 생각은 없고, 중간중간 열심히 살고 있는지 스스로를 독려해주기만 해도 큰 역할을 할 것 같습니다.

액션​

목표와 액션 아이템까지 생각했습니다. 이제 할 일은 액션!

인생은 탐구하면서 살아가는 것이 아니라, 살아가면서 탐구하는 것이다. 실수는 되풀이된다. 그것이 인생이다.......

모순, 양귀자

이 소설을 읽은 분들이라면 아시겠지만 소설의 결말이 여느 K-드라마처럼 행복하고, 이상적으로 마무리되지 않아서 이런 다짐글에 인용하는 것이 맞나 싶은 생각이 듭니다. 하지만 뻔한 성공 스토리가 아니라서 더 마음에 깊이 와닿았어요. 저도 비장하고, 거창하게 다짐했지만 6개월 후에는 후회가 가득한 회고글을 작성하고 있을지도 모르지요. 설령 정해진 미래가 그렇다 하더라도, 실수를 되풀이 하는것... 그것이 인생이니까...

일단 고! 🚀🚀🚀

전공자도 비전공자도 아닌 나​

저는 '디지털콘텐츠학'을 전공했습니다. 이름만으로는 정확히 어떤 전공인지 알기 쉽지 않습니다. 사실 입학할 때, 포토샵이나 프리미어로 디지털콘텐츠를 만드는 방법을 배우는 곳이겠거니 싶어서 선택했는데 실제로는 포토샵이나 프리미어 같은 프로그램을 만드는 방법을 배우는 곳이었어요😅

1~2학년 때까지는 프로그래밍은 절대 하지 말아야겠다고 생각했었고, 운영체제나 네트워크 같은 전공 필수 수업은 듣지 않았습니다. 교내 방송국에서 일하면서 영상 편집을 배웠고, 대만으로 교환학생을 가서 중국어를 배우며 이리 저리 방황했더랬습니다. 어찌저찌 개발자로 취업했지만 스스로 '전공자'라고 하기에는 부끄러운 마음이 들 때가 많습니다.

직장에서 만난 사람들의 실력은, 적어도 현재까지 나의 경험으로는, 대학의 전공과는 별로 상관이 없었다. 직장은 결과로 말하는 곳이며, 자신의 업무와 조직에 대한 정확한 이해와 통찰, 일을 완수하려는 성실성과 태도가 더 중요하다는 것을 이제 나는 안다.

다른 삶, 곽미성 저

책을 읽다가 깊이 공감한 부분입니다. 저희 회사에도 직무와 무관한 전공을 가진 분들이 많은데, 전공과 업무 퍼포먼스는 별개인 경우가 많습니다.

비전공자도 무엇무엇을 할 수 있느냐는 질문에는 사실 두려운 마음이 깔려있는 것이겠지요. 정말 하고 싶은 일이라면 용기를 내어야한다고 생각합니다. 만약 학위때문에 개발자를 하지 못하게 된다고 하더라도 그 도전의 경험이 삶의 다른 길로 이끌어 줄 거라고 믿어요.

애초에 마음을 따랐다면 남편에게 적성에 맞지 않는 학과에 들어갔다가 자괴감으로 방황하는 시간도 없었을 것이고, '해야만 한다'는 생각으로 되고 싶지도 않은 교수직을 위해 허비하는 시간도 없었을 테니까. 하지만, 그걸 처음부터 알았다면 우리는 젊은이가 아니었겠지. 이게 아니면 안되는 인생은 없다.

다른 삶, 곽미성 저

애자일 하다는 착각​

뉴로클의 개발 문화

회사 채용페이지의 개발 문화에 대한 내용은 제가 작성했는데요. 작성할 때만해도 저는 저희 조직이 애자일하게 개발하고 있다고 생각했습니다.

착각 요소​

1. 스프린트를 진행한다.
2. Jira를 사용한다.
3. 프로젝트가 끝나면 회고한다.

생각해보면 이 두 가지 요소 때문에 애자일하다고 착각하고 있었던 것 같습니다. '워터폴이 아니니까 애자일인거 아니야...?'라고 대충 생각했던 것 같아요.

우리 조직은 애자일하게 하고 있는데 기획을 수정하는 게 왜 이렇게 힘든 걸까요? 왜 개발자들이 릴리즈 날에 밤새면서 버그를 고치는 걸까요? 애자일이란 과연 무엇일까요?

어떤 부분이 문제 였을까?​

약 2개월 동안 팀원들과 애자일을 공부하고, 치열하게 토론하며 저희 프로세스의 문제점을 찾아내고 새로운 프로세스를 만들었습니다. 진짜 애자일한 조직이 되기 위해 크게 2가지를 바꾸었는데요.

1. 스프린트 기간을 2주로 줄임
2. 스토리 포인트 도입

결과적으로 이런 사이클을 계속 반복하게 되었어요! 업무 프로세스를 변경한다고 했을 때, 너무 복잡해져서 적응하지 못하는 것 아닌지에 대한 걱정이 많았는데 사실 핵심은 이 2가지였고, 나머지는 저희가 늘 해왔던 일들이라 실제로 수행하는 데 어려움은 적었습니다.

1. 스프린트 기간을 2주로 줄임​

1개월 단위로 진행했던 스프린트 기간을 2주로 줄이고, 스프린트 전후로 킥오프와 회고를 진행했습니다.

예를 들어 메이저 업데이트를 6개월 간 개발한다고 가정해 보겠습니다. 기존에는 스프린트 1개의 기간을 1개월로 잡아서 총 6개의 스프린트를 진행하던 것을 2주로 줄여 12개의 스프린트를 진행하였습니다.

스프린트가 끝날 때마다 스프린트 회고를 진행하는데 짧은 간격으로 일정을 점검하게 되면서 문제점을 비교적 초기에 발견하고, 대처할 수 있었습니다. 더불어 스프린트 기간이 짧아지면서 개발의 속도감도 높아지는 장점도 있었습니다.

2. 스토리 포인트 도입​

모든 업무를 스토리로 만들고, 각 스토리마다 스토리 포인트를 부여하여 피쳐의 크기를 수치화 했습니다.

스토리란 유저가 제품에서 사용해 볼 수 있는 변경사항으로 정의했습니다. 기능을 유저관점에서 설명한 것으로 예를 들면 유저가 OO버튼을 누르면 OO화면으로 이동하는 기능이 될 수 있습니다. 이전에는 이런 기능을 OO 기능 개발이라고 크게 잡아서 진행했는데, 이를 스토리 범위로 작게 쪼개고 기능 하나의 크기를 상대적으로 비교할 수 있도록 스토리포인트를 계산하여 전체적인 피쳐의 크기를 수치화 했습니다.

스프린트 계획단계 에서 스프린트에서 진행할 스토리를 산정하고, 스프린트 회고에서는 완료된 스토리 포인트를 계산해 평균 속도를 측정했는데요. 팀의 개발 속도를 PM의 감성적 의견이 아닌 정량적인 수치로 파악할 수 있었어요. 남은 기간동안 우리가 목표했던 것들을 전부 개발할 수 있는지 없는지, 개발할 수 없다면 얼만큼의 시간이 더 필요한지에 대한 판단 근거가 되어주었습니다.

포스트잇으로 시각화하면 훨씬 와닿더라구요!

그래서 좋아졌나요?​

저는 이 프로세스를 도입하고나서 크게 3가지 효과를 느꼈습니다.

1. 피쳐의 크기를 파악할 수 있다.
2. QA를 더 꼼꼼히 볼 수 있다.
3. 큰 피쳐에서도 각 기능마다 우선순위를 고려할 수 있다.

1. 피쳐의 크기를 파악할 수 있다.​

초반 1~2개월은 버전에 들어갈 메인 피쳐를 선정하는 데 소비합니다. 우선순위와 대략적인 마감 날짜를 정하기 위해 피쳐 목록들을 쭉 보면서 기획이 없는 항목에 대해서도 주 단위로 공수를 산정해야 했습니다. 기획자도 모르는 피쳐에 대한 공수를 산정하는 것이 너무 어렵기도하고, 각 팀이 생각하는 기능이 동상이몽입니다. 초반에 대충 계산한 공수가 기획이 구체화 되면서 불어나는 경우가 많이 있었고, 이로 인해 릴리즈 날짜가 미뤄지는 경우가 종종 있었어요.

스토리가 없었을 때에는 한 스프린트를 끝내고 진행도를 체크할 때, 피쳐의 완성도를 수치화하기 어렵고 '큰 피쳐들을 열심히 개발중'이라고 밖에 말할 수 없었습니다.

스토리 포인트가 도입 된 후에는 전체 100 스토리 포인트 중 n 스토리 포인트 완료처럼 완성도 파악이 쉬워졌고, 각 기능 개발에 걸리는 시간을 상대적으로 비교할 수 있게 되었어요!

하나의 피쳐에 대해 각 팀이 상의하여 합리적인 스토리 포인트를 산정합니다.

2. QA를 더 꼼꼼히 볼 수 있다.​

이전에는 스프린트가 끝날 때마다 어떤 기능이 완성되었는지 확인하는 것이 어려웠습니다. 크기가 큰 피쳐같은 경우에는 2~3개월에 걸쳐 개발이 진행되는 경우가 많아서 스프린트가 끝날 때마다 QA를 진행하기가 불가능했어요. 릴리즈 직전 3주동안 QA 스프린트를 진행하면서 QA의 부담이 커지고, 제품의 안정성도 떨어지는 상황이었습니다.

스토리로 피쳐를 작게 쪼개고, 스토리를 완료하면 2주마다 해당 스토리에 대한 QA를 진행하게 되면서 릴리즈 직전의 QA 부담을 많이 줄일 수 있게 되었어요. 유저의 입장을 기준으로 정리된 스토리로 QA 포인트도 좀 더 정확하게 잡아낼 수 있었습니다. OO 기능에 대한 QA 보다는 OO 버튼을 누르면 OO 화면으로 이동하는 기능에 대한 QA 가 훨씬 구체적이고, 놓치기 어렵거든요.

3. 큰 피쳐에서도 각 기능마다 우선순위를 고려할 수 있다.​

스토리를 구체적으로 뽑아낼 수 없는 기획은 더 잘게 쪼개게 되면서 MVP를 더 빨리 도출할 수 있었습니다. 중요한 기능을 먼저 개발하고, 나머지는 시간이 남을 때 개발하는 방식으로 진행할 수도 있었어요. 시장에 임팩트가 있을 기능이 무엇인지 더 자주 고민하게 되고, 야근을 하더라도 의미있는 야근을 했다고 느껴져서 정신적으로도 덜 힘들었습니다.

PM의 후기​

프로젝트 관리의 주체였던 PM분께 애자일 프로세스 도입 후기에 대해 여쭤봤는데요. 이전에는 스프린트 2~3개에 걸쳐서 '진행중'이던 피쳐가 스토리로 작게 쪼개진 덕분에 관리 리소스가 크게 줄었고, 명확해졌다고 말씀해주셨습니다. 그럼에도 불구하고 스토리를 만드는 것은 각 팀마다 이해도 차이가 있어서 아직은 조금 더 연습이 필요한 것 같다고 하셨어요. 아직 개선할 점들이 있지만 충분히 만족스러운 애자일 첫걸음 이었다고 생각해요🎉

혼자서는 바꿀 수 없는 것​

애자일 프로세스를 도입하면서 가장 크게 느낀 점은 '혼자서는 바꿀 수 없다'는 것이었습니다. 나만 스토리를 잘 뽑고, 나만 스토리 포인트를 잘 산정하고, 나만 스프린트 목표를 이룬다고 해서 조직이 애자일해지는 것은 아닙니다. 팀원 모두의 이해도를 올리는 것이 중요했고, 이를 위해서 많은 노력이 필요했습니다.

태어나서 처음으로 업무 워크샵을 기획하고 진행해보았습니다

애자일 워크샵을 진행해서 스토리를 어떻게 만들어야 하는지, 스토리 포인트는 어떻게 산정해야 하는지에 대해 설명하고 실습을 통해 익히는 시간을 가졌습니다. 그 과정에서 각자의 이해 수준을 맞추고, 각 팀이 느끼는 어려운 점을 함께 공유할 수 있었어요.

이 워크샵을 진행하기 위한 자료를 2개월 동안 정말 치열하게 연구하고, 토론해서 만들어 냈는데 이 과정이 팀을 더 단단하게 만들어 주기도 했습니다.

가장 중요한 건 팀원 모두가 이 모든 프로세스를 그저 생각없이 따르거나, 최대한 덜 일하려고 이용하는 것이 아니라 더 나은 제품을 만들기 위한 과정, 완성도를 높이기 위한 시간을 확보하는 수단으로 생각해야 한다는 것입니다. 그렇지 않다면 큰 의미가 없고, 워터폴 방식으로 하는 것이 나쁜 방식이 아니라고 생각하거든요.

애자일이 만병통치약은 아니에요!​

조직에 애자일 프로세스를 적용한다고 해서 모든 문제가 해결되는 것은 아닙니다. 각 팀의 성격, 규모, 상황마다 적절한 프로세스가 있는 것 같아요. 때로는 워터폴 방식이 훨씬 더 효율적일 수 있어요.

사실, 처음 이 프로세스를 도입한 마이너 버전 릴리즈 날도 새벽에 퇴근 했습니다. 노력했지만 한 번에 모든 문제를 해결할 수는 없더라고요.

<애자일 개발이 처음인 내가 출근했더니 스크럼 마스터가 된 건에 관하여> 중에서...

책의 한 페이지가 너무 와닿아서 찍어두었습니다. (책에 실제로 겪을 법한 상황들이 많이 묘사되어있어서 재미있었어요. 추천!) 애자일을 처음 도입한 팀의 이야기인데 이 팀도 결국 릴리즈 당일에는 새벽 2시까지 일하더군요...ㅎㅎ 애자일의 진정한 의미는 '카이젠(개선)'에 있으니까! 다음 릴리즈에는 더 나은 방향으로 개선 되기를 바라고 있습니다.

그리고 아직도 해결되지 않은 문제 중, 가장 큰 문제는 기획과 디자인이 완성되는 시점이 너무 늦는 것입니다. 책에서도 나오지 않는 문제인데요.
가장 좋은 시나리오는 다음 버전의 기획이 미리 완료되어있고, 스토리와 스토리포인트까지 산정되어있는건데 현재 리소스로는 불가능에 가까운 일이네요. 기획자, 디자이너가 많은 조직은 이런 문제가 없을까... 궁금한 점이 많습니다. 일단 와이어프레임으로 MVP 개발과 검증을 진행하면서 완성도를 올리는 방식을 지향하고 있지만, 모든 피쳐의 성격이 MVP 기획이 가능한 형태는 아니라서 현실과 타협할 수밖에 없는 상황입니다. 책이나 컨퍼런스에 참가할 기회가 있다면 이런 문제들에 대한 해결책들을 찾아보고 싶어요.

중요한 것은 꺾이지 않는 마음​

처음 개선된 프로세스를 소개할 때, 사내 발표에서 썼던 장표 중 하나입니다.

이런 것들을 기대했는데 완벽하진 않지만 어느정도 변화를 이끌어 낸 것 같아서 굉장히 뿌듯하네요. 가장 긍정적으로 생각되는 건 일하고 싶은 환경을 스스로 만들어 갈 수 있다는 희망이 생겼다는 것입니다. 이 글을 읽고 계신 분들은 애자일 하고 계시는지, 어떤 방식으로 일하고 싶은 환경을 가꾸고 계신지 궁금하네요!

긴 글 읽어주셔서 감사합니다!🙏

업무 배분 기준​

1. 담당자가 이전에 담당했던 부분을 계속 개발한다.
2. 담당자가 이전에 담당하지 않았던 부분을 개발한다.

1번을 선택하면 효율적이고, 빠르게 개발할 수 있는 대신 유지보수가 어려워질 수 있다. 신규 입사자에게는 성과를 낼 기회가 없을 수도 있고, 오래 일한 사람 혹은 손이 빠른 사람에게 일이 몰리기기도 한다.

2번을 선택하면 모든 팀원의 프로젝트 이해도가 높아지는 대신 개발 속도가 떨어질 수 있다. 기존 코드를 이해하는 데 시간이 필요하지만, 그 과정에서 개개인의 능력이 향상 될 수도 있다.

어떤 기준을 선택해야 할까?​

팀원 전체가 프로젝트에 익숙해지기 전까지는 2번 방식으로 업무를 배분해야 소수의 슈퍼 개발자에게 의존하지 않는 지속 가능한 팀을 만들 수 있다고 생각한다. 비즈니스 상황을 고려해 1번 기준으로 1개, 2번 기준으로 1개씩 업무를 배분하는 하이브리드 방식도 좋을 것 같다.(현재 팀은 이렇게 하고 있다.)

두 개의 기준을 적절히 섞어야 개인과 조직의 성장을 동시에 이룰 수 있지 않을까? 업무 배분의 딜레마를 언젠가는 해결할 수 있을까?

장비 목록​

모니터 - LG 34인치 360 모니터 34WN780 WQHD​

34인치 울트라 와이드 모니터. 가격은 약 65만원.

원래 듀얼 모니터 + 모니터 받침대 조합으로 사용중이었는데 책상 공간을 너무 많이 차지하는 단점이 있었습니다. 모니터를 하나로 줄이고, 모니터 암으로 책상 공간을 확보한 덕분에 책상을 넓게 쓸 수 있게되었는데 이 점이 제일 만족스럽습니다. 내장 스피커가 있어 스피커를 따로 구매하지 않아도 되고, HDMI도 2개 연결할 수 있어서 맥북과 데스크탑 화면을 전환하며 사용중입니다.

키보드 - 키크론 K6​

키크론 K6 블루투스 키보드. 가격은 약 10만원.

맥북 키보드와 윈도우 키보드를 모두 지원하고, 무선으로 사용할 수 있어서 선택했습니다. 숫자키를 쓸 일이 많이 없어서 아주 미니멀한 스타일로 골랐는데 아직까지 큰 불편함은 없습니다. 휴대성이 좋지만 외출할 땐 잘 안들고 나가는 편이에요.

키보드 트레이​

책상에 설치할 수 있는 키보드 트레이. 가격은 약 4만원.

손목을 보호하기 위해 책상 아래에 키보드 트레이를 설치했습니다.

팔꿈치를 직각으로 두고, 손목은 꺾이지 않도록 해야 어깨나 손목에 무리가 덜 가는데 책상 위에 키보드를 놓으면 도저히 그 각도가 나오지 않아서 찾아보니 키보드 트레이라는 것이 있더라구요. 덕분에 책상 위 공간을 더 넓게 사용할 수 있게 되어 좋습니다. 키보드 트레이를 구입하니 손목을 받칠 수 있는 팜레스트도 같이 사은품으로 챙겨줘서 더 좋았습니다 :-)

마우스 - 애플 트랙패드​

트랙패드 1세대. 중고로 구입.

맥북을 좀 사용하다보면 일반 마우스를 쓰는게 불편해집니다. 1세대는 충전식이 아니라 건전지를 사용하는데 매번 충전하는 게 귀찮을 것 같아서 일부러 1세대로 구입했습니다.

맥북 아이패드 듀얼 거치대​

아이패드와 맥북을 동시에 사용할 수 있는 거치대. 가격은 약 4만원.

모니터 암을 사용하면서 확보한 책상 공간을 더 넓게 사용하기 위해 세로로 거치할 수 있는 모니터 거치대를 구입했습니다. 맥북을 거치해두고 클램쉘 모드로 사용 중인데, 무선 블루투스 키보드와 트랙패드의 조합으로 책상 공간을 넓게 유지하며 깔끔한 생활이 가능해집니다.

의자 - 일룸​

당시 코로나 보조금으로 구입. 약 30만원.

오래 앉아있어야하므로 그래도 꽤 거금을 들였으나 조금 무겁고, 매쉬 재질이 아니라서 여름에 사용감이 썩 좋지 않습니다. 더워요...

셋업은 아직 끝나지 않았다...​

재택이 가능한 데스크 셋업을 마련하는 데에만 100만원이 넘게 썼네요. 건강하고 즐겁게 일하기 위해 투자하는 것이라고 생각하고 있습니다. 애석하게도 아직 꿈의 데스크 셋업은 완성되지 않았습니다.

1. 서서 일할 수 있는 모션 데스크
2. 통풍이 잘되는 허먼밀러 의자
3. 공간을 많이 차지하지 않으면서 음질이 좋은 사운드바

글또에서 생긴 일​

옛날부터 글또의 존재를 알고 있었지만 지원서를 작성할 용기가 생기기까지는 2~3년이 걸렸습니다. 제 삶에 꾸준히 긍정적 영향을 주는 친구가 있는데 그 친구가 꽤 오래전부터 글또 활동을 하고 있었더라구요.(심지어 운영진😮!!!) 덕분에 용기내어 글또 9기 활동을 시작 할 수 있었고, 글또를 통해 많은 것을 얻었습니다. 커뮤니티의 규칙은 단순히 '2주에 한 번 글을 제출'하는 것이지만 그것보다 더 많은 것을 해낸 5개월 이라고 생각합니다.

1. 8편의 글 작성​

2022년 회고 글에, '개발 블로그를 개편했지만 글 작성을 하지 않은' 반성 항목이 있었습니다. 글또에 지원한 목적도 더 많은 글을 써보기 위해서 였는데 5개월 동안 총 8편의 글을 작성해냈습니다! 작년에 총 6편의 글을 작성한 것에 비하면 괄목할만한 성과라고 생각합니다!

매번 회고글만 쓰는 것 같아서 기술적인 글을 쓰고 싶었는데 총 3편의 기술적인 글을 작성했습니다. 입사 후 가장 열심히 했던 다국어 관리 시스템에 대해 언젠가 한 번은 정리해보고 싶었는데 2주라는 마감시간을 갖게 되어 더이상 미루지 않고 글을 작성할 수 있었어요.

2. 큐레이션 2픽!!​

글또에서 첫 활동이기도하고, 막상 들어와보니 활동 인원이 많아서(452명) 기대도 안했는데 첫 회차에 제출한 글이 큐레이션에 뽑혀서 정말 기분이 좋았습니다~

크리스마스날 큐레이션에 뽑혀서 선물같고, 더 좋았어요. '내 글을 다른 사람들이 재미있게 읽어주었구나'하는 보람이 있었습니다.

그리고 8회차에 제출한 번역글이 큐레이션에 뽑혀서 놀랐습니다. 단순 번역만 하지 않고, 제가 느꼈던 점을 덧붙였는데 큐레이션 이유에도 짤막하게 쓰여있듯 공감할 수 있는 부분이 많았던 것 같아요.

활동 전에는 큐레이션의 존재를 몰랐기 때문에 별 생각이 없었는데 제가 쓴 글이 큐레이션에 뽑히면서 글쓰는 재미를 좀 더 느끼게 되었습니다. (인정하긴 싫지만 인정받는 건 너무 달콤하네요...🍬)

3. 글쓰기 세미나​

성윤님께서 몇 년간 쌓아온 노하우를 2회에 걸쳐 세미나로 공유해주신 글쓰기 세미나에 참석했습니다. 세미나를 듣고 과제를 수행하면서 제 글쓰기 프로세스를 되돌아보고, 글 작성을 위한 환경을 조성할 수 있었어요. 안타깝게도 글쓰기 습관을 들이는 것에는 실패했지만 그래도 무기한으로 미루는 나쁜 습관은 조금씩 개선되는 것 같습니다.

4. 커뮤니티 활동​

글또 슬랙에는 생각보다 많은 채널이 있습니다. 달리기 모임이나 독서모임 같은 제너럴한 모임부터 강아지 모임 같은 귀여운 모임도 있어요. 여러 채널에서 적극적으로 활동하지는 못했지만 몇 몇 커뮤니티 활동이 기억에 남습니다.

리액트 훅을 활용한 마이크로 상태관리 스터디

리액트 훅을 활용한 마이크로 상태관리 라는 책을 번역해주신 분께서 글또에 홍보 글을 작성해주신 덕분에, 그리고 그 글을 보고 스터디를 모집해주신 분 덕분에 글또 활동기간 중 개발 서적 한 권을 찐하게 읽을 수 있었습니다. 책을 읽다가 궁금한 부분에 대해서 사소한 거라도 깊게 파보고, 라이브러리 코드를 파헤쳐보면서 이해하려고 노력하시는 스터디원분들을 보면서 개발 서적을 대하는 자세에 대해 배울 수 있었어요.

4번의 커피챗 ☕️☕️☕️☕️

'커피챗'이라는 용어는 많이 들어봤지만 실제로 진행해 본 것은 글또를 통해서가 처음이었습니다. 제가 먼저 신청한 적도 있고, 다른 분이 먼저 제안해주신 적도 있고, 글또에서 엮어준 기회도 있었는데 4번 모두 기억에 남는 시간이었습니다. 같은 프론트엔드 직군의 개발자들을 만나서 다양한 이야기를 나눈 것도 좋았고, 다른 직군 개발자분들은 어떤 고민을 하는지 들어보는 것도 좋았습니다. 한두시간의 대화에서도 인사이트를 얻을 수 있고, 또 제가 다른 분에게 인사이트를 줄 수 있다는 것도 즐거운 경험이었어요.

독서모임

다양한 커뮤니티 활동 중에 독서모임에도 참여했습니다. 책을 좋아하시고, 같은 개발직군이라 그런지 다른 독서모임보다 훨씬 공감가는 이야기를 나눌 수 있었어요. 서로 다른 책을 읽고 이야기를 나눴지만 전체적으로 같은 결의 이야기를 하게 되는 것이 신기했습니다. 확실히 비슷한 결의 사람들이 모여있는 커뮤니티라는 생각이 들었어요.

반상회

글또 활동 막바지에 진행된 반상회도 재미있었습니다. 뭔가 연예인처럼 느껴지는 분들도 실제로 볼 수 있었어요.(쑥쓰러워 대화는 못해보았습니다만...) 블로그 SEO 향상에 관한 발표를 들으며 제 블로그에 google search console을 연결해놓아야겠다는 다짐을 했습니다. 그리고 1시간 정도 4명정도의 인원으로 네트워킹을 할 수 있는 시간도 정말 재미있었습니다. 같은 업계 사람들을 만나 네트워킹 할 수 있다는 것도 글또 활동의 큰 장점이라고 생각합니다.

Before & After​

지원서에 적었던 목표를 돌아보았습니다.

목표하지 않은 항목에서도 큰 성과가 있었습니다. 주기적으로 블로그를 관리하게 되면서 GA를 연결하고, docusaurus 버전 업데이트와 플러그인을 추가했습니다. 블로그 버그들을 글또를 통해 발견하고 수정할 수 있었어요. 뜻밖의 순기능입니다!

방학이다! 놀자(?)​

글또 9기가 끝나고 방학이 시작되었습니다. 요즘은 퇴근 후 자기계발은 싹 잊고 각종 콘텐츠에 빠져 즐겁게 살고 있는데요. 일단 짧고 소중한 봄은 신나게 즐기고, 다시 글쓰기에 도전해보려고 합니다. 제 삶에 변화를 이끌어 준 글또에 감사하고, 덕분에 만난 모든 인연에게도 감사드립니다. 글또 10기에서 또 만나요!👐

Quest! Snackbar 컴포넌트 제작하기​

Snackbar 컴포넌트는 사용자에게 메시지를 보여주는 컴포넌트입니다. 사용자가 어떤 작업을 했을 때, 성공했는지 실패했는지 등을 알려주는 데 사용합니다.

말줄임표 처리 문제​

제가 맞닥뜨린 문제는 Snackbar 컴포넌트의 내부 텍스트의 말줄임표 처리였습니다. 단순히 Snackbar 컴포넌트의 내부 메세지 텍스트에 max width값을 설정해 주어 ellipsis로 말 줄임 처리하면 해결되는 문제가 아니었기 때문입니다. Snackbar 컴포넌트 내부에 액션버튼이 있을 때, 액션 버튼의 길이에 따라 내부 메세지 텍스트의 max width값이 동적으로 변경되어야 했습니다.

const Snackbar = ({ message, action }) => {
  const classes = useStyles({
    root: {
      width: "fit-content",
      maxWidth: "300px",
    },
    message: {
      width: "fit-content",
      // maxWidth: 'calc(100% - action 버튼의 크기에 따라 동적으로 변경)',
      overflow: "hidden",
      textOverflow: "ellipsis",
      whiteSpace: "nowrap",
    },
    action: {
      maxWidth: "100px",
      overflow: "hidden",
      textOverflow: "ellipsis",
      whiteSpace: "nowrap",
    },
  });

  return (
    <div className={classes.root}>
      <div className={classes.message}>{message}</div>
      <button className={classes.action}>{action}</button>
    </div>
  );
};

시도 1) useEffect 의존성에 ref 객체를 주입하기​

처음 생각했던 방법은 button 노드를 ref에 등록한 후, useEffect에 의존성을 주어서 액션 버튼의 크기가 변경될 때마다 버튼의 width값을 전달 받는 방법이었습니다.

const Snackbar = ({ message, action }) => {
  const buttonRef = useRef(null);
  const [buttonWidth, setButtonWidth] = useState(0);

  useEffect(() => {
    if (buttonRef.current) {
      const width = buttonRef.current.getBoundingClientRect().width;
      setButtonWidth(width);
    }
  }, [buttonRef]);

  return (
    <div className={classes.root}>
      <div
        className={classes.message}
        style={
          {
            maxWidth: `calc(100% - ${buttonWidth}px)`,
            // action 버튼의 크기에 따라 동적으로 변경
          } 
        }
      >
        {message}
      </div>
      <button ref={buttonRef} className={classes.action}>
        {action}
      </button>
    </div>
  );
};

리렌더링 문제​

이때의 렌더링 순서는 다음과 같습니다.

1. buttonWidth state가 0인 상태로 컴포넌트 렌더링
2. buttonRef가 등록되면서 useEffect가 실행되어 buttonWidth를 계산
3. buttonWidth state가 변경되면서 컴포넌트 리렌더링

이런 동작 방식 때문에 컴포넌트가 두 번 렌더링 되는 문제가 발생했습니다. 그래서 useEffect의 의존성에 ref 객체를 주입하는 것은 올바른 해결책이 아니라는 생각이 들었고, 이 문제를 해결하기 위해 callback ref를 사용하게 되었습니다.

시도 2) callback ref 사용한 useDimension hook​

callback ref​

callback ref는 함수를 ref로 전달하는 방식입니다. ref 객체를 생성하고, 해당 ref 객체를 컴포넌트의 ref 속성에 전달하는 대신, 함수를 ref 속성에 전달합니다. DOM 노드가 화면에 추가되면 ref 속성은 전달된 callback 함수를 호출하고, DOM 노드를 인수로 전달합니다.

useDimension hook​

DOM 노드가 화면에 추가될 때, width 값을 업데이트해주면 컴포넌트가 리렌더링 되는 문제를 해결할 수 있을 것이라고 생각했습니다. 그래서 인수로 전달받은 DOM 노드의 width와 height를 반환하는 useDimension hook을 만들었습니다.

type useDimensionReturn = {
  width: nullableNumber;
  height: nullableNumber;
  ref: (node: HTMLElement | null) => void;
};

const useDimension = (): useDimensionReturn => {
  const [width, setWidth] = useState<number | null>(null);
  const [height, setHeight] = useState<number | null>(null);

  // useCallback을 사용한 ref 함수
  const ref = useCallback((node: HTMLElement | null) => {
    if (node !== null) {
      setWidth(node.getBoundingClientRect().width);
      setHeight(node.getBoundingClientRect().height);
    }
  }, []);
  return { width, height, ref };
};

export default useDimension;

Snackbar 컴포넌트에는 다음과 같이 사용할 수 있습니다.

const Snackbar = ({ message, action }) => {
  const { width: buttonWidth, ref: buttonRef } = useDimension();

  return (
    <div className={classes.root}>
      <div
        className={classes.message}
        style={ 
          {
            maxWidth: `calc(100% - ${buttonWidth}px)`,
          } 
        }
      >
        {message}
      </div>
      <button ref={buttonRef} className={classes.action}>
        {action}
      </button>
    </div>
  );
};

이렇게 하면 ref가 변경되어도 컴포넌트가 리렌더링 되지 않아서 불필요한 리렌더링을 방지할 수 있습니다.

ref를 단순히 DOM 노드에 접근하는 변수, 컴포넌트 렌더링에 영향을 미치지 않는 변수로만 생각했었는데, Snackbar 컴포넌트를 구현하며 ref를 활용하는 방법에 대해 배울 수 있었습니다. 이 글이 ref의 활용을 배우는 데에 많은 도움이 되었으면 좋겠습니다. 감사합니다.

어찌 보면 당연한(?) 말인데요. 처음에는 릴리즈 === 끝이라고 생각했습니다. 개발 기간 동안 야근한 나를 위로하기 위해 긴 휴가를 보내거나 하릴없이 월급 루팡을 하기도 했고요. 하지만 정말 프로젝트를 매조지기 위해서 해야 할 일들이 있고, 코드 개발에 비해 개발자들이 놓치기 쉽고 귀찮은 작업들이 많습니다.

우연히 읽게 된 Stopping at 90%라는 글에 굉장히 공감했고, 이것이 비단 개발자들만의 문제는 아니라는 점도 흥미로웠습니다. 글을 소개하며 저도 지금까지 프로젝트들을 잘 마무리해왔는지 되돌아보려고 하는데요. 이 글을 읽는 분들도 하고 계신 일을 완전히 매듭짓는 데 이 글이 도움이 되었으면 좋겠습니다.

Stopping at 90%​

이 글은 Austin Z. Henley의 포스트 Stopping at 90%을 번역한 글입니다.

프로젝트를 막 마무리 했습니다.

4개월 동안 소프트웨어 시스템을 구축하고, 실험을 진행하고, 논문을 작성해 저널에 출판을 위해 제출하였습니다. 이제 할 일이 끝났습니다. 끝. 그렇죠?

아니요! 저는 이것을 90%에서 멈추기라고 합니다.

핵심 프로젝트는 완료되었지만 아직 할 일이 많이 남아 있습니다. 아무도 남은 할 일에 대해 모르거나 하려고 하지 않는다면 절대 일어나지 않을 일들입니다. 이렇게 마무리된다면 그것은 잘못된 마무리입니다.

이것은 비단 연구 논문 작성에만 발생하는 문제가 아닙니다. 당신이 출시한 iOS 앱, GitHub에 올린 개인 레포지토리, 회사에 제출할 보고서, 귀여운 강아지 그림을 그리는 사이드 프로젝트 등 모든 프로젝트에서 발생할 수 있습니다.

저는 이 현상을 어디에서나 발견했고, 어느 누구도 문제 발생에서 자유로울 수 없습니다.

핵심 프로젝트는 쉽게 측정할 수 있는 구체적인 결과물이 있는 반면, 나머지 10%의 할 일은 추적이 어렵고 명확한 중단 지점이 없는 경우가 많기 때문에 90%에서 멈추는 경우가 많습니다. (쉽게 측정할 수 있는 구체적인 결과물에는 예를 들어, 시스템 성능을 개선, 논문 제출 등이 있습니다.)

90%에서 100%로 가려면 무엇을 해야 할까요?

• 다른 팀에게 한 일을 발표합니다.
• 조직 내의 다른 사람들이 알 수 있도록 요점을 정리한 이메일을 발송합니다.
• 동료들이 나중에 활용할 수 있도록 코드를 저장합니다.
• 블로그 게시물을 작성합니다. 트위터, HN, Reddit에 글을 올립니다.
• 계속 진행할 계획이 없더라도 다음에 무엇을 할 것인지, 그 이유는 무엇인지 설명하는 문서를 작성합니다.
• 도움이 될 수 있는 비슷한 프로젝트를 찾아봅니다.
• 본인의 작업물에 허점을 찾아낼 수 있는 사람을 찾습니다. 그리고 그 문제를 해결하세요.

전파, 문서화, 고도화는 핵심 프로젝트만큼이나 중요합니다.

나는 95%쯤...?​

저는 문서화와 전파를 중요하게 생각합니다. 일하는 인원에 교체가 있더라도 문제없이 잘 돌아갈 수 있는 시스템을 만들어 놓아야 한다고 생각합니다. 그러기 위해서는 이런 문서화 작업들이 필수적이라고 생각해서 몇 가지 작업들을 해놓았습니다.

먼저 릴리즈가 끝나면 체크리스트를 보며 빠뜨린 것이 없는지 확인합니다.

그리고 작성중인 글들을 확인하고, 문서화를 마무리합니다. 노션에 작성하는 문서는 하나의 데이터베이스에만 작성해서 관리하기 때문에 '상태' 값을 통해 작성중인 문서를 쉽게 확인할 수 있습니다.

작성 중인 글들을 완성하고 나면, 이전에 작성 완료된 문서들을 쭉 돌아보며 갱신이 필요한 부분이 있는지 확인합니다. 노션 데이터베이스의 '수식' 기능을 사용해 얼마나 방치된 문서인지 확인합니다.

dateBetween(now(), prop("마지막 업데이트"), "days")

위와 같은 나머지 10%에 해당하는 작업은 개발에 비해 우선순위가 떨어집니다. 그리고 당장하지 않아도 크게 문제되지 않아요. 굉장히 귀찮습니다. 하지만 이런 작업들을 릴리즈가 끝난 시점에 하지 않으면 다음 기회는 없습니다.

그래도 릴리즈 이후 이런 작업들을 하는 버릇이 들어 완성도가 95%정도는 되지 않나...라고 생각해봅니다. 앞으로는 문서화 외에도 다른 팀과 작업 내용에 대한 기술적 교류, 비슷한 프로젝트를 탐구해보고 비교하기, 작업물 개선 등을 시도해서 나머지 5%를 채워보아야겠습니다.