Yeon’s Dev Log

리액트에서 컴포넌트를 작성하는 기준 (Feat. SOLID원칙)

Dev.yeon — Thu, 25 Jan 2024 18:53:00 +0900

리액트를 개발할때 컴포넌트를 어떤 기준으로 작성하시나요? SOLID원칙을 통해 어떻게 컴포넌트를 작성할지에 대해서 살펴보도록하겠습니다. 본격적으로 시작하기전에 리액트 가이드문서에서 계층을 분리하는 과정을 먼저 보고가겠습니다.

리액트 계층분리과정

https://react.dev/learn/thinking-in-react 글을 요약하였습니다. 실제예시가 본문에 잘나와있으므로 참고하시기바랍니다.

1. UI를 컴포넌트 계층으로 쪼개기

컴포넌트를 하위 컴포넌트들로 쪼개야하는데 나누는 관점에는 차이가 있을수있습니다. 이미 디자인팀에서 정해놓은 계층이 있다면 그것을 기준으로 분리해도되고, 개발관점에서는 SRP원칙에따라 분리를 할수도있습니다. JSON이 잘구조화되어있다면, 응답값을 기준으로 컴포넌트 구조를 분리해볼수도있습니다. UI와 데이터는 같은 구조를 가지기때문입니다.

2. 정적인 버전 구현하기

컴포넌트 계층구조를 만들었다면, 실제로 리액트에서 개발을 해야합니다. 처음에는 상호작용기능은 추가하지않되, UI를 렌더링하는 버전을 먼저 만드는게 좋습니다. 재사용성을 고려해서 개발하게된다면 props를 이용하여 데이터를 넘겨주는 컴포넌트를 구현하게될것입니다. 이때 정적인 버전이기때문에 state는 고려하지않는것이 좋습니다. state는 시간이 지남에따라 데이터가 바뀌는것에 사용하기때문입니다. 계층구조에따라 상층부에 있는 컴포넌트부터 하양식(top-down)으로 만들거나, 하층부에있는 컴포넌트부터 상향식(bottom-up)으로 만들수있지만 프로젝트가 클수록 탑다운방식이 더 좋습니다.

3. 최소한의 데이터만 이용해서 완벽하게 UI State 표현하기

