kyun 기술 블로그

Promise.all 과 Promise.allSettled 직접 구현해보기

kyuuuun — Mon, 20 Oct 2025 16:52:28 +0900

Promise.all 의 익숙함의 속아 소중함을 잃지 말고 직접 구현해보기

// 모든 Promise가 성공하면 결과 배열을 반환하고,
// 하나라도 실패하면 즉시 reject 
const promiseAll = (promises) => {
  const result = [];

  return new Promise((resolve, reject) => {
    let completeLen = 0; // 완료된 Promise 개수

    for (let i = 0; i < promises.length; i++) {
      // Promise가 아닐 수도 있으니 안전하게 감싸기
      Promise.resolve(promises[i])
        .then((res) => {
          result[i] = res;       // 인덱스 순서대로 결과 저장
          completeLen += 1;      // 완료 개수 증가

          // 모든 Promise가 성공하면 resolve
          if (completeLen === promises.length) {
            resolve(result);
          }
        })
        .catch((err) => {
          // 하나라도 실패하면 즉시 reject
          reject(err);
        });
    }
  });
};

// 모든 Promise가 완료될 때까지 기다리고
// 각 결과를 { status, value/reason } 형태로 반환
const promiseAllSettled = (promises) => {
  if (promises.length === 0) return Promise.resolve([]);

  const result = [];
  let completeLen = 0;

  return new Promise((resolve) => {
    for (let i = 0; i < promises.length; i++) {
      Promise.resolve(promises[i])
        .then((res) => {
          // 성공한 경우
          result[i] = { status: 'fulfilled', value: res };
          completeLen += 1;
        })
        .catch((err) => {
          // 실패한 경우
          result[i] = { status: 'rejected', reason: err };
          completeLen += 1;
        })
        .finally(() => {
          // 모든 Promise가 settled(성공 또는 실패) 상태가 되면 resolve
          if (completeLen === promises.length) {
            resolve(result);
          }
        });
    }
  });
};

// 테스트
const p1 = Promise.resolve(1);
const p2 = Promise.resolve(2);
const p3 = Promise.reject('에러 발생');

const promises = [p1, p2, p3];

promiseAllSettled(promises)
  .then((res) => console.log(res))
  .catch((err) => console.log(err));

Next.js App Router에 FSD(Feature-Sliced Design)를 곁들인..- FSD 도입기

kyuuuun — Tue, 23 Sep 2025 17:38:58 +0900

개요

개인 프로젝트를 App Rotuer 로 마이그레이션하면서 아키텍처의 중요성을 다시한번 깨닫고 FSD(Feature-Sliced Design)을 고민해보았다. 기존 프로젝트 구조는 Next.js Pages Router 의 공식 Docs 를 보고 큰 고민없이 확장해나간 모놀리식 구조였다.

nextjs-keylog
 ┣ components
 ┣ config
 ┣ hooks
 ┣ pages
 ┃ ┣ [userId]
 ┃ ┃ ┣ posts
 ┃ ┣ api
 ┃ ┃ ┣ auth
 ┃ ┣ resetPassword
 ┣ public
 ┃ ┣ font
 ┃ ┣ icon
 ┣ reducer
 ┣ store
 ┣ styles
 ┣ utils

[기존 Pages Router 기반 구조]

이런식의 구조를 구성하다보니 프로젝트가 커질수록 컴포넌트가 계속 늘어나 어디에서 쓰이는지 구분하기 어려워졌고, 비즈니스 로직도 도메인 기준이 아닌 util, hook 같은 기술 단위로만 나뉘어 뒤섞이다 보니 구조 자체가 점점 더 복잡해졌다.

FSD 란 무엇인가

1) FSD(Feature-Sliced Design)란?

우선 FSD(Feature-Sliced Design)에 대해 간략하게 설명을 해보면 프론트엔드 아키텍처 설계 방법론 중 하나로, 기능 단위로 분할 설계 하여 낮은 결합력과 높은 응집력을 달성하는것을 목표로 하는 아키텍처이다. 이를 통해 코드의 복잡성은 줄이고 유지 보수성과 확장성을 높여 팀원 간의 협업을 극대화할 수 있는 장점이 있다.

2) FSD의 계층 구조

일반적으로 FSD는 크게 아래와 같이 Layers - Slices - Segment 계층으로 나눌수 있다.

- Layers

app : 애플리케이션 전역 설정 (라우터, 프로바이더, 글로벌 스타일 등)
~~processes~~ : 로그인 흐름, 결제 플로우처럼 여러 기능을 묶어 하나의 큰 프로세스를 표현(더이상 사용되지는 않는다.)
pages : 페이지 단위. 특정 URL에 매핑되는 화면
widgets : 여러 features나 entities를 조합해서 화면의 큰 블록을 이루는 단위
features : 사용자에게 제공되는 구체적인 기능 (예: 댓글 작성, 게시글 좋아요 버튼)
entities : 비즈니스 도메인 모델 단위 (예: User, Post, Product)
shared : 프로젝트 전반에서 재사용 가능한 유틸, UI 컴포넌트, 훅 등

- Slices

의미: 프로젝트를 도메인 단위로 세로로 나눈 것.
예를 들어 블로그 서비스라면 Post, User, Comment 같은 도메인별 폴더가 Slice가 될 수 있다.
한 슬라이스 안에는 그 도메인을 표현하는 UI, 상태관리, API 호출, 비즈니스 로직이 모두 들어갈 수 있다.

- Segements

의미: 각 Slice 안에서 기술적 목적에 따라 세분화하여 역할별로 나눈 계층.
Segment는 팀/프로젝트 성격에 맞게 자유롭게 구성할 수 있고, 보통은 다음과 같은 Segment를 사용한다.
- ui : React 컴포넌트(UI 레이어)
- model : 상태관리, 비즈니스 로직 (예: Zustand, React Query, Redux 등)
- api : 서버와의 통신 로직
- lib : 순수 유틸/도우미 함수
- config : configuration files, feature flags 등 환경 기능 설정

여기서 주의할 점은

