어느 1년차 주니어 개발자의 2023년 회고

devty·2023년 12월 28일

ETC

목록 보기

3/3

시작하겠습니다~~~

2022년 하반기 개발자로 처음 발을 내딛고 2022년도엔 회사 적응하는데 시간을 썼다면, 2023년도에는 개발자로서 성장하기 위한 한해였던 것 같다.

한해동안 새로운 프로젝트(SI 특성상 프로젝트가 자주 바뀜)에 적응하느라 정신 없이 보냈던 것 같다. 하지만 회사 내 프로젝트도 그렇고 개인적으로 공부하는 것도 스터디도 너무나도 재밌었다. 이렇게 개발로서 재밌게 보낸 한해가 있을까 싶다.

개발을 할 때 다른 개발자의 블로그글을 많이 참고하는 편인데 회고에 대해 처음 알게 되어 11월 말부터 써야지 써야지 하다 연말이 돼서야 시간이 조금 남아 쓰게 되었다.

쓸 내용은 간략하게 올해 이뤄낸 성과, 회사 프로젝트 회고, 대외 활동(스터디), 이직에 대한 고민, 일상, 올해 목표등 정도 될 것 같다.

올해 이뤄낸 것들

가장 처음으로 얘기할 건 아마도 작년에도 해왔던거이긴 하지만 올해도 꾸준하게 진행했던 1일 1커밋이다.
작년에 3월달부터 시작하여 지금까지도 커밋을 꾸준하게 유지해오고있다.
사실 커밋이 별것도 아닐뿐더러 커밋을 위해서 공부를 한다? 이것도 정말 아니다. → 이 말 꼭 DI(의존성 역전)같다. ~~스프링 개발자 유머입니다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋ~~

공부를 하고 그거에 대한 기록을 꼭 남기지 않아도 되지만, 나는 어느정도 수치로 나타내는게 좋은 것 같아서 계속 커밋을 해두는 편이긴 하다. 작년에는 540개의 커밋을 해두었는데, 올해는 그거의 2배정도 되는 1112개의 커밋을 하였다. (나의 꾸준함에 칭찬👏🏻👏🏻👏🏻)
올해 하반기부터는 깃허브 Repo 관리도 주제별로 나눠서 작업하기 시작하였다.
위 처럼 주제별로 나눠서 정리하니까 좀 더 보기 깔끔해진 것 같다. 기존에는 원래 있던 토이 프로젝트에 덕지덕지 붙여둔 수준이었는데 나중에 찾기도 어렵고 누군가에게 설명하기도 어려워서 Repo를 다른 방식으로 사용하였다.

블로그도 작년 11월부터 시작하여 지금까지 운영중에 있는데 작년에는 4개정도 올렸는데 올해는 37개 작성하였다. 작년에는 2달밖에 없었기도 하였고 블로그를 어디로 갈까하는 고민도 컸어서 많이 포스팅하지 못했던 것 같다.

올해 37개면 달에 거의 3개정도 올린 것 같다. 물론 나보다 더 잘하는 사람들에게 도움이 줄순 없었겠지만, 그래도 개발을 이제 시작하시는 분들이나 나랑 비슷한 연차인 사람들이 도움을 받았다면 그걸로 만족한다.

대외 활동

올해부터는 회사도 적응하기도 하였고 다른 회사 개발자들의 생각이나 자문을 구하고자 스터디를 찾게 되었다.

원래 다른사람들이랑 시간 약속을 잡고 무언가 꼭 해야한다는 압박감이 싫어서 혼자 공부하는 걸 선호하는 편이었는데 막상 계속 혼자하려니까 막히는 부분도 많고 이럴때 다른사람들은 어떻게 고쳐나갈까하는 의견을 듣고싶어서 MBTI 대문자 I 가 용기를 내어 우아한 스터디 서머에 지원하게 되었다. 하지만 그당시에 간절함이 부족했는지, 탈락에 고배를 맛보게 되었다. 그러곤 그 당시 지원했던 스터디인 클린 아키텍처에 대해 혼자 따로 공부한 뒤로 사내에 접목시키기도 하였다. 물론 블로그 포스팅도 하였고 그 후 우아한 스터디 겨울시즌에 내가 했던 포스팅들과 꾸준함을 어필하여 합격하였다! 🎉🎉🎉 올해 열심히 했던걸 보상받은 느낌과 더불어 여태 내가 공부해왔던 방향이 틀리지 않았다는걸 증명 받은 기분이라 너무 좋았다.

