ilikezzi

[NestJS] 비동기의 핵심, 이벤트 루프 + libuv 파헤치기 (2편)

대파양파애비 — Mon, 26 May 2025 02:04:21 +0900

예전 포스팅에서 Node.js의 이벤트 루프(event loop)의 개념과 동작 원리에 대해 자세히 알아보았다.

https://ilikezzi.tistory.com/68

[Javascript] 비동기의 핵심, 이벤트 루프(Event loop) 파헤치기

메리 크리스마스 크리스마스인데도 포스팅을 하는 이유는 백엔드파트 리더님과 대화중에 JS 이벤트루프를 설명해보라고 하셨는데 어버버대다가 제대로 설명을 못해서 당황했었다.. 리더님

ilikezzi.tistory.com

이번 포스팅에서는 그 이벤트 루프를 포함하고 있는 Node.js의 핵심 비동기 처리 라이브러리인 libuv를 중심으로,

NestJS를 사용하면서 반드시 이해해야 할 장단점과 부하에 대한 내구성 관리에 대해서 깊이 있게 다뤄보겠다.

많은 개발자들이 Node.js에 대해 "싱글 스레드라서 I/O에는 강하지만 CPU 집약적 작업에는 약하다"라고 알고 있는데,

정확히 왜 그런지, 그리고 그 한계를 어떻게 극복할 수 있을지 하나씩 알아보자.

왜 CPU 집약 작업에 약할까?

먼저 Node.js의 단점부터 살펴보자.

Node.js는 기본적으로 싱글 스레드 + 이벤트 루프 구조로 동작한다.

Java/Spring처럼 멀티 스레드가 아닌 싱글 스레드에서 JavaScript를 실행하기 때문에,

CPU 집약적인 작업이 들어오면 이벤트 루프가 블로킹되어 버린다.

for (let i = 0; i < 1e9; i++) {
  Math.sqrt(i);
}

예를 들어, 이런 코드가 있다면

이 연산은 무조건 메인 스레드에서 실행되고, 이벤트 루프를 막아버린다.

그 결과 API 응답이 지연되고 전체 애플리케이션이 멈춘 것처럼 동작하게 된다.

하지만 이 문제도 해결 방법이 있다.

Node.js에서 이러한 CPU 집약적 작업을 처리할 때는 크게 두 가지 방법으로 해결할 수 있다.

1. Worker Threads 활용

import { Worker } from 'worker_threads';
new Worker('./heavy-task.js'); // 별도의 쓰레드에서 연산

Worker Threads는 각각 독립적인 V8 엔진 인스턴스를 워커마다 띄워서,

순수 CPU 연산(암호화, 영상 처리, 대규모 계산 등)을 진정한 병렬로 수행할 수 있다.

이미지 처리(이미지 리사이징), 복잡한 수식 계산, 텍스트 파싱 등의 작업에 적합하다.

2. 클러스터 모드 (PM2) 활용

pm2 start app.js -i max

클러스터 모드는 멀티코어를 활용하여 CPU 코어 수만큼

Node.js 인스턴스를 띄워 병렬 처리를 가능하게 해준다.

이렇게 하면 멀티코어를 활용해서 부하를 분산시킬 수 있다.

이런 방법들을 통해 NestJS의 싱글 스레드 구조로 인한 블로킹 문제를 상당 부분 해소할 수 있다.

그럼 왜 I/O 작업은 장점일까?

이제 핵심 질문이다.

왜 Node.js는 I/O 작업에 강할까?

단순히 이벤트 루프가 있어서일까?

아니다.

그 비밀은 바로 libuv라는 라이브러리에 숨어 있다.

이벤트 루프는 사실 libuv 안에 포함된 개념이고, libuv가 실제 I/O를 처리하는 핵심 엔진이다.

이게 바로 싱글 스레드이면서도 논블로킹 구조를 가질 수 있는 핵심이다!

libuv란 무엇인가?

libuv는 Node.js의 비동기/논블로킹 처리를 가능하게 해주는 C 기반 라이브러리다. (C++ 아님)

Node.js는 내부적으로 이런 구조로 되어 있다:

이전 Node.js 버전에서는 libeio, libev를 나눠서 사용했는데,

현재 우리가 사용하는 Node.js에서는 통합된 libuv로 변경되었다.

컴포넌트	언어	역할
V8	C++	자바스크립트 실행 엔진
libuv	C	비동기 I/O 처리 (이벤트 루프, Thread Pool 포함)
Node.js 바인딩 코드	C++	JS → C/C++ 연결 코드 (fs, crypto 등)

libuv의 특징에 대해 알아보자.

주요 특징:

- 네트워크 요청, 파일 읽기, 타이머, DNS, 비동기 I/O 전부 libuv가 처리

- OS에 작업을 위임하고 결과를 기다림

- 시스템마다 제공하는 최적화된 API를 활용

libuv가 정말 똑똑한 점은 각 운영체제가 제공하는 최적화된 API를 활용한다는 것이다:

- Windows: IOCP (I/O Completion Ports)

- Linux: epoll

- macOS: kqueue

참고로 Spring의 경우 Linux 환경에서 select를 사용하는데, libuv는 더 효율적인 epoll을 사용한다.

libuv의 내부 동작 원리

Node.js 내부적으로 비동기 작업이 발생하면 다음과 같은 흐름으로 처리된다.

JavaScript 코드 실행: 스택에 코드가 쌓임
libuv 호출: 스택에 쌓인 코드를 실행하면서 libuv를 호출
작업 분류: libuv가 비동기 처리할지, 동기 처리할지 검사
작업 위임: (비동기 작업) 시스템 API를 이용하거나 Thread Pool에게 작업 위임
- 시스템 API: 소켓 네트워크, 파이프, 파일 디스크립터 감시, 타이머 등
- ThreadPool: 파일 시스템 read/write, DNS getaddrinfo, xrypto, zlib 등
콜백 등록: 작업이 완료되면 콜백 함수를 태스크 큐에 전달
이벤트 루프: 콜스택이 비었을 때 태스크 큐의 콜백을 콜스택으로 이동
콜백 실행: 콜스택에서 콜백 함수 실행 후 제거

즉, libuv가 내부적으로 작업을 처리하여 JS 실행 스레드는 블로킹되지 않고 다음 작업을 계속 수행할 수 있다.

실제 Node.js 공식 소스코드를 보면 이런 식으로 되어 있다:

int NodeMainInstance::Run() {
  // ... 초기화 코드 ...
  
  do {
    uv_run(env->event_loop(), UV_RUN_DEFAULT);
    
    per_process::v8_platform.DrainVMTasks(isolate_);
    
    more = uv_loop_alive(env->event_loop());
    if (more && !env->is_stopping()) continue;
    
    // ... 기타 처리 ...
  } while (more == true && !env->is_stopping());
  
  // ... 정리 코드 ...
}

여기서 uv_run()이 이벤트 루프를 실행하는 핵심 함수다.

Node.js 인스턴스가 생성될 때 이 함수가 do-while문으로 계속 호출되면서 이벤트 루프가 동작한다.

중요한 점은 Node.js에서 동작하는 이벤트 루프는 libuv의 구현체라는 것이다.

libuv는 JavaScript 엔진이 아니기 때문에,

파라미터로 넘겨받은 v8::Isolate, v8::Context를 이용해서 JavaScript 로직을 처리한다.

Thread Pool의 이해

Node.js는 싱글 스레드라고 하지만, 이는 JavaScript를 실행하는 스레드가 하나라는 의미다.

실제로는 libuv 내부에 Thread Pool이 존재한다.

기본적으로 4개의 워커 스레드를 사용하며, 이렇게 조절할 수 있다:

process.env.UV_THREADPOOL_SIZE = 10

Thread Pool은 라운드 로빈이 아니라 단순 FIFO 큐 기반으로 실행된다.

예를 들어 10개의 요청이 들어오면:

- 처음 4개는 각 스레드에서 즉시 처리

- 나머지 6개는 대기 큐에서 순서대로 대기

- 스레드가 완료되는 순서대로 대기 중인 작업을 처리

즉, 동시에 기본 4개까지만 처리되고, 나머지는 풀 안에서 FIFO 순서로 대기하는 구조다.

libuv Thread Pool은 일부 CPU 작업도 처리할 수 있다.

처리 가능한 작업:

- crypto.pbkdf2와 같은 내장 비동기 API

- 파일 시스템 I/O(fs), zlib 압축, DNS 조회 등

처리 불가능한 작업:

- (메인 스레드에서 처리됨): 순수 JavaScript로 구현한 반복문이나 수학 연산

- 이미지 처리, 머신러닝과 같은 복잡한 연산

결론적으로 NestJS에서 성능을 최적화하기 위한 전략은 다음과 같이 정리할 수 있다.

- 순수 CPU 연산이 필요한 경우: Worker Threads 또는 PM2 클러스터 모드를 사용

- I/O 기반 작업(fs, crypto 등)인 경우: UV_THREADPOOL_SIZE를 늘려서 효율적으로 처리

이 두 가지 전략을 활용하면 Node.js의 단점인 CPU 집약적 작업에 대한 블로킹 문제를 효과적으로 해결할 수 있다.

아래 링크는 이벤트 루프와 libuv에 대해 더 깊이 이해하는 데 큰 도움을 받았어서 강추한다!

https://medium.com/the-node-js-collection/what-you-should-know-to-really-understand-the-node-js-event-loop-and-its-metrics-c4907b19da4c

What you should know to really understand the Node.js Event Loop

Node.js is an event-based platform. This means that everything that happens in Node is the reaction to an event. A transaction passing…

medium.com

Node.js와 NestJS의 비동기 처리 메커니즘을 이해하는 것은 단순히 이론적 지식이 아니다.

실제 애플리케이션의 성능을 최적화하고, 병목 지점을 파악하며,

적절한 아키텍처를 설계하는 데 필수적인 지식이다.

참고:

https://bravochos.medium.com/the-internals-of-node-js-b57bab6dc90

https://github.com/nodejs/node

https://nodejs.org/ko/docs/guides/event-loop-timers-and-nexttick/

https://blog.naver.com/pjt3591oo/221976414901

https://sjh836.tistory.com/149

[Frontend] React SPA에서 Next.js SSR로 동적 OG 메타태그 적용기

대파양파애비 — Sat, 24 May 2025 04:58:11 +0900

갑자기 프론트엔드 포스팅을 쓰게 되었다..

어느 날 문득 개발로 부수입을 벌어보고 싶다는 생각이 들었다.

마침 주변에 웹·앱에 애드센스를 붙여 매달 용돈을 벌고 있는 개발자가 적지 않게 보이더라.

문제는 프론트엔드 경험이 전무하다는 사실이었다.

하지만 최근 Cursor AI·GPT 같은 ‘바이브 코딩’ 도구들이 꽤 쓸 만해 보여 직접 React로 도전해 보기로 했다.

개인 일정상 오래 매달릴 수 없었기에, 주말 이틀동안 밤새서 ‘자체 1인 해커톤’으로 삼아 기획부터 배포까지 끝내기로 결심했다.

광고 수익을 노리려면 트래픽이 필수이니, 공유 기능이 있는 단순 모바일 웹을 목표로 삼았다.

LuckStargram

그래서 LuckStargram이라는 AI 운세 서비스를 만들기로 했다.

- 이름·생년월일·운세 날짜를 입력하면 GPT AI가 오늘의 운세를 생성한다.

- 결과는 카드형 UI로 표시되며, 메시지와 행동 팁을 함께 제공한다.

또한, 인스타그램이나 카카오톡에 쉽게 공유를 유도하기 위해 '티켓'이라는 게이미피케이션 요소도 넣었다.

- 운세 결과를 공유하면 티켓 1장 추가 획득

- 공유 링크로 들어온 사용자도 1회 티켓을 받을 수 있음

주말 동안 기획 → 개발 → 배포까지 일사천리로 진행했다.

- 백엔드 : NestJS → AWS API Gateway + AWS Lambda

- 프론트엔드 : React → Vercel

하지만 카카오톡으로 공유해 보니 메타태그가 항상 같은 이미지·텍스트로 노출되었다.

그래서 React 공유페이지에서 메타태그를 아래처럼 넣고 공유해봤다.

const dateObj = new Date(json.fortune_date);
const mm  = dateObj.getMonth() + 1;
const dd  = dateObj.getDate();
const nameOnly = json.name.length > 1 ? json.name.slice(1) : json.name;
const title = `${nameOnly}님의 ${mm}월 ${dd}일 운세  `;
const firstSentence = json.message.split('. ')[0] + '.';
const description  = firstSentence;

document.title = title;

const setMeta = (sel: string, attr: string, val: string) => {
  const el = document.querySelector(sel);
  if (el) el.setAttribute(attr, val);
};

setMeta('meta[property="og:title"]',        'content', title);
setMeta('meta[name="twitter:title"]',        'content', title);
setMeta('meta[property="og:description"]',   'content', description);
setMeta('meta[name="description"]',          'content', description);

그러나 결과는 변하지 않았다.

찾아보니 React는 SPA라서 클라이언트 사이드에서 동적으로 메타태그를 변경해도

카카오톡, 페이스북 같은 소셜 크롤러들이 이를 제대로 인식하지 못한다고 하더라.

SPA는 처음에 비어있는 HTML을 받고, JavaScript가 실행되면서 동적으로 내용을 채우는 방식이다.

하지만 소셜 크롤러들은 초기 HTML만 읽고 JavaScript 실행을 기다리지 않기 때문에 빈 메타태그만 보게 된다.

그래서 아무리 JavaScript로 메타태그를 수정해도 소용없는 것이다.

그래서 다른 방법을 찾아보았다.

다이나믹 링크, Prerender.io 시도

이전에 다른 프로젝트에서 공유 기능을 넣을 때 Firebase의 다이나믹 링크를

쉽게 적용했었던 기억이 있어서 바로 적용하려고 홈페이지에 들어가보니

... 그렇다고 한다.

그래서 어쩔 수 없이 다른 대안을 찾아보았다.

프리렌더링 Prerender.io를 알게 되었는데, 이것도 물론 편하고 좋지만

초반 일부만 무료고 유료라길래 다른 방법을 알아보기로 했다.

https://www.linode.com/ko/blog/devops/improve-seo-with-prerender-io/

Prerender.io로 SEO 개선

이 글에서는 Prerender.io의 프리렌더링 서비스가 SEO 장애물을 극복하는 데 어떻게 도움이 되는지 살펴보겠습니다.

www.linode.com

React-Helmet-Async + Puppeteer 시도

- react-helmet-async : 렌더 시점에 <head>를 동적으로 조작해 주는 라이브러리

- Puppeteer : Headless Chrome을 제어해 실제 브라우저에서 페이지를 렌더링, 정적 HTML을 생성할 수 있음

두 라이브러리 조합이 내 상황에 적절해 보였기에 바로 도입했다.

1. <Helmet>으로 SPA 내부에서 동적 OG 메타태그를 설정했다.

2. Puppeteer로 크롤러 User-Agent일 때만 HTML 스냅샷을 생성하도록 프리렌더링 플로우를 만들었다.

하지만…

// vite.config.ts
function generatePerformanceRoutes() {
  const staticRoutes  = ['/', '/main']; // 정적 경로
  const dynamicRoutes = [];             // 동적 경로 저장 배열
  dynamicRoutes.push('/share/123');
  return staticRoutes.concat(dynamicRoutes);
}

dynamicRoutes에 직접 경로를 써야만 HTML이 생성됐다.

운세 페이지는 /share/:uuid 형태로 동적 생성되는데, SSG 시점에는 UUID를 알 수 없다.

빌드 후에 메시지 큐로 vite 설정을 다시 만지려 하니, 구조가 지나치게 복잡해져 다른 방법을 모색했다.

Next.js SSR 도입

결국 하이브리드 구조로 결정했다:

메인 앱: React SPA로 유지 (빠른 사용자 경험)
공유 페이지: Next.js SSR로 분리 (완벽한 OG 메타태그)
share. 서브도메인을 만들어 도메인 레벨로 기능을 구분

여기에 Short Link까지 도입해서 share/luckstargram.com/abc123 같은 깔끔한 공유 주소를 만들기로 했다.

// pages/share/[uuid].tsx

// pages/share/[uuid].tsx
import { GetStaticProps } from 'next';
import Head from 'next/head';

export const getStaticProps: GetStaticProps = async ({ params }) => {
  const uuid = params?.uuid as string;
  
  // 백엔드에서 운세 데이터 가져오기
  const res = await fetch(`${process.env.API_BASE_URL}/share/${uuid}`);
  const data = await res.json();
  
  // 동적 OG 메타 생성
  const nameOnly = data.name.length > 1 ? data.name.slice(1) : data.name;
  const title = `${nameOnly}님의 ${mm}월 ${dd}일 운세  `;
  const description = data.message.split('. ')[0] + '.';
  
  return {
    props: { meta: { title, description, image: '/logo.webp' } },
    revalidate: 60, // ISR로 60초마다 캐시 갱신
  };
};

export default function SharePage({ meta }) {
  return (
    <>
      <Head>
        <title>{meta.title}</title>
        <meta property="og:title" content={meta.title} />
        <meta property="og:description" content={meta.description} />
        <meta property="og:image" content={meta.image} />
        {/* 일반 사용자는 메인 앱으로 리다이렉트 */}
        <meta httpEquiv="refresh" content="0; URL=https://luckstargram.com" />
      </Head>
      <div />
    </>
  );
}

// middleware.ts

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

const SOCIAL_BOTS = ['facebookexternalhit', 'twitterbot', 'kakaotalk'];

export async function middleware(req: NextRequest) {
  const userAgent = req.headers.get('user-agent')?.toLowerCase() || '';
  const isSocialBot = SOCIAL_BOTS.some(bot => userAgent.includes(bot));
  
  if (isSocialBot) {
    // 소셜 크롤러 → SSR 페이지로 내부 라우팅
    return NextResponse.rewrite(new URL(`/share/${uuid}`, req.url));
  } else {
    // 일반 사용자 → 메인 앱으로 리다이렉트  
    return NextResponse.redirect('https://luckstargram.com/share/...', 302);
  }
}

/share/[uuid] 페이지에서 ISR + Edge Runtime으로 OG 메타를 동적으로 공급하도록 구성했다.

여기서 ISR(Incremental Static Regeneration)이란?

Next.js의 하이브리드 렌더링 방식으로, 빌드 시에는 정적 페이지를 만들고,

런타임에는 필요에 따라 페이지를 재생성한다.

revalidate: 60로 설정하면 60초마다 백그라운드에서 페이지를 새로 만들어서 최신 데이터를 유지할 수 있다.

이렇게 SPA의 빠른 로딩 성능을 유지하면서도,

공유 페이지는 SSR로 완벽히 OG 메타를 제공하는 하이브리드 구조를 완성했다.

최종적으로 아키텍쳐는 아래처럼 간단하게 구성을 하였다.

설명이 길었다.

결국 서비스가 제대로 작동하는지 궁금하다면, 직접 한 번 체험해 보는 편이 가장 빠르다.

https://share.luckstargram.com/mCrr1R

승모님의 5월 25일 운세

오늘은 명확함이 길을 열어요.

share.luckstargram.com

이름이랑 생년월일 입력해 AI가 오늘의 운세를 만들어준 결과를

카카오톡에 공유해보면 이 글에서 설명한 동적 OG 메타태그가 어떻게 작동하는지 직접 확인할 수 있을 것이다!

참조 :

https://techblog.woowahan.com/15469/

https://team-beat.tistory.com/32

https://firebase.google.com/support/dynamic-links-faq?hl=ko

https://www.npmjs.com/package/react-helmet-async

https://developer.chrome.com/docs/puppeteer?hl=ko

https://nextjs.org/docs/app/getting-started/metadata-and-og-images

++ 해당 포스팅은 vibeaz에도 함께 게재되었습니다.

https://www.vibeaz.co.kr/share/RTEq

[NestJS] Winston 기반 로깅 라이브러리 'blanc-logger' npm 배포하기

대파양파애비 — Wed, 5 Mar 2025 03:08:35 +0900

NestJS 기반 프로젝트를 개발 중에 곧 배포를 앞두고 있어서 로깅 시스템이 필요했다.

처음에는 Winston을 그대로 사용하려 했지만, 생각보다 부족한 기능이 많았다.

1. Winston 기본 설정이 부족 → NestJS와 TypeORM에서 바로 사용하기 어려움

2. SQL 쿼리 로깅이 비효율적 → 중요한 정보를 가독성 좋게 보기 어려움

3. 모듈 기반 로깅 미지원 → 특정 모듈에서 발생한 로그를 명확하게 구분하기 어려움

4. 파일 로그 관리 부족 → 로그 파일이 커지면 관리가 어려워지고, 파일 회전 기능이 필요함

이러한 문제를 해결하기 위해 일일히 Winston을 커스텀하기 시작했다.

특히 NestJS 및 TypeORM 환경에 최적화하여 HTTP 요청 로깅, SQL 쿼리 하이라이팅, 에러 스택 추적 등

다양한 기능을 사용할 수 있도록 개발하였다.

만들다 보니 생각보다 NestJS와 TypeORM에 최적화된 기능을 추가하게 된 것 같아서

처음으로 npm에 배포를 해보기로 했다 !

Blanc-Logger

그래서 Winston 기반 로깅 라이브러리 "Blanc-Logger" 를 만들게 되었다.

먼저 전반적인 파일 구성에 대해 살펴보자.

├─ src
│  ├─ helper
│  │  ├─ sql-formatter.ts           // SQL 구문 하이라이팅, 포맷팅, 및 쿼리 분석 기능을 제공
│  │  └─ uuid.ts                    // UUIDv5를 사용하여 고유한 로그 식별자를 생성하는 기능을 제공
│  ├─ index.ts                      // 라이브러리의 주요 모듈들을 한 곳에서 통합하여 내보내는 엔트리 포인트 역할
│  ├─ logger                         
│  │  ├─ blanc-logger.ts            // Winston 기반 로거의 메인 설정 및 콘솔/파일 로그 전송을 구성
│  │  ├─ custom-blanc.logger.ts     // NestJS의 LoggerService를 구현해서 기본 로거 대체 제공
│  │  ├─ logger.config.ts           // 사용자 커스터마이징 로깅 설정을 로드하고 관리하는 구성 파일
│  │  └─ typeorm-blanc-logger.ts    // TypeORM 전용 로거로, SQL 쿼리와 데이터베이스 관련 로그를 상세하게 기록
│  └─ middleware
│     └─ blanc-logger.middleware.ts // HTTP 요청에서 모듈명을 추출하여 로그 컨텍스트에 추가하는 미들웨어를 제공

상세 코드는 포스팅 하단의 GitHub 링크에서 확인할 수 있다.

우선 로그 출력 콘솔부터 살펴보자.

디버깅할 때 추적이 편해지게, 각 로그에 UUIDv5로 생성된 고유 LogID를 부여하고,

{timestamp, level, message} 구조의 JSON 포맷으로 출력되어 외부 로그 분석 도구와 연동하기 용이하도록 하였다.

커스텀 콘솔 포맷에서는 로그 레벨에 따라 이모지와 색상을 적용하여 가독성을 높였다.

이어서 SQL 쿼리 내의 주요 키워드를 식별하고, 해당 토큰에 서식을 적용하여 쿼리의 가독성을 높였다.

쿼리 하이라이팅은 키워드, 값, 테이블명을 색상 강조 및 들여 쓰기로 구분하며, 파라미터 값도 별도로 강조했다.

이렇게 콘솔에 출력되는 로그와 SQL 쿼리의 하이라이팅을 통해 사용성과 가독성을 개선했다.

다음으로 에러 발생 시 다중 스택 레이어와 추가 메타데이터를 포함하여 상세한 에러 로그를 기록했다.

그리고 BlancLoggerMiddleware를 활용하여 HTTP 요청의 URL에서 모듈명을 자동 추출해서 메시지에 활용했다.

미들웨어 적용으로 모듈별 컨텍스트 추적이 가능해져,

[UserService → AuthModule → Subsystem] 과 같이 계층 구조로 로깅할 수 있게 되어,

각 로그 메시지의 출처를 명확하게 파악할 수 있었다.

╔═ SQL Query ═════════════════════════════════
    SELECT
        "user"."id" AS "userId",
        "user"."email" AS "userEmail"
    FROM "user" "user"
    WHERE "user"."age" > $1
╠═ Parameters ═══════════════════════════════
    [18]
╠═ Analysis ═════════════════════════════════
    ⚠️ Avoid SELECT * - specify columns explicitly
╚═════════════════════════════════════════════

다음과 같이 SQL 쿼리 출력 시 간단한 성능 모니터링과 실행 계획(Explain Plan) 리포트를 구축했다.

또한, SELECT * 및 JOIN 조건 누락과 같은 SQL 성능 저하 패턴을 자동 감지하고,

Slow Query (예: 100ms 이상)를 자동 감지를 해 경고 로그로 기록하도록 구성했다.

이렇게 쿼리 최적화가 필요한 부분을 사전에 식별 가능하게 되었다.

combined-YYYY-MM-DD.log    // 모든 레벨의 로그 메시지가 기록되는 파일
error-YYYY-MM-DD.log       // 에러 레벨의 로그 메시지만 기록되는 파일
exceptions-YYYY-MM-DD.log  // 처리되지 않은 예외(Unhandled Exception) 로그가 기록되는 파일
rejections-YYYY-MM-DD.log  // 미처리된 Promise 거부(Unhandled Rejection) 로그가 기록되는 파일

// error-2025-03-05.log 
{"level":"error","message":"HTTP Exception: DUPLICATION","stack":[{"moduleName":"user","path":"/api/user/profile","stack":"ConflictException: DUPLICATION\n    at UserService.getProfile (/path/to/src/user/user.service.ts:60:13)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)"}],"timestamp":"2025-03-05 02:29:51"}

이제 중요한 로그 파일에 대해 알아보자.

아까 살펴본 콘솔 출력과 파일 저장을 동시에 지원하게끔 했다.

그리고 로그 파일이 무작정 쌓이지 않도록 일정 크기(예: 20MB) 또는 일정 주기(예: 15일)에 따라

자동으로 파일 회전(Rotation) 되고 날짜별로 파일이 분리되어 생성되도록 구현했다.

또한 필요한 정보만 선별 기록하여 로그의 가독성과 관리 효율성을 증가시키기 위해

개발 및 운영 환경에 따라 [debug, verbose, info, warn, error] 로그 레벨을 실시간으로 조절할 수 있도록 했다.

예를 들어 FILE_LOG_LEVEL 변수를 info로 세팅 시 해당 값보다 높은 로그 레벨인,

[info, warn, error] 세 가지의 로그 레벨이 로그 파일에 적재되고,

FILE_LOG_LEVEL 변수를 error로 세팅 시 가장 높은 레벨이므로 error 로그만 파일에 적재된다.

이렇게 실시간으로 레벨을 조절하여 필요한 정보만 효과적으로 기록 가능하게 했다.

LOG_DIR: logs            # 로그 파일 저장 경로 (기본: 프로젝트 루트/logs)
CONSOLE_LOG_LEVEL: info  # 콘솔 출력 로그 레벨 (debug, verbose, info, warn, error)
FILE_LOG_LEVEL: error    # 파일 출력 로그 레벨 (debug, verbose, info, warn, error)
ROTATION_DAYS: 30d       # 로그 파일 보관 기간 (예: 30일)
MAX_FILE_SIZE: 20m       # 단일 파일 최대 크기 (예: 20MB)

방금 얘기한 변숫값들을 기본 설정을 제공하지만, 필요에 따라 사용자 환경에 맞게 커스터마이징 할 수 있게 했다.

설정을 변경하려면 프로젝트 루트에 logger-config.yaml 파일을 생성하고 원하는 값을 세팅하고,

실행 시 자동으로 Override 되어서 사용자가 원하는 환경설정을 할 수 있게끔 구성했다.

설정 방법

blanc-logger는 NestJS 프로젝트에 아주 간단하게 통합할 수 있도록 설계되었다.

npm install blanc-logger

우선 install을 하자.

1. NestJS 전역 Logger 적용 (main.ts)

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { blancLogger, BlancLoggerMiddleware } from 'blanc-logger';

async function bootstrap() {
  const app = await NestFactory.create(AppModule, {
    logger: blancLogger, // 전역 Logger 적용
  });

  // 미들웨어를 적용하여 요청 시 모듈명 등 컨텍스트 정보를 추가
  app.use(new BlancLoggerMiddleware().use); 

  await app.listen(3000);
}
bootstrap();

Blanc Logger를 전역 로거로 적용하면, 애플리케이션 전체에서 동일한 로깅 설정을 사용할 수 있다.

이 미들웨어는 AppModule에서 DI(Dependency Injection) 방식으로 등록해도 무방하다.

2. TypeORM Logger 적용 (AppModule)

import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';
import { TypeOrmBlancLogger } from 'blanc-logger';

@Module({
  imports: [
    TypeOrmModule.forRoot({
      // ... DB 설정
      logging: true,
      logger: new TypeOrmBlancLogger(), // TypeORM용 로거 사용
    }),
    // 다른 모듈들...
  ],
})
export class AppModule {}

TypeORM 설정에서 Blanc Logger의 전용 로거를 사용하여,

SQL 쿼리 및 데이터베이스 관련 로그를 효과적으로 기록할 수 있다.

이러면 사용을 위한 설정은 모두 끝났다 !

기존 Logger 대체 방법

이제 사용법을 살펴보자.

사용법도 정말 간단하다.

Blanc Logger를 사용하여 기존의 NestJS 내장 로거를 대체할 수 있다.

1. 기존 코드

// 기존 NestJS 내장 로거 사용:
this.logger.error('Error message', error.stack);
this.logger.log('Log message');

2. Blanc Logger 사용

// 에러 발생 시, 스택 정보와 함께 기록
blancLogger.error('Error message', { moduleName: 'ModuleName', stack: error.stack });
blancLogger.log('Log message', { moduleName: 'ModuleName' });
blancLogger.warn('Warn message', { moduleName: 'ModuleName' });
blancLogger.verbose('Verbose message', { moduleName: 'ModuleName' });
blancLogger.debug('Debug message', { moduleName: 'ModuleName' });

이제 기존 Logger를 대체하여 사용할 수 있다.

사용 예시

이렇게 적용한 Logger에 적용 예시를 살펴보자.

1. Logging Interceptor 구현

import { CallHandler, ExecutionContext, Injectable, NestInterceptor } from '@nestjs/common';
import { blancLogger } from 'blanc-logger';
import * as chalk from 'chalk';
import { Observable } from 'rxjs';
import { tap } from 'rxjs/operators';

@Injectable()
export class LoggingInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const startTime = Date.now();
    const req = context.switchToHttp().getRequest();
    const decodedUrl = decodeURIComponent(req.url);
    const moduleName = (req as any).moduleName || 'UnknownModule';

    return next.handle().pipe(
      tap(() => {
        const delay = Date.now() - startTime;
        const delayStr =
          delay > 100 ? chalk.bold.red(`${delay}ms  `) : chalk.magenta(`${delay}ms`);
        const message = `Request processed: ${chalk.yellow(req.method)} ${chalk.green(
          decodedUrl,
        )} ${delayStr}`;
        blancLogger.log(message, moduleName);
      }),
    );
  }
}

전역 인터셉터로 적용하려면 AppModule에 아래와 같이 등록하면 된다.

import { Module } from '@nestjs/common';
import { APP_INTERCEPTOR } from '@nestjs/core';
import { LoggingInterceptor } from './commons/interceptors/logging.interceptor';

@Module({
  providers: [
    {
      provide: APP_INTERCEPTOR,
      useClass: LoggingInterceptor, // 전역 인터셉터로 등록
    },
  ],
})
export class AppModule {}

HTTP 요청 처리 시간을 측정하여 로그로 기록하는 인터셉터 예시다.

아까 적용한 BlancLoggerMiddleware를 통해 설정된 모듈명 정보가 자동으로 포함된다.

이런 식으로 로그가 출력된다.

(응답 시간 초과 시 (예: 100ms)강조)

2. Global Exception Filter 구현

import {
  ArgumentsHost,
  Catch,
  ExceptionFilter,
  HttpException,
  InternalServerErrorException,
} from '@nestjs/common';
import { blancLogger } from 'blanc-logger';
import { Request, Response } from 'express';

interface ExceptionResponse {
  status: number;
  message: string;
  stack?: string;
}

/** 예외 객체를 처리하여 상태, 메시지, 스택을 반환하는 함수 */
const handleException = (exception: unknown, _request: Request): ExceptionResponse => {
  if (exception instanceof HttpException) {
    const status = exception.getStatus();
    const res = exception.getResponse();
    const message =
      typeof res === 'object' && res !== null
        ? (res as any).message ?? exception.message
        : exception.message;
    return {
      status,
      message: `HTTP Exception: ${message}`,
      stack: exception instanceof Error ? exception.stack : '',
    };
  }
  if (exception instanceof Error) {
    const status = new InternalServerErrorException().getStatus();
    return {
      status,
      message: `Unhandled exception: ${exception.message}`,
      stack: exception.stack,
    };
  }
  return { status: 500, message: 'Unknown error' };
};

@Catch()
export class GlobalExceptionFilter implements ExceptionFilter {
  catch(exception: unknown, host: ArgumentsHost): void {
    const ctx = host.switchToHttp();
    const response = ctx.getResponse<Response>();
    const request = ctx.getRequest<Request>();

    const moduleName = (request as any)?.moduleName ?? 'Global';
    const { status, message, stack } = handleException(exception, request);

    blancLogger.error(message, {
      moduleName,
      path: request.url,
      stack,
    });

    response.status(status).json({
      statusCode: status,
      status: message,
      timestamp: new Date().toISOString(),
      path: request.url,
    });
  }
}

전역 필터로 적용하려면 AppModule에 아래와 같이 등록하면 된다.

import { Module } from '@nestjs/common';
import { APP_FILTER } from '@nestjs/core';
import { GlobalExceptionFilter } from './commons/filters/global-exception.filter';

@Module({
  providers: [
    {
      provide: APP_FILTER,
      useClass: GlobalExceptionFilter, // 전역 필터로 등록
    },
  ],
})
export class AppModule {}

이렇게 다 적용을 했으면 예외를 던져보자.

throw new ConflictException('DUPLICATION');

// error-2025-03-05.log 
{"level":"error","message":"HTTP Exception: DUPLICATION","stack":[{"moduleName":"user","path":"/api/user/profile","stack":"ConflictException: DUPLICATION\n    at UserService.getProfile (/path/to/src/user/user.service.ts:60:13)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)"}],"timestamp":"2025-03-05 02:29:51"}

이런 식으로 에러 로그 출력과 함께 로그 파일에 정상적으로 저장된다.

npm 배포

처음엔 npm배포 후 GitHub 패키지까지 둘 다 배포를 하였으나

이후 package.json 파일에 아래 설정을 적용하여 동시에 배포하려 하였다.

"publishConfig": {
  "registry": "https://npm.pkg.github.com/"
}

