안녕하세요. 이번 자바스크립트의 비웨어 첫 발표를 맡게 된 당근마켓의 원지혁입니다.

오늘 이제 'Declarative'라는 주제를 들고 왔는데요.

이제 제가 지난 1년 동안 프론트엔드 개발을 하면서 경험한 부분들, 그 다음에 고민한 부분들을 최대한 담으려고 노력을 해봤어요.

뭐 그러다 보니까 내용이 추상적일 수도 있는데요. 이제 좀 더 제가 구체적으로 설명을 드리고 싶어 가지고 예제를 뭐 이것저것 막 넣어봤는데, 뭐 제가 보기에는 추상적인 건 마찬가지인 것 같아요.

그래서 그런 부분 양해해주시면 좋을 것 같고요. 그러면 발표 시작하도록 하겠습니다.

아 네, 일단 제 소개부터 드리자면요.

이제 저는 당근마켓에서 소프트웨어 엔지니어로 일하고 있는 원지혁이고요.

GraphQL 코리아의 오거나이저로 활동을 하고 있습니다.

그리고 기술적으로는 이제 GraphQL 기반으로 백엔드, 프론트엔드 모두 개발을 하고 있습니다.

예, 저는 처음에 Vue.js로 개발을 시작했는데요.

현재는 파일 스크립트, 리액트, 그래프 큐엘을 주로 사용하고 있고 이제 하이 퀄리티 앱을 빠르게 제공하는 방법에 대해서 계속 고민을 하고 있습니다 네, 그럼 이제 본격적으로 발표를 시작할 텐데요.

첫 번째 챕터에서는 UI 를 표현하는 기존의 방법과 그 다음에 디클러레이티브 UI에 대해서 한번 알아보겠습니다.

영재 님께서 질문을 해주셨는데요. 이 선언형 프로그래밍에 대한 이야기냐고 여쭤보셨는데, 정확히 말하면 제가 뭐 선언형 프로그래밍에 대해서 이런 담론을 다루기에는 제 실력이 좀 부족한 것 같고, 원래는 선언적이라는 게 좀 와닿지는 않았는데 이번에 어떤 기회를 통해서 좀 와닿게 되었거든요.

그런 부분들을 소개하는 발표가 될 것 같습니다.

아마 웹 개발을 하신다면 다들 익숙하실 텐데요.

바로 요, 또는 HTML입니다. 뭐 아시다시피 이제 웹 문서를 표현하는 가장 기본적인 방법이고요.

이제 트리 구조라든지 열고 닫는 문법이라든지 이런 규칙에 따라서 각 요소들이 웹 브라우저 내에 배치가 됩니다 뭐 다른 정보를 보기 위해서 다른 페이지를 보려면 페이지 링크를 통해 이동해야 되고요 문서 내용을 교체하려면 반드시 페이지 변경을 통해서만 합니다 어 여기서 페이지의 내용을 페이지 이동 없이 동적으로 변경하기 위해 나온 게 바로 자바스크립트인데요 정해진 알고리즘을 통해 DOM을 조작하고 이러한 알고리즘을 특정 시점에 동작시킴으로써 페이지 이동 없는 UI 변경을 구현할 수 있습니다 그러다가 이제 2000년대 초반에 구글 맵이 등장하면서 웹 API라는 개념이 등장하게 되는데요 웹 페이지와의 상호작용이 극대화되면서 자바스크립트 코드가 복잡해지고 길어질 수밖에 없었습니다 그래서 필연적으로 스크립트를 통한 UI의 조작을 어떻게 간결하게 표현할 수 있을지에 대한 생각을 하게 돼요 어 한번 그 당시로 돌아간다고 생각하고 코드를 함께 볼까요 이 코드는 다들 이해하실 거라고 생각해요 일반적인 자바스크립트 코드입니다 보시면 이제 'Greeting'이라는 변수의 스트링을 대입하고 p 태그 엘리먼트를 만들어서 거기에 그 스트링을 넣고 이제 'app'이라는 id를 가진 엘리먼트를 찾아서 p 태그를 어펜드하는 일반적인 자바스크립트 코드에서 먼저 설명을 했듯이 순차적으로 위에서부터 아래로 명령을 실행하는 방식이구요.

