12부 65장. 하네스란 무엇인가

AI를 쓰다 보면 누구나 비슷한 순간을 맞는다. 어제는 분명 잘됐는데 오늘은 이상하다. 프롬프트를 조금 고쳤더니 어떤 결과는 좋아졌는데, 다른 결과는 오히려 나빠졌다. 모델을 바꿨더니 속도는 빨라졌지만 품질이 흔들린다. 이럴 때 많은 사람은 감으로 판단한다. "이번 버전이 더 나은 것 같아." 문제는 그 "같아"가 자주 틀린다는 데 있다.

바로 이 지점에서 필요한 것이 하네스다. 하네스는 어렵고 거창한 장비가 아니다. 쉽게 말해, AI 결과를 같은 조건에서 반복해서 시험하고 비교할 수 있게 만드는 작은 실험장이다. 한마디로 정리하면, 하네스는 AI 개선을 감의 영역에서 테스트의 영역으로 옮겨 주는 장치다.

하네스는 왜 필요한가

하네스라는 말을 처음 들으면 뭔가 대단한 엔지니어링 시스템처럼 느껴질 수 있다. 하지만 핵심은 아주 소박하다. "바꾼 것이 정말 나아졌는지 확인하자"는 것이다.

예를 들어 당신이 회의록 요약 프롬프트를 쓰고 있다고 해 보자. 어느 날은 요약이 깔끔하고, 어느 날은 중요 결정이 빠진다. 그래서 프롬프트를 고친다. 그런데 고친 뒤 결과가 더 좋아졌는지 어떻게 알 수 있을까. 단 하나의 예시만 보고 판단하면 착각하기 쉽다. 우연히 잘 맞은 것일 수도 있고, 반대로 우연히 망한 것일 수도 있다.

하네스는 이런 문제를 막아 준다. 같은 작업 유형의 예시들을 모아 두고, 이전 버전과 새 버전을 같은 조건에서 돌려 보고, 어떤 기준으로 더 나은지 비교하게 해 준다. 그러면 "왠지 좋아 보인다"가 아니라 "이런 입력 20개에서 누락이 줄었다"처럼 말할 수 있다.

AI는 확률적으로 움직인다. 그래서 더더욱 반복 시험이 필요하다. 계산기처럼 늘 똑같이 답하는 도구였다면 하네스가 덜 중요했을지도 모른다. 하지만 AI는 입력 표현, 문맥, 모델 상태, 출력 길이에 따라 결과가 흔들릴 수 있다. 이 흔들림을 사람 기억에만 맡기면 개선이 쌓이지 않는다.

하네스란 정확히 무엇인가

하네스를 너무 기술적으로 생각할 필요는 없다. 본질적으로는 다음 네 가지를 묶어 둔 구조다.

• 시험할 입력 묶음: 실제로 자주 다루는 질문, 문서, 작업 사례

• 비교할 대상: 프롬프트 버전 A와 B, 모델 1과 2, 워크플로 전후

• 평가 기준: 무엇이 좋은 결과인지 판단하는 규칙

• 기록 방식: 어떤 조건에서 어떤 결과가 나왔는지 남기는 장치

이 네 가지가 있으면 작은 하네스가 된다.

중요한 점은 하네스가 꼭 자동 채점 시스템일 필요는 없다는 것이다. 처음에는 사람이 직접 결과를 보고 평가해도 된다. 예를 들어 요약 작업이라면 "핵심 결정 포함 여부", "날짜·숫자 정확성", "불필요한 장황함" 같은 체크 항목을 만들어 사람이 표시하면 된다. 이것도 훌륭한 하네스다.

즉, 하네스는 프로그램의 이름이 아니라 비교 가능한 실험 환경의 이름에 가깝다.

하네스가 없는 개선은 왜 위험한가

하네스 없이 AI를 고치면, 개선이 아니라 요행을 쫓기 쉽다. 한 문제를 해결하려다 다른 문제를 키우는 일도 많다.

예를 들어 "더 자세하게 써 달라"는 지시를 추가했더니 설명은 풍부해졌다. 그런데 동시에 불필요한 말도 길어지고, 요약 정확도는 떨어질 수 있다. 또 "확신 없는 내용은 추측하지 말라"는 제약을 넣었더니 환각은 줄었지만, 필요한 답변까지 지나치게 소극적으로 바뀔 수도 있다.

하네스가 없으면 이런 부작용을 잘 못 본다. 사람은 보통 눈에 띄는 성공 사례를 더 강하게 기억하기 때문이다. 한두 번 좋아진 결과를 보면 전체가 개선됐다고 믿기 쉽다. 하지만 실제 현장에서는 전체 평균이 중요하다. 한 번의 멋진 답변보다, 열 번 중 여덟 번 안정적으로 통과하는 시스템이 더 쓸모 있다.