이를 적용하였을 때, 두 레지스트리 간의 설정 충돌과 배포 관련 이슈가 발생하였으며,

동시에 관리하는 것이 비효율적인 것으로 확인되었다.

GitHub 패키지는 주로 프라이빗 패키지 관리 용도로 활용하고

CI/CD 환경에서 npm 패키지가 더 쉽게 배포 및 설치 가능하다.

따라서 최종적으로 불필요한 복잡성을 줄이기 위해 npm 배포에 집중하기로 결정하였다.

이를 위해 package.json에 다음과 같은 설정이 필요하였다.

1. 빌드 결과물만 포함하도록 하였다.

"files": ["dist"]

2. ES 모듈, CommonJS, 타입스크립트 타입 파일을 각각 지원하도록 구성하였다.

"exports": { 
    "import": "./dist/index.js", 
    "require": "./dist/index.cjs", 
    "types": "./dist/index.d.ts" 
}

3. 검색 최적화를 위한 키워드 추가

  "keywords": [
    "winston",
    "nestjs",
    "logger",
    "typeorm",
  ],

그리고 tsconfig.json 파일을 통해 엄격한 컴파일 환경 (예: CommonJS 모듈, ES6 타겟, 데코레이터 지원 등)을 설정하였다.

npm에 배포된 blanc-logger는 아래 링크에서 확인할 수 있다.

NestJS를 사용하시는 분들이라면 한번 사용해 보시길 !

https://www.npmjs.com/package/blanc-logger

blanc-logger

Advanced Winston logger for NestJS & TypeORM with structured logging (npm package).. Latest version: 1.0.9, last published: a day ago. Start using blanc-logger in your project by running `npm i blanc-logger`. There are no other projects in the npm registry

www.npmjs.com

https://github.com/yooseungmo/blanc-logger

GitHub - yooseungmo/blanc-logger: Advanced Winston logger for NestJS & TypeORM with structured logging (npm package).

Advanced Winston logger for NestJS & TypeORM with structured logging (npm package). - yooseungmo/blanc-logger

github.com

[NestJS] @automock/jest로 번거로운 Unit Test Mocking 자동화하기

대파양파애비 — Sun, 2 Feb 2025 08:44:16 +0900

Jest

NestJS에서 유닛 테스트를 작성할 때, 많은 의존성을 모킹(Mock)해야 하는 상황이 자주 발생한다.

Repository, Service, ConfigService, Cache 등 다양한 Provider를 직접 등록하고

jest.fn()을 이용해 일일이 모킹하면 코드가 복잡해지고 관리가 어려워진다.

이 문제를 해결하기 위해 AutoMock을 활용할 수 있다.

이번 포스팅에서는 @automock/jest를 사용해 번거로운 Provider 등록 과정을 자동화하고,

NestJS의 DI 흐름을 그대로 모사하여 테스트하는 방법을 살펴보자.

기존의 Mocking 방식과 문제점

NestJS에서 유닛 테스트를 작성할 때, 종속된 서비스나 레포지토리를

직접 `jest.fn()`을 사용하여 일일이 Mocking해야 했다.

이를 위해 `@nestjs/testing`의 `Test.createTestingModule`을 사용하여

`providers` 배열에 `useValue` 또는 `useFactory`를 통해 Mock 객체를 수동으로 주입해야 했다.

일일이 주입해야 하므로, Provider가 많을수록 복잡해지는 문제가 있었다.

const mockUserRepository = {
  findOne: jest.fn(),
};

const mockConfigService = {
  get: jest.fn(),
};

const mockJwtService = {
  signAsync: jest.fn(),
  verifyAsync: jest.fn(),
};

const mockUserService = {
  create: jest.fn(),
};

const mockCacheManager = {
  set: jest.fn(),
};

describe('AuthService', () => {
  let authService: AuthService;
  let userRepository: Repository<User>;
  let configService: ConfigService;
  let jwtService: JwtService;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      providers: [
        AuthService,
        {
          provide: getRepositoryToken(User),
          useValue: mockUserRepository,
        },
        {
          provide: ConfigService,
          useValue: mockConfigService,
        },
        {
          provide: JwtService,
          useValue: mockJwtService,
        },
        // ...
      ],
    }).compile();

    authService = module.get<AuthService>(AuthService);
    userRepository = module.get<Repository<User>>(getRepositoryToken(User));
    configService = module.get<ConfigService>(ConfigService);
    jwtService = module.get<JwtService>(JwtService);
  });

  // ... 테스트 코드 ...
});

기존 방식의 단점

• providers: [...] 배열에 Mock 객체를 매번 수동으로 등록해야 한다.

• 의존하는 객체가 많아질수록 테스트 코드가 복잡해진다.

• Mock 객체를 직접 관리해야 해서 유지보수에 부담이 크다.

• 새로운 Provider가 추가될 때마다 일일이 변경해야 하는 번거롭다.

이러한 문제를 해결하기 위해 @automock/jest를 적용하면 된다.

AutoMock(@automock/jest) 적용

@automock/jest는 이러한 번거로운 과정을 자동화해주는 라이브러리다.

NestJS에서 필요한 Provider를 알아서 찾아 Mock 버전으로 주입해주므로,

기존 대비 훨씬 코드가 간결해진다.

패키지 설치

npm i -D @automock/jest @automock/adapters.nestjs

@automock/jest 적용 방식

import { TestBed } from '@automock/jest';

describe('MovieService', () => {
  let movieService: MovieService;
  let movieRepository: jest.Mocked<Repository<Movie>>;

  beforeEach(async () => {
    // TestBed.create(MovieService) 호출 시, 의존성이 자동으로 Mock 처리된다.
    const { unit, unitRef } = TestBed.create(MovieService).compile();
     
    /**
     * unit: 실제 테스트 대상인 MovieService의 인스턴스 (Mock 아님)
     * unitRef: Nest DI 컨테이너처럼 작동하는 레퍼런스 (Mock을 get(token)으로 조회)
     */
    movieService = unit;
    movieRepository = unitRef.get(getRepositoryToken(Movie) as string);
  });

  // ... 테스트 코드 ...
});

- 기존 방식: beforeEach에서 Mock 객체를 만들고, providers에 수동 등록

- AutoMock 방식: TestBed.create(MyService).compile()만 하면, NestJS에서 주입받는 의존성을 자동으로 Mock 처리

동작 원리를 살펴보자.

1. TestBed.create(MyService).compile()를 호출하면,

MyService가 의존하는 모든 Provider를 NestJS 컨테이너처럼 자동 스캔하여 Mock 버전을 생성한다.

2. unit은 실제 서비스의 인스턴스(테스트 대상)이고,

unitRef는 Nest 컨테이너처럼 get(token)을 통해 Mock 객체를 반환한다.

3. 리포지토리나 ConfigService 같은 객체는 jest.Mocked<Type> 형태로 제공되어,

mockResolvedValue(), mockImplementation() 등의 Jest 함수를 바로 사용할 수 있어 편리하다.

항목	기존 방식	@automock/jest 적용 후
의존성 주입	providers: [...]에 직접 Mock 객체 등록	TestBed.create() 호출만으로 자동 처리
의존성 접근	module.get(토큰)	unitRef.get(토큰)
유지보수	의존성이 많아질수록 복잡해짐	간결하고 확장 가능
Mock 생성	jest.fn()을 이용해 직접 생성	자동 생성된 Mock 사용

적용 후 장점을 살펴보면

- 코드 간소화: 테스트를 위한 모킹 로직이 줄어듦으로써, 테스트 파일이 한결 가독성 있어진다.

- NestJS 친화적인 DI: NestJS의 Provider/DI 매커니즘을 그대로 사용하므로, 실제 애플리케이션 구조와 유사한 테스트가 가능하다.

- 유지보수성 향상: Provider가 늘어나도 자동으로 Mock가 생성되므로, 설정해야 하는 부분이 최소화된다.

- 커버리지 상승: 모킹 작업 부담이 줄어드니, 로직 테스트에 집중할 수 있어 자연스럽게 커버리지를 높일 수 있다.

Automock 적용 후 간결해진 코드 예시

import { TestBed } from '@automock/jest';

describe('MovieService', () => {
  let movieService: MovieService;
  let movieRepository: jest.Mocked<Repository<Movie>>;
  let directorRepository: jest.Mocked<Repository<Director>>;
  let genreRepository: jest.Mocked<Repository<Genre>>;
  let userRepository: jest.Mocked<Repository<User>>;
  let dataSource: jest.Mocked<DataSource>;
  let commonService: jest.Mocked<CommonService>;
  let cacheManager: jest.Mocked<Cache>;

  beforeEach(async () => { 
    // 오토목 TestBed 사용
    const { unit, unitRef } = TestBed.create(MovieService).compile();

    movieService = unit;
    movieRepository = unitRef.get(getRepositoryToken(Movie) as string);
    directorRepository = unitRef.get(getRepositoryToken(Director) as string);
    genreRepository = unitRef.get(getRepositoryToken(Genre) as string);
    userRepository = unitRef.get(getRepositoryToken(User) as string);
    dataSource = unitRef.get(DataSource);
    commonService = unitRef.get(CommonService);
    cacheManager = unitRef.get(CACHE_MANAGER);
  });

  // ... 테스트 코드 ...
});

providers: [...] 배열에 useValue로 Mock 객체를 일일이 등록하거나,

jest.fn()을 통해 중복 설정하지 않아도 되므로 테스트 코드가 상당히 간결해진다.

JEST 커버리지 100% + E2E 테스트

@automock/jest를 적용하여 기존보다 훨씬 빠르고 쉽게 테스트를 작성할 수 있었고,

최종적으로 Jest 커버리지 100%를 달성하였으며,

유닛(Unit), 통합(Integration), E2E(End-to-End) 테스트까지 완료했다.

AutoMock을 활용하면 NestJS 테스트에서 필요한 의존성을 자동으로 Mocking하여,

테스트 코드의 복잡도를 줄이고 유지보수성을 극대화할 수 있다.

복잡한 의존성으로 인해 테스트 작성을 미뤘다면,

AutoMock을 도입하여 안정적이고 효율적인 테스트 환경을 구축해보길 바란다.

Happy Testing !!!

참조 :

https://docs.nestjs.com/fundamentals/testing

https://docs.nestjs.com/recipes/suites#suites-formerly-automock

https://jestjs.io/docs/es6-class-mocks#automatic-mock

https://dev.to/omermorad/unit-test-like-a-pro-automock-my-open-source-answer-to-mocking-frustration-31p4

[Postman] 환경변수와 Script를 활용한 랜덤 데이터 생성부터 관계형 데이터 Seeding까지

대파양파애비 — Tue, 21 Jan 2025 06:15:01 +0900

개발을 하다 페이지네이션 관련 테스트를 진행해야 하는 상황이 생겼다.

관계형 데이터를 하나하나 매핑해서 적재하는 작업이 번거로워,

보다 간편한 방법을 찾던 중 이 방식을 활용해봤는데, 매우 유용해서 포스팅하게 되었다.

이번 포스팅에서는 Postman 환경변수와 Script를 활용해 랜덤 데이터부터 관계형 데이터(FK)까지 한 번에 생성해보고,

이후에 Collection Runner로 대량 데이터를 만들어 보는 과정을 정리해보려 한다.

특히 TypeORM 관계 설정(@ManyToOne, @ManyToMany 등)을 해둔 DB에 손쉽게 데이터를 넣을 수 있는 방법이라,

대규모 테스트에도 편리하게 활용할 수 있다.

일일히 넣기 귀찮은 Token 자동화부터, 랜덤한 데이터 생성, Runner로 대규모 데이터 만들기 까지

지금부터 하나씩 알아보자.

환경변수(Environments) 설정

Postman에서 새 Environment를 하나 생성하자.

환경변수를 사용해 API URL이나 동적인 데이터를 간단히 관리할 수 있다.

이제 다음과 같이 host를 추가해주자.

host: ex) http://localhost:3000

이렇게 만들어두면, API 호출 시 {{host}}가 자동으로 http://localhost:3000으로 대체된다.

- Path 사용법:
{{host}}/movie

이제 이 Environment에 다양한 변수들을 추가시킬 것이다.

로그인 및 Token 자동화

예시로 POST {{host}}/auth/login을 호출했다고 가정했다.

이 API가 accessToken, refreshToken을 JSON으로 리턴한다고 할 때,

Script에서 아래처럼 코드를 작성해봤다.

좌측에 Pre-request랑 Post-reponse가 있는데,

해당 작업은 return값을 활용해야 하므로 Post-reponse 를 선택하고 스크립트를 작성하자.

pm.test("Status code is 201", function (){
    pm.response.to.have.status(201)

    const body = pm.response.json()

    pm.environment.set("accessToken", body.accessToken);
    pm.environment.set("refreshToken", body.refreshToken);
})

이 코드는 로그인 성공 시 응답으로 받은 accessToken과 refreshToken을 Postman 환경변수에 저장한다.

실행시키고 Environment에 가보면 Token이 정상적으로 추가되었을것이다.

이제 Environment에 있는 Token을 사용해서 Authorization 재사용 설정을 해보자.

1. 다른 API에서 Authorization 타입을 Inherit auth from parent로 설정한다.

2. 프로젝트 상단의 폴더에서 Authorization 타입을 Bearer Token으로 변경한 뒤,

Token 값에 {{accessToken}}을 입력한다.

이후 한 번만 로그인하면, 모든 요청에서 환경변수에 저장된 토큰 값을 사용하여 편리하게 인증할 수 있다.

이제 귀찮게 매번 헤더에 토큰을 추가해서 디버깅하지 않아도 된다!

랜덤 데이터 생성

Postman에서는 일부 빌트인 랜덤 변수를 제공한다. 예를 들어,

{
  "name": "{{$randomFullName}}"
}

이렇게 작성하면, Body 데이터 생성할 때마다 새로운 이름으로 데이터를 생성할 수 있었다.

이 외에도 {{$randomCountry}}, {{$randomLoremSentence}},

{{$randomNoun}}, {{$randomAdjective}} 등 다양한 랜덤 변수가 있으니 참고하면 편리하다.

관계형 데이터 Seeding 설정

여기서는 TypeORM 예시를 들어서, Director와 Movie, 그리고 Genre 간의 관계를 다뤄봤다.

// Movie Entity
@ManyToMany(() => Genre, (genre) => genre.movies)
@JoinTable()
genres: Genre[];

@ManyToOne(() => Director, (director) => director.id, {
  cascade: true,
  nullable: false,
})
director: Director;

영화(Movie)에 장르(Genre)가 여러 개 매핑될 수 있으므로 @ManyToMany

감독(Director)은 @ManyToOne으로 지정해두었다.

FK인 Director와 Genre 먼저 생성해보자.

Director POST API

Director를 생성하는 API를 예시로 보겠다.

{
    "name": "{{$randomFullName}}",
    "dob": "1963-05-02T00:00:00.000Z",
    "nationality": "{{$randomCountry}}"
}

이렇게 Body에 랜덤 변수들을 넣어서, 다양한 감독 정보가 쌓이도록 했다.

응답에서 받은 director의 id를 환경변수에 계속 누적하기 위해, Script에서 아래처럼 작성한다.

pm.test("Status code is 201", function () {
    pm.response.to.have.status(201);

    const body = pm.response.json();

    let directorIds = pm.environment.get("directorIds");
    if(!directorIds){
        directorIds = body.id;
    } else {
        directorIds = directorIds + ',' + body.id;
    }

    pm.environment.set("directorIds", directorIds);
});

아까와 마찬가지로 return값을 활용해야 하므로 Post-reponse 를 선택하고 스크립트를 작성하자.

이 스크립트는 Director를 하나 만들 때마다 directorIds 문자열에 ,로 ID를 이어붙여서 저장했다.

Genre POST API

Genre도 마찬가지로, 아래처럼 Body를 작성하고 응답의 id를 모아서 genreIds에 저장했다.

{
  "name": "{{$randomNoun}}"
}

pm.test("Status code is 201", function () {
    pm.response.to.have.status(201);

    const body = pm.response.json();

    let genres = pm.environment.get("genreIds");
    if(!genres){
        genres = body.id;
    } else {
        genres = genres + ',' + body.id;
    }

    pm.environment.set("genreIds", genres);
});

아까와 마찬가지로 return값을 활용해야 하므로 Post-reponse 를 선택하고 스크립트를 작성하자.

이렇게 하면, Director IDs와 Genre IDs가 각각 환경변수에 누적되므로, Movie 데이터를 만들 때 이를 참조하면 된다.

Movie (PK) POST API

{
    "title": "{{$randomNoun}} {{$randomAdjective}} {{$randomAlphaNumeric}}",
    "detail": "{{$randomLoremSentence}}",
    "directorId": {{director}},
    "genreIds": [{{genres}}]
}

{{$randomNoun}}, {{$randomAdjective}}, {{$randomAlphaNumeric}} 등을 조합해 영화 제목을 랜덤하게 만들었다.

directorId와 genreIds에 아까 쌓은 Postman 환경변수를 사용하도록 설정했다.

const _ = require('lodash');

const directorIds = pm.environment.get('directorIds').split(",");
const randomDirectorId = _.sample(directorIds);
pm.environment.set("director", randomDirectorId);

const genreIds = pm.environment.get('genreIds').split(",");
const pickedGenreIds = [];
let failCount = 0;

while(pickedGenreIds.length < 3 && failCount < 20) {
    const randomGenreId = _.sample(genreIds);

    if(pickedGenreIds.includes(randomGenreId)) {
        failCount++;
        continue;
    }

    pickedGenreIds.push(randomGenreId);
}

pm.environment.set("genres", pickedGenreIds);

방금 Body에서 {{director}}, {{genres}}라는 변수를 썼다.

이 값들은 request 전에 필요하므로 Pre-request Script에서 작성하고, 무작위로 뽑아내준다.

Lodash의 .sample() 함수를 사용해서 directorIds 중 하나를 무작위로 뽑았다.

genreIds 중 3개까지만 골라서 genres 변수에 할당했다. (중복 방지를 위해 failCount도 추가)

{
    "id": 917,
    "title": "program cross-platform t",
    "detail": {
        "id": 917,
        "detail": "Rerum voluptas omnis."
    },
    "director": {
        "id": 229,
        "name": "Kathy Cummings",
        "dob": "1963-05-02T00:00:00.000Z",
        "nationality": "Poland"
    },
    "genres": [
        {
            "id": 14,
            "name": "driver"
        },
        {
            "id": 21,
            "name": "capacitor"
        },
        {
            "id": 24,
            "name": "sensor"
        }
    ]
}

이렇게 FK 테이블(Director, Genre)을 먼저 여러 번 생성해두고,

Movie 생성 시점에 랜덤 FK를 골라 넣어주면, DB에 다양한 조합의 데이터가 쌓이게 된다.

Collection Runner로 대규모 데이터 만들기

마지막으로, Postman의 Collection Runner 기능을 사용하면 수백~수천 번 반복 호출도 간단하게 할 수 있다.

Runner 설정 방법

1. Postman에서 Collection 선택

2. Runner 실행 후, Iterations 값을 원하는 만큼 설정 (예: 10번, 50번, 100번 등)

3. Start Run 클릭하여 대량 데이터 생성.

이제 Director와 Genre API가 반복적으로 호출되어 환경변수에 ID를 계속 쌓아두고,

Movie API 호출 시 FK를 랜덤으로 할당해, DB에 방대한 테스트 데이터를 자동으로 넣을 수 있었다.

이렇게 생성된 영화 데이터들을 토대로 페이지네이션 기능을 테스트할 수도 있고,

다양한 시나리오별로 데이터를 쉽게 구성할 수 있어서 아주 편리했다 !

정리하자면,

1. Environment에 host부터 미리 셋팅을 해둔다.

2. 로그인 API로 accessToken을 받아 환경변수에 저장해두고, Bearer Token 설정을 Inherit해서 편리하게 인증한다.

3. 랜덤 변수({{$randomFullName}}, {{$randomNoun}}, {{$randomCountry}} 등)를 이용해 다양하게 테스트 데이터를 만든다

4. FK가 필요한 경우, Post-response Script에서 응답의 id를 환경변수에 저장하고,

PK 쪽(예: Movie) API에서 Pre-request Script로 무작위 샘플을 뽑아 Body에 넣어준다.

5. Collection Runner를 통해 대규모 반복 호출을 수행하면서 DB에 한꺼번에 많은 데이터를 쌓는다.

끝 !

[Typescript] Reflect Metadata를 활용한 Custom Decorator

대파양파애비 — Thu, 24 Oct 2024 03:28:08 +0900

그동안 NestJS로 개발을 하면서, class-validator 같은 라이브러리를 사용하는 건 너무나 당연한 일이였다.

별다른 고민 없이 데이터 유효성 검사를 자동으로 처리하는 데 class-validator를 사용해 왔지만,

실제로 내부에서 어떻게 작동하는지에 대한 깊은 이해 없이 그저 편리함에 의존해왔다.

하지만 이제는 그 원리를 제대로 이해하고, 더 창의적으로 Custom Decorator를 생성해서 활용해 보고자 한다.

이번 포스팅에서는 Reflect Metadata를 활용하여 런타임에도 타입 정보를 유지하고 검증하는 방법과

Custom Decorator를 만드는 법을 알아보겠다.

Reflect Metadata란?

TypeScript는 컴파일 시점에 타입 정보를 가지고 있지만, 컴파일 후 JavaScript로 변환되면 그 정보가 사라진다.

이때 Reflect Metadata를 사용하면 런타임에도 타입 정보를 유지하고 활용할 수 있다.

이는 주로 데코레이터를 사용할 때 추가적인 메타데이터를 주고받기 위해 사용되며,

클래스, 메서드, 파라미터 등의 메타정보를 코드에 삽입하거나 수정할 수 있게 해준다.

Reflect Metadata의 주요 요소

Reflect Metadata를 사용하기 위해서는 다음과 같은 요소들이 필요하다:

1. 메타데이터의 키: 메타데이터를 식별하기 위한 고유한 키.

2. 메타데이터 키에 저장할 값: 메타데이터 키에 매핑되어 저장될 값.

3. 메타데이터를 저장할 객체: 메타데이터를 저장할 대상 객체.

4. (선택 사항) 메타데이터를 저장할 객체의 프로퍼티: 메타데이터를 저장할 객체의 특정 프로퍼티.

Method Decorator

function TestMethodDecorator(target: any, propertyKey: string, descriptor: PropertyDescriptor) {}

1. target: 데코레이터가 적용된 메서드가 속한 클래스의 프로토타입 또는 생성자 함수.

- 스태틱 메서드인 경우 생성자 함수.

- 인스턴스 메서드인 경우 프로토타입.

2. propertyKey: 데코레이터가 적용된 메서드의 이름.

3. descriptor: 메서드의 속성 디스크립터로, { value, writable, enumerable, configurable } 등의 속성을 가진다.

Descriptor attributes의 역할에 대해서도 간략하게 집고 넘어가자.

1. value:

- 메서드 자체를 나타내는 값이다. 즉, 해당 메서드의 실제 구현이 저장된 속성이다.

2. writable:

- 이 속성이 true일 경우, 메서드의 value를 수정할 수 있다. false일 경우 메서드를 덮어쓸 수 없게 된다.

(값 변경시 에러는 안뜨지만 절때 안바뀐다.)

3. enumerable:

- 이 속성이 true일 경우, 객체의 속성을 열거할 때(예: for...in 루프) 이 메서드가 포함된다. false일 경우 열거되지 않는다.

(false로 설정해두고 값 변경시 값이 안보이지만 그 값이 없어진건 아님 호출하면 나온다.)

4. configurable:

- 이 속성이 true일 경우, 나중에 메서드의 속성(예: writable 등)을 수정하거나, 메서드 자체를 삭제할 수 있다.

false일 경우, 속성을 변경하거나 삭제할 수 없게 된다.

(writable 속성은 한 번만 true에서 false로 변경할 수 있다. false로 설정한 후에는 다시 true로 되돌릴 수 없다.)

데코레이터와 Reflect Metadata 예제 code

아래의 예제 코드를 통해 Reflect Metadata와 Custom Decorator를 어떻게 활용하는지 알아보자.

class Idol {
  name: string;
  age: number;

  constructor(name: string, age: number) {
    this.name = name;
    this.age = age;
  }

  sing(style: 'hiphop' | 'rock') {
    return `${this.name}이 ${style} 노래를 부릅니다.`;
  }
}

sing 메서드는 style 매개변수로 'hiphop' 또는 'rock'만을 허용한다.

하지만 컴파일 후 JS에서는 타입 정보가 사라지기 때문에, 다른 값이 들어와도 런타임에서는 오류가 발생하지 않는다.

이것이 문제점이자, Reflect Metadata 를 사용하는 가장 큰 이유이다.

매번 메서드 내부에서 조건문으로 검증하는 것은 번거롭고 매개변수가 많아질수록 코드가 아주 지저분해진다.

따라서 Reflect Metadata와 데코레이터를 사용하여 런타임에서도 매개변수 값을 제한할 수 있다.

이제 적용한 코드를 살펴보자.

npm install --save reflect-metadata

import 'reflect-metadata';

Reflect Metadata 설치하고 import 시켜준다.

const restrictParamValueKey = Symbol('restrictParamValue');

interface RestrictionInfo<T> {
  index: number;
  restrictedValues: T[];
}

function RestrictParamValue<T>(restrictedValues: T[]) {
  return (target: any, propertyKey: string, index: number) => {
    const prevMeta = Reflect.getOwnMetadata(restrictParamValueKey, target, propertyKey) ?? [];

    const info = {
      index,
      restrictedValues,
    };

    Reflect.defineMetadata(restrictParamValueKey, [...prevMeta, info], target, propertyKey);
  };
}

매개변수 데코레이터 생성

여기서 Symbol('restrictParamValue')는 고유한 메타데이터 키를 생성한다.

이 키를 통해 메타데이터에 접근할 수 있다.

RestrictParamValue는 허용할 값들의 배열을 인자로 받아 매개변수 데코레이터를 반환한다.

내부 함수는 데코레이터의 표준 형태로, target, propertyKey, index를 인자로 받는다.

- target: 데코레이터가 적용된 메서드가 속한 객체.

- propertyKey: 메서드의 이름.

- index: 매개변수의 인덱스.

Reflect.getOwnMetadata를 통해 기존에 저장된 메타데이터를 가져온다. ??로 없으면 빈 배열을 사용한다.

info 객체에 현재 매개변수의 인덱스와 허용할 값들을 저장한다.

Reflect.defineMetadata를 통해 메타데이터를 갱신한다.

function ValidateMethod(target: any, propertyKey: string, descriptor: PropertyDescriptor) {
  const metas = Reflect.getOwnMetadata(restrictParamValueKey, target, propertyKey) ?? [];
  const originalMethod = descriptor.value;

  descriptor.value = function (...args: any[]) {
    for (const meta of metas) {
      const argValue = args[meta.index];
      if (!meta.restrictedValues.includes(argValue)) {
        throw new Error(`매개변수 ${meta.index}의 값 "${argValue}"는 허용되지 않습니다.`);
      }
    }
    return originalMethod.apply(this, args);
  };
}

메서드 데코레이터 생성

ValidateMethod는 메서드 데코레이터로, 메서드 실행 전에 매개변수 검증을 수행한다.

Reflect.getOwnMetadata를 통해 해당 메서드에 저장된 매개변수 제한 정보를 가져온다.

originalMethod에 원래의 메서드 구현을 저장한다.

descriptor.value를 재정의하여 매개변수 검증 로직을 추가한다.

- 각 매개변수에 대해 허용된 값인지 검사한다.

- 허용되지 않은 값이 있으면 에러를 throw한다.

- 검증이 통과하면 원래의 메서드를 실행한다.

class Idol {
  name: string;
  age: number;

  constructor(name: string, age: number) {
    this.name = name;
    this.age = age;
  }

  @ValidateMethod
  sing(@RestrictParamValue(['hiphop', 'rock']) style: string) {
    return `${this.name}이 ${style} 노래를 부릅니다.`;
  }
}

데코레이터 적용

@RestrictParamValue(['hiphop', 'rock']) 데코레이터로 sing 메서드의 style 매개변수에 허용할 값들을 지정한다.

@ValidateMethod 데코레이터로 메서드 실행 전에 매개변수 검증을 수행하도록 한다.

const idol = new Idol('Newjeans', 20);

console.log(idol.sing('hiphop')); // 정상 동작
console.log(idol.sing('ballad')); // 오류 발생: 매개변수 0의 값 "ballad"는 허용되지 않습니다.

허용되지 않은 'ballad'를 전달하면, 에러가 발생한다.

한번 더 전체적인 흐름을 정리해보자.

1. 메타데이터 키 생성: 메타데이터를 저장하고 읽을 때 사용할 고유한 키를 생성한다.

2. 매개변수 데코레이터: 매개변수에 허용할 값들을 지정하고, 해당 정보를 메타데이터에 저장한다.

3. 메서드 데코레이터: 메서드 실행 전에 메타데이터를 참고하여 매개변수를 검증한다.

4. 데코레이터 적용: 클래스의 메서드와 매개변수에 데코레이터를 적용하여 검증 로직을 추가한다.

메서드 실행 시간을 측정하는 Custom Decorator 만들기

이제 전반적인 흐름에 대해 이해를 했으니 간단한 Custom Decorator를 만들어보자.

애플리케이션을 개발하다 보면 성능 최적화가 필요한 부분을 식별해야 할 때가 많다.

어떤 메서드가 오래 걸리는지, 병목 현상이 어디서 발생하는지 알기 위해서는 메서드의 실행 시간을 측정하는 것이 중요하다.

예전에 CloudWatch로 메서드의 실행 시간을 비교해서 모니터링 하는것을 만들어 보기도 했었다.

https://ilikezzi.tistory.com/71

[AWS] 서버 상태 실시간 모니터링: CloudWatch를 이용한 Nginx 액세스 로그 분석 및 대시보드 구축하기

AWS에서 서비스를 운영하다 보면, 서버의 상태를 실시간으로 파악하는 것이 얼마나 중요한지 잘 알게 될 것이다. 특히 웹 서버인 NGINX에서 발생하는 액세스 로그를 분석하고 모니터링하는 것은,

ilikezzi.tistory.com

이번에는 간단하게 실행 시간이 특정 임계값(threshold)을 초과할 때만 로그를 출력하는

LogExecutionTime 데코레이터의 코드를 짜보자.

function LogExecutionTime(threshold: number = 0) {
  return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
    const originalMethod = descriptor.value;

    descriptor.value = function (...args: any[]) {
      const start = Date.now();
      const result = originalMethod.apply(this, args);
      const finish = Date.now();
      const time = finish - start;

      if (time >= threshold) {
        console.log(`${propertyKey} 실행 시간: ${time}ms`);
      }

      return result;
    };
  };
}

데코레이터 팩토리: LogExecutionTime은 데코레이터 팩토리 함수로, threshold라는 매개변수를 받는다.

이 매개변수는 실행 시간이 이 값 이상일 때만 로그를 출력하도록 한다.

데코레이터 함수 반환: 데코레이터 팩토리는 실제 데코레이터 함수를 반환한다.

이 함수는 target, propertyKey, descriptor를 매개변수로 받는다.

(해당 매개변수에 대한 설명은 위에서 작성했어서 생략한다)

원래 메서드 저장: const originalMethod = descriptor.value;를 통해 원래의 메서드 구현을 저장해둔다.

이후에 이 메서드를 호출해야 하므로 따로 보관한다.

메서드 재정의: descriptor.value에 새로운 함수를 할당하여 메서드를 재정의한다.

이 새로운 함수는 실행 시간 측정 로직을 포함한다.

실행 시간 측정: 메서드 실행전 (start), 메서드 실행 후(finish)로 실행 시간을 계산한다.

조건부 로그 출력: if (time >= threshold) { ... }를 통해 실행 시간이 임계값 이상인 경우에만 로그를 출력한다.

결과 반환: return result;를 통해 원래 메서드의 실행 결과를 반환한다.

class Calculator {
  @LogExecutionTime(10) // 실행 시간이 10ms 이상인 경우에만 로그 출력
  fibonacci(n: number): number {
    if (n <= 1) return n;
    return this.fibonacci(n - 1) + this.fibonacci(n - 2);
  }
}

const calc = new Calculator();
calc.fibonacci(10);

fibonacci 실행 시간: 55ms

@LogExecutionTime(10) 데코레이터를 fibonacci 메서드에 적용해보았다.

이 데코레이터는 실행 시간이 10ms 이상인 경우에만 실행 시간을 로그로 출력한다.

calc.fibonacci(10);을 호출하면 피보나치 수를 계산하면서 실행 시간이 측정된다.

n의 값이 커질수록 재귀 호출이 많아져 실행 시간이 길어지므로, 임계값을 적절히 조정하면 된다.

마지막으로 방금 데코레이터에 기능을 좀 더 추가한 데코레이터를 살펴보자.

function LogExecutionTime(threshold: number = 0) {
  let maxTime = 0;
  let maxMethod = '';

  return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
    const originalMethod = descriptor.value;

    descriptor.value = function (...args: any[]) {
      const start = Date.now();
      const result = originalMethod.apply(this, args);
      const finish = Date.now();
      const time = finish - start;

      if (time >= threshold) {
        console.log(`${propertyKey} 실행 시간: ${time}ms`);
      }

      if (time > maxTime) {
        maxTime = time;
        maxMethod = propertyKey;
      }

      return result;
    };

    // 클래스가 로드될 때 실행되는 코드
    process.on('exit', () => {
      console.log(`가장 오래 걸린 메서드: ${maxMethod} (${maxTime}ms)`);
    });
  };
}

이 코드는 LogExecutionTime 데코레이터를 정의하여 메서드의 실행 시간을 측정하고,

임계값을 초과하면 로그를 출력하며, 가장 오래 걸린 메서드를 추적한다.

(전반적인 프로세스는 다 똑같아서 설명은 생략하겠다)

마치며

첫번째 예시를 잘 이해했다면 따라오기 쉬웠을 것이다.

이렇게 데코레이터를 사용하면 중복 코드 제거, 관심사의 분리, 깔끔한 코드 등 장점이 있으나, 물론 단점도 존재한다.

디버깅 어려움: 데코레이터를 통해 메서드가 재정의되므로 디버깅 시 호출 스택이 복잡해질 수 있다.

성능 영향: 데코레이터 자체가 추가 연산을 수행하므로 성능에 민감한 부분에서는 주의해야 한다.

가독성 저하: 데코레이터가 너무 많으면 코드가 복잡해져 가독성이 떨어질 수 있다.

이번 포스팅에서는 Reflect Metadata와 Custom Decorator를 활용하여 런타임에서도

타입 정보를 유지하고 검증하는 방법을 알아보았다.

우리가 NestJS와 같은 프레임워크에서 이미 편리하게 사용하고 있던 class-validator 등의 라이브러리가

내부적으로 어떻게 동작하는지 이해하게 되면서, 그 원리를 직접 적용해 보았다.

