
## ErrorBoundary 를 분석 및 조사하며

리액트 프로젝트를 진행하며 에러를 감지하기 위해 ErrorBoundary를 사용하고는 해요. 저는 React의 `ErrorInfo` 혹은 `react-error-boundary` 패키지를 지금까지 사용해왔고 이전의 실무 프로젝트에서 적용하였어요.

try-catch를 통한 error 객체를 이용한 로직이 아닌 React 16 버전부터 도입된 ErrorBoundar를 통해 비동기 호출에 대한 에러 처리를 하는 것이에요.

Redux, Recoil 등의 상태관리 라이브러리를 통해 API 호출에 대한 error를 분기처리를 한다그러면 API를 호출하는 모든 컴포넌트에 해당 상태값을 조정하는 로직이 포함되어야 하기 때문에 반복되는 코드가 많아지고 불편하다는 단점을 가지고 있죠. 이 때 ErrorBoundary를 통하여 프로젝트를 감싸 하위 컴포넌트 트리에서 발생한 에러를 잡아 선언적으로 처리를 할 수 있어요.

그러면 이에 대한 예시를 살펴보죠

```ts
function MainPage() {
  return (
    <PageA />
  )
}

function PageA() {
  const dispatch = useDispatch();
  const error = useSelector((state: RootState) => state.error.message);

  const handleClick = () => {
    dispatch(fetchData());
  };

  if(error) {
    return <div>현재 페이지에 문제가 발생하였습니다.</div>
  }

  return (
    <main>
      <h1>API 요청 테스트</h1>
      <button onClick={handleClick}>데이터 가져오기</button>
    </main>
  );  
}
```
현재 위 방식은 API를 통하여 에러가 발생할 경우 error 여부를 통한 에러 컴포넌트를 렌더링 하고 있습니다. 
그렇다면 이러한 방식의 에러처리는 어떠한 문제를 야기할 수 있을까요?

```list
- Redux로 에러를 전역으로 관리하면 다른 컴포넌트의 에러까지 영향을 주진 않을까?
- API 요청이 여러 개인 경우 어떤 요청에서 발생한 에러인지 구분할 수 있을까?
- 에러를 초기화하지 않으면 이전 에러가 화면에 남아 사용자 경험을 망치지 않을까?
- 에러 발생 시 전체 화면이 전환된다면 사용자는 당황하지 않을까?
```

이러한 문제점들이 발생할 수 있죠. 그러면 이러한 문제들을 해결하기 위해 ErrorBoundary를 적용해보죠.

## ErrorBoundary를 통해 API 에러를 처리하기
```ts
// ErrorBoundary
interface ErrorProps {}

interface ErrorState {
	hasError: boolean;
}

class ErrorBoundary extends React.Component<ErrorProps, ErrorState> {

	constructor(props: ErrorProps) {
		super(props);
		this.state = {
			hasError: false,
		};
	}

	static displayName = 'ErrorBoundary';

	static getDerivedStateFromError(): ErrorState {
		return { hasError: true };
	}

	render(): React.ReactNode {
		if (this.state.hasError) {
			return (
				<div>Fallback 에러발생</div>
			);
		}
		return this.props.children;
	}
}

export default ErrorBoundary;
-----------------------------------------------------------
// MainPage
import ErrorBoundary from '';

function MainPage() {
  return (
    <ErrorBoundary>
      <PageA />
    </ErrorBoundary>
  )
}
```

이처럼 구성한 ErorrBoundary는 렌더링 중에 발생된 에러를 catch 하게 됩니다.
즉 ErrorBoundary로 감싸진 하위 트리에서 발생하는 catch 하는 것입니다.

이러한 개념을 확장하고 형태를 참고하여 프로젝트마다 필요한 error 성격에 따라서 다양한 ErrorBoundary를 구성할 수 있습니다.

```list
- ApiErrorBoundary – API 요청 중 발생한 에러를 감지하고 사용자에게 재시도 UI를 제공
- NetworkErrorBoundary – 오프라인 상태나 네트워크 장애에 대응
- AuthErrorBoundary – 인증 실패나 토큰 만료에 따른 리다이렉트 처리
- RootErrorBoundary – 앱 전체를 감싸는 전역 에러 처리 컴포넌트
```

에러의 종류나 위치에 따라 ErrorBoundary를 구분하면 더 유연하고 상황에 맞는 에러 대응이 가능해지겠죠.


## 마지막으로
지금까지 Redux 상태로 에러를 처리하는 방식의 한계와 ErrorBoundary를 활용한 선언적 에러 처리 방식에 대해 알아봤어요.
에러는 언제 어디서든 발생할 수 있고 이를 어떻게 효율적이고 사용자 친화적으로 처리하느냐는 프로젝트의 완성도를 크게 좌우합니다.
ErrorBoundary는 단순히 예외를 막는 도구를 넘어 에러의 종류별로 책임을 나누고 사용자 경험을 지키는 수단이 될 수 있습니다.
프로젝트의 구조나 상황에 맞게 ErrorBoundary를 유연하게 설계한다면 분명 더 탄탄하고 안정적인 앱을 만들 수 있을 것 같다고 생각이 드네요.

React의 ErrorBoundary를 활용해 컴포넌트 단위로 오류를 감지하고 에러 상황에 유연하게 대응할 수 있는 에러 처리 패턴을 소개합니다.

ErrorBoundary 분석 및 error 처리


## 들어가기 앞서
프로젝트들을 진행하며 공통 부분은 굉장히 중요한 부분이에요. 프로젝트에 투입이 된다면 구조를 파악하고 다음으로 보게될 부분 중 하나이죠. 이 중 공통 컴포넌트를 살펴보죠. 
잘 만들어진 공통 컴포넌트를 사용한다면 개발을 진행할 때 편리함과 완성도를 높여주는데요. 그러면 한번 확인해보죠.

```caution
환경: react, typeScript, scss
```


### 공통 컴포넌트, 왜 써야할까요?

```ts
// ****.scss
.buttonStyle {
    border: solid 1px red;
}
----------------------------------------------
import styles from './****.scss';

// ButtonA component
export default function ButtonA() {
  return <button className={styles.buttonStyle} />;
}

// ButtonB component
export default function ButtonB() {
  return <button className={styles.buttonStyle} />;
}

// ButtonC component
export default function ButtonC() {
  return <button className={styles.buttonStyle} />;
}
```

위 코드에서 A, B, C 버튼이 각각의 컴포넌트로 나뉘어 있네요. 이렇게 구성하면 유지보수가 어렵고 확장성도 떨어지게 됩니다. 이처럼 `재사용성이 낮은 컴포넌트를 반복해서 만드는 일`은 피해야 하겠죠. 대신 하나의 공통 컴포넌트로 통일하면 더욱 유연한 구조를 만들 수 있습니다.

```list
그럼 공통 컴포넌트를 만들 때 어떤 점들을 고려해야 할까요?
```

이것은 공통 컴포넌트를 개발하는 개발자마다 관점이 다르다고 생각해요. 

첫 째로 구축한 공통 컴포넌트를 여러 곳에서 사용할 수 있게끔 해야겠죠. 혼자만 쓸 것이 아니고 다른 팀원들과도 함께 써야하니 이러한 상황도 고려하는게 좋겠죠.

둘 째로 props에 어떤 데이터를 둘 것 인가요?
만약 제가 이커머스 사이트 프로젝트에서 공통 컴포넌트를 구축하고 있어요. 각각의 버튼의 재사용성과 확장성을 위해 'plus', 'minus', 'order','cart', 'up-arrow', 'down-arrow' 이에 맞는 icon을 넣고 'red', 'default', 'green' 의 테마가 들어있는 theme도 넣을거에요. 버튼의 크기도 다를 수 있지 않나요? 크기에 대한 prop인 size도 넣을게요!

그러면 여기서 물어볼게요. props를 통해 버튼의 다양한 상태를 조절할 수 있지만 해당 props가 유연하다고 생각하시나요? padding, margin 등의 다양한 css를 적용시키기에는 어느정도 한정되어있죠. 만약 정말로 유연한 공통 컴포넌트를 만들고 싶다면 props가 3개가 아닌 5개, 10개 이상도 될 수 있겠죠. 이처럼 모든 상황을 variant로 대응하기는 쉽지 않아요.

```list
제한이 있다면 className을 props로 받으면 안되나요?
```

저는 공통 컴포넌트에 어느 정도 제한이 필요하다고 생각해요.
프로젝트의 디자인 시스템을 유지하면서도 유연함을 제공하려면 기본적인 스타일은 고정하고, 정말 필요한 경우에만 className을 통해 커스터마이징할 수 있게 하는 것이 좋겠죠.

## Button에 대한 공통 컴포넌트를 만들어 봐요.
ButtonA, ButtonB, ButtonC 를 하나로 통합한다면 텅 빈 DOMElement가 되겠죠?

```ts
export const Button = () => {
    return <button />;
};
```

여기서 아이콘, 테마, 크기에 대한 props에 대한 인터페이스를 활용하여 확장성을 높여보죠.

```ts
// Button.types.ts

// 테마
export const Themes = [
    'string',
    'default',
    'default-sub',
] as const;
export type Theme = (typeof Themes)[number];

// 아이콘
export const Icons = [
    'plus',
    'minus',
    'order',
    'cart',
    'up-arrow',
    'down-arrow',
] as const;
export type Icon = (typeof Icons)[number];

// 아이콘 위치
export const IconPosition = ['left', 'right'] as const;
export type IconPosition = (typeof IconPosition)[number];

// 버튼 사이즈
export const Sizes = [
    's',
    'm',
    'l',
] as const;
export type Size = (typeof Sizes)[number];

export interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
    className?: string;
    theme?: Theme;
    icon?: Icon;
    iconPosition?: IconPosition;
    size?: Size;
}
```

이렇게 공통 컴포넌트의 사용자가 요구사항에 따른 적절한 variant을 적용하여 디자인에 적용할 수 있도록 할 수 있죠. 또한 인터페이스의 상속과 rest parameters인 버튼에 대한 DOMElement를 사용하여 확장성 있는 설계를 하였어요. 추가로 classNames 라이브러리를 통해 디자인에 대응도 해보죠.

```ts
import classNames from 'classnames';
import { ButtonProps } from './Button.type';
import styles from './Button.module.scss';

export const Button = ({ 
    className, 
    theme = 'default', 
    icon, 
    iconPosition = `left`, 
    size='m', 
    ...props
}: ButtonProps) => {
    return (
        <button
            className={classNames(styles[`size-${size}`], className)}
            data-theme={theme}
            data-icon={icon}
            icon-position={iconPosition}
            {...props}
        />
    );
}
```

이제 모든 상황에도 대응이 가능하며 본래의 책임이 있는 버튼 UI 컴포넌트가 완성이 되었어요. 여기서 추가로 리액트에서 요소 참조를 위해 사용하는 ref를 위해 forwardRef로 감싸보죠. 이를 통해 경우에 따라 작용할 수 있는 외부에서 특정 DOM 요소에 ref로 접근할 수 있도록 할게요.

```ts
import classNames from 'classnames';
import { forwardRef } from 'react';
import { ButtonProps } from './Button.type';
import styles from './Button.module.scss';

export const ButtonBase = forwardRef<HTMLButtonElement, ButtonProps>(
	(
		{ onClick, type = 'button', size = 'max', className, disabled, ...props },
		ref
	) => {
		return (
			<button
				ref={ref}
				className={classNames(styles.button, styles[`size-${size}`], className)}
				type={type}
				disabled={disabled}
				onClick={onClick}
				{...props}
			/>
		);
	}
);
```

이제 이 Button 컴포넌트는 UI뿐만 아니라 기능적으로도 유연한, 실용적인 공통 컴포넌트가 되었어요.

