2024년 12월 24일 화요일

리액트는 프레임워크인가? : 부채가 아닌 투자를 위한 질문

글을 통해 전하고 싶은 메세지

리액트는 렌더링 라이브러리이다.
내 문제를 다른 사람의 코드로 완벽하게 해결할 수는 없다. 이와 관련된 기술 부채는 항상 염두에 둬야 한다.
프레임워크, 라이브러리의 개념과 특징이 무엇인지 명확히 알고, 이에 따라서 내가 맞닥뜨린 문제에 대해 적합한 솔루션을 선택할 수 있는 기준을 키워야 한다.

개요

리액트는 공식적으로 라이브러리이다.

그러나 리액트를 마냥 라이브러리로 바라봐야하는 건가? 하는 이야기가 종종 들리는 듯 하다.

먼저 내 생각을 밝히면 "리액트는 라이브러리이다."라고 설명할 수 있을 것 같다. 단정짓는 건 별로 좋은 습관은 아니지만.. 적어도 내 기준에서는 이렇게 확실하게 말할 수 있을 것 같다.

그러면 지금부터 하나씩 살펴보자.

프레임워크와 라이브러리

리액트가 프레임워크인지, 라이브러리인지 판단하기 위해서 먼저 이 둘의 차이점을 분명하게 이해할 필요가 있을 것 같다.

프레임워크 없는 프론트엔드 개발의 저자인 '프란세스코 스트라츨로'는 라이브러리와 프레임워크의 구분을 다음과 같이 설명하고 있다.

프레임워크는 코드를 실행시킨다. 코드는 라이브러리를 실행시킨다.

나도 이 관점이 프레임워크와 라이브러리의 차이를 분명하게 보여준다고 생각한다.

프레임워크를 사용한다는 것은 곧, 도구가 강제하는 방법에 따라서 개발이 이루어진다는 의미이다.

좀 더 명확하게 표현하면 프레임워크가 애플리케이션의 제어 흐름을 관리하며, 개발자는 프레임워크가 제공하는 구조 안에서 코드를 작성한다는 데 있다.

반대로 라이브러리는 개발자가 관리하는 제어 흐름 안에서 이를 호출한다는 게 보다 분명하게 표현되는 차이점이라고 볼 수 있다.

그림으로 표현하면 위와 같다.

프레임워크 방식이란?

책을 바탕으로 학습을 하고 있기에, 저자의 생각을 빼놓을 수 없을 것 같다.

작업을 처리할 때 '프레임워크 방식'을 사용하고 있다면 프레임워크로 볼 수 있다.

저자가 책에서 제시한 프레임워크의 판단 기준이다.

