[개발일기] 5년차 개발자의 2023년 회고(부제: 2023년 내가 배운 것들)

목차

 

"포스팅을 시작하며"

2022년 말에 이직하며, 2023년은 이직한 회사에 적응하며 팀원들에게 신뢰를 쌓고 본격적으로 여기서 내가 하고자 하는 목표를 실행하기 위해 기반을 다지는 해였다. 내가 어떤 생각을 가지고 올해를 보냈고 또 내년에는 어떤 목표를 가지고 회사 생활에 임할 것인지 정리하는 글이 될 것이다.

 

"2023년 초에 나를 되돌아 보며"

누구나 그렇듯 빅테크 기업에서 일해보고 싶었다. 이유는 최신 기술스택으로 개발하고 싶었고 체계적으로 일하고 싶었기 때문이다. 그래서 도전을 했지만 결과가 좋지 못했다. 그래도 나를 인정해주는 현회사로 이직을 선택했고 1년이 지난 지금 너무 잘한 선택이라고 생각한다.

이직을 선택한 자세한 이유가 궁금하다면 아래 글을 추천한다.

https://jfbta.tistory.com/192

개발일기 ] 내가 퇴사하려는 이유

 

웹개발자만 존재하던 전 직장과 달리 팀의 규모가 커졌다. 분야별로 전문가인 동료들도 많아졌다.

1) 인프라ㆍ시스템 엔지니어
2) 데이터 수집 엔지니어
3) 데이터 분석가
4) 백엔드 서버 개발자(빅데이터 엔지니어 겸직)
5) 웹 풀스택 개발자

여러 전문가 동료들이 많아져서 새로운 경험을 할 수 있어 좋았다. 하지만 빅테크 기업에서 경험할 수 있는 환경과 문화는 적었다

내가 꿈꾸던 환경은 다음과 같다.

1) 웹 백엔드와 프론트엔드의 분리
2) 잘 설계된 아키텍처(MSA, Hexagonal)
3) JSP, Jquery가 아닌 프론트엔드 언어(vue, react) 사용
4) CI&CD 배포 자동화
5) PR 또는 MR을 이용한 코드 리뷰
6) Struts, Spring Framework가 아닌 Spring Boot 사용
7) MVC - Webclient가 아닌 Webflux 사용 경험
8) API 문서 자동화(Swagger, REST Doc)
9) 테스트 코드 작성
10) 잘 정리된 문서들(DB명세서, 아키텍처, API 문서 등등)
11) SQL Mapper가 아닌 ORM 사용
등등

vue와 Spring Boot는 사용하고 있었다. 하지만 나머지는 경험할 수 없었고 크게 실망했다.

 

"동료에게 배우려고만 하지 말고서 내가 배워서 전파하자!"

생각에 전환으로 성장하는 계기가 되었다. 관심 있게 본 회사들이 공통적으로 사용하는 기술들이 막연히 좋아 보였다.

왜 사용하는지 이유도 모르면서..

지금 생각하면 바보 같은 생각이지만 성장하는 과정이라 생각한다. 이것을 깨달았을 때부터 기술들을 왜 사용하는지 찾아보았고 학습했으며 적극적으로 의견을 제시하게 되었다.

 

"걸림돌"

동료들에게 의견을 제시하면 처음엔 대부분 돌아오는 답변은 회의적이었다. 우리 회사는 빅테크 기업과는 다르다고 하였다. 가장 많이 꼽은 원인은 업무 부담이 높아지는 것이었다.

예를 들면, 기존에는 구현을 하면 깃에 커밋만 하였다. 테크 기업에서는 구현뿐 아니라 테스트 코드도 작성하며, 커밋 전 PR을 통해 리뷰로 승인을 받는다. 

[기존 업무 플로우 그림]

[변경 후 업무 플로우 그림]

 

또 다른 예는 기존 업무도 바쁜데 학습할 시간이 없는 이유다. 모든 학습에는 러닝커브가 존재한다. 학습이 되어도 실무에 적용하면서 시행착오를 겪어야 비로소 온전히 사용할 수 있는 기술이 된다. 이 과정에 부담을 느끼는 이유가 제일 컸다.

 

"한 송이 꽃으로 봄을 만들 수 없듯이, 혼자만으로는 큰 일을 이룰 수 없다."

