[회고] 2021년을 돌아보며

https://unsplash.com/photos/cniHhgdUjPo

2021년 마지막 날, 다른 개발자들의 회고 릴레이에 참여하여 나도 올해의 나를 다시 되돌아보고자 한다.

인생 회고는 몇 주전 정리를 했으니, 올해의 개발과 성장에 초점을 맞춰 글을 작성했다.

---

개발자로서의 첫 발을 내딛다

올해 1월, (돈을 받고 일하는) 개발자로서의 첫 발을 내딛었다. 11번가 이커머스 기업에서 백엔드 개발자로 취업하게 되었고, 일을 시작했다. 솔직히 말하면 최근 떠오르는 이커머스 기업들에 비해 눈에 띄지 않아 매력이 없어보일 수 있지만, 컨퍼런스의 영상들(MSA로의 전환, 스케일아웃 없이 순간 급증하는 주문 처리하기)들을 보며 ‘배울점들은 충분히 많겠다’라는 생각을 가지고 입사를 결정하게 됬다.

입사 전만 해도 나는 Node/Express 기반의 서버 개발을 하던 그리고 아키텍처, 클린코드 등을 거의 모르던 개발자였다. 하지만 회사의 경우 Java/Spring boot/Spring cloud 기반의 스택을 가지고 서버를 구성하고 있었기에 입사초기에는 신입 개발자 교육 및 개인 학습에 집중했다. 초기 몇 달은 퇴근 후에도 강의와 책을 보고, 사내 코드를 보며 학습에만 매진했다. 그러다보니 어렵게만 느껴졌던 Spring boot도 왜 사용하고 있는지 깨닫고, 어느새 익숙해져 Spring boot를 어느정도 능숙하게 다루고 있는 내 자신을 발견할 수 있었다. (Spring boot를 다루지 못하는 개발자를 뽑아 가르쳐주고 성장할 수 있는 기회를 만들어 준 회사, 팀 그리고 개발자 분들에게 정말 고맙다)

이렇게 개발자로서 첫 발을 내딛었다.

뭔가 개발자라는 직업을 가지게 되면 뭔가 새롭고 오묘한 느낌이 들 줄 알았는데, 별로 아무런? 특별한 느낌이 들지 않았다. 코로나로 인해 재택을 거의 1년간 해오고 있고 회사도 몇 번 출근한 적이 없어서 더 그렇게 느껴지는 것 같기도 하다. 하지만 배우고 깨달은 것은 정말 정말 많았다.

 

언어/프레임워크 말고 배운 것

개발언어와 프레임워크 말고도 배운 점이 많은데, 제일 크게 문서화 및 공유하기, 공식문서 읽기, 테스트 코드 작성하기 인 것 같다.

 

문서화 및 공유하기

입사 전에는 배우더라도 혼자 문서화를 해놓거나 문서화 없이 데모를 작성해 github에 올리는 정도로 학습을 마무리했었다. 하지만 회사에서는 학습을 하며 문서화를 자연스럽게 진행하고(그것도 공식문서처럼 깔끔하게) 그것을 팀 내 공유하며 지식 싱크를 맞춰나가고 있었다.

이 과정이 처음 배우기 시작한 나에겐 참 좋았는데, 보고 배우면서 나도 배운 것들을 정리하는 습관을 가지게 됬고, 내가 정리한 글을 읽을 팀원 내지 개발자 분들의 입장을 생각하며 이해할 수 있는 글을 적고자 노력했다. 그러다보니 어느새 공유된 글은 수십개가량 되었고, 작성한 위키도 많았다. 그 중 Java에서의 Proxy 설정 방법 이라는 글은 사내 기술 블로그에 올라가기도 했다. 좋은 결과를 보니 뿌듯해져서 요즘에도 무언갈 배우면 꾸준히 기록하며 공유하고 있다.

 

공식문서 읽기

공식문서를 읽어보는 습관을 들였다. 이전이었으면 새로운 부분에 대한 학습을 진행할 때 국내 블로그만 찾아 보곤했다. 하지만 모든 내용을 블로그에서 다루는 것도 아니며, 잘못된 정보 및 부분의 정보만 다루는 것도 많았다. 그러다보니 그런 것에만 의존하여 개발을 하다보면 정작 놓치는 부분이라던지, 설정 해주어야하는 것을 빼먹는다던지, 이전 버전 방식으로 개발하고 있는 등 여러 문제가 있었다. 마지막으로 배운 것을 공유할 때, 오피셜하지 않은 정보를 제공하며 공유하면 그 자료에 대해 확실한 보장을 하지 못했다 (대학 시절, 참고자료에 나무위키를 적는 느낌이랄까...)

