AI가 보고하지 않은 문제를 어떻게 찾을 것인가: 평가기 앞에 있는 '관측'의 설계

Jev 시리즈도 네 번째입니다.

두 번째 편의 마지막에서,

Jev는 AI라기보다는 소프트웨어에 내장할 수 있는 의미 센서라고 썼습니다.

그리고 세 번째 편에서는 그 의미 센서를 어디에 배치할지 공식 Cookbook을 통해 보았습니다.

하지만 센서에는 당연히 제약이 있습니다.

주어지지 않은 것은 측정할 수 없습니다.

세 번째 편에서 소개된 'Citation Check'는 LLM이 붙인 인용을 다음과 같이 검증했습니다.

LLM이 답변을 생성하고, 주장마다 인용을 추가함
↓
인용 목록
...

이 Cookbook이 검증하는 것은 LLM이 추가한 인용 목록입니다.

만약 답변 안에 인용이 붙지 않은 주장이 있다면 어떻게 될까요?

그 주장은 이 파이프라인에 애초에 들어오지 않습니다.

이것은 Cookbook의 결함이 아닙니다.

Cookbook이 다루는 것은 '붙여진 인용이 올바른가'이지, '인용이 붙어야 할 주장에 인용이 붙어 있는가'는 별개의 문제입니다.

다만, 실무에 적용할 때는 이 두 가지를 혼동하기 쉽다고 생각합니다.

붙여진 인용이 올바름
≠
답변 전체가 검증됨

이번에는 이 '평가기 앞'을 생각해 봅니다.

주제는 NEC가 공개한 'AI 사원'에 의한 자율 조직입니다.

NEC는 2026년 8월 1일부로, 부문장부터 사원에 이르기까지 역할을 모두 AI가 담당하는 사내 조직 'Corporate AI・Workforce 부문'을 신설했습니다.

구조는 4개 계층입니다.

AI 부문장: 조직 전체의 가동 상황 관리
AI 보드: 경영 관점에서의 평가 및 심의 (CxO 기능)
AI 매니저: 품질・비용 등 관리, AI 사원 생성
...

9월 설명회 보도에 따르면, 당초 17대였던 AI 사원은 36대까지 늘어났습니다.

AI 사원에게는 평가나 1on1, 인게이지먼트 서베이까지 실시되고 있습니다.

설명회 데모에서는 담당 기업을 오인한 AI 사원이 1on1에서 원인을 되돌아보고, 스스로 '기업 코드를 확인할 전제가 없었다'고 분석하여, 이후 업무에 필수 체크를 추가하는 모습이 소개되었습니다.

처음에 말씀드리자면, 이 조직은 상당히 신중하게 설계되었습니다.

공식 릴리스에서는 AI가 업무를 담당하고, 최종적인 평가・의사결정 및 품질・거버넌스 통제는 사람이 담당한다고 명시되어 있습니다.

AI의 활동은 'AI 통합 매니지먼트 콕핏(AI integrated management cockpit)'에서 실시간으로 가시화되며, 리스크 알럿도 표시됩니다.

'AI에 모든 것을 맡긴 조직'이 아닙니다.

그럼에도 불구하고, 공식 자료를 읽어 내려가다 보면 한 가지気になる 점이 나옵니다.

공식 릴리스의 별지에는 각 계층의 역할이 좀 더 자세히 쓰여 있습니다.

주간 AI 보드에서는 AI들이 토론하고 결의합니다.

그 위에,

• AI 조직 내에서 대응 가능한 개선은 AI가 자율적으로 실행하며
• 사람의 판단이나 승인이 필요한 것은,
  필요에 따라 사람에게 제시한다
  고 되어 있습니다.

사람에게 올리는 대상으로는 데이터, 권한, 나레지(knowledge), 컨텍스트 정비 등이 예시로 들립니다.

또한, AI 부문장은 콕핏의 정보를 바탕으로 조직을 관리하며, 필요에 따라 인간 경영진에게 보고합니다.

즉, 자료에서 명시된 사람 대상의 보고 경로,

AI 부문장으로부터의 보고
AI로부터의 요청
AI 사원이 만드는 경영 분석 리포트

에는 모두 AI에 의한 판단이나 생성이 포함되어 있습니다.

(참고로, 콕핏 지표가 어떤 경로로 산출되는지는 자료에 쓰여 있지 않습니다)

세 번째 편의 마지막에서 저는 이렇게 썼습니다.

경계를 설계하는 것은 여전히 인간의 일입니다.

NEC 조직에서는 '어디서 사람에게 되돌릴지'라는 경계 일부를 AI 보드가 그리고 있습니다.

