Lead Form에서 “회사 규모”를 추가하거나 “문의 내용”의 표현을 바꾸는 일은 화면 문구 수정처럼 보입니다. 하지만 제출자 연락처가 Google Sheets나 Notion으로 전달되고 있다면 그 항목은 downstream 데이터 구조의 일부입니다. 폼만 먼저 바꾸면 새 값이 어느 열에 들어오는지, 기존 수식과 담당자가 같은 뜻으로 읽는지 뒤늦게 확인하게 됩니다.
폼 변경은 디자인 수정이 아니라 수집 화면과 destination 사이의 data contract 변경으로 다루는 편이 안전합니다. 변경 이유와 적용 시각, mapping, 테스트와 책임자를 하나의 version으로 묶습니다.
먼저 현재 schema를 복사해 기준선을 만듭니다
변경 전에 현재 form field와 destination의 열 또는 속성을 한 표에 놓습니다. 각 행에는 field key, 화면 label, 필수 여부, 값의 형식, destination 이름, 값을 읽는 업무와 owner를 적습니다. 화면에 보이는 질문과 downstream에서 쓰는 이름이 다르다면 둘을 별도 칸에 둡니다.
여기에 schema version과 effectiveAt을 붙입니다. 버전은 거창한 번호일 필요가 없습니다. “2026-08-31-v2”처럼 어떤 제출부터 새 구조로 읽어야 하는지 구분할 수 있으면 됩니다. 변경 요청서에는 추가·변경·제거 중 무엇을 하려는지, 왜 필요한지, 영향을 받는 보고서나 수식이 무엇인지 적습니다.
고정 열과 form field 열을 구분합니다
FeatPaper가 Google Sheets로 보내는 구조는 고정 열 27개와 정보 입력폼 항목 수만큼의 열로 구성됩니다. 열람이 이어지면 관심도, 열람 횟수, 체류시간, 완료율, 최근 열람 일시 같은 누적 항목이 같은 행에서 갱신될 수 있습니다. 반면 form field는 제출 시 받은 값입니다.
새 열이 필요하면 헤더의 오른쪽 끝에 추가되고, 사용자가 시트에 직접 만든 열은 건드리지 않는다고 공식 가이드가 설명합니다. 이 특성을 알아도 downstream이 자동으로 안전해지는 것은 아닙니다. 열 순서로 가져오는 수식, 고정 범위를 읽는 import, 이름이 같은 별도 열이 있는지 확인해야 합니다.
필드 이름 변경이나 제거가 Notion과 Google Sheets에서 어떤 기존 열·속성에 영향을 주는지는 화면과 destination에서 직접 검증합니다. 공식 source가 확인하지 않은 rename, delete 또는 migration 동작을 일반 규칙으로 만들지 않습니다.
destination은 링크가 아니라 문서 단위로 봅니다
Notion과 Google Sheets의 연락처 전송 대상은 문서마다 지정합니다. 같은 문서의 여러 링크에 서로 다른 destination을 붙이는 구조가 아닙니다. 따라서 한 링크의 form field를 바꾼다고 생각했더라도, 그 문서에서 제출되는 contact 흐름 전체와 연결 대상을 함께 확인해야 합니다.
전송되는 대상도 정보 입력폼을 제출한 contact입니다. 개인별 추적 링크 수신자, 익명 열람인, 폼을 제출하지 않은 열람인까지 같은 destination에 자동으로 전달된다고 가정하지 않습니다. form schema의 영향 범위를 잡을 때 이 경계를 명시해야 불필요한 데이터 수집 기대가 생기지 않습니다.
mapping table에서 소비자까지 연결합니다
새 schema의 각 field에는 destination 열·속성만 적지 않고 누가 무엇에 쓰는지도 붙입니다. 예를 들어 필수 이메일은 후속 연락 식별에, 선택 질문은 상담 준비에 쓸 수 있습니다. 그러나 값을 받는 목적이 있다는 사실과 법적 적합성이 보장된다는 말은 다릅니다. 개인정보 수집과 보관 정책은 조직의 별도 검토 범위로 남깁니다.
변경 영향은 다음 세 방향으로 확인합니다.
- 입력: 열람인이 보는 label, 필수 여부와 값 형식이 의도대로인가
- 전달: 제출한 값이 지정한 Notion 데이터베이스 또는 Google Sheets에 도착하는가
- 소비: 수식, 필터, dashboard, 알림과 담당자의 작업이 새 열·속성을 올바르게 읽는가
generic CRM sync나 Salesforce·HubSpot native integration까지 확대하지 않습니다. 이 글의 contract는 공식 source가 확인하는 Notion과 Google Sheets의 제출자 contact 전달 범위에 한정합니다.
cutover는 실제 제출 한 건으로 확인합니다
새 version을 저장하기 전에 변경 시각과 되돌릴 조건을 정합니다. 가능하면 업무가 적은 시간에 적용하고, 테스트용 식별값을 넣은 제출 한 건을 보냅니다. destination에서 새 행과 field 값을 확인한 뒤, 관련 수식이나 view가 예상대로 읽는지 downstream owner가 확인합니다.
Google Sheets에서는 제출 1건이 한 행을 만들고, 열람이 이어지면 같은 행의 누적 항목이 갱신될 수 있습니다. 첫 도착만 보고 끝내지 말고 필요한 누적 필드도 후속 시점에 확인합니다. 반대로 과거 행이 새 schema로 자동 backfill되거나 기존 값이 무손실로 변환된다고 기대하지 않습니다. 과거 자료를 옮겨야 한다면 별도 migration 계획과 검증이 필요합니다.
완료 기록은 화면 저장과 downstream 승인을 나눕니다
change log에는 form 저장 시각, schema version, 실제 destination, test submission 식별값, 도착 결과, consumer 검증, 미해결 예외와 승인자를 남깁니다. 문제가 생기면 어느 버전부터 어떤 mapping이 적용됐는지 찾을 수 있어야 합니다.
폼 항목을 바꾸는 가장 안전한 순서는 질문을 먼저 고치는 것이 아닙니다. 현재 schema를 고정하고, mapping과 영향을 합의하고, form과 destination을 함께 바꾼 뒤 새 제출로 확인하는 것입니다. 이 순서를 지키면 폼은 고립된 UI가 아니라 변경 책임이 분명한 데이터 계약으로 운영됩니다.