UI를 상호작용하기위헤서는 이제 state를 활용해야합니다. state를 구조화하는데 가장 중요한원칙은 DRY(Don't Repeat Yourself) 입니다. 가장 최소한의 state만을 가지게하고, 나머지는 필요에따라 실시간으로 계산하는게 좋습니다. 시간이 지나면서 변하지않거나, 부모로부터 props를 통해 전달되거나, 컴포넌트안의 다른 값을 이용해서 계산이 가능하다면 state가 아닙니다.

4. state가 어디에있어야하는지 정하기

state를 구조화했다면 어떤 컴포넌트가 이 state를 소유하고 변경할 책임을 지게할지 정해야합니다. 리액트애서는 항상 컴포넌트 게층을 따라 부모에서 자식으로 데이터를 전달하는 단방향 데이터 흐름을 사용한다는것을 기억하면 조금더 쉽게 정할수있습니다. state를 기반으로 렌더링하는 모든 컴포넌트를 찾은다음, 가장 가까운 공통되는 부모컴포넌트에 state를 두면됩니다.

5. 역데이터 흐름 추가하기

계층구조 아래로 흐르는 props와 state를 구성했다면, 반대로 사용자의 입력을 상위로 전달하는 역데이터흐름을 추가해야합니다. 이때에는 이벤트핸들러를 추가하여 state를 변경하도록 구현합니다.

아마도 실제 프로젝트를 진행하실때도 리액트에서 소개하고있는 계층분리과정순으로 개발을 많이 하실것이라고 생각됩니다. 1, 2번에서 소개하고있는 컴포넌트를 쪼개고 실제 구현을 할때 컴포넌트 어떻게 구분할지에 대한 기준이 없다면 개발할때 상당히 난처할수있습니다. 개발을 진행하면서도 이 컴포넌트를 분리할지 합쳐서 작성할지에대해 고민하게되고, 그러다보면 프로젝트구조가 통일성없이 설계될수있습니다. 또한 개발후에 변경건이 발생하게되거나, 확장하게될경우 공수가 크게들수도있습니다. 따라서 실제 개발전에 팀원들과 컴포넌트를 나누는 기준을 정하고간다면, 리뷰할때나 유지보수할때에 편리할것입니다.

SOLID 원칙

SOLID원칙은 아키텍처 설계부터 코딩과 리뷰까지 사용되는 원칙입니다. 이 원칙을 하나하나 살펴보며, 리액트에서 컴포넌트를 작성할때 어떻게 작성하면 좋을까?에 대해서 탐구해보도록하겠습니다.

https://fe-developers.kakaoent.com/2023/230330-frontend-solid/ 글을 참고하였습니다. 보다 자세하게 알고싶은분들은 원글을 꼭 읽어보시기바랍니다.

SRP: Single Responsibility Principle
OCP: Open/Closed Principle
LSP: Liskov Substitution Principle
ISP: Interface Segregation Principle
DIP: Dependency Inversion Principle

1. SRP(Single Responsibility Principle)

SRP를 먼저논하기전에 콘웨이법칙을 알고가면좋습니다. 콘웨이법칙은 소프트웨어구조는 해당 소프트웨어를 개발한 조직의 커뮤니케이션 구조를 닮게된다 라는 법칙입니다. 즉 이말은 소프트웨어구조가 조직의 커뮤니케이션 구조와 다르다면 잘못된 구조이다 라는뜻을 내포하고있습니다. 코드를 변경해야하는 요구사항도 조직에서 비롯되기때문에, 이상적인 컴포넌트 구조는 변경된 요구사항이 전달되었을때 최대한 side-effect없이 원하는 부분만 변경할수있는 구조가 좋습니다. 응집도는 높고, 결합도는 낮은 구조로 구성해야한다는 뜻입니다.

SRP를 직역하면 단일책임원칙입니다. 하지만 개발관점에서 "책임"을 "동작"으로 해석하게되면 컴포넌트를 과하게 쪼갤수있습니다. 이렇게되면 전체로직을 한눈에 파악하기어렵고 코드 네이게이션에 들어가는 공수를 늘어나게 만듭니다. 관점을 다르게하여 R을 책임이 아닌 책무라고 이해해보면, R은 소프트웨어 내부의 동작이나 논리가 아니라 조직간 커뮤니케이션 영역으로 볼수있습니다.

즉, 책무기반 컴포넌트 설계라고 볼수있습니다. 프로젝트별로 기획이나 디자인부서가 있을것이고, 요구사항이 있을것입니다. 컴포넌트 설계를 '요구사항을 전달하는 책무단위'로 진행하게되면, 변경에도 사이드이펙트없이 대처가 가능하며 커뮤니케이션 비용이 줄어들게됩니다. 실제업무에 대입해서 생각해본다면 다음과같이 원칙을 세울수있을것입니다.

기획에서 구조화된 그대로 컴포넌트를 설계하고, 네이밍또한 별도의 변환없이 그대로 사용한다.
디자인시스템이 구축되어있다면 아토믹 디자인을 차용하여 그대로 사용한다.
- https://fe-developers.kakaoent.com/2022/220505-how-page-part-use-atomic-design-system/
- 아토믹디자인: 컴포넌트를 atom, molecule, organism, template, page의 5가지 레벨로 나누어 생각하는 디자인시스템
- 아토믹디자인에서의 SRP를 생각해본다면, molecule단계를 잘 설계해야합니다. molecule은 쪼갤수없는 atom으로 구성되어 SRP에 따라 한가지의 책무를 지는것입니다.
- molecule과 organism을 구분은, 작성한 컴포넌트에 컨텍스트가 있을경우에는 Organism으로, 컨텍스트없이 UI적인 요소라면 molecule로 한다.
범용적인 컴포넌트를 구성할때는 특정 도메인과의 결합도를 낮추고 재사용성을 높이는것이 중요하며, 너무나 많은 역할을 수행하지 않도록 주의한다.
- https://fe-developers.kakaoent.com/2022/221020-component-abstraction/
- 범용적인 컴포넌트에서 특정도메인과 높은 의존성은 변경에 취약한 코드를 낳게되기때문에, 공통의 기능을 수행하게끔 구성해야한다.
- 도메인과의 의존성과 별개로 컴포넌트자체가 수행하는 책임이 크다면 합성을 잘 이용해야한다. 하나의 컴포넌트가 가진 책임을 잘게 나누어 유연하게 대응할수있도록 한다.

실무에서 다음과같은 원칙을 정해놓고 개발을 하게된다면 굉장히 용이할것입니다. 정리하자면, 컴포넌트에는 SRP에 따라 단일책임을 부여하고, 특정도메인과의 결합도는 낮추자라고 볼수있습니다.

2. OCP(Open/Closed Principle)

OCP는 요구사항이 변경될때 기존코드를 변경하는것이아니라 새롭게 코드를 추가하는 원칙입니다. 개방폐쇄원칙은 객체는 확장에 개방되어있고, 변경에는 폐쇄되어있어야한다는 뜻을 내포합니다. 기획은 계속해서 변경되고, 새로운 스펙들이 추가되는 상황에서 닫혀있는 구조를 사용한다면 코드구조가 많이 변경되게됩니다. https://www.octobot.io/blog/solid-principles-react/ 에 작성된 코드예시를 보겠습니다.

const RecipeCard = ({id, name, ingredients, type, onClick}) => {
   return (
       <Card>
           <CardHeader>
               <CardTitle>{name}</CardTitle>
           </CardHeader>
           <CardBody>
               <p>Id: {id}</p>
               <IngredientsFields>
                   {ingredients.map((ingredient) => {
                       <Ingredient>{ingredient}</Ingredient>
                   })}
               </IngredientsFields>
               {type === 'byAuthor' &&
                   <button onClick={onClick}>Go to site</button>
               }
               {type === 'byUs' &&
                   <button onClick={onClick}>Go to cook steps</button>
               }
           </CardBody>
       </Card>
   )
}

RecipeCard 컴포넌트는 type에 따라 다른 버튼을 렌더링합니다. 새로운 type을 추가하려면 컴포넌트를 수동으로 수정해야하므로 변경이 일어날수밖에 없습니다. 기존코드를 변경해야하기때문에 앞서 언급한 원칙에 위배됩니다. 따라서 다음과 같이 코드를 작성하는것이 좋습니다.

// parent
const RecipeCard = ({id, name, ingredients}) => {
   return (
       <Card>
           <CardHeader>
               <CardTitle>{name}</CardTitle>
           </CardHeader>
           <CardBody>
               <p>Id: {id}</p>
               <IngredientsFields>
                   {ingredients.map((ingredient) => {
                       <Ingredient>{ingredient}</Ingredient>
                   })}
               </IngredientsFields>
               {children}
           </CardBody>
       </Card>
   )
}


// children
const AuthorRecipeCard = ({id, name, ingredients, onClick}) => {
   return (
       <RecipeCard id={id} name={name} ingredients={ingredients}>
           <button onClick={onClick}>Go to site</button>
       </RecipeCard>
   )
}

const OwnRecipeCard = ({id, name, ingredients, onClick}) => {
   return (
       <RecipeCard id={id} name={name} ingredients={ingredients}>
           <button onClick={onClick}>Go to cook steps</button>
       </RecipeCard>
   )
}

아이디, 이름, 재료와같이 공통적인 부분은 유지를 하되, type별로 나눠지는 부분은 특정컴포넌트를 만들어서 children으로 렌더링하게됩니다. 새로운 type이 추가되더라도 새 컴포넌트를 추가하고 children으로 전달하면되기때문에 확장성이 높아졌습니다. 즉, 확장에 개방되어있고, 변경에는 폐쇄되어있는 원칙을 잘 지켰다고 볼수있습니다. 또한, 앞서 설명한 SRP에서 특정도메인과의 결합도를 낮추는것과도 부합한다고 볼수있습니다.

3. LSP(Liskov Substitution Principle)

LSP는 리스코프 치환법칙입니다. 주로 객체지향언어에서 아용되는 원칙이기때문에 보통 "클래스 A가 클래스 B의 하위유형인 경우, 프로그램에서 오류를 일으키지않고 클래스 B의 객체를 클래스 A의 객체로 대체해야한다" 라고 설명합니다. 자식부모관계는 클래스 상속을 통해 설정되지만, 더 넓은 맥락에서 상속이란 비슷한 구현을 유지하면서 한 객체를 다른객체 위에 구축하는것을 의미합니다. https://www.octobot.io/blog/solid-principles-react/ 에 작성된 코드예시를 보겠습니다.

const RecipeCard = ({children, color, size}) => {
   return (
       <Card style={{color, fontSize: size === 'xl' ? '32px' : '16px'}}>
           {children}
       </Card>
   )
}

위의 코드는 자식컴포넌트, 색상, 크기를 props로 받는 RecipeCard component입니다. 여기에 나중에 다크모드가 기획상 추가되어서 새로운 DarkRecipeCard 컴포넌트를 만들어야한다고 가정해보겠습니다.

const DarkRecipeCard = ({children, isBig}) => {
   return (
       <RecipeCard color='dark' size={isBig ? 'xl' : 'tb'}>
           {children}
       </RecipeCard>
   )
}

이 코드는 언뜻보면 문제가 없어보입니다. 렌더링할때도 제대로 동작하는것을 볼수있습니다. 하지만 리스코프 치환법칙을 준수하지는 않습니다. 왜냐하면 DarkRecipeCard를 다른 레시피 카드로 대체하고싶어도 상속되는 props의 동작을 수정해서 이름을 변경하였기때문에 대체하지 못하기때문입니다. 따라서 이 리스코프 치환법칙을 지키기위해서는 아래와같이 코드를 작성하는편이 좋습니다.

const DarkRecipeCard = ({children, size}) => {
   return (
       <RecipeCard color='dark' size={size}>
           {children}
       </RecipeCard>
   )
}

렌더링상 문제는 없지만 아무생각없이 개발하다보면 놓칠수 있는 부분입니다. 이 원칙을 코드레벨말고 아키텍쳐레벨 관점에서 본다면 더 넓은 의미로 적용이 가능합니다. 리스코프 치환법칙은 다시말하자면 상속으로 이어진 관계에서 예상못할 행동을 하지말라는 것입니다. 타입스크립트 인터페이스정의를 아무생각없이 상속관계로 만든다거나, `ApiErrorBoudary` 를 작성해놓고 API와 관련없는 에러처리를 한다거나 등의 위반을 저지를수있습니다. 실제로 SOLID원칙중 장애상황과 가장 밀접한 부분은 LSP이기때문에 실제개발단계에서 이원칙을 지켰나 생각하면서 개발을 하는것이 좋습니다. 상위정의된부분과 실제 구현된 부분이 다르가면 장애상황이 일어날 확률이 커지게되고, 나중에 원인을 찾기도 힙들게됩니다. 따라서 개발단계에서부터 조심해서 쓰는것이 좋습니다.

4. ISP(Interface Segregation Principle)

ISP는 인터페이스 분리원칙입니다. 어떤 코드도 "사용하지 않는 메서드/인터페이스"에 의존하도록 해서는 안된다라는 원칙입니다. 리액트에서 ISP는 컴포넌트를 작성할때 정확하고 최소한의 인터페이스를 만드는것에 대한 중요성을 강조하고있습니다. 즉, 불필요한 부피를 피하면서 특정요구에 맞는 컴포넌트 인터페이스를 설계하도록 권장하는 것입니다. 이러한 접근방식은 컴포넌트가 작아지고 집중화되어 가독성과 확장성이 개선된 모듈로 기능을 하게됩니다. https://www.octobot.io/blog/solid-principles-react/ 에 작성된 코드예시를 보겠습니다.

const RecipeCard = ({ recipeData }) => {
   return (
     <Card>
       <Title>{recipeData.name}</Title>
       <TypeLabel>{recipeData.type}</TypeLabel>
       {recipeData.ingredients.map((ingredient) =>
       (<Ingredient>{ingredient}</Ingredient>))}
       <Photo src={recipeData.img} />
     </Card>
   );
}
RecipeCard.propTypes = {
   recipeData: PropTypes.object.isRequired,

RecipeCard는 recipeData를 받아서 렌더링하는 컴포넌트입니다. 만약 recipeData에서 특정 데이터만 필요하다면 이 부분은 쪼개어 props를 받는것이 좋습니다. 컴포넌트에 불필요한 정보를 제공하는것은 컴포넌트의 클라이언트가 사용하지않는 인터페이스에 의존하도록 강요하는것이기 때문입니다. 따라서 다음과같이 코드를 수정하는것이 좋습니다.

const RecipeCard = ({ name, type, ingredients, photo }) => {
   return (
     <Card>
       <Title>{name}</Title>
       <TypeLabel>{type}</TypeLabel>
       {ingredients.map((ingredient) =>
       (<Ingredient>{ingredient}</Ingredient>))}
       <Photo src={photo} />
     </Card>
   );
}
RecipeCard.propTypes = {
   name: PropTypes.string.isRequired,
   type: PropTypes.string.isRequired,
   ingredients: PropTypes.array.isRequired,
   photo: PropTypes.string.isRequired,
};

이렇게함으로써 컴포넌트가 사용하지않는 props에 의존하지않게되었습니다. 컴포넌트간의 종속성을 최소하하고, 한 컴포넌트에서 다른 컴포넌트로 전달되는 props를 최소화하여 결합도를 낮췄습니다. 이렇게하면 코드를 유지보수할때나, 장애상황 발생시 빠르게 파악이 가능합니다.

5. DIP(Dependency Inversion Principle)

DIP는 의존성역전법칙으로 그 개념이 다소 어렵습니다. 클린아키텍처저자인 Martin, Robert C의 말씀을 빌리면 DIP는 다음과같습니다.

- 고차원모듈은 저차원 모듈에 의존하면안된다.
- 이 모듈 모두 다른 추상화된것에 의존해야한다.
- 추상화된것은 구체적인 것에 의존하면안된다. 구체적인것이 추상화된것에 의존해야한다.

이 부분을 리액트에 대입해서 생각해보자면, 상위 컴포넌트가 하위 컴포넌트에 직접적으로 의존하게 하는것이 아닌, props나 context와 같은 추상화에 의존하여 유연성과 유지보수를 강화하자는 말로 이해할수있습니다. 이렇게되면 모듈화하기에도 좋고, 테스트하기에도 쉬우며 코드유지관리가 쉬워집니다. https://fe-developers.kakaoent.com/2023/230330-frontend-solid/에 작성된 예시를 보겠습니다.

function TicketInfoContainer(){
  const { isLoading, data:ticketInfo, error } = useTicketInfoQuery();
  const { data:commentInfo, error:commentApiError } = useCommentInfoQuery();
  const { data:keywordInfo } = useKeywordInfoQuery();
  
  if(isLoading){
    return <Loading />
  }

  if(error){
    return <Error />
  }

  return (
    <TicketInfo
      waitfreePeriod={ticketInfo.waitfreePeriod}
      waitfreeChargedDate={ticketInfo.waitfreeChargedDate}
      rentalTicketCount={ticketInfo.rentalTicketCount}
      ownTicketCount={ticketInfo.ownTicketCount}
      commentCount={commentInfo.commentCount}
      commentError={commentApiError}
      keywordInfo={keywordInfo}
    />
  )
}

이 코드를 DIP원칙으로 개선해본다면 다음과같은 개선점이 있을수있습니다.

Loading과 Error 처리가 TicketInfoContainer 컴포넌트 내부에 강하게 결합되어있기때문에 의존성을 반전시켜주는게 좋습니다. 리액트 ErrorBoundary와 Suspense를 사용하면 상위레벨에서 해당처리를 할수있습니다. 또한 ErrorBoundary와 Suspense는 여러부분에서 공통으로 사용되므로 응집도는 높이고 결합도는 낮추는 결과를 가져오게됩니다.
TicketInfo 컴포넌트가 너무많은 props를 가지고있습니다. 의존되는곳이 많기때문에 한번에 파악이 어렵고 테스트를 작성하기도 어렵습니다. 원글에서는 합성컴포넌트를 사용하여 컴포넌트를 분리하였습니다. 선호하는 방향에따라 각각의 컴포넌트를 폴더구조 하위에 만들어서 사용하는 방법도 있을것입니다.
- 여기서 IoC라는 개념을 잠깐 살피고 넘어가자면, IoC(Inversion of Control)는 제어역전으로, 컴포넌트를 사용하는 개발자에게 컴포넌트 제어권을 넘겨줌으로써 개발자가 원하는대로 컨트롤하도록하는 개념입니다.
- 컴포넌트가 특정조건에서 다른 렌더링결과물을 만들어내야하는데, 전달되는 props도 많고 렌더링조건이 많아지게된다면 컴포넌트 복잡도는 증가할것입니다. 이때 여러 IoC패턴들을 사용해서 쉽게 쪼개볼수있습니다.
- https://fe-developers.kakaoent.com/2022/221110-ioc-pattern/ 글을 참고하시기 바랍니다.

마치며

React에 SOLID원칙을 적용하면 프로젝트에서 발생할수있는변화, 장애상황시에 조금 더 유연한 대처가 가능합니다. 응집도는 높고 결합도는 낮은, 확장에는 개방되어있고 변경에는 폐쇄되어있는 컴포넌트를 만들어내는것이 중요한것같습니다. 여태까지는 나중에 어떤 결과를 가져올지는 생각안하고 대충느낌상 쪼개야할때 컴포넌트를 분리하곤했었습니다. SOLID원칙을 정리하고나니, 이젠 근거를 가지고 컴포넌트구조를 설계할수있을것같습니다. 더 나은 의견이 있다면 댓글로 알려주세요! 긴글 읽어주셔서 감사합니다.

TanStack Query v5 변경사항, 마이그레이션 가이드

Dev.yeon — Thu, 26 Oct 2023 14:01:55 +0900

드디어 TanStack Query v5가 릴리즈되었습니다! v4보다 용량은 더작게, 하지만 더 직관적이게 변화했는데요, 변경사항과 마이그레이션시의 주의사항을 살펴보도록 하겠습니다.

1. Breaking Change

가장 큰 변화에는 코드베이스로부터의 overload를 제거하여 useQuery와같은 훅을 더 직관적으로 만들었다는 것입니다. 사실 v4부터 하려고 기획했던것이지만 타입스크립트에서의 제약으로 인해 할수가없었는데요, TS 4.7에서 이부분이 보완되었고, 훅을 호출할때의 다양한 매개변수를 이제는 신경쓰지 않아도되게 변화하였습니다. v5에서는 객체만을 지원합니다. 이 부분은 DX측면에서 큰 성과라고 할수있습니다. 일일히 overload를 고려하지않아도되며, 하나의 객체만을 전달하면되기때문에 일관성이 높아졌습니다. 당연히 새로운 API를 사용할수있도록 eslint 패키지에 자동수정가능한 규칙도 배포되었습니다. 또한 v5로 마이그레이션하는데에 도움이되는 codemod도 추가되었습니다.

이외에도, 기존 cacheTime을 gcTime으로 이름을 변경하여 직관성을 높였고, keepPrevioudsData 옵션을 placeholderData 옵션과 통합하여 비슷한 기능을 하던 두가지의 옵션을 하나로 재정의하였습니다. 또한 loading으로 표시되던 상태값을 pending이라는 이름으로 변경되었고, useQuery에서의 콜백을 제거하였습니다.

2. New Features

당연히 새롭게 추가된 기능들도 있습니다.

Simplified optimistic updates: cache를 수동적으로 업데이트하는 코드대신, useMutation에서 반환된 'variables'를 사용하여 업데이트를 수행할수있습니다.
Sharable mutation state: useMutation 훅을 통해 컴포넌트 간에 공유되는 모든 상태에 접근할수있습니다.
1st class 'suspense' support: suspense를 완전히 지원하며, useSuspenseQuery나 useSuspenseInfiniteQuery와 같은 훅을 사용할수있습니다.
Improved Infinite Queries: infinite query는 이제 한번에 여러페이지를 prefetch할수있으며, 옵션으로 최대페이지의 개수까지 지정할수있습니다.
New Devtools: Query devtools는 모든 어댑터, 프레임워크에 사용될수있도록 다시 개발되었습니다. UI개선과함께 cache 인라인 편집이나 light mode같은 기능도 추가되었습니다.
Fine-grained persistense: PersistQueryClient 플러그인에 기존에는 없었던 복원기능이 추가되었습니다. experimental_createPersister를 사용하면 storage를 전달할수있습니다.

3. Migration Guide

1) Supports a single signature, one object

이제 useQuery, useInfiniteQuery등 훅을 호출할때 객체만을 지원합니다. TS에 많은 오버로드를 가지는것과 매개변수 유형을 확인하기위해 runtime 검사를 해야하는 수고로움이 사라졌습니다. 타입스크립트 4.7 이전버전에서는 함수인수가 unknown으로 추론되는 이슈가 있었고, 이 때문에 useQuery등의 훅에서 매개변수를 사용할때 많은 타입스크립트 에러를 만나야만했습니다. 하지만 이 부분이 TS 4.7에서 해결이되면서 오버로드가 모두 제거되었기때문에 단일객체로 사용이 가능합니다. 그렇기때문에 최소한 TS 버전은 4.7이상으로 설정해주어야합니다.

- useQuery(key, fn, options)
+ useQuery({ queryKey, queryFn, ...options })

- useInfiniteQuery(key, fn, options)
+ useInfiniteQuery({ queryKey, queryFn, ...options })

- useMutation(fn, options)
+ useMutation({ mutationFn, ...options })

- useIsFetching(key, filters)
+ useIsFetching({ queryKey, ...filters })

- useIsMutating(key, filters)
+ useIsMutating({ mutationKey, ...filters })

**2) getQueryData, getQueryState now accepts queryKey only as an Argument**

