최근에 회사에서 ui-library처럼 사용할 global-package를 만들었었다. 이름은 FCC (Flex Custome Contract - Flex 커스텀 계약서)로 고객사에서 커스텀 한 계약서(근로, 연봉, 경업금지 등..)를 간편하게 등록 및 관리할 수 있게 하였다.

계약서에 들어가야 하는 여러 placeholder들을 채워 넣어야 하는데 각각의 로직이 매우 복잡하게 이루어진다. 예를 들면 이름, 계약일, 연 근무 시간, 초과 근로 수당 등이 있다.

근로자 A의 연 근무 시간을 구하기 위해 주당 일하는 시간 및 휴게 시간, 휴일 근로 여부와 시간, 연봉 정보 등 여러 가지의 데이터가 필요한데 척 보기에도 복잡하게 생긴 데이터들을 소수점 단위로 계산해야 한다.

그리고 FCC에선 이런 placeholder들을 모두 계산해서 자동으로 지정된 위치에 넣어주는 역할을 한다.

FCC를 라이브러리처럼 만든 이유는 Flex Client(클라이언트 - ts) Aws lambda(서버 - js)에서 사용해야 하기에 어차피 build 파일이 필요한 구조라면 libray처럼 만들어서 어디와도 의존성을 완전 제거해보고 싶었다.

비하인드 😢

FCC는 현 product에 영향력이 강한 feature를 개발하는데 사용해야 해서 최대한 이쁘고 완벽하게 만들려고 노력했다. 그리고 셋업을 진행하며 피드백과 코드리뷰를 많이 받고 기쁜 마음으로 반영했다.

하지만... feature의 방향성이 바뀌면서 library pr을 close했다.

열심히 만든 FCC가 close 된 게 너무 아쉬워서 블로그 글로 남겨본다.

왜 rollup인가 ❓

rollup이 생소하고 익숙하지 않은 사람이 있을 수 있다. 애초에 라이브러리화하는 패키지가 webpack으로 빌드되는 react (cra 기준)로 개발되는데 webpack을 사용하면 된다고 생각할 수 있다.

맞다. webpack으로 빌드해도 ui-library를 만드는데 아무런 문제가 없다. 다만, webpack과 비교했을 때 라이브러리로써 얻을 수 있는 이점이 몇 있다.

• 웹펙에서는 ESM 번들이 힘들다. -> rollup은 가능
• 복잡한 웹펙보다 설정이 쉽다.
• build 결과물이 좀 더 가볍다
• webpack보다 강한 tree shaking을 지원한다

이를 제외하고 개인마다 느끼는 이점은 다 다르겠지만 보편적인 예를 들어보았다.

FCC의 rollup 👀

FCC를 설계할 때 rollup 말고 webpack을 사용할 수도 있었다. 그런데도 rollup을 사용한 이유는 위에 나열되어있는 이유가 대부분이다.

개인적으로 esm과 cjs를 둘 다 제공하고 싶었고, 최근에 rollup관련 블로그를 많이 읽으면서 package.json의 강력함을 알게 되어서 이를 활용 해보고 싶기도 하였다.

rollup setting ⚒

FCC는 typescript + react + scss + rollup의 구조로 이루어진다. 그리고 cjs와 esm 빌드를 제공한다. (FCC와 동일한 세팅을 하겠습니다.)

+eslint를 적용하고 깔끔한 환경에서 개발 하려 했었는데 전부 다 세팅하고 보니까 상위 package에서 적용되고 있는 별도의 lint때문에 내가 설정한 lint는 먹히지 않았다.

1. package.json init

먼저 package.json을 만들기 위해 터미널에 명령어를 작성해준다.

npm init

명령어를 작성하고 나면 여러 질문을 할 것이다. 전부 엔터 누르고 마지막에 yes 하면 된다. 그러면 package.json 파일이 생성된다. 그리고 이어서 필요한 모듈들을 다운로드한다.

명령어는 네 줄 다 작성해야 한다.

// babel
npm i -D @babel/core babel-preset-react-app

// rollup
npm i -D @rollup/plugin-commonjs @rollup/plugin-json @rollup/plugin-node-resolve rollup rollup-plugin-peer-deps-external rollup-plugin-postcss rollup-plugin-typescript2

// typescript, react
npm i -D @types/react typescript

// postcss
npm i -D node-sass postcss postcss-loader postcss-prefixer

모든 모듈이 다운로드 되고 나면 package.json에 peerDependency를 추가한다. (peerDependency는 간단히 말해, 현 package(FCC)에 모듈을 다운하는 게 아니라 package를 사용하는 쪽(FCC를 사용하는 곳)에서 dependeny를 갖고 있어야 한다.)

{
  ...
  "devDependencies": {
    ...
  },
  "peerDependencies": {
    "react": "^16.8.6",
    "react-dom": "^16.8.6"
  }
}

peerDependency를 끝으로 모듈 다운로드는 끝이 났다.

그리고 build파일들을 외부에서 캐치할 수 있게 타입들과 빌드파일들을 package.json에 명시해주어야한다.

+추가로 간편 명령어 등록도 해주었다.

{
  "name": "flex-customer-contract",
  "version": "1.0.0",
  "description": "components for contract in flex",
  "license": "UNLICENSED",
  // type 명시
  "types": "lib/index.d.ts",
  // 외부에서 접근할 index 명시
  "main": "dist/esm.js",
  "directories": {
    "example": "example"
  },
  "scripts": {
    "start": "npm run exam & npm run watch",
    "build": "rollup -c",
    "watch": "rollup -cw",
    "exam": "cd example && npm start",
    "lint": "eslint . --ext .js,.jsx,.ts,.tsx"
  },
  "author": "junwoo@flex.team",
  "devDependencies": {
    ...
  },
  "peerDependencies": {
    ...
  }
}

2. rollup config

다음으로 rollup.config.js 파일을 생성한다. rollup은 특이하게 config를 배열로 설정할 수 있다. 배열로 설정하게 되면 배열의 인자에 맞춰서 여러 개의 build파일이 생성된다.

import pkg from './package.json';
import typescript from 'rollup-plugin-typescript2';
import peerDepsExternal from 'rollup-plugin-peer-deps-external';
import postcss from 'rollup-plugin-postcss';
import postcssPrefixer from 'postcss-prefixer';
import resolve from '@rollup/plugin-node-resolve';
import commonjs from '@rollup/plugin-commonjs';
import json from '@rollup/plugin-json';

const extensions = ['.js', '.jsx', '.ts', '.tsx', '.scss'];

process.env.BABEL_ENV = 'production';

function setUpRollup({ input, output }) {
  return {
    input,
    exports: 'named',
    output,
    watch: {
      include: '*',
      exclude: 'node_modules/**',
    },
    plugins: [
      peerDepsExternal(),
      json(),
      resolve({ extensions }),
      commonjs({
        include: /node_modules/,
      }),
      typescript({ useTsconfigDeclarationDir: true }),
      postcss({
        extract: true,
        modules: true,
        sourceMap: true,
        use: ['sass'],
        plugins: [
          postcssPrefixer({
            prefix: `${pkg.name}__`,
          }),
        ],
      }),
    ],
    external: ['react', 'react-dom'],
  };
}

