외부 UI/UX 프롬프트로 DB 러너 화면을 점검했습니다

외부에서 받은 UI/UX 프롬프트 네 개를 AI에게 검토하게 했습니다. 화면의 정보 배치, 입력 폼, 작은 화면 대응, 접근성을 점검하는 지시문이었습니다. 저는 검토에 그치지 않고 실제 화면을 개선한 뒤, 자료를 받아 적용하는 과정까지 The Forge에 정리해 달라고 요청했습니다.

대상은 제가 쓰는 DB 러너 현황판이었습니다. DB 러너는 데이터베이스에 등록된 작업의 실행을 관리하는 프로그램입니다. 이번에는 작업을 실행하는 기능을 바꾸지 않고, 그 상태와 예정시각을 보여주는 화면을 고쳤습니다.

처음부터 대상이 정확히 맞지는 않았습니다. 이전에 만든 화면과 현재 운영 화면이 달랐고, 제가 DB 러너를 말한 것인지 다시 확인하는 과정이 있었습니다. 화면을 찾은 뒤에는 현재 코드와 저장소 사본도 대조했습니다. 저장소 쪽이 오래돼 있어 실제 운영 중인 파일을 기준으로 작업본을 만들었습니다.

받은 프롬프트와 보완한 검사 조건

외부 게시물에서 전달받은 문구를 제 작업에 맞게 고치는 데서 시작했습니다. 원 게시물 전체를 확보하지 못해 전달받은 문구만 검토했습니다. 특정 모델의 효과 비교 시험은 이번 작업 범위 밖이었습니다.

지시문에는 문제를 찾고, 화면을 수정한 뒤, 여러 폭에서 다시 확인하는 순서가 있었습니다. 그대로 적용하기에는 조건을 더 구체적으로 써야 했습니다. 문제는 실제로 발견한 만큼만 적도록 했습니다. 다섯 개보다 적어도 숫자를 채우려고 문제를 만들어서는 안 된다는 조건입니다. 디자인 수정과 실제 서비스 반영은 별도로 다뤘습니다. 폼 개선은 이번 화면에 필요 없어 적용 범위에서 뺐습니다.

작은 화면 검사에는 원래 지시문의 390px에 더해 320 CSS px 폭을 넣었습니다. CSS px는 브라우저에서 화면 배치에 쓰는 길이 단위입니다. 웹 접근성 지침인 WCAG의 리플로 기준은 세로로 읽는 콘텐츠가 320 CSS px 상당 폭에서도 정보와 기능을 잃지 않고 재배치되는지를 봅니다. 표나 지도처럼 의미상 두 방향 배치가 필요한 부분에는 예외가 있습니다. 표를 카드로 바꿀지는 이 예외와 화면의 쓰임을 보고 판단하도록 고쳤습니다. W3C 리플로 설명

접근성 숫자도 구분했습니다. 버튼의 누를 수 있는 영역을 44×44 CSS px로 확보하는 목표와 WCAG AA의 최소 기준은 다릅니다. AA 기준은 24×24 CSS px이며 간격·본문 안 링크 등의 예외가 있습니다. 44×44는 더 높은 AAA 기준에 해당합니다. 최소 타깃 크기 · 강화 타깃 크기

대비는 요소별 기준을 적용하도록 고쳤습니다. 일반 텍스트는 4.5:1, 큰 텍스트는 3:1이며 비활성 요소·장식·로고 등의 예외를 따로 봐야 합니다. 버튼 같은 컨트롤이나 상태를 알아보는 데 필요한 시각 정보에는 별도의 비텍스트 대비 기준이 있습니다. 텍스트 대비 · 비텍스트 대비

DB 러너 현황판의 수정 범위

Claude가 현재 화면을 브라우저로 확인한 결과, 작은 폭에서 작업 단계를 표시하는 작은 표식들이 카드 밖으로 나왔습니다. 운영 화면의 페이지 전체 가로넘침은 1440·768 CSS px에서 0px, 390에서 29px, 320에서 99px였습니다.

