멘토님은 빅데이터 자바 백엔드로 개발자 활동을 시작!
스타트업에서 백엔드 2년 6개월 리드직 맡으시다가, 현재는 29cm에서 근무하고 계신다고.
군대에서 남들보다 5~6년 쯤 더 빠르게 진급했다고 한다.
어떻게 하셨을까? 바로 다른 사람 얘기를 많이 듣고, 그 내용을 바탕으로 일에 적용시키신 것.
많은 사람들과 대화를 나눠가며 지식을 쌓았고, 이를 바탕으로 프로그래밍에 대해 잘 모르던 당시에
업무의 생산성을 높이기 위해 엑셀 자동화 프로그램을 만들기도 함.
이것으로 승진을 빨리 하실 수 있으셨다고.
멘토님은 현재도 여러 커뮤니티에서 활동하고 계신다.
그 이유는 오프라인을 굉장히 중요시하기 때문.
왜 오프라인이 중요할까?
오프라인은 사람들과 만나서 정보를 많이 얻을 수 있다.
깊이가 깊진 않아도 되니까 전반적인 지식이 좀 필요하다.
(프론트라도 서버, db, 백엔드 등)
프론트는 백이랑 api 말고는 소통을 할 기회가 별로 없다.
그리고 학생일 경우, 대학생들은 각자 본인들이 목표하는 것들이 다양하기에,
그들과 많은 소통을 통해 넓은 지식을 얻어보면 좋다고.
또한 개발바닥 좁다.
여기 계시는 멘토님들 덕분에 프로그래머스 멘토링에 참여하기도 했고,
그분들이랑 자주 밥도 먹고 커피챗도 한다.
그리고 팀 멤버들이랑 친분을 많이 쌓아놔라.
나중에 프론트 되면 비슷한 연차에 공통점도 많을테니까.
우리 팀 멤버들이 공부하는 방식이라던가, 정보 등등을 얻을 수도 있고.
관계를 유지하는걸 깊게 할 필요는 없다.
얇고 길게 가도 좋아.
그 얇고 길게 가는 가장 좋은 방법이 커피챗 혹은 모각코.
이러한 이유에, 오프라인 참여를 적극 권유.
어떤 분은 대전에서 거주하시는데, 2주에 한 번씩 서울 올라오셨다고.
멘토님의 코드 리뷰 방식
코드 보고 어드바이스 / 과제를 제출할 것
내가 받을 코드리뷰의 부분을 정확히 알아야 한다.
코드짜면서 잘 모르겠는거라던가 등 물어볼거를 가지고 와라
옛날에 류찬규 멘토님께서, 과제를 할 때 내가 어떤 작업들을 해야하는지를 세분화해서
어려운 부분들은 일단 건너뛰고, 할 수 있고 또 빠르게 쳐낼 수 있는 부분들 먼저 하라고 하셨다.
남아있는 어려운 부분들을 멘토님께 리뷰 받고싶다고 말씀드리면 좋을 것 같다.
취직 관련
20~21년 코로나 당시, 개발자에 대한 거품이 너~무 많이 끼어졌다.
오프라인 활동이 안되니까 다들 온라인 시장에 발을 들이게 된 것이 관건이다.
이를 위해 회사는 개발자들을 뽑기 시작했고, 타 회사들과의 경쟁을 위해 회사들은 다양한 복지들을 내걸었다.
바로 높은 연봉과 사내 문화 (코드리뷰 같은..)
하지만 이제는 다르다.
그렇게 개발에 진심인 회사들은 많이 망해가고 있다.
멘토님 전 직장도 그렇고, 유명한 뱅샐.
현재는 뱅샐 개발자의 80%가 퇴직했다고 한다.
그리고 코드리뷰 같은 개발 문화도 회사입장에서는 그렇게 달갑지 않단다.
왜 그럴까 ?
예를 들어, 윗선에서 ‘~~한 것을 만들어라!’ 라는 상황을 가정해보자.
코드리뷰를 원하는 A 부서는 좋은 코드를 위해, 진행 중간 중간에 코드리뷰를 지속해가며 제품을 만든다.
반면 B 부서는 우선 제품부터 만들어내자! 라는 마인드로 빠르게 개발한다.
뭐가 더 좋은지는 개인에 따라 다를 수 있겠지만, 대부분은 B가 맞다고 생각할거다.
왜? 재사용성 있는 코드라던가, 모두가 함께 성장하는 그런 문화가 중요하지않아?
음.. 그렇게 해서 과연 기일 내에 제품을 완성할 수 있을까?
당장 내일이 런칭인데 코드 리뷰나 받고 있을 것 같은데?
멘토님이 강조해서 말씀하신 부분이 있다.
개발자 === ‘제품’을 만들어내는 사람이다.
제품을 만들어내야 결국 개발자도 생존할 수 있는거지.
그리고, 코드리뷰는 그 사람이 작성한 마인드셋을 알아야 제대로 작성해줄 수 있는 부분이고
리뷰 요청자와 리뷰어 모두 시간이 비어야 할 수 있잖아.
제품 만들어내기도 시간이 빠듯한데, 언제 그런걸 해.
빠르게 제품을 만들어내고, 남는 시간에 그런거 하는거지.
그리고 제품을 만들어내기만 하면 끝인가?
더 발전을 시켜서 회사에 이윤을 더 창출해야지.
군인이실때의 멘토님도 군대에 엑셀 자동화 프로그램이라는 제품을 만드셔서 군의 이익을 창출하셨기에 빠르게 승진한 것 처럼 말이다.
에엥..? 그럼 코드리뷰는 필요 없다는건가?
아니다. 당연히 필요하지. 근데 그런 것에 초점을 맞추란 것이 아니다.
그럼 코드 리뷰는 어떤 부분에 초점을 맞춰야할까?
예를 들어 보겠다. 쇼핑몰에서 유저에게 쿠폰을 줄 때, 그냥 주는 것이 아니라 복권 긁는 듯한 방식으로 준다고 해보자.
어? 복권 방식은 번거로워서 사람들이 긁다가 귀찮다고 페이지를 떠나진 않을까?
근데 실제 적용시켜보니 대부분은 잘 긁더라. 데이터가 여기 있다.
그렇다면 이 데이터를 기반으로 기존에 그냥 지급하던 쿠폰제를 수정해볼까? 아니면 복권식 쿠폰에 게임을 가미한다던가 등의 이벤트를 추가해볼까? 처럼,
데이터를 기반으로 특정 부분을 수정하는게 코드리뷰이다.
이렇게보면, 제품군을 성장시켜나가는게 중요해보인다.
이걸 회사 취직에 접목시키는거지.
이제는 회사의 성장 == 나의 성장인 마인드가 취직에 중요하다.
개발자로써 성장을 원하는 곳을 찾는게 아니라,
나는 이러이러한 스택을 가지고 있고, 그걸 토대로 너네 회사 제품을 이러이러하게 성장시킬 수 있다.
라는 것을 어필했을 때, 큰 이점을 가질 수 있다.
실제로 회사에서 실력이 아직 부족해도, 이런 모습을 보인다면 보고 뽑는대.
그렇게 또 중요한게, 제품의 성장을 바탕으로 생각하는 것.
예를 들어, 윗선에서 뭐 만들어라! 했을 때, 제품레벨에서 생각한다는 것.
무작정 알겠습니다~ 가 아니라, 왜 이걸 만들어요? 라고 생각할 줄 알아야 한다.
현대 엘리베이터 사례가 생각나네.
사람들이 엘베 속도가 느린 것 같아요 ⇒
- A회사: 100억을 투자하여 20% 더 빠른 엘베 설치
- B회사 : 엘베 앞에 거울을 설치
결국은 A나 B나 유저의 입장에선 별 차이 없었다고했나? 뭐 암튼 A회사는 개손해봤던..
개발자도 윗선과 같이 제품군에 관하여 생각하는 것이 중요하다.
제품군과 이야기를 할 때 가장 좋은 수단이 ‘데이터’
아까 복권식 쿠폰에 게임을 가미하는 것도 데이터 기반으로 했던 행동이니까.
실제로 사내에는 데이터 분석팀이 있어서 그걸 기반으로 움직이는 실무 사례를 직접 보니까 더 와닿았던 것 같다.
그래서 예진님이 정말 좋다고, 데이터 분석과라고 하셨는데 그쪽 분야에 지식이 있으시니까.
(이는 초반에 넓은 지식 부분에 해당하는 내용)
멘토님이 말씀하신 토픽들을 끌어모아서 회사에서 어떻게 행동하면 더 좋을지도 알려주셨다.
ex )
저번에 실행했던 액션 ‘데이터’를 기반으로 시각화해서 보니까, 어떤 유의미한 점이 있었다~
그러니 이 부분을 더욱 향상 시켜보는게 어떻겠냐?
예를 들어 유저는 그냥 복권을 긁는 것 보다 게임을 통한 복권을 긁는게 더 좋을거다-라는
‘가설’을 세워서 (제품군에 관하여 생각) 그 내용을 바탕으로 토이 프로젝트를 진행해보자.
이런거 하자 했을 때 사람들이 참여할까는 걱정 안해도 된다고.
개발자들은 공부하는거 좋아한다고도 하시네 ㅇㅇ
회사에서 프론트 파트는 내가 하고싶은 코딩이 아니라 신물이 날 수 있다고 하셨다.
하지만 이렇게 접근한다면, 조금 더 주도적인 개발자가 될 수 있지 않을까..?
토막 상식 )
- 아젠다 ? 화두를 가지고 와라~ 라는 뜻