코드가 위에서부터 아래로 차례대로 실행이 됩니다.

이런 방식을 보통 데클러러티브(Declarative)랑 반대되는 개념으로 임페러티브(Imperative)라고 표현을 하더라고요.

그렇다면 이 코드는 무슨 문제가 있을까요?

지금 예제 코드 같은 경우에는 굉장히 짧긴 한데요.

이런 코드가 1만 줄 정도 있다고 상상을 해볼게요. 예를 들면 뭐 특정 부분을 바꾸고 싶다고 하면 어떨까요?

그 코드가 어디에 있는지 찾아야겠죠. 만약에 뭐 IDE에 포함된 검색 기능을 썼더니 검색 결과가 50개 정도 나왔다, 이러면 꽤나 당황스럽겠죠.

아니면 뭐 기능은 그대로인데 성능을 높이고 싶다거나 리팩토링을 하고 싶다면 어떨까요?

저라면 혹시 내가 고친 코드가 다른 코드에 영향을 미치지는 않을까 걱정이 될 것 같아요.

그리고 만약에 이제 회사에서 신규 입사자분이 들어오셔서 이 코드를 인수인계 받아야 된다면 어떨까요?

그 상황을 설명하는 데만 한 일주일은 필요할 것 같아요.

네, 그리고 저는 이제 명확한 코드라고 말하는 게 누가 봐도 같은 의미로 받아들일 수 있는 코드라고 생각하는데요.

위의 방식대로 구현을 하다 보면 같은 기능을 구현하더라도 사람에 따라 수많은 베리에이션이 나올 수 있고 수많은 생각들이 나올 수 있기 때문에 누가 봐도 같은 의미로 받아들이는 명확한 코드가 되기는 조금 힘들 것 같아요.

자, 그러면 저랑 같이 코드를 한번 선언적으로 개선을 해 볼까요?

일단 선언적이라는 게 뭔지 어렴풋이 이해를 하면 좋을 것 같아요.

음, 이 문장은 이제 띵킹 인 리액트(Thinking in React)라는 문서 내용 중에 제가 발 췌한 부분인데요.

리액트 컴포넌트를 설명하는 부분인데, 이제 리액트 컴포넌트가 선언 적이라고 이야기를 꺼내면서 이러한 선언적인 컴포넌트는 어떻게 해당 고민 없이 어떤 UI를 그릴지에 대한 부분만 신경 쓰면 된다고 적혀 있어요.

저는 여기서 핵심을 '하우(How)'랑 '왓(What)'으로 봤습니다.

일단 여기서 How는 어떻게, 어떤 방식으로, 어떤 순서로를 의미하고 What은 무엇을, 어디에, 어떤 모양으로를 의미를 합니다.

네, 그래서 다시 한번 문장을 가볍게 정리를 해보면 이 문장이 말하고 싶은 Declarative, Declarative의 뜻을 이제 How를 최소화하고 What을 극대화하는 방법이라고 표현을 하고 있습니다.

네, 자 그럼 아까 그 코드를 How랑 What으로 한번 분리를 해 볼까요?

코드를 다시 보시면 어떤 문장을 그릴지에 대한 부분은 아실 거고요.

createElement나 getElementById, 죄송합니다. createElement나 getElementById, appendChild 같은 부분은 How일 것 같네요.

네, 그러면은 이 코드에서 How와 What을 분리를 해보겠습니다.

그럼 이제 다음과 같은 코드가 될 텐데요. 저는 이제 함수의 형태로 분리를 했어요. What에 해당하는 밑의 부분을 다시 한번 보시면은 좀 더 직관적으로 코드가 변한 것을 확인하실 수 있을 것 같아요.

이전의 코드는 그냥 HTML 정적인 내용을 그리는 것이었는데요.

만약에 내용을 버튼이 눌릴 때마다라든지 변함없이 바꾸는 기능을 만든다면 어떨까요?

이 기능의 How와 What으로 분리를 해 보면 How는 어떻게 바꿀 건지, 언제 바꿀 건지, 어떤 타이밍에 바꿀 건지에 대한 부분일 것 같고요.

