결론부터 말하면,
20년이 지났다고 해서 EJB 안에 구현된 업무 로직이 나이를 먹어 못 쓰게 되는 것은 아니다.
시간이 흘렀다는 이유만으로 논리가 틀려지는 것은 아니다.
20년 전에 예약 가능 여부를 판단하고, 회원을 조회하고, 요금을 계산하고, 트랜잭션을 처리하던 로직이 지금도 같은 업무 규칙 안에서 정확하게 작동한다면 그 로직은 여전히 유효하다.
예를 들어 20년 전 코드가 이런 판단을 한다고 해보자.
예약가능 = 잔여티 > 0 && 회원상태 == 정상 && 예약일 >= 오늘
2026년이 됐다고 이 논리가 갑자기 노망나는 건 아니잖아? ㅋㅋㅋ
논리는 나이를 먹지 않는다.
그 논리를 둘러싼 환경이 늙는다.
EJB에 구현된 업무 로직
→ 업무 규칙이 그대로라면 계속 사용할 수 있다.
Java 6 / JBoss 4.2.3 같은 실행환경
→ 지원이 종료되고 보안 패치와 최신 라이브러리 호환에 문제가 생긴다.
IE 기반 화면
→ 브라우저와 운영체제 생태계가 변하면서 더 이상 정상적인 사용환경을 유지하기 어려워진다.
DB·암호화·통신규격·인증 방식
→ 보안 기준과 외부 환경이 변하면서 과거의 구현이 위험해질 수 있다.
그러니까 오래된 시스템을 교체해야 하는 이유는 반드시
“옛날 알고리즘이라 느리고 낡아서”
가 아니라,
“그 알고리즘을 계속 실행하기 위해 20년 전의 환경까지 함께 보존해야 하기 때문”
일 수 있다.
나는 이 차이가 중요하다고 생각한다.
그런데 우리는 종종
“20년이나 됐으니까 낡았다.”
“새로운 기술이 나왔으니까 전부 다시 만들어야 한다.”
라는 식으로 너무 쉽게 결론을 내린다.
정말 그럴까?
내가 국민학교에 다니던 시절, 갤러그라는 오락이 있었다.
1981년에 등장한 갤러그의 게임 규칙은 단순하다.
적 편대가 움직이고,
적이 공격하고,
플레이어가 총을 쏘고,
적을 맞히면 점수가 올라간다.
2026년이 됐다고 이 게임의 논리가 갑자기 쓸모없어진 것은 아니다.
갤러그는 지금 돌려도 갤러그다.
문제는 원래의 1981년 아케이드 기판을 그대로 현대의 PC나 스마트폰에 꽂아 사용할 수 없다는 것이다.
그래서 우리는 에뮬레이션을 하거나, 포팅을 하거나, 새로운 환경에 맞게 다시 구현한다.
즉,
갤러그의 게임 규칙은 살아 있다.
갤러그가 태어났던 플랫폼은 낡았다.
이걸 내가 다루는 시스템에 대입하면 꽤 재미있다.
업무 로직 = 갤러그의 게임 규칙
JBoss 4 + Java 6 + IE 환경 = 오래된 갤러그 기판
내가 이런 생각을 떠올리는 게 단순히 미친놈이라서일까? ㅡ.ㅡㅋ
그렇다면 시스템 현대화의 정답은 반드시
“20년 된 코드는 모두 버리고 처음부터 다시 만들자.”
일까?
나는 꼭 그렇지는 않다고 생각한다.
오랫동안 운영되면서 검증된 시스템이라면 오히려
검증된 업무 로직은 최대한 보존하고,
낡은 실행환경과 사용자 인터페이스를 교체하는 것.
이게 더 합리적인 현대화 방법일 수도 있다.
물론 업무 규칙 자체가 바뀌었거나, 구조적으로 확장할 수 없거나, 보안상 더 이상 유지할 수 없는 로직이라면 바꿔야 한다.
하지만 단지 “오래됐으니까”라는 이유만으로 검증된 업무 로직까지 모두 버리는 것은 또 다른 종류의 낭비일 수 있다.
생각해보면 내가 요즘 골프예약 시스템에서 하고 있는 작업도 비슷하다.
예약이라는 업무를 새로 발명하고 있는 것이 아니다.
오랫동안 사용해 온 기존 데이터와 업무 흐름을 최대한 살려두면서,
화면을 반응형으로 바꾸고,
보안 취약점을 서버 검증 방식으로 옮기고,
사용자 인터페이스를 현대화하고,
낡은 브라우저 환경에 묶여 있던 부분을 하나씩 걷어내고 있다.
갤러그를 버리는 게 아니다.
갤러그가 돌아가던 낡은 기판을 바꾸고 있는 것이다.
그래서 다시 묻게 된다.
오래됐다는 이유만으로
정말 모든 것을 버려야 하는가?
아니면 우리가 버려야 할 것은
오랫동안 검증된 지식이 아니라,
“오래됐으니 가치가 없다”고 너무 쉽게 판단해버리는 우리의 태도일까?
제발~!!!!
쫌~!!!!!!!
내가 왜 “쫌”이라고 하는지는…
아는 사람은 알 거다. ㅡ.ㅡㅋ