[권찬] 7단계 - 게시글 이미지 업로드, 이미지 조회, 마이페이지 화면 개발

[kckc0608]

완료 작업 목록

• 피그마의 요구사항 항목들 구현
  • 게시글에 첨부한 사진을 저장하는 로직 작성
  • 게시글 조회 시 첨부한 사진을 조회하는 로직 작성
  • 이전글 / 다음글 조회 로직 작성
  • 404 에러 페이지 화면 개발
  • 회원가입 검증 추가 (각 필드의 글자 수가 4글자 이상, 이름/닉네임 중복 방지)
  • 인증된 사용자 정보를 가져오기 위한 AuthenticationGate, AuthenticateManager 로직 수정
  • 마이페이지 기본 이미지 조회 로직 구현

주요 고민과 해결 과정

• 이전글/다음글 조회 로직

  • 현재 보고 있는 게시글의 댓글 작성, 좋아요 등의 기능을 수행하려면 현재 게시글의 post id 를 알아야 함
  • 이전글/다음글은 조회한 게시글 리스트의 인덱스를 바꾸어야 함
    • 인덱스와 게시글 ID 사이에는 관계가 없기 때문에, 로직 구현을 어떻게 해야 할 지 고민이 되었음
  • 현재는 게시글 삭제 기능이 없고, auto increment 로 인해 게시글 id 가 1씩 순차증가하는 것이 보장되어있으므로, 이전글, 다음글을 조회할 때 현재 조회중인 게시글 id 기준으로 -1, +1 을 하여 조회하도록 간단하게 우선 구현함

• 인증 정보 조회 로직

  • 기존의 인증여부를 검증하는 로직은 AuthenticationGate 에서 수행하고 있었음
  • 인증된 사용자의 정보를 가져오려면 user database 에서 조회해야 함
    • 하지만 webserver 코어 로직인 AuthenticationGate 가 어플리케이션 로직인 user database 을 아는 것은 바람직 하지 않다고 생각함. (유지보수의 관점에서 알아야 할 컨텍스트가 늘어나 좋지 않음)
    • 그럼에도 AuthenticationGate 가 제대로 검증하려면 결국 user database 에 의존할 수 밖에 없음. 이는 곧 AuthenticationGate 는 어플리케이션 스펙임을 의미했음
    • 따라서 AuthenticationGate 로직을 webserver 패키지 외부로 이동하였음. 현재는 기능 구현을 우선하느라 RequestProcessor 가 AuthenticationGate 에 직접 의존하고 있지만, 인터페이스를 통해서 직접적인 의존성을 분리하는 것이 바람직하다고 생각함.
  • 인증 정보를 조회한 뒤, 이를 어디에 저장하고, 어떻게 가져올 지 고민이 되었음.
  • 아무것도 구현하지 않는다면 사실 핸들러에서 request 로 들어온 쿠키를 매번 파싱한 뒤, 직접 유저 디비를 조회하면 되지만 반복적인 로직을 계속해서 작성해야 하므로 생산성 측면에서 좋지 못하다고 생각했음.
  • 스프링 시큐리티의 경우, SecurityContext 라는 전역 공간에 인증 정보를 저장해두고, 서비스 계층에서는 전역 공간에서 인증정보를 가져오고 있음.
  • 이 로직이 편리하다고 생각하여 기존의 static 메서드로 사용되고 있던 AuthenticationManager 에 인증 정보를 저장할 static Map 을 두고, 핸들러 매핑 전에 호출되는 AuthenticationGate 에서 인증 정보를 체크하면서 가져온 유저 객체를 항상 해당 Map 에 넣어두도록 만듦.
  • 핸들러는 인증 정보가 필요할 경우, AuthenticationManager 에게 인증 정보를 받아 처리하면 되므로, 반복 로직을 작성할 필요가 없어져 생산성이 개선됨