AI 트렌드 | 5월 30일 : 에이전트 조직, 온디바이스 MoE, CAPTCHA 판별, AI 코드 스멜, 실시간 추론

2026년 5월 30일 | AI 최신 트렌드

---

5월 30일 아침 기준으로 눈에 들어온 축은 에이전트를 실제 업무 구조에 넣는 문제, 작은 모델과 빠른 추론으로 루프를 줄이는 문제, 그리고 AI가 만든 결과물을 어떻게 걸러낼지였다. 모델 발표 하나보다, AI를 오래 굴릴 때 생기는 조직·보안·품질·인프라 비용이 더 선명하게 보인 날이었다.

1. 에이전트는 툴보다 조직 설계 문제에 가까워짐

MIT Technology Review가 다룬 agentic AI 조직 설계 이미지.

MIT Technology Review는 agentic AI 도입을 단순한 도구 추가가 아니라 조직 운영 모델 재설계로 봐야 한다고 정리했다. 기사에서 인용한 조사 수치가 꽤 직관적이었다. 조직의 85%는 3년 안에 agentic해지고 싶다고 답했지만, 76%는 현재 운영·인프라가 그 변화를 받쳐 주지 못한다고 했다. 나는 이 대목이 과장된 컨설팅 문장보다 더 현실적으로 느껴졌다. 에이전트를 몇 개 붙이는 것과, 에이전트가 실제 workflow를 건너다니며 책임 있는 결과를 내는 것은 완전히 다른 문제이기 때문이다.

흥미로운 지점은 성과 지표다. AI가 1,000건을 처리할 수 있으면 “처리 건수”는 금방 의미를 잃는다. 그 대신 사람에게 escalation되지 않고 끝난 계약 검토 비율처럼 outcome 기준으로 봐야 한다는 얘기가 나온다. 나도 에이전트 도입 글을 읽을 때마다 결국 질문은 “얼마나 많이 돌렸나”가 아니라 “어디까지 사람이 책임질 수 있는 구조로 접었나” 쪽으로 돌아온다고 느낀다. 원문: MIT Technology Review

2. Liquid AI의 LFM2.5-8B-A1B, 온디바이스 MoE의 방향

Liquid AI가 공개한 LFM2.5-8B-A1B 벤치마크 이미지.

Liquid AI는 LFM2.5-8B-A1B를 공개했다. 이름은 길지만 핵심은 꽤 명확하다. 8B급 전체 파라미터, 1B급 active 파라미터를 쓰는 MoE 모델을 온디바이스 에이전트용으로 더 밀어붙인 것이다. 이전 LFM2-8B-A1B와 비교해 context window가 32K에서 128K로 늘었고, pretraining 데이터도 12T에서 38T token으로 커졌다. vocabulary도 65K에서 128K로 늘려 비라틴 문자 효율을 챙긴 점이 눈에 띄었다.

내가 재미있게 본 부분은 “작은 모델을 그냥 싸게 쓰자”가 아니라 로컬 도구 호출 루프를 빠르게 돌리는 개인 비서 모델로 포지셔닝한다는 점이다. Liquid AI는 LocalCowork 데모에서 13개 MCP 서버와 67개 도구를 온디바이스로 묶었다고 설명한다. 프런티어 모델 하나가 모든 걸 대신하는 흐름과는 다르게, 개인 장비 안에서 짧은 tool dispatch loop를 안정적으로 돌리는 쪽이다. 결국 에이전트 UX는 모델 지능만큼이나 지연 시간, context 길이, 로컬 데이터 경계의 영향을 받는다. 원문: Liquid AI Blog

3. CAPTCHA는 답보다 푸는 과정으로 AI를 구분하려는 쪽으로 이동

Roundtable Research가 공개한 모델 성능 비교 이미지.

Roundtable Research의 CAPTCHA 글은 방향이 흥미로웠다. 요지는 “AI도 CAPTCHA를 풀 수 있다”에서 끝나지 않는다. 같은 답을 내더라도 인간처럼 풀지는 않는다는 점을 측정하겠다는 얘기다. 순차 클릭 패턴, 방향 전환, 과잉 선택 같은 행동 경로를 보면 인간과 AI 사이에 통계적으로 다른 흔적이 남는다고 한다. 이걸 글에서는 Process Turing Test라고 부른다.

