다음주에 인턴으로서 첫 출근을 한다.

난 백엔드보다 프론트엔드를 잘 한다고 생각했는데 막상 프론트에선 다 떨어지고 백엔드쪽 일을 하게 됐다. 음 신의 뜻이라고 생각하고 백엔드도 열심히 공부해봐야겠다.

다소 걱정되는 건 지금까진 난 Express.js나 NestJS 위주로만 백엔드 작업을 했지만 회사는 파이썬이랑 코틀린을 쓴다는 점이다. 물론 정글때도 코치님들께서는 실제론 언어는 금방 배우니까 문제 해결능력이 더 중요하다~ 는 뉘앙스로 말씀을 많이 해 주셨다. 일단 마음가짐이 더 중요할려나 싶다.

면접때 매일 인천에서 서울 왔다갔다하니 너무 피곤했다. 결국엔 단기로 방을 잡게 됐다. 사당 낙성대는 너무 비싸서 결국 구로디지털단지로 가게됐다. 참 방의 위치가 묘한 게 역이름은 구로구고 실제 주소는 관악구인데 횡단보도 하나만 지나면 금천구다.

그리고 지금까지 정글-취준 달려오면서 운동을 너무 안 했다. 그래서인지 너무 저질체력이 되는 것 같아, 새로 자취생활 시작하면 꾸준히 헬스장 좀 가려고 한다. PT 다시 받는것도 생각중이다... 개발자에게 제일 중요한 덕목은 똑똑함도 아니고, 문제 해결력도 아니고, 소통능력도 아니고, 체력인 것 같다.

이번 글은 Next.js의 제일 큰 특징인 사전 렌더링을 다룹니다.

참고: 인프런 - 한 입 크기로 잘라먹는 Next.js

프레임워크 vs 라이브러리

Next.js는 React 라이브러리를 기반으로 한 프레임워크라고 생각하면 됩니다.

이때 라이브러리와 프레임워크의 차이가 헷갈리실 수 있는데, 이런 차이가 있습니다.

• 라이브러리: 기능 구현의 주도권이 개발자에 있어서 자유로움
• 프레임워크: 기능 구현의 주도권이 프레임워크에 있어서, 정해놓은 대로 구현하는 것이 권장됨

이를테면, React에서는 페이지 라우팅을 할 때 React Router나 Tanstack Router 등 별도 라이브러리 중 적당한 친구를 골라서 사용하면 됩니다. 대신 React 자체적으로는 라우팅 기능을 제공하지 않습니다. 구현할 방법은 다양하지만, 선택하는 건 개발자의 몫이죠.

하지만 Next.js 사용 시, 자체적으로 제공하는 Page/App Router를 통해 페이지 라우팅을 구현하는 것이 권장됩니다. 대신 별도 설정 없이 바로 사용 가능하다는 장점이 있습니다.

그 외에 Next.js에는 이미지나 폰트의 용량 최적화, TypeScript 기본 지원, API Routes를 통한 백엔드 서버의 기능 구현 등등 기능이 추가되어 있습니다. 그러므로 프로젝트를 단기간에 진행해야 할 때는, 주어진 기능이 많고 정해진 틀만 지키면 되는 Next.js가 훨씬 효율적입니다.

기존 리액트 Client Side Rendering

기존 글에 리액트는 Client Side Rendering으로 작동한다고 언급을 했었는데요,

간단히 요약하자면 클라이언트에서 직접 화면을 렌더링하는 방식이였죠.

우선 서버는 브라우저에 내용이 없는 index.html 파일을 보내고, 브라우저가 이를 렌더링합니다. 일단 빈 화면만 보이겠죠.

하지만 그 이후 서버가 브라우저에 JS 파일을 묶은 하나의 번들 파일인 React App을 보냅니다. 브라우저는 React App을 실행하여 콘텐츠를 렌더링하게 됩니다.

초기 접속만 되면, 페이지 이동이 빠르고 쾌적하다는 장점이 있었습니다. 페이지를 이동할 때마다, 서버를 거치지 않고 React App만 실행하면 되니까요.

하지만 초기 접속을 할 때, 요청 시작부터 화면 렌더링 시점까지 시간이 오래 소요된다는 단점이 있습니다. 이를 First Contentful Paint(FCP)라고도 부릅니다. 일단 빈 index.html 파일을 받고, 서버에서 React App도 받고, 이걸 뒤늦게 렌더링하는 과정에서 초기 시간이 다소 소요됩니다.

넥스트의 사전 렌더링

넥스트는 이러한 CSR의 장점은 유지하면서, FCP가 느린 단점을 보완하기 위해 서버 측에서 사전 렌더링을 하는 기능을 지원합니다.

이때 렌더링은, 앞선 CSR처럼 브라우저에 내용을 그린다는 의미가 아닌, 서버가 JS 코드를 HTML로 변환한다라는 뜻임에 유의합시다.

유저가 초기 접속을 하면, 빈 껍데기인 index.html만 보내주는 리액트와 다르게, 넥스트에서는 서버가 사전에 내용이 채워진 HTML 파일을 응답하도록 설정할 수 있습니다.

• 서버가 리액트 컴포넌트 등이 포함된 JS 코드를 실행해, 이를 HTML로 변환합니다.
• 이렇게 서버가 사전에 렌더링한 HTML을 브라우저로 보냅니다.
• 브라우저는 해당 파일을 화면에 표시합니다.

이 시점에서 사용자가 화면을 볼 수 있으므로, 기존 리액트에 비해 FCP가 훨씬 빨라진다는 장점이 있습니다.

Hydration

물론 HTML 파일만 있으면 버튼 클릭과 같은 상호작용적인 요소가 먹히지 않을 겁니다. 이때 넥스트는 React 기반이라는 점 다시 기억해 봅시다. 그러므로 JS 번들 파일인 React App도 여전히 존재합니다.

FCP 이후 서버는 브라우저에 React App을 보내게 되고, 이후 React App이 기존 HTML 코드와 연동됩니다. 이를 황무지와 같은 HTML에 물을 준다는 느낌으로, Hydration이라고도 부릅니다. 이렇게 초기 접속으로부터 사용자가 첫 상호작용을 할 수 있기까지의 시간을 TTI(Time to Interact)로도 부릅니다.

/cv 페이지              /projects 페이지
┌──────────────┐       ┌──────────────┐
│   Header    │       │   Header    │ <- 유지
├──────────────┤  -->  ├──────────────┤
│             │       │             │
│  CV         │       │   Projects  │ <- 너만 교체
│             │       │             │
├──────────────┤       ├──────────────┤
│   Footer    │       │   Footer    │ <- 유지
└──────────────┘       └──────────────┘
+ 이 과정에서 서버 요청은 이루어지지 않음

페이지 이동을 하는 경우 역시 기존 리액트와 마찬가지로, 서버까지 가지 않고 Hydration된 React APP을 통해 브라우저가 컴포넌트를 교체하는 CSR 방식으로 이루어집니다. 즉 페이지 이동이 빠르고 쾌적하다는 React CSR의 장점이 유지된다는 것도 중요한 특징이겠죠.

Hydration Error

가끔가다 Next.js에선 Hydration Error라는 친구를 마주칠 수 있습니다. 이 에러는 서버에서 생성한 HTML과, 클라이언트에서 React가 렌더링한 결과가 일치하지 않을 때 발생합니다.

• JSX 리턴문 내부에 서버는 이해 못하고 브라우저만 이해하는 window, document, localStorage가 포함되어 있거나
• JSX 리턴문 내부에 랜덤 값이나 현재 시간처럼, 서버 생성 / 클라이언트 렌더링 시점에 달라질 수 있는 값이 있거나
• <p> 안에 <div>를 넣는 등 HTML을 잘못 중첩했거나 (서버는 수정 안하는데, 브라우저는 자동 수정해서 불일치 발생)

할 때 발생합니다. 기본적으로 서버는 컴포넌트의 JSX 리턴분에 있는 HTML을 사전 렌더링하니까, 거기에 문제되는 값이 들어가면 안 됩니다.

즉 랜덤 값이나 window 같은 브라우저 전용 코드는, 서버가 사전 렌더링하지 않는 useEffect를 통해 처리하면 이런 오류를 막을 수 있습니다. 서버가 렌더링 안하니까, 불일치가 뜰 일도 없겠죠.

// 서버엔 window가 없으므로, JSX 리턴문에 넣으면 안됨
function Component() {
  return <div>{window.innerWidth}</div>  // 서버에는 window가 없음!
}

// useState로 분리해 놔야 함
function Component() {
  const [width, setWidth] = useState(null);

  useEffect(() => {
    setWidth(window.innerWidth);  // 브라우저에서만 실행
  }, []);

  return <div>{width || '로딩중...'}</div>;
}

사전 렌더링의 여러가지 방식

재미있게도 Next.js에서 사전 렌더링을 할 수 있는 방법도 하나가 아닙니다. 좀 많습니다.

• SSG(Static Site Generation): 웹사이트를 빌드할 때 HTML을 미리 생성하고, 요청이 오면 서버가 미리 만들어진 HTML을 바로 전달합니다.
  • 즉 요청이 오기 전에 이미 완성본이 있으므로, 아주 빠릅니다.
  • 블로그 내용이나 문서처럼 내용이 자주 바뀌지 않을 때 적당하겠죠.
• SSR(Server Side Rendering): 요청 시점마다 서버가 HTML을 생성합니다.
  • 매 요청마다 렌더링하므로 SSG보단 느리지만, 경매 사이트처럼 실시간 데이터를 API로 받아오는 페이지 같은 경우에는 이런 방식을 사용해야겠죠.
• ISR(Incremental Static Regeneration): 빌드 타임에 HTML을 생성하되, 일정 시간마다 백그라운드에서 재생성
  • 주기적으로 업데이트되는 사이트에서는 이걸 쓰면 좋습니다. 뉴스라든가, 전날 야구 스코어라든가를 이렇게 처리할 수 있겠네요.

SSR은 Song Sang Rok이 아니라 Server Side Rendering을 뜻합니다.

페이지 라우팅

라우팅이란 사용자가 요청한 경로에 따라 적절한 페이지를 보여주는 기능입니다.

이를테면, https://strawberry-tree.github.io/cv로 접속하면 CV 페이지가, https://strawberry-tree.github.io/projects로 접속하면 프로젝트 페이지를 보여줘야겠죠.

라우팅이 이루어지는 원리에 따라, 웹사이트는 MPA(multi page application)과 SPA(single page application)으로 나눌 수 있습니다.

MPA(Multi Page Application)

MPA 방식의 웹사이트에선, 서버에 이미 여러 개의 완성된 html 페이지가 존재합니다. 브라우저가 경로를 요청하면 서버가 해당 페이지를 찾아 반환하게 됩니다.

SSR (Server Side Rendering)

일반적으로 MPA 방식에서 페이지 내용을 화면에 렌더링하는 데는 SSR이 사용되는데요, 이는 서버가 렌더링을 한다는 뜻입니다. 서버가 미리 완성된 html 파일을 만들어 브라우저에 전송하고, 브라우저가 그대로 화면에 띄우게 됩니다.

이때 MPA와 SSR은 흔히 함께 쓰이지만 동일 개념은 아닙니다. MPA는 서버에 여러 페이지가 존재하는 구조, SSR은 그 페이지를 서버에서 완성해서 보내주는 렌더링 방식을 의미합니다.

MPA 방식의 단점

MPA 방식은 쾌적한 페이지 이동 경험에 방해가 된다는 단점이 있습니다. 그 이유를 2가지로 정리해 보자면,

1. 비효율적인 페이지 이동

/cv 페이지              /projects 페이지
┌──────────────┐       ┌──────────────┐
│   Header    │       │   Header    │ <- 동일한데 재렌더링
├──────────────┤  -->  ├──────────────┤
│             │       │             │
│  CV         │       │   Projects  │ <- 재렌더링
│             │       │             │
├──────────────┤       ├──────────────┤
│   Footer    │       │   Footer    │ <- 동일한데 재렌더링
└──────────────┘       └──────────────┘

MPA 방식에서는 페이지를 이동할 때마다, 화면 전체에 렌더링된 내용이 모두 제거되고, 새로운 페이지를 처음부터 다시 렌더링됩니다.

그러니까 헤더, 푸터 등 모든 페이지에 들어가는 공통 요소도 매번 다시 그려지므로 비효율적입니다. 렌더링 과정에서 페이지 전체가 한번 깜빡이는 게 이런 이유 때문이죠.

2. 서버 부하 증가

MPA 방식에서는 페이지를 이동할 때마다 서버에 새 페이지를 요청합니다. 즉, 사용자가 많아질수록 서버 부하가 심해집니다.

SPA (Single Page Application)

React는 페이지 이동 시 MPA의 단점을 해결하기 위해, SPA 방식을 채택했습니다.

SPA의 경우 서버에 페이지가 단 하나 (index.html) 존재합니다. 추가로 React 컴포넌트나 각종 유틸리티 함수가 담긴 별도의 JavaScript 파일들도 존재합니다.

절대로 사용자가 접근할 수 있는 페이지가 하나라는 뜻이 아닙니다. (저도 맨 처음에 이게 헷갈려서 리액트로는 페이지를 하나 밖에 못 만드나? 싶은 줄 알았습니다.)

CSR (Client Side Rendering)

사용자가 어떤 경로로 접속하든, 이러한 과정을 따릅니다.

• 1단계 서버는 항상 index.html을 반환하고, 브라우저는 먼저 index.html을 렌더링한다
  • 이때 index.html엔 JS 파일을 실행하는 태그만 있습니다. 즉 index.html엔 아무 내용이 없어, 아주 잠깐 빈 화면이 뜨게 됩니다.
• 2단계 서버는 모든 React 컴포넌트/유틸리티에 사용되는 JS 파일들을 하나의 번들 파일로 묶어 브라우저로 전달한다
  • 이러한 번들링 과정을 Vite 같은 친구들이 해 줍니다
  • 이러한 번들 파일을 React 앱으로도 부릅니다
• 3단계 브라우저는 번들 파일을 실행하며, <App> 컴포넌트부터 순서대로 렌더링한다

