1회차

• 영감을 받은
  • 염려하는 과 같은 사건으로 뽑았음
  • 사내 DS 개발중인데 내일로써 회고의 시간을 가진다. (그동안의 개발에 대해)
  • panda CSS를 알고는 있었는데 1버전도 아니어서 냅두고 있다가 어떤 툴을 사용할지 고민하다가 번들링, CSS-in-js 방식의 장단점을 고민하다가 수림이 panda css 추천해줘서 봤는데 너무 좋았다
  • 새로운 방법으로 스타일링에 추천해준다
    • 왜 좋은가?
      • 현재 css-in-js 방식이 반감을 내비치고 있다. 근데 SSR 이슈도 있고 렌더링이 되어야 돌아가는 구조여서 브라우저 성능 저하, 번들링 크기가 애로 사항이 되는데 panda css는 빌드 타임때 css를 만들어줘서 런타임때 돌아가지 않아서 이 부분 장점인 것 같다
      • 공식 문서 너무 친절해요
      • vanilla extract랑 고민했었다
      • tsup (opens in a new tab)
• 염려하는
  • 내일 DS를 평가 받아서 염려하는 기분이 든다
    • 3주 작업에 대한 평가

• 놀란
  • 생각보다 충일님과 인연이 겹치는 게 많고, 발이 넓다. 세상이 좁다.
• 만족스러운
  • 이론 정리해주신 걸 봤는데, 다들 너무 열심히 정리해주셔서 스터디에 만족감이 높다.

• 격분한
  • 이번주가 상당히 격분이다. 3주째 야근하고 주말 출근하고 있다.(ㅠ)
  • FE 리더분이 이해를 못하시는 것 같다. 필요없는 리소스를 스스로 넣는 것 같다
  • 공유를 안해서 그런 것 같기도 해서 공유를 좀 자주 드려야겠다라는 생각중
  • 동료분들은 그래도 다들 아시는 것 같아서 위로로 들어서 동료들 믿고 간다!
• 편안한
  • 프로젝트가 내 눈 안에 들어오는 느낌이라 편안하다

• 피곤한
  • 술을 거하게 마셨다. 나는 애주가이다. 피곤하지만 그렇지만 계속 마셨다. 술마시면 집가기 싫다.
  • 신논현 새벽 2시 소주 6병, 만취, 사망
• 집중하는
  • 성과를 내야하니까

• 재미있는
  • 프레임워크도 도입하면 오버엔지니어링인지 고민해보는 재미
    • 결론이 나지는 않았지만 오버엔지니어링이다 / 아니다로 토론했다
• 만족스러운
  • 춘식도락 돼지고기 김치찌개 너무 맛있다.
  • 계란말이도 맛있다.
  • 밀키스는 안 먹었다.

• 좋았던 부분
  • Ch1 쏙쏙 들어오는 함수형 코딩에 오신 것을 환영합니다.
    • 함수형 프로그래밍을 어렵게만 다가가지 말라고 다독이는 느낌이 따뜻했다.
    • 계산과 액션, 그리고 데이터로 나누어서 실제 예시로 설명해서 이해가 잘 되었다.
  • Ch2 현실에서의 함수형 사고
    • 타임라인 다이어그램으로 시각화해서 설명을 해준 부분이 이해가 잘 되어서 좋았다.
    • 요점 정리와 결론을 정리해주는 부분이 이제까지 배운 내용을 다시 상기할 수 있어서 좋았다.
  • Ch3 액션과 계산, 데이터의 차이를 알기
    • 계산은 때로 ‘우리 머릿속에서’ 일어납니다. 라는 부분이 와닿았다.
    • 계산으로 더이상 분류할 게 없다고 생각한 내용도 사실은 우리 머리속에서 이미 계산이 이루어지기 때문에 계산으로 생각하지 못하는 경우가 많다는 예시였다.
    • 액션이 코드 전체로 퍼질 수 있다는 내용이 와닿았다.
    • Ch1에서 말한 것처럼, 함수형 프로그래밍을 활용한다고 해서 액션을 사용하지 않는 것은 아니다.
  • Ch4 액션에서 계산 빼내기
    • 액션을 사용하되, 다른 계산들에게 영향을 주지 않게 액션에서 계산을 분리하고, 액션을 함수의 최상단으로 끌어올리는 과정이 인상 깊었다.
    • 이를 통해 분리된 계산들은 테스트하기 쉬웠고, 재사용성이 높아졌다.
