서재(書齋)

React 교육 수강 중에 만든 간단한 React App을 배포해보고자 한다.

사실 나중을 생각하면 GitHub Pages에 배포하는 것이 아니라 실제 어플리케이션 서버에 배포하는 것을 작성해야 하나, 과정 중에 배울 만한 점들이 있어 별도로 기록해 둔다.

gh-pages 패키지 설치

GitHub 계정은 이미 생성하여 보유하고 있다고 가정한다.

프로젝트 폴더 내에서 아래와 같이 npm install 명령어를 통해 GitHub Pages에 배포하는 것을 도와줄 gh-pages 패키지를 설치한다.

npm install gh-pages

package.json 수정

package.json 파일에 두가지 정도를 수정해야 한다.

하나는 deploy와 관련된 script를 추가하는 것이고, 다른 하나는 해당 App이 배포될 Homepage를 명시해주는 것이다.

1.  Script 수정

파일 내 scripts 부분에 아래와 같이 predeploy와 deploy를 추가한다.

  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "eject": "react-scripts eject",
    "predeploy": "npm run build",
    "deploy": "gh-pages -d build"
  },

이렇게 하면, 배포를 위해 npm run deploy 명령어 수행 시 Node.js에서 자동으로 predeploy 명령어를 실행 후 deploy를 수행하게 된다.

1. 'npm run deploy' 입력 -> predeploy가 있으므로 predeploy 명령어인 'npm run build' 수행
2. npm run build 명령어인 'react-scripts build'를 통해 build 폴더에 배포 파일 생성
3. 실제 npm run deploy 명령어인 'gh-pages -d build' 명령어를 통해 GitHub Pages에 build 폴더의 파일 배포

GitHub Pages 사용 설정

우선 GitHub의 호스팅 기능을 사용하기 위해서는 해당 Repository가 Public으로 공개되어 있어야 한다.

만약 공개되어 있지 않다면 Settings > General의 맨 하단에서 공개 여부를 설정할 수 있으므로 참고하자.

내가 배포하고자 하는 Repo.의 Settings > Pages 메뉴로 들어가면 아래와 같은 메뉴를 볼 수 있다.

첫번째 빨간 네모는 해당 Repository의 GitHub Pages 주소를 나타내며, 두번째 빨간 네모는 그래서 내 App Source가 어디 있냐? 나는 Deploy from a branch를 선택했으므로 그러면 어느 브랜치에 있냐? 를 묻는 부분이 되겠다.

gh-pages 패키지를 사용하면 자동으로 gh-pages 브랜치를 생성하고 해당 브랜치에 파일을 배포하므로 gh-pages & root를 선택해 주면 되겠다.

배포 실행

Visual Studio 등 작업하던 툴의 Terminal에서 이 전 단계에서 사전 셋팅한 npm run deploy 명령어를 실행한다.

그러면 자동으로 배포용 파일을 생성하고, 내 레파지토리의 gh-pages 브랜치에 파일들을 배포해 주게 된다.

약 10분 정도의 대기시간이 필요했던 것 같다.

조금의 대기 후에 아까 보았던 Pages 화면의 빨간색 네모 표시해 두었던 github.io 주소로 들어가 보면 페이지가 정상적으로 표시되는 것을 볼 수 있다.

추가) Firebase Authentication 도메인 승인

해당 앱은 Firebase 기반으로 만들었으므로 Firebase Authentication 기능을 이용해 가입 및 로그인을 진행하는데, 배포한 깃헙 도메인이 승인되어 있지 않아 처음에는 로그인이 되지 않는 현상이 발생한다.

Firebase > Authentication > Settings > 도메인 > 승인된 도메인 메뉴에서 '도메인 추가' 버튼을 클릭하여 계정명.github.io 도메인을 추가해 주자.

이상으로 간단하게 GitHub Pages를 활용하여 배포하는 과정을 알아보았다.

끝.

간단한 앱이나, 구현하고자 하는 서비스의 프로토타입을 빠르고 간편하게 만들기 위해서 Google Firebase를 많이 사용하는 것 같다.

Firebase 내에는 많은 부가 서비스와 기능들이 제공되지만, 그 중 Google의 규모를 활용한 강력하고 단순하며 경제적인 객체 저장소 서비스인 Firebase용 Cloud Storage 서비스를 활용해 사진 파일을 업로드 할 수 있는 기능을 구현하고자 했다.

그러나 아직 익숙치 않아서인지 파일 업로드와 관련된 부분을 구현하는 중에 발생한 오류(Uncaught (in promise) FirebaseError: Firebase Storage: User does not have permission to access '...'. (storage/unauthorized))를 수정하는 데 시간을 조금 허비하여 관련 내용을 기록해 둔다.

