몇 가지 기억..

SI보다는 SM이나 에이전시에서 이슈 처리 포함해서 이런저런 경험을 했다(기억나는대로 추가 예정..). 당시 파악을 제대로 못한 게 있어 정확치 못한 부분이 있을 수 있지만, 그것대로 그냥 적어본다.

 

1. 트래픽 과부하로 인해 앱 다운 이슈
   • 은행권 알림 앱이었고, 매달 특정 일자에 트래픽이 몰리면서 앱이 뻗는 이슈[A]가 발생했다. 문제는 앱의 특정 로직이 DB 커넥션을 너무 많이 물고 있는 거였는데, 해당 로직은 실시간 처리가 필요치 않은 부분이었다. 따라서 해당 로직을 파일 쓰기로 변경하고, 트래픽이 없는 새벽 시간대에 배치를 돌려 한 번에 DB에 삽입해주는 식으로 처리했다.
   • 이때 Spring Batch를 이용할지, Spring JDBC를 이용할지 고려해야 했는데 기존에 후자로 작성된 부분이 있어서 일관성을 위해 후자로 작성했다. 데이터 건수가 약 4천만건 이상으로 굉장히 많았기 때문에 JVM 메모리 이슈를 피하기 위해 적절한 커밋 단위로 나누어 진행했다. 실운영되고 있는 서비스라 반영 후 약 3-4일간 테스트 및 모니터링했던 기억이 있다.
2. CORS
   
   • 따로 웹 취약점 점검을 할 때도 있었으나 유지보수를 하면서 단건으로 이슈로 맞닥뜨린 경험이 있어 적어보려고 한다[B].
   • 그룹 내 조직문화 관련 설문 사이트였는데, 도메인 이관[C] 후 설문 생성 시 이미지 및 CSS 파일을 받아오지 못했다. 크롬 네트워크 탭을 확인해보니 요청 URL이 이관 전 URL이었고, strict-origin-when-cross-origin이라고 나왔다. 프로젝트 내 소스 전체 검색으로 모든 URL을 바꿔주었고, 해당 AJAX 요청이 200인데 이상했다.
   • 알고 보니 해당 설문 화면은 JSON(MappingJackson2JsonView)으로 HTML 문자열을 받고 있었다. 이후 JSP에서 동적으로 HTML을 그려주는 과정에서 CORS가 발생한 것이었다. 따라서 DB에 박혀있던 HTML 문자열의 URL을 수정함으로써 이슈를 해결할 수 있었다.
3. 결제모듈
   
   • 사실 이 작업은 당시 상황 때문에 완수하지 못하고 퇴사하였는데, 기억에 남아서 남긴다. 오래됐긴 하지만 당시 고민했던 흔적들이 남아있기도 하고[D], 좀 더 생각해보고 싶은 마음도 있다. 
   • 구청 홈페이지 관련 결제모듈 연동 작업이었다. 프로그램 수강신청/취소 로직에 결제모듈 연동(LGU+)이 필요했다[E]. 원하는 플로우는 다음과 같았다. 첫째, 회원은 프로그램 신청을 할 수 있고 마이페이지상(myPage.jsp)에서 신청 프로그램에 대한 결제를 할 수 있다[F]. 둘째, 결제 누르면 프로그램 정보와 함께 결제 팝업(tossPayment.jsp)을 타게 된다. 셋째, 마이페이지(myPage.jsp)로 리다이렉트되며, 결제 상태를 업데이트 쳐준다.
   • 혼동되었던 부분은 당시 PG사에서 제공한 JSP 파일이 결제 페이지 외에 결제 결과 페이지도 있었다는 것이다. 결제 팝업(tossPayment.jsp)에서 결제 서버, 즉 토스 서버와 연동 후 바로 마이페이지(myPage.jsp)로 리다이렉트되는 것이 아니라 결제 요청 결과를 결과 팝업 페이지(payReq.jsp)에서 받아왔다. 여기서 마이페이지를 리다이렉트 시키면 부모창이 아니라 자식창에서 마이페이지로 이동되었기 때문에, 데이터만 기존 마이페이지로 전달해준 후 부모창을 새로고침 및 자식창 닫아주었던 걸로 기억한다.
   • 하지만 이런 식의 지저분한 결제 모듈을 본 적이 없기 때문에[G] 문제가 배포할 수 없는 상황이었고, 익스플로어에서는 동작하는데 크롬에서는 동작하지 않았던 이슈도 있었다[H]. 그 외 테스트 위해 인증서 설치를 해야 했던 걸로 기억하는데 로컬 환경과 개발 환경의 OS가 달라서 각각 설치했었던 기억이 난다.
