MuRing-KB 개발기 4 (활용 편)
검색한 지식이 실제 작업에 쓰였는지 확인하고 후보를 정리한 기록
지난 글에서는 토큰 사용량을 모으고 작업 결과와 함께 비교할 준비를 했다. 마지막에는 숫자가 좋아 보이는 날만 고르지 않고 실패와 재작업도 남겨보겠다고 적었다. 수집 경로를 만들었으니 이제 기록을 읽으며 개선점을 찾을 수 있을 것 같았다.
그런데 먼저 확인해야 할 것이 있었다. KB를 검색한 흔적은 남아 있는데, 그 지식을 실제 작업에 썼는지는 분명하지 않은 사례였다. 문서가 존재하고 검색 결과에 나왔다는 사실만으로는 같은 요청이 반복되는 이유를 설명할 수 없었다. 지식을 저장하는 일 다음에는 저장한 지식이 어떤 판단으로 이어졌는지 확인하는 일이 남아 있었다.
"찾아본 기록이 있다면, 실제로 활용한 기록도 있다고 봐도 될까?"
이번에는 그 사이를 구분하기로 했다. 검색 결과에서 무엇을 골랐는지, 적용했다면 어디에 썼는지, 적용하지 않았다면 이유가 무엇인지 남기는 기준을 정했다. 쌓인 후보도 함께 정리하면서 기록을 늘리는 것과 다시 쓸 수 있게 만드는 것이 얼마나 다른 작업인지 돌아봤다.
검색 다음에 남아 있던 빈칸
지난 편에서도 검색과 실제 적용은 다르다고 적었다. 당시에는 사용량을 해석할 때 주의해야 할 기준에 가까웠다. 이번에는 그 구분을 작업 기록과 연결해 확인할 수 있도록 구체화했다. 관련 문서가 검색됐다는 사실에서 멈추면, 문서를 읽었는지조차 확실히 알 수 없었기 때문이다.
예를 들어 표 안에서만 스크롤하도록 정리한 선호가 검색됐다고 해도 결과 화면에 그대로 반영됐다는 보장은 없었다. 다른 조건 때문에 적용하지 않았을 수도 있고, 내용을 읽고도 놓쳤을 수도 있었다. 검색 결과만 보고 둘을 같은 문제로 취급하면 필요한 개선도 달라진다. 검색 품질을 고쳐야 하는지, 적용 판단을 남겨야 하는지, 결과 확인을 보완해야 하는지부터 나눠야 했다.
검색 결과를 활용 실적으로 세지 않기로 했다. 작업과 검색을 연결하고, 그중 실제로 읽고 판단한 문서에만 선택과 적용 정보를 남기는 쪽으로 정리했다. 이미 위치를 아는 문서를 바로 읽는 경우도 있어서 검색을 반드시 거치도록 강제하지는 않았다. 직접 읽은 경우와 검색을 통해 선택한 경우를 구분하면 충분했다.
| 단계 | 확인할 수 있는 내용 | 그 사실만으로 알 수 없는 내용 |
|---|---|---|
| 검색 | 어떤 작업에서 어떤 문서가 반환됐는가 | 원문을 읽었는가 |
| 선택 | 어떤 문서를 읽고 판단 대상으로 삼았는가 | 실제 작업에 반영했는가 |
| 적용 판단 | 적용 여부와 그 이유가 무엇인가 | 적용 결과가 기대와 같았는가 |
| 검증 | 무엇을 어떤 방법으로 확인했는가 | 장기적인 효율이 좋아졌는가 |
단계를 나누고 나니 검색 횟수를 높이는 것 자체는 목표가 될 수 없었다. 이미 잘 알고 있는 문서를 직접 참고해 한 번에 작업을 끝내는 경우도 있었다. 반대로 검색을 여러 번 했더라도 문제와 맞는 문서를 찾지 못했다면 활용이 잘됐다고 말하기 어려웠다. 검색과 적용의 개수를 나란히 놓을 때도 같은 작업 집합을 비교하고 있는지 먼저 확인해야 했다.
과거 기록을 점검할 때도 이 제한을 지켰다. 검색 기록이 있는 기간과 적용 기록이 있는 작업 범위가 같지 않은데 단순히 나누면 그럴듯한 비율만 만들어진다. 세션 연결이 없는 검색을 나중에 비슷한 작업에 붙이는 것도 하지 않기로 했다. 이미 남아 있는 근거로 설명할 수 있는 범위만 비교하고 나머지는 연결되지 않은 기록으로 남겼다.
적용하지 않은 이유도 기록했다
적용 여부를 예와 아니오로만 나누면 설명이 너무 많이 사라졌다. 개념을 이해하기 위해 참고했지만 구현에는 쓰지 않은 문서가 있었고, 현재 조건과 맞지 않아 제외한 문서도 있었다. 적용할 필요는 있지만 다른 일이 먼저여서 미룬 경우도 있었다. 이런 판단을 전부 미사용으로 묶으면 나중에 같은 문서를 다시 읽을 때 처음부터 판단해야 했다.
그래서 작업 기록에는 적용, 참고, 조건 불일치, 보류, 미상을 구분했다. 적용에는 실제로 바꾼 내용과 확인 방법을 붙이고, 나머지 판단에는 이유를 남기도록 했다. 기록이 없다는 이유로 사용하지 않았다고 단정하지는 않았다. 미상은 미사용과 다른 상태로 유지했다.
| 판단 | 남길 내용 |
|---|---|
| 적용 | 어디에 반영했고 무엇으로 결과를 확인했는가 |
| 참고 | 이해에 어떤 도움이 됐으며 구현에는 왜 쓰지 않았는가 |
| 조건 불일치 | 현재 작업과 맞지 않는 조건은 무엇인가 |
| 보류 | 무엇이 먼저 필요하며 언제 다시 검토할 것인가 |
| 미상 | 판단 근거를 아직 확인하지 못했다는 사실 |
적용과 성공도 분리했다. 문서의 방법을 실제로 사용했지만 검증에서 문제가 드러났다면 그것도 적용한 기록이었다. 성공한 경우만 남기면 문서가 맞지 않았던 조건을 다음 작업에서 다시 밟을 수 있었다. 확인 결과가 실패였다는 사실까지 함께 남겨야 지식의 적용 범위를 좁히거나 내용을 고칠 근거가 생겼다.
다음으로는 작업의 적용 판단과 KB에 남은 기존 적용 이력을 대조하도록 했다. 실제 적용 내용과 검증 근거가 있는데 이력만 빠졌는지, 애초에 적용하지 않기로 판단한 것인지, 검색과 작업의 연결이 잘못됐는지를 구분했다. 기본 대조는 읽기 전용으로 두었다. 확인 명령을 실행했다는 이유만으로 새로운 활용 실적이 생기지 않게 하려는 선택이었다.
근거가 갖춰진 적용 이력을 기록하는 동작은 따로 두었다. 같은 작업과 문서를 반복 처리해도 같은 적용 기록이 중복으로 늘지 않아야 했고, 기존 판단과 다른 내용이 들어오면 조용히 덮어쓰지 않아야 했다. 문서가 이동한 경우에는 경로 변경을 고려하되 실제 대상이 확인되지 않으면 멈추도록 했다. 기록을 쉽게 추가하는 것보다 잘못 연결된 이력을 만들지 않는 쪽을 먼저 택했다.
이 과정에서 나의 분류도 한 번 바로잡았다. 절차 문서를 읽었는데 적용 이력이 없다는 이유로 누락처럼 보았지만, 그 문서는 원래 적용 이력을 남기는 대상 범위 밖이었다. 적용 기록의 대상이 아닌 문서와 기록해야 했는데 빠진 문서를 같은 상태로 다루면 안 됐다. 누락 검사에도 무엇을 검사 대상으로 삼는지 명확한 경계가 필요했다.
"비어 있는 칸을 채우는 일이 오히려 잘못된 확신을 만들고 있지는 않을까?"
대조 결과도 한 번의 최종 판정으로만 보관하지 않기로 했다. 처음에는 기록이 없어 누락으로 나왔다가, 근거를 확인하고 기록한 뒤 일치로 바뀔 수 있었다. 나중의 일치 결과가 이전 판단을 지워버리면 왜 상태가 바뀌었는지 알기 어려웠다. 시도 당시의 판단과 근거를 보존해야 재시도가 제대로 작동했는지도 확인할 수 있었다.
다만 이 기능이 코드 전체를 읽고 지식의 실제 사용 여부를 자동으로 알아내는 것은 아니다. 작업을 수행하면서 확인한 내용과 근거를 입력하고, 도구는 그 연결과 형식, 기존 이력과의 일치를 검사한다. 입력에 없는 사실까지 복원하는 기능으로 설명하면 다시 같은 과장이 생긴다. 자동으로 확인하는 범위와 사람이 판단해 남기는 범위를 구분해 두었다.
기록의 빈칸을 추측으로 채우지 않았다
활용 판단을 작업에 연결하려니 날짜와 완료 상태도 다시 보게 됐다. 문서 이름에 날짜가 있으면 그날 수행한 일처럼 보이기 쉬웠다. 하지만 기록을 만든 날과 실제 작업을 한 날은 다를 수 있었다. 날짜가 적힌 식별자만으로 주간 작업량에 포함하면 비교의 기준부터 흔들릴 수 있었다.
확인된 시각이 있으면 시각을 남기고, 원본 근거로 날짜까지만 알 수 있으면 날짜만 남기기로 했다. 날짜만 아는 기록에 임의로 자정 시각을 붙이지 않았다. 문서 이름의 날짜는 기록을 알아보기 위한 정보로 표시할 수 있지만, 검증된 수행일과 섞지 않았다. 근거가 부족한 과거 기록은 미상으로 남기는 편이 더 정확했다.
완료라는 말도 같은 문제를 갖고 있었다. 공용 명령의 구현이 끝난 것과 블로그가 그 데이터를 받을 준비를 마친 것은 달랐다. 수신 코드가 배포됐더라도 실제 자료를 보내 확인하기 전까지는 운영 반영을 확인했다고 할 수 없었다. 서로 다른 프로젝트가 각자의 완료를 회신할 때 전체 작업의 완료로 확대해서 해석하지 않도록 했다.
이 구분을 유지하려고 역할을 나눴다. KB는 기록의 의미와 집계 기준을 관리하고, 공용 도구 쪽은 작업 입력과 저장·전송을 맡았다. 블로그는 수신 검증과 화면 표시를 맡았다. 같은 필드를 서로 다르게 해석하지 않도록 계약과 예시 입력을 공유하고, 담당 경계를 넘는 변경은 해당 프로젝트에서 처리했다.
프로젝트 사이에 요청을 보낸 기록도 비슷했다. 전송 도구가 입력을 접수한 것과 상대가 실제로 요청을 읽고 작업을 시작한 것은 달랐다. 입력란에 문구가 남아 있는 상황에서는 전송을 시도했다는 사실만으로 수신을 확인할 수 없었다. 요청과 수신, 착수, 결과를 같은 인계에 연결하되 확인되지 않은 단계는 비워 두기로 했다.
이 내용의 화면 구성은 별도의 블로그 개발기에서 다뤘다. 여기서 중요했던 것은 표시할 항목을 늘리는 것보다 각 상태가 뜻하는 바를 지키는 일이었다. 날짜와 완료를 쉽게 보정하면 화면은 더 채워지지만, 이후 분석에서 그 값의 근거를 다시 의심해야 한다. 모르는 부분을 남기는 규칙도 수집 체계의 일부로 보게 됐다.
후보를 줄이면서 지식을 남겼다
작업 기록을 정리하는 동안 KB 후보도 쌓였다. 후보에는 앞으로 반복해서 쓸 기술적 원리뿐 아니라 특정 버전에서 겪은 증상, 작업 중간의 판단, 아직 확인하지 못한 추정이 함께 들어 있었다. 모두 정식 문서로 옮기면 문서 수는 늘어나지만 검색 결과에서 무엇을 믿고 적용할지 더 어려워질 수 있었다. 후보를 보관하는 절차와 지식으로 반영하는 절차를 분리해 둔 이유가 여기서 드러났다.
기존 문서에 이미 설명된 내용은 해당 문서를 보완하는 쪽으로 정리했다. 새 문서가 필요한 내용은 적용 조건과 확인 근거, 한계를 함께 적었다. 반영한 후보는 어디에 내용이 들어갔는지 연결해 보관했다. 후보를 정리했다고 해서 원래의 판단 과정까지 없애지는 않았다.
특히 한 후보 안에서도 확정할 수 있는 범위가 달랐다. 터미널 복구 문제에서는 저장된 레이아웃과 실제 세션 복구 상태를 구분해야 한다는 원리를 따로 정리할 수 있었다. 그렇다고 당시 화면 증상의 원인이나 모든 버전에서의 해결까지 확정할 수 있는 것은 아니었다. 확인된 원리만 먼저 남기고 나머지는 보류하는 방식으로 나눴다.
이렇게 나누면 보류는 정리하지 못한 항목을 숨기는 상태가 아니었다. 무엇이 확인됐고 어떤 근거가 더 있어야 결론을 낼 수 있는지 남기는 상태가 됐다. 다음에 같은 문제가 나타났을 때도 후보 전체를 처음부터 다시 판단할 필요가 줄어든다. 다만 실제로 읽는 시간이나 토큰이 얼마나 줄었는지는 별도로 측정하지 않았다.
블로그 집필 방식도 같은 기준으로 정리했다. 독립된 여러 편을 작성할 때는 먼저 범위와 말투, 근거를 공유하고 각각 초안을 쓴 뒤 전체를 함께 검토하도록 했다. 이미 완성한 글을 병렬 작업이라는 이유로 다시 쓰게 하지는 않았다. 작업을 나누는 형식보다 중복과 누락을 줄이는 조건을 지식으로 남기는 편이 유용했다.
문서가 늘어난 만큼 매번 전체를 읽게 하는 방식도 피했다. 시작 문서에서 관련 자료로 들어가고, 필요한 구간을 확인한 다음 실제 판단에 사용한 문서를 남기는 흐름을 유지했다. 같은 내용을 다시 조회할 때는 변경이나 누락된 맥락이 있는지를 먼저 보도록 했다. KB가 존재한다는 이유로 매 작업의 읽기 부담까지 커지면 처음의 목적과 멀어질 수 있었다.
검증에도 같은 기준을 적용했다. 여러 프로젝트가 같은 계약을 다루다 보니 이미 통과한 검사를 다른 쪽에서 반복하기 쉬웠다. 변경된 연결 지점과 새로 드러난 실패를 검사하고, 구현과 입력이 그대로인 범위는 기존 결과의 근거를 확인해 재사용하기로 했다. 필요한 검증을 줄이는 대신 무엇을 확인하려고 실행하는 검사인지를 더 좁혔다.
결과
이번에는 지식의 개수보다 작업과 지식 사이의 연결을 정리했다. 검색 결과, 문서 선택, 적용 판단, 검증 결과를 같은 사실처럼 취급하지 않도록 했다. 적용 이력과 작업 기록이 맞는지 확인하는 경로도 연결했다. 후보 정리는 이 흐름에서 다시 쓸 수 있는 내용을 정식 문서에 남기는 작업이었다.
| 이전에 남던 질문 | 정리한 확인 기준 |
|---|---|
| 검색했으니 활용한 것인가 | 실제 선택과 적용 판단을 별도로 확인한다 |
| 기록이 없으면 사용하지 않은 것인가 | 미상과 이유 있는 미적용을 구분한다 |
| 적용했다면 성공한 것인가 | 적용 내용과 검증 결과를 함께 남긴다 |
| 대조 결과가 바뀌면 이전 것은 지워도 되는가 | 시도 당시 판단과 근거를 보존한다 |
| 날짜와 완료 표시를 그대로 집계해도 되는가 | 수행 근거와 담당 범위를 먼저 확인한다 |
| 후보를 전부 문서로 옮겨도 되는가 | 재사용 가능한 범위와 보류할 내용을 나눈다 |
구현 과정에서는 합성 입력으로 검색부터 판단 저장, 작업 종료 대조까지 연결해 확인했다. 적용 이력이 빠진 경우와 기록 후 일치하는 경우, 재시도해도 이전 근거가 보존되는 경우를 검사했다. 공용 전송 자료와 블로그 수신부의 판정도 맞춰 보았고, 비공개 판단 상세가 공개용 자료에 섞이지 않는 경계도 확인했다. 이 글을 위해 동일한 전체 검사를 다시 실행하지는 않았으며, 당시 남긴 검증 결과와 반영 기록을 근거로 삼았다.
아직 장기적인 개선 효과를 확인한 것은 아니다. 합성 연결 검사가 통과했다는 사실이 모든 실제 작업에서 판단이 빠짐없이 기록된다는 뜻은 아니다. 과거의 연결되지 않은 검색이나 수행일 미상 기록을 추정으로 복원하지도 않았다. 토큰 절감률이나 재작업 감소율은 비교 가능한 실제 기록이 쌓인 뒤 따로 평가해야 한다.
느낀점
- 지식을 찾는 것과 쓰는 것은 다른 단계였다. 검색 결과가 좋아져도 작업에 반영되는 과정은 따로 확인해야 했다. 어떤 판단으로 적용하거나 제외했는지가 다음 개선의 출발점이었다.
- 미상도 보존할 가치가 있었다. 비어 있는 값을 그럴듯하게 채우면 당장은 보기 편하지만 나중의 비교가 부정확해졌다. 확인한 사실의 범위를 지키는 편이 기록을 오래 쓰는 데 도움이 됐다.
- 보류에도 다음 판단을 위한 근거가 필요했다. 한 후보를 전부 확정하거나 전부 버릴 필요는 없었다. 확인된 원리를 먼저 정리하고 남은 조건을 분리하면 다음 검토의 시작점이 분명해졌다.
- 자동화의 범위를 설명할 수 있어야 했다. 도구는 기록의 연결과 일관성을 검사할 수 있지만 실제 판단을 대신 만들어서는 안 됐다. 어떤 사실을 입력했고 무엇을 검사했는지 남기는 일이 기능 자체만큼 중요했다.
지난 편에서는 비교할 기록을 모으는 준비를 했다면, 이번에는 그 기록이 무엇을 뜻하는지 더 좁혔다. 앞으로는 같은 기준으로 쌓인 실제 작업을 보면서 적용 판단이 자주 빠지는 지점과 반복되는 재작업을 확인하려고 한다. 문서가 많아졌다는 사실보다 같은 문제를 다시 만났을 때 판단을 더 정확하게 할 수 있는지가 중요해졌다.
긴 글을 읽어주셔서 감사하다.
댓글