## 마지막으로
공통 컴포넌트는 단순히 하나로 묶는 것에서 끝나지 않아요. 어떤 상황에서도 일관성 있게 사용할 수 있어야 하며 필요에 따라 유연하게 확장도 가능해야 합니다. 또 다른 개발자들과의 협업을 고려한 구조도 중요합니다.

잘 만들어진 공통 컴포넌트 하나는 프로젝트 전반의 생산성과 유지보수성을 크게 향상시킬 수 있다는 것을 알려드리고 싶었어요.

유연성과 일관성을 갖춘 실용적인 공통 버튼 컴포넌트 설계 방법

실용성 있는 공통 컴포넌트 만들기 위해서는 어떻게 해야할까요


## React를 실무에서 개발할 수 있는 경험을 하다니
리뉴얼 개발 프로젝트의 개발 환경은 크게 `React, TypeScript, Next.js, Redux`로 구성되어 있어요. 현재 가장 인기 있고 실제로 많이 쓰이는 기술들이라 그런지 굉장히 설레기도 했고 한편으로는 긴장도 많이 됐죠.

각 기술은 단순히 강의에만 의존하지 않고 강의나 유튜브로 기초를 다진 다음 공식 Document를 최대한 많이 참고하려고 했어요. 그리고 공부한 내용을 바탕으로 동일한 환경의 간단한 개인 프로젝트도 직접 진행해봤어요. 그렇게 공부하다 보니 처음엔 많이 어렵던 것들도 점점 익숙해졌어요. 이 날을 위해서 지금까지 운영과 유지보수의 과정들과 그동안 해왔던 공부와 스터디, 개인프로젝트들이 빛을 밝힐 시간이었죠.

프로젝트 초반과는 다르게 PM님께서는 저에게 많은 부분을 개발할 수 있도록 맡겨주었죠. 덕분에 다양한 경험을 할 수 있었고 개발에 대한 자신감도 조금씩 쌓였어요.

그러면 리뉴얼 프로젝트에서 제가 맡게 된 주요 개발 항목들도 정리해볼게요.

## 내가 맡은 기능과 영역들

```list
* 공통 Header 개발: 로고, 문구, 견적/주문, 장바구니, 문의,로그인/로그아웃 등 구현
* 카테고리 페이지 및 서브·말단 카테고리 UI 설계 및 개발
* 검색 기능 개발: 검색창, 주문, 장바구니, 배너, 상품 정보 미게재 주문 지원
* 공통 플로팅 바 구현: 상품 추천, CAD, 비교하기, 견적/주문 등 기능 개발
* 공통 유저 기능 개발: 권한 관리, 가격 확인, 장바구니, 마이부품표, 회원 정보 및 배송 정보 관리
* 메인 페이지 설계 및 개발
* 브랜드 페이지 UI 개발
* 상품 비교 기능 및 비교 페이지 구현
* AA 및 GA 연동 및 데이터 분석 기능 개발
```

![메인페이지.webp](https://d2ut7x8yqv441q.cloudfront.net/posts/1750102461514.webp)

홈페이지를 개발할 때는 영역별로 우선순위가 있죠. 해당 리스트를 참고해서 1순위, 2순위를 정하면 모든 페이지에 공통으로 들어가야 하는 Header, 플로팅 바, 공통 유저 기능 같은 것들이 1순위가 되고 그 외 기능들은 2~3순위로 나뉘게 됩니다. 그래서 제가 맡은 공통 컴포넌트들을 빠르고 완성도 높게 개발해야 이후 다른 기능들도 문제없이 진행될 수 있었어요.

리뉴얼 프로젝트는 PC버전과 Mobile버전으로 구분되어 있었고 각 버전별로 따로 개발을 진행해야 했어요. 로컬스토리지를 활용해 사용자의 디바이스 정보를 저장하고 Next.js를 기준으로 _app.tsx 파일을 _app.pc.tsx, _app.mobile.tsx처럼 구분해서 각 디바이스에 맞는 타겟을 호출할 수 있도록 설정했어요. 버전이 분리되다 보니 파일 수도 많아지고 자연스럽게 속도 문제가 생길 수 있었는데 이런 부분을 고려해서 공통 모듈, UI 컴포넌트, 공통 함수 등 자주 사용하는 부분은 최대한 모듈화하려고 노력했어요.

### 렌더링 속도를 빠르게
이커머스 특성상 이미지가 많이 보여질 수밖에 없다고 생각해요. 그 중 메인페이지와 카테고리 페이지는 한 페이지에 최대 100개가 넘는 이미지가 로드되어 렌더링 속도 저하문제가 심했죠. 그러면 이미지로 인해 발생하는 속도 저하 문제는 어떻게 해결하는 것이 좋을까요?

```list
Amazon S3 + CloudFront CDN 도입
```

첫 번째로는 이미지 서빙 방식의 개선이었어요. 기존에는 모든 정적 파일을 웹 서버에서 직접 제공하고 있었는데 이렇게 되면 서버에 부하가 집중되면서 전체적인 응답 속도가 느려질 수밖에 없었어요. 

Amazon S3에 모든 이미지 파일을 업로드하고 CloudFront CDN을 통해 전 세계 어디서든 빠르게 접근할 수 있도록 구성했어요. CDN의 장점은 사용자와 가장 가까운 서버에서 이미지를 제공하기 때문에 물리적 거리로 인한 지연시간을 최소화할 수 있다는 점이죠.

```ts
// 이미지 URL 구성 예시
const getOptimizedImageUrl = (imagePath, width = 300) => {
    return `https://cdn.cloudfront.net/images/${imagePath}?w=${width}&q=80`;
};
```

두 번째로는 두 번째는 지연 로딩(Lazy Loading) 전략이었어요. 모든 이미지를 한꺼번에 로드하는 게 아니라 사용자가 실제로 보게 될 이미지만 우선적으로 로드하는 방식으로 변경했어요.

페이지 내 컴포넌트들을 다음과 같이 우선순위를 나누어 처리했어요

```list
* 1순위 (즉시 로드)
  - 메인 배너 이미지
  - 로고 및 네비게이션 아이콘
  - 첫 화면에 보이는 상품 이미지

* 2순위 (조건부 로드)
  - 스크롤 시 나타나는 상품 이미지들
  - 탭 전환 시 보이는 이미지들

* 3순위 (필요시 로드)
  - 모달이나 팝업 내 이미지들
  - 하단 푸터 영역 이미지들
```

다음으로는 Intersection Observer API를 활용한 동적 이미지 로드에요. 사용자가 스크롤해서 특정 이미지가 뷰포트에 들어올 때까지는 실제 이미지를 로드하지 않고 들어오는 순간에 로드하는 방식이죠.

```ts
// Intersection Observer 구현 예시
const useImageLazyLoading = () => {
    const [imageRef, setImageRef] = useState(null);
    const [isLoaded, setIsLoaded] = useState(false);

    useEffect(() => {
        if (!imageRef) {
            return;
        }

        const observer = new IntersectionObserver(
            ([entry]) => {
                if (entry.isIntersecting && !isLoaded) {
                setIsLoaded(true);
                observer.disconnect();
                }
            },
            { 
                threshold: 0.1 
            }
        );

        observer.observe(imageRef);
        return () => observer.disconnect();
    }, [imageRef, isLoaded]);

    return { setImageRef, isLoaded };
};
```

이러한 작업들을 통해 초기 렌더링 속도를 체감될 정도로 단축시킬 수 있었어요. 다시 생각해보니 뿌듯하네요.

### 공통 UI 컴포넌트를 통해 보다 더 효율성있게
리뉴얼 전 기존 사이트는 UI의 일관성이 없어 아쉬운 점이 많았어요. 버튼, 체크박스, 셀렉트 박스 등 조금씩 제각각인면이 있었죠. 여기서 React의 장점들이 빛을 발하죠.

```list
- 재사용성: 한 번 만든 컴포넌트를 여러 곳에서 반복 사용 가능
- 모듈화: 각 UI 요소를 독립적인 모듈로 관리
- 조합 가능: 작은 컴포넌트들을 조합해서 복잡한 UI 구성
```

이러한 장점을 통해 공통 UI 컴포넌트를 구성해 보았어요.

```ts
// Button 테마
const Themes = [
	'strong',
	'primary',
	'default',
	'sub',
	'secondary',
] as const;
export type Theme = (typeof Themes)[number];

// Button 아이콘
export const Icons = [
	'arrow',
	'order',
	'cart',
	'check',
	'plus',
	'minus',
	'comment',
] as const;
export type Icon = (typeof Icons)[number];

// Button 아이콘 위치
export const IconPosition = ['left', 'right'] as const;
export type IconPosition = (typeof IconPosition)[number];

export type ButtonProps = ButtonBaseProps & {
	theme?: Theme;
	icon?: Icon;
	iconPosition?: IconPosition;
};
```

이처럼 각각의 UI 컴포넌트를 공통으로 사용할 수 있게끔 타입을 지정하고 스타일링을 해주면 도입 후 개발 속도도 빨라지고 디자인의 일관성으로 보기도 좋아진다고 생각해요. 또한 유지보수에도 장점이 증가하겠죠? 예를 들면 "모든 버튼의 모서리를 좀 더 둥글게 만들어달라"는 요청이 들어왔을 때 Button 컴포넌트 한 곳만 수정하면 전체 사이트에 일괄 적용이 되기 때문에 간편해지죠.

### 상품 비교 기능과 비교 페이지를 만들어보자

한국미스미는 제조업의 자동화·효율화를 위한 모든 부품 판매하는 기업이에요. 일반적인 상품들과는 다르게 각 부품의 스펙이 mm 단위로 쪼개지고 다양하죠. 또한 이러한 스펙들을 통해서 가격도 천차만별이라 비교할 수 있는 기능이 도입된다면 사용자들은 좀 더 효율적으로 이용할 수 있겠죠.

상품 비교 버튼의 위치와 동작 상품을 비교할 수 있는 비교 버튼은 상품 상세 페이지에 위치해 있어요. 사용자가 해당 페이지에서 원하는 모든 스펙(사이즈, 재질 등)을 설정하고 '비교' 버튼을 클릭하면, 해당 상품이 비교 리스트에 추가되는 방식이죠.

![플로팅 바 비교 팝업.webp](https://d2ut7x8yqv441q.cloudfront.net/posts/1750105549724.webp)

비교 상품 관리 시스템 최대 5개까지의 상품을 동시에 비교할 수 있도록 제한을 두었고, 선택된 비교 상품들은 모든 페이지 하단에 고정된 플로팅 바를 통해 실시간으로 확인할 수 있어요. 사용자가 어떤 페이지를 이동하더라도 비교 리스트가 유지되어 편리하게 상품들을 관리할 수 있도록 했죠.

Redux와 LocalStorage 기반 상태 관리 상품 비교 기능은 Redux와 LocalStorage를 조합한 방식으로 개발했어요. Redux를 통해 앱 전체에서 비교 상품 상태를 관리하고, LocalStorage에 데이터를 저장해서 브라우저를 새로고침하거나 재방문해도 이전에 선택한 비교 상품들이 그대로 유지되도록 구현했어요. 또한 Date 인터페이스를 사용해 일정 시간이 지나면 자동으로 초기화될 수 있게끔 설정해 놓았죠.

```ts
// 비교 Redux 일부 예시

export const loadCompare = (sdispatch: Dispatchtore) => {
    const compare = localStorage.getItem('compare');
    if (!!compare) {
        return () => {
            dispatch(compareAction.update(compare));
        };
    }
    return () => { return dispatch(compareAction.update([]));}
}

