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

오늘 이제 '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가 뭔데? - 원지혁

Scripts