Reflect Metadata를 사용하면 런타임에도 타입 정보를 유지하며, 메서드와 매개변수에 대한 검증을 더욱 쉽게 할 수 있다.

또한, 메서드의 실행 시간을 측정하거나, 메서드의 동작을 제한하는 등 다양한 커스텀 데코레이터를 통해

코드의 중복을 줄이고 가독성을 높일 수 있었다.

물론, 데코레이터의 남용은 코드의 복잡성을 높이고 디버깅을 어렵게 할 수 있기 때문에 적절히 사용하는 것이 중요하다.

앞으로도 TypeScript의 강력한 기능들을 깊이 있게 이해하고 활용하여 더욱 효율적이고 안정적인 코드를 작성하도록 해야겠다!

참조 :

https://www.npmjs.com/package/reflect-metadata

https://www.typescriptlang.org/ko/docs/handbook/decorators.html

https://toss.tech/article/nestjs-custom-decorator

https://www.inflearn.com/course/%EC%BD%94%EB%93%9C%ED%8C%A9%ED%86%A0%EB%A6%AC-%ED%83%80%EC%9E%85%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%ED%92%80%EC%BD%94%EC%8A%A4

[책 리뷰] 객체지향의 사실과 오해

대파양파애비 — Mon, 26 Aug 2024 15:30:41 +0900

얼마 전, 약 2년간 다녔던 회사를 퇴사했다.

퇴사 후 한두 달 정도는 아예 코드를 쳐다보지 않고 푹 쉬었다.

이직을 바로 할까 고민하다가, 실업급여를 받을 수 있는 기회도 생겨서 이번 기회에 부족한 부분을 채우기로 했다.

무작정 코드를 작성하기보다는, 내 코드의 구조를 고민하다가 객체지향에 대해 좀 더 깊이 있게 알고, 코드에 적용해보고 싶어졌다.

그러던 중 조영호 저자의 "객체지향의 사실과 오해" 와 "오브젝트" 라는 책을 알게 되었다.

찾아보니 둘다 객체지향 관련 책이지만

"오브젝트"는 실질적인 구현에 관한 코드 위주의 책이고,

"객체지향의 사실과 오해"는 제목 그대로 객체지향의 개념과, 사람들이 오해하는 포인트를 잡아서 설명하는 설명해주는 책이다.

나는 CS지식이 탄탄하지 않아서 평소 코딩을 할 때에도 "왜??" 라는 의문을 품었던 적이 많았다.

그래서 나는 좀 더 개념을 다루는 "객체지향의 사실과 오해"를 선택하게 되었다.

객체지향 프로그래밍이란?

이 책에서는 “커피 주문”이나 “이상한 나라의 앨리스”와 같은 비유를 들어 객체지향 개념을 설명하고 있다.

복잡하다고 느꼈던 개념들이 비유를 통해 훨씬 쉽게 다가왔다.

시너지를 생각하라. 전체는 부분의 합보다 크다. - 스티븐 코비

객체지향 프로그래밍은 현실 세계에 존재하는 사물을 최대한 유사하게 소프트웨어 내부로 옮겨오는 작업이다.

하지만 이 과정은 단순히 현실 세계를 모방하는 것이 아니다.

이 작업은 신세계를 창조하는 것에 가깝다.

객체지향 패러다임의 목적은 현실 세계를 기반으로 새로운 세계를 창조하는 것이다.

책에서는 “커피 주문”을 예시로 들어 설명하고 있다.

손님, 캐시어, 바리스타는 각각의 역할과 책임을 갖고 있으며, 이들은 협력을 통해 문제를 해결한다.

어떤 객체도 단독으로 존재하지 않으며, 항상 협력한다.

"객체는 다른 객체가 무엇(what)을 수행하는지 알 수 있지만 어떻게(how) 수행하는지에 대해서는 알 수 없다"

클래스가 아닌 객체 중심의 사고

객체지향의 중심은 클래스가 아니라 객체다.

메시지를 주고받는 객체의 관점에서 사고의 중심을 전환해야 한다.

클래스는 객체들의 협력 관계를 코드로 옮기는 도구에 불과하다.

소프트웨어 세계와 현실 세계의 가장 큰 차이점은 소프트웨어 세계의 객체들이 모두 “스스로” 행동한다는 점이다.

예를 들어, 전등이 외부의 도움 없이 스스로 켜지고, 자동차가 스스로 시동을 거는 것처럼 말이다.

객체지향의 세계에서 모든 객체는 자신의 상태를 스스로 관리하는 자율적인 존재다.

객체의 상태와 행동

객체는 상태를 통해 과거의 행동을 기억하며, 상태 변경에 따라 유일하게 식별될 수 있다.

상태가 중요한 이유는 과거의 행동이 현재의 행동에 영향을 미치기 때문이다.

하지만 객체지향에서 더 중요한 것은 행동이다.

행동이 상태를 결정하고, 객체를 결정하는 것도 행동이다. 중요한 것은 상태가 아닌 행동에 초점을 맞추는 것이다.

객체지향 입문자들이 자주 하는 실수는 상태를 중심으로 객체를 바라보는 것이다.

상태를 먼저 결정하고 행동을 나중에 결정하면, 설계에 부정적인 영향을 미칠 수 있다.

구체적으로, 이런 접근 방식은 캡슐화를 저해하고, 객체를 고립된 섬처럼 만들며, 결과적으로 객체의 재사용성을 떨어뜨린다.

왼쪽과 오른쪽에 차이점은 지도가 당연히 가져야한다고 생각되는 "정확성"을 버리고 그 "목적"에 집중했다.

즉 상태가 아닌 행동에 초점을 둔 것이다.

결론적으로 객체의 타입을 결정하는것은 객체의 행동뿐이다.

동일한 행동 === 동일한 책임 === 동일한 메시지 수신

일반화/특수화 = 슈퍼 타입/서브 타입

이 개념 역시 행동과 관련이 있다.

슈퍼 타입과 서브 타입을 구분하는 기준은 다른 타입보다 더 특수하게 행동하는지, 아니면 더 일반적으로 행동하는지에 따라 결정된다.

다형성과 책임

다형성이란 서로 다른 유형의 객체가 동일한 메시지에 대해 다르게 반응하는 것을 의미한다.

이러한 다형성은 코드의 유연성을 극대화하며, 객체지향 설계에서 역할과 책임의 명확한 분리를 가능하게 한다.

코드의 재사용성을 높이고, 새로운 객체를 추가할 때 기존 코드를 수정할 필요 없이 확장할 수 있게 만들어준다.

결국 다형성은 객체들이 동일한 인터페이스를 통해 다양한 방식으로 행동할 수 있도록 하여,

설계를 더욱 유연하고 강력하게 만든다.

객체의 책임과 메시지

객체의 책임은 외부에 제공할 수 있는 정보와 서비스의 목록을 의미한다.

이는 객체의 인터페이스를 구성하며, 객체의 역할을 대체할 수 있는 다른 객체는 동일한 메시지를 이해할 수 있어야 한다.

테스트 주도 개발(TDD)의 목표는 역할, 책임, 협력을 명확히 식별하고, 이를 코드로 구현한 후 피드백을 받는 것이다.

테스트는 단지 TDD를 통해 얻을 수 있는 별도의 보너스 같은것이다.

이 과정에서 객체가 자율적이기 위해서는 객체에게 부여되는 책임의 수준 또한 자율적이어야 한다.

“메시지는 어떻게(how)가 아니라 무엇(what)을 해야 하는지를 요청하는 것이다.”

메시지 중심의 설계에서 중요한 것은 메시지가 객체에 무엇을 요청하는가이다.

설계의 품질을 높이기 위해서는 훌륭한 메시지를 선택해야 하며,

객체지향의 강력함은 클래스가 아니라 객체들이 주고받는 메시지에서 비롯된다.

메시지 중심의 설계

객체지향 설계의 핵심은 객체 자체가 아닌 객체들이 주고받는 메시지에 있다.

메시지는 객체가 무엇을 해야 하는지를 요청하며, 이는 객체의 공용 인터페이스를 통해 외부로 노출된다.

책임 주도 설계(Responsibility-Driven Design) 방식에서는 What/Who 사이클을 따른다.

먼저 어떤 행위(What)를 수행할지를 결정한 후, 누가(Who) 그 행위를 수행할지를 결정하는 것이다.

여기서 어떤 행위가 바로 메시지에 해당한다.

이러한 책임 주도 설계는 객체가 아닌 객체들이 주고받는 메시지에 초점을 맞추어, 객체지향의 장점을 극대화한다.

메시지는 어떻게가 아닌 무엇을 해야 하는지를 요청하는 방식으로 설계를 단순화하고, 객체의 인터페이스 크기를 줄인다.

객체의 공용 인터페이스는 외부에서 전송 가능한 메시지의 집합으로 정의되며,

이는 객체가 외부와 어떻게 상호작용하는지를 명확하게 나타낸다.

결론

객체지향 프로그래밍은 객체들의 협력과 메시지에 초점을 맞춘다.

행동이 상태를 결정하며, 객체는 자율적인 존재로서 자신의 상태를 관리한다.

설계의 중심은 객체가 아니라 객체들이 주고받는 메시지에 있으며, 이를 통해 유연하고 확장 가능한 소프트웨어를 만들 수 있다.

역할, 책임, 협력 등 객체지향의 핵심 개념들을 이해하고 적용함으로써, 더 유연하고 확장 가능한 설계를 할 수 있을 것 같다.

이 책을 다 읽고 나니, 객체지향이 무엇인지에 대한 개념이 대략적으로 잡히는 것 같다.

객체지향이라는 주제를 깊이 있게 다루면서도 실생활의 예시를 통해 쉽게 이해할 수 있게 해준 덕분에

복잡하게만 느껴졌던 개념들이 점점 명확해졌다.

특히, 객체지향의 본질과 설계 원칙에 대해 고민하게 되어, 앞으로의 코드 작성에 큰 도움이 될 것 같다.

책에는 "비개발자가 책을 읽더라도 이해하는 데는 큰 무리가 없을 정도로 일반적이고 평이한 난이도를 유지하기 위해 노력했습니다."

라고 써 있지만 나는 아예 객체지향에 낯선 사람보다 객체지향 코드를 적어도 1년 정도 다뤄본 사람에게 더 적합해 보인다.

객체지향의 구조를 고민해본 사람이라면 꼭 읽어보길 권한다.

- LinkedIn 조영호님

그리고 어쩌다보니 이 책의 저자인 조영호님께 피드백을 받았다...!

감사합니다

[TypeORM] 밤 12시, 수만 명의 출석체크에 대응한 동시성 문제 해결기

대파양파애비 — Wed, 20 Mar 2024 09:19:39 +0900

운영중인 앱에서 출석체크 이벤트를 도입하게 되었다.

출석체크 이벤트는 사용자들에게 매일 자정에 접속하여 출석체크를 하면 보상을 제공하는 간단한 메커니즘이다.

하지만...

예상했던 것 이상으로 수만 명의 사용자들로부터 동시에 들어오는 출석체크 요청의 폭풍에 직면했다.

동시성 문제

수만 명의 사용자들로부터 동시에 들어오는 요청을 처리하는 것은 결코 간단한 일이 아니었다.

서버의 자원은 한정되어 있고, 동시에 너무 많은 요청이 처리될 경우

데이터베이스 충돌, 성능 저하, 심지어는 서비스 다운에 이르기도 한다.

이는 단순히 기술적인 도전을 넘어, 우리 서비스의 안정성과 사용자의 신뢰성에 대한 문제였다.

CloudWatch를 확인해보면 출석체크가 시작되는 밤 12시 (UTC 15:00)에

API 요청이 수만 건으로 확 치솟는 게 보일 것이다.

동시성 문제를 해결하기 위해선 먼저 문제의 본질을 이해해야 했다.

동시에 들어오는 수많은 요청이 데이터베이스에 동일한 쓰기 작업을 요구할 때,

이는 데이터의 무결성을 해치고, 충돌이나 데이터 손실로 이어질 수 있다.

출석체크 이벤트에 동시에 참여하려는 수만 명의 사용자들이 이 문제를 발생시키기엔 충분했다.

추가로 우리 시스템이 서버가 4대로 분리되어 있다는 특성도 큰 영향을 미쳤다.

서버 4대가 분리되어 있다는 것은, 각 서버가 동시에 독립적으로 같은 데이터에 접근하려 할 때

데이터 일관성을 유지하는 것이 더욱 어렵다는 것을 의미한다.

이는 각 서버 간에 상태를 동기화하는 복잡성을 증가시키며,

단순히 한 대의 서버에서만 동시성을 관리하는 것보다 훨씬 더 많은 고려 사항을 필요로 한다.

이제 이 문제점들을 어떻게 해결했는지 알아보자.

Pessimistic Locking

동시성 문제에 대응하기 위해 먼저 TypeORM의 Pessimistic Locking(비관적 잠금 기능)을 활용하기로 했다.

Pessimistic Locking은 특정 데이터에 대한 변경이나 조회를 시도할 때,

해당 데이터를 잠가 다른 트랜잭션의 접근을 차단하는 방법입니다.

이는 데이터의 일관성을 유지하고, 동시성 문제에서 발생할 수 있는 데이터 무결성 위반을 방지하는 데 큰 도움이 된다.

예를 들어, 두 사용자가 동시에 같은 계정의 잔액을 수정한다고 해보자.

Pessimistic Lock을 사용하면, 첫 번째 사용자가 해당 데이터에 접근하여 잠금을 걸면,

두 번째 사용자는 첫 번째 사용자의 작업이 완료되고 잠금이 해제될 때까지 기다려야 한다.

이렇게 하면 데이터의 동시 수정으로 인한 충돌이나 불일치를 방지할 수 있다.

Pessimistic Lock

이런식으로 TypeORM에서 Pessimistic Lock을 사용할 수 있다.

추가로 Optimistic Locking(낙관적 잠금 기능)도 존재 하지만 Pessimistic Lock을 선택한 이유는

포인트 지급과 같은 중요한 작업의 데이터 일관성과 무결성을 최우선으로 고려했기 때문이다.

Optimistic Locking으로는 충돌 해결 과정에서 발생할 수 있는 데이터 일관성 문제를 효과적으로 관리하기 어렵다.

Unique 제약 조건

유니크 키는 특정 컬럼(또는 컬럼들의 조합)에 대해 각 행의 값이 전체 테이블에서 유일함을 보장하는 제약 조건이다.

이를 통해 사용자의 출석체크 데이터에서 같은 사용자가 같은 이벤트에 두 번 이상 참여하는 것을 방지할 수 있다.

이는 우발적인 중복 요청이나 네트워크 지연으로 인한 재시도 요청으로부터도 데이터의 무결성을 보호하는 역할을 했다.

ALTER TABLE user_attend_check
ADD UNIQUE UNIQ_user_attend_check_user (user_id, event_id, check_date);

이런식으로 MySQL DB에 Unique 제약 조건을 걸 수 있다.

해결 완료

Pessimistic Lock과 Unique 제약 조건을 활용한 접근 방식은 우리 서비스의 동시성 문제를 해결하는 데 큰 도움이 되었다.

특히, 서버 4대에서 동시에 처리되는 요청들 사이에서 데이터의 일관성과 정확성을 유지할 수 있게 되었다.

이로 인해 사용자 경험이 크게 개선되었고, 시스템의 안정성도 높아졌다.

이 모든 과정을 통해, 나는 단순히 동시성 문제를 해결하는 것을 넘어,

분산 시스템 환경에서도 데이터의 일관성과 무결성을 유지할 수 있는 방법을 찾아냈다.

앞으로도 이러한 경험을 바탕으로 더 나은 서비스와 유저 경험을 제공하도록 노력해야겠다!

[해커톤] 연대 X 숙대 ABC LIVING LAB 해커톤 멘토 참여 후기

대파양파애비 — Tue, 12 Mar 2024 22:00:15 +0900

간만에 해커톤 멘토링을 다녀오게 되어서 포스팅을 해보려 한다.

24.03.09 - 24.03.10

연대 X 숙대 ABC LIVING LAB HACKATHON

이번 해커톤은 리빙랩 해커톤이라서 메인 주제는 AI/Cloud/Bigdata를 이용해 지역사회의 문제를 해결하는 서비스를 개발해보는 것이다.

참여한 학생들은 AWS Cloud과정을 사전 교육으로 받았으며,

특히 이전 해커톤과 다르게 AWS Bedrock 이라는 서비스 활용을 권장했다.

나도 이번 기회에 처음 접해보게 되었다..

간략하게 AWS Bedrock 이란 ?

다양한 고성능 파운데이션 모델을 단일 API를 통해 제공하는 완전관리형 서비스이다.

이 서비스를 활용하면, 사용자들은 AI 기반의 생성형 AI 애플리케이션을 쉽게 개발하고 확장할 수 있으며,

AWS 서비스를 통해 생성형 AI 기능을 인프라 관리 없이 애플리케이션에 통합하고 배포할 수 있는 장점이 있다.

이번 해커톤은 AWS 본사에서 진행되었으며

나는 3시쯤 도착했는데 아이디어 브레인스토밍로 다들 머리를 싸매고 있었다.

이 시간이 해커톤에서 가장 중요한 순간 중 하나다.

리빙랩이라는 주제에 부합하면서, 생성형 AI 및 Elastic Search도 접목하고,

제한된 시간안에 현실적으로 구현이 가능한 아이디어를 정하는것은 정말이지 어려운 일이다.

해커톤 현장을 돌아다니며 다양한 팀들의 아이디어 스피치하는 시간을 가졌다.

각 팀의 프로젝트에 대한 소소한 피드백을 나누는 것은 생각보다 더 의미 있는 경험이었다.

"이미 존재하는 서비스와의 작은 차별점을 찾아보는 것도 하나의 방법이 될 수 있어요"

"ChatGPT를 활용하는 건 좋지만, 가끔 데이터를 잘못 인식할 수도 있으니 이에 대비한 대책이 필요할 것 같다"

"사용자 범위를 명확히 하여, 타겟 이용자의 필요와 문제점을 이해하고, 그들의 관점에서 실질적인 가치를 제공하는 것이 중요해요."

등등.. 다양한 피드백을 제시해주었다.

이 과정에서, 조금이나마 방향을 잡아준것 같아서 만족스러웠다!

깨알 내사진...

뭔가 열심히 알려주고 있는거 같은데 기억이 안난다 ㅎ

무박 2일로 하는 해커톤이다 보니깐 새벽엔 눈이 반토막 되어있었다.

팀별 아이디어 스피치를 했을 때 솔직히 조금은 걱정이 앞섰지만

걱정과 달리, 모든 학생들이 보여준 열정과 노력은 정말 놀라웠다.

더욱 놀라운 것은, 포기하는 팀이 단 한 팀도 없었다는 사실이다.

모든 팀이 제한된 시간 내에 실제로 구현까지 마무리 지었다는 점에서 정말 대단했다!

학생들이 밤새우며 Slack으로 다양한 이슈들을 SOS 치면 달려가서 도움을 주었는데,

Elastic Search를 사용해 본 적이 없어서 관련 질문들에 내가 도움을 전혀 주지 못했다..

그래서 이참에 지금 진행 중인 사이드 프로젝트에다가 Elastic Search를 붙혀볼 생각이다.

다음엔 좀 더 도움이 될 수 있도록 미리미리 준비를 해둬야겠다.

이번 해커톤도 배우고 얻어가는 점이 너무나 많았다.

다들 고생하셨습니다 !

[AWS] 서버 상태 실시간 모니터링: CloudWatch를 이용한 Nginx 액세스 로그 분석 및 대시보드 구축하기

대파양파애비 — Tue, 20 Feb 2024 00:08:37 +0900

AWS에서 서비스를 운영하다 보면, 서버의 상태를 실시간으로 파악하는 것이 얼마나 중요한지 잘 알게 될 것이다.

특히 웹 서버인 NGINX에서 발생하는 액세스 로그를 분석하고 모니터링하는 것은,

서비스의 성능을 유지하고 사용자 경험을 개선하는 데 필수적이다.

그런데 많은 사람들이 이런 중요한 데이터를 어떻게 효과적으로 수집하고 분석할 수 있는지에 대해 궁금해 하는데

여기서 AWS의 CloudWatch Logs가 빛을 발한다.

CloudWatch Logs는 로그 데이터를 실시간으로 수집하고, 저장하며, 접근할 수 있게 해주는 서비스이다.

내가 서비스중인 앱에 최근에 유저가 5배 가량 확 증가하면서 사용자 경험을 개선하고, 서비스를 더욱 최적화하기 위해서 구축하기로 했다.

이제 AWS의 NGINX 액세스 로그를 CloudWatch Logs로 전송하는 과정을 단계별로 자세하게 알아보자.

IAM 역할 생성 및 EC2 인스턴스에 할당하기

AWS에서 서비스 간 통신을 위해 IAM 역할이 필수적이다.

CloudWatch Logs에 로그를 보낼 수 있도록 EC2 인스턴스에 권한을 부여하는 것부터 시작해보자.

IAM 콘솔에 접속하여 역할(Role) 섹션으로 이동하자.

여기서 "새 역할 생성(Create new role)"을 선택한다.

AWS 서비스를 선택하고, 사용 사례로 EC2를 선택한 다음, "권한(Next: Permissions)"을 클릭한다.

CloudWatchLogsFullAccess 정책을 검색해서 선택하고, 역할 이름을 지정한 후 역할을 생성한다.

이렇게 하면 EC2 인스턴스가 CloudWatch Logs에 로그를 보낼 권한을 갖게 된다.

생성된 IAM 역할을 EC2 인스턴스에 할당해야 한다.

EC2 대시보드에서 인스턴스를 선택하고 작업 -> 보안 -> IAM 역할 수정으로 이동해서 새로 생성한 역할을 선택하면 된다!

CloudWatch Logs Agent 설치 및 구성하기

EC2 인스턴스에서 로그를 수집하고 CloudWatch로 전송하기 위해선 CloudWatch Logs Agent가 필요하다.

Ubuntu 기반의 시스템에서는 CloudWatch Unified Agent를 설치하고 구성하는 과정을 따라야 한다.

- AWS CLI 설치하기

먼저, EC2 인스턴스에 AWS CLI가 설치되어 있는지 확인해야 한다.

설치되어 있지 않다면 다음 명령어로 설치할 수 있다.

sudo apt-get update
sudo apt-get install awscli -y

- CloudWatch Logs Agent 설치하기

이제 CloudWatch Unified Agent를 설치할 차례다.

홈 디렉토리로 이동한 후, 다음 명령어를 실행해서 Agent를 다운로드하고 설치하자.

cd ~

wget https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb

sudo dpkg -i amazon-cloudwatch-agent.deb

- CloudWatch Agent 구성하기

CloudWatch Agent를 설치한 후, 로그와 메트릭을 CloudWatch로 보낼 수 있도록 구성해야 한다.

이 과정에서 로그 파일의 위치, 로그 그룹 및 스트림 이름 등을 지정할 수 있다.

구성 파일을 직접 수정하거나 구성 마법사를 사용할 수 있다.

구성 마법사를 사용하려면 다음 명령어를 실행하자.

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

또는, 구성 파일을 직접 편집하고 싶다면 다음 명령어를 실행하자.

sudo nano /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json

여기서는 NGINX 액세스 로그 파일의 경로, 로그 그룹 이름 등을 지정해야 한다.

간단한 예시를 보자.

{
    "agent": {
        "metrics_collection_interval": 60,
        "run_as_user": "cwagent"
    },
    "metrics": {
        "metrics_collected": {
            "disk": {
                "measurement": [
                    "used_percent"
                ],
                "metrics_collection_interval": 60,
                "resources": [
                    "*"
                ]
            },
            "mem": {
                "measurement": [
                    "mem_used_percent"
                ],
                "metrics_collection_interval": 60
            }
        }
    },
    "logs": {
        "logs_collected": {
            "files": {
                "collect_list": [
                    {
                        "file_path": "/var/log/nginx/**액세스 로그 파일**",
                        "log_group_name": "**원하는 로그 그룹 이름**",
                        "log_stream_name": "{instance_id}",
                        "timezone": "Local"
                    }
                ]
            }
        }
    }
}

위의 "file_path" 와 "log_group_name"만 알아서 자신의 환경에 맞게 적절하게 입력 해준다.

CloudWatch Agent 실행 및 모니터링

구성이 완료된 후, CloudWatch Agent를 시작해야 로그가 CloudWatch로 전송된다.

Agent를 시작하기 위해 다음 명령어를 실행하자.

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json -s

로그를 확인하거나, Agent의 상태를 확인하고 싶다면 다음 명령어를 실행하자.

sudo systemctl status amazon-cloudwatch-agent

설정을 변경해서 재시작을 하고 싶다면 다음 명령어를 실행하자.

sudo systemctl restart amazon-cloudwatch-agent

로그 모니터링 및 분석

이제 설정은 모두 끝나서 확인을 하러 가보자.

CloudWatch > 로그그룹 > 아까 설정하면서 만든 로그그룹 선택

이제 하단에 로그 스트림에 자동으로 추가가 되어 있을 것이다.

눌러서 들어가보자.

정상적으로 Nginx 액세스 로그가 쌓이는 중이다!!!

이제 해당 로그값들을 보기 쉽게 대시보드에 구축을 해보자.

다양한 지표 분석 및 대시보드 구축하기

CloudWatch > 대시보드 생성 > "+" 버튼 클릭

로그 유형에서 원하는 위젯을 골라주자.

그 다음, Logs Insights에 들어왔으면 내가 아까 만든 로그그룹을 선택한다.

이제 쿼리를 짜면 되는데 이전에 로그 스트림에서 나왔던 로그 형식을 참고해서 쿼리를 작성하자.

한가지 예시를 보여주자면

나는 "응답시간이 1초를 초과하는 요청 수"를 만들었다.

parse @message "* - - [*] \"*\" * * \"*\" \"*\" *" as ip_address, timestamp, request, status, body_bytes_sent, referer, user_agent, upstream_response_time
| filter user_agent != "ELB-HealthChecker/2.0"
| filter upstream_response_time > 1.0
| stats count() by bin(10m)

이런식으로 "응답시간 1초를 초과하는 요청 수" 의 합을 막대 그래프로 뽑아서,

어느시간에 요청이 전반적으로 느려졌는지 구했다!

이제 그래프 우측 상단에 "대시보드에 추가"를 하면 끝이다.

CloudWatch Nginx access log

추가로 나는 우선 4가지를 더 만들었다.

흔히들 HTTP status를 가지고 대시보드로 많이 만들던데 지금 서비스에 status가 문제가 있어서... 다른걸 이용했다.

- 평균 응답 시간

평균 응답 시간을 모니터링함으로써, 우리는 서버가 얼마나 빠르게 사용자의 요청에 반응하는지를 파악할 수 있다.

이는 애플리케이션의 성능을 실시간으로 감시하고, 필요한 경우 즉시 개선 조치를 취할 수 있는 근거를 제공해준다.

- 요청 수

전체 요청 수를 추적하는 것은 우리에게 웹 애플리케이션에 대한 사용자 트래픽의 양과 패턴을 이해할 수 있는 통찰력을 준다.

이 정보를 활용함으로써, 우리는 서버 용량을 적절히 계획하고 조정하여 사용자 경험을 최적화할 수 있다.

- 특정 IP 주소로부터의 요청 수

특정 IP 주소로부터 오는 요청 수를 모니터링함으로써, 우리는 비정상적인 트래픽 패턴이나 의심스러운 행동을 조기에 탐지할 수 있다.

이는 서비스의 보안 위협에 대응하고, 안정성을 유지하는 데 큰 도움이 된다.

- 응답시간이 1초를 초과하는 요청 수

응답 시간이 1초를 초과하는 요청의 수를 분석함으로써, 우리는 사용자 경험에 부정적인 영향을 미치는 느린 요청을 식별할 수 있다.

이 데이터를 기반으로 성능 최적화를 진행함으로써, 전반적인 서비스 품질을 개선할 수 있는 기회를 얻게 된다.

[SeoulSync82] HTTPS와 SameSite로 해결한 서로 다른 도메인의 Cookie 전송 이슈

대파양파애비 — Mon, 29 Jan 2024 23:34:03 +0900

소셜로그인

오늘은 이전에 만들었던 소셜로그인에 이슈가 생겼는데 2주정도 머리 쥐어뜯다가 해결을 해서

관련 내용을 포스팅 해보려고 한다.

https://ilikezzi.tistory.com/65

[Nest.JS] 구글, 네이버, 카카오 소셜로그인 구현 - 2

소셜로그인 1편에 이어서 바로 2편을 포스팅하려 했는데 refresh_token과 JWT 전략에 대해서 이것저것 머리싸매면서 고민하느라 늦어졌다.. 정말 다양한 JWT 전략과 고민할 사항이 많았다. 한 계정으

ilikezzi.tistory.com

소셜로그인 전략을 어떻게 구성했는지는 위의 포스팅을 참고하길 바란다.

일단 소셜로그인 전략에 대해 간략하게 얘기해보자면,

소셜로그인 전략

1. 첫 로그인 시 access_token / refresh_token 발급

2. access_token은 1시간 만료기간으로 로컬스토리지에 저장

3. refresh_token은 2주 만료기간으로 Set-Cookie 헤더에 httpOnly 쿠키로 저장 + DB에 저장

4. access_token이 만료되었으면 쿠키에 저장된 refresh_token을 검증해서 새로운 access_token 발급

ㄴ (Silent Refresh API)

이런 식으로 이루어져 있다.

문제 이슈

위의 4번째 전략에서 Silent Refresh API를 프론트에서 호출시 새로운 access_token 발급이 안된다고 했다.

이 문제를 해결하기 위해 코드를 디버깅하기 시작했다.

silent refresh api

"getRefreshToken" 이 undefined로 출력 되더라

그래서 return 값에 access_token이 아닌 false만 출력되고 있었다...

애초에 헤더에 cookie가 저장되지 않았나? 하고 확인을 해보았다.

Cookie는 정상적으로 헤더에 저장되어 있었다.

다만, Cookie를 헤더에서 꺼내오지 못하고 있었다.

구글링을 해보니 credentials:true 옵션을 찾았다.

이 옵션을 프론트,백엔드 둘 다 설정하면 동일 출처 또는 다른 출처에 관계없이

모든 HTTP 요청에 쿠키를 포함시킨다고 했다.

즉, 크로스 오리진 요청에서도 쿠키를 보내고 받을 수 있다.

main.ts

그래서 바로 해당 옵션을 추가하고 테스트를 해봤는데

여전히 안되더라...

그 후 다양하게 테스트를 해보다가

프론트(staging) - 백엔드(staging) 이렇게 같은 환경에서는 정상적으로 쿠키를 꺼내오고 있는걸 확인했다 !

이제서야 문제점을 제대로 파악했다.

쿠키는 기본적으로 동일한 도메인 및 서브 도메인으로만 전송되도록 설정되어 있어서,

서로 다른 도메인 간에는 쿠키가 공유되지 않았던것이였다.

프론트엔드 로컬 환경에서 테스트를 하다보니

localhost:3457 에서 -> http://staging.seoulsync82.com 으로요청을 보낼 때,

이렇게 다른 도메인 간에 쿠키가 전송되지 않는 상황이 발생했던 것이다.

문제 해결

이제 다른 도메인 간에 쿠키 전송을 가능하게끔 해줄 것이다.

Cookie 설정

쿠키 설정을 할때 "SameSite"라는 옵션을 "none"으로 해줘야

다른 도메인에서도 쿠키 전달이 가능하다더라.

하지만 "SameSite : none" 옵션을 사용하려면 중요한 포인트가 있다.

바로 "Secure" 옵션이 "True"로 설정되어야 한다는 것이다.

이는 쿠키가 HTTPS 연결을 통해서만 전송되도록 보장해준다.

그래서 결국엔, 나는 사이트를 HTTPS로 바꿔야만 했다ㅎㅎ

AWS에서 제공하는 SSL/TLS 인증서를 받고 인증서를 웹서버에 연결해서 HTTPS로 안전하게 전환을 했다.

SSH 터미널

드디어 !!!

다른 도메인 간에 쿠키 전송을 성공했다.

이로 인해, Silent Refresh API도 제대로 실행되어서 새로운 access_token 발급까지 원활하게 이루어졌다.

이런 변경 덕분에 이제 로컬 환경의 프론트엔드에서도 Staging 서버의 도메인으로

쿠키 전송을 원활하게 할 수 있게 되었다.

개발하는 동안에도 쿠키를 효과적으로 관리하며, 더 나은 테스트 환경을 구축할 수 있게 되었다 !

[해커톤] AWS Rookie Championship 심사위원 참여 후기

대파양파애비 — Mon, 1 Jan 2024 04:58:50 +0900

AWS Rookie Championship

올 한해 운 좋게 AWS 멘토진에 들어가게 되면서 다양한 해커톤 멘토로 참석을 했었다.

열정 넘치는 학생들과의 만남은 정말 영광스러운 경험이였다.

어찌보면 지금 개발중인 프로젝트를 하게 된 계기도 멘토링을 하면서 부족한 부분을 느껴 시작한 것이다.

2023년을 회고하며, 멘토링 활동은 나 자신의 성장에도 크게 기여했다고 생각한다.

너무나 감사하게도 AWS 이사님께서 초대를 해주셔서

지난주 금요일(29일) AWS Rookie Championship 심사위원으로 참석하게 되었다.

2023년 해커톤에서 뛰어난 결과를 낸 학생들을 초대해 발표하고 시상 까지하는 자리였다 !

AWS 본사

AWS Rookie Championship

장소는 AWS 본사라서 센터필드로 갔다.

AWS 본사는 역시나 멋있더라..

귀여운 스티커도 받았다..ㅎㅎ

총 12개 팀이 참여해 기능소개 및 아키텍쳐에 대해 발표를 했다.

수상 팀들의 프로젝트인 만큼 대학생이 구현한거 맞아??? 라는 생각이 들 정도로

수준 높은 기술로 구현된 프로젝트들이 많았다.

당장 비즈니스 모델로 사용해도 손색이 없어 보였다.

그리고 인상 깊었던건 해당 프로젝트가 단순한 발표로 끝나는 것이 아니라,

지속적인 관리와 발전을 통해 더욱 개선되고 성장할 것임을 시사했다.

시상은 AWS 상, Slack 상, Elastic 상, 코드스테이츠 상 등 다양한 상이 주어졌다.

특히 AWS 상으로는 팀원 각자에게 AWS 주식 1주가 수여되었다 !

2023년 한 해 동안 AWS 해커톤 멘토로 활동하면서 많은 것을 배우고 느꼈다.

열정적인 분위기 속에서 함께 문제를 해결해 나가는 과정은 매우 보람찼다.

각 팀이 특색 있는 프로젝트를 발표하는 모습을 보며, 기술의 무한한 가능성을 다시 한번 실감했다.

내년에도 이러한 멘토링 경험을 계속 이어나가며, 더 많은 지식을 나누고, 더 많은 영감을 받고 싶다.

