우아콘 2024 후기, 한번의 배달을 위해 필요한 모든 기술을 만나다!

안녕하세요! 운 좋게 우아콘 2024에 당첨되어 다녀왔어요! 올해는 "한 번의 배달을 위해 필요한 모든 기술들"이라는 멋진 주제로, 정말 다양한 발표와 기술들이 선보였답니다. AI/ML, 배달 로봇, 트래픽 처리 같은 최신 기술들이 주를 이루었고, 무려 30개 이상의 세션이 마련되어 있어 어디부터 들을지 고민될 정도였어요.

 

사실 다른 분야 세션도 들어볼까 했지만, 4일 뒤에 다른 AI 컨퍼런스도 다녀와야 해서 프론트엔드 세션 위주로 참석했답니다. 한정된 시간 안에서 최대한 유익한 내용을 챙기려고 한 선택이었어요. 😊

 

 

 

 

오프닝 노트에서 만난 만다오(mandao)와 버즈(Buds) 🛠️

우아콘 2024의 오프닝 노트에서는 우아한형제들 CTO와 딜리버리 히어로 CTO가 함께 무대에 올라, 두 기업 간의 기술 교류 현황을 공유하는 시간을 가졌어요. 글로벌 시장에 선보인 두 가지 프로덕트, 만다오(mandao)와 버즈(buds)에 대한 소개도 함께 전해주셨답니다.

 

만다오(mandao)는 이름부터 재미있는 유래가 있어요. “만들어다오!”라는 의미에서 지은 이름이라고 해요! 😆 클릭 몇 번만으로 콘텐츠를 손쉽게 제작할 수 있는 웹 에디터로, 개발자나 마케터, 디자이너들이 복잡한 기능을 간편하게 조작할 수 있어요. 데이터 흐름, 조건 분기, API 연동 등도 손쉽게 관리할 수 있도록 설계된 프로덕트입니다.

 

버즈(buds)는 이름만 들었을 때 삼성 이어폰이 떠오를 수도 있지만, 사실은 Baemin User Data System의 약자라고 해요! 배달의민족의 유저 데이터를 기반으로 특정 조건을 가진 고객을 타깃팅할 수 있는 마케팅 타깃팅 툴이에요. 예를 들어 CDP(Customer Data Platform) 데이터를 활용해 연령, 음식 선호도 등의 조건에 따라 맞춤형 타깃팅이 가능하다고 합니다.

 

이 두 프로덕트는 딜리버리 히어로와 협업해서 이제 글로벌 시장으로도 수출된다고 해요. 배달의민족이 처음 나왔을 때가 엊그제 같은데, 이렇게 글로벌 기업으로 성장하는 걸 보니 정말 대단하다는 생각이 들었어요.

 

 

첫 번째 섹션: 복잡한 비즈니스에서 중복 개발을 줄이기 위한 Module Federation Platform 구축

 

처음에 Module Federation을 도입하게 된 배경을 차근차근 설명해 주셨어요. 초기에는 모노레포를 통해 어드민 통합 작업을 진행했을 때, 세 팀만 참여했기 때문에 큰 문제가 없었지만, 시간이 지나면서 작업자 수가 증가하면서 상황이 달라졌다고 해요. 코드 충돌이 빈번해지고, 책임 소재가 불분명해지면서 팀 간 커뮤니케이션 비용도 점점 늘어나게 되었다고 합니다.

 

이 문제를 해결하기 위해 깊이 고민한 끝에, 기존의 모놀리식(monolithic) 구조보다는 마이크로 프론트엔드(microfrontend) 방식으로 전환해야 한다는 결론에 도달했다고 해요. 어드민 페이지뿐만 아니라 서비스 페이지도 한 페이지에 공통팀, 주문팀, 결제팀, 혜택팀 등 다양한 팀이 관여하고 있기 때문에, 어드민 관리 역시 더 효율적으로 구성할 필요가 있었다는 점을 강조해 주셨답니다.

 

기술적인 문제를 해결하기 위해 여러 가지 고민을 하던 중, Module Federation을 도입해보자는 아이디어가 나왔다고 합니다. 그리고 이때부터 Module Federation 1.0 도입기가 시작되었다고 합니다.

 

Module Federation은 각 모듈을 독립적으로 배포할 수 있도록 해주며, 브라우저 런타임에서 필요한 모듈을 동적으로 로드하고 통합하여 하나의 프로덕트처럼 동작하게 만드는 기술이라고 해요. 이 방식 덕분에, 다양한 팀들이 각자의 모듈을 독립적으로 개발하면서도, 최종적으로는 통합된 하나의 서비스처럼 운영할 수 있게 되었다고 합니다.

 

 