getQueryData와 getQueryState는 이제부터 queryKey만을 인자로 받습니다. 기존에는 filters 인자도 optional하게 받아서, stale이나 exact 등의 필터를 설정할수있었지만, v5에서는 filters 설정기능이 사라졌습니다.

- queryClient.getQueryData(queryKey, filters)
+ queryClient.getQueryData(queryKey)

- queryClient.getQueryState(queryKey, filters)
+ queryClient.getQueryState(queryKey)

3) Callbacks on useQuery have been removed

useQuery에서의 콜백이 제거되었습니다(useMutation에서의 콜백은 사라지지않았습니다). 따라서 onSuccess, onError, onSettled는 이제 사용하지 못합니다. useQuery의 콜백이 제거된 이유는 예상대로 동작하지 않을 가능성이 높기때문입니다. 기존에는 쿼리가 성공적으로 실행되었을때 / 오류가 발생했을때 / 두 경우모두 해당할때 호출되는 3가지 콜백함수 onSuccess / onError / onSettled가 있었습니다. 하지만 이러한 콜백들이 일어나지않을수도, 중복으로 호출될수도 있습니다. (자세한 사례는 본글을 참조하세요) 따라서 이 콜백들은 직관적이지 못합니다. v5에서는 이러한 콜백을 사용하지 못하기때문에 다른 대안법을 찾아야합니다. onError대신 meta필드를 사용한다든지, onSuccess대신 value값 자체를 반환한다던지의 대안을 사용해야합니다.

//AS-IS
export function useTodos() {
  return useQuery({
    queryKey: ['todos', 'list'],
    queryFn: fetchTodos,
    onError: (error) => {
      toast.error(error.message)
    },
  })
}



// To-BE
const queryClient = new QueryClient({
  queryCache: new QueryCache({
    onError: (error, query) => { 
      if (query.meta.errorMessage) {
        toast.error(query.meta.errorMessage)
      }
    },
  }),
})

export function useTodos() {
  return useQuery({
    queryKey: ['todos', 'list'],
    queryFn: fetchTodos,
    meta: { 
      errorMessage: 'Failed to fetch todos',
    },
  })
}

//AS-IS
export function useTodos() {
  const [todoCount, setTodoCount] = React.useState(0)
  const { data: todos } = useQuery({
    queryKey: ['todos', 'list'],
    queryFn: fetchTodos,
    //  please don't
    onSuccess: (data) => {
      setTodoCount(data.length)
    },
  })

  return { todos, todoCount }
}

//TO-BE
export function useTodos() {
  const { data: todos } = useQuery({
    queryKey: ['todos', 'list'],
    queryFn: fetchTodos,
  })

  const todoCount = todos?.length ?? 0

  return { todos, todoCount }
}

**4) refetchInterval callback function only gets 'query' passed**

refetchInterval, refechOnWindowFocus, refetchOnMount, refetchOnReconnect와 같은 훅들에서 더이상 data를 select하여 변환하지 못합니다. 기존에 변환된 데이터를 가져올때 발생하던 typing issue를 해결하기위해서 수정되었습니다. 하지만 여전히 query.state.date를 사용하여 데이터에 접근할수있기때문에 refetch한 후에 데이터변환을 시도하면됩니다.

- refetchInterval: number | false | ((data: TData | undefined, query: Query) => number | false | undefined)
+ refetchInterval: number | false | ((query: Query) => number | false | undefined)

5) 'remove' method has been removed from useQuery

remove는 기존에 옵저버에게 알리지않고 쿼리를 제거하는데 사용되는 메서드였으나, 쿼리가 아직 활성화되지 않은 상태에서 remove를 수행하는 것은 리렌더링시에 로딩상태를 불러오기때문에 합리적이지 못하다는 이유로 사라졌습니다. v5에서는 removeQueries 메서드를 통해 쿼리 삭제가 가능합니다.

const queryClient = useQueryClient();
 const query = useQuery({ queryKey, queryFn });
 
- query.remove()
+ queryClient.removeQueries({ queryKey })

6) `isDataEqual` option has been removed from useQuery

기존에 isDataEqual 옵션은 이전데이터를 사용할지 새로운데이터를 사용할지에 대해 판단하는데 사용되었으나 structuralSharing 옵션과 비슷한 기능을 하기에 제거되었습니다.

import { replaceEqualDeep } from '@tanstack/react-query'

- isDataEqual: (oldData, newData) => customCheck(oldData, newData)
+ structuralSharing: (oldData, newData) => customCheck(oldData, newData) ? oldData : replaceEqualDeep(oldData, newData)

7) Supported Broswers

성능과 번들크기를위해 지원되는 브라우저 범위를 업데이트하였습니다.

Chrome >= 91
Firefox >= 90
Edge >= 91
Safari >= 15
iOS >= 15
opera >= 77

8) Rename `cacheTime` to `gcTime`

기존 cacheTime은 마치 "데이터가 캐시로 유지되는시간"이라는 뜻을 나타내는것처럼 보이지만 사실은 "쿼리가 사용되지않을때 캐시가 제거되기까지의 시간"입니다. 쿼리가 계속사용될때 cacheTime은 아무일도하지않다가 쿼리가 사용되지않는 순간부터 일정시간 이후에 garbage colletor가 수집해서 버려버리기 때문입니다. 따라서 gcTime으로 이름을 변경하여 가비지로 수집되기까지의 시간이라는 뜻을 더 잘 나타내게하였습니다.

const MINUTE = 1000 * 60;

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
-      cacheTime: 10 * MINUTE,  //AS-IS
+      gcTime: 10 * MINUTE, 	//TO-BE
    },
  },
})

9) `useErrorBoundary` option has been renamed to `throwOnError`

기존 리액트 훅의 use와 혼동되는것을 방지하기위해 useErrorBoundary 옵션의 이름이 throwErrors로 변경되었습니다.

10) TS: `Error` is now the default type for errors instead of `unknown`

에러의 기본타입이 unknown에서 Error로 변경되었습니다. 커스텀에러나 에러가 아닌 타입을 지정하고싶다면 다음과 같이 지정할수있습니다.

declare module '@tanstack/react-query' {
  interface Register {
    defaultError: AxiosError
  }
}

const { error } = useQuery({ queryKey: ['groups'], queryFn: fetchGroups })

11) Removed `keepPreviousData` in favor of `placeholderData` idenify function

keepPreviousData와 isPreviousData 플래그는 placeholderData 혹은 isPlaceholderData플래그와 비슷한 기능을 하므로 제거되었습니다. 다만 몇가지 다른점은 placeholderData는 항상 success상태를 반환할것이며, dataUpdatedAt은 항상 0으로 유지될것이라는점입니다. 기존 keepPreviousData는 이전 쿼리의 상태를 나타냈지만, 에러 자체가 다음 쿼리로 공유되지는 않으므로 placeholderData의 동작(success로 반환되는것)을 그대로 사용하기로 하였습니다.

useQuery({
  queryKey,
  queryFn,
  placeholderData: (previousData, previousQuery) => previousData, // identity function with the same behaviour as `keepPreviousData`
})

12) Window focus refetching no longer listends to the `focus` event

focus 이벤트 대신에 visibilityChange 이벤트를 전적으로 사용합니다. visibilityChange이벤트를 지원하는 브라우저만을 지원하고 있으며, 기존에 focus로 인한 이슈는 해결되었습니다.

13) Network status no longer relies on the `navigator.onLine` property

navigator.onLine은 chromium 기반 브라우저에서 제대로 작동하지않기때문에 online:true로 가정하고 온라인/오프라인 이벤트를 수신하였을때만 상태를 업데이트합니다. 이때 인터넷 연결없이도 작동이 가능한 서비스워커를 통해 로드되는 오프라인 앱에서는 오탐이 있을수 있습니다.

14) Removed custom `context` prop in favor of custom `queryClient` instance

v4에서는 모든 리액트 쿼리 훅에 custom context를 전달할수있는 기능을 도입했으나, 이는 리액트 전용 기능이므로 quert client를 직접 전달하게함으로써 모든 프레임워크에서 사용가능하도록 변경하였습니다.

import { queryClient } from './my-client'

const { data } = useQuery(
  {
    queryKey: ['users', id],
    queryFn: () => fetch(...),
-   context: customContext //AS-IS
  },
+  queryClient, //To-BE
)

15) Infinite queries now need a `initialPageParam`

기존에는 pageParam으로 undefined를 지정할수도 있었지만 이는 query cache에 정의되지않은 상태로 존재한다는 허점이 있었습니다. v5에서는 명시적으로 initialPageParam을 지정하여 첫페이지의 pageParam을 정해주어야합니다.

useInfiniteQuery({
   queryKey,
-  queryFn: ({ pageParam = 0 }) => fetchSomething(pageParam), //AS-IS
+  queryFn: ({ pageParam }) => fetchSomething(pageParam), //TO-BE
+  initialPageParam: 0, //TO-BE
   getNextPageParam: (lastPage) => lastPage.next,
})

16) No retries on the server

