AI는 왜 메모를 엉뚱한 보관함에 넣을까요?

메모앱을 만들고 있어요. 떠오르는 걸 아무렇게나 적어두면 나중에 "정리하기"를 눌렀을 때 AI가 그 메모를 읽고 어느 보관함에 넣을지 알아서 골라주는 앱이에요. 보관함이라는 건 그냥 메모가 모이는 칸이고, 시작할 때 할 일·아이디어·알게 된 것·읽을거리·보관 같은 칸 몇 개를 기본으로 줘요.

문제는 이 AI가 종종 엉뚱한 데 넣는다는 거였는데, 그럴 때마다 저는 AI한테 주는 지시문을 열어서 설명을 좀 더 또렷하게 쓰고 예시를 하나 붙이고 "애매하면 이렇게 해라"를 덧붙이곤 했어요. 그렇게 여섯 번쯤 고쳤는데 나아졌는지 어쨌는지는 사실 잘 몰랐어요. 메모 서너 개 넣어보고 "음 이제 되네" 하는 게 검증의 전부였으니까요.

그래서 제대로 재보기로 했는데, 메모 52개를 쓰고 정답을 손으로 붙인 다음 AI한테 세 번씩 시켜서 몇 개나 맞히는지 세는 방식이라 손이 좀 갔지만 적어도 나아졌는지 아닌지는 숫자로 보여요. 그런데 틀린 걸 모아놓고 보니 다섯 개 중 넷이 같은 자리에서 나고 있었어요.

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

읽을거리 칸과 할 일 칸이 서로 메모를 빼앗고 있었어요. 그리고 이걸 보자마자 든 생각은 AI가 틀렸다고 하기가 좀 애매하다는 거였는데, "논문 다시 읽기"는 읽을거리이면서 동시에 진짜로 해야 할 일이라서요. 사람한테 시켜도 반반으로 갈릴 것 같아요.

지시문을 고쳐도 안 되는 이유

AI한테 분류를 시키는 방식을 좀 설명해야 할 것 같아요. 우리는 AI한테 메모 본문이랑 보관함 이름 목록을 같이 주고 "이 목록 안에서 하나만 골라라"라고 시키는데, 목록 밖의 이름은 아예 답으로 낼 수 없게 막아뒀고 그건 안 막아두면 있지도 않은 칸 이름을 지어내서 뱉을 때가 있기 때문이에요.

그래서 AI 앞에 놓인 선택지는 그 목록이 전부예요. 지시문은 어떻게 고를지를 말해주고 목록은 무엇을 고를 수 있는지를 정해요. 목록 안에 정답이 두 개 들어 있으면 지시문이 아무리 친절해도 하나를 골라낼 방법이 없어요. 이 경우가 딱 그랬어요.

칸 이름이 서로 다른 걸 재고 있었어요

할 일과 읽을거리를 나란히 놓고 보면 둘이 애초에 같은 종류의 이름이 아니에요. 할 일은 제가 그 메모를 가지고 할 행동이고, 읽을거리는 그 메모가 가리키는 물건이에요. 재는 잣대가 다른 두 칸을 나란히 두면 "물건은 글이고 행동은 읽기인 메모"는 양쪽 다 맞는 답이 되고, 그런 메모는 처음부터 갈 자리가 두 개인 셈이에요.

기본으로 주는 칸들을 이 관점으로 다시 늘어놓으니 이렇게 됐어요.

아이디어와 알게 된 것은 서로 안 겹치는데, 떠올린 것과 배운 것은 같은 잣대 위의 다른 값이라 하나를 고르면 다른 하나는 자동으로 아니게 되기 때문이고, 반면 할 일은 혼자 잣대가 다르다 보니 나머지 칸들과 조금씩 다 겹쳐요. 실제로 읽을거리에서만 새는 게 아니라 아이디어로 갈 만한 메모("리퍼럴 프로그램 한번 해볼까")가 할 일로 새는 것도 있었어요.

비슷한 걸 한 번 겪었어요