const slice = createSlice({
    name: 'compare';
    reducers: {
        update(state, action: PayloadAction<CompareProduct[]>) {
			return {
				...state,
				compare: action.payload,
			};
		},
    }
});
```

전역 접근 가능한 UI 플로팅 바는 모든 페이지에서 필수적으로 표시되는 고정 영역으로 설계했어요. 이를 통해 사용자가 사이트 어디에서든 비교 상품을 관리할 수 있도록 했죠.

다양한 관리 기능 제공 플로팅 바에서는 다음과 같은 기능들을 제공해요:

```list
개별 상품 삭제: 특정 상품만 비교 리스트에서 제거
전체 삭제: 비교 리스트의 모든 상품을 한 번에 삭제
개별 선택: 원하는 상품만 선택해서 비교 페이지로 이동
전체 선택: 리스트의 모든 상품을 선택
비교 실행: 선택된 상품들의 상세 비교 페이지로 이동
```

이렇게 구현된 상품 비교 기능을 통해 사용자들이 여러 상품의 스펙을 체계적으로 비교하고 최적의 선택을 할 수 있도록 도움을 주었어요


### 지훈 주임님 SEO 데이터 수집이 되질 않아요.
```point
SEO 크롤링 문제 해결 과정은 아래 URL의 게시글에 정리해 놓았어요!
```
https://www.baakhan.com/posts/CSR과-SSR을-활용한-SEO-크롤링-대응처리/


## 마무리
모든 프로젝트의 경험은 개발자라는 길에 있어서 뼈와 살이 되는 것 같아요. 제가 요즘에 스스로에게도 하는 말이며 고민을 갖고 있는 분들에게 항상 하는 말이 있어요.
`기회는 찾아오는 것이 아니며 계속 움직이는 나에게 다가오는 것이다.`
마지막 프로젝트를 진행하면서 스스로에게 부족한 부분이 보이며 제자리인 느낌이 계속 들었어요. 저는 이 순간에도 가만히 방황하지 않으며 무엇인가 하려고 했죠. 이것이 독서일 수도 개인 프로젝트가 될 수도 있죠. 저는 진행했던 React 프로젝트를 복습하고 제 것으로 만들고싶어 같은 환경으로 경력기술서와 지금의 블로그를 만들었죠. 바위처럼 클 수도 소금처럼 작을 수도 있지만 이렇게 쌓다보면 언젠가는 제가 원하는 탑의 모양이 나오지 않을까요?

낯선 기술 스택 습득부터 모던 프론트엔드 리뉴얼까지. PHP/RxJS/Twig 환경에서 React/TypeScript로의 대전환 프로젝트를 통한 개발자 성장 스토리!

Php, RxJS에서 React, TypeScript로의 대전환 - 이커머스 리뉴얼 실무 경험 2편


## 이커머스 프론트엔드 리뉴얼개발 및 유지보수
이커머스 프로젝트에 투입되기 전 정확한 날짜는 정해지지 않았지만 React를 이용하여 리뉴얼개발이 진행된다는 소식을 듣고 프로젝트에 투입되었어요. 홈페이지의 전체적인 흐름을 알아야 리뉴얼개발이 진행될 때 어려움없이 개발을 진행할 수 있기 때문이죠. 그렇기 때문에 먼저 유지보수 인력으로 투입되었죠. 해당 프로젝트는 크게 3개로 나뉘었어요. `이커머스, 마이페이지, 리뷰 및 문의` 이를 관리하고 신규 개발 건이 있을 경우 진행하였죠.

### 프론트엔드 유지보수/운영은 어떻게 하는거죠?
처음 프로젝트에 투입되었을 때 낯선 기술들이 정말 많았어요. `Php, Rxjs, Twig` 등 들어는 봤지만 한번도 접해보지 못한 기술들을 사용했어요. 또한 소스의 구조가 이해하기 힘들었고 데이터의 흐름이 정말 복잡하였죠. 해당 프로젝트의 회사의 본사는 일본에 있으며 국제적인 회사에요. 중국, 독일, 프랑스 등 여러 나라에 있죠. 일본에 있는 서버의 API를 이용하여 데이터를 받아오며 백엔드는 Php를 프론트엔드는 Javascript, Jquery 가 기본이 되며 Rxjs, Twig를 사용하고 있죠. 그러면 Rxjs와 Twig란 무엇일까요?

```point
- Rxjs란?
JavaScript에서 사용할 수 있게 해주는 라이브러리입니다. 다양한 비동기 이벤트 스트림을 효율적으로 처리할 수 있도록 도와줍니다.

- Twig란?
Twig는 PHP를 위한 템플릿 엔진입니다. HTML 문서 안에 PHP 로직을 깔끔하게 삽입할 수 있도록 도와줍니다.
```

이 중 Rxjs의 개념을 익히고 이를 적용하는데에 시간이 오래걸린 것 같아요.

해당 프로젝트에 이전부터 계신 PM님께서는 자신의 밑에 있는 개발자들에게 자신이 원하는 수준까지 올라오지 않으면 일을 주지 않으셨어요. 저는 PM님에게 인정받고 싶어 정말 많이 노력한 결과 3~4개월 정도가 지나서야 개발을 할 수 있었죠. 이전에는 간단한 수정 건만 진행했다면 이후에는 하나의 파트를 맡아 책임을 질 수 있었어요. 새로운 개발 건이나 UI/UX 개선이 들어올 경우 일본에서 오는 문서를 확인하여 개발을 진행하였죠.

### 요청을 받았으면 일을 해야지!
한국미스미에 들어와서 가장 처음으로 맡았던 개발 건은 GA4 및 이에대한 이벤트 트래킹을 구축하는 것이었어요. 

![GA4이미지.webp](https://d2ut7x8yqv441q.cloudfront.net/posts/1750098417939.webp)

Universal Analytics 종료 그리고 GA4로의 전환
2023년 7월 Universal Analytics(UA) 서비스 종료 발표와 함께 Google Analytics 4(GA4)로의 전면 전환이었죠. 기존에 UA로 수집하던 모든 데이터를 GA4 방식으로 재구축해야 하는 상황이었어요.

처음에는 단순히 분석 도구만 바꾸는 정도로 생각했는데 막상 시작해보니 완전히 다른 데이터 수집 방식이라 거의 처음부터 다시 구축해야 하는 수준이었어요. UA는 세션 기반이었다면 GA4는 이벤트 기반이라 근본적인 접근 방식부터 달랐거든요.

```list
* 페이지뷰(PV): 모든 페이지의 기본 방문 데이터
* 상품 관련 이벤트: 상품 조회, 상품 스펙 확인, 장바구니 추가
* 구매 관련 이벤트: 견적 요청, 주문 완료, 결제 프로세스
* 검색 이벤트: 사이트 내 검색어, 필터 사용, 정렬 기준 변경
```

지라 티켓을 통해 요구서와 정의서가 들어오고 해당 문서를 참고하여 개발을 진행했어요. 여기서 가장 큰 문제는 모든 문서가 일본어로 작성되어 있다는 점이었죠.

좀 더 정확하고 완벽하게 개발하려면 문서를 꼼꼼히 읽어야 하는데 언어 장벽 때문에 항상 "혹시 중요한 부분을 놓치고 있는 건 아닐까?"라는 불안감이 있었어요.

이를 해결하기 위해 조금씩 일본어 공부를 시작했고 회사에 일본어를 할 줄 아시는 분들께 애매한 부분을 조심스럽게 물어보며 개발을 진행하게 되었어요. 시간이 지날수록 문서 이해도가 높아지면서 더 정확한 개발을 할 수 있게 되었죠.

### UI/UX를 좀 더 맛있게 만들어 봐

`AS-IS`
![ASIS.webp](https://d2ut7x8yqv441q.cloudfront.net/posts/1750099459916.webp)

`TO-BE`
![TOBE.webp](https://d2ut7x8yqv441q.cloudfront.net/posts/1750099463232.webp)

UI/UX는 이커머스 사이트에서 사용자 경험은 곧 매출과 직결되는 부분이에요. 아무리 좋은 상품이 있어도 사이트가 불편하면 고객들은 금세 다른 곳으로 떠나버리거든요. 그래서 이번 리뉴얼에서는 단순히 디자인만 예쁘게 바꾸는 게 아니라 실제 사용자의 행동 패턴을 분석해서 불편한 지점들을 하나씩 개선해나가는 데 집중했어요. 작은 애니메이션과 인터랙션 효과들이 사용자 경험에 미치는 영향은 생각보다 크다고 생각해요. 버튼을 클릭했을 때의 호버 효과, 로딩 상태를 보여주는 스피너, 성공/실패 상태를 알려주는 토스트 메시지 등 마이크로 인터랙션을 뜻하죠.

특히 상품을 장바구니에 담을 때 작은 애니메이션과 함께 "장바구니에 담겼습니다"라는 메시지가 나타나도록 했는데 이런 작은 피드백이 사용자의 만족도를 크게 높였어요. 이커머스 사이트는 정보량이 방대하기 때문에 정보 우선순위에 따른 시각적 계층 구조가 정말 중요해요. 사용자의 시선이 자연스럽게 중요한 정보부터 훑을 수 있도록 레이아웃을 설계가 필요하죠.

이커머스의 특성상 사용자마다 권한과 할인율이 다르기 때문에 사용자 권한에 따른 UI 분기 처리가 필수였어요. 일반 사용자, 기업회원, 구매연계계정 등 각각의 권한에 따라 메인페이지가 달라져요. 또한 이전 구매 이력이나 관심 카테고리를 바탕으로 메인페이지의 추천 상품 영역을 개인화해서 보여주는 기능도 추가했어요. 같은 페이지라도 사용자마다 다른 경험을 제공할 수 있게 된 거죠.

### 그루비 API를 이용한 상품 추천 배너 기능
그루비 API의 장점은 이것이죠 실시간 데이터 학습과 다양한 추천 알고리즘을 제공한다는 점이 매력적이었죠. 추천 시스템의 정확도는 결국 데이터의 품질과 양에 달려있어요.

그루비 API의 데이터는 가장 먼저 상품 데이터를 그루비측에서 수집해 가야해요. 이벤트를 통해 그루비측에 상품 데이터를 전달하고 그 데이터를 기반으로 각 영역에 상품을 추천하는 것이죠.

```list
* 상품 조회 이벤트: 어떤 상품을 몇 번 봤는지
* 구매 이벤트: 실제 구매로 이어진 상품들의 연관성
* 장바구니 이벤트: 함께 담은 상품들의 패턴
* 검색 이벤트: 검색어와 클릭한 상품의 관계
```

```js
// 그루비 API 전송 예시
let payload = {
    name: '',                        
    code: '',
    amt: 0,
    prc: 0, 
    salePrc: 0,
    cnt: 0,
    brandNm: ''
};
groobeeAPI.push(payload);

