감시자 없는 공장은 불량품을 낸다 — DeReAct가 AI 에이전트에 품질 검사관을 두는 이유

AI 에이전트란 무엇인가 — 그리고 ReAct의 약속

AI 에이전트(agent, 여기서는 '스스로 생각하고 행동하는 AI 프로그램')는 최근 몇 년 사이 가장 뜨거운 기술 화두입니다. 단순히 질문에 답하는 챗봇을 넘어, 스스로 목표를 설정하고, 계획을 세우고, 외부 도구(인터넷 검색, 파일 편집, 코드 실행 등)를 써서 결과를 만들어 내는 시스템입니다. 택배 기사에 비유하면, 챗봇은 "어디로 가면 되나요?"라고 묻는 수준이고, 에이전트는 지도를 직접 찾아보고 경로를 짜고 배달을 완료하는 수준입니다.

이 에이전트 기술의 핵심 설계 방식 중 하나가 'ReAct(리액트)'입니다. ReAct는 'Reasoning and Acting', 즉 '추론하고 행동하기'의 줄임말입니다. 2022년 구글 연구팀이 제안한 이 방식은, LLM(Large Language Model, 쉽게 말해 사람 말을 이해하고 문장을 만들어 내는 거대 AI 모델)이 혼자 추론→행동→관찰→재추론→재행동을 반복하면서 문제를 해결하도록 설계되어 있습니다. 마치 길을 걷다 막히면 "이 길이 맞나, 다른 길로 가야겠다"고 스스로 판단하며 나아가는 것과 비슷합니다.

ReAct는 단순한 질문 응답에서 벗어나 복잡한 다단계 작업을 처리하는 데 꽤 효과를 보였습니다. 학술 벤치마크에서 여러 기존 방식보다 높은 성능을 기록했고, 업계에서도 에이전트 개발의 기본 틀로 자리를 잡았습니다. 그런데 실제 현장에서 써 보니 결정적인 약점이 드러나기 시작했습니다.

혼자 다 맡으면 생기는 문제 — ReAct의 구조적 취약점

ReAct 구조의 핵심 문제는 '모든 것을 LLM 하나가 처리한다'는 데 있습니다. 행동을 제안하는 것도, 그 행동을 실행할지 결정하는 것도, 작업이 끝났는지 판단하는 것도 전부 같은 AI가 담당합니다.

집 짓기에 비유하면 이렇습니다. 설계사가 도면을 그리고, 시공사가 집을 짓고, 감리사가 잘 지어졌는지 확인하는 역할을 한 사람이 전부 맡는 셈입니다. 설계 단계에서 실수가 생겨도 아무도 그것을 지적해 주지 않습니다. 건물이 완성되지 않았는데도 "다 됐습니다"라고 도장을 찍어 버릴 수 있습니다.

AI 연구자들이 실제로 관찰한 문제 유형은 크게 세 가지입니다.

1. 오류 전파: 초기 추론 단계에서 잘못된 전제가 생기면, 그 전제가 이후 모든 행동 단계에 그대로 흘러들어 갑니다. 한 번 삐뚤어진 씨실이 천 전체를 틀어지게 만드는 것과 같습니다.
2. 승인 없는 행동 실행: LLM이 스스로 '이 행동이 필요하다'고 판단하면, 별도 검증 없이 실행에 옮깁니다. 파일을 삭제하거나, API(외부 서비스와 대화하는 창구)를 잘못 호출하거나, 금융 거래를 잘못 처리하는 상황이 생길 수 있습니다.
3. 할루시네이션(환각) 기반 종료: '할루시네이션(hallucination)'은 AI가 사실이 아닌 것을 사실처럼 말하는 현상입니다. ReAct 에이전트는 실제로 작업이 끝나지 않았는데도 "완료했습니다"라고 판단하고 멈춰 버리는 사례가 보고됩니다. 이것이 고위험 환경에서 얼마나 위험한지는 쉽게 짐작할 수 있습니다.