• 논의하고 싶은 부분

  • FE에서는 API 통신을 하는 경우가 너무 많은데, 이 책에서 제시하는 방법처럼 액션을(API 통신) 최상단으로 올리는 게 가능할까?

    1. 자식 컴포넌트들이 계산이 되기 위해 최상단에서 통신을 한 번만 하고 응답 값을 명시적 입력인 props로 전달한다고 하면, props drilling 을 피할 수 있을까?
    2. props drilling 을 피하기 위해 전역 상태 관리 툴을 도입하게 되면, 그것은 계산이자 순수함수가 되었다고 말할 수 있을까?
    3. 최상단에서 서버 통신을 하다가 장애가 발생하면, 서버 상태가 필요하지 않은 자식 컴포넌트들도 영향이 갈텐데, 서버 상태가 필요한 자식 하나만 장애가 발생하는 게 낫지 않나?

    결국엔 서버 상태가 필요한 컴포넌트는 액션이 되는 것을 피할 수 없는 것일까

    MUT figma1 (opens in a new tab)

    MUT figma2 (opens in a new tab)

    MUT figma3 (opens in a new tab)

좋았던 부분

함수형 프로그래밍의 효과 (옮긴이 머리말)

• 불변 데이터 구조를 사용하면서 변경 가능한 상태로 인한 버그가 생기지 않아서 좋았다
• 부수 효과가 있는 함수를 분리하자 테스트하기 좋은 코드가 되었다

부수 효과에 대한 생각 (옮긴이 머리말)

• 부수 효과를 처리한다는 것은 없앨 수 있는 부수 효과는 없애고 필요한 부수 효과는 잘 두는 것

불변형 데이터 구조를 사용하면 전역 변수를 읽고 쓰는 것과 같은 부수 효과가 없습니다. 하지만 입출력과 같은
부수 효과는 여전히 남아있습니다.
 
하스켈 개발자가 아닌 사람들은 하스켈과 같은 순수 함수형 언어는 부수 효과마저 순수한 함수로 표현하기 때문에
부수 효과가 없다고 오해하기도 합니다.
 
**하지만 부수 효과를 단지 미루는 것뿐이고 결국 부수 효과는 발생합니다.
 
부수 효과가 없는 소프트웨어는 의미가 없기 때문입니다.**

프로그래밍 스타일의 변화 (추천사)

• 구조적 프로그래밍 흐름 제어 구조
  • 흐름 제어를 단순한 패턴으로 만든다
  • 중첩할 수 있는 블록으로 순차적으로 실행되는 구문을 나눌 수 있다
• 객체 지향 프로그래밍 데이터 접근 구조
  • 모든 변수가 어떤 구조에 캡슐화 되거나 포함된다는 것
    • 코드의 특정 부분에서만 변수에 접근할 수 있기 때문에 코드를 관리하고 읽기 쉬워진다.
    • 변수들의 집합이 일관된 속성을 따르게 할 수 있다
  • 상속, 상속도 캡슐화가 있기에 가능하다
• 함수형 프로그래밍 부수 효과 구성
  • 부수 효과를 잘 관리해서 코드의 아무 곳에나 있지 않도록 하는 것
  • 계산과 액션을 구분하는 것
  • 배열, 리스트, 데이터베이스와 같은 컬렉션을 하나씩 처리하지 않고 ‘한 번에’ 처리한다는 개념
    • ‘한 번에’ 처리하기 위해서는 컬렉션 항목에 외부에 영향을 주는 부수 효과가 없어야 한다
    • 항목이 독립적일 때 가장 효과적이다
      • 이 개념은 계산과 액션의 구분이 있어야 동작하는 개념이다.

부수 효과 (p.2)

• 함수가 리턴값 이외에 하는 모든 일 (Ex. 메일 보내기, 전역 상태 수정하기)

순수 함수(p.2)

• 인자에만 의존하고 부수 효과가 없는 함수

  인자에만 의존 : 같은 인자를 넣으면 항상 같은 결과를 돌려준다

액션, 계산과 데이터 (p.10)

함수형 프로그래머는 액션보다 계산을 좋아하고 계산보다 데이터를 좋아합니다.

• 액션 (부수 효과)
  • 호출 시점이나 횟수 또는 둘 다에 의존
    • 시간이 지남에 따라 안전하게 상태를 바꿀 수 있는 방법
    • 순서를 보장하는 방법
    • 액션이 정확히 한 번만 실행되게 보장하는 방법