What은 무슨 데이터를 바꿀지, 어디에 데이터를 보여줄지에 대한 부분일 것 같습니다.

물론 더 고민해 보면 좋겠지만, 저희는 React라는 이미 좋은 아이디어가 있으니까 How와 What을 분리하기 위해서 React의 상태 개념을 그대로 차용해 보도록 할게요.

먼저 인터랙티브하게 작성된 코드를 함께 보실게요.

버튼이 눌릴 때마다 카운트를 하나씩 증가시키는 코드인데요.

보시다시피 How와 What이 섞여 있는 모습입니다. 자, 여기서 상태 개념을 도입해서 How를 한번 분리해 내 볼까요?

아까 전에 작성했던 render를 다시 한번 작성해 보겠습니다.

원래는 정적인 엘리먼트를 인자로 받았었는데요.

이번에는 initialState라는 오브젝트와 createElement라는 함수를 받아서 setState라는 함수가 내부에서 호출될 때마다 render 함수가 호출 이렇게 선언적으로 작성을 했습니다.

이런 식으로 하우를 제거하면 UI는 어떻게 변할까요?

다음과 같이 변하게 됩니다. 우리가 흔히 알고 있는 리액트 컴포넌트의 모습이 되어서, 이전에 임퍼러티브하게 작성했던 코드와 비교해 봤을 때 어떤가요?

좀 더 UI에 집중된 모습을 보여주는 것 같습니다. 자, 그러면은 이제 디클러러티브에 대해서 더 잘 이해하기 위해서 조금 다른 개념들을 소개해 드려볼게요.

두 번째 챕터는 이제 관심사의 분리입니다.

만약에 앞서 제가 짰던 렌더 함수를 이용해서 앱을 만든다고 하면 어떤 일이 벌어질까요?

스테이트가 너무 커지고 이제 돔 트리가 비대해져서 관리하기가 되게 힘들어질 것 같아요.

이를 해결하기 위해서 리액트에서는 컴포넌트라는 개념으로 앱을 분리하게 됩니다.

컴포넌트를 어떻게 작성하면 좋을까요?

이때 우리는 보통 관심사의 분리라는 단어를 쓰는데요. 이 단어에 대해서 조금 설명을 드리면, 일단 기존의 웹 문서 같은 경우에는 주로 역할에 따라 HTML, CSS, 자바스크립트로 코드를 분리했습니다.

왜 그럴까요? 저는 자바스크립트가 HTML, CSS와 같은 마크업 언어와 너무 달랐기 때문이라고 생각해요.

하지만 이 경우 Declarative UI가 허물게 되는데요.

Declarative UI 패턴을 통해서 자바스크립트를 마치 마크업 짜듯이 작성할 수 있게 됐고, 이를 통해 HTML, CSS, 자바스크립트가 자연스럽게 섞일 수 있게 됐어요.

그렇게 되면서 우리는 역할이 아닌 관심사를 기반으로 컴포넌트를 쪼개게 됩니다.

그렇다면 컴포넌트를 관심사에 따라서 잘 쪼개려면 어떻게 해야 될까요?

이거 정말 많은 분들이 궁금해하실 것 같아요. 저도 이런 질문을 되게 많이 봤는데, 자율적인 주제이기도 하잖아요.

그래서 조금 과장되게 말해보면 저는 컴포넌트를 쪼개는 어떤 절대적인 기준 같은 건 없다고 생각해요.

어, 이게 왜냐하면 쌩뚱맞게 들릴 수도 있는데 우리가 보통 앱에서 표현하고자 하는 것이 트리 구조가 아니거든요.

우리가 표현하고자 하는 것이 뭘까요? 바로 정보예요.

저는 컴포넌트를 잘 쪼개는 절대적인 기준은 없겠지만, 상대적으로 잘 쪼개는 방법은 있다고 생각해요.

그런데 컴포넌트를 잘 쪼개게 되면 저는 우리가 표현하려는 정보에 좀 더 집중해야 된다고 생각합니다.

