Claude에서 만든 파일을 수정할 때 원본 남겨 두기
Claude에서 만든 파일을 내려받아 수정하려면 처음 받은 파일을 따로 남겨 두세요. 수정한 파일에 새 이름을 붙여도 대화에 보이는 결과나 이전에 저장한 파일이 함께 바뀌는 것은 아닙니다.
이 글에서는 Claude Artifacts의 대화에서 선택한 결과, 내려받은 원본, 수정할 사본을 구분합니다. 가상 HTML 안내문을 예로 들어 허용한 부분만 바뀌었는지 확인하고, 잘못 고쳤을 때 원본으로 돌아가는 방법을 설명합니다.
본문의 HTML 파일은 가상 예제입니다. Python으로 파일 바이트와 허용 변경 두 곳을 비교했습니다. 파일 차이 검사와 앱의 저장·화면 동작 확인은 별도입니다.
현재 내 결과의 유형부터 확인하기
2026-10-04에 읽은 Claude Artifacts 공식 도움말은 2026-09-16 이전 대화에서 만든 결과를 legacy artifact로 구분합니다. 최신 템플릿 기반 결과에는 Export를, legacy 결과에는 패널의 코드 보기·복사·다운로드 컨트롤을 안내합니다. 내 결과가 어느 유형인지 보지 않고 과거의 ‘버전 선택기’나 같은 다운로드 버튼이 반드시 있다고 가정하지 마세요.
같은 도움말은 이전 메시지를 편집하면 별도 대화 버전과 그 버전의 결과로 다른 방향을 탐색할 수 있다고 설명합니다. 대화 갈래가 달라질 수 있으므로 파일명 하나만으로 어느 결과를 보관했는지 알 수 없습니다. 이 글의 demo-v1은 설명용 이름이며 실제 서비스의 버전 번호나 UI 표시를 재현한 값이 아닙니다.
출력 유형이 다르면 파일 형식도 다를 수 있습니다. 이 예제는 독립 HTML 두 사본만 검사하며 ZIP·문서·슬라이드·서버가 필요한 앱을 같은 방식으로 실행할 수 있다고 보장하지 않습니다. 서비스에서 결과를 저장하는 단계와 저장한 코드를 로컬에서 실행하는 단계도 별도로 판단해야 합니다.
세 기록을 연결하는 보존 규칙
| 기록 | 남길 항목 | 섞으면 생기는 문제 |
|---|---|---|
| 대화 출력 | 대화·갈래·결과 이름, 선택한 버전 또는 확인 가능한 수정 시점 | 최신 화면을 봤지만 예전 결과를 저장할 수 있음 |
| 저장 원본 | 저장 시각, 파일명·확장자, 바이트 수, SHA-256 | 같은 이름으로 덮어쓰면 처음 받은 파일을 잃음 |
| 로컬 수정본 | 원본 연결, 새 이름, 변경 목록, 수정본 SHA-256 | 어느 원본에서 무엇을 바꿨는지 알 수 없음 |
원본은 처음 저장한 바이트 그대로 보관하고, 수정은 복사본에서 시작합니다. 원본을 열어서 고친 다음 파일명만 ‘원본’으로 되돌려도 보존이 아닙니다. 다시 다운로드하면 현재 선택 결과의 다른 파일이 저장될 수 있으므로 기존 원본 위에 덮어쓰지 않습니다.
실제 앱에서 원본을 확보하지 못한 상태라면 다음 요청문으로 먼저 결과를 고정할 수 있습니다. 계정 기능이나 UI에 따라 저장 방식은 본인이 확인하세요.
기존 결과를 덮어쓰지 않고 수정 전과 수정 제안을 구분한다.
대상은 아래 합성 HTML의 demo-v1이다. 이것을 실제 Claude 버전 번호로 주장하지 않는다.
원본의 날짜 2026-10-12와 상자 수 8개, 제목, 다른 문장은 유지한다.
허용 변경은 두 곳뿐이다.
1. id="time"의 14:00을 15:00으로 변경
2. id="state"의 접수중을 검토중으로 변경
변경 후 전체 HTML과 변경 목록을 보여준다.
외부 라이브러리·스크립트·연결 앱·실제 자료를 추가하거나 실행하지 않는다.
어느 원본을 수정하는지 불명확하면 새 버전을 만들었다고 단정하지 않고 질문한다.이 요청문이 파일 보존을 대신하지는 않습니다. AI에게 ‘원본을 보존했다’는 답을 받아도 내 저장 폴더에서 원본 바이트와 사본을 확인해야 합니다.
전체 합성 입력과 정한 변경 두 곳
아래가 수정 전 원문 전체입니다. 네트워크 주소·JavaScript·외부 폰트·외부 라이브러리가 없고, 실제 접수 서비스를 제공하지 않는 설명용 HTML입니다. UTF-8, BOM 없음, LF 줄바꿈, 마지막 줄바꿈 한 개를 기준으로 했습니다. 이 조건이 달라져도 화면이 비슷할 수 있지만 해시는 달라집니다.
<!doctype html>
<html lang="ko">
<head>
<meta charset="utf-8">
<title>연습 접수 안내</title>
</head>
<body>
<main>
<h1>연습 접수 안내</h1>
<p id="date">2026-10-12</p>
<p id="time">14:00</p>
<p id="state">접수중</p>
<p id="count">대상은 파란 상자 8개입니다.</p>
<p>이 문서는 합성 예제입니다.</p>
</main>
</body>
</html>수정본의 전체 내용은 이 원문에서 아래 두 줄만 바꾼 것입니다. 날짜·수량·제목·합성 예제 문장은 그대로입니다. 8개를 9개로 바꾸는 제안은 이번 승인 범위 밖입니다.
수정 전: <p id="time">14:00</p>
수정 후: <p id="time">15:00</p>
수정 전: <p id="state">접수중</p>
수정 후: <p id="state">검토중</p>저장 이름은 artifact-demo-v1-original.html과 artifact-demo-v1-working.html로 나눴습니다. working의 업무 버전 표식은 local-02로 별도 기록했습니다. 두 파일은 제작 작업 공간에서 직접 만들었으며 이 페이지가 공개 첨부나 실제 다운로드 파일을 제공한다고 쓰지 않습니다. 독자는 아래 코드로 빈 연습 폴더 안에 같은 합성 사본을 만들 수 있습니다.
HTML을 실행하지 않고 파일 바이트를 검사하기
다음 Python 3.12 코드는 임시 연습 폴더에 두 HTML을 직접 쓰고 읽어 비교합니다. HTML을 브라우저로 열거나 그 안의 코드를 실행하지 않으며 외부 통신도 없습니다. 두 변경이 정확히 한 번씩 나타나는지 확인하고, 원본 바이트 보존과 수정본의 전체 예상 바이트를 함께 대조합니다.
from pathlib import Path
from tempfile import TemporaryDirectory
from hashlib import sha256
original = '''<!doctype html>
<html lang="ko">
<head>
<meta charset="utf-8">
<title>연습 접수 안내</title>
</head>
<body>
<main>
<h1>연습 접수 안내</h1>
<p id="date">2026-10-12</p>
<p id="time">14:00</p>
<p id="state">접수중</p>
<p id="count">대상은 파란 상자 8개입니다.</p>
<p>이 문서는 합성 예제입니다.</p>
</main>
</body>
</html>
'''
changes = [
('<p id="time">14:00</p>', '<p id="time">15:00</p>'),
('<p id="state">접수중</p>', '<p id="state">검토중</p>')
]
modified = original
for before, after in changes:
if modified.count(before) != 1:
raise ValueError("변경 위치 누락 또는 중복")
modified = modified.replace(before, after, 1)
with TemporaryDirectory(dir=Path.cwd()) as folder:
source = Path(folder) / "artifact-demo-v1-original.html"
working = Path(folder) / "artifact-demo-v1-working.html"
source.write_bytes(original.encode("utf-8"))
working.write_bytes(modified.encode("utf-8"))
assert source.read_bytes() == original.encode("utf-8")
assert working.read_bytes() == modified.encode("utf-8")
print("original", sha256(source.read_bytes()).hexdigest())
print("working", sha256(working.read_bytes()).hexdigest())
print("allowed_changes", len(changes), "original_preserved", True)original b9027c46e1ceb5bbb814af7ac74648114566ead7e4397448a1f7355a536376fb
working 6cefb40102ecaf2edf5154b8afcc0ecb0c0d30c9afbc3dedf52851f66b4a977b
allowed_changes 2 original_preserved TruePython 3.12.14에서 본문 코드와 별도 사본 검증기를 실행했습니다. 제작한 두 파일은 각각 356바이트이며 위 해시와 일치했습니다. 실제 파일 비교, 허용 변경 두 곳, 추가 수량 변경, 원본 변경, 파일 기록 누락·중복, 변경하지 않은 수정본, LF/CRLF 차이, 사본 복구의 9개 검사가 모두 통과했습니다. Claude 응답·서비스 다운로드·HTML 동작·Windows 저장 과정은 시험하지 않았습니다.
Python hashlib 공식 문서는 sha256과 바이트 입력에 대한 해시 계산을 설명합니다. 해시가 다르다는 것은 바이트가 달라졌다는 뜻입니다. 악성 코드의 유무나 출처의 신뢰성을 판단하는 안전 인증서가 아닙니다. 파일이 동일하더라도 처음부터 문제가 있는 코드는 여전히 문제가 있습니다.
실패하면 새 사본에서 복구하기
| 실패 반례 | 기대 검출 | 복구 순서 |
|---|---|---|
| working에 상자 수 9개 추가 | 허용되지 않은 수정 | 변경 목록과 원본을 읽고 깨끗한 사본에 두 변경만 재적용 |
| original 끝에 공백 추가 | 원본 바이트 변경 | 변경 전 별도 보관본과 비교, 없으면 원본 보존 실패로 기록 |
| 원본 파일 기록을 두 번 적음 | 중복 파일 기록 | 원본/수정본의 실제 파일명·경로를 각각 확인 |
| 수정본 파일 기록 없음 | 누락 | 저장 성공을 주장하지 않고 파일 존재부터 확인 |
| 원본의 LF를 CRLF로 변환 | 원본 바이트 차이 | 내용 변경과 저장 형식 변경을 분리해서 기록 |
확장 검증기에서는 원본이 기준 문자열과 같은지도 확인했습니다. 단순히 ‘지금 존재하는 원본’과 ‘지금 존재하는 수정본’의 해시가 다르다는 조건만 쓰면 원본을 이미 덮어쓴 실수를 놓칠 수 있습니다. 최초 기준 해시는 수정 전 기록으로 보존해야 합니다. 이 예제에서는 원문의 독립 문자열을 기준으로 삼았습니다.
다시 내려받을 수 없거나 처음 원본을 보관하지 않았다면 ‘원본 복구 완료’로 표시하지 않습니다. 현재 확보한 파일의 출처·시점과 보존 실패를 적고 담당자가 어느 결과를 기준으로 삼을지 결정해야 합니다.
결과 사본 기록
대화·갈래 / 결과 이름 / 화면에서 확인 가능한 버전·수정 시점:
저장 시각 / 저장 원본 이름 / 최초 SHA-256:
원본 출처: 실제 저장 또는 자체 작성 합성 예제
수정 사본 이름 / 로컬 수정 번호:
허용 변경 목록 / 유지할 값:
검사한 두 파일의 실제 경로 / 현재 해시:
불일치와 중단 지점:
복구에 사용한 보관본 / 새 사본 / 재검사 결과:
미확인: 서비스 버전, 다운로드 성공, 화면 동작 등저장 검증과 실행 승인은 나누기
이 예제는 신뢰할 수 있는 자체 작성 HTML만 바이트로 읽었습니다. 실제로 받은 HTML에 스크립트·외부 통신·패키지 설치 요청이 들어 있다면 파일명이나 해시만 확인하고 실행하지 마세요. 데이터 접근·외부 전송·연결 앱·유료 기능이 생기는 실행은 별도 검토가 필요합니다. 단순 안내문과 로그인·서버·API가 필요한 도구의 실행 조건을 같다고 보지 않습니다.
업무 결과의 채택 기록까지 필요하다면 엑셀 AI 결과 승인대장을 연결하세요. 그 글은 사람이 고른 승인값을 보관하고, 이 글은 승인 전에 어떤 출력 사본을 수정했는지 바이트와 변경 목록으로 남깁니다. 원본이 보존됐다는 결론을 화면의 ‘성공’ 문장 대신 실제 파일 대조로 확인하는 것이 핵심입니다.
작성자 소개