export default [
  setUpRollup({
    input: 'index.ts',
    output: {
      file: 'dist/cjs.js',
      sourcemap: true,
      format: 'cjs',
    },
  }),
  setUpRollup({
    input: 'index.ts',
    output: {
      file: 'dist/esm.js',
      sourcemap: true,
      format: 'esm',
    },
  }),
];

위 config파일을 간단히 설명하면

• setUpRollup이라는 함수를 만들어서 rollup config setting을 한다.
• index.ts파일을 불러와서 빌드하고 각각 dist/cjs.js와 dis/dsm.js로 추출한다.
• source-map파일을 함께 만들며 각각의 format은 cjs, esm으로 한다.
• peerDependency를 사용할 수 있다.
• json파일을 읽을 수 있다. (package.json을 읽기 위함)
• ts 컴파일이 가능하다.
• postcss를 통해 scss를 컴파일링 할 수 있다. 그리고 scss를 통해 만들어진 파일들의 이름앞에 prefix를 설정한다.

3. tsconfig.json 설정

FCC는 타입스크립트를 사용하기 때문에 ts를 관리하는 tsconfig 파일을 만들어 줘야한다. (tsconfig 설정은 ts빌드 파일 관련한 설정을 제외하곤 생략)

{
  "compilerOptions": {
    "declaration": true,
    "declarationDir": "./lib", // lib폴더에 ts 타입 속성을 빌드한다.
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "module": "es6",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "jsx": "react",
    "typeRoots": ["@types"]
  },
  "include": ["**/*.tsx", "**/*.ts", "@types", "index.ts"],
  "exclude": ["node_modules", "build", "dist", "lib", "example", "rollup.config.js"]
}

4. 테스트 환경 구성

FCC는 라이브러리기 때문에 다른 React 프로젝트에서 install 해서 테스트를 해봐야했다. 때문에 나는 cra를 이용하여 테스트 환경을 구성하였다.

// rollup.config.js가 있는 path에서
create-react-app example

그리고 cra로 만들어진 package.json 에 FCC를 install 하였다.

{
  "name": "example",
  "version": "0.1.0",
  "dependencies": {
    "@testing-library/jest-dom": "^5.11.4",
    "@testing-library/react": "^11.1.0",
    "@testing-library/user-event": "^12.1.10",
    // 요기
    "flex-customer-contract": "file:..",
    "react": "^17.0.1",
    "react-dom": "^17.0.1",
    "react-scripts": "4.0.1",
    "web-vitals": "^0.2.4"
  },
  "scripts": {
    "start": "PORT=8000 react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  }
}

package.json에서 FCC를 install 할 때 path를 file:..으로 해주었는데, example 밖에 존재하는 FCC의 package.json에서 index.js를 main으로 설정해 주었기에 동작한다.

5. index.ts 생성 및 개발

기본적인 세팅이 마무리되었으니 직접 ts, tsx파일을 생성해서 library를 만들어야한다.

먼저 명령어로 rollup watch를 실행시킨다. rollup watch는 react의 hot-loader와 같은 역할을 한다. 그리고 example에서 테스트 해야하니까 함께 실행시킨다.

// ter 1
npm run watch

// ter 2
npm run exam

본격적으로 개발에 들어가서 *.scss파일들의 타입을 정의한다.

// @types/index.d.ts
declare module '*.scss' {
  const content: { [className: string]: string };
  export = content;
}

그리고 root가 될 index.ts와 demo component Input.tsx 를 작성한다

// index.ts

export { default as Input } from './components/Input';

// components/Input.tsx
import React from 'react';

import 'index.scss';

const Input = () => {
  return (
    <div class="like-input">인풋인 척 하는 div</div>
  );
};

export default Input;

그리고 scss테스트를 위해 index.scss파일을 생성한다.

// index.scss
.like-input {
  width: 20px;
  height: 20px;
  background: red;
}

6. 라이브러리 테스트

빌드가 성공적으로 돌아가면 /example/src에서 FCC를 install후 사용할 수 있다.

import React from 'react';
import * as FCC from 'flex-customer-contract';

function App() {
  return (
    <div className="App">
      <FCC.Input />
    </div>
  );
}

export default App;

코드리뷰로 코드 다듬기 ✨

코드리뷰 과정에서 53개의 코멘트를 받았다. 그리고 그 중 반영하면서 삽질을 많이 했던 부분들을 정리해보았다.

1. 절대경로를 설정하면 build 결과물이 회손될 수 있다. (path문제)
2. tslint는 deprecated 되었다. -> eslint로
3. rollup이 모노레포로 변화하면서 @rollup/~의 꼴로 package들이 변했다.
4. rollup-plugin-typescript2 package는 build시간을 많이 저하시킨다.
5. ant design의 build를 봤더니 .css, .js 이렇게만 build하더라. -> FCC도 이렇게 해보자!

FCC잘가 🧵

FCC가 close된 것은 아쉽지만 재미있게 셋업 했던 것 같다.

요즘들어 회사일이 많이 바빠서 피곤했는데 잠시나마 코딩이아니라 빌드 셋업을 하니까 뭔가 많이 배운 것 같아서 기분이 좋다.

+) 최근 받은 투자에 힘입어 전 직군에서 함께 의지하며 성장하는 좋은 동료 분들을 모시고 있습니다. 관심이 가시거든 많은 지원 부탁드립니다. flex 채용 링크 바로가기 😆

앞으로 한달 간격으로 회고를 써보기로 했다. 앞으로 계속 될 나의 개발자 인생의 첫 걸음을 땐만큼 열심히 하고싶은 마음 뿐이다.

회사

나는 소프트웨어 마이스터고등학교를 재학 중 이다. 덕분에 고3인데도 불구하고 현장실습이라는 명칭으로 회사에 취업할 수 있었다. 나는 지금 Flex 주식회사 에 다니고 있다. 회사에 입사부터 퇴사까지 모든 인사관리업무를 대신 하는 B2B SaaS 솔루션을 제공하는 따끈따끈한 스타트업이다. (FLEX는 아름다운 미래, 밝은내일이 기다리고있다.😎 난 나옹이다옹)

간단한 취업 스토리를 읊어보면..

면접 🤦🏻‍♂️

나는 친구들 사이에서 취업을 빨리한 편이 아니었다. 친구들이 하나둘 씩 취업을 하고 학교에서 떠나가는 모습을 보고 조바심을 느끼고 두려웠다. 게다가 나는 병역특례를 목표로 취업을 하려고 결심했었기에 도전할 수 있는 폭이 좁았다.

병역 TO를 갖고있는 회사는 서류부터 탈락했고 어찌저찌 1차, 2차합격을 하면 코딩 테스트라는 벽에 막혀 떨어지기 일쑤였다. 이렇게 계속해서 떨어진 기업들은 내가 욕심을 갖고 너무 큰 회사에 지원한게 아닌가 싶기도 하였고 아직 내가 많이 부족함을 느낄 수 있었다.

