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

## 한화생명 코어 프로젝트
```list
생명보험, 손해보험, 운영비, 수수료 지급 등등의 20개가 넘는 수수료 시스템이 존재합니다.
```
개발자로 처음 입문하는 프로젝트라 굉장히 설레이고 떨렸던 것으로 기억해요 제가 담당했던 파트는 '수수료 관리 시스템' 파트이며 한화 생명에 소속되어있는 모든 FP(보험설계사) 분들에게 수수료를 지급하는 것이 궁극적인 목표였죠, 매 월 기간내에 지급되는 시스템을 관리하고 보험 약관에 맞춰 새로운 기능을 개발하고 보수를 하였으며 또한 리뉴얼 개발로 인한 차세대 시스템을 개발하였고 Core에서 받아오는 데이터를 위한 시스템을 개발하였죠.

### 수수료 지급 프로세스
담당했던 수수료 지급의 프로세스는 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장정도 되는 명칭들을 출퇴근할때 외웠던 것으로 기억이 나요. 모든 것이 처음이여서 적응을 하는데 힘이들었지만 좋은 팀원분들 덕분에 실력도 많이 늘고 해당 프로젝트를 마칠 때는 웃으면서 철수할 수 있었던 것 같아요.

## 사내 홈페이지 신규개발
한화생명 프로젝트에서 철수한 뒤 회사 홈페이지를 새롭게 만드는 프로젝트를 진행하였어요. 기존 홈페이지 UI는 정말 오래된 옛날 홈페이지의 UI이었고 동료 2분과 함께 총 3명에서 사내 홈페이지를 개발했죠. 저를 많이 아껴주시는 이사님께서 제 주도하에 홈페이지를 구축하라고 전달하셨고 저는 홈페이지를 기획 및 개발까지 모두 참여하였어요. 가장먼저 홈페이지를 개발할 때 요구사항은 세가지였어요.
```list
1. 관리자페이지를 통하여 홈페이지를 관리할 수 있도록 함
2. 최신 홈페이지에 맞게 스크롤링을 통한 UI가 구성될 수 있도록 함
3. 한글, 영문페이지가 있도록 함
```
이러한 요구사항이 들어왔고 이사님, 동료분들이랑 회의를 한 결과 OJT 때 만들었던 관리자 시스템을 이용하여 홈페이지를 관리할 수 있도록 했어요. 이후 다음으로는 IT 회사에 맞게 홈페이지의 템플릿과 레퍼런스 찾아갔죠. 레퍼런스를 찾았으면 홈페이지의 사이트맵을 최대한 자세히 만드려고 했어요.

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

이처럼 구체적으로 전체 페이지를 잡고 회사의 얼굴이 될 메인페이지와 각 서브페이지를 기획하였어요 각 사업부에 부장님들에게 사진 및 사업부 소개에 들어갈 자료들을 받았죠.
다행이도 로그인을하여 무엇을 판매, 구매 및 글을 작성하고 이러한 이커머스 속성이 없는 홈페이지며 회사를 얼마나 아름답게 표현할 수 있느냐만 홈페이지에 담기만 하면 되기때문에 복잡하고 어려운 기능들이 없었어요. 즉 홈페이지의 UI 디자인적 요소가 가장 중요한 것이죠.

한글 및 영문페이지 같은 경우 회사 내부 영어를 잘 하시는 분께 번역한 내용을 컨펌 받았으며 쿠키값을 이용하여 한글 및 영문페이지를 변경할 수 있도록 개발을 진행했어요.

메인페이지나 서브페이지의 디자인이 모두 완료되었으면 각 부서에서 받은 자료를 참고삼아 내용을 입력하였고 홈페이지의 들어갈 이모티콘이나 고화질사진의 결제를 진행하였으며 1차적으로 홈페이지가 완성된 후 본사에 들려 대표님과 각 사업부의 부장님들에게 변경될 홈페이지를 소개하였어요. 이러한 과정의 이유는 각 사업부마다 개선사항이 분명히 있을 것으로 생각되어 회의를 진행하게 되었죠. 

마지막으로 SEO 및 Analytics를 개발하여 홈페이지에 적용시켜 최종적으로 개발이 끝나게 되었어요.

