팀장님이 팀 이동을 하시고 혼자 개발을 시작하게 되었습니다.
당시 팀 구조는 직군별이 아닌 서비스 단위로 구성되어 있었습니다.
그래서 기획자 3분, 마크업 개발자 1분, 저 이렇게 5명이 한 팀이였습니다.
개발자가 저 혼자이다보니, 개발에 관해서 얘기를 나눌 사람이 없다는 것이 힘들었습니다.
출근하고 퇴근할때까지 커피도, 사적인 대화도 전혀 없는 날이 많았습니다.
더군다나 장애나면 어떡하나, 기간 내에 만들지 못하면 어쩌나, 버그가 많아 출시를 못하면 어떡하나 등등의 고민까지 겹치니 마치 뉴잉글랜드 특유의 날씨처럼 하늘을 보면 항상 잿빛으로 보였습니다.
실제로 매일 하늘이 그랬을리 없겠지만 기억 속은 그랬습니다.
시니어 개발자님은 언제 오시려나하는 마음으로 하루하루 버티고 있었습니다.
5-1. 첫번째 후임
어느날 출근하자마자 불쑥 사장님께서 같이 최종면접에 들어가자고 하셨습니다.
"사장님과 단 둘이서 최종면접이라니?"
라는 생각으로 뻘쭘한 자세로 이유를 여쭤봤습니다.
사장님 왈, 오늘이 신입 개발 지원자 2명의 최종 면접이 있는 날인데 결국 둘 중 한명은 함께 일 할 예정이라 같이 일할 사람이 면접에 들어가는게 맞다고 생각한다고 답변주셨습니다.
다시 생각해도 당시 사장님은 정말 유연한 사고를 갖고 계셨던것 같습니다
그래서 경력 2년도 안되는 제가 최종 면접관으로 들어가게 됩니다.
최종 면접에 오신 두 분은 스타일이 완전히 달랐습니다.
한 분은 면접 준비를 굉장히 철저하게 준비를 해 온 상태였고, 다른 한 분은 천상 개발자의 느낌이였습니다.
준비가 철저했던 분은 자기소개가 이미 유창하게 나왔고, 면접 시작하자마자 준비한 포트폴리오를 저와 사장님께 나눠주셨습니다.
면접 과외를 받으셨나? 라는 생각이 들 정도로 정성껏 준비하신게 느껴졌습니다.
다만, 포트폴리오를 보면서 들었던 생각은 "코드를 보고 싶다"였습니다.
포트폴리오 특성상 보여줄 수 있는건 기술 스택 / 목적 / 프로젝트 기능 소개 / 화면 등 외형적인 것만 포함됩니다.
근데 이런 내용들이 개발자를 평가하는데는 크게 도움이 되지 않습니다.
(물론 저 개인의 느낌입니다.)
(출처: 삼성 소프트웨어 멤버십 면접관 후기 2탄)
앞에 계신 분이 어떤 코드를 작성하는지가 궁금했습니다.
기능만 돌아가는 코드를 작성하는 분인지, 정말 많은 부분을 고려해서 코드를 작성하는 분인지가 궁금했었는데, 이걸 확인할 방법이 없어서 조금 아쉬웠습니다.
이렇게 길게 쓴 이유는 아직 많은 분들이 포트폴리오를 어떻게 준비해야하는지 고민하시고,
대학교 취업 센터 혹은 교수님들조차 포트폴리오를 만들어야 한다고 부추기는걸 봤기 때문입니다.
Github과 블로그, 개인 프로젝트를 진행하시는걸 적극 추천드립니다.
포트폴리오를 제출하신 분은 학교 수업 외에도 직접 국비교육을 듣고, 여러 기업에서 인턴등을 하면서 착실하게 준비해왔다는걸 이력서와 대화로 알 수 있었습니다.
뭔가 모범 신입 사원이란 단어를 사전에서 찾으면 바로 첫장에 나올것 같은 분이였습니다.
반대로 다른 분은 웹 개발과 관련해서는 경험이 적었고 국비 교육도 전혀 수료하지 않은 상태였습니다.
그래서 내심 걱정이 되었습니다.
"회사가 신입 사원 교육이 전혀 없는데 오시면 잘 적응하실까"
"Java & Spring을 전혀 안배웠는데 괜찮으실까"
등등의 생각이 면접 시간 내내 들었습니다.
면접이 끝나고 그런 생각을 사장님께 전달드렸는데 사장님은 그래도 채용하는게 맞다고 하셨습니다.
- 코딩 테스트 결과가 전체 1등이였던 점
- 전 회사에서 반도체 장비의 컴파일러를 만들정도로 개발 역량이 이미 있다는 점
2가지 이유로 웹 개발도 굉장히 빠르게 적응하고 배울것이라 생각했기 때문입니다.
사실 저는 신입 사원을 받는다는 것에 반대 입장이였습니다.
결국 1명을 받는 것이라 팀의 개발자 TO는 채워진 반면에, 실제로 생산성에는 큰 기여를 못할거라는 생각 때문이였습니다.
(물론 2달 뒤에 완전히 오판임을 깨닫게 됩니다.)
더군다나 제가 사수로서 누굴 가르칠 수 있는 실력이 아니였기 때문에 입사하시는 분에게도 좋지 않을거라 생각했습니다.
그래도 사장님의 판단을 믿고 두분 다 합격 하시게 되어 드디어 저에게 첫 후임이 생겼습니다.
5-2. 첫 후임의 파일럿 프로젝트
면접 준비가 철저했던 분은 다른 팀으로 가시고, 코딩 테스트 전체 1등이였던 분이 저와 한팀이 되셨습니다.
다른 팀의 경우 기존 개발자가 2분 계셨는데, 2분 모두 제가 봤던 비슷한 연차의 그 누구보다도 잘하시는 분들이라 걱정이 되지 않았습니다.
하지만 저희 팀은 저 밖에 없었습니다.
같이 입사했는데 누군 선배 개발자들에게 많은 내용을 배우고, 누군 전혀 배우지 못하는 상황이 된것 같아 괜스래 죄송스러웠습니다.
그런 마음과는 별개로 이 분들 역시 파일럿 프로젝트를 시작하게 됐습니다.
저와 똑같은 주제로 진행했던터라 걱정이 되긴했지만, 사내 규정상 파일럿 프로젝트는 그 누구도 도와줘선 안됐기에 지켜볼수밖에 없었습니다.
사내 Gitlab 주소와 Redmine 주소를 전달 드린 뒤 종료일까지 기다리기 시작했습니다.
(과제중엔 Redmine으로 이슈생성/관리도 포함되있었습니다.)
걱정반/우려반을 갖던 중 휴일에 잠깐 회사로 갔다가 파일럿 프로젝트 코딩을 하시는 모습을 보게 되었습니다.
누가 시키지도 않았는데, 혼자 와서 코딩하시는걸 보게 되니 책임감이 있는 분이란 생각에 조금 안도가 되었습니다.
대망의 프로젝트 발표날.
이상하게 제 발표도 아닌데 제가 떨렸습니다.
발표를 진행하는데 생각보다 구현 수준과 코드 퀄리티가 너무 좋았습니다.
특히 선택 기술이였던 스프링 시큐리티와 Freemarker를 쓴 걸 보고 깜짝 놀랬습니다.
지금에야 이걸 쓰는게 뭐가 그리 대단한 일이냐 할 수 있겠지만, 당시에 한글로 된 자료들을 검색해보면 Interceptor 혹은 Filter로 인증을 구현하고, JSP를 뷰 리졸버로 사용하는 것이 많았습니다.
더군다나 Spring 기반의 웹을 전혀 안해본 신입 개발자분이 레퍼런스 자료들을 기반으로 누구의 도움도 없이 짧은 시간 안에 적용했다는게 너무 놀라웠습니다.
코드 자체도 저처럼 복사 & 붙여넣기한게 아니라 최대한 베스트 프렉티스에 맞춰서 작성되있었습니다.
좀 이상하게 작성된 코드에 대해서도 질문을 하면 그 나름의 고민과 타당한 이유로 답변하는걸 보면서 소름 돋기도 했습니다.
발표가 끝나고 관련해서 잠깐 이야기를 나누면서 이정도 퀄리티가 나온 이유를 알 수 있었는데요.
출/퇴근 시간에도 지하철에서 고민하고, 많은 내용을 다 이해할려고 노력하다가 두통약까지 먹는 중이란 이야기를 들었습니다.
두통이 날 정도로 내용을 이해하려고 노력했다는 이야기에 대단한 분이란 생각이 들었습니다.
그리고 이제 막 입사한 신입 분들이 이정도면 난 어떡하나란 생각에 초조해지기 시작했습니다.
초조한 제 마음과 달리 파일럿 프로젝트가 끝나 이제 함께 일하게 되었습니다.
참고로 2년 뒤에 두 분 모두 잘 성장하셔서 많은 분들이 가고 싶어하는 좋은 회사로 이직했고, 이직 후에도 좋은 개발자로 인정받고 있습니다.
5-3. 개발팀 완성
2명이서만 일을 하던 중, 위로 2분이 오시게 됐습니다.
차석님 1분과 선임 개발자님 1분이 오셨습니다.
후에 차석님은 본부장님으로, 선임님은 팀장님이 되셨습니다.
시니어 분들이 오신 뒤, 손발이 될 수 있는 사람이 2년이 안된 저와 6개월도 안된 신입분까지 딱 2명뿐이였기 때문에 신입 채용을 시작하게 됩니다.
이번 채용에서 저는 시니어 분들과 함께 1차 실문 면접관으로 참석하게 되었습니다.
1차, 2차 면접관으로 한번씩 들어갔던 경험이 이후에 큰 도움이 되었습니다.
면접관 분들은 면접장에서 어떤 생각들을 하시는지 작게나마 경험해볼 수 있었습니다.
면접장에서 신기한 경험을 하게 됩니다.
항상 최근에 공부하고 있는 내용이 무엇인지 물어보는데요.
그때마다 답변이 없으셨습니다.
저: 최근에 가장 관심 있어하시는 주제가 무엇인가요?
면접자: 자바8입니다.
저: 오! 그럼 자바 8에 추가된 기능 중 하나만 소개해주시겠어요?
면접자: ….
…
저: 요즘에 하시는 공부가 있으신가요?
면접자: 최근에 Angularjs를 공부중입니다.
저: 오! 그럼 Angularjs에서의 양방향 바인딩이 어떤건지 간단하게 설명좀 해주시겠어요?
면접자: ….
다들 개발에 관심이 많다고 하셨는데, 생각보다 여유 시간에 공부하고 코딩하는 분들은 잘 없다는 것을 새삼 깨닫게 되었습니다.
여러 1차 면접자분들 중에 최종적으로 2명의 후보를 고려하게 됐는데요.
- 한분은 개발을 잘하시지만, 커뮤니케이션이 조금 어려웠던 분
- 한분은 다른 분에 비해 개발은 덜 하시지만, 커뮤니케이션이 뛰어나고 성실하신 분
TO가 1명 뿐이라 결국 1명을 선택해야 했고, 팀의 최종 선택은 후자였습니다.
자체 웹 서비스를 하는 곳에서는 커뮤니케이션이 정말 중요합니다.
기획/디자인/마케팅/운영자 등등 굉장히 많은 직군의 분들과 대화를 해야하고, 여러 광고회사나 제휴 회사와 서비스 연동할 일이 많기 때문에 커뮤니케이션이 안되면 같이 일하기가 너무 힘듭니다.
물론 커뮤니케이션만 뛰어나면 선택하지 않았습니다.
기본적인 개발 실력 (코딩 테스트)과 성실함이 있으셨기 때문에 선택할 수 있었습니다.
결국 그 분은 최종면접까지 통과하여 저희와 함께 일하게 되고, 저희 팀은 5명이 모인 개발팀이 되었습니다!
당시 팀 이야기를 잠깐 하면 시니어 개발자 두 분이 정말 저희를 아껴주셨습니다.
서번트 리더십이라고 하나요?
저희의 의견을 굉장히 존중해주셔서 큰 틀안에서 굉장히 자유롭게 일할 수 있었습니다.
5명밖에 안되는 인원이지만 그 안에서 Gitflow나 배포 및 롤백 방식, 프로젝트 리뷰 등 작은 기술 공유가 지속적으로 진행되어 굉장히 즐거웠습니다.
(회사를 다니는 이유)
위로 오셨던 2분이 기존 사내 문화에 대해 굉장히 호의적이셔서 코드리뷰 문화를 계속 이어갈 수 있었습니다.
거듭 말씀드리지만, 저는 코드리뷰 문화가 없는 것은 큰 잘못이라고 생각하고 있었기에 코드리뷰 문화를 지켜주시는 분들을 만나서 좋았습니다.
팀 외적으로는 다른 팀으로 가셨던 신입 개발자분을 포함한 4명이서 자주 세미나를 참가했습니다.
(세미나 후기)
평일 점심 시간때는 개발 관련 이야기를 하면서 서로에게 많은 자극을 줬던것 같습니다.
사실 경력 3년도 안되는 사람들끼리 모여서 대화해봐야 틀린 내용도 제법 있었고, 별거 아닌 내용도 많았을거라 생각합니다.
(정확히 기억은 잘 안나지만요)
그래도 그런 자극을 줄 수 있는 분위기가 좋았습니다.
당시의 기억을 떠올려보면 월요병이나 회사 출근에 관해서 크게 부담되지 않았던것 같습니다.
오히려 빨리 회사로 가서 주말에 개인 개발했던 이야기를 하고 싶어서 빨리 가고 싶었습니다.
지금도 그 3분과는 연락하면서 서로 좋은 자극제 역할을 하고 있습니다.
마지막 후임 분은 입사 2년 후에 네이버/라인/카카오를 전부 합격합니다.
다들 잘 된걸 보면 그만큼 두번째 회사가 신입 개발자를 잘 뽑고, 좋은 환경을 제공했다고 생각합니다.
5-4. 승진 시험
당시 회사에는 독특한 개발자 문화가 있었습니다.
6개월 마다 알고리즘 시험을 치고, 결과에 따라 진급 시기를 1년씩 단축시키는 것이였습니다.
토요일 오전 9시부터 오후 4시까지 2 ~ 3문제를 푸는 방식이였는데요.
정말 어려웠습니다.
입사 초기에는 나도 알고리즘 테스트를 통과해서 입사했으니 자신 있다 란 생각이였습니다.
헌데 첫 문제를 보자마자 와 이건 손도 못쓰겠다 란 생각이 들었습니다.
당시 문제 출제자셨던 분은 매번 구글 코드잼을 참가하시면서 알고리즘을 연습하시고 나중에는 구글 개발자로 이직하시기도 하셨습니다.
다른 선배 개발자분들께 여쭤보니 거의 몇 달을 주말마다 10시간씩 알고리즘 문제를 풀어서 통과했었다고 합니다.
그 얘기까지 듣고 나니 이걸 왜 해야하나란 생각이 정말 많이 들었습니다.
물론 알고리즘을 공부해서 나쁘다는 이야기는 아닙니다.
하지만 웹 서비스 개발에 필요한 당장의 지식들이 하나도 없는 상황에서 무작정 알고리즘이 최고야를 외치는것 같아서 굉장히 불편했습니다.
웹 이라는 환경이 어떻게 돌아가는지조차 모르고,
사용하고 있는 언어와 프레임워크의 기본적인 구동 환경조차 모르고,
객체지향이나 클린 코드에 대한 이해도가 없는 상황에서 모든 남는 시간을 알고리즘에 투자하길 강제하는 회사 문화가 싫었습니다.
물론 한 가지 장점은 있었습니다.
6개월마다 쳤던 이 시험 덕분에 다른 회사로 이직할때 코딩 테스트에 대한 부담감이 적었습니다.
이렇게 높은 난이도의 알고리즘 시험만으로 웹 서비스 개발자를 평가하는게 맞는가에 대해서는 계속 의문이였습니다.
물론 입사시에 어느 정도의 코딩 테스트를 봐야하는 것에는 동의합니다.
최소한의 개발 수준과 그 사람의 코드 스타일을 볼 수 있는 좋은 방법이라고 생각합니다.
당시에 계셨던 후임 두 분들에게 악영향을 끼치는 것 같아서 계속 시험을 치긴 했지만 불만은 계속 쌓였습니다.
뭔가 제가 하고 있는 공부는 인정을 못받는 느낌이라고나 할까요?
6개월에 한번씩 그런 스트레스를 받으며 회사 생활을 계속 하고 있었습니다.
5-5. 학습 방법의 변화
이 시기에 학습 방법을 강의형 -> 블로그로 변경하게 됩니다.
몇가지 이유가 있었는데요.
- 스터디 운영에 드는 수고가 많았습니다.
- 스터디룸 예약, 회비 관리, 출석 관리 등등이 생각보다 힘이 많이 들었습니다.
- 학습 가성비가 너무 떨어졌습니다.
- 발표 장표 준비나, 샘플 코드 작성으로 인해 굉장히 많은 시간이 소모됐습니다.
- 제가 앞으로 공부해야할 내용이 너무나 많은데 1주일에 1챕터 정도만 진도가 나가니 속도가 너무 더뎠습니다.
- 강의 준비가 조금씩 부담이 됐습니다.
- 제가 준비를 못하면 스터디원 전체의 토요일이 낭비된다는 생각에 굉장히 부담됐습니다.
- 공부한 내용이 팀의 다른 분들도 동일하게 필요했던 지식임을 발견했습니다.
- 강의에서 했던 내용이 저희팀의 다른 분들도 몰랐던/궁금했던 내용임을 알게 되었습니다.
- 팀내에서 다시 강의하기 보다는, 어딘가에 잘 정리해서 그걸 공유하면 좋겠다는 생각이 들었습니다.
- 스터디 했던 내용을 다시 복기하기가 어려웠습니다.
- PPT 위주이다보니 전체 문맥 없이는 다시 볼때 이해하기가 힘들었습니다.
지금 보니 당시의 글 수준이 얼마나 형편없었는지 부끄럽기만 합니다.
블로그를 시작은 했지만, 스터디때 만큼 꾸준하게 진행이 안되었습니다.
뭔가 강제성도 없고 딱히 의욕도 안났던것 같습니다.
그러다가 KSUG에서 진행했던 경력 관리 세미나 참석 후기를 시작으로 변하기 시작했습니다.
(2016년 회고)
당시에 이 후기는 2800 PV가 발생했는데요.
제 블로그 전체 PV와 비슷했습니다.
많은 분들이 방문해주시고, 댓글을 달아주시니 신이 나서 계속 블로그를 쓸 수 있게 되었습니다.
제 성격이 조용히 남몰래 하는것 보다는 많은 사람들이 관심을 가져줄때 더 열심히 하는 성격임을 알게 된 계기 였습니다.
그렇게 가벼운 마음으로 시작했던 블로그가 저에게 얼마나 큰 혜택을 주었는지!
…
다음 편에서 소개드리겠습니다 :)
5-6. 스터디 방법
2012년부터 작년까지 꼭 1개 이상의 스터디는 진행했었습니다.
(현재는 안하고 있습니다.)
1년이상 유지한 그룹도 있고, 2달만에 끝나버린 스터디도 있었습니다.
아마 대부분의 주니어 개발자분들이 역량 강화라고 하면 스터디를 가장 먼저 떠올리실텐데요.
그간의 경험으로 스터디 방법에 대해서 한번 이야기 드리고 싶습니다.
스터디를 참석하기도, 운영하기도 했기 때문에 조금은 자세히 얘기드릴 수 있을것 같습니다.
아래 내용은 모두 저의 경험에 근거한 내용들입니다.
개인에 따라 큰 차이가 있음을 알려드립니다.
망했던 스터디 유형
참가하면 거의 망했던 스터디 방법들입니다.
- 하나의 책을 정해 모여서 같이 공부하기
- 하나의 책을 서로 돌아가며 발표하기
- 포트폴리오 만들기
- 함께 프로젝트 진행하기
특히 "초보자들끼리 모여", "같이" 라는 단어가 포함되면 거의 다 망했습니다.
제가 경험했던 초보자 스터디의 대부분은 얻으려고만 했습니다
(모두가 그렇다는건 아닙니다.)
같이 공부하자는 의미로 모였는데, 결국 소수의 인원이 계속 가르치기만 하다가 그 소수의 인원이 본인들은 얻는게 없다고 판단되서 스터디를 나가고 곧바로 와해되는 경우를 몇번이나 경험했습니다.
책을 정하고 발표할때는 해당 주차의 발표자분이 안오시는 경우를 몇번이나 보기도 했습니다.
더군다나 이 방식의 제일 큰 문제는 발표를 준비했던 챕터만 공부가 된다는 것입니다.
본인이 발표할 차례가 아니면, 제대로 공부를 안해오는걸 저 스스로도 경험했기 때문에 이 방식은 조금 힘들겠다란 생각이 들었습니다.
3번과 4번은 구심점이 있지 않는 이상은 대부분 기획단계에서 다 와해되었습니다.
스터디는 학원이 아님에도, 스터디에 참가만 하면 어떻게든 되겠지란 마음으로 오시는 분들이 너무 많았습니다.
다 같이 공부를 하자고 모인 모임에서, 항상 누군가가 가르쳐주기만을 바라는 마음으로 오신 분들을 자꾸 만나게 되니 위 4가지 유형의 스터디는 더이상 진행하지 않는게 낫다고 생각하게 됐습니다.
개인적인 생각이지만 주니어 개발자일수록 초보자들끼리 모여 같이 공부하는 스터디는 참석하지 않는게 좋은것 같습니다.
여기서의 초보자는 실력을 얘기합니다.
낮은 연차를 얘기하는게 아닙니다.
연차가 높음에도 2~3년차처럼 개발하시는 분들이 계시고, 2~3년차임에도 굉장히 훌륭하게 개발하시는 분들이 계십니다.
잘됐던 스터디 유형
아래 4가지는 모두 잘됐던 스터디입니다.
- 직접 강의 하기
- 강의형 스터디 참석하기
- 온라인으로 공부한것 공유하기
- 모여서 각자 코딩하기
잘됐던 스터디들을 보면 공통점이 있습니다.
구성원들에게 부담이 되지 않는다는 것입니다.
이게 굉장히 중요한것 같습니다.
어떤 스터디 유형을 선택하시더라도, 최대한 구성원들에게 부담이 안되는 방식으로 진행하셔야 오래 지속될 수 있습니다.
첫번째로 직접 강의 하는 방식은 타인의 강의를 수강하는 것보다 훨씬 더 공부가 많이 됐습니다.
남을 가르치기 위해 공부하고 준비할때 좀 더 확실하게 공부되는 것은 사실 이였습니다.
다만 위에서 언급한 것처럼 여러 단점들이 분명하게 있습니다.
그럼에도 만약 괜찮은 스터디가 없다면 저는 직접 강의하는 방식을 추천드립니다.
강의를 준비하시는 분은 분명 그 강의 주제에 관해서는 확실히 공부가 됩니다.
2번째인 타인의 강의를 수강한 경우는 일단 마음의 부담이 없습니다.
저만 복습을 잘하면 확실히 좋은 방법입니다.
다만, 제가 원하는 주제의 강의형 스터디를 찾기가 쉽지 않습니다.
더군다나 해당 주제를 진짜 제대로 알고 계신 분도 많지 않습니다.
그래서 가장 참여하기 힘든 스터디 유형입니다.
1번째나 2번째나 한가지 팁을 드리자면, 강의를 진행하시는 분은 강의에만 집중할 수 있게 스터디원들 중 한분이 총무를 맡아주시면 더 오래 지속될 수 있습니다.
생각보다 스터디 운영에 들어가는 수고가 많습니다.
강의를 준비하시는 분이 이것 저것 신경쓰다보면 쉽게 현자타임(?) 이 오기 때문에 다른 분들이 도와주시면 좋습니다.
3번째 방식은 평일에 각자 자신들이 하고 싶은 공부를 하고, 주말 아침에 행아웃에서 만나 공부한 내용을 공유하는 것입니다.
생각보다 부담도 덜되고, 장소 제약도 없고, 운영하기도 편해서 만족도가 높았습니다.
다만, 각자의 주제가 서로에게 너무 생뚱맞을때가 있습니다.
내용 공유라는 것이 결국 남을 이해시키는 발표인데, 발표 대상이 해당 내용에 대해 전혀 관심이 없다면 발표 의욕이 좀 떨어지는 것도 사실입니다.
만약 이 방식을 택한다면 최소한 구성원들의 기술 스택과 주제에 교집합이 있는 것이 좋습니다.
(EX: SpringBoot, SQL 튜닝, Java8 등을 서로 주제로 선택한다던지)
4번째는 정해진 시간에 정해진 장소로 와서 각자 따로 공부하는 것입니다.
보통 장소는 넓은 탁자가 있는 카페를 선택합니다.
(스터디룸은 사용하지 않습니다. 편하게 왔다갔다 하기 위해서..)
시간은 오전 10시로 정하지만 지각이나 노쇼 같은걸 별도로 체크할 필요가 없습니다.
먼저 오시는 분들은 미리 와서 공부하면 되고, 늦게 오신 분들은 늦게 오신 분대로 공부를 시작하시면 됩니다.
출석이나 회비, 스터디룸 예약 등을 전혀 신경쓰지 않아도 되고, 공부할 주제에 대해서 고민할 필요도 없었습니다.
제 경험상에서 가장 성공했던 스터디 방식이였습니다.
추천 스터디 방법
주니어 개발자 분들은 그 무엇보다 올바른 지식을 배우셔야 합니다.
나름 검증된 스터디나 운영자분이 아닌 스터디에서는 잘못된 습관과 지식을 배울 확률이 있습니다.
그래서 가능하다면 검증된 스터디를 참석하시는걸 추천드립니다.
(물론 쉽지 않죠.)
예를 들어 8퍼센트의 경우 스터디 진행시 외부 인원들도 함께 진행 할때가 종종 있으신데요.
이럴때 참석하면 정말 좋은 기회가 됩니다.
이 외에 오랜 시간 운영되어 운영진들이 잘 구성되어있고, 노하우가 있는 스터디를 참석하시는걸 적극 추천합니다.
- Slipp
- 자바지기 박재성님을 필두로 뭉쳐진 스터디입니다.
- 5년이상 유지된 스터디이고 상반기/하반기마다 주제를 선정해서 진행합니다
- 자바카페
- 10년이상 유지된 스터디입니다 (국내에서 가장 오래된걸로 알고 있습니다.)
- 운영진 분들이 직접 강의식으로 진행할때가 많고 좋은 시니어 개발자 분들이 많이 계십니다.
- AWS 한국사용자모임
- 월 1 ~ 4회 이상의 핸즈온 밋업이 진행됩니다.
- AWS에서 공식 지원하는 스터디와 밋업이 많아 원하는 내용들만 선택해서 들으시면 됩니다.
- 어설프게 책 스터디 하는 것보다 훨씬 더 정확한 정보를 얻을 수 있습니다.
- 코드스피츠
- 비사이드 소프트의 맹기완님께서 직접 운영하시는 스터디입니다.
- JS, CSS, HTML 등등 웹의 전반적인 내용을 아주 심도있게 강의해주십니다.
- 장고걸스
- 파이썬의 웹 프레임워크인 장고를 주로 다루는 커뮤니티입니다.
- 굳이 파이썬 때문이 아니더라도, 대학생 ~ 주니어 개발자 분들 중 열정있는 분들이 많이 모여있어 해당 연차의 개발자들간의 스터디가 활발하게 이루어집니다.
이외에도 Java 관련 커뮤니티는 더 있습니다.
(OKKY, KSUG 등등)
다만, 스터디 보다는 Q&A, 정보 공유 위주라 스터디 찾기가 쉽지 않습니다.
제일 좋은 방법은, 원하는 내용의 유료 강좌를 듣는 것입니다.
(돈 써서 배워야 하는 이유)
저 같은 경우 패스트 캠퍼스에서 3번의 강좌를 수강했었는데요.
모두 다 만족한건 아니지만, 돈이 아깝다는 생각은 들지 않았습니다.
이런 유료 교육들은 결국 돈을 쓰는게 아니라 시간을 사는것입니다.
물론 특정 학원의 강좌가 모두 좋은것은 아닙니다.
강사님이 어떤 분인지 꼭!! 확인해보셔야합니다.
전 기수의 수강생 분이 다음 기수의 강사님으로 계시는 경우도 있습니다.
강사님께서 현업에서 다년간 경험을 갖고 계신지를 꼭 확인해보셔야 합니다.
안그러면 실무경험이 전혀 없는 분들의 지식을 100만원이 넘는 돈으로 듣게 될 수도 있습니다.