- Cross-import 금지: features/* → 다른 features/* 직접 import 지양. 필요한 건 entities/* 또는 shared/*로 끌어올려 재사용.

- 상위 레이어가 하위 레이어를 의존하고, 역방향 의존은 금지한다.

허용: features → entities, shared
지양: entities → features, widgets → pages 등 상향 의존

Next.js App Router 에서의 FSD 도입

FSD 공식 문서를 보면 Next.js 환경에 맞춘 가이드라인이 친절하게 제공된다.(공식 Docs 가이드라인: https://feature-sliced.design/docs/guides/tech/with-nextjs) 특히 Pages Router에서의 pages 레이어와 App Router에서의 app 레이어 간 폴더명 충돌 문제에 대해 다양한 예시를 들어 설명하고 있다. 나 역시 이 부분을 고민했지만, 가이드라인을 그대로 따르기보다는 app 폴더는 유지하되 라우팅과 Pages 레이어의 역할을 동시에 수행하도록 방향을 정했다.

두번째 고민은 entities 와 features 의 명확한 구분 기준에 대해서도 많은 고민을 했는데 entities 는 비즈니스 api 응답에서 받는 DTO , 즉 명사 개념으로 생각했고 features 는 사용자와의 인터랙션, 기능 위주 즉 동사 개념으로 생각해서 구분하였다. 최종적인 디렉토리 구조는 아래와 같다.

src/
├── app/                         # App Router (route segments만 표시)
│   ├── [userId]/
│   │   └── [postId]/
│   ├── api/
│   ├── findPassword/
│   ├── resetPassword/
│   ├── login/
│   ├── signup/
│   ├── write/
│   ├── home/
│   ├── provider/
├── entities/                    # 엔티티 레이어
│   ├── article/
│   │   ├── api/
│   │   ├── component/
│   │   ├── lib/
│   │   ├── model/
│   │   └── query/
│   ├── comment/
│   │   ├── api/
│   │   ├── component/
│   │   └── model/
│   ├── hashtag/
│   │   ├── api/
│   │   ├── component/
│   │   ├── lib/
│   │   └── model/
│   ├── like/
│   │   ├── api/
│   │   ├── component/
│   │   ├── lib/
│   │   └── model/
│   ├── post/
│   │   ├── api/
│   │   ├── component/
│   │   ├── lib/
│   │   ├── model/
│   │   └── query/
│   ├── trend/
│   │   ├── api/
│   │   ├── component/
│   │   ├── hooks/
│   │   ├── lib/
│   │   ├── model/
│   │   └── query/
│   └── user/
│       ├── api/
│       ├── component/
│       └── model/
├── features/                    # 기능 레이어
│   ├── account/
│   │   ├── api/
│   │   ├── component/
│   │   ├── lib/
│   │   └── model/
│   ├── comment/
│   │   ├── api/
│   │   ├── component/
│   │   ├── hooks/
│   │   ├── lib/
│   │   └── model/
│   ├── like/
│   │   ├── api/
│   │   └── hooks/
│   ├── login/
│   │   ├── api/
│   │   ├── component/
│   │   ├── lib/
│   │   └── model/
│   ├── logout/
│   │   └── api/
│   ├── post/
│   │   ├── api/
│   │   ├── component/
│   │   ├── hooks/
│   │   ├── lib/
│   │   └── model/
│   └── signup/
│       ├── api/
│       ├── component/
│       ├── lib/
│       └── model/
├── shared/                      # 공용 레이어
│   ├── boundary/
│   ├── hooks/
│   ├── lib/
│   └── ui/
├── styles/
│   ├── fonts/
│   ├── globals.css
│   └── scss/
└── widgets/                     # 페이지 위젯
    ├── article/
    ├── footer/
    ├── header/
    └── sidebar/

Segments에서 ui 대신 component 라는 segment를 만들어서 사용했는데 이유는 ui 라고 하기에 SSR을 사용하기위한 서버컴포넌트가 있어서 순수 UI 라 말할수는 없을 것 같아 component segment를 만들고 그 아래 순수 ui 만 렌더링하는 ui 세그먼트를 하나 더 만들었다.

FSD 아키텍처를 도입해보며 느낀점

FSD 공식 문서에서 제시하는 가이드라인을 그대로 FM처럼 도입한 것은 아니지만, 직접 적용해보니 DX가 얼마나 크게 향상되는지 체감할 수 있었다. 이전 구조에서는 components, utils, hooks 같은 기술 단위 폴더에 코드가 흩어져 있어 새로운 기능을 추가할 때마다 서로 다른 관심사의 코드들이 뒤섞이며 어디에 넣어야 할지 고민이 많았다. 반면 FSD는 기능 단위(Slice)로 구조가 나뉘어 있어 필요한 api, model, ui, lib 코드가 한 폴더 안에 모여 있으니 새로운 기능을 개발할 때 해당 Slice에만 집중하면 되고, 다른 Slice에 불필요한 영향을 주지 않아 개발 속도와 안정성 측면에서도 큰 개선을 가져올 수 있었다. 규모나 복잡도가 높은 프로젝트 일 수록 더 직관적이고, 유지보수가 쉽고, 확장성이 높은 구조의 이점이 더 확연하게 느낄 수 있는 아키텍처라는 생각이 든다.

useInfiniteQuery를 활용한 무한 스크롤 구현과 뒤로가기 스크롤 복원

kyuuuun — Mon, 22 Sep 2025 17:08:04 +0900

개요

Next.js v15를 기반으로 개인 프로젝트를 진행하면서 게시물들을 블러올 때 무한 스크롤을 구현할 상황이 생겨서 IntersectionObserver 를 기반으로 무한 스크롤을 구현하였다. 근데 게시물을 클릭하여 상세 페이지로 이동 후 뒤로가기를 하니 이전 스크롤 위치가 아닌 최상단으로 스크롤이 올라가는 현상이 있었다. 이런 현상은 사용자 경험에 있어 매우 좋지 않다.

개선하기 위해 Next.js 에서 혹시 제공해주는 기능이 있는지 공식 Docs 를 먼저 뒤져봤다.

// next.config.js
module.exports = {
  experimental: {
    scrollRestoration: true
  }
}

실험적 기능으로 scrollRestoration 옵션이 있었다. 해당 기능을 켜고 테스트 해봤지만 기대하는 대로 동작하지 않았다. 정확하지 않지만 body에 overflow-y 로 스크롤을 걸었더니 정상적으로 동작은 했다. 하지만 내 개인 프로젝트는 body 외에 내부적으로 스크롤 기능이 필요한 컴포넌트들이 있어 직접 구현하기로 결정하였다.

Session Storage 를 활용한 스크롤 복원

일단 세션스토리지를 사용한 이유는 단순하고 휘발성이 있기 때문이다.

로컬스토리지처럼 탭을 닫고나서도 기억하고 있을 필요도 없고 쿠키보다 상대적으로 구현하기 편리하다.

스크롤 위치 저장시점은 언제 ?

스크롤 위치를 저장하는 시점에 대한 고민이 많았다.

1. beforeunload 이벤트

window.addEventListener("beforeunload", handler)

제일 단순하게 생각해보면 페이지를 나가기 직전에 저장하는게 맞으니까 제일 먼저 떠오른 방법이지만 React는 Single Page Application 이다. 내부적으로 감지할수 없다.

2. next/router 이벤트(구 pages router)

import Router from 'next/router';

useEffect(() => {
  const onStart = () => saveScroll(); // routeChangeStart 시 저장
  Router.events.on('routeChangeStart', onStart);
  return () => Router.events.off('routeChangeStart', onStart);
}, []);

두번째 next/router 이벤트를 활용해서 route 가 변하는 시점에 저장하는 방법인데 app router를 사용하고 있어서 패스했다.

app router에서 사용하는 next/navigation 의 useRotuer 는 저런 이벤트를 제공하지 않는다.

3. 라우트 전환 감지 (usePathname)

useEffect에 usePathname 에서 가져온 pathname 을 의존성으로 걸고 해당 컴포넌트가 unmount 되는 시점을 잡아보려고도 해봤지만 그 시점은 이미 새로운 페이지로 진입한 이후에 잡혀서 이것도 실패했다.

4. onClick 이벤트

결국 선택한 방법은 새로운 페이지로 이동하기 위해 next/link 를 클릭할 때 onClick 이벤트를 활용하여 저장하는 걸로 결정했다. 물론 스크롤 유지가 필요한 컴포넌트에 모두 걸어줘야 하는 단점이 존재하긴 하지만 스크롤 유지가 필요한 리스트페이지가 개인프로젝트 특성상 그렇게 많지는 않아서 선택했다. 커스텀 훅으로 구현 코드는 아래와 같다.

'use client';

import { usePathname } from 'next/navigation';
import { useSearchParams } from 'next/navigation';

interface Props {
  scrollElementId: string;
  extendQueryParams?: boolean;
}

export const useScrollRestoration = ({ scrollElementId, extendQueryParams = false }: Props) => {
  const pathname = usePathname();
  const searchParams = useSearchParams();

  const query = searchParams.toString();
  const key = createScrollKey(pathname, query, extendQueryParams);

  return {
    saveScrollPos: () => saveScrollPos(scrollElementId, key),
    restoreScrollPos: () => restoreScrollPos(scrollElementId, key),
  };
};

const createScrollKey = (pathname: string, query: string, extendQueryParams?: boolean) => {
  return `scrollPos_${pathname}${extendQueryParams && query ? `_${query}` : ''}`;
};

const saveScrollPos = (scrollElementId: string, key: string) => {
  const el = document.getElementById(scrollElementId);
  if (!el) return;
  sessionStorage.setItem(key, el.scrollTop.toString());
};

const restoreScrollPos = (scrollElementId: string, key: string) => {
  const el = document.getElementById(scrollElementId);
  const scrollTop = sessionStorage.getItem(key);
  if (!el || !scrollTop) return;
  requestAnimationFrame(() => {
    el.scrollTop = parseInt(scrollTop, 10);
  });
  sessionStorage.removeItem(key);
};

파라미터로 스크롤을 유지하고 싶은 element의 ID 를 넘겨주고 url path 를 키값으로 sessionStorage 에 스크롤 위치를 저장해줬다. saveScrollPos 를 onClick 에 걸고 스크롤 복원은 restoreScrollPos 로 렌더링이 완료되는 시점에 복원해줬다. extendQueryParams 는 쿼리스트링까지 키값으로 활용하고 싶은 경우에 사용한다.

'use client'

import { useEffect } from 'react'
import Link from 'next/link'
import { useScrollRestoration } from '@/shared/hooks'

export function BlogPostItem() {
  const { saveScrollPos, restoreScrollPos } = useScrollRestoration({
    scrollElementId: 'article',
    extendQueryParams: true,
  })

  useEffect(() => {
    restoreScrollPos()
  }, [])

  return (
    <Link href="/somewhere" onClick={saveScrollPos}>
      {..중략...}
    </Link>
  )
}

클라이언트 컴포넌트에서의 사용방법은 위와 같다.

useInfiniteQuery 를 사용한 무한 스크롤 구현

스크롤 복원을 위한 커스텀 훅을 만들었지만 기존 IntersectionObserver 만을 사용해서 구현한 무한 스크롤에서는 정상적으로 동작하지 않는다. 설정한 perPage 개수 만큼 한페이지에 게시물들을 불러오고 마지막 게시물이 뷰포트에 관측되면 다음 페이지 게시물들을 요청하여 아래에 뿌리는데 2페이지 이상만 넘어가도 뒤로가기시 default 로 불러오는 1페이지까지의 게시물 개수만큼만 있기 때문에 스크롤이 더 아래로 내려갈데가 없다.. 스크롤을 내린 이후 다음 데이터 패칭이 일어나기 때문이다.

예를 들면 아래와 같은 flow 이다.

1) 3페이지까지 스크롤을 내림

2) 게시물 상세 페이지 이동

3) 뒤로가기

4) 1페이지 게시물만 있음

5) 스크롤 복원으로 1페이지 끝까지 스크롤이 내려감(더 내려가야하지만 스크롤이 끝남)

6) 다음 페이지 데이터패칭

7) 스크롤 늘어남

이 문제의 해결은 단순하게 생각하면 뒤로 갔을때 이전 페이지 개수만큼 게시물이 있으면 된다.

useInfiniteQuery를 사용하면 이 문제가 명쾌하게 해결된다.

import { Post } from '../model';
import { getPosts } from '../api';
import { queryKey } from '@/app/provider/query/lib';
import { useInfiniteQuery, InfiniteData, QueryKey } from '@tanstack/react-query';

interface UseInfinitePostsQueryProps {
  searchWord?: string;
  initialPage?: Post[];
}

export const useInfinitePostsQuery = ({ searchWord = '', initialPage }: UseInfinitePostsQueryProps) => {
  // 초기 데이터
  const initialData: InfiniteData<Post[], number> | undefined = initialPage
    ? { pages: [initialPage], pageParams: [1] }
    : undefined;

  return useInfiniteQuery<Post[], Error, InfiniteData<Post[], number>, QueryKey, number>({
    queryKey: queryKey().post().postSearch({ searchWord }),
    initialPageParam: 1,
    queryFn: async ({ pageParam }) => await getPosts({
        searchWord,
        currPageNum: pageParam,
      });
    },
    // 다음페이지 반환 값
    getNextPageParam: (lastPage, _allPages, lastPageParam) => {
      const totalItems = lastPage[0]?.totalItems;
      const lastPageItemIndex = Number(lastPage[lastPage.length - 1]?.pageIndx);
      const hasMorePages = totalItems && lastPageItemIndex !== totalItems;
      return hasMorePages ? lastPageParam + 1 : undefined;
    },
    initialData,
  });
};

- queryKey : 명시한 queryKey로 데이터 페칭을 통해 가져온 데이터를 누적하여 캐싱한다.

- initialPageParam: 초기 페이지 번호

- queryFn: 데이터를 페치해오기 위한 함수이다. pageParam은 useInfiniteQuery가 내부적으로 관리하고 있는 페이지 번호로 같은 키로 관리되는 리스트의 다음 조각을 불러오기 위한 제어 값이라고 생각하면 된다.

- getNextPageParam: 무한 스크롤에서 다음 페이지를 무엇으로 요청할지 결정하는 함수이다. 로직을 직접 구현해야하는데 반환값이 다음 요청의 pageParam이 되고 undefined 를 반환하면 더이상 불러오지 않는다.

현재는 모든 게시물 데이터의 raw 응답에 totalItems 컬럼이 포함되어 있어, 마지막 게시물의 페이지 인덱스와 비교하여 이후에 더 페이지가 존재하는지 판별하고 있다.

const { data, fetchNextPage, hasNextPage, isFetchingNextPage, isFetching } = useInfinitePostsQuery({
  searchWord,
  initialPage: initPosts,
  });

// 마지막 게시물이 viewport 에 노출되면 fetchNextPage
const { setTarget } = useIntersectionObserver({
    onShow: () => {
      if (hasNextPage && !isFetchingNextPage && !isFetching) {
        fetchNextPage();
      }
    },
    once: true,
  });

사용은 위와 같이 IntersectionObserver 기반의 커스텀 훅에서 마지막 게시물이 노출 될 때 useInfiniteQuery 가 다음 페이지 데이터를 페치 해오도록 설정하였다. getNextPageParam 의 반환값이 undefined 가 아니면 hasNextPage의 값은 true 이다.

useInfinitQuery 가 반환하는 프로퍼티는 다음과 같다.

- data: 누적 페이지 데이터들

- fetchNextPage: 다음 페이지 트리거

- hasNextPage: 다음 페이지 존재 여부

- isFetchingNextPage: 다음 페이지 로딩중 여부

- isFetching: 이 쿼리로 네트워크 요청중 여부

Next.js Pages Router에서 App Router로: 데이터 패칭 흐름 개선기

kyuuuun — Mon, 22 Sep 2025 12:51:25 +0900

개요

기존에 next.js pages router 로 진행하였던 개인 프로젝트(https://github.com/alkalisummer/nextjs-keylog)를 v15.3으로 버전을 올리면서 app router 로 마이그레이션을 진행하였다.

전 직장에서 nuxt.js 를 next.js(v15.2.5)의 app router 로 마이그레이션 해본 경험을 토대로 진행하며 개선점을 정리해보려한다.

크게 와닿았던 개선점은 app router에서 서버 컴포넌트와 스트리밍 SSR이 가능해지면서 data fetch가 끝나고 준비된 컴포넌트부터 순차적으로 렌더링하여 바로 사용자에게 보여줄 수 있다는 점이다.

Pages Router - 기존 Data Fetch 패턴의 한계점

pages router에서의 SSR 은 getServerSideProps 에서 해당 page에 진입할 때 필요한 데이터를 한번에 fetch 하여 클라이언트 컴포넌트로 내려주는 구조다. 예시로 아래의 sudo 코드를 보자.

const Blog =({ ...props }) => {
  const {authorInfo, recentPosts, popularPosts, recentComments, hashtags} = props 
  return (
    <>
      <AuthorInfo authorInfo={authorInfo}/>
      <RecentPosts recentPosts={recentPosts}/>
      <PopularPosts popularPosts={popularPosts}/>
      <RecentComments recentComments={recentComments}/>
      <hashtags hashtags={hashtags}/>
    </>
  )
}
export default Blog

export const getServerSideProps = (ctx) => {
 
  const session = await fetchSession(ctx)
  const authorId = ctx.query.auhorId
  
  // Blog page 에 필요한 데이터를 병렬로 fetch
  if (userId) {
    const [
      authorInfo,
      recentPosts,
      popularPosts,
      recentComments,
      hashtags,
    ] = await Promise.all([
      fetchData("getAuthor",      { id: authorId }),
      fetchData("getRecentPosts",  { id: authorId }),
      fetchData("getPopularPosts", { id: authorId }),
      fetchData("getRecentComments",{ id: authorId }),
      fetchData("getAuthorHashtags",{ id: authorId }),
    ])
  }

  return {
    props: {
      authorInfo,
      recentPosts,
      popularPosts,
      recentComments,
      hashtags,
    }
  }
}

위 코드에서는 getServerSideProps 를 통해 server-side 에서 이 페이지에서 필요한 블로그 저자의 정보, 최근게시물, 인기 게시물, 최근 댓글등의 데이터를 SSR로 fetch 해오는데 병렬로 실행된다고 하더라도 어느 하나가 늦게 도착하면 Promise All의 특성상 꼼짝없이 기다려야 한다. 위 구조를 app router의 서버컴포넌트 + 스트리밍 SSR 로 개선한 구조는 아래와 같다.

App Router – 요청은 한 번만, 먼저 온 놈 먼저

import { PropsWithChildren, ReactNode, Suspense } from 'react';
import { ErrorBoundary } from './ErrorBoundary';

interface AsyncBoundaryProps {
  pending: ReactNode | null;
  error: ReactNode | null;
}

// loading 상태에 따른 fallback과 error를 처리
export const AsyncBoundary = ({ pending, error, children }: PropsWithChildren<AsyncBoundaryProps>) => {
  return (
    <ErrorBoundary fallback={error}>
      <Suspense fallback={pending}>{children}</Suspense>
    </ErrorBoundary>
  );
};

interface Props {
  authorId: string;
}

export const Sidebar = async ({ authorId }: Props) => {
  const authorInfo = getAuthor(authorId);
  const recentPosts = getRecentPosts(authorId);
  const popularPosts = getPopularPosts(authorId);
  const recentComments = getRecentComments(authorId);
  const hashtags = getAuthorHashtags(authorId);
  
  //promise 객체를 그대로 내려줌
  return (
    <aside className={css.module}>
      <div className={css.leftArea}>
        <AsyncBoundary pending={<BoxSkeleton height={166.5} />} error={<BoxError height={150} />}>
          <UserInfo promise={{ authorInfo }} authorId={authorId} />
        </AsyncBoundary>
        <AsyncBoundary pending={<BoxSkeleton height={166.5} />} error={<BoxError height={150} />}>
          <RecentPosts promise={{ recentPosts }} authorId={authorId} />
        </AsyncBoundary>
        <AsyncBoundary pending={<BoxSkeleton height={166.5} />} error={<BoxError height={150} />}>
          <PopularPosts promise={{ popularPosts }} authorId={authorId} />
        </AsyncBoundary>
        <AsyncBoundary pending={<BoxSkeleton height={166.5} />} error={<BoxError height={150} />}>
          <RecentComments promise={{ recentComments }} authorId={authorId} />
        </AsyncBoundary>
        <AsyncBoundary pending={<BoxSkeleton height={150} />} error={<BoxError height={150} />}>
          <SidebarHashtags promise={{ hashtags }} authorId={authorId} />
        </AsyncBoundary>
      </div>
    </aside>
  );
};

위 서버컴포넌트인 Sidebar 컴포넌트에서 필요한 데이터를 fetch 해오는 함수들은 모두 Promise 객체이다. 중요한 점은 Sidebar 컴포넌트에서 await 으로 데이터를 fetch 하여 응답을 기다리는게 아니라 그대로 해당 데이터가 필요한 컴포넌트에 props 로 내려주는 것이다.

이러한 패턴으로 next.js의 스트리밍 SSR을 활용하여 먼저 응답이 도착한 컴포넌트 부터 순차적으로 렌더링하여 사용자에게 보여줄 수 있는 것이다.

여기서 한 가지 의문이 생길 수 있다. 특정 데이터 패칭 함수를 여러 컴포넌트에서 공통으로 사용한다면 호출이 중복되지 않을까 하는 점이다. 그러나 이 함수들은 내부적으로 Next.js의 fetch를 사용하고 있으며, Next.js는 한 렌더 사이클 내에서 동일한 URL 요청을 한 번만 수행하고 결과를 재사용한다. 따라서 불필요한 중복 네트워크 요청에 대해서는 걱정하지 않아도 된다.

Async Boundary 컴포넌트는 React의 Suspense와 Error Boundary를 활용하여, Promise를 반환하는 데이터 패칭 함수의 로딩 상태는 fallback으로, 에러는 에러 핸들러로 처리하도록 책임을 분리해주었다.

데이터 패칭을 위한 promise 를 props로 받은 이후에는 react query 로 아래와 같이 작성하였다.

export const RecentPosts = async ({ promise, authorId }: Props) => {
  const queryClient = new QueryClient();

  const recentPostsQueryOptions = {
    queryKey: queryKey().post().recentPost(authorId),
    queryFn: () => promise.recentPosts,
  };
  await queryClient.prefetchQuery(recentPostsQueryOptions);

  const dehydratedState = dehydrate(queryClient);

  return (
    <HydrateClient state={dehydratedState}>
      <View/>
    </HydrateClient>
  );
};

View 컴포넌트는 UI 를 렌더링하는 담긴 클라이언트 컴포넌트이다.

서버 컴포넌트에서 데이터를 가져오는 동안 클라이언트 컴포넌트는 Suspense의 fallback UI를 노출하고, 패칭 완료 시 queryKey 기반으로 캐싱된 데이터를 useQuery로 즉시 불러와 렌더링하도록 구현하였다.

이런 패턴으로 화면 진입 시 즉시 보여야 하는 데이터나 사용자와의 인터랙션이 필요 없는 정적 데이터는, 스트리밍 SSR을 활용해 서버 컴포넌트에서 미리 패치해 두고 응답이 도착한 컴포넌트부터 순차적으로 렌더링하는 방식이 특히 유용했다.

Google Trends API, npm 패키지 배포

kyuuuun — Wed, 4 Jun 2025 14:31:54 +0900

개요

오랜만에 개인적으로 진행하던 사이드프로젝트를 리팩토링 해볼겸 로컬에서 서버를 올려봤는데 .. 동적으로 Google Trends 데이터를 받아오기 위해 사용하던 npm 패키지(https://www.npmjs.com/package/google-trends-api)가 어느순간 먹통이 되어 디버깅을 해보니 response가 왠 404 에러가 .. 뭐지 .. 하는 기분으로 goole trends 에 먼저 접속해봤더니 UI가 대폭 업데이트 되었다.. npm 에서 설치하여 사용하던 패키지는 Google 에서 공식적으로 제공해주는 라이브러리가 아니기에 해당 소스 repository의 github issue 탭을 들어가보니 아니나 다를까 UI 가 업데이트 되면서 Google Trends 자체적으로 clientside쪽에서 호출하는 여러 API들의 endpoint도 같이 변경된 것으로 보였고 나와 같은 고통을 겪는 다른 개발자들의 이슈 글들이 보였다.

2월달부터 게시된 이슈글이 아직 해결되지 않은 것을 보니 해당 패키지는 더이상 관리되지 않는 것으로 보였다.

좀 더 디깅을 해보다가 다른 개발자가 타입스크립트로 개발해놓은 패키지를 발견하였지만 기존 패키지보다 다소 기능이 많이 부족하여 해당 레포를 fork떠서 기존 기능들을 직접 추가하고 npm 에 배포해보기로 했다.

NPM 배포

개발 방식은 네트워크 탭에 들어가서 각 API들 request 및 payload를 분석하고 response 응답을 parsing 하여 만들었다.

[request payload 및 response 분석]

(Google trends 에서 동적으로 클릭해서 요청이 발생하면 payload에 담기는 파라미터 값들이 패턴이 있어서 엄청 어렵지는 않았습니다.)

- package.json

{
  "name": "@alkalisummer/google-trends-js",
  "version": "0.1.0",
  "description": "Google Trends API for Node.js",
  "main": "lib/index.js",
  "types": "lib/index.d.ts",
  "scripts": {
    "build": "tsc",
    "format": "prettier --write \"src/**/*.(js|ts)\"",
    "lint": "eslint src --ext .js,.ts",
    "lint:fix": "eslint src --fix --ext .js,.ts",
    "test": "jest --config jest.config.js",
    "prepare": "npm run build",
    "prepublishOnly": "npm test && npm run lint",
    "preversion": "npm run lint",
    "version": "npm run format && git add -A src",
    "postversion": "git push && git push --tags"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/alkalisummer/google-trends-js.git"
  },
  "keywords": [
    "google trends",
    "keyword",
    "google",
    "trends",
    "API",
    "search",
    "typescript",
    "npm",
    "module"
  ],
  "author": "alkalisummer",
  "private": false,
  "publishConfig": {
    "access": "public"
  },
  "license": "MIT",
  "devDependencies": {
    "@types/jest": "29.5.14",
    "@typescript-eslint/eslint-plugin": "5.62.0",
    "@typescript-eslint/parser": "5.62.0",
    "eslint": "8.57.1",
    "eslint-plugin-jest": "27.9.0",
    "jest": "29.7.0",
    "prettier": "2.8.8",
    "ts-jest": "29.2.5",
    "typescript": "4.9.5"
  },
  "files": [
    "lib/**/*"
  ]
}

