2022년 회고록 (백엔드 개발자로 정착하기 까지)

처음에 학생 때에는 뭔가 목표와 꿈이 있었다기 보다는 흘러가는대로 삶을 살아왔던 것 같다.

그래도 디자인에 관심이 있어서 관련된 과에 들어가서 포토샵, 일러스트, 영상편집 등을 배웠었지만 아쉽게도 디자인이라는 길은 나에게 맞지 않았었고 어영부영 세월을 보내다가 입대를 하고 복학하게 되었다. 

 

그러다가 우연히 화이트 해커 양성 인턴쉽에 들어가게 되었고 거기에서 멘토분이 들려주던 화이트 해커가 되기까지의 이야기와 IT 분야에서 종사하고 있는 여러 사람들이 더 높은 수준의 발전을 위해 거리낌없이 지식을 공유하고 오픈소스를 통해 기여한다는 문화를 듣고 보면서 홀린 것 처럼 관심을 가지게 되었고 그렇게 개발자의 길이 시작되었다.

 

2019년 ~ 2021년의 정리

2019년 

개발이라는 것을 무작정 더 공부해보기 위해 2019년 국비교육을 들어가게 되었다.

국비교육은 강사별로 호불호가 매우 나뉜다고 했었는데 다행히 나는 좋은 강사님을 만날 수 있었고 강사님도 가르치고자 하는 의지도 대단하셔서 웹 뿐만 아니라 웹개발자로써 필요한 CS지식에 대해서도 많이 알려주셨다. 덕분에 국비과정을 수료하기 전에 여러 SW 회사에 면접을 봐서 SI기업에 입사하게 되었다. 지금이라면 가지않고 더 찾아봤겠지만 그때에는 개발만 할 수 있다면 배우는 것도 많을 것이라고 생각했었다. 

 

2020년

회사에서는 공장 소프트웨어를 개발하는 회사였는데 너무나 개발환경이 열악했었고 내가 생각했던 개발 문화와 수평적인 조직 구조에 대해 거리가 먼 환경이였다.  운영체제도 지원이 한참전에 끝난 운영체제를 기반으로 개발을 했어야 했고 내부망 안에서 소프트웨어를 개발했어야 했기에 오픈소스나 버전관리시스템 등을 쓰는 것에 대해서도 제한이 매우 많았다.

 

더 경력이 쌓이면 바뀔 수 있을 것이라는 생각을 하면서 버텼었지만 버티면 버틸수록 근심만 늘어갔었다. 그러다가 우연히 OKKY라는 사이트를 알게되었고 나와 비슷한 경험을 한 사람들이 많이 만날 수 있었다. 이때 여러 상담을 하는 글을 많이 올렸었는데 많은 개발자분들의 답글과 다른 개발자들의 비슷한 고민글을 보면서 현실적으로 계속 남으면 나의 커리어와 내가 가고자 하는 목표와 멀어지고 있다는 생각을 하게되었고  이직을 결심하였다.

 

2021년

회사에 퇴사하는 사람이 많아지면서 나에게 전산실 유지보수로 인사이동을 해야된다고 청천벽력같은 소식을 통보 받았다. 1년동안 여러 프로젝트를 들어가고 경험한 결과 인사이동을 할 경우 개발과 길이 더 멀어질 수 밖에 없었고 갑을관계가 확실한 구조여서 이전보다 더 많은 부분에서 제한이 생기는 것은 확실한 상황이였다. 그렇게 나는 퇴사를 선언하고 백엔드 개발자로 커리어를 전환하기 위한 여정을 떠났가.

 

초기에는 국비교육이나 부트캠프를 가더라도 내가 이미 알고 있는 내용들을 또 공부할 것이라는 생각에 이동욱님이 쓰신 스프링 부트와 AWS로 혼자 구현하는 웹 서비스라는 책을 구매하고 이책을 기반으로 토이프로젝트를 진행하고 있었다. 나태해지지 않기 위해 나와 비슷한 목표를 가진 사람들을 모왔고 3~4명이서 카페에 모여 모각코를 진행했었다.

계속되는 번아웃

