FE가 되고싶니? 나도✨

지난 포스팅인 코딩하는데 4시간, 배포하는데 1시간 걸렸던 [첫 배포하기] 이후에 리액트를 학습하게 되었다.

파트 2에서 같은 팀에 배정 된 분들이 노션을 많이 사용하셨는데 쓰다보니 마크다운 언어에 흥미를 느껴 노션을 즐겨 사용하게 되었다. 덕분에 블로그에 조금 뜸하게 들어왔지만,.. 역시 회고는 블로그가 제 맛이다.

팀 프로젝트에서 나의 역할은 공통영역, 헤더, 버튼, 카드 (컴포넌트) 이다.

코린이와 첫 프로젝트 진행으로 많은 난관이 예상되는 나는 팀원분들의 배려로 그나마 쉬운(?, 근데 사실 쉽지 않다는 멘토님의 말씀🥲🫠) 부분을 맡게 되었는데 하,, 쉽지 않다. 뭐랄까 신경써서 해야할게 너무 많다. 규칙은 뭐가 그렇게 많고 복잡한지 모르겠다.🥲 울고싶지만 어쩌겠는가. 해내야지.

사용하기로 한 기술

• React, Vite, react-router
• Prettier, ESLint, Husky
• Tailwind CSS
• VSCode, Figma, Github

라이브러리

• 에디터
• /list 페이지 캐러셀
• 이모지 기능
• axios

코드 컨벤션, 네이밍 컨벤션, 커밋 메시지 컨벤션

• 코드 컨벤션 : 토스트 컨벤션 (너무 세세하진 않게)
  • 코딩 컨벤션은 읽고, 관리하기 쉬운 코드를 작성하기 위한 일종의 코딩 스타일 규약
  • 들여쓰기 : space와 tab을 섞어서 사용하지 않기.
  • 문장의 종료 : 한줄에 하나의 문장만 허용! 문장 종료시 세미콜론(;) 사용!
  • 명명규칙 : (기본, 변수나 함수) 카멜 케이스 사용, 예약어 사용X, 상수는대문자 SNAKE_CASE 사용
  • 전역변수 사용 X
  • 값이 변하지 않는 변수는 const 변하는 변수는 let 사용 (var 사용금지)
  • const를 let보다 위에 사용하고 선언시점에 선언 및 할당 할 것
  • 배열과 객체는 반드시 리터럴로 선언
  • 일관된 줄바꿈
  • 주석은 설명하려는 구문에 맞춰 들여쓰기 
• 네이밍 컨벤션 : 브랜치 작업 시 모아서 정하기
• 커밋 메시지 :
  • feat : 새로운 기능 추가
  • fix : 버그 수정
  • docs : 문서의 수정
  • style : (코드의 수정 없이) 스타일만 변경 (들여쓰기 같은 포맷이나 세미콜론을 빼먹은 경우 등)
  • design : 사용자 UI 디자인 변경 (CSS 등)
  • refactor : 코드를 리펙토링
  • test : TEST 관련한 코드의 추가, 수정
  • chore : (코드의 수정 없이) 설정을 변경, 
  • build : 빌드 파일 수정
  • ci : CI 설정 파일 수정
  • perf : 성능개선
  • rename : 파일 혹은 폴더명을 수정만 할 경우
  • remove : 파일을 삭제만 한 경우 

커밋 메시지의 7가지 규칙

• • 1. 제목과 본문을 빈 행으로 구분한다.
    2. 제목은 50글자 이내로 제한한다.
    3. 제목의 첫 글자는 대문자로 작성한다.
    4. 제목 끝에는 마침표를 넣지 않는다.
    5. 제목은 명령문으로 사용하며 과거형을 사용하지 않는다.
    6. 본문의 각 행은 72글자 내로 제한한다.
    7. 어떻게 보다는 무엇과 왜를 설명한다.
       • Header는 필수이며 스코프는 생략 가능
       • 타입은 해당 커밋의 성격을 나타내며 위 타입 중 하나여야 한다.
       • Body는 Header에서 표현할 수 없는 상세한 내용을 적는다.
       • Footer는 바닥글로 어떤 이슈에서 왔는지 같은 참조 정보들을 추가하는 용도로 사용
       • Footer는 생략 가능
       • 예를 들어 특정 이슈를 참조하려면 Issues #1234 와 같이 작성
       • Header에서 충분히 표현할 수 있다면 생략 가능

// Header, Body, Footer는 빈 행으로 구분한다.
타입(스코프): 주제(제목) // Header(헤더)

본문 // Body(바디)

바닥글 // Footer

git commit -m "fix: Safari에서 모달을 띄웠을 때 스크롤 이슈 수정

모바일 사파리에서 Carousel 모달을 띄웠을 때,
모달 밖의 상하 스크롤이 움직이는 이슈 수정.

resolves: #1137

폴더 구조