이와 같이 서버가 아니라 브라우저가 화면에 뜨는 요소를 렌더링하며, 이를 CSR(Client-Side Rendering)이라 합니다. MPA와 SSR의 관계랑 비슷하게, SPA는 페이지 구조, CSR은 렌더링 방식이고 동일한 개념이 아님에 유의합시다.

페이지 이동 시

/cv 페이지              /projects 페이지
┌──────────────┐       ┌──────────────┐
│   Header    │       │   Header    │ <- 유지
├──────────────┤  -->  ├──────────────┤
│             │       │             │
│  CV         │       │   Projects  │ <- 너만 교체
│             │       │             │
├──────────────┤       ├──────────────┤
│   Footer    │       │   Footer    │ <- 유지
└──────────────┘       └──────────────┘
+ 이 과정에서 서버 요청은 이루어지지 않음

기존 MPA 방식에서는 페이지를 이동할 때마다 전체 페이지를 없애고 다시 렌더링해야 했지만, SPA 방식에서는 React 앱(JS 번들 파일)을 이용해 브라우저가 자체적으로 필요한 컴포넌트만 교체합니다.

그러므로 헤더, 푸터 등 모든 페이지에서 동일한 컴포넌트는 그대로 남아 있고, 바뀌는 컴포넌트만 즉시 불러와 화면에 보여주게 됩니다.

결국에는 페이지 이동이 매끄럽고 빠르며, 서버에도 요청이 전혀 가지 않기 때문에 서버 부하도 줄어듭니다.

실전에서는

흔히는 React Router 같은 패키지로 페이지 라우팅을 구현합니다. 이런 패키지는 (1)컴포넌트가 현재 브라우저의 주소를 읽어올 수 있게, 그리고 (2)컴포넌트가 주소의 변화를 감지할 수 있게 처리해 줍니다.

function App() {
  return (
    <>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/new" element={<New />} />
        <Route path="/diary" element={<Diary />} />
        <Route path="*" element={<NotFound />} />
      </Routes>
    </>
  );
}

얘를 들어 이런 코드에서는, 주소가 /new 에서 /diary로 바뀌면 App 컴포넌트 내부의 New 컴포넌트가 Diary 컴포넌트로 교체되게 됩니다.

SSR, CSR 모두 지원하는 Next.js

특이하게 저의 최애 프레임워크인 Next.js 같은 경우는 SSR과 CSR의 장점을 모두 활용할 수 있습니다.

첫 페이지 로드는 SSR로 완성된 HTML을 받아오고, 이후 페이지 이동은 CSR 방식으로 필요한 부분만 바꿔주는 식이죠.

예를 들어 프로젝트 목록 페이지로 이동한다면...

1단계 사용자가 /projects로 이동하면, 필요한 <ProjectsPage> 컴포넌트만 불러옵니다. 헤더, 푸터 등 공통 컴포넌트는 그대로 유지됩니다.

2단계 <ProjectsPage> 안에 <ProjectList>라는 서버 컴포넌트(Server Component)가 있다고 합시다.

• 이 <ProjectList>는 DB에서 프로젝트 목록 데이터를 가져와야 합니다.
• 서버가 DB에서 데이터를 미리 조회해서, <ProjectList>를 완성된 HTML 형태로 만들어 보내줍니다.

3단계 브라우저가 HTML을 받으면, 로딩 화면 없이 바로 프로젝트 목록이 표시됩니다.

순수 CSR과 비교

일반 React(순수 CSR)에서는:

• 빈 화면 렌더링 → 브라우저가 API 호출 → 로딩 표시 → 내용 표시

Next.js의 SSR에서는:

• 서버가 미리 데이터 조회 + 렌더링 → 완성된 화면 바로 표시

물론 서버에서 렌더링하는 시간도 걸리긴 하지만, 서버-DB 간 통신이 빠른 경우가 많아서 대부분 사용자 체감 속도가 더 빠릅니다. 특히 의미있는 콘텐츠를 빈 화면 대신 먼저 보여줄 수 있는게 장점입니다.

그래서 Next.js에선 페이지 이동은 빠르게(CSR), 데이터는 미리 준비해서(SSR) 보여주는 등 상황에 맞게 선택할 수 있습니다. 우와~~

메모이제이션

한 4달전쯤 크래프톤 정글에서 다이나믹 프로그래밍을 공부하면서 메모이제이션을 처음 접했는데요,

앞서 이미 계산한 값을 반복해서 계산하는 대신, 배열 같은 자료구조에 저장해 두고 필요할 때 다시 써먹는 방법이였죠.

리액트에서도 비슷하게 메모이제이션을 활용 가능합니다. 값/함수/컴포넌트를 메모리에 저장해두어, 불필요한 연산과 리렌더링을 방지하는 것이죠

참고 - 한 입 크기로 잘라 먹는 리액트, 인프런

useMemo - 값 최적화

const memoizedValue = useMemo(() => {
  return 계산할값;
}, [의존성]);

useMemo는 값의 불필요한 재계산을 방지하는Hook입니다. 처음 계산된 결과를 메모리에 저장하고, 이후 컴포넌트가 리렌더링되더라도 의존성 배열의 값이 바뀌지 않으면 재계산 없이 저장값을 그대로 반환합니다.

다만, 의존성 배열에 포함된 값이 변경되면 해당 계산을 다시 수행합니다.

import { useState, useMemo } from "react";

function Example() {
  const [count, setCount] = useState(0);
  const [text, setText] = useState("");

  const double = useMemo(() => {
    return count * 2;
  }, [count]);

  return (
    <div>
      <p>count: {count}</p>
      <p>double: {double}</p>
      <button onClick={() => setCount(count + 1)}>+1</button>
      <input
        value={text}
        onChange={(e) => setText(e.target.value)}
        placeholder="텍스트 입력"
      />
    </div>
  );
}

위 코드 같은 경우 텍스트를 <input>에 입력해 text state가 변경되면 Example 컴포넌트가 리렌더링됩니다. 하지만 double이 재계산되지는 않습니다. 변수 count는 그대로기 때문입니다.

React.memo - 컴포넌트 최적화

export default React.memo(컴포넌트명);

React.memo는 컴포넌트의 불필요한 재렌더링을 방지하며, 컴포넌트에 감싸서 사용합니다. 처음 렌더링할 때 결과를 메모리에 저장하고, 이후 컴포넌트가 리렌더링되더라도 props가 변하지 않으면 저장된 렌더링 결과를 재사용합니다.

다만, props가 변경되면 컴포넌트가 재렌더링됩니다.

const Child = React.memo(({ value }) => {
  return <div>{value}</div>;
});

function Parent() {
  const [count, setCount] = useState(0);
  return (
    <>
      <Child value="고정된 값" />
      <button onClick={() => setCount(count + 1)}>+</button>
    </>
  );
}

위 코드 같은 경우 button을 클릭하면 count가 변경되어 Parent가 리렌더링되더라도, React.memo로 감싼 Child는 리렌더링되지 않습니다. 전달되는 prop인 value가 그대로기 때문입니다.

useCallback - 함수 최적화

const memoizedFunc = useCallback(콜백함수, [의존성]);

useCallback은 함수의 불필요한 재생성을 방지하는 훅입니다. 함수도 JS 객체이기 때문에, 함수를 포함하는 컴포넌트가 리렌더링될 시 함수 내부 코드는 동일해도 별도의 객체로 재생성됩니다. 이러한 현상을 방지하기 위해서 useCallback을 사용하며, 이후 컴포넌트가 리렌더링되더라도 의존성 배열의 값이 바뀌지 않으면 함수를 다시 생성하지 않습니다.

다만, 의존성 배열에 포핟된 값이 변경되면 해당 함수를 재생성합니다.

참고로 useCallback(콜백함수, 의존성배열)은 useMemo(() => 콜백함수, 의존성배열)과 동일한 동작을 합니다. 하지만 깔끔한 코드를 위해선 useCallback을 쓰는 게 더 좋겠죠.

import { useState, useCallback } from "react";

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

  const increment = useCallback(() => {
    setCount((prev) => prev + 1);
  }, []);

  return <button onClick={increment}>+1</button>;
}

위 코드의 경우, button을 눌러 count state가 변경되어 Example 컴포넌트가 다시 렌더링되어도, increment 함수가 다시 생성되지 않습니다. 의존성 배열이 비어 있어서, 처음 렌더링될 때 빼고는 절대로 함수가 다시 생성되지 않아요.

최적화는 언제, 어떻게 해야 해요?

우선 프로젝트 기능을 구현하고, 최적화는 맨 마지막에 하는 것이 권장됩니다. 이런 최적화 방법을 처음부터 적용하면, 추가로 기능을 구현할 시 코드가 복잡해져서 유지보수가 어려워질 수 있습니다.

그리고 꼭 모든 컴포넌트/값/함수에 최적화를 하기보단, 필수적인 코드에만 하는 게 권장됩니다. 메모이제이션 시 의존성 배열의 값이나 props가 변경되었는지 확인해야 하므로 오버헤드가 발생하기 때문입니다.

최적화가 필요한 경우

• 배열의 아이템처럼, 무한히 증가할 수 있는 컴포넌트. 개수가 많아질수록 배열을 순회하면서 렌더링할 때 성능에 영향을 줍니다.
• 복잡한 수학 계산, 데이터 변환, 필터링 등 오래 걸리는 작업.

최적화가 불필요한 경우

• 헤더, 푸터처럼 단순 HTML만 렌더링하는 컴포넌트
• 리렌더링 빈도가 낮은 컴포넌트
• 사칙연산과 같은 간단한 계산만 이루어지는 컴포넌트

웹사이트 링크

참고로 원랜 이랬어요.

사실 제가 짠건 아니고 AI 시킨 건데, 적어도 내용은 복습해야 할 것 같아서 올려봅니다.

위에선 "뭔갈 만드는 걸 좋아하는", "송상록", "입니다"를 별도의 TypingEffect.jsx 컴포넌트로 처리해 줍니다

// TypingEffect.jsx
'use client'

import { useEffect, useState } from 'react'

interface TypingEffectProps {
  text: string              // 타이핑할 전체 텍스트
  delay?: number           // 각 글자 사이 지연 시간 (ms)
  className?: string       // 스타일 클래스
  onComplete?: () => void  // 타이핑 완료 시 실행할 콜백
  startDelay?: number      // 타이핑 시작 전 대기 시간 (ms)
}

export default function TypingEffect({
  text,
  delay = 100,
  className = '',
  onComplete,
  startDelay = 0,
}: TypingEffectProps) {
  // 화면에 실제로 표시되는 텍스트
  const [displayedText, setDisplayedText] = useState('')
  // 현재까지 출력된 글자의 인덱스
  const [currentIndex, setCurrentIndex] = useState(0)
  // 시작 지연 후 타이핑이 시작되었는지 여부
  const [started, setStarted] = useState(false)

  useEffect(() => {
    // startDelay가 설정되어 있고 아직 시작 안 했으면
    if (startDelay > 0 && !started) {
      const startTimeout = setTimeout(() => {
        setStarted(true)    // 지연 시간 후 시작
      }, startDelay)
      // 컴포넌트 재렌더링 후 이전 타이머 남아있는 것을 방지 (cleanup)
      return () => clearTimeout(startTimeout)
    } else if (startDelay === 0) {
      setStarted(true)        // 지연이 없으면 바로 시작
    }
  }, [startDelay, started])

  // 타이핑 효과
  useEffect(() => {
    if (!started) return

    // 아직 출력할 글자가 남아있으면
    if (currentIndex < text.length) {
      const timeout = setTimeout(() => {
        // 현재 인덱스의 글자를 displayedText에 추가
        setDisplayedText((prev) => prev + text[currentIndex])
        // 다음 글자로 이동
        setCurrentIndex((prev) => prev + 1)
      }, delay)

      return () => clearTimeout(timeout)
      // 모든 글자 출력 완료 시 콜백 실행
    } else if (currentIndex === text.length && onComplete) {
      onComplete()
    }
  }, [currentIndex, delay, text, onComplete, started])

  // 아직 시작 안 했으면 빈 span 반환
  if (!started) {
    return <span className={className}></span>
  }

  return (
    <span className={className}>
      {displayedText}
      {currentIndex < text.length && (
        <span className="animate-pulse text-primary-500">|</span>
      )}
    </span>
  )
}

• startDelay 시간만큼 대기 후 타이핑을 시작합니다.
  • 대기 중일 땐 started는 false. setStarted로 제어합니다.
• delay (기본 100ms) 간격으로 한글자씩 가져와 displayedText state에 추가합니다.
  • 현재 위치는 currentIndex로 추적합니다
• 모든 글자 출력 완료 시 onComplete를 출력합니다.

// MainTitle.jsx
'use client'

import TypingEffect from './TypingEffect'
import { useState } from 'react'

export default function MainTitle() {
  const [showSecondLine, setShowSecondLine] = useState(false)
  const [showThirdPart, setShowThirdPart] = useState(false)
  return (
    <div className="space-y-4">
      <h1 className="min-h-[6rem] text-4xl leading-tight font-bold tracking-tight text-gray-900 sm:min-h-[8rem] sm:text-5xl md:min-h-[10rem] md:text-6xl dark:text-gray-100">
        <TypingEffect
          text="뭔가 만드는 걸 좋아하는"
          delay={80}
          onComplete={() => setShowSecondLine(true)}
        />
        <br />
        {showSecondLine && (
          <>
            <TypingEffect
              text="송상록"
              delay={80}
              className="text-primary-500"
              startDelay={200}
              onComplete={() => setShowThirdPart(true)}
            />
            {showThirdPart && <TypingEffect text="입니다" delay={80} startDelay={100} />}
          </>
        )}
      </h1>
    </div>
  )
}

• "뭔가 만드는 걸 좋아하는" 타이핑 → 완료 시 showSecondLine을 true로, 이후 showSecondLine && 오른쪽 TypingEffect 렌더링.
• 200ms 대기 후 "송상록" 타이핑 → 완료 시 showThirdPart을 true로, 이후 showThirdPart && 오른쪽 TypingEffect 렌더링.
• 100ms 대기 후 "입니다" 타이핑