• 계산 (순수 함수)
  • 입력값으로 출력값을 계산하여 만드는 것
  • 어떤 것을 결정하거나 계획하는 것
  • 같은 입력값 → 계산 → 같은 결괏값
  • 외부에 영향을 주지 않는다
  • 계산을 호출하는 코드를 계산 결과로 바꿀 수 있기 때문에 참조 투명함
    • 코드의 결과는 항상 같기 때문에 여러 번 불러도 문제가 없다
  • 테스트하기 쉽고 언제든지 몇 번을 불러도 안전하다
    • 정확성을 위한 정적 분석
    • 소프트웨어에서 쓸 수 있는 수학적 지식
    • 테스트 전략
• 데이터
  • 이벤트에 대해 기록한 사실
  • 실행하는 코드만큼 복잡하지 않기 때문에 다른 것과 구분됨
    • 효율적으로 접근하기 위해 데이터를 구성하는 방법
    • 데이터를 보관하기 위한 기술
    • 데이터를 이용해 중요한 것을 발견하는 원칙

액션보다 계산이 좋은 이유 (p.53)

• 테스트하기 쉽다
• 기계적인 분석이 쉽다
• 조합하기 좋다

함수형 사고 (p.13)

• 함수형 프로그래머가 소프트웨어 문제를 해결하기 위해 사용하는 기술과 생각
  • 액션과 계산, 데이터를 구분해서 생각하는 것
  • 일급 추상

계층형 설계 (p.20)

• 각 계층은 그 아래에 있는 계층을 기반으로 만들어진다.
  • 각 계층에 있는 코드는 더 안정적인 기반 위에 작성할 수 있다. ⇒ 이런 구조로 소프트웨어를 만들면 코드 쉽게 변경 가능
    • 가장 위에 있는 코드는 의존성이 거의 없기 때문에 쉽게 변경 가능
    • 아래에 있는 코드들은 위에 있는 코드보다 의존성이 많아 바꾸기 어렵지만 자주 바뀌지 않음
• 계층형 설계는 일반적으로 비즈니스 규칙, 도메인 규칙, 기술 스택 계층
  • 계층형 설계로 만든 코드는 테스트, 재사용, 유지보수가 쉽다

함수형 사고를 적용할 때 신경써야 하는 부분 (p.32)

• 문제에 대해 생각할 때
  • 특별히 주의해야할 부분(액션)
  • 데이터로 처리해야 할 부분
  • 결정을 내려야 하는 부분(계산)
• 코딩할 때
  • 최대한 액션에서 계산을 빼내려 해보기
  • 계산에서는 데이터를 분리할 수 있는지 생각 해보기
  • 액션이 계산이 될 수 있는지, 계산은 데이터가 될 수 있는지 고민해보기

액션은 코드 전체로 퍼져나간다 (p.55)

액션을 쓰는 순간 코드 전체로 퍼져나가기 때문에 사용할 때 조심해야 한다.

• 액션을 추출
• 함수 안에서 액션을 호출하고 있으면 함수 전체가 액션이다 ⇒ 작은 코드 하나가 전체 프로그램을 액션으로 만든다

자바스크립트에서 발생할 수 있는 액션 (p.57)

• 함수 호출

  alert('hello world!')

• 메서드 호출

  console.log('hello')

• 생성자

  new Date()

• 표현식

  // 변수 참조 : y가 공유되고 변경 가능한 변수인 경우, 읽는 시점에 따라 값이 다를 수 있다
  y
  // 속성 참조 : user가 공유되고 변경 가능한 객체라면 firstName은 읽는 시점에 따라 값이 다를 수 있다
  user.firstName
  // 배열 참조 : stack이 공유되고 변경 가능한 배열이라면 읽는 시점에 따라 값이 다를 수 있다
  stack[0]
   

• 상태

  // 값 할당 : 공유를 위해 값을 할당했고 변경 가능한 변수인 경우, 다른 코드에 영향을 줌
  z = 3
  // 속성 삭제
  delete user.firstName

함수에는 입력과 출력이 있다 (p.68)

• 입력
  • 함수가 계산을 하기 위한 외부 정보
    • 정보는 입력을 통해 함수 안으로 들어간다
• 출력
  • 함수 밖으로 나오는 정보나 어떤 동작
    • 정보나 어떤 효과는 출력으로 함수 밖으로 나온다
