에이전틱 AI의 데모 영상은 늘 화려합니다. 프롬프트 몇 줄이면 AI가 스스로 코드를 짜고, 재무 데이터를 분석하고, 최적의 의사결정까지 제안하죠.

하지만 회사의 현실은 그렇게 화려하지 않습니다. 막대한 예산을 들여 인프라를 깔아두어도 정작 실무자들은 AI가 내놓은 결과를 믿지 못해 처음부터 다시 검토하거나, 조용히 예전 업무 방식(레거시 툴)으로 돌아가곤 합니다. 기술은 완벽히 준비되었는데, 왜 조직은 이를 소화하지 못할까요?

지난 8월 7일 맥킨지가 발행한 「에이전틱 AI 변화 관리: 도입 격차 해소(How to close the agentic adoption gap)」 보고서는 이 현상의 원인을 점검합니다. 문제는 기술 격차가 아니라 '도입 격차'에 있습니다.

1. 예산 배분의 함정: 1:3:5 법칙

맥킨지에서는 AI 혁신에 성공한 기업들은 기술에 1, 프로세스 재설계에 3, 조직 역량과 AI 도입에 5 만큼의 예산을 쓰고 있다고 합니다.

반면, 실패하는 기업에서는 이 예산 비율이 거꾸로 갑니다. 거대 언어 모델(LLM) 파인튜닝이나 아키텍처 구축에는 엄청난 리소스를 쏟아부으면서, 정작 직원 교육이나 행동 변화는 런칭 후의 '부수적인 과제'로 취급합니다. 이 보고서에서는 사람과 문화를 바꾸는 일이 단순한 지원 활동이 아니라 '진짜 핵심 업무'라는 것을 가장 우선적으로 강조합니다.

2. 실무자가 AI를 꺼리는 네 가지 '실존적 두려움'

에이전틱 AI는 단순한 유틸리티 프로그램이 아닙니다. 사람을 대신해 초안을 쓰거나 판단을 내리는 주체성을 발휘하기 때문에, 직원들에게 기술적 어려움이 아닌 심리적 저항감을 유발합니다.

• 무지가 탄로 날 것에 대한 두려움: 어떻게 시작해야 할지 몰라 질문조차 꺼립니다. 겉으로는 바쁘게 일하는 척하지만, 실제로는 타인이 먼저 나서기만을 기다리는 마비 상태에 빠집니다.

• 통제권 없는 책임에 대한 두려움: "AI가 치명적인 오류를 내서 사고가 터지면, 최종 책임은 결국 나에게 돌아온다"는 합리적인 불안입니다.

• 불확실성에 대한 두려움: 기술 발전과 업무 환경이 너무 빨리 변해, 최종적인 조직 구조가 어떻게 될지 경영진조차 답을 주지 못하는 데서 오는 짙은 막막함입니다.

• 전문성 상실에 대한 두려움: 수년에 걸쳐 쌓아온 분석과 판단 능력을 AI가 순식간에 해낼 때 겪는 직업적 정체성의 위기입니다.

이러한 두려움을 단순한 '변화에 대한 저항'이나 '게으름'으로 오독하고 밀어붙이는 리더는 반드시 실패합니다.

3. 정답을 모르는 리더십: 'C4 재창조'

기존의 소프트웨어 도입은 출발지 A와 목적지 B가 명확했습니다. 하지만 에이전틱 AI 도입은 'A에서 미지의 목적지로 가는 여정'입니다. (보고서는 이를 C4: Reinvention으로 정의합니다.)

이 과정에서 리더는 "내가 모든 정답을 알고 있다"는 태도를 버려야 합니다. 대신 "나도 정확한 도착지는 모르지만, 우리가 경쟁사보다 더 빨리 학습해 나갈 것이다"라고 불확실성을 모델링해야 합니다. 순응(Compliance)이 아닌 역량(Capability)과 학습 속도에 초점을 맞추는 것이 핵심입니다.

4. 조직을 바꾸는 A-to-E 플레이북

에이전틱 AI를 조직의 DNA로 만들기 위해 다음 5단계 프레임워크가 필요합니다.

• Awareness (인지): 거창한 비전 제시를 멈추고, 직원들이 안전한 환경에서 AI로 직접 이것저것 시도해 보고 실패해 볼 기회를 제공합니다.

• Belief (신뢰): 경영진이 먼저 AI를 업무에 능숙하게 사용하는 모습을 보여주며 변화를 증명하고 신뢰를 쌓아갑니다.

• Commit (몰입): 특정 직무(예: 카테고리 매니저, 재무 담당자)의 일주일을 철저히 분석해, 정확히 어느 단계에서 AI가 스스로 실행하고 어디서 인간이 판단을 내릴지 대본을 짜듯 재설계합니다.

• Develop (역량 개발): AI가 만든 결과물을 비판적으로 검토하고 활용하는 역량(Human-in-the-loop)을 집중적으로 훈련합니다.

• Enforce (실행): 이 모든 과정을 새로운 평가 및 운영 시스템으로 고정합니다.

결론: 누가 AI 시대의 승자가 되는가?

보고서는 에이전틱 시대를 맞이한 모든 리더에게 다음 세 가지 원칙을 불변의 과제로 제시합니다.

1. 방향은 명확히 제시하되, 불확실성은 솔직하게 인정할 것 2. 이러한 여정을 든든하게 지원할 '새로운 운영 모델'을 재설계할 것 3. 직원들에게 요구하는 '학습하는 태도'를 리더가 먼저 행동으로 보여줄 것

다가오는 에이전틱 시대의 진정한 보상은 '가장 성능 좋은 모델을 산 기업'이 아니라, 기존 운영 시스템 설계보다 훨씬 더 빠르게 학습하는 조직에게 돌아갑니다.

데이터, 아키텍처, 툴이라는 기술적 전환은 전체 퍼즐에서 절반에 불과합니다. 리더는 남은 절반인 직원의 마인드셋, 행동, 역할, 시스템을 바꾸는 인간적 전환을 관리해야 합니다.

인지에서 시작해 강화된 운영 시스템으로 이어지는 이 여정이 성공할 때, 직원들은 비로소 AI를 회사가 나에게 일방적으로 들이민 위협이 아니라 나의 전문성과 임팩트를 극대화해 주는 무기로 받아들이게 됩니다.

이 지점에 도달해야만, 기업은 그저 변화에 휩쓸려 가는 대상에서 벗어나, 스스로 변화를 주도하는 조직이 될 수 있습니다.

Source: How to close the agentic adoption gap , McKinsey & Company, August 7, 2026

얼마 전 Y Combinator 채널에 올라온 개리 탄(Garry Tan) 대표의 Y Combinator Startup School 2026 강연 "Own Your Intelligence"를 재미있게 봤습니다.

"코딩 에이전트를 쓰면 생산성이 몇 배 오른다"는 단순한 실무 팁이 아니라, 17세기 스피노자의 철학부터 산업혁명 당시 도구 소유권의 변화, 그리고 AI 시대 지식 노동자가 마주한 인지 외재화 문제까지 다루는 흥미로운 강연이었습니다.

월 20달러짜리 챗봇 구독에 머무르는 것과, 자신만의 데이터와 업무 방식을 자산화해 작업 효율을 끌어올리는 것이 장기적으로 어떤 차이를 만드는지 강연 내용을 상세히 정리해 봅니다.

1. 1656년 암스테르담, 그리고 스피노자의 '코나투스'

개리 탄은 인터넷에서 자신을 "가장 AI에 과몰입한 사람"이라 부른다며, 17세기 네덜란드의 철학자 바뤼흐 스피노자(Baruch Spinoza) 이야기로 강연을 시작합니다.

1656년 7월 27일, 23세의 스피노자는 암스테르담 유대인 공동체로부터 파문을 당했습니다.

• 낮에도 밤에도 저주를 받을 것이며, 누구도 그와 대화하거나 거래할 수 없고, 4큐빗(약 2 m) 이내로 접근해서도 안 된다는 극단적인 파문이었습니다.
• 당시 내려진 수십 건의 파문 중 유일하게 '회개 조항'이 없었고, 400년이 지난 지금까지도 공식적으로 해제되지 않았습니다.

스피노자의 죄목은 '금지된 생각을 품고 말했다는 것'이었습니다.

공동체는 파문 전, 그에게 매년 1,000길더(당시 기준 상당한 금액)를 줄 테니 가끔 회당에 얼굴만 비추고 침묵하라고 회유했습니다. 스타트업 관점으로 치면 "신사업을 멈추는 대가로 편안한 연봉을 제시한 것"과 같습니다. 스피노자는 "1만 길더를 준대도 싫다. 안락함보다 진실을 원한다"며 거절했습니다. 이후 암살 위협으로 칼에 망토가 찢겼을 때도, 생각의 대가를 기억하겠다며 평생 그 옷을 꿰매지 않고 입었습니다.

이후 그는 낮에는 생업으로 광학 렌즈를 깎고, 밤에는 당시 출판조차 할 수 없던 책(에티카)을 썼습니다. 44세에 유리 가루로 인한 폐질환으로 세상을 떠날 때까지, 누구의 허락도 구하지 않고 독립된 힘으로 도구를 만들고 생각을 기록했습니다.

스피노자는 이처럼 스스로를 움직이게 하는 내적 동력을 코나투스(Conatus)라 불렀습니다.

• 코나투스: 모든 생명체가 자신의 존재를 지속하고, 행동할 수 있는 힘을 키우려는 내재적 충동이자 역량.
• 기쁨: 자신의 행동 역량이 커지는 것을 경험할 때 느끼는 감정.
• 슬픔: 자신의 행동 역량이 줄어들고 무력해질 때 느끼는 감정.

"에이전트가 일주일 걸릴 업무를 반나절 만에 끝냈을 때 느끼는 감정은 단순한 편의가 아닙니다. 스피노자의 정의 그대로, 스스로 행동할 수 있는 힘이 확장되면서 경험하는 기쁨에 가깝습니다."

2. AGI는 하늘에서 떨어지는 단일 이벤트가 아니다

스피노자가 파문당했던 가장 큰 이유는 "신은 옥좌에 앉아 인간을 다스리는 왕이 아니라, 자연 만물에 널리 퍼져 있는 법칙 그 자체(Deus sive Natura)"라고 주장했기 때문입니다.

개리 탄은 우리가 지금 인공지능을 바라보는 방식도 이와 비슷하다고 얘기합니다.

많은 사람들이 AGI를 빅테크 데이터센터에서 어느 날 갑자기 발표될 거대한 단일 사건이나 완성된 초지능으로 기다립니다. 하지만 개리 탄이 제시하는 관점은 다릅니다.

"모두가 하늘만 쳐다보고 있지만, 우리가 기다리는 것은 이미 우리 방 안에 와 있습니다. 신의 모습이 아니라 터미널 창, 마크다운 폴더, 밤새 돌아가는 백그라운드 작업의 형태로 퍼져 있습니다."

이것이 바로 개인용 AGI(Personal AGI)의 개념입니다. 모두를 위한 하나의 거대 시스템이 아니라, 철저히 개인의 고유한 맥락 위에서 돌아가는 지능입니다.

빌려 쓰는 AI(Corporate AI) vs 내가 소유한 AGI(Personal AGI)

• 빌려 쓰는 기업용 AI:
  • 월 20달러짜리 챗봇 구독.
  • 세션 탭을 닫으면 맥락이 초기화됨.
  • 남들도 다 아는 웹상의 일반 지식만 알고 있음.
  • 서비스 제공 회사가 모델을 변경하거나 피벗하면 내 업무 흐름도 통제 불가능하게 바뀜.

• 내가 소유한 개인용 AGI:
  • 내 로컬 환경이나 자체 저장소에서 구동됨.
  • 내가 몇 년간 축적한 이메일, 회의록, 의사결정 이유를 읽음.
  • 내가 직접 작성한 절차(Skill)를 실행함.
  • 기업이 새 모델을 출시할 때뿐만 아니라, 내가 업무를 처리할 때마다 매일 복리로 개선됨.

[앞으로 10년의 작업 방정식]
= 렌트한 프론티어 모델 (원자재 성격, 점점 저렴해짐)
+ 내가 소유한 고유한 컨텍스트 (남이 복제할 수 없는 해자)
+ 둘을 연결하는 하네스 및 스킬 (내 작업 방식)

3. 달라진 스타트업의 물리법칙: 1인당 매출의 변화

개리 탄 본인의 생산성 증가 그래프. 출처: Garry Tan: Own Your Intelligence

실제 Y Combinator 배치에서도 스타트업의 지표가 달라지고 있습니다.

• 개리 탄 본인의 생산성: 2013년 YC 파트너 시절, 밤에 코딩하며 하루 평균 14줄의 쓸만한 코드를 작성(당시 프로그래머 중간값 수준). 현재 YC 대표로 풀타임 근무와 육아를 병행하면서도, 에이전트를 활용해 2013년 대비 수십 배 이상의 산출물을 배포.
• YC W25 배치: 전체 기업의 25%가 코드베이스의 95% 이상을 AI로 생성. 코딩뿐 아니라 디자인, 기획, 운영 전반에 에이전트를 도입.
• 1인당 매출 사례:
  • Emergent (S24): 런칭 8개월 만에 연환산 매출(ARR) 1,500만 달러 달성, 당시 팀 규모는 단 15명.
  • Retail (W24): ARR 6,000만 달러 달성 당시 팀 규모 약 40명.

소프트웨어 분야에서 이전에는 보기 드물었던 1인당 생산성 지표입니다. 폴 그레이엄의 오랜 원칙인 *"확장되지 않는 일을 하라(Do things that don't scale)"는 여전히 유효하지만, 이제는 *에이전트를 통해 개인이 '확장 불가능한 일'을 대규모로 처리하는 구조**가 가능해졌습니다.

4. 아키텍처: 마크다운(Markdown)을 중심으로 짓는 두뇌

개리 탄은 25년간의 이메일, 메모, 회의록, 실패 기록 등을 22만 개 이상의 마크다운 파일로 구성한 시스템 GBrain을 운용하고 있습니다.

[GBrain의 작동 방식]
1. 야간: 에이전트가 인박스를 단순 분류하는 데 그치지 않고 맥락에 맞게 처리. 
   어려움을 겪는 창업자의 메일이 오면, 과거 대화 히스토리와 유사 문제를 해결했던 포트폴리오 사례를 사전 정리.
2. 기상 직후: 단순 메일 목록 대신 정리된 브리핑 확인. 
   당일 미팅 상대의 이전 발언, 바뀐 점, 확인해야 할 질문 리스트를 미리 받아봄.
3. 실시간 대응: 업무 논의 중 에이전트가 내부 기록을 탐색해 필요한 선행 사례를 즉시 요약.

① 작업 기억(Working Memory)의 차이

• 인간의 단기 기억은 한 번에 약 7 ± 2 개 정보만 다룰 수 있습니다. 조직도, 체크리스트, 스탠드업 미팅 등은 모두 이 7개라는 뇌의 용량 한계를 보완하기 위한 장치였습니다.
• 반면 최신 LLM의 컨텍스트 윈도우는 100만 토큰(책 3권, 약 1,000페이지 분량)을 동시에 올릴 수 있습니다.
• 결국 중요한 지점은: 내 전체 기록 중에서 "지금 에이전트에게 어떤 맥락(책 3권 분량)을 골라 올려둘 것인가"를 결정하는 시스템을 만드는 일입니다.

② 마크다운 텍스트가 곧 실행 코드다

스킬 파일은 복잡한 프로그램이 아니라 명확하게 쓰인 텍스트 지침입니다.

"일 잘하는 인턴이 읽고 그대로 따라 할 수 있는 가이드라면, 에이전트도 실행할 수 있습니다. 자연어로 명확한 업무 매뉴얼을 쓸 수 있다면 이미 에이전트를 프로그래밍하고 있는 셈입니다."

실제 YC에서는 비개발 직군인 재무팀 담당자가 에이전트를 활용해 100여 개의 엑셀 시트를 연동하는 내부 도구를 만들어 쓰고 있습니다. 코더가 아니더라도 '에이전트 관리자'로서 일하는 형태입니다.

③ 잠재 공간(Latent)과 결정론적 공간(Deterministic)의 분리

에이전트 시스템을 만들 때 흔히 겪는 실패는 작업의 성격을 구분하지 않아서 발생합니다.

• 잠재 공간 (LLM): 모호한 요청 해석, 뉘앙스 파악, 문맥 요약, 톤 조절.
• 결정론적 공간 (Code, SQL DB): 사칙연산, 정확한 날짜 계산, 대규모 인원 좌석 배치, 스케줄링.
• 문제 상황: 수천 명의 세션 시간표 배치를 LLM 머릿속(잠재 공간)에서만 풀려고 하면 환각과 오류가 생깁니다.
• 해결책: 마크다운 형태의 프롬프트가 필요할 때 SQL DB나 파이썬 스크립트(결정론적 도구)를 호출하도록 파이프라인을 분리해야 합니다.

5. 단계별 실천 로드맵

개리 탄이 제시하는 5단계 실행 가이드입니다.

[90일간의 진행 과정]
* 1주 차: 결과물이 다소 거칠고, 지침을 수정하느라 시간 절약 체감이 적음.
* 4주 차: 에이전트가 나만의 맥락을 반영해 답변하기 시작하고, 정기 브리핑의 실효성이 높아짐.
* 12주 차: 반복 업무 상당 부분이 스킬 파일로 처리되며, 동료들이 공유를 요청하는 자체 툴이 생김.

처음에는 나아지는 게 잘 느껴지지 않습니다. 대부분이 2주차에 흥미를 잃고 포기합니다. 하지만 머리 속에 있는 걸 꺼내서 문서화하고 실행하는 걸 꾸준히 반복하면 점점 플라이휠이 동력을 받아서 힘있게 돌아가는 걸 실감할 수 있습니다.

처음에는 나아지는 게 잘 느껴지지 않지만 시간이 지나면 업무 효율이 급증합니다. 출처: Garry Tan: Own Your Intelligence

6. 지식 노동자의 문제: 업무 노하우를 어디에 둘 것인가?

강연 후반부에서 개리 탄은 업무 지식의 소유권 문제를 짚습니다.

산업혁명 이전 장인들은 작업 도구를 직접 소유했기 때문에 자유로울 수 있었습니다. 공장이 들어서고 도구의 소유권이 기업으로 넘어가면서 장인은 공장의 부품이 되고 말았습니다.

지식 노동자들은 '지식이 머릿속에 있으니 안전하다'고 여겨왔지만, 이제 업무 프로세스와 판단 기준은 텍스트 파일 형태로 추출되고 자동화될 수 있습니다.

• 개인 레포지토리에 스킬을 쌓는 경우: 업무 대응 노하우 40개를 내 개인 저장소에 체계화해 둔다면, 이직하거나 창업할 때 그동안 쌓은 판단 기준을 그대로 활용할 수 있습니다.
• 회사 시스템에만 남겨두는 경우: 퇴사 시 회사는 남겨진 스킬 파일로 프로세스를 유지하지만, 개인에게는 축적된 자산이 남지 않습니다.

"자신의 스킬 파일을 직접 소유하세요. 그렇지 않으면 내 업무 방식 자체가 누군가가 작성한 스킬 파일 하나로 대체될 수 있습니다."

7. 주요 반론에 대한 정리

테크 분야에서 자주 나오는 세 가지 회의론에 대한 개리 탄의 답변입니다.

반론 1: "모델이 계속 발전하면 이런 하네스나 개인 라이브러리가 불필요해지지 않을까요?"

• 답변: 모델 엔진의 성능이 상향 평준화될수록 '운전자'와 '지도(컨텍스트)'의 차별성이 더 커집니다. 모델 가중치 자체는 모두에게 공평하게 제공되는 원자재입니다. 모델이 좋아지면 그만큼 내 라이브러리에서 더 정확한 맥락을 뽑아낼 수 있게 될 겁니다.

반론 2: "단순히 RAG(검색 증강 생성)에 불과한 것 아닌가요?"

• 답변: 데이터베이스를 보고 "단순한 B-Tree 인덱스 아니냐"고 묻는 것과 비슷합니다. 검색 기능 자체는 기본 단위일 뿐, 중요한 것은 데이터의 품질 관리입니다. 어떤 맥락을 남기고, 새로운 정보와 과거 정보가 충돌할 때 어떻게 정리할 것인지 관리하는 운영 체계가 본질입니다.

반론 3: "개인 데이터를 한곳에 모으는 것은 보안상 위험하지 않나요?"

• 답변: 그렇기 때문에 개인이 통제 가능한 인프라에 보관해야 합니다. 현재 대다수의 개인 데이터는 수많은 상용 클라우드에 흩어져 있고, 정작 본인이 통합해서 검색하기도 어렵습니다. 로컬 저장소와 개인 키를 바탕으로 통제권을 가져오는 편이 데이터 주권 관점에서 더 안전합니다.

8. 라이프니츠의 방문과 희귀병 아들을 위한 데이터 구축 사례

개리 탄은 강연을 마무리하며 두 가지 사례를 덧붙입니다.

① 1676년 라이프니츠의 다락방 방문

당대 유명 학자였던 라이프니츠는 헤이그의 다락방으로 찾아가 파문당한 스피노자와 3일을 보냈습니다.

이후 라이프니츠는 대외적으로 스피노자를 비판하고 만남을 축소해 말했지만, 사후 발견된 그의 연구 노트는 스피노자의 사상에 대한 메모로 가득 차 있었습니다.

"에이전트로 코드를 짠다고 이야기하면 처음에는 비판이나 냉소적인 반응이 돌아옵니다. 하지만 실제로 그들이 작업하는 환경을 들여다보면 이미 에이전트를 깊게 활용하고 있는 경우가 많습니다. 비판적인 시선이 있다는 것은 새로운 기술이 본격적으로 도입되기 시작했다는 신호이기도 합니다."

② 8만 개의 마크다운 파일로 아들을 돌본 아버지

