인프런 워밍업 클럽 스터디 BE 세번째 발자국

3주차입니다!

들어가기 전에

드디어 커리큘럼의 마지막 3주차를 지났다.

과정이 시작할 쯔음에 이번 스터디를 통해 많이 배우고 성장하고 싶어했다.

그리고 그걸 이룬 것 같아 뿌듯하다.

 

3주차에는 아래의 내용을 학습했다.

• JPA 연관관계
• AWS EC2를 활용한 배포
• Spring Boot 설정
• 코드리뷰

전부 처음 배우는 개념들이었지만 역시 쉽게 배울 수 있었다.

 

그동안 배운 내용을 실제 서비스의 형태로 배포하기까지의 과정을 배우며

서버 개발자로 필요한 전반적인 지식들에 대한 기초와 자신감을 얻기 충분한 시간이었다.

 

Day 10: 객체지향과 JPA 연관관계

연관관계

엔터티 간 관계를 정의하는 방법으

테이블(엔터티) 간 객체지향적 모델링이 가능해진다.

 

1:1 (@OneToOne)

한 엔터티가 하나의 엔터티만 연관된 경우에 해당한다.

 

1:N (@OneToMany)

한 엔터티가 여러개의 엔터티와 연관된 경우에 해당한다.

 

ex) 하나의 템 엔터티는 여러개의 멤버 엔터티를 가진다

 

N:M (@ManyToMany)

여러 엔터티가 여러 엔터티와 연관된 경우에 해당한다.

 

ex) 여러 학생은 여러 과목 엔터티를 가진다

 

연관관계는 항상 사용하는 것이 좋을까?

연관관계를 통해 객체지향 모델링이 가능해지고,

서비스 로직이 도메인 계층에 작성되어 Service코드가 간결해진다는 장점이 있다.

 

그러나,

지나친 연관관계로 모든 엔터티 간 결합이 발생하면

시스템을 파악하기 어려워지고

코드를 수정할 때 다른 코드에 영향을 끼치게 되어 유지보수에 어려움을 줄 수 있다.

 

짧은 회고

SQLD를 공부할 때 배웠던

엔터티 간 관계를 적용할 수 있는 시간이었다.

배웠던 개념이 실제 어떻게 구현되는지 확인할 수 있어 유익했다.

 

좋은 코드가 작성되기 위해 적절한 DB모델링이 수반되어야함을 깨달았다.

 

Day 11: 기본적인 배포를 위한 준비

배포 (Deployment)

서비스를 만든 로컬의 모든 환경 및 소스코드를 서버 컴퓨터에 옮겨 실행하는 작업

 

Profile

local, dev로 나누어 DB 적용

 

똑같은 코드를 실행시켜도 Profile 설정에 따라 실행시 설정을 다르게 할 수 있다.

 

Git, GitHub

Git은 버전 관리 소프트웨어로

로컬에서 프로젝트의 형상을 관리한다.

 

GitHub는 단순 원격 저장소로

프로젝트 공유, 협업, 배포 등에 활용된다.

 

익숙하게 써온 툴인만큼,

가볍게 점검할 수 있었다.

 

AWS의 EC2

AWS는 Amazon Web Service의 약자로,

클라우드 기반의 다양한 웹 개발 서비스를 제공한다.

 

EC2는 Elastic Compute Cloud의 약자로,

탄력적으로 사용할 수 있는 클라우드 컴퓨터를 제공한다.

 

'탄력적'이라는 뜻은,

원격에서 언제든 생성하고 제거할 수 있어 붙은 뜻이다.

 

EC2에서 컴퓨터를 할당받는 것을 인스턴스를 생성한다고 하는데,

원하는 옵션에 맞춰 인스턴스를 생성한다.

 

실제 현업에서처럼,

OS의 경우 Linux로 맞추는 것을 권장한다.

 

짧은 회고

회고라고 할 것도 없이 날로 먹은 기분이다.

 

Git, GitHub야 너무 익숙했고,

AWS도 결국 플랫폼일뿐이라는 것을 알게되니 그동안 왜 무서워했던걸까싶었다.

 

결국 낯설어서 어려워하는 것 뿐,

익숙해지면 별 거 아니다라는 사실을 오늘도 깨닫는다!

 

Day 12: AWS EC2 배포

Linux 환경에서 필요한 프로그램 설치

