개요
작년에 회고록을 작성한 지 벌써 1년이 지났다. 시간이 빨리 간 것 같지만, 1년이란 시간 동안 내가 느끼고 배운 것들을 생각해 보면 절대 짧지 않은 시간이었던 것 같다. 그래서 작년에 내가 겪었던 일들에 대해서 간단하게나마 정리해 보려고 한다.
회사 생활
우리 팀은 인사 솔루션 개발에 사용되는 프레임워크를 개발한다. 그렇기 때문에 우리 팀의 역할은 팀에서 만든 프레임워크를 사용하는 개발자들이 편하게 개발할 수 있도록 좋은 기능을 제공해 주는 것이다. 팀에서 하는 업무는 너무 마음에 들었다. 단순 반복 업무가 아닌, 그때그때 필요한 기능을 구현하고 내가 구현한 기능이 현재 운영 중인 서비스에 반영되었다. 물론, 신입 개발자에게는 어렵고 부담스러운 업무였던 것 같다. 하지만 좋은 선임 개발자분들이 많아서인지 큰 문제 없이 개발할 수 있었던 것 같다.
2022년에 나는 어떻게 하루하루를 보냈는가
2022년에 나는 신입 웹 개발자로서 모르는 내용을 배우는 것에 초점을 맞추었다. Spring MVC, Spring Data, Spring Security, Spring Batch와 같은 스프링 생태계에 대한 강의나 블로그를 보며, 무작정 새로운 지식을 머리에 주입했다. 그래서 나는 항상 시간이 부족했다. Java, 네트워크, 디자인패턴, 클린코드... 등등 백엔드 개발자로서 알아야 할 지식을 모두 알고 싶었다. 급한 마음에 깊이 없이 개념들만 어느 정도 이해되면 블로그에 간단히 정리한 뒤, 다음 공부해야 할 내용을 찾아 다시 공부하기 시작했다. 그래서인지 글을 쓰는 지금, 블로그에는 200개 정도의 글이 쌓였지만 만족스럽진 않다. 하지만, 한편으로는 뿌듯하다. 어쩌면 갓 취업한 신입 개발자가 할 수 있는 베스트는 아니지만 나쁘지 않은 노력이었던 것 같다. 덕분에 많은 코드를 접할 수 있었고, 백엔드 개발에 필요한 여러 키워드를 들을 수 있었다.
기억에 남는 업무
[Multi-DataSource]
우리의 솔루션을 사용하고 있는 고객사로부터, 로그인한 사용자마다 다른 DB를 바라보길 원한다는 요구사항을 받았다. '엇 이게 가능할까?' 라는 생각이 들었다. 애플리케이션이 구동되는 순간 DataSource의 커넥션 정보가 정해지는 거 아니야? 라는 의문이 있었다. 하지만 역시 스프링... 이 기능 또한 아주 심플하게 구현할 수 있도록 제공해 주고 있었다. 스프링에서는 이 기능을 AbstractRoutingDataSource를 사용하면 간단하게 구현하고 있다. 이 기능을 구현하면서 DataSource라는 빈이 어떠한 역할을 하는지 정리할 수 있었고, 하나의 애플리케이션에서 여러 개의 DataSource를 관리하는 설계를 할 기회였다.
[HikariCP 라이브러리 분석하기]
우리 팀은 자주는 아니지만 몇 개월에 한 번씩 자유 주제로 본인이 공유하고 싶은 내용을 발표하는 세미나를 진행한다. 나는 위에서 언급한 Multi-DataSoure를 구현하면서 HikariDataSource에 대해서 가볍게 공부했지만, HikariCP에서 어떤 식으로 Connection을 관리하는지 자세히 알지 못했다. 그래서 세미나 주제로 HikariCP가 커넥션풀을 관리하는 방법을 주제로 발표를 진행하였다. 발표를 준비하는 과정에서 HikariCP 라이브러리를 수십번 디버깅했다. 이렇게 한 줄씩 정리해 가면 라이브러리를 까본 경험은 처음이었다. 정말 재미있었고, 팀원분들도 관심을 가져주셔서 너무 기뻤다.
[Spring Data MongoDB로 QueryDSL 기능 구현하기]
사내에 우리가 만든 프레임워크에 대한 관심이 높아지면서, 몇몇 팀으로부터 프레임워크 적용 요청이 들어왔다. 문제는 RDBMS를 사용하지 않고 MongoDB만을 사용하는 팀들에게도 지원해 줘야 한다는 점이었다. (작은 규모의 솔루션이라 RDB까지 구축하긴 힘들다고 한다..) 그래서 기존 RDBMS로 짜여진 로직을 어떻게 하면 MongoDB로 전환할 수 있을지를 고민하던 중 MongoDB Aggregation이라는 것을 알게 되었고, 이를 Spring Data MongoDB를 사용해서 구현할 수 있었다. 나는 최대한 쉽게 QueryDSL-JPA로 짜인 코드를 Spring Data MongoDB로 전환할 수 있는 설계 방안을 제시하였고, 무사히 150개가 넘는 테이블에 대한 로직들을 성공적으로 전환할 수 있었다.
[DB-Migration]
솔루션 초기 구축 시, DB 세팅을 수동으로 진행하였다. 테이블은 JPA에서 제공해 주는 ddl-auto 기능으로 생성하였고, 초기 데이터는 덤프 파일을 떠서 세팅했다. 솔루션이 늘어남에 따라 매번 이런 식으로 데이터를 세팅해 주는 것은 상당히 오랜 시간과 비용이 들었다. 여기서 문제는 ddl-auto로 테이블을 생성하게 되면, 칼럼의 순서도 일정하지 않고, 칼럼코멘트도 누락되었다. 인사 시스템에서 이러한 점들은 설계자분들에게 큰 불편함을 주었다. 또한, 데이터베이스 벤더가 다르면, 덤프 파일로 데이터를 이관하는 것도 쉬운 작업이 아니었다. 그래서 나는 이러한 문제점들을 해결할 수 있는 DB-Migration 기능을 개발하였다. 이 기능 덕분에 클릭 한 번에 원하는 테이블을 있는 그대로 생성할 수 있었고 원하는 테이블의 데이터를 벤더에 상관없이 이관할 수 있었다. 이제 우리 팀의 솔루션을 테스트해 보고 싶다는 고객들에게 클릭 한 번으로 테이블과 데이터를 세팅해 줄 수 있게 되었다.
[Kubernetes 입문]
우리 팀은 따로 Devops 팀과 협력하고 있는 구조가 아니다. 그렇기 때문에 팀 내에서 직접 파이프라인을 구성하고, Kubernetes를 통해서 애플리케이션을 배포하고 운영한다. 팀에 적응하고 작년 중순부터 Devops 업무에 참여하였다. 너무 감사하게도 선임 개발자분들이 자세히 설명해 주셨고, 나 또한 열심히 배워서 이제는 어느 정도 Kubernetes를 다룰 수 있게 되었다. 또한, 팀 선임의 권유로 CKAD(Certified Kubernetes Application) 라는 시험이 있는 것을 알게 되었고, 자격증을 취득할 수 있었다. 실무에서 Kubernetes를 사용하고 있어서 CKAD는 비교적 쉽게 취득할 수 있었다. 기회가 된다면 내년에는 CKA, CKS도 따볼 생각이다.
[Spring Batch 도입]
우리 솔루션을 사용하는 회사마다 스키마와 데이터 형태가 달랐다. 그렇기 때문에 우리의 솔루션을 도입하기 위해서는 우리의 솔루션에 맞게 데이터를 마이그레이션 하는 작업이 필요하다. 이런 프로세스를 보통 ETL(Extract, Transform, Load)라고 한다. 나는 Spring Batch가 ETL 프로세스를 처리하는데 매우 좋은 조건들을 가지고 있다는 것을 알고 있었다. 하지만, 항상 새로운 기술을 도입하기 위해서는 명분이 필요하다. 그래서 나는 Spring Batch 공식 문서를 3번 이상 정독하고, Spring Batch의 특징과 장점, 그리고 도입했을 얻을 수 있는 기대효과에 대해서 팀원분들에게 1시간가량의 발표를 진행했다. 그 결과 Spring Batch를 도입할 수 있었고, 데이터 마이그레이션 기능을 아주 효율적으로 구현할 수 있었다. 내년에는 기존의 구현된 배치 작업을 Spring Batch로 전환해 볼 생각이다.
2023년의 계획
[RDBMS 공부]
작년에 나는 스프링 관련 공부에만 집중했던 것 같다. 하지만, 정작 가장 중요한 RDBMS 공부에 소홀했던 것 같다. 아무리 Spring JPA 공부를 열심히 한다고 해도 DB를 잘 알지 못한다면, 애플리케이션이 비효율적으로 동작할 가능성이 있다고 생각한다. 그래서 올해에는 RDBMS 공부를 집중적으로 해볼 생각이다. 특히, 팀에서 사용하는 PostgreSQL 위주로 공부할 계획이다.
[Kubernetes 공부]
Kubernetes 공부도 좀 더 하고 싶다. k8s를 공부하고 실무에서 사용해 보기 전까지 나는 k8s는 Devops 팀의 롤이라고 생각했다. 하지만 k8s를 공부하고 사용해 보니 생각이 바뀌었다. Kubernetes에서 애플리케이션을 배포하기 위해서는 여러 개의. yaml 파일들을 작성해야 하고, 이는 애플리케이션을 개발한 개발자가 가장 잘 작성할 수 있다. 또한, 로그를 모니터링하고 장애에 즉각적으로 대응하고 부하가 몰렸을 때 스케일 아웃하는 등 애플리케이션을 관리하는 것도 백엔드 개발자의 몫인 것 같다. 그래서인지 Kubernetes를 좀 더 깊게 해보고 싶다는 생각이 들었다. 또한 Kubernetes를 공부하는 과정에서 네트워크, 운영체제와 같은 CS 지식을 같이 배울 수 있는 것 같다. 그래서인지 Kubernetes를 공부하면 성취감이 높은 것은 같다..ㅎㅎ
[블로그]
작년에는 새로 알게 된 내용들을 나열하는 식으로 블로그를 작성했던 것 같다. 하지만 올해에는 실무에서 내가 겪었던 내용과 꼭 기억하고 공유하고 싶은 내용만 작성할 생각이다. 그리고 내가 배우고 느낀 것들을 주변 동료들과 공유하고 기회가 된다면 발표도 해봤으면 좋겠다.
[업무에 대한 이해]
올해 2023년에는 6개월가량 외부 프로젝트에 투입될 예정이다. 이번 프로젝트에 투입하면 우리 솔루션을 사용하는 인사시스템의 인사업무에 대해서도 관심 갖고 공부해 볼 생각이다. 개발자에게 있어서 개발을 잘하는 것도 물론 중요하지만, 업무를 이해하는 능력도 개발 못지않게 중요하다고 생각하기 때문이다.
느낀 점
이 회고록을 쓰면서 작년에 내가 작성했던 회고록을 읽어보았다. 1년 전의 회고였지만 그 당시 내가 느꼈던 감정들이 생생하게 기억난다. 그 당시 나는 회사에 취업한 지 얼마 되지 않았고, 개발자라는 직업이 너무 마음에 들었다. 회사 일이 재미있었고 주변 팀 분들이 너무 좋았다. 공부하고 싶은 것들이 많았고, 개발을 정말 잘하고 싶었다. 글을 쓰는 지금, 작년의 마음가짐과 전혀 다르지 않다. 다만, 차이가 있다면 불안함이 있다. 내가 효율적으로 개발 공부를 하고 있는 걸까? 라는 의문이 든다. 하지만 내가 내린 결론은 딱 한 가지다. 현재에 집중하자. 현재 내가 개발하고 있는 시스템, 사용하고 있는 기술, 개발 환경 그리고 내가 맡은 업무, 이 모든 게 현재 트렌드에 맞지 않거나 조금 뒤처져 있다고 하더라도 현재 위치에서 더 좋은 설계와 더 나은 개발에 초점을 맞추고, 찾아오는 문제 해결에 집중하는 것만큼 값진 것은 없다고 생각한다.