12부 66장. 평가 없이는 왜 발전하지 않는가

AI를 조금만 오래 써 보면 이상한 경험을 한다. 분명히 더 열심히 다듬고 있는데, 정말로 나아지고 있는지는 잘 모르겠다. 프롬프트를 고쳤고, 예시도 붙였고, 모델도 바꿨다. 체감상 뭔가 좋아진 것 같기도 하다. 그런데 막상 실전에 넣어 보면 어떤 날은 훌륭하고, 어떤 날은 엉뚱하다.

이때 많은 사람이 빠지는 함정이 있다. 좋은 느낌이 곧 좋은 성능이라고 믿는 것이다. 하지만 AI 시스템은 느낌만으로 키우기 어려운 도구다. 오히려 느낌에만 기대면 제자리걸음을 하거나, 더 나쁘게 바뀌고도 눈치채지 못하기 쉽다.

앞 장에서 하네스가 같은 조건에서 비교할 수 있게 만드는 실험장이라면, 이번 장의 주인공인 평가는 그 실험장에서 무엇을 보고 어떻게 판단할지 정하는 일이다. 하네스가 무대라면, 평가는 조명이다. 무대만 있고 조명이 없으면 배우가 어디 있는지 잘 안 보인다.

왜 사람은 쉽게 착각하는가

사람은 생각보다 공정한 평가자가 아니다. 특히 AI 결과를 볼 때는 더 그렇다. 눈에 띄는 성공 사례를 강하게 기억하고, 실패는 빨리 잊는다. 내가 조금 고친 뒤 한 번 멋진 답이 나오면, 전체가 개선된 것처럼 느껴진다.

문제는 실무가 그렇게 돌아가지 않는다는 점이다. 실무에서는 한 번의 대박보다 여러 번의 평균적인 안정성이 중요하다. 보고서 초안이 열 번 중 두 번 아주 멋지게 나오는 것보다, 열 번 중 여덟 번 무난하고 정확하게 나오는 편이 훨씬 유용하다.

게다가 AI는 종종 "그럴듯함"으로 사람을 속인다. 문장은 매끄럽고 자신감도 넘치는데, 정작 핵심 사실이 틀리거나 중요한 정보가 빠져 있을 수 있다. 사람은 매끄러운 문장에 쉽게 설득된다. 그래서 평가 기준 없이 보면, 정확성보다 인상에 끌려가기 쉽다.

쉽게 말해, AI를 감으로 개선하는 일은 안개 속에서 인테리어를 바꾸는 것과 비슷하다. 소파 위치를 바꾸고 조명을 달았는데 분위기가 좋아진 것 같긴 하다. 그런데 창문이 막혀 있는지는 여전히 모른다.

발전은 수정이 아니라 검증에서 나온다

많은 사람이 AI를 개선한다고 하면 무언가를 계속 추가하는 모습을 떠올린다. 프롬프트를 더 길게 쓰고, 규칙을 더 붙이고, 예시를 더 넣고, 더 강한 모델을 쓴다. 물론 이런 수정은 필요하다. 하지만 수정 자체가 발전은 아니다.

발전은 수정한 뒤, 정말 나아졌는지 확인할 수 있을 때 일어난다.

이 차이는 아주 중요하다. 평가가 없으면 우리는 단지 바꾸기만 한다. 평가가 있으면 비로소 고친다. 겉보기에는 비슷하지만 결과는 완전히 다르다.

예를 들어 요약 시스템을 운영한다고 해 보자. "더 자세히 써라"라는 지시를 추가했더니 내용은 풍부해졌다. 그런데 평가가 없다면 여기서 만족하고 끝낼 수 있다. 하지만 실제로 확인해 보면 길이만 늘고, 핵심 결정은 오히려 덜 선명해졌을 수도 있다. 반대로 "추측하지 말라"는 제약을 넣었더니 환각은 줄었지만, 필요한 설명도 지나치게 짧아졌을 수 있다.

즉, AI 개선은 대체로 하나를 얻으면 다른 하나가 흔들리는 조정 작업이다. 그래서 무엇이 좋아졌고 무엇이 나빠졌는지 보는 평가가 반드시 필요하다.

평가가 없으면 시스템은 왜 정체되는가

AI 시스템이 정체되는 가장 흔한 이유는, 사실 기술이 부족해서가 아니다. 어디를 고쳐야 하는지 모르는 상태가 계속되기 때문이다.

