정확성

=> AI관련들 이동

AI 엔지니어링에서 정확성을 높이는 방법

AI가 코드를 작성하고, 도구를 호출하고, 데이터를 수정하는 영역까지 발전하면서 정확성(Correctness / Reliability)은 AI 엔지니어링에서 가장 먼저 고려해야 할 요소 중 하나가 되었다.

기존 소프트웨어 개발에서도 정확성은 중요했지만 AI 시스템에서는 조금 다른 문제가 발생한다.

기존 프로그램은 작성된 코드와 입력값이 동일하다면 대부분 동일한 결과를 만들어낸다. 반면 LLM 기반 시스템은 동일한 요청에서도 결과가 달라질 수 있으며, 사용자의 의도를 잘못 해석하거나 잘못된 정보를 근거로 판단할 수도 있다.

특히 AI 에이전트는 단순히 답변을 생성하는 것을 넘어 파일 수정, 코드 작성, API 호출, 데이터 조회와 같은 행동까지 수행하기 때문에 잘못된 판단 하나가 이후 작업 전체에 영향을 줄 수 있다.

따라서 AI 엔지니어링에서 정확성을 높인다는 것은 단순히 좋은 모델을 사용하는 것만을 의미하지 않는다.

AI가 올바른 요구사항을 이해하고, 올바른 정보를 사용하고, 올바른 행동을 수행했으며, 그 결과가 실제 요구사항과 일치하는지를 시스템적으로 검증할 수 있어야 한다.

---

왜 AI 엔지니어링에서 정확성이 더 중요해졌을까?

초기의 생성형 AI는 대부분 사용자가 질문하면 답변을 생성하는 형태였다.

사용자 질문
    ↓
LLM
    ↓
답변

답변이 조금 틀리더라도 사용자가 결과를 확인하고 다시 질문할 수 있었다.

하지만 AI 에이전트에서는 구조가 달라진다.

사용자 요청
    ↓
AI Agent
    ↓
코드 수정
    ↓
Tool 호출
    ↓
테스트 실행
    ↓
파일 변경
    ↓
PR 생성

AI가 직접 행동하기 시작하면서 하나의 잘못된 판단이 여러 단계로 전달될 수 있다.

예를 들어 AI가 요구사항을 잘못 이해한 상태에서 코드를 수정하면 코드 자체는 정상적으로 실행되고 테스트까지 통과할 수도 있다.

문제는 잘못 이해한 요구사항을 정확하게 구현했다는 것이다.

잘못된 요구사항 해석
        ↓
정상적인 코드 구현
        ↓
테스트 성공
        ↓
잘못된 기능 완성

즉 코드가 정상적으로 동작하는 것과 실제 요구사항을 만족하는 것은 서로 다른 문제다.

AI의 자율성이 높아질수록 사람이 모든 중간 과정을 확인하기 어려워지기 때문에 결과가 올바른지를 시스템이 스스로 검증할 수 있는 구조가 필요해진다.

---

1. 요구사항을 검증 가능한 형태로 만든다

정확성을 높이기 위한 첫 번째 단계는 모델을 변경하는 것이 아니라 요구사항을 명확하게 만드는 것이다.

다음과 같은 요청이 있다고 해보자.

예약 취소 기능 수정해줘.

사람이라면 기존 업무 맥락을 바탕으로 어느 정도 의도를 추측할 수 있지만 AI에게는 여러 가지 해석이 가능하다.

따라서 다음처럼 성공 조건을 명확하게 만들 수 있다.

일반 회원
- 예약 시작 24시간 전까지 취소 가능

VIP 회원
- 예약 시작 2시간 전까지 취소 가능

공통
- 취소 시 기존 환불 정책 유지
- 이미 시작된 예약은 취소 불가능

이렇게 요구사항을 작성하면 이후 테스트나 평가 기준으로 그대로 사용할 수도 있다.

즉 좋은 요구사항은 단순한 설명이 아니라 AI의 결과를 판정할 수 있는 명세(Specification)가 되어야 한다.