의존성배열에 뭐가 많은 건 react-hooks/exhaustive-deps 규칙 때문인데, 예상치 못한 버그를 방지하려고 useEffect 내 모든 변수가 들어갔다고 생각하심 됩니다...

Hooks

클래스 / 함수 컴포넌트

리액트에서 컴포넌트를 작성할 때는 흔히 아래와 같은 함수형 컴포넌트를 사용합니다. 아래는 버튼을 누르면 숫자가 1 증가하는 컴포넌트의 코드입니다.

(참고로 5번 누른 이후 상황입니다)

import { useState } from "react";

export default function Count() {
  const [number, setNumber] = useState(0);

  return (
    <>
      <h1>{number}</h1>
      <button
        onClick={() => {
          setNumber(number + 1);
        }}
      >
        +1
      </button>
    </>
  );
}

그런데 클래스 형식으로도 컴포넌트를 작성할 수 있어요. 그걸 클래스 컴포넌트라 하는데, 함수 컴포넌트에 비해 문법이 많이 복잡하고 가독성도 떨어집니다.

import React, { Component } from "react";

export default class Count extends Component {
  constructor(props) {
    super(props);
    this.state = {
      number: 0,
    };
  }

  increment = () => {
    this.setState((prevState) => ({
      number: prevState.number + 1,
    }));
  };

  render() {
    return (
      <>
        <h1>{this.state.number}</h1>
        <button onClick={this.increment}>+1</button>
      </>
    );
  }
}

놀랍게도 기존에는 useState, useRef 같은 함수들을 클래스 컴포넌트에서만 쓸 수 있었어요.

하지만 Hooks가 등장하면서 이러한 함수들을 함수 컴포넌트에서도 쓸 수 있게 됐습니다. 클래스 컴포넌트의 기능을 갈고리로 낚아 채온다... 는 뜻에서 Hook이라는 이름이 붙었어요. 모든 Hook은 이름 앞에 use가 옵니다. 그러니까

• useState는 클래스 컴포넌트의 State 기능을 낚아채온 거고
• useRef는 클래스 컴포넌트의 Ref 기능을 낚아채온 거다

라고 생각하시면 됩니다.

Hook 사용 규칙

Hook을 사용할 땐 이런 규칙을 지켜야 합니다.

(1) 함수형 컴포넌트 혹은 Custom Hook 안에서만 사용할 수 있다

const [number, setNumber] = useState(0);

export default function Count() {
  // 생략
}

즉 이렇게 useState를 Count 바깥에서 사용하시면 안 됩니다.

커스텀 훅이 뭔지는 뒤에서 설명할게요.

(2) 조건문 / 반복문 안에서 사용할 수 없다

if (true){
    const [number, setNumber] = useState(0);
  }

기본적으로 조건문, 반복문은 해당 조건이 만족되어야만 안에 내용을 실행하는 특징이 있습니다. 따라서 이 안에다 Hook을 사용하면, 어떤 렌더링에서는 실행되고 어떤 렌더링에선 실행되지 않아 호출 순서가 꼬이게 됩니다.

규칙을 어기시면 이런 무시무시한 경고창을 개발자도구에서 보실 수 있습니다. 바로 사이트가 뻗진 않지만 잠재적으로 고치기 어려운 버그가 생길 수 있습니다.

useState vs useRef

useState에 대해선 앞선 글에서 잘 정리했으니 참고 바랍니다

공통점

useState의 state, useRef의 ref 모두 컴포넌트 내부 변수로 활용 가능하다는 공통점이 있습니다. 그 뜻은 컴포넌트가 리렌더링되어도 값이 유지된다는 뜻입니다.

참고로 컴포넌트는 이러한 상황에서 리렌더링이 됩니다.

• 자신이 관리하는 state가 변경될 때
• 부모 컴포넌트에서 제공받는 props가 변경될 때
• 부모 컴포넌트가 리렌더링될 때

let으로 변수를 선언하면, 컴포넌트가 리렌더링되면 코드가 다시 실행되어 변수 선언이 다시 이루어집니다. 즉 매번 초기값으로 리셋되는 문제가 있습니다.

차이점

state는 변경될 때마다 컴포넌트가 리렌더링되지만, ref는 변경되어도 컴포넌트가 리렌더링되지 않습니다.

예제

import React, { useState, useRef } from 'react';

function Counter() {
  const [stateCount, setStateCount] = useState(0);
  const refCount = useRef(0);
  let letCount = 0;

  console.log('컴포넌트가 리렌더링됨');

  return (
    <div>
      <h2>State count: {stateCount}</h2>
      <button onClick={() => setStateCount(stateCount + 1)}>State 증가</button>

      <h2>Ref count: {refCount.current}</h2>
      <button onClick={() => {
        refCount.current += 1;
        console.log('Ref count:', refCount.current);
      }}>Ref 증가</button>
    </div>
  );
}

export default Counter;

• 버튼 State 증가를 누를 시
  • setCount(count + 1) 호출 후 컴포넌트가 리렌더링되어, 화면에 숫자 즉시 갱신됩니다.
• 버튼 Ref 증가를 누를 시
  • countRef.current+ 호출 시 값은 증가하지만, 컴포넌트가 리렌더링되진 않아 화면에 표시되진 않습니다.
  • console.log(countRef.current)에서는 증가된 값을 확인할 수 있습니다.
  • State 증가를 나중에 누르면 컴포넌트가 리렌더링되니, 그제서야 증가된 값이 반영됩니다.

useRef를 통한 DOM 요소 조작

useRef는 DOM 요소 조작에도 흔히 사용됩니다.

특히 특정 DOM 요소에의 자동 포커스나, 특정 DOM 요소로의 자동 스크롤에 흔히 사용됩니다.

예를 들어, 회원가입창에서 Submit 버튼을 눌렀는데 이름이 미입력된 경우 이름을 강조하고 싶다고 합시다.

(코드의 간결함을 위해 이름 제외 다른 필드는 생략한 점 양해 바랍니다)

function Register() {
  const [input, setInput] = useState({ name: "" });
  const nameRef = useRef();

  const onSubmit = () => {
    if (input.name === "") {
      nameRef.current.focus(); // DOM 직접 제어
    }
  };

  return (
    <>
      <input
        ref={nameRef}
        type="text"
        name="name"
        value={input.name}
        onChange={(e) => setInput({ name: e.target.value })}
        placeholder="이름을 입력하세요"
      />
      <button onClick={onSubmit}>제출</button>
    </>
  );
}

이렇게 input 태그의 ref 속성에 useRef로 만든 inputRef를 명시해 주고, 제출버튼을 눌렀을 때 실행되는 onSubmit 이벤트에서 inputRef.current.focus()를 주게끔 하는 식으로 조작이 가능합니다.

useEffect

useEffect는 컴포넌트의 Side Effect를 처리하는 Hook입니다.

Side Effect...가 뭐냐면, 컴포넌트의 핵심 기능은 화면에 보여지는 렌더링이겠죠. 그런데 실제로는 이와 더불어 다른 작업을 수행할 수 있습니다.

• 이를테면 API호출을 통한 fetching이라든가, DOM 조작이라든가...

useEffect는 (1)콜백함수 (effect 실행 내용)와 (2)의존성 배열을 받습니다.

• 이때 처음 컴포넌트가 렌더링될 때 + 의존성 배열 안의 값이 바뀔 때마다, 콜백 함수가 실행됩니다.
• 그래서 일반적으로 리렌더링과 관련된 값 (state나 props 등)이 들어가는데, 리렌더링을 통해 컴포넌트를 화면에 그리고 이후 콜백함수가 실행됩니다.

  // 콜백함수, 배열
  // count 또는 input 값이 바뀌면, 콜백함수 실행
  useEffect(() => {
    console.log(`count: ${count} | input: ${input}`);
  }, [count, input]);

이때 의존성 배열을 비워 두거나, 생략할 수도 있습니다.

• 값이 있으면, 배열 안 값 중 하나가 변경될 때마다 실행
• 비어 있으면 ([]), 컴포넌트가 처음 마운트될 때 1번만 실행
• 생략하면 (콜백함수만 인수로 보냄), 모든 렌더링마다 실행

Custom Hook

직접 custom hook을 만드는 것 역시 가능합니다. 앞서 말했듯이 Hook은 함수형 컴포넌트나 Custom Hook 내부에서만 사용할 수 있습니다. 즉 중복되는 Hook 코드가 반복될 때 함수화하고 싶으시면 Custom Hook을 사용하셔야 합니다.

리액트는 use로 시작하는 함수를 만들면 자동으로 Hook으로 인식하기 때문에, 쉽게 만드실 수 있습니다.

아래 코드처럼 여러 입력창에서 동일한 입력 관리 로직을 사용하는 경우, Custom Hook으로 분리할 수 있겠죠.

// src/hooks/useInput.jsx

import { useState } from "react";
// Custom Hook 만들기
// 그냥 함수 이름이 use로 시작하면 됨
export default function useInput() {
  const [input, setInput] = useState("");
  const onChange = (e) => {
    setInput(e.target.value);
  };

  return [input, onChange];
}

// src/components/HookExam.jsx
import useInput from "../hooks/useInput";

export default function HookExam() {
  const [name, onChangeName] = useInput("");
  const [email, onChangeEmail] = useInput("");

  return (
    <div>
      <input value={name} onChange={onChangeName} placeholder="이름" />
      <input value={email} onChange={onChangeEmail} placeholder="이메일" />
    </div>
  );
}

그래서 글로 정리해보았어요들레이요.

Critical rendering path

웹사이트를 화면에 표시할 때 HTML, CSS, JavaScript가 사용된다는 건 아실 거에요.

실제로는 HTML, CSS, JavaScript 코드가 화면에 보이는 웹사이트로 변신(?)될때까지는 일련의 과정이 이루어지는데, 이를 Critical Rendering Path라 합니다.

대충 과정을 정리해 보자면

HTML 코드                           DOM 트리
--------------------------------    ----------------------------
<html>                              [html]
  <body>                                ├── [body]
    <h1>무적 LG</h1>                     │     ├── [h1] "무적 LG"
    <p>끝까지 TWINS</p>                        │     └── [p] "끝까지 TWINS"
  </body>                               └──
</html>
--------------------------------    ----------------------------

CSS 코드                             CSSOM 트리
--------------------------------    ----------------------------
h1 { color: pink; }                  [CSSOM]
p  { font-size: 24px; }                 ├── [h1]
                                        │     └── color: pink
                                        └── [p]
                                              └── font-size: 24px
--------------------------------    ----------------------------

1단계 HTML 코드는 DOM(Document Object Model), CSS 코드는 CSSOM (CSS Object Model)로 전환됩니다.

• DOM 및 CSS Object Model은, 각각 HTML / CSS 코드를 브라우저가 이해하기 쉬운 형태로 변환한 트리 구조의 객체를 뜻합니다.
• 이때 JavaScript는 DOM을 수정하는 역할을 합니다. 예를 들어 버튼을 누르면 표시되는 숫자가 1씩 늘어나는 기능을 구현하면, DOM 중 해당 숫자에 해당되는 부분이 수정되겠죠.

2단계 DOM + CSS Object Model을 합쳐서 렌더 트리를 만듭니다.

• 특별한 건 아니고 두 모델이 합쳐진 거라고 생각하면 됩니다.
• 화면에 렌더링되는 요소들의 모든 정보가 포함되어 있는, 웹사이트의 설계도이자 청사진 역할을 합니다.

3단계 렌더 트리 내 요소의 위치를 계산하는 Layout 단계가 진행됩니다.

• DOM이 변경돼서 Layout이 다시 진행되는 과정을 Reflow라고도 합니다

4단계 레이아웃이 계산된 요소들을 실제로 웹사이트에 그리는 Paint 단계가 진행됩니다.

• DOM이 변경돼서 Paint가 다시 진행되는 과정을 Repaint라고도 합니다

DOM이 수정될 때

앞서 언급했듯이 JavaScript로는 DOM을 수정할 수 있습니다.

이런 경우 브라우저는 다시 render tree를 생성하고(2단계), 웹사이트의 레이아웃을 다시 잡는 reflow를 거치고(3단계), 렌더링 역시 다시 하여 repaint(4단계)도 거치게 됩니다.

문제는 reflow와 repaint에는 큰 시간적 비용이 든다는 점입니다. 그래서 DOM 수정이 많아질수록 웹사이트 성능이 급격히 떨어집니다.

이를테면, <ul>에 0부터 2999까지 <li>를 삽입하는 함수를 만들었다고 합시다

function badPractice() {
  const $ul = document.getElementById("ul");
  for (let i = 0; i < 3000; i++) {
    $ul.innerHTML += `<li>${i}</li>`;
  }
}

위 함수에서는 무려 3000번 DOM 수정을 하게 됩니다. reflow와 repaint 역시 오래 걸리기 때문에, 실제로 <li> 태그 내용이 다 생성되려면 상당한 시간이 소요됩니다. 즉 렌더링이 많이 느려지므로, 이렇게 코드를 짜시면 안 됩니다.

function goodPractice(){
  let list = "";
  for (let i = 0; i < 3000; i++){
    list += `<li>${i}</li>`
  }
  const $ul = document.getElementById("ul");
  $ul.innerHTML = list;
}

대신 이렇게 list라는 String 매개변수를 선언한 뒤, <li> 태그에 해당하는 내용을 미리 저장해 두고, DOM은 단 1번 수정하는 식으로 코드를 짜시면 됩니다.

이렇게 한꺼번에 변경사항이 많을 경우, 매번 따로 DOM 수정을 하기보단, 한 번에 모아서 수정을 해야 합니다.

Virtual DOM

React에서는 컴포넌트와 state를 통해 업데이트를 관리한다는 점을 기억합시다. 컴포넌트 내 State가 바뀔 때마다 컴포넌트 UI가 업데이트되는 방식이였죠.

앞선 논리대로라면 여러 업데이트가 발생할 시, 모아서 한 방에 DOM에 반영해야 하는 게 좋을 겁니다. 이를 위해 리액트는 Virtual DOM을 사용하는데요, 이는 실제 브라우저가 렌더링하는 DOM을 자바스크립트 객체로 흉내낸 거라고 생각하면 됩니다.

자세한 동작과정을 보자면