이런 곳에서 실수를 거듭하며 공식문서를 읽기 시작했다. 이전까지는 공식문서에 대한 두려움이 있었다. 다 영어로 이루어져있고, 뭔가 (찐찐찐)개발자를 위한 문서라서 내가 이해할 수 있을까 하는 두려움 같은거 말이다. 근데 막상 읽어보니 그러지 않았다. 물론 오픈소스나 프로젝트마다 친절도나 이해도가 다르긴한데, 대부분 내용이 명확했고 기존 블로그 글보다 더 많은 것을 알 수 있었다. 또한 기술을 직접 개발한 곳에서 발행한 문서이기도 하니 99% 믿고 사용할 수 있었다. 1%의 불신이 느껴지면(문서가 잘못되었다고 생각이 들면) 그건 오픈소스 기여거리(안주거리 마냥...)이므로 더 좋아졌다.

 

Reactor Flux marble diagram... 이젠 이뻐 보인다...

특히 Kubernetes 공식문서, Reactor javadoc(marble diagram), Spring boot docs이 정말 잘 설명되어있고, 학습 및 개발할 때 도움이 많이 됬다. 역시 좋은 프로젝트일수록 많은 개발자들이 문서를 같이 만들어나가기도 하고, 많은 개발자들의 러닝 커브를 줄이기 위해 문서가 좋아지는 것 같다.

 

테스트 코드 작성하기

테스트 코드도 마찬가지다. 이전에는 테스트 코드니 TDD니 말로만/이론으로만 접했지 한번도 작성해보지 않았던 테스트 코드였기에 ‘이게 프로젝트에 진짜 도움이되나?’ 라는 생각이 있었다. 근데 테스트 코드의 힘은 기능 수정 및 추가에서 온다. 큰 프로젝트일수록 기능의 수정과 추가가 어떠한 사이드 이펙트를 발생시킬지 모른다. 그러한 불안감을 줄이는데 테스트 코드가 엄청난 역할을 한다는 것을 (올해가 되서야) 깨달았다.

PDD (Pray Driven Development) 멈춰

테스트 코드의 중요성을 알고부터는 기능 개발 시에 해당 기능에 대한 테스트 코드를 무조건 작성하려고 노력한다. 운이 좋게도 팀원 분들이 테스트 코드를 워낙 잘 작성하시고 유지하시기도 하고, 왠만한 프로젝트들에서 jacoco 등을 통해 coverage를 검사하고 있어 부족한 부분들에 대해 계속해서 구현해나가고 있다.

하지만 아직까지도 테스트 코드 짜는 것은 어려운 것 같다. 테스트 코드가 주 코드를 짜는 것보단 적으니 익숙해지기가 쉽지 않아서 그런 것 같다. 기능을 개발하더라도 한 6할은 테스트 코드 작성인 것 같기도 하다. 아직도 ‘이렇게 테스트 코드를 작성하는 것이 정말 도움이 될까?’, ‘내가 검증하고 싶은 것은 무엇이지?’ 라는 고민을 거듭하며 작성해나가고 있다. 내년에는 더 자연스럽게 테스트 시나리오를 생각하고 코드를 작성할 수 있도록 노력해야겠다.

(사내 개발이 아니면 테스트 코드를 안짜는 나를 반성하자 😂 )

 

첫 프로젝트

‘첫 프로젝트’라는 이름이 너무 거창한 것 같지만, 사내에서 처음 맡았던 업무는 팀 내 활용되는 슬랙봇 개발이었다. 플랫폼 팀에 들어가다보니 직접적인 서비스보단 사내 팀들을 위한 개발을 많이했는데, 그런 작업 중 하나였다. Slack API를 활용하여 Bot을 개발하고 이를 자동화해서 업무 생산성을 향상시키는 것이 목표였는데, 처음 업무를 들었을 땐 ‘뭐, 어렵겠어?’ 라는 생각이 먼저 들었다. 그 이유는 이전에 Slack bot을 Python으로 개발한 경험이 있기 때문이다.

