블로그 개발기 13 (작업 기록 편)

지난 글에서는 AI 활용 화면과 관리 필터를 정리했다. 사용량·작업·수집 상태를 나누고, 여러 조건으로 자료를 좁히고, 표를 읽는 동선을 맞췄다. 화면의 자리를 정한 다음에는 그 안에 들어가는 작업 기록을 다시 보게 됐다.

처음에는 작업 이름과 상태가 있으면 무엇을 했는지 대략 알 수 있을 것 같았다. 하지만 시간이 지나서 기록을 다시 읽으니 완료 표시만으로는 설명되지 않는 부분이 많았다. 구현이 끝났다는 뜻인지, 검증까지 했다는 뜻인지, 운영에 반영했다는 뜻인지가 서로 달랐다.

KB를 썼다는 기록도 비슷했다. 문서를 검색한 것과 참고한 것, 실제로 적용한 것, 적용 이력이 문서 쪽에도 남은 것은 다른 사실이다. 한 줄의 상태로 묶어버리면 짧아지는 대신 무엇을 확인했는지가 사라졌다.

"나중의 내가 이 기록만 보고 같은 판단을 다시 할 수 있을까?"

그래서 작업 화면을 단순한 완료 목록보다 근거를 따라 읽는 곳으로 바꾸기로 했다. 먼저 작업이 한눈에 들어오게 하고, 펼치면 요약과 사실을 읽고, 필요한 경우에만 원본 근거까지 내려가도록 했다. KB 대조 결과는 그때그때 덮어쓰지 않고 시도별 이력으로 남겼다.

---

작업 하나를 끝까지 읽게 했다

프로젝트 묶음보다 작업을 먼저 놓았다

작업 목록은 프로젝트별로 묶인 구조에서 전체 작업을 한 표로 읽는 구조로 바꿨다. 특정 프로젝트만 볼 때는 묶음이 편하지만, 최근에 무엇을 했는지 훑으려면 여러 덩어리를 번갈아 봐야 했다. 프로젝트는 필터와 열에서 확인하고, 목록의 기본 단위는 작업 하나로 두는 편이 목적에 맞았다.

표에는 작업, 프로젝트, 결과, 날짜, 상태를 배치했다. 긴 설명을 처음부터 모두 꺼내지 않고, 어떤 작업을 열어볼지 고를 수 있는 정보를 남겼다. 작업명을 보고 결과와 상태를 가늠한 뒤 상세를 여는 순서다.

상세에서는 상단 요약을 먼저 읽고, 항목 이름과 값이 짝을 이루는 형태로 사실을 배치했다. 수행한 일, 역할, 결과, 검증, 후속 작업을 구분하고, 그 뒤에 KB 판단과 인계 관련 기록을 연결했다. 원본 출처는 맨 아래로 내려, 내부 기록 형식을 먼저 해석해야 내용을 이해하는 순서를 바꿨다.

읽는 단계	확인할 내용	먼저 내보내지 않은 것
목록	어떤 작업이며 결과와 상태는 무엇인가	상세 원본 전체
상단 요약	왜 했고 무엇이 달라졌나	내부 필드 이름의 나열
사실 항목	수행·역할·검증·후속 작업	서로 다른 의미를 합친 상태
KB·인계	어떤 근거와 다른 작업에 연결되나	연결됐다는 이유만으로 내린 완료 판단
출처	기록을 어디서 확인할 수 있나	근거 없는 빈칸 보완

작업에 사람과 도구의 역할이 각각 기록되어 있으면 그것도 나눠 읽게 했다. 결과만 남기면 누가 어떤 판단과 실행을 맡았는지 다시 해석해야 한다. 다만 이 항목이 있다고 모든 작업의 기여도를 계산할 수 있다고 보지는 않았다.

역할이 명시되지 않은 과거 기록을 현재 기준으로 추측해 채우지 않았다. 기록된 사실을 읽기 좋게 배치하는 일과, 없던 사실을 만들어 완결된 보고서처럼 보이게 하는 일은 구분해야 했다. 화면의 빈 부분은 자료가 아직 충분하지 않다는 표시이기도 했다.

펼쳤을 때의 움직임도 읽는 순서에 맞췄다

행을 펼칠 때 제목과 배지가 갑자기 다른 위치로 튀면 시선이 끊겼다. 접힌 행의 높이와 배지 높이를 일정하게 두고, 제목이 두 줄이 되는 경우에도 이동을 따라갈 수 있게 조정했다. 상세 영역은 높이 변화에 맞춰 열리고 닫히도록 했다.

이것은 애니메이션을 더 넣기 위한 작업은 아니었다. 방금 누른 작업과 새로 나타난 상세가 같은 항목이라는 연결을 유지하고 싶었다. 특히 이름이 긴 작업이나 좁은 화면에서는 어느 행을 열었는지 놓치기 쉬웠다.

