리멤버 서버/웹 팀은 어떻게 일을 하는가?

들어가며

안녕하세요 리멤버를 서비스하고 있는 드라마앤컴퍼니의 개발실 리더 김담형입니다.

다른 회사의 개발팀은 어떻게 일을 하고 있을지 궁금하신 적 없으신가요? 친구나 모임을 통해서 건너 듣는 얘기도 한계가 있고 회사 홍보 글도 보면 추상적인 경우가 많아서 감이 잘 안 오곤 합니다. 그래서 이번 글에서는 코드부터 Slack, Confluence 등 실제 스크린 샷을 최대한 담아 서버/웹 팀이 어떻게 일을 하는지 개발자의 입장에서 있는 그대로 보여드리려고 합니다.

이 글에서는 다음 내용을 다루고 있습니다.

• 테크 스택은 이렇습니다 – AWS, Ruby on Rails, React, UI Components
• 코드 퀄리티를 중시합니다 – 코드 리뷰와 테스트 코드
• 오버 커뮤니케이션을 지향합니다 – Slack, 업무내용 공유와 회고
• 문서화를 중요하게 생각합니다 – Jira와 Confluence

리멤버

리멤버는 국민 명함앱으로 시작하여 지금은 350만 명에 가까운 직장인 회원과 2.5억 장에 가까운 명함을 보유하고 있습니다. 350만이라는 회원 수가 많지 않아 보일 수 있지만, 전체 회원의 70%가 가장 구매력이 강한 30~40대 직장인이라는 굉장히 유니크한 사용자들이 애용하는 서비스입니다.

이런 사용자들이 모여있다 보니 채용, 네트워킹, 광고 등의 영역에서 강점을 갖고 사업을 진행할 수 있습니다. 실제로 리멤버 커리어, 리멤버 커뮤니티, 리멤버 나우, 광고 등 다양한 서비스들이 각자 시장에서 존재감을 보여주면서 커나가고 있습니다.

순조롭게 명함 관리 앱 리멤버에서 비즈니스 플랫폼의 리멤버로 진화를 하고 있으며 내년에는 각 서비스를 더 고도화해 나가면서 새로운 시도들도 계속 시도해볼 계획을 갖고 있습니다.

Team

리멤버를 서비스하는 드라마앤컴퍼니에는 2020년 말 현재, 총 80명이 넘는 구성원이 있으며 이 중 30명이 약간 안 되는 인원이 엔지니어링과 관련된 업무를 하고 있습니다. 팀들의 목록은 다음과 같습니다.

• Server/Web 팀: Front-end web 개발자와 Back-end server 개발자들이 함께 있는 팀입니다. 7명의 server 개발자와 4명의 front-end web 개발자들로 구성되어있습니다. 몇 분들은 상황에 따라 full-stack으로 개발하시는 경우도 있습니다.
• App 팀: Android 개발자와 iOS 개발자들이 함께 있는 팀입니다. 4명의 Android 개발자와 3명의 iOS 개발자들로 구성되어있습니다.
• BDC: 리멤버는 2억 장이 넘는 명함과 직장인들의 네트워크 데이터를 가진 데이터 중심 회사입니다. Big Data Center에서는 이 데이터를 수집, 정제, 가공하여 부가가치를 창출해 낼 수 있도록 하는 일을 맡고 있습니다. 데이터를 관리하고 그 시스템을 만드는 데이터 팀 개발자 2명, 머신러닝 등 데이터로 여러 실험을 하는 리서치 엔지니어 4명과 그 외 데이터를 관리, 기획 등 여러 운영 업무를 맡고 계신 비 개발자분들도 함께 계십니다.
• 그 외 리멤버 최종 서비스 품질을 관리하는 QA 팀, 보안을 책임지는 Privacy & Information Security 팀, Data Engineer 분이 계신 Data Intelligence 팀 등이 있습니다.

Tech Stack

AWS

리멤버 서비스의 99%는 AWS 위에 올라가 있습니다. 서버의 경우 EC2와 Auto Scaling Group을 많이 이용하기도 하며 Fargate에 올라가있는 서비스들도 일부 있습니다. 최근에는 서비스들을 점차 container로 옮겨가고 있는 중입니다. 웹의 경우 서버가 필요하지 않은 경우에는 CloudFront를 이용하여 serverless하게 운영하고 있습니다.

