spring 게시판 강의
이번주 강의 내용
author와 post 엔티티를 가진 게시판 서비스를 두고 본격적으로 springboot와 jpa강의가 시작되었다.
두 엔티티간의 연계를 위해 OneToMany, ManyToOne 어노테이션과 관련된 주요 옵션에 대해 강조했다. 연관관계의 주인이 누구인지, 지연로딩과 즉시로딩은 무엇인지, 그리고 N+1문제는 왜 발생하고 어떻게 해결해야 하는지에 대해 실습코드를 통해 확인해 보았다. OneToMany, ManyToOne, OneToOne 등 습관적으로 코드를 짜는 것은 어렵지 않을것이나, 이론적인 백그라운드가 있어야 면접에서 주요 이슈사항에 대해 대답할 수 있을것이므로 코드와 이론을 번갈아가면서 잘 정리하길 바란다.
테스트코드 작성을 통해 어떤 목적을 가지고 테스트코드를 작성하는지, 각 레이어별로 어떻게 격리환경을 만들어서 테스트를 할수 있는지에 대해 학습했고, 그 격리와 환경통제를 통해 특정 레이어만을 대상으로 테스트 하는 것이 어떤 의미가 있는지 강조했다. 실무에서는 api스펙을 정의하기 위해 postman, swagger, 문서화 등 여러 방법을 동원하지만 테스트코드자체만으로도 api스펙을 확인해 볼수 있으므로, 다양한 목적으로 테스트코드가 활용된다. 수강생들이 직접 프로젝트때 테스트코드를 제대로 한번 짜보는것도 프로젝트를 포트폴리오 목적으로 어필하기 좋은 방법이라고 생각된다.
데이터 조회과정에서 Paging처리를 하는 방법에 대해서도 다뤘다. Page객체, Pageable객체의 요소들에 대해 눈으로 확인했고, 해당 객체에서 어떤 값을 담을지와 어떤 응답값을 받을지, 그리고 그 값들을 화면에서 어떻게 활용할지에 대해 강조했다. pagination은 항상 프론트엔드와 백엔드간에 이슈가 되는 사항이고 성능상 문제를 발생시킬수 있는 부분이고, 조회서비스는 어디에나 있는 기능이므로 이 또한 프로젝트에 빠뜨리지 말고 적용시켜보길 바란다.
타이머처럼 때가 되면 트리거가 발동하여 동작하는 스프링 스케쥴러에 대해서도 다루었다. 예전에는 리눅스차원에 많은 크론job이 돌아갔지만, 현대적인 아키텍처에서는 과거 운영체제와 DB차원에서 별도로 작업하던 사항들을 프로그램에서 해결하는 방식이 훨씬 선호된다. 서버는 언제든 확장될수 있고, 클라우드 환경에서 리눅스 서버라는 것은 프로그램이 잠시 동작하는 일시적인 공간에 불과하기에 모든 기능을 프로그램중심 또는 객체중심으로 처리하는 것이 더 이상적인 아키텍처라고 생각된다.
스케쥴러처럼 배치(batch)도 실무에서 많이 사용하는 서비스이다. 특히, 대규모 데이터처리를 위해 사용되는데 시간관계상 우리 수업에서 다루진 않았지만 말로 설명해보자면, 스케쥴러를 만들고 batch job을 정의한다. 이때의 batchjob은 step별로 시나리오 별로 작업을 정의한다. 스케쥴러의 크론이 특정 시간이 되면 batch job에 trigger를 발동시키고, batchjob은 정의돼있는 많은 작업을 단계별로 실행하게 된다. 실패했을경우를 커버할수 있는 다양한 시나리오를 고민해서 대용량 데이터처리과정에 발생할수 있는 예상치 못한 상황을 잘 커버하여 프로그램을 작성해야 한다.
차주 수업 계획
마지막 주에는 웹서비스에서 가장 중요한 부분 중 하나인 로그인 서비스에 중점을 두고 수업을 진행할 예정이다.
먼저, mvc에서 쿠키와 세션을 활용한 로그인이 진행된다. 그 후 restapi로 설계된 서버에서 jwt토큰을 사용한 로그인을 진행할 예정이다. 대표적인 로그인 방식인 세션/토큰 방식을 각기 다른 아키텍처에서 구현할 예정이다. 세션을 다룰때에는 세션에서의 단점으로 여겨지는 단일서버 의존성으로 인한 문제점을 개선하기 위해 redis를 도커를 통해 도입하여 redis 세션도 구현할 예정이다.
세션, 토큰에 대해 제대로 배우려면 http통신에 대한 이해가 필수이고, 암호화의 원리에 대한 이해도 필요하므로 이에 대한 부분 별도강의도 진행한다.
로그관리를 위한 몇가지 전략에 대해서도 학습할 예정이다. 먼저 기초적인 로그레벨 관리방법부터 파일시스템에 로그파일을 날짜별로(또는 로그종류별로) 관리하는 logback설정, aop를 활용한 로깅전역관리도 배울예정이다.
프로그램 전역에서 발생할수 있는 404, 500에러 등을 공통으로 처리하기 위 ControllerAdvice를 배워 예외처리의 공통화 작업을 진행한다.
스프링프로젝트의 마무리로서 order system을 수강생들이 직접 개발해볼수 있도록 숙제를 내주었다. 전형적인 crud는 몇번해보았으니, 주문관리시스템에서는 n:m관계성을 풀어낼수 있도록 order_item 엔티티를 정의하고 활용하는데 중점을 두고자 한다. 주문을 할때에 cascading 또는 더티체킹을 통해 소스코드를 단순화하고 가독성을 올릴수 있는 부분에 중점을 두고 수업을 진행하고자 한다. 또한 이 repository에서는 최대한의 클린코드를 지향하여 스프링의 최종수업을 마무리하고자 한다.