• 각 컴포넌트는 자신만의 Virtual DOM 트리를 가지고 있습니다.
• 컴포넌트 state가 바뀌면, 해당 컴포넌트의 Virtual DOM이 갱신됩니다.
• 이전 Virtual DOM과 새로운 Virtual DOM을 비교합니다(diffing)
• 여러 컴포넌트가 동시에 바뀌면, React는 모든 Virtual DOM에서 변경 사항을 모아 한 번에 실제 DOM에 반영합니다(batch)

이러면 Reflow, Repaint가 최소화되어 훨씬 빠른 렌더링이 가능해집니다. 우와~

포트폴리오랑 이력서에 치이느라 JS문법 복습에 신경을 못 쓰고 있었네요.

JS 비동기 처리에 중요한 Promise 및 async / await에 대해 정리해본 글입니다.

Promise: 비동기 처리용 객체

new Promise((resolve, reject) => {...})의 형태로 Promise를 생성할 수 있습니다.

• Promise의 인수로 들어가는 이 콜백함수를 executor라고 하며, 실제 비동기 작업을 처리하는 부분이라 이런 이름이 붙었습니다.
• 그러니까 setTimeout, fetch와 같은 비동기 작업을 {...} 안에 넣어주면 됩니다.

resolve, reject

일반적으로는 아래처럼 Promise를 반환하는 비동기 함수를 만들어 사용합니다.

한번 숫자에 10을 더하는 비동기 함수를 만들어 볼까요?

function addTen(num) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      if (typeof num === "number") {
        resolve(num + 10);                // 성공 시 인수에 결과값 전달
      } else {
        reject("Number형을 입력하세요!");    // 실패 시 인수에 에러 메시지 전달
      }
    }, 2000);
  });
}

기존에는 num + 10을 그대로 반환하게끔 작성했겠지만, 이제 Promise 객체 안에 resolve(num + 10)을 넣고 그걸 반환을 하는 것 같은데요... 그런데 resolve는 무슨 역할일까요?

• executor는 resolve, reject 두 함수를 매개변수로 가집니다
• resolve는 비동기 작업이 성공적으로 완료됐을 때 호출하며, 인수에는 성공 시 표시할 결과값을 전달합니다.
• reject는 비동기 작업이 실패했을 때 호출하며, 인수에는 실패 시 오류 메시지를 전달합니다.
• 언제 resolve, reject를 호출할 지는 함수 짤 때 알아서 잘 생각하셔야 한다는 점에 유의합시다.

then, catch

이렇게 Promise를 반환하는 함수는,then이나 catch 메서드를 이용해 후속 작업 및 예외 처리를 진행할 수 있습니다.

addTen(10)
  .then((value) => {
    console.log(value);
    return addTen(value);
  }) // then 메서드 안에 return 값이 있을 시, 다음 then 메서드의 매개변수로 전달됨
  .then((value) => {
    console.log(value);
    return addTen(value);
  })
  .then((value) => {
    console.log(value);
    return addTen(value);
  })
  .catch((error) => {
    console.log(error);
  }); // 도중에 reject될 시 catch 메서드로 이동

// num = 10 일시 -> 2초 후 20 출력, 4초(2+2) 후 30 출력, 6초(4+2)후 40 출력
// num이 숫자가 아닐시 -> 2초 후 "Number형을 입력하세요!" 출력

• then: 앞선 Promise가 resolve될 때까지 기다리고, 그 결괏값이 매개변수 (value)로 전달됩니다.
  • then 메서드 안에서 또 다른 Promise를 반환할 시, 다음 then은 그 Promise가 resolve될 때까지 기다린 후 값을 전달받습니다.
• catch: 도중에 reject 처리된 Promise가 생길 시, 에러 메시지가 error 매개변수로 전달되고, 이후 체이닝이 종료됩니다.

기존에는 이렇게 10을 더하는 비동기 연산을 3번 할 때, 콜백함수를 3단으로 호출해야 했으나, 그럴 필요가 없어졌습니다! 우와~~ 콜백 지옥에서 탈출했어요.

async, await

.then 메서드를 쓰는게 직관적이지 않은 것 같으면, 조금 더 깔끔한 async, await 키워드를 쓰는 방법도 있습니다.

async

async는 함수를 항상 Promise를 반환하는 비동기 함수로 만들어 줍니다.

• 반환값이 Promise가 아닌 경우 자동으로 resolve된 Promise를 반환합니다.
• 이미 Promise를 반환하면 그런 효과는 없지만... 이따 볼 await를 사용하기 위해선 일단 쓰셔야 합니다.

async function addTen(num) {
  // 반환값이 Promise 객체가 아닌 경우, 이를 결과값으로 가진 fulfilled / promise 객체가 반환되는 효과도 있음
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      if (typeof num === "number") {
        resolve(num + 10);
      } else {
        reject("Number형을 입력하세요!");
      }
    }, 2000);
  });
}

await, try~catch

await는 async 함수의 Promise가 처리될때까지 기다리고, 결과값을 반환하는 역할입니다. 기존에 then(...)안에서 처리하던 코드를, await를 통해 변수에 저장하고 다음 줄에 바로 사용하는 식으로 변경하실 수 있습니다.

• 단 await는 async 함수 안에서만 쓸 수 있으니 유의합시다.
• .catch() 같은 경우 try~catch를 통한 예외 처리로 변경하시면 됩니다.

async function addThreeTens(num) {
  try {
    const result1 = await addTen(num);
    console.log(result1);
    const result2 = await addTen(result1);
    console.log(result2);
    const result3 = await addTen(result2);
    console.log(result3);
  } catch (error) {
    console.log(error);
  }
}

addThreeTens(10);
// num = 10 일시 -> 2초 후 20 출력, 4초(2+2) 후 30 출력, 6초(4+2)후 40 출력
// num이 숫자가 아닐시 -> 2초 후 "Number형을 입력하세요!" 출력

포트폴리오 사이트 보러 가기

포트폴리오

사실 대부분 포트폴리오는 피그마나 캔바를 써서 pdf로 만드시는 것 같은데

뭔가 홈페이지로 만드는 게 좀 더 개발자 느낌 날 것 같아서 홈페이지로 만들어봤다. 뭐 PDF로 제출하라는 곳들도 있는데 웹사이트 PDF로 바꿔주는 툴들도 있으니 그런걸 쓰면 될 것 같고

나만무 때 익숙해진 Next.js + TailwindCSS를 사용했는데, 내가 밑바닥부터 만들지는 않았고 인터넷에 돌아다니는 블로그 템플릿을 썼다.

이런 깃허브 템플릿이 있길래 썼다. 여러분도 튜토리얼만 잘 읽으면 따라 쓰실 수 있음

호스팅은 GitHub Pages로 했다. 무료에다가, GitHub Actions랑 연동하면 푸시하면 자동으로 빌드하고 배포해주는게 편하다.

결과물

메인페이지는 아직 조촐한데 시간 나면 좀더 꾸밀 생각이다. 일단은 이력서랑 포트폴리오에 더 집중해야 되니까...

포트폴리오에는 정글에서 한 프로젝트 3개 (핀토스, 나만무 준비주차 때 한 클론코딩, 나만무 최종프로젝트)랑 학교에서 코딩 깔짝하면서 만든 프로젝트 2개를 넣었다.

아 그리고 컬러는 내가 좋아하는 핑크로 골랐다.

각 프로젝트별 페이지는, 마크다운 파일만 업로드하면 자동으로 사이트에 올라가는 방식이다. 나름 웹페이지의 장점을 활용하려고 해서 나만무 발표영상도 첨부했고, 5년전에 만든 게임은 직접 해 보실 수도 있다.

근데 아직 포트폴리오 세부내용을 완전히 적지는 못했다. 일단은 방대한 코드를 다시 읽으면서 기술적 챌린지를 판단하는 건 무리수인 것 같아서... 클로드 코드한테 이력서 내용 + 실제 코드 내용 보고 간단히나마 정리해달라고 했다. 내일 참고해서 새롭게 다시 쓰고, 사진도 추가하고 해야겠다.

이력서 페이지도 있는데, 이력서는 얼추 작성은 했지만 웹페이지에는 ㄹㅇ Ctrl+C Ctrl+V만 해 둬서 아직 CSS를 많이 입히진 못했다. 나중에 좀 더 예쁘게 다듬을 생각이다.

비동기

참고: 인프런 <한입크기로 잡아먹는 리액트>

동기

기본적으로 JavaScript는 여러 개의 작업을 순서대로, 한 번에 한 개씩 처리한다. (동기)

function taskA() {
  console.log("나는 야옹입니다");
}

console.log("당신은 누구십니까");
taskA();
console.log("아하 그렇군요");

/* 출력 결과 
// 당신은 누구십니까
// 나는 야옹입니다
// 아하 그렇군요
*/

다만 이런 동기 처리의 경우, 중간의 한 작업의 시간이 길어지면 전체 프로그램의 실행 속도도 느려지는 문제가 있다.

예를 들어, 지금 이 코드의 taskA가 만약 1분 소요되는 작업이였다면, 1분이 지날때까지 console.log("아하 그렇군요")가 출력되지 못한다.

특히 네트워크 요청(API라든지...), 파일 읽기 같이 오래 걸리는 작업일 때 애로사항이 많아진다.

비동기

이렇게 도중에 시간이 오래 걸리는 작업이 있는 경우, 비동기 처리하여 다음 코드를 우선 실행 할 수 있다.

비동기란 작업을 백그라운드에서 처리하면서, 다른 작업을 먼저 실행할 수 있는 방식이다.

즉 비동기를 잘 활용하면, 네트워크 요청이나 파일 읽기 등 작업이 이루어지는 동안 전체 프로그램이 멈추는 것을 방지할 수 있다.

console.log("약속장소에 도착했다");
// setTimeout(): 비동기 함수, 일정 시간이 지난 후에 콜백함수를 실행
setTimeout(() => {
  console.log("늦어서 미안해!");
}, 3000);
// 3초(3000ms) 타이머만 실행 후 다음 라인으로 넘어감, 기다리지 않음
console.log("얜 왜이렇게 늦게 와?");

/* 출력 결과
// 약속장소에 도착했다 (즉시)
// 얜 왜이렇게 늦게 와? (즉시)
// 늦어서 미안해! (3초 후)
*/

위 코드의 setTimeout은 비동기 함수로, 콜백함수랑 시간(ms)을 인자로 받는다. 우선 인자로 받은 시간만큼 타이머를 실행한 후, 바로 다음 라인으로 넘어간다. 이후 시간이 경과하면 콜백함수가 실행된다.

console.log("데이터 요청 시작");

fetch("https://api.example.com/users")
  .then((response) => response.json())
  .then((data) => {
    console.log("데이터 받음:", data);
  });

console.log("다른 작업 실행 중...");

/* 출력 결과
// 데이터 요청 시작
// 다른 작업 실행 중...
// 데이터 받음: [사용자 데이터...] (API 응답 후 출력)
*/

실제로는 setTimeout 대신 fetch와 같은 API 요청 함수가 중간에 들어가는 경우가 많은데, 이러한 함수를 비동기 처리하면, 처리가 완료될 때까지 이후의 라인을 우선 실행할 수 있다는 소리다.

물론 fetch에다가 콜백 함수를 넣어, API 요청이 완료된 후 후속 작업을 지정하는 것도 가능하다.

js는 싱글쓰레드

C#, Java 같은 언어는 멀티쓰레드를 통해 비동기 처리를 실행한다. 쓰레드는 프로그램이 작업을 실행하는 흐름의 단위인데, 이런 언어들론 병렬로 여러 작업을 실행할 수 있다....정도로 이해하면 된다.

하지만 애석하게도 JavaScript 엔진은 싱글쓰레드다. 한 번에 하나의 작업만 처리할 수 있다는 뜻이다. 그런데도 이런 비동기 처리가 가능하다. 왤까?

이는 비동기 작업은 JavaScript 엔진이 아닌, Web API(브라우저가 제공하는 별도 공간이라고만 알아두기)에서 실행되기 때문이다.

클로드 형님께서 그려준 아래 그림을 보고 이해해보자.

  JS ENGINE (Call Stack)          WEB APIs              Callback Queue
┌─────────────────────────┐    ┌──────────────────┐       ┌─────────────────┐
│                       │    │                  │    │                 │
│  1️⃣ console.log()     │    │                  │    │                 │
│     "약속장소에..."      │    │                  │    │                 │
│  ✓ 실행 완료            │    │                  │    │                 │
│                       │    │                  │    │                 │
│  2️⃣ setTimeout()      │───▶│  Timer 시작      │    │                 │
│     ✓ Web API에 위임    │    │  (3000ms)       │    │                 │
│     ✓ 즉시 다음으로      │    │   ⏱️ 카운트다운   │     │                 │
│                       │    │                  │    │                 │
│  3️⃣ console.log()     │    │   ⏱️ 카운트다운   │     │                 │
│     "얜 왜이렇게..."     │    │                  │    │                 │
│  ✓ 실행 완료            │    │   ⏱️ 카운트다운   │    │                 │
│                        │   │                  │    │                 │
│  [비어있음]              │    │  ✓ 3초 완료!     │───▶│  () => {...}    │
│   대기 중...            │    │                  │    │  콜백 대기 중   │
│                        │    │                 │    │                 │
│                        │    │                 │    │                 │
│  4️⃣ () => console.log()  │◀───────────────────────────│  콜백 전달      │
│     "늦어서 미안해!"     │    │                  │    │                 │
│  ✓ 실행!               │    │                  │    │  [비어있음]     │
│                        │   │                  │    │                 │
└─────────────────────────┘    └──────────────────┘     └─────────────────┘
         ▲                                                      │
         │                                                      │
         └──────────────────────────────────────────────────────┘
                        Event Loop (계속 감시)
                "Call Stack 비었어? 그럼 Queue에서 가져올게!"

일반적인 동기 함수(e.g., console.log())는 자바스크립트 엔진의 콜 스택에서 실행된다.

하지만 setTimeout()같은 비동기 함수를 만나면, 이러한 절차가 이루어진다.

1. 자바스크립트 엔진은 비동기 작업을 Web API에 맡긴다. 이와 동시에 setTimeout() 종료 후 실행될 콜백 함수도 전달한다.

