웹 서비스의 규모가 커지고 관리해야 할 메타데이터의 종류가 늘어날수록, 관리자 전역 페이지의 사용성과 대용량 데이터 처리 속도는 서비스의 생산성을 결정짓는 핵심 지표가 된다.
단순한 데이터 적재를 넘어 사용자가 직관적으로 순서를 바꾸고, 인프라 이전 과정에서도 중단 없는 데이터 정합성을 보장하는 것은 엔터프라이즈급 번역 관리 시스템(TMS)의 필수 과제이다.
관리자 설정 페이지의 사용성 혁신(Drag & Drop API)을 단행하고, 번역 요청 파이프라인 정제, 그리고 레거시 인프라와 신규 SQLite 인프라를 동시에 지원하는 듀얼 모드 마이그레이션 프리뷰 엔진을 성공적으로 구축하였다.
1. HTML5 API를 활용한 Settings 페이지 드래그 앤 드롭 순서 변경 기능
기존의 “위로” / “아래로” 단방향 버튼 방식은 제품, 언어, 플랫폼 등 관리 항목이 늘어날수록 사용자의 클릭 리소스를 과도하게 소모하는 병목 요인이었음. 이를 직관적인 드래그 앤 드롭 정렬 방식으로 전면 개편하였음.
1. UI/UX 요소의 정제: 정렬 기능이 있음을 명시하기 위해 각 로우(Row)에 드래그 핸들 아이콘(
≡)과 안내 문구를 배치하였음.
2. 시각적 피드백 시스템: 드래그가 시작되면 대상 요소의 투명도를
opacity-50으로 조절하여 이동 중임을 알리고, 마우스가 올라가는 드롭 타깃 영역에는ring-2효과를 동적으로 부여하여 적재 위치를 직관적으로 인지하도록 설계하였음.3. 자동 동기화 파이프라인: 드롭 인터랙션이 완료되는 즉시 메모리 상의 배열 순서를 재정렬하고, 내부 순서 필드인
display_order값을 연산하여 백엔드 PATCH API로 자동 저장 요청을 송신하도록 자동화하였음.
ㄱ. 트러블슈팅: 외래 키(Foreign Key) 제약 조건으로 인한 API 호출 실패
순서 변경 API를 가동하는 과정에서 데이터베이스 외래 키 제약 조건(Foreign Key Constraint) 오류로 인해 데이터 업데이트가 거부되는 현상이 관측되었음
[해결 방안]
순서를 일괄 재정렬하는 짧은 트랜잭션 과정에서 제약 조건이 걸려 있으면 데이터 수정 순서에 따라 일시적인 관계 단절이 일어날 수 있음. 이를 해결하기 위해 순서 갱신 쿼리가 실행되기 전PRAGMA foreign_keys = OFF명령어로 제약 조건을 잠시 잠금 해제한 뒤, 일괄 갱신 처리가 완료되면 다시PRAGMA foreign_keys = ON상태로 복구시키는 안전장치를 백엔드에 이식하여 무결성을 유지하며 에러를 완전 소멸시켰음.
2. 제품별 독립 스코프(Scope) 필터링 아키텍처 및 번역 요청 UI 개선
서비스 내 도메인 모델이 다양해짐에 따라, 특정 제품군에서만 사용하는 분류(Scope) 데이터를 격리하여 매핑할 수 있는 관계형 데이터베이스 모델 다이어트 작업을 수행하였음
[제품 테이블] ──> [product_scopes (중간 테이블)] ──> [제품분류 명세]
하이브리드 스코프 설계: 모든 제품군이 공통으로 사용하는 4대 기본 분류(
SaaS,Solution,정부과제,기타)는 전역 공유 구조로 유지하되, 제품별 고유 특화 분류는product_scopes라는 교차 연결용 중간 테이블을 신설하여 정밀 관리하도록 아키텍처를 고도화하였음.컨텍스트 필터링:
/api/scopes?productCode=xxx엔드포인트를 구현하여 프론트엔드 단에서 제품이 선택되면 해당 제품에 바인딩된 고유 스코프 명세만 화면에 동적으로 주입되도록 필터링 시스템을 구축하였음.번역 업로드 파이프라인 결합: 이 아키텍처는 번역 요청하기
Step 1페이지와 즉각 연동되었음. 제품 선택을 필수 가드레일 조건으로 걸어두어 미선택 시 다음 단계로의 진입을 원천 차단하고, 파일 파싱 시 해당 제품 코드가formData에 담겨 백엔드로 유기적으로 흐르도록 동선을 정돈하였음.
3. 대용량 파싱을 위한 Migration Preview API SQLite 모드 확장 전략
이번 스프린트의 가장 큰 기술적 성과는 Pilot 인프라 이전을 위해 기존 Supabase 환경에 더해 SQLite 로컬 데이터 엔진을 동시에 지원하도록 백엔드 중복 체크 파이프라인을 듀얼 모드로 개편한 점에 있다.
4. SQLite 매개변수 변수 한계 극복을 위한 청크(Chunk) 기반 벌크 조회
SQLite 모드 활성화 시 데이터베이스 레이어 내부에서 수천 건의 매핑 리스트를 인덱싱할 때 호스트 변수 제한(Variable Limit)에 걸려 무한 로딩이 걸리거나 응답 불능(Crash) 상태에 빠지는 성능 병목이 발견되었음.
ㄱ. 최적화 파이프라인
N+1 문제를 방지하는 일괄 배치 조회 함수 checkDuplicatesBatch 내부에 SQLite 엔진 전용 분기 분리 로직을 설계하였음. 수천 행에 달하는 대용량 원문 어레이 데이터를 무조건 통으로 인서트 쿼리에 대입하는 대신, 안전 바운더리인 500개 레코드 단위의 청크(Chunk) 배열로 쪼개어 슬라이싱 쿼리를 날리는 루프 파이프라인을 구축하였음.
이 분할 쿼리 최적화 기법 덕분에 498행 이상의 대규모 데이터 파일이나 1,000행이 넘어가는 엔터프라이즈급 현지화 엑셀 시트가 인입되더라도 메모리 병목이나 커넥션 락 현상 없이 밀리초 단위로 중복 데이터를 완전 스캔해 내는 견고함을 달성하였음.
ㄴ. 트러블슈팅: WAL(Write-Ahead Logging) 비정상 종료로 인한 테이블 누락 해결
서버 엔진을 고속화하기 위해 데이터베이스 세션에 WAL 모드를 적용해 둔 상태에서 테스트 인프라가 비정상 종료(Crash)되었을 때, 로그 파일에 잔존하던 데이터 덤프가 메인 .db 파일로 이식되지 못하고 유실되어 테이블 구조가 깨지는 치명적인 정합성 파괴 현상이 보고되었음
[해결 방안]
메모리와 디스크 간의 싱크 시점을 강제 통제하기 위해 시스템 초기화 커넥터 모듈에PRAGMA wal_checkpoint(TRUNCATE)명령 파이프라인을 강제 주입하였음.이 스크립트는 임시 체크포인트에 기록된 모든 변경 이력을 메인 마스터 데이터베이스 디스크 공간으로 안전하게 플러시(Flush)한 뒤 WAL 로그의 용량을 0으로 초기화하므로, 예기치 못한 인프라 다운타임 상황이 닥치더라도 테이블 구조와 인덱스가 절대 손상되지 않는 완벽한 데이터 영속성을 확보하게 되었음.
5. 품질 가이드라인 요약
e886552 (SQLite 프리뷰 지원), 962e3f9 (제품별 스코프 필터링) 등 아키텍처의 중심을 잡아주는 5개의 굵직한 커밋 리스트가 성공적으로 메인 리포지토리에 적용 완료되었음.
프론트엔드 단에서도 PreviewCommitStep 진입 시 발생하던 어색한 깜빡임 문제를 해결하기 위해 전용 로딩 스피너 UI(isLoading prop)를 매핑하여 데이터 연산이 끝나기 전까지 레이아웃의 무너짐을 사전에 방어하도록 마감하였음.
인프라 듀얼 엔진의 기반이 확립된 만큼, 내일부터는 마스터 계정의 API 키 관리 권한 스코프를 유기적으로 확장하고 1,000행 이상의 하이퍼 스트레스 마이그레이션 성능 고도화에 전념할 예정