REST vs GraphQL vs gRPC

선택지는 넷이고, 비용이 낮은 것부터 봅니다.

첫 줄로 끝나는 경우가 많습니다. 큰 필드 몇 개가 문제라면 그것만 선택적으로 빼도 전송량이 크게 줍니다. 구조를 바꾸지 않고 오늘 할 수 있습니다.

둘째는 화면 수가 적을 때 좋습니다. 다만 화면이 늘수록 엔드포인트가 늘고, 어느 것이 어디서 쓰이는지 추적이 어려워집니다.

넷째로 갈지는 화면마다 요구가 얼마나 다른가로 판단합니다. 대부분의 화면이 비슷한 데이터를 쓰는데 몇 개만 다르다면 과한 선택입니다.

흔한 실수: 응답이 커진다는 이유만으로 질의 언어를 도입하는 것. 그 문제는 훨씬 싼 수단으로 풀리고, 도입하면 캐싱과 비용 제한, 권한 검사를 처음부터 다시 설계해야 합니다.

유연함이 그대로 위험이 됩니다.

첫 줄이 가장 먼저 터집니다. 목록 10개를 받고 각 항목의 작성자를 요청하면 조회가 11번 나갑니다. 같은 종류의 조회를 한 요청 안에서 모았다가 한 번에 처리하는 장치가 사실상 필수입니다.

둘째와 넷째는 공개 API 일 때 특히 중요합니다. 상한이 없으면 요청 하나로 서버를 세울 수 있습니다. 그래서 이 방식은 외부 공개보다 우리 앱 전용으로 쓰는 쪽이 다루기 쉽습니다.

흔한 실수: 조회 횟수 문제를 도입 후에 발견하는 것. 작은 데이터로 시험하면 안 보이고, 운영에서 목록이 길어진 뒤에 드러납니다. 묶음 조회는 처음부터 넣고 시작합니다.

내부 통신에서 아쉬운 것이 지연과 규약 일치인데, 둘 다에 답이 됩니다.

첫 줄이 가장 큽니다. 내부 서비스가 늘수록 "필드 이름이 바뀐 걸 몰랐다" 류의 사고가 늘어나는데, 스키마에서 생성하면 그 부류가 사라집니다.

마지막 줄도 실무에서 값이 큽니다. 호출자가 이미 포기한 요청을 서버가 계속 처리하는 낭비를 막아 줍니다.

대신 포기하는 것이 있습니다. 사람이 눈으로 읽기 어렵고, 브라우저에서 바로 못 부르며, 중간 프록시와 도구 생태계가 HTTP 만큼 넓지 않습니다. 그래서 외부 공개에는 잘 안 맞습니다.

흔한 실수: 빠르다는 이유로 전부 바꾸는 것. 호출 빈도가 낮은 경로에서는 차이가 안 느껴지고, 도구와 디버깅이 불편해진 대가만 남습니다. 자주 부르고 지연이 중요한 경로부터 적용합니다.

HTTP 캐시는 같은 주소에 같은 응답일 때 값이 납니다. 그 전제가 깨지면 이점 자체가 이미 없습니다.

첫 줄이 실무에서 가장 흔합니다. 로그인한 사용자별 응답은 공유 캐시에 못 올리므로, HTTP 캐시의 큰 이점인 여럿이 한 복사본을 나눠 쓰는 것이 처음부터 불가능합니다. 이럴 때는 캐시를 포기하는 것이 아니라 처음부터 없던 것입니다.

반대로 포기하면 안 되는 자리는 명확합니다. 공개 콘텐츠, 목록, 이미지처럼 누구에게나 같은 응답은 HTTP 캐시만으로 서버 부하가 크게 줍니다. 이건 다른 수단으로 대체하기 어렵습니다.

포기할 때는 대체 계층을 함께 설계해야 합니다. 응답 캐시가 없어지면 그 부하가 전부 DB 로 갑니다. 필드나 엔티티 단위 캐시를 따로 두는 식입니다.

흔한 실수: 캐시 이점을 따져 보지 않고 "캐시는 나중에" 로 미루는 것. 어떤 응답이 공유 가능한지는 설계 시점에 정해지고, 나중에 바꾸려면 주소 체계부터 손대야 합니다.