2019년 1분기 회고

2019년 1분기 회고

2019년도 어느새 4분의 1이 지났다. 이전에 했던 회고는 1년 단위의 회고였는데, 앞으로는 되도록 분기별로 회고를 하자고 마음 먹었기 때문에 이번에는 2019년도 1분기의 회고를 하고자 한다.

회사

파트너 API 프로젝트

회사에서 파트너 업체들에게 회사의 서비스 기능을 제공해주는 파트너 API를 개발하기로 결정했고, 해당 프로젝트에 참여하여 설계 및 구현, 릴리즈까지 마쳤다. 물론 혼자서 이 모든 것을 진행한 것이 절대 아니고 좋은 동료들이 함께였다. 덕분에 프로젝트를 무사히 마칠 수 있었으나 아직 끝난 건 아니었다. 서비스 개발로 끝나는 것이 아니라 운영 및 관리도 해줘야 하니까. 개발하고 릴리즈하는 것은 소프트웨어를 탄생하게 하는 것, 그리고 그 소프트웨어를 운영하면서 관리해주는 것이야말로 소프트웨어를 자라게 해주는 것 아닐까. 그런 점에서 보면 태어난 지 얼마 되지 않은 서비스라서 신경 써야 할 부분이 아직 많은 것이 사실이다.

이 프로젝트를 진행하는 과정에서 여러 가지 서비스들이 추가되었는데 OAuth 2.0 인증 방식을 도입한 인증 서비스, Zuul API Gateway를 사용한 게이트웨이 서비스, 상품 관련 비즈니스 로직을 가지고 있는 상품 서비스, 파트너 API 관련 기능을 가지고 있으며 Swagger를 통한 API 문서화 기능까지 포함된 파트너 API 서비스가 바로 그것이다.

이 과정에서 파트너 API의 전체적인 흐름과 구조, 서비스 간의 관계 등을 고민하면서 직접 설계했는데 MSA의 여러 가지 어려움을 느낄 수 있었다. 서비스 간에 인터페이스를 어떻게 하는 것이 좋을지, 공통된 인터페이스는 어떤 포맷으로 정해야 할지, 서비스가 많아짐에 따른 관리를 어떻게 할 것인지, 서비스 간 의존성은 어떻게 관리할 것인지 등등…

어쨌든 내가 직접적으로 구현한 것은 Zuul API Gateway를 사용한 게이트웨이 서비스와 파트너 API 서비스 중 이전에 구현했던 주문 서비스와 관련되어 있는 부분들, 공통 인터페이스 부분이었다. 그 외에 이전에 만들었던 주문 서비스에 필요한 기능들을 추가하는 업무까지 포함되어 꽤나 정신없이 바쁘게 움직였다.

파트너 API의 인터페이스와 더불어 각 서비스 간의 인터페이스를 설계하면서 좀 더 RESTful한 API를 만들고자 노력했지만 완벽하게 “이것이야말로 REST API다!”라고 자부할만큼은 아니었다. 사내 스터디를 하면서 읽었던 “REST API 디자인 규칙” 책에서 나온 여러 가지 디자인 규칙을 도입하긴 했지만 모두 해내기에는 역부족이었다. “완벽한 REST API란 정말 까다로운 것이구나”라는 생각이 들 정도였다. 이에 대한 자세한 내용은 별도로 포스팅 해야겠다.

또한 서비스들의 분산되어 있는 로그를 통합하여 모니터링하기 위해 ELK 스택 도입을 건의했고, 그 과정에서 환경 구축 일부를 지원했다. 사실 굳이 로그 통합 모니터링을 위해서 ELK 스택을 도입하는 것은 배보다 배꼽이 더 큰 것 아닐까, 라는 생각이 들기도 했는데 이번에 구축한 ELK 스택이 로그 통합 모니터링으로 끝나는 게 아닌, 서비스의 데이터를 수집하고 분석하는 용도로도 사용될 여지가 있다는 판단 하에 ELK 스택 도입을 추천했으며 결국 우리 시스템에도 ELK 스택이 도입되었다. 아직은 시스템 일부에서만 사용하고 있지만 앞으로 적극적으로 활용할 수 있으리라 기대하고 있다.

늘어나는 서비스에 대비해서 늘어나는 EC2 인스턴스를 줄이고자 컨테이너 환경 도입을 건의했고, 새로 입사한 동료가 구축한 Rancher라는 컨테이너 오케스트레이션 서비스를 이용해 일부 서비스의 컨테이너 환경을 구축해보았다. 지금은 프로덕션 환경만 기존과 같이 서비스 당 인스턴스 단위로 운영하고 있으며, 베타 환경과 테스트 환경과 같은 다른 환경은 컨테이너 환경으로 운영하고 있다. 컨테이너 오케스트레이션 서비스를 처음 사용해보는 것이라 색다른 경험이었는데 추후에 이러한 컨테이너 오케스트레이션 서비스 중에서 특히나 유명한 Kubernetes에 대해서 따로 공부해봐야겠다는 생각이 들었다.

