1. 문제 해결
가. AWS ECS 환경의 메모리 이슈 해결
주요 API의 간헐적 동작 이상의 원인 파악 후, 서버 Scale Out 정책을 수정하여 이슈를 해결했다. 이슈의 해결 과정에 대해 이하 연관 문서와 같이 자세히 정리했다. 문서화에 공들인 이유는 사내 인프라 담당자가 없는 관계로 인프라 업무를 전담하는 백엔드 개발자들에게 도움이 될 것이라 판단했기 때문이다. 더불어 기회가 생겨 개발자 컨퍼런스에서 본 이슈 해결 과정을 주제로 발표할 수 있었다.
본 이슈의 해결과정에 대한 발표 및 문서에 대해 동료들로부터 긍정적인 평가를 받았다. 타 본부의 김용철님은 메모리 이슈에 참고할 만한 대응 프로세스가 있어서 유사 이슈 해결에 큰 도움이 될 것이라고 평가해주셨다. 같은 본부의 양재우님은 서버의 메모리 분석이 필요한 상황에서 문서의 메모리 덤프 부분을 참고하여 도움을 받았다고 전해주셨다.
참고) 연관 문서
참고) 발표 세션 홍보 포스터 이미지
나. 메시지 알림 불일치 이슈 해결
‘안 읽은 메시지’에 대한 알림 불일치 이슈의 원인을 찾고, 연관 기능을 수정하여 문제를 해결했다. 동료 개발자와 여러 논의 끝에 본 이슈가 사용자 탈퇴에 따른 데이터 부정합에 의해 발생했다는 단서를 찾았다. 이후 탈퇴한 사용자가 보낸 메시지의 경우, 메시지 목록을 확인하는 단계에서 탈퇴한 사용자의 메시지를 읽음 처리하도록 기능을 수정했다.
다. 1만 건 이상 조회 불가 이슈 해결
Elastic Search의 search_after 명령을 활용하여 1만 건 이상 조회 불가 이슈를 해결했다. 본 이슈에 대한 CS 접수 후 연관 기능의 수정 작업을 담당했다. 하위 호환성을 고려하여 1만 건 미만의 조회 요청에 대해서는 기존과 같이 응답하고, 1만 건 이상 요청에 대해서만 search_after 명령을 활용하여 Deep Paging하여 응답하도록 수정했다.
2. 유지보수성 향상
가. 주요 API 대상 통합 테스트 추가
테스트가 없는 프로젝트에 주요 API를 대상으로 통합 테스트를 작성했다. 테스트에 많은 리소스를 투입할 수 없는 환경을 고려하여 주요 API 대상으로만 통합 테스트를 작성했다. 통합 테스트 작성에 따라 회귀 방지 및 리팩토링 내성이 생겼기 때문에 추후 기능 변경 및 리팩토링 작업 시 최소한의 가이드 라인의 역할을 할 것이다. 참고로 테스트의 검증 대상은 주요 API의 Happy Path 및 주요 예외에 대한 정상 동작 여부이다.
참고) 통합 테스트 결과 출력 이미지
나. 자동배포 프로세스 구축
세 개의 서버 프로젝트를 대상으로 GitHub Actions 기반으로 자동 배포 프로세스를 구축했다. Spring 메인 프로젝트의 경우, Jenkins 기반 배포 프로세스에서 GitHub Actions 기반으로 쉽게 이전했다. 하지만 Jenkins 기반의 Django 메인 프로젝트 및 BitBucket 기반의 채팅 프로젝트의 경우, 참고 자료가 많지 않아서 작업하는데 많은 시간이 소요됐다.
Spring 기반의 채팅 프로젝트의 경우, 2019년 2월 초 이후 커밋이 없었고, 3년 9개월이 넘는 시간 동안 이슈가 발생하지 않았기 때문에 자동 배포 프로세스 구축이 급하지 않았다. 하지만 만에 하나 채팅 서비스에 이슈가 발생할 경우, BitBucket 기반의 레거시 배포 프로세스는 빠른 문제 해결에 큰 장애물이 될 것이라 판단했다. 실제로 GitHub Actions 기반으로 배포 프로세스를 구축한지 얼마 지나지 않아 채팅 메시지 알림 불일치 이슈가 발생했다. 만약 4년 가까운 시간 동안 업데이트가 안되었다는 이유로 자동 배포 프로세스 재구축을 미뤘다면 해당 이슈를 해결하는데 훨씬 많은 시간이 걸렸을 것이다.
참고) 3년 9개월 이후의 첫 커밋
다. 개발 문서 보완
10년 이상 운영되고 있는 프로젝트의 유지보수성 향상을 위해 개발 문서를 보완했다. 주로 복잡도가 높은 로직 분석, 새로운 기능의 설계 및 구현, 이슈 해결 과정에 대한 내용을 중심으로 문서를 작성했다. 문서는 예상 독자의 접근성을 고려하여 연관 프로젝트의 GitHub Wiki에 작성했다. 본인이 담당하고 있는 세 개의 프로젝트의 GitHub Wiki에 29개 문서가 존재하는데 그중 22개를 직접 작성했다.
참고) GitHub Wiki 목록
3. 신규 기능 개발
가. ver.2 로깅 시스템 개발
OGQ Market 콘텐츠 대상 로깅 시스템(ver.2)을 개발했다. API 서버에 부하를 주지 않기 위해 별개의 worker 서버에서 처리하도록 개발했다. 로깅 구현 기술은 세 가지 후보 기술(Filter, Interceptor, Aspect) 중 생산성과 유지보수성을 고려하여 Aspect를 최종 선택했다. Filter는 Spring의 컴포넌트를 주입 받지 못해서 개발 생산성이 떨어지기 때문에 후보에서 제외 되었다. Interceptor와 Aspect의 성능상 차이가 없지만 Aspect의 경우 보다 직관적이기 때문에 추후 유지보수면에서 이점이 있다고 판단하여 최종 선택하였다.
나. 주요 지표 자동 산출 기능 개발
Spring Batch 기반으로 주요 서비스 지표를 산출하고 Google Sheets에 자동 출력하는 기능을 개발했다. Django 서버에서 처리하던 지표 산출 기능을 Spring 기반의 워커 서버로 이관했다. 더불어 서비스 운영자의 요구사항에 따라 추가적인 서비스 지표를 산출하도록 작업했다. 산출된 지표는 주별로 Google Sheets에 자동 출력되도록 작업했다.
다. 성인 이미지 분별 API 개발
Google Vision API 활용하여 성인 이미지 여부를 분별하는 API를 개발했다. API 설계 단계에서 Google Vision API의 성능 테스트를 수행했다. 예술 작품 이미지, 오해 소지가 있는 이미지, 성인 이미지 등 약 30개의 표본 이미지를 대상으로 Google Vision API의 성능을 테스트했다. 테스트 결과를 바탕으로 관계 인원들과의 회의를 주도했고, Google Vision API의 활용 방향을 결정했다. 구현 단계에서는 Google Vision API 호출에 따른 네트워크 지연이 병목이 되기 때문에 이를 최소화하기 위해 클라이언트 단계에서 이미지 품질을 최소화하여 서버로 전송하는 것이 바람직하다는 의견을 제안했다.
4. 향후 계획
가. 지속 가능한 소프트웨어 개발 역량 향상
지속 가능한 소프트웨어 개발을 위해 ‘도메인 주도 디자인 역량’과 ‘가성비 테스트 설계 역량’을 집중 향상 시키겠다. 지속 가능한 소프트웨어 개발에 대한 테크 리더의 강조에 따라 앞의 두 가지 역량에 대한 집중 향상 계획을 세웠다. 나루세 마사노부의 입문서를 시작으로 Eric Evans의 본서를 읽는 방향으로 ‘도메인 주도 디자인 역량’을 계발할 계획이다. 더불어 지속 가능한 소프트웨어 개발에 있어 테스트의 중요성에 대해 깨달았다. 저비용 고가치 중심의 테스트 설계 역량을 높이기 위해 블라디미르 코리코프의 단위 테스트와 켄트백의 TDD를 읽고 소화해내겠다.
참고) 학습 정리
나. 단위 테스트 기반 회귀 방지 기여
유지보수 책임이 있는 프로젝트에 단위 테스트를 추가하여 서비스의 회귀 방지에 기여할 것이다. 기존 서버 프로젝트에는 비지니스 로직에 대한 단위 테스트가 없기 때문에 코드를 수정할 때마다 회귀에 대한 두려움이 있다. 이러한 두려움이 쌓여 리팩토링은 엄두도 못내고 있는 상황이다. 비지니스 요구사항에 따라 신규 기능만 추가된다면 추후 돌이킬 수 없는 사태로 이어질 가능성이 있다. 상황의 심각성을 인지하고 있기 때문에 2023년에는 담당 프로젝트의 주요 비지니스 로직에 대한 단위 테스트를 작성하여 서비스가 지속적으로 성장할 수 있는 가이드 라인을 만들겠다.
다. 기한 내 N사 콘텐츠 플랫폼 인수 개발
N사 콘텐츠 플랫폼 서비스 대상 인수 개발을 기한 내 완료할 것이다. 예상되는 주요 작업으로는 기존 서비스의 데이터 이관, 계정 연동, 콘텐츠 편집 메타데이터 처리 등이다. 특히 본 프로젝트에서 Kotlin과 GraphQL 도입에 따라 학습비용이 발생하는데, 이를 최소화하기 위해 틈틈히 설정법과 기본 사용법에 대해 학습하고 동료들과 공유하고 있다.