Work

웹과 모바일 앱의 사용자 흐름부터 Android 장비와 운영 배포까지, 복잡한 경계를 어떤 기준으로 나누고 검증했는지 대표 업무와 보조 경험으로 정리했습니다.

대표 업무

01신규 개발Web / Mobile2026.04 ~ 2026.06

물류 운영·출력 흐름

조회부터 예약·Excel·라벨 출력까지 이어지는 업무 흐름을 웹과 모바일 장비 경계로 연결했습니다.

맡은 범위

신규 구축/출력 연동

업무 운영 / WebView·Android 출력

기술 환경

Web

React
TypeScript
Vite
React Router
TanStack Query
Zustand
XLSX
Vitest

Mobile

Expo
React Native
Expo Router
WebView
Android native module
TypeScript
Bluetooth

문제

예약 접수, 다건 처리, Excel 미리보기, 출력은 같은 업무 흐름이지만 PC 브라우저와 모바일 장비는 별도 앱·저장소와 실행 조건을 가졌습니다. 웹의 초기 로딩 비용을 줄이는 일과 Android 권한·Bluetooth·프린터 SDK를 다루는 일을 분리하면서도 요청 데이터와 실패 기준은 이어져야 했습니다.

핵심 판단

웹은 조회·예약·Excel·출력 요청의 상태와 초기 로딩을 책임지고, 모바일은 WebView contract 이후의 권한·Bluetooth·프린터 출력을 책임지도록 경계를 나눴습니다.

Web

2026.04 ~ 2026.06

물류 운영 웹

반복 업무 화면을 단순히 늘리는 것이 아니라, API 연동, 반응형 UI, Excel 처리, 출력 경로가 같은 기준으로 움직이도록 구성했습니다.

Mobile

2026.04 ~ 2026.06

모바일 출력 브릿지 앱

웹 화면은 WebView로 유지하면서, 모바일에서만 필요한 장비 출력은 native module에 맡기도록 경계를 나눴습니다.

확인한 결과

웹 초기 진입 비용과 모바일 출력 완료를 서로 다른 실행 환경과 검증 기준으로 확인했습니다.

물류 운영 웹

웹 초기 JS entry: 2,405.50 → 616.59 kB; 약 74% 감소. route·spreadsheet 지연 로딩 결과
웹 gzip 기준: 815.10 → 204.38 kB; 약 75% 감소. 동일 초기 entry 비교

모바일 출력 브릿지 앱

모바일 출력 검증: Android 16 / API 36; 권한·Bluetooth 연결·실물 라벨 출력 흐름 확인

남긴 기준

하나의 사용자 흐름이어도 브라우저 성능과 장비 출력은 같은 완료 기준으로 묶지 않는다는 원칙.

세부 구현 및 검증 기록

서로 다른 저장소와 앱으로 구축된 React 운영 웹과 모바일 출력 앱을 하나의 사용자 흐름으로 설명하되, 화면 상태와 장비 SDK의 책임은 섞지 않았습니다.

Web

물류 운영 웹

2026.04 ~ 2026.06업무 운영 / 성능

문제

초기 화면과 Excel 처리 코드가 한 번에 묶이면 첫 로딩이 무거워지고, PC 브라우저와 모바일 WebView 출력 경로가 섞이면 같은 기능도 서로 다른 기준으로 검증될 수 있었습니다.

판단

업무 화면을 먼저 늘리기보다 데이터 연동, 화면 상태, 출력 요청의 경계를 나눴습니다.
초기 진입에 필요하지 않은 route와 spreadsheet 처리는 실행 시점으로 미뤘습니다.
PC 출력, 모바일 브라우저 fallback, WebView/native 출력 요청을 별도 흐름으로 판단했습니다.

해결

공통 shell, table, modal, form, feedback 구조 위에 주요 업무 흐름을 얹었습니다.
예약 접수, 다건 처리, 주소록 선택, Excel 미리보기, 출력 요청 변환을 하나의 흐름으로 연결했습니다.
번들 분석 결과를 기준으로 route-level lazy loading과 spreadsheet library lazy loading을 적용했습니다.

