안녕하세요, 배민상품시스템팀 개발자 한진욱입니다.

신규 개발자로 입사한 지 어느덧 1년이 다 되어가는데요.

1년 동안 배운 점들을 정리했습니다.

1. 비즈니스 규칙은 언제든지 변경될 수 있다.

혹시 ‘오픈서비스’라고 들어보셨나요?

2020년 4월 1일 사장님을 대상으로 출시한 배달의민족의 새로운 광고상품인데요.

외부 사정상 오픈서비스는 1달 만에 사라지고, 이전 상품(오픈리스트)로 빠르게 원복되었습니다.

openservice


당시 배민상품시스템팀은 원복 현장의 한복판에 있었습니다.

배민상품시스템팀은 오픈서비스, 울트라콜(정액제 광고상품).. 등의 광고 데이터를 다룹니다.

그래서 오픈서비스를 출시하고 원복하는 과정에서 팀의 작업 계획도 바뀌었습니다.

아래와 같은 작업들이 원복 작업에 포함되었습니다.

  • 오픈서비스 상품에 속한 광고들 종료 처리
  • 4월 1일 이전에 있었던 상품(오픈리스트) 데이터 새로 생성
  • 오픈서비스 상품 유효성 검사 삭제
  • 4월 1일 이전에 있었던 상품(오픈리스트) 유효성 검사 원복
  • 그 외..

비즈니스의 변화는 컸지만 상대적으로 코드 작업량은 크지 않았는데요.

상품의 개별 특성이 한 코드 부분에 집중되어 있었기에 작업량이 비교적 적었던 것 같습니다.

오픈서비스를 폐지하고 그 전 상품으로 원복하는 과정을 겪으면서, 비즈니스 규칙은 언제든지 바뀔 수 있다는 점을 실감했습니다.

또한 코드에서도, 비즈니스 정책은 코드 상에서 하나의 지점으로 관리하기 쉬워야 정책이 제거되는 상황에 대비할 수 있을 것입니다.

2. 백엔드 시스템도 다 같은 백엔드 시스템이 아니다.

아까도 말씀드렸듯이, 배민상품시스템팀은 광고 데이터를 다루는 팀입니다.

사장님들이 구매한 광고 데이터, 사장님들의 광고 결제 이력 데이터 등과 같은 데이터들인데요.

일반 사용자(배달의민족 앱 사용자)가 필요한 데이터는 아닙니다.

그래서 트래픽이 많지 않았습니다.

하지만 올해 6월에 팀에 광고노출 시스템이 새롭게 들어오게 됩니다.

광고노출 시스템(디비, 서버 등등)은 저희 팀이 주로 일했던 시스템(광고시스템)과 성격이 달랐습니다.

addisplay
(실제로는 광고노출시스템과 사용자 사이에 다른 시스템이 자리하고 있으며, 이해를 돕기 위해 중간 시스템을 생략했습니다.)

  1. 기술 스택이 달랐고
    • 광고시스템: mysql, spring web mvc, tomcat
    • 광고노출: elasticsearch, spring web flux, netty
      • 큰 트래픽을 위한 성능 요소가 고려된 기술들이라는게 특징입니다.
  2. 시스템 특징이 달랐습니다.
    • 광고시스템:
      • 사장님들이 구매한 광고 데이터를 관리한다.
      • 주로 다른 시스템에게 이벤트를 던져주는 쪽이다.
      • 다른 시스템으로부터 수신하는 이벤트들이 적다.
      • 적은 트래픽
        • 많으면 1분당 20,000개의 요청. 변동성이 크지 않다.
    • 광고노출:
      • 일반 사용자(배달의민족 앱 사용자)들에게 노출할 광고 데이터를 관리한다.
        • 일반 사용자들의 요청 수만큼 요청이 들어온다.
      • 이벤트를 수신하는 쪽이다.
      • 다른 시스템에게 이벤트를 던지는 일은 없다.
      • 매우 큰 트래픽
        • 저녁 피크 시간 때 1분당 90,000개의 요청. 변동성이 크다.
  3. 시스템 특징의 차이로 인하여, 일하는 방식도 차이가 있습니다.
    • 광고시스템:
      • 스프린트 일정을 자체적으로 끌고 나갈 수 있다.
        • 다른 팀 요청사항으로 인해 팀 내 일정이 변경되는 경우가 흔하지 않다.
      • 트래픽이 많지 않아, 배포 시간이 상대적으로 자유롭다.
    • 광고노출:
      • 타팀들과 긴밀하게 협업해야 하는 경우가 많다.
        • 다른 팀의 요청사항에 의해 우선순위가 바뀌는 경우가 많다.
      • 배포가 잘못되면 일반사용자에게 장애가 그대로 전달되어, 배포시간이 자유롭지 않다.

