상담 전에 대략적인 규모를 알고 싶은 사람에게 숫자를 보여 주는 것은 도움이 된다. 다만 면적 하나를 입력했다고 현장 조건까지 확인한 견적이 되지는 않는다. 실제 상담 사이트의 범위 계산과 문구를 읽고 그 사이의 약속을 정리했다.

입력이 적을수록 결과의 이름을 좁혔다

기존 화면은 면적과 선택 조건을 받아 계산한 범위를 보여 준다. 방문자가 처음 질문하기에는 짧은 입력이 편하지만 지역·설치 조건과 실제 계약 조건까지 받은 것은 아니다. 나는 입력이 적다는 장점을 유지하면서 결과를 확정 가격처럼 부르지 않는 것이 중요하다고 보았다.

그래서 이번 예제의 결과에는 quoteConfirmed를 false로 둔다. 상담에서 확인해야 할 조건이 남아 있다는 뜻이다. 어떤 업종에서도 적은 입력만으로 모든 비용을 알아냈다고 표현하기 전에 계산이 실제로 받은 사실과 아직 모르는 사실을 나누어 보면 좋다.

공유 예제는 시장 단가를 가져오지 않았다

새 estimate 함수는 basic과 extended라는 합성 규칙만 받는다. basic의 계수는 2와 3, extended는 3과 5이며 단위도 synthetic units다. 면적 10이면 각각 20~30과 30~50이다. 이 숫자는 실제 설치비와 절감액을 안내하는 값이 아니라 규칙 전환을 검산하는 고정 예제다.

원래 프로젝트의 업종 계수를 복사해 최신 가격처럼 공개하지 않았다. 규칙 버전 demo-v1도 결과에 남겨 어떤 기준으로 나온 범위인지 알 수 있게 했다. 실제 사업에 연결할 때는 담당자가 승인한 현행 기준과 적용 범위를 별도로 준비해야 한다.

0과 비어 있음이 결과를 만들지 않게 했다

면적은 유한한 양수이고 예제의 상한 안에 있어야 한다. 숫자 문자열과 참·거짓, 알 수 없는 규칙도 계산 함수에서 거절한다. 화면은 입력을 숫자로 바꾼 뒤 오류를 결과 영역에 남긴다. 잘못된 입력이 들어오면 이전 상담 맥락도 지워 오래된 범위를 새 입력의 결과로 전달하지 않는다.

오류를 숨기고 기본값으로 계산을 성공시키는 편이 화면은 매끄러울 수 있다. 하지만 사용자가 입력한 조건과 다른 계산을 보여 줄 위험이 있다. 나는 이 단계에서는 계산의 가능 여부를 분명히 하는 편이 상담에서 같은 숫자를 다시 이해하는 데 도움이 된다고 판단했다.

범위의 두 끝을 어디까지 해석할 수 있는가

하한과 상한을 보여 준다고 그 사이에 실제 견적이 반드시 들어온다는 통계적 보장이 생기지는 않는다. 이번 범위는 선언한 두 계수를 같은 면적에 곱한 값이다. 신뢰구간과 시장 조사 결과로 부르지 않고 결과 단위도 합성이라고 표시했다. 화면의 익숙한 범위 기호가 실제로는 더 강한 약속처럼 읽힐 수 있기 때문이다.

면적과 규칙이 바뀌면 범위뿐 아니라 규칙 버전과 상담 맥락도 함께 다시 만들어야 한다. handoff는 받은 결과를 재계산해 비교하므로 면적은 그대로 두고 상한만 바꾼 데이터가 전달되면 실패한다. 이것은 서버 보안 서명이 아니라 한 예제 안에서 불일치가 섞이는 것을 막는 검사다.

실제 서비스라면 사용자 입력과 산출 근거를 어느 기간 보관할지, 담당자가 범위를 조정할 때 무엇을 설명할지도 정해야 한다. 이 모듈에 그 운영 정책을 감추어 넣지 않았다. 숫자가 상담을 여는 도구가 되려면 어떤 근거로 이야기하고 있는지를 양쪽이 다시 확인할 수 있어야 한다.

범위를 본 다음의 행동까지 이어 본다

공유 화면은 계산 결과를 상담 메모로 이어 넣되 기존 편집 문장이 있으면 보존 충돌을 반환한다. 숫자를 보여 준 뒤 다시 처음부터 설명하게 만들지 않으면서 사용자의 문장을 덮지 않는 흐름이다. 실제 접수와 연락은 수행하지 않는다.

코어 테스트 17개와 두 언어의 실제 인라인 이벤트 대역 검사를 마쳤다. 물리적인 모바일 화면이나 시장 견적의 적합성을 검수한 것은 아니다. 나는 정확해 보이는 숫자 하나보다 그 숫자의 한계와 다음 확인 절차가 함께 읽히는 상담 도구를 만들고 싶었다.

상담 화면에서 범위가 달라졌을 때는 이전 값이 틀렸다고만 말하기보다 추가 확인으로 어떤 조건이 바뀌었는지 보여 주어야 한다. 그래야 처음 도구가 했던 좁은 약속과 실제 견적의 역할이 이어진다.