[인턴IN메타] React의 '왜'를 파고들다: 레거시 코드에서 배우는 최신 프레임워크의 본질

아는 것과 '설명할 수 있는 것'의 차이

베테랑 개발자일수록 기본기의 중요성을 강조합니다. 저 역시 이번 인턴IN메타 1주 차 React 기본 개념 학습을 통해 그 중요성을 다시 한번 체감했습니다. 익숙하다고 생각했던 개념들이었지만, '왜 그렇게 동작하는가?'라는 스스로의 질문 앞에서 순간 머뭇거리게 되더군요.

특히 퀴즈의 오답들은 React가 클래스 컴포넌트에서 함수형 컴포넌트와 Hook으로 진화해 온 이유를 명확하게 보여주는 '살아있는 역사'와 같았습니다. 이 글을 통해 단순히 'state는 변경 가능, props는 불가능'과 같은 단편적인 지식을 넘어, React의 핵심 철학과 발전 방향을 함께 고찰해보고자 합니다.

 

1. 틀린 문제에서 발견한 성장의 기회: React의 진화와 '왜'

기존에 다수의 React 프로젝트 경험이 있었기에, 자신감을 가지고 영상 시청 전 퀴즈부터 풀어봤습니다. 결과는 아쉽게도 10개의 문제 중 두 개나 틀렸지만, 결과 자체가 흥미로웠습니다. 맞힌 문제보다 틀린 문제에서 더 큰 배움을 얻었기 때문입니다. 특히 현재는 잘 사용되지 않는 레거시 문법 관련 문제들은 '왜' 기술이 변화해왔는지, 그 본질을 다시금 생각하게 하는 좋은 계기가 되었습니다.

 

퀴즈 과업 중 오답 부분

인턴IN메타_응용SW_5일차 과업 중 일부 캡처

 

createComponent(), getInitialState()... React를 처음 배울 때나 볼 수 있었던, 이제는 다소 낯선 함수들입니다. 사실 답안을 검토하기 이전까지는 해당 함수들의 존재조차 까먹고 있었습니다.

 

1.1 오답 고찰 : 문제 6

문제 6의 'React에서 컴포넌트를 만드는 명령어는 무엇인가요?' 라는 질문에 createComponent() 함수는 커녕 함수 선언문(Function Declaration) 방식과 화살표 함수 표현식(Arrow Function Expression) 방식만이 머릿속에 떠올랐으며, 화살표 함수 표현식을 주관식 정답으로 제출하기에는 애매하다는 생각이 들어 함수 선언문 방식인 'function' 키워드를 정답으로 제출했었습니다.

 

함수 선언문(Function Declaration) 방식

function MyComponent(props) {
  return <div>Hello, {props.name}</div>;
}

 

화살표 함수 표현식(Arrow Function Expression) 방식

const MyComponent = (props) => {
  return <div>Hello, {props.name}</div>;
};

 

그렇다면 두 방식중에는 어떤걸 사용하는것이 왜 좋은건지 라는 의문이 생깁니다. 결론부터 말하자면, 실무에서는 팀의 컨벤션에 따라 다르지만 화살표 함수의 선호도가 높은 경향이 있다고 합니다. 이는 두 방식의 미묘하지만 중요한 차이점 때문입니다.

 

함수 선언문 방식과 화살표 함수 방식의 비교

구분	함수 선언문 (function)	화살표 함수 (const ... = () => {})
this 바인딩	함수가 호출될 때 this가 결정됨	함수가 선언될 때의 상위 스코프 this를 그대로 가짐
호이스팅(Hoisting)	O (선언부가 최상단으로 끌어올려짐)	X (변수 선언 규칙을 따르므로 예측 가능)
문법	function 키워드 사용	더 간결하며, 암묵적 반환(implicit return) 가능

 

화살표 함수는 문법이 간결하고, 호이스팅이 발생하지 않아 코드의 실행 순서를 예측하기 쉽다는 장점이 있습니다. 특히 과거 클래스 컴포넌트에서 고질적인 문제였던 this 바인딩 이슈를 해결하는 데 매우 유용했기 때문에, 이 스타일이 현재까지 선호되는 경향이 있습니다.

물론 두 방식 모두 유효하며, 어느 하나가 절대적으로 우월한 것은 아닙니다. 중요한 것은 "두 방식의 차이점을 명확히 이해하고, 팀의 코드 스타일에 맞춰 일관성을 유지하는 것" 입니다. PM이나 시니어 개발자라면 이러한 기술적 트레이드오프를 이해하고 프로젝트의 기술 표준을 정립하는 역량이 반드시 필요하다는 생각이 들었습니다.

---

1.2 오답 고찰 : 문제 7

