배경
AWS S3의 컨피그와 서비스를 작성 후에 파일이 업로드 되었는지, 삭제가 되었는지 확인하는 시간을 가졌고 실제로 S3 버켓 안에 해당 파일이 업로드 되었고, 삭제도 문제 없이 되는 걸 확인 했다. 처음 구성 해봐서 신기하기에 2번 정도 테스트 해봐았다.
그리고 아무 문제가 없어서 깃허브를 통해 팀원과 공유를 하였다.
문제 발생
그 다음날 아침에 팀원들과 모여 아침회의를 끝내고 팀원이 공유한 통합 코드를 내려받아서 postman으로 전체 테스트를 진행 하였다. 그렇게 테스트 도중 S3 파일 업로드는 잘 되는데, S3 파일 삭제에서 성공했다고 나오는데, 실제로 S3에서는 파일 삭제가 되지 않는 현상을 발견했다. 파일 삭제는 비동기 방식을 사용하기에 서비스 로직에서는 문제없이 작동되는 것 처럼 보이나, 실제로는 실패하여 예외처리를 던지고 있었다.
접근 방식
먼저 팀원들과 통합시킨 코드에서 변경점이 있어서 문제가 발생 하지 않았을까 생각이 들어서 작성한 모든 부분을 점검하였다. 하지만 그 어떤 것도 수정되지 않았다. 업로드는 잘되니깐 삭제 로직이 이상한가? 혹은 이 로직을 가져다 쓴 서비스 로직 쪽의 문제인가 의심되어 집중적으로 다시 확인해 보아도 아무런 변경 점이 없었다.
이 이상 혼자서 문제점을 파악하는 건 불가능 하다고 판단하고 바로 튜터님에게 찾아가서 물어보았다. 튜터님은 코드가 문제가 없다면 AWS의 S3과 IAM에 대한 설정을 다시 확인해야 한다면서 같이 확인해 보았다. 하지만 나는 당시 AWS S3 와 IAM을 처음 만져 보았고 어제 생성 이후에 변경 한 건 일절 없었다. 그렇기에 튜터님과 함께 의문은 미궁에 빠져버렸다.
튜터님과 나는 1시간 동안 찾아봤지만 여전이 해결법은 보이지 않았고, 나는 문득 이러한 문제는 나말고 다른 사람도 경험 했을 것 같다는 생각이 들었고, 그렇게 해결법을 어느 한 블로그에서 발견 할 수 있이다.
원인 파악
그 블로그에서도 나처럼 파일 업로드는 되는데 삭제는 안되는 경험을 하였고 그 원인이 깃허브에 자신의 IAM 시크릿키가 공유되면서 AWS가 자동으로 감지해 정책을 추가하기에 생긴 문제라고 말했다. 참고로 메일도 보내 준다고 하기에 바로 메일을 확인하니 진짜로 AWS에서 보낸 메일이 있었다.
AWS에서는 영문으로 해결법을 제시하면 문제된 지점의 사이트 링크를 보내주었는데, 해당 링크를 들어가서 확인해 보니 시크릿키가 노출되어 있엇다. 문제가 되던 부분을 확인하니 다른 팀원이 시크릿키를 나처럼 인텔리제이 환경변수로 안 넣고, 바로 프로퍼티에서 입력하여 깃허브에 올린 것이였다. 따라 AWS가 감지하고 IAM에 정책을 추가하여 S3 버켓에 파일이 삭제 안되도록 조치한 것이엿다.
문제 해결
나는 블로거의 경험과 AWS에 날라 온 메일을 보면서 문제를 해결했다.
먼저 IAM의 기존 액새스키를 삭제 후 재발급 받아서 해당 액세스 키와 시크릿 키로 환경변수를 수정했다. 또한 AWS가 자동으로 IAM에 추가한 정책을 찾아서 제거해 주었더니 S3 파일 삭제 기능이 정상적으로 작동이 되었다.
여담
이렇게 한나절을 소비해서 해당 기능이 정상적으로 작동 되도록 수정하였다. 이후 수정된 액세스 키와 시크릿 키를 팀원과 공유하면서 깃허브 같은 공용 공간에서 시크릿 키가 노출 안되도록 신신당부하며 나머지 전체 테스트를 진행하였다.
