근황 보고

블로그 작성이 뜸했던 이유

기술 블로그 리뉴얼을 할 때도 이야기를 했었지만 9월부터 프로젝트로 한창 바빴었다.
그런데 그 때만 해도 10월까지만 바쁠 줄 알았는데... 아니었다 ^^;

무슨 일이 있었는지 간단 요약

자세한 내용을 이야기할 수는 없지만 9월부터 어떤 일이 있었는지 요약하자면 다음과 같다.

• 자사 솔루션을 모놀리식에서 MSA로 전환하는 장기 프로젝트에 참여
• 9월부터 12월 초까지는 장기 프로젝트 중 초반 일정을 진행
• 여러 개의 마이크로서비스 중에서 핵심 도메인 중 1개의 파트를 제외하고는 전부 담당
• 인프라도 홀로 담당

물론 억지로 떠맡은 일은 아니었고 내가 하고 싶어서 + 팀 내에서 나만 할 수 있는 일 이었기에 맡아서 했다.

회고

일정 관련
사실 프로젝트가 끝난 건 아니고 내년 말까지 진행되는 장기 프로젝트에서 초반 일정이 막 마감이 된 것이다.
다만 초반 일정 자체가 굉장히 타이트하게 잡혔기 때문에 팀원 모두가 고생을 한 것일 뿐... 일정이 타이트하게 잡힌 데에는 이유가 있긴 했지만 힘든 건 어쩔 수 없었다.

그나마 다행인 점? 위로가 되었던 점은 팀원들 모두가 무리한 일정임에도 불구하고 책임감을 가지고 서로 힘을 내며 프로젝트에 몰두했던 점이다. 소위 말해서 일하는 사람 힘 빠지게 분위기 흐리는 사람도 없었고, 사람 간의 불화도 없었다. 혹시라도 이런 일이 있었다면 일정 자체도 힘든데 사람 간의 일로도 스트레스를 받았을텐데 다행이었다.

다만 일정 관리가 제대로 되지 않는 점이 있었어서 (회사 도메인 상 PM을 외부에서 채용하기가 힘든 구조이고 PM 역할을 수행할 수 있는 부서 쪽 인원도 많이 바빠서... PM이 없는 상황) 이 부분에 대해 개선이 필요하다는 생각이 들었고 이전까지는 Notion이나 Github Projects로 일정을 관리하던 것을 Jira를 시범적으로 도입하여 운영을 하면서 개선해나가고 있다.

일정이 너무 타이트했고 변수도 많았기 때문에 미리 일정을 산출하는 것이 불가능한 상황이었기에 프로젝트 관리가 많이 어려웠지만 이어지는 다음 프로젝트부터는 일정 자체가 상대적으로 많이 여유로워졌기 때문에 앞으로는 일정 산출과 더불어 프로젝트 관리를 보다 철저히 진행하고자 한다.

MSA 관련
이번 장기 프로젝트의 최종 목표는 PHP 기반으로 구성된 자사 솔루션을 Java / Python 기반 MSA로 변경하는 것이다. 여기서 본인은 Java + Spring Cloud 기반 마이크로서비스 개발을 담당하였다. 참고한 서적은 다음과 같다.

• 도메인 주도 설계로 시작하는 마이크로서비스 개발
• 마이크로서비스 패턴

일단 도메인 별로 여러 개의 마이크로서비스로 분리를 하였지만 애초에 도메인 간의 커플링이 느슨했고 상호간에 발생하는 이벤트 역시 많지는 않아서 Saga Pattern 등의 구현 난이도가 복잡한 기술들을 사용하지는 않았다. (일부러 넣었다가는 오버 엔지니어링이 될 가능성이 높았다) 물론 필요할 경우 배워서 적용해야 하겠지만 이 부분을 제외하고는 크게 어려운 점은 없었다.

다만 시간이 급해서 헥사고날 아키텍처에 대한 충분한 학습이 이뤄지지 않았던 점은 아쉽다. 애초에 개발 공부를 Spring Data JPA로 시작을 했어서 그런지 트랜잭션 스크립트 패턴이 아닌 도메인 모델 형태로 개발하는 것에는 익숙했지만 포트 - 어댑터 형태는 아직도 모호한 점이 있다. (유스케이스도 그렇고)

어차피 이번 기간에 MSA 구조 관련해서 공부하고 개발한 사람이 본인 밖에 없어서 이어지는 프로젝트에서 다른 인원들에게 인수인계 / 교육하는 과정에서 다시 한 번 개념을 복습하고 이전 코드를 리팩토링해야할 것 같다.

인프라 관련
초반 프로젝트는 NHN Cloud 위에서 개발 환경이 구축되었으며 쿠버네티스는 NKS를 사용하였다.
취업 전에 올해 초에 국비교육으로 DevOps 과정을 3개월 정도 들었었는데 여기서 인프라와 쿠버네티스에 대해 어느 정도 배우고 간 것이 다행이었다. 팀 내에서 쿠버네티스에 대한 사전지식이 있는 사람이 본인 뿐이었기 때문에 자연스레 클라우드 환경 구성 및 CI / CD 파이프라인, NKS 구성을 모두 담당하였다.

