작년에 이어 올해도 운 좋게 우아콘에 참여했습니다. 올해는 프론트엔드 세션에 특히 관심이 많아 네트워킹도 했지만 세션에 더 집중했습니다. 세션 영상은 유튜브로 볼 수 있지만, 끝나고 연사님과 직접 이야기하는 경험은 개발 컨퍼런스만의 큰 장점이라고 생각합니다. 프론트엔드뿐 아니라 배달의민족이 새로운 서비스를 런칭할 때의 프로덕트·PM 관점도 함께 듣고 싶어 관련 세션도 챙겼습니다.
고객의 편리함을 완성하는 프로세스, 배민 사용자경험관리
경험의 일괄성은 ‘중앙 정렬 + 문서화 + 빠른 공유’로 만든다. UI·UX 자체도 테스트의 대상이다.
회사 서비스와 사이드프로젝트 모두 ‘보기 좋은 UI’가 아닌 ‘사용하기 편한 UI’로 만들고 싶다는 고민으로 찾은 세션입니다.
배달의민족은 여러 팀이 동시에 기능을 개선해도 경험의 일관성을 지키기 위해 전담 TF를 운영한다는 사실을 알았습니다.
특히 ‘배민클럽’ 사례가 인상적이었습니다. 같은 이벤트를 다루는데도 팀마다 설명이 달라서, 사용자 입장에선 정보가 들쭉날쭉한 상황에서 TF가 중앙에서 전체 플로우를 정렬하고, 회의 직후 핵심 내용을 문서로 정리해 전사에 빠르게 공유하면서 “모두가 같은 그림”을 갖게 만들었습니다.
또, 저는 그동안 테스트를 기능 검증에만 한정해 생각했어요. 그런데 발표를 듣고 보니 UI·UX 자체도 테스트의 대상이더라고요. 개발 과정에서 놓치기 쉬운 사용자 흐름의 끊김, 동일 정보의 표현 불일치 같은 문제는 코드 밖에서 생기지만, 결국 경험의 품질을 좌우하니까요. 규모가 커질수록 이런 관리가 더 중요해진다는 것도 실감했어요.
막연하던 UX 최적화를 중앙 정렬 → 문서화 → 공유라는 실행 단계로 시작해볼 수 있겠다는 생각이 들었습니다. 아직 실제로 도입하기엔 시간이 걸리겠지만 방향성을 잡을 수 있었던 시간이었습니다.
로그 회귀 테스트 구축으로 데이터 기반 비즈니스 지키기
기능 테스트뿐 아니라 의사결정을 위한 로깅 데이터의 회귀 테스트가 필요하다.
이번 컨퍼런스에서 개인적으로 가장 의미 있었던 세션이었어요. 단위/통합/E2E는 익숙했지만 회귀 테스트의 실전적 필요성을 이번에 제대로 이해했습니다. 핵심은 새 기능 추가 후 기존 기능이 깨지지 않았는지 확인하기 위해 기존에 통과한 테스트를 정기적으로 재실행하는 것입니다.
발표에선 로그 데이터를 예로 들었는데, 초기에 잘 쌓이던 로그가 어느 순간부터 버그로 쌓이지 않으면서 지표로 쓸 수 없게 된 일이 있었다고 해요. 로그 누락이나 과다는 단순 개발 이슈를 넘어 성과 지표 왜곡으로 이어질 수 있어서 위험하죠.
예를 들면, 서비스 오픈 직후 유저가 폭증하는 상황에서 로그가 2배로 찍히는 버그가 생겼다가 나중에 고쳐지면, 통계상으론 성과가 반토막 난 것처럼 보이는 착시가 생겨요. 실제 운영은 정상화했는데 숫자는 악화되는, 아주 곤란한 상황이죠. 그래서 배달의민족은 회귀 테스트를 체계적으로 운영하고 있었어요. 핵심은 회귀 테스트가 별도의 체계를 새로 만드는 게 아니라, 단위·통합·E2E로 쌓인 테스트 자산을 주기적으로 재실행한다는 점이었어요.
발표에서 공유된 로깅 회귀 테스트 흐름은 이렇습니다.
- 테스팅 라이브러리로 로깅 컴포넌트를 렌더링하고
- 사용자 이벤트로 로그 전송을 유발한 뒤
- 전송되는 로그 API를 MSW로 모킹해서 payload를 캡처하고
- 그 payload를 스냅샷 테스트로 관리해 사이드 이펙트 변화를 추적해요.
겉보기엔 우리가 하던 테스트와 크게 다르지 않지만, “지표 레이어(로그)”까지 테스트 범위를 끌어올렸다는 점이 실전적이었어요.
배민 퀵커머스 성장을 위한 프로덕트 전략: 익숙함을 넘어 새로운 탐색으로
직관보다 데이터 기반의 가설 → 실험 → 지표 검증 → 회귀/개선 사이클.
원래는 “우아한 디버깅 툴: QA 이슈 해결에 필요한 데이터를 쉽게 주고, 받자” 세션을 들을 계획이었지만, 좌석 부족으로 대신 본 이 세션이 예상외로 큰 인사이트를 얻었습니다.
배달의민족이 장보기∙쇼핑 화면을 어떻게 구성해야 고객 유입과 전환을 높일 수 있는지, 실제 실험 사례를 통해 접근법을 공유했죠.
특히 숏컷(바로가기) 중심 → 콘텐츠 중심으로 개편했을 때, 의도와 달리 사용성이 떨어지는 역효과가 발생했던 점이 인상적이었는데, 작은 UI·정보 구조 변경도 고객 행동에 큰 비중으로 작용할 수 있음을 다시 확인했습니다.
직관보다 데이터를 기반으로 가설 → 실험 → 지표 검증 → 회귀/개선의 사이클을 돌릴 수 있는 환경이 무척 부러웠고, 우리 팀에 어떻게 도입할지 고민이 깊어졌습니다. 그동안은 “테스트에 쓸 시간 부족”과 “지표를 검증할 만큼의 트래픽 부재”를 이유로 마음만 있었지 실행하지 못했는데, 현재 진행 중인 사이드 프로젝트는 선택과 실험의 자유도가 높으니, 여기서 먼저 사이클을 적용해보고 검증된 방식을 팀에 역으로 이식해보려 합니다.
장보기∙쇼핑 가게홈 성능 최적화 고군분투기: 웹 전환 과정에서의 경험과 교훈
웹뷰 기반 전환에서 CSR, 레이지 로딩, 크리티컬 스크립트, 코드 스플리팅 등을 통해 FCP/LCP를 개선.
성능 개선은 개발자라면 누구나 끌릴 수밖에 없는 주제라, 저도 거의 홀리듯이 세션을 보게 됐습니다. 특히 웹뷰를 앱에 도입하는 과정에서 마주한 성능 이슈를 어떤 방식으로 해결했는지, 그리고 그 결과가 FCP·LCP 등 핵심 지표로 어떻게 드러났는지 구체적으로 확인할 수 있어 인상적이었습니다.
처음에는 SSR 기반 웹뷰로 시작해 앱에 적용했고, 이후 CSR 전환을 통해 성과를 끌어낸 과정, 그리고 이미지 레이지 로딩, 크리티컬 스크립트, 코드 스플리팅 같은 최적화 기법을 “문제 → 해결 → 성과” 흐름으로 풀어낸 점이 특히 도움이 됐습니다. 이론으로만 알고 있던 기법들이 실제 사례로 연결되면서 도입 판단의 근거를 더 분명히 잡을 수 있었거든요.
앞서 “배민 퀵커머스 성장을 위한 프로덕트 전략” 세션과 마찬가지로, 데이터 기반 의사결정이 문제 해결의 중심에 있는 모습을 보며 저 또한 업무 중 의견을 낼 때 충분한 근거를 갖추고 있었는지 돌아보게 됐습니다.
발표가 끝나고 연사님과 대화를 나누며, 생각보다 많은 영역에서 웹뷰(WebView)가 활용된다는 점도 새로 알게 됐습니다. 작은 메뉴 버튼에 복잡한 애니메이션을 적용하거나 재배포 없이 디자인을 바꿔야 하는 상황 등에서 웹뷰가 효과적이었습니다.
이 밖에도 최적화 측면에서 얻은 인사이트가 많았지만, 글이 길어질 것 같아 회고는 여기까지 정리하겠습니다.