적은 인원으로 최대한 효율적으로 서비스를 운영하려다 보니 AWS의 서비스들을 최대한 많이 이용하고 있는 편입니다. AWS를 특이하게 사용하는 몇 가지 예시를 들어보면 다음과 같습니다.

• 매일 아침 리멤버 나우 수신자들을 위하여 200만대가 넘는 device에 대해 SNS Topic을 이용하여 한 번에 push를 발송합니다. Elastic Load Balancer에서 이런 traffic spike를 받아줄 수 있도록 AWS에 ELB prewarm을 요청하여 트래픽에 대응하고 있습니다.
• 테스트 코드를 직렬로 돌리기에는 시간이 너무 오래 걸려서 하나의 Jenkins master가 CodeBuild를 이용하여 필요할 때 마다 여러 개의 slave를 만들어서 테스트를 분산 처리하고 있습니다.

Ruby on Rails

현재 리멤버 API의 99%는 Ruby on Rails로 이루어져 있습니다. RoR에 대해서는 블로그 글을 이미 두 개나 적은 적이 있기 때문에 현재 저희의 생각을 단순히 요약하면 다음과 같습니다.

• 리멤버에 입사한 거의 모든 개발자들은 여기서 RoR를 처음 접해보았다.
• 최근 진행한 내부 개발자 만족도 조사 결과 대부분 RoR에 만족하고 있다.
• 하지만 더 많은 동료를 모셔오기 위하여 기존 RoR 외 새로운 기술 스택을 메인 기술 스택으로 추가하는 것에 매우 열려있다.

추가로 다음 두 글을 읽어보시면 도움이 될 것 같습니다.

리멤버 지원자분들이 묻는 질문 Top 4

Java&Spring 개발자가 Ruby on Rails 를 해보고 마주친 생각들

React

현재 리멤버 웹 사이트는 대부분 React로 이루어져 있습니다. 급변하는 웹의 기술을 계속 파악하며 Redux, Context API부터 Recoil, suspense까지 아직 실험적인 기능들까지 적용해보고 있습니다. 그 외에도 Jest를 이용한 테스트, SWR을 이용한 data fetching 등 여러 기술을 시도해보고 그 장단점을 개발자들과 함께 공유하고 있습니다. TypeScript도 올해 초 도입하기 시작한 이후에 점점 적용 영역을 넓혀가고 있으며 리멤버 커뮤니티 웹 버전은 100% TypeScript로 이루어져있습니다.

UI Components

각 항목에 대한 설명은 다음과 같습니다.

• 작업 내용: 이번에 작업한 주요 내용을 적습니다. 변경된 파일이 50개여도 사실 가장 중요한 로직은 몇 개의 파일에 모여 있습니다. 어떤 Service를 생성했다, 어떤 로직이 변경되었다 등 이 PR의 핵심 내용을 적습니다. 이것만으로도 reviewer가 전체 파일을 다 파악해야 하는 수고가 줄어듭니다.
• 스크린샷: 추가되는 기능이나 고친 버그 등을 잘 보여주는 스크린샷을 첨부합니다. API의 경우 스펙 문서가 있지만 클라이언트는 화면이 상황을 이해하는 데 훨씬 도움이 되는 경우가 많습니다.
• 링크: 기획 문서, 디자인 문서, API 스펙 문서, JIRA 이슈 등 관련 있는 모든 링크는 다 추가해둡니다.
• 기타 사항: 고민했던 지점이나 변수명, 기획자와의 의사 결정 내용 등 이 코드가 만들어지게 된 배경 있다면 모조리 적습니다. 작업자가 어떤 생각으로 이 코드를 작성했는지 물어보고 답변받는 시간을 많이 줄일 수 있습니다.
• Merge 전 필요 작업: 스키마 변경이나 의존성이 있는 다른 서비스가 선배포 되어야 하는 등 중요한 작업을 잊지 않기 위해 적어둡니다.
• 희망 리뷰 완료 일: 급한 이슈인지, 천천히 봐도 되는 이슈인지 희망 일정을 적어두어 서로 리뷰 일정을 조율하는 데 도움을 줍니다.

Test Code