새로운 기술에는 장단점이 있기 마련이죠. 하지만 연사님은 Module Federation(MF)은 조직 개편이 잦은 배민에 각 팀이 독립적으로 모듈을 개발하고 배포할 수 있는 구조 덕분에, 조직이 변경될 때도 유연하게 대응할 수 있었다고 합니다.

MF 1.0을 사용하면서도 몇 가지 해결해야 할 문제들이 나타났어요. 바로 이 시점에 MF 2.0 업데이트 소식이 들려왔다고 합니다. MF 2.0의 업데이트는 기존의 불편한 점을 개선했지만, 여전히 아쉬운 부분도 남아있었다고 합니다.

 

 

1. 복잡한 Remote 개발환경
   • 각 모듈이 항상 특정 Host에 의존적이어서, 리모트를 동시에 확인하는 과정이 복잡하고 어려웠어요.
2. 공통 코드 관리 방식의 부재
   • Host마다 리모트 관련 공통 코드가 독립적으로 개발되다 보니, 일관된 코드 관리가 쉽지 않았고, 공통 코드가 부족하다는 점이 아쉬웠습니다.
3. 런타임 Remote 관리 시스템 부재
   • 리모트를 동적으로 관리할 수 있는 시스템이 부족해, 런타임에서 효율적으로 관리하기 어려웠어요.

 

이러한 문제들을 보완하고 더 나은 개발 환경을 만들기 위해 추가적인 고민과 개선이 필요하다는 것을 다시금 느끼게 되었다고 합니다.

 

이런 문제들을 해결하기 위해, 배민에서는 Module Federation을 보다 쉽게 다루고 운영할 수 있는 플랫폼을 구축했어요. 연사님께서 도입기를 길게 설명하신 후, 시간이 부족해지면서 이 부분을 빠르게 설명하셨는데요, 저도 듣다 보니 세 가지 정도만 기억에 남았어요.

1. 배민에 @baemin/exodia라는 라이브러리가 있다는 점
2. 어드민에서 리모콘을 통해 원격 제어를 할 수 있다는 점
3. 로컬 개발자 경험(DX)을 개선했다는 점

마지막으로 연사님께서 “상황에 맞게 유연하게 모듈을 정의하고, 언제든 재활용하며 서로를 참조해 웹페이지를 만들어 가는 것”에 대한 중요성을 강조하셨는데, 그 부분이 참 인상 깊었어요.

저도 현업에서 이런 문제 해결 과정을 겪는다면, 연사님처럼 문제를 명확히 정의하고 해결책을 찾아가는 사람이 되고 싶다는 생각이 들었답니다. Module Federation이라는 새로운 기술이 그저 문제만 남기는 것이 아니라, 하나하나 해결해 나가면서 더 나은 방향으로 나아가는 모습이 정말 멋져 보였어요.

 

 

두 번째 섹션: 디자인 가이드를 넘어 비로소 시스템으로, 우아한 콩방 코어 시스템

 

두 번째 섹션에서 가장 기억에 남았던 것은 디자인 시스템에 대한 이야기였어요. 처음에는 긍정적인 반응을 얻었던 디자인 시스템이, 1년 6개월 후 설문조사 결과에서는 불만족도가 높아졌다는 거였죠. 연사님께서는 설문조사를 보면서 원인을 찾으셨는데, 결국에는 원칙과 기준의 부재 때문이라고 진단하셨어요.

 

 

연사님은 예시로 운전 좌석 위치에 대한 각국의 정책을 들며 설명해 주셨어요. 우리나라처럼 운전석이 왼쪽에 있는 경우도 있고, 일본이나 호주, 영국처럼 오른쪽에 위치하는 경우도 있지만, 각국은 모두 운전석 위치에 대한 명확한 정책을 가지고 있죠. 시스템도 마찬가지로 정책이 필요하며, 이는 클린 코드 책에서도 강조되는 부분이라고 해요.

결국 중요한 것은 원칙과 기준을 세우는 것, 그리고 이를 위한 의사결정과 원활한 커뮤니케이션이라고 하셨어요.

이어서 연사님은 코어 시스템에서 해결해야 할 문제와 달성해야 할 목표를 다음과 같이 정리해 주셨습니다.