API 문서화에는 Swagger를 사용했다. Swagger를 선택한 이유는 서비스의 코드가 변경될 때마다 API 문서의 내용도 함께 갱신해야 하는데, 이 과정을 최대한 효율적으로 진행하기 위해서였다. API 문서 중 인터페이스 내용만이라도 변경된 코드 내용이 자동으로 반영된다면, 그만큼 손이 덜 가지 않을까 싶었다. 그러나 Swagger 역시 한계가 있었기 때문에 꽤 많은 부분을 커스터마이징해서 사용했다.

여기서 또 하나 느꼈던 것은 바깥으로 공개되는 API를 만들 때에는 특히 신경 써야 할 부분이 많다는 점이었다. 문서화도 그렇고, 인터페이스도 최대한 직관적으로 정해야 했다. 개발 시간만큼 많이 투자했던 부분이 바로 이런 부분들이었다. 내가 아직 이런 영역에 대한 경험이 적고 주도해야 하는 입장으로 일한 경험이 많지 않아서 더더욱 어렵게 느껴지기도 했다.

개인

독서

2권의 책(“컴퓨터 과학이 여는 세계”, “REST API 디자인 규칙”)을 읽었으며 현재 3번째, 4번째 책을 읽고 있다. 동시에 여러 권의 책을 번갈아 읽는 편이 효율적이라고 느껴서 이 방법을 채택하고 있는데, 애초에 목표했던 1달에 1권 읽기는 벌써 지키지 못했지만 포기할 생각은 없다. 오히려 좀 더 독서에 시간을 들여서 다시금 목표를 따라잡을 생각이다. 지금 현재 읽고 있는 책은 “토비의 스프링 3.1 1권”, “자바 ORM 표준 JPA 프로그래밍”인데 최근에는 “자바 ORM 표준 JPA 프로그래밍”을 좀 더 집중해서 읽고 있다.

블로깅

일단 1달에 2개 정도의 포스팅을 했으며, Hexo로 블로그 플랫폼을 갈아탔다. 문제는 저번달인 3월에는 아무것도 올리지 못했다는 것. 변명하자면 3월이 가장 바빴는데, 위에 적은 파트너 API 프로젝트의 막바지 단계였기 때문에 포스트 작성 시간을 확보하지 못했었다. 그래서 대신 이번 4월, 5월에는 좀 더 포스트 작성에 신경 쓰기로 마음 먹었다.

개인 스터디

최근에 Rust와 JPA를 집중적으로 공부하고 있다. Rust는 워낙 개인적으로 관심있는 언어였기 때문에 “지금 아니면 언제 해보랴”라는 생각으로 Rust Language Book을 보면서 따라서 코딩해봤다.

JPA는 최근 회사에서 서비스를 개발하면서 중점적으로 파고 들만한 이유가 있었다. 일단 ORM을 엔터프라이즈 환경에서 사용하는 것은 처음이니만큼 부족한 점이 있었다. 거기에 최근 JPA로 개발하면서 “우리 서비스의 데이터베이스에 맞춰 ORM으로 풀어낼 때 어떻게 풀어내야 할 것인가”에 대해 고민하고 삽질할 기회가 많아졌고, 같이 일하는 동료들도 열심히 JPA를 공부하며 이런 문제들을 하나씩 해결하고 있어서 나 역시 발목을 붙잡는 입장이 되지 않도록 열심히 공부하고 있다.

회고를 마치며

이 회고를 작성하고 있는 지금은 벌써 4월의 마지막 날이다. 이번 회고를 작성하면서 작년 한 해도 바쁘게 움직였지만 “올 해도 꽤나 파란만장하겠구나”라는 생각이 들었다. 거기에 더해서 앞으로 공부해야 할 목록들이 공부하면 할수록 오히려 늘고 있어서 약간의 압박감마저 느끼고 있다.

그래도 회고를 작성하면서 스스로가 어떤 면에서 발전하고 있는지 알 수 있어 뿌듯하기도 하고, “앞으로 이런 부분들은 더 발전해야겠다”라는 생각이 들어 동기부여에도 도움이 되는 듯 하다. 이번으로 회고가 끝나지 않도록, 그리고 스스로가 경험하고 해내는 것들이 기록이 되고 데이터가 될 수 있도록 틈틈이 정리하는 시간을 가져야겠다. 앞으로 남은 시간들도 힘내서 더 발전할 수 있도록, 비록 빠르지 않더라도 한 걸음씩 나아갈 수 있는 사람이 되도록!