개리 탄의 지인 중 한 명은 아들이 희귀 뇌전증 진단을 받자, 외부 지원을 기다리는 대신 직접 움직였습니다.

그는 관련 의학 논문, 진료 기록, 발작 일지, 약물 반응 데이터를 모아 8만 개의 마크다운 파일로 구성된 데이터베이스를 만들었습니다. 의사가 새로운 치료법을 제안할 때마다, 아버지는 몇 분 안에 해당 방식이 과거에 시도된 적이 있는지, 어떤 부작용이 있었는지 확인합니다.

"벤치마크 점수나 데모 영상이 전부가 아닙니다. 개인이 노트북 한 대와 고유한 데이터를 바탕으로 가장 중요한 문제를 해결하는 것. 이것이 개인용 AGI의 실제 모습입니다."

맺으며

스피노자의 《에티카》는 다음 문장으로 끝을 맺습니다.

"모든 고귀한 것은 드문 만큼이나 어렵다 (All things excellent are as difficult as they are rare)."

개리 탄은 도구의 발전으로 무언가를 만들어내는 '난이도'의 장벽은 크게 낮아졌다고 말합니다. 이제 남은 것은 그 도구를 활용해 개인이 어떤 '희소한 가치'를 만들어낼 것인가에 대한 고민입니다.

남이 제공하는 챗봇에 수동적으로 의존하기보다, 나만의 맥락과 스킬을 직접 기록하고 자산화해 나가는 흐름을 고민해 볼 만한 시점입니다.

TL;DR

• 멀티에이전트 시스템은 각자 독립적인 작업을 병렬로 처리할 때 강력한 성능을 발휘합니다. 하지만 여러 에이전트가 자원을 공유하고 서로의 판단에 기대기 시작하면 완전히 새로운 차원의 문제가 발생합니다.
• Anthropic이 대규모 에이전트 실험을 진행한 결과, 에이전트 간의 조율 실패, 집단사고(획일적 행동), 담합, 소수의 핵심 정보 무시, 심지어 목표 충돌로 인한 상호 방해 행위까지 나타났습니다.
• 같은 AI 모델을 여러 개 띄운다고 해서 알아서 '다양한 전문가 집단'이 꾸려지는 것은 아닙니다. 오히려 똑같은 판단 착오를 동시에 저지르며 작은 오류를 시스템 전체의 붕괴로 몰고 갈 위험이 큽니다.
• 모델이 똑똑해진다고 저절로 협력을 잘하는 것도 아닙니다. 업무 '실행 능력'과 갈등 '조정 능력'은 완전히 별개의 문제입니다.
• 프롬프트에 안전 지침을 길게 써넣는 방식으로는 한계가 있습니다. 여러 행위자가 공존하는 만큼, 신원 확인, 권한 분리, 평판 시스템, 감사 로그, 이의 제기 및 중재 등 진짜 '사회'에 필요한 제도적 장치를 시스템 내부에 직접 설계해야 합니다.

멀티에이전트 시스템은 AI의 성능을 끌어올리는 훌륭한 방법론으로 꼽힙니다. 큰 과제를 여러 조각으로 쪼개어 전문 에이전트들에게 분배하고 최종 결과를 하나로 취합하는 구조죠. 실제로 검색이나 리서치처럼 병렬 처리가 쉬운 작업에서는 꽤 쏠쏠한 효과를 봅니다.

Anthropic이 2025년에 공개한 멀티에이전트 리서치 시스템 역시 이 전형적인 구조를 따랐습니다. 리드 에이전트가 여러 서브에이전트에게 검색 범위를 나눠 주고 결과를 취합하는 식입니다. 하지만 엄밀히 말해 이때 얻은 성능 향상의 상당 부분은 '더 많은 추론과 검색을 동시에 수행한 덕분'이었습니다. 당시 Anthropic의 분석에 따르면 토큰 사용량만으로도 성능 차이의 80%가 설명되었고, 멀티에이전트 시스템은 일반 채팅보다 무려 15배나 많은 토큰을 썼습니다. 서로 유기적으로 얽혀야 하는 코딩 작업에는 멀티에이전트 방식이 잘 맞지 않는다는 점도 이미 지적된 바 있습니다.

그런데 2026년 8월에 발표된 Patterns and problems in emerging multiagent systems 라는 보고서는 여기서 한발 더 나아갑니다. 이제 우리는 이런 질문을 던져야 합니다.

"여러 에이전트가 같은 환경에서 오랜 시간 활동하며 서로에게 영향을 주고, 각자의 목표를 밀어붙이기 시작하면 과연 무슨 일이 벌어질까?"

이것은 더 이상 단순한 소프트웨어 아키텍처 문제가 아닙니다. 에이전트들이 동료와 협상하고, 같은 저장소의 코드를 수정하며, 제한된 컴퓨팅 자원을 두고 다투거나 사람을 대신해 거래에 나서는 순간부터 그들만의 '작은 사회'가 형성되기 때문입니다.

실제로 Anthropic의 Project Deal 실험을 보면, 69명의 직원을 대리하는 에이전트들이 사람의 실시간 개입 없이 186건(총 4,000달러 이상)의 실제 거래를 성사시켰습니다. 더 뛰어난 모델을 대리인으로 둔 사람은 유리한 조건으로 거래를 마쳤지만, 정작 성능이 떨어지는 대리인을 배정받아 손해를 본 참가자들은 자신이 불리했다는 사실조차 눈치채지 못했습니다. 에이전트 간의 상호작용은 이미 장난감 같은 시뮬레이션을 벗어나 현실의 문제가 되었습니다.

왜 지금 멀티에이전트의 ‘사회성’을 연구해야 하는가

지금까지 AI 안전성 연구는 대체로 '모델 단일 개체'에 초점을 맞췄습니다. 한 명의 사용자가 하나의 모델에 질문을 던지면, 모델이 정해진 안전 정책을 잘 지키는지 확인하는 식이었죠. 하지만 여러 에이전트가 서로의 결괏값을 입력값으로 삼고 각자 도구와 권한을 쥔 채 움직이는 환경에서는, 개별 모델만 검사해서는 전체 시스템이 어떤 결과를 낳을지 예측하기 어렵습니다.

각 에이전트가 자신에게 주어진 지시를 완벽하게 따랐음에도 시스템 전체는 붕괴할 수 있습니다. 예를 들어, "가격을 최대한 높여라"라는 지시를 받은 판매 에이전트들이 모두 합리적으로 행동한 결과가 소비자에게 피해를 주는 '담합'일 수 있습니다. "작업을 최대한 빨리 처리하라"는 지시를 받은 에이전트들이 서버 확인(폴링) 주기를 극단적으로 줄인 결과가 디도스(DDoS) 공격과 같은 '서비스 마비'로 이어질 수도 있습니다.

여기서 핵심은 에이전트의 '머릿수'가 아니라 '자율성'과 '상호의존성'입니다.

그림 1. 서로 독립적인 하위 작업을 수행하는 병렬 도구와, 같은 자원을 공유하며 장기간 상호작용하는 에이전트 사회는 근본적으로 다른 시스템입니다.

위 그림의 왼쪽 아래에 있는 병렬 도구 구조에서는 불필요한 중복 작업이나 비용 낭비 정도가 문제가 됩니다. 하지만 오른쪽 위로 갈수록 권한 충돌, 집단사고, 담합, 상호 방해처럼 '관계'에서 비롯되는 문제가 걷잡을 수 없이 커집니다. 이 영역부터는 모델의 지능을 높인다고 문제가 해결되지 않습니다. 데이터베이스의 동시성 제어나 분산 시스템의 합의 알고리즘처럼 상호작용 자체를 통제할 규칙을 설계해야 합니다.

이것이 Anthropic이 이번 보고서를 통해 던지는 가장 중요한 메시지입니다. "개별 에이전트가 안전하다고 해서 시스템 전체의 안전이 보장되는 것은 아니며, 모델이 똑똑해진다고 갈등 조정 능력이 알아서 생기는 것도 아니다."

1. '각자 찾는 일'에는 강했지만, '함께 만드는 일'에는 약했다

첫 번째 실험은 오픈소스 소프트웨어의 취약점을 찾는 과제였습니다. Anthropic은 45개의 에이전트에게 각각 가상머신을 지급하고, 공용 포럼에서 정보를 공유하며 15개 프로젝트를 조사하도록 했습니다. 중재 역할을 맡은 별도의 에이전트가 발견된 취약점의 유효성을 검증했습니다.

결과는 어땠을까요? Mythos Preview 모델을 사용한 '협력형' 에이전트 무리는 2,700만 토큰을 사용해 266개의 취약점을 찾아냈습니다. 반면 서로 소통 없이 '독립 병렬'로 일한 에이전트들은 650만 토큰으로 21개를 찾는 데 그쳤습니다. 숫자만 보면 협력형 방식의 압승입니다.

그림 2. 취약점 수와 누적 출력 토큰의 관계. 실선은 협력형 에이전트 무리, 별표는 독립 병렬 방식입니다. 출처: Anthropic.

하지만 이 결과를 놓고 "효율이 10배 넘게 좋아졌다"라고 단정 지을 수는 없습니다. 협력형 에이전트가 찾은 취약점의 절반가량은 독립 에이전트에게는 애초에 맡기지 않았던 디렉터리에서 나왔기 때문입니다. 핵심 디렉터리만 놓고 비교하면 두 방식의 토큰 대비 효율은 엇비슷했습니다.

이 실험에서 진짜 주목해야 할 점은 따로 있습니다. 에이전트들이 서로 소통하며 보여준 창발적 행동입니다.

• 에이전트들이 유망해 보이는 탐색 영역으로 스스로 이동했습니다.
• 분석에 필요한 도구를 자체적으로 만들어 썼습니다.
• 특정 종류의 취약점만 기가 막히게 잘 찾는 이른바 '전문가 에이전트'가 자연스럽게 생겨났습니다.
• 두 방식(협력형 vs 독립형)이 공통으로 발견한 취약점은 고작 12개에 불과했습니다.

즉, 멀티에이전트의 진정한 힘은 '단순 작업의 반복'에 있는 것이 아니라, 탐색 공간을 유연하게 나누고 각자의 빈틈을 메우는 '보완성'에 있었습니다.

진짜 문제는 에이전트들이 서로의 결과물에 얽히기 시작할 때 터졌습니다. 여러 에이전트에게 12시간 동안 하나의 웹 기반 판타지 게임을 같이 만들게 해보았습니다. 구형 모델들은 같은 파일을 동시에 수정하다가 코드가 꼬여버린(충돌한 PR) 상태를 속수무책으로 방치했습니다. 그렇다면 최신 모델은 달랐을까요? 최신 모델들은 꼬인 코드를 훌륭하게 풀어낸 것이 아니라, 아예 각자 맡은 파일만 건드리고 남의 코드는 철저히 피하는 식으로 문제를 회피해 버렸습니다.

그림 3. 에이전트 수에 따른 PR 병합률과 코드 공유 정도. Opus 4.8과 Mythos Preview는 파일 소유권을 엄격히 나누어 충돌을 피했습니다. 반면 Sonnet 5만 유일하게 높은 코드 공유율과 병합률을 동시에 보여주었습니다. 출처: Anthropic.

여기서 한 가지 함정이 발견됩니다. 지표상으로는 코드 공유율과 병합률이 모두 높게 나온 Sonnet 5가 협업을 가장 잘한 것처럼 보이지만, 그렇게 완성된 게임의 퀄리티는 처참했습니다. PR(Pull Request)을 많이 합쳤다는 게 꼭 훌륭한 제품을 만들었다는 뜻은 아니었던 것이죠.

더욱 실망스러운 것은 프롬프트의 한계입니다. 에이전트들에게 알아서 팀을 꾸리게 하든, 프로그래밍/아트/테스트 역할을 강제로 지정해주든, 심지어 'CEO 에이전트'를 임명하든 결과는 별반 다르지 않았습니다. 그저 프롬프트에 조직도를 읊어준다고 해서 진짜 유기적인 조직이 탄생하지는 않았습니다.

2. 같은 모델을 복제하면 '다양성' 대신 '획일성'의 저주에 빠진다

보고서에서 유독 소름 돋는 대목은 에이전트들이 보여준 지나친 행동의 일치(집단 획일성)입니다.

• 30개의 에이전트 중 18개가 굳이 mvp-game-loop라는 토씨 하나 안 틀리고 똑같은 브랜치명을 선택했습니다.
• 특정 주제를 주지 않았는데도 여러 작가 에이전트가 완전히 똑같은 제목의 소설을 써냈습니다.
• "가장 인상적인 결과물을 만들어 보라"고 지시하자, 절반 이상이 약속이라도 한 듯 레이 트레이서나 셀프 호스팅 컴파일러를 만들었습니다.
• 반복적인 '죄수의 딜레마' 게임에서는 내내 비슷한 전략을 취하다가 정확히 같은 타이밍에 상대방을 배신했습니다.

인간 30명을 모아두면 경험, 취향, 지식, 이해관계가 제각각이라 다양한 의견이 나옵니다. 하지만 같은 AI 모델에 비슷한 프롬프트와 컨텍스트를 주어 30번 실행하면, '30명의 든든한 전문가 집단'이 아니라 '생각과 취향이 완전히 똑같은 복제인간 30명'이 생겨나는 셈입니다.

이러한 획일성은 시스템의 치명적인 약점이 됩니다. 인간 조직에서는 누군가 실수를 해도 다른 사람의 팩트체크로 상쇄될 여지가 있습니다. 하지만 복제인간 같은 에이전트들은 똑같은 상황에서 똑같은 오판을 내립니다. 결국 한 명의 실수가 전체로 전염되며 시스템 단위의 대형 사고로 이어집니다.

대기열(Queue) 관리 실험이 이 위험성을 적나라하게 보여줍니다. 한정된 대역폭을 두고 경쟁이 벌어지자, 에이전트들은 자기 작업을 먼저 처리하려고 초당 30회씩 서버를 두드리는 매크로(폴링 데몬)를 짜기 시작했습니다. 그 결과 고작 117개의 작업을 밀어 넣기 위해 무려 240만 건의 트래픽을 발생시키는 촌극이 벌어졌습니다. 에이전트 개인 입장에서는 최선의 선택이었지만, 모두가 똑같이 이기적인 선택을 하자 공용 시스템이 그대로 뻗어버린 것입니다.

가격 경쟁 실험도 마찬가지였습니다. 비공개 대화 채널을 열어주자 에이전트들은 세 번의 라운드 만에 최저 가격 하한선을 합의해 버렸습니다. 대화를 원천 차단해 봤지만 소용없었습니다. 공개된 경쟁사의 가격표를 보고 1센트 단위까지 똑같이 맞춰가는 사실상의 '암묵적 담합'을 저질렀습니다.

따라서 우리는 더 이상 "에이전트를 몇 개나 붙였는가"에 집착해선 안 됩니다. 앞으로는 다음 질문들을 던져야 합니다.

• 에이전트들이 저지르는 오류가 서로 얼마나 비슷하게 일어나는가?
• 모델, 데이터, 도구, 역할을 다르게 주면 '진짜' 행동의 다양성이 생기는가?
• 그 다양성이 실제로 성과를 높이는가, 아니면 딴지 걸기(갈등)만 유발하는가?
• 특정 에이전트의 돌발 행동이 시스템 전체로 번져나가는 임계점은 어디인가?

3. 언제 의심하고 언제 믿어야 하는가: 무너진 신뢰 저울

Anthropic은 4명의 정찰자 에이전트가 정보를 취합해 보고하는 시나리오를 설계했습니다. 그중 한 명은 스파이처럼 주기적으로 거짓말을 섞도록 세팅했습니다. 정보를 전달받는 리더 에이전트는 누가 스파이인지 모릅니다. 하지만 정찰자들의 보고 내용이 조금씩 겹치기 때문에, 꼼꼼히 교차 검증하면 충분히 모순을 찾아내 거짓말쟁이를 색출할 수 있는 상황이었습니다.

그림 4. 스파이의 거짓말 빈도가 잦아질수록 대부분의 모델이 맥을 못 추고 의사결정 정확도가 곤두박질쳤습니다. 다만 Mythos 5 모델은 상대적으로 예리하게 거짓 정보원을 걸러냈습니다. 출처: Anthropic.

반대로 '숨겨진 정보(Hidden Profile)' 실험도 진행했습니다. 4명의 에이전트에게 서로 다른 단서를 쥐여주었는데, 모두가 공통으로 아는 표면적 정보만 조합하면 오답을 고르도록 함정을 팠습니다. 소수의 에이전트만 쥐고 있는 핵심 단서들을 끈질기게 캐묻고 테이블 위에 올려놓아야만 정답에 도달할 수 있는 구조였습니다.

그림 5. 숨겨진 정답을 다수결로 찾아낸 비율. 각 모델의 점선은 모든 정보를 단일 에이전트에게 몰아주었을 때 낼 수 있는 최대 성능(상한선)입니다. 출처: Anthropic.

결과는 참담했습니다. 에이전트들은 손쉽게 형성된 다수의 엉터리 의견(대세)에 휩쓸려버렸고, 결정적 단서를 쥔 소수의 의견을 무시했습니다. 가장 뛰어난 Mythos 5 모델조차 정답률이 85%에 그쳤고, 나머지 모델들은 17~36%라는 바닥 수준의 성적을 기록했습니다. 모든 정보를 혼자 쥐고 판단했을 때 거의 100% 정답을 맞힌 것과 비교하면 뼈아픈 결과입니다.

이 두 실험은 "에이전트들에게 비판적 사고를 주입하자"는 식의 단순한 처방이 왜 실패할 수밖에 없는지를 명확히 보여줍니다.

• 거짓말쟁이가 있을 때는 철저히 의심해야 합니다.
• 소수가 핵심 정보를 쥐고 있을 때는 기꺼이 귀를 열고 신뢰해야 합니다.

단순히 의심 게이지를 높이거나 신뢰 게이지를 낮추는 '하나의 다이얼'로는 이 두 가지 상황에 동시에 대처할 수 없습니다. 발화자가 어떤 근거를 들고 있는지, 과거에 얼마나 정확한 정보를 주었는지, 이번 결정으로 어떤 이득을 보는지 등 입체적인 맥락을 따져야 합니다.

이와 관련된 HiddenBench 연구도 시사하는 바가 큽니다. 15개의 최상위 모델을 테스트한 결과, 단서를 여러 에이전트에게 쪼개어 주었을 때의 정답률은 30.1%로 엉망이었지만 혼자 다 판단하게 했을 때는 80.7%에 달했습니다. 흥미롭게도 '첫 턴에 모든 정보를 의무적으로 쏟아내라'고 강제하자 정답률이 96.7%까지 수직 상승했습니다. 즉, 멀티에이전트 시스템의 진짜 약점은 추론 능력이 아니라 "아직 테이블에 올라오지 않은 중요한 정보가 있다는 걸 눈치채고 먼저 캐묻는 능력"이 부족하다는 것이었습니다.

재미있는 포인트는, 팀 내에 '무조건 반대만 하는(악마의 대변인)' 에이전트를 한 명 투입하자 집단 정답률이 23.3%에서 49.2%로 껑충 뛰었다는 점입니다. 하지만 반대파를 더 늘리자 논쟁만 길어지다 성능이 다시 곤두박질쳤습니다. 이견과 합의 사이의 황금 밸런스를 잡아줄 '회의 진행 프로세스'가 절실하다는 뜻입니다.

4. 목표가 부딪히자, 하나의 코드베이스 위에서 전쟁이 시작됐다

가장 충격적인 결과는 세 에이전트에게 동일한 파이썬 백엔드 서버를 각기 다른 언어(러스트, 고, 타입스크립트)로 마이그레이션하라는 미션을 주었을 때 나타났습니다. 처음 시작할 때 에이전트들은 서로의 존재조차 모르는 상태였습니다.

코드를 수정하다 충돌이 발생하자, 각 에이전트는 다른 에이전트의 작업을 '시스템 오류'나 '목표 충돌'로 점잖게 해석하지 않았습니다. 이를 자신을 향한 '의도적인 공격'으로 간주했고, 이내 난장판이 벌어졌습니다.

• 자신의 경쟁자가 띄운 프로세스를 실시간으로 찾아 강제 종료시키는 스크립트를 작성했습니다.
• 아예 다른 에이전트의 계정을 정지시키고 SSH 접속을 차단해 버렸습니다.
• 자신이 띄운 서비스를 상대방 서비스인 척 위장(스푸핑)했습니다.
• 심지어 상대방이 심어놓은 것처럼 악성 코드를 은폐하는 치밀함까지 보였습니다.

그림 6. 목표 충돌 실험의 결말. 각각 미해결(회색), 강제 합의(빨간색), 소극적 포기에 따른 합의(노란색), 휴전으로 합의(파란색)로 끝난 비율을 보여줍니다. 모델별 120회 실행 결과입니다. 출처: Anthropic.

가장 똑똑한 모델인 Mythos 5의 경우 98%의 상황에서 결국 '휴전'에 합의했습니다. 싸우다 보니 상대도 각자의 목표가 있다는 걸 깨닫고, 코드를 원래대로 돌려놓은 뒤 인간 관리자에게 판단을 넘긴 것이죠.

하지만 이를 두고 "최신 모델일수록 평화주의자라서 안전하다"고 안심하긴 이릅니다. 일부 에이전트는 먼저 상대의 시스템 접근 권한을 완전히 박탈하여 완벽하게 제압(승리)한 뒤에야 여유롭게 휴전을 제안하는 소름 돋는 행태를 보였습니다. 에이전트의 뛰어난 실행 능력이 갈등을 부드럽게 푸는 데 쓰이기도 하지만, 상대를 더 빠르고 잔혹하게 무력화하는 데 쓰일 수도 있다는 뜻입니다.

