---

개인적인 팁, 성서 공유

이런저런 이야기를 사례와 함께 꽤 길게 풀어냈습니다. 키워드로 정리한다면 프로정신, 어른스러움, Leadership/Followership, GRIT(Growth, Resilience, Intrinsic Motivation, Tenacity) 정도가 있을 것 같습니다.

마지막으로 조금 가벼운 이야기들을 해볼까 합니다. 팁들과, 제가 매주 반복해서 읽는 성서들을 공유하도록 하겠습니다.

나만의 뉴스레터를 만들어 두세요

세상에 블로그는 많고, RSS라는 멋진 기술이 있습니다. feedly같은 앱을 통해 구독하고 단일 공간에서 읽어내세요. Programmer Weekly, GeekNews Weekly같은 뉴스레터에 이메일을 등록하세요. 백엔드 개발자라면 44bits.io는 꼭 구독합시다.

저는 Lets-Study라는 repository에 좋은 글들을 주기적으로 등록하고 있습니다. Watch 누르고, PR을 날려도 좋습니다(홍보입니다).

모각코하는 친구들이 있으면 좋아요

우수한 친구를 옆에 두세요. 내가 조금만 쉬어도 얘가 앞서가겠다 싶은 사람이어야 합니다. 동기부여가 되고, 서로에게 귀감이 됩니다. 온라인이든 오프라인이든 주기적으로 모각코를 하자고 약속해 두세요. 실행력이 10배는 높아지는 것 같습니다.

저는 퇴근 후 일정이 없으면, 집 주변 카페에서 개발자 친구를 만나 2~3시간씩 모각코를 합니다. 덕분에 혼자서는 해내기 어려웠을 대단한 일들을 많이 이뤄냈습니다.

모각코를 목적으로 하는 디스코드 서버나 개발 동아리, 커뮤니티도 많으니 그런 공간의 도움을 받아도 좋을 것 같습니다.

집필은 조금 고민해 보세요

집필 제안은 생각보다 흔하게 옵니다. 책을 쓰는 것은 생각보다 부담되는 일이니 깊이 있게 고민해보기 바랍니다.

내 이름이 적힌 책이 국립중앙도서관에 보관된다는 명예, 그리고 책이라는 소재가 이력서에 적혔을 때 주는 특별한 분위기가 있습니다. 하지만 다음의 항목들이 감당 가능한지 확인해 볼 필요가 있습니다.

• 알려지지 않은 작가의 책은 팔리지 않으며 계약금과 인세가 낮습니다. 물론 홍보가 잘 되면 괜찮을 수 있지만, 부수입을 벌기 위함이라면 너무 큰 도박입니다.

• 장인정신이 있다면 정말 오랜 시간이 걸립니다. 저는 400페이지 가량의 파이썬 입문서의 초고를 작성하는 데에 1년간 약 1,000시간 이상을 썼습니다. 그래도 퀄리티가 만족스럽지 않아 drop을 결정했습니다.

• 의외로 기술적인 성장을 많이 겪지 못합니다. 특정 주제를 단순히 학습하는 것에 비해, 그것으로 문장을 구사해 책을 쓴다는 것은 시간 효율적이지 않습니다. 저는 for문에 대해 3페이지를 작성하는 데 12시간이 걸렸습니다.

• 링크가 깨지거나, 오타가 난 부분이 발견되어도 개정판을 내지 않으면 수정할 수 없습니다.

집필 대신 시도해볼 수 있는 대안은 다음과 같습니다.

• 교육에 대한 열망 때문이라면 온라인 강의로 시작하는 방법이 있습니다. 개인 강의를 개설해도 좋고, 요즘 많이 진행되는 부트캠프 강의도 좋습니다. 생각보다 허들이 그렇게 높지 않습니다.

• 텍스트를 고집하고자 한다면 Ebook을 내거나, Wikidocs, 구름 EDU같은 온라인 지면과 계약하는 방향을 고민해 보세요. 접근성은 온라인이 훨씬 높습니다.

• 그냥 블로그에서 시작하세요. 애초에 책은 계약서에 서명을 하고 첫 술을 뜨기보다, 완성하고 투고하는 편이 더 유리합니다. 여러 출판사를 비교하며 조건을 협상할 수도 있고, 일정에 대한 압박에서 자유롭습니다.