서버 컴퓨터는 대부분 리눅스로 사용하는 만큼,

리눅스에 대해 익숙해져야한다.

 

다행히(?) 리눅스마스터 자격증을 딸 때 공부해둔만큼,

반가운 마음으로 리눅스와 재회할 수 있었다.

 

Linux OS에서 Git, Java, MySQL을 설치해야하며

아래의 블로그 글에 미리 정리해두었다.

 

https://itaekit.tistory.com/14

AWS Linux 2023에서 Git, Java, MySQL 설치하기

 

Linux 환경에서 build, 실행

로컬에서는 Intellij를 통해,

자동으로 빌드 및 실행할 수 있었다.

 

그러나,

리눅스 환경에서는 개발자가 리눅스명령을 통해 빌드 및 실행을 해야한다.

 

Build on Linux

chmod +x ./gradlew
./gradlew build -x test
./gradlew clean

 

빌드를 위한 gradlew를 실행하기 위해 가장 먼저 권한 설정을 해야한다.

빌드 결과물을 지우기 위해서는 ./gradlew clean을 실행한다.

 

Run on Linux

java -jar {Path}/{파일명}.jar --spring.profiles.active={profile명}

 

빌드 결과물인 Artifact는

build/libs안에 ~.jar의 형태로 생성되어있다.

profile 지정까지!

 

java 명령어로 해당 jar를 실행하는 것으로 서버에서 애플리케이션을 동작시킬 수 있다.

 

짧은 회고

리눅스 마스터 따두길 잘했다...

리눅스가 이렇게 반갑고 재밌을 줄이야!

 

"현업에서 서버 컴퓨터는 리눅스로 배포하니..."

예전에 강의를 들을 때 이런 말을 들은 적이 몇 번 있었다.

 

그땐 뭐가 뭔지도 모르고 리눅스를 배웠었는데...

이젠 잘 알겠다!

 

Day 13: Spring Boot 설정

이전에는 그냥 따라만했던 설정에 대해 조금 더 알아보는 시간이었다.

 

build.gradle

gradle(build tool)을 이용해 프로젝트 빌드 및 의존성 관리를 위해 작성하는 Build Script이다.

빌드 스크립트에 작성하는 요소에 대해 하나씩 소개한다.

 

plugins

프로젝트에서 사용하는 플러그인 작성

 

group, version, sourceCompatibility

프로젝트 그룹명, 버전, JDK 버전에 대한 작성

version의 경우 빌드 결과물(.jar)의 확장명에 사용된다

 

repositories

외부 라이브러리, 프레임워크를 가져오는 실제 원격 저장소를 작성한다.

 

dependencies

프로젝트에서 사용하는 외부 라이브러리, 프레임워크에 대해 작성하는 부분이다.

 

Spring과 Spring Boot의 차이

Spring에서 Spring Boot로 넘어오며 아래의 이점들을 갖게된다.

 

1. 간편한 설정 : 복잡한 xml 지옥에서 벗어남
2. 쉬워진 의존성 관리
3. 강력한 확작성 : 다양한 starter를 지원, Tomcat(WAS)가 내장됨

 

application.yml (application.properties)

스프링 설정 파일에 해당

각각의 확장명에 따라 작성 포맷이 다름

 

짧은 회고

모른채 따라하기 바빴던 설정하는 법도

알게되니 별 거 아니였다!

 

사실 아무것도 모를 때 설정부터 배웠다면 감도 못잡았을텐데,

어느정도 사용법에 익숙해지고나서 배우니 "아 그게 이거였구나~" 하면서 깨닫게된다.

 

무조건 모르면 머리 싸매고 공부하는 자세보다,

일단 써보고 차차 알아가는 흐름으로 공부하는 자세를 좀 더 배워야할 것 같다.

 

Day 14: 마무리

강의 마지막날에는 조언과 꿀팁 소개 등 가벼운(?) 구성으로 진행됐다.

 

학습 방향성

첫번째,

스프링의 원리, 핵심 가치에 대해 학습이 필요하나,

그 전에 OOP 및 디자인 패턴에 대한 학습이 필요하다.

 

스프링에서 제공하는 다양한 모듈들 학습하기 전에,

CS 지식도 필요하다.

 

두번째,

클린 코드, OOP, 테스트 코드 관련 학습이 필요하다.

