지금까지의 일을 정리해보는 것도 좋겠다.

2020년 이후론 이 블로그에 글을 쓸 일이 없었다. 이 블로그는 내가 어떤 일을 하는지, 뭘 할 수 있는지 남들에게 보여주려고 만들었다. (구직 활동에 도움이 되었으면 했다.) 하지만 지금의 회사에 입사하고 나서 내가 뭘 하는지 딱히 보여줄 필요가 없어졌다. 필요하다면 회사 내에 내가 하는 일을 글로 정리해서 공유하는게 더 나았다. (물론 외부에도 올릴 수 있지만 굳이 올리진 않았다.) 아마 지금 회사에 만족하고 있어서 그런 것 같다.

그런데 지금 글을 쓰는 이유는 여태까지의 일을 기록해두는 것도 좋을 것 같아서이다.

2021년

신규 플랫폼 구축

팀이 두 팀으로 나눠지고 나서 기존에 운영하던 서비스를 나눠야 했다. 데이터베이스부터 소스 코드까지 모두 나눠야 했는데 이 일을 많이 했던 것 같다. 우리 팀은 쇼핑 서비스의 전시를 담당하고 있는데, 상품 데이터를 타 팀에서 받아서 기존처럼 잘 전시하기 위한 신규 코드를 작성했다. 기존에 사용하던 레거시 시스템이 있고, 이걸 신규 프로젝트에서 재작성 해야했다. 히스토리를 잘 몰라서 여기저기 코드와 이슈문서를 뒤적거리면서 작업했다. 잘 달리고 있는 마차의 바퀴를 바꿔야 하는 상황이라 부담감이 컸다. 괜히 바퀴에 손댔다가 마차가 멈출수도 있으니까…

테스트를 충분히 했다고 생각했는데 막상 배포하니 청바지가 나와야 할 상품 카드에 면 100%라고 써있는 택이 나와서 4시간 동안 상품을 재처리해야 하기도 했다. 몇 시간동안 문제가 있었지만 다행히 모든 이슈를 해결하고 일을 완료했다. (이 때 테스트에 대한 아쉬움이 좀 있었다.)

Kafka Connect 도입

타 팀에서 Kafka Connect에 대한 도입 사례를 발표했다. 설명을 듣고 데모를 관람하고 나니 우리 팀에서도 적용해볼 여지가 있어보였다. 우리 팀은 MongoDB를 사용하고, 특정 컬렉션의 데이터는 변경내역을 모두 저장하고 있다.

기존에는 Change streams listener를 사용해서 컬렉션마다 핸들러를 작성해주고 있었다. 그런데 kafka connect를 사용하면 커넥터 설정만 해줘도 우리가 코드를 작성해 했던 일을 이 녀석이 알아서 해주는게 아닌가? 그래서 리더에게 이걸 도입하는 작업을 내가 하고싶다고 말했다.

리더는 우리 팀에 도움이 될 것 같다고, 진행해보라고 지지해줬고 한 달동안 열심히 공부하고 poc 수준의 환경을 만들어서 팀에 공유했다. 물론 어려움이 없진 않았다.

kafka connect, 그러니까 CDC(Change Data Capture)는 데이터의 변경 전, 후 값이 있어야 좀 더 의미가 있는데 MongoDB 특성상 이전 데이터는 남지 않는다. 그리고 json 데이터를 표현하는데 어려움이 있어 SMT 라이브러리를 직접 만들어줘야 했다.

어쨌든 우리 팀에 도입해서 코드를 작성하는 일을 많이 줄일 수 있었다. 그리고 지금은 단순 이력관리 데이터 수집을 넘어서 비즈니스에서도 사용하는 수준으로 많이 사용 중이다.

한 해 총평

든든한 지원을 바탕으로 팀에 도움이 되는 기술을 연구해보고 도입했다. 그 과정에서 어려움도 있었지만 고민도 많이 하고 팀원들과 논의하면서 많은 어려움을 해결했던 것 같다. 한편 플랫폼 개편에만 치중해서 서스테이닝 업무를 많이 못한게 아쉬웠다. 이건 팀원들의 피어 리뷰에도 있었다. 다음 해엔 좀 더 적극적으로 기존 업무도 해야겠다고 다짐했다.

2022년