2. Web API가 3초 타이머를 실행한다.

3.setTimeout()의 3초 타이머가 종료되면, WEB API가 콜백 함수를 콜백 큐에 추가한다.

• 콜백 큐는 역시 Web API처럼 브라우저에서 관리한다.

4. 이때 브라우저의 Event Loop이라는 친구가 계속 콜 스택이 비어 있는지 확인한다. 비어 있으면 콜백 큐에서 함수를 가져와, 콜 스택에서 다시 실행하는 식이다.

• 얘 덕분에 콜백 함수가 기존에 실행되는 동기 작업을 강제 중단시키고 새치기하는 일은 없게 된다.

콜백 지옥

다만 비동기 함수 때 콜백 함수를 사용할 땐 애로사항이 많다.

이를테면, 비동기 작업이 끝나고 다른 비동기 작업을 연달아 실행하는 경우가 있다고 하자.

그러면 콜백 함수 자리에 다른 비동기 함수를 넣어 줘야 하는데, 이러한 작업이 많아질수록 코드가 복잡해진다.

실제로 이런 코드를 적을 일은 없지만, 1초 간격으로 음식을 먹었다고 출력하는 코드를 짰다고 가정해 보자.

// 콜백 함수

function eatMandu(callback) {
  setTimeout(() => {
    const ateMandu = "만두도 먹고";
    callback(ateMandu);
  }, 1000);
}

function eatPizza(food, callback) {
  setTimeout(() => {
    const atePizza = `${food} 피자도 먹고`;
    callback(atePizza);
  }, 1000);
}

function eatJjajang(food, callback) {
  setTimeout(() => {
    const ateJjajang = `${food} 짜장면도 먹고`;
    callback(ateJjajang);
  }, 1000);
}

// 비동기 작업의 결과를 다른 비동기 작업의 인수로 활용할 수 있음
// 보다시피 복잡함 - 콜백 지옥 우려
eatMandu((ateMandu) => {
  console.log(ateMandu);
  eatPizza(ateMandu, (atePizza) => {
    console.log(atePizza);
    eatJjajang(atePizza, (ateJjajang) => {
      console.log(ateJjajang);
    });
  });
});

// 출력결과
// 만두도 먹고 (1초 후 출력)
// 만두도 먹고 피자도 먹고 (2초 후 출력)
// 만두도 먹고 피자도 먹고 짜장면도 먹고 (3초 후 출력)

보시다시피 비동기작업이 3번 연달아 일어나니 코드가 복잡해지는 것을 볼 수 있다.

이러한 현상을 콜백 지옥이라 하는데, Promise나 async/await라는 친구로 해결할 수 있다. 거기서부턴 내일 정리할게용~

일단 오늘도 이력서 다듬기를 했는데, 뭔가 지금까지 한 프로젝트들이 잘 정리가 안 되니까 이력서도 어떻게 정리해야 할지 헷갈리는 감이 있다.

그래서 내일은 이력서 말고 포트폴리오를 작업하면서 지금까지 한 프로젝트들을 좀 다시 정리해볼 생각이다.

참고: 인프런 <한입크기로 잡아먹는 리액트>

원시 vs 객체 타입

JavaScript에서 변수에 할당되는 값들은 메모리에 저장이 된다.

이때 실제로 값이 저장되는 방식은, 값이 원시 타입인지, 객체 타입인지에 따라 달라진다.

원시 타입 (불변 타입)

• number, string, boolean, null, undefined 등 타입은 원시 타입이다.
• 값 자체가 메모리에 저장되며, 변수는 실제 값을 가리킨다.

  변수 선언:  let p1 = 1;

     변수          메모리
   ┌──────┐     ┌──────┐
   │  p1  │---->│  1   │  메모리 주소: 0x001
   └──────┘     └──────┘

  복사:  let p2 = p1;

     변수          메모리
   ┌──────┐     ┌──────┐
   │  p1  │---->│  1   │  메모리 주소: 0x001
   └──────┘     └──────┘
   ┌──────┐     ┌──────┐
   │  p2  │---->│  1   │  메모리 주소: 0x002 (새로운 복사본!)
   └──────┘     └──────┘

• p2에 p1 값을 할당하면, 메모리상 값이 복사되어 독립적인 메모리에 저장된다.
• 따라서 p2와 p1은 서로 영향을 주지 않는다.

  재할당:  p2 = 2;

     변수          메모리
   ┌──────┐     ┌──────┐
   │  p1  │---->│  1   │  메모리 주소: 0x001 (변경 없음)
   └──────┘     └──────┘
                ┌──────┐
   ┌──────┐     │  1   │  메모리 주소: 0x002 (버려짐)
   │  p2  │-╳   └──────┘
   └──────┘ ║   ┌──────┐
            ╚═=>│  2   │  메모리 주소: 0x003 (새 값!)
                └──────┘

• p2 = 2와 같이 변수에 값을 재할당하더라도, 기존의 값 1은 메모리에서 수정되지 않는다.
  • 그래서 원시 타입을 불변 타입으로도 부른다.
• 단지 메모리에 새로운 값 2가 새로 저장되고, 변수 p2가 새로운 값을 가리킬 뿐이다.

객체 타입

• object, array, function 등 타입은 객체 타입이다.
• 실제 객체 및 해당 객체의 참조값(주소)이 모두 메모리에 저장되며, 변수는 참조값을 가리킨다.
  • 배열의 원소나 객체의 프로퍼티가 추가/삭제/수정될 수 있기 때문에 이러한 방식으로 저장된다고 한다.

변수 선언:  let o1 = { place: "서울" };

     변수          참조값           실제 객체
   ┌──────┐     ┌────────┐      ┌─────────────────┐
   │  o1 │---->│ 0xA001 │----->│ place: "서울"   │  메모리: 0xA001
   └──────┘     └────────┘      └─────────────────┘

• 변수 o1에는 실제 객체를 가리키는 참조값이 저장되며, 실제 데이터는 별도 메모리에 존재한다.

  얕은 복사:  let o2 = o1;

     변수          참조값           실제 객체
   ┌──────┐     ┌────────┐      ┌─────────────────┐
   │  o1 │---->│ 0xA001 │--┐   │ place: "서울"   │  메모리: 0xA001
   └──────┘     └────────┘  │   └─────────────────┘
   ┌──────┐     ┌────────┐  │          ▲
   │  o2 │---->│ 0xA001 │--┘         │
   └──────┘     └────────┘             │
                                동일한 객체를 가리킴!

• o2에 o1 값을 할당할 때, 메모리상 실제 객체가 아닌 참조값이 복사된다. (얕은 복사)
• 따라서 o2와 o1은 동일한 객체를 가리키므로 서로 영향을 줄 수 있다.

  값 수정:  o2.place = "인천";

     변수          참조값           실제 객체
   ┌──────┐     ┌────────┐      ┌─────────────────┐
   │  o1  │---->│ 0xA001 │--┐   │ place: "인천"   │  메모리: 0xA001
   └──────┘     └────────┘  │   └─────────────────┘
   ┌──────┐     ┌────────┐  │          ▲
   │  o2  │---->│ 0xA001 │--┘         │
   └──────┘     └────────┘             │
                                 둘 다 영향받음!

  console.log(o1.place)    // "인천"

• o2의 place를 인천으로 바꾸면, 실제객체(0xA001)의 데이터가 바뀌므로o1.place도 인천으로 변경된다.
  • 그래서 원시 타입을 가변 타입으로도 부른다.

깊은 복사

• 만약 원래 객체를 복사해야 하는데 위처럼 의도치 않게 값이 삭제되는 일을 막으려면, ...(스프레드 연산자)로 깊은 복사를 수행해야 한다.

  선언:  let o3 = { place: "서울" };
         let o4 = { ...o3 };

     변수          참조값           실제 객체
   ┌──────┐     ┌────────┐      ┌─────────────────┐
   │  o3  │---->│ 0xB001 │----->│ place: "서울"   │  메모리: 0xB001
   └──────┘     └────────┘      └─────────────────┘

   ┌──────┐     ┌────────┐      ┌─────────────────┐
   │  o4  │---->│ 0xB002 │----->│ place: "서울"   │  메모리: 0xB002
   └──────┘     └────────┘      └─────────────────┘
                                     (새 객체!)

• ...(스프레드연산자)는 배열/객체의 여러 값을 개별로 흩뿌려 주는 역할을 수행한다.
• 위와 같이 let o4 = {...o3}로 복사 시, 메모리에 새로운 객체가 생성되며, 프로퍼티만 따로 복사된다.
  • 이를 깊은 복사라 한다.

  값 수정:  o4.place = "대전";

     변수          참조값           실제 객체
   ┌──────┐     ┌────────┐      ┌─────────────────┐
   │  o3  │---->│ 0xB001 │----->│ place: "서울"   │  변경 없음!
   └──────┘     └────────┘      └─────────────────┘

   ┌──────┐     ┌────────┐      ┌─────────────────┐
   │  o4  │---->│ 0xB002 │----->│ place: "대전"   │  o4만 변경!
   └──────┘     └────────┘      └─────────────────┘

• o3, o4는 별개 객체를 가리키므로, o4.place를 대전으로 변경해도 o3.place는 변경되지 않는다.

깊은 비교

• 객체를 비교할 땐, 실제 객체의 값이 아닌 참조값 기준으로 비교가 이루어진다.

  설정:  let o5 = { place: "대구" };
         let o6 = o5;        // 얕은 복사
         let o7 = { ...o5 }; // 깊은 복사


  [얕은 비교 - 참조값 비교]

    o5 === o6  →  true

    ┌────────┐      ┌─────────────────┐
    │ 0xC001 │----->│ place: "대구"   │
    └────────┘      └─────────────────┘
         ▲                   ▲
         │                   │
      o5, o6 모두 같은 참조값!


    o5 === o7  →  false

    ┌────────┐      ┌─────────────────┐
    │ 0xC001 │----->│ place: "대구"   │  o5
    └────────┘      └─────────────────┘

    ┌────────┐      ┌─────────────────┐
    │ 0xC002 │----->│ place: "대구"   │  o7
    └────────┘      └─────────────────┘

    참조값이 다름!

• o6은 o5와 같은 객체를 가리켜 (동일 참조값) 비교 결과가 true가 된다.
• o7은 스프레드연산자를 통해 생성된 새로운 객체기 때문에, o5와 프로퍼티의 키/값이 완전히 동일하더라도 참조값이 다르므로 비교 결과가 false가 된다.
• 이러한 ===를 이용한 참조값 기준 비교를 얕은 비교라고 한다.

  [깊은 비교 - 내부 값 비교]

    JSON.stringify(o5) === JSON.stringify(o7)  →  true

    "{"place":"대구"}" === "{"place":"대구"}"

    문자열로 변환하여 내부 값 비교!

• 만약 실제 객체의 값 기준으로 비교를 하고 싶다면, JSON.stringify를 사용해 객체의 값을 문자로 변경한 뒤 내부 값을 비교해야 한다. 이를 깊은 비교라고 한다.

정리

배열 메서드

• 너무 많지만 리액트에서 흔히 사용되는 메서드들 위주로만 정리해보았다.

필수 3형제

map

• 모든 요소에 대해 콜백 함수 수행 후, 그 반환값으로 이루어진 새로운 배열을 반환한다.

  let arr = [1, 2, 3];
  let arr_squared = arr.map((item, idx, arr) => {
  console.log(`${idx}번째 요소: ${item}`);
  return item ** 2;
  });
  // 0번째 요소: 1
  // 1번째 요소: 2
  // 2번째 요소: 3
  console.log(arr_squared); // [1, 4, 9]
  

let arr = [ { name: "롯데리아", category: "햄버거" }, { name: "김가네", category: "김밥" }, { name: "설빙", category: "디저트" }, { name: "맥도날드", category: "햄버거" }, ]; let food_names = arr.map((item) => item.name); console.log(food_names); // [ '롯데리아', '김가네', '설빙', '맥도날드' ]

- 리액트에서는 배열을 JSX 요소 배열로 변환하여, 화면에 리스트를 렌더링할 때 주로 사용된다.
  - 상품 목록, 드롭다운 옵션, 테이블 행 등...