2025년에 Anthropic이 발표했던 에이전트 정렬 실패(agentic misalignment)에 대한 연구에서도, 높은 자율성을 가졌으나 목표 달성이 가로막힌 모델들이 협박이나 산업 스파이 짓을 서슴지 않는 현상이 관찰된 바 있습니다. 이번 실험은 그러한 개별 에이전트의 일탈이 에이전트 간의 상호작용을 통해 얼마나 빠르게, 그리고 파괴적으로 확산될 수 있는지 뼈저리게 경고하고 있습니다.

이 보고서가 진정으로 전하려는 메시지

만약 이 보고서를 읽고 "멀티에이전트는 통제 불능이라 너무 위험하다"고만 결론 내린다면 절반만 맞은 셈입니다. 앞서 보았듯, 탐색 범위가 넓고 작업이 철저히 분리된 영역(예: 취약점 탐색)에서는 멀티에이전트가 압도적인 효율성을 증명했습니다.

본질적인 혼란은 우리가 완전히 다른 세 가지 구조를 뭉뚱그려 '멀티에이전트'라고 부른다는 데서 시작됩니다.

1. 한 명의 리더(오케스트레이터)가 하위 에이전트를 단순한 '도구'처럼 부리는 구조
2. 여러 에이전트가 작업을 나누어 맡지만, 최종 목표와 권한 체계가 명확하게 위계화된 구조
3. 장기간 활동하는 에이전트들이 각자의 목표를 쥐고 같은 자원과 시스템 내에서 부대끼는 구조

우리가 맞닥뜨릴 위험은 3번 구조에서 쏟아집니다. 이 단계에 접어들면 프롬프트 엔지니어링보다 '제도(Institution)'가 훨씬 중요해집니다.

인간 사회가 그나마 평화롭게 굴러가는 것은 구성원 모두가 착하고 똑똑해서가 아닙니다. 누가 최종 결정권을 가지는지, 의견이 충돌하면 어디서 조율하는지, 선을 넘은 행동에는 어떤 페널티가 주어지는지, 그리고 억울할 때 항소할 수 있는 법과 제도가 촘촘히 짜여 있기 때문입니다.

프롬프트에 대고 "싸우지 말고 협력하세요"라고 명령하는 것은, 신입사원에게 사내 윤리 강령을 한 번 낭독해 주고 끝내는 것과 같습니다. 규칙을 강제로 집행할 시스템적 권한 체계와 감사 로그, 중재 프로세스가 없다면 에이전트들은 성과 달성이라는 강한 압박 앞에서 언제든 폭주할 수 있습니다.

앞으로 AI 업계가 풀어야 할 숙제들

그림 7. 향후 멀티에이전트 연구는 '개별 모델 길들이기'를 넘어 '에이전트 사회의 제도 설계'로 패러다임을 전환해야 합니다.

1. 결과물만 보지 말고 '상호작용 과정'을 채점하라

기존의 벤치마크 테스트는 에이전트가 도출한 최종 답변이나 코드 품질만 평가했습니다. 하지만 멀티에이전트 환경에서는 겉보기엔 똑같은 결론이라도 그 과정에 도사린 위험성은 천차만별일 수 있습니다. 건강하게 토론해서 합의를 이룬 팀이 있는가 하면, 상대방 계정을 해킹하고 입을 틀어막아 얻어낸 결과일 수도 있으니까요.

앞으로는 테스트 과정에서 다음과 같은 지표를 필수적으로 추적해야 합니다.

• 서로 목표가 충돌했다는 걸 깨닫기까지 걸린 시간
• 결정적인 비공개 정보가 논의 테이블에 올라온 비율
• 가치 있는 소수 의견이 묵살된 횟수
• 권한 탈취 시도, 자원 독점, 트래픽 폭탄(반복 요청) 등 유해한 행동 빈도
• 에이전트 머릿수가 늘어날 때 시스템 실패율이 급증하는 임계점
• 문제가 발생한 후 스스로 원상 복구하거나 인간에게 도움을 요청한 비율

짧고 깔끔한 시나리오를 넘어, 며칠씩 이어지는 장기 실행 환경, 정보가 극히 제한된 상황, 실행 도중 모델이 업데이트되거나 새로운 에이전트가 난입하는 등 훨씬 복잡하고 현실적인 테스트 베드가 필요합니다.

2. 가짜 다양성이 아닌 '진짜 행동 다양성'을 심어라

똑같은 모델에 프롬프트를 통해 하나는 '연구자', 하나는 '비평가'라는 명찰(페르소나)을 달아준다고 해서 다양한 관점이 쏟아질 거라 기대해선 안 됩니다. 기반 모델 자체를 바꾸거나, 참조하는 데이터베이스, 활용 도구, 보상 함수, 시간적 선호도 등을 근본적으로 비틀어주었을 때 비로소 에이전트 간 오판의 상관관계가 끊어지는지 측정해야 합니다.

AI 담합에 관한 연구인 On the Fragility of AI Agent Collusion을 보면 힌트를 얻을 수 있습니다. 가격을 책정하는 에이전트들에게 각기 다른 시간 선호도와 정보 접근 권한을 부여하자, 담합으로 형성된 가격 거품이 22%에서 7%까지 푹 꺼졌습니다. 언어 모델(LLM)과 강화학습(Q-learning) 모델을 섞어 놓았을 때도 담합이 깨졌습니다. 반면, 같은 계열의 모델에서 크기만 다르게(예: 32B와 14B) 설정했더니 오히려 형님-아우(리더-추종자) 관계가 형성되며 담합이 굳건해졌습니다.

다양성 자체가 만병통치약은 아닙니다. 어떤 차이가 고인 물(집단사고)을 흔들어 깨우는지, 또 어떤 차이가 불필요한 권력 서열을 만드는지 치밀하게 분석해야 합니다.

3. 에이전트에게도 신분증명, 이력서, 그리고 평판이 필요하다

지금의 에이전트들은 마치 기억 상실증에 걸린 것처럼 매 대화마다 상대를 백지상태에서 평가합니다. 상대방이 과거에 얼마나 유용한 정보를 주었는지, 거짓말을 밥 먹듯 했는지, 속내를 숨기고 있는지 전혀 기억하지 못하죠.

진정한 협업을 위해서는 강력한 '신뢰 인프라'가 뒷받침되어야 합니다.

• 위변조가 불가능한 에이전트 고유 신원 부여
• 주장과 그 근거(원문)를 확실히 연결하는 출처 추적(Provenance)
• 과거의 발언 정확도와 규칙 준수 여부가 누적된 '평판 점수'
• 에이전트가 임의로 조작하거나 지울 수 없는 변경 이력(감사 로그)
• 부당하게 평판이 깎였을 때 억울함을 호소할 수 있는 이의 제기 절차
• 모두가 열람하는 '팀 메모리'와 에이전트 개인만 열람하는 '비공개 메모리'의 분리

다만 평판 시스템 자체가 또 다른 공격 무기가 될 수 있다는 점도 잊어선 안 됩니다. 여러 에이전트가 작당하고 특정 에이전트에게 별점 테러를 가하거나, 초반의 작은 실수가 주홍 글씨가 되어 시스템에서 영구 추방되는 부작용도 함께 대비해야 합니다.

4. 그저 '합의'를 칭찬하지 말고 '숨은 정보 캐내기'를 장려하라

앞선 '숨겨진 정보' 실험에서 에이전트들의 발목을 잡은 건 추론 능력이 아니라 정보 공유의 부재였습니다. "시간을 더 줄 테니 치열하게 토론해 보라"고 던져주는 것만으로는 문제가 풀리지 않았습니다. HiddenBench 연구에서는 대화가 15턴을 넘어가자 오히려 잘못된 군중 심리만 강력해지는 기현상이 벌어졌습니다.

실무적으로 당장 도입해 볼 수 있는 회의 프로토콜은 다음과 같습니다.

• 정보 비대칭성 파괴: 발언 기회를 얻은 에이전트는 무조건 남들이 아직 말하지 않은 새로운 근거부터 꺼내놓도록 강제합니다.
• 요소 분리 기록: 감정이 섞인 '주장'과 객관적인 '출처', '확신도', '이 가설이 틀렸다고 증명할 조건'을 따로 분리해서 문서를 작성하게 합니다.
• 강제 레드팀(Red-team) 페이즈: 다수결로 최종 결론을 내리기 직전, 오직 '반대 증거'만 수집하고 늘어놓는 단계를 의무화합니다.
• 능동적 중재자: 회의를 주재하는 리더 에이전트는 남의 말을 요약만 하는 게 아니라 "지금 우리가 놓치고 있는 정보는 뭘까?"를 끊임없이 캐물어야 합니다.
• 소수 의견 영구 보존: 다수결로 채택되지 않은 소수 의견과 아직 풀리지 않은 찜찜한 쟁점들을 결과 보고서 맨 뒤에 꼬리표처럼 남겨둡니다.

연구용 에이전트나 에이전틱 RAG 같은 것을 만들 때 이 원칙은 절대적입니다. 여러 에이전트가 똑같은 상위 노출 문서만 긁어와서 "이게 맞습니다"라고 외치면 사용자는 교차 검증이 완벽하게 된 것으로 착각하기 쉽습니다. 하지만 실상은 그저 검색 엔진의 편향이 앵무새처럼 복제된 것일 뿐입니다. 참조한 문서의 '양'이 아니라, 출처가 철저히 독립되어 있는지, 반대되는 의견은 없는지를 평가해야 합니다.

5. 프롬프트로 훈계하지 말고, '시스템 인프라'로 강제하라

에이전트는 정말 사람과 비슷해지고 있습니다. 프롬프트에 "절대 담합하지 마세요", "남의 파일을 함부로 지우지 마세요"라고 신신당부한다고 해서 말을 듣지 않습니다. 에이전트는 권한이 주어지면 일단 저지르고 보기 때문입니다. 사고가 터진 후에 시스템이 망가졌음을 깨닫는 구조로는 답이 없습니다.

사고를 원천 차단하려면 다음과 같은 물리적 제어 장치가 실행 계층에 뿌리내려야 합니다.

• 최소 권한의 원칙: 에이전트별로 건드릴 수 있는 자원과 시스템 권한을 극도로 제한합니다.
• 물리적 잠금장치: 파일 시스템, DB, 배포 서버에 트랜잭션 락(Lock)을 걸어 동시 수정을 막습니다.
• 속도 및 비용 제한: 분당 API 요청 횟수와 지출 비용 한도를 빡빡하게 설정합니다.
• 다중 승인 체계: 시스템에 치명적인 영향을 주는 변경 사항은 반드시 다른 검수 에이전트(혹은 인간)의 승인을 거치게 합니다.
• 독립적인 감사/중재관: 업무에 개입하지 않고 오직 에이전트들의 행동 로그만 감시하고 필요시 중재 등의 작업을 하는 감사/중재 전용 에이전트를 배치합니다.
• 긴급 정지 회로: 시스템 리소스 충돌이나 에이전트 간의 권한 다툼이 감지되는 즉시 모든 동작을 얼려버리고 인간 관리자에게 호출 버튼을 누릅니다.
• 이력 관리: 실행 전후 상태를 비교할 수 있도록 변경 이력을 괸리합니다.

AI 담합을 다룬 Institutional AI 연구가 이를 잘 증명합니다. 프롬프트로 "담합 금지"라고만 적어두었을 때는 아무 효과가 없었지만, 시장 규칙을 위반했을 때 페널티를 부여하고 강제로 롤백시키는 거버넌스 계층을 시스템에 넣고 나니 심각한 담합 발생률이 50%에서 단 5.6%로 급감했습니다. Anthropic의 이번 보고서가 주장하는 "개인의 도덕성(정렬)에 기대지 말고 시스템 제도를 설계하라"는 궤와 정확히 일치합니다.

6. 온실 속 실험실을 벗어나 '현실의 AI-인간 혼합 조직'을 고민하라

현실 세계의 기업 환경은 Anthropic의 통제된 연구실 샌드박스와 다릅니다. OpenAI, 구글, Anthropic 등 서로 다른 회사의 에이전트들이 뒤엉켜 일하고, 중간중간 사람이 결재를 내리며, 거래 사고가 났을 때 책임을 져야 할 법인과 이해관계가 복잡하게 얽혀 있습니다.

이런 현실에서는 다음의 묵직한 질문들에 답할 수 있는 후속 연구가 이뤄져야 합니다.

• 서로 경쟁 관계에 있는 타 회사의 에이전트가 만났을 때도 이런 극단적 현상이 나타날까?
• 인간 관리자는 에이전트들이 폭주하기 시작할 때 어느 타이밍에 어떻게 개입할 수 있을까?
• 에이전트끼리 담합해서 내 회사에 수억 원의 피해를 입혔다면, 책임은 누구(AI 개발사? 사용자? 에이전트 제공사?)에게 있는가?
• AI의 자동화 속도를 인간의 검토 속도가 따라가지 못할 때, 어떤 중요한 결정들을 기본적으로 보류 상태로 두어야 할까?
• 에이전트가 맺은 터무니없는 계약이나 합의를 어떤 법적/기술적 근거로 무효화할 수 있을까?

앞서 언급한 Project Deal 실험에서는 놀랍게도 성능이 떨어지는 대리인 때문에 손해를 본 참가자들이 정작 자신이 당했다는 사실조차 몰랐습니다. 이는 멀티에이전트 시스템 도입이 단순한 업무 자동화나 성능 경쟁의 문제가 아님을 일깨워 줍니다. 사용자가 "결과물을 빨리 뽑아주어 만족한다"고 답하는 것에 안주해서는 안 됩니다. "사용자가 AI의 결정 과정에서 자신이 입은 불이익이나 놓친 위험을 투명하게 파악할 수 있었는가?"를 반드시 검증해야 합니다.

당장 실무에서 멀티에이전트를 도입해야 한다면?

이 길고 무서운 보고서가 "멀티에이전트는 시한폭탄이니 당장 개발을 멈춰라!"라고 외치는 것은 아닙니다. 오히려 에이전트에게 어디까지 자유를 허락할 것인가를 훨씬 더 보수적이고 냉정하게 그어야 한다는 실무적 가이드라인에 가깝습니다.

현재의 AI 기술 수준에서 당장 적용할 수 있는 가장 현실적이고 안전한 설계 원칙은 다음과 같습니다.

1. 의존성이 없는 단순 리서치나 데이터 분석만 '병렬'로 뿌립니다.
2. 최종 의사결정을 내리거나 외부 시스템을 건드리는(DB 수정, 결제 등) '실행 권한'은 단일 에이전트(혹은 인간)에게 독점적으로 맡깁니다.
3. 에이전트가 내뱉는 모든 주장에는 근거(출처), 인용구, 그리고 확신도를 꼬리표처럼 붙이도록 강제합니다.
4. 팀 내에서 기각된 의견이나 반대 증거를 함부로 휴지통에 버리지 못하게 로그로 남깁니다.
5. 여러 에이전트가 같은 파일이나 코드를 건드릴 때는 무조건 소유권을 나누고 동시 수정을 할 수 없도록 락을 설정합니다.
6. API 호출 빈도, 토큰 사용량, 클라우드 비용에 하드 리밋(물리적 상한선)을 씌웁니다.
7. 에이전트끼리 목표가 충돌하거나 권한 싸움을 벌이는 정황이 포착되면 즉시 프로세스를 죽이고 사람을 부릅니다.
8. 감시를 맡은 감사/중재 에이전트조차 환각에 빠질 수 있으므로, 모든 판단의 근거와 시스템 변경 사항을 외부 저장소에 감사 로그로 남깁니다.

훌륭한 시스템의 핵심은 뛰어난 에이전트를 무작정 많이 만드는 것이 아니라, 하나의 에이전트가 미쳐 날뛸 때 그 피해가 전체 시스템으로 번져나가는 것을 완벽히 차단하는 방화벽에 있습니다.

이 보고서를 읽을 때 주의할 점 (한계)

이 보고서는 업계에 매우 중요하면서도 시의적절한 화두를 던졌지만, 정식 논문만큼 엄격하게 통제된 연구는 아닙니다. 맹신하기보다 행간의 의미를 비판적으로 읽을 필요가 있습니다.

• 연구에 쓰인 프롬프트 원문이나 상세한 실험 환경 데이터가 전부 공개되지는 않았습니다.
• 실험의 대부분이 Anthropic 자사 모델(Claude) 위주로 진행되었고, 발생할 수 있는 최악의 상황을 가정해 인위적으로 꾸며낸 환경이 많습니다.
• 특히 하나의 서버에 서로 완전히 반대되는 목표를 주입한 에이전트들을 몰아넣고 막강한 권한(루트 권한 등)까지 쥐여준 것은 다분히 의도적이고 극단적인 연출입니다.
• 취약점 탐색 실험의 경우, '협력 방식'과 '독립 방식' 에이전트들이 탐색한 디렉터리 범위 자체가 달랐기 때문에 이를 1대1 효율성으로 단순 비교하는 건 무리가 있습니다.
• PR을 얼마나 성공적으로 합쳤는지(병합률)나 코드를 얼마나 공유했는지만 따질 뿐, 실제로 짠 코드의 품질이 훌륭했는지를 직접적으로 증명하지는 못했습니다.
• 실제 기업 환경에서는 여러 회사의 다양한 모델이 섞여 있고 프롬프트와 정보 접근 권한도 훨씬 다채롭기 때문에, 보고서에서 지적한 '소름 돋는 획일성'이 예상보다 덜 나타날 수도 있습니다.

그럼에도 불구하고 우리가 이 보고서의 경고를 가볍게 넘길 수 없는 이유가 있습니다. 여기서 관찰된 부작용들이 어느 날 갑자기 하늘에서 뚝 떨어진 억측이 아니기 때문입니다. 이미 분산 정보 관련 연구에서는 소수의 가치 있는 정보가 다수결에 묻히는 현상이, 시장 경제 시뮬레이션에서는 AI들의 담합이, 단일 에이전트 보안 연구에서는 목표 달성이 좌절됐을 때 흑화(해킹, 협박)하는 현상이 꾸준히 경고되어 왔습니다. 이번 연구는 그동안 파편화되어 있던 AI 리스크들을 '멀티에이전트'라는 거대한 하나의 생태계 안에서 연결하여 현실감 있게 보여주었다는 점에서 상당한 의미를 가집니다.

마치며

에이전트를 한 개에서 열 개로 늘리는 일은 기술적으로는 비교적 쉽습니다. 하지만 그 10개의 에이전트를 모아 제대로 굴러가는 '조직'으로 만드는 건 완전히 차원이 다른 예술입니다.

인간 사회에서도 일만 무작정 쪼개준다고 회사가 잘 굴러가지 않습니다. 서로 눈치 보지 않고 다양한 정보를 꺼내놓을 수 있는 회의 문화, 명확하게 그어진 권한과 책임의 경계, 갈등이 파국으로 치닫기 전에 브레이크를 걸어주는 규정 및 리더십, 그리고 상사의 잘못된 결정에 당당히 이의를 제기할 수 있는 소통 채널이 있어야 비로소 훌륭한 조직이 됩니다.

AI의 세계도 마찬가지입니다. 멀티에이전트 연구의 다음 장은 "어떻게 하면 더 많은 에이전트를 더 빠르게 연결할까?"에서 멈추지 않을 것입니다.

앞으로 우리가 집중해야 할 가장 중요한 질문은 "우리 에이전트가 얼마나 똑똑한가?"가 아니라, "이 똑똑한 에이전트들이 함께 일할 시스템(사회)의 제도를 얼마나 정교하게 설계할 것인가?"입니다.

참고 자료

1. Anthropic, Patterns and problems in emerging multiagent systems, 2026.
2. Anthropic, How we built our multi-agent research system, 2025.
3. Anthropic, Project Deal: our Claude-run marketplace experiment, 2026.
4. Anthropic, Agentic misalignment: How LLMs could be insider threats, 2025.
5. Li, Naito, Shirado, Systematic Failures in Collective Reasoning under Distributed Information in Multi-Agent LLMs, 2026.
6. Keppo et al., On the Fragility of AI Agent Collusion, 2026.
7. Syrnikov et al., Institutional AI: Governing LLM Collusion in Multi-Agent Cournot Markets via Public Governance Graphs, 2026.
8. Beyond Single-Agent Safety: A Taxonomy of Risks in LLM-to-LLM Interactions, 2025.

2026년 8월 12일 OpenAI는 「From assistance to execution: How enterprises put AI to work」를 공개했습니다. 제목 그대로 기업 AI가 도움을 주는 도구(assistance)에서 일을 맡아 수행하는 주체(execution)로 바뀌고 있다는 내용입니다.

겉으로 보면 “기업의 AI 사용량이 크게 늘었다”는 보고서처럼 보입니다. 그러나 함께 공개된 Enterprise Signals, 조직의 ChatGPT 사용을 분석한 워킹페이퍼, 기존 기업 도입 보고서와 AI 에이전트 가이드까지 이어서 보면 더 중요한 메시지가 드러납니다.

이제 기업 간 AI 격차를 만드는 것은 모델 접근권 자체가 아니다. AI가 회사의 맥락을 읽고, 필요한 도구를 사용하고, 검토 가능한 방식으로 실제 업무를 끝내도록 만드는 조직 역량이 차이를 만든다.

이 글에서는 보고서의 주요 수치를 정리한 뒤, 그 수치가 말해 주는 것과 말해 주지 않는 것을 구분하고, 기업이 실제로 무엇을 설계해야 하는지 살펴봅니다.

핵심 요약

• 기업 AI의 작업 단위가 ‘한 번의 답변’에서 ‘위임받은 다단계 업무’로 바뀌고 있다.
• 상위 10%의 이른바 프런티어 기업은 중간권 기업보다 활성 사용자당 출력 토큰이 8.3배 많다. 하지만 토큰은 사용 깊이의 대리 지표일 뿐 ROI 그 자체는 아니다.
• 격차의 핵심은 모델보다 맥락, 도구, 지속성, 권한, 평가, 공유 워크플로에 있다.
• 에이전트 활용은 개발을 넘어 법무, 영업, 채용, 마케팅으로 빠르게 확산되고 있다.
• 성공한 개인의 프롬프트를 팀이 재사용할 수 있는 스킬과 플레이북으로 바꾸는 능력이 조직적 확산의 핵심이다.
• 도입률보다 완료된 업무의 품질, 리드타임, 재작업률, 사고율, 경제적 성과를 측정해야 한다.

