Web-Server/React

React, 기반 뿌리부터 살펴보자 - (부제 : 다양한 방법론의 조합)

코딩크리처 2025. 6. 10. 04:15

제목 : React, 기반 뿌리부터 살펴보자 - (부제 : 다양한 방법론의 조합)

이 글을 작성하는 이유

드디어, JavaScript 의 Syntax Sugar 의 형태,

JS 의 private 의 또 다른 의미, (실질적으로는 보안을 위해 # 으로 21 년 도입됨)

Webpack 의 동작 원리, package.json, package-lock.json, tsconfig.json

이 파일의 존재 이유에 대해서 파헤쳤다.

또한, HTML5 정식 스펙상에 존재하는 "모든 카테고리의 태그" 를 다루었다. (실제 예제 및 렌더링 예시까지)


특히, JS 로 제작된 대부분의 최신 프레임워크는 아직 정식 스펙에 도입되지 않은 문법을 채택하여

이를 tsconfig.json 의 옵션에서 적용하고 있다는 것이 놀라웠다.

async 와 Promise 의 역할, 싱글 스레드라는 Node.js 의 기본 한계점을 없애기 위해

Worker 라이브러리를 공부했으며, 이를 통해 JS 의 한계점 또한 알게 되었다.

위의 내용을 보자면, "JS 는 단점이 많지 않나?" 라고 생각이 들 수도 있지만,

초-중반의 JS 문법 자체의 간단함과 그 커뮤니티의 거대함(EX - NPM) 은 일반인들도 쉽게 개발할 수 있게 만들었다.

특히나, JS 자체가 2015 년 이후로 최적화되어 이전보다 속도가 훨등히 빨라졌기 때문에,

유저 인터랙션과 수많은 컴포넌트들을 관리하는 과정에서 생각해야 할 최적화는 약간 후순위로 밀려났다.

특히, 브라우저의 동적 시스템은 JS 를 기반으로 동작한다.

물론, 모든 기능과 컴포넌트를 .wasm 으로 만들어서(C++, Rust, Java, Go 로 만든 모듈)

속도 면에서 월등하게 최적화가 가능하겠지만, 생태계가 주는 라이브러리와 컨벤션은 이길 수 없다.

나는 Development Engineer 가 되기 위해 2 가지 트랙을 동시에 진행 할 것이다.

  1. C++ 도 아닌 C 에서, 최소한의 라이브러리를 사용하여 파생 언어의 특징을 쉽게 받아들일 수 있도록 만든다.
  2. 현재(25년 6월 기준) 가장 활발하게 사용되고 있는 React 라이브러리를 사용하여
    현재 웹 사이트 제작의 트렌드(컨벤션) 을 배우며, 내가 웹 모듈로 최적화 할 수 있는 부분을 찾는다.

C 언어를 사용하는 것도 정말 Legacy 시스템을 사용하는 것이지만,

나는 개인적으로 "최소한의 필요 라이브러리" 만을 사용한다는 제약을 걸었다.


또한, React 를 통해 JS 를 통한 문서 개발에 착수한다.

이는 상반된 공부라는 것을 잘 알고 있지만, 두 가지의 공부 과정에서 얻는 지식과 연결고리는 중요하다고 생각한다.


그래서 React 란 무엇인가?

현대 모던 웹 사이트 프로그래밍은 10년 전과 비교할 수 없을 정도로 복잡해졌다.

하드웨어의 발전과, 소프트웨어의 최적화 및 접근성이 발달됨에 따라 개발의 문턱은 낮아졌다.

이전에 웹 문서를 작성하기 위해 html 파일로 작업하고, 필요 한 경우 JavaScript 모듈을

부착하여 기능을 추가하는 방식으로 진화했다.


하지만, 점점 고도화 되어 웹 사이트에 수많은 유틸성 기능과 애니메이션이 추가되기 시작됐다.

이는 단순히 JavaScript 의 모듈 복잡성을 일으킬 뿐만 아니라, 각 코드의 의존성 계층을

전부 파악하여 순서대로 놓아야 하는 지경에까지 이르른 것이다.

물론, 이 때 당시 JQuery 를 통한 DOM 조작 라이브러리가 존재했지만,

따로 "컴포넌트" 개념을 만들어 가상의 DOM 을 사용하면서, 최적화를 이룬 것이 React 이다.


웹 페이지는 더 이상 정보를 전송해 주기만 하는 어플리케이션이 아니었다.

이제는, 사용자의 생활 편의성을 위한 프로그램, 보안, 상호작용, 게임 등등 수많은 역할을 하고 있다.

이러한 프로그램을 작성하기 위해서는 "정적" 속성에 가까운 HTML 파일만으로는 한계가 존재했다.

따라서, 현대 웹 개발 시스템에 걸맞은 개발 라이브러리로 React 가 각광받았으며, 가장 큰 커뮤니티를 가지고 있다.


현재 React 는 여러 방법론의 조합 결과이다.

위의 소제목은 내가 React 를 다시 공부하기 전, 부족했던 웹 지식을 다시 쌓으면서 깨닫은

개인적인 문구이다.


현재 사람들은, 웹 개발을 위해 먼저 HTML 을 공부하는 것이 아니라, React 로 접하는 경우가 많아졌다.

심지어는, React 를 통해 JavaScript 를 익히게 된다.

사실상, React 의 최종 결과물은 HTML, JS, CSS 이며,

제작 과정은 JavaScript, TypeScript, Webpack 으로 이루어져 있는데,

React 를 시작하고, 아름다운 결과물을 먼저 관람 한 뒤, 구성된 프로그램을 나중에 배우게 된다.

나 또한 React 로 웹 개발을 시작 한 사람이다. 위의 과정은 실제로 내가 실행했던 순서이다.

React 는 공부 순서가 거꾸로 되어도 웹 페이지를 제작 할 수 있을 만큼, 쉽게 매력적인 라이브러리이다.

그러나, React 를 통해 웹 제작 실력을 중급으로 끌어올리기 위해서는 굉장히 힘든 과정이 이어진다.

그 이유는, React 를 사용하더라도, 결국 브라우저 유틸리티, JS 문법, 필요 라이브러리,

Webpack 의 구성 결과, package.json, tsconfig.json 의 설정 파일,

등등 수없이 많은 기초 지식이 결국은 사용되기 때문이다.

단순히 코드를 따라서 치다 보면, 따라가기가 어려워서 "일단 외우고 보자" 가 된다.

이 메서드와, 라이브러리, 및 프로그램을 "왜?" 사용하는지도 모르고 말이다.


따라서, React 는 여러 방법론의 조합 으로 나온 매우 간편한 라이브러리라는 것을 알아야 한다.

하나의 언어처럼 이를 익힌다면, 중급 이상의 기능을 익히기 위해

다시 기초로 돌아가야 하는 상황이 거의 무조건 일어날 것이라고 생각한다.


그래서, React 는 어떤 방법론을 사용하고 있나?

먼저, HTML, CSS, JS 만으로 웹 개발을 시작한 사람과,

React 로 웹 개발을 시작한 사람 사이에서 이해할 수 있는 방법론의 차이는 존재한다.

React 자체가 모든 것을 해 주고 있었으므로, 어떤 것을 도와줬는지 파악하기 어렵다.

나는 웹 개발 실력의 포텐셜(잠재력) 을 높이기 위해, 다시 태초마을로 돌아와서

사용되었던 방법론들을 공부 한 사람이다. 한번, 대표적인 예시를 들어 보겠다.


1. JSX, TSX 파일

리액트에서 컴포넌트를 제작하기 위해 사용되는 대표적인 파일이다.

웹 페이지 개발 시, 특정 시멘틱 태그를 이용한 DOM 조작에는 여러 방식이 존재한다.

  • document 최상위 객체에 존재하는 기능을 이용하여 DOM 객체 생성 & 속성 조작
  • 특정 태그 컴포넌트를 추출하여, 기본적으로 존재하는 기능 innerHTML 로 생성
  • append, appendChild, removeChild 등등 NodeList 조작 메서드 사용
  • 등등등...

여러 방식이 존재하나, 사용자 정의 컴포넌트나, 속성 주입 및 동적인 변화를 주기에 어렵다.

그리고, 애초에 JavaScript 에서 <div>...</div>, <span>...</span>

과 같이, 처음부터 태그를 사용하여 내부 중첩된 태그 표현식을 사용할 수 없다.


그러나, JSX, TSX 파일을 이용하여 컴포넌트를 제작하면, 컴포넌트 제작이 매우 쉬워진다.

  • 공유 유틸리티 Hook 들을 주입하기 매우 간편하다.
  • 컴포넌트 자체적으로 변수를 가질 수 있다.
  • React 에서, 대부분의 시멘틱 태그들을 구현 해 놓았다.
  • 컴포넌트 생성, 부착, 제거 등등의 과정에서 특정 행동을 지시 할 수 있다.
  • 제작한 컴포넌트와 사용자가 상호작용 하는 과정을 매우 쉽게 제작할 수 있다.
  • 무엇보다도, html 파일에 태그를 넣듯이 복잡한 계층을 쉽게 표현 할 수 있다.
  • 컴포넌트에 속성에 자주 변하는 속성을 넣을 수 있다.

예를 들어서, JSX 파일은 이렇게 작성된다 :

const CustomComponent1 = () => {
  return (
    <div>
      <span>내가 직접 만든 컴포넌트</span>
    </div>
  )
}

// or

function CustomComponent2 = ({props}) => {
  return (
    <div>
      <span>이 컴포넌트들 사용하는 상위 컴포넌트가 props 를 내려줄 수도 있음</span>
      <CustomComponent1 />
    </div>
  )
}

굉장히 쉽게 제작이 되고 있는 것을 알 수 있다.

심지어, 내가 만든 컴포넌트가 또 다른 컴포넌트에 삽입되어 반복, 혹은 공용 컴포넌트 제작이 간편하다.

이는 JavaScript 와, XML 표현 방식이 어울러진 방식으로, JSX 라고 부른다.

물론, 여기에 TypeScript 를 적용한다면, TSX 가 된다.


2. Webpack 을 이용한 번들링

위의 JSX, TSX 내용과 이어지는데,

위의 시멘틱 태그 및 커스텀 태그 표현식은 JavaScript 정식 Syntax 가 아니다.

원래는,

const CustomElement1 = () => React.createElement(
  'div',
  null,
  React.createElement('span', null, '내가 직접 만든 컴포넌트');
);

const CustomElement2 = (props) => React.createElement(
  'div',
  null,
  React.createElement(
    'span',
    null,
    '이 컴포넌트를 사용하는 상위 컴포넌트가 props 를 내려 줄 수도 있음'
  ),
  React.createElement(
    CustomElement1,
    null
  )
)

위와 같은 형식으로, 진정한 JavaScript 표현식으로 생성된다.

Webpack 은 JSX, TSX 파일에서 만들어진 컴포넌트들을

React.createElement 의 형식으로 재귀적으로 생성한다.

즉, JSX, TSX 파일은 그 자체로 정식 스펙이 아니라,

결국 Webpack 과 같은 번들링 프로그램으로 "다시 Parsing" 되는 파일이라는 것이다.


또한, sass 와 같은 스타일링 외부 확장자 또한 Webpack 이 인식하여

특정 컴포넌트에 안착시켜주는 역할도 진행한다.

따라서, 배포 시, 혹은 개발 시 웹 어플리케이션은 무조건 JS 와 CSS 로 실행되므로,

Webpack 은 이러한 의존 관계를 해석하여 js, css 로 만들고,

이를 각각 하나의 Chunk 파일로 만들어서 웹에 제공한다.

이 때, 파일의 크기가 너무 크다면, 이를 나누어서 Code Spliting(코드 스플리팅) 도 해준다.


이러한 파싱의 결과는 생각보다 외부에서 취약점을 찾는 데 쉬울 수도 있다.

따라서, Webpack 은 "코드 난독화" 를 진행하여, 읽지 못하도록 만들어 버린다.

즉, Webpack 은 개발은 편하게 만들어 주며, 컴파일 자동화 를 수행하고 있다.

그런데, 만약에 React + TypeScript 프로젝트를 진행하면서,

예를 들어 경로를 tsconfig.json 에 선언하여 간소화 시켰다면,

webpack 에도 이를 알려주는 설정 파일을 작성해야 할 것이다.


3. React Hook 과 Custom Hook

동적 페이지를 가장 간편하게 만들어주며,

개발자가 의도하는 페이지의 상호작용을 직접 커스텀하게 해 주는

가장 중요한 기능 중 하나라고 생각한다.

"아주 대표적인 Hook" 은, 바로 useState 이다.


우리가 홈페이지를 HTML 로 작성한다고 상상 해 보자.

우리는, 직접 만든 DOM 에 어떻게 변화된 데이터를 출력 할 것인가?

아마 HTML 태그 선언 후, 이러한 js 코드가 붙게 될 것이다.

<div>
    <span id="counter"></span>
    <button onclick="count()">카운트</button>
</div>

<script>
let count = 0;
const countText = document.getElementById("counter");
countText.innerText = count;

function count() {
  count++;
  countText.innerText = count;
}
</script>

위의 형식은, "정적 속성" DOM 과,

"동적 수행" 담당 JS 부분이 따로 나뉜 것이다.

물론 이러한 방식으로 동적 페이지 구성이 가능하긴 하겠지만,

그 수많은 컴포넌트의 동적 변화를 구성하기 위해서,

가독성이 매우 떨어질 뿐만 아니라, 이벤트 구독 및 수행을 구현하기 위해 너무 많은 코드가 작성된다.

여기서, React 는 각 컴포넌트가 독립적인 "함수 or 클래스" 로서,

자체적인 변수와 이벤트 리스너를 가지며, 이를 반환할 JSX 표현식에 사용 할 수 있다.

즉, React 만의 Hook 들이 존재하는데, 이 라이브러리가 쉽게 표현 해 준다.

const TestingComponent = () => {
  const [count, setCount] = useState(0);

  return (
    <div>
      <span>{count}</span>
      <button onClick={ () => setCount(count + 1) }>카운트 올리기</button>
    </div>
  );
}

jsx 표현식으로 매우 간단하게 표현 할 수 있다.

useState 는 아주 기본적인 React 의 Hook 인데,

count 는 useState 로 인해 등록된 변수를 "참조" 할 수 있는 일종의 변수이고, (변경 불가능)

setCount 는 useState 로 인해 생겨난 변수를 조작할 수 있는 Dispatcher 이다.

현재는 매우 지역적으로(좁은 영역으로) 사용하고 있어서 잘 못느끼겠지만,

Dispatcher 라는 개념은 React 에서 매우매우 중요하다.


또한, 들어오는 도메인 데이터를 중심으로 Custom Hook 파일을 만들어서,

컴포넌트가 원하는 Hook 들만 가져올 수 있게끔 만들수도 있다.


4. React 와 TypeScript

모든 JavaScript 기반 엔진들이 공통적으로 가지는 장점과 단점 (Pros and Cons) 가 있다.

  • 장점 : 타입이 너무 자유롭다
  • 단점 : 타입이 너무 자유롭다

JavaScript 로 처음 공부하면 너무나도 자유로운 타입 덕분에 코딩이 매우 쉽다.

컴파일 언어가 아니라, 인터프리터 언어이기에, 실행 중에 번역되어 사용된다.

저수준 ~ 중간 수준의 언어는 "먼저 타입 선언" 이 필수이기 때문에,

주고받으며, 처리하는 데이터의 유형이 코드에 명확히 선언되어야 한다.

그러나, JavaScript 는 전혀 그렇지 않다.

어떤 코드 방식까지도 가능하냐면,

"일단 변수명을 선언 해 놓고, 원하는 데이터를 내부에서 추출하자" 가 가능하다.

이는 초기 단계에서는 매우 간편하나, 데이터가 복잡해질 경우

스파게티 코드가 될 확률이 매우매우 높다.


이런 JavaScript 의 단점을 해소하기 위해, 타입 선언적 언어로 만들어 주는 것이

TypeScript 이다. 물론, 그 자체로 "언어"라기 보다는,

JavaScript 의 SuperSet 이다.

TypeScript 는 결국 JavaScript 로 컴파일 되어야 한다.

그럼에도 불구하고, TypeScript 는 강력한 타입 체계를 가지고 있으며,

타 언어보다 타입 선언에 대해 자유롭다는 장점이 있다.


React 와 TypeScript 는 어떤 조합을 이룰까?

React 는 사용자의 상호작용과 데이터 변화에 매우 민감하다.

어떤 이벤트가 발생하면, React 내부의 Virtual DOM 에서 이를 받아들여 변화시키기 때문이다.

React 는 특정 컴포넌트가 상위 컴포넌트로부터 받는 props 라는 객체와,

자신의 하위 컴포넌트에게 내려주는 props 객체가 있다.

이 데이터들은 일관성을 지킬 필요가 있는데,

컴포넌트들은 개발자의 의도와 방향에 따라 props 의 데이터에 의해

다양한 방식으로 표현 될 수 있기 때문이다.


뿐만 아니라, 전역 데이터 객체, 지역 데이터 객체를 정해 줄 때

타입 시스템은 매우매우 중요하다.

개발 과정에서 개발자의 가독성은 물론, 데이터를 정하여 규칙을 세울 수 있기 때문이다.

만약에 TypeScript 가 존재하지 않았다면, 일관성 있는 웹 어플리케이션 개발은 훨씬 어려워 질 것이다.


뿐만 아니라, React 프로젝트 내부에 따로 TypeScript 인터페이스 파일을 지정하여

React 에서 사용될 모든 객체에 대해서 정확한 형식을 명명할 수 있으며,

이를 다시 활용하여 복잡한 객체의 타입 시스템을 만들 수 있다.

타입 시스템 덕분에, 리액트 테스팅 과정에서

원치 않는 데이터를 걸러내거나, 경고 화면을 보아 사전에 버그를 차단할 수 있다.

물론, 이 모든 데이터들은 프로덕션 과정에서 JS 로 파싱된다.

사실, 애초에 TypeScript 는 모두 JS 로 파싱되어 실행된다.

단순히 개발 편의성을 위해 결과 파일만 내놓지 않을 뿐이다.


React 와 Style Library

리액트는 컴포넌트 스타일링에 대해 다양한 방법론을 제시한다.

그리고, 이 스타일링 기법들은 React 컴포넌트 형식에 대해 안성맞춤 급으로 편리하다.


하지만, 스타일링 기법은 주로 2 가지로 나눌 수 있다.

  1. css 결과물로 나옴
  2. css 결과물 없이 js 로 같이 컴파일

그렇다면, css 로 결과물이 나오는 방법은 무엇일까?

일단 생각나는 대로 적자면,

  • sass
  • scss
  • css - 주로 전역 스타일링으로 사용됨

위에서 적힌 sass, scss 와 같은 확장자 파일은,

css 문법에서 확장된 버전이다.

특정 컴포넌트에만 사용하기 위해서는 jsx or tsx 파일에서 import 로 가져와야 한다.

이유는, 바로 Webpack 이 각 파일을 순회하며 의존성을 파악해야 하기 때문이다.


두 번째로, js 로 스타일링 결과가 나오는 방식이다.

  • Tailwind
  • Banilla Extract
  • Styled-Component

-Tailwind-

테일윈드는 DOM 자체의 class 속성을 이용하여 스타일링 한다.

하지만, 클래스 이름이 너무 복잡해 진다는 단점이 존재한다.

그리고, tailwind 만의 문법을 따로 배워야 한다.


-Banilla Extract-

바닐라 익스트랙트는 팀 프로젝트에서 공통된 css 를 사용하기 위해 좋은 선택이라고 생각한다.

사용할 css 객체 파일을 생성하여 따로 작성하며,

이 객체는 내부에서 각 DOM 의 태그, 혹은 클래스에 대한 스타일링을 먼저 선언 해 놓는다.

이 복잡한 객체는 props 로 하위 태그들에 전해지고,

개발자는 css 객체 props 에서 원하는 스타일링을 꺼내서 컴포넌튿에 적용 할 수 있다.


-Styled-Component-

특정 컴포넌트, 혹은 태그 컴포넌트 등등에 사용할 수 있는

css 적용 객체를 선언하는 것이다.

주로 템플릿 문자열 `` 을 사용하며,

Styled-Component 로 제작한 객체는 그 자체로 컴포넌트가 되어서,

이를 렌더링 할 수 있다.

즉, 커스텀 컴포넌트를 생성하여 만드는 것과 큰 차이는 없다.

그러나, 항상 정적으로 적용되는 css 파일에서

현재 JavaScript or TypeScript 의 데이터 상황에 따라 변경할 수 있다는 것이

매우 큰 장점이다.


React 가 방법론의 조합이라는 것이 나쁜 것인가?

그건 절대로 아니다.

React 는 정말 수많은 방법론을 스스로 자유롭게 결합시키면서,

독보적인 웹 개발 라이브러리로서 일어섰다.

특히, 스스로를 "프레임워크" 가 아닌, "라이브러리" 라고 지칭하는 데에

매우 깊은 의미가 있음을 알 수 있다.


-내가 말하고자 하는 것은,-

React 에 어떤 것이 적용되었는지를 알아야, React 중~고급 수준으로 갈 수 있다는 것이다.

처음에 useState 를 통한 컴포넌트의 re-렌더링을 본다면, 도파민이 나올 수도 있다.

그러나, 나중에 Context 와 전역 데이터 객체, useEffect 와 생명주기를 같이 다룬다면,

  • React 가 변수로 함수를 왜 주는지,
  • React 는 내가 원하는 페이지를 왜 렌더링 하지 않았는지,
  • 왜 두 번의 Dispatch 이벤트가 적용되지 않고, 한 번만 적용되었는지
  • 등등 수많은 현상들..

이러한 현상들을 이해 할 수 없으며, 디버깅하기 매우 어려울 것이다.

특히나, 현재로서는 AI 가 매우 발달 했기 때문에,(현재 o3)

이러한 웹 개발은 AI 가 다 해줘서 괜찮다고 생각 할 수도 있다.

그러나 한번 생각 해 보자.

"AI 가 생성한 React 코드를 스스로 이해 할 수 있는가?"

만약에 AI 한테 특정 데이터셋에 대한 컴포넌트 계층과 코드를 만들어 달라고 부탁했다고 가정 해 보자.

여러 번의 질문을 통해, 10 개의 복잡하며 깔끔한 파일이 탄생했고,

이제 이 10 개의 컴포넌트를 사용하는 포용적인 컴포넌트를 사용한다고 가정 해 보자.

그렇다면, AI 에게 어떤 질문을 해야 할까?


그렇다. AI 에게 올바른 질문을 하기 위해서는, 나 또한 AI 와 같이 융화 될 정도로

사용된 기술에 대한 이해도를 갖춰야 하는 것이다.

이해도를 결국 갖추지 못한다면, AI 에 끌려 다니거나,

결국 AI 가 만든 깔끔한 코드들은 대부분 "기술 부채" 가 되어 나에게 화살로 날아올 것이다.

이것은, 프로젝트를 처음 만드는 것 보다 못하다고 개인적으로 생각된다.


따라서, "방법론" 이라는 키워드에 집중하는 것은,

React 에 적용된 수많은 편리성 라이브러리들의 결합과 사용을 이해하지 못한다면,

결국 프로덕션 수준의 웹 어플리케이션은 제작하기 매우 어려울 것이란 것이 내 판단이다.


그렇다면 어떻게 React 공부를 해야 할까?

나 스스로도 매우 고민했던 부분이기도 하다.


우리는 개발자, 혹은 개발 엔지니어로서, React 를 배운다.

그래서 우리는 React 를 왜 배우는가?

다양한 목적이 있을 것이다. 그러나, 내가 대부분 맞을 거라고 생각하는 의견은,

React 를 "실제 사용자가 이용할 수 있을 정도의 프로덕션 웹을 만드는 것" 이라고 생각한다.

어쨌든 웹 어플리케이션을 제작한다는 것은, 혼자만의 만족을 위해서라기 보다는,

사용자의 편의성과 사용에 초점이 훨씬 더 맞춰져 있다고 생각한다.

따라서, "프로덕션 급으로 제작하기 위한 실력을 갖춰야 한다" 가 내 의견이다.

  1. HTML 구조 이해
  2. DOM 객체와 JavaScript 조작 과정을 이해
  3. CSS 파일에 대한 이해
  4. JavaScript 의 기본 메서드에 대한 이해
  5. JSON 객체 사용법의 이해
  6. JavaScript 와 이벤트 등록 이해 - AI 한테 물어보기를 추천
  7. 클라이언트 사이드에서 데이터 fetch 하는 방법 - EX - axios

이번 글을 작성하며 느낀 것

나는 이전에 React 로 웹 공부를 시작했었고, 단순 React 지식만으로는 분명한 한계를 느꼈다.

따라서, JavaScript 를 공부했으며, 프로젝트에 NestJS 를 공부하기도 하며,

DOM 의 공식문서를 이용한 간단한 Component 시스템 제작,

"웹 서버란 무엇인가?" 에 대한 블로그 글을 작성하며 조사,

그리고 HTML5 정식 스펙에 존재하는 "모든 태그" 150개 정도? 를 조사하여 작성했다.

뿐만 아니라, Webpack 의 작동 원리와 의존성 관계 파악 이해,

package.json, tsconfig.json 의 역할과 옵션을 명시하여 설명하는 블로그 글도 제작했다.

그리고, package.json 과 npm 모듈에 내장되어 있는 CLI 옵션을 사용하는 법에 대해서도 공부했다.

음... 이렇게 보면 웹 개발이라는 목적에 비해 과하게 공부하고 조사 한 감이 있긴 하지만,

나는 이전에 느꼈던 한계를 빠르게 느끼기 싫다.

나는 마치 로그라이크 게임처럼, 태초마을로 돌아와서 공부하고 있지만,

이번에는 아주 멀리멀리 날아 갈 생각이다.


참고 사이트

최신 리액트 공식 사이트

https://ko.react.dev/


이전 리액트 문서 (시작하기)

https://ko.legacy.reactjs.org/docs/getting-started.html


이전 리액트 문서 (웹사이트에 React 추가)

https://ko.legacy.reactjs.org/docs/add-react-to-a-website.html


이전 리액트 문서 (JSX 이해하기)

https://ko.legacy.reactjs.org/docs/jsx-in-depth.html


이전 리액트 문서 (Hook 소개)

https://ko.legacy.reactjs.org/docs/hooks-intro.html