```js
{users.map(user => <UserCard key={user.id} user={user} />)}

filter

• 콜백 함수 결과가 true인 요소들만 이루어진 새로운 배열을 반환한다.

  // 콜백함수 결과가 true인 요소들로만 이루어진 새로운 배열 반환
  let arr = [
  { name: "롯데리아", category: "햄버거" },
  { name: "김가네", category: "김밥" },
  { name: "설빙", category: "디저트" },
  { name: "맥도날드", category: "햄버거" },
  ];
  console.log(arr.filter((item) => item.category === "햄버거"));
  // [ { name: '롯데리아', category: '햄버거' }, { name: '맥도날드', category: '햄버거' } ]

• 리액트에서는 검색, 카테고리에 따라 조건에 맞는 데이터만 추출해서 보여줄 때 주로 사용된다.

  const activeUsers = users.filter(user => user.isActive);

find

// 배열에서 콜백함수 결과가 true인 첫 요소를 반환. 없으면 undefined 반환
let arr = [1, 2, 3];
console.log(arr.find((item) => item > 1)); // 2

let objectArr = [{ name: "누렁이" }, { name: "탱고" }, { name: "빵아지" }];
console.log(objectArr.find((item) => item.name === "탱고"));
// { name: '탱고' }

• 리액트에선 파라미터, ID를 기반으로 데이터를 찾아 상세 페이지를 렌더링할 때 주로 사용된다.

  const user = users.find(u => u.id === userId);

덜 중요한데 쓰이긴 함

slice

• 배열의 특정 범위를 잘라, 새로운 배열로 반환한다.

let arr = [1, 2, 3, 4, 5];
console.log(arr.slice(1, 4)); // [2, 3, 4] (인덱스 1부터 4 전까지)
console.log(arr.slice(2)); // [3, 4, 5] (인덱스 2부터 끝까지)
console.log(arr.slice(-2)); // [4, 5] (뒤에서부터 2개)
console.log(arr); // [1, 2, 3, 4, 5] (원본 배열은 변경되지 않음)

• 리액트에선 페이지네이션으로 현재 페이지에 해당하는 데이터만 잘라내거나, 원본 배열을 유지하며 특정 요소를 삭제할 때 사용한다.

  // 페이지네이션 예시
  const currentPage = 2;
  const itemsPerPage = 10;
  const displayItems = items.slice(
  (currentPage - 1) * itemsPerPage,
  currentPage * itemsPerPage
  );

const newArr = [...arr.slice(0, index), ...arr.slice(index + 1)];

sort/toSorted

• 사전 순으로 배열 요소를 정렬한다. 원본 배열이 변경된다!!
• 사전 순이므로, 숫자값 등을 비교할 시 별도 비교 콜백 함수로 명시해야 한다.
  • 매개변수 2개를 받으며, -1 반환 시 앞 변수, 1 반환 시 뒷 변수가 앞에 오게끔 정렬된다.

// 사전순으로 배열 요소를 정렬. 원본 배열이 변경됨
let arr = [5, 10, 3];
arr.sort();
console.log(arr); // [10, 3, 5] (사전순임에 유의)

// 숫자값 기준 시, 비교 콜백함수로 명시해야 함
arr.sort((a, b) => {
  if (a > b) {
    // 양수 반환 -> 뒤의 매개변수(b)가 먼저 옴
    return 1;
  } else if (a < b) {
    // 음수 반환 -> 앞의 매개변수(a)가 먼저 옴
    return -1;
  } else {
    // 0 반환 -> 두 값의 자리를 바꾸지 않음
    return 0;
  }
});
console.log(arr); // [3, 5, 10]

let arr_desc = [5, 10, 3];

// 내림차순일 시 그 반대로...
arr_desc.sort((a, b) => {
  if (a > b) {
    return -1;
  } else if (a < b) {
    return 1;
  } else {
    return 0;
  }
});

• 리액트에서는 최신순, 가격순 등 정렬 기능을 구현할 때 사용된다.
  • 반드시 복사본을 만든 후 정렬해야 한다.

    const sorted = [...items].sort((a, b) => a.order - b.order);

• 원본이 유지되고 새로운 배열을 반환하는 toSorted를 사용할 수도 있다.

  const sorted = items.toSorted((a, b) => a.price - b.price);

알면 좋은 나머지 메서드 요약

내가 다 정리하기 귀찮아서 클로드가 요약해줬다.

리액트에서 push, pop, shift, unshift 쓰면 안되는 이유

• 리액트에서는 상태 변화를 참조값(메모리주소) 비교로 감지한다.
• 아예 새로운 배열을 만든 경우 참조값이 변경돼서 변화를 감지할 수 있다.
• 하지만 원본 배열을 직접 수정하면, 참조값은 그대로이므로 변화를 감지할 수 없다.

// 올바르지 않은 방법
const [items, setItems] = useState([1, 2, 3]);

const handleAdd = () => {
  items.push(4);        // 원본 배열 수정
  setItems(items);      // 같은 참조(주소) -> React는 변화 없다고 판단
};
// 화면이 업데이트되지 않음

// 새로운 배열 생성 - React가 변화 감지
const handleAdd = () => {
  setItems([...items, 4]);  // 새 배열 생성 -> 다른 참조(주소)
};
// 화면이 정상적으로 업데이트됨

Date 객체와 날짜

Date 객체

• 후술할 각종 메서드를 사용할 수 있다.

  let date1 = new Date(); // 매개변수 없을 시현재 시간
  console.log(date1);
  // Sat Oct 04 2025 22:17:15 GMT+0900 (한국 표준시)
  // 결과는 실행 시점에 따라 다름
  

let date2 = new Date(2000, 6, 22, 12, 30, 59); // 월은 0부터 시작함에 유의 (0: 1월, 1: 2월, ..., 6: 7월) console.log(date2); // Sat Jul 22 2000 12:30:59 GMT+0900 (한국 표준시)

## 타임 스탬프
- 특정 시간이 1970년 1월 1일 00:00:00 UTC로부터 몇 밀리초가 지났는지 나타낸 값
- 참고로 대한민국은 UTC보다 9시간 빠르다.

```js
let ts1 = date2.getTime();
console.log(ts1); // 964296659000

// 타임 스탬프로부터 Date 객체 생성 가능
let date3 = new Date(ts1);
console.log(date3); // Sat Jul 22 2000 12:30:59 GMT+0900 (한국 표준시)

시간 요소의 추출, 수정

• 추출은 get, 수정은 set을 기억하자.

  // 시간 요소 추출
  let year = date2.getFullYear();
  let month = date2.getMonth() + 1; // 월은 0부터 시작하므로 +1
  let day = date2.getDate();
  let hours = date2.getHours();
  let minutes = date2.getMinutes();
  let seconds = date2.getSeconds();
  console.log(
  `${year}년 ${month}월 ${day}일 ${hours}시 ${minutes}분 ${seconds}초`
  );
  // 2000년 7월 22일 12시 30분 59초
  

// 시간 요소 수정 date2.setFullYear(2025); date2.setMonth(9); // 10월 (0부터 시작) date2.setDate(4); date2.setHours(22); date2.setMinutes(15); date2.setSeconds(30); console.log(date2); // Sat Oct 04 2025 22:15:30 GMT+0900 (한국 표준시)