---

2. 테스트를 이용해 결과를 기계적으로 검증한다

코드 생성 에이전트에서 가장 강력한 검증 방법 중 하나는 여전히 테스트다.

AI에게 단순히

코드가 제대로 작성됐는지 다시 확인해.

라고 요청하는 것은 강한 검증 방법이 아니다.

코드를 작성한 모델이 자신의 결과를 다시 검토하는 것이기 때문이다.

대신 AI 외부에 독립적인 검증 장치를 둔다.

Agent
   ↓
코드 작성
   ↓
Unit Test
Integration Test
Regression Test
Type Check
Lint
Static Analysis
   ↓
성공 / 실패

AI가 자신이 잘했다고 주장하는 것이 아니라 실행 가능한 검증 기준이 결과를 판단하도록 만드는 것이다.

이러한 구조는 TDD의 Red → Green 방식과도 연결된다.

실패하는 테스트 작성
        ↓
RED
        ↓
Agent 구현
        ↓
테스트 실행
        ↓
GREEN

먼저 실패하는 테스트를 만들어두면 AI가 어떤 기능을 구현해야 하는지 명확한 목표가 생긴다.

또한 변경 전에는 실패하고 변경 후에는 성공했다는 것을 확인할 수 있기 때문에 구현과 결과 사이의 인과관계도 확인할 수 있다.

---

3. Eval을 이용해 테스트하기 어려운 영역을 검증한다

모든 AI 시스템을 전통적인 테스트 코드만으로 검증할 수 있는 것은 아니다.

예를 들어 다음과 같은 작업은 정답이 하나로 결정되지 않을 수 있다.

문서 요약
고객 문의 답변
코드 리뷰
보고서 작성
검색 결과 정리
에이전트의 Tool 선택

이런 영역에서는 평가(Evaluation, Eval)가 필요하다.

Eval은 특정 입력을 AI에게 제공하고 결과가 기대하는 기준을 만족하는지 평가하는 방식이다.

평가 방법은 크게 다음과 같이 나눌 수 있다.

코드 기반 평가

명확하게 판정 가능한 결과에 적합하다.

정확한 값 비교
정규식 검사
JSON Schema 검증
테스트 코드
정적 분석
DB 상태 확인

가능하다면 가장 우선적으로 사용할 수 있는 방식이다.

모델 기반 평가

정답을 단순한 코드로 판단하기 어려울 때 다른 모델을 평가자로 사용할 수 있다.

예를 들어 고객 답변을 다음 기준으로 평가할 수 있다.

질문에 실제로 답했는가?
잘못된 정보를 포함하지 않았는가?
회사 정책을 위반하지 않았는가?
불필요하게 장황하지 않은가?

다만 평가 모델 역시 AI이기 때문에 평가 기준을 구체적으로 정의하고 필요한 경우 사람의 평가와 비교해 신뢰성을 확인해야 한다.

사람 평가

업무적으로 중요한 판단이나 자동 평가가 어려운 영역에서는 여전히 사람이 최종 평가자가 될 수 있다.

중요한 것은 모든 결과를 사람이 확인하는 것이 아니라 자동 평가가 어려운 영역에 사람을 배치하는 것이다.

---

4. 회귀 테스트를 반드시 관리한다

AI가 새로운 기능을 잘 구현했다고 해서 기존 기능까지 정상이라는 보장은 없다.

예를 들어 VIP 예약 취소 기능을 추가한다고 해보자.

기존

일반회원
24시간 전까지 취소 가능

여기에 새로운 요구사항이 추가된다.

VIP
2시간 전까지 취소 가능

AI가 VIP 테스트만 성공시키면서 기존 일반 회원 로직을 깨뜨릴 수도 있다.

따라서 새로운 기능을 검증하는 것과 기존 기능이 유지되는지를 검증하는 것은 별도로 관리해야 한다.

새로운 기능

Capability Test
"새로운 기능을 수행할 수 있는가?"

