[2022 회고] 올해 나는 개발자로써 무엇을 했을까

안녕하세요. 이번 글에서는 2022년에 진행한 내용을 돌아보는 시간을 가지고, 지난 1년동안 무슨 성과를 가졌는지 고민해보는 시간을 가져보려 합니다.

 

0. 인트로

저는 회사에서 주로 회의시간에 회의록을 작성하고 있습니다. 그리고 실제로 회의 때 나온 내용들을 토대로 개발을 어떻게 할지 기획을 짜고 이렇게 작성한 글들을 제 개인 노션으로 옮겨적는 일을 하고 있습니다. 이렇게 옮겨 적게 되면 뭔가 실행하기까지의 과정은 느리지만 코드 뿐만 아닌 전체 틀을 볼 수 있는 안목이 생기고, 코드의 양이 많아지고 개발하는 프로세스가 어려워지더라도 이전에 작성해둔 가이드 문서를 보았을 때 보다 쉽게 작성할 수 있지 않을까 했습니다. 

물론 글로 옮겨 적는 것이 불필요하고 이런 행동들과 습관들이 급하게 개발하여야 하는 경우는 유용하지 않을 수도 있습니다. 급하게 먼저 개발을 해서 배포해야하는 버그를 수정해야하는 상황이 올 때는 먼저 조치한 후 후작성을 진행하는 것이 일반적이고, 서비스적인 부분에서 개선해야하는 경우는 위와 같이 진행하고 있습니다.

그래서 그런지 제가 어느 때에 어떤 개발을 했는지 보다 명확하게 확인할 수 있었습니다. 

실제로 작성한 회의록과 기록들

 

1. 회사 배치 시스템 구성과 고도화

저는 스타트업 회사에서 서버 개발자의 포지션으로 근무하고 있습니다. 근속연수는 2년이 되었지만 아직까지 배치 프로세스가 갖춰지지 않고 웹훅정도로 알림을 보내는 라이트한 스케줄러만 사용하고 있었습니다. 

근데, 어느덧 이런 배치 시스템이 도입이 되어야할 시기가 왔습니다. 지속적으로 웹 크롤링으로 받아온 데이터들의 양이 꽤나 많고, 정량의 데이터를 가공 및 처리해야하고 24시간을 돌려야 겨우 가능한 시스템을 구축할 때였습니다. 그래서 기존의 프로젝트와 다르게 새로운 배치 프로젝트를 만들고, 구성하는 작업을 병행하였습니다. 

 

1-1. Spring Batch Project 생성

배치 프로젝트를 생성하고 이런 구성을 하면서 여러 블로그들에서 알게된 내용들을 배치 구성에 성공하며 하나씩 적었던 것 같습니다. 없는 프로젝트에서 새로운 프로젝틀르 구성하고, 그에 맞는 프로토타입과 우리 회사의 인력풀에 맞는 배치 프로젝트를 개발하느라 하루 근무하는 시간 내내 시간가는 줄 모르고 세팅했던 것 같습니다. 

Spring Batch에 대한 레퍼런스는 꽤나 많았습니다. 제가 개발한 내용 중에 일부 필요한 내용은 작년에도 있었지만, 올해에는 기존에는 제가 이해하고 있지 못했던 Spring Batch 만의 특성을 기준으로 서치를 하고 그걸 실제로 내가 개발하고 있는 프로젝트에 입히는 작업을 더 많이 병행하였습니다. 

아래 글은 Job과 Step이라는 배치의 기준 단위를 처리하는 방법에 대해 더 적어본 글입니다. 이 글 내에는 제가 어디에서 이런 내용을 참조했는지 적어보았고, 이를 통해 알게된 내용을 적었습니다.

https://abbo.tistory.com/267

Job & Step 병렬 처리 하기

 

1-2. 배치 스케줄 조율

