Horizon 카테고리 한도를 넣어도 기술 글이 빠지는 이유

Horizon으로 기술 소식을 모을 때 카테고리 한도만 설정하면 기술 해설 글의 자리가 확보된다고 생각하기 쉽습니다. 하지만 확인한 구현은 점수순으로 카테고리별 상한을 적용한 뒤 전체 개수로 다시 자릅니다. 하루 여섯 편을 읽으려는 작은 팀이라면 AI 소식 세 편, 기술 해설 두 편, 기타 한 편처럼 모든 그룹의 상한을 먼저 배분하는 편이 이해하기 쉽습니다. 그래도 조건을 통과한 글이 없으면 빈자리는 남습니다.

확인일: 2026년 10월 16일. Thysrael/Horizon 소스 8f5446bf, pyproject 기준 버전 0.1.0을 검토했습니다. 공식 문서와 소스를 AI의 도움으로 정리한 글이며, Horizon 설치·모델 호출·실제 브리핑 생성은 하지 않았습니다. 아래 점수와 글 목록은 설명용 합성 데이터이고, 선택 결과는 소스의 규칙을 따라 손으로 계산했습니다.

Horizon은 정보를 모은 뒤 읽을 글을 고릅니다

Horizon은 RSS, Hacker News, GitHub 등에서 콘텐츠를 모아 AI로 분석하고, 배경 설명을 보완해 브리핑을 만드는 Python 프로젝트입니다. 기술 뉴스와 긴 개발 해설에 서로 다른 처리 프로필을 붙일 수 있습니다. 예를 들어 tech-news는 시의성 있는 변화에, tech-blog는 문제·해결·교훈을 읽는 데 맞춘 기준을 갖습니다.

저장소는 2026년 2월 20일 생성됐습니다. 이번에 처음 나온 도구라기보다 최근 다시 관심을 받는 프로젝트로 보는 것이 맞습니다. 10월 16일 12:32 UTC에 확인한 GitHub 누적 별은 10,255개였습니다. 같은 시간대의 Trendshift 날짜별 집계는 15일 증가량 213개, 16일 371개를 표시했습니다. 16일은 진행 중인 날짜이며 집계 경계를 별도로 검증하거나 증가량을 직접 재측정하지 않았습니다. 이런 관심 신호가 결과의 정확성이나 도입 효과를 증명하지는 않습니다.

이 글의 질문은 기능 목록보다 좁습니다. “AI 소식이 많이 들어오는 날에도 우리 팀이 읽을 기술 해설을 브리핑에 남기려면 어떤 설정을 함께 봐야 할까?”입니다.

프로필, 카테고리, 표시 순서를 구별합니다

  • 프로필: 콘텐츠를 어떤 기준으로 분석하고 어떤 형식으로 설명할지 정합니다. 항목 하나는 프로필 하나로 처리됩니다.
  • 카테고리: 브리핑의 그룹별 개수를 제한할 때 쓰는 값입니다. RSS에서는 각 소스에 설정한 category가 항목의 메타데이터로 복사됩니다.
  • profile_order: 이미 선택된 항목을 프로필별로 묶어 보여 주는 순서입니다.

RSS 처리 코드는 profile과 metadata["category"]를 따로 저장합니다. 따라서 tech-blog 프로필을 지정했다고 자동으로 기술 해설용 개수 제한에 들어가지는 않습니다. 카테고리 그룹의 키를 tech-blog라고 적는 것만으로도 연결되지 않습니다. 그룹의 categories 배열에 실제 소스 카테고리 값이 들어 있어야 합니다.

또 profile_order에서 tech-blog를 맨 앞으로 옮겨도 탈락한 글이 되살아나지는 않습니다. 렌더러는 전달받은 항목을 묶은 뒤 이 순서로 정렬합니다. 읽는 순서를 바꾸는 설정입니다.

카테고리 상한 다음에 전체 상한이 적용됩니다