공부와 프로젝트를 병행를 하면서 여러회사 지원했지만 계속되는 불합격 소식과 반복되는 프로젝트의 삽질을 경험하면서 번아웃이 자주왔었다. 그렇게 나는 점점 지쳐가면서 코드에 손을 놓기도 했었고 집에만 틀어박혀 생활하기도 했었다. 하지만 이렇게 손을 놓고만 있을 수는 없었고 무엇보다 이전으로 돌아가고 싶지 않았기에 인프런에 개발자 취업에 관련된 강의도 듣고 스타트업 취업 멘토링도 받으면서 나 자신을 계속 채찍질하여 강제로 할 수밖에 없는 상황을 만들었어야 했다.

 점점 눈에 보이는 효과들

처음에는 백엔드 개발자로 이직하기 위해서는 프로젝트와 백엔드 기술만 익히면 된다고 생각을 했었지만 그것은 나의 우매함의 봉우리였다. 커리어의 방향, 문제해결능력, 리더쉽, 커뮤니케이션 등 많은 부분이 필요했고 이러한 부분에서 준비가 미비했던 나는 계속된 실패를 했고 좌절하였다. 부족한 부분을 개선하기 위해 멘토링에 대한 피드백과 여러 면접봤었던 자료들을 정리하면서 내가 부족했던 부분에 대해서 정리하고 개선하였다. 그렇게 나의 부족한 부분을 개선하면서 점점 서류에 붙고 면접을 보는 기회도 점점 많아졌다. 그리고 막막하던 프로젝트들도 전체적인 구조가 보이기 시작했었고 이전보다 더 수월하게 진행하면서 나아갔다. 

 

서비스 회사에서의 개발은 결국 팀단위로 협업하고 움직이게 된다. 혼자 개발만 해왔던 나에기 이러한 부분이 벽으로 다가왔고 면접을 볼 때 마다 협업이나 리드해본 경험을 질문했었고 그때마다 제대로 답변하지 못했다. 이력서에서도 팀과 협업 해본 경험이나 팀을 리드 해본 모습이 잘 드러나지 않아 기업들 입장에서 좋은 모습으로 보이는 것이 어려웠을 것이다.

처음부터 다시

 

같은 것을 또 배운다는 생각에 부트캠프를 가지 않으려 했지만 사이드 프로젝트의 팀원들을 구하는 것은 생각보다 많은 시간과 리소스를 투자해야하고 또 구한 팀원이 마무리를 지을 때까지 같이 있을 것이라는 보장도 없었다. 그렇기에 어쩔 수 없이 부트캠프를 신청하였고 내가 배웠던 것을 다시 배우기로 마음을 먹었다. 하지만 이전과는 달라야 했기에 좀 더 난이도를 높여 시작하기로 마음을 먹었다.

어렵게 시작하기

같은 Input을 넣고 다른 Output을 바라는 것은 미친 짓이다. 나는 이러한 경험을 한번 겪었었고 두번까지 겪어야 깨닫는 멍청이가 될수는 없었다. 그럼 어떻게 해야 난이도를 올릴 수 있을까? 고민을 많이 했었다.

 

그러다가 이전에 봤었던 리처드 파인만의 인터뷰 영상이 생각났었고 그것을 통해 고민을 해결하는데 도움을 받을 수 있었다. 내용을 요약하자면 리처드 파인만은 기자가 자석이 왜 서로 밀어내는가에 대해 질문했을 때 처음에는 기자가 이해하기 쉬울 정도로 쉽게 답변했고 이에 불만족한 기자는 계속 왜라는 질문을 던지면서 심오한 답변을 요구하자 더 설명해도 의미없다는 것을 기자에게 비유와 예시를 통해 재치있게 반박하였었다. 그리고 이전에 봤었던 시니어 개발자들의 영상에서도 실력있는 개발자는 어려운 문제를 쉽게 풀어내고 어려운 내용들을 모두가 이해하기 쉽게 전달할 수 있는 사람이 실력있는 개발자라고 했었기에 지금 나에게 부족한 어려운 문제를 쉽게 풀어낼 수 있는 메타인지 능력을 기를 수 있는 환경을 만들어야 했다. 

 