프로젝트폴더/
├── node_modules/     # 설치된 패키지들
├── public/          # 정적 파일들
│   ├── vite.svg
├── src/
│   ├── components/  
│   │   ├── Button/
│   │   │   ├── index.jsx
│   │   │   └── styles.js
│   │   ├── Card/
│   │   │   ├── index.jsx
│   │   │   └── styles.js
│   │   ├── Header/
│   │   │   ├── index.jsx
│   │   │   └── styles.js
│   │   └── Footer/
│   │       ├── index.jsx
│   │       └── styles.js
│   ├── pages/
│   │   ├── Home/
│   │   │   ├── index.jsx
│   │   │   └── styles.js
│   │   ├── About/
│   │   │   ├── index.jsx
│   │   │   └── styles.js
│   ├── api/               
│   │   ├── axios.js       # axios 인스턴스 및 인터셉터 설정
│   │   ├── auth.js        # 인증 관련 API
│   │   └── product.js     # 상품 관련 API
│   ├── routes/            # 라우팅 관련 폴더 추가
│   │   ├── Router.jsx     # 라우터 설정
│   ├── styles/
│   │   ├── GlobalStyle.js
│   │   └── theme.js
│   ├── assets/
│   │   └── images/
│   │       ├── logo.png
│   │       └── banner.jpg
│   ├── App.jsx
│   └── main.jsx
├── .gitignore       # Git 제외 파일 설정
├── .env.local       # 로컬 환경 변수 (git에서 제외됨)
├── .eslintrc.js    # ESLint 설정
├── .prettierrc     # Prettier 설정
├── package.json    # 프로젝트 설정 및 의존성
├── package-lock.json  # 의존성 버전 고정
├── README.md       # 프로젝트 문서
└── vite.config.js  # Vite 설정 (CRA의 경우 불필요)

브랜치 전략

• Git Flow 전략
  • 예시_ feat/from, feat/components 등
  • main 브랜치 :  제품 출시 버전을 관리하는 메인 브랜치 . 프로젝트 시작시 생성된다. 개발 프로세스 전반에 걸쳐 유지
  • develop 브랜치 : 다음 버전 개발을 위한 코드를 모아두는 브랜치. 개발완료 후 main 브랜치로 머지됨
  • feature 브랜치 : 하나의(새로운) 기능을 개발하기 위한 브랜치. develop 브랜치에서 생성. 기능이 개발 완료 되면 develop 브랜치로 머지.
    • 주의할 점 : Fast-Forward로 머지하지 않고 Merge Commit 을 생성하며 머지를 해주어야 함
    • 그래야 히스토리가 특정 단위로 묶임
    • 네이밍은 조금씩 차이가 있지만 "feature/branch-name"과 같은 형태로 생성
  • release 브랜치 : 소프트웨어 배포를 준비()하기 위한 브랜치. develop 브랜치에서 생성. 버전 이름 등의 소소한 데이터를 수정하거나 배포 전 사소한 버그 수정. 배포 준비 완료 후 main과 develop 브랜치에 둘다 머지. 이 때 main  브랜치에는 태그를 사용하여 버전 표시
    
    • 네이밍은 "release/v1.1"과 같은 형태로 생성
  • hotfix 브랜치 : 이미 배포된 버전에 문제 발생 시 이 브랜치를 통해 문제 해결. main 브랜치에서 생성. 문제 해결 완료 되면 main과 develop 브랜치에 둘 다 머지
    • 네이밍은 "hotfix/v1.0.1"과 같은 형태로 생성

1. 신규 기능 개발을 위해 개발자는 develop 브랜치를 기준으로 한 feature 브랜치를 따서 작업을 진행.
2. 작업이 완료된 feature 브랜치는 develop 브랜치로 병합 (Merge) 된다. (일반적으로 프로젝트 진행 시에는 Pull Request 를 통해 작업 내용을 Review 받은 후 해당 PR 을 Merge 하는 방식으로 진행한다고 함.)
3. 다음 출시 버전을 위해 개발 중인 develop 브랜치에서 release 브랜치를 따서 배포를 위한 준비. (이 때 발견되는 버그들은 release 브랜치에서 바로 반영.)
4. 충분한 테스트 후에, 일정한 주기로 (일반적으로는 배포하고자 하는 버전 단위) main 브랜치로 Merge 하여 제품을 출시.
5. 상용 배포 이후, release 브랜치에서 미처 발견되지 못한 새로운 버그들은 hotfix 브랜치에 바로 반영.

1단계 Github 팀 계정 fork 하기

가장 먼저! 프로젝트를 위해 팀장님이 만들고 초대해주신 Github 프로젝트를 팀원들은 각자 개인 Github 레포지토리로 fork 해야한다.

복습하는 느낌으로 다시 해보도록 하자. 먼저 Fork 해주기.

그리고 나서 나오는 이 화면에서 중요한 Tip! 

현재 Copy the main branch only의 체크박스에 체크가 되어있는데 이 뜻은 fork(복사)해 오는데 main 브랜치만 가져올건지 묻는것이다. 나는 팀프로젝트를 진행할거고 다른 브랜치에서 작업을 해줘야 하기 때문에 (이미 만들어져 있고 내가 만들게 아니기도 함) 꼭 체크박스를 해제 해주고 create fork를 해주도록 하자.

2단계 clone하기

그 다음으로 fork 해온 내 레포지토리를 로컬 작업 환경으로 clone해야한다.

git clone {fork 해 온 나의 repository 주소}

쨔쟌, 현재 디렉토리 아래에 프로젝트 이름을 따서 디렉토리를 만들고, 그 아래에 저장소를 복사한다. 여기서는 프로젝트 이름은 rolling이다.

3단계 원본 레포지토리 연결하기

clone으로 가져오면 기본적으로 origin이라는 이름에 내 원격저장소 URL이 연결된다.

원본 레포지토리 주소를 연결해줘야 내 컴퓨터(로컬)로 원본 레포지토리의 변경사항을 반영시킬 수 있기 때문에 연결을 해주어야 한다.