평가가 없으면 다음과 같은 일이 반복된다.

• 문제가 생기면 프롬프트를 손본다.

• 결과가 좋아 보이면 일단 넘어간다.

• 비슷한 문제가 다시 생긴다.

• 또 감으로 수정한다.

• 몇 달이 지나도 같은 종류의 실수가 반복된다.

이 흐름에서는 경험이 쌓이는 것 같지만, 실제로는 지식이 축적되지 않는다. 왜 실패했는지 기록되지 않고, 어떤 수정이 효과 있었는지도 남지 않기 때문이다.

결국 시스템은 움직이는 것처럼 보이지만, 제자리에서 빙글빙글 돈다. 어제의 실수를 오늘 다시 하고, 오늘의 성공을 내일 재현하지 못한다.

평가는 이 악순환을 끊는다. 실패를 그냥 불쾌한 사건으로 흘려보내지 않고, 다음 개선에 쓸 수 있는 신호로 바꿔 주기 때문이다.

좋은 느낌보다 좋은 측정이 중요한 이유

이 장의 핵심은 단순하다. 좋은 느낌은 출발점일 수는 있어도, 판단 기준이 되어서는 안 된다.

느낌은 빠르고 편하다. 하지만 쉽게 흔들린다. 측정은 번거롭다. 하지만 누적된다.

예를 들어 두 개의 프롬프트 버전이 있다고 하자. A는 읽기에 부드럽고 세련돼 보인다. B는 조금 덜 멋져 보이지만, 중요한 숫자와 일정 누락이 적다. 사람이 첫인상으로만 보면 A를 더 좋아할 수 있다. 그러나 실제 업무에 필요한 것은 B일 가능성이 높다.

여기서 측정이 힘을 발휘한다. "더 좋아 보인다"가 아니라 "주요 정보 누락률이 낮다", "지정한 형식을 더 잘 지킨다", "재수정 시간이 덜 든다" 같은 식으로 판단하기 시작하면, 시스템은 비로소 발전할 수 있다.

측정은 AI를 차갑게 만드는 일이 아니다. 오히려 AI를 실제로 믿고 쓸 수 있게 만드는 과정이다. 감탄할 만한 한 번의 결과보다, 예측 가능한 여러 번의 결과가 더 가치 있기 때문이다.

평가란 무엇을 보는 일인가

평가라고 하면 많은 사람이 정답 맞히기만 떠올린다. 하지만 AI 작업의 평가는 훨씬 넓다. 어떤 작업은 정답이 하나지만, 어떤 작업은 좋은 답의 조건이 여러 개다.

예를 들어 평가 대상은 이런 식으로 나뉠 수 있다.

• 정확성: 사실이 맞는가, 계산이 맞는가, 핵심 정보가 빠지지 않았는가

• 형식 준수: 요청한 구조와 길이, 출력 형식을 지켰는가

• 유용성: 실제로 바로 쓸 수 있는가, 사람이 덜 고쳐도 되는가

• 안정성: 비슷한 입력에서 품질이 심하게 흔들리지 않는가

• 비용과 속도: 더 좋은 결과를 위해 지나치게 느리거나 비싸지 않은가

이 중 무엇이 중요한지는 작업에 따라 달라진다. 고객 응답 시스템이라면 정중함과 안전성이 중요할 수 있고, 회계 요약이라면 숫자 정확성이 더 중요할 수 있다. 코드 생성이라면 실행 가능성과 테스트 통과가 핵심이 된다.

중요한 것은 "좋은 결과"를 막연한 취향이 아니라 구체적인 기준으로 바꾸는 일이다.

피드백 루프가 왜 성장의 엔진인가

평가가 한 번의 채점으로 끝난다면, 발전은 여전히 느리다. 진짜 중요한 것은 평가가 피드백 루프로 이어지는 것이다.

피드백 루프는 간단히 말하면 이런 흐름이다. 결과를 만든다. 평가한다. 약점을 찾는다. 수정한다. 다시 시험한다. 그리고 그 결과를 기록한다.

이 구조가 생기면 AI 활용은 우연의 게임에서 학습의 과정으로 바뀐다. 실패가 그냥 기분 나쁜 사건이 아니라, 다음 버전을 더 낫게 만드는 재료가 된다.

