블로그 개발기 12 (AI 화면 편)
AI 활용 화면과 관리 필터를 실제로 읽고 비교하기 편하게 다듬었다
지난 글에서는 포스트·댓글·이미지를 관리하는 도구를 정리했다. 필요한 조건으로 목록을 좁히고, 이미지가 어디에 쓰이는지 확인하고, 작은 화면에서도 같은 작업을 할 수 있게 만드는 과정이었다. 관리 기능은 갖춰졌지만, 그 뒤에 붙인 AI 활용 화면에는 그때 정리한 방식이 충분히 이어지지 않았다.
사용량을 수집하기 시작한 이유는 MuRing-KB 개발기 3에 적었다. 토큰 합계만으로 효율을 판단하기 어려워서 작업 결과와 검증 근거를 함께 모으기로 했다는 이야기다. 이번에는 수집의 이유보다, 모인 자료를 블로그에서 어떻게 읽게 했는지를 정리하려고 한다.
숫자가 보이는 것과 비교할 수 있는 것은 달랐다. 필터를 하나 바꾸면 다른 조건을 다시 골라야 했고, 표 안의 스크롤과 화면 스크롤이 겹쳤다. 설명과 조작부가 자리를 차지하면서 정작 확인하려던 기록은 아래로 밀렸다.
"자료는 늘었는데, 왜 원하는 항목을 찾는 일은 더 번거로워졌지?"
그래서 화면에 정보를 더 얹기 전에 읽는 순서를 다시 잡았다. 공개 화면의 입구, 관리 화면의 탭, 필터의 의미, 표의 스크롤을 차례로 정리했다. 이후 작업 기록 자체를 바꾼 내용과 저장·발행 구조를 바꾼 내용은 다음 두 편으로 나눠 적는다.
먼저 볼 내용을 나눴다
공개 화면과 관리 화면의 질문은 달랐다
공개 AI 활용 페이지는 블로그에서 바로 들어갈 수 있어야 했다. 기존 외부 링크 옆에 진입점을 두고, 모바일에서도 하단에서 찾을 수 있게 했다. 주소를 알고 있어야만 열 수 있는 별도 페이지보다 블로그의 한 부분으로 두는 편이 자연스러웠다.
그렇다고 관리 화면에 있는 내용을 모두 공개할 이유는 없었다. 공개 화면에서는 사용량과 변화의 흐름을 보고, 관리 화면에서는 개별 작업과 수집 상태를 확인한다. 원본 경로나 내부 판단 근거를 자세히 읽는 일은 관리 영역에 남겼다.
이 구분은 보안뿐 아니라 화면의 목적에도 맞았다. 처음 들어온 사람에게 필요한 것은 각 기록의 내부 구조보다 무엇을 관측한 수치인지에 대한 설명이다. 반대로 내가 관리 화면을 열었을 때는 전체 소개를 다시 읽는 것보다 특정 작업과 누락된 자료를 찾는 일이 먼저였다.
공개 소개 문구를 편집하던 관리 UI와 API도 이번 정리에서 제거했다. 현재 필요한 설명은 코드에 둔 기본 소개로 유지했다. 관리할 값이 많아지는 것 자체를 기능의 발전으로 보지 않기로 했다.
사용량·작업·수집 상태는 따로 읽게 했다
관리 화면은 사용량, 작업, 수집 상태를 각각 탭으로 나눴다. 한 화면에 세 종류의 내용을 계속 이어 붙이면 지금 어떤 질문을 확인하는지 흐려졌다. 작업을 찾다가 수집 안내를 지나고, 다시 합계를 보기 위해 위로 올라가는 동선도 줄이고 싶었다.
탭마다 맡는 질문을 먼저 정했다. 사용량은 기간과 조건에 따른 수치, 작업은 무엇을 했고 어떤 결과가 남았는지, 수집 상태는 그 자료를 어디까지 믿고 볼 수 있는지다. 화면을 분리했지만 같은 관리 도구를 쓰고 있다는 느낌은 유지하도록 공통 조작부를 맞췄다.
| 영역 | 먼저 확인할 질문 | 화면에서 앞에 둔 것 |
|---|---|---|
| 공개 AI 활용 | 어느 기간에 어떤 사용 흐름이 있었나 | 설명과 집계 흐름 |
| 관리 사용량 | 특정 조건의 수치는 어떻게 다른가 | 기간·조건 필터와 표 |
| 관리 작업 | 무엇을 했고 결과는 무엇인가 | 작업 목록과 상세 기록 |
| 관리 수집 상태 | 자료가 어디까지 들어왔나 | 수집 상태와 확인할 정보 |
이렇게 나누고 나니 표가 쓸 수 있는 자리도 분명해졌다. 설명을 무조건 줄이기보다 설명이 필요한 곳에 두고, 표를 읽는 동안 반복해서 볼 필요가 없는 내용은 표 바깥에 뒀다. 같은 높이 안에서도 실제 자료에 쓸 수 있는 공간이 달라졌다.
필터를 여러 개 골라도 뜻이 같게 했다
같은 조건은 OR, 다른 조건은 AND로 정했다
지난 편의 필터는 검색어와 정확한 조건을 구분하는 데 초점을 맞췄다. 이번에는 한 조건에서 여러 값을 고를 수 있도록 넓혔다. 포스트의 태그와 시리즈, 댓글의 포스트와 작성자, 이미지의 연결 포스트와 파일 형식, AI 기록의 프로젝트·도구·모델·추론 수준이 대상이었다.
여러 값을 선택할 수 있게 하는 것보다 중요한 것은 선택의 뜻이었다. 태그 두 개를 골랐을 때 둘 다 붙은 글만 찾는지, 둘 중 하나가 붙은 글을 찾는지가 모호하면 화면이 예상과 다르게 느껴진다. 이번에는 한 조건 안에서는 OR, 서로 다른 조건 사이는 AND로 통일했다.
예를 들어 태그에서 frontend와 backend를 고르면 둘 중 하나에 해당하는 글을 찾는다. 여기에 특정 시리즈를 고르면 그 시리즈에 속하면서 앞의 태그 조건에 맞는 글로 좁힌다. AI 화면에서도 여러 모델을 고른 뒤 프로젝트를 하나 고르면 같은 방식으로 해석한다.
| 선택 | 해석 |
|---|---|
| 태그 A, 태그 B | A 또는 B에 해당 |
| 태그 A, 태그 B + 시리즈 C | A 또는 B에 해당하면서 C에 속함 |
| 모델 A, 모델 B + 프로젝트 C | A 또는 B를 사용했고 프로젝트는 C |
| 특정 조건의 선택을 전부 해제 | 해당 조건으로는 제한하지 않음 |
포스트·댓글·이미지 목록은 서버 조회도 배열 조건을 받아 같은 의미로 처리하도록 맞췄다. 화면은 여러 개를 선택했는데 실제 쿼리는 마지막 값 하나만 쓰는 상태가 되지 않도록, URL부터 조회 조건까지 이어서 바꿨다. AI 화면은 이미 받은 자료에 클라이언트 필터를 적용하되 같은 OR·AND 의미를 유지했다.
URL에도 선택한 상태를 남겼다
포스트·댓글·이미지 목록의 필터 상태는 반복되는 쿼리 매개변수로 표현했다. 같은 이름의 값을 여러 개 담으면 무엇을 선택했는지 URL에서도 드러난다. 기존에 값 하나만 들어 있는 주소도 계속 읽을 수 있도록 했다.
관리 화면에서는 같은 조건을 다시 확인하는 일이 많다. 다른 항목을 보고 돌아왔을 때 선택이 사라지거나, 주소를 복사했는데 전혀 다른 목록이 나오면 필터의 효용이 줄어든다. 이들 목록의 여러 선택을 화면의 임시 상태에만 두지 않은 이유다. AI 관리 화면의 선택은 화면 내부 상태로 유지하며, 이 URL 보존 범위에 포함하지 않았다.
드롭다운은 체크박스로 여러 항목을 고를 수 있게 하고, 하나를 골랐다고 바로 닫히지 않게 했다. 선택을 끝낸 뒤 닫는 흐름이 여러 번 열고 닫는 것보다 덜 번거로웠다. 전체 해제도 함께 두어 조건을 처음부터 다시 만들 수 있게 했다.
값이 많을 때 버튼에는 첫 항목과 나머지 개수를 표시했다. 펼쳐진 선택 칩에서는 각 값을 따로 제거할 수 있게 했다. 버튼은 현재 조건을 짧게 설명하고, 칩은 세부 선택을 직접 조정하는 역할을 맡았다.
필터 배지의 숫자는 선택한 값의 총개수와 구분했다. 모델을 세 개 골랐다고 필터 세 종류를 쓰는 것은 아니다. 활성화된 조건의 수를 세어, 값이 많아졌다는 이유로 조작부의 의미가 바뀌지 않게 했다.
목록의 태그도 같은 필터로 연결했다
포스트 목록을 읽다가 태그를 발견했을 때, 다시 위의 필터에서 같은 이름을 찾는 과정도 줄였다. 목록의 태그를 누르면 해당 필터를 켜거나 끌 수 있게 했다. 여러 태그가 접혀 있는 영역에서도 같은 동작을 하도록 연결했다.
공용 태그 컴포넌트 전체를 버튼으로 바꾸지는 않았다. 실제 선택 동작이 연결된 자리에서만 버튼이 되고, 표시만 하는 태그는 그대로 읽는 요소로 남겼다. 같은 모양을 공유하더라도 눌렀을 때 일이 일어나는지는 분명해야 했다.
호버와 선택 상태도 다르게 표현했다. 포인터가 올라간 순간의 테두리와 이미 선택된 항목의 배경을 구분해, 잠깐 가리키는 것과 지속되는 조건이 섞이지 않게 했다. 이 부분은 새로운 장식보다 조작 결과를 바로 읽을 수 있게 하는 데 의미가 있었다.
표가 움직이는 방식을 정리했다
스크롤을 맡는 곳을 하나로 줄였다
AI 관리 화면을 손보면서 가장 많이 되짚은 부분은 표 주변의 높이였다. 표 안에서도 스크롤되고 그 바깥에서도 다시 스크롤되면, 휠을 굴릴 때 어디가 움직일지 계속 신경 써야 했다. 고정 헤더와 표 머리글까지 겹치면 작은 틈도 눈에 잘 들어왔다.
불필요한 두 번째 스크롤 영역을 걷어내고, 표가 움직이는 범위를 분명하게 했다. 설명은 표 위에 두고 머리글은 자료를 읽는 위치에 남겼다. 카드와 표 사이에 생기던 높이 차이도 함께 맞췄다.
툴바는 다른 관리 목록과 공용 구조를 쓰도록 정리했다. 검색이 필요하지 않은 화면에서는 빈 검색창을 억지로 유지하지 않고, 검색 기능을 선택적으로 붙일 수 있게 했다. AI 화면만 별도 필터 조작법을 익혀야 하는 상태를 줄이는 쪽이었다.
작은 폭에서는 모든 버튼을 무리하게 한 줄에 넣지 않았다. 넓을 때는 한 줄을 유지하되, 좁은 화면에서는 기간 조작부가 별도 줄로 내려가도록 했다. 폭을 줄였을 때 항목이 사라지는지보다 같은 조건을 여전히 선택할 수 있는지를 확인했다.
스크롤바가 차지하는 폭도 레이아웃이었다
표의 오른쪽이 유독 넓거나 좁아 보이는 문제는 셀의 padding만으로 설명되지 않았다. 스크롤바가 차지하는 공간이 더해지면서 왼쪽 여백과 오른쪽 여백이 달라졌다. 숫자만 같은 padding을 줬다고 실제 눈에 보이는 여백까지 같아지는 것은 아니었다.
첫 날짜 열은 내용에 맞는 폭을 갖게 하고, 마지막 셀은 스크롤바 공간을 고려하도록 조정했다. 바깥 상자와 안쪽 셀의 위치를 따로 재며 양끝을 맞췄다. 공용 표 스타일로 묶어 같은 문제를 각 목록에서 다시 풀지 않도록 했다. 포트폴리오 링크 스타일도 별도 모듈로 분리해 사용 위치를 명확히 했다.
헤더의 배경과 스크롤바 시작 위치도 같이 봤다. 스크롤 여유 공간이 헤더 옆에서 다른 색으로 보이면, 표 자체가 맞아도 화면 전체가 끊긴 것처럼 느껴졌다. 반대로 스크롤이 없는 공개 화면에 공간을 미리 확보하면 필요 없는 빈틈만 남았다.
중간에는 CSS를 바꿨는데 화면에 적용되지 않는 일도 있었다. 같은 이름처럼 보여도 다른 CSS Module에서 만들어진 클래스는 서로 다른 클래스였다. 사용 중인 요소가 참조하는 모듈을 확인한 뒤에야 수정이 실제 화면에 닿았다.
"스타일을 고친 것과, 그 스타일이 해당 요소에 붙은 것은 같은 일인가?"
이 문제는 빌드가 통과했다는 사실만으로 확인할 수 없었다. 문법은 맞고 클래스도 존재하지만 대상이 다르면 화면은 그대로다. 그래서 스타일 파일의 변화량보다 실제 요소의 위치와 적용된 규칙을 확인하는 쪽으로 검증을 좁혔다.
최신 기록과 시간 흐름은 정렬 방향을 달리했다
표의 기본 정렬은 최신 기록이 먼저 보이도록 바꿨다. 관리 화면을 열었을 때 가장 자주 확인하는 것이 최근 수집 결과였기 때문이다. 과거부터 읽을 필요가 있을 때는 오래된 순서도 고를 수 있게 했다.
공개 주별 표 역시 최근 주를 먼저 보게 했다. 하지만 차트까지 같은 방향으로 뒤집지는 않았다. 차트에서는 시간이 왼쪽에서 오른쪽으로 흐르는 편이 변화를 읽기 쉬웠다.
같은 자료라고 해서 모든 표현의 순서를 통일할 필요는 없었다. 표는 특정 행을 찾는 도구이고, 차트는 기간의 흐름을 보는 도구다. 데이터의 기준은 같게 두고, 먼저 마주치는 순서는 읽는 목적에 맞췄다.
헤더의 읽기 진행선에서도 별도 문제가 나왔다. 페이지가 짧아 스크롤할 높이가 없으면 진행률 계산의 분모가 0이 된다. 그 상태를 그대로 넘겨 유효하지 않은 값이 스타일에 들어가지 않도록 0으로 처리하고, 경로가 바뀔 때도 다시 계산하게 했다.
처음에는 표의 여백과 상단 선이 각각 사소한 화면 문제처럼 보였다. 실제로는 스크롤할 공간이 있는지, 어느 요소가 움직이는지, 현재 페이지가 바뀌었는지를 함께 다루는 일이었다. 내용이 많은 화면뿐 아니라 짧은 화면에서도 성립하는 규칙이 필요했다.
결과
이번 변경으로 AI 화면만 따로 붙인 도구처럼 보이던 부분을 기존 관리 목록과 맞췄다. 여러 조건을 조합하고, 선택된 값을 확인하고, 필요한 항목만 해제하는 방식이 화면마다 이어진다. 표는 최근 기록을 먼저 보여 주면서 차트의 시간 흐름은 유지한다.
| 이전에 걸리던 부분 | 바꾼 뒤의 방식 |
|---|---|
| 한 조건에서 값을 바꾸며 번갈아 확인 | 여러 값을 함께 선택 |
| 목록의 태그를 보고 필터에서 다시 검색 | 목록의 태그로 조건 전환 |
| 화면마다 다른 필터 조작 | 공용 드롭다운·필터 바 사용 |
| 표 안팎의 중첩 스크롤 | 표의 스크롤 범위 정리 |
| 스크롤바 때문에 달라 보이는 양끝 | 실제 셀과 스크롤 공간을 함께 계산 |
| 표와 차트의 읽는 목적이 섞임 | 표는 최신 우선, 차트는 시간 순서 |
관련 변경에서는 lint와 타입 검사, AI 자료의 기존 검증을 실행했다. 필터의 서버 조건은 로컬 DB 경로로 확인했고, 화면은 합성 자료를 사용한 작은 폭과 넓은 폭, 라이트·다크 테마의 미리보기로 살폈다. 여백처럼 실제 위치가 중요한 부분은 계산값과 화면을 함께 대조했다.
다만 합성 자료의 미리보기와 로그인한 운영 관리 화면은 같은 검증이 아니다. 모든 관리자 동선을 실제 계정으로 끝까지 확인한 것은 아니며, 앞선 글에서 남긴 실제 한글 입력 조합 확인까지 이번 결과에 포함하지 않았다. 각 변경 때 확보한 결과를 재사용했고 글을 쓰기 위해 전체 검사를 다시 돌리지는 않았다.
이번 편에서 다룬 화면 변경은 운영 반영된 범위를 기준으로 정리했다. 이후 실험하다 남긴 원본 DB 관리 화면까지 지금 사용할 수 있는 기능으로 묶지 않았다. 자료를 어떻게 저장하고 갱신하기로 했는지는 마지막 편에서 별도로 다룬다.
느낀점
- 선택의 개수보다 선택의 뜻이 먼저였다. 다중 선택을 붙이기 전에 OR와 AND의 경계를 정하니 URL과 서버 조회도 같은 기준으로 맞출 수 있었다.
- 공용 컴포넌트는 조작법을 공유하는 장치였다. 드롭다운과 필터 바를 재사용한 효과는 코드 양보다 화면을 옮겨도 같은 방식으로 다룰 수 있다는 데 있었다.
- 같은 여백 값이 같은 화면을 만들지는 않았다. 스크롤바와 셀의 실제 위치를 같이 봐야 양끝이 맞았다. 스타일이 적용되는 모듈까지 확인해야 했다.
- 검증한 화면의 조건을 남겨야 했다. 합성 자료와 운영 로그인 화면을 구분해 적어야, 다음에 무엇을 확인할지 판단할 수 있었다.
화면을 정리한 뒤에도 작업 목록을 읽는 일은 남아 있었다. 보기 좋은 표 안에 무엇을 담아야 완료와 검증, 기록 누락을 구분할 수 있는지는 별개의 문제였다. 다음 글에서는 작업 상세와 KB 대조 이력을 어떻게 바꿨는지 이어서 정리하려고 한다.
긴 글을 읽어줘서 감사하다.
댓글