2022년은 몰아치는 서비스 과제로 정신이 없던 한 해였다. 그 와중에도 관심있는 것들을 조금씩 해보려고 노력했다.

다양한 서비스 과제

우리 팀은 다양한 버티컬 쇼핑 서비스를 운영 중인데, 많은 개편 요구가 있었다. 거의 1년 내내 서비스 개편을 한 것 같다. 서비스 과제에 참여하면서 자세히 알지 못했던 서비스 구조를 알아가는 계기가 되기도 했다.

나는 검색 프론트를 개편하는 일을 주로 했다. 검색 API를 제공하는 팀과 새로운 요구사항에 대해 커뮤니케이션하고 때론 요청하고, 때론 요청에 대응하면서 유관부서 팀원과 (나혼자) 친밀감이 생겼다. 현재 서비스 구조 상 구현이 어려운 스펙이 몇 가지 있었는데 이해관계자들과 다각적으로 협의하면서 서비스 오픈에 포함할 수 있었다.

테스트 코드

테스트 코드 작성에 대한 고민은 이전부터 있었고 작성도 나름 했지만 어떻게 해야 잘하는건지 막막했다. 팀에 테스트를 작성하는 분이 간간히 있었지만 모두 어떻게 해야할지 고민이 많은 상태였다. 마침 시니어가 테스트 스터디를 제안주셨고, 팀원들과 작정하고 공부하는 시간을 가졌다. 팀 스터디라서 좋았던게, 우리 팀의 코드를 가지고 팀원들과 더 나은 테스트를 위해 고민할 수 있는 기회가 됐기 때문이다. 이건 팀원들이 아니라면 하기 어려운 일이었다.

지금도 테스트를 적극적으로 작성하는 팀/나 라고 할 순 없지만 이전보단 테스트 작성에 대해 자신감이 생겼다.

모니터링 환경 개선

내가 속한 팀은 여러 모니터링 툴을 가지고 있는데, 환경은 갖춰져있지만 모니터링에 필요한 지표 수집같은게 부족하다고 느껴졌다. 그래서 주력으로 사용하는 spring application의 메트릭을 수집할 수 있는 환경을 만들었다. application level metric을 수집하고 grafana에서 시각화해 팀원들에게 공유했다.

오픈소스 기여

사실 이건 기대하지 않았던 일인데, 테스트 코드 작성하던 중 사용하는 라이브러리(AutoParams)에서 ZonedDateTime 타입을 지원하지 않는다는 걸 알게됐다. 우리 팀은 기본 날짜 타입으로 ZonedDateTime을 사용하고 있기 때문에 타입지원이 안되는건 치명적이었다.

처음엔 프로젝트 코드에 라이브러리 이슈를 해결하는 코드를 만들어서 넣었는데, 이걸 오픈소스 메인 스트림에 넣는게 더 낫겠다 싶어 PR을 올렸다. 생각보다 오래 걸렸지만 PR은 머지됐고, 오픈소스에 대해 가지고있던 두려움? 거리감이 사라졌다.

모니터링 환경을 개선하면서도 PR을 하나 올렸다. MongoDB 메트릭에서 database명이 수집되지 않고 있었는데, 우리 팀은 여러 database를 사용하고 있어서 이게 보여야 하는 상황이었다.

그래서 사용하고 있는 micrometer 코드를 살펴보다 내가 충분히 작업할 수 있을 것 같아서, 이슈를 등록하고 메인테이너와 이슈 해결에 대해 논의하고 PR을 올렸다. 이것도 금방 머지되진 않았지만 결국 머지되어 spring boot 3부턴 적용된 버전을 사용할 수 있다.

오픈소스에 PR 몇번 안했지만 느꼈던 점은 생각보다 오픈소스는 느리게 진행된다는 것이다. 이 점이 때론 답답하기도 했지만, 메인테이너들은 페이를 받고 일하는 사람이 많지 않다는걸 생각해봤을 때 당연한 것이기도 하다. 최근 오픈소스에 대해 말들이 많은데, 나도 조금은 걱정된다.

총평

몰아치는 서비스 개편에도 내가 하고싶은 걸 조금씩은 했다. 내년에도 서비스 개편은 몰아치겠지만, 올해처럼 팀에 도움이 되면서 나도 성장할 수 있는 일을 할 수 있으면 좋겠다.