항해99 37일차 TIL1 - 미니 프로젝트 나홀로 중간 회고

이번 주차는 백앤드 3명, 프론트앤드 2명 총 5명이서 미니 프로젝트를 진행했습니다. 

미니 프로젝트 요구 사항이 3주간 배운 내용 + 배포였습니다. 요구 사항만 봤을 때는 여유로운 한 주가 될 것으로 생각했습니다. 무엇보다도 저와 함께한 백앤드 분들은 모두 잘하셨고 또한 잘하려는 의지도 가지고 계신분들이었습니다. 현준님, 현우님 감사합니다. 프론트앤드 분들 화이팅입니다!

 

글 순서

1. 예외 처리를 맡으려고 한 이유

2. 추가로 해본 것, 느낀 것, 배우게 된 것

---

백앤드 팀 역할을 다음과 같이 나눴습니다.

1. 인증/인가

2. 게시글/댓글

3. 좋아요/예외 처리

 

저는 3번을 맡았습니다. 딱히 어떤 것을 더 선호하지는 않았습니다. 각 파트마다 배울 것들이 있다고 생각했습니다.

 

예외 처리를 맡으려고 한 이유

예외가 잘 처리되지 않았을 때 단점

 

1. 예외가 처리되지 않았을 때 요청 - 응답 흐름

정상 응답(예외가 발생하지 않을 경우) - 클라이언트의 요청과 서버의 응답으로 통신이 마무리됩니다.

예외 발생 - 클라이언트 요청  > 예외 > WAS까지 전파 > 예외 요청 > 예외 응답 이런 구조로 통신이 이뤄집니다.

한 마디로 비효율적?입니다. 예외를 처리한다는 것은 예외가 터지더라도 정상 응답하겠다는 말입니다.

그렇기 때문에 WAS까지 전파되었다가 다시 예외를 찾기 위해 컨트롤러까지 올라가는 일을 하지 않습니다.

 

2. 500에러 방지

500에러는 서버에서 처리할 수 없음을 의미합니다. 한 마디로 문제가 발생했지만 서버단에서 해결하지 못함을 의미합니다.

 

3. 프론트와의 소통

상태코드를 통해 프론트와 간접적인 소통이 가능합니다. 예를 들어 권한이 없을 때 터지는 예외를 처리하지 않는다면 500에러가 발생합니다. 그렇게 된다면 프론트에서는 서버 측 문제로 여길 수 있습니다.

 

예외를 처리하여 해당 상황이 어떤 문제임을 말해준다면 프론트와 의미없는 소통을 줄일 수 있게 됩니다.

 

추가로 해본 것, 느낀 것, 배우게 된 것

1. 200번을 제외한 정상 응답 코드도 사용하자.

매니저님의 피드백이었습니다. 아직 코린이지만 개발에서는 문서로 소통할 일이 많습니다. 문서는 명확할수록 상대방이 이해하기 편합니다. 201(created), 202(Accept), 204(no content) 등을 알게 되었고 201 이번 프로젝트에서 적용하였습니다. HTTP 상태 코드 - 위키백과

 

 

2. API 명세는 정확해야 한다.

API 명세는 동료들과의 약속입니다. 수정 사항이 있다면 바로바로 수정해서 보고합시다.

 

3. github organization 인증 이슈 - 왜 나는 비밀번호 인증을 고집하였을까?

프로젝트 시작 첫 날, 이것때문에 하루동안 고생했습니다. 지금 생각해보니 왜 고집을 부렸을까? 이런 생각이 드네요. 

인텔리제이에서 깃 연동을 하려는 인증이 되지 않았습니다. 구글링을 하며 여러 포스팅들의 해결책들을 적용해보았지만 적용되지 않았습니다. 그러던 도중 토큰 인증을 권장한다는 깃헙의 권유와 토큰 인증을 통해 문제를 해결한 팀원을 보며 저도 토큰 인증으로 문제를 해결했습니다. 

 

4. AOP 이제는 원리에 대해 배울 때