groobee("XX", { 
    goods: payload
});
```

그렇게 수집했던 데이터를 통해 상품을 추천하는 것이죠 각 영역마다 다른 추천 알고리즘을 적용하고, 배너의 디자인과 문구도 맥락에 맞게 다르게 구성했어요.

```list
상품 상세 페이지: "이 상품을 본 고객들이 함께 구매한 상품"
상품 카테고리 페이지: "이 카테고리에서 인기 있는 상품"
검색창: "이 검색어로 찾은 다른 고객들이 함께 본 상품"
```

![그루비 카테고리.webp](https://d2ut7x8yqv441q.cloudfront.net/posts/1750100410915.webp)

추천 기능 도입 약 2개월 후 성과를 분석해보니 새로운 기분을 느꼈어요. 재방문율 15% 증가, 상품 전환율 23% 향상 등 제가 개발했던 추천 영역을 통해 매출이 늘어난다는 것이 너무 신기하고 새로웠어요.

무엇보다 이 기능을 통해 데이터 기반 개발의 중요성을 다시 한번 깨달을 수 있었어요. 단순히 기능을 만드는 것을 넘어서 실제 비즈니스 임팩트까지 측정하고 개선해나가는 경험이 정말 보람찼던 것 같아요.


Php, RxJS에서 React, TypeScript로의 대전환 - 이커머스 리뉴얼 실무 경험 1편


## 사내 홈페이지 신규개발
한화생명 프로젝트에서 철수한 뒤 회사 홈페이지를 새롭게 만드는 프로젝트를 진행하였어요. 저를 많이 아껴주시는 이사님께서 제 주도하에 내부 직원들과 홈페이지를 구축하라고 전달하셨고 저는 홈페이지를 기획 및 개발까지 모두 참여하였어요. 기존 홈페이지 UI는 정말 오래된 옛날 홈페이지의 UI이었고 동료 2분과 함께 총 3명에서 사내 홈페이지를 개발했죠.

가장먼저 홈페이지를 개발할 때 요구사항은 세가지였어요.

```list
1. 관리자페이지를 통하여 홈페이지를 관리할 수 있도록 함
2. 최신 트렌드 홈페이지에 맞게 스크롤링을 통한 UI가 구성될 수 있도록 함
3. 한글, 영문페이지가 있도록 함
```

이러한 요구사항이 들어왔고 IT 회사에 맞게 홈페이지의 템플릿과 레퍼런스 찾아갔죠. 레퍼런스를 찾았으면 홈페이지의 사이트맵을 최대한 자세히 만드려고 했어요.

### 사내 홈페이지 기획단계
![사이트맵.webp](https://d2ut7x8yqv441q.cloudfront.net/posts/사이트맵.webp)

이처럼 구체적으로 전체 페이지를 잡고 회사의 얼굴이 될 메인페이지와 각 서브페이지를 기획하였어요. 각 사업부 부장님들에게 부서를 소개할 페이지들에 사진 및 자료들을 요청하였어요.

![메인페이지.webp](https://d2ut7x8yqv441q.cloudfront.net/posts/1750089218492.webp)

다행이라 생각했던 것이 로그인하고, 무엇을 판매하고, 구매 및 글을 작성하고 이러한 이커머스 속성이 없는 홈페이지며 회사를 얼마나 아름답게 표현할 수 있느냐만 홈페이지에 담기만 하면 되기때문에 복잡하고 어려운 기능들이 없었어요. 즉 홈페이지의 UI 디자인적 요소가 가장 중요한 것이죠.

### 관리자 페이지 CMS 도입 및 개발
요구사항 중 첫 번째! CMS 연동 및 콘텐츠 관리 기능 개발을 하는 것이죠. 이렇게 메인페이지와 서브페이지 설계가 완료되었으면 이제 본격적으로 관리자 페이지를 만들어야 했어요.

![cms.webp](https://d2ut7x8yqv441q.cloudfront.net/posts/1750089963121.webp)

관리자 페이지는 이전 OJT 프로젝트 때 만들었던 CMS 시스템을 참고하여 개발 기간을 최대한으로 단축시킬 수 있도록 했어요. 처음부터 새로 개발하는 것보다는 기존에 검증된 구조를 활용하는 것이 효율적이라고 판단했거든요.

관리자 페이지에서의 핵심 기능은 데이터를 필요로 하는 모든 페이지를 실시간으로 관리할 수 있도록 하고 개발자의 도움 없이도 간단한 수정이 가능하도록 하는 것이었어요. 구체적으로는 메인 페이지의 배너 사진 및 문구를 손쉽게 변경할 수 있도록 하고 각 메뉴와 서브메뉴의 텍스트는 물론 페이지 내에 있는 모든 사진들을 드래그 앤 드롭으로 변경이 가능하도록 만들었어요. 또한 메뉴 구조 자체도 관리자가 직접 추가, 삭제, 순서 변경할 수 있도록 트리 구조로 설계했죠.

이렇게 구현한 이유는 향후 마케팅팀이나 기획팀에서 홈페이지 내용을 업데이트할 때마다 개발팀에 요청하지 않아도 되도록 하기 위해서였어요. 실제로 완성 후에는 비개발자도 쉽게 사용할 수 있다는 피드백을 받을 수 있었죠.

### 홈페이지에 CMS 기능을 통합하여 개발을 진행하자
CMS 구축이 완료되었다면 홈페이지를 만들어 봐야겠죠? CMS를 통하여 기획단계에서 구성하였던 레퍼런스와 각 사업부에서 받은 사진들과 자료를 통하여 넣었던 데이터들을 통하여 메인페이지와 각 서브페이지를 개발하였어요. 커다란 기능들은 존재하지 않아 CSS에만 집중하면 됐었죠. 하지만 요청사항 중 두 번째, `최신 트렌드 홈페이지에 맞게 스크롤링을 통한 UI가 구성될 수 있도록 함` 회사의 얼굴이 될 수 있는 메인페이지를 만드는데 많은 시간을 사용했어요. swiper.js 라이브러리를 사용하여 메인 배너를 만들었고 아이패드의 특정 어플을 이용하여 각각의 사업부의 텍스트가 들어가있는 SVG 파일을 직접 만든 뒤 scrollmagic 라이브러리를 이용하여 스크롤을 내릴 때 애니메이션 효과를 주었어요.

```point
- Swiper.js 이란?
모바일 및 데스크탑에서 사용할 수 있는 모던한 터치 슬라이더 라이브러리에요.

- ScrollMagic 이란?
스크롤 이벤트에 따라 애니메이션을 제어하는 JavaScript 라이브러리에요.
```

아직 끝난게 아니죠. 어떻게 보면 가장 시간이 오래 걸렸고 손이 많이 가는 반응형 작업이 남았어요.

이전 회의 때 팀원들과 논의한 결과, 반응형 사이트 기준을 PC, Tablet, Mobile 이렇게 3개 디바이스를 기준으로 잡고 반응형 작업에 들어갔어요. 미디어 쿼리는 `max-width: 1280px (PC)`, `max-width: 1024px (Tablet)`, `max-width: 768px (Mobile)` 이렇게 max-width 값을 기준으로 설정해서 개발을 진행했죠.

사실 반응형 작업이 가장 까다로운 이유는 각 디바이스마다 레이아웃을 다시 구성해야 하고 특히 이미지 크기나 텍스트 배치, 메뉴 구조 등을 모두 다르게 조정해야 하기 때문이에요. PC에서는 가로로 배치된 요소들이 모바일에서는 세로로 쌓여야 하고, 네비게이션도 햄버거 메뉴로 바뀌어야 하죠. 단순히 크기만 줄이는 게 아니라 터치 환경에 맞게 버튼 크기를 조절하고 모바일에서는 스크롤 방향도 고려해서 UI를 재배치했어요. 이렇게 설명하다보니 정말 힘들었던 기억이네요...

이제 마지막 요구사항인 다국어 페이지 기능! 쿠키값(ko, en)을 활용하여 다국어 전환이 가능하도록 구현했어요. 페이지 번역은 사내에 영어을 잘 하시는 분에게 번역을 부탁드렸죠. 마지막으로 검색 엔진 최적화를 위해 각 페이지별로 title, description, keywords 등 Meta 태그들을 꼼꼼히 삽입했어요. 자 이제 끝이 보이네요.

### 대표님과 부장님들에게 컨펌을 받자
홈페이지의 UI와 구성이 끝난 뒤 대표님과 부장님들에게 컨펌을 받는 회의일정을 잡게되었어요. 이러한 과정의 이유는 각 사업부마다 개선사항이 분명히 있을 것으로 생각되어 회의를 진행하게 되었죠. 다행이도 큰 변경사항이 없이 오픈을 할 수 있게되었어요. 회의 때 변경될 회사 홈페이지를 소개하는데 얼마나 떨리던지 그 날 대표님과 함께하던 점심식사.. 음식이 목 넘어로 잘 안 넘어갔는데 잘 먹는다고 공깃밥 한 공기를 더 묵묵히 주문해주셨던 것이 기억나네요.

### 언제 오픈해도 상관없죠~
도메인같은 경우 기존에 사용하고 있던 카페24의 도메인을 그대로 이용하였어요. 배포를 진행할 때 무중단 배포(Root 파일 교체 방식)을 이용하면 되기 때문에 큰 어려움은 없었어요. 혹여나 운영서버에서 이슈사항이 발생할 수 있음으로 사용하지 않는 도메인을 개발서버로 이용하여 테스트를 진행하였어요.

## 마무리
개발 경력이 많지 않은 저에게 이런 프로젝트를 주도할 수 있게 해주신 이사님에게 감사하면서도 부담을 많이 갖게 됐어요. 개인 프로젝트가 아닌 회사의 얼굴이 되며 내가 회사를 떠난다고 해도 커밋 히스토리와 주석에 저의 이름이 적혀있으므로 보다 더 완벽하게 할 수 있길 원했어요. 프로젝트를 진행하면서 가벼운 마음으로 임한적이 한번도 없었으며 이러한 다짐들이 아웃풋을 만들고 자신감을 북돋아주었어요. 부담은 되었지만 정말 행복하고 즐겁게 개발을 했어요. 제가 지금까지 좌절하지 않고 개발을 할 수 있었던 이유도 해당 프로젝트 경험이 있기 때문이 아닐까 할 정도로요. 같이 프로젝트를 진행했던 사내 직원분들이랑은 자주 만날 정도로 친한 사이가 되었죠.

개발 경력이 많지 않은 상황에서 이사님의 신뢰로 맡게 된 사내 홈페이지 리뉴얼 프로젝트. 기획, 디자인, 개발, 배포까지 모든 과정을 주도하며 얻은 기술적 성장과 개발자로서의 자신감을 키운 특별한 경험담

회사의 얼굴을 만드는 일 - IT 기업 홈페이지 리뉴얼기


# 시작하기 앞서
이전 회사에서는 총 4개의 프로젝트를 진행하였고 이에 대해서 정리를 해보려고 해요. 2022년 03월 프론트엔드 서비스부서에 입사하게 되었고 수습 3개월의 OJT 기간동안에는 같은 달에 들어왔던 동기들과 직장 선배님들의 도움을 받아 관리자 시스템을 개발하였죠, 그렇게 3개월이 지난 후 '한화생명 코어 프로젝트' 첫 프로젝트를 들어갔었죠.

# 한화생명 코어 프로젝트
```list
HCS에는 생명보험, 손해보험, 운영비, 수수료 지급 등의 20개가 넘는 수수료 시스템이 존재합니다. 
```
제가 한화생명에서 담당했던 파트는 HCS인 수수료 시스템에요
HCS에는 생명보험, 손해보험, 운영비, 수수료 지급 등의 20개가 넘는 수수료 시스템이 존재합니다. 수습기간에 진행했던 OJT 프로젝트 외 개발자로서의 첫 업무라 무척 설레이고 떨렸었죠 아직도 63빌딩 엘레베이터를 타고 제가 업무를 해야하는 층까지 가는 길이 생생하게 기억이 나네요. 업무 컴퓨터는 총 2대가 있으며 보안을 위해 인터넷이 되지 않는 본체 1대, 그 외 본체 1대 이렇게 총 2대의 컴퓨터로 업무를 진행했어요. 들어가서 가장 먼저 했던 일은 현재 HCS 프로그램의 구조를 파악하며 이 업무를 왜 해야하는지 알아야 했던 것이 1순위라고 생각했어요. 이렇게 저의 첫 업무가 시작되었죠.

![fp.webp](https://d2ut7x8yqv441q.cloudfront.net/posts/1750087039153.webp)

제가 담당했던 '수수료 관리 시스템' 파트는 한화 생명에 소속되어있는 모든 FP(보험설계사) 분들에게 수수료를 지급하는 것이 궁극적인 목표에요. 매 월 기간내에 지급되는 시스템을 관리하고 보험 약관에 맞춰 새로운 기능을 개발하고 보수를 하였으며 또한 리뉴얼 개발로 인한 차세대 시스템을 개발하였고 Core에서 받아오는 데이터를 위한 시스템을 개발하며 각 수수료 지급에 관한 페이지를 개발하였죠.

수수료 지급을 '지급의뢰' 라고 했으며 매 월 특정 일자에 해당 배치 프로그램을 실행시켜요. ETL 프로그램을 통하여 월 자동배치가 실행되긴 하지만 수수료 데이터가 변경될 수 있기에 수기로 배치를 실행시키기도 해요. 그러면 이 안에서 가장 중요한 것은 뭘까요? 당연히 FP분들에게 정확한 금액의 수수료가 지급될 수 있도록 검증을 해야하죠. 그렇기 때문에 프로세스에 이상이 전혀 없고 완전해야 해요.

그러면 제가 하는 일을 명확히 알게됐으니 어떤 업무를 했는지 알아보죠.

## 수수료 시스템(HCS) 관리 및 지급의뢰
위에서 말했다시피 지급의뢰가 저의 업무에 있어서 1순위였죠. 코어 시스템을 구축하고 시스템 개편을 한다 하더라도 기존 시스템을 이용하여 그대로 지급의뢰는 실행되어야 하죠. 어떻게 보면 담당 업무가 두가지(운영, 신규개발)였죠. 보험약관은 생각보다 자주 변경된다는 것을 해당 프로젝트에서 알게되었어요. 보험 약관으로 인한 오라클 프로시저 수정요청이 들어오면 PL_SQL을 수정하였고. 신규 지급의뢰가 추가될 경우 새로운 배치 인터페이스를 만들고 해당 지급의뢰에 관한 페이지를 만들었어요.

```point
오라클 프로시저란?
오라클 프로시저는 Oracle 데이터베이스에서 사용하는 PL/SQL(Procedural Language/SQL) 기반의 `저장 프로시저(Stored Procedure)`입니다. 자주 반복되는 데이터베이스 작업을 하나의 블록으로 묶어두고 필요할 때마다 호출하여 실행할 수 있도록 만든 함수처럼 동작하는 SQL 코드의 집합입니다.
```
```js
// 프로시져 예시
CREATE OR REPLACE PROCEDURE 프로시저이름 (
    매개변수명 IN 데이터타입,
    매개변수명 OUT 데이터타입
)
IS
    -- 변수 선언
