간단한 앱이나, 구현하고자 하는 서비스의 프로토타입을 빠르고 간편하게 만들기 위해서 Google Firebase를 많이 사용하는 것 같다.
Firebase 내에는 많은 부가 서비스와 기능들이 제공되지만, 그 중 Google의 규모를 활용한 강력하고 단순하며 경제적인 객체 저장소 서비스인 Firebase용 Cloud Storage 서비스를 활용해 사진 파일을 업로드 할 수 있는 기능을 구현하고자 했다.
그러나 아직 익숙치 않아서인지 파일 업로드와 관련된 부분을 구현하는 중에 발생한 오류(Uncaught (in promise) FirebaseError: Firebase Storage: User does not have permission to access '...'. (storage/unauthorized))를 수정하는 데 시간을 조금 허비하여 관련 내용을 기록해 둔다.
GitHub에서 소스를 관리하다 보면, 내 개인 프로젝트임에도 불구하고 Public으로 공개되어야 얻을 수 있는 각종 지원 기능들로 인해 Public Repository로 생성하게 되는 경우가 발생한다.
이 때, 소스상에 연동에 필요한 각종 Key들이 그대로 들어가 있고 해당 소스들이 모두 공개 리파지토리에 올라가는 것이 싫다면 환경 변수에 각종 Key들을 생성하여 한 단계 숨기고, 해당 Key가 포함된 env 파일은 git에 업로드 되지 않도록 하는 방법을 적용할 수 있다.
단, 결과적으로 배포 시 App을 Build하면 어차피 해당 Key들은 환경변수 값을 참조하여 컴파일을 하게 된다.
보안 측면에서 영영 숨기는 방법은 아니라는 것이다. 단순히 GitHub에 소스 레벨로 이러한 키들이 공개되는 것을 원치 않는 경우에는 해당 방법을 적용하면 된다.
(Nomad Coder - 트위터 클론코딩 강좌 수강 중 내용을 참고하였습니다.)
.env 파일 생성 & 환경변수 등록
우선 프로젝트 폴더 아래에 .env 파일이 없다면 해당 파일을 생성한다.
그 후, 각종 환경변수를 생성하고 기존에 있던 key를 해당 변수값으로 할당해 준다.
이 때, React App의 경우에는 환경변수가 반드시 REACT_APP으로 시작해야 한다는 점을 명심하자.
아래는 Firebase 개발 시 등록한 환경변수의 예제이다.
.env 파일에 환경변수를 생성한 모습
기존 소스 수정
기존 소스에서 Key가 그대로 입력된 부분들은 모두 아래와 같이 환경변수로 대체한다.
GitHub에는 해당 파일은 업로드가 될 것이지만, 다른 사용자들은 환경변수명만 알 수 있게 된다.
기존의 Key가 입력되어 있던 부분을 환경변수로 변경한 모습
.gitignore 파일 수정
하지만 이렇게 숨겨놓은 env 파일이 git에 업로드된다면 말짱 꽝이므로, 해당 파일이 Repository에 업로드되지 않도록 설정해 주어야 한다.
아래와 같이 .env 파일을 .gitignore 파일 내에 등록해 주면, 해당 파일은 GitHub으로 업로드되지 않게 된다.
.gitignore 수정
확인을 해 보면, 아래와 같이 gitignore 파일에 env를 등록하기 전에는 env 파일도 Changes로 감지하나(좌), gitignore 파일에 .env를 등록한 후 저장하면 Changes 목록에 .env 파일이 사라진 것을 볼 수 있다.
gitignore 파일 수정 전/후 비교
(230211 추가)
해당 방법으로 관리하는 경우, 치명적인 오류가 하나 발생한다.
아마 로컬 환경에서 빌드 시 순서에 따른 문제인 것 같은데, apiKey나 authDomain 같은 환경변수 값들이 필요한 경우 해당 값들을 제대로 참조하지 못하는 경우가 발생한다.
(Ex. API Key가 비정상적이라거나, Firebase Auth 사용 시 Domain을 등록하고 사용하라거나 등의 오류 발생)
실제 배포시에는 해당 문제가 발생하지 않는다 하더라도, 개발 과정에서 위와 같은 불편함을 감수하기는 힘드므로 그냥 key를 업로드해야 할 수밖에 없을수도....
어떻게 보면 가장 문외한이라 할 수 있는 FE 영역을 공부하려 하는데, 자꾸만 프레임웤(이 아니라 사실 React는 라이브러리라고 하지만 혼용된 의미로 사용되는 것 같다. 일단은 사전 제공되는 규모의 차이니 둘 다 프레임워크라 하기로...) 선택에 시간이 소요되고 있다.
많은 영상을 참고해 보면 둘 다 배우라는 이야기가 많지만, 나는 BE 뿐 아니라 DB도 신경써야 하고 서비스 자체를 기획해야 하는 입장에서 컨텐츠/디자인 영역에 소요될 시간이 더 많을 것 같아서 둘 중 하나를 선택해서 배워야 하는 입장이다.
혼자 끙끙 앓으며 고민하기보다는 두 기술에 대해 잘 설명되어 있는 유튜브 영상을 참고하여 프론트에 대한 이해도 할 겸, 선택에 대한 근거를 좀 쌓아두려고 한다.
React가 사용하는 단방향 데이터 바인딩의 경우, 아래 그림과 같이 로직이 존재하는 Model에서 화면을 로딩하는 시점에 View 영역으로 데이터를 제공하고 이를 이용하여 초기값 등을 셋팅한다.
이후 사용자가 View 영역에서 값을 수정하면, onClick 등의 이벤트 함수를 생성하여 이를 다시 Model로 보내준 뒤 각종 로직을 처리하고 DB에 저장 등을 수행하게 된다.
(MVC(Model - View - Controller) 패턴)
단방향 데이터 바인딩
Vue가 사용하는(단방향 또한 지원한다) 양방향 데이터 바인딩의 경우, ViewModel 이라는 컴포넌트가 존재하여 View와 Model 컴포넌트의 데이터 변화를 감지하다가, 어느 한 쪽에서 값의 변화가 일어나는 경우 자동으로 다른 컴포넌트에 변화된 값을 동기화해 준다.
(MVVM(Model - View - ViewModel) 패턴)
양방향 데이터 바인딩
자유도
자유도의 경우 React가 조금 더 높다고 한다.
타 플러그인 의존도
Vue보다는 React가 타 플러그인 의존도가 높으며, React는 많은 라이브러리를 import 하므로 빌드 시 생성되는 파일의 수도 상대적으로 많다.
Document
공식적으로 제공되는 도큐먼트의 경우 Vue가 조금 더 이해하기 쉽다.
Learning Curve
배우기에는 Vue가 React보다는 조금 더 쉽다고 한다.
성능
성능의 경우 둘 다 준수한 성능을 나타내나, 상대적으로 Vue가 조금 더 우수하다.
각종 프레임워크의 성능을 비교해 놓은 GitHub 링크가 있어 이를 참고하여 설명해 주셨다.
sudo apt update # apt로 설치 가능한 패키지 리스트를 업데이트
sudo apt upgrade # apt로 설치한 패키지들을 업그레이드
설치한 적 없으나 혹시 몰라 Java 버전을 확인해 보니, 당연히 설치된 버전이 없다고 표시가 되지만 거기에 그치지 않고 자동으로 설치 가능한 버전과 설치 명령어를 제시해 준다. 아주 똑똑하다.
Java 버전 확인 결과 설치되어 있지 않으면, 자동으로 설치 가능한 버전과 명령어를 제시한다. 똑똑하다
나는 Tomcat 10 버전을 사용하기로 했으므로, 11 버전의 jdk를 설치하였다.
sudo apt install openjdk-11-jre-headless
설치 후 버전 확인을 다시 한번 진행하면, 아래와 같이 openjdk 버전이 정상 표시되는 것을 볼 수 있다.
ubuntu@ip-(my-ip):~$ java --version
openjdk 11.0.17 2022-10-18 # 정상 설치된 jdk 버전
OpenJDK Runtime Environment (build 11.0.17+8-post-Ubuntu-1ubuntu222.04)
OpenJDK 64-Bit Server VM (build 11.0.17+8-post-Ubuntu-1ubuntu222.04, mixed mode, sharing)
Tomcat 설치
다음으로는 Tomcat 설치를 진행한다.
우선 home 디렉토리 아래에 tomcat 폴더를 생성한다.
sudo mkdir /home/tomcat
다음으로는 tomcat 폴더 안에 tomcat 설치 파일을 다운받는다.
다운로드를 위해서는 설치 경로를 알아야 하는데, 설치 경로는 공식 다운로드 페이지 내에서 Download > Tomcat XX(다운받을 버전) 메뉴로 진입한 뒤 아래와 같이 tar.gz 파일의 URL을 복사하여 사용한다.
tar.gz 파일의 다운로드 URL 복사
cd /home/tomcat # 디렉토리 이동
sudo wget https://dlcdn.apache.org/tomcat/tomcat-10/v10.0.27/bin/apache-tomcat-10.0.27.tar.gz(복사한 URL) # tomcat 10버전 다운로드
이후 다운받은 파일을 tar 명령어를 이용하여 압축 해제한다.
사용되는 옵션의 상세 내용은 아래를 참고한다.
-v : 묶거나 파일을 풀 때 과정을 출력 -f : 파일 이름을 지정 -x : tar 압축 풀기 -z : gzip으로 압축하거나 해제
sudo tar xvfx apache-tomcat-10.0.27.tar.gz # 다운받은 파일 압축 해제
# 압축 해제된 이후 폴더 정상 생성 확인
sudo rm apache-tomcat-10.0.27.tar.gz # 원본 압축파일 삭제
압축을 해제하는 것만으로 Tomcat 설치는 완료된다.
이후 tomcat 정상 구동을 확인하기 위해 bin 폴더에 있는 startup.sh을 실행하였다.
sudo chmod -R 777 /home/tomcat/apache-tomcat-10.0.27/bin #tomcat bin 폴더의 권한을 전체 권한으로 변경
cd bin # /home/tomcat/apache-tomcat-10.0.27 폴더 내에서 bin 폴더로 한 단계 더 진입
./startup.sh # startup.sh 실행
그랬더니 아래와 같이 catalina.out 파일에 권한이 없어 로깅을 못 한다는 오류가 표시되며 구동이 되지 않는다.
구동이 되지 않는다. 권한..... 휴
나는 정상 설치가 되었는지, 현재 별다른 환경 변수 설정 없이 tomcat이 구동 가능한 상태인지를 확인하고자 하는 것이기 때문에, sudo로 계정을 변경하여 진행하기로 했다.
다만 Installer에 두 가지 타입이 있는데, 특정 User만을 위한 User Installer가 있고, 해당 Windows의 모든 사용자를 위한 System Installer가 있다.
공용 PC 등을 사용해서 특정 사용자만 사용해야 하는 경우가 아니고, 개인 PC를 사용하는 경우라면 일반적으로 System Installer를 설치해서 사용한다고 하니 참고하자.
User / System Installer를 목적에 맞게 선택하자.
Git 설치
설치가 완료된 후 VSCode를 구동시켜 보면, 생산성을 향상시키기 위한 방법 중 하나로 Git을 설치할 것을 권유하고 있다.
Install Git 버튼을 눌러 사이트에 들어간 후, 다운로드 파일을 찾아 다운받는다.
2023년 1월 21일 현재 최신 버전은 2.39.1 버전이다.
설치 후 VSCode에서 Install Git을 제안한다.
Git 사이트에서 다운로드 링크로 진입하여 64bit Standalone Installer를 다운받는다.
이후 대부분을 기본 설정으로 넘어간 뒤, 기본 에디터를 선택하는 부분에서 우리는 VSCode와 Git을 연동할 것이므로 'Use Visual Studio Code as Git's Default Editor' 옵션으로 변경한 후 넘어가자.
'Use Visual Studio Code as Git's Default Editor' 옵션으로 변경
이후에는 저장소의 메인 브랜치 이름을 Git 기본값인 master로 할 것인지, main등으로 변경할 것인지를 비롯한 각종 셋팅들이 나오나 구동에 큰 영향을 주지 않는 옵션들로 대부분 기본값을 선택했다.
아, 마지막 즈음에 PATH environment와 관련된 설정을 하는 부분이 있다.
Git을 Command Line에서 사용할 때 Git Bash만을 사용할 것인지(1번), 또는 윈도우 PowerShell을 비롯한 각종 써드 파티 소프트웨어들을 사용해서 Git을 사용할 것인지(2번) 등을 묻는 부분인데, 대부분 윈도우 사용자들은 2번을 선택할 것을 추천하고 있으므로 기본 선택값인 두번째 옵션을 선택하여 설치한다.
다시 한번 찬찬히 읽어 보니, 환경변수의 PATH 값을 전혀 수정하지 않고 Git Bash만을 사용하려면 1번, VSCode와 같은 써드 파티 툴들을 이용해서 Git을 이용하려면 PATH에 일부 Git Wrapper와 관련된 환경변수 값이 추가되는 2번을 선택하면 되는 듯하다.
일반적인 사용자들은 두번째 옵션을 선택하자
설치가 완료되면, 윈도우 메뉴에서도 Git을 확인할 수 있으며 일반적인 cmd 창에서도 'git --version' 명령어로 Git의 설치 여부와 설치된 버전을 확인할 수 있다.
Git 설치 여부 및 버전 확인
GitHub 연동
설치가 완료된 후 VSCode로 돌아와 좌측의 세번째 아이콘(Source Control)을 클릭하면, 아직 아래와 같이 설치된 Git을 인식하지 못하는 것을 볼 수 있다.
reload를 클릭해 VSCode를 다시 로딩해 주자.
reload 클릭
그러면 아래와 같이 Git이 인식된다.
설치된 Git이 인식된다
이제 'Oepn Folder'를 클릭해 기존에 내가 로컬에서 작업하고 있던 폴더를 선택하여 불러올 수도, 'Clone Repository'를 클릭하여 GitHub에 이미 등록되어 있는 리파지토리를 복제해서 가져올 수도 있다.
자세한 GitHub 연동 및 소스 관리 방법은 나중에 추가로 작성하도록 하고, 우선 설치 방법까지의 가이드는 이것으로 마친다.
