조금 늦은 2022년 회고를 써보려고 한다. 써야지 써야지 생각은 했지만 계속 실천으로 옮기지 못했는데, 역시 나는 적당히 바빠야 시간을 더 내는 사람인 것 같다.
상반기
2022년 상반기는 2021년과 비슷하게 보냈다. 회사에서 내 포지션은 프론트엔드였고, 여전히 AngularJS를 사용한 유지보수를 진행했다. 그래도 회사에서 SaaS 전환을 시도하게 되면서 내게 스프링 부트 + 리액트 조합을 사용한 회원가입 / 로그인 프로토타입을 만들어보라고 해서 알지 못하던 스프링과 자바를 공부할 수 있어서 좋았다.
ID와 PW를 사용한 로그인 외에 구글/네이버/카카오 로그인을 붙이면서 OAuth의 동작 원리들을 이해할 수 있었다. 이 작업을 하면서 외부 API를 사용하는데 자신감이 많이 붙었다.
하반기 1
상반기에는 위의 내용이 전부인데 하반기는 일로 꽉 찬 시간들을 보냈다. 조직 개편이 이루어지면서 SaaS 전환을 본격적으로 시작하게 되었고, 나는 SaaS Backend 팀으로 이동하게 되었다.
개발을 진행하면서 빠르게 개발하는 것과 좋은 아키텍처를 고민하며 좋은 코드를 만드는 것 사이에서 계속 타협을 해야했다. 당장 급한 기능들을 구현하면서 중복 코드와 값을 스트링으로 그대로 넣는 질 나쁜 코드들을 생성할 때도 많았고, 성급한 설계와 기획의 변경으로 기능을 전면 수정해야 하는 일도 발생했다.
최근에도 많이 느끼는 부분이지만 구현 전 설계 과정은 꼼꼼하면 꼼꼼할 수록 좋다고 생각한다. 물론 조금의 코딩을 통해 설계를 검증하는 작업은 필수다.
SaaS 전환을 하면서 AWS의 다양한 기능을 사용해 볼 수 있었다. EC2에 있는 서버, LB 등은 기본이고 나는 인증/인가 서비스를 맡아 구현하면서 AWS Cognito와 Lambda를 사용할 수 있었다. Cognito User Pool의 기본적인 동작들과 우리 서비스를 통합하기 위해서 Lambda를 사용했고, 이를 사용하면서 좋은 서비스(소프트웨어보다 더 작은 단위라고 생각함)란 무엇일지에 대해 생각해보게 되었다. 유저쪽에 임시적으로 추가 기능을 넣어야 한다거나(예를 들면 잠시 회원가입을 막고 승인 절차를 거치게 하는) 잠시 기능을 막아야 하는 경우가 생기면 가장 쉽게 수정하고 적용할 수 있는 곳이 Cognito가 호출하는 Lambda였다.
추후에 Cognito를 자체 인증 서비스(현재 인가는 우리 서비스 내에서 처리하고 있어서 Congito는 인증을 위한 수단으로만 사용하고 있음)로 전환하려는 작업을 계획중에 있는데 자체 인증 서비스 구현 전에 Cognito처럼 완성도 높은 서비스를 사용할 수 있다는 점이 감사하다. 처음 Congito를 공부하면서 사용할 때는 굳이 이걸 써야하나? 라는 생각이 계속 들었는데 쓰면 쓸 수록 왜 사용하는지 알 수 있는 서비스였다. 가장 큰 장점은 완전한 커스터마이징이 가능하다는 점이라는 생각이 든다. 그만큼 유연하고 제공하는 기능도 풍부하다.
하반기 2
10월 부터는 AWS 위에 올라간 우리의 SaaS 제품을 KT Cloud에서도 동작하도록 하는 작업을 맡아서 처리하게 되었다. 우리는 VM 기반의 SaaS(테넌트가 VM 단위로 올라감)를 제공하고 있는데, 테넌트가 자동으로 프로비저닝되고 동작되도록 하기 위해 AWS의 Cloud Formation과 Code Deploy를 사용했다. 문제는 KT Cloud에는 Cloud Formation과 같은 서비스를 제공하지 않는다는 점인데, 이를 해결하기 위해서 나는 우리 서비스를 리눅스 시스템 서비스로 등록하고 이미지를 만든 뒤 userdata를 사용해 동작에 필요한 값들을 주입시키는 방법을 사용했다.
이 외에도 많은 고민들이 필요했는데 대표적으로는 KT Cloud에서 고객 계정에 기본적으로 LB와 NAS를 제공하지 않고 있기 때문에 이를 생으로 만들어진 VM으로 대체해야 하는 것이 있었다. AWS에서 ALB를 사용하던 것은 리눅스 서버에 NGINX를 설치하고 userdata로 NGINX 설정을 바꾸는 것으로, AWS의 EFS를 사용하던 것은 리눅스 서버에 NAS 서비스를 올려서 사용하는 것으로 대체했다.
그리고 S3와 같은 좋은 서비스들도 당연히 사용할 수 없기 때문에 자체적으로 파일을 저장하는 서비스를 만들고, NGINX를 정적 파일 서버로 사용하는 방식으로 대체했다.
내가 선택한 방법이 가장 좋은 방법인지는 아직 확신이 없다. 리눅스를 사용하게 된 것도, 이런 서비스의 인프라 및 서비스를 혼자 구축해야 하는 것이 처음이기도 했고 시간도 많이 부족했다. 그런데 짧은 시간에 내릴 수 있는 최선의 방법을 내렸다고 생각하고 여전히 더 좋은 아키텍처를 고민하고 있다.
우리 대표 서비스의 코드 역시 회사에서는 한 코드 베이스에서 두 CSP 모두 제공하는 방향을 원했기에(처음에는 반대했지만 현재는 나도 매우 동의하고 있는 부분) 공통의 인터페이스를 분리하는 것을 고민할 수 있었다.
마무리
연말 연초에 번아웃을 겪었다. 짧은 마감 시간으로 인해 업무적 압박이 심했고 야근하지 않은 날을 찾기 힘들 정도였다. 특히 KT Cloud 전환은 내게 오너십이 주어졌고, 1인 개발 및 구축이었기에 업무가 더 몰렸던 것 같다.
프로젝트를 처음 출시 했을 때의 기쁨이 얼마 가지 못했고, 계속해서 들어오는 인터럽트에 솔직히 마음이 너무 어려웠다. 가끔 짜증내기도 했는데 그때마다 너그럽게 봐준 나의 동료들에게 너무 고맙고 미안하다.
지금은 번아웃을 많이 극복했는데, 개인적으로 예배와 기도를 통한 감사의 회복 + 운동을 통한 심적 회복 + 눈치보지 않고 칼퇴근으로 극복할 수 있었던 것 같다.
현재는 결제 서비스 및 자체 인증/인가 서비스 구현에 초점을 맞추고 일하고 있다. 인증/인가는 원래 내가 하던 부분이라 더 전문성을 갖출 수 있어서, 그리고 결제는 새로운 도메인이라서 좋다. 물론 돈과 관련되어 있어서 조금 겁나기는 하지만 실수하면 고치면 된다는 생각으로 임하고 있다(QA팀 사랑해요).
여전히 바쁘고 마감 기한은 짧지만 요즘은 감사하게 일하고 있다. 다양한 부분에서 내가 도전할 수 있음에 감사하고, 문제가 발생했을 때 같이 고민할 수 있는 동료가 있어서 감사하다.