실행

조회, 예약, 주소록, Excel, 출력 흐름을 같은 shell 안에서 이어지도록 먼저 묶었습니다.
모의 데이터와 실제 API adapter를 분리해 화면 상태와 연동 상태를 따로 확인했습니다.
출력 흐름은 PC와 모바일 조건을 나눠 formatter, preview, native 요청을 각각 검증했습니다.
앱, 인증, 공개 API, UI를 더 나눈 실험에서는 500.67 kB(gzip 164.69 kB)까지 줄었지만 초기 인증·API 경계와 첫 클릭 loading 부담이 커져 채택하지 않았습니다.
최종 지연 로딩 범위는 116개 파일·573개 테스트로 확인했고, PC 실물 라벨 출력 경로는 별도로 8개 파일·73개 테스트를 확인했습니다.

성과

초기 JS entry: 약 74% 감소; 초기 진입에 필요하지 않은 화면과 Excel 처리 코드를 분리
gzip 기준: 약 75% 감소; 동일 기준 초기 로딩 비용 감소
반응형 확인: 모바일~데스크톱; 모바일, 태블릿, 데스크톱 주요 폭에서 확인

확인

주요 viewport에서 overflow, modal clipping, dropdown 위치를 확인했습니다.
출력 formatter, bitmap, command, browser fallback 흐름을 회귀 기준으로 확인했습니다.
lint/test/build와 bundle 분석을 반복해 채택한 최적화 범위를 구분했습니다.

Mobile

모바일 출력 브릿지 앱

2026.04 ~ 2026.06WebView / Android native module

문제

웹 버튼으로 출력 요청을 보내는 것과 실제 모바일 장비에서 출력되는 것은 다른 문제였습니다. WebView, 권한, native module, 장비 상태가 한 흐름에 묶이면 실패 지점을 찾기 어려웠습니다.

판단

업무 화면은 웹에 두고, 장비와 직접 맞닿는 출력 책임은 native module로 분리했습니다.
WebView bridge 요청과 native 응답을 구조화된 contract로 다뤘습니다.
개발/운영 URL과 앱 식별자, 설치 산출물 기준을 나눴습니다.

해결

WebView bridge와 Android native module 사이의 요청/응답 흐름을 정리했습니다.
출력 payload 변환, 장비 상태 확인, 실패 메시지를 별도 단계로 나눴습니다.
모바일 브라우저 fallback과 앱 WebView 출력 경로를 구분했습니다.

실행

웹에서 전달되는 출력 데이터를 native 출력 payload로 변환하는 경계를 먼저 잡았습니다.
Bluetooth 권한, 장비 탐색, 연결 상태, 출력 명령을 단계별로 확인했습니다.
로컬 개발, 테스트 설치, 운영 설치 조건을 분리해 잘못된 환경으로 붙는 문제를 줄였습니다.
Android 16/API 36에서 SDK 내부 장비 탐색 호출까지 따라가 취소 흐름과 BLUETOOTH_SCAN·BLUETOOTH_CONNECT 권한을 보완했습니다.
명령 queue 수락과 실제 종이 출력 완료는 다른 검증 기준으로 분리했습니다.

성과

출력 요청 경계: WebView -> native; 웹 payload와 장비 출력 명령을 분리
장비 출력 검증: 실기기 확인; emulator가 아닌 Android 기기 기준으로 확인

확인

Android 실기기에서 권한, 장비 연결, 출력 요청 흐름을 확인했습니다.
WebView bridge 요청과 native 출력 응답이 분리되는지 확인했습니다.
개발/운영 설치 기준과 URL 분기를 확인했습니다.

02신규 개발Web2026.03 ~ 2026.04

구조화된 차트 편집 UI

데이터 역할과 설정 상태가 실제 프리뷰와 어긋나지 않는 편집 흐름을 설계했습니다.

맡은 범위