초반 반년동안 광고시스템을 봐온 저는, 광고노출 시스템을 보면서 두 시스템의 차이가 크다고 느꼈습니다.

두 시스템의 차이를 인정하면서 두 시스템을 함께 동시에 개선하는 것이 하나의 과제인 것 같습니다.

3. 개발 문화는 중요하다.

마지막으로 제가 올해 팀에서 배운 것은 개발 문화입니다.

저는 우아한형제들 교육생(우아한 테크코스) 신분일 때도 페어 프로그래밍, 코드리뷰와 같은 개발문화를 간접적으로 경험했었는데요.
(우아한테크코스 소개)

교육생 때 이런 문화가 신선하다고 생각했고, 실제 동기들과의 협업에 도움이 된다고 느꼈습니다. 하지만 당시에는 직장에서 페어 프로그래밍, 코드리뷰를 할 것이라고 생각하지 않았습니다.

우아한형제들에 입사하여 현재 팀에서도 페어 프로그래밍, 코드리뷰를 하고 있습니다.

  1. 모든 작업은 페어로 진행합니다.
    • 재택근무를 할 때는 보통 zoom으로 합니다.
    • 보통 2주에 한 번 페어가 바뀝니다. 현재 상황에 맞춰 유동적으로 페어 기간을 바꾸고 있습니다.
    • 코드를 작성하는 것뿐만 아니라, 배포 과정까지 페어로 진행합니다.
    • 2인 페어입니다.
  2. 일주일에 두 번씩 화상으로 개발자들끼리 모여서 코드리뷰를 진행합니다.
    • 코드리뷰 시간은 한시간입니다.
    • 원하는 사람이 각자 돌아가면서 코드리뷰를 합니다.
    • 페어와 마찬가지로, 재택근무를 할 때는 zoom으로 진행합니다.
  3. 상시적으로 코드리뷰를 진행합니다.
    • 도구는 upsource를 사용합니다.
    • 작업을 마치면, upsource에 작업 내용을 올립니다.
    • 매일 30분씩, upsource에 올린 내용을 보고 코드에 의견을 댓글로 적습니다.
    • 코드에 문제가 없으면, accepted 이모티콘을 표시합니다.

페어 프로그래밍, 코드리뷰를 하며 느낀 점

페어 프로그래밍, 코드리뷰를 하면서, 해당 과정 자체가 팀원들의 작업에 관심을 갖는 동기가 된다고 느꼈습니다.

페어로 작업을 진행하면, 코드를 보는 팀원은 코드를 쓰는 팀원에게 끊임없이 피드백을 줍니다.

그리고 코드리뷰를 통해서, 작업자의 리뷰에 대해 팀원 전체가 피드백을 줄 수 있습니다.

위와 같은 개발문화가 공동 책임과 시스템의 개선을 중시하는 팀 문화로 이어지는 것 같습니다.

물론 페어 프로그래밍과 코드리뷰를 하는 것이 정답이라고 생각하지는 않습니다.

제가 느꼈던 건, 좋은 개발 문화는 팀이 일하는 방식에 긍정적인 영향을 미치고, 이는 개인의 역량 발전에도 큰 도움을 준다는 점입니다.

마치며

이상으로 배민상품시스템팀에서 1년 동안 일한 신입 개발자가 배운 점 3가지였습니다.

어떻게 보면 주관적인 글이고, 그리고 기술적으로 얕은 글인데요.

다음에는 특정 기술이 주제가 되는 글로 다시 뵐 수 있었으면 좋겠습니다.

글 읽어주셔서 감사합니다!


배민상품시스템팀과 함께 하고 싶으시다면 아래 링크를 클릭하세요!

https://baeminb2b.oopy.io/0f7d128c-26de-43dd-8680-b2639b027aac