오랜만의 servlet, jsp 삽질
나는 요즘 유행하는 spring, react, angular, vue 등등은 포기했다.
예전의 의욕 충만했던 시절로 돌아가 새로운 프레임웍을 학습하며 성취감을 느끼고 싶지만
시간과 체력도 부족하고 이젠 내 삶이 그 시간들을 기다려주지 않는다.
그래서 많이 익숙한 servlet, jsp, vanilla script , bootstrap, pwa 로 시스템을 구축했는데
수십여년을 다룬 개발 환경임에도 삽질은 여전하다. ㅎㅎ
현재 시스템에서는 request 의 session 에 UserSession 이라는 객체로 사용자 정보를 담아 이를 활용하고 있다.
그리고 이렇게 저장된 UserSession 을 jsp 에서 조회하여 사용자의 자격과 권한을 체크하고 사용 가능한 메뉴를 구분하고 있다.
그런데 이렇게 UserSession 을 저장하려면 로그인시에 DB 를 조회하여 사용자 정보를 취하고 그 정보들로 instance 를 생성한 후 request.setAttribute() 를 수행해야 하는데
사용자 로그인 방식이 계정 아이디/비밀번호 인증 방식과 SNS 계정 인증 방식 두가지가 있고
두가지 방식에서 instance 저장 수행 속도가 서로 달랐다.
그래서 SNS 계정 인증 방식으로 동작할땐 현상이 발생하지 않았는데 아이디/비밀번호 인증 방식으로 동작할때는 해당 session 값이 취해지지 않아 권한 오류가 발생하고 있었다.
처음엔 jsp 의 출력 버퍼의 문제로 생각하고 버퍼를 조기에 flush 하면 원하는 값을 정상적으로 출력하지 않을까? 했었다.
하지만 초기에 flush 해도 문제가 발생하고 문서의 마지막에 flush 해도 증상은 여전했다.
instance 의 생성 시점의 문제라는 것을 알지를 못하니 도저히 원인을 예측하지 못하던 와중에
혹시 service worker 에서의 cache 문제인 걸까? 싶어서 service-worker.js 를 재점검 해봤지만
괜히 두어시간을 허비하며 스파게티 코드만 양산해 버린 꼴이 되었다.
그래서 service-worker.js 는 전날 저장된 상태로 다시 복원 할 수 밖에 없었고
다시 초심으로 돌아가 jsp 페이지에 javascript alert 이나 띄우며 값의 흐름을 쫓고 있었는데
이상하게 현상이 발생하지를 않는 것이었다.
결국 여전히 미심쩍긴 하지만 javascript 의 alert 은 ui 를 holding 상태로 만들어 server 에서의 process 가 완료될때까지 기다릴 수 있으며 이는 미리 정의된 jsp 코드에도 영향을 준다는 점을 알게 되었다.
request 에 설정한 attribute는 jsp 코드로 취하고 있는데 jsp 코드 역시 server side 프로그램인데
왜 javascript 의 alert 에 영향을 받는지 잘 모르겠다.
gpt 한테 물어봐도 jsp 코드는 server 에서 이미 실행되어 client 로 전달된 문서내에서 javascript 가 alert 을 띄우는 것이므로 javascript 의 alert 이 jsp 프로그램의 수행에 영향을 줄 수 없다는 답변을 주었다.
다만 gpt 는 센스있게도 내가 이전에 질문했던 내용을 기억하고 javascript 의 alert 에 따라 세션 값이 다르게 반환되는 현상에 대해서도 짤막하게 유추해 주었는데 그저 비동기 프로세싱에 따른 시간차 오류일 것이라고 귀띔해 주었다.
이미 현상이 그렇게 나오니 그건 맞는거 같은데... 이해 할 수 없는 현상이 되어버렸다.
세션을 이용하려 했던 것은 문서를 전달하는 시점에 사용자 권한까지 함께 전달하여 통신 자원 이용을 최소화하려는 것이었는데
이를 포기하고 최종적으로 그냥 서버에 사용자 권한을 한번 더 요청하자로 결론 지었다.
페이지 하나 띄우는데 ajax 통신을 3번 이상씩 수행하는게 매우 부담스럽지만
프로세스를 최소한으로 분리하면 추후 유지보수에서도 오류 분석에 있어 범위를 좁힐 수 있어 작업 효율성이 좋으므로
당장은 데이터를 별도로 요청하는 것으로 마무리 하였다.
결국 차후에는 네트웍이 완전 차단된 상태에서도 앱의 데이터를 저장, 변경하도록 아키텍처를 구성할 예정인데
이번에 겪은 오류 사항을 기억하여 앱과 서버의 데이터 동기화 매커니즘을 신중하게 설계 해야겠다.
마지막으로 이번 분석 작업을 통해 다시금 상기하게 된 사실은
이번 오류에서는 jsp 들간의 include 에 의한 compile 시간차가 있고 pwa 로 인해 client cache 가 있다보니
시스템 복잡도로 인해 별 것 아닌 기능조차 오류를 쫓아 원인을 분석해 나가기가 너무나 버거웠다.
그런데 규모가 큰 시스템은 이보다 더한 복잡도로 시스템을 구축해 가는데...
문제 해결에 있어 오래된 시스템에 익숙해진 개발자의 몸값이 높아지는건 당연한 일이겠다.