3장_ 원격 서버 띄우기

 

로컬에서 개발 환경을 세팅한 뒤, 이번엔 원격 서버(EC2)에서 직접 프로젝트를 내려받고 빌드해서 실행해보려 한다.
처음에는 “서버에 그냥 jar만 올리면 되는 거 아닌가?” 싶었는데, 실습 흐름은 서버에서 직접 clone → 빌드 → 실행을 경험하는 쪽에 가깝다.

특히 지금 단계에서 중요한 건 “웹 서버를 띄우는 것” 자체보다,
터미널 환경에서 작업하는 감각이랑, 빌드/의존성/실행 구조를 납득하는 것이 핵심이었다.

 

 

지금 내가 있는 곳은 어디?

SSH로 EC2에 접속하면 보통 프롬프트가 이런 식으로 뜬다.

ubuntu@ip-...:~$

여기서 중요한 포인트는 ~가 의미하는 위치다.

• 계정: ubuntu (Ubuntu AMI의 기본 계정)
• 홈 디렉토리: /home/ubuntu
• ~ = 현재 로그인한 유저의 홈 디렉토리

즉, 화면에 ubuntu@...:~$가 보이면 지금 나는 /home/ubuntu에 있는 거다.

그래서 결론:

/home/ubuntu가 홈 맞고, 여기에 clone 받아도 된다.
(프로젝트 폴더를 홈 아래에 두는 게 제일 흔한 방식)

 

 

Git 설치: 서버에서 clone 받으려면 일단 Git이 필요하다

로컬에서는 Git이 당연히 깔려있는데, EC2는 “빈 우분투 서버”라서 Git이 없는 경우가 많다.
원격 서버에서 GitHub 저장소를 받으려면 Git 설치부터 해야 한다.

sudo apt update
sudo apt install -y git
git --version

 

 

 

Git clone: 서버에 소스코드를 내려받기

서버에서 실행할 거면 “내 로컬에 코드가 있다”로 끝이 아니다.
EC2 내부에도 프로젝트 소스코드가 있어야 빌드/실행이 가능하다.

보통 홈 디렉토리에서 진행한다.

cd /home/ubuntu
# 또는
cd ~

clone 후 프로젝트 폴더로 이동:

git clone <레포주소>
cd web-application-server

“clone이 제대로 된 건지” 확인 포인트

내가 ls -al로 확인했을 때 이런 것들이 보였다.

• .git (git 저장소라는 증거)
• pom.xml (Maven 프로젝트 루트)
• src/ (소스 코드)
• webapp/
• target/ (이미 빌드 산출물이 있거나 이전 빌드 흔적)
• Procfile (실행 명령 힌트)

이 구조가 보이면 결론은 명확하다.

✅ clone 성공
✅ Maven 프로젝트 루트를 제대로 열고 있음

 

 

Maven 빌드: 소스를 “실행 가능한 형태”로 컴파일하기

Java는 .java 파일을 바로 실행할 수 없다.

• 컴파일된 .class 파일이 필요하고
• 외부 라이브러리(.jar)도 같이 준비돼야 한다

이걸 자동으로 처리해주는 게 Maven이다.

프로젝트 루트(pom.xml 있는 곳)에서:

mvn clean package

빌드가 성공하면 target/ 폴더가 만들어지고, 대략 이런 구조가 생긴다.

• target/classes/ : 컴파일된 .class 파일들
• target/dependency/ : 외부 라이브러리 .jar들

나는 실제로 이렇게 확인했다.

ls -al target/dependency | head

그러면 guava-18.0.jar, junit-4.11.jar, logback-*.jar 같은 것들이 찍힌다.

✅ 결론: 빌드 + 의존성 jar 준비까지 완료된 상태

 

 

“외부 라이브러리를 내가 설치한 적이 없는데 jar가 왜 있지?”

여기서 제일 헷갈렸던 부분이 이거였다.

