탈잉 - 월간 코드리뷰 ver_0.1 을 보고 정리한 글입니다! 어떻게 성장할 것인가?
Session 1, 성장하는 개발자의 '공유의 기술' : 나대기에도 목표가 필요해
발표자 - 레이첼(박미정) 개발자님
개발자로 성장하려면 무엇을 해야 할까?
1.
스터디
2.
블로그 글쓰기
3.
컨퍼런스 발표
4.
오픈소스 기여
5.
집필
... 등등이 있을 것이다! 그러나!
이걸 다 하면 정말 성장할까?
구체적 목표 없이는 곤란하다. 가장 중요한 것은, 나만의 방법을 세우는 것이다.
레이첼의 성장이야기
레이첼은 학습하기 전 항상 이 4개를 고려한다.
1.
나 지금 이거 할 시간이 있어?
2.
왜 하는건데?
3.
그래서 결과물이 뭐야?
4.
그럼 어떻게 할까?
아래 내용들은 이 4개를 기반으로 설명된다.
학습
왜? : 레이첼 같은 경우, 기존의 것을 더 정확히 이해하는 것을 필요로 해서 공부를 한다. 사람마다 방법이 다르겠지!
어떻게! : 업무에 밀접한 내용을 주로 학습하시는 편! 학습해야할 목록을 리스트업 하고, 업무 계획을 할 때 공부 시간도 할당한다.
결과물 : 업무를 잘 해내는 것이다.
다음은 예시이다.
블로깅
새로운 기술 사용법 보단, 실제로 겪은 문제 해결 과정을 작성한다. 이는 더닝 크루거 효과를 피하기 위함이다!
더닝 크루거 효과(Dunning–Kruger effect)는 인지 편향의 하나로, 능력이 없는 사람이 잘못된 판단을 내려 잘못된 결론에 도달하지만, 능력이 없기 때문에 자신의 실수를 알아차리지 못하는 현상을 가리킨다.
왜? : 잘 못된 사실을 믿지 않기 위해서, 실제로 실행을 해보는 편이다.
어떻게! : 블로그에 쓸 거리를 모으기 위해 업무를 진행하며 블로그에 작성할 내용을 위해 키워드를 적어 놓는다. 자세히 적어 놓을 필요는 없으며, 기억을 환기시켜주는 정도면 충분하다.
결과물 : 지식과 깨달음을 온전히 내 것으로 만드는 것이다.
집필
왜? : 이타적으로 다른 사람에게 필요하다고 판단했을 때, 스스로의 가치관을 표현하고 싶다는 동기가 있을 때 집필한다.
깃과 깃헙에 대한 책을 집필하실 때, 다음 플로우에 기반했다.
1.
이에 대한 동기는 깃과 깃헙 관련 정보는 넘쳐나는데 왜 팀원에게 질문을 받을까?
2.
업무 환경을 반영한 자료를 찾기 힘들구나!
3.
업무 시나리오에 기반한 깃 / 깃헙 자료를 집필하면 입문자에게 도움이 되지 않을까?
하지만 집필은 정~~말 많은 고민과 시간을 필요로 한다. 그런 리소스를 투자할 환경이 되는지 고민하자.
어떻게! :
1.
평소에 '왜 없지?' 라고 생각했던 주제를 리스트 업
2.
내가 그 주제를 경험했거나, 곧 경험할 예정인지 판단(해보지 않은 걸 설명하긴 매우 어렵다)
3.
필요성, 차별화, 목차 작성 후 출판사에 제안
4.
(가장 중요한!!) 집필 시간 계획
결과물 : 내 이름으로 된 저작물, 그리고 다음 책에 대한 욕심...
탄탄한 준비와 각오를 통해 집필에 임하자.
혹시 왜? 내용에 언급한 책이 궁금하신 분들은!
나도 한 권 쟁여놔야겠다
발표
왜? : 하드 스킬, 동기부여가 필요할 때 한다. 소프트 스킬, 개발 문화에 기여하고 싶을 때 한다.
결과물 : 스스로의 경험을 회고한 것이다.
어떻게! :
1.
기술, 개발문화 주제를 선정한다
2.
외부 발표든 사내 발표든 데드라인 공표
결론
명확하고 구체적인 목표를 세우고, 결과물을 만들고, 공유를 통해 피드백을 수집하자!
하지만 피드백은 무서웡 그러나 상처받지 말자! 무플보다 악플이 낫다! 내가 필요한 정보를 얻을 수 있다면 이득이다.
모든 것의 시작은 객관적으로 필요성 / 현실성을 판단 해야한다. 나에게 정말 필요한 것을 해라!
모든 것의 마무리는 피드백이다.
웨지의 느낀점
목표만으론 이루어 지지 않는다. 시간을 할당해야 한다! 나에게 부족하던 부분을 보충할 수 있어 좋았다. 더닝 크루거 효과에 대한 부분도 인상적이었다. 믿기지 않으면 수행해보자!
Session 2, 혼자서 오픈 소스로 성장하기 : 기여보다 학습 목적으로 바라본 오픈 소스
발표자 - 아웃사이더(박정훈) 개발자님
코딩을 잘할 수 있는 방법
동영상 강의, 책, 사이드 프로젝트... 다양한 방법이 있지만 최고의 성장방법 중 하나는 좋은 동료 or 사수와 함께 하는 것이다. 하지만 동료와 사수는 내가 선택할 수 있는 것은 아니다.
그런 상황에서 코딩을 잘할 수 있는 방법은?
하나. 개인 프로젝트로부터 시작하기
좋은 코드든, 나쁜 코드든 코드를 많이 작성하는 것이 중요하다.
새로운 프로그래밍 언어를 배우는 유일한 방법은 그 언어로 프로그램을 작성하는 것이다 - 데니스 리치(C, UNIX 창시자)
새로운 기술을 익히기 위해
공부할 기술을 활용해 볼 소프트웨어를 만들어 보는 것은 기술에 대한 좋은 방법 중 하나이다. 기술을 먼저 선택하고, 프로젝트를 시작해보자.
첫 고객은 나 자신, 필요한 프로그램을 만들자
물론 그렇다 해도 내가 필요한 것을 만들어야 한다! 내 프로젝트의 첫 고객은 자기 자신임을 기억하자.
내게 필요한 것을 만들면 요구사항을 직접 정의할 수 있다.
오픈 소스로 공개하자
이렇게 만든 프로그램을 오픈소스 라이센스로 공개한다.
그러면 누군가 이슈를 남겨줄 수도, PR을 날려줄 수 도 있다. 다른 관점을 얻거나 다른 개발자의 기여를 받으며 오픈소스에 대한 벅참 같은 것을 느낄 수 있다.
둘. 기존의 소프트웨어를 다시 만든다
딱히 아이디어가 없을 땐!?
아이디어는 항상 새로 나오지 않는다. 그럴 땐 기존 소프트웨어를 다시 만드는 방법도 하나의 코딩 학습법이 될 수 있다. 요구사항이 정해져 있기 때문에 많은 고민이 필요없다는 장점이 있다.
바퀴의 재발명은 부정적으로 받아들여질 때도 있지만, 효과적인 학습 방법이다.
Example
EX) 웹서버, 랜덤 워드 제너레이터, UUID 제너레이터, HTTP 클라이언트, gRPC 클라이언트, 날짜/시간 관련, 라이브러리..
참고할 소스코드가 있다는 것이 장점이다. 기존 코드를 참고하며 좋은 패턴을 배울 수 있고, 내부 구현을 자세히 이해할 수 있다.
셋. 오픈소스 프로젝트 코드를 읽는다
코드를 작성하는 것보다 읽는 것이 더 어렵습니다. - 조엘 스폴스키 (스택오버플로우 공동창업자)
많이 읽어볼수록 점점 더 빨리, 잘 읽을 수 있다.
그러나 대중없이 읽는 것은 목표도, 동기도 없어 보기 어렵다.
코드를 읽어야 하는 상황
1.
자주 사용하는 프로젝트의 코드를 본다
2.
버그나 이슈가 있을 때 코드를 본다.
3.
문서가 잘 이해 안될 때 코드를 본다.
4.
내부 동작이 궁금해지면 코드를 본다.
보기만 하는 것으로 모자랄 땐
또한 코드를 읽으려면 다음 노력도 병행해야 한다.
1.
실행도 해보자
2.
로그도 찍어보자
3.
디버깅도 해보자
4.
때론 학습 테스트를 작성해 보자
너무 어려워 코드를 읽기 힘들다면...
거대한 규모의 오픈 소스는 오래동안 기여되어 왔기에 복잡도가 높다. 규모가 작은 오픈소스 프로젝트를 찾아 읽어보자.
혹은, 0.1 버전은 어느 프로젝트나 있다. 초기버전도 라이브러리가 해결하고자 하는 문제 내용은 같기 때문에, 되려 핵심적인 내용을 볼 수 있다. 큰 프로젝트에 달려있는 태그 혹은 릴리즈를 참고하여 초기 버전을 살펴보자!
넷. 오픈 소스를 통해 협업하는 방법을 배운다
대부분의 오픈소스는 회사에 비해 높은 수준의 협업이 필요하다.
오픈소스에서 만나는 사람들
서로 본 적이 없는 사람이며, 어느 정도의 지식이나 경험이 있는지 모르고, 하고자 하는 일의 문맥도 모르고, 시간대도 다르며, 신뢰도 하지 않는다...
협업을 위한 방법
이런 사람들과 협업을 하려면? 더 많은 문맥을 제공해야 한다!
1.
문제 정의
2.
도메인 내용 공유
3.
필요한 변화
4.
변화의 효과
5.
예상되는 문제점
번외 ) 영어 학습을 꾸준히 해놓는 것이 중요하다. 대화에 끼고 싶어도 못 낄 수 있다.
메인테이너 입장에서 보자
이슈에선? 이해하기 좋은지, 문제 파악이 쉬운지, 어떤 이슈가 처리가 안 되는지 확인하면서 문제 해결과정에 대한 인사이트를 얻을 수 있다.
PR에선 ? 리뷰하기 좋은지, 어떤 PR이 막혀있는지 확인하면서 좋은 코드에 대해 고찰할 수 있다.
오픈소스를 통해 배우는 협업
회사에선 문맥이 맞춰져 있는 부분이 많기에 생략하는 의사소통이 많다. 그러나 오픈 소스에서 풍부한 문맥을 제공하며 소통하는 연습을 해보면 회사에서의 작업에도 도움이 된다.
개발자의 실수를 막기 위해 소통뿐만 아니라 다양한 시스템이 필요하다. 바로 CI도구 이다.
Travis, Github Actions, Circle CI 같은 도구를 도입하여 가능하다.
CI에서 확인해야 하는 문제
1.
Formatting
2.
Linting
3.
Unit Tests
4.
Integration Tests
코드 커버리지를 확인하기 위해
불특정 다수로부터 통합되는 코드의 동작을 보장하기 위해 테스트 코드 커버리지 또한 중요하다.
Q. 이런 공부방법이 맞을까요?
시간 효율을 따져보자면 프로젝트를 하는 것은 큰 리소스를 요구로 하기 때문에 비효율적으로 보일 수 있다. 그러나 거기에서 얻을 수 있는 깊은 이해까지 고려하면 오히려 효율적이라 생각한다.
웨지의 느낀점
코드를 무조건 많이 쳐보는 것!! 요즘 코드 작성을 도외시하고 CS 이론 공부에 매진하는 경향이 있다. 다시 코드로 복귀하자는 동기부여를 많이 받았다. 좋은 개발자가 되는 가장 빠른 길은 다른 개발자의 코드를 보며 좋은 패턴을 흡수하는 거라는 깨달음을 다시 리와인드 할 수 도 있었다. 오픈 소스 읽기 스터디를 기획해볼까?
Session 3, 개발자의 슬기로운 발표생활 : 발표 기회를 만드는 방법, 그리고 놓치지 않는 방법
발표자 : 치즈 (서지연) 개발자님
발표 경험이 중요한 이유
talk is cheap, show me the code. - 리누스 토르발즈 (2000년)
리누스 토르발즈의 말처럼 개발 실력은 당연히 중요하다. 그러나 서로의 서비스를 이용하는 일(SaaS)이 많아지는 요즘, 커뮤니케이션의 강점은 다시 중요해지고 있을지도!?
커뮤니케이션 능력성장, 커리어 성장, 몸값 성장!
대내외 조직간의 효과적으로 커뮤니케이션 할 수 있는 능력! 프로덕트 조직에서 다양한 분야의 협업자와 개발자의 커뮤니케이션을 중시하면서 커뮤니케이션 능력의 중요도가 높아지고 있다.
과거 발표자의 페이스북 솔루션 엔지니어링 팀 입사 당시에도 다양한 발표경력에서 보이는 커뮤니케이션 능력을 높이 샀다는 피드백을 받은 적이 있다.
발표를 잘한다는 이미지는 커리어 상의 다양한 기회를 제공해준다. 여기서 커리어가 성장하고, 커리어 성장은 몸값 상승으로 이어진다!
기회를 만드는 방법
총탄을 두둑하게 준비해 두어야한다.
평소에 일 하면서, 공부하면서 발표할 생각으로 정리해두자
결론 - 문제 - 해결 방식으로 정리해두면 좋다.
Example - 쿼리튜닝 작업을 진행했다면?
결론 - 응답속도를 개선했다. - 발표 주제가 된다! 먼저 생각해보자.
문제 - 사용자가 많아지면서 응답 속도가 느려졌다. - 발표를 하는 배경이 된다.
해결 - 쿼리의 병목 발견. 인덱스와 조인문으로 쿼리를 개선했다. - 발표의 내용, 디테일이 된다.
회사업무였다면 문제점 같은 경우 대외 발표가 부담될 수 도 있다. 사실 발표 배경은 청중이 크게 신경쓰지 않기 때문에, 그럴 땐 빼버리자!
안물안궁이면 어떡하지? - 먼저 검색해보기
먼저 검색해보자! 한글 자료를 기준으로 한페이지 이내라면, 해 볼만한 발표라고 판단할 수 있다.
다른 컨퍼런스 찾기
회사 업무는 거기서 거기라 발표가 의미 없을 수 있다. 혹은 이미 발표해서 할 게 없다면.
컨퍼런스마다 타겟 청중이 다르기 때문에 우려먹을 수 있다!!
같은 소재를 가지고 다른 방법, 다른 난이도, 다른 주제로 사골을 끓여보자.
사골 발표 예시
Women WHO CODE SEOUL 컨퍼런스에서 발표자님이 발표한
코로나 시대에 개발자가 운동하는 법!
운동 : 닌텐도 스위치 링피트로 운동한 결과를
문자 인식 : Naver OCR로
자동화 : github actions
시각화 : github pages
라는 발표가 있다.
문자인식-자동화-시각화를 Azure 스펙으로 바꾸어
서버리스 코리아 커뮤니티 월별 meet up에서 '개발자가 Serverless로 운동하는 방법'
global Azure 2021에서 '개발자가 애저로 운동하며 살아남는 법'을 발표했다.
사골을 끓이다 보면 조금씩 나아지는 코드, 다양한 스펙에 대한 적응을 얻을 수 있다.
발표할 곳 찾기
어디서 찾을 수 있을까?
꼭 대단한 곳에서 발표할 이유가 없다! 일상 속에 발표를 녹여보자
•
오프라인 코드 리뷰
•
스크럼
•
주간회의
조금 더 규모를 키워보고 싶다면!
•
스터디 리딩
•
지식 공유
•
커뮤니티 밋업 참여
준비가 되었다고 느낀다면!
•
커뮤니티들을 감시하며 연례 컨퍼런스가 개최될 때 연사로 참여해보자!
우선 질러!
발표할 기회가 보인다면 눈감고 질러버리자. 선지름, 후수습. 닥치면 하게 된다. 발표 실력을 기르는 방법은 별 수 없다. 코딩실력을 키우고 싶다면 코딩을 하면 된다. 발표 실력을 키우고 싶다면?? 발표를 해보아야 한다! 어색한 발표는 고통이지만, 성장에는 고통이 따른다. 열심히 두드려보자.
발표 잘하는 법
횡설수설, 노잼일까봐 무서워
짧게! 핵심만 먼저 전달하자. 발표자님은 한 장표(ppt 한 장)에 하나의 메시지만 전달해보자.
너무 많은 텍스트, 한번에 해석하기 어려운 그래프, 긴 코드블록은 청중을 힘들게 만든다.
•
모든 이야기를 전달하는 것 보다 중요한 내용만 전달하자
•
장표 집중 보다는 연사자 발표에 집중하게 하자
•
화면이 빠르게 넘어가게 되면 속도감이 증가 해서 지루할 틈이 없다.
→ 장표는 한 눈에, 집중은 연사자에게 집중!
발표할 때마다 너무 떨려요
익숙해 질 때 까지 연습하는 수밖에..!!! 자주 노출되보자!
개발자는 다양한 청중으로부터 주목받을 일이 잘 없다. 주목되면 떨리는 건 어쩌면 당연하다.
어려운 것은 안 익숙하기 때문이다. 하다보면 쉬워지니까, 연습해보자.
연습 사이클
1.
주변 사람들을 이용해 리허설 하기! (가족, 친구, 팀)
2.
발표 리뷰를 받기!
3.
피드백 반영하기!
망신 당하면 어쩌죠
못 하는 발표는 어차피 까먹는다ㅋ 걱정 말자
발표를 통해 배운 것 - 함께 성장하기
우린 까먹는다. 가장 좋은 기억법은 무엇일까? 서로 설명하는 것이다. 우리의 성장을 위해 발표해보자.
공유의 즐거움도 있다. 뭘 모르는지도 몰라 힘들었던 시절을 생각해보자. 그 때 내게 하나의 좋은 발표가 준 영향력을 떠올려보자.
내가 다른 거인의 어깨위에 올라가 성장했듯이, 내 어깨 위에도 다른 사람들을 올려보자.
웨지의 느낀점
발표가 최고시다... 발표 기회 놓치지 않기!! 나도 발표쟁이가 될테야
Session 4, 오픈소스 프로젝트 키우기 : 파종부터 추수까지! 오픈소스 재배 일기
발표자 - 옥찬호 개발자님
파종 - 어떤 오픈소스 프로젝트를 만들까?
오픈소스 프로젝트를 만든다, 다음처럼 고민이 될 것이다.
•
잘하는 분야 vs 좋아하는 분야
•
잘하는 언어 vs 좋아하는 언어
•
검증된 기술 vs 새로운 기술
어떡하지!!?
상관 없다. 내가 하고 싶은걸 해라.
시작이 반이고, 가만히 있으면 반이라도 가니까 먼저 시작해놓고 가만히 있으면 완성될 것이다.(아닌가?)
꿈은 크고 넓게! 발걸음은 작고 짧게!
발아 - 프로젝트 프로토타입 만들기
프로토 타입을 만들 때 고려해야 하는 사항 - "미니멀리즘 (Minimalism)"
최소 목표를 설정하고, 빠르게 최소기능만 구현해서 완성해봐야 한다!
의욕은 시간이 지나면 떨어진다. 빠르게 완성시켜서 성취감을 얻어야 한다. (애자일!)
써레질 - 빌드/배포 자동화 및 각종 툴 설치
유명한 오픈소스는 몇 가지 공통점이 있다.
1.
CI/CD를 통한 자동화
RosettaStone을 보자
status 배지가 더덕더덕 달려있는데, 이는 다양한 자동화를 의미한다.
지속적 통합 및 지속적 배포를 의미하는 CI/CD를 구현해야 한다.
github actions, Circles CI, jenkins, Travis CI, AppVeyor 등 다양한 툴이 있다. 학습해서 적용해보자!
2.
코드 커버리지
테스트를 진행할 때 얼마나 테스트가 진행 되었는지 확인하는 지표이다. 테스트 커버리지가 반드시 고품질의 테스트를 뜻하진 않지만, 어느정도 지향점이 되어줄 수 있다.
Cobertura, CppUnit, Icov/gcov, Coverage.py, pytest... 다양한 도구가 있다!
3.
정적 코드분석
코드 내에서 발견될 수 있는 보안 취약점, 잠재적인 결함, 위험 등을 찾는 과정
정적 도구의 도움으로 잠재적인 코드의 위험성을 확인할 수 있다.
CodeClimate, Codebeat, Codacy, CodeFactor, LGTM 등이 있다.
다양한 툴을 적용하여 안정적인 서비스를 만들어보자!
모내기 - 협업을 위한 준비 및 홍보
프로젝트 설치 및 사용 방법 알려주기
내 프로젝트에 기여하려는 사람의 컴퓨터에 설치만 되어도 성공이라는 농담이 있다. 운영체제별로 설치법, 사용방법을 가이드하는 것은 기여자에게 매우 큰 도움이 된다! (사용자에게도)
프로젝트 코드 및 구조 문서화하기
최초로 기여하려는 사람에게 프로젝트 전반을 이해할 수 있는 내용을 문서화해두면 기여자의 프로젝트 이해를 높이고, 기여 코드의 품질을 높일 수 있다.
기여 방법 단계별로 알려주기
•
세팅 하는 법(git repository clone 및 브랜칭 전략, 프로젝트 실행하는 법)
•
이슈 작성 하는 법
•
코드 작성 컨벤션
•
커밋 메시지 컨벤션
•
깃 브랜치 전략(리베이스, 머지 등) 컨벤션
•
테스트 컨벤션
•
푸쉬 컨벤션
•
PR 보내는 법 및 업데이트 하는 법
•
정적 코드분석 확인하는 법
단계별로 상세하게 가이드 할수록 다양하고 좋은 기여를 받게 될 확률이 높아진다.
도움이 필요한 부분 등록하기
프로젝트의 우선순위가 높은 부분이나 도움을 받고 싶은 부분을 따로 등록해놓으면 빠르게 문제가 해결될 가능성이 높다.
질문/답변을 위한 창구 만들기
때때론 이슈로 만들기 애매한 간단한 질답도 있다. 이런 경우 빠르게 묻고 응답받을 수 있는 창구를 만들면 좋다. EX) discord 채널!
프로젝트 오픈소스 체크리스트
오픈 소스에 기여하고자 하는 사람들을 위한 가이드가 있다. 해당 가이드를 참고해보자!
모든 준비가 끝났다면, 홍보해보자!!
Facebook, Twitter, Reddit...
국내는 페이스북 커뮤니티가 활발하므로 페이스북에, 해외의 경우 트위터와 레딧에 홍보한다.
제초 - 이슈 및 코드 리뷰 대응
이슈 템플릿 만들기
깃헙은 이슈 템플릿이란 기능을 제공한다. 이슈 템플릿을 통해 어떤 버그가 발생했는지, 재현하려면 어떻게 해야되는가, 어떤 버전에서 발생하는가... 등등을 템플릿을 통해 더 나은 방식으로 버그를 제보받을 수 있다.
PR 템플릿 만들기
PR템플릿도 제공한다! PR에 대한 설명을 적어주고, 이 PR은 어떻게 테스트 하는지... 등등을 템플릿으로 제공해보자.
PR에 대한 코드리뷰
PR에 대해 직접 코드리뷰를 하고 논의를 발전시키자!
이후 Approve, Review, Reject를 진행하자.
추수 - 다음 단계를 위한 준비
위까지 진행되었다면 프로젝트가 궤도위에 올랐다는 이야기다!! 축하축하!
앞으로 무엇을 해야할까?
기능을 추가할수도, 리팩토링을 할수도, 성능을 개선할수도, 새로운 프로젝트에 도전할수도... 그것은 나의 자유이다!
시도해보지 않고는 누구도 자신이 얼마만큼 해낼 수 있는지 알지 못한다. - 프블릴리우스 시루스
자기자신의 한계점을 재단하지 말고 시도하고, 도전해보자.
웨지의 느낀점
오픈소스, 멀게만 느껴졌던 말인데... 생각보다 가까운 곳에 있었을지도! 영어의 장벽을 빨리 극복해야 겠다는 생각이 들었다.
Session 05, Zero to Hero : 非개발자에서 Be개발자로 성장하기까지의 과정
발표자 - 이수진 개발자님
1. 나만의 커리어 로드맵을 그려라
IT업계의 커리어는 사다리가 아닌 정글짐이다.
신기술, 회사내 업무, 관심사에 따른 커리어 변환이 잦다. 그래서!
내 관심사와 성향에 맞는 개발 분야 및 직무를 찾아야한다.
나만의 강점을 만들려면 본인에게 맞는 분야를 찾는 것이 중요하다. 어떤 직군은 기술에 포커싱될 수도, 어떤 직군은 커뮤니케이션, 어떤 직군은 가르치는데 특화되어야 한다.
개발자 로드맵에 따라 배워야할 학습 내용이 다름
다음 사이트에 개발자 별로 어떤 학습을 진행해야 할지 알 수 있다. 한국어로도 잘 번역이 되어있으니, 참고하여 배워야할 로드맵을 구성해보자!
개발자에게 커리어 로드맵인가?
나는 00 개발자로 성장하기 위해 어떤 노력을 할 것인가
1.
Discovery - 현재 나의 상황을 객관적으로 진단하고 필요한 지식과 역량을 발견
2.
Plan - 구체적인 목표와 액션 플랜을 설정
위 두개의 지표를 정해보자!
커리어 로드맵 작성하기
내 커리어 로드맵을 직접 작성하자. 아래 내용을 정리해 보라.
1.
커리어
a.
향후 1-2년, 3-5년 후 나의 모습은?
b.
나는 현재 어느 위치에 있는가?
2.
개발
a.
나의 강점은 무엇인가?
b.
내가 개발해야할 역량은 무엇인가? - 커리어 탐색
c.
이를 성취하기 위해 해야할 일은 무엇인가? - 역량개발 목표탐색
커리어 로드맵 작성하기 - 커리어 탐색
1.
희망 직무의 기술 트렌드 및 요구 역량 이해
•
개발자 로드맵에서 희망 직무를 찾아보기
•
관심있는 회사와 채용 공고를 3개 이상 찾아보고 필요한 소프트스킬, 하드스킬을 정리해 보기
•
관련 업계 롤모델을 찾아보고 배울 점을 정리해보기
•
실무자의 경우, 부서 내 Career Ladder 기준으로 개인 역량 진단
2.
질문해보기!
•
현재 내 지식과 역량이 업계에서 요구하는 수준에 미치는가?
•
특정 지식을 학습하는데 어느 정도 걸리는가? 배우면 할 수 있는 일인가?
커리어 탐색 예시 - 주요역량, 롤모델 찾기
[예시 - 리액트 개발자에게 필요한 주요역량]
Hard Skills
•
Strong proficiency in JavaScript, object model, DOM manipulation and event handlers, data
structures, algorithms, JSX,and Babel
•
Complete understanding of React JS and its mainfundamentals like JSX, VirtualDOM, component life cycle, etc.
•
Preceding experience with React JS workflows like Flux, Redux, CreateReactApp, data structure libraries
•
Understanding of RESTful APIs / GraphQL, HTML / CSS, ES6(variables and scoping, array
methods), code versioning tools like GIT, SVN, etc., popular frontend develop ment tools, CI/CD tools, DevOps, performance testing frameworks like Mocha, Node+NPM
•
Preferred degree in ComputerScience, Information Technology or similar
[예시 - 리액트 개발자에게 필요한 주요 역량]
Soft Skills
•
Competence to translate business needs into technical requirements
•
Open-minded team player, willing to accept feedback and offer suggestions
•
Good time management, project management, communication, and interpersonal skills
•
Capability to write crisp and clear code based on guide line sand best practices
•
Willingness to learn modern - day tools and processes
•
Good problem - solving, trouble shooting skills
•
Creativity and accountability
[예시 - 데이터 분석가 롤모델 찾기]
커리어 로드맵 작성하기 - 역량 개발 목표 설정
•
목표
◦
나는 다음 3~6개월 동안 무엇을 개선하기를 원하는가?
◦
내 앞에 내가 극복해야만 하는 무엇이 있는가?
•
행동 단계
◦
목표를 달성하기 위해 내가 취해야 할 특정 행동은 무엇인가?
◦
어떤 행동이 가장 시급하고(즉 먼저 행해져야 하는) 어떤 것이 덜 시급할까?
◦
만일 내가 더 많은 자료들이나 정보, 목표를 달성할 네트워크가 필요하다면 어디에서 그것을 찾을까?
•
결과
◦
행동 단계를 완성한 것에 대한 대가는 무엇인가?
◦
나의 장기적인 인생 목표를 위해 어떤 방식으로 이 목표를 달성할 수 있는가?
◦
내가 지금은 가지고 있지 않지만 이 목표를 완성한 후에 나는 무엇을 가질것인가?
주의점!!
•
단 시간에 성취할 수 있는 아주 작은 것 부터 시작하기
•
기본기에서 탁월함이 나온다 (프로그래밍 기초의 중요!)
•
소프트 스킬(커뮤니케이션 능력, 리더십) 도 역량이며 경쟁력
2. 영어로 개발 지식을 쌓자
개발자에게 날개를 달아주는 영어
•
전세계 어디서든 일할 수 있는 해외 취업의 기회의 문
•
최신 개발 지식과 정보를 습득
•
전 세계적인 오픈 소스에 기여
•
해외 컨퍼런스 참석 및 발표 기회
•
기술 번역서 출간
영어로 개발을 배워보니...
이수진 개발자님은 처음엔 영어를 잘하지 못했으나~! (지금도 어색할 때 가 있다고 하신다)
[취업 전]
•
처음 개발을 시작할 때 부터 한국어 컨텐츠를 보지 않고 영어 강좌 및 원서만 활용(추후 한국어 컨텐츠로 개념 확인)
•
세 번째 강좌부터 귀가 트이기 시작
•
프로그래밍 용어와 개념에 익숙해지고 공식 문서를 보기에도 편함
•
알고리즘 프로그래밍 문제를 읽고 풀 수 있게 됨
•
어학연수나 유학 경험 없이 충분히 해외 취업이 가능함을 경험
[취업 후]
•
개발자도 사내 발표해야 하는 경우가 매우 많음
•
지금도 비즈니스 영어 수업을 들으며 부단히 노력 중
OSS University
온라인 강좌 만으로 4년제 CS 커리큘럼을 재구성 할 수 있다. 유학을 가지 않고 집에서 MIT 수업을 듣고 해외 취업을 할 수 있는 세상!!!
영어는 내 삶의 영역을 넓혀주는 도구
•
[듣기] 개발 관련 팟캐스트, 유투브 채널 등 구독
•
[읽기] 한국어 번역, 영어로 개발 문서, 서적, 블로그 읽기
•
[쓰기] 개발 문서 작성, 소셜미디어, 블로그 글
•
[말하기] 해외 컨퍼런스 발표하기, 해외 개발자들과 네트워킹 하기
3. 학습과 취업을 동시에 잡는 개발 프로젝트를 만들자
1.
학습의 70%는 업무 경험을 통해, 20%는 타인과의 상호작용을 통해, 10%는 교육을 통해서 일어난다.
2.
업무 경험이 없는 비전공자라면, 프로젝트를 진행하며 업무 경험을 직간접적으로 경험할 수 있다.
3.
Learning By Doing!!
4.
그리고 이 학습은 단순히 프로덕트를 생산 뿐 아니라 다른 컨텐츠로 이어질 수 있다.
개발 프로젝트는 제품을 만들고 파는 경험이다.
내가 만든 프로젝트는 대단하지 않은데 주위에 소개해도 될까? 싶기도 하지만, 이것은 제품을 만들어 판매해보는 경험이다.
•
가공되지 않는 리소스를 투입한다
•
투입된 리소스를 제품에 맞게 가공한다
•
고객 마케팅 및 영업 활동을 통해 제품을 광고한다
•
제품 판매 후 고객 지원 서비스를 제공한다.
내 프로젝트를 주변에 적극적으로 홍보하자!
취업을 위한 프로젝트 - 신입
•
신입이라면 프로젝트 최소 3개 준비하기.
•
프로젝트 소개 문서를 잘 작성하기.
•
실험적인 라이브러리를 도입하지 말 것. 기본기에 충실!
•
Github로 소스코드를 관리
•
기술 스택은 희망 직군 스킬 인벤토리와 일치하도록
•
실제 운영되는 서비스 혹은 데모 버전으로 관리
•
시니어 멘토에게 코드 리뷰 받기
•
테스트 코드 작성하기
취업을 위한 프로젝트 - 실무자
•
내가 고용주를 찾는 것이 아니라 고용주가 직접 우리를 찾게 만들자
•
기업의 가치를 높여주는 프로젝트
•
회사 내에서 오픈소스 프로젝트를 진행
•
현업에서 부딪힌 문제점을 발전시켜 프로젝트를 진행
발표자님의 예시! 실제 해외 취업 성공을 도와준 개인 프로젝트
•
깃허브 저장소로 관리하며 이력서에 포함시킴
•
프로젝트를 만들 수 있는 강좌/프로그램을 등록하여 배우면서 프로젝트를 완성
◦
유다시티 나노디그리 수업을 통해 프로젝트 3가지를 완성 (react, react-redux, react-native)
•
데이터 시각화 수업에 만든 숙제를 발전시켜 프로젝트로 활용 (d3.js을 react와 연동)
→ 총 4가지의 프로젝트를 resume를 포함시키고 싱가폴에서 진행한 밋업에 참가했다가 개인프로젝트만 보여주고 합격이 됨 (그 회사의 기술스택과 일치했음)
우리는 모두 자신의 힘으로 발견한 내용을 가장 쉽게 익힌다 - 도널드 크누스 (수학자, 스탠퍼드 대학교 명예교수)
4. 커뮤니티와 함께 성장하자.
문화는 흙이고 기술은 꽃이다. 기술은 문화라는 흙을 먹고 자라는 꽃이다. 개발자들이 모여서 진행하는 가상의 모인은 꽃을 피우기 위한 문화라는 흙을 비옥하게 만들어 줄 것이다. - 임백준 작가의 칼럼 중(2015)
개발자에게 커뮤니티는 개발자 문화와 모두의 성장을 함께 도와주는 학습 공동체이다.
언어나 플랫폼, 회사, 직책, 나이에 상관없이 프로그래밍에 열정을 품은 사람들이 모여서 성대한 가상 컨퍼런스를 개최하고, 의견을 교류하고, 관심을 공유하여 국내 개발자들의 문화가 윤택해졌으면... - 임백준 작가의 칼럼 중 (2015)
비전공자, 비개발자여도 다양한 커뮤니티 활동에 참여할 수 있다. 공통의 관심사를 가진 사람들과 만남을 통해 성장할 수 있다.
다양한 커뮤니티 활동을 통해 멘티에서 멘토로 성장
발표자님은 개발에 대해 아무것도 모르던 뉴비시절 장고걸스서울(2016-2017)을 시작으로 Rails Girls Summer of Code (2018), Women Who Code Seoul (2018-2019), Singapore.js, Jr Dev Singapore(2019), ReDI School(2021) 을 통해 해커톤 참여, 주니어에게 필요한 기술능력 향상, 커뮤니티 리더들과 네트워킹, 지식 공유, 리더쉽 배양을 얻으셨다고 한다.
개발 커뮤니티는 어떻게 참여하나요!?
•
온라인 커뮤니티
◦
온라인 강좌를 통해 학습 커뮤니티에 활동하기
◦
온라인 해커톤, 세미나, 워크샵 등에 참여하기
◦
핵토버페스트 등 입문자를 위한 오픈 소스 행사에 참여하기
◦
스택오버플로우 등 동료 개발자들의 질문에 답글 남기기
웨지의 느낀점
발표를 보면서 대단하다고 느꼈다. 씨유(우아한테크코스 코치)의 해외 취업 버전을 보는 것 같았다. 목표 설정 - 로드맵 구상 - 실행의 iteration을 꾸준히 반복! 단순히 열심히 보다 중요한 것은 방향성이라는 것을 다시 한 번 느꼈다.
다 보고 느낀 점!
처음엔 3만원이길래 '뭐지? VOD 한 개 가격이 맞나?' 하고 잠시 얼이 빠졌지만, 속는 셈 치고 한번 사봤다. 결과는 만족 현직자들의 학습법을 보며 내가 가는 길이 혼자가 아니라는 것을 느꼈고, 또한 발표자님들의 발표에 일맥상통하는 부분이 있어 신기함도 느꼈다.
공통적으로 강조되는 것은
목표를 확실히 하고
내가 투자할 수 있는 리소스를 파악하며
거창한 것보단 한 번 해보는 것을 추구하며
빠른 피드백을 받기 위해 노력한다는 점!
투자할 수 있는 리소스를 파악해야 한다는 것이 새롭게 와닿은 부분이다. 생각해보면 시간은 공유자원이고 내 인생의 다양한 스레드(일, 가족, 친구, 취미, 공부)가 시시각각 공유자원에 접근한다. 시간을 파악하고 분배하는 효율적인 알고리즘을 구축하여 내가 하고 싶은 것에 적절하게 투자해주는 것이 중요하겠지!
그리고 모든 발표에 깔려있는 공유정신. 내가 도움받은 것을 잊지 않고 다시 다른 사람들을 끌어주는 이 선순환 구조가 날 설레게 만든다. 나 혼자 공부하여 훌륭한 개발자가 되어 큰 문제를 해결해도 그 때 뿐이다. 두고두고 세상을 돕기 위해선 '공유문화'를 길러야 한다. 난 공유문화에 이바지하며 살 것이다. 이 결심이 끊이지 않고 이어지기를 바라며!