나는 이러한 환경을 만들기 위해서 온라인으로 부트캠프를 운영하고 있는 매니저에게 온라인 모각코를 열 수 있을지 요청을 했고 매니저님은 흔쾌히 제 수락을 들어주셨다. 실시간으로 배우고 공유하기 위해서 줌을 결제하고 매일같이 온라인 모각코를 아침부터 새벽까지 열었고 지속적으로 도움을 요청하는 사람이나 시스템을 설계하면서 서로의 견해에 궁금해하는 사람들로 모이기 시작했다. 나는 쉽게 더 자세하게 알려주기 위해서 더 공부하기 시작했고 그렇게 나는 2개월이라는 짧은 기간동안 불태우면서 큰 성장을 할 수 있었다. 부트캠프도 우수수료통하여 마무리를 지을 수 있었다.

 

험난한 스타트업에서의 시작

개발을 할 줄 아는 사람에서 주니어 개발자 수준까지 성장한 나는 스타트업에서 오퍼를 받게되었고 면접을 보고 합류를 하게 되었다. 물론 A시리즈도 받지 못한 스타트업이였지만 지금에 나에게는 새로운 시작이 필요했고 여러 개발자의 인터뷰와 회고록을 보면서 다 각자 다른 출발점에서 시작했지만 모두들 꾸준이 전진한 결과, 더 앞서 나가 출발했던 사람들 보다 앞서 나간 것을 보고 나라고 못할 것이 없었다.

 

이제 시니어 개발자분에게 가르침을 받으면 순조롭게 나아갈 것이라 생각했었지만 입사 1주일 전에 시니어 개발자가 2주뒤 퇴사한다는 이야기와 입사 취소를 희망해도 괜찮다는 연락을 받았다. 하지만 취소하고 무르기에는 집도 계약하고 내려온 상황이였고 지방에서 서울까지 면접을 보기위해 몇시간을 왕복하고 다니는 것과 지방에서 얻을 수 있는 IT 관련 인사이트들은 거의 없었기에 입사를 수락하고 서울로 상경하였다.

 

2022년

무너진 스타트업의 꿈

 

스타트업 입사하고 나서도 쉽지 않았다. 네이티브앱 플랫폼이지만 안드로이드 개발자의 공석과 시니어 개발자의 공석, 시니어 개발자가 있기전에 있었던 주니어 개발자가 작성해놓은 레거시, 시장을 입증하기에는 부족한 유저등 많은 문제가 있었고 이대로 서비스를 운영하기에는 불가능해보였다. 하지만 다행히도 대표님이 알고계시는 외국에 계시는 시니어 개발자분의 도움을 받을 수 있었고 문제가 있던 프로젝트 방향성에 대해서도 바로 잡고 미들레벨의 백엔드 개발자와 마케터를 영입하면서 차차 풀려나가기 시작했었다. 하지만 연초에 결국 투자가 무산이 되면서 회사를 정리하게 되었다. 

 

중요한 건 꺾이지 않는 마음

이미 고난에 익숙해졌고 좌절할 틈이 없었다. 빨리 이직을 준비하여야 했었기에 이전에 정리해두었던 기업정보들과 면접 자료들을 다시한번 훑어보면서 여러 기업을 지원했다. 이제는 좀 더 안정적인 곳을 추구했어야 했기에 안정적인 기업을 위주로 지원을 하였었다. 이때 마침 전에 같이 부트캠프에서 공부했었던 분도 준비하고 계셔서 같이 면접 준비를 했었는데 이전에 온라인 모각코를 했던 경험 때문인지 서로가 멘토가 되어 피드백을 주고받을 수 있었고 그외에도 많은 도움을 주고 받으면서 취업준비를 수월하게 진행할 수 있었다.

그 결과 2주만에 이직을 하게 되었고 두곳을 면접을 통과하여 한곳은 최종합격을 받았었고 나머진 한 곳에서는 최종합격 소식을 기다리고 는있는 상황이였다. 둘 다 각자의 매력이 있었고 고민하고 있었지만 한 곳이 합격발표가 미뤄지게 되면서 결국 최종합격한 곳의 오퍼를 받아 입사하게 되었다.

 

