AI 분류가 나빠진 걸 어떻게 알아챌까요?

메모앱을 만들고 있어요. 떠오르는 걸 아무렇게나 적어두면 나중에 "정리하기"를 눌렀을 때 AI가 메모를 읽고 어느 보관함에 넣을지 알아서 골라주는 앱이에요.

AI한테 주는 지시문은 지금까지 대여섯 번쯤 고쳤는데, 고칠 때마다 하는 확인이라곤 제가 메모 서너 개 넣어보고 "음 잘 되네" 하는 게 전부였어요. 그러다 문득 이런 생각이 들었어요. 지난주에 고친 것 때문에 뭐가 나빠졌으면 저는 그걸 알 수 있나?

알 수 없었어요. 테스트는 50개나 있는데 그중에 AI를 실제로 부르는 게 하나도 없었거든요.

// 테스트를 시작할 때 도는 코드
delete process.env.OPENAI_API_KEY;

AI 열쇠를 지우고 시작해요. 일부러 그렇게 해뒀어요. 열쇠가 없으면 AI를 안 부르고 그냥 기본 보관함에 넣도록 짜뒀으니까, 테스트를 돌릴 때마다 돈 내고 외부 서비스를 두드릴 이유가 없어서요. 그 50개는 남의 메모가 제 화면에 보이지 않는지, 정리하다 실패하면 메모가 사라지지 않고 제자리로 돌아오는지 같은 걸 지켜줘요. 다 중요한데, 전부 "약속한 대로 도는가"에 대한 것뿐이라서 분류가 슬금슬금 나빠지는 일에 대해서는 아무 말도 해주지 않아요.

채점 기준을 어떻게 잡을까요

잘 되던 게 나빠진 걸 알아채려면 비교할 기준선이 있어야 하는데, 여기서 막혔어요. AI는 같은 메모를 같은 상황에서 두 번 물어봐도 두 번 다 같은 답을 준다는 보장이 없어요. 그러니까 평소 테스트하듯이 정답을 적어놓고 다르면 실패로 처리하게 만들면, 제가 코드를 하나도 안 건드려도 어제는 통과하고 오늘은 실패하는 일이 생겨요. 그건 알림이 아니라 소음이고, 소음이 몇 번 반복되면 사람은 그 테스트를 안 보게 돼요.

그래서 하나하나 통과/실패를 매기는 걸 그만두고 점수로 바꿨어요. 메모마다 세 번씩 시켜서 몇 점인지 내고, 그 점수를 파일에 적어서 코드와 함께 저장해둬요. 다음에 뭘 고치고 다시 돌리면 이렇게 나와요.

정답률 0.964 → 0.923 ▼0.041 · 흔들림 1 → 6 ▲5

빨간불 초록불 대신 어느 쪽으로 움직였는지를 봐요. 그리고 정답률 옆에 "흔들림"을 같이 찍게 해뒀는데, 세 번 다 틀린 메모는 그냥 어려운 메모지만 세 번 중 한 번만 틀린 메모는 그 자리가 위태롭다는 뜻이라서 개인적으로는 이 숫자가 더 쓸모 있었어요. 나중에 AI 모델을 바꾸거나 보관함이 늘어나면 제일 먼저 무너질 곳이 거기일 것 같아요.

채점해야 할 상대가 둘이었어요

앉아서 문제지를 만들기 시작하니까 우리 앱에서 분류를 하는 쪽이 하나가 아니라는 게 걸렸어요.

하나는 앱 안의 AI예요. 메모 본문이랑 보관함 이름 목록을 주고 하나 고르게 하는 흔한 방식이고, 여기서 제가 손댈 수 있는 건 지시문 정도예요.

