강의

멘토링

로드맵

카카오 면접관이 알려주는 문서기반의 프레임워크 통신 패턴을 위한 GraphQL

Swagger 문서를 수정하고, API 스펙을 맞추고, 프론트엔드와 반복적으로 커뮤니케이션하다 보면 “왜 같은 일을 계속 두 번 하고 있지?”라는 고민을 하게 됩니다. 저 역시 실무에서 비슷한 답답함을 많이 느꼈고, 그 과정에서 GraphQL을 깊게 사용하며 데이터 중심 설계 방식에 관심을 가지게 되었습니다. 이 강의에서는 단순한 GraphQL 문법이 아니라, 실제 서비스에서 어떤 문제를 해결하기 위해 등장했는지와 Resolver 구조, N+1 문제, Federation 같은 실무적인 고민들을 함께 다룹니다. 개발자 간의 커뮤니케이션 비용을 줄이고, 더 유연한 API 구조를 설계하는 흐름을 자연스럽게 익힐 수 있도록 구성했습니다.

33명 이 수강하고 있어요.

난이도 입문

수강기한 무제한

현대오토에버
카카오
네이버
네이버웹툰
wemade

wemade

임직원들도 이 강의를 듣고 있어요!

현대오토에버
카카오
네이버
네이버웹툰
wemade

wemade

임직원들도 이 강의를 듣고 있어요!

수강 후 이런걸 얻을 수 있어요

  • 단순히 Query만 작성하는 수준이 아니라, 실제 서비스에서 GraphQL Schema를 어떻게 설계해야 하는지에 대한 감각을 얻게 됩니다. “왜 이런 구조로 나누는지?”를 이해하게 됩니다.

  • REST API에서 반복되던 Over Fetching / Under Fetching 문제를 직접 해결하면서, 프론트엔드와 백엔드가 데이터를 중심으로 어떻게 더 유연하게 협업할 수 있는지 경험하게 됩니다.

  • Resolver 구조화, DataLoader, N+1 문제 해결 전략까지 실무에서 반드시 마주치는 성능 문제를 직접 다뤄보며 “돌아가는 GraphQL”이 아니라 “운영 가능한 GraphQL”을 만들 수 있게 됩니다.

  • Swagger 문서를 따로 관리하며 생기던 스펙 불일치 문제 대신, Introspection 기반의 자기 문서화 구조를 이해하고 API 문서화 방식 자체를 새롭게 바라보게 됩니다.

  • 단순 CRUD 수준을 넘어서 Federation, Subscription, 인증 처리 같은 고급 패턴까지 학습하며 실제 대규모 서비스 환경에서도 GraphQL을 어떻게 확장하는지 흐름을 이해할 수 있게 됩니다.

문서 기반의 통신?? Swagger?? 이런게 다 뭐야??

  • 아래에 있는 내용은 실제 대화 내용입니다.

😄 Hong : 회사에서 진짜 그냥 API 개발 하나 할떄도 너무 귀찮은게 Swagger를 너무 요구해... 그거 포멧 맞춰주고 스펙 바뀔때마다 같이 수정해야하다보니 너무 귀찮아

😄 Hong : 매번 느끼는건데.. Swagger도 해야하고, 문서 작성도 해야하고 왜 중복된 일을 두번하는거지 단순히 개발자끼리 소통하는데에 국한을 둔다면 난 개인적으로 문서라는게 그렇게 중요한지 모르겠는데

😄 Hong : 그냥 gRPC 마냥 .proto 파일 보고 DDD 느낌으로 개발하면 안되나 답답해

😁Kakao 면접관(개발자) : 성장했구나 범부여... ㅋㅋㅋㅋㅋㅋ 농담이고 사실 뭐 막 틀린말은 아니기도 한거같아

😁Kakao 면접관(개발자) : 나도 예전에는 그냥 다들 하니깐, 그래서 그냥 똑같이 했는데 하면서도 "이걸 왜 이렇게 하는거지??" 라는 의문은 있었어 그러면서 다른걸 추구하다보니 성장을 하게 된거같은데?

😁 Toss 개발자 : ㅋㅋㅋㅋ Hong 범부여... ㅋㅋㅋㅋㅋ 그거 떄문에 GraphQL이 있잖아 Facebook에서 만들었나?

😁Kakao 면접관(개발자) : ㅇㅇ 그래서 나도 공부하다보니 그거 관련해서 좀 많이 사용해봤는데 Hong이 말한것처럼 gRPC랑 똑같아 사실상 HTTP 통신을 규격화해서 진행한다라는 느낌이지

