이곳은 인터넷과 업무망이 분리된 폐쇄망 연구소다. 외부 서비스를 업무 코드나 데이터에 직접 연결할 수 없다.

금요일 오후 네 시 십칠 분, 사내 프로젝트 접수 화면이 다시 멈췄다.

김전산 주무관은 조회 버튼을 한 번만 눌렀다. 회색 진행 표시가 사라지지 않았다. 옆자리 이코딩 주무관이 휴대전화의 초시계를 켰다.

“십이 초입니다.”

“지난주에는 팔 초였는데요.”

“그때는 진행 중인 사업만 조회했습니다. 지금은 종료 사업하고 외주업체 인력까지 같이 붙었습니다.”

목록이 나타났을 때는 열두 줄뿐이었다. 하지만 그 열두 줄을 만들기 위해 전자정부프레임워크 아래의 MyBatis 동적 SQL은 프로젝트, 입찰, 계약, 일정, 원가, 지급, 투입 인력 테이블을 오갔다. 사용자가 보지 않는 값도 함께 읽었다.

김전산은 오류 기록과 실행 시간을 수첩에 적었다. 업무 코드를 집으로 가져갈 수는 없었다. 이곳은 전편에서 폐쇄망 AI를 들여왔던 바로 그 연구소였다. 인터넷과 업무망은 분리되어 있었고, 외부 자료를 반입할 때는 보안 검사와 승인 절차를 거쳐야 했다.

그날 밤 김전산은 집에서 기술 영상을 찾아봤다. 업무 화면도, 테이블 이름도, 소스 코드도 가져오지 않았다. 공개된 Next.js 소개와 개발 사례만 차례로 봤다.

영상에서는 React 화면과 서버 기능을 한 프로젝트에서 만들고 있었다. 페이지를 하나 추가하려고 Java 클래스 여러 개와 XML 설정을 오가는 모습도 없었다.

김전산은 영상을 멈추고 속으로 말했다.

‘우리 프로젝트를 개편한다면 Next.js가 답일 것 같은데.’

곧바로 결론을 내리지는 않았다. 공개 영상의 예제와 폐쇄망 ERP는 조건이 달랐다. Node.js와 npm 패키지를 반입할 방법, Oracle 연결, 사내 인증, 파일, 결재, 운영 배포를 모두 확인해야 했다.

월요일 아침 김전산은 최정보 팀장 자리로 갔다.

“팀장님, 프로젝트 접수 시스템 개편 회의를 요청드리고 싶습니다.”

“지난주에 느려진 그 시스템 말입니까?”

“예. 화면 한 군데를 다시 고치는 회의가 아니라 전자정부프레임워크를 Next.js로 바꿀 수 있는지 검토하는 회의입니다.”

김전산은 잠시 말을 고른 뒤 덧붙였다.

“지금 시작하면 기존 시스템 운영과 개편 작업을 함께 해야 해서 당분간 업무가 고되고 힘들 겁니다. 그렇지만 더 미루면 의존성과 예외 처리가 계속 쌓이고, 구조를 아는 사람도 줄어듭니다. 난이도가 더 커지기 전에 시작해야 합니다.”

최정보 팀장은 바로 승인하지 않았다.

“왜 Next.js여야 하는지, 폐쇄망에서 가능한지, 운영 위험은 무엇인지 준비해 오세요. 기존 것이 무겁다는 말만으로는 바꿀 수 없습니다.”

폐쇄망에서 가능한가

오후 회의에는 최정보 팀장, 박개발 사무관, 김전산 주무관, 이코딩 주무관, 정운영 주무관, 정시스템 주무관이 모였다. 전편에서 폐쇄망 AI 환경을 만들었던 정보시스템팀 그대로였다.

김전산은 첫 화면에 기술 이름보다 조건을 먼저 적었다.

