입사 후, 벌써 1년
작은 SI 회사 개발자에서 우아한형제들로 이직 1년
안녕하세요. 배민플랫폼실 결제정산개발팀에서 정산 업무를 맡고 있는 이호진입니다.
이 글은 SI 회사에서 우아한형제들로 이직한 후 1년간 있었던 변화에 대한 이야기입니다.
5월 14일, 입사 1년이 되는 날을 맞아 지난 1년을 돌아보겠습니다.
배민플랫폼실을 지원한 이유
배민플랫폼실을 지원한 가장 큰 계기는 제가 원하는 기술스택을 사용하고 있기 때문이었습니다.
SpringBoot, JPA, QueryDsl
SI 회사에서 근무하는 동안에는 해당 기술스택을 사용할 일이 많지 않았습니다.
그렇지만 위 기술스택에 관심이 많았던 저는 사내제안 및 시연 프로그램, 토이프로젝트에서 적용하며 기술적인 목마름을 해소해왔습니다.
그러다보니 대부분 혼자 만들었고 현재 만드는 방법이 잘하는건지 잘못하는건지 피드백을 받을 수가 없었습니다.
관심을 가지고 사용하고 싶던 기술스택을 요구하는 채용공고가 참으로 반가웠고 지원하게 되었습니다.
그리고 좋았던건 면접때 김영한님이 면접관으로 들어왔던 점입니다. 2015년 초부터 JPA 를 삽질하면서 고생하고 있을 때 영한님 책을 보고 어느정도 방향성을 잡을수 있었고 면접때 보고나서 지원하길 잘 했다는 생각을 했던 기억이 납니다.
회사의 기술 스택과 겹치는게 많다고 ?? 하지만…
합격 전에 영한님이 전화로 안부를 계속 물어봐주시고 기술 스택이 겹쳐서 별도로 공부하고 올건 없을거라고 꼭 합격했으면 좋겠다라고 좋은 얘기를 많이 해주셨습니다.
회사에는 돌보미라는 제도가 있는데 기존 인원이 새로 오신 분을 팀에 잘 안착할수 있게 도와주는 역할입니다.
입사 후 유명 블로거 jojoldu, (이름 비공개 해달라함) 님이 저의 돌보미여서 입사하길 잘 했다고 느꼈습니다.
몇몇 블로거들은 블로그 내용에 비해 실력이 없다라는 얘기를 많이 들었습니다. 하지만 jojoldu님은 잘하고 노력도 많이 하는것을 옆에서 보면서 자극이 많이 되었습니다.
결제정산개발팀은 ec2-gazua 라는 오픈소스를 만들고 다방면에 재능이 많은 호돌맨, 개발을 정말 잘하는 킹뽀대님, 그리고 도메인을 잘 아는 이성호님 외 한분이 계신 어벤져스 팀입니다.
잘 하면 형이라는 마인드로 형들에게 많이 물어보고 배우며 뒤늦게 성장을 하고 있습니다.
1년간 일을 하다보니 모든 SI 업체가 해당하는것은 아니지만 적어도 제가 다녀왔던 회사들에서 사용하지 않았던 방식들이 있었습니다.
SI 에서 하지 않았던 것들
1) 젠킨스 + 스프링 배치
저는 SI 업체를 다녔을때 젠킨스를 배포할때만 사용을 했고 스프링 스케쥴러를 사용하였습니다. 모니터링 화면은 별도로 간단히 구축하였고 실패 알람은 따로 받지 않았었습니다.
현재 저는 정산 업무를 맡고 있습니다. 하루 주문량 100만건 이상 일정산으로 업주들에게 돈을 지급해주고 있습니다.
그러다보니 다량의 데이터를 가공할때 특화된 스프링 배치는 정산업무에 많은 부분을 차지하고 있습니다. 정산에는 수백개의 배치가 있고 그중에 몇개는 몇 분단위로 주기적으로 돌고 있습니다.
스프링 배치의 장점이라면 읽고 가공하고 쓰는 단계로 매우 단순한 구조를 가지고 있습니다. 또한 대량의 데이터를 읽은 다음 가공하고 청크단위가 모일때까지 가지고 있다가 한번에 커밋을 하기에 속도상의 이점도 있습니다.
정산업무 특성상 IDC 를 사용하고 있어서 사양에 제약이 있습니다. 그렇기에 우리는 배치를 만들고 나서 적정량의 청크사이즈를 찾기위해 여러번 테스트를 거칩니다. 그렇게 CPU와 메모리, IO 를 적정 수준으로 유지하고 있습니다. 또한 계속적으로 늘어나는 데이터와 배치의 효율을 위해 점진적으로 개선중입니다.
그리고 젠킨스로 스케쥴 관리, 로그, 파이프라인, 실패시 Slack 또는 메일 알람 기능등 배치를 모니터링 합니다. 젠킨스에 배치를 등록하고 파라미터를 이용하여 배치를 수행함으로써 스프링 배치는 LocalDate.now() 같은 테스트시 제어하기 힘든 코드가 들어가는게 아니라 LocalDate Parameter 를 사용하기에 테스트를 잘 짤수 있는 구조가 가능했습니다. 그리고 스프링 배치의 로직을 복잡하게 하지 않고 단순하게 여러 기능으로 잘게 쪼개어서 젠킨스 파이프라인을 이용하여 여러 배치를 연결하여 사용하고 있습니다. 그렇기에 특정 배치에 에러가 발생했을시 처음부터 다시 돌리지 않고 에러난 시점의 배치부터 다시 돌려서 효율을 높였습니다.
기존에는 스케쥴링을 만들어놓고 모니터링 화면을 구축하는 등 추가 공수가 많이 들었지만 젠킨스에서 해주는 강력한 기능으로 뒤늦게 편하게 개발하는 느낌입니다.
2) JPA + QueryDSL
기존에도 언급했듯이 저는 JPA 와 QueryDSL 을 이미 사용하고 있었습니다.
하지만 규모가 작은 제안 프로그램이나 토이프로젝트에서만 써봤기에 정말 초보적인 수준에 머물러있었습니다.
제가 속한 팀에는 결제, 정산, 포인트 그리고 비즈머니 모두 JPA 로 구축되어있습니다. 입사전에 듣던 JPA 쓰면 느리지 않아? 라는 말이 무색하게 정말 하드하게 잘 사용하고 있습니다.
한방쿼리로 쿼리를 날리던 과거와는 달리 JPA 에서 가져온 데이터의 연관관계를 가지고 정말 객체지향처럼 사용하고 있습니다. 여러개의 테이블을 조인해서 디비 성능을 저하시키던 쿼리에서 IO는 조금더 발생할수 있지만 데이터를 가져와서 조립하는 형태로 디비의 부하를 줄이려고 노력하고 있습니다.
3) 집계 테이블
배치와 관련된 내용일 수 있는데 하루에 100만건의 주문이 들어오면 단순히 생각해도 1년에 3억 6천 5백만 건의 데이터가 생깁니다. 이 데이터는 하나의 주문에 대한 데이터이며 여기에 연관되어있는 많은 테이블들을 생각하면 그 양은 생각보다 많습니다. 이러한 데이터에서 특수한 목적의 데이터들로 노출하려고 하면 속도가 느릴수 밖에 없습니다.
그래서 스프링 배치를 이용하여 특수한 목적에 맞는 데이터들의 스냅샷을 생성합니다. 그렇다고 모든 화면마다 스냅샷을 만든다면 배치의 숫자가 너무 많아지고 관리도 어려워지기때문에 설계시점에 특수하지만 어느정도 범용성을 가지도록 테이블을 설계하여 사용합니다.
1년여만에 거의 2배로 오른 주문수를 따라잡기위해 기존에 만들어졌던 화면들도 필요하면 집계 데이터를 만들어서 개선작업을 하고 있습니다.
4) 결제정산플랫폼 기획팀
SI 업체에 다닐때는 고객의 요구사항에 맞춰 설계와 개발 테스트를 전부 혼자하였습니다.
그러다보니 요구에 맞는 결과가 나오기는 하지만 스트레스와 업무량이 많고 일정이 촉박해서 코드의 품질도 떨어질때가 잦았습니다.
정산업무를 하면서 다리를 펴고 잘수 있었던건 팀동료분들의 도움도 있었지만 결제정산플랫폼 기획팀의 존재가 매우 컸습니다. 유비쿼터스언어로 대화를 했어야했지만 용어정리 전부터 결제정산플랫폼 기획팀에서는 ERD의 논리모델을 가지고 대화가 될 정도로 개발자의 편의를 많이 봐주면서 적극적으로 협업을 해주고 있었습니다.
결제정산플랫폼 기획팀은 단순 기획이 아닌 몇년후의 로드맵을 그리면서 기획을 합니다. 그렇기때문에 몇년후의 정산은 어떤 모습일지 얘기를 들었고 겁이 납니다. 오랫동안 같이 했으면 합니다.
그리고 정산업무는 돈이 실제로 지급되는 최종관문이기 때문에 데이터 검증이 매우 중요한데 지금 제 맥북만큼 빠르고 정확한 분이 계셔서 안심하면서 회사생활을 하고 있습니다.
5) 그레이들 멀티모듈
우아한형제들 입사하기 바로 전 직장에서 멀티모듈을 구성해서 사용을 했으나 api, admin, common 정도의 구분이였습니다.
현재 정산에서는 9개의 모듈이 조립하기 쉬운 구조로 되어있습니다.
중복되는 코드를 여러 프로젝트에서 같이 사용할수 있고 mail 기능이나 Slack 알람같은 외부적인 설정들도 별도로 모듈로 사용하면 편리하게 가져다 쓸수 있습니다.
6) 협업 도구
제가 다녔던 회사의 협업도구는 구글드라이브, 이메일이 전부였습니다.
Jira 와 Confluence 는 입사해서 처음 써봤습니다. 그리고 Slack 도 마찬가지입니다. 이미 쓰시고 있으신분들한테는 당연한 소리처럼 들리겠지만 주변에 물어보면 사용안하는곳이 생각보다 많습니다.
이걸 사용하면서 좋은점은 이력관리, 문서관리, 알람 등 프로젝트를 하면서 전반적인 내용 파악에 매우 도움이 되고 임계치 알람을 Slack으로 받음으로써 장애에 대비를 할수 있는 좋은 경험을 하고 있습니다.
7) 코드리뷰
기존에 다니던 회사들은 코드리뷰를 안했습니다.
그런데 여기는 별로 신경 안썼던 사소한 부분까지 짚어주면서 차츰차츰 코드가 개선이 되고 추후에 비슷한것을 개발할때 해당 사항을 유념하면서 개발할수 있습니다.
처음 왔을때 다른분의 코드리뷰를 했을때와 지금 코드리뷰를 했을때 코드가 많이 세련되졌다라는 느낌을 자주 받습니다.
그만큼 코드리뷰의 성과로 코딩 스킬의 편차가 많이 줄어들었다는것을 알수 있습니다.
스타플레이어 몇몇이 모든 짐을 짊어지는것보다 여러명의 구성원들이 같이 짐을 짊어지는 모습이 더 권장되듯이 좋은 방향으로 가는 하나의 방법임에 틀립없습니다.
8) 필요한것은 직접 만드는 문화
물론 전 만들지 않았지만… 언급이 되어야할것 같습니다.
ec2 계정관리, 접속 불편 => ec2-gazua
젠킨스 데이터 처리 불편 => jenkins-plugin
애플리케이션 호출현황 필요 => spring-trace
aws 외부 자원 테스트 필요 => spring-boot-aws-mock
등 팀에서 필요한것이 있다면 직접 만들고 오픈소스로 제공하는 문화가 있습니다.
그동안 가져다 쓰기만 하다가 제공하는 사람들 틈에 있으니 저도 뭔가를 만들어서 제공해야 겠다는 생각이 듭니다.
그래서 소감은?
입사전에 워라벨에 많이 치중된 회사를 다니다보니 일을 하고 싶다
그리고 멘토, 멘티 혹은 같이 개발얘기를 할 사람이 없으신 분들. 여긴 같이 얘기할 분들이 정말 많습니다. 오시면 정말 재밌게 일할수 있습니다.
많은 분들이 오셔서 같이 개발하면 일이 재미있는 회사에서 워라벨도 보장되는 회사로 변화되지 않을까 합니다.
감사합니다!