본문 바로가기
📦 아카이브

WIL 5주차 - Practical Read Optimization (루퍼스 백엔드 부트캠프)

by Gukin 2025. 8. 17.

루퍼스 백엔드 부트캠프를 시작한지 절반이 지난 시점이다. 한주한주 카드 돌려막기 처럼 과제를 쳐내고 있다. 이번 WIL은 좀 두서없이 생각의 흐름대로 적어보려고 한다.

 

라이팅 과제는 지난 주에 이어서 RT를 받았는데, 기분은 좋지만 무슨 용도로 쓰는지는 잘 모르겠다. 다음주는 각이 안나와서 못받을것으로 예상된다.

 

 

그래도 이번 주는 흥미로운 과제라고 생각했고, 배운 점이 특히 많은 주차였다고 느꼈다. 이유는 테스트를 통해 수집된 메트릭을 그라파나로 시각화된 결과를 분석하는 과정에서 '재미'를 느꼈기 때문이다.

 

무엇을 배웠는가?

보통의 서비스는 데이터를 읽기(Read)하는 트래픽이 우세하다. 그래서 읽기 성능을 잘 고민한 설계와 구현을 서비스에 적용해야 하는데, 우리 회사 서비스를 운영하면서 경험한 내용을 바탕으로 DB로 부터의 쿼리가 병목점이 되었다.'

 

복잡한 요구사항으로 복잡한 쿼리를 낳는 경우도 있었지만, 한주 한주 배우고 새로운 지식을 머릿속에 넣으면서 우리 서비스를 바라보는 관점이 달라진게 느껴진다. 예전에 배운 Bad Practice를 가져와서 그대로 적용하여 당장의 요구사항을 충족하는데 바빴던것 같다.

 

'깨진 유리창 이론'도 하나의 역할을 했다. 

서비스를 리딩하는 사람이 자주 바뀌니, 설계하는 방식도 중간중간 바뀌었다. 이도저도 아닌 애매한 방식. 남아서 운영하고 고도화를 하는 팀원들의 마음도 이해가 간다.

 

그래도 유리창이 덜 깨지라고 테이프를 붙이고 있다. PO가 원하는 방향이 있고, 그 니즈를 충족하면서 레거시를 더 나은 형태로 만드는건 힘든일이다. 잘하고 있다고 어깨를 두들겨 보자.

 

DB는 자신없는 분야

이번 주차의 주체는 읽기 성능 향상을 위해 인덱싱 + 캐싱 전략을 적용해보고 이를 모니터링 및 플랜을 확인하였다.

 

JPA를 기대하고 입사한 후에 MyBatis를 사용하면서, 나의 DB에 대한 무지함에 많은 공부를 했었다. 인덱스 설계와 실행 계획 분석 경험은 실무에서 보다 지금 배운 내용들이 크게 도움되었다. 오래동안 DB기반 개발을 해온 팀원에게 '인덱스 설계'를 어떤식으로 하는지 물어본적이 있었는데, 답변은 '모른다' 와 '감으로 한다' 였다.

 

요즘은 24시간 바보같은 질문을 해도 똑똑한 답변을 해주는 LLM의 시대이다. 많은 대화를 통해 약간의 감은 잡을 수 있었다.

 

 

그라파나는 노스탤지어

우리팀의 엔젤(도움을 주시는)분이 그라파나 대시보드 설정 JSON을 참고하라고 전달해주셨다. 설정을 해보고 이것저것 만져보니 옛날 기억이 새록새록해졌다.

 

 

나는 항상 시각화하여 분석하는것에 재미를 느꼈었다. 실험을 통해 뽑아낸 데이터를 MATLAB과 Python을 이용해서 어떻게 하면 상대방이 이해하기 쉬울까? 를 고민하면서 그래프를 그렸었다.

 

새벽까지 했었던 실험들과 이번에도 새벽까지 그라파나를 만졌던게 아이러니하게도 그때도 로드 테스트였고, 지금도 로드 테스트였다. 생각해보니 데이터는 거짓말을 하지 않고, 읽는 사람이 거짓말을 만들어 낸다.

 

측정하지 않으면 변화시킬 수 없다

모니터링과 로깅 처리에 대한 고민은 항상 많았는데 문제를 감지하고 변화를 야기하기 위해서는 객관적인 지표를 비교해서 그 차이를 알아야 한다.

 

헬스장에 매일 가서 변화를 느끼지 못한다고 생각한다면 그는 매일 똑같은 무게를 들고 있을 가능성이 높다. 주 단위로 어느정도의 볼륨을 들고 있는지를 기록해서 몸무게 변화를 같이 보면 근성장을 왜 하지 못하고 있는지 파악할 수 있다.

 

서비스도 비슷한 논리가 적용된다고 느꼈다. 운영지표를 파악하고 분석을 해야한다. B2B는 좀 다를지도.

 

캐싱은 아직도 모르겠다

멘토님의 답변으로는 TTL과 evict에 대한 고민을 많이 해보라고 하셨다. 한주 안에 인덱스와 캐시를 같이 공부하기에는 시간이 모자른듯 하다.

 

여러가지 캐시전략이 있었고, 가장 단순한 cache-aside 전략을 적용했다. 7일의 시간이 있을때 6일을 인덱스, 1일을 캐시 고민을 해서 그런가 멘토님의 피드백은 '구현 방식의 reability가 좋지 않다'였다. 

 

캐시 적용 코드가 전반적으로 리더빌리티가 떨어지는 형태로 구성되어 있는것 같아요. 파라미터로 캐시키, 값, TTL만 받으면될것 같습니다!

 

사실 구현에 대한 자신감이 좀 떨어지고 있다. 코드를 잘짜는 사람들이 너무 많다. 더 유하게 작성하기 위해 디자인패턴도 공부했지만, 지금의 상태는 어떤 패턴인지 알고 적용하는 정도의 수준 밖에 안된다. 새로운 기준들을 받아들이다보니 나만의 기준이 많이 무너진 느낌이다.

 

다음에는 무엇을 배우는가?

쉬운말로 하면 '장애로 부터 격리된 서비스' 만들기? 키워드를 나열해보면 다음과 같다 :

 

  • Fallback
  • Timeout
  • CircuitBreaker
  • Retryer

멘토님이 PG 시스템을 구현해주셨고, 성공과 실패 확률이있다. 이에 대해 어떻게 대응할지를 고민해봐야 한다. 실무에서는 타임아웃때문에 고생하고 있긴 한데, 어떻게 해야할지에 대한 감은 전혀 없다. 이번 주차에도 큰 배움이 있을것 같아서 기대된다.

 

읽기(Readings) 목록

이번 주에 제시된 과제와 발제자료를 바탕으로 읽기 목록을 GPT의 심층리서치에게 리스트업 요청했다. 학습 및 과제를 진행하면서 읽어봐야겠다.

 

관련글

티스토리툴바