| name | transcript-markdown-cleanup |
| description | 원문 말투와 반복을 유지한 채, 문맥상 확실한 인식 오류만 고쳐 마크다운 스크립트로 정리하고 애매한 표현은 별도 체크리스트로 분리하는 작업에 사용한다. |
전사 스크립트 마크다운 정리
이 스킬은 원시 전사본을 읽기 좋은 마크다운 스크립트로 바꾸되, 원문 흐름은 유지하고 음성 인식 과정에서 생긴 것으로 보이는 오류만 문맥에 맞게 바로잡아야 할 때 사용한다.
목표
기본 산출물은 두 개다.
- 정리된 마크다운 스크립트
- 애매한 표현이나 의미를 확인하기 위한 체크리스트 마크다운 파일
이 작업은 요약이 아니다. 기본 원칙은 원문에 최대한 가깝게 유지하는 것이다.
정리 원칙
다음 기준을 순서대로 적용한다.
- 사용자가 강한 문체 수정을 원하지 않는 이상, 원래 말투와 반복, 추임새, 비효율적인 문장 흐름을 유지한다.
- 문맥상 거의 확실한 경우에만 인식 오류를 고친다.
- 이름, 기술 용어, 파일명, 제품명, 숫자, 도메인 용어가 명백히 틀린 경우는 바로잡는다.
- 어색해 보여도 실제 발화였을 가능성이 있으면 유지한다.
- 틀렸을 가능성은 높지만 안전하게 복원할 수 없으면 억지로 고치지 말고 체크리스트로 보낸다.
- 사용자가 따로 요청하지 않는 이상, 요약하거나 문어체로 다듬거나 화자의 톤을 정규화하지 않는다.
이런 경우는 고칠 가능성이 높다.
- 기술 용어가 깨진 경우:
발그라인드 -> Valgrind
- CS 용어가 잘못 적힌 경우:
말록 -> malloc
- 문맥상 확실한 이름 오인식
- 앞뒤 문장을 보면 의도한 도구나 제품명이 분명한 경우
- 숫자나 단위가 문맥과 명백히 충돌하는 경우
이런 경우는 기본적으로 유지한다.
- 구어체 특유의 반복
- 어색하지만 실제 말로는 충분히 나올 수 있는 표현
- 길고 돌아가는 문장이지만 이해는 되는 경우
- 빠진 내용을 새로 지어내야만 복원되는 경우
출력 구조
정리본은 대체로 아래 구조를 따른다.
# {제목} 스크립트 정리
원본: `{원본 파일명}`
정리 기준: 원문을 최대한 유지하되, 녹음 스크립트 과정에서 생긴 명백한 텍스트 인식 오류만 최소한으로 다듬었다. 반복, 말버릇, 비효율적인 문장 흐름은 유지했다.
## 00:00 {해당 구간 주제}
**화자 00:00**
발화 내용
서식 원칙:
- 섹션 헤더는
## MM:SS 주제 형식을 사용한다.
- 제목은 시간 흐름과 주제를 잡아주는 정도로만 쓰고, 과한 요약 제목은 피한다.
- 본문은 화자와 타임스탬프 기준의 발화 블록으로 유지한다.
- 한국어 띄어쓰기와 문장부호는 자연스럽게 정리하되, 문어체 문장으로 과도하게 다듬지 않는다.
작업 순서
1. 원본을 끝까지 읽기
편집 전에 원본 전사본을 처음부터 끝까지 읽는다. 전체 대화 맥락을 모른 채 줄 단위로 바로 고치기 시작하면 잘못 복원할 가능성이 높다. 많은 수정은 뒤쪽 문맥을 본 뒤에야 확정된다.
2. 첫 번째 마크다운 정리본 만들기
첫 번째 정리본은 다음에 집중한다.
- 시간 순서를 유지한다
- 화자 전환을 유지한다
- 이해 가능한 범위에서는 반복 표현과 머뭇거림도 유지한다
- 읽기 편하도록 적절한 주제 경계에 섹션 헤더를 넣는다
첫 번째 패스에서는 거의 확실한 오류만 고친다.
3. 문맥 기반 2차 보정
초안 전체를 다시 읽고, 앞뒤 의미와 분명히 맞지 않는 표현만 두 번째로 보정한다.
2차 보정의 대표 사례:
- 도구명이나 모델명이 분명히 잘못된 경우
- 문단 전체 의미와 충돌하는 명사가 들어간 경우
- 인접 문장으로 안전하게 복원 가능한 깨진 문장
확신이 낮으면 억지로 고치지 말고 체크리스트로 보낸다.
4. 애매한 표현 체크리스트 만들기
보조 파일은 다음과 같은 이름을 우선 사용한다.
{제목} 애매한 표현 체크리스트.md
체크리스트에는 다음을 넣는다.
- 스크립트 안에서의 위치
- 현재 문구
- 왜 애매한지
- 가능하면 1~3개의 예상 대체표현
- 사용자가 정확한 표현을 직접 적을 수 있도록
직접 수정안 선택지
체크리스트 후보에는 다음 종류만 둔다.
녹음 파일이나 원본 음성을 다시 들을 수 없다고 가정한다. 따라서 사용자가 나중에 확인해야 한다는 식의 대기 선택지는 만들지 않는다.
형식은 다음처럼 간결하게 유지한다.
## 4. 13:30 발표/프레젠테이션 구간
위치
- 13:30 부근
- 발표/프레젠테이션 관련 문장
현재
우리는 프리젠테이션 해봐야 인생은 거 아니죠.
의문
- 문맥상 표현이 어색함
후보
- A. 그대로 유지
- B. 프레젠테이션 해봐야 의미 없는 거 아니죠
- C. 프레젠테이션 해봐야 되는 거 아니죠
- D. 직접 수정안
체크리스트 운영 방식
체크리스트 항목은 보통 두 종류로 나눈다.
표현 애매함
의미 확인 필요
표현 애매함은 단어나 짧은 구절이 잘못 인식된 것 같을 때 사용한다.
의미 확인 필요는 문장은 읽히지만, 그 발화의 핵심 뜻이나 의도가 불분명할 때 사용한다.
사용자가 체크리스트에 답하면:
- 본문 스크립트에 바로 반영한다
- 체크리스트 파일의 해당 항목 제목에
(반영 완료: {선택지 또는 직접 수정})을 표시한다
- 체크리스트 상단의 처리 상태를 갱신한다
- 보수적인 수정 기조를 유지한다
- 사용자가 원하지 않는 큰 폭의 재서술은 하지 않는다
- 아직 남은 항목이 있으면 다음 항목을 이어서 묻는다
체크리스트를 사용자에게 확인받을 때는 한 번에 모든 항목을 길게 묻기보다, 저장된 체크리스트 파일을 기준으로 순서대로 진행한다. 각 질문에는 현재 진행 상황을 함께 보여준다.
예:
체크리스트 4/17
위치
- 13:30 부근
현재
우리는 프리젠테이션 해봐야 인생은 거 아니죠.
의문
- 문맥상 표현이 어색함
후보
- A. 그대로 유지
- B. 프레젠테이션 해봐야 의미 없는 거 아니죠
- C. 프레젠테이션 해봐야 되는 거 아니죠
- D. 직접 수정안
사용자가 여러 번호의 답을 한꺼번에 주면 그 범위는 모두 반영하고, 다음 미해결 번호부터 다시 이어서 묻는다.
사용자와의 진행 방식
기본 흐름은 다음과 같다.
- 정리된 마크다운 스크립트를 만든다.
- 애매한 표현이 남으면 체크리스트 파일을 만든다.
- 체크리스트 파일을 저장한 뒤, 사용자에게 1번부터 순서대로 묻는다.
- 질문에는
체크리스트 {현재 번호}/{전체 개수} 진행 상황을 표시한다.
- 사용자가 답하면 본문 스크립트와 체크리스트 파일에 바로 반영한다.
- 다음 미해결 항목을 이어서 묻는다.
- 사용자가 여러 항목의 답을 한꺼번에 주면 모두 반영하고, 다음 미해결 항목부터 진행한다.
- 모든 항목이 반영되면 체크리스트 상단에 전체 반영 완료 상태를 표시한다.
사용자에게는 이런 식으로 설명하는 편이 좋다.
- "요약/문체 정리는 하지 않고, 문맥상 잘못 인식된 표현만 고쳤다."
- "확신 없는 표현은 과하게 복원하지 않고 체크리스트로 분리했다."
- "체크리스트는 저장해 두고, 진행률을 보여주면서 순서대로 확인받는다."
하지 말아야 할 것
기본적으로 다음은 하지 않는다.
- 구어체 발화를 매끈한 문어체 글로 다시 쓰기
- 비효율적으로 느껴진다는 이유만으로 반복 삭제하기
- 어색하다는 이유만으로 내용 빼기
- 여러 턴을 하나의 요약 문단으로 합치기
- 비어 있는 의미를 조용히 추측해서 채워 넣기
반대로 다음은 필요하면 한다.
- 깨진 기술 용어 복원
- 문맥상 성립할 수 없는 문장 보정
- 읽기 쉽게 시간/주제 헤더 추가
- 확신 없는 부분을 추측 대신 체크리스트로 분리
파일 이름 원칙
사용자가 달리 요청하지 않으면 보통 다음 이름을 쓴다.
- 정리본:
{원본 제목} 스크립트 정리.md
- 체크리스트:
{원본 제목} 애매한 표현 체크리스트.md
이미 정리본이 있다면, 사용자가 새 버전을 명시적으로 요구하지 않는 이상 중복 파일을 만들기보다 기존 파일을 업데이트한다.
범용 사용 지침
이 스킬은 특정 레포 구조나 기존 예시 파일에 의존하지 않아야 한다.
항상 범용적으로 유지한다.
- 제목은 원본 자료나 사용자 요청에서 추론한다
- 체크리스트 위치는 타임스탬프, 화자, 주변 주제로 설명한다
- 고정된 폴더 구조를 전제하지 않는다
- 사용자가 주지 않은 참조 파일을 당연하게 전제하지 않는다