그렇게 계속해서 도전하고 선택하던 도중 학교 선배 한명이 사내추천으로 나를 넣어줬다. 꽤나 큰 회사였고 아는사람도 있었기에 지원서를 드렸더니 서류 통과를 받았다. 그리고 이어서 코딩 과제를 진행하였고, 결과는 정말 좋았다.

회사의 2차 면접 공지를 받고 꼭 합격하겠다는 마음으로 공부하고 준비하던 도중 충격적인 소식이 들려왔다. 만약 내가 합격한다 한들 2021년도에 병역특례 혜택을 받는게 힘들다고했다. (😭)

Flex 🏢

그러던 도중 학교를 통해 Flex라고 하는 설립된지 2년도 안된 스타트업의 정보를 알게 되었다. 처음에는 이렇게 작은 회사에 들어가봐야 미래 보장도 안되고 성장하기도 힘들거라는 걱정이 앞섰다. 하지만 물불 가릴 처지가 아니었기 때문에 걱정되는 마음으로 서류를 넣었다. 서류를 넣고 하루 정도가 지나자 화상 인터뷰 요청이 왔고, 나는 기쁜마음으로 수락하였다.

Flex와 인터뷰를 마치고 난 뒤 든 생각은 딱 이거였다.

조금 회사가 작은 것 같은데.. 이 것 빼면 다 좋은데? (오해하지 마세요. 저는 Flex가 좋습니다. 이건 생각만.. 🤓)

첫 술에 배부를 수 없다고 하지만 회사의 대외적으로 알려진 정도가 친구들과 꽤 차이가 나서 자랑하고 싶었지만 남들이 부럽기만 했다. 그리곤 이미 취업한 것 마냥 김칫국을 마시다가 약속한 태크인터뷰 날짜가 다가오고 회사로 면접을 보러 갔다.

면접을 보면서 '아 Fit이 잘 맞는다는게 이런거구나' 하는 생각이 들정도로 물 흐르듯이 진행되었다. 그리고 결과는 대 성공이었다! (나는 면접이 끝나고 34일이 지나도록 결과가 안나오길래 떨어진 줄만 알았는데, 알고보니까 면접 이후 1시간도 안되서 합격 통보를 전했다고 한다. ~학교에서 일부로 늦게 알려줬었다. 왜 그런 건지..~~)

아무튼 이렇게 우여곡절 끝에 Flex에 취업 하고 지금은 Core Squad에서 열심히 클라이언트 개발을 하고 있다.

내가 한달동안 해온 일

일주일의 적응 기간

처음에 회사에 오고 일주일동안은 회사에 적응하고 코드를 읽기 바빴다. COVID 19때문에 회사에서 제공하는 맥북이 중국에 묶여있어서 내 개인 맥북으로 일을 했던 것 같다.

우리 회사는 FDS(Flex Design System)라고 하는 디자인 시스템을 사용한다. 마치 ant design같이 모든 요소를 템플릿 화 시켜서 개발한다. 개인적으로 사이드 프로젝트를 하면서 꼭 한번 만들어보고 싶었던 구조였는데 회사에 와서 직접 사용해보니까 내 생각만큼 좋기도 하고 그만큼 단점도 있는 것 같고 싶다.

바로 Product 개발?! 😳

일주일간 회사에 적응기간(?)을 갖고 개발 장비를 받았다. 맥북 16인치에 최고옵으로 회사에서 노트북을 준비해주었다. 새로운 장비를 받았다는 설레임에 기쁘고 신나서 더 열심히 했던 것 같다.

이것 저것 개발할 준비를 하고 Planning Meeting에 참가했다. (애자일 스럽게 squad단위로 팀을 나누고 개발하는 모습이 나도 이제 진짜 프로구나 라는 걸 세삼 느끼게 해주었다.) 미팅에서 서로 얘기를 나누다가 역할을 배정했었다. 회사에 신입으로 입사하면 이것 저것 배우고 사수님의 뒷바라지하는 역할을 하거나 귀찮은 노가다 작업 등을 하게 될 줄 알았는데 처음부터 feature개발에 참여하게 되었다.

feature 개발이라고 해서 많이 긴장하고 설레었는데 그냥 하다보면서 느낀게 '뭐야 그냥 학교에서 큰 프로젝트 할 때랑 별로 차이가 없잖아?' 라는 생각이 좀 강하게 남았다. 학교에선 많이 바쁘면 프로젝트 5~6개 정도를 동시에 진행 하곤 했는데 지금은 그냥 매일매일이 그렇게 바쁘게 움직이면서 개발하는 느낌? 정도다.

흠.. 개발은 뭔가 비슷하고요.. 다른게 좀 많이 다르네요 👀

솔직히 말해서 개발하는건 더 굴려주셔도.. 잘 할 수 있을 것 같다. (물론 시간이 뒷 받쳐준다면..!)

학교에서 프로젝트를 진행하면서 최대한 실무와 비슷하게 개발하려고 노력하다보니까 그런 것 같다.

그리고 개발적인 측면보다 일을하면서 동료들과의 커뮤니케이션이나 코드 컨벤션, 마인드 컨트롤 등을 더 많이 배우고 필요하다고 생각이된다. 일주일에 2~3번 정도 하루의 절반 정도를 쏟는 planing meeting과 역할 챕터 별 미팅이 있는데 (나는 PE(Product Enginner) meeting과 FE(Front Enginner) meeting에 참석한다.) 이렇게 모여서 실무 경험이 짱짱👍 하신 분들이 대화하는 걸 보고있으면 나는 한없이 작아진다.

그래도 한 4~5번 참석하고 나니까 나도 뭔가를 해야할 것 같아서 용기를 내보는 중이다.

뭔가 내가 TL이 된 것 같다.

현재 내가 속해있는 core squad가 맡고 있는 part는 크게 3가지로 나뉜다. 그 중 한가지를 내가 혼자 FE(Front Enginner)작업을 해야한다. 내가 생각하기에는 엄청 나게 큰 feature단위 중 하나라고 생각이된다. 원래는 나 혼자하는 개발이 아니었다. FE(Front Enginner)와 BE(Back Enginner)를 모두 하실 수 있는 풀스택 팀원분이랑 함께 개발할 예정이었는데 갑자기 팀원분이 나에게 티타임을 요청하셨다.

스타트업에서 첫직장을 시작하다보면 내가 원하는 목표에 도달하기가 쉽지 않다고 하셨다. 대화를 나눠보니까 개발 직군에 관련된 이야기였다. WEB FE개발자를 목표로 취업했지만 스타트업에서는 자신이 하고싶지 않은 BE일이나 모바일 개발 등도 하게 될 수 있다. 라는 내용인데 내가 스타트업에 취업한 이상 이런 고민에 부딪힐 거라고 생각하고 있었기 때문에 별다른 고민없이 나는 말할 수 있었다.

저는 흐름에 맞춰가고싶어요.

