기록하는 IT 블로그

🏕️상황 프런트 팀원이 해당 사진을 보내주면서 imageurl이 반환이 안 된다고 했다. (맥북에서 캡처를 하니 저렇게 이름이 길어졌다고 했다.) 평상시랑 다른 점(내가 테스트했을 때와 다른 점)이라고 한다면 파일의 이름이 지나치게 길다는 것이다. 그래서 aws 인스턴스에 실행중인 프로젝트의 로그를 확인해 보니 오류가 발생하고 있었다. com.amazonaws.services.s3.model.AmazonS3Exception: The specified key does not exist. (Service: Amazon S3; Status Code: 404; Error Code: NoSuchKey; Request ID: --이 부분은 혹시 몰라 삭제--; S3 Extended Request ID: --이 부분..

🏕️상황 rds에서 테이블들을 확인해 보니 똑같은 테이블이 2개씩 대소문자만 살짝씩 바뀌어서 생겨있었다. 원인이 정확하게 뭔지는 모르지만 일단 확실한 건 rds(mysql)에서 테이블 명이든, 칼럼명이든 모든 소문자로만 저장한다는 것이다. 이 상태로 둘 순 없으니 그냥 스키마를 다 날리고 새로 만들었다. (안에는 더미 데이터만 있는 상태) 오른쪽 entity를 정의했고, @Column을 따로 지정하지 않았으니 해당 속성 명으로 db에도 생성되어야 하는데 rds에서 확인해 보니 맘대로 언더스코어를 붙이고, 모두 소문자로 바뀌어있었다. ⭐알아보니 로컬 Mysql 서버와 amazon rds mysql은 대소문자의 민감도가 달라서 내가 로컬에서 db를 활용했을 때 문제가 되지 않았던 부분이 rds에서는 문제가 ..

한이음 공모전은 연말까지 계속 진행할 것이지만 그 와중에 한이음 내부에서 공모전을 또 실시했다. 그 결과가 오늘 발표되었는데 1차 합격이다!!! 2차도 붙을 수 있도록(시연영상에 좀 더 그럴듯한 기능을 넣을 수 있도록) 더 열심히 개발해야겠다!!

🏕️상황로컬에서 프로젝트 빌드, 컴파일 시에 전혀 오류가 없었다.로컬에서 각 기능들이 너무나 잘 돌아가는 것을 확인하였다.그 상태로 깃허브에 올리고 ec2에서 git pull 받고 빌드를 시키니 오류가 아래와 같이 100개가 나왔다 :) 💦과정이전 블로그에 올렸듯이 dev와 main 브랜치를 합치는 과정에서 많은 오류를 마주치고 해결하는 바람에 깃허브에 올린 코드가 아래의 사진처럼 2개씩 생긴 폴더나 파일이 있었다. (같은 폴더인데 구버전 : dto, 신버전 : DTO) 그래서 기뻤다. 왜냐? 이걸 고치면 오류가 100개씩이나 생기지 않을 것이라고 생각했다. 하지만 고쳐서 수정해도 달라지는 것은 없었다ㅎㅎ   🗝️해결오류가 100개가 아니라 10개라면 일일이 고칠 테지만 100개를 하나하나 고치는 ..

🏕️상황 dev 브랜치의 내용을 main 브랜치에 rebase를 하고 싶었는데 나의 착각으로 인해서 merge를 하게 되었다. 그런데 두 브랜치를 merge 한 지 꽤 되어서 충돌이 굉장히 많이 일어났다. 저 사진에 빨간 부분이 다 오류가 발생한 부분.... 🗝️과정 / 해결 일단 화면에 와 같은 충돌 마커를 다 제거하고, 충돌된 부분을 해결해도 빨간색이 사라지지 않는 클래스도 있었고.... 충돌 해결후에 git add 을 실행해도 unmerged 상태에서 statged 영역으로 내려가지 않고 계`~속 그 상태에 있는 파일이 있기도 했다. 🔜 그래서 일단 마지막까지 해결되지 않은 파일들은 지우고 나서 문제를 해결한 뒤에 다시 생성하기도 하고, 인터넷에서 보이는 것들을 여러 가지 시도하기도 하였다. 중간에..

🏕️상황 꽤나 긴 시간 동안 굉장히 여러 상황을 마주해서 하나하나 기억은 안 나지만 그래도 기억나는 거라도 작성해보록 하겠음. public void updateImages(List newImageList, List existingImageList) { // 새로 추가된 이미지 찾기 List addedImages = new ArrayList(newImageList); addedImages.removeAll(existingImageList); // 삭제된 이미지 찾기 List deletedImages = new ArrayList(existingImageList); deletedImages.removeAll(newImageList); // 새 이미지 업로드 로직 for (String newImage : add..

🏕️상황 처음에는 아래의 코드만 있으면 바로 삭제가 될 줄 알았다. public void deleteFile(String fileName) { DeleteObjectRequest request = new DeleteObjectRequest(bucket, fileName); amazonS3Client.deleteObject(request); } 그런데 나는 기존에 임시경로는 "temporary/"로 정식경로는 "final/"로 설정했기 때문에 이에 맞게 코드를 구성하려고 했다. 위의 코드는 루트 디렉터리 기준이고 나는 키(key) 구조를 활용해서 폴더 같은 형식으로 진행하고 싶었기 때문에 추가적인 코드 작업을 할 계획이었다. 하지만.... Amazon S3에서는 특정 폴더 내에 있는 파일을 삭제하기 위해 ..

🏕️상황 post men에서 post 방식으로 테스트를 진행하고 있었는데 계속 저런 오류가 발생하였다. + 🗝️해결 클라이언트 요청 헤더에 Content-Type을 올바르게 설정했는지 확인해야 합니다. 보내는 데이터의 형식에 따라서 Content-Type을 적절히 설정해야 합니다. 예를 들어 JSON 데이터를 보낼 때는 Content-Type을 application/json으로 설정해야 합니다.

> 게시글에 이미지를 올린다. 그럼 프런트 단에서 이벤트 감지 기능으로 api를 호출한다. (유효성 + 사이즈 검사를 진행 후 S3 임시 경로에 이미지들을 업로드한다.) 임시 경로가 포함된 해당 이미지의 URL을 반환한다. 사용자가 게시글까지 작성 후에 [등록하기]를 누르면 게시글은 게시글 DB에 저장, 이미지는 임시경로 🔜 정식경로로 이동시킨 후에 정식 경로로 변경된 url을 다시 반환받는다. public class imageService { @Autowired private AmazonS3 amazonS3; private final AmazonS3Client amazonS3Client; private final imageRepository repository; @Value("${cloud.aws.s3..

🏕️상황 > 나는 일단 하나의 api를 통해서 게시글의 내용들 + 이미지를 한 번에 처리하도록 구현하였다. 이미지를 포함한 게시판 기능을 계속해서 개발하던 중에 프런트 팀과 이야기를 나누게 되었는데 그 팀원의 의견은 다음과 같았다. 1. 예를 들어 사용자가 정상적인 이미지를 올리지 못하거나, 업로드에 실패했을 시에 하나의 api로 진행하게 되면 작성 중이던 게시글까지 날아가게 되니 사용자 입장에서 불편할 수 있는 상황이 생길 것이다. 2. api 분리를 하면 CDN을 이용해서 좀 더 빠르게 렌더링을 할 수 있을 것이다. 하지만 나는 아무리 생각해도 하나의 api로 처리를 하는 것이 괜히 일을 2번 만들지 않고 간단하게 진행하는 방법이라고 생각했기 때문에 생각이 좁혀지지 않았고, 결국 멘토분께 조언을 구하..