LLM 심판 에이전트와 함께한 사내 이슈 찾기 대회: AI 판정을 시도하며 배운 것

들어가며

안녕하세요. 노머스에서 HoE(Head of Engineering)를 맡고 있는 오상아입니다. 얼마 전 사내에서 이슈 찾기 대회를 열었습니다. 특정 아티스트의 구독자가 늘어났을 때 fromm 서비스에 발생할 수 있는 이슈를 코드를 기반으로 찾는 대회였습니다. 23명이 참여해 총 208건의 이슈를 제출해 주셨습니다.

이슈 찾기 “대회”인 만큼, 어떤 이슈가 실제로 의미 있는지 검증하고 순위를 매겨야 했습니다. 문제는 이 심사를 저 혼자 해야 한다는 것이었습니다. 208건을 하나씩 읽는 데만 상당한 시간이 필요했습니다. 게다가 이슈의 타당성과 영향도를 판단하려면 해당 코드를 직접 열어 확인하는 것은 물론, 그 코드가 왜 그렇게 구현되었는지에 대한 히스토리와 백엔드·프론트엔드 양쪽의 지식이 함께 필요했습니다. 그래서 AI에게 심사를 맡겨보기로 했습니다. 그런데 예상과 다른 문제가 생겼습니다. 208건을 중복 제거한 141건 중, AI가 ‘이슈가 아니다’라고 판단한 것은 단 한 건도 없었습니다. 같은 141건을 사람이 직접 검토했을 때는 59건, 42% 를 제외했습니다. 왜 이런 차이가 생겼을까요? 이 글에서는 이슈 판정 과정을 AI 파이프라인으로 만들면서 어떤 부분을 잘못 설계했는지, 무엇을 시도했고 왜 실패했는지, 그리고 결국 어떤 방식으로 바꾸었는지를 공유해보겠습니다.

우리가 판정하려던 ‘이슈’의 정의

먼저, 이번 대회에서 정의한 ‘이슈’ 는 단순히 기존 코드에 존재하는 결함을 말하는 것은 아니었습니다. 트래픽이나 구독자 증가로 인해 실제 문제가 될 가능성이 있고, 이번 검토 범위에서 수정할 가치가 있는 문제를 찾는 것이 목적이었습니다.

따라서 다음과 같은 제출물은 이슈로 인정하지 않았습니다.

• 트래픽 증가와 관계없는 기존 버그
• 이번 검토 범위에 포함되지 않는 영역 (예: 내부 운영 도구)
• 거의 일어나지 않는, 특수한 조건이 겹쳐야만 성립하는 문제
• 이미 의도적으로 선택한 설계
• 이번에 수정할 필요가 없거나 정책상 제외하기로 한 문제

이 글에서는 이런 항목을 편의상 ‘허수’라고 부르겠습니다.

초기 파이프라인 설계

전체 파이프라인은 다음과 같이 구성했습니다.

단계	역할
① 수집·정제	자유 형식 제출물 → 동일한 필드 구조로 변환
② 중복 취합	208건 → 141개 고유 이슈
③ 카테고리	6개 영역 중 하나로 분류
④ 분류 심판	채점표에 따라 1차 판정
⑤ 검증 심판	④의 점수를 보지 않고 독립적으로 재채점
⑥ 재조정	제출자별 심각도 평가를 대표값 하나로 정리
⑦ 보강	담당 팀·기술 태그·영향 범위 부여

제출물은 기본적으로 구글 폼으로 받았지만 일부는 docx나 md 파일로 전달되었습니다. 따라서 첫번째 단계로 자유 형식의 제출물을 동일한 필드 구조로 정했습니다. 그 다음에 중복을 제거해 208건을 141개 고유 이슈로 묶었습니다. 그리고 나서 카테고리를 분류하고, 두 개의 심판 에이전트가 채점하고, 마지막에 담당 팀과 기술 태그를 붙였습니다.

여기서 중요한 것은 두 심판 에이전트입니다. 하나의 에이전트에게 판정과 검산을 모두 맡기면 같은 대화 안에서 자신의 판정을 다시 반박하게 만들기 어려웠습니다. 그래서 분류 심판은 이슈 원문만 보고 채점하고, 검증 심판은 원문과 분류 심판의 판정 근거를 전달받되 점수는 보지 않고 다시 채점하도록 나눴습니다.

