[운영 경험담] jun.park(7팀)

[mepwj]

FE, BE, DevOps 와 팀장을 맡아 FE 와 내용이 달라질 거 같아서 따로 작성하였습니다.

1. 사용자 피드백을 어떻게 수집하고 반영했나요?

저희 서비스는 서비스 자체 페이지로 문의하기 페이지가 있어 직접적으로 피드백을 받을 수 있고
홍보 사이트나 사이트의 푸터에 팀 이메일의 주소가 있어서 피드백을 받을 수 있었습니다.
또한, Disquiet 서비스를 이용하여 홍보했기 때문에 해당 서비스 내에 리뷰나 댓글을 통해 받을 수 있었습니다.

타 팀의 일원과 함께 서로 프로젝트를 QA 해주면서 피드백을 받았는 데

그 중에서도

1. 로딩 이미지 변경 : 분석 중 혹은 로딩 중이라고 확실하게 표현 됨을 원했다.
2. 홈 페이지에 다람쥐가 나타나는 데 이게 맨 먼저 보이는 게 아니라서 아쉽다.

이 피드백을 적용시키기 위해서 기존의 통합대기환경지수와 날씨 정보를 기존 다람쥐와 대사의 위치를 변경하였습니다. 또한, 로딩 이미지 또한 보다 확실한 로딩임을 표시하는 이미지로 변경하였습니다.

2. 사용자들이 제기한 주요 문제점 중 하나를 해결한 사례가 있나요?

날씨 정보를 불러오는 기존 비지니스 로직은 벡엔드 서버로 현재 위치 정보를 주면 날씨 정보를 기상청 API 를 호출하여 데이터를 정제하고 파싱하여 클라이언트에게 보여지기 까지 600ms 이상이거나 Timeout 이 나는 경우가 허다했다.
제일 주요 사안으로 그 다음날 MVP 배포였는데 당일 기상청 API 가 먹통이 된 것이다. 이를 대체하기 위해서 OpenWeatherMap이나 AccuWeather 등 기존 기상청 API 말고 다른 날씨 API를 찾고 API 호출 횟수 제한 문제를 하루에 2번 아침, 저녁으로 호출하여 DB 에 저장하고 이를 클라이언트에게 주는 것으로 로직을 수정하고 변경된 API 에 맞게 Python CrobJob 을 사용하여 자동으로 DB 에 저장하는 코드를 실행시켰다. 또한 API 문서를 빠르게 수정하여 구현 후 테스트 진행하고 MVP 배포를 시간 안에 맞출 수 있었다.

.

3. 서비스 장애나 에러로 인해 사용자가 불편을 겪었을 때 어떻게 대처했나요?

MVP 배포 후 홍보를 진행하였는데 2번의 서버 장애를 겪었다.
첫 번째 서버 장애는 EC2 의 메모리 부족 문제였다. MVP 라서 prod 서버를 EC2 사이즈를 micro 사용하고 있는데 이가 문제임을 파악하고 빠르게 서버를 복구하고 팀원들과 함께 포스트모템을 통해 어떤 원인인지 이야기하고 다음 배포는 무중단 배포 포함하여 사이즈를 업그레이드 하자고 계획을 하였습니다.
두 번째 서버 장애는 업그레이드 된 EC2 에 Backend 서버인 Spring boot 의 JPA Hikari 가 DB 와 연결이 끊겨 Spring boot 어플리케이션을 종료해 문제가 되었다.
RDS 를 확인해보니 RDS 사이즈가 프리 티어인 micro 로 되어있어서 connection pool 이 최대 40개이기 때문에 여러 사용자가 들어오면 pool 이 꽉 차서 문제였던 것이다. 이 문제 또한 포스트모템을 통해 어떤 원인인 지 이야기 하고 RDS 사이즈를 기존보다 업그레이드 한 small 사이즈로 변경하였고 현재 프로젝트에서 사용중인 기술들인 AWS나 라이브러리가 어떤 것인지 검토하였습니다.

.

4. 실제 사용자의 행동 패턴을 분석한 경험이 있나요?