개발을 다하고 나면 package.json을 위와 같이 정보에 맞게 수정후

(새로 배포할 때마다 버전은 무조건 올려줘야 합니다.)

npm publish --access public

위 명령어로 npm 에 배포할 수 있습니다.

위와 같이 배포가 완료되면 npm에서 배포된 패키지 모듈을 확인할 수 있습니다.

기능에 관한 설명은 readme에 정리해놨습니다.

배포된 npm 패키지 url

https://www.npmjs.com/package/@alkalisummer/google-trends-js

@alkalisummer/google-trends-js

Google Trends API for Node.js. Latest version: 0.1.0, last published: an hour ago. Start using @alkalisummer/google-trends-js in your project by running `npm i @alkalisummer/google-trends-js`. There are no other projects in the npm registry using @alkalisu

www.npmjs.com

AWS API Gateway - Lambda 를 활용한 동적 이미지 프로세싱

kyuuuun — Fri, 25 Apr 2025 00:30:32 +0900

근래 사내 프로젝트로 AWS Lambda 를 활용하여 on-the-fly 방식으로 동적 이미지 프로세싱 프로젝트를 진행하게 되었습니다.

프로젝트를 진행하며 겪었던 이슈와 과정들을 회고하며 간략하게 정리해보려 합니다.

