개발자가 되고 첫 일년이 지났다.
처음이라는 것은 무척이나 강렬하지만 그만큼 금세 휘발되고 마는데, 회고를 통해 정리하고 기억하려고 한다.
1. 퇴사
3개월을 채우지 못하고 회사를 그만뒀다. 근원적인 이유는 내가 절대 성장하지 못할 것이라는 확신 때문이었다. 파견된 프로젝트의 개발 환경은 그야 말로 최악이었다.
당시 파견 직전에 김영한님의 스프링 원리 기본편 강의를 들었었는데, 파견지에 가보니 내가 바로 그 첫 강의에 언급되는 지옥의 EJB를 써야했다. Model1 방식으로 설계되어 있어 한 화면에 5천 줄이 넘는 JSP 소스를 욕을 뱉으면서도 수정 요청이 들어오면 처리하고 EJB 가 어떻게 동작하는지도 모른 채로 다른 소스코드를 눈치껏 보면서 파악했다.
사실 EJB는 아직도 뭔지 모르겠다.
일주일에 한 번 정기적으로 운영에 반영하는 날이면 작업 내역을 SVN에 커밋하고 업무 시간이 종료된 후 FTP로 수정한 JSP를 운영서버에 전송하고는 관리자가 서버를 재시작 하는 것을 대기해야 했다. 반영 전에는 JSP 파일 하나를 수정하면 문서를 세 개는 산출해야만 했다.
프로젝트에 사용되던 JDK 버전의 공식 지원이 이미 종료되었기 때문에 별도 프로젝트에서 내가 운영하는 프로젝트의 JDK를 버전업하는 차세대 프로젝트를 하고 있었던 것은 부수적인 이야기다.
근무하면서 무언가 이상하다 라고 느꼈지만 당시에는 무엇이 이상한지는 몰랐다. 단순히 회사에서 개발하는 시간 동안 동시대를 살아가고 있는 개발자들과 점점 격차가 벌어지고 있는 것 같은 형체 없는 불안함에 휩싸였을 뿐. 하지만 이 불안감이, 이전 직장인 영화관에서 오픈 준비를 하면서 하루 16시간씩 근무했던 기간보다 나를 더 지치게 했다.
이상한 무언가의 형태를 찾기 위해서 퇴근 하면 공부를 했다. Git과 CI/CD를 배우면서 점점 불안감이 뚜렷한 근거를 가지게 되고, Spring Boot와 Java 8의 함수형 프로그램을 배우면서 그만둬야겠다 고 결정 내렸다. 단순히 동시대의 개발자들에 뒤쳐지고 있다는 막연한 불안감보다는, 보다 합리적으로 서비스를 제공하는 회사에서 근무하고 싶은 마음이 생겼다.
그렇다고 바로 이직을 생각했던 것은 아니다. 내가 선택한 회사인데 노력해보지도 않고 퇴사하는 것은 도리가 아니라고 생각했다. PM님께 가지고 있는 고민을 말씀 드리면서 적어도 Spring Framework 를 사용하는 프로젝트로의 이동을 요청드렸지만, 돌아오는 것은 "이 환경에서도 배울 것은 있고 자바 버전이나 프레임워크는 중요하지 않다. 개발은 다 비슷하다." 라는 대답이었다. 그리고 내가 프로젝트를 이동하려면 최소 2년은 지금의 운영업무를 해야 한다고 했다. 여러 번 미팅을 요청드렸더니 옆에서 Spring Boot / JPA 환경에서 개발하고 있는 동기와 프로젝트를 바꿔줄까 하시길래 그때부터는 입을 닫고 다른 회사에 입사 지원을 했다.
그리고 몇 번의 시도 끝에 수습을 끝내지 않고 지금 회사로 이직을 하게 됐다.
2. 회사 생활
개발에 관심이 많고 친절한 회사 동료들이 있는 지금의 회사에서 많은 것을 배웠다. 리눅스 환경에서의 서비스 운영, 웹서버와 WAS를 분리하여 관리하는 것, 새로운 서비스를 개발하기도 하고 운영 중인 서비스를 유지보수를 하기도 했다. 주어진 요구사항과 사용 가능한 리소스를 가늠해서 일정을 산출하는 실무 환경에서의 값진 경험도 얻었다.
특히 동료들이 개발에 관한 이야기를 하다 언급되는 책들은 웬만하면 따로 사서 읽었던 것이 큰 도움이 되었다. 자주 거론되는 기술들도 따로 적어두었다가 꼭 한 번은 공부해보곤 했다.
이번 회사의 개발환경도 다소 레거시하거나 부족한 부분이 있었지만 이것을 개선해나가는 것에서도 재미를 느꼈다. 처음에는 세상이 나를 억까한다고 생각하면서 투정을 부렸지만... 내가 무기로 내세울 수 있는 포인트들은 현재의 불편함을 개선하는 데에서 생겼다.
개선했던 포인트 중 가장 직접적으로 업무에 긍정적인 영향이 있었고 만족스러운 것은 로깅 시스템을 개선한 것이다. 기존에는 두 가지 불편함이 있었다. 에러 로깅이 시스템 내부에만 이루어졌다는 점, 그리고 서비스에 오류가 있었을 때 확인하기 위해 리눅스 내부에 있는 로그를 윈도우로 옮기는 데 많은 시간이 소요되었다는 점이다.
이를 예외가 터졌을 때 바로 슬랙으로 알람 받을 수 있도록 시스템을 개선하고 자동화 프로그램을 개발해서 총 9개의 리눅스 서버 로그 파일을 클릭 한 번으로 윈도우로 가져올 수 있도록 했다. 이러한 개선을 통해서 예외 상황을 실시간으로 확인할 수 있고 로그 파일 수집 시간은 약 120초에서 2초 내로 줄일 수 있었다.
하지만 도망친 곳에 낙원은 없었을까. 인턴 기간이 끝나고 몇 개월이 지나지 않아서 같은 서비스를 개발하고 운영하고 있는 선배들이 모두 퇴사했다. 혼자서 두 개의 서비스를 운영하고 하나의 신규 서비스를 개발해야 했는데 정말... 어떻게든 하고 있지만, 단순히 하고 있다는 사실에서 어떠한 피드백도 얻을 수 없어서 다음 단계로의 성장을 목표로 하기는 쉽지 않음을 느끼고 있다.
3. 개발동아리 DND 활동
개발 네트워크가 없는 비전공자로서 다른 개발자들은 어떻게 성장하고 있을까? 는 떼놓을 수 없는 고민이었고 이러한 고민을 하고 있는 사람들에게 업계 선배들은 "동아리나 스터디처럼 커뮤니티 활동을 하라"는 조언을 해주었다. 처음에는 스터디를 알아보다가 책 한권을 나눠서 읽고 발표하는 정형적인 스터디 방식이 내게 적합한 학습방법은 아닌 것 같다는 생각에 개발 동아리로 눈을 돌렸다.
소속감과 책임감이 있는 상태에서 무언가를 해결하는 걸 즐기는 편이니 즐겁게 할 수 있을 것 같았다.
마음을 먹은 뒤로 약 세 달간 지원한 모든 동아리에서 탈락했다. 몇 군데 더 있었는데 메일이 안 보인다.
개발 동아리들은 평균 10대 1 이상의 경쟁률이 있었고 팀 빌딩 비용을 내고 참여하는 비사이드마저 3:1의 경쟁률이 있었다. 다른 개발 커뮤니티에서 모집하는 사이드 프로젝트에 지원해볼까 고민했지만, 참여하는 인원에 대한 검증이 이루어지지 않기 때문에 하지 않았다. 동아리 지원에서 떨어진다는 것은 내가 아직 검증을 통과할 만큼 쌓은 것이 없기 때문이라고 생각했다.
그리고 7월 1일, DND에서 합격 메일을 받았다.
당연히 너무 기뻤지만 걱정도 생겼다. 국비학원과 SI회사, 현 직장을 합쳐도 채 1년이 되지 않은 개발 기간. 그마저도 모두 레거시한 환경에서의 경험이었으니. 그래도 오랫동안 목표로 해왔던 동아리 활동이고, 폭발적으로 성장할 수 있는 기회를 놓치고 싶지는 않았다. 같은 팀원에게 민폐를 끼치기도 정말 싫었고. DND 이전 기수에서 진행한 프로젝트들을 보고 필요한 기술들을 리스트업 해서 동아리 개발이 시작되기 전까지 매일매일 학습 했다.
김영한 님의 JPA, QueryDSL, Spring Data JPA 강의를 몰아서 듣고 Spring Security와 JWT, 도커 그리고 DDD나 JUnit에 대해 공부했다. 모두 꼼꼼히 보지는 못했지만 개발을 시작할 수는 있었다.
하나의 서비스를 기획 단계부터 런칭까지 하는 경험은 아주 색다른 경험이었다. 서로 다른 직군이 각자의 입장에서 적극적으로 의견을 내고 조율하는 과정이 있고, 이 조율 과정의 대전제가 보다 나은 서비스를 만들기 위해 이루어지는 것을 겪으면서 회사에서 이렇게 일할 수 있으면 출근길이 얼마나 즐거울까? 하는 생각을 했다.
무사히 Linkkle 서비스를 플레이스토어에 런칭했고, 운영까지도 해보자고 생각했지만 각자의 사정으로 인해 실제로 운영까지 할 수 없었던 점은 아쉽다.
4. NextStep
NextStep의 TDD, 클린 코드 with Java 15기를 수강했다. NextStep의 교육은 많은 개발자들이 강력 추천하는 교육이고 실제로 내가 경험한 바로도 아주 좋은 교육이다. 하지만 2022년 진행했던 일 중 가장 아쉬움이 많이 남는 기간이었다. 조금 더 준비가 되고 나서 진행했다면 아주 많이 배울 수 있었을텐데.
미션 3단계의 후반부에 도착하니 요구사항이 명확하게 이해가지 않았고 그러다보니 어떻게 구현할 지 멘붕이 왔다. 안그래도 구현력이 부족한 편인데 요구사항까지 명확하게 이해하지 못했으니 멘탈을 지킬 수가 없었다. 이때 포기하지 않고 남들의 코드를 봐서라도, 리뷰어 님께 끈질기게 물음을 던지면서 진행했어야 했다.
하지만 결과적으로는 포기해버렸다. 한 주를 미루고보니 점점 더 손을 대기가 싫어졌고 다른 해야 할 일들은 우선순위가 높아져만 가고... 결국 3단계의 후반부를 포기하고 재성 님이 꼭 해보라고 한 미션인 4단계의 첫 미션을 수행하고는 이후 단계의 진행을 포기했다.
디프만 동아리 활동을 병행함과 동시에 회사 업무가 바빠져서 종종 야근을 했다는 변명도 한 줄만.
비록 완주하지는 못했지만 객체지향적으로 코드를 짜고 테스트 코드를 작성하는 방법에 대한 많은 공부가 되었다. 특히 TDD 는 개발방법론이 아니라 설계방법론에 가깝다는 재성님의 말씀이 아직도 기억에 남는다.
그리고 테스트 코드라는 것이 기능이 올바르게 작동하는 지를 검증하는 것을 넘어서 코드 리팩토링을 위해 꼭 필요하다는 새로운 관점도 얻게 되었다.
5. 디프만 활동
DND 동아리 활동이 끝나고 새로운 서비스를 만든다는 것이 너무 재밌었던 나머지, 바로 이어서 새로운 동아리를 시작했다. 같은 개발 동아리지만 디프만은 10명이 한 팀으로 4개월 간 프로덕트를 개발하기 때문에 DND와는 조금 다른 호흡으로 활동을 하게 되었는데, 가장 좋았던 점은 내가 목말라 있던 개발자 친구를 많이 사귈 수 있었다는 점이다!
백엔드 개발자로서는 나를 리드해주는 팀원을 만나서 많이 배울 수 있었다. 완벽하지는 않지만 멀티 모듈으로 프로젝트를 구성해볼 수 있었고 처음으로 서비스를 개발하면서 코드 리뷰를 해봤다! 코드 리뷰의 장점과 단점을 충분히 느껴볼 수 있었던 시간이었다.
코드 리뷰를 통해서 비효율적인 쿼리가 나가는 것을 발견하기도 하고 가독성이 좋지 않은 코드를 개선할 수도 있었다. 하지만 팀원 모두가 회사 생활을 하고 있었기 때문에 코드 리뷰로 인해 작업 속도가 저하되는 경우도 있었다. 이는 PR 에 대해 모든 인원의 Approve 를 받지 않으면 Merge 되지 않도록 설정해두어서 더더욱 그랬다.
테스트 커버리지를 높이고자 API 명세 도구로 Spring REST DOCS 를 선택했다. 모든 API 계층에 대한 통합 테스트를 작성할 수 있었지만 작업 속도가 Swagger를 사용하는 것에 비해서는 더뎠고, 가장 중요한 도메인에 대한 테스트는 많이 작성하지 못했다.
코드 리뷰나 REST DOCS를 도입해보면서, 선택에는 항상 트레이드 오프가 발생한다는 것을 피부로 느낄 수 있었다. 보다 나은 코드 퀄리티를 유지하고, 테스트 커버리지를 올릴 수 있었지만 그에 대한 트레이드 오프로 생산성이 저하되었다.
하지만 조금 더 넓은 시야를 가지게 된다면, 결국 당장의 기능이나 명세가 빠르게 추가되는 것보다 일정한 수준 이상의 코드 퀄리티를 유지하고 테스트 코드를 작성하는 것이 유지보수의 단계에 간다면 결국 결과적인 생산성이 높아질 수도 있지 않을까 하는 생각도 들지만, 아직은 피부로 느낄 수는 없었다.
동아리 활동기간이 끝나고 디프만의 IAM 계정으로 운영하던 서버를 개인 AWS 계정으로 옮겨야 했는데, 이때 서버 이전이 무중단으로 서비스에 대한 영향도를 최소한으로 할 수 있는 방법에 대해 고민하다가 결국 해내지는 못했다. 디프만 IAM 계정으로 운영되는 서버의 DB 연결을 개인 서버로 바꾼 후 기존 서버 DB를 스냅샷을 찍어서 옮겼는데 만약 이 서비스가 트래픽이 많이 발생해서, DB를 교체하는 순간에도 DB에 DML 쿼리가 엄청나게 날아온다면 어떨까 끔찍한 상상을 했다.
디프만 최종 발표 때는 대상을 수상했다! 이때는 주말에도 계속 출근을 하던 시즌이라 참여는 못했지만 멋진 상패와 케이크 사진를 공유 받을 수 있었고 그 순간을 누리지 못한 조금의 섭섭함과, 큰 기쁨이 있었다.
출시 이후에는 아맞다 서비스가 노트폴리오에서 오늘의 픽으로 선정되어 메인에 노출되기도 했다. 내가 만든 서비스를 누군가가 이용하고 있다는 사실은 회사에서도 느낄 수 있지만, 기획부터 개발까지 참여한 서비스를 누군가가 이용해주는 것은 또다른 느낌이었다.
아맞다 서비스는 천원이라도 수익을 얻는 것을 목표로 계속 개발해보려고 한다.
6. 2022년 마무리
2022년에는 커밋 기록을 남기는 데 꽤 신경을 썻었다. 커밋을 남기는 게 오늘 내가 공부를 했는지 안 했는지를 증명하는 척도라고 생각했었다. 그리고 하루 커밋을 놓치고 나면, 실패했다는 생각에 꼭 며칠을 연달아 쉬게 되는 걸 깨닫고 나서는 크게 연연하지 않기로 했다.
그래도 깃허브에 커밋을 남겨두면 지금처럼, 후일에 이때는 이런 공부를 했었지, 하고 볼 수 있는 점은 좋다.
2022년의 각 월마다 얼마나 몰입했는지에 대해 그래프를 그려봤다.
1) 이직 직전인 1월
2) DND에서 활동한 7월과 8월
3) NextStep과 디프만 활동을 한 10월 이후
그래프에서 상위를 찍었던 기간들의 공통점을 생각해보면, 마감 기한이 정해져있고 목표가 확실했던 기간이다. 그리고 또 한 가지 알 수 있는 것은 한 기간의 몰입이 끝나고 나면 급격하게 그래프가 내려간다는 것.
당연하게도 몰입도가 급격히 올라갔던 순간에 많은 것들을 배웠지만, 이후에 꽤 많이 휴식을 찾게 되었었다. 최고로 몰입한 기간들의 몰입도를 조금 낮추더라도 체력을 안배해서 전체적으로 조금씩 올리는 것이 전체합이 더 높지 않았을까. 마라톤을 인터벌로 뛰지 않고 일정한 속도로 꾸준히 달리는 것이 기록이 좋은 것처럼.
2023년에는 미리 몇 가지 목표지점을 생각하고 세밀하게 기간을 나눈 뒤 최고와 최저의 중간 쯤에서 꾸준히 공부하면 2022년보다 효율적인 발전을 할 수 있을 것 같다.
7. 2023년 목표
첫 번째는 이직하기.
원티드나 점핏, 프로그래머스 등 다양한 플랫폼을 통해 지원했지만 지금으로써는 타율이 매우 좋지 않다. 그래도 처음에는 아예 전부 서류 탈락을 하다가, 멘토링을 통해서 이력서 피드백을 받은 후에는 서류 합격률이 5~10퍼 정도는 됐다.
3월부터 7월 DND에 처음 합격하기까지 동아리 지원에서도 모두 떨어졌었고 이를 피드백으로 삼아서 꾸준히 공부해서 결국 DND를 통해 동아리 활동을 시작할 수 있었듯이 취업활동도 똑같을 것이라 생각한다.
꾸준히 지원해보고 떨어지면 왜 떨어졌는지 고민해보고. 멘토링도 받아보고 과제나 면접에 떨어진 기업에는 피드백도 요청해보다 보면 언젠가 목표로 하는 환경에서 일할 수 있겠지. 성장은 OK인지 NO인지에 대한 피드백에서 온다고 믿는다.
두 번째는 넓게가 아니라 깊게 배우기.
2022년에는 몰랐던 여러 기술들의 사용법을 배운 해였다면, 올해는 하나하나의 기술을 깊게 공부해보려고 한다. 토비의 스프링, Real MySQL, Modern Java in Action, Effective Java 를 책장에 꽂아두고 펼치지 않았는데 올해는 긴 호흡으로 읽어야겠다. Shell Script와 Linux도 다음 단계로 발전할 수 있는 중요한 단서라고 생각하고 있다.
깊게 공부하는 과정에서 얻게 되는 것들은 블로그에 정리하면서 내 지식으로 만드는 것이 목표다. 글또 8기 활동도 좋은 촉매제가 될 것 같다.
8. 2022년의 개인적인 사족
자기 앞의 생 이라는 책에 오랫동안 빠져 있었던 적이 있다. 내용도 좋지만 특히 책의 제목이 주는 어감이나 작가의 삶을 좋아한다.
로맹 가리는 공쿠르 상을 수상하고 에밀 아자르라는 필명으로 자기 앞의 생을 써내고 공쿠르 상을 다시 한 번 수상한다.
그가 언젠가 인터뷰에서 이런 말을 했다.
"나는 삶을 살아가기보다는 내 삶에 의해 살아졌다는 느낌이 듭니다. 내가 삶을 선택했다기보다는 삶의 대상이 되었다는 느낌입니다."
-2022년 회고 끝.
'생각글쓰기 > 회고' 카테고리의 다른 글
| DND 7기 활동의 기술 회고 (0) | 2022.08.26 |
|---|---|
| 2021년 회고: 비전공자가 개발자가 되기까지 (0) | 2021.12.25 |
댓글