도메인같은 경우 기존에 사용하고 있던 카페24의 도메인을 그대로 이용하였어요. 배포를 진행할 때 ROOT 파일만 교체하면 되기 때문에 큰 어려움은 없었어요. 혹여나 운영서버에서 이슈사항이 발생할 수 있음으로 사용하지 않는 도메인을 개발서버로 이용하여 테스트를 진행하였어요.

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

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

```point
먼저 구분을 위해 리뉴얼 개발 전을 AS-IS 리뉴얼 개발 후를 TO-BE 라고 지정할게요.
```

### AS-IS 프로젝트
AS-IS 프로젝트는 낯선 기술들이 정말 많았어요. `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 개선이 들어올 경우 일본에서 오는 문서를 확인하여 개발을 진행하였죠. 

신규 개발 건이 발생하면 필요한 API가 있는 경우 직접 필요한 데이터 구조를 정의해서 일본 본사에 요청한 뒤 데이터를 받아 개발하는 방식으로 진행했어요. 즉 단순히 요청만 하는 게 아니라 어떤 데이터가 필요한지 어떤 형식으로 오는 게 효율적인지까지 고민해서 정의해야 했기 때문에 처음에는 시간이 좀 걸렸지만 점점 속도를 높일 수 있었어요. GA4(Google Analytics 4), 리뷰 및 문의 페이지의 Admin 기능을 개선하는 작업도 진행했어요. CAD 파일 다운로드 대기 기능도 개발했는데요 CAD 파일 용량이 크기 때문에 바로 다운로드할 수 없는 상황을 고려해 다운로드 요청 시 상태값을 관리하고 파일이 준비되었을 때 다운로드가 가능하도록 비동기 처리 구조로 개발했어요. 또 하나는 검색창, 상품 카테고리, 상품 상세페이지에 적용된 상품 추천 기능을 개발했어요. 이 기능은 사용자가 특정 상품을 검색하거나 조회했을 때 같은 카테고리 내 유사 상품 유형(예: 브랜드, 타입, 가격대 등)을 기반으로 추천 상품 리스트를 보여주는 구조예요. 이때 단순히 카테고리 매칭만 하는 게 아니라 관련성 높은 상품을 우선적으로 노출하는 것이죠. 상품 추천 기능을 실제로 적용한 이후 다양한 상품의 조회수나 구매 수가 눈에 띄게 증가하는 걸 보면서 꽤 뿌듯했어요. 단순히 기능을 구현하는 걸 넘어서 실제 비즈니스 성과로 연결되는 개발을 경험한 건 이번이 처음이라 의미가 컸던 것 같아요.

### TO-BE 프로젝트
어떻게 보면 이번 AS-IS 프로젝트는 TO-BE React 프로젝트를 진행하기 위한 준비 과정이었다고 생각해요. 모든 구조를 정확히 파악했을 때쯤 바로 TO-BE 프로젝트가 시작됐어요. TO-BE 프로젝트의 개발 환경은 크게 `React, TypeScript, Next.js, Redux`로 구성되어 있었어요. 현재 가장 인기 있고 실제로 많이 쓰이는 기술들이라 그런지 굉장히 설레기도 했고 한편으로는 긴장도 많이 됐어요. 

각 기술은 단순히 강의에만 의존하지 않고 강의나 유튜브로 기초를 다진 다음 공식 Document를 최대한 많이 참고하려고 했어요. 그리고 공부한 내용을 바탕으로 동일한 환경의 간단한 개인 프로젝트도 직접 진행해봤어요. 그렇게 공부하다 보니 처음엔 많이 어렵던 것들도 점점 익숙해졌어요. 프로젝트 초반과는 다르게 PM님께서는 저에게 많은 부분을 개발할 수 있도록 맡겨주었죠. 덕분에 다양한 경험을 할 수 있었고 개발에 대한 자신감도 조금씩 쌓였어요. TO-BE 프로젝트는 총 5개월로 계획되었어요. 처음 3개월 동안은 개발을 이후 2개월 동안은 테스트를 진행하면서 기능들을 다듬었으며 본 서버로 릴리즈가 완료된 이후에는 안정화 기간에 들어섰어요.

TO-BE 프로젝트에서 제가 맡게 된 주요 개발 항목들도 정리해볼게요.
```list
* 공통 Header 개발: 로고, 문구, 견적/주문, 장바구니, 문의,로그인/로그아웃 등 구현
* 카테고리 페이지 및 서브·말단 카테고리 UI 설계 및 개발
* 검색 기능 개발: 검색창, 주문, 장바구니, 배너, 상품 정보 미게재 주문 지원
* 공통 플로팅 바 구현: 상품 추천, CAD, 비교하기, 견적/주문 등 기능 개발
* 공통 유저 기능 개발: 권한 관리, 가격 확인, 장바구니, 마이부품표, 회원 정보 및 배송 정보 관리
* 메인 페이지 설계 및 개발
* 브랜드 페이지 UI 개발
* 상품 비교 기능 및 비교 페이지 구현
* AA 및 GA 연동 및 데이터 분석 기능 개발
```
홈페이지를 개발할 때는 영역별로 우선순위가 있죠. 해당 리스트를 참고해서 1순위, 2순위를 정하면 모든 페이지에 공통으로 들어가야 하는 Header, 플로팅 바, 공통 유저 기능 같은 것들이 1순위가 되고 그 외 기능들은 2~3순위로 나뉘게 됩니다. 그래서 제가 맡은 공통 컴포넌트들을 빠르고 완성도 높게 개발해야 이후 다른 기능들도 문제없이 진행될 수 있었어요.

이번 프로젝트가 이전 사내 홈페이지 개발과 다른 점은 예전에는 제가 주도해서 기획서를 만들고 개발을 진행했는데 이번에는 기획서나 설계서를 받은 뒤 그것을 토대로 개발을 해야 했다는 점이에요. 특히 일본 본사에서 전달받은 문서들이 모두 일본어로 되어 있어서 정확하게 분석하고 이해하는 데 생각보다 시간이 많이 걸렸어요. 단순히 번역하는 게 아니라 요구사항의 의도까지 파악해야 했기 때문에 더 꼼꼼하게 문서를 읽어야 했어요.
게다가 이번에는 실무에 바로 적용되는 새로운 기술들을 사용해야 해서 쉬운 작업은 아니었어요. 개발과 테스트를 병행하면서 5개월 동안 거의 매일 야근을 했지만 새로운 기술을 배우고 적용하는 재미 덕분에 힘들면서도 시간 가는 줄 몰랐어요.

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

이커머스 홈페이지 특성상 하나의 페이지에 많게는 수백 개의 이미지가 들어가야 하는데 이렇게 되면 렌더링 속도가 느려지는 문제가 발생할 수밖에 없었어요. 위 개발 목록중 메인페이지, 카테고리 페이지, 브랜드 페이지가 이에 속했죠. 이를 해결하기 위해 아마존 S3를 이용한 CDN 방식을 적용하거나 BASE64로 이미지를 변환해 불러오는 방법을 사용했어요. 또한 이벤트를 통해 불러오는 이미지들은 Lazyload를 적용해서 초기 렌더링 속도를 최대한 빠르게 당길 수 있도록 했어요.

가장 오래걸렸던 개발 건은 GA(Google Analytics), AA(Adobe Analytics) 이 두가지에요. 모든 페이지와 각 이벤트별로 개발을 진행해야 했으며 해당 기능의 설계서또한 명확하지 않아 일본에 있는 본사 직원분과 소통을 하는데에도 어려움이 있었고 개발이 완료된 후 제대로 수집이 되고있는지 확인을 해야하기 때문에 시간이 오래 걸렸죠. 오래 걸리더라도 확실하고 정확하게하자 라는 마음가짐으로 해당 기능을 개발했던 것 같아요.

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

이전 회사에서 진행했던 모든 프로젝트를 정리해 보았어요. 이를 통해 복습도 하고 초심을 가꿔보려고요

지금까지 진행했던 프로젝트에 관하여


## 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.png](https://d2ut7x8yqv441q.cloudfront.net/posts/1741325521155.png)

### 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.png](https://d2ut7x8yqv441q.cloudfront.net/posts/1741331013306.png)

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

작성한 마크다운의 내용으로 목차도 자동생성이 되면 좋겠다 라는 마음이 있어 추가로 개발을 해봤어요. 목차의 기준을 마크다운의 헤딩을(#, ##, ###)을 통해 만들어 볼게요. 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.png](https://d2ut7x8yqv441q.cloudfront.net/posts/1741333505378.png)

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

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

지금까지 진행했던 프로젝트에 관하여

퇴사 후 새로운 시작 전 회고

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

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

Batching과 상태 변경의 관계

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