2022.01 ~ 2022.02 ## 회고 커뮤니케이션 오류로 공지사항 예약 발송 기능에 GraphQL을 사용했다. 나와 프론트엔드 개발자 한 분이 GraphQL을 사용하면 좋을 것 같다고 팀장님께 말씀드려서 OK 사인을 받고 진행했는데, 알고보니 팀장님은 장기적인 개선 방향에 찬성한 것이고 지금 당장 도입은 생각하지 않으셨다고 한다. 그래서 본의 아니게 팀장님 몰래 GraphQL을 사용한 모양새가 되어버렸다. 나와 팀장님이 커뮤니케이션 오류인 것을 깨달았을 때는 이미 GraphQL로 기능이 거의 완성되었고 마지막 테스트와 배포만을 남겨둔 상태였다. 그래서 일단 공지사항 예약 발송 기능까지는 GraphQL을 사용하고 이후에 어떻게 할지 개발 팀장 회의에서 정하기로 했다. 결론적으로는 나와 프론트엔드 개발자가 어떻게든 팀장님들을을 설득하기 위해 고군분투했으나 이후에는 기존처럼 HTTP API를 사용하기로 결정되었다. 나는 GraphQL의 일반적인 장점 외에도 부족한 API 문서화 기능, HTTP API를 생성하기에 불편하고 validation 기능이 약한 Rails 문법, 타입을 수동으로 생성하고 있던 프론트엔드 개발의 문제를 일거에 해결할 수 있는 좋은 방법이라는 것을 어필했었다. 특히 Ruby on Rails는 Shopify, GitHub, GitLab 등 큰 기업이 GraphQL 생태계를 주도하고 있고, 공개된 GitLab 코드에서 Rails + Vue + GraphQL의 베스트 프랙티스를 볼 수 있어서 그대로 따라가면 된다고 열심히 주장했다. 동시에 다른 개발자들이 쉽게 GraphQL을 사용할 수 있도록 기본적인 GraphQL 사용 방법과 페이지네이션 및 데이터 로더 등 신경써야 할 부분에 대한 가이드 문서도 제작했다. 그러나 안정성과 러닝커브 측면에서 우려가 된다는 이유로 기존 방식을 사용하게 되었다는 결론을 듣게 되었다. 이 얘기를 듣자마자 러닝커브가 있기는 하지만 GitLab의 베스트 프랙티스를 참고하면 충분히 감당할 수 있는 문제이고, 작은 기능부터 도입하면 안정성도 큰 이슈가 아닐 것 같다는 생각을 했었다. 결정권자이자 책임자인 팀장님의 결정이기 때문에 받아들였지만 여전히 HTTP API 개발 방식의 수많은 문제점을 어떻게 해결할지 의문이다. 혹시 개발 팀장님들 중에서 프론트엔드 개발자가 없어서 타이핑 문제를 가볍게 생각했던 것은 아닌지, 팀장님 중에 프론트엔드 개발자가 있었다면 결과가 달랐을지도 궁금하다. 어쩌면 경험 없는 주니어 개발자의 짧은 생각이었을 수도 있다. 그러나 현재 문제점을 해결할 다른 방법이 없는 상황에서, 좀 더 진지하게 GraphQL을 검토해주었으면 하는 아쉬움이 있다. 기회가 된다면 다시 도입을 노려봐야겠다.