이번 챕터에서는 우리가 표현하려고 하는 데이터에 대해서 한번 이야기를 해볼게요.

제가 되게 일반적인 상황을 좀 가져와 봤는데요. 단순하게 소셜 미디어, 페이스북 같은 걸 만든다고 생각하고 그려보긴 했는데, 보시다시피 기본적인 모델도 꽤 되고 관계도 꽤 복잡한 것 같아요.

이렇게 간단한 상황도 이런데, 모델에 대한 요소가 많으면 100개 정도 생각해야 된다고 생각해 보면 엄청 더 복잡해질 것 같네요.

우리가 소셜 미디어 앱을 만든다고 가정했을 때 이런 일이 일어날 수 있어요.

다른 분이 피드를 쭉 내리면서 글을 읽고 있는데, 그 사이에 이제 제가 프로필 이미지를 변경한 거죠.

그래서 그분이 보시기에 먼저 쓴 글과 나중에 쓴 글의 프로필 이미지가 다른 거예요.

이런 상황을 일관성이 깨졌다고 표현을 해요.

이러한 일관성 문제를 해결하기 위해서 데이터를 잘 정리하고 컴포넌트의 전파해야 할 텐데요.

여기서 나오는 개념이 바로 단일 진실 공급원입니다. 싱글 소스 오브 트루스인데요.

만약에 특정한 상태가 바뀌었을 때 해당 상태를 우리는 모든 각 컴포넌트의 전파를 하는데, 이 상태를 여러 개 주지 말고 하나의 진실로 만들자는 개념이에요.

물론 이러한 생각 자체는 일관성 문제를 해결하는 데 좋지만, 문제는 이 단일 상태가 너무 커지기 때문에 어떻게 관리해야 될지 굉장히 막막하다 는 점이 있어요.

이런 부분을 해결하기 위해서 우리가 보통 알고 있는 리덕스나 몹엑스 같은 라이브러리들이 나오기도 했고요.

그런데 다시 한번 데이터를 볼까요?

우리가 표현하려는 데이터를 잘 살펴보면 그래프의 형태인 것을 알 수 있어요.

그리고 제가 이렇게 생각을 해봤을 때 뭔가 규격을 잘 만들면, 저 그래프를 표현할 수 있는 규격을 잘 만들면 우리가 아까 데이터 페이퍼를 정리한다고 표현했는데, 노멀라이즈하는 과정도 잘 말할 수 있을 것 같아요.

저는 그래서 어느 정도 규칙만 잘 따면 데이터를 이해하고 처리하는 것이 크게 복잡한 문제는 아니라고 생각합니다.

자, 그러면은 만약에 요런 JSON이 API의 응답으로 왔다고 가정해 볼게요.

이 데이터를 이제 데이터 일관성을 지킬 수 있도록 정규화(Normalize) 한번 해볼까요?

관계를 표현하는 필드들을 ID 값만 갖도록 변경한 뒤에 ID끼리 연결하는 모양으로 정규화했습니다.

어, 그런데 데이터 일관성을 위해서 이렇게 한 땀 한 땀 노력할 수도 있겠지만 음, 굳이 이렇게까지?

생각하시는 분도 분명 있을 것 같아요.

하지만 만약 이런 부분들을 큰 노력 없이 잘 표현하고 도와주는 도구가 있다면 어떨까요?

저는 이런 부분을 잘 도와줄 수 있는 도구가 바로 GraphQL이라고 생각합니다.

GraphQL을 사용하게 되면 앞서 설명한 모델 타입을 정의하는 것, 그리고 이를 통한 쉬운 정규화 그리고 쉽게 상태 관리를 할 수 있게 되는데요.

어, 앞서 보셨던 다음과 같은 JSON 구조는 다음과 같은 GraphQL 스키마로 표현할 수 있게 되고요.

각 모델 간의 관계는 그래프 QL 스키마를 통해서 다음과 같이 정의할 수 있게 됩니다.

그리고 그래프 QL 기반의 자동화된 상태 관리 툴을 도입하게 되면 저희가 별도의 프로그래밍을 하지 않아도 상태 관리가 모두 자동으로 되면서 데이터 일관성을 거의 완벽하게 달성할 수 있게 됩니다.

