(번역) 프런트엔드 아키텍처 시각화하기
원문: https://frontendatscale.com/issues/17
이해하기 쉬운 프런트엔드 아키텍처 다이어그램을 그리는 방법
안녕하세요, 여러분! 👋 지난 몇 주 동안 프런트엔드 아키텍처 워크숍 준비를 열심히 해왔는데요. 곧 여러분께 더 자세한 내용을 알려드릴 수 있을 것 같아 정말 설렙니다. 오늘은 그중에서도 특별히 C4 모델을 활용해 아키텍처를 시각화하는 방법을 살짝 미리 보여드리려고 합니다.
본격적인 이야기를 시작하기 전에 부탁 하나만 드려도 될까요? 혹시 이 이메일에 짧게라도 답장을 보내주실 수 있나요? 최근에 일부 구독자분들의 뉴스레터가 스팸함으로 분류되고 있다는 이야기를 들었는데, 여러분의 답장이 이 문제 해결에 큰 도움이 된다고 하더라고요.
답장엔 이런 내용을 써주시면 좋을 것 같아요.
- 여러분의 언어로 간단한 인사 한마디 (예: “hi”, “hola” 등)
- “제가 애용하는 자바스크립트 프레임워크는 ____예요”
- “다음 뉴스레터에서는 ____ 주제를 다뤄주세요” (요리 레시피만 빼주세요. 제가 요리와는 영 담을 쌓고 살거든요 😅)
도움 주셔서 미리 감사드립니다! 🙏 자, 이제 이번 주 이야기를 시작해 볼까요?
프런트엔드 아키텍처 시각화하기
사진: Pexels.com의 Leah Newhouse 촬영
제가 계속해서 발전시키려 노력하는 (그리고 모든 소프트웨어 엔지니어에게도 추천하고 싶은) 기술이 하나 있습니다. 바로 명확하고 간결한 다이어그램을 그리는 능력이죠.
사실 아키텍처 다이어그램을 만드는 건 그리 어렵지 않습니다. 대부분 박스와 화살표, 라벨로 구성되기 때문입니다. 하지만 보는 사람이 제대로 이해할 수 있게 그리는 건 또 다른 문제입니다.
다이어그램을 볼 때 사람마다 관심 있는 부분이 다릅니다. 예를 들어 프로덕트 매니저는 전반적인 아키텍처를 보고 싶어하는 반면, 프런트엔드 개발자는 UI 컴포넌트들이 서로 어떻게 상호작용을 하는지에 더 관심이 있을 겁니다. 하나의 다이어그램으로 여러 사람의 니즈를 만족시키기는 쉽지 않습니다.
만들기도 쉽고, 필요할 때마다 코드 베이스를 확대하거나 축소해서 볼 수 있는 다이어그램이 있다면 얼마나 좋을까요? 더 이상 상상만 하지 않으셔도 됩니다. C4 모델이 바로 그런 걸 가능하게 해 줍니다.
코드의 지도
C4 모델의 창시자인 사이먼 브라운은 C4를 코드의 지도를 만드는 방법이라고 설명합니다. 이 지도를 통해 우리는 방향을 잡을 수 있습니다(즉, 더 큰 시스템 안에서 우리 애플리케이션이 어디에 위치하는지 파악할 수 있습니다). 또한 다양한 독자들에게 우리의 아키텍처를 효과적으로 전달할 수도 있습니다.
C4 웹사이트에서 사이먼은 이렇게 설명합니다.
마치 구글 맵을 사용하여 관심 있는 영역을 확대하고 축소하는 것처럼, 다양한 상세 수준에서 코드의 지도를 만드는 방법입니다.
C4는 서로 다른 ‘확대 수준’에서 아키텍처를 표현할 수 있는 네 가지 기본 다이어그램을 제공합니다. 각각을 간단히 설명하자면 아래와 같습니다.
레벨 1: 시스템 컨텍스트 다이어그램
한 걸음 물러서서 전체 그림을 볼 수 있게 해주는 상위 수준의 개요입니다. 우리 시스템을 가운데 큰 상자로 표시하고, 여기에 시스템과 상호작용하는 사용자 및 다른 시스템들을 함께 보여줍니다.
시스템 컨텍스트 다이어그램은 특정 기술이나 프레임워크에 대한 세부 내용을 포함하지 않기 때문에, 기술에 익숙하지 않은 사람들과 아키텍처를 소통할 때 특히 유용합니다.
레벨 2: 컨테이너 다이어그램
소프트웨어 시스템은 애플리케이션이나 데이터 저장소와 같은 컨테이너로 구성됩니다. 예를 들어, 인터넷 뱅킹 시스템의 컨테이너에는 웹 애플리케이션, 싱글 페이지 애플리케이션, 모바일 앱, API, 데이터베이스 등이 포함될 수 있죠.
이 단계에서는 기술 선택에 관해 이야기하기 시작하므로, 이런 유형의 다이어그램은 주로 기술 담당자를 위한 것입니다.
레벨 3: 컴포넌트 다이어그램
컨테이너는 여러 컴포넌트로 구성됩니다(UI 컴포넌트와는 다른 개념입니다. 이건 잠시 후에 자세히 설명해 드리죠). 컴포넌트는 애플리케이션의 기본 구성 요소로, 클래스, 라우트, MVC 컨트롤러 등이 될 수 있습니다. 다음 섹션에서 프런트엔드 애플리케이션의 레벨 3 다이어그램 예시를 더 자세히 살펴보겠습니다.
이 수준에서는 실제 코드에 더 가까워지므로, 이런 종류의 다이어그램은 해당 애플리케이션이나 데이터베이스를 다루는 개발자들에게 특히 유용합니다.
레벨 4: 코드 다이어그램
마지막으로, 컴포넌트를 더 자세히 들여다보면 코드 수준의 구현을 볼 수 있습니다. 이 단계에서는 UML 클래스 다이어그램, 엔티티 관계 다이어그램, 또는 의존성 그래프를 사용해 클래스, 함수, 객체들이 어떻게 상호작용하는지 보여줄 수 있습니다.
코드 다이어그램의 상세 수준은 보통 필요하지 않기 때문에, 중요하거나 복잡한 컴포넌트를 문서화할 때만 사용하는 것이 좋습니다. 또한 IDE 플러그인이나 다른 도구(이 VSCode용 도구처럼)를 사용해 소스 코드에서 자동으로 이런 다이어그램을 생성하는 것이 좋습니다.
C4는 이런 다이어그램을 그리는 간단한 규칙도 제공합니다. 박스와 화살표에 어떻게 라벨을 붙일지, 그리고 배포 다이어그램과 같은 특정 상황에서 사용할 수 있는 보완적인 다이어그램 세트까지 제공합니다.
이제 코드의 지도가 생겼으니, 즐겁지만 때로는 위험할 수 있는 프런트엔드 개발의 바다를 항해하는 데 이것을 어떻게 활용할 수 있는지 살펴보겠습니다.
프런트엔드 아키텍처를 위한 C4 모델 적용
C4의 가장 큰 장점은 특정 애플리케이션 유형에 대한 가정을 전혀 하지 않는다는 점입니다. 덕분에 프런트엔드 아키텍처를 시각화하기에도 딱 좋습니다.
레벨 1과 레벨 2 다이어그램은 특정 기술에 대한 세부 사항이 많지 않아서, 원래 방식 그대로 사용할 수 있습니다. 저는 여러 직군이 함께 일하는 팀이라면 백엔드, 데이터, 모바일 개발자들과 함께 이 다이어그램을 그려보길 추천해 드립니다.
레벨 3과 4에서는 프런트엔드 개발자들에게 더 흥미로운 부분이 나옵니다. 웹 앱 컨테이너를 자세히 들여다보면(클라이언트 사이드 SPA든 Next.js나 Laravel 같은 프레임워크로 만든 ‘풀스택’ 앱이든), 프런트엔드 아키텍처의 마법 같은 세계로 들어가게 됩니다.
프런트엔드 아키텍처 세계에 대해 이런 말이 있습니다… 프런트엔드에서 일어나는 일은 프런트엔드에 머무른다! (네트워크 요청만 빼고요.)
농담은 접어두고(네. 농담이었으니, 구독 취소하지 마세요!), C4 모델의 레벨 3과 4를 프런트엔드 애플리케이션에 더 잘 맞도록 약간 수정하는 게 좋다고 생각합니다. 제가 주로 하는 방식을 소개해드려 보겠습니다.
레벨 3: 컴포넌트 -> 모듈
이 레벨에서 제가 선호하는 작은 변화는 ‘컴포넌트’라는 단어를 ‘모듈’로 바꾸는 것입니다. 프런트엔드 생태계에서 컴포넌트는 보통 UI 컴포넌트라는 매우 구체적인 의미로 쓰이기 때문에, 모듈이라는 단어가 좀 더 명확하다고 생각합니다.
물론 이렇게 바꿀 필요는 없습니다. 하지만 기존 애플리케이션에 C4를 도입하시는 거라면, 아마도 C4의 추상적인 개념들에 대한 여러분만의 용어가 이미 있을 겁니다. 그래서 여러분의 필요에 맞게 이름을 수정해서 사용하셔도 전혀 문제없다는 걸 알아두시면 좋겠습니다.
하지만 제가 가장 중요하게 생각하는 변화는 애플리케이션의 UI를 기준으로 프런트엔드 컨테이너를 모듈로 나누기 시작한다는 점입니다.
예를 들어, 제품 디자이너 쥴리엣 라가슈가 만든 Nook이라는 부동산 관리 앱의 UI를 한번 살펴볼까요? 이 앱을 싱글 페이지 애플리케이션으로 만든다면, 컨테이너 다이어그램은 이런 모습이 될 것 같습니다(자세히 보시려면 이미지를 전체 화면으로 열어보시는 것을 추천합니다).
여기서는 이해를 돕기 위해 각 모듈의 스크린숏을 사용했지만, 실제로는 보통 텍스트가 들어있는 박스로 표현됩니다.
본질적으로 모듈은 애플리케이션의 최상위 구성 요소입니다. 이 예시에서는 대시보드, 설정, 로그인 화면이 각각 별도의 모듈이 되죠. 보통 이런 모듈들은 앱의 최상위 경로(/dashboard, /settings, /login 같은)를 나타내지만, 반드시 그래야 하는 건 아닙니다. 예를 들어, 이커머스 사이트의 장바구니는 전용 경로가 없더라도 하나의 독립적인 모듈이 될 수 있습니다.
레벨 4: 코드 -> UI 분해
모듈을 자세히 들여다보면 어떤 코드 구조로 구현되는지 보이기 시작합니다. 객체지향 프로그래밍을 사용한다면 이 레벨에서 보통 UML 클래스 다이어그램을 보게 되겠죠. 하지만 현대의 컴포넌트 기반 프런트엔드 개발에서는 이런 종류의 다이어그램이 그다지 유용하지 않습니다.
대신 저는 레벨 4에서 특정 모듈의 UI를 개별 컴포넌트로 분해하는 것을 선호합니다. 이는 리액트가 대중화한 리액트로 사고하기와 비슷하지만, 저는 한 걸음 더 나아가 각 컴포넌트를 스크린, 기능, 컴포넌트라는 세 가지 유형으로 분류합니다.
- 스크린 — 일부 모듈은 여러 스크린으로 구성됩니다. 아래 예시를 보면 설정 모듈에는 개인정보, 멤버, 통합, 결제 설정을 탐색하는 탭들이 있죠. 이들은 모두 이 모듈 내의 독립적인 스크린이 되며(아마도
/settings/personal,/settings/integrations등의 하위 경로를 가지게 될 겁니다). - 기능 — 본질적으로 ‘큰 컴포넌트’입니다. 기본 컴포넌트와 구별할 만큼 복잡한 UI의 일부를 말합니다. 제가 쓰는 판단 기준은 이렇습니다. 만약 컴포넌트에 하위 컴포넌트가 너무 많아서 정리를 위해 자체 (중첩된) 컴포넌트 폴더가 필요하다면, 그건 기능입니다.
- 컴포넌트 — 우리가 알고 사랑하는 UI 컴포넌트들입니다. 크기는 크든 작든 상관없죠. 모듈 전체에서 공유될 수도 있고, 특정 스크린이나 기능에만 쓰일 수도 있습니다. 버튼, 표, 폼 요소, 아이콘 등이 모두 이 카테고리에 속합니다.
어떤 명명 규칙을 사용하든, 이런 식의 간단한 컴포넌트 계층 구조를 가지면 특정 컴포넌트가 아키텍처에서 어디에 적합한지 더 잘 이해할 수 있습니다.
레벨 4에서 다음으로 나오는 질문은 “이걸 정확히 어떻게 코드로 옮길까요?”입니다. 이 모든 컴포넌트는 어떻게든 서로 연결되어야 하고, 정리를 위한 폴더 구조도 필요하죠. 그래서, 이걸 어떻게 하는 게 가장 좋을까요?
정말 좋은 질문이네요! 다행히도 이 내용은 곧 열릴 프런트엔드 아키텍처 워크숍에서 자세히 다룰 예정입니다. 참고로 말씀드리면, Frontend at Scale 구독자분들은 무료로 참여하실 수 있습니다.
관심이 있으시다면 계속 지켜봐 주세요 — 워크숍에 대한 더 자세한 내용이 곧 공개될 예정입니다 ✨
살펴볼 만한 링크들
📕 읽을거리
- 코드베이스를 처음부터 다시 작성하는 것을 고려 중이신가요? 조엘 스폴스키는 이것이 회사가 저지를 수 있는 최악의 전략적 실수라고 말하며, 이 고전적인 에세이에서 그 이유를 설명합니다.
- 제이크 아치볼드가 View Transitions API 사용 시 가장 흔한 문제인 화면 비율 변경 처리에 대해 상호작용 가능한 데모가 가득한 상세한 글을 작성했습니다.
- 새로운 React Hook이 등장했습니다.
useOptimistic이라고 하는데요, 긍정적인 성격 때문이 아닙니다. 샘 셀리코프가 이것의 작동 방식을 설명하는 훌륭한 블로그 포스트를 작성했습니다. - 알렉스 콘도프가 탄탄한 설계 방식을 활용한 리액트 애플리케이션 구축에 대한 조언이 가득한 리액트 클린 아키텍처에 관한 방대한 글을 작성했습니다.
🎥 볼거리
사이먼 브라운은 C4 모델의 창시자일 뿐만 아니라 Structurizr라는 다이어그래밍 도구의 제작자이기도 합니다. 이 도구를 사용하면 우리의 아키텍처를 코드로 모델링할 수 있죠. GOTO 2021 강연에서 그는 Structurizr DSL(도메인 특화 언어)의 사용법과 Mermaid나 PlantUML 같은 일반적인 다이어그래밍 도구 대신 모델링 언어를 사용할 때의 장점을 보여줍니다.
🎧 팟캐스트 켈빈 오메레숀과 함께하는 The Boring JavaScript Stack
Laravel이나 Rails 같은 모든 기능이 포함된 프레임워크를 좋아하지만 백엔드에서도 자바스크립트를 계속 사용하고 싶으시다면, the boring stack에 대해 알아보시는 걸 추천드립니다. Sails.js(Node.js용 MVC 프레임워크)와 Inertia 라이브러리를 기반으로 한 풀스택으로, UI 레이어에 리액트, 스벨트, 뷰를 사용할 수 있게 해줍니다. Frontend Fire 팟캐스트에서 켈빈 오메레숀과 진행한 이 인터뷰는 이 새로운 스택을 소개하는 훌륭한 입문 자료입니다.
오늘은 여기까지입니다, 여러분! 끝까지 읽어주셔서 감사합니다. 이 뉴스레터가 마음에 드셨다면, 친구들이나 동료들과 공유해 주시면 정말 감사하겠습니다. (마음에 들지 않으셨다면 못마땅한 누군가에게 공유해보시는건 어떠신가요? 😉)
누군가 이 뉴스레터를 전달해주셨나요? 우선, 그분이 얼마나 멋진 분인지 말씀해 드리고, 다음 호를 받아보고 싶으시다면 뉴스레터 구독을 고려해보세요.
여러분의 모든 댓글을 읽고 답변 드립니다. 피드백이나 질문이 있으시다면 트위터로 연락하시거나 이 이메일로 직접 답장해 주세요.
좋은 한 주 보내세요 👋
– 맥시
