[우테코] 레벨로그: 레벨2 동안 공부한 내용들을 정리하며

⭐ 레벨2 인터뷰를 준비하며

 

약 두 달 간의 레벨2 과정을 마치고, 다시 레벨 인터뷰가 왔다. 

내가 공부한 내용들을 정리해보는 글이다. 

 

 

💋 레벨 도중 진행한 미션에 대한 회고

 

웹 자동차 경주 회고

[우테코] 웹 자동차 경주 1단계 회고: 안녕 스프링? Spring을 처음 만난 2일간의 기록

 

장바구니 미션 1단계 회고

[우테코] 장바구니 미션 1단계 회고(feat. 현구막): 우당탕탕 스프링 공부하기! 자세한 내용은 목차

 

지하철 미션 회고

[우테코] 지하철 미션 회고: 지하철 미션인데 리뷰어도 서브웨이, 나는 우당탕탕

 

장바구니 협업 미션 회고

 

 

---

 

 

💋 과정 전반에 대한 이야기

 

스프링 처음 공부하는 입장에서 첫 두 달을 어떤 내용을 공부해야 할까 잠깐 막막했었다.

금방 방향성을 잡았는데, 레벨2 학습 키워드로 우테코에서 제시한 내용들을 익히고, 내 코드에 활용할 수 있도록 하자는 것이 내 목표였다.

어떻게 보면 목표는 잘 달성한 것 같다...! (매우 잘한건가?!!?!)

살짝의 걱정은, 내가 공부한 내용이 지금 다시 돌아보니 벌써 당연한 내용이 되어버려서, 인터뷰에서 할 말을 잘 정리하기가 어렵다!

 

공부법에 대해 생각해보자면, 이번 레벨에서는 꾸준히 블로그에 내가 공부한 내용에 대한 글을 작성하는 방식으로 공부를 해왔다. 

잘못된 내용이 있던 적도 있지만, 다른 크루로부터 피드백을 받아서 오히려 제대로 된 내용을 알 수 있는 계기가 되었고, 크루들과 함께 논의한 내용을 블로그에 적다 보니깐 더 적극적으로 다른 크루들과 소통할 수 있었던 것 같다.

전반적으로 내가 하던 고민들의 대답은 "팀에서 정하면 됩니다."인 경우가 많았는데, 그만큼 팀 내에서 정한 규칙을 따르는 것이 좋은 방법일 때가 많다고 느꼈다. 

 

 

 

💋 스프링 기초 지식 익히기

 

✔ Spring DI

 

스프링이 어떻게 자바 객체를 관리하는 지에 대해서 전반적으로 학습했다. 

 

스프링이 돌아가는 순서에 대해서 대략적으로 알게 되었고, 이제는 에러 메세지를 보고 Bean과 관련된 에러인 경우에 대략적으로 감을 잡을 수 있는 정도가 되었다. 

 

스프링은 ApplicationContext의 종류에 따라서 선택적으로 XML, Java Config 파일, 혹은 자바 어노테이션을 보고 빈으로 등록할 객체들을 파악한다. 각 객체들에 대한 생성에 대한 책임을 스프링이 내 프로젝트 소스 코드의 완전히 바깥으로 빼내 준다는 점에서 스프링의 DI는 의미가 있다. 

 

어노테이션을 간단히 붙이면서 어노테이션 이름을 통해서 내 프로젝트 내에서 해당 빈이 어떤 역할을 하는지 표시할 수 있고(@Controller, @Service 등), 때에 따라서 특정 기능이 추가적으로 부여된다(@Repository). 또 내가 직접 코드를 수정할 수 없는 외부 라이브러리의 클래스에 대해서는 config 파일을 통해서 빈으로 등록할 수 있다. 

 

다음으로는 스프링 애플리케이션에서 의존성을 주입하는 방법 대략 3가지에 대해서 공부를 했고, 결과적으로 프로덕션 코드에서는 생성자 주입 방식을, @SpringBootTest와 같은 테스트 코드에서는 필드 주입 방식을 사용하기로 했다. (지금은 습관처럼 사용하게 됨)

Lombok처럼 프로덕션 코드에서 생성자 주입 방식 + private final 제어자를 사용할 때 편리한 방법도 있지만, 현재는 사용하고 있지는 않다.

 

 

✔ Exception Handler

 

또 스프링에서 예외에 대한 공통 처리에 대해서는 @ControllerAdvice를 사용한다는 것을 배워서, 애플리케이션에서 광역적으로 예외를 처리하게 되었다. 

 

이전까지는 내가 정의한 클라이언트 측의 잘못으로 인한 예외 상황들에 대해서 IllegalArgumentException을 터뜨릴 때가 많았는데, IAE는 표준 예외이기 때문에 내가 사용하는 다른 라이브러리에서도 터지는 일이 많다는 것을 리뷰어 피드백을 통해 깨달았다. 

이후로는 내가 정의한 예외에 대해서는 커스텀 예외를 만들고, 다양한 예외 클래스들은 해당 커스텀 예외를 상속받는 방식으로 만든다. 이렇게 하면 내가 만든 가장 상위의 커스텀 예외에 대해서는 안심하고, 공통적으로 400대 에러를 보낼 수 있다. 

 

 

✔ Spring JDBC

 

이 분야는 사실 공부했다기보다는 잘 사용했다에 가깝다.

 