나는 개발자로 살아가면서 여러가지를 공부해보고 경험하는 일은 필수적이라고 생각한다. 그렇기에 흐름에 맞춰가고 싶다. 라고 말씀을 드렸더니 팀원분께선 나에게 제안을 하셨다.

팀원: 그러면 준우님이 Client개발을 전부하시는건 어떨까요? 나: 오.. 그러면 뭔가 저희 feature에서 제가 FE 리더 같은 느낌이네요? 팀원: 음.. 네 그렇죠.

위와 비슷한 내용의 대화 맥락이 있었고 나는 뭔가 인정받았다는 느낌에 기분이 너무나도 좋았다.

그래서 지금 feature의 client를 인수인계 받아서 협업하며 개발에 착수하고 있다.

기술적인 측면에서 봤을 땐..

학교에서 사이드프로젝트를 진행하거나 친구들과 큰 프로젝트를 진행할 때 개발하면서 최대한 코드를 깔끔하게 짜보려고 노력했었다.

나는 개발을 할 때 우선순위 1번으로 코드 퀄리티를 두고 2번으로 기능이 동작하게 하자. 로 두었다.

하지만 지금 회사에서는

1. 코드 퀄리티
2. 기능의 효율성

으로 우선순위를 맞추고 있다. 나는 지금까지 기능의 효율성에 관해서 많은 고민을 하지 않았었다.

내가 회사에 와서 기술적으로 많이 배우고 성장한 건 React Component Debugging과 rendering을 고려해서 성능상의 이슈를 해결하는 방법등 인 것 같다.

왜 나만 1레벨 이지? 🤔

우리 회사는 엄청 특이하다. 신입(주니어)개발자는 나 한명 뿐이고 나머지 전부 엄청난 이력을 갖고 있는 만렙 개발자 뿐이다. 우리나라에 typescript를 전파했다고 불러도 손색이 없는 슈퍼 개발자분과 네이버가 젖먹던 시절부터 지금 한국을 대표하는 검색엔진이 되기까지 많은 기여를 하신 분도 계시다. 현재 잘나가는 스타트업의 공동 창업자 분들도 계시고 친구가 다니고 있는 회사의 초기 맴버였던 분들도 계시다.

여기서 충격적인건 나를 제외하곤 서로가 대부분 같이 일을 해봤던 사이인 것 이다. 🥺

솔직히 좋으면서, 왜 그래~ 😘

맞다. 나는 사실 지금 내 직장생활이 너무나도 행복하다.

앞으로 살면서 이런 경험을 할 수 있을까 싶기도 하고 계속 이렇게 가다간 나도 슈퍼 개발자가 되는거 아니야?! 하는 망상속에서 살고있기 때문에 지금은 너무나도 행복하다. 첫 직장이라서 모르는 것도 많았고 어떻게 해야할지 감이 잘 안왔지만 지금은 잘 적응해서 일 할 시간이 부족하다.

아 그리고, 팀원분들이 내가 고등학생이라고 자꾸 놀린다.

이렇게 계속 나한테 말 걸어주고 자꾸 다가와주어서 나는 너무 기쁘고 안도한다. 신년이되면 나도 이제 성인이니까 어른의 세계를 알려주신다고 하셨다. (술.. 좋지..)

첫 Flex

결론은, 내 첫 회사는 Flex이고 1의 후회도 없고 행복한 회사 생활을 하고 있다. 첫 월급을 받고 적지도 많지도 않은 딱 적당한 금액(학생 신분으로 현장실습 중이라서 기존의 받는 금액의 70%정도를 받는다.)으로 남들보다 빠른 스타트와 좋은 환경에서 일하고 공부할 수 있음에 감사하다.

아 그리고 오늘 2020년도 병역특례업체에 선정되었다. 🥳 기념으로 슬랙으로 팀원분들이 농담을 해주셨는데 벌써 너무 슬프다. (사실 좋다.😏)

클릭아키텍처 정리

오타 및 잘못된 정보는 junukim.dev@gmail.com 으로 연락부탁드립니다. 🤞

React에서 SVG 사용하기 🤹‍♂️

React에서는 SVG를 다른 assets처럼 사용할 수도 있지만 component로 분할하여 사용할 수 있습니다.

svg파일을 열면 svg태그와 g, path등의 태그들을 확인할 수 있습니다. 그리고 이들로 svg를 구성하고 만듭니다.

그리고 이를 React에서 SVG로 컴포넌트화 시키는데 방법이 조금 까다롭습니다.

SVG파일이 작거나 비교적 만들기 쉬운 모양이라면 태그 조금의 변경으로 컴포넌트화가 가능합니다. 그러나 지도 SVG처럼 모양이 다체롭고 복잡한 경우에는 해당 방법이 거의 불가능합니다.

그래서 저는 어떻게 Component로 바꿀 수 있을까 구글링하다가 SVG To JSX라는 키워드를 통해 좋은 사이트를 찾을 수 있었습니다.

svg2jsx.com

위 사이트는 SVG파일을 insert하면 JSX에서 사용가능한 SVG컴포넌트를 만들어줍니다.

이를 통해 SVG를 컴포넌트로 변경켰습니다. 그리고 SVG를 굳이 컴포넌트로 변형시킨 이유가 있습니다. SVG파일을 컴포넌트로 변경시켜 react의 hooks와 지도 path의 onClick event를 사용하기 위해서입니다.

지도의 곳곳을 클릭하여 이미지를 추가해야하는 프로젝트여서 어떻게 개발할까 생각하다가 이런 방법을 택하게 되었습니다.

지역별 클릭 🥄

인터넷을 통해 지도 SVG파일을 얻고 이를 바탕으로 지도앱을 개발하던도중 하나의 문제에 부딪히게됩니다.

사용자가 지명을 모르면 말짱도루묵아닌가?

그렇습니다. 제가 같고있는 SVG는 오직 지도 하나뿐이었습니다.

열심히 구상하고 계획한 프로젝트가 엉망이되려고하자 저는 직접 SVG를 만들어보기로 하였습니다.

XD를 열어 지도 SVG를 붙이고, 구역에 맡게 이름을 써내려갔습니다. 너무 자잘자잘하거나 작은것들은 하나의 지역으로 모아서 붙이고, 너무 크거나 애매한 지역은 동부, 서부등으로 나누어서 지역을 나누었습니다.

그리고 이렇게 하여 두개의 SVG파일을 얻을 수 있었습니다.

pointer-events: none; 👍

<svg ... /> // 지역
<svg ... /> // 지도

위와 같이 svg를 배치하고 css position을 absolute로 설정하여 위에 올린 후 지도 SVG에 onClick이벤트를 path마다 적용시켰더니 지역SVG에 지도SVG가 가려져서 클릭 이벤트에 접근을 하지 못하였습니다.

정말 하루종일 구글링하고 여러 키워드로 검색하였으나 방법을 찾을 수 없어서 카카오톡 오픈채팅방과 페이스북을 통해 질문도 하였습니다.

하지만 키워드 선택에 실패했는지 방법은 찾기 힘들었고 계속해서 고민만 늘어났습니다.

