ML과 LLM을 사용하여 Jira 백로그를 자동으로 관리하는 시리즈의 파트 2입니다. 파트 1 기사: How I Auto-Groomed 500 Jira Tickets with ML and LLM은 이 파트의 기반이 되는 기존 TF-IDF + Gemini 파이프라인에 관한 내용입니다.

파트 1에서 남겨둔 질문

파트 1을 놓친 분들을 위한 빠른 요약: 저는 Jira의 공개 API에서 500개의 실제 Apache ZooKeeper 티켓을 가져와 텍스트를 정제하고, TF-IDF와 K-Means를 실행하여 5개의 클러스터(cluster)를 생성한 뒤, 코사인 유사도(cosine similarity)를 통해 중복 가능성이 있는 항목들을 식별했습니다. 이는 어떤 ML 파이프라인이라도 수행할 수 있는 부분입니다. 흥미로운 부분은 2단계(Phase II)였습니다. 추출된 원시 클러스터와 중복 쌍들을 세 가지 선택적 가중치가 적용된 RAG 파일(프로젝트 컨텍스트, 릴리스 노트, 2026 로드맵 테마)을 기반으로 Gemini 2.5 Flash에 입력했습니다. 그 결과, 키워드 스프레드시트 대신 PM 권장 사항, 기간을 고려한 중복 호출, 그리고 요약 보고서가 포함된 명명된 클러스터 형태로 결과가 도출되었습니다.

하지만 저는 정확히 하나의 클러스터링(clustering) 방법과 하나의 LLM만을 사용하여 해당 파이프라인을 구축했으며, 다른 무엇과도 대조해 보지 않았습니다. 만약 Gemini의 클러스터 이름이 날카롭게 들렸다면, 그것은 Gemini가 일을 잘했기 때문일까요, 아니면 비교할 대상이 방 안에 아무것도 없었기 때문일까요?

이번 파트에서 답하고자 하는 질문이 바로 이것입니다. 하나의 파이프라인이 하나의 LLM에 데이터를 공급하는 대신, 저는 두 개의 클러스터링 파이프라인을 두 개의 LLM을 통해 실행하여 총 12개의 출력을 생성했고, 세 번째 LLM이 루브릭(rubric)에 따라 이 모든 것을 점수 매기도록 했습니다. 그 후 저 또한 동일한 12개의 출력을 직접 수동으로 점수 매겨 비교했습니다.

저는 이 비교를 통해 Claude와 GPT의 차이점을 알게 될 것이라 예상했습니다. 하지만 결과적으로는 더 유용한 사실, 즉 LLM 심판을 어디까지 신뢰할 수 있고 어디서부터 신뢰할 수 없는지에 대해 알게 되었습니다.

왜 두 개의 파이프라인과 두 개의 LLM인가

하나의 파이프라인은 기준점(baseline)을 제공하지 않습니다. 두 번째 클러스터링 방법과 두 번째 모델을 추가함으로써, 저는 두 가지 요소를 독립적으로 변화시킬 수 있게 되었습니다:

• 클러스터링 접근 방식(Clustering approach) — 문장 임베딩(sentence embeddings) 대 TF-IDF. 이 키워드가 밀집된 백로그에서 의미론적 임베딩이 실제로 도움이 될까요, 아니면 TF-IDF의 단순함만으로 충분할까요?
• LLM 자체 — 동일한 입력과 동일한 RAG 컨텍스트를 전제로 Claude Sonnet 4.5 대 GPT-5.5.

Part 1보다 움직이는 부분이 더 많지만, '파이프라인 A가 더 잘 클러스터링한다' 또는 'Claude가 오래된 티켓에 대해 더 나은 추론을 한다'와 같은 주장이 실제로 의미를 가지게 하려면, 단순히 발견처럼 포장된 일화(anecdote) 이상의 것이 필요하기 때문입니다.