하지만 기술 스택이 문제였다. Spring webflux(Reactor)였기 때문이다. Java도 다시 학습한지 얼마되지 않은 상황에 리액터까지 학습하려니 정말 힘들었다. ‘Reactive 란 무엇인가’부터 ‘subscribe, block 을 하지 않으면 결과가 안나온다고?’ 같은 생각을 가지며 스트레스를 받아가며 학습했던게 기억이 난다. 이 당시 새로운 기술에 대해 학습하는 법은 책과 인터넷 강의 밖에 몰랐던 터라 관련된 강의들을 찾아다녔었는데 괜찮은 것이 없었고, 결국 외국 블로그와 공식문서를 보고 학습하게 되었다.

이게 참 많은 도움이 되었는데, Reactor는 마블 다이어그램을 보며 메서드들의 의미와 흐름을 파악하는게 핵심적이었고 그게 공식문서나 javadoc에 너무 잘 나와있었다. 또한 추후 새로운 기술을 공부할 때 국내 자료보단 공식문서와 외국 오피셜한 자료들을 찾아보며 학습하는 습관을 기르게 만들어주었다.

아무튼 이것도 몇 일 걸려가며 학습하고 구현해내는 걸로 잘 마무리 되는 줄 알았으나... , 다음 미션은 이걸 AWS Lambda (Serverless)로 서비스해보자는 Challenge가 주어졌다. 당시 Serverless에 대한 개념만 가지고 있던 나는 ‘아, 이거 그냥 옮기면 되는거 아닌가’하는 단순한 생각으로 Spring boot 기반의 프로젝트를 AWS Lambda로 실행시키기 위한 방법들을 찾아보았고, 이를 적용해나갔다. 하지만 문제는 옮기는 것이 아니었다. Cold start (Warm up 시간이 느린)문제였다.

 

https://levelup.gitconnected.com/aws-lambda-cold-start-language-comparisons-2019-edition- ️-1946d32a0244

Serverless/JVM 등의 구조로 인해 발생하는 이슈라고 보면 되는데 회고에서 이를 설명하기엔 너무 길고, 짧게 요약하면 Cold start 문제로 인해 Serverless가 요청을 받았을 때 응답을 주기까지 너무나 오랜 시간이 걸렸다. 슬랙봇이라하면 사용자의 요청에 따라 즉각적으로 답이 주어지며 소통을 할 수 있어야 했는데, 5~6초 가량의 딜레이가 발생했다. 이를 어떻게 해결할까에 대한 고민이 이어졌고, 해결방법은 GraalVM의 native image를 활용하는 것이었다. 이를 활용하는 과정에서 정말 많은 점들을 배울 수 있었는데, 이를 간략하게 정리하면 다음과 같다.

• GraalVM, native-image: 설명이 길어 잘 설명된 국내 유튜브 영상을 참고
• Spring boot 프로젝트 → Spring native 적용하기 (대안으로 quarkus, micronaut 프레임워크가 있다)
• AWS Lambda에서 native image를 사용하기: 로컬에서 Devcontainer를 통해 빌드

 

결국 이런 과정을 거쳐 native image로 빌드한 슬랙봇을 구성했고, 답장까지 총 6초 가량 걸리 던 것을 1초 내로 줄였다. 개발까진 이렇게 마무리되었고, 추후 유지보수 및 기능 추가를 위해 빌드/배포 관련하여 SAM 사용방법 등의 문서화를 작성하는 것으로 첫 프로젝트를 완료시켰다.

완료하는데까지 많은 시간이 걸렸고, 빌드를 실패할 때마다 그 원인을 찾아가는데 까지 많은 스트레스를 받았던 것 같다(버그를 만나면 언제나 그렇듯). 하지만 ‘문제는 언제나 답이 있다’라는 것을 다시 한번 배울 수 있었고, 새로운 것을 익혀나가는 방법과 AWS/Serverless/Spring webflux, native/devcontainer 등 다양한 기술들을 배울 수 있어서 좋았던 프로젝트였다.

 

Kubernetes와 함께한 한 해

Java/Spring도 올해 첫 시작을 했지만, Kubernetes(이하 k8s)도 올해 첫 시작을 했다. 중순 막바지부터 사내 도입을 위해 계속된 학습을 하고, 현재는 개발을 하며 끊임없이 학습하고 있다. 기존 컨테이너 환경도 아직 익숙하지 않았던 나였기에 docker/docker-compose를 학습하고 이어 k8s 구성요소/컴포넌트 등을 학습했다.

