AI 하네스 변경을 실제 업무로 검증하는 실습

실습 목표와 준비

프롬프트나 도구 설정을 바꾼 뒤 실제 업무가 좋아졌는지 확인할 평가 기록을 만들어요. 입력을 보관할 폴더, 기준·후보 설정, 결과를 확인할 방법이 필요해요. 자동화 코드를 작성하기 전 표와 파일만으로도 시작할 수 있어요.

이 글은 foundby 공개 평가 방법을 바탕으로 구성한 실습 자료예요. 아래 작업과 기록은 설계 예시이며 직접 실행한 성능 보고서가 아니에요. 기본 개념은 우리 업무에 맞는 AI 평가 설계하기, 배경은 관련 기사에서 확인할 수 있어요.

1. 운영 점검 옆에 업무 완료 검사를 둬요

필수 스크립트가 있는지, 훅 테스트가 통과하는지, 보고서 생성 명령이 끝나는지를 검사하는 기존 점검은 유지해요. 여기에 에이전트가 받은 요청의 결과를 확인하는 별도 평가를 추가해요. 스크립트 존재만으로 파일 수정의 정확성을 알 수 없고, 검증 명령 횟수만으로 최종 결과가 쓸 만한지 판단할 수 없기 때문이에요.

연습 과제는 “작은 저장소의 날짜 표시 함수를 수정하되, 이미 있던 안내문 변경은 보존한다”로 잡을 수 있어요. 통과 조건은 기대 날짜 출력, 지정한 수정 범위, 기존 변경 보존이에요. 완료했다고 답했는지는 보조 기록이고, 실제 파일과 테스트 결과가 판정 근거예요. 사용자 수정량은 평가자가 결과물을 수용 가능하게 만드는 데 추가로 한 수정과 시간으로 기록해요. 업무마다 난도가 다르므로 다른 과제의 수정량을 바로 평균하지 않아요.

2. 비교 전에 입력과 설정의 스냅샷을 남겨요

기준 설정을 baseline, 바꾼 설정을 candidate로 구분하고 동일한 task ID를 사용해요. 저장소 기준 버전뿐 아니라 작업 시작 전 diff와 추가 파일도 보관해요. 커밋 번호만 같아도 미커밋 변경이 다르면 입력이 달라져요. 반복마다 같은 초기 상태의 격리된 작업 복사본을 사용해 이전 회차의 수정이 섞이지 않게 해요.

요청문, fixture, 채점 기준에 버전을 붙이고 내용 해시를 저장해요. 해시는 두 실행에 사용한 파일이 같았는지 확인하는 수단이에요. 원문을 대체하거나 입력이 올바르다는 것을 보증하지 않으므로 실제 파일도 남겨요. 도구 허용 범위, 출력 한도, 타임아웃, 모델·런타임 버전, 샘플링 설정도 함께 기록해요. 제공자가 실제 적용값을 알려주지 않는 항목은 ‘미확인’으로 남겨요.

요청문 개선을 비교한다면 모델과 입력을 고정해요. 배포 구성을 비교하려고 여러 설정을 함께 바꿨다면 그 전체 구성을 평가 단위로 삼아요. 개별 설정 하나가 개선의 원인이라고 단정하지 않아요.

3. 요청한 모델과 처리한 경로를 구별해요

다음은 회차별 기록 필드 예시예요. 값이 없는 칸을 추측으로 채우지 않아요.

모델 ID만으로 실제 추론 장소를 확인할 수는 없어요. 폴백이 켜져 있다면 요청 모델의 결과와 폴백 결과를 섞지 않아요. 모델별 비교와 “이 폴백 구성을 사용한 전체 업무 완료율”을 별도로 계산해요. 민감한 키가 포함된 헤더나 인증 URL을 기록에 그대로 남기지 않도록 해요.

공개 평가의 운영 환경은 제공자 제한과 폴백의 범위를 설명해요. 로컬 폴백을 구성하는 단계는 Ollama 폴백 가이드와 함께 볼 수 있어요.

