프론트엔드 아키텍처(Architecture)란?

처음에는 그냥 프론트엔드 개발을 하면서 화면에 잘 보이기만 하고 코드만 잘 짜면 된다는 생각을 가지고 있었다.

하지만 취업의 문은 높았고, 나는 아직 우물 안 개구리였다는 사실을 깨닫게 되었다.

 

 

기술 면접을 준비하면서 단순한 개발 스킬만으로는 부족하다는 걸 느꼈고, 

그때부터 자연스럽게 CS(computer Science) 전반에 대한 공부를 시작하게 되었다.

 

그 과정에서 "아키텍처" 라는 개념이 눈에 들어왔다.

 

아키텍처

아키텍처를 간단히 말하면 시스템의 구조를 설계하는 일을 의미한다.

 어떻게 보면 소프트웨어에서 어떤 기술을 어떤 방식으로 조합해서 전체 서비스를 구현할 것인가에 대한 큰 그림 설계도 라고 할 수 있다. 쉽게 말해, 성능, 유지보수, 협업, 확장성을 고려해 시스템을 나누고 연결하는 전략이다.

 

프론트엔드 아키텍처

 아키텍처가 어떻게 보면 소프트웨어나, 전체 서비스를 구현, 구성하는 큰 설계도 라고 한다면, 

 프론트엔드에서는 어떤 것을 아키텍처라고 하는지 궁금증이 생겼다.

 

 프론트엔드는 주로 브라우저에서 사용자와 직접 상호작용하는 영역으로 

 그걸 체계적으로 설계하는 방식이 바로 프론트엔드 아키텍처라고 한다.

 

 아키텍처는 상호작용하는 영역을 분담한다고 했으니, 

 어떻게 보면, 우리가 만드는 UI 안에서 사용자 클릭, 입력, 이동, 데이터 변경 렌더링 같은 걸 

 누가 어디서, 어떤 책임으로 처리할지 설계 자체가 바로 프론트엔드 아키텍처의 본질이다. 

 

 내가 만든 Board 게시판 프로젝트를 참고하여.

 https://github.com/hanabe02/board 

 

왜 이런 아키텍처(구조)를 설계하게 되었는지 논리적으로 설명해 보겠습니다.

 

현재 Board 게시판은 

   React + Redux + Redux-Saga + Axios + Rest API 조합을 기반으로 한,

   Flux 아키텍처 기반 + 관심사 분리 + 계층 구조 설계로 구성된 게시판이다.

 

폴더 설계 구조 

  관심사 분리 (Separation of Concems) 를 통해

   ㄴ 기능별로 폴더를 나누었다. api, redux, pages, styles 등

  

  관심사를 분리한 이유 

    1. 기능별로 코드를 분리하여 어느 파일이 어떤 역할을 하는지 명확해지고.

    2. 새로운 기능이 생겨도, 기존 구조에 맞춰 

       ㄴ pages, redux, api 등에 모듈만 추가하면 된다.

    3. 폴더 구조가 명확하면 역할 분담이 쉬워지고. (협업 효율 증가)

       ㄴ api 담당, pages 담당, 나눠서 작업을 할 수 있다.

 

 

상태 관리 구조

  Flux 아키텍처 기반 Redux를 사용하여 단방향 데이터 흐름을 유지했다.

  

  단방향 데이터 흐름은 데이터가 하나의 방향으로만 흐르는 구조로

    ex) UI - Action - Reducer - Stroe - UI 업데이트

 

  이런 단방향 흐름은

     1. 디버깅과 상태 추적이 쉬워지고,

     2. 비즈니스 로직 분리를 통해 

        ㄴ UI 컴포넌트는 화면만 그리면 되고,

            상태 변경 로직은 Redux 에 위임 할 수 있다.

     3. 예측 가능한 상태 (Predicatable State)

         ㄴ 같은 Action 과 상태에서 항상 같은 결과가 나오는 순수 함수(Reducer)를 사용하여

             테스트와 리펙토링이 안전하다.

 

라우팅 구조

  SPA (Single Page Application) 구조를 사용

  App.jsx 안에서 /react-router-dom 으로 페이지를 나누었다.

import { Routes, Route, Navigate,  } from 'react-router-dom';

function App() {
  return (
    <Routes>
      <Route path="/" element={<Navigate to="/login" />} />
      <Route path="/login" element={<LoginPage setIsLoggedIn={setIsLoggedIn} />} />
      <Route
        path="/board"
        element={
          <PrivateRoute isLoggedIn={isLoggedIn}>
            <BoardPage />
          </PrivateRoute>
        }
      />
      <Route
        path="/write"
        element={
          <PrivateRoute isLoggedIn={isLoggedIn}>
            <WritePage />
          </PrivateRoute>
        }
      />
      <Route
        path="/board/:boardId"
        element={
          <PrivateRoute isLoggedIn={isLoggedIn}>
            <BoardDetailPage />
          </PrivateRoute>
        }
      />
    </Routes>
    
  );
}