😁Kakao 면접관(개발자) : 이걸 내가 알려줄게 ㅋㅋㅋㅋ 말 나온김에 오랜만에 GraphQL 고인물로써 좀 다뤄보고 싶어졌어

개발자들이 기피하는 스펙 문서화 어떻게 하면 개발자들끼리 소통하는데에 있어서 커뮤니케이션 비용을 줄일 수 있을까요? ⚡

수많은 서비스가 데이터를 중심으로 연결되는 환경에서, 우리는 단순한 REST API 설계를 넘어 “데이터를 어떻게 전달하고 소비할 것인가” 자체를 고민하게 됩니다.

백엔드에서는 이미 준비된 데이터를 내려주는데, 프론트엔드에서는 필요하지 않은 필드까지 받아오기도 하고, 반대로 화면 하나를 구성하기 위해 여러 API를 다시 호출해야 하는 상황도 반복됩니다.

그러다보니 자연스럽게 이런 고민들이 생기게 되죠.

  1. 왜 필요한 데이터만 요청할 수는 없는걸까??

  2. API 버전이 계속 늘어나는 구조가 정말 맞는걸까??

  3. Swagger 스펙 문서와 실제 응답 구조가 어긋나는 문제는 왜 반복될까??

  4. 프론트엔드와 백엔드가 데이터를 중심으로 더 유연하게 협업할 수는 없을까??

GraphQL은 바로 이러한 문제의식에서 출발합니다.

단순히 REST를 대체하는 기술이 아니라, 클라이언트가 필요한 데이터를 직접 정의하고 가져오는 방식으로 API의 역할 자체를 다시 설계한 접근 방식입니다. 실제 현업에서 왜 GraphQL이 등장하게 되었는지,
어떤 상황에서 REST보다 강력한지를 알려드리며 단순 CRUD 수준을 넘어서 Schema 설계, Resolver 구조화, N+1 문제 해결, DataLoader 활용, Federation, Subscription, 인증 처리 등 실무에서 반드시 마주하게 되는 구조적인 문제들도 함께 살펴봅니다.

“GraphQL 문법을 아는 개발자”가 아니라 "데이터 중심 API 구조를 설계할 수 있는 개발자”로 성장하는 과정이 될 수 있도록 이 강의를 통해 도와드리겠습니다. 🚀

TypeScript, JavaScript, GraphQL, MSA, 국비지원 부트캠프

GraphQL은 단순한 API 기술이 아닙니다. ⚡

기존 REST 기반 구조에서는 화면마다 필요한 데이터가 달라질수록 API 개수도 함께 늘어나게 됩니다.
Web, Mobile, Admin 페이지가 각각 다른 데이터를 요구하기 시작하면, 결국 백엔드는 비슷한 API를 계속 추가하게 되고 구조는 점점 복잡해집니다.


하지만 GraphQL은 조금 다른 방식으로 접근합니다.

클라이언트가 “어떤 데이터가 필요한지” 직접 정의하고, 서버는 그 요청에 맞춰 필요한 데이터만 조합해서 반환합니다. 즉, 서버가 화면을 기준으로 API를 설계하는 것이 아니라, 데이터 구조 자체를 중심으로 동작하게 되는 것이죠.


또한 GraphQL은 단순히 하나의 데이터베이스만 바라보지 않습니다.

User Database, Post Database, 외부 API, Comment 시스템 등 서로 다른 데이터 소스를 하나의 Schema 아래에서 유기적으로 연결할 수 있습니다. 덕분에 프론트엔드는 내부 구조를 몰라도 단일 Endpoint만으로 필요한 데이터를 가져올 수 있게 됩니다.


말씀드렸지만, 이 강의에서는 단순히 Query 문법만 설명하지 않습니다.

실제 Resolver가 어떤 역할을 하는지,
왜 DataLoader가 필요한지,
N+1 문제가 왜 발생하는지,
서비스 규모가 커질수록 Schema를 어떻게 진화시켜야 하는지까지 함께 다룹니다.


단순히 “GraphQL 사용법”을 배우는 것이 아니라, 복잡한 서비스 환경에서 데이터를 어떻게 설계하고 연결해야 하는지에 대한 사고방식을 함께 익히게 될 것입니다. 🚀

하지만 GraphQL도 만능은 아닙니다. ⚡

많은 개발자들이 처음에는 GraphQL을 단순히 “REST보다 편한 API 기술” 정도로 접근합니다.