제목처럼 보이는 글자는 있었지만 HTML의 제목 요소로 구성돼 있지 않았습니다. 다음 실행 예정시각이 마지막 실행시각보다 과거인데 별도 안내가 없는 경우도 있었습니다. 처음 화면을 불러올 때는 자료를 찾지 못했다는 404 응답이 한 건 관찰됐습니다.

이전에 제가 승인한 ‘쉬운 설명’ 팝업이 아직 운영 화면에 들어가지 않은 것도 확인했습니다. 이 기능은 이번 프롬프트로 새로 발견한 개선안과 구분해 함께 반영했습니다.

수정은 이 범위에 맞췄습니다. 좁은 폭에서는 단계 표식이 줄바꿈되게 하고 제목 계층을 넣었습니다. 다음 예정시각이 현재 시각보다 지났거나 마지막 완료시각보다 앞서는 경우에는 ‘지남’을 붙였습니다. 표시만 바꾼 것으로, 예정시각 재계산과 예약 작업 재실행은 범위에서 제외했습니다.

데스크톱 화면도 일부 달라졌습니다. 카드 폭은 유지하고 단계 표식의 위치를 가운데 쪽으로 옮겼습니다. 설명 버튼도 추가해 기존 배치가 일부 바뀌었습니다.

브라우저 탭의 작은 아이콘을 화면 안에 포함해 기본 아이콘을 따로 찾는 요청을 줄였습니다. 404가 발생할 수 있는 원인 하나를 줄인 조치입니다. 최초 404가 그 요청에서 발생했는지는 아직 모릅니다.

Codex의 수정과 별도 검토

코드 수정은 Codex가 맡았습니다. Codex의 작업 환경에서는 브라우저를 실행할 수 없어, Claude가 작업본을 브라우저로 시험했습니다. 이어서 검토 담당이 변경 내용, 검사 코드와 결과, 실제 화면 이미지를 살폈습니다. 검토 담당의 역할은 이 자료를 검토하는 데까지였으며 운영 화면에서 같은 시험을 재실행하지는 않았습니다.

작업본 시험에는 화면 상태와 폭을 조합한 20개 경우가 포함됐습니다. 페이지 전체의 가로넘침과 수집된 페이지 오류를 확인하고, 키보드로 탭·정렬·설명 버튼에 접근하는지 살폈습니다. 키보드 입력을 받을 위치를 뜻하는 ‘초점’도 살폈습니다. 설명 창을 Esc 키와 닫기 버튼으로 닫으면 처음 버튼으로 초점이 돌아오는지 시험했습니다. 정렬 선택의 유지 여부와 경계 시각에서의 ‘지남’ 표시도 검사했습니다.

검사 방법 자체를 고친 부분도 있었습니다. 설명 창에서 Tab을 눌렀을 때 브라우저의 도구 영역으로 초점이 잠시 이동하는 동작이 있었습니다. 처음에는 해당 검사를 빼기도 했지만, 검토 과정에서 실제 이동을 확인하는 검사로 바꿨습니다. 배경 화면의 버튼으로 초점이 넘어가지 않는지와 Tab을 눌러 설명 창으로 돌아오는지를 다시 시험했습니다.

넓은 화면에서 일부 요소가 화면 바깥에 있다는 기록도 나왔습니다. 확인해 보니 여러 단계를 가로로 배치한 내부 스크롤 영역이었습니다. 시험에서는 끝까지 스크롤해 마지막 단계를 볼 수 있었고, Tab으로 설명 버튼들을 따라갈 때 해당 위치가 보이도록 스크롤됐습니다. 페이지 전체가 옆으로 밀리는 현상과 카드 안에서 의도적으로 가로 스크롤하는 동작을 구분했습니다.