배경

저희 회사는 이커머스 업계 특성상 굉장히 많은 상품 이미지를 AWS S3로 관리하고 있습니다.

당시 이미 동적 이미지 프로세싱 및 캐싱 기능의 역할을 하는 외부 솔루션을 도입하여 Image 서버가 구축되어 있었고 월마다 고정 비용이 나가고 있었는데요. 클라이언트에서 이미지 요청의 경우 flow 를 자세히 보니 조금 의아한 부분이 있었습니다.

기존 이미지 요청 flow 를 간략하게 도식화한 이미지입니다. 이미 AWS CloudFront가 제일 앞 단에서 url 을 key 값으로 캐싱을 잘해주고 있었고 실제 Image Server 의 캐싱 히트율은 2-3%대에 지나지 않았습니다.

그럼 이미지 프로세싱만 잘 구현하면 굳이 Image Server 솔루션 사용할 이유가 있을까 ? 에서 시작된 PoC 였습니다. 초기에는 nest.js를 기반으로 sharp 라이브러리를 활용하여 Image Server 를 대체할 서버를 구축하려 했으나 구글링을 해보니 AWS Lambda 를 활용하여 비교적 더 간단한게 구현한 선례들이 많아 API Gateway + Lambda로 우회하게 되었습니다. Lambda에 대해 간략하게 설명하면 AWS 에서 제공하는 serverless 함수 기반 서비스로 작성된 코드를 aws 가 알아서 실행해주는 저렴한 가격의 훌륭한 서비스입니다.