기존에 서버 요청 실패시 재시도 기본값은 3번이였으나 이제는 0으로 변경되었습니다. prefetch의 경우 항상 기본값이 0이였지만, suspense가 활성화된 쿼리는 직접 서버에서 실행할수있기때문에 재시도를 전혀 하지않는것으로 변경되었습니다.

4. Conclusion

이외에도 변경된 사항이 있으므로 자세한 내용은 원글을 참조하시길 바랍니다. v5로 마이그레이션 할때 codemod를 지원해주므로 같이 사용한다면 훨씬 빠르게 가능할것으로 보입니다. 1년전 v5 로드맵 발표이후 많은 우려와 논의가 이루어졌었는데요, 기존에 문제되던 이슈들이 많이해결되었고, '직관성'을 강조하는 철학이 담겨 더 탄탄한 Tanstack query가 되었다라는 생각이 들었습니다. v4 -> v5에서 엄청난 변화가 있다고 느껴지진않지만, DX가 향상된 확고한 API들은 더 매력적으로 보이는것같습니다. 긴글 읽어주셔서 감사합니다.

Reference.

https://tanstack.com/query/v5/docs/react/guides/migrating-to-v5#codemod

Migrating to TanStack Query v5 | TanStack Query Docs

Breaking Changes v5 is a major version, so there are some breaking changes to be aware of:

tanstack.com

https://tanstack.com/blog/announcing-tanstack-query-v5

Announcing TanStack Query v5 | TanStack Blog

About one year ago, we announced the TanStack Query v5 roadmap, and the whole team has been working hard on that version ever since. So we're super happy to announce that today is the day: After 91 alpha releases, 35 betas and 16 release candidates, TanSta

tanstack.com

'unload' 이벤트는 이제 사용하지마세요

Dev.yeon — Tue, 24 Oct 2023 01:53:09 +0900

Never use unload event

'unload' 이벤트는 이제 크롬에서 점차 실행되지 않도록 변경된다고 합니다. 도대체 왜 사라지는것이며, unload 이벤트를 대체할수있는 이벤트에는 무엇이 있을까요?

1. Background

unload 이벤트는 말그대로 페이지가 unload 될때 실행되도록 설계되었습니다. 이론적으로 사용자가 페이지에서 다른페이지로 이동할때마다 실행되었습니다. unload 이벤트가 가장 일반적으로 사용되는 시나리오는 다음과 같습니다.

Saving user data: 페이지에서 나가기전에 데이터를 저장한다.
Performing cleanup tasks: 페이지를 끝내기전에 열려있는 리소스를 제거한다.
Sending analytics: 페이지 종료시 사용자 상호작용과 관련된 데이터를 전송한다.

하지만 unload 이벤트는 매우 불안정합니다. 데스크탑 Chrome 및 firefox에서의 unload 이벤트는 안정적이지만, bfcache의 사용을 방지하여 사이트 성능에 부정적인 영향을 미칩니다.

또한 모바일 브라우저에서는 탭이 백그라운드에서 실행되다가 종료되는 경우가 많기때문에 unload 이벤트 자체가 실행되지 않는 경우가 많습니다. 이러한 이유때문에 모바일에서는 unload보다 bfcache의 우선순위를 높게 책정하여 더더욱 unload 이벤트를 불안정하게 만듭니다.

따라서 크롬팀에서는 unload 이벤트를 완전히 제거하는것을 목표로 하고있습니다. 당장 이벤트를 없애는 것은 아니지만, unload 이벤트 자체를 명시적으로 다시 활성화하지않는한 unload 이벤트의 실행을 중지하도록 기본값을 변경하여 점진적으로 없애겠다고합니다.

※ bfcache(Back/forward cache)
사용자가 이동하는 동안 페이지의 전체 스냅샷을 저장하는 in-memory 캐시. 전체페이지가 저장되어있기때문에 사용자가 다시 페이지로 돌아올경우에 빠르게 복원을 가능하게 한다.

2. Page LifeCyle

그렇다면 unload 이벤트 대신에 사용할수있는 이벤트에는 무엇이 있을까요? 그전에 Page Lifecycle을 한번 간략하게 살펴보고 가도록 하겠습니다.

Page Lifecycle

모든 페이지 상태는 개별적이고 상호배타적이기때문에, 한페이지에는 한번에 한가지의 상태에만 있을수 있습니다.

Active: 페이지가 표시되고, 입력이 활성화된 상태
Passive: 페이지가 표시되어있지만, 입력포커스는 없는상태
Hidden: 페이지가 표시되지않고 숨겨진상태. 종료된것은 아닌상태
Terminated: 페이지가 브라우저에서 사라지면서 메모리에서 지워진 상태.

3. Alternatives to 'unload' events

unload 이벤트를 대신해서 쓸 수있는 이벤트는 visibilitychange와 pagehide가 있습니다.

visibilitychange: 페이지의 가시성이 변경되는 시점을 파악합니다. 사용자가 탭을 전환하거나, 브라우저 창을 최소화하거나, 새 페이지를 열때 발생합니다. 숨겨진 상태를 마지막으로 신뢰할수있는 이벤트라고 할수있습니다.
pagehide: 사용자가 페이지에서 벗어난 시점을 파악합니다. 사용자가 페이지에서 다른곳으로 이동하거나, 페이지를 다시 로드하거나, 브라우저 창을 닫을때 발생합니다. 페이지가 단순히 최소화되거나 다른탭으로 전환된 경우에는 발생하지 않습니다.

beforeunload event caution

beforeunload 이벤트도 페이지가 언로드되기 이전에 일어나기는하지만, unload이벤트와 마찬가지로 bfcache의 사용을 방지한다는 문제가 있습니다. 하지만 beforeunload는 unload와는 다르게 취소가능한 이벤트라는 점에 주목할 필요가 있는데요, 이때문에 저장되지않는 변경사항을 사용자에게 경고하는데에 사용됩니다. 크롬에서도 오직 이 용례에 한해서만 사용하라 라고 가이드하고있습니다.

4. Detect usage of 'unload'

unload 이벤트핸들러를 사용하고있는지는 lighthouse와 chrome devtools를 통해 확인이 가능합니다.

1) Lighthouse: 라이트하우스 테스트를 실행한후 결과를 보면, 페이지의 자바스크립트가 unload이벤트 리스너를 추가하는경우 경고문구를 확인할수있습니다.

2) Chrome Devtools: Application tab의 "Test back/forward cache"를 이용하여 테스트를 하면, 경고문구를 확인할수있습니다.

Reference.

- https://developer.chrome.com/blog/deprecating-unload/

Deprecating the unload event - Chrome for Developers

The unload event will be gradually deprecated starting from Chrome 117. Learn what this means and how sites and enterprises can prepare for this

developer.chrome.com

- https://developer.chrome.com/articles/page-lifecycle-api/

Page Lifecycle API - Chrome for Developers

The Page Lifecycle API brings app lifecycle features common on mobile operating systems to the web. Browsers are now able to safely freeze and discard background pages to conserve resources, and developers can safely handle these interventions without affe

developer.chrome.com

- https://web.dev/articles/bfcache?hl=ko#never_use_the_unload_event

뒤로-앞으로 캐시 | Articles | web.dev

브라우저의 뒤로 및 앞으로 버튼을 사용할 때 페이지가 즉시 로드되도록 최적화하는 방법을 알아보세요.

web.dev

2022년 상반기 하이닉스 IT 최종합격 수기

Dev.yeon — Mon, 22 Aug 2022 23:05:09 +0900

면접합격 메일

2022년 상반기 하이닉스 신입 공개체용에 ✨최종합격✨ 했습니다. 제가 지원했던 직무는 IT 직무이며, 이천에 위치하고 있습니다. 당시 자격요건에는 4년제 학사 이상 졸업(예정)자이며, 전산/컴퓨터/산업공학/경영정보학/전기/전자/반도체 등 관련전공자라는 조건이 있었습니다. 채용 전형은 서류전형 -> SKCT ( IT는 코딩테스트와 인성검사) -> 면접전형으로 3가지의 단계로 진행되었습니다. 비록 최종적으로 하이닉스에 입사하지는 않았지만, 각 단계에 대한 후기와 꿀팁을 적어보려합니다. 지원하고자하는 많은 분들께 도움이 되길 바라며, 혹시 궁금하신점이 있다면 댓글로 달아주시면 됩니다.

1. 서류전형

서류합격메일

서류전형에는 기본인적사항, 학력, 경력, 학부전공이수내역, 외국어능력사항과 함께 4가지 자소서 질문 문항에 대한 답변을 적게 됩니다. 하이닉스의 서류전형에서 가장 중요한점은 개인적으로 학점, 학력, 자소서문항이라는 생각이 들었습니다. '서류전형만 통과해도 반절은 왔다' 라는 생각이 들만큼 하이닉스에서는 서류에서 많이 필터를 거치기 때문에 3단계의 전형 중 가장 중요하다고 생각합니다. 또한 자소서를 기반으로 면접이 이루어지기 때문에 많은 시간을 들여 작성하는 것을 추천드립니다. 학점, 학력과 같은 사항은 자소서를 쓸 당시에는 바꿀수 없는 사항이기 때문에 많은 분들이 걱정하시는 부분중 하나입니다. 하지만 여러명의 최종합격자 분들과 대화했을때 제가 느낀 점은 물론 학력도 하이닉스 합격에 있어서 중요한 지표중 하나지만, 본인의 직무에 대해 이해도가 높고, 대학생활때 열심히 하신분들이 붙는다는 점입니다. 참고를 위해 저의 스펙을 말씀드리자면,

이화여대 컴퓨터공학과 4.1 / 2번의 인턴경험 (SKT, LG전자) / 토익스피킹 LV7 / 2번의 개발동아리(교내, 교외) / 프로젝트 4개(전공팀플젝 제외)

정도의 스펙을 보유하고 있습니다. 실제로 면접전형에서 받은 질문 중 70%가 인턴경험, 동아리활동 에서 나온만큼, 본인이 했던 활동에 대해 충분히 설명이 가능한경우에 쓰는 것이 좋다고 생각합니다. 특별한 자격증이나 동아리활동이 있는 경우에도 적는 것이 좋다고 느꼈는데, 직무와 관련이 없는 자격증이였지만, 면접때 자소서에 기재한 저의 열정과 자격증을 얻는 과정을 연결지어 답변했더니 면접분위기가 아주좋았습니다. 직무와 관련이 없더라도 본인의 성향을 잘 나타낼수있는 활동이라면 적으시는 것을 추천드립니다.

자소서 문항은 4가지입니다. 자발적으로 최고수준의 목표를 세우고 끈질기게 성취한 경험 / 새로운것을 접목하거나 남다른 아이디어를 통해 문제를 개선했던 경험 / 지원분야의 전문성을 키우기 위해 꾸준히 노력한경험 / 팀워크를 발휘하여 공동의 목표달성에 기여한 경험에 대한 질문입니다. 글자수 제한은 모두 1000자 이내인데, 저는 거의 1000자를 꽉 채워서 제출하였습니다. 4가지 문항모두 개발과 관련지어 작성하였고, 선택질문에 대한 답변은 추가적으로 하지 않았기 때문에 결과적으로 필수였던 4개의 답변만 제출하였습니다. 하이닉스는 특이하게 질문이 굉장히 길고 상세합니다. 괄호안에 친절하게 어떤 내용이 들어가면 좋다라는 것을 명시해주는데, 이 괄호안의 조건들을 순서대로 연결지어 글을 쓰시는것을 추천드립니다. 전문가 분들께 자소서 첨삭을 받을때 항상 칭찬을 받은 점이, 괄호안의 조건들이 모두 답변에 녹아있기때문에 자소서 점수가 높을 것이다 라는 점이였습니다. 추가적으로 꿀팁을 알려드리자면, 소제목을 꼭 달아주시는것이 좋습니다. 평가자분들이 한눈에 알아볼수 있게끔 키워드를 중심으로 궁금하게 작성한다면 더 높은 점수를 받을 수 있습니다.