멘토링의 질을 향상시키기 위해, 지속적인 학습과 개인적 성장에 힘 써야겠다

[Javascript] 비동기의 핵심, 이벤트 루프(Event loop) 파헤치기

대파양파애비 — Mon, 25 Dec 2023 22:07:55 +0900

메리 크리스마스

크리스마스인데도 포스팅을 하는 이유는 백엔드파트 리더님과 대화중에 JS 이벤트루프를 설명해보라고 하셨는데

어버버대다가 제대로 설명을 못해서 당황했었다..

리더님은 면접을 보러 들어가면 주니어, 시니어 상관없이 JS 이벤트 루프에 대해서 설명해보라고 질문을 던진다고 하셨다.

그만큼 JS에서 가장 기본적이고 비동기 동작원리를 알려면 무조건 알아야하고 설명을 할 수 있어야 한다.

그래서..! 내일 출근하기전에 제대로 알고 가서 설명을 드리려 포스팅을 해본다.

Event Loop

시작하기에 앞서 간단히 JS에 대해 알아보자.

JavaScript는 싱글 스레드 프로그래밍 언어로서, 한 번에 하나의 작업만 처리할 수 있다.

싱글 스레드인 자바스크립트의 작업을 멀티 스레드로 돌려 작업을 동시에 처리시키게 하던가,

JavaScript가 웹 애플리케이션에서 비동기적인 작업을 수행할 수 있는 이유는 무엇일까 ?

바로 '이벤트 루프(Event Loop)' 이다.

간단히 표현하자면 브라우저의 동작 타이밍을 제어하는 관리자라고 보면 된다.

이 포스팅에서는 JavaScript의 핵심인 이벤트 루프의 원리와 작동 방식을 한번 알아보자.

이벤트 루프의 원리와 구성 요소

Event Loop

사진속 이벤트 루프의 구성 요소를 살펴보자.

- Heap

동적으로 할당된 메모리를 관리하는 영역이다.

객체와 같은 구조체는 이곳에 저장되며, 메모리 관리는 '가비지 컬렉션'에 의해 자동으로 수행된다.

- Call Stack

함수의 호출을 기록하는 자료구조이다.

JavaScript 코드가 실행되면, 함수 호출은 스택에 push 된다.

각 함수가 실행을 마치고 반환될 때, 해당 함수는 스택에서 pop 되어 나간다.

JavaScript는 싱글 스레드 언어이기 때문에, 한 번에 하나의 함수만 처리할 수 있으며 이 처리 과정이 Call Stack에서 일어난다.

- Web APIs

브라우저가 제공하는 비동기적인 기능들을 말한다.

이는 setTimeout, XMLHttpRequest, fetch, DOM 이벤트 등을 포함한다.

JavaScript 엔진이 아니라 브라우저에서 제공되고 실행된다.

이를 통해 JavaScript는 싱글 스레드임에도 불구하고 비블로킹 방식으로 다양한 작업을 동시에 처리할 수 있다.

- Callback Queue

비동기 작업(Web API로부터의 콜백, 사용자 이벤트 등)의 결과를 받는 콜백 함수들이 대기하는 곳이다.

이벤트 루프가 이 큐를 모니터링하며, Call Stack이 비어있을 때 콜백을 Call Stack으로 이동시킨다.

- Event Loop

Call Stack, Web APIs, Callback Queue 간의 작업 흐름을 조정한다.

이 루프는 계속해서 Call Stack을 확인하며, Stack이 비어있고,

콜백이 Callback Queue에 있을 때, 해당 콜백을 Call Stack으로 옮겨 실행하게 됩니다.

싱글 스레드인 JavaScript가 비동기 작업을 수행할 수 있게 해주며, 프로그램이 멈추지 않고 계속해서 실행될 수 있도록 한다.

- Event Table

발생한 이벤트와 그에 해당하는 콜백 함수를 임시로 저장하는 자료구조이다.

예를 들어, addEventListener를 사용하여 이벤트 리스너를 등록하면, 해당 이벤트와 콜백 함수가 Event Table에 등록된다.

이벤트가 발생하면, Event Table은 해당 콜백을 Callback Queue로 이동시킨다.

두 가지의 Callback Queue

Microtask Queue

Callback Queue에는 (Task)Macrotask queue와 (Job)Microtask queue 두 가지 종류가 있다.

두가지 큐는 비슷하지만 다양한 종류의 작업에 적합한 우선 순위와 실행 타이밍을 제공하기 위해서 나눠진것이다.

Callback Queue는 해당 두가지 큐를 묶어 총칭하는 개념이라고 보면 된다.

각각의 큐는 무슨 작업을 처리 하는지 알아보자.

- (Task) Macrotask queue

이벤트 루프가 관리하는 큐 중 하나로, 일련의 macrotask를 포함한다.

Macrotask는 큐에 들어온 순서대로 처리된다.

한 Macrotask의 처리가 완료되면 다음 Macrotask로 넘어간다.

Macrotask 예시: setTimeout, setInterval, setImmediate (Node.js의 경우), I/O 작업, UI 렌더링 요청 등

- (Job) Microtask queue

ES6/ES2015 에서 소개된 Job Queue는 주로 Promise를 사용할 경우 Job Queue를 사용하게 된다.

promise를 사용할 때 callback 함수 역할을 하는 .then 을 사용하게 되며,

이런 thenable한 함수들은 Job Queue에 추가된다.

Macrotask가 처리된 후, 다음 Macrotask로 넘어가기 전에, 이벤트 루프는 Microtask Queue에 있는 모든 작업을 처리한다.

이는 Microtask가 Macrotask 사이에 빠르게 처리되도록 보장한다.

Microtask Queue는 비어있을 때까지 Microtask를 연속적으로 처리한다.

즉, 하나의 Microtask 처리 중에 새로운 Microtask가 생성되면, 그것도 즉시 처리됩니다.

Microtasks 예시: Promise 처리 (then, catch, finally 콜백), MutationObserver, process.nextTick (Node.js의 경우)

이렇게 두개의 큐에 대해서 알아봤는데 요약해보자면

Job의 우선순위가 task의 우선순위보다 높다.

Job의 높은 우선 순위는 빠른 반응성을 필요로 하는 작업을 적시에 처리할 수 있게 도와줍니다.

반면, task는 더 큰 작업 단위를 관리하여, 애플리케이션의 흐름을 조절하고 성능을 최적화합니다.

우선순위와 처리 방식을 이해하는 것은 비동기 프로그래밍 패턴을 효과적으로 설계하고 최적화하는데 중요하다.

예제 코드와 작동 방식

console.log('Start!');

setTimeout(() => {
	console.log('Timeout!');
}, 0);

Promise.resolve('Promise!').then(res => console.log(res));

console.log('End!');

이제 개념을 흝어봤으니 직접 코드를 통한 작동방식을 살펴보자.

1. console.log('Start!')가 Call Stack에 쌓인 후 "start!" 출력

2. setTimeout이 Call Stack에 적재되고 실행되면, 그 안의 콜백 함수가 Web API로 옮겨지고 타이머가 작동한다.

3. 타이머가 종료되면 setTimeout의 콜백 함수는 (Task)MacroTask Queue에 적재된다.

4. Promise 코드가 Call Stack에 적재 되어 실행되고, then 핸들러의 콜백 함수가 (Job)MicroTask Queue에 적재된다.

5. console.log('End!') 코드가 실행되고 콘솔창에 "End!"를 출력된다.

6. 모든 메인 스레드의 자바스크립트 코드가 실행이되어 더이상 Call Stack엔 실행할 스택이 없어 비워지게 된다.

7. 그러면 이벤트 핸들러가 이를 감지하여, Callback Queue에 남아있는 콜백 함수들을 빼와 Call Stack에 적재하게 된다.

8. 이때 2종류의 큐 중 (Job)MicroTask Queue에 남아있는 콜백이 우선적으로 처리된다.

9. (Job)MicroTask Queue가 비어지면, 이제 (Task)MacroTask Queue에 있는 콜백 함수를 Call Stack에 적재시켜 실행한다.

이것이 이벤트 루프다 !

마지막으로 이벤트 루프에 중요한 특징을 알아보자.

- Non-blocking

Event Loop는 I/O 작업이나 타이머 등을 비동기적으로 처리할 수 있게 하여,

메인 스레드가 그 동안 다른 작업을 계속 수행할 수 있도록 합니다.

- Concurrency & Threading

JavaScript는 싱글 스레드 기반이지만, Event Loop와 Callback Queue를 통해 동시성을 가질 수 있다.

이는 JavaScript가 멀티 스레드 언어처럼 작동할 수 있게 하며, 특히 웹 애플리케이션에서 비동기적인 작업 처리에 매우 유용하다.

- Event-Driven Programming

JavaScript는 이벤트 기반 프로그래밍을 지원한다.

사용자 인터랙션, I/O 작업 완료 등의 이벤트에 대응하여 비동기적으로 코드를 실행할 수 있다.

JS 이벤트 루프 시각화

오늘 알아본 이벤트 루프를 직접 코드를 쓰고 조작하여,

애니메이션으로 볼 수 있는 시각화 사이트가 있어 소개해본다.

이것저것 실험해보며 브라우저 내부에서 비동기 동작이 어떠한 순서로 일어나는지 알아보자.

http://latentflip.com/loupe/?code=JC5vbignYnV0dG9uJywgJ2NsaWNrJywgZnVuY3Rpb24gb25DbGljaygpIHsKICAgIHNldFRpbWVvdXQoZnVuY3Rpb24gdGltZXIoKSB7CiAgICAgICAgY29uc29sZS5sb2coJ1lvdSBjbGlja2VkIHRoZSBidXR0b24hJyk7ICAgIAogICAgfSwgMjAwMCk7Cn0pOwoKY29uc29sZS5sb2coIkhpISIpOwoKc2V0VGltZW91dChmdW5jdGlvbiB0aW1lb3V0KCkgewogICAgY29uc29sZS5sb2coIkNsaWNrIHRoZSBidXR0b24hIik7Cn0sIDUwMDApOwoKY29uc29sZS5sb2coIldlbGNvbWUgdG8gbG91cGUuIik7!!!PGJ1dHRvbj5DbGljayBtZSE8L2J1dHRvbj4%3D

latentflip.com

참조:

https://www.youtube.com/watch?v=8aGhZQkoFbQ

https://engineering.linecorp.com/ko/blog/dont-block-the-event-loop

https://medium.com/sjk5766/javascript-%EB%B9%84%EB%8F%99%EA%B8%B0-%ED%95%B5%EC%8B%AC-event-loop-%EC%A0%95%EB%A6%AC-422eb29231a8

https://inpa.tistory.com/entry/%F0%9F%94%84-%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%EC%9D%B4%EB%B2%A4%ED%8A%B8-%EB%A3%A8%ED%94%84-%EA%B5%AC%EC%A1%B0-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC

https://wiki.yowu.dev/ko/dev/Nodejs/event-loop

[SeoulSync82] Mysql DB에 이모지 저장하기 - Nest.JS

대파양파애비 — Wed, 20 Dec 2023 23:21:44 +0900

정말 오랜만에 하는 포스팅이다 !

최근에 프로젝트, 회사업무, 코딩테스트 준비때매 너무 정신없이 바빴다.

프로젝트는 기획이 어느정도 나오고 한달 넘게..? 걸려서 모든 API 개발을 완료했다.

처음에는 간단하게 하려고 했는데 점점 욕심이 생겨서 API도 50개 넘게 생겨버렸다...^^

Git-hub

예비군 동미참 가느라 3일 빼고 전부 달렸네.. 따흑

그래도 내꺼를 만드니깐 확실히 재밌긴하다 !

SeoulSync82 - AI추천

프로젝트에서 "테마" 를 고르는 부분이있는데

각각의 테마에 이모지가 붙어있어서 해당 이모지를 "코스이름"을 만들어줄때 붙혀주기로 했다.

SeoulSync82 - "코스 결과"

이런식으로 코스이름에 이모지를 붙여 줘야 한다.

그래서 API 로직을 짜고 실행을 시켰더니 에러가 나왔다.

Error

엥 이게 뭐지 싶었다.

그래서 ChatGPT 와 구글링을 해봤다.

이모지를 저장하려면 기존의 utf8 문자셋으로는 부족합니다.
이유는 utf8 이 MySQL에서 3바이트까지만 지원하기 때문입니다.
대부분의 이모지는 4바이트를 필요로 하기 때문에, utf8mb4 문자셋으로 전환해야 합니다.
이 문자셋은 모든 유니코드 문자를 지원하며, 이모지도 문제없이 저장할 수 있습니다.

utf8 문자셋이 문제였다!

MySQL과 TypeORM 두가지 설정을 바꿔줘야지 이모지를 저장할 수 있다.

MySQL 문자셋 변경하기

먼저 MySQL을 바꿔보자.

ALTER TABLE your_table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

해당 명령어로 변경이 가능하다.

MySQL

내 DB는 다행히 이미 utf8mb4_unicode_ci 로 되어있었다.

TypeORM 연결 설정

NestJS 프로젝트에서 TypeORM을 사용한다면, 연결 설정에 utf8mb4 문자셋을 명시해야 한다.

app.module.ts 파일에서 데이터베이스 연결 설정을 다음과 같이 수정하면 된다.

TypeOrmModule.forRoot({
  // 다른 설정들...
  charset: 'utf8mb4',
});

나는 해당 연결 설정이 기존에 없었다.

그래서 이모지 저장이 안됬었나보다..!

설정을 하고 저장을 한 후 다시 코드를 실행 시켜 보았다.

MySQL

이제 DB에 이모지가 정상적으로 쌓였다 !

[TypeOrm] loadRelationCountAndMap() - 관계된 데이터의 갯수를 쉽게 세는 방법

대파양파애비 — Sun, 5 Nov 2023 19:53:37 +0900

TypeOrm

회사에 백엔드파트 리더로 전 야놀자 리더분께서 오셨다.

오셔서 코드품질과 성능개선에 대해서 설명해주시는데,

그동안 내가 쓰레기같은 코드들만 빨리 짜고 있었구나 싶었다..

그래서 요새는 기존 코드들을 하나씩 리팩토링에 들어가고있다.

TypeOrm을 좀 효율적으로 잘 쓰자고 강조하셨다.

그래서 오늘은 TypeOrm의 loadRelationCountAndMap() 메서드에 대해서 포스팅을 해보려한다.

우선 기존 코드를 먼저 확인해보자.

기존 Code

comment.service.ts

사진속 코드에 대해서 설명을 하자면 투표 댓글 작성 API 인데,

존재하지 않는 투표거나, 종료된 투표가 내가 참여한 투표가 아니면

댓글을 못달게 에러를 return하는 로직이였다.

vote Repository / voting Repository로 두번 DB Connection이 이뤄지는데

이를 한번만 Connection 하도록 효율적으로 리팩토링을 했다.

이제 loadRelationCountAndMap() 메서드를 사용한 리팩토링한 코드를 보자.

리팩토링한 code

comment.service.ts

vote.query.repository.ts

이런식으로 기존과 다르게 한개의 repository 로만 connection이 이뤄진다.

이게 왜 될까?

loadRelationCountAndMap() 를 사용해서 가상의 속성을 매핑할 수 있다.

이렇게 들으면 무슨소리인지 모를테니 좀 더 알아보자.

loadRelationCountAndMap()

특정 엔티티와 연결된 관계의 수를 쉽게 계산하고, 그 결과를 엔티티의 속성에 매핑해주는 기능을 제공한다.

이를 통해 복잡한 쿼리를 작성하지 않고도 관계의 수를 쉽게 얻을 수 있 다.

vote.entity

voting.entity

loadRelationCountAndMap()를 사용하려면 각각 엔티티에서 속성이 추가되어야한다.

@OneToMany와 @ManyToOne은 TypeORM에서 제공하는 데코레이터로,

엔티티 간의 1:N(N:1) 관계를 정의해준다.

loadRelationCountAndMap() 은 이러한 관계를 바탕으로 하여,

연관된 엔티티의 개수를 세어 그 결과를 특정 엔티티의 속성으로 매핑하는 기능을 한다.

이제 엔티티 준비가 끝났으니 사용법을 살펴보자.

// VoteEntity 내부에 voted 속성을 추가해야 한다.
@Entity()
export class VoteEntity {
  // ... 기타 필드들 ...

  // 가상 속성을 추가
  voted?: number;
}

// Service 또는 Repository 내부
async function findVoteAndVotingCount(voteId: string, userId: string) {
  return await this.repository
    .createQueryBuilder("vote")
    .loadRelationCountAndMap(
      "vote.voted", // 매핑될 속성
      "vote.votings", // 관계 경로
      "voting", // 쿼리 빌더 내에서 사용될 별칭
      (qb) => qb.andWhere("voting.userId = :userId", { userId }) // 조건을 적용하기 위한 콜백 함수
    )
    .getOne();
}

loadRelationCountAndMap()은 세 가지 주요 인자를 받는다.

1. 매핑될 속성의 이름 - 결과가 매핑될 엔티티 내의 속성 이름.

이 이름은 "entityName.propertyName" 형태로 지정돼야 하며,

entityName은 TypeORM 쿼리 빌더에서 사용된 별칭(alias)이다.

vote.entity

이런식은 voteEntity에 새 속성을 추가시켜준다.

2. 관계(relation)의 경로 - 카운트될 관계의 경로. "entity.relation" 형태로 작성된다.

vote.entity

아까 @OnetoMany에 votings 라고 이름을 정해주었다.

3. 조건을 추가할 수 있는 콜백 함수 (선택적) (QueryBuilder를 인자로 받는 함수)

- 필요한 경우 특정 조건을 적용하기 위해 사용된다.

세 가지 주요 인자에 대해서 알아봤으니 그 다음 qb.andWhere 를 보자.

andWhere 메소드를 사용해서 voting.userId가 파라미터로 받아온 userId와 일치하는 조건을 쿼리에 추가한다.

즉, 특정 사용자가 투표한 것만 세겠다는 의미다.

이제 loadRelationCountAndMap()의 장점을 살펴보자.

- 성능 향상

별도의 카운트 쿼리를 실행하지 않고도 관련 데이터의 수를 가져올 수 있어서

데이터베이스에 대한 요청 횟수가 줄어들고, 결과적으로 애플리케이션의 성능이 향상된다.

- 코드 간결성

관계 수를 셀 때 필요한 추가적인 쿼리 작성 없이 명확한 API를 통해

직관적으로 카운트를 할 수 있어서 코드가 훨씬 간결해진다.

- 유연성

loadRelationCountAndMap는 콜백 함수를 통해 특정 조건에 맞는 카운트만을 셀 수 있도록 해서,

동적인 쿼리 생성이 가능해진다.

다음으로 loadRelationCountAndMap()의 주의할 점을 살펴보자.

- 복잡한 쿼리 성능 저하

만약에 매우 복잡한 조건이나 많은 양의 조인이 필요한 경우, loadRelationCountAndMap 메소드는 성능이 저하될 수 있다.

이럴 땐 성능을 위해 별도의 최적화된 쿼리를 작성하는 것이 좋을 수 있다.

- 인덱싱과 최적화

loadRelationCountAndMap를 사용할 때는 관련 테이블에 적절한 인덱스가 설정되어 있는지 확인해야 한다.

그렇지 않으면 카운트를 계산할 때 성능 문제가 발생할 수 있다.

- 오버페칭 문제

단일 쿼리로 많은 데이터와 그 관계를 가져올 경우, 실제로 필요하지 않은 데이터까지 가져오는 오버페칭 문제가 발생할 수 있다.

따라서 어떤 데이터가 실제로 필요한지 잘 파악하고 쿼리를 작성해야 한다.

- 엔티티 설계

loadRelationCountAndMap를 사용하기 위해서는 엔티티 간의 관계가 올바르게 매핑되어 있어야 한다.

때때로 이런 관계 설정이 복잡할 수 있는데, 이때 잘못 설계되면 예상치 못한 결과가 나올 수 있다.

이렇게 loadRelationCountAndMap() 메서드에 대해서 자세히 알아보았다.

앞으로도 엔티티 관계가 잡혀있고 여러 Connection을 해야할 경우엔

loadRelationCountAndMap() 를 사용하여 효율성 높은 코드를 짜야겠다 !

[Nest.JS] 구글, 네이버, 카카오 소셜로그인 구현 - 2

대파양파애비 — Sat, 4 Nov 2023 07:21:19 +0900

Nest.JS

소셜로그인 1편에 이어서 바로 2편을 포스팅하려 했는데

refresh_token과 JWT 전략에 대해서 이것저것 머리싸매면서 고민하느라 늦어졌다..

정말 다양한 JWT 전략과 고민할 사항이 많았다.

한 계정으로 여러 디바이스에서 로그인을 할 수도 있고,

access_Token 만료시 refresh-API 실행 타이밍을 백엔드에서 만료를 체크해서 할 지,

아니면 프론트엔드에서 access_Token "exp"로 만료 체크해서 API 요청할지 등등...

바로 본론으로 들어가기전에 소설로그인 1편을 꼭 보고오시길 !

https://ilikezzi.tistory.com/64

[Nest.JS] 구글, 네이버, 카카오 소셜로그인 구현 - 1

진행중인 사이드 프로젝트에서 기획이 끝나서 화면기획서가 나오고, 디자인쪽도 피그마로 UI/UX 디자인을 시작하고, 개발쪽도 DB ERD 설계, 서버설계, Stg서버 등등.. 기본적인 개발하기 위한 준비

ilikezzi.tistory.com

refresh_token

소셜로그인 1편을 보고왔으면 알겠지만, 나는 refresh_token을 쓰기로 했다.

그럼 refresh_token은 뭐고 왜 쓰는것일까?

refresh_token은 단어 뜻 그대로 새로고침 토큰이라고 보면 좋을 것 같다.

access_token은 보호된 자원에 액세스 하는데 필요한 인증 수단이지만, 해당 토큰을 가지고 있는 사람이라면 누구든지 해당 자원에 접근할 수 있게 된다.

이러한 특성 때문에 악의적인 사용자가 시스템을 침해하고 access_token을 훔쳐서 접근을 하지 못하도록 막기 위한 적절한 조치가 필요한 것이다.

다양한 적절한 조치가 있지만 그 중 하나인 access_token의 만료시간을 짧게 설정하는 것이다.

이렇게 하면 기존의 access_token이 탈취 당하더라도 새로운 access_token만이 자원에 액세스할 수 있게된다.

하지만 단점도 존재한다.

만료시간을 짧게 설정하면 보안적 측면에서는 좋겠지만,

"유저 경험" 즉 ,UX 측면에선 굉장히 불편할 것이다.

이 단점을 개선하기 위해 등장한 것이 바로 "refresh_token"이다.

JWT 전략

JWT 전략을 사용하면 서버가 세션 상태를 유지할 필요가 없기 때문에 확장성 있는 어플리케이션을 만드는 데 좋고,

여러 시스템 간에 토큰을 전달하기 용이하다는 점을 강조할 수 있다.

하지만, 앞서 얘기한대로 한 번 발급된 토큰은 그 자체로 인증 수단이 되기 때문에, 보안에 더 신경을 써야 하고,

토큰이 탈취되면 악용될 수 있다는 점도 주의해야 한다.

이러한 refresh_token을 가지고 JWT전략을 어떻게 짰는지 살펴보자.

1. 유저가 첫 로그인시 access_token, refresh_token 발급해 줄 것이다.

2. access_token은 클라이언트에서 저장을 하고 refresh_token은 DB에 쌓는다.

3. 각각의 토큰 만료는 access_token: 1시간 , refresh_token: 14일로 정했다.

4. refresh_token은 쿠키에 저장을 하고 만료기간은 동일하게 14일로 정했다.

5. Access token의 payload안에 “exp”정보도 담아서 이 값으로 프론트에서 만료체크를 하고,

만료되었으면 refresh-API로 access_token을 재발급해준다.

6. refresh-API 실행시 refresh_token도 만료되었으면 재로그인을 하게끔 한다.

7. refresh-API실행시 refresh_token이 다르면 재로그인을 하게끔 한다. (여러 디바이스 동시로그인 방지)

8. 로그아웃 API는 DB와 쿠키의 있는 refresh_token을 지워버린다.

여기까지가 내가 세운 JWT 전략이다.

Code

이제 바로 코드로 확인해보자.

// auth.controller.ts

@Get('/user/login/google')
  @ApiOperation({
    summary: '구글 로그인',
    description: '구글 로그인',
  })
  @UseGuards(AuthGuard('google'))
  async googleAuth(@Req() _req: Request) {}

  /* Get Google Auth Callback */
  @Get('/auth/google/callback')
  @UseGuards(AuthGuard('google'))
  async googleAuthCallback(
    @Req() req: GoogleRequest,
    @Res() res: Response, // : Promise<GoogleLoginAuthOutputDto>
  ) {
    const result = await this.authService.googleLogin(req, res);
    return res.json(result);
  }

// auth.service.ts

async googleLogin(
    req: GoogleRequest,
    res: Response,
  ) {
    try {
      req.user.nickname = req.user.firstName + req.user.lastName;
      const { user } = req;
      delete user.lastName;
      delete user.firstName;
      user.type = 'google';

      // 유저 중복 검사
      let findUser = await this.userQueryRepository.findUser(user);

      // 없는 유저면 DB에 유저정보 저장
      if (!findUser) {
        const uuid = generateUUID();
        findUser = await this.userQueryRepository.createUser(user, uuid);
      }

      // 구글 가입이 되어 있는 경우 accessToken 및 refreshToken 발급
      const findUserPayload = {
        id: findUser.id,
        uuid: findUser.uuid,
        nickname: findUser.name,
        profile_image: findUser.profile_image,
      };
      const eid_access_token = jwt.sign(findUserPayload, this.configService.get('JWT_SECRET'), {
        expiresIn: this.configService.get('JWT_ACCESS_TOKEN_EXPIRATION_TIME'),
      });
      const eid_refresh_token = jwt.sign({}, this.configService.get('JWT_REFRESH_KEY'), {
        expiresIn: this.configService.get('JWT_REFRESH_TOKEN_EXPIRATION_TIME'),
        audience: String(findUser.id),
      });

      /* refreshToken 필드 업데이트 */
      findUser.eid_refresh_token = eid_refresh_token;
      await this.userQueryRepository.save(findUser);

      // 쿠키 설정
      const now = new Date();
      now.setDate(
        now.getDate() +
          parseInt(this.configService.get('JWT_REFRESH_TOKEN_EXPIRATION_DATE')) / 1000,
      );
      console.log(this.configService.get('JWT_REFRESH_TOKEN_EXPIRATION_DATE'));
      res.cookie('eid_refresh_token', eid_refresh_token, {
        expires: now,
        httpOnly: true,
        secure: process.env.NODE_ENV === 'production' ? true : false,
        sameSite: process.env.NODE_ENV === 'production' ? 'none' : 'lax',
      });
      return {
        ok: true,
        eid_access_token,
      };
    } catch (error) {
      return { ok: false, error: '구글 로그인 인증을 실패 하였습니다.' };
    }
  }

소셜로그인 1편 포스팅에서 DB에 유저정보 쌓는거 까지 다뤘으니 그 다음부터 보자.

auth.service.ts

findUserPayload에는 access_token에 담을 정보들을 넣어준다.

refresh_token에는 굳이 findUserPayload 이 정보를 다 담을 필요가 없어서

audience만 지정해줬다.

이렇게 설정하면 나중에 백엔드에서 이 audience값을 검증해서,

요청을 보낸 사용자의 ID와 일치하는지를 확인해 해당 토큰이 맞는 사용자에게 발급된 건지 확인할 수 있다.

.env.debug

만료기간은 env파일에서 access_token 1시간, refresh_token 14일로 지정해준다.

auth.service.ts

쿠키설정의 만료기간도 refresh_token에서 사용하던 14일을 동일하게 넣어준다.

httpOnly: 이 옵션을 true로 설정하면, 쿠키에 자바스크립트로 접근할 수 없다.

XSS 공격을 방지하기 위한 중요한 설정이다.

secure: 이 속성이 true일 때, 쿠키는 HTTPS 프로토콜을 통해서만 전송된다.

개발 환경에서는 굳이 HTTPS가 아니어도 되니까,

process.env.NODE_ENV === 'production' 조건을 통해 프로덕션 환경에서만 true로 설정되게 해놨다.

sameSite: 이 옵션은 CSRF 공격을 방지하는 데 도움을 준다.

이렇게해서 로그인 할 때는 끝이다.

이제 로그인 연장하는 refresh API를 살펴보자.

  // auth.controller.ts
  
  @Post('/user/refresh')
  @ApiOperation({
    summary: '로그인 연장',
    description: '로그인 연장',
  })
  async silentRefresh(@Req() req: Request, @Res({ passthrough: true }) res: Response) {
    return await this.authService.silentRefresh(req, res);
  }

// auth.service.ts

async silentRefresh(req: Request, res: Response): Promise<SilentRefreshAuthOutputDto> {
    try {
      // refreshToken 유효성 검사
      const getRefreshToken = req.cookies['eid_refresh_token'];
      if (isEmpty(getRefreshToken)) {
        return { ok: false };
      }
      let userId: string | string[] | null;
      jwt.verify(
        getRefreshToken,
        this.configService.get('JWT_REFRESH_KEY'),
        (err: jwt.VerifyErrors | null, decoded: jwt.JwtPayload | undefined) => {
          if (err) {
            res.clearCookie('eid_refresh_token');
            return { ok: false, error: '토큰이 유효하지 않습니다. 로그인이 필요합니다' };
          }
          userId = decoded.aud;
        },
      );

      // 로그아웃 후에는 Silent Refresh를 무시
      const loginUser = await this.userQueryRepository.findId(+userId);
      if (loginUser.eid_refresh_token !== getRefreshToken) {
        return { ok: false, error: '토큰이 유효하지 않습니다. 로그인이 필요합니다' };
      }

      // accessToken 재발급
      const payload = {
        id: loginUser.id,
        uuid: loginUser.uuid,
        nickname: loginUser.name,
        profile_image: loginUser.profile_image,
      };
      const eid_access_token = jwt.sign(payload, this.configService.get('JWT_SECRET'), {
        expiresIn: this.configService.get('JWT_ACCESS_TOKEN_EXPIRATION_TIME'),
      });

      return {
        ok: true,
        eid_access_token,
      };
    } catch (error) {
      console.log(error);
      return { ok: false, error: '로그인 연장에 실패하였습니다.' };
    }
  }

이제 하나씩 무슨코드인지 살펴보자.

auth.service.ts

해당 API는 Req로 쿠키값만 사용된다.

아까 refresh_token 발급할 때 audience 를 넣은 이유가 이제 나온다.

JWT의 유효성을 검증을 하고 이상이 없으면 userId에 audience를 담아준다.

auth.service.ts

userId로 DB에서 유저정보를 찾고 쿠키의 refresh_token이랑 DB의 refresh_token이랑 비교를한다.

값이 다를 경우엔 다른 디바이스로 로그인 한 것이므로 로그인이 필요하다고 return 시켜준다.

access_token 재발급을 해줄때는 기존과 동일하게 payload와 만료시간을 설정하고

새 토큰을 return 해준다.

이렇게 refresh API는 끝이다.

이제 마지막으로 로그아웃 API를 살펴보자.

// auth.controller.ts

@UseGuards(JwtAuthGuard)
  @ApiBearerAuth('access-token')
  @Post('user/logout')
  @ApiOperation({
    summary: '로그아웃',
    description: '로그아웃',
  })
  async logout(
    @Res({ passthrough: true }) res: Response,
    @CurrentUser() user,
  ): Promise<LogoutAuthOutputDto> {
    return await this.authService.logout(user, res);
  }

// auth.service.ts

async logout(user, res): Promise<LogoutAuthOutputDto> {
    try {
      if (isEmpty(user.id)) return { ok: false, error: '접근 권한을 가지고 있지 않습니다' };

      const loginUser = await this.userQueryRepository.findId(user.id);
      loginUser.eid_refresh_token = null;
      await this.userQueryRepository.save(loginUser);
      res.clearCookie('refreshToken');
      return { ok: true };
    } catch (error) {
      console.log(error);
      return { ok: false, error: '로그아웃을 실패하였습니다' };
    }
  }

auth.service.ts

로그아웃 API는 @UseGuards(JwtAuthGuard)로 토큰이 필요하다.

정상적인 access_token 인지 체크하고

해당 유저DB의 refresh_token과 쿠키의 refresh_token을 초기화 시켜주면 끝이다.

결과 확인

이제 전부 끝났으니 정상 작동하는지 결과를 확인해보자.

1. 로그인

On-boarding 페이지

google-login

클라이언트

user DB

로그인시 클라이언트엔 access_token, DB엔 refresh_token이 정상적으로 쌓였다.

2. refresh-API

access_token 재발급

만료된 refresh_token

첫번째는 정상적으로 access_token이 정상적으로 재발급 된것이고,

두번째는 만료된 refresh_token을 넣었을 때 case인데 "로그인이 필요합니다" 제대로 출력된다.

3. 로그아웃 API

Swagger

user DB

로그아웃 API를 실행하면 정상적으로 refresh_token이 초기화된 것을 확인할 수 있다.

드디어 소셜 로그인을 전부 완료했다 ㅠㅠ

처음으로 제대로 JWT를 해보는거라 초반에 이해하는데 꽤나 머리를 쥐어뜯었는데

막상 이해를하고 코드를 보니 어려운건 없더라.

포스팅도 하면서 한번 더 정리를 하느라 완벽히 이해를 했다.

얼른 프로젝트를 끝내고 깃헙에 오픈소스로 올려야지...!

[Nest.JS] 구글, 네이버, 카카오 소셜로그인 구현 - 1

대파양파애비 — Mon, 16 Oct 2023 03:01:04 +0900

Nest.JS

진행중인 사이드 프로젝트에서 기획이 끝나서 화면기획서가 나오고,

디자인쪽도 피그마로 UI/UX 디자인을 시작하고,

개발쪽도 DB ERD 설계, 서버설계, Stg서버 등등.. 기본적인 개발하기 위한 준비를 마치고

온보딩, 메인페이지 부터 드디어 Api 작업에 들어갔다.

막상 개발은 큰 어려움이 없을텐데, 역시나 처음해보는 기획이나 DB/서버 설계에서

시간이 많이 걸리고, 제대로 처음 해보는거라서 어렵더라..

On-boarding 페이지

따로 Local 이메일 로그인은 제외하고 구글 / 카카오 / 네이버 로그인 세가지를 넣기로 했다.

NestJS에서 소셜 로그인을 붙히기 위해서는 순서에 대한 이해가 필요하다.

하나씩 차근차근 살펴보자.

소셜 로그인 순서

NestJS 소셜로그인 순서

내가 이해한 순서를 이해하기 쉽게 그림으로 만들어 보았다. (디자인 감각 Zero ㅠ)

1. 페이지 요청: 사용자가 소셜 로그인 페이지에 접속한다.

2. 페이지 응답: 소셜 로그인 HTML 페이지를 웹/앱 브라우저에 반환한다.