1. 유연한 조직 변경에도 새로운 학습이 필요 없는 통합된 시스템 인터페이스 구축
2. 시스템 안에서 일관성과 예측 가능성을 확보해 학습 곡선을 완만하게 하는 것
3. 프로덕트에서 발생하는 UI 변경을 즉시 구현하고 Mold에 맞춰 관리할 수 있는 구성
4. 디자인 시스템 엔지니어와 디자이너, 그리고 제품 디자이너와 엔지니어의 역할 경계 설정

 

 

그리고 코어 시스템의 Base Component에 대해서도 설명해 주셨는데, 이를 듣자마자 아토믹 패턴이 떠오르더라고요. 다른 분들도 같은 생각을 하셨는지, 익명 질문에서 "아토믹 패턴과 코어 시스템의 차이"에 대한 질문이 올라왔고, 많은 좋아요를 받았지만 시간 관계상 답변을 듣지 못해 아쉬웠어요.

확실한 건, 대규모 프로젝트에서는 Headless UI와 같은 코어 시스템이 필요하다는 점이에요. 이런 코어 시스템이 체계적으로 구축될 때, 복잡한 요구사항 속에서도 일관된 디자인 시스템을 운영할 수 있을 테니까요.

이번 발표를 통해 연사님의 고민과 문제 해결 방식에서 많은 영감을 얻었답니다.

 

 

세 번째 섹션: 통합테스트로 보다 안전한 웹 프런트엔드 서비스 제공하기

우아콘에서 단위 테스트, 통합 테스트, E2E 테스트의 장단점을 다양한 예시와 함께 설명해 주셨는데, 모든 테스트가 모든 문제를 해결해주지는 않는다고 강조하셨습니다.

 

특히 기억에 남았던 부분은 서버 통신 시나리오 검증에 관한 이야기였어요. MSW(Mock Service Worker)라는 브라우저와 Node 환경에서 API 모킹을 지원하는 라이브러리를 이용해 테스트를 진행한다고 하셨는데, 이 부분이 새롭게 다가왔어요. 저는 그동안 일일이 목 데이터를 만들어 테스트했는데, 라이브러리를 활용해 다양한 케이스를 테스트할 수 있다는 것이 신기하더라고요. 예를 들어 서버 응답 실패나 지연 상황 등 다양한 케이스를 검증할 수 있어서, 지금 진행하는 프로젝트에 꼭 적용해보고 싶었습니다.

 

 

연사님께서는 테스트의 장점으로 코드 수정 시 영향 범위를 파악하기 쉽다는 점을 들며, 테스트 수준의 적절한 분리를 강조하셨어요. E2E 테스트는 실제 사용자의 동작과 유사하게 핵심 시나리오를 검증하는 데 좋고, 유닛 테스트는 세부 기능을 검증할 때 간단하고 빠르게 진행할 수 있어 테스트의 독립성이 보장된다는 것이었죠. 이렇게 하면 안전한 웹 프론트엔드 서비스를 제공할 수 있다는 설명이 인상 깊었어요.

또 기억에 남았던 익명 질문 중 하나는 "초기 팀인데, MVP 수준의 프로젝트에서도 테스트 코드가 필요할까요?"라는 질문이었어요. 연사님께서는 개인적인 의견으로 초반에 테스트 코드를 작성해 두면 유지보수가 쉬워진다고 답변하셨는데, 이 부분에 저도 크게 공감했습니다.

현재 MVP 수준의 프로젝트를 진행 중인데, 테스트를 적용하려고 하니 고민이 참 많아집니다. 테스트가 필요하다는 건 알지만, 실제로 도입하려면 여러 번 결심을 하게 되는 것 같아요. 😅

물론 "테스트에 너무 얽매이지 말라"는 이야기도 많이 들었지만, 다시 생각해보니 필요할 때 사용할 수 있는 도구로서 테스트는 반드시 배워둘 가치가 있는 영역이라는 생각이 들었습니다. 이번 우아콘을 통해 테스트의 중요성과 필요성에 대해 다시 한번 깨달을 수 있었던 소중한 시간이었어요.

 

 

네 번째 섹션: 디자인 시스템 문서를 생동감있게 만들기 위한 '우아한플레이그라운드' 제작기

 

두 번째 섹션과 이어지는 느낌으로 우아한 형제들의 디자인 시스템에 대한 이야기가 나왔어요. 배민의 디자인 시스템인 클레이와 몰드를 설명하면서, 이제는 프론트엔드 개발자뿐만 아니라 백엔드나 다른 직무의 분들도 화면 구현이 필요한 상황이 많아졌다고 하더라고요.

