
# Clean Code란 무엇일까?

개발을 하다보면 가끔 내가 쓴 코드인데도 이해가 안되는 경우가 가끔 있다. 특히 시간이 지나서 보면 더 심하다. 아마 시간이 지나면서 문법이 달라졌을 수도 있겠지만, 결국 좋은 코드란 내가 아니라 **다른 사람이 봐도 쉽게 이해할 수 있는 코드**가 아닐까?
그냥 단순히 코드를 작성하는 건 어렵지 않다. 하지만 좋은 코드를 작성하는 건 또 다른 문제다. 특히 협업을 하다 보면 후반부엔 시간이 촉박해서 클린코드를 작성 하지 못하는 경우가 대다수다. 클린 코드란 과연 무엇일까?

## Clean code 란?

클린 코드는 단순히 "잘 정리된 코드"가 아니다. 유지보수성이 높고, 가독성이 뛰어나며, 의도가 명확한 코드다. 로버트 C. 마틴(Robert C. Martin)의 책 Clean Code에서는 클린 코드에 대한 여러 가지 원칙을 제시하는데, 그중에서 몇 가지 핵심 요소를 살펴보자.

## 클린 코드의 기준

### 의미 있는 이름 짓기

변수, 함수, 클래스 이름은 그 목적과 역할을 명확하게 드러내야 한다. 이름만 보고도 대략적인 기능이 떠올라야 한다.

❌ 안 좋은 예시:

```js
int d;
```

이게 날짜인지, 거리인지, 무슨 값인지 전혀 알 수 없다.

✅ 좋은 예시:

```js
int elapsedTimeInDays;
```

이름만 봐도 '경과 시간(일 단위)'라는 걸 알 수 있다. 이렇게만 해도 코드 읽는 속도가 확 달라진다.

프로젝트 초기에 `tempData`, `obj` 같은 애매한 변수를 많이 사용했었다. 그런데 시간이 지나고 보니 이 변수들이 어떤 역할을 하는지 전혀 기억나지 않았다. 결국 나중에 유지보수를 하면서 모두 의미 있는 이름으로 바꾸는 작업을 해야 했다. 처음부터 명확한 이름을 짓는 게 시간 절약이다.

### 그릇된 정보 피하기

이름을 지을 때, 잘못된 정보가 들어가면 오히려 혼란을 준다. 예를 들어 `accountList`라는 변수가 리스트가 아니라면?

❌ 안 좋은 예시:

```js
int accountList;
```

이름에 `List`가 들어가 있어서 배열이나 컬렉션 같은 느낌인데, 실제로는 `int` 형이다. 이러면 헷갈릴 수밖에 없다.

✅ 좋은 예시:

```js
int accountCount;
```

이렇게 정확한 의미를 전달하는 이름을 사용해야 한다.

### 함수는 한 가지 일만 하도록

하나의 함수가 여러 가지 일을 하면, 어디서 버그가 나는지도 파악하기 어렵다.

❌ 안 좋은 예시:

```js
public void processOrder(Order order) {
validateOrder(order);
calculateTotal(order);
applyDiscount(order);
saveToDatabase(order);
sendEmailConfirmation(order);
}
```

이 함수는 검증, 계산, 저장, 이메일 전송까지 전부 다 하고 있다. 만약 문제가 생긴다면 어디서 터진 건지 찾기도 어렵다.

✅ 좋은 예시:

```js
public void processOrder(Order order) {
if (!isValid(order)) {
throw new InvalidOrderException();
}
double total = calculateTotal(order);
double discountedTotal = applyDiscount(total);
saveOrder(order, discountedTotal);
sendConfirmationEmail(order);
}
```

각 작업을 따로 함수로 빼면 가독성이 좋아지고, 디버깅도 훨씬 쉬워진다.

유지보수하면서 가장 힘들었던 부분이 "이 함수가 대체 뭘 하는 거지?"였다. 함수가 너무 많은 역할을 하다 보니, 특정 기능만 수정하고 싶어도 부작용이 발생하는 경우가 많았다. 결국 함수는 작게 나누고, 한 가지 역할만 하도록 만들어야 한다는 걸 깨달았다.

### 명령과 조회를 분리하기

함수는 '무언가를 변경하는 명령'과 '값을 조회하는 기능'을 따로 나눠야 한다. 두 가지를 섞어버리면 코드가 예상과 다르게 동작할 수 있다.

❌ 안 좋은 예시:

```js
public boolean set(String attribute, String value) {
    // 설정 로직
}
if (set("username", "newUser")) {
    // 설정을 한 건지, 값을 조회한 건지 알 수 없음
}
```

✅ 좋은 예시:

```js
public void setAttribute(String attribute, String value) {
    // 설정 로직
}
public boolean isAttributeSet(String attribute) {
    // 조회 로직
}
```

이렇게 명령과 조회를 분리하면 코드의 의도가 훨씬 명확해진다.

### 코드 스타일 통일하기

코드 스타일이 들쭉날쭉하면 협업이 어려워진다. 카멜케이스(camelCase), 파스칼케이스(PascalCase), 스네이크케이스(snake_case) 등 일관된 네이밍 규칙을 유지해야 한다.

- **카멜케이스 (camelCase)**: 변수명, 함수명 (getUserData)

- **파스칼케이스 (PascalCase)**: 클래스명 (UserController)

- **스네이크케이스 (snake_case)**: 상수명 (MAX_CONNECTIONS)

### 불필요한 주석 줄이기

❌ 안 좋은 예시:

```js
// 사용자의 이름을 가져옴
String n = u.getNm();
```

✅ 좋은 예시:

```js
String userName = user.getName();
```

사실 이것저것 배우고 있기도 하고, 따로 주석이 없을 때 이해하기 힘든 부분이 확실히 있다고 생각하기 때문에 개인적으론 주석을 많이 다는 편이다.
다른 글들을 참고해보면 실행속도보단 읽어오는데서 오는 속도차이가 날 수 있다곤 하는데 간단한 프로그램에 주석을 **1.1mb** 달아서 테스트 해보면 **0.000011**초 정도 차이가 난다고 한다.
미미한 수준이지만 대규모 프로젝트로 갈수록 신경을 쓸 여지가 있다고 생각한다.

### 코드의 _*나쁜 냄새*_ 를 감지하고 제거하자

클린 코드를 유지하기 위해서는 _코드의 나쁜 냄새(Code Smell)_ 를 감지하고 수정하는 것이 중요하다. 대표적인 나쁜 냄새로는 아래와 같은 것들이 있다.

- 중복 코드: 같은 기능을 하는 코드가 여러 곳에서 반복되는 경우

- 긴 함수: 한 함수가 너무 많은 일을 하는 경우

- 의미 없는 변수명: 변수가 어떤 역할을 하는지 명확하지 않은 경우

