일과 개발 공부 사이

열심히 개발하고 공부하며 블로그에 기록하는 개발자가 되자.

예전에 취준을 시작하던 즈음에 내린 결심이다.

 

어느덧 개발 경력이 만 1년을 거의 다 채워가는 때가 왔다.

2021년 12월에 입사했고, 2022년 1월부터 팀에 배정받아 실무에 투입되었으니, 몇달이 지나면 1년이 꽉 차게 된다.

지금까지의 나는 예전의 결심을 잘 지키고 있는 개발자일까?

일과 삶, 실무와 자기개발 사이

대략 5월 중순쯤부터 SI 프로젝트에 투입되었다. 기존의 SM 프로젝트와는 프로젝트의 성격도 다르고, 이에 따라 일을 진행하는 방식도 달라졌다.

가장 큰 차이점은 이번에는 사수가 없다. 첫 프로젝트 때는 옆에서 보고 듣고 배울 점이 많은 시니어 분들이 계셨고, 내 개발 결과물을 그분들이 봐 주시면서 많이 배웠다.

이번 프로젝트에는 사수가 없다. 물론 분석 및 설계 쪽에 더 적극적으로 의견도 낼 수 있고, 나도 사수 없이도 주어진 업무를 잘 수행할 수 있지만, 내 개발 과정과 품질에 대해 피드백을 받지 못하고 있다는 점이 가장 큰 아쉬움이다.

 

프로젝트는 두 번에 나누어 운영 환경 릴리즈가 이루어졌다. 1차 릴리즈 때 야근과 주말 출근, 밀려드는 결함 목록을 이겨내고 성공적으로 릴리즈를 마쳤다. 같은 어려움을 반복하지 않도록, 2차 릴리즈는 미리미리(?) 야근도 하고, 업무 계획도 조금 더 균등하게 나뉘도록 하였다.

 

이러다 보니 실무 개발에 소요되는 시간이 늘어나고, 이것은 평일 중의 체력 저하와 자기개발에 투자하는 시간 감소로 이어졌다.

나는 개발에 관해서 해야 하고, 하고 싶은 것들이 너무나 많다. 스터디에도 참여하고 있고, 개인 프로젝트도 진행하고 있으며, 인프런에서 강의도 들어야 한다. 또 강의에서 배운 걸 가지고 적용도 해 봐야 한다. 새롭게 마주하고 고민하게 되는 문제들을 블로그에 작성하기도 하고.

또, 동시에 회사 업무도 완성도 있게 기한에 맞춰서 개발해 내고 싶다. 업무 상황이 어떻고, 프로젝트 일정이 어떻고는 결국 부차적인 문제일 뿐이다. 어쨌든 나는 돈을 받고 일을 하는 개발자고, 최소 요구 조건의 100%를 하는 것이 프로의 자세다. 구차하게 다른 탓을 하며 회사 업무를 소홀히 하고 싶지 않다.

 

이런 상황에 운동까지 할 계획을 세우고 있다. 허리와 목, 그리고 손목 건강을 위해 좋은 자세를 유지하면서 개발하려고 노력하고 있지만, 좋은 자세와 더불어 운동을 챙겨서 하는 것이 중요한 것 같다. 이직한 후에는 개인 PT를 받아보고 운동하려고 하는데, 언제 시작하게 될지 모르겠다 ㅎㅎ;

 

내가 욕심이 많은 걸까? 해야 하는 일도 완벽했으면 좋겠고, 하고 싶은 일도 잘 진행하고 싶다. 무엇 하나 포기하고 싶지 않으니, 있는 시간을 어떻게 하면 더 효율적으로 쓸 수 있을지 고민해봐야겠다.

 

계속되는 서비스 기업 이직 준비

이직 준비도 계속하고 싶다. 사실 딱히 이직 준비라고 콕 집어서 하는건 코딩 테스트 준비밖에 없고, 그마저도 시간을 많이 투자하지는 않는다. 백엔드 개발자로써 스프링, HTTP, Java에 대해 깊이 있게 공부하는 것을 1순위로 두고, '나'라는 개발자를 일목요연하게 브랜딩 하는 이력서 작성을 2순위로 두며, 코딩 테스트는 3순위로 두고 있다.

 

