[인프런 워밍업 클럽 BE 2기] 백엔드 프로젝트 - 4주차 발자국

마지막 주차인 4주차는 지금까지 개발한 어디민 페이지의 뷰를 개발하였고, 스프링 시큐리티를 이용한 로그인 개발, 로그 저장 등의 기능을 구현 하였다. 프로젝트를 마무리 짓고 최종적으로 docker와 구글 클라우드를 이용해서 배포를 하였다. 어드민 화면 개발 1부트스트랩 템플릿 적용 시 코드 분석 및 TODO 체크 기능 해제: 부트스트랩 템플릿을 사용해 UI를 구성할 때 코드 변경 사항이 많아 analyze code와 check TODO 기능이 오래 걸려, 이를 해제하여 커밋 및 푸시 시간을 줄임.사이드바 개발에서 th:classappend, th:attr data-bs-target, th:classappend show 사용: Thymeleaf의 th:classappend를 이용해 동적으로 클래스를 추가하고, th:attr을 통해 부트스트랩의 data-bs-target 속성을 설정하여 UI 요소를 제어함. show 클래스를 사용해 사이드바를 열고 닫는 동작을 구현.뷰 레이아웃 개발 및 테이블 페이지(Table) 구현: HTML 템플릿에서 레이아웃을 설계하고, 데이터가 표시될 테이블 형태의 페이지를 구성. 이를 통해 표 형태로 데이터를 보기 쉽게 표시./* 구문 사용과 [[${pageName}]] 바인딩: Thymeleaf에서 스크립트를 안전하게 사용하기 위해 CDATA 구문을 사용하고, ${pageName}을 통해 페이지 이름을 동적으로 바인딩하여 화면에 표시.테이블 아이디 tableName 설정: HTML에서 테이블을 식별하기 위한 아이디를 tableName으로 설정하여 JavaScript 등에서 쉽게 접근 가능하도록 함. 어드민 화면 개발 2테이블 페이지(Form) 개발: 사용자가 데이터를 입력하고 제출할 수 있는 Form 페이지를 구성. 입력된 데이터를 서버로 전송하고 처리하는 역할을 함.onsubmit : Form이 제출되기 전에 특정 JavaScript 함수를 실행하여 데이터를 검증하거나 추가 작업을 수행할 수 있게 해주는 이벤트.대시보드와 로그인 기능 개발스프링 시큐리티를 이용한 로그인 개발: 스프링 프레임워크에서 제공하는 시큐리티 모듈을 사용해 사용자 인증 및 권한 관리를 구현. 안전한 로그인 기능을 제공.패스워드 인코더 및 필터 체인 개발: 패스워드 보안을 위해 PasswordEncoder를 사용해 비밀번호를 암호화하고, 인증 과정을 제어하기 위해 필터 체인을 설정함.AntPathRequestMatcher 사용: 특정 URL 경로와 HTTP 메서드에 대해 시큐리티 필터링을 설정하는 데 사용. 로그아웃 등의 특정 경로에 대해 시큐리티를 설정할 때 유용함.구글 클라우드 플랫폼으로 프로젝트 배포Docker로 MySQL 실행 및 컨테이너 설정: Docker 이미지를 사용해 MySQL 데이터베이스를 컨테이너로 실행하고, 필요한 포트와 환경 변수를 설정하여 데이터베이스를 관리.ports, command, volumes 설정:ports: 호스트와 컨테이너 간의 포트를 매핑하여 외부에서 데이터베이스에 접근할 수 있도록 함.command: 컨테이너가 시작될 때 실행할 명령어를 정의. 예를 들어, MySQL의 문자 집합을 설정하는 명령어를 추가.volumes: 컨테이너의 데이터가 호스트에 영구적으로 저장되도록 설정하여 컨테이너 재시작 시 데이터가 손실되지 않도록 함.프로젝트 컨테이너 설정 및 depends_on 사용: Spring 애플리케이션을 실행하는 컨테이너와 데이터베이스 컨테이너를 설정하고, depends_on을 통해 MySQL이 먼저 실행된 후 애플리케이션이 실행되도록 순서를 지정.호스트 포트 (Host Port): 호스트 컴퓨터에서 사용되는 포트입니다. 예를 들어, 3306:3306에서 앞의 3306이 호스트 포트입니다. 이는 Docker를 실행하는 컴퓨터에서 접근 가능한 포트 번호를 의미합니다. 다른 컴퓨터나 서버에서 이 호스트의 IP 주소와 포트를 사용하여 Docker 컨테이너의 서비스에 접근할 수 있습니다.컨테이너 포트 (Container Port): 컨테이너 내부에서 서비스가 실행되는 포트입니다. 3306:3306에서 뒤의 3306이 컨테이너 포트입니다. 이는 컨테이너 내부에서 MySQL 서비스가 동작하는 포트를 의미합니다. 컨테이너 내의 애플리케이션은 이 포트를 통해 데이터베이스와 통신합니다.Docker로 프로젝트 빌드Google Cloud Platform에서 Compute Engine 인스턴스 생성: 애플리케이션을 배포할 가상 머신을 생성하여, Docker 컨테이너를 실행할 환경을 제공.도커 허브로 푸시 시 커맨드로 진행: Docker Desktop에서 푸시 시 발생하는 오류를 해결하기 위해 명령어를 사용하여 직접 푸시.Compute Engine에서 도커 컨테이너 실행: Google Cloud에서 생성한 인스턴스에 도커 컨테이너를 실행하여 애플리케이션을 운영.메모리 스왑 설정 및 Nginx 사용: 하드디스크의 일부를 메모리처럼 사용하는 메모리 스왑을 설정하고, Nginx를 사용해 애플리케이션의 로드 밸런싱 및 리버스 프록시 역할을 설정.도메인 연결 및 HTTPS 적용: 애플리케이션에 도메인을 연결하고 SSL 인증서를 적용하여 HTTPS를 통해 안전하게 서비스.[미션 6] MySQL에 내 데이터 넣기문제 상황: Docker로 실행한 MySQL과 DBeaver에서 연결된 데이터베이스의 내용이 달랐음.원인: 과거 MariaDB 사용 이력이 있어, MariaDB와 MySQL이 서로 다른 포트로 연결되어 데이터가 불일치.DBeaver에서는 MariaDB에 연결되고, Docker에서는 MySQL에 연결되는 상황 발생.해결 방법: MariaDB의 서비스를 중단하여 MySQL만 실행되도록 설정하여 문제를 해결.[미션 7] 내 포트폴리오 도메인 공유하기문제 상황: Google Cloud Compute Engine에서 Docker Hub의 이미지를 pull하려 했으나, Docker push가 되지 않아 pull이 실패.원인: Docker Desktop 4.3.3 버전 이후로, Docker Desktop을 통한 push에서 오류 발생.해결 방법: Docker Desktop 대신 명령어를 사용해 push하여 문제를 해결.

[인프런 워밍업 클럽 BE 2기] 백엔드 프로젝트 - 3주차 발자국

이번 주차에서는 포트폴리오 사이트 화면과 어드민 기능을 개발하며, 사이트의 삽입, 수정, 조회 API 구현과 인터셉터 설정을 완료하였다. 타임리프와 부트스트랩을 활용한 뷰 템플릿 구성, 데이터 처리, 예외 관리 등 다양한 기능을 학습하며 웹 개발의 전체적인 흐름을 이해할 수 있었다. 포트폴리오 사이트 화면 개발하기 1RestController와 Controller의 차이점RestController: JSON 데이터를 반환하며, 주로 RESTful API를 구현할 때 사용. HTML 뷰 템플릿을 반환하지 않음.Controller: HTML 등 뷰 템플릿을 반환하기 위해 사용.부트스트랩과 타임리프 프래그먼트 사용부트스트랩 템플릿 적용: 부트스트랩 사이트에서 템플릿을 다운로드하여 프로젝트에 적용.타임리프 프래그먼트 사용: head, footer, navigation 등의 공통 영역을 분리하여 프래그먼트로 구성.th:fragment: 프래그먼트의 이름을 지정해 원하는 곳에서 재사용.th:replace: 프래그먼트를 뷰 파일에 포함할 때 사용.타임리프 문법 활용th:each: 컨트롤러에서 전달된 모델 데이터를 반복하여 출력.th:text: 서버 데이터를 HTML 요소에 텍스트로 삽입.target="_blank": 링크 클릭 시 새 탭에서 열리도록 설정.포트폴리오 사이트 화면 개발하기 2동적 콘텐츠와 레이아웃 처리th:fragment에 파라미터 전달: 프래그먼트에 파라미터를 전달해 동적 콘텐츠를 처리.th:block 사용 이유: 불필요한 태그 없이 블록을 형성해 th:each와 조건부 렌더링(th:if)을 함께 사용하기 위함.d-inline 태그: 인라인 요소로 배치하여 레이아웃 조정을 쉽게 함.레이아웃 작업: 공통 레이아웃을 th:fragment로 정의해, 수정 시 모든 페이지에 자동 반영되도록 구성.인터셉터의 역할과 설정인터셉터: 컨트롤러보다 앞단에서 동작하며, 여러 컨트롤러의 요청을 잡아 공통적인 처리를 수행.addInterceptors 오버라이딩: WebMvcConfigurer에서 인터셉터를 등록할 때 사용.모든 경로를 대상으로 하며, 정적 자원 경로(CSS, JS 등)는 제외.presentationInterceptor의 HandlerInterceptor 추가:preHandle: 컨트롤러에 도달하기 전 실행.postHandle: 컨트롤러의 응답 후 실행되나, 예외가 발생하면 동작하지 않음.afterCompletion: 예외 발생 여부와 상관없이 항상 실행.HttpInterface 사용: 클라이언트 정보를 수집해 기록.어드민 공통 기능 개발하기클래스 생성 및 관리admin 패키지: 컨트롤러, 데이터 처리, 예외 처리, 인터셉터, 보안 관련 클래스를 구성.예외 처리와 로깅Throwable: 모든 오류의 최상위 클래스.Error: 복구할 수 없는 오류.Exception: 애플리케이션이 복구 가능한 오류.Checked Exception: 컴파일 시점에 예외가 검출됨.Unchecked Exception: 런타임 시점에 발생.ControllerAdvice: 인터셉터와 유사하게 동작하며, 예외 처리를 담당.@ExceptionHandler: 특정 예외를 처리하는 메소드.Logger 사용: LoggerFactory.getLogger를 활용해 로그를 기록.DTO 개발companion object: 클래스 내부에서 정적 메소드와 변수를 정의할 때 사용.vararg: 가변 인자를 받아 여러 파라미터를 전달할 수 있도록 함.filterings: 데이터에서 제외할 필드를 관리.classInfo: 클래스의 메타데이터와 정보를 담음.인터셉터 추가postHandle 오버라이딩: 메뉴 데이터를 modelAndView에 추가해 특정 페이지에 전달.addInterceptors 설정: admin 경로에 인터셉터를 추가하며, 정적 자원(CSS, JS 등)은 제외.데이터 조회 기능 개발하기조회 기능 구현context 패키지: 화면과 관련된 설정을 서버에서 관리.orElseThrow: 데이터가 없을 경우 예외를 발생.@field: 필드 유효성 검사를 수행.@PathVariable: 경로 변수를 통해 데이터를 전달.@RequestBody: 요청 본문 데이터를 객체로 변환.@Validated: 입력 데이터의 유효성을 검사.데이터 삽입, 수정, 삭제 기능 개발하기DTO와 데이터 처리form 패키지: DTO 역할을 하는 클래스들을 생성해 데이터 전달에 활용.ifPresent 사용ifPresent: 값이 존재할 때만 특정 동작을 수행하도록 처리.[미션4] 조회 REST API 만들기이번 미션에서는 제품, 브랜드, 카테고리, 재고에 대한 조회 API를 개발하고, 각 경로(/api/products, /api/brands, /api/categories, /api/stocks)에 대해 테스트 코드를 작성하였다.이번 미션에서는 조회 API 개발 및 테스트 코드 작성을 통해 RESTful API의 기본 구조를 익히고, Null 처리와 영속성 관리를 경험하였다. 특히 **?.let {}**과 ?: 엘비스 연산자를 활용해 null-safe한 코드를 작성하는 방법을 익혔으며, 서비스 계층 분리를 통해 더 효율적인 설계를 계획하게 되었다.ProductDTO에서 발생한 Null 처리 이슈와 해결조회 API를 구현하는 과정에서 ProductDTO 내의 brand와 category가 null일 경우 NullPointerException이 발생하는 문제가 발견되었다. 이를 해결하기 위해 ?.let {} 구문을 사용해 null-safe하게 처리하였다.?.let {}의 역할?.let {}: 객체가 null이 아닐 때만 코드 블록 내부를 실행한다.예시:brand = product.brand?.let { BrandDTO(it) }product.brand가 null이 아닐 경우에만 BrandDTO를 생성하고, 그렇지 않으면 실행되지 않음.엘비스 연산자(?:) 사용조회 로직에서는 **엘비스 연산자 ?:**를 사용하여, 값이 null일 경우 대체 동작을 수행하도록 하였다.?: 연산자: 왼쪽의 값이 null이면 오른쪽 값을 반환한다. product = stock.product ?: throw IllegalArgumentException("제품정보를 찾을 수 없습니다..")만약 stock.product가 null이면 IllegalArgumentException을 던지도록 처리.영속성 설정: Cascade = PERSIST재고와 관련된 엔티티를 영속성 컨텍스트에 포함시키기 위해, cascade = PERSIST 옵션을 사용하였다. 이 설정은 엔티티가 함께 영속화될 수 있도록 보장하며, 이를 통해 테스트 코드가 문제없이 성공적으로 실행되었다.재고 수량 설정과 서비스 계층 분리 계획현재 재고 테이블의 재고 수량(stockCount) 설정은 Stock 엔티티의 메서드를 통해 처리하고 있다.하지만, 이 로직을 추후 삽입 및 수정 API에서 더 깔끔하게 관리하기 위해 서비스 계층으로 분리할 계획이다.

[인프런 워밍업 클럽 BE 2기] 백엔드 프로젝트 - 2주차 발자국

1주차에는 간단한 엔티티와 프로젝트 구조 작성을 완료하고, 이번 주에는 리포지토리, DTO, 서비스 계층을 전반적으로 개발했으며, 그 과정에서 테스트 코드도 함께 작성했다. 이를 통해 프로젝트의 핵심 기능들을 구조화하고, 안정성을 높이는 데 중점을 두었다. 데이터를 다루는 리포지토리 개발하기리포지토리 개발을 하였으며 역시 1주차와 달리 혼동스러운 어노테이션 및 개념과 처음 접하는 어노테이션 및 개념들이 나왔었다. 하나하나 상세히 어떤 역할을 하는지 강의에서 알려주셔서 따라가는데 문제 없었으나, 중간에 오류가 한번 발생하여 찾아보니 JPA영속성 관련 부분이였다.Projectskill에 데이터가 들어가지 않아 확인을 해보니 project 엔티티에서 skill 부분에 cascade 부분을 빼먹어서 함께 저장이 되지 않았다.1. Spring Component와 Bean 등록Component Bean 등록:스프링에서는 @Component, @Controller, @Service, @Repository 어노테이션을 통해 클래스를 Bean으로 등록@Component: 기본적인 스프링 컴포넌트 등록 어노테이션.@Controller: 웹 컨트롤러 계층에 사용, 요청을 처리하는 클래스.@Service: 서비스 계층에 사용, 비즈니스 로직을 처리하는 클래스.@Repository: 데이터 접근 계층에 사용, 데이터베이스와 상호작용하는 클래스.이들은 모두 @Component를 상속한 어노테이션으로, 역할에 따라 더 구체적으로 분류@ComponentScan:스프링이 애플리케이션을 시작할 때, 이 어노테이션을 사용하여 해당 패키지나 하위 패키지에서 컴포넌트를 스캔하고, DI(의존성 주입)를 위해 Bean으로 등록2. 스프링 프로파일과 @Profile 어노테이션@Profile:스프링에서 다양한 환경 설정을 관리할 때, 특정 프로파일이 활성화된 경우에만 빈(Bean)을 활성화할 수 있도록 하는 어노테이션예를 들어, @Profile("dev")는 "dev" 프로파일이 활성화될 때만 해당 빈이 등록3. 생성자 주입과 Bean 관리생성자 주입 방식으로 의존성을 주입받아 사용하는 것이 권장. 생성자 내부에서 미리 정의된 Bean을 주입받아 사용하고, 이 과정에서 스프링이 의존성 관리를 담당.@PostConstruct:Bean이 스프링 컨테이너에 등록된 후 실행되는 메서드에 붙일 수 있는 어노테이션. Bean의 초기화를 마친 후 로직을 처리할 때 사용.4. 로그 사용 권장System.out.println()은 성능상 좋지 않으며, 멀티 쓰레드 환경에서 비효율적이기 때문에 로그 라이브러리를 사용하여 로그를 남기는 것이 좋다.5. JPA와 영속성 관리 (Cascade)Cascade: JPA에서 엔티티의 상태 변화에 따라 연관된 엔티티도 함께 변경되도록 하는 옵션.CascadeType.PERSIST: 엔티티를 저장할 때 연관된 엔티티도 함께 저장.CascadeType.MERGE: 엔티티를 병합할 때 연관된 엔티티도 함께 병합.CascadeType.REMOVE: 엔티티를 삭제할 때 연관된 엔티티도 함께 삭제.CascadeType.REFRESH: 엔티티를 새로고침할 때 연관된 엔티티도 함께 새로고침.CascadeType.DETACH: 엔티티가 영속성 컨텍스트에서 분리될 때 연관된 엔티티도 분리.CascadeType.ALL: 모든 작업(PERSIST, MERGE, REMOVE, REFRESH, DETACH)에 대해 적용.예를 들어, Project 클래스에서 ProjectSkill 엔티티와의 연관관계에 CascadeType.PERSIST를 설정하지 않으면, Project가 저장될 때 연관된 ProjectSkill이 함께 저장되지 않을 수 있다. 6. JPA 성능 개선 (findById 오버라이딩)JpaRepository의 findById 메서드를 오버라이드하여 성능을 최적화할 수 있습니다. 예를 들어, 특정 조건에 맞는 쿼리를 커스터마이징하여 데이터베이스 성능을 개선할 수 있습니다.이러한 요소들은 스프링 애플리케이션 개발에서 빈 관리, 의존성 주입, JPA를 통한 데이터베이스 영속성 관리를 포함한 다양한 개발 과정에서 중요한 역할을 합니다. 리포지토리 테스트 하고 성능 개선하기개발한 리포지토리가 제대로 작성 되는지 테스트코드를 작성하였으며, 또한 리포지토리의 성능을 개선하기 위해 JPQL을 따로 작성하여 fetch 전략으로 LAZY를 사용하여도 깔끔하게 출력되게 개선하였다.리포지토리 테스트 코드 작성@TestInstance.Lifecycle.PER_CLASS: 메서드 간 독립적인 실행이 가능하며, 메서드 간 의존성이 제거됨.의존성 주입: 테스트 시 필요한 리포지토리나 서비스 등을 주입받아 테스트를 진행. 테스트 데이터 초기화: @BeforeAll을 사용하여 테스트에 필요한 데이터를 사전 생성. 프록시 객체와 Fetch 전략프록시 객체: JPA에서 연관된 엔티티를 가짜 객체로 생성하여 필요할 때만 데이터베이스에서 불러옴.LAZY 로딩: 필요할 때마다 쿼리를 날려 데이터를 가져옴. 하지만, 반복문을 돌 때마다 SELECT 문이 나가 성능 저하가 발생할 수 있음.EAGER 로딩: 한 번에 모든 연관된 엔티티를 조회하지만, 불필요한 데이터를 미리 가져올 경우 성능에 영향을 미칠 수 있음.3. Fetch Join과 N+1 문제 해결Fetch Join: JPQL에서 사용하여 연관된 엔티티를 한 번의 쿼리로 모두 조회하는 방법.장점: 추가적인 쿼리가 발생하지 않아 성능 최적화가 가능.단점: 필요 없는 데이터를 미리 가져올 경우 메모리 낭비 가능.N+1 문제: Lazy 로딩 시 발생하는 성능 문제로, 하나의 엔티티를 조회할 때 연관된 엔티티를 각각 추가 쿼리로 조회하여 비효율이 발생. Fetch Join으로 이 문제를 해결 가능. 4.Assertions의 assertThatassertThat: 테스트 코드에서 검증을 위한 메서드로, 다양한 조건에 맞는 검증을 수행할 수 있음.isEqualTo(): 두 값이 같은지 비교.isTrue() / isFalse(): 조건이 참인지, 거짓인지 확인.hasSize(): 리스트나 배열의 크기를 검증.contains(): 리스트가 특정 값을 포함하는지 확인.데이터를 조회하고 변환하는 서비스 개발하기도메인 패키지와 연결된 presentation 패키지를 생성하였고, 해당 패키지 안에 클래스, DTO, 리포지토리, 서비스 개발을 완료하였다. 또한, 서비스에 대한 테스트 코드도 작성했다.이번에는 도메인에서 개발했던 리포지토리 테스트와 달리 단위 테스트가 아닌 방법으로 개발하였다. 기존까지 나는 개발 환경에서 페이지를 띄운 후 하나하나 수동으로 테스트를 진행했지만, 이러한 방식은 운영 서버에서 테스트하기 어렵다는 단점이 있었다.따라서 테스트 코드를 작성하여 자동화된 방식으로 테스트하는 것이 실무적으로 더 안정적이라고 한다.1. @RestController로 REST API 구현@RestController: 스프링에서 RESTful 웹 서비스를 만들 때 사용하는 어노테이션으로, 컨트롤러에서 반환하는 데이터를 자동으로 JSON 형식으로 변환해 클라이언트에 전달한다. 주로 API 응답에서 사용되며, HTML이 아닌 데이터를 반환한다.2. @GetMapping과 @RequestMapping@GetMapping: HTTP GET 요청을 처리하는 어노테이션으로, @RequestMapping(method = RequestMethod.GET)의 간편한 대체 방식이다. 이를 통해 서버는 클라이언트의 GET 요청에 대해 데이터를 조회하고 응답할 수 있다.3. DTO (Data Transfer Object)DTO: 데이터 전송 객체로, 서버와 클라이언트 간 데이터를 주고받기 위한 객체다. 비즈니스 로직을 포함하지 않고 데이터의 전송에만 집중되어 있으며, 데이터를 안전하고 일관되게 전달하는 데 사용된다.4. Mockito와 @InjectMocks로 의존성 주입Mockito: 단위 테스트에서 실제 객체 대신 Mock 객체를 사용하여 독립적인 테스트를 가능하게 해주는 테스트 라이브러리이다. 이를 통해 외부 의존성을 최소화한 테스트를 할 수 있다.@ExtendWith(MockitoExtension::class): JUnit5와 Mockito를 통합해, 테스트 환경에서 Mock 객체의 자동 주입을 제공하는 어노테이션이다. 테스트 클래스에서 의존성 주입을 자동으로 처리하며, 의존성을 가진 객체들을 쉽게 Mocking할 수 있다.@InjectMocks: Mock 객체를 주입받아 의존성을 가진 객체를 독립적으로 테스트할 수 있도록 하는 어노테이션이다. Mock 객체를 통해 실제 객체 없이도 테스트할 수 있어, 테스트의 독립성과 효율성을 높여준다.미션 3REST API 설계하기이번 미션에서는 설계한 테이블을 기반으로 REST API를 설계하는 작업을 진행했다. 상품 API, 분류 API, 브랜드 API, 재고 API를 설계했으며, 각 API의 기능을 세부적으로 구현하였다.분류와 브랜드 API에서는 삭제 대신 useYn 필드를 변경하여 비활성화하는 API를 설계했다. 즉, 데이터를 완전히 삭제하지 않고 비활성화 상태로 변경하는 방식이다.재고 API에서는 재고 삭제 API를 설계하지 않았고, 재고를 수정할 때 기존 데이터를 수정하는 대신 새로운 데이터를 생성하여 수정 이력을 로그처럼 남길 수 있도록 설계했다.또한, HTTP 메서드 중 PUT과 PATCH 메서드의 차이점에 대해 고민했는데, 두 메서드의 차이는 다음과 같다:PUT: 전체 리소스를 대체하거나 새로 생성하는 데 사용된다.PATCH: 리소스의 일부만 수정하는 데 사용되며, 부분적인 변경에 적합하다.https://github.com/Malvin222/mission-backoffice

[인프런 워밍업 클럽 BE 2기] 백엔드 프로젝트 - 1주차 발자국

새로운 프로젝트 아이디어를 찾다가 인프런에서 위밍업클럽 2기를 시작한다는 소식을 듣고 신청하게 됐다. 강의 목록 중 특히 끌리는 강의가 있었고, 코틀린을 사용하는 점도 마음에 들었다. 그동안 코틀린을 접해본 적이 없어서 배우고 싶은 마음도 컸고, 새로운 기술들을 익히면서 동시에 다양한 사람들과 네트워킹을 할 수 있다는 부분이 마음에 들었다. 프로젝트 미리보기 + 웹 개발 기본 개념이번 강의에서는 웹 프레임워크, HTTP, 그리고 REST API와 같은 웹 개발의 기본 개념을 간략하게 학습했다.강의 시간이 짧아서 깊이 있는 설명은 없었지만, 웹 개발에서 필수적인 기초 개념을 알기 쉽게 설명해주었다. 덕분에 그동안 혼란스러웠던 부분들이 정리되었고, 전체적인 웹 개발의 기본 흐름을 이해할 수 있었다. 프로젝트 시작하기 + 데이터베이스 기본 개념데이터베이스와 JPA에 대해 이론적으로 학습하고, 실습으로 테이블 설계와 개발 환경을 구성하여 프로젝트를 시작했다.이전에는 주로 마이바티스(MyBatis)를 사용해 DB와 연결했지만, JPA에 대해서는 개념만 알고 있었다. 이번 강의를 통해 JPA의 기본 개념과 동작 방식을 명확히 이해하게 되었고, Spring Initializr 사이트를 통해 강의에서 사용할 개발 환경을 설정하고 프로젝트를 생성했다. 프로젝트 기초 설정하기코드 형상 관리를 위해 git과 GitHub를 사용하는 방법을 학습했다.또한, 생성된 프로젝트를 GitHub에 연결하고, 기본적인 상수 클래스, 리포지토리 클래스, 엔티티 클래스를 생성하였다.불필요한 파일들이 추적되지 않도록 .gitignore 파일을 설정하였고, 이 작업은 gitignore.io에서 현재 개발 환경에 맞는 설정을 자동으로 생성하여 적용했다.추가로, application.properties 설정 파일을 application-default.yml과 application-docker.yml로 나누어 개발 서버와 운영 서버에서 각각 다른 환경 설정을 적용하였다. H2와 MySQL 중 하나를 선택하여 각 서버에 맞게 설정했다. 프로젝트의 뼈대 엔티티 개발하기설계한 테이블을 바탕으로 엔티티(Entity)를 개발했다. 기본적으로 BaseEntity와 프로젝트에 필요한 여러 엔티티를 작성하였다.JPA와 코틀린을 처음 접해 생소한 부분도 있었지만, 자바에 대한 기본 지식 덕분에 비교적 빠르게 적응할 수 있었다. 연관관계가 있는 엔티티와 없는 엔티티를 나누어 개발하면서 새로운 어노테이션도 많이 사용했는데, 강의에서 해당 어노테이션에 대한 설명이 명확해서 어려움 없이 따라갈 수 있었다. 미션 1 + 21:N테이블 설계하기, 깃허브 리포지토리 만들기1주차에서 배운 내용을 바탕으로 서브 프로젝트의 GitHub 리포지토리를 만들고 테이블을 설계하는 미션을 수행했다.GitHub 리포지토리 생성은 문제없이 따라갔으나, 테이블 설계에서는 과연 내가 올바르게 하고 있는지 의구심이 들었다.적은 수의 테이블을 설계하는 것조차 여러 요인을 고려해야 했고, 설계한 테이블들이 적합한지 확신이 서지 않았다.우선 테이블을 설계하고, 프로젝트를 진행하면서 고려하지 못했던 부분이나 잘못 설계된 부분은 수정해나가기로 생각하였고, 이 과정에서 배운 점들을 기록하며 앞으로 개선해나갈 예정이다.https://github.com/Malvin222/mission-backoffice