이 관점은 에이전트 평가에도 꽤 중요하다. 최종 답만 맞으면 되는 benchmark에서는 이미 많은 모델이 사람처럼 보인다. 그런데 실제 서비스에서는 “답을 맞혔나” 못지않게 어떤 절차로 도달했는지가 중요하다. CAPTCHA의 수명 자체를 떠나서, 출력 등가성과 과정 등가성을 분리하는 시도는 앞으로 보안·평가·사용자 식별 쪽에서 계속 나올 가능성이 크다. 원문: Roundtable Research

4. AISlop, AI가 남긴 코드 냄새를 정적 규칙으로 잡기

AISlop GitHub 저장소의 대표 이미지.

GitHub에서 올라온 AISlop은 이름부터 노골적이다. Claude Code, Codex, Cursor 같은 도구를 쓰고 나면 테스트는 통과하는데 코드에 묘한 냄새가 남는 경우가 있다. 설명 주석이 과하게 붙거나, 빈 catch 블록이 생기거나, generic helper가 중복되거나, 죽은 코드가 남는 식이다. AISlop은 이걸 LLM으로 다시 판단하지 않고 정적 규칙과 기존 린터 조합으로 잡겠다는 도구다.

이 접근은 꽤 마음에 든다. AI가 만든 코드를 AI로 다시 감정하는 것도 가능하지만, 반복적으로 보이는 냄새라면 deterministic gate로 빼는 편이 더 싸고 예측 가능하다. README 기준으로 7개 언어, 40개 이상 규칙, hook과 MCP 서버까지 지원한다고 한다. 내가 보기에는 “AI 코드 품질”이라는 말이 추상적으로 흘러가지 않으려면 이런 식의 작고 반복 가능한 품질 게이트가 필요하다. 원문: GitHub scanaislop/aislop

5. Kog의 3,000 tokens/s, 에이전트 루프에서 latency가 다시 전면으로

Kog가 공개한 실시간 LLM 추론 설명 이미지.

Kog의 글은 표면적으로는 “표준 데이터센터 GPU에서 3,000 tokens/s per request”라는 속도 이야기다. 그런데 읽다 보면 핵심은 benchmark 숫자보다 에이전트 루프의 단일 요청 지연 시간에 있다. 여러 사용자의 총 처리량보다, inspect → plan → edit → test → revise처럼 앞 단계가 끝나야 다음 단계가 열리는 루프에서는 한 요청의 decode speed가 바로 작업 시간으로 이어진다.

Kog는 batch size 1 decoding을 memory bandwidth 문제로 보고, persistent monokernel, GPU-resident logic, custom collective layer 같은 방식으로 일반 스택의 kernel overhead를 줄였다고 설명한다. 50,000-token workflow가 100 tokens/s에서는 8분 정도 걸리지만 3,000 tokens/s에서는 20초 아래로 내려간다는 비교도 인상적이었다. 모든 claim을 그대로 받아들이기보다, 나는 이 글을 에이전트 시대의 추론 지표가 throughput에서 iteration speed로 이동하는 신호로 읽었다. 원문: Kog Blog

다섯 소식을 묶어 보니 공통점은 꽤 분명했다. 에이전트는 더 이상 데모 화면 안의 기능만이 아니라 조직 구조, 개인 장비, 인증 절차, 코드 리뷰, 추론 엔진까지 동시에 흔드는 운영 단위가 되고 있다. 그래서 나는 요즘 AI 뉴스를 볼 때 모델 이름 하나보다 그 모델이 어떤 루프 안에서 쓰이는지를 먼저 보게 된다. 빠른 모델은 빠른 검증 루프를 만들고, 좋은 도구는 실패를 더 일찍 드러내며, 좋은 조직 설계는 에이전트가 만든 결과를 사람이 책임질 수 있는 형태로 접어 준다.

출처 목록

• MIT Technology Review — Rethinking organizational design in the age of agentic AI
• Liquid AI — LFM2.5-8B-A1B: an Even Better on-Device Mixture-of-Experts
• Roundtable Research — CAPTCHAs can still detect AI agents
• GitHub — scanaislop/aislop
• Kog Blog — Real-time LLM Inference on Standard Datacenter GPUs