여러분이 생각하는 '이상적인 프로그래머'는 어떤 모습인가요? 일곱 살 때부터 코딩을 시작해 백만 달러짜리 앱을 만들어낸 천재일까요? 아니면 10년, 20년 경력으로 수많은 언어를 다룰 줄 알고, 여러분이 커피 한 잔 마시고 올 동안 웹사이트를 통째로 완성해버리는 베테랑 개발자일까요? 혹은 그저 코드만 봐도 사람들이 감탄과 질투로 동시에 울부짖게 만드는 '코드 예술가'일지도 모르겠네요.
물론 저런 프로그래머라면 훌륭하겠죠. 하지만 이렇게 말하면 믿어주실까요? 아무리 뛰어난 코딩 실력이라도 전부가 아니며, 좋은 프로그래밍은 좋은 프로그래머의 절반에 불과하다는 사실을요.
당연히 코딩 방법을 모르면 좋은 개발자가 될 수 없습니다. 하지만 프로그래머에게 필요한 비(非)개발 영역의 역량은 의외로 간과되곤 합니다. 프로 개발자로서 해야 할 일 중 상당수는 코딩과는 무관하고, 오직 '프로페셔널'하기 위한 것들입니다. 진정한 전문가란 업무를 기한 내에 끝내고, 구세주처럼 등장하는 히어로가 아니라 팀플레이어로서 협업할 줄 알며, 고용주나 클라이언트에게 든든한 자산이 되는 사람입니다.
그렇다면 좋은 개발자의 특징은 무엇일까요? 제가 정리한 몇 가지를 소개합니다. 물론 이 외에도 더 많겠지만요.
1. 깨끗한 코드를 작성한다
네, 이것만큼은 코딩 이야기입니다. 코딩이 절반을 차지한다고 했으니까요. 🙂 좋은 코드의 기본은 첫째로 정상적으로 작동하고, 둘째로 다른 개발자가 이해할 수 있으며, 셋째로 너무 고통스럽지 않게 리팩토링할 수 있어야 합니다. 코드는 컴퓨터와 소통하는 도구이지만, 인간과도 소통해야 하는 대상입니다.
몇 달 전의 내 코드를 열어봤다가 '옛날의 나는 도대체 무슨 생각을 하고 있었던 거지?' 하며 시간을 허비한 적이 몇 번인지 셀 수 없습니다. 잘 지어진 함수명, 잘 정리된 구조, 주석과 문서화는 미래의 다른 사람들(그리고 미래의 나 자신!)의 시간을 열 배 이상 아껴줍니다.
좋은 코드 작성법을 더 공부하고 싶다면 아래 책들을 추천합니다.
『Clean Code』
『The Pragmatic Programmer』
『Refactoring: Improving the Design of Existing Code』
2. 트렌드를 꾸준히 따라간다
웹 개발 분야의 트렌드가 요즘 얼마나 빠르게 바뀌는지는 누구나 압니다. 새로 나온 기술이라면 뭐든 좇아야 한다는 뜻은 아닙니다. 하지만 반대편 극단으로 가서 익숙함에 안주하고 게을러지면 '공룡 개발자'가 되는데, 그건 훨씬 더 나쁩니다.
중요한 것은 균형입니다. 몇 가지 핵심 스킬은 탄탄하게 다듬으면서도, 업계의 다른 흐름과 소식에는 최소한 익숙해져 있는 자세가 필요합니다. 아래 매체들은 늘 변하는 우리 업계의 최신 정보를 따라가는 데 도움이 됩니다. 유용한 매체가 더 있다면 댓글로 공유해 주세요!
Hacker News
A List Apart
Smashing Magazine
CSS Tricks
3. 새로운 것에 열린 마음으로 빠르게 배운다
아직 코딩을 배우기 시작한 초입 단계라면 스스로를 너무 몰아붙이지 마세요. Angular를 일주일 만에 마스터해야 한다는 뜻이 아닙니다. 다만 어떤 문제든 그 해결책이 '아직 내가 모르는 것'일 수 있다는 가능성에 열려 있으세요. 여기서 '아직(yet)'이라는 단어가 중요합니다. 내가 모르는 그것은, 배우면 내 도구 상자에 추가할 수 있는 것일 뿐이니까요.
새로운 것을 최대한 빠르고 효율적으로 배우려 노력하는 것이 중요합니다. 빨리 습득할수록 코딩하고 또 다른 것들을 배울 시간이 더 많아지니까요. 참고로 '배우는 능력' 자체도 훈련할 수 있는 하나의 스킬입니다.
4. 집중하고 효율적으로 일한다
우리 뇌는 싱글 스레드로 작동하기 때문에 인간에게 멀티태스킹은 불가능하다는 건 이미 잘 알려진 사실입니다. 할 수 있는 건 작업 간 전환뿐인데, 이건 효율적이지 않을뿐더러 솔직히 이상적인 방식도 아닙니다. 하지만 직장이나 상황에 따라 방해받는 것이 일상이 될 수도 있죠. 그럴수록 한정된 코딩 시간을 최대한 활용하는 것이 필수적입니다.
업무 시간과 비업무 시간을 최대한 분리하고, 서로 침범하지 않도록 하세요. 예를 들어 몇 분마다 페이스북을 확인하는 습관은 생산성을 갉아먹습니다. 일할 때는 불필요한 브라우저 탭을 모두 닫고, 적절한 목표 지점에 도달할 때까지 꾸준히 집중하는 것이 도움이 됩니다. 25분 단위로 집중해서 일하는 '포모도로 타이머' 기법도 눈앞의 단일 과제에 집중하는 데 효과적입니다.
추천 도서: Cal Newport의 『Deep Work』
5. 업무 소요 시간을 정확하게 산정한다
이건 정말 어려운 과제이고, 솔직히 저 자신도 아직 연습 중입니다. 하지만 자신의 능력을 '시간' 단위로 정확히 가늠하는 능력은 매우 가치 있는 스킬입니다. 회사에서 일하든 독립적으로 일하든, 부정확한 산정은 프로젝트 일정을 엉망으로 만들고 주변 사람들에게까지 추가 업무를 떠안깁니다. 최악의 경우, 프로젝트 소요 시간을 크게 과소평가하면 본인이나 회사에 금전적 손실까지 가져올 수 있습니다.
한 가지 덧붙이자면, 항상 시간을 X시간으로 못 박아 정확히 맞출 필요는 없습니다. 보통은 범위로 답변하거나, 프로젝트에 대한 정보가 더 필요해서 지금은 산정하기 어렵다고 솔직히 말해도 됩니다. 소요 시간 산정 감각을 기르는 한 가지 방법은 코딩할 때 자신의 작업 시간을 기록하는 것입니다. (이건 4번과도 직결됩니다. 업무 시간의 절반을 Reddit을 뒤지는 데 쓰지 않는다면 산정도 훨씬 정확해지니까요.)
6. 비전공자에게도 기술 개념을 설명할 수 있다
답답하죠? 코드 블록과 메서드 사이를 신나게 헤엄치다가, 갑자기 현실 세계로 수면 위로 올라와 프로그래머가 아닌 사람들에게 모든 걸 설명해야 한다면요. 그냥 소스 코드를 보고 이해하면 안 될까요?
흔히 생각하는 코더의 스테레오타입은 지하 동굴에 숨어 외부의 방해 없이 키보드만 두드리고 싶어하는 아웃사이더입니다. 특히 성가신 문제를 파고들고 있을 때 방해받으면 흐름이 깨지고 짜증이 난다는 것, 저도 인정합니다. 하지만 함께 일하는 비개발자들도 여러분만큼 중요한 역할을 하고 있습니다. (일단 그들이 모든 대화를 대신 처리해주니 여러분이 굳이 나설 필요가 없죠!)
팀의 모든 구성원과 잘 협업하려면 코드 관련 내용을 그들이 이해할 수 있는 방식으로 설명해야 합니다. 그 첫걸음은, 당신은 세상을 '고쳐야 할 코딩 문제'로 보지만 다른 사람들은 비용, 마감 기한, 클라이언트 같은 원칙 위에서 움직인다는 사실을 이해하는 것입니다.
상대방의 언어와 논리로 소통하는 법을 익히면 훌륭한 팀플레이어로 가는 길이 멀어지지 않습니다. 예를 들어 프로젝트에 새 기능을 추가해 달라는 요청을 받았다면, "아니요, 그건 바보 같은 짓이라 싫어요!"라고 외치며 동굴로 도망치는 대신, "그 기능을 추가하면 약 20시간의 작업이 더 필요하고, 마감 기한도 연장해야 할 가능성이 높습니다"라고 설명하세요.
7. 자존심을 회사에 가져가지 않는다
매일 100% 이것을 해내는 건 최고의 실력자들만큼도 어렵습니다. 하지만 적어도 일할 때 순수하게 자존심만으로 움직이지 않으려 노력할 수는 있습니다. 무슨 의미냐면, 자신이 좋아 보이는 것만이 목표가 되어서는 안 된다는 뜻입니다. 프로젝트, 팀, 회사가 좋은 결과를 내도록 함께 힘써야 합니다. 남을 돕고 자신만이 아니라 모두의 성공을 위해 애쓰는 사람이라면, 모두가 당신과 일하고 싶어할 것입니다.
반대로 자신의 목적을 위해 발판 삼아 남을 짓밟는다면, 결국 자신이 서 있는 다리에 불을 지른 것과 같습니다. 그리고 그 다리가 무너질 때 당신은 딱 그 한가운데 있게 됩니다. 물론 단기적인 이득은 있을 수 있죠. 하지만 모두가 함께 일하기 싫어하는 사람이 되고 싶으신가요?
8. 실수를 숨기지 않는다
실수하는 걸 좋아하는 사람은 없습니다. 그건 인간이니 어쩔 수 없죠. 하지만 프로페셔널이라는 자리에 서면, 자신의 실수를 세상으로부터 감추고 싶다는 아주 인간적인 충동을 이겨내야 합니다.
프로젝트에 부정적인 영향을 주는 실수를 저질렀다면, 본인과 함께 일하는 동료들을 위해 할 수 있는 최선은 즉시 털어놓는 것입니다. 상사에게 말하든, 클라이언트에게 말하든, 말해야 할 사람에게 알리고 바로 복구 작업에 착수하세요. 실수를 덮고 아무도 눈치채지 못하길 바라는 게 때론 통할 수도 있지만, 들키면 신뢰가 심각하게 무너지고 프로젝트는커녕 일자리 자체를 위태롭게 만들 수 있습니다.
물론 사소한 실수 하나하나까지 전부 보고할 필요는 없습니다. 하지만 수정에 추가 시간이 필요하거나 중요한 것을 망가뜨린 실수라면, 본인과 모두를 위해 솔직히 인정하세요. 장기적으로 반드시 더 나은 결과로 돌아옵니다.
9. 도움을 요청하고, 도움을 줄 줄 안다
막혔거나 이해되지 않는 부분이 있다면 질문하는 것을 두려워하지 마세요. 마감 기한이 있는 프로젝트를 진행 중이라면, 도움을 요청하면 한 시간 안에 해결될 문제를 홀로 몇 시간씩 붙잡고 있을 필요는 없습니다.
물론 Google, StackOverflow, Slack 등을 활용해 스스로 최대한 해결하려 노력하는 것과 균형을 맞춰야 합니다. 하지만 특히 회사에 다닐 때는 독립적으로, 아무것도 도움 없이 모든 걸 해내고 싶어 하는 경향이 있습니다. 이게 정말 시간 낭비가 될 수 있죠. 쉽지 않지만 자존심을 잠시 내려놓고 도움이 필요하다는 사실을 인정하세요. 더 빨리 배우고, 더 빨리 업무를 끝낼 수 있습니다.
반대로, 동료가 도움이 필요할 때 도와주는 것도 중요합니다. 저도 웹 개발자로 시작했을 때 회사의 선배들에게 많은 도움을 받으며 성장했습니다. 경력이 쌓이니 이번엔 후배들이 자주 저에게 질문을 하러 왔죠. 업무 중단은 프로그래밍에서 가장 즐거운 순간은 아니지만, 팀플레이어의 일부입니다. 만약 깊은 코딩 중이라면 "몇 분 뒤에 다시 찾아줄게"라고 말하면 됩니다. (문제가 정말 급한 경우는 예외지만요.)
누군가 도움을 요청할 때는, 다음번에 스스로 성공할 수 있도록 도와주세요. 정답만 알려주기보다 맥락과 원리를 함께 전달해서 문제가 어떻게 해결되는지 이해하게 만드는 거죠. 이른바 '물고기를 잡는 법을 가르쳐주라'는 교훈이랍니다. 🙂
이 중에서 공감되는 항목이 있었나요? 반대 의견이 있다면 아래 댓글로 자유롭게 남겨주세요!