24시간 수행되고 있는 배치 프로그램이지만 특정 시간대에 맞춰서 작동하는 배치를 돌려야 하는 경우도 있었습니다. 예를 들어, 하루에 한 번만 돌아도 되는 배치이지만 사람들의 활동량이 적은 새벽 3시에 돌아야 하는 시스템이라던지, 1시간마다 1번만 체크해도 시스템의 운영에 문제가 없는 배치 프로그램이라던지에 대한 개발건입니다. 

그래서 저는 배치의 스케줄링에 속하는 크론식에 대해 조금 더 공부해보았고, 이런 내용을 회고하였습니다. 비록 작년에 작성한 글이지만 올해 한 번 업데이트를 한 것 같아요.

https://abbo.tistory.com/195

Batch 프로그램과 스케줄러

 

1-3. 배치 테스트 

Spring Batch 특성상 배치 프로그램이 기동되면 여기에서 전체가 다 수행되다보니, 디버그로 잡는다고 해도 다른 스케줄러가 먼저 돌아버리게 되는 특성상 테스트를 하는 것이 가장 어려웠던 부분중에 하나였습니다. 그래서 이런 배치중에 특정 Job만 실행시키고자 할 때의 방법을 더 찾아보고, 이렇게 수행해보았을 때 테스트를 하는 것과 한 싸이클만 돌릴 수 있는 방법에 대해 연구 및 서치해보게 되었습니다. 아래의 글은 이와 관련된 내용을 정리해보았습니다.

https://abbo.tistory.com/269

특정 잡만 수행하고 싶을 때

 

---

 

2. Docker Image 의 활용 + Maven 에서 Gradle 전환

2-1. ECR 시스템의 도입

저를 포함한 대다수의 개발자분들이 신기술을 좋아합니다. 그 중에서도 손에 꼽고자 하는 것은 Docker Image 배포 시스템을 서버 팀원분들과 같이 구성해보고, 이를 스터디한 내용일 것입니다. 

기존에 우리는 Java로 만들어진 .jar 파일을 정적으로 배포하는 시스템을 구성하고 있었습니다. 그래서 Jenkins를 사용할 때 Jenkins Server 내에서 .jar 를 빌드시키고 생성된 파일을 다른 서버에서 구동시킬 수 있도록 쉘 스크립트 파일을 주로 실행해주는 컨테이너의 역할을 많이 했었습니다. 

그런데 이런 방법은 이전 회사 및 다른 곳에서도 많이 사용하는 흔히 전형적인 방법이었습니다. ftp를 활용하여 jar를 옮기고 그런 리소스를 온전히 서버에서 처리하는 것은 소스 한줄만 변경이 되었는데도, 전체 통파일이 올라가야하는 것이 상당히 비효율적이라고 느꼈습니다. 이런 부분을 개선하기 위해서 3가지의 방법론이 나왔습니다.

 

a. Kubernetes(K8S)

쿠버네티스를 사용하는 것은 사실 서버의 관리의 용이성때문이기도 하지만, 배포의 용이성을 위하여 사용하기도 합니다. 기본적으로 Docker 를 사용하기 때문에 쿠버네티스를 도입하는 것은 굉장히 용이해보였습니다. 

장점: 위에서 얘기한 바와 같이 배포 및 서버 관리가 쉬워집니다. 젠킨스 서버를 중심으로 다른 서버와 브릿지로 연결하여 모든 내용을 실시간으로 전달받을 수 있는 시스템을 구성해두면 앞으로 서비스를 확장하는 입장에서도 정말 쉬워집니다.

단점: 인원 대비 투입할 수 있는 리소스가 한정적이었습니다. 그 때 당시만 해도 서버팀의 인원은 5명이었고, 내부 시스템을 고도화하는데도 필요한 인력이 많았기 때문에 쿠버네티스 세팅에 인원을 배치할 수 있는 여력의 한계가 있었습니다. 그리고 쿠버네티스를 구성하고 테스트하는 것도 운영중인 환경에서 도입하기는 실상 쉽지 않은 것이 현실적이었습니다. 

단점에서 오는 리스크가 너무 컸기 때문에 쿠버네티스 환경 설정은 우선 보류하기로 결정하였습니다.

 

b. AWS EKS

