본문 바로가기

AI NEWS

Fujitsu self-evolving multi-AI agent technology May 25 2026: 기업용 에이전트는 어디까지 자동 개선될까

 

Fujitsu의 self-evolving AI agent: 기업용 에이전트는 어디까지 자동 개선될까

후지쯔 발표로 보는 업무 피드백 학습형 AI 에이전트와 소버린 AI 전략

 

Fujitsu self-evolving multi-AI agent란 무엇인가

 

Fujitsu self-evolving multi-AI agent technology May 25 2026은 여러 AI 에이전트가 업무 결과, 사람의 피드백, 정책·사양 변경을 반영해 업무 특화 LLM과 프로세스를 계속 손보는 구조입니다. 단순 자동화보다 검증된 개선안만 운영에 올리는 기업용 피드백 루프에 가깝습니다.

AI 에이전트 도입을 생각할 때 의외로 오래 남는 질문이 있습니다. 한 번 만든 에이전트를 누가 계속 고칠 것인가. 업무 규정은 바뀌고, 내부 문서는 쌓이고, 현장 담당자는 검색 실패나 답변 오류를 계속 수정합니다. 그 수정 기록이 다음 실행에 반영되지 않으면 에이전트는 금방 낡은 자동화가 됩니다.

후지쯔(Fujitsu)는 2026년 5월 25일 여러 AI 에이전트가 업무 실행 결과와 사람의 수정, 정책 개정, 사양 변경을 학습해 비즈니스 특화 LLM과 업무 프로세스를 개선하는 기술을 발표했습니다. 2026년 5월 26일 기준으로 보면, 이 뉴스는 “새 챗봇 출시”라기보다 “기업용 에이전트를 운영 중에 어떻게 고쳐 갈 것인가”를 묻는 자료입니다.

제가 보기에는 두 갈래가 실무적으로 중요합니다. 하나는 Takane 같은 기업용 LLM을 특정 산업 데이터에 맞춰 계속 조정하려는 흐름이고, 다른 하나는 그 개선 과정을 클라우드 바깥의 전용 환경, 온프레미스, 엣지까지 가져가려는 소버린 AI 방향입니다.

 
보안 운영실에서 여러 AI 에이전트가 업무 문서, 피드백 로그, 평가 결과를 연결해 개선 루프를 만드는 장면. Fujitsu 로고나 실제 제품 UI 없이 생성형 AI/기업 자동화 느낌.
 

2024년 Takane부터 2026년 자기진화 에이전트까지의 흐름

 

2024년 Takane, 2026년 1월 Fujitsu Kozuchi Enterprise AI Factory, 그리고 2026년 5월 self-evolving multi-AI agent가 한 줄로 이어집니다. LLM을 만드는 단계에서 업무 중에 계속 조정하는 단계로 관심이 옮겨간 흐름입니다.

Fujitsu는 2024년 Cohere와의 협력을 바탕으로 일본어 기업 업무에 맞춘 LLM인 Takane을 발표했습니다. 2025년에는 Takane 기반 모델을 더 작고 효율적으로 쓰기 위한 재구성 기술, NVIDIA와의 산업 AI 에이전트 협력, 물리 AI와 멀티 에이전트 프레임워크를 차례로 공개했습니다.

2026년 1월에는 Fujitsu Kozuchi Enterprise AI Factory를 내놓으면서 전용 환경에서 생성형 AI 수명주기, 사내 파인튜닝, 양자화, 신뢰 기술, 로우코드 에이전트 개발을 다루는 플랫폼 맥락을 만들었습니다. 그래서 Fujitsu self-evolving multi-AI agent technology May 25 2026은 “에이전트가 알아서 좋아진다”는 구호보다, 기업 내부 AI 운영을 계속 조정하는 장치로 읽는 편이 맞습니다.

흐름을 짧게 놓으면 이렇습니다.