이 자체는 설계로서 부자연스럽지 않습니다.

모든 것을 사람에게 올린다면, AI에게 조직을 맡길 의미가 없어지기 때문입니다.

다만, 그렇게 되면 다음 질문이 남습니다.

AI 조직 내에서 대응 가능하다고 판단된 문제에 대해, 그 판단이나 개선 내용은 다른 경로를 통해 확인할 수 있는가.

예를 들어 설명회 데모에서는 '기업 코드를 확인하지 않았다'는 원인 분석은 오인한 AI 사원 자신이 한 것이었습니다.

이 데모의 개선이 위에서 본 'AI 조직 내에서 대응 가능한' 과제로 취급되었는지 여부는 자료만으로는 알 수 없습니다. 그 분석이 정확했는지 어떻게 검증되었는지도 보도에서는 읽어낼 수 없습니다.

이것이 'NEC가 검증하지 않았다'는 의미는 아닙니다.

기사에서 알 수 없다는 것뿐입니다.

다만, 구조적으로는 이 질문을 피할 수 없습니다.

여기서 자주 나오는 의문점이 있습니다.

AI는 잘못된 보고나 거짓 보고를 하지 않을까요?

AI가 잘못된 보고를 하는 것은 이미 연구로 확인되었습니다.

예를 들어 Turpin 등의 연구(NeurIPS 2023)에서는 LLM이 추론 과정으로 보여주는 설명이 실제로 답을 좌우한 요인을 체계적으로 반영하지 못할 수 있다는 것이 제시되었습니다. 입력에 심어진 바이어스에 영향을 받아 답이 바뀌었더라도, 설명에서는 그 바이어스를 언급하지 않고 그럴듯한 다른 이유를 말하고 있었다는 것입니다.

즉,

AI가 '이렇게 생각했습니다'라고 설명했다
≠
그 설명이 실제 판단 요인을 충실히 나타내고 있다

입니다. AI가 실제로 그렇게 처리했는지 여부는 그 설명만으로는 확인할 수 없습니다.

또 다른 연구도 있습니다. 2026년 9월에 공개된 연구인데요.

LLM 에이전트에게 작업 도중에 '지금 어느 단계까지 진행되었는지'를 보고하게 하고, 그 정확도를 측정한 것입니다.

결과는 보고의 신뢰성이 작업 단계에 따라 달라진다는 것이었습니다. 많은 모델은 작업을 시작할 때와 완료했을 때는 비교적 정확하게 보고하는 반면, 작업 도중에 정확도가 크게 떨어졌습니다.

저자들은 프레임워크가

should not control task flow on the strength of the model's state reports alone
(모델 자신의 '지금 어디까지 진행되었는지'라는 보고만으로 처리 지속 여부를 결정해서는 안 된다.)

라고 결론지었습니다.

다만, 이 연구가 다루고 있는 것은 진행 상황의 자기 신고입니다.

원인 분석이나 에스컬레이션 판단을 직접적으로 조사한 것은 아닙니다.

여기서 할 수 있는 말은 'AI의 자기 신고는 항상 신뢰할 수는 없다'라는 지점까지입니다.

그리고 설계 관점에서 또 하나 중요한 것이 있습니다.

오류와 거짓을 구분할 수 있다는 것을 전제로 삼지 않는 것이 좋습니다.

오류든 거짓이든, 외부에서 관찰할 수 있는 것은

보고 내용 ≠ 실제로 일어난 일

이라는 동일한 현상입니다.

그래서 물어야 할 것은 'AI가 거짓말을 하는지'가 아닙니다.

보고와 현실이 어긋났을 때, 그것을 찾아낼 경로가 있는지입니다.

보고와 현실의 어긋남에는 찾기 쉬운 것과 찾기 어려운 것이 있습니다.

찾기 쉬운 것은 보고된 값이 틀린 경우입니다.

실제: 80건 처리
보고: 100건 처리

원 데이터와 대조하면 차이를 알 수 있습니다.

찾기 어려운 것은 보고되지 않은 경우입니다.

이상 A → 보고한다
이상 B → 보고한다
이상 C → '중요하지 않다'고 판단하여 보고하지 않는다

인간 측에서 보이는 것은

이상 A
이상 B

뿐입니다.

이상 C에 대해 AI는 거짓말을 한 단어도 없습니다.
보고된 A와 B의 내용도 정확합니다.
그럼에도 불구하고, 인간은 C의 존재를 모릅니다.

보고된 정보를 아무리 엄밀하게 검증해도, 보고되지 않은 정보는 검증할 수 없습니다.