두 심판은 같은 채점표를 사용했습니다. 이 이슈가 실제로 성립하는지, 성립한다면 얼마나 큰 문제인지를 네 항목으로 나누고, 각 항목을 0~3점으로 평가해 총 12점으로 계산했습니다.

항목	3점을 주는 경우	0점을 주는 경우
구체성	실제 시스템이나 기능을 명확히 지목	어느 서비스에나 붙는 일반론
규모 연관성	구독자·트래픽 증가가 직접 원인임이 설명됨	규모와 무관한 문제를 억지로 끼워 넣음
인과 타당성	문제가 되는 메커니즘이 기술적으로 타당	기술적으로 성립하지 않음
실재성	실제 존재하는 것에 기반, 지어낸 내용 없음	없는 기능을 지어냄 / 이미 해결된 이슈

합계 9점 이상은 진짜 이슈, 4~8점은 보류, 3점 이하는 허수로 판정했습니다. 실재성이 0점이면 합계와 관계없이 허수로 처리했습니다. 여기서 보류는 사람이 한 번 더 확인해야 하는 이슈를 뜻합니다. 두 심판의 등급이 일치하면 그대로 확정하고, 갈리면 사람이 직접 보도록 했습니다.

사내 과거 장애 리포트에서 추출한 허수 전형 6종과 진짜 이슈 전형 11종도 예시로 함께 제공했고, 프롬프트에는 이렇게 적었습니다.

관대하게 통과시키지 말 것. 근거 없는 일반론은 허수다.

결과는 이랬습니다. 141건 중 진짜 이슈가 126건, 보류가 15건, 허수는 0건이었습니다. 처음에는 심판 에이전트가 너무 관대하다고 생각했지만, 채점 결과를 항목별로 뜯어보니 문제는 모델의 성향만이 아니었습니다.

왜 아무것도 탈락하지 못했는가

1. 네 항목 중 셋이 사실상 고정값이었다

먼저 각 항목의 점수 분포를 확인했습니다.

항목	평균	표준편차	최빈값 비중
구체성	2.98	0.14	98%
인과 타당성	2.92	0.27	92%
실재성	2.82	0.42	83%
규모 연관성	2.28	0.85	50%

구체성은 141건 중 138건이 3점을 받았습니다. 생각해보니 당연했습니다. 제출자들 모두 코드의 파일 경로와 줄 번호까지 적어 근거로 제출했습니다. 채점표에서는 실제 시스템이나 기능을 명확히 지목하면 구체성 3점을 주도록 했는데, 파일 경로가 적혀 있으니 이 조건은 거의 자동으로 만족했습니다. 인과 타당성도 마찬가지였습니다. 코드를 직접 읽고 작성한 이슈라면 기술적인 메커니즘 설명은 대부분 타당했습니다. 결국 점수가 갈린 것은 규모 연관성 하나였습니다. 네 항목짜리 채점표를 만들었다고 생각했지만, 실제로는 한 항목짜리 채점표에 가까웠던 것이었습니다.

2. 허수 판정은 애초에 도달할 수 없었다

문제는 점수의 분포만이 아니었습니다. 허수의 기준을 합계 3점 이하로 설정했는데, 구체성에서 이미 138건이 3점을 받았습니다. 이 138건이 허수가 되려면 나머지 세 항목이 모두 0점이어야 합니다. 그런데 인과 타당성이 0점인 항목도, 실재성이 0점인 항목도 0건이었습니다.

실제 점수 분포는 이랬습니다.

합계	12	11	10	9	8	7	6점 이하
건수	57	49	19	11	4	1	0

최저점이 7점이었습니다. 허수 커트라인인 3점 근처에 온 이슈조차 없었고, 허수 구간을 0~5점으로 넓혀보아도 결과는 같았습니다. 아무리 프롬프트에 “엄격하게 판정하라”고 적어도 채점표 자체가 허수라는 결과를 만들 수 없는 구조였습니다.

