글 쓰는 법을 잊은 개발자

저는 2020년 8월 대학을 졸업한 6개월 차 개발자입니다. 최근 들어 회사에서 글을 쓸 일이 많아졌는데, 생각만큼 잘 써지지 않아 어려움을 겪고 있습니다. 어렸을 때는 글을 읽는 것도 쓰는 것도 좋아했던, 한때는 도서관을 매일 다니고, 국어 과외로 밥도 벌어 먹었지만, 어느 순간 글쓰기가 어색하고 힘들어진 제가 스스로를 돌아보며 적어본 글입니다.

영상의 시대

글쓰기가 왜 어려워졌을까? 를 생각하면서 제 스스로를 돌아보기로 했습니다. 돌이켜보니 글을 소비하고 생산하는 빈도가 많이 줄었다는 것을 느낍니다. 이유는 사람들이 더 이상 글에 관심을 가지지 않기 때문이 아닐까 싶습니다. 다른 사람이 제 글을 안읽으니 딱히 글을 쓸 필요도 없고, 자연스럽게 저도 남의 글을 안 읽게 되는거죠.

제 생각에 글은 요즘 세상에 그렇게 매력적인 정보 전달 수단은 아닙니다. 시각을 통해 전해진 글은 그 자체로는 흑색 이미지에 불과합니다. 머릿속에 가지고 있는 상념과 매치하기 위해 무수한 노력을 해야 합니다. 글자를 모아 단어를 만들고, 단어를 모아 문장을 만들고, 그 문장 사이의 문맥을 찾아가야만 비로소 하나의 글을 이해할 수 있습니다. 다시 말하면, 집중력이 많이 필요로 하는 작업입니다.

반면 영상은 어떻습니까? 영상의 시각적 요소들은 그 자체로 머릿속의 상념과 일치합니다. 거기다 글에는 없는 청각도 이해와 집중을 돕습니다. 굳이 집중하지 않아도 알아서 자극을 쏟아 부어주니 편하고, 이런 자료들이 유튜브에만 가면 4K 고퀄리티로 넘쳐납니다.

연간 성인 독서량이 줄어드는 것이 새삼스러운 일이 아니게 되고, 페이스북의 시대가 저물고 인스타그램과 틱톡이 득세하는 것도 결국 이런 맥락에서 아닐까 합니다. 그러다보니 글은 살아남기 위해서 더 짧아지고, 더 자극적이고, 더 읽기 편한 단어들로 구성됩니다. 자연스럽게 글의 질도, 그 글을 읽는 소비자들의 수준도 떨어질 수밖에 없습니다. 요즘 아이들은 ‘다섯 줄’만 넘어가도 글을 읽기 힘든 지경이 됐다고 하니 어찌 보면 저의 0개 국어는 TL;DR의 시대에 따른 자연스러운 퇴화의 산물일지도 모르겠습니다.

개발자의 글

그렇다면 개발자에게 글이란 어떤 의미일까요?

교환학생으로 스웨덴에 있을 적, 함께 조별 과제를 하던 요한에게 스웨덴 취업에 관해 물어본 적이 있었습니다. 스웨덴이 너무 좋아서 꼭 이곳에서 일해보고 싶다고. 그런데 스웨덴어를 못 해서 걱정이라고. 그러자 그는, 다른 직업은 몰라도 개발자의 언어는 코드이기 때문에 영어만 적당히 하면 충분하다고 저를 격려해줬습니다. 그렇지. 개발자는 자고로 컴퓨터와 인간 세상 사이에서 코드로 의사소통을 하는 사람들 이니, 백마디 말보다 한 줄의 코드가 더 중요한 것이 이 바닥이겠지! 그런 생각을 하면서 요한과 하하 호호 샌드위치를 먹었던 것이 얼마 전이었습니다.

그러나 막상 IT 회사에 들어오니 전혀 그렇지 않았습니다. 오히려 들어와서 글을 쓰는 일이 더 많아진듯 하고, Github만큼 Confluence를, 코드만큼 마크다운에 글을 쓰고 있습니다. 기본적인 이유는 회사에 혼자하는 일은 없기 때문입니다. 따라서 서로의 생각을 일치시키는 것이 중요하고, 그 수단으로 글을 쓰게 됩니다. 어떤 프로젝트를 시작했으면, 코드로 이행하기 전에 스펙을 정하고 유저 시나리오를 구상해서 Workflow를 작성하는 것부터 시작해야 합니다. 프로젝트를 진행하는 중에는 제가 한 시행착오를 다른 개발자가 하지 않도록 시행착오에 관련된 내용을 공유하는 것도 중요합니다. 종종 예전에 근무하시던 분들의 CS 처리 후기 등을 만날 때마다 제가 얼마나 많은 시간을 절약하고 있는 지 감사를 느끼곤 합니다.