이 세 가지 문제는 모두 '같은 시스템이 행동을 제안하고 스스로 검증도 한다'는 구조에서 비롯됩니다. 스스로 만든 결과물을 스스로 점검하면 오류를 걸러 내기가 어렵습니다. 인간 조직에서도 내부 감사 부서를 따로 두는 이유가 바로 여기에 있습니다.

DeReAct가 제안하는 해법 — 역할을 분리하라

DeReAct(디리액트, Decomposed Reasoning and Acting의 줄임말로 '분해된 추론 및 행동'이라는 뜻)는 이 문제를 '역할 분리'로 풀려고 합니다. ReAct의 기본 흐름(추론→행동→관찰→반복)은 그대로 유지하되, 두 개의 독립적인 검증 모듈을 흐름 중간에 끼워 넣는 방식입니다.

두 모듈의 역할을 구체적으로 설명하면 이렇습니다.

첫 번째는 'Critic(크리틱, 비평가)' 모듈입니다. LLM이 "이 행동을 하겠다"고 제안하면, 실제로 실행하기 전에 Critic이 가로막고 점검합니다. "이 API 호출에 파라미터(작동에 필요한 설정값)가 올바르게 담겼는가?" "이 행동이 현재 상황에서 적절한가?" "예상치 못한 부작용은 없는가?" 이런 질문들을 Critic이 독립적으로 던집니다. 문제가 없으면 통과, 문제가 발견되면 실행을 막고 LLM에게 재검토를 요청합니다.

두 번째는 'Context Manager(콘텍스트 매니저, 맥락 관리자)' 모듈입니다. 행동이 실행된 뒤, 환경이 어떻게 변했는지를 독립적으로 해석하고 "지금 작업이 실제로 완료되었는가?"를 판단합니다. LLM이 "다 됐다"고 말하더라도, Context Manager가 실제 환경 상태를 확인해서 동의하지 않으면 작업을 종료하지 않습니다.

이를 구조적으로 보면, 기존 ReAct가 LLM 단일 채널이었다면, DeReAct는 행동 전 검문소(Critic)와 결과 후 확인소(Context Manager)를 두는 구조입니다. 한 사람이 설계·시공·감리를 다 했던 것을, 설계와 시공은 LLM이, 감리 두 단계를 별도 전문가가 맡는 형태로 바꾸는 것입니다.

역사적 평행 — 공장 품질 관리의 교훈

이 방식이 왜 중요한지를 이해하려면, 제조업의 품질 관리 역사를 잠깐 살펴보는 것이 도움이 됩니다.

20세기 초반 대량 생산 공장에서는 생산과 품질 검사를 한 부서가 담당하는 경우가 많았습니다. 결과는 예상대로였습니다. 불량품이 많았고, 발견이 늦었고, 문제가 눈덩이처럼 커진 후에야 발각되었습니다. 그 뒤 일본의 도요타를 비롯한 제조 기업들이 '독립적인 품질 검사' 체계를 정착시켰습니다. 생산 라인과 품질 관리 라인을 분리하고, 이상이 발견되면 즉시 라인을 멈추는 '안돈(Andon)' 시스템을 도입했습니다. 작업자 누구나 라인을 세울 권한을 가지게 하는 이 체계가 결국 도요타를 세계 최고 품질 브랜드로 만든 핵심 중 하나였습니다.

DeReAct가 하려는 것은 AI 에이전트에 이와 비슷한 독립 품질 검사 레이어를 도입하는 것입니다. AI가 제안한 행동이 '생산 라인'이라면, Critic은 '품질 검사관'입니다. Context Manager는 최종 출하 전 완성도를 확인하는 '출하 검사'에 해당합니다.

소프트웨어 개발 역사에서도 비슷한 전환점이 있었습니다. 초기에는 개발자가 자신이 짠 코드를 스스로 테스트했습니다. 나중에 별도의 QA(Quality Assurance, 품질 보증) 팀이 생겼고, 이후엔 코드 리뷰 문화가 정착했습니다. 오늘날 잘 운영되는 소프트웨어 팀은 코드를 짠 사람과 검토하는 사람을 분리합니다. 짠 사람이 자신의 코드에서 오류를 발견하기 어렵다는 것을 수십 년의 경험으로 배웠기 때문입니다. DeReAct는 AI 에이전트에도 이 원칙을 적용한 셈입니다.