Google Analytics 의 보고서를 통해 패턴을 분석했습니다. 기존 API 호출하고 이를 파싱하여 클라이언트에게 건네주는 단순하지만 느린 비지니스 로직을 선택한 당시에는 사용자는 "/" 인 홈에는 평균 2분 동안 머문 반면에 날씨 정보 조회나 대기질 오염 정보 조회 페이지는 로딩이 오래 걸려 활성 사용자당 평균 참여 시간이 1분 미만이였다. 이는 로딩 시간이 많이 걸리기 때문이 아닐까라는 추측을 하였고 로직을 변경하니 1분 30초 정도로 늘게 되었다.
또한 2차 릴리즈 때 많은 작업 시간을 들여서 UI 개선과 디자인 변경을 하였는데 이 이후 새로운 사용자를 받고 나니 평균 시간이 대부분 페이지가 2분 대로 늘었습니다.

.

5. 사용자 수가 급증했을 때, 성능 저하 없이 서비스를 어떻게 유지했나요?

기존 MVP 배포 및 홍보 때는 사용자가 최대 40명 정도의 사용자가 접속하였습니다. 이때는 RDS Connection pool 문제가 생겨 서버 다운 사건이 있었습니다. 이 이후 여러 기술 검토를 통해 무중단 배포와 함께 서버 사이즈를 증가 시켰고

.

6. 사용자 경험(UX)을 개선한 사례가 있나요?

로그인을 해야 서비스를 이용할 수 있는 페이지를 로그인하지 않아도 제한적으로 이용할 수 있게 변경하였습니다.
이는 커리어 매니저 님의 피드백을 받고 팀원이 요청하여 UI/UX 를 개선하였습니다.

.

7. 사용자가 불편을 겪는 상황에서 어떻게 사용자 친화적인 해결책을 제공했나요?

로그인 이후 Access Token 이 만료되어 재 발급이 필요할 때 console로만 이를 알리고 Token 이 필요한 모든 API 호출에 재 발급 로직을 넣어두었고 이를 사용자에게 발각되지 않기 위해 최소한의 오류 처리를 하였습니다.

.

8. 사용자 이탈을 방지하기 위해 어떤 노력을 했나요?

사용자 이탈을 방지하기 위해 주제인 "대기질 오염 정보 조회 서비스" 에 다람쥐 와 게임이라는 요소를 첨가하고 다람쥐를 육성하고 여러 종류의 다람쥐를 두어 사용자의 이탈을 막았는데 이 외에도 UI 와 전체적인 디자인 개선이 노력이라고 할 수 있다.

.

9. 장애나 오류가 발생했을 때 사용자에게 어떻게 커뮤니케이션했나요?

아직 커뮤니케이션 한 사건은 없지만 이 질문 이후 장애나 오류가 발생하여 문제가 발생하였을 경우
홈페이지 내의 "공지사항" 페이지를 이용하여 사용자와 커뮤니케이션 할 거 같습니다.

.

10 실사용자 데이터를 기반으로 성능을 최적화한 경험이 있나요?

Zustand 전역 상태 라이브러리를 사용하여 이미 호출한 API 와 동일한 API 호출을 여러 페이지에서 똑같은 요청과 똑같은 응답을 사용하는 데 이를 전역상태로 두어 이미 호출했던 API 호출을 하지 않도록하였고

로그인 과 일일 미션을 적용 시키기 위해서 페이지 전환을 어떻게해야할지 고민하였는 데 로그인 하면 무조건 홈페이지로 보내어 일일 미션을 확인하는 꽤나 강압적인? 방법을 사용하여 일일 미션 을 검증하게 하여 사용자가 불필요한 오류 메세지나 불편을 겪지 않도록 하였다.

이를 적용하니, 크롬의 개발자도구에서 Network Tab의 API 요청과 응답까지 데이터를 가져오는 데 기존 57초 정도 걸리는 반면에 기존에 했던 API 응답 내용을 불러오는 것이라서 12초 정도 걸리게 변경하였습니다.