# 원격저장소 remote등록
git remote add {이름} {저장소 URL}

# 예시_ 원본 github 레포지토리를 upstream 이라는 이름으로 연결.
# git remote add로 연결한 후에는 추후에 다시 연결하지 않아도 된다.
git remote add upstream https://github.com/예시URL주소/rolling.git

# 원격저장소 확인
git remote -v

보통은 내 원격 저장소의 이름을 origin으로, 원본 저장소의 이름을 upstream으로 하는 것 같다.

4단계 브랜치 만들고 나누기

협업에서 정말 중요한 필수! 브랜치를 나눠놔야 어떤 브랜치에서 작업하던게 문제가 생기더라도 main에서의 코드는 유지되어 있기 때문에 role back(이전 리비전으로 문서를 되돌리는 행위)하기 쉽다.

우리 팀은 브랜치 전략으로 Git flow 전략을 쓰기로 해서 일단 develop 브랜치를 따로 만들어야한다.

# 브랜치 생성 명령어
git branch {브랜치명}

# git branch {생성할 브랜치명} {기준 브랜치명}
git branch develop main

# 브랜치를 잘못 만들었을 때 브랜치명을 수정할 수 있는 방법
git branch -m {잘못 만든 브랜치명} {수정할 브랜치명}

# 브랜치 이동
git checkout {브랜치명}

# 생성과 동시에 이동하는 옵션
git checkout -b {브랜치명}
 
# 브랜치 리스트 확인
git branch

Git Flow 구조 예시

master (또는 main)  # 실제 서비스 중인 코드
  └── develop       # 개발 중인 코드
      └── feature/login
      └── feature/payment
  └── hotfix        # 긴급 버그 수정
  └── release       # 출시 준비

5단계 만든 브랜치에서 작업 후 해야하는 것

브랜치를 만들고 개인 브랜치에서 코드 작업을 한다. 

코드 작업을 마친 후 코드를 저장한다.

# 현재 폴더의 변경 사항을 저장하기 위해 모두 '지정'한다.
git add .

# 지정한 파일들을 git에 저장한다.
git commit -m "메세지 입력"

그리고 본인 Github 레포지토리에 업로드 한다.

git push origin <브랜치명>

# 예시
git push origin Basic-step

💡여기서 주의해야할 것, push를 upstream(원본 저장소)에 하지 말고 origin(나의 원격 저장소)에 해야한다.

6단계 PR 요청

push까지 마치고 나면 내 Github저장소에 compare & pull request 버튼이 생성되어 있다. 해당 버튼을 눌러서 전달사항 및 변경사항을 기록하고 pull request 요청하면 된다.

Pull Request란 '코드를 수정했는데 당신도 코드를 수정했다면 제 수정한 내용도 적용시켜 주세요' 라는 의미이다.

작업을 하다보면 PR을 이미 했는데 '아! 이거도 같이 수정(추가)해서 할걸!'할 때가 있다.
이럴 땐 굳이 PR을 취소하고 다시 commit/push후 PR할 필요 없이 그냥 PR이 이미 올려진 상태에서 commit/push를 진행하면 된다. (같은 branch로 push 해야함.)

그러면 해당 branch에 대한 PR에 추가로 push한 commit기록이 쌓이게 된다.

다만 협업의 경우 내가 추가 push하기 전에 다른 사람이 PR확인 후 merge시킬 수 있으니 미리 고지 후에 추가로 push하는 것이 좋다.

7단계 머지(merge)

작업한 내용을 PR요청하면 다른 팀원은 원본 저장소에서 PR 내용을 확인 할 수 있다.

그리고 해당 내용이 다른 코드에 영향을 미치지 않고, 원본 저장소에 반영해도 되겠다는 판단이 들면 그때 하는 것이 merge. 즉, 변경사항을 원본에 병합하는 것이라고 생각하면 된다.

만약 merge를 진행하게되면 PR내용은 닫혀서 사라지게 되고 원본 저장소에는 바뀐 내용이 반영되어 합쳐진다.
(문제가 있다고 판단될 시에는 이를 거절할 수도 있다.)

# 1. 메인 브랜치로 이동
git checkout main

# 2. 기능 브랜치 병합
git merge feature/login

## 실제예시 상황
# 1. 로그인 기능 완성 후 메인으로 이동
git checkout main

# 2. 로그인 브랜치 병합
git merge feature/login

# 3. 기능 브랜치 삭제 (선택사항)
git branch -d feature/login

8단계 merge가 완료되면

merge가 완료되면 내 로컬 파일에도 다른 사람이 추가한 내용이 반영된다.

#git pull {원본 remote 이름} {브랜치명}

git pull upstream develop

9단계 브랜치 삭제

해당 작업이 완료된 branch는 삭제해준다.

git branch -d {브랜치명}

지난 포스팅에서 c드라이브에서 어플리케이션을 수행하면 앞으론 잘 동작될거라고 생각했던 나의 핑크빛 리액트 미래는 산산히 무너지고 말았다.

아니 이 망나니 녀석 왜 강사님 앞에선 됐으면서 나 혼자 남으니까 또 안되는거냐. 이거 그거 아니냐고 컴퓨터 수리 기사님 오면 컴퓨터가 마치 아팠던 적 없는 척 하는 그거. 하필 12월 31일 강사님 마지막 근무시간까지 나한테 할애를 하면서 고쳐낸건데 1월 1일이라 도움의 손길을 요청할 수도 없는 노릇이었다.