AWS에서 제공하는 Elastic Kubernetes Service 를 활용해보는 것도 의견으로 나오게 되었습니다. 이렇게 되면 a번에서 얘기한 쿠버네티스 세팅을 젠킨스 서버 내에서 하지 않아도, AWS에서 자동적으로 스케일링을 조절해주고 서버간의 커넥션을 연결할 수 있는 시스템을 활용하는 것도 좋아보이는 방법이었습니다. 

장점: 세팅이 쉽습니다. 무엇보다도 1에서 인원들이 지속적으로 투입되어야 하는 인력 낭비를 방지할 수 있습니다. 

단점: 인력 낭비를 막는 대신 그만큼의 비용이 발생한다. 그리고 확장시마다 비용적인 손실이 많이 생긴다. 

우리 회사가 스타트업이고 아직 많은 서비스를 도입하지 않은 입장이기 때문에, 그리고 비용적으로 부담되는 EKS를 사용하는 것은 너무 확대된 모델이 아니기 때문에 비효율적이라고 느꼈습니다. 구성은 쉽지만 쉬운 만큼 돈으로 떼워야한다는 느낌이 강했달까요..? 그렇기 때문에 EKS 도입은 보류로 결정하였습니다.

 

c. AWS ECR 

지금 선택하여 운영중인 모델입니다. AWS에서 제공하는 EKS 뿐 아니라 ECR 이라는 다른 서비스도 운영중이었고, 이는 Docker에 대한 이해만 있다면 시간을 할애하여 도입하여도 충분한 모델이었습니다. 우선 이러한 부분이 메리트로 느껴지게 되었고, 팀원들간 의견이 모아지게 되어 바로 도입에 착수하게 되었습니다.

장점: 세팅이 쉽고 비용적으로 적게 발생합니다. 솔직히 이 시스템을 왜 도입하지 않았는지 의문이었습니다. 

단점: Docker Image, Container 에 대한 이해가 필요하고 배포대상 서버의 설정도 같이 진행해주어야 합니다. 사실 이런 부분을 감수하고자 쿠버네티스와 EKS를 사용하는 것이긴 합니다.

이런 단점을 극복하고, 또 위에서 이미 보류로 넘어왔기 때문에 다른 차선책을 찾는 것보다 이렇게 배포하는 방법이 효율적이라고 생각하였고, 실제로 빠르게 적응되었습니다. 적응하기 까지에는 약 3일의 시간이 소요된 것 같고, 현재는 블루그린 무중단 배포까지 도입되어 잘 운영중에 있습니다. 

제가 작성한 글 중에서는 ECR로 구성을 하면서 어떻게 세팅을 했는지 보다 상세히 기술한 문서가 있습니다. 

https://abbo.tistory.com/308

AWS의 DockerHub 인 ECR 에 대해 알아보자

https://abbo.tistory.com/311

ECR 사용해서 Jenkins 배포하기

 

---

 

2-2. Maven 에서 Gradle로 넘어오기

a. 기존에 Maven을 썼던 이유

Spring Framework 를 사용하면서 Gradle 이 없던 시절에 (이건 완전 옛날) Maven이 대세였던 시기가 있습니다. 지금도 물론 Maven을 많이 활용하고 있습니다. 확장 가치가 많이 높은 의존성 주입, 시스템의 환경 설정과 자바 버전 선택 등 여러 가지를 공용으로 사용할 수 있는 시스템 아키텍쳐중에 하나이기 때문입니다. 

그리고 Maven의 장점 중에 하나는 오래 사용하다 보니 레퍼런스가 정말 많다는 것입니다. Maven을 쓰다가 Gradle 로 넘어가게 되면서 빌드 방식도 변경되고, 패키지하는 방법과 디렉터리도 달라지게 되었습니다.

이전에 제가 작성한 Maven vs Gradle의 비교 글도 존재합니다. 

https://abbo.tistory.com/3

Maven vs Gradle

 

b. Gradle로 이전한 이유와 개선한 과정

