서재(書齋)

서비스의 해상도를 결정하는 일은 중요하다고 생각한다.

고객 경험이 좋지 않은 서비스는 아무리 컨텐츠가 뛰어나도 성공할 확률이 낮아진다.

소규모 개발자의 컨텐츠는 더더욱 사용자가 접하는 서비스의 첫 인상과 초기 몇 분 동안의 경험이 고객 확보와 이탈의 기로 사이에서 굉장히 중요한 역할을 한다고 생각하기에, 디자인과 고객 경험은 특히나 더 신중해야 할 부분이다.

UI Framework 선정

UI 프레임워크(라고 해야할지 Kit이라고 해야할지)를 우선 선정한다.

리서치를 통해 비교군은 아래와 같이 잡아보았다.

• Tailwind CSS
  - 단순 CSS 라이브러리
• MUI(Material UI)
  - Material Design(Made by Google)의 React 버전
  - 안드로이드 스타일의 디자인이 쉽고 간편하다
  - 무겁고 커스터마이징이 어렵다
• bootstrap
  - Made by Twitter
  - 트위터 스타일의 디자인이 쉽고 간편하다
• Ant Design
  - Made by Alibaba
  - 가볍다
  - 중국…

나는 Android 사용자이기도 하고, 개인적으로 애플의 폐쇄성이 싫고 구글 스타일의 UI가 나쁘지 않다고 생각하는 사람이다.

또한 내 서비스는 개인 프로젝트에 가까워 무겁다는 것은 단점이 되지 않는다.

커스터마이징 할 시간에 서비스를 구현해야 하기 때문에 커스터마이징도 크게 고려하지 않기로 했다.

따라서 답정너인것 같기는 하지만 MUI(Material UI)를 사용하여 UI를 만들기로 했다.

표준 해상도 결정

운이 좋게도 서비스 및 화면 기획 경험이 있다 보니, 표준 해상도라는 것이 서비스 구현에 있어 얼마나 중요하며 기준을 제대로 잡고 디자인하는 것이 사용자 경험에 얼마나 큰 요소인지를 체감할 수 있었다.

나는 모바일 웹 게임에 가까운 서비스를 만들려고 하고 있으므로, PC 환경에 대한 대응은 크게 신경쓰지 않을 예정이다.