코딩에서도 전통적인 글쓰기는 필요합니다. 회사에 들어오기 전 토이 프로젝트를 위해 혼자 끄적이던 코드들이나, 알고리즘 테스트를 보기 위해 번갯불에 콩 볶아먹듯 작성한 코드들과는 달리, 회사에서 쓰는 코드는 이제 저와 컴파일러만의 것이 아닙니다. 옆자리에 앉은 동료도, 재택 중인 리더도, 내년에 들어올 후배도 이해할 수 있는 코드를 작성해야 하고, 그 가독성을 위해서 고민해야 합니다. 이를 위해 제가 쓴 함수에 담긴 함의를 설명하는 함수명이나 주석, 코드 들이 모인 Commit 이름, PR도 모두 정성스레 써야합니다. 외국인과 함께 일하는 국제적인 회사라면 영어로도 작성해야 합니다.

유저들에게 전달도 앱 하나 프로그램 하나 툭 던지는 것으로 끝나지 않습니다. 우선 사용 설명서가 필요합니다. 아무리 좋은 프로그램도 사용자가 어떻게 써야 하는 지 모른다면 외면 받을 수 밖에 없습니다. 그 외에도 Release Note를 써야 할 때도 있고, 피드백이나 리뷰에 답장을 해야 할 때도 있습니다. CS를 처리하는 일이라면 더 골치 아파집니다. 유저가 회사로 찾아오는 경우가 아니라면 유저가 이해하는 바와 개발자가 이해하는 바를 일치시키고, 문제를 해결하기 위한 글을 써야 합니다. 글쓰기가 프로그램에 대한 만족도로 이어지는 순간입니다.

극단적으로 프로그램을 혼자 생산해서 혼자 소비할 생각이라도 글쓰기는 필요합니다. 코딩을 많이 하다보면, 오래 전에 썼던 코드는 자기가 썼던 것임에도 불구하고 잘 알아보기 힘든 경우가 있습니다. 그 때마다 새로 시작하는 마음으로 코드를 들여다보지 않기 위해서는 적절한 글이 필요할 것입니다. 또한, 자기가 배운 것을 복습하고, 되새길 수 있도록 꾸준한 기록을 하는 것이 중요합니다(제가 블로그를 시작한 이유이기도 합니다).

이렇게 놓고 보니 이 영상의 시대 속에서도 글쓰기는 개발자의 숙명인 것 같습니다. 잘 쓰면 좋은 게 아니라 잘 써야 할.

오늘의 나

오랫동안 인정하기 싫었던 사실을 이 글을 계기로 인정하려고 합니다. 오늘의 저에겐 긴 글을 읽는 힘도, 쓰는 힘도 없습니다. 특히 쓰는 힘이 부족한데, 용건만 간단히 말하자는 마음으로 글을 쓰면 글이 너무 영양가가 없어지고, 구체적인 내용을 써보자는 마음으로 쓰면 주저리가 되어버립니다.

정말 다행히도 아직까진 시간과 집중력을 쏟으면 어느 정도 읽을만한 글이 나오는 것 같습니다. 2000자를 쓸 수 있다면 모든 글을 쓸 수 있다는 사이토 다카시 선생의 말을 본받아서 앞으로 꾸준히 2000자 내외로 좋은 글감을 가지고 글을 써서 제 글 쓰는 힘을 다시 키워보고자 합니다.

이 글을 포함해, 앞으로 쓴 글들은 당분간 저의 좁은 식견과 횡설수설로 가득하겠지만, 모쪼록 잘부탁드립니다.

그 외

• 글을 다 쓰고 나서 회사 엔지니어링 블로그에 그것이 알고 싶다 - 왜 개발자는 글을 못 쓸까? 라는 (마치 저를 저격하는 것 같은) 글이 올라온 것을 보았습니다. 마치 이야기꾼이 썰을 푸는 것 같은 느낌의 글이라 술술 읽히기 때문에 비슷한 고민이 있으시다면 꼭 읽어보시기 바랍니다.