프레임워크 방식(Framework's way)이란 무엇일까?

책을 통해 접한 나에게 있어서 새로운 개념이다.

쉽게 말하면 도구를 사용하기 위해서 강제되는 것들로, 앵귤러를 예로 들어서 설명하면 다음과 같다.

언어 : TypeScript가 앵귤러 생태계의 사실상 표준이다. (de facto)
의존성 주입 : 요소(Element)가 앵귤러 애플리케이션에서 통신하려면 유형에 따라 의존성 주입(dependency injection) 메커니즘을 사용해야 한다.
옵저버블 : 앵귤러는 표준 방법인 프라미스(Promise)대신 옵저버블(Observable)을 사용한 반응형 프로그래밍용 라이브러리인 RxJS를 기반으로 설계되었다.

위의 몇몇 요소는 반드시 사용되어야 하는 것은 아니지만, 커뮤니티 사용자들에 있어서 사실상 표준(de facto)처럼 사용되는 방식이다.

결국 프레임워크 방식이란, 프레임워크이든 아니든 상관 없이 커뮤니티 사용자에 의해서 사실상 표준처럼 어떤 규칙이 강제되고, 보편화되어서 사용되는 것을 의미한다고 볼 수 있다.

프레임워크 방식 관점에서의 리액트

리액트도 이런 관점에서 살펴보면 프레임워크 방식에 해당한다고 볼 수 있다.

React.createElement나 클래스 문법 등을 사용해서 Vanilla JS 처럼 명령형 방식으로 DOM을 조작할 수 있다.

그러나, 현재의 리액트에서 보편적으로 쓰이는 방식은 JSX 등에 기반한 선언형 방식이다.

또한 최근의 리액트 커뮤니티에서는 함수형 방식 사용을 권장하고 있다.

이에 따라 useState, useEffect, useRef 등의 선언형 방식으로 사용하는 것이 보편화 되었다.

이런 관점을 좀 더 이해하기 위해서 코드를 살펴보자.

선언형 코드
명령형 코드

선언형 코드
  import React, { useState } from 'react';

  const Counter = () => {
    // useState Hook을 사용하여 상태 관리
    const [count, setCount] = useState(0);

    // 카운트 증가 함수
    const increment = () => {
      setCount(prevCount => prevCount + 1);
    };

    // 카운트 감소 함수
    const decrement = () => {
      setCount(prevCount => prevCount - 1);
    };

    return (
      <div>
        <h2>카운터: {count}</h2>
        <button onClick={increment}>증가</button>
        <button onClick={decrement}>감소</button>
      </div>
    );
  };

  export default Counter;

명령형 코드
  import React, { Component } from 'react';

  class Counter extends Component {
    constructor(props) {
      super(props);
      // 상태 초기화
      this.state = {
        count: 0,
      };
      // 메서드 바인딩
      this.increment = this.increment.bind(this);
      this.decrement = this.decrement.bind(this);
    }

      // 카운트 증가 메서드
    increment() {
      this.setState((prevState) => ({
        count: prevState.count + 1,
      }));
    }

      // 카운트 감소 메서드
    decrement() {
      this.setState((prevState) => ({
        count: prevState.count - 1,
      }));
    }

    render() {
      return (
        <div>
          <h2>카운터: {this.state.count}</h2>
          <button onClick={this.increment}>증가</button>
          <button onClick={this.decrement}>감소</button>
        </div>
      );
    }
  }

  export default Counter;

리액트 사용자라면 명령형 방식에서 어색함이 느껴질 수도 있을 것 같다.

하지만, 엄연히 동작하는 방식이다. 그러나, 우리는 커뮤니티나 공식 문서 등에서 권장하는 방식에 익숙해져 있기에 이런 코드 작성법이 다소 어색해보일 수 있다.

이게 바로 프레임워크 방식이다. 프레임워크는 아니나, 커뮤니티에 의해서 프레임워크처럼 쓰이는 사실상 표준 방식.

리액트는 그러면 프레임워크인가?

작업을 처리할 때 '프레임워크 방식'을 사용하고 있다면 프레임워크라고 볼 수 있다.

저자의 기준대로라면 프레임워크라고 이야기할 수 있을 듯 하다.

다만, 나의 생각은 조금 다르다.

프레임워크의 기준은 프레임워크와 라이브러리에서 확인한 기준으로 평가하는게 맞다고 생각한다.

실제로 리액트의 경우, vanilla JS로 작성한 코드 흐름 내에서 일부분만 리액트로 작성해서 사용할 수 있다.

즉, 개발자가 작성한 코드의 흐름 내에서 리액트를 실행시킬 수 있다는 것이다.

리액트를 프레임워크로 정의하고, 위의 기준대로 리액트의 흐름에 따라서 개발을 해야한다면 자칫 잘못하면 유연한 사고 방식을 잃을 수 있다고 생각한다.

더불어, 도구가 해결하고자 하는 문제가 있을 텐데, 그 본질을 놓힐 가능성이 있을 수 있다.

그렇기에, 리액트는 라이브러리로 바라보는 것이 보다 좋은 접근 방법이다라고 생각한다.

기술 부채

혹자는 이런 구분을 왜 알아야하는지 의문을 품을 수 있다.

이를 깊게 다뤄본 이유는 프레임워크의 사용은 무료가 아니기 때문이다.

여기서 말하는 무료라는 개념은 오픈소스처럼 돈을 내지 않고 사용한다는 의미가 아니다. 유지보수 관점에서 프레임워크를 사용함으로써 발생하는 추가적인 비용에 대한 이야기이다.

저자는 이에 대해서, 워드 커닝햄(Ward Cunningham)의 기술 부채(Technical debt)를 예시로 들고 있다.

지저분한 솔루션을 선택할수록 기술 부채는 늘어난다.

워드 커닝햄의 기술 부채 관련 글 번역

워드 커닝햄의 부채 은유 설명

Ward Cunningham은 Debt Metaphor(예: TechnicalDebt)에 대해 혼란을 해소하기 위해 직접 설명한 동영상을 게시했습니다. 블로그계의 혼란을 정리하는 데 도움이 되었습니다.

http://www.youtube.com/watch?v=pqeJFYwnkjE

동영상의 녹취록은 아래에 있습니다.

(감사합니다, Ward. 우리는 당신의 영감을 주는 말들에 빚을 지고 있습니다)

기여자: JuneKim, LawrenceWang

은유

나는 조지 레이코프와 마크 존슨의 《우리가 사는 은유들》(Metaphors We Live By)을 읽은 후 은유가 우리의 사고 방식에 어떻게 영향을 미치는지에 관심을 가지게 되었습니다. 중요한 생각 중 하나는 우리가 사용하는 언어에 들어온 은유와 유사성을 통해 유추하여 추론한다는 것입니다.

부채

나는 WyCash 제품에서 우리가 수행하고 있던 리팩토링을 설명하기 위해 부채 은유를 만들었습니다. 이는 Digitalk Smalltalk으로 처음 개발된 제품이었고, 시간이 지남에 따라 애플리케이션에 대해 배운 점들을 축적하는 것이 중요했습니다. 프로그램을 우리가 원래부터 알고 있었던 것처럼 수정하고 Smalltalk에서 쉽게 할 수 있었던 것처럼 보이도록 만드는 것이 중요했습니다.

내가 상사에게 설명한 것은 금융 소프트웨어였기 때문에 "부채 은유"라는 금융 비유였습니다. 이는 우리가 프로그램을 금융 객체에 대해 우리가 당시 이해한 올바른 방식과 일치시키지 못하면 지속적으로 그 불일치로 인해 걸려 넘어질 것이고, 이는 대출의 이자를 지불하는 것과 같다고 했습니다.

속도

빌린 돈으로 인해 원래보다 더 빨리 무언가를 할 수 있지만, 그 돈을 갚기 전까지는 이자를 지불하게 됩니다. 나는 돈을 빌리는 것이 좋은 생각이라고 생각했으며, 소프트웨어를 서둘러 출시하여 경험을 얻는 것도 좋은 생각이라고 생각했습니다. 그러나 물론, 결국에는 그 경험을 반영하여 프로그램을 리팩토링함으로써 그 대출을 갚아야 한다고 생각했습니다.

부담

사람들이 소프트웨어를 서둘러 출시하고 배운 점을 프로그램에 되돌려 놓지 않는 경우가 많이 있었고, 이는 마치 돈을 빌리고 갚을 필요가 없다고 생각하는 것과 유사했습니다. 물론, 신용카드를 사용하는 경우처럼 결국 모든 수입이 이자에 사용되고 구매력이 0이 됩니다.

동일한 맥락에서, 오랜 기간 동안 프로그램을 단지 기능을 추가하는 것만으로 개발하고 이러한 기능에 대한 이해를 반영하여 재구성하지 않으면 결국 그 프로그램은 이해를 포함하지 않게 되고, 프로그램을 작업하는 모든 노력이 점점 더 오래 걸리게 됩니다. 다시 말해, 이자는 총합으로, 진행이 전혀 이루어지지 않습니다.

민첩성

많은 블로거들이 적어도 부채 은유를 설명했지만, 그것을 주로 부채의 주요 원천으로 생각하며 나중에 좋은 작업을 하기 위해 코드를 잘못 작성할 수 있다는 생각과 혼동했습니다. 나는 결코 코드를 잘못 작성하는 것을 지지하지 않지만, 현재의 문제에 대한 이해를 반영하여 코드를 작성하는 것을 지지합니다.

부분적인 이해라도 현재의 문제에 대한 이해를 반영하여 소프트웨어를 개발하고 그렇게 함으로써 나중에 리팩토링할 때 작성 당시의 생각이 명확하게 드러나 현재의 생각으로 리팩토링하기가 더 쉬워집니다. 다시 말해, 부채 은유 전체, 즉 부채를 갚을 수 있는 능력과 부채 은유를 당신의 이익을 위해 작동시키는 것은 코드를 충분히 깨끗하게 작성하여 문제를 이해하게 될 때 리팩토링할 수 있도록 하는 것에 달려 있습니다.

나는 그것이 좋은 방법론이라고 생각합니다. 이는 Extreme Programming의 핵심입니다. 부채 은유는 Extreme Programming이 작동하는 여러 가지 설명 중 하나입니다.

비디오에서 이 단어들을 복사, 배포, 전송 및 수정하는 것은 Creative Commons Attribution 3.0 라이선스 조건에 따라 자유롭게 할 수 있습니다.

마지막 수정일: 2011년 1월 22일

완벽히 이해하지 않은 채 프레임워크를 사용하는 것은, 유지보수 단계에서 여러 에러나 수정 사항에 대한 위험성을 안고 가는 것과 같다.

이는 겉으로 드러나지 않을 뿐이지 언젠가는 갚아야하는 부분이기도 하다.

그리고, 당연하게도 부채에 따른 이자도 발생한다.

간단하면서 극단적인 예시로, 프로젝트 초기에 사용하던 프레임워크를 다른 프레임워크로 교체하는 것과, 10년동안 사용하던 프레임워크를 다른 프레임워크로 교체하는 것에 드는 비용을 생각해보자.

후자는 전자에 비해서 막대한 비용을 요구한다.

기술 투자

다른 사람의 코드는 내 문제를 해결 하는데 최적의 방법이 될 수 없다.

저자는 기술 부채를 이유로 위와 같이 의견을 전달하고 있다. 동시에, 기술 투자라는 개념도 제시하고 있다.

모든 것을 다 구현하면 좋지만, 사실 이는 소프트웨어의 특성을 거스르는 것과도 같다.

개인적인 의견으로, 소프트웨어 산업이 다른 산업과 다른 가장 큰 요소는 복제가 가능하다라는 점이다.

단순 CTRL+C / CTRL+V로 어떤 파일이나 소프트웨어든 복사할 수 있지 않은가?

이는 다시 말하면, 재사용 가능하다라는 특징을 내포하고 있음을 의미하기도 한다.

집을 매매할 때, 사업을 할 때 대출을 받기도 하는 것처럼, 기술 부채는 반드시 나쁜 것 만은 아니다.

부채를 적절하게 관리할 수 있다면 오히려 이는 투자가 되기도 한다.

결론 : 중요하게 바라봐야 하는 것

기술 부채와 기술 투자라는 관점은 프레임워크를 도입할 때 비용의 관점에서 고려해야함을 시사한다.

결국 합리적인 이유로 적합하면서 빠른 솔루션을 도입해서 문제를 해결하는 것이 핵심이라고 볼 수 있다.

리액트가 프레임워크인가? 하는 다소 엉뚱해보일 수 있는 질문을 던지고, 글에서 판단 근거를 마련한 이유도 이런 관점에서의 접근이었다.

그리고 나아가서, 보다 명확한 판단의 근거를 내리기 위해서 라이브러리/프레임워크의 소스코드를 살펴보고, 때에 따라서는 직접 구현을 시도하게 되었다.

도구를 잘 다루는 것도 물론 중요하지만, 이 도구에 매몰되지 않고, 지금 내 문제에 맞는지 적절한 판단 근거과, 사용법을 익히기 위해서라도 본질적인 요소에 대한 학습이 필요하다고 생각한다.

본 글이 다른 개발자에게도 조금이나마 도움이 되었으면 한다.

글을 통해 전하고 싶은 메세지​

개요​

프레임워크와 라이브러리​

프레임워크 방식이란?​

프레임워크 방식 관점에서의 리액트​

리액트는 그러면 프레임워크인가?​

기술 부채​

은유​

부채​

속도​

부담​

민첩성​

기술 투자​

결론 : 중요하게 바라봐야 하는 것​