다른 하나는 밖에서 들어오는 AI예요. 우리 앱은 Claude 같은 AI 비서가 직접 붙을 수 있는 통로를 열어뒀어요. 사용자가 자기가 쓰던 AI한테 "오늘 적어둔 것들 좀 정리해줘"라고 시키면 그 AI가 우리 앱에 접속해서 메모를 담고 꺼내고 정리해요. 이쪽엔 우리 AI를 아예 안 붙여놨는데, 붙는 상대가 이미 AI라서 메모 본문만 보는 우리 것보다 사정을 훨씬 잘 알거든요. 그러니까 이 경우 분류하는 건 우리가 아니라 손님 쪽 AI고, 우리가 고치다 망가뜨릴 수 있는 건 그 AI한테 보여주는 설명문뿐이에요.

나빠지는 모양이 서로 달라서 채점 방법도 달라야 했어요. 앞쪽은 엉뚱한 보관함을 고르는 식으로 나빠지고, 뒤쪽은 있지도 않은 보관함 이름을 지어내거나 사용자한테 "이건 어디에 넣을까요?"를 되묻고 멈추는 식으로 나빠져요.

정답을 하나로 못 박으면 안 되더라고요

문제지를 쓰다가 바로 걸린 게 있어요. "스프린트 끝. 이번엔 배포가 유난히 느렸다"는 메모는 일/회고에 가야 할까요 일에 가야 할까요. 저도 그때그때 다를 것 같은데 정답을 하나로 박아두면, AI가 일을 골랐을 때 그건 오답이 아니라 그냥 제 채점이 까다로운 거예요.

그래서 문제마다 정답 하나와 "이것도 인정" 목록을 같이 뒀어요. 그리고 "ㅁㄴㅇㄹ" 같은, 사람이 봐도 판단이 안 되는 메모는 아예 기본 자리로 가는 게 정답이라고 적어뒀고요. 판단이 안 될 때 사용자한테 되묻지 않고 정해둔 자리에 넣는 게 이 앱의 규칙이라서요.

문제지의 진짜 주인공은 보관함 구성이었어요

이건 만들면서 제일 늦게 깨달았어요. 우리는 AI한테 보관함 이름 목록을 주고 그 안에서만 고르게 해요. 목록 밖의 이름은 답으로 낼 수조차 없게 막아뒀는데, 그러면 AI 앞에 놓인 선택지 전부가 그 목록인 셈이에요. 지시문을 아무리 다듬어도 목록 안의 두 칸이 뜻이 겹치면 그건 지시문으로 고칠 수 있는 문제가 아니에요.

우리 앱은 시작할 때 고를 수 있는 기본 템플릿을 여섯 개 줘요. 직군별로 하나씩인데 여섯 개가 같은 뼈대(할 일·아이디어·알게 된 것·읽을거리·보관)를 쓰면서 칸 한두 개만 바꿔요. 개발자는 이력서 재료가, 기획자는 들은 말이, 디자이너는 레퍼런스와 받은 피드백이 붙는 식이에요. 그러면 채점해야 할 건 공통 칸이 아니라 그 다른 칸이 자기 몫을 제대로 가져가는가가 돼요. 못 가져가면 그 칸은 목록만 길게 만들고 분류는 흐리는 셈이니까요.

그래서 여섯 템플릿을 전부 문제지에 넣고 템플릿별로 점수를 따로 냈어요. 이때 중요한 게 하나 있었는데, 채점용으로 보관함 구성을 베껴 적지 않고 앱이 실제로 쓰는 그 데이터를 그대로 읽어다 쓰는 거였어요. 사본을 두면 템플릿을 고쳐도 점수가 안 움직여서 애초 목적인 "나빠졌는지 알아채기"에 못 써요. (이거 처음엔 문제지 파일에 손으로 적어뒀다가 다시 뜯어고쳤어요.)

처음 매겨본 점수

문제 52개를 세 번씩, AI를 156번 부르는 데 80초쯤 걸렸어요.

정답률       92%      정답 1지망으로 맞힌 것   87%
흔들린 문제   6/52     기본 자리로 간 비율      17%