2월 28일 접수마감 후, 3월 11일 금요일 5시 17분에 합격메일을 수신하였습니다. 합격메일을 기다리는 순간이 가장 떨렸는데요, 전형마다 메일 수신 날짜와 시각을 작성해놓을테니 참고하시면 좋을것 같습니다.

2. SKCT ( 코딩테스트와 인성검사)

SKCT 합격메일

IT직무는 코딩테스트를 보게 됩니다. 3월 19일 토요일에 온라인으로 진행되었으며, 카메라를 연결해야하고 검색은 불가능합니다. 오전 10시부터 12시까지 2시간동안 4문제를 풀어야하며, 언어는 C++ 고정입니다. 저는 원래 코딩테스트 주언어를 파이썬으로 사용하고 있었기 때문에 3월 11일 합격메일을 수신한 후, 일주일동안 C언어를 공부하였습니다. 밥먹고 자는 시간빼고 C언어를 공부하였고, 주로 백준과 프로그래머스를 사용하여 공부하였습니다. 하이닉스 코딩테스트의 경우, 타기업에 비해 난이도가 높은 편은 아닙니다만, 예전에 비해 점점 더 어려워지고있고, 언어가 한정적이라는 점때문에 어렵게 느껴집니다. 제가 봤던 코딩테스트에서는 완전탐색, BFS/DFS, DP, 구현과 관련된 문제가 나왔습니다. 문제순서가 난이도 순서는 아니기 때문에, 문제를 잘 살펴보시고 자신있는 문제서부터 푸는것을 추천드립니다. 저는 따로 면접에서 코드리뷰는 실시하지 않았으나, 면접방식이 어떻게 바뀔지 모르기 때문에 코딩테스트 후에 복기를 해놓는 것을 추천드립니다. 당시 코딩테스트 문제와 유사했던 문제의 링크를 하단에 첨부해둘테니 참고하시기 바랍니다.

1시부터는 따로 인성검사를 실시하게 됩니다. 소요시간은 약 40~50분 사이이며, 시간내에 인성 질문에 대해 답변을 체크하는 형식입니다. 이 부분은 솔직하게 답변하는 것이 좋다고 생각합니다. 물론 SK하이닉스의 인재상에 맞게 답변하는 것도 중요하지만, 본인이 답변한 내용이 면접에서의 본인과 다를 경우에는 면접결과에 좋지 않은 영향을 미칠 것이라는 생각이 듭니다. 저는 인성검사에서 솔직하게 열정적이고 매사에 진중한 모습으로 답변하였고, 그 모습그대로를 면접장에서 보여드렸습니다. 또한 문항수가 굉장히 많은데, 앞에서의 답변과 뒤에서의 답변이 일치하는 것도 중요하므로, 앞에서의 답변을 기억하고 넘어가는것이 좋습니다.

3월 19일 코딩테스트 실시 후에, 3월 25일 금요일 오후 5시 27분에 합격메일을 수신하였습니다.

* 코딩테스트전에 아래의 문제들을 풀어보세요 *

https://programmers.co.kr/learn/courses/30/lessons/81302
https://www.acmicpc.net/problem/1913
https://www.acmicpc.net/problem/11005
https://programmers.co.kr/learn/courses/30/lessons/12983

3. 면접전형

건강검진까지 통과 후 받은 입사선물

면접전형은 4월 4일 ~ 19일 사이에 온라인으로 진행되었습니다. 저는 상대적으로 늦게 면접 일정이 잡혔지만, 같은 직무여도 굉장히 빠르게 보시는 분들도 계셨습니다. 또한 최종합격자 분들과 대화를 나눠본 결과, 면접 일정이 최종합불에는 영향을 미치지 않는다는 생각이 들었습니다. 따라서 일정신경쓰시지 마시고 준비하시면 될것같습니다. 지원자마다 면접 시간이 상이한데, 평균적으로 약 25~30분동안 면접을 봅니다. 이때 인성질문과 직무질문에 대한 질문을 쉴새없이 받는다고 생각하시면 됩니다. 저는 인성질문을 대체로 받았는데, 다른 분들께서는 직무질문도 많이 받았다라고 하시니 골고루 준비를 하시면 될 것 같습니다.

어떤 질문이 나왔는지에 대해서 말씀드릴수는 없지만 제가 준비한 질문들을 공유해보자면, 인성질문에서는 1분 자기소개, 지원 이유, 불화 해결방법, 되고싶은 개발자, 존경하는 사람, 나의 장단점, 인턴경험, 동아리활동 등에 대한 질문을 약 30개정도 만들었고 그에 대한 답변을 연습했습니다. 직무질문에서는 반도체, 펌웨어, 지원직무가 정확히 무슨일을 하는지, ESG에 대한 질문을 약 30개 정도 만들었고 그에 대한 답변을 연습했습니다. 이렇게 연습했던것이 면접에 도움이 되었다고 생각하고, 하이닉스에 대한 기업조사는 기본이라고 생각합니다. 하이닉스 공식 홈페이지를 참고하여 답변을 만들어나가시길 바랍니다.

4월 19일 모든 지원자분들의 면접이 끝난후에, 최종합격메일은 5월 3일 화요일 5시 50분에 수신하였습니다.

4. 최종합격 후기

건강검진, OT까지 모두 참여했지만 최종적으로는 입사하지 않았습니다. 너무나 좋은 회사지만 제가 좀더 하고싶은 일을 하는 것이 맞다라는 생각이들어 입사를 포기하게 되었습니다. 오랜기간동안 전형이 진행되는 만큼, 개인적으로 마음을 다잡기가 힘든순간이 여러차례 왔습니다. 결과메일이 언제올까 노심초사하게되고, 다른 지원자 분들과의 비교를 통해 나의 답변이 틀렸나 라는 생각도 들었습니다. 하지만 그럴때마다, 조금 더 직무에 대한 이해도를 높이려 공부를 하였고, "지금 할 수 있는 일을 하자" 라는 마인드로 마음을 다잡으려 노력하였습니다. 채용과정을 거치면서, 반도체 산업과 IT직무에 대한 부분도 자세히 알게되었지만, 정신적으로 더 성숙해졌다는 생각이 듭니다. 후배가 하이닉스 하반기 지원 시작했는데 막막하다라는 말을 듣고 최종합격수기를 작성해보았습니다. 제글이 도움이 되길 바라며, 궁금하신 점은 댓글로 남겨주시면 아는선에서 답변해드리도록 하겠습니다. 감사합니다.

2022년 상반기 LINE 라인 최종 합격 수기

Dev.yeon — Sat, 4 Jun 2022 00:46:07 +0900

언제봐도 짜릿한 최종합격 메일

2022년 상반기 라인 신입 공개 채용에 ✨최종합격✨ 했습니다. 제가 지원했던 직무는 Web FrontEnd Engineer 이며, 라인플러스 법인 소속입니다. 지원서접수, 코딩테스트, 필기테스트, 1차 면접, 2차면접의 채용과정을 거쳤는데, 각 단계에 대한 후기와 지원꿀팁을 순서대로 적어보려 합니다. 제글이 도움이 되길 바라며, 궁금하신 점은 언제든지 댓글로 달아주시면 됩니다!

2022년 라인 상반기 채용과정

1. 지원서 접수

지원서에는 기본인적, 학력, 경력, 어학사항과 함께 3가지의 자소서 질문 문항에 대한 답변을 적게됩니다. 지원서 접수단계의 경우 적혀있는 것처럼 지원자격만을 확인하기 때문에 자격만 갖춘다면 코딩테스트를 응시할 수 있지만, 필기테스트의 지원자격을 판단할때는 지원서 + 코딩테스트 결과를 같이 고려하여 합격여부가 나오기 때문에 열심히 작성을 하는 것이 좋습니다. 또한, 자소서 기반으로 면접이 진행되기때문에 최대한 상세하게 적는 것이 좋습니다. 참고를 위해 저의 서류 스펙을 말씀드리자면,

이화여대 컴퓨터공학과 4.1 / 2번의 인턴경험 (SKT, LG전자) / 토익스피킹 LV7 / 2번의 개발동아리(교내, 교외) / 프로젝트 4개(전공팀플젝 제외)

정도의 스펙을 보유하고 있습니다. 자소서 문항은 3가지로, 의미있었던 개발경험 / CS지식과 기술적역량 / 협업 경험에 대한 질문입니다. 글자수 제한은 딱히 없었어서 1000자 내외정도로 작성하였고, 한 문항당 2개의 프로젝트 경험을 서술하였습니다. 배포까지 했던 프로젝트는 실제 서비스 링크를 첨부하였습니다. 자소서를 적을때는 실제 기술명과 함께 최대한 자세하게 서술하였고, 자세하게 서술했던점이 후에 면접 과정에서도 그것과 관련된 질문에 답변하는데에 도움이 되었다고 생각합니다. 프로젝트를 2개이상 언급할 경우 번호를 달아 구분되게 하였고, 소제목을 달아 어떤 줄거리인지 한눈에 파악하게끔 작성하였습니다.

첨부자료항목에 포트폴리오 파일과 깃허브링크를 첨부할 수 있습니다. 빈항목으로 두는 것보단 파일과 링크 모두 첨부하는 것을 추천드립니다! 포트폴리오는 20장정도로 작성하였고, 작성법에 대해선 추후에 게시글을 업로드할 예정입니다. 블로그 링크또한 포르폴리오에 첨부하여서 채용담당자분께서 확인하실 수 있도록 하였고, 실제 면접장에서 블로그 관련 질문또한 받았습니다. 자소서와함께 첨부자료도 모두 확인하여 면접질문이 정해지므로, 자세하게 작성하여 첨부하시면 좋을 것 같습니다.

2. 코딩테스트

코딩테스트 합격 메일

3월 26일 토요일 오전 10시부터 1시까지, 총 3시간동안 6문제를 풀었습니다. 오픈인터넷, IDE사용가능인 시험이므로 따로 카메라를 설치하진 않았습니다. 체감상 난이도는 백준티어로 표현하면 실버4, 골드 5, 실버 1, 골드 3, 골드 4, 골드2 이렇게 여섯문제가 나왔다고 생각합니다. 저는 다섯문제를 풀었지만 끝나고 생각해보니 한문제는 효율성에서 오류날 것이라 생각하여 정확하게는 4문제정도 정확하게 풀었다고 볼 수 있을 것 같습니다. 통상적으로 6문제중에 4문제는 맞춰야 필기테스트를 볼 수 있는 자격이 주어지는 것 같습니다. 저는 전략적으로 다섯문제만 정확하게 풀어내자라는 마인드로 1개의 문제는 아예 풀지 않았고, 다섯문제를 푼 후 남은 1시간 동안은 엣지케이스를 생각해보며 검토하고 주석을 달았습니다. 테스트케이스는 3개정도 주어지고, 본인이 케이스를 추가하여 테스트를 돌려볼 수는 있습니다. 나중에 히든케이스로 채점하기 때문에 테스트 케이스가 다 맞았다고 하여, 그 문제가 맞았다고 확답할 수 없습니다. 라인 코딩테스트를 잘풀기 위해서는

구현 / 문자열 조작(문자열 나누기, 대소문자 등) / 완전탐색 / 스택, 큐, 집합 자료구조 / BFS, DFS

에 대한 문제에 대해서는 확실히 익히고 들어가면 좋을 것 같습니다. 프로그래머스의 LV2 문제나 백준의 실버 문제들에 대해선 15분 이내에 빠르게 풀 수 있는 실력은 무조건 갖추고, 프로그래머스의 LV3문제나 백준의 골드4정도의 문제에 대해서는 45분 이내에 풀어내는 정도의 실력을 갖춘다면 라인 코딩테스트는 무난하게 통과할 수 있을 것이라 생각합니다.

