Q: ?! 뭐고,, 바로 앞에서 DB 설계해놓고 무슨 벌써 배포야 이 뚱때지야!
A: 산전수전 다 겪어본 개발자 선배님의 조언을 듣고 결정했어요!

이번 토이프로젝트는 혼자 하는 게 아니라 짱멋진 프론트엔드 파트너도 함께 하는데,

클라이언트와 서버 사이에 오갈 API의 내용이나 오류 처리 방법 등을 저 혼자 싹 정해놓고 '이대로 해줘!' 하는 건 양쪽에게 너무 큰 부담이기도 하거니와, 파트너와 협업하는 바람직한 태도가 아니라고 생각했어요.

그래서 '백엔드 어플리케이션(스프링 부트)와 프론트엔드 어플리케이션(리액트)를 배포한 다음 -> 두 어플리케이션이 원활히 소통할 수 있도록 설정을 완료한 후 -> 처음에 계획한 요구사항을 양쪽에서 하나하나 구현해가보자' 하고 가닥을 잡은거죠!

면접관님 보고 계시나요? 제가 얼마나 생각이 깊은지 보이시나요? 네? 보이시나요? 네? 보이시나요? 네? (···)

---

인프라 공부하기

어디에 배포할까!

제가 클론코딩 서적이나 강의를 들으면서 배포 작업을 위해 사용해본 플랫폼이 두 개가 있는데, 하나는 Hiroku이고 하나는 AWS였어요.

AWS는 막 EC2가 어쩌구 설정할 게 많은데 셸 스크립트라는 언어를 하나도 몰라 꽤 고생했던 기억이 있지만 많은 회사에서 사용하고 있고,
Hiroku는 배포하는 작업이 되게 단순하고 쉽게 성공했던 기억이 있는데 채용공고를 보면 회사들이 많이 사용하지 않는 것 같았어요.

어렵지만 배워두면 많이 쓰이는 AWS, 쉽지만 잘 안 쓰는 Hiroku 중 어떤 게 좋을까 고민하다, 제 성장 가능성과 미래를 생각해 봤을 때 AWS를 사용해보기로 결정했습니다! ٩(๑•̀o•́๑)و

AWS 간단히 공부해보기