템플릿별
  기본 3칸 구성   100% (24/24)
  개발자          100% (12/12)
  디자이너        100% (12/12)
  기획자           83% (10/12)
  마케터           83% (10/12)
  일상             83% (10/12)
  연구·학습        75% ( 9/12)

직군마다 붙인 그 특별한 칸들은 오히려 다 멀쩡했어요. "이번 분기에 결제 모듈 마이그레이션을 혼자 끝냈다"는 이력서 재료로, "고객사 미팅에서 검색이 느리다는 말을 세 번 들었다"는 들은 말로, "무선 이어폰 새로 살까"는 사고 싶은 것으로 잘 갔어요. 걱정했던 쪽은 안 틀린 거예요.

틀린 걸 모아놓고 보니 다섯 중 넷이 같은 자리였어요.

"PMF 판단 기준에 대한 글 읽기"    읽을거리에 가야 하는데 → 할 일, 할 일, 읽을거리
"Attention 논문 다시 읽기"        읽을거리에 가야 하는데 → 할 일, 할 일, 할 일
"추천받은 소설 주말에 읽기"       읽을거리에 가야 하는데 → 읽을거리, 할 일, 할 일
"경쟁사 랜딩 카피 분석글 저장"    읽을거리에 가야 하는데 → 읽을거리, 보관, 보관

"읽기"로 끝나는 메모는 읽을거리가 아니라 할 일로 가요. 생각해보면 AI가 틀렸다고 하기도 애매한 게, "논문 다시 읽기"는 정말로 해야 할 일이에요. 두 칸이 서로 메모를 빼앗는 구조라 어느 쪽에 넣어도 사용자는 반대쪽을 뒤지게 될 것 같고, 이건 지시문을 고쳐서 될 일이 아니라 보관함 이름을 고쳐야 하는 일이에요. 이 얘기는 따로 한 편 더 썼어요.

확신 점수는 믿을 게 못 됐어요

AI는 답을 고를 때 자기가 얼마나 확신하는지를 0에서 1 사이 숫자로 같이 보고해요. 우리는 이 숫자가 낮으면 억지로 고르게 두지 말고 기본 자리로 보내자는 규칙을 만들어뒀고, 기준선을 0.5로 잡아뒀고요. 채점표에 이 숫자도 같이 찍게 해놨는데 처음 28문제로 돌렸을 때 이런 게 나왔어요.

확신 점수 평균   맞혔을 때 0.977 / 틀렸을 때 0.983
기준선을 0.1씩 옮겨봤을 때   0.0부터 0.9까지 전부 96%

맞았을 때랑 틀렸을 때가 구분이 안 되고, 기준선을 어디에 그어도 걸러지는 게 없어요. 규칙을 만들고 설정값까지 열어뒀는데 그게 아무 일도 안 하고 있었던 셈이에요. 문제를 52개로 늘린 지금은 맞음 0.982 / 틀림 0.898로 조금 갈리고 기준선을 0.7로 올리면 1~2%p 정도 좋아지긴 하는데, 이 정도 차이로 값을 옮길 자신은 없어요. AI가 자기 확신을 정직하게 말해줄 거라고 믿은 게 애초에 순진했던 것 같아요.

칸 개수에 대한 제 믿음도 하나 뒤집혔어요. 칸이 늘수록 확신이 떨어져서 오히려 다 기본 자리로 떨어질 거라고 코드에까지 적어뒀는데, 6칸짜리 템플릿들이 0.98~0.99를 받고 3칸짜리 기본 구성이 0.961로 더 낮았어요. 6칸까지만 확인한 거라 20칸에서 어떨지는 여전히 몰라서 상한 자체는 그냥 두기로 했어요.

손님 쪽 AI는 어떻게 채점할까요