그리하여 AWS API Gateway + Lambda 를 도입한 이미지 요청 flow 는 아래와 같습니다.

왜 CloudFront 가 바라보는 origin(원본)이 두개일까?

이유는 Lambda의 응답 용량 한계에 있습니다. 처음에는 AWS Lamda@Edge 를 생각했지만 response limit 이 1mb 밖에 되지 않아 고민하였습니다. 실제 사용자들이 올리는 리뷰 이미지의 경우는 스마트폰의 카메라 기술 발전에 따라 굉장히 고화질이라 1mb 가 넘는 이미지가 수두룩하였기 때문입니다... 이미지를 리사이징하여 용량을 낮추면 되지 않나 ? 라고 생각하면 또 그럴수 있겠지만 원본이미지 요청인 경우 1mb가 넘어가면 불필요한 이미지 리사이징이 필요하기에 용량 제한이 6mb 인 일반 Lambda로 변경 하였고 이미지 프로세싱이 필요없는 원본 이미지 요청은 바로 S3를 찌르도록 구성하였습니다. API Gateway는 CloudFront에 직접 붙일수 있는 Lambda@Edge 와 다르게 일반 Lambda는 직접 붙일수가 없어 CloudFront에서 Lambdad를 사용하기위해서는 API Gateway를 엔드포인트처럼 함께 사용하여야 합니다.

Lambda 배포 방법