AWS로 배포해보자!
근데 어쩌죠, 전 정말 하나도 모르거든요 (;´༎ຶД༎ຶ`)

성급하게 프로젝트를 배포부터 하려하지 말고,
AWS라는 기술의 전반적인 생태계에 발부터 담구어 보자는 마음으로 입문 강의를 찾아다녔어요.

제가 애용하는 인프런에 마침 적당한 가격에 적당한 커리큘럼을 가진 AWS(Amazon Web Service) 입문자를 위한 강의를 발견하고 냅다 질렀죠!

AWS라는 기술에 대한 개념이 사실상 없는 저같은 입문자에게는
깊은 이해나 복잡한 응용보다는 간단한 실습을 따라하면서 눈과 손에 익히는 친절한 강의가 필요했는데, 운좋게도 이 강의가 딱 그런 강의었어요!

프로젝트를 배포하고 관리, 모니터링하기 위해 필요한 AWS의 다양한 분야를 살짝살짝씩 사용해보면서 '이런 게 있구나'를 익히는 데에는 충분했습니다.

간단히, 하지만 쪼금 더 깊이 공부해보기

스프링 시큐리티 관련한 글에도 살짝 이야기했는데,
어떤 기술이든지 한 번에 똑딱 공부하고 바로 똑딱 적용할 수 있는 사람은 세상에 그렇게 많지 않을 뿐더러 그래서도 안된다고 생각해요.

같은 주제에 대해 최소한 3명 이상의 서로 다른 사람이 설명하는 내용을 공부하고 훈련해보면서 몸에 익히는 과정이 반드시 필요하다 판단하여,

이번엔 AWS 입문용 서적으로 서비스 운영이 쉬워지는 AWS 인프라 구축 가이드를 읽고 실습하는 훈련을 했습니다!

종이책은 2019년에 출간했는데, E북으로는 올 해(2022년) 7월에 출간되어 AWS 책 중에서는 가장 최근에 나온 책 중 하나여서 구매했어요!

책에서 제공해주는 프로젝트를 AWS에 실제로 배포해보고, 관리해보고, 모니터링해보고 그 유명한 Elastic Stack과 CI/CD에 사용하는 다양한 도구를 사용해 이것저것 뽀시락뽀시락 실습해보는 서적이에요.

실제 프로젝트를 배포하는 실습과정이 제 공부목적에 딱 맞았고, 도구들의 개념을 진짜, 진짜진짜 쉽게 설명해주셔서 실습 내내 '이게 이런 거였어?!' 하면서 즐겁게 공부했던 기억이 납니다. 기본 개념이 한 층 더 튼튼해진 것은 덤이구요!

내 프로젝트 배포 방법 찾기

'이런 게 있구나' 정도 수준에서 '이건 이런 거구나' 를 아는 정도까지 왔으니,
실습 훈련을 몇 번 더 해보면 프로젝트에 적용해볼 수 있겠구나 생각했어요.

하지만 면접 준비도 슬슬 해야 하고, 면접을 보기 위해 서류심사에 통과하려면 완성된 토이프로젝트가 하나쯤은 필요하기 때문에 하염없이 공부만 하고있을 수는 없었습니다. 🥲

그래서 바로 위에서 완독했던 책을 다시 한 번 읽어보되, 책의 예제파일이 아니라 이번엔 제 토이프로젝트를 배포하면서 실습해보면 좋겠다 생각했습니다.
그런데 젠장 책에서 배포하는 프로젝트는 Node.js고 제 프로젝트는 Spring boot라서 이게 아다리가(???) 안 맞는거에요!

아쉽지만 이 책을 보면서 제 프로젝트를 배포하는 건 너무 험난하다 싶어 또 다른 차선책을 찾았으니,
예전에 샀던 스프링 부트와 AWS로 혼자 구현하는 웹 서비스라는 클론코딩 서적의 챕터 5부터 쭉 이어지는 프로젝트 배포 파트였습니다.

보통의 클론코딩 서적에서 프로젝트를 배포할 때에는 EC2, S3 등 많은 작업을 편리하게 자동화해주는 Beanstalk을 사용하지만, 이 서적에서는 쉬운 Paas 기술을 사용하지 않고 Iaas 영역인 EC2, S3, RDS 등을 하나하나 직접 설정하면서 배포를 진행합니다.

(IaaS(Infrastructure as a Service, 서비스형 인프라)는 서버, 데이터베이스, 로드 밸런서 등 원래라면 우리가 들어 나르고 전선 뽑았다 꽂았다 하며 물리적으로 작업해야 하는 컴퓨터 자원을 아마존 같은 기업에서 하나의 서비스로 만들어 제공하는 것을 말해요!)

(PaaS(Platform as a Service, 서비스형 인프라)는 IaaS를 한 번 더 추상화해서, IaaS만 사용한다면 각각의 설정창에서 서버 구성,, 데이터베이스 크기,, 트래픽이 커지면 서버를 몇 개까지 늘릴 것인가 줄일 것인가 등 일일이 설정해야 했던 것을 기업에서 알아서 자동화하여 서비스로 제공하는 것을 말해요!)

beanstalk을 사용하는 것보다 훨씬 복잡하긴 하지만
beanstalk으로 배포한 프로젝트는 무중단 배포(배포를 진행하는 동안 어플리케이션이 닫히지 않게 하는 기술)이 안된다 하고,
무엇보다 입문자일 때에는 하나하나 직접 해보며 깨우치는 과정이 꼭 필요하다 생각해
이 책의 배포 과정이 꽤 마음에 들었습니다.

실전! 내 프로젝트 배포하기 (｡•̀ᴗ-)✧

서적에서는 프로젝트를 배포하기 위해
-> EC2 인스턴스를 만들고
-> RDS(데이터베이스) 인스턴스를 만들어 EC2와 연동하고
-> deploy.sh라는 배포 파일을 만들고 실행하여 프로젝트를 수동으로 배포하고
-> Travis CI에 연동하여 깃허브에 프로젝트가 푸시될 때마다 자동으로 프로젝트를 테스트, 빌드하여 안정적인 배포 파일을 만들도록 하고
-> 배포 파일을 자동으로 S3에 저장하도록 하고
-> CodeDeploy에서 S3에 저장된 배포 파일을 사용해 배포를 자동으로 진행하도록 만드는···

다사다난한 과정을 거쳐 배포를 진행하는 데다
매 단계마다 오류가 나며 마음대로 되지 않아
입문자인 저는 배포를 완료하는 데에 일주일 넘게 걸렸으나,,

문제의 원인을 찾고 해결하는 과정(트러블슈팅이라고 불러요!)에서
정말 많은 검색과 공부를 하며 성장할 수 있었고,
결과적으로 제 백엔드 토이프로젝트 배포에 성공했기 때문에
엄청난 성장과 뿌듯함을 느낄 수 있었습니다.

위 과정을 거치며 제일 저를 괴롭게 했던 트러블슈팅 사례를 몇 개 정리하면서 글을 마무리하겠습니다 :-)

 
···라고 하기엔 당시에 너무 기록을 안 해놔서 쓸 게 하나 뿐이네 머쓱;;;

트러블슈팅 1 - CodeDeploy 미작동

원래 제가 설정한 대로라면,
깃허브의 main 브랜치에 저의 코드를 뽁하고 푸시했을 때
Travis CI가 자동으로 감지해 CI/CD 작업을 시작해요.

Travis CI에서 배포가 완료되었다는 로그가 나오면

AWS S3에 배포 파일이 잘 업로드된 것을 확인하고

AWS codeDeploy에 배포의 배포 내역에 성공적인 배포 결과가 뚷 하고 나와야 해요.

 
그런데 세상에마상에! S3에 배포파일이 저장은 잘 됐는데,
codeDeploy가 전혀 동작하지 않는 거에요..
무슨 오류가 났다면 배포 실패 기록이라도 있을 텐데,
정말 아무 기록도 없는 걸 보아, 아예 작동하지 않은 것으로 보입니다.

뭐 무슨 오류 기록이라도 있으면 구글링이라도 해볼 텐데,
Travis CI에서는 '배포 완료!' 이래놓고 실제로는 그게 아니니 정말 답답했습니다.
당시 'Travis CI worked but codeDeploy not working' 이런 식으로 구글링하며 해결책이 있나 찾아보았지만 영 신통치 않아, Travis CI 말고 다른 배포 도구를 사용해야 하나 진지하게 고민하고 있었어요.

깃헙액션을 한 번 써볼까 생각하며 착잡한 마음으로 태블릿을 켜 Travis CI 사이트를 다시 들어가본 그때!

오류 로그가 로그 파일의 맨 위에 있었네요 (;´༎ຶД༎ຶ`)

어떤 브랜치로 푸시했을 때 codedeploy에 접근해 작업을 진행할 수 있는지 명시해주어야 하는데,
main 브랜치에 대해 codedeploy 접근 권한을 명시해주지 않아 codedeploy와 관련한 작업을 건너뛰었다는 거에요.
역시 프로그램은 잘못이 없군요. 사람이 문제야 ;-;

Travis CI가 작업할 때 참고하는 설정 파일인 travis.yml이 있는데,
이 파일에 해당 내용을 반영했습니다.

해당 코드를 추가하고 main 브랜치에 반영했더니
Codedeploy에 짜잔~ 하고 배포 성공 내역이 기록된 것을 확인했어요.

---

이번에 배포한 프로젝트는 저의 스프링 프레임워크 프로젝트이고,
프론트엔드 파트너가 만든 리액트 프로젝트도 배포해야 하니
자연스럽게 반복학습이 될 수 있겠네요! 기대가 됩니다.

일기장에 가까운 내용이지만 읽어주셔서 고마워요. 안녕 :):)