📕Facts(한 것)

📕Findings(배운 것)

도커로 빌드하기 전에 막혀서 aws상에서 배포를 진행했다.

aws상에서 배포, 뭔가 거창해 보이지만 단어 하나하나 풀어보면 그렇게 거창하지 않다.

먼저 배포란 뭘까? 배포를 어떻게 해야 배포인 걸까?

배포는 서버를 실행하는 것과 동일하다고 생각하면 된다.

하지만 이 서버가 항상 실행이 된 상태여야 클라이언트가 언제든 요청할 수 있지 않겠는가?

당연히 우리 개인 컴퓨터로도 할 수 있지만, 우리의 컴퓨터가 서버용도 아닐뿐더러, 굳이 비싼 노트북, 맥북을 써서 이렇게 할 이유가 없다.

그래서 우리는 아마존의 서버를 빌려서, 내 스프링 프로젝트를 실행하는 것이다.

배포하는 방법은 간단하다.

aws에서 git 프로젝트를 clone 해서 명령어를 입력해 실행하면 끝.

프로젝트 git을 aws 상에 clone 한다.
프로젝트 최상위 폴더로 이동한다.
(gradle이라는 가정 하에)./gradlew build 명령어를 실행한다. (test 제외 빌드는./gradlew build -x test)
빌드를 하면 /build/libs에 .jar 파일이 생성된 것을 확인할 수 있다.
sudo java -jar /build/libs/{생성된파일.jar} 를 입력하면 서버를 띄울 수 있다.
ssh 연결을 종료하고 나서 계속 실행하게 하고 싶다면
nohup java -jar /build/libs/{생성된 파일.jar} & 를 입력하면 된다.

물론 기본적으로 서버에서 사용하는 포트를 인바운드 규칙에서 열어줘야 한다.

(gradle 프로젝트의 경우 8080 포트)

팀원들과 내부 메서드를 외부에서 접근 가능하게 사용할지에 대한 여부에 대해서 논의를 많이 했다.

userService에 있는 함수인데, 이를 다른 서비스에서도 사용하고 싶다는 게 포인트이다.

하지만 나는 서비스가 다른 서비스에 의존하고 있는 것이 영 마음에 들지 않았고, 아키텍처 의존관계에 위배된다고 생각한다.

클린 아키텍처 구조를 보면 web -> controllerts -> service -> entity 순으로 들어가야하는데, 이 관계를 해치기 때문이다.

또한 컨트롤러에서 내부함수를 리턴하는 것도 설계상에는 문제가 없지만, 내부 로직에서 문제가 여럿 발생한다.

그렇기 때문에 로직 수정을 감행하고서라도 이걸 변경해야할 필요가 있는지 나는 의문이 든다.

이 문제를 논리적으로 잘 해결하면 다음에 나타나는 문제도 잘 해결할 수 있을 것 같다.