그러다가 딱 머리를 스치고 지나가는 생각이 있었습니다.

분명히 CSS에서 클릭을 비활성화 시킬 수 있을거야.

그래서 CSS에 초첨을 두고 구글링를 하였는데.. 방법을 찾았습니다. 그리고 해당 방법은 pointer-events: none;이라는 속성입니다.

MDN에서 pointer-events속성을 다음과 같이 정의하고 있습니다.

MDN링크: 그래픽 요소가 어떤 상황에서 포인터 이벤트의 대상이 될 수 있는지 지정합니다.

pointer-events를 none으로 설정해주면 이벤트의 대상으로 설정되지 않습니다.

MDN에서 pointer-events: none을 다음과 같이 정의하고 있습니다.

MDN링크: 요소가 포인터 이벤트의 대상이 되지 않습니다. 그러나 해당 요소의 자손이 다른 pointer-events 값을 지정한 경우, 그 자손은 대상이 될 수 있습니다. 이 때는 이벤트 캡처/버블 단계에서 none을 지정한 요소의 이벤트 처리기를 발동할 수 있습니다.

이런 CSS도 있구나.. 하며 감탄했습니다.

Typescript로 지도 조작 만들기

• 지도 드래그
• 지도 확대 축소 위 내역은 현재 지도를 조작할 수 있는 방법들 입니다.

라이브러리를 사용하지 않고 순수 Javascript(TS)로 개발하면서 생겼던 이슈들을 공유하려고 합니다.

다음 포스팅에서 자세하게 설명해드리겠습니다.

개발 전 준비 사항 🤔

오랫만에 혼자하는 프로젝트이고 열심히 해보고 싶어서 차근차근 시작하기로 하였습니다. 그래서 개발 전에 미리 준비해야할 사항이 있을까? 싶어서 리스트를 나열해보았습니다.

• ❌ 지도 모양의 svg 파일
• ❌ 간편 로그인을 위한 oAuth 연결
• ❌ 배포를 위한 aws ci/cd 작업
• ❌ 정적 이미지 관리를 위한 s3 연결

나열해본 리스트는 다음과 같았고, 하나하나 꼼꼼히 준비하였습니다.

지도 모양의 svg 파일 😬

구글에 지도 모양의 svg파일을 검색하면 여러가지 블로그와 파일들이 나옵니다. 이 중 저작권 관리가 쉽고 다루기쉬울 만한 파일이 뭐가 있을까 찾다가 위키백과에서 한국 지도를 찾아볼 수 있었습니다. 2014년이 마지막 업데이트지만 그래도 쓸만할 것 같아서 해당 svg로 골랐습니다.

• ✅ 지도 모양의 svg 파일
• ❌ 간편 로그인을 위한 oAuth 연결
• ❌ 배포를 위한 aws ci/cd 작업
• ❌ 정적 이미지 관리를 위한 s3 연결

간편 로그인을 위한 oAuth 연결

사용자에게 보다 편한 UX를 제공하기위해 별도의 로그인을 구현하지 않고 oauth연동을 통해 한번의 클릭만으로 로그은을 진행할 수 있도록 하였습니다.

특별히 oAuth중 Facebook을 사용하였습니다.

이와 같이 페이스북 개발자 센터에서 앱을 등록하고 Facebook로그인 제품 검수를 받았습니다. 요즘은 COVID 19 때문에 앱 검수가 힘들다고 하던데.. 작년 12월에 미리미리 해놔서 다행인 것 같습니다.

• ✅ 지도 모양의 svg 파일
• ✅ 간편 로그인을 위한 oAuth 연결
• ❌ 배포를 위한 aws ci/cd 작업
• ❌ 정적 이미지 관리를 위한 s3 연결

배포를 위한 aws ci/cd 작업

자세한 내용은 CloudFront로-React앱-배포하기 편을 참고하여 주세요.

개발에 앞서서 미리 클라이언트의 배포환경을 구축하고 Github Actions를 이용한 파이프라인까지 만들어두었습니다.

해당 build.yml파일과 모든 개발 파일은 여기에서 확인하실 수 있습니다.

• ✅ 지도 모양의 svg 파일
• ✅ 간편 로그인을 위한 oAuth 연결
• ✅ 배포를 위한 aws ci/cd 작업
• ❌ 정적 이미지 관리를 위한 s3 연결

정적 이미지 관리를 위한 s3 연결

저는 평소 개발할 때 assets들을 배포 파일에 함께 넣어서 배포했는데 저번에 황당한 경험을 한 이후로 AWS S3에 정적 파일을 따로 저장하고 URL로 불러옵니다.

이미지 파일이랑 동영상파일들을 함께 빌드해서 배포했더니 ReactAPP용량이 8MB가 넘었었다. ㅋㅋ.. 지금 생각해보면.. 와우 사용자를 고려하지 않고 돌아가니까 상관없지~ 했던 내가 생각난다.. 😑 해당 React앱 빌드는 다시 했었따.

이렇게 import해서 사용하였습니다.

• ✅ 지도 모양의 svg 파일
• ✅ 간편 로그인을 위한 oAuth 연결
• ✅ 배포를 위한 aws ci/cd 작업
• ✅ 정적 이미지 관리를 위한 s3 연결

이슈 및 해결 방법 🤷‍♂️

지도 SVG를 이용하면서 정말 많은 이슈와 문제들이 있었습니다.

SVG만 이렇게 직접적으로 다뤄본 적도 처음이었고 React에서 SVG를 사용하는게 좀 힘들었습니다.

또 지도 드래그와 줌 인/아웃, 지역 별 클릭등 기능을 구현하는데 다양한 버그가 있었습니다.

다음 포스팅에서 이러한 이슈들과 이슈별 해결방안을 설명드리겠습니다.

makeToon 😉 - 웹 포토로그 제작

사람들은 여행을 하고 사진으로 당시의 기억과 추억을 남깁니다. 하지만 사진으로 추억을 남긴다고 해도 당시의 상황이나 위치 등을 정확히 기억하지 못합니다. 이를 해결할 수 있는 방법은 없을까?

사진으로 이루어진 지도를 만든다면 어떨까? 더욱 눈에 띄고 사진을 하나하나 채워 가면서 이것 또한 추억이 되지 않을까? 그리고 더욱 기억을 정확하고 오래 갖고 있지 않을까? 이러한 생각에서 개발된 사진으로 지도를 구성할 수 있는 어플. makeToon 입니다.

서론

MakeToon은 고등학교 2학년 겨울방학이 시작되고 겨울방학을 알차게 보내보자는 생각에서 여러 아이디어를 모아보다가 꽤 괜찮은 아이디어 같아서 개발하게 되었습니다. 2019년 12월 부터 2020년 7월말 까지 개발하였으며 현재는 서비스되고 있는 중 입니다.

개발하면서 겪은 이슈 및 해결방안을 공유하기 위해 글을 작성합니다. 🎧

기타

