들어가며

어느덧 데브코스에 합류한지 3개월이라는 시간이 흘렀다. 그간 자바 & 스프링 강의를 듣고, 미션 & 스터디를 하느라 정신없이 달려왔다. 멘토님들과 팀원에게 코드리뷰를 받고, 내 코드에서 어떤 점이 아쉬웠는지 고민. 피드백을 적용하면서 더 나은 코드를 작성하기 위해 신경쓰기 시작했다. 또, 팀에서 스크럼 시간을 길게 가져가면서 새롭게 알게 된 내용이나 기술적으로 어려웠던 내용을 이야기하며 혼자 공부하면 습득하지 못했을 지식과 경험을 다방면으로 채울 수 있었다. 다만 새로 생긴 인사이트들을 별도로 정리하지 않다보니, 학습한 내용을 까먹기 일쑤였다. 더 나은 한 주를 위해, 지금부터라도 회고를 작성해본다.

이번 주는 무엇을 했나

쿠키를 이용하여 사용자 인증/인가 처리를 구현했다.

기존에 완료했던 JPA 게시판 미션 에 더해, 쿠키를 이용한 인증/인가를 구현했다. 기능 자체는 간단히 구현할 수 있었지만, 쿠키값을 조회하는 작업 을 컨트롤러 레벨에서 마쳐야하는지 아니면 서비스 레벨에서 해도 되는지에 대한 명확한 기준이 없어 애를 먹었다. 멘토님들께서는 ‘쿠키와 관련된 로직은 컨트롤러 레벨에서 마치자.’ 라는 조언을 해주셨고, 이것이 웹은 도메인을 의존해도 되지만, 도메인은 웹을 의존해서는 안 된다. 라는 것과 관련되어 있음을 알 수 있었다. 내가 이해한 바를 정리하면 아래와 같다.

• RestController 의 코드는 API 설계에 따라 언제든지 변경이 가능하다.
• 도메인(서비스 레이어 이하)이 웹(RestController)을 의존하게 된다면 API 설계가 변경됨에 따라 도메인 코드까지 수정해야할 수도 있다. 따라서 도메인 코드는 쿠키와 관련된 로직은 몰라야한다.
  • 예) HttpServletRequest 와 관련된 코드가 서비스 객체에 포함되서는 안 된다.

백엔드 팀플

팀원들과 강남에 모여 다음 주부터 시작할 팀플에 대한 회의를 했다.

이번 프로젝트는 한 달 뒤 있을 최종 프로젝트 이전에 진행하는 BE팀 끼리의 팀 프로젝트이다. 따라서 ‘최선과 안정’ 보다는 ‘도전과 경험을 통한 성장’을 목표로 삼았다(교육매니저 스펜서 님의 말씀을 빌렸다). 해당 목표를 가지고 선정한 클론 타깃 주제는 캐치테이블 이다. 예약, 커뮤니티, 음식점 정보 등 영역이 명확하게 구분된 도메인을 가지면서도 애플리케이션 전체 규모가 크지 않아 다양한 기술적 도전을 해보기에 적당하다고 판단했기 때문이다.

더불어 이번 팀플에서 PO 역할도 겸임하게 되었다. 책임을 안는데는 그만큼 부담도 따른다. 결은 다르지만 학부 1학년부터 졸업프로젝트까지 모든 팀플의 팀장과 발표를 도맡아왔고, 힘에 부칠때도 있었지만 결국 좋은 성적이 그 노력을 빛내주었다. 지금 PO 해보는 게 아니면 언제해보겠어? 라는 마인드로 임하자. 모든 경험은 내 자양분이 될 것이다.

새롭게 알게 된 점

(API) 행위마다 목적에 맞는 DTO를 만들자

• 게시글 단건 조회와 다건 조회 시 같은 응답 DTO를 사용하였고, 이보다는 행위에 맞는 DTO를 사용해보라는 피드백을 받았다. 관련하여 포스팅으로 정리해두었다.

[REST API] 행위마다 목적에 맞는 DTO를 만들자

단순 상수의 모음으로 enum을 사용하는 것은 지양하자

단순 상수의 모음으로 enum을 사용할 때는 자칫 절차지향 프로그래밍을 하게될 수도 있다. 상태등을 나타내는 상수의 모음으로는 괜찮지만 단순한 상수의 모음(예: 문자열의 모음)으로는 enum을 사용하지 말자.