그리고

기존 기능

Regression Test
"기존에 잘하던 것을 여전히 잘하는가?"

두 가지가 필요하다.

AI 시스템에서는 모델, 프롬프트, Tool, 컨텍스트 구조 중 하나만 변경되어도 결과가 달라질 수 있기 때문에 회귀 검증의 중요성이 더욱 커진다.

---

5. 올바른 컨텍스트를 제공한다

AI의 정확성 문제를 모델의 추론 능력 문제라고만 생각하기 쉽지만 실제로는 잘못된 Context 때문에 발생하는 오류도 많다.

예를 들어 회사 정책이 변경되었는데 AI에게 이전 정책 문서를 제공하면 모델은 주어진 정보를 기준으로 매우 논리적인 오답을 만들 수 있다.

잘못된 Context
      ↓
정확한 추론
      ↓
잘못된 결과

따라서 다음과 같은 부분을 관리해야 한다.

최신 문서인가?
현재 코드 버전과 일치하는가?
관련 있는 정보인가?
신뢰할 수 있는 출처인가?
서로 충돌하는 문서가 존재하지 않는가?

RAG를 사용한다면 단순히 검색 결과를 가져오는 것으로 끝나지 않고 검색된 정보 자체가 정확한지도 평가해야 한다.

---

6. 온톨로지를 이용해 업무 지식을 명시적으로 관리한다

AI가 복잡한 업무 영역을 다루기 시작하면 단순한 문서 검색만으로는 관계를 정확하게 이해하기 어려울 수 있다.

예를 들어 다음과 같은 관계가 있다고 하자.

VIP
 ↓
Customer
 ↓
Reservation
 ↓
CancellationPolicy
 ↓
취소 제한 시간

이러한 업무 개념과 관계를 온톨로지로 관리하면 AI가 매번 자연어 문서를 읽고 관계를 추측할 필요가 없다.

Customer
 ├─ membershipGrade
 └─ Reservation

VIP
 └─ CancellationPolicy

CancellationPolicy
 └─ cancellationLimit

하지만 온톨로지를 사용한다고 해서 자동으로 정확성이 확보되는 것은 아니다.

온톨로지에 잘못된 관계가 정의되어 있다면 AI는 그 잘못된 지식을 정확하게 사용할 수 있다.

따라서 온톨로지를 사용하는 시스템에서는 다음도 검증 대상이 된다.

Entity가 올바르게 정의되어 있는가?
Relation이 실제 업무 관계와 일치하는가?
Rule이 최신 정책인가?
중복된 개념이 존재하지 않는가?
실제 데이터와 Ontology가 일치하는가?

즉 온톨로지는 정확성을 높이기 위한 수단인 동시에 새로운 검증 대상이 된다.

---

7. Agent가 실패하면 다시 수정할 수 있는 루프를 만든다

AI가 항상 첫 번째 시도에서 정확한 결과를 만들어낼 것이라고 기대하는 것은 현실적이지 않다.

따라서 첫 번째 결과의 정확도만 높이는 것보다 실패를 감지하고 스스로 수정할 수 있는 구조를 만드는 것이 중요하다.

Task
 ↓
Agent 실행
 ↓
Test / Eval
 ↓
실패
 ↓
실패 정보 전달
 ↓
Agent 수정
 ↓
재검증
 ↓
성공

이것이 AI 엔지니어링에서 Harness가 중요한 이유 중 하나다.

Harness는 Agent 주변에서 테스트, 평가, Tool, 로그, 권한 등의 환경을 제공하면서 Agent가 반복적으로 작업을 수행할 수 있게 한다.

핵심은 단순하다.

AI의 첫 번째 답을 믿는 것

        ↓

AI의 결과를 검증하고
틀렸으면 다시 수정시키는 것

정확성을 모델 하나의 능력에서 시스템 전체의 능력으로 바꾸는 것이다.

---

8. 불확실한 상황에서는 행동하지 않도록 한다