3. 구글 로그인 요청: 사용자가 구글 로그인 버튼을 클릭하면 http://localhost:3456/user/login/google 주소로 GET 요청을 보낸다.

4. 구글 -> 웹/앱 브라우저: 구글 로그인 페이지에서 사용자가 인증을 하면, 구글은 시크릿코드를 반환한다.

5. controller -> 구글: 시크릿코드를 이용해서 구글에 access_token과 refresh_token을 요청한다.

6. 구글 -> controller: 구글은 JWT와 user profile을 반환한다.

7. controller -> service: JWT와 user profile을 반환한다.

8. service -> repository: 이미 가입된 유저인지 체크하고, 미가입 유저면 DB에 쌓는다.

9. repository -> service: 새로 만든 유저정보 or 기존 유저정보 데이터를 반환한다.

10. service: 넘겨받은 유저정보로 JWT access_token과 refresh_token을 생성한다.

11. service -> repository: refresh_token을 user DB에 쌓는다.

12. service -> controller : JWT access_token과 refresh_token을 반환한다.

13. controller -> 웹/앱 브라우저: JWT access_token과 refresh_token을 반환한다.

이후 토큰만료 체크해서 refresh_token으로 토큰만료 체크해서 새로운 access_token 발급받는데

해당 내용은 다음 포스팅에서 진행할 예정이다.

위 흐름을 제대로 이해하는데 좀 헤맸지만, 이것만 이해하면 끝이나 다름없다.

Google, Naver, Kakao - secret key 발급

이제 각각의 사이트에서 시크릿 키를 발급 받아야한다.

이때 유저의 정보를 추가로 받아올지 정할 수 있는데

나는 이메일, 프사, 닉네임 세가지를 공통으로 추가했다.

https://console.developers.google.com/apis

Google 클라우드 플랫폼

로그인 Google 클라우드 플랫폼으로 이동

accounts.google.com

https://developers.naver.com/main/

NAVER Developers

네이버 오픈 API들을 활용해 개발자들이 다양한 애플리케이션을 개발할 수 있도록 API 가이드와 SDK를 제공합니다. 제공중인 오픈 API에는 네이버 로그인, 검색, 단축URL, 캡차를 비롯 기계번역, 음

developers.naver.com

https://developers.kakao.com/

Kakao Developers

카카오 API를 활용하여 다양한 어플리케이션을 개발해보세요. 카카오 로그인, 메시지 보내기, 친구 API, 인공지능 API 등을 제공합니다.

developers.kakao.com

승인된 자바스크립트 원본 : http://localhost:3456

승인된 리디렉션 URI : http://localhost:3456/auth/google/callback

나는 이런식으로 콜백 url을 구성 했는데 각자 알아서 url을 추가해 주면된다.

각각의 사이트에서 Client ID 와 Client Secret 를 생성을 한 후

.env 파일에 다음과 같이 넣어준다.

.env.debug

이제 준비는 끝났으니 로직을 짜러 가보자.

Code

// JWT, passport 라이브러리 설치
npm install @nestjs/jwt
npm install @nestjs/passport;  

// 각각 스트래티지를 지원하는 의존성 패키지 설치
npm install passport-google-oauth20
npm install passport-kakao 
npm install passport-naver

// ts 버전 추가 설치
npm install --dev @types/passport-google-oauth20
npm install --dev @types/passport-kakao 
npm install --dev @types/passport-naver

해당 라이브러리를 모두 설치해준다.

yarn을 쓰면 yarn add 로 설치해주면 된다.

이제 각각의 strategy 파일 코드를 보자.

// jwt-social-google.strategy.ts

import { Injectable } from '@nestjs/common';
import { PassportStrategy } from '@nestjs/passport';
import { Profile, Strategy, VerifyCallback } from 'passport-google-oauth20';
import { ConfigService } from 'src/config/config.service';

@Injectable()
export class JwtGoogleStrategy extends PassportStrategy(Strategy, 'google') {
  //UseGuards의 이름과 동일해야함
  constructor(private readonly configService: ConfigService) {
    // console.log(configService)
    super({
      //자식의 constructor를 부모의 constructor에 넘기는 방법은 super를 사용하면 된다.
      clientID: configService.get('GOOGLE_ID'), //.env파일에 들어있음
      clientSecret: configService.get('GOOGLE_SECRET'), //.env파일에 들어있음
      callbackURL: 'http://localhost:3456/auth/google/callback', //.env파일에 들어있음
      scope: ['email', 'profile'],
    });
  }

  authorizationParams(): { [key: string]: string } {
    return {
      access_type: 'offline',
      prompt: 'consent',
    };
  }

  async validate(
    accessToken: string,
    refreshToken: string,
    profile: Profile,
    done: VerifyCallback,
  ) {
    console.log('success');
    console.log(accessToken);
    console.log(refreshToken);
    try {
      const { name, emails, photos } = profile;
      const user = {
        email: emails[0].value,
        firstName: name.familyName,
        lastName: name.givenName,
        photo: photos[0].value,
      };
      done(null, user);
    } catch (error) {
      done(error);
    }
  }
}

// jwt-social-kakao.strategy.ts

import { ConsoleLogger, Injectable } from '@nestjs/common';
import { PassportStrategy } from '@nestjs/passport';
import { Profile, Strategy } from 'passport-kakao';
import { ConfigService } from 'src/config/config.service';

@Injectable()
export class JwtKakaoStrategy extends PassportStrategy(Strategy, 'kakao') {
  constructor(private readonly configService: ConfigService) {
    super({
      clientID: configService.get('KAKAO_ID'), //.env파일에 들어있음
      clientSecret: configService.get('KAKAO_SECRET'), //.env파일에 들어있음
      callbackURL: 'http://localhost:3456/auth/kakao/callback', //.env파일에 들어있음
      // scope: ["account_email", "profile_nickname"],
    });
  }

  async validate(
    accessToken: string,
    refreshToken: string,
    profile: Profile,
    done: (error: any, user?: any, info?: any) => void,
  ) {
    try {
      console.log(profile);
      const { _json } = profile;
      const user = {
        email: _json.kakao_account.email,
        nickname: _json.properties.nickname,
        photo: _json.properties.profile_image,
      };
      done(null, user);
    } catch (error) {
      done(error);
    }
  }
}

// jwt-social-naver.strategy.ts

import { Injectable } from '@nestjs/common';
import { PassportStrategy } from '@nestjs/passport';
import { Profile, Strategy } from 'passport-naver';
import { ConfigService } from 'src/config/config.service';

@Injectable()
export class JwtNaverStrategy extends PassportStrategy(Strategy, 'naver') {
  constructor(private readonly configService: ConfigService) {
    super({
      clientID: configService.get('NAVER_ID'), //.env파일에 들어있음
      clientSecret: configService.get('NAVER_SECRET'), //.env파일에 들어있음
      callbackURL: 'http://localhost:3456/auth/naver/callback', //.env파일에 들어있음
    });
  }

  async validate(
    accessToken: string,
    refreshToken: string,
    profile: Profile,
    done: (error: any, user?: any, info?: any) => void,
  ) {
    try {
      console.log(profile);
      const { _json } = profile;
      const user = {
        email: _json.email,
        nickname: _json.nickname,
        photo: _json.profile_image,
      };
      done(null, user);
    } catch (error) {
      done(error);
    }
  }
}

이렇게 구글, 카카오, 네이버 strategy 파일을 추가해 주자.

나는 ConfigModule 로컬 라이브러리를 사용하는데

외부 라이브러리를 사용하게 될 경우 import 경로를 맞게 바꿔주면 된다.

그리고 각각에 strategy 파일마다 validate() 부분이 다른게 보일텐데

이는 구글, 카카오, 네이버에서 넘겨주는 데이터 폼이 약간씩 달라서 그렇다.

// auth.controller.ts

//-----------------------구글 로그인-----------------------------//

  @Get('/user/login/google')
  @UseGuards(GoogleAuthGuard)
  async googleAuth(@Req() _req: Request) {
  }

  /* Get Google Auth Callback */
  @Get('/auth/google/callback')
  @UseGuards(AuthGuard('google'))
  async googleAuthCallback(
    @Req() req: GoogleRequest,
    @Res() res: Response, // : Promise<GoogleLoginAuthOutputDto>
  ) {
    // return res.send(user);
    return this.authService.googleLogin(req, res);
  }

  //-----------------------카카오 로그인-----------------------------//

  @Get('/user/login/kakao')
  @UseGuards(AuthGuard('kakao'))
  async kakaoAuth(@Req() _req: Request) {
  }

  /* Get kakao Auth Callback */
  @Get('/auth/kakao/callback')
  @UseGuards(AuthGuard('kakao'))
  async kakaoAuthCallback(
    @Req() req: KakaoRequest,
    // @Res({ passthrough: true }) res: Response,
    @Res() res: Response, // : Promise<KakaoLoginAuthOutputDto>
  ) {
    const { user } = req;
    console.log(user);
    return res.send(user);
    // return this.authService.kakaoLogin(req, res);
  }

  //-----------------------네이버 로그인-----------------------------//

  @Get('/user/login/naver')
  @UseGuards(AuthGuard('naver'))
  async naverAuth(@Req() _req: Request) {
  }

  /* Get naver Auth Callback */
  @Get('/auth/naver/callback')
  @UseGuards(AuthGuard('naver'))
  async naverAuthCallback(
    @Req() req: NaverRequest,
    @Res() res: Response, // : Promise<NaverLoginAuthOutputDto>
  ) {
    const { user } = req;
    console.log(user);
    return res.send(user);
    // return this.authService.naverLogin(req, res);
  }
}

구글 이랑 카카오,네이버랑 return 값이 다를텐데

카카오, 네이버는 테스트를 위해서 return 값을 임시로 이렇게 해둔것이라 테스트가 끝나면 구글처럼 해주면 된다.

return res.send(user) 로 구성하면 service부 없이도

http://localhost:3456/user/login/naver -> 네이버 로그인하면

콜백 url로 위 사진처럼 내가 정해놓은 유저 데이터가 출력될 것이다.

여기서 혹시나 안되면 env파일, config 설정, Auth module, 네이버 개발자센터 콜백 url

해당 4가지 항목을 잘 체크해보면 아마 해결될 것이다.

(4가지 체크하라는건 슬프게도 경험담... 따흑)

이제 여기까지 잘 따라왔다면 DB에 데이터를 쌓아보자.

// auth.service.ts

async googleLogin(
    req: GoogleRequest,
    res: Response,
    // googleLoginAuthInputDto, // : Promise<GoogleLoginAuthOutputDto>
  ) {
    try {
      req.user.nickname = req.user.firstName + req.user.lastName;
      const { user } = req;
      delete user.lastName;
      delete user.firstName;
      user.type = 'google';

      // 유저 중복 검사
      let findUser = await this.userQueryRepository.findUser(user);

      // 없는 유저면 DB에 유저정보 저장
      if (!findUser) {
        const uuid = generateUUID();
        findUser = await this.userQueryRepository.createUser(user, uuid);
      }
      console.log(findUser);

      // 구글 가입이 되어 있는 경우 accessToken 및 refreshToken 발급
      const findUserPayload = { id: findUser.id };
      const eid_access_token = jwt.sign(
        findUserPayload,
        this.configService.get('JWT_ACCESS_TOKEN_SECRET_KEY'),
        {
          expiresIn: this.configService.get('JWT_ACCESS_TOKEN_EXPIRATION_TIME'),
        },
      );
      const eid_refresh_token = jwt.sign(
        {},
        this.configService.get('JWT_REFRESH_TOKEN_SECRET_KEY'),
        {
          expiresIn: this.configService.get('JWT_REFRESH_TOKEN_EXPIRATION_TIME'),
          audience: String(findUser.id),
        },
      );

      /* refreshToken 필드 업데이트 */
      findUser.eid_refresh_token = eid_refresh_token;
      await this.userQueryRepository.save(findUser);

      // 쿠키 설정
      const now = new Date();
      now.setDate(now.getDate() + +this.configService.get('JWT_REFRESH_TOKEN_EXPIRATION_DATE'));
      res.cookie('eid_refresh_token', eid_refresh_token, {
        expires: now,
        httpOnly: true,
        secure: process.env.NODE_ENV === 'production' ? true : false,
        sameSite: process.env.NODE_ENV === 'production' ? 'none' : 'lax',
      });
      return {
        ok: true,
        eid_access_token,
      };
    } catch (error) {
      return { ok: false, error: '구글 로그인 인증을 실패 하였습니다.' };
    }
  }

토큰 전까지만 우선 보자.

토큰, 쿠키는 다음 포스팅에서 다룰것이다.

구글은 lastname, firstname을 따로 넘겨줘서 네이버, 카카오처럼 "닉네임"으로 합쳐주었다.

Repository에서 이미 있는 유저인지 체크를 하고,

가입된 유저가 아니면 유저DB를 쌓아준다.

나는 uuid 베이스로 DB를 설계해놔서 uuid도 추가해 주었다.

// user.query.repository.ts

async findUser(user): Promise<UserEntity> {
    return await this.repository.findOne({
      where: { email: user.email, name: user.nickname, type: user.type },
    });
  }

  async createUser(user, uuid): Promise<UserEntity> {
    return await this.repository.save({
      uuid: uuid,
      email: user.email,
      name: user.nickname,
      profile_image: user.photo,
      type: user.type,
    });
  }

  async save(UserEntity): Promise<UserEntity> {
    return await this.repository.save(UserEntity);
  }

user repository에는 별거없다.

아까 auth.service에서 넘긴 데이터 처리만 이뤄진다.

중복 유저는 email, name, type 세가지로 비교한다.

이제 기본적인 코드는 끝이다.

코드를 실행시키고 http://localhost:3456/user/login/google 에 접속하자.

http://localhost:3456/user/login/google

여기서 계정을 누르면 콜백url로 넘어가면서 auth 코드로 넘어갈 것이다.

첫 로그인이니 제대로 DB에 쌓였나 확인을 해보자.

user table

아주 잘 쌓였다 ㅎㅎ

이제 네이버, 카카오도 동일한 방법으로 진행을 해주면 된다.

access_token과 fresh_token에 대해서

[Nest.JS] 구글, 네이버, 카카오 소셜로그인 구현 - 2편 에서 포스팅 할 예정이다.

[Javascript] 클로저_코어 자바스크립트

대파양파애비 — Fri, 29 Sep 2023 05:03:28 +0900

코어 자바스크립트

오늘은 5단원인 "클로저" 를 포스팅 할 것이다.

클로저(closure)는 자바스크립트에서 중요한 개념 중 하나지만,

사실 이번에 처음 제대로 파본다...

실행 컨텍스트에 대한 사전지식이 없으면 분명 이해가 안 갈 것이다.

마침 2단원에서 실행컨텍스트를 다뤘으니 꼭! 꼭! 보고 오길 권장한다.

https://ilikezzi.tistory.com/55

[Javascript] 실행 컨텍스트_코어 자바스크립트

저번에 포스팅한 "데이터 타입" 에 이어서 다음 챕터인 "실행 컨텍스트"를 포스팅 할 것이다. https://ilikezzi.tistory.com/52 [Javascript] 데이터 타입_코어 자바스크립트 계획했던대로 자격증 취득도 다

ilikezzi.tistory.com

05. 클로저

클로저의 의미 및 원리 이해

클로저는 여러 함수형 프로그래밍 언어에서 등장하는 보편적인 특성이다.

클로저의 설명은 다양한 문헌에서 제각각 다르게 정의 또는 설명하고 있지만,

처음 문장을 접하면 이해하기 어려울 수 있다.

클로저는 내부 함수가 외부 함수의 변수에 접근할 수 있게 해주는 자바스크립트의 특별한 기능

다양한 설명 중에 이 설명이 그나마 처음 접했을 때 제일 와닿았다.

MDN(Mozilla Developer Network)에서는 클로저에 대해 이렇게 설명했다.

A Closure is the combination of a function and the lexical environment within which that function was declared.

직역해보면 다음과 같다.

"클로저는 함수와 그 함수가 선언될 당시의 lexical environment의 상호관계에 따른 현상"

여기서 lexical environment는 실행 컨텍스트의 구성요소 중 하나인 outerEnvironmentReference에 해당한다.

그리고 상호관계란 내부 함수에서 외부 변수를 참조하는 때에만 만을 뜻한다.

지금까지 파악한 내용에 따르면 클로저란

"어떤 함수에서 선언한 변수를 참조하는 내부함수에서만 발생하는 현상" 이라고 볼 수 있겠다.

이제 외부함수의 변수를 참조하는 내부함수 예제 코드를 보자.

var outer = function(){
  var a = 1;
  var inner = function(){
    return ++a;
  };
  return inner();
};
var outer2 = outer();

console.log(outer2);     // 2

6번째 라인을 보면 함수를 실행한 결과를 return 하고있으므로,

outer함수의 실행 컨텐스트가 종료된 시점에는 a 변수를 참조하는 대상이 없어진다.

a, inner변수 값들은 가비지 컬렉터에 의해 소멸될 것이다.

이제 outer의 실행 컨텍스트가 종료된 후에도 inner 함수를 호출하는 예제 코드를 보자.

var outer = function(){
  var a = 1;
  var inner = function(){
    return ++a;
  };
  return inner;
};
var outer2 = outer();

console.log(outer2());    // 2
console.log(outer2());    // 3

이번에는 6번째 라인에서 함수의 실행결과가 아닌 inner 함수 자체를 return 했다.

그러면 outer 함수의 실행 컨텍스트가 종료될 때,

outer2 변수는 outer의 실행 결과인 inner 함수를 참조하게 될 것이다.

여기서 의문이 들 것이다.

inner 함수의 실행 시점에는 outer 함수는 이미 실행이 종료된 상태인데,

outer함수의 LexicalEnvironment에 어떻게 접근하는 걸까?

정답은 가비지 컬렉터의 동작 방식 때문이다.

가비지 컬렉터는 어떤값을 참조하는 변수가 하나라도 있다면 그 값은 수집 대상에 포함시키지 않는다.

그 덕에 inner 함수가 이 변수에 접근할 수 있었던 것이다.

이제 다시 클로저의 정의에 대해서 살펴보면

"클로저란 어떤 함수 A에서 선언한 변수 a를 참조하는 내부함수 B를 외부로 전달 할 경우 A의 실행 컨텍스트가 종료된 이후에도 변수 a가 사라지지 않는 현상"

이라고 정의할 수 있을 것이다.

메모리 관리

클로저를 사용할 때 주의해야할 점이 있다.

클로저는 메모리를 차지하기 때문에 과도하게 사용하면 성능 문제가 생길 수 있다.

흔히 "메모리 누수" 라는 표현을 쓰기도 하는데

어떤 값의 참조 카운트가 0이 되지 않아 가비지 컬렉터의 수거 대상이 되지 않는 경우를 얘기하는 것이다.

하지만 관리방법은 정말 간단하다.

클로저는 어떤 필요에 의해 의도적으로 함수의 지역변수를 메모리를 소모하도록 함으로써 발생한다.

그렇다면 그 필요성이 사라진 시점에는 더는 메모리를 소모하지 않게 해주면 된다.

참조 카운트를 0 으로 만들어주면 언젠간 가비지 컬렉터가 수거해갈 것이다.

보통 null이나 undefined를 할당하면 해결된다.

클로저 메모리 관리 예제 코드로 살펴보자.

var outer = function(){
  var a = 1;
  var inner = function(){
    return ++a;
  };
  return inner;
};
var outer2 = outer();

console.log(outer2());
console.log(outer2());
outer = null; 			// outer 식별자의 inner 함수 참조를 끊음

마지막 라인을 보면 이렇게 null을 할당하면 끝이다.

클로저 활용

정보은닉은 어떤 모듈의 내부 로직에 대해 외부로의 노출을 최소화해서,

모듈간의 결합도를 낮추고 유연성을 높이고자 하는 현대 프로그래밍 언어의 중요한 개념이다.

쉽게 말해 외부에서는 오직 return 한 정보에만 접근할 수 있다.

return 값이 외부에 정보를 제공하는 유일한 수단인 것이다.

외부에 제공하고자 하는 정보들을 모아서 return하고,

내부에서만 사용할 정보들은 return하지 않는 것으로 접근 권한 제어가 가능하다.

따라서 return한 변수들은 공개 멤버(public member)가 되고,

그렇지 않은 변수들은 비공개 멤버(private member)가 되는 것이다.

간단한 게임으로 해당 예제를 보자.

var car = {
  fuel: Math.ceil(Math.random() * 10 + 10),	 // 연료
  power: Math.ceil(Math.random() * 3 + 2),	 // 연비
  moved:0,									 // 총 이동거리
  run: function(){
    var km = Math.ceil(Math.random() * 6);
    var wasteFuel = km / this.power;
    if(this.fuel < wasteFuel){
      console.log('이동불가');
      return;
    }
    this.fuel -= wasteFuel;
    this.moved += km;
    console.log(km + 'km 이동 (총 ' + this.moved + 'km)');
  }
}

// 각 턴마다 주사위를 굴려 나온 숫자(km)만큼 이동한다.
// 차량별로 연료량과 연비는 랜덤으로 생성된다.
// 남은 연료가 이동할 거리에 필요한 연료보다 부족하면 이동하지 못한다.
// 모든 유저가 이동할 수 없는 턴에 게임이 종료된다.
// 게임 종료 시점에 가장 멀리 이동해 있는 사람이 승리한다.

이렇게 간단한 게임을 만들어 보았다.

모든 유저가 run 메서드만 호출하면 해당 게임의 코드는 아무런 문제가 없다.

하지만 일부 유저가 JS를 다룰줄 안다면 조작을 해버릴 수 있다.

car.fuel = 99999999;
car.power = 9999999;
car.moved = 9999999;

이런식으로 해버리면 치트키가 따로 없다.

이런 케이스에서 값을 바꾸지 못하도록 방어할 때 클로저를 활용하는 것이다.

객체가 아닌 함수로 만들고, 필요한 멤버만을 return 하면 된다.

var createCar = function() {
  var fuel = Math.ceil(Math.random() * 10 + 10); // 연료
  var power = Math.ceil(Math.random() * 3 + 2);  // 연비
  var moved = 0;
  
  return {
    get moved() {
      return moved;
    },
    run: function() {
      var km = Math.ceil(Math.random() * 6);
      var wasteFuel = km / power;
      if (fuel < wasteFuel) {
        console.log('이동불가');
        return;
      }
      fuel -= wasteFuel;
      moved += km;
      console.log(km + 'km 이동 (총 ' + moved + 'km). 남은 연료: ' + fuel);
    }
  };
};

var car = createCar();

fuel, power 변수는 비공개 멤버로 지정해 외부에서 접근을 제한하고,

moved 변수는 getter만을 부여함으로써 읽기 전용 속성을 부여했다.

이제 외부에서는 run 메서드 실행과, 현재 moved 값을 확인하는 두가지 동작만 할 수 있다.

커링 함수

다음으로 이제 커링 함수에 대해 살펴보자.

커링 함수란 여러개의 인자를 받는 함수를 하나의 인자만 받는 함수로 나눠서

순차적으로 호출될 수 있게 체인형태로 구성한 것을 말한다.

함수를 실행한 결과는 그 다음 인자를 받기 위해 대기만 할 뿐,

마지막 인자가 전달되기 전까지는 원본 함수가 실행되지 않는다.

이것도 관련 코드를 먼저 보자.

var curry5 = function(func){
  return function(a){
    return function(b){
      return function(c){
        return function(d){
          return function(e){
            return func(a, b, c, d, e);
          };
        };
      };      
    };
  };
};
var getMax = curry5(Math.max);
console.log(getMax(1)(2)(3)(4)(5));

결과적으로 이 코드는 5개의 숫자 중에서 가장 큰 숫자를 한번에 찾아줄 것이다.

하지만 한눈에 봐도 코드가 길고 가독성이 떨어진다.

ES6에서 제공하는 화살표 함수를 써서 한줄에 표기할 수 있다.

const curry5 = func => a => b => c => d => e => func(a, b, c, d, e);

이렇게 화살표 함수로 변환하면 한줄에 표기할 수 있다.

각 단계에서 받은 인자들을 모두 마지막 단계에서 참조할 것이므로 가비지 컬렉터되지 않고,

메모리에 차곡차곡 쌓였다가, 마지막 호출로 실행 컨텍스트가 종료된 후에야

한꺼번에 가비지 컬렉터의 수거 대상이 된다.

이런식으로 하면 결국 마지막 인자가 넘어갈 때까지 함수 실행을 미루는 셈이된다.

이 커링 함수가 유용한 경우는 바로 지연실행이다.

원하는 시점까지 지연시켰다가 실행하는 것이 필요할때 커링을 쓰기 적합하다.

프로젝트 내에서 자주 쓰이는 함수의 매개변수가 항상 비슷하고 일부만 바뀌는 경우에도 적합할 것이다.

이렇게 클로저에 대해서 제대로 알아보았다.

클로저는 확실히 코드를 보고나서 다시 설명을 보니 이해가 잘 가는것 같다.

그리고 클로저 메모리는 항상 주의를 해야겠다.

다음 챕터는 "프로토타입" 이다.

[해커톤] 숙명여대 Bigdata/AI Streamlit 해커톤 멘토 참여후기

대파양파애비 — Wed, 27 Sep 2023 22:30:48 +0900

숙명여대 Streamlit 해커톤 AWS 멘토

Streamlit 해커톤

저번주에 숙명여대에서 Bigdata/AI Streamlit 해커톤을 진행했다.

나는 AWS 멘토로 참여하게 되어서 간략하게 후기를 써보려고 한다.

저번 인하대 해커톤 AWS 멘토로 참여했을때, 멘토진들이랑 거의 동일해서 반가웠다ㅎㅎ

AWS 멘토진

이번 해커톤은 오뚜기가 후원사여서 오뚜기의 상품 판매 데이터와, 제품 리뷰 데이터를 받아서 진행했다.

해당 데이터와 생성형 AI를 활용하여 Streamlit or Cloud native app을 개발을 하였다.

Streamlit에 대해서 이번기회에 처음 접하게 되었는데,

Streamlit은 데이터 사이언티스트나 백엔드 개발자처럼 프론트엔드에 익숙하지 않은 사람들도

쉽게 데이터 시각화나 웹 앱을 만들 수 있도록 해주는 파이썬 라이브러리이다.

코드 몇 줄만으로도 인터랙티브한 대시보드나 차트를 만들 수 있어서,

특히 데이터 분석이나 머신러닝 모델의 결과를 빠르게 시각화하고 공유하는 데 엄청 유용한것 같다.

따라서 Streamlit은 이번 해커톤 취지에 딱 맞는것 같았다.

해커톤 스케쥴

시상내역은 다음과 같았다.

- 오뚜기상 100만원

- Snow (Streamlit)상 50만원

- AWS상 AWS Stock 팀원당 1주

- Slack상 50만원

- 인기상 30만원

따라서 전략적으로 어떤 시상에 초점을 두고 할지에 따라 주제도 다양하게 정해졌다.

내가 멘토링을 맡았던 조들에 대해 간략하게 얘기해보면,

악성재고 처리, 반품데이터 분석, 우크라이나 식품지원 등등 너무나 좋은 아이디어가 많았다.

열정! 열정! 열정!

밤새고 진행하는 해커톤인 만큼 새벽에 출출하지 않게 오뚜기에서 밥차(?)도 왔다.

오뚜기 만세

이번 해커톤에서 느낀점은

다음에 프로젝트할 때 한번쯤은 꼭 Streamlit을 써봐야겠다고 느꼈다.

내가 백엔드 개발자다보니 프론트엔드쪽을 잘 몰라서, 지금 사이드 프로젝트 진행하는건

나(백엔드), 프론트엔드, 디자이너, AI 이렇게 넷이서 하고 있지만

Streamlit을 쓰면 나 혼자서도 간단한 사이드 프로젝트는 할 수 있지않을까..? 싶었다.

다음 사이드 프로젝트는 Streamlit으로 도전 !!

[Nest.JS] Nest.JS에서 cache-manager를 활용한 캐싱 방법

대파양파애비 — Sun, 17 Sep 2023 03:31:10 +0900

Nest.JS

운영중인 서비스에서 응답시간이 느려진 부분이 있어서, 이를 개선하고 싶었다.

마침 유저 구분이 필요 없고, 수정이 거의 없는 페이지라서 캐싱 전략을 사용하기 적합해 보였다!

해당 페이지에 대해 간략하게 설명하자면,

당일 새벽시간의 뉴스데이터를 전부 분석을 해서 아침 8시에 그날의 뉴스를 한눈에 정리해서 보여주는 페이지다.

따라서 유저별로 개인화가 들어가는 페이지도 아니고, 웬만해서는 수정이 이뤄지지 않는 API 이다.

그럼 바로 캐싱작업을 시작해보자.

설치

해당 프로젝트로 이동해서 필요한 패키지를 몇가지 설치해주자.

npm install cache-manager

cache-manager: 캐싱을 담당할 라이브러리다.

npm install @nestjs/common

nestjs의 CACHE_MANAGER: NestJS에서 캐싱을 쉽게 관리하기 위한 것이니까 이것도 설치해줘야된다.

(일반적으로 NestJS 프로젝트를 시작할 때 이미 @nestjs/common은 설치되어 있을것이다.)

npm install @types/cache-manager

TypeScript: 만약 TypeScript를 사용하고 있다면, @types 패키지도 설치해야 할 수도 있다.

이제 전부 설치를 했으니 코드로 가보자.

캐싱 처리 코드

해당 @Get 요청을 하는 API의 Service부로 이동하자.

service 부

먼저 캐싱 처리 코드는 이런식으로 구현을 했는데, 이제 하나씩 코드를 살펴보자.

import { CACHE_MANAGER, Inject, Injectable } from '@nestjs/common';
import { Cache } from 'cache-manager';

@Injectable()
export class TodayService {
  constructor(@Inject(CACHE_MANAGER) private cacheManager: Cache) {}

1. @Inject(CACHE_MANAGER)

NestJS에서 Dependency Injection을 사용하면서 @Inject 데코레이터를 사용한다.

여기서 CACHE_MANAGER는 특정 서비스나 객체를 주입할 때 사용되는 토큰이라고 생각하면 된다.

이 토큰으로 어떤 객체를 주입할지 NestJS가 알게 된다고 보면된다.

2. private cacheManager Cache

여기서 cacheManager는 주입받은 객체를 사용할 수 있는 클래스 내부의 변수이다.

그리고 이 변수의 타입은 Cache 이다 .

이 코드의 주 목적은 Cache 타입의 객체를 cacheManager라는 이름으로 클래스에 주입하는 것이다.

이를 위해 CACHE_MANAGER라는 토큰을 사용한다.

cache-manager에서 캐싱을 쉽게 관리할 수 있게 몇가지 메서드를 제공하는데 간단히 살펴보자.

1 .get(key)

- 주어진 키에 해당하는 값을 가져온다.

- "key" : 찾을 값의 키

const value = await this.cacheManager.get('key');

2. .set(key, value, [options])

- 캐시에 키-값 쌍을 저장한다.

- "key" : 저장할 키

- "value" : 저장할 값

- "options" : 옵션 객체. 보통 { ttl: 시간(초) } 이런 식으로 시간을 설정한다.

await this.cacheManager.set('key', 'value', { ttl: 60 });

이제 이 두가지 메서드로 캐싱처리를 할 수 있다.

async getData(key: string): Promise<any> {
    // 캐시에서 데이터 확인
    const cachedData = await this.cacheManager.get('temp');

    if (cachedData) {
      // 캐시에 데이터가 있으면 반환
      return cachedData;
    } else {

    // 캐시에 데이터가 없으면 새로 데이터를 생성 (DB 조회 등)
    const newData = await this.~~~~

    // 새로 생성한 데이터를 캐시에 저장
    await this.cacheManager.set('temp', newData, 360000 });  // ttl : 1시간 설정

    return newData;
  	}
  }

간단하게 IF - ELSE문 으로 구현이 가능하다.

저장한 캐시데이터가 있는지 찾고,

캐시 데이터가 있으면 그대로 바로 값을 return하고,

캐시 데이터가 없으면 ELSE 쪽 로직을 돌면서 return 하기 직전에

cacheManager.set() 으로 ttl시간과 함께 캐시데이터를 저장한다.

이렇게 캐싱 구현을 마치고 성능 테스트를 해봤는데 결과가 놀라웠다.

처음 로딩할 때는 캐싱데이터 .set() 을 하느라 400ms 가량 걸렸는데,

그 후 캐싱 적용이 된 같은 페이지를 로딩 했을때엔 10ms 미만으로 엄청난 성능을 보여줬다.

대만족 !

회사 직원분들도 빨라진 서비스에 만족을 하셨다 ㅎㅎ

장점, 단점, 주의사항

캐싱의 장점

빠른 데이터 접근: 캐싱된 데이터는 빠르게 접근할 수 있다.

서버 부하 감소: 데이터베이스나 다른 서비스에 덜 접근하므로 서버 부하가 감소한다.

캐싱의 단점

최신 데이터 지연: 캐싱된 데이터가 최신이 아닐 수 있다.

캐시 무효화 전략 필요: 언제 캐시를 지울지, 언제 새로운 데이터로 갱신할지에 대한 전략이 필요하다.

주의 사항

캐시 사이즈: 캐시 사이즈가 너무 크면 메모리 이슈가 생길 수 있다.

캐시 유효 시간 (TTL): 너무 짧으면 캐싱의 의미가 없고, 너무 길면 데이터가 최신이 아니게 될 수 있다.

이렇게 장단점과 주의사항을 보면 추후에 개선해줘야 할 게 바로 떠오를 것이다.

해당 캐싱 처리 쪽 API 의 내용을 혹시나 수정하게되면,

수정한 내용이 TTL 시간이 지날때 까지 반영이 되지 않을 것이다.

따라서 @Update API쪽에 캐싱 초기화를 넣으면 좋을것 같다.

캐싱 초기화는 두가지 방법이 있다.

- del : 특정 키로 저장된 캐시 삭제

this.cacheManager.del('키', (err) => {
  if (err) {
    // 에러 처리
  }
});

- reset: 모든 캐시 삭제

this.cacheManager.reset((err) => {
  if (err) {
    // 에러 처리
  }
});

이 두가지중에 Update API에 넣기 적합한 건 "del" 이므로

추후에 작업을 할 때, 해당 Update 로직에 캐싱초기화를 추가해야겠다.

참조 : https://docs.nestjs.com/techniques/caching

Documentation | NestJS - A progressive Node.js framework