좋은 문화와 개발 환경은 혼자 이뤄낼 수 없다. 팀원 모두가 긍정적으로 받아들여야 하고 필요한 이유를 확실하게 인지해야 적극적으로 활용하여 나아갈 수 있다.

때마침 본부 내에서 개발자 및 엔지니어들이 돌아가면서 교육을 하는 제도가 있었고 나는 이를 활용해 '좋은 문화와 좋은 개발환경'에 대해 발표하였다. 

또 오래된 기술로 개발된 솔루션의 문제점들을 파악하고 새로운 기술로 마이그레이션 했을 때 개선되는 점들을 정리하여 팀에 제안하기도 했다.

이런 과정들로 인해 SQLMapper -> ORM과 Monolithic Architecture -> Client-Server Architecture 등 일부 개선된 기술들을 적용하였다.

또 온프레미스 Git 환경에서 Github로 변경하였으며, Github PR을 통한 코드리뷰를 시작하였다. 그 팀의 환경과 문화는 내가 정하는 것이 아니고 팀이 정하는 것이다. 이 때문에 팀이 이해해야 되고 함께 나아가기 위해 노력해야 한다.

 

"개발자는 비즈니스 로직과 트러블 슈팅뿐 아니라 기술 부채 청산도 고민해야 한다."

올해 가장 큰 수확은 Monolithic Architecture로 구현된 오래된 기술로 구축된 솔루션을 맡으면서 한계를 직접 경험해 본 것이다.

이 솔루션은 청산하지 않은 기술 부채가 많았는데 이 때문에 개발 속도가 상당히 느려졌다. 크게 2가지 문제가 있는데 Monolithic Architecture와 빌드도구로 Maven을 사용한 것이다.

Monolithic Architecture로 구축된 솔루션 환경은 Java, Maven, vue2, webpack 등을 사용했는데 분리되지 않은 환경이다 보니 vue에서 개발되어 install과 build를 할 때 생성된 node-module, dist 파일이 프로젝트 내부에 쌓였다. 그렇게 쌓인 프로젝트를 톰캣으로 빌드하여 배포하였다. 이렇게 되면 프로젝트는 많이 무거워질 수밖에 없다. 그래서 아키텍처에 관심을 가지게 되었고, 현재는 개선된 아키텍처인 MSA를 학습하고 있고 팀에 제안한 상태이다. 조만간 API Gateway와 BFF로 변경을 도전해 볼 수 있길 기대하고 있다.

또 Maven으로 구성된 환경은 캐싱이 되지 않아 Java와 xml파일을 수정한 경우  톰캣을 재기동했을 때 처음부터 다시 빌드를 하기 때문에 엄청 느렸다. 반면에 Gradle은 캐싱을 제공해주고 있기 때문에 한 번 빌드한 것은 빌드하지 않는다. 변경된 파일만 빌드하기 때문에 매우 빠르다.

여기서 기술 부채란 기존에 Maven을 사용하고 있었고 빌드 시간이 5분이 걸린다고 가정해 보자 Gradle은 최대 100배 빠르기 때문에 가장 빠른 5초로 가정하겠다. 이때 기술 부채 시간은 4분 55초이다. 개선되면 5초만 빌드하면 되기 때문이다.

그래도 기술 부채가 무엇인지 잘 모른다면 기술 부채에 대해 잘 작성된 게시글이 있어 추천한다.

https://yozm.wishket.com/magazine/detail/1331/

개발자라면 마주치는 기술 부채, 꼭 다 갚아야 하나요? | 요즘IT

 

많은 회사들이 기술 부채 개선에 대해 관심이 없는 경우가 많다. 신규 서비스 출시와 서비스 확장에만 관심이 많다. 기술 부채가 쌓인 경우 출시가 늦어지고 이슈가 많은 서비스가 될 가능성이 높다. 서로 탓하는 것보다 관심을 갖고 우리 서비스(제품)의 기술 부채가 무엇인지 파악하고 개선해 보는 것은 어떨까?

 

"마무리"

커리어를 시작한 19년부터 22년까지는 생존 능력을 키우기 바빴던 것 같다. 그리고 23년 올해는 생각이 더 성숙해졌고 주니어가 아닌 시니어로 나아가기 위해 또 전문가로서 비즈니스 역량을 키우기 위한 기반을 다진 해였다. 내년에는 올해 고민하고 학습했던 기술들을 실무에 적용할 수 있는 것이 목표고 그렇게 되길 바란다.