BEGIN
    -- 실행할 SQL 문
EXCEPTION
    -- 예외 처리
END;
```

## ETL 프로그램 전환으로 인한 시스템 개편
기존 ETL 프로그램을 청산하고 신규 ETL 프로그램을 도입하였어요. 여기서 추가로 Core에서 들어오는 데이터 수집을 위한 기존 HCS 테이블, 컬럼명 변경으로 인해 신규 배치 프로세스를 구축해야 했죠.

### 수수료 지급 프로세스
수수료 지급의 ETL 프로그램은 JopPass와 TeraStream을 이용하여 데이터를 받아왔어요.

```point
- TeraSteream 이란? 
고성능 데이터 통합 ETL 솔루션으로 대용량의 데이터의 추출, 변환, 적재 과정을 효율적으로 처리할 수 있도록 해주는 프로그램이에요.
- JopPass 란?
자동화 관리 솔루션으로 배치, DBMS, 파일 송수신 작업 등을 도와주고 있는 프로그램이에요.
```

받아오는 방식은 총 두가지로 DD(DB to DB), FD(File to DB) 방식이 있죠, 즉 한화생명에서 데이터 파일을 전송해 주면 프로그램을 실행하여 수수료 시스템에 데이터를 적재하고 수수료 계산 로직을 이용하여 수수료를 산출하고 ERP로 전송하는 것이 최종 작업이죠 수수료의 흐름을 정리해보면

```list
1. 데이터 파일 전송
2. ETL 프로그램을 이용하여 데이터 적재
3. 해당 지급 수수료 유형에 맞는 프로시저 실행
4. 지급될 금액과 데이터 검증
5. 데이터 검증 및 결재 후 수수료 지급
```

이러한 단계를 거치고 있어요. 제가 여기서 진행하고 담당했던 부분은 차세대 프로젝트 환경에 맞게 각 지급유형별 수수료 계산 프로시저를 개발하고 배치 시스템 및 인터페이스를 개발하고 보험 정책 변경에 따른 유지보수, 데이터 마이그래이션 등 이렇게 보니 많은 부분을 진행하였네요. 배치시스템 인터페이스에는 일배치, 월배치가 있었으며 특정 스케쥴러 시간 혹은 직접 실행할 수 있었고 이는 SQL MERGE 사용하여 데이터를 적재하는 형식을 갖고 있어요

```point
MERGE문이란?

MERGE INTO Customer AS target
USING CustomerUpdates AS source
ON target.CustomerID = source.CustomerID
WHEN MATCHED THEN
    UPDATE SET 
        target.Name = source.Name,
        target.Email = source.Email,
        target.Phone = source.Phone
WHEN NOT MATCHED THEN
    INSERT (CustomerID, Name, Email, Phone)
    VALUES (source.CustomerID, source.Name, source.Email, source.Phone);

