싸피를 하면서 배포를 했던 경험에 대해 한 번 정리해보려고 한다.

관통프로젝트 - 특별함

사실상 처음으로 프로젝트 단위로 개발을 경험했다고 생각한다. 이 때 까지만 해도 교육생들은 배포에 대해 생각하지 않고 있었고, 나 조차도 배포를 해본 경험은 없었다.
졸업 프로젝트 당시 같은 팀원이 배포하는 것을 옆에서 지켜보았고, 그다지 중요하지 않게 생각했던 것 같다.
관통프로젝트를 진행하면서 한 팀원의 DB가 데이터를 제대로 받아올 수 없는 상태였는데, 이 문제에 대한 답변이 배포였다.

그럼 각자 DB를 놓지 말고 DB를 배포해서 사용하면 더 좋지 않을까요?

당연히 팀원들의 반응은 호의적이였고, 나도 아주 쉽게 성공할 수 있을 것이라 생각했다. 실제로 당시만 하더라도 쉽게 된 줄 알았다. 또 배포하는 김에 전체 서비스를 배포해서 발표할 때 보여주고 서비스를 직접 들어올 수 있게 만든다면 굉장한 와우포인트가 될 수 있을 것이라고 생각했다.
그렇게 배포를 하면서 Spring Boot의 배포 방법을 찾아보게 되었고, .jar 파일로 쉽게 배포할 수 있다는 것을 알게 되었다.
여기서 큰 실수가 나오게 되는데 Vue.js를 배우면서 실행시키는 방법으로 npm run serve만을 알고 있었던 것이다...
당연하다는듯 콘솔에 직접 들어가서 npm run serve를 치고 접속이 되는 것을 확인하면서 "오 된다!" 라며 배포에 성공(?)하게 된다.

당연히 안됐다.

문제 발생

이렇게 말도 안되는 방법으로 배포하고 난 뒤 문제는 발표에서 터지게 된다.
제일 마지막에 발표하게 되면서 서버를 계속 켜놓았는데 당시에는 putty에서 세션을 유지하는 세팅을 하는 것 조차 몰랐고 결국 대기중 핑이 없어 putty가 터지게 되었다.
덕분에 시연에서 문제가 발생했고 바로 접속하지 못하는 문제가 발생했다.

해결

당시에는 웹서버의 존재도 알지 못했고, 스프링 부트를 배포할 때 왜 .jar만으로 배포할 수 있었는지조차 알지 못했다.
이 과정 속에서 기술을 정확히 알고 사용하는 것이 무엇보다 중요하다는 것을 느끼게 된다.

공통프로젝트 - 제대로 배포하기

이전 프로젝트에서 발생한 run serve 사건 이후로 제대로 배포하기 위해 Front-end의 배포 방법에 대해 찾아보게 되었다. 결론적으로는 웹 서버가 필요하다는 것.
대표적인 웹 서버는 아파치 httpd 와 NGINX가 있다는 것도 알 수 있었고, 최근에는 더 설정이 간단한 NGINX를 더 많이 사용한다는 것도 알 수 있었다. 러시아에서 만들어서인지 공식 문서가 굉장히 불친절했지만 다양한 곳에서 설정에 필요한 내용이 잘 설명되어 있어 NGINX를 사용할 수 있었다.
백엔드에 경우는 여전히 Spring Boot 단독으로 사용하게 되었다. 다만, 그 안에 Tomcat이 있기 때문에 단독으로 배포가 가능하다는 것을 알게 되었다.
이후 쉽게 배포가 되었다면 정말 좋았겠지만...

https...?

문제 발생

처음으로 https라는 것을 듣게 된다.
다른 팀에서 배포한 환경에서는 없는 빨간색 삼각형 안의 느낌표와 경고 페이지를 통해 https의 존재를 알게 되었다.
이를 적용하기 위해 SSL을 설정해야하고, 설정하기 위해 Certbot으로 키를 받아야 한다는 것도 알 수 있었다.
다만, 이렇게 세팅한 이후 백엔드로 요청이 가지 않는 문제가 발생한다.
백엔드에서는 http 요청을 대기하고 있었기에 발생한 문제였다.

해결

당시 해결 방법으로 생각한 것은 백엔드에도 https 설정을 해주는 것이였다. certbot으로 받은 키를 .p2파일로 변환하고, 이를 통해 스프링 부트 설정 파일(yaml)에서 세팅해주는 것.
백엔드의 https 설정 이후 정상적으로 요청을 받아올 수 있었고, 문제가 "해결된 것 처럼" 보였다.

더 좋은 해결 방법