그래서 DECLARATIVE가 뭔데? - 원지혁

_engross

선언적 프로그래밍은 실행 순서와 방법을 의미하는 하우(How)를 최소화하고 무엇을 구현할 것인가에 해당하는 왓(What)을 극대화하는 방식입니다.

리액트와 GraphQL은 각각 UI 렌더링과 데이터 페칭 과정에서 복잡한 하우(How)를 추상화하여 코드의 의도와 실체를 명확하게 결합하도록 돕습니다.

반복되는 로직을 함수 단위로 분리하고 관심사 기반으로 컴포넌트를 설계하면 코드의 명확성이 높아지고 데이터 일관성을 효율적으로 유지할 수 있습니다.

임페러티브 방식의 가장 큰 문제는 **코드의 명확성이 결여**된다는 점입니다. 수천 줄이 넘는 코드 속에서 특정 UI 요소를 수정하거나 성능 개선을 시도할 때, 예상치 못한 사이드 이펙트가 발생할 가능성이 높으며 신규 입사자에게 코드를 인수인계하는 과정에서도 상당한 리소스가 소모됩니다.

반면 선언적(Declarative) 접근법은 **How를 최소화하고 What을 극대화**하는 것을 핵심 가치로 삼습니다. 이는 구현 방식이나 순서에 집중하기보다는, 결과적으로 '어떤 UI를 그릴 것인가'에 집중하게 함으로써 코드의 가독성을 높이고 예측 가능성을 향상시킵니다.

상태 관리를 통한 선언적 UI의 구현

기존의 정적인 코드에 인터랙티브한 상태(State) 개념을 도입하면, UI 조작 로직인 'How'를 추상화할 수 있습니다. 상태가 변경될 때마다 렌더 함수가 다시 호출되는 리액트 컴포넌트의 구조는 **UI를 데이터의 함수로 표현**하여 개발자가 DOM을 직접 제어하지 않아도 되게 만듭니다.

관심사의 분리와 데이터 일관성

과거에는 웹 문서를 HTML, CSS, JavaScript라는 역할 기반으로 분리했지만, 선언적 UI 패턴은 이를 허물었습니다. 이제는 기술적 역할이 아닌 **관심사(정보의 단위)를 기준으로 컴포넌트를 분리**하며, 이는 개발자가 앱의 트리 구조보다 다루고자 하는 데이터의 정보 전달에 집중하게 합니다.

복잡한 앱에서 데이터의 일관성을 유지하기 위해 '단일 진실 공급원(Single Source of Truth)' 개념이 도입되었으나, 관리할 상태가 비대해진다는 문제가 발생합니다. 이때 **데이터를 그래프 구조로 이해하고 이를 정규화(Normalize)하여 처리**하는 것이 중요합니다.

GraphQL은 이러한 데이터 정규화와 상태 관리를 자동화해주는 강력한 도구입니다. 스키마를 통해 모델 간의 관계를 명확히 정의함으로써 **데이터 페칭(Data Fetching)의 How를 라이브러리가 담당**하게 하여, 개발자가 데이터 일관성을 수동으로 관리하는 고통에서 벗어나게 합니다.

선언적 데이터 요청의 실천과 리팩토링

컴포넌트는 1차원적인 데이터가 아닌 그래프 형태의 정보들을 필요로 합니다. GraphQL의 프래그먼트 문법을 활용하면 **컴포넌트가 의존하는 데이터를 선언적으로 명시**할 수 있으며, 이는 결과적으로 각 컴포넌트가 무엇을 필요로 하는지 명확히 드러내어 코드의 의도를 직관적으로 만듭니다.

리팩토링에 있어서도 단순한 함수 분리가 아닌, **로직의 구조를 재정의하여 What에 집중**하는 것이 중요합니다. 예를 들어 미들웨어 내에서 `redirectIf`와 같이 조건을 분리하여 가독성을 높이는 기법은 코드가 담고 있는 비즈니스 의도를 명확하게 전달합니다.