더불어 문제 7에서 'React에서 컴포넌트의 상태를 초기화할 때 사용하는 메서드는 무엇인가요?' 라는 질문에는 아래의 코드를 떠올리며 useState라고 답한 제 답변은 오답 처리되었습니다.

import React, { useState } from 'react';

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

 

1.3 고찰 결론
이 문제들은 React가 클래스(Class) 컴포넌트를 사용하던 시절을 생각하며 작성되었지만, 저 자신은 현재 프로젝트를 진행해 본 경험을 바탕으로 현재 사용하는 방식인 함수형 컴포넌트와 Hook의 시대만을 생각하며 답안을 작성한 것이 가장 큰 오답의 이유라고 생각합니다.

과거: 클래스 컴포넌트의 방식

• React.createClass() 나 ES6의 class 문법으로 컴포넌트를 생성했습니다.
• getInitialState() 메서드 안에서 컴포넌트의 초기 상태를 객체 형태로 반환하여 설정했습니다.
• this 키워드를 통해 상태나 생명주기 메서드에 접근해야 했기에, this가 가리키는 대상이 달라지는 문제(this binding)로부터 자유롭지 못했습니다.

현재: 함수형 컴포넌트와 Hook의 시대

• 왜 바뀌었을까요? 클래스 컴포넌트는 코드가 길어지고, 재사용이 어려우며, 생명주기 메서드를 이해하고 사용하기 복잡하다는 단점이 있었습니다.
• React 16.8 버전부터 도입된 Hook은 이러한 문제들을 해결했습니다.
  • 'function'이나 'const ... = () => {}' 키워드로 훨씬 간결하게 컴포넌트를 선언합니다.
  • useState() Hook을 사용해 직관적으로 상태를 생성하고 관리합니다.
  • useEffect() Hook으로 생명주기 관리를 통합하여 코드를 이해하기 쉽게 만듭니다.

오히려 틀린 문제들 덕분에, React가 개발자의 더 나은 경험과 코드의 간결성, 재사용성을 위해 얼마나 치열하게 고민하며 발전해왔는지 명확히 이해할 수 있었습니다. 이는 단순히 문법을 아는 것을 넘어, 프레임워크의 철학을 이해하는 귀중한 학습 경험이었습니다.

 

2. 아는 것을 넘어 설명할 수 있는가: State와 Props, 그리고 상태 끌어올리기

이 문제는 정답을 맞혔습니다. 하지만 여기서 멈추지 않고 한 단계 더 깊이 들어가 보겠습니다.

인턴IN메타_응용SW_5일차 과업 중 일부 캡처

 

'state는 변경 가능, props는 불가능'이라는 규칙은 React의 단방향 데이터 흐름(One-Way Data Flow) 원칙을 지키기 위한 핵심적인 장치입니다. 데이터는 항상 부모에서 자식으로, 위에서 아래로 흐릅니다.

그렇다면 이런 의문이 생깁니다. "만약 자식 컴포넌트에서 발생한 이벤트가 부모 컴포넌트의 상태를 바꿔야 한다면 어떻게 해야 할까요?"

이 질문에 대한 해답이 바로 '상태 끌어올리기(Lifting State Up)' 패턴입니다.

• 문제 상황: 자식 컴포넌트(예: InputBox)의 입력값이 부모 컴포넌트(예: Form)의 상태를 변경해야 할 때, 자식은 부모의 state를 직접 수정할 수 없습니다. (props는 읽기 전용이므로)
• 해결 방안:
  1. 상태는 공통의 부모에 위치시킵니다. 상태를 변경해야 하는 여러 컴포넌트들의 가장 가까운 공통 부모 컴포넌트가 state를 소유합니다.
  2. 부모는 상태를 변경하는 함수를 정의합니다. (예: handleValueChange)
  3. 부모는 자식에게 state 값과 함께 상태 변경 함수를 props로 내려줍니다.
  4. 자식은 이벤트가 발생했을 때 props로 전달받은 함수를 호출하여 부모의 상태 변경을 '요청'합니다.

 

상태 끌어올리기 예시 코드 (입력 필드 동기화)

import React, { useState } from 'react';

// 자식 컴포넌트 (화살표 함수로 정의)
const SharedInput = ({ label, value, onValueChange }) => {
  return (
    <label>
      {label}:
      <input value={value} onChange={onValueChange} />
    </label>
  );
};

