2022 Masters Course/Project Course

2022 마스터즈 코스(백엔드) 66일차 회고(2022. 4. 11.) - "마침내 하게 된 AWS 배포"

ikjo 2022. 4. 11. 21:17

해당 글은 코드스쿼드 2022 마스터즈 코스 "Java 웹 백엔드" 과정을 수강하면서 학습한 내용 등에 대한 회고 글입니다. :)

 

수강 회고

오늘(정확하게는 오늘 새벽) 처음으로 AWS EC2를 이용하여 스프링 부트 웹 앱(MySQL 연동)을 배포해보았다. AWS 배포는 코드스쿼드 마스터즈 코스 과정을 시작하기 전부터 매번 미루어 두었던 과제였는데, 마침내 마스터즈 과정 미션을 통해서 도전해볼 수 있게 되었다. 🤣 마스터즈 코스 과정을 수강하면서 느낀 장점 중 하나는 혼자서 학습할 때는 매번 미루어두는 것을 미션 등의 환경을 통해 (반강제적으로?) 해볼 수 있게 된다는 것이다.

 

지난번 3주 과정의 스프링 부트 웹 앱 미션에서는 Heroku를 이용하여 스프링 웹 앱(h2 인메모리 방식 및 cleardb MySQL 연동) 배포를 시도했었는데 당시에 엄청난 삽질과 함께 '시간과 정신의 방'을 겪을 수 있었다. 😇 이번 AWS EC2를 이용한 배포 시에도 아니나 다를까 똑같이 엄청난 삽질과 함께 '시간과 정신의 방'을 겪을 수 있었다....🤣

 

배포는 개발과 다르게 오류 등이 발생 시 '원인을 찾기가' 매우 힘든 것 같다. 개발할 때 발생하는 예외들의 경우에는 나름 정형화되있는 편이라 구글링을 통해 해당 문제의 원인을 발견하기가 용이한 편이다. 하지만 배포는 운영체제, 프로그램 버전 등 개발자가 각자만의 환경에서 작업하는 것이기 때문에 구글링을 통해 해당 문제에 대한 원인을 검색(구글링 등)해보아도 명쾌하게 해답이 나온 곳이 흔치 않다. 심지어 대소문자, 슬래쉬 등 아주 사소한 원인으로 인해 오류가 발생하는 경우도 많은데 이를 찾기가 쉬운 일이 아니었다. (감사하게도 간혹 도움이 되는 글들이 보이는데, 이 글들 덕에 해결되는 일도 있다.) 

 

아무쪼록 지난 스프링 부트 웹 앱 미션(웹 백엔드 과정)에서의 Heroku 배포와 이번 팀 프로젝트 투두리스트 웹 앱 미션에서의 AWS 배포를 무사히 마칠 수 있었고 그 과정에서도 많은 것을 경험(학습이라기 보다는 🤣)할 수 있었다. 배포 역시 개발처럼 많이 해보고 경험을 많이 쌓을 수 밖에 없겠다는 생각이 들었다.

 

 

학습 회고

  • 투두리스트 구현 프로젝트
    • 팀원들(백 엔드 2명, 프론트 엔드 2명)과 zoom 회의실에서 학습

 

지난 주 스프링 부트를 통해 투두리스트 웹 앱을 개발하면서 다소 기능 구현에 초점이 맞쳐져 웹 앱 구조 설계에 대한 고민이 많이 부족했었는데, 마침 주말간 담당 리뷰어가 관련해서 리뷰를 많이 주었다. 좀 더 객체지향적으로 웹 앱을 설계할 수 있을지 고민해볼 필요성을 느낄 수 있었고 저번주에 이어 관련된 객체 지향 설계 원칙을 공부해보았다.

 

개방 폐쇄 원칙

자신의 확장에는 열려 있고, 주변의 변화에 대해서는 닫혀 있어야 한다.(로버트 C. 마틴)

 

만일 운전자라는 클래스와 마티즈 클래스, 쏘나타 클래스가 있다고 가정해보자. 이때 운전자는 마티즈 또는 쏘나타 중 하나의 클래스에 의존하게 될텐데 의존하는 클래스가 바뀔 때마다 그 클래스에 맞는 메서드를 호출해주어야 한다. 운전자 입장에서는 의존 클래스가 바뀔 때마다 매번 메서드명을 수정해야하는 번거로움이 있다.

 

이때 운전자 클래스와 마티즈나 쏘나타 클래스 사이에 완충 장치로서 상위 클래스(마티즈나 쏘나타 클래스의)나 인터페이스를 중간에 둔다면 운전자 입장에서는 인터페이스에 명시된 메서드만 호출한다면 마티즈, 쏘나타 등 그 어떤 차량 클래스로 바뀐다고 한들 신경쓸 필요가 없게 된다. 즉, 완충 장치 역할의 상위 클래스나 인터페이스 입장에서는 자신의 확장에는 개방돼 있는 것이고, 운전자 입장에서는 주변의 변화에 폐쇄돼 있는 것이다.

 

여러 데이터베이스 프로그래밍을 지원하는 JDBC 인터페이스자바 소스 코드 파일이 자바 컴파일러에 의해 변환된 목적 파일(One Source One Object Use Anywhere) 역시 이러한 개방 폐쇄 원칙을 적용시켰다고 볼 수 있다.

 

개방 폐쇄 원칙을 따르지 않는다고 해서 객체 지향 프로그램을 구현하는 것이 불가능한 것은 아니지만 개방 폐쇄 원칙을 무시하면 객체 지향 프로그래밍의 가장 큰 장점인 유연성, 재사용성, 유지보수성 등을 얻을 수 없다. 따라서 객체 지향 프로그래밍에서 개방 폐쇄 원칙은 반드시 지켜야 할 원칙이다. 이러한 개방 폐쇄 원칙에 대한 좋은 예는 바로 스프링 프레임워크이다.

 

 

학습 참고자료

  • 위키북스 출판 '스프링 입문을 위한 자바 객체 지향의 원리와 이해'

 

 

좋았던 점

  • 오늘 팀원인 Hanse와 협의하여 각자의 컨디션 조절을 위해 휴식 시간을 가졌는데, 이 휴식 시간을 통해서 피로했던 컨디션 상태를 많이 회복할 수 있었습니다. 👍

 

 

아쉬웠던 점

  • 주말에 담당 리뷰어께서 리뷰를 주셨는데, 리뷰를 보니 설계에 대해 많은 고민을 하지 않았었던 것 같아 아쉬웠습니다. 😇

 

 

이전 보다 개선되었던 점

  • 매번 미루어 두기만 했었던 AWS(EC2)를 이용한 배포를 처음으로 시도(MySQL 연동 스프링 부트 웹 앱)해보았고 성공적으로 배포할 수 있어서 보람있었습니다. 🥕