레거시 UI 개선, 전면 리뉴얼 전에 먼저 정해야 할 우선순위 5가지

Jul 20, 2026

오래된 서비스 화면을 보면 가장 먼저 “전면 리뉴얼이 필요하다”는 말이 나온다.

그 판단이 맞을 때도 있다. 화면 구조와 코드가 함께 한계에 닿았다면 부분 수정만으로는 문제를 풀기 어렵다. 다만 많은 경우, 리뉴얼의 범위가 먼저 정해지고 정작 무엇이 사용자와 운영팀을 가장 힘들게 하는지는 나중에 확인한다.

이 순서가 바뀌면 보기 좋은 화면은 만들 수 있어도, 업무가 막히는 지점은 그대로 남는다.

요약

UI가 낡아 보인다는 이유만으로 우선순위를 정하지 않는다.
사용자 작업이 멈추는 빈도와 영향, 사업 목표, 운영팀의 수작업, 수정 난이도를 함께 본다.
점수가 높은 화면부터 작은 범위로 고쳐 검증하고, 그 결과를 다음 개선 범위에 반영한다.
전면 리뉴얼은 선택지 중 하나다. 먼저 문제의 크기와 연결 관계를 파악해야 한다.

오래된 UI의 문제는 화면 수가 아니다

레거시 UI는 오래된 색상이나 버튼 모양을 뜻하지 않는다. 같은 기능이 화면마다 다른 방식으로 작동하고, 새 기능을 붙일 때마다 예외가 늘어나며, 사용자가 익힌 우회 방법이 업무 절차처럼 굳어진 상태에 가깝다.

이런 문제는 작은 수정으로 시작된다. 마감 때문에 검증을 생략하고, 한 화면만 급하게 고치고, 기존 컴포넌트 대신 새 스타일을 얹는다. 각각은 납득할 수 있는 결정이지만 누적되면 UI의 기준이 흐려진다.

이런 상태를 UX 부채라고 부른다. 사용자 경험의 문제를 계속 미루면 나중에 수정 범위와 비용이 커지고, 이미 불편한 흐름에 익숙해진 사용자에게 변경 자체가 부담이 될 수 있다.

그래서 첫 질문은 “무엇을 새로 만들까”가 아니다. 지금 어떤 작업이 실패하거나, 오래 걸리거나, 사람의 도움을 필요로 하는지부터 확인해야 한다.

1. 사용자 작업이 실제로 멈추는 화면부터 찾는다

로그인, 가입, 결제, 신청, 검색, 주문 관리처럼 서비스의 핵심 작업은 작은 불편도 크게 쌓인다. 반대로 사용 빈도가 낮고 업무 영향도 작은 화면은 낡아 보여도 뒤로 미룰 수 있다.

다음 자료를 같은 화면 단위로 모아보면 우선순위가 선명해진다.

고객 문의와 운영팀의 반복 문의
분석 도구에서 확인되는 이탈, 오류, 재시도
사용자 테스트나 인터뷰에서 반복되는 막힘
내부 직원이 쓰는 매뉴얼, 엑셀, 메신저 우회 절차

숫자가 충분하지 않다면 운영 담당자와 사용자 5명 정도의 짧은 인터뷰부터 시작해도 된다. 여기서 필요한 것은 정교한 보고서보다, 반복되는 작업 실패를 구체적인 문장으로 남기는 일이다. 예를 들면 “배송지 변경을 찾지 못해 고객센터에 문의한다”처럼 적는다.

2. 사용자 영향과 사업 영향을 분리해서 본다

불편한 화면이 항상 먼저 고쳐야 할 화면은 아니다. 사용자 영향과 사업 영향이 모두 큰 경우를 먼저 찾아야 한다.

사용자 영향은 작업 실패, 소요 시간, 오류 가능성, 접근성 문제로 판단할 수 있다. 사업 영향은 전환, 매출, 고객 이탈, 계약 처리 지연, 지원 비용처럼 서비스 목표에 연결해 본다.

예를 들어 관리자가 하루에 여러 번 쓰는 주문 처리 화면은 외부 고객이 직접 보지 않아도 우선순위가 높을 수 있다. 처리 오류가 고객 경험과 운영 비용으로 이어지기 때문이다.

“예쁘지 않다”는 개선 이유가 될 수 있지만, 그것만으로는 순서를 정하기 어렵다. 그 화면이 어떤 작업을 어렵게 만들고 그 결과가 무엇인지까지 적어야 팀이 같은 판단을 할 수 있다.

3. 운영팀이 메우고 있는 빈틈을 비용으로 본다

레거시 UI의 문제는 분석 도구에 잘 잡히지 않을 때가 많다. 고객이 실패한 뒤 전화를 걸고, 운영팀이 관리자 화면과 엑셀을 오가며 처리하면 화면의 문제는 사람의 노동으로 가려진다.

다음 신호가 보이면 개선 후보로 올려야 한다.

같은 내용을 여러 시스템에 다시 입력한다.
담당자마다 처리 순서가 다르다.
오류를 막기 위해 개인 메모나 별도 체크리스트를 쓴다.
고객 문의가 들어와야 누락을 발견한다.

