업무 입력과 도구 형식을 나눕니다
도구가 받은 JSON을 그대로 업무 원장에 넣기보다 필요한 정보가 무엇인지 정합니다. 코드 이름이 같아도 금액의 단위나 날짜의 의미가 다를 수 있습니다. 수집하지 않아도 되는 개인정보와 자유 입력을 후속 도구에 모두 복사하지 않습니다.
설계용 계약 예시
다음은 실제 서비스의 API 명세가 아닌 입력 정책을 논의하기 위한 가정 예시입니다. 고객 연락처는 승인된 별도 접수 경로에서 다루고 이 예시에는 넣지 않았습니다.
{
"contract_version": "lead-routing-v1",
"request_id": "demo-request-001",
"service_code": "analytics",
"allowed_service_codes": ["seo", "geo", "analytics"],
"source_kind": "website_form",
"received_at": "2026-10-20T09:00:00+09:00",
"validation_result": "pending"
}
거절과 보류
필수값 누락, 허용하지 않은 서비스 코드, 잘못된 시각과 너무 긴 입력을 구분합니다. 오류가 있는 요청을 무조건 폐기하면 복구가 어렵고 전부 통과시키면 후속 단계가 실패합니다. 원장에 필요한 최소 상태와 사유를 남기고 사용자에게 수정이 가능한 안내를 제공할지 정합니다.
검증 순서
- 정상 입력의 기대 결과를 정의합니다.
- 필수 누락·빈값·잘못된 자료형을 시험합니다.
- 허용 범위 밖 입력에서 후속 실행이 없는지 봅니다.
- 오류 상태와 재처리 경로를 확인합니다.
한 도구가 자동으로 문자열을 숫자로 바꾸는지 확인합니다. 변환에 실패한 값을 0으로 채우면 잘못된 견적이나 배정이 발생할 수 있습니다. 입력 계약은 공급자별 실제 지원에 맞춰 구현하고 예시 JSON 자체를 보안 검증 코드로 사용하지 않습니다.
완료 기준
입력이 잘못됐을 때 어느 단계에서 왜 멈췄는지 알 수 있어야 합니다. 명세와 코드, 오류 안내가 같은 허용 범위를 사용하고 연동 변경 시 계약 버전의 영향을 검토합니다. 정상 한 건 성공뿐 아니라 경계값에서도 잘못된 메일과 원장 항목이 만들어지지 않는 상태가 검수 완료입니다.
자주 묻는 질문
- 폼에서 검사하니 서버 검증은 없어도 되나요?
- 브라우저 입력 검사는 사용자 안내를 돕지만 외부 요청과 다른 연동 경로도 있을 수 있습니다. 실제 처리 경계에서 허용하는 입력을 확인하고 화면만 믿지 않도록 설계합니다.
- 필드가 하나 추가되면 전체 작업을 중단하나요?
- 알 수 없는 필드를 무시할지 거절할지 호환성 규칙을 정합니다. 필수 필드의 의미가 바뀐 경우와 단순 선택 필드 추가를 구분해 버전과 오류 처리를 설계합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.