역할
Takane 업무 특화 대상이 되는 기업용 LLM
multi-AI agent 작업 분할, 실행, 실패 분석, 개선안 검증을 맡는 운영 루프
Kozuchi Enterprise AI Factory 전용 환경·소버린 AI·모델 운영을 묶는 플랫폼 맥락
 

기존 AI 에이전트 자동화와 무엇이 다른가

 

일반적인 workflow agent가 정해진 프롬프트와 도구 체인을 실행하는 데 초점을 둔다면, Fujitsu 발표는 실패 사례와 사람의 수정 기록을 바탕으로 검색 범위, 추출 전략, 평가 규칙까지 개선하는 쪽에 초점이 있습니다. 다만 이는 Fujitsu가 발표한 기술 방향이며 독립적인 시장 검증 결과와는 구분해야 합니다.

현업에서 많이 쓰는 에이전트 자동화는 대개 “문서를 찾고, 요약하고, 티켓을 만들고, 다음 도구를 호출한다”는 실행 흐름입니다. 잘 설계하면 유용하지만, 규정이 바뀌거나 문서 체계가 바뀌면 프롬프트와 검색 설정을 사람이 다시 손봐야 합니다.

후지쯔가 강조한 차이는 그 수정 작업의 일부를 에이전트 시스템 안으로 가져오는 데 있습니다. 발표에 따르면 에이전트는 성공과 실패의 이유를 분석하고, 업무 지식으로 바꿀 신호를 추출하며, 제안된 개선안이 실제로 효과가 있는지 검증한 뒤 반영합니다. 여기서 볼 부분은 모든 변경을 무조건 저장하는 구조가 아니라는 점입니다.

예를 들어 설계 사양 검색 업무라면 단순히 “문서를 더 많이 검색한다”가 아닙니다. 과거 검색 실패, 담당자의 수정, 누락된 문서 패턴을 보고 검색 범위를 넓힐지, 추출 기준을 바꿀지, 평가 기준을 손볼지 판단하는 방식입니다. 한국 사용자 입장에서는 이 대목이 내부 지식관리와 감사 로그 설계 문제로 바로 이어집니다.

 
업무 요청, 에이전트 실행, 실패 로그, 사람 피드백, 검증, 롤백이 순환하는 추상적 플로우 이미지. 실제 보도자료 도표를 모방하지 않는 독자적 구성.
 

평균 정확도 28포인트 향상은 어떻게 봐야 하나

 

Fujitsu는 제조, 의료, 금융, 공공 영역에서 Takane을 자동 강화한 결과 사전 특화 성능 대비 평균 정확도가 28포인트 향상됐다고 밝혔습니다. 이 수치는 Fujitsu가 보고한 평가 결과로 읽어야 하며 모든 산업, 모든 데이터셋에서 보장되는 성능으로 확대하면 안 됩니다.

AI 뉴스에서 수치가 나오면 먼저 볼 것은 “누가, 어떤 범위에서, 무엇과 비교했는가”입니다. 28포인트 향상은 Fujitsu가 업무 특화 LLM 구축 프로세스에 해당 기술을 적용해 평가했다고 밝힌 결과입니다. 제조, 의료, 금융, 공공이라는 영역이 언급되지만, 그것이 곧 모든 기업 환경의 일반 성능을 뜻하지는 않습니다.

의료 예시는 특히 조심해서 읽어야 합니다. Fujitsu는 비정형 기록과 검사 결과에서 진단명, 진행 단계, 치료 방침 같은 정보를 구조화해 추출하는 지원 가능성을 설명했습니다. 이것을 임상 판단 자동화나 의사 대체로 해석하면 범위를 넘어섭니다.

실제로 확인할 부분은 간단합니다. 우리 조직의 문서, 규정, 피드백 로그로 같은 before/after 평가가 가능한지입니다. 데모 정확도보다 중요한 질문은 두 가지입니다. 최근 규정 변경을 반영했을 때 누락이 줄었는가. 사람의 수정이 다음 검색과 추출에 재현 가능하게 반영됐는가.

 