이 원칙에는 훨씬 더 오래된 뿌리가 있습니다. 의학에서 '두 번째 소견(second opinion)' 원칙이 그것입니다. 중요한 진단을 내릴 때 의사 혼자 결정하지 않고, 독립적인 다른 의사의 의견을 구합니다. 같은 환자 정보를 보더라도 다른 눈이 놓친 것을 잡아낼 수 있기 때문입니다. Critic 모듈은 LLM의 판단에 두 번째 소견을 제공하는 역할을 합니다.

구체 사례로 보는 효과 — 어디에서 차이가 나타나는가

DeReAct의 효과를 이해하기 위해, 실제 시나리오를 구체적으로 그려 보겠습니다. 다음 시나리오들은 논문의 취지를 설명하기 위한 사례이며, 구체 수치는 실제 논문 검증이 필요합니다.

시나리오 1 — 이메일 자동 발송 에이전트

ReAct 에이전트에게 "고객 A에게 할인 쿠폰 메일을 보내라"는 작업을 줍니다. 에이전트가 추론 도중 고객 B의 이메일 주소를 혼동했다면? ReAct는 이를 걸러 낼 장치가 없습니다. 그냥 틀린 주소로 발송합니다. DeReAct라면 Critic 모듈이 "발송 대상 주소가 작업 요청의 고객 A 정보와 일치하는가?"를 실행 전에 확인합니다. 불일치가 발견되면 실행을 멈추고 재검토를 요청합니다.

시나리오 2 — 데이터베이스 쿼리 에이전트

에이전트가 데이터베이스(대용량 정보를 체계적으로 저장하는 시스템)에서 특정 조건의 데이터를 삭제하는 작업을 합니다. ReAct 에이전트가 잘못된 조건을 입력해 삭제 범위를 의도보다 훨씬 넓게 잡았다면? Critic이 없다면 수천 건의 데이터가 지워집니다. DeReAct에서 Critic은 쿼리 파라미터(조건값)가 작업 요청과 일치하는지 실행 전에 검증합니다.

시나리오 3 — 작업 완료 오판

에이전트가 파일 변환 작업을 수행합니다. 중간 단계까지만 완료됐는데, LLM이 내부적으로 "완료"라고 잘못 판단해 작업을 종료합니다. Context Manager가 없다면 반쪽짜리 결과물이 최종 산출물로 처리됩니다. Context Manager는 실제 파일 상태를 독립적으로 확인해 "아직 변환이 완료되지 않았다"는 판단을 내리고 작업을 계속 진행하도록 합니다.

이 논문이 효과를 주장하는 영역을 정리하면 다음과 같습니다.

• 금융 거래 처리: 잘못된 금액이나 계좌 정보로 거래가 실행되는 사고를 사전 차단
• 의료 데이터 조회: 환자 정보를 혼동하는 오류가 미치는 치명적 결과를 막는 검문 역할
• 코드 자동 작성: 잘못된 코드가 실제 시스템에 배포되기 전에 Critic이 구문 오류와 논리 오류를 걸러 냄
• 법률 문서 검토: 조항 해석 오류가 최종 문서에 반영되기 전 검증 단계 추가

흔한 오해 두 가지 — 연구는 정확히 읽어야 합니다

DeReAct 같은 논문을 접하면 몇 가지 오해가 생기기 쉽습니다. 여기서 두 가지를 짚어 두겠습니다.

오해 첫 번째: "DeReAct가 AI 에이전트의 실수를 완전히 없앤다"

그렇지 않습니다. Critic과 Context Manager도 결국 AI 모델이거나 규칙 기반 시스템입니다. Critic이 오류를 잡지 못하는 경우가 있고, Context Manager도 맥락을 잘못 해석할 수 있습니다. 논문이 주장하는 것은 '완전한 오류 제거'가 아니라 '단일 시스템 대비 오류 전파 억제'입니다. 완벽한 품질 보증이 아니라 '결함 발생 확률 감소'에 가깝습니다. 이 차이를 명확히 구분해야 합니다. "이제 AI 에이전트가 절대 실수하지 않는다"는 식의 보도나 설명은 과장입니다.