Gradle로 넘어간 특별한 이유는 없었습니다. 그저 마이그레이션하고 다른 것을 탐구하는 것이 재밌고, 또 회사 직원분들도 성향이 비슷하여 배우는 것을 좋아하고 즐기는 분들로 구성이 되어있어서 선택하게 된 것 같습니다. 하지만 Gradle로 넘어간 후에 리스크가 발생한 것은 분명히 있었습니다.

우리 회사의 프로젝트는 DDD(도메인 주도 설계) 방식으로 아키텍처가 설계되어있기 때문에 domain의 패키지를 주 모듈로 삼아 다른 패키지를 서브모듈로 사용하고 있는 방식으로 구성되어 있습니다. 여기에서 다른 모듈에 상속구조를 주는 것이 pom.xml의 방식으로는 쉽게 구성되어 있었지만 build.gradle에서는 상속구조를 갖추는 것 또한 문제였기 때문에 이를 찾고 고안하고 개선해나가는데 꽤나 오랜 시간이 소요되었습니다. 

2차적으로 봉착한 문제는 중복으로 사용하는 의존성이 서브 모듈에 너무 많다는 것이었습니다. 이런 중복을 배제하기 위해서 계속 빌드 및 테스트, 정상 빌드 후 문제점이 없는지 이슈 체크를 반복하였고 최적화작업을 진행하였습니다. 이 과정은 약 1주일정도 병행하였으며 사이드 이펙트가 있을 확률을 염두하여 깃플로우와 다른 방식으로 브랜치를 새롭게 생성하여 해당 브랜치에서만 작업을 진행하였습니다. 

 

c. 이전 후 결과

먼저 금액적으로 지출한 것은 0입니다. 하지만 인력적인 리소스를 소모한 부분은 1주일 정도입니다. 

그리고 무엇보다도 향상성이 있는 것은 빌드 속도면에서 개선이 있었습니다. 이전에 캡쳐를 해둔 자료는 존재하지 않아서 가시적으로 보여드리기는 어렵지만, Maven platform 에서 Gradle platform 으로 이전하게 되면서 빌드 속도는 20%정도 빨라지게 되었습니다. 

• Maven : build complete 까지 약 2분 (IntelliJ 2022.02 빌드 기준), 1분 40초 (M1 Macbook iTerm2 기준)
• Gradle : build complete 까지 약 1분 40초 (IntelliJ 2022.02 빌드 기준), 1분 30초 (M1 Macbook iTerm2 기준)
• 실행 기준 : https://abbo.tistory.com/138

IntelliJ를 활용하여 빌드한 프로그램의 war, jar 생성하기

 

빌드 속도가 개선이 되는 부분을 체크하고 왜 빨라졌는지 알기 위해서는 플랫폼별 아키텍처를 공부해봐야 알지 않을까 합니다. 제 예상으로는 인텔리제이에서 시간이 경감되는 것은 인텔리제이도 자바로 만들어졌기 때문에 Gradle 기반으로 구성된 플랫폼의 호환성이 더 우월하지 않을까 싶습니다. (실제로 위의 글에서는 Maven 보다 Gradle 이 빌드 속도 100배 빠르다고 써있는데, 이는 POJO 프로젝트의 경우이지 않을까 합니다.)

이 부분이 얼마나 큰 생산성을 나타내는 것인지 개발자분들은 이해하실 수도 있습니다. 빌드 속도가 빨라지면서 오는 이점은 아래에 간략하게 적어두었습니다.

• 컴파일 속도가 빨라진다.
• 테스트 주도 개발방법(TDD) 속도가 빨라진다.
• 배포하면서 Image를 만드는 속도가 빨라진다. -> 빠른 배포로 핫픽스 배포에서 우선권을 가진다.

 

---

 

3. 직원 채용과 면접관 참여

기존에 서버 개발자를 포함한 개발팀의 인력은 6명이었습니다. 지금까지 수많은 면접에 면접관으로 참여하여 인재 채용을 하면서, 제가 인재를 채용할 떄 중요하게 여기는 부분과 제가 생각하는 개발자의 덕목에 대해서 깊게 공부했던 것 같습니다. 그렇기 때문에 가장 먼저 이러한 기회를 주신 회사 임원분들에게 먼저 감사를 드리는 바입니다. 

