[🛠] Operations Automation #5: 실패한 프로토타입을 UI 감사 기준으로 바꿨다

✨ GPT-5.6 Sol의 요약 　

여백 덩어리 카드와 망가진 테이블을 화면별로 고치는 대신, 검색·필터·다행 행·현재 화면 다운로드와 편집 위험 분류를 공용 UI 감사 기준으로 만든 기록.

큰 카드와 넉넉한 여백이 화면을 망쳤다

50대 이상 회사원과 관리자가 쓸 연차 관리 화면을 다시 설계하고 있었다. 큰 글자, 큰 조작 영역, 충분한 여백을 요구했다. 그런데 프로토타입은 그 말을 가장 단순하고 끔찍한 방식으로 해석했다.

한 줄이면 될 수치를 항목명 → 큰 숫자 → 보조 설명 세 줄로 찢어 거대한 카드에 넣었다. 카드 세 개가 첫 화면을 다 먹었지만, 정작 사용자가 지금 처리해야 할 일은 아래로 밀렸다. 신청 화면은 달력, 요약, 입력을 커다란 흰 상자로 따로 쌓았고, 내역 table은 핵심 값이 비어 있는데 상태 badge만 남았다. 가로 scroll까지 생겼다.

예전에 실제 모바일 기기에서 찌그러진 table과 filter를 고쳤을 때는 overflow와 줄바꿈을 없애면 화면이 나아졌다고 생각했다. 이번 프로토타입은 그보다 더 근본적인 문제를 보여 줬다. 안 깨지는 화면과 쓸 수 있는 화면은 전혀 달랐다.

UI 감사 기준이 화면보다 먼저 깨져 있었다

더 큰 문제는 별도의 감사 절차를 돌렸는데도 이런 화면이 살아남았다는 점이었다.

감사는 route가 열리는지, 글자가 잘리지 않는지, control을 누를 수 있는지, 색과 간격이 크게 어긋나지 않는지를 봤다. 하지만 아래 질문은 강제하지 않았다.

• 첫 화면에서 사용자가 지금 처리할 일을 찾을 수 있는가
• 같은 판단에 필요한 값이 한 시야에 모여 있는가
• 빈 공간이 정보의 관계를 설명하는가, 그냥 component 크기를 채우는가
• table의 검색·필터·정렬·전체 건수·결과가 하나의 흐름으로 이어지는가
• 조회한 결과를 그대로 내려받아 다시 사용할 수 있는가
• 수정 가능한 값과 덮어쓰면 안 되는 이력이 구분되는가

감사 항목에 없으면 Agent는 문제를 보면서도 통과시킨다. 그래서 화면마다 padding을 줄이는 대신, 이 실패를 다시 통과시킬 수 없도록 공용 감사 기준부터 고쳤다.

Collection은 검색·결과·다운로드를 한 덩어리로 묶었다

가장 많이 뜯어본 참고 화면은 타사 연차관리 앱의 요청 관리 table이었다. 공식 도움말에서도 웹 관리자 모드의 날짜 조회, 요청 filter, 승인·거절 흐름을 한 업무로 설명한다.¹ 참고 이미지에서 더 눈에 들어온 것은 기능 개수가 아니라 기능 사이의 거리였다.

기간과 요청 유형은 결과 바로 위에 있었다. 검색칸은 각 열과 맞물렸고, 전체 요청 수와 download가 같은 시야에 있었다. 한 요청의 날짜, 변경 전후, 근무시간 차이처럼 함께 읽어야 할 값은 열을 끝없이 늘리지 않고 한 cell 안에 여러 줄로 묶었다. 상태와 가능한 action도 같은 행에서 이어졌다.

이 구조를 특정 연차 화면에만 복사하지 않고 collection 공통 계약으로 일반화했다.

• table, grid, 밀도 높은 목록, calendar의 목록 보기는 결과 바로 위에 search/filter block을 둔다.
• 기간·scope, 검색, 빠른 filter, 상세 filter, 적용 조건, 전체/현재 건수, 초기화, download를 같은 시야에 둔다.
• 같은 판단에 쓰는 값은 주 정보 → 보조 정보 → 조건부 경고 순서의 다행 cell로 묶는다.
• 행 높이는 내용이 결정한다. 여러 줄을 쓴다는 이유로 고정 높이 mini card를 만들지 않는다.
• download는 현재 page에 보이는 몇 행이 아니라 현재 조건에 맞는 전체 결과를 내보낸다.
• export에는 현재 scope, 기간, 검색, filter, 정렬, 기준 시각과 사용자가 보는 업무 열을 그대로 보존한다.
• 개인정보와 감사 자료도 download를 통째로 없애지 않고 같은 권한·masking·audit를 적용한다.

