AI 번역 관리 시스템에서 용어집(Glossary)은 서비스의 일관성을 결정짓는 핵심적인 자산이다.
“완벽한 데이터는 없다, 오직 완벽하게 관리되는 이력만이 있을 뿐이다.”
하지만 사람이 운영하는 시스템에서 실수는 반드시 발생하며, 때로는 여러 사용자가 동시에 같은 단어를 수정하다 데이터가 꼬이는 ‘동시성 충돌’ 문제에 직면하게 된다.
7일 차, 사용자의 실수를 완벽하게 복구하는 필드별 롤백 기능과 데이터 무결성을 보장하는 낙관적 락(Optimistic Locking) 시스템을 구축했다.
또한, 구글 문서처럼 시스템 전체의 변화를 한눈에 파악하는 통합 변경 이력 센터를 구현하여 관리 효율성을 극대화했음.
1. 낙관적 락(Optimistic Locking) – 데이터 충돌의 원천 차단
ㄱ. 왜 ‘낙관적 락’인가? 비즈니스적 결정 근거
여러 사용자가 동시에 접속하는 환경에서 ‘마지막에 저장한 사람’이 이전 사람의 노력을 무시하고 덮어쓰는 사고는 빈번하게 일어난다. 이를 막기 위해 데이터베이스 자체를 잠가버리는 ‘비관적 락’은 성능 저하가 심해 채택하지 않았음.
대신, 데이터에 버전(Version) 정보를 부여하고 수정 시점에 버전이 일치하는지 확인하는 낙관적 락(Optimistic Concurrency Control) 방식을 선택했다.
ㄴ. 버전 기반 동시 수정 감지 서비스 구현
OptimisticLockService를 구축하여 모든 수정 요청 전에 현재 DB의 버전과 클라이언트가 알고 있는 버전을 대조하도록 했다.
만약 버전이 다르다면 서버는 즉시 EDIT_CONFLICT 에러를 반환하고 수정을 중단한다. 사용자는 “다른 사용자가 이미 수정했습니다”라는 메시지와 함께 현재 서버의 최신 데이터를 확인하고 다시 작업을 진행하게 되어, 데이터가 유실되는 사고를 원천 방지했음.
2. 용어집 롤백 시스템 – 시간을 되돌리는 기술
ㄱ. Audit Log 기반의 정교한 필터별 복구 로직
단순히 전체 데이터를 이전으로 돌리는 것은 위험하다. 특정 필드(용어, 번역, 문맥 등)만 골라서 복구하고 싶어 하는 사용자의 니즈를 반영했다. glossary_audit_logs 테이블을 설계하여 어떤 사용자가 어떤 필드를 기존 값(old_value)에서 새 값(new_value)으로 바꿨는지 모든 흔적을 기록했음.
GlossaryRollbackService는 이 감사 로그(Audit Log)를 추적하여 사용자가 원하는 시점의 값으로 데이터를 되돌린다. 롤백 시에도 낙관적 락을 적용하여 롤백을 시도하는 도중에 다른 수정이 일어났는지 체크하는 이중 안전장치를 마련했음.
ㄴ. PostgreSQL 함수(RPC)를 이용한 원자적 실행
롤백은 ‘데이터 수정’과 ‘롤백 로그 기록’이 한꺼번에 성공해야 하는 원자적(Atomic) 작업이다.
이를 위해 execute_glossary_rollback이라는 트랜잭션 함수를 PostgreSQL 내부에 직접 구현했다. FOR UPDATE 구문을 사용해 롤백이 진행되는 찰나의 순간에도 데이터 일관성이 깨지지 않도록 DB 레벨에서 락을 걸어 처리했음.
3. 통합 변경 이력 센터 – 구글 스타일의 타임라인 UX
ㄱ. 시스템 전체의 변화를 읽는 슬라이드 패널 디자인
사용자가 각 항목을 일일이 클릭하지 않아도 시스템 전체의 변화를 파악할 수 있도록 글로벌 변경 이력(Global Change History) 패널을 도입했다. 화면 오른쪽에서 슬라이드 형태로 나타나는 이 패널은 구글 문서의 ‘버전 기록’ 인터페이스를 벤치마킹하여 친숙함을 더했음.
사용자는 페이지별 필터링 기능을 통해 ‘용어집’의 변경 사항만 모아보거나, ‘번역 관리’의 이력만 따로 조회할 수 있다. 모든 히스토리 아이템에는 롤백 버튼이 내장되어 있어, 관리자는 이상 징후 발견 시 즉각적인 대응이 가능해졌음.
ㄴ. 충돌 해결 모달과 사용자 피드백 강화
동시 수정 충돌이 발생했을 때 사용자는 당황하기 마련이다. 이를 방지하기 위해 ConflictResolutionModal을 구현했다. 단순히 에러만 띄우는 것이 아니라, ‘내가 수정하려던 내용’과 ‘서버에 이미 저장된 내용’을 나란히 보여주어 사용자가 ‘덮어쓰기’를 할지 ‘취소’를 할지 현명하게 선택할 수 있도록 도왔음.
4. 보안 및 성능 최적화 전략
ㄱ. 권한 제어와 Rate Limiting의 결합
롤백 기능은 데이터를 직접 수정하는 강력한 도구이므로 철저한 보안이 필요하다. Supabase의 RLS(Row Level Security) 정책을 활용해 권한이 없는 사용자의 접근을 차단했다. 또한, 벌크(Bulk) 롤백 시 시스템 부하를 막기 위해 한 번에 최대 100개까지만 처리하도록 제한하는 Rate Limiting을 적용했음.
ㄴ. 성능 지표와 최적화 포인트
대량의 감사 로그가 쌓여도 조회 성능이 떨어지지 않도록 복합 인덱스(glossary_term_id, created_at)를 최적화했다.
그 결과 단일 롤백은 45ms, 10개 이상의 벌크 작업도 300ms 이내에 완료되는 쾌적한 속도를 확보했음. 네트워크 왕복 횟수를 줄이기 위해 RPC 함수를 적극적으로 활용한 것이 성능 향상의 핵심이었음.
5. 데이터 신뢰성이 시스템의 품격을 만든다
ㄱ. 기술적 부채를 청산하고 데이터의 주인으로
이번 7일 차 작업은 단순한 기능 추가를 넘어 시스템의 데이터 신뢰성을 완성하는 과정이었다.
낙관적 락을 통해 동시성 문제를 해결했고, 필드별 롤백으로 사용자에게 ‘실수할 권리’와 ‘복구할 능력’을 동시에 부여했음. 통합 이력 센터는 관리자가 시스템의 모든 흐름을 장악할 수 있게 해주는 강력한 무기가 되었다.
ㄴ. 7일간의 여정
1. 속도: 단일 롤백 처리 시간 100ms 미만 달성
2. 안전: 낙관적 락 도입으로 동시 편집 충돌 사고 0건 달성
3. 편의: 통합 이력 센터를 통한 관리 효율성 200% 증대
앞으로 Redis를 활용한 분산 락이나 실시간 알림 기능을 추가해 시스템을 더욱 견고하게 다듬어 나갈 예정이다.
근데, 다듬으면 다듬을 수록 왜 이렇게 해야할 것이 많은지 의문이다…!