개발 파트 소개 - 1. 백엔드 파트
안녕하세요.
인프랩의 향로입니다.
저희 인프랩 개발팀은 현재 백엔드, 프론트엔드, 모바일, 데브옵스 파트로 나뉘어져 있습니다.
각각의 개발 파트가 어떻게 일 하는지, 어떤 사람과 함께 하고 싶어하는지 등을 소개드리려 합니다.
첫 번째로 백엔드 파트를 소개드리겠습니다.
지원하고자 하는 회사의 백엔드 개발자 채용 공고를 본다면 일반적으로 다음과 같은 궁금증이 생깁니다.
- 같이 일하게 될 사람들은 어떤 사람들일까?
- 배포 프로세스는 어떻게 될까? 자동화가 되어있을까?
- 코드리뷰는 하고 있는걸까? 서비스 기능 개발하기에 바빠서 각개전투 하는건 아닐까?
- 백엔드 역량 향상이 가능할 정도의 유의미한 트래픽이 발생하고 있을까?
- 테스트 코드를 작성하고 있을까?
- 모니터링과 로깅은 제대로 구축되어있을까?
- 구성원의 성장을 위해 회사에서는 어떤 지원을 해줄까?
개발자의 성장에 있어 가장 중요한건 개인의 노력인데요.
그렇다면 회사에서 해줄 수 있는 것은 무엇일까요?
제 생각에는 그 사람이 성장할 수 있는 좋은 재료와 환경을 제공해주는 것이 아닐까 싶습니다.
지금부터는 인프랩의 백엔드 파트를 소개드리려고 합니다.
이런 환경이라면 좋은 개발자로 성장할 수 있지 않을까 생각해보는 시간이 되셨으면 합니다.
직군 소개
현재 인프랩 백엔드 팀은 1년차부터 10년차까지 총 8명의 개발자로 이루어져있습니다.
이 8명의 인프랩 백엔드 개발자는 24시간 365일 장애 없는 서비스 환경 구성과 데이터 기반의 비즈니스 로직 개발을 담당합니다.
(출처: https://www.instagram.com/p/CQXLFvODOfF/)
- NodeJS 기반으로 백엔드 비지니스 로직을 개발하고 배포합니다.
- 데이터 성격에 맞게 PostgreSQL과 Redis, MongoDB Atlas에 데이터를 적재하고 이용하는 코드를 작성합니다.
- SEO를 위한 Server Rendering과 Client Rendering을 위한 API를 설계하고 개발합니다.
- 여러 백엔드 개발자들이 협업하기 좋은 코드로 지속적으로 리팩토링합니다.
- 테스트 코드 기반의 개발을 진행하며, 타입지향, 정적분석등 같이 협업하는 분들의 심리적 안정감을 주기 위해 노력합니다.
- 온라인 PR, 오프라인 페어프로그래밍 등 코드리뷰를 통해 성장하는 문화를 지향하고 있습니다.
- 데이터베이스의 실행계획 (
Explain
) 을 통한 인덱스 설계/수정과 슬로우 쿼리에 대한 튜닝 등을 진행합니다. - 모니터링 서비스인 Datadog을 적극적으로 사용하여 시스템에서 발생하는 모든 이슈 사항에 대해서 추적하고 해결합니다.
이외에 인프런 백엔드팀의 개발자들은 어떤 고민들을 하고 있고, 어떤 문제들을 해결하기 위해 노력하고 있는지는 아래 기술 블로그를 통해 확인할 수 있습니다.
기술 스택
현재 백엔드 기술 스택은 크게 2가지로 나눠져있습니다.
- 현재 대부분의 인프런 기능을 담당하고 있는 기존 시스템
- 새 기술 스택으로 기존 기능을 하나씩 이관 중인 신규 시스템
각각의 기술 스택은 목적에 맞게 다르게 구성되어 있습니다.
기존 시스템 스택
- NodeJS / JavaScript
- Express
- FxJS
- 함수형 라이브러리
- FxSQL
- SQL Builder
- Date-fns
- AWS Lambda를 통한 스케줄링 & 배치 환경
- Circle CI를 통한 배포 환경
- FP 로만 이루어진 애플리케이션 설계와 구조
신규 시스템 스택
- NodeJS / TypeScript
- Nest.js
- Mono Repo (Multi Module) 을 사용하고 있습니다.
- TypeORM / MikroORM
- Jest / SuperTest
- AWS LocalStack
- AWS 서비스를 로컬 테스트 하기 위해
- js-joda / ts-jenum
- Docker Compose를 통한 개인 개발 환경
- Jenkins를 통한 스케줄링 & 배치 환경
- Jenkins / Github Action 를 통한 배포 환경
- OOP / 도메인 기반의 애플리케이션 설계와 구조
- FP를 버리는 것이 아니라, FP가 필요한 영역과 OOP가 필요한 영역을 조화롭게 사용합니다.
이외 인프라 요소는 두 시스템 모두 비슷한 형태를 취하고 있습니다.
- Docker
- DataDog 모니터링
- AWS Aurora PostgreSQL, Elastic Cache Redis, MongoDB Atlas
- AWS ECS (Fargate, EC2) & EC2
- Git/GitHub
- Webstorm / VSCode / DataGrip
- JetBrains사의 전제품을 지원하고 있어 개인이 원하는 제품을 사용하도록 권장하고 있습니다.
신규 시스템의 기술 스택과 기존 시스템의 기술 스택이 조금 차이가 있는데요.
인프랩 서비스는 초기에 빠르게 성장하기 위해 가장 익숙한 방법으로 열심히 달려왔습니다.
(원피스 - 고잉 메리 호)
시간이 지나 조금 더 규모가 있는 서비스로 확장하려다보니 다음과 같은 고민을 하게 되었습니다.
- 신규 입사자의 러닝커브
- IDE 지원
- 자동완성, 코드추적, 리팩토링 등
- 타입안정성
- 개발자 시장 Pool
- Third Party 라이브러리 호환성
- 규모가 있는 커뮤니티
그래서 신규 시스템의 기술 스택은 이 부분을 해결하기 위한 것으로 선택하였습니다.
(원피스 - 사우전드 써니 호)
기존의 기술 스택을 신규 기술스택으로 전환하는 과정을 제대로 경험해보실 수 있습니다. 현재도 구성원분들과 함께 신규 기술 스택에 대한 스터디를 진행하고 있습니다.
업무 방식
스타트업 특유의 빠른 제품 릴리즈와 서비스 안정성 이라는 2마리 토끼를 최소한의 인원으로 잡기 위해 적절히 업무 균형을 유지하고 있습니다.
- Confluence / Jira를 도입하여 문서화를 적극적으로 진행하고 있습니다.
- 설치형을 사용하지 않고, Cloud 버전을 사용해 관리 리소스를 최소화 하고 있습니다.
- 특정 개인에게 의존하는 위험도를 낮추고, 신규 입사자분들의 심리적 안정감을 위해 개발파트 전체가 문서화에 적극 참여하고 있습니다.
- 장애 내역과 그에 대한 해결 사례를 남겨 전체 구성원의 역량을 끌어올리려고 노력하고 있습니다.
-
정기적인 스프린트를 통해 업무 공유와 회고를 주기적으로 진행합니다.
- 본인이 속한 Cell (스쿼드) 에서는 2주 단위의 스프린트를, 개발 조직 전체는 주 1회 모여 개발 작업들을 공유합니다.
- 스프린트 방식 자체에 대해서도 주기적으로 회고를 진행합니다.
- 어떤 방식이 가장 효율적이고 성과를 낼 수 있을지 정기적으로 고민하고 논의합니다.
-
이슈 관리 도구인 JIRA 기반으로 업무를 진행합니다.
-
Git Flow를 변형한 저희만의 Git Flow에 맞춰 Branch 를 생성하고 Rebase / Merge 등을 진행합니다.
- 작업된 코드는 PR (Pull Request) 을 요청하고 코드리뷰를 진행하여 반영하고 있습니다.
- 모든 PR (Pull Request) 은 정적 분석 도구인 소나큐브(SonarQube) 와 연동하여 코드 퀄리티를 보장합니다.
- 신규로 진행되는 프로젝트들은 모두 테스트 코드 작성을 필수로 하고, 최소 커버리지 기준을 두어 테스트 코드역시 관리 대상으로 보고 개선합니다.
- 개발된 코드는 테스트서버에 배포를 하여 QA를 진행합니다.
- 모든 배포는 Jenkins를 통해 dev / master 브랜치 push 시에 자동으로 ECS로 배포가 진행됩니다.
- PostgreSQL에서 발생하는 Slow Query에 대해 슬랙 알람을 걸어두고, 매번 쿼리 튜닝과 사내 가이드 문서를 작성합니다.
- DataDog Log와 APM을 통해 서비스 장애 알람을 수신 받고, 대응합니다.
- 6개월에 한번씩 제품 개발 파트 전체 회고를 진행합니다.
- 진행했던 과제에 대한 소개와 아쉬운점/개선점등을 이야기합니다.
- 다음 반기에 진행할 과제들을 정리합니다.
- 이를 통해 제품 릴리즈에 몰두하느라 방향성을 잃는 일이 없도록 중심을 잡고 있습니다.
백엔드 개발자로서 얻을 수 있는 것들
채용공고를 작성하면서 가장 많은 고민을 했던 부분인데요.
이 글을 보시는 분들이 수많은 시리즈 A이상의 스타트업들과 대기업들 사이에서 인프랩에 백엔드 개발자로서 합류해야할 이유는 무엇일까 곰곰히 생각해보았습니다.
- 다양한 도메인을 경험해볼 수 있습니다.
- 일반적으로 큰 기업에서 백엔드 개발자는 깊게 한가지 역량에 집중하게 됩니다.
- 마이크로서비스 아키텍처로 인해 각 도메인팀이 분리되어있다면 그럴 확률이 더 높습니다.
- 반면에 인프랩은 현재 백엔드 개발 파트가 서비스 전체의 백엔드를 다루고 있습니다.
- 강의, 영상 스트리밍, 채용, 커뮤니티, 블로그, 결제/정산등의 커머스, 이벤트를 통한 갑작스런 트래픽 대응 등 백엔드 개발자가 익혀야할 전반적인 역량을 익힐 수 있습니다.
- 현재 일부 서비스는 분리된 형태로, 일부 서비스는 단일 Repository에서 관리되어 있어, 대형 프로젝트와 분산 서비스를 동시에 경험할 수 있습니다.
- 일반적으로 큰 기업에서 백엔드 개발자는 깊게 한가지 역량에 집중하게 됩니다.
- 안정적으로 성장하는 서비스를 경험해볼 수 있습니다.
- 현재 인프랩은 매년 50~300%의 서비스 성장을 하고 있습니다.
- 최근 4분기에는 분기 흑자를 달성 하였습니다.
- 지속적으로 성장하는 서비스에서 발생하는 기술 부채와 사업적 성장 그 중간 지점을 조율하면서 성장하는 방법을 배울 수 있습니다.
- 다양한 레거시 개편 경험을 얻을 수 있습니다.
- 이미 안정화된 서비스에서는 개편을 경험하기 쉽지 않은데요.
- 더이상 이 코드와 구조로는 버틸수 없다는 판단하에 레거시를 개편하는 것은 성장하는 스타트업에서만 경험해볼 수 있는 희귀한 경험입니다.
- 기술 스택과 패러다임 변경이 예정되어있어 전체 구성원이 함께 공부하는 문화가 있습니다.
- 매주 수요일마다 테크 리뷰시간을 가져 기술적인 내용을 공유하고, 학습하는 문화가 있습니다.
- 팀 전체가 학습하고 성장하는 문화가 시작되고 있어, 같이 시작해볼 수 있습니다.
마무리
예전에 즐겨보던 백종원의 골목식당에서는 (거의) 매번 가게주인분께 여쭤보는 질문이 있습니다.
”쉴틈없이 손님들이 방문하면 어떻게 할 것이냐?”
저는 이 부분이 백엔드 개발자에게 항상 필요한 질문이라고 생각하는데요.
일단 실행되는 백엔드 애플리케이션을 만드는 일은 쉽습니다.
요즘은 특히 인터넷에 튜토리얼이 있기에 더욱 그러합니다.
여기서 인프런을 떠올리셨다면 가산점++
그러나 협업하기에 좋은 방식으로, 성능과 안정성까지 고려한 백엔드 애플리케이션을 만드는 개발은 쉽지 않습니다.
모니터링 / 로그관리 / 테스트하기 좋은 구조 / 테스트코드 등 사용자분들은 못느끼지만 실제 운영 레벨에서 중요한 점들이 백엔드에서는 더 많은 비중을 차지합니다.
현재 인프랩은 데이터와 사용자가 적었을때 효율적이었던 방식들이 서비스가 성장하면서 더이상 효율적이지 않다는 것을 매일 경험하고 있습니다.
이런 경험은 이 시기에만 경험할 수 있기 때문에 같이 경험해보았으면 합니다.
긴 글 끝까지 읽어주셔서 감사합니다.
이 글을 읽고 저희 팀에 관심이 생기셨다면, 인프랩 채용 공고 를 확인해주세요.