// 부모 컴포넌트 (화살표 함수로 정의)
const SyncedFields = () => {
  // 1. 상태(value)를 공통 부모가 단독으로 소유합니다.
  const [value, setValue] = useState('');

  // 이벤트 핸들러 함수
  const handleValueChange = (e) => {
    setValue(e.target.value);
  };

  return (
    <div>
      {/* 2. 두 자식에게 동일한 상태값과 상태 변경 함수를 props로 전달합니다. */}
      <SharedInput
        label="첫 번째 입력"
        value={value}
        onValueChange={handleValueChange}
      />
      <br />
      <SharedInput
        label="두 번째 입력"
        value={value}
        onValueChange={handleValueChange}
      />
    </div>
  );
};

export default SyncedFields;

 

이처럼 'state와 props의 차이'라는 단순한 지식은 상태 끌어올리기라는 실용적인 설계 패턴으로 이어집니다. 이를 이해해야 비로소 컴포넌트 간의 상호작용을 효과적으로 관리하고, 예측 가능하며 유지보수가 쉬운 React 애플리케이션을 만들 수 있습니다.

 

3. 컨텐츠 피드백 및 진행 소감: 학습 자료의 '최신성'에 대하여

이번 1주 차 학습을 진행하며 한 가지 아쉬웠던 점은 일부 학습 자료의 '최신성'이었습니다. 특히 Git과 GitHub의 개념을 설명하는 영상 자료는 SW 개발 생태계의 빠른 변화를 충분히 담아내지 못하고 있다는 인상을 받았습니다.

 

인턴IN메타_응용SW_4일차 과업 중 일부 캡처

 

영상에 등장하는 GitHub의 화면은 UI 디자인과 피드 내용을 분석했을 때, 대략 2012년 ~ 2013년경의 모습으로 추정됩니다. 물론 Repository, Fork, Pull Request와 같은 GitHub의 핵심 개념은 예나 지금이나 변함없이 중요합니다. 하지만 10년이면 강산이 변하듯, GitHub의 UI/UX와 개발 워크플로우는 완전히 다른 차원으로 발전했습니다.

 

3.1 왜 최신성이 중요할까요?

IT, 특히 SW 분야는 하루가 다르게 발전합니다. 과거의 인터페이스를 보고 학습한 초심자가 현재의 GitHub 사이트에 접속했을 때, 완전히 다른 모습에 당황하며 불필요한 학습 장벽을 느낄 수 있습니다.

또한, 오늘날의 개발 환경은 훨씬 더 효율적인 도구들을 제공합니다. 예를 들어, 복잡한 Git 명령어를 몰라도 누구나 쉽게 버전 관리를 시작할 수 있도록 돕는 'GitHub Desktop' 과 같은 GUI 툴은 이제 표준처럼 사용되고 있습니다. 뿐만 아니라, ▲코드 리뷰와 협업을 극적으로 개선한 Pull Request 인터페이스 ▲자동화된 빌드와 배포를 위한 GitHub Actions ▲클라우드 기반의 통합 개발 환경인 Codespaces 등은 현대적인 개발자에게 필수적인 도구입니다.

따라서 기본적인 개념 설명과 더불어, 이러한 최신 도구와 발전된 워크플로우를 함께 소개해준다면 교육의 효과가 극대화될 것이라 생각합니다. 이처럼 건설적인 피드백을 통해 '인턴IN메타' 프로그램이 앞으로 더욱 발전하고 참여자들에게 더 큰 가치를 제공하기를 기대합니다.

 

3.2 진행 소감

최근 좋은 기회로 '인턴IN메타' 프로그램에 참여하게 되어, 어느덧 정신없지만 알찼던 첫 주차를 성공적으로 마쳤습니다.

인턴IN메타 교육 일정표 중 일부 캡쳐

 

이번 인턴IN메타 1주차 활동은 React에 대한 제 지식을 점검하고, 더 깊은 이해를 얻는 소중한 시간이었습니다. 특히 레거시 코드를 통해 최신 기술의 '존재 이유'를 배우고, 기본적인 개념에서 '상태 끌어올리기'와 같은 실무 패턴을 연결지어 생각하는 과정은 매우 긍정적인 경험이었습니다.

결국 기술의 본질을 꿰뚫어 보는 힘은 이처럼 기본기를 끊임없이 되짚어보고, '왜?'라는 질문을 던지는 데서 나옵니다. 앞으로 남은 챌린지 기간 동안에도 이러한 자세로 학습에 임하며, 단순한 지식의 나열이 아닌 깊이 있는 인사이트를 공유하겠습니다.

여러분의 경험은 어떠신가요? React의 기본 개념을 공부하며 특별히 어려웠거나, 새롭게 깨달은 점이 있다면 댓글로 공유해주세요. 이번 포스팅은 이번 주차에 작성한 주간 회고 기록을 남기며 글을 마칩니다.

 

1주차 주간 회고 기록

 

 

---

◆ 관련 링크

• [인턴IN메타] 홈페이지 LINK

인턴IN메타