3. 필기테스트

필기테스트 합격메일

필기테스트는 코딩테스트 일주일 후에 4월 2일 토요일 오전 10시부터 11시 30분까지 총 90분동안 진행하였습니다. 다만, 코딩테스트 결과는 수요일 오후에 발표되었기 때문에 결과를 보고 공부를 시작하신다면 늦을거라 생각합니다. 만약 코딩테스트를 4문제정도 정확하게 풀어냈다라고 생각이 드신다면, 바로 필기테스트에 대해 공부를 하셔야 할것같습니다. 약 30~40문항정도 나오기 때문에 한문항당 쓸 수 있는 시간은 2~3분정도 입니다. 필기테스트 범위는 4년간 컴퓨터공학 에서 배우는 전공과목입니다. 중요한 순으로 추려보자면,

네트워크 / 운영체제 / 데이터베이스 / 보안 / 자료구조와 알고리즘 / C 언어 / 컴퓨터구조 / OOP / 오토마타 / 디자인패턴 입니다.

학부시절 열심히 정리를 해놓았다면 도움이 될 것 같습니다! 자세하고 꼼꼼하게 계산법까지 공부를 한다기 보다는, 해당 전공에 등장하는 분야와 용어에 대한 정의를 정확하게 알아놓자 라는 식으로 공부를 하시면 좋을 것 같습니다. 또한 필기테스트에서는 오픈인터넷이 불가하며 카메라를 설치해야하는 시험이기 때문에 누가누가더 많이 암기하냐의 싸움입니다. 코딩테스트가 끝난후 일주일동안 시간을 잘 배분하여 여러 분야의 범위를 커버할 수 있도록 계획을 잘 세우는 것이 중요할 것 같습니다. 만약 비전공자이시거나 학교수업시간에 정리를 하지 않으셨다면, 케이묵 사이트에서 해당 전공과목에 대한 수업을 들으시거나, 한재엽님의 깃허브를 참고하시면 좋을 것 같습니다.

http://www.kmooc.kr/

| K-MOOC

K-MOOC 소개 K-MOOC는 온라인을 통해서누구나, 어디서나 원하는 강좌를 무료로 들을 수 있는온라인 공개강좌 서비스로 2015년에 시작된한국형 무크입니다. more 강좌찾기 K-MOOC의 다양한 강좌를 통해

www.kmooc.kr

https://github.com/JaeYeopHan/Interview_Question_for_Beginner

GitHub - JaeYeopHan/Interview_Question_for_Beginner: Technical-Interview guidelines written for those who started studying progr

:boy: :girl: Technical-Interview guidelines written for those who started studying programming. I wish you all the best. :space_invader: - GitHub - JaeYeopHan/Interview_Question_for_Beginner: Techn...

github.com

4. 1차면접

1차 면접 합격메일

1차면접은 4월 18일 월요일부터 5월 2일 월요일까지 진행되었습니다. 그 중 저는 4월 21일에 면접을 보았고, 약 60분동안 기술면접을 보았습니다. 총 2명의 면접관분들과 함께 진행하였고, 여러 분야에 걸친 기술문제를 받았습니다.

인성질문(5분정도) / 프로젝트 질문(5분정도) / 리액트 질문 / 돔과 가상돔 / CSR SSR / SEO / 시맨틱마크업 / 네트워크 계층 / 마크업 최적화 / JS엔진 / 프로세스와 스레드 / 자료구조

에 대한 질문을 50분동안 쉴새없이 받았습니다. 프론트엔드에 관련한 질문부터 시작해서 네트워크, 운영체제 등 CS와 관련된 질문들도 받았기 때문에, 필기테스트에서 준비했던 것과 별개로 답변하는 연습을 많이 하셔야합니다. 본인이 수행했던 프로젝트에 대해서는 막힘없이 술술 이야기 할 수 있어야하며, 그외의 기술질문에 대해서는 정말 깊이 공부하셔야 합니다. 저는 200문항에 대한 질문과 답변을 준비하였고, 그외에도 노트정리를 통해 각 전공과목에 대한 공부를 하였습니다. 정말 간단한 예를 들어보자면,

브라우저 동작과정에 대해서 말해보세요 -> HTML을 파싱하여 어쩌구 -> 파싱의 뜻이 무엇인가요? -> 자바스크립트엔진이 어쩌구 -> 자바스크립트 엔진은 어떤 동작과정을 가지나요? -> 이벤트루프와 콜스택 어쩌구 -> 그럼 이벤트루프와 콜스택은 어디에 존재하나요?

와 같은 과정을 통해 정말 모를때까지 깊게 질문을 하십니다. 위의 예시는 제가 방금 만들어낸거라 허접하지만, 실제 면접에서는 정말 논리적이고 타당한 과정으로 깊게 탐구하게 됩니다. 1차면접을 거치면서 정말 공부를 많이 했고, 면접 50분동안에 질문들을 들으면서 감탄이 나올정도로 질문들이 너무 좋았습니다. 이런 면접 경험을 거쳤다는 것이 영광이고 큰 교훈이였습니다. 30여정도의 질문중에 대답을 못한건 4개정도라고 생각하며, 그외의 질문들은 제가 아는것을 정확히 전달하려고 노력하였습니다. 50분동안의 기술면접이 끝난후에 나머지 10분동안에는 제가 면접관 분들께 질문할 수 있는 시간이 주어집니다. 저는 라인 기술블로그에서 해당 직무와 관련된 글은 모두 읽었고, 그중에서 궁금한 점에 대해서 여쭈어 보았습니다.

https://engineering.linecorp.com/ko/

Main - LINE ENGINEERING

LINE의 미션은 사람과 사람, 정보, 서비스 사이의 거리를 좁히는 것입니다. TAKE OWNERSHIP LINE 개발자들은 자신의 프로젝트에 오너십을 가지고 최고의 결과물을 만들어냅니다 BE OPEN LINE 엔지니어들

engineering.linecorp.com

5. 2차 면접

최종합격메일에 실린 이미지

2차면접은 5월 16일 월요일부터 5월 26일 목요일까지 진행되었습니다. 그 중 저는 5월 16일에 면접을 보았고, 약 60분정도 진행되었습니다. 저는 2차면접에서는 여러 인성질문과 프로젝트 관련질문을 7:3 비율로 받았습니다. 하지만 다른 분들중에서는 1차면접보다도 더 어려운 기술면접을 보셨다는 분들고 계셨고, 인성질문만 받았다는 분들고 계셨습니다. 따라서 일단 1차면접에서 준비한 면접 문항들은 다시 처음부터 공부하면서 혹시나 빠트린것이 있지는 않은지 확인하셔야하며, 1차면접에서 대답하지 못했던 것들에 대해서는 따로 적어두었다가 공부를 하셔야합니다. 또한 본인이 작성한 지원서를 다시 보면서 프로젝트 관련하여 제대로 알고있는지, 관련 기술들에 대해 최신기술 현황을 공부하고, 코드를 다시 보면서 복습하시는 것을 추천드립니다. 인성질문에 대한 대비를 하실때에는

나는 어떤 개발자가 되고싶은가? / 나라는 사람은 어떤 사람이지? / 나의 장단점 / 내가 개발자가 되고싶은 이유 / 나의 개발 가치관 / 내가 라인에서 하고싶은 일 / 내가 라인에 가고싶은 이유 / 마지막으로 정말 드리고 싶은 말

에 대해서 곰곰히 생각해 보시면 좋을 것 같습니다. 인성질문에 대한 답변은 하루아침 완성되는 것이 아니라고 생각합니다. 또한 개인마다 다른 인성질문이 주어질 수도 있습니다. 따라서 그간의 개발 경험과 나의 인생 가치관이 맞물려서 가지고 있는 생각들을 말로 잘 표현하여 답변하는 연습을 하시면 좋을 것 같습니다.

6. 최종합격 후기

라인의 채용과정을 거치면서 제 자신이 정말 성장했다라는 생각이 듭니다. 여러 분야에 걸쳐서 공부하는 과정에서 제가 그간 얕게 알고있던 내용에 대해서 깊이 공부할 수 있었고, 정말 대단하신 면접관 분들과 질문과 답변을 주고받으며 많은 지식 뿐만 아니라 개발자가 가져야할 자세에 대해 생각해볼 수 있어서 영광이었습니다. 라인에 입사하기까지 약 3주정도의 시간이 남았는데, 입사를 기다리며 라인에서 발간한 책을 읽어보려 합니다. 라인 개발자 분들의 개발이야기를 들으며, 신입 개발자가 가져야할 자세와 앞으로 어떤 개발자가 될 것인지에 대해서 깊게 생각해보는 시간을 가지려고 합니다. 긴글 읽어주셔서 감사하며, 라인에서 동료개발자로 만나뵙길 기원하겠습니다! 궁금하신점은 댓글로 남겨주세요. 감사합니다

오늘 온 따끈따끈한 새책

[JS] 콜백함수, 콜백지옥

Dev.yeon — Fri, 13 May 2022 16:03:09 +0900

1. 콜백함수란?

다른 코드(함수 또는 메서드)에게 인자로 넘겨줌으로써 그 제어권도 함께 위임한 함수이다. 예를들면 A와 B는 토요일 오전 7시에 만나기로 하였다. 둘은 만나기위해 5시에 기상하여야 한다. A는 알람을 5시에 맞춰 푹자다가 기상하였다. 하지만 B는 알람이 고장나서 편히 잠들지 못하고 수시로 일어나서 시간을 확인하다가 기상하였다. 여기서 콜백함수를 쓴 사람은 A이다. B는 수시로 시간을 구하는 함수를 직접 호출하였지만 A는 알람을 울리는 함수를 호출할 당시에는 아무것도 하지 않다가 정해진 시간이 되었을때 함수를 호출하였다. B는 함수를 호출하는 제어권을 자신이 가지고 있으면서 함수를 호출하였고, A는 제어권을 알람에게 넘겨주고 취침이라는 다른일을 하다가 함수가 호출되었다.

여기서 콜백함수의 중요한 키워드는 제어권이다. 콜백함수는 다른 코드에게 인자와 제어권을 함께 넘겨주게 된다. 콜백함수를 위임받은 코드는 자체적인 내부로직에 의해 이 콜백함수를 적절한 시점에 실행한다. 제어권을 넘겨받은 코드는 (1)호출하는 시점 (2) 인자의 순서 (3)this 지정에 대한 제어권을 획득한다.

1) 호출하는 시점: setInterval이라고 하는 '다른 코드'에 첫번째 인자로 ex1func 함수를 넘겨주자 제어권을 넘겨받은 setInterval이 스스로 판단에 따라 적절한 시점(0.3)에 익명함수를 실행했다. 따라서 콜백함수의 제어권을 넘겨받은 코드는 콜백함수 호출시점에 대한 제어권을 가진다.

호출시점에 대한 제어권

2) 인자의 순서: 밑의 예시를 보면 첫번째 예시에서는 첫번째 인덱스 0 에 대한 콜백함수는 currnetValue에는 10, index에는 0이 담기고 15를 반환한다. 두번째 인덱스 1에 대한 콜백함수는 currentValue에는 20, index에는 1이 담기고 25를 반환한다. 두번째 예시에서 컴퓨터는 순서에 의해서만 각각을 구분하고 인식한다. map 메서드에 정의된 규칙에 따라 함수를 작성해야하며, map메서드에는 콜백함수를 호출할 때 인자의 순서에 대한 정보가 들어있다. 따라서 콜백함수의 제어권을 넘겨받은 코드는 콜백함수를 호출할 때 인자에 어떤값들을 어떤 순서로 넘길 것인지에 대한 제어권을 가진다.