오해 두 번째: "DeReAct는 ReAct보다 무조건 낫다"

상황에 따라 다릅니다. Critic과 Context Manager를 추가하면 처리 단계가 늘어나고 응답 속도가 느려집니다. 단순한 작업, 빠른 응답이 중요한 서비스, 오류의 영향이 크지 않은 환경에서는 기존 ReAct가 더 효율적일 수 있습니다. 망치를 쥐었다고 모든 것이 못은 아닙니다. DeReAct가 진가를 발휘하는 건 고위험·고정밀 환경입니다. 어느 상황에 어느 도구를 쓸지는 여전히 설계자의 판단 영역입니다.

추가로 한 가지 더 짚겠습니다. 논문에서 제시하는 성능 개선 결과는 특정 벤치마크(성능 측정 기준 과제)에서의 수치입니다. 벤치마크는 실제 현장 조건을 온전히 반영하지 못하는 경우가 많습니다. 통제된 실험 환경과 복잡한 실 세계 운영 환경의 차이는 항상 존재합니다. 논문의 수치를 현장에 그대로 기대하는 것은 무리입니다. 이 논문이 지적하는 구조적 문제 진단과 해법의 방향성은 타당하지만, 실제 성능은 적용 환경에서 별도로 검증해야 합니다.

더 넓은 시사점 — 신뢰할 수 있는 AI란 무엇인가

DeReAct 논문이 던지는 더 큰 질문이 있습니다. AI 에이전트가 진짜 현실 세계에서 쓰이려면 어떤 조건을 갖춰야 하는가입니다.

지금까지 AI 연구의 상당 부분은 'AI가 얼마나 잘하는가(성능)'에 집중해 왔습니다. 더 큰 모델, 더 많은 데이터, 더 높은 정확도. 그런데 DeReAct 같은 연구는 질문의 방향을 바꿉니다. 'AI가 잘못 행동했을 때 어떻게 막는가(신뢰성)'를 중심에 놓습니다.

이 전환은 의미가 큽니다. 자동차를 예로 들면, 엔진 출력이 강하다고 좋은 차가 아닙니다. 브레이크, 에어백, 충돌 감지 시스템이 함께 있어야 도로에 내보낼 수 있습니다. AI 에이전트도 마찬가지입니다. 추론 능력이 뛰어나다고 바로 금융 시스템이나 의료 환경에 투입할 수 없습니다. 오류를 잡는 장치, 행동을 검증하는 장치, 예상치 못한 상황에서 멈출 수 있는 장치가 갖춰져야 합니다.

DeReAct의 접근 방식은 이런 '안전 장치 내재화' 흐름의 일부입니다. 최근 AI 업계에서 부상하는 개념들, 예를 들어 헌법적 AI(Constitutional AI, AI가 따라야 할 원칙을 명시하는 방식), AI 얼라인먼트(Alignment, AI의 행동이 인간 의도와 일치하도록 하는 연구), 해석 가능성(Interpretability, AI가 왜 그런 결정을 내렸는지 이해하는 연구) 등은 모두 비슷한 문제의식에서 출발합니다. 성능이 아니라 신뢰와 안전을 어떻게 보장할 것인가.

한국의 맥락에서 이 문제는 특히 중요한 차원을 하나 더 가집니다. 데이터 주권의 문제입니다. AI 에이전트가 외부 시스템과 상호작용하면서 민감한 데이터를 다룰 때, 그 데이터가 어디서 처리되고 누가 검증하는지가 불투명하다면 개인정보 보호와 국가 데이터 주권 문제가 생깁니다. DeReAct 같은 구조는 어떤 행동이 어떤 검증을 거쳐 실행됐는지를 추적 가능하게 만듭니다. 이것은 단순한 성능 개선이 아니라 감사 가능성(Audit trail), 즉 나중에 '왜 그 행동을 했는가'를 확인할 수 있는 투명성과 연결됩니다.