Nest is a framework for building efficient, scalable Node.js server-side applications. It uses progressive JavaScript, is built with TypeScript and combines elements of OOP (Object Oriented Programming), FP (Functional Programming), and FRP (Functional Rea

docs.nestjs.com

[Error] 504 Gateway Timeout Error 해결: Nginx와 로드밸런서 타임아웃

대파양파애비 — Sat, 16 Sep 2023 23:29:26 +0900

504 Error

얼마 전 회사 프론트직원분께서 staging admin에서 504에러가 뜬다고 찾으셨다.

그래서 바로 staging Swagger에서 관련 API를 날려보니 다음과 같이 나왔다.

504 Gateway Time-out

확인해보니 504 Time-out 에러가 나왔다.

이제 차근차근 해결을 해보자 !

해결 1 - axios timeout 설정

해당 API 부분은 axios로 코드를 불러와서 파싱한 후 리턴하는 코드다.

axios 할 때 일정 시간을 초과하면 504에러가 뜰 수 있다는 얘기가 있어서,

우선 time-out 시간을 늘려주기로 했다.

axios - code

갑자기 504에러가 뜬 이유는 axios로 받아오는 chatGpt 관련 처리시간이 늦어진듯 하다.

그래서 timeout 을 10분으로 넉넉히 변경하였다.

timeout : 600000

로컬에서 코드를 돌렸을때엔 100초정도 뒤에 504에러없이 잘 출력되었다.

그래서 바로 staging로 배포를 하고,

staging Swagger에서 동일하게 해당 API를 돌려보았다.

엥?

504 Gateway Time-out

다시 이전과 같은 504 에러가 나왔다.

로컬에선 정상적으로 실행됬는데 staging에서 에러가 뜨는거 보면,

유추해볼만한 케이스는 두가지가 있다.

1. Nginx의 타임아웃 설정

2. AWS ELB의 타임아웃 설정

이제 1, 2번을 하나씩 해결해보자.

해결 2 - Nginx timeout 설정

AWS EC2에서 해당 인스턴스를 찾고 SSH 터미널을 사용해 접속하자.

EC2 Instance Connect

이제 Nginx의 메인 설정 파일을 열어보자.

sudo vi /etc/nginx/sites-available/default

// 뒤에 default 자리엔 server_name을 써주면 된다.

Nginx 설정 파일로 이동했으면 사진처럼 location / 으로 이동해서 timeout 코드를 추가해 주자.

Nginx 설정파일

location / {
    ...
    proxy_connect_timeout 600s;
    proxy_send_timeout 600s;
    proxy_read_timeout 600s;
    send_timeout 600s;
    ...
}

시간은 넉넉히 10분으로 변경했다.

이제 Nginx 설정파일을 저장 ":wq" 하고 나오자.

sudo nginx -s reload

그리고 해당 명령어로 Nginx를 재시작 시켜주면 설정 끝이다.

이제 다시 Staging Swagger로 가서 해당 API를 실행 시켜주자.

504 Gateway Time-out

엥?

혹시나 Nginx 설정 코드가 반영이 안되는건가 싶어서 테스트 해보자.

location / {
    ...
    proxy_connect_timeout 3s;
    proxy_send_timeout 3s;
    proxy_read_timeout 3s;
    send_timeout 3s;
    ...
}

다시 설정 SSH 터미널로 가서 Nginx 설정을 다음과 같이 3초로 바꿔주었다.

그러고 Nginx를 재시작하고 Staging Swagger에서 API를 실행해보니

정확히 3초만에 504 Error가 나왔다..!

그러면 이제 Nginx time-out 설정은 잘 반영되는걸 확인했으니 다시 원래대로 600초로 변경해주자.

해결 3 - ELB timeout 설정

다른게 전부 이상없으니 이제 마지막으로 ELB time-out 설정을 바꿔보자.

EC2 -> 로드 밸런서 -> 해당 ELB

이렇게 이동해 ELB로 들어간다.

AWS ELB

스크롤 내려서 속성에서 편집에 들어가서

"유휴 제한 시간" 을 사진처럼 600초로 맞춰주자.

이렇게 ELB timeout 설정은 간단하게 끝났다.

Staging Swagger로 이동해서 기도를 하며 API를 날려보자.

Success!!!

....!!!

이제 정상적으로 504 Error 없이 해결되었다.

웹에가서 한번 확인해보니, 80초 가량 걸려서 에러없이 잘 출력되는걸 확인했다 !

해결완료 ^___^

[Javascript] 콜백 함수_코어 자바스크립트

대파양파애비 — Mon, 4 Sep 2023 04:24:52 +0900

코어 자바스크립트

오늘은 4단원인 "콜백 함수" 를 포스팅 할 것이다.

중간에 "콜백 함수 내부에서의 this" 에 대해서 깊게 다루니

이전 포스팅인 "this" 에 대해서 필수적으로 알고 있어야 한다.

https://ilikezzi.tistory.com/58

[Javascript] this_코어 자바스크립트

오늘은 3단원인 "this" 를 포스팅 할 것이다. 지난번 포스팅한 "실행 컨텍스트" 도 읽어보면 도움이 될 듯하다. https://ilikezzi.tistory.com/55 [Javascript] 실행 컨텍스트_코어 자바스크립트 저번에 포스팅

ilikezzi.tistory.com

04. 콜백 함수

콜백 함수란?

콜백 함수는 쉽게 말해 함수 안에 함수다.

즉, 다른 함수의 인자로 전달되는 함수이다.

비동기 작업이 끝나면 어떤 작업을 해야 할지를 콜백 함수로 지정할 수 있어서

주로 비동기 작업에서 자주 사용된다.

콜백 함수는 제어권과 관련이 깊다.

예를 들어, 내가 친구에게 "나 이따가 연락할 테니까, 그때 전화받아줘!"라고 부탁했다고 해보자.

여기서 친구는 "전화받는 일"이라는 특정 작업을 담당하게 되고, 그 '제어권'을 가지게 된다.

내가 전화를 걸면 친구는 그 전화를 받아 '약속한 대로' 행동을 하는게 이게 바로 제어권을 넘겨주는 상황이다!

콜백 함수도 비슷하다.

특정 함수나 이벤트가 일어났을 때, "이제 너 차례야, 이 일을 해줘!"라고 다른 함수에게 제어권을 넘기는 거다.

인자

var newArr = [10, 20, 30].map(function (currentValue, index) {
  console.log(currentValue, index);
  return currentValue + 5;
});
console.log(newArr);

// 10 0
// 20 1
// 30 2
// [15, 25, 35]

이런식으로 할당 되는 콜백함수 예제가 있다.

map 메서드의 구조를 확인해보면 다음과 같다.

Array.prototype.map(callback[, thisArg])
callback: function(currentValue, index, array)

map 메서드는 첫번째 인자로 콜백함수를 받고, 생략가능한 두번째 인자로 콜백함수 내부에서의 this를 지정할 수 있다.

thisArg를 생략할 경우엔 일반 함수와 마찬가지로 전역객체가 바인딩 된다.

첫 코드에서 콘솔값이 할당되는건 쉽게 이해를 했을것이다.

그럼 한번 콜백함수 내부의 첫번째 인자를 index, 두번째 인자를 currentValue가 오게 변경해보자.

var newArr2 = [10, 20, 30].map(function (index, currentValue) {
  console.log(index, currentValue);
  return currentValue + 5;
});
console.log(newArr2);

// 10 0
// 20 1
// 30 2
// [5, 6, 7]

새로만든 newArr2를 보면

사람은 'index' , 'currentValue' 단어로 접근하기 때문에 순서를 바꿔도 의미가 바뀌지 않으니깐

문제 없을 것이라 생각하기 쉽지만, 컴퓨터는 그저 첫번째 두번째 순서에 의해서만 구분한다.

따라서 마지막에 콘솔값을 보면 각각 [15, 25, 35] // [5, 6, 7] 로 서로 다르게 나온다.

newArr2에 currentValue라고 명명한 인자의 위치가 두번째라서 컴퓨터가 여기에 인덱스 값을 부여하게 된 것이다.

콜백함수를 호출하는 주제가 사용자가 아닌 map 메서드이므로

원하는 배열을 얻으려면 map 메서드에 정의된 규칙에 따라 함수를 작성해야 한다.

map메서드가 콜백함수를 호출할 때 인자에 어떤값들을 어떤순서로 넘길 것인지가

전적으로 map메서드에게 달린것이다.

이처럼 콜백함수의 제어권을 넘겨받은 코드는 콜백함수를 호출할 때

인자에 어떤값들을 어떤순서로 넘길 것인지에 대한 제어권을 갖는다.

this

콜백함수도 함수이기 때문에 기본적으로는 this가 전역객체를 참조하지만,

제어권을 넘겨받을 코드에서 콜백함수에 별도로 this가 될 대상을 지정한 경우엔 그 대상을 참조한다.

setTimeout(function () { console.log(this); }, 300); 

[1, 2, 3, 4, 5].forEach(function(x) {
	console.log(this);
});

// (1) Window {...}
// (2) Window {...}

위 두 콜백함수 내부에서의 this는 콘솔을 찍어보면 둘 다 전역객체를 가리킨다.

둘다 따로 명시적으로 this를 바인딩하지 않았기 때문에

기본적으로 전역 컨텍스트에서 실행되기 때문에 Window {...} 가 출력된다.

const obj = {
  vals: [1, 2, 3],
  logValues: function (v, i) {
    console.log(this, v, i);
  },
};


obj.logValues(1, 2); 				// { vals: [1, 2, 3], logValues: f} 1 2
[4, 5, 6].forEach(obj.logValues);	// Window {...} 4 0
									// Window {...} 5 1
									// Window {...} 6 2

해당 코드에서 첫번째의 출력을 보면

이름앞에 점이 있으니 메서드로서 호출 한 것이다.

따라서 this는 obj를 가리키고 인자로 넘어온 1, 2 가 출력된다.

두번째의 출력은 다른 방식으로 작동한다.

forEach에서 obj.logValues가 콜백으로 전달되면, 이 함수는 일반 함수로 호출된다.

그래서 this가 전역 객체를 가리키는 거다. (obj X)

원래 obj.logValues는 obj라는 객체 안에 있었지만, forEach 안에서는 그 연결이 끊어지게 된다.

만약 this를 obj로 지정하고 싶다면 별도로 this인자를 지정하거나

call, apply, bind 같은 메서드를 사용해 this를 지정해야 한다.

이전 "this" 포스팅에서 다뤘지만 한번 더 call, apply, bind에 대해서 짚고 넘어가자.

call

Func.call(obj, arg1, arg2, ...);

1. obj는 명시적으로 this를 어떤 객체로 바인딩할지 정해준다.

2. 그 다음으로 함수에 필요한 인자값들을 차례대로 넘겨준다.

apply

Func.apply(obj, [arg1, arg2, ...]);

1. obj는 명시적으로 this를 어떤 객체로 바인딩할지 정해준다.

2. 그 다음으로 함수에 필요한 인자값들을 차례대로 넘겨준다.

(call 과 차이점은 인자를 배열 형태로 넘긴다)

bind

const boundFunc = Func.bind(obj);

1. 새로운 함수를 만들어서 반환한다.

2. 그 함수의 this는 bind로 지정한 객체로 고정되어 있다.

콜백 지옥

콜백 지옥이라는 건, 콜백 함수가 다른 콜백 함수 내부에서 또 호출되고,

그 안에서 또 다른 콜백 함수가 호출되는 등 이런식으로 깊어지는 상황을 말한다.

이렇게 되면 코드가 정말 복잡해져서 읽기도 어렵고, 유지보수도 힘들어진다.

// 콜백 지옥

setTimeout(() => {
  console.log('첫 번째 작업');
  setTimeout(() => {
    console.log('두 번째 작업');
    setTimeout(() => {
      console.log('세 번째 작업');
    }, 1000);
  }, 1000);
}, 1000);

콜백 지옥을 보면 들여쓰기가 깊어지는 것처럼 코드가 >)>)>)>) 이런 모양이 돼서, "피라미드 코드"라고도 부르기도 한다.

이게 코드의 가독성을 낮추고, 오류를 찾기 어렵게 만든다.

이 가독성 문제와 어색함을 동시에 해결하는 가장 간단한 방법은

익명의 콜백 함수를 모두 기명함수로 전환하는 것이다.

// 기명 함수

function thirdJob() {
  console.log('세 번째 작업');
}

function secondJob() {
  console.log('두 번째 작업');
  setTimeout(thirdJob, 1000);
}

function firstJob() {
  console.log('첫 번째 작업');
  setTimeout(secondJob, 1000);
}

setTimeout(firstJob, 1000);

기명 함수는 재사용하기 좋고, 디버깅할 때도 편하다.

이름이 있으니까 함수의 목적이 뭔지 더 쉽게 알 수 있다.

하지만 이렇게 일회성 함수를 전부 변수에 할당하는 것이 불만일수도 있다.

그래서 마침 ES6에서 Promise 가 도입되었다.

// Promise

const wait = ms => new Promise(resolve => setTimeout(resolve, ms));

wait(1000).then(() => {
  console.log('첫 번째 작업');
  return wait(1000);
}).then(() => {
  console.log('두 번째 작업');
  return wait(1000);
}).then(() => {
  console.log('세 번째 작업');
});

Promise에 대해서 간략히 설명하자면,

Promise는 크게 resolve와 reject 두 가지 상태를 가지고 있다.

resolve는 작업이 성공적으로 끝났을 때 호출되고,

reject는 에러가 발생했을 때 호출된다.

이 코드에서는 wait라는 함수를 선언했는데, 이 함수는 일정 시간(ms)이 지난 후에 resolve를 호출한다.

그래서 .then()을 통해 이후에 실행할 작업을 쭉 이어나갈 수 있다.

첫 번째 wait(1000)은 1초 후에 resolve되고, .then() 안의 첫 번째 작업이 실행된다.

그 다음에 또 wait(1000)을 호출하고, 두 번째 작업을 실행한다.

마지막으로 세 번째 작업까지 이어나간다.

이렇게 Promise를 사용하면, 각 단계별로 어떤 작업을 해야 할지 명확하게 표현할 수 있어서 코드가 훨씬 깔끔하고 이해하기 쉬워진다.

그 후 ES2017에서는 가독성이 뛰어나면서 작성법도 간단한 새로운 기능이 추가되었다.

바로 async / await 이다.

// async / await

const wait = ms => new Promise(resolve => setTimeout(resolve, ms));

async function run() {
  await wait(1000);
  console.log('첫 번째 작업');
  
  await wait(1000);
  console.log('두 번째 작업');

  await wait(1000);
  console.log('세 번째 작업');
}

run();

비동기 작업을 수행하고자 하는 함수앞에 async를 표기하고,

함수 내부에서 실질적인 비동기 작업이 필요한 위치마다 await를 표기하는 것만으로

뒤의 내용을 Promise로 자동 전환하고, 해당 내용이 resolve된 이후에야 다음으로 진행한다.

즉 Promise의 then과 흡사한 기능을 하게된다.

오늘 이렇게 콜백 함수에 대해서 자세히 알아보았다.

다음 챕터는 "클로저" 이다.

[Javascript] this_코어 자바스크립트

대파양파애비 — Tue, 22 Aug 2023 05:38:12 +0900

코어 자바스크립트

오늘은 3단원인 "this" 를 포스팅 할 것이다.

지난번 포스팅한 "실행 컨텍스트" 도 읽어보면 도움이 될 듯하다.

https://ilikezzi.tistory.com/55

[Javascript] 실행 컨텍스트_코어 자바스크립트

ilikezzi.tistory.com

this....

'이것' 이라는 단어 그 자체로의 뜻을 가지지만, 가끔씩 어디를 가르키는건지 헷갈렸는데

이제 그 헷갈리던 this에 대해서 제대로 잡아보자.

03. this

전역 공간에서의 this

브라우저 환경에서 전역객체는 window

Node.js.환경에서 전역객체는 global

전역변수를 선언하면 자바스크립트 엔진은 이를 전역객체의 프로퍼티로 할당한다.

간단한 예제 코드를 보자.

// 브라우저 환경 예시

var a = 1;
console.log(a); = 1
console.log(window.a) = 1
console.log(this.a) = 1

이처럼 자바스크립트의 모든 변수는 실은 특정객체의 프로퍼티이다.

하지만 이는 var에만 해당 되는 얘기다.

var는 함수범위여서 현재 실행 컨텍스트의 전역 객체의 프로퍼티로 할당되지만,

let, const는 블록 범위여서 전역 객체의 프로퍼티로 할당되지 않는다.

var myVar = "hello"; // 전역 객체의 프로퍼티로 할당됨
let myLet = "world"; // 전역 객체의 프로퍼티로 할당되지 않음


console.log(window.myVar); // "hello"
console.log(window.myLet); // undefined

그리고 머쓱하지만 처음 알게된 부분이 있다...

처음부터 전역객체의 프로퍼티로 할당한 경우에는 삭제가 되는 반면,

전역 변수로 선언한 경우에는 삭제가 되지않는다.

뭔소린지 코드로 보자.

var a = 1;
delete window.a;                 // false
console.log(a, window.a, this.a) // 1 1 1

var b = 2;
delete b;                        // false
console.log(b, window.b, this.b) // 2 2 2



window.c = 3;
delete window.c;                 // true
console.log(c, window.c, this.c) // Uncaught ReferenceErrorr: c is not defined

window.d = 4;
delete d;                        // true
console.log(d, window.d, this.d) // Uncaught ReferenceErrorr: d is not defined

위 두개랑 아래 두개의 차이점을 보자.

위 두개는 전역변수로 선언을 해서 삭제가 안되고,

아래 두개는 처음부터 전역변수의 프로퍼티로 할당을 해서 문제 없이 삭제가 되었다.

왜 그럴까?

이는 사용자가 의도치 않게 삭제하는 것을 방지하는 차원에서 마련한 나름의 방어 전략이라고 해석된다.

전역변수로 선언시, JS엔진이 이를 자동으로 전역객체의 프로퍼티로 할당하면서 추가적으로

해당 프로퍼티의 configurable 속성(변경 및 삭제 가능성)을 false로 정의해버린다.

메서드로서 호출할 때의 this

크게 함수로서의 호출과 메서드로서의 호출이 있는데

메서드로서의 호출은 되게 간단하다.

점 표기법 (.) 이든 대괄호 표기법이든, 어떤 함수를 호출할 때

그 함수이름 앞에 객체가 명시되어 있으면 메서드로서의 호출이다.

var obj = {
	method = function(x) { console.log(this, x); }
};

obj.method(1);    // { method: f } 1
obj['method'](2); // { method: f } 2

함수로서 호출할 때의 this

이 부분도 생각보다 단순하다.

this 바인딩에 관해서는 함수를 실행하는 당시의 주변환경은 중요하지 않고,

오직 해당 함수를 호출하는 구문 앞에서 점 또는 대괄호 표기가 있는지 없는지가 관건이다.

저번 포스팅인 2단원_실행 컨텍스트에서 나왔던

실행 컨텍스트를 활성화할 당시에 this가 지정되지 않은경우 전역객체를 바라본다고 했다.

ES6에서는 이 문제를 보완하고자 화살표 함수를 도입했다.

화살표 함수는 this를 바인딩하지 않고, 선언될 당시의 상위 스코프의 this를 그대로 사용한다.

그래서 특정 객체의 메소드 안에서 비동기 작업을 할 때 this를 유지하고 싶을 때 많이 사용한다.

즉, 화살표 함수 안에서는 this가 아예 없으며, 스코프체인상 가장 가까운 this에 접근하게 된다.

var obj = {
  outer: function () {
    console.log(this);       // (1) { outer:f }
    var innerFunc = () => {
      console.log(this);     // (2) { outer:f }
    };
    innerFunc();
  }
};
obj.outer();

위 코드 처럼 두 콘솔의 this가 같은 곳을 바라보고 있다.

생성자 함수 내부에서의 this

function Dog(name, breed) {
  this.name = name; // 여기서 this는 새로 생성되는 객체를 가리킨다.
  this.breed = breed;
}

var myDog = new Dog('Buddy', 'Golden Retriever');

console.log(myDog.name);  // 'Buddy'
console.log(myDog.breed); // 'Golden Retriever'

생성자 함수는 일반 함수와 달리 new 키워드와 함께 호출되며,

이때 생성자 함수 내의 this는 생성되는 객체를 가리키게 된다.

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

상황별로 this에 어떤값이 바인딩되는지를 살펴봤지만 this에 별도의 대상을 바인딩하는 방법도 있다.

call 메서드

Function.prototype.call(thisArg, arg1, arg2, ...);

call 메서드는 함수를 호출하면서 첫 번째 인자로 this 값을 바인딩하고,

나머지 인자들을 그대로 함수의 파라미터로 전달한다.

- thisArg: this로 바인딩할 값

- arg1, arg2, arg3, ...: 함수에 전달될 인자들

apply 메서드

Function.prototype.apply(thisArg[, argsArray]);

apply 메서드는 call과 비슷한데, 인자들을 배열 형태로 전달한다는 차이가 있다.

- thisArg: this로 바인딩할 값

- [argsArray]: 함수에 전달될 인자들의 배열

call과 apply는 모양만 조금 다를 뿐 기능은 같다.

쉽게말해, 배열로 인자를 넘기고 싶으면 apply, 그렇지 않으면 call을 사용하면 된다.

function Person(name, gender) {
  this.name = name;
  this.gender = gender;
}

function Student(name, gender, school) {
  Person.call(this, name, gender);
  this.school = school;
}

function Employee(name, gender, company) {
  Person.apply(this, [name, gender]);
  this.company = company;
}

const by = new Student('Blanc', 'male', '하버드');
const jn = new Employee('개발', 'male', 'JS');


console.log(by);
// {
//   name: 'Blanc',
//   gender: 'male',
//   school: '하버드'
// }

console.log(jn);
// {
//   name: '개발',
//   gender: 'male',
//   company: 'JS'
// }

이렇게 생성자 내부에서 call , apply 로 다른 생성자를 호출해 반복을 줄일 수 있다.

다음으로 콜백함수 내에서의 this에 대해서 살펴보자.

var report = {
  sum: 0,
  count: 0,
  add: function() {
    var args = Array.prototype.slice.call(arguments);
    args.forEach(function (entry){
      this.sum += entry;
      ++this.count;
    }, this);
  },
  average: function(){
    return this.sum / this.count;
  }
};
report.add(60, 85, 95);
console.log(report.sum, report.count, report.average()); // 240 3 80

Array.prototype.slice.call(arguments)를 사용해 배열로 변환하는데,

forEach를 사용해서 배열을 순회한다.

forEach의 두 번째 인수로 this를 전달하면, forEach 내의 콜백 함수에서 이 this가 바인딩된다.

report.add(60, 85, 95)를 호출해서 여기서 this는 report를 바라보게 된다.

확실히 포스팅을 하고나니 this에 대해서 제대로 알게된 것 같다.

다음 챕터는 "콜백 함수"이다

[Javascript] console.dir()로 객체의 모든 depth 구조 출력

대파양파애비 — Tue, 15 Aug 2023 05:38:22 +0900

오늘 할 내용은 코드로 바로 확인 해보자.

service 부

단순히 axios로 불러온 데이터를 파싱해서 쓰려고 했는데, 모든 depth의 데이터가 나오지 않았다.

예전에도 이런적이 한 번 있었는데 이번에 또 같은 케이스여서 포스팅을 해본다.

console.log(Openai_data.data)

이렇게 사진처럼 comments: [Array] 라고 나오는데 나는 그 값을 필요로해서 보고싶었다.

자바스크립트에서 객체를 콘솔에 출력하면, 기본적으로 일부 깊이까지만 출력되고,

그 이상의 깊이는 [Array]나 [Object] 형태로 간략하게 표시되는 경우가 있다.

이때 console.dir() 을 쓰면 해결 가능하다.

자주 사용하는 console.log()와 console.dir()를 비교해 보면서 뭔지 알아보자.

console.log()와 console.dir()

- console.log()

사용법: 데이터를 간단하고 빠르게 확인하고 싶을 때 사용한다.

출력 형식: 일반적인 로그 출력에 적합하다.

깊이 제한: 중첩된 속성을 일정 깊이까지만 보여준다.

- console.dir():

사용법: 객체의 내부 구조를 자세히 보고 싶을 때 사용한다.

출력 형식: 트리 형태로 객체의 구조를 보여준다.

깊이 제한: depth 옵션으로 출력 깊이를 조절할 수 있다.

null이면 모든 수준을, 숫자를 지정하면 해당 깊이만큼만 탐색한다.

console.dir(Newming_data.data, { depth: null }); // 무한 깊이까지 출력

console.dir(Newming_data.data, { depth: 2 }); // 2단계 깊이까지 출력

이런식으로 코드는 작성하면 된다.

depth에 대해서 좀 더 자세히 살펴 보면,

console.dir() 메서드의 두 번째 인자로 옵션 객체를 전달할 수 있다.

여기서 depth 프로퍼티는 객체의 내부를 얼마나 깊게 보여줄지 정하는 옵션인데,

null로 설정하면 객체의 모든 수준의 내용을 보여준다.

{depth: 숫자}: 숫자를 지정하면 해당 깊이만큼만 탐색한다.

console.dir(Openai_data.data, { depth: null });

기존에 console.log(Openai_data.data) 부분을

console.dir(Openai_data.data, { depth: null }); 이렇게 변경하니 원하는대로 모든 depth의 데이터가 나왔다.

한번 더 정리를 하자면

console.log()는 빠르게 값 확인하기 좋다.

console.dir()은 객체 분석하기 좋고, 세부적으로 깊이를 조절할 수도 있다.

[Javascript] new Set() 배열에서 쉽게 중복값 제거하기

대파양파애비 — Mon, 14 Aug 2023 05:44:59 +0900

오늘은 배열에서 중복값을 제거하는 방법에 대해서 포스팅을 해보려한다.

console.log(dto.value_uuid)

위 코드는 간략하게 얘기하면 투표항목을 클릭하면 하위depth의 투표 항목까지

전부 불러오는 코드중 일부분이다.

아무튼 하위항목들을 찾아서 기존dto에 push하다가 console.log 창을보니 중복된 값도 같이 쌓이고 있었다.

하위 항목 찾을 때 기존항목 if문으로 비교 후 제거하거나, 정 안되면 for문으로 돌려서 비교후 제외시켜도 되지만

Array에서 바로 처리하는 방법이 있나 궁금해서 찾아보다가

"new Set()" 이라는 방법을 찾게 되었다.

new Set()

- Set 객체는 자바스크립트에서 유일한 값의 집합을 표현할 수 있다.

- 배열의 중복 값을 제거하려면 Set을 이용하면 정말 쉽게 할 수 있다.

사용 방법은 다음과 같다.

- new Set(numbers)는 numbers 배열의 중복 값을 제거한 Set 객체를 만들어준다.

- 스프레드 연산자 ...를 사용하면, Set 객체를 다시 배열로 변환할 수 있다.

const numbers = [1, 2, 2, 3, 4, 4, 5];
const uniqueNumbers = [...new Set(numbers)];

console.log(uniqueNumbers); // [1, 2, 3, 4, 5]

이제 기존코드에 적용을 해보자.

console.log(dto.value_uuid)

정말 간단하게 배열의 중복값을 제거 해버렸다.

new Set()은 간단하고 직관적이고, 코드 길이를 줄이고 가독성을 높일 수 있었다.

다른 복잡한 로직 없이도 중복 제거를 할 수 있어서 만족스럽다 !

[Javascript] 실행 컨텍스트_코어 자바스크립트

대파양파애비 — Sun, 13 Aug 2023 07:08:24 +0900

코어 자바스크립트

저번에 포스팅한 "데이터 타입" 에 이어서 다음 챕터인 "실행 컨텍스트"를 포스팅 할 것이다.

https://ilikezzi.tistory.com/52

[Javascript] 데이터 타입_코어 자바스크립트

계획했던대로 자격증 취득도 다 해서, 8월부터는 알고리즘과 팀프로젝트에 전념할 계획이였다. 하지만 알고리즘 스터디를 하기전에 JS 기본기를 탄탄하게 다져두고 하는게 깊은 이해에 도움이

ilikezzi.tistory.com

위에 있는 저번 포스팅과 크게 이어지는 내용은 아니지만,

그래도 "데이터 타입"에 대한 기본적인 이해가 있어야 이번 포스팅을 쉽게 이해할 수 있을듯 싶다.

02. 실행 컨텍스트

실행 컨텍스트란?

- 실행 컨텍스트(Execution Context)

실행할 코드에 제공할 환경 정보들을 모아놓은 객체다.

자바스크립트의 동적 언어로서의 성격을 가장 잘 파악할 수 있는 중요한 개념이다.

기본적인 개념이지만 한번 집고 넘어가자.

스택(Stack)

- 출입구가 하나뿐인 깊은 우물 같은 데이터 구조다.

- 끝에서만 자료를 넣거나 뺄 수 있다.

- 앞서 실행 컨텍스트를 "실행할 코드에 제공할 환경 정보들을 모아놓은 객체"라고 했는데,

이를 콜 스택에 쌓아 올렸다가, 가장 위에 쌓여있는 컨텐스트와 관련 있는 코드를 하나씩 실행한다.

큐(Queue)

- 양쪽이 모두 열린 파이프 같은 데이터 구조다.

- 한 쪽 끝에서 넣고 반대 쪽 끝에서 빼는 식으로 동작한다.

// --------------------------- (1)
var a = 1;
function outer() {
	function inner() {
    	console.log(a); // undefined
        var a = 3
    }
    inner(); //--------------- (2)
    console.log(a); // 1
}
outer(); // ------------------ (3)
console.log(a); // 1

콜스택

코드의 콜스택 순서를 사진으로 보자.

1. 처음 JS 코드를 실행하는 순간(1) 전역 컨텍스트가 콜스택에 push 된다.

2. 콜스택에 쌓인 전역 콘텍스트 관련된 코드를 실행하다가 (3)에서 Outer를 만나 콜스택에 push 된다.

3. 이제 콜스택 맨 위에 Outer가 놓인 상태이므로 전역 콘텍스트 관련 코드는 일시 중지하고,

Outer 관련 컨텍스트, 즉 Outer 함수 내부의 코드를 순차적으로 실행한다.

4. 다시 (2)에서 Inner 함수의 실행 컨텍스트가 콜스택에 push되서, Inner 함수 내부코드를 실행한다.

5. Inner함수 실행이 끝나면 "pop" 되면서 콜스택에서 제거된다.

6. 이제 아래에 있던 Outer 함수코드를 실행하고, 끝나면 pop 되면서 콜스택에서 제거된다.

7. 마지막으로 맨 아래에 있던 전역 콘텍스트를 마저 실행시키고, 끝나면 pop 되면서 끝난다.

이 처럼 콜스택은 후입선출(LIFO) 방식으로 동작하게 된다.

또한 콜스택이 너무 깊어지면 스택 오버플로우라는 문제가 발생할 수 있다.

이제 활성화된 실행 컨텍스트에는 무엇이 담겨 있는지 보자.

- LexicalEnvironment

현재 코드의 실행 컨텍스트 내에서 식별자와 그에 해당하는 값이 어떻게 연결되는지 나타내는 환경이다.

쉽게 말하면, 어떤 변수가 어떤 값을 가지고 있는지 관리해주는 역할이다.

- VariableEnvironment

현재 실행 컨텍스트에서 var로 선언된 변수들을 관리하는 환경이다.

선언시점의 LexicalEnvironment의 스냅샷으로 변경사항은 반영X

ES6 이전에는 LexicalEnvironment와 거의 동일했지만,

let과 const가 도입되면서 LexicalEnvironment가 좀 더 복잡한 역할을 하게 됐다.

- ThisBinding

this 키워드의 값이 무엇인지 결정하는 부분이다.

함수가 어떻게 호출되었는지, 그리고 어떤 객체의 컨텍스트에서 실행되었는지에 따라 this의 값이 달라지게 된다.

Hoisting

function a() {
	console.log(b);  // (1)
    var b = 'bbb';   // 수집 대상 1 (변수선언)
    console.log(b);  // (2)
    function b() { } // 수집 대상 2 (함수선언)
    console.log(b);  // (3)
}
a();

해당 코드를 예시로 보고 하나씩 살펴보자.

1. a 함수를 실행하는 순간 a 함수의 실행컨텍스트가 생성된다.

2. 이때 변수명과 함수 선언정보를 위로 끌어올린다. (호이스팅)

- 변수는 선언부와 할당부로 나누어 선언부만 끌어올림

- 함수 선언은 함수 전체를 끌어 올린다.

function a() {
	var b;           // 수집 대상 1 (변수선언) 선언부만 끌어올린다.
    // function b() { } // 수집 대상 2 (함수선언) 함수 선언은 전체를 끌어올린다.
	var b = function b() { } // 변경부분!
   
    console.log(b);  // (1)
    b = 'bbb';       // 변수의 할당부는 자리에 남는다.
    console.log(b);  // (2)
    console.log(b);  // (3)
}
a();

호이스팅이 이뤄지면 다음과 같이 변환된다.

하지만 3번째 주석 라인으로 처음에는 변환되지만, 4번째 라인과 같은 의미로 여겨진다.

왜냐?

함수 선언문을 사용하면 자바스크립트 엔진이 해당 함수를 변수에 할당하는 과정을 내부적으로 처리한다.

호이스팅이 끝난 상태에서의 함수 선언문은 함수명으로 선언한 변수에 함수를 할당한 것 처럼 여긴다.

이게 좀 복잡하게 느껴질 수 있는 부분인데, 이전 포스팅에서 데이터 메모리 할당을 봤으면 이해가 될 것이다.

따라서 각 콘솔에 대한 값은 이렇게 출력된다.

(1) : b함수 / (2) : 'bbb' / (3) : 'bbb'

"함수 선언문"과 "함수 표현식"

이제 호이스팅을 다루는데에 꼭 알아둬야 할 "함수 선언문"과 "함수 표현식"에 대해서 알아보자.

 function a() {} // 함수 선언문. 함수명 a가 곧 변수명
 a(); // 실행 OK
 
 var b = function() {} // (익명) 함수 표현식. 변수명 b가 곧 함수명
 b(); // 실행 OK
 
 var c = function d() {} // (익명) 기명 함수 표현식. 변수명 c , 함수명 d
 c(); // 실행 OK
 d(); // 에러!

1. 함수 선언문 (Function Declaration)

함수 선언문은 "function" 키워드로 시작하고, 이름이 있는 함수를 선언한다.

호이스팅 - 함수 선언문은 코드가 실행되기 전에 메모리에 할당되어, 선언문이 있는 코드 블록 내 어디에서든 접근 가능하다.

이름 필수 - 함수에 반드시 이름이 있어야 한다.

2. 함수 표현식 (Function Expression)

함수 표현식은 변수에 함수를 할당하는 형태로 되어있다.

호이스팅 X - 변수 선언만 호이스팅되고, 함수는 할당 시점에 메모리에 저장돼. 따라서 선언 전에 호출하려고 하면 오류가 발생한다.

이름이 선택: 함수에 이름을 주지 않아도 된다. 이름을 준다면 디버깅에 도움이 될 수 있다.

차이점을 한번 더 정리 해보면 다음과 같다.

호이스팅: 함수 선언문은 전체 접근 가능, 함수 표현식은 선언 후에만 접근 가능.

선언 형태: 함수 선언문은 function 키워드로 시작, 함수 표현식은 변수 할당 형태.