• 함수를 부르는 이유
  • 결과를 얻기 위해서
    • 결과를 얻으려면 입력이 필요하다

입력과 출력은 명시적이거나 암묵적일 수 있다 (p.68)

• 명시적 입력
  • 인자
• 명시적 출력
  • 리턴값
• 암묵적 입력 (부수효과)
  • 함수를 부르는 동안 결과에 영향을 줄 수 있는 것 - 인자 외 다른 입력
    • 전역 변수를 읽는 것
    • DOM 요소를 읽는 것
• 암묵적 출력 (부수효과)
  • 함수 호출의 결과로 영향을 받는 것 - 리턴값 외 다른 출력
    • DOM 요소를 변경하는 것
    • 전역 변수를 변경하는 것

함수에 암묵적 입력과 출력이 있으면 액션이 된다 (p.68)

• 함수에서 암묵적 입력과 출력을 없애면 계산이 된다
  • 암묵적 입력 → 함수의 인자
  • 암묵적 출력 → 리턴값

계산 추출 단계 (p.78)

• 계산 코드를 찾아 빼내기 (서브 루틴 추출)
  • 코드를 추출해 새로운 함수를 만들어 리팩터링
  • 새 함수에 인자가 필요하다면 추가
  • 원래 코드에서 빼낸 부분에 새 함수를 부르도록 변경
• 새 함수에 암묵적 입력과 출력 찾기
• 암묵적 입력은 인자로 암묵적 출력은 리턴값으로 변경하기
  • 한 번에 하나씩 입력 → 인자 , 출력 → 리턴값으로 변경

논의하고 싶은 부분

소프트웨어 설계 원칙 (p.12)

규모가 큰 소프트웨어를 만들 때는 설계 원칙 같은 것이 필요합니다.

• 본인만의 설계 원칙이 있는지? 최근에는 어떤 설계를 했는지?

기존에 있던 코드에 함수형 사고를 적용한 경험 (p.12)

자바스크립트는 왜 함수형 프로그래밍을 하기 좋은 언어가 아닐까? (p.13)

자바스크립트는 함수형 프로그래밍을 하기 좋은 언어는 아니지만 함수형 프로그래밍을 하기에 부족하기 때문에
함수형 프로그래밍을 가르치기 좋은 언어입니다.
 
왜냐하면 부족한 기능으로 인해 그 문제를 어떻게 해결할지 생각해봐야 하기 때문입니다.

• 어떤 점이 부족하다고 이야기하는걸까?

액션은 코드 전체로 퍼져나간다 (p.55)

• react-hook-form을 사용하면서 나름 계산과 액션을 분리한다고 했는데 위 말에서 번개 쳤다
  • 사실은 액션을 호출하는 쪽도 액션
• react-hook-form 혹은 unControlled form에서 액션을 어떻게 관리하는 게 좋을까?

  • 난 증오해..

     
    A
    ㄴ B
      ㄴ C
        ㄴ D (여기에 Input이 있을 때...어떻게 관리하는 게 좋을까?.?)
     
    const Parent = () => {
      const { register } = useForm({
        defaultValues: async () => {
          return fetch('https://example.com/...')
        }
      })
    }
     
    const Nested = () => {
      const { register } = useFormContext<FormType>()
     
      return <input {...register('name')}
    }

실습 문제 아이디어 스토밍

• 스파게티 코드 보고 액션, 계산, 데이터 구분해보기?
• “JS에는 배열을 직접 복사하는 방법이 없습니다. (p.75)” 배열을 직접 복사하는 메서드 만들어보기

• 좋았던 부분
  • 액션, 계산, 데이터로 나누어 어떠한 방향으로 함수를 분리해가야 할지 고민해볼 수 있어서 좋았다.