전제
1. 이 연구소는 폐쇄망이다.
2. 업무 소스와 운영 데이터는 외부로 나가지 않는다.
3. 외부 패키지는 보안 검사와 승인 뒤 내부 저장소로 반입한다.
4. 개발계와 테스트베드에서 검증한 결과만 운영계로 승격한다.
5. Oracle은 그대로 유지한다.

정운영 주무관이 물었다.

“npm이 인터넷에서 패키지를 받는 구조 아닙니까?”

“개발자가 운영망에서 마음대로 받게 하지 않습니다. 승인된 Node.js 버전과 패키지를 외부 준비 구간에서 내려받고, 해시와 라이선스, 취약점을 확인한 뒤 폐쇄망 내부 패키지 저장소로 반입해야 합니다. 잠금 파일도 함께 관리합니다.”

박개발 사무관이 말을 받았다.

“빌드할 때마다 최신 패키지를 찾게 두면 재현도 안 됩니다. 승인된 버전을 고정하고, 개발계에서 만든 같은 결과물을 테스트베드와 운영계로 올리는 절차가 필요합니다.”

최정보 팀장이 물었다.

“그러면 기술적으로 불가능한 것은 아닙니까?”

“가능성은 있습니다.” 김전산이 말했다. “다만 오늘은 도입을 확정하는 회의가 아니라, 개발계와 테스트베드에서 증명할 범위를 정하는 회의입니다.”

지금 구조는 왜 어려운가

박개발 사무관이 기존 시스템의 흐름을 화이트보드에 적었다.

브라우저
  → JSP 화면
  → Spring MVC Controller
  → Service 클래스
  → DAO 또는 Mapper
  → MyBatis XML
  → Oracle

애플리케이션은 WAR 파일로 만들어져 Tomcat 또는 JEUS 같은 Java WAS 컨테이너 위에서 실행됐다. 전자정부프레임워크가 MVC 구조를 제공하고 공통 기능을 묶어 주었지만, 오랜 수정 끝에 화면 하나를 바꾸는 일도 여러 계층과 설정 파일을 함께 건드리는 작업이 됐다.

이코딩 주무관이 물었다.

“MVC라서 무거운 겁니까?”

김전산은 고개를 저었다.

“MVC 자체가 문제라는 뜻은 아닙니다. 잘 나눈 계층은 필요합니다. 문제는 우리 시스템에서 단순한 업무 하나에도 Controller, 요청 객체, 응답 객체, Service 인터페이스, 구현 클래스, DAO, Mapper XML 같은 파일이 반복되고 있다는 겁니다. Java와 전자정부프레임워크가 나빠서가 아니라, 현재 업무 규모에 비해 구조와 코드가 너무 많이 쌓였습니다.”

그는 새 구조를 옆에 적었다.

브라우저
  → Next.js React 화면
  → Next.js 서버 기능
  → 업무 Service
  → Knex.js 또는 바인드된 Oracle SQL
  → Oracle

“Next.js는 프론트와 백엔드를 하나의 프로젝트에서 개발하고 같은 빌드 체계로 관리할 수 있습니다. 서버 기능은 Node.js 프로세스에서 실행합니다. React의 클라이언트 코드는 브라우저에서 실행되므로 프론트까지 전부 Node.js 위에서 돈다고 말하면 정확하지 않습니다. 대신 화면과 서버의 타입, 검증 규칙, 배포 버전을 한 저장소에서 맞출 수 있습니다.”

정시스템 주무관이 물었다.

“Tomcat과 JEUS를 내리면 WAS가 완전히 없어지는 겁니까?”

“Java WAS는 없어지지만 서버 프로그램은 남습니다. Node.js 위의 Next.js 서버가 조회, 저장, 인증을 처리합니다. Nginx는 앞에서 HTTPS와 정적 파일, 리버스 프록시를 맡습니다.”

사용자
  → Nginx
      ├─ 정적 파일
      └─ Next.js Node.js 프로세스
              → 기존 Oracle

줄이려는 것은 업무가 아니라 반복 코드다