막상 스터디를 직접 해보니까 생각보다 별건 없었다. 생각보다 해야하는 것에 대해 압박이 심하지도 않고 일정이 빠듯하지도 않았던 것 같았다. 같이 공통적으로 한 권에 책을 읽고 그 책에 대해서 궁금한점이나 토론하고 싶은게 있으면 올리는 식으로 진행하였다. 혼자 코드 짤 때 이건 이래도 되나? 저건 저래도 되나? 했는데 마음껏 얘기할 수 있어서 너무나도 좋았다. 다음에도 이런 기회가 온다면 꼭 다시 해볼것이다!

올해는 처음 해본것들이 많은데 그중에서 한가지 더 얘기하자면 커피챗이 있다. 커피챗이란 다들 알고 있긴할텐데 막상 위에서 말했듯이 내가 집밖에 나가는 걸 그닥 좋아하지 않는 편이라 나에겐 생각도 못했던 것이었다.

뭐 채팅앱으로 커피챗을 하는 경우도 있지만 오프라인에서 만나서 바로바로 이야기(통신)하는게 개발자라면 더 편하지 않은가? 물론 그런 기회가 주어진다면 말이다.

근데 때마침 패스트캠퍼스에서 MSA에 대해서 강의를 다 들었는데 강사님께서 마지막에 이스터에그처럼 자기 메일을 남기곤 완강한 사람들에게 커피를 한잔씩 쏘겠다고 하여서 바로 메일을 남겨드렸다. 며칠뒤에 답장이 와서 만나게 되었다. (두둥)
커피챗 하기 전에 물어볼 체크리스트를 몇가지 작성하고 갔다. 처음부터 바로 질문하긴 애매해서 스몰톡 느낌으로 회사는 어떤지도 물어보고 내 상황을 얘기하면서 자연스럽게 풀어갔다. 그리고 내 이력서에 대해서 많이 봐주셨는데 정말 많은 도움이 되었다. 누구나 할수 있는 부분은 빼는게 좋다라는 조언과 어떤걸 사용했을 때 “왜” 사용했는지에 대해 적어두라고 조언을 해주셨다. 기술적인 부분은 다 작성하고 싶었지만 그러기엔 길고 지루한 글이 될까봐 뺐었는데 그걸 요약하는 것도 이력서를 잘 쓰는 방법중 하나라고 말씀해주셨다.

물론 커피챗이 아니더라도 강의에서 MSA에 대해 혼자는 어려워서 못하는 부분들을 친절하게 설명해주시고 기술 선택에 대한 트레이드 오프, 사이드 이펙트에 대해서도 잘 설명해주셔서 잘 따라갈 수 있게 되었다.

그리고 올해는 콘퍼런스에 많이 지원해봤는데 인프콘, 우아콘 등등 하나도 된게 없어서 아쉬웠다…직접 가서듣는거랑 집에서 듣는거랑 비슷하겠지만 그 현장감을 생생하게 느껴보고 싶었다. 또 나중에 나도 저렇게 발표하고 싶기도 하고..ㅎ 미리 경험삼아 보고오는 것도 좋다고 판단되어 매번 지원했는데 아쉽게 잘 되진 않았다. 내년에는 꼭 갈 수 있길 바라면서…

개인 프로젝트

개인적으로 했던 프로젝트중 가장 컸던건 역시나 EWM이 아닐까 싶다. 운동 같이 할 사람을 모집하는 서비스였는데, 처음에는 모놀로식으로 하였다가 MSA로 마이그레이션까지 끝낸 상태이다.