4. 같은 과제를 짝지어 반복하고 오류를 분모에 남겨요

동일 과제를 두 설정에 각각 실행해 과제별 차이를 확인해요. 첫 탐색은 각각 3회로 시작할 수 있지만, 이를 안정성 입증으로 해석하지 않아요. 실행 순서를 번갈아 배치하고 반복 횟수·재시도 상한·중단 조건을 실행 전에 적어요. 추가 실행을 했다면 이유를 기록해요.

업무 회차와 API 호출 시도를 구분해요. 한 회차가 두 번의 재시도 뒤 성공했다면 업무 완료는 한 건이지만 호출은 세 번이에요. 전체 계획 회차 중 성공 수, 실제 시도 중 실행 오류 수, 완료 응답 중 내용 통과 수를 각각 분자·분모와 함께 표시해요. 요청 불가와 미실행도 별도 집계해 빠진 과제를 드러내요. 응답이 돌아온 사례만으로 성공률을 계산한다면 반드시 ‘완료 응답 기준’이라고 써요.

실패 명령 비율은 원인 조사에 활용해요. 수정 전 테스트 실패를 재현하고 고친 회차와, 명령은 모두 성공했지만 요구한 수정을 못 한 회차를 최종 완료 조건으로 구별해야 해요. 질문 역시 필요한 정보를 확인한 것인지, 이미 주어진 정보를 다시 물은 것인지 과제 조건으로 판정해요.

5. 실행·형식·내용·시간을 각각 확인해요

실행 상태는 요청 불가, 시간 초과, 제공자 오류, 응답 완료 등으로 나눠요. 형식은 실제 후속 파서로 읽히는지 확인하고, 내용은 필수 조건과 최종 산출물로 판정해요. 시간은 최초 요청부터 재시도를 포함한 완료까지 측정하되 각 시도 시간도 보관해요. 부분 결과에서 끝났다면 실패까지 걸린 시간으로 표시해요.

JSON 파싱에 성공해도 필수 값이 틀릴 수 있고, 응답이 정상 종료돼도 저장 가능한 결과가 아닐 수 있어요. 네 항목을 한 점수로 합치기 전에 어느 조건이 사용을 막는지 보여 주세요. 입력은 같은데 출력이 반복해서 같았다면 그 사실도 남겨요. 동일 출력의 반복은 다양한 업무를 통과했다는 증거가 아니에요.

6. 채점 반례를 만들고 변경 범위에 맞게 다시 확인해요

정답 파일과 함께 그럴듯한 오답을 준비해요. 표의 담당자를 다른 행으로 옮긴 답, 날짜만 맞고 대상이 다른 답, 형식만 맞는 미완료 결과가 통과하면 채점 규칙을 고쳐요. 올바른 답의 공백·순서·동의어만 바꾼 사례도 넣어 과잉 탈락을 찾을 수 있어요. M05의 행·필드 연결 검사는 이런 반례를 설계하는 참고가 돼요.

채점 설명만 바뀌고 원본에 증거가 충분하면 같은 출력을 새 규칙으로 재채점해요. 이전 판정도 남기고 채점 버전으로 구분해요. 프롬프트·fixture·도구 정책·샘플링·실행 경로가 바뀌면 새 조건으로 재실행해요. 새 규칙이 저장하지 않은 도구 인자나 중간 상태를 요구할 때도 재실행이 필요해요.

실습 결과에는 과제별 기준·후보 결과와 함께 ‘바꾼 조건, 남은 실패, 적용할 업무 범위’를 적어요. 설정 점검 통과와 업무 성공을 나란히 보여주면 다음 개선이 필요한 지점과 아직 확인하지 못한 범위가 분명해져요. 팀과 함께 진행하려면 무료 공개한 90분 AI 평가 실습 교안을 사용하세요. 진행자용 자료이며 모집 중인 행사 안내는 아니에요.