작동 방식 (How It's Wired Together)

총 5단계가 있으며, 아래 제목의 다이어그램이 이를 보여주지만, 간단히 요약하면 다음과 같습니다:

Jira Backlog Analyzer Architecture2-updated

1. 두 개의 파이프라인, 동일한 입력. 동일한 500개 티켓 CSV가 독립적으로 파이프라인 A(문장 임베딩 → K-평균(K-Means) → 코사인 유사도(cosine similarity))와 파이프라인 B(TF-IDF → K-평균(K-Means) → 코사인 유사도(cosine similarity))를 거칩니다. 두 파이프라인 모두 K 값을 동일하게 결정했습니다. 즉, Part 1에서 고정했던 K=5를 재사용하는 대신 엘보우 방법(elbow method)과 실루엣 점수(Silhouette Score)를 사용했기 때문에, 클러스터 개수가 어느 방식에 대한 숨겨진 변수는 아니었습니다. 각 파이프라인은 자체적인 클러스터 세트와 중복 목록을 출력합니다.

2. 두 LLM 모두 두 파이프라인을 확인. 이 부분이 Part 1과 달라지는 지점입니다. Claude Sonnet 4.5는 먼저 파이프라인 A의 출력을 향상시키고, 그다음 파이프라인 B의 출력을 향상시킵니다. GPT-5.5도 마찬가지로 수행합니다. 즉, 매칭된 쌍(matched one)뿐만 아니라 두 파이프라인 모두를 처리합니다. 이 네 가지 조합 각각은 Part 1에서와 동일한 세 가지 결과물(artifacts)을 생성합니다: 개선된 클러스터 이름 및 설명, 개선된 중복 목록, 그리고 동일한 세 단계 RAG 설정(프로젝트 컨텍스트, 출시 노트, 2026년 테마)과 Part 1의 연령 분류를 기반으로 하는 PM 인사이트 보고서입니다.

두 개의 LLM, 두 개의 파이프라인, 각각 세 개의 결과물 — 총 12개의 출력물입니다. 각 LLM이 두 파이프라인을 모두 다루게 하는 것이 중요한 이유는, "LLM이 더 나은 PM 보고서를 작성한다"는 점과 "임베딩 (embedding) 파이프라인이 더 나은 원재료를 제공했다"는 점을 분리할 수 있기 때문입니다. 만약 매칭된 설계(Claude는 Pipeline A만 보고, GPT는 Pipeline B만 보는 방식)를 사용했다면 이 두 요인이 뒤섞였을 것입니다.

3. 중립적인 심판이 12개 모두를 평가합니다. Claude 및 GPT 제품군에 속하지 않는 Gemini 3.1 Pro가 다섯 가지 기준에 따라 모든 출력물을 평가합니다: 전략적 정렬 (Strategic Alignment), PM 권장 사항의 구체성 (PM Recommendation Specificity), 연령 인지 중복 추론 (Age-Aware Duplicate Reasoning), 클러스터 일관성 (Cluster Coherence), 그리고 데이터 합성 및 품질 (Data Synthesis & Quality). 모든 기준이 모든 출력물 유형에 적용되는 것은 아니므로 (예를 들어, 중복 목록은 당연히 클러스터 일관성 점수를 받지 않습니다), 각 출력물은 실제로 적용 가능한 분모를 기준으로 점수가 매겨집니다. 또한 평가 루브릭(rubric)은 Gemini에게 의심되는 환각 (hallucination)을 직접 표시하도록 요구하며, 의도를 추론하기보다는 명시적으로 존재하는 내용에 대해서만 점수를 매기도록 합니다. 이 규칙은 아래에서 설명하듯 매우 중요한 역할을 합니다.

저는 모델이 자신의 제품군을 편애하는 것을 제어하기 위해 Claude와 GPT가 서로의 출력물을 교차 심판하게 하는 것도 고려했습니다. 하지만 이번에는 생략했습니다. 12개의 출력물만 있는 상황에서 이는 제가 실제로 수행하고자 했던 실험과는 다른 (그리고 더 노이즈가 많은) 실험이 될 것이기 때문입니다. 제가 원했던 실험은 더 단순합니다: 어느 모델에도 이해관계가 없는 심판이 인간과 과연 일치하는가?

4. 저는 심판과 의견을 비교하기 전에, 동일한 루브릭을 사용하여 12개 모두를 직접 검토하고 점수를 매겼습니다.

5. 이 파이프라인의 후속 활용을 위한 최종 카피를 실제로 결정한 것은 심판의 원점수가 아니라 저의 검토 결과였습니다.

비교 결과가 실제로 보여준 것

핵심 요약: 저는 Gemini보다 두 모델의 작업 결과에 눈에 띄게 더 높은 점수를 주었습니다.

그 격차는 균등하게 분포되어 있지 않았습니다. 기준별로 세분화하면 다음과 같습니다:

가장 명확한 예는 임베딩 파이프라인에서 나온 GPT-5.5의 PM 통찰 보고서(PM Insight Report)에서 나타났습니다. Gemini는 이를 환각(hallucination)으로 표시하며, 소스 문서 어디에서도 찾을 수 없는 구체적인 수치들 — 예를 들어

(원시 수치를 원한다면, 두 모델의 모든 기준별 점수는 Github evaluations 폴더에 있습니다.)

심사관 프롬프트에 대한 참고 사항

제가 전체 심사관 프롬프트를 여기에 재현하지는 않겠습니다. 이것은 상당히 길고 엄격한 루브릭 문서이며, 기사에 붙여넣기 하는 것보다 실제로 복사하고 조정할 수 있는 리포지토리(repo)에 있는 것이 더 유용합니다. 요약하자면: Gemini에게 공정한 심사관 역할을 맡도록 지시했고, 다섯 가지 기준 각각에 대해 명확한 5/3/1 점수 기준점(scoring anchors)을 제공했으며, 어떤 기준이 어떤 출력 유형에 적용되는지 지정했고, 제가 예상했던 것보다 더 중요하게 작용한 규칙 하나를 포함했습니다. 바로 '명시적으로 존재하는 것만 점수를 매기고, 의도를 추론하지 말라'는 것입니다. 이 지침이야말로 심사관이 GPT-5.5가 도출한 수치를 '도출된(derived)' 것이 아닌 '지원되지 않는(unsupported)' 것으로 취급한 거의 확실한 이유입니다. 심사관은 자신이 받은 지시를 정확히 따랐을 뿐, 조금 너무 문자 그대로 해석했을 뿐입니다.

카파(Kappa)가 아닌 델타(Delta)

코헨의 카파(Cohen's Kappa)는 이러한 종류의 비교에 표준 도구이며, 제가 가장 먼저 살펴본 것이기도 합니다. 하지만 카파는 안정적이기 위해 충분한 시도가 필요하며, 1~5점 척도에서 모델당 6개의 출력이 있었기 때문에 신뢰할 수 없는 숫자가 나왔을 것입니다. 간단한 델타(delta) — 즉 기준별로 나의 점수에서 Gemini의 점수를 뺀 값 — 는 우아하지는 않았지만, 의견 불일치가 정확히 어디에 집중되어 있는지를 알려주었고, 이것이 실제로 중요했던 부분입니다.

여전히 인간이 필요한 이유

위의 GPT-5.5 환각(hallucination) 플래그가 사람이 개입해야 하는 전체 논거입니다. 그것은

심판은 분류(triage) 도구이지, 최종 판결(verdict)이 아닙니다. Gemini의 점수는 대부분의 경우 제 점수와 상당히 유사하게 추적되었으며, 잠재적인 문제를 빠르게 식별(flag)할 수 있을 만큼 충분히 훌륭했습니다. 하지만 특히 환각(hallucination) 판단에 있어서는 최종적인 결론을 내리기에는 충분하지 않았습니다.

불일치는 무작위로 발생하지 않았습니다. 단순 조회(lookup)가 아닌 추론(inference)을 필요로 하는 두 가지 기준에서 집중적으로 나타났습니다. 이는 해결 가능한 설계 문제입니다. 심판 모델이 단순히 소스 텍스트와 패턴 매칭(pattern-matching)만 하는 대신, 플래그를 달기 전에 숫자를 다시 도출(re-derive)할 수 있는 방법을 제공하면 됩니다.

교차 파이프라인(Cross-pipeline) 커버리지는 추가적인 설정의 가치가 있었습니다. 각 LLM이 두 파이프라인을 모두 다루게 함으로써, 엉킨 하나의 결과 대신 LLM과 파이프라인을 각각 분리하여 논할 수 있었습니다.

향후 계획

심판 모델에게 실제 계산기나 코드 도구를 제공하여, 숫자를 조작되었다고 판단하기 전에 직접 검증할 수 있도록 시도해보고 싶습니다. 또한, 더 크고 복잡한 백로그(backlog)에서도 이를 실행해보고 싶습니다. Kappa 계수를 다시 검토할 가치가 있을 만큼 충분한 출력물과, TF-IDF가 실제로 어려움을 겪을 수 있는 지점에서 임베딩(embedding) 파이프라인을 스트레스 테스트(stress-test)할 수 있을 만큼 충분한 다양성을 갖춘 데이터 말입니다. 인간의 검토를 경량화하는 버전도 가능해 보입니다. 모든 것을 수동으로 다시 점수 매기는 대신, 심판의 환각 플래그가 특정 숫자에 근거한 출력물만 골라 확인하는 방식입니다.

마무리

파트 1에서는 파이프라인이 작동할 수 있음을 보여주었습니다. 파트 2는 LLM이 그것이 얼마나 잘 작동하는지를 말해주는 것을 신뢰할 수 있는지에 관한 것이었습니다. 대체로 그렇습니다. Gemini의 점수는 방향성 측면에서 유용했으며 대규모로 생성하기에도 저렴했습니다. 하지만 Gemini는 올바른 추론을 날조(invention)로 지속적으로 오인했는데, 이는 바로 인간이 잡아내야 하는 조용하면서도 중대한 실수 유형입니다. PM(Product Manager)이 실제로 읽고 행동에 옮길 내용이라면, 이러한 검토는 선택 사항이 아닙니다.

코드, RAG 파일, 그리고 두 모델에 대한 전체 점수 테이블은 GitHub에서 확인할 수 있습니다.