프론트엔드가 개발자가 백엔드 동작 구조를 알아두면 좋은 이유
CI/CD 실패, 수동 배포로 전환
인스타그램 과제 마감일이 1주일이나 지났는데 아직도 끝내지 못했다.
원래는 백엔드 배포 시 CI/CD 를 구축하려고 했는데 지속된 실패에 계속 지연됐다.
프론트엔드 팀과 백엔드 팀 모두 달라붙어서 버그를 하나씩 해결해갔는데
하나 해결하면 또 문제가 생기고 이 문제를 해결하면 또 다른 버그가 생겼다.
이러한 과정이 약 3일간 지속됐다.
계속된 딜레이에 마냥 붙들고 있을 수는 없어서
CI/CD 작업을 백엔드 팀원 한명에게만 맡기고 나머지 두분께 수동 배포를 요청드려서
배포에 성공했다.
API 요청 테스트
예상은 했지만 역시 많은 문제가 발생했다..
내가 맡은 부분은 회원가입, 로그인 등 회원 및 인증 관련인데
인증 부분에서 많은 에러가 발생했다.그 중 하나가 서버에서 Refresh Token을 쿠키에 담아 보냈는데
클라이언트에서 확인해보니 오지않는 버그였다.
그래서 이 기능을 맡으신 백엔드 팀원과 함께 버그를 분석해야했다.
백엔드 버그 직접 해결 - 담당 백엔드 팀원의 코로나 이슈
버그 분석을 시작하려던 중 담당 백엔드 팀원이 코로나에 걸리게 돼서
Spring 및 Spring Security 코드를 분석할 수 없게 되었다.코로나 완치까지 보통 약 1주일이 걸리는데 그때까지 손놓고 있을 순 없었다.
프로젝트를 하느라 구름에서 제공해준 김영한님 Spring 강의를 다 듣진 못했다.
기본원리를 다 듣고 MVC 1편 절반 정도 들었던 시점이었다.
나는 프론트엔드 공부를 주로 하는 입장으로서 백엔드에 대한 지식이 얕지만 일단 해보자 였다..
다른 백엔드 팀원의 도움을 받아 Spring 서버 및 데이터베이스를 내 로컬에서 실행시켰다.
그리고 내 로컬에서 프론트엔드 웹 서버를 실행시켰고
break point를 걸어가며 백엔드 팀에서 만든 코드의 동작 구조를 파악해나갔다.
버그 원인 발견 및 직접 코드 수정
5~6시간의 사투 끝에 버그의 원인을 찾고 직접 코드를 수정해서 버그를 해결했다.
아래는 버그 원인과 코드를 수정한 사항을 정리해둔 포스팅이다.
추가적으로 쿠키에 대해 알아보다가 SameSite 정책을 알게되었고
이 부분에 대해서 정리도 했다.
회고
사실 스프링 인강을 들을때 너무 자세하게 배우는 느낌이라 효율적이지 못하다는 생각을 했다.
나는 현재 프론트엔드를 공부하는 입장에서 백엔드를 알아야된다고 생각한 이유가
동작 구조를 알아두면 좋을 것 같다는 생각에How가 궁금했던 것이지
Why에 대해서는 뒷전이었다.내가 지금 듣고 있는 강의의 초점은
왜 스프링을 써야하는가여서
순수 자바->JSP->Spring순으로 코드를 업그레이드 하는 방식이어서
위와 같은 생각을 했다.
큰 오산이었다.
내가 들었던 강의가 이 버그를 해결하는데 큰 도움이 되었던 것 같다.
이런 비상 상황에 내가 직접 대처할 수 있는 능력을 기를 수 있었던 시간이었다.이 사건(?) 이 있기전에 인강을 들으면서 많이 징징거렸던 것 같은데
매우 의미있는 시간이었음을 알게되었고 이제부터 좀 덜 징징거릴 수 있을 것 같다.
스프링.. 한번에 이해가 안돼서 징징거리긴 해야겠습니다..ㅎ
