예약 변경 안내가 반복되는 문제를 줄이려는 가상 아이디어를 IPMAKER에 입력했습니다. 무엇을 넣고 어떤 초안을 받았는지, 실제 화면과 함께 입력부터 수정까지 따라갑니다.
예약 시간을 한 번 바꿨는데 똑같은 안내 문자가 두 번 온다면 어떨까요? 예약이 또 바뀐 건지 헷갈릴 수 있습니다.
이번 아이디어는 여기서 출발합니다. 알림을 보내는 서버가 같은 예약 변경 건을 여러 번 처리하지 않도록, 처리 기록을 남기고 확인하자는 것입니다. 이 설명문을 IPMAKER에 넣어 어떤 명세서 초안이 나왔고, 무엇을 고쳤는지 따라가 보겠습니다.
2026년 9월 20일 가상 자료로 진행한 문서 작성 시연입니다. 예약 시스템을 실제로 구현하거나 성능을 시험한 것은 아니며, 특허 등록 사례도 아닙니다.
출발점: 같은 예약 변경인지부터 구별하기
같은 예약이라도 나중에 다시 변경했다면 새 안내가 필요합니다. 그래서 예약번호만 비교하지 않고, 예약번호·몇 번째 변경인지·받을 사람·문자나 이메일 같은 알림 종류를 함께 구별하기로 했습니다.
이 네 정보를 묶은 표식을 입력 자료에서는 ‘처리 키’라고 불렀습니다. 쉽게 말해, 서버가 “아까 처리하던 바로 그 건인가?”를 알아보는 기준입니다.
IPMAKER에는 무엇을 입력했나요?
워크스테이션의 ‘내용 직접 입력’에 아이디어 설명문을 넣었습니다. 실제 자료에서 문제를 설명한 부분은 이렇게 시작합니다.
예약 내용이 변경될 때 서버가 고객에게 알림을 보낸다. 동일한 예약 변경 이벤트가 중복 수신되거나 두 처리 작업이 동시에 실행되면 같은 알림이 반복 처리될 수 있다.
문제 설명에 이어, 알림을 처리할 규칙도 함께 적었습니다.
같은 표식의 새 기록은 하나만 만들 수 있고, 기록을 만드는 데 성공한 작업만 최초 발송을 시작합니다.
이미 보내는 중이거나 전송 완료인 기록이 있으면, 중복 요청은 새 발송을 시작하지 않습니다.
실패가 확실할 때는 기록을 ‘다시 시도 가능’에서 ‘처리 중’으로 바꾸는 데 성공한 작업만 다시 보냅니다.
보냈는지 알 수 없을 때는 곧바로 다시 보내지 않고, 확인이 필요하다고 기록합니다.
입력한 뒤에는 어떤 순서로 진행했나요?
내용 직접 입력: 문제와 처리 규칙을 적은 설명문을 넣었습니다.
AI 정리 내용 확인: AI가 나눈 문제·구성·특징을 읽고 원자료와 다른 표현을 수정했습니다.
발명 분석과 추가 질문: 분석 결과를 확인하고, 정보 보완 인터뷰에서 빠진 조건을 답했습니다.
명세서 초안 검토: 기술분야·배경기술·해결 수단 등을 포함한 8개 항목을 확인했습니다.
설명문을 넣은 뒤, 정리 내용과 추가 질문을 거쳐 명세서 초안을 검토했습니다.
1. 자료 정리: 설명한 범위보다 큰 “보장”은 줄이기
‘자료 확인’ 화면의 ‘아이디어의 핵심 특징’에는 다음 문장이 나왔습니다.
상태 기반의 조건부 갱신 메커니즘으로 동시 요청 시에도 단 하나의 전송만 진행되도록 보장하며, 실패 응답과 미확인 상태를 구분하여 불필요한 자동 재전송을 방지한다.
여기서 설명한 것은 서버가 같은 건의 발송 작업을 반복해서 시작하지 않도록 하는 규칙입니다. 외부 문자 서비스나 고객 휴대전화에서 실제로 몇 번 전달·표시되는지까지 확인한 것은 아닙니다.
두 범위를 혼동하지 않도록 다음 문장을 넣었습니다.
이는 서버 내부의 중복 처리 제어이며, 외부 알림의 정확히 한 번 전달을 보장하지 않는다.
2. 추가 질문: 60초가 무슨 시간인지 바로잡기
입력 자료에는 명확한 실패 뒤 60초 간격으로 최대 3회 다시 시도한다는 예시 설정도 적었습니다. 그런데 정보 보완 인터뷰에서는 “응답 시간 초과(예: 60초)”를 누가 판단하는지 물었습니다.
‘실패 후 다시 시도하기까지 기다리는 시간’과 ‘외부 서비스의 응답을 기다리는 제한 시간’은 다릅니다. 숫자만 같다고 같은 설정이 되는 것은 아닙니다. 그래서 이렇게 답했습니다.
원자료의 60초는 명확한 실패 뒤 재시도하는 간격이며, 응답 타임아웃 시간으로 정한 값이 아닙니다.
전송 완료 기록을 7일간 보관한다는 값도 설명용 가정이었습니다. 보냈는지 모르는 기록을 언제까지 남길지는 정하지 않았습니다. 이런 미정 사항은 AI 질문에 숫자가 나왔다는 이유만으로 확정하지 않았습니다.
3. 명세서 작성: 기술 설명과 검토 메모를 나누기
입력에는 ‘가상 설계’라는 안내와 ‘등록 가능성을 확인하지 않았다’는 메모도 적었습니다. 명세서의 ‘기술분야’ 초안에는 이 메모까지 긴 문장에 이어져 있었습니다.
기술분야에는 무엇을 다루는 기술인지가 보여야 합니다. 그래서 어떤 알림을 어떤 기록으로 제어하는 서버인지 남기고, 미정 조건은 ‘구체적인 실시 내용’의 별도 검토 메모로 구분했습니다.
직접 고친 기술분야 문장은 다음과 같습니다.
본 발명은 예약 변경 이벤트에 대한 알림 처리 기술에 관한 것이다. 구체적으로, 예약 식별자·변경 버전·수신자 식별자·알림 채널로 구성한 처리 키와 전송 이력의 상태를 이용하여 서버 내부의 최초 전송과 재시도를 제어하는 서버에 관한 것이다.
쉽게 말하면 “같은 예약 변경 건인지 구별하고, 처리 기록에 따라 발송을 시작하는 서버”입니다. 미정 조건은 추후 보완할 항목으로 남겼습니다.
내 아이디어로 시작한다면
처음부터 특허 문장을 만들기보다 겪는 불편, 바꾸려는 동작, 정한 조건과 미정인 부분을 자신의 말로 적어보세요. 초안을 받은 뒤에는 입력한 뜻이 바뀌거나, 정하지 않은 기능이 추가되지는 않았는지 먼저 확인하세요. 특허법 제42조도 발명을 쉽게 실시할 수 있도록 명확하고 상세히 설명할 것을 요구합니다. 이번 시연은 명세서 초안 검토까지이며, 필요한 구현 설명 보완과 도면·청구항의 최종 검토, 출원 준비는 별도로 남습니다.
같은 가상 아이디어를 청구항으로 나누어 읽는 방법은 독립항·종속항 작성 예시에서 이어집니다. 가지고 있는 문서에서 입력할 내용을 고르는 방법은 사업계획서로 초안 준비하기를 참고하세요.
본문의 서비스 화면은 2026년 9월 20일 실제 시연 캡처입니다. 흐름도는 진행 순서를 요약했습니다. 명세서 초안의 결과는 입력과 실행 시점에 따라 달라질 수 있습니다.