사내에서는 여러 Lambda 함수를 Serverless 프레임워크를 통해 관리 및 배포를 하고 있었습니다. serverless 프레임워크는 serverless.yml 파일 하나로 Lambda 함수, API Gateway, S3, IAM 권한 등을 손쉽게 관리하고 배포할수 있는 툴로 생각하시면 됩니다.

AWS 권한만 있다면 serverless deploy 명령어 하나로 serverless.yml에 작성된 설정대로 AWS 에 바로 배포되니 정말 편리하긴 합니다. 저 같은 경우는 사내 보안상? 모든 권한을 다 받지는 못했습니다.. 그리 하여 코드 수정이 필요할때는 수동 배포를 진행했는데serverless deploy 에 비해 조금 번거롭긴 하지만 나름 적응되면 또 괜찮습니다.

방법은 아래와 같습니다.

serverless package --stage dev // 개발 환경으로 패키징
serverless package --stage prod // 운영 환경으로 패키징

위 명령어들을 실행하면 local에 설치된 node_mouduls 와 코드를 가지고 패키징을 하여 위 이미지처럼 .serverless 폴더 아래에 zip 파일을 만들어줍니다.

* 여기서 정말 주의 해야하는 점은 AWS Lambda는 linux 환경에서 실행되기 때문에 반드시 linux 환경에서 호환이되는 모듈을 설치해야 합니다.

저의 경우 Lambda 런타임 환경이 리눅스, 아키텍처가 arm64로 아래 명령어를 통해 sharp 를 설치하였습니다.

npm install sharp --platform=linux --arch=arm64

이 zip 파일을 가지고 AWS Lambda 콘솔로 이동합니다.

콘솔의 코드탭에서 코드 소스를 zip파일로 업로드하거나 S3 버킷에 올리고 버킷주소를 통해 업로드할 수 있습니다.

업로드 후에는 버전 탭으로 이동해서 새버전 발행으로 배포를 진행하면 완료입니다.

AWS Lambda Console 테스트

코드 업로드 후에는 테스트 탭에서 업로드된 코드로 AWS Lambda 콘솔에서 테스트를 진행해볼 수 있습니다.

테스트 탭에서 저장버튼을 클릭시 테스트했던 이벤트 Json을 테스트 이름과 같이 저장하고 추후에도 계속 세팅하여 테스트 할 수 있습니다.

이미지 프로세싱의 경우 대게 request url에 원본 파일경로나 어떻게 이미지를 가공할 것인지에 대한 옵션 정보 값들이 있을텐데 저 역시 request url 이 필요했고 Lambda 함수 실행시 진입점인 handler 함수에서는 event 객체를 인자로 받아 path 에서 request url 에서 꺼내서 사용하기 때문에 이벤트 JSON 에 위와 같이 cloudfront url을 제외한 나머지 경로를 path 프로퍼티에 넣어 테스트를 진행하면 아래와 같이 테스트 결과를 확인할 수 있습니다.

lambda 함수 내에서 찍은 log도 로그 출력에서 확인이 가능합니다. 물론 CloudWatch에서도 해당 lambda의 로그를 확인할 수 있습니다.

AWS CloudFront 설정

이제 lambda 를 만들었으니 API Gateway에 연결 후 마지막으로 CloudFront의 원본으로 API Gateway 설정하면 완료입니다.

API Gateway는 serverless.yml에 작성된 설정대로 배포하면 잘 배포되지만 CloudFront 설정에서 한가지 주의해야하는 점이 있습니다.

우선 CloudFront로 이동하여 원본탭으로 가보면 아래와 같은 화면이 나오는데

이 탭에서는 cloudfront 의 캐시가 miss 났을때 바라볼 원본 origin 들을 설정할 수 있습니다. 도식에서 설명드렸던것과 같이 원본유형이 API Gateway, S3 두개가 있는 것을 확인할 수 있습니다.

이 탭에서는 크게 볼건 없고 람다 함수를 실행시키기 위한 API Gateway 도메인 이름과 원본 이미지가 저장된 S3 버킷 이름 정도만 알고 넘어가면 될 것 같습니다.

다음은 동작탭으로 이동해보면 request url 에서 패턴에 따라 어떤 원본(origin)을 가져올지 설정할 수 있습니다.

처음 요청이 들어오면 우선순위가 높은 순으로 먼저 패턴 체크를 하여 저희는 image processing 이 필요한 이미지의 경우 특정 예약어가 url 에 붙기때문에 해당 예약어가 url 포함되어 있으면 API Gateway 를 통해 람다를 실행시킵니다.

0번째 동작이 정상적인 응답을 반환했다면 다음 우선순위는 실행되지 않습니다.

동작을 새로 생성하거나 편집 버튼을 통해 수정하면 해당 동작의 캐시 키와 응답 헤더 정책 등을 설정할 수 있는데 cloudfront 원본(origin)을 기본적으로 헤더에 넣어주지는 않습니다.

origin 이 빠진 정책으로 설정하면 CORS 이슈가 발생하여 정상적으로 이미지가 불러와지지 않기에 CORS 에러 발생을 막기위해서는 반드시 요청정책과 응답 헤더 정책에 origin 이 포함된 정책을 넣어야합니다. 위 이미지의 요청정책과 응답헤더 정책은 보기 클릭시 origin이 포함되어 있습니다. (응답헤더는 보안상 가리긴했지만)

여기까지 모든 설정이 완료되었습니다. 현재는 운영에 배포되어 기존 이미지 서버는 걷어내고 Lambda를 통해 정상적으로 이미지 프로세싱이 되고 있습니다. 아무래도 AWS 인프라 설정은 Front end 개발자로서 자주 접해볼 기회가 많지 않아 매우 유익한 시간이였고 CloudFront와 이미지 캐싱 및 프로세싱 모두 Front end 측면에서는 알아두면 매우 좋은 경험이 될 것 같아 회고해보면서 뿌듯했습니다 ㅎㅎ..

긴 글 읽어주셔서 감사합니다!

나 볼려고 만든 PHP 기초 문법(echo, var_dump, 변수 사용법, 형변환, $_GET, $_POST, 배열, 연관배열)

kyuuuun — Sun, 11 Feb 2024 15:48:00 +0900

나 필요할때 볼려고 만든 PHP 기초 문법 정리 글이다.

1. 화면 출력

echo 문을 사용하여 화면에 출력

','를 구분자로 여러 인자를 출력 가능

<?php
  echo "Hello World!", " ", "Hello", " ", "World!"; //Hello World! Hello World!
?>

2. 변수 선언

$ 표시를 변수 명 앞에 붙여서 변수를 선언

<?php
  $num = 1;
  $str = "string";
  $test;
  
  //1
  //string
  //Warning: Undefined variable $test2 in /Users/kihoon/myPhp/test.php on line 9
  echo $num;
  echo '<br/>';
  echo $str;
  echo $test;
?>

3. 변수 정보 확인

var_dump 함수를 사용하여 확인 가능.

<?php
  $num = 1;
  $str = "string";
  $arr = array(1, 2);
  $bool = true;

/*
int(1)
string(6) "string"
array(2) { [0]=> int(1) [1]=> int(2) }
bool(true)
*/
  echo var_dump($num);
  echo '<br/>';
  echo var_dump($str);
  echo '<br/>';
  echo var_dump($arr);
  echo '<br/>';
  echo var_dump($bool);
?>

4. 문자열 붙이기

'.' 을 사용하여 문자열끼리 붙여서 표출할 수 있다.

<html>
  <body>
    <?php 
      //coding everybody
      $first = "coding";
      echo $first." everybody";
    ?>
  </body>
</html>

5. 상수 선언

