[DocuFlow] PDF 도구를 만들다가 문서 흐름을 보게 됐다

PDF 도구를 처음 만들 때는 기능 단위로 생각했다. 합치기, 나누기, 회전, 압축, OCR, 마스킹. 각각은 쓸모가 분명했다.

그런데 사용자가 남기는 말은 기능 이름이 아니었다. “또 올려야 해요”, “중간 결과가 맞는지 모르겠어요”, “주민번호 가렸는지 불안해요.”

기능 목록이 늘어날수록 문서 작업은 더 분절됐다. 그 지점에서 시선이 바뀌었다. 도구가 아니라 흐름을 설계해야 한다.

PDF 도구가 커진 문제

여러 사이트와 툴을 전전하면 사용자는 같은 파일을 반복해 올리고 내려받는다. 한 번 변환할 때마다 맥락이 끊긴다.

• 합친 뒤 OCR 사이트에 다시 업로드
• OCR 뒤 마스킹 툴에 다시 업로드
• 마스킹 뒤 메일/업무 시스템에 다시 첨부
• 오류 나면 어느 파일이 최신인지 모름

기능은 성공해도 사람은 지친다. 문서 자동화의 병목은 CPU보다 손과 불안의 반복에 있었다.

한국 문서 업무에서는 이 마찰이 더 커진다. PDF와 HWP가 섞이고, 도장·서명·주민번호 같은 민감 요소가 자주 등장한다. “그냥 변환”이 아니라 “믿고 넘길 수 있는가”가 실제 채택 기준이 된다.

배포 초기에 기능 완성도를 자랑하고 싶었지만, 실제 피드백은 기능 품질보다 이동 비용에 모였다. 변환이 빨라도 파일을 세 번 다시 올리면 사람은 그 제품을 느리다고 느낀다. 체감 속도는 연산 시간이 아니라 손의 횟수다.

처음에는 도구가 답일 줄 알았다

초기 가설은 “필요한 기능을 많이 모으면 플랫폼이 된다”였다. PDF Master, 마스킹, HWP, OCR을 각각 잘 만들면 언젠가 연결될 거라 봤다.

구멍은 연결이 자동으로 생기지 않는다는 점이었다. 기능 사이에는 최소한 이런 계약이 필요하다.

1. 입력 파일이 무엇인지
2. 중간 산출물을 신뢰할 수 있는지
3. 민감정보가 어느 단계에서 다루어지는지
4. 실패 시 어느 단계부터 다시 하면 되는지
5. 결과물을 어디에 넘기는지

이 계약 없이 버튼만 늘리면 도구 모음은 생겨도 워크플로는 생기지 않는다. 사용자는 기능 페이지마다 새로운 미니 제품을 학습해야 하고, 우리는 같은 업로드 UX를 반복 구현하게 된다.

또 다른 구멍은 처리 위치의 모호함이었다. 어떤 작업은 브라우저에서 끝나는 편이 신뢰에 유리하고, 어떤 작업은 서버/워커가 필요하다. 이를 기능 이름 뒤에 숨기면 사용자는 “이 파일이 어디로 가는지”를 추측해야 한다. 추측이 필요한 제품은 민감 문서에서 먼저 탈락한다.

가설을 고치면서 백로그 정렬 방식도 바꿨다. “OCR 정확도 2% 개선”보다 “재업로드 1회 제거”가 더 높은 우선순위가 되는 날이 생겼다. 기능 팀의 자존심 문제처럼 보일 수 있지만, 실제로는 사용자 문장에 맞춘 것이다.

흐름이 선명해진 순간

전환율 숫자보다 선명했던 불만은 “다시 올리기”였다. 사용자는 변환 시간보다 재업로드 횟수에 화를 냈다.

동시에 보안 불안이 붙었다. 민감 문서를 어디로 올리는지 보이지 않으면, 기능이 훌륭해도 쓰지 못한다. 특히 마스킹/OCR처럼 내용 열람이 필요한 단계에서 이 불안이 커진다.

불만의 형태는 대개 세 문장으로 수렴했다.