그래도 종이 책을 내고 싶다면 다음의 팁을 참고하세요.

• 링크는 shortener 등을 통해 한 차례 말아두세요. 링크가 깨지더라도 destination만 수정해 주면 됩니다. 개정판을 낼 필요가 없이 말입니다.

• 키워드에 대한 컨벤션을 정해놓고 출발하세요. array, Array, 배열처럼 다양한 컨벤션이 사용되면 혼란스러우며 출판사의 reject 원인이 됩니다.

• bold, italic과 같은 데코레이션은 퇴고 시점에 진행하세요. 미학적인 부분은 생각이 자주 바뀌는데, 그럴 때마다 그동안의 내용을 모두 수정하는 것은 시간이 너무 아깝습니다.

• 기한은 예상보다 4배 정도 미뤄집니다. 충분히 넉넉하게 잡으세요.

• Drop했을 때 별도의 위약금이 지불되어야 하는지 계약서를 리뷰하세요.

• 베타리딩은 최대한 나중에 요청하세요. “수정했는데 다시 읽어주세요” 같은 요청은 베타리더를 피곤하게 만듭니다.

• Ebook도 꼭 내세요.

나쁜 글은 많다

정확하지 않은 지식을 전달하는 글이 많습니다. 작성자가 무책임하다고 비판하기엔 인터넷이라는 곳이 원래 그렇습니다. 판단하는 능력을 길러야 합니다. 예로 최근에, 일론 머스크가 트위터로 출근한 첫날 엔지니어들이 해고되었다는 CNBC 앵커의 보도가 있었습니다.

사실 이 사진의 주인공은 실제 직원이 아니라 어그로꾼이었고, 결국 허위보도를 인정하고 사과하는 일이 일어났습니다.

이렇게 의도적으로 속이려는 것이 아니더라도, 자신감에 의해 착각하는 경우가 많습니다. ‘이렇게 자신있게 주장하는데, 맞겠지’ 하며 받아들이는 것입니다. 더닝 크루거 효과라는 것이 있습니다. 능력이 없기 때문에 자신의 실수를 알아차리지 못하는 현상입니다. 사실 잘못된 정보인데, 작성자가 단지 실수를 발견하지 못 해서 자신감이 드러난 것일 수 있습니다. 그렇게 잘못된 정보가 계속 전파되며 악순환이 일어납니다.

정보의 참과 거짓을 판단하는 것은 높은 지식 수준이 필요합니다. 그러니 그냥 습관을 만드는 것으로 낮은 판단력을 커버할 수 있습니다. 되도록 원문으로 된 공식 문서를 찾고, upvote를 많이 받은 Stackoverflow 질문과 답변을 찾고, 오픈소스에 관한 문제라면 GitHub로 가서 issue나 PR을 대상으로 검색해 봅시다. 개인적으로 믿음직한 블로그 플랫폼이나 사람을 정해두는 것도 좋습니다. 저는 Medium을 좋아하고, 검색 결과에 Outsider(변정훈)님, charsyam(강대명)님, mingrammer(권민재)님, winterjung(정겨울)님의 블로그를 마주치면 먼저 들어가는 편입니다.

-

저는 의도적으로 나쁜 글을 읽으려고 합니다. 반면교사 삼기 위함입니다. 글이나 책이 나쁘게 받아들여지는 이유를 잘 정리하다 보면, 결국은 저의 글을 작성하는 데에 도움이 많이 됩니다.

알고리즘은 똑똑함을 평가하기 위함

많은 논쟁이 발생할 수도 있겠습니다. 알고리즘 문제를 푼 점수로 합불을 평가하는 채용 프로세스가 시장을 지배하고 있습니다. 알고리즘 문제를 잘 풀면 똑똑한 사람일 확률이 높으니 그렇습니다. 똑똑한 사람이라면 실무는 가르치면 되니 말입니다. 등급 높은 학교의 졸업자를 좋아하는 것과 비슷합니다. 시간 효율적인 프로세스라고 생각하지만, 알고리즘에 능하지 않아도 충분히 우수한 사람들을 마주쳐와서 그런지 저는 반감이 드는 것 같습니다.

