저 신입사원 때 지도해 주셨던 분께 받았던 메일 내용인데요. 시간이 한참 지났어도 다시 읽어보면 아직도 뼈를 때리는 말씀과 곱씹어 볼 내용들이 너무 많은 내용이라 공유해 봅니다. 누군가 백날 이야기

저 신입사원 때 지도해 주셨던 분께 받았던 메일 내용인데요. 시간이 한참 지났어도 다시 읽어보면 아직도 뼈를 때리는 말씀과 곱씹어 볼 내용들이 너무 많은 내용이라 공유해 봅니다. 누군가 백날 이야기해도 사실 개인이 이해하지 못하면 한낱 소음에 불과할 텐데요. 아래는 제가 하는 말이 아닌 업계에서 몇십 년 동안 계셨고 최고 자리에도 계셨던 분이 과거에 말씀하신 내용이라 꼭꼭 읽어보시길 추천드립니다. (아직도 존경하는 개발자가 누구냐라고 한다면 전 단연코 이분이 1픽입니다.) 1. (문제풀이 숙제를 내주시며) 알고리즘 교육받으며 탑코더 문제를 하루 세 개씩 푸시는 게 쉽지 않은 일이죠? 어려움은 몰라주고 회사에서 강하게 밀어붙이기만 하는 듯싶어 원망스러운 마음도 드실 것입니다. 그렇게 하는 이유에 대해 설명드리고자 합니다. 첫 번째 이유는 개발자는 기반 지식이 튼튼해야 하고 직접 경험해 보아야 하기 때문입니다. 자전거 타기를 글로 배울 수 없고 여러 번 넘어져 보며 실제 경험을 통해서만 배울 수 있음을 공감하실 것입니다. 소프트웨어 개발도 마찬가지입니다. 직접 작성하고 활용해 보고 문제를 겪어 봐야지만 자신의 실력이 됩니다. 그런 다음 그 실력을 활용하여 보다 창의적인 문제를 해결할 수 있게 됩니다. 언어의 간단한 문법을 책을 통해 읽고 강의를 통해 배우면 매우 쉬워 보이지만 막상 본인이 직접 작성하려면 막막함이 느껴집니다. 그런데 그런 막막함을 한 번에 넘어갈 방법이 없습니다. 결국 자주 작성하여 몸이 기억하는 상태가 되어야만 합니다. 그런 과정을 겪고 계신 것이고 회사에서 그런 기회를 여러분께 제공하고 있는 것입니다. 대한민국 어느 회사를 가도 이 정도로 기초실력을 높이기 위한 기회를 제공하는 회사는 없다고 단언할 수 있습니다. 대부분의 회사는 개인 능력의 발전은 개인의 몫으로 두고 발전하지 못하는 사람은 낙오시켜 버립니다. 저희 회사도 모든 개발자에게 이런 기회를 무한정 제공할 수는 없습니다. 여러분은 신입사원으로 누릴 수 있는 최고이자 마지막 기회를 제공받고 계신 것입니다. 이를 이해하시고 적극 활용하여 문제를 직접 부딪혀 보고 해결해 나가시길 바랍니다. 탑코더 문제를 풀기가 당장은 어렵겠지만 알고리즘 수업을 듣고 이에 대한 이해도가 높아지면 점점 문제 풀기가 용이해질 것입니다. 그런 변화 과정을 스스로 경험하시길 바라는 의도이며 이를 기반으로 향후에도 지속적으로 발전하실 수 있기를 바라는 마음입니다. 두 번째는 개발은 습관입니다. 습관에는 좋은 습관과 나쁜 습관이 있습니다. 개발자의 나쁜 습관이라고 하면 여기저기 인터넷 검색에서 가져온 코드를 모아 그냥저냥 돌아가게 만드는 코드를 생산하는 일입니다. 그런데 무서운 것이 습관은 한 번 들면 고치기 어렵습니다. 문제의 핵심을 이해하고 논리를 개발하고 구현하고 검증하고 개선해 나가는 좋은 습관을 초기에 가지셔야 합니다. 그런 관점에서 탑코더 환경은 매우 유용합니다. 검증할 테스트를 먼저 정의하고 그 테스트를 통과하도록 개발하고 성능, 메모리 관점에서 보다 효과적인 방법을 고민할 수 있는 환경을 제공해 줍니다. 이런 습관은 여러분이 현업에서 당연히 가져야 하는 좋은 습관입니다. 이것을 할 줄 아는 개발자와 그렇지 않은 개발자의 차이는 어마어마하며 할 줄 모르는 개발자는 발전할 수 없습니다. 탑코더 문제가 영어로 되어 있어 어렵게 느껴지실 텐데 불행하게도 개발자는 대부분의 레퍼런스를 영어로 볼 수밖에 없습니다. 그러니 옆에 동료와 협업하여 문제를 이해할 수 있도록 노력하시기 바랍니다. 그리고 커밋 하실 때 로그를 의미 있게 남겨 주시기 바랍니다. 커밋 로그는 해당 코드 변경에 대한 중요한 정보를 제공합니다. 그러므로 어떤 정보를 로그에 남겨 두면 도움이 될지 고민해 보시기 바랍니다. (현업에서 로그 남기는 법은 따로 교육을 받게 되지만 그냥 교육받아 알게 되는 것과 자신이 고민해 본 뒤에 알게 되는 것의 차이는 매우 크니까요) 커밋 시간을 보니 새벽까지 노력하신 분도 계시고 최근 이틀간 커밋 하지 않으신 분도 계시네요. 어차피 개인 선택이라면 제가 더 말씀드릴 이유는 없습니다. 선택에 대한 책임을 지시면 되니까요. 끝으로 여러분이 발전할 수 있는 좋은 기회를 잘 활용하시길 바랍니다. 2. (문제풀이 숙제를 보고 피드백) 여러분의 코드에서 개선하였으면 하는 점을 말씀드리고자 메일 드립니다. 코드를 읽는 주체가 "컴파일러"라고 오해하는 경우가 많습니다. IDE에서 지적하는 문법 오류만 발생하지 않으면 괜찮은 코드라고 생각하시는 경우가 많죠. 하지만 코드는 혼자 작성하는 경우라도 읽히는 시간이 훨씬 많으며 읽는 대상도 컴파일러가 아닌 사람입니다. 결국 좋은 코드란 사람이 이해하기 쉽고 잘 읽을 수 있도록 작성한 코드입니다.= 단적인 예로 반복문을 중첩하여 작성하지 말라고 하는 이유는 사람이 논리적으로 이해하기 어렵기 때문입니다. 그리고 변수와 함수 이름을 의미 있게 작성하라는 이유도 사람이 읽고 이해하기 좋게 하려는 것입니다. 결국 좋은 개발자는 클린 코드(Clean Code)를 작성하는 개발자이며 클린 코드를 통해 "이해하기 쉽고", "변경이 용이하며", "유지 보수 비용이 낮은" 제품을 개발해야 합니다. 이에 클린 코드(Clean Code) 작성에 도움이 될 자료를 첨부하였습니다. 꼭 읽어 보시고 실천하시기 바랍니다. 그리고 코드의 복잡도가 너무 높습니다. 조건문 안에 여러 조건을 붙여 작성하시면 실수하기 딱 좋습니다. 이에 코드의 복잡도를 낮게 유지하는 방법을 담은 자료도 첨부하였습니다. 탑코더 문제는 적어도 하루에 1round의 문제는 다 푸시는 것이 필수이고 그 이상으로 하시길 당부드렸는데 많은 분이 한 문제 정도에 머무시거나 그마저도 완료하지 않으시는 경우가 많습니다. 처음에는 적응하시는 단계로 생각하였고 시간이 지날수록 문제를 해결하시는 속도가 빨라질 것이라 기대했는데 그렇지 않네요. 스스로 발전하실 수 있는 기회를 이용하시지 않으시면 저로서도 더 이상 지원해 드릴 방법이 없다는 점 명확하게 말씀드립니다. --- 왜 우리는 피가 되고 살이 되는 내용의 메시지였다는 걸 지나고 나서야 알게 될까요? 늦었다고 생각할 때가 가장 늦었다는 명수 옹의 이야기처럼 지금이라도 개발자로써 지녀야 할 자세를 바로잡는 것도 좋을 것 같습니다.