편집 파트 구축

시각화 / 편집 UI

기술 환경

React
TypeScript
Vite
Chart.js
WebGL/GLSL (OpenGL 계열)
OGL (WebGL 라이브러리)
MSW
Vitest

문제

모든 차트에 같은 옵션을 강제하면 설정 UI가 복잡해지고, preview와 panel state가 따로 움직이면 사용자가 현재 결과를 신뢰하기 어렵습니다.

핵심 판단

차트 타입별 유효 옵션만 노출하고, field mapping·preview lifecycle·settings state를 분리해 같은 편집 모델을 바라보도록 했습니다.

확인한 결과

설정 상태와 실제 프리뷰를 하나의 회귀 범위로 연결해 편집 흐름이 어긋나지 않는지 확인했습니다.

mapping · preview · settings: 상태 동기화; 사용자가 고른 데이터 역할과 설정이 실제 렌더 결과에 이어지도록 정렬
mixed chart preview: 재렌더 조건 축소; 불필요한 remount와 스크롤 흔들림을 줄인 범위로 한정

남긴 기준

편집 도구의 신뢰도는 옵션 수보다 입력 상태와 실제 렌더 결과의 일치에서 나온다는 기준.

세부 구현 및 검증 기록

수제 프리뷰의 확장 한계를 Chart.js 전환으로 풀고, field mapping·preview lifecycle·차트별 설정 책임을 분리했습니다.

문제

모든 차트에 같은 옵션을 강제하면 설정 UI가 복잡해지고, preview와 panel state가 따로 움직이면 사용자가 현재 결과를 신뢰하기 어렵습니다.

판단

차트 타입별 유효 옵션만 보여주는 방향으로 설정 경계를 잡았습니다.
데이터 mapping, preview rendering, settings state를 독립적으로 추적했습니다.

해결

6개 영역의 설정 패널과 preview 흐름을 구성했습니다.
mixed chart 재렌더 조건을 줄여 preview 깜빡임과 스크롤 흔들림을 낮췄습니다.

실행

차트 타입, field mapping, preview, option panel을 같은 편집 흐름으로 맞췄습니다.
설정 변경 때 preview가 불필요하게 다시 붙는 조건을 줄였습니다.
WebGL/GLSL 프래그먼트 셰이더와 OGL로 편집 화면의 배경 모드를 구성했습니다.
portal 도움말, drag overlay, loading·empty·error 상태와 renderer 경계를 별도로 확인했습니다.

성과

설정 구조: 6-tab panel; 차트 설정을 영역별로 분리

확인

preview rendering, option change, panel collapse, drag/drop, tooltip 흐름을 확인했습니다.
관련 테스트, lint, build를 확인했습니다.

03내부 도구 개발Tooling2026.04

AI 보조 프로젝트 문서화 도구

AI가 문서를 대신 쓰는 구조가 아니라, 근거 수집과 사람 검수를 통제 가능한 흐름으로 만들었습니다.

맡은 범위

내부 도구 구축

AI API / 개발 생산성

기술 환경

Node.js
TypeScript
React
AI API
Workbook UI
xlsx
Vitest

문제

비정형 자료를 모델에 바로 넘기면 근거와 추측이 섞이기 쉽고, 일부 문서만 보강하고 싶을 때도 전체 산출물이 흔들릴 수 있었습니다.

핵심 판단

규칙 기반 scanner 결과를 preview한 뒤 AI 초안에 사용하고, workbook을 검수 원장으로 두며 수정 범위는 선택한 sheet와 cell로 제한했습니다.

확인한 결과

근거 수집부터 사람 검수와 선택 범위 수정까지 각 단계를 분리된 검증 경로로 확인했습니다.

scanner → preview: 근거 우선; 규칙 기반 수집 결과를 먼저 확인한 뒤 AI 초안에 사용
사람 중심 산출물: workbook 검수; 요구사항·기능·화면 단위를 표로 검토하고 export
sheet / cell revision: 선택 범위 수정; 전체 재생성 대신 수정 대상과 보존 문맥을 함께 전달

