요구사항을 글로 되묻는 방식은 무엇이 문제였나?
HTML 프로토타입 한 장을 요구사항 문서보다 먼저 보내는 절차를 만들었지만, 이 방식이 고객 회신을 늘리는지는 아직 재지 못했습니다. 이 글은 그 절차를 왜, 어떤 규칙으로 만들었는지와 무엇을 아직 모르는지를 함께 남기는 기록입니다.
작은 개발 스튜디오에 들어오는 의뢰는 대개 한 단락짜리 글입니다. 외주 플랫폼 요청서, 홈페이지 문의, 채팅 첫 메시지가 그렇습니다. 지금까지는 이 단락을 읽고 “이렇게 이해했는데 맞습니까”를 다시 글로 정리해 되물었습니다. 요구사항을 문서로 설명하고, 고객이 그 문서를 읽고 판단하기를 기다리는 방식입니다.
이 방식의 약점은 고객이 답하기 어렵다는 데 있습니다. 동물병원 원장님이나 학원 상담 실장에게 “예약 알림 흐름은 3단계로 구성합니다”라는 문장은 판단할 거리가 아닙니다. 맞는지 틀린지를 말하려면 자기 업무가 그 문장대로 바뀐 모습을 머릿속에서 그려야 합니다. 그 일을 고객에게 떠넘기는 셈입니다.
계기는 2026년 10월 3일에 정리한 링크드인 글 분석이었습니다. 한 개발자(Kurt Lee)가 “html파일 하나여도” 동작하는 데모를 바로 보여 줄 수 있게 된 변화를 압도적인 개선으로 꼽았습니다. 이 문장을 읽고, 고객에게 문서 대신 클릭해 볼 수 있는 화면 한 장을 먼저 보내는 절차를 만들기로 했습니다.
여기서 먼저 밝혀 둘 점이 있습니다. 문서로 되묻던 시절의 회신율, 한 건에 들던 시간 같은 출발점 숫자는 저희 기록에 없습니다. 그래서 이 글의 “전” 수치는 잰 값이 아니라 새로 정한 기준값이고, “후” 수치는 기준 예시 한 장의 검사 결과뿐입니다. 고객 반응을 잰 숫자는 아직 없습니다.
처음 잰 숫자: 잰 값이 아니라 정한 값부터
측정할 출발점이 없었으므로, 먼저 “한 장의 데모가 지켜야 할 숫자”를 정했습니다. 이 숫자들은 나중에 재측정할 때 비교 기준이 됩니다.
- 작업 시간: 1건에 30~60분을 목표로 둡니다. 이보다 길어지면 범위를 다시 자릅니다.
- 파일 크기: 단일 HTML 파일 하나, 목표 50KB 이하입니다.
- 사용자 동작: 화면 1장에서 3번 이하로 끝납니다. 예를 들어 목록 보기, 하나 누르기, 결과 보기입니다.
- 예시 데이터: 고객 업종에 맞춘 가상 예시 6~10행이고, 이름은 김OO 식으로 가립니다.
- 문제 카드: 고객 원문 아래에 4줄을 채웁니다(누가, 지금 하는 일, 막히는 지점, 데모에서 보일 변화).
- 검사 화면 폭: 데스크톱 1280px, 모바일 390px 두 가지로 렌더해 봅니다.
기준 예시도 하나 만들었습니다. 가상 동물병원의 노쇼(예약 부도) 알림 데모입니다. 크기는 3.6KB이고 자체 검사기를 통과했습니다. 상한 50KB와 비교하면 여유가 큽니다. 이 예시가 이후 모든 데모의 형식 기준입니다.
측정 방법도 정했습니다. 크기와 외부 의존성은 검사 스크립트가 파일을 읽어 판정하고, 렌더 결과는 브라우저 자동화 도구인 Playwright로 데스크톱과 모바일 두 폭에서 확인합니다. 고객 반응은 데모를 보낼 때마다 결과를 미리 예측해 적어 두고, 실제 결과가 오면 예측과 비교합니다.
세운 가설: 글보다 화면이 고객의 반박을 빨리 끌어낸다
첫 가설은 이렇습니다. 고객은 문서를 읽으면 “네, 그런 것 같습니다” 정도로 답하지만, 화면을 누르면 “아, 이런 거구나” 또는 “아니, 그게 아니라”를 말한다. 저희가 원하는 답은 뒤쪽입니다. 견적 전에 고객의 반박을 듣는 편이 견적 뒤에 듣는 편보다 훨씬 쌉니다.
그래서 데모의 목적을 제품 만들기가 아니라 고객의 말 끌어내기로 못박았습니다. 로그인, 설정, 관리자, 통계 화면은 넣지 않습니다. 고객이 묻지 않은 것을 넣으면 고객은 그 화면을 구경하느라 자기 문제를 말하지 않습니다. 뺀 범위는 버리지 않고 문제 카드 끝에 “뺀 것:” 한 줄로 남깁니다. 고객이 “그것도 되나요”라고 물으면 그때 붙입니다.
두 번째 가설은 형태입니다. URL로 배포한 페이지보다 메일에 첨부한 파일 한 장이 낫다고 봤습니다. 받는 사람이 오프라인에서 더블클릭해도 같은 화면이 떠야 하고, 링크를 열기 꺼리는 고객도 첨부 파일은 엽니다. 외주 플랫폼 일부는 외부 URL 노출 자체를 막기도 합니다.
세 번째 가설은 검증 방법이었습니다. 처음에는 데모를 만들고 스크린샷 두 장(데스크톱·모바일)을 찍으면 확인이 끝난다고 생각했습니다. 이 가설은 절차를 다듬는 과정에서 버렸습니다. 다음 절에 그 이유를 적습니다.
가설이 틀린 지점: 스크린샷이 있으면 확인했다고 볼 수 있나?
스크린샷이 있다는 사실은 화면이 그려졌다는 증거일 뿐입니다. 버튼을 눌렀을 때 결과가 바뀌는지는 알려 주지 않습니다. 버튼을 눌러도 아무 일도 일어나지 않는 HTML은 데모가 아니라 그림입니다. 고객이 “아니, 그게 아니라”를 말하려면 눌러 볼 수 있어야 합니다.
그래서 확인 단계를 둘로 나눴습니다. 첫째, 찍은 스크린샷 두 장을 실제로 열어 눈으로 봅니다. 파일이 있다는 이유만으로 통과시키지 않습니다. 둘째, 범위를 자를 때 정한 동작 3번을 브라우저 자동화로 실제로 누르고, 누를 때마다 화면이 바뀌는지 봅니다. 바뀌지 않으면 작성 단계로 돌아갑니다.
“검사기를 통과하면 끝”이라는 생각도 같은 이유로 버렸습니다. 검사기는 외부 파일 호출, 금액 표기, 가로 넘침 같은 형식을 봅니다. 화면이 고객 업무를 제대로 옮겼는지는 보지 못합니다. 완료 판정 4항목 가운데 하나를 “동작 3번을 눌러 화면이 바뀌는 것을 확인했고, 그 판정 1줄을 문제 카드에 적었다”로 둔 이유입니다.
브라우저 자체를 못 띄우는 상황도 있습니다. Playwright가 설치돼 있지 않거나 실행에 실패하면 정적 검사만 통과시키고, 문제 카드에 “브라우저 확인 못 함”을 적습니다. 렌더 확인 없이 완성이라고 보고하지 않습니다. 처음 가설대로였다면 이 경우도 스크린샷 없이 그냥 통과했을 겁니다.
진짜 원인: 왜 문서는 고객의 “아니, 그게 아니라”를 못 끌어내나?
여기부터는 측정이 아니라 판단입니다. 저희가 보기에 문서가 고객의 반박을 끌어내지 못하는 원인은 두 가지입니다.
첫째, 문서는 저희의 말로 쓰입니다. “AI 자동화 솔루션”, “알림 워크플로” 같은 말은 고객의 하루에 없는 말입니다. 고객은 자기가 매일 하는 동작, 예를 들어 “전날 저녁에 예약 환자 보호자에게 전화를 돌린다” 같은 단위로 생각합니다. 그래서 데모 카피는 고객 업종의 말(원장님, 보호자, 원무과)로 쓰고, 화면 제목에 “AI”나 “자동화 솔루션”을 넣지 않기로 했습니다.
둘째, 문서는 범위가 넓습니다. 문서 한 편에는 로그인부터 통계까지 다 들어가기 쉽고, 고객은 어디를 짚어야 할지 모릅니다. 데모를 고객 쪽 사람이 이미 하는 일 하나로 좁히면, 고객이 짚을 곳도 하나로 좁아집니다. 문제 카드의 “지금 하는 일” 칸을 동사 하나로 쓰게 한 이유입니다.
원문에 그 동작이 없을 때도 있습니다. 문제 단락이 너무 짧으면 지어내지 않습니다. 업종 공통 동작 1개로 데모를 만들고 문제 카드에 “가정:”으로 표시합니다. 그 가정 자체가 고객에게 되묻는 질문이 됩니다. 문서로 되물을 때는 질문이 추상적이었다면, 이 경우에는 “이 화면이 원장님 하루와 맞습니까”라는 구체적인 질문이 나옵니다.
조치: 데모 한 장을 만드는 6단계
이 판단을 AI 코딩 에이전트가 따라 할 수 있는 작업 절차(스킬) 한 편으로 고정했습니다. 입력은 고객 문제 한 단락과 고객 식별용 영문 이름이고, 출력은 같은 폴더의 파일 4개입니다.
| 구분 | 값 |
|---|---|
| 입력 | 고객 문제 한 단락(요청서·문의·채팅 원문) + 영문 소문자·하이픈 식별자 |
| 출력 | demo.html 한 장 + demo-desktop.png · demo-mobile.png · brief.md(문제 카드) |
| 검사 | demo-check.py 종료 코드 0 |
| 기준 예시 | 가상 동물병원 노쇼 알림, 3.6KB, 검사 통과 |
1단계는 문제 카드입니다. 고객 원문을 그대로 붙이고 4줄을 채웁니다. “막히는 지점” 칸에는 고객이 직접 쓴 표현을 그대로 인용합니다. 원문에 없는 내용은 “원문에 없음”으로 적습니다.
누가: 고객 쪽에서 실제로 손을 쓰는 사람, 대표·원무과·상담 실장 등 지금 하는 일: 그 사람이 매일/매주 하는 동작 1개, 동사로 막히는 지점: 원문에서 고객이 직접 쓴 표현 그대로 인용 데모에서 보일 변화: 같은 동작이 바뀐 뒤 화면에 나타나는 것 1개
이 4줄 양식은 고객 원문을 해석하기 전에 원문에서 뽑을 것을 먼저 정해 둔 틀입니다. 특히 “막히는 지점”을 저희 말로 고쳐 쓰지 않게 막는 장치가 중요합니다. 고객이 쓴 표현을 인용부호째 옮겨 두면, 데모 화면이 그 문장에 답하고 있는지를 나중에 한 줄씩 대조할 수 있습니다. 저희 말로 요약한 순간 그 대조가 불가능해집니다.
2단계는 범위 자르기입니다. 화면 1장, 사용자 동작 3번 이하입니다. 고객 문제가 화면이 아닌 경우, 예를 들어 배치 처리나 API 연동이나 문서 작성이면 “전 → 후” 두 칸 비교 화면으로 만듭니다. 왼쪽에 지금 결과물, 오른쪽에 바뀐 결과물, 가운데에 버튼 1개입니다.
3단계는 작성입니다. 외부 의존성 0개가 원칙입니다. CDN, 웹폰트, 외부 이미지, 외부 스크립트와 스타일시트, fetch 호출을 모두 금지하고 CSS와 JS는 파일 안에 넣습니다. 서체는 Pretendard가 설치돼 있으면 쓰고 없으면 시스템 고딕으로 떨어지게 둡니다. 화면 어딘가에 “예시 화면 · 실제 데이터 아님” 문구를 넣고, word-break: keep-all과 모바일 가로 넘침 없음을 지킵니다.
넣지 않는 것도 정했습니다. 가격·견적·할인, 미팅·통화·방문·시연 일정 제안, 납기·성과 약속, 저희 사이트 주소입니다. 데모는 질문을 끌어내는 도구이지 약속하는 문서가 아닙니다. 미팅 제안을 빼는 규칙은 2026년 10월 16일과 19일 두 차례 받은 지적에서 나왔습니다.
4단계는 기계 검사입니다. 검사기 demo-check.py가 외부 의존성, 금지 서체, 금액 표기, 미팅·통화·방문 약속 문구, “예시” 표기, 데스크톱과 모바일 렌더의 콘솔 에러, 외부 네트워크 요청, 가로 넘침을 봅니다. 하나라도 걸리면 종료 코드 1을 냅니다. 별도의 문체 검사기로 “AI가 만든 티” 매칭이 3개 미만인지도 봅니다. 금지 서체 규칙(손글씨풍 명조체 금지)은 2026년 10월 17일에 추가했습니다.
5단계는 앞 절에서 설명한 눈 확인입니다. 스크린샷 2장을 열어 보고, 동작 3번을 실제로 누릅니다. 6단계는 보낼 때의 사전 예측 기록입니다. 데모를 고객에게 보내는 일은 사람이 직접 하고, 절차는 초안 파일까지만 만듭니다.
실패 경로도 표로 정했습니다. 검사가 실패하면 지적된 줄을 고치고 다시 돌립니다. 같은 항목이 3회 연속 실패하면 멈추고 문제 카드에 사유를 적습니다. 데모가 50KB를 넘으면 데이터 행 수를 줄이고 SVG를 단순화하되, 기능을 늘려서 커진 경우라면 범위 자르기로 돌아갑니다. 고객이 엑셀이나 사진 같은 실제 자료를 보내면 화면 구성 참고로만 쓰고, 데모에는 가상 값을 넣습니다.
| 상황 | 할 일 |
|---|---|
| 문제 단락이 너무 짧아 “지금 하는 일”을 못 채움 | 업종 공통 동작 1개로 만들고 “가정:” 표시: 그 가정이 되묻는 질문 |
| 고객 문제가 화면이 아님 | “전 → 후” 두 칸 비교 화면, 가운데 버튼 1개 |
| 검사 실패 | 지적된 줄 수정 후 재실행, 같은 항목 3회 연속 실패면 중단·사유 기록 |
| 브라우저 실행 실패 | 정적 검사만 통과, “브라우저 확인 못 함” 명시, 완성 보고 금지 |
| 50KB 초과 | 데이터 행 수 축소·SVG 단순화, 기능이 늘어난 탓이면 범위 다시 자르기 |
| 고객이 실제 자료를 보냄 | 화면 구성 참고만, 데모에는 가상 값 |
역할 경계도 분명히 그었습니다. 제안서 슬라이드, 시연 영상, 실제 랜딩 페이지는 각각 다른 절차가 맡습니다. 이 절차는 견적을 내기 전, 고객 문제를 화면으로 되묻는 자리에만 씁니다. 외주 플랫폼 요청서에 답하기 전, 먼저 연락하는 메일의 첨부물, 제안 단계의 첫 회신이 그 자리입니다.
내부 확인 방식도 하나 정했습니다. 데모를 결정권자에게 보여 줄 때는 파일을 그 사람 PC의 기본 브라우저로 직접 엽니다. 로컬 파일을 여는 일이라 외부로 나가는 것이 없습니다. 고객이 받아 볼 화면과 같은 조건, 곧 인터넷 연결과 무관한 파일 한 장 상태로 보게 하려는 목적입니다.
재측정 결과: 기준 예시 3.6KB 통과, 고객 반응은 아직 0건
지금까지 잰 결과는 형식 쪽뿐입니다. 기준 예시 한 장이 3.6KB로 상한 50KB 안에 들어왔고, 검사기를 통과했습니다. 외부 의존성 없이 파일 한 장으로 동작하는 데모가 실제로 만들어진다는 사실까지는 확인했습니다.
“예시 화면 · 실제 데이터 아님” 문구도 검사 대상입니다. 검사기는 화면에서 “예시”라는 문자열을 찾고, 없으면 통과시키지 않습니다. 받는 고객이 가상 데이터를 실제 운영 화면으로 오해하지 않게 하려는 규칙이고, 기준 예시도 이 항목을 통과했습니다.
고객 반응을 잰 숫자는 없습니다. 이 절차가 고객 회신을 늘리는지, 회신이 “아니, 그게 아니라” 같은 수정 요청 형태로 오는지는 데모를 실제로 보내고 결과를 모아야 압니다. 그래서 보낼 때마다 예측을 먼저 적도록 했습니다. 기록 형식의 예는 “48시간 내 회신 30%, 회신 중 수정 요청 형태 70%”입니다. 이 30%와 70%는 형식을 보여 주는 예시이지 결과가 아닙니다.
결과가 오면 예측과 실제의 차이를 적습니다. 회신이 왔는지, 거절인지, 무응답인지와 함께 “예측과 달랐던 점”을 한 줄로 남깁니다. 예측이 맞은 부분은 누구나 짐작하는 내용이라 배울 것이 적고, 어긋난 부분이 이 절차가 쌓을 지식입니다.
완료 판정은 4개 조건이 모두 참일 때입니다. 폴더에 파일 4개가 있고, 검사기 종료 코드가 0이고 문체 검사 매칭이 3개 미만이며, 동작 3번을 눌러 화면이 바뀌는 것을 확인한 판정 1줄이 있고, 보냈다면 사전 예측 1행이 있어야 합니다. 형식은 이 기준으로 반복해서 잴 수 있습니다. 효과는 아직 재지 못했습니다.
남는 한계: 출발점이 없는 개선은 개선이라 부를 수 있나?
가장 큰 한계는 비교 대상입니다. 문서로 되묻던 시절의 회신율과 한 건당 시간을 재 두지 않았습니다. 앞으로 데모를 보낸 건의 회신율을 모아도, 그 숫자를 비교할 “전” 값이 없습니다. 지금 할 수 있는 일은 데모를 보낸 건과 보내지 않은 건을 같은 기간에 나란히 기록하는 정도입니다.
두 번째는 범위입니다. 이 절차는 화면이 있는 문제에 맞춰져 있습니다. 배치 처리나 API 연동처럼 화면이 없는 문제는 “전 → 후” 두 칸 비교로 바꿔 그리지만, 그 비교 화면이 고객의 반박을 같은 정도로 끌어내는지는 모릅니다.
세 번째는 개인정보와 공유 형태입니다. 문제 카드에는 고객 원문이 그대로 들어가므로 이 폴더는 저장소에 커밋하지 않습니다. 데모를 URL로 배포하지도 않습니다. 파일 한 장이 이 절차의 형태이고, URL이 필요해지면 별도의 랜딩 페이지 작업으로 넘깁니다. 대신 고객이 링크로 쉽게 공유하는 장점은 포기했습니다.
네 번째는 데이터 규칙의 비용입니다. 실제 고객·환자·잠재 고객의 이메일과 전화번호는 넣지 않고, 고객이 보낸 엑셀 값도 가상 값으로 바꿉니다. 안전한 대신, 고객이 자기 실제 데이터로 화면을 볼 때 생기는 실감은 포기합니다. 이 차이가 반응에 얼마나 영향을 주는지도 모릅니다.
마지막으로 30~60분이라는 작업 시간 목표도 아직 목표일 뿐입니다. 실제 데모 한 장에 몇 분이 드는지는 건별로 재서 쌓아야 합니다. 목표를 넘기는 건이 반복되면 범위 자르기 규칙이 느슨하다는 신호로 봅니다.
HTML 프로토타입을 고객 응대에 쓰려면 어디서 시작하나?
저희 경험에서 가장 먼저 할 일은 데모가 아니라 문제 카드 4줄입니다. 누가, 지금 무엇을 하는지, 고객이 직접 쓴 막힘 표현, 바뀐 뒤 화면에 보일 변화 하나. 이 4줄이 안 채워지면 데모를 만들어도 고객의 업무가 아니라 저희 상상을 그리고 맙니다.
그다음은 빼는 일입니다. 로그인, 설정, 관리자, 통계, 가격, 일정 약속을 빼고 동작 3번만 남깁니다. 그리고 보내기 전에 결과를 예측해 적습니다. 효과를 재는 장치가 없으면 이 글처럼 “만들었지만 모른다”에서 멈추기 쉽습니다.
AI 에이전트가 만든 결과물을 사람이 다 보지 않고 기계 규칙으로 검증하는 방식은 AI 에이전트 작업 검증 자동화 글에 더 자세히 적었습니다. 요청서 한 단락을 들고 화면부터 확인해 보고 싶다면 상담으로 남겨 주세요.