이처럼 두 테이블 간의 데이터를 비교하여 조건에 따라서 INSERT, UPDATE, DELETE를 수행하는 문이에요.
위 예시의 쿼리는 기존 고객 정보가 있는 테이블 Customer, 새로운 고객 정보가 담긴 테이블 CustomerUpdates라는 테이블이 있다고 가정할 때 기존 고객이면 정보를 업데이트하고 없으면 새로 추가하는 쿼리이죠.
```

개발을 진행할 때 다행이도 AS-IS 버전이 존재하여 참고하여 개발했던 것으로 기억해요. 개발 업무에서 가장 중요한 것이 테스트 부분이라고 생각해요 내가 완벽하게 개발을 한다 가정을 하여도 나올 수 있는 것이 버그 및 이슈사항이며 다양한 방면으로 테스트를 해야하는 것도 첫 프로젝트 경험에서 얻을 수 있었죠.

## 첫 오픈 날
한화생명 코어 프로젝트는 일정 연기가 두 번 정도 됐던 것으로 기억해요. 저희 수수료 관리 시스템 파트는 개발이 완료되고 테스트까지 모두 끝난 상태였지만, 다른 파트에서 예상치 못한 큰 이슈사항들이 발생하면서 오픈 연기를 요청했어요. 그렇게 몇 달을 더 기다린 후 드디어 대망의 오픈 날이 다가왔죠. 같은 팀원분들과 함께 새벽부터 나름의 긴장감을 가지고 준비했어요. 오픈 당일에는 모든 팀원들이 각자 맡은 부분을 점검하며 체크리스트를 하나씩 확인해나갔어요. 본격적인 배포가 시작되면서 하나하나 본 서버에 반영을 시작했고 가장 중요한 데이터 마이그레이션 작업을 신중하게 진행했어요. 제가 개발했던 인터페이스와 지급의뢰 페이지들이 차례대로 올라가는 모습을 지켜보며 마음이 조마조마했죠. 시스템이 안정적으로 올라간 후에는 한화생명 현업 직원분들이 실제 업무 데이터로 테스트를 진행하시는 동안 저희 개발팀은 최종 기능 테스트와 모니터링을 병행했어요. 실시간으로 로그를 확인하면서 혹시나 하는 오류가 없는지 긴장의 끈을 놓지 않았죠. 다행히도 오픈 이후 큰 이슈사항 없이 모든 기능들이 정상적으로 작동했고 며칠간의 안정화 기간을 거쳐 정식으로 서비스를 오픈하게 되었어요. 그동안의 고생이 보상받는 순간이었죠.

## 마무리
저는 회사 내부에서 부득이하게 혼자서 해당 프로젝트를 들어갔었죠 첫 프로젝트이고 개발자의 첫 발걸음이 비록 쉽지만은 않았어요. 이전에 배웠던 개발은 기초중에 기초였고 실무는 정말 다르다는 것을 알았죠. 한화생명은 보험회사이며 가장 어색했던 것이 보험에 관련한 명칭들이었어요 예로 보험설계사는 FP로 불리는 등 이러한 명칭들을 모르면 업무를 진행하기가 힘들어 개발뿐만 아니라 보험에 관련된 명칭들을 정리한 뒤 출력하여 4장정도 되는 명칭들을 출퇴근할때 외웠던 것으로 기억이 나요. 

많은 것을 느끼고 또 제가 개발자로서 가야할 방향성이 정해졌어요. 코딩을 잘 하는 것도 중요하지만 현재 위치에서 자신이 하는 업무는 무엇인지 어떠한 책임감을 가져야 하는지 알 수 있는 첫 프로젝트였어요. 진행했던 6개월동안 야근도 많이하고 공휴일도 쉬지 않고 출근하며 달마다 있는 지급의뢰 기간에는 항상 철야작업을 진행했지만 좋은 팀원분들 덕분에 실력도 많이 늘고 해당 프로젝트를 마칠 때는 웃으면서 철수할 수 있었던 것 같아요.

매월 수천 명의 보험설계사 수수료를 처리하는 시스템 개발 과정과 런칭과정을 알아볼까요

FP 수수료 지급부터 차세대 시스템까지 - 한화생명 프로젝트 회고록


## 2025/03/21 퇴사 후 새로운 시작 앞에서
회사라는 울타리를 벗어나는 건 결코 쉬운 결정이 아니었어요. 안정적인 급여, 익숙한 업무, 정든 동료들 하지만 문득 돌아봤을 때 나는 더 이상 성장하고 있지 않다는 생각이 들었어요. 비슷한 연차의 개발자분들과 대화를 나누어보면 같은 고민을 한다는 것을 알게되었고 저는 그 자리에서 머물기 보다는 실행하고 제 스스로가 움직이려고 했어요.
더 깊이 배우고 싶다는 갈증, 내가 몰입할 수 있는 환경에서 일하고 싶다는 갈망이 마음 속에서 점점 커져갔으며 마침내 목표했던 3년이라는 시간이 지나고 새로운 시작을 시작하려고 해요.

### 채워가야 할 것들
제 스스로에게 가장 부족한 부분이 무엇인지 물어보았어요. 그것은 `깊이감` 이라는 것을 깨달았죠. 현재 많은 개발자들이 개발을 진행함에 있어서 AI를 많이 사용하고 있죠. 이를 활용함으로서 개발의 진행 속도도 증가하며 아웃풋도 잘 나오고 있죠. 여기서 `'그렇다면 개발자들의 능력은 어디서 나뉘어질까?'` 라는 생각이 들더라고요. 많은 기술블로그와 기업에서 작성한 글들을 살펴보니 CS지식 즉 깊이감에서 많이 나뉘어 질 것 같다는 생각이 들었어요. 저는 개발하는 것이 재미있고 또 자신이 있었죠. 업무에 있어서 개발이 전부가 아니라는 것을 최근 프로젝트를 진행하며 많은 이야기를 담당 PM님에게 들었고 저에게 부족한 부분이 도드라 보여졌죠. 다른 직원분들과 협업분들은 '일을 잘한다.', '열심히 하는 모습이 보기좋다' 등 좋은 말들을 하지만 제 스스로가 만족하지 못하기 때문에 부족한 부분을 채워나가기 위해 제자리에 머물러있지 않으려고 해요.

### 목표 - 방향성을 향한 한 걸음
이제 뼈대를 세울 차례죠. 단순히 코드를 잘 치는 개발자가 아니라 왜 이 구조를 선택했는지 설명할 수 있는 개발자가 되고 싶어요.
```list
- 실무 React, TypeScript, Next.js 개발 프로젝트 복습을 위한 '테크 블로그 만들기' 개인 프로젝트 진행 및 설계 -> 개발 -> 배포 진행
- 깊이감을 위한 CS 지식 확립
- 새로운 기술들을 많이 쌓기
- 진심으로 좋아할 수 있는 조직에 합류
```

### 마지막으로
결국 이 모든 시간은 '나다운 개발자'가 되기 위한 여정입니다. 트렌드를 좇기보다 내가 좋아하고 잘할 수 있는 방향을 찾고 싶어요. 그리고 그 끝에는 함께 성장할 수 있는 좋은 팀에서 일하여 스스로에게 만족할 수 있는 개발자가 될거에요.


퇴사 후의 회고록을 작성해보자

퇴사 후 새로운 시작 전 회고


## SEO 크롤링 이슈
회사에서 진행하고있는 홈페이지 리뉴얼 개발 프로젝트가 끝나고 안정화기간 및 유지보수 과정중 SEO 개발건이 들어왔어요. 팀 동료분께서 PC버전 모바일버전 SEO 개발이 완료되고 추 후 SEO 데이터가 제대로 수집되지 않는다는 이슈사항을 받았죠. 개발자도구에서 확인해보니 데이터가 정상적으로 들어가 있는것을 확인했지만 그것은 js 혹은 서버에서 완성된 데이터였으며 현재 PC버전은 CSR, 모바일버전은 SSR로 PC버전에서만 발생했던 이슈로 메타태그 내의 데이터가 완성되기 전의 데이터를 파싱하고 있다는 것을 알게되었어요.

SEO에는 3단계의 프로세스를 지니고 있다고 하죠.
```list
1. 크롤링: 웹 크롤러가 웹페이지의 콘텐츠를 복사하여 검색엔진으로 가져온다.
2. 인덱싱: 가져온 콘텐츠를 주제별로 색인하여 보관한다.
3. 랭킹: 검색의도에 맞춰 색인된 콘텐츠에 순위를 부여한 결과를 제공한다.
```

여기서 그러면 SSR 과 CSR의 차이는 무엇일까요?

![csr_ssr.jpeg](https://d2ut7x8yqv441q.cloudfront.net/posts/1741593928191.jpeg)

### SSR이란?
SSR은 Server Side Rendering의 약자로 말 그대로 서버 측에서 데이터를 완성한 후 페이지를 정적으로 렌더링 하는 것을 의미해요. SSR의 단점으로는 특정부분 데이터가 변경이 필요하다 하더라도 전체 페이지를 새로고침을 해야한다는 단점이 있어요. 또한 서버도 데이터를 다시 받아 페이지를 만들어야 함으로 데이터의 부하 문제도 생길 수 있다고 합니다. 이러한 단점을 해결하기 위해 나온 것이 CSR, SPA의 React, Vue 라는 프레임워크에요.

### CSR이란?
CSR은 Client Side Rendering의 약자로 SSR처럼 서버에서 미리 준비하는 것이 아닌 웹사이트의 콘테츠가 Client에서 동적으로 렌더링 하는 것을 의미해요. React는 HTML의 body내 id가 root인 div태그를 Client가 동적으로 JavaScript를 통해 HTML을 만들어가는 것이에요. 즉 사용자의 요청에 따라서 해당 태그가 새로고침 없이 업데이트 되는 것을 뜻하며 이러한 형태가 SPA=Single Page Application 이죠.

이렇게 SSR과 CSR의 기본 개념을 확인했으면 이 두가지의 Redering 방식이 SEO랑 무슨 관련이 있는지 확인해보죠.

현재 SEO관련 문제의 원인이 CSR인 PC 사양의 웹 사이트를 접근하면 Client가 HTML을 구성하는 동안 크롤러 과정에서 검색엔진의 로봇이 빈페이지를 인지하지 못해 발생하는 문제였어요.

이에 대한 문제 해결 방법은 의외로 간단해요, 

CSR, SSR 방식을 둘 다 사용하는 것이죠. 검색엔진은 로딩 상태나 JavaScript 실행에 의존하지 않고 완성된 HTML 구조와 메타 정보를 크롤링 하고있어요. 검색엔진 크롤러는 사용자처럼 로딩 상태를 기다리지 않으므로, SSR(Server-Side Rendering)을 통해 완전히 렌더링된 HTML 페이지를 즉시 제공해야 하죠.

이처럼 사용하게되면 다시 SSR의 단점을 가지고 오는 것이 아닌가요!?

저도 이러한 문제를 해결하기 위해서는 어떻게 해야할까 고민이 되었어요. SEO라는 기능 하나때문에 CSR 방식을 SSR 방식으로 변경하여 HTML을 렌더링 하는 것은 현재 운영중이며 안정화가 다 끝나가는 이 시점에서는 시간과 노력, 이에 따른 테스트 기간 등 많은 것들이 소모된다고 생각하여 다른 방법을 찾아보았어요. 다른 좋은 방법이 있을까 찾아보니 이때 Next의 Middleware에 대해서 확인할 수 있었어요.

그러면 Middelware란 무엇일까요?

### Next의 Middleware란?
Next.js의 Middleware는 요청(Request)과 응답(Response) 사이에 실행되는 코드로, 요청을 가로채어 특정 작업을 수행하거나 요청을 수정할 수 있는 기능이에요. 이를 통해 사용자 요청에 대한 동적 처리를 서버에서 미리 수행할 수 있다고 합니다.

이렇게 내용이 나와있네요,,,

즉 예로 localhost:3000/menu/ 라는 요청이 들어올 시 서버 단에서 해당 요청을 가로채어 특정 작업을 수행할 수 있는 것이에요.

이론적인 내용을 알았으니 이를 한번 적용시켜보죠

## 해결방법
이러한 내용을 응용하여 SEO 관련의 요청을 두 분류로 나뉘어 볼게요
```list
1. 사용자 요청 = CSR
2. 크롤링 봇 요청 = SSR
```
localhost:3000/menu/ 라는 요청이 들어왔을 때 이처럼 사용자의 요청일 경우에는 그대로 CSR 렌더링 형식으로, 크롤링 봇의 요청일 경우에는 SSR 렌더링 형식으로 분류할 수가 있죠.

사용자 요청과 크롤링 봇의 요청을 구분하기 위해서는 user-agent 에서 크롤링 봇의 요청인지 확인을 해야해요. 확인을 위해 NextRequest의 headers 내에 'user-agent'을 get 하여 크롤링 봇인지 조회을 해보죠 ( ex:bingbot, Googlebot )

```js
// src\middleware.pc.tsx
import { NextResponse, type NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
	const userAgent = request.headers.get('user-agent') ?? '';
	const regex = new RegExp('yeti', 'i');
	const isYetiBot = regex.test(userAgent);

	if (isYetiBot) {
		const url = request.nextUrl.clone();
		url.pathname = `/partial-ssr${url.pathname}`;
		return NextResponse.rewrite(url);
	}

	return NextResponse.next();
}
```

user-agent 내에 'bingbot', 'Googlebot', 'yeti'(크롤링 봇)의 값이 true일 때는 따로만든 SSR 전용 페이지로 리다이렉트 시키는 것이죠. 이처럼 Middleware를 통해 각 요청에 맞는 페이지로 리다이렉트 시키면 됩니다.

위 함수를 해석하자면 '현재 요청을 한 당신 사용자에요? 아니면 봇이에요? 사용자면 그대로 CSR로 가고 봇이면 리다이렉트해서 SSR로 가요!'

그러면 다른 방법도 있지 않냐고요?

물론 다른 방법도 있죠. 말씀드렸다시피 SSR로 변경하는 방법, history API를 활용하는 방법, React 라이브러리 활용 방법 등 다양한 방법이 있다고 하네요. 하지만 오픈 후 안정화가 완료됐는데 모든 페이지를 크롤링을 해야하는 현 상황에서 새로운 page를 만드는 것이 낫지 잘 돌아가는 기존 page의 모든 코드를 건든다는 것은 큰 모험이나 마찬가지라고 생각했어요. 상황에 따라서 방법이 달라지겠지만 현 상황에서는 이러한 방법이 최선이라고 생각했고 팀원들과의 회의 결과 이처럼 진행했어요.

```point
Middleware 적용 방법
프로젝트 최상단 루트경로, src 하위에 middleware.ts 파일을 사용하면 돼요. 즉 pages 또는 app 과 동일한 수준에 있거나 src 내부에 있으면 됩니다.
```

업무중 SEO 크롤링 문제 리액트 프로젝트를 완료하고 SEO 크롤링이 제대로 되지 않는다는 요청을 받았어요. 확인해보니 CSR 환경으로 메타태그 내의 데이터가 완성되기 전의 데이터를 파싱하고 있는 것이 확인되었고 이에 대한 대응에 관련하여 작성해볼게요.

CSR과 SSR을 활용한 SEO 크롤링 대응처리


tstory, 네이버블로그, velog 등을 이용하지 않고 최근에 진행했던 프로젝트의 환경을 기반으로하여 블로그를 만들고 싶었어요. CS 지식이 많이 부족한 스스로에게 공부를 메모할 수 있는 나만의 공간을 만들어보고 기능들을 사용하여 블로그를 만들어봅시다.

## 블로그 프로젝트 환경
처음에는 백, 프론트 구분하여 개발을 하려고 했지만 시간과 비용이 소모되며 마크다운을 이용한 gray-matter 라이브러리를 이용해 블로그를 구축할 수 있다는 것을 알게되었습니다. 이를 기준으로 React, Next는 기본으로 이에 따른 상태관리를 위한 Redux, 스타일링은 sass 방식을 사용하기로 했어요.

![Next.js](https://img.shields.io/badge/Next.js-14.2.1-blue) ![React](https://img.shields.io/badge/React-18-blue) ![TypeScript](https://img.shields.io/badge/TypeScript-5.4.5-blue) ![Styled with Sass](https://img.shields.io/badge/Styled_with-Sass-pink)

## 개발단계

### 1. 공통 레이아웃, 메인페이지 구성
블로그의 첫 인상이되는 메인페이지를 보여준다고 했을 때 깔끔한 디자인을 보여주고 싶어 고민을 많이 했어요. 기본적인 헤더와 푸터 중앙 영역에는 게시글 목록을 보여주고 목록을 기준으로 양 옆에 사이드 바 메뉴를 구성하면 좋겠다고 생각해 지금과 같은 메인페이지의 UI 구성이 되었죠

![mainpage_layout.webp](https://d2ut7x8yqv441q.cloudfront.net/posts/1741325521155.webp)

### 2. 마크다운
gray-matter 라는 라이브러리를 통해 마크다운 파일을 읽어올 수 있도록 하였어요. 메인페이지에서 보여줄 전체 게시글 목록인 getMarkdownAllPosts.ts 파일과 게시글 상세페이지에서 보여줄 특정 게시글 목록인 getMarkdownPost.ts 파일을 각각 생성하였고 fs.readFile 을 통해 파일을 읽어 gray-matter로 데이터를 분리하였어요 아래의 코드의 data와 content를 분리하자면 마크다운 파일의 --- 삼중 대시로 감싸 진 영역(Front Matter)이 'data'고 그 외의 본문 내용은 'content'에요 즉 Front Matter 영역 내에 메인페이지, 상세페이지에 보여줄 데이터 내용을 완성하는거죠
```js
const getMarkdownAllPosts = async () => {
    const fileNames = fs.readdirSync(postsDirectory);

    const postList = fileNames.map((fileName) => {
        const fullPath = path.join(postsDirectory, fileName);
        const contents = fs.readFileSync(fullPath, 'utf8');

        /// data === FrontMater, content === 본문
        const { data, content } = matter(contents);

        const post: PostType = {
            slug: convertToSlug(data.title),
            title: data.title,
            description: data.description,
            thumbnailImage: data.thumbnailImage,
            mainTag: data.mainTag,
            regDate: data.regDate,
            tags: data.tags,
            content,
        };

        /// 게시글 상세 페이지일 경우 아래 코드 추가
        // if(convertSlug === slug) {
        //     return post;
        // }

        return post;
    }).sort(
        (a, b) => new Date(b.regDate).getTime() - new Date(a.regDate).getTime(),
    );

    return {
        postList: postList,
    };
};
```

### 3. 상세 페이지
마크다운 파일을 통해서 데이터를 가져오는 방법을 확인했으면 이러한 데이터를 이용하여 화면에 출력하는 방법을 알아보죠. 마크다운 형식의 데이터를 화면에 출력하기 위해 아래와 같은 라이브러리를 사용해볼게요
```list
1. react-markdown
- React 환경에서 마크다운을 렌더링 할 수 있도록 도와줍니다.
- 마크다운 문법을 HTML로 변환하여 출력해줍니다.
2. rehype-raw
- 기본적으로 react-markdown 와 함께 사용되며 HTML 태그를 파싱하여 적용할 수 있도록 해줍니다.
3. remark-breaks
- 마크다운에서 줄바꿈(\n)을 <br> 태그로 변환해주는 플러그인이에요 즉 줄바꿈을 강제로 적용시켜 줍니다.
4. remark-gfm
- GFM을 지원하는 플러그인으로 체크박스 리스트, 표, 스트라이크스루(취소선) 같은 GitHub에서 사용하는 확장된 마크다운 문법을 적용할 수 있도록 해줍니다.
5. react-syntax-highlighter
- 코드 블록의 구문 강조를 지원하는 라이브러리입니다. (```js  {코드}  ```)
```

적용에 앞서 react-markdown의 Import에 관련이에요. react-markdown을 직접적으로 import 하게되면 Hydration failed 에러가 발생할 수 있어요 그러면 가장 먼저 Hydration failed는 무엇일까요?
```point
1. Hydration failed 에러란? 
- Next.js에서는 서버에서 미리 렌더링한 HTML과 클라이언트에서 실행되는 React 컴포넌트의 결과가 일치하지 않으면 Hydration failed 오류가 발생해요. 즉, 서버에서 렌더링한 마크다운과 클라이언트에서 렌더링한 마크다운이 다르면 에러가 뜨는 거죠.
```
서버와 클라이언트의 마크다운이 다르게 해석될 가능성이 충분이 있으며 저는 이러한 에러로인해 Dynamic Import로 클라이언트에서만 실행되도록 설정하였어요.

```js
const DynamicReactMarkdown = dynamic(() => import("react-markdown"), {
    ssr: false,
});
```
Next.js에서 react-markdown을 직접 사용하면 서버와 클라이언트의 렌더링 결과 불일치로 Hydration failed 에러가 발생할 수 있어요.
이를 방지하기 위해 dynamic(import("react-markdown"), { ssr: false })를 사용하면, 클라이언트에서만 렌더링되도록 강제하여 오류를 해결할 수 있어요. 그러면 Dynamic으로 import한 react-markdown을 사용해보죠.

```js
<DynamicReactMarkdown 
    remarkPlugins={[remarkGfm, remarkBreaks]}
    rehypePlugins={[rehypeRaw]}
    components={{
        code(props) {
            return customCodeBlock({ props, theme });
        },
        h1: ({ children, ...props }) => {
            return <h1 id={generateHeadingId(String(children))} style={{ fontSize: "2em" }} {...props}>{children}</h1>;
        },
        h2: ({ children, ...props }) => {
            return <h2 id={generateHeadingId(String(children))} style={{ fontSize: "1.75em" }} {...props}>{children}</h2>;
        },
        h3: ({ children, ...props }) => {
            return <h3 id={generateHeadingId(String(children))} style={{ fontSize: "1.5em" }} {...props}>{children}</h3>;
        },
        h4: ({ ...props }) => <h4 style={{ fontSize: "1.25em" }} {...props} />,
        h5: ({ ...props }) => <h5 style={{ fontSize: "1em" }} {...props} />,
        p: ({ ...props }) => <p style={{ marginTop: "0", marginBottom: "1rem" }} {...props} />,
        pre: ({ ...props }) => <pre style={{ marginTop: "0", marginBottom: "1rem" }} {...props} />,
        details: ({ ...props }) => <details style={{ cursor: "pointer" }} {...props} />,
    }}