서버 개발자들이 관리하는 주요 프로젝트들의 테스트 커버리지는 약 90%, 총 테스트 수는 약 9,000개가 넘습니다. 공통된 로직을 최대한 추출하고 Rspec 프레임웍과 FactoryBot, Faker 라이브러리를 적극적으로 활용하여 최대한 짜기 쉽고 유지보수가 가능한 코드를 작성할 수 있는 환경을 구축해두었습니다.

웹에서는 일부 프로젝트에 대해 테스트 코드를 적용하고 있습니다. Jest와 React Testing Library를 같이 사용하여 로직과 컴포넌트를 같이 가진 컨테이너 정도의 규모로 통합 테스트를 진행하고 있습니다. 최대한 단위 테스트당 필요로 하는 API mock의 개수를 최소한으로 가져가고 있고, 필요한 데이터는 FactoryBot의 JS 버전이라 할 수 있는 Rosie와 Faker 라이브러리를 조합하여 사용하고 있습니다. 하지만 아직 완벽한 테스트 코드 작성 방식을 찾지 못했기 때문에 더 나은 방식을 고민하고 있습니다.

Over-communication

리멤버를 서비스하는 드라마앤컴퍼니에서 전사적으로 항상 강조하는 소통 문화는 over-communication입니다.

"모든 내용은 투명하게 공개하자" 그리고 "DM으로 할 얘기는 팀 채널에서 하고 팀 채널에서 할 얘기는 전사 채널에 공유하자"라는 기조로 커뮤니케이션을 진행하고 있습니다. 이런 over-communication을 통해서 회사의 정보를 동기화하고 개개인이 더 주체적이고 효율적으로 일할 수 있는 데 많은 도움을 받고 있습니다.

Communication tool로는 Slack, Confluence, Jira를 적극 이용하고 있습니다.

Slack

#public-서버_웹

public- prefix가 붙은 채널들은 특정 팀에 요청할 때 이용하는 채널들입니다.

보통 다른 팀에서 요청할 때 보면 가장 부탁을 잘 들어줄 것 같은 사람한테 DM을 많이 하게 됩니다. 이러면 그 사람은 엄청 바쁜데 주위 사람들은 인지를 못하거나 여러 명이 같은 요청을 받아서 똑같은 일을 하는 상황이 비일비재하게 발생합니다. 이런 문제도 해결하고 over-communication을 위하여 사내 대부분의 팀들은 public 채널을 운영하고 있습니다.

해당 채널에는 CS 처리, 운영 처리, 개발 질문 등 정말 다양한 내용이 올라옵니다. 내가 궁금하지 않더라도 다른 사람이 얘기한 메시지를 보고 "오 이런 것도 가능하구나!" 하는 경우도 있고 질문하시는 분들도 더 빨리 답변을 받을 수 있습니다. 가끔은 해당 팀이 아닌 다른 팀원 분이 대답을 해주시는 경우도 있습니다 😂

#internal-서버_웹

internal- prefix가 붙은 채널들은 팀 내부용 소통 채널들입니다.

서버/웹 팀의 경우 채널 내에서 잡담, 업무 얘기, IT 소식, 개발 의견 나누기 등 다양한 얘기를 많이 하는 편입니다.

나와 직접적으로 상관이 없는 일이더라도 많은 분들이 언제나 적극적으로 thread에서 여러 의견을 주시곤 합니다.

#noti-pull-request, #noti-hook-api, #noti-hook-web

noti- prefix가 붙은 채널들은 시스템 알림 등이 들어오는 채널입니다.

Jenkins build 결과, GitHub PR comment, PR request 등 의 내용들이 noti- 채널들로 들어옵니다.

업무 내용 공유

저희는 confluence에 매주 페이지를 만들어서 매일 모든 팀원이 작업한 내용을 적고 있습니다. 이는 개인의 업무 내용을 객관적으로 기록하기 위한 목적인데요, 분명히 정신없는 한 주를 보냈는데 금요일 누가 와서 "이번 주 뭐하셨어요?"라고 물어봤을 때 꿀 먹은 벙어리가 되신 적 많지 않으신가요? 내가 어떤 일을 하느라 바빴던 건지, 어떤 문제가 있지는 않은지 파악하기 위하여 이 문서를 작성합니다. 연말에 올해 했던 일들을 뒤돌아보는데도 매우 유용합니다.

적는 칸은 총 네 가지로 나누어져 있습니다.