define 함수를 사용하여 상수를 선언할수 있다. 첫번째 인자로 변수명, 두번째 인자로 값을 전달받는다.

이미 정의된 상수를 재선언시 오류 발생

<html>
  <body>
    <?php
      /*
      PHP Tutorial
      Warning: Constant TITLE already defined in /Users/kihoon/myPhp/variable/variable4.php on line 7
      PHP Tutorial
      */
      define('TITLE', 'PHP Tutorial');
      echo TITLE;
      define('TITLE', 'JAVA Tutorial');
      echo TITLE;
    ?>
  </body>
</html>

6. 형변환

settype 을 사용하여 변수 값 자체를 형변환 하거나

(int), (string), (array), (object), (float)

등을 사용하여 일시적으로 형변환을 할 수 있다.

<html>
  <body>
    <?php
      /*
      integer
      double
      string(3) "100"
      array(1) { [0]=> float(100) }
      object(stdClass)#1 (1) { ["scalar"]=> float(100) }
      float(100)
      */
      $a = 100;
      echo gettype($a);
      settype($a, 'float');
      echo '<br/>';
      echo gettype($a);
      echo '<br/>';
      echo gettype((string)$a);
      echo '<br/>';
      echo gettype((array)$a);
      echo var_dump((array)$a);
      echo '<br/>';
      echo gettype((object)$a);
      echo '<br/>';
      echo gettype((float)$a);
      echo '<br/>';
    ?>
  </body>
</html>

7. 가변 변수

title이라는 변수에 'subject'라는 값을 담고 $title에 $를 하나 더붙여서 사용시 $subject로 값을 할당하거나 사용할 수 있다.

<html>
  <body>
    <?php
      #가변변수
      // PHP tutorial
      $title = 'subject';
      $$title = 'PHP tutorial';
      echo $subject;
    ?>
  </body>
</html>

8. form I/O

form 에서 submit으로 전송한 value를 각 메서드에 맞게 $_GET[name속성 값] , $_POST[name 속성 값] 으로 받을수 있다.

//formTest.html
<html>
  <body>
    <form method="POST" action="postTest.php">
      id : <input type="text" name="id" /> pw : <input type="text" name="password" />
      <button type="submit">전송</button>
    </form>
  </body>
</html>

//postTest.php
<?php
echo $_POST['id'].','.$_POST['password']
?>

위 코드에서는 form 메서드로 input value를 POST 로 보내고 $_POST로 데이터를 받았지만 GET 메서드로 보내고 $_GET으로 데이터를 받을수도 있다.

9. function

<?php
  $test = "테스트";
  function numbering($param = 0){ // param 변수의 초기값을 0으로 설정
    global $test;
    while($param < 10){
      echo $param;
      $param += 1;
    }
    echo $test;
  }
  numbering(1);//123456789테스트
?>

php에서의 함수사용 방법은 javascript와 큰 차이는 없지만 전역변수의 값을 함수내에서 사용시 global을 사용하여 함수 내에서 사용할 수 있다.

10. 배열

<?php
function get_members(){
    return ['egoing', 'k8805', 'sorialgi'];
}

$members = get_members();
for($i=0; $i<count($members); $i++){
    echo ucfirst($members[$i]).'<br/>'; // ucfirst : 첫번째 문자만 대문자로 변환
}

/*
초기화 방법 종류
$li = [];
$li = array();
$li = array(1,2);
*/
$li = ['b', 'c', 'a', 'g', 'e'];

array_push($li, 'f'); // 제일 뒤에 'f'를 삽입 
array_unshift($li, 'd');// 제일 앞에 'd'를 삽입

array_shift($li);// 제일 앞 원소를 제거
array_pop($li);// 제일 뒤 원소를 제거 

sort($li); // 정렬
rsort($li);// 역정렬
?>

11. 연관배열

/*
key: egoing value:10
key: k8805 value:6
key: sorialgi value:80
*/
<?php
  $grades = array('egoing'=>10, 'k8805'=>6, 'sorialgi'=>80);
  foreach($grades as $key => $value){
      echo "key: {$key} value:{$value} <br />";
  }
?>

[Git] Conflict(충돌)시 해결방법

kyuuuun — Sun, 21 Jan 2024 23:17:44 +0900

git 에서 브랜치간 merge(병합)시 confilct(충돌)이 발생했을때 해결하는 방법에 대해 간단하게 정리하는 글이다.

간단한 예시를 위해 main 브랜치와 o2 브랜치에서 같은 파일을 수정 후 merge 하여 일부러 충돌을 발생시킬 것이다.

main 브랜치의 work.txt(좌) / o2 브랜치의 work.txt(우)

merge -> conflict 발생

======= 를 구분선으로

현재 HEAD(main 브랜치)의 파일과 o2 브랜치의 파일 에서 같은 라인에 어디가 충돌 났는지 보여준다.

이때 직접 수동으로 두 브랜치의 반영사항을 모두 반영할 지 한쪽만 반영할 지 정하고 수정한 뒤 저장한다.

두개다 반영하기 위해 위와 같이 수정하였다.

이후 아래 순서와 같이 충돌이 발생한 파일을 add 하고 status로 상태를 확인한 뒤 commit 으로 merge를 완료한다.

git add 충돌이 발생한 파일
git status 
git commit -m "커밋메시지"

git log 확인시 정상적으로 merge 가 된 것을 확인할 수 있다.

[Git] CLI 명령어 모음(init, status, add, commit, log, diff, reset, checkout, revert)

kyuuuun — Fri, 19 Jan 2024 00:29:45 +0900

1. Git Repository 생성 및 초기화

git init

해당 명령어를 사용한 경로에서 git을 사용할 수 있도록 지역 저장소를 생성 및 초기화한다.

git init으로 repository 생성

2. 현재 상태 확인

git status

해당 명령어를 사용해서 현재 상태와 버전이 달라진게 없는지 확인한다.

하위 이미지를 보면 Untracked files에 hello1.txt 파일이 있는 것을 확인할 수 있는데 이것은 현재 git 해당 파일을 추적하고 있지 않다는 의미이다. add 명령어를 사용하여 stagingArea에 올려주면 그 이후로는 git 이 해당파일을 추적한다.

git status 로 상태 확인

3. Staging Area 에 올리기

우선 Working tree, Staging Area, Repository 의 개념부터 알아야할 필요가 있다.

git init 으로 생성된 레파지토리 내에서 파일을 생성하거나 수정하게 되면 git status 명령어를 통해 커밋할수 있는 파일이나 커밋을 해야할 파일 , 추적중이지 않은 파일들을 확인할 수 있다. 지역 저장소로 버전관리를 하는 flow를 간략하게 나타내면 아래와 같다.

1. 파일을 수정 한다.

2. git add 명령어를 통해 Working tree 에서 변경사항들을 Staging Area에 올린다.

3. git commit 명령어를 통해 Staging Area 에 올라온 사항들을 Repository에 반영한다.

# 파일명1 파일명2 파일명3을 stage에 올림
git add 파일명1 파일명2 파일명3 

# 현재 디렉토리의 모든 파일을 staging Area에 올림
git add .

git add 명령어를 사용하여 스테이지에 올림

4. Commit

# stagig area에 올라온 모든 것을 커밋
git commit -m "커밋 메세지"

# stagig area에 올라온 것중에 파일명1을 커밋
git commit 파일명1 -m "커밋 메세지"

# add를 생략하고 바로 커밋(untracked 파일은 무시됨)
git commit -am "커밋 메세지"

