오래된 사내 시스템을 자동화해 달라는 요청을 받으면 가장 먼저 부딪히는 벽은 기술이 아니라 정보의 부재입니다. 개발한 지 오래된 시스템은 API 문서가 없고 담당자도 내부 동작을 모르며 보안 정책 때문에 원격으로 들여다볼 수도 없습니다. 한 통행료 정산 시스템을 연동할 때가 그랬습니다. 화면은 Nexacro라는 옛 UI 프레임워크로 만들어져 있었고 겉으로 보이는 것만으로는 이 프로그램이 서버와 무엇을 어떻게 주고받는지 전혀 알 수 없었습니다. 이 글은 그런 상황에서 화면이 아니라 통신을 상대로 시스템을 여는 방법을 정리했습니다.
화면 자동화가 아니라 통신 재현으로 가는 이유
레거시 시스템 자동화에는 크게 두 갈래가 있습니다. 하나는 사람이 하듯 화면을 클릭하고 값을 입력하는 UI 자동화이고 다른 하나는 시스템이 서버와 주고받는 통신을 직접 재현하는 방식입니다. 언뜻 화면 자동화가 쉬워 보이지만 옛 UI 프레임워크에서는 오히려 함정이 많습니다. 화면 요소를 안정적으로 붙잡기 어렵고 렌더링이 느려 타이밍 문제가 잦으며 무엇보다 화면이 조금만 바뀌어도 전체가 멈춥니다. 무인으로 매일 돌아야 하는 업무라면 이 취약함은 치명적입니다.
반대로 통신을 재현하는 방식은 서버가 실제로 이해하는 요청을 그대로 보내는 것이라, 화면이라는 중간 단계를 통째로 건너뜁니다. 서버 입장에서는 사람이 보낸 요청인지 프로그램이 보낸 요청인지 구분할 수 없습니다. 브라우저를 띄우지 않으니 빠르고 화면 변화에 흔들리지 않으니 견고합니다. 물론 서버가 무엇을 기대하는지 알아내는 초기 비용이 크지만 한 번 해석해 두면 그 위에서 안정적으로 운영할 수 있습니다. 이 시스템은 무인으로 매일 돌아야 했기에 처음부터 통신 재현을 선택했습니다.
통신을 캡처해서 정체를 확인하다
원격 접속이 막혀 있었기 때문에, 실제 시스템에 접근할 수 있는 유일한 기회는 현장 방문이었습니다. 현장에서 실제로 로그인하고 미납 목록을 조회하는 정상적인 업무 흐름을 한 번 수행하면서 그 과정에서 오가는 네트워크 통신을 통째로 기록했습니다. 브라우저 개발자 도구로 요청과 응답을 남기면, 이후에는 그 기록만 들고 사무실에서 차분히 분석할 수 있습니다. 여기서 중요한 것은 특별한 도구가 아니라, 정상적인 업무 한 사이클을 빠짐없이 캡처하는 것입니다.
기록을 열어 보니 몇 가지가 분명해졌습니다. 서버는 동작마다 하나의 통합된 창구가 아니라 각기 다른 주소를 호출했고 요청과 응답이 모두 XML 형태였습니다. 자세히 보니 이 XML은 데이터셋이라는 단위로 컬럼 정의와 행 데이터를 담는 특정 프레임워크의 형식이었습니다. 인증은 인증서나 일회용 비밀번호 같은 복잡한 장치 없이 표준적인 세션 쿠키 하나로 유지됐습니다. 즉 로그인 한 번으로 세션을 확보하면, 이후 각 동작에 해당하는 주소로 올바른 형식의 요청을 보내는 것만으로 조회와 처리가 가능했습니다.
트랜잭션마다의 규칙을 읽어 내다
이 프레임워크의 특징은 각 요청이 자기 자신을 설명한다는 점이었습니다. 요청 안에는 이 동작이 어떤 서비스이고 어떤 주소를 호출하며 어떤 데이터셋을 입력으로 받고 무엇을 출력으로 돌려주는지가 함께 담겨 있었습니다. 캡처된 로그인 요청과 조회 요청을 나란히 놓고 이 메타 정보를 하나씩 대조하자, 시스템의 동작 지도가 그려지기 시작했습니다. 어떤 주소가 로그인이고 어떤 주소가 미납 조회이며 어떤 입력 컬럼에 조회 조건이 들어가고 응답의 어떤 컬럼에 차량번호와 금액이 담기는지가 드러났습니다.
특히 조회 응답은 미납 한 건마다 한 행이 오는 구조였습니다. 한 차량이 여러 건 미납이면 같은 차량번호로 여러 행이 나뉘어 왔습니다. 그래서 응답을 그대로 쓰지 않고 차량번호를 기준으로 행을 묶어, 차량 한 대당 미납 건수와 총액과 통행 내역을 계산하는 처리를 붙였습니다. 이렇게 프로토콜의 구조를 이해하면, 화면에서는 여러 번 클릭하고 눈으로 세던 일이 데이터 위의 단순한 그룹핑 연산으로 바뀝니다.
코드값의 의미까지 해석하다
프로토콜을 읽는 일은 요청 형식을 맞추는 데서 끝나지 않습니다. 이런 시스템은 화면에 보이는 사람이 읽는 값 대신 내부 코드값으로 데이터를 주고받는 경우가 많습니다. 처리 구분이나 영업소 같은 항목이 사람이 아는 이름이 아니라 짧은 코드로 오는 식입니다. 다행히 이 시스템에도 공통 코드 테이블을 내려 주는 초기화 요청이 있었고 로그인 직후 이 테이블을 함께 읽어 두면 코드값을 사람이 읽는 이름으로 되돌릴 수 있었습니다. 프로그램이 시스템의 언어뿐 아니라 그 안의 약속된 부호까지 이해하게 만든 셈입니다.
이렇게 통신 캡처에서 출발해 프로토콜과 코드값까지 해석하고 나면, 나머지는 그 규칙에 맞는 요청을 성실하게 만드는 일입니다. 물론 그 과정에도 함정이 있었습니다. 로그인 자격증명이 암호화되어 있었고 발송 요청은 형식이 조금만 어긋나도 거부됐습니다. 이 두 이야기는 각각 클라이언트 측 로그인 암호화 해석과 바이트 단위 요청 재현으로 오류 잡기에서 이어집니다. 이 역설계가 실제 업무 자동화로 이어진 전체 그림은 레거시 통행료 시스템 역설계 연동 사례에서 볼 수 있습니다.
자주 묻는 질문
Nexacro 같은 옛 UI 프레임워크도 API 연동이 되나요?
됩니다. UI 프레임워크가 무엇이든 그 뒤에서 서버와 주고받는 통신은 결국 요청과 응답의 형식으로 정의됩니다. 그 형식을 통신 캡처로 확인해 재현하면, 화면을 거치지 않고 서버와 직접 통신할 수 있습니다. 이 방식이 화면 클릭 자동화보다 빠르고 안정적입니다.
통신 캡처에는 특별한 도구가 필요한가요?
브라우저 개발자 도구의 네트워크 기록만으로도 충분한 경우가 많습니다. 핵심은 도구가 아니라 정상적인 업무 흐름을 한 사이클 빠짐없이 캡처하는 것입니다. 로그인부터 조회, 처리까지 이어지는 실제 흐름을 온전히 기록해 두면, 이후 분석은 접근 권한 없이도 진행할 수 있습니다.
시스템이 나중에 바뀌면 다시 만들어야 하나요?
통신 구조 자체가 바뀌면 해당 부분은 재대응이 필요합니다. 다만 화면 클릭 자동화처럼 사소한 화면 변경에 매번 멈추지는 않습니다. 서버가 주고받는 요청 형식은 화면보다 훨씬 자주 안정적으로 유지되기 때문에, 실무에서는 유지보수 부담이 오히려 작은 편입니다.