김전산은 두 구조의 파일 수를 단순히 비교하지 않았다. Java 클래스가 많다는 이유만으로 잘못된 시스템이라고 할 수는 없었다. 대신 이번 전환에서 줄일 수 있는 반복을 적었다.

• 화면 요청과 응답을 위해 반복되는 Java DTO
• Controller와 Service 사이의 단순 전달 메서드
• 구현이 하나뿐인 Service 인터페이스와 구현 클래스
• CRUD마다 반복되는 DAO와 Mapper 연결 코드
• JSP와 JavaScript 사이에서 따로 관리되는 검증 규칙
• WAR 패키징과 WAS별 배포 설정

“Next.js로 바꾸면 이 계층 일부를 TypeScript 함수와 모듈로 합칠 수 있습니다. 화면과 서버가 같은 타입을 공유할 수 있고, 단순 전달용 클래스도 줄어듭니다. 수정해야 할 파일과 코드가 줄면 작업 난이도와 유지보수 난이도도 낮아질 가능성이 큽니다.”

최정보 팀장이 ‘가능성이’라는 단어에 밑줄을 그었다.

“훨씬 가벼워진다고 확정해서 말하지는 않는군요.”

“예. Node.js라고 자동으로 빠르거나 가벼운 것은 아닙니다. Next.js도 잘못 만들면 메모리를 많이 쓰고 쿼리를 반복합니다. 개발계와 테스트베드에서 응답 시간, 메모리, CPU, Oracle 부하, 배포 시간, 수정 파일 수를 같은 조건으로 재야 합니다.”

박개발 사무관이 웃었다.

“그 답이면 검토해 볼 수 있겠습니다. 유행이라서 바꾸는 게 아니라 우리 반복을 줄이는지 확인하는 것이니까요.”

먼저 Next.js를 선택하고, 작게 증명한다

회의는 전면 재개발을 승인하는 것으로 끝나지 않았다. 다음 단계를 시험할 기술로 Next.js를 선택하고, 폐쇄망에서 재현 가능한 개발·배포 경로부터 확인하기로 했다.

1. Next.js를 목표 기술로 정한다.
2. Node.js와 승인 패키지를 폐쇄망에 반입하는 절차를 만든다.
3. 기존 Oracle을 그대로 사용한다.
4. 개발계에 최소 서버를 배포한다.
5. 같은 결과물을 테스트베드로 승격한다.
6. 성능과 운영 가능성을 측정한다.
7. 통과한 범위만 다음 단계로 진행한다.

최정보 팀장이 회의 결론을 읽었다.

“전자정부프레임워크를 Next.js로 전환하는 안을 개발계와 테스트베드에서 검증한다. Oracle은 유지한다. 운영계는 검증 결과를 본 뒤 결정한다. 맞습니까?”

모두 고개를 끄덕였다.

이코딩 주무관이 물었다.

“그러면 화면부터 만들어 봅니까?”

김전산은 회의록의 다음 장을 열었다.

“아닙니다. 먼저 Next.js에 맞는 개발 도구와 폐쇄망 코딩 환경부터 통일해야 합니다. 그다음 기존 MyBatis가 내놓는 값과 똑같은 값을 새 백엔드가 내놓는지 확인하겠습니다.”

“Eclipse를 그대로 쓰는 겁니까?”

“기존 Java 유지보수에는 남겨 두고, 신규 Next.js 프로젝트는 VS Code와 일전에 구축한 로컬 AI를 사용하자는 안을 준비하겠습니다.”

최정보 팀장이 새 안건 제목을 적었다.

제2편 안건
Eclipse에서 VS Code로

고장 난 화면에서 시작한 회의는 새 화면 시안으로 끝나지 않았다. 팀이 먼저 정한 것은 기술과 순서였다. 폐쇄망 안에서 Next.js에 맞는 개발 환경을 세우고, 백엔드가 기존 업무와 같은 답을 내는지 확인한 뒤에야 화면을 바꾼다.