다운로드 버튼이 있다만 검사하면 또 실패한다. 실제 화면의 건수와 대표 행, 적용된 filter, 정렬, masking이 내려받은 파일과 같은지까지 비교해야 한다.

편집 방식은 데이터 위험도에 따라 갈랐다

table에서 값을 바로 고칠 수 있으면 편하다. 그렇다고 모든 cell을 Excel처럼 만들면 승인, 원장, 법적 증거까지 평범한 입력칸으로 덮어쓸 수 있게 된다.

그래서 편집 control보다 먼저 변경의 성격을 나눴다.

변경 성격	기본 interaction
되돌릴 수 있는 단일 저위험 값	눈에 보이는 편집 affordance가 있는 inline edit
여러 행의 안전한 반복 수정	명시적인 editable-grid mode
주변 맥락을 함께 봐야 하는 여러 field	목록 위치를 보존하는 side panel
짧고 독립적인 입력·확인	목적이 하나인 modal
고위험·효력일·권한·version·append-only 변경	별도 preview-and-apply 또는 correction workflow

double-click, Enter, F2는 숙련자를 위한 가속 수단으로만 둔다. 편집 진입을 그것에만 숨기지 않는다. grid에는 keyboard 이동, 변경 cell 표시, validation, undo, 전체 취소, stale 충돌, 적용 전 preview와 적용 뒤 readback이 필요하다. 승인·반려와 append-only 원장 사건은 cell edit 대상이 아니다.

공용 감사 규칙과 제품 계약을 분리했다

참고 화면에서 배운 것을 전부 Leave Operations 전용 규칙으로 적으면 다음 프로젝트에서는 같은 실수를 다시 한다. 반대로 연차의 승인 단계, 촉진 문서, 원장 보정 같은 업무 규칙까지 공용 Skill에 넣으면 공용 기준이 특정 제품의 설계서가 된다.

그래서 경계를 나눴다.

공용 규칙과 UI 감사 Skill에는 다음 실패 유형을 넣었다.

• 짧은 scalar를 거대한 독립 card로 만드는 구조
• label·값·분모를 기계적으로 세 줄로 쪼개는 구조
• 결과와 떨어진 검색·filter
• 전체 건수·초기화·현재 화면 download가 없는 collection
• 관련 값을 과도한 열로 펼치거나 고정 높이 다행 행으로 만드는 table
• 권한과 현재 화면 조건이 다른 export
• hover나 double-click에만 숨은 편집
• 고위험·versioned·append-only 데이터를 일반 cell이나 popup으로 덮어쓰는 동작

Leave Operations 문서에는 그 원칙을 어느 page의 어떤 view에 쓸지 따로 배치했다. 승인함, 직원, 촉진, 원장, 출근부 충돌, 문자 결과, 업무폰 같은 table마다 검색·filter·정렬·다운로드 계약을 두고, 직원·소속처럼 반복 수정이 필요한 곳과 승인·원장처럼 직접 수정하면 안 되는 곳을 나눴다.

아직 화면은 고치지 않았다

이번 작업으로 실제 제품 UI가 좋아진 것은 아니다. 공용 규칙, UI 전용 감사 Skill, 제품별 화면 계약을 고쳤고, 참고 이미지를 원본 hash와 함께 보존했다. 아직 Leave Operations 데스크톱 화면을 그 계약대로 구현하지 않았고, 50대 회사원·관리자가 정상 진입점에서 직접 업무를 끝내는 검증도 하지 않았다.

그래도 다음 프로토타입은 최소한 같은 이유로 통과해서는 안 된다. 큰 글자와 충분한 조작 영역은 그대로 지키되, 화면을 비대하게 만드는 핑계로 쓰지 않는다. 목표는 낮은 정보 밀도가 아니라 높은 정보 밀도와 낮은 인지 부담이다.

참고 자료

1. 시프티 고객센터, 요청 관리하기. 웹 관리자 모드에서 날짜 범위와 요청 filter로 대상을 찾고, 요청별 승인·거절과 다음 요청 이동을 처리하는 흐름을 설명한다. ↩