프로덕트와 조직의 형태, 규모에 따라 알고리즘을 포함한 컴퓨터공학의 중요도는 크게 달라지기도 합니다. 대용량 서비스에서는 최적의 시간복잡도를 찾지 못 하거나, DB 이론을 잘 몰라 이상한 쿼리를 날리면 시스템이 다운되기까지 합니다. 겨우 몇 millisecond와 쿼리 몇 번으로 시스템이 망가지는 게 이해가 되지 않을 수 있는데, 1TB 데이터를 full scan하는 상황을 생각해보면 될 것 같습니다.

-

그러나 저는 알고리즘 지식이 필수적이라고 생각하지 않습니다. 제가 스타트업 개발자라 이런 생각을 하는 것일지 모르겠습니다. 당연히 도움되는 것은 맞습니다. DB Index에 대해 배울 때, 이진 탐색과 tree traversal을 알고 있었던 것은 학습에 많은 도움이 됐습니다. 극도로 발전하고 있는 최전선의 산업은 알고리즘이 이끌어나간다고 볼 수도 있습니다. Stable diffusion의 등장으로 인공지능이 일러스트를 비롯한 예술 분야로 확장하기 시작한 것처럼 말입니다.

하지만 그런 생각이 들었습니다. 알고리즘을 아무리 배워 봐야 논문을 쓸 수준도 안 되고, 게다가 웬만큼의 기본기 없이도 보통의 개발 업무는 되던 것을 느꼈습니다. 그렇다면 실무 능력이 급한 신입 시절부터 알고리즘을 파야 할 필요가 있을까 싶었습니다. 물론 시간이 지나 창조의 영역에 들어가게 되면 다시 찾게 되겠지만요. 그런 입장에서, 지극히 개인적인 의견이지만, BFS와 DFS를 구현해본 사람보다 git conflict를 해결하고 소셜 로그인같은 것을 구현해본 경험이 있는 사람이 더 끌립니다.

알고리즘이라는 게 근본적으로는 시간과 공간복잡도를 잡기 위한 싸움인데, 시간 몇 millisecond, 메모리 몇 KB 낭비해도 되니 git 때문에 쩔쩔매다 워킹타임을 하루 더 쓰지 않았으면 좋겠습니다. 평가에 알고리즘 테스트는 지능을 평가하기 위함이지, 분할정복, Hamiltonian path, 최단 경로 문제처럼 얼마나 많은 지식을 가졌는지 평가하기 위함이 아닙니다.

취업을 위해 알고리즘을 공부할 수밖에 없는 현실을 알고 있습니다. 지식이 아니라 지능이 필요하다는 말은 힘 빠지는 이야기일까 조심스러웠지만, 꼭 하고 싶은 얘기였습니다.

진부한 내용으로 블로깅하지 마세요

저는 블로그를 처음 시작할 때 Java 튜토리얼같은 글을 업로드했습니다. 학습을 하기 위함이었지만, 시간 효율이 극도로 안 좋았습니다. for문 배우는 건 10분이면 하는데, 글 쓰느라 3시간씩 소비하곤 했습니다. 인기의 입장에서도 그렇습니다. 네이버 블로그 당시 Java 가지고 썼던 글 8~90개보다, FastAPI 글 하나의 파급력이 더 높았습니다.

튜토리얼을 작성하는 경험도 물론 소중합니다. 진부한 주제로도 평균을 상회하는 글을 적어내는 능력은 꽤 귀합니다. 하지만 이것은 낭만의 영역이라고 생각합니다. 학습의 입장에서도, 포트폴리오의 입장에서도 진부한 글은 별로 도움이 되지 않습니다.

대단한 블로그라고 생각되는 곳에는 정말 처음 보는 주제의 글이 많습니다. Wireframe님, 박성범님, K리그 프로그래머님 블로그처럼 말입니다. 의미있는 글을 통해 누군가에게 도움이 되는 게 더 중요한 것 같습니다.

프로젝트 너무 많이 뛰지 맙시다