예를 들어 학습용 요약 시스템을 운영한다고 해 보자. 평가해 보니 개념은 잘 요약하는데, 예외 조건을 자주 빼먹는다는 사실이 드러났다. 그러면 다음 버전에서는 "예외와 함정을 따로 정리하라"는 지시를 추가할 수 있다. 다시 평가해 보니 예외는 잘 잡지만, 이번에는 요약이 너무 길어진다. 그러면 길이 제한과 우선순위 규칙을 조정한다.

이 과정은 조금 귀찮다. 하지만 바로 이런 귀찮음이 성능을 쌓는다. AI 시스템은 한 번의 영감으로 완성되는 경우보다, 이런 반복 루프로 단단해지는 경우가 훨씬 많다.

평가가 없는 팀은 늘 같은 대화를 반복한다

개인이든 팀이든, 평가가 없으면 대화 수준이 일정 이상 올라가기 어렵다. 이런 말이 반복된다.

"이번 모델이 더 똑똑한 것 같아요." "저번 프롬프트가 더 자연스러웠던 것 같은데요?" "케이스마다 다른 것 같습니다."

이 말들이 틀린 것은 아니다. 문제는 여기서 대화가 자주 멈춘다는 점이다. 의견은 있는데 판단 근거가 약하다. 결국 더 목소리가 큰 사람, 더 최근 결과를 본 사람, 더 인상이 강한 사례를 본 사람이 결정하게 된다.

반대로 평가 체계가 있는 팀은 대화가 달라진다.

"자연스러움은 조금 떨어졌지만 누락률이 줄었습니다." "속도는 30퍼센트 빨라졌는데 수정 시간은 늘었습니다." "짧은 문서에는 강하지만 긴 문서에서 흔들립니다."

이런 대화가 가능해지면 개선 방향이 선명해진다. 감상이 사라지는 것은 아니지만, 감상이 운영을 대신하지 않게 된다.

AI는 왜 특히 평가가 더 중요한가

일반 소프트웨어도 테스트가 중요하지만, AI는 그 필요성이 더 크다. 이유는 AI가 늘 같은 방식으로 작동하지 않기 때문이다.

전통적인 프로그램은 보통 같은 입력에 같은 출력이 나온다. 물론 버그는 있을 수 있지만, 적어도 규칙은 비교적 명확하다. 반면 AI는 입력 표현, 문맥 길이, 모델 특성, 도구 연결 여부에 따라 결과가 크게 달라질 수 있다. 겉보기에는 작은 수정이 전체 성능에 의외의 영향을 줄 때도 많다.

그래서 AI에서는 "이 정도면 되겠지"가 특히 위험하다. 잘 되는 순간보다 흔들리는 순간을 빨리 발견하는 능력이 더 중요하다. 평가는 바로 그 흔들림을 잡아내는 역할을 한다.

한마디로 말하면, AI는 똑똑해서 평가가 덜 필요한 도구가 아니라, 오히려 그럴듯해서 평가가 더 필요한 도구다.

사례로 보는 평가의 힘

회의록 요약 시스템

처음에는 팀원 모두가 만족했다. 문장이 깔끔했고, 읽기 좋았다. 그런데 실제로 회의 후속 작업에서 문제가 생겼다. 담당자 이름과 마감일이 빠지는 경우가 자주 있었던 것이다.

만약 느낌만 믿었다면 이 시스템은 "잘 작동하는 요약기"로 남았을 것이다. 하지만 평가 항목에 "담당자 포함 여부"와 "기한 누락 여부"를 넣는 순간 진짜 상태가 보인다. 그제야 무엇을 고쳐야 할지 선명해진다.

보고서 초안 생성

초안이 꽤 그럴듯하게 나왔다. 표현도 부드럽고 구성도 멀쩡했다. 그런데 실제 업무에서는 매번 사람이 핵심 근거를 다시 채워 넣어야 했다. 문장은 좋아도 실무 유용성이 낮았던 것이다.

이때 평가 기준을 "문장 자연스러움"만 두면 계속 속는다. 대신 "근거 포함", "숫자 출처 명확성", "즉시 제출 가능성" 같은 항목을 넣으면 다른 그림이 나온다. 초안의 진짜 약점은 문체가 아니라 근거 밀도였다는 사실이 드러난다.

코딩 작업

코드가 보기에는 멀쩡하다. 설명도 자신감 있다. 하지만 테스트를 돌려 보니 경계 조건에서 자주 깨진다. 여기서도 느낌은 별 도움이 되지 않는다. 코드 영역에서는 특히 실행, 테스트 통과, 성능, 예외 처리처럼 비교적 명확한 평가가 성능을 냉정하게 보여 준다.