혼자 걷기

새로 입사하게 된 기업은 테크 기업이 아니였고 제조 기반 기업에서 IT 사업 분야를 확장하기 위해 주니어 개발자들을 영입하여 운영하고 있었다. 이전과 마찬가지로 이번 기업도 혼자 남아서 프로젝트를 운영을 했어야 했다. 기존에 있던 백엔드 개발자는 이틀만에 복학했어야 했기 때문에 인수인계를 받을 시간이 이틀밖에 없었고 그마저도 개발 일정으로 인해 밀려서 입사하자마자 야근을 했었다. 대학생이 개발하였기에 스프링의 활용도나 코드에 대한 설계는 아쉬웠지만 불평한다고 상황이 바뀌지 않기에 빠르게 문제를 인식하고 개선해야 했다. 데이터 베이스나 API에 대한 문서나 개발 정책에 대한 문서도 없었기 때문에 말그대로 넓은 들판을 혼자 걷게된 상황이였다. 그나마 정말 다행인건 초기에 클라이언트를 개발하던 앱개발자분이 계셔서 많은 도움을 받을 수 있었다.

 

레거시 개선하기 

고치고 싶은 문제는 많았지만 MVP 단계의 서비스이기 때문에 레거시 시스템 개선에 많은 시간을 할애할 수는 없었다. 그래서 트레이드 오프를 잘 선택했어야 했고 잘못된 선택을 한다면 나뿐만 아니라 이 서비스를 운영하는 모든 팀원들에게 지장을 주는 상황이였기 때문에 신중하게 선택을 했어야 했다. 쉽지 않았었지만 그때의 내가 선택할 수 있었던 것에 최선이였다고 생각하고 지금이라도 개선이 되어서 다행이라고 생각한다.

 

개선했던 레거시들

• 스프링 시큐리티의 도입: 컨트롤러마다 인증, 인가 로직을 넣고 처리하기에는 생산성이 떨어지고 컨트롤러에 로깅, 인증 인가, 비지니스 로직 등 여러 로직이 섞이다 보니 문제를 파악하기에 쉽지 않았다. 그래서 최우선적으로 스프링 시큐리티를 도입하였다. 
• JDBC -> JPA로 변환: 자바 자체가 생산성이 좋은 언어가 아니지만 그래도 ORM을 통해서 상당한 쿼리와 관련된 작업들을 줄일 수 있다. 스프링 내부에서 엔티티를 통해 영속성을 관리하면서 프로젝트를 좀 더 객체지향적으로 설계하고 관리할 수 있었다. 
• 테이블 Zero DATE => null 전환: 가장 애를 먹었던 개선 중 하나였다. "0000-00-00" 형태의 값을 디폴트로 넣게되면서 JPA를 활용하는데 직렬화 하는데에서도 이슈가 많고 의미없는 데이터를 체크하는 로직이 추가됐어야 했다. 정석대로라면 테스트코드를 짜고 해당 값에 의존된 로직을 모두 찾아서 한쪽으로 모은 다음 리팩토링했어야 했지만 그럴 시간이 없어서 달리는 차에 생으로 타이어를 바꿔끼우듯이 배포할 수 밖에 없었다. 테이블의 일부임에도 불구하고 2주 동안 오류를 대응을 했어야 했다. 
• 단계적 로깅 시스템 개선: 가장 필요한 작업이였지만 처음부터 다할 수는 없었기에 단계적으로 나마 도입하기로 했다. 초기에는 로컬에 저장하고 매일 압축하도록 했지만 로그를 확인할 때 마다 FTP를 통해 다운로드 받고 해당 날짜를 찾기도 쉽지 않았다. 그래서 다시 한번 개선을 하여 클라우드 와치를 통해 로그스트림을 전달하도록 개선했다. 정석대로라면 클라우드 와치에 있는 로그스트림을 파일서버에 전달하고 로그 모니터링 시스템을 통해 볼 수 있도록 개선하고 싶었지만 현재가 최선의 구조였다.
• DevOps의 도입: 백엔드 개발자는 나 혼자였기 때문에 모든 것을 감당하기에 무리가 있었다. 그래서 부분적으로 젠킨스와 센트리를 도입하여 자동화와 에러 모니터링을 구축하여 나의 일을 덜 수 있었다. 이때 센트리와 젠킨스가 얼마나 강력한 툴인지 체감하게 되었다.
• 문서화: 내가 가장 힘들었던 부분 중 하나는 개발에 대한 히스토리를 사람의 기억의 의존하고 있어서 정확한 정책과 시스템을 이해하기 어려웠던 것 이다. 그래서 기존에 구축되어 있던 프로시저, 스케줄러, API, 트리거 등 하나하나 다 뜯어봐서 파악해야 했고 상당한 시간을 투자해야했다. 그래서 팀원들에게 문서화의 필요성을 공유했고 노션과 포스트맨 등을 통해 문서화를 진행하기로 했다. 물론 Swagger나 Spring Docs를 통해 API문서화를 하고 싶었지만 그러기에는 사용하고 있는 API와 사용하지 않는 API에 대해 알 수 없었기에 포스트맨을 선택하였다.

 