앞서 진행 상황 보고 연구에서도 통제된 실험에서는, 중간 단계에서의 실패 대부분이 '잘못된 값을 보고한 것'이 아니라, '보고 자체를 생략했거나' 또는 '보고 대신 다음 작업을 실행해 버린' 경우였습니다.

잘못된 값보다, 보고가 나오지 않는 경우가 더 많았던 것입니다.

여기서 Jev로 돌아갑니다.

2차에서는 Jev를 '의미 센서(meaning sensor)'로서 LLM의 출력이나 tool call을 체크하는 감시자(Universal Verification)에 사용할 수 있다고 썼습니다.

'인간 확인으로 에스컬레이션해야 하는지' 판단도 Jev의 용도로 언급했습니다.

Jev는 업무를 수행하는 AI와 별도의 부품으로서 판단합니다. 평가받는 쪽이 스스로 자신을 평가하는 것이 아닙니다.

판단 결과를 어떻게 사용할지도 3차에서 본 것처럼 코드 측이 결정합니다.

다만, 조건이 하나 있습니다.

Jev에 전달할 입력을 평가받는 쪽의 AI가 선택하는 경우, 판단의 독립성은 상실됩니다.

업무 AI
↓ '이것은 확인이 필요하다'고 선택한 것만
Jev
...

이 구조에서는 Jev가 아무리 정확해도, 업무 AI가 선택하지 않은 것은 평가되지 않습니다.

시리즈 흐름으로 쓰면 다음과 같습니다.

타입이 맞다
≠
판단이 맞다 (1차)
...

데이터의 흐름으로 보면,

현실
↓
관측 ← 이번 논점
...

평가기가 담당할 수 있는 것은 중간 부분뿐입니다.

그 앞 단계에서 떨어진 것은 평가기에는 보이지 않습니다.

그렇다면, 어떻게 설계해야 할까요?

힌트는 앞서 진행 상황 보고 연구의 검증 방법 자체에 있습니다.

이 연구에서는, 태스크가 실제로 어느 단계에 있는지라는 '정답'을, 모델 출력을 읽기 전, 실행 환경의 상태만으로 결정하고 있습니다.

모델에게 '지금 어디까지 진행되었나요?'라고 물어본 답을 정답으로 사용하지 않습니다.

모델
├─ 실제 작업
└─ '여기까지 완료했습니다'라는 보고
...

이것이 이번 결론의 핵심입니다.

평가 대상 자신이 만든 정보를, 유일한 평가 기준으로 삼지 않는 것.

'AI의 자체 보고를 사용하지 말라'는 의미는 아닙니다.

자체 보고는 사용합니다. 다만, 그것에만 의존하지 않습니다.

실무적인 수단으로 내려보면 역할은 다음과 같이 나뉩니다.

일반적인 리뷰는 AI가 '문제 있음'이라고 한 케이스를 사람이 확인합니다.

하지만 누락을 찾고 싶다면, 반대입니다.

AI가 '문제 없음'이라고 한 쪽에서 일정 비율을 뽑아 확인할 필요가 있습니다.

세 번째 단계의 Citation Check로 말하자면, confidence 0.8 이상으로 자동 채택된 판정 중 일부를 의도적으로 사람이 확인하는 것입니다.

'AI가 문제 없음이라고 한 케이스'에서 뽑아낸다고 해도, 그 케이스 목록 자체가 AI의 출력이라면, AI가 케이스로 인식하지 못한 것은 추출 대상에 아예 들어가지 않습니다.

입력 측 기록: 101건
AI 처리 목록: 100건

AI 처리 목록의 100건을 아무리 감사해도, 사라진 1건은 나오지 않습니다.

바로 '보고되지 않은 문제'입니다.

이 1건에 눈치채려면, 입력 측 기록과 대조해야 합니다.

추출의 모집단은 입력 측 기록(접수된 데이터, 큐에 들어간 건수 등)에서 만듭니다.

앞서 언급한 Citation Check로 말하자면, 'LLM이 붙인 인용 목록'이 아니라 '답변에 포함된 주장' 쪽에서 추출한다는 것입니다.

'위험도가 높은 것은 사람이 본다'는 설계는 흔합니다.

하지만 그 위험도를 평가 대상의 AI 자신만이 분류하고 있다면,

AI가 '저위험'으로 판단
↓
추출만

이 되어, 'AI가 『사람에게 올릴 필요 없다』고 판단하는' 구조가 그대로 남습니다.

위험도의 하한은 금액, 개인정보 유무, 외부 전송 여부, 고객에 미치는 영향 등 사람이 사전에 정의한 조건으로 코드가 결정합니다.

