저에게는 AI에 관련된 콘텐츠를 자동으로 수집하는 '콕집이'가 있습니다. 매일 유용한 ax-tip을 발굴해 슬랙으로 공유하는데요. 좋은 ax-tip을 발굴하기 위해서는 상당히 많은 양의 콘텐츠를 수집해야 합니다.
콕집이가 매일 슬랙으로 보내는 결과물. 위쪽 'AI NEWS'는 수집·요약, 아래쪽 'AX TIP'이 바로 골라낸 실습감(ax-tip)이에요.
그런데 요약은 나오지만 그게 좋은지 나쁜지 판단할 기준이 없었어요. 프롬프트를 바꿔도 "나아진 것 같다"는 감일 뿐, 실제로 나아졌는지 확인할 수단이 없었어요.
요즘 많이 보이는 키워드인 '루프 엔지니어링'을 콕집이 품질 개선에 활용해보고 싶었어요! 마침 좋은 원문(Full Product Evaluation Loop)을 발견해서, 이걸 틀로 삼기로 했죠.
로나에 원문을 주고 맞춤 실습을 요청했습니다. rubric-driven-self-improvement-loop라는 자가 개선 루프 실습을 만들어줬는데, 그 실습은 "콕집이엔 채점 장치가 없다"는 전제로 짜여 있었어서 제가 중간중간 변경하긴 했습니다.
로나가 준 스킬을 바탕으로 클로드 코드로 실제 레포를 읽히면서 3시간을 파보니 결론은 명확했어요. "eval이 안 된다"고 느낀 문제의 정체는 로나가 가정한 것과 달랐고, 사람 피드백이 거의 0건인 상황에서도 봇이 스스로 좋아지는 자가 개선 루프를 설계까지 끝낼 수 있었어요.
그래서 loop 엔지니어링이 뭔데?
AI한테 일을 시킬 때 보통은 이렇게 해요. 프롬프트를 한 번 잘 써서 결 과를 받고, 마음에 안 들면 프롬프트를 또 손보고. 매번 사람이 눈으로 보고 고치는 방식이죠. 문제는 이게 사람 손과 감에 계속 의존한다는 거예요. 봇이 100개를 처리하면 100개를 다 들여다볼 수도 없고요.
loop 엔지니어링은 이 과정을 사람이 매번 끼지 않아도 돌아가는 한 바퀴(loop)로 만드는 것이에요. "결과를 내고 → 스스로 채점하고 → 약한 곳을 고치고 → 다시 돌린다"를 시스템이 알아서 반복하게 짜는 거죠. 사람은 매 건을 보는 대신, 그 바퀴가 잘 돌게 설계하는 데로 역할이 옮겨가요.
이 글에서 만든 자가 개선 루프는 그 loop 엔지니어링의 한 종류예요. 그중에서도 "AI 결과물의 품질을 채점해서 끌어올리는" 평가용 루프죠. 틀은 아래 Full Product Evaluation Loop에서 그대로 가져왔어요.
기준이 된 틀: Full Product Evaluation Loop
이 작업은 즉흥이 아니라 Full Product Evaluation Loop를 틀로 삼았어요. 원문은 "실제 시나리오로 모든 주요 기능을 평가하고, 고친 뒤 다시 돌린다"를 5단계로 정의해요.
환경 구축 — 실제와 비슷한 데이터로 테스트할 판을 만든다
목록화 — 평가할 기능과 경우를 빠짐없이 적고, 각각의 통과 기준을 정한다
테스트 실행 — 실제 사용자처럼 하나씩 돌려보고, 실패는 증거와 함께 기록한다
원인 분석·수정 — 한 건씩 땜질하지 않고 공통 원인부터 묶어 한꺼번에 고친다
재실행·검증 — 고친 뒤 전체를 다시 돌린다
원칙은 두 가지예요. 목록을 끝까지 적어 빠뜨리는 기능을 없앨 것, 고치기 전에 원인을 묶어서 볼 것. 멈추는 시점도 명확해요. 전체를 다시 돌려 모두 통과하면 종료(clean pass), 진행이 막히면 중단이에요.
이 5단계 틀을 콕집이에 하나씩 끼워 맞췄어요. 원문이 "이런 단계로 하라"고 한 걸, 콕집이에선 각각 무엇에 해당하는지로 바꿔 끼운 거죠.
무엇을 평가할지(목록) → 콕집이에 이미 있던 6개 평가 항목을 그대로 씀
어떻게 채점할지(통과 기준) → 5가지 기준으로 점수를 매기는 R1~R5 채점
점수가 낮으면 왜 그런지(원인 분석) → 원인을 "프롬프트 / 데이터 / 선별 / 척도" 4가지 유형으로 분류
언제 끝낼지(멈춤 조건) → "통과율 80% 이상 + 사실 오류 0건"이면 완료(clean pass)
쉽게 말하면, 남이 만든 5단계 설명서를 내 봇에 맞게 부품을 갈아 끼운 거예요.
문제는 이 루프의 심장인 "자동 채점"이 콕집이에서 제대로 안 돌고 있었다는 점이었어요.
1단계: 레포를 직접 읽혔더니 — 로나가 가정한 것과 달랐다
로나 실습은 "콕집이엔 채점 장치가 없으니 처음부터 만들자"는 전제였어요. 저도 그 말을 그대로 믿고 시작했죠. 채점 기준을 맨땅에서 만들 생각이었어요.
여기서 로나가 모르던 부분이 드러났어요. 로나는 제 깃 레포 안을 들여다볼 수 없거든요. 그래서 외부에서 보이는 정보만으로 "없을 것"이라 가정한 거예요. 이 가정이 맞는지는 제가 직접 확인해야 했어요.
그래서 클로드 코드에게 레포를 직접 열게 했더니, 답이 바뀌었어요.
레포를 봤더니, 이미 6개짜리 평가 시스템이 돌고 있어요.eval이 없는 게 아니라 이미 있었어요. 그것도 꽤 정교하게. 6개 평가 중 일부는 통과(PASS), 일부는 실패(FAIL) 상태로 전부 기록돼 있었어요.
첫 번째 결론은 분명했어요. "eval이 안 된다"고 느낀 건 eval이 없어서가 아니라, 있는데 헛돌고 있어서였어요.
진단표가 진짜 문제를 드러냈어요. FAIL 난 "매칭 정확도"의 원인은 사용자 피드백 누적 2건이었어요. 통계 자체가 불가능했죠. 좋아요나 싫어요가 안 들어오니, 그걸 정답으로 삼는 평가는 영원히 FAIL일 수밖에 없었어요.
2단계: "피드백은 영원히 안 온다" — 정답을 교체하다
여기가 작업의 전환점이었어요.
클로드 코드는 "피드백을 더 모으는" 방향으로 루프를 짜려 했어요. 하지만 봇을 운영해본 입장에서 결론은 분명했어요. 그 피드백은 영원히 안 들어와요. 사람들은 좋아요를 안 눌러요.
그래서 방향을 틀었어요.
피드백은 영원히 안 들어올 거고,
콕집으로 선정된 애들이 그나마 가치 있다고 볼 수 있을 듯콕집이는 콘텐츠 중 "실습으로 만들 만큼 가치 있다"고 판단한 걸 따로 선정해요. 클로드 코드가 레포를 더 파보니, 그 선정 기준이 이미 점수로 DB에 저장되 고 있었어요. 두 달 전 제가 직접 설계한 시스템이었고요.
결론은 간단했어요. 안 들어오는 피드백을 기다릴 게 아니라, 슬랙으로 공유된 콘텐츠는 양질의 콘텐츠라고 판단할 수 있었어요. 사람이 라벨링(어느 게 정답인지 일일이 표시해주는 작업)을 한 건도 안 해도 정답지가 공짜로 생기는 구조죠. 이렇게 완벽하진 않아도 공짜로 얻어지는 정답을 '약한 라벨(weak label)'이라고 해요.
이 지점이 AI 협업의 핵심이었어요. 클로드 코드는 코드를 빠르게 읽고 구조를 파악하지만, "이 신호는 죽었으니 저걸 쓰자"는 판단은 봇을 직접 굴려본 사람만 할 수 있어요.
3단계: 5가지 채점 기준 + 원인을 가르는 규칙
정답을 바꾸자 나머지는 빠르게 풀렸어요. 클로드 코드와 함께 잡은 세 가지예요.
1. 채점 기준을 3개에서 5개로. 그동안 콕집이는 글을 채점할 때 3가지만 봤어요. 사실이 정확한지, 핵심을 잡았는지, 간결한지. 그런데 정작 중요한 2가지가 빠져 있었어요. "읽는 사람 업무에 맞게 개인화됐나", 그리고 "ax-tip으로 뽑을 만한 가치가 있나"요. 이 둘을 더해 5개로 만들었어요. 채점기가 정말 중요한 걸 빠뜨리고 있었으니까요.
2. 점수가 낮으면, 원인부터 가려내기. 보통 결과가 별로면 "프롬프트가 문제겠지" 하고 프롬프트부터 손대요. 하지만 점수가 낮은 이유는 여러 가지예요. 원문 자료 자체가 부실했거나, 콕집이가 콘텐츠를 잘못 골라왔거나, 채점 기준이 틀렸거나. 원인마다 고치는 방법이 다른데 무작정 프롬프트만 바꾸면 헛수고죠. 실제로 콕집이의 가장 약한 지점은 프롬프트 로는 못 고치는 문제였어요. 엉뚱한 데 손대지 않으려고 원인을 먼저 분류한 거예요.
3. 새로 만들지 않고, 있던 걸 키우기. 채점 장치를 새로 만들 수도 있었지만, 콕집이엔 이미 채점 스크립트가 있었어요. 그래서 그걸 3축에서 5축으로 늘리기만 했어요. 새로 만들면 똑같은 걸 두 군데서 관리하게 되거든요.
실제로 돌려봤다 — 그리고 설계가 경고한 함정이 그대로 나왔다
설계만으로 끝내면 공허하니, 콕집이 실제 DB에 붙여 eval을 한 번 돌렸어요. 콕집이가 실제로 골라냈던 양질의 글 6개에 안 골라낸 글 6개, 총 12개를 채점기한테 매기게 했죠. 채점기가 제대로라면 골라낸 6개엔 높은 점수, 안 골라낸 6개엔 낮은 점수를 줘야 해요. 그게 되는지 본 거예요. 결과는 솔직히 신통치 않았고, 그게 오히려 핵심 교훈이었어요.
표 읽는 법: 채점기가 좋은 글과 나쁜 글을 잘 가려내는지 본 결과예요. 숫자가 나쁠수록 "채점기가 둘을 구분 못 한다"는 뜻입니다.
무엇을 봤나
실측
쉽게 해석
채점 기가 "골라낼 글"이라 한 게 실제와 맞은 비율
55%
절반만 맞음 = 찍기 수준
채점기 점수와 콕집이 실제 점수가 같이 움직이는 정도 (1이면 일치, 0이면 무관)
0.22
거의 따로 놂
"개인화" 항목 — 12개 글에 매긴 점수
전부 4점
다 똑같음 = 좋고 나쁨 못 가름
"톤" 항목 — 12개 글에 매긴 점수
전부 5점
다 똑같음 = 좋고 나쁨 못 가름
한마디로, 채점하는 AI(이걸 'judge', 채점관이라고 불러요)가 좋은 글이든 그저 그런 글이든 거의 다 같은 점수를 줬어요. 둘을 못 가른 거죠. 그래서 "이건 골라낼 글"이라고 맞히는 정확도가 55%, 사실상 찍기였어요.
그런데 이건 설계 단계에서 이미 경고했던 함정이에요. "judge가 중앙값으로 몰린다"는 거였죠. 채점관이 자신 없을 때 4점·5점 같은 무난한 점수만 주고 1점·2점은 안 줘서, 결국 다 비슷해 보이는 현상이에요(중앙값 편향). 설계가 예측한 위험이 실측에서 그대로 재현된 거예요. 덕분에 다음 할 일이 분명해졌어요. 채점관한테 '이건 선정감, 이건 아님' 하는 실제 예시를 몇 개 보여줘서 기준을 잡아주는 거예요. 이렇게 예시로 기준을 잡아주는 걸 few-shot이라고 해요. 이게 다음 한 바퀴의 출발점이에요.
자가 개선 루프의 진짜 가치가 여기 있었어요. 안 돌려봤으면 "rubric 만들었으니 됐다"고 착각했을 텐데, 한 번 돌리니 "채점기 자체가 아직 못 믿을 상태"라는 게 숫자로 드러났어요. 측정이 없으면 이걸 영영 몰랐겠죠.
결과
설계 9개 문서에 실제 eval 1회까지 돌렸어요. 가장 크게 바뀐 건 수치가 아니라 사고방식이었어요.
Before: "eval이 안 되네"(막연함) → After: "정답 신호가 죽어 있었다 + 채점기도 아직 못 믿는다"(숫자로 진단)
Before: 감으로 "좋아진 것 같다" → After: R5 정확도 55%·상관 0.22처럼 약점을 수치로 특정
Rona를 사용해서 좋았던 점은, 원문 자체에 eval 내용이 많아서 엄두가 안 났는데 Rona에게 자세한 설명을 요청하니 차근차근 알려준 거예요. 리서치 경험이 적어도 누군가의 방법론을 따라해볼 수 있다는 게 참 좋았어요.
AI 활용 팁!
콕집이뿐 아니라 AI 봇이나 자동화를 운영하는 누구에게나 적용돼요.
품질이 의심되면, 봇보다 측정 기준을 먼저 의심하세요. 봇이 별로인 게 아니라 좋고 나쁨을 가를 기준이 없는 경우가 더 많아요.
사람 피드백을 기다리지 마세요. 좋아요나 별점은 거의 안 들어와요. 이미 시스템에 쌓이는 신호(선정 여부, 클릭, 저장)를 정답 대용으로 쓰세요.
AI에게 "내 시스템부터 직접 읽어"라고 시키세요. 맨땅에서 만들게 하면, 이미 있는 걸 놓치고 헛수고만 늘어요.
이 글은 로나(Rona)가 만들어준 맞춤 실습을 출발점으로, 클로드 코드와 함께 AI 큐레이션 봇에 자가 개선 루프를 설계한 실제 기록입니다. 오늘은 설계까지, 실제 코드 적용은 다음 단계예요.
Sources