전후 화면 이미지와 수치도 같은 자료인지 대조했습니다. 일반 예시 데이터에서는 수정 전후 모두 페이지 가로넘침이 0이었습니다. 더 긴 내용을 넣은 시험 데이터에서는 넘침이 줄었습니다. 시험 데이터의 수치와 실제 운영 화면에서 측정한 29px·99px는 각각의 자료로 기록했습니다. 두 값을 섞어 개선 폭을 계산하지는 않았습니다.

운영 화면에서 확인한 결과

11월 12일 배포 기록에는 제 승인을 받은 뒤 기존 파일을 백업하고 수정본을 운영 화면에 반영했다고 적혀 있습니다. Claude는 실제 반영한 파일이 검토한 작업본과 같은지 확인하고 화면을 다시 불러왔습니다.

Claude가 같은 날 20시 55분에 다시 검사한 기록에서 1440·768·390·320 CSS px 네 폭의 페이지 전체 가로넘침은 모두 0px였고, 해당 검사에서 수집된 오류도 0건이었습니다. 수정 전 운영 화면에서 확인한 390·320 폭의 넘침은 이 재검사에서는 나타나지 않았습니다. 제목 요소가 들어간 것도 확인됐습니다.

운영 화면에서는 1440·390 폭에서 키보드로 작업 항목을 펼치고 설명 창을 여는 동작도 확인했습니다. 창이 열리면 초점이 안으로 들어갔고, Esc로 닫으면 버튼으로 돌아왔습니다. 다만 그 버튼이 처음 창을 연 버튼과 같은지, Tab으로 이동할 때 배경 화면으로 빠지지 않는지는 작업본에서만 검사했습니다. 운영 재검사 시점에는 예정시각이 지난 작업이 없어 ‘지남’ 표시도 작업본 시험 결과로 구분했습니다.

이 결과는 배포 후 해당 시점에 검사한 화면에 한정됩니다. 데스크톱의 단계 목록에는 기존 내부 가로 스크롤이 남아 있습니다. 최초 404는 재검사에서 관찰되지 않았으나 원인은 미확정입니다. 화면 낭독기 시험과 전체 WCAG AA 평가는 미실시 상태입니다. 다른 브라우저에서의 동작, 긴 설명 창의 모바일 사용, 자동 갱신 중 초점 유지도 추가로 살펴야 합니다. ‘지남’ 표시는 사용 중인 기기의 시계와 전달받은 시각 정보에 영향을 받습니다.

이번 변경은 화면 배치와 표시·상태 해석을 다뤘습니다. 예약 실행기, 화면에 자료를 읽어 오는 기능, 데이터베이스, 인증은 변경 범위에서 제외했습니다. 업무 처리 시간의 단축이나 사용자의 상태 이해도 향상 여부는 아직 측정한 자료가 없습니다.

저는 개선할 대상을 정하고 운영 반영 여부를 승인했습니다. Codex는 코드를 고쳤습니다. 검토 담당은 그 변경을 뒷받침하는 자료와 확인하지 못한 부분을 짚었습니다. Claude는 검토한 파일을 올리고 실제 화면을 다시 확인했습니다. 검토 결과와 별개로 운영 반영에는 제 승인이 필요했습니다.

저 김반장의 작업대는 MD와 Google Drive입니다

받은 프롬프트, 적용할 때 보완한 조건, 수정 범위, 작업본 시험과 운영 확인 결과를 Markdown 문서로 구분해 Google Drive에 기록했습니다. Markdown은 제목과 문단을 간단한 기호로 구분하는 텍스트 문서 형식입니다. Codex가 브라우저를 실행하지 못한 기록과 이후 Claude가 실행한 결과도 따로 보존했습니다. 다음에 이 화면을 고칠 때 어느 단계까지 확인했는지 다시 읽을 수 있습니다.

이러한 AX 과정을 think-designer에서는 MD와 Google Drive로 일하는 방법을 중심으로, AI 대장간 ‘더포지’(the-forge.kr) 커뮤니티에서는 실제 업무를 중심으로 이야기합니다.