운영팀의 우회 절차는 현장 지식이기도 하다. 없애기 전에 왜 필요한지 물어야 한다. 화면이 부족해서 생긴 절차인지, 정책상 반드시 필요한 확인인지 구분하지 않으면 UI만 바꾸고 업무는 더 복잡해질 수 있다.

4. 고칠 수 있는 범위와 연결된 위험을 확인한다

우선순위가 높은 화면이라도 바로 손대면 안 되는 경우가 있다. 오래된 화면은 다른 기능, 권한, 외부 연동과 묶여 있을 수 있다.

개선 후보마다 다음을 확인한다.

이 화면을 쓰는 사용자와 권한은 누구인가
앞뒤 단계와 어떤 데이터가 연결되는가
수정하면 영향을 받는 API, 결제, 정산, 알림, 외부 시스템이 있는가
공통 컴포넌트로 바꿀 수 있는 부분과 화면 전용 규칙은 무엇인가
테스트할 수 있는 실제 업무 시나리오가 있는가

이 확인은 개선을 미루기 위한 절차가 아니다. 작은 수정으로 시작할 수 있는 영역과, 별도 프로젝트로 분리해야 할 영역을 나누기 위한 작업이다.

5. 한 번에 바꾸지 말고, 검증 가능한 단위로 자른다

전면 리뉴얼은 배포 전까지 성과를 확인하기 어렵고, 기존 사용자의 업무 습관을 한 번에 바꾼다. 반면 우선순위가 높은 흐름 하나를 개선하면 변화의 효과와 부작용을 더 빨리 확인할 수 있다.

첫 개선 대상은 다음 조건을 만족하면 좋다.

사용 빈도나 업무 영향이 분명하다.
기존 문제를 설명할 근거가 있다.
수정 범위를 한두 개의 작업 흐름으로 제한할 수 있다.
배포 뒤 확인할 지표나 사용자 피드백 경로가 있다.

예를 들어 회원가입 전체를 다시 만들기보다, 휴대폰 인증 단계에서 이탈이 반복되는지 확인하고 그 단계의 안내 문구, 오류 처리, 입력 방식부터 고칠 수 있다. 개선 전후의 완료율, 재시도, 문의 수를 같은 기준으로 확인하면 다음 우선순위도 감이 아니라 근거로 정할 수 있다.

우선순위 기준을 정리하는 간단한 방법

완벽한 평가 모델은 필요 없다. 팀이 같은 화면을 같은 기준으로 볼 수 있으면 된다. 아래 다섯 항목을 각 1점에서 5점으로 평가해 보자.

사용자 영향: 이 문제 때문에 사용자가 작업을 포기하거나 실수하는가?
사업 영향: 전환, 매출, 계약, 고객 유지, 지원 비용에 영향을 주는가?
발생 빈도: 많은 사람이 자주 겪는가?
운영 부담: 사람이 수작업이나 별도 확인으로 메우고 있는가?
개선 가능성: 현재 범위에서 안전하게 고치고 검증할 수 있는가?

점수는 정답이 아니다. 의견이 갈리는 항목을 드러내는 도구다. 점수 차이가 큰 화면은 근거가 부족하거나 이해관계가 다른 경우가 많다. 그때는 화면을 더 빨리 만들기보다 사용자 기록과 업무 흐름을 다시 확인하는 편이 낫다.

전면 리뉴얼은 언제 필요한가

부분 개선을 반복해도 공통 규칙을 만들 수 없고, 화면 간 데이터 구조나 권한 체계가 충돌하며, 수정할 때마다 회귀 오류가 발생한다면 전면 리뉴얼을 검토할 시점이다.

이때도 시작점은 UI 시안이 아니다. 주요 사용자, 핵심 업무, 현재 시스템의 제약, 이관 범위, 운영 전환 계획을 먼저 합의해야 한다. 대규모 리뉴얼은 디자인 작업만이 아니라 서비스 운영 방식의 변화이기 때문이다.

대규모 리뉴얼도 화면 설계와 개발에 앞서 사용자 요구 조사, 현재 상태 파악, 이해관계자 정렬, 운영 계획을 준비 단계로 두어야 한다.

마무리

레거시 UI를 개선할 때 가장 위험한 결정은 “전체가 낡았으니 전부 바꾸자”는 말만으로 범위를 정하는 일이다.

먼저 사용자의 핵심 작업이 어디에서 멈추는지 확인한다. 그다음 사업과 운영에 미치는 영향을 살피고, 안전하게 검증할 수 있는 단위로 자른다. 이렇게 시작하면 부분 개선이 임시 처방으로 끝나지 않고, 다음 화면을 고칠 기준이 된다.

CTA

서비스 화면이 오래됐다는 이유만으로 전면 리뉴얼을 결정하기 전에, 실제 업무 흐름과 UI 구조를 함께 점검해 보세요. SLUR은 반응형 웹, UI 구조, 디자인 시스템 관점에서 개선 범위를 정리하는 일을 돕습니다.