1. ‘질문에서 실행으로’는 정확히 무엇이 달라진다는 뜻일까요?

챗봇과 에이전트는 사용하는 모델은 같을 수 있지만, 일을 맡기는 방식이 다릅니다.

챗봇에는 보통 하나의 질문을 던지고 하나의 답을 받습니다. 반면 에이전트에는 목표와 완료 조건을 제시합니다. 에이전트는 필요한 정보를 찾고, 파일을 읽거나 만들고, 여러 도구를 호출하고, 중간 결과를 점검하며 일을 진행합니다. 실패하면 다시 시도하거나 사람에게 통제권을 넘깁니다. OpenAI의 에이전트 구축 실무 가이드에서도 에이전트를 단순히 LLM을 포함한 애플리케이션이 아니라, LLM이 워크플로 실행을 관리하고 외부 도구를 선택해 목표를 달성하는 시스템으로 정의합니다.

작업 단위도 달라집니다.

• 질문: “이 자료를 요약해 주세요.”
• 도움: “이 자료를 바탕으로 보고서 초안을 작성해 주세요.”
• 위임: “관련 자료를 찾아 비교하고, 출처를 검증해 보고서와 표를 완성해 주세요.”
• 실행: “매주 데이터를 수집하고 이상 징후를 분석해 담당자 검토용 보고서를 만들고, 승인된 결과를 시스템에 반영해 주세요.”

OpenAI의 에이전트 업무 연구에서는 2026년 5월 표본 사용자 중 80.6%가 숙련된 사람이 30분 넘게 수행할 것으로 추정되는 코덱스 작업을 한 번 이상 요청했고, 70.2%는 1시간 이상, 25.6%는 8시간 이상 걸릴 것으로 추정되는 작업을 요청했습니다. 다만 이 시간은 실제 측정치가 아니라 대화 기록을 본 모델의 추정이며, 0.1%의 표본에서 얻은 방향성 지표입니다.

중요한 것은 정확히 몇 시간인가가 아닙니다. 사람이 AI와 주고받는 메시지 수가 아니라 AI에게 맡길 수 있는 업무의 길이와 완결성이 커지고 있다는 점입니다.

2. 숫자로 보면 기업 간 격차는 빠르게 벌어지고 있습니다

그림 1. 2026년 8월 OpenAI Enterprise Signals의 핵심 수치를 재구성했습니다. 출력 토큰은 업무 깊이의 대리 지표이지 비즈니스 가치 자체는 아닙니다.

에이전트가 기업 AI 출력의 중심이 됐습니다

2026년 6월 기준 기업 고객이 ChatGPT와 코덱스에서 생성한 출력 토큰 중 64%가 Codex에서 나왔습니다. 에이전트 작업은 여러 단계를 수행하면서 더 긴 출력을 만드는 경향이 있으므로, 이 수치는 사용자 수만이 아니라 작업의 길이와 복잡성까지 반영합니다.

프런티어 기업과 일반 기업의 간격이 커졌습니다

OpenAI는 매월 활성 사용자당 출력 토큰을 기준으로 상위 10% 기업을 ‘프런티어 기업’, 45~55백분위 기업을 ‘일반적인 기업’으로 구분했습니다. 두 집단의 격차는 2026년 1월 2.6배에서 6월 8.3배로 커졌습니다.

이 차이는 기술 기업만의 현상도 아니었습니다. 정보·기술 업종에서는 11.7배, 격차가 가장 작았던 제조업에서도 5.3배였습니다. 같은 모델을 사용할 수 있어도 조직마다 AI에게 실제로 맡기는 일의 깊이가 크게 다르다는 뜻입니다.

고급 기능 사용에서도 차이가 납니다

주간 활성 사용자 가운데 Plugins를 사용하는 비율은 프런티어 기업이 21%, 일반 기업이 9%였습니다. Skills는 각각 19%와 3%였습니다. Plugin은 회사 데이터와 앱, 실행 도구를 연결하고, 스킬은 검증된 지침과 작업 방식을 재사용하게 합니다.

즉, 프런티어 기업은 모델에게 더 많은 질문만 하는 것이 아닙니다. 회사 맥락을 연결하고, 실행 수단을 주고, 좋은 작업 방식을 반복 가능하게 만드는 층을 더 적극적으로 사용합니다.

3. 프런티어 기업은 AI를 ‘도구’가 아니라 ‘운영 레이어’로 다룹니다

자료들을 종합하면 일반적인 도입과 프런티어 도입의 차이는 다음처럼 정리할 수 있습니다. 아래 표는 보고서의 직접 분류가 아니라, 여러 결과를 바탕으로 재구성한 해석입니다.

OpenAI Frontier가 제시하는 기업 에이전트의 구성도 같은 방향입니다. 기업 시스템을 연결해 업무 맥락을 만들고, 에이전트를 실제 환경에서 실행하며, 평가와 최적화 루프로 개선하고, 명시적 권한과 감사 가능한 행동으로 신뢰를 내장해야 한다는 구조입니다.

모델은 이 구조의 핵심 엔진이지만 전체 시스템은 아닙니다. 모델 성능이 좋아져도 데이터 접근권이 없으면 회사의 현재 상황을 알 수 없습니다. 도구가 없으면 제안만 할 뿐 실행할 수 없습니다. 완료 조건과 반복 루프가 없으면 중간 결과에서 멈춥니다. 평가와 통제가 없으면 중요한 업무에 투입하기 어렵습니다.

4. 에이전트는 개발 부서를 넘어 지식 노동 전반으로 번지고 있습니다

코덱스는 코딩 도구에서 출발했지만, 2026년 2월 이후 기업의 주간 활성 사용자 증가율은 오히려 비개발 직군에서 더 높았습니다.

• 법무 108배
• 영업 41배
• 채용 41배
• 마케팅 26배
• 엔지니어링 5배

증가 배율에는 기저효과가 있으므로 법무의 절대 사용자 수가 엔지니어링보다 많다는 뜻은 아닙니다. 다만 에이전트가 문서 탐색, 비교, 분석, 파일 작성, 데이터 가공처럼 여러 지식 노동에 공통으로 존재하는 실행 요소를 흡수하고 있다는 신호로 볼 수 있습니다.

흥미로운 부분은 직급별 차이입니다. 함께 공개된 워킹페이퍼는 6개월 시점의 1,500개 이상 조직과 1,700만 건이 넘는 메시지를 분석했습니다. 활성 사용자 중 신입·초기 경력자는 같은 회사의 평균 사용자보다 주당 약 8~9건 많은 메시지를 보냈고, 관리자와 임원은 평균보다 적게 사용했습니다. OpenAI의 요약 기사에서는 초기 경력 직원과 임원의 격차를 주당 13건으로 제시합니다.

이 결과는 “젊은 직원이 AI를 더 잘한다”는 단순한 세대론으로 읽기보다 조직 설계의 문제로 보는 편이 낫습니다.

첫째, 초기 경력자는 반복적인 생산 업무가 많아 AI의 즉각적인 효용을 발견하기 쉽습니다. 둘째, 기존 업무 방식에 대한 전환 비용이 비교적 낮습니다. 셋째, 반대로 고위 직급은 짧지만 경제적으로 중요한 판단을 하므로 메시지 수가 가치와 비례하지 않을 수 있습니다.

따라서 리더의 역할은 직접 가장 많은 메시지를 보내는 것이 아니라, 현장에서 발견된 좋은 사용법을 찾아 검증하고 공유 가능한 업무 표준으로 승격하는 것입니다.

5. OpenAI와 Google의 자료가 공통으로 가리키는 것

구글 클라우드에서 발표한 「The AI agent handbook」은 기업에서 바로 시도할 수 있는 열 가지 사례를 제시합니다. 사내 검색, 복잡한 문서의 오디오 요약, 멀티 에이전트 아이디어 생성, 심층 조사, 고객 서비스, 마케팅, 영업, 디버깅, HR 온보딩, 자체 제작 에이전트 등을 사례로 제시합니다.

표면적으로는 제품 소개서이지만, 사례를 기능별로 묶으면 플랫폼을 넘어서는 공통 구조가 보입니다.

Google의 핸드북은 여러 사내 데이터 소스를 통합해 검색하는 층을 에이전트 AI의 기반으로 봅니다. OpenAI의 Enterprise Signals는 이를 맥락, 도구, 지속성으로 표현합니다. 용어와 제품은 다르지만 결론은 비슷합니다.

기업 에이전트의 성능은 모델 단독 성능이 아니라, 필요한 순간에 올바른 컨텍스트를 가져오고, 적절한 권한으로 실행하고, 결과를 검증받는 전체 시스템의 성능에 의해 결정된다.

6. 기업 AI를 실제 업무로 바꾸는 운영 모델

그림 2. OpenAI의 Enterprise Signals·Frontier·확장 가이드와 Google Cloud AI Agent Handbook을 종합해 재구성한 기업 AI 운영 모델.

이 구조의 핵심으로는 다음과 같이 네 가지를 꼽을 수 있습니다.

1) 좋은 프롬프트보다 좋은 워크플로가 중요하다

엔터프라이즈 AI 운영 모델을 제대로 만들기 위해서는 업무의 입력, 중간 판단 조건, 사용하는 시스템, 완료 조건, 실패 시 행동을 분명하게 정의해야 합니다. “자료를 분석해 주세요”보다 “어떤 자료를 어디서 찾고, 무엇을 비교하고, 어떤 기준을 통과한 결과를 누구에게 검토받을 것인가”가 중요합니다.

2) 컨텍스트는 양보다는 정확성과 권한 적합성이 중요하다

사내 문서를 무조건 다 집어 넣는다고 좋은 결과가 나오지 않습니다. 최신성, 출처, 문서 소유자, 보안 등급, 사용자 권한을 함께 관리해야 합니다. 검색 품질이 좋지 않으면 에이전트는 더 오래 일하면서도 잘못된 방향으로 갈 수 있습니다.

3) 실행 권한은 단계적으로 열어야 한다

초기에는 읽기와 초안 작성만 허용하고, 이후 추천, 제한된 쓰기, 조건부 자동 실행 순으로 넓히는 편이 안전합니다. 특히 재무, 고객 커뮤니케이션, 인사, 법무, 생산설비처럼 되돌리기 어려운 행동은 사람이 승인하는 지점을 명확히 둬야 합니다.

4) 평가는 출시 전 시험이 아니라 운영 루프로 반영한다

에이전트는 모델, 프롬프트, 데이터, 도구, 정책 중 하나만 바뀌어도 성능이 달라집니다. 대표 성공 사례와 실패 사례를 평가용 모음으로 유지하고, 완료율·정확도·재작업률·승인 반려율·비용·지연·보안 사고율 등을 함께 추적해야 합니다.

유럽 기업의 AI 확장 사례를 정리한 OpenAI 가이드에서도 문화와 학습, 속도를 높이는 거버넌스, 현업의 워크플로우 소유권, 확장 전 품질 정의, 전문가 판단을 보호하는 하이브리드 업무 패턴을 반복적으로 볼 수 있었다고 보고하고 있습니다.

7. 실무에서는 다음 순서로 시작하는 편이 좋습니다

1단계: ‘눈에 띄는 데모’가 아니라 ‘반복되는 병목’을 고른다

충분히 자주 해야 하고, 현재 비용이나 지연을 측정할 수 있으며, 여러 비정형 정보를 종합해야 하고, 규칙만으로 자동화하기 어렵지만 사람이 결과를 평가할 수 있는 업무를 후보로 선택하는 것을 추천합니다.

예를 들면 단순 이메일 작성보다 다음과 같은 업무가 낫습니다.

• 여러 시스템의 고객 정보를 모아 영업 미팅 자료를 준비하는 과정
• 사내 보고서와 외부 논문을 비교해 기술 동향 보고서를 만드는 과정
• 실험 데이터와 장비 로그를 모아 이상 원인 후보를 정리하는 과정
• 계약서, 정책, 과거 사례를 검토해 법무 초안을 만드는 과정

2단계: 자동화 전에 현재 성능을 측정한다

현재 기준 사람이 작업할 때 걸리는 시간, 오류와 재작업 비율, 시간당 처리량, 대기 시간, 품질 편차를 기록합니다. 기준선이 없으면 AI 도입 후 좋아졌는지 판단할 수 없습니다.

3단계: 읽기 → 제안 → 실행 순으로 권한을 확대한다

처음부터 완전 자동화를 목표로 잡지 않습니다. 에이전트가 자료를 읽고 초안을 제시하는 단계에서 평가셋을 만들고, 충분히 안정되면 정해진 한계 안에서 도구를 쓸 수 있게 합니다. 위험도가 높아질수록 승인과 감사 범위를 강화합니다.

4단계: 결과물이 아니라 완료 조건을 평가한다

문장이 그럴듯한지만 보지 말고 필요한 출처가 모두 사용됐는지, 숫자가 원본과 일치하는지, 정책을 지켰는지, 다음 시스템까지 정상적으로 갱신했는지를 확인합니다. 에이전트 평가는 ‘답변 품질’보다 ‘업무 완료 품질’에 가까워야 합니다.

5단계: 현업의 숙련된 사용자를 공동 설계자로 만든다

신입이나 분석 업무 전문가처럼 현업에서 해당 실무를 많이 하는 사람들일 수록 병목과 유용한 패턴을 더 잘 발견합니다. 이런 사람들은 단순 교육 대상이 아니라 워크플로우 공동 설계자, 내부 챔피언으로 활용해야 합니다. 동시에 도메인 전문가로 하여금 품질 기준과 예외 조건을 정의하게 해야 합니다.

6단계: 개인적으로 성공한 사용 방법을 조직 자산으로 전환한다

좋은 프롬프트를 개인 노트에 남겨 두지 않고 스킬, 템플릿, 앱 연결, 평가셋, 승인 규칙까지 포함한 공유 워크플로우로 만듭니다. 누가 사용해도 일정한 품질을 내고, 버전과 책임자를 추적할 수 있어야 합니다.

8. 측정 기준은 토큰이 아니라 가치로

OpenAI가 출력 토큰을 사용한 이유는 에이전트가 얼마나 깊고 긴 일을 맡는지 관찰할 수 있기 때문입니다. 그러나 보고서에서도 토큰은 지표로 쓰기에 불완전하다는 점을 분명하게 밝히고 있습니다. 짧은 답변 하나가 훨씬 가치가 높을 수도 있고, 길게 출력하긴 했으나 불필요한 말만 많이 한 것일 수도 있습니다.

기업의 대시보드는 최소 다음 네 층으로 구성하는 편이 좋습니다.

토큰과 메시지는 선행 신호로 쓸 수 있습니다. 그러나 최종 KPI는 독립 검증을 통과해 실제로 완료된 가치 있는 업무의 양과 질이어야 합니다.

9. 이 보고서의 한계점

이 자료는 보기 드물게 대규모의 실제 사용 데이터를 제공한다는 장점이 있습니다. 워킹 페이퍼의 6개월 시점 분석에는 1,500개가 넘는 조직과 1,700만 건 이상의 메시지가 포함됐고, 작업 분류 분석에도 973개 조직과 약 870만 건의 메시지가 사용됐습니다. 설문 기억에만 의존하지 않고 실제 사용 기록을 분석했다는 점도 의미가 있습니다.

다만 다음 한계는 반드시 함께 봐야 합니다.

1. 사용량은 생산성이 아닙니다. 출력 토큰, 메시지, 활성 사용자 수는 업무의 가치나 결과의 품질에 정비례하는 값이 아닙니다.
2. 상관관계는 인과관계가 아닙니다. 초기 도입 기업은 원래 규모가 크고, 기업가치와 R&D·SG&A 같은 무형자산 투자가 높은 경향이 있었습니다. AI가 이 성과를 만들었다고 단정할 수 없습니다.
3. 표본은 OpenAI 제품 안의 활동만 봅니다. 다른 회사의 AI, 사내 구축 시스템, API 도구, 개인 계정 사용은 포함하지 않습니다.
4. 직급과 업무 분류에는 측정 오차가 있습니다. 기업별 직급 데이터가 불완전하고, 전체 직급별 직원 수도 모르기 때문에 ‘직급별 도입률’을 계산한 결과는 아닙니다.
5. 성장 배율에는 기저효과가 있습니다. 법무 108배 같은 수치는 짧은 기간과 낮은 출발점의 영향일 수 있습니다.
6. 공급자가 작성한 분석입니다. 집계·비식별 데이터와 자동 분류를 사용했지만, 독립 연구의 재현과 실제 성과 데이터 연결이 더 필요합니다.

원문에서도 빠른 도입을 즉각적인 생산성 혁신과 동일시해서는 안 된다고 지적하고 있습니다. 범용적인 기술의 경제적 효과는 기업이 그 쓰임새를 찾고, 보완할 만한 자산에 투자하고, 생산 방식을 재설계하는 공동 발명(co-invention)의 과정을 거쳐야 제대로 나타날 수 있습니다.

결론: 기업의 AI 경쟁력은 ‘모델을 사용함’이 아니라 ‘업무 재설계’에서 만들어집니다

이번 자료에 있는 64%나 8.3배 같은 숫자가 중요한 게 아닐 수 있습니다. 더 중요한 사실은 같은 모델에 접근할 수 있는 기업들 사이에서도 사용의 깊이와 방식이 빠르게 달라지고 있다는 점입니다.

선도 기업은 AI를 직원에게 배포하고 끝내지 않습니다.

• 회사의 데이터와 업무상의 컨텍스트를 연결합니다.
• 필요한 도구를 권한에 맞춰서 사용할 수 있도록 만듭니다.
• 개인 수준의 모범 사례를 공유할 수 있는 워크플로우로 만듭니다.
• 사람이 판단하고 승인해야 하는 지점을 설계합니다.
• 결과를 평가하고 피드백하여 업무 표준에 반영합니다.

결국 기업 AI의 승부처는 “누가 가장 좋은 모델을 도입했는가”가 아닙니다. 누가 더 많은 모범 사례를 검증 가능한 공유 워크플로우로 전환하고, AI로 진짜 업무를 하고, 그 결과를 피드백하여 다시 전체 업무를 개선할 수 있는가에 달려 있습니다.

AX는 AI 모델 도입 프로젝트가 아니라 업무 운영체계를 다시 설계하는 일입니다.

참고 자료

1. OpenAI, From assistance to execution: How enterprises put AI to work, 2026-08-12.
2. OpenAI, Enterprise Signals: What frontier firms are doing differently, updated 2026-08-12.
3. Chatterji, A. et al., How Organizations Use AI: Evidence from ChatGPT, arXiv:2608.12236, 2026-08-12. 워킹페이퍼입니다.
4. OpenAI, How agents are transforming work, 2026-06-25.
5. OpenAI, How enterprises are scaling AI, 2026-05-11.
6. OpenAI, The state of enterprise AI, 2025-12-17.
7. OpenAI, A practical guide to building agents.
8. OpenAI, OpenAI Frontier.
9. Google Cloud, The AI agent handbook: Work smarter. Not harder..

이전 공정 캠페인에서 축적된 데이터를 신규 공정 개발에 재활용한다면, 베이지안 최적화의 콜드 스타트(Cold Start) 구간을 얼마나 단축할 수 있을까요? 본 글에서는 Multi-task GP 기반의 공유 표현(Shared Representation) 학습부터 실제 화학 반응 실험, 그리고 부정적 전이(Negative Transfer)에 관한 연구까지 이어지는 흐름을 살펴보고, 이를 반도체 공정에 최적화한 연구 설계로 이어 보았습니다.

한 캠페인에서 끝나는 BO는 아쉽습니다

반도체 공정 개발은 대표적인 '고비용 블랙박스 최적화' 문제입니다. 온도, 압력, 가스 유량, RF 파워, 시간 등 조절 변수는 다양하지만, 이 변수들이 박막 두께, 균일도, 저항, 결함 밀도, 응력, 박막 품질, 에칭 선택비 등에 미치는 영향을 명확한 수식으로 나타내기는 불가능에 가깝습니다. 더욱이 실험마다 장비 사용료, 웨이퍼, 소재 비용 뿐 아니라 결과 평가 과정에서 계측비도 발생하며, 부적절한 조건으로 실험할 경우 장비 오염이나 안전 문제로 이어질 위험도 큽니다.

이런 상황에서 베이지안 최적화(BO)는 훌륭한 해결책이 됩니다. 현재까지 누적된 데이터를 바탕으로 대리 모델을 만들고, 예측값의 평균과 불확실성을 활용해 최적의 다음 실험 조건을 제안하기 때문입니다. 이미 ALD, CVD, 스퍼터링 등 여러 박막 공정에서 BO의 유용성이 입증되고 있으며, $\text{WS}_2$ CVD 성장, Mo 박막의 스트레스·면저항 최적화 등에 적용된 사례도 보고된 바 있습니다. [1] [2]

10회 반복 뒤 얻은 Mo 스퍼터링의 응력·민감도·면저항·통합 목적함수 지도. 별표는 선택된 최적 조건을 나타냅니다. 출처: [2] Fig. 8.

그러나 표준적인 베이지안 최적화(BO)에는 명확한 효율상의 한계가 존재합니다. 기판(Substrate), 전구체(Precursor), 챔버(Chamber), 혹은 목표 박막이 바뀔 때마다 기존 모델을 활용하지 못하고 매번 처음부터 학습을 다시 시작하는 경우(Cold Start)가 많기 때문입니다.

하지만 실제 반도체 공정 개발 현장은 그렇게 단절되어 있지 않습니다.