새로운 기술(예: Relay 등)을 학습하는 과정은 단순히 도구 사용법을 익히는 것이 아니라 그 안에 담긴 '선언적' 사고방식을 이해하는 과정입니다. 이러한 **기술에 담긴 철학을 깨닫고 실천**할 때 더 나은 코드를 작성할 수 있게 됩니다.

당근마켓의 원지혁이며 'Declarative' 주제로 지난 1년간의 프론트엔드 개발 경험과 고민을 공유합니다.

소프트웨어 엔지니어이자 GraphQL 코리아 오거나이저이며, GraphQL 기반으로 백엔드/프론트엔드를 개발합니다.

Vue.js로 시작하여 현재 TypeScript, React, GraphQL을 주로 사용하며 고품질 앱을 빠르게 제공하는 방법을 고민합니다.

UI 표현 방식: 기존 방법과 Declarative UI

선언형 프로그래밍 전반보다는 '선언적' 개념이 와닿게 된 경험을 공유합니다.

웹 문서의 기본 표현 방식인 HTML은 트리 구조와 문법 규칙에 따라 요소가 배치됩니다.

페이지 이동 없는 동적 UI 변경을 위해 JavaScript가 등장했고, DOM 조작을 통해 구현됩니다.

2000년대 초반 Google Maps 등장과 함께 웹 API 개념이 생기면서 JavaScript 코드가 복잡해졌습니다.

명령을 순차적으로 실행하는 일반적인 JavaScript 코드를 'Imperative' 방식이라고 합니다.

Imperative 코드의 문제점: 코드 길이가 길어지면 특정 부분 찾기 어렵고, 리팩토링 시 영향 범위 예측 어려움, 신규 개발자 인수인계가 어렵습니다.

명확한 코드(누구나 같은 의미로 받아들일 수 있는 코드)를 만들기 어렵습니다.

'Thinking in React' 문서에 따르면, React 컴포넌트는 UI를 어떻게 그릴지(How) 고민 없이 무엇을 그릴지(What)에만 신경 쓰면 됩니다.

How는 '어떻게, 어떤 방식으로, 어떤 순서로'를 의미하고, What은 '무엇을, 어디에, 어떤 모양으로'를 의미합니다.

Declarative는 How를 최소화하고 What을 극대화하는 방법입니다.

Imperative 코드에서 `createElement`, `getElementById`, `appendChild`와 같은 부분은 How에 해당합니다.

How와 What을 분리하여 함수 형태로 만들면, What에 해당하는 코드가 더 직관적으로 변합니다.

동적인 기능 구현 시, How는 '어떻게, 언제, 어떤 타이밍에 바꿀지', What은 '무슨 데이터를 바꿀지, 어디에 보여줄지'에 해당합니다.

React의 상태 개념을 차용하여 How와 What을 분리합니다.

버튼 클릭 시 카운트 증가 코드에서 How와 What이 섞여 있는 것을 확인하고, 상태 개념을 도입하여 How를 분리합니다.

`render` 함수가 `setState` 호출 시마다 다시 호출되도록 선언적으로 작성하여 How를 제거합니다.

How를 제거하면 React 컴포넌트와 같이 UI에 더 집중된 코드가 됩니다.

관심사의 분리 (Separation of Concerns)

상태와 DOM 트리가 비대해지는 문제를 해결하기 위해 React에서는 컴포넌트 개념으로 앱을 분리합니다.

기존 웹 문서는 역할에 따라 HTML, CSS, JavaScript로 코드를 분리했습니다.

Declarative UI 패턴을 통해 JavaScript가 마크업처럼 작성 가능해지면서, HTML, CSS, JavaScript가 자연스럽게 섞이게 되었습니다.

이제 역할이 아닌 관심사를 기반으로 컴포넌트를 분리합니다.

컴포넌트를 쪼개는 절대적인 기준은 없으며, 앱에서 표현하고자 하는 것은 정보(데이터)입니다.

상대적으로 잘 쪼개는 방법은 표현하려는 정보에 더 집중하는 것입니다.

소셜 미디어 앱과 같이 모델이 많고 관계가 복잡한 경우를 예시로 듭니다.