makeToon은 이곳에서 이용하실 수 있습니다. 주소는 https://maketoon.junukim.dev입니다.

다음은 추후에 추가될 기능입니다.

• 지도 프린트 기능
• 모든 사진 모아보기 기능
• 지도 공유 기능

내가 CloudFront로 정적 웹 사이팅을 배포하는 이유는 별거 없다. https가 무료이고, 배포가 간단하기 때문이다. 나한테는 https가 무료인게 많이 끌렸었다.

시작하기

먼저 S3때와 마찬가지로 CloudFront를 검색해준다.

그리고 Create Distribution버튼을 클릭한다.

내 프로젝트는 당연히 웹이니까 Web란의 Get Started 버튼을 누른다.

이제 뭔가를 막 입력해야하는데 여기서 잘못입력하면 꼬일 수 있으니까 주의하면서 진행한다.

먼저 Origin Domain Name을 클릭하면 자신의 S3와 자동으로 연결되고, S3에서 만들어 둔 버킷과 연결할 수 있다.

이후 아래 Default Cache Behavior Settings에서 Viewer Protocol Policy를 Redirect HTTP to HTTPS로 바꿔준다. 그리고 맨 아래의 Create Distribution버튼을 눌러준다.

그러면 저렇게 Status가 in Progress인 클라우드 프론트 Distribution이 생긴 것을 확인할 수 있다. in Progress 상태가 해제되면 CloudFront 생성이 완료된다.

CloudFront가 다 생성되고 나면 Domain Name을 통해서 배포한 React앱에 들어갈 수 있다. HTTPS가 적용된 상태일 것 이다.

에러 핸들링

React와 같은 SPA를 통해 S3 - CloudFront 배포를 하게되면 Redirect문제가 발생한다.

예를 들어 https://maketoon.junukim.dev 라는 도메인으로 React앱을 배포했다.

해당 URL에 그냥 접속하면 앱은 매우 잘 작동한다. 하지만 https://maketoon.junukim.dev/photomap 으로 접속하면 Access Denied 문제가 발생한다.

이는 React에서 사용하는 react-router-dom때문인데, CloudFront에서 redirect를 403으로 막은 것 이다. 그래서 이를 해결하려면 CloudFront에서 에러 핸들링을 해줘야한다.

Access Denied 방지

CloudFront Distributions에서 자신의 CloudFront ID를 클릭하여 상세정보를 열람한다. 그 후 Error Pages 탭으로 이동하고 Creaet Custom Error Response버튼을 클릭한다.

해당 이미지와 같이 HTTP Error Code를 403으로 설정하고 TTL을 5초로 설정한다. 그리고 Response Page Path와 Response Code를 설정해준다.

403 뿐 아니라 404도 똑같이 만들어주면, 이렇게 된다.

캐시 문제 해결

그리고 마지막으로 CloudFront는 배포에 오랜시간이 걸린다. 사실 배포에는 오래걸리지 않지만 브라우저 캐시 때문에 적용하고 하루 넘게 지나야 적용되는 것 이다. 이를 해결하는 방법은 간단하다.

Invalidations탭으로 이동해서 Create Invalidation버튼을 클릭한다.