하네스는 바로 이 평균 감각을 만들어 준다. 좋은 사례와 나쁜 사례를 함께 보게 만들고, 한쪽만 보고 흥분하지 않게 해 준다.

하네스는 무엇을 시험하나

많은 사람이 하네스라고 하면 프롬프트만 떠올린다. 하지만 실제로 시험 대상은 훨씬 넓다.

당신은 하네스로 여러 가지를 시험할 수 있다.

• 프롬프트 문구 변경

• 예시 추가 여부

• 출력 형식 변경

• 컨텍스트 길이와 구성 방식

• 모델 교체

• 멀티턴 워크플로 단계 수

• 도구 사용 여부

• 후처리 규칙 추가 여부

예를 들어 같은 문서 요약 작업이라도 "문서를 통째로 넣는 방식"과 "핵심 부분만 발췌해서 넣는 방식" 중 어느 쪽이 더 나은지 시험할 수 있다. 또는 같은 코딩 작업에서도 "바로 코드 작성"과 "먼저 계획 수립 후 코드 작성" 중 어느 흐름이 더 안정적인지 비교할 수 있다.

이렇게 보면 하네스는 단순한 품질 확인 도구가 아니다. AI 시스템 전체를 조정하는 실험판이다.

좋은 하네스는 실제 작업을 닮아 있다

하네스를 만들 때 가장 흔한 실수는 너무 깨끗한 예시만 모으는 것이다. 현실은 지저분한데 시험장은 지나치게 예쁘면, 실제 배포 후에 금방 무너진다.

좋은 하네스는 실제 현장을 닮아 있어야 한다. 사람 메모처럼 어수선한 입력, 길이가 제각각인 문서, 애매한 질문, 부족한 정보, 헷갈리는 표현도 들어 있어야 한다. 왜냐하면 AI가 흔들리는 곳이 바로 그런 구간이기 때문이다.

예를 들어 고객 문의 답변 시스템을 만든다고 하자. 하네스에 "정중하고 명확한 문의"만 들어 있으면 실전에서는 큰 도움이 안 된다. 실제로는 오타가 많고, 감정이 섞여 있고, 맥락이 누락된 문의가 더 많기 때문이다.

하네스는 AI를 시험하는 장소이자, 시스템의 약점을 드러내는 거울이다. 거울이 현실을 잘 비출수록 개선도 정확해진다.

평가 기준이 없으면 하네스도 반쪽이다

입력 묶음만 있다고 하네스가 완성되는 것은 아니다. 무엇보다 중요한 것은 무엇을 통과라고 볼 것인가다.

예를 들어 요약 작업이라면 길이만 짧다고 좋은 결과는 아니다. 핵심이 빠지면 실패다. 반대로 핵심은 다 넣었지만 문장이 엉망이면 실무에서는 다시 손을 봐야 한다. 그러니 평가 기준을 분리해서 봐야 한다.

대표적으로 이런 질문을 붙일 수 있다.

• 중요한 사실이 빠지지 않았는가

• 잘못된 내용이 들어가지는 않았는가

• 요청한 형식을 지켰는가

• 지나치게 장황하지 않은가

• 바로 사용할 수 있을 만큼 명확한가

기준을 정할 때는 완벽주의보다 실용성이 중요하다. 처음부터 모든 것을 수치화하려고 하면 오히려 시작을 못 한다. 처음에는 "통과 / 수정 필요 / 실패"처럼 단순하게 나눠도 된다. 중요한 것은 기준이 있다는 사실이다.

기준이 생기면 사람끼리도 대화를 더 잘할 수 있다. "이상하게 별로다"가 아니라 "핵심 숫자가 자주 빠진다"라고 말할 수 있기 때문이다. 그 순간 개선은 훨씬 빨라진다.

하네스의 가장 작은 형태

하네스는 꼭 대규모 시스템이어야 한다고 생각하면 시작이 늦어진다. 사실 가장 작은 하네스는 아주 단순하다.

예를 들어 다음 정도면 충분히 시작할 수 있다.

• 자주 나오는 실제 작업 예시 10개를 모은다.

• 현재 프롬프트와 새 프롬프트를 각각 돌린다.

• 결과를 나란히 놓고 같은 체크리스트로 본다.

• 어떤 항목이 좋아졌고 나빠졌는지 기록한다.

이 정도만 해도 벌써 감에 의존하던 상태에서 한 단계 올라선다.