인터페이스 상수는 안티패턴이다.

인터페이스는 타입을 정의하는 용도로만 사용해야한다(아이템 22). 인터페이스 상수는 안티패턴이며, enum 을 통해 관리하는 것이 아니라면 인스턴스화할 수 없는 유틸클래스에 작성하는 편이 좋다.

401과 403의 차이

401 은 인증과 관련된 응답으로 적절하다. 사용자가 로그인 되지 않는 경우 등에 사용한다.

403 은 인가와 관련된 응답으로 적절하다. 로그인은 되어있지만 특정 요청에 대해 권한 자체가 없는 경우 등에 사용한다.

참고

[HTTP] HTTP 상태 401(Unauthorized) vs 403(Forbidden) 차이

(HTTP) DELETE의 응답으로 200? 204?

DELETE 의 응답으로 DB의 튜플이 삭제된다면, 응답 Payload 가 없다는 의미로 204 를 내려줄 수 있다. 단 튜플이 삭제되지 않는 경우에는 200 을 사용하기도 하는데 예를 들자면 아래와 같다.

• 회원이 이미 상품을 주문한 상태에서, 회원 탈퇴 요청을 하는 경우 → 200 응답

이 경우 회원 튜플을 삭제한다면 참조 무결성과 관련된 문제를 야기할 수 있다. 이 때 회원을 활성/비활성 으로 구분하는 플래그를 세우고, 회원 삭제시 비활성 상태로 변경한다면 문제를 해결할 수 있다. 이 경우에 200 으로 응답을 내려주는 것을 고려한다.

참고

Delete with REST.. 200 or 204 response code?

REST Response Code for DELETE Operation, 200 or 204?

201 의 응답과 함께 새로 생성된 리소스의 URI를 전달한다.

(자료 출처 : 모든 개발자를 위한 HTTP 웹 기본 지식)

POST 를 통해 리소스를 생성한 경우, 서버에서 자원에 대한 관리도 맡게 된다. 이 경우 응답으로 201 을 사용하며 응답 Location 에 리소스에 접근할 수 있는 URI를 같이 전달한다.

PUT은 멱등성을 보장한다

PUT 을 사용할 때는 멱등성을 보장해야한다. 즉, 항상 동일한 결과를 보장해야하는 기능에 PUT 을 사용한다. 예시로는 회원 정보 수정, 게시글 정보 수정 등이 있다. 멱등성을 보장하지 못하는 경우는 PATCH 사용을 고려한다. 예시로는 좋아요 처리, 조회수, 재고처리 등이 있다. 이 외에도 PUT 은 단지 자원의 수정뿐만 아니라, 자원이 없는 경우 요청 페이로드를 이용해 자원을 생성할 수도 있다.

무턱대고 PUT 을 사용할 것이 아니라 대상 리소스가 없다면 생성해야하는 요구사항이 있고, 멱등성이 보장되는 경우에 사용해야겠다고 생각이 들었다. 몇 가지 사례들을 더 찾아보고 우선 그전까지 리소스 수정에 대한 메서드는 PATCH 를 우선 고려해야겠다.

마치며

이제 백엔드 팀플 4주, 프론트엔드 데브코스 크루들과 함께하는 팀플 4주면 데브코스 5개월 과정이 끝이난다. 지난 3개월보다 남은 2개월 과정에서 더 많이 성장할 것이라 믿어 의심치 않는다.

‘어떻게 하면 효율적으로 공부할 수 있을까?’ 라고 고민하기보다는 우선 공부하고 부딪쳐보자. 어려운 점이 있다면 도움을 구하자. 지금 내게는 고민 해결을 위해 도와주실 멘토님들과 의견을 나눌 멋진 팀원들이 있다.

답을 구하고, 배우고, 나누자.

TMI

프로그래머스에 내 실명이 올라갔다. 데브코스 내에서 진행하는 발표스터디에서 Java8 에 추가된 Optional 에 대하여 발표했는데, 감사하게도 많은 분들이 봐주시는 프로그래머스에 내 발표가 업로드되었다. 별 것 아닐 수도 있지만, 공부하는데 적잖은 동기부여가 되었다. 다음 스터디에서 발표할 주제인 필터와 인터셉터도 열심히 준비하자고 다짐한다.