한국 기업이 주목할 이유: sovereign AI와 온프레미스

 

한국의 제조, 금융, 의료, 공공 조직은 내부 문서와 규정 변경 데이터를 public cloud에 그대로 올리기 어렵습니다. Fujitsu가 강조한 sovereign AI, 전용 환경, 온프레미스, 엣지 방향은 이런 조직이 AI 에이전트 자동화를 검토할 때 비교 기준으로 쓸 만합니다.

한국 독자에게는 “일본 대기업도 기업용 AI를 폐쇄 환경과 운영 거버넌스 중심으로 보고 있다”는 점이 먼저 보입니다. 챗봇 UI보다 더 중요한 것은 데이터가 어디에 남고, 누가 개선안을 승인하며, 어떤 평가 세트로 변경을 검증하는가입니다.

Fujitsu Kozuchi Enterprise AI Factory는 전용 환경에서 Takane, 사내 파인튜닝, 양자화, 생성형 AI 신뢰 기술, 로우코드 에이전트 개발을 다루는 플랫폼으로 소개됩니다. 2026년 5월 25일 뉴스도 향후 자체 AI 플랫폼에 통합해 비즈니스 특화 AI의 사내 개발과 자율 운영을 지원하는 기술로 제공하겠다는 방향을 담고 있습니다.

다만 “온프레미스라서 무조건 안전하다”로 읽으면 곤란합니다. 온프레미스와 엣지는 데이터 위치 문제를 줄일 수 있지만, 피드백 루프가 잘못 설계되면 잘못된 규칙이 내부에 더 빨리 퍼질 수도 있습니다. 그래서 한국 기업에는 보안보다 넓은 의미의 감사, 롤백, 평가 데이터 관리가 같이 필요합니다.

 
 
 

도입 시뮬레이션: 설치보다 먼저 private PoC를 설계해야 한다

 

이 발표에는 공개 GitHub repository나 install command가 없으므로 사용법은 설치 튜토리얼이 아니라 private PoC 설계로 접근해야 합니다. 첫 테스트는 규정·사양 변경이 잦은 한 업무를 고르고 과거 작업 결과, 사람 수정 로그, 평가 기준을 준비해 before/after를 비교하는 방식이 적합합니다.

Fujitsu self-evolving multi-AI agent technology May 25 2026을 바로 내려받아 설치하는 방식으로 이해하면 안 됩니다. 공식 자료는 기술 개발과 플랫폼 통합 계획에 가깝고, 공개 패키지명이나 GitHub 설치 명령은 확인되지 않았습니다.

현실적인 첫 테스트는 좁아야 합니다. 제조 설계 변경 영향 분석, 병원 시스템 사양 검색, 공공 주민기록 관련 규정 검색, 금융 내부 통제 문서 검토처럼 “문서가 많고 변경이 잦고 담당자 수정 기록이 남는 업무”를 하나 고릅니다. 그런 다음 최근 3~6개월의 실패 검색, 사람이 고친 답변, 누락 문서, 평가 기준을 모아 기준 성능을 먼저 재야 합니다.

제가 권하고 싶은 PoC 질문은 세 가지입니다.

  • 에이전트가 틀린 이유를 설명 가능한 로그로 남기는가?
  • 개선안이 prompt, search range, extraction rule, evaluation rule 중 무엇을 바꾸는지 구분되는가?
  • 반영 후 성능이 좋아졌더라도 이전 규정과 다른 부작용이 생기지 않았는가?

이 세 가지를 답하지 못하면 “자기진화”라는 말은 운영 리스크가 됩니다.

 

과장하면 안 되는 부분: 판매 중 제품, 성능 보장, 자동 학습

 

이 AI NEWS를 즉시 구매 가능한 독립 제품이나 모든 산업에서 검증된 성능으로 쓰면 안 됩니다. Fujitsu가 밝힌 것은 기술 개발과 플랫폼 통합 계획이며, 실제 도입 판단은 고객 데이터 기반 PoC와 감사 가능한 운영 모델로 다시 확인해야 합니다.

