웹스퀘어 화면이 새 브라우저에서 깨지거나 유지보수 계약이 끝날 때 — 재계약과 전환의 비교
WebSquare 시스템은 평소에는 아무 결정도 요구하지 않는다. 결정이 필요해지는 순간은 정해져 있다. 브라우저가 업데이트되어 화면이 깨지거나, 보안 감사에서 지적이 나오거나, 서버를 교체하거나, 유지보수 계약 갱신 시점이 오거나, 개발자를 못 구할 때다. 이 글은 그 순간에 놓이는 두 선택지를 같은 기준으로 비교한다.
결정을 강제하는 계기들
- 브라우저·OS 업데이트로 특정 화면이 깨지거나 동작이 달라진다. 오래된 엔진 버전일수록 자주 겪는다.
- 보안 감사(ISMS 등)에서 지원이 끝난 컴포넌트·라이브러리가 지적된다.
- 서버 교체·클라우드 이전 시 기존 WAS 안의 엔진 구성을 그대로 옮기기 어렵다.
- 엔진 버전 업그레이드가 필요하지만 화면 전체를 다시 검수해야 한다.
- 유지보수 계약 갱신 시점에 비용이 오른다.
- 개발자 수급 실패로 장애 대응이 늦어진다.
공통점은 "어차피 돈을 써야 하는 시점"이라는 것이다. 선택은 "쓰느냐 마느냐"가 아니라 "재계약·업그레이드에 쓰느냐, 전환에 쓰느냐"다.
두 선택지의 비교
| 기준 | 재계약·업그레이드 | React 전환(화면 계층만) |
|---|---|---|
| 지출 성격 | 반복(연 단위) | 1회성 |
| 이번 문제 해결 | 해결되지만 다음 브라우저 업데이트에서 반복 | 표준 웹 기술이라 브라우저 호환 문제의 성격이 바뀜 |
| 인력 | 벤더 제품 경력자 필요 | 일반 React 개발자 |
| 백엔드 | 변경 없음 | 변경 없음 |
| 검수 범위 | 업그레이드 시 화면 전체 재검수 | 전환 화면 검수(자동 검증 통과본 기준) |
| 배포 | WAS 안의 엔진 구성 | 정적 빌드 폴더 하나 |
전환이 이전에 선택지가 아니었던 이유는 비용이 "대기업 프로젝트 단위"였기 때문이다. 화면 변환이 자동화되면서 그 전제가 바뀌었다.
전환 비용의 실측
실제 업무 시스템 두 곳 64화면을 자동 변환 도구(ws2react)로 옮긴 결과, 자동 변환 64 / 64(수작업 코드 수정 0건), 화면당 2~5분, LLM 비용 화면당 $0.3~6, 백엔드 변경 0이었다. 화면 변환은 컴퓨터의 시간으로 끝나고, 사람의 시간은 어댑터 검토와 업무 검수에 쓰인다. 유지보수비 1~2년치 안에 들어오는 규모다.
부분 전환이라는 중간 경로
전체를 한 번에 옮길 필요는 없다. 백엔드가 그대로이므로 문제가 된 화면 묶음부터 옮기고 나머지는 기존 시스템으로 두는 병행 운영이 가능하다. 브라우저에서 깨진 화면 10개를 먼저 옮기고, 결과를 보고 다음 묶음을 결정하는 식이다. 첫 묶음이 곧 타당성 검증이 된다.
자주 묻는 질문
엔진을 최신 버전으로 올리면 되지 않나요?
가능하지만 반복 지출이고, 화면 전체 재검수가 따르며, 인력 문제는 그대로다. 이번 계기만 넘기는 선택인지, 다음 계기까지 포함한 선택인지를 기준으로 비교하는 것이 맞다.
보안 심사에서 전환 도구 자체가 문제되지 않나요?
도구는 로컬에서 실행되고 소스는 PC를 떠나지 않는다. LLM 호출은 구매자 본인의 계정으로 이루어지며 모델에 파일 접근 권한이 없다. 라이선스 검증도 오프라인이라 폐쇄망에서 동작한다.
전환 후 브라우저 호환은 누가 책임지나요?
산출물이 표준 React·Vite 프로젝트이므로 일반 프론트엔드 유지보수 범주에 들어간다. 특정 벤더의 패치 일정에 묶이지 않는다.
먼저 확인해 보려면?
로컬 CLI를 내려받아 문제된 화면 2개를 라이선스 없이 변환해 볼 수 있다. 결과 리포트에 시도 횟수·검증 단계·비용이 기록된다.
ws2react는 로컬 CLI입니다. 소스는 PC를 떠나지 않고, 라이선스 없이 프로젝트당 화면 2개까지 변환해 볼 수 있습니다.
무료 체험 다운로드 가격 보기
ws