2022년을 정리하며

2022년에는 다사다난했던 해였지만 그만큼 많은 경험을 하고 성장할 수 있었던 해였다. 올해를 보내면서 가장 많이 바뀌었던 것은 프로덕트 개발에 대한 관점이 많이 바뀌었다는 것이다. 이전에는 클린코드, 소프트웨어 장인 정신 등을 읽으면서 나는 어떠한 상황에도 100점짜리 소프트웨어를 만들어야 된다고 생각했었다. 하지만 현실은 제한된 리소스와 일정에 맞춰 완벽한 소프트웨어를 만들지 못하는 상황이였고 나는 괴로웠었다. 그리고 내가 만든 프로덕트를 불신했었다. 그후로 여러 IT 컨퍼런스와 세미나의 참여를 통해 레거시를 개선했던 이야기와 여러 IT 기업들의 과거의 이야기들을 듣고 팀원들과 이야기를 공유하면서 제한된 환경에서는 트레이트 오프를 해야하고 현재에 맞는 최적의 선택으로 나아갈 수 밖에 없다는 것을 깨닫게 되었다. 그렇게 나는 기술부채에 대해 좀 더 관대하게 바라보게 되었고 현재의 최적의 선택을 하기위해 더 노력했다. 그러한 선택들로 인해 서비스는 점점 안정화하기 시작했고 오류에 대한 접수는 일주일동안 적어도 두번 이상의 오던 문의들이 2주일에 한두번으로 주기가 줄면서 내가 가고 있는 선택들의 자신감이 붙을 수 있었다. 

2023년 목표

2022년 목표에는 IT 컨퍼런스 참여, 사외 스터디 참여, 사내 스터디 운영등 여러가지 목표를 달성했지만 NEXT STEP에서 인프라 공방의 과제를 끝까지 완수하지 못한 것과 아직 다 읽지 못한 개발 서적 등 아쉽게 달성하지 못했던 목표들도 있었다. 그래서 2023년에는 좀 더 세부적인 목표를 세우고 실천하려고 한다. 인프콘에서 김영한 님이 말했었던 "나만의 프로세스를 만들고 반복해라 결과를 목표로 세우면 지치게 된다." 라는 말씀을 해주신 것처럼 2023년에는 나만의 프로세스를 만드는 것이 가장 큰 목표이고 세부적인 목표로는 그동안 내가 부족했던 쿼리 튜닝, OOP, Unit Test, Docker 등을 공부하고 스프링에 대한 깊은 이해를 위해 토비의 스프링이 완독이 목표이다. 그외에도 실력있는 개발자를 넘어 좋은 동료가 되기 위해 인문학책 4권 이상 읽기를 목표로 삼고 새해를 시작하려고 한다. 물론 쉽진 않겠지만 나만의 프로세스를 만들고 작은 성공을 반복 하다보면 큰 성공을 할 수 있을 것이라고 생각한다.