3. 그런데 에이전트는 이미 문제를 짚고 있었다

에이전트가 문제를 전혀 발견하지 못한 것도 아니었습니다. 한 이슈는 규모 연관성을 1점으로 평가하면서 근거에 이렇게 적었습니다.

코드로 위치를 특정했으나 트리거가 구독 직후 권한 반영 지연이라 규모 연관성은 약함

사람도 이 이슈를 트래픽과 무관하다는 이유로 제외했습니다. 그런데 나머지 세 항목이 모두 3점이라 총점은 10점으로 진짜 이슈로 판정되었습니다.

전체적으로도 같은 경향이 보였습니다. 사람이 규모와 무관하다는 이유로 제외한 18건의 평균 규모 연관성 점수는 1.67점이었고, 사람이 채택한 82건은 2.37점이었습니다. 다만 이 한 항목만으로 사람의 판정을 예측할 수는 없었습니다. 규모 연관성이 3점인 이슈 중에서도 34%는 사람이 제외한 이슈였기 때문입니다.

에이전트는 규모 연관성을 1점으로 낮게 매겨 문제를 짚어두었지만, 네 항목을 합산하는 순간 그 정보가 총점에 묻혀 저희가 정의한 이슈를 알아보기 힘들게 만들었습니다.

세 번의 시도: 심판을 더 엄격하게 만들기

처음에는 심판 에이전트를 더 엄격하게 만들면 된다고 생각했습니다.

1. 프롬프트에 숨어 있던 편향 제거하기

검증 심판의 프롬프트를 다시 읽다가 제가 직접 넣은 문장을 발견했습니다.

특히 허수 판정을 집중적으로 재확인한다. 진짜 이슈를 실수로 버리는 것이 대회 공정성에 가장 치명적이기 때문이다.

억울하게 탈락하는 사람이 없어야 한다는 의도로 넣은 문장이었지만, 한쪽으로만 기울어진 지시였습니다. 그래서 진짜 이슈와 허수를 모두 같은 강도로 재확인하도록 수정했습니다.

결과는 꽤 크게 움직였습니다. 다시 채점한 33건 중 17건이 진짜 이슈에서 보류로 내려왔습니다. 하지만 허수로 내려간 것은 한 건도 없었습니다.

엄격하게 만들면 탈락이 늘어날 것이라고 생각했는데, 실제로는 보류가 늘어났습니다. 탈락시키려면 왜 허수인지 근거를 제시해야 하지만, 보류는 “판단하기 어렵다”고 쓰면 되기 때문입니다.

2. 판단 보류를 없애기

그렇다면 중간 선택지를 없애면 어떨까 싶었습니다. 진짜 이슈와 허수 중 하나를 반드시 고르도록 했습니다. 141건 중 3건이 탈락했습니다. 그런데 그 3건은 모두 사람이 채택한 이슈였습니다. 애매한 판단을 없애자 아예 점수를 위로 밀어 올렸습니다. 이런 현상은 앞서 카테고리 분류에서도 경험했습니다. 카테고리에서 ‘기타’를 없애자 애매한 이슈는 가장 가까운 카테고리로 분류되었습니다. 선택지를 지우니 애매한 판단이 옆으로 옮겨갈 뿐이었습니다.

3. 하위 25%를 강제로 탈락시키기

마지막으로 점수 하위 25%를 무조건 탈락시키도록 했습니다. 141건 중 36건이 잘렸고, 그중 사람도 제외한 것은 16건, 정확도로는 44%였습니다. 그런데 사람이 전체 141건 중 42%를 제외했으니, 36건을 무작위로 골라도 약 15건은 맞힐 수 있습니다. 통계적으로 검정해보아도 무작위 선택과 구분되지 않았습니다. 자르는 건수만 늘었을 뿐, 자동 판정의 품질은 좋아졌다고 보기 어려웠습니다.

세 가지 처방에는 공통점이 있었습니다. 모두 심판 에이전트를 더 엄격하게 만드는 방법이었습니다. 그런데 문제를 다시 들여다보니 원인은 채점의 강도가 아니라 판정 과제 자체였습니다.

네 번째 시도: 질문을 바꾸기

