이벤트 핸들링

이벤트 타겟

웹 페이지에서 사용자가 클릭하는 지점에 있는 요소는 "이벤트 타깃" 또는 "리프 노드"다. 이는 해당 클릭 지점에서 가장 구체적인, 즉 가장 하위에 위치한 요소이다. 이 타겟에 대한 이벤트가 발생하는 과정에서 이벤트가 전파되는 경우 각 노드는 "원본 이벤트 객체"를 공유한다. 캡쳐링-타겟도달-버블링을 거치는 이유는 다음과 같다.

캡쳐링 특정 상황에서 이벤트를 미리 처리하거나 중간에 이벤트를 중단해야 할 때 유용하다. 캡처링 단계의 존재는 개발자가 이벤트 처리의 흐름을 더욱 세밀하게 제어할 수 있게 해준다.

• 이벤트 핸들링의 우선 순위 제공: 특정 이벤트가 발생했을 때, 상위 요소에서 먼저 이벤트를 감지하고 처리할 기회를 제공. 이는 하위 요소보다 먼저 이벤트에 반응해야 하는 경우 유용하다. 예를 들어, 특정 조건에서 이벤트를 차단하거나, 특정 동작을 먼저 수행한 후 하위 요소로 이벤트를 전달해야 할 때 사용된다.

• 보안 및 사전 처리: 캡처링 단계에서 이벤트를 처리함으로써, 보안 관련 로직이나 데이터 검증과 같은 작업을 수행할 수 있다. 이를 통해 이벤트가 실제 타깃에 도달하기 전에 필요한 조치를 취할 수 있다.

리액트 이벤트 핸들링

리액트는 자체적인 합성 이벤트(synthetic events) 시스템을 통해 DOM 이벤트를 처리한다. 이 합성 이벤트는 브라우저 간 호환성을 보장하고, 리액트 이벤트 핸들러에서 자체적으로 이벤트를 관리하므로 더 빠른 성능을 제공한다. 합성 이벤트는 실제 DOM 이벤트를 감싸는 래퍼로, 리액트 이벤트가 실제 DOM으로 전파되기 전에 리액트가 중간에서 처리한다.

브라우저에서 이벤트 발생 -> 이벤트 처리 시스템이 document level 또는 root level에서 이벤트 리스닝 -> 내부 타입과 타겟 식별 -> 합성 이벤트 생성 -> 핸들러 실행 -> 이벤트 버블링 에뮬레이션 -> (선택)버블링 또는 타겟 단계에서stop propagation 적용

대충 갓난아기가 쿠키를 로켓배송시켰다고 생각하면 모든게 이해가 된다.

리액트 19

Next 13부분을 살펴본 뒤 보면 이해가 잘 된다. 아래에서 다루도록 하겠다.

11장 Next.js 13과 리액트 18

Nextjs 13의 주요한 변경사항

• 서버사이드 렌더링과 관련된 변화가 많이 있는 React 18을 채용하였다.
• 레이아웃 지원을 시작했다.
• 트랜스파일러로 Rust를 사용한 SWC를 출시하였다.
• 웹팩을 대체할 Turbopack을 출시하였다.

Next.js 돌아보기

서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), 클라이언트 사이드 렌더링(CSR), 그리고 Incremental Static Regeneration(ISR)을 지원하는 React 기반의 프레임워크이다. 이 프레임워크는 웹 개발에 있어서 빠른 성능, SEO 최적화, 그리고 개발자 친화적인 환경을 제공하기 위해 설계되었다.

Next.js는 Nest.js와 같은 별도의 서버 프레임워크 없이도 웹 애플리케이션의 전반적인 기능을 수행할 수 있으며, API 라우트를 통해 서버 사이드 로직 처리 역시 가능하다. 따라서 Next.js 하나로 클라이언트와 서버의 모든 동작을 처리할 수 있다.

pages 디렉토리 내의 각 파일은 라우트와 직접 매핑되므로, 파일 이름과 구조를 명확히 관리해야 한다.

클라이언트 사이드 코드와 서버 사이드 코드를 명확히 분리하며, 보안을 유지해야 한다.

서버 사이드

렌더링 방식: Next.js의 서버 사이드 렌더링은 초기 페이지 로드 시 사용자의 요청에 따라 즉시 HTML을 생성하고, 이를 클라이언트로 전송한다. 이 방식은 사용자에게 빠른 초기 로딩을 제공하고, 검색 엔진 최적화(SEO)에 유리하다.

API 라우트: /pages/api 디렉토리 내부에 파일을 배치함으로써 API 라우트를 설정할 수 있다. 이 라우트들은 서버에서만 실행되며, 데이터베이스 쿼리, 사용자 인증, 외부 API 호출 등 서버 사이드 로직을 처리한다.

데이터 페칭: 서버 사이드에서는 getServerSideProps, getStaticProps 등의 데이터 페칭 함수를 사용하여 페이지 렌더링 전에 필요한 데이터를 미리 가져올 수 있다.

클라이언트 사이드

하이드레이션: 서버로부터 받은 HTML은 클라이언트에서 React가 관리하는 동적인 웹 페이지로 "하이드레이션"되어 사용자와의 상호작용을 처리한다. 이 과정에서 클라이언트 사이드에서만 필요한 자바스크립트가 로드되고 실행된다.

동적 라우팅: 클라이언트 사이드 라우팅은 사용자가 페이지 간에 이동할 때 페이지를 새로 로드하지 않고, 필요한 데이터만을 비동기적으로 불러와 페이지를 업데이트한다. 이는 사용자 경험을 향상시킨다.

클라이언트 사이드 데이터 페칭: 페이지의 동적 부분에 대한 데이터는 클라이언트 사이드에서 fetch API나 Axios 같은 라이브러리를 사용해 비동기적으로 불러올 수 있다.

서버와 클라이언트 간의 상호작용

Next.js에서 서버와 클라이언트 사이의 상호작용은 주로 데이터와 상태를 공유하는 방식으로 이루어진다. 예를 들어, 서버에서 생성된 HTML 페이지는 클라이언트로 전송된 후, 사용자의 상호작용에 따라 필요한 데이터만을 클라이언트에서 불러와 업데이트한다. 또한, API 라우트를 통해 클라이언트는 서버에 데이터 요청을 보낼 수 있고, 서버는 이에 대한 응답을 처리하여 다시 클라이언트로 전송한다.

11.1 app 디렉터리의 등장

