개발자가 쉽게 터득하지 못하고, 빨리 터득하지 않으면 안 되는 스킬이 있다. 9년 차에 접어들면서 '아, 이런 건 미리 터득할걸' 또는 지금 와서 생각해 보니 '잘 터득했다'라는 스킬이 있어서 이에 관해 이야기해 보겠다.
1️⃣ 뛰어난 의사소통 능력
1인 개발자가 아닌 이상 회사를 다니든 창업하든 상관없이 여러 사람과 함께 일하게 된다. 특히 연차가 쌓이고 기술 리더가 될 수록 많은 사람과 함께 해야 하고 그들을 이끌어야 하는데, 많은 사람들과 효과적으로 일하려면 의사소통 스킬이 뛰어나야 한다. 특히 가장 중요한 것은 문서나 특정 문제를 빠르게 이해하고 내용을 잘 정리할 줄 알아야 한다. 내용을 빨리 이해하는 건 효과적인 논의를 하고 중요한 질문을 던지기 위함이다.
정리된 내용은 여러 사람이 한 번에 알아들을 수 있게 간결하고 임팩트 있게 말해야 한다. 큰 프로젝트를 맡으면 서로 다른 이해 관계자 여러 명, 많게는 수십 명과 일하게 된다. 이해관계가 다른 사람은 가진 배경과 지식 그리고 기술 전문 분야가 다르기 때문에 한 번에 알아들을 수 있도록 말하는 것이 아주 중요하다.
그리고 마지막으로 중요한 질문을 던질 줄 알아야 한다. 중요한 질문이란 생각지도 못했던 점을 생각하게 만드는 것이다. 예를 들어 라지 시스템 설계의 '틈'을 빠르게 파악하고 설계자에게 되묻거나, 문제의 핵심이 될 수 있는 '포인트'를 물어 보는 것과 같은 것이다. 질문을 잘하는 것도 의사소통 잘하는 법에 포함된다. 중요한 질문을 머릿속에는 잘 정리했는데, 의외로 말로 잘 내뱉지 못하고 소통하지 못하는 경우가 있다.
2️⃣ '틈'을 재빠르게 파악하는 능력
당연한 이야기지만 기술이나 문제의 핵심을 재빠르게 이해하고 파악해야 한다. '틈'을 빠르게 파악하고 좋은 피드백을 주는 선임이 있는 팀과 그렇지 않은 팀의 효율성 차이는 아주 크다. 예를 들면, 예전에 <좋은 개발자가 되기 위한 버그 고치는 데 드는 비용>이라는 글을 포스팅했을 때, 개발 시작하기 전에 충분한 검토와 논의를 거쳐 설계의 틀을 잘 잡는 것이 중요한 이유에 관해 이야기 했다. 하지만 무조건 검토와 논의를 한다고 틀이 잘 잡히는 것이 아니다. 검토에 참여한 사람들의 검토 실력에 따라 이 과정이 효과적일 수 있고 아닐 수 있다. 예를 들어, 나는 예전에 주니어 시절 선임들이 조용히 설계 문서를 읽고 듣기만 하던 설계 검토 미팅에 참여했던 적이 있다. 결국 설계를 마치고 개발 단계를 마친 후 기존 설계의 흠을 발견했고, 코드 전체를 리펙토링하는 불상사가 발생했다.
또한 기술 이외 개발에 방해되는 요소의 틈을 빠르게 파악하는 것도 아주 중요하다. 단순히 코딩만 한다고 기술을 선보일 수 있는 게 아니다. 프로젝트 관리, 주니어 개발자 코칭 등등 여러 가지 요소도 함께 포함된다. 이러한 요소에도 '틈'이 발생할 수 있는데, 그 틈을 빠르고 자발적으로 캐치한 후 고칠 수 있어야 한다.
개인적으로 '틈'을 파악하는 건 쉽게 배울 수 없는 능력이라고 생각한다. 제일 좋은 방법은 '틈'을 잘 파악하는 선임과 함께 일하며, 그들을 롤모델로 삼고 따라해 보는 것이 많은 도움이 되었다. 그 외에도 빅픽처를 보는 능력을 키우면 확실히 틈을 파악하는 능력도 같이 느는 것 같다.
3️⃣ 빅픽처 보는 능력
알고리즘 문제를 풀 때 문제의 단편만 보고 바로 코드부터 쓰는 경우가 다반사다. 이렇게 문제의 한 부분만 보고 풀면, 틀린 답을 내리기 쉽다. 하지만 큰 그림을 먼저 보고 포괄적인 솔루션을 제공하면 좋은 답을 내릴 가능성이 높다. 단순히 코딩 문제에만 국한되지 않고 라지 시스템 설계 또는 비즈니스 관련 결정을 내릴 때도 빅픽처를 잘 볼 줄 알면, 퀄리티가 높은 결과물을 낼 수 있다. 큰그림을 독보적으로 잘 보는 선임이 있었는데, 아무리 머릿수가 많은 개발자들이 모여 결론을 내려도 찾을 수 없었던 답을 그 선임은 한 번에 찾아줬다. 일의 효율성도 높아지지만, 다음에 더 큰 문제(예: 잘못된 시스템 배포, 버그 배포 등등)를 막을 수 있다.
4️⃣ 프로젝트 관리 능력
많은 개발자는 코딩만 잘하면 된다고 생각한다. 하지만 개발자에게는 코딩뿐만 아니라 설계 실력과 프로젝트 관리 능력도 있어야 한다. 결국 모든 개발자는 특정 프로젝트를 완료해야 하고, 그 프로젝트를 진행하는데 프로젝트 관리는 필수 영역이다. 특히 기술 리더나 팀의 선임이 될수록 이 능력이 뛰어나야 한다.
5️⃣ 같이 일하고 싶은 동료가 되는 능력
팀에 같이 일하기 싫은 동료가 있으면 문제가 꼭 터진다. 같이 일하기 싫은 동료란 자기주장만 옳다고 여기거나, 남의 말에 꼬투리만 잡는다거나, 의사소통이 전혀 안 되는 사람 등 여러 부류가 포함된다. 이런 사람이 있으면 제일 큰 문제는 개발자들이 효율적인 논의를 하지 못하게 된다. 논의를 제대로 못 하면 틀린 답을 내리기 쉽고, 비즈니스에 안 좋은 영향을 미치는 결과를 내기 쉽다.
또한 모든 사람은 똑같이 하루에 24시간을 갖게 되고, 그중 적어도 8시간을 일하는 데 사용한다. 8시간 동안 함께 일하고 싶은 동료와 일할 수 있으면, 일하는 게 즐겁다. 일이 즐거우면 내 생활에 활력을 갖게 되고, 더 나아가 좋은 결과물을 낼 힘이 되기도 한다.
6️⃣ 라지 스케일 시스템 설계 능력
코딩 공부할 때 간과하는 것은 설계 공부다. 그중에서도 라지 스케일 시스템 설계 능력이 아주 중요하다. 근데 라지 스케일 설계는 학교에서 쉽게 배울 수 없고, 트래픽이 다량으로 발생하는 시스템을 다루어야지만 배울 수 있는 유용한 지식이다. 단순한 설계나 코드는 요즘 챗GPT가 쉽게 힌트를 줄 수 있지만, 라지 스케일 시스템 설계 능력은 단순하게 완성할 수 없다. 많은 아이디어를 검토하고, 절충점을 찾고, 다양한 전문가와 검토를 거쳐야 하는 복잡한 프로세스다.
개인적인 생각이지만 라지 스케일 시스템 설계 능력은 경험을 통해서만 배울 수 있다. 최대한 대량 트래픽이 발생하는 곳에서 일해보는 게 좋다. 하지만 대량 트래픽이 발생해도 설계할 기회가 없으면 아무짝에 쓸모없다. 따라서 라지 스케일 시스템 설계를 할 수 있고 배울 수 있는 팀에서 일해보는 게 좋다. 그 외 라지 스케일 시스템 설계 관련 책을 읽어보는 것도 도움 되었던 것 같다. 그런데 확실히 실무에서 경험해보고 책을 읽어보니 개념 이해가 훨씬 빨랐다.
7️⃣ 글 잘 쓰는 능력
"개발하는 데 코드만 잘 쓰고 의사소통만 잘하면 되지 않을까?"라고 할 수 있다. 코드만큼 중요한 것도 코드를 잘 설명하는 것이다. 아무리 가독성이 높은 코드를 작성해도 비즈니즈 로직이 복잡하면 추가 설명이 필요하다. 마찬가지로 설계만큼 중요한 것도 설계한 것을 잘 설명하고 새로운 팀원이 와도 쉽게 그 시스템을 이해할 수 있도록 전문 지식을 잘 문서화해야 한다. 무작정 문서를 작성하는 것보다 '내용 전달을 잘하는 문서'를 작성해야 한다. 내가 개인적으로 겪은 일인데, 새 팀원이 조인할 때마다 일대일 면담을 통해 일일이 시스템과 개념을 설명해야 했던 적이 있다. 지속할 수 없는 방법이라고 여기고 필요한 정보를 문서화를 했고, 똑같은 질문하는 팀원이 있으면 작성한 문서를 먼저 읽어보라고 했다. 그런데 팀원이 문서를 읽어도 이해를 못 해서 결국 다시 일대일 면담으로 불분명한 점을 확실히 해야 했다. 이 경험을 통해 '문서도 잘 적을 줄 알아야 하는구나'를 느꼈다. 그 후 좋은 문서를 많이 읽어보고 여러 사람의 검토를 걸쳐 최대한 많은 정보를 간결하고 쉽게 전달할 수 있도록 노력하고 있다.
