ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • DEVGROUND JUNIOR 2019 참여 후기 (2)
    IT행사 2019. 12. 19. 14:09

    DEVGROUND JUNIOR 2019 참여 후기 (1) 

       개발자가 갖추어야 할 9가지 기술 / AI: 막막해 하는 당신에게 

    DEVGROUND JUNIOR 2019 참여 후기 (2) - 현재 글

       내가 주니어 개발자 때 알았더라면 좋았을 것들 / 성장을 바라는 웹 프론트엔드 개발자를 위한 제언

    DEVGROUND JUNIOR 2019 참여 후기 (3) 

      오픈소스 속에서 성장하기  / 절망 드리븐 성장: 함께 일하고 싶은 개발자가 되기까지

    DEVGROUND JUNIOR 2019 참여 후기 (4)

      개발자도 DB 모델링을 알아야 할까요? / AI/데이터 시대를 사는 개발자를 위한 생존가이드

       


     

    내가 주니어 개발자 때 알았더라면 좋았을 것들

    정도현 & 김태현 AWS코리아

     다음 세션은 AWS코리아의 김태현 님, 정도현 님이 차례로 진행해주셨다. 

     

    7번의 이직, 주니어 개발자로 돌아간다면?

     김태현 님은 총 7번의 이직에 대한 이야기를 전해주셨다. 지나왔던 회사에 대한 이야기는 좋은 이야기와 나쁜 이야기가 섞여있기 때문에 블로그에는 적지 않는다. 이직에 대한 이야기 외에, 김태현님은 영어공부에 대한 중요성을 강조했다. 다시 주니어 개발자로 돌아간다면, 글로벌 회사에 지원해보겠다고 하셨다. 지나고 나니 왜 한국 회사만 보였을까? 하는 의문이 생기셨다고 한다. 

     글로벌 회사의 코딩 면접은 LeetCode로 준비하면 되는데, Medium 레벨을 20분 안에 풀 수 있다면 무난하게 코딩 면접을 합격할 수 있다고 한다. 하루에 한 두 문제씩, 1년~2년 공부하기를 권하셨다. 만약 데이터 사이언티스트를 준비한다면, Kaggle로!

     

     

     다음으로 정도현 님의 강연이 이어졌다. 정도현 님은 '정개발'이라는 닉네임을 가지고 계신데, 내가 출퇴근 할 때 가끔 들었던 '나는 프로그래머다'의 그 '정개발'님이셨다. 목소리로만 만나뵈었던 분을 실제로 보게 되니 굉장히 신기했다. 

    Learn and Be Curious와 Deep Dive

     정도현님은 "궁금해하는 것"과 그것을 "깊게 공부해나가는 것"을 강조하셨다. 호기심에 대한 예를 들자면, AI나 자율주행 등 새로운 기술들을 보며 호기심이 생기고, 찾아서 공부해보는 사람이 성장한다고 한다. 또한 깊게 공부하는 것도 중요한데,  만약 면접에서 일하다가 만난 기술적인 문제를 어떻게 해결했는지에 대한 질문을 받았을 때, 잘 대답할 수 있어야 한다. 물론 모든 것을 궁금해 할 수는 없으니 우선순위를 가져야겠다.

     "호기심"이야말로 개발자 힘의 원천이라고 한다. 책, 블로그, 유튜브, 개발자 커뮤니티를 들여다보며 호기심을 지속해나가는 것을 권하셨다. 특히 책에 관해서, 요즘에는 얇고 쉬운 책을 선호하기 때문에 특정한 주제를 깊이 있게 알아보려는 능력이 전반적으로 사라졌다고 한다. 하지만 어려운 부분도 반복해서 이해해보려고 노력하는 자세가 필요하다고 한다.

     

    멋진 이력을 가질 수 있는 방법

     두 가지 이력서를 유지해가자. 

      1, 현재의 이력서

      2. 미래에 내가 가지고 싶은 이력서

     이 두 가지 이력서를 어떻게 일치해 나갈지에 대한 고민이 필요하다고 한다. 만약 현재의 이력서가 발전할 것 같지 않다면, 이직에 대한 고려를 해봐야 한다고 한다. 특히 주니어 개발자는 시니어 개발자와 비교했을 때 고정비용이 적기 때문에 이직의 대미지가 상대적으로 적으므로, 이직에 대한 리스크가 적다고 한다. (저축의 중요성 또한 함께 강조하셨는데, 저축을 하지 않으면 나중에 하기 싫은 일을 돈을 벌기 위해 해야만 한다고 하셨다.)

     

    좋은 개발자는 좋은 작가이다.

     정도현 님은 글쓰기의 중요성을 강조하시면서, "좋은 개발자는 좋은 작가이다"라고 하셨다. 글쓰기와 코딩은 '논리를 쌓아하는 과정'이라는 측면에서 같은 원리로 동작한다고 한다. 내가 하는 일이나, 배우고 있는 것을 잘 설명할 수 있도록 체계적으로 정리하는 연습이 필요하다고 하셨다. 나는 내가 글을 잘 쓰는 편이 아니라고 생각한다. 주변에서도 큰 기대는 없는 것이, 같은 개발자 동료끼리도 "우리 같은 개발자들은 원래 글 잘 못써"라는 농담을 나누곤 한다. 정대현 님의 이야기를 듣고, 개발자라서 글을 못 쓸 수밖에 없다는 핑계를 버리고, 잘 읽히는 글을 쓸 수 있도록 노력해야겠다는 생각이 들었다.

     추천 서적 두 가지를 함께 소개해주셨다.

    https://book.naver.com/bookdb/book_detail.nhn?bid=1528741

     

    조엘 온 소프트웨어

    소프트웨어 개발내용을 다뤄 개발자들에게 인기가 높은 블로그인 조엘 온 소프트웨어 블러그에 실렸던 기사 중에서 유쾌하고 핵심을 찌르는 베스트 기사만 뽑아내 엮은 책으로, 개발자/관리자/CEO를 불문하고 소프트웨어 분야에 종사하는 사람들이라면 누구나 흥미있게 읽을 수 있다.이 책은 현실에서 벗어난 공허한 이야기가 아니라 놓치기 쉬운 프로그래밍 기법은 물론이고 조엘 테스트로 알려진 개발수준 점검기법, 시간, 일정, 개발자 관리기법, 능력있는 개발자를 포섭할 수

    book.naver.com

    https://book.naver.com/bookdb/book_detail.nhn?bid=7366735

     

    코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기

    『코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기』는 코딩 호러 블로그 운영자이자 스택 오버플로우의 공동 창업자인 제프 앳우드가 전작에 이어 소프트웨어 업계 종사자가 본받고 새겨들을 만한 내용을 이 책에 담았다. 쓸데없는 일을 줄이는 법, 프로그래밍, 웹디자인의 원칙, 테스트 등의 내용을 다루고 있다.

    book.naver.com

     두 작가의 공통점이 있다면, 둘 다 StackOverflow의 공동 창업자라고 한다. <코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기>는 처음 들어본 책이고, <조엘 온 소프트웨어>는 대학생 때 존 손메즈의 <소프트 스킬>에서 언급된 것을 보고 읽으려고 시도했다가 실패했던 책이다. 당시에는 C언어를 갓 배우기 시작한 개발 새내기였기 때문에 더 읽기 어려웠을 것이다. 꼭! 다시 읽어봐야겠다. 오늘도 책 장바구니 목록은 늘어난다!

     

    효과적인 학습법

     가장 효과적인 학습법은, 회사에서 하는 일이 그대로 나에게 도움이 되는 경우라고 한다. 나 같은 경우에는 정말로 운이 좋게도, (+ 선임님의 선견지명으로) WPF개발자로 입사했다가 선임님의 크로스 플랫폼 추진으로 웹을 접하게 된 케이스다. 덕분에 일을 핑계로(?) 하고 싶은 공부를 맘껏 할 수 있었다. 이런 경우는 정개발 님이 말씀하신 대로 정말 학습에 효과적인 것 같다. 매일 최소 9시간 머무르는 곳에서 원하는 분야의 개발을 해야만 하니까.

     다른 방법으로는, '남을 가르치는 것'을 추천해주셨다. 커뮤니티를 활용해서 발표할 수 있는 기회를 얻는 것도 좋다고 한다. 여러 번 듣기보다는 한 번 앞에 나가서 발표하는 것이 훨씬 값어치 있다고 한다.

     

    Q&A

    질문에 대한 답변은 정도현 님과 김태현 님이 함께 해주셨다.

    Q. 영어공부를 위한 Tip이 있다면? 💡
    A. Language Exchange. 
        가능하다면 개발자를 찾아보고, 없다면 교사도 좋다.
    Q. 정말 완전 주니어에게 추천해주고 싶은 게 있다면?
    A. 언어 하나 깊게 파기, 영어공부, 블로그

     

     

     


    성장을 바라는 웹 프론트엔드 개발자를 위한 제언

    김민태 우아한형제들

     점심시간이 끝나고, 우아한형제들의 김민태 님의 세션이 시작되었다. 세션의 제목은 "성장을 바라는 웹 프론트엔드 개발자를 위한 제언"이지만 프론트엔드 개발자에 한정하지 않고 '성장'을 바라는 모든 주니어 개발자를 위한 제언을 해 주셨다. 

     

     김민태 님은 질문 하나를 던지며 세션을 시작하셨다.

     "성장해야만 한다! 성장해야만 할까?"

     다른 주니어 개발자들도 마찬가지겠지만 나는 주니어 개발자로서 성장에 대한 압박을 심하게 받는다. 막상 매일매일 열심히 공부하는 것은 아니지만 생산적이지 못 한 하루를 보내면 스트레스를 받는다. 김민태 님은 어떻게 성장하면 좋을지 이야기하기 전에 먼저 '성장'에 대한 근본적인 질문을 던진다. "성장해야만 할까?"

     

    내가 생각하는 성장과, 내가 상상하는 성장

     우리는 스스로 성장에 대한 정의를 내리지만, '그 정의가 나만의 상상이 아닐까?' 하는 의문을 갖는다. 또한 성장에 대한 상상과 현실의 괴리가 분명히 존재한다. 성장에 대한 나만의 호흡 전략 그리고 의미 있는 훈련이 필요하다고 한다.

     

    개발은 긴 마라톤이다.

     김민태 님은 '조급해하면 지는 것이다'라는 조언을 해주셨다. 조급한 마음으로 공부하고 스스로 많이 성장했다고 생각하더라도 그게 끝이 아닐 수 있다고 한다. 

     개발이 긴 마라톤이라고 해서, 마라톤 내내 겪는 모든 일이 '다 경험이겠거니..' 하며 방치하는 생각은 나 자신을 뒤쳐지게 할 수도 있다고 한다. 그러므로 Edge Point를 잡고 성장하는 것이 중요하다. 

     긴 마라톤을 뛰기 위해는 다음과 같은 호흡이 필요하다.

    목표 -> 실행 -> 피드백 -> 충전 -> 목표 -> 실행 -> 피드백 -> 충전 -> .....

     호흡 중간중간 충전을 위한 휴식이 반드시 필요하다고 한다. 계속 달려가려면 에너지가 필요하기 때문이다.

     

    타인이 바라보는 성장, 타인이 평가하는 성장

     타인(사수, 회사)은 나를 평가하기 위해 성장하라고 보채는 것임을 자각하는 것이 중요하다고 한다. 

     그러므로 성장을 위한 결심만으로는 부족하며, 객관화를 위한 측정 지표를 만드는 것이 좋다고 전해주셨다. 또한, 반드시 타인에게 피드백을 받으라고 하셨다. 좋은 피드백을 받기 위해서는 좋은 질문이 필요하다. 막연하게 '이거 잘했나요?', '보완할 점이 있나요?'와 같은 질문은 던지는 것은 피드백을 주는 사람의 입장에서 좋은 피드백을 주기 어렵다고 한다. 때문에 실행계획을 세울 때 구체적인 지표를 세우는 것이 중요하다고 강조하셨다. 예를 들면, '어떤 기능이 추가되어도 흔들리지 않는 탄탄한 구조를 가진 프로그램을 짜겠다.'라는 지표가 있다면 그 지표에 맞는 피드백을 받을 수 있다. 

     '왜 이 기술을 도입했나요?', '유사 기술은 무엇이 있을까요?' 같은 질문에 제대로 대답할 수 있어야 한다고도 덧붙여주셨다.

     

    결심한 목표와 형태는 적절한가?

     목표에는 달성 기준과 성장 목적이 중요하다고 한다. 성장 목적이 없다면 달성 기준도 아무런 의미가 없다. 

     

    성장에 영향을 주는 환경

     김민태 님은 성장에 영향을 주는 환경 중 멘토에 대한 두 가지 생각을 전해주셨다.

     첫 번째는 멘토가 필요 없을 정도가 되어야 어느 정도 성장했다고 생각하신다는 것.

     두 번째는 멘토가 있다면, 그 멘토는 나에 대해 잘 알고 있고 나의 문제점을 정확히 집어낼 수 있어야 한다는 것이다. 

     멘토가 나에 대해 잘 알고 있고, 나의 문제점을 정확히 집어내는지 스스로 알아차리기 위해서는 나의 단점은 내가 먼저 잘 파악하고 있어야 한다. 또한 멘토가 전하는 너무나도 당연한 이야기, 너무 광범위한 이론은 알아서 잘 걸러내기를 바라셨다. 

     

     성장을 주는 환경에는 "기술, 회사, 멘토, 동료, 태도"가 있다.

     이 다섯 가지 환경을 중요한 순서대로 정렬해보자면

    태도 > 동료 > 회사 > 멘토 > 기술

     순서라고 한다. 

     

     태도는 배운 것이 되는 게 아니며, 나중에 교정하기가 매우 힘들다. 어떤 게 좋은 attitude일지 처음부터 잘 생각하고 습득하면 좋겠다는 말씀을 하셨다. 김민태 님이 생각하시는 좋은 태도의 기준은 "얼마나 열정을 가지고 있는지"와 "타인에게 그 에너지를 나누어 줄 수 있는지"라고 한다.

     동료는 나에게 가장 배움을 많이 주는 존재라고 한다. 동료의 태도와 사상, 동료가 이해하는 방식을 통해 많은 영감을 받을 수 있다. 동료에게 열린 마음으로 좋은 점을 배웠으면 좋겠다고 하셨다.

     기술은 가장 배우기 쉬우면서도 어떤 상황에서나 중요하다고 말씀해주셨다. 하지만 평가받는 상황에서는 기술보다는 태도가 중요하다고 한다.

     

    어떤 걸 배워야 할까요?

     매우 흔한 질문이다. 이런 질문에 김민태 님은 "정말 어떤걸 배워야하는지 모르는가?"라고 자문해보라고 하셨다. 인터넷에 잠깐 검색만 해봐도 수많은 아티클이 나온다. 

    개발자 로드맵으로 검색해본 결과

     김민태님은 "어떤 걸 배워야 하나요?"라는 질문은 "실패비용 없이 학습하고 싶습니다."라는 뜻을 내포하고 있다고 생각하신다고 한다. 

     하지만 성장 로드맵에 Best Price는 없다. 유튜브에 "개발자 성장"이라고 쳤을 때 나오는 수많은 영상들.. 따라 하기가 매우 힘들 것이다. 나는 나만의 Case를 만들어야 한다.

     지름길은 없지만, 시간은 있다. 그러므로 조급해하지 말라고 말씀해주셨다. 시간은 나의 편이니, 내 호흡에 맞는 시간 관리법을 만들자.

     

     

     처음 질문으로 돌아가 보자, "성장해야만 한다! 성장해야만 할까?"

     김민태 님은 이 질문에 대한 답변을 주셨다.

      "성장은 환경에 대한 적응이므로 성장해야만 한다. 그러기 위해 어떻게 성장할 것인가 스스로  끊임없이 질문하자."

     

     김민태님은 마지막으로 '혼자 성장할 수 있는 상태' 즉, 자가학습 가능상태를 만들어야 한다고 말씀해주셨다. 

     목표를 설정하고, 피드백을 받고, 무엇이 잘못되어있는지 객관화하고, 다음 목표를 설정할 수 있는 상태가 되어야 한다고 한다.

     

     

    Q&A

    Q. 회사에서 쓰이는 기술과 개인적으로 공부해보고 싶은 기술이 있다. 하지만 지금 상태로는 회사에서 쓰이는 기술 조차 잘 알지 못하는데, 어떻게 방향을 잡아야 하면 좋을지
    A. 회사 기술에 대해 충분히 공부하는 것이 가장 우선순위가 높다. 그 뒤에 배워보고 싶은 기술이 있다면, 개인 시간은 얼마든지 있다. 두 개를 병행해도 문제 될 것이 없다고 생각한다. 팀원들에게도 개인 프로젝트를 권한다. 회사는 기술에 대한 변화를 자유롭게 대응하기가 어렵다. 개발자들은 2~3년 동안 챌린지가 없으면 지루해진다. 그럴 때마다 이직을 할 수도 없으니 개인 프로젝트를 진행하며 회사일과 에너지를 공유하는 것이 좋다. 개인 프로젝트와 회사일이 양립되는 구조라고 생각하지 않는다.
    Q. 개인 프로젝트에 대한 피드백은 어떻게 받는 것이 좋을지
    A. 주변 동료들이 불편해하는 것을 해소해주는 프로젝트를 만들면 좋은 피드백이 온다.

     

     

     

     

    댓글

Designed by Tistory.