export default App;

 

  이런 구조적 장점 (왜 SPA 구조로 라우팅을 구현했을까)

    1. 빠른 페이지 전환 

         ㄴ 전체 페이지를 새로 불러오지 않으니, 사용자 체감 속도가 훨씬 빠르다.

    2. 페이지 상태 유지

         ㄴ 글 목록에서 5페이지 보던 상태 그대로 유지되고, 다시 돌아와도 유지된다.

    3. 백엔드 트래픽 감소

         ㄴ 매 요청마다 서버에서 HTML을 새로 내려주지 않아서, 서버는 API만 처리하고

             라우팅은 클라이언트가 담당한다.

 

 비동기 처리 구조

 Side Effect 는 "순수하지 않은 연산" 으로

    ㄴ API 호출, setTimeout, 로컬스토리지 접근, 데이터베이스 요청 같은 것들.

        React 컴포넌트 안에서 이런 걸 직접 처리하면

        UI랑 로직이 섞여 버려 코드가 지저분해지고 테스트도 힘들어진다.

 

  때문에 Redux middleware 을 사용하여 비동기 로직을 UI 에서 분리한다.

  

  비동기 로직을 사용하는 이유는

    1. 비동기 로직을 UI 에서 분리 하여 API 호출 로직을 컴포넌트 밖으로 빼낸다.

    2. 데이터 흐름 추적이 명확해진다. action - middleware(Saga) - API - 결과 dispatch

    3. 확작성 높은 구조 

         ㄴ 로딩 상태, 에러 처리, 토큰 갱신, 재시도 로직 등도 미들웨어에서 쉽게 추가 가능하다.

 

API 모듈 분리

  API 통신 관심사 분리

    ㄴ api/ 폴더에서 서버 통신 로직을 UI 와 분리한다.

 

  

  API 호출을 추상화해 UI 와 분리하는 이유는 

  API 주소(API 연결 시 사용하는 서버 주소), 요청 방식이 변경되더라도 컴포넌트 코드 수정 없이 API 모듈만 수정하면 된다.

 

  즉, "유지보수성과 테스트 용이성을 확보 할 수 있다."

 

엔트리포인트 설계

  구조적 App 구성을 통해 main.jsx - App.jsx - pages 구조로 앱 흐름이 명확해진다.

  

  이렇게 설계한 이유는 구조적 흐름이 명확 해지면 

    main.jsx 에서 root DOM 을 지정하고

                            ㄴ React 컴포넌트를 렌더링하는 출발점이 된다. (js 실행)

                                렌더링이 이해가 안된다면 https://o-ohi-code.tistory.com/54 참고

    

     App.jsx 에서 layout과 Router를 제어하고

    실제 화면 구성은 pages /에서 관리 하여 

  

큰 틀에서 앱의 진입 - 페이지 라우팅 - 화면 구성 이라는 흐름이 명확해지기 때문이다.

 

 

 

 지금에서야 느끼는 거지만, 내 프로젝트 안에서도 생각보다 많은 아키텍처적 선택이 녹아 있었다는 것을 알 수 있었다.

 

 솔직히 프로젝트를 구현할 단계에서는 이런 아키텍처는 하나도 생각 안 하고 그냥 배웠던 기술이나 구현하고 싶은 

 기술 같은 거만 때려 넣었었는데, 아키텍처가 무엇인지 어떤 역할을 하는지 이해할 수 있는 시간이었다.

 

 아키텍처를 잘 알아야 한다는 말도 단순히 코드를 짜는 걸 넘어, 

   어떤 문제를 어떤 구조로 풀 것인지, 를 설계할 수 있는 능력을 가진다는 의미이다.

 정리하면 아키텍처는 결국

    기술을 가지고 "어떻게 더 잘 나눌까, 더 잘 연결할까, 더 잘 바꿀 수 있을까"

    를 고민하는 구조적 사고인 것이다.

   

    단순히 그림을 그리는 것, 설계를 하는 것이 아닌 

       ㄴ 성능, 유지보수, 확장성, 협업 편의성을 고려해서, 전체 시스템을 효율적으로 만드는 설계 전략이다.

 

JWT, OAuth, Firebase, CDN... 이런 것들은 도구 또는 기술 스택이라고 표현하고

  그걸 어떻게 아키텍처 내에 배치하느냐가 설계인 것이다.

   

아키텍처라는 게 주관적일 수 있기 때문에.

 

아키텍처 설계 시 왜 이렇게 아키텍처(구조)를 설계하였나요? 라고 묻는다면

 자신의 주관을 논리적으로 말하는 것이 아주 중요한다.