React는 왜 HTML, CSS, JS를 한 곳에 모았을까?

웹 개발을 처음 배울 때 우리는 HTML은 구조, CSS는 스타일, JavaScript는 동작을 담당한다고 배웠습니다. 그래서 각 기술을 다른 파일에 나눠서 작성하는 것이 **Separation of Concerns(관심사의 분리)**라는 모범 사례로 여겨졌죠.

하지만 React는 이 전통적인 방식을 깨고, 모든 것을 하나의 컴포넌트 파일 안에 통합해버렸습니다. 이게 처음엔 이상하게 느껴지기도 하죠. "왜 굳이 HTML, CSS, JS를 뒤섞을까?" 하는 의문이 생깁니다.

이번 포스트에서는 이 의문을 풀고, React가 왜 이런 구조를 택했는지, 어떤 의미의 관심사 분리를 따르고 있는지를 살펴보겠습니다.

---

전통적인 구조: 기술별로 파일을 분리하던 시절

기존의 웹 개발에서는 다음과 같은 구조가 일반적이었습니다:

• index.html: 마크업
• style.css: 스타일
• script.js: 동작

이처럼 기술별로 파일을 나누는 것이 **관심사의 분리(Separation of Concerns)**라고 불렸고, 유지보수성과 확장성에 있어서 유리한 방식으로 여겨졌습니다.

---

SPA의 등장과 JavaScript의 주도권

하지만 시간이 지나면서 웹은 점점 **인터랙티브한 싱글 페이지 애플리케이션(SPA)**으로 진화했습니다. 이때부터 JavaScript는 단순한 보조 도구가 아닌 UI를 주도하는 중심 기술이 되었습니다.

예를 들어 버튼을 누르면 화면이 바뀌고, 데이터에 따라 동적으로 내용이 렌더링되는 UI가 늘어나면서 HTML과 CSS는 JavaScript에 종속되기 시작했습니다.

즉, JavaScript가 UI를 결정하게 되었고, 이는 논리와 구조(마크업)가 밀접하게 얽히게 되는 구조로 발전했습니다.

---

컴포넌트 중심 사고의 시작

이렇게 논리와 UI가 강하게 결합된 상황에서, React는 다음과 같은 질문을 던졌습니다:

이미 논리와 UI가 붙어 있는데, 굳이 파일을 따로 나눌 필요가 있을까?

그 결과 탄생한 것이 바로 React 컴포넌트입니다. 하나의 컴포넌트 안에:

• 데이터 (State, Props)
• 로직 (함수, 이벤트 처리 등)
• UI 정의 (JSX)
• 스타일 (선택적 co-located 스타일)

을 모두 함께 정의합니다.

---

관심사의 분리는 여전히 존재한다

React가 전통적인 방식처럼 기술별로 파일을 나누지는 않지만, 그렇다고 해서 관심사의 분리가 아예 사라진 것은 아닙니다.

React는 **"기능 단위"의 관심사 분리(Component-based SoC)**를 따릅니다.

전통 방식은 기술 단위로 나누었고,
React는 UI 단위로 나눕니다.

즉, 하나의 컴포넌트는 UI의 한 조각을 표현하며,
그 컴포넌트 내부에 관련된 모든 로직과 데이터, 스타일을 담는 것이죠.

이런 구조를 co-location이라고 부르며,
"변화가 함께 일어나는 코드들을 함께 두자"는 철학에서 출발했습니다.

---

초창기 반응은? 그리고 현재는?

React와 JSX가 처음 등장했을 때 많은 개발자들은 불편함을 느꼈습니다. 익숙하지 않고, 구조가 어지러워 보였기 때문입니다.

하지만 시간이 지나면서 많은 개발자들이 이 구조에 익숙해졌고, 그 장점이 입증되었습니다:

• 컴포넌트 단위로 개발/유지보수가 쉬움
• 재사용성, 테스트 용이성 증가
• 로직과 UI를 함께 다루는 자연스러운 흐름

---

결론: React는 다른 형태의 관심사 분리를 따른다

React는 전통적인 "기술별 파일 분리" 방식을 버리고, "컴포넌트 중심 분리"라는 새로운 접근을 도입했습니다. 이 방식은 복잡한 현대 웹 애플리케이션의 요구에 훨씬 잘 들어맞으며, 실제로 많은 개발자들이 이 방식에 익숙해져 있습니다.

결국 핵심은: 기술 단위가 아니라 기능 단위로 관심사를 분리하는 것.
React는 이 철학을 구현한 대표적인 프레임워크입니다.