본문 바로가기

업무 자동화 · 도구 검증 · 서비스 운영

반복 업무를 줄이는 방법,
직접 시험하고 기록합니다.

예약 명단 정리부터 알림 자동화, 앱 운영까지.
원본 예제와 확인표, 실험 결과를 함께 나눕니다.

첫 번째 실험 · 예약 명단

이름이 같으면
같은 예약일까요?

B102 · 방문자B9월 10일
B103 · 방문자B9월 11일

다른 예약입니다. 둘 다 남겨야 합니다.

가상 명단 12행으로 확인한 결과 →
AI로 첫 앱 만들기

AI로 첫 앱 만들기: 입력 폼에서 필수값·형식·서버 확인을 나누는 방법

by 코딩히어로 2026. 9. 23.
300x250
반응형

첫 앱에 신청 폼을 넣는다면 “제출 버튼을 누르면 저장한다”만으로는 화면 규칙을 정하기 어렵습니다. 이름이 빈 경우, 이메일 형식을 확인할 경우, 저장 요청 뒤 서버의 결과를 기다리는 경우를 나눠야 합니다. 이 글은 가상의 행사 신청 폼을 설계하는 연습이며 실제 개인 정보를 수집하거나 서버에 연결한 결과는 아닙니다.

1. 필드마다 목적을 적습니다
예시 폼은 이름, 이메일, 희망 시간 세 칸입니다. 이름과 희망 시간은 필수, 이메일은 안내를 받을 때만 입력하는 선택 항목이라고 정해 봅니다. 어떤 항목이 꼭 필요한지부터 정하면 사용자가 입력 범위를 이해하기 쉽습니다. 라벨은 입력칸 위에 두고 “이메일(선택)”처럼 표시합니다. 예시 값만으로 설명을 대신하지 말고, 입력 목적도 짧게 알려 주세요.

2. 검사를 세 단계로 나눕니다
첫 단계는 필수값 확인입니다. 이름이 비었으면 이름 칸 아래에 “이름을 입력해 주세요”를 표시합니다. 두 번째는 형식 확인입니다. 선택 이메일을 입력했다면 이메일 형식을 검사합니다. 세 번째는 서버 확인입니다. 브라우저에서 통과한 값도 서버에서 다시 확인하고 저장 결과를 받아 완료 화면을 보여 줍니다. 화면에서 검사를 통과했다는 사실만으로 저장 완료를 표시하지 않습니다.

신청 폼의 입력, 화면 검사, 서버 확인, 결과 안내 네 단계를 보여 주는 도해



3. 다음 행동을 보여 줍니다
입력칸 색만 바꾸면 어느 내용을 수정할지 알기 어려울 수 있습니다. 안내에는 위치와 행동을 함께 적으세요. 제출 중에는 버튼을 잠시 비활성화하고 “신청 내용을 보내는 중”이라고 표시합니다. 응답이 오면 접수된 항목과 다음 단계를 보여 줍니다. 응답을 확인할 수 없다면 입력 내용을 화면에 보존하고 사용자가 상태를 다시 확인할 경로를 안내하는 방식도 설계할 수 있습니다.

4. AI에게 상태별 문구를 요청합니다
“행사 신청 폼을 설계해 주세요. 이름·희망 시간은 필수, 이메일은 선택입니다. 입력 전, 필수값 누락, 형식 확인, 제출 중, 저장 완료, 서버 응답 확인이 필요한 경우의 화면 문구를 각각 작성해 주세요. 메모에 없는 세부 정책은 질문으로 남겨 주세요.” 이렇게 요청하면 코드보다 먼저 화면 규칙을 검토할 수 있습니다. 그림은 입력→화면 검사→서버 확인→결과 안내를 보여 줍니다.

5. 작은 시험표를 만듭니다
빈 이름, 선택 이메일 미입력, 이메일 형식, 정상 제출, 서버 응답 지연을 한 번씩 확인하세요. 기대하는 안내와 실제 화면을 나란히 기록하면 수정할 지점을 찾기 쉽습니다. HTML의 required와 Constraint Validation API는 브라우저 검사를 돕습니다. 공식 참고: MDN ‘Using HTML form validation and the Constraint Validation API’ https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Constraint_validation (확인일 2026-09-23). 예시와 그림은 직접 구성했습니다.

바로 해볼 연습
종이에 세 칸짜리 폼을 그리고 이름을 비운 채 제출해 보세요. 어느 칸에 어떤 안내가 나타나는지 적습니다. 다음에는 이메일을 비우고 제출해 봅니다. 이메일이 선택 항목이라면 이 입력은 통과해야 합니다. 두 결과가 다르게 나오도록 먼저 설계하면 실제 코드를 만들 때도 확인 기준이 분명해집니다.