MSA로 마이그레이션 하는 과정중에 어려웠던 점이 한두가지가 아니였지만 한 싸이클을 다 돌아보니 MSA가 개인적인 생각으로 유니콘 같은 느낌이다. 사실 혼자 모든 것을 하려니 어려웠던 점이 많았겠지만 과연 완벽한 MSA가 있을지도 의문이긴 하다. 이렇게 생각한 계기중 가장 컸던건 역시 트랜잭션 관리가 제일 어려웠기 때문이다. 1개의 DB에서는 트랙잭션에 대한 롤백 처리를 따로 관리하지 않았는데 N개의 DB를 거치는 MSA에서 롤백처리란 무수히 많은 케이스들을 고려해야해서 혼자 하기엔 너무나도 어려웠다.

그래서 나는 생각했다 도메인 별로 분리를 하는것은 너무나도 좋은 생각이지만, DB는 공유해서 사용하면 안 될까? 라고 그게 대한 답은 멀티 모듈에 있었다. 모듈별로 크게 나누는것과 각각의 build.gradle이 있는것이 MSA와 동일하지만 1개의 DB에서 관리 된다는 점이 다른점으로 꼽힐수 있다.

이렇게 되면 좋은 점은 1개의 DB에서 처리하기에 따로 트랜잭션 관리를 해줄 필요가 거의 없어진다. 이 부분이 MSA 최대 단점을 보안해준다고 생각한다. 이거 하나만으로도 개발의 효율성을 극대화 시킬수 있다. 당연하게도 1개의 DB를 사용하면 나중에 단일 장애점이 발생할 수도 있지만 그건 다른 방면으로 해결할 수 있다. ex) DB Replication, Sharding 등

개인적으로 했던 프로젝트중 가장 오래 프로젝트를 했던거라 애정이 많이 가기도 하였다. 하다보니 이것도 하면 좋지 않을까? 저렇고 고려하는건 어떻지? 라는 생각에 덕지덕지 추가되긴 하였지만 빼곡히 글씨가 쓰여진 연습장 같은 느낌이라 뿌듯하다. 이번껀 잠깐이나마 운영해보았지만 역시나 트래픽은 0…다음에 프로젝트를 하게된다면 사람들이 진짜 쓸만한걸로 진행해보려고 한다.

이직에 대한 고민

이런말은 조금 그렇지만 SI 회사이다보니 처음 들어가기 전부터 오래 있을 생각은 없었다. 1년안에 나가는게 원래 내 목표였지만 어찌저찌 채용시장이 얼어붙은것도 아직 내가 부족한것도 어려가지 겹쳐서 이직을 아직도 못하고 있다…최대한 빨리 서비스하는 회사로 이직하는게 내 목표이긴 하지만 너무 급하게만 생각하지는 않으려고 한다.

지금도 충분히 배울수 있는건 있고 아직은 부족하다고 나 자신도 알고 있기 때문이다. 물론! 올 한해 열심히 준비했어서 내년 2월이나 3월쯤에는 이직하는게 나의 목표이다. 지금 11월부터 시작해서 이력서를 3번정도 갈아 엎은 것 같다. 매번 볼때마다 왜케 부족한지…SI 특성상 깊이가 부족하긴한데 매번 회사 탓을 할수 없는 노릇이다.
이직을 하기전에 회사 내에서 효율적이지 못한걸 최대한 고쳐보려고 노력을 많이 하는 편이다. 내가 나가더라도 이건 계속해서 유지 됐으면 좋겠다. “타자를 변화시키는 힘은 계몽이 아니라 전염이다.” - 올드 걸의 시집에서 봤던 내용이다. 계속 되길 바라는 마음이지만 누군가 이걸 딱 맡아서 해주길 바라는 건 아니다. 시집에 내용처럼 내가 의지를 갖고 꾸준히 나아간다면 주변에서 언젠간 인정해주고 따라와줄 것이라고 믿는다.

TMI가 난무하였지만 다시 돌아가서 가고 싶은 회사에 대해서 작성해보겠다.

서비스를 하는 회사