두 번째 채점은 좀 다른 물건이 필요했어요. 우리 코드를 부르는 게 아니라 진짜 AI 비서가 밖에서 우리 앱에 접속해서 이것저것 시도하는 걸 지켜봐야 하니까, 앱을 실제로 띄워놓고 AI를 접속시킨 다음 대화를 끝까지 진행시키는 작은 장치를 만들었어요. 우리 앱이 손님한테 내미는 기능 설명문을 손대지 않고 그대로 AI한테 넘기고, AI가 "이 기능 써볼게"라고 하면 실제로 실행해서 결과를 돌려주는 게 전부예요.

AI한테 주는 사전 안내는 일부러 두 문장만 썼어요. 여기에 "정리를 꼼꼼히 해라" 같은 걸 적으면 우리가 채점하려던 것, 그러니까 우리 기능 설명문이 스스로 얼마나 잘 안내하는지가 가려지기 때문이에요.

채점은 AI가 뭐라고 말했는지가 아니라 데이터를 직접 열어서 해요. "8건 다 정리했습니다"라고 말해놓고 3건만 넣었을 수도 있으니까요. 그리고 맞혔는지만 보면 안 될 것 같아서 어떤 순서로 몇 번 시도했는지도 같이 봤어요. 설명문에 "한 번에 다 처리하라"고 써놨으면 그걸 지키는지가 곧 그 설명문의 품질이라고 생각해서요.

제자리에 넣은 비율   100% (24/24)
없는 이름 지어냄     0건
시도 순서            목록 보기 → 정리하기 (세 번 다 동일)

메모 8건을 정리시키면 목록을 한 번 보고 정리를 한 번에 몰아서 끝내요. 우리 트리에 아예 없는 주제(전세 계약, 김치찌개 레시피)만 담아놓고 시켜도 없는 이름을 지어내지 않고 있는 칸에 넣었고, 사람도 헷갈릴 이름들만 늘어놓은 트리에 애매한 메모만 넣고 "되묻지 말고 알아서 넣어줘"라고 하면 정말 안 되묻고 다 처리했어요.

여기서 고칠 거리는 안 나왔는데 대신 이 100%가 믿을 만한 100%가 아니라는 건 알게 됐어요. 처음 시험 삼아 돌렸을 때는 같은 상황에서 정리를 두 번에 나눠 했고 직전 실행에서는 24개 중 23개였으니까, 횟수를 늘리면 96%와 100% 사이를 오갈 것 같아요. 그러니까 이 숫자를 한 번 재고 기준선으로 박아두면 다음번에 아무것도 안 고쳤는데 4% 떨어진 걸 보고 범인을 찾으러 다니게 돼요. 몇 번 재서 나온 숫자인지를 같이 적어두고 몇 퍼센트까지는 그냥 흔들림으로 볼지 정해두는 게 다음 숙제예요.

아직 못 한 것들

손님 쪽 AI를 흉내 내는 데 쓰는 모델이 실제 사용자가 쓸 것과 달라요. 지금은 열쇠 하나로 두 채점을 다 돌리고 있어서, 남의 AI가 우리 설명문을 어떻게 읽는지를 또 다른 남의 AI로 대신 재고 있는 셈이에요. Claude로도 같은 걸 돌려보고 숫자가 갈리는지 봐야 하는데 아직 안 했어요.

문제 52개의 정답은 전부 제가 붙였어요. 그러니까 어떤 의미로는 이 채점표가 재고 있는 건 "AI가 저처럼 분류하는가"예요. 사용자들이 실제로 만든 보관함과 실제로 적어 넣은 메모를 보고 나면 정답이 꽤 바뀔 것 같아요.

그리고 이 채점을 자동으로 돌리지는 않기로 했어요. 느리고 돈이 들고 무엇보다 매번 조금씩 다른 숫자가 나오는 물건이라, 켜두면 사람이 곧 무시하게 될 것 같아서요. 뭘 고칠 때 손으로 돌리고 숫자가 어느 쪽으로 움직였는지만 보는 정도로 당분간 써보려고 해요.