벌써 한달
미리디에 백엔드 개발 인턴으로 출근한지 벌써 한달이 지났다. 첫 출근 후기를 작성한것이 엊그제 같은데 시간 참 빠르다. 오늘은 그 동안 내가 미리디에 대해서 알게된 것들과 내가 했던 작업들을 정리하기 위해 글을 작성한다.
첫 출근과 요즘 출근의 차이점
내 생활 패턴에 있어서 가장 차이나 나는 부분은 출퇴근 시간이다. 첫날에는 9시까지 출근이었는데, 집과 거리가 조금 있다보니 7시 반쯤에 출발해야 여유있게 도착할 수 있었다. 문제는 이 시간대가 지옥철 정점이기 때문에 앉아서 가는건 상상도 할 수 없고, 사람들 사이에 꽉 껴서 출근하지 않으면 다행이라는 점이다. 나는 또 열이 많아서 이런 출근철을 도저히 견딜 수 없어 9to6에서 10to7으로 출퇴근 시간을 늦췄다. 9시에서 10시 사이 자율 출퇴근을 인턴에게도 적용해줘서 너무 행복하다. 덕분에 이제 지하철에서 전체 구간 절반 정도는 앉아서 갈 수 있다.
입사한지 2주 정도가 되었을때부터는 남아서 공부도 하기 시작했다. 전에는 아무래도 사람들도 잘 모르고하니 어색해서 칼퇴했었는데, 이제는 남아서 공부하는 팀원들을 따라 나도 공부하기 시작했다 ㅋㅋㅋ. 내 업무에 도움이 될만한 공부를 위주로 하다보니 최근에는 유닛 테스트와 객체지향, 그리고 캐싱에 대해서 공부하고 있다. 그래서 요즘엔 보통 10시 반정도에 퇴근하고 있다. 출근-퇴근-잠을 반복하는 생활인데, 오히려 배우는 것도 많고 뿌듯해서 나는 좋다.
미리디에 대해 알게된 점
1. 야근이 없다
백엔드 개발자는 야근과 당직이 당연한 것으로 알고 있어서 난 미리디도 그럴줄 알았다. 한달 동안 다니면서 느낀점은 야근을 할일이 생기는 것이 상상되지 않는다는 것이다. 특정 주기로 서비스를 계속 배포하는데, 프로덕션 배포 전 항상 QA 기간을 거치기 때문에 대부분의 문제들이 이때 잡힌다. 프로덕션에서 문제가 발생해 고객 문의가 들어오는 것도 업무 시간내에 들어오기 때문에, 진짜 크리티컬한 문제가 아닌 이상 야근을 할일이 없다. 서비스 특정상 특정 시간에 트래픽이 몰리지도 않기 때문에 당직 같은 것도 딱히 없다.
2. Atlassian 제품을 적극 활용한다
깃 레포는 Bitbucket, 문서화는 Confluence, 이슈 트래킹은 Jira, CI/CD툴은 Bamboo를 사용한다. 이 제품들을 따로따로 보자면 개인적으로 BitBucket 보다는 Github, Confluence보다는 Notion, Bamboo보다는 Github Action을 선호한다. 하지만 확실이 한 회사의 제품들을 사용하니 연동이 좋아서 편한부분들도 있다.
3. 스포티파이 모델로 일한다
스포티파이의 엔지니어링 문화과 유사하게 팀이 구성되어 있다. 기본적으로 특정 목적을 위한 작은 팀 단위인 스쿼드로 이루어져 있다. 스쿼드끼리는 가깝고 오픈되어 있는 공간에서 일하면서 서로에게 편하게 소통을 한다. 처음에는 너무 산만해서 집중이 안되지 않을까봐 걱정했는데 어떻게 잘 돌아간다;; (물론 인턴인 나를 찾은 일은 크게 없기 때문에 나만 그렇게 느끼는걸수도 있다) 이게 왜 잘 되는지에 대해서는 나중에 더 생각해봐야겠다.
4. 매주 스터디 시간이 있다
매주 특정 요일에 업무 시간 중 스터디가 있다. 어떠한 주제를 정하고 진행되는 것은 아니고 개인이 공부한 내용이나 서비스 전체가 고민해봐야할 내용, 또는 일을 하면서 있었던 이슈를 공유하는 시간이다. 공부-정리-공유를 할때 가장 빠르게 성장할 수 있다고 생각하기 때문에, 너무나 마음에 드는 방식이다. 실제로 나도 스터디때 당신의 Checked Exception은 필요없다를 가지고 발표하는 등 참여하기도 했다. 너무 재밌닿
5. 서비스가 매우 빠르게 성장하고 있다
2020년도에 처음 사용해보고 이후로도 몇번 사용하면서 입사 전에 미리 캔버스 서비스를 사용해본적이 있다. 당시에 조금 버그가 있지만 편한 서비스라고 생각했었는데, 입사하고 나서 내가 맨 처음 사용했을때가 서비스 출시 극초기라는 걸 알게 됐다;; 당시에는 가입자 100만도 안됐던거 같은데, 2021년 4월에는 200만명을 달성하고, 지난달에는 500만명을 넘었다. 이제 곧 학기가 시작하면 또 가입자가 급격히 늘것 같은데, 얼마나 늘어날지 기대된다.
한달 동안 내가 한 일
1. 검증 로직 추가 및 예외에 대한 고민
가장 먼저 담당한 이슈는 요청에서 특정 문자열 데이터에 대해 길이를 검증하는 로직을 추가하는 것이었다. 이 길이의 경우 나는 비즈니스 로직이라고 생각해 도메일 모델의 생성시점에 검증하도록 했다. 검증 로직 자체야 매우 간단하지만 해당 데이터를 가질 수 있는 도메인 모델이 10개가 넘었고, 각 모델이 무엇인지 조차 잘 모르고 있었기 때문에 조금 헤맸었다; 이 이슈를 담당한 덕분에 어떤 모델들이 있고, 무엇인지 도메인을 이해할 수 있었다. 한가지 아쉬운점은, 검증 실패시 커스텀 예외를 던지도록 구현했는데 그렇게까지 할필요는 없었던거 같다. 괜히 관리 포인트만 들어난거 같아 다음에 그냥 guava precondition을 사용하도록 수정해야겠다.
내 코드를 머지하고 나서도 문제가 조금 있었다. 해당 데이터는 기존에 딱히 검증을 딱히 하지 않았었는데 내가 검증을 추가하면서 QA 분들께 테스트를 요청하게 되었다. 그러자 기존에 있었던 문제들이 발견되어 나한테 이슈가 들어왔다 ㅎㅎ;;
2. 유닛 테스트 작성
별도 이슈를 받았던 것은 아니지만 위 이슈를 담당하면서 유닛 테스트도 많이 작성했다. 기존에 내가 테스트 코드를 작성하는 방식은 컨트롤러단은 @SpringBootTest를 통한 통합 테스트를 하고 서비스와 도메인 모델은 메소드 단위로 유닛 테스트를 작성하는 것이었다. 하지만 회사의 코드는 내가 기존에 많이 작성하던 controller-service-repository 보다는 더 복잡하고 추가적인 레이어도 있어 그대로 적용하기에는 무리가 있었다. 또 아무래도 실제 서비스이다 보니 코드가 쌓여 리팩토링이 필요한 부분들도 좀 있는데, 어떻게 해야 리팩토링에 안전한 테스트 코드를 작성할 수 있을지 고민됐다. 그래서 최근에는 블라디미르 코리코프의 단위 테스트 책을 읽고 있는데, 조만간 정리해서 회사 스터디에서도 공유하고 블로그에도 포스팅할 것 같다.
3. 캐싱 문제 해결
모종의 이유로 현재 백엔드 단에서 캐시를 write-through 할 수 없는 상황이다. 그래서 데이터를 업데이트 했음에도 불고하고, 이후 조회시 업데이트 이전의 캐싱된 데이터를 반환하기 때문에 해결이 필요했다. 다른 사람들에게 새로운 데이터가 즉각적으로 보일 필요는 없고, 업데이트를 수행한 사람한테만 변경 내용이 보이면 돼서 일단은 프론트가 캐시 사용 여부 플래그를 보내는 것으로 해결하기로 했다. 스프링의 Cache Abstraction을 사용 중이라 컬렉션의 개별 객체 캐싱이 어려워 약간 우회하는 방식으로 하고 있어 이 부분에 대해서도 이야기를 나눠봐야 한다.
4. 데이터 마이그레이션
일부 데이터를 다른 데이터베이스에서 관리하다가 이제 우리쪽 DB에서 관리하기 위해 이전 작업 중에 있다. 따라서 조회를 위해 외부로 요청을 보내던 API가 우리쪽 DB로 요청을 하도록 변경하고 있다. 내가 하는 작업은 이 부분이지만 단순 테이블 마이그레이션 뿐만아니라 S3도 우리쪽 저장소를 사용하게 하는 등 사실상 업로드 시스템을 갈아끼웠다;;
한달 후기
뭔가 열심히 많이 한거 같은데 막상 정리하고 보니 별로 많이 한거 같지는 않다. 나름 현직자(?)가 되고 나니 가장 크게 느낀 점은, 결국 모든 일은 공수 대비 효용을 생각하면서 해야한다는 점이다. 모든 코드를 테스트하고, 예외를 깔끔하게 로깅하기 위해 커스텀 예외를 작성하고 등등 물론 다 좋지만 기대효용에 비해 공수가 너무 많이 든다면 좋지 않은 것 같다. 우리는 엔지니어니까 이상과 효율 그 사이 어딘가에 밸런스를 잡으려고 하면서 일하자!
👀 잘 보고 갑니다 총총