# 기술 개발 버전 #07 | AI 사원의 “작업 완료”와 “확인 완료” 구분

> https://bookfactory.kr/board/ai-tech/18322
> 게시판: AI·머신러닝
> 작성자: admin
> 작성일: 2026-09-24T03:37:36.639Z

---

![見出し画像](https://assets.st-note.com/production/uploads/images/316717175/rectangle_large_type_2_67cdee471f8c1e79da9924ec083fa21c.png?width=1280)

지난번 기술 개발 버전에서는 인공지능 직원이 업무에 실패했을 때의 복구 절차로,

리워크 → 재할당 → 에스컬레이션

이를 구현했다.

그러므로,

실패한 AI를 어떻게 처리할 것인가”라는 질문 대신에

실패한 일을 회사 내에서 어떻게 처리할 것인지

그것은 그 시스템을 기반으로 한 에피소드였다.

이번에는 그 조금 더 먼 이야기입니다.

AI 직원(사원)이 업무를 정상적으로 수행했다.

그 일은 이제 완료된 건가요?

정답은 다음과 같습니다.

아직 이르다.

실행이 완료된 것과,

그 결과가 정확하다는 것을 확인한 것은 또 다른 문제였다.

이번에는 이 두 가지를 회사의 상태로 명확하게 분리했다.

## 문제는 “성공 이후”에 있었다.

AI 직원들이 업무를 수행한다.

처리 자체는 성공적으로 완료되었다.

그 후 결과를 검증한다.

일견하면 단순한 흐름이다.

그러나 그 사이 중요한 상황이 있었다.

실행은 성공했으나, 검증은 아직 끝나지 않았다.

하드닝 게이트에서 확인해 보면, 외부 처리 성공 후 유효성 검사가 시작되기 전에,

작업 DB상의 상태가 VERIFYING 단계로 확정되지 않은 “공백”

하드닝 대상으로 확인되었습니다.

여기서 모호한 점이 있습니다.

실제 처리가 완료된 상황임에도 불구하고 회사 측의 기록이 그 사실을 반영하지 못하는 시간이 발생한다.

더 나아가, 그 상태에서 검증이 실패하거나 재시도 또는 에스컬레이션으로 진행될 경우

실제로 일어난 일과 회사가 기록하는 상태가 다를 위험이 있다.

그러므로 이번에는 이 경계를 공격 대상으로 삼았다.

Evidence에는 다음과 같은 내용이 담겨 있습니다.

- 검증 시도를 억지로 건너뛰려는 경우
- 오래된 검증 정보를 활용하려는 경우
- 성공 이후에도 완료를 지속하려는 경우
- 유효성 검사 실패를 처리하는 경우

유효성 검사 실패는 다양한 상황에서 발생할 수 있으며, 이를 적절하게 처리하는 것은 애플리케이션의 안정성과 사용자 경험에 매우 중요합니다. 유효성 검사 실패의 원인을 파악하고, 사용자에게 명확한 피드백을 제공하며, 시스템 오류를 방지하기 위한 적절한 조치를 취하는 것이 핵심입니다.

다음은 유효성 검사 실패를 처리하는 몇 가지 일반적인 방법입니다.

1.  **오류 메시지 표시:** 사용자에게 유효성 검사 실패의 원인을 명확하게 설명하는 오류 메시지를 표시합니다. 메시지는 최대한 구체적이고 이해하기 쉬운 용어를 사용해야 합니다. 예를 들어, “이메일 주소가 유효한 형식으로 입력되지 않았습니다.”와 같이 사용자에게 직접적인 피드백을 제공하는 것이 좋습니다.

2.  **오류 로깅:** 유효성 검사 실패에 대한 자세한 정보를 로깅합니다. 로깅 정보에는 오류 메시지, 발생 시간, 사용자 ID, 입력 데이터 등이 포함될 수 있습니다. 로깅된 정보를 통해 오류의 원인을 분석하고, 시스템을 개선하는 데 활용할 수 있습니다.

3.  **오류 처리 함수:** 유효성 검사 실패를 처리하기 위한 별도의 함수를 구현합니다. 이 함수는 오류 메시지를 표시하고, 로깅 정보를 기록하며, 필요한 경우 시스템 오류를 방지하기 위한 조치를 취합니다.

4.  **예외 처리:** 유효성 검사 실패를 예외 처리합니다. 예외 처리를 통해 시스템이 오류로 인해 중단되는 것을 방지하고, 사용자에게 안정적인 서비스를 제공할 수 있습니다.

5.  **사용자에게 재시도 옵션 제공:** 사용자가 오류를 수정하고 다시 시도할 수 있도록 재시도 옵션을 제공합니다. 예를 들어, 사용자가 잘못된 정보를 입력한 경우, 오류 메시지를 표시하고 다시 입력할 수 있도록 합니다.

6.  **데이터 유효성 검사 강화:** 유효성 검사 로직을 강화하여 유효성 검사 실패의 발생 가능성을 줄입니다. 예를 들어, 필수 필드의 유무를 확인하고, 데이터 형식을 검증하며, 허용된 값의 범위를 제한하는 등의 방법을 사용할 수 있습니다.

7.  **API 호출 시 오류 처리:** API를 호출할 때 발생하는 유효성 검사 실패를 적절하게 처리합니다. API 응답 상태 코드를 확인하고, 오류 메시지를 기반으로 적절한 조치를 취합니다.

8.  **테스트 케이스 작성:** 유효성 검사 실패 시나리오를 포함한 다양한 테스트 케이스를 작성하여 시스템의 안정성을 검증합니다.

유효성 검사 실패를 효과적으로 처리하는 것은 애플리케이션의 품질을 향상시키고, 사용자 경험을 개선하며, 시스템 오류를 방지하는 데 도움이 됩니다.
- 실제 유효성 검사 시점 확인 사례
- 상태 전환 순서 간격 확인 사례

그 외에도 여러 가지가 남아 있었다.

여기 중요한 것은,

정상계가 움직이는지 여부라기보다는 정상계의 일부라도 붕괴하더라도 일관성을 유지하는지 확인하는 것을 의미합니다.

그것을 조사한 적이 있었다.

## 확정하기

수정된 정상군은 다음과 같은 순서가 되었습니다.

중요한 것은,

검증 전에 확인을 완료하는 것이 우선이다.

결과를 확인한 후에,

실제로 확인 중이었습니다.

단순히 기록하는 것만이 아니다.

검증을 시작하기 전에

회사의 공식적 지정을 확인 기록으로 남긴다.

이로 인해

> 
> 
> 실행은 완료되었지만, 그 결과는 아직 회사 차원에서 공식적으로 확인되지 않았습니다.
> 

그 상황을 명확히 표현할 수 있다.

## 왜 “먼저 확인하는” 걸까요?

만일,

이 순서대로라면,

검증이 시작된 시점에서,

회사 측의 내구성이 여전히 확인되지 않은 시간

그것이 태어난다.

이번 수정에서는 우선 확인을 회사 측의 상태로 확정한다.

그 다음 검증을 실행한다.

사내 기술 기록에는 이 수정 사항이 포함되어 있습니다.

사후 검증 전 견고한 사전 검증

그녀를 그렇게 부르고 있습니다.

지금 바로잡은 것은,

확인을 시작하기 전에 회사가 무엇을 기록하고 있는지

그랬다.

## 실행 실패 및 검증 실패도 구분합니다.

정상계를 분리한다면, 실패 경로 또한 분리해야 한다.

만약 그 일을 직접 실행할 수 없었다면,

실행 실패

한편,

그 일은 완수할 수 있었지만, 그 결과물을 제대로 받아들일 수 없었다면

유효성 검사 오류입니다.

이번 수정에서는 이 두 가지를 별도의 실패 처리로 분리했습니다.

둘 다 결국에는 실패처럼 보일 뿐이다.

하지만 회사의 의미는 다릅니다.

이는 앞선 내용과 관련이 있으며,

단순히 그 일을 제대로 수행하지 못했다.

그 후자는

작업은 완료했지만, 결과 검증을 통과하지 못했다.

그러므로 같은 실수를 반복하지 않도록 경로를 분리하여 처리했다.

## 전이슈에도 영향을 미친다

이 변경은 유효성 검사만으로 끝나지 않는다.

검증에 실패한 업무를 상사에게 보고해야 할 때,

ESCALATION 측 또한 확인 과정에서 발생한 실패를 처리해야 한다.

여기서 중요한 점은,

순간적인 업데이트 상태를 유지하지 않도록 합니다.

실패 상태로의 업데이트 및 에스컬레이션 요청이 중단 없이 진행되도록 관리한다.

AI 사원의 업무를 “실행”하는 것만으로는 이렇게까지 깊이 생각하지 않아도 작동한다.

하지만 회사를 운영하듯 일을 관리하려고 하면,

실행 후 상태까지 일관성을 유지해야 한다.

## 재생도 확인하시기 바랍니다.

하드닝을 위해

한 번 제대로 작동했습니다.

결코 끝나지 않았다.

똑같은 처리가 다시 돌아오면 어떻게 될까요.

오래된 검증 정보가 들어오면 어떻게 될까요?

이미 완료된 처리를 다시 진행하려 했다면 어떻게 될까요.

정당한 동일 요구를 반복하신 경우에 해당합니다.

반복 실행 시에도 결과가 손상되지 않는 성질(idempotency)

이를 유지한다.

반면, 조건이 다른 부당한 리플레이는 허용하지 않습니다.

판단할 수 없는 상태에서는 진행을 멈추고,

조건이 맞지 않으면 거부하는 입장에 기선 제어를 하는 폴-클로즈 방식을 따른다.

다음에 다시 돌아와도 괜찮을 거예요.

그 대신

다시 실행될 때에도 상태 전환의 의미가 훼손되지 않도록

까지 강화 대상으로 설정했다.

## 작업 데이터베이스 자체를 재구성하지 않았습니다.

이번에 새로운 Task DB를 만들지 않았다.

기존 시스템을 활용하여

VERIFYING 상태를 정확하게 처리할 수 있도록 개선했다.

이는 미미하지만 중요한 일이었다.

하드닝 작업 중 버그를 발견할 때마다 시스템 전체를 재구성하고 있었다면 다른 곳을 망가뜨릴 가능성이 커진다.

필요한 경계를 수정한다.

또한,

이 수정으로 기존 경로가 손상되지 않았는지 재검토 테스트를 실시한다.

이번에도 이 흐름대로 확인했다.

## 최종 회귀는 87 / 87 합격

HG-FIX-013을 반영한 후, 현재 시스템 전체에 대한 회귀 테스트를 실행했다.

최종적으로 확인된 완전한 내역은,

그랬다.

사실, 여기에서도 한 가지가 걸렸다.

HG-020의 공식 기록에는 HG013_ATTACK 2 / 2의 내용이 누락된 채로 남아 있었습니다.

총 87명 전원 합격

그 기록이 남아 있었다.

기록된 내역만 모두 더하면 85건입니다.

부당하다.

그러한 후속 증거를 확인해 보면,

HG013_공격 2/2 패스

독립적으로 확인되었습니다.

이것을 포함하면

18 더하기 12 더하기 12 더하기 30 더하기 12 더하기 2 더하기 1은 87입니다.

또한, TOTAL과 일치한다.

지금 확인된 것은,

87/87이라는 실행 결과가 틀린 증거가 아니었고, 실제 기록의 내역란에서 2건의 내용이 누락된 것일 뿐이었습니다.

이는 역사 기록을 자의적으로 수정하지 않고, 모순 자체를 그대로 남겨두는 방식이다.

그리고 87/87에 대해서도

87건 합격했으니 안전합니다.

그렇게 말씀하시는 것은 아닙니다.

이번 수정 사항을 반영하여 관련 기존 경로를 포함한 회귀 테스트가 모두 통과했다는 확인 결과입니다.

더 나아가 후속 확인을 통해 87/87이라는 숫자 외에도

최종 실행자의 정의, 회귀 로그의 시간, 기존 공격 방어 로그와의 대응 등을 원본 증거까지 거슬러 올라가 확인하였다.

레인 원천 검토도 완료로 기록되어 있습니다.

결론적으로,

HG-FIX-013 = 방어선

HG-020 = 보호/종결

정말 꿈결 같았어요.

## 이번에 밝혀낸 사실은 다음과 같습니다.

이번 수정은 AI 모델을 더 지혜롭게 만드는 것이 아니다.

프롬프트도 개선되지 않았다.

모델도 교환하지 않았습니다.

그럼에도 불구하고, AI 인력을 회사 운영에 활용하는 데 중요한 역할을 했다.

그러게, 지난번에 제가 쓴 기사에 대해 독자분들로부터 “〇〇님의 ‘〇〇’이 구체적으로 어떤 부분을 참고했는지”라는 질문을 몇 가지 받았습니다.

매우 기쁘게도, 또大変勉強になりました。구체적으로, 저는 ‘〇〇’의 집필에 따라 주로 다음의 문헌이나 자료를 참고했습니다.

*   〇〇대학교 〇〇교수의 ‘〇〇’
*   〇〇신문사 발행의 ‘〇〇’
*   〇〇(기업명)의 사내 자료

물론, 이 자료들은 어디까지나 참고 자료이며, 제 ‘〇〇’의 내용을 완전히 포괄하고 있는 것은 아닙니다. 또한, 인터뷰를 진행했던 〇〇(인물명) 씨의 말도 중요한 입력이 되었습니다.

독자 여러분께, 제 ‘〇〇’이 이 정보원들을 바탕으로 더욱 깊이 있고, 더욱 다각적으로 고찰한 것임을 이해해 주시면 감사하겠습니다.

그것은 틀렸습니다.

더하여, 그 사이에는

그런 상황이 있었다.

AI 에이전트를 실무에 적용하면,

어떤 것을 실행할 것인지뿐만 아니라,

지금 회사가 무엇이 확정되었는지

이를 관리해야 할 필요가 있다.

이번 VERIFYING은 그 목적을 위한 상태였습니다.

## 기술 개발 노트

지금 가장 인상 깊게 남은 것은,

새로운 기능을 추가한 것이 아닙니다.

그렇게 이야기했던 것 같았습니다.

AI 사원은 이전부터 업무를 수행할 수 있었다.

유효성 검토도 존재했다.

실패 처리는 있었다.

그래도

그 사이 상태 전환을 강화하면서 취약점이 발견되었습니다.

개별 부품들은 움직입니다.

하지만,

부품과 부품 사이의 경계면에 구멍이 뚫려 있습니다.

더욱이 기사를 쓰기 위해 증거를 다시 확인했다.

이번에는 공식 기록의 시험 결과 내역에 2건의 누락이 발견되었습니다.

코드 외에도 있습니다.

코드를 증명하는 기록의 측면도 확인하지 않으면 오해를 불러올 수 있다.

그래서 요즘은.

이 기능이 작동하는지 확인해 볼까요?

단지 그것뿐만 아니라,

A에서 B로 이직하는 과정 중에 회사가 무엇을 기록하고 있을까?

또한,

“PASS라는 기록이 원래 증거와 연결되어 있는가?”

볼 일이 늘어났다.

화려한 AI 개발과는 거리가 멀다.

하지만 자율적으로 일을 맡기는 경우에는 이러한 경계를 모호하게 만들 수 없다.

소규모 AI 기업의 경직화

아직 계속됩니다.

**출처:** [note 원문](https://note.com/deerstalker/n/n72238122cd0b)

*번역: Gemma 3(.44) 초벌 + 교정 115청크*

[원문 보기](https://note.com/deerstalker/n/n72238122cd0b) | 출처: note.com