Record/회고록

3년동안 방치된 증권사 폐쇄망 레거시 프로젝트 배포하기

seung_soos 2024. 5. 2. 12:38

시작하며

해당 글은 제목에서 보셨듯이 3년동안 방치된 증권사 폐쇄망  레거시 프로젝트를 배포하며 필자의 우당탕탕 경험을 작성하였다.

 

사내에서 간단한 변경개발 건이라며 000사의 프로젝트를 받게되었다.

 

해당 프로젝트의 초기 개발자들은 이미 퇴사한 팀장 급 분들이 개발하셨고, 남은 우리팀의 팀장님만 해당 프로젝트의 간략한 히스토리를 알고계셨다.

서버 프로젝트는 Admin, App으로 총 2개의 프로젝트로 구성되어 있으며, 환경은 아래와 같다.

프로젝트 구성 구분 버전
Admin Java 1.8
Spring 2.3.1
Apache Tomcat  
App Java 1.8
Spring Boot 2.3.1

 

여기서 문제는 폐쇄망이라는점과 코드의 히스토리를 아는사람이 없다 라는것이다.

 

Admin 서버의 경우 프로젝트를 Clone 받은 후 Spring 이기 때문에 Apache Tomcat설정을 추가하였다.

Tomcat Context-path 및 context.xml 등등 여러 설정을 추가하고 사내 개발서버를 구축하여 테스트를 하였다.

Admin 모듈의경우 큰 변수없이 잘 마무리하였다.

 

Admin Tomcat 설정 참고사이트

하지만 ApServer가 쉽지 않았다. 프로젝트를 Clone 받을때 부터 라이브러리 문제로 모든프로젝트가 컴파일에러가 발생하고 있었다.

해당 라이브러리는 프로젝트내에 위치하고 있지만 인식되지 않아 pom.xml 에 수동으로 system-path를 설정하여 컴파일 시켰다.

이후 App 서버도 변경 개발 후 사내 개발서버에 구축하여 테스트를 하고 마무리 되는줄 알았으나, 코드가 이상하다는걸 느꼈다.

 

"왜 return을  true 로 고정하는걸까?" 분명 권한 인증단계인데.. 아.... 이거 코드가 운영 코드가 아니다.. 라는걸 느꼈다.

모두 이상한건 아니지만, 인증단계의 몇 부분이 이상하다보니 해당 코드에대한 신뢰도가 많이 떨어졌다.

 

팀장님께 여쭤보니 고객사 내부에서 개발하고 코드를 가지고 나와 커밋하였고 팀장님은 다른 모듈을 개발해 정확히 기억나지 않는다고 하셨다.  고객사 담당자분께 여쭤보니 사내 이클립스로  최초배포하고, 변경 개발도 있었다고 들었다. 즉, 최신 코드는 사내의 이클립스에 있다. 라는 것이다.

 

정리를 해보자면 코드는 배포 직전의 코드인것같고, 코드는 신뢰 할 수 없다. 그로인해 war 파일 추출은 불가능하여,

.Java 파일을 컴파일 하여 .class 파일로 운영서버의 ROOT 디렉토리의  class 파일을 교체하면 정상 반영이 되기때문에 해당방법을 선택하기로하였다. 현재 변경 파일이 인증단계이기 때문에  Local 코드로는 불가능한것이다.

 

고객사에 방문하여 Admin은 Local의 코드로 war를 말아서 배포하였고, 특이사항은 없었다.

App 서버 코드를 빌드 시키려하였으나, 폴더 정리가 안되어있고, 담당자분 말씀으로는 보안프로그램이 작동되어 특정 하위폴더는 삭제가된다라고 말씀하시며 정확한 폴더와 삭제파일에 대해서는 인지를 못하시고 계셨다. 

 

반입 프로그램중 이클립스를 찾아 App 서버를 import 시키고 빌드하며 겪은 이슈 및 참고 사이트이다.

고객사에 반입한 라이브러리의 문제인지 Maven 빌드가 지속 실패하였고, 배포를 우선시 해야했기에 .class 파일을 생성하기위해 삽질을하였고, 결국 .class 파일로 배포하였다.

 

배포는 문제없었지만 깨진창문에 커튼을 달아놓는 격이기 때문에 여유가 있다면 배포환경을 다시 구축하고 싶다.