• 논의하고 싶은 부분

  • 민수 댓글: 2.props drilling 을 피하기 위해 전역 상태 관리 툴을 도입하게 되면, 그것은 계산이자 순수함수가 되었다고 말할 수 있을까?

    import { connect } from 'react-redux'
     
    // 이건 순수! 재사용 쉬움
    const TodoList = ({ todos }) => {
      return ...
    }
     
    // 이건 상태랑 연결
    const ConnectedComp = connect(state => ({ todos: state.todos }))(TodoList)
     
    const App = () => {
      return <>
        {/* 독립적으로 사용가능 */}
        <TodoList todos={[{
          ...
        }]} />
      </>
    }

  • 그럼 react-query에서 훅으로 내부에서 외부에 암묵적 입력이 아니라 명시적 입력이면 어떨까?

    import { useQuery } from '@tanstack/react-query'
     
    // 이건 순수! 재사용 쉬움
    const TodoList = ({ todos }) => {
      return ...
    }
     
    const connectQuery = (queryOptions, mapQueryToProps) => {
      return ({
        fulfilled: Fulfilled,
        pending: Pending
      }) => {
        const query = useQuery(queryOptions)
        if(query.isLoading) {
          return (<Pending />)
        }
     
        // ...생략...
     
        return (<Component {...mapQueryToProps(query)} />)
      }
    }
     
    const QueryConnected = connectQuery({
        queryKey: ['...'],
        queryFn: fetchTodos
      },
      (query) => ({ todos: query.data }))
    ({
      fulfilled: TodoList
      pending: Spinner
    })
     
    const Example1 = () => {
    jljljljljk
     
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
    dflkdsjflksjflkdsjf
     
      return (
        <ErrorBoundary fallback={(caught) => <>{caught.error.message}<>}>
          <Suspense fallback={<Spinner/>}>
            <Query
              options={{
                key: [],
                fn: fetchTodos,
                suspense: true,
              }}
            >
              {(queryOnSuccess) => <TodoList todos={queryOnSuccess.data} />} /* 이렇게 하면 재사용 가능?? */
            </Query>
            <SuspenseQuery
              options={{
                queryKey: [],
                queryFn: fetchTodos,
              }}
            >
              {(queryOnSuccess) => queryOnSuccess.data.map((todo) => <TodoItem todo={todo}/>)} /* 이렇게 하면 재사용 가능?? */
            </SuspenseQuery>
          </Suspense>
        </ErrorBoundary>
      )
    }
     
    const Example2 = () => {
      return <TodoList todos={[]} /> // 이렇게 하면 재사용 가능??
    }

• 좋았던 부분

  부수 효과 (Side Effects)에 대한 고찰

  부수 효과는 함수의 실행 과정에서 시스템의 상태를 바꾸거나, 함수 실행 이후에 영향을 미치는 일을 말해요. 함수형 프로그래밍에서는 부수 효과를 최대한 피하거나 제한하는 것을 지향한다고 합니다.

  부수 효과의 종류

  부수 효과의 형태는 어떻게 될까요?

  1. 전역 변수나 데이터 구조를 변경: 함수 내부에서 전역 변수나 데이터 구조를 직접 변경하는 것은 부수 효과. → 함수의 순수성이 깨지고 동일한 입력에 대해 동일한 출력을 보장할 수 없게 된다.
  2. I/O 작업: 파일을 읽거나 쓰는 작업, 네트워크 통신 등의 I/O 작업도 부수 효과. → 이런 작업을 통해 시스템의 상태가 변경되거나 함수 실행 외부에 영향을 미치게 된다.
  3. 데이터베이스나 상태를 가진 저장소와의 통신: 데이터베이스에 저장하거나 가져오는 작업, 쿠키나 세션 저장소와의 통신 등이 이에 해당한다.

  부수 효과를 어떻게 관리하면 좋을까..?

  책에서 부수 효과를 관리하는 것은 없앨 수 있는 부수 효과는 없애고 필요한 부수 효과는 잘 관리하는 것을 의미한다고 해요. 예를 들어, 함수형 프로그래밍에서는 불변 데이터 구조를 사용하여 변경 가능한 상태로 인한 부수 효과를 제거합니다. 하지만 I/O와 같은 필요한 부수 효과는 아예 없앨 수 없으므로, 이를 잘 관리해야 해야하는데 어떻게하면 잘 관리할 수 있을까?? 이를 위해 일부 순수 함수형 언어들은 부수 효과를 순수한 함수로 표현하는 방법을 제공해요. 하지만 이것은 부수 효과를 완전히 없애는 것이 아니라, 발생하는 부수 효과를 순차적으로 관리하거나 실행 순서를 명시적으로 표현하는 것을 의미해요.

  그렇다면 부수 효과와 함수형 프로그래밍을 어떻게 엮어볼 수 있을까?

  함수형 프로그래밍은 부수 효과를 최소화하려는 노력이 핵심이라고 생각했어요. 함수가 순수해 질수록 그 함수를 이용해서 프로그램을 이해하고, 테스트하고, 다시 사용하기가 더 쉬워진다고 생각해서 입니다. 따라서 부수 효과를 일으키는 작업은 최대한 분리하고 제어하는 것이 좋을 것 같습니다.

  함수의 암묵적 입력과 출력? 액션과 계산의 분리는?

  함수형 프로그래밍에서는 함수의 순수성, 즉 입력에 대한 출력이 일관되게 유지되는 특성을 중요하게 생각한다고 해요. 함수의 암묵적 입력과 출력을 명시적으로 처리하려는 노력이 필요해요. 암묵적인 입력과 출력은 함수의 결과를 예측하기 어렵게 하고 어렵게 되면 코드의 유지보수와 테스트 또한 어려워질 것 같아요.

  암묵적 입력과 출력이 있는 함수는 액션인가?

  함수에 암묵적인 입력과 출력이 있다면 그 함수를 '액션'이라고 불러요. 이는 함수의 실행 결과가 그 함수 외부의 상태나 시간에 따라 달라질 수 있음을 의미한다고 하고, 액션은 부수 효과를 가질 수 있으며, 이로 인해 동일한 입력에 대해 항상 동일한 출력을 보장하지 않아요.

  암묵적 입력과 출력을 없애는 방법은 계산인가?

  함수에서 암묵적 입력과 출력을 없애면 그 함수는 '계산'이라고 불러요. 계산은 동일한 입력에 대해 항상 동일한 출력을 반환하며, 부수 효과를 가지지 않아요. 암묵적인 입력을 함수의 인자로, 암묵적인 출력을 함수의 리턴값으로 변경하고 이로 인해서 함수의 행동이 명확해지고 테스트와 재사용이 수월해져요.

