사무자동화 도구를 만들고도 웹에 한 줄도 없으면 무슨 일이 생기는가?
사무자동화 도구가 있어도 웹에 아무것도 없으면, 소개서를 받은 사람은 검색창에서 막힙니다. 우리가 겪은 일이 정확히 그랬습니다. 대사 엔진도 있었고, 소개서 10쪽도 있었고, 대화가 오가던 상대도 한 곳 있었는데, 웹에는 한 줄도 없었습니다.
메일을 받은 사람이 가장 먼저 하는 일은 보낸 회사 이름을 검색하는 것입니다. 거기서 아무것도 나오지 않으면 메일 내용이 아무리 좋아도 신뢰가 서지 않습니다. 이 상태가 다음 발송을 막고 있었습니다. 엔진을 더 다듬는 일이 아니라, 검색한 사람이 도착할 면 하나가 비어 있던 것입니다.
여기서 말하는 대사는 거래처가 보낸 명세서와 우리 쪽 지불 예정 목록을 나란히 놓고 금액과 거래처가 맞는지 확인하는 일입니다. 사람이 엑셀 두 장을 눈으로 맞추던 일을 엔진이 먼저 훑고, 맞는 행과 어긋나는 행을 판정 이름을 붙여 나눠 줍니다. 판정 이름에는 금액 불일치, 미등록 거래처, 지불예정에 없음 같은 것이 있습니다.
이 글은 그 빈자리를 메운 페이지를 어떤 대안을 버리고 어떤 구조로 만들었는지, 그리고 만든 뒤 맥락 없는 독자에게 읽혀 가며 무엇이 틀렸는지를 기록한 구축기입니다. 변경 규모는 5개 파일에 812줄 추가, 3줄 삭제였습니다.
이 페이지로 검색 유입을 받으려고 했는가?
아닙니다. 가장 먼저 버린 안이 검색 유입을 노리는 페이지였습니다. 이유는 숫자에 있었습니다. 대사 같은 니치 업무 용어(“거래명세서 대사”)는 검색량이 사실상 0이었고, 순위를 다툴 만한 검색어 100종 중에 이긴다고 볼 수 있는 검색어가 1개뿐이라는 내부 분석이 있었습니다.
검색량이 없는 말에 순위를 걸고 페이지를 만들면 만든 값을 회수할 길이 없습니다. 그래서 이 페이지는 처음부터 유입용이 아니라 접촉 후 검증용으로 정했습니다. 독자는 이미 소개서를 받은 사람이고, 우리를 알고 옵니다.
처음부터 이 판단이 쉬웠던 것은 아닙니다. 엔진이 있고 소개서가 있으니 웹에도 올려 두면 언젠가 검색으로 누군가 올 것이라는 기대는 자연스럽습니다. 하지만 기대와 달리 올 사람이 없는 검색어에 면을 만들면, 면은 남고 방문은 없습니다. 방문이 없는 면은 관리 비용만 쌓이므로, 쓰임이 분명한 독자 한 명을 위해 만드는 쪽이 낫다고 판단했습니다. 그 한 명은 소개서를 손에 쥔 채 우리 이름을 검색창에 넣는 사람입니다.
독자가 이미 안다는 전제는 구성도 바꿨습니다. “이게 뭔가”에 답하는 소개가 첫머리에 올 필요가 없습니다. 이 독자가 궁금한 건 “이 사람들이 진짜 이걸 하나”이므로, 첫 화면 다음에 소개가 아니라 실적을 놓았습니다.
같은 맥락에서 검색에서 노출이 붙는 원리를 따로 따져 본 글이 있습니다. 노출이 안 붙는 원인을 짚은 SEO 콘텐츠 노출이 안 붙은 원인 — 중복이 아니라 검색광고 입찰가였다를 함께 보면, 검색용 페이지와 검증용 페이지를 왜 갈라 만들었는지 더 잘 보입니다.
버린 대안은 무엇이고 각각 왜 탈락했는가?
구축기에서 가장 쉽게 빠뜨리는 부분이 버린 안입니다. 이 페이지에서 실제로 갈린 대안은 네 가지였고, 탈락 사유는 모두 작업 기록에 남아 있는 것만 적습니다.
표의 세 번째 줄이 가장 사소해 보이지만 신뢰에 가장 직접 닿습니다. 소개서 화면을 캡처해 붙이면 만들기는 쉽지만, 방문자는 그게 지금 돌아가는 결과인지 한 번 만든 그림인지 알 수 없습니다. 그래서 실행 결과 표는 데모 스크립트(demo_e2e.py)를 그날 다시 돌려 나온 출력을 그대로 옮겼습니다.
네 안을 하나씩 버리는 동안 공통점이 하나 보였습니다. 모두 “누가 이 페이지를 여는가”라는 질문에서 갈렸다는 점입니다. 검색으로 오는 낯선 사람을 상정하면 소개와 순위가 중요해지고, 소개서를 받은 사람을 상정하면 증거와 한계의 공개가 중요해집니다. 이 페이지는 후자를 골랐고, 선택의 근거는 취향이 아니라 독자가 누구인가였습니다.
네 번째 줄은 기술 판단이 아니라 사업 판단이라 따로 적습니다. 이 서비스는 아직 판매 서비스 목록에 올라 있지 않고 가격은 사업 결정 사항이라, 페이지에 가격을 적지 않기로 했습니다. 검증 단계에서 가격 표기가 0건인지 직접 확인했습니다.
선택한 구조는 어떻게 생겼는가?
구조는 한 문장으로 줄일 수 있습니다. 소개서를 받은 사람이 검색해서 도착하면, 실적으로 신뢰를 먼저 세우고, 설계에서 지킨 약속과 아직 모르는 한계를 숨기지 않고 보여 준 뒤, 샘플 파일을 보내도록 안내하는 면입니다.
순서를 이렇게 잡은 이유는 읽는 사람의 질문 순서와 맞추기 위해서입니다. 메일을 받은 사람은 이미 무엇을 하는 서비스인지 압니다. 그다음 떠오르는 질문은 실제로 돌려 본 적이 있는지, 틀리면 어떻게 되는지, 내 파일은 어디로 가는지입니다. 이 세 질문에 각각 실적, 설계에서 지킨 것과 아직 모르는 것, 처리와 파기 안내가 답하도록 면을 나눴습니다.
카피는 새로 쓰지 않았습니다. 소개서 문장을 옮겼고, 숫자와 분류 이름은 엔진에서 그대로 가져왔습니다. 두 곳이 서로 다른 말을 하는 순간 신뢰가 깨지기 때문에, 문장의 출처를 소개서 한 곳과 엔진 한 곳으로 묶었습니다.
코드 쪽은 페이지 경로 하나(17줄), 화면 컴포넌트(395줄), 문구 사전 파일(375줄), 검색엔진용 사이트맵(4줄), 상단 메뉴 정의(24줄 변경)로 나뉩니다. 문구를 화면 코드에서 떼어 사전 파일로 모은 선택이 뒤에서 큰 몫을 합니다. 상단 메뉴는 정본이 다른 저장소에 있고, 이 커밋의 메뉴 정의는 그 사본이며 메뉴를 여는 일은 정본 쪽 변경에서 합니다.
구현에서 막힌 곳은 어디였는가? 맥락 없는 독자 시험이 잡은 것
막힌 곳은 코드가 아니라 문장이었습니다. 페이지를 올린 뒤 이 회사를 전혀 모르는 독자에게 읽히는 시험을 돌렸고, 첫 두 번의 시험에서 회계팀장 역할과 회의적인 실무자 역할을 각 2명씩 세웠습니다. 읽은 사람이 의심하는 지점이 곧 방문자가 의심할 지점이라는 가정이었습니다.
이 시험은 만든 사람이 읽으면 못 보는 빈 곳을 잡으려는 장치입니다. 만든 사람은 어느 문장이 어느 소개서 쪽에서 왔는지 다 알기 때문에 빈 곳을 머릿속에서 메워 읽습니다. 맥락이 없는 독자는 메우지 못하고 그 자리에서 멈춥니다. 멈춘 자리가 곧 고칠 자리였습니다.
첫 두 회차에서 나온 지적은 다음과 같았습니다. 받은 지적을 하나씩 고쳤고, 고친 이유를 같은 표에 적습니다.
가장 아팠던 지적은 “명세서 두 장을 주세요”라고 하면서 그 파일을 어떻게 다루는지는 한 줄도 적지 않았다는 점입니다. 파일을 맡기는 쪽에서 가장 먼저 묻는 질문이 처리와 파기인데, 비어 있었습니다. 스캔본을 글자로 읽어 주는 외부 제품이 클라우드일 수 있다는 사실도 적었습니다. 처음 글은 “대사 프로그램 자체가”라는 한정어로 그 구간을 비켜 가고 있었습니다.
두 번째는 반대편 위험입니다. 모든 행을 사람이 보지 않는다는 점을 자랑해 놓고, 그 반대 위험인 잘못 붙은 일치에는 답이 없었습니다. 소개서 7절 “설계에서 지킨 것”을 통째로 빠뜨린 탓이었습니다. 그래서 설계 섹션을 새로 만들고 “아직 모르는 것”에 오탐률을 넣었습니다.
세 번째와 네 번째는 숫자입니다. 12/12와 16/16은 무엇을 센 분모인지 없어서 검증할 수 없는 숫자로 읽혔습니다. 같은 페이지에 “기성품이 없습니다”와 “전수 확인한 것은 아닙니다”가 함께 있어 서로 부딪쳤습니다. 없다는 말은 끝까지 찾아본 사람만 할 수 있는 말이라서 부재 단정을 철회했습니다. 해외 벤치마크는 실적 타일과 같은 모양이라 우리 성과로 읽힐 수 있어 목록으로 내렸고, 표본 6건(n=6) 데모에 “50.0%”라는 없는 정밀도를 쓰던 자리도 건수만 남겼습니다.
고친 문장이 새 모순을 만들었다 — 4·5회차에서 무엇이 드러났는가?
가설은 “지적을 다 반영했으니 이제 깨끗하다”였고 반증됐습니다. 독자 2명에게 두 회차를 더 읽혔더니, 앞 회차에서 내가 덧붙인 조각들이 서로 모순을 만들고 있었습니다. 두 독자가 같은 자리를 지목한 지적 하나가 특히 컸습니다.
“주실 것” 목록의 첫 줄은 거래처명과 금액은 가려도 된다고 했고, 셋째 줄은 금액과 날짜는 그대로 두어야 판정 비율이 나온다고 했습니다. 같은 목록 안에서 반대 말을 한 것입니다. 첫 줄대로 가리면 금액 불일치 판정과 자동 확인 비율이 아예 나오지 않습니다. 가리는 규칙을 한 곳으로 모아서 풀었습니다.
더 깊은 모순도 있었습니다. 상호를 일괄 치환해도 지장 없다는 말이 이 페이지의 핵심 주장과 정면으로 부딪쳤습니다. 전부 “거래처A”로 바꾸면 (주), ㈜, 주식회사 같은 표기 차이가 사라지고, 그러면 엔진이 풀어야 할 가장 어려운 부분이 빠진 결과가 나옵니다. 그래서 형태는 남기고 이름만 바꾸는 방법으로 고쳤습니다.
나머지 지적은 작지만 전부 같은 뿌리였습니다.
- 미등록 거래처 판정은 거래처 마스터가 있어야 나오는데 “주실 것”에 없었다 → 목록에 추가
- 스캔본을 읽어 주는 제품이 어떤 곳은 “가져다 씁니다”(선정 완료), 다른 곳은 “아직 정하지 않았으므로”로 적혀 있었다 → 한 문장으로 통일
- “건드리지 않는 구간”이라는 라벨이 1단계(직접 만들지 않는다)와 3단계(귀사 프로그램에 손대지 않는다)에서 다른 뜻이라 오류 책임이 누구에게 있는지 반대로 읽혔다 → 설명 문구를 분리
- 장부 화면 캡처가 처리 안내 두 갈래 어디에도 들어 있지 않았다 → 명시
- “몇 시간에서 몇 시간으로”를 약속했는데 현재 소요 시간을 받지 않았다 → 조건부 문장으로 정정
- “대개 사람이 합니다”, “대부분의 자동화 시도가 여기서 멈춥니다” 같은 출처 없는 빈도 단정 → 철회
- 해외 벤치마크 3수치 → 두 독자가 두 회차 연속으로 “확인 안 한 숫자를 왜 실었나”라고 물어서 제거
- 판정 이름 “일치”와 “예상과 맞았다”의 “일치”가 섞였다 → 후자는 “예상대로”로 변경
- 요약이 “지불예정에 없음”을 “미등록”으로 줄여 불러 “미등록 거래처”와 섞였다 → 판정 이름 그대로 사용
6회차에서 「+13,000원」은 왜 정반대로 읽혔는가?
6회차에서 두 독자 모두 결함 없음으로 판정했습니다. 대신 실무자 역할이 “다음 회신에 물을 것”으로 남긴 질문 하나가 페이지가 답할 수 있는 질문이었습니다. 화면에 “+13,000원”이라는 차액이 나오는데 부호 기준이 없었습니다.
부호 기준이 없으면 같은 숫자가 정반대 행동을 부릅니다. 거래처가 더 청구했다면 담당자는 거래처에 따져 물어야 하고, 우리 장부에서 빠뜨렸다면 우리 쪽을 고쳐야 합니다. 어느 쪽인지 몰라서는 일을 시작할 수 없습니다.
답은 엔진 코드가 이미 정해 두고 있었습니다. 엔진의 차액 계산 코드(recon.py 99번째 줄)가 정의한 그대로 적었습니다. 같은 질문의 나머지 절반인 “차액만 나옵니까”에도 함께 답했습니다. 판정 결과(Finding)는 명세서 합계와 지불예정 합계를 둘 다 싣고, 원본 위치까지 붙입니다.
이 질문이 6회차에야 나왔다는 점도 기록해 둡니다. 앞선 회차에서는 더 큰 구멍이 시야를 가리고 있었습니다. 파일 취급 설명이 없고, 반대편 위험에 답이 없고, 마스킹 지시가 서로 부딪치는 동안에는 차액 부호처럼 세부 항목이 후순위로 밀립니다. 큰 구멍을 모두 막은 다음에야 실무자가 실제 업무 장면으로 넘어가 “이 숫자를 받으면 내가 무엇을 하지”를 묻기 시작했고, 그 질문이 부호 문제였습니다. 시험 회차가 더 필요했던 이유가 여기에 있습니다.
이 수정은 새 기능이 아니라 코드에 이미 있는 정의를 페이지로 옮긴 것입니다. 페이지의 주장이 코드와 한 글자라도 다르면 읽는 쪽이 코드를 믿게 됩니다. 그래서 정의의 출처를 코드 줄 번호까지 붙여 고정했습니다.
운영에서 드러난 것은 무엇인가? 조각을 덧붙이면 그 조각이 다음 모순을 만든다
가장 큰 교훈은 4·5회차에 나왔습니다. 지적이 나올 때마다 문구를 한 조각씩 갈아 끼웠더니 사본이 늘었고, 사본끼리 어긋났습니다. 마스킹 지시가 목록 안에서 서로 모순이던 일도, 스캔 제품 서술이 두 곳에서 달랐던 일도 같은 원인에서 나왔습니다.
조각을 덧붙이면 그 조각이 다음 모순을 만든다.
그래서 문구 사전 파일을 조각 치환으로 고치는 대신 확정본으로 통째 다시 썼습니다. 한 값은 한 곳에만 두고, 화면은 그 값을 가져다 쓰는 구조입니다. 마스킹 규칙이 페이지 안에 한 곳만 남았는지, 사전 상수가 중복되지 않았는지는 기계로 확인했습니다.
왜 이 방식이 통했는지도 적어 둡니다. 문구를 화면 코드 안에 흩어 두었다면 같은 규칙이 여러 화면 파일에 사본으로 남아 한 군데만 고치고 지나갔을 것입니다. 문구를 사전 파일 한 곳에 모아 둔 덕분에 마스킹 규칙 하나를 고치는 일이 한 줄을 찾는 일로 줄었습니다. 반대로 사전 파일이 375줄까지 커지는 동안 조각 치환을 반복하면 사본이 늘어난다는 사실은, 파일이 커진 뒤에야 보였습니다.
검증은 세 겹으로 했습니다. 빌드가 오류 없이 끝나는지(종료 코드 0), 상단 메뉴의 AI·AX 드롭다운에서 클릭해 이 페이지에 도착하는지(브라우저 자동화 도구 Playwright로 확인), 소개서의 필수 9항목이 페이지에 전부 있는지(문자열 검색)입니다. 가격 표기는 0건이어야 했고 0건이었습니다.
끝에 남기는 정직한 한계도 있습니다. 이 페이지가 근거로 삼은 기록에는 올린 뒤의 방문자 반응이 들어 있지 않습니다. 독자 시험은 사람 역할을 맡긴 읽기 시험이지 실제 방문자 데이터가 아닙니다. 시험에서 결함이 없다고 나온 6회차도 “다음에 물을 질문”은 남겼습니다.
지금 상태와 다음 단계는 무엇인가?
지금 이 면은 올라가 있고, 소개서를 받은 사람이 검색했을 때 도착할 자리가 생겼습니다. 하지만 이 글을 쓰는 시점에 확인된 사실은 페이지가 읽히고 모순이 걷혔다는 것까지이고, 이 페이지가 계약에 얼마나 기여했는지는 아직 알 수 없습니다.
이 기록에서 얻은 규칙을 하나만 꼽으면, 외부로 나가는 면은 만든 사람이 아니라 맥락 없는 독자가 끝까지 읽혀 보고 올린다는 것입니다. 회차가 올라갈수록 지적은 큰 누락에서 작은 모순으로, 마지막에는 부호 하나로 작아졌습니다. 지적이 작아지는 모양이 곧 면이 단단해지는 신호였고, 6회차에서 결함 없음이 나온 뒤에야 멈췄습니다. 반대로 한두 번 읽고 끝냈다면 마스킹 모순과 부호 문제는 방문자가 먼저 발견했을 것입니다.
정리하면 이 페이지는 완성품이 아니라 검증 중인 면입니다. 소개서 10쪽이 말하는 것과 웹이 말하는 것이 어긋나지 않게 맞추고, 모르는 부분을 모른다고 적어 두었다는 점이 지금 갖춘 전부입니다. 계약으로 이어지는지는 발송이 다시 시작된 뒤의 반응이 알려 줄 것이고, 그 결과가 나오면 이 글에 이어서 적겠습니다. 그때까지는 가격도, 효과 수치도, 고객 사례처럼 근거가 없는 이야기도, 우리가 확인하지 못한 주장도 이 면에 올리지 않습니다.
다음에 할 일은 세 가지입니다.
- 오탐률(잘못 붙은 일치 비율)을 실제 값으로 채우는 일. 지금은 “아직 모르는 것”에 이름만 있습니다
- 상단 메뉴 정본 쪽 변경으로 메뉴를 정식으로 여는 일. 이 커밋의 메뉴 정의는 사본입니다
- 가격 게시 여부는 사업 판단이 서야 정해지므로, 그전까지는 계속 적지 않습니다
사무자동화를 맡기려는 쪽에서 가장 먼저 묻는 질문은 “이 회사가 진짜 이걸 하나”입니다. 거래명세서 대사처럼 검색창에 거의 안 나오는 업무는 검색 순위로 설득할 수 없으니, 받은 사람이 도착하는 면에서 실적과 한계를 같이 보여 주는 쪽이 답이었습니다. 비슷한 업무 자동화를 검토 중이라면 상담에서 업무 흐름부터 같이 살펴볼 수 있습니다.