가령 학습용 요약 하네스를 만든다고 해 보자. 입력은 교재 일부 10개, 출력은 요약문, 평가는 "핵심 개념 포함", "오해를 부르는 표현 없음", "복습용으로 적절함" 같은 기준으로 한다. 그러면 프롬프트를 바꿀 때마다 바로 비교할 수 있다.

작지만 이런 하네스가 쌓이면 나중에는 더 큰 실험도 가능해진다. 중요한 것은 크기가 아니라 반복 가능성이다.

예시로 보는 하네스

하네스를 더 쉽게 이해하려면 실제 장면으로 떠올려 보는 것이 좋다.

회의록 요약 하네스

당신의 팀이 매주 회의를 하고, AI로 회의록 요약을 만든다고 해 보자. 문제는 어떤 날은 결정 사항이 잘 보이고, 어떤 날은 잡담만 길게 정리된다는 것이다.

이때 하네스는 최근 회의록 15개를 모아서 만든다. 각 결과를 보며 "의사결정 포함 여부", "담당자·기한 누락 여부", "불필요한 내용 비중"을 체크한다. 그런 다음 프롬프트를 고치거나 출력 형식을 바꿔 비교한다.

그러면 막연한 만족감 대신, 실제로 어떤 변화가 있었는지 보이기 시작한다. 예를 들어 "기한 누락은 줄었지만 잡담 정리는 여전히 많다" 같은 식이다. 이 정도만 알아도 다음 개선 방향이 분명해진다.

글쓰기 초안 하네스

블로그 초안 생성에서도 하네스는 유용하다. 좋은 글은 단순히 문장이 자연스럽기만 한 것이 아니다. 독자 수준에 맞아야 하고, 구조가 분명해야 하고, 반복 표현이 적어야 한다.

이때 하네스는 주제 12개를 정하고, 같은 형식의 글 초안을 여러 버전으로 생성해 비교한다. 평가 기준은 "도입부의 흡입력", "핵심 설명의 명료함", "예시의 적절성", "군더더기 정도"처럼 잡을 수 있다.

그러면 "이 프롬프트가 더 창의적인 것 같다" 같은 느낌 대신, "초보자 설명은 좋아졌지만 구조 일관성은 떨어진다"는 식으로 해석할 수 있다.

코드 생성 하네스

코드 작업에서는 하네스의 가치가 더 선명하다. 코드가 그럴듯해 보여도 실행이 안 되면 소용이 없다. 그래서 코딩 하네스는 흔히 테스트와 잘 어울린다.

예를 들어 작은 함수 생성 작업 20개를 준비하고, 각 결과가 실행되는지, 테스트를 통과하는지, 불필요하게 복잡하지 않은지 확인한다. 이때부터는 평가가 조금 더 명확해진다. "좋아 보인다"가 아니라 "테스트 20개 중 17개 통과"처럼 볼 수 있기 때문이다.

이런 하네스가 있으면 모델을 바꾸거나 프롬프트를 수정할 때 훨씬 덜 불안하다. 적어도 무엇이 나아지고 무엇이 나빠졌는지 볼 수 있기 때문이다.

하네스는 평가와 어떻게 다른가

하네스와 평가는 비슷해 보이지만 완전히 같은 말은 아니다. 평가가 결과가 좋은지 판단하는 행위라면, 하네스는 그 평가를 반복 가능하게 수행하도록 받쳐 주는 틀에 가깝다.

조금 쉽게 말해 보자. 평가는 시험의 채점표이고, 하네스는 시험장이다. 시험장 없이 채점만 할 수는 없다. 반대로 채점표 없이 시험장만 있어도 무슨 의미인지 알기 어렵다.

그래서 하네스는 보통 평가와 함께 간다. 입력을 준비하고, 결과를 뽑고, 기준으로 보고, 기록하고, 다시 비교하는 흐름 전체를 떠받치는 구조가 바로 하네스다.

다음 장에서 더 본격적으로 다루겠지만, 평가가 발전의 엔진이라면 하네스는 그 엔진을 얹는 차체라고 생각하면 이해하기 쉽다.

하네스를 만들 때 자주 하는 오해

하네스를 처음 만들 때 사람들은 몇 가지 오해에 빠지기 쉽다.

첫째, "자동화되지 않으면 하네스가 아니다"라고 생각한다. 그렇지 않다. 처음에는 수작업 비교표만 있어도 충분하다. 중요한 것은 반복성과 기준이다.

둘째, "예시가 많아야만 의미 있다"고 생각한다. 물론 많을수록 좋을 수는 있다. 하지만 10개의 대표 사례라도 제대로 고른다면 꽤 많은 것을 배울 수 있다. 적은 수라도 현실적인 실패 패턴이 담겨 있으면 훌륭하다.

