[T-004] 논리적 GraphQL 에러 풀기

논리적 GraphQL 에러

GraphQL Client(이 글에서는 Relay를 기준으로 설명)의 상태 관리와 Fetch Policy는 개발과 QA 단계에서 발견하기 어려운 문제들을 만들어내요. 배포 이후 운영 레벨에서 논리적 GraphQL 에러들이 나타나죠. Syntax나 Runtime 에러는 아니지만, 사용자들이 '경험이 이상하다'고 제보하는 상황들이에요. 이런 문제들은 유저 트래픽이 충분히 크고 리포팅 라인이 잘 구축되어 있을 때에야 발견돼요.

사용자들은 우리가 예상한 happy path로만 서비스를 이용하지 않아요. 예상치 못하게 발생하는 추가 작업 리소스를 개발 시점에서 제거할 수 있는지, 만약 놓쳤다면 얼마나 빠르게 잡아낼 수 있는지, '논리적 GrpahQL 에러'를 풀어내는 역량에 대해서 이야기해보고 싶어요.

논리적 에러는 주로 이런 형태로 나타나요.

• 특정 상황에 보여선 안 될 UI가 보이는 경우
• 특정 상황에 보여야 할 UI가 보이지 않는 경우
• 특정 상황에 변경되어야 할 UI가 변경되지 않는 경우
• 특정 상황에 변경되지 않아야 할 UI가 변경된 경우

논리적 에러를 해결하는 안티패턴

만약 이슈가 이런 현상을 띄고 있다면 여러 가능성을 의심해 볼 수 있겠지만, 서버 응답이나 응답을 렌더링하는 과정의 변환 로직에 문제가 없는 경우 GraphQL의 상태 정규화에 기반한 캐싱과 Fetch Policy를 다루는 과정에서 놓친 부분이 있을 가능성이 높아요. 문제가 일어난 유저 정보가 있다면 이벤트 로그를 분석하고 유저 플로우를 트레이싱해서 재현할 수 있는데, 역량이 부족하면 가령 Fetch Policy를 'network-only'로 바꿔서 해결하려는 선택을 하게 돼요.

데이터의 무조건적 최신화를 선택하는 건 GraphQL 클라이언트 도구의 캐싱 전략에 대한 안티패턴이에요. 마치 React의 선언적 렌더링을 포기하고 useEffect로 직접 DOM을 조작하는 것처럼, 기술이 제공하는 본질적 가치를 훼손하는 거죠. 우리가 어떤 기술을 선택할 때는 그 기술의 패러다임이 주는 힘이 작동하는데, 그 힘의 방향을 따라가는 게 중요하다고 생각해요. 'network-only'는 논리적으로 캐싱된 데이터를 쓰는 것이 무의미할 때 사용하는 것이 좋아요.

어떻게 풀 것인가