인계에서 다른 작업으로 이동할 때도 같은 기준을 썼다. 연결된 작업이 있으면 현재 화면에서 해당 위치로 이동하고 상세를 열었다. 새 주소만 던져주기보다 연결 전후의 맥락을 유지하는 편이 기록을 따라가기 쉬웠다.

대상이 현재 필터에 가려져 있어도 전체 자료에 있으면 표 위의 별도 연결 작업 상세로 열었다. 실제 대상을 찾을 수 없거나 연결이 충돌할 때는 이동한 것처럼 처리하지 않고 안내를 남겼다. 링크가 존재한다는 사실과 실제로 열 수 있는 대상이 존재한다는 사실을 따로 다뤘다.

---

날짜와 상태를 추측하지 않았다

날짜만 아는 기록에 시각을 만들지 않았다

과거 작업에는 정확한 시각까지 남은 기록도 있고, 날짜만 확인되는 기록도 있었다. 이를 같은 모양으로 만들려고 날짜에 임의의 시각을 붙이면 정렬은 쉬워지지만 원래 기록보다 더 많은 것을 안다고 표현하게 된다. 날짜와 시각의 정밀도를 보존하기로 했다.

날짜를 확인할 근거가 있는 과거 자료는 그 범위에서 표시했다. 그 근거가 작업 결과 전체를 증명하는 것처럼 쓰이지 않도록 의미를 제한했다. 어느 날의 작업인지는 알지만, 모든 수행 내용이 검증됐다는 뜻은 아니다. 작업명에서 읽어낸 날짜는 더 제한적인 단서여서 ‘기록명 기준’으로 표시하고 기간 필터와 날짜 정렬의 근거에서는 제외했다.

날짜가 없는 작업은 목록에서 없애지 않았다. 같은 표에서 읽을 수 있게 두되, 날짜 범위를 적용하거나 날짜 순서로 비교할 때는 확인된 날짜가 있는 기록과 섞어 해석하지 않도록 했다. 모르는 날짜가 오늘이나 수집일로 둔갑하는 것을 피하고 싶었다.

기록에서 확인한 것	화면에서 표현할 수 있는 것
날짜와 시각	해당 정밀도의 시점
날짜만 있음	그 날짜까지의 정보
날짜 근거가 없음	날짜 미상
수집된 시각만 있음	수집 시점이며 작업 시점으로 대체하지 않음

자료를 더 많이 보이게 하는 데 집중하면 이런 차이는 쉽게 지워진다. 하지만 날짜 필터를 걸었을 때 어떤 항목이 들어오고 빠지는지는 보고서의 의미를 바꾼다. 빠진 날짜를 임의로 채우는 대신 필터가 무엇을 알고 판단하는지 드러내는 쪽을 택했다.

완료·검증·인계는 각각의 사실이었다

작업의 완료 여부와 검증 결과는 따로 읽도록 했다. 구현이 끝났어도 검사를 돌리지 않았을 수 있고, 일부 검사는 통과했어도 운영 확인은 남아 있을 수 있다. 결과가 좋다는 한 문장으로 이 차이를 덮으면 다음 작업자가 무엇을 해야 하는지 알기 어렵다.

KB 적용 여부도 마찬가지다. 적용, 참고, 해당 없음, 보류, 미상은 서로 다른 상태다. 여기에 검증의 통과·실패·미실행·미상을 따로 두어, 문서를 적용했다는 기록이 곧 그 변경의 검증 통과를 뜻하지 않도록 했다.

인계는 전달과 후속 처리의 연결을 보여 주는 자료로 다뤘다. 요청을 보냈거나 상대가 받았다는 사실만으로 대상 작업이 끝난 것은 아니다. 같은 프로젝트의 다른 기록으로 이동할 수 있더라도 완료 판단은 그 작업의 실제 결과를 봐야 한다.

상태를 세분화하면 화면이 복잡해질 수 있다. 그래서 목록에서 필요한 요약과 상세에서 확인할 근거를 나눴다. 데이터의 의미를 단순화해서 화면을 줄이는 대신, 읽는 단계에 따라 드러나는 양을 조절했다.

---

KB 대조를 한 번의 판정으로 남기지 않았다

검색과 적용 사이의 빈 부분을 보려 했다

KB를 적용했다는 작업 기록과 KB 문서의 적용 이력이 항상 같은 모습으로 남는 것은 아니었다. 작업 쪽에서는 적용했다고 했는데 문서 쪽 이력이 없을 수도 있고, 검색 기록과 연결이 끊겼을 수도 있다. 문서 자체를 확보하지 못하면 일치 여부를 판단할 수 없는 경우도 있다.

