처음 사무실에 앨리스를 가져왔을 때는 ERP 전체 자동화까지 생각했지만, 실제로 적용 가능한 범위부터 시작하기로 했다.
1차 목표는 기존 TrustForm 화면을 분석해 JSP·HTML5·Bootstrap·JavaScript 기반의 표준 웹 화면으로 변환하는 작업을 얼마나 보조할 수 있는지 확인하는 것이었다.
처음에는 로컬 LLM에게 원본 소스만 보여주고 변환을 맡겼다. 하지만 일반적인 HTML이나 JavaScript는 이해해도 TrustForm 고유의 Model, Instance, Submission, Bind, Datagrid 같은 개념과 전용 API의 의미까지 정확하게 파악하지는 못했다.
그래서 약 400페이지의 TrustForm 사용자 매뉴얼을 임베딩하고, 앨리스가 필요한 내용을 직접 검색해 참고할 수 있도록 RAG 구조를 만들었다.
하지만 단순히 관련 문서를 Top-k 방식으로 몇 개 가져오는 것만으로는 부족했다. 화면 하나를 이해하려면 여러 개념과 API의 관계, 데이터 흐름까지 함께 파악해야 했기 때문이다.
그래서 검색 구조를 다음과 같이 확장했다.
원본 화면 분석
→ TrustForm 전용 요소 추출
→ 개념·API별 매뉴얼 검색
→ 근거 수집
→ 부족한 근거 재검색
→ 데이터 흐름 분석
→ JavaScript 변환
→ JSP·Bootstrap 화면 생성
단순히 “매뉴얼에서 비슷한 문장을 찾아라”가 아니라, 참고서를 펼쳐가며 문제를 푸는 과정에 가깝게 만들고 싶었다.
이 과정을 거치면서 처음 약 60% 수준이던 변환 결과도 점차 좋아졌다.
특히 control.ref, submission.ref, submission.resultref, datagrid.nodeset, model.refresh()처럼 TrustForm 화면의 데이터 흐름을 결정하는 요소들을 공통 규칙으로 정리하면서 화면 구조를 분석하는 정확도가 크게 향상됐다.
다음 단계에서는 비교적 단순한 조회형 TrustForm 화면 하나를 실제 변환 대상으로 선택했다.
원본 화면을 분석하고 매뉴얼 근거를 검색한 뒤, 앨리스의 변환 파이프라인과 Gemma4 엔진을 이용해 JavaScript와 JSP 화면을 생성했다.
처음부터 완벽했던 것은 아니다.
화면 구조와 버튼, 테이블, Submission 정의 등 대부분의 골격은 만들어졌지만 가장 중요한 한 조각이 남아 있었다.
서버가 반환하는 실제 XML 데이터를 TrustForm의 resultref 구조와 어떻게 연결할 것인가 하는 부분이었다.
매뉴얼과 원본 화면만으로는 실제 서버 응답 구조까지 확정할 수 없었고, 모델도 이 부분을 임의로 만들어내지 않고 미확인 영역으로 남겼다.
이후 실제 Action에서 반환되는 XML 구조를 확인하면서 연결 관계가 명확해졌다.
그 XML 패턴을 기준으로 변환 코드를 보완했고, 결국 조회 데이터가 새 JSP 화면에 정상적으로 출력됐다.
사무실 도입 이후 처음으로 TrustForm 분석부터 JSP 변환, 실제 서버 연동까지 하나의 흐름이 끝까지 동작한 순간이었다.
이번 작업에서는 모델의 변환 정확도뿐 아니라, 프로그램을 직접 실행해야만 알 수 있는 문제들도 발견됐다.
예를 들어 JSP 안에서 JavaScript의 ${...} 표현을 사용하면 JSP EL과 충돌할 수 있었고, XML 데이터를 JavaScript 객체 구조로 변경하면 초기화 코드와 렌더링 코드 역시 같은 구조에 맞춰 수정해야 했다.
이런 내용은 TrustForm 매뉴얼에는 없다.
지금까지 앨리스에게 가르쳐 준 것이 주로 제품에 대한 지식이었다면, 실제 프로젝트를 시작하면서 처음으로 작업 과정에서 얻은 경험이 생기기 시작한 것이다.
그리고 여기에서 다음 문제가 보였다.
현재 앨리스는 이렇게 얻은 경험을 다음 작업에서 충분히 활용하지 못한다.
오늘 어렵게 해결한 문제도 비슷한 화면을 다시 만나면 처음부터 다시 판단할 가능성이 있다.
그래서 조회형 화면 변환을 마친 다음 바로 더 복잡한 화면으로 넘어가기보다, 잠시 번외 작업으로 경험을 축적하고 다시 활용하는 구조를 손볼 생각이다.
현재까지의 성과를 정리하면 TrustForm 사용자 매뉴얼 약 400페이지를 로컬 지식으로 구축했고, 단순 Top-k 검색을 여러 단계의 근거 검색 방식으로 확장했다. 또한 TrustForm의 주요 데이터 흐름을 공통 변환 규칙으로 정리하고 Gemma4 기반의 분석·코드 생성 파이프라인을 적용했다.
그 결과 조회형 TrustForm 화면을 JSP·Bootstrap·JavaScript 형태로 변환하고, 실제 서버 XML과 연결해 조회 결과가 정상적으로 출력되는 것까지 확인했다.
동시에 자동 변환만으로 해결되지 않는 영역과 사람이 검증해야 하는 지점도 확인할 수 있었다.
그리고 이번 작업을 통해 한 가지가 더 분명해졌다.
앨리스에게 TrustForm을 변환하는 방법을 가르치는 단계에서, 이제는 실제 일을 하면서 얻은 경험을 기억하고 다음 작업에 활용하는 방법을 가르쳐야 하는 단계로 넘어왔다.
다음 시험은 조회형보다 기능이 훨씬 많이 얽혀 있는 복합 페이지다.
그 전에 경험 축적, 즉 성찰 로직을 다시 손보려는 이유도 여기에 있다.
코드를 더 잘 생성하게 만들기 위해서만이 아니라, 한 번 해결한 문제를 매번 처음부터 다시 풀지 않는 AI로 만들기 위해서다.