Spring native를 학습 및 도입할 때와 다르게 k8s는 워낙 많은 곳에서 사용되고 있었기에 학습할 수 있는 자료가 정말 많았다. 특히 공식문서와 공식 블로그(문서 내)가 정말 잘 작성되어져있었고, 한글화 된 부분도 많았다. 문서화를 위해 힘쓴 느낌이 딱 느껴졌고, 잘 된 오픈소스 일수록 문서화가 정말 중요하다는 것도 알 수 있었다. 추후 k8s 문서화에 컨트리뷰션 작업을 도전한 적이 있었는데, 그 컨트리뷰션 과정을 보며ㅋㅋㅋ 정말 문서화에 진심이구나, 정말 많은 사용자가 있는 오픈소스는 관리해야하는 요소들이 많으니깐 이렇게 이루어지는구나 싶었다. 만약 이러한 과정이 궁금하시다면 한번 컨트리뷰션을 도전해보세요...!

하.지.만 정말 공부할게 방대했다. 도입을 위해선 단순히 k8s 기본 컴포넌트만 학습해서는 안됬다.

진짜 고려해야 할 사항과 도입을 생각해봐야할 컴포넌트들이 속된 말로 뒤지게 많다.

 

위 그림에도 어느정도 나와있지만

• 매니징툴 (helm, kustomize, ...)
• 모니터링 (lens, kiali, k9s, grafana...)
• 로깅 (prometheus, fluentd, datadog, ...)
• CI/CD (Jenkins (k8s), ArgoCD, Jenkins X, ...)
• Service mesh (Istio, Envoy, ...)
• 개발 툴 (devcontainer, telepresence, devspace, ...)
• Operator와 Admission controller 개발 (OperatorSDK, java-operator-sdk, ...)
• 외부 여러 오퍼레이터 및 툴 (cert-manager , botkube, ...)

대략 이렇게 학습하고 데모를 작성해보며 사용해보았던 것 같다.

첫 도입이다보니 장단점을 가려서 다 사용해봐야했고, 팀원들과 나눠 사용해보고 조사하며 한 주마다 공유를 했던 것 같다. 이렇게 보면 정말 많이 사용을 해봤는데, 어떻게 했나 싶다. 혼자 했으면 막막할 수 있었어도 꾸준히 열심히 하시는 팀원들을 보면서 나도 동기부여 받으면서 열심히 했던 것 같다.

지금은 대략 어느정도 도입할 준비를 마치고 Operator, Admission controller 개발에 집중하고 있는데 k8s 환경을 이해하고 서버 개발을 진행하고 있다는 점에서 나 스스로 뿌듯하면서 재미있게 하고 있다. (그럼에도 아직도 배워야할 게 한가득이다. 위에서 말한 것은 데모 수준에서 학습한 것이기에 🥲)

 

MSA, Spring cloud, ...

Spring boot와 k8s 말고도 Spring cloud 기반의 MSA 아키텍처를 다루고 학습했다. MSA 내 컴포넌트들이 정말 많은데 학습할 때 도움이 됬던 점이 ‘왜 이 컴포넌트가 필요한 것인가’ 라는 생각을 먼저하는 것이었다. 즉, ‘문제 인식’에 따른 ‘필요성’을 생각해보는 것이 이해를 하는 데 큰 도움이 됬다.

예를 들어, Circuit breaker 에 대해 학습한다면 ‘왜 Circuit breaker가 필요할까?’를 생각해보는 것이다. MSA 구조에서 이게 없어진다고 생각하면 ‘한 서비스의 오류가 전파되어 전체 서비스가 먹통이 되는 문제가 발생할 수 있겠구나’ 같은 결론에 다다르게 되고 이 컴포넌트의 목적을 이해할 수 있게 된다. 그 다음 구현을 보거나 현재 서비스 되고 있는 아키텍처 상황을 보면 더 이해가 잘 되는 것 같다.

이것 말고도 신입이여서 그런지 배운게 수두룩 하지만 생략하겠다. 아무튼 작년 EC2에 서버 하나만 올리면 서비스가 끝나는 줄 알았던 아주 작고 작았던 나는 아직도 작지만 많은 것을 배우고 학습하고 흡수했던 한 해였다. ‘1년차’라기엔 아직 부족하고 부족하고 부족하지만, 그 부족함에 맞게 내년에도 배우는데 더 노력해야 겠다는 생각이 든다.

 

오픈소스 기여하기

