2년하고도 4개월만에 쓰는 첫 글입니다. 2022년 상반기를 끝으로 이후 아무런 글을 작성하지 않앟습니다. 약 2년 반이라는 기간동안 회사에 몰입해서 일했기 때문이면서도 제 나태함을 드러낸 기간이라고 볼 수 있겠습니다. 2025년은 2024년 회고 글을 시작으로 지속적으로 글을 투고하고자 합니다. 이 글은 2024년 회고임과 동시에 공백의 기간동안 어떤 성장을 했고 어떤 변화가 있었는지를 총망라하는 글이기 때문에 많은 피쳐를 이야기 하게 될 것입니다.
새로운 경험을 통한 성장
지난 몇 년간 제 블로그에서 회고를 보면 알 수 있다시피 회사 일에 미쳐살았다는 것을 알 수 있습니다. 그런 것처럼 하나에 빠지면 끝까지 텐션을 유지해서 나아가는 것이 저의 장점이기도 하면서 단점이기도 합니다. 그래서 기존엔 회사에 초점이 있었던 것을 2022년 상반기부터 지금까지는 키워드를 바꿔서 새로운 경험 이라는 새로운 포커스를 만들었습니다. 새로운 경험이라는 키워드는 회사일에도 적용될 수 있고, 개인에도 적용될 수 있기 때문에 여러 키워드를 고민하다가 결정했었습니다.
제게 새로운 경험은 다음과 같은 걸 기대하는 키워드였습니다.
- 말 그대로의 새로운 경험, 지금까지 안해본 것을 해보기
- 기존에 관성대로 해오던 일을 관성을 무너뜨리고 새로운 관점, 아에 다른 형태로 업무를 진행해보기
- 규칙으로 잡혀있는 것을 무규칙으로 바꿔보기, 나에게 더 알맞는 형태의 방법을 고민해보기
- 프로그래머라는 틀에서 벗어나기, 코드를 작성해야하는 압박감을 넘어 문제를 해결하는 사람이 되기
- 직관보다 객관과 수치를 갖고 일해보기, 직관은 중요하지만 직관을 뒷받침해주는 객관과 수치를 통해 더 정밀해지기
즉, 지금까지 안해본 걸 해보므로써 다른 방향으로의 성장을 모색해보고 내 나름대로 새로운 질서를 만들어보는 것에 초점을 맞추었습니다. 왜냐하면 지금까지 누군가의 선각자가 만들어 둔 일의 방식과 일을 처리해둔 방식을 그대로 답습해서 사용하고 있었고 물론 나름대로 변경하긴 했지만, 그 과정에서 관성대로 적용한 것도 분명히 있기 때문에 속도의 관점에서 좋은가를 판단할 겨를 없이 그저 빠르게만 진행한게 아닌가라는 생각이 저를 덮쳤습니다.
이러한 생각이 들었던 이유는 점점 늘어가는 연차가 있었습니다. 2025년이 되면 경력이 13년차, 배민에서만 6년차가 됩니다. 한 회사에 오래 다니면서 회사 내에서 오랜기간 다닌다는 것은 좀 더 안정적인 리더십과 다져진 프로덕트 인사이트를 통해 내가 하려고 하는 업무를 드라이브 할 수 있기 수월하고 주어진 컨텍스트에서 다양한 경험을 해볼 수 있는 장점이 있습니다. 하지만 반대로는 오히려 고이면서 고민의 범주가 좁아지고, 한계인력이 되기 쉬워지는 문제도 존재합니다.
그래서 더더욱 배민에서 5년의 기간동안 쉴틈없이 달려오면서 배민에서 원하는 관성대로만 살아왔구나를 생각했습니다. 물론 그 외에도 외부 활동을 정말 많이 했지만, 그러한 외부 활동보다도 내 자신이 어디서든 문제를 해결할 수 있는 문제해결사가 되길 바라기 때문에 위의 키워드를 기반으로 계속 달라지기 위해 노력했습니다.
새로운 업무 도메인으로
커머스 도메인에서 커리어 절반 이상을 뿌리깊은 커머스 사람으로써 살아왔었습니다. 때로는 PM, Front, DevOps, Server 등 여러 업무를 해왔고 그 과정에서 다양한 스킬을 습득했습니다. 여러 경험을 습득해오면서 2023년에서 2024년으로 해가 지나갈 때, 커머스라는 도메인을 계속 해야하는가에 대해 많은 고민이 있었습니다. 그 이유로 다른 도메인으로 옮기기에 커머스 도메인은 물론 평생을 해도 다 이해하기 어렵고 여전히 전세계적으로 성장하는 곳이고 평생을 바치는 사람들도 있을 정도로 광활한데, 지금 과연 내가 모두 습득했다고 생각하고 옮기는게 맞는가에 대한 고민이었습니다.
결론적으로 새로운 도메인으로 옮기게 되었습니다. 이러한 새로운 도전을 이끈 것은 지금 커머스 도메인을 떠나는 것이 오히려 회사를 발전시키는 방향이라고 믿었기 때문입니다. 배민의 커머스는 B마트/배민스토어/대용량특가/전국별미 등 배달/배송(택배) 등으로 이뤄지는 여러 비즈니스 도메인의 커머스가 존재합니다. 하지만 여러 커머스가 서로 저마다의 시스템으로 엮어져 있었고 그 과정에서 이를 통합하기 위한 고민을 본격적으로 하기 시작했습니다. 그 과정에서 커머스의 전문가로써 활약하기보다 지금은 공통으로써 시스템을 만들고 커머스 도메인이 아닌 전사적으로 효율화를 시킬 수 있도록 하는 것이 더 회사에 도움이 된다고 판단했습니다.
판단의 근거 중 하나로, 배민은 전시에서 평시로 넘어가는 회사라고 생각했기 때문입니다. 전시에서 평시로 넘어가게 되면 더 튼튼한 시스템과 그 시스템 위에서 프로덕트를 쉽게 운영할 수 있도록 만드는 작업이 중요해지고, 지금 전사적인 프론트 시스템은 없기 때문에 시스템을 구축하는 것을 최우선 순위로 보았습니다.
전시와 평시
전시는 회사가 적극적으로 매출 향상 혹은 어떤 명확한 목표를 갖고 드라이브를 하면서 빠르게 프로덕트를 성장시키는 것에 초점을 두는 상황을 말합니다. 평시는 프로덕트를 성장시키는 것보다 회사 전반을 안정화시키고 튼튼하게 만드는 것이 주요 목표입니다. 두 상황은 각각 업무하는 방식과 시스템이 모두 다르기 때문에 현재 회사가 어떤 형태의 업무 형상을 띄고 있는지 파악하는 것이 중요합니다.
그렇게 2024년에는 기존에 함께하던 25명의 팀원이 세 팀으로 쪼개지며 배민공통서비스웹프론트개발팀이라는 새로운 팀을 맡게 되었습니다. 배민공통서비스웹프론트개발팀은 12명 (1월 2일부로 17명)이라는 인원으로 저와 함께하던 팀원 몇 명과 다른 팀원 몇 명이 합쳐져서 생긴 팀입니다. 새로운 경험과 새로운 팀, 모든 것이 새로운 상태에서 2024년을 시작했습니다.
변혁적 리더십(Transformational Leadership)과 서번트 리더십(Servant Leadership)
변혁적 리더십과 서번트 리더십
변혁적 리더십은 구성원에게 신뢰, 경탄, 충성과 존경심을 통해 리더십을 느끼게 하며, 리더가 구성원에게 사리사욕이 아닌 다른 무언가를 더 느끼고 제공해 고무적인 시야와 성장에대한 시야, 그들의 자아를 함께 찾는 등 그러한 활동을 토대로 영향력과 지적 자극등을 통해 구성원을 성장시키는 리더십입니다. 이러한 리더십에서 리더는 카리스마, 개인별 관심 및 배러, 구성원의 성과에 대한 개입 등 더 적극적이고 활발한 리더로써의 활동을 진행합니다. 이러한 결과는 조직의 목표를 향한 구성원들의 고취를 중점을 둡니다.
서번트 리더십은 변혁적 리더십과 다르게, 조직의 목표보다 구성원에 대한 봉사라는 차원에서 동작합니다. 구성원 단위를 중심으로 고민하고 팀장으로써 더 잘할 수 있는 부분을 시행하는 것이 큰 특징입니다.
2023년까지 전시 체제의 도메인 그리고 업무 방식을 유지하면서 그에따라 변혁적 리더십(Transformational Leadership)의 형태로 팀원들과 소통해왔습니다. 변혁적 리더십을 토대로 사람들에게 카리스마를 더 보여주며 빠르게 비즈니스를 굴리고 그에 따른 업무의 형태를 분배하고 정리해 선제적으로 리더가 활발히 움직이는 것을 목표로 했습니다. 그러한 까닭으로 실제 커머스 프론트엔드를 맡았던 시점에는 모든 구성원이 바쁘고 힘들었지만 목표를 달성하면서 긍정적인 인사이트를 얻었습니다.
리더는 다른 사람을 최우선시 함으로써 맨 앞에 설 자격을 얻는다.
다른 사람을 자극하는 것이 리더의 주된 임무이다.
다른 사람들이 최고가 되지 않고서는 리더 역시 최고가 될 수 없다.
~ 당신도 섬기는 리더가 될 수 있다 (2010), 켄 제닝스 & 존슈탈 베르트
2024년에 가장 집중했던 키워드는 서번트 리더십(Servant Leadership)입니다. 변혁적 리더십처럼 변화가 빠른 비즈니스에서 대응하기 위한 리더십도 있지만, 팀원을 최우선적으로 생각하는 섬기는 리더십도 존재합니다. 그것이 바로 2024년에 가장 중요하게 생각했던 기워드이며 서번트 리더십 이라고 합니다.
서번트 리더십으로 2024년에 팀을 이끈 이유는 몇 가지 고민으로 출발했습니다.
공통 도메인에서의 리더십 고민
공통이라는 도메인이 새로 만들어지면서 우리는 조직간의 관계에서 튼튼한 중간의 역할을 했어야 했습니다. 특히나 언제든지 공명정대, 중간을 지켜야 한다는 것과 그에 따른 논리도 튼튼하게 갖고 있어야 하는 것이 중요했는데 공통에서 만드는 것이 전사 차원으로 사용되고 나가다 보니 무언가 장애가 만들어지거나 논리없이 개발이 되면 공통의 것을 사용하는 개발자 입장에서도 사용하는 것에 반감을 가지거나 난감한 일이 생기게 되었습니다.
이는 이전부터 디자인시스템을 운영해오던 것과 동일한 이치였는데, 공통이 되면서 이런 부분이 회사가 전시 상황에서 업무를 진행하던 틀릴 수도 있으나 일단 해보자와 같은 업무 스타일과 달리 모두가 이해하고 만족할 수 있는 시스템을 튼튼하게 만들어나가자와 같은 업무 스타일을 하게 되는 것이었습니다. 그래서 이러한 조직에서는 목표지향적으로 움직이는 것보다 더 좋은 프로덕트를 만들기 위해 우리 자신과 싸워나가야 하는 고독한 팀인 만큼 팀 케어에 신경을 더 쓰면서 프로덕트의 완성도를 올리는 형태의 리더십이 필요하다고 생각했습니다.
화성에서 온 팀원과 목성에서 온 팀원
2월, 새로운 팀이 만들어지면서 여러 조직에서 팀원이 오게 되었고 2025년 1월까지 총 4개 이상의 팀에서 우리 팀으로 합쳐지고 이동이 되어 17명이 되었습니다. 이러한 17명의 멤버는 서로 알아가는 시간과 업무 스타일을 맞춰나가는 두 가지 일을 진행하면서 기존의 관성으로 오던 업무를 진행해야하는 쉽지 않고 정신없는 일을 해야합니다. 특히 인원이 많아지면 서로의 이야기가 더 많아지고 지방방송 등 다양한 아젠다가 넘쳐흐르게 되어, 누군가는 평소보다 몇 배는 업무가 힘들어질 수 있고 누군가는 평소보다 몇 배는 퍼포먼스가 안나올 수도 있습니다.
이 과정에서 리더로써 해야하는 것은 최대한 지방방송을 없애고 하나의 목표를 팀원에게 전파하는 것 그리고 팀원끼리 빠르게 친밀감을 높일 수 있는 이벤트를 주기적으로 만들어 점진적으로 친해지도록 하는 것입니다. 가장 먼저 했던 일은 팀에 합류하는 인원을 팀의 목표와 목적 그리고 구성원으로써 하고 싶은 것을 1 on 1을 통해 물어보고 그에 맞는 파트에 배정해서 목표를 만들어주는 것이었습니다. 그 과정에서 그들이 회사에서 지금까지 했던 일을 일일히 찾아다니면서 어떤 업무를 잘하는지, 어떤 부분이 부족해 성장을 시켜야 하는지를 찾아봤고, 상세히 그들과 동화되기 위한 노력을 진행했습니다.
팀에 융화되는 것을 목표기반이 아닌 사람에 기반해서 서번트 리더십을 행사하므로써 조금 더 빠르게 팀에 흡수될 수 있도록 하는 노력을 했던 것이었습니다.
서번트 리더십, 효과가 있었나요?
회고를 하면서 서번트 리더십이 효과가 있었는가는 결과론적일 수 있습니다. 변혁적 리더십을 했으면 더 좋은 성과 등을 얻었을 수도 있고 리더십을 아에 발휘 안하는게 오히려 더 좋은 방향으로 이어졌을수도 있겠죠. 그래서 효과가 있었는가 측면보다는 의미가 있다로 이야기 할 수 있을 것 같습니다.
작년, 변혁적 리더십으로 팀을 이끌때 우리 팀은 전사에서 가장 일을 잘한다는 자긍심과 목표를 갖고 일했습니다. 하지만 팀원 개인은 매우 힘들었고 지쳐서 번아웃이 온 멤버들도 있었습니다.
올해는 작년보다 느릴 수 있어도 훌륭한 프로덕트 (Module Federation Platform 등, 아래에서 후술)을 만들어냈고 팀원들의 업무 만족도를 높게 올렸습니다. 빠르고 짧게 성과를 내기보다 길고 효율적으로 성과를 내었기 때문에 효과가 있었다고 생각합니다. 공통으로 오면서 여러 고민을 했던 것은 더 좋은 시스템을 구축하기 위해 긴 시간을 보고 바꾸는 걸 고민하고 생각했습니다. 지금까지 단기간으로 성과를 내고 살아남아야 하는 상황에서 조직의 목표가 완전히 달라졌기 때문에 그에 따라 저도 바뀐 것이죠.
현재 조직이 가는 방향, 요구하는 조건, 팀원의 상황에 맞췄을때 서번트 리더십을 선택하는 것은 필수였고 이러한 리더십을 선택적으로 잘 펼치는 것이 현명한 리더가 아닐까 합니다.
비즈니스에 따른 아키텍처를 고민하고 구축하기
오랜기간 배민에 몸 담으면서 소프트웨어 개발자에서 엔지니어로 생각을 바꾸고, 엔지니어에서 시니어 엔지니어 롤을 개인에게 부여하고 업무를 진행함에 따라 다양한 고민을 했었습니다. 위의 서번트 리더십 이야기를 할 때 조직의 방향에 따라 리더십을 다르게 설정하여 이행하는 것이 현명한 리더라고 이야기 했는데, 소프트웨어 엔지니어도 동일하다고 생각이 듭니다. 즉, 비즈니스의 방향에 따라 소프트웨어 아키텍처도 고민하고 변경해야하는 것이 자명한 것이죠.
예를들어 우리가 더 빠른 서비스를 배포하고 더 많은 개발자가 기여한다고 하면, Git Flow 전략이 올바르지 않을 수 있습니다. Trunked Base가 올바를 수도 있죠. 그러면 그에따라 브랜치 전략을 수정하고 브랜치 전략과 CI/CD를 적절하게 수정하여 자동화된 프로세스가 동작하도록 해야합니다.
이러한 고민 중 1년간 가장 많은 고민을 했던 것은 모두가 빠르게 변화 가능한 업무 프로세스를 사용하지 않고 있다는 점입니다. 특히 웹 프론트엔드의 경우 더 안되어있다고 생각했던 것이 있었습니다. 배민은 지난 시간동안 경쟁대응과 사업의 성장에 포커스를 맞추어 회사를 크게 만들어왔습니다. 그러면서 비즈니스의 특성상 주문이 특정 시점에 몰리는 현상과 더불어 월드컵 등의 이벤트가 있다면 그러한 이벤트를 대비하기 위한 여러 서버 측면에서의 인프라/개발 강화가 되어왔습니다.
웹의 경우 상대적으로 그러한 트래픽에 대해 자유로울 수 있도록 노드 서버를 지향하고, 안정적인 배포가 될 수 있도록 대다수 정적사이트 배포를 통해 사업의 요건을 빠르게 디스플레이를 해주는 형태로 만들어왔었죠. 그러한 인프라 리소스도 서버쪽에 더 중시가 되어있었던 것입니다. 하지만 배민이 점차 평시로 전환되고 서버 안정화가 가속될 수록 전시에서 더 기민하게 대응하게 되는 상황이 발생하게 되었습니다. 더이상 배민의 성장이 푸드 주문을 모객하는 것이 끝이 아닌 더 많은 콘텐츠와 더 많은 기능을 통해 사용자를 더 붙잡아 서비스를 오래 쓰게하면서 커머스와 같은 경험을 주는 것이 주 목적이 되었죠.
더불어 웹 프론트엔드 개발자도 100명이 넘어가게 되었습니다. 100명이 각 조직에 산발되어 있으면서 모두가 비슷한 생산성 개선을 위해 동일한 것을 개발하고, 모두가 저마다 바쁘다고 호소하는 상황이 반복되었습니다. 이러한 상황은 사실 썩 유쾌하지 않습니다. 회사 입장에서는 사람을 뽑아놨는데 시니어와 주니어가 하는 일이 그저 빠르게 비즈니스를 굴리고 쳐내버리는 일에 소진되어 있었기 때문입니다.
가장 먼저 했던 일은 회사의 웹 프론트 상황을 살피고 해당 상황을 서로가 공유할 수 있는 협의채를 만들고 생각의 방향을 일원화시키는 것이었습니다. 그 과정에서 생긴 것이 서비스 부문 웹 시스템 논의와 클럽 이었습니다. 서비스 부문 웹 시스템 논의는 부문 단위의 협의채로써, 서비스 부문 내 웹 프론트 개발자 70~80명을 대상으로 회사의 방향성과 웹 프론트에서 나오는 공통 코드, 하고 싶은 일을 언제든지 이야기하고 개선하고 함께할 수 있도록 한 달에 한 번씩 회의채를 만들어 운영했습니다. 더불어 해당 협의채의 부산물로 해당 협의채 하위에서 진행되는 클럽을 구축했습니다. 일종의 일을 하기 위한 워킹그룹인데, 조금 더 키치(?)하게 브랜딩을 했고 이 클럽을 통해 비즈니스 요건이 산발적으로 퍼져있는 아젠다를 여러 조직의 프론트가 합쳐서 일을 해결하거나 뾰족하게 특정 팀이 하기 어려운 과제를 모여서 업무를 진행합니다.
부문 웹 시스템 논의와 클럽을 진행하면서 각 프론트 조직의 문제를 취합했습니다. 1년간 내부적으로 어떤 문제를 개선해야 비즈니스를 빠르게 동작시킬 수 있을지 고민을 했었습니다. 여러 뷰 측면에서 고민했고, 가장 먼저 했던 것은 코드 뷰를 검토하는 일이었습니다. 코드 뷰에서 하나의 문제는 수정해야하는 포인트가 전방위적으로 얽혀있는 경우에 문제가 있었습니다. 이러한 문제를 막기 위해 각 도메인 별로 코드를 분리하는 정책과 레이어드 아키텍처처럼, 각 시스템 도메인을 분리하고 수정이 많은 빈도의 코드를 분리하는 등 전체적인 아키텍처를 쉽게 수정할 수 있도록 변경하는 것이었습니다.
이러한 일을 주니어 개발자도 소프트웨어 엔지니어로써 고민할 수 있도록 그림을 작성하는 방법을 알려드렸고, 몇 차례의 걸친 아키텍처 미팅을 통해 훌륭하게 그려내고 시스템을 구축해 여러 시스템을 동일하게 개발할 수 있도록 만들었습니다. 우리는 이 아키텍처 프로덕트를 통합 게이트웨이 라고 불렀습니다. 모바일 웹뷰의 요청사항이 들어오는 모든 웹을 쉽게 개선할 수 있도록 아키텍처 리펙토링을 했고, 통합된 웹뷰 코드를 띄울 수 있도록 게이트웨이 역할을 해주었기 때문이죠.
이 리펙토링건만 해도 수 개월동안 진행한 프로젝트이고, 든든한 두 명의 주니어 개발자가 함께 해주었습니다. 언젠가 해당 글이 회사 블로그에 올라갈지 모르겠습니다. 저는 주니어 개발자라고 선 긋는 것을 오히려 싫어하고, 비개발자 출신이라고 차별하는 것을 싫어합니다. 오히려 주니어 개발자만 모여있을때 훌륭한 아키텍처를 필두로 한 서비스가 만들어지기도 하고, 우리가 생각하지 못한 문제 해결 방향을 제시하기 때문입니다. 그래서 이번 프로덕트가 두 주니어 개발자가 훌륭하게 처리했기에 인상이 깊었습니다.
추후 이 아키텍처 경험을 기반으로 다양한 서비스에서도 아키텍처를 생각하고 쉽게 개선할 수 있도록 하는 생각을 가질 수 있도록 전파할 예정입니다. (물론 이전에 담당하던 커머스 등에서는 제가 아키텍처 중요성을 설파했기에 더 필요가 없다고 보기도 하지만요.)
도메인의 특성을 이해한 표준화 공략
2024년 1월부터 맡게된 배민공통서비스웹프론트개발팀은 수십개의 도메인을 개발하고 있습니다. 배민 서비스 내에 있는 공통에 관한 페이지, 라이브러리, 시스템 등 다양하고 많은 도메인을 개발하고 제작하고 있죠. 하지만 현실적으로 굉장히 많은 도메인을 유지보수하는 것은 어렵습니다.
이러한 팀을 맡게된다고 했을때, 우리는 상위 조직장이 나에게 이러한 인원과 조직의 R&R을 왜 주었을까를 고민해봐야 합니다.
- 인원 대비 하는 업무와 역할이 어느정도 범위인지
- 합쳐진 인원의 역량 수준은 어느정도인지
- 올해 핵심 과제와 목표가 무엇인지
이러한 고민을 통해 우리 팀의 목표와 성과가 명확해질 수 있습니다. 목표와 성과가 명확해지면 그 이후부터는 쉽습니다. 주도적으로 하는 구성원에게 더 줄 과제를 찾거나 필요없는 R&R을 가진 서비스를 타 팀으로 주거나 서비스 종료등의 결정을 하기 위해 지속적으로 상위 조직장에게 푸쉬를 넣으면 됩니다. 그 과정동안 팀장은 해당 업무에 대해서 최대한 디펜스를 해야합니다.
팀이 어느정도 정리가 되었다면 다음에 해야하는 것은 코드 레벨에서의 생산성을 챙겨야 합니다. 팀의 업무/역할과 같은 큰 범위의 고민에서 점차적으로 작은 규모로 내려오면서 우리의 조직이 개발조직이라는 본질을 잊어선 안됩니다. 아무리 좋은 업무 프로세스와 업무 분장을 했다고 해도 코드가 스파게티 코드로 짜여있어 개발 퍼포먼스가 나오지 않으면 안될 것입니다.
조직개편이 되었을때 코드는 다음과 같은 과정을 거쳐서 정리하는 것이 좋습니다.
- 프로젝트가 프로덕트로 배포된 운영 환경에서 어느정도 쓰이는지, 코드의 유지보수가 얼만큼 투자 되는지 파악한다. (그동안 운영은 진행한다.)
- 파악이 완료되었다면 구분을 통해 잦은 변경과 영향도가 큰 중요한 프로젝트 순서로 하나의 모노레포로 코드를 마이그레이션 한다. 마이그레이션 할 때 코드 베이스만 옮기고 리펙토링은 진행하지 않는다.
- 하나의 레포지토리로 옮겼다면 일원화된 아키텍처를 구상하고 아키텍처 형태로 리펙토링을 진행한다. 이 때 아키텍처는 인프라/폴더/코드 등 모든 아키텍처를 이야기한다.
- 업무량이 많다면 Phase로 쪼개서 진행하여 배포를 과제단위로 함께 배포시키는 방법도 있다.
프론트엔드 생태계에서 인프라는 자유롭기 때문에 상대적으로 배포를 쉽게 할 수 있고 리펙토링의 난이도는 낮은 편입니다. 물론 복잡한 시스템이 있을땐 다른 이야기지만..
결론적으로 우리 팀, 하는 역할, 뭘 해야하는지, 코드를 응집했다면 그 이후부턴 표준으로 만들어진 방향으로 지속적으로 업무를 하고 업무에서 나오는 이슈를 아키텍처를 덧대어가면서 성장시키면 됩니다.
프론트엔드 플랫폼으로, 시스템을 구축하기
작년(2023년)부터 프론트엔드의 미래를 마이크로프론트엔드로 생각했습니다. 그 이유로는 다음과 같습니다.
- 서버의 흐름이 마이크로서비스로 완전히 변경되감에 따라 조직구조가 서버+PM 기반의 사일로 조직이 되는 경우가 생긴다.
- 조직의 흐름에서 프론트엔드 개발자도 사일로에 포함되어 여러 도메인에 걸쳐진 비즈니스와 레이아웃이 결함된 코드가 생긴다.
- 마이크로서비스 레벨에서 컴포넌트 패턴이 만들어진다. 해당 컴포넌트 패턴의 R&R이 계속 변경된다.
여러 사례들이 있겠지만 위의 세 가지가 지속적으로 관찰된 패턴의 결과였습니다. 이러한 패턴으로 하여금 문제 해결을 마이크로프론트엔드 아키텍처가 적합하다고 생각했고 실제 배민에 전파하기 위해 노력중에 있습니다. 그래서 2023년에 마이크로프론트엔드 아키텍처를 실제로 통합전시어드민이라는 통합된 어드민에 활용하여 페이지 단위로 마이크로프론트엔드를 운영하고 언제든 서비스를 붙일 수 있도록 구축하였습니다.
그러다보니, 이 마이크로프론트엔드 서비스를 관리하기 위한 플랫폼이 이내 필요해졌습니다. 왜냐하면 마이크로프론트엔드로 만들게 되면 정말 마이크로한 단위조차도 모듈이 될 수 있기 때문입니다. 그래서 이러한 모듈이 서로 연관성이 어떻게 생기는지, 수정했을때 어떤 영향범위가 있는지를 지속적으로 트래킹하고 가시적으로 볼 수 있어야 했습니다. 그렇기에 저는 MFP라는 개념을 도입했습니다.
MFP는 Module Federation Platform의 준말입니다. 사내에서 표준 기술로 세팅을 하려고 시도한 것은 Module Federation이었고, MF를 이용해 마이크로프론트엔드를 구현하고자 했습니다. 전사적으로 SSR을 사용하지 않기도 했고 가장 정보와 쉽게 접근할 수 있는 기술스택이었기 때문입니다. MF로 만들어진 여러 모듈을 Platform으로 하여금 언제든지 모듈을 합쳐서 페이지를 만들어낼 수 있는 구조를 만들어내기 위해 노력했고, 해당 내용은 제 발표 영상 에서 더 자세히 보실 수 있습니다.
나의 변화
2024년에는 나 자신에게 떳떳한 사람이 되고 더 현명하고 많은 경험을 해본 사람으로 되는 것이 목표였습니다. 그래서 여러 도전을 진행했고 오늘 회고에서야 비로소 이야기를 할 수 있게 되었습니다.
다이어트
이미지상으로는 그렇게 보이지 않는데, 배민에 2019년부터 다니면서 배달음식과 코로나를 맞아 몸무게가 거의 30~40키로가 쪘었습니다. 그래서 건강의 적신호가 너무 많이 오게되어 실제 관리를 해야겠다 마음먹고 40키로를 뺐습니다. 이 글을 최종 작성하고 있는 2월 기준으로 40키로니까, 약 1년의 시간동안 다이어트를 통해 40키로를 뺐네요. 뺴면서 정말 자존감이라던지 업무 텐션이라던지 많은 부분이 긍정적으로 작용하여 하루하루 알차게 보낼 수 있었습니다.
여행
20대 중반까지 개발에만 미쳐있었던 저는 새로운 경험이 부족하다고 많이 느꼈고 이야기 할 주제도 없어 흔히말하는 공대형 노잼인간이었던 것 같습니다. 배민오면서 이러한 자신을 버리고 더 재밌고 뭐든지 경험을 해보아서 언제든지 자신있게 나에 대해서 이야기 할 수 있는 사람이 되길 바랬던 것 같아요. 그래서 새로운 경험을 해보고자 캠핑, 여행 등 다양한 경험을 했고 이러한 다양한 경험을 함께 할 수 있었던 회사 동료 (형들)이 있었기에 행복했던 날들이었던 것 같아요.
실제로 정말 많은 곳을 여행하고 그들의 문화 그리고 그걸 경험하는 나 자신에 대해 복합적으로 고민해보고 삶을 마주하는 자세를 바꿀 수 있었던 것 같습니다. 여행은 나 자신을 성장시킬 수 있었던 동력이었던 것 같아 다이어트 다음으로 여행을 넣어봤어요.
스쿠버 다이빙
올해의 가장 큰 도전 중 하나였던 것 같습니다. 물을 무서워하는 저는 스쿠버다이빙을 통해 물 두려움을 극복하고 새로운 경험을 해보았던 것 같아요.
끝으로
블로그 글을 실로 정말 오랜만에 작성합니다. 그래서 아마 읽으시는 분들께서 ‘얘 갑자기 왜이리 글을 못써졌지?’ 라고 생각하실수도 있을 것 같다는 생각이 듭니다.
사실 이번 블로그 글은 외부 사람에게 보여주기 위한 그러한 글보다는 제가 나름대로 반성하면서 앞으로 글을 열심히 작성해봐야겠다는 생각을 갖고 정말 글이 안써졌음에도 끝까지 밀어붙여 몇 달간 작성한 글이었습니다.
몇 년의 공백기동안, 저는 회사일에 집중하면서 블로그 포맷이 아닌 위키에 나의 템플릿을 만들고 업무를 위한 글만 작성을 했던 것 같아요.
그러한 날을 반성하면서, 앞으로는 블로그 글을 많이 쓰고 느낀 걸 최소한 적기라도 하는 느낌으로 블로그를 다시 운영해보고자 작성했습니다.
2025년의 제 개인 목표는 ‘작은것을 하더라도 진짜 제대로, 정말 잘’ 입니다. 예를들어 회식을 준비해도 최선을 다해서 모두가 즐겁게 웃을 수 있는 걸 하는 것처럼 조그마한 업무도 최대한으로 잘 할수 있도록 만들어보고자 합니다.