개발 공부를 가장 중요하게 생각해서 꾸준히 이어 가고 있다. 우선 인프런의 김영한님 로드맵을 따라서 강의를 들으며 공부하고 있는데, 스프링과 JPA 강의가 중심이 되고 있다. HTTP 강의도 하나 있고, 전반적으로 실력 있는 웹 백엔드 개발자가 필요로 하는 지식을 가장 우선해서 생각하고 있다. 추가적으로 '자바의 신' 이라는 책을 통해 Java 언어에 대해서도 공부하고 있다.

이런 내용들이 1순위인 이유는, 나는 결국 웹 개발자이지, 알고리즘 푸는 사람이 아니기 때문이다. 코테 없이 채용되는 전형은 있지만, 면접 없이 채용되는 전형은 없다시피 하다. 면접 (기술면접)은 지원자의 개발 역량, 경험과 고민을 깊이 있게 알아보는 시간인데, 내가 실력 있는 개발자가 되어간다면 이런 면접도 자연스레 준비되지 않을까? 결국 이직을 준비하려면 기본이 받쳐 줘야 한다고 생각한다. 기본을 쌓는 과정이 결국 이직으로 가는 길이 아닌가 싶다.

 

추석 연휴 중에 인프런에서 워니님의 이력서 강의를 들었다. 특히 기억에 남은 것은 '성과를 가능하면 수치로 나타내라'는 것인데, 이 점은 평소에도 염두에 두고 있어야 하는 부분 같다. 내가 개선하거나 개발한 기능이 기존의 어렵거나 불편한 점을 얼만큼 개선을 했는지, 이렇게 개선하기 위해 어떤 점을 고민했는지, 더 나은 해결법은 없을지 늘 생각해야 하고, 수치 중심의 성과를 잘 정리해 두는 습관이 필요할듯 하다.

실제로 내 이력서의 work experience를 소개하는 부분이다. 아직 내가 주도적으로 무언가를 개선해 본 경험은 잘 없고, 여건상 수치로 측정하기에는 쉽지 않기 때문에, 그나마 수치로 표현할 수 있는 부분을 표현해 봤다. 아쉬운 점은 위의 내용들이 전부 백엔드 분야에 해당하는 내용은 아니라는 점인데, SI/SM 프로젝트 특성상 특정 기술 분야에 집중되지 않는 점은 아쉽다.

이렇게 이력서를 쓰면, 내가 현재 뭐가 부족하고 뭘 개선해야 할지 눈에 잘 들어오게 된다. 나의 경우에는 JPA에 대한 경험이 필요하고, Spring과 Java에 대해서 깊이 있게 공부를 더 해야 하고, 이를 녹여낸 프로젝트가 필요하다. 어떻게 보면 앞에서 언급한 내가 하고 싶은 자기개발과 겹치는데, 언급한 바와 같이 시간이 부족해서 아쉬울 따름이다.

 

코딩 테스트는... 올해는 전반적으로 작년보다 더 못 하고 있다. 아무래도 취준하면서 매일 알고리즘을 집중적으로 공부하던 때와, 실무와 자기개발을 병행하면서 알고리즘 문제까지 풀 때의 집중도와 마음가짐은 차이가 있을 수밖에 없나 보다. 최근 카카오와 라인 코딩 테스트를 봤는데, 조금만 더 잘 했으면 통과 안정권이었을 텐데 너무 아쉬운 마음이 크다. 여기서 코딩 테스트에 시간을 더 투자하는게 맞을지, 아니면 깔끔하게 접고 경력 이직을 노력야 할지 고민이 크다.

블로그에는 무슨 글을 써야 할까?

아침에 개발바닥 영상을 보는데, 평소에 어렴풋이 느끼던 내용이 언급되었다.

"구글에서 무언가에 대해 검색을 하다 보면, 같은 얘기를 하는 블로그를 여러 개 보게 되는 경우가 있다."

책, 인프런 강의 등 무언가를 보고 학습한 사람들이, 해당 내용을 옮겨 적듯 블로그에 남기는 경우가 많은 것 같다. 이런 내용들이 구글 검색을 통해 사용자에게 노출되는 것이다.

 

내 블로그도 그렇지 않을까?

예전에 진행했던 '스프링 부트와 AWS로 혼자 개발하는 웹 서비스' 책을 따라 간단한 웹 서비스를 제작 및 배포하면서 글을 썼는데, 물론 내 고민과 접근법이 담겨 있기는 했지만 책의 내용을 따라서 진행하다 보니 책의 내용을 어느 정도 답습하고 있다.