하지만 실제 서비스 환경에서는 생각보다 다양한 문제들을 마주하게 됩니다.

  1. Resolver가 많아질수록 복잡해지는 호출 구조,

  2. 무심코 작성한 Query 하나 때문에 발생하는 N+1 문제

  3. 과도하게 비대해지는 Schema,

  4. 권한 처리와 캐싱 전략,

  5. MSA 환경에서의 Federation 설계까지

결국 중요한 것은 “GraphQL 문법”이 아니라, 데이터 흐름을 어떻게 설계할 것인가에 대한 관점입니다. 🚀

실제 강의 내용 맛보기 🍡

Prisma를 활용한 데이터 마이그레이션 및 GUI

Database의 가장 치명적인 문제 N+1 문제 방지를 위한 DataLoader 패턴

비동기 및 이벤트 통신(PubSub)을 위한 Subscription 패턴

이 강의를 함께 준비해주신 카카오 면접관님의 이력 🤭

12년차 백엔드 서버 개발자로 카카오에서 서버 개발도 하고 면접관으로도 활동하고 있는 Choi라고 합니다.

Hong과는 예전에 Conference에서 연을 맺고 되었고, 강의 활동 중반부터 계속해서 함께 적극적으로 참여하면서 다양한 주제로 강의를 만든 이력이 있습니다. 이렇게 강의를 만들어가면서 다양한분들과 대화하고 소통하는것이 저의 개발자 인생에서 많은 도움이 되고 다양한 관점을 배울 수 있는 시간이라고 생각하며 더 다양한 주제를 다루기 위해 노력하고 있습니다.

속히 말하는 대기업이라는 한가지 이력이 좋은 개발자라는것을 증명하지는 않는다고 생각하지만, 최소한 일반적인 플랫폼에 비해 더 많은 트래픽과 경험을 할 수 있다고 생각합니다. 이런 부분을 항상 강의에 녹이며 알려드리도록 하겠습니다.

[現] 카카오 본사 서버 개발자

[前] 서울 4년제 컴퓨터공학 전공

실습 환경

  • OS :

    Apple M3 Air

  • Node : v25.5.0

  • IDE : VsCode

이런 분들께
추천드려요

학습 대상은
누구일까요?

  • Swagger 수정하고 API 문서 맞추는 작업이 반복될 때마다 “왜 같은 일을 두 번 하고 있지?”라는 생각이 드는 백엔드 개발자

  • 화면 하나 만들기 위해 REST API를 여러 개 호출하면서 프론트엔드와 계속 데이터 스펙 조율하느라 지쳐있는 개발자

  • GraphQL 문법은 조금 봤지만, 실제 Resolver 구조나 실무 설계 방식은 아직 감이 안 오는 개발자

  • MSA 환경이나 대규모 서비스 구조에서 데이터 흐름을 어떻게 연결하고 관리해야 하는지 고민하고 있는 서버 개발자

  • 단순 기술 사용법보다 “왜 이런 기술이 등장했고 어떤 문제를 해결하려고 하는가?”를 이해하면서 성장하고 싶은 개발자

선수 지식,
필요할까요?

  • 입문자를 위한 강의입니다! 난이도가 낮기 떄문에 선수 지식은 요구되지 않습니다.

안녕하세요
Hong입니다.

인프런인증

커리어인증

9,462

수강생

585

수강평

157

답변

4.7

강의 평점

32

강의

자기 소개

집에서 빈둥대다 개발에 흥미를 느껴 개발 공부를 시작하였고 현재는 판교에서 플랫폼 서버 개발을 담당하여 진행하고 있습니다. 제가 공부를 했던 방법과 실무에서 접하실 수 있는 여러가지 문제점들과 해결책을 여러분들에게 제공하고 싶어 지식공유자 활동을 이어나가고 있습니다.

 

강의는 오로지 저만의 지식을 통해 만들어지지 않습니다. 모든 강의는 함께하시는 분들이 계십니다.

 

지식공유자 경력

[前] 샌드박스IP 관련 블록체인 개발자

[前] 메타버스 백엔드 개발자

[] 판교에서 고여가는 서버 개발자

 

인터뷰 이력

기타 문의

  • unduck2022@gmail.com

커리큘럼

전체

16개 ∙ (3시간 58분)

해당 강의에서 제공:

수업자료
강의 게시일: 
마지막 업데이트일: 

수강평

아직 충분한 평가를 받지 못한 강의입니다.
모두에게 도움이 되는 수강평의 주인공이 되어주세요!

얼리버드 할인 중

₩30,360

60%

₩75,900

Hong님의 다른 강의

지식공유자님의 다른 강의를 만나보세요!

비슷한 강의

같은 분야의 다른 강의를 만나보세요!