남긴 기준

AI 보조는 근거 입력, 사람 검수, 부분 수정의 경계를 명시해 검토 가능한 산출물을 남긴다는 기준.

세부 구현 및 검증 기록

프로젝트 착수 자료와 로컬 저장소 근거를 바탕으로 요구사항 후보, 확인 질문, 기능/화면 문서 초안을 만들고 workbook에서 검토할 수 있게 구성했습니다.

문제

비정형 자료를 모델에 바로 넘기면 근거와 추측이 섞이기 쉽고, 일부 문서만 보강하고 싶을 때도 전체 산출물이 흔들릴 수 있었습니다.

판단

규칙 기반 scanner 결과를 먼저 만들고, AI 생성은 그 다음 단계에 두었습니다.
workbook JSON을 중심 모델로 두고 markdown과 export는 파생 결과로 판단했습니다.
자동화는 초안 생성까지 맡기고 최종 검토와 보강은 사람이 확인할 수 있는 표 구조로 남겼습니다.

해결

run workflow, scanner 결과, preview, detail artifact, logs, export 흐름을 연결했습니다.
요구사항 원장, 기능 정의서, 화면 설계서 성격의 문서를 workbook으로 검토할 수 있게 했습니다.
사용자가 수정하려는 sheet/cell과 보존해야 할 내용을 함께 전달하는 revision 흐름을 만들었습니다.

실행

자료 스캔 결과를 preview로 보여준 뒤 사용자가 문서화 방향을 확인할 수 있게 했습니다.
생성 결과는 긴 문장 묶음이 아니라 workbook sheet 단위로 나눠 검토할 수 있게 했습니다.
수정은 전체 재생성이 아니라 선택한 sheet/cell 문맥을 기준으로 다시 요청하도록 좁혔습니다.
부분 실패는 manifest와 current/history artifact를 분리해 성공한 결과와 실패한 실행을 함께 추적했습니다.
AI가 정리할 수 있는 항목과 사용자가 결정해야 하는 항목을 나누고, 근거 없는 placeholder 생성을 억제했습니다.

성과

생성 입력 흐름: Scan -> Preview; 규칙 기반 스캔 결과를 바탕으로 AI 초안 생성
검수 산출물: xlsx workbook; 요구사항/기능/화면 단위를 표로 검토
부분 보강: Selected cell revision; 선택 시트와 셀 기준으로 재작성 범위 축소

확인

자료 스캔, AI preview, workbook 렌더링, export 흐름을 확인했습니다.
선택 시트/셀 기반 재작성과 기존 workbook 보존 흐름을 확인했습니다.
shared, engine, server, web 테스트와 lint/build를 확인했습니다.

04유지보수Hybrid2026.06 ~ 2026.07

생활정보 하이브리드 서비스

레거시 웹과 Android WebView의 외부 API, 캐시, 위치 처리와 운영 배포를 유지보수했습니다.

맡은 범위

유지보수/운영 반영

레거시 웹 / Android WebView / 운영

기술 환경

Spring MVC
JSP
jQuery
Java
Android
Public API adapter
SHA-256

문제

여러 외부 API와 기준 데이터 조회가 한 요청 안에 묶이면 일부 지연이 전체 화면 지연으로 번질 수 있었습니다. 운영 반영도 파일 단위로 이뤄져 누락과 설정 노출 위험을 함께 관리해야 했습니다.

핵심 판단

핵심·보조 loading, fresh·stale cache, 기준 데이터 cache를 분리하고 운영 반영은 manifest와 SHA-256 hash 단위로 좁혔습니다.

확인한 결과

캐시 성능, 회귀 테스트, 날짜별 운영 배포를 서로 다른 기준으로 확인하고 기록했습니다.