이름 유무: 함수 선언문은 이름 필수, 함수 표현식은 이름 선택.

여기서 중요한 포인트가 있다.

협업을 할 때에 함수 선언문은 위험하다.

호이스팅을 제대로 이해한분들은 이게 무슨 얘기인지 눈치 챘을것이다.

두 개발자가 같은 이름으로 함수를 선언하게 되면 나중에 선언한 함수가 이전 선언을 덮어써버린다.

이로 인해 예상치 못한 동작이나 버그가 발생할 수 있다.

그리고 같은 이름의 함수가 여러 곳에서 선언되면, 나중에 코드를 유지보수하거나 리팩토링할 때 문제가 생길 수 있다.

어떤 함수가 어떻게 동작하는지 파악하기 어려워지고, 버그를 찾거나 수정하기 힘들어진다.

따라서 상대적으로 함수 표현식이 안전하다.

스코프 체인

이제 스코프 체인에 대해서 알아보자.

스코프 체인이란?

스코프 체인은 현재 실행 컨텍스트의 스코프에서 시작해서, 상위 스코프를 따라가며 체인처럼 연결된 구조를 말한다.

이 체인은 변수를 찾을 때 사용되며, 현재 스코프부터 시작해서 전역 스코프까지 이어진다.

작동 방식은 다음과 같다.

현재 스코프에서 찾기: 변수를 찾을 때, 현재 스코프부터 찾기 시작한다.

상위 스코프로 올라가기: 현재 스코프에 없으면, 상위 스코프로 올라가서 찾는다.

전역 스코프까지 반복: 전역 스코프까지 계속 올라가서 찾는다.

찾지 못하면 오류: 전역 스코프까지 갔는데도 못 찾으면 ReferenceError를 내뱉는다.

이 규칙을 이해하면 변수가 어떻게 조회되고 동작하는지 이해하는 데 도움이 된다.

스코프 체인 예제 코드로 보자.

var a = 1;
var outer = function () {
    var inner = function() {
        console.log(a); // undefined
        var a = 3;
    };
    inner();
    console.log(a); // 1
};
outer();
console.log(a); // 1

스코프 체인과 호이스팅 관점에서 동작순서를 보자.

1. 전역 스코프에서 변수 a 와 함수 outer가 선언된다.

2. 변수 a에 1을 할당한다.

3. outer 함수가 호출되어 실행 컨텍스트가 생성된다.

4. outer 내부에서 inner 함수가 선언된다.

5. inner 함수가 호출되고, 새로운 실행 컨텍스트가 생성된다.

이 때, inner의 지역 스코프에서 a의 선언이 호이스팅되어 undefined로 초기화된다.

6. inner 함수 내에서 a를 출력하려고 하면, 현재 스코프에서 a의 값은 undefined이므로, undefined가 출력된다.

7. inner 함수 내에서 지역 변수 a에 3을 할당한다.

8. inner 함수의 실행이 종료되고, 해당 실행 컨텍스트가 스택에서 제거된다.

9. outer 함수 내에서 전역 변수 a를 출력하려고 하면, 해당 스코프에서 a의 값은 1이므로, 1이 출력된다.

10. outer 함수의 실행이 종료되고, 해당 실행 컨텍스트가 스택에서 제거된다.

11. outer 함수 외부에서 전역 변수 a를 출력하면, 전역 스코프에서 a의 값은 1이므로, 1이 출력된다.

이렇게 스코프체인과 호이스팅 작동방식에 대해서 예제코드로 찝어보았다.

오늘은 내용이 좀 길었지만 개념과 코드의 동작방식을 하나씩 살펴보면

실행 컨텍스트에 대해서 확실히 이해를 할 수 있을 것이다!

다음 챕터는 "this" 이다.

[AWS] CloudFront + ACM을 이용한 https 리다이렉팅 (Route53,S3)

대파양파애비 — Sat, 12 Aug 2023 06:20:39 +0900

직전에 Route53 + S3로 정적 웹 호스팅하는 방법에 대해 포스팅을 했었다.

https://ilikezzi.tistory.com/53

[AWS] Route53 도메인 구매 및 S3 웹 호스팅

얼마전에 해커톤 멘토링을 다녀와서 서버설계와 DB설계쪽에 부족함을 느껴서 주변에 프론트엔드 1명, AI 1명, 디자이너 1명을 섭외해서 팀프로젝트를 하기로했다. 주제선정과 기능선정이 끝나서

ilikezzi.tistory.com

해당 포스팅과 이어지는 내용이니 먼저 보고와서, 이 포스팅을 봐주면 좋을 것 같다.

이전에 Route53 + S3 를 이용해서 정적 웹 호스팅을 해서 http 까지 완료했다.

이번에는 CloudFront + ACM 을 이용해서 https로 리다이렉팅 해보려고 한다.

우선 왜 이 두가지 서비스를 사용하는지부터 살펴보자.

Amazon CloudFront

- AWS에서 제공하는 글로벌 콘텐츠 전송 네트워크(CDN) 서비스이다.

- CloudFront는 사용자에게 빠른 데이터 전송 속도를 제공하려고 웹사이트의 콘텐츠를 전 세계에 분산된 서버에 배포한다.

- 사용자가 요청하면 가장 가까운 서버에서 콘텐츠를 제공하게 된다.

AWS Certificate Manager (ACM)

- SSL/TLS 인증서를 무료로 제공하고, 관리를 쉽게 해주는 서비스다.

- ACM을 사용하면, HTTPS를 통한 안전한 연결을 쉽게 설정할 수 있다.

- 인증서 갱신 같은거 걱정 없이 안전한 연결을 유지할 수 있다.

요약하자면 웹사이트의 속도를 향상시키고, 사용자에게 안전한 연결을 제공하기 위해서 사용하는 것이다!

먼저 ACM으로 SSL인증부터 받아보자.

"버지니아 북부" 리전을 선택 후

ACM 서비스에 들어가서 인증서 -> 요청을 눌러주자.

도메인 이름에 www. ~~ 가 추가된 도메인과 일반 도메인을 각각 써준다.

그럼 해당 화면처럼 나올텐데 아래 "Route 53에서 레코드 생성"을 눌러준다.

2개가 생성 되었을텐데 CNAME 과 CNAME값을 Route53에서 맞춰줘야한다.

Route53 호스팅 영역에서 레코드 목록을 보면 방금 생성한 항목이 보일 것이다.

여기에 CNAME 값을 비교해보고 "편집"으로 동일한 값으로 맞춰준다.

(나는 자동으로 동일한 값으로 되어 있었다.)

값을 맞춰주었으면 1분정도 안에 다시 ACM->도메인으로 돌아가서 "상태"를 확인해보면 성공으로 변경되었을 것이다.

이제 ACM에서 SSL인증은 끝이다!

그 다음으로 이제 CloudFront 설정을 해보자.

아까와 동일하게 "버지니아 북부" 리전을 선택 후

CloudFront 서비스로 들어가서 배포 생성을 눌러주자.

원본 도메인에 S3 주소를 넣어줘야하는데, 직접 S3에 가서 복사를 해오자.

S3 버킷 -> 속성 -> 스크롤 맨 아래 "정적 웹 사이트 호스팅" 의 엔드포인트 복사

복사한 값을 다시 원본 도메인에 붙혀 넣어주자.

Origin Shield 활성화를 켜주고 버지니아 북부로 해준다.

Redirect HTTP to HTTPS 를 선택 하고,

GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE 를 선택해주자.

캐시 정책은 CahingOptimized 를 선택해주자.

모든 엣지 로케이션 사용을 선택하고,

대체 도메인은 기존도메인과, www.기존도메인 총 두가지를 써주자.

(처음에 한개만 썼다가 리다이렉팅 안되서 다 지우고 다시했다...)

SSL인증서는 아까 ACM에서 했던 SSL인증서를 선택해주자.

이로써 CloudFront 설정도 마쳤다.

이제 CloudFront랑 Route53이랑 붙혀주기만하면 끝난다.

Route53 -> 호스팅영역 -> 해당 호스팅 선택

레코드 생성을 눌러주자.

레코드 이름에 www 를 써주고,

레코드 유형은 "A - IPv4" 를 선택해주고,

값/트래픽 라우팅 대상은 "CloudFront 배포에 대한 별칭" 으로 해주자.

마지막으로 아까 생성한 CloudFront를 선택하고 레코드 생성을 해주자.

이제 전부 완료했다 !

1분정도 기다리고 www.도메인 을 검색해보면 정상적으로 작동할 것이다.

이제 프로젝트 기능 플로우 작성하고, 전반적인 서버 설계와 DB설계할 때쯤 분명 막힐텐데

그때 다시 머리싸매면서 해결 후, 관련 내용 포스팅을 하러 와야겠다.

[AWS] Route53 도메인 구매 및 S3 웹 호스팅

대파양파애비 — Wed, 9 Aug 2023 06:52:42 +0900

얼마전에 해커톤 멘토링을 다녀와서 서버설계와 DB설계쪽에 부족함을 느껴서

주변에 프론트엔드 1명, AI 1명, 디자이너 1명을 섭외해서 팀프로젝트를 하기로했다.

주제선정과 기능선정이 끝나서 이제 각자 맡은일을 해야하는데

나는 기획, 서버, DB, 백엔드 파트를 혼자서 전부 하기로했다.

모바일 웹/앱 서비스로 진행하기로 해서 우선 프로젝트 도메인이 필요했다.

찾아보니 시중에 도메인 판매하는 사이트도 많았지만,

회사 테크니컬 리더님께서 역량 향상 명목으로 회사 AWS계정을 사용하라고 하셨다!

그래서 한치의 고민도 없이 AWS로 접속했다.

Route 53 서비스를 검색 후 들어가서

등록된 도메인으로 들어가서, "도메인 등록"을 누르자.

그리고 사용하고 싶은 도메인주소를 검색하면 .com , .io , .net 등등 주소들과 가격이 나온다.

그중에서 원하는 도메인을 선택하고 결제진행을 해주자.

그 후 개인정보와 결제정보를 입력해서 진행해주자.

기다리면 작성한 메일로 인증링크가 메일로 오는데 링크를 눌러주자.

이제 기다리면 Route53에서 등록이 된 걸 확인할 수 있을 것이다.

이제 도메인 구매했으면 끝이지만, 배포전까지 해당 도메인에 html 파일이라도 띄워두고싶어서

S3 버킷과 연동시켜서 웹 호스팅을 하기로 했다.

그럼 이제 S3버킷을 만들어야 하는데 여기서 중요한게

연결할 도메인과 동일하게 버킷이름을 생성해 주어야한다.

리전은 서울로 해주고 아래엔 "ACL 비활성화" 로 해주자.

아래에 "퍼블릭 엑세스 차단설정" 은 모두 해제하고 퍼블릭 상태에 체크를 해주자.

그럼 이제 S3 버킷 생성은 끝났다.

이제 S3에 몇가지 설정을 변경해주어야한다.

그전에 S3에 업로드 시킬 "index.html" 파일을 준비해주자.

S3 -> 객체 -> 업로드 순서로 준비된 "index.html" 을 업로드를 해주자.

이제 S3설정을 해보자.

S3 -> 속성 탭 에서 아래로 내려서 "정적 웹 사이트 호스팅" 에서 편집을 눌러주자.

활성화, 정적 웹 호스팅에 체크를 해주고

인덱스 문서와 오류 문서에 아까 업로드한 "index.html" 을 입력해주자.

그리고 저장을 해주자.

이제 S3 -> 정책 탭에서 아래로 내려서 버킷정책으로 이동하자.

여기서 편집을 눌러주자.

버킷 ARN 을 복사하고 정챙생성기 버튼을 눌러주자.

S3 Bucket Policy , * , Amazon S3 를 차례대로 누르고

Action에서 "GetObject" 를 선택해주자.

