2.png

메뉴시스템팀

들어가며

오늘은 딱딱한 채용공고보단 팀의 역할, 개발 문화, 기술스택 등에 대해서 자유롭게 이야기해 보려고 합니다. 🙂

메뉴시스템의 역할

메뉴시스템은 사용자 관점으로 봤을 때 세 가지 로 나눌 수 있습니다.

첫 번째, 고객 관점

Untitled.png
Untitled.png
배달의민족에서 주문을 시켜보신 분이라면 한 번쯤 보셨을 화면 입니다 ^^
주문할 음식을 결정할 때 크게 작용하는 메뉴 이미지, 가격, 메뉴 구성, 설명, 옵션 등등..
메뉴 관련 기초데이터를 제공하는 역할을 하고 있습니다.
💡
여기서 잠깐~ 앱에 노출되는 화면까지 팀에서 담당한다고 생각하실 수 있을 것 같은데요~ 우아한형제들 시스템은 MSA 형태로 설계되어 있어서 앱에 메뉴를 노출하고 앱과 연동되는 API는 담당하는 팀이 별도로 있답니다~ 메뉴시스템팀 에서는 메뉴 변경 이벤트를 발행하고 메뉴판 조회하는 API를 제공하고 있어요 ~

두 번째, 사장님 관점

메뉴는 누가 만들고 관리할까요? 바로 장사를 하시는 사장님입니다.
사장님이 메뉴를 어떻게 관리하는지 살펴보도록 할게요~
menu_self.gif
사장님은 배민사장님광장 안에 있는 기능 중 셀프서비스를 통해 아래와 같은 메뉴 작업을 할 수 있어요~
신메뉴가 출시된 경우 메뉴 추가
더 이상 판매되지 않는 메뉴 삭제 또는 숨김
재료가 소진된 경우 메뉴 품절
가격이 인상된 경우 가격 변경
메뉴 설명이나 구성의 변경
메뉴 원산지 정보 추가/변경
메뉴라는 복잡한 정보를 사장님이 쉽고 편하게 관리할 수 있도록 하기 위해 UX에 신경을 많이 쓰고 있지만 아직도 부족함이 많습니다 ^^

세 번째, 운영자 관점

메뉴셀프서비스에 익숙하지 않은 사장님을 위해 메뉴운영센터를 두고 있고 이곳에서 사용하는 관리자 시스템을 개발하고 있어요~
메뉴셀프서비스와 다른 점이라면 하루에도 수십/수백 들어오는 요청을 빠르고 정확하게 처리 해야 하므로 생산성과 효율성에 포커싱 되어있습니다.
메뉴를 조금 더 빠르게 등록할 수 있도록 단축키를 지원한다거나 메뉴 복사 기능 등 생산성을 향상 시키는 요소를 제공한다는 것이 큰 차이점이라고 할 수 있습니다.

기술스택

메뉴시스템 팀은 아래와 같은 기술 스택으로 개발이 진행되고 있습니다.

공통

언어 : Java8, Node.js 10.x
인프라 : AWS 를 100% 사용합니다
EC2 : Api, Worker, Batch 모든 프로세스는 ec2로 구성됩니다
SNS, SQS : 메뉴 변경 이벤트를 발행하기 위해 사용합니다
Elastic Cache (Redis) : 자주 사용되는 메뉴 정보를 캐싱 합니다
RDS (Aurora) : 메뉴 정보를 영속적으로 보관합니다
Lambda (with node.js) : 서비스에 주요한 로직이 아닌 (모니터링, 캐시 갱신 배치) 경우에 사용하고 있습니다
S3, CloudFront : html, js, css 등 정적파일을 제공하기 위해 사용합니다.
버전관리 : Git (gitlab) / Gitflow 를 따릅니다

백엔드

Web & Was
Nginx
Tomcat
Framework & Library
Spring Boot 2.1.x
Spring Data JPA
Spring Security
Query DSL
Lettuce
Mybatis : JPA로 해결이 불가능한 복잡한 SQL에 대해서만 사용하고 있습니다
API Docs
Swagger2
Spring rest docs
Test : Junit 5 (일부 Junit4도 있음)
Build & Deploy
Gradle
전사 배포 플랫폼
Monitoring
CloudWatch
Grafana
Pinpoint
Kibana

프론트 엔드

JavaScript(ES6) / TypeScript
React / Redux Toolkit(Redux) / Redux Saga / mobx
Webpack / Babel

개발자로서 얻을 수 있는 것들

고가용성 시스템 설계 경험
가용성이 높은 시스템을 만들기 위한 여러가지 고민을 할 수 있습니다.
DBMS나 CACHE 서버에 문제가 생겨도 서비스 이슈가 생기지 않는 방안을 찾고 고민할 수 있습니다.
중요도가 높은 API에 수정 배포를 해야 하는 경우 성능테스트와 Fallback 테스트를 필수로 진행 합니다.
대용량 트래픽에 대한 경험
오두막을 짓는 방법과 고층 아파트를 짓는 방법이 다르듯 시스템도 규모에 따라 설계와 문제 해결 방법이 완전히 다릅니다.
API 하나를 만들더라도 트래픽에 대한 고민을 통해 대용량 트래픽 설계 능력을 기를 수 있습니다.
이벤트 + 비동기 시스템 설계 경험
메뉴 변경이 될 때마다 동기방식으로 DB, CACHE 등을 갱신하면 프로세스가 무거워지기 마련입니다. 이를 개선하기 위해 올해 초부터 개선작업을 진행하였고 현재도 진행 중이긴 합니다~ 동기 방식에서 비동기 방식으로 시스템을 구축하고 있고 이 과정을 함께 할 수 있습니다.

어떻게 일하나요?

모든 업무는 계획-분석-설계-구현-테스트-배포-운영-회고 의 순서로 진행됩니다.
분기가 시작될 때 팀원 한자리에 모여 백로그 플래닝 회의를 합니다. 그 회의에서 가장 우선순위가 높은 일감을 선정하고 2주 단위 스프린트로 계획하고 일을 진행합니다.
모든 일의 시작은 JIRA 티켓을 생성하고 JIRA로 워크플로우를 관리합니다. 문서화가 필요한 경우 Confulence 로 문서를 작성합니다.
팀 내 기획, 개발(프론트, 백엔드), QA, 메뉴운영자가 모여 명확한 목적의식을 갖고 서비스를 만들어 갑니다.

이런 사람과 일하고 싶어요

어떤 문제를 집요하게 파고들어 해결하는 것에 희열을 느끼시는 분
자신이 담당한 시스템을 처음부터 끝까지 설명 가능한 분
같은 요청이 3번 이상 반복되는 경우 자동화를 고민하시는 분
특정 언어나 프레임워크보다 기본 기술에 충실하신 분
신기술 추종자보다 기술 발생 배경과 목적을 이해하고 계신 분
혼자서 빨리가 아닌 함께 제대로 가고자 하는 분
"나중은 오지 않는다." 를 가슴에 새기고 습관적 클린코드를 실천하시는 분

마무리

서비스 트래픽이 증가하면서 팀이 담당하는 시스템도 계속 성장하고 있습니다.
아직 부족함이 많은 팀이지만 같이 부족함을 채워갈 수 있는 분과 일하고 싶습니다~~ 팀 소개글을 읽고 마음이 끓어 오른다면 바로 지원해주세요!!
그럼 면접장에서 뵙겠습니다 🙂
Made with 💕 and Oopy