[회고 #8] 4학년 1학기 여름방학 회고 (7월, 8월)

안녕하세요 dev_writer입니다. 6월 말 여름방학이 시작되면서 6월 달 회고를 작성했었으나, 실질적인 여름방학은 7월부터이기도 했고 7월에 취준을 하게 되면서 회고적인 측면에서 작성을 못했기 때문에 여름방학 회고 (7월, 8월 회고 통합)를 이번에 작성하게 되었습니다.
 

7월 회고

공부보다는 취준을 하던 시기

6월에 작성했던 회고록에서는 7월에 구직 활동과 취업에 필요한 기술을 함께 공부해야겠다는 생각을 가졌었는데, 생각보다 이를 병행하는 것은 쉽지 않다는 것을 느꼈습니다.
 
시간의 투자도 80% 정도는 사람인이나 잡코리아에서 여러 곳을 알아보고, 지원하는 과정을 거쳤습니다. 그래서 아예 취준에만 집중했습니다.
 

<최종 합격>이 이번 인턴으로 근무하게 된 회사입니다. 68곳보다 더 많았던 것 같습니다.

 
돌이켜보면 7월 달에 한 게 취준밖에 없는 것 같아, 처음 6월에 방학을 시작했을 때 가진 목표들 (스프링 인강 완벽히 끝내고, 코딩테스트도 개념 모두 챙겨서 마스터하고..)을 하나도 이룬 게 없는 것 같아 허송세월로 보낸 느낌이 들었습니다.
 
한편으로는 나는 예전 개발자 붐 때문에 개발자가 되고 싶은 게 아니라, 중학교 시절부터 진짜 개발이 좋아서 개발자를 하고 싶었던 건데 시기상 서류통과도 잘 되지 않는 현실에 싫은 마음이 들기도 하고 억울하다는 생각도 들었습니다. (물론, 이러한 현상은 어쩔 수 없고 제가 제어할 수 있는 게 아니라는 것을 깨달았습니다.)
 
다만 돌이켜보면 이 취준 과정은 언젠가는 마주칠 과정이었고, 그것을 미리 체험했다는 것에 의의를 두기로 했습니다. 어차피 개발을 하면서는 평생 공부를 해야 하며, 취준을 통해서도 제 상태를 진단할 수 있는 경험을 얻었기 때문입니다.
 

F-Lab 공부: 최소한의 공부를 할 수 있도록 해준 환경

취준을 하며 공부를 거의 못 하게 되었지만, 이전에 결제를 했던 F-Lab 공부는 계속하기로 했습니다. 3월 초에 굳은 결심으로 F-Lab을 결제했던 그때의 제가 가졌던 각오를 보면 F-Lab마저 포기하는 것은 도저히 용납이 되지 않을 것 같았고, F-Lab을 통해 어떤 식으로든 조금이라도 더 부족한 제 실력을 기르고 싶었습니다.
 
자바에 대한 기본기를 익히고, 이미 아는 내용이더라도 멘토님께서 질문해 주셨을 때 답변을 아예 하지 못한 것들이 있어 이를 보완하기 위해 깃허브에 F-Lab에서 배운 것을 정리하는 리포지터리를 만들었습니다. (이전에 공유했었던 것 같은데 이번에 다시 공유해 드립니다.)
 

자바 기본기 공부 예

 
지금은 프로젝트 개발 및 인턴 생활을 하고 있기에 이전처럼 자바 등의 기본기에 대해 공부를 많이 하고 있지는 못하지만, 향후 반드시 부족한 점을 더 공부할 예정입니다.

8월 회고

인턴 합격 (+ 현업을 하며 느낀 점)

6월 초 학교에서 지원했던 서비스 회사 인턴 공고에 코딩테스트와 1차 면접, 최종 면접을 진행한 뒤 3주 간의 대기를 하였고, 감사하게도 백엔드 채용전환형 인턴에 합격을 받았습니다.
 

회사 규모가 매우 큰 편은 아니라서 블라인드 처리를 하였습니다 🙇

 
인턴을 합격하며 현업을 경험해 볼 수 있게 되었고, 어쩌면 인턴 후 정규직 전환이 들어올 수도 있기에 지금은 시간의 70% 정도를 회사 일에 집중하고 있습니다.
 
인턴 생활을 한 지 지금 시점에서 약 열흘 정도 지났는데요, 짧았지만 느낀 점을 공유하고자 합니다.
 

사용자의 리뷰가 실시간으로 올라온다

회사는 B2C 회사로, 저나 다른 분들이 개발한 코드가 고객들에게 보이는 서비스 기업입니다.
 
처음에는 그토록 중학교 시절부터 가졌던 목표였기도 했고, 대학교 4년 동안 개발을 좋아하는 마음을 가지다 보니 업무에 쉽게 적응할 수 있으리라고 생각하였습니다.
 
그러나 실제로 들어가 보니 사용자의 리뷰를 즉각적으로 확인할 수 있었고, 때문에 최대한 문제없이 지속적으로 운영되는 서비스에 내 코드가 반영되어야 한다는 생각과 내가 혹시라도 잘못 개발함으로써 사용자들의 불편함을 야기한다면 어떻게 버틸 수 있을까라는 고민을 하게 되었습니다.
 
이 과정에서 어느 회사를 들어가더라도, 회사에서 일을 한다면 개인적으로 사이드 프로젝트를 하던 때와 다르게 더 긴장감 있게, 책임감 있게 살아가야 된다는 것을 직접 몸으로 배울 수 있었습니다. (동시에, 왜 회사들이 공통적으로 '업무 경험'을 원하는지도 알게 되었습니다.)
 

개발 외적인 요소도 매우 중요하다

제가 맡은 서비스는 개발팀, 마케팅팀, 기획팀 등 어느 정도 규모 있는 사이드 프로젝트를 할 때 공통적으로 존재하는 부서들이 모두 있습니다.
 
그래서 그런지 개발팀 이외의 분들이 회의하시는 것에 참석하기도 하고, 그분들이 나누는 의견 공유 현황도 쉽게 볼 수 있었습니다.
 
처음에는 개발 이외의 용어들을 접하다 보니 한 번에 이해가 되지 않았기도 했고, 지금 가지고 계신 고민들을 왜 하고 있는지조차 파악하는 게 힘들었습니다. 또, 초기에는 회사 기술 (Java X, Spring X, MySQL X..)을 익히는 데 집중해야겠다는 생각이 우선적으로 들기도 했습니다.
 
그러나 개발 이외의 영역들도 이해하고 있어야 회사의 수익 원리를 이해할 수 있고, 고객의 목소리를 들음으로써 고객이 원하는 것이 무엇인지를 파악하여 고객과 더 가깝게 다가갈 수 있다는 것을 배울 수 있었습니다. (이 과정에서 고객이 있어야 기술이 있다는 생각을 하게 되었습니다.) 그래서 지금은 다른 부서 분들이 기록해 두신 문서를 여유가 생길 때마다 읽어보는 등의 과정을 이어오고 있습니다.
 
예전에는 개발하는 것에만 집중했었는데, 이제는 사이드 프로젝트를 하든, 회사에서 일을 하든 전체적인 그림을 이해한 뒤 그 상황에서 개발을 해야겠다고 느끼게 되었습니다.
 

항상 갈망하자

인턴을 하며 이제 취업하였으니 안주해야겠다는 생각은 하지 않고 있고, 앞으로도 하지 않을 것입니다.
 
두 달의 취준을 하며 제가 생각보다 훨씬 부족한 상태라는 것을 자각할 수 있었고, 포트폴리오에 쓸만한 프로젝트를 완벽히 끝내놓은 것도 없고 코딩테스트도 승률이 매우 낮은 상황이라는 것도 직접 겪어보니 깨달을 수 있었습니다.
 
항상 나보다 더 뛰어난 사람이 있음을 깨닫고, 더 겸손하고 지적 갈망을 더욱 가지자라는 마음을 먹게 되었습니다.
 

F-Lab 프로젝트 병행 시작

동시에, F-Lab의 프로젝트 (EatToFit: 음식을 운동으로)도 실제 개발 단계에 들어갔습니다.
 
F-Lab의 모든 멘토님들이 같은 커리큘럼을 가지고 계신지는 모르겠지만, 제 멘토님은 프로젝트 아이디어 선정 - API 설계 - DB 설계 - 코드 작성 (실제 개발)의 과정을 구성하셨습니다.
 
그래서 API 설계에서의 고민점을 블로그에 공유할 수 있었고, 자연스럽게 DB 설계/개발 단계에서의 고민점, 문제 해결점 등을 작성해야겠다는 생각을 가질 수 있었습니다.
 
추가로 DB 설계를 하면서는 그동안 제가 JPA의 자동 DDL에 너무나 크게 의존하고 있었다는 사실을 배울 수 있었습니다. 비교적 간단한 프로젝트 같은데 DB 설계를 깔끔하게 하지 못했던 제 자신을 발견할 수 있었고, DB 설계만을 할 때에도 애플리케이션에 대한 설계를 혼합하려는 시도를 하기도 했습니다.
 
위의 문제들을 해결한 과정과 고민점들을 차례로 블로그에도 공유하고, 동시에 내년이 오기 전에 개발을 모두 완료해 두는 것을 목표로 F-Lab 프로젝트도 열심히 진행하겠습니다.
 

앞으로 어떻게 살 것인가?

해야 할 건 많은데 물리적으로 시간은 한정되어 있고, 너무 이곳저곳에 찍먹 하는 것은 아닌지, 제대로 뭐 하나 완료해 둔 게 있는지 싶어 글을 작성하는 시점에도 명확히 떠오른 계획은 없습니다.
 
우선은 회사 기술 공부 및 업무를 하는 데 집중할 것 같고, 그 이외에는 F-Lab 프로젝트 및 블로그 공유, 추가로 개발하고 있는 에이투지 연애 서비스에 대한 개발을 하는 것만으로도 시간이 꽤 소모될 것 같습니다. (그 이외의 공부는.. F-Lab과 에이투지 개발이 완료된 이후에야 가능할 것 같습니다.)
 

같은 기간을 겪고 계신 개발자 취준생 분들께

2024년은 직군을 막론하고 개발자 분들이 유독 이전에 비해 취업하시기 힘든 상황인 것 같습니다.
 
신입 개발자가 되기 위해서는

1. 코딩 테스트
2. 사이드 프로젝트 경험 (단순 구현 말고 고민점, 성능 개선 등이 준필수)
3. 사용하는 언어/프레임워크에 대한 기본기
4. 전공 지식 (네트워크, 데이터베이스, 운영체제)

등 위의 네 가지 말고도 추가적으로 다른 것들도 필요할 수도 있습니다.
 
이때 심하면 더 공부하고 싶다는 생각을 포기하게 되거나, 개발을 더 이상 업으로 삼고 싶지 않다는 생각이 들 수도 있습니다. 또는, 이전의 저처럼 불안 증세를 겪게 되실 수도 있습니다.
 
적절한 객관적 판단은 필수이지만 그렇다고 너무 스스로만 자책하지는 않으시면 좋겠습니다. 개발자가 되기 위해 힘든 상황이고 해야 할 것이 많지만, 그것이 꼭 개인의 잘못만인 것은 아니기 때문입니다.
 
계획을 세우면서 너무 해야 할 게 많다는 생각이 든다면, 알고리즘 전략 중 하나인 Divide and Conquer: 분할 정복 알고리즘을 떠올려보시길 권장합니다. 개인적으로 종종 이용하던 방법인데, 아무리 해야 할 게 많다는 생각이 들어도 이들을 작게 나누고 각개격파 해나가다 보니 어느새 제가 계획했던 것들을 모두 처리할 수 있었던 순간들이 있었습니다.
 
이번 방학 후기 글은 이벤트가 많이 없었어서 내용이 적은 것 같은데, 끝으로 박보영 님께서 하신 말씀이 너무 와닿았어서 공유하며 마쳐보겠습니다.
 

혹시 너무 어둡고 긴 밤을 보내고 계신 분이 계시다면, 지치지 말고 끝까지 잘 버티셔서 아침을 맞이하셨으면 좋겠습니다.