IT 대기업의 기술 블로그에 소개된 파일럿 프로젝트나 실습형 강의를 수강하는 것도 크게 도움이 된다.

 

세번째,

배포에 대한 학습이 필요하다.

배포 자동화에 대한 학습도 요구된다.

 

정리하자면,

스프링에 대한 기본 사용법을 배우게 되었으니 계속 심화 학습을 할 수 있지만,

본격적인 심화 학습에 앞서 필요한 기본 지식들을 빠르게 다져야할 것 같다.

 

짧은 회고

독학으로 준비하고 있는 내게

가장 어려운 것은 공부 그 자체보다 방향성이다.

 

그동안 너무나 많은 시행착오를 겪어왔기때문에,

방향을 설정하는 것이 얼마나 중요한지 정말 잘 알고있다.

 

강사님의 조언덕분에,

당분간의 스케쥴을 정할 수 있었다.

 

스프링 심화에 앞서 필요한 재료들을 빠르게 학습하고,

본격적인 스프링 학습으로 뛰어들어야겠다.

 

네번째 Online Session: 프로젝트 코드리뷰

마지막 온라인 세션이 진행됐다.

이번 세션에서는 기다리고 기다리던 코드리뷰가 진행되었고

나 포함 신청자 3명의 코드를 공개적으로 리뷰해주셨다.

 

칭찬받은 부분

package 설계를 잘했다고 칭찬받았다.

사실 설계를 의도했다기보다 강사님 어깨너머 봐왔던 코드를 최대한 따라하다보니 자연스레 나온 것 같다.

역시 고수의 코드를 배우고 체득하는 것은 큰 공부가 된다.

 

지도받은 부분

무척 감사하게도,

대부분의 코드에 대해 지도를 해주셨다.

 

1. @RequestMapping()에 직접 URL을 작성하기보다 web/ApiUrlConstants 클래스를 활용할 것 권장
2. Spring에 내장된 Tomcat은 멀티쓰레드로 동작하므로 동시성 문제에 대해 고려 필요
3. DTO 클래스를 만들 때 Record 클래스를 활용해 볼 것
4. Query 요청수는 성능에 크리티컬하므로 N+1문제에 대해 해결 필요
5. Entity 작성시 확장성을 위해 boolean(tinyint)로 설계하기보다 enum class를 활용해 볼 것

후...

단순히 기능만 구현해냈다고해서 만족했던 과거의 나 반성해라...!!

 

이제 정말 '좋은 코드'를 고민하고, 배워가야할 것 같다.

 

짧은 회고

코드리뷰를 신청하기전만해도,

기능 구현은 다 해놨기 때문에 자신있었다.

 

애초에 그렇게 어렵지 않은 기능들이었고,

내가 작성한 코드보다 좋은 코드가 나와봤자 얼마나 나올까? 하는 궁금증도 있었다.

 

뚜껑을 까보니,

사실상 모든 코드를 피드백받았다.

 

그리고 처음으로,

'좋은 코드'를 생각하는 사람에게 내 코드를 보여주면서 부끄러움을 느끼기도 했다.

 

기능 구현은 당연히 해내야하는 것이었고,

좋은 코드를 위해 필요한 CS지식, 코드 작성 방법 등에 대한 공부가 정말 많이 필요함을 느낄 수 있었다.

 

이번주 가장 유익한 시간이었다.

 

3주차 후기

스프링 사용, API 작성으로 바빴던 1,2주차와 다르게

3주차는 그동안 배운 내용 중 모르고 지나왔던 부분에 대한 보충,

작성한 코드를 배포하기 위한 툴을 배웠다.

일일 과제도 없어 학습 부담도 없었다.

 

역설적이게도,

가장 유익했던 한 주였다.

 

그동안 내가 극복하지 못했던 학습 스타일을 고치게되는 계기가 되었고

실제 서비스의 A-Z까지 맛보며 좋은 백엔드 개발자가 되기 위해 필요한 역량, 자세를 배울 수 있었다.

 

모든 강의와 라이브 세션이 끝났고,

이제 최종 프로젝트만이 남았다.

 

수료의 기준은 모두 통과했지만

코드리뷰받은 부분까지 다시 되새김질하며 프로젝트를 마무리할 계획이다.

 

3주간 정말 많이 배우고 성장했다!

수고했다 나!!!