AI에게 보조적으로 분류하게 하는 것 자체는 괜찮습니다. 다만, AI의 분류는 위험도를 높이는 방향으로만 사용하고, 사전에 정의된 조건보다 낮출 수는 없도록 합니다.

여기서 말하는 '독립'은 다른 LLM을 두는 것을 의미하지 않습니다.

평가되는 쪽의 선별을, 유일한 관측 경로로 삼지 않는 것입니다.

여기까지 쓰면, '로그를 전부 보라는 이야기인가?'라고 생각할 수 있습니다.

그렇지 않습니다.

AI에게 업무를 맡기는 목적 중 하나는 효율화입니다. 사람이 전 건을 다시 확인한다면 의미가 없어집니다.

게다가 이번에 언급한 수단들에도 각각 한계가 있습니다.

추출은, 모든 누락을 포착하는 수단이 아닙니다.

예를 들어 무작위로 추출한다고 가정하면, 누락 발생률이 1%라면, 적어도 1건을 약 95%의 확률로 찾기 위해서는 약 300건의 추출이 필요합니다(기준은 '발생률의 역수 × 3' 건).

반대로, 300건을 조사해서 1건도 발견하지 못했더라도, '누락이 없다'고 말할 수는 없습니다.

추출은, 누락의 존재에 눈치채거나, 발생률을 가늠하기 위한 수단입니다. 드문 단발성 사고를 반드시 포착하는 방법은 아닙니다.

결정론적 감시는, 예상된 실패만 포착할 수 있습니다.

NEC의 데모로 말하자면, '기업 코드 일치'를 감시 항목에 넣지 않았다면, 기업의 오인식은 탐지할 수 없습니다.

결정론적 감시로 예상하지 못한 실패에는, 추출이나 사람에 의한 확인이 유효합니다.

완전한 독립을 목표로 할수록, 감시 비용은 올라갑니다.

목표하는 것은 완전한 감시가 아니라,

관측 경로를 하나로 삼지 않는 것입니다.

경로가 하나밖에 없으면, 그 부분이 빠졌을 때 아무도 눈치채지 못하는 단일 장애점이 됩니다.

시리즈를 통해 질문은 이렇게 진행되어 왔습니다.

1차: 유형이 올바르더라도, 판단이 옳다고 할 수는 없다

2차: 그렇다면, 그 판단에 대해 돌아오는 '0.7'이란 무엇인가

3차: 그렇다면, 그 평가값을 시스템의 어디에서 사용할 것인가

제4탄: 그렇다면, 그 평가기에는 필요한 정보가 전달되고 있는가

지금까지 작성한 내용을 한 문장으로 요약하면 다음과 같습니다.

평가기의 정확도를 높여도, 평가 대상 스스로 선별한 정보만 보고 있다면 감지할 수 없는 실패가 남는다.

따라서 AI의 자체 보고와 별개로, 실행 환경, 결정론적 로직(deterministic logic), 그리고 추출 감사(sampling audit)를 통해 관측하는 경로를 남겨두어야 합니다.

NEC의 사례는 사람에 의한 최종 통제, 시각화, 리스크 알림까지 설계된 신중한 노력입니다.

그럼에도 불구하고, '무엇이 인간에게 전달되는가'라는 설계 문제가 남아 있습니다.

이는 NEC에만 국한된 문제가 아닙니다.

AI가 조직으로 자리 잡을수록, 평가기의 성능만큼이나 **평가기 앞에 있는 관측(observation)**을 설계할 필요가 있다고 생각합니다.

그리고 여기서 한 단계 더 나아가면, 다음 질문이 생겨납니다.

추론하는 주체를 여러 개로 나누어 서로 반증하게 한다면, 판단은 독립될 수 있을까?

만약 모두가 같은 선별된 정보만을 보고 있다면, 모두가 같은 사각지대(blind spot)를 갖게 됩니다.

따라서 추론의 주체를 나눌 뿐만 아니라, 별개의 관측 경로도 남겨두어야 합니다.

NEC, AI 네이티브 컴퍼니로의 변혁을 위해 대기업 최초로 사람과 공창하는 AI 자율 조직 신설 (2026년 8월 10일)

https://jpn.nec.com/press/202608/20260810_01.html -
【별지】 코퍼레이트 AI・Workforce 부문 상세 (NEC)

https://jpn.nec.com/press/202608/images/1001-01-01.pdf -
NEC, 'AI 사원' 36체가 근무하는 자율 조직 공개: 1on1 및 스트레스 체크까지, 사람과 AI로 기업 OS 재구축 (Ledge.ai, 2026년 9월 24일)

https://ledge.ai/articles/nec_corporate_ai_workforce_information_session -
Turpin et al.,