Last updated on 1월 26th, 2024 at 04:48 오후
얼마 전, 패스트캠퍼스의 안드로이드 개발 SCHOOL 수강생들을 대상으로 리디 주식회사의 개발센터 선임 개발자를 거쳐 현재 Smarteen App Challenge의 멘토, 삼성 SDS의 sGen Club의 ICT 개발 업무를 겸임하고 계신 박민수님의 특강이 있었습니다. ‘주니어 개발자’들이 명심해야 할 점에 대해 전달해주셨죠. 핵심만 꼽아 정리했습니다. 주니어 개발자라면 꼭 알아야 할 일곱가지!
개인의 성장에 대해
새로운 문제에 유연하게 대처하기 위해서는 ‘문제 해결력’을 키워야 한다.
이는 공부가 아닌 경험을 통해서만 가능하다.
1. 기술도 물론 중요하지만 ‘경험’이 더 중요하다.
최대한 많은 경험을 쌓는 것이 중요하다. 현업 개발자에게 가장 중요한 역량은 ‘문제 해결 능력’인데, 이는 혼자 하는 공부로 얻을 수 있는 것이 아니다. 경험을 쌓을수록 문제를 미리 예측할 수 있으며 어떠한 상황에도 유연하게 대처할 수 있는 능력을 기를 수 있다.
나도 수많은 경험을 했지만, 개발은 끝이 없는 영역이기에 여전히 예측할 수 없는 문제들이 많다. 끝없이 몸으로 부딪히며 ‘문제 해결력’을 기르는 것이 중요하다. 이제 막 개발 분야에 입문했거나 경력을 쌓고자 하는 주니어 개발자라면, 여러 제품을 개발하며 경험을 쌓는 것을 권한다.
2. 모르는 것을 부끄러워하지 마라
실력이 부족한 개발자는 나쁜 개발자가 아니다. 나쁜 개발자는 자신의 부족한 점을 드러내지 않는 사람이다. 이런 사람은 협력하는 팀원들을 힘들게 만든다. 모르는 것을 모른다고 해야 모두가 행복해진다. 모르는데 아는 척을 하는 순간 본인 뿐만 아니라 모든 이들의 불행이 시작되는 것이다.
아는 척을 하면 그 순간에는 사람들의 눈총이나 부끄러움을 피해갈 수는 있지만, 결국 전체적인 업무 효율은 떨어지게 된다. 그에 대한 책임은 팀원들이 지게되는 것이다. 그러니 솔직하게 말하며 학습해 나가는 것이 최선의 방법이다. 모름을 인정할 때 업무가 효율적으로 돌아간다.
3. 나를 성장하게 하는 남의 코드
동료의 어떤 코드라도 읽어보고, 분석해보라. 그게 잘 쓴 코드든 못 쓴 코드든 다른 사람의 코딩을 접하는 것은 자신의 실력을 높이기 위한 좋은 방법이다. 또한 이는 갇혀있던 우물에서 벗어날 수 있는 지름길이다.
세상에는 실력이 뛰어난 개발자가 정말 많다. 그만큼 배울 수 있는 기회가 많다는 뜻이다. 어떤 방식이든 괜찮다. 똑같이 배껴 써보는 방법도 좋고, 상대방의 코딩을 리뷰해주는 것도 좋다. 그 과정에서 어느새 개발을 바라보는 시야가 넓고 깊어진 자신을 발견할 것이다.
4. 남을 성장하게 하는 나의 코드
Open Source 활동을 자주 할 것을 권한다. 내 기준으로 짠 코드를 타인의 입장을 고려해 정리정돈할 수 있기 때문이다.
Open Source 활동을 하면 말 그대로 자신의 코드를 공개하는 것이기 때문에 누구든지 부끄러움을 피하고 싶은 생각에 보다 큰 공을 들여 코딩을 하게 된다. Method 이름 한 개조차 가볍게 적을 수 없다.
협업에 대해
1. 합리적인 일정 산출
전체 프로젝트 기간에서 기획과 개발 일정을 정해 두었더라도 막상 실제 프로젝트가 시작되면 초반 기획 부분에서 생각보다 많은 시간을 할애하게 되는 경우가 많다. 그런 변수가 생기면 프로젝트 진행 속도가 느려지게 되고, 결국 이는 개발 기간의 단축으로 이어지기에 프로젝트의 전체 완성도가 떨어지게 된다. 따라서 전체 기간 중에 세부 목표를 설정하여 기간을 나눠 합리적인 일정을 짤 수 있어야 한다. 너무 짧지도, 그렇다고 너무 길지도 않아야 한다. 최대한 많은 변수들을 고려해 일정을 짜고, 그 안에 완수하도록 노력해보기를 권한다.
2. 주석이 필요 없는 코드를 짜라
현업에 들어가면 혼자서 코딩하는 일은 없다. 하나의 프로젝트에 다양한 사람들이 직·간접적으로 참여하기 때문에 여러 이해관계가 얽혀있다.
그렇기 때문에 내가 구현한 결과물을 이해시키고 함께 더 나은 결과물을 만들고자 할 때 함께 일하는 사람들이 알아보도록, 그래서 커뮤니케이션이 원활하게 이뤄지도록 코드를 짜야 한다. 기능을 구현하는 것은 스스로 노력해서 만들어낼 수 있지만, 프로젝트에서 생각보다 많은 시간이 투입되는 부분이 바로 이 커뮤니케이션 부분이다.
사람들이 쉽게 이해할 수 있는 코딩에 대해 로버트 마틴이 저술한 <Clean Code>는 다음과 같이 말하고 있다. ‘코딩을 할 때 코드 앞에 주석을 달지 마라’. 이는 주석이 있는 것 자체로 가독성이 없는 코딩임을 암시하고 있는 것이기 때문이다. 주석이 없어도 남이 보고 이해할 수 있는 코드를 짜야 한다.
3. 누군가의 이슈는 모두의 이슈다
팀은 하나의 서비스를 위해 달린다. 디자이너도, 기획자도, 개발자도 모두 하나의 서비스를 런칭하고 버전을 업데이트 하며 오롯이 하나의 목표를 위해 최선을 다한다.
그렇기 때문에 한 명의 이슈가 팀원 전체의 이슈라는 생각으로 프로젝트를 진행해야 한다. 만약에 디자이너, 기획자, 개발자가 팀을 이뤄 11월 30일에 서비스를 런칭할 예정인데, 개발자가 발견한 중대한 에러로 인해 계획된 일정보다 3일정도의 시간이 더 걸리게 됐다면 이는 개발자 한 명의 이슈가 아니다.
따라서 팀으로 활동할 이들에게 발생할 이슈는 곧 팀원 모두의 이슈이기 때문에 작은 이슈라도 팀 내에서 공유가 원활해야한다. 자신에게는 작은 일이 팀 전체에게는 큰 여파로 다가올 수 있기 때문이다.