그리고 Object Paths에 * or /* 이라고 입력한다.

그리고 한 3분 정도 지나면 캐시 문제는 해결된다.

앱 소개

"MakeToon" 이라는 이름을 갖고있는 포토로그 프로젝트이다. React로 여러 프로젝트를 진행하였지만 해당 프로젝트만큼 SVG를 열심히 사용한 건 처음인 것 같다. 해당 프로젝트를 AWS에 올린 경험을 포스팅 하겠다.

프로젝트 소개는 노션으로 대체하도록 하겠다.

! 프로젝트 관련 포스팅 -> 바로가기

React 앱 빌드

앱을 배포하기 위해선 develop모드가 아닌 product모드로 앱을 빌드해서 html파일을 뽑아야한다.

> npm run build

해당 명령어를 통해 빌드된 앱을 만들 수 있다.

나 같은 경우는 custom webpack을 사용하기 때문에 index.html과 main.css, bundle.js 그리고 favicon과 public파일들로 이루어지지만 create-react-app을 이용해서 앱을 개발한 경우는 여러 파일들이 같이 나오게 된다.

CRA를 사용해서 앱을 빌드하거나, custom webpack을 이용한 경우 모두 상관없이 AWS에서 배포할 수 있으니 별 걱정하지 않아도 된다.

AWS

포스팅의 목표가 CloudFront로 React앱 배포하기인 만큼 AWS를 사용해야만 한다.

aws계정이 따로 없는 경우 AWS에 회원가입을 해준다.

참고로, AWS에 처음 접속하면 따로 회원가입 버튼이 없고 콘솔에 로그인이라는 버튼이 있다. 버튼을 클릭하면 AWS 계정 새로 만들기를 통해 회원가입이 가능하다.

S3

AWS에 회원가입을 완료했으면 본격적인 배포를 할 수 있다.

내가 배포한 방법은 다음과 같다.

1. 정적 데이터를 AWS의 S3에 저장.
2. S3를 통해 정적 웹 호스팅을 구축하고 이를 CloudFront를 통해 배포.
3. route53을 이용해 CludeFront를 내 도메인에 장착.

먼저 s3에 배포하기위해 서비스 검색을 한다. 해당 검색란에 S3를 검색한다. (S3 - 클라우드의 확장 가능한 스토리지)

S3를 성공적으로 검색하고 redirect되면 해당 화면으로 넘어온다. 여기서 버킷 만들기 버튼을 클릭한다.

버킷 이름을 정하고 위치를 조정한다. 아마 대부분 아시아 태평양(서울) ap-northeast-2 이라고 생각한다. 이후 버킷을 만들어준다.

이렇게 버킷이 만들어진 것을 확인할 수 있다.

이제 해당 버킷을 공개적으로 사용할 수 있도록 수정해줘야한다. 현재 버킷은 엑세스가 퍼블릭 아님으로 되어있다. 이렇게 되면 권한이 없는 사람들은 나의 앱에 접근할 수 없다. (access denied) 그러므로 수정해보도록 하겠다.

이름란에 있는 파란 버킷 이름을 누르면 된다. (해당 포스트에선 junukim-dev-posting)

클릭해서 버킷에 접속하면 해당 화면을 마주한다. 이때 바로 보이는 화면에서 나의 앱을 버킷에 담을 수 있다. 자신의 빌드 파일을 이 버킷은 비어 있습니다. 시작하려면 새 객체를 업로드합니다. 라고 적혀있는 하늘색 네모로 드래그하거나 업로드하면 된다.

성공적으로 빌드 파일을 업로드하면 이렇게, 파일이 생긴 것을 볼 수 있다.

이제 파일을 다 올렸으니 권한을 설정하도록 하겠다. 권한 탭으로 이동한다. 권한 탭에 들어오면 퍼블릭 엑세스를 허용해줄 수 있다. 편집 버튼을 누르고 허용해준다.

편집을 누르면 모든 퍼블릭 엑세스 차단의 체크를 해제할 수 있는데, 이를 해제하고 저장한다. 이후 확인을 입력한다.

이제 위에 액세스 제어 목록을 클릭하고 퍼블릭 엑세스 권한을 부여해준다. 퍼블릭 엑세스란에 있는 Everyone을 클릭하고 버킷 읽기 권한을 허용한 후 저장해준다.

이후 위에 버킷 정책 버튼을 클릭하여 버킷 정책을 적어준다. 버킷 정책은 아래에 있는 정책 생성기 버튼을 통해서 만들어도 상관없지만 문구는 같기 때문에 그냥 복사하는 것을 추천한다.

해당 정책을 입력하고 자신의 버킷이름에 맞도록 수정한다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AddPerm",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::버킷이름/*"
        }
    ]
}

이후 저장 버튼을 누르고 상단의 속성 탭으로 넘어간다. 속성 탭에서 정적 파일을 웹 사이트 호스팅할 수 있도록 변경한다. 정적 웹 사이트 호스팅을 클릭하고 인덱스 문서와 오류 문서에 index.html을 입력하고 저장한다.

이러한 과정을 거치면 앤드포인트 라고 적혀있는 링크를 통해 자신이 버킷에 올린 빌드 파일을 정적 웹사이트 호스팅으로 접근할 수 있게 된다.

이렇게 정적 웹사이트 호스팅을 통해 React앱 빌드 파일을 정적 호스팅 해보았다. 하지만 현재 배포는 불완전함으로 이를 보안적으로 강화하고, 도메인을 달아줘야한다. 다음 포스팅에서 CludeFront와 연결해보도록 하겠다.

테스트? 한번 해보지 뭐

테스트 코드라.. 오래전 부터 들어왔고 많은 시도를 해왔었다. 이론적으로 테스트를 공부하고 수 많은 프로젝트에 도입을 해보려 했으나 번번이 실패하였던 기억이 있다. 그리고 사실 오늘 작성한 테스트 코드가 좋은 코드인지도 잘 모르겠다. 모든 것은 처음이 있었기에 끝이 있기 마련이다. 오늘의 도전을 하나의 시발점으로 두고 더욱 공부해야 겠다.

세팅

나는 TS를 사용하고 webpack을 직접 세팅하여 React 개발을 하고있다. 그렇기에 CRA를 사용하였을 때 기본적으로 install 되어있는 라이브러리들을 직접 다운받아야했다.

테스트 관련해서 1~2년 전 글은 많았지만 최근 글은 없어서 하는 수 없이 여러 블로그와 사이트에서 정보를 모았다. 그렇게 나는 이와 같은 라이브러리를 install 할 수 있었다.

enzyme

npm i -D enzyme enzyme-adapter-react-16 enzyme-to-json @types/enzyme

jest

npm i -D jest ts-jest babel-jest @types/jest

react-test-renderer

npm i -D react-test-renderer @types/react-test-renderer

각 라이브러리에 대한 설명은 velopert님의 리액트 테스트 글에 자세히 설명되어있다.

jest.config.js

간단하게 라이브러리를 다운 받고 test setting을 해야한다. 그래서 jest.config.js를 설정하는데 여러 블로그에서 jest의 파일확장자를 js로 설정하였었다. webpack.config.ts나 postcss.config.ts같은 경우는 확장자를 ts로 하여도 오류없이 잘 돌아가서 당연히 jest.config.ts로 두고 세팅을 하였는데 계속 알 수 없는 오류가 발생하였다.

설마 하고 확장자를 js로 바꿔보았는데.. 만들어 둔 세팅이 잘 작동되서 당황했었다. 그러니 확장자를 js로 하자.

jest.config.js파일을 생성하고 다음과 같은 코드를 입력해 준다.

jest.config.js

module.exports = {
  globals: {
    "ts-jest": {
      tsConfig: "tsconfig.json",
      diagnostics: true
    }
  },
  moduleFileExtensions: ["ts", "js", "tsx", "jsx"],
  moduleNameMapper: {    // 절대 경로
    "^src/(.*)": "<rootDir>/src/$1",
        ...
  },
  transformIgnorePatterns: ["./node_modules/"],
  preset: "ts-jest",
  transform: {
    "^.+\\.(ts|tsx)$": "ts-jest"
  },
  testMatch: ["**/test/**/*.test.(ts|tsx)"],
  testEnvironment: "node",
  snapshotSerializers: ["enzyme-to-json/serializer"],
  setupFilesAfterEnv: ["./src/test/setUpTest.ts"]
};

나는 개발하면서 절대경로를 사용하는데 jest에서 절대 경로를 사용해보려고 하니 조금 애 먹었다. 분명 시키는 대로 하고, 나와있는데로 설정했는데 왜 안될까.. 싶었는데!

현재 위의 코드에서 moduleNameMapper부분이 절대경로를 설정하는 부분이다. 보면 알겠지만 나는 src 디렉토리를 절대경로로 표기했다.

"^src/(.*)": "<rootDir>/src/$1"

이와 같이 적혀있는데 "^src/(.*)"에서 ^를 절대경로로 사용하는 문자열 구문인 줄 알고 빼고 적었다가 절대 로 설정이 잘 안됬다..

그리고 "<rootDir>/src/$1"에서 <rootDir>를 나의 디렉토리의 root를 적으라는 줄 알고 .을 찍었다가 절대경로 설정이 잘 안되었다.

이 부분 꼭 참고해서 설정할 수 있도록 하자.

혹시 했갈릴 수 있으니 tsconfig.json과 jest.config.js의 절대경로 부분을 사진으로 올려놓았다.

이제 마지막으로 package.json의 script탭에다가 실행 명령어를 입력해 준다.

package.json

{
  ...
  "scripts": {
      ...
    "test": "jest"
   }
 }

이렇게 Typescript와 Jest, enzyme를 이용한 Test setting을 마칠 수 있다.

그리고 src/test/**/*.test.(ts|tsx)에 test 파일을 작성할 수 있다.

느낀점과 팁

나는 하나를 하더라도 내가 할 수 있는 역량 안에서 최대한 완벽하게 만들고 싶어하는 완벽주의자 이다. 그래서 테스트환경을 설정할 때도 최대한으로 설정해보았지만 아무래도 아직 엉성한 부분이 있는 것 같다. 나중에 꼭 시간나면 보완할 것 이다.

팁

• jest.config.ts (x) -> jest.config.js (o)
• 을 통째로 넣을 것.

배경

React를 이용해서 웹을 개발한지 어느덧 2년이 넘어간다. 책을 읽는 것 보단 공식 문서를 통해 공부하는 것을 더 좋아해서 공식문서를 많이 참고하여 공부하였는데 역시 너무 어려웠다. 영어 독해 능력이 떨어질 뿐더러 처음 접하는 프레임워크(프레임워크 처럼 사용할 수 있는 라이브러리)가 너무 어려웠다.

그냥 하라는 대로 하고, 기본적으로 제공해주는 틀을 이용해서 개발하였는데 계속 개발하다보니 이런 생각이 떠올랐다.