특히, 신규 입사자들이 스토리북이나 가이드만으로는 컴포넌트를 명확히 이해하기 어려워, 결국 코드를 통해 직접 확인해야 하는 번거로움이 있었는데요. 이를 해결하기 위해 우아한플레이그라운드가 제작되었다고 합니다.

연사님께서 우아한플레이그라운드를 만드는 과정에 대해서 설명해주셨어요.

1. 코드 에디터와 프리뷰 배치: monaco-editor와 iframe srcDoc을 활용해 실시간 UI 미리보기를 구현
2. npm 라이브러리 import: 리액트가 import 구문을 통해 npm 라이브러리를 사용하는 문제를 importmap과 esm.sh를 통해 해결
3. TypeScript/JSX 지원: esbuild-wasm을 사용하여 TypeScript와 JSX 파일을 지원
4. TypeScript 인텔리센스 지원: TypeScript Language Server와 TypeScript Compiler API를 활용해 코드 자동완성 기능 제공
5. 인메모리 파일 시스템: esbuild Plugin과 in-memory FS로 빠른 빌드와 실행을 지원하는 인메모리 시스템 구현

 

 

이러한 실시간 IDE 기능이 정말 흥미로웠어요. 작은 프로젝트에 이런 기능을 어떻게 적용할 수 있을지 고민하다가, 잠시 코드샌드박스에 적용해 보면 좋겠다는 생각도 들었습니다. 다만, 코드샌드박스의 빌드 시간이 길어 직접 만들어보는 게 더 나을 것 같다는 생각도 들었어요. 현재 프로젝트에서 일정을 관리하고 이슈를 해결하느라 바쁘지만, 언젠가 개인 프로젝트로 꼭 한 번 만들어보고 싶은 목표가 생겼답니다.

 

 

다섯 번째 섹션: 네이티브 모듈? 그게 뭔데요? React Native로 만드는 배민커넥트 앱 두 번째 이야기

 

프로젝트를 하던 중에 아는 분이 유튜브 영상을 추천해주셨던 기억이 나요. 당시엔 "웹 개발자가 리액트 네이티브를 한다고? 짱인데?" 하고 놀라워했죠. 그런데 영상을 보면서 웹 개발자가 앱 개발에 도전하는 과정을 보니 우당탕탕 고생이 많으셨더라고요. 그때 보았던 분의 이야기를 이번 현장에서 직접 듣게 되다니, 정말 영광스러운 순간이었어요.

강연을 들으면서 느낀 건, 리액트와 리액트 네이티브가 문법은 비슷하지만 실전에서는 많이 다르다는 점이었어요. 앱 개발에 관심이 있다면 리액트 네이티브를 한 번 시도해보라는 권유를 들은 적이 있었고, 강의를 통해 "이거 할만한데?"라는 생각도 했었죠. 하지만 이번 강연을 들으면서 리액트와 리액트 네이티브가 정말 많이 다르다는 걸 실감했어요.

연사님께서는 네이티브 모듈에 대해 세 줄 요약으로 설명해주셨는데요.

1. 리액트 네이티브만으로는 안드로이드와 iOS의 모든 기능을 다 다룰 수 없다.
2. 네이티브 모듈과 네이티브 컴포넌트를 사용하면 자바스크립트 코드에서 네이티브 API와 UI를 다룰 수 있다.
3. 많은 React Native 라이브러리들이 사실 네이티브 모듈과 컴포넌트의 모음이다.

이렇게 핵심적인 설명을 들으니 이해가 쉬웠어요.

 

 

그런데 앱 업데이트마다 알림이 울리지 않는다는 문제를 해결하려고 고생하셨다는 에피소드도 들려주셨어요. 해결의 실마리는 웹 개발자들이 안드로이드 앱 개발 기초 스터디를 했던 경험에서 얻었다고 하시더라고요.

 

 

이 외에도 소소한 경험들을 공유해 주셨는데, 그중에서도 리액트와 리액트 네이티브가 렌더링 시점이 다르다는 점을 처음 알게 되어 인상 깊었어요. 그리고 연사님의 강연 마무리가 가장 재미있었어요.

 

 

"물론 항상 해피엔딩은 아님"라는 문구를 보고, 프로젝트 중간 발표 때 이 문구를 사용해보기도 했어요. 정말 개발이라는 건 적극적인 자세와 호기심이 없다면 꾸준히 이어가기 쉽지 않은 것 같아요. 이번 강연을 보며 긍정적인 마음가짐으로 개발에 임해야겠다는 다짐을 하게 되었답니다.

 

 