- 과도한 주석: 주석이 없으면 이해하기 어려운 경우(주석 없이도 이해할 수 있도록 네이밍과 구조를 개선하는 것이 중요)

## 마무리하며

클린 코드는 단순히 **깔끔한 코드**가 아니라 **함께 일하기 좋은 코드**라고 생각한다. 유지보수가 어렵고 이해하기 힘든 코드는 결국 팀 전체의 생산성을 낮춘다.

내가 짠 코드가 나중에도 이해하기 쉽고 유지보수하기 좋다면, 그게 바로 좋은 코드가 아닐까?

아직도 클린 코드에 대해 배워가는 중이지만, 앞으로 더 좋은 코드를 짜기 위해 계속 고민해볼 생각이다. 개발자로서 성장하면서 클린 코드의 기준도 더 명확해질 거라고 믿는다.

## 관련 자료

https://www.samsungsds.com/kr/insights/cleancode-0823.html?referrer=https://talkwithcode.tistory.com/73
https://medium.com/naver-cloud-platform/%EB%84%A4%EC%9D%B4%EB%B2%84%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%8A%A4%ED%86%A0%EB%A6%AC-%EC%A2%8B%EC%9D%80-%EC%BD%94%EB%93%9C%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C-%ED%81%B4%EB%A6%B0%EC%BD%94%EB%93%9C-%EC%9D%B4%EC%95%BC%EA%B8%B0-c7811f73a46b


clean code에 관해


## 💡Back Tracking?

백트래킹은 깊이 우선 탐색(DFS)를 진행하며 탐색 중인 경로에 답이 없다고 판단되면 해당 노드를 제거하고, 탐색을 시작했던 부모 노드에서 바른 방향으로 다시 탐색
여기서 더 이상 탐색할 필요가 없는 노드를 제외하는 것을 **가지치기(Pruning)** 이라 하고
해당 경로에 답이 있다고 판단되는 경우에는 **유망하다(Promising)** 라고 합니다.
&nbsp;
즉, 백트래킹은 **DFS탐색을 진행하며 유망한 조건을 만족하는 방향으로만 탐색**하는 알고리즘!

### DFS(Depth-First Search)

- 깊이 우선 탐색으로 가능한 모든 경로를 탐색 (그래프에서 깊은부분을 우선적으로 탐색)
- 모든 경로를 탐색하는 특징으로 불필요할 것 같은 경로를 사전에 차단하지 않기 때문에 경우의 수를 줄이지 못합니다.

### 백트래킹(BackTraking)

- 해를 찾아가는 도중에 지금의 경로가 해가 될 거 같지 않으면, 더이상 깊이 들어가지 않고 이전 단계로 다시 돌아갑니다.(가지치기)
- 불필요한 부분을 쳐내고 최대한 올바른 방향으로 나아가는 방식이기 때문에 DFS보다 효율적입니다.

## 🔗백트래킹 탐색 과정

![backtracking](1.png)

## ♟♟문제 예시

![n-queen](2.png)

길이가 N인 체스판 위에 N개의 퀸이 서로 공격할 수 없도록 배치할 수 있는 경우의 수는?
&nbsp;

- 가지치기를 할 수 있는 경우의 수: 행, 열, 대각선
  - 가지치기를 위해 모든 경우의 수를 검사하게 되면 성능을 크게 낭비한다
  - 최대한 적은 비용으로 가지치기를 하기 위해 1차원 배열 사용
  - 배열의 index는 행의 위치, 해당 index의 value는 열의 위치
- ex) queen[2] = 1은 체스판 위에서 두번째 줄, 첫번째 칸에 해당
  - 위와 같은 데이터 형태를 잡으면 아래와 같이 잡을 수 있다
  - 한 index에 여러 value를 둘 수 없기에 행은 자연스럽게 가지치기 한다
  - index가 같다면 둘 수 없다. 같다면 가지치기
  - 행, 열에 대한 차가 같다면 대각선에 있다는 뜻이므로 가지치기
    &nbsp;

**핵심은 가지치기!!!**

### 결과 코드

![result](3.png)

### 출처

PGS 12952[N-Queen]


algorithm-backtracking


![image](nextjs-image2.webp)

# 개요

웹사이트 성능을 높이는 방법은 많지만, 가장 쉬우면서도 효과적인 방법 중 하나가 이미지 최적화입니다.
처음 Next.js를 사용하여 블로그를 만들 때는 이미지 최적화에 대해 깊게 생각하지 않았는데, 번들이나 다른 최적화를 알아보면서 next의 이미지 최적화에 대해 알아본 것을 정리하고자 합니다.
\
_+_ 추가적으로 lighthouse 성능도 체크해보았습니다.

# 왜 이미지 최적화를 해야 할까?

웹페이지에서 이미지가 차지하는 비중은 매우 큽니다. 특히, 사용자가 웹사이트를 방문할 때 가장 먼저 로드되는 요소 중 하나가 이미지이기 때문에, 이미지 최적화 여부가 페이지 속도와 사용자 경험에 직접적인 영향을 미칩니다.
페이지 로딩 속도가 느려지면 사용자는 쉽게 이탈하고, 이는 곧바로 SEO(검색 엔진 최적화)에도 영향을 미칩니다.
또한, Google Lighthouse에서는 이미지 최적화를 중요한 요소로 평가하며, 최적화되지 않으면 성능 점수가 낮아집니다.

이런 여러 이유도 있지만, 가장 중요한 것은 **사용자의 경험을 최적화**하는 것입니다.
로딩 속도가 빠르고, 데이터 사용량이 적으며, 선명한 이미지가 제공되는 환경은 결국 웹사이트의 성공과 직결되기 때문입니다. 그래서 Next.js를 사용할 때 이미지 최적화는 가장 먼저 고려해야 할 요소입니다.

## Next.js의 기본 이미지 최적화 기능

Next.js에는 `next/image`라는 강력한 이미지 최적화 컴포넌트가 있습니다.  
이걸 사용하면 자동으로 _웹 최적화된 포맷(WebP 등)으로 변환_, _지연 로딩(Lazy Loading) 지원_, _반응형 이미지 제공_ 같은 기능을 활용할 수 있습니다.

### ✅ 기존 `<img>` 태그 vs `next/image`

```js
// 일반 img 태그 사용
<img src='/images/sample.jpg' alt='일반 이미지' width={600} height={400} />;

// Next.js의 next/image 사용
import Image from "next/image";

<Image src='/images/sample.jpg' alt='최적화된 이미지' width={600} height={400} />;
```

기본 `<img>` 태그를 사용하면 브라우저가 직접 이미지를 처리하지만,
`next/image`는 자동으로 최적화를 적용해 줍니다.

### `next.config.js` 설정