• 또 올려야 함
• 중간 결과가 맞는지 모름
• 민감정보가 남았는지 불안함

이 세 문장을 기능 추가만으로 풀 수는 없다. 단계 가시성, 미리보기, 처리 위치 공개, 실패 구간 표시가 같이 가야 한다.

불만을 티켓으로 옮길 때도 주의가 필요했다. “마스킹 기능 개선”으로 받으면 버튼 고치기로 끝나고, “보호 단계 신뢰 부족”으로 받으면 미리보기·경고·처리 위치 공개가 같이 열린다. 문제를 어느 층으로 명명하는지가 설계 범위를 결정한다.

경계를 다시 배치하기

DocuFlow 쪽으로 옮긴 기준은 기능 카탈로그가 아니라 단계형 흐름이다.

단계	질문	설계 포인트
수집	어떤 문서가 들어오는가	포맷/페이지/용량 가시화
변환	무엇을 바꾸는가	브라우저 처리 vs 서버 처리 분리
보호	무엇을 가리는가	마스킹 위치와 미리보기
확인	결과를 믿을 수 있는가	전후 비교, 실패 구간
전달	어디로 넘어가는가	재업로드 최소화

특히 브라우저에서 할 일과 서버에서 할 일을 나누는 것이 핵심이었다. 모든 것을 서버로 보내면 구현은 쉬워 보여도 신뢰 비용이 커지고, 모든 것을 브라우저로만 밀면 한글/OCR 한계에 막힌다.

이 경계를 문서화하면 제품 문장도 달라진다. “업로드하면 끝”이 아니라 “이 단계는 기기에서 처리되고, 이 단계만 서버를 거친다”고 말할 수 있다. 기능 마케팅보다 신뢰 설계에 가까운 문장이다.

경계 재배치는 내부 패키지 구조에도 영향을 줬다. 기능 함수를 페이지마다 복제하기보다, 단계 계약을 공유하고 UI만 다르게 두는 쪽이 유지보수에 유리했다. 도구 페이지가 늘어나도 사용자가 배우는 동선은 같아야 한다. 그게 플랫폼의 최소 정의에 가깝다.

구현과 운영에 남긴 조건

• 민감 처리 단계를 숨기지 않는다
• 중간 산출물 없는 “한 방 마법 버튼”을 기본값으로 두지 않는다
• 실패 시 어느 단계부터 재시도인지 표시한다
• PDF 도구군과 문서 흐름 제품의 문장을 구분한다
• 재업로드 횟수를 성공 지표의 일부로 본다

pdf-master, DocuFlow, 마스킹/변환 유틸은 같은 문제의 다른 해상도다. 공통 목표는 기능 수 자랑이 아니라 다시 올리지 않아도 되는 경로다.

실무적으로는 단계마다 산출물 메타데이터(페이지 수, 처리 위치, 경고)를 남기는 편이 디버깅과 사용자 안내에 모두 유리했다. 기능 함수가 성공해도 흐름이 실패할 수 있다는 점을, 로그 축부터 인정해야 한다.

불변조건은 신기능 제안의 필터로도 썼다. 새 버튼이 재업로드를 줄이지 못하고, 민감 단계를 더 불투명하게 만들면 보류한다. 기능이 많아 보이는 제품과 손이 덜 가는 제품 중 후자를 고르겠다는 선언이다.

흐름 제품으로 넘어갈 때의 실무 기준

도구 모음에서 흐름 제품으로 넘어갈 때 내가 쓰는 기준은 단순하다.

• 이 기능이 재업로드를 줄이는가
• 중간 산출물을 사용자가 확인할 수 있는가
• 민감 처리 위치가 문장으로 드러나는가
• 실패 시 되돌아갈 단계가 보이는가
• 다음 업무 시스템으로 넘기는 비용이 줄어드는가