이걸 나중에 구글링 하면서 느꼈는데, '스프링 OAuth', 'JUnit4 테스트 코드', 'lombok 사용법' 같은 내용으로 검색해 보면 비슷한 내용을 다루는 글이 많이 보인다. 다 같은 책을 보고 공부한 분들이 작성한 내용이다.

 

그래서 최근에는 단순 학습에 대한 블로그 글을 별도로 작성하지 않았다. 인프런에서 HTTP 강의를 들으면서 꼼꼼히 필기하고 공부했지만, 블로그에는 남기지 않았다.

(지금 올라와 있는 '자바의 신' 스터디와 CS 스터디 내용들은 블로그에 올리려고 작성한 글이 아니고, GitHub에 커밋하고 발표하면서 정리한 내용을 겸사겸사 올린 것이다.)

대신, 실무나 개인 프로젝트르 진행하면서 겪고, 고민하고, 접근한 해결법을 중심으로 글을 써 보려고 한다. 예를 들면 이런 글인데, 저 글을 작성하게 된 배경은 실무에서 필드 주입 방식으로 도배가 된 코드를 보고 나서이다. 내가 신규로 개발하는 부분은 전부 생성자 주입 방식으로 진행했는데, 누가 이걸 보고 왜 이렇게 작성했냐고 할 때 자신 있게 설명하려면 먼저 내가 잘 알고 있어야겠다고 생각했다. 실무에서 마주한 '좋지 않은 방식'으로 개발된 코드를 '더 바람직한 방법'으로 수정하면서, 그 배경과 과정을 정리했다.

또는 이런 글도 작성했다. 현재 실무에서는 ORM으로 JPA보다는 MyBatis를 사용한다. 실무에서 처음 접해봤음에도 쿼리만 작성하면 되니 바로 실무에 적용할 수 있었고, 쿼리가 바로 눈에 들어오니 로직을 이해하기에도 쉬웠다. 그렇지만 내가 목표로 하는 서비스 기업들은 어떨까? Java/Spring 기반의 여러 직무는 거의 대부분이 JPA를 사용하고 있다. JPA의 명확한 단점인 높은 러닝 커브를 감수하고서 말이다. 이것을 통계를 바탕으로, 왜 나도 JPA를 공부해야 하는지 작성했다. 이것도 마찬가지로 실무를 통해 마주한 내용인데, 사용하고 있는 기술의 이유와 적합성을 고민해본 사례라고 할 수 있겠다.

 

어떤 글을 쓰면 좋을지 사실 생각해 놓은 주제는 많다.

일하면서 마주한, 혹은 처음 진행해 보는 개발 내용에 대해서 글로 남기려고 틈틈이 다이어리에 주제를 기록하고 있다.

최근에 Rest API를 사용한 개발, 응답으로 받은 JSON 파싱을 실컷 경험해 봤고, 개발할 때 로그 남기기와 예외 처리가 중요한 이유도 잔뜩 체감하고 있다. API의 응답을 기다리기 위해 소켓 통신 연결을 사용해 보기도 했다. 개인 프로젝트에서 쓰기 위해 Vue.js도 공부했는데, 이를 개인 프로젝트에 녹이면서 마주하는 어려움을 하나하나 헤쳐 나가고 싶다.

 

나라는 개발자가 겪고 고민하고 해결한 다양한 사례를 정리해서 블로그에 적으면, 내 블로그는 다른 어디서 본 것 같은 블로그가 아닌, 유니크한 블로그가 되지 않을까?

결론

그래서 결론은, 나는 제법 예전의 초심을 잘 지키고 있는 개발자라고 생각한다.

적어도 개발자로 평생 살기를 결심한 이래, 지금까지 꾸준히 블로그 글도 (비정기적이지만) 작성하고 있고, 어떻게 하면 더 좋은 글을 담는 블로그로 만들 수 있을지 고민하고 있다.

고민은 결국 시도해 봤기 때문에 생기는 것이다. 비록 일도, 하고 싶은 것도 많고, 해야 하는 일도 산더미지만, 이러한 과정을 조금 느리더라도 결국 기록으로 남기고 다른 사람들과 공유하는 블로그가 되었으면 한다.