```js
// 기존 config 파일에 images 설정 추가
const nextConfig = (phase) => {
  if (phase === PHASE_DEVELOPMENT_SERVER) {
    return {
      env: {
        ///
      },
      webpack: (config) => {
        config.resolve.fallback = { fs: false };
        return config;
      },
      images: {
        formats: ["image/avif", "image/webp"],
      },
    };
  }
};
```

기존 이미지들은 `avif` 파일로 변환, `avif`를 지원하지 않는 파일은 `webp`로 설정하였습니다.
\
_기존 이미지 크기_
![image](11.jpg)
\
\
_`avif` 변경 후 이미지 크기_
![image](22.jpg)

## Lighthouse에서 이미지 최적화 효과 확인하기

### 1) 이미지 최적화 적용 전 Lighthouse 점수

![image](33.jpg)

프로젝트에서 `<img>` 태그를 사용하고 Lighthouse로 성능을 측정하면
보통 Performance 항목에서 "Properly size images", "Serve images in next-gen formats" 같은 경고가 뜹니다.
제 경우에는 Performance 점수가 60점대로 나왔습니다.

### 2) next/image 적용 후 Lighthouse 점수

![image](44.jpg)

next/image로 변경한 후 다시 측정해 보니, Performance 점수가 90점 이상으로 올랐습니다.
특히 "Serve images in next-gen formats" 관련 경고가 사라졌고, LCP(최대 콘텐츠 표시, Largest Contentful Paint) 시간이 단축되었습니다.
_페이지 내부 사진이 몇 개 없어서 점수가 비약적으로 오른 것도 있습니다._

### 포스트 글에서 HTML의 동적 img 파일을 next/image로 변환할 때의 문제점

이 블로그는 썸네일 이미지의 경우 위 같은 방식으로 헤더 image 컴포넌트만 따로 `next/image`로 변환 할 수 있지만 포스트 내부의 이미지는 따로 `next/image` 로 바꾸는게 오히려 더 부담일 수 있다고 합니다. 찾아보니
_블로그 글의 내용이 Markdown이나 CMS에서 동적으로 가져오는 경우, `next/image`는 정적 최적화를 적용할 수 없어 오히려 SSR(Server-Side Rendering) 비용이 증가할 수 있습니다. 또한, `next/image`는 내부적으로 width와 height가 필요하지만 블로그 내부의 이미지들은 크기가 동적으로 결정되는 경우가 많아 이를 적용하기 어려운 경우가 많습니다. 추가적으로, `next/image`는 기본적으로 클라이언트 측 JavaScript 처리가 필요하므로, 단순한 블로그 콘텐츠라면 오히려 기본 `<img>`태그가 더 빠를 수 있다는 점도 고려해야 합니다. 따라서 정적 파일이나 특정한 이미지 최적화가 필요한 경우에는`next/image`를 사용하는 것이 좋지만, 블로그 글 내부의 `<img>` 태그는 그대로 두는 것이 더 나을 수 있습니다._
라고 합니다. 요약을 해보면,

- 단순한 블로그 내부 md파일은 이래저래 `<img>` 태그가 더 빠를 수 있다.
- `next/image`가 빌드 시 최적화된 이미지를 생성하는 방식이다.

라고 정리 할 수 있을 거 같습니다.

## 결론

전체 `<img>`파일을 `next/image` 로 바꾸진 못했지만, Lighthouse 점수 개선에 즉각적인 효과가 있는 것을 확인했습니다.
다른 폰트 최적화나 정적 리소스 최적화 등 다른 최적화도 이후 시도해 볼 예정입니다.


이미지 최적화로 성능 개선해보기


# 개요

