들어가며
오늘은 딱딱한 채용공고보단 팀의 역할, 개발 문화, 기술스택 등에 대해서 자유롭게 이야기해 보려고 합니다. 🙂
메뉴시스템의 역할
메뉴시스템은 사용자 관점으로 봤을 때 세 가지 로 나눌 수 있습니다.
첫 번째, 고객 관점
배달의민족에서 주문을 시켜보신 분이라면 한 번쯤 보셨을 화면 입니다 ^^
주문할 음식을 결정할 때 크게 작용하는 메뉴 이미지, 가격, 메뉴 구성, 설명, 옵션 등등..
메뉴 관련 기초데이터를 제공하는 역할을 하고 있습니다.
여기서 잠깐~
앱에 노출되는 화면까지 팀에서 담당한다고 생각하실 수 있을 것 같은데요~
우아한형제들 시스템은 MSA 형태로 설계되어 있어서 앱에 메뉴를 노출하고 앱과 연동되는 API는 담당하는 팀이 별도로 있답니다~
메뉴시스템팀 에서는 메뉴 변경 이벤트를 발행하고 메뉴판 조회하는 API를 제공하고 있어요 ~
두 번째, 사장님 관점
메뉴는 누가 만들고 관리할까요? 바로 장사를 하시는 사장님입니다.
사장님이 메뉴를 어떻게 관리하는지 살펴보도록 할게요~
사장님은 배민사장님광장 안에 있는 기능 중 셀프서비스를 통해 아래와 같은 메뉴 작업을 할 수 있어요~
•
신메뉴가 출시된 경우 메뉴 추가
•
더 이상 판매되지 않는 메뉴 삭제 또는 숨김
•
재료가 소진된 경우 메뉴 품절
•
가격이 인상된 경우 가격 변경
•
메뉴 설명이나 구성의 변경
•
메뉴 원산지 정보 추가/변경
메뉴라는 복잡한 정보를 사장님이 쉽고 편하게 관리할 수 있도록 하기 위해 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 등을 갱신하면 프로세스가 무거워지기 마련입니다. 이를 개선하기 위해 올해 초부터 개선작업을 진행하였고 현재도 진행 중이긴 합니다~ 동기 방식에서 비동기 방식으로 시스템을 구축하고 있고 이 과정을 함께 할 수 있습니다.
어떻게 일하나요?
목적조직
•
기획자는 기획만, 개발자는 개발만 하지 않습니다.
•
기획 과정부터 개발자, 디자이너, QA가 참여하여 최선의 결과물을 만들기 위해 노력합니다.
•
위 과정을 통해 담당자들의 명확한 목적의식을 갖고 프로젝트가 진행 됩니다.
2주 단위 스프린트
•
모든 업무는 계획-분석-설계-구현-테스트-배포-운영-회고 의 순서로 진행됩니다.
•
모든 일의 시작은 JIRA 티켓으로 시작하고 생성된 티켓을 기반으로 데일리를 진행 합니다.
•
2주 스프린트가 끝나면 잘한 점, 아쉬운 점, 더 잘하고 싶은 점에 대한 회고를 진행 합니다.
페어 프로그래밍
•
개발단계 뿐만 아니라 요구사항 분석, 설계 단계도 페어로 진행 합니다. (페어 타스크 라고 부르고 있습니다)
•
보통 시니어-주니어 조합으로 페어를 진행 합니다.
이런 사람과 일하고 싶어요
•
어떤 문제를 집요하게 파고들어 해결하는 것에 희열을 느끼시는 분
•
한가지 문제로만 해결하기보다 엔지니어링의 트레이드오프를 잘 이해하는 분
•
자신이 담당한 시스템을 처음부터 끝까지 설명 가능한 분
•
같은 요청이 3번 이상 반복되는 경우 자동화를 고민하시는 분
•
특정 언어나 프레임워크보다 기본 기술에 충실하신 분
•
신기술 추종자보다 기술 발생 배경과 목적을 이해하고 계신 분
•
혼자서 빨리가 아닌 함께 제대로 가고자 하는 분
•
"나중은 오지 않는다." 를 가슴에 새기고 습관적 클린코드를 실천하시는 분
마무리
서비스 트래픽이 증가하면서 팀이 담당하는 시스템도 계속 성장하고 있습니다.
아직 부족함이 많은 팀이지만 같이 부족함을 채워갈 수 있는 분과 일하고 싶습니다~~
팀 소개글을 읽고 마음이 끓어 오른다면 바로 지원해주세요!!
그럼 면접장에서 뵙겠습니다 🙂