4. 첨부파일
   •  
5. 레드마인
   • .
6. 기타
   • 개발적인 부분은 아니지만 환경적으로 적응이 쉽지 않았던 곳이 있었다. SM의 경우 개발, 운영의 소스 관리가 제대로 안 되어 있었던 경우가 꽤 있었다[I]. 이런 경우 원인도 모르게 어느 날 운영에서 에러가 나면 운영에 접속해서 관련 로그를 찾아서 원인을 추론해야 하는 경우가 있었는데, 적어도 자기 자리에서 운영에 접속은 가능했었다. 하지만 에이전시 근무할 때는 조금 달랐다. 여기는 어떤 홈페이지에 문제가 있으면 해당 사이트에 방문하여 거기서 서버 로그를 확인해야 했다[J]. 소스가 관리가 안 되어 있어 운영, 개발도 달라 원인도 파악하기 어려웠고 방문시 담당 공무원이 친절하지도 않았다. 이렇게 여러 곳의 소스를 관리하다보니 결국 개발자 개인의 실력에 따라 일을 넘기는 환경이었던 거 같다. 입사했을 때 앞으로 MSA 같은 구조로 소스 구조를 리팩토링하고 싶다는 얘기를 들었는데, 지금 생각해보면 말도 안 되는 상황이었던 거 같다.
   • 첫 회사에서 Oracle BI 지원으로 나주였나, 한국전력에 이틀 정도 지원나간 일이 있었다. 사실 개발이 아니고 연동 관련된 문제라 내가 전문가도 아니고, 할 게 없었으나 중개해주는 회사 영업하시는 분이 굉장히 저자세였다. 나는 사원이고, 그분은 나이도 40대 중반 이상의 인상도 굉장히 강해 보였으나 내가 잘 모르겠어요, 하는 말도 다 노트에 받아적었다. 좀 의아했는데 그분이 본인 회사 임원과 전화하면서 말그대로 쌍욕 먹는 모습을 보고 정말 충격을 받았다. 저렇게까지 하면서 저래야 하나 싶은 마음도 들고, 영업하고 안 맞으시는 거 같은데 왜 굳이.. 라는 생각도 들고.. 그때 기억이 종종 난다.

 

 

----------

A. 은행권이다보니 인프라쪽에서 요청 트래픽과 DB 커넥션 관련해서 모니터링하다가 문제가 생기면 담당자 연락해서 서버를 내렸다 올리는 식이었다. 그런데 해당 이슈는 재발 가능성이 높아 몇 차례 회의를 통해 소스를 수정, 반영해주었다.

B. XSS 같은 경우도 JSP단에서 스크립트로 처리한 경험이 있지만 딱히 적을 만한 건 아니고, MyBatis를 사용한 경우가 많아 SQL 인젝션 같은 건 자체적으로 방어가 되어 따로 처리해준 기억이 없었다.

C. 예를 들면 기존 URL이 A.COM이었다면 B.COM으로 바뀌었다.

D. 당시 구현하다 막혀서 고민하다 남긴 질문글이 있었다.

E. 오래되긴 했지만 기억하기론 LGU+ 전자결제 방식이 TOSS로 흡수되었나 했었던 것 같다. 더욱이 결제 모듈 소스가 자바 버전도 그렇고 상당히 오래되어서 연동이 쉽지 않아 토스에 전화로 물어가며 작업했던 기억이 난다.

F. 신청과 결제가 다른 페이지에서 진행되는 구조였다. 결제는 오직 마이페이지에서만 진행할 수 있었다.

G. 보통 모달을 띄우는 식으로 결제가 진행되는 경우가 많았는데, 이 경우 JSP를 전달받아서 팝업으로 진행해야 하니 어려웠다.

H. 당시 원인은 못 찾았으나 브라우저의 CORS 등 보안 정책과 관련있지 않나 추측된다.

I. SI의 경우 로컬, 개발 순으로 개발이 진행되기에 운영, 아니 개발에서 디버깅할 일도 많지 않은 것 같다.

J. 노트북 가져가서 거기서 제공해주는 서버에서 붙을 수 있는 노트북 옆에 켜놓고, 가져간 노트북으로 JSP 파일 수정해서 컴파일 후 해당 서버에서 FTP로 반영한 후 로그 확인했었던 거 같다. 이때 로그 한글로 찍었다가 깨져서... 아 로그는 영어로 찍어야 되는구나 했었던 기억도 난다.