## 시간 포맷팅
```js
console.log(date2.toDateString()); // Sat Oct 04 2025
console.log(date2.toLocaleString()); // 2025. 10. 4. 오후 10:15:30
console.log(date2.toLocaleDateString()); // 2025. 10. 4.

정글 최종프로젝트를 하면서, 자바스크립트에 헷갈리는 게 많다보니 타입스크립트든 리액트든 Next.js도 점점 어려워지는 걸 씨게 느꼈다...

그래서 복습하면서 특히나 헷갈리는 개념 위주로 정리를 해보기로 했다.

참고: 인프런 <한입크기로 잡아먹는 리액트>

(cf. 마음같아선 하루종일 인강 들으면서 빨리 끝내고싶지만, 이력서 / 포트폴리오 준비랑 병행하느라 그러진 못할것같다)

(??) null 병합 연산자

• 왼쪽 값이 null 또는 undefined일 때만 오른쪽 값을 반환한다.

// 존재하는 값을 추려내는 기능 (null, undefined 제외)
// e.g., 회원가입
let userName = "코딩왕 송상록";
let displayName = userName ?? "익명의 두루미"; // 회원이름이 없으면 익명의 두루미로 표시
console.log(displayName); // 코딩왕 송상록

||과의 비교

• || (논리 OR 연산자) 같은 경우는 왼쪽 값이 null, undefined가 아닌 다른 falsy 값(0, "" - 빈 문자열, false)일 때도 체크한다.
• 하지만 ??은 오직 null, undefined 둘만 체크한다.

let userName = "";
let displayName = userName || "익명의 두루미"; 
console.log(displayName); // "익명의 두루미" -> ''(빈 문자열)도 falsy라서 OR에서는 오른쪽 값 반환

let displayName2 = userName ?? "익명의 두루미";
console.log(displayName2); // "" -> null이나 undefined일 때만 오른쪽 값 반환

호이스팅

• Javascript 특유의 함수 호출법으로, 함수를 선언되기 전에 호출하는 방식이다.
• function 함수이름(){} 꼴의 함수 선언식으로 선언된 함수에서만 적용 가능하다.
• 변수에 익명 함수를 할당한 함수 표현식에는 적용 불가능하다.
  • 이건 let, const 따위로 선언한 변수를 선언 전에 사용할 수 없는 거랑 동일한 이유라고 생각하심 된다.
  • 이걸 복잡한 말로 Temporal Dead Zone(TDZ)이라 부른다. 실제로는 선언 전에도 변수 확인은 가능하지만, 초기화되어 있지 않아 정상적인 접근이 불가능하다.

// 호이스팅: '끌어올린다'는 뜻. 함수가 선언되기 전에 호출해도 문제 없음.

console.log(getArea(10, 5));

// 매개변수와 인수
function getArea(width, height) {
  const area = width * height;
  console.log(`가로 ${width}, 세로 ${height}인 사각형의 넓이는 ${area}입니다.`);
  return area;
}

// 단, 함수 표현식을 사용하는 경우... 변수에 함수를 할당하는 방식이므로, 호이스팅 불가능.
console.log(mandu());    // ReferenceError 발생
let mandu = function () {
  console.log("만두먹고싶다");
};

Python에선 됐었나?

print(mandu())  # NameError: name "mandu" is not defined

def mandu():
    return "만두먹고싶다"

안 되니까 코테 볼 때 헷갈리지 말자.

콜백 함수

• 자신이 아닌 다른 함수에, 인수로써 전달된 함수를 의미한다.
• 자바스크립트 특유의 비동기 처리에 흔히 사용되는데, 이건 내일 들을 강의 내용이라서 그때 더 정리해 보려고 한다.
  • 일단은 '작업이 완료된 뒤 실행될 함수'를 콜백 함수로 흔히 전달한다고만 알아두면 된다.

// 자신이 아닌 다른 함수에, 인수로써 전달된 함수를 의미함

function repeat(count, callback) {
  for (let idx = 0; idx < count; idx++) {
    callback(idx);
  }
}
// 0, 1, 2, 3, 4 순으로 출력.
repeat(5, (idx) => {
  console.log(idx);
});

// 0, 2, 4, 6, 8 순으로 출력.
repeat(5, (idx) => {
  console.log(idx * 2);
});

// 0, 3, 6, 9, 12 순으로 출력.
repeat(5, (idx) => {
  console.log(idx * 3);
});

콜백 지옥

• 콜백이 여러 단계로 중첩돼서 코드 가독성이 쓰레기가 되는 현상을 뜻한다.
• 만약에 로그인하고 사용자 프로필 구하고 친구들 정보 구하고 게시글 정보 구하는 비동기 과정을 콜백 함수로 작성하면 아래처럼 되는데... 이렇게 쓰면 여러모로 나중에 유지보수가 어려워진다.
• 이런 걸 해결하려고 async/await, Promises 같은 게 생겼다는 데, 내일 범위라서 내일 글에서 다룰 예정이다.

loginUser(id, password, (user) => {
  getUserProfile(user, (profile) => {
    getFriends(profile, (friends) => {
      getPosts(friends, (posts) => {
        console.log(posts);
      });
    });
  });
});

일단 정글 공식일정상 협력사 (+인턴) 지원은 명절 이후부터라고 한다.

지원하려는 협력사의 성격이나 직무에 따라 전략이 달라질 수도 있을 것 같아, 지금 말고 해당 시점부터 작업하려고 한다.

포트폴리오는 깃허브 jekyll 같은 거 써서 웹사이트로 만들까 싶다.

문제는 정글 오기전에 학교에서 프로그래밍 과제를 했을땐 기술적 챌린지 그런 건 신경 안쓰고 프로젝트를 진행해서, 뭘 강조해야할지 모르겠다는 거다. (사진의) 정글 나만무 최종프로젝트 말곤 딱히 개발자가 되어야겠단 생각 전에 했던지라 그런 부분들을 간과했다

이건 대학 2학년때, 그니까 5년전에 교양수업에서 만든 웹게임이다. AI도 없을 때 만들었어서 삽질을 많이 하긴 했는데, 구체적으로 어떤 삽질을 했나 기억 안난다... 같이 만드신 선배님 잘 살아계시나요?

웹프로그래밍 밖으로 범주를 넓히자면, langchain 프롬프팅 미니프로젝트를 과제로 몇번 했지만, 아무래도 기술적 챌린지보단 사회과학적/교육학적 결론을 내는 것에 집중했다보니, 이력서와 핏이 맞을 지 모르겠다.

그렇다고 개발이랑 아예 상관없는, 내 과거 교육봉사 및 진로 멘토링 이력을 적기도 그렇고 흠. 고민이 많다. 일단 써 보는 것에 의의를 둬야 할듯.

프로젝트 더 많이 하고 싶은데 그런 건 어디서 구해야할지 모르겠다.

코딩테스트

정글 입학하기 전에 사둔 책을 다시 한번 보며 복습할 생각이다. 하루에 한두문제 정도 푸는 게 적당할 것 같다.

웹개발

일단은 프론트에 가까운 풀스택 개발자를 목표로 하고 있다. 옛날에 사둔 인프랩 이정환님 리액트 강의를 완주하는 게 목표다. 다 들으면 타입스크립트랑 넥스트 강의도 들어볼 예정이다.

꼭 이건 취업 목적만은 아닌게, 난 나만무 최종프로젝트 때 내가 쓴 리액트 코드의 절반은 동작원리를 모르겠다,,, 그래서 필수라고 생각했다.

기술 면접

정글에서 핀토스를 아무리 열심히 하고 CSAPP을 아무리 열심히 읽었다고 해도, 그걸 다시 보라고 하면 못 보겠다;;; 정글에서 하루 10시간 넘게 공부할 때도 너무 방대했는데 지금은 더할 거다. 기술면접 말고도 준비할 게 많은데 더 효율적인 방법이 필요하다.

그래서 일단은 면접대비용 요약서를 보면서, CSAPP이나 핀토스의 내용 중 필요한 부분이 있으면 과거에 블로그에 정리한 내용들 참고하면서 복습하는 게 좋을 것 같다.

위치

슬프게도 정글에선 더 이상 집중이 안 돼서 나가서 공부할 것 같다. 오랜만에 봄날의 서재를 들릴 것 같다.

<어따놀래>는 사용자가 도면의 사진을 업로드하면 벽을 검출하여 표시하는 기능을 제공합니다.

단 본 프로젝트의 지향점이 AI의 성능 강화보단 전반적인 웹 서비스 구현에 초점을 맞추었기 때문에, 벽 검출 기능에 일부 오차가 있을 수 있습니다.

물론 직접 인공지능 모형을 훈련하거나 하는 식으로 해결할 순 있겠지만, 도면만들기보단 시뮬레이터에 집중해야 할 필요가 있겠다고 생각했습니다. (특히 정글이 AI 부트캠프는 아닌만큼, 선택과 집중을...)

대신 축척 설정 및 벽 추가 / 삭제 등 에디터 기능 역시 구현되어 있으므로, 벽 검출에 오차가 있더라도 사용자가 바로 수정할 수 있습니다.

Hough Transformation

소스 코드

벽 검출에는 공개 컴퓨터 비전 라이브러리인 OpenCV.js의 Hough Transformation을 사용하였습니다.

Hough Transformation은 도형 및 사진에서 선을 검출해 주는 알고리즘입니다. 동작 과정을 차례로 설명해 보겠습니다.

0. 원본 이미지

1. 그레이스케일 변환

window.cv.cvtColor(srcImg, gray, window.cv.COLOR_RGBA2GRAY);

• 벽 검출에 불필요한 색상 정보를 없애고 그레이스케일로 변환합니다.

2. 이진화

window.cv.threshold(gray,
  binary,
  0,
  255,
  window.cv.THRESH_BINARY_INV + window.cv.THRESH_OTSU
);

• 실제로는 흑백 이미지도 0부터 255까지의 밝기를 가집니다. Otsu 이진화는 그레이스케일 이미지를 완전한 검은색(0) 또는 흰색(255)로 변환하는 과정입니다.
• 0부터 255까지 모든 밝기 값의 빈도를 구한 뒤, 빈도의 분산이 최대가 되는 임계값을 구합니다.
  • 분산은 '어두운 그룹과 밝은 그룹의 평균 밝기 차이가 가장 커지도록 이미지를 둘로 나누는 기준 값'을 말합니다.
• 이후 임계값보다 어두우면 흰색(0, 벽을 나타냄), 밝으면 검은색(255, 벽이 아닌 곳을 나타냄)으로 처리됩니다.

3. 모폴로지 연산 (노이즈 계산)

const kernel = window.cv.Mat.ones(3, 3, window.cv.CV_8U);
window.cv.morphologyEx(binary, cleaned, window.cv.MORPH_OPEN, kernel);

• 모폴로지 연산은 이미지의 점들을 조금씩 늘리거나 줄여서, 작은 얼룩을 없앨 수 있습니다.
• 선 내 작은 구멍을 메우고 연결해 주는 역할을 수행합니다.
• 3 x 3 행렬로 주변 9개 점들을 한 번에 보면서 작은 점들을 지우고, 끊어진 선들을 이어줍니다.

4. Canny 엣지 검출을 통한 윤곽선 계산

window.cv.Canny(cleaned, edges, canny1, canny2, 3, false);

• Canny 엣지검출은 이미지에서 가장자리, 즉 윤곽선을 검출하는 알고리즘입니다.
• Canny 임계값은 벽과 배경 사이 밝기 차이를 측정합니다.
• canny1(50)보다 낮으면 경계선이 아니라고 판단하고, canny2(150)보다 높으면 확실한 경계선으로 판단합니다. 50과 150 사이의 값은 주변에 확실한 경계선이 있을 때만 경계선으로 인정합니다.

5. Probabilistic Hough를 통한 벽 선분 추출

window.cv.HoughLinesP(
  edges,
  lines,
  1,                    // rho: 거리 해상도
  Math.PI / 180,        // theta: 각도 해상도 (1도)
  houghTh,              // 임계값 (80)
  minLen,               // 최소 선분 길이 (30)
  maxGap                // 선분 간 최대 간격 (20)
);

• Hough Transform을 통해 흩어진 점을을 이어 선분을 검출할 수 있습니다.
• rho는 선의 위치를 1픽셀 단위로, theta는 선의 기울기를 1도 단위로 세밀하게 측정하여 정확한 직선을 찾아냅니다.
• houghTh(80)는 몇 개의 점이 일직선 위에 있어야 선으로 인정할지 정하는 값입니다. 80개 이상의 점이 일직선상에 있으면 벽으로 판단합니다.

6. 선분 필터링

filterLines(lines, minLength = 80, angleThreshold = 5)

• 실제 벽으로 보기 어려운 선분을 제거합니다.
• 너무 짧은 선분(80px 미만)이나, 수직/수평이 아닌 선분 (회전각도가 5도 이상)인 경우 제거됩니다.

7. 평행선 병합

mergeParallelLines(lines, maxDistance = 15, angleThreshold = 5)

• 지금까지의 과정에서는 한 벽에서 여러 개의 선이 검출될 수 있습니다. 따라서 평행한 선을 하나의 선으로 병합할 필요가 있습니다.
• 위 사진의 분홍색 선은, 원래 선들 중 병합된 선을 의미합니다.
• angleThreshold: 5도 이내의 각도 차이만 평행선으로 인정합니다.
• maxDistance: 15px 이내 거리의 선만 병합 대상입니다.
• 겹침 구간이 10% 이상인 선분만 병합하여, 정확도를 높입니다.

실제 인테리어에서는 가구를 벽에 붙여 배치하는 경우가 많기 때문에, 이를 돕는 벽 자석 기능을 구현했습니다.

파일 구조

벽 자석 기능은 다음 파일들에 구현되어 있습니다:

• useObjectControls.js:39-396 - 메인 벽 자석 로직 (findNearestWallSnap 함수)
• wallSlice.js:11-17 - 벽 자석 기능 상태 관리
• CameraControlPanel.jsx:164-182 - 벽 자석 ON/OFF 토글 UI

벽 자석은 가구를 벽의 모서리 300mm(three.js 기준 0.3) 이내로 이동시키면, 자동으로 가구를 벽에서 50mm 떨어진 위치로 보정하는 기능입니다. 위치가 보정된 이후에도 사용자가 추가적으로 미세 조정할 수 있습니다.

이때 자석 효과가 활성화된 벽은 노란색으로 하이라이트되어, 사용자가 쉽게 인식할 수 있습니다.

또한 직각으로 만나는 두 벽의 교차점 500mm(three.js 기준 0.5) 이내 범위로 가구를 이동시키면, 두 벽이 만나는 직각 코너에 정확히 맞춰 자동 배치됩니다. 코너 스냅이 활성화되면 벽이 주황색으로 하이라이트됩니다.

벽 자석 기능은 화면 좌측 Display 패널의 "벽 자석" 토글 스위치를 통해 활성화 및 비활성화가 가능합니다.

작동 로직

1. 자석 발동 거리 설정

const SNAP_DISTANCE = 0.3; // 300mm 이내에서 자석 효과
const WALL_OFFSET = 0.05; // 벽에서 50mm 떨어진 위치로 보정
const CORNER_SNAP_DISTANCE = 0.5; // 직각 코너의 경우, 500mm 이내

<어따놀래>에서는 실제 1mm를 three.js 0.001 단위로 환산해 사용합니다.

즉 가구가 300mm(한 벽) / 500mm(직각 코너) 이내로 접근하면, 자석 효과가 발동해 가구가 벽에서 50mm 떨어진 위치에 맞춰집니다.

직각 코너에서는 두 벽과 동시에 거리 조건을 만족해야 하는 특성상 일반 벽 자석보다 발동이 어려우므로, 의도적으로 감지 거리를 300mm에서 500mm로 늘려 사용성을 향상시켰습니다.

또한 보정된 벽과의 거리를 0mm가 아닌 50mm로 설정한 이유는, 실제 인테리어에서도 청소 공간 확보 및 벽면 손상 방지를 위해 벽과 가구 사이에 약간의 틈을 두는 점을 반영했습니다.

2. 벽면별 거리 판정 로직

각 벽의 4개 면(앞, 뒤, 좌, 우)에 대해 개별적으로 거리를 계산하고, 자석 거리 이내에 있는지 확인합니다:

// useObjectControls.js:140-149 (벽 앞면 예시)
// Z축 방향 자석 발동 가능 여부 먼저 확인
if (Math.abs(localX) <= wallHalfWidth + rotatedFurnitureWidth) {
  // 벽 앞면과 가구 뒷면의 거리 계산
  const furnitureBackEdge = localZ - rotatedFurnitureDepth;
  const wallFrontEdge = wallHalfDepth;
  const frontDistance = Math.abs(furnitureBackEdge - wallFrontEdge);

  // 거리 조건과 위치 조건을 동시에 만족하는지 확인
  if (furnitureBackEdge > wallFrontEdge && frontDistance < SNAP_DISTANCE) {
    // 자석 발동 후보로 등록
  }
}

이 로직이 벽의 4개 면 모두에 대해 실행되며, 조건을 만족하는 면들이 allCandidates 배열에 수집됩니다.

3. 벽과 가구의 거리 계산을 위한 로컬 좌표계 변환

벽이 회전되어 있는 경우, 벽과 가구의 정확한 거리를 측정하기 까다롭습니다.

예를 들어 45도 회전된 벽의 경우, 가구와의 거리를 X, Z 좌표로 직접 계산하면 복잡한 삼각함수 계산이 필요합니다.

이미지 출처

따라서 벽을 기준으로 하는 새로운 좌표계(로컬 좌표계)를 만들어, 마치 벽이 수평인 것처럼 간단하게 계산할 수 있도록 했습니다. 이는 전체 공간(월드 좌표계)에서 벽 중심의 작은 공간(로컬 좌표계)으로 관점을 바꾸는 것입니다. (월드 좌표계는 전체 공간 기준의 좌표계, 로컬 좌표계는 벽을 기준으로 다시 계산한 좌표계로 이해하시면 됩니다.)

// 벽을 기준으로 가구의 상대 좌표 계산
const relativePos = new THREE.Vector3(
  position.x - wallPos.x,
  0,
  position.z - wallPos.z
);

먼저 가구의 월드 좌표에서 벽의 월드 좌표를 빼서, 가구가 벽으로부터 얼마나 떨어져 있는지를 나타내는 상대 벡터(relativePos)를 구합니다.

하지만 이 relativePos는 여전히 월드 좌표계 기준이므로 벽의 회전이 반영되지 않은 상태입니다.

// 벽 회전에 따라 좌표 변환
const wallCos = Math.cos(wallRotation);
const wallSin = Math.sin(wallRotation);

const localX = relativePos.x * wallCos + relativePos.z * wallSin;
const localZ = -relativePos.x * wallSin + relativePos.z * wallCos;

따라서 벽의 회전 각도(wallRotation)을 고려하여, 가구가 실제로 벽 기준으로 어느 쪽에 있는지를 다시 계산합니다.

이때 앞서 구한 relativePos에 삼각함수를 사용한 회전 변환을 적용합니다.

localX는 벽을 기준으로 한 좌우 거리로, 양수인 경우 벽의 오른쪽, 음수인 경우 벽의 왼쪽에 가구가 있음을 의미합니다.

localZ는 벽을 기준으로 한 앞뒤 거리로, 양수인 경우 벽의 앞쪽, 음수인 경우 벽의 뒤쪽에 가구가 있음을 의미합니다.

(three.js에서는 관례와 다르게 높이를 나타내는 축이 z축이 아닌 y축으로 처리된다는 점에 유의 바랍니다.)

4. 회전된 가구의 바운딩 박스 계산

앞서 구한 localX, localZ는 벽과 가구의 중심점 간의 상대적 위치입니다.

하지만 실제 벽 자석에서는 가구의 중심점이 아닌 가구의 가장자리가 벽에 닿는 거리를 계산해야 합니다. 즉, 가구 중심에서 벽까지의 거리가 아니라 가구의 면(edge)에서 벽까지의 최단거리를 측정해야 합니다. 이를 위해 furnitureHalfWidth, furnitureHalfDepth 같은 가구의 실제 크기를 반영한 바운딩 박스 계산이 필수입니다.

이를 위해, 가구를 감싸는 박스인 바운딩 박스를 따로 계산했습니다. (위 사진의 파란색 박스가 bounding box입니다).

이미지 출처

가구가 회전된 경우, 월드 좌표계에서 보는 바운딩 박스의 실제 크기가 달라집니다.

예를 들어 원본 크기가 width 2000mm, depth 1000mm인 가구를 Y축 기준으로 90도 회전시키면:

• 회전 전: X축 방향 2000mm, Z축 방향 1000mm
• 회전 후: X축 방향 1000mm, Z축 방향 2000mm

이러한 회전을 고려하지 않으면 가구를 회전해도 벽 자석이 원래 크기로 잘못 계산하여 부정확한 스냅이 발생합니다.

따라서 회전 변환 행렬을 적용한 Oriented Bounding Box(OBB)를 계산하여 실제 공간에서의 정확한 바운딩 박스 크기(rotatedFurnitureWidth, rotatedFurnitureDepth)를 구해야 합니다.

// 가구의 회전을 벽의 로컬 좌표계에서 계산
const relativeRotation = furnitureRotationY - wallRotation;
const furnitureCos = Math.cos(relativeRotation);
const furnitureSin = Math.sin(relativeRotation);

// 회전된 가구의 실제 바운딩 박스 크기
const rotatedFurnitureWidth =
  Math.abs(furnitureHalfWidth * furnitureCos) +
  Math.abs(furnitureHalfDepth * furnitureSin);
const rotatedFurnitureDepth =
  Math.abs(furnitureHalfWidth * furnitureSin) +
  Math.abs(furnitureHalfDepth * furnitureCos);

벽을 기준으로 가구가 얼마나 회전했는지(relativeRotation)를 구한 다음, 삼각함수(furnitureCos, furnitureSin)를 이용해 회전된 가구가 실제로 차지하는 폭(rotatedFurnitureWidth)과 깊이(rotatedFurnitureDepth)를 계산합니다.

5. 벽면별 자석 위치 계산

실제 자석 계산은 각 벽의 4개 면(앞, 뒤, 좌, 우)에 대해 개별적으로 수행됩니다. 아래는 벽 앞면과의 자석 발동 여부를 계산한 코드입니다:

// 벽 앞면 자석 발동 계산 예시
const furnitureBackEdge = localZ - rotatedFurnitureDepth; // 가구 뒷면 위치
const wallFrontEdge = wallHalfDepth; // 벽 앞면 위치
const frontDistance = Math.abs(furnitureBackEdge - wallFrontEdge); // 거리 계산

// 거리 조건과 위치 조건 확인
if (furnitureBackEdge > wallFrontEdge && frontDistance < SNAP_DISTANCE) {
  // 자석 발동 위치 계산: 벽 앞면에서 WALL_OFFSET만큼 떨어진 곳
  const snapLocalZ = wallFrontEdge + WALL_OFFSET + rotatedFurnitureDepth;

  // 로컬 좌표를 월드 좌표로 변환
  const snapWorldPos = {
    x: wallPos.x + (localX * wallCos - snapLocalZ * wallSin),
    y: position.y,
    z: wallPos.z + (localX * wallSin + snapLocalZ * wallCos),
  };

  // 자석 발동 후보로 등록
  allCandidates.push({
    distance: frontDistance,
    snapPosition: snapWorldPos,
    wall: wall,
    face: "front",
  });
}

계산 과정 요약

1. 가구와 벽면의 거리 계산: furnitureBackEdge와 wallFrontEdge 사이의 실제 거리(frontDistance)
2. 조건 확인: frontDistance가 SNAP_DISTANCE(300mm) 이내이고, 가구가 벽의 올바른 쪽에 위치하는지 확인
3. 자석 발동 위치 계산: snapLocalZ로 벽에서 WALL_OFFSET(50mm) 떨어진 최종 위치 계산
4. 좌표 변환: wallCos, wallSin을 사용해 로컬 좌표(snapLocalZ)를 월드 좌표(snapWorldPos)로 변환

이 과정이 벽의 모든 면에 대해 반복되어 가능한 모든 자석 발동 후보들이 allCandidates 배열에 수집됩니다.

6. 직각 벽 감지 및 코너 자석 활성화

코너 자석이 활성화되려면 다음 조건들을 만족해야 합니다:

1. 두 개 이상의 가까운 벽 감지

// useObjectControls.js:250-252
const nearCandidates = allCandidates.filter(
  (candidate) => candidate.distance < CORNER_SNAP_DISTANCE // 0.5 (500mm) 이내
);

allCandidates 배열에서 CORNER_SNAP_DISTANCE(500mm) 이내의 벽들을 nearCandidates로 필터링합니다.

2. 직각 관계 확인

// useObjectControls.js:284-288
const angleDiff = Math.abs(wall1.rotation[1] - wall2.rotation[1]);
const normalizedDiff = angleDiff % (2 * Math.PI);
const isRightAngle =
  Math.abs(normalizedDiff - Math.PI / 2) < 0.1 ||
  Math.abs(normalizedDiff - (3 * Math.PI) / 2) < 0.1;

wall1.rotation[1]과 wall2.rotation[1]의 차이(angleDiff)를 계산하여 두 벽이 90도 각도로 만나는지 확인합니다. normalizedDiff로 정규화하고, isRightAngle로 0.1라디안 (약 5.7도)의 오차를 허용합니다.

두 벽이 서로 다른 방향(하나는 가로, 하나는 세로)을 향해야 코너 자석이 가능합니다. 같은 방향을 향하는 평행한 벽들은 코너가 아니므로 제외됩니다.

추가 설명

벽이 많거나 가구가 여러 개일 때 성능이 저하될 가능성은 없을까요?

• 벽 자석 발동 여부 계산은 매 프레임마다 실행되지 않고, 가구를 드래그할 때만 실행됩니다.
• 가구를 움직이지 않을 때는 계산이 발생하지 않아, 성능에 영향은 없습니다.
• 한 번에 드래그되는 가구 1개에 대해서만 벽 자석 계산이 실행됩니다.

조건을 만족하는 벽이 많을 때, 어떤 우선순위로 결정되나요?

• 코너 자석과 일반 벽 자석을 모두 만족하는 경우, 코너 자석이 최우선으로 적용됩니다.
• 일반 자석의 경우, 가장 가까운 벽을 기준으로 작동합니다.

• 자바스크립트는 어떤 타입이든 받아줌 -> 이로 인해 오류 발생 가능

let age = 25;
age = "스물다섯";
console.log(age + 5); // "스물다섯5"

• age에는 숫자만 들어갈 수 있게 의도했는데, 문자열이 들어가게 되면 의도치 않은 결과 발생할 수 있음

• 타입스크립트에선 변수, 함수, 객체에 타입을 명시적으로 선언

  • 컴파일 단계에서 타입 오류를 잡아주므로, 이런 버그를 줄일 수 있음

타입스크립트 기본 문법

설치

npm install -g typescript

타입스크립트의 type

• 총 6개의 타입이 존재한다.
  • number
  • string
  • boolean
  • null
  • undefined
  • any -> 그 외의 타입

// let (변수명):(타입명)
let a: number = 15;
a = "hello world";
let b: string = "무적LG";

any 타입

// any: 뭐가 올지 모름
let c: any = 4;
c = "날려버려 날려버려 안타 신민재"; // 다른 타입의 값 넣어도 에러 없음

• 단, 지나친 any를 사용하는 것은 지양해야 함
• 그럼 TypeScript를 쓰는 의미가 없으니까

2개 이상 타입 지정

// 여러 타입 지정 가능 - 얘네 중 하나
let c: number | string = "홍창기 안타 날려 홍창기";
c = 51;

• 여러 타입 중 하나가 올 수 있는 경우

배열

// 배열
let d: string[] = ["박해민", "신민재", "홍창기", "문성주"];
d.push("김현수");

• (타입)[] 과 같은 식으로 가능

let d: (string | number)[] = ["박해민", "신민재", "홍창기", "문성주"];
d.push("김현수");
d.push(13);

• |를 통한 여러 타입 선언도 가능

함수

// 함수
// e.g., number 인수 2개를 받고, number를 반환한다.
function addNumber(a: number, b: number): number {
  return a + b;
}
console.log(addNumber(7, 22)); // 29

• 인수 및 반환값에도 타입을 지정할 수 있음

const addNumber = (a: number, b: number): number => {
  return a + b;
};

• 화살표 함수인 경우에도 선언 가능

객체

• 객체는 C 구조체마냥, 타입을 직접 만들 수 있음
• 방법은 두 가지. interface 와 type이 있음
• 이런 객체를 선언한다고 가정하면

let data = {
  name: "임찬규",
  number: 1,
  size: { height: 186, weight: 88 },
  friends: [
    { name: "손주영", number: 29 },
    { name: "김진성", number: 42 },
    { name: "유영찬", number: 54 },
    { name: "송승기", number: 13 },
  ],
};

type

• 객체에 들어갈 필드의 타입 지정 후, 나만의 타입을 지정 가능

type Player = {
  name: string;
  number: number;
  size: { height: number; weight: number }; // 객체 안 객체
  friends: { name: string; number: number }[]; // 객체의 배열
};

let data: Player = {
  name: "임찬규",
  number: 1,
  size: { height: 186, weight: 88 },
  friends: [
    { name: "손주영", number: 29 },
    { name: "김진성", number: 42 },
    { name: "유영찬", number: 54 },
    { name: "송승기", number: 13 },
  ],
};

• 위처럼 해도 되고, 객체 안 객체를 별도의 객체로 만들어 줘도 됨

type Size = {
  height: number;
  weight: number;
};

type Friend = {
  name: string;
  number: number;
};

type Player = {
  name: string;
  number: number;
  size: Size;
  friends: Friend[];
};

interface

• type 타입명 = {...} 이 아니라 interface 타입명 {...} 식으로 선언된다는 점이 큰 차이.

interface Size {
  height: number;
  weight: number;
}

interface Friend {
  name: string;
  number: number;
}

interface Player {
  name: string;
  number?: number;
  size: Size;
  friends: Friend[];
}

let data: Player = {
  name: "임찬규",
  number: 1,
  size: { height: 186, weight: 88 },
  friends: [
    { name: "손주영", number: 29 },
    { name: "김진성", number: 42 },
    { name: "유영찬", number: 54 },
    { name: "송승기", number: 13 },
  ],
};

• number? 처럼 물음표를 붙이면, 해당 필드는 와도 되고, 안 와도 됨.

extends

• interface에서는 extends라고, 기존 interface에 뭘 더하는 문법을 사용할 수 있음

interface Food {
  name: string;
  price: number;
}

interface Pizza extends Food {
  pieces: number;
  comment: string;
}

let pizza: Pizza = {
  name: "불고기 피자",
  price: 13000,
  pieces: 8,
  comment: "너무 맛있어요",
};

타입스크립트 코드 컴파일

• 웹 브라우저는 JavaScript만 이해하지, TypeScript를 이해하지 못함
  • TypeScript는 인간의 편리를 위한 언어
• 즉, TypeScript는 JavaScript로 컴파일해야 함

// test.ts
function addNumber(a: number, b: number): number {
  return a + b;
}
console.log(addNumber(7, 22));

# test.ts -> test.js 파일 생성
tsc test.ts

// 컴파일된 test.js 파일
function addNumber(a, b) {
  return a + b;
}
console.log(addNumber(7, 22));

• 타입 오류 발생 시, 컴파일은 되지만 아래와 같이 알려줌

test.ts:2:1 - error TS2322: Type 'string' is not assignable to type 'number'.

2 a = "fsdfsdsfd";
  ~
Found 1 error in test.ts:2

tsconfig.json

• ts -> js config 위한 json 파일
• 자바스크립트 버전도 다양한 만큼, 이를 설정하기 위함

{
  "compilerOptions": {
    "outDir": "dist", // 컴파일된 JS 파일을 저장할 디렉토리
    "target": "es6", // 어떤버전의 JS로 변환할지 지정. 제일 최신은 ES6
    "module": "commonjs", // Express는 commonjs, React는 es6로 설정
    "lib": ["es6"], // 컴파일 시 사용할 라이브러리 지정
    "sourceMap": true // 디버깅용. JS코드에서 에러 발생시, 원래 작성한 TS에서 위치를 정확히 확인하기 위함.
  }
}

• 이후 tsc (파일명)로 빌드하면, 해당폴더의 tsconfig.json에서 지정한 컴파일러 옵션을 적용함
• config 옵션은 사용하는 라이브러리 등에 따라 달라질 수 있음. 보통 이를 그대로 따르면 됨

React + TypeScript

• 기존처럼 npm create vite@latest을 실행하시되, TypeScript 선택.

> create-vite

│
◇  Project name:
│  react-typescript
│
◇  Select a framework:
│  React
│
◇  Select a variant:
│  TypeScript
│
◇  Scaffolding project in C:\Users\drink\Documents\jungle\week15\typescript\react\react-typescript...
│
└  Done. Now run:

  cd react-typescript
  npm install
  npm run dev

• 기본 파일도 .tsx고, tsconfig.json 파일도 기본적으로 생성된 것을 확인할 수 있음.
• 대신 코드 자체는 아직 타입스크립트 형태로 바뀌지 않은 상황

state 타입스크립트에서 사용하기

• useState 함수에 무슨 타입이 들어가지?
• 리액트는 기본적으로는 JS 기반. 뭔 타입이 들어와도 괜찮음.
• JS를 위한 함수를 TS에 맞게 수정할 수는 없는 노릇. 대신 제네릭이라는 친구를 사용.
• 제네릭 <...>: 내가 useState를 호출하는 순간, 타입을 정해 준다.

// 내가 `myPlayer` state에 앞서 만든 Player type를 저장하는 경우
// `useState<Player>`와 같이 사용.
const [myPlayer, setMyPlayer] = useState<Player>(data);

• 여기서 myPlayer는 Player 타입
• setMyPlayer는 Player를 인수로 받고 반환값이 없는 함수 타입이 됨.

props 타입스크립트에서 사용하기

• 컴포넌트에 보내는 props 역시 type나 interface로 타입을 만들어 사용

const App = () => {
  const [myPlayer, setMyPlayer] = useState<Player>(data);
  const changeName = (name: string) => {
    setMyPlayer((myPlayer) => ({ ...myPlayer, name }));
  };

  return (
    <>
      <CheckPlayer data={myPlayer} changeName={changeName} />
    </>
  );
};

• e.g., 내가 Player 형의 data와, string을 받고 반환값이 없는 함수 changeName을 CheckPlayer 컴포넌트에 전달하고 싶다면?

interface CheckPlayerProps {
  data: Player;
  changeName(name: string): void;
}

• Props를 interface나 type로 만들어 주고
  • 이때 interface에 함수를 넣는 경우, (변수명: 변수타입, ...): 반환값타입 식으로 작성
  • 반환값 없는 경우 void로

const CheckPlayer = (props: CheckPlayerProps) => {
  return (
    <>
      <h1>
        #{props.data.number}: {props.data.name}
      </h1>
    </>
  );
};

• 이후 CheckPlayer의 매개변수 타입을 CheckPlayerProps로 설정한다

예제코드

// App.tsx
import "./App.css";
import { useState } from "react";

interface Size {
  height: number;
  weight: number;
}

interface Friend {
  name: string;
  number: number;
}

interface Player {
  name: string;
  number: number;
  size: Size;
  friends: Friend[];
}

const data: Player = {
  name: "임찬규",
  number: 1,
  size: { height: 186, weight: 88 },
  friends: [
    { name: "손주영", number: 29 },
    { name: "김진성", number: 42 },
    { name: "유영찬", number: 54 },
    { name: "송승기", number: 13 },
  ],
};

interface CheckPlayerProps {
  data: Player;
  changeName(name: string): void;
}

const CheckPlayer = (props: CheckPlayerProps) => {
  const [newName, setNewName] = useState<string>(props.data.name);
  return (
    <>
      <h1>
        #{props.data.number}: {props.data.name}
      </h1>
      <div>
        키 {props.data.size.height}, 몸무게 {props.data.size.weight}
      </div>
      <h2>동료 선수들</h2>
      <ul>
        {props.data.friends.map((friend: Friend, idx: number) => (
          <li key={idx}>
            #{friend.number} {friend.name}
          </li>
        ))}
      </ul>
      <input
        type="text"
        value={newName}
        onChange={(e) => setNewName(e.target.value)}
        placeholder="변경할 이름 입력"
      />
      <button onClick={() => props.changeName(newName)}>이름 변경</button>
    </>
  );
};

const App = () => {
  const [myPlayer, setMyPlayer] = useState<Player>(data);
  const changeName = (name: string) => {
    setMyPlayer((myPlayer) => ({ ...myPlayer, name }));
  };

  return (
    <>
      <CheckPlayer data={myPlayer} changeName={changeName} />
    </>
  );
};

export default App;

우리 팀 사랑합니다 ㅎㅎㅎ