JDBC 자체는 우리가 다양한 데이터베이스를 사용할 때 자바 코드를 사용해서 표준적으로 데이터베이스에 접근하는 코드를 만들기 위한 인터페이스이다. 하지만 JDBC는 데이터 커넥션 관련해서도 개발자가 직접 코드를 작성해야 한다는 점에서 불편했다. 

 

이를 개선하기 위해 나온 것이 JdbcTemplate인데, 데이터에 접근을 도와주는 구체 클래스로, 데이터 커넥션에 필요한 기능들을 쉽게 제공해서 개발자는 SQL문만 작성하면 되게 되었다. 하지만 이 SQL문 마저 작성하기 귀찮은 개발자들을 위해서 후에 객체와 관계를 매핑한  JPA가 만들어졌는데, 편의를 위한 많은 생략이 있어서 기초부터 공부하는 것이 좋다는 말에 따라 아직 학습하지 않았다.

 

JdbcTemplate은 그 자체로 매우 편리하기도 하지만, 비슷한 기능을 하는 다양한 버전이 있다.

 

NamedParameterJdbcTemplate는 확장 버전으로, SQL문에 들어갈 문자들에 이름을 부여할 수 있다.

SimpleJdbcInsert도 insert에 한정해서 더 편리하게 entity를 테이블에 추가하고, id와 같이 자동 생성되는 key를 얻어올 수 있는 등 다양한 확장 기능을 제공한다.

 

 

✔ Layered Architecture

 

소프트웨어를 여러 개의 계층으로 분리해서 설계하는 방법이다.

 

사용자에게 보여지는 presentation layer, 실제 비즈니스 로직을 담은 buisness layer, 데이터베이스에 접근하는 presistence layer, 이외의 데이터베이스, 네트워크 등 인프라에 대한 코드를 담는 infrastructure layer의 역할이 각 계층에 딱 들어있지 않고, 섞이게 되면 문제가 발생했을 때 해당 코드가  어디 있는지 찾기도 어렵고, 정신이 없어서 여러모로 유지보수가 어렵기 때문에 사람들이 경험적으로 나누어놓은 계층이다.

 

처음 공부할 때는 감도 잘 오지 않고, 어려웠다. 

이 주제는 깊게 파고 공부하기보다는 실제 애플리케이션을 한 번 만들어보는 것이 훨씬 더 빠르게 학습할 수 있는 분야인 것 같다.

 

 

✔ 더미데이터 추가하기

 

• data.sql에 추가하기
• @PostConstruct를 사용해 초기화
• @ApplicationRunner를 사용해 초기화

 

 

---

 

 

위의 지식은 내가 2~3주에 걸쳐 천천히 습득한 개념이어서 당시에는 매우 뿌듯했고, 스프링을 사용할 수 있게 된 것 같아 매우 기뻤다.

지금 보니 너무 당연한 내용이 되어버려서 레벨 인터뷰에서 말하기에는 어려운 것 같아서 속상하다. 

역시나 지식은 알게 되면 너무 별 것 아닌 것처럼 느껴지는 경향이 있으니, 앞으로도 그때그때 잘 기록을 해놔야겠다는 생각이 들었다. 

 

 

 

✔ HTTP 프로토콜 기초 공부하기

 

HTTP 프로토콜을 적용한 Reqeust, Response에 들어있는 Header, Body의 종류에 대해서 간략히 공부했다. 

 

 

✔ 스프링 애플리케이션에서 클라이언트와 소통하는 방법

 

우선 두 가지를 크게 공부해야 한다.

 

클라이언트로부터 들어온 요청을 어떻게 내가 자바 코드로 받을 수 있는가

내가 클라이언트에게 보내고 싶은 응답을 어떤 방식으로 보내줄 수 있는가

 

요청 관련해서 @RequestMapping 어노테이션과 파라미터 값을 바인딩하기 위한 @RequestParam, @ModelAttribute에 대해 우선 공부했다. 요청 헤더를 가져오기 위한 @RequestHeader 어노테이션도 학습했고, 각 HTTP Method에 특화된 @GetMapping, @PostMapping 등등에 대해서 공부했다.

 

Basic Authentication을 공부하면서 Authorization 헤더에 있는 내용을 데려오기 위해서 @RequestHeader("Authorization") 형태로 많이 사용한 것 같다. 

 

 

반환값으로 응답을 보내줘야 하기 때문에 ResponseEntity와 @ResponseBody에 대해 공부했다. 그치만 지금 사용하는건 주로 ResponseEntity인 것 같다. 상태 코드를 별도의 어노테이션 없이 설정할 수 있어서, 더 간결하면서 섬세하게 응답을 생성할 수 있기 때문이다. 

 

 

 

✔ 스프링이 만드는 프록시 객체

 

레벨1에서 하나의 클래스를 작성할 때 상속할 예정이 아니라면 final 키워드를 붙이겠다고 다짐한 적이 있다. 

그런데 @Repository 어노테이션을 붙인 클래스는 final을 붙인 경우에 Spring이 동작하지 않았다...!

 

이 포스팅에 해당 내용을 자세히 정리해 놓았다. 

 

 

 

 

💋 협업

 

협업은 참 어렵다. 늘 어려운데, 크루 중 쿠션어를 잘 사용하는 크루가 있어서(주노) 그친구의 말투와 행동을 많이 따라해봤다. 

협업에 관한 자세한 내용은 이 포스팅에 적어놨다!