이번 기회를 통해 직접 만든 스프링 AOP를 프로젝트에 적용해보았습니다.

트랜잭션, 컨트롤러어드바이스 모두 AOP지만 직접 스픠링 AOP를 만들어 적용한 것은 이번이 처음입니다.

 

제가 만든 AOP는 도메인 내부 컨트롤러에서 응답까지 걸리는 시간이 3초 이상 걸리는 것들을 기록합니다.

발생 시간, 요청자, 응답 시간, 컨트롤러 메소드 등을 기록합니다. AOP를 직접 만들고 사용해보니 이제 그 원리를 배워야 겠다는 생각이 들었다.

 

5. 화가나지만... 판단보다는 생각을 묻자.

팀원의 소스코드 dto에 @Data를 보고 조금 화가나서 쓰지말라고 했다. 팀원분께서 기분이 상하셨을 수도 있을 것 같다. 팀원에 대한 기대가 컸기 때문일까? 다 핑계이다. 내가 감정을 조절하지 못해서 못한 탓이다. 앞으로는 화가날때는 채팅이나 댓글로 내 의견을 피력해야겠다. 

 

참고로 dto에는 @Data를 쓸 필요가 없다. 데이터를 옮기는 객체가 Setter, Equals, Hashcode, ToString 등을 재정의할 필요가 없다. @Data는 왜 지양해야할까? - 내 블로그

 

6. 이미지 업로드, S3를 공부하며... 왜 나는 또 AWS sdk 2.x를 고집하였을까..?

담당한 API를 개발한 뒤 이미지 업로드, 이미지 저장을 공부했다. MultiPartFile이란 걸 알게 되었다. MultiPartFile은 이후 TIL이나 노션을 통해 정리하려고 한다.

 

문제는 AWS였다. S3에 이미지를 저장하기 위해서는 aws SDK에 대해 조금은 알아야한다.

최신 버전이 좋겠지하는 생각에 대뜸 2.x를 적용하려고 했다. AWS SDK for JAVA 2.x - github

 

결과적으로 실패했다. 이미지를 불러오는 것 까지 되는데 업로드 하는 부분에서 실패했다.

더 자세히는 업로드 하려는 파일의 절대 경로를 동적으로 가져올 수 있어야 하는데 이 부분에서 잘 되지 않는다.

objectPath 파라미터가 아무리봐도 파일의 절대 경로를 의미한다. 실제 절대 경로를 입력해주면 파일이 잘 업로드 되기도 한다.

 

 

업로드 파일의 절대 경로를 가져오는 방법 중 하나이다.

Resource resource = multipartFile.getResource();
String absolutePath = resource.getFile().getAbsolutePath();

일단 안된다.검색해보니 jar로 배포할 때 문제라고 한다. 잘 모르겠어요. 어찌 됐던 여기에 약 이틀을 쏟았지만 해결하지 못했다... 침대에 누워서 생각해보니... 커피를 사러 밖을 거닐다보니 내가 왜 2.x 를 고집하고 있는지 의문이 들었다.

 

그래서 1.x 대로 돌아왔고 필요한 기능들은 모두 구현해놓았다. 내일 마무리 지으려고 한다.

 

수정 사항 2023-01-23

 

aws sdk 2.x 버전의 putObject 예제 코드는 객체의 경로가 필요한 것처럼 구성되어 있습니다. 그래서인지 절대경로를 어떻게하면 구할 수 있을지에 대해서만 고민했습니다.

 

inputstream을 통해 경로 없이 업로드할 수 있는 방법을 찾았습니다. 1.x 버전 예제코드가 이 방법을 떠올리는데 많은 도움을 주었습니다. 해당 저장소에는 업로드, 조회, 삭제 기능이 구현되어 있습니다.

 

이미지가 포함된 게시글 API - S3 sdk 2.x 버전 예시 코드

GitHub - JxxHxxx/S3-image-upload-practice: 이미지가 포함된 게시글 API(feat- s3)