선택 파이프라인은 프로필별 점수 필터와 주제 중복 제거를 거쳐 최종 후보를 고릅니다. 주제 중복 제거는 프로필별로 진행되며 설정으로 끌 수 있습니다. 이어지는 개수 제한 코드의 핵심은 다음과 같습니다.

  1. 후보 전체를 분석 점수 내림차순으로 정렬합니다.
  2. 각 항목의 카테고리를 그룹에 연결합니다. 일치하지 않거나 카테고리가 없으면 기본 그룹으로 보냅니다.
  3. 그룹의 상한을 넘는 항목을 제외합니다.
  4. 남은 목록 앞에서 max_items개만 선택합니다.

프로필마다 점수 기준이 다르지만 마지막 선택에서는 숫자를 한 목록에 정렬합니다. 점수가 서로 다른 프로필 사이에서 교정된 중요도나 확률이라고 해석할 근거는 없습니다. 카테고리 상한은 팀의 읽기 비중을 조절하는 수단으로 보는 편이 낫습니다.

가상 팀의 하루 여섯 편 예산을 계산해 봅니다

먼저 분석과 점수 필터, 주제 중복 제거를 통과한 글 아홉 편이 있다고 가정하겠습니다. 실제 프로젝트의 평가 결과가 아니라 선택 규칙을 설명하기 위해 만든 값입니다.

  • AI 소식 A~F: 9.9, 9.6, 9.3, 9.1, 8.9, 8.7점. 소스 카테고리는 ai-release
  • 기술 해설 G와 H: Django 쿼리 해설 8.2점, 작업 큐 설계 해설 7.8점. 소스 카테고리는 backend-practice
  • 기타 I: 터미널 도구 소개 8.5점. 위 두 카테고리에 속하지 않음

전체 여섯 편, AI 최대 여섯 편, 기술 해설 최대 두 편, 기타 최대 한 편으로 설정하면 어떻게 될까요? 그룹별 상한을 거친 뒤에도 아홉 편이 남고, 전체 상한에서 A~F만 선택됩니다. 기술 해설의 “최대 두 편”은 채워야 하는 최소 수량이 아니기 때문입니다.

이 팀이 원하는 비중을 AI 최대 세 편, 기술 해설 최대 두 편, 기타 최대 한 편으로 바꾸면 합계가 여섯 편이 됩니다. 같은 합성 후보에서는 A·B·C, G·H, I가 남습니다. 선택 목록의 점수순은 A·B·C·I·G·H이고, 이후 프로필 표시 순서는 따로 적용됩니다.

아래는 기존 data/config.json에 병합할 문서 검토용 설정 발췌입니다. 모델과 소스 등 전체 실행 설정은 포함하지 않았으며 Horizon에서 실행하지 않았습니다. JSON 문법만 별도로 확인했습니다.

{
  "digest": {
    "max_items": 6,
    "profile_order": ["tech-blog", "tech-news"],
    "category_groups": {
      "ai_updates": {
        "limit": 3,
        "categories": ["ai-release"]
      },
      "engineering": {
        "limit": 2,
        "categories": ["backend-practice"]
      }
    },
    "default_group": "other",
    "default_group_limit": 1
  }
}

이 발췌를 쓰려면 AI 소식 RSS의 category를 ai-release로, 기술 해설 RSS의 category를 backend-practice로 지정해야 합니다. 기술 해설을 tech-blog로 분석할지도 각 소스의 profile에서 별도로 정합니다. 실제 소스 값과 그룹 연결을 한 줄씩 대조하는 것이 먼저입니다.

이 구성에서 얻는 보장은 제한적이지만 명확합니다. 기본 그룹까지 모든 그룹에 유한한 상한을 두고, 그 합을 전체 상한 이하로 맞추면 마지막 전체 개수 제한 때문에 추가로 잘리는 항목은 없습니다. 그룹 안의 경쟁, 잘못된 분류, 앞 단계의 필터까지 해결해 주는 조건은 아닙니다.

여섯 편이 채워지지 않아도 먼저 원인을 봅니다

  1. 카테고리가 빠진 경우: 위 예시에서 G와 H의 카테고리를 빠뜨리면 둘 다 기본 그룹으로 갑니다. 기타 I의 8.5점이 더 높으므로 기본 그룹 한 자리는 I가 차지합니다. AI 세 편과 I, 총 네 편만 남습니다. 기술 해설 그룹의 상한을 늘려도 연결되지 않은 항목에는 적용되지 않습니다.
  2. 점수 기준을 넘지 못한 경우: 카테고리가 정상이어도 기술 해설 프로필의 기준을 8점으로 올리면 7.8점인 H는 앞 단계에서 제외됩니다. 기술 해설 최대 두 편이라는 설정이 H를 복원하지 않으므로 이 예시에서는 다섯 편이 남습니다.
  3. 기본 그룹이 무제한인 경우: default_group_limit을 생략하거나 null로 두면 미분류 항목이 많아질 수 있습니다. 설정한 두 그룹의 합만 보고 전체 상한과 비교해서는 안 됩니다.

