웹 페이지 문서를 번역하는 webtoword 스킬
실제 프롬프트로 따라가는 스킬 제작 과정
시작 — xtoword에서 webtoword로
이전 블로그에서 x 아티클을 번역해서 워드 파일로 만드는 xtoword라는 스킬을 만드는 방법을 소개했습니다. X(구 트위터)에 올라온 긴 글의 URL을 입력하면, Claude가 해당 페이지에 직접 접근하여 본문 텍스트와 이미지를 추출하고, 전체 내용을 한국어로 번역한 뒤, 이미지가 원래 위치에 삽입된 Word(.docx) 파일을 자동으로 생성해주는 스킬입니다. Claude for Chrome 확장 프로그램을 통해 웹 페이지를 탐색하고, Cowork 모드에서 파일 생성까지 한 번에 처리하는 구조였습니다.
이 스킬은 꽤 유용했습니다. X에 올라오는 영어 아티클을 한국어 Word 문서로 변환하는 작업이 URL 하나로 끝났기 때문입니다. 그런데 어느 날, X가 아닌 웹사이트의 글을 번역해야 하는 상황이 생겼습니다. beehiiv라는 뉴스레터 플랫폼에 실린 'Karpathy's Skill Loop'이라는 글이었습니다.
xtoword를 실행했지만, 동작하지 않았습니다. xtoword는 X 플랫폼의 DOM 구조에 맞춰 설계된 전용 스킬이었기 때문입니다. X가 아닌 일반 웹페이지는 처리 대상이 아니었습니다.
같은 상황이 앞으로도 반복될 것이 분명했습니다. X 외에도 Substack, Medium 같은 다양한 플랫폼의 글을 번역해야 할 일이 계속 생길 것이었습니다. 그래서 일반 웹페이지에서도 동작하는 새로운 스킬, webtoword를 만들기로 했습니다. 이 글은 그 제작 과정을, 실제로 Claude에게 입력한 프롬프트를 중심으로 기록한 것입니다.
첫 번째 프롬프트 — 작업 시작
가장 처음 Claude에게 보낸 프롬프트는 다음과 같습니다.
xtoword 스킬을 이용해서 https://godofprompt.beehiiv.com/p/karpathy-s-skill-loop 링크에 있는 내용을 정리해주세요
xtoword는 X URL만 처리할 수 있으므로 이 요청은 실패했습니다. 하지만 Claude는 이것이 X URL이 아니라는 점을 인식하고 다른 방법을 제안했습니다. Claude for Chrome을 통해 직접 페이지에 접근하고, DOM 구조를 분석해서 내용을 추출하는 방식이었습니다.
그렇게 첫 번째 Word 문서가 생성되었지만, 만족할 만한 품질이 아니었습니다.
피드백으로 품질 올리기 — 원문 구조의 보존
첫 번째 번역된 문서를 검토한 결과 몇 가지 문제가 발견되었습니다. 가장 핵심적인 문제는 원문에서 누락되는 내용이 있었다는 점이었고, 다음과 같은 프롬프트를 통해서 수정을 요청했습니다.
입력 프롬프트
도입부 문장이 번역되지 않았습니다. Greetings from above...
원문에는 'Greetings from above,'라는 인사말이 분명히 존재했지만, 번역본에서는 생략되어 있었습니다. 사소해 보이는 인사말이라도 원문에 포함된 내용은 모두 번역에 반영되어야 합니다. 뉘앙스를 담고 있기 때문입니다.
두 번째로 다음과 같이 볼드로 표시된 문장을 무시하고 하나의 통으로 된 문장으로 번역을해서 강조되는 사항을 알 수 없었던 문제에 대해서 수정을 요청했습니다. 형식은 내용만큼 중요합니다. 볼드 제목이 문단과 합쳐지면 원문의 핵심 메시지 전달 방식이 훼손됩니다.
입력 프롬프트
볼드로 표시된 Run the skill, Diagnose... 부분은 일종의 제목인데 다른 부분과 합쳐져서 하나의 문장으로 번역이 됐습니다
세 번째 피드백에서는 스크린샷을 첨부하며 더 구체적으로 지적했습니다.
입력 프롬프트
원본 문장과 번역본 문장을 캡쳐했습니다. 단락 나누기 띄어쓰기 등이 원문과 같아야 합니다.
번역이란 단순히 의미를 옮기는 작업이 아닙니다. 원문의 단락 구조, 줄바꿈, 강조 표시까지 정확히 재현해야 하는 작업입니다. 이 원칙은 이후 webtoword 스킬의 핵심 규칙이 되었습니다.
마지막으로 다음과 같은 프롬프트를 보냈습니다.
입력 프롬프트
다시 한번 꼼꼼하게 단락과 구성을 검토해주세요. 시간이 걸려도 됩니다.
이 프롬프트는 '완벽함'이 '속도'보다 중요하다는 기준을 명확히 한 것입니다. Claude는 이 지시를 받고 한 문장 한 문장 원문과 대조하며 검토를 수행했습니다.
번역 품질 다듬기
구조와 디자인 문제를 해결한 뒤, 마지막 단계는 번역 품질 자체를 높이는 것이었습니다.
입력 프롬프트
아래와 같은 번역은 무슨 말인지 잘 모르겠습니다. 번역 품질을 다시 한번 꼼꼼하게 검토해주세요
Greetings from above, --> 저 위에서 인사드립니다,
'Greetings from above'를 '저 위에서 인사드립니다'로 번역한 것은 전형적인 직역의 문제입니다. 이 뉴스레터의 이름이 'God of Prompt'라는 점을 고려하면, '하늘에서 인사 전합니다'와 같이 뉘앙스를 살린 번역이 필요합니다.
이 피드백을 기점으로 Claude는 전체 번역을 재검토했습니다. 단순한 단어 치환이 아니라, 원문의 톤과 문맥을 고려한 번역으로 교체하는 작업이었습니다. 예를 들어 '제네릭한 제목줄'은 '뻔한 제목줄'로, '이것은 폭발적으로 퍼졌습니다'는 '폭발적인 반응이었습니다'로 수정되었습니다. 이 과정에서 25건 이상의 번역이 개선되었습니다.
이 경험에서 도출된 번역 원칙은 다음과 같습니다.
첫째, 직역이 아닌 문맥 기반 번역을 수행할 것.
둘째, 원문의 톤(유머, 격식, 캐주얼 등)을 보존할 것.
셋째, 괄호 안에 원문을 병기하는 '번역체'를 피할 것.
넷째, 번역 후 반드시 전문을 통독하여 자연스러움을 검증할 것.
구성을 변경하고, 번역 품질을 개선하는 다양한 작업을 통해서 다음과 같은 최종 번역본을 얻을수 있었습니다.
https://docs.google.com/document/d/183I8kdIogA6n6Yd9VW4zBgI34tpt4gVkRgi_sGvhpUo/edit?tab=t.0
스킬로 만들기 — 핵심 프롬프트
지금까지의 작업 과정에서 축적된 원칙과 노하우를 재사용 가능한 스킬로 만드는 단계입니다. 다음 프롬프트를 사용했습니다.
입력 프롬프트
지금까지 작업한 사항을 정리해서 webtoword 스킬을 만들어주세요. xtoword 스킬을 기반으로 오늘 작업한 사항이 세부적으로 추가된 스킬이어야 합니다.
webtoword 스킬에는 오늘 작업에서 도출된 네 가지 핵심 개선사항이 반영되었습니다. 첫째, DOM 구조 분석 단계(Phase 1-B)를 추가하여 웹페이지의 단락 구조를 먼저 파악하도록 했습니다. 둘째, 번역 품질 가이드라인(Phase 3)에 문맥 기반 번역, 톤 보존, 번역체 회피 원칙을 명시했습니다. 셋째, boxedBlock 코드 블록 형식(Phase 4)을 정의하여 프롬프트와 코드의 시각적 표현을 표준화했습니다. 넷째, 번역 품질 검증 단계(Phase 5)를 추가하여 완성 후 전체 검토를 의무화했습니다.
기존 스킬 업그레이드
webtoword 스킬이 완성된 시점에서, 기존 xtoword 스킬과의 관계를 정리할 필요가 있었습니다.
입력 프롬프트
현재 비슷한 구성의 xtoword 스킬이 있습니다. 지금 만든 webtoword 스킬과 xtoword 스킬을 합치는 것이 좋을지 각각 유지하는 것이 좋을지 의견주세요
Claude의 분석 결과, 두 스킬을 분리 유지하는 것이 적합하다는 결론이 나왔습니다. 두 스킬은 약 70%의 로직을 공유하지만, X 플랫폼 특유의 DOM 구조(스레드 연결, 미디어 임베드 등)를 처리하는 부분이 xtoword에만 존재하기 때문입니다. 통합할 경우 X 전용 로직이 일반 웹페이지 처리를 복잡하게 만들 위험이 있었습니다.
대신, webtoword에서 개선된 사항을 xtoword에도 역으로 반영하기로 했습니다.
입력 프롬프트
네, xtoword 스킬을 업데이트해주세요
이렇게 하여 xtoword v2가 완성되었습니다. 단락 구조 매핑, 번역 품질 가이드라인, boxedBlock 헬퍼, 번역 품질 검증 단계라는 네 가지 개선사항이 xtoword에도 적용되었고, '흔한 실수와 방지법' 섹션이 추가되어 향후 같은 실수를 반복하지 않도록 했습니다.
정리 — 스킬 만들기의 핵심
이 전체 과정을 돌아보면 한 가지 패턴이 눈에 띕니다.
처음 프롬프트('xtoword로 이 링크를 정리해주세요')는 스킬을 만들기 위한 프롬프트가 아니었습니다. 그것은 단지 한 번의 작업 요청이었습니다. 스킬의 가치를 만든 것은 그 이후의 피드백들이었습니다. '이건 번역되지 않았습니다', '형식이 원문과 다릅니다', '번역 뉘앙스가 어색합니다'와 같은 구체적인 지적이 품질 기준을 정의한 것입니다.
피드백이란 결국 '원하는 결과의 기준'을 정의하는 행위입니다. 'Word 문서가 필요하다'가 아니라 '이런 품질의 Word 문서가 필요하다'라는 구체적 기준을 제시하는 것입니다. Claude는 이 기준들을 수집하여 일반화하고, SKILL.md에 체계적으로 정리합니다. 다음번에 같은 유형의 작업을 요청하면 그 기준들이 자동으로 적용됩니다.
반복되는 작업이 있다면, Claude와 대화를 시작하는 것을 권합니다. 첫 번째 결과물이 완벽하지 않아도 괜찮습니다. 피드백을 보내면 됩니다. 그 피드백들이 축적되어, 결국 자신만의 맞춤형 자동화 스킬이 완성됩니다.
필요하신 분들에게 다운로드 링크를 공유드립니다.
댓글로 간단한 의견, 후기 함께 남겨주시면 감사합니다.