앞의 블로그 얘기처럼, 질적인 것이 더 중요하다고 생각합니다. 저는 고등학생 때 프로젝트를 동시에 대여섯개 씩 했던 적이 있습니다. 말이 되나 싶을 수도 있지만, 다 고만고만한 비슷한 서비스였기 때문입니다. 복붙하는 게 일이었고, 뭔가 새로운 기능을 만들더라도 깊은 리서치를 하기보단 편한 방법을 찾으려 했습니다. 예를 들어, API 문서화를 위해 열심히 리서치했다면 OAS(OpenAPI Spec)같은 것을 발견했겠지만 저는 놀랍게도 엑셀을 썼습니다.

이력서를 작성할 때 보니, 쓸 수 있는 프로젝트가 하나도 없었습니다. 도전적이지도 않았고, 쉽게 하려다 보니 어려움도 없었고, 교훈을 얻은 것도 없었습니다. 제대로 완성되지 않은 것이 많았고, 버그 투성이라 제대로 쓰지도 못 하는 수준이었습니다.

우여곡절과 교훈이 많았던 프로젝트 딱 하나면 되는 것 같습니다. 머리 싸매며 몇 날 고민하고, 선배나 선생님께 물어보고, 그래도 안 되면 현업 종사하는 사람 메일이라도 뜯어서 염치 불구하고 질문까지 해보는 것처럼 말입니다. 공장처럼 코드를 찍어낸 고만고만한 프로젝트 10개는 가치가 없습니다. 시장 조사도 해보고, 에러도 맞아보고, 자동화도 해보고, DB도 날려보고, 테스트도 짜보고, 모니터링도 구성해본 프로젝트 1개가 낫습니다.

취미 가집시다!

개발을 몇 년 하고 말 게 아니라면, 잘 쉬는 능력이 필요합니다. 코딩이 세상에서 제일 재밌고 그 기분이 평생 이어질 것 같더라도 침체기는 옵니다. 재미로, 취미로 하던 개발이 일이 되고 밥벌이가 되면 가끔 코딩이 싫어질 때가 있습니다. 하고 싶은 일이 아니라 해야 하는 일을 위주로 움직여야 하기 때문입니다.

그냥 출근 안 하는 날 며칠 가지고는 회복이 충분히 되지 않습니다. 지식노동이라는 것 자체가 사람을 빠른 속도로 피곤하게 만들기 때문입니다. 직장인의 휴일은 주말과 공휴일, 연차 몇 개 뿐입니다. 요즘은 주 4일제나 전면 재택근무 등 조직원의 체력 안배를 신경쓰려는 조직이 많지만, 아직 주 5일제와 사무실 출근이 과반입니다. 그리고 단지 업무 시간이나 공간만의 문제가 아니기도 합니다.

회복력을 높여 주는 무언가가 있는 것이 좋습니다. 휴가나 주말에 해볼만 한 취미를 가져 봅시다. 되도록 컴퓨터를 벗어나는 것일수록 좋습니다. 저는 사진, 미식, 술, EDM페스티벌, 게임이 취미입니다. 악기, 요리, 운동 등… 휴식도 되고, 경험도 되고, 인간적인 성장이 되는 것도 같습니다.

성서

긴 글 읽느라 고생 많으셨습니다. 대화 내용이나 사례를 글에 집어넣어도 된다고 흔쾌히 허용해주신 많은 분들께도 감사의 말씀을 드립니다. 마지막으로, 다음은 제가 주기적으로 반복해서 읽는 성서들입니다.

• 리더에게 사랑받는 주니어의 특징
• Netflix Jobs
• 누구랑 일할텐가
• 훌륭한 팀원의 조건 - Strong Views, Weakly Held
• 90% 이기기
• 아마추어가 아닌 프로가 되는 법
• 팀장이 된 후에 알게 된 것들
• “일 잘하면 더 몰아준다던데, 적당히 해야 하나?”
• 쥬니어라고 생각하세요?
• 스타트업에서 성장한다는 주니어의 착각
• 나는 어떻게 더 나은 프로그래머가 되었는가
• The Forty-Year Programmer
• 노력은 배신해도, 게으름은 배신하지 않는다
• 코더