이때 필요한 것은 무조건 정상이나 오류를 붙이는 기능이 아니었다. 무엇과 무엇을 대조했고, 어느 지점까지 확인했는지를 기록해야 했다. 검색 자료를 읽지 못한 실패와 실제로 적용되지 않았음을 확인한 결과는 같은 상태로 둘 수 없었다.

대조 상태에는 이력 일치, 이력 기록됨, 이력 누락, 미적용 확인, 판단과 이력의 충돌 같은 구분을 뒀다. 검색 연결 오류, 검색 기록 미확보, 문서 없음, 기록 대상 외, 판단 미상도 따로 표현했다. 결과가 불편해 보인다고 하나의 경고로 합치지 않았다.

대조에서 만난 상황	그 결과만으로 말할 수 없는 것
적용 이력이 누락됨	실제 적용이 없었다는 확정
검색 기록을 확보하지 못함	검색을 하지 않았다는 확정
문서를 찾지 못함	작업의 모든 판단이 틀렸다는 결론
대조 시도가 실패함	이전의 유효한 대조 결과가 무효라는 결론
현재 자료와 과거 대조의 기준이 다름	과거 시도가 당시에도 틀렸다는 결론

이 구분은 문제를 덜 심각하게 보이게 하려는 것이 아니다. 다음에 해야 할 일을 정확히 고르기 위해서다. 이력만 보완하면 되는 상황과 원래 판단부터 다시 확인해야 하는 상황이 같은 경고로 보이면, 매번 전체 자료를 다시 읽게 된다.

"이번에 대조하지 못했다는 이유로, 지난번에 확인한 사실까지 지워야 할까?"

대조 시도는 덮어쓰지 않고 쌓았다

처음 생각하기 쉬운 방식은 작업마다 최신 대조 상태 하나를 두는 것이었다. 하지만 재시도가 실패하면 이전의 정상 결과가 사라지고, 기준 자료가 바뀌면 무엇을 비교했던 결과인지 알기 어려워진다. 최종 상태 하나만 저장해서는 판단의 경과를 설명할 수 없었다.

그래서 대조 시도를 별도 이력으로 남기기로 했다. 각각의 시도에는 관측 시점과 대조에 사용한 기준 자료를 묶었다. 나중에 다시 확인하더라도 과거 시도의 내용을 현재 판단으로 바꿔 쓰지 않았다.

화면에서는 최근 시도를 먼저 보여 주고, 처음에는 세 개를 펼쳐 읽게 했다. 더 오래된 기록이 있으면 추가로 열 수 있도록 했다. 모든 이력을 지우지 않으면서도 상세 화면의 첫 부분이 대조 기록으로만 채워지지 않게 한 것이다.

중요한 것은 맨 위의 결과를 무조건 정답으로 삼지 않는 점이었다. 최근 시도가 실패했을 수 있고, 성공한 시도도 현재와 다른 자료를 기준으로 했을 수 있다. 시도 시점과 기준 자료의 일치 여부를 결과와 함께 보여 줘야 했다.

대조한 자료를 내용 해시로 묶었다

이력이 어느 자료를 기준으로 했는지 확인하려면 단순히 작업 이름만 같아서는 부족했다. 같은 작업의 판단이나 근거가 나중에 달라질 수 있기 때문이다. 대조 당시 자료의 스냅샷을 정해진 방식으로 표현하고, 내용 해시로 묶었다.

이 해시는 자료가 현재도 같은지를 비교하기 위한 기준이다. 누가 작성했는지 인증하거나 내용 자체가 진실임을 보장하는 서명은 아니다. 구조와 내용이 달라진 기록을 예전과 같은 기준으로 대조한 것처럼 표시하지 않는 데 목적이 있었다.

표현 방식도 언어마다 달라지지 않아야 했다. Python 쪽에서 만든 자료를 서버와 브라우저가 읽을 때, 같은 내용인데 해시 계산 방식이 달라 과거 자료로 오인하면 이력의 의미가 깨진다. 정규화된 표현과 SHA-256 계산 결과를 서로 대조했다.

입력 검증도 함께 좁혔다. 다른 프로젝트나 작업에 속한 이력을 끼우거나, 같은 식별자를 중복으로 넣거나, 근거가 빠진 상태를 정상 기록처럼 받아들이지 않게 했다. 모르는 필드와 공백만 있는 문자열도 조용히 정리해 받아들이지 않고 계약 위반으로 처리했다.

이력의 개수에도 상한을 뒀다. 끝없이 받아들이는 배열은 한 작업을 읽는 비용을 제한하기 어렵게 만든다. 그렇다고 상한에 닿으면 임의로 과거 이력을 삭제하는 운영 정책까지 이번에 정한 것은 아니다.

새 필드는 기존 기록과 함께 읽을 수 있게 추가했다. KB 판단 자체의 의미는 기존 검증을 재사용하고, 대조 이력이 생겼다는 이유로 적용·참고·보류의 뜻을 바꾸지 않았다. 기존 자료를 새로운 해석으로 조용히 갈아끼우는 일을 피했다.