• 논의하고 싶은 부분 계층형 설계의 적용 가능성이 있을까? 각 계층을 구성하는 요소를 어떤식으로 식별하고 그것을 기반으로 코드를 어떤식으로 재구조화하는지 → 그렇다면 테스트 전략은 어떻게 가져갈 수 있을까? 각 계층을 어떻게 독립적으로 테스트할 수 있을지

• 좋았던 부분

  • 다른 곳에서 쓰지 않아도, 계산으로 분리하는게 좋다고 한 것이 좋았다. 코드에서 ‘이것까지 함수로 분리해야할까?’에 대해 고민할 수 있는데, ‘이렇게 까지 나눠도 된다’고 생각할 수 있는 근거를 알려주었다.
  • 데이터, 계산, 액션으로 나누어서 코드를 더 잘게 쪼개서 리팩토링하는 부분을 예제로 볼 수 있어서 좋았다.

• 논의하고 싶은 부분

  내부함수(함수 안에 함수가 있는 형태)에서도 내부함수 밖에 있는 변수나 함수를 호출하는 것은 암시적 입출력이라고 할 수 있을까?

  만약 그렇다면, 내부 함수는 언제 쓰는 것이 올바르다고 할 수 있을까?

  const getUniqueIdBuilder = () => {
    let id = 0
   
    return () => ++id
  }
   
  // () => ++id 부분을 추출할 필요가 있을까?
  // 오히려 헷갈리지 않을까
  // 불필요한 함수 선언이 매번 선언되진 않을까?

  

  const getText = (status, isEdit) => {
    switch(status) {
      ....
    }
  }
   
  const getColor = (status) => {
   
  }
   
  const getProps = () => {
    return {color, text, onClick}
  }
   
  const Comp = (isEdit) => {
   
      const props = getProps(status)
   
      return <button color={props.color}>
        {props.text}
      </button>
  }
   
  const Comp = (isEdit) => {
   
  <button css={[
          variantStyle(variant),
          disabled ? disabledStyle(disabled) : null,
   
          customStyle,
        ]} />
   
      return <>
        {tabType === '배달' && <>
        {status === 'PAUSED' && <button>일시정지</button>}
        {status === 'ON' && <button>살아있다</button>}
        {status === 'OFF' && <div>텍스트만 있다</div>}
        {status === 'TEMP' && <button>임시 되어있다.</button>}
        </>}
        {tabType === '익스프레스' && <>
        {status === 'PAUSED' && <button>일시정지</button>}
        {status === 'ON' && <button>살아있다</button>}
        {status === 'OFF' && <div>텍스트만 있다
          <button>살아있다</button>
        </div>}
        {status === 'TEMP' && <button>임시 되어있다.</button>}
        </>}
      </>
  }