인자의 순서에 대한 제어권

3) this 지정: 밑의 예시에서 마지막인자에 담긴 userData는 call함수의 첫번째 인자로 넘어가게 되어서 this객체가 매핑된다. 콜백함수도 함수이기 때문에 기본적으로 this가 전역객체를 참조하지만, 제어권을 넘겨받을 코드에서 콜백함수에 별도로 this가 될 대상을 지정한 경우에는 그 대상을 참조하게 된다. 따라서 call/ apply 함수를 이용하여 첫번째 인자에 콜백함수 내부에서의 this가 될 대상을 명시적으로 바인딩해야한다.

this 지정에 대한 제어권

2. 콜백지옥이란?

콜백함수를 익명함수로 전달하는 과정이 반복되어 코드의 들여쓰기 수준이 감당하기 힘들정도로 깊어지는 현상을 말한다. 현대의 자바스크립트는 웹의 복잡도가 높아진 만큼 비동기적인 코드의 비중이 예전보다 훨씬 높아진 상횡이며, 비동기적인 코드는 별도의 요청, 실행 대기, 보류 등으로 콜백지옥에 빠지기 훨씬 쉽다.

콜백지옥 예시

해결방법 1) 기명함수로 전환: 기명함수로의 변환은 코드의 가독성을 높인다는 장점이 있지만, 일회성 함수를 전부 변수에 할당해야 하는 것이 반복되고 복잡하여 좋은 방법은 아니다.

기명함수로 전환

해결방법 2) promise 사용: ES6에 등장한 promise를 사용할 수도 있다. new연산자와 함께 호출한 promise의 인자로 넘겨주는 콜백함수는 호출할때 바로 실행되지만 그 내부에 resolve 또는 rejected 함수를 호출하는 구문이 있을 경우 둘 중 하나가 실행되기 전까지는 다음으로 넘어가지 않는다.

promise 사용

해결방법 3) promise + async/await: ES2017에는 가독성이 뛰어나면서도 작성법이 간단한 async/await 기능이 추가되었다. 비동기작업을 하고자하는 함수앞에 async를 표시하고 함수 내부에서 실질적으로 비동기 작업이 필요한 위치마다 await를 표기하면 자동적으로 await 뒤의 내용을 promise로 전환하고 해당내용이 resolve된 이후에야 다음으로 진행한다. promise then과 같은 원리이다.

promise + async/await

✨ 이 글은 정재남님의 코어자바스크립트를 참고하여 작성된 글입니다. 프론트엔드 개발자라면 꼭 사서 읽어보시는 것을 추천드립니다.

[JS] This, Binding

Dev.yeon — Thu, 12 May 2022 15:01:55 +0900

1. This 란?

자바스크립트에서의 this는 상황에 따라 바라보는 대상이 달라진다. 즉, 실행컨텍스트가 생성될때, 함수가 호출될때 결정된다.

1) 전역공간에서의 This: 전역공간에서는 전역객체를 가리키게된다. 브라우저 환경에서 전역객체는 window이고, Node.js에서는 global 이다. 자바스크립트에서 모든 변수는 특정객체의 프로퍼티로서 동작하게되는데, 전역변수를 선언하면 자바스크립트 엔진은 이를 전역객체의 프로퍼티로 할당하게 된다.

전역변수와 전역객체

2) 메서드 내부에서의 this: 메서드 내부에서는 호출한 주체에 대한 정보가 담긴다. 어떤함수를 메서드로서 호출하는 경우 호출주체는 함수명앞의 객체가 된다.

메서드로서 호출

3) 함수내부에서의 this: 함수내부에서는 전역객체를 바라보게 된다. ES6에서는 함수내부에서 this가 전역객체를 바라보는 문제를 보완하고자 this를 바인딩하지 않는 화살표함수를 새로 도입하였고, 그외에도 call, apply, bind의 메서드를 통해 명시적으로 this를 지정할수도 있다. ES5환경에서는 var self 를 선언하여 객체를 바라보게끔 우회해줄수도 있다.

함수내부에서의 this

4) 콜백함수 호출시 함수내부에서의 this: 콜백함수에서는 제어권을 다른함수에게 넘겨주므로, 제어권을 가진함수에서의 내부로직에서 정한 규칙에 따라 값이 결정되게 된다. 콜백함수도 함수이기 때문에 기본적으로 전역객체를 참조하지만, 제어권을 받은 함수에서 콜백함수에 별도로 this가 지정된 경우라면 그 대상을 참조하게 된다. 해당 내용은 콜백함수 게시글에서 자세히 확인할 수 있다.

2022.05.13 - [FrontEnd] - [JS] 콜백함수, 콜백지옥

[JS] 콜백함수, 콜백지옥

1. 콜백함수란? 다른 코드(함수 또는 메서드)에게 인자로 넘겨줌으로써 그 제어권도 함께 위임한 함수이다. 예를들면 A와 B는 토요일 오전 7시에 만나기로 하였다. 둘은 만나기위해 5시에 기상하

yeon-code.tistory.com

5) 생성자 함수 내부에서의 this: 생성자 함수를 호출하면 생성자의 프로토타입 프로퍼티를 참조하는 __proto__라는 프로퍼티가 있는 객체를 만들고, 미리 준비된 속성을 해당 객체에 부여하게 된다. 즉, 인스턴스를 가리키게 된다.

생성자함수

2. 명시적으로 this를 바인딩 하는법

1) call 메서드: 메서드의 호출주체인 함수를 즉시 실행하도록 하는 명령이다. 첫번째 인자를 this로 바인딩하고, 이후 인자들은 호출한 함수의 매개변수로 쓰인다.

call 메서드

2) apply 메서드: call과 기능적인 측면에서 거의동일하나, apply는 두번째 인자를 배열로 받아 그 배열의 요소들을 호출할 함수의 매개변수로 지정을 해준다.

apply 메서드

3) bind 메서드: call과 비슷하지만 즉시 호출하지는 않고 새로운 함수를 반환하기만 하는 메서드이다. 새로운 함수를 호출할때 인수를 넘기면 그 인수든 기존 bind메서드를 호출할때 전달했던 인수들 뒤에 이어서 등록되므로 부분적용함수를 구현할수도 있다.

bind 메서드

4) 화살표함수: ES6에서 새롭게 도입된 화살표함수는 실행컨텍스트 생성시에 this를 바인딩 하지않는다. 따라서 함수 내부에서는 this가 아예 없고, 접근하려면 스코프체인상 가장 가까운 this에 접근하게 된다.

화살표함수

✨ 이 글은 정재남님의 코어자바스크립트를 참고하여 작성된 글입니다. 프론트엔드 개발자라면 꼭 사서 읽어보시는 것을 추천드립니다.

[JS] 실행컨텍스트, 호이스팅, 스코프체인

Dev.yeon — Wed, 11 May 2022 20:35:39 +0900

1. 실행컨텍스트란?

실행컨텍스트는 실행할 코드에 제공할 환경정보를 모아놓은 객체로, 자바스크립트는 실행컨텍스트가 활성화되는 시점에 선언된 변수를 호이스팅하고, 외부환경정보를 구성하고, this값을 설정하는 등의 동작을 수행하게된다. 자바스크립트는 동일한 환경에 있는 코드들을 실행할때 필요한 환경정보들을 모아 컨텍스트를 구성하고, 이를 콜스택에 쌓아올렸다가 가장 위에서부터 실행하여 전체코드의 환경과 순서를 보정하게 된다. 어떤 실행컨텍스트가 활성화될때, 자바스크립트 엔진은 해당 컨텍스트에 관련된 코드들을 실행하는데 필요한 환경정보를 수집해서 실행컨텍스트 객체에 저장하게되는데, 이때 수집하는 정보는 variavle environment, lexical environment, this binding 3가지이다.

Variable Environment	Environment Record: 식별자 정보
Variable Environment	Outer Environment Reference: 선언될 당시의 Lexical 참조
Lexical Environment	Environment Record: 식별자 정보
Lexical Environment	Outer Environment Reference: 선언될 당시의 Lexical 참조
This Binding	this로 지정된 객체

Variable Environment는 현재 컨텍스트 내의 식별자들에 대한 정보와 외부환경정보를 담고있고, 선언시점의 스냅샷이여서 변경사항은 반영되지 않는다. 그에 비해 Lexical Environment는 변경사항이 실시간으로 반영된다. This Binding은 this식별자가 바라봐야할 대상 객체에 대한 정보를 갖게된다.

2. 호이스팅

Environment Record에는 현재 컨텍스트와 관련된 코드의 식별자 정보들이 저장되게되는데, 컨텍스트 내부전체를 처음부터 끝까지 순서대로 수집하게된다. 이때, 코드가 실행되기 전임에도 불구하고 자바스크립트엔진은 식별자에 대한 정보를 갖게되는것이고, 이는 '식별자들을 최상단으로 끌어올려놓은다음 실제코드를 실행한다'라고 할수있는데 이 개념이 호이스팅이다. 호이스팅에서는 변수명만 끌어올리고 할당과정은 그대로 남겨두게된다.

호이스팅 예시

호이스팅에 있어서 함수선언문과 함수표현식의 차이점을 알아야한다. 함수선언문을 사용할 경우에는 함수명이 곧 변수명이기 때문에 함수전체가 호이스팅되지만, 함수표현식은 선언부변수만 호이스팅이 되게된다.

함수선언문과 함수표현식

위의 예시에 의하면 함수선언문은 전체가 호이스팅되어 정상적으로 작동하는 반면에, 함수표현식은 선언부변수만 호이스팅이 되어 런타임오류가 일어난다. 하지만 그럼에도 불구하고 함수표현식을 써야하는 이유는 안전하기 때문이다. 코드가 작성순서에 의하여 차례대로 실행되게끔, 선언 이후의 코드들에서만 안전하게 동작하게끔 해주기 위해서는 함수표현식을 사용하는 것이 좋다.

3. 스코프체인

스코프란 식별자에 대한 유효범위로, ES5까지는 스코프는 오직 함수에 의해 생성이 되었었다. 식별자의 유효범위를 안에서부터 바깥으로 차례대로 탐색해 나가는 것을 스코프체인이라고 한다. Outer Environment Reference는 현재 호출된 함수가 선언될 당시의 Lexical Environment를 참조하게 된다. 즉 A함수 내부에 B함수를 선언했다면, B함수의 Lexical Environment에 존재하는 Outer Environment Reference는 A의 Lexical Environment를 참조하게 되는 것이다. 만약 여러 스코프에서 동일한 식별자를 선언한 경우에는 스코프체인상에서 가장 먼저 발견된 식별자에만 접근 가능하게된다. 여기서 변수은닉화라는 개념이 등장하는데, 함수내부에서 이미 선언한 변수에 대해서는 전역공간에 접근이 불가능한 것을 말한다.

스코프체인 예시

자바스크립트에서 전역변수란 전역컨텍스트의 Lexical Environment에 담긴 변수를 말하며, 지역변수는 그밖의 함수에 의해 생성된 실행컨텍스트의 변수를 말한다. 코드의 안전성을 위해서는 가급적 전역변수의 사용을 최소화하는 것이 좋은데, 그 이유는 전역공간에 같은 변수명의 함수를 선언하더라도 이미 지역변수로 선언을 했다면 코드 대부분이 함수내부에서 동작하게되어 전역공간에서 접근할 수 없게 되기때문이다. ES6에서는 let, const, class, strict와 같은 블록에 의해서도 스코프 경계가 발생한다.

✨ 이 글은 정재남님의 코어자바스크립트를 참고하여 작성된 글입니다. 프론트엔드 개발자라면 꼭 사서 읽어보시는 것을 추천드립니다.

[JS] 자바스크립트 데이터 타입