세 칸짜리 폼을 실제 규칙으로 바꾸기

가상 행사 신청에서 이름은 1~40자, 희망 시간은 제공한 선택지 가운데 하나, 이메일은 입력할 때만 형식을 확인한다고 정합니다. 이 숫자와 선택지는 연습용 제품 규칙입니다. 서버에서 저장을 허용할지 결정하는 규칙은 별도로 있어야 합니다. 먼저 “어떤 입력을 받는가”와 “어떤 안내를 보여 주는가”를 같은 표에 놓으면 AI가 만든 문구를 화면에 바로 대조할 수 있습니다.

필드연습용 규칙화면 안내서버에서 다시 볼 것
이름필수, 1~40자빈칸이면 이름 입력 안내빈칸·길이·저장 가능 여부
이메일선택, 입력 시 이메일 형식빈칸은 허용, 형식은 확인입력값의 형식과 저장 정책
희망 시간제공한 시간 중 선택미선택이면 선택 안내선택지가 아직 유효한지 확인

브라우저의 required와 type="email"은 기본 입력 검사를 돕지만 저장 성공을 알려 주지는 않습니다. 완료 화면은 서버의 성공 응답을 받은 뒤에만 보여 주세요. 응답을 확인하지 못한 경우에는 사용자가 적은 이름과 선택 시간을 보존하고 “접수 상태를 확인해 주세요”와 확인 경로를 표시합니다.

복사해서 실행하는 화면 전용 예시

<form id="apply">
  <label>이름 <input name="name" required maxlength="40"></label>
  <label>이메일(선택) <input name="email" type="email"></label>
  <label>희망 시간
    <select name="slot" required>
      <option value="">시간을 선택하세요</option>
      <option value="morning">오전</option>
      <option value="afternoon">오후</option>
    </select>
  </label>
  <button type="submit">신청하기</button>
</form>

이 HTML은 브라우저에서 필수값과 이메일 형식을 연습하는 화면 예시입니다. 전송 주소나 저장 코드를 넣지 않았으므로 실제 신청은 접수되지 않습니다. 네트워크로 보내는 기능을 만들 때는 서버가 같은 규칙을 검증하고, 저장 결과와 요청 식별자를 응답으로 돌려주는 흐름을 별도로 설계해야 합니다.

제출 상태별 기대값

재현 입력기대 화면확인 자료
이름 빈칸이름 위치에 입력 안내서버 요청 전 화면
이메일 빈칸형식 안내 없이 다음 검사선택 항목 규칙
이메일 형식 확인 필요이메일 위치에 수정 안내해당 입력값
제출 중중복 제출을 줄이는 버튼 상태요청 대기 화면
저장 성공 응답접수 결과와 다음 단계서버 응답의 식별자
응답 미확인입력값 보존, 상태 확인 경로접수 목록 또는 조회 화면

마지막 줄은 저장 실패를 단정하는 화면이 아닙니다. 응답을 받지 못했어도 서버가 처리했을 수 있으므로 재전송 전에 접수 목록이나 식별자로 상태를 확인합니다. 같은 버튼을 두 번 누른 상황도 별도로 시험하세요. 기대값은 제품이 정한 중복 처리 방식에 따라 기록해야 합니다.

AI 요청문과 검토 질문

가상 행사 신청 폼의 입력 항목은 이름(필수, 1~40자), 이메일(선택, 입력 시 형식 확인), 희망 시간(필수 선택)입니다. 입력 전·각 필드 안내·제출 중·서버 성공·응답 미확인 상태를 표로 작성해 주세요. 각 행에 화면 문구, 버튼 상태, 사용자 데이터 보존 여부, 확인할 서버 결과를 넣고 미정 정책은 질문으로 남겨 주세요.

Q. required만 붙이면 신청이 저장되나요? 아닙니다. 브라우저 입력 검사와 서버 저장·응답 확인은 별도 단계입니다.

Q. 이메일이 선택인데 비어 있어도 되나요? 이 예시 규칙에서는 빈칸을 허용하고, 입력한 값에만 형식을 확인합니다.

Q. 응답이 늦으면 완료 화면을 보여도 되나요? 저장 결과를 확인한 뒤 완료로 전환합니다. 그 전에는 입력값과 확인 경로를 남깁니다.

공식 참고: MDN의 HTML 폼 검증 안내(2026-09-23 확인). 이어서 볼 글: 저장 버튼을 두 번 눌렀을 때의 기록 규칙, 사진 첨부의 선택·미리보기·업로드 상태.

300x250
반응형

댓글