이런 작업일수록 사람의 감탄보다 측정값이 훨씬 믿을 만하다.

무엇을 측정해야 하는가

평가가 중요하다고 해서 모든 것을 숫자로 만들 필요는 없다. 오히려 처음부터 너무 많은 지표를 붙이면 시작도 못 한다. 중요한 것은 작업의 성공을 가르는 몇 가지 기준부터 잡는 것이다.

예를 들어 처음에는 아래처럼 단순하게 시작해도 충분하다.

• 핵심 정보가 빠지지 않았는가

• 사실 오류가 없는가

• 요청한 형식을 지켰는가

• 사람이 다시 고치는 시간이 줄었는가

• 결과 품질이 사례마다 심하게 흔들리지 않는가

이 기준들은 화려하지 않지만 강력하다. 왜냐하면 대부분의 AI 시스템은 아주 복잡한 실패보다, 이런 기본적인 실패에서 더 자주 무너지기 때문이다.

특히 실무에서는 "정답률" 하나만 보면 부족하다. 어떤 시스템은 정답은 꽤 맞추지만 너무 느릴 수 있고, 어떤 시스템은 빠르지만 손이 너무 많이 갈 수 있다. 그래서 품질, 안정성, 비용, 속도를 함께 보는 습관이 필요하다.

평가가 어려운 작업은 어떻게 해야 하는가

누군가는 이렇게 말할 수 있다. "요약이나 글쓰기처럼 정답이 여러 개인 작업은 어떻게 평가하죠?" 아주 좋은 질문이다. 이런 작업은 수학 문제처럼 딱 떨어지지 않는다. 그렇다고 평가를 포기할 이유는 없다.

정답이 하나가 아닌 작업에서는 보통 세 가지 접근이 유용하다.

첫째, 체크리스트를 만든다. 핵심 개념 포함 여부, 독자 수준 적합성, 구조 명확성처럼 좋은 결과의 조건을 항목으로 나눈다.

둘째, 비교 평가를 한다. 절대 점수를 억지로 매기기보다 A와 B 중 어느 쪽이 더 낫고 왜 그런지 보는 방식이다. 사람은 절대 평가보다 상대 비교를 더 안정적으로 하는 경우가 많다.

셋째, 실제 사용성을 본다. 결과를 본 뒤 사람이 얼마나 수정해야 하는지, 실제 작업 시간이 줄었는지를 측정한다. 이 지표는 놀랄 만큼 현실적이다.

즉, 평가가 어렵다는 것은 평가가 불가능하다는 뜻이 아니다. 다만 정답 하나 찾기 대신, 좋은 결과의 특징을 분해해서 보는 방식이 필요하다는 뜻이다.

평가를 시작하면 마주치는 불편한 진실

평가를 도입하면 종종 마음이 불편해진다. 내가 잘 만들었다고 믿었던 시스템이 생각보다 약하다는 사실이 드러나기 때문이다. 체감상 좋았던 프롬프트가 실제로는 별 차이가 없을 수도 있다. 심지어 열심히 넣은 규칙들이 성능을 떨어뜨렸다는 결과가 나올 수도 있다.

하지만 이 불편함이 바로 발전의 시작이다.

평가는 우리 자존심을 만족시키는 장치가 아니라, 시스템을 강하게 만드는 장치다. 좋은 측정은 때때로 기분을 상하게 한다. 그러나 그 기분 상함 덕분에 다음 수정은 훨씬 정확해진다.

여기서 중요한 태도는 "내 아이디어가 맞았는가"보다 "시스템이 실제로 좋아졌는가"를 더 중요하게 여기는 것이다. AI 실전에서는 이 태도 차이가 성과를 크게 가른다.

너무 늦기 전에 평가를 붙여야 하는 이유

많은 사람은 시스템이 어느 정도 커진 뒤에야 평가를 붙이려 한다. 하지만 그때는 이미 늦고 복잡해진 경우가 많다. 프롬프트도 여러 버전이고, 모델도 바뀌었고, 예외 규칙도 덕지덕지 붙어 있다. 무엇이 왜 그렇게 되었는지 아무도 정확히 모른다.