• 계획된 업무: 대부분의 업무 내용은 여기에 포함되어야 합니다. 다만 계획된 업무에 여러 업무가 오랜 시간 반복되어 보인다면, 일을 하나씩 끝내는 게 아니라 너무 많은 일을 동시에 벌여 리드 타임이 길어지고 있는 문제일 수 있습니다.
• 계획에 없던 업무: 여기에 속한 내용이 많으면 안 됩니다. 계획된 일정과 무관하게 갑자기 들어오는 업무가 많거나 장애 등 다른 문제가 있다는 뜻입니다.
• CS 업무: 여기에 같은 내용이 많이 추가된다면 어드민에 기능을 추가해야 한다는 뜻일 수 있습니다.
• 공유사항: 휴가 등 다른 분들이 알면 좋을 내용을 적습니다.

추가로 이 문서에서 JIRA label과 issue filter를 이용하여 이번 주에 진행될 작업, 백로그, 이번 주에 배포될 내용을 확인할 수 있습니다.

회고

과거를 돌아보고 다음에는 어떻게 하면 더 잘 할 수 있을지에 도움이 되는 회고 문화는 개발자 뿐만 아니라 회사 전체에 매우 깊게 뿌리 잡혀있습니다. 짧으면 매주, 길면 큰 프로젝트가 끝날 때마다 회고를 진행하고 있습니다.

서버/웹 팀은 매주 금요일마다 회고를 진행합니다. 회고 전에는 다음과 같은 서베이에 답변을 하게 됩니다.

• 이번 주 좋았던 점: 여기서 나온 내용을 기반으로 어떻게 하면 더 즐겁게 일에 집중할 수 있을지 알아내고자 합니다.
• 이번 주 아쉬웠던 점: 어떤 문제가 있거나 해당 팀원이 본인과 맞지 않은 일을 하는 것일 수 있습니다. 어떻게 하면 이런 일이 덜 일어나게 할지 알아내고자 합니다.
• 기타 얘기해보고 싶은 주제: 모두 모여있을 때 얘기해보고 싶은 주제를 적습니다.

위 서베이에 적힌 내용을 기반으로 약 1시간 정도 모여서 본인의 얘기를 하고, 상대방의 얘기에 대한 본인의 생각을 얘기하거나 함께 얘기해보고 싶은 주제에 대해서 논의합니다.

1 on 1

1 on 1의 경우 매달 최소 30분씩 진행합니다. 1 on 1을 통해 팀원과 리더가 서로를 더 잘 이해하면서 생각의 격차를 줄일 수 있고 신뢰도 쌓을 수 있게 됩니다. 또한 평소에 쉽게 얘기하지 못했던 이야기나 피드백들을 주고받을 수 있는 시간이 됩니다. 1 on 1도 마찬가지로 미팅 시간 전에 다음과 같은 서베이를 받고 해당 내용을 기반으로 대화를 나눕니다.

문서화

문서화 작업을 하는 데는 크게 세 가지의 목적이 있습니다.

• 미래에 누군가(나를 포함) 이 이슈를 돌아봤을 때 어떤 일이 있었는지 알 수 있도록 합니다.
• 타인과의 커뮤니케이션을 더 명확하고 원활하게 할 수 있도록 합니다.
• 작업하는 사람이 작업 이전에 생각을 정리하고 빠트리는 부분이 없도록 도와줍니다.

모두 문서화를 잘 해주고 계시지만 그렇다고 형식을 맞추기 위해 작업하는 비효율적인 문서 작업을 하지는 않습니다. 간단하게라도 남들이 이해하기 쉽게, 핵심 내용만 잘 적어두면 됩니다.

Jira

제품 개발팀의 모든 일은 Jira 이슈로 관리합니다. 타 팀에서 요청을 주실 때도 Jira 이슈를 생성하여 담당자를 할당합니다.

이렇게 생성된 Jira 이슈의 번호는 커밋 메시지, Confluence 제목, 코드 주석 등 모든 곳에 적히게 됩니다.

운영 업무 등으로 잠깐 만들어서 실행한 스크립트들도 모두 Jira 코멘트에 적어두고 있습니다.

또한 Jira의 코멘트를 통해 기획자, 디자이너, 다른 개발자분들과 소통하면서 대화 이력을 남겨두고 있습니다.

Confluence