정확성을 높이는 방법은 항상 더 좋은 답을 생성하는 것만 있는 것이 아니다.

정확하지 않을 가능성이 높은 상황에서는 행동하지 않는 것도 정확성을 높이는 방법이다.

예를 들어 Agent의 확신이나 검증 상태에 따라 행동 범위를 나눌 수 있다.

충분한 정보 존재
+ 검증 성공
→ 자동 실행

정보 부족
→ 추가 정보 검색

여러 정책 충돌
→ 사람에게 확인

위험도가 높은 작업
→ 사람 승인

검증 실패
→ 실행 중단

특히 데이터 삭제, 운영 배포, 결제, 권한 변경처럼 잘못된 행동의 비용이 큰 작업에서는 잘못된 결과를 내는 것보다 실패 상태로 종료하는 것이 더 올바른 결과일 수 있다.

---

9. 실행 과정을 추적할 수 있어야 한다

AI가 잘못된 결과를 만들었을 때 단순히 실패했다는 사실만 알아서는 정확성을 개선하기 어렵다.

다음과 같은 정보를 추적할 수 있어야 한다.

어떤 요구사항을 받았는가?
어떤 Context를 사용했는가?
어떤 Tool을 호출했는가?
어떤 파일을 수정했는가?
어떤 테스트가 실패했는가?
몇 번 재시도했는가?
어떤 규칙을 근거로 판단했는가?

예를 들어 다음과 같은 실행 경로를 확인할 수 있다면

VIP
 ↓
MembershipPolicy
 ↓
CancellationPolicy
 ↓
2시간
 ↓
예약 취소

오류가 발생했을 때

Agent의 추론이 잘못됐는지
Context가 잘못됐는지
Ontology가 잘못됐는지
코드 구현이 잘못됐는지

구분할 수 있다.

따라서 관측 가능성은 운영 편의성뿐만 아니라 정확성을 지속적으로 개선하기 위한 기반이 된다.

---

정확성을 높이는 전체 구조

결국 AI 엔지니어링에서 정확성을 높이는 방법을 하나의 흐름으로 정리하면 다음과 같다.

명확한 요구사항
      ↓
신뢰할 수 있는 Context / Ontology
      ↓
Agent 실행
      ↓
Test / Eval
      ↓
┌──── 성공 ────┐
│              │
│             결과
│
실패
 ↓
오류 원인 전달
 ↓
Agent 수정
 ↓
재검증
      ↓
Regression Test
      ↓
최종 결과

여기서 중요한 점은 정확성을 특정 모델 하나에게 의존하지 않는 것이다.

더 좋은 모델을 사용하면 물론 정확도가 올라갈 수 있다.

하지만 모델은 언제든 변경될 수 있고 같은 모델에서도 작업이나 Context에 따라 결과가 달라질 수 있다.

따라서 실제 AI 엔지니어링에서는

• 명확한 요구사항
• Test
• Eval
• Regression Test
• Context Engineering
• Ontology
• Harness
• Human Gate
• Observability

같은 여러 장치를 함께 사용해 정확성을 확보한다.

결국 AI 엔지니어링에서 정확성을 높인다는 것은 AI가 틀리지 않도록 만드는 것보다는 AI가 틀렸을 때 이를 발견하고 수정할 수 있는 시스템을 만드는 것에 더 가깝다.

AI의 자율성이 높아질수록 사람의 역할 역시 모든 결과를 직접 확인하는 것에서 AI가 올바른 방향으로 움직이는지 검증할 수 있는 환경과 기준을 만드는 것으로 이동하게 된다.

특히 **`정확성 = 모델 성능`이 아니라 `검증 가능한 시스템을 만드는 것`**이라는 방향으로 잡았습니다. 현재 에이전트 평가에서도 자동 평가, 회귀 평가, 실행 기록 확인을 핵심으로 다루고 있고, 에이전트가 자율적으로 여러 단계를 수행할수록 오류가 누적될 수 있기 때문에 이런 구조가 필요합니다.