grep

Culture

2년차 개발자와 함께하는 전시개발팀 탐방기

Teemo Lee여기어때

2022년 3월 22일

원문에서 보기 ↗

안녕하세요. 여기어때 전시개발팀에서 서비스 인터페이스를 개발하고 있는 티모입니다. 여기어때에 입사하고 적응하기까지 많은 분들의 도움을 받았기에, 미래의 젊은이(여기어때에서는 회사 임직원을 ‘젊은이'로 부릅니다.)분들을 위한 글을 쓰면 좋겠다는 마음으로 작성하게 되었습니다.

이번 글은 개발 문화 그리고 팀 소개를 하는 글인 만큼 가볍게 읽어주시면 좋겠습니다. 더불어 이 글을 작성하기까지 많은 도움을 주신 전시개발 팀원 분들께 감사의 말씀을 드립니다.

모든 업무의 시작은 티켓으로부터…

전시개발팀은 1주 스프린트를 통해 애자일하게 개발하고 있어요. 스크럼은 애자일 방법론 중 하나인데요. 스크럼 안에 1~4주 단위로 스프린트를 나누어 개발하는 방법이에요.

큰 작업은 Epic(큰 틀) 안에서 일주일 안에 완료할 수 있는 단위로 작게 쪼개고, JIRA 티켓을 만들어 관리하고 있어요. 예를 들어, 한 작업이 4주가 걸린다고 하면 총 5개의 JIRA 티켓이 생기는거죠!(스프린트 내에 작업할 티켓 4개, Epic 티켓 1개)

스프린트를 하면 계속 진행 사항을 체크하면서 스스로 계획을 짤 수 있어 일을 체계적으로 할 수 있다는 장점이 있습니다.

저희 팀은 매일 오전 10시에 데일리 미팅을 하고, 매주 수요일 11시에는 스프린트 회고를 하고 있어요.

데일리 미팅에서는 각자 어떤 업무를 하고 있는지 공유하고, 스프린트 회고에서는 우리가 잘한 일, 더 잘했어야 하는 일, 놓치고 있는 것들을 체크합니다.

리뷰 없이는 단 한 줄의 코드도 머지 할 수 없다.

전시개발팀은 모든 커밋을 리뷰해야 한다는 대원칙이 있어요. 공백, 주석 제거와 같은 간단한 커밋도 리뷰 없이는 서버에 반영할 수 없습니다.

전시개발팀 리뷰어들은 리뷰 할 때 어떤 부분을 중점적으로 볼까요?

이중에서도 [코드를 작성한 의도, 클린 코드, 예외를 발생시키는 코드]가 가장 많이 언급되었어요.

코드 리뷰를 제대로 해 본 경험은 여기어때에 입사하고 처음인데요. 아무래도 첫 MR이 가장 기억에 남아요. 리뷰어 분들이 발생할 수 있는 예외에 대해 잡아주셨는데, 코드 리뷰가 없었다면 장애가 발생할 수도 있었겠죠?

젊은이는 개발만 해, 배포는 자동이니까!

여기어때는 Development, QA, Stage, Production 환경으로 구성되어 있어요. Development는 개발 테스트를 위해 배포하고, QA는 QA분들이 테스트할 수 있는 환경이에요. Stage는 Production과 비슷한 환경으로 실제 서비스 전에 다시 한번 체크하는 용도입니다.

Stage나 Production은 웬만하면 자동 배포를 하지 않구요. Development나 QA는 Merge event가 발생하면 자동으로 배포됩니다.

CI/CD 툴은 공통적으로 Jenkins를 사용하고 있어요.

다만, 기존 프로세스는 프로젝트를 JAR로 묶어 올리는 것만 지원하고 있어서 전시개발팀은 올해 모든 프로젝트를 컨테이너화하는 것을 목표로 EKS를 도입하는 과정 중에 있습니다. (이와 관련해서 저희 팀 팡이 최근 Docker 스터디를 진행해 주셨어요. 이론과 실습을 동시에 배울 수 있는 유익한 시간이었습니다. 이 글을 빌려… 고마워요 팡!!👍)

Oncall

여기어때는 효율적인 모니터링을 위해 Oncall로 대응자를 정하고 있어요. 각 팀에서 1차 대응자와 2차 대응자를 뽑습니다. 대응자들은 업무 시간 외에도 알림을 주시해야 하는데요. 1차 대응자가 주 대응자로, 장애 발생 시 내용을 확인하고 담당자에게 공유해요. 2차 대응자는 1차 대응자가 부재 시 그 역할을 대리합니다.

전시개발팀은 매주 수요일을 기준으로 로테이션하고 있어요. 저는 입사 후에 딱 한 번 온콜 대응을 했던 적이 있는데요. 첫날에 잔뜩 긴장해서 새벽까지 잠을 이루지 못하고 슬랙만 쳐다봤던 기억이 나네요.. 다행히 큰 문제없이 지나간 일주일이었습니다.

여기어때의 복지

집과 회사의 거리가 꽤 있다보니 출퇴근할 때 대중교통을 이용하면 왕복 4시간 정도가 소요되는데요. 여기어때는 현재 재택근무를 기본으로 하고, 출근할 때는 출퇴근 택시비와 점심, 저녁 식대를 지원해 주고 있어요. 덕분에 출퇴근길이 부담스럽지 않습니다!

재택근무 시에는 회사의 장비를 사용할 수 없잖아요. 그래서 모니터, 키보드, 마우스를 따로 지원해 주고 있습니다. 저는 모니터 하나를 지급받아 듀얼 모니터로 사용하고 있는데, 굉장히 만족스럽습니다.

또, 업무와 관련된 도서나 온/오프라인 강의비를 지원해 주고 있어요. 저는 평소에 관심 있던 MSA, DDD, Spring 책들을 구입해 읽고 있습니다.

전시개발팀은 주로 어떤 책을 구입할까요?

이중에서도 Java, Spring, MongoDB와 관련된 책을 많이 구입하시네요!

회사 측에서 직원의 발전을 위해 여러 가지로 힘쓰고 있다는 점이 느껴지죠? 저도 더 열심히 일해야겠다는 생각이 듭니다.

전시개발팀은 무슨 일을 하나요?

여기까지 읽으셨다면 도대체 전시개발팀은 무슨 일을 하나 궁금하실거라고 생각합니다. (맞죠?)

전시개발팀은 서비스 인터페이스 개발 파트와 데이터 동기화 파트로 나누어지는데요. 팀 안에서는 서비스 인터페이스 개발 파트를 YB, 데이터 동기화 파트를 OB라고 부르고 있어요.

왼쪽부터 오스카, 포프(팀장), 엉, 티모, 브라이스

YB는 여기어때 웹과 앱에 필요한 API를 개발하고 있습니다. 타 플랫폼 API를 통해 필요한 데이터를 가져오고, 이를 융합하여 하나의 데이터로 만드는 것이 주 업무인데요. 앱에서 발생하는 모든 데이터는 YB의 서비스를 거쳐가기 때문에 여기어때의 Gateway 역할을 하는 팀입니다.

YB의 서비스는 모든 트래픽을 받는 구간이기 때문에 최적화가 중요한데요. 한 번 받은 파라미터는 캐시에 저장해서 일정 시간 동안 같은 요청이 들어올 경우 저장된 데이터를 보내주면서 트래픽 관리를 하고 있어요. 이때 Redis를 사용합니다.

사용하는 기술에는 Java, Spring Boot, Spring WebFlux, JPA, MyBatis, MySQL, Redis 등이 있어요. 아직 Java로 전환하기 전인 PHP로 구성된 API도 있는데요. 올해 모든 API를 Java로 전환하는 것이 목표입니다.

왼쪽부터 팡, 웨이드, 주드, 리버

여기어때에는 호텔, 펜션, 리조트 상품을 판매하는 호텔타임 앱도 있는데요. 여기어때에서 관리하는 상품과 호텔타임에서 관리하는 상품은 각각의 다른 데이터베이스에 존재하고 있어 두 데이터를 동기화하는 작업이 중요해요.

OB는 호텔타임 데이터와 여기어때 데이터의 싱크를 맞추는 Syncer, 숙소 상품 데이터를 MongoDB에 적재하는 Builder를 개발하고 있습니다. YB에서 개발하는 API 중 상품과 관련된 데이터들은 모두 OB에서 생성한 MongoDB 데이터를 사용하고 있어요. OB는 데이터베이스와 사용자를 이어주는 Bridge 역할을 하는 팀입니다.

사용하는 기술에는 Java, Spring Boot, Spring WebFlux, RxJava, MongoDB, MySQL, AWS SQS/SNS, LogStash, Couchbase, EKS가 있습니다.

여러분은 YB와 OB 중 어느 파트에서 일해보고 싶으신가요?

우리가 같이 일하고 싶은 동료는요

팀원들과 위 주제에 대해서 이야기했던 날, 많은 의견이 나왔지만 공통점은 [실력보다는 됨됨이]였습니다!

저희 팀은 기술적인 부분보다는 함께 성장하는 것을 중요하게 생각하기 때문에, 앞으로 입사하실 미래의 젊은이 분들도 같은 마음이었으면 좋겠습니다! 제 글이 작게나마 도움이 되었으면 좋겠네요. 긴 글 읽어주셔서 감사합니다.