AI 에이전트를 기업이나 공공기관에 도입할 때, "이 에이전트가 어떤 행동을 했고 왜 했는지 언제든 확인할 수 있는가?"라는 질문에 답할 수 있어야 합니다. 검증 레이어를 분리하고 독립화하는 DeReAct의 방식은 이 감사 가능성을 높이는 방향과 일치합니다.

물론 Critic 모듈과 Context Manager 모듈 자체가 어떤 모델 또는 규칙으로 구성되는지, 그 의사결정 과정 또한 투명하게 공개되어야 합니다. '검증하는 것을 누가 검증하는가'라는 질문은 끝없이 이어질 수 있습니다. 이 점에서 DeReAct는 완성된 해답이라기보다 올바른 방향으로의 한 걸음에 가깝습니다.

마무리 — 속도보다 신뢰가 먼저입니다

AI 에이전트 기술이 빠르게 발전하고 있습니다. GPT-4o, Claude, Gemini 등 여러 대형 LLM이 에이전트 기능을 강화하고 있고, 기업들은 이를 업무에 적용하는 속도를 높이고 있습니다. 그런데 이 속도 경쟁 속에서 종종 뒷전으로 밀리는 질문이 있습니다. "이 에이전트가 잘못 행동했을 때 어떻게 막을 수 있는가?"

DeReAct 논문이 값진 이유는 성능 수치를 높인 것보다, 이 질문에 구조적으로 답하려 했다는 데 있습니다. 물론 이 논문의 주장이 현장에서 검증되려면 더 많은 실험과 시간이 필요합니다. 다양한 환경에서의 재현 가능성, Critic과 Context Manager 모듈 자체의 정확도, 추가 처리 비용의 현실적 수용 가능성 등이 모두 풀어야 할 숙제입니다.

하지만 방향은 옳습니다. 한 사람이 설계·시공·감리를 다 맡는 구조에서, 역할을 나누고 독립적인 검증을 두는 구조로의 전환. 이것은 공학의 역사가 반복해서 증명한 원칙입니다. AI도 예외가 아닙니다.

연구는 정확히 읽어야 합니다. DeReAct가 모든 문제를 해결했다고 읽지 마십시오. 다만 지금 우리에게 필요한 질문, AI 에이전트의 행동을 어떻게 감시하고 검증할 것인가를 구체적인 설계 언어로 제안했다고 읽는 것이 적절합니다.

Q. Critic과 Context Manager 모듈도 AI라면 결국 같은 오류를 범하지 않을까요? A. 타당한 지적입니다. 논문은 이 모듈들이 반드시 대형 LLM일 필요는 없으며, 특정 목적에 특화된 소형 모델이나 규칙 기반 시스템으로도 구현 가능하다고 제안합니다. 다만 어떤 모델을 써도 오류를 100% 차단할 수는 없습니다. 핵심은 '오류 발생률 감소'와 '오류 전파 억제'입니다. 완전한 제거가 아니라 위험 감소를 목표로 읽어야 합니다.

Q. DeReAct가 실제 서비스에 적용된 사례가 있나요? A. 현재 이 논문은 제안 단계입니다. 실제 운영 서비스에서의 대규모 적용 사례는 현재 공개된 것이 없습니다(추정). 학술 논문에서 벤치마크 성능을 확인한 단계로, 현장 적용 결과는 향후 검증이 필요합니다. 이 논문의 구조적 아이디어가 산업계 제품에 흡수되어 실험되는 데는 통상 1~2년의 시간이 걸립니다.

Q. 처리 속도가 느려진다면 실시간 서비스에는 쓸 수 없는 건 아닌가요? A. 추가 검증 단계로 인한 지연이 실제로 발생합니다. 빠른 응답이 최우선인 서비스에서는 트레이드오프(하나를 얻으면 다른 하나를 잃는 상충 관계)가 있습니다. 반면 처리 속도보다 정확성이 중요한 환경, 금융 결산, 의료 기록 처리, 법률 문서 검토에서는 이 지연이 충분히 수용 가능합니다. 도구를 고를 때는 적용 영역을 먼저 가려야 합니다.