git commit 으로 stage에 올라온 변경사항을 지역 저장소(repository)에 commit\

-m 명령어를 사용하지 않고 git commit 만 실행하게 되면 default 로 설정된 에디터가 켜지면서 여러 줄에 걸쳐 커밋 메세지를 작성할 수 있다. default 로 설정된 에디터를 변경하고 싶다면 아래의 명령어를 사용하여 에디터를 변경하자.

git config --global core.editor "vim" #원하는 에디터 ex) nano, vim

5. log 확인

# commit 로그를 최신 순으로 표출
git log

# commit 로그와 변경사항을 최신 순으로 표출 
git log -p

git log / git log -p 의 차이점

6. 변경사항 확인

# working directory 와 staging area 사이의 차이 확인
git diff

# working directory, staging area의 변경사항 모두를 repository head commit과 비교 
git diff HEAD

# 브랜치1 과 브랜치2 간 변경사항 확인 
git diff branch1 branch2
git diff branch1..branch2

# commit1과 commit2 간 변경사항 확인
git diff commitId1..commitId2

git diff / git diff HEAD 차이점

7. Reset을 사용하여 commit 되돌리기

# HEAD를 이전 커밋으로 이동하면서 staging area와 working directory 변경내용은 그대로 유지
git reset --soft

# HEAD를 이전 커밋으로 이동하면서 staging area는 초기화되지만 working directory의 변경내용은 그대로 유지됨(기본값)
git reset --mixed

# HEAD를 이전 커밋으로 이동하면서 staging area와 working directory 변경내용을 모두 초기화
git reset --hard

# HEAD를 특정 커밋 ID로 이동하면서 staging area와 working directory 변경내용을 모두 초기화
git reset --hard 커밋ID

뒤에 붙이는 모드에 따라 staging area 와 working directory 의 변경내용 무시 여부를 설정하고 staging area에 올라간 커밋을 되돌릴 수 있다. 주의 할점은 HEAD가 가르키던 브랜치가 특정 커밋을 가르키도록 변경되기 때문에 특정 커밋 ID로 리셋시 그 이후 커밋으로 되돌아갈수 없으니 주의해서 사용해야 한다.

git reset 실행

reset 실행후 Message 3 에 해당하는 커밋은 사라지고 HEAD가 가르키던 main branch의 최근 커밋이 Message 2로 변경된 것을 확인할 수 있다.

8. 특정 버전으로 돌아가기

# 특정 커밋 ID로 HEAD룰 이동
git checkout 커밋ID

# main branch 로 HEAD를 이동
git checkout main

위 명령어를 이용해서 특정 커밋 ID나 브랜치로 HEAD를 이동시킬 수 있다. 커밋 ID 는 git log 를 통해 확인가능하다. 특정 커밋 ID로 체크아웃을 받으면 브랜치는 별개로 HEAD의 위치만 바꿀 수 있으므로 브랜치의 최근 커밋으로 다시 이동할 수 있다.

9. Revert를 사용한 되돌리기

git revert 커밋ID

revert 를 사용하여 되돌리는 방법도 있지만 reset과는 원리가 다르다. 아래의 예시를 보자.

현재의 git log

위 git log에서 R4 커밋메세지에 해당하는 커밋을 revert 하면 아래와 같다.

git revert 실행

git reset 처럼 HEAD가 가르키던 브랜치의 최근 커밋이 R3가 된것이 아니라 R4 커밋은 그대로 있고 새로운 커밋이 생긴 것을 확인할 수 있다. 파일의 내용을 열어서 확인해보면 R3의 작업 내역이 들어있는 것을 확인할 수 있다.

10. 제일 최근 커밋 메시지 수정

# default 로 설정된 에디터가 열리면서 메시지 수정
git commit --amend

# 에디터를 열지 않고 간단하게 메시지 수정
git commit --amend -m "커밋 메시지 수정"

[Node.js] BOJ - 캠프가는 영식

kyuuuun — Tue, 16 Jan 2024 09:04:23 +0900

백준 링크 : https://www.acmicpc.net/problem/1590

1590번: 캠프가는 영식

예제 1의 경우 150분, 200분, 250분, ..., 600분에 한 대씩 버스가 출발한다. 따라서 영식이는 300분에 버스를 타면 된다.

www.acmicpc.net

문제

영식이는 민식이와 함게 고속버스를 타고 캠프를 가야 하지만, 민식이는 영식이를 깨우지 않고 혼자 버스를 타고 캠프에 가버렸다.

영식이는 혼자 고속버스터미널까지 가서 캠프에 오려고 한다. 터미널에는 캠프 장소까지 운행하는 N가지의 버스가 있다. 각각의 버스는 시작 시각, 간격, 대수의 정보를 가지고 있다. 예를 들어, 어떤 버스의 시작 시각이 특점 시점을 기준으로 10분 후이고, 간격은 10분이고, 대수가 5대이면, 이 버스는 10분, 20분, 30분, 40분, 50분에 한 대씩 출발한다.

영식이는 버스터미널에 T분에 도착했다. 영식이가 버스를 타려면 최소 몇 분을 더 기다려야 하는지 구하는 프로그램을 작성하시오.

입력
첫째 줄에 버스의 개수 N과 영식이가 버스터미널에 도착하는 시간 T가 주어진다. 둘째 줄부터 총 N개의 줄에 각 버스의 시작 시각 Si, 간격 Ii, 대수 Ci가 공백을 사이에 두고 주어진다.

출력
첫째 줄에 영식이가 기다려야 하는 시간을 출력한다. 영식이가 도착하는 동시에 버스가 출발하면 정답은 0이다. 만약 버스가 없어서 캠프에 갈 수 없으면 -1을 출력한다. 정답은 231보다 작다.

풀이

이분탐색 알고리즘을 적용하면 해결할 수 있는 문제로 버스의 시작 시각 S와 간격 I, 대수 C 로 각 버스별 시간정보를 담은 배열을 생성하고 반복문을 돌리면서 각 버스별로 이분탐색 알고리즘을 적용하여 해결할 수 있다. 단, 만약 버스 시각이 목표 시각 T 보다 크고 이전 목표시각이 T보다 작은 경우도 답이 될수 있기때문에 while 문에서 탈출해야 한다.

코드

const fs = require('fs');
const input = fs.readFileSync('/dev/stdin').toString().trim().split('\n');

// n : 버스 종류 개수, t: 영식이가 버스터미널에 도착하는 시간
const [n, t] = input[0].split(' ').map(Number);

let res = [];
let min = 0;
for (let i = 1; i <= n; i++) {
  // s : 버스 시작 시각, l : 간격, C : 대수
  let [s, l, c] = input[i].split(' ').map(Number);
  let start = 0;
  let busArr = [];
  for (let i = 0; i < c; i++) {
    busArr.push(s + l * i);
  }
  let end = busArr.length;
  if (busArr[start] > t) {
    res.push(busArr[start]);
  } else {
    while (start <= end) {
      let mid = parseInt((start + end) / 2);
      if (busArr[mid] == t) { // 버스시각이 목표시각과 같다면 탈출
        res.push(busArr[mid]);
        break;
      } else if (busArr[mid] > t) { // 버스시각이 목표시각 보다 크고 
        if (busArr[mid - 1] < t) { // 이전 버스시각이 목표시각보다 작다면 탈출
          res.push(busArr[mid]);
          break;
        } else {
          end = mid - 1;
        }
      } else start = mid + 1;
    }
  }
}
if (res.length > 0) {
  min = Math.min(...res);
}
console.log(min ? min - t : -1);