회사를 고르는데에 있어서 가장 큰 척도이다. 다음 회사는 무조건 SI가 아닌 서비스를 하는 회사로 이직을 하고싶다. 그 이유는 SI는 유지보수면 유지보수만, 기능 개발이면 기능 개발만 딱 그 정도까지만 하고 그 뒤론 나에게 맡겨진건 새로운 프로젝트이다. 한 프로젝트를 오래 경험하고 성능 테스트, 부하 테스트 등등 많은 리팩토링을 하고 싶다.
SpringBoot를 사용하는 회사

나는 대게 SI면 Spring을 사용하여 개발을 할 줄 알았다. 근데 생각보다 Python, Node등을 사용하는 경우도 허다했다. 이게 생각보다 한 언어를 계속하지 못하니까 언어에 대한 깊이가 너무나도 낮아진 것 같다…그래서 하나의 언어 하나의 프레임워크를 잘 다루고 다른걸 해보고싶은 마음이다.
코드 리뷰를 하는 회사

내가 만든 코드가 어떤 헛점이 있고 다른 사람들은 어떻게 생각할까 의견을 듣고싶다. 내가 알기론 처음 코드 리뷰를 받으면 등에 식은땀이 줄줄 난다고 들었다..그런 경험은 싫으면서 좋은 경험..?ㅋㅋㅋㅋㅋㅋㅋㅋ말이 이상하지만 나도 받아보고싶다. 그리고 개인적으로 클린한 코드를 위해 노력하는 편이라 다른 사람들과 소통을 많이 해보고 싶다..😃
기술 블로그가 있는 회사

이건 개인적으로 바라는 부분인데, 다른 회사에 있는 기술 블로그를 많이 참고했던 터라 나도 꼭 기술 블로그를 운영하는 회사에 내 포스팅도 올라갔으면 하는 바람이다..ㅎㅎ
집과의 거리가 1시간 안으로 걸리는 회사

이건 강남, 판교 등등 서울 중심쪽에 위치하고 있어서 어느정도까진 커버가 가능한 것 같다.
맥북을 사용하는 회사

이것도 개인적인 바람!!
재택을 하는 회사

잠깐 재택을 해보니까 진짜 삶의 질이 너무나도 올라간다..꼭 다음 회사는 재택이 있는 회사로 가고싶다. (내 소망)

회사 프로젝트 회고

~~올해 했던 큰 프로젝트는 사내 백오피스 개발, ??? 2차 개발이었다.~~

하나씩 뜯어보자면 사내 백오피스 개발은 거의 HR 시스템을 만드는 일이었고, 해당 프로젝트를 할 때 기술 선택에 대한 제약이 거의 없어서 하고싶었던 기술을 팀원들에게 설명하고 설득하는 과정들을 많이 거쳤다.

클린 아키텍처, 단위 테스트, API 명세서 개편등 다양한 방면으로 SI에서 없던 것들을 시도해보았다. 시도했던 과정중에서는 나름 여유가 있던 프로젝트라 다들 잘 따라와주기도 하였고, 새로운 변화에 대해 반대하기보단 이해하려고 노력해줬던 팀원들에게 감사하다.

결과적으로 여러번에 요구사항이 변경되었지만 새로 도입했던 방식 덕분에 금방 발을 맞춰 갈수 있게 되었다. 그리고 지금 와서 생각한거지만 그당시 나는 너무나도 신기술에만 집착하던 사람이었던 것 같다. 왜냐하면 그 당시에는 이거라도 안 하면 나에게 강점이란 무엇인가라는 고민을 많이 했던 시기였고 SI에서 어떻게든 자발적으로 무언가 했다라는 어필을 남기고 싶었기도 했다. 그러나 지금 다시 돌이켜보면 당연하게 해야하는 것(신기술을 도입하는)은 절대로 없는 것 같다. 그 중 클린 아키텍처는 소위 말하는 힙한 기술 스택이었다. 해당 기술 스택은 러닝커브가 매우 깊고, 불 필요할 정도에 클래스 나누기 등 여러가지가 우리를 힘들게 하였다. 나라도 잘 알고 있었다면 다른 사람들에 방향이 되어 주었을 텐데 나도 깊게 이해하지 못하고 해당 기술 스택을 도입하자고 했던 나 자신에게 실망감을 느꼈다. 앞으로는 무언가 도입하기 전에 그 기술 스택에 대해 1 ~ 5렙까지 있다면 3.5렙 이상까지는 이해한 상태로 도입하자고 얘기를 꺼내볼 것 같다.