좀 불편할 때도 있지만 Jira와 너무 연동이 잘되는 confluence를 함께 이용하고 있습니다.

설계 문서나 Jira에 적기에는 너무 양이 많거나 복잡한 업무 내용은 confluence를 이용합니다.

동료

리멤버의 강점이라고 얘기하면 언제나 자신 있게 "동료"가 가장 처음으로 떠오르게 됩니다. 서버/웹 팀 1 on 1에서 "회사를 만족하면서 다닌다면 어떤 이유로?"라는 질문에 매달 가장 많은 답변은 "훌륭한 동료와 일할 수 있어서"입니다. 전사 서베이에도 늘 빠지지 않은 문항이기도 합니다. 모든 직군에서 동료 한 분 한 분을 정말 신중하게 모시다 보니 단기간에 많은 분을 모시지는 못하지만 이렇게 합류하신 분들은 정말 훌륭한 분들입니다.

열심히 무언갈 시도하거나 노력할 때 옆에서 누가 "귀찮게 뭘 그런걸 해 그냥 하던 대로 하자"라는 얘기를 해서 힘 빠지는 경험을 해보신 적 한 번씩은 있을 텐데요, 그만큼 동료가 정말 중요하다고 생각합니다.

동료분들 모두 어떻게 하면 리멤버가 더 잘 될 수 있을까 계속 고민하시고 먼저 주체적으로 여러 아이디어를 제안해주시거나 크고 작은 시도들을 하시는 모습을 자주 볼 수 있습니다. 서버/웹 팀 동료분들도 내일 할 것 없이 적극 의견을 제시해주시고

https://dramancompany.com/team 에서 저희 전체 동료에 대한 설명과 몇몇 분의 인터뷰를 확인하실 수 있습니다.

업무 구조

리멤버에서는 기능 조직(서버, 웹, AOS, iOS, 기획, 디자인, QA 등)과 목적 조직(광고, 리멤버 커리어, 리멤버 커뮤니티 등)이 함께 있는 매트릭스 조직 형태로 일하게 됩니다. 목적 조직은 Crew와 Base camp로 나누어집니다.

Crew

저희는 회사와 조직을 "배"로 자주 비유를 하는데, 그러다 보니 자연스럽게 특정 미션을 해결하기 위한 목적 조직을 Crew라고 칭하고 있습니다. Crew는 광고, 커리어, 컨텐츠 처럼 특정 도메인이나 서비스를 맡게 됩니다. 각 crew에는 Product Owner와 파트별로 기능 조직원들이 함께 일합니다. 인원이 4명도 안 되는 작은 크루부터 15명이 넘어가는 큰 crew도 있습니다.

각 crew는 맡은 미션에 맞게 phase마다 OKR을 세우고 그 미션과 목표를 완수시키기 위해서 모든 집중을 다합니다.

Base camp

Base camp는 Crew들이 미션 완수에 집중할 수 있도록 도와주며 다음과 같은 일들을 합니다.

1. Crew에 부족한 기능 조직 파트의 업무 지원
2. Crew들이 공통으로 사용하는 것들 개선 (A/B 테스팅, 로그 시스템, 인프라, 가이드 문서 등)
3. 새로운 crew가 조직되기 전에 아이템에 대한 가능성 테스트

Crew가 종료되어 귀항하면 자동으로 base camp의 소속으로 있다가 다시 새로운 Crew가 결성되어 출항을 하게 되는 경우 필요한 사람들끼리 티밍이 되어 모험을 떠나게 됩니다.

채용

이 글의 결론입니다. 제가 지금 설명들인 업무 방식을 함께 개선해나가면서 리멤버의 본게임인 비즈니스 플랫폼을 만들 분들을 모시고 있습니다. 현재 서버/웹 팀에서는 서버 개발자, 플랫폼 서버 개발자, 웹 개발자를 채용 중에 있습니다. 자세한 job description과 지원 방법은 https://dramancompany.com/joinus 에서 확인하실 수 있습니다.

이 글을 읽어보고 관심이 생겼지만, 더 궁금하거나 자세히 알아보고 싶은 부분이 있으시다면 제 이메일인 [email protected] 로 언제든지 편하게 연락해주셔도 됩니다. 캐쥬얼한 티 미팅도 자주 진행하고 있으니 부담 갖지 마시고 연락 주시면 감사하겠습니다 😁