Dev.yeon — Wed, 11 May 2022 15:01:22 +0900

1. 자바스크립트의 데이터 타입: 기본형과 참조형

자바스크립트의 데이터 타입에는 2가지가 있다. 기본형(prototype)과 참조형(refrence type)이다.

기본형	Number, String, Boolean, null, undefined, Symbol
참조형	Array, Function, Date, Map, Set, RegExp

기본형은 불변값이고, 참조형은 보통 가변값이다. 컴퓨터는 데이터를 늘릴경우를 대비하기 위해, 중복데이터에 대해 효율성을 높이기 위해 변수영역과 데이터 영역을 분리하게 된다. 기본형이 불변값인 이유는 기본값에서의 변경이 새로 만드는 동작을 통해서만 이루어지기 때문이다. 반면에 참조형은 기본형과는 달리 객체의 변수영역이 별도로 존재하여 다른값을 얼마든지 대입할수있고, 데이터 영역에 저장된 값은 모두 불변값이다. 따라서 가변값이라고 부르는것이고, 재할당 명령을 내릴시에 참조카운트가 0인 이전 메모리 주소는 가비지 콜렉터가 수거해가게된다.

참조형 데이터의 할당

2. 기본형과 참조형의 변수복사

기본형은 복사를 할때 값이 담긴 주소값을 바로 복제하게되지만, 참조형은 값이 담긴 주소값들로 이루어진 묶음을 가리키는 주소값을 복제하게된다. 따라서 기본형은 객체의 프로퍼티를 변경시에 서로 다른 주소를 바라보게 되지만, 참조형데이터는 여전히 같은 주소를 바라보게 된다. 참조형데이터를 불변객체로 만들기 위해서, 얕은복사와 깊은복사의 개념에 대해 알아야한다. 얕은 복사는 바로 아래단계의 값만을 복사하는 방법이고, 깊은 복사는 내부의 모든값을 모두 찾아서 전부 복사하는 방법이다. 얕은 복사를 시행할 경우 깊이가 1인 기본형 프로퍼티만 있다면 문제가 되지 않겠지만, 참조형 데이터가 프로퍼티로 있을 경우에는 다시 재귀적으로 내부의 프로퍼티까지 모두 복사를 해주는 깊은 복사를 해주어야 문제가 생기지 않는다.

기본형과 참조형의 복사 비교

얕은복사를 하기 위해서는 1) assign함수이용 2) 전개연산자 이용 이렇게 2가지의 방법이 있다.

얕은복사 방법

깊은 복사를 하기위해서는 1) 깊은복사를 시행하는 재귀함수를 생성 2)String을 Json으로 변환 3) loadash 라이브러리를 사용 이렇게 3가지 방법이 있다.

깊은복사방법

3. undefined 와 null

자바스크립트에는 '없음'을 나타내는 값에 undefined와 null 2가지가 있다. undefined는 사실 사용자가 지정할수도 있겠지만, 보통 자바스크립트 엔진이 값이 존재하지 않을 때 자동으로 부여하게 된다. 값을 대입하지 않아서 데이터 영역의 메모리 주소를 지정하지 않은 식별자에 접근할때, 객체 내부에 존재하지 않는 프로퍼티에 접근하려할때, return문이 없거나 호출되지 않는 함수의 실행결과에는 undefined가 부여된다. null은 '비어있음'을 명시적으로 나타내고 싶을때 사용자가 할당하는 값이다. 이 두가지를 혼용하지 않기 위해서는 undefined를 명시적으로 할당하지 않기만하면된다. 다만, null을 쓸때 주의할점은 typeof(null)은 object라는 결과를 반환하는 자바스크립트 버그있기때문에 어떤 변수값이 null인지 확인하기 위해서는 동등연산자가 아닌 일치연산자로 비교를 해주어야한다.

null과 undefined 비교

✨ 이 글은 정재남님의 코어자바스크립트를 참고하여 작성된 글입니다. 프론트엔드 개발자라면 꼭 사서 읽어보시는 것을 추천드립니다.

[python] BOJ 백준 21610: 마법사상어와 비바라기

Dev.yeon — Fri, 29 Apr 2022 23:42:41 +0900

1. 문제

마법사 상어는 파이어볼, 토네이도, 파이어스톰, 물복사버그 마법을 할 수 있다. 오늘 새로 배운 마법은 비바라기이다. 비바라기를 시전하면 하늘에 비구름을 만들 수 있다. 오늘은 비바라기를 크기가 N×N인 격자에서 연습하려고 한다. 격자의 각 칸에는 바구니가 하나 있고, 바구니는 칸 전체를 차지한다. 바구니에 저장할 수 있는 물의 양에는 제한이 없다. (r, c)는 격자의 r행 c열에 있는 바구니를 의미하고, A[r][c]는 (r, c)에 있는 바구니에 저장되어 있는 물의 양을 의미한다.

격자의 가장 왼쪽 윗 칸은 (1, 1)이고, 가장 오른쪽 아랫 칸은 (N, N)이다. 마법사 상어는 연습을 위해 1번 행과 N번 행을 연결했고, 1번 열과 N번 열도 연결했다. 즉, N번 행의 아래에는 1번 행이, 1번 행의 위에는 N번 행이 있고, 1번 열의 왼쪽에는 N번 열이, N번 열의 오른쪽에는 1번 열이 있다.

비바라기를 시전하면 (N, 1), (N, 2), (N-1, 1), (N-1, 2)에 비구름이 생긴다. 구름은 칸 전체를 차지한다. 이제 구름에 이동을 M번 명령하려고 한다. i번째 이동 명령은 방향 di과 거리 si로 이루어져 있다. 방향은 총 8개의 방향이 있으며, 8개의 정수로 표현한다. 1부터 순서대로 ←, ↖, ↑, ↗, →, ↘, ↓, ↙ 이다. 이동을 명령하면 다음이 순서대로 진행된다.

모든 구름이 di 방향으로 si칸 이동한다.
각 구름에서 비가 내려 구름이 있는 칸의 바구니에 저장된 물의 양이 1 증가한다.
구름이 모두 사라진다.
2에서 물이 증가한 칸 (r, c)에 물복사버그 마법을 시전한다. 물복사버그 마법을 사용하면, 대각선 방향으로 거리가 1인 칸에 물이 있는 바구니의 수만큼 (r, c)에 있는 바구니의 물이 양이 증가한다.
- 이때는 이동과 다르게 경계를 넘어가는 칸은 대각선 방향으로 거리가 1인 칸이 아니다.
- 예를 들어, (N, 2)에서 인접한 대각선 칸은 (N-1, 1), (N-1, 3)이고, (N, N)에서 인접한 대각선 칸은 (N-1, N-1)뿐이다.
바구니에 저장된 물의 양이 2 이상인 모든 칸에 구름이 생기고, 물의 양이 2 줄어든다. 이때 구름이 생기는 칸은 3에서 구름이 사라진 칸이 아니어야 한다.

M번의 이동이 모두 끝난 후 바구니에 들어있는 물의 양의 합을 구해보자.

2. 입력

첫째 줄에 N, M이 주어진다.

둘째 줄부터 N개의 줄에는 N개의 정수가 주어진다. r번째 행의 c번째 정수는 A[r][c]를 의미한다.

다음 M개의 줄에는 이동의 정보 di, si가 순서대로 한 줄에 하나씩 주어진다.

3. 출력

첫째 줄에 M번의 이동이 모두 끝난 후 바구니에 들어있는 물의 양의 합을 출력한다.

4. 해결방법

이 문제는 구현, 시뮬레이션 문제이다. 구름배열과 바구니 격자배열을 계속해서 업데이트 해주면서 각 단계를 진행하면된다. 다만 각 단계에서 구름이 이미 생성된 칸에 대해서 정보를 계속해서 가지고 있어야하므로 방문배열 visited를 생성해서 관리를 해주어야한다. 기존 배열에서 들어있는지를 확인하는 in 함수를 쓰게된다면 O(n)의 시간이 걸려서 시간초과가 일어나게되기 때문이다.

1) move함수: 방향 d에 대해서 s만큼 이동한다. 다만 행과열을 각각 이어져있다고 하였으므로 범위가 넘어가다면 각 끝점으로 다시 이어주어야한다. 또한 여기서 방문체크를 해주는 배열을 같이 계산하여 리턴을 해주어야 5단계의 구름생성에서 활용할 수 있다.

2) rain 함수: 구름이 있는 곳에 대해서 물의 양을 1씩 증가시켜준다. 그 후에 물복사를 실시하여 대각선을 탐색해준다. 이때 임시배열을 만들고 증가시킬 물의양을 따로 저장해주어야 계산오류가 나지않는다. 한번에 적용시켜준다면 동시성에 어긋나므로 계산오류가 일어나게 된다.

3) make_cloud 함수: 물이 2이상이고 move함수에서 리턴한 방문배열에서 체크가 안되어있다면 구름이 생성가능한 부분이다. 새로운 배열에 저장해주고 리턴해준다음, 메인함수에서 원래의 구름배열에 저장해주면된다.

5) 구현코드

n,m=map(int,input().split())
a=[list(map(int,input().split()))for _ in range(n)] #격자 
commands=[list(map(int,input().split())) for _ in range(m)] #명령
cloud=[(n-1,0),(n-1,1),(n-2,0),(n-2,1)] #구름배열 

#8가지 방향 
dx=[0,-1,-1,-1,0,1,1,1]
dy=[-1,-1,0,1,1,1,0,-1]

#1단계: 구름이동 
def move(d,s):
  #5단게를 위해 저장할 방문여부 배열 
  visited=[[0]*n for _ in range(n)]
  d-=1 #방향 
  for i in range(len(cloud)):
    x,y=cloud[i] #구름좌표 
    for _ in range(s): #s만큼이동 
      x,y=x+dx[d],y+dy[d]
      #경계를 넘어가는건 이어주기 
      if x<0: x=n-1
      if x>=n: x=0
      if y<0: y=n-1
      if y>=n : y=0 
    cloud[i]=(x,y) #구름좌표 업데이트 
    visited[x][y]=1 #방문체크 
  return visited #방문배열 리턴 

#2,4단계: 물증가, 물복사버그 
def rain():
  temp=[]
  #2단계: 비오기 
  for x,y in cloud:
    a[x][y]+=1#물증가 

  #4단계: 물복사마법 실시   
  for x,y in cloud:
    cnt=0 #대각선 물개수  
    for i in [1,3,5,7]: #대각선 
      nx,ny=x+dx[i],y+dy[i] 
      if 0<=nx<n and 0<=ny<n:#범위안 
        if a[nx][ny]>0: #물있으면 
          cnt+=1 #개수증가 
    temp.append((x,y,cnt)) #임시배열에 저장 
  for x,y,cnt in temp:
      a[x][y]+=cnt #물복사

#3,5단게: 새로운 구름생성 
def make_cloud(cloud,visited):
  temp=[] #새로운 구름배열 
  for i in range(n):
    for j in range(n):
      #물이 2이상이고 예전에 구름이 아닌칸
      if a[i][j]>=2 and visited[i][j]==0:
        temp.append((i,j)) #구름생성 
        a[i][j]-=2 #물의양 줄기 
  return temp 


for d,s in commands:
  visited=move(d,s) 
  rain()
  cloud=make_cloud(cloud,visited)

answer=0
for i in range(n):
  answer+=sum(a[i])
print(answer)

⭐️난이도: 골드 5 ⭐️

https://www.acmicpc.net/problem/21610

21610번: 마법사 상어와 비바라기

마법사 상어는 파이어볼, 토네이도, 파이어스톰, 물복사버그 마법을 할 수 있다. 오늘 새로 배운 마법은 비바라기이다. 비바라기를 시전하면 하늘에 비구름을 만들 수 있다. 오늘은 비바라기