그 아래 ARN 에서는 복사한 ARN주소를 넣어주고 뒤에 /* 를 써서 Add statement를 누른다.

그리고 만들어준 정책코드를 복사해주자.

이제 복사한 정책코드를 붙혀넣기해서 넣어주면 S3에서는 전부 다 설정했다.

S3 설정이 끝났으니 Route 53에서 호스팅영역으로 이동하자.

혹시 호스팅 리스트에 아까 도메인 구매한게 없으면, 호스팅 영역 생성을 해주자.

호스팅 영역 생성은 "구매한 도메인" 과 "퍼블릭 호스팅 영역"을 눌러주면 된다.

이렇게 생성된 호스팅 영역을 생성 후 호스팅 영역을 눌러주자.

여기서 "레코드 생성"으로 들어가주자

"단순 라우팅" 을 누르고 "단순 레코드 정의"를 눌러주자.

레코드 이름은 비워두거나 www를 써주고

레코드 유형은 A - IPv4

값/ 트래픽 라우트 대상은 S3 -> 아까 고른 서울 리전 -> 생성한 S3 버킷이 나올텐데 눌러주자.

(S3 이름을 도메인 이름과 다르게 생성시 여기서 리전을 골라도 버킷이 보이지 않는다.)

이제 단순 레코드 정의를 해주자.

그럼 드디어 끝이다 !

도메인에 들어가보면 1분안에 S3에 업로드한게 호스팅 되서 나올 것이다.

그런데 나는 시간이 지나고 지나도 작동하지 않았다....

그래서 해당 작업을 열댓번 다른케이스로 반복하고, 구글링과 GPT한테 물어봐도 답을 찾지 못했다.

결국 밤새 머리를 싸매서 해결했다.

두가지를 비교해야한다.

1. 호스팅 영역 -> 레코드 -> NS 유형의 값/ 트래픽 라우팅 대상

2. 등록된 도메인 -> 이름서버

해당 1,2 번이 동일해야지만 호스팅이 되지 않을까? 라는 생각을 했다.

등록된 도메인 -> 이름 서버편집 -> 위 2번에 있던 4개의 Url로 동일하게 맞춰주자.

그러고 1분정도 지나서 새로고침을 해보면

드디어 정상적으로 웹 호스팅이 되었다!!!

하지만 지금은 http여서 다음번에 CloudFront를 사용해서 Https로 웹 호스팅을 할 예정이다.

[Javascript] 데이터 타입_코어 자바스크립트

대파양파애비 — Mon, 7 Aug 2023 00:40:54 +0900

계획했던대로 자격증 취득도 다 해서, 8월부터는 알고리즘과 팀프로젝트에 전념할 계획이였다.

하지만 알고리즘 스터디를 하기전에 JS 기본기를 탄탄하게 다져두고 하는게 깊은 이해에 도움이 될 것 같았다.

때마침 회사 프런트 엔드 직원분들이 "모던 자바스크립트 Deep Dive" 와 "코어 자바스크립트" 두 책을 강추해주셨다.

그동안 나는 인강이 좀 더 잘 맞는다고 생각했어서, 우선 끝까지 읽기에 상대적으로 얇은 책으로 선택했다.

코어 자바스크립트

처음엔 가볍게 "혼동되는 개념만 잡고 빨리 알고리즘으로 넘어가야지. " 라는 생각뿐이였는데

1, 2 단원을 읽고 생각이 바뀌었다.

남들이 이해한 내용을 듣기만 하는게 아닌, 책을 보면서 곰곰히 고민하고 이해하는것도 잘 정리가 되었다.

그래서 단원별로 포스팅하면서 한번 더 머리속에 정리를 해보려고한다.

01. 데이터 타입

데이터 타입과 변수 선언

var a;			// 변수 a 선언
a = 'abc';		// 변수 a에 데이터 할당

var a = 'abc'; 		// 변수 선언과 할당을 한 문장으로 표현

이런 식으로 변수 선언과 데이터 할당에 대해서는 알고 있었지만 깊게 들어가 보자.

데이터 할당에 대한 메모리 변화

데이터할당에 대한 메모리 변화를 표로 살펴보자.

1. 변수 영역에서 빈 공간(@1003)을 우선 확보

2. 확보한 공간의 식별자를 a로 지정

3. 데이터 영역의 빈 공간(@5004)에 문자열 'abc'를 저장

4. 앞서 저장한 문자열의 주소(@5004)를 @1003의 공간에 대입

그리고 만약

// var a = 'abc' 
var a = 'abcdef'

이런식으로 데이터 영역에 새로운 값을 할당하면

1. 데이터 영역에 빈 공간(@5005)에 문자열 'abcdef'를 저장

2. 앞서 저장한 문자열의 주소(@5005)를 @1003의 공간에 다시 대입

이렇게 기존 문자열에 새 값이 할당되더라도 무조건 새로 만들어 별도의 공간에 저장한다.

변수와 상수를 구분 짓는 변경 가능성의 대상은 위 사진의 변수 영역 메모리이다.

변수: 한 번 할당된 데이터 영역에 재할당이 가능.

상수: 재할당이 불가능.

반면 불변성 여부를 구분 할 떄의 변경 가능성의 대상은 데이터 영역 메모리이다.

var a = 10;
var b = a;

b = 15;

/////////////////

var obj1 = { c:10, d:’ddd’ };
var obj2 = obj1;

obj2.c = 20;

해당 두 코드의 결과값 비교부터 해보자면

a !== b
obj1 === obj2

이 결과가 바로 기본형과 참조형 데이터의 가장 큰 차이점이다.

사진으로 보면 이해가 바로 될 것이다.

첫번째 case를 먼저 보면

b에 15라는 값이 할당 되는순간, 변수 영역 주소 1002에 있던 b는

데이터 영역에서 빈 주소(@5004)를 찾아서 15를 저장하고,

저장한 문자열의 주소(@5004)를 @1002의 공간에 다시 대입한다.

따라서 기본형 데이터를 복사했던 a와 b 는 이제 다른 주소를 바라보고 서로 다른 값이 된 것이다.

두번째 case를 보면

obj2의 프로퍼티를 변경해도 변수 @1003과 @1004가 바라보는 데이터 주소는 변함이 없다.

하지만 데이터 영역에 아직 20이 없으므로 새로운 공간 @5005에 저장하고,

@5002가 가리키는 변수 영역에서 다시 c를 찾아(@7103) 그곳에 @5005를 대입한다.

따라서 참조형 데이터를 복사 했던 obj1과 obj2는 여전히 같은 객체를 바라보고 있는 상태이다.

기본형 데이터: 실제 값이 저장되는 형태로, 값이 변경되면 새로운 메모리 공간에 저장.

참조형 데이터: 주소를 통해 값을 참조하는 형태로, 내부 프로퍼티가 변경되어도 참조 주소는 그대로.

var obj1 = { c:10, d:'ddd' };
var obj2 = obj1;

obj2 = { c: 15, d:'123' };

하지만 이 세번째 case를 보자.

이때 결과 다음과 같다.

 obj1 !== obj2

지금은 왜 같지 않을까?

내부의 프로퍼티를 변경한게 아니라 데이터 자체를 변경한거라서

obj2 의 변수 영역의 바라보는 주소자체가 바뀌게 된다.

따라서 obj1 과 obj2는 이제 서로 다른 주소를 바라보는 다른 값이 되어버린 것이다.

참조형 데이터가 '가변값'이라고 설명할 때의 '가변'은 참조형 데이터자체를 변경할 경우가 아니라

그 내부의 프로퍼티를 변경할 때만 성립된다. ⭐️

기본형과 참조형의 차이점과 메모리 상에서 어떻게 동작하는지 이해하면, 더욱 효과적인 코드를 작성할 수 있을 것 같다!

불변객체 이해하기

불변 객체는 한 번 생성되면 그 상태를 변경할 수 없는 객체다.

자바스크립트와 같은 언어에서는 객체에 대한 변경을 막기 위해 불변 객체를 사용하는 경우가 종종 있다.

그럼 어떻게 이게 작동하는지 살펴보자.

1. 얕은 복사(Shallow Copy)

: 객체의 첫 번째 레벨만 복사해. 나머지는 참조로 연결되므로 원본 객체에 영향을 줄 수 있다.

2. 깊은 복사(Deep Copy)

: 내부의 모든 값을 하나하나 찾아 전부 복사해서 독립된 원본을 만들어. 원본 객체에 영향을 주지 않는다.

기본형은 그대로 복사하고, 참조형은 내부의 프로퍼티들을 재귀적으로 복사해야 깊은 복사가 이루어진다.

이 깊은 복사의 예제코드를 보자.

 var copyObjectDeep = function(target){
        var result = {};  
        if(typeof target === 'object' && target !== null ){
          for(var prop in target){
            result[prop] = copyObjectDeep(target[prop]);
          }
        } else {
          result = target;
        }
      return result;
    }

좀 더 간단하게 깊은 복사를 처리 할 수 있는 JSON을 활용한 깊은 복사 코드를 보자.

var copyObjectViaJSON = function(target) {
    					return JSON.parse(JSON.stringify(target));
   						}
                        
// JSON.parse(...): 앞서 JSON 형식의 문자열로 변환된 target 객체를 다시 일반 자바스크립트 객체로 파싱한다. 
// 					그 결과로 완전히 새로운 객체가 생성된다.

객체를 Json문법으로 표현된 문자열로 전환했다가 다시JSON객체로 바꾸는 방법이다.

하지만 이 방법은 메서드나 숨겨진 프로퍼티, getter/setter 등과 같이 JSON으로 변경할 수 없는 프로퍼티는 무시된다.

그래서 순수한 정보만 다룰 때 활용하기 좋다.

null과 undefined의 차이점

1. null

타입: typeof null의 결과는 "object". 이건 JavaScript의 초기 버전에서 발생한 버그로, 지금까지 수정되지 않았다.

의미: 명시적으로 값이 없음을 나타내고 싶을 때 사용한다.

2. undefined

타입: typeof undefined의 결과는 "undefined".

의미: 변수가 선언되었지만 값이 할당되지 않았을 때 자동으로 할당되는 값.

null과 undefined는 == (동등 비교)를 사용할 경우 서로 동등하다고 간주된다.

이건 null과 undefined만의 특별한 케이스다.

=== (일치 비교)를 사용하면 null은 null과만 일치하고, undefined는 undefined와만 일치하게 된다.

var n = null;

console.log(typeof n); // "object"
console.log(n == undefined) // true
console.log(n === undefined) // false
console.log(n == null) // true
console.log(n === null) // true

null과 undefined는 비슷한 개념이지만, 다르게 취급되는 경우가 있어서,

가능한 일치 비교(===)를 사용하는 습관을 들이는 것이 좋을 것 같다.

[해커톤] 인하대 해커톤 멘토 참여후기

대파양파애비 — Sun, 16 Jul 2023 05:22:41 +0900

INHA SW NET-Zero 공동해커톤

오늘은 인하대학교에서 진행한

INHA SW NET-Zero 공동해커톤에 멘토로 참여한 후기를 포스팅 해보려한다.

나는 컴공 전공자임에도 불구하고 대학시절에 해커톤 참가를 한번도 안해봐서,

밤새면서 개발의 열정을 불태우는 분위기가 너무나 궁금했는데 이번에 우연히 기회가 생겼다.

얼마전 contect하게 된 AWS 직원분께서 해커톤 멘토로 참여 제의를 하셨다.

제의를 받고 처음엔 "내가 누군가한테 조언을 줄 수 있는 입장인가?" 라는 생각 때문에 잠시 망설였지만,

주니어 개발자로 1년간 경력을 쌓아오면서 문제를 해결했던 경험이나 다양한 트러블 슈팅 지식들이

어쩌면 밤새며 빠르게 개발을 해야하는 그들에게 도움을 줄 수 있겠다. 라는 생각이 들었다.

그래서 나는 AWS DevOps 및 Backend 개발자로 멘토단에 들어가게 되었다.

이번 NET-Zero 해커톤의 주제는 탄소중립 실천이였다.

인하대, 상명대, 경기대에서 총 20개 팀이 참여를 하였다.

20개 팀들이 단상에서 각자 선정한 주제에 대해서 1분 발표를 진행했다.

인원이 100명이 넘다보니 역시 신박한 아이디어와 좋은 의견들이 쏟아져 나왔다.

웃겨서 찍은 사진인데 역시 chatGPT는 못참지...

개발할 때 보니 거의 모든 학생들이 chatGPT를 활용하고 있더라.

하긴 요새는 얼마나 chatGPT를 잘 활용하느냐도 중요한 능력인듯 하다.

해커톤이 시작하니 다들 눈에 불을키고 으쌰으쌰하면서 개발을 하는데 너무나 멋있었다.

멘토진들은 즉각 멘토링을 해주기 위해서 선정한 주제와 설계를 살펴보며 준비를 했다.

학생들의 초반과 막바지의 주된 질문은 AWS쪽이였다.

EC2, RDS, 보안그룹, S3, Cloud9 등등..

SAA(AWS Certified Solutions Architect - Associate) 자격증은 취득하길 참 잘한것 같다.

이렇게 서버를 설계하면 좀 더 빠르고 개발 시간을 줄이는데 좋지 않을까? 라는 조언을 할 수 있게 되었다.

그리고 새벽시간에는 백엔드쪽 질문이 쏟아져 나왔다.

자바, 스프링부트, 노드, 크롤링 등등...

멘토진들은 각자 분야의 맡아서 멘토링을 담당했는데 나는 백엔드에서 노드쪽을 맡았다.

각자의 분야가 다르다보니 배울점도 많았다.

멘토링을 해주면서 내가 겪었던 문제들이 나오면 빠르게 해답을 주었지만,

나도 모르는 문제가 나오면 같이 해결하거나, 식은땀 흘리며 다른 멘토님의 힘을 빌렸다.

멘토진들 정말 똑똑한분들이 많으셔서 든든했다..!

이런 분위기 속에 있으니 정말 긍정적인 영향과 자극을 많이 받았다.

배우기도 많이 배웠고 무엇보다 열정이 정말 대단했다.

멘토진들도 식사시간에 재미삼아 모니터링 시스템도 만들기도하고 개발을 하기도하고

다들 개발에 진심인 사람들이 모이다보니 너무나 즐거웠다.

귀여운 스티커랑 크록스도 받았다ㅎㅎ

이렇게 내 맥북은 점점 더 지저분해져 간다...

이렇게 해커톤을 무사히 마치고 나서 학생들에게 멘토링 피드백을 받았다.

누구한테 도움이 된다는 건 정말 뿌듯한 일인 것 같다.

멘토진들끼리 다 같이 다음 해커톤에서도 멘토로 참석하기로 했다.

다음번 멘토링을 위해서 좀 부족한 부분을 메꾸고 나도 프로젝트를 해보려한다.

개발단계를 0 to 1 / 1 to 10 / 10 to 100 이처럼 3단계로 나누어 보았을때

그동안 회사에서 나는 주로 1 to 10 이나 10 to 100 위주의 일을 맡아서 해왔기 때문에

설계단계부터 진행하는 0 to 1 은 나한테 너무나 낯설고 어려웠다.

그래서 이참에 거창하지는 않지만 따로 개인 프로젝트를 시작해보면서 부족한 부분을 메꿀생각이다.

정말 얻은게 많은 첫 해커톤이였다.

열심히 사시는 모든 개발자분들 존경합니다.

[AWS] 국내 1호 AWS 굿즈 개봉기! (+ 개발진스)

대파양파애비 — Mon, 3 Jul 2023 22:50:07 +0900

오늘은 처음으로 개발 내용 외에 포스팅을 해보려한다.

얼마전에 SAA-C03 합격후기, 합격요약 포스팅을 올렸었는데, 혹시나 필요한 사람이 있지않을까 해서

카카오톡에 AWS Study하는 오픈채팅방이 있어서 포스팅 내용을 공유했었다.

예상외로 반응이 핫해서 고맙다는 피드백을 많이 받고 블로그 유입도 500명이 넘었다!

그러고 몇일이 지나서 아래 사진처럼 나를 찾았다.

aws study 오픈채팅방

......!

따로 갠톡을 해보니 AWS 직원분이셨고 AWS 관련 자격증 준비하는 대학생들에게 공유를 해도 될지 여쭤보셨다.

한명이라도 누군가한테 도움이 되고 싶었는데 이렇게 까지 해주시니 너무 감사한 마음뿐이였다.

보내 주신다는 굿즈도 아직 국내에 제공된 적 없는 첫 굿즈였다!!

AWS 굿즈

시간이 지나 사무실로 굿즈가 도착했다!!!

구성이 너무 알차고 예뻤다ㅠㅠ

개발진스 외 다양한 스티커, 크록스 꾸미기 셋트(?), 카드홀더, 펜슬, 손풍기, 컵 받침대 등등..

개발진스 스티커

으악 사실 이게 제일좋다...

너무 귀엽잖아?

바로 맥붙에 붙혀버렸다.

컵받침대..? 인데 물마실때마다 "나는 AWS에서 인증한 엔지니어다" 하고 마셔야겠다^^

블로그가 살짝 지루해지던 찰라였는데 이렇게 누군가한테 도움이 될 수 있겠다는 마음으로

다시 잘 정리하면서 포스팅해야겠다.

https://ilikezzi.tistory.com/48

[AWS] SAA-C03 합격후기, 핵심요약 정리 (AWS Certified Solutions Architect - Associate)

무려 한 달 만에 포스팅이다... 때는 3달전 AWS에 수많은 서비스 중에서 EC2, S3, Lambda 같은 기본적인 서비스 밖에 다룰 줄 몰랐었다. 하지만 점점 개발경력이 쌓여가면서 설계 쪽도 조금씩 맡아서

ilikezzi.tistory.com

이게 내가 예전에 SAA-C03 포스팅 한 게시물이다.

다른 많은 분들한테 도움이 됬으면 좋겠다 !

AWS 감사합니다 !

[Nest.JS] Slack에 다양한 통계데이터 알림 자동화

대파양파애비 — Sun, 2 Jul 2023 04:39:35 +0900

Slack

회사에서 협업툴로 Slack을 사용하고 있는데,

각종 통계자료 몇 로그데이터를 매일 알림으로 보내주면 좋을 것 같았다.

그래서 무슨데이터를 전송해주면 좋을지 고민하다가

1.전체 유저수 / 2.가입자수 / 3.기사 조회수 / 4.언론사별 기사 발행수 / 5.댓글수 / 6.DAU / 7.WAU

해당 7가지 데이터를 보여주기로 결정했다.

Slack bot을 통한 axios와 schedule를 사용해서 자동화를 시켜줄 것이다.

우선 Slack bot을 만들자.

https://api.slack.com/apps/

해당 URL에 접속하여 슬랙봇을 생성을 하고,

https://api.slack.com/methods

다음 URL에서 슬랙봇의 chat.postMessage 권한을 추가해 주도록 하자.

그 후 Install to Workspace 를 통해 토큰을 빠르게 발급받자.

이제 바로 Node.JS와 API 연동을 시켜보자.

우선 axios와 schedule를 사용하려면 패키지를 설치해야한다.

axios 설치

npm install axios
// or
yarn add axios

schedule 설치

npm install @nestjs/schedule
// or
yarn add @nestjs/schedule

그 후 Api를 연동시킬 모듈에 HttpModule를 추가 해야한다.

report.module.ts

그다음 아까 발급받은 Slackbot 토큰값을 추가해 줄 차례다.

src > common > apis > slack.api.ts

해당 경로에 apis 폴더와 ts파일을 추가해주자.

import axios from 'axios';

export const postMessage = async (channel: string, text: string) => {
  const params = { channel, text };
  const option = {
    headers: {
      Authorization: `Bearer 여기에 발급받은 토큰정보를 넣으면 됩니다.`, 
    },
  };

  try {
    const res = await axios.post(
      'https://slack.com/api/chat.postMessage',
      params,
      option,
    );

    console.log(res.data);
  } catch (err: any) {
    console.log(err.message);
    throw err;
  }
};

이제 Controller부로 가서 자동화 코드와 관련 데이터코드를 짜보자.

 @Cron('원하는 Cron 시간', {
    name: 'userLogData',
  })
  async userLogDataSlack() {
    // 필요한 데이터를 갖고오는 코드 작성

    const TARGET_CHANNEL = '해당 메시지를 전송할 채널명';
    const msg = `
    < ${month}월 ${date}일 NEXT Analytics >
    \n1. 전체 유저수: ${totalUser}명
    \n2. 가입자수: ${registerUser}명
    \n3. 기사 조회수: ${articleViewCount}회
    \n4. 언론사별 기사 발행수
    \n 
    \n5. 댓글수: ${totalComment}개
    \n6. DAU: ${dau}
    \n7. WAU: ${wau}
    \n
    `;
 
    postMessage(TARGET_CHANNEL, msg);
  }

관련 코드를 작성하고 import 부분을 체크해줘야한다.

마지막 라인에 postMessage 부분을 아까 slack bot 토큰파일 경로로 import 시켜야한다.

report.controller.ts

사진 속 처럼 import정보까지 변경 해 주었다면 전부 끝났다!

이제 설정해둔 @Cron 시간이 돌때까지 기다리면

SLACK

내가 설정했던 slack채널에 정상적으로 메시지가 전송된 것을 확인할 수 있을 것이다!

해당 내용을 바탕으로 다음번에는

서버에 이상이 있을시 바로 Slack에 알림 발송하는 모니터링을 만들 계획이다.

[AWS] SAA-C03 합격후기, 핵심요약 정리 (AWS Certified Solutions Architect - Associate)

대파양파애비 — Sun, 18 Jun 2023 04:50:28 +0900

무려 한 달 만에 포스팅이다...

때는 3달전 AWS에 수많은 서비스 중에서 EC2, S3, Lambda 같은 기본적인 서비스 밖에 다룰 줄 몰랐었다.

하지만 점점 개발경력이 쌓여가면서 설계 쪽도 조금씩 맡아서 하게 되고, 점차 보안 쪽도 고민을 하게 되었다.

그래서 막연히 AWS공부를 하기보다, 이참에 자격증취득을 목표로 삼고 스터디를 하면 좋을 것 같았다.

자격증 종류에 대해 알아보다가 AWS Certified Solutions Architect - Associate SAA-C03로 정했다!

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/

SAA강의 중에서 꽤나 유명한 Udemy강의로 선택했다.

할인받아서 18000원 정도에 구매하였다!

금방 완강해버릴 줄 알았지만 해당 강의는 개념설명 후 AWS에서 직접 그 서비스를 일일이 다뤄보는 방식이어서,

강의시간의 3~4배 이상 소요되었다...

그래도 직접 손으로 서비스를 다뤄봐서 이해가 되고 시험 때 까지도 기억에 남았다. (실수로 비용부과도 되었지만ㅠㅠ)

퇴근 후와 주말에 꾸역꾸역 완강을 하고 Dump문제를 EXAMTOPICS에서 풀었다.

https://www.examtopics.com/exams/amazon/aws-certified-solutions-architect-associate-saa-c03/view/

AWS Certified Solutions Architect - Associate SAA-C03 Exam – Free Exam Q&As, Page 1 | ExamTopics

A company is hosting a web application on AWS using a single Amazon EC2 instance that stores user-uploaded documents in an Amazon EBS volume. For better scalability and availability, the company duplicated the architecture and created a second EC2 instance

www.examtopics.com

270문 제까지만 무료이고 이후엔 유료여서 그냥 맘 편히 결제하고 다 풀었다.

다들 시험에 Dump문제 그대로 많이 나온다던데 나는 금붕어인가..

단순암기는 잘 못해서 해결 방식을 이해하면서 Dump 풀다 보니 시험 때 전부 풀어버렸다ㅠㅠ

이렇게 3달가량 공부하고 시험을 보러 갔다.

시험본 당일 저녁 6시쯤 AWS에서 합격 메일이 왔다!!

신나는 마음으로 AWS에 들어가 보니 합격문구와 인증서와 점수표를 볼 수 있었다!

이제 나도 AWS 솔루션 아키텍쳐다. 야호~!

그간 유데미 강의와 Dump문제를 풀면서 핵심키워드 및 전체 개념정리를 노션에 해뒀는데

해당 노션만 이해를 해도 합격하기엔 충분할 것 같아서 부족하지만 공유를 해본다.

https://ilikezzi.notion.site/AWS-Certified-Solutions-Architect-Associate-SAA-C03-f03e5df55da148009339c7a4fb0e48cc?pvs=4

AWS Certified Solutions Architect - Associate SAA-C03 ‍

ilikezzi.notion.site

다들 빠이팅

[Mysql] max_connection_errors 해결

대파양파애비 — Sun, 14 May 2023 21:37:36 +0900

오늘은 협업 업체에서 사내 DB에 연결 시에 max_connect_errors 관련 에러가 뜬다고 해서,

관련내용을 포스팅해보려고 한다.

참고로 나는 블랭 아니고 블랑이다...

맥주 블랑을 좋아해서 입사할 때 영어이름을 Blanc으로 정했는데 그 뒤로 블랑 쳐다도안본다... ^^

아무튼 이처럼 DB접속이 불가능 하고, max_connection_errors 수치 변경을 요청하셨다.

아마도 이런 에러가 나왔을 것이다.

ERROR 1129(00000): Host '*' is blocked because of many connection errors.
Unblock with 'mysqladmin flush-hosts

이제 max_connection_errors 가 뭔지 알아보자.

max_connection_errors는 권한이 없거나 문제가 있는 클라이언트로부터 데이터베이스 서버를 보호하는 데 사용된다.

이는 서버가 해당 호스트를 차단하기 전에 호스트에서 허용되는 연속 중단된 연결 시도 횟수를 지정한다.

오류로 인해 클라이언트가 서버에 연결하지 못하는 경우 서버는 해당 클라이언트의 호스트에 대한 오류 수를 증가시킨다.

오류 수가 값에 도달하면 max_connection_errors 서버는 해당 호스트로부터의 추가 연결을 차단한다.

성공적인 연결은 오류 수를 0으로 재설정하게 된다.

그럼 여기서 무작정 수를 높히면 되지 않을까? 라는 생각이 들 수도 있다.

값을 너무 높게 설정하면 서버가 잠재적인 무차별 암호 대입 공격에 노출될 수 있고,

너무 낮게 설정하면 몇 가지 네트워크 문제가 발생한 후 정상적인 클라이언트 도 차단할 수 있다.

따라서 적당한 값으로 설정하는데 알아보니 대부분 10000으로 설정하는것 같다.

원인을 알았으니 이제 해결을 해보자.

1. SSH를 통해 해당 EC2인스턴스에 연결한다.

2. 텍스트 편집기로 Mysql 구성파일을 연다.

MySQL의 경우 구성 파일은 일반적으로 /etc/mysql/mysql.conf.d/mysqld.cnf 에 있다.

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

3. 구성 파일의 섹션[mysqld]에서 max_connection_errors 설정을 추가하거나 업데이트한다.

[mysqld]
...
max_connection_errors = 10000

4. 텍스트 편집기를 저장하고 종료한다.

CTRL + X -> Y -> Enter

5. Mysql 서비스를 다시 시작한다.

sudo service mysql restart

이제 데이터베이스 서버에 정상적으로 접속할 수 있을 것이다!

[Typescript] Eslint로 저장 시 사용하지 않는 import 제거

대파양파애비 — Tue, 9 May 2023 22:20:08 +0900

바쁘게 개발을 하다보니 코드상에 사용하지 않는 import들이 너무나 쌓여버렸다...

'press' is defined but never used.

사진 속 코드처럼 사용하지 않는 import들이 있다.

일일히 지우기엔 너무 양이 많고 앞으로도 쌓일 가능성이 있어서 Eslint로 저장 시에 지워지게 할 것이다.

eslint 설치부터해서 적용법까지 해보자.

npm i eslint --save-dev

해당 명령어로 eslint를 설치한다.

npm install eslint-plugin-unused-imports --save-dev

그리고 import제거하는 플러그인을 설치한다.

{
	"plugins": ["unused-imports"]
}

{
	"rules": {
		"@typescript-eslint/no-unused-vars": "off",
		"unused-imports/no-unused-imports": "error",
		"unused-imports/no-unused-vars": [
			"warn",
			{ "vars": "all", "varsIgnorePattern": "^_", "args": "after-used", "argsIgnorePattern": "^_" }
		]
	}
}

.eslintrc 파일에 두가지 코드를 추가해 준다.

그럼 끝이다!

이제 저장을 하면 알아서 사용하지 않는 import가 제거된 것을 확인할 수 있을 것이다.

[Nest.JS] TypeOrm에서 페이지네이션 구현 (last_id, size)

대파양파애비 — Fri, 5 May 2023 03:35:43 +0900

오늘은 백엔드 개발에 있어서 필수적이라 생각하는 페이지네이션에 대해서 포스팅을 해보려고 한다.

우선 페이지네이션에 대해서 간략하게 설명하자면,

흔히 페이지수(쪽수)를 매기로 정렬할 떄 쓰이는 개념으로써 웹에서 자주 다루게 된다.

나도 마찬가지도 이번 프로젝트 개발을 하면서 페이지네이션을 상당히 많이 사용하였다.

댓글 목록
투표 목록
팔로잉 목록
차단 목록
북마크 목록
선물함 목록
포인트 내역 목록
이벤트 목록
내가 본 뉴스 목록
알림 목록
등등..

이 처럼 거의 대부분에 목록(@GET) 에서는 페이지네이션을 사용하였다.

우선 알림쪽을 사진으로 간략하게 보자.

알림

해당 사진은 알림 목록 쪽 사진인데, 아래로 스크롤하면서 10개씩 끊어서 로딩해서 보여주게끔 해준다.

즉, 한번에 많은 양을 로딩해서 보여주는것이 아니라서 데이터적인 측면에서도 성능에 도움이 된다.

구글링을 해보면 대부분 "skip"과 "take"를 사용해서 페이지네이션을 하였으나,

나는 "last_id"와 "size"로 페이징 처리를 진행하였다.

알림목록 코드를 통해서 하나씩 살펴보자.

controller 부

해당 controller부에서 @Query dto에 "last_id"와, "size"를 넣어준다.

description에 나와있드시

last_id : 가장 마지막으로 보낸 알림 아이디

size : 한번에 보여질 알림 수

service 부

모자이크 부분은 페이지네이션과 관련없는 코드이니 무시해도 된다.

위에서 부터 한줄한줄 살펴보자.

변수 notificationEntity를 선언하고 Repository.find() 로 넘어가보자.

Repository 부

해당 레파지토리에서는 쿼리빌더로 find를 한다.

눈여겨 볼 부분은 직전에 controller에 @Query에 dto안에 넣었던 last_id가 존재하면,

notification.id 는 last_id보다 작은 수를 갖는다.

왜냐?

정렬이 DESC로 내림차순이여서 id는 last_id보다 작은 수를 가져야지 페이지네이션이 순차적으로 이뤄진다.

그리고 dto에 있는 size값은 말 그대로 페이지 size여서 limit를 걸어주면 된다.

이제 다시 service부로 돌아가 보자.

service 부

자, 이제 변수 notificationEntity를 구했으니 아래로 내려가 보자.

아래에 last_item_id는 페이지네이션을 이어서해주기 위해서 필요한 값이다.

무슨말이냐면, 예를들어 notificationEntity의 id가 [100,99,98 ... 92,91] 일 경우에

last_item_id의 값은 91이 된다.

그래야지 이 last_item_id 값이 다음 페이지의 last_id값으로 들어가면서 페이지네이션이 이루어진다.

이러면 이제 다음 페이지의 notificationEntity의 id는 [90,89,88, ... 82,81]로 이어진다.

그리고 notificationEntity가 빈배열이면 0으로 출력한다.

이제 마지막 리턴값을 보면,

last_item_id 까지 같이 응답값으로 주기위해서 Response.dto를 만들었다.

response.dto.ts

해당 response dto파일은 이 알림 목록 외에도 대부분 리턴값으로 사용되고 있어서

그냥 결과값과, last_item_id를 같이 출력해 주기위해 사용한다고 보면된다.

이제 Swagger에서 확인해 보자.

Swagger

알림 Swagger가 정상적으로 만들어 졌을것이다.

여기에 첫 페이지네이션이라 last_id는 비워두고 size는 10으로 줘보자.

size: 10

다음과 같이 10개의 값이 나오고 맨 아래에 "last_item_id" 가 473으로 나왔다.

앞서 말했듯이 이 값은 10개의 값중에 가장 작은 id값이다.

다음 페이지를 보려면 last_id에 473을 넣으면 정상적으로 다음 10개의 값이 출력될 것이다.

2페이지

이제 프론트엔드에서 작업을 하면 웹 상에서 10개씩 물흐르듯이 페이지네이션이 될 것이다..!

[Mysql] 여러행의 데이터를 한 행의 데이터로 합치기 "GROUP_CONCAT"

대파양파애비 — Mon, 1 May 2023 20:09:23 +0900

오늘은 Mysql에서 여러행의 데이터를 한 행의 데이터로 합치는 쿼리에 대해서 알아보자.

우선 각각의 테이블에 대해서 대략적으로 살펴보자.

blanc_story_log

blanc_keyword_news

위 두 테이블은 간단하게 설명하자면,

blanc_story_log 테이블은 뉴스의 정보가 담긴다고 보면 되고, ( "action" 컬럼에 "view" or "create" 존재)

blanc_keyword_news 테이블은 해당뉴스의 키워드가 담긴다. (같은 뉴스에 키워드 최대 5개)

이런구조에서 두 테이블을 조인해서 뉴스가 생성 되었을때,

뉴스의 키워드 정보를 한 개의 uuid로우에 여러 키워드를 담고 싶었다.

우선 정답을 보고 쿼리를 하나씩 파헤쳐 보자.

SELECT t1.uuid AS id_post,
 t1.user_uuid AS id_usr,
 t1.news_uuid AS cts, 
t1.press_uuid AS id_press, 
GROUP_CONCAT(DISTINCT t2.keyword SEPARATOR ', ') AS keywords, 
DATE_FORMAT(t1.created_at, '%Y%m%d%H') AS day_str 
FROM blanc_user_story_log t1 JOIN blanc_keyword_by_news t2 ON t1.news_uuid = t2.uuid 
WHERE t1.action = 'create' 
GROUP BY t1.uuid, t1.user_uuid, t1.news_uuid, t1.press_uuid, DATE_FORMAT(t1.created_at, '%Y%m%d%H');

우선 SELECT로 "id_post", "id_usr", "cts", "id_press" 4 개의 컬럼을 Alias해서 갖고오고

GROUP_CONCAT()을 활용하여 아래에서 GROUPING한 키워드를 한개의 로우로 합쳐셔 갖고 온다.

GROUP_CONCAT() 안에 있는 조건에 대해서 보면,

DISTINCT는 말그대로 혹시 모를 중복된 키워드가 들어옴을 방지하기 위해 사용했고,

SEPARATOR는 각각의 키워드의 구분기호로 보면 된다.

요구사항이 ", " 이런식으로 키워드를 띄워야 했어서 사용했다.

DATE_FORMAT은 아래 사진처럼 시간 데이터가 오고있어서,

기존 created_at 컬럼

'%Y%m%d%H' 이 형태대로 "년 월 일 시간" 네가지 데이터만 뽑았다.

그 다음 두 테이블을 t1의 target_uuid 와 t2의 uuid로 INNER JOIN을 했다.

그리고 WHERE절 에는 t1의 action이 "create"일때로 조건을 걸어준다.

마지막으로 GROUP BY를 사용하여 t2의 키워드 컬럼을 제외한 t1의 모든 컬럼을 그룹핑해준다.

한가지 컬럼이라도 그룹핑을 하지 않게 되면 다음과 같은 에러문구가 발생한다.

Error (모자이크 부분은 DB이름이다.)

1055 - Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'next_newming_statistics.t1.uuid' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

GROUP BY를 사용하는 경우, SELECT할 수 있는 컬럼은 GROUP BY에 나열된 컬럼과 SUM(), COUNT() 같은 집계 함수(Aggregation Function)으로 한정 sql 표준 문법은 group by 사용시 select 의 칼럼중 집계함수에 쓰이는 것을 제외한 모든 칼럼을 기입해야 한다.

이 에러의 경우 세가지 방법이 있는데,

첫째 내 쿼리대로 관련 컬럼을 모두 그룹핑을 해준다.

둘째 비 집계 칼럼에 ANY_VALUE() 함수 사용한다.

셋째 mysql 설정 변경 (sql_mode 에서 ONLY_FULL_GROUP_BY 설정을 뺀다.)

나는 협업 업체에 쿼리문을 줘야되는 상황이여서 1번 방법을 사용해서 관련 컬럼을 모두 작성 하였다.

이제 쿼리를 돌린 데이터를 확인해보자.

쿼리 결과가 내가 원하는 대로 keywords가 한개의 로우에 합쳐져서 나오는 걸 볼 수 있다.

[Nest.JS] DTO vs Interface

대파양파애비 — Sun, 23 Apr 2023 04:26:39 +0900

벌써 일주일이나 포스팅을 하지 못했다.

개발중인 서비스 런칭일이 한달도 남지않아서 UnitTest랑 QA랑 협업업체 대응 하느라 정신이없다...

한달전에 내가 개발한 코드를 보면 왜 이렇게 짰나 어질어질하다.

그만큼 가파르게 성장하고 있다는 반증인 것 같아서 내심 뿌듯하기도 하다 ^__^

본론으로 돌아와서 프로젝트를 하면서 자주 사용하지만 그 차이점을 제대로 모르고 사용했던게 있다.

바로 DTO 와 Interface 이다.

두개가 비슷하다고 생각해서 이 케이스에서는 둘중에 뭘 쓰는게 맞는거지? 하고 고민했던적이 많았다.

오늘 두개의 비슷한 점과 명확히 다른점에 대해 알아보고 제대로 이해를 해 볼 것이다.

DTO란?

말그대로 Data Transfer Object, 계층간 데이터 교환을 위해 사용하는 객체이다.

= 데이터를 담아서 전달하는 바구니

계층은 Repository패턴에서는 Controller, Service, Repository,

MVC패턴에서는 Model, View Controller 를 뜻한다.

계층간 데이터를 주고 받을때 어떤모양의 데이터 객체로 주고 받을지를 결정하게 되므로 설계 시 우선순위다.

엔티티는 절때로 요청이나 응답값을 전달하는 클래스로 사용하면 안되므로,

다른 클래스들에게 영향을 끼치지 않고 자유롭게 변경할 수 있는 DTO를 사용해야만 한다.

쉽게 말해서 데이터를 주고받을 객체의 타입을 체크해주기 위한 구조라고 하면 될 것이다.

이는 데이터 무결성을 유지하고 보안 취약성을 방지하는 데 크게 도움이 된다.

Interface란?

상호간에 정의한 데이터의 약속 혹은 규칙을 말한다.

TypeScript에서 변수, 함수, 클래스의 타입 체크를 위해 사용된다.

클래스와 유사하지만 인스턴스 생성이 불가능하고 모든 메소드는 추상 메소드로 이루어져 있다.

하지만 ES6에서 지원하지 않고 Typescript에서만 지원한다.

좀 더 자세히 알아보기 위해서 NestJS공식문서를 흝어보았는데,

타입체크를 위해서 DTO 사용을 안내하고 있다.

NestJS 공식문서 Request payload

왜 하필 DTO로 안내를 하고 있는걸까?

아...!

방금 인터페이스 특징을 알아볼때 왜 NestJS에서 DTO사용을 안내하는지 나왔었다.

인터페이스는 ES6에서 지원하지 않아서, Javascript에서는 컴파일 도중 인터페이스가 제거된다.

따라서 NestJS의 런타임에 인터페이스를 참조할 수 없게 된다.

반면 DTO는 Class로 작성되기에 ES6표준이므로 참조 및 데이터타입을 지속적으로 추적이 가능하다.

이제 두개의 차이점에 대해서 더 알아보자.

DTO는 클라이언트와 서버 간에 전송되는 데이터에 중점을 두는 반면,

인터페이스는 개체의 구조와 응용 프로그램 내에서 예상되는 동작을 정의한다.

이렇게 서로 타입을 지정해주는 유사성이 있지만, 서로 관점이 다르다고 생각하면 되겠다.

코드로 한번보자.

DTO

해당 DTO는 응답값의 데이터 타입을 정의하는데에 사용되었다.

앞서 정리 했던대로 계층간의 데이터를 주고받을때 어떤 모양의 데이터 객체로 주고 받을지 정했다고 보면 된다.

Interface

뉴스컨트롤러부와, 투표컨트롤러부에서 같은방식으로 랭킹을 구하기 위해서

랭킹서비스부로 넘어가게 되는데 이때 RankingInterface로 어떠한 데이터를 넘길지 약속을 해주는 의미로

인터페이스를 사용하고 있다.

한마디로 DTO 및 인터페이스는

데이터의 모양을 정의하고 애플리케이션의 여러 부분이 특정 조건을 준수하도록 하여,

깨끗하고 일관된 코드를 유지하는데 도움이 된다.

마지막으로 내가 왜 비슷하다고 느꼈는지에 대해서 정리해보자면

1. 추상화

DTO와 인터페이스 모두 소프트웨어 시스템에서 추상화를 촉진(?)한다.

DTO는 여러 데이터 조각을 단일 개체로 캡슐화하여 데이터의 추상 표현을 제공하는 반면,

인터페이스는 특정 동작을 구현하는 클래스에 대한 추상 계약을 정의한다.

2. 모듈성

두 개념 모두 소프트웨어 설계의 모듈성에 기여한다.

DTO는 구성 요소의 내부 작업을 노출하지 않고 서로 다른 계층 또는 구성 요소 간에 데이터를 전달한다.

인터페이스는 구현할 클래스에 대한 계약을 정의하여 모듈식 설계를 가능하게 한다.

3. 유지 관리성 향상

DTO와 인터페이스는 모두 코드를 보다 유지 관리하기 쉽게 한다.

DTO는 계층 또는 구성 요소 간의 데이터 전송을 단순화하여 코드를 쉽게 리팩토링하거나 업데이트할 수 있도록 한다.

인터페이스는 공통 계약을 정의함으로써 우려사항을 명확하게 분리하고 코드 재사용성을 촉진하여,

시스템의 특정 부분을 쉽게 업데이트하거나 교체할 수 있다.

[Nest.JS] Axios, Http 비동기 통신 라이브러리

대파양파애비 — Sat, 15 Apr 2023 00:08:27 +0900

요새 외부업체들과 협업이 잦아지면서 API를 연동 시키기 위해 Axios를 많이 사용하고 있다.

그래서 이 참에 Axios에 대해서 제대로 알고 사용할 겸 포스팅을 해보려고 한다.

우선, Axios란 ?

Http클라이언트 라이브러리로서, 웹 애플리케이션에서 웹 API와 통신하는 데 사용되며,

웹 브라우저와 Node.js 환경 모두에서 사용할 수 있다.

1. Promise 기반

Axios는 Promise 기반으로 작성되어 있어서, 콜백 대신 .then()과 .catch() 또는 async/await를

사용하여 비동기 작업을 처리할 수 있다 .

이를 통해 비동기 작업을 처리 시, 코드의 가독성과 유지 관리성이 향상된다.

2. HTTP 메서드 지원

Axios는 다양한 HTTP 메서드 (GET, POST, PUT, DELETE, PATCH)를 사용하여 웹 API와 통신할 수 있다.

특정 메서드를 사용하려면 axios 객체의 메서드를 호출하면 된다.

ex) axios.get(), axios.post(), axios.put(), axios.delete()

3. 요청 및 응답 헤더 설정

Axios를 사용하여 요청과 응답 헤더를 쉽게 설정하고 가져올 수 있다.

요청 헤더를 설정할 때는 headers 옵션을 사용하며, 응답 헤더는 response.headers 객체를 통해 접근할 수 있다.

예를 들어, 헤더에 인증 토큰을 추가하는 방법은 다음과 같다.

new.service.ts

이런식으로 헤더안에 Authorization: 으로 관련 인증 토큰값을 넣으면 된다.

4. 요청 및 응답 데이터 처리

Axios는 요청 및 응답 데이터를 쉽게 처리할 수 있는 기능을 제공한다.

기본적으로 요청 및 응답 데이터는 JSON 형식으로 자동 변환되며

사용자 정의 데이터 변환기를 사용하여 요청 및 응답 데이터를 변환할 수도 있다.

5. 요청 취소 및 중복 요청 처리

Axios에서는 요청을 취소할 수 있는 CancelToken을 지원한다.

이를 활용하여 이미 시작된 요청을 취소할 수 있고, 서버의 부하를 줄일 수 있다.

6. 타임아웃 및 에러 처리

Axios는 요청에 대한 타임아웃을 설정할 수 있으며, 타임아웃이 발생하면 에러를 자동으로 처리한다.

또한, 네트워크 오류, 서버 응답 오류 등 다양한 종류의 에러를 적절하게 처리할 수 있는 기능을 제공한다.

이제 Axios 사용방법에 대해서 알아보자.

npm install axios

NestJS에서 Axios를 사용하려면 다음 명령을 사용하여 설치해야 한다.

이제 Axios를 활용한 간단한 예제 코드를 보자.

1. Get

이런식으로 간단하게 headers의 값만 넣어서 get요청을 할 수 있다.

2. Post

Req 값으로 "id_usr"를 넣어야 해서 url 뒤에 넣어주면 정상적으로 post가 작동한다.

3. 요청 및 응답 인터셉터

const axios = require('axios');

// 요청 인터셉터
axios.interceptors.request.use((config) => {
  config.headers['Authorization'] = 'Bearer YOUR_ACCESS_TOKEN';
  return config;
}, (error) => {
  return Promise.reject(error);
});

// 응답 인터셉터
axios.interceptors.response.use((response) => {
  if (response.status === 200) {
    console.log('Request successful');
  }
  return response;
}, (error) => {
  if (error.response.status === 401) {
    console.log('Unauthorized');
  }
  return Promise.reject(error);
});

axios.get('https://google.com/posts')
  .then((response) => {
    console.log(response.data);
  })
  .catch((error) => {
    console.error(error);
  });

4. 요청 취소

const axios = require('axios');

const CancelToken = axios.CancelToken;
const source = CancelToken.source();

axios.get('https://google.com/posts', {
  cancelToken: source.token,
})
  .then((response) => {
    console.log(response.data);
  })
  .catch((error) => {
    if (axios.isCancel(error)) {
      console.log('Request canceled:', error.message);
    } else {
      console.error(error);
    }
  });

// 요청 취소
source.cancel('Operation canceled by the user.');

5. 타임아웃 설정

const axios = require('axios');

axios.get('https://google.com/posts', {
  timeout: 1000, // 1초 이내에 응답이 없으면 타임아웃
})
  .then((response) => {
    console.log(response.data);
  })
  .catch((error) => {
    if (error.code === 'ECONNABORTED') {
      console.log('Timeout error:', error.message);
    } else {
      console.error(error);
    }
  });

[Javascript] null 병합연산자 "??"

대파양파애비 — Tue, 11 Apr 2023 21:52:34 +0900

오늘은 병합연산자 "??" 에 대해서 포스팅 해보려고 한다.

?? 예시를 보면 바로 이해가 갈 것이다.

A ?? B

A가 null 또는 undefined이면 B

그게 아니라면 A

이게 전부다.

이걸 언제쓰면 유용한지 알아보자.

notice.query.repository.ts

dto.last_id가 null이거나 undefined일때 0으로 변환해서 이후 0과 대소 비교를 하는 코드다.

이처럼 숫자 0을 구분 지어 다뤄야 할때 아주 유용하다.

comment.service.ts

또 이런 dto.parent_uuid에 대한 이런 구구절절 말도안되는 코드도

dto.parent_sort_depth = dto.parent_uuid ?? 0

이렇게 한줄로 끝내버릴수 있다.

이처럼 0 외에도 기본값을 할당하는 좋은 용도로 사용할 수 있다.

[Nest.JS] DTO 객체의 키 이름 변경 @Transform

대파양파애비 — Thu, 6 Apr 2023 22:51:32 +0900

오늘은 DTO 객체의 키 이름을 @Transform 데코레이터를 사용하여 바꾸는 방법에 대해 포스팅을 할 것이다.

음,, 이렇게만 얘기해서는 무슨소린지 헷갈리니 바로 예제 코드로 보자.

findBookmark=[
  {
    target_uuid: 123,
    name: Blanc,
    ...
  },
  {
    target_uuid: 234,
    name: Jack,
    ...
  },
  {
    target_uuid: 345,
    name: Scott,
    ...
  }
]
 
 /////////////////////////////
 
BookmarkReadDto={
  @Expose()
  @ApiProperty()
  uuid: string;
  
  @Expose()
  @ApiProperty(
  name: string;
  
  ...
}

변수 findBookmark : [] 와 BookmarkReadDto가 해당 코드처럼 각각 존재한다.

나는 Response값으로 BookmarkReadDto 형태가 필요하므로 plainToInstance로 매핑을 해줘야 한다.

객체를 원하는 형태의 DTO로 매핑 시켜줄 수 있는 plainToInstance에 대한 설명이 있으니

한번 읽어보면 도움이 될 것이다...!

https://ilikezzi.tistory.com/9

[Nest.JS] class-transform의 plainToInstance를 활용한 Object Mapping

Class-transform을 다루기전에 Model Mapper에 대해서 먼저 대략적으로 알아보자. Model Mapper 이 Model Mapper란 쉽게 말해 object에 필드값을 원하는 모양의 object로 매핑시켜주는 라이브러리다. Typescript에서 Mo

ilikezzi.tistory.com

다시 본론으로 돌아와서, 우선 매핑을 시켜보자.

bookmark.service.ts

이런식으로 plainToInstance를 사용하여 매핑을 시켜주었으나, 여기서 고민이 생겼다.

기존 findBookmark에 있는 객체의 target_uuid 라는 key값을

매핑한 BookmarkReadDto의 객체의 uuid 라는 key값으로 변경해서 사용해야했다.

그래서 강제로 for문을 돌면서 map함수를 사용해서 findBookmark의 target_uuid값을 추출해서

새로운 BookmarkReadDto의 uuid key값을 가진 객체에 넣을까 했는데

너무 비효율적인것 같아서 다른방법을 찾게 되었다.

이때 찾게 된게 DTO에서 @Transform 데코레이터 사용이다.

bookmark.dto.ts

이렇게 해당 DTO파일에서

@Transform(({ obj }) => obj.target_uuid)

한줄만 추가해주면 끝이다.

@Transform 데코레이터가 uuid 속성에 적용된다.

데코레이터는 원래 개체를 나타내는 obj 속성을 포함하는 개체를 사용한다.

그런 다음 원래 개체의 target_uuid 속성을 반환하고,

이렇게 하면 DTO를 사용할 때 uuid 속성이 target_uuid 값으로 설정된다.

굉장히 간단하면서 편리하다..!

이제 매핑한 bookmarkReadDto를 콘솔을 찍어보자.

bookmarkReadDto=[
  {
    uuid: 123,
    name: Blanc,
    ...
  },
  {
    uuid: 234,
    name: Jack,
    ...
  },
  {
    uuid: 345,
    name: Scott,
    ...
  }
]

내가 원했던대로 key값이 target_uuid --> uuid 로 잘 바뀐걸 확인할 수 있을것이다.

[AWS] AWS 사용량 예산 초과 시 이메일로 알림 받기

대파양파애비 — Sun, 2 Apr 2023 15:35:14 +0900

오늘은 AWS 예산 초과 시 이메일로 알림받는 법에 대해 포스팅을 할 것이다.

AWS 클라우드 서비스를 사용하다보면 예상치 못한 사용량 급증이나,

혹시 모를 엑세스키 해킹을 통한 요금 폭탄을 맞을 수 있으므로 필수적으로 해주는게 좋다.

우선 루트 계정 외에 IAM 관리자계정으로 하려면, 루트계정에서 권한을 변경을 해줘야한다.

루트계정으로 로그인해서 My account에서 내려보면

결제 정보에 대한 IAM 사용자 및 역할 액세스가 있을 것이다.

이부분에서 IAM 액세스 활성화 버튼을 눌러서 업데이트를 해주면,

관리자인 IAM 사용자가 청구데이터에 접근할수 있게 된다.

이제 권한을 설정을 변경하였으니 관리자인 IAM사용자나, ROOT계정 모두 진행할 수 있다.

이제 Budgets으로 이동해보자.

예산 생성으로 이동하자.

템플릿 사용을 권장하고,

프리티어 사용자는 제로지출예산, 아닌경우는 월별 비용 예산을 눌러준다.

그리고 자신이 원하는 예산 금액과, 알림받을 이메일을 입력해준다.

이제 설정 지출금액에 85%에 도달했을때와,

실제 지출의 100%에 도달할경우,

예상 지출이 100%에 도달할 것으로 예상되는 경우에 알림을 받게 됩니다.

[Javascript] split() 지정 구분기호로 문자열을 배열로 분할

대파양파애비 — Thu, 30 Mar 2023 02:08:23 +0900

오늘은 문자열을 원하는 지정구분 기호로 배열로 분할하는 법에 대해서 알아보자.

케이스는 이러하다.

DB "sort_depth" 컬럼

관련 DB에 sort_depth라는 컬럼이 존재하는데 해당 값들은 string으로 이루어져 있다.

나는 사진에 아랫쪽에 있는 "118,121,122,123" 의 크기(길이?)를 구해 4라는 값을 얻고 싶었다.

그럼 우선 배열로 변환한 다음, length()를 사용하여 크기를 구할 계획이다.

여기서 배열로 변환할때 " , " 이 콤마 단위로 구분을 해서 넣어 줘야되는데

이때 split()를 사용하면 간단하다.

split()이란?

지정된 구분 기호에 따라 문자열을 하위 문자열 배열로 분할할 수 있는 내장 JavaScript 문자열 메서드이다.

사용법은 간단하다.

const str = "118,121,122,123";
const arr = str.split(","); // ,로 분할 하겠다.

console.log(arr); // outputs ["118", "121", "122", "123"]

이런식으로 사용해주면 쉽게 배열로 분할 할 수 있다.

그 다음 배열 arr을 "arr.length"를 사용하면 원하는 문자열의 크기를 구할수 있다.

service부 관련코드

[NestJS] DB커넥션을 최소화하고 Service부에 부하를 줘야하는 이유.

대파양파애비 — Mon, 27 Mar 2023 23:18:32 +0900

오늘은 별건 아니고, 배포중인 어플에서 뉴스 댓글 목록을 불러올때 2~3초 가량 소요되서

이 코드를 리팩토링 하였다.

리팩토링은 왜 할까 ?

1. 성능향상, 가독성 향상

2. 유사한 내용이 반복될때 코드의 중복 제거

3. 새로운 기능을 추가할 때

위 세가지 이유가 제일 핵심적인 이유다.

기존 코드를 Swagger에서 돌려 보았을때 두 눈을 의심했다.

이게 목록 불러오는 @Get API를 단 한번 실행 시킨것이다....

물론 Response값으로 다양한 값이 필요하긴 하지만 이건 말이 안된다.

이러니 목록 불러올때 2~3초 가량 로딩시간이 걸렸던 것이다.

실행된 사진 속 쿼리문을 보니 중복된 테이블에서 SELECT가 여러번 이루어 지는걸로 보아

for문을 돌면서 그 안에서 DB커넥션이 여러번 이뤄지고 있는 것 같다.

성능관점에서 DB커넥션수를 최소화하고 Service부에 부하를 가하는게 훨씬 좋다.

왜냐?

첫째. 성능

각 데이터베이스 연결은 메모리, CPU 및 네트워크 대역폭과 같은 리소스를 소비한다.

연결 수를 줄임으로써 오버헤드를 최소화하고 애플리케이션의 성능을 향상시킬 수 있다.

이렇게 하면 애플리케이션이 과부하 상태에서도 응답성을 유지하는 데 도움이 될 수 있다.

둘째. 확장성

애플리케이션이 커짐에 따라 데이터베이스에 대한 동시 연결 수가 증가할 수 있는데,

연결 수를 줄이면 애플리케이션이 효율적으로 확장되고 데이터베이스에서 부과하는 제한 없이 더 많은 사용자를 수용할 수 있다.

셋째. 연결 Pool 고갈

많은 데이터베이스에는 동시에 처리할 수 있는 최대 연결 수가 있다.

이 제한에 도달하면 새 연결 요청이 대기하거나 거부되어 애플리케이션에서 지연 또는 오류가 발생한다.

연결 수를 줄이면 연결 풀이 고갈되는 것을 방지하고 애플리케이션을 안정적으로 유지할 수 있다.

넷째. 비용 절감

스팅 공급자와 클라우드 서비스는 종종 사용하는 데이터베이스 연결 수에 따라 요금을 부과하기도 한다.

연결 수를 줄이면 호스팅 비용도 절약할 수 있다.

이정도면 필수적으로 해야되는게 맞는것 같다.

그래서 Service부에서 필요한 DB커넥션은 최소화하면서 불필요한 쿼리 최대한 로직으로 풀어서 리팩토링을 하였다.

리팩토링을 다 하고 Swagger에서 동일하게 코드를 실행시켰더니

이 말도안되는 차이,,,,,

배포를 하고 댓글 불러오는 부분에서 로딩시간이 걸렸던것도 완전히 사라졌다.

앞으로도 DB커넥션은 무조건 최소화하고 불 필요한 쿼리수는 줄이도록 하자.

[Javascript] "some()" 배열의 객체에 원하는 값이 있으면 True 반환

대파양파애비 — Sat, 25 Mar 2023 22:50:15 +0900

Javascript에서 배열의 요소를 순차적으로 순회하면서 특정 조건을 만족하는지 체크하는

some()함수를 다룰 것이다.

some함수의 특징은

- true를 만족하는 요소를 찾을 때까지 callback 함수를 실행한다.

- 만족하는 요소가 없거나 빈 배열인 경우 false를 반환한다.

- 처리하는 요소의 범위는 callback 함수의 첫 호출 전에 설정된다.

likeTotal이라는 배열안에 객체의 "user_uuid"라는 key값에, "user"라는 value값이 있으면 true를 반환 하고 싶었다.