<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>muaco.dev</title>
    <link>https://muaco.dev</link>
    <description>Claude Code·Cursor·MCP·스킬. AI 도구를 실제로 써보고 남기는 사용법과 정리.</description>
    <language>ko</language>
    <atom:link href="https://muaco.dev/rss.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>EU, 챗GPT를 초대형 검색엔진으로 지정: 직장인 업무에 달라지는 점</title>
      <link>https://muaco.dev/posts/2026-09-01-eu-chaetgptreul-chodaehyeong-geomsaekenjineuro-jijeong-jikjangin-eopmu/</link>
      <guid isPermaLink="true">https://muaco.dev/posts/2026-09-01-eu-chaetgptreul-chodaehyeong-geomsaekenjineuro-jijeong-jikjangin-eopmu/</guid>
      <pubDate>Tue, 01 Sep 2026 00:00:00 GMT</pubDate>
      <category>AI 소식</category>
      <description>EU가 챗GPT를 디지털서비스법상 초대형 검색엔진으로 지정하면서 오픈AI가 2027년 1월 말까지 위험 평가·감사 의무를 갖춰야 합니다.</description>
      <content:encoded><![CDATA[<p>안녕하세요, muaco입니다.</p>
<p>유럽연합 집행위원회가 2026년 8월 31일 오픈AI의 챗GPT를 디지털서비스법상 '초대형 온라인 검색엔진'으로 지정했습니다. 생성형 AI 챗봇이 이 분류에 들어간 첫 사례입니다. PYMNTS는 오픈AI가 2027년 1월 31일까지 관련 의무를 준수해야 한다고 전했습니다. 구글 검색이나 마이크로소프트 빙과 같은 수준의 위험 평가·투명성 의무입니다. AI 서비스가 신기술 실험 단계를 지나 기존 플랫폼 규제의 틀 안으로 들어왔다는 신호입니다.</p>
<h2 id="배경-디지털서비스법이라는-틀">배경: 디지털서비스법이라는 틀</h2>
<p>디지털서비스법(DSA, 온라인 플랫폼의 불법 콘텐츠와 이용자 보호를 규율하는 EU 법)은 규모가 큰 서비스일수록 무거운 책임을 지운다는 원칙 위에 서 있습니다. EU 27개 회원국 안에서 월간 활성 이용자가 4500만명을 넘으면 '초대형' 딱지가 붙습니다. 4500만명은 EU 인구의 약 10%에 해당하는 선입니다. 이 선을 넘은 서비스는 그동안 대형 검색엔진과 소셜미디어가 대부분이었습니다.</p>
<p>챗GPT의 이용자 규모는 이 기준을 한참 넘어섭니다. TechRepublic은 2025년 9월로 끝나는 6개월 동안 챗GPT의 EU 월평균 이용자를 약 1억 2040만명으로 전했습니다. 4500만명 기준을 두 배 넘게 웃도는 수치입니다.</p>
<p>같은 날 EU는 레딧과 로블록스도 규제 대상에 올렸습니다. 이 두 서비스는 제3자 콘텐츠를 퍼뜨리는 성격이라 '초대형 온라인 플랫폼'으로 분류됐습니다. 챗GPT만 검색엔진 쪽으로 묶였습니다. 이로써 초대형 검색엔진 명단은 구글 검색, 빙, 챗GPT 셋이 됐습니다.</p>
<h2 id="무엇이-달라지나">무엇이 달라지나</h2>
<p>오픈AI가 새로 져야 할 의무는 대체로 이렇습니다. 불법 콘텐츠 유포, 미성년자에게 미치는 부정적 영향, 이용자의 신체적·정신적 안녕, 기본권 침해, 선거 절차 개입, 공공 안전 위협을 스스로 평가하고 줄여야 합니다. 추천이나 응답을 만들어내는 알고리즘이 이런 위험을 키우지 않는지도 점검 대상입니다. 여기에 연 1회 독립 감사, 광고와 콘텐츠 관리에 관한 투명성 공개, 연구자에게 데이터를 열어주는 절차, 규제당국·이용자와 연결되는 담당 창구 설치가 따라붙습니다.</p>
<p>비용도 발생합니다. 지정 사업자는 EU의 감독 활동에 연간 전 세계 순이익의 최대 0.05%를 감독 수수료로 냅니다. 의무를 지키지 않으면 제재가 뒤따릅니다. 유럽 집행위는 앞서 X에 1억 2000만 유로 과징금을 부과한 적이 있습니다. 규제 강도가 선언에 그치지 않는다는 실증입니다.</p>
<p>EU 기술·주권 담당 집행위원 헤나 비르쿠넨은 이번 지정의 취지를 이렇게 요약했습니다.</p>
<blockquote>챗GPT와 레딧, 로블록스는 시민들과 사회에 미치는 영향력에 걸맞게 EU에서 보다 높은 수준의 감독과 책임을 지게 될 것입니다. (PYMNTS 인용)</blockquote>
<h2 id="직장인에게-어떤-의미인가">직장인에게 어떤 의미인가</h2>
<p>당장 해볼 만한 일입니다. 지금 팀이 쓰는 AI 도구를 한 장으로 정리해 보세요. 어떤 서비스에 어떤 성격의 데이터가 들어가는지, 고객 정보나 미공개 자료가 섞여 있는지만 적어도 충분합니다. 유럽 법인이나 유럽 고객을 둔 회사라면 이 목록이 곧 감사 대응 자료가 됩니다. 예를 들어 마케팅팀이 고객 문의 원문을 챗GPT에 붙여 넣어 요약해 왔다면, 개인정보가 섞이는 지점을 지금 끊어두는 편이 낫습니다.</p>
<p>미리 준비할 일도 있습니다. 준수 기한인 2027년 1월 말을 전후해 챗GPT 화면이 조금씩 바뀔 가능성이 있습니다. 답변의 출처 표시가 촘촘해지거나, 미성년자 계정 확인 절차가 붙거나, 문제 있는 응답을 신고하는 버튼이 생기는 식입니다. 사내 매뉴얼에 화면 캡처를 박아 넣었다면 갱신이 필요해집니다. 규제 대응 과정에서 특정 답변이 보수적으로 바뀔 수도 있으니 업무 흐름이 한 도구에만 묶여 있지 않은지 점검해 두면 좋습니다.</p>
<p>과장은 금물입니다. 이번 지정은 오픈AI에 부과된 의무이지, 챗GPT를 쓰는 회사가 곧바로 새 법적 책임을 지지는 않습니다. 서비스가 유럽에서 멈추는 상황도 아닙니다. DSA는 별도로 시행 중인 EU 인공지능법과도 다른 법이라 둘을 섞어 이해하면 혼란이 생깁니다. 오픈AI가 어떤 기능을 어떻게 손볼지는 아직 공개되지 않았습니다.</p>
<h2 id="정리">정리</h2>
<p>EU가 챗GPT를 초대형 검색엔진으로 지정하면서 생성형 AI도 대형 플랫폼과 같은 감독 체계에 들어왔습니다. 준수 기한인 2027년 1월 말을 전후해 오픈AI가 내놓을 첫 위험 평가 보고서와 화면 변경 내역을 지켜보면, 다른 AI 서비스에 닥칠 변화도 미리 가늠할 수 있습니다. 회사에서 AI 도구를 고를 때 성능과 가격만 보던 관행에 규제 항목이 하나 더 붙습니다.</p>
<p>이상으로 글 마치겠습니다.</p>
<h2 id="참고한-자료">참고한 자료</h2>
<ul>
<li><a href="https://www.etnews.com/20260901000014" target="_blank">EU, 오픈AI '챗GPT' 디지털서비스법 초대형 규제 적용 (전자신문)</a></li>
<li><a href="https://cryptobriefing.com/chatgpt-reddit-roblox-eu-very-large-platforms/" target="_blank">ChatGPT, Reddit, Roblox designated as EU Very Large Platforms under Digital Services Act (Crypto Briefing)</a></li>
<li><a href="https://www.techrepublic.com/article/chatgpt-digital-services-act-vlose-classification/" target="_blank">EU to Classify ChatGPT as VLOSE Under Digital Services Act (TechRepublic)</a></li>
<li><a href="https://www.pymnts.com/legal/2026/chatgpt-faces-greater-regulatory-oversight-european-union/" target="_blank">ChatGPT Faces Greater Regulatory Oversight by EU (PYMNTS)</a></li>
</ul>]]></content:encoded>
    </item>
    <item>
      <title>AI 에이전트 설계, 프롬프트 엔지니어링만으로는 안 되는 이유</title>
      <link>https://muaco.dev/posts/2026-09-01-ai-eijeonteu-seolgye-peurompeuteu-enjinieoringmaneuroneun-an-doeneun-i/</link>
      <guid isPermaLink="true">https://muaco.dev/posts/2026-09-01-ai-eijeonteu-seolgye-peurompeuteu-enjinieoringmaneuroneun-an-doeneun-i/</guid>
      <pubDate>Tue, 01 Sep 2026 00:00:00 GMT</pubDate>
      <category>AI 에이전트</category>
      <description>n8n 블로그는 오래 도는 AI 에이전트의 성패가 프롬프트가 아니라 기억·재시작·검증 설계에서 갈린다고 짚었습니다.</description>
      <content:encoded><![CDATA[<p>n8n 블로그가 8월 31일 공개한 글에서 저자 앤드루 그린은 오래 돌아가는 AI 에이전트를 프롬프트만으로 만들 수 없다고 못 박았습니다. 모델은 글자를 받고 내놓는 부품일 뿐입니다. 언제 멈추고 어떻게 다시 이어갈지는 사람이 미리 설계해야 한다는 이야기입니다. 저자는 특히 작업이 잘 됐는지 AI에게 되묻는 방식을 가장 손쉽지만 가장 못 믿을 검증으로 지목했습니다. 업무 자동화를 준비하는 직장인에게도 남의 이야기가 아닙니다.</p>
<h2 id="프롬프트-컨텍스트-루프로-이름만-바뀌었습니다">프롬프트, 컨텍스트, 루프로 이름만 바뀌었습니다</h2>
<p>지난 몇 년 사이 자동화 현장의 유행어는 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로, 다시 루프 엔지니어링으로 옮겨갔습니다. 저자는 이름표만 갈아 끼웠을 뿐 같은 습관이 반복된다고 봅니다. 모델에게 더 좋은 지시문을 주면 알아서 끝까지 해내리라는 기대 말입니다.</p>
<p>구조를 뜯어보면 그 기대가 왜 무너지는지 드러납니다. 언어 모델은 이전 대화를 스스로 기억하지 못합니다. 그래서 매 호출마다 지금까지 오간 기록 전체를 다시 밀어 넣습니다. 대화가 길어지면 입력 한도를 넘습니다. 넘기 전부터 모델이 중심 지시를 놓치는 컨텍스트 부패가 시작됩니다. 채팅 화면은 기억이 이어지는 듯한 착시를 줄 뿐입니다.</p>
<h2 id="글이-제시한-세-갈래-설계">글이 제시한 세 갈래 설계</h2>
<h3 id="기억을-모델-밖에-둡니다">기억을 모델 밖에 둡니다</h3>
<p>첫째는 맥락과 기억입니다. 구글의 에이전트 개발 키트(ADK)는 오래된 대화 기록을 요약해 입력을 줄이는 압축 기능을 제공합니다. 공식 문서를 보면 방식이 두 가지입니다. 소비한 토큰(모델이 글을 처리하는 단위) 양이 기준값을 넘으면 압축하는 방식, 그리고 정해진 대화 턴마다 압축하되 앞뒤를 조금 겹쳐 두는 방식입니다. 구글은 비용과 응답 지연을 줄이려는 목적이라고 설명합니다.</p>
<p>저자는 여기에 저장 원칙을 덧붙입니다. 에이전트가 기록을 추가할 수는 있어도 지우거나 고칠 수는 없는 장부 형태로 남기라는 주문입니다. 기억을 만드는 작업은 본 작업과 떼어 뒤에서 돌리고 오래된 정보에는 만료 기한을 걸어 정리합니다.</p>
<h3 id="중간에-멈춰도-이어집니다">중간에 멈춰도 이어집니다</h3>
<p>둘째는 지속성 있는 실행입니다. 저자는 살려둘 대상과 버릴 대상을 나눕니다. 에이전트 상태, 저장된 표, 예약된 작업은 살려둡니다. 메모리에 떠 있는 변수, 돌아가던 타이머, 진행 중인 외부 호출은 버립니다. 작업이 오래 걸리면 붙잡고 기다리지 말고 잠들었다가 완료 신호를 받아 깨어나거나, 간격을 점점 늘려가며 다시 확인합니다.</p>
<p>복구도 같은 원리입니다. 장부를 되짚어 어디까지 했는지 확인하고 그 지점부터 이어갑니다. 저자는 이런 기능을 제공하는 도구로 DBOS, Restate, Inngest를 듭니다.</p>
<h3 id="합격-판정을-기계에-맡깁니다">합격 판정을 기계에 맡깁니다</h3>
<p>셋째 갈래의 비판이 가장 셉니다. 저자는 모델에게 채점을 맡기는 관행을 이렇게 정리합니다.</p>
<blockquote>가장 쉬운 해법이면서 가장 믿을 수 없는 해법입니다. (n8n 블로그, 앤드루 그린)</blockquote>
<p>대신 기계가 시비를 가릴 수 있는 신호를 쓰라고 권합니다. 응답 코드 확인, 정해진 형식대로 값이 들어왔는지 검사, 값들이 서로 앞뒤가 맞는지 보는 교차 필드 일관성 검사, 데이터가 실제로 바뀌었는지 다시 조회, 테스트 실행 순으로 신뢰도가 높다고 봅니다. 여기에 실행 전 완료 기준을 체크리스트로 적어두고 하나씩 지워가는 방식, 도구 호출이 같은 자리를 맴돌거나 토큰 사용이 갑자기 튀는지 감시하는 방식을 더합니다. 모델의 판단은 예 아니오로 답이 갈리는 좁은 질문에만 씁니다.</p>
<h2 id="직장인에게-어떤-의미인가">직장인에게 어떤 의미인가</h2>
<p>당장 바꿀 수 있는 습관이 하나 있습니다. 자동화를 짜기 전에 성공 조건을 문장으로 적어두는 습관입니다. 보고서 초안 작성을 맡긴다면 <strong>지정한 폴더에 파일이 생겼는가, 표에 행이 늘었는가, 요청한 항목이 빠짐없이 들어갔는가</strong>처럼 눈으로 확인 가능한 조건이어야 합니다. AI에게 잘했냐고 묻고 잘했다는 답을 받는 절차는 검증이 아닙니다.</p>
<p>긴 작업을 한 덩어리로 던지지 않는 습관도 같이 갑니다. 단계를 쪼개고 각 단계가 끝날 때마다 결과를 남기면, 도중에 멈춰도 처음부터 다시 하지 않습니다. 도구를 고를 때는 실행 기록이 남는지, 실패한 단계만 다시 돌릴 수 있는지 미리 확인해 두면 좋습니다.</p>
<p>과장은 금물입니다. 이 글은 실험 결과나 성능 비교가 아니라 저자의 현장 판단과 벤더 문서를 엮은 정리입니다. 저자 스스로 단계별 청사진이 아니라고 밝혔고, 짧게 도는 에이전트로 충분하다면 그렇게 하고 가장 단순한 도구를 고르라고도 적었습니다. 사내 도입을 설득할 때 이 글 하나만 근거로 삼기는 어렵습니다.</p>
<h2 id="정리">정리</h2>
<p>오래 도는 에이전트의 성패는 지시문 문장이 아니라 기억·재시작·검증을 어떻게 설계했느냐에서 갈립니다. 업무에 도입한다면 완료 조건을 기계가 확인할 수 있는 형태로 바꾸는 작업부터 시작하면 됩니다. 자동화 도구들이 이런 지속 실행 기능을 기본으로 품는지 지켜볼 만합니다.</p>
<h2 id="참고한-자료">참고한 자료</h2>
<ul><li><a href="https://blog.n8n.io/long-running-agents-beyond-prompt-engineering/" target="_blank">Long-running agents beyond prompt engineering (n8n Blog)</a></li><li><a href="https://adk.dev/context/compaction/" target="_blank">Context compaction (Google Agent Development Kit 공식 문서)</a></li></ul>]]></content:encoded>
    </item>
  </channel>
</rss>