Troubleshooting

문제

배포를 하는 중 에러가 났다.

Web server failed to start. Port 8080 was already in use.

스프링을 처음 공부할 때부터 종종 겪었던 에러이기 때문에
cmd 켜서 netstat -ano 치고, process id 찾고 kill하면 되지~
라고 간단하게 생각했는데

어랏? 뭐야 무서워 port를 죽였는데, 또 사용 중이다..?

파일이 잘못 됐나 싶어서
싹 정리하고 다시 .jar 생성하고 파일질라에 업로드했다.

로컬에선 잘 돌아간다.
그런데 아이피 주소만 찍으면 ? 에러.
EC2 설정이 잘못 됐나?
특별히 문제될 부분은 없다.
포트포워딩을 안 해서? :8080 붙이면 ? 에러.
nohup 적용? 당연히 에러.

백엔드 세 명이 반나절을 머리를 맞대고 생각했지만,
에러. 에러. 에러.만 보고 결국 해결하지 못해서
기술 매니저님께 도움을 요청했다.

문제의 원인 & 해결 과정

그래서 문제의 원인은?!

server.address=localhost
server.port=8080

application.properties 파일에 이 코드가 있었다.
네가 왜 거기서 나와...?

깃헙에 푸쉬할 때는 application.** 파일을 다 제외하고 올리니까 몰랐는데
배포할 때 DB랑 S3 버킷 등 연결하기 위해 파일을 공유하면서
코드가 뒤섞인 모양이다.

이렇게 포트 번호를 지정해 놓고 서버를 올려서 충돌이 났고,
그래서 지정이 안 됐던 것!

이 코드를 지우고 나니 그 뒤로는 어렵지 않게 배포할 수 있었다.
휴우 드디어 배포를 했다😹

회고

좀 더 찬찬히 코드와 설정 부분을 살펴봤어야 하는데,
마냥 기다리고 있는 프론트 팀원들을 생각하니 마음이 급했다.
그래서 당장 뱉어내는 에러 메시지만 구글링하고 있었다.

매니저님이 문제 해결 과정에서 application.properties 파일을 보시고
어? 저 코드 뭐죠? 지워볼까요? 라고 말씀하셨고,
그제서야 코드가 섞였다는 것을 알게 되었다.

아하 로컬에서는 문제가 없는데 아이피만 사용하면 작동되지 않는 이유가 한번에 설명됐다.

좀 더 코드를 살펴볼걸.. 이라는 생각과 함께
와 어떻게 바로 찾아내시지? 라며 감탄했다.

문제 해결이 끝나고 매니저님과 QnA 시간을 가지면서 듣게 된 이야기인데,
이렇게 문제 해결하는 것도 경험에서 비롯된다고 말씀해 주셨다.

그리고 에러노트 작성에 대한 조언도 들었다. (그렇게 시작하게 된 시리즈🤓💡)

++ 틈새 아이디어
캠프 구성원들끼리 에러 상황과 해결법을 공유하고 더 좋은 방안에 대한 토론이 이뤄지는 서비스(feat. 캠프 내 스택오버플로우?)를 만들면 좋겠다는 생각도 떠올랐다.

결론은 에러 메시지만 보지 말고, 문제 발생 원인을 찬찬히 고민하자.
문제 해결 능력은 경험에서 비롯되고, 그 경험을 흘려보내지 말고 에러노트로 기록하자.