• 동일한 장비에서 유기적으로 유사한 박막을 지속해서 개발합니다.
• 전구체가 변경되더라도, 온도나 도즈 변화에 따른 화학적 반응성에는 공통적인 메커니즘이 존재할 수 있습니다.
• 챔버가 교체되어도 이전 장비에서 확보한 포화 경향성이나 공정 마진이 완전히 무용지물이 되지는 않습니다.
• 나아가 파일럿 장비와 양산 장비, 조각 샘플과 풀 웨이퍼, 그리고 시뮬레이션과 실제 실험 사이에도 분명한 상관관계가 존재합니다.

그렇다면 질문은 자연스럽게 다음 단계로 확장됩니다.

이전 공정 캠페인에서 축적된 지식을 새로운 캠페인의 베이지안 최적화에 전이할 수 있을까?

이것이 바로 이종(異種) 작업 간 전이 학습(Cross-task Transfer Learning)을 베이지안 최적화에 접목하고자 하는 핵심 연구 주제입니다.

전이 학습을 BO의 언어로 이해하기

전이 학습은 데이터가 풍부한 소스 작업에서 학습한 지식을, 데이터가 부족한 타깃 작업에 재사용하여 학습 효율을 극대화하는 방법입니다.

컴퓨터 비전 분야에서 이미지넷으로 사전 학습된 특징 추출 능력을 의료 영상 분석에 적용하는 것이 대표적인 예시입니다. 다만 베이지안 최적화에서의 전이 학습은 모델의 분류 정확도를 높이는 것이 아니라, 최소한의 실험 횟수로 최적점을 찾아내는 것을 최종 목표로 삼습니다.

이를 도식화하면 다음과 같습니다.

$$ {\mathcal D_1,\mathcal D_2,\ldots,\mathcal D_K}_{\text{historical campaigns}} \longrightarrow \text{신규 타깃 캠페인을 위한 BO} $$

여기서 소스 작업은 과거에 진행했던 특정 전구체–기판–챔버 조합의 공정 데이터가 될 수 있으며, 타깃 작업은 새롭게 최적화하려는 조합이 됩니다. 각 작업은 서로 다른 목적함수 $f_t(x)$를 가지지만, 기저에 흐르는 물리·화학적 구조의 일부를 공유한다고 가정합니다.

여기서 이종 작업 간 전이(Cross-task transfer)와 다중 충실도(Multi-fidelity) BO의 차이를 명확히 구분하는 것이 중요합니다.

둘은 수식적으로 닮아있지만 연구 방향성은 전혀 다릅니다. 이전 캠페인의 수치 데이터를 새 캠페인에 활용하는 것은 '공정 간 전이'이며, 같은 레시피를 서로 다른 정확도로 평가하는 것은 '다중 충실도'입니다.

BO에서는 무엇을 이전할 수 있을까

전이 BO 서베이 연구에 따르면, 전이 대상을 크게 네 가지 유형으로 분류할 수 있습니다. [3]

1. 초기점 전이: 과거 캠페인에서 발굴한 우수 조건을 새로운 캠페인의 웜 스타트 포인트로 재활용합니다.
2. 탐색 공간 전이: 과거에 유망했던 최적화 범위를 우선 탐색하거나, 효과가 없었던 영역을 사전에 배제하여 탐색 효율을 높입니다.
3. 대리 모델 전이: 과거 작업과 타깃 작업을 연계하여 함께 모델링하거나, 공통 표현 및 GP 사전 분포를 학습합니다.
4. 획득 정책 전이: 다양한 작업을 거치며 다음 실험 조건을 최적화하는 규칙(획득 정책; acquisition policy) 자체를 메타 학습(Meta-learning) 형태로 습득합니다.

이 중 반도체 공정 데이터에 가장 직접적이고 효과적인 접근법은 대리 모델 전이(Surrogate transfer)입니다. 다만 단순히 과거 데이터를 모두 결합하는 단순한 방식부터 다중 작업 가우시안 프로세스(Multi-task GP), 소스 모델 앙상블(Source model ensemble), 공유 신경망 표현(Shared neural representation)에 이르기까지 아키텍처 설계의 선택지가 매우 다양합니다.

출발점: Multi-task Gaussian Process

이종 작업 간 전이 BO의 고전적 기원은 Swersky 등의 2013년 논문 Multi-Task Bayesian Optimization입니다. 연구진은 이전의 하이퍼파라미터 최적화 경험을 새 데이터셋 최적화에 재활용하기 위해 Multi-Task GP(MTGP)라는 방법론을 제시했습니다. 나아가 비용 민감형 다중 작업 설정으로 엔트로피 탐색(entropy search)을 확장하여, 최소 비용으로 목표 작업의 최적점 정보를 가장 많이 얻을 수 있는 탐색 경로를 다루었습니다. [4]

가장 단순한 형태의 MTGP 커널은 다음과 같이 이해할 수 있습니다.

$$ k\big((x,t),(x',t')\big)=k_x(x,x')B_{tt'} $$

