채널에서 동일한 사건에 대한 설명은 종종 여러 메시지에 흩어져 있습니다. 먼저 예고가 나오고, 그다음 확인 소식이 이어지며, 이후 시간이 변경되고, 마지막으로 결과가 발표됩니다. 검색 결과 중 가장 눈에 띄는 메시지 하나만 열어보면, 초기 계획을 최종 결과로 오해하기 쉽습니다. 타임라인의 역할은 각 변경 사항을 발생한 시점으로 되돌려 놓고, 독자가 원본 메시지를 열어 확인할 수 있도록 하는 것입니다.
신뢰할 수 있는 타임라인은 단순히 모든 일치 항목을 날짜순으로 나열하는 것이 아닙니다. 사건의 경계를 명확히 하고, 관련 없는 중복을 배제하며, 채널 자체의 공지사항과 타인의 발언을 인용한 내용을 구분하고, 현재 데이터로 커버되지 않은 공백을 표시해야 합니다.
먼저 “하나의 사건”이 무엇인지 정의해 보겠습니다
이벤트 명칭이 포괄적일수록 타임라인에 관련 없는 내용이 섞이기 쉽습니다. ‘프로젝트 X’에는 자금 조달, 버전 출시, 커뮤니티 활동, 보안 사고가 포함될 수 있으며, ‘선거’에는 서로 다른 지역과 여러 차례의 선거가 포함될 수 있습니다.
시작하기 전에 최소한 목표 엔티티, 이벤트 유형, 시간 범위 및 종료 조건을 명시해야 합니다. 예시:
현재 채널에서 7월 1일부터 7월 31일까지 “프로젝트 X 2.0 정식 출시”와 관련된 타임라인을 정리합니다. 출시 일정, 연기, 기능 범위, 정식 출시 및 후속 정정 사항만 포함하고, 가격 논의와 일반 재게시 내용은 제외합니다.
종료 조건은 “정식 출시”, “행사 종료” 또는 “현재 범위 내 마지막 업데이트”일 수 있습니다. 명확한 종료 메시지가 없는 경우, “타임라인은 현재 조회 가능한 범위까지입니다”라고 기재해야 하며, 임의로 사건이 종료되었다고 선언해서는 안 됩니다.
각 노드에 고정 필드 지정
각 타임라인 노드에는 다음 내용을 포함할 것을 권장합니다:
| 필드 | 설명 |
|---|---|
| 메시지 시간 | 페이지에 표시된 정확한 시간을 사용하고, 시간대 맥락을 설명합니다 |
| 노드 유형 | 최초 공지, 확인, 진행 상황, 정정, 철회 또는 결과 |
| 원문의 사실 | 메시지에서 명확하게 표현된 내용만 기술 |
| 이전 항목과의 관계 | 추가, 중복, 충돌 또는 대체 |
| 증거 유형 | 채널 공지, 인용 출처, 댓글 또는 확인 불가 |
| 원본 메시지 | 열 수 있는 Telegram 출처 |
“영향”과 “의미”는 분석란에 별도로 기재해야 하며, 원문의 사실 내용과 혼동되어서는 안 됩니다. 이를 통해 독자는 어떤 내용이 채널에서 나온 것인지, 어떤 내용이 정리자의 해석인지 구분할 수 있습니다.
검색 시 먼저 앵커를 찾은 다음, 표현을 확장합니다
먼저 프로젝트명, 날짜, 버전 번호, 장소 및 @username 등과 같은 정확한 앵커를 사용합니다. 그 후 ‘발표’, ‘출시’, ‘공개’, ‘연기’, ‘지연’, ‘정정’ 및 ‘철회’와 같이 사건의 행동을 나타내는 동의어를 보충합니다.
1차 결과는 후보 집합을 구성하는 데 사용되며, 당장 결론을 내리지 마십시오. 각 메시지의 전후 문맥을 읽고, 이전 메시지를 인용했는지, 답글이나 후속 설명이 있는지 확인하십시오. 일부 메시지는 뉴스 제목만 반복하는 반면, 다른 메시지는 실제 공지 사항입니다.
시간적 순서는 인과관계와 동일하지 않습니다
메시지 B가 메시지 A보다 뒤에 있다고 해서 A가 B를 초래했다는 의미는 아닙니다. 채널이 사건 발생 시점보다 늦게 보도를 재전송할 수도 있습니다. 타임라인에서는 “메시지 전송 시간”과 “메시지가 주장하는 사건 발생 시간”을 구분해야 합니다.
예를 들어, 8월 10일 게시물에 “행사는 8월 8일에 종료되었습니다”라고 적혀 있다면, 두 날짜 모두 그대로 유지해야 합니다. 게시물 시간순으로만 정렬할 때는 행사가 8월 10일에 종료된 것처럼 작성해서는 안 됩니다.
전달 및 중복 메시지는 어떻게 처리할까요?
동일한 내용이 반복적으로 전달될 경우, 하나의 사실 노드로 통합할 수 있으나 최초 등장 및 후속 반복 메시지의 출처는 유지해야 합니다. 서로 다른 메시지가 동일한 외부 보도를 인용한 경우, 이를 여러 개의 독립적인 확인 사례로 간주해서는 안 됩니다.
채널 측에서 정보 출처를 명시하지 않은 경우, “채널 게시”라고만 기재하고, 임의로 “공식 확인”으로 격상하지 마십시오. 뉴스, 금융 또는 정책과 관련된 내용은 최종 결론을 내릴 때 여전히 정부, 기업 또는 프로젝트의 공식 채널을 통해 확인해야 합니다.
충돌 및 수정 사항을 어떻게 표시할 것인가
초기 오류 노드를 삭제하지 마십시오. 이를 그대로 유지하고 후속 노드에 “수정됨” 또는 “대체됨”이라고 표시해야만, 타임라인을 통해 독자가 왜 서로 다른 내용을 보게 되는지 설명할 수 있습니다.
두 개의 메시지가 서로 상충되지만 채널에서 어느 쪽이 유효한지 명확히 명시하지 않은 경우, 두 메시지를 나란히 표시하고 “현재 범위로는 확인할 수 없음”이라고 기재해야 합니다. 시간이 더 최근인 것이 단서일 뿐, 자동적으로 진실이라고 단정할 수는 없습니다.
데이터 공백 식별
타임라인은 현재 조회 가능한 범위가 최초 공지 시점을 포함하지 않아 중간부터 시작될 수 있으며, 주요 날짜에 메시지가 없을 수도 있습니다. 가장 이른 시점과 가장 늦은 시점의 이용 가능한 메시지, 현재 데이터 범위, 그리고 어떤 단계에서 증거를 찾지 못했는지를 명확히 기재해야 합니다.
“찾을 수 없음”은 확인된 범위만을 설명해야 합니다. 이를 “사건이 발생하지 않았다” 또는 “채널에서 보도된 적이 없다”라고 표현하지 마십시오. 결과에 “전체 타임라인”이 필요한 경우, 해당 범위가 실제로 사건 전체를 포괄하는지 먼저 확인한 후 “전체”라는 단어를 사용하십시오.
asktele를 타임라인 작업에 활용하는 방법
선택한 방송 채널을 중심으로, 자연어 질문을 현재 조회 가능한 메시지와 결합하여 사건의 시점을 파악하고 메시지 출처를 명시할 수 있습니다. 모델에게 한 번에 전체 이야기를 설명하도록 요구하는 것보다, 먼저 구체적인 질문을 통해 골격을 세운 다음 누락된 단계에 대해 추가 질문을 하는 것이 더 좋은 방법입니다.
제품은 여러 채널의 내용을 자동으로 하나의 타임라인으로 통합하지 않습니다. 여러 출처를 넘나드는 조사를 할 때는 각각 별도의 타임라인을 구축한 후, 사용자가 어떤 노드가 독립적인 정보이고 어떤 노드가 서로 재전송된 것인지 직접 확인해야 합니다. 지속적인 수정 사항에 주의를 기울여야 할 경우, 채널 업데이트 및 수정 사항 추적 가이드를 계속 읽어보시기 바랍니다.
명확한 시간, 원문에 근거한 상태 변화, 확인할 수 있는 메시지 출처. 이 중 어느 하나라도 누락되면 해당 노드의 확실성을 낮춰야 합니다.
사실 출처
- Telegram:messages.search — 텍스트, 날짜 범위 및 필터 조건.
- Telegram: 딥 링크 — 특정 채널 메시지로 돌아가는 링크 구조.
- Telegram: Pagination — 기록 및 검색 결과에서 날짜, ID 등을 사용하여 오프셋 페이징을 적용합니다.
- Telegram: messages.getHistory — 채팅 기록의 시간순 및 페이지별 목록에 접근할 수 있습니다.
- Telegram: messages.getMessages — 접근 권한이 있는 경우 메시지 식별자를 기준으로 특정 메시지를 가져옵니다.
마지막 검토일: 2026년 8월 9일. Telegram 화면은 플랫폼과 버전에 따라 달라질 수 있습니다.