사실 이 해결방법은 네번의 프로젝트를 모두 종료한 뒤 팀원들을 위한 배포 세션을 준비하던 중 알게 되었다.
NGINX에는 다양한 기능이 존재하는데, 크게 웹서버, 로드밸런서, 그리고 리버스 프록시이다.
이중 리버스 프록시를 활용해 요청을 나눠줄 수 있는데, request url에 따라 각각 그 요청을 나눠주는 것이다.
이를 통해 백엔드의 요청은 '/api'와 같이 설정하고, 해당 요청이 들어왔을 때 localhost:{port번호}로 프록시를 넘겨주면 해당 요청은 다른 ssl 설정 없이도 요청을 받을 수 있는 것이다. NGINX가 내부 서버에 다시 요청하는 방식이기에 ssl 설정 없이 가능한 것.
프로젝트 종료 후 진행하는 배포에서는 해당 방법을 적극적으로 사용하며 배포하고 있다.

특화-자율 프로젝트 - 자동배포

앞서 수동으로 배포하는 환경도 나쁘지 않았다.
다만 프로젝트가 막바지가 되면서 계속해서 배포하며 테스트해야 했고, 이 과정에 Back-end와 배포를 겸업하는데 크게 문제가 되기 시작했다. 또, 매 프로젝트마다 더 발전된 모습으로 배포하길 원했기에 자동배포에 욕심을 내기 시작한다.

좋긴한데... 그래서 어떻게...?

1. 도커

자동 배포를 위해 필수적이진 않으나, 서비스를 더 효과적으로 관리하기 위해 반드시 필요하다고 생각했다. 특히 특화 프로젝트에서는 추천 시스템으로 인해 2가지 백엔드 서버(Spring과 Django)가 필요했기 때문에 도커의 사용으로 더 편리하게 시스템을 구성할 수 있을 것이라 기대하게 되었다.
또, 이미지를 통해 간단하게 배포하는 과정이 배포하는 과정을 단순화하고 편리하게 도와줄 것이라 기대했다.

2. 젠킨스

자동 배포를 위해 가장 많이 거론된 솔루션이 Jenkins와 TravisCI였다. 현업에서는 CI환경 구축을 위해 TravisCI를 많이 사용하는 것 같았지만, Jenkins의 설정이 더 간단하게 보여 Jenkins를 사용하게 되었다.
(또, 자동배포를 하는 과정에서 찾은 블로그가 Jenkins를 사용하기도 했다.)

프로젝트가 끝나고,

그래서 결과적으로 자동 배포를 하기에 이른다.
도커의 사용방법을 익히기 위해 공식문서와 여러 블로그 아티클을 살펴보았고, 자율프로젝트가 끝난 시점에서는 도커에 대해 이해하고 사용할 수 있게 되었다. ctrl-c,v로 만들었던 내용들이 어떤 의미인지 이해할 수 있었고, 자율프로젝트에서는 아주 어렵지 않게 자동배포 환경을 만들 수 있었다.
무엇보다 치열하게 고민했던 문제였기에 문제에 대한 해결 방법을 잘 정리하며 진행했고, 정리한 내용을 팀원들과 공유하기 위해 발표 자료도 만들어 공유했다. 팀원들의 호응도 좋았지만 대체로 "좋긴 한데 아직은 다 이해하기는 힘들다"였다.

이 과정들에서 특히 다음 생각을 많이 했다.

• 결국 내가 직접 고민한 내용이 내 것이 된다.
• 도움을 받는 빠른 방법도 있지만, 내가 고민한 것이 더 빨리 체득된다.
• 세상에는 너무 많은 블로그가 있고, 단 하나의 공식문서가 있다. 공식문서를 봐라.

진행 과정이 느릴지언정 내가 직접 고민하고 찾아낸 것들이 더 빠르게 체득되었다. 이 생각은 교육생을 넘어서 코치가 되었을 때에도 같았기에, 교육생들에게 피드백을 제공하거나 질의응답에 대한 답변을 주면서도 계속해서 고민하게 되었던 것 같다. 빠르게 진행하기 위해서 반드시 질의응답이 필요하긴 하지만, 직접 찾았어도 해결할 수 있었을텐데 싶은 문제도 있었기 때문이다.

또 구글링을 통해, 혹은 블로그 아티클을 통해 해결한 문제는 보통 "내가 이해한 문제"는 아닌 경우가 잦았다. 배포와 서버에 대해 공부하면서 "Snowflake 서버"라는 말에 굉장히 공감했는데, 블로그 아티클은 결국 나의 상황과 100% 일치하지 않는다. 하지만 (영어라 어려울지라도) 공식 문서를 보고 따라가는 방식이 문제 해결에도 좋았고, 원리를 배우기에도 더 좋은 방식이였다. 다만 어려워서 그렇지.

결과적으로는 이후 개발자로서 어떻게 개발해야 할 것인지에 대해 굉장히 많이 고민했던 과정이였던 것 같다. 배운 점도 많았고, 해보고 싶은 것도 많았던 과정이다. 특히 내가, 내 팀이 고생해서 만든 프로젝트를 다른 사람들이 사용해볼 수 있도록 만들 수 있다는 것이 그랬다.
그래서인지 프로젝트가 모두 끝난 이후 그 내용들을 다시 정리하고 배포하는 과정에 공을 들이고 있다고 생각한다.

빨리... 채용 시즌이 끝나면... 다시 배포를 진행해보려 한다.

채용 과정이... 끝나면... 더 좋고...