가장 피해야 할 오해는 “에이전트가 알아서 학습하니 사람 검토가 줄어든다”는 식의 단순화입니다. Fujitsu 자료는 사람 피드백과 검증을 포함한 개선 흐름을 강조합니다. 이것을 무제한 자동 학습으로 받아들이면 규제 산업에서는 바로 문제가 됩니다.

운영 모델은 최소한 다섯 단계를 분리해야 합니다. 실행 로그, 사람 피드백 로그, 개선안 생성, 검증 결과, 롤백 결정입니다. 특히 의료, 금융, 공공 업무에서는 정책 변경이나 문서 검색 전략이 실제 업무 판단에 영향을 줄 수 있으므로 승인권자와 책임 범위를 미리 정해야 합니다.

관련 연구로 언급되는 EVE-Agent는 자기진화 에이전트가 설명 가능한 근거를 가진 예제로 학습해야 한다는 문제의식을 보여줍니다. OneComp는 모델 압축과 효율화 맥락에서 온프레미스·엣지 운영을 이해하는 데 참고할 수 있습니다. 둘 다 Fujitsu의 발표 기술 자체와 동일한 제품은 아니므로, 개념적 배경으로만 연결하는 편이 안전합니다.

 
 
 

자주 묻는 질문

 

Q. Fujitsu self-evolving multi-AI agent는 무엇인가?
A. 여러 AI 에이전트가 업무를 나눠 실행하고, 결과와 사람의 수정, 정책·사양 변경을 바탕으로 다음 실행 방식을 개선하는 기업용 AI 기술입니다. 공식 발표 기준으로는 business-specific LLM과 업무 프로세스를 함께 개선하는 방향입니다.

Q. Takane LLM은 이번 발표에서 어떤 역할을 하나?
A. Takane은 Fujitsu가 Cohere와 함께 발표한 기업용 LLM이며, 이번 뉴스에서는 제조, 의료, 금융, 공공 영역에 맞게 자동 강화되는 대상 LLM로 등장합니다. 즉 Takane은 기반 모델 맥락이고, self-evolving multi-AI agent는 그 모델과 업무 프로세스를 개선하는 운영 루프에 가깝습니다.

Q. 평균 정확도 28포인트 향상은 그대로 믿어도 되나?
A. Fujitsu가 보고한 평가 결과로는 중요하지만, 모든 기업과 모든 데이터셋에 일반화하면 안 됩니다. 도입 전에는 자사 문서, 피드백 로그, 평가 기준으로 별도 before/after PoC를 해야 합니다.

Q. 지금 바로 설치해 쓸 수 있는 GitHub 프로젝트인가?
A. 아닙니다. 공식 발표에는 공개 GitHub repository, package name, install command가 제시되지 않았습니다. 지금은 Fujitsu 플랫폼 맥락을 확인하고 private PoC 조건을 설계하는 쪽이 현실적입니다.

Q. 한국 기업에는 왜 온프레미스와 sovereign AI 관점이 중요한가?
A. 제조 설계 문서, 금융 규정 문서, 의료 기록, 공공 행정 데이터는 외부 public cloud에 그대로 올리기 어려운 경우가 많습니다. Fujitsu가 말한 전용 환경, 온프레미스, 엣지 방향은 이런 데이터 주권 요구가 있는 조직의 비교 기준이 됩니다.

Q. 도입 전에 무엇을 먼저 준비해야 하나?
A. 먼저 한 업무를 좁게 정하고 과거 작업 결과, 실패 사례, 사람 수정 로그, 규정 변경 이력, 평가 기준을 모아야 합니다. 그다음 개선안이 어떤 설정을 바꿨는지, 누가 승인했는지, 실패 시 어떻게 롤백하는지까지 운영 기준을 정해야 합니다.

함께 읽으면 좋은 글

 

참조 링크