프론트엔드 기술은 빠르게 변화하고 있습니다. React만 봐도 상태 관리 라이브러리가 계속 등장하며, 이 기술을 썼다가 저 기술로 바꾸는 일이 빈번합니다. 결국 과도기에 이도 저도 아닌 코드들이 남아, 유지보수가 어려워지는 문제가 생깁니다. GraphQL도 마찬가지입니다. 새로운 기술을 도입할 때는 신중해야 합니다.
저는 프론트엔드 개발자로서 최근 Next.js + GraphQL 조합을 사용하는 오픈한 지 얼마 안 된 서비스에 투입되었습니다. 문제는 GraphQL을 도입한 명확한 이유나 가이드 없이 사용되고 있다는 점이었습니다. 새로운 기술은 문제를 해결하기 위해 도입해야 하는데, 단순히 신기술이라는 이유로 도입하면 예상치 못한 기술적 부채를 떠안게 됩니다.
GraphQL, 정말 필요할까?
이 프로젝트의 백엔드는 MSA 구조의 REST API를 제공합니다. GraphQL이 도입된 이유는 화면에서 한 개의 MSA API만으로는 충분한 데이터를 제공할 수 없기 때문이었습니다. 애그리게이션 서버 없이, 각 기능별로 나뉜 MAS API들을 조합해야 했습니다. 그래서 중간에 Next.js를 이용해 인증/인가와 SEO 처리를 위한 SSR 서버를 추가했습니다.
하지만 신규 프로젝트의 현실은 바빴습니다. 화면 스펙도 많았고, GraphQL을 제대로 구성할 시간이 없었습니다. 그 결과 MSA REST API를 단순히 1:1 매핑하여 합쳐놓은 크고 느린 Resolver가 만들어졌습니다. API들을 합친 .graphql 파일은 복잡하고 유지보수하기 어려운 형태로 남았습니다. DataLoader, Resolver Chain 등 좋다는 것은 다 가져다 붙였지만, 결과적으로 무겁고 어려운 GraphQL 레이어가 만들어졌습니다.
GraphQL을 유지보수하는 과정에서도 많은 어려움이 발생합니다. Data Source인 REST API의 버전을 변경하거나 새 API를 추가할 때마다, REST API의 변경점을 찾아서 GraphQL의 타입과 쿼리 내 필드를 하나하나 추적해야 합니다. 결국, REST API의 변경점을 프론트엔드에서 직접 관리해야 하는 부담이 생깁니다. 특히, enum 타입이 추가되었을 때, GraphQL 스키마가 업데이트되지 않으면 500 에러가 발생하거나 타입 불일치로 인해 요청이 실패하는 문제가 자주 발생합니다.
FE에서 GraphQL을 사용해 직접 DB를 GraphQL의 DataSource로 활용하는 경우라면 그나마 가볍게 적용할 수 있지만, REST API를 기반으로 GraphQL을 구성하는 것은 오히려 MSA의 애그리게이션 부채를 떠안게 되는 느낌입니다. 따라서 이 방식은 정말 추천하지 않습니다.
신기술 도입, 신중해야 한다
디자인 패턴도 비슷한 문제를 겪습니다. 배웠으니 써보고 싶어서 도입하는 것이 아니라, 먼저 해결하려는 문제가 무엇인지 정의하고 그 문제를 해결하는 데 적합한 방법을 찾아야 합니다. 프론트엔드 기술이 많아지면서 "이 기술이 요즘 좋다더라"라는 이유로 도입했다가 나중에 유지보수가 어려워지는 경우가 많습니다. 상태 관리 라이브러리도 마찬가지입니다. Redux에서 Recoil, Zustand 등으로 이동하는 과정에서 과도기적인 코드들이 많아졌습니다.
GraphQL도 처음에는 좋을 것 같았지만, 제대로 된 설계 없이 도입한 결과 복잡하고 무거운 구조가 되었습니다. 유지보수도 어렵고, 새로운 사람이 프로젝트에 들어올 때의 러닝커브도 상당히 큽니다. 결국, 기술을 도입하기 전에 충분한 논의와 가이드라인 수립이 필요합니다. 신기술이 꼭 좋은 것은 아닙니다. 고민된다면, 차라리 사용하지 않는 것이 나을 수도 있습니다.
마치며
기술을 선택할 때는 유행이나 기대감이 아니라, 실제로 우리가 해결해야 할 문제를 중심으로 판단해야 합니다. GraphQL이 강력한 도구인 것은 맞지만, 무작정 도입하면 오히려 기술적 부채를 키울 수도 있습니다. "이 기술을 왜 사용하는가?" 라는 질문에 명확한 답을 할 수 없다면, 사용하지 않는 것이 더 나을 수도 있습니다. 신기술은 필요할 때, 그리고 팀이 충분히 준비되었을 때 도입하는 것이 가장 현명한 선택입니다.
또한, 동료들과 충분히 고민하고 도입을 결정했다면, 우리가 해결하고 싶은 문제가 무엇인지, 좋은 사례는 무엇인지 먼저 정의하는 것이 중요합니다. 이를 기반으로 개발 가이드를 마련하고, 베스트 프랙티스를 고민한다면 기술적 부채를 최소화하고 더욱 효과적으로 기술을 활용할 수 있을 것입니다.