🧪 Software Testing · 8/8 · 약 8분

시리즈 전체 보기

최신 문서 처리 기능이 단독 환경에서 동작해도 오래된 스크립트 화면에서 바로 호출할 수 있는 것은 아니다. 문법을 낮춘 뒤에도 모듈 로딩, 전역 이름, 실행 시점, 런타임 기능에서 문제가 생길 수 있다.

이 글은 완료 보고가 아니라 서로 다른 실행 환경을 연결할 때 제약을 조사하고 경계를 설계하는 순서를 정리한 기록이다. 최신 코드를 오래된 코드에 밀어 넣기보다 두 세계 사이에 작고 검증 가능한 계약을 뒀다.

#Legacy · #ES5 · #Integration · #Architecture

이 글에서 다룰 것

1. ‘ES5 호환’이라는 말을 제약별로 나눴다

제약 확인 질문 문제가 드러나는 순간
문법 대상 환경이 결과 코드를 해석할 수 있는가? 파일을 읽는 즉시 구문 오류가 발생
모듈 가져오기·내보내기 방식을 어떻게 연결할 것인가? 기능은 번들에 있지만 UI에서 찾지 못함
런타임 필요한 기본 기능과 API가 존재하는가? 실행 중 특정 기능이 없어 중단
로딩 순서 준비되기 전에 호출될 가능성이 있는가? 초기 화면에서 간헐적으로 호출 실패
전역 경계 노출 이름과 수명 주기를 통제하는가? 이름 충돌이나 예상치 못한 덮어쓰기

한 묶음으로 ‘호환된다’고 말하면 실패 원인을 찾기 어렵다. 확인한 제약과 조사 중인 제약을 구분해야 한다.

2. UI와 엔진 사이에 작은 브리지 계약을 뒀다

레거시 UI
   ↓ 단순한 요청
브리지 계층
   ├─ 준비 상태 확인
   ├─ 입력 검증
   ├─ 오류 형태 통일
   └─ 문서 처리 기능 호출
          ↓
   제한된 결과 반환

레거시 UI가 엔진 내부 구조를 알게 되면 구현이 바뀔 때 화면 코드도 수정해야 한다. 브리지 계층은 UI가 쓸 최소 기능만 노출하고 내부 차이를 감싼다.

계약 요소 포함할 내용 이유
입력 가상 문서 데이터와 요청 종류 호출 형태를 단순하게 유지
출력 필요한 결과와 검토 상태 내부 모델의 외부 누출 방지
오류 입력 오류, 준비 전 호출, 처리 실패를 구분 UI가 다음 행동을 안내할 수 있게 함
준비 상태 호출 가능 여부와 초기화 결과 로딩 순서 문제를 명시적으로 처리

계약은 가상 JSON처럼 단순하게 만들 수 있지만 실제 방식은 별도로 조사해야 한다. 직렬화 형식보다 UI와 엔진이 서로 기대하는 값을 고정하는 일이 중요하다.

3. 번들보다 먼저 가장 작은 호출을 확인했다

통합 범위를 한 번에 넓히면 실패 원인이 문법, 로딩, 입력, 엔진 중 어디에 있는지 구분하기 어렵다. 다음 순서로 범위를 늘릴 수 있다.