"내가 회사에 가서도 CRA를 통해 개발할까? " 🤔

정답은 아니었다. 약 1년전에 우연한 기회로 레이니스트에 견학을 가게됬는데 이때 궁금해서 웹 팀장님께 물어봤었다. 정말 직설적으로 물어봤었는데, 지금 생각해보면 정말 당연한 대답이다.😂 (이불킥 엄청 했다)

그래서 이 이후로 webpack을 공부하기 시작했고 React 프로젝트 기초 설정부터 폴더구조까지 직접 만들어보게되었다. (나는 내 프로젝트 구조가 한참 부족하고 보완 해야할 점이 많다고 생각하기 때문에 계속해서 보완하려고 노력하고 있다.)

디자인 패턴과 아키텍처

나는 React에서 상태관리를 위해 Redux를 사용한다. 주위에서 ContextApi나 MobX를 추천해주기도 하였지만 내가 생각하는 이상적인 코드의 깔끔함이 Redux와 가장 잘 맞는 것 같아서 Redux를 사용하고 있다. 때문에 Flux패턴을 사용하게 되는데 나는 여기에 아키텍처를 입혀보았다.

아키텍처 중 Clean Architecture를 공부하고 아키텍처에 대한 지식을 차근차근 쌓아가다가 계속 공부만 하고 적용을 안 해보다 보니 내가 정확하게 이해하고 있는지도 궁금했고, 공부만 해선 계속 지체될 것 같아서 과감하게 도전해보았다.

실패

막연하게 도전했지만 React프로젝트에 Clean Architecture를 적용하는 것은 내 생각만큼 쉽지 않았다. 가장 큰 문제는 Redux가 있는데 어떻게 프로젝트 구조를 설계 해야하는지가 어려웠다.

그래서 나는 외부의 도움을 얻기로 하였다. 나는 Github에 떠돌고 있는 여러 예제들을 참고해보았다. 그 중 모티브를 삼아 설계했던 구조가 해당 링크이다.

위 사진은 모티브로 했던 폴더 구조인데 보이는 것 처럼 module들도 따로 분리하여 새로운 package를 형성하는 것을 볼 수 있다. 처음에는 이와 같은 방법으로 진행을 해보려고 많은 삽질을 해보았는데 개인적으로 선호하는 스타일이 아니어서 다른 방향으로 고개를 돌렸다.

이후에도 많은 시도를 하였다. android의 Clean Architecture처럼 구조를 잡아보기도 하였고 redux를 제외시키고 구조를 설계해보기도 하였다. 또 TS말고 Javascript를 이용해서도 해보았는데.. 역시 힘들었다. 많은 시도와 삽질을 해본 끝에 결단을 내린 폴더구조는 애매모호 했다.

프로젝트 설계

Clean Architecture를 완전 사용하지 않고 어느정도만 copy한다는 느낌으로 설계하였다. 그리고 Redux의 데이터 흐름을 어떻게 하면 유연하게 흘러가게할 수 있을까, 의존성을 어떻게 하면 더 줄일 수 있을까 열심히 생각하면서 설계하였다.

┌── .vscode                    - vscode setting
├── node_modules
├── public/                    - favicon, html
├── src/
│   ├── @types/                          - typescript date type 정의
│   │    └── index.d.ts
│   │
│   ├── assets/                          - assets 폴더
│   ├── components/                     - 컴포넌트 폴더 (views)
│   │   └── componentName/                          - index.ts를 정의
│   │         └── style/                            - 컴포넌트 별 style
│   ├── container/                      - 컨테이너 폴더 (presenters)
│   │   └── containerName/                          - custom hook을 통한 상태관리
│   │         └── presenter/                        - 해당 container에서 사용되는 presenter
│   ├── data/                              - redux 폴더 (use Cases & entities)
│   │   ├── actions/                               - 액션 정의
│   │   ├── middleware/                                   - 미들웨어 정의
│   │   │    ├── api/
│   │   │    │    ├── apiTypes.ts
│   │   │    │    ├── baseUrl.ts
│   │   │    │    └── index.ts
│   │   │    │
│   │   │    └── sagas/                         - 사가 정의
│   │   │
│   │   └── reducers/                          - 리듀서 정의
│   │ 
│   ├── page/                             - 라우터 정의 폴더
│   │   └── App.tsx
│   │ 
│   ├── styles/                           - 글로벌 스타일 폴더
│   │   └── globalStyle.ts
│   │ 
│   └── utils/                            - 유틸 폴더
│       └── util.ts
│
├── package.json
├── .babelrc
├── .env
├── postcss.config.ts
├── tsconfig.json
├── tslint.json
└── webpack.config.ts

기술 스택

프로젝트를 설계하면서 사용하는 기술에 따라 구조를 조금씩 변경하였다. 물론 라이브러리에 의존적이 않도록 나만의 규칙을 세우고 개발한다. 😏

기본적으로 React + Redux + @middleware를 사용하고, middleware는 redux-saga를 사용한다. 스타일링에선 styled-components를 사용하고, HTTP 통신에서 axios를 사용한다.

또 post-css와 webpack + babel로 기본적인 앱 세팅을 하고있고, Typescript를 사용하여 개발한다.

결론 및 고찰

위 프로젝트 구조가 내가 직접 설계하고 고안한 구조이다. 지금 이렇게 글을 적으면서 다시 돌아보니 많이 허접하고 부족한 점이 눈에 보이는 것 같다. 직접 프로젝트 구조를 설계하면서 데이터의 흐름이나 방향에 대해 많이 고민하게 되고 의존성 주입에 대해 많이 생각하게 되는 것 같다.

해당 프로젝트 구조를 만들기 까지 여러 프로젝트를 경험하였다.

처음에는 구글링을 하다가 언뜻 본 폴더구조에서 style폴더를 src/위치에 설계한 것 보고 따라해보았는데 styled-components를 사용해서 스타일링을 하다보니 styled-component의 네이밍이 겹치는 부분이 많아서 재활용 하기 힘든 이름을 정하게 되었다. 그러다가 velopert님이 발표하신 자료를 우연하게 접하게 되었는데 나와 같은 고민을 하셨어서 좋은 해답을 찾을 수 있었다.

그리고 프로젝트 구조를 새우기전에는 container를 component의 구분을 짓는 용도로 사용하고 component의 모든 데이터를 관리하도록 하였는데 redux example를 참고하여 view는 모두 compoennt로 이동시키고 container를 presenter처럼 사용하게 되었다.

webpack에 대한 이해도도 많이 부족하고, 아키텍처나 디자인 패턴에 대한 이해도가 많이 부족한 상황에서 나만의 React 프로젝트를 설계하는 과정은 쉽지 만은 않았다. 하지만 어려운 과정을 거치고 나니 많은 배움을 얻을 수 있었다. 직접 프로젝트를 설계한다는 경험을 통해 좀 더 깊은 생각을 할 수 있는 기회였다.

처음 작성하는 블로그 글이라서 필력이 많이 부족합니다. 많은 조언 부탁드립니다.😎