core 운영 smoke: 약 2.85초 → 0.11초; 2026-07-08 당시 cold 요청과 cache HIT 비교
대기질 운영 smoke: 약 2.02초 → 0.07초; 2026-07-08 당시 cold 요청과 cache HIT 비교
최종 회귀: 131 tests / skipped 1; 최종 mvn test로 확인하고 운영 반영 후에는 hash와 smoke를 별도로 확인

남긴 기준

레거시 운영 개선은 바꾼 범위뿐 아니라 보존한 계약과 fallback·배포 증거까지 함께 남겨야 한다는 기준.

세부 구현 및 검증 기록

웹 화면과 Android WebView를 고치고 외부 API 응답, 기준 데이터 캐시, 운영 배포 결과를 실제 화면에서 점검했습니다.

문제

판단

먼저 보여야 하는 핵심 정보와 늦게 채워져도 되는 보조 정보를 분리했습니다.
fresh cache와 stale cache를 나눠 외부 API 실패 시 제한적으로 이전 값을 활용할 수 있게 판단했습니다.
운영 반영은 전체 산출물을 덮어쓰기보다 manifest, hash, smoke 기준으로 범위를 좁혔습니다.

해결

핵심 정보 우선 loading과 section별 cache 기준을 구성했습니다.
기준 데이터를 서버 cache로 준비하고 임시 저장, 검증, 교체 흐름을 만들었습니다.
Android WebView에서는 native 위치 흐름을 우선 사용하고 저장 위치와 browser fallback을 함께 두었습니다.

실행

외부 API 호출, 기준 데이터 조회, 위치 fallback을 화면 loading 순서와 맞춰 다시 나눴습니다.
기준 데이터는 수집, 임시 저장, 필수값 검증, 교체 순서로 운영 반영 위험을 줄였습니다.
운영 파일은 변경 범위와 hash를 확인한 뒤 smoke로 실제 화면 흐름을 다시 확인했습니다.
요청 경로 밖에 대기질 측정소 673행과 법정동 20,560행의 기준 cache를 준비했습니다.
2026-07-02의 111개 파일 배포와 2026-07-08의 42개 manifest 배포는 서로 다른 작업으로 나눠 검증했습니다.
기준 데이터 갱신과 catalog 축소 자동화는 후속 과제로 남았고, JVM memory cache는 단일 Tomcat 범위라는 제한이 있습니다.

성과

기준 데이터 cache: 필수값 검증; 서버 cache로 준비하고 누락 여부를 확인
지역 해석 흐름: fallback 기준; 외부 조회 실패나 지연에 대비한 기준 분리
운영 반영 확인: smoke 기준; 변경 파일과 주요 화면 흐름을 함께 확인

확인

기준 데이터 수집 결과와 필수값 누락 여부를 확인했습니다.
cold request와 cache hit 흐름을 smoke 기준으로 비교했습니다.
운영 반영 대상 파일의 hash 일치 여부와 주요 화면 흐름을 확인했습니다.

함께 정리한 업무

기능 확장과 유지보수에서 변경 범위와 회귀 기준을 정리한 경험입니다.

유지보수Android / Hybrid2026.03

레거시 모바일 앱 호환성

기술 환경

Android Java
Gradle/AGP
RxJava
FileProvider

핵심 판단

빌드 성공과 런타임 호환성을 같은 완료 조건으로 취급하지 않았습니다.

확인한 결과

Gradle/AGP/JDK/SDK: 빌드 기준선 복구; 빌드 도구 변경과 target SDK·런타임 동작 변경을 분리

debug와 release 빌드, IDE sync와 compile 경로를 확인했습니다.

세부 구현 및 검증 기록

최신 Android 빌드 정책 대응과 구형 런타임 회귀를 서로 다른 검증 축으로 분리했습니다.

오래된 Android 하이브리드 앱에서 빌드 체인, 권한과 파일 처리, WebView bridge, 로그인과 초기 동기화를 한꺼번에 바꾸지 않고 실패 경계별로 안정화했습니다.

문제

구형 Gradle·AGP와 최신 개발 환경이 맞지 않았고, 최신 SDK 정책을 그대로 적용하면 파일 접근, 권한, service, back API가 구형 OS 진입과 WebView 흐름에 별도 회귀를 만들 수 있었습니다.