평가는 초기에 시작할수록 좋다. 아주 작아도 괜찮다. 사례 몇 개, 기준 몇 줄, 간단한 비교표만 있어도 충분하다. 핵심은 완벽한 측정 체계를 갖추는 것이 아니라, 처음부터 변화의 효과를 확인하는 습관을 들이는 것이다.

작은 평가가 쌓이면 시스템도 덜 흔들린다. 나중에 모델을 교체하든, 워크플로를 늘리든, 도구 연결을 바꾸든 최소한 무엇이 변했는지 볼 수 있다. 이것은 생각보다 큰 안정감을 준다.

평가 없는 개선은 왜 쉽게 종교가 되는가

조금 과장해서 말하면, 평가 없는 AI 개선은 종종 종교처럼 변한다. 누군가는 긴 프롬프트를 믿고, 누군가는 짧은 프롬프트를 믿는다. 누군가는 체인 오브 쏘트를 좋아하고, 누군가는 예시 몇 개가 전부라고 생각한다. 누군가는 최신 모델이면 다 해결된다고 믿는다.

이런 믿음 중 일부는 실제로 맞을 수도 있다. 문제는 내 작업에서도 그런가를 확인하지 않으면, 믿음은 지식이 되지 못한다는 점이다.

평가는 유행과 취향을 현실로 끌어내린다. "남들이 좋다고 하더라"에서 멈추지 않고, "우리 작업에서는 무엇이 효과 있더라"로 바꿔 준다. 이 차이가 실전 사용자와 구경꾼을 가른다.

실전에서는 완벽한 평가보다 지속 가능한 평가가 낫다

여기서 또 하나 기억할 점이 있다. 평가는 정교할수록 좋지만, 지속되지 않으면 소용이 없다.

처음부터 너무 복잡한 기준표를 만들면 며칠은 열심히 하다가 금방 지친다. 그래서 실제로는 약간 거칠더라도 계속 돌릴 수 있는 평가가 더 가치 있다.

예를 들어 처음에는 다음 정도면 충분하다.

• 대표 사례 10개를 정한다.

• 핵심 기준 3개에서 5개만 본다.

• 새 버전을 만들 때마다 이전 버전과 비교한다.

• 나빠진 사례를 따로 기록한다.

이 정도만 꾸준히 해도 시스템은 달라진다. 왜냐하면 발전은 거대한 한 번의 혁신보다, 작은 수정과 확인의 반복에서 나오는 경우가 많기 때문이다.

결국 평가는 신뢰를 만드는 일이다

우리가 평가를 하는 이유는 점수를 예쁘게 만들기 위해서가 아니다. 믿을 수 있는 시스템을 만들기 위해서다.

AI를 자주 쓰는 사람일수록 이 사실을 빨리 받아들인다. 좋은 시스템은 멋진 데모를 보여 주는 시스템이 아니라, 반복해서 맡길 수 있는 시스템이다. 그리고 반복해서 맡기려면, 적어도 어떤 조건에서 잘되고 어떤 조건에서 흔들리는지 알아야 한다.

평가는 그 지도를 만든다. 어디가 안전한 길이고 어디가 위험한 길인지 알려 준다. 그 지도가 없으면 우리는 매번 새로 헤맨다.

좋은 느낌은 기분을 좋게 해 준다. 좋은 측정은 방향을 알려 준다. AI를 오래, 깊게, 실전에서 쓰려면 결국 필요한 것은 방향이다.

이 장의 핵심 정리

AI 시스템은 그냥 많이 손본다고 발전하지 않는다. 평가를 통해 무엇이 실제로 좋아졌는지 확인할 수 있을 때만 발전한다.

좋은 느낌은 자주 우리를 속인다. 그럴듯한 문장, 멋진 한 번의 결과, 강한 첫인상은 전체 성능을 대신하지 못한다. 반대로 좋은 측정은 불편할 수 있지만, 실패 패턴을 드러내고 다음 수정을 더 정확하게 만든다.

평가의 목적은 점수 놀이가 아니다. 피드백 루프를 만들어 시스템이 같은 실수를 반복하지 않게 하는 것이다. 결국 AI 활용에서 성장을 가르는 것은 더 많은 수정이 아니라, 수정을 검증하고 축적하는 능력이다.

그래서 실전에서 중요한 질문은 이것이다. "이번 결과가 마음에 드는가?"가 아니다. "이번 변경이 정말로 더 나아졌는가?"다. 이 질문을 붙잡는 순간, AI 활용은 감상에서 운영으로 넘어간다.