정리해보니 에이전트와 사람이 서로 다른 질문에 답하고 있었습니다.

저는 처음에 AI에게 “이 결함이 실제로 존재하는가?”를 물었습니다.
하지만 사람이 실제로 판단하고 있던 질문은 “이것이 이번 주제에 맞는 이슈인가? 그리고 이번에 고칠 만한 사항인가?”였습니다.
AI가 판단을 못한 것이 아니라, 처음부터 다른 질문을 풀고 있었습니다.

사내 개발자가 실제 코드를 읽고 작성한 이슈이기 때문에 첫 번째 질문에는 대부분 “그렇다”고 답할 수 있습니다. 하지만 대회의 목적은 두 번째 질문에 답하는 것이었습니다.

그래서 사람이 실제 심사에서 사용했던 질문 네 개를 그대로 모델에게 물어보기로 했습니다.

1. 규모 비례성 — 부하가 10배가 되면 이 결함의 피해도 10배가 되는가, 아니면 부하와 상관없이 늘 같은 크기인가?

2. 발생 조건 — 평범하게 운영하다 보면 일어나는가, 아니면 특수한 조건이 여러 개 겹쳐야만 성립하는가?

3. 의도성 — 몰라서 그렇게 만든 것인가, 아니면 알고 선택한 트레이드오프로 보이는가?

4. 영역 — 이번 검토 범위인 팬 대상 서비스에 해당하는가?

하나라도 통과하지 못하면 제외하도록 했고, 보류 등급은 두지 않았습니다. 사람의 판정을 이미 알고 있는 상태에서 제가 직접 채점하면 답을 외운 채 시험을 보는 것과 같기 때문에, 판정은 별도의 에이전트가 수행했습니다. 이 에이전트에는 이슈 목록과 채점 기준 파일만 전달하고 사람의 최종 판정은 전달하지 않았습니다.

결과는 이전보다 나아졌습니다. 141건 중 49건을 제외했고, 그중 29건은 사람도 제외한 이슈였습니다.

하지만 사람이 제외한 이유별로 보면 편차가 컸습니다.

사람이 제외한 이유	건수	잡아낸 비율
규모·트래픽과 무관	18	78%
검토 영역 밖	10	90%
발생 가능성 낮음	10	30%
범위·정책상 제외	16	13%
의도된 구현	5	20%

규모 비례성을 물었으니 규모와 무관한 이슈를 78% 잡아낸 것은 예상할 수 있는 결과였습니다.

검토 영역 밖을 90% 잡아낸 것은 모델의 판단력으로 얻은 숫자가 아니었습니다. 범위 밖 영역의 이름을 목록으로 적어줬기 때문에 모델은 목록과 대조하기만 하면 됐습니다.

전체로는 사람이 제외한 59건 중 29건, 49%를 잡아냈습니다. 그런데 이 29건 가운데 9건은 모델이 판단한 것이 아니라 목록과 대조해서 걸러낸 것입니다. 답을 미리 알려준 영역 관련 이슈를 통째로 빼고, 모델이 스스로 판단해야 했던 나머지만 놓고 보면 맞힌 비율은 41%로 내려갑니다.

아무도 잡지 못한 25건

이렇게 보니 네번째 시도는 어느 정도 유효했습니다. 그럼에도 불구하고 사람이 제외한 59건 중, 네 번의 시도 어느 것으로도 걸러지지 않은 이슈가 25건이었습니다.

그중 11건은 범위·정책상 제외였습니다. 타임아웃 정책 자체를 이번 분기에 다루지 않기로 한 것, AWS 장애에 함께 죽는다는 식의 이슈는 받지 않기로 한 것, 근본적인 개선이 필요하지만 이번에는 손대지 않기로 한 것 같은 판단들이었습니다.

의도된 구현 4건도 모두 알고 선택한 설계였습니다. 고정 주기 폴링이나 조회 건수 상한처럼 코드만 보면 전형적인 규모 리스크로 보이지만, 실제로는 트레이드오프를 따져서 고른 구현이었습니다. 사람이 이런 이유로 제외한 이슈들은 채택된 이슈보다 AI의 점수와 확신도가 오히려 높았습니다.

