알고리즘이나 기능은 누구나 주장할 수 있습니다
시나리오 1: 프리랜서 개발자가 클라이언트에게 기능을 전달했지만, 클라이언트가 지적 저작자라고 주장하며 지불을 거부. 시나리오 2: 독립 개발자가 독창적인 알고리즘을 만들었지만, 몇 달 후 경쟁사가 동일한 것을 출시하며 저작권을 다툼. 두 경우 모두 Git 커밋이나 이메일로는 충분하지 않습니다 — 날짜를 소급하거나 이의를 제기할 수 있습니다. 신뢰할 수 있는 제3자 기관의 타임스탬프 증명만이 기술적으로 반박 불가능합니다.
Git 저장소 외부에 있는 코드의 인증된 지문
코드나 기술 산출물의 안정 버전을 마무리하고 있습니다.
전달 또는 공개 전에 프로젝트 ZIP 파일의 타임스탬프 증명을 생성합니다.
Git과 독립적으로 이 정확한 버전이 이 날짜에 존재했음을 증명할 수 있습니다.
코드는 장치를 떠나지 않습니다. SHA-256 지문만 전송됩니다.
지원 형식: ZIP, TAR.GZ, JS, PY, SQL, 컴파일된 바이너리 — 모든 형식
3단계, 30초
- 파일 드롭: 프로젝트 ZIP, 소스 파일, 컴파일된 바이너리…
- 자동 인증: 브라우저에서 SHA-256 해시 계산 + FreeTSA를 통한 RFC 3161 타임스탬프
- Proof Pack 다운로드: 읽기 쉬운 PDF 인증서 + RFC 3161 호환 도구로 검증 가능한 .tsr 토큰
왜 단순히 Git만으로는 안 되나요?
Git은 버전 관리 도구이지 외부 증명 도구가 아닙니다.
| 기준 | Git 커밋 | GitHub 타임스탬프 | ProofStamper |
|---|---|---|---|
| 날짜 조작 가능 | 예 (git commit --date) | 아니오 | 아니오 (외부 TSA) |
| 플랫폼 의존적 | 아니오 | 예 (GitHub) | 아니오 |
| 코드 기밀성 | 로컬 | 호스팅됨 | 100% 로컬 |
| 독립적으로 검증 가능 | 아니오 | 아니오 | 예 (RFC 3161) |
| 외부 기술 증명 | 아니오 | 아니오 | 예 ✓ |
개발의 각 핵심 단계를 보호하세요
- 클라이언트 납품 — 기술 산출물의 정확한 전달 날짜를 증명.
- 소프트웨어 특허 출원 — 공개 전에 발명의 선행성을 문서화.
- 독점 알고리즘 — 공유 또는 협업 전에 알고리즘 버전을 고정.
- 오픈소스 공개 전 버전 — 오픈 라이선스로 공개하기 전에 코드에 타임스탬프.
- 규정 준수 감사 — 특정 날짜에 시스템의 정확한 상태를 증명.
- 비회귀 증명 — 특정 날짜에 테스트를 통과한 버전을 인증.
자주 묻는 질문
- Git 커밋만으로 증명이 충분하지 않나요?
- Git 커밋은 git commit --date로 날짜를 소급할 수 있습니다. 내부 버전 관리 도구이며 독립적인 증명이 아닙니다. ProofStamper는 날짜를 논쟁의 여지 없이 인증하는 제3자 타임스탬프 기관(RFC 3161)을 사용합니다.
- 소스 코드가 서버로 전송되나요?
- 아니오, 절대로. 모든 처리는 브라우저에서 로컬로 수행됩니다. 코드를 재구성할 수 없는 고유 식별자인 암호화 지문(SHA-256)만 타임스탬프 획득을 위해 전송됩니다.
- 전체 프로젝트를 하나의 ZIP 파일로 타임스탬프할 수 있나요?
- 예. 프로젝트를 ZIP 또는 TAR.GZ로 압축하고 드롭하세요. SHA-256 지문은 전체 내용을 커버합니다. 단일 바이트가 변경되면 지문이 달라집니다.
- 이 증명은 상업적 분쟁에서 사용할 수 있나요?
- 예. RFC 3161 인증서는 인정된 선행성의 기술적 증명입니다. 공증인 보고서와 결합하면 파일의 존재 날짜를 확립하는 강력한 증거가 됩니다.