왜 크런치 모드...?
기존 우리 회사 제품을 SaaS로 전환하기 위해 7월 3주간 크런치 모드에 들어가게 되었다. 최대한 빠르게 우리 제품을 AWS에 올리는 것이 목표였고, AWS는 물론이고 클라우드 환경, 그리고 기존 프론트엔드 개발자에서 백엔드 개발자로 전환되면서 아는 것이 하나도 없는 뇌까지 제로 베이스에서 시작하는 프로젝트였다. 7월 말까지 제품 출시라는 목표가 있었고 7월 초부터 조금씩 기획이 완성되었기 때문에 일정이 굉장히 빠듯했다.
백엔드 개발
백엔드로 넘어오면서 개인적으로 좋았던 점은
- 테스트 코드 작성이 쉬움
- 더 깔끔하게 코드 작성이 가능
테스트 코드 작성이 쉬운 것과 깔끔한 코드 작성이 쉬운 것은 굉장히 개인적인 의견이고, 아직 백엔드에 대해 자세히 모르기 때문일 수도 있는데, 프론트엔드 개발을 할 때는 디자인 기획 상 어쩔 수 없는(?) 하드 코딩과 테스트의 기준 및 예시를 찾기가 힘들었는데 적어도 지금 개발하고 있는 스프링 부트에서는 단위 테스트 및 스프링 통합 테스트 환경을 만들고 테스트 하는 것이 굉장히 쉽게 느껴졌다. 그리고 시니어 급의 팀원이 있어서 배울 수 있는 환경이 조성된 것이 백엔드로 넘어오며 가장 좋은 점이었다.
백엔드로 넘어오며 아쉬웠던 점도 역시 있긴 한데
- 프레임워크 선택지가 좁음
- 프론트엔드보다는 개발 전 설계가 중요
이 역시 내 개인적인 생각인데, 프론트엔드에서는 리액트, 뷰, 앵귤러 당장 생각 나는 것만 해도 세 가지인데, 백엔드 자바 진영에서는 스프링 밖에 없는 것 같아서 다른 것과 비교할 수 없는 부분이 조금 아쉬웠다. 그리고 프론트엔드의 경우 빠르게 개발하고 다시 수정하는 것이 편했는데 백엔드는 아무래도 DB와 붙어 있기 때문에 DB 설계에 많은 시간을 들여야 했다.
무엇을 했는지
인증
나는 주로 인증/인가와 관련된 작업을 했다. AWS의 Cognito 서비스를 사용했기 때문에 실제로 구현해야 할 부분은 그렇게 많지 않았지만, 우리의 상황에 맞게 Cognito를 사용해야 했기 때문에 Cognito에 대해 공부해야 했다. Cognito를 사용해 회원 관리를 했지만 우리도 결국 회원에 대한 정보를 가지고 있어야 하기 때문에 Cognito와 우리 서비스를 연결하는 연결 다리로 AWS Lambda 함수를 사용했다. Cognito에서 회원가입이 이루어지면 Lambda가 우리 서비스로 회원 정보를 전달한다.
추가로 구글 회원 가입, 통합을 진행했는데 Cognito에서 자체적으로 third party idp 기능을 제공하고 있어서 약간만 커스터마이징 했고, 아직 Cognito에서 가지고 있는 계정 통합 이슈는 기획적으로 풀어냈다.
reCAPTCHA
이렇게 한 일들을 적어보니 우리 서비스라기 보다 외부 서비스를 호출하고 사용하는 일을 주로 진행해왔다는 것을 알게 된다. 로봇이 아님을 인증하는 리캡챠 서비스를 사용하기로 결정이 되었고, 이를 우리 서비스에 적용하는 작업을 진행했다. OAuth2.0과 비슷해서 크게 어려움 없이 적용 가능했다.
초대
가장 애를 먹었던 부분이다. 초대를 할 때 기존에 회원 가입이 되어 있는 유저는 초대 링크만 메일로 전송하고, 만약 회원 가입이 되어 있지 않을 경우 계정 생성 + 메일 전송을 모두 해야 했다. 결국 또 Cognito와 연관되는 부분이 발생하게 되는데, 처음의 나는 우리 서비스에서 Cognito를 바라보는 것을 원하지 않았다. 아까 위의 인증 부분에서의 회원 가입은 "브라우저 -> Cognito -> 우리 서비스" 의 단계를 거치기 때문에 Cognito는 우리 서비스를 알아야 하지만 우리는 Cognito를 알 필요가 없기 때문에 문제가 되지 않았는데, 초대의 경우는 그 반대이기 때문에 어떻게 하면 우리 서비스와 Cognito의 연관성 없이 초대를 구현할 수 있을지 고민했다.
내 생각은 Lambda를 사용한 초대 구현이었다. Lambda에 Cognito에서 회원을 체크하는 로직을 두어 만약 이미 회원 가입 되어 있는 계정일 경우 바로 우리 서비스의 초대를 호출하고, 만약 없다면 계정을 새로 만들고 우리 서비스의 초대 API를 호출하는 방법을 생각했다.
이 방법으로 Lambda를 구현했는데 코드가 굉장히 지저분했다. 그래서 결국 우리 서비스에서 Cognito를 알고 있는 방식으로 전환하게 되었다. 최종적으로 "브라우저 -> 우리 서비스 -> 조건부 Cognito 호출"로 변하게 되었다.
배운것
테스트 코드의 가치를 배웠다. 새로 오신 직원분께서 테스트 코드를 강조해주셔서, 그리고 좋은 테스트 코드까지는 아니더라도 돌아가는 테스트 코드를 따라서 작성한 과거의 나에게 감사했다. 코드 수정 사항이 생기고 신규 기능을 추가할 때 이 테스트 코드가 주는 심적인 안정감은 절대 무시하지 못한다. 특히 리팩터링에 자신감이 붙어 더 좋은 코드에 대해 고민할 수 있었다.
테스트 코드를 작성하면서 더 좋은 테스트 코드에 대한 고민이 생기게 되었다. 특히 한 서비스에서 다른 서비스를 호출하거나 의존성을 가지고 있을 때, 특히 AWS 서비스와 같은 외부 서비스를 사용하고 있을 때 테스트 코드에서는 외부 서비스를 실제 호출하지 않을 수 있는 방법에 대해 고민했고, AWS와 같은 외부 서비스를 별도의 컴포넌트로 분리해 이를 mock bean으로 만들어 테스트 하는 방식으로 수정했다. 이렇게 하니 기존 서비스 코드도 더 깔끔해졌고 테스트도 가능해졌다. 테스트 하기 좋은 코드가 좋은 코드라는 것을 몸소 알게 되는 시간이었다.
AWS에 대해 굉장히 많이 배웠다. 인증과 관련해 여러가지 방법을 생각하며 API Gateway, Cognito, Lambda, DynamoDB, S3 등의 서비스를 직접 사용해 볼 수 있었고 왜 사용하는지에 대해서 조금은 알 수 있었다. 이런 하나하나의 개별 서비스보다 나는 ECS에 대해서 알아보고 싶은데 기회가 주어지길 기다려본다.
마무리
체력적으로 굉장히 힘들었다. 막판에는 몸이 안좋아지는 것이 너무 느껴졌다. 말이 9시 출근 8시 퇴근이지 사실 8시 퇴근한 적이 손에 꼽고 빨라야 9시 반쯤 들어갔던 것 같다. 막차가 끊겨서 택시를 타고 퇴근하고, 집에 들어가면 12시가 넘는데 다음날 9시까지 출근하려면 6시 기상해야하는데 수면이 부족하고 다시 다음날 늦게 퇴근하고... 악순환의 반복이었다. 내 몸에게 너무 미안했다.
체력적으로 굉장히 힘들었지만 그래도 버틸 수 있던 것은 같이 일하는 동료가 있었기 때문인 것 같다. 작년에 비슷한 일이 있을 때는 혼자 일하는 것 같아서 외로웠고 내가 일을 떠맡아 진 것 같아서 많이 분노했었는데, 같이 짐을 지고 갈 수 있는 동료들이 있어서 감사했다. 그리고 크런치 모드 마지막 이틀을 내가 휴가로 런했는데도 불구하고 조심히 다녀오라는 팀원들과 팀장님께 너무 미안하고 감사했고 나도 저런 넉넉한 마음이 생기기를 바랬다.
크런치 모드 분석
- 잃은 것
- 건강
- 애사심
- 얻은 것
- 팀워크
- 실력
이렇게 분석해보니 얻은 것이 잃은 것보다 조금 커보인다. 다행이다. 크런치 모드의 후유증으로 이후에 일에 몰두하는 것이 조금 어려운데 뭔가 보상이 주어졌으면 하는 마음이다. 휴가 3.5일을 받기는 했지만 여전히 휴가를 몰아 쓰기는 좀 그렇고, 금전적인 보상이나 아니면 조금 쉬어갈 수 있는 환경이 마련되었으면 좋겠다. 하지만 크런치 모드가 끝난지 한 달이 넘어갔는데도 그런 것은 없었다... 건강은 회복 되었는데 애사심이 회복되지 않는다. 어떻게 하면 다시 이전의 열정을 살릴 수 있을까?