진짜 열받네. 너는 형벌이다. 포맷.

결국 포맷 엔딩루트를 타고 "vs code와 nodejs만 설치해서 확인해보면 리액트가 완전히 고쳐졌겠지?" 라는 나의 망상은 나를 철저하게 깨부셔주었다.

npm : 이 시스템에서 스크립트를 실행할 수 없으므로 C:\Program Files\nodejs\npm.ps1 파일을 로드할 수
없습니다. 자세한 내용은 about_Execution_Policies(https://go.microsoft.com/fwlink/?LinkID=135170)를
참조하십시오.
위치 줄:1 문자:1
+ npm init
+ ~~~
    + CategoryInfo          : 보안 오류: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

🤦‍♀️네..? 이게 무슨 소리요 의사양반, 포맷하면 다 괜찮아 지는거 아니였소?     🤷‍♂️네 아닙니다.

오류 코드를 구글링해서 해결 방법을 찾아보니 nodejs/npm.ps1을 삭제하면 해결이 될거라는 어느 개발자 블로그를 참고해 해당 파일을 찾아나섰다.

그런데 해당 디렉토리에 들어가서 찾아봐도 npm.ps1이라는 파일은 찾아 볼 수 없었고, powershell로 숨겨진 파일 목록까지 보여주는 ls -al을 작성해봤지만 powershell에서 la -al 명령어를 인식하지 못했다. (자꾸 빨간색으로 어쩌구 저쩌구 하는데 list는 보여주지 않음)

여기서 2차 열받. 포맷하는것도 지금 큰 마음 먹고 한거구만 왜 이런 시련을 주는것이죠..?

재포맷간다. (두번째 포맷)

그래서 두번째 포맷을 하고 기본적인 셋팅(vscode, git 설치)만 해둔 뒤 날이 밝기를 기다렸고, 9시 땡 하자마자 강사님께 찾아가 나의 안타까운 사정을 읍소했다.

강사님과 줌에서 만나 화면 공유를 하고 node 설치부터 같이 했다.

원래는 c\program files\nodejs 로 설치되는 경로를 c\nodejs로 변경한 뒤 설치를 진행했고, C 드라이브 하위 폴더로 workspace라는 디렉토리를 만들어 이 안에서만 리액트 작업을 하기로 했다.

VSCode 오류 : 이 시스템에서 스크립트를 실행할 수 없으므로 C:\Users\...파일을 로드할 수 없습니 다. 
자세한 내용은 about_Execution_Policies(https://go.microsoft.com/fwlink/?LinkID=135170)를 참조하십시오.

LinkID=135170 ? 포맷 처음 했을 때 봤던 오류에서 참조하라는 사이트 주소랑 똑같은데라는 생각에 강사님께 첫 포맷에서 되지 않았던 npm.ps1 파일 삭제 실패 이슈를 말씀드렸고 git bash와 powershell을 관리자 권한으로 실행해서 powershell에서 ls -al이 되지 않던걸 git bash에서 명령어를 입력해 숨겨진 npm.ps1 파일을 찾았다.

그리고 rm -rf npm.ps1 / git bash에서 한다면 sudo rm -rf npm.ps1을 해줬고, npx.ps1도 똑같이 삭제 해 줬다.

그리고 테스트를 해봤더니 결과는 성.공.적.

하지만 지난번에 내가 다른 디렉토리를 만들고 리액트를 실행했을 때 실패했으므로 강사님과 줌을 하는 동안에 확인하고 싶었다. (강사님 계실때만 잘되고 나 혼자할 때 안되면 안되니까.)

그래서 c\workspace에 새로운 디렉토리를 만들고 vs code를 열어 터미널에 명령어를 입력했다.

npm init react-app .

설치가 되는듯 하면서 마지막엔 결국 erorr가 떴는데 강사님께서 당황하지 말고

npm i web-vitals
//i는 install의 줄임이다.

해당 명령어를 실행해보라는 말씀을 해주셨다.

그랬더니 터미널창은 다시 바쁘게 돌아가고 완료가 된 후에 

npm run start

를 해봤더니

잘 실행이 됐다.

강사님께 왜 npm i web-vitals를 해줘야 하는것이냐고 여쭤봤는데 이건 내 컴퓨터도, 윈도우 문제도 아닌 오픈 소스의 문제라고 하셨다. 저 명령어는 오픈 소스에서 불안정한 이슈를 안정화시켜주는..? 그런 용도라고. 오픈 소스에서 설치하는거에 문제가 있기 때문에 그런것이니 오픈소스에서 업데이트가 되어야 하고 당분간은 지금 진행했던 경로로 설치를 해야한다고 하셨다.

오픈 소스 이 사람들아... 빨리 업데이트 좀 해주세요.🙇🏻‍♀️🙇🏻🙇🏻‍♂️ 간곡히 부탁드립니다.

리액트 강의를 들으며 평화롭게 설치를 하던 중 난데 없는 날벼락이 발생하고 말았다.

두둥-

아니 강사 양반 나는 설치가 안되는데 어찌하여 그대만 혼자 쭉쭉 나간단 말이오.🤷🏻‍♀️

알수 없는 오류만 잔뜩인 채 해결하기 위해 구글링을 시작했다.

a complete log of this run can be found in

라고 검색해보면 관련된 후기 및 해결 방법 블로그들이 잔뜩 나타났다.

그 중 대표적인 방법으로 우선 캐시를 지워주는 일.

npm cache clean --force

하지만 이 역시 리액트가 설치되진 않았다.

그 다음으로 해본 일은 명령어 수정,

npm init react-app .
이라고 작성했던 명령어를 대신해서

npx create-react-app .
이라고 작성해주었다.

하지만 이것도 역시 오류가 발생했고,,,

전역으로 설치해보라는 글도 있어서 전역으로 설치도 시도 했으나 마찬가지였다.

npm install -g create-react-app
create-react-app C:\Users\사용자명\Desktop\hello_react

혼자서는 도저히 답이 나오지 않는것 같아 머리를 부여잡고 강사님을 찾아갔다.🥲

오류가 나는 화면을 들고 찾아가 도움을 요청 드렸더니 흔쾌히 요청을 수락해주셨다. (강사님껜 악몽의 시작이셨을지도 모를..) 그렇게 줌으로 강사님께 화면 공유를 했고, 강사님께서 이것저것 확인해보시며 나의 상황에 대해서 파악 해주셨다.

1. create-react-app이 deprecated (더 이상 업데이트 없음) 되서 node 최신 버전이랑 안맞을 수 있음
→node 버전 더 낮은 거 설치
→ nvm 설치해서 node 버전 여러 개 설치 가능
→ 혹은 vite 로 설치해서 확인 

2. 알약 같은 보안 프로그램이 실행을 막음 → 알약 및 보안 프로그램 삭제 필요
→ npm create vite@latest . -- --template react

으로 축약되어 해결을 위해 같이 열심히 2-3시간 동안 붙잡고 있었다.

(고치는 과정 사진이 없는게 조금 아쉽긴 하다.)

하지만 환경변수를 들여다보고, node를 삭제했다 다시 깔아보고, nvm을 깔아봐도 도무지 해결되지 않는 나의 리액트,,🥲

강사님께선 왠지 경로에 한글이 들어가 있어서 깨지는 걸수도 있다고 하셨다.

C드라이브\Users\여기에 들어가는 사용자명을 내가 윈도우 설치할 때 한글 내 별명으로 해버렸다.

과거의 노트북 구매 당시의 나 자신아.. 왠만하면 앞으로 사용자명은 영어로 하자..(멘토님께서 대문자 상관 없긴 하지만 혹시모를 오류 방지를 위해 소문자로 쓰자고 당부하셨다.)

그렇게 주말 강사님과 함께 지지고 볶던 시간이 지나고,, 울적한 마음에 사설 디스코드 방에서 신세한탄을 하고 있었다.

그렇게 시작된 멘토님의 도전! 😂

갑자기 원격제어로 한번 봐주시겠다면서 원격제어를 걸어 상태를 살펴봐 주셨다. (이 때도 캡쳐를 못해서 아쉽긴 하다.)

환경 변수를 다 지워도 보고, 관리자 권한도 줘보고, 버전도 계속 체크해보고, VS코드의 bash와 powershell에서도 해보고, 경로에 한글이 들어가지 않게 C드라이브 바로 밑에 폴더를 만들어서도 해보고,, 하여튼 할 수 있는건 다 해본것같다. 장장 2시간 동안...

진짜 너무너무 고생해주신 멘토님,,🥲날 봐주신다고 돈이 되는것도 아닌데 자신의 일처럼 열정적으로 나서주셔서 감사했습니다.

그래서 이 때부턴 백업준비에 들어갔었다. 월-금은 평일 주강사님이 봐주시고, 토요일은 주말 주강사님이 봐주시는데 내가 문제가 발생했던게 금요일 저녁이라 토요일 낮에 주말 주강사님이랑 뚝딱뚝딱하고, 토요일 저녁에 멘토님이랑 뚝딱뚝딱했는데도 되지 않아서 이 땐 마음을 어느정도 해탈하고 노트북에 있는 자료들을 열심히 클라우드로 옮겼다.

그러다 파트 1 때 같은 팀이었던 다른 수강생분이 "저도 리액트 설치과정에서 오류가 났었는데 평일 주강사님과 해결했어요, 한번 찾아가보시는게 어떨까요?" 라는 의견에 화요일에 조심스럽게 평일 강사님께 DM을 드렸다.

역시나 오류를 찾아가는 과정중에 나는 한가하게 캡쳐 같은걸 하고 있을 수가 없으니, 강사님께서 보내주신 명령어들만 남아있다.

자세한건 잘 모르겠지만 환경 변수에 설정되어 있는 경로들을 찾아가서 npm, nvm 폴더들도 깔끔히 삭제하고, 환경 변수에 지정 되어있던 %NVM_HOME%과 %NVM_SYMLINK%도 삭제하고,, 로컬 C 파일 탐색기에서 node와 nvm도 따로 검색해서 더 이상 뜨는게 없는지 점검하고, c드라이브 바로 아래에 있는 디렉토리에서 vs코드 열어 명령어 입력 뚝딱뚝딱 해줬더니 두둥..!

와아..!! 백업의 마음준비를 하고 마지막 끈으로 찾아갔던 평일 강사님이 해결해주셨다.😂😂😂

상황이 어찌 됐던건지 어리둥절한 나를 위해 강사님께서 말씀해주시기를

1. 환경변수가 꼬임
2. 삭제가 제대로 안됨
3. 경로에 한글이 있어서

-앞으로 파워쉘로 해야한다.
-C드라이브에서 어플리케이션 수행할 것 (미션도 C드라이브 밑에다가 할 것!)

이라고 하셨다. 와아아..! 포맷 안해도 된다!😂

진짜 너무너무 감사했고, 죄송스러웠던 강사님들과 멘토님... 인사는 계속 드렸지만 그래도 회고록을 빌어 한번 더 인사를 전하고 싶습니다. 당신의 일들도 아닌데 열심히 봐주고 해결해주려고 노력해주셔서 정말정말 감사드립니다.🙇‍♀️❤️

리액트 공부... 열심히 해야겠다.🥲👍

+추가 (25.01.01)

결국엔 포맷엔딩을 탔다.

참여 동기 및 과정 소개

프론트엔드는 아니고 웹 퍼블리셔 국비과정을 수료했던 경험이 있다. 디자인 위주의 수업이었고, 취업을 목표로 하는 학원 같지는 않아서 아쉬운 점도 있었다. (수강생 중에 60대 할아버지 두 분이 계셨는데, 수업 시간에 신문을 읽거나 딴짓을 해도 제지하는 게 없어서 살짝 당황스럽기도 했다.) 그래도 디자인과 코딩 수업을 통해 나는 디자인보다 코딩 수업을 더 좋아한다는 점과 프론트엔드 개발자라는 직업의 매력을 알게 되었다. 아무래도 눈으로 보이는 작업물을 다루다 보니 성과가 보여서 더 뿌듯하고 좋았고, 덕분에 부트캠프에 도전하는 계기가 되었다.

첫 시작

첫 시작 땐 팀원들과의 조우가 많이 긴장됐었다. 낯을 많이 가리는 편은 아니지만 새로운 시작은 긴장 될 수밖에 없는것 같다. 우리팀은 6명으로 구성되어 있었다. (다른 팀은 5명씩도 있었던 듯)

팀 활동

월요일부터 토요일까지 매일 팀 미팅을 진행했다. 첫 시간에 팀장 선정과 멘토링 일정 협의, 미팅 시간을 정하고 간단하게 자기소개를 했다. 

그리고 데일리 팀미션이라고, 팀미팅 시간 때 매일 돌아가며 배운 내용을 물어보는 활동과 더불어 한 명씩 돌아가며 배운 내용 중 주제를 정해 문제를 내면 팀원들이 구두로 대답하는 활동을 했는데 추후에 있을 취업 대비 면접을 준비하는 느낌으로 진행했다.

데일리 팀 미팅 6번 중 2번은 멘토링 활동도 같이 하는데, 현직 프론트엔드 개발자 멘토님과 함께하는 시간이었다. 팀원들과 협의해서 시간을 정하고 디스코드에서 만났는데 팀원들이 서로 잘 맞아서 팀 미팅 및 멘토링이 끝나고도 1시간 동안 잡담을 나눈 날도 있었다. (마지막 멘토링 때는 멘토링시간이 끝나고 난 뒤에도 헤어지기 아쉬워🥲 추가로 1시간동안 잡담을 나눴다.)

매주 토요일에는 위클리 페이퍼라는 활동도 했다. 코드잇에서 월요일에 새로운 주제를 디스코드에 공지해주면 그 주 토요일 전까지 해당 주제에 대해 생각을 정리해 팀원들과 토요일에 해당 주제에 대해서 이야기를 나누는 시간을 가졌다.

배운내용

파트1에서 HTML, CSS, Git, 유닉스 커맨드, 반응형 웹 퍼블리싱, 자바스크립트 중급, 인터렉티브 자바스크립트, 모던 자바스크립트, 비동기, 리퀘스트 등을 배웠다. (와, 이렇게 나열하니 정말 많다.)

그중에서 가장 기억에 남는 건 Git 수업이었다. 이전에 학원에서 잠깐 해본 기억이 있는데, 너무 어려워서 포기할까 고민도 했었던 애증의 Git. 하지만 Git은 필수라서 꼭 이해하고 싶었고, 수업에서 흥미를 갖고 공부하려고 노력했다.

느낀 점

강의는 온라인 강의 기반으로, 기초적인 이론 설명을 많이 다뤘는데, 조금 더 심화된 내용이라던지 이해를 위해 다른 내용을 추가로 알아야 하는 것은 직접 찾아보며 공부해야 했다. 그래서 초심자인 나에겐 조금 어렵게 느껴졌다. 어려울 땐 확실히 힘들긴 하다. "왜 이해를 이정도밖에 못할까?" 하고 자책스러운 마음도 있고, 다른사람들은 다 잘 나가고있는데 나만 이러는게 아닐까 하는 걱정도 들기도 했다. 하지만 나같은 비전공자에 초심자인 사람들도 분명 있었고, 그들과 얘기하면서 많이 위로를 얻었다. 이기적인것 같지만 나만 힘든게 아니라는 위로는 나를 괜찮게 많들기도 하는것 같다.

어렵긴 했지만 심화된 내용을 알아가기 위해 스스로 공부하는 방법도 깨닫기도 했고, 힘들 때는 토요일 보충 수업도 듣고(지금 껏 매 보충수업 올 출석인건 안비밀😅), 구글링으로 추가 학습도 하면서 계속 발전해 나가려고 노력했다.

우리 팀은 전공자도 꽤 있었는데 그들이 해주는 말들이 나에게 도움이 되기도 했다. 
유닉스 커맨드 파트를 정리하면서 듣느라 진도를 나가는게 좀 더디기도 했고, 어려워서 힘들어 했는데 '술술 머리에 스치듯이 정보를 입력하라'는 조언도 있었고, '그래도 중요한 부분이긴 하니 정리하면서 듣는게 나중에 훨씬 도움이 많이 될거다' 라는 의견도 들었다. 그런 얘기를 듣고나니 진도를 더디게 나가긴 했지만 머리에 조금이라도 남기려는 노력을 한 내가 조금 뿌듯해졌다.

그 외에도 팀원들이 추천하는 인프런 강의, 추천 교재(모던 자바 Deep Dive 등), 요약본 파일 공유(그저 빛✨) 등 말 뿐만 아니라 현실적인 도움도 많은 힘이 되었다.

앞으로의 계획

파트 2에 대한 기대와 걱정이 반반 섞여있다. 파트1 팀원들과 정말 잘 맞아서, 이렇게 좋은 팀원이 또 있을지 걱정이 되는것도 사실이다. (멘토님도 우리 팀처럼 반응이 좋고 참여도 잘하는 팀은 오랜만에 만난다고 하셨다.)  아직은 리액트를 본격적으로 배우기 직전이라 개인적인 계획은 리액트를 배우고 나서 방향성을 정해야 할 것 같다. 멘토님께서도 프론트엔드의 99%는 리액트가 필수라고 말씀하시기도 하셨으니.. 물론 자바스크립트는 계속 공부해야할것같다. 외우는게 어려우니 '눈과 손가락에라도 익도록 반복한다!' 라는 생각이다.

아, 그리고 스프린트 미션이라고 개인과제 제출 미션이 있다. 제출 기한에 제한은 없지만 주어진 디자인을 가지고 코딩해서 제출하는건데 멘토님께서 미션 5는 취업 과제로도 많이 나오는 문제라 꼭 해봤으면 좋겠다고 하셨으니 다음 파트 때는 스프린트 미션을 좀 더 열심히 수행해볼까 한다. (지금은 미션 1만 진행한 상황이다.)

파트1을 함께 해준 동료들에게..

던지는 말 한마디가 너무 웃겼던 갓생사는 ENFP님, 다정다감하고 상황정리를 잘하던 분위기 메이커 INFP님,  조용하지만 잘 어우러져서 천방지축팀을 묵묵히 이끌어줬던 팀장 ISFJ님, 뭔가 범상치 않은 드립과 전공자 + 막내다운 싱싱한 두뇌로 고견을 아낌 없이 나누던 INTJ님, 조금 늦게 합류했지만 잘 적응하고 금새 다른 팀원들을 따라잡던 똑똑이막내 ISTJ님, 그리고 파트1엔 알려줄 것이 많이 없다고 아쉬워 하며 멘토링 시간 늘 알차게 진행해주시던 꼼꼼+깔끔이(a.k.a 알잘딱깔센의 의인화) INTJ멘토님

어느 한명 모남 없이 모두가 둥글둥글하게 잘 어우러져서 더 기억에 많이 남고 아쉬움이 큰 것 같다. 얼굴만 봐도 반가워지는 내적 친밀감이 쌓일 때 쯔음 끝나는 느낌이라 섭섭하지만 다음 만남을 위해서, 그리고 언제든 대화를 나눌 수 있는 채널이 있으니까 섭섭함은 잠시 접어두도록 하겠다. 모두 취업까지 힘내서 열심히 나아갔으면 좋겠습니다.(물론 나도!) ♥팀 화이팅! (멘토님은 다음에 만나는 팀이 멘토님을 많이 힘들게 하지 않길 기원합니다.🙇‍♀️ 하지만 우리팀보단 좋아하지 말아줬으면.. 아냐 그래도 멘토님이 행복하셨으면.. 그래도 우리팀 최고였으면..♾️)

코딩하는데 4시간, 배포하는데 1시간 걸린 멍청이의 첫 배포 일지. 내가 보기 위해 내가 정리하는 내.보.내.정

git으로 배포하기 배우면서 알게된 점들을 주황글씨로 새겨볼까 한다.

먼저 레포지토리 포크를 해야한다.

포크한 레포지토리의 브랜치 목록에 내 이름이 있는지 확인을 꼭 한 후 진행해야한다.

확인이 끝났으면 포크한 레포지토리에서 저장소 URL을 복사 후 브랜치 클론 작업을 해줘야한다.

clone : 온라인에 있는걸 통째로 내 컴퓨터로 가져온다. 저장소 url을 clone할 때 적는 이유 : 구체적으로 어떤 코드를 가져오는지 알기 위해서 URL을 적어 명명하는 것이다.

$ git clone -b Basic-본인이름 --single-branch {저장소 URL}

$ git clone -b Basic-이코딩 --single-branch https://github.com/12124334@!#@$#@!

그 다음 clone해 온 폴더를 열어줘야 한다.

이게 무슨 말이냐면, 예를 들어 바탕화면에 폴더(디렉토리)를 만들고서 그 안에서 클론을 하면 폴더 안에 폴더가 생긴다. 안에 생긴 폴더에서 작업을 해주면 된다.

//예시
$ git checkout -b Basic-본인이름-sprint1

git checkout -b 새로운 브랜치로 만들면서 이동하기

+ 만약 다른 브랜치로 설정 되어 있으면 git checkout 명령어로 브랜치 이동해주기!

$ git checkout 이동할 브랜치명

이렇게 만든 브랜치 내에서 미션을 진행하면 된다!

그런 다음 내가 한 작업물 보내기 위한 작업을 진행한다.

$ git add .
$ git commit -m "메시지"
$ git push origin <브랜치명>

//예시
$ git push origin Basic-본인이름-sprint1

add 지정 / commit 저장 / origin 내 레포지토리 주소

여기까지 됐다면 Pull Request를 할 수 있다. pull request = 검토받기 위한 작업, 만약에 내가 신입개발자로 뽑혀서 들어가 중요 프로젝트에 투입됐는데 내가 만든 브랜치를 바로 머지 할 수 있는가? 아마 사수나 상사가 무조건 확인 후에 올릴것이다. 그래서 PR을 하는것이라고 생각하면 된다.

PR제목은 [본인이름] sprintN로 꼭 통일하기! (ex. 미션 2번하는 홍길동이라면 => [홍길동] sprint2)

미션 1부터
-base repository: 코드잇 레파지토리/기수-Sprint-Mission / base: Basic-본인이름 (🚨반드시 main 브랜치가 아닌, Basic-본인이름 브랜치로 설정)
-head repository: 내 레파지토리/기수-Sprint-Mission / compare: Basic-본인이름-sprintN

미션 5부터
-base repository: 코드잇 레파지토리/기수-Sprint-Mission / base: React-본인이름 (🚨반드시 main 브랜치가 아닌, React-본인이름 브랜치로 설정)
-head repository: 내 레파지토리/기수-Sprint-Mission / compare: React-본인이름-sprintN

미션 9부터
-base repository: 코드잇 레파지토리/기수-Sprint-Mission / base: Next-본인이름(🚨 반드시 main 브랜치가 아닌, Next-본인이름 브랜치로 설정)
-head repository: 내 레파지토리/기수-Sprint-Mission / compare: Next-본인이름-sprintN

제목을 생성하면 PR 템플릿을 작성하도록 나온다.

## 요구사항

### 기본

- [x]
- []
- []

### 심화

- [x]
- []

## 주요 변경사항

-
-

## 스크린샷

![image](이미지url)

## 주강사님에게

-
-
- 셀프 코드 리뷰를 통해 질문 이어가겠습니다.

💡 PR 템플릿을 활용하실  때 주의할 것
-PR 템플릿은 마크다운 문법을 준수해서 작성하기
-체크리스트를 만들고 싶다면 [ ], 체크를 하고싶다면 [x]와 같이 작성해 주기
-스프린트 미션이 안내된 레슨의 셀프 채점 부분에 있는 체크리스트를 PR에도 반영하기
-PR에서 큰 변경사항이 있을 때에는 '주요 변경사항'에 기록하기(e.g. 랜딩 페이지 추가, 로그인/회원가입 페이지 반응형 디자인 적용 등)
-주강사님이 작업한 내용을 빠르게 이해할 수 있도록 png, jpg, gif 등의 이미지를 '스크린샷'에 첨부하기. 참고로, 이미지 첨부를 위한 마크다운 문법은 
-코드의 특정 영역에 대해 질문이 있을 때는 PR에 코멘트를 작성하는 방식으로 진행하기

나는 이때 [기본]에다가 netlify로 배포한 사이트 주소를 넣었다. (나중에 강사님이 맞게 잘 하셨다면서 확인해주심.)

본문을 다 작성했다면 평일 강사님을 Reviewers에 추가해주고 (k로 시작하심) Label로 원하는 피드백 스타일을 표시한다.

이렇게 까지 했다면 아직 끝난게 아니라 미션 설문을 제출 + 디스코드에서 강사님께 미션완료 코드리뷰 요청을 드려야한다.

+이후 강사님께서 제출된 PR의 내용을 확인 후 리뷰를 남기고 머지(Merge)해 주신다.

+PR은 강사님 리뷰 후에 머지 되기 때문에 리뷰에 대한 개선작업은 그 다음 스프린트 미션에 반영해주면 된다.

그 다음 프로젝트 진행하기

본인 프로젝트 열고, Basic-본인이름-sprint 브랜치에서 Basic-본인이름 브랜치로 이동을 해준다.

$ git checkout Basic-본인이름

그 다음 github 레포지토리의 Basic-본인이름 브랜치에서 변경된 코드를 가져온다.

//github 레포지토리를 upstream 이라는 이름으로 연결한다.
//git remote add로 연결한 후에는 추후에 다시 연결하지 않아도 된다.
$ git remote add upstream 저장소-url

//github 레포지토리의 Basic-본인이름 브랜치에서 변경된 사항을 내 Basic-본인이름 브랜치로 가져온다.
$ git pull upstream Basic-본인이름

여기서 $ git remote add upstream 저장소-url 은 

이 때 봤던 Basic-내 이름 말고 main 에서의 주소이다. 왜냐! 위에서 clone해 올 때는 basic-내이름 에서 주소를 가져왔다. $ git push origin Basic-본인이름-sprint1 에서 origin은 내 레포지토리의 주소이다. 그럼 가져올 저장소의 위치도 알려줘야 한다. 그래서 내가 가져오려는 github 레포지토리를 upstream이라는 이름으로 연결해주는 것이다. (매번 주소 다 치기 번거로우니까!)

그리고 다음 미션을 위한 새 브랜치를 생성한다.

$ git checkout -b Basic-본인이름-sprint2

Basic-본인이름-sprint2 브랜치에서 미션을 완수한다.

$ git add .
$ git commit -m "메시지"
$ git push origin <브랜치명>

//예시
$ git push origin Basic-본인이름-sprint2