판단

최신 API 타입과 OS별 권한·파일 처리는 화면 코드가 아니라 compatibility helper 경계에 두었습니다.
로그인, 초기 동기화, WebView navigation, bridge 오류를 서로 다른 실패 채널로 나눴습니다.

해결

레거시 support 의존성의 전면 재작성 없이 컴파일 가능한 기준선을 만들었습니다.
최신 back API 직접 참조와 파일·권한 분기를 helper 안으로 캡슐화했습니다.
WebView bridge 응답과 비동기 오류를 정규화하고, 장비·외부 기능 실패가 앱 전체 종료로 번지지 않는 fallback을 정리했습니다.

실행

Gradle, AGP, JDK, compile SDK와 module namespace를 단계적으로 정렬했습니다.
content URI, FileProvider, Bluetooth 권한, scanner와 service 실행 조건을 OS 정책별로 점검했습니다.
bridge null/error 응답, 비동기 종료, 로그인과 초기 동기화 실패를 분리해 회귀 원인을 좁혔습니다.

성과

OS별 분기: 호환성 경계; 권한, 파일 URI, back API, service 호출을 helper로 격리

확인

호환성 helper와 bridge fallback의 단위 테스트를 확인했습니다.
구형 OS 확인이 필요한 항목과 정적 빌드로 확인한 항목을 분리해 남겼습니다.

React 신규 재구축Web2026.03

주식 업무 관리 웹

기술 환경

React
TypeScript
Vite
React Router
TanStack Query
Zustand

핵심 판단

반복 table/filter/modal 패턴은 공통 primitive로 묶되, 업무별 의미는 각 화면에 남겼습니다.

확인한 결과

서버 상태 흐름: React Query; 화면별 조회/갱신 기준 통일

table, filter, modal, session 흐름을 화면 단위로 확인했습니다.

세부 구현 및 검증 기록

기존 화면의 업무 절차를 살펴본 뒤 목록, 검색, 상세, Excel 처리 화면을 React로 새로 만들었습니다.

목록 조회, 검색 모달, 상세 확인, 등록/수정, 상태 변경처럼 반복되는 관리 흐름을 공통 구조로 잡았습니다.

문제

주식 업무 화면에서 직접 DOM 조작에 의존하면 비슷한 테이블과 모달이 늘어날수록 변경 지점이 흩어지고, 공통 문제가 화면별 예외로 남을 수 있었습니다.

판단

서버 데이터 갱신은 React Query 흐름으로 모으고 화면 상태는 별도로 관리했습니다.

해결

공통 table, filter, modal, top bar 패턴을 재사용 가능한 구조로 정리했습니다.
컬럼 고정/리사이즈, truncate tooltip, copy, infinite scroll 같은 반복 기능을 일반화했습니다.

실행

반복되는 table, filter, modal, top bar 동작을 먼저 공통 기준으로 모았습니다.
각 화면의 column, action, session 흐름은 공통 기준 위에 얹는 방식으로 정리했습니다.

기능 확장Hybrid2026.06

하이브리드 외부 연동 기능 확장

기술 환경

Android
Cordova
Spring MVC
jQuery
Java

핵심 판단

외부 조회 책임은 server-side proxy에만 두었습니다.

확인한 결과

인증 정보 경계: server-side proxy; 외부 연동 책임을 client 밖으로 분리

문서와 예시 설정에서 실제 credential 값이 검색되지 않는지 확인했습니다.

세부 구현 및 검증 기록

외부 인증 정보를 클라이언트에 두지 않고 서버 프록시와 WebView QA 경계로 나눴습니다.

하이브리드 앱에서 외부 연동, 응답 정규화, 이미지 입력, file picker, route, bridge가 함께 움직이는 범위를 정리했습니다.

문제