올해는 오픈소스에 개발을 배우기 시작하고 제일 많이 했던 한 해인 것 같다 (제일 많이 했다고는 하지만 몇 개 안된다 😂). 사실 이전까지만 해도 오픈소스/프레임워크를 깊이 다뤄보지 않았기에 기여할 요소라던지, 이슈 작성 등 하지 못했다.

하지만 올해 많은 것을 배우기도 했고, 국내 자료가 없는 기술들의 데모를 작성해보며 온갖 오류를 만나면서 직접 이슈 및 기여를 해봐야겠다는 생각이 들었다. 또한 정말 정말 운이 좋게도 우리 팀 및 사내 분위기가 오픈소스에 기여하는 것을 매우 긍정적으로 봐주시기에 더 동기부여가 되었다.

직접 사용하고 있는 Resilience4j, Spring 에 기여를 했다는 것이 뿌듯하고, 추가적으로 다른 프로젝트에도 이슈라던지 사소한 기여를 할 수 있어서 좋았다. 하면 할수록 뿌듯해지는게 오픈소스 기여인 것 같다.

올해한 오픈소스 기여는 다음과 같은데, 관련된 내용을 추후 더 정리하려고 한다.

Resilience4j

• https://github.com/resilience4j/resilience4j/issues/1503
• https://github.com/resilience4j/resilience4j/pull/1504
• https://github.com/resilience4j/resilience4j/pull/1504

Telepresence

• https://github.com/telepresenceio/telepresence/issues/2124

Java-operator-sdk

• https://github.com/java-operator-sdk/java-operator-sdk/pull/645

Spring

• https://github.com/spring-projects/spring-framework/pull/27680

k9s

• https://github.com/derailed/k9s/issues/1349

kubernetes docs

• https://github.com/kubernetes/website/pull/30982

 

개발자들과 직접 소통하기

추가로 오픈소스를 사용해 개발을 하다가 공식문서 및 github issue에도 없는 문제를 만났거나 정말 어떠한 사항에 대해 궁금할 때가 있다. 사실 이전 같았으면 주변 개발자에게 물어보거나 그냥 포기했었다.

하지만 팀원들분들은 직접 해당 오픈소스를 만든 개발자에게 메일을 보내 물어보기도 하고, 관련 프로젝트 소통방(Slack, Gitter 등)에 들어가 질문하는 모습을 보며 존경스러웠고, 과거의 포기하던 내가 조금 부끄러웠다. 그 후론 나도 관련되어 아무리 찾아도 궁금한 사항에 대해 찾지 못했을 때 직접 채팅에 들어가 질문하고 있다.

그냥 단순히 보면 개발자들과 소통하고 질문하는건데, 이러한 과정이 그냥 스스로 뿌듯했다. 진짜 개발자인 것 같으면서도 ‘모르는 점을 결국 해결했다’ 이런 감정이랄까.

 

이외에도 그리고 마지막으로

이외에도 회사 업무를 제외하고 많은 개발자분들과 같이 책 및 공식문서 읽기 스터디에 참여하였고, Spring boot를 이용한 여러 프로젝트를 진행하기도 하였으며, 개발자 동아리에도 들어가 많은 사람들을 만난 해였다.

회사 내부에서만 배우는 것으로 만족하지 않고 더 배우려고 외부에서 많이 참여한 것이었는데, 그 과정속에서 ‘개발’이라는 것보다 좋은 사람들과 재미있는 프로젝트 및 스터디를 진행할 수 있었고, 그게 정말 좋았다. 오히려 그래서 더 성장했다고 생각한다.

사실 1년이란 개발과 커리어 말고도 내 인생에서 많은 일들이 일어났다. 사람 관계 속에서 인생에서 제일 큰 어려움을 겪었고, 그 속에서 내 자신을 더 알아가며 나에 대해 더 알게된 한 해이기도 하다. 참 힘든 날들이었지만, 값진 날들이었다.

정리하고 싶은 Context에만 좀 집중해서 작성하다보니 글이 전체적으로 특정 주제에만 집중된 것 같지만, 이렇게 라도 정리를 하고 글을 마치고자 한다. 참 많은 것을 배우고, 깨닫고, 알아간 한 해였다. 내년엔 더 재밌고, 행복하고, 좋은 일들만 가득한 한 해 였으면 좋겠다 :) 마지막으로 사람으로서, 개발자로서 더 성장한 한 해가 되길.