[2차 팀 프로젝트](https://github.com/JJHHYB/deepvalley-front)에서 급하게 Infinite Scroll을 적용해야 하는 상황이 있었고, 당시엔 깊이 고민하지 못한 채 구현했다. 이번 포스팅에서는 무한 스크롤의 개념과 다양한 구현 방법, 그리고 성능 최적화 방안까지 상세히 살펴보려고 한다.

# Infinite Scroll이란?

사용자가 페이지를 아래로 스크롤할 때 콘텐츠를 지속적으로 로드하는 기술이다. 모바일 환경에 최적화된 UX 패턴이며, 페이지네이션(Pagination)과 비교했을 때 별도의 페이지 이동 없이 연속적인 데이터 로딩이 가능하다는 장점이 있다.

여러가지 구현 방식이 있지만 대표적으로 두 가지가 있다.

**Scroll 이벤트 감지 방식**

**Intersection Observer 방식**
각각의 방법을 살펴보면서 장단점과 최적화 방안을 고민해보자.

## Scroll 이벤트 방식

가장 직관적인 방법은 `window.scroll` 이벤트를 감지하는 것이다. 특정 위치에 도달하면 API 요청을 통해 데이터를 추가 로드하는 방식이다.

```js
function InfiniteScroll() {
  const fetchData = async () => {
    // API 호출 로직
  };

  const handleScroll = () => {
    const { documentElement } = document;
    const scrollHeight = documentElement.scrollHeight;
    const scrollTop = documentElement.scrollTop;
    const clientHeight = documentElement.clientHeight;

    if (scrollTop + clientHeight >= scrollHeight) {
      fetchData();
    }
  };

  useEffect(() => {
    window.addEventListener("scroll", handleScroll);
    return () => {
      window.removeEventListener("scroll", handleScroll);
    };
  }, []);
}
```

### 문제점

이 방법은 간단하고 직관적이지만, `scroll` 이벤트가 너무 자주 발생하여 성능 저하를 유발할 수 있다. 특히, 이런 블로그 형태나 실시간으로 fetch를 하는 지도API를 사용하는 경우 감지하는 이벤트가 계속 호출되기 때문에 렌더링 성능에 영향을 미칠 수 있다.

### 해결책

이를 개선하기 위해 Debounce 또는 Throttling 기법을 적용할 수 있다.

&nbsp; `Debounce` 일정 시간 동안 이벤트가 연속해서 발생하면 마지막 이벤트만 실행

&nbsp; `Throttling` 지정한 시간 간격마다 이벤트 실행

하지만 여전히 스크롤 이벤트를 감지해야 하기 때문에 불필요한 연산이 발생할 가능성이 있다.

## Intersection Observer 방식

이러한 문제를 해결할 수 있는 대안으로 `Intersection Observer`를 사용할 수 있다. 특정 요소가 뷰포트에 들어오는지를 감지하여 데이터를 로드하는 방식이다.

## 전체 코드

```js
import React, { useState, useEffect } from "react";
import { useInView } from "react-intersection-observer";

const InfiniteScroll = () => {
  const [items, setItems] = useState([]);
  const [page, setPage] = useState(1);
  const [ref, inView] = useInView();

  const fetchMoreData = async () => {
    const newItems = Array.from({ length: 10 }, (_, i) => `Item ${i + (page - 1) * 10 + 1}`);
    setItems((prevItems) => [...prevItems, ...newItems]);
    setPage((prevPage) => prevPage + 1);
  };

  useEffect(() => {
    if (inView) {
      fetchMoreData();
    }
  }, [inView]);

  return (
    <div>
      <ul>
        {items.map((item, index) => (
          <li key={index}>{item}</li>
        ))}
      </ul>
      {/* Intersection Observer 타겟 요소 */}
      <div ref={ref} />
    </div>
  );
};

export default InfiniteScroll;
```

### Custom Hook 설정

&nbsp; `Intersection Observer`를 활용하여 커스텀 훅을 특정 DOM 요소가 화면에 나타나는지를 감지하는 커스텀 훅을 구현한다.

- useInView
  특정 DOM 요소가 뷰포트에 진입했는지 여부 감지
- ref
  관찰할 DOM 요소에 연결
- inview
  요소가 뷰포트에 들어왔는지 여부를 나타냄

```js
const [ref, inView] = useInView();
```

![image](image.png)
이런식으로 특정 요소를 감지한다.

### 데이터 로드

&nbsp;`useEffect`를 사용하여 inView 값이 변경될 때마다 데이터를 로드한다.

요소가 뷰포트에 들어오면 `fetchMoreData`가 실행

```jsx
useEffect(() => {
  if (inView) {
    fetchMoreData();
  }
}, [inView]);
```

### 사용 예시

```js
const SampleList = () => {
  const dispatch = useDispatch();
  const { pageNumber, totalPageCount, list } = useSelector(selector);

  useEffect(() => {
    dispatch(fetch());
    return () => dispatch(clear());
  }, []);

  return (
    <InfiniteScroll
      isLoaded={list.length !== 0}
      pageNumber={pageNumber}
      totalPageCount={totalPageCount}
      trigger={() => dispatch(fetch())}
    >
      {list.map((item, index) => (
        <div key={index}>{item}</div>
      ))}
    </InfiniteScroll>
  );
};
```

## 마무리하며

이번 포스팅에서는 2차 팀 프로젝트에서 급하게 적용했던 Infinite Scroll을 다시 살펴보았다. 당시에는 단순한 scroll 이벤트 감지를 사용했지만, Intersection Observer 방식이 더 적절한 방법임을 알게 되었다. 프리페치(pre-fetching)나 Skeleton UI를 통해 최적화를 시킬 수도 있지만 일단은 원시적인 방법으로 찾아보았다. 앞으로는 성능 최적화와 UX까지 고려한 무한 스크롤 구현을 고민해봐야겠다.

## 출처

사진
https://velog.io/@oneook/Intersection-Observer-%EB%B7%B0%ED%8F%AC%ED%8A%B8-%EB%85%B8%EC%B6%9C-%EA%B0%90%EC%A7%80-APIs
http://brianyang.com/infinite-scroll-techniques-in-react/


Infinite Scroll 알아보기


## 개요

Next.js 애플리케이션의 번들 사이즈가 커지면 성능 저하와 로딩 속도 문제를 초래할 수 있습니다. \
따라서 번들 크기를 최소화하는 것은 UX/UI의 중요한 요소입니다.

## 번들 사이즈 확인하기

Next.js는 빌드 시 next build 명령어를 실행하면 각 페이지의 번들 사이즈를 분석하여 제공합니다.
빌드가 완료되면 터미널에서 각 페이지의 번들 크기를 확인할 수 있습니다. 특히 First Load JS 크기를 줄이는 것이 중요합니다.
또한, @next/bundle-analyzer 패키지를 사용하여 시각적으로 번들 내용을 분석할 수도 있습니다.

```js
npm install @next/bundle-analyzer
```

`next.config.js` 파일을 수정하여 분석 기능을 활성화할 수 있습니다.

```js
const withBundleAnalyzer = require("@next/bundle-analyzer")({
  enabled: process.env.ANALYZE === "true",
});

module.exports = withBundleAnalyzer({});
```

\
이제 다음 명령어를 실행하면 번들 분석 페이지를 확인할 수 있습니다.

```js
ANALYZE=true next build
```

## 불필요한 패키지 제거 및 경량화

불필요한 패키지를 제거하고 가벼운 대체 패키지를 사용하는 것도 효과적인 방법입니다.

### Moment.js 대체

moment.js는 매우 크므로 `date-fns` 또는 `dayjs` 같은 가벼운 라이브러리로 교체하는 것이 좋습니다.

`npm install date-fns`

```js
import { format } from "date-fns";

const date = new Date();
console.log(format(date, "yyyy-MM-dd"));
```

### Lodash 최적화

&nbsp;`lodash`를 사용할 경우 필요한 기능만 개별적으로 임포트하면 번들 크기를 줄일 수 있습니다.

```js
import debounce from "lodash/debounce";
```

## 코드 스플리팅 활용하기

Next.js는 기본적으로 코드 스플리팅을 지원하지만, 아래 방법을 추가하면 더욱 최적화할 수 있습니다.

### 동적 로딩 (next/dynamic)

&nbsp;`next/dynamic`을 사용하면 특정 컴포넌트를 필요할 때만 로드할 수 있습니다.

```js
const HeavyComponent = dynamic(() => import("../components/HeavyComponent"), {
  ssr: false,
});

export default function Page() {
  return <HeavyComponent />;
}
```

**ssr: false 옵션을 사용하면 클라이언트 사이드에서만 로드됩니다.**

### Webpack Chunking 활용

Next.js 12부터 Webpack 5가 기본 적용되며, splitChunks 설정을 통해 번들을 최적화할 수 있습니다. next.config.js에서 설정을 조정할 수 있습니다.

```js
module.exports = {
  webpack(config) {
    config.optimization.splitChunks = {
      chunks: "all",
    };

    return config;
  },
};
```

## 이미지 및 폰트 최적화

### next/image 사용

Next.js의 next/image 컴포넌트를 사용하면 이미지 최적화가 가능합니다.

```js
import Image from "next/image";

<Image src='/example.jpg' width={500} height={300} alt='Example' />;
```

### 폰트 최적화

웹 폰트를 직접 로드하면 번들 크기가 증가할 수 있습니다. next/font를 활용하여 폰트를 최적화할 수 있습니다.

```js
import { Inter } from "next/font/google";

const inter = Inter({ subsets: ["latin"] });
```

## 환경 변수 및 설정 최적화

### production 모드에서 개발 코드 제거

&nbsp; `process.env.NODE_ENV` 를 활용하여 개발용 코드가 프로덕션 번들에 포함되지 않도록 할 수 있습니다.

```js
if (process.env.NODE_ENV === "development") {
  console.log("이 코드는 개발 환경에서만 실행됩니다.");
}
```

### Tree Shaking 활성화

ESM(ES Modules)을 지원하는 라이브러리를 사용하면 Tree Shaking이 활성화됩니다. `package.json`에서 `sideEffects: false`를 추가하면 불필요한 코드가 제거됩니다.

```js
"sideEffects": false
```

## 마무리

번들 크기 분석 (@next/bundle-analyzer 활용)

불필요한 패키지 제거 및 경량화 (moment.js 대체, Lodash 최적화)

코드 스플리팅 (next/dynamic 활용, Webpack 최적화)

이미지 및 폰트 최적화 (next/image, next/font 활용)

환경 변수 및 설정 최적화 (production 모드, Tree Shaking 활성화)


Next.js 번들 사이즈 최적화


## 개요

<img src="1.jpg" width="400" height="200" alt="yarn" />

[1차프로젝트](https://github.com/gooormmoon/algorithm-fighter-front) 때 npm을 쓰면서 여러가지 이유모를? 오류들이 종종 발생해서 꽤나 애를 먹었습니다. 예를들어, 팀원과 동일한 패키지 버전을 설치했는데도 팀원들과 환경이 달라지거나, 네트워크 문제로 패키지 설치가 중단되는 경우가 있었는데 그 때 Yarn으로 패키지를 바꾼 후 이런 문제들이 눈에 띄게 줄어들었습니다.
이번 글에선 Yarn의 설치 방법과 사용법을 공유하면서, npm에서의 문제들이 Yarn을 통해 어떻게 해결되었는지도 이야기 해보려고 합니다.

### npm을 사용하면서 겪었던 문제

- 의존성 충돌: npm은 `package-lock.json`을 사용해 의존성 버전을 관리하지만, 팀원들 간 환경 차이로 동일한 설정에서도 설치되는 모듈 버전이 달라지는 문제가 발생했습니다.
- 캐싱 기능 부족: 한 번 설치한 패키지도 다시 설치할 때마다 네트워크를 통해 내려받아야 했습니다.

이러한 문제들이

- 일관성 있는 의존성 관리: `yarn.lock` 파일을 통해 동일한 패키지와 버전을 유지할 수 있어, 팀 프로젝트 시 환경 차이로 인한 오류가 줄었습니다.
- 강력한 캐싱 기능: 이미 설치한 패키지는 오프라인에서도 재설치할 수 있어 네트워크 문제를 피해갈 수 있었습니다.

## Yarn 설치

Yarn은 다양한 운영 체제에서 설치할 수 있습니다.

### macOS

Homebrew를 사용한 설치 방법입니다.

```js
brew install yarn
```

NVM(Node Version Manager)과 같은 버전 관리 툴을 사용한다면 Node.js 설치를 제외할 수 있습니다.

```js
brew install yarn --without-node
```

### Windows

Windows에서는 Chocolatey 또는 Scoop을 사용하여 설치할 수 있습니다.

```js
# Chocolatey
choco install yarn

# Scoop
scoop install yarn
```

## npm을 사용한 설치

npm을 통해 Yarn을 설치할 수도 있습니다.

```js
npm install -g yarn
```

### 설치 확인

Yarn이 올바르게 설치되었는지 확인하려면 다음 명령어를 사용합니다.

```js
yarn --version
```

### 환경 변수 설정

전역 사용에 문제가 있다면 Path 설정을 추가해야 합니다. `.profile` `.bash_profile` `.bashrc` `.zshrc` 파일에 다음을 추가합니다.

```js
export PATH="$PATH:/opt/yarn-[version]/bin"
```

## Yarn 사용법

Yarn은 NPM을 사용해 본 경험이 있다면 쉽게 사용할 수 있습니다.

### 프로젝트 초기화

프로젝트를 시작할 때 `package.json`을 생성하려면 다음 명령어를 사용합니다.

```js
yarn init
```

### 의존성 모듈 설치

`package.json`으로부터 의존성 모듈을 설치할 때는 다음과 같이 명령어를 입력합니다.

```js
yarn

# 또는

yarn install
```

### 패키지 추가

의존성 모듈을 추가하려면 `yarn add` 명령어를 사용합니다.

```js
yarn add [package]
yarn add [package]@[version]
yarn add [package]@[tag]
```

다른 범주의 의존성을 추가할 수도 있습니다.

```js
# 개발용 의존성

yarn add [package] --dev

# Peer 의존성

yarn add [package] --peer

# 선택적 의존성

yarn add [package] --optional
```

### 패키지 업그레이드

패키지를 업그레이드하려면 다음 명령어를 사용합니다.

```js
yarn upgrade [package]
yarn upgrade [package]@[version]
yarn upgrade [package]@[tag]
```

패키지 제거

불필요한 패키지를 제거할 때는 다음과 같이 입력합니다.

```js
yarn remove [package]
```

### yarn.lock 파일

`yarn.lock` 파일은 설치된 모듈의 버전을 저장하여 어디서나 동일한 버전과 구조의 의존성을 유지할 수 있게 합니다. `yarn install` 명령어를 실행할 때 자동으로 생성되며, `package-lock.json`과 비슷한 역할을 합니다.

### 참고

https://yarnpkg.com/


Yarn 설치 및 사용법


## 개요

next 프로젝트를 하면서 있었던 에러 정리

## 오류 목록

### Failed to process byte index 6 is out of bounds of '\ude'

**원인**
udemy 프로젝트를 하는 중, 프로젝트 폴더 이름이 `ude...` 로 작성되어서 생긴 오류

**해결 방안**
프로젝트의 폴더 이름을 바꾸거나 `ude`로 시작하지 않는 다른 경로로 이동

**참조**

https://stackoverflow.com/questions/77278303/next-js-13-error-byte-index-out-of-bounds-on-npm-run-dev

### Module not found: Can't resolve 'fs'

**원인**
클라이언트 측에서 `nodejs` 라이브러리를 사용하려고 할 때 발생하는 오류

**해결 방안**
루트 디렉토리에 `next.config.js` 생성 후 아래와 같이 설정

_webpack4_

```js
const nextConfig = {
  reactStrictMode: true,
  webpack: (config, { isServer }) => {
    // Fixes npm packages that depend on 'fs' module
    if (!isServer) {
      config.node = {
        fs: "empty",
      };
    }

    return config;
  },
};

module.exports = nextConfig;
```

_webpack5_

```js
const nextConfig = {
  reactStrictMode: true,
  webpack5: true,
  webpack: (config) => {
    config.resolve.fallback = { fs: false };

    return config;
  },
};

module.exports = nextConfig;
```

**참조**
https://cocoon1787.tistory.com/851

### Image 컴포넌트의 layout 속성오류

![error1](error1.jpg)

**원인**
Next.js 13 이상에서 `<Image>` 컴포넌트를 사용할 때 `layout` 속성이 더 이상 지원되지 않는다는 경고문
찾아보니 `Image`컴포넌트에 `layout`속성이 추가되어 있었다😂

**해결 방안**
&nbsp; `layout` 속성을 없애거나 아래 자동 변환 도구 사용(codemod 실행)

```js
npx @next/codemod next-image-to-legacy-image ./src
```

**참조**
https://nextjs.org/docs/messages/next-image-upgrade-to-13


next 트러블 슈팅


## getStaticProps를 통한 정적 생성

`getStaticProps`는 빌드 시점에 데이터를 미리 가져와 정적 페이지를 생성하는 함수입니다. 이 방식은 블로그 포스트나 제품 목록과 같이 자주 변경되지 않는 데이터를 다룰 때 특히 유용합니다.

**주요 특징**

- 빌드 타임에 실행되어 정적 HTML 생성
- 클라이언트 측에서 실행되지 않아 보안 크리덴셜 사용 가능
- 빠른 페이지 로딩 제공

```js
function HomePage({ products }) {
  return (
    <ul>
      {products.map((product) => (
        <li key={product.id}>{product.title}</li>
      ))}
    </ul>
  );
}

export async function getStaticProps() {
  return {
    props: {
      products: [{ id: "p1", title: "제품 1" }],
    },
  };
}

export default HomePage;
```

동적 라우팅을 사용하는 페이지에서는 getStaticPaths를 통해 사전 생성할 경로들을 지정할 수 있습니다.

### fallback 옵션

**false**
정의되지 않은 경로는 404 반환

**true**
새로운 경로를 동적으로 생성

**blocking**
SSR과 유사하게 새 페이지 생성 후 응답

```js
export async function getStaticPaths() {
  return {
    paths: [{ params: { pid: "p1" } }, { params: { pid: "p2" } }],
    fallback: "blocking",
  };
}
```

## getServerSideProps를 통한 서버 사이드 렌더링

실시간 데이터가 필요한 페이지에서는 getServerSideProps를 사용하여 요청 시점에 데이터를 가져올 수 있습니다.

```js
export default function UserPage({ userData }) {
  return <div>{userData.name}</div>;
}

export async function getServerSideProps(context) {
  const { params } = context;

  return {
    props: {
      userData: {
        id: params.uid,
        name: "사용자 이름",
      },
    },
  };
}
```

## 메서드 비교

| 메서드             | 실행 시점 | 사용 사례     | 장점                |
| ------------------ | --------- | ------------- | ------------------- |
| getStaticProps     | 빌드 시   | 정적 콘텐츠   | 빠른 로딩, CDN 캐싱 |
| getStaticPaths     | 빌드 시   | 동적 라우트   | 효율적인 정적 생성  |
| getServerSideProps | 요청 시   | 실시간 데이터 | 최신 데이터 보장    |

### 사용 시 고려사항

- getStaticProps/getStaticPaths
  - 데이터가 자주 변경되지 않는 경우 적합
  - CDN 캐싱의 이점 활용 가능
  - 빌드 시간이 길어질 수 있음
- getServerSideProps
  - 실시간 데이터가 필요한 경우 사용
  - 매 요청마다 서버 리소스 사용
  - SEO가 중요한 동적 콘텐츠에 적합


Next의 데이터 페칭


# 개요

![deep-valley-hero](deep-valley.jpg)
**deep-valley 프로젝트 회고 (2차)**
프로젝트 기간 : 2024.06.26 - 2024.07.12
프로젝트에 대한 상세 정보는 [여기](https://github.com/JJHHYB/deepvalley-front)에서 확인하실 수 있습니다.

## 프로젝트 소개

- 사용자의 위치를 기반으로 주변 계곡을 쉽게 찾고, 상세 정보를 확인할 수 있는 서비스입니다.
- 로그인/회원가입으로 계정을 만들어 계곡에 대한 리뷰를 작성하고 관리할 수 있습니다.
- 사용자는 계곡의 수영 가능 여부, 야영 시설, 주차장 유무 등 필수 정보를 한눈에 확인할 수 있습니다.
- 실시간 날씨 정보와 함께 수심, 연락처 등 안전한 물놀이를 위한 상세 정보를 제공합니다.

## 담당 파트

페이지 단위로 파트를 나누어 담당하였고, 저는 지도 페이지, 계곡 상세 페이지, 리뷰 페이지를 담당하였습니다.

## **기술 스택**

🖥 Frontend
![front-stack](front-stack.png)
🖥 Backend
![back-stack](back-stack.png)
🖥 CI/CD
![CICD](CICD.png)

## 초기 세팅 🔧

**데일리 스크럼**
매일 오전 10시 30분 아침 회의 Todo list 체크 및 진행 예정사항 공유 -> 돌아가면서 회의록 작성
오후 18시 30분 Todo list 체크 및 진행상황 공유 → 숨김없이, 정확하게, 프로젝트에 관한 모든 내용을 공유
![daily-scrum](scrum.jpg)
**BE/FE 세팅**
각 업무를 페이지 단위로 세분화 -> 각 페이지를 맡은 BE 및 FE 가 서로 자유롭게 회의

## 4L

### Liked (좋았던 점) 👍

오전, 오후 데일리 스크럼을 진행하면서 팀원들의 진행 상황을 빠르게 파악할 수 있었고, 이를 통해 자연스럽게 협업이 이루어졌습니다. 특히, 이슈가 발생했을 때 혼자 고민하기보다 팀원들과 함께 논의하고 해결해 나가는 과정이 유익했습니다. 또한, 백엔드 팀과의 원활한 소통 덕분에 API 연동 과정에서 예상보다 빠르게 작업을 마무리할 수 있었습니다.

### Learned (배운 점) 📚

이번 프로젝트에서는 계곡 관련 공공 API를 활용하면서 데이터 구조를 이해하는 과정이 필요했습니다. 단순히 API를 호출하는 것뿐만 아니라, 불필요한 데이터를 정리하고 필요한 정보만 추려서 사용자에게 제공하는 것이 중요하다는 걸 깨달았습니다.
또한, 지도 기반 서비스를 개발하면서 좌표 데이터를 다루는 경험을 쌓을 수 있었습니다. 프론트엔드에서 백엔드 API를 어떻게 효율적으로 소비할지 고민한 것도 큰 배움이었습니다.
![discord1](discord1.jpg)
_최종 API 데이터😭_

### Lacked (부족했던 점) 🤦‍♂️

기본적인 서비스 로직은 빠르게 정리되었지만, 세부적인 기능을 설계하는 과정에서 추가 논의가 필요했던 부분이 많았습니다.
리뷰 기능을 구현할 때 단순한 댓글 형식이 아니라 별점과 사진 업로드 같은 요소를 추가하는 과정에서 설계 변경이 잦았고, 이로 인해 일정 조정이 필요했습니다. 또한, 프론트엔드와 백엔드 간의 데이터 형식에 대한 정의가 초반에 명확하지 않아 몇 번의 수정 작업이 발생한 점도 아쉬웠습니다.

### Longed For (바라는 점) 😼

CI/CD 파이프라인을 자동화하면서 몇 가지 시행착오를 겪었는데, 이런 부분도 초반에 더 깊이 이해하고 시작했으면 좋았을 것 같다는 아쉬움이 남습니다. 다음 프로젝트에서는 이런 경험을 바탕으로 더 체계적으로 접근하고 싶습니다.

### 프로젝트를 마치며

이번 프로젝트를 통해 단순히 기능을 구현하는 것뿐만 아니라, 팀으로서 함께 협력하는 과정이 얼마나 중요한지 다시 한번 깨닫게 되었습니다. 특히, 프론트엔드와 백엔드 간의 소통이 원활해야 개발 속도가 배가된다는 점을 실감했습니다.
API 명세를 정리하는 과정에서 예상치 못한 어려움을 겪기도 했지만, 이를 해결하면서 실무에서 요구하는 협업 방식에 대해 더 깊이 이해할 수 있었습니다.
처음 다뤄보는 지도 API와 공공 데이터를 활용하는 과정에서 기술적으로도 많은 성장을 할 수 있었습니다.
이번 경험을 발판 삼아 다음 프로젝트에서는 더 나은 협업 방식과 기술적 깊이를 가져갈 수 있도록 노력해야겠습니다. 함께 고생한 팀원들 모두 너무 감사했고, 앞으로도 다들 원하는 목표를 이루길 바랍니다! 🚀💪


[깊은산골짜기] 팀 프로젝트 회고


# 개요

![algorithm-fighter-hero](algorithm-fighter-hero.gif)
**Algorithm fighter 프로젝트 회고**
프로젝트에 대한 상세 정보는 [여기](https://github.com/gooormmoon/algorithm-fighter-front)에서 확인하실 수 있습니다.

# 프로젝트

프로젝트는 원래 프론트엔드 3명, 백엔드 2명으로 구성된 5명의 팀이었으나, 한 명이 취업으로 나가게 되어 급하게 백엔드 인원을 구해야 했습니다. 대부분의 팀이 이미 구성된 상태에서 갑작스럽게 백엔드를 모집하다 보니 인원이 부족해 다른 인원이 부족한 팀과 합쳐지게 되었고, 이로 인해 이전에 세웠던 기획들이 잘 융화되지 않아 다시 기획을 짜는 데 시간이 걸렸습니다. 늦게 시작한 만큼 빠르게 기획하고 실행하기 위해 노력하였습니다.

## 프로젝트 설계

디자이너가 없는 상황에서 **Figma**를 활용해 기본적인 UI 구조를 설계하였으며, 재사용 가능한 컴포넌트들을 조합하여 UI를 완성하고자 하였습니다. Typescript를 사용해본 팀원이 있어 **Typescript**로 진행하였고, **Tailwind**는 빠르게 수정 가능한 점과 유지보수의 용이성 덕분에 선택되었습니다.

## **기술 스택**

🖥 Frontend

- React, Typescript, Tailwind, SCSS(SASS), Zustand, Axios, Monaco

🖥 Backend

- Spring, Java, MySQL, Docker, Stomp

🖥 Deployment

- AWS EC2 Github Actions

## Liked (좋았던 점) 👍

백엔드와 협업하는 프로젝트는 처음이었는데, 함께한 프론트 팀원 중 경험자가 있어 기획 관련 도움을 받을 수 있었고 뿐만아니라 현업에 종사하시는 프론트 멘토분의 세부적인 지원이 있어서 좀 더 편하게 할 수 있었던 것 같습니다. \
_프로젝트에 관한 현실적 가능성, 진행상황 피드백, UI/UX, 테스트 케이스 여부, 보안 관련, 웹 접근성, 무한 스크롤, vite 마이그레이션 등_ \
협업 툴로 Github를 사용하면서 git의 다양한 기능을 경험할 수 있었고, **추후 이 경험이 다음 프로젝트에 많은 도움이 되었습니다**. 주말에도 따로 일정이 없을 때 대부분 프론트 팀원분들이 디스코드에 있으셔서 피드백을 빠르게 주고받을 수 있어 좋았습니다.

## Learned (배운 점) 📚

리액트에서 타입스크립트를 처음 사용해보았지만, 타입을 지정하는 방법에 대해 완벽하진 않더라도 어느 정도 사용할 수 있게 되었습니다. \
사용자 입장에서 UI/UX를 다시 한번 깊이 있게 고민할 수 있는 기회를 가졌습니다.
팀 프로젝트를 위해 개발 규칙이나 팀 문화를 만들어가는 과정을 통해 팀 프로젝트의 흐름에 대해 배울 수 있었습니다.

## Lacked (부족했던 점) 🤦‍♂️

기획 중 팀이 해체되었다 합쳐진 팀이라 주제선정 때 시간적 여유가 없어서 프로젝트 주제가 생각보다 복잡해져 기술적인 한계가 있었습니다. \
처음 사용하는 기술들이 많고 시간도 부족하다 보니, 상세히 이해하지 않고 사용한 기술이 정상적으로 작동되면 그냥 넘어가는 경우가 많았습니다. \
스스로 팀 규칙을 잘 지켰는지 생각해보면 그렇지 않은 것 같습니다. 특히 1, 2번의 이유로 하나의 작업을 하는 데 시간이 좀 걸렸던 것 같습니다. 그러다 보니 후반에 맡은 기능 구현을 급하게 하다 보니 다른 팀원의 PR에 신경을 많이 쓰지 못한 것 같습니다.

마감 전날까지 시간이 빠듯해서 기능 구현에만 집중하다 보니 리팩토링 및 성능 최적화는 잘되지 않은 것 같아 아쉽습니다. 이외에도 추가 구현 기능들이 몇 가지 있었는데, 시간이 없어 하지 못했습니다.

## Longed For (바라는 점) 😼

개인 프로젝트를 한 번 진행해보고 새로운 것들을 적극적으로 사용해보고 싶습니다. 다음 프로젝트 전까지 사용한 기술을 다시 한번 확인해보려 합니다.

## 프로젝트를 마치며

필수 기능은 어느 정도 구현되었지만, 완벽한 오류 처리를 하지 못한 점과 추가 기능 중 게임 느낌을 더할 수 있는 UI/UX를 구현하지 못한 것이 아쉽습니다. 프론트와 백엔드 팀원들이 주말 새벽까지 열심히 작업해주신 것을 알고 있기 때문에, 이런 자잘한 것들이 더 아쉬운 것 같습니다. 개인 역량을 늘리는 것이 중요하다고 생각하여, 2차 프로젝트 전까지 부족한 기술을 보충해나갈 계획입니다.


Algorithm fighter 팀 프로젝트 회고


## 문제 설명

조이스틱으로 알파벳 이름을 완성하세요. 맨 처음엔 A로만 이루어져 있습니다.

ex) 완성해야 하는 이름이 세 글자면 AAA, 네 글자면 AAAA

조이스틱을 각 방향으로 움직이면 아래와 같습니다.
▲ - 다음 알파벳
▼ - 이전 알파벳 (A에서 아래쪽으로 이동하면 Z로)
◀ - 커서를 왼쪽으로 이동 (첫 번째 위치에서 왼쪽으로 이동하면 마지막 문자에 커서)
▶ - 커서를 오른쪽으로 이동 (마지막 위치에서 오른쪽으로 이동하면 첫 번째 문자에 커서)

예를 들어 아래의 방법으로 "JAZ"를 만들 수 있습니다.

- `첫 번째 위치에서 조이스틱을 위로 9번 조작하여 J를 완성합니다.
- 조이스틱을 왼쪽으로 1번 조작하여 커서를 마지막 문자 위치로 이동시킵니다.
- 마지막 위치에서 조이스틱을 아래로 1번 조작하여 Z를 완성합니다.
  따라서 11번 이동시켜 "JAZ"를 만들 수 있고, 이때가 최소 이동입니다.`

만들고자 하는 이름 name이 매개변수로 주어질 때, 이름에 대해 조이스틱 조작 횟수의 최솟값을 return 하도록 solution 함수를 만드세요.

## 제한 사항

- name은 알파벳 대문자로만 이루어져 있습니다.
- name의 길이는 1 이상 20 이하입니다.

## 입출력 예

| name     | return |
| -------- | ------ |
| "JEROEN" | 56     |
| "JAN"    | 23     |

### 1차 실패

<img src="1.png" width="400" height="300" alt="ex" />

테스트케이스 일부 합

왕복설정 X 갔다가 돌아오는것도 조건에 포함 시켜야 함

### 2차 통과(구글)

<img src="2.png"  alt="ex" />

-1. 처음부터 끝까지 쭉 비교하는 경우

=> name.length

-2. 처음부터 시작하다가 A 뭉텅이를 만났을 때, 다시 뒤로 가서 A 뭉텅이 끝난 이후 단어부터 시작하는 경우

=> i\*2 + name.length - idx

ex) BBBAAAAAAABA

i*2 : 다시 첫 단어로 돌아가는 횟수. 여기서는 첫번째 A까지 갔다가 뒤로 돌아가므로 2(i) * 2 = 4 // 4
name.length - idx : 길이 - A 뭉텅이가 끝난 다음 단어의 위치 => 여기서는 12 - 10 = 2 // 2 3. 연속된 A의 앞쪽보다 뒷쪽이 짧은 경우, A 뭉텅이 길이 이용하여 맨 뒤에서 시작하는 경우

=> i + 2 \* (name.length - idx)

2 \* name.length - idx : 'A 뭉텅이 끝난 다음 단어부터 비교하고 다시 맨 앞으로 돌아오는 횟수
(맨 뒤 A-> 뒤에서 두번째 B(1번) -> A 뭉텅이 제일 마지막 A(2번) -> 뒤에서 두번째 B(3번) ->맨 뒤 A(4번) // 4
i : 다시 처음으로 돌아온 후 좌우 이동 횟수(B->B->B) // 2


algorithm-조이스틱


## 문제 설명

한국중학교에 다니는 학생들은 각자 정수 번호를 갖고 있습니다. 이 학교 학생 3명의 정수 번호를 더했을 때 0이 되면 3명의 학생은 삼총사라고 합니다. 예를 들어, 5명의 학생이 있고, 각각의 정수 번호가 순서대로 -2, 3, 0, 2, -5일 때, 첫 번째, 세 번째, 네 번째 학생의 정수 번호를 더하면 0이므로 세 학생은 삼총사입니다. 또한, 두 번째, 네 번째, 다섯 번째 학생의 정수 번호를 더해도 0이므로 세 학생도 삼총사입니다. 따라서 이 경우 한국중학교에서는 두 가지 방법으로 삼총사를 만들 수 있습니다.

한국중학교 학생들의 번호를 나타내는 정수 배열 number가 매개변수로 주어질 때, 학생들 중 삼총사를 만들 수 있는 방법의 수를 return 하도록 solution 함수를 완성하세요.

## 제한사항

- 3 ≤ number의 길이 ≤ 13
- 1,000 ≤ number의 각 원소 ≤ 1,000
- 서로 다른 학생의 정수 번호가 같을 수 있습니다.

## 입출력 예

<img src="ex.png" width="400" height="200" alt="ex" />

## 입출력 예 설명

- 입출력 예 #1
  문제 예시와 같습니다.
- 입출력 예 #2
  학생들의 정수 번호 쌍 (-3, 0, 3), (-2, 0, 2), (-1, 0, 1), (-2, -1, 3), (-3, 1, 2) 이 삼총사가 될 수 있으므로, 5를 return 합니다.
- 입출력 예 #3
  삼총사가 될 수 있는 방법이 없습니다.

### 나의 풀이

```jsx
function solution(number) {
  let answer = 0;
  for (let i = 0; i < number.length - 2; i++) {
    for (let j = i + 1; j < number.length - 1; j++) {
      for (let k = j + 1; k < number.length; k++) {
        if (number[i] + number[j] + number[k] === 0) {
          answer++;
        }
      }
    }
  }
  return answer;
}
```

### 2차 풀이 (구글)

```jsx
const NUM = 3;

function solution(number) {
  let ans = 0;
  const tmp = [];
  const backtrack = (cur) => {
    if (tmp.length === NUM) {
      ans += tmp.reduce((a, b) => a + b) ? 0 : 1;
      return;
    }

    for (let i = cur; i < number.length; i++) {
      tmp.push(number[i]);
      backtrack(i + 1);
      tmp.pop();
    }
  };

  backtrack(0);
  return ans;
}
```

중복을 허용해 r개 뽑는 경우 (순서 상관 X) (조합)

- 탐색 중인 인덱스(cur)를 인자로 설정하고, **다음 탐색에 i + 1을** 넘긴다.
- 현재 값 이후의 값만 선택하도록 해 중복을 제거한다.


algorithm-삼총사


## 개요

## 문제점

### Dependencies

- Node.js@20
- React@18
- Next.js@14
- TypeScript@5
- next-contentlayer
- vercel

### Rendering

### 그 외

## 마치며