>
    {markDownContent}
</DynamicReactMarkdown>
```
install 받은 rehype-raw, remark-breaks, remark-gfm 세개의 라이브러리는 위 코드처럼 적용시켜줄 수 있어요.
react-markdown의 장점으로는 내가 원하는 태그 영역을 커스텀하여 스타일링 할 수 있다는 것이 장점이죠. react-syntax-highlighter를 사용하기 위해서는 components 객체의 code 속성에 적용시켜줘야 해요
```js
import { Prism as SyntaxHighlighter } from "react-syntax-highlighter";

const customCodeBlock = ({ props, theme }: CustomMarkdownType) => {
    const { className, children } = props;
    const match = /language-(\w+)/.exec(className || '');

    if (match?.[1] === "javascript" || match?.[1] === "js" || match?.[1] === "ts") {
        return (
            <SyntaxHighlighter
                className={styles.scriptBlock}
                style={theme === 'dark' ? materialDark : coy}
                language="javascript"
                PreTag="div"
                showLineNumbers
                wrapLines
            >
                {String(children).replace(/\n$/, '')}
            </SyntaxHighlighter>
        );
    }
    return (
        <div className={styles.codeBlock}>
            <code {...props}>{children}</code>
        </div>
    );
};
```

react-markdown과 같은 라이브러리는 코드 블록을 렌더링할 때 보통 다음과 같이 code 태그에 className을 추가해요. code 태그 영역으로 들어오는 props 중 className을 통해서 match를 구분하고 각 match마다 원하는 style을 적용시킬 수도 있어요. 저는 코드블록을 두가지로 구분을 했어요 JavaScript("javascript", "js") 또는 TypeScript("ts") 코드 블록이면 react-syntax-highlighter의 SyntaxHighlighter를 사용해 코드 블록을 하이라이팅 하였고 그 외는 모두 일반 code 태그로 출력하여 원하는 코드블럭을 만들었죠. showLineNumbers, wrapLines은 코드블록 좌측에 line number를 생성해주어 같이 추가해 주었어요.

- 하이라이팅 코드블록
![matchCodeBlock.webp](https://d2ut7x8yqv441q.cloudfront.net/posts/1741331013306.webp)

- 그 외 코드블록
![defalutCodeBlock.webp](https://d2ut7x8yqv441q.cloudfront.net/posts/1741331029037.webp)

작성한 마크다운의 내용으로 목차도 자동생성이 되면 좋겠다 라는 마음이 있어 추가로 개발을 해봤어요. 목차의 기준을 마크다운의 헤딩을(#, ##, ###)을 통해 만들어 볼게요. content로 들어오는 마크다운 본문에서 헤딩을 모두 조회하여 각 헤딩별 level과 내용을 위한 text 클릭했을 때 해당 위치로 바로 가기 위한 id 값을 주었어요.

```js
//PostContent.hook.ts
export const usePostContent = ({
    content
}: PostContentParams) => {
    const getPostContentHeadings = useCallback(() => {
        const headingMatches = content.match(/^#{1,3} .+/gm) || [];

        return headingMatches.map((heading) => {
            const level = heading.match(/^#{1,3}/)?.[0].length || 0;
            const text = heading.replace(/^#{1,3} /, "");
            const id = text.replace(/\s+/g, "-").toLowerCase();

            return { level, text, id };
        });
    }, [content]);

    return {
        getPostContentHeadings
    };
};
```
이렇게 가지고 온 데이터를 이용해 이처럼 목차를 만들 수 있죠

### 4. 게시글 등록
블로그에 게시글을 생성할 때 마크다운 파일을 생성하고 커밋, 푸쉬, 풀리퀘, 디플로이 이러한 과정이 매번 있는 것은 번거롭다고 느껴져 홈페이지 관리자만 게시글 등록을 할 수 있는 페이지를 만들어 봤어요.
/admin에 접근했을 때 next-auth를 통해 깃허브 로그인을 할 수 있게끔 했고 로그인한 계정의 정보와 버셀에 등록한 secret 값이 일치할 시 헤더에 '게시글 작성 페이지'로 이동하는 버튼을 놓고 해당 페이지로 접근시 유효성 체크를 하였죠.

```js
// admin/index.tsx
import { signIn } from "next-auth/react";
import { useEffect } from "react";

export default function AdminRedirect() {
    useEffect(() => {
        signIn("github", { callbackUrl: "/" });
    }, []);

    return <p>Loding...</p>;
}

// write/index.tsx
import { useRouter } from 'next/router';
import { useSession } from 'next-auth/react';
import { useEffect, useState, useCallback } from 'react';
import { Write } from '@/components/pages/Write';

const WritePage: React.FC = () => {
    const [notFound, setNotFound] = useState(false);
    const { isReady } = useRouter();
    const { data: session, status } = useSession();

    const load = useCallback(async () => {
        setNotFound(false);
        const authenticate = 
            !!(ACCESS 데이터 === process.env.NEXT_PUBLIC_GITHUB_ACCESS && status === "authenticated");

        if(!authenticate) {
            setNotFound(true);
        }
    }, [session, status]);

    useEffect(() => {
        if (isReady) {
			load();
		}
    }, [isReady, load]);

~~~~~~
```

게시글을 작성할 때는 현재 작성하고 있는 마크다운 내용들이 제가 커스텀한 마크다운 디자인으로 실시간 확인이 되길 원했어서 textarea에 onChange 이벤트와 useState set을 적용시켰죠 해당 데이터를 통해 상세 페이지에서 작성한 코드를 응용하면 이처럼 작성페이지와 미리보기를 만들 수 있어요.

![post_write.webp](https://d2ut7x8yqv441q.cloudfront.net/posts/1741333505378.webp)

그러면 완성된 게시글을 등록해보죠. 

onClick 이벤트를 통해 작성한 게시글이 GitHub의 main 브랜치에 업로드되며, Vercel에서 자동으로 배포될 수 있도록 설정했어요. GitHub의 Settings → Developer settings에서 OAuth를 생성하고, 발급된 OAuth 토큰을 활용해 블로그 레포지토리와 연결했어요. 이후, useState로 관리하는 post 데이터를 기반으로 Front Matter를 생성하고, 커밋 메시지, GitHub API URL, 마크다운 파일 경로 등을 설정하여 업로드할 수 있도록 구현했어요.

```js
import { format, parseISO } from "date-fns";
import { PostType } from "@/models/pages/slug";

export const uploadToGitHub = async (post: PostType) => {
    const repo = process.env.NEXT_PUBLIC_GITHUB_REPO!;
    const branch = process.env.NEXT_PUBLIC_GITHUB_BRANCH!;
    const token = process.env.NEXT_PUBLIC_GITHUB_ACCESS_TOKEN!;
  
    const filePath = `frontend/src/posts/${post.title}.md`;
    const commitMessage = `docs: ${post.title} 게시글 작성`;
  
    // GitHub API URL
    const url = `https://api.github.com/repos/${repo}/contents/${filePath}`;
  
    const frontMatter = [
        "---",
        `title: "${post.title}"`,
        `regDate: "${format(parseISO(post.regDate), "yyyy-MM-dd HH:mm")}"`,
        `description: '${post.description}'`,
        `thumbnailImage: '${post.thumbnailImage}'`,
        `mainTag: '${post.mainTag}'`,
        `tags: ${JSON.stringify(post.tags)}`,
        "---",
    ].join("\n");

    const markdownWithMetadata = `${frontMatter}\n\n${post.content}`;

    // 파일 내용 Base64 인코딩
    const contentEncoded = Buffer.from(markdownWithMetadata, "utf-8").toString("base64");
  
    // 기존 파일 체크 (있으면 업데이트)
    const existingFile = await fetch(url, {
        headers: { Authorization: `token ${token}` },
    }).then(res => res.ok ? res.json() : null);
  
    const requestBody = {
        message: commitMessage,
        content: contentEncoded,
        branch: branch,
        ...(existingFile && { sha: existingFile.sha }),
    };
  
    // GitHub API 요청 (파일 업로드 또는 수정)
    const response = await fetch(url, {
        method: "PUT",
        headers: {
            Authorization: `token ${token}`,
            "Content-Type": "application/json",
        },
        body: JSON.stringify(requestBody),
    });
  
    if (!response.ok) {
        throw new Error("GitHub 업로드 실패");
    }
  
    return response.json();
};
```

### 5. 라이트 모드 & 다크 모드
라이트 모드와 다크 모드 변경은 Redux와 localstorage를 이용하여 개발해 보았어요. 페이지가 처음 로드가 되었을 때 dispatch를 통해 default theme의 값을 dark로 지정한 후 헤더의 있는 버튼을 누를 경우 store 이벤트를 통해 반대의 theme로 업데이트 되도록 구성하였어요

```js
export const loadLayoutTheme = (dispatch: Dispatch) => {
    dispatch(actions.updateTheme(getLayoutTheme() || 'dark'));
};

export function toggleUpdateLayoutTheme(store: AppStore) {
    return (currentTheme: string) => {
        const theme = currentTheme === 'light' ? 'dark' : 'light';
        updateThemeState(store, theme);
    };
}

const updateThemeState = (store: AppStore, theme: string) => {
    store.dispatch(actions.updateTheme(theme));
    updateLayoutTheme(theme);
};
```

이렇게 변경된 theme를 useEffect를 통해 theme가 변경될 시 html 속성값에 넣어놓고

```js
    useEffect(() => {
        document.documentElement.setAttribute("data-theme", theme);
    }, [theme]);
```

```js
@use './dark' as dark;
@use './light' as light;

html[data-theme="dark"] {
	--background: #{dark.$backgroundColor};
	--sub-background-color: #{dark.$subBackgroundColor};
	--foreground: #{dark.$fontColor};
	--sub-font-color: #{dark.$subFontColor};
	~~~
}

html[data-theme="light"] {
	--background: #{light.$backgroundColor};
	--sub-background-color: #{light.$subBackgroundColor};
	--foreground: #{light.$fontColor};
	--sub-font-color: #{light.$subFontColor};
    ~~~~   
}
```

data-theme가 변경될 때 CSS 변수를 통해서 전역적으로 신고를 하고 다크 모드 및 라이트 모드의 테마를 동적으로 적용할 수 있도록 구성하였어요. 또한 theme가 바뀔 때 자연스러웠으면 좋겠어서 transition 속성을 적용시키기도 하였죠.

### 6. 추가사항
게시글을 작성할 때 이미지 삽입처리는 아마존의 S3, CloudFront를 이용하여 드래그앤드롭시 S3에 이미지가 업로드되며 화면에 출력될 수 있도록 작업을 하였어요 해당 기능에 관련된 내용은 아래의 블로그에 잘 작성되어 있습니다.
https://www.chanwooyam.dev/series/next-blog/fhE9lkS8xo8aEbKvo6uR

## 마지막으로
곧 퇴사를 앞두고 있네요.
프로그래머로서 스스로에게 부족한 부분이 무엇인지 명확이 파악이 되었고 CS 지식과 알고리즘이 많이 부족하다는 것을 알게되었어요. 이 블로그를 통해서 부족한 부분을 점차 채워나가는 모습 보여드릴게요.

tstory, 네이버블로그, velog 등을 이용하지 않고 최근에 진행했던 프로젝트의 환경을 기반으로하여 블로그를 만들고 싶었어요. CS 지식이 많이 부족한 스스로에게 공부를 메모할 수 있는 나만의 공간을 만들어보고 기능들을 사용하여 블로그를 만들어봅시다.

React, Next를 이용한 개인블로그는 어떻게 만들까


## 예시
리액트를 공부하는 도중 기본적으로 내가 아는 프로그래밍의 구조와는 다른 것을 배웠다. React의 공식 문서에는 나와있다. 'useState는 비동기적으로 작동한다.' 또한 이를 통하여 일괄 처리(batching) 이 무엇이며 여러 상태 업데이트를 적용하는 방법을 알 수 있다.

```js
const [ isEditing, setIsEditing ] = useState(false);

const handleEditClick = () => {
    setIsEditing(!isEditing);
}

return (
    <li>
        <button onClick={handleEditClick}>눌러줘~</button>
    </li>
);
```

button을 클릭했을 때 isEditing의 값은 true이다.
그러면 다음 코드를 예상해보자

```js
const [ isEditing, setIsEditing ] = useState(false);

const handleEditClick = () => {
    setIsEditing(!isEditing);
    setIsEditing(!isEditing);
}

return (
    <li>
        <button onClick={handleEditClick}>눌러줘~</button>
    </li>
);
```

위 코드에서의 isEditing의 값이 무엇이 될까?
해당 코드만 확인했을 때는 기존 useState를 통하여 isEditing의 값은 false이며 onClick 이벤트가 실행되었을 때  setIsEditing(!isEditing) 을 두번 실행하여
false => true => false 즉 false 값이 나올 것이 예상된다.
하지만 예상과는 달리 isEditing의 값은 true로 처리되어 프로그램이 흘러가는 것이 확인된다.

이러한 이유를 알아보자  
  

리액트는 상태 변경 스케줄을 조율하는데 두 변화 모두 isEditing의 현재 상태를 기준으로 삼는다. 즉 시작점은 false이다 그렇기 때문에 저 두 줄 모두 isEditing가 false인 시점을 기준으로 잡힌다. 

onClick 핸들러가 React에게 지시하는 작업을 확인해보자
```list
1. setIsEditing(!isEditing);
== 다음 렌더링 때 isEditing을 기존 false에서 true로 변경할 준비를 해!

2. setIsEditing(!isEditing);
== 다음 렌더링 때 isEditing을 기존 false에서 true로 변경할 준비를 해!
```

setIsEditing(!isEditing)을 두 번 호출했음에도 불구하고 이 렌더링에서의 이벤트 핸들러의 isEditing은 항상 false이므로 그저 state의 값을 true로 두 번 설정한 것이다. 이것이 이벤트 핸들러가 완료된 후 React가 컴포넌트 안에 isEditing을 false가 아닌 true로 다시 렌더링 하는 이유이다.

리액트 공식문서에 예가 있다.

```list
레스토랑에 주문을 받는 직원이 있다고 가정하자 직원은 한개의 주문을 받을 때마다 주방으로 가지 않을 것이다.
주문을 마무리할 때까지 기다리고, 주문을 변경할 수 있도록 해주며 테이블에서 다른 손님들의 주문도 받을 것이다.
```

그러면 여기서 Batching이란 무엇인지 알아보자

## Bactching이란?
Bactching이란 React가 더 나은 성능을 위해 state 업데이트를 한 번은 리렌더링으로 묶어 진행하는 것을 뜻한다.
즉 여러개의 state가 업데이트 될 때마다 반복적으로 발생하는 불필요한 렌더링을 최적화 하는 것이다.
UI가 이벤트 핸들러 및 그 안에 있는 모든 코드가 완료된 후에야 업데이트 되는 것 이러한 것을 Bactching이라고 한다. 이를 통해 React 앱이 훨씬 빠르게 실행된다고 한다.


그렇다면 위 코드가 false가 나오게 하는 방법은 없을까

```js
const [ isEditing, setIsEditing ] = useState(false);

const handleEditClick = () => {
    setIsEditing((editing) => !editing);
    setIsEditing((editing) => !editing);
}

return (
    <li>
        <button onClick={handleEditClick}>눌러줘~</button>
    </li>
);
```

(editing) => !edting 업데이트 함수를 통하여 상태 설정 함수에 전달할 때 React는 이 함수를 이벤트 핸들러 내의 모든 다른 코드가 실행된 후에 처리하기 위해 대기열에 추가한다.

해당 핸들러에 대한 작업을 확인해보면

1. setIsEditing((editing) => !editing);
== isEditing을 기존 false에서 true로 바꿨네 true를 대기열에 추가할게
2. setIsEditing((editing) => !editing)

== 이전 대기열의 값이 true네? false로 바꾸고 false를 대기열에 추가할게

이처럼 React는 이전 업데이터 함수의 반환 값을 다음 업데이터 함수로 isEditing을 전달하고, 이런 식으로 계속된다.

### 요약
```list
- 상태를 설정하는 것은 기존 렌더링 내의 변수를 변경하지 않지만, 새로운 렌더링을 요청한다.
- React는 이벤트 핸들러가 실행된 후에 상태 업데이트를 처리합니다. 이를 일괄 처리(batching)라고 한다.
- 한 이벤트 내에서 상태를 여러 번 업데이트하려면 setIsEditing((editing) => !editing) 업데이트 함수를 사용할 수 있다.
```

리액트를 공부하는 도중 기본적으로 내가 아는 프로그래밍의 구조와는 다른 것을 배웠다. React의 공식 문서에는 나와있다. useState는 비동기적으로 작동한다. 또한 이를 통하여 일괄 처리(batching) 이 무엇이며 여러 상태 업데이트를 적용하는 방법을 알 수 있다. 이를 통해 Batching과 상태 변경의 관계에 대해 알아보자

Batching과 상태 변경의 관계


출근을 하여 컴퓨터를 켠 후 프로필에 지문인식, 비밀번호 입력하여 로그인을 로그인을 했을 때

```caution
"윈도우 10 로그온이 user profile service 서비스에서 실패했습니다 사용자 프로필을 로드할 수 없습니다."
```

위와 같은 오류가 나면서 프로필에 로그인이 되지 않는 문제가 발생하였다. 컴퓨터를 몇번이나 다시 시작해도 해당과 같은 오류가 발생하며 로그인이 되지 않았고 검색을 통하여 문제를 해결하였다.

그러면 해당 오류를 해결하는 위해서는 어떻게 해야할까?.

검색결과 사람들마다 해결 방법이 조금씩 다르지만 이렇게 해결해 보았다.

1. window 로그인 창에서 shift를 계속 누른 상태에서 로그아웃을 클릭하여 윈도우 복구 환경에 진입한다.

2. 모든 사이트와 어플이 없는 복구 환경에서 아래와 같은 경로로 이동한다.

```list
시작 => 레지스트리 편집기 => HKEY_LOCAL_MACHINE => SOFTWARE => Microsoft => Windows NT => CurrentVersion => ProfileList
```

3. ProfileList에 들어가보면 가장 하단에 같은 이름의 폴더가 두개 존재하며 그 중 하나는 .bak 으로 되어있다.

4. 여기서 .bak으로 되어있지 않은 폴더를 .bak2 을 붙여 이름을 바꾸고
```list
ex) S-1-5-21-2641910279-66850460-2938557443-1001 
=> S-1-5-21-2641910279-66850460-2938557443-1001.bak2
```

5. 기존에 .bak으로 되어있던 폴더에 .bak을 제거해준다.
```list
ex) S-1-5-21-2641910279-66850460-2938557443-1001.bak 
=> S-1-5-21-2641910279-66850460-2938557443-1001
```

6. 컴퓨터를 재부팅 해본다.

해당 오류에는 명확한 이유를 찾지 못하였다. 원인이 있다면 사용자 계정이 손상되어서 그렇다는 내용만이 확인되었다.

"윈도우 10 로그온이 user profile service 서비스에서 실패했습니다 사용자 프로필을 로드할 수 없습니다." 위와 같은 오류가 나면서 프로필에 로그인이 되지 않는 문제가 발생하였다. 컴퓨터를 몇번이나 다시 시작해도 해당과 같은 오류가 발생하며 로그인이 되지 않았고 검색을 통하여 문제를 해결하였다.