셋째, "정답이 하나로 고정돼야만 평가 가능하다"고 생각한다. 이것도 절반만 맞다. 요약이나 글쓰기처럼 정답이 여러 개인 작업도 체크리스트, 비교 평가, 사람 선호 판단으로 충분히 볼 수 있다.

넷째, "하네스는 개발자만 만드는 것"이라고 생각한다. 아니다. 마케터는 카피 초안 하네스를 만들 수 있고, 기획자는 보고서 요약 하네스를 만들 수 있고, 교사는 학습 설명 하네스를 만들 수 있다. 하네스는 기술 직군만의 도구가 아니라, 반복 작업이 있는 사람 모두의 도구다.

하네스가 생기면 무엇이 달라지는가

하네스가 있으면 AI 활용의 태도 자체가 달라진다. 우선, 수정이 덜 두려워진다. 바꾸고 시험하면 되기 때문이다. 예전에는 프롬프트 한 줄 고치는 것도 겁났다. 괜히 전체가 망가질까 봐서다. 하지만 하네스가 있으면 바꾼 뒤 비교하면 된다.

또 하나 달라지는 것은 팀 대화다. 팀원들이 "이 모델이 더 똑똑한 것 같아요"라고 말하는 대신, "우리 주요 사례 30개에서 누락률이 줄었습니다"라고 말하기 시작한다. 이 변화는 작아 보이지만 매우 크다. 감상이 줄고 운영이 시작되기 때문이다.

무엇보다 하네스는 실패를 자산으로 바꾼다. 예전에는 이상한 결과가 나오면 그냥 짜증나고 넘어갔다. 이제는 "이 사례를 하네스에 추가하자"가 된다. 그러면 그 실패는 다음 개선에서 다시 쓰이는 데이터가 된다. 같은 실수를 두 번 반복할 가능성이 줄어드는 것이다.

처음 만드는 사람을 위한 실전 순서

하네스를 처음 만든다면 거창하게 시작하지 않는 것이 좋다. 다음 순서면 충분하다.

• 먼저 반복해서 하는 작업 하나를 고른다.

• 그 작업에서 자주 나오는 실제 사례를 5개에서 20개 정도 모은다.

• 좋은 결과의 기준을 3개에서 5개 정도 정한다.

• 현재 방식과 새 방식을 같은 입력에 적용한다.

• 결과를 나란히 보고 기준에 따라 표시한다.

• 나빠진 사례까지 함께 기록한다.

핵심은 "완벽한 측정"이 아니라 "같은 조건에서 비교"다. 많은 사람이 여기서 멈춘다. 너무 잘하려고 하기 때문이다. 하지만 하네스는 처음부터 완성품일 필요가 없다. 오히려 실제로 돌려 보면서 자라는 것이 정상이다.

처음에는 엑셀 표 하나, 문서 폴더 하나, 체크리스트 몇 줄이면 된다. 그 정도로도 충분히 많은 것이 보이기 시작한다.

하네스는 AI를 더 똑똑하게 만드는 도구가 아니다

조금 역설적으로 들릴 수 있지만, 하네스는 모델 자체를 더 똑똑하게 만드는 도구는 아니다. 대신 당신이 AI를 다루는 방식을 더 똑똑하게 만든다.

이 차이가 중요하다. 많은 사람이 더 좋은 모델이 모든 문제를 해결해 줄 거라고 기대한다. 하지만 실무에서 자주 성과를 가르는 것은 모델의 절대 성능보다, 사용자가 얼마나 안정적으로 시험하고 고칠 수 있느냐다.

하네스가 있으면 작은 개선이 쌓인다. 작은 개선이 쌓이면 시스템이 단단해진다. 그리고 단단한 시스템은 최신 유행보다 오래 간다.

이 장의 핵심 정리

하네스는 AI 결과를 반복적으로 시험하고 비교하기 위한 구조다. 거창한 자동화 시스템이 아니라, 같은 입력으로 여러 버전을 비교하고, 같은 기준으로 판단하고, 결과를 기록하는 틀이라고 이해하면 된다.

하네스가 없으면 개선은 감에 의존하기 쉽다. 한 번 잘된 사례에 속기 쉽고, 무엇이 나아졌는지 정확히 알기 어렵다. 반대로 하네스가 있으면 AI 활용은 훨씬 덜 흔들린다. 실패를 모을 수 있고, 변경의 효과를 비교할 수 있고, 점점 더 나은 방향으로 고칠 수 있다.

결국 하네스의 가치는 단순하다. "좋아진 것 같다"를 "어디가 얼마나 좋아졌는지 알 수 있다"로 바꿔 준다. 이 전환이 일어나면, AI 활용은 운에 기대는 실험에서 관리 가능한 시스템으로 넘어가기 시작한다.