면접보신 분들의 피드백을 위해 따로 리스트업해두었어요

 

3-1. 면접자와 면접 일정 맞추고 진행하기

아무래도 인사적인 부분은 개발과는 너무 다르게도 일정을 잡아도 변경이 되거나 취소가 되는 경우도 비지기수였습니다. 그리고 일부 지원자들은 면접 일정을 잡아두고 면접 이전에 따로 연락이 없이 노쇼(면접 장소에 출석하지 않는..)인 경우도 종종 있어서, 발목을 잡은 케이스도 종종 있었습니다. 심지어 사무실을 이전하면서 이전 주소가 지도상이나 도메인 페이지에 남아있게 되어 (업데이트를 하지 못하여) 구 주소의 근무지로 면접을 보러 가신 약간 당황스러운 일도 종종 발생하였습니다. 

물론 감사하게도 많은 지원자분들께서 면접을 응해주셨고, 긍정적인 피드백을 주시거나 그렇지 않아도 면접에 응하시면서 각자 어떤 스타일로 개발에 임하고, 개발자들은 퇴근 후 여가시간에 어떻게 쉬는지 이야기를 들을 수 있었던 의미있는 시간이 되었습니다. 

그리고 합격 절차에 권한을 가지게 되면서 제가 이전에 같이 면접보았던 분들과 얘기를 나누고 '이번에 면접보게 된 사람 특징은 이런 점인데, 어떤 기술 스택이 있고 어느 회사에서 경험했는지(경력자분이실때) 이런 부분이 마음에 들어서 면접을 진행하게 되었고, 결과가 이렇게 나올 것 같다.'라고 간접적으로 직원분들께 전달하면서 저를 돌아보았을 때 어떤 부분이 부족하고 필요한지도 다시 돌아보게 되는 계기가 되었습니다.

면접자 분들 중에서 저보다도 더 열정적인 성향을 지니셔서 같이 일하게 되면 어떤 부분들이 우리 회사 및 우리 팀에 유리한 점으로 작용하는지, 외부에서 보았을 때의 우리 회사가 어떤 이미지를 가지고 있는지 직접적으로 전달받게 되면서 새롭게 느낀 점들도 많았습니다. 피드백을 직접 받아보니 회사가 성장하는데 더 기여할 부분과 나중에 진행해야 할 것들과 같은 우선순위를 조율하는데도 탁월하였습니다.

 

3-2. 회사의 프로세스에 참여하기

개발팀 직원들을 채용하면서 회사 성장에 기여한 것도 나름 스스로 뿌듯하다고 느낀 부분 중 하나입니다. 회사가 규모가 커지는 것이 같은 시간 대비 더 많은 제품을 출시할 수 있고, 유지보수와 고도화를 함에 있어서도 인원이 필요한 부분이 분명 존재하다보니 규모가 작은 경우 이런 일을 동시에 병행하기 어렵다는 문제점이 개발팀의 인원이 적었을 때 느끼는 가장 큰 부담이었습니다. 

직원 수가 늘게 되면서 다른 직원들이 회사에 적응하고 팀 빌딩이 잘 되도록 그리고 하나의 목표를 향해 공동으로 작업을 진행하면서 일을 효율적으로 처리하고, 소통도 더 원활하게 되기 위해 많은 고민을 했습니다. 

그 중에서 가장 대표적으로 개편된 것은 Jira 소프트웨어를 쓰더라도 효율적으로 쓰는 것과, 많은 개발자 및 개발팀이 주력인 회사에서 사용하는 메신저인 Slack 을 사용하게 된 것이 큰 변화의 시작이었습니다. 배치 프로그램을 도입하고 Jira에 등록되는 이슈들이 전환되는 상태들을 주기적으로 전달받아보면서 자동화의 중요성과 개발팀의 존재 이유에 대해 새삼 느끼게 된 계기가 되었습니다. 