국비교육에서는 EKS를 만져보기 전에 취업으로 조기 퇴소를 했기 때문에 관리형 쿠버네티스 서비스를 만져보는 것은 이번이 처음이었는데 정말 편하긴 했다. (이전까지는 VirtualBox에서 VM을 여러 개 만들고 직업 마스터 / 워커 노드를 설정하는 식으로 했었다) 이맛에 현질하는구나 싶었음...

쿠버네티스 환경을 구성하면서 느낀 점은 확실히 쿠버네티스 쪽 자료가 국내에 생각보다 많지 않았어서 오류가 발생할 때마다 공식 문서나 해외 쪽 자료에 의존하게 된다는 것이었다.

특히 주요 미들웨어의 Helm Chart를 사용할 때 오류가 발생할 때마다 체감이 많이 되었었는데 심한 경우는 국내 쪽 자료는 고사하고 몇몇 Chart는 지원이 끊겼다던지, 답변이 늦는다던지(오죽하면 깃헙에 PR을 올려놓은 외국 개발자들이 PR 닫지 말라고 화내는 글들이 많았음) 하는 경우가 있었는데 진짜 죽을 맛이었다 ㅋㅋㅋ....

또 대부분의 차트를 보면 AWS, Azure, GCP 전용 스펙을 갖춘 경우들이 많았는데 이를 보면서 왜 AWS를 써야 하는지... 뼈저리게 느끼게 되었다 ㅋ;

일단 1달 넘게 개고생하면서 어떻게든 그럴싸하게 클러스터를 구성해뒀고 관련 문서와 Chart를 전부 정리해놨기 때문에 클라우드 환경을 이관한다고 해도 이전보다는 훨씬 빠르게 인프라를 구성할 수 있을 것 같다. 물론 보이지 않는 구멍들이 엄청 많이 뚫려있을 것이므로... 틈틈이 허술한 부분이 없는지 찾아내면서 보완도 해야할 것이다.

소감
내가 소속된 개발팀의 구성 인원이 대부분 본인을 포함해 신입 / 주니어 개발자들이 절대 다수라서 사실 프로젝트가 잘 진행될지 우려가 되는 상황도 있었다. 뭐 나는 개발자가 되기 이전부터 사수가 없는 상황에서 많이 일을 해봤고 그 과정에서 자연스레 사수가 되는 경우가 많았어서 이러한 분위기가 좀 익숙 했지만 다른 팀원들은 그게 아니니까 불안해하는 것이 있었다.

그래도 다행인 점은 다같이 머리를 맞대고 논의를 하고 문제를 해결하려고 노력했었고, 두려워하거나 도망치는 사람은 없었다는 점이다. 매 순간순간이 사실 도전이고 고난이었기 때문에 혹시라도 다들 의지가 꺾이거나 멘탈이 무너지지는 않을까 걱정했었지만 체력 이슈를 제외하고는 다들 그래도 꿋꿋하게 버티면서 장기 프로젝트의 첫 시작을 마무리하게 되었다. 우리를 끝까지 믿어주셨던 분들과 우리 팀원들이 자랑스럽다.

여담으로 이번 프로젝트를 진행하면서 놀랐던 점은 예전에 중간 관리자로 일했던 가닥이 있어서인지 자연스럽게 나도 똑같은 신입 / 주니어 개발자임에도 다른 동료들을 케어하고 도와주려고 하고 일정 / 프로젝트를 관리하고 있었다는 점이다. 2개월이긴 하지만 포트폴리오를 만지면서 프론트엔드 쪽 공부도 했어서 프론트엔드 개발자 동료들과도 소통이 잘 되었던 부분도 있는 것 같다. (몇몇 부분은 내가 도와주기도 했고)

다만 이건 내가 대단한 것이 아니라 다른 동료들도 기분 나빠하지 않고 나를 신뢰해주었기에 가능했던 일 같다. 절대 자만하지 않고 우리 개발팀 모두가 좀 더 나은 환경에서 개발을 할 수 있게끔 내가 할 수 있는 일을 다 하고 싶다. 그리고 모두와 함께 우리 회사 만의 개발 문화를 만들고 싶다.

앞으로

회사 업무 영역
위에서도 언급했지만 MSA 구조에 대해 복습 및 리팩토링이 필요하다.
또한 이번 프로젝트에서는 오버 엔지니어링이 될 가능성이 높아보여 Istio를 제대로 활용하지는 않았지만 이어지는 프로젝트에서는 적용을 해봐야 하지 않을까 싶다. 그리고 다른 동료들에게도 공유할 수 있게 미리 문서도 작성을 해두었지만 다시 한 번 더 체크해서 고칠 부분을 고치고 다음 프로젝트 때 제대로 인수인계를 하고 싶다.

개인 공부 영역
잠깐 중단된 Spring Framework 관련 복습 및 Spring Cloud에 대한 복습 위주로 진행할 예정이다.
또한 쿠버네티스 클러스터 보안 부분을 제대로 공부하지는 않았는데 이 부분도 공부하고 싶다.
마지막으로 이어지는 프로젝트에서는 Flask 기반 마이크로서비스를 FastAPI 기반으로 변경할 예정이라고 하는데 이에 대한 스터디도 필요할 듯 싶다.