AI가 도저히 못 정하겠을 때 메모를 보내는 칸이 하나 필요해요. 우리는 그걸 기본 자리라고 부르고 보관이라는 이름을 붙여뒀는데, 처음엔 나중에로 하려고 했었어요. 근데 만들다가 그만뒀어요. 나중에라는 이름이 "언젠가 해보고 싶다" 같은 메모를 할 일한테서 빼앗아 가기 때문이었고, 사람도 그 메모가 할 일인지 나중에인지 모르는 걸 AI한테 고르라고 시키면 매번 다르게 고를 수밖에 없거든요.

기본 자리에 쓸 이름은 뜻이 비어 있어야 한다는 걸 그때 배웠는데, 정작 같은 눈으로 읽을거리를 보지는 못했어요. 여섯 개 기본 템플릿 중 다섯 개에 들어 있는 흔한 칸이라 의심할 생각을 아예 안 했던 것 같아요. (디자이너용 템플릿에서만 그 자리를 레퍼런스로 바꿔뒀는데, 그때 코드에 적어둔 이유가 "뜻이 겹쳐서 둘 다 두면 분류가 흔들린다"였어요... 알고 있었으면서.)

칸을 많이 두는 건 생각보다 문제가 아니었어요

AI는 답을 고를 때 자기가 얼마나 확신하는지를 0에서 1 사이 숫자로 같이 보고해요. 저는 칸이 많아질수록 이 확신 점수가 낮아질 거라고 믿고 있었고, 코드 주석에 "칸이 늘면 확신이 떨어져서 오히려 다 기본 자리로 떨어진다"고까지 적어뒀어요. 재보니 그렇지 않았어요.

칸 3개짜리 기본 구성      확신 0.961
칸 6개짜리 개발자 템플릿  확신 0.988
칸 6개짜리 연구용 템플릿  확신 0.989

칸이 두 배인 쪽이 오히려 더 확신했어요. 물론 6개까지만 확인한 거라 20개나 50개가 되면 어떨지는 여전히 모르고, 칸 개수 상한은 다른 이유로도 필요해서 그대로 두기로 했어요. 다만 칸을 하나 더 둘지 말지 고민할 때 "많아져서 흐려지지 않을까"를 걱정하는 건 순서가 틀렸다는 건 알게 됐어요. 그보다 먼저 볼 건 새 칸이 기존 칸과 겹치는지예요.

그래서 지금 쓰는 검사

칸을 하나 늘리거나 이름을 바꿀 때 이 세 개를 봐요. 대단한 건 아니고 위에서 데인 걸 그대로 질문으로 바꾼 것뿐이에요.

첫째, 두 칸 이름을 나란히 놓고 "양쪽 다 맞는 메모"를 지어보는데, 30초 안에 하나라도 지어지면 그 둘은 겹치는 거라서 방금 지은 그 메모를 바로 평가용 목록에 집어넣어요. 할 일과 읽을거리는 "논문 다시 읽기"로 5초 만에 지어졌어요.

둘째, 칸 이름들이 다 같은 잣대인지 봐요. 성격이면 다 성격, 물건이면 다 물건이어야 해요. 하나만 행동이면 그 칸이 나머지 전부와 조금씩 겹쳐요.

셋째, 기본 자리 이름을 소리 내어 읽고 "이 이름 때문에 여기 가고 싶어지는 메모"가 떠오르는지 봐요. 떠오르면 그 이름은 기본 자리에 못 써요.

아직 안 정한 것

읽을거리를 어떻게 할지는 못 정했어요. 그냥 없애면 읽을 것들이 할 일 칸에 섞여 쌓일 테고, 이름을 링크·자료처럼 물건 쪽으로 더 밀면 겹침은 줄겠지만 사용자한테 딱딱하게 들릴 것 같아요. 반대로 할 일을 해야 할 일로 좁히는 것도 생각해봤는데 그건 그것대로 티가 안 날 것 같고요.

셋 다 후보로만 적어두고 하나씩 바꿔가며 다시 재볼 생각이에요. 어느 쪽이 나은지 감으로 정하지 않아도 된다는 게 이번에 얻은 거의 유일한 소득이라서, 이번만큼은 숫자 보고 정하려고 해요. 사용자들이 직접 만든 칸 이름들을 보게 되면 이런 겹침이 훨씬 더 많이 나올 것 같기도 하고요.