설정 모델에서 개수 한도는 양수이고, 허용되는 null은 제한을 두지 않는 뜻입니다. 한도를 0으로 넣어 그룹을 끄는 설정은 유효하지 않습니다. 카테고리를 여러 그룹에 중복으로 넣으면 설정 순서상 첫 그룹이 사용되므로 중복도 함께 확인해야 합니다.

빈자리를 다른 그룹에서 자동으로 채우거나 매일 기술 해설을 반드시 두 편 보장해야 한다면, 이 상한 설정만으로는 요구를 충족하지 못합니다. 읽을 글이 적은 날은 짧게 끝낼지, 별도 선택 규칙을 둘지 팀이 먼저 결정해야 합니다.

도입 전에 읽기 비용과 운영 비용을 따로 봅니다

Horizon은 MIT 라이선스이며 소스 설정은 Python 3.11 이상을 요구합니다. 확인 시점 GitHub Releases는 비어 있었고 0.1.0은 소스 메타데이터의 버전입니다. 공식 시작 안내는 저장소를 받아 의존성을 설치하는 방식과 Docker 방식을 제공합니다. PyPI의 horizon은 별개의 OpenStack Dashboard 프로젝트이므로 이름만 보고 설치하면 안 됩니다.

여섯 편 제한은 사람이 읽을 양을 줄이는 장치입니다. 처리 순서상 수집과 초기 AI 분석은 최종 개수 제한보다 먼저 일어납니다. 따라서 최종 여섯 편이 모델 호출 여섯 번이나 일정한 요금 상한을 뜻하지 않습니다. 보강 단계에 들어가는 항목은 줄일 수 있지만 실제 비용과 절감액은 모델, 입력량, 재시도와 검색 사용에 따라 확인해야 합니다.

공급자 설정에 따라 콘텐츠와 관련 입력이 외부 모델 서비스로 전달될 수 있습니다. 비공개 RSS나 내부 문서를 넣기 전에는 전달할 정보와 공급자의 처리 조건을 확인해야 합니다. 로컬 모델을 선택하더라도 수집과 웹 검색까지 모두 오프라인이 되는 것은 아닙니다. 한국어 출력 품질도 이 글에서는 검증하지 않았습니다.

여러 소스를 꾸준히 읽고 뉴스와 기술 해설에 다른 기준을 적용하려는 팀이라면 검토할 만합니다. 읽는 피드가 몇 개뿐이고 직접 고르는 데 큰 부담이 없다면 기존 RSS 리더의 폴더나 읽기 목록으로 시작해도 됩니다. 반드시 정해진 비율을 채워야 하는 요구라면 상한 방식과 별도로 최소 수량·부족분 처리 규칙을 설계해야 합니다.

처음 평가할 때는 기존 설정을 보관하고 자동 게시·메일·웹훅 등 외부 전달을 꺼 둔 상태에서 결과 파일을 검토하는 편이 좋습니다. 소스별 카테고리, 통과한 후보 수, 최종 선택 수, 빠진 이유를 함께 적고 원문과 대조합니다. 구성이 맞지 않으면 이전 설정으로 돌리고 기존 읽기 목록을 계속 쓰면 됩니다. 이는 권장 평가 절차이며 실제 실행을 마쳤다는 뜻은 아닙니다.

핵심은 상한의 합과 연결 관계입니다. 프로필로 분석 기준을 정하고, 소스 카테고리로 읽을 양을 나누고, 표시 순서로 읽기 편하게 정렬합니다. 이 세 가지를 구별하면 “설정에는 기술 글 두 편인데 결과에는 없다”는 상황을 훨씬 구체적으로 점검할 수 있습니다.

댓글

댓글 쓰기