“나는 guava를 apt로 설치한 적도 없고, jar를 다운받은 적도 없는데
왜 target/dependency에 jar가 깔려있지?”

이건 Maven의 핵심 구조 때문에 그렇다.

Maven 프로젝트에서는 외부 라이브러리를 “내가 직접 설치”하지 않는다.
대신 pom.xml에 이렇게 선언한다.

• “이 라이브러리가 필요하다”
• “버전은 이걸로 쓴다”

그러면 Maven이:

• 공식 Maven 저장소에서 자동 다운로드
• 빌드에 포함되도록 정리

즉,

target/dependency/*.jar는 Maven에 기본으로 들어있는 게 아니라
이 프로젝트가 요구한 의존성을 Maven이 받아온 결과다.

 

 

실행: 서버를 실제로 띄우기 (Procfile을 실행 힌트로 사용)

프로젝트 루트에 Procfile이 있었고, 안에 실행 명령이 적혀 있었다.

web: java -cp target/classes:target/dependency/* webserver.WebServer $PORT

Procfile은 원래 Heroku 같은 PaaS에서 “앱 실행 방법”을 알려주려고 쓰는 파일인데,
지금 내 입장에서는 그냥 이렇게 이해하는 게 편했다.

“이 프로젝트 제작자가 의도한 공식 실행 방식”

즉, 실행할 때 참고해야 할 힌트가 이미 들어있었다.

 

 

java -cp ... webserver.WebServer가 왜 필요하냐?

Java는 결국 main 클래스 하나를 지정해서 실행해야 한다.

여기서 main 클래스가:

• webserver.WebServer

즉, webserver 패키지 안의 WebServer 클래스에 main()이 있고,
그걸 실행하는 구조다.

내가 처음에 “webserver 없다고 했잖아?”라고 생각했던 건
“내가 아직 구조를 모른다”는 의미였지, 프로젝트에 없다는 뜻이 아니었다.

실제로는 프로젝트 안에 존재한다.

예를 들어 이런 식으로 찾아볼 수 있다.

find src -type f | grep WebServer
# 또는
grep -R "class WebServer" -n src

 

 

 

포트 7070으로 서버 띄우기

나는 이번 실습에서 포트를 7070으로 쓰기로 했다.

이 프로젝트는 포트를 환경변수 PORT로만 받는 게 아니라,
프로그램 인자(args)로 받는 구조라서, 가장 확실한 실행은 이거다.

java -cp "target/classes:target/dependency/*" webserver.WebServer 7070

 

• -cp : classpath 지정 (실행에 필요한 클래스/라이브러리 경로)
• target/classes : 내 프로젝트 컴파일 결과(내 클래스들)
• target/dependency/* : 의존성 jar들 전부
• webserver.WebServer : main()이 들어있는 실행 클래스
• 7070 : 서버가 열릴 포트 번호(프로그램 인자)

즉 “내가 만든 클래스 + 필요한 라이브러리를 classpath에 올리고, WebServer.main()을 7070 포트로 실행해라”

를 JVM에게 명확히 지시한 거다.

 

sudo는 왜 붙였다/뺐다?

이것도 같이 정리해두면 헷갈릴 일이 없다.

• 7070은 1024보다 큰 포트 → sudo 필요 없음
• 80 같은 특권 포트(<1024)는 → sudo 필요

즉,

7070 → sudo 없이 실행
80 → sudo 필요

 

 

여기까지 오면 “서버에서 실행 가능” 상태가 된다

정리하면 이 순서로 딱 정리된다.

1. EC2에 접속해서 내가 어디 있는지 확인 (~ = /home/ubuntu)
2. Git 설치 후 clone으로 코드 내려받기
3. Maven으로 빌드하면서 클래스 + 의존성 jar 준비
4. java -cp로 main 클래스 실행
5. 포트 지정해서 서버 띄우기

 

 

 

---

출처 : 《자바 웹 프로그래밍 Next Step》, 박재성, 로드북