자동화를 돌리다 보면 이런 일이 생깁니다. 폴더를 정리하다 파일 하나를 옮겼는데, 다음 날 아침 워크플로가 통째로 실패해 있는 겁니다.
에이전트는 경로로 파일을 찾습니다. 사람은 경로를 아무렇지 않게 바꿉니다. 둘이 같은 폴더를 쓰면 깨질 수밖에 없습니다.
더 성가신 쪽은 따로 있습니다. 에이전트가 30분 전 상태를 기준으로 문서를 쓰면서, 그사이 내가 고쳐둔 내용을 조용히 덮어씁니다. 에러도 안 납니다. 며칠 뒤에야 뭔가 사라졌다는 걸 알게 됩니다.
Docbank는 딱 이 지점을 노린 도구입니다. 만든 곳은 Kenn Software.
파일 이름 대신 번호로 문서를 찾는다
Docbank는 문서마다 고유 ID를 붙입니다. 이름을 바꾸든 위치를 옮기든 이 ID와 버전 이력이 그대로 따라다니기 때문에 에이전트가 대상을 놓치지 않습니다.
덮어쓰기는 막아뒀습니다. 문서를 고치려면 “내가 아는 최신 리비전은 3번”이라는 정보를 같이 보내야 합니다. 그사이 누군가 4번을 만들어놨으면 저장이 거부됩니다. 조용히 덮어쓰는 대신 시끄럽게 실패하는 쪽을 택한 설계입니다.
저장된 모든 버전에는 SHA-256 값이 붙고, docbank verify 명령으로 저장된 바이트를 다시 해싱해 대조할 수 있습니다. 백업은 바뀐 부분만 뜨고, 복원해보고 검증할 때는 별도의 금고에 풀어서 확인합니다. 백업 스크립트를 짜두고 복원을 한 번도 안 해본 사람이라면 이 항목이 눈에 들어올 겁니다.
붙이는 방법
명령줄, 터미널 화면(TUI), 로컬 웹 화면 세 가지가 있고, Go로 짠 프로그램 안에 라이브러리처럼 넣을 수도 있습니다.
에이전트는 HTTP API로 붙습니다. 다만 loopback API입니다. CLI든 에이전트든 스크립트든 전부 같은 인증 API를 쓰고, 금고로 질러가는 지름길을 가진 쪽은 없습니다. 원격에서 팀원이 붙는 구조가 아니라, 같은 머신 안에서 사람과 에이전트가 같은 창구를 쓰는 구조입니다.
저장에 성공하면 방금 들어간 내용의 지문 값이 응답으로 돌아옵니다. “성공했겠지”가 아니라 증거를 손에 쥐여준다는 게 이 설계의 요지입니다.
클라우드 드라이브나 NAS로는 왜 안 되나
원문이 비교 대상으로 삼는 건 Dropbox·Google Drive, 그리고 NAS입니다.
클라우드 드라이브는 동기화와 공유는 잘하지만, 접근 권한과 이력과 복구가 전부 서비스 정책에 묶입니다. 계정이 잠기면 아카이브 전체가 같이 잠깁니다.
NAS 쪽 논지가 더 흥미롭습니다. 체크섬이나 스냅샷을 지원하는 제품도 있지만 그건 기기와 파일시스템에 달린 얘기고, 결국 폴더 경로 하나가 너무 많은 역할을 떠맡는다는 겁니다. 저장소는 바이트가 어디 있는지만 답하고, 그게 어느 문서인지·무슨 일이 있었는지는 답하지 않습니다.
한편 Docbank는 클라우드 드라이브의 대체재가 아닙니다. 기기 간 동기화도, 링크 공유도 없습니다. 빠뜨린 게 아니라 일부러 뺀 것이라고 못 박고 있습니다.
그래서 지금 붙일 만한가
먼저 짚어야 할 게 있습니다. Docbank는 alpha이고 1.0이 아닙니다. 업무 문서를 여기 옮기는 건 지금 단계에서 권하기 어렵습니다.
성격도 확인해둘 필요가 있습니다. 같은 회사의 msgvault가 메시지를 불변 기록으로 보존하는 쪽이라면, Docbank는 계속 정리하고 검색하고 워크플로를 붙이는 ‘작업 중인 문서’ 쪽입니다. 다 끝난 파일을 넣어두는 창고가 아닙니다.
스크립트 몇 개 돌리는 수준이면 과합니다. 폴더 공유로 충분합니다. 값을 하는 건 에이전트가 정기적으로 문서를 만들고 고치면서, “누가 언제 뭘 바꿨나”를 되짚어야 하는 구조일 때입니다.
지금 시점의 현실적인 태도는 이 정도입니다. 테스트 금고를 하나 만들어 개인 문서로 굴려보고, 1.0이 나오면 그때 다시 본다. Apache 2.0이라 나중에 사내 도입을 검토할 때 라이선스는 걸림돌이 안 됩니다.