아래는 파일 업로드 시 실행되는, 내가 구현한 onSubmit 함수의 일부분이다.

        event.preventDefault(); 
        const fileRef = fbStorage.ref().child(`${userObj.uid}/${uuidv4()}`);
        console.log(fileRef);
        const response = await fileRef.putString(fileState, "data_url");
        console.log(response);

첫번째 시도 결과, fileRef(ReferenceCompat)는 콘솔에 정상적으로 출력되나 response는 정상적으로 출력되지 않고 bucket의 특정 경로에 접근할 permission이 없다는 경고가 표시된다.

약간의 구글링 끝에, Firebase Storage 내 'Rules' 메뉴에서 읽기/쓰기 시 적용될 각종 Rule을 편집할 수 있다는 것을 알게 되었다.

해당 메뉴에서는 읽기/쓰기와 관련된 권한 체크, 쓰기 시 각종 Validation Rule 추가 등 유용한 기능등을 전용 문법으로 작성할 수 있는 기능을 제공하고 있었다.

위 캡쳐를 보면 알 수 있듯이, read와 write 모두 if false로 아무도 읽고 쓰지 못하게 초기 설정이 되어 있었다.

해당 부분을 아래와 같이 Firebase의 Auth를 통해 로그인하고 권한을 부여받았다면 읽기/쓰기가 가능하도록 수정해 주었다.

이후 재시도하면 아래와 같이 업로드 관련 로직 수정 후 Console.log가 정상적으로 출력됨을 볼 수 있다.

Firebase Storage 콘솔 내에서 'Files' 탭을 확인해 보면, 파일이 정상적으로 생성된 모습을 볼 수 있다.

끝.

GitHub에서 소스를 관리하다 보면, 내 개인 프로젝트임에도 불구하고 Public으로 공개되어야 얻을 수 있는 각종 지원 기능들로 인해 Public Repository로 생성하게 되는 경우가 발생한다.

이 때, 소스상에 연동에 필요한 각종 Key들이 그대로 들어가 있고 해당 소스들이 모두 공개 리파지토리에 올라가는 것이 싫다면 환경 변수에 각종 Key들을 생성하여 한 단계 숨기고, 해당 Key가 포함된 env 파일은 git에 업로드 되지 않도록 하는 방법을 적용할 수 있다.

단, 결과적으로 배포 시 App을 Build하면 어차피 해당 Key들은 환경변수 값을 참조하여 컴파일을 하게 된다.

보안 측면에서 영영 숨기는 방법은 아니라는 것이다. 단순히 GitHub에 소스 레벨로 이러한 키들이 공개되는 것을 원치 않는 경우에는 해당 방법을 적용하면 된다.

(Nomad Coder - 트위터 클론코딩 강좌 수강 중 내용을 참고하였습니다.)

.env 파일 생성 & 환경변수 등록

우선 프로젝트 폴더 아래에 .env 파일이 없다면 해당 파일을 생성한다.

그 후, 각종 환경변수를 생성하고 기존에 있던 key를 해당 변수값으로 할당해 준다.

이 때, React App의 경우에는 환경변수가 반드시 REACT_APP으로 시작해야 한다는 점을 명심하자.

아래는 Firebase 개발 시 등록한 환경변수의 예제이다.

기존 소스 수정

기존 소스에서 Key가 그대로 입력된 부분들은 모두 아래와 같이 환경변수로 대체한다.

GitHub에는 해당 파일은 업로드가 될 것이지만, 다른 사용자들은 환경변수명만 알 수 있게 된다.

.gitignore 파일 수정

하지만 이렇게 숨겨놓은 env 파일이 git에 업로드된다면 말짱 꽝이므로, 해당 파일이 Repository에 업로드되지 않도록 설정해 주어야 한다.

아래와 같이 .env 파일을 .gitignore 파일 내에 등록해 주면, 해당 파일은 GitHub으로 업로드되지 않게 된다.

확인을 해 보면, 아래와 같이 gitignore 파일에 env를 등록하기 전에는 env 파일도 Changes로 감지하나(좌), gitignore 파일에 .env를 등록한 후 저장하면 Changes 목록에 .env 파일이 사라진 것을 볼 수 있다.

(230211 추가)

해당 방법으로 관리하는 경우, 치명적인 오류가 하나 발생한다.

아마 로컬 환경에서 빌드 시 순서에 따른 문제인 것 같은데, apiKey나 authDomain 같은 환경변수 값들이 필요한 경우 해당 값들을 제대로 참조하지 못하는 경우가 발생한다.

(Ex. API Key가 비정상적이라거나, Firebase Auth 사용 시 Domain을 등록하고 사용하라거나 등의 오류 발생)

실제 배포시에는 해당 문제가 발생하지 않는다 하더라도, 개발 과정에서 위와 같은 불편함을 감수하기는 힘드므로 그냥 key를 업로드해야 할 수밖에 없을수도....

끝.