자세한 대조 근거는 관리 화면에 남겼다

이력을 자세히 읽을수록 내부 문서 경로나 작업 연결 정보도 함께 보일 수 있었다. 관리 화면에서는 필요한 근거지만 공개 AI 활용 페이지에 그대로 나갈 이유는 없었다. 공개 데이터에서는 대조 상세, 내용 해시, 내부 경로를 제외했다.

집계 수치와 내부 감사 자료는 목적이 달랐다. 공개 화면에 세부 근거가 없다고 해서 관리 기록에서도 지울 필요는 없고, 관리자가 볼 수 있다고 해서 공개해도 되는 것도 아니다. 같은 원천에서 나오더라도 출력 경로별로 필요한 범위를 정했다.

브라우저에서 대조 이력을 읽는 권한과 원본을 수정하는 권한도 같게 취급하지 않았다. 이 화면이 생겼다고 KB 기록을 자동으로 고치거나 새로운 승인 권한을 부여한 것은 아니다. 잘못된 기록을 어떻게 정정할지는 별도 계약과 후속 작업으로 남았다.

---

결과

작업 화면은 상태를 모아놓은 목록에서, 결과와 근거를 순서대로 확인하는 화면으로 바뀌었다. 날짜가 없는 기록도 버리지 않으면서 날짜 비교의 범위를 제한했고, 인계는 연결된 작업의 실제 내용을 따라가게 했다. KB 대조는 한 번의 결론보다 시도와 기준 자료가 남는 이력으로 정리했다.

이전에 부족했던 설명	이번에 남긴 구분
완료 표시만으로 작업 판단	결과·검증·후속 작업을 따로 확인
프로젝트 묶음을 오가며 작업 탐색	한 표에서 작업을 읽고 조건으로 좁힘
날짜를 일괄된 값으로 해석	날짜·시각·미상의 정밀도 보존
KB 적용 여부와 대조 성공이 섞임	원래 판단과 대조 시도를 분리
최신 대조 하나로 과거 결과 대체	시도별 이력과 기준 자료 보존
내부 근거가 공개 자료에 섞일 여지	공개 출력에서 상세 대조 정보 제외

작업·활동·인계 구조는 관련 53개 fixture 검증으로 확인했고, KB 대조 이력은 별도의 37개 fixture로 입력 경계를 확인했다. Python과 서버의 허용·거부 결과를 맞췄고, 정규화한 내용의 해시는 Node와 브라우저 JavaScript 경로에서도 대조했다. 이 숫자는 작업 기록의 품질 점수가 아니라 입력 계약을 확인한 사례 수다.

화면은 합성 자료를 사용해 넓은 다크 화면과 좁은 라이트 화면에서 확인했다. 다만 로그인한 운영 관리 화면의 모든 이력과 인계 동선을 실제 자료로 끝까지 검증한 것은 아니다. 자료가 없는 상태와 과거 자료가 섞이는 장기 운영에서 더 확인할 부분도 남아 있다.

이번 결과로 효율 점수나 자동 평가를 만들지는 않았다. 대조가 성공했다고 작업 자체의 품질이 보장되는 것도 아니다. 어떤 자료에 근거해 무엇을 확인했는지를 남겨, 나중에 다시 판단할 수 있는 범위를 넓힌 작업이었다.

---

느낀점

• 기록의 정밀도를 보존하는 것이 먼저였다. 날짜만 아는 자료에 시각을 붙이거나 미실행 검사를 통과로 채우면 표는 단정해져도 기록은 부정확해졌다.
• 실패한 대조와 잘못된 적용은 달랐다. 자료를 확보하지 못한 상황까지 미적용으로 묶지 않아야 다음 확인 범위를 좁힐 수 있었다.
• 이력에는 판단 당시의 기준이 필요했다. 시점과 내용 해시가 있어야 과거 결과를 현재 자료에 대한 판정으로 오해하지 않았다.
• 요약과 근거는 함께 남길 수 있었다. 처음부터 원본을 펼치지 않아도, 요약 다음에 사실과 출처로 내려가는 구조로 읽기와 확인을 이어갈 수 있었다.

기록이 자세해질수록 저장할 자료도 늘었다. 처음에는 이 원본과 이력을 DB에 함께 넣으면 조회와 정정이 편해질 것 같았다. 하지만 실제 용량을 계산해 보니 다음 결정은 화면이나 스키마만으로 끝나지 않았다.

다음 글에서는 무료 한도를 유지하기 위해 저장 방식을 되돌아보고, 수집 후 별도 예약을 기다리지 않도록 발행 흐름을 바꾼 과정을 적는다. 이번 글도 끝까지 읽어줘서 감사하다.