물론 완벽하게 마이그레이션이 되지는 않았고, 연말이 된 현재도 꾸준하게 진행하고 있는 부분입니다. 심지어 서비스가 많이 확장되고 그만큼 날라오는 웹훅의 갯수도 많아지면서 채널도 분산시키고 있고, 사내 직원 및 고객들이 요청하는 작업도 같이 응대를 진행하고 있다보니 이런 과제는 개발자로서 숙명같은 느낌입니다. 그치만 이렇게 일하는 것이 재밌고, 마치게 되었을 때 뿌듯한 점은 분명합니다. 

 

3-3. 직원 채용 후

직원을 채용한 뒤에는 더 많은 일들이 기다리고 있었습니다. 관리를 한다는 것은 직원들이 회사에 잘 적응하기 위한 '온보딩 프로세스', 더 좋은 개발 문화를 만들기 위한 '노력과 끈기', 중도에 직원들이 지쳐서 나가지 않도록 해줄 수 있는 '믿음'을 지속적으로 주어야 했습니다. 면접관으로 참가했으니 그 직원이 들어오게 된 창구는 결국 저이기 때문에 그런 책임감이 더 무겁게 느껴지게 되었습니다. 

그래서 아이디어를 내게 된 것은 간담회처럼 1:1 면담을 진행하고, 정기적으로 팀 빌딩을 위해서 월간 회의를 진행하는 것, 코로나로 인해 침체되어 있던 회식문화(제일 요청이 많았습니다)가 대표적이었습니다. 사기 증진을 위해 모두 다 필요한 것들이었고, 사실 생각하지 못하고 계속 일만 하다가는 지치기 일쑤였기 때문에 이런 불을 끄기 위한 방책들이 시급하게 느껴졌습니다. 

1:1면담을 진행하게 되면서 직원들이 평소에 어떤 생각을 가지고 회사에 출퇴근하고, 현재 개인대 회사로 느끼고 있는 것들에 대한 해소 방안, 만나서 소통하지 못하며 발생하는 문제점들에 대해 알게 되었습니다. 이를 개선하기 위해서 많은 생각을 하고 고민하게 되면서 개인으로서도 그리고 회사로서도 더 성장하게 되는 좋은 계기가 되었습니다. 

 

3-4. 그 외

가장 크게 다가온 것은 우선 팀장이기 보다는 팀원으로 남고 싶은 저였기 때문에 선택한 것에 대해 크게 후회가 없었습니다. 관련한 내용은 아래의 글에 적어두었습니다. 둘 다 이점으로 다가오는 것들이 더 많았지만, 제가 판단하였고 생각해서 실행에 옮긴 것중 크다고 생각합니다. 

https://abbo.tistory.com/361

팀장을 그만두게 되었습니다

 

그리고 신입 직원분들이 여러 회사에서 진행하는 면접에 참여하면서 면접 경험을 늘리고 회사를 보는 안목을 늘리는 것이 하나의 좋은 점으로 작용할 것입니다. 회사의 입장에서도 여러 방면에서 열심히 일하고 있는 또는 열정을 가지고 있는 직원들과 이야기를 나누면서 저 또한 면접관으로 즐겁게 일하지 않았나 싶습니다. 지금은 상황이 달라졌기에 면접에 참여하고 있지 않지만, 그 때의 기억은 저를 다시 돌아보게 되는 기억 중 하나로 남았습니다.

 

 

2022년도 다사다난하게 지나가느라 시간이 금방 흘러간 것 같습니다. 앞으로도 개발자로서 개발할 내용들과 아키텍처, 프로세스들에 대해 꾸준히 고민하는 것도 좋고 실행에 옮기는 것도 좋지만, 과거의 내가 존재하기에 현재 제가 존재하는 이유인 것처럼 더 돌아볼 수 있는 여유를 가지며 즐겁게 일했으면 좋겠다는 생각을 했습니다.

긴 글 읽어주셔서 감사합니다 :) 다들 새해에는 무탈하고 건강한 한 해가 되길 바라겠습니다.