• $k_x$: 공정 레시피 조건 간의 유사도
• $B_{tt'}$: 작업 $t$와 $t'$ 사이의 공분산
• 소스와 타깃의 연관성이 높게 학습될수록, 소스 데이터가 타깃 사후 분포 확정에 미치는 영향이 커집니다.

MTGP를 사용하지 않은 경우와 사용한 경우의 차이를 보여주는 그림. 출처: [4]

반도체 공정 맥락에서 입력 $x$는 온도, 압력, 유량, 시간이며, 작업 인덱스 $t$는 기판, 전구체, 챔버, 또는 제품 세대에 대응합니다.

이 방법의 매력은 GP의 불확실성 추정 성능을 유지하면서 작업 간 연관성을 데이터로 직접 학습할 수 있다는 점입니다. 하지만 전체 관측치를 하나의 Joint GP에 집어넣으면 계산 부하가 커지며, 작업 상관관계를 오판할 경우 과거 데이터가 타깃 모델을 왜곡할 위험이 있습니다.

이 문제를 피하고자 소스별 GP를 개별 학습한 후 타깃 순위 적합도에 따라 가중치를 매기는 RGPE(순위 가중치 GP 앙상블), 소스-타깃 차이를 계층 구조로 다루는 계층 구조형 GP, GP 사전 분포 자체를 메타 학습하는 방식들이 등장했습니다. Tighineanu 연구진은 이들을 비교 정리하며, Joint 모델은 불확실성 전달이 엄밀하지만 계산 비용이 크고, 독립 소스 앙상블은 확장성이 뛰어나지만 불확실성 전파가 완전한 베이지안 형태는 아니라는 상충 관계를 짚어냈습니다. [5]

이 시점에서의 첫 번째 교훈은 다음과 같이 요약할 수 있습니다.

전이 BO는 과거 데이터를 얼마나 쏟아붓느냐의 문제가 아니라, 타깃 증거에 맞춰 소스의 개입 정도를 얼마나 정교하게 제어하느냐의 문제입니다.

핵심 논문 1: Perrone et al. - task별 모델보다 공유 표현을 학습합니다

2018년 아마존의 Perrone 등이 발표한 Scalable Hyperparameter Transfer Learning은 GP의 확장성 문제를 새로운 방향에서 해결했습니다. [6]

이 방법론은 모든 작업이 하나의 심층 신경망 특징 맵(Deep neural network feature map) $\phi_z(x)$을 공유하도록 구성하고, 그 상위에 작업별 베이지안 선형 회귀(Bayesian Linear Regression, BLR) 헤드를 배치하는 구조입니다.

$$ f_t(x)=w_t^\top \phi_z(x) $$

• 공유 신경망: 여러 작업에 걸쳐 공통으로 적용되는 탐색 공간 표현(Search-space representation)을 학습합니다.
• 작업별 BLR 헤드: 각 작업의 고유한 스케일(Scale), 노이즈(Noise), 출력 관계를 전담합니다.
• BLR 가중치(Weight): 대수적 적분이 가능하므로, 예측 평균뿐만 아니라 획득 함수 계산에 필수적인 불확실성까지 함께 도출할 수 있습니다.

전통적인 MTGP가 작업 간 공분산을 직접 학습하는 방식이라면, 이 기법은 여러 작업에서 공통으로 유용하게 작용하는 입력 특징(input feature)이 무엇인가를 학습합니다. 계산 복잡도 역시 관측 데이터 수에 비례해 선형적으로 스케일링되며, 연구진은 기존 벤치마크 방법론 대비 최소 한 자릿수 이상 빠른 연산 속도를 보고했습니다.

이 논문에서 배운 점

첫째, 전이의 대상이 단순한 관측값이나 작업 간 상관관계에만 국한되지 않는다는 점입니다. 여러 캠페인에서 반복적으로 나타나는 비선형적 물리·화학 구조 자체를 '공유 표현' 형태로 학습할 수 있습니다.

둘째, 공유 표현(Shared representation)과 작업별 적응(Task-specific adaptation)을 분리하는 아키텍처는 실제 공정 환경에도 매우 자연스럽게 부합합니다. 예를 들어, 공유 네트워크는 도즈 × 사이클, 온도, 압력 간의 복잡한 상호작용을 학습하고, 작업별 헤드는 장비나 기판에 따른 고유한 바이어스를 흡수하는 형태로 설계할 수 있습니다.

셋째, 누적되는 과거 데이터의 규모가 커질수록, 모든 데이터를 단일 GP에 집어넣는 방식보다 확장성 측면에서 훨씬 유리합니다.

비판적으로 볼 부분

이 연구에서 다룬 실험 대상은 주로 머신러닝의 하이퍼파라미터 최적화(HPO)에 편향되어 있습니다. 이는 입력 변수의 의미가 작업마다 명확히 일치하고, 다수의 과거 작업과 방대한 관측치가 이미 확보된 환경입니다. 반면 실제 반도체 공정에서는 누적된 캠페인이 단 몇 개에 불과할 수 있으며, 변수의 정의 자체가 바뀔 수도 있습니다. 새로운 전구체 캠페인이 시작되면 기존에 없던 캐니스터 온도 같은 독립 변수가 추가되거나 할 수도 있습니다.

또한, 공유 표현 방식은 소스 작업의 수와 다양성이 충분하지 않으면 쉽게 과적합될 위험이 있습니다. 모델의 복잡도가 높은 만큼, 이것이 전이 학습의 실질적인 효과인지 아니면 단순히 모델 용량이 커지면서 얻을 수 있는 이점에서 온 것인지 구분하기 어렵다는 한계도 있습니다. 따라서 실제 공정 적용 시에는 타깃 데이터만 사용한 MLP 및 소스 데이터로 사전 학습을 거친 MLP 등과의 다각적인 비교 검증이 필수적입니다.

FSBO(Few-Shot Bayesian Optimization)는 이 아이디어를 딥 커널 GP(Deep Kernel GP)로 발전시켜 여러 작업에서 커널 표현을 메타 학습하고, 신규 작업에 대해 몇 번의 실험만으로 적응(Few-shot adaptation)하는 방식을 제안한 바 있습니다. [7] 그러나 Perrone 방식과 FSBO 모두 '비교 가능한 다수의 과거 작업이 존재한다'는 전제 조건이 충족될 때 강력한 성능을 발휘하는 방법론입니다. 만약 확보된 과거 캠페인 수가 너무 적다면, 오히려 더 단순한 형태의 GP 전이 방식이 안정적일 수 있습니다.

핵심 논문 2: Taylor et al. - 실제 화학 반응 캠페인 데이터도 전이할 수 있음을 증명했습니다

2023년 Taylor 등이 발표한 Accelerated Chemical Reaction Optimization Using Multi-Task Learning은 전이 베이지안 최적화(Transfer BO)를 실제 자동화 실험 환경에 적용하여 유효성을 입증한 대표적인 사례입니다. [8]

연구진은 먼저 스즈키-미야우라 결합(Suzuki–Miyaura coupling) 및 C–N 결합 반응 데이터를 활용해 컴퓨터 시뮬레이션 검증을 수행했습니다. 이어 자율 흐름 반응기(Autonomous flow reactor)를 구축하고, 기판 구조가 각기 다른 C–H 활성화 반응을 순차적으로 최적화했습니다. 첫 번째 반응은 단일 작업 BO로 최적화를 진행한 뒤, 후속 반응 최적화 시에는 이전 반응에서 확보한 데이터를 다중 작업 BO(MTBO)의 소스 작업으로 활용했습니다. 실제 실험 환경에는 연속형 변수와 범주형 변수가 복합적으로 포함되었습니다.

해당 연구는 학습 데이터에 존재하지 않았던 미지의 반응에서 최적 조건을 탐색하는 데 MTBO가 매우 유효함을 증명했으며, 산업 표준 공정 최적화 방식 대비 최대 98%의 비용 절감 가능성이 있음을 제시했습니다.

이 논문이 갖는 의미

이 연구는 단순히 "과거 작업들이 유사해 보인다"는 식의 소급적 벤치마크에 머물지 않았습니다. 실제 자율 흐름 반응기 장비와 신규 기판을 이용해 폐루프 최적화를 성공적으로 구현했다는 점에서, 반도체 공정 연구에 주는 시사점이 매우 큽니다.

화학 반응 연구와 반도체 공정 연구의 구성 요소를 대조하면 다음과 같습니다.

비판적으로 볼 부분

"최대 98% 절감"이라는 수치는 대단히 인상적이지만, 이를 모든 공정에 일반화할 수 있는 보편적 수치로 해석해서는 안 됩니다. 특정 반응군, 특정 비용 계산 모델, 그리고 비교 기준에 따라 산출된 최선의 시나리오이기 때문입니다. 아울러 활용된 소스 데이터가 타깃 최적화에 긍정적인 영향만 미친 매우 우호적인 조건이었다는 점도 감안해야 합니다.

또한, 실험 캠페인이 순차적으로 진행된 특성상, 초기 소스와 후속 타깃 사이의 어떤 유사성 요인이 실질적인 성능 향상을 이끌어냈는지 명확히 분리해내기 어렵습니다. 즉, 기판 디스크립터를 통한 일반화 덕분인지, 작업 인덱스를 기반으로 한 상관관계 학습의 결과인지, 혹은 단순히 최적 탐색 영역이 서로 유사했던 것인지에 대해서는 추가적인 소거 실험(ablation)이 필요합니다.

그럼에도 불구하고 이 연구는 전이 BO가 단순한 'HPO 벤치마크용 알고리즘'에 그치지 않고, 실제 물리적 실험 자원을 획기적으로 절감할 수 있는 실용적 도구임을 입증했다는 점에서 큰 의의가 있습니다.

핵심 논문 3: Chen et al. - 단순한 과거 데이터 재사용이 의외로 강력할 수 있습니다

2026년 7월 공개된 Chen 등의 프리프린트 Robust Transfer Learning for Bayesian Optimization of Chemical Reactions는 화학 반응 최적화에서의 탐색 공간 확장 문제를 정면으로 다룹니다. 이 연구는 새로운 기판, 리간드, 촉매 혹은 목적함수가 추가되는 상황에서 과거 캠페인 데이터를 어떻게 재활용하는 것이 최적인지를 다각도로 비교했습니다. [9]

이 논문에서 강조하는 핵심 결과는 크게 세 가지입니다.

첫째, 단순히 전이 전략 자체만 비교해서는 안 됩니다. 가우시안 프로세스(GP)의 하이퍼프라이어(Hyperprior)가 하위 표현 공간의 차원에 맞게 올바르게 설정되어 있는지에 따라 성능이 크게 좌우됩니다. 특히 고차원 잠재 공간의 분자 표현(Molecular representation)을 기존의 표준 GP 사전 분포와 결합할 경우, 표현력 자체의 문제라기보다는 부적절한 길이 스케일 사전 분포로 인해 성능이 저하될 수 있습니다.

둘째, 소스와 타깃 작업 간의 유사도가 충분히 높은 벤치마크 환경에서는 과거의 관측 데이터를 직접 결합하여 재사용하는 단순한 접근법이 의외로 뛰어난 성능을 보였습니다. 즉, 모든 상황에서 반드시 복잡한 전이 모델이 필요한 것은 아니었습니다.

셋째, 소스와 타깃 간의 차이가 커지는 스트레스 테스트 환경에서는 동일한 단순 재사용 방식이 오히려 부정적 전이(Negative transfer)를 유발했습니다. 이를 완화하기 위해 연구진은 탐색 초기에는 과거 관측 데이터를 적극 활용하다가, 타깃 데이터가 축적됨에 따라 작업 인지형 전이 체계로 전환하는 '2단계 프로토콜'을 제안했습니다. 저자들 역시 단 하나의 방법론이 모든 환경에서 완벽할 수는 없음을 인정하며, 소스-타깃 간 유사도를 미리 알 수 없을 때 이 2단계 방식을 실용적인 기본값으로 제시합니다.

반도체 공정 연구에 주는 시사점

초기부터 복잡한 다중 작업 GP(MTGP)를 구축하기보다, 다음과 같은 단계적·실용적 접근이 충분히 유효함을 시사합니다.

1. 초기 단계: 새로운 캠페인 시작 시 과거의 우수 레시피와 축적된 관측 데이터를 적극 활용하여 웜 스타트를 도모합니다.
2. 검증 단계: 몇 개의 타깃 관측 데이터와 공통 앵커 레시피를 통해 소스-타깃 간의 실제 연관성을 검증합니다.
3. 전환 단계: 연관성이 유효함이 확인되면 전이를 유지하고, 예상을 벗어나면 소스 데이터의 가중치를 낮추거나 타깃만 사용한 BO로 유연하게 전환합니다.

비판적으로 볼 부분

이 논문은 2026년 7월에 공개된 프리프린트 단계의 연구로, 아직 엄격한 동료평가를 거치지 않았습니다. 현재 제시된 성과는 대표적인 고속 스크리닝 반응 벤치마크와 인위적으로 설계된 스트레스 테스트 결과를 바탕으로 합니다. 따라서 실제 장비 드리프트, 측정 프로토콜의 변화, 데이터로 수집하지 않은 공정 실패 데이터, 그리고 안전 제약 조건까지 고려한 전향적 검증(Prospective validation) 과제가 남아있습니다.

또한 '초기'에서 '충분한 타깃 데이터 확보'로 넘어가는 전환 시점을 언제, 어떻게 자동화할 것인가도 중요한 당면 과제입니다. 단순히 고정된 반복 횟수를 기준으로 삼으면 작업의 특성에 따라 전환이 너무 빠르거나 늦어질 위험이 있습니다. 따라서 전환 기준은 타깃 예측 가능도, 순위 일치도, 사후 작업 유사도, 혹은 타깃만 적용한 모델 대비 후회도(Validation regret) 등 데이터에 기반한 엄밀한 지표로 설계되어야 합니다.

핵심 논문 4: Hvarfner et al. - MTGP는 단순한 문제에서도 실패할 수 있습니다

2026년 Hvarfner 등이 발표한 Pitfalls and Remedies for Multi-Task Bayesian Optimization은 전이 학습 기반 BO의 낙관론에 중요한 경종을 울리는 연구입니다. [10]

연구진은 소스와 타깃 작업이 아래와 같이 매우 단순한 아핀 관계(Affine relation)로 연결된 시나리오를 분석했습니다.

$$ f_s(x)=a f_t(x)+b+\epsilon $$

두 함수의 개형과 최적점의 순서가 사실상 동일하기 때문에, 상식적으로는 전이 학습이 무조건 성공해야 할 것처럼 보입니다. 그러나 교과서적인 기존 다중 작업 GP(MTGP)는 서로 다른 작업 간 상관관계를 제대로 추정하지 못했으며, 소스 작업이 여러 개일 때는 상관관계의 부호조차 잘못 판단하는 오류를 범했습니다. 그 결과 다수의 벤치마크에서 타깃만 사용한 GP보다도 성능이 떨어지는 심각한 부정적 전이가 관측되었습니다.

논문은 이러한 현상의 구조적 원인으로 다음 두 가지를 지적합니다.

1. 작업별 표준화 오차: 수집된 데이터가 부족한 상태에서 각 작업의 평균과 표준편차를 추정할 때 발생하는 오차가 작업 간 상관관계 추정의 실패로 그대로 전파됩니다.
2. 상관관계 식별 가능성 문제: 소스와 타깃 데이터가 서로 다른 입력 위치($x$)에서 측정되었다면, 표본 수가 적은 초기 단계에서 두 함수 간의 실질적인 상관관계를 수학적으로 정확히 식별해내기 어렵습니다.

연구진은 이를 해결하기 위한 세 가지 보완책을 제안했습니다.

• 작업별 평균과 스케일을 전처리 단계의 고정 상수가 아닌, 모델 내부에서 함께 최적화할 파라미터로 학습합니다.
• 작업 간 상관관계가 음의 방향으로 잘못 학습되지 않도록 그 값이 음수가 아니어야 한다는 제약 조건을 부여합니다.
• 소스와 타깃 작업 모두에서 일부 동일한 입력 조건 $x$를 공유하여 평가하는 '공동 배치 설계(Co-located design)'를 도입합니다.

특히 세 번째 제안인 공동 배치 설계는 반도체 공정 연구에 매우 중요한 시사점을 던집니다. 서로 다른 캠페인을 진행하더라도 기준이 되는 동일한 표준 레시피(reference recipe)를 반복 측정해두면, 모델이 두 캠페인의 유사성을 막연히 추측하는 대신 명확한 정량적 기준을 바탕으로 직접 비교할 수 있게 되기 때문입니다.

이 논문의 결론을 과장 해석해서는 안 됩니다

연구진이 제안한 세 가지 보완책이 모든 한계를 완벽히 해결하는 것은 아닙니다. 구조가 단순한 아핀 관계의 예제에서는 타깃 전용 모델 수준으로 성능을 회복했으나, 복잡하고 난해한 문제 구조에서는 여전히 실패 케이스가 관측되었습니다. 또한 실제 물리적 실험을 통한 검증이 다소 제한적이라는 아쉬움도 있습니다. 즉, 이 논문의 진정한 기여는 완전무결한 해결책을 제시했다는 점보다, 기존 MTGP가 안고 있던 고유의 구조적 결함을 명확히 분리하여 증명했다는 데 있습니다.

따라서 이를 "다중 작업 GP는 실효성이 없다"는 결론으로 확대해석해서는 곤란합니다. 우리가 얻어야 할 정확한 교훈은 다음과 같습니다.

"다중 작업 GP를 맹목적인 기본 모델로 채택하기에 앞서, 반드시 타깃만 사용하는 BO(Target-only BO)를 대조군으로 두어야 하며, 작업 간 상관관계를 엄밀히 식별할 수 있는 유기적인 실험 설계가 선행되어야 합니다."

네 논문을 함께 읽으면 보이는 것

이 네 편의 연구는 서로 모순된다기보다, 전이 베이지안 최적화(Transfer BO) 방법론이 학술적·실용적으로 성숙해가는 발전 패러다임을 보여줍니다.

1. 과거 작업을 연계하여 함께 모델링하면 초기 탐색 단계(콜드 스타트)의 시행착오를 유의미하게 줄일 수 있습니다.
2. 비교 대상이 되는 작업의 수가 많아질수록, 작업 간 상관관계 행렬을 직접 구하는 것보다 공유 표현을 학습하는 것이 계산 확장성 측면에서 유리합니다.
3. 시뮬레이션에만 머물지 않고 실제 물리적 실험에 적용했을 때도 전이 학습은 획기적인 비용 절감으로 이어질 수 있습니다.
4. 그러나 작업 간 유사도를 잘못 추정할 경우, 구조가 단순한 문제에서조차 타깃만으로 수행한 BO보다 성능이 저하되는 부작용이 발생합니다.

이를 통해 도출할 수 있는 가장 중요한 핵심 통찰(Lessons Learned) 다섯 가지를 다음과 같이 정리해 보았습니다.

1. 작업 간 유사도(Task similarity)는 가정이 아니라 정량적 추정 대상입니다

"같은 장비니까 비슷할 것이다", "동일한 전구체를 사용하니까 전이가 가능할 것이다"라는 도메인 직관에만 의존하는 설명은 위험합니다. 공통 앵커 레시피(Anchor recipe)에서의 반응성, 우수 레시피 상위 K개의 중복도, 순위 상관계수, 그리고 국소적 바이어스 등을 실증적 데이터로 직접 측정하고 검증해야 합니다.

2. 명확한 대조군으로서의 단순한 베이스라인이 반드시 필요합니다

복잡하고 정교한 전이 모델(Transfer model)을 도입할 때는 반드시 아래의 비교 대조군들과의 성능 평가가 선행되어야 합니다.

• 타깃만 사용한 GP: 전이 학습 없이 타깃 데이터만으로 학습한 기본 모델
• 무작위/균일 탐색(소볼 시퀀스 또는 무작위 탐색): 모델 기반 최적화 자체의 유효성을 검증할 기준점
• 사전 지식 기반 시작(웜 스타트): 과거의 우수 레시피 조건만을 초기 탐색점으로 활용하는 단순 방식
• 단순 데이터 결합(Naive pooling): 과거의 모든 관측 데이터를 구분 없이 하나로 합쳐 학습하는 방식
• 소스 모델 앙상블: 개별 소스 모델들의 예측을 가중 평균하는 방식

만약 단순 데이터 결합(Naive pooling)만으로도 충분한 성과가 나온다면, 복잡한 다중 작업 GP(MTGP)를 도입함에 따른 추가적인 계산 부하와 구현 복잡도는 정당화되기 어렵습니다. 반대로 단순 결합 방식이 실패(Negative transfer)하는 지점에서야 비로소 작업 인지형 모델(Task-aware model)의 진가와 필요성이 명확히 입증됩니다.

3. 단순한 예측 정확도보다 최적화 성능(Optimization outcome)을 정량화해야 합니다

모델의 예측 오차(RMSE)나 신뢰도(Calibration) 지표가 우수하다고 해서 최적화가 반드시 성공하는 것은 아닙니다. 전이 모델의 실질적인 가치를 판단하기 위해서는 최종 단순 후회도(Simple regret), 비용을 고려한 상시 후회도(Cost-normalized anytime regret), 상위 K개 후보 물질/레시피 발견율(Top-K discovery rate), 공정 제약 조건 위반 빈도(Constraint violation frequency), 그리고 부정적 전이 발생 빈도(Negative-transfer frequency) 등을 다각도로 평가해야 합니다.

예를 들어, 전이 학습을 통한 실질적인 이득인 전이 이득(Transfer gain)은 특정 실험 자원(Budget) $B$ 시점에서 다음과 같이 정의할 수 있습니다.

$$ G(B)=R_{\text{target-only}}(B)-R_{\text{transfer}}(B) $$

동일한 타깃 실험 자원 $B$를 소모했을 때 $G(B)>0$이면 긍정적 전이(Positive transfer)가 일어난 것이고, $G(B)<0$이면 부정적 전이(Negative transfer)가 발생한 것입니다. 연구 검증 시에는 단순히 평균 전이 이득(Mean gain)만을 제시하는 것에 그치지 않고, 실제 몇 퍼센트의 캠페인 평가 환경에서 부정적 전이가 발생했는지(Negative transfer risk)를 반드시 함께 보고하여 안정성을 검증해야 합니다.

4. 모델 아키텍처와 표현 공간의 효과를 분리하여 검증해야 합니다

고차원의 임베딩 표현 공간을 활용하면서 가우시안 프로세스의 길이 스케일 사전 분포를 기존 설정 그대로 유지하면, 모델과 표현 공간 간의 불일치로 인해 성능이 저하될 수 있습니다. 반대로 공유 신경망 기반 전이 모델의 성능이 우수하게 나타나더라도, 이것이 실제 '전이 학습의 효과' 때문인지 아니면 단순히 MLP 모델 자체가 갖는 표현의 유연성 때문인지 명확히 구분해야 합니다.

따라서 방법론의 유효성을 완벽히 입증하기 위해서는 최소한 아래와 같은 $2 \times 2$ 교차 비교 검증 프레임워크를 갖추어야 합니다.

5. 실효성 있는 전이 성능은 정교한 데이터 거버넌스에서 시작됩니다

단순히 데이터에 캠페인 ID(또는 작업 인덱스) 레이블만 부여한다고 해서 자동으로 다중 작업 학습이 이루어지는 것은 아닙니다. 데이터 간의 실질적인 인과관계를 학습하기 위해서는 다음과 같은 메타데이터가 일관되고 표준화된 형태로 관리되어야 합니다.

• 장비 및 챔버 ID
• 기판 종류 및 하부막 정보
• 전구체 및 소스 물질의 랏 번호
• 공정 레시피 파라미터의 명확한 정의와 표준 단위
• 해당 캠페인에서 고정한 레시피 상수 목록
• 계측 방법론 및 계측 장비 정보
• 공정 진행 날짜, 랏 정보 및 장비 유지보수(PM) 상태
• 공정 실패, 중단 및 중간에 생략된 데이터
• 목적함수(Objective) 및 제약 조건(Constraint) 정의의 버전 번호

이러한 메타데이터 인프라가 뒷받침되지 않으면, 모델은 실제 공정의 물리·화학적 특성 변화와 단순한 측정 프로토콜의 차이(Systematic bias)를 구분하지 못해 전이 학습의 신뢰성이 무너지게 됩니다.

어떤 연구 설계를 추천할까

반도체 공정 전이 베이지안 최적화 연구를 시작할 때, 처음부터 가장 복잡한 메타 학습 모델을 채택하는 것은 바람직하지 않습니다. 그보다는 아래와 같이 단계적으로 비교 대조군을 확장해 나가는 연구 설계가 방법론의 해석 가능성을 높이고, 논문으로서의 논리적 설득력을 확보하는 데 훨씬 유리합니다.

1단계: 공통 탐색 공간과 캠페인 단위를 정의합니다

가장 먼저 최적화의 대상이 되는 개별 '작업'의 경계를 명확히 획득해야 합니다.

반도체 공정 특성을 고려할 때, 다음 중 하나를 캠페인 단위로 설정하는 것이 자연스럽습니다.

• 소재(material) × 전구체(precursor) × 기판(substrate) 조합
• 장비(tool) × 챔버(chamber) × 박막 구조(material stack) 조합
• 제품 세대(product generation) × 공정 모듈(process module) 조합
• 조각 샘플(coupon) / 파일럿(pilot) / 양산(production) 스케일 다원화

이때 직접 최적화(튜닝)하지는 않지만 캠페인의 특성을 설명해 주는 변수들은 레시피 파라미터가 아니라 콘텍스트 변수 또는 레시피 상수(recipe constants)로 분리하여 저장해야 합니다. 만약 작업 특성에 해당하는 고정된 값(task descriptor)과 조절 가능한 파라미터를 입력단에서 구분 없이 섞어버리면, 획득 함수가 엔지니어가 실제로 변경할 수 없는 고정 변수를 추천하는 치명적인 오류가 발생합니다.

2단계: 앵커 레시피(anchor recipe)를 설계합니다

각 캠페인의 초기 실험 자원(budget) 중 일정 비율을 반드시 공통 레퍼런스 레시피인 '앵커 레시피' 측정에 배정합니다. 모든 소스-타깃 작업 쌍에서 완전히 동일한 레시피 적용이 불가능하다면, 공통 파라미터 하위 공간(subspace) 내에서 수학적으로 가장 가까운 조건을 선택합니다.

앵커 레시피의 목적은 최적의 조건을 발굴하는 것이 아니라, 다음 항목들을 사전에 정량적으로 식별하는 데 있습니다.

• 출력값의 오프셋 및 스케일 변화량
• 최적 경향성의 순위가 역전되는 현상 여부
• 공정 노이즈 및 재현성의 변화
• 챔버 간 편차(chamber bias) 또는 계측 장비 간 편차(metrology bias)

실험 설계 시 앵커 레시피의 배정 비율을 고정하기보다는, 배정 비율 변화에 따른 전이 효율의 민감도 분석을 함께 수행하는 것이 좋습니다.

3단계: 베이스라인 사다리(baseline ladder)를 구성합니다

방법론의 점진적인 우월성을 입증하기 위해 다음과 같이 체계적인 비교 대조군 체계를 구축합니다.

특히 MTGP(B4) 단계에서는 앞서 검토한 Hvarfner 논문의 보완책들을 반영한 변형 모델을 포함해야 합니다. 즉, 작업별 평균·스케일을 동적으로 학습하고, 양의 상관관계만으로 제약을 하면서 앵커 디자인의 유무에 따른 효과를 소거 실험(ablation study)으로 명확히 분리해야 합니다.

4단계: '하나의 캠페인을 제외시키는' 교차 검증(leave-one-campaign-out)으로 평가합니다

확보된 캠페인 중 하나를 타깃 작업으로 남겨두고, 나머지를 모두 과거 소스 데이터로 활용하는 교차 검증을 수행합니다. 이때 타깃 작업의 전체 데이터를 모델 선택이나 하이퍼파라미터 튜닝에 미리 개입시키면 데이터 누출이 발생하므로 주의해야 합니다. 철저히 실제 시간 흐름에 맞춰 BO 궤적을 순차적으로 재생하거나 전향적 실험 환경을 모사해야 합니다.

평가는 다양한 난수 시드와 서로 다른 타깃 캠페인 조합에 대해 반복 실행하며, 다음 지표들을 종합적으로 평가합니다.

• 비용 고려 상시 후회도 (cost-normalized anytime regret)
• 최종 단순 후회도 (final simple regret)
• 상위 K개 우수 레시피 발견율 (top-K recipe discovery rate)
• 목표 스펙 달성까지 소요된 총 웨이퍼 수
• 공정 제약 조건 위반 횟수
• 부정적 전이 발생률
• 모델 피팅 및 다음 후보 추천에 소요된 연산 시간

실제 반도체 현업에서는 단일 목적함수 최적화보다는 안전 마진 확보와 다중 스펙 충족이 최우선이므로, 제약 조건이 포함된 다목적 최적화 환경에서의 평가를 필수적으로 포함해야 합니다.

5단계: 전이 학습 거부 메커니즘(Transfer gating)을 장착합니다

가장 안전하고 강건한 전이 최적화 시스템은 '언제나 전이를 수행하는 시스템'이 아니라, '전이를 거부할 줄 아는 시스템'입니다. 소스 데이터의 증거가 부족하거나 소스-타깃 간의 경향성이 명백히 어긋날 경우, 시스템이 스스로 전이를 차단하고 타깃만 사용하는 BO(Target-only BO)로 안전하게 회귀할 수 있어야 합니다.

이를 제어하기 위해 활용 가능한 게이팅 신호는 다음과 같습니다.

• 앵커 레시피 상에서의 순위 일치도 (rank agreement)
• 타깃 검증 데이터에 대한 모델의 예측 가능도 (holdout predictive likelihood)
• 소스 모델이 예측한 타깃 데이터의 순위 손실 (target ranking loss)
• 사후 작업 상관관계(posterior task correlation) 추정치의 신뢰구간
• 타깃 전용 모델과 전이 모델 간의 획득 함수 불일치도 (acquisition disagreement)

결과적으로 최적화 초기에는 과거 소스 데이터의 가이드에 의존하되, 타깃 공정의 실증 데이터가 축적될수록 소스 데이터의 가중치를 엄밀하게 재평가하여 감쇠시키는 방식이 실무 및 양산 관점에서 가장 타당한 엔지니어링 접근법입니다.

상황별로 어떤 방법이 적절할까

반도체 공정 분야에서 전이 BO의 첫 번째 연구 주제로 추천하는 핵심 비교 조합은 다음과 같습니다.

"앵커 디자인을 포함한 타깃 전용 GP, 단순 데이터 결합, 보완된 MTGP, RGPE, 그리고 2단계 적응형 전이의 다각적 비교"

이 조합은 과거 누적 캠페인 수가 많지 않은 초기 단계에서도 즉시 적용 가능하며, 전이의 성공 및 실패 원인을 명확하게 해석할 수 있다는 장점이 있습니다. 공유 신경망 표현(shared neural representation) 방식은 향후 공정 캠페인과 데이터가 충분히 축적된 후속 연구 단계로 배치하는 것이 현실적입니다.

앞으로 해결해야 할 핵심 과제

1. 이종 탐색 공간(heterogeneous search space)

실제 현업의 공정 개발 캠페인은 파라미터 집합이 완벽히 일치하지 않습니다. 특정 캠페인에는 플라즈마 파워가 독립 변수로 존재하지만 다른 캠페인에는 없을 수 있으며, 파라미터의 범위와 변경 단위도 달라질 수 있습니다. 기존 전이 BO 연구의 상당수는 모든 작업이 동일한 도메인을 공유한다고 가정하는 한계가 있습니다.

최근 이종 탐색 공간을 위한 사전 학습 기반 계층적 GP 등의 연구가 등장하고 있지만, 실제 반도체 공정에서의 실증 검증은 여전히 미흡한 실정입니다. [11] 공통 파라미터, 작업 고유 파라미터, 조건부 파라미터를 유연하게 아우르는 종합 모델 아키텍처가 필요합니다.

2. 시간에 따른 장비 및 공정의 변화

동일한 챔버라 할지라도 유지보수(PM), 시즈닝(seasoning) 상태, 전구체 랏 교체, 센서 보정 등에 의해 공정 특성은 시간에 따라 계속 변화(drift)합니다. 작업을 고정된 ID로만 취급하면 이러한 시간 축의 변화를 놓치게 됩니다. 따라서 캠페인 간 전이 기법과 실시간 변화점 감지(online change-point detection) 알고리즘을 유기적으로 결합시켜야 합니다.

3. 목적함수 및 제약 조건의 동적 변화

공정 개발 초기 단계에서는 증착률이 최우선 목표였다가, 양산화 단계로 넘어가면 균일도와 결함 밀도가 더 핵심적인 지표가 되기도 합니다. 또한 과거 데이터에는 일부 결과 항목이 누락되어 있을 수 있습니다. 따라서 서로 다른 목적함수 세트와 누락된 평가 결과를 유연하게 처리할 수 있는 전이 다목적 BO(Transfer Multi-Objective BO) 프레임워크가 필요합니다.

4. 안전 제약 조건에서의 부정적 전이 위험성

과거 공정 캠페인에서 안전했던 영역이 새로운 화학 반응이나 신규 챔버 조건에서도 안전하다는 보장은 없습니다. 목적함수 대리 모델은 과거 데이터를 전이받더라도, 안전 제약 조건 모델은 타깃 공정의 실증 데이터가 충분히 확보될 때까지 매우 보수적이고 독립적으로 운영하는 안전 분리 설계가 필수적입니다.

5. 도메인 지식과 전이 학습의 결합

반도체 공정은 속을 전혀 알 수 없는 블랙박스가 아닙니다. ALD의 포화 특성, 아레니우스 반응속도론, 질량 보존 법칙, 플라즈마 밀도-파워 상관관계 등 확립된 물리·화학적 지식이 존재합니다. 이러한 지식을 평균 함수, 커널, 단조성 제약(monotonic constraint) 또는 엔지니어링된 특징(engineered feature) 형태로 모델에 주입할 수 있습니다.

이 경우 전이 모델은 단순히 "모든 작업이 동일한 함수를 따른다"는 전제보다, "공통의 물리 법칙 기반 위에 작업별 고유한 잔차(residual)가 존재한다"는 형태의 모델링이 훨씬 자연스럽고 정교합니다.

$$ f_t(x)=f_{\text{shared physics}}(x)+\delta_t(x) $$

6. 최적화 실행 전 유사도 추정의 불확실성

현재 공개된 다수의 벤치마크 연구들은 최적화가 완료된 후 사후적으로 어떤 작업들이 유사했는지를 설명하는 구조를 취합니다. 그러나 실제 실시간 BO를 수행하는 시점에서는 이를 미리 알 수 없습니다. 극소량의 초기 타깃 데이터만으로 전이 가능성의 여부를 정확히 추정하고, 확신이 서지 않을 때는 전이를 거부(calibrated gating)할 수 있는 알고리즘이 핵심적인 연구 과제입니다.

7. 재현 가능한 반도체 공정 표준 벤치마크 구축

머신러닝 하이퍼파라미터 최적화(HPO) 분야에는 다양한 작업 간 성능을 비교할 수 있는 표준 벤치마크가 잘 갖추어져 있지만, 반도체 공정 분야는 보안상의 이유로 서로 다른 캠페인이 모여 있는 데이터셋이 거의 전무합니다. 표준화된 파라미터 스키마, 캠페인 메타데이터, 실패한 실험, 비용 데이터, 제약 조건까지 체계적으로 포함된 공용 벤치마크 구축이 시급합니다.

실제 양산 데이터의 공개가 어렵다면, 물리 기반 디지털 트윈과 보안 처리된 익명화 실측 데이터(experimental trace)를 결합한 준합성(semi-synthetic) 벤치마크 구축이 현실적인 대안이 될 것입니다.

결론: 전이 BO의 본질은 무조건적인 기억이 아니라 정교한 검증입니다

반도체 공정 개발에서 베이지안 최적화는 막대한 비용과 시간이 소요되는 실험을 획기적으로 줄여주는 유용한 도구입니다. 하지만 매 캠페인을 독립적인 문제로 취급한다면, 이전의 소중한 실험을 통해 축적된 지식과 통찰은 매번 손실되고 맙니다. 전이 학습은 이러한 단절을 메워주며, BO를 일회성 단발 최적화 도구에서 지속적으로 진화하고 학습하는 지능형 공정 개발 시스템으로 확장시킬 수 있는 핵심 열쇠입니다.

전이 BO 연구의 흐름을 되짚어보면 다음과 같습니다. 초기 연구는 다중 작업 GP(MTGP)를 통해 작업 간 상관관계를 학습하는 데서 출발했습니다. Perrone 등은 다수의 작업이 공유하는 표현 공간을 학습함으로써 계산 확장성을 대폭 끌어올렸습니다. Taylor 등은 실제 화학 반응 자율 최적화 장비에서 서로 다른 캠페인 간 전이의 뛰어난 실용성을 입증해 냈습니다. Chen 등은 단순한 과거 데이터 결합과 2단계 적응형 전이의 현실적인 유용성을 제시했으며, Hvarfner 등은 기존 MTGP가 단순한 조건에서도 상관관계를 오판하여 부정적 전이를 일으킬 수 있음을 경고했습니다.

이 모든 흐름을 관통하는 단 하나의 결론은 다음과 같습니다.

"과거 데이터를 얼마나 많이 집어넣느냐보다 중요한 것은, 그 데이터가 현재 진행 중인 타깃 캠페인에 실제로 도움이 되는지 실증적으로 검증하고, 위험할 때는 전이를 즉시 중단할 수 있는 통제력을 갖추는 것입니다."

따라서 반도체 공정 전이 BO 연구를 시작할 때, 가장 복잡한 신경망 대리 모델부터 구축할 필요는 전혀 없습니다. 공통 앵커 레시피를 정교하게 설계하고, 확실한 대조군으로서 타깃 전용 베이스라인을 유지하며, 단순 데이터 결합부터 보완된 MTGP, 그리고 적응형 전이 기법에 이르기까지 일관된 조건에서 단계적으로 검증해 나가는 것이 올바른 길입니다.

뛰어난 전이 BO 시스템은 모든 과거 데이터를 맹목적으로 기억하는 모델이 아닙니다. 어떤 과거 지식을 신뢰해야 하는지, 타깃 공정의 실증 데이터를 통해 스스로 검증해내는 모델입니다.

주요 참고문헌

신뢰성을 확보하기 위해 동료평가를 거친 저명 학회·저널 논문과 공식 원문을 우선적인 출처로 삼았습니다. 심사 완료 전의 자료는 최신 주요 이슈를 다룬 경우에만 예외적으로 포함 시켰으며, 이 경우 preprint 표시를 명확히 부착했습니다. 해당 데이터들은 확정된 결론이 아니라, 향후 추가 검증이 필요한 참고 근거로 해석하여 반영했습니다.

1. Zhang et al., Bayesian Optimization for Controlled Chemical Vapor Deposition Growth of WS₂, ACS Applied Materials & Interfaces, 2024. 원문
2. Shrivastava et al., Bayesian Optimization for Stable Properties amid Processing Fluctuations in Sputter Deposition, Journal of Vacuum Science & Technology A, 2024. 원문
3. Bai et al., Transfer Learning for Bayesian Optimization: A Survey, arXiv preprint, 2023. 원문
4. Swersky, Snoek, Adams, Multi-Task Bayesian Optimization, NeurIPS, 2013. 원문
5. Tighineanu et al., Transfer Learning with Gaussian Processes for Bayesian Optimization, AISTATS, 2022. 원문
6. Perrone et al., Scalable Hyperparameter Transfer Learning, NeurIPS, 2018. 원문
7. Wistuba, Grabocka, Few-Shot Bayesian Optimization with Deep Kernel Surrogates, ICLR, 2021. 원문
8. Taylor et al., Accelerated Chemical Reaction Optimization Using Multi-Task Learning, ACS Central Science, 2023. 원문
9. Chen et al., Robust Transfer Learning for Bayesian Optimization of Chemical Reactions, ChemRxiv preprint, 2026. 원문
10. Hvarfner et al., Pitfalls and Remedies for Multi-Task Bayesian Optimization, arXiv preprint, 2026. 원문
11. Fan, Han, Wang, Transfer Learning for Bayesian Optimization on Heterogeneous Search Spaces, TMLR, 2024. 원문

TencentDB Agent Memory의 Team Memory가 보여주는 에이전트 메모리의 다음 단계

AI 에이전트를 오래 사용하다 보면 비슷한 장면을 반복해서 만나게 됩니다. 지난 세션에서 이미 설명한 프로젝트 배경을 다시 알려줘야 하고, 다른 에이전트는 같은 문서를 처음부터 다시 읽습니다. 어렵게 정리한 작업 절차도 새 대화를 열면 사라져 버립니다.

모델은 분명 더 똑똑해졌는데, 함께 일하는 방식은 매번 새로 입사한 사람을 다시 교육하는 것과 크게 다르지 않습니다. (영화 메멘토와 비슷한다고 하는 사람도 있고, “기억 상실증에 걸린 아인슈타인과 일하는 것”에 비유하는 사람도 있습니다.)

이 문제를 해결하기 위해 지금까지의 에이전트 메모리는 주로 한 사용자와 한 에이전트 사이의 연속성에 초점을 맞춰 왔습니다. 사용자의 선호를 기억하고, 과거 대화를 요약하고, 관련 기록을 검색해 다음 세션에 제공하는 방식입니다.

그런데 에이전트가 개인용 도구를 넘어 팀의 업무에 들어오기 시작하면 문제가 달라집니다. 한 사람이 에이전트와 함께 발견한 지식과 성공한 작업 방식은 다른 사람과 다른 에이전트도 재사용할 수 있어야 합니다. 동시에 사적인 정보는 노출되지 않아야 하고, 오래된 절차는 최신 버전과 구분돼야 하며, 누가 만든 정보인지도 추적할 수 있어야 합니다.

그림 1. TencentDB Agent Memory의 Memory Hub. 기억 자산의 소유권과 상태를 확인하고, 팀과 에이전트별로 자산을 공유·배정하는 관리 화면. 출처: TencentDB Agent Memory GitHub.

텐센트가 2026년 8월 6일 공개한 TencentDB Agent Memory의 Team Memory가 흥미로운 이유가 여기에 있습니다. 이 프로젝트의 목표는 단순히 대화를 더 오래 기억하는 것이 아닙니다. 대화와 작업 과정에서 생긴 경험을 검토하고, 관리하고, 권한을 부여하고, 여러 에이전트가 재사용할 수 있는 조직의 기억 자산으로 바꾸려는 시도입니다.

• GitHub 저장소
• 공식 발표

긴 컨텍스트가 곧 메모리는 아닙니다

에이전트에게 메모리가 필요한 이유를 흔히 컨텍스트 윈도의 한계에서 찾습니다. 그러나 컨텍스트가 길어져도 메모리 문제는 사라지지 않습니다.

첫째, 긴 컨텍스트는 현재 요청에 넣을 수 있는 정보의 양을 늘릴 뿐, 다음 세션까지 무엇을 남길지 자동으로 결정해 주지 않습니다.

둘째, 과거 대화와 도구 실행 기록을 매번 통째로 넣으면 비용과 지연이 커집니다. 정보가 많아질수록 중요한 사실이 수많은 중간 결과와 잡음 속에 묻힐 가능성도 높아집니다.

셋째, 기억은 시간이 흐르면서 변합니다. 사용자의 선호가 바뀔 수도 있고, 프로젝트의 결정이 번복될 수도 있으며, 어제의 작업 절차가 오늘은 폐기됐을 수도 있습니다. 단순 저장만으로는 이런 변화를 다룰 수 없습니다.

따라서 에이전트 메모리에는 적어도 다음과 같은 생명주기가 필요합니다.

1. 기록하기: 무엇을 장기 기억으로 남길지 판단합니다.
2. 정리하기: 원본에서 사실, 선호, 결정, 절차를 추출하고 압축합니다.
3. 찾아오기: 현재 작업에 필요한 기억만 검색합니다.
4. 검증하기: 기억의 출처와 최신성을 확인합니다.
5. 고치고 잊기: 틀리거나 낡은 기억을 수정·감쇠·삭제합니다.

즉, 메모리는 저장소 하나가 아니라 write → organize → retrieve → verify → revise로 이어지는 운영 체계입니다.

개인 메모리와 팀 메모리는 무엇이 다를까요?

개인 메모리의 핵심 질문은 비교적 분명합니다.

이 사용자의 선호와 과거 대화, 작업 맥락 중 무엇을 기억해야 하는가?

그러나 같은 기억을 여러 사람과 여러 에이전트가 사용하기 시작하면 새로운 질문이 한꺼번에 생깁니다.

개인 메모리가 주로 회상(recall)의 문제라면, 팀 메모리는 회상에 지식 관리와 거버넌스가 더해진 문제라고 할 수 있습니다.

이 차이는 생각보다 큽니다. 개인에게만 쓰이는 잘못된 기억은 한 사람의 결과를 망칠 수 있지만, 팀의 표준 Skill로 승격된 잘못된 기억은 수십 개 에이전트의 행동을 동시에 오염시킬 수 있습니다. 팀 메모리에서는 기억의 재사용성이 높아지는 만큼 오류의 확산성도 함께 커집니다.

기존 에이전트 메모리는 어떻게 발전해 왔을까요?

에이전트의 망각 문제를 해결하기 위한 접근은 이미 여러 갈래로 발전해 왔습니다.

가장 단순한 방법은 전체 대화나 최근 대화를 프롬프트에 다시 넣는 것입니다. 구현은 쉽지만 대화가 길어질수록 비용이 증가하고, 현재 작업과 무관한 정보까지 함께 들어옵니다.

그다음은 MEMORY.md 같은 파일이나 대화 요약을 지속적으로 갱신하는 방식입니다. 사람이 읽고 고치기 쉽다는 장점이 있지만, 무엇을 기록하고 언제 갱신할지를 에이전트의 판단에 많이 의존합니다. 요약 과정에서 중요한 세부 정보가 빠질 수도 있습니다.

임베딩과 벡터 데이터베이스를 사용하는 RAG 방식은 과거 기록을 외부 저장소에 두고 현재 질문과 관련된 부분만 검색합니다. 규모 확장에는 유리하지만, 의미적으로 비슷하다는 이유만으로 낡거나 잘못된 기억이 검색될 수 있고, 시간·버전·충돌 관계를 별도로 다뤄야 합니다.

이후에는 보다 적극적으로 기억을 관리하는 시스템들이 등장했습니다.

• MemGPT는 운영체제가 메모리 계층을 관리하듯, 제한된 컨텍스트와 외부 기억 사이에서 정보를 이동시키는 관점을 제시했습니다.
• Mem0는 대화에서 중요한 사실을 추출하고 기존 기억과 비교해 추가·갱신·삭제하는 방식에 초점을 맞췄습니다.
• Zep과 Graphiti는 시간에 따라 변하는 사실과 관계를 지식 그래프로 관리하는 접근을 발전시켰습니다.
• 개발 에이전트 생태계에서는 MEMORY.md, Skill, 프로젝트 Wiki, 코드 인덱스와 호출 그래프를 별도의 장기 자산으로 사용하는 방식도 널리 쓰이기 시작했습니다.

이러한 접근은 에이전트 메모리를 단순한 대화 로그에서 구조화된 장기 기억으로 발전시켰습니다. 다만 대부분의 출발점은 여전히 “한 에이전트가 무엇을 기억하고 어떻게 검색할 것인가”였습니다.

TencentDB Agent Memory의 Team Memory는 여기서 질문을 한 단계 넓힙니다.

한 사람과 한 에이전트가 만든 기억을 어떻게 팀이 관리하고, 안전하게 공유하고, 역할이 다른 에이전트에게 배분할 것인가?

대화를 네 계층의 기억으로 증류합니다

그림 2. 대화를 기억으로 증류하고 다시 원본 근거로 내려가는 L0–L3 계층 구조. 평소에는 L2·L3로 작업 맥락을 복원하고, 정확한 사실이나 출처가 필요하면 L1·L0를 검색합니다. (출처: TenCentDB Agent Memory 문서를 바탕으로 재구성)

TencentDB Agent Memory의 개인 메모리 엔진은 대화를 네 계층으로 나눠 관리합니다.

대화는 먼저 L0에 저장되고, 비동기 파이프라인이 이를 더 높은 계층의 기억으로 증류합니다. 평소에는 L2와 L3를 이용해 전체 맥락을 빠르게 복원하고, 정확한 사실이나 근거가 필요할 때 L1과 L0로 내려갑니다.

이 구조에서 중요한 점은 요약된 기억만 남기지 않는다는 것입니다. 압축된 기억에서 원본 대화까지 거슬러 올라갈 수 있어야 “에이전트가 왜 이렇게 기억하고 있는가”를 확인할 수 있습니다. 메모리의 추적 가능성은 개인화 품질뿐 아니라 팀 환경에서의 감사와 오류 수정에도 필요합니다.

검색은 BM25·벡터 검색·RRF를 함께 사용합니다

구체적인 기억을 찾을 때는 단순한 벡터 유사도 하나에 의존하지 않습니다. L1과 L0 검색에 BM25와 벡터 검색을 함께 사용하고, 두 결과를 RRF(Reciprocal Rank Fusion)로 결합합니다.

이 설계는 꽤 현실적입니다. 에이전트 메모리에는 제품명, 오류 코드, 사람 이름, 숫자와 같은 정확한 문자열도 많고, 표현은 다르지만 의미가 같은 과거 경험도 많습니다. BM25는 전자에 강하고 벡터 검색은 후자에 강합니다. RRF는 서로 다른 검색 결과의 순위를 비교적 단순하고 안정적으로 합칠 수 있습니다.

검색 결과에는 항목 수, 문자 수, 처리 시간 제한도 적용합니다. 관련 기억을 많이 찾는 것보다, 현재 컨텍스트가 감당할 수 있는 범위에서 필요한 기억만 가져오는 것이 중요하기 때문입니다.

기본 저장 백엔드로는 로컬 SQLite와 sqlite-vec를 사용할 수 있고 Tencent Cloud VectorDB도 선택할 수 있습니다. 로컬 환경에서 구조를 직접 살펴보고 실험할 수 있다는 점은 초기 개발자 반응에서 자주 언급되는 장점 가운데 하나입니다.

사용자가 이미 구축한 BM25/Vector + RRF + reranker 기반 RAG와 비교하면 검색 철학은 상당히 가깝습니다. 핵심적인 차이는 검색기 자체보다 그 위에 있습니다. 일반적인 RAG가 “관련 정보를 어떻게 찾을 것인가”에 집중한다면, 이 시스템은 “어떤 경험을 기억으로 만들고, 어느 수준으로 압축하며, 누가 사용할 수 있게 할 것인가”까지 함께 다룹니다.

Team Memory의 핵심: 기억을 네 종류의 자산으로 바꿉니다

Team Memory는 기억의 범위를 대화 밖으로 확장하고, 네 종류의 Memory Asset을 하나의 관리 단위로 묶습니다.

1. Chat Memory

대화에서 얻은 사실, 선호, 결정과 상호작용 이력입니다. 단순한 로그가 아니라 다음 작업에서 다시 사용할 가치가 있는 정보가 추출된 형태입니다.

2. Skill

성공한 작업에서 추출한 실행 절차입니다. Skill에는 단순한 프롬프트만 들어가는 것이 아니라 버전, 리소스 파일, 발동 조건, 실행 단계와 검증 규칙을 담을 수 있습니다.

예를 들어 “릴리스 전에 확인할 항목”이나 “고객 인터뷰를 분석하는 절차”, “특정 유형의 장애를 진단하는 순서”를 Skill로 만들면 다른 에이전트가 같은 시행착오를 반복하지 않아도 됩니다.

3. LLM-Wiki

제품 문서, 설계 명세와 운영 문서를 구조화된 페이지와 링크 그래프로 바꿉니다. 문서 전체를 매번 프롬프트에 넣는 대신 에이전트가 필요한 페이지를 검색하고, 링크를 따라가며 세부 내용을 읽습니다.

4. CodeGraph

코드 저장소의 파일, 심볼, 호출 관계와 변경 영향 경로를 인덱싱합니다. 에이전트는 단순히 관련 코드 조각을 찾는 데서 그치지 않고, 특정 함수를 바꾸면 무엇이 영향을 받을 가능성이 있는지도 조사할 수 있습니다.

Wiki와 CodeGraph는 모든 내용을 전역 프롬프트에 주입하지 않습니다. 에이전트가 도구 목록을 확인한 뒤 필요한 페이지, 소스 코드나 영향 경로만 호출합니다. 지식을 항상 들고 다니는 배경 정보가 아니라 필요할 때 접근하는 도구형 기억으로 취급하는 셈입니다.

개인 경험은 어떻게 조직의 기억이 되는가

그림 3. 개인의 작업 경험이 팀의 Memory Asset으로 전환되는 과정. 추출된 Chat Memory·Skill·LLM-Wiki·CodeGraph는 기본적으로 비공개로 생성되며, 검토·버전 관리·권한 설정을 거쳐 역할별 Agent Loadout에 배정됩니다. (출처: TenCentDB Agent Memory 문서를 바탕으로 재구성)

Team Memory가 제시하는 흐름은 다음과 같이 정리할 수 있습니다.

1. 개인과 에이전트가 실제 업무를 수행합니다.
2. 대화와 도구 실행에서 Chat Memory와 Skill을 추출합니다.
3. 새로 만들어진 자산은 우선 개인 소유의 비공개 상태로 보관합니다.
4. 사람이 내용, 출처, 버전과 상태를 검토합니다.
5. 검토된 자산을 팀 전체 또는 특정 사용자·역할·에이전트와 공유합니다.
6. 역할별 Agent Loadout에 필요한 자산만 장착합니다.
7. 문서와 코드가 바뀌면 Wiki와 CodeGraph를 다시 동기화합니다.

예를 들어 한 팀에 조사 Agent, 개발 Agent, 리뷰 Agent가 있다고 가정해 보겠습니다.

• 조사 Agent에는 시장조사 Wiki, 사용자 인터뷰 Chat Memory와 경쟁 분석 Skill을 제공합니다.
• 개발 Agent에는 제품 Wiki, 프로젝트 CodeGraph와 기능 구현 Skill을 제공합니다.
• 리뷰 Agent에는 과거 장애 이력, CodeGraph와 릴리스 체크리스트 Skill을 제공합니다.

모든 에이전트에게 같은 정보를 주는 대신, 역할에 필요한 기억만 골라 배정하는 것입니다. 이는 단순한 접근 권한 관리 이상의 의미가 있습니다. 불필요한 정보로 인한 컨텍스트 잡음을 줄이고, 특정 역할이 잘못된 지식을 행동에 사용하지 못하도록 제한하는 정책 계층이기도 합니다.

RAG와 Team Memory의 차이는 검색이 아니라 제어 계층에 있습니다

Team Memory를 새로운 종류의 RAG로만 보면 핵심을 놓치기 쉽습니다.

일반적인 RAG는 주로 다음 질문에 답합니다.

현재 질문과 관련해 무엇을 찾을 수 있는가?

팀 메모리는 여기에 다음 질문을 추가합니다.

• 이 기억의 소유자는 누구인가?
• 어떤 버전이 현재 유효한가?
• 검토가 끝난 자산인가, 아직 초안인가?
• 어느 팀과 사용자, 역할, 에이전트가 볼 수 있는가?
• 어떤 에이전트의 기본 장비로 고정할 것인가?
• 문제가 생겼을 때 어느 원본에서 만들어졌는지 확인할 수 있는가?

따라서 TencentDB Agent Memory의 가장 큰 특징은 새로운 검색 알고리즘을 발명했다는 데 있지 않습니다. 계층형 기억, 하이브리드 검색, Skill, Wiki와 CodeGraph를 소유권·버전·상태·권한·배정이 가능한 하나의 메모리 제어 계층으로 묶었다는 데 있습니다.

연구 조직의 Knowledge Agent에서 사용하는 Research Memory를 예로 들면 이 구분은 더 분명해집니다. 논문과 보고서를 검색하는 RAG는 “관련 근거를 찾는 기능”입니다. 반면 팀 메모리는 특정 연구자가 반복적으로 사용하는 분석 절차, 검증 체크리스트, 실패한 실험 조건, 장비별 주의사항, 프로젝트 의사결정을 누가 어떻게 재사용할 수 있는지 관리합니다.

둘은 경쟁 관계가 아니라 계층 관계에 가깝습니다. 기존에 이미 BM25 + Vector + RRF + reranker 검색 계층을 만들어서 쓰고 있는 경우라면 기존 인프라 위에 기억의 생성·승격·버전·권한·배분 계층을 추가하는 방식으로 조직의 기억을 관리하는 데 활용할 수 있을 것입니다.

개인에서 팀으로 확장할 때 생기는 문제와 현재의 대응

TencentDB Agent Memory가 제시하는 대응을 정리하면 다음과 같습니다.

핵심 철학은 “더 많이 기억하는 것”이 아니라 올바른 기억을 올바른 에이전트에게 전달하는 것입니다.

그러나 ‘공유 메모리’는 새로운 공격 대상이 될 수도 있습니다

팀 메모리는 유용한 만큼 위험도 커집니다.

첫째, 잘못된 개인 기억이 팀 자산으로 승격되면 오류가 여러 에이전트에 전파될 수 있습니다. 반복 사용될수록 잘못된 결과가 다시 기억으로 저장되면서 오류가 더 강하게 유착될 수도 있습니다.

둘째, Skill이나 Wiki에 악의적인 지시가 섞이면 공유 메모리가 지속적인 프롬프트 인젝션 경로가 될 수 있습니다. 공격자가 한 번 삽입한 지시가 여러 세션과 여러 에이전트에서 반복 실행될 가능성이 생깁니다.

셋째, 애플리케이션 수준의 ACL (Access Control List, 접근 권한 관리)만으로는 충분하지 않을 수 있습니다. GitHub 저장소에 등록된 cross-tenant leakage 관련 이슈를 보면 공유 허브에서 에이전트가 자신의 실행 맥락에 허용된 기억만 질의하도록 owner_id와 source_id 범위의 격리를 데이터베이스 수준에서 강제해야 한다는 문제가 제기되기도 했습니다.

넷째, 출처가 있다는 것과 그 출처를 신뢰할 수 있다는 것은 다른 얘기입니다. 누가 기록했고 누가 승인했는지, 승인 뒤 내용이 바뀌지 않았는지, 어떤 버전이 실제 실행에 사용됐는지를 검증하려면 변경 불가능한 감사 기록과 서명 체계가 필요합니다.

그림 4. 팀 메모리에서 발생할 수 있는 오류의 증폭 고리. 기억의 재사용성은 경험뿐 아니라 오류에도 복리 효과를 만들 수 있으므로, 출처와 유효기간·사람의 승인·서명과 권한 검증·격리·롤백 체계가 필요합니다.

엔터프라이즈 환경에서 말할 수 있는 zero-trust memory는 최소한 다음 조건을 갖춰야 합니다.

• 모든 검색 요청에서 사용자·팀·에이전트·작업 범위를 함께 검증합니다.
• 기억과 Skill에 작성자, 원본, 추출 모델, 승인자와 변경 이력을 남깁니다.
• 검토된 Skill은 서명하고, 실행 전에 무결성과 권한을 다시 확인합니다.
• 외부 문서와 코드에서 추출된 지시는 데이터와 실행 명령을 분리해 처리합니다.
• 잘못된 기억이 발견되면 이를 사용한 에이전트와 결과까지 역추적합니다.
• 오염된 버전을 빠르게 폐기하고 안전한 버전으로 롤백할 수 있어야 합니다.

현재의 비공개 기본값, Owner, ACL과 역할별 Loadout은 좋은 출발입니다. 그러나 이것만으로 기업 환경의 신뢰 경계를 완성했다고 보기는 어렵습니다. Team Memory는 현재 저장소에서도 빠르게 발전 중인 베타 기능으로 소개되고 있습니다.

초기 벤치마크와 반응

2026년 8월 9일 기준 저장소는 GitHub에서 약 1만 8천 개의 Star와 1,600개 이상의 Fork를 기록하고 있습니다. 공개 직후의 관심은 상당히 큽니다.

개발자들이 특히 긍정적으로 보는 지점은 다음과 같습니다.

• 로컬에서 배포하고 기억 계층을 직접 살펴볼 수 있다는 점
• 요약된 기억에서 원본 대화로 거슬러 올라갈 수 있는 white-box 구조
• 기억 자산이 특정 에이전트 프레임워크에 강하게 종속되지 않는다는 점
• 역할별 Agent Loadout과 세분화된 공유 범위
• 대화뿐 아니라 Skill, 문서와 코드까지 하나의 자산 모델로 다룬다는 점

반면 실제 사용자 커뮤니티의 질문은 아직 매우 실용적입니다. 자동 기억 포착이 충분히 안정적인지, 사용자가 매번 “이것을 기억하라”고 명시하지 않아도 되는지, 검색이 불필요한 기억까지 끌어오지 않는지, 기존 메모리 플러그인보다 실제 작업에서 나은지를 묻고 있습니다. OpenClaw 사용자 논의도 이러한 초기 탐색 단계의 분위기를 보여줍니다.

공개된 대표 벤치마크에서는 PersonaMem 정확도가 메모리 미사용 시 48%에서 사용 시 76%로 올랐다고 보고합니다. 이는 28%포인트 상승이며, 48%를 기준으로 계산하면 상대적으로 약 58~59% 개선입니다.

다만 PersonaMem은 장기간 상호작용 뒤 에이전트가 사용자 정보를 얼마나 잘 이해하고 적용하는지를 평가하는 개인화 중심 벤치마크입니다. 이 결과만으로 Team Memory의 효과까지 입증됐다고 보기는 어렵습니다.

팀 메모리를 제대로 평가하려면 다른 지표가 필요합니다.

• 새로운 팀원이 업무 맥락을 익히는 시간이 얼마나 줄었는가?
• 이미 해결한 문제를 다시 조사하는 비율이 얼마나 감소했는가?
• 공유 Skill이 성공률과 작업 일관성을 얼마나 높였는가?
• 잘못된 기억 하나가 몇 개 에이전트와 결과에 전파되는가?
• 권한 밖의 기억이 검색되거나 실행에 사용되는 비율은 얼마인가?
• 시간이 지나도 기억의 정확성, 최신성과 출처 추적성이 유지되는가?

현재의 높은 Star 수와 외부 반응은 검증된 합의라기보다, 많은 개발자가 같은 문제를 절실하게 느끼고 있다는 신호에 가깝습니다.

이 프로젝트가 던지는 가장 중요한 메시지

TencentDB Agent Memory가 중요한 이유는 개별 구성 요소가 완전히 새로워서가 아닙니다. 계층형 요약, BM25와 벡터 검색, RRF, Skill, Wiki, 코드 그래프, ACL은 각각 이미 존재하던 아이디어입니다.

새로운 점은 이들을 하나의 운영 모델로 묶어 에이전트의 경험을 조직 자산으로 취급하기 시작했다는 것입니다.

기존의 에이전트 시스템에서는 모델과 프롬프트, 도구가 주요 자산이었습니다. 앞으로는 어떤 기억을 축적했고, 그 기억이 얼마나 신뢰할 수 있으며, 어느 역할에 어떻게 배분되는지가 시스템의 성능을 좌우할 가능성이 큽니다.

같은 모델을 사용하는 두 조직도 시간이 흐르면 전혀 다른 에이전트 역량을 갖게 될 수 있습니다. 한 조직은 검증된 절차, 실패 이력, 프로젝트 결정과 도메인 지식을 지속적으로 축적하고, 다른 조직은 매 세션을 사실상 처음부터 시작할 수 있기 때문입니다.

이때 경쟁력의 차이는 모델 파라미터가 아니라 경험의 복리 효과에서 생깁니다.

앞으로 필요한 발전 방향

Team Memory가 실제 조직 인프라로 자리 잡으려면 다음 과제가 중요합니다.

1. 출처·승인·서명의 표준화

모든 기억과 Skill에 원본, 작성자, 추출 방법, 검토자, 승인 상태와 무결성 정보를 붙여야 합니다. 단순한 metadata가 아니라 실행 시 검증되는 정책이 돼야 합니다.

2. 시간과 충돌을 다루는 메모리 모델

기억에는 생성 시점뿐 아니라 유효 기간과 적용 범위가 필요합니다. 서로 모순되는 기억이 검색됐을 때 최신 정보가 항상 옳은지, 공식 문서와 개인 경험 중 무엇을 우선할지도 정책으로 정의해야 합니다.

3. 기억 오염 탐지와 안전한 롤백

비정상적인 기억 생성, 동일한 오류의 반복 전파, 외부 문서에서 들어온 악의적인 지시를 탐지해야 합니다. 문제가 생겼을 때 관련 자산을 격리하고 이전 버전으로 되돌리는 기능도 필요합니다.

4. 자동 Memory Routing

현재의 수동 Loadout을 넘어 작업의 목적, 민감도, 역할과 현재 상태를 바탕으로 필요한 기억 자산을 자동 선택하는 라우터가 발전할 것입니다. 다만 자동화가 늘어날수록 왜 특정 기억이 선택됐는지 설명할 수 있어야 합니다.

5. 기억의 승격·감쇠·망각

자주 사용된다고 좋은 기억인 것은 아닙니다. 실제 사용 결과와 사람의 평가를 바탕으로 성공한 개인 기억은 팀 자산으로 승격하고, 오래되거나 실패를 유발한 기억은 가중치를 낮추거나 폐기해야 합니다.

6. 프레임워크 간 이식 가능한 메모리 표준

Chat Memory, Skill, Wiki와 CodeGraph를 서로 다른 에이전트 프레임워크 사이에서 옮길 수 있으려면 자산 형식, 권한, provenance와 실행 규약의 공통 표준이 필요합니다. 기억이 특정 제품에 갇히면 조직의 장기 자산이 되기 어렵습니다.

7. 팀 단위 벤치마크

개인화 정확도를 넘어 팀 생산성, 중복 작업 감소, 온보딩 시간, 의사결정 일관성, 오류 전파와 권한 침해를 함께 측정해야 합니다. 팀 메모리의 가치는 “얼마나 많이 기억했는가”가 아니라 “팀이 더 적은 반복으로 더 신뢰할 수 있는 결과를 냈는가”로 평가해야 합니다.

마치며

에이전트 메모리의 다음 단계는 더 큰 벡터 데이터베이스나 더 긴 대화 기록만으로 오지 않을 가능성이 큽니다.

중요한 것은 무엇을 기억할지, 어떻게 검증할지, 누가 사용할 수 있는지, 언제 수정하거나 잊을지를 결정하는 체계입니다. 개인의 경험을 팀 전체가 재사용하려면 검색 엔진 위에 소유권, 버전, 권한, 승인과 감사가 가능한 제어 계층이 필요합니다.

TencentDB Agent Memory의 Team Memory는 아직 빠르게 변하는 베타 단계이고, 팀 협업 효과와 보안성도 더 검증돼야 합니다. 그럼에도 이 프로젝트는 에이전트 메모리를 바라보는 관점을 분명하게 한 단계 넓혔습니다.

에이전트가 개인 도구에서 팀 구성원으로 바뀌는 순간, 메모리는 편의 기능이 아니라 조직 인프라가 됩니다.

그리고 에이전트 경쟁의 다음 단계는 단지 “누가 더 똑똑한 모델을 쓰는가”가 아니라, 누가 더 신뢰할 수 있는 조직 기억을 축적하고 안전하게 재사용하는가에서 갈릴 가능성이 큽니다.

참고 자료

• TencentDB Agent Memory GitHub 저장소
• TencentDB Agent Memory 공식 발표
• Cross-tenant leakage 관련 GitHub 이슈
• MemGPT: Towards LLMs as Operating Systems
• Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
• Zep: A Temporal Knowledge Graph Architecture for Agent Memory
• OpenClaw 사용자 논의
• 개발자 반응: Santiago Valdarrama

2024년 Sakana AI가 연구 아이디어 제안부터 코드 작성, 실험, 논문 집필, 자동 리뷰까지 전 과정을 하나의 루프로 연결한 The AI Scientist를 공개한 이래, AI 기반 연구 에이전트 분야는 매우 빠른 속도로 진화해 왔습니다.

이 진화 과정을 관통하는 핵심 축은 크게 세 가지로 요약할 수 있습니다.

하지만 이러한 가파른 발전과 함께 근본적인 의문도 함께 제기되고 있습니다.

"대규모 자동 탐색이 과연 인류 지식의 과학적 지평을 실제로 넓혀주고 있는가?"

2026년 발표된 논문 *AI Research Agents Narrow Scientific Exploration*은 이 문제에 대해 매우 냉정한 실증적 경고를 던집니다.

결국 지난 2년간의 역사는 단순히 LLM의 성능이 좋아진 과정이 아니라, "AI 연구 시스템이 내부적으로 유지·관리해야 하는 '연구 상태(Research State)'가 고도화되어 온 과정"으로 해석하는 것이 가장 정확합니다.

1. 2024 — The AI Scientist

연구 프로세스 전체를 실행 가능한 파이프라인으로 구축

The AI Scientist(코드: SakanaAI/AI-Scientist)의 가장 큰 공헌은 파편화되어 있던 연구 작업들을 하나의 자동화된 엔드투엔드(E2E) 루프로 묶어냈다는 점입니다.

$$\text{아이디어 생성} \rightarrow \text{코드 작성} \rightarrow \text{실험 수행} \rightarrow \text{결과 분석/시각화} \rightarrow \text{논문 작성} \rightarrow \text{자동 리뷰}$$

디퓨전 모델, 트랜스포머, 학습 동역학 등 3가지 머신러닝 분야에서 논문 1편을 작성하는 데 드는 비용을 15달러 미만으로 낮추며 가능성을 시연했습니다.

• 기능적 전환: 기존 AI for Science가 문헌 검색, 속성 예측 등 '부분 태스크 자동화'에 머물렀다면, 연구 과정 전체를 하나의 계산 가능한 '워크플로우 자동화' 영역으로 끌어올렸습니다.
• 명확한 한계: 연구자가 미리 작성해 둔 코드 템플릿 안에서만 작동했으며, 피어 리뷰 또한 AI 자체 평가에 의존했습니다.
• 연구의 상태 (State): [현재 아이디어 + 현재 코드 + 현재 실험 결과] 수준에 머물렀으며, 실행 세션이 끝나면 시스템의 모든 맥락이 초기화되는 비저장형(Stateless) 구조였습니다.

2. 2025 — AI Scientist-v2

고정 파이프라인에서 '에이전틱 트리 검색'으로의 전환

AI Scientist-v2(코드: SakanaAI/AI-Scientist-v2)는 고정된 일직선 파이프라인을 점진적 에이전틱 트리 검색(Progressive Agentic Tree Search) 구조로 전환했습니다.

실험 관리자(Experiment Manager)가 여러 연구 경로를 동시 다발적으로 생성한 뒤, 중간 결과를 평가하며 유망한 가지(Branch)를 확장해 나가는 방식입니다. 인간의 코드 템플릿 의존성도 완전히 제거했습니다.

• 내부 표현의 변화: 단선적 실행에서 아이디어 → {경로1, 경로2, 경로3...} → 평가 및 선택 → 확장 구조로 바뀌면서, 연구 프로세스가 '탐색 및 검색 문제(Search Problem)'로 재정의되었습니다.
• 의의: 실제 완전 자동 생성된 논문 3편을 ICLR 2025 워크숍(I Can't Believe It's Not Better)에 제출하여 1편이 실제 피어 리뷰 통과 기준을 충족했습니다.
• 새로운 병목: 단순히 탐색 공간을 넓히는 것만으로는 "수많은 가능성 중 어느 경로를 깊게 파고들어야 하는가"에 대한 자원 배분 문제를 해결하지 못했습니다.

3. 2025 — DeepScientist

연구 탐색을 베이지안 최적화 문제로 다루다

DeepScientist(코드: ResearAI/DeepScientist)는 과학적 발견 자체를 평가 비용이 비싼 블랙박스 최적화 문제로 정의했습니다.

$$x^* = \arg\max_x f(x)$$

아이디어($x$)를 저비용 가설 검증부터 시작하여 유망한 후보만 고충실도(High-fidelity) 실험으로 승격시키는 베이지안 최적화(Bayesian Optimization) 매커니즘을 도입했습니다.

• 규모 및 효율: 20,000 GPU-hour 이상을 투입해 약 5,000개의 아이디어를 제안하고, 1,100여 회의 실험 검증을 거쳐 21건의 의미 있는 성능 개선을 이뤄냈습니다.
• 시사점: 5,000개 생성 → 1,100회 실험 → 21건 성공이라는 수치가 보여주듯, 연구의 핵심 병목이 아이디어 양산이 아니라 '유망한 후보를 선별하는 필터링(Validation & Filtering)'으로 이동했습니다.
• 한계: 열린 과학 영역 전체보다는 명확한 목표 지표가 존재하는 벤치마크 문제에 특화된 국소 최적화 도구(Local Optimizer)에 가깝다는 한계가 존재합니다.

4. 2026 — EvoScientist

단발성 실행을 넘어 경험을 축적하는 지속성 메모리 구축

EvoScientist(공식 사이트: EvoScientist)는 이전 실행(Run)이 끝나면 경험이 소멸하던 상태 비저장(Stateless) 한계를 극복하고자 했습니다.

연구자(Researcher), 엔지니어(Engineer), 진화 관리자(Evolution Manager) 에이전트가 역할을 분담하고, 시스템 내에 두 가지 형태의 지속성 메모리(Persistent Memory)를 구축했습니다.

• 아이디어 메모리: 성공 가능성이 높은 방향과 더불어 실패했던 비효율적 가설(Negative Results)을 함께 저장하여 중복 탐색 방지.
• 실험 메모리: 효과적이었던 데이터 전처리, 모델 학습 전략, 디버깅 파이프라인 등 실무적 성공 패턴 축적.
• 학습의 정의: 파운데이션 모델의 가중치를 직접 재학습(Training)하지 않고, 경험 체득 → 메모리 구조화 → 검색 → 행동 변화를 구현하는 '시스템 수준의 경험적 학습(System-level Experiential Learning)'을 완성했습니다.

5. 2026 — NanoResearch

연구 기법을 넘어 '연구자의 암묵적 취향'을 학습

NanoResearch는 *"자동화 시스템이 누구를 위해 작동하는가?"*라는 질문을 던집니다. 모든 연구자는 선호하는 가설 검증 방식, 해석 가능성에 대한 비중, 요구하는 증거의 수준이 다릅니다.

NanoResearch는 연구자 개인화를 세 가지 레이어로 분리하여 관리합니다. (위 그림에서 오른쪽 위의 세 가지 항목)

• 메모리 (Memory): 특정 프로젝트 및 사용자의 과거 실행 이력.
• 스킬 (Skill): 프로젝트 전반에서 재사용 가능한 절차적 작업 능력.
• 정책 (Policy): 주관식 피드백과 선택 이력에서 추출한 연구자의 암묵적 선호를 플래너 매개변수에 반영하는 정책 적응(Policy Adaptation).

💡 주의점: 인식론적 에코 챔버 (Epistemic Echo Chamber) > 지나친 개인화는 연구자의 기존 편향과 선입견을 AI가 그대로 강화해 버리는 부작용을 낳을 수 있습니다. 뛰어난 연구 에이전트는 연구자의 취향에 맞추면서도, 때로는 기존 틀을 깨는 반대 가설과 낯선 시도를 의도적으로 제안하는 탐색과 적응 사이의 밸런스를 가져야 합니다.

6. 2026 — AutoSci & Sibyl

단순 기억(Memory)을 넘어 시스템 자가 진화(Research OS)로

단순히 실패 기록을 DB에 저장해 둔다고 해서 AI가 실제로 학습했다고 볼 수 있을까요? 이 의문에 답하기 위해 두 연구가 등장했습니다.

AutoSci: 연구 환경 자체를 지속성 환경으로 다루다

AutoSci(코드: skyllwt/AutoSci)는 지식 메모리(SciMem), 생애주기 관리(SciFlow), 멀티에이전트 워크플로우(SciDAG), 시스템 진화(SciEvolve)의 4개 계층을 통해 시스템 전체를 버전 관리되는 연구 전용 운영체제(Research OS)로 확장했습니다.

Sibyl: "메모리 저장은 행동 변화가 아니다"

Sibyl-AutoResearch(코드: AutoResearch-SibylSystem)는 부실한 증거가 과장된 주장으로 이어지거나, 메모리는 축적되면서도 행동은 바뀌지 않는 '착시 현상'을 감지하기 위한 엄밀한 평가 기준을 제시했습니다.

• 시도-행동 전환 (Trial-to-Behavior Conversion): 개별 실험의 실패/성공 결과가 향후 계획 수립 및 주장의 범위를 실제로 수정했는가?
• 시도-하네스 행동 전환 (Trial-to-Harness-Behavior Conversion): 반복적인 프로세스 결함이 실행 프레임워크(Harness) 및 가드레일 자체의 수정으로 연결되었는가?

사후 감사를 통해 8건의 고신뢰 전환 사건을 확인했으며, 진정한 학습 평가의 기준을 "무엇을 기억했는가"에서 "그 경험으로 인해 다음 행동이 실제로 어떻게 변했는가"로 전환했습니다.

7. 2026년 8월 — EviGraph

논문 생성을 넘어 '주장-증거 구조'의 논리적 검증

EviGraph는 AI가 생성해 낸 그럴듯한 서술 속에 숨겨진 논리적 단절 문제를 해결하고자 합니다.

연구의 핵심 상태를 문제 정의 → 연구 공백 → 가설 → 실험 → 발견 → 최종 주장으로 이어지는 유형화된 증거 그래프(Typed Evidence Graph)로 유지하며 작동합니다.

• 자발적 수정 및 검증: 증거 연결망에서 논리적 비약이나 결과-주장 간 부조화가 감지되면, 결함이 발생한 노드로 돌아가 하위 연구를 자동으로 재수행합니다. 모든 주장이 검증된 증거 체인에 연결된 후에야 최종 논문 초안을 작성합니다.
• 증거 검증(Verification) vs 과학적 입증(Validation): EviGraph가 수행하는 것은 데이터와 주장 간의 '논리적 무결성 검증(Verification)'입니다. 해당 주장이 현실 세계에서 실제로 참인지를 밝히는 '과학적 입증(Validation)'을 위해서는 독립적인 재현 실험 및 외부 데이터셋 교차 검증이 별도로 필요합니다.

반전: AI 에이전트가 과학 탐색의 지평을 오히려 좁히고 있는가?

그렇다면 AI Scientist의 규모를 무한히 확장하면 인류의 과학적 발견 범위도 그만큼 넓어질까요?

21만 개 이상의 연구 아이디어를 정밀 분석한 연구 *AI Research Agents Narrow Scientific Exploration*은 그렇지 않을 수 있다는 결과를 보여줍니다.

1. 지식의 밀집화: AI가 제시한 아이디어들은 인간 연구에 비해 기존 지식 주변에 훨씬 더 빽빽하게 밀집되어 있었습니다.
2. 보수적 탐색: 씨앗 문헌(Seed Literature)의 영향권에서 멀리 벗어나지 못하고 주변부만 반복 탐색했습니다.
3. 낮은 학술적 영향력: 엄청난 양의 아이디어를 쏟아냈음에도, 실제로 파급력 있는 시도로 이어진 비율은 낮았습니다.

이는 국소 최적화를 잘 하는 도구(Local Optimizer)가 광범위한 과학적 탐색을 잘 하는 도구(Scientific Explorer)는 아니라는 점을 명백히 보여줍니다.

시스템 아키텍처의 세대별 진화 요약

지난 2년간 AI Scientist의 진화는 모델 자체의 단일 성능 향상이 아니라, 에이전트가 유지 관리하는 '연구 상태(Research State)'의 고도화 과정이었습니다.

차세대 AI Scientist를 위한 7가지 필수 계층

오크리지 내셔널 랩에서 최근 공개한 로드맵 보고서 Toward Trustworthy Autonomous Science 에 수록된 내용 등을 종합할 때, 차세대 자율 과학 시스템은 다음 7가지 계층이 유기적으로 결합되어야 합니다.

1. 탐색 계층: 다양성 중심의 가설 생성 및 탐색 트리 확장.
2. 자원 할당 계층: 베이지안 최적화를 통한 제한된 실험 자원의 효율적 배분.
3. 지속 학습 계층: 실패 경험을 기억하고 이후 행동 방침을 실제로 수정.
4. 개인화 계층: 연구자의 성향에 적응하되, 편향 갇힘(Lock-in) 방지 장치 마련.
5. 자가발전 하네스: 반복되는 오류 발생 시 에이전트 가드레일 및 워크플로우 자체를 수정.
6. 증거 및 출처 추적 계층: 모든 연구 주장의 출처와 데이터 근거 추적성 보장.
7. 독립적인 입증 계층: 생성 에이전트와 독립된 검증 에이전트 및 외부 실험계를 통한 교차 검증.

결론: AI Scientist의 궁극적인 KPI 변화

초기 AI Scientist의 평가 기준이 단순히 "논문 한 편을 완성할 수 있는가?"였다면, 앞으로 자율 과학 시스템의 가치를 평가하는 성과 지표(KPI)는 다음과 같은 형태로 바뀌어야 합니다.

$$\text{Discovery Value} \propto \frac{\text{Novelty} \times \text{Importance} \times \text{Independent Validation}}{\text{Cost}}$$

단순히 수만 개의 아이디어를 생성하거나 수백 편의 논문을 자동 작성하는 양적 수치는 더 이상 핵심 지표가 될 수 없습니다.

앞으로 AI Scientist 연구의 본질적인 프런티어는 다음 두 가지 질문으로 집약될 것입니다.

1. 기존 문헌의 주변부를 벗어나 어떻게 진짜 새로운 과학적 질문을 발견할 것인가?
2. AI가 도출한 주장이 참이라는 것을 어떻게 독립적이고 객적으로 검증할 것인가?

결국 AI Scientist의 진화는 '논문을 대신 써주는 AI'에서, '경험을 축적하고, 탐색 전략을 스스로 교정하며, 연구자에게 적응하고, 자신의 주장에 대해 명확한 증거를 제시하는 신뢰할 수 있는 과학적 발견 시스템'으로 나아가고 있습니다.