외부 인증 정보가 Android APK나 browser JavaScript에 들어가면 노출될 수 있고, 외부 응답 전체를 화면에 전달하면 불필요한 원문 데이터가 섞일 수 있었습니다.

판단

client에는 화면에 필요한 최소 결과와 상태만 내려주도록 계약을 좁혔습니다.

해결

예시 설정과 credential 검색 기준을 정리했습니다.
file chooser를 입력 source와 native picker 흐름으로 나눴습니다.

실행

client 입력, server proxy, 외부 응답, 화면 표시 값을 순서대로 분리했습니다.
WebView file chooser는 입력 source별로 emulator와 실기기 확인 범위를 나눴습니다.

확인

emulator와 실기기에서 route, file chooser, tab sync, bridge 흐름을 확인했습니다.

유지보수Android2026.03 ~ 2026.04

현장 단말 Android 앱

기술 환경

Android Java
Gradle/AGP
Scanner SDK

핵심 판단

운영 배포 조건과 로컬 개발 빌드 가능 여부를 분리했습니다.

확인한 결과

Gradle/JDK 정리: 빌드 복구; 운영 서명 유무와 개발 빌드 경로 분리

개발/운영 빌드 경로와 주요 진입 흐름을 확인했습니다.

세부 구현 및 검증 기록

운영 서명과 최근 빌드 환경을 분리해 현장 앱을 다시 확인 가능한 상태로 만들었습니다.

현장 단말에서 쓰이는 Android 앱의 빌드와 런타임 흐름을 복구했습니다. 빌드 도구, 서명, 로그인, 초기 데이터, 스캔 입력을 나눠 확인했습니다.

문제

운영 서명이나 오래된 빌드 조건이 맞지 않으면 개발자가 기능을 확인하기 전부터 막힐 수 있고, emulator에서 되는 흐름이 실제 단말에서는 입력 timing 때문에 실패할 수 있었습니다.

판단

빌드 도구 최신화와 런타임 동작 변경을 같은 문제로 묶지 않았습니다.

해결

운영 서명이 없어도 개발 빌드가 막히지 않도록 조건을 분리했습니다.
입력 장비 흐름은 실제 단말 기준으로 확인해야 하는 항목으로 남겼습니다.

실행

Gradle, JDK, SDK, 서명 조건을 나눠 빌드 실패 원인을 좁혔습니다.
로그인, 초기 데이터, 스캔 입력 흐름을 별도 단계로 확인했습니다.

성과

스캔/장비 흐름: 현장 입력; 로그인, 초기 동기화, 입력 흐름을 나눠 확인

확인

스캔 입력과 초기 데이터 흐름을 단계별로 확인했습니다.

영향 분석Legacy Web2026.06

레거시 웹 패널 분리 기준선

기술 환경

JSP
jQuery
Server-rendered web

핵심 판단

분리 대상과 비대상을 먼저 나누고, 기존 결함과 새 regression을 구분했습니다.

확인한 결과

변경 전 지도화: impact map; selector, popup, loader, contract 위험 분리

browser 접근 기준과 page loader 흐름을 확인했습니다.

세부 구현 및 검증 기록

레거시 화면을 바로 쪼개기 전에 coupling, API contract, browser baseline을 먼저 만들었습니다.

공유 popup, selector prefix, list state, page loader, backend parameter order를 먼저 확인해 변경 위험을 줄였습니다.

문제

오래된 패널 안에서는 여러 메뉴와 popup callback이 같은 스크립트를 공유하고 있어, 파일만 나누면 주변 기능이 함께 깨질 위험이 있었습니다.

판단

backend parameter와 upload/download 계약은 이번 분리에서 바꾸지 않는 것으로 고정했습니다.

해결

impact matrix, API contract, manual verification runbook, runtime baseline을 정리했습니다.
구현 전 static search 목록과 stop signal을 남겼습니다.

실행

공유 popup, selector prefix, page loader, backend parameter 순서로 영향 지점을 확인했습니다.
코드를 바로 나누기 전에 수동 확인 runbook과 stop signal을 먼저 남겼습니다.