열정만 가득했던 신입의 패기로 팀원들을 힘들게 해서 많이 미안한 마음을 가지고 있다. 그래도 프로젝트를 경험함에 있어서 많이 생각하고 성장했던 시기가 아닌가 싶다. 팀원들을 설득하는 방법, 내 편을 만드는 방법, 처음 듣는 사람도 이해할 정도에 간단한 비유법 등 커뮤니케이션이 꽤나 많이 증가한 것 같다.

두번째 프로젝트는 ??? MP 서비스 개발이다. ??? 2차라고 써두었는데 1차는 이미 다른 팀원들이 해둔거이고 그걸 고도화하는 방식으로 작업을 진행하였다. 1차때 했던 관례들을 최대한 지키면서 2차 고도화를 진행하려고 하려니 조금 어려웠던 부분들도 존재하는 것 같다. 그래서 팀원들과 얘기를 통해 개편해야할 사항과 그대로 두어야하는 사항을 나누면서 점진적으로 수정해 나아갔다.

그리곤 대망에 오픈날이 다가오기 2주 전부터 자잘한 오류들이 계속해서 나오기 시작하였다. 최대한 오류를 미연에 잡기 위해 테스트 코드도 많이 작성 하였는데..테스트 코드로도 못 잡는 부분들이 계속해서 나오게 되었다. 미연에 몇가지 방지 장치들을 설치하긴 했는데도 오픈 직전에는 어쩔수 없나보다 느꼈다ㅠ 계속해서 수정 및 개발기 반영을 계속 하다보니 코드가 점점 더러워지는 것을 확인하게 되었다. 이런 부분들은 리팩토링을 통해 어느정도는 처리하게 되었다.

쓰다가 너무나도 재미 없어서 이건 포기했다……

일상

기술 블로그란 주제로 써왓기에 내 일상에 대해서 다뤄본적이 없어 쓰려니 조금 어색한 것 같다. 개발자를 직업을 갖는게 괜찮은가 누군가 물어본다면 나는 재미나게 개발하고 있는 편이라 ok라고 대답할 것 같다. 개발자란 직종을 선택하기 전에는 매번 바뀌는 트렌드에 계속해서 공부해 나아가야한다 등 지레 겁을 주는 얘기들이 많았다. 물론 반은 맞고 반은 틀리다. 이건 사람에 따라 다를수 있는데 지금에 만족하는 사람들은 적당하게 사는 것 같고 지금에 만족하지 못하는 사람들은 무엇인가 하려고 노력하는게 보인다.

물론 노력을 하지 않는다고 문제가 되는것은 절대 아니다. 회사 생활을 하며 버티는 것 만으로도 얼마나 대단한 일인가 다 각자에 사정속에서 살고 있기에 남에 대해서 이러쿵 저러쿵 얘기하는 것은 좋지 못해 보인다. 퇴근후에 공부를 안 한다고 해서 나쁘게 보거나 내가 여기서 제일 잘 낫다라는 생각을 가지고 있다면 버리는 것이 좋을 것이다.

퇴근 후(출퇴근 + 저녁을 뺀)를 생각해보면 12시까지 나에게 4시간정도 있는 것 같다. 그 중 월, 수, 금은 헬스를 하며 보내기에 1시간을 사용하고 나머지 화, 목은 강아지와 산책을 하며 1시간을 사용한다. 나머지 3시간 중 2시간은 개인 공부로 시간을 보내며, 나머지 1시간은 여자친구와 전화 통화하며 하루를 충전한다.

여자친구가 있기에 더욱더 책임감이 생기는 것 같다. 나를 믿고 의지해주는 사람이 있기에 나는 꼭 보답하고 싶다. 좋아하는 사람에게 잘 보이고 싶은 마음은 만인의 공통점 아니던가, 좀 더 나은사람이 되기 위해 오늘도 나는 노력할 것이다.