콘텐츠·미디어웹 · Python 서버

HTML News Creator

커뮤니티 리포트 미리보기의 목표 개수를 늘려도 가짜 뉴스 항목을 채우지 않도록 고쳤습니다. 읽기 목적과 데이터 범위를 맞춘 HTML News Creator 제작기입니다.

AI Tools Lab · 소개 글 작성 · 수정

HTML News Creator — 프로젝트 화면
News Studio 운영 대시보드입니다. 수집·생성 상태를 살피고 리포트 검토로 이동하는 화면입니다.

스무 개를 선택했다고 스무 개의 소식이 생기는 것은 아닙니다

HTML News Creator에서는 AI 소식을 수집한 뒤 분류하고 묶어 HTML 리포트로 만드는 흐름을 만들었습니다. 운영 화면에서 출력 형식을 바꾸고 미리보기를 읽은 다음 결과를 검토합니다. 저는 이 미리보기의 개수 설정이 실제 자료와 어떤 관계를 가져야 하는지 다듬었습니다.

5월 28일에는 커뮤니티 리포트 미리보기에서 부족한 항목을 일반 샘플 뉴스로 채우지 않도록 고쳤습니다. 일반 템플릿 미리보기에는 레이아웃을 보여주기 위한 합성 항목이 있었는데, 수동 커뮤니티 자료를 읽는 경로에 같은 채우기 규칙을 적용하면 성격이 다른 내용이 섞일 수 있었습니다.

문제는 제목에 Top10이 있는지보다 입력에 없는 항목이 왜 화면에 나타나는지였습니다. 목표 개수를 20으로 올려도 자료가 그만큼 존재한다는 뜻은 아닙니다. 저는 개수 설정을 자료를 늘리는 명령으로 해석하지 않도록 수정했습니다.

레이아웃 샘플과 커뮤니티 자료를 나눴습니다

일반 미리보기는 저장된 리포트를 읽거나, 자료가 없으면 화면 구성 확인용 샘플을 만들 수 있습니다. 샘플에는 ‘미리보기용 섹션’과 예시 링크를 붙여 실제 기사와 구분합니다. 색상이나 배치 옵션의 차이를 보기 위한 입력입니다.

커뮤니티 모드는 선택한 digest 자료를 리포트에 매핑합니다. 기본 예제 자료도 이 모드의 구성을 보여주는 용도로 둡니다. 그 목록의 실제 항목과 별도로 일반 미리보기의 합성 뉴스까지 뒤에 추가하지 않도록 했습니다.

두 경로는 같은 HTML renderer를 사용해도 입력의 의미가 다릅니다. 저는 자료를 읽은 뒤 목표 개수보다 많으면 자르는 동작은 유지하고, 목표보다 적을 때 샘플을 붙이는 동작은 일반 미리보기에만 남겼습니다. 공통 출력 엔진을 쓰면서도 데이터 선택 규칙은 나눠야 했던 부분입니다.

선택한 모드가 출력 형식까지 이어지게 했습니다

커뮤니티 리포트에는 signal과 hype 같은 읽기 모드가 있습니다. 각각 관련 출력 형식을 갖는데, 기존 일반 뉴스 형식 옵션이 남아 있으면 모드 이름과 실제 화면의 구성이 어긋날 수 있습니다. 저는 커뮤니티 모드에 맞는 출력 형식을 연결했습니다.

예를 들어 커뮤니티 signal 모드를 선택하면 해당 자료를 signal 화면 구성으로 읽습니다. 이전 설정에 일반 newsstream이 남아 있다고 그 형식으로 섞어 렌더하지 않습니다.

이 선택은 데이터 처리와 출력 처리를 연결합니다. 어떤 내용을 읽고 싶은지 고른 순간부터 매핑과 제목, 섹션 구성이 같은 목적을 반영해야 합니다. 옵션 목록에 모드가 생긴 것만으로 작업을 끝내지 않고 실제 미리보기의 결과까지 확인하도록 했습니다.

개수보다 입력에 없는 문장이 없는지 검사했습니다

회귀 조건에는 signal 모드에서 목표 개수를 20으로 지정하는 경우를 넣었습니다. 이때 커뮤니티 제목은 유지하고 ‘미리보기용 섹션’이나 일반 예시 링크가 결과에 섞이지 않는지 확인합니다. 단순히 HTML에 20개 블록이 있는지 검사하는 기준은 택하지 않았습니다.

목표 개수는 최대 표시 범위와 편집 의도를 표현할 수 있지만 빈 자료를 사실로 채우는 근거는 아닙니다. 저는 부족한 목록을 그대로 다룰 수 있도록 경로를 나누고, 실제로 어떤 입력을 읽었는지 출력이 드러내도록 만들었습니다.

이 검수는 기사 내용의 진위를 대신하지 않습니다. 자료 안의 주장과 출처는 편집할 때 별도로 읽어야 합니다. 여기서 고친 것은 입력 목록에 없던 샘플이 다른 종류의 리포트에 들어가는 조건입니다. 검사마다 무엇을 확인하는지 범위를 좁혀야 결과를 설명할 수 있습니다.

수집·편집·미리보기를 같은 완료로 묶지 않았습니다

뉴스 파이프라인은 수집, 본문 추출, 분류와 묶음, 검수, 생성, 렌더로 나눴습니다. 여러 출처가 같은 사건을 다룬다면 링크 수가 그대로 기사 수가 되지 않도록 묶는 단계가 필요합니다. 또한 수집된 날짜와 원문 사건의 날짜도 구분해 읽어야 합니다.

운영 화면에는 소스와 정책, 리포트와 검토 경로를 따로 뒀습니다. 화면 옵션을 바꾸는 단계는 무엇을 수집할지 바꾸는 단계와 다릅니다. 미리보기는 데이터베이스에 새 결과를 쓰지 않고 형식을 확인하도록 구성했습니다.

저는 이 차이를 자동화의 경계로 사용합니다. 보기 좋은 HTML이 만들어졌다는 사실만으로 수집과 근거 검수까지 끝난 것은 아닙니다. 각 단계가 어떤 입력과 결과를 가진 상태인지 살펴야 같은 소식의 중복이나 부족한 자료를 다시 정리할 수 있습니다.

빈자리를 채우기보다 읽는 목적을 유지합니다

커뮤니티 프리셋에서도 기사와 예시를 구분하는 원칙을 유지했습니다. 목표 개수가 남았다는 이유로 예시를 더하면 화면은 완성되어 보일 수 있지만 독자는 서로 다른 입력을 같은 소식으로 읽게 됩니다.

비슷한 뉴스 도구를 만들 때는 데이터 없는 미리보기, 저장된 리포트, 수동 큐레이션을 각각 확인해볼 수 있습니다. 모두 같은 renderer를 써도 샘플을 허용할 조건은 다를 수 있습니다. 옵션을 바꾸었을 때 목록을 잘라내는지, 임의로 늘리는지도 함께 검사해야 합니다.

커뮤니티 리포트에는 선택한 자료의 항목을 남기고, 부족한 개수를 일반 샘플 뉴스로 채우지 않게 했습니다. 선택한 읽기 모드에 맞는 출력 형식도 연결했습니다. 목록이 짧더라도 독자가 어떤 자료를 읽고 있는지 분명해야 했습니다.

개발 자료

프로젝트 링크

커뮤니티 자료와 화면 샘플을 섞지 않고, 미리보기의 목표 개수가 입력 자료를 늘리지 않도록 다듬었습니다.

원본 프로젝트 ↗ · 문의·정정 요청