따라서 스탯 카운터(https://gs.statcounter.com/) 사이트를 참고하여 현재 모바일 기기별 해상도 점유율을 살펴보고, 이에 따라 표준 해상도를 결정하기로 했다.

아래는 해당 사이트에서 살펴본 대한민국의 최근 1년(23. 03. 26. 기준)간 모바일 해상도 점유율이다.

1위는 10.25%의 390x844, 2위는 9.47%의 412x915 해상도임을 알 수 있다.

검색을 해 보니, 390x844 해상도는 iPhone 13 Pro & iPhone 14의 해상도로, 412x915 해상도는 Galaxy S20 Ultra 기종의 해상도다.

처음에는 Worldwide로 필터를 설정하여 검색했으나, 아직까지 예전 안드로이드 핸드폰을 사용중인 전 세계인들의 영향인지 아래와 같이 예전 안드로이드 표준 해상도인 360x800의 점유율이 압도적인 1위로 나타난다.

갤럭시 S21 이하 휴대폰의 해상도가 360x800, 또는 360x760이 많으므로 완전 구형 핸드폰이라고는 할 수 없지만, 나는 K-서비스를 만들 예정이므로 전 세계인의 기준이 아닌 내수 기준을 따르고 이 기준을 전 세계로 확산시키겠다.

결론은, 한국 기준으로 안드로이드 점유율 1위 해상도인 412x915를 기준으로 서비스를 개발하기로 했다.

디자인 툴은 Adobe XD를 사용할 예정이다.

끝.

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를 업로드해야 할 수밖에 없을수도....

끝.

이 전 글들에서는 Visual Studio Code에 Git을 설치하고, GitHub에 존재하는 Repository를 불러와서 내 로컬에서 작업하고 이를 다시 GitHub Repository로 Push하는 방법을 알아보았다.

이번에는 반대로 흔히 실습을 하다 보면 각종 프레임워크/라이브러리 등을 로컬에 설치하고 이를 이용해 로컬에 파일을 우선 만들게 되는데, 이렇게 만들어진 로컬 파일을 GitHub 내 Branch를 신규 생성하고 형상관리하는 방법에 대해서 알아보고자 한다.

신규 Repository 및 Branch 생성

기존에 GitHub 계정과 연동을 한 상태라면, VSCode 내에서 Source Control 메뉴에 진입했을 때 아래와 같이 'Publish Branch' 버튼이 보이게 된다.

이를 클릭하면 상단에 Private Repository를 생성할지, Public Repository를 생성할지 선택하는 부분이 표시된다.

목적에 맞는 것을 선택하자.

그러면 아래와 같이 VSCode 우측 하단 창에 생성 상태바가 표시된 후 성공적으로 publising까지 완료되었다는 메시지를 볼 수 있다.

Open on GitHub 버튼을 클릭하여 사이트로 들어가 보면, 아래와 같이 새로운 Repository가 자동으로 생성되어 master branch에 정상적으로 소스가 업로드되어 있음을 확인할 수 있다.

공부하면서 많이 느끼는 부분인데, 정말 새삼 모든 것이 한층 더 좋아지고 편리해졌다는 생각이 든다.

한창 Google Cloud Summit등에 참석해서 열의를 가지고 이런저런 것들을 학습했을 때보다 더 많은 것들이 진보했다는 느낌이다. 그게 이 IT 업계라서 더더욱 빠르게 느껴지고.

내 업무 환경이 레거시 SI라서, 회사가 온프레미스에 폐쇄망만 고집해서 등의 이유로 이런 신기술들을 활용하지 못한다면 더더욱, 개인적으로라도 끊임없이 학습하고 본인의 생산성을 향상시키기 위해 노력해야만 시간이라는 귀중한 자원을 가장 효율적으로 쓸 수 있지 않을까 싶다.

비록 여러가지 이유로 업무에 적용할 수 없는 상황일지라도 '나'는 항상 갖춰져 있어야 한다는 생각이다. 그게 기술적인 부분이건 업무에 임하는 자세건 내가 갖춰져 있어야만 기회가 왔을 때 잡을 수 있다.

그렇지 않으면 본인 머릿속에 있는 시스템이나 서비스의 히스토리로만 먹고 사는, 그저 그런 관리자나 개발자가 되어 밀려나고 도태될 뿐이다.

끝.

어떻게 보면 가장 문외한이라 할 수 있는 FE 영역을 공부하려 하는데, 자꾸만 프레임웤(이 아니라 사실 React는 라이브러리라고 하지만 혼용된 의미로 사용되는 것 같다. 일단은 사전 제공되는 규모의 차이니 둘 다 프레임워크라 하기로...) 선택에 시간이 소요되고 있다.

많은 영상을 참고해 보면 둘 다 배우라는 이야기가 많지만, 나는 BE 뿐 아니라 DB도 신경써야 하고 서비스 자체를 기획해야 하는 입장에서 컨텐츠/디자인 영역에 소요될 시간이 더 많을 것 같아서 둘 중 하나를 선택해서 배워야 하는 입장이다.

혼자 끙끙 앓으며 고민하기보다는 두 기술에 대해 잘 설명되어 있는 유튜브 영상을 참고하여 프론트에 대한 이해도 할 겸, 선택에 대한 근거를 좀 쌓아두려고 한다.

참고한 자료는 아래 '큰돌의터전'님 유튜브 영상이다.

전반적인 특징

프로그래밍 패러다임

Vue.js(이하 Vue라 한다)의 경우, 반응형 프로그래밍으로 특정 요소에 값을 입력하면 watch하고 있다가 특정 변수에 값을 자동으로 입력해 준다고 한다. (Input -> Value)

예를 들어, 텍스트박스에 값을 입력하면 입력된 값을 별도의 할당 함수 없이도 변수가 해당 값을 인지하고 가지고 있을 수 있다.

위와 같은 특성을 가진 라이브러리를 다뤄본 적이 없어서 정확히 어떤 식으로 작동되는지는 알 수 없으나, 영상 내의 예시를 보니 대충 이해가 되었다.

React.js(이하 React라 한다)의 경우, 함수형 프로그래밍으로 setState등의 함수를 활용해 특정 요소에 입력된 값을 이용해 변수의 값을 변경 가능하다. (Input -> function -> Value)

데이터 바인딩

다 까먹어서 가장 이해가 취약한 부분인데... 현재 수준에서 적어보려 한다.

모델과 뷰 간의 데이터 동기화 방식에 대한 차이를 의미하는 것으로, 다른 분이 정리해 주신 내용을 참고하여 이해했다.

(출처 - adjh54님의 Tistory https://adjh54.tistory.com/49)

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 링크가 있어 이를 참고하여 설명해 주셨다.

(https://krausest.github.io/js-framework-benchmark/2022/table_chrome_104_windows.html)

기타

커뮤니티의 경우 React가 좀 더 활성화되어 있다.

아무래도 Facebook 진영에서 공식적으로 지원하는 라이브러리이다 보니, 버그 수정도 빠르고 뒷배가 더 든든해서 커밋 수, 포크 수, 기여자 수 등에서 React가 조금 더 앞선 모습을 볼 수 있다.

모바일로서의 확장성의 경우 React는 React-Native라는 너무나 강력한 지원군이 존재하여 NativeScript 등이 존재하는 Vue 진영에 비해 우위에 있다고 할 수 있다.

결론...?

다른 부분은 큰 차이가 없다고 가정하면, 세 가지 포인트 정도가 주된 의사결정 요소가 될 것 같다.

(표에는 없는) 시장 선호도, 러닝커브, (역시 표에는 안 쓴...) 모바일 확장성이다.

시장 선호도는 WorldWide 기준 여전히 React가 높고, 러닝 커브는 Vue가 낮으며, 모바일 확장성은 React가 우위에 있다.

이렇게만 놓고 보면 2대 1로 React의 승리인데... 리액트가 얼마나 배우기 어려운지를 잘 모르겠다...

조금만 더... 고민해보기로 하자...

끝.

이번 글에서는 ubuntu에서 sudo 계정 패스워드 초기화 및 sudo 계정으로 전환하는 방법을 알아보려고 한다.

최초에는 sudo 계정의 패스워드가 지정되어 있지 않으므로 1번 초기화 한 이후에 사용이 가능하다.

아래와 같이 sudo passwd root 명령어를 이용해 비밀번호를 초기화한다.

ubuntu@ip-(my-ip):~$ sudo passwd root
New password:  # sudo 계정에서 사용할 패스워드 입력
Retype new password:  # 한번 더 입력
passwd: password updated successfully  # 패스워드 초기화 완료

이후 su, su root 명령어를 입력 후 패스워드를 한번 입력하면 사용자 계정 -> root 계정으로 변경이 가능하며

exit 명령어를 통해서는 root 계정 -> 사용자 계정으로 변경이 가능한 것을 확인할 수 있다.

끝.

신규 인스턴스는 생성했으니, 지금 개발중인 크롤링 서버를 띄우기 위해 Tomcat 설치 및 관련 셋팅을 진행한다.

EC2 생성 및 SSH를 통한 접속 방법은 아래에 있는 이전 포스팅을 참고하면 된다.

JDK 설치

Tomcat은 Java EE 플랫폼을 기반으로 만들어져 Java를 필수적으로 요구한다.

JDK 또는 JRE를 설치하면 정상적으로 Tomcat 구동이 가능하며, Java 관련 개발을 할 진 모르겠으나 확장성을 위해 JDK를 설치하였다.

JDK를 설치하기 전, 필요한 버전부터 우선 확인한다.

아래 표를 보면 Apache Tomcat Version별 Supported Java Versions가 표시되어 있으니 본인에게 필요한 Tomcat 버전과 Java 버전을 확인하고 설치를 진행하면 된다.

현재 공식 홈페이지를 보면 Tomcat 11 버전까지 출시가 되었으나 Alpha 버전이므로, 정식 출시 버전 중 가장 최신인 10 버전으로 설치하기로 한다. JDK는 11 이상 버전을 선택하여 설치하면 되겠다.

내가 생성한 인스턴스의 OS는 Ubuntu이므로, apt를 이용해 설치를 진행한다.

레드햇 계열의 OS(CentOS 등)는 yum을 사용해 설치를 진행하면 되고, 일부 명령어 차이는 있으나 진행 방식은 거의 유사하므로 CentOS 등을 사용하시는 분은 아래 명령어 비교표를 참고하며 진행하면 되겠다.

sudo apt update  # apt로 설치 가능한 패키지 리스트를 업데이트
sudo apt upgrade  # apt로 설치한 패키지들을 업그레이드

설치한 적 없으나 혹시 몰라 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을 복사하여 사용한다.

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로 계정을 변경하여 진행하기로 했다.

무적의 sudo 계정을 가지고 다시 돌아왔다. 명령어를 재 실행해 보면...

Tomcat started.

Security Group - Port 설정

정상적으로 기동된 tomcat의 웰컴 페이지를 보기 위해, 기본 포트를 확인한다.

Tomcat 설치 경로 아래 conf\server.xml 파일을 확인해 보면, 아래와 같이 Connector port의 설정값이 8080임을 볼 수 있다.

그러면 내 인스턴스의 Public IP를 넣고, 포트를 8080으로 붙여서 접속해 보면...

아래와 같이 접속 불가 페이지를 볼 수 있다.

이유는 현재 내 인스턴스는 SSH로 접속하기 위한 SSH 기본 포트인 22 포트만 오픈되어 있기 때문이다.

AWS 콘솔에서 'EC2 > 인스턴스 > 인스턴스' 메뉴로 들어가서 내 인스턴스를 클릭한 뒤 아래 뜨는 창에서 '보안' 탭으로 들어가 보면, 아래와 같이 인바운드에 22번 Port만 오픈되어 있는 것을 볼 수 있다.

위 화면에서 '보안 그룹' 부분의 파란색 보안 그룹 ID를 클릭하면 해당 보안 그룹을 편집할 수 있는 새 창이 표시된다. 

해당 화면에서 하단의 '인바운드 규칙' 탭으로 진입한 뒤 '인바운드 규칙 편집' 버튼을 클릭한다.

표시되는 페이지에서 '규칙 추가' 버튼을 클릭한다.

유형은 '사용자 지정 TCP' 유형으로, 포트 범위는 Tomcat의 기본 커넥터 포트였던 8080으로, 소스는 우선은 전체 접속이 가능하도록 '0.0.0.0/0' 으로 입력한다.

이러한 인바운드 규칙을 추가하면 해당 인스턴스는 어떤 IP에서 접속하더라도 22번 포트로의 진입 뿐 아니라 8080 포트로의 진입도 허용하게 된다.

이후 다시 Public IP:8080 형태로 진입을 시도하면 아래와 같이 Tomcat 기본 페이지를 정상적으로 확인할 수 있다.

환경변수 설정 등 기본적으로 확인해야 할 내용들이 더 있으나, 해당 글에서는 전반적인 설치 후 정상적인 기동 확인까지만 진행한 후 다른 포스팅에서 이어 진행해보려고 한다.

끝.