회사에 입사하고 어느덧 1년 6개월이 지났다. 그간 거쳐온 프로젝트는 총 2개. 그리고 지금 하고 있는 3번째 프로젝트도 설 연휴가 지나면 인수인계만 남게 된다. 6개월 + @의 시간. 더군다나 이번 프로젝트는 프로젝트 생성부터 직접 시작했기에 더더욱 회고 할 것이 많다.
프로젝트의 생성부터 개발 환경 조성, 공통 모듈 구현까지 백엔드 파트의 전반적인 부분들이 내게 주어졌다. 경험치를 쌓아보라는 회사 상사들의 배려였을 것이다. 답답한 부분이 많았음에도 별다른 핀잔 없이 내가 구현한 공통단에 맞춰주는 상사들께 일단 감사를 표한다.
1.리소스 할당은 어렵다.
리소스 할당은 최대한 단순하고 명확하게 하는 것이 좋다.
이번 프로젝트에서 가장 나를 괴롭힌 부분은 Spring Security 였다. 전자정부 프레임워크에서 제공하는 시큐리티 기능을 전혀 쓰지 않고 오직 스프링 코어에서 제공하는 기능만 구현해서 썼다. 하지만 처음엔 몰랐다. 전자정부에 시큐리티 기능이 있다는 건, 관공서 등에서 요구하는 특유의 시큐리티 구현 기능이 있다는 뜻이란걸.
관공서에서는 관리자 페이지와 사용자 페이지가 분할되는 것을 원했고, 심지어 하나의 프로젝트에서, 즉 하나의 쓰레드에서 이 두 페이지가 관리될 수 있도록 요구했다. 하나의 세션 객체에서 두 개의 계정이 관리되어야 하는 상황이었다.
전자정부에서 제공하는 시큐리티로 교체하면 해결될 일이었지만 이미 스프링 시큐리티로 회원 기능의 전반적인 부분이 모두 구현된 상태였다. 무엇보다, 타이트하게 구현된 전자정부 시큐리티는 요구사항이 조금만 추가되도 전체적으로 갈아 엎어야 할 위험이 있었기에 직접 로직을 구현할 수 있는 스프링 시큐리티를 고집하기로 했다.
고려해야 할 요소가 너무나도 많았다.
- 세션이 없을 경우 로그인 시 세션을 생성한다.
- 로그아웃 시, 세션이 비어 있을 경우 세션과 쿠키를 삭제한다.
- (사용자)로그아웃 시, 세션이 비어 있지 않은 경우 (관리자 계정 로그인) 세션과 쿠키를 유지한다.
- (사용자)로그인 시, 세션이 생성 되어 있는 경우 (관리자 계정 로그인) 기존 세션에 로그인 한 요소를 추가한다.
여기다가 중복 로그인 처리까지 구현하자니 말 그대로 머리가 아파왔다. 애초에 설계 미스였다.
세션 하나에는 반드시 하나의 계정만 관리 되도록 단순하게 바꾸기로 했다.
- 로그아웃 시에는 무조건 세션을 삭제한다.
- 로그아웃 시, 세션이 비어 있지 않은 경우 새로운 세션을 생성한다.
- JSESSIONID를 업데이트한다.
- 새로 생성된 세션에 기존 세션의 데이터를 복사한다.
리소스 할당은 어렵다. 결국 설계 자체를 최대한 단순하고 명확하게 할 필요가 있었다.
2. URI 정책은 설계 단계에서 정하자.
URI는 생각보다 잘 까먹고, 잘 겹친다.
마찬가지로 스프링 시큐리티의 문제가 컸다. 사실 관리자 페이지라는 기능 자체가 한창 구현 중에 추가로 들어온 요구사항이었다. 그렇기에 시큐리티를 분리해야 하는 상황이 벌어졌고, 시큐리티는 URL로 관리 범위를 정하기 때문에 URL 자체가 완전히 분리되어야 하는 상황이었다.
쉬운 일이라 여겼다. 사용자와 관리자. 이렇게 두 단계로만 분리되면 되는 일 아닌가? 아니었다. 공통적으로 쓰이는 api들은 어떻게 나눌 것이며, 자바 이외의 폴더들은 또 어떻게 나눌 것인가. 관리자라는 기능이 하나 더 생겼을 뿐인데 모든 URL과 파일 경로들을 재검토하고 나눠야 하는 불상사가 벌어진 것이다.
결국 공통단의 api들은 매핑 어노테이션에 2개 씩의 URL을 갖게 되었다.
3. 테스트 코드는 선택이 아닌 필수다.
개발 환경과 배포 환경은 서로 같을 수 없다.
테스트 코드는 굉장히 유익한 개발 기법이지만 SI 환경에서 크게 와닿는 말은 아니다. 테스트 코드가 고맙게 느껴질 정도로 거대한 프로젝트는 경험해보지 못했기 때문이다. 더군다나 스프링 레거시 환경은 테스트 코드 작성 시, context 설정부터 컴포넌트 설정까지 다 해줘야 하기 때문에 제법 소요가 있는 작업이다.
그럼에도 불구하고 반드시 테스트 코드를 작성한 이유는, SI 환경에서는 오히려 배포 시에 테스트 코드가 더 유익하다고 생각하기 때문이다. 개발 환경에서 잘 되는데 배포 환경에서는 오류를 내뱉는 경우가 적지 않게 있다. 열에 아홉은 개발 환경과 배포 환경이 다르기 때문에 벌어지는 일이었다. 특히 개발 DB와 운영 DB를 따로 두다 보니 데이터 상의 오류이거나 테이블의 구성 방식이 달라서 생기는 오류가 많았다.
하지만 일단 배포 이후의 오류에 대해서는 변명의 여지가 없는 것이 개발자라는 포지션이다. 더군다나 말그대로 개발 환경에서만 재현 가능한 오류이기 때문에 개발 환경에서 수정하고 재배포하고 was를 재기동 시켜서 테스트하는 짓을 반복해야 한다. 이 때 테스트 코드가 굉장히 유익하게 사용됬다. 운영 서버에 재배포 한 뒤, 테스트 코드만 작동 시켜보는 것이다. was를 재기동 시키지 않기 때문에 서버에 반영되지도 않을 뿐더러 무엇보다 빠르게 결과를 확인할 수 있다.
4. WAS 종속적인 개발을 피해라.
servlet 관련 클래스는 java에서 제공하는 클래스와 was에서 제공하는 클래스가 동시에 존재한다.
was가 내장되어 있는 springboot 프로젝트에게는 좀 먼 나라 얘기일 수도 있지만 스프링 레거시 프로젝트에게는 생각보다 골치 아픈 내용이다.
위에서도 언급했다시피 개발 환경과 배포 환경은 서로 같을 수 없다. 스프링 레거시 프로젝트의 경우 was도 개발 환경과는 다른 was를 사용해야 한다. 같은 tomcat이라도 세세한 설정 사항 등이 완벽하게 일치할 수는 없다.
그렇기에 was 종속적인 개발을 최대한 피해야 한다. 개발 환경에서 tomcat에서 제공하는 api를 import 했다가 다른 was를 사용하는 배포 환경에서 컴파일 오류를 낸 적이 몇 번 있었다.