다섯 중 세 개 이상 “아니오”면 아직 기능 페이지일 뿐이다. 버튼 수가 많아도 흐름이 없으면 사용자는 여전히 파일 택배 기사처럼 일한다. DocuFlow가 남기려는 차이는 그 택배 횟수를 줄이는 쪽에 있다. 흐름 설계로 넘어가면서 가장 도움이 된 연습은 “한 사용자의 하루”를 기능 단위가 아니라 파일 단위로 적어 보는 일이었다. 어떤 파일이 아침에 들어와서 저녁에 어디로 나가는지, 그 사이에 손이 몇 번 멈추는지. 그 메모를 보면 기능 로드맵의 허영이 빨리 드러난다.

예를 들어 OCR 정확도를 올리는 일은 중요하다. 하지만 사용자가 OCR 전에 이미 세 번 변환 사이트를 전전한다면, 정확도 개선의 체감은 늦게 도착한다. 반대로 합치기-마스킹-확인을 한 흐름으로 잇고 중간 미리보기를 주면, 정확도가 같아도 제품이 더 똑똑해 보인다. 똑똑함의 상당 부분은 동선이다.

민감정보 처리에서는 “안심 문구”보다 “확인 가능성”이 강했다. 가렸다는 말보다, 어디를 가렸는지 전후 비교로 보여 주는 편이 신뢰에 직접적이다. 브라우저 처리 구간을 명시하는 것도 같은 계열이다. 숨긴 채 잘해 주기보다, 보이는 범위에서 잘해 주는 쪽이 문서 제품에 맞다.

마지막으로, 도구 페이지를 완전히 없애자는 주장은 아니다. 단일 기능 진입은 검색과 공유에 유리하다. 다만 단일 기능 페이지도 흐름의 한 정거장처럼 행동해야 한다. 입력과 출력의 계약, 다음 단계 제안, 실패 시 되돌아갈 위치. 이 세 가지가 있으면 도구 페이지도 흐름 제품의 일부가 된다. 없으면 영원히 외톨이 버튼이다. 문서 제품에서 내가 경계하는 문장이 있다. “원클릭으로 모두 해결”. 매력적이지만 민감 문서에서는 위험하다. 모두 해결을 약속할수록 중간 확인이 사라지고, 중간 확인이 사라질수록 사고 한 번의 피해가 커진다.

대신 약속하고 싶은 문장은 이것이다. “손이 멈추는 단계를 줄이고, 멈추더라도 어디서 다시 하면 되는지 보여 준다.” 덜 화려하지만 더 오래 간다. DocuFlow를 도구 모음이 아니라 흐름으로 보려 한 이유는, 바로 그 문장을 제품 구조에 새기기 위해서였다.

문서 자동화 로드맵을 기능 카드로만 관리하면 항상 다음 버튼이 승리한다. 흐름 지표를 옆에 두면 승자가 바뀐다. 재업로드, 중도 이탈 단계, 민감 확인 스킵률. 이 숫자들을 보기 시작하면서 나는 비로소 도구 제작자에서 흐름 설계자에 가까워졌다. 같은 결론을 다음 주 우선순위 회의에서도 다시 꺼내 보려 한다.

문서 자동화 로드맵을 기능 카드로만 관리하면 항상 다음 버튼이 승리한다. 흐름 지표를 옆에 두면 승자가 바뀐다. 재업로드, 중도 이탈 단계, 민감 확인 스킵률. 이 숫자들을 보기 시작하면서 나는 비로소 도구 제작자에서 흐름 설계자에 가까워졌다.

마치며

문서 자동화는 기능을 모은다고 완성되지 않는다. 사용자가 파일을 몇 번 다시 올리는지, 중간 결과를 믿을 수 있는지, 민감정보를 언제 확인하는지로 완성도가 갈린다.

도구를 만들다 흐름을 보게 된 뒤부터는 질문 순서가 바뀌었다. “무슨 기능을 추가할까”보다 “어느 단계에서 손이 멈추는가.”

손이 멈추는 지점을 줄이는 쪽이, 버튼 하나를 더 만드는 쪽보다 강한 문서 제품이다. 다음 설계에서도 기능 목록보다 단계 계약 표를 먼저 펼치겠다.