AI에게 문서를 맡기고 “끝나면 스스로 점검해 줘”라고 덧붙이면, 돌아오는 점검표는 대개 전부 ‘지킴’입니다. 표는 반듯하고 근거 칸도 채워져 있습니다. 그런데 다른 눈으로 다시 보면 빠진 것이 나옵니다. 스스로는 결함을 0건 찾았는데, 남이 보니 있었던 겁니다.
AI에게 문서를 맡기고 “끝나면 스스로 점검해 줘”라고 덧붙이면, 돌아오는 점검표는 대개 전부 ‘지킴’입니다.
저도 그 일을 겪었고, 오늘 앞선 글에 기록했습니다. “BABOK 기법으로 요구사항을 뽑은 AI는, 자기 판단의 결함을 한 건도 찾지 못했습니다”라는 글입니다. BABOK은 국제 비즈니스 분석 협회가 펴낸 비즈니스 분석 지식 체계입니다. 그 글에서는 무엇이 일어났고 어떻게 바꿨는지를 적었습니다. 다만 한 가지는 답하지 못했습니다. 같은 AI가 왜 자기 결과에는 관대한가 하는 것입니다.
그 답을 가장 짧게 설명해 준 강연이 있어 정리합니다. 2026년 7월 AI Engineer World's Fair에서 Diogo Almeida가 한 18분짜리 발표입니다. 그는 GPT-4, ChatGPT, InstructGPT 논문의 공저자이고, 지금은 Jev라는 제품을 만드는 TypeSafeAI의 대표입니다.
너무 잘하는 일과 너무 못하는 일 사이에 선이 하나 있었습니다
발표는 질문 하나로 시작합니다. AI는 미해결 수학 문제를 풀고 코딩 에이전트로 일하는데, 고객 상담이나 데이터 입력처럼 훨씬 쉬워 보이는 일에는 여전히 사람이 붙어 있습니다. 무엇이 이 둘을 가를까요.
그의 답은 이렇습니다. 왼쪽 일들은 곁에서 결과를 받아 보는 사람을 만족시키는 것이 목표이고, 오른쪽 일들은 그 사람을 빼는 것이 목표라는 겁니다. 그는 이 곁의 사람을 ‘루프 안의 사람’이라고 부르며, “왼쪽 일의 목표는 루프 안의 사람을 기쁘게 하는 것”(04:21)이라고 말합니다. 왼쪽을 돕는 일(assistance), 오른쪽을 맡기는 일(automation)로 나누면, 지금의 AI는 왼쪽에 강하고 오른쪽에 약합니다. 이것이 그가 정리한 첫 번째 교훈입니다.
사람이 좋아할 답을 고르도록 훈련됐기 때문이었습니다
원인으로 그가 드는 것은 RLHF(사람 피드백 강화학습)입니다. 사람에게 두 답 중 어느 쪽이 나은지 고르게 하고, 모델이 사람이 고를 법한 답을 내도록 훈련하는 방식입니다. 그의 말로는 지금 쓰이는 언어 모델은 사실상 전부 이 과정을 거칩니다(05:52).
그는 이 방식의 목적을 이렇게 요약합니다. “루프의 목표는 사람의 선호에 맞추는 것이지, 소프트웨어를 스스로 돌리는 것이 아닙니다.”(06:40) 사람이 고르는 기준은 ‘맞는 답’이 아니라 ‘나아 보이는 답’입니다. 둘이 대개는 겹치지만, 갈리는 자리에서 모델은 나아 보이는 쪽을 배웁니다.
사람이 느낀 효과와 실제 결과가 반대로 나왔습니다
그는 이 간극을 보여 주려고 METR라는 연구 기관의 2025년 실험을 가져옵니다. 숙련 오픈소스 개발자 16명이 AI 도구를 쓰기 전에는 작업 시간이 24% 줄 거라고 예상했고, 다 쓰고 난 뒤에도 20% 빨라졌다고 느꼈습니다. 실제로 잰 작업 시간은 19% 늘었습니다. 경제 전문가와 머신러닝 전문가의 예측도 모두 빨라지는 쪽이었습니다.
이 실험 자체는 사람이 AI의 효과를 과대평가했다는 결과입니다. 발표자는 여기서 한 걸음 더 나아가 해석합니다. 사람의 선호로 훈련된 모델은 쓰는 사람에게 좋은 인상을 남기는 쪽으로 다듬어지고, 그래서 느낌과 결과 사이에 늘 간극이 생긴다는 겁니다. 슬라이드 제목 “Overpromising is a feature”는 그 해석을 담은 말입니다. 실험이 이 인과까지 입증한 것은 아니고, 발표자의 설명이라는 점은 구분해 둡니다.
바로 이어서 그가 보여 준 예시입니다. 모르는 것을 받으면 모델은 사람이 좋아할 쪽으로 답합니다. 그는 이것을 고장이 아니라 RLHF가 가르친 그대로라고 설명합니다.
제 자가 점검이 0건이었던 이유가 여기 있었습니다
그가 정리한 두 번째 교훈에는 부연이 한 줄 달려 있습니다. “모델이 아무리 틀려도 맞아 보인다.”(08:14)
이 문장을 보고 앞선 글의 숫자를 다시 읽었습니다. 저는 BABOK의 문서 분석 기법으로, AI에게 가상의 채용 회사 엑셀과 인사 규정을 분석하게 했습니다. AI가 산출물 끝에 붙인 자가 점검표는 규칙 다섯 칸이 모두 ‘지킴’이었습니다.
같은 산출물을 같은 AI의 새 대화에 다시 보였습니다. 다른 모델도 사람도 아니고, 달라진 것은 만든 대화의 맥락을 전혀 모른다는 점 하나였습니다. 이 검사자는 규칙 다섯 개 중 1개를 못 지켰다고 봤고, 이틀 뒤 같은 지시로 다시 돌렸을 때는 2개로 봤습니다.
두 번 모두 잡힌 결함은 조항마다 잣대가 달랐다는 것이었습니다. 인사 규정 세 조항은 모두 엑셀에 지켜지는지 확인할 기록이 없다는 같은 처지였습니다. AI는 그중 두 조항을 판정할 수 없다며 요구사항에서 빼고 ‘확인 필요’로 미뤘는데, 기록 보존 기간 조항만은 요구사항으로 올렸습니다. 보존 대장이 있는지 모른다고 스스로 ‘확인 필요’에 적어 두고서였습니다. 규정의 “파악하여 전형에 반영할 수 있다”를 요구사항에서 “파악한다”로 옮겨, 재량을 의무로 바꾼 문장도 있었습니다.
같은 주에 PMBOK(프로젝트 관리 지식 체계) 프로세스로 넓혀, 이해관계자 식별과 리스크 분석과 일정 도출 같은 일을 가상 자료로 일곱 번 돌렸습니다. 그중 여섯 번은 자가 점검이 스스로 찾은 불일치가 0건이었고, 나머지 한 번은 2건이었습니다. 따로 세운 검사자는 일곱 번 모두 무언가를 찾았습니다.
막힌 곳: 처음에는 점검 규칙이 부족해서라고 생각했습니다. 그래서 0건이 나오면 원천을 다시 세어 보라는 규칙까지 넣었습니다. AI는 그 규칙도 따랐고, 원천 엑셀의 열 16개를 다시 세어 전부 맞는다고 적었습니다. 세는 일은 실제로 맞았습니다. 조항마다 다른 잣대를 댄 판단은 여전히 스스로 걸리지 않았습니다.
여기서 원인을 둘로 나눠 둡니다. 하나는 같은 대화의 맥락입니다. 같은 대화 안의 AI는 방금 한 판단의 이유를 그대로 기억하고 있으니, 그 판단이 점검할 때도 똑같이 그럴듯해 보입니다. 다른 하나는 강연이 말한 훈련 성향입니다. 나아 보이는 답으로 기울도록 훈련된 모델에게 자기 결과를 채점하게 하면, 채점도 나아 보이는 쪽으로 기웁니다.
제 실험이 보여 준 것은 앞쪽뿐입니다. 바꾼 조건이 맥락 하나였고, 그것만으로 결과가 달라졌습니다. 훈련 성향이 얼마나 보탰는지는 제 실험으로 가를 수 없습니다. 강연은 그 뒤쪽 원인에 대한 설명이고, 저는 그 설명이 제 숫자와 어긋나지 않는다는 데까지만 말할 수 있습니다.
세기와 판단과 결정을 다른 손에 맡긴 방식을 강연에 비춰 봤습니다
앞선 글에서 제가 바꾼 것은 사실 세 갈래였습니다. 셀 수 있는 것, 즉 열 개수와 건수는 제 스크립트로 셉니다. 세는 일은 AI도 맞게 했지만, 스크립트는 나아 보이는 쪽으로 기울 여지가 아예 없습니다. 그래서 열 하나를 일부러 지운 사본을 만들어, 스크립트가 16이 15로 줄어든 것을 곧바로 잡는지부터 확인해 두었습니다. 판단이 필요한 것은 맥락을 모르는 새 대화의 검사자에게 보입니다. 두 번 돌려 겹친 결함은 고치고, 한 번만 나온 결함은 제가 원문을 열어 직접 봅니다. 어느 쪽이든 고칠지 말지는 제가 정합니다.
그때는 경험으로 나눈 것이었습니다. 강연의 설명이 맞다면, 이렇게 나눈 데에는 이유가 하나 더 붙습니다. 맥락을 떼어 낸 검사자는 맥락 쪽 원인은 끊지만, 훈련 성향은 만든 쪽과 같은 모델이니까요. 그렇다면 검사자 한 명으로 끝내지 않고, 기울 여지가 없는 세기는 스크립트에, 기울 수 있는 판단의 마지막 결정은 사람에게 두는 편이 맞습니다.
아직 남은 문제: 검사자도 나아 보이는 쪽으로 기울 수 있습니다
맥락을 끊으면 ‘방금 내린 판단 편들기’는 끊깁니다. 하지만 ‘그럴듯하게 쓰는 성향’까지 끊기는지는 확인하지 못했습니다. 실제로 따로 세운 검사자를 두 번 돌렸을 때, 핵심 결함은 둘 다 잡았지만 부차적인 판정은 회차마다 달랐습니다.
강연자의 주장에도 선을 그어 둡니다. 그는 다음 시대가 자동화를 목표로 훈련한 모델의 시대가 될 거라고 말하고, 자기 회사가 그 일을 한다고 소개합니다. 그 방향이 맞는지는 제가 판단할 수 있는 영역이 아닙니다. 제가 가져온 것은 그 앞 단계의 설명, 지금 모델이 무엇을 목표로 훈련됐는가 하나입니다.
마치며: ‘맞아 보이나’가 아니라 ‘누가 봤나’
AI 결과물이 반듯해 보이는 것은 품질의 증거가 아니었습니다. 강연의 설명대로라면 반듯해 보이도록 훈련된 결과이기도 합니다. 적어도 자가 점검표의 ‘지킴’은 같은 손, 같은 대화에서 나온 문장이었습니다.
AI에게 문서를 맡기고 있다면, 다음 번에는 “스스로 점검해 줘”를 빼고 일을 둘로 나눠 보시길 권합니다. 숫자와 건수는 원천, 즉 처음 받은 자료에서 직접 셉니다. 엑셀이라면 COUNTA 함수 하나로도 충분합니다. 판단은 새 대화를 열어 산출물과 원천 자료, 점검 기준만 붙여 넣고 보게 합니다. 이것을 대화를 새로 열어 한 번 더 합니다. 두 번 모두 나온 지적은 고치고, 한 번만 나온 지적은 원문을 열어 직접 확인합니다. 어느 쪽이든 고칠지는 사람이 정합니다.
강연 원본은 18분이고, 03:14부터 08:47까지만 봐도 이 글의 뼈대가 다 들어 있습니다.
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
- Diogo Almeida, “Jev CEO: I made ChatGPT, now I'm building what's next”, AI Engineer, 2026: https://www.youtube.com/watch?v=cJ0EOzey--o
- Joel Becker 외, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, METR, 2025: https://arxiv.org/abs/2507.09089