시작하기에 앞서..
이 글에서는 대기업 이직기와 준비 과정, 그리고 앞으로의 공부 계획을 정리해보려고 한다.
또한 마지막엔 왜 블로그를 티스토리 → velog → 새 티스토리로 다시 돌아왔는지를 간략하게 얘기하고(TMI), 앞으로의 블로그 관리 방법을 정리해보겠다.
대기업에 합격하다
나는 최근에 생각지도 못했던 대기업에 최종 합격했다.
누구든 한 번쯤은 보고 들었을 법한 기업에서 감사하게도 대리 직급(4년차)으로 좋은 기회를 주셨다.
(많이 부족한 주니어인데도 기존 경력에 +1년을 더 인정해주셨으니 그에 맞게 열심히 기대에 부응해볼까 한다 😊)
대기업을 밟기까지는 아래와 같은 과정을 거쳤다.
- 개발팀 4명 솔루션 SI 기업(10개월-대학교 실습&취업계) → 개발팀 30명 솔루션 SI 기업(13개월) → 멘토링 및 개인공부(10개월) → 대기업 입사
학습 및 멘토링을 끝내고 원티드를 통해 본격적으로 지원하였고, 130개 지원 중 11개의 기업에서 면접을 보며 그 중 3개의 기업에 최종합격을 했다. (아래 결과는 이미 다 거절하고, 뒤늦게 캡쳐한 사진 😂 + 9개는 자사 채용 사이트 지원)
왜 갑자기 TMI를?
나는 솔루션 SI 기업에서 선 퇴사를 하고 잠깐의 방황을 할 때 향로님, 기선님, 재성님(jason)등 정말 많은 분들에게 도움을 받았다. 이분들의 공통점은 모두 소프트웨어 생태계의 선순환을 이뤄내기 위해 개인 시간을 투자하여 방황하는 개발자들에게 도움을 주는 분들이다.
도움을 받았으니 이젠 나도 도움을 줘야 되지 않을까?
따라서 이 글을 쓰게 된 계기는 내 앞으로의 다짐과 계획을 하려는 목적도 있지만, 내 준비 과정과 갖고 있는 정보들을 모두 공유함으로써 한명의 개발자라도 도움이 됐으면 하는 마음에 글을 쓰게 됐다.
또한 나는 현재 아래 사진과 같이 신입분들이 주로 계시는 600명대의 커뮤니티에서 알렉스라는 이름으로 활동하며 질문에 대한 답변을 열심히 하고 있고, 1:1로 멘토링을 드리는 분들도 3명 정도 있다. (물론 아직 많이 부족하므로 무료로 진행 중이다! 😅)
커뮤니티나 개인 DM으로 문의해주시는 분들께는 성심성의껏 답변을 드리지만, 이런 내용들을 따로 블로그에 기록한다면 좀 더 많은 분들이 조금이나마 도움이 될 수 있지 않을까 하는 마음에 글을 써보려 한다.
도약을 위한 준비 과정
우선 약 2년간의 SI 실무에서는 아쉽게도 공부를 많이 하지 못했다. 주 5일 야근을 해도 부족한 살인적인 업무량에 주말까지 출근한 적도 빈번했기 때문이다. 관련 내용은 2022년 회고에 기록해놓았으니 넘어가겠다.
따라서 이 글에서는 내가 선퇴사를 하고 어떤식으로 전략을 세워서 이직을 준비했는지를 기록해보려고 한다.
(참고로 나는 선퇴사를 했지만, 문의 주시는 모든 분들께는 환승 이직을 권장드린다 😅)
1. 개인 학습 로드맵 만들기
나는 2년 동안의 실무를 경험했지만 객관적으로 내 실력은 신입이라고 생각했다. 따라서 무엇을 순차적으로 공부해야 될 지 로드맵을 만들어놔야 방황하지 않고 공부해나갈 수 있을 것이라 생각했다.
아래는 내가 현재 진행하는 우아한유스방 스터디에서 권장하는 로드맵이고, 내가 생각했었던 로드맵과 거의 비슷하다. (Shout out to 제이슨)
- 학습과 적용, 응용에 대한 태도 -> 클린 코드, 좋은 설계를 이끄는 단위 테스트 -> 웹 기술과 웹 프로그래밍 -> 스프링 프레임워크 -> 데이터베이스 -> ORM 프레임워크 -> … -> CI/CD를 위한 인프라스트럭처 -> 클린 아키텍처 -> DDD -> 분산 시스템 -> 인프라스트럭처 -> MSA -> …
첫 번째로 학습과 적용, 응용에 대한 태도 이 부분이 주니어 개발자가 가져야 할 첫 번째 덕목이라고 생각한다.
나도 그랬었지만 여러 신입분들이 하나의 기술에만 집착해서 사용법을 익히는 공부를 많이 하시는 것 같았다. 하지만 개인적인 생각으로는 특정 기술을 잘 사용하는 것보다, 왜 이 기술을 사용했는지가 더 중요하다고 생각한다.
어떤 비즈니스 문제에 직면했고, 이 문제를 해결하기 위한 솔루션은 어떤 것들이 있으며, 내 프로젝트에 적합한 솔루션은 무엇인지 트레이드 오프를 고려하여 기술을 선정한 후에 그때 비로소 기술에 대해 공부를 하는 것이 순서이지 않을까?
우리는 특정 기술을 잘 사용하는 코더가 아닌, 비즈니스 문제를 해결해나가는 개발자이니까.
또한 구글링을 할 때 최대한 공식문서와 가까운 글을 찾아보는 연습을 했다. 공식문서와 친해지는 연습을 해야 가장 정확하고 가장 빠르게 최신 정보를 습득할 수 있다고 생각한다.
두 번째로는 단위 테스트이다. 내가 퇴사하고 가장 먼저 공부한 기술이기도 하다. 요즘 신입 기본 역량인 단위 테스트는 버그를 방지하는 목적도 있지만, 객체를 설계할 때 유용한 도구이기도 하다. 단위 테스트를 짜기 어려운 코드를 테스트 짜기 쉬운 코드로 변경한다면 자연스럽게 객체 지향적으로 설계할 확률이 높기 때문이다.
그 뒤로는 웹 기술을 배우기 위한 Servlet → Spring → Database → ORM → CI/CD 등등 애플리케이션 단에서 인프라, 아키텍처까지 영역을 확장하는 형태로 공부하는 것이 좋다고 생각한다. 여기서 중요한 건 ORM 기술을 배우기 전에 Database 공부를 선행해야 한다는 것이다. 대부분은 당연한 거 아니냐고 생각할 수도 있지만, 생각보다 많은 신입분들이 Database 공부는 건너뛰고 JPA 공부를 먼저 하려고 하시는 분들이 꽤 많다는 걸 느꼈기에 다시 한번 강조한다.
또한 향로님을 비롯한 여러 멘토님들이 공통적으로 얘기해주신 내용 중에, 신입/주니어분들이 가장 놓치는 포인트는 애플리케이션 단이 미숙한데 인프라나 아키텍처 쪽으로 시선을 돌린다는 것이다.
요즘 흔히 신입 5대 위험 요소라고 불리는 TDD, MSA, DDD, Hexagonal Architecture, Kafka도 정작 비즈니스 로직을 깔끔하게 짤 줄 모르는 상태에서 사용한다는 것은 모순이라고 생각한다.
따라서 순서대로 하나씩 정복해나가는 것을 추천한다.
(정상급 기업을 제외한 웬만한 기업들에서는 신입한테 생각보다 많은 걸 바라지 않는다고 느껴졌다 😅)
2. 학습에서만 멈추지 말기
흔히 주객전도라고 불리는 현상이 나뿐만 아니라 여러 주니어분의 학습 방식에서 나오는 것 같다. 우리는 기술을 학습하려고 공부하지만, 어느샌가 목표한 강의 수를 채우는 나를 발견할 것이다.
하지만 인강을 듣는다고, 책을 읽는다고 그 내용이 온전히 내 것이 될까? 아무리 머리 좋은 사람이라도 한 달이면 다 까먹을 것이다.
중요한 건 학습한 내용을 바로 적용해보며 직접 체화하는 것이다. 실무에서 적용해보는 것이 가장 베스트한 방법이겠지만, 상황이 안되더라도 토이 프로젝트를 통해 얼마든지 적용해볼 수 있다.
확실한 건 우리는 어떤 개념을 눈으로만 보고 넘어가거나 메모장에 잘 기록해놓는 것보다는, 실제 프로젝트에 직접 적용해보는 것이 훨씬 기억에 오래 남는다고 생각한다.
3. 피드백 환경을 마련하기
위의 1번과 2번을 통해 단계적으로 학습한 내용을 프로젝트에 적용했다면 그 다음은 필요한 것이 무엇일까?
만약 열심히 짠 내 코드가 남이 봤을 때 정말 하나도 안 읽히고 이상하게 보인다면 어떨까?
사실 대부분의 신입이라면 한 번씩 직면할 수밖에 없는 상황이라고 생각한다. 나 또한 실무를 2년 동안 뛰었는데도 퇴사 당시 내 코드는 굉장히 처참했다.
따라서 나는 퇴사 직후 하루에 한 번 코드 리뷰를 꼭 받을 수 있는 멘토링을 신청했다. 하지만 여건이 안 된다면 굳이 멘토링을 비싼 돈 들여 할 필요는 없다.
단지 내 코드에 대한 리뷰만 해줄 수 있는 환경이라면 뭐든 상관없다고 생각한다.
따라서 나는 아래와 같은 방법을 추천한다.
- 어느 정도 검증된 기업 부트캠프(우테코 등)를 수강한다.
- 여건이 된다면 어느 정도 검증된 멘토링(NEXTSTEP, 코드숨, F-Lab 등)을 수강한다.
- 코드 리뷰와 피드백을 받을 수 있는 국비 교육을 수강한다.
- 인프런 1회 멘토링을 통해 소액으로 코드 리뷰를 요청한다.
- 개발 커뮤니티에서 리뷰 요청을 한다.
개발 직군에서 신입 때 맨땅에 헤딩으로 혼자 학습하며 경험을 쌓는 것은 확실히 장점도 있지만, 그 과정은 상당히 많은 시간을 요구한다. 또한 실무 경험이 없는 상태에서는 시야를 넓히는 것이 쉽지 않다.
따라서 효율적인 성장 방법으로는, 멘토링을 받거나 잘하는 개발자분들께 코드 리뷰를 받아보는 것을 추천한다.
리뷰를 통해 현재의 내 코드와 접근 방식에 어떤 문제점이 있는지 피드백을 받고 이를 개선함으로써 빠르게 성장할 수 있다고 생각한다.
(위의 멘토링 중 개인적으로 F-Lab은 다소 비싸다고 느껴지긴 한다 😂)
마지막으로 최근 개발바닥 유튜브에서도 한번 얘기가 나왔지만, 나 또한 공감하는 내용이 있다.
비슷한 국비 교육을 2번 듣지는 말자. 국비 교육을 들었는데도 부족함을 느낀다면, 배운 내용을 토대로 개인적으로 공부하며 채워 넣는 것을 추천한다.
4. 완벽할 때 까지 기다리지 말고 진행하면서 완벽해지기
어느 정도 공부했다면 이제는 이력서를 지원하면서 공부하는 것을 추천한다.
나 또한 아직 부족한 것 같다고 계속 지원을 미루며 7개월 동안 아무 곳에도 지원하지 않았었다.
하지만 공부를 계속한다고 완벽해지긴 힘들더라 😂
개인적으로 깨달은 것은 면접을 1~2번 보는 것이 오히려 훨씬 공부가 잘된다는 것이다. 면접에서 몇번 혼나다보면 자연스럽게 내가 무엇을 모르고 있는지 파악하게 되고, 혼자 공부하는 것보다 훨씬 효과적으로 학습을 할 수 있다.
만약 내가 지원을 하지 않고 공부를 계속했다면 아직까지도 이직을 못 하고 집에서 계속 불안한 감정과 함께 컴퓨터를 두드리고 있었을 것이다.
따라서 1번부터 3번까지 어느 정도 진행했다면 그 경험을 기반으로 이력서와 포트폴리오를 작성하여 계속 회사에 지원해보자. 그리고 웬만하면 제일 가고 싶은 회사의 역순으로 지원하자.
면접은 정말 보면 볼수록 스킬이 는다. 한 6번째의 면접부터는 어느 정도 감이 잡혀 나만의 면접 방식을 확립할 수 있을 것이고, 그렇게 된다면 곧 좋은 결과를 받을 수 있다고 확신한다.
추가로 이력서와 포트폴리오를 작성하는 팁에 대해서는 내가 가끔 재밌게 보는 우테코 4기 연로그님의 글을 첨부하겠다.
앞으로의 목표와 계획
나는 우아한유스방 로드맵을 참고하여 아래와 같이 처음부터 다시 차근차근 공부를 시작해보려고 한다.
자바 -> 클린 코드, 좋은 설계를 이끄는 단위 테스트 -> 스프링 프레임워크 -> 데이터베이스 -> ORM 프레임워크(JPA) -> CI/CD를 위한 인프라스트럭처 -> 클린 아키텍처 -> DDD -> 분산 시스템 -> 인프라스트럭처 -> MSA
각각 스탭바이 스탭으로 책이나 강의를 통해 진행해보려고 한다.
- 자바 : 모던 자바 인 액션 + 더 자바, Java 8 강의(백기선님)
- 클린 코드 : 리팩터링 2 + 코딩으로 학습하는 리팩터링(백기선님)
- Testing : Unit Testing(단위 테스트)
- 스프링 프레임워크 입문 : 스프링 입문을 위한 자바 객체지향의 원리와 이해
- 스프링 프레임워크 심화 : 토비의 스프링 3.1 Vol.1 + 토비의 스프링 부트 - 이해와 원리
- 데이터베이스 : Real MySQL 8.0 or 데이터베이스 인터널스
- JPA : 자바 ORM 표준 JPA 프로그래밍
- CI/CD : 미정
- 클린 아키텍처 : 클린 아키텍처
- DDD : 도메인 주도 설계 핵심
추가로 NEXTSTEP의 DDD(Domain-Driven Design) 세레나데와 NEXTSTEP의 TDD, 클린코드 with Java를 올해 하반기에 신청하여 들어보는 것이 목표이다.
또한 이건 욕심일 수도 있지만 아이패드를 통해 출퇴근 길에 아래 책을 읽는 것도 좋을 것 같다는 생각을 하였다.
- 객체지향의 사실과 오해
- 오브젝트
- 이펙티브 자바 + 백기선님 강의 or 제로베이스
아마 올해에 5. 스프링 프레임워크 심화까지만 완료하여도 만족할 것 같지만, 일단 전체적인 그림을 그려놓으며 하나씩 하나씩 체크리스트를 없애는 재미로 공부를 해볼까 한다.
블로그 관리
우선 지금까지 내가 걸어왔던 멘토링(Codesoom, NEXTSTEP, 우아한유스방 등)의 기록들은 멘토링 카테고리에 저장해놓을 생각이다. 또한, 간간히 내 자신을 되돌아보는 글은 회고 카테고리에 저장해놓을 생각이다.
하지만 이제부터 새로 작성하는 기술 관련 글들은 실무 경험 위주로 작성해서 기술 경험 카테고리에 저장해놓을 생각이다.
그리고 실무에 적용하기 전에, 관련 기술을 공부한 내용들은 기술 공부 카테고리에 차곡차곡 모아놓으려고 한다.
따라서 앞으로는 새롭게 출발하는 회사에서 비즈니스 문제를 해결해나가기 위해 현재 상황에 적합한 기술을 결정하고, 공부하며 적용해나가는 과정들을 열심히 소개해보겠다.
(TMI)
알렉스는 왜 이렇게 블로그를 이리저리(블로그를 티스토리 → velog → 새 티스토리) 옮겨 다닐까?
기존 티스토리에서 velog로 옮기게 된 계기는 작년 10월 카카오톡 서비스 전체 장애였다. 티스토리 또한 카카오톡이 관리하는 플랫폼인데, 그때 당시 신뢰도가 매우 떨어져서 velog로 옮기게 되었다. 하지만 velog는 생각보다 자유도가 떨어졌고, 개인적인 생각이지만 플랫폼 이미지 자체가 좀 부정적이기도 했다.
나는 하나의 블로그 글을 작성할 때 시간을 꽤 많이 투자하여 작성하는 편인데, 생각보다 짜집기 블로그나 책이나 강의 내용을 그대로 복붙하는 부류의 글들이 특히 velog에 너무나도 많았다. 따라서 내가 구글링을 할 때도 velog 글이 보이면 클릭을 망설이는 나를 발견하면서 블로그를 이전해야겠다는 마음을 먹었다.
따라서 medium, github 블로그, 우피 등 많은 플랫폼을 고려했지만, 가장 글 작성 시간이 최소한으로 들면서 이미지가 나쁘지 않은 티스토리로 돌아오게 되었다. (티스토리에는 내 멘토님이신 향로님이 계시기도 하니까 😊)
꾸준함의 가치를 향해 열심히 정진하자.
'회고' 카테고리의 다른 글
| 주니어 개발자의 우당탕탕 입사기 (1) | 2024.07.25 |
|---|