사용자가 피드를 내리는 동안 프로필 이미지가 변경되어 게시글마다 이미지가 다르게 보이는 '일관성 깨짐' 문제가 발생할 수 있습니다.

일관성 문제를 해결하기 위해 데이터를 잘 정리하고 컴포넌트에 전파해야 합니다.

단일 진실 공급원(Single Source of Truth) 개념은 상태를 여러 개 주지 않고 하나의 진실로 만들자는 것입니다.

단일 상태가 너무 커져 관리하기 어렵다는 문제가 있으며, 이를 해결하기 위해 Redux, MobX 같은 라이브러리가 등장했습니다.

우리가 표현하려는 데이터는 그래프 형태이며, 이를 잘 표현할 수 있는 규격을 만들면 데이터 정규화 과정도 효율적으로 할 수 있습니다.

API 응답으로 온 JSON 데이터를 정규화하여 관계 필드를 ID 값으로 변경하고 ID끼리 연결하는 방식으로 일관성을 지킵니다.

GraphQL은 모델 타입 정의, 쉬운 정규화, 간편한 상태 관리를 통해 데이터 일관성을 돕는 도구입니다.

JSON 구조는 GraphQL 스키마로 표현 가능하며, 모델 간 관계도 스키마를 통해 정의할 수 있습니다.

GraphQL 기반 자동화된 상태 관리 툴을 사용하면 프로그래밍 없이 상태 관리가 자동으로 되어 데이터 일관성을 완벽하게 달성합니다.

React가 UI에 대한 How를 가져가듯이, GraphQL은 데이터 처리에 대한 How를 가져갑니다.

React 컴포넌트는 데이터를 필요로 하며, 데이터 의존성은 props 형태로 표현됩니다.

우리가 다루는 데이터는 1차원이 아닌 그래프 형태이므로, 컴포넌트도 그래프를 필요로 합니다.

GraphQL의 프래그먼트 문법을 사용하여 컴포넌트에 필요한 데이터를 선언적으로 표현할 수 있습니다.

Declarative하게 데이터를 요청하는 것은 각 컴포넌트가 필요한 데이터를 명시하면, 라이브러리가 이를 단일 요청으로 만들고 변경 사항을 자동으로 반영하는 것을 의미합니다.

Declarative UI, GraphQL, Declarative 데이터 페칭 모두 공통된 How를 분석하여 분리하고, 코드의 의도와 실체를 통합하는 과정입니다.

이를 위해 How와 What을 날카롭게 구분하는 안목이 필요합니다.

Express 기반의 로그인 여부 확인 미들웨어 리팩토링 예시를 통해 Declarative 방식의 개선을 설명합니다.

기존에는 `redirectIfNotLogin` 함수로 로직을 숨기는 방식이었다면,

Declarative 방식은 `compare` 함수를 인자로 받아 조건에 따라 리다이렉트하는 `redirectIf` 함수를 만들어 코드의 의도를 명확하게 드러냅니다.

새로운 생각은 새로운 기법을 만들고, 새로운 기법은 새로운 문법을 만듭니다.

Relay 라이브러리 학습을 통해 '선언적 데이터 패칭' 개념을 깨닫고 '선언적'의 의미를 더 잘 이해하게 되었습니다.

기술을 통해 그 안에 담긴 생각에 공감하고 깨달아 더 나은 코드를 작성하길 기원합니다.

당근마켓 회사 소개 및 채용 안내

당근마켓은 실력 있는 소수 정예로 일하며, 개인 성장을 중요시하고 수평적인 문화를 가지고 있습니다.

하는 일이 재미있고, 전문 분야에 자신감 있으며, 스스로 업무를 결정하고 적극적인 소통을 하는 개발자를 찾고 있습니다.

지원 방법은 de-graph.kr 채용 페이지를 참고하면 됩니다.

GraphQL에 대해 궁금하거나 토론하고 싶은 분들은 GraphQL Korea 커뮤니티에 참여를 환영합니다.

커뮤니티 활성화를 위해 어려운 질문보다 쉬운 질문이 더 많아야 한다고 생각합니다.

페이스북 그룹과 슬랙 채널을 통해 언제든지 질문할 수 있습니다.