약 한 달 동안(23.12.11~ 24.01.12) “클라우드 기반 MSA 이커머스 서비스 새싹농장“ 이라는 주제로 팀 프로젝트를 진행했다. 본문에서는 가볍게 회고를 해보려고 한다.
프로젝트 요약
프로젝트의 주된 목적은 Mono Repo로 관리하는 폴리글랏 마이크로 서비스를 CI/CD 파이프라인을 구축해 AWS EKS(AWS 완전 관리형 쿠버네티스) 상에 배포하고 운영하는 것이었다. 추가로 MSA 특성인 유지보수 용이성을 경험해보기 위해 처음부터 개발하지 않고 서비스 및 기술스택과 파일구조가 잡힌 레포지토리를 가져와서 코드를 수정하는 작업을 진행했다. 그 결과 위 도표와 같은 구조로 서비스를 개발했다. CI는 Github Action으로, CD는 Argo CD를 사용해서 AWS EKS 클러스터 상에 배포했다. 서비스 기능은 심플하다. 회원가입, 로그인, 상품 정보 노출, 장바구니에 상품 담기가 있다.
나의 역할은 서비스 개발과 CI를 맡았고 전체 아키텍처를 설계였다. 처음으로 FastAPI, Spring Boot, Express를 사용해 폴리글랏으로 백엔드를 개발했고 CI/CD 파이프라인 구축과 AWS EKS에 배포까지 Software Life Cycle을 경험했다. 아쉬운 점이 있다면 k8s 환경에 서비스를 배포했음에도 EKS Auto Scaling을 경험해 보지 못했다는 점이다. EKS AutoScailing은 추가적으로 학습하고 구축해 볼 계획이다.
느낀점
기본 적인 것에 대하여 : 지각하지 말아다오
나는 규칙 준수를 중요하게 생각하는 편이다. 그러나 이를 중요시하지 않는 사람들이 도처에 암약하고 있다. 우리 팀원도 예외는 아니었다. 지각을 꾸준히 하는 팀원이 둘이나 있었다. 이유 없이 늦지 말아 달라고 당부하는 일이 계속되자 심적으로 너무 괴로웠지만 그래도 늦지 않을 때까지 포기하지 않았다. 심지어 새벽 2~3시가 넘어서 취침하지말고 일찍 주무시라는 부탁까지 했다. 결과적으로 개선이 되었고 지각하는 사례는 줄어들었다. 사소한 행동들이 쌓여서 신뢰에 영향을 준다고 생각한다. 동료에게 신뢰를 쌓기 위해서는 기본적인 약속부터 잘 지켜야 한다는 것을 몸소 느꼈다.
서로의 열정 차이: 극복하기 위해 솔선수범 했던 기억
팀장을 맡았다. 그래서 더 적극적으로 찾아보고 공유했다. 특히 개발자로 일할 때 팀에서 사용했던 애자일 방법론을 적용하기 위해 노력했다. 협업도구로는 칸반보드를 사용하기 위해 Jira를 채택했고 프로젝트 문서 관리를 위해 Confluence라는 제품을 사용했다. 내가 먼저 사용 방법을 학습하고 팀원에게 공유했다. 도구의 필요성을 설명하고 각 사용 방법을 공유했다. Jira를 사용하면서 업무 진행도를 시각화해서 볼 수있게 했다. Confluence를 사용하면서 프로젝트 문서를 아카이빙할 수 있었다. 무료 노션 팀 페이지 사용에서 제한되던 텍스트 블럭 수를 신경쓰지 않고 마음 껏 문서를 작성하는 것은 덤이었다. 스크럼 회의, 코어타임, 일주일 단위 스프린트를 도입했다. 작은 목표를 빠르게 이루어 큰 목표를 달성하기 위함이었다. 작업 상황을 시시각각으로 공유하고 서로 피드백을 주도록 팀원들을 설득했다.
물론 처음부터 모든 것이 뜻대로 되진 않았다. 업계 표준이라 생각했던 협업도구는 팀원들에게 낯설고 사용하기 어려운 걸림돌이었고 작업을 위한 작업으로 여겨졌다. 애자일 방법에 대해 설명하고 실천하기로 이야기를 했으나 받아들이는 방법은 각자 달랐다. 나는 주도적으로 일하고 최대한 의사소통을 많이 하고 변화에 빠르게 대응할 수 있는 마음가짐에 중점을 두었으나 팀원들은 수동적이었고 워터폴 방식으로 작업했다. 한 번은 워터폴방식으로 작업하는 팀원과의 마찰이 있었다. AWS 인프라를 담당하는 조원에게 진행도를 물었으나 개발을 맡은 내가 개발을 마칠 때까지 기다리고 있었다고 했다. 나는 기본적인 crud가 되는 Todo List 서비스라도 배포해보라고 권했다. 이처럼 작업 진행에 간극이 생길 수 있기 때문에 칸반보드를 이용해 작업 상황을 파악하고 짧은 주기로 동료와 진행사항에 대해 이야기하려고 했다. 보다 적극적인 의사소통을 해야겠다!
설득하기: 한 번 해보시고 판단해 주시면 안 될까요?
프로젝트 내내 서비스 개발, 협업 툴 도입, 방법론 등을 IT 프로젝트 경험이 없는 조원들을 설득하는 과정의 연속이었다. 왜 해야하는지 설명하고, 우선 해보고 판단해달라고 부탁했으나 늘 뚜렷한 근거없는 반대에 부딪혔다. 가령, 개발에서는 폴리글랏 마이크로 서비스 개발, Mono Repo 도입에 대해서 개발을 할 줄 모른다며 반대했고, 인프라 구성에서는 AWS 워크샵에서 안내해주는대로 EKS 클러스터를 구성하는게 아닌 차례차례 EKS의 모든 요소를 직접 구성해 EKS 클러스터 구축하자는 의견을 내면 팀원들은 어렵고 복잡하다는 이유에서 반대했던 일이 있었다. 그럼에도 불구하고 십 분이라도 사용하는 기술을 이해하기 위해서는 현업과 비슷하게 서비스를 개발해야한다는 생각이 들었고 계속 제안했다. 나는 꾸준히 말했다. “그래서 말인데, 한 번 해보시고 판단해주시면 안될까요?”
갑작스러운 팀 규모 축소와 프로젝트 규모 조정
다섯 명의 팀원이 있었으나 결과적으로 2명이 진행했다. 처음부터 취업으로 빠진 팀원 A, 중간에 하차한 B와 C가 있었다. 그리고 팀원은 D만 남았다. 이 과정에서 너무나 많은 마음 에너지를 소모해버렸다. 하차하는 조원들은 일단 하는 데까지 뭐라도 해보겠다는 태도였다. 나는 이들 각자가 자발적으로 떠나기 전까지 할 수 있는 작업을 제시하고 어떻게 인수인계할 것인지 말해주길 바랐지만 그들은 두루뭉술하게 최대한 돕겠다는 말만 했다. 구체적으로 계획을 말해달라고 했으나 시키는 대로 하겠다는 대답을 받았다. 혹은 그마저도 말하지 않는 사람도 있었다. 이런 태도를 보고 남아서 끝까지 마무리 짓는 사람은 어찌 되든 상관없다는 태도로 대하는 느낌을 받았다. 결자해지. 자신이 저지른 일은 자신이 책임져야 한다. 반면교사 사례가 또 하나 늘었다.
모쪼록 팀원의 부재로 중간에 프로젝트 규모와 팀 내 역할을 조정해야 했다. 첫 계획은 Prometheus와 Grapana와 같은 o11y를 서비스메시를 활용해 적용해 보려고 했다. 또한 백엔드 마이크로 서비스 간에 통신 로직을 추가할 예정이었다. 그러나 인력이 갑자기 감축되었다. 가장 먼저 고민했던 것은 작업의 우선순위였다. 그 결과, 먼저 서비스를 개발하고 AWS EKS 환경에서 실행하는 작업을 했다. 그 후 CI/CD 파이프라인을 구축해서 코드 수정부터 배포까지 자동화할 수 있었다.
질문방어: 설명하면서 학습도 하는 방법
조원들은 대부분의 IT용어를 알고 있지 못했다. MSA와 Monolithic, 애자일 방법론, 스크럼 미팅, 형상관리, 프로그래밍 언어, 서비스메쉬와 이를 설명하기 위한 사이드카 패턴 등 수없이 많은 개념을 생소하게 받아들였다. 나는 설명하는 일을 좋아한다(마치 해리포터에 나오는 어둠의 마법 방어술처럼 "질문방어"라고 생각했기 때문이었을까?). 어떤 개념을 이해하기 쉽고 정확하게 설명하고 싶은 생각에 더욱 열심히 레퍼런스를 찾아서 설명했다. 기억에 남는 일은 VPC 내부에 있는 백엔드 서비스에서 외부의 MongoDB Atlas와 어떻게 통신하는지 묻는 팀원에게 화이트보드에 그림을 그려가며 설명했던 일이다 ①. 항상 설명 끝엔 백 번 이론에 대해 말하는 것보단 직접 해봐야 이해할 수 있다고 습관처럼 말을 했었는데 스스로도 이 말을 명심하고 지켜나갈 것이다. 동료에게 지식을 설명하기 위해 학습한 뒤 설명하고 궁금증 방어는 잘 잊혀지지 않는 좋은 공부 방법이라고 생각한다. 특히 스터디 후 짧은 발표를 해보는 일은 더욱 좋은 학습법이라고 생각한다.
회고를 마치며 : 솔선수범, 긍정, 행동
프로젝트를 마무리 지었다. 기술 구현에 대한 어려움보단 IT에 대한 배경 지식이 없는 동료를 공감시키는 점이 가장 어려웠다. 그래도 꿋꿋하게 내가 먼저 “클라우드 기반 MSA 이커머스 서비스”라는 주제를 찾아와서 공유했고 애자일 방식과 Jira, Confluence를 사용하게끔 노력했다. Gitops 전략을 사용하기 위해 CD를 담당한 팀원에게 GitOps Repo를 운영할 수 있도록 부탁했고 Git 사용법을 알려주었다. 또 다른 시련은 갑자기 인원이 5명에서 2명으로 줄었던 일이다. 좌절하기보다는 둘이서 할 수 있는 작업 우선순위를 세웠고 프로젝트를 마무리했다.
지금까지 살면서 곤란했던 순간이 이렇게 많았던 프로젝트는 처음이었다. 그 이유는 태도 및 마음가짐 때문이라고 생각한다. 어떻게든 해내야겠다는 생각으로 문제에 접근하는 사람과 그렇지 않은 사람 사이에서 마찰이 잦았다. 내가 어떤 사항을 제안할 때 어렵다고 거절하거나 모른다는 이유로 고민하는 모습조차 보이지 않고 멍하니 있는 조원을 볼 때면 깊은 고뇌에 빠지기도 했다. 문득 무력감의 수렁에서 빠져나가야 겠다는 생각이 들었고 솔선수범해보자는 판단을 했다. 내가 먼저 좋은 방법을 찾아 제안하고 적극적으로 피드백을 주고받을 수 있는 분위기를 만들기 위해 노력했고 선순환을 만들 수 있었다. 어떤 상황에서도 부정적으로 생각해서 바뀌는 것은 없다. 긍정적인 자세로 목표를 완수할 수 있는 방법을 생각해보자.
추가 설명
①: AWS EKS에서는 Private Subnet에 배치된 node가 외부와 통신할 때 Nat Gateway를 사용하는데, 이 때 AWS에서 Nat Gateway의 Public IP를 할당하고 관리한다. 해당 Public IP를 MongoDB 접근가능 IP로 추가하면 VPC 내부의 백엔드 서비스와 통신할 수 있다.
'프로젝트' 카테고리의 다른 글
| 이커머스 클론 프로젝트 후기 (0) | 2023.06.08 |
|---|