이 25건에는 공통점이 있었습니다. 판단 근거가 제출한 이슈 설명에는 없었던 것입니다. 코드에도 없고, 문서에도 없고, 회의에서 합의한 내용도 기록되어 있지 않았습니다.

같은 설계가 여러 사람에게서 반복해서 이슈로 제출되었다는 것은, 왜 그렇게 만들었는지가 충분히 기록되어 있지 않다는 뜻이기도 합니다. 저희는 이 25건을 심사에서 제외했지만, 다른 관점에서 보면 설계 결정 문서가 필요하다는 신호로 볼 수도 있었습니다. AI가 판단하지 못한 원인 중에는 조직 안에 존재하는 판단 근거가 기록되어 있지 않다는 문제도 있었습니다.

다시 한다면 어떻게 할 것인가

이 대회는 일회성 행사였고 심사는 이미 끝났습니다. 그래서 이 파이프라인을 지금도 돌리고 있지는 않습니다.

다만 지금 다시 파이프라인을 설계한다면, 처음부터 두 가지를 먼저 확인했을 것입니다.

첫째, 평가 기준이 실제 데이터에서 충분한 판별력을 갖는지입니다. 10~20개 정도의 샘플에 먼저 적용해 점수가 어떻게 분포하는지, 각 기준이 진짜 이슈와 허수를 제대로 구분하는지 살펴봤을 것입니다.

둘째, AI에게 판단을 맡기기 전에 사람이 실제로 어떤 질문에 답하고 있는지 정의했을 것입니다. 사람이 여러 조건을 종합해 판단하고 있다면 그 조건을 AI가 답할 수 있는 질문으로 구체화해야 합니다. 반대로 단순히 특정 목록에 포함되는지를 확인하는 문제라면, AI의 판단에 맡기기보다 별도의 조회나 비교 단계로 분리하는 편이 적절하다는 것을 알게 되었습니다.

그럼에도 불구하고 AI에게 최종 결정을 모두 맡기지는 않을 것 같습니다.

네 번째 방식을 그대로 쓰면 사람의 검토량을 141건에서 92건으로 35% 줄일 수 있었지만, 사람이 채택한 82건 중 20건을 함께 버리게 됩니다. 검토 시간 35%를 아끼기 위해 진짜 이슈 네 건 중 한 건을 놓치는 것이 더 위험하다고 생각합니다.

대신 AI의 결과는 검토 순서를 정하는 데 활용하는 편이 더 효율적일 것 같습니다. 141건을 모두 사람이 확인하되, AI가 규모 비례성이나 발생 조건을 기준으로 정리한 결과를 함께 놓고 추가 확인이 필요한 이슈부터 살펴보는 방식입니다.

이렇게 생각하게 된 까닭은, 사람이 실제로 던지는 질문을 그대로 전달하자 AI의 출력 형태가 달라지는 것을 관찰했기 때문입니다. 통과와 탈락을 결정하는 데서 그치지 않고, 각 이슈를 네 가지 질문에 비추어 어떻게 봐야 하는지까지 정리해주었습니다. 최종 결정을 맡기기에는 여전히 위험하지만, 검토 기준을 적용하고 우선순위를 정리하는 역할이라면 충분히 활용할 수 있겠다고 보았습니다.

마치며

처음에 저는 심판 에이전트가 관대한 것이 문제라고 생각했고, 프롬프트를 고쳐 쓰는 데 대부분의 시간을 썼습니다. 편향된 문장을 지우고, 보류를 없애고, 하위 25%를 강제로 잘라봤지만 탈락 목록의 품질은 달라지지 않았습니다. 결과가 실제로 움직인 것은 채점표를 버리고 사람이 심사에서 던지던 질문을 그대로 물어봤을 때였습니다.

AI 자동화를 설계할 때 중요한 것은 더 강하게 지시하는 것이 아니라, 내가 실제로 어떤 결정을 자동화하려는지 먼저 정의하고 그 판단을 어떤 질문으로 바꿀 것인지 설계하는 것이라는 걸 다시금 알게 되었습니다.

읽어주셔서 감사합니다.