집중형 멘토링 시간 - 복다훈 멘토님

이번에 처음으로 집중형 멘토링과 이그나이트 세션이 생겨서 신청하게 되었어요. 사실 그때는 프로젝트 문제 때문에 정말 울고 싶을 정도로 힘든 상황이었는데, 멘토님이 해주신 말씀이 큰 위로가 되었어요. 특히, 자신감이 떨어질 때야말로 중급 개발자로 성장해가는 과정이라는 이야기가 정말 가슴에 남았습니다. 그 외에도 많은 유익한 조언을 들을 수 있었어요.

• 클린 코드를 지향하고, SOLID 원칙을 고려하여 객체지향 프로그래밍을 적용하되, 컴포넌트에 너무 많은 책임을 부여하지 말 것
• 페이지 단에서 if문이 많아지면 코드가 복잡해지기 때문에, 개방-폐쇄 원칙을 활용해 원본 코드를 수정하지 않고 확장할 수 있는 방법을 고민할 것
• 컴파운드 컴포넌트나 렌더 프롭스 패턴과 같은 다양한 패턴을 활용해 코드 재사용성을 높이기
• 기능 구현 후 리팩토링과 테스트 코드를 작성해 코드 품질을 지속적으로 개선
• SonarQube와 같은 코드 품질 분석 도구를 사용해 코드의 품질을 점검할 것
• 최신 기술 동향을 파악하고 사내 적용 가능성을 탐색하기 위해 기술 컨퍼런스나 네이버 FE 뉴스 등을 참고할 것
• 폴더 구조는 프로젝트 초기 상태에 맞게 구성하되, 프로젝트가 커질 때 유연하게 변경할 수 있도록 팀원들과 논의하며 준비할 것
• 작은 규모의 팀에서는 GitHub Actions를 활용한 CI/CD 구축을 추천. ESLint, SonarQube, Lighthouse CI 등의 도구를 통해 품질을 관리할 것
• 성능 최적화와 네트워크에 대한 이해를 바탕으로 번들 사이즈를 줄이고 렌더링을 최적화하는 방법을 고민할 것
• 토론을 통해 자바스크립트와 타입스크립트, 네트워크 및 자료구조에 대한 기본기를 탄탄히 다질 것
• 경쟁력을 높이기 위해 모던 자바스크립트와 HTTP 네트워크와 같은 기본기를 꾸준히 학습할 것
• CI/CD 설정 시 도전적인 시도를 해볼 것(예를 들어 GitHub AI 분석을 활용하거나, Lighthouse CI로 프론트엔드 성능 점수를 확인해 보는 것도 좋은 방법)
• 코드 중복보다는 코드 복잡도를 줄이는 방향을 선호할 것(예를 들어, if문을 적절히 분리하고 단일 책임 원칙을 유지하는 식으로 코드의 가독성과 유지보수성을 높이기)
• MSA 구조에서 프론트엔드를 위한 서버를 구성하고, 팀 단위로 독립 배포를 고려하는 것

 

 

마무리: "나는 왜 이걸 사용하는 걸까?" 기술적인 문제를 깊이 고민하고, 해결책을 찾아가며 성장한 시간

 

이번 우아콘을 다녀와서 느낀 점은, 비록 아직 현업 경험이 없는 취준생이지만 저도 작은 문제부터 하나씩 해결해볼 수 있겠다는 자신감이 생겼다는 거예요. 현재 사이드 프로젝트와 마지막 프로젝트를 진행 중인데, MSW를 이용해 서버 테스트를 해보는 것도 괜찮겠다는 생각이 들었고, 직접 Headless UI를 만들 수는 없어도 Headless UI 라이브러리를 활용해 구현해보자는 목표도 생겼어요. 그래서 이 두 가지를 지금 진행 중인 프로젝트에 적용하고 있답니다.

특히, 단순히 라이브러리나 도구를 사용하는 데서 끝나는 게 아니라, "나는 왜 이걸 사용하는 걸까?"라는 질문을 던지며 기술적인 문제를 깊이 고민하고, "그러면 내가 어떤 방법으로 해결할 수 있을까?"라고 스스로 해결책을 찾아보려는 시각이 생긴 점이 큰 수확이었어요.

이번 우아콘에 참석한 것이 정말 큰 행운이라고 느꼈고, 내년에도 꼭 다시 참석할 수 있으면 좋겠네요. 😊