export default function App() {
  return (
    <div>
        Common Layout
    </div>
    <Routes>
        <Route ... >
        <Route ... >
    </Routes>

리액트에선 위와 같은 구조에서 Common Layout을 유지할 수 있으나, Next.js는 각각의 파일이 하나의 페이지가 되므로 공통 영역을 가질 수 없다. Next.js 13까지 공통된 것은 다음과 같았다.

_document.js _document.js 파일은 서버에서만 작동하는 파일이다. 이 파일은 웹 애플리케이션의 HTML 문서 구조를 정의하는 데 사용된다. 클라이언트 사이드 로직을 추가하는 것은 금지되어 있다. 그 이유는 _document.js가 초기 서버 사이드 렌더링 시에만 실행되며, 페이지를 네비게이션 할 때 재실행되지 않기 때문이다. 따라서 클라이언트 사이드에서 변화를 일으킬 수 있는 스크립트나 로직은 이 파일에 포함되어서는 안 된다.

_app.js _app.js 파일은 Next.js 애플리케이션의 루트 컴포넌트를 정의한다. 이 파일은 페이지 간의 상태 유지를 가능하게 하며, 애플리케이션 전반에 걸쳐 공통적으로 사용되는 레이아웃이나 페이지 전환, 타이틀 업데이트 등을 관리한다. 모든 페이지 요청에 대해 실행되기 때문에, _app.js는 전역 상태 관리나 라우팅 관리에 적합하다. _document.js와 달리, _app.js는 클라이언트 사이드에서도 실행되어 페이지 간에 일관된 상태를 유지할 수 있도록 한다.

그러나 위와 같은 요소를 사용하여서는 페이지별로 다른 레이아웃을 생성할 수 없기 때문에 제한적이었다. 이러한 사항을 레이아웃을 통해 극복하였다.

아래에서 구조를 살펴본다.

11.1.1 라우팅

기존에 Next.js는 프레임워크로서 파일시스템을 기반으로 페이지를 생성하였다. 정해진 디렉터리 구조 등을 따라야 했으며 이에 따라 생성되는 내용은 다음과 같다.

/pages/a/b.tsx(파일시스템) -> /a/b(URL)

이는 Next.js 13에 이르러 다음과 같이 변경되었다.

app/a/b -> /a/b

디렉터리 b 내에는 예약된 파일명만이 next.js에서 사용되게 된다. 예약된 파일명은 다음과 같다.

• layout.js
• page.js
• error.js

11.1.1.1 layout.js

export default function AppLayout({ children }: { children: ReactNode}) {
  return (
    <PageLayout>
        {children}
    </PageLayout>
  )
}

이와 같은 파일을 서브루트로 할당되는 서브디렉터리 내에 할당할 수가 있는데 이렇게 할당된 layout은 해당 위치부터 하위에 이르기까지 영향을 미친다.

루트의 경우에는 웹페이지에 필요한 기본 정보를 담아둘 수도 있다.

이를 통해 공통된 UI 뿐만 아리나 웹페이지를 시작하는데에 필요한 공통 코드를 삽입할 수도 있다. 다만 다음과 같은 주의사항을 준수하여야 한다.

• layout은 app 디렉터레 내부에서는 예약어이다. layout.{js|jsx|ts|tsx}는 공통 레이아웃 관리 목적으로만 사용한다.
• layout은 children을 props로 받아서 렌더링해야 한다.
• layout에서는 반드시 export default로 내보내는 컴포넌트가 있어야 한다.
• 비동기 작업을 수행할 수 있다는 점을 인지한다.

클라이언트 사이드: layout은 페이지 전환 시에도 유지되는 구조를 제공하며, 사용자 인터페이스의 일관성을 유지한다.

서버 사이드: 서버에서 페이지 요청 시에도 layout은 사용되어 일관된 HTML 구조를 생성한다.

11.1.1.2 page.js

기존에 Next.js에서 렌더링 되는 페이지의 역할을 맡았던 파일에 대한 예약어이다.

클라이언트 사이드: 각 페이지는 클라이언트 사이드에서 동적으로 렌더링된다.

서버 사이드: 첫 요청이나 페이지 새로고침 시에는 서버에서 페이지가 렌더링되고, 결과적으로 생성된 HTML이 클라이언트로 전송된다. 다음과 같은 props를 받는다.

params params 객체는 동적 라우팅을 사용할 때 URL의 경로 부분에서 정의된 변수들을 포함한다. 예를 들어, /posts/[id]라는 파일 경로로 정의된 페이지가 있고 사용자가 /posts/123 URL로 접속했다면, params 객체는 { id: '123' }와 같이 매핑된다. 이 객체는 페이지 경로의 각 세그먼트를 변수로 캡처하여 접근할 수 있게 해준다.

searchParams searchParams 객체는 URL의 쿼리 문자열 부분을 처리한다. 이 객체는 URLSearchParams 인터페이스를 기반으로 하며, URL의 쿼리스트링에서 키-값 쌍을 쉽게 읽거나 조작할 수 있다. 예를 들어, 사용자가 /search?query=nextjs URL로 접속했다면, searchParams.get('query')는 nextjs를 반환한다.

11.1.1.3 error.js

해당 라우팅 영역에서 사용되는 공통 에러 컴포넌트이다. 라우팅별로 서로 다른 에러 UI를 렌더링할 수 있다.

클라이언트 사이드: loading은 사용자가 새 페이지로 이동하는 동안 보여지는 상태이다. 페이지 로딩 중 사용자 경험을 개선하기 위해 사용된다.

서버 사이드: 서버 사이드에서는 loading 상태가 존재하지 않는다. 페이지 로딩 상태는 클라이언트에서 관리된다.

'use client' // Error components must be Client Components

export default function Error({error,reset}: {error: Error, reset: () => void}) {
  useEffect(() => {
    // Log the error to an error reporting service
    console.error(error)
  }, [error])

  return (
    <div>
      <button
        onClick={() => reset()}
      >
      </button>
    </div>
  )
}

error : 에러 정보를 담고 있음

reset : 에러 바운더리를 초기화 할 수 있는 함수

11.1.1.4 not-found.js

export default function NotFound() {
  return '404 Not Found'
}

찾을 수 없는 페이지를 렌더링 할 때 사용된다.

클라이언트 사이드: 사용자가 없는 페이지에 접근하려 할 때 not-found 페이지가 표시된다.

서버 사이드: 서버에서도 요청받은 URL이 유효하지 않을 경우 not-found 페이지를 렌더링하여 응답한다.

11.1.1.5 loading.js

export default function Loading() {
  return 'Loading...'
}

리액트 Suspense를 기반으로 해당 컴포넌트가 불러오는 중임을 나타낸다.

클라이언트 사이드: loading은 사용자가 새 페이지로 이동하는 동안 보여지는 상태이다. 페이지 로딩 중 사용자 경험을 개선하기 위해 사용된다.

서버 사이드: 서버 사이드에서는 loading 상태가 존재하지 않는다. 페이지 로딩 상태는 클라이언트에서 관리된다.

11.1.1.6 route.js

이것에 앞서 잠시 /app/api에 대해 살펴본다.

/app/api 디렉토리

/app/api 내부에 파일을 배치함으로써, 개발자는 서버 사이드 로직을 구현할 수 있다. 예를 들어, /app/api/user.js 파일을 생성하면, 이 파일은 http://myDomain/api/user 주소로 접근할 수 있는 API 엔드포인트가 된다. 이 파일 내에서는 데이터베이스 조회, 데이터 처리, 외부 API 호출 등 서버 사이드에서 필요한 작업을 수행할 수 있다.

API 라우트 파일 API 라우트 파일에서는 Next.js의 API 라우트 기능을 활용하여 HTTP 요청을 처리한다. 각 API 라우트 파일은 기본적으로 다음과 같은 구조를 가질 수 있다:

  export default function handler(req, res) {
  if (req.method === 'GET') {
    // GET 요청 처리 로직
    res.status(200).json({ message: 'This is a GET request' });
  } else if (req.method === 'POST') {
    // POST 요청 처리 로직
    res.status(201).json({ message: 'This is a POST request' });
  } else {
    // 지원하지 않는 HTTP 메소드에 대한 응답
    res.status(405).end();
  }
}

다시 돌아와서, 파일명 라우팅이 없어지고 위와 같은 내용은 디렉터리 라우팅으로 변경되었다고 한다. 즉 /pages/api를 기준으로 디렉터리를 추가하여 api 엔드포인트의 주소를 구성해야 하는 것이다. 다만 여기서 api 디렉터리를 사용하는 것은 컨벤션으로, 사실은 어떤 디렉터리를 사용하여도 route.ts가 있는 경우 해당 디렉터리는 라우팅 포인트로 작동한다.

/apps/internal-api/hello/route.ts

"curl -X GET "http://localhost:3000/internal-api/hello"

다만 page.tsx와 공존할 수 없다.

11.2 리액트 서버 컴포넌트

서버사이드 렌더링과 다른 개념이다.

11.2.1 기존 리액트 컴포넌트와 서버사이드 렌더링의 한계

리액트의 모든 컴포넌트는 클라이언트 사이드에서 작동하였다. 이는 즉 모든 코드가 클라이언트로 다운로드 되고, 클라이언트 사이드에서 리액트 돔을 구성한 뒤 작동하는 것을 의미한다.

서버사이드 렌더링에서는 서버에서 필요한 데이터를 모아 HTML을 생성하고, 클라이언트에서는 전송된 HTML을 렌더링 한 후 만들어진 DOM을 기준으로 하이드레이션을 진행한다. 이러한 구조에는 다음과 같은 한계점들이 존재한다.

• 자바스크립트 번들 크기가 0인 컴포넌트를 만들 수 없다. 즉, 컴포넌트가 클라이언트 사이드에서 실행되므로 실행에 필요한 자바스크립트 번들 파일을 포함하게 된다. 이것을 서버측에서 수행하길 원할 수 있다.

• 백엔드 리소스에 대한 직접적인 접근이 불가능하다. API를 이용하여야 한다. 클라이언트에서 백엔드 리소스에 직접 접근할 수 있을 수도 있다?

• 자동 코드 분할(code split)이 불가능하다. 코드가 필요하게 되는 시점에 동적으로 게으른 로딩을 하는것을 의미한다. 개발자가 일일히 설정해주고, 분기 등 처리가 일어난 후에야 로딩을 시작하기 때문에 분할의 이점이 없어지게 된다.

• 연쇄적인 로딩 중첩된 구조의 컴포넌트 로딩이 있는 경우, 그리고 각 컴포넌트들이 서버에 요청을 해야 하는 경우, 그 수만큼의 지연과 요청이 발생한다. 이러한 모든 과정이 서버에서 일어난다면 효율적일 것이다.

이러한 문제점들이 모두 리액트가 클라이언트를 중심으로 돌아가기 때문에 발생한다고 이야기 할 수 있다고 한다.

11.2.2 서버 컴포넌트란?

서버 컴포넌트(Server Component)란 하나의 언어, 하나의 프레임워크, 하나의 API와 개념을 사용하면서 서버와 클라이언트 모두에서 컴포넌트를 렌더링 할 수 있는 기법.

다음과 같이 세 종류로 이루어진다.

서버 컴포넌트 서버 수준에서 실행되어 그 결과값으로 정적인 결과물을 반환하는 컴포넌트로 다음과 같은 특성을 갖는다.

• 상태를 가질 수 없다.
• 렌더링 생명주기를 사용할 수 없다.
• DOM API에 접근할 수 없다.
• 서버에 있는 데이터에 접근할 수 있다.
• 다른 서버 컴포넌트를 렌더링하거나, (클라이언트 컴포넌트를 렌더링 할 수 있다)<-?

클라이언트 컴포넌트 클라이언트에서 실행되어 렌더링되는 컴포넌트

• 서버 컴포넌트를 불러오거나, 서버 전용 훅/유틸리티를 사용할 수 없다.
• 서버 컴포넌트를 자식으로 가질 수 있다. 서버 컴포넌트는 결과값 트리로 반환되기 때문이다.
• 상태나 생명주기 등을 가질 수 있다.

공용 컴포넌트 서버와 클라이언트 모두에서 사용할 수 있으며, 두 제약을 동시에 받는다.

리액트는 모든 컴포넌트를 공용컴포넌트로 판단한다(안전).

다만 파일의 첫 줄에 'use client'를 작성하는 경우 클라이언트 컴포넌트로 간주한다.

11.2.3 서버 사이드 렌더링과 서버 컴포넌트의 차이

서버 사이드 렌더링의 장점을 사용할 수 있는 컴포넌트를 의미하는 것이 서버 컴포넌트이다.

기본적으로 작동이 클라이언트일 것으로 예상되기 때문에, 서버 컴포넌트라는 이름이 붙었다.

서버 작동이 기본일 것이라고 생각하는 경우, 양쪽의 장점을 취하기 위해 클라이언트 컴포넌트가 되었을 것이다.

11.2.4 서버 컴포넌트는 어떻게 작동하는가?

• 서버가 렌더링 요청을 받는다.
• 서버는 받은 요청에 따라 컴포넌트를 JSON으로 직렬화한다.
• 빈 부분은 플레이스 홀더 형식으로 남겨둔 채 결과물을 보낸다.
• 클라이언트 사이드에서 결과물을 역직렬화 한 후 렌더링을 수행한다.
• 브라우저가 리액트 컴포넌트 트리를 구성한다.
• 트리를 렌더링한다.
• DOM에 커밋한다.

여기서 특별한 점

• 클라이언트로 정보를 스트리밍 형태로 보내 빠르게 반응할 수 있다.
• 컴포넌트별로 번들링이 별개로 되어 있다.
• HTML이 아니라 JSON 방식으로 보내진다. 이는 복잡하게 구성된 형태를 조화롭게 구성하기 위해서이다.

11.3 Next.js에서의 리액트 서버 컴포넌트

위에서 살펴본 것과 같이

서버 컴포넌트는 클라이언트 컴포넌트를 불러올 수 없다. 클라이언트 컴포넌트는 서버 컴포넌트를 내용으로 포함할 수 있다.

11.3.1 새로운 fetch 도입과 getServerSideProps, getStaticProps, getInitial Props의 삭제

fetch가 데이터 요청의 표준으로서 사용된다. 비동기적으로 요청하며 다음과 같이 사용한다.

async function getData() {
  const result = await fetch('https://api.imagoworks.com')

  return result.json()
}

export default function Page() {
  const data = await getData()

  return(
    <main>
        <Children data={data} />
    </main>
}

내부적으로 캐싱을 하기 때문에 동일한 요청이 서버 컴포넌트 트리 내에 있을 경우, 중복 요청을 방지한다.

11.3.2 정적 렌더링과 동적 렌더링

정적 렌더링은 미리 해놓는것 - 캐싱 활용

동적 렌더링은 서버에서 요청이 올때마다 렌더링 하는 것

이것은 모두 결국 fetch가 동작시에 캐싱을 하는지 아닌지에 따라 결정되는데, 그 명세는 다음과 같다.

• fetch(URL, { cache: 'force-cache' }) : 캐싱한다.
• fetch(URL, { cache: 'no-store}) : 매번 새로운 데이터를 불러온다.
• fetch(URL, { next: { revalidate: 10 } }) : 일정 기간동안만 캐싱을 유지한다.

11.3.3 캐시와 mutating 그리고 revalidating

export const revalidate = 60

위와 같이 루트에 설정해 놓는 경우, 위의 기간에 따라 캐시를 갱신한다. 갱신 과정에서 공백이 생기지 않도록 다음과 같이 한다.

기간 내엔 캐시된 데이터 보여준다 - 해당시간이 지나도 데이터를 불러오기 전까진 캐싱된 데이터를 보여준다 - 데이터가 불러와지면 데이터를 캐싱하고, 실패했을 경우 이전에 캐시된 데이터를 보여준다.

11.3.4 스트리밍을 활용한 점진적인 페이지 불러오기

TTFB(Time To First Byte)의 시간을 줄여주고, 최초 콘텐츠풀 페인팅(FCP; First Contentful Paint)을 개선하는데 큰 도움을 준다.

11.4 웹팩의 대항마, 터보팩의 등장(beta)

기존 자바스크립트로 만들어지고 제공되는 기능을 Rust나 Go등 다른 언어를 사용해 제공 많은 프로젝트에서 바벨을 대신해 사용하고 있다. 웹팩 대비 700배 Vite보다 10배 빠르다고 소개하고 있다고 한다.

11.5 서버 액션(alpha)

API를 생성하지 않고 함수 수준에서 직접 서버에 접근해 데이터 요청 등을 수행할 수 있는 기능이다. 책 기준으로는 서버 액션을 활성화하기 위해 next.config.js에서 실험 기능을 활성화해야 한다고 하고 있으며, "use server"키워드를 사용해야 한다고 한다.

아래와 같은 자세한 내용은 생략한다.

11.5.1 form의 액션

11.5.2 input의 submit과 image의 formAction

11.5.3 startTransition과의 연동

11.5.4 server mutation이 없는 작업

11.5.5 서버 액션 사용 시 주의할 점

11.6 그 밖의 변화

이 부분은 책에서도 알아서 찾아보라고 하면서 생략한다. 나도 생략한다.

서버 컴포넌트 등은 단순하게 프로젝트를 구성해서는 사용하기 어렵기 때문에, 프레임워크를 통한 적용이 거의 필수적이며, 리액트 팀도 이러한 부분을 구현하기 위해서는 프레임워크와의 협업이 필요하다고 판단, Vercel등과 활발이 협업하고 있다고 한다. 고려하자.

11.7 맛보기는 생략한다.

근황 알아보기

트랜스파일러 / 컴파일러

SWC(Speedy Web Compiler) JavaScript 및 TypeScript 컴파일러로, 특히 Babel과 같은 기존 도구들에 비해 그 성능과 속도에서 두드러진 차이를 보인다. Rust로 작성되어 있어 싱글 스레드에서는 Babel보다 최대 20배, 멀티 코어 환경에서는 최대 70배 빠른 속도를 제공한다 https://blog.logrocket.com/why-you-should-use-swc/

주요 특성 및 비교 : 성능: SWC는 빌드 시간이 중요한 프로젝트에 적합할 만큼 빠른 속도로 컴파일을 수행한다. Babel, Sucrase, 심지어 esbuild보다도 빠를 수 있는 성능을 자랑한다

*호환성: * SWC는 최신 JavaScript 기능을 포함한 JSX 및 TypeScript를 지원한다. 주로 새로운 브라우저에 최적화되어 있으며, 구형 브라우저와의 호환성을 위해서는 추가 설정이 필요할 수 있다

인테그레이션: SWC는 개발 환경에 통합하기가 비교적 간단하다. Webpack과 같은 인기 있는 번들러와 빌드 시스템에 swc-loader를 사용하거나 Jest의 성능을 향상시키기 위한 플러그인을 제공한다. 설정은 주로 .swcrc 파일을 통해 코드의 변환 방법을 지정함으로써 이루어진다

커뮤니티 및 지원: SWC는 Babel에 비해 상대적으로 신생이지만, 주요 프로젝트와 회사에서의 사용 증가로 인해 커뮤니티가 성장하고 있다.

아래 벤치마크 영상을 확인한 결과 바벨보다는 확연히 뛰어난 성능을 보이나 경합은 있는것으로 보인다. 추후 커뮤니티 활성도 등을 고려하여 선택하면 될 것으로 생각된다. https://www.youtube.com/watch?v=1p-Vjle0vZ0

NextJS 버전

https://nextjs.org/blog 위 블로그에서 아주 간략하게 축약된 주요 변경사항들을 확인할 수 있다. 2022.10.25 : 13 2022.12.22 : 13.1 2023.02.23 : 13.2 2023.04.06 : 13.3 2023.05.04 : 13.4 2023.10.19 : 13.5

2023.10.26 : 14 2024.01.18 : 14.1 2024.04.11 : 14.2

현재에는 TurboPack이 정식 적용되었고, ServerAction이 안정화되었으며 여러가지 기능들이 추가되었다.

서버컴포넌트

Next.js 13의 서버컴포넌트 - https://blog.logrocket.com/react-server-components-next-js-13/ 2024.02 리액트 트렌드 - https://www.robinwieruch.de/react-trends/ 2024.02 리액트팀 무슨일하고 있나 - https://chatgpt.com/c/3d223760-aa69-4356-bd72-abf44306ead3

리액트 서버 컴포넌트(React Server Components, RSC)는 성능 향상과 네트워크 요청 감소에 기여한다.

Next.js 13에서는 RSC가 기본적으로 활성화되어 있으며, 데이터를 서버에서 가져오고 이를 스트리밍하는 방식으로 구현되어 있다. 이 방식은 전통적인 SSR과 SSG의 의 장점을 취하고 단점을 상쇄하여 새로운 방향성으로 제안되고 있다.

RSC의 도입은 데이터를 서버에서 컴포넌트 수준에서 가져오는 새로운 아키텍처를 가능하게 한다. 이는 클라이언트와 서버 간의 '워터폴' 요청 방식을 개선하며, 서버에서 데이터 처리가 진행되고 클라이언트는 최종적으로 컴포넌트를 받아 렌더링만 수행함으로써 응답 시간과 성능이 크게 향상된다.

위 링크를 참조하여서 보면, 리액트 팀은 RSC를 더욱 발전시키기 위해 지속적으로 연구하고 개선할 예정이라고 한다. 이에 따라 서버와 클라이언트 간에 일관된 프로그래밍 모델을 사용할 수 있게 하며, 다양한 환경에서 애플리케이션을 운영할 수 있도록 지원할 것으로 예상된다.

리액트 19

동시 렌더링 지원: React 19는 동시 렌더링을 기본 모드로 지원한다. 이는 UI 업데이트를 더 작은 비동기 작업으로 세분화하여, 우선순위가 높은 업데이트를 먼저 처리함으로써 사용자 경험을 개선한다.

Suspense 개선: React 19는 Suspense 기능을 개선하여, 로딩 상태와 데이터 종속성을 선언적으로 처리할 수 있다. 이를 통해 데이터 기반 애플리케이션 개발이 간소화된다.

서버 측 렌더링 개선: React 19는 서버 측 렌더링을 통해 TTFB(Time to First Byte)와 SEO 성능을 향상한다. 서버에서의 렌더링 개선은 클라이언트로의 응답 속도를 빠르게 하여 사용자 경험을 향상시킨다.

점진적 도입: React 19는 기존 React 프로젝트와의 호환성을 유지하면서 점진적으로 업그레이드할 수 있는 환경을 제공한다. 이는 개발자가 새로운 기능을 손쉽게 도입할 수 있게 한다.

성능 최적화 기법: React 19는 런타임 효율을 높이고 번들 사이즈를 줄이기 위한 다양한 성능 최적화 기술을 사용한다. 이는 애플리케이션의 렌더링 속도와 메모리 관리를 향상시킨다.

디버깅 개발자 도구: React 19는 개발자가 컴포넌트의 수명 주기와 성능 문제를 보다 정밀하게 진단할 수 있도록 고급 디버깅 및 프로파일링 도구를 제공한다.

모듈의 실행 시점:

모듈 임포트 시 실행:

모듈이 다른 파일에서 임포트될 때, 해당 모듈의 최상위 레벨 코드는 실행된다. 이 코드에는 함수, 클래스, 변수의 초기화가 포함될 수 있다. 이러한 실행은 모듈이 처음 임포트될 때 단 한 번만 발생한다.

export만 있고 import되지 않는 모듈:

모듈이 단지 export를 하고 다른 곳에서 명시적으로 임포트되지 않는 경우, 그 모듈의 코드는 실행되지 않는다. 모듈의 코드를 실행시키기 위해서는 어딘가에서 그 모듈을 임포트해야 한다.

Import 시점의 실행:

모듈이 임포트되는 순간, 해당 모듈의 코드가 실행되며, export된 객체들이 메모리에 로드된다. 이 후, 해당 모듈을 임포트한 모든 파일에서 export된 객체들을 사용할 수 있다.

예시: index.ts 파일이 프로그램의 진입점일 때, index.ts에서 다양한 모듈을 임포트하면, 그 모듈들의 코드는 index.ts가 실행될 때 실행된다. 예를 들어, index.ts에서 다음과 같이 모듈을 임포트하는 경우:

// index.ts
import './setup';  // setup 모듈에서 코드가 실행됨
import { functionFromModuleA } from './moduleA'; // moduleA의 코드가 실행됨

functionFromModuleA();

여기서 setup 모듈과 moduleA의 코드는 index.ts가 로드되는 시점에 실행된다. setup은 명시적으로 아무것도 import하지 않아도 그 내부의 코드가 실행되며, moduleA는 필요한 함수나 변수를 export한다.

결론: 모듈은 임포트된 시점에 실행되며, 해당 모듈의 모든 최상위 코드가 처리된다. export만 있고 실제로 임포트되지 않은 모듈의 코드는 실행되지 않는다.

Self-Paced Courses 에는 유료/무료가 섞여있는데, 이쪽에도 무료 강좌들 괜찮은게 별도로 있음 무료 강좌 Generative AI Explained Building a Brain in 10 Minutes An Even Easier Introduction to CUDA Essentials of Developing Omniverse Kit Applications Building Video AI Applications at the Edge on Jetson Nano Assemble a Simple Robot in Isaac Sim Build Beautiful, Custom UI for 3D Tools on NVIDIA Omniverse Develop, Customize, and Publish in Omniverse With Extensions Disaster Risk Monitoring Using Satellite Imagery Getting Started with AI on Jetson Nano Getting Started with USD for Collaborative 3D Workflows Easily Develop Advanced 3D Layout Tools on NVIDIA Omniverse Getting Started with DOCA Flow How to Build Custom 3D Scene Manipulator Tools on NVIDIA Omniverse Digital Fingerprinting with MorpheusTM Introduction to DOCA for DPUs Self-Paced Courses의 무료 강좌들 Building RAG Agents for LLMs Augmenting LLMs using Retrieval Augmented Generation Accelerate Data Science Workflows with Zero Code Changes

Jest에서 ModuleNameMapper를 통해 경로별칭을 이용하여 불러오는 과정에서 발생한 문제이다. 최종수정일 : 2024.02.28

02 source code

/src/features/featuredir/feature.spec.ts

import { mine } from 'mine';

describe('captureBatchThumbnails', () => {
  it('Initialize CrownCase', () => {
    console.log(mine(1, 2));
  });
});

/src/mine/index.ts

export function mine(a: number, b: number): number {
  return a + b;
}

/jest.config.js

export default {
  preset: 'ts-jest',
  testMatch: ['**/__tests__/**/*.+(ts|tsx|js)', '**/?(*.)+(spec|test).+(ts|tsx|js)'],
  transform: {
    '^.+\\.(ts|tsx)$': ['ts-jest', { tsconfig: 'tsconfig.esm.json' }],
  },
  testPathIgnorePatterns: ['/node_modules/', '/dist/'],
  roots: ['<rootDir>'],
  moduleFileExtensions: ['js', 'mjs', 'cjs', 'jsx', 'ts', 'tsx', 'json', 'node'],
  moduleNameMapper: {
    '^@constants/(.*)$': '<rootDir>/src/constants/$1',
    '^@types/(.*)$': '<rootDir>/src/types/$1',
    '^classes/(.*)$': '<rootDir>/src/classes/$1',
    '^features/(.*)$': '<rootDir>/src/features/$1',
    '^lib/(.*)$': '<rootDir>/src/lib/$1',
    '^managers/(.*)$': '<rootDir>/src/managers/$1',
    '^modules/(.*)$': '<rootDir>/src/modules/$1',
    '^utils/(.*)$': '<rootDir>/src/utils/$1',
    '^mine/(.*)$': '<rootDir>/src/mine/$1',
  },
};

03 문제

04 해결

ModuleNameMapper에서 하위항목이 있어야하도록 정의되었기 때문이다. 다음과 같이 변경하였다. /jest.config.js

export default {
  preset: 'ts-jest',
  testMatch: ['**/__tests__/**/*.+(ts|tsx|js)', '**/?(*.)+(spec|test).+(ts|tsx|js)'],
  transform: {
    '^.+\\.(ts|tsx)$': ['ts-jest', { tsconfig: 'tsconfig.esm.json' }],
  },
  testPathIgnorePatterns: ['/node_modules/', '/dist/'],
  roots: ['<rootDir>'],
  moduleFileExtensions: ['js', 'mjs', 'cjs', 'jsx', 'ts', 'tsx', 'json', 'node'],
  moduleNameMapper: {
    '^@constants(.*)$': '<rootDir>/src/constants$1',
    '^@types(.*)$': '<rootDir>/src/types$1',
    '^classes(.*)$': '<rootDir>/src/classes$1',
    '^features(.*)$': '<rootDir>/src/features$1',
    '^lib(.*)$': '<rootDir>/src/lib$1',
    '^managers(.*)$': '<rootDir>/src/managers$1',
    '^modules(.*)$': '<rootDir>/src/modules$1',
    '^utils(.*)$': '<rootDir>/src/utils$1',
    '^mine(.*)$': '<rootDir>/src/mine$1',
  },
};

(이전 작업 진행중)

https://philipsung.notion.site/f1bdfa4049c3418b995fef803882a542?v=42fee1ecdb0b46e09e6419a31c533c6c&pvs=4

본 문서에서는 딥러닝 기반 추천 시스템을 다루기 위해, 추천 시스템 일반에 대하여 개괄적인 내용을 다룬다.

최종수정일 : 2023.11.23

02 추천시스템 구조

참조 : https://yamalab.tistory.com/117

2019년 기준 추천 시스템은 일반적으로 아래와 같은 절차를 따른다고 한다.

Candidate generate part

수많은 상품 중, 후보가 될 만한 상대적으로 적은 수의 상품으로 선택지를 줄이는 것을 목적으로 한다. 후보군 산출 단계에서는 여러 개의 전략들을 합쳐서(merge) 유저의 관심사가 최대한 많이 포함되도록 coverage를 넓히는 것이 좋다.

Intention prediction part

의도 예측 단계에서는 유저의 ‘최신 행동’에 기반하여 click, buy 등의 다음 행동을 예측한다.

Ranking part(prediction CTR/CR)

의도 예측 단계 후에, 지금까지 선정된 수백 개의 candidate를 내로우 다운(Narrow down) 형식으로 추려낼 필요가 있다. 이를 위해 CTR/CR(Click-Through Rate/ Click Rate)를 예측하는 모델을 통해 상품이 노출될 순위를 결정한다.

03 추천시스템의 평가

03.01 Basics

추천시스템을 평가하기 위하여는 아래 개념들에 대해 알아야 한다.

Precision $Precision = \frac{True Positive}{TruePositive + False Positive}$

e.g. 범죄자라고 판단한 사람 중 진짜 범죄자가 몇명인가에 대한 비율이다. e.g. 우리가 추천한 아이템 중에 사용자가 정말 관심있어하는 아이템의 비율이다.

Recall $Recall = \frac{True Positive}{True Positive + False Negative}$

e.g. 현재까지 본 범죄자들 중에서 실제로 범죄자라고 판단한 경우가 몇명인가에 대한 비율이다. e.g. 실제로 사용자가 관심있어하는 아이템 중에 우리가 추천한 아이템의 비율이다.

우리가 추천한 아이템 개수: 5 추천한 아이템 중 사용자가 관심있어하는 아이템 개수 : 2 실제로 사용자가 관심있어하는 아이템 개수 : 3

Precision = 2/5 Recall = 2/3

~@K 추천된 리스트 중에서 상위 K개만큼만 추출하여 평가하겠다는 의미이다.

03.02 Precision@K

$Precision@K = \frac{user;interested;items}{recommended;k;items}$

추천한 K개의 아이템 중 사용자가 관심있어하는 아이템의 수이며, 순서 등은 고려되지 않는다.

03.03 Recall@K

$Recall@K = \frac{recommended;interested;item}{all;interested;items;of;user}$

사용자가 관심있어하는 아이템의 수 대비 추천된 실제 관심있는 아이템의 수이며, @K의 경우 K개를 넘을 수 없다.

03.04 MRR : Mean Reciprocal Rank

$MRR = \frac{1}{Q}\sum_{i}^Q \frac{1}{rank_{i}}$

MRR은 각각의 질의 Q에 대해, 추천해 준 품목 중 사용자의 선호가 있는 항목이 최초로 등장한 것이 몇번째인지 파악하고, 그 역수를 취한다. 첫번째만 취하므로, 최적의 상품이 무엇인가에 대해 초점을 둔다.

첫번째 질의에서, 사용자가 선호하는 아이템이 두번째에, 두번째 질의에서 사용자가 선호하는 아이템이 세번째에 있었다면 계산식은 다음과 같다.

$MRR = \frac{1}{2}*(\frac{1}{2} + \frac{1}{3})$

03.05 MAP : Mean Average Precision

Average Precision

$AP@K = \frac{1}{K}\sum_{i=1}^K P(i)*rel(i)$

P(i) : 해당 인덱스 i까지의 Precision rel(i) : 해당 인덱스 i에서 user engagement가 일어났는지 여부(0 | 1)

위 AP는 한명의 사용자에 대한 것으로, 전체 사용자에 대해 AP를 평균 낸 것을 mAP라고 한다.

$MAP@K = \frac{1}{|U|}\sum_{u = 1}^{|U|}(AP@K)_u$

03.06 nDCG@K : Normalized Discounted Cumulative Gain

DCG

$DCG_p = \sum_{i=1}^{p}\frac{rel_i}{\log_2(i+1)}$ 또는 $DCG_p = \sum_{i=1}^{p}\frac{2^{rel_i}-1}{\log_2(i+1)}$

DCG는 추천항목의 관련성(별점 등)을 순위에 로그를 취해 나눈 값으로 나누어 순차적으로 합한 값이다. 후순위의 항목일수록 분모가 커지고, 관련성이 높을수록 분자가 커지므로 점수가 높을수록 더 뛰어난 성능을 나타낸다.

IDCG(Ideal DCG) IDCG는 연관성이 높은 항목 순으로 높은 순위에 배치한 이상적인 DCG값을 이야기 한다. 연관성이 [5,4,3,2,1]인 항목이 있는 경우, IDCG는 다음과 같다.

$IDCG = \frac{5}{\log_2{2}}+\frac{4}{\log_2{3}}+\frac{3}{\log_2{4}}+\frac{2}{\log_2{5}}+\frac{1}{\log_2{6}}$

nDCG

$nDCG_p = \frac{DCG_p}{IDCG_p}$

DCG를 IDCG로 나누어 얻은 정규화된 값을 nDCG라고 부른다.

03.08 MAE : Mean Absolute Error

$MAE = \frac{1}{|\hat{R}|}\sum_{\hat{r}{ui}\in\hat{R}} |r{ui} - \hat{r}_{ui}|$

$_{\hat{R} = 예측한;평점의;개수}$

MAE는 추천항목의 적절성을 평가하는 것이 아니고, 항목의 평점예측을 수행하여 평가한다.

03.07 RMSE : Root Mean Square Error

$RMSE = \sqrt{\frac{1}{|\hat{R}|}\sum_{\hat{r}{ui}\in\hat{R}} (r{ui} - \hat{r}_{ui})^2}$

RMSE는 추천항목의 적절성을 평가하는 것이 아니고, 항목의 평점예측을 수행하여 평가한다.

04 추천시스템 종류 및 방법론

[ 추천을 받는 대상자 / 추천되는 대상 / 추천 규칙 자체] 중 어느쪽에 중점을 두는지에 따라 크게 [ Collaborative / Content-based / Rule-based ] 로 나뉜다. 조합되는 경우 Hybrid로 부른다. 이에 대한 내용은 깊게 다루지 않는다.

대신, 위 분류와 상관 없이, 독립적으로 또는 복합적으로 적용되는 추천 방법론들에 대해 다룬다. 아래 방법론들은 중복되거나 서로 포함관계에 있을 수 있다.

(작성중 - 예상되는 주요 방법론 :)

04.01 Simple Rule based

04.02 Matrix factorization based

04.03 Sequential based

04.04 Embedding based

04.05 Deep Learning based

04.06 Transformer based

04.07 Generative model based

ESLint는 코딩 컨벤션에 위배되는 코드나 안티 패턴을 자동 검출하는 도구다. 코딩 컨벤션은 사전에 작성된 특정 형태를 따를 수도 있고, 사용자가 직접 작성할 수 있다.

02 생성

npx eslint --init

03 규칙(Rules)

no-unused-vars

module.exports = {
 ...
 rules: {
   "no-unused-vars": "off"
 }

99

React에서 chrome API를 사용하려 하면 다음과 같은 오류를 확인할 수 있다.

'chrome' is not defined no-undef

이는 다음과 같은 세 가지 방법으로 해결할 수 있다.

01. add /*global chrome*/ at top

/*global chrome*/
import React, { Component } from 'react';
import './App.css';

02. modify eslint rule locally

/* eslint-disable no-undef */

function callback(val) {
   console.log(val)
}

chrome.topSites.get(callback);
/* eslint-enable no-undef */

03. modify eslint config

module.exports = {
 ...otherConfigs,
 globals: {
   chrome: true
 }
}

리액트를 사용할 때 처음에 ESLint configuration이 숨겨진 채로 내부적으로 작동하는데, 이 때 no-undef rule이 활성화되어 있기 때문에 발생하는 문제이다.

본 문서에서는 크롬 익스텐션 개발을 위한 개괄적인 내용을 다룬다.

(작성중)

02 구조

크롬익스텐션은 크게 background,content-script,popup세 가지 요소로 구성되며, 이 세 가지 구성요소를 포함하여 extenstion에 관한 사항들은 manifest.json에 명기된다.

manifest.json

background 크롬 익스텐션이 실제로 동작하는데 필요한 스크립트이다 storage에 저장하거나하는 등의 액션은 모두 background 스크립트에서만 동작 가능하다 별도의 개발자 도구 창을 제공한다.

content-script 사용자 화면의 DOM에 접근할 수 있는 유일한 스크립트

popup 크롬 익스텐션 버튼을 눌렀을 때 아래에 뜨는 팝업창을 위한 스크립트 및 html

02.01 manifest.json

기본정보 등록 service-worker 등록 content-script 등록 popup 등록 permissions

03

크롬 익스텐션을 구성하고 있는 세 가지 요소는 Message Passing 방식으로 소통한다. 참조 : https://velog.io/@broccolism/%ED%81%AC%EB%A1%AC-%EC%9D%B5%EC%8A%A4%ED%85%90%EC%85%98-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8%EB%81%BC%EB%A6%AC-%ED%86%B5%EC%8B%A0%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95

03.01 popup - background

//sender
chrome.runtime.sendMessage("message");

//receiver
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
   console.log(message);
});

03.02 contentScript - background

// content-script.js
chrome.runtime.sendMessage({ "key": "value" });

// background.js
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
   console.log(message);
});

99 참조자료

익스텐션개요 https://tidyline.gitbook.io/today-i-learned/etc/chromeextension 네이버카페글제목가져오는Extension만들기 https://m.blog.naver.com/siryua/221496597007

판다스에는 크게 세 가지 자료구조가 존재한다. 1차원 자료구조인 Series, 2차원 자료구조인 DataFrame, 3차원 자료구조인 Panel이 있다. 본 문서에서는 판다스에서 사용하는 자료구조와 그 속성, 메서드 등에 대해서 다룬다.

최종수정일 : 2023.11.22

02 자료구조

02.01 Series

Series는 value와 index의 형태를 지니는 Pandas의 자료 구조이다. 일련의 시퀀스 데이터를 받아들이는데, 별도의 인덱스 레이블을 지정하지 않으면 자동적으로 0부터 시작되는 디폴트 정수 인덱스를 사용한다.

import pandas as pd

dict = {'a':1, 'b':2, 'c':3}
list = [1,3,7]

indexed_series = pd.Series(dict)
unindexed_series = pd.Series(list)

print(indexed_series)
print(unindexed_series)

#result
a  1
b  2
c  3
dtype: int64

0  1
1  3
2  7
dtype: int64

02.02 DataFrame

DataFrame은 시퀀스 데이터를 받아 column과 row로 구성된 2차원 자료구조를 형성한다.

import pandas as pd

df_dictionary = pd.DataFrame({'a': [1,2,3], 'b' : [4,6,8]})
df_list = pd.DataFrame([3,6,9],[4,8,12])

#result
   a  b
0  1  4
1  2  6
2  3  8

   0  1  2
0  3  6  9
1  4  8  12

딕셔너리로 생성할 경우 딕셔너리 키가 column index가 되며, 값은 해당 열의 원소가 된다. 리스트로 생성할 경우 하나의 리스트가 하나의 행이 된다.

02.03 Panel

Panel은 3차원 자료구조이다.

03 연산

03.01 Indexing

03.01.01 Series Indexing

dict = {'a':1, 'b':2, 'c':3}
list = [1,3,7]

indexed_series = pd.Series(dict)
unindexed_series = pd.Series(list)

indexed_series['a']
#result : 1

unindexed_series[3]
#result : 7

Series는 일반 리스트나 딕셔너리처럼 접근할 수 있다.

03.01.02 DataFrame Indexing

df_dictionary = pd.DataFrame({'a': [4,8,12], 'b' : [3,6,9]})

#column indexing
df_dictionary['a']
#result : 
0    4
1    8
2    12

#iloc value indexing
df_dictionary.iloc[1,1]
#result : 6

#iloc range indexing
df_dictionary.iloc[0:2,0:2]
#result :
   a  b
0  4  3
1  8  6

#sequence indexing
boolean_series = pd.Series([True,True,False])
df_dictionary[boolean_series]
#result :
   a  b
0  4  3
1  8  6

column indexing DataFrame에서 열 인덱스로 인덱싱할 경우 해당 열 전체가 추출된다.

iloc indexing 위치를 지정할 경우 해당 위치의 값이, 범위를 지정할 경우 해당 지점 왼쪽 위까지의 프레임이 포함된다.

sequnce indexing 데이터프레임의 행 수와 같은 크기의 boolean sequence(series, list)를 인덱싱에 사용할 경우, 사용된 시퀀스의 값이 True인 행만을 반환한다.

대부분의 프로젝트에서는 외부 라이브러리의 목록과 버전을 별도로 관리하여 언제나 같은 실행환경을 구축하는 방법을 가지고 있다. JavaScript기반 프로젝트는 일반적으로 package.json을 통해 관리한다.

파이썬 도한 마찬가지로 이렇게 라이브러리 목록을 가지고 있으며, 이를 실행하기 위한 실행 환경을 프로젝트마다 별도로 구축하는 것이 가능하다. 본 문서에서는 이와 관련된 내용을 정리한다.

최종수정일 : 2023.12.01

02 현재 환경 확인

02.01 파이썬의 설치 경로 확인

import sys
sys.executable

#result : 'C:\\Users\\myPC\\.virtualenvs\\myPC-aubkC56d\\Scripts\\python.exe'

02.02 모듈 경로 확인

import numpy

print(np)

#result : <module 'numpy' from 'C:\\Users\\myPC\\.virtualenvs\\myPC-aubkC56d\\Lib\\site-packages\\numpy\\__init__.py'>

03 Python 버전 관리

03.01 pyenv

모듈에 따라 사용 가능한 다양한 Python의 버전을 유동적으로 사용하기 위해서 pyenv를 사용한다. windows 운영체제의 경우 2023년 11월 기준 정식으로 지원하지는 않으나, kirankotari의 pyenv-win의 fork를 사용한다.

Invoke-WebRequest -UseBasicParsing -Uri "https://raw.githubusercontent.com/pyenv-win/pyenv-win/master/pyenv-win/install-pyenv-win.ps1" -OutFile "./install-pyenv-win.ps1"; &"./install-pyenv-win.ps1"

about_Execution_Policies오류가 발생할 경우 아래와 같은 방법을 사용한다.

Get-ExecutionPolicy
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

pyenv가 설치된 경우, 아래와 같은 명령어로 사용할 파이썬의 버전을 선택한다.

#show installable versions of python
pyenv install -l 

#install python version 3.11.6
pyenv install 3.11.6

#set global python version 3.11.6
pyenv global 3.11.6

#set directory's local python version 3.9.13
mkdir myDirectory
cd ./myDirectory
pyenv local 3.9.13

#show installed python versions
pyenv versions

04 가상환경 설정

Pipenv는 javascript 개발환경에서의 package.json과 같은 패키지 관리 시스템의 장점을 도입하는 것과 같은 효과를 같는다.

python의 다른 가상환경 설정 방법인 venv는 쉽게 가상환경을 구축할 수 있지만, 패키지 관리는 pip를 사용한다. pip는 종속성 관리를 requirementes.txt로 수동으로 관리한다. 패키지를 삭제할 때도 종속성을 수동으로 관리해야 하는 불편함이 있기 때문에 pipenv로 편리하고 안정적으로 패키지 관리를 할 수 있다.

04.01 설치

pip install pipenv

mkdir myDirectory
cd myDirectory

pipenv --python 3.11.6
pipenv shell
pipenv install torch
#(NewVEnv-IscNwJwu) C:\Users\myPC\Desktop\NewVEnv>

위와 같은 과정을 통해 pipenv shell에 접속하여 패키지를 관리할 수 있다. pipenv --python version을 통해 Pipfile 파일을 생성할 수 없는 경우, 상위 폴더에 있는 Pipfile을 찾아 삭제해본다.

위와 같이 실행한 경우 Windows10 환경에서는 일반적으로 아래 경로에 가상환경에 대한 메타데이터가 생성된다.

C:\Users\UserName\.virtualenvs

05 가상환경에서 패키지 설치

05.01 pytorch cuda

pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

파이토치에서 제공하는 위와 같은 옵션은 보안상의 문제로 사용이 불가능 할 수 있다. 이러한 경우 Pipfile을 아래와 같이 수정하여 옵션을 적용할 수 있다.

#Pipfile
[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[[source]]
url = "https://download.pytorch.org/whl/cu121"
verify_ssl = false
name = "pytorch"


[packages]

[dev-packages]

[requires]
python_version = "3.10"

pipenv install --index=pytorch torch
pipenv install --index=pytorch torchvision
pipenv install --index=pytorch torchaudio

#result
...
[packages]
torch = {version="*", index="pytorch"}
torchvision = {version="*", index="pytorch"}
torchaudio = {version="*", index="pytorch"}
...

99 참조자료

가장보통의파이썬 개발환경 https://jonnung.dev/python/2019/11/23/ordinary-python-development-environment/#gsc.tab=0 pyenv https://docs.kanaries.net/ko/topics/Python/python-version-manager pipenv등장배경 https://heytech.tistory.com/320 pipenv https://medium.com/@erish/python-pipenv-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-961b00d4f42f 파이썬가상환경 비교 https://devbull.xyz/python-create-environment/ 모듈찾는 위치 https://livetodaykono.tistory.com/22

공간에 객체가 존재한다고 하여도, 카메라로 표현되는 "시점"이 존재하지 않으면 이미지로 인식될 수 없다. 본 문서에서는 모든 3D 구성에서 시점의 역할을 담당하고, 보여지는 배합을 조절하는 카메라 객체에 대한 내용을 개괄적으로 다룬다.

최종수정일 : 2023.11.06

02 기초

3D 구성요소의 카메라는 기본적으로 아래와 같은 개념에 의해 "frustum"을 정의한다.

Near 공간에 정의된 물체가 보이기 시작하는 지점

Far 물체가 보이는 마지막 시점. 이 시점을 넘어가면 너무 멀어서 보이지 않는다.

FOV(Field Of View) 종종 시야각이라고도 불린다. 시야의 너비를 나타내며 시야각이 너무 커지면 공간이 이미지에 표현되기 위해 어안렌즈 효과가 나타난다.

aspect 시야각에서 높이와 너비의 비율을 나타낸다.

본 문서에서는 ThreeJS의 기본적인 사항을 다룬다.

최종수정일 : 2023.11.06

02 구성

ThreeJS는 다음과 같은 구성요소들로 이루어진다.

02.01 Renderer

렌더러(renderer)는 씬과 카메라를 조합하여 3D 씬 객체를 화면에 투사시키는 역할을 한다.

02.02 Camera

카메라(Camera)는 공간에서 하나의 시점을 정의한다.

02.03 Scene

씬(Scene) 객체는 하나의 공간을 정의하며, 공간의 원점(origin)을 정의한다.

02.03.01 Geometry

지오메트리(Geometry)는 구, 입방체, 사람, 강아지 등 정점(Vertex)으로 구성된 데이터를 의미한다.

02.03.02 Texture

텍스쳐(Texture)는 (질감을 나타내는)이미지이다.

02.03.03 Material

재질(Material)은 지오메트리로부터 면을 구성할 때 사용되는 특성을 포함하는 객체로, 하나 이상의 텍스쳐와 반사값, 색상 등의 특성을 갖는다.

02.03.04 Mesh

메쉬(Mesh) 객체는 특정한 도형(Geometry)과 특정한 재질(Material)로 이루어진 개체를 의미한다. 재질과 지오메트리는 여러 매쉬 객체에서 사용될 수 있다

02.03.05 Light

광원(Light)은 여러 종류의 빛을 의미한다.

02.03.06 Object3D

-

02.03.07 Group

Velog의 마크다운 문서와 이미지를 손쉽게 로컬 스토리지로 옮길 수 있도록 한 프로젝트가 있다. https://github.com/cjaewon/velog-backup

`
> git clone https://github.com/cjaewon/velog-backup
> cd velog-backup
> npm install

> node app.js --help
Usage: app [options]

Options:
 -V, --version              output the version number
 -u, --username <username>  velog 유저이름
 -d, --delay <ms>           요청 딜레이 시간 (글이 많은 경우 딜레이 시간을 늘려주세요)
 -c, --cert <access_token>  velog 유저 access_token
 -h, --help                 display help for command

> node app.js -u <유저 이름>

📙 백업을 시작합니다 / velog-backup
✅ <유저 이름>님의 모든 글(3 개) 을 가져옴
✅ " 🐦 serverless 로 날아다니기 " 백업 완료
✅ " Github Action으로 매일마다 브리핑 받기! " 백업 완료
✅ " Github 이스터에그 " 백업 완료

`

options username : 필수 옵션으로 백업 할 유저를 선택한다. delay : 백업 요청 딜레이 시간을 넣을 때 사용된다. cert : 비공개 글을 같이 가져오고 싶을 때 가능하다.

백업 위치 백업 된 파일은 backup 폴더 안에 저장되어 있다.

content : 백업 한 글들이 마크다운 확장자로 저장됩니다. images : 글들이 참조하고 있는 이미지들이 다운로드 되어 저장됩니다.

02 Naver Blog 백업 방법

네이버 블로그에서는 글을 PDF로 백업하는 기능을 자체적으로 제공한다.

이제는 다음과 같은 작업이 늘어날 것으로 생각된다.

• 다른 사람의 코드를 구조를 그려가며 읽는 작업
• 기존 코드를 확장하는 작업
• 내 코드를 설명하고 이해시키는 작
• 다양한 디자인 패턴과 아키텍쳐를 적용
• 리팩터링 등

이에 따라 혼자서 한 프로젝트라고 해도 기억하기 어렵거나 구조를 명확하게 그리는 것이 모호한 채로 주먹구구식 개발을 하게될 수 있다.

이에 따라 이 시점부터 단계에 맞게 필요한 개발 문서를 작성해가며 작업하기로 정한다.

최종수정일 : 2023.10.28

많은 패키지들이 자바스크립트로 만들어졌다. 이러한 경우 해당 패키지 내의 변수나 함수들은 타입을 알 수 없어 타입스크립트가 정보를 추론하기 어렵다. 본 문서에서는 이와 같은 기존의 자바스크립트 코드를 타입스크립트에서 이용하기 위하여 필요한 내용을 다룬다.

최종수정일 : 2023.10.25

02 d.ts : declaration file

MyPackage.js

export function init(config) {
   return true;
}

export function exit(code) {
   return code + 1;
}

useMyPackage.ts : Dummy Code

import { init, exit } from "MyPackage"

init({
   url:"true"
})

exit(1)

MyPackage.d.ts : declaration file

interface Config {
   url: string;
}
declare module "MyPackage" {
   function init(config: Config):boolean;
   function exit(code: number): number;
}

Javascript로 작성된 라이브러리를 타입스크립트에서 타입안정성 있게 사용하기 위해서 타입에 대해 서술한 추가적인 파일이다.

03 JSDoc : @ts-check

tsconfig.json

{
   "include": ["src"],
   "compilerOptions": {
       ...
       "allowJS": true
   }
}

myPackage.js

// @ts-check

/**
* Initialize the project
*@param {object} config
*@param {boolean} config.debug
*@param {string} config.url
*@return boolean
*/
export function init(config) {
   return true;
}

/**
* Exit the project
*@param {number} code
*@return number
*/
export function exit(code) {
   return code + 1;
}

위와 같이 작성하면 JSDoc 문법을 통해 자바스크립트 파일의 변형이나 오작동 없이 타입스크립트에서 임포트했을 때 타입을 안내해준다.

타입스크립트 컴파일러는 100개 이상의 다양한 설정을 가지고 있다. 그 외에도 타입스크립트에서 사용할 다양한 옵션이 존재한다. 본 문서에서는 tsconfig.json을 파일을 주로 커맨드라인에서도 사용가능한 타입스크립트의 자주 사용되는 설정에 대해서 다룬다.

최종수정일 : 2023.10.20

02 Compile Options

https://www.typescriptlang.org/tsconfig#strictNullChecks

{
   "compilerOptions": {
//        "strict": true            - automatically set true on following options
//            "strict": true,
//            "strictNullChecks": true,
//            "strictFunctionTypes": true,
//            "strictBindCallApply": true,
//            "strictPropertyInitialization": true,
//            "noImplicitThis": true,
//            "alwaysStrict": true,

       "noImplicitAny": true
       "strictNullChecks": true
       ...
   }
}

02.01 strict

Default : false Released : 2.3 엄격한 타입스크립트 룰을 적용한다.

02.02 noImplicitAny

Default : true if strict; false otherwise. Related : strict

암묵적으로 타입이 지정되지 않은 변수에 any타입을 적용할 것인지를 결정한다.

02.03 strictNullChecks

Default : true if strict; false otherwise. Related : strict Released : 2.0

null과 undefined가 모든 타입에 할당하는 것이 허용되는지 확인한다.

02.04 noEmitOnError

Default : false Released : 1.4

타입 오류가 있을 경우에, 해당 옵션이 false일 경우 컴파일이 가능하다. 해당 옵션을 설정하면 타입 오류가 있을 때 컴파일이 불가능해진다.

본 문서에서는 Visual Studio Code에 대한 환경설정과 사용자 최적화에 관한 내용을 다룬다.

최종수정일 : 2023.10.19

02 초기 설정

02.01 Extension

VScode Pet 설치

02.02 환경설정

터미널 한글 사용

vscode settings > encoding(settings.json에서 직접 수정 가능) 제어판 > 시계 및 국가 > 국가 또는 지역 > 관리자 옵션 > 시스템 로캘 변경 > 세계 언어 지원을 위해 Unicode UTF-8 사용 활성화

자동완성 기능 사용

code > settings > Trigger Suggest

03 단축키

03.01 코드 작성

Ctrl + K C Ctrl + K U : 주석처리 선택한 영역을 주석처리/해제한다.

Ctrk + L : 선택 줄 삭제 선택된 줄을 삭제한다.

Ctrk + D : 다중선택(순차) 선택한 변수와 같은 변수를 하나씩 동시수정 가능하게 추가한다.

Ctrk + Shift + L : 다중선택(순차) 선택한 변수와 같은 변수 전체를 동시수정 가능하게 추가한다.

03.02 추가설정

Ctrl+(number) : 해당 번호 탭으로 이동 Code -> Preferences -> Keyboard Shortcurs -> 우측상단 keybindings.json 아래 내용 추가

[
   {
       "key": "ctrl+0",
       "command": "workbench.action.openLastEditorInGroup"
   },
   {
       "key": "ctrl+1",
       "command": "workbench.action.openEditorAtIndex1"
   },
   {
       "key": "ctrl+2",
       "command": "workbench.action.openEditorAtIndex2"
   },
   {
       "key": "ctrl+3",
       "command": "workbench.action.openEditorAtIndex3"
   },
   {
       "key": "ctrl+4",
       "command": "workbench.action.openEditorAtIndex4"
   },
   {
       "key": "ctrl+5",
       "command": "workbench.action.openEditorAtIndex5"
   }
]

본 문서에서는 GitHub를 관리하는 과정에서 필요한 여러가지 테크닉에 대해 다룬다.

최종수정일 :2023.10.16

02 과거 커밋 이력 공개 없이 공개범위 변경

https://stackoverflow.com/questions/39336842/make-git-repo-public-without-revealing-past-commits

git checkout UserCommitHash

원하는 커밋으로 이동한다.

git reset InitialCommitHash --soft

초기 커밋으로 이동한다.

git commit --amend -m "My new initial commit"

amend 옵션과 함께 커밋한다.

git push your_remote main

퍼블릭 리포지토리에 푸시한다.

클론한 리포지토리를 푸시할 수도 있지만 이렇게 진행할 경우, git reflog 명령어를 통해 조회할 수 있지만 원격 저장소에 푸시되지는 않는다.

또한 첫번째 커밋의 아이디를 얻기 위해서는 아래 글에 나온 명령어를 사용할 수 있다. (https://stackoverflow.com/questions/5188914/how-to-show-the-first-commit-by-git-log/5189296#5189296)

git rev-list --max-parents=0 HEAD

리액트 네이티브의 스타일에 관한 내용 전반을 다룬다.

최종수정일 : 2023.09.22

02 스타일 관리 방법

02.01 inline-style

<Text style={{color:'#000'}}>My Text</Text>

02.02 stylesheet

import { StyleSheet } from 'react-native';
const LotsOfStyles = () => {
 return (
   <View style={styles.container}>
     <Text style={styles.red}>just red</Text>
     <Text style={styles.bigBlue}>just bigBlue</Text>
     <Text style={[styles.bigBlue, styles.red]}>bigBlue, then red</Text>
     <Text style={[styles.red, styles.bigBlue]}>red, then bigBlue</Text>
   </View>
 );
};

const styles = StyleSheet.create({
 container: {
   marginTop: 50,
 },
 bigBlue: {
   color: 'blue',
   fontWeight: 'bold',
   fontSize: 30,
 },
 red: {
   color: 'red',
 },
});

02.03 styled component

import styled from 'styled-components'

const Button = styled.button``

03 세부사항

03.01 Font 설정

참조링크 : https://dev-yakuza.posstree.com/ko/react-native/react-native-custom-font/

03.01.01 Android

android/app/src/main/assets/fonts에 폰트 파일을 추가한다.

03.01.02 iOS

ios/Fonts에 폰트 파일을 추가한다.

xcode > project명 우클릭 > Add Files to "project_name"... > ios/Fonts 선택 > Create folder references를 선택 > Add

왼쪽 상단 프로젝트명을 선택 > TARGETS 프로젝트명을 선택 >상단 메뉴에서 Info 선택 > Info.plist의 내용을 확인 > Info.plist에 Fonts provided by application 추가 > 폰트 파일을 추가

경우에 따라 리액트 네이티브 앱 내부에서 html 문서를 렌더링 해야 할 필요가 있는 경우가 있다. 이러한 경우 사용할 수 있는 라이브러리는 2023년 09월 현재 크게 두가지가 있다.

react-native-render-html react-native-webview

본 문서에서는 위 두 라이브러리를 포함하여 HTML문서를 리액트 네이티브 내부에서 렌더하는 방법에 대해서 다룬다.

최종수정일 : 2023.09.22

02 작동방식

02.01 react-native-render-html

03 기본적인 사용법

03.01 react-native-render-html

import React from 'react';
import { useWindowDimensions } from 'react-native';
import RenderHtml from 'react-native-render-html';

const source = {
 html: `
<p style='text-align:center;'>
 Hello World!
</p>`
};

//` <- Markdown edtorial requirement
export default function App() {
 const { width } = useWindowDimensions();
 return (
   <RenderHtml
     contentWidth={width}
     source={source}
   />
 );
}
//`

03.02 react-native-webview

import React, { Component } from 'react';
import { StyleSheet, Text, View } from 'react-native';
import { WebView } from 'react-native-webview';

// ...
const MyWebComponent = () => {
 return <WebView source={{ uri: 'https://reactnative.dev/' }} style={{ flex: 1 }} />;
}

99 참조링크

99.01 react-native-render-html

https://blog.logrocket.com/how-render-html-react-native/ https://www.npmjs.com/package/react-native-render-html

99.02 react-native-webview

https://github.com/react-native-webview/react-native-webview