2026년 7월 27일 | AI 최신 트렌드
에이전트가 한 번 답하고 끝나는 도구에서 오래 일하는 실행 주체로 바뀌면서, 모델 바깥의 조건이 더 선명하게 드러나고 있다. 어떤 컴퓨터를 빌려줄지, 작은 장치의 메모리를 어떻게 나눌지, 생산성 향상이 실제 채용 변화로 이어졌는지, 대화 중 바뀐 요구를 끝까지 따라가는지가 모두 같은 질문으로 모인다. 모델이 낼 수 있는 답보다 작업을 유지하는 환경과 상태가 먼저 병목이 되는 장면이 늘었다.
7월 22~26일 공개된 네 소식은 규모가 크게 다르다. 하나는 수천 개까지 복제하는 에이전트용 컴퓨터이고, 하나는 8달러짜리 마이크로컨트롤러에서 돌아가는 작은 언어 모델이다. 노동시장 데이터는 AI 도입과 일자리 감소를 성급히 같은 선에 놓지 말라고 경고하고, 새 프리프린트는 정적인 벤치마크에서 강한 모델도 사용자의 의도가 대화 중 바뀌면 흔들린다고 보고한다. 나는 네 사례를 계산량보다 상태, 연결, 전환을 어떻게 다루는가라는 관점에서 묶어 봤다.
1. Fly.io Sprites: 에이전트에게 오래 유지되는 컴퓨터를 빌려주는 방식
Fly.io의 Sprites 전환 발표에 따르면, 회사는 기존 PaaS와 Fly Machines를 유지하면서도 앞으로의 핵심 사업을 ‘에이전트용 컴퓨터’에 맞춘다. Sprites는 필요할 때 수백·수천 개를 만들 수 있고, 인스턴스마다 100GB 영구 디스크를 제공한다. 유휴 상태에서는 계량을 멈추는 구조라서 짧게 생성했다가 버리는 샌드박스와 며칠 동안 작업 맥락을 들고 있는 개발 환경 사이를 겨냥한다.
눈에 들어온 것은 CPU나 메모리 사양보다 스토리지였다. 새 Sprite Block Device는 체크포인트와 복원을 지원하고, 템플릿 디스크 하나를 여러 작업 환경으로 포크할 수 있게 한다. 코딩 에이전트가 동일한 저장소와 도구 구성을 가진 환경을 여러 개 띄워 서로 다른 수정안을 시험한다면, 매번 의존성을 다시 설치하는 대신 기준 디스크를 복제하는 편이 빠르다. 실행 환경 자체를 버전이 있는 작업 상태로 취급한다는 점이 일반 컨테이너 실행과 구별되는 부분이다.
Connectors도 같은 맥락에 있다. 에이전트가 외부 서비스에 인증된 요청을 보내더라도 원래 API 키를 작업 환경에 직접 넣지 않는 방식이다. 장기 실행 환경은 편하지만, 디스크에 비밀값이 남거나 포크된 인스턴스로 함께 복제될 위험도 커진다. 실행 상태의 지속성과 자격증명의 지속성을 분리하려는 설계가 필요한 이유다. 실제 운영에서는 포크 일관성, 장애 뒤 복원 성공률, 네트워크 격리, Connector 권한 범위를 따로 검증해야 한다. 제품이 말하는 ‘에이전트용 컴퓨터’는 서버 이름을 바꾸는 일이 아니라 상태 복제와 권한 위임을 함께 다루는 인프라 계약에 가깝다.
여기에 관측 가능성도 빠질 수 없다. 사람이 터미널 하나를 보며 작업할 때는 실패 직전의 명령과 파일을 추적하기 쉽지만, 수백 개의 Sprite가 동시에 분기되면 어떤 기준 이미지에서 시작했고 어떤 도구를 호출했는지 별도 계보가 필요하다. 체크포인트 ID, 부모 디스크, 승인받은 Connector, 종료 이유를 한 묶음으로 남겨야 실패한 에이전트를 재현할 수 있다. 복제가 싸질수록 실행 수는 늘고, 실행 수가 늘수록 환경 계보와 비용 상한이 제품 기능이 된다.
2. ESP32-S3의 2,890만 매개변수 LLM: 연산보다 메모리 배치가 만든 실험
ESP32-S3 LLM 실험 저장소는 약 8달러짜리 마이크로컨트롤러에서 서버 연결 없이 2,890만 매개변수 모델을 실행한 사례를 소개한다. 하드웨어에는 512KB SRAM, 8MB PSRAM, 16MB 플래시가 있고, 4비트로 양자화한 모델 크기는 14.9MB다. 생성 속도는 약 9.5 token/s로 보고됐다. 숫자만 보면 작은 모델을 더 작게 압축한 이야기 같지만, 핵심은 매개변수를 한 메모리에 모두 올리지 않았다는 데 있다.
연산 코어처럼 매 토큰마다 쓰는 부분은 빠른 SRAM에 두고, 출력 헤드와 작업 메모리는 PSRAM에 배치했다. 약 2,500만 개를 차지하는 큰 임베딩 테이블은 느린 플래시에 남겨 둔 뒤, 토큰마다 필요한 약 여섯 행, 450바이트 정도만 읽는다. Per-Layer Embeddings를 이용해 ‘전체 모델을 계속 읽는다’는 전제를 ‘지금 필요한 작은 조각만 가져온다’로 바꾼 셈이다. 내가 재미있게 본 지점도 최고 성능이 아니라 접근 빈도에 따라 가중치의 거처를 나눈 메모리 계층 설계였다.
물론 이 장치가 범용 챗봇이 되는 것은 아니다. TinyStories로 학습해 짧은 이야기를 만들 수 있지만, 질문 응답·명령 수행·코드 작성·사실 지식에는 적합하지 않다고 제작자도 선을 그었다. 2,890만이라는 매개변수 수가 곧 추론 능력을 뜻하지 않는 좋은 사례다. 대신 센서 가까이에서 아주 제한된 텍스트 패턴을 처리하거나, 네트워크가 끊긴 장치에서 작은 생성기를 돌릴 때 무엇을 줄여야 하는지 보여 준다. 앞으로 온디바이스 AI를 볼 때는 모델 크기 하나보다 활성 매개변수, 메모리 대역폭, 플래시 읽기량, 실제 과제 범위를 함께 봐야 한다.
3. AI와 고용 데이터: 대규모 실직보다 먼저 보이는 초기 경력 채용의 압력
AI 과대광고와 노동시장 증거를 구분한 분석은 ‘AI 때문에 일자리가 이미 사라졌다’는 단순한 결론을 경계한다. 2022년 이후 실업률은 AI 노출 상위 20% 직군에서 0.77%포인트, 하위 20% 직군에서 0.85%포인트 상승했다. 적어도 이 비교만으로는 AI 노출 직군에만 큰 충격이 왔다고 보기 어렵다. 기업 조사에서도 AI가 고용에 영향을 줬다는 응답은 아직 적고, 감소와 증가가 함께 나타난다.
생산성 실험은 조금 다른 그림을 보여 준다. 고객 지원, 코딩, 글쓰기, 법률 업무에서 생성형 AI가 작업 속도를 높인 결과가 있지만, 효과는 직무와 숙련도에 따라 크게 달랐다. 콜센터 실험에서는 저숙련 상담원의 개선 폭이 컸고, 숙련 상담원은 이득이 작거나 품질이 소폭 떨어졌다. 소프트웨어 개발에서도 실험 환경과 기업에 따라 효과 크기가 달랐다. 특정 작업의 시간이 줄었다는 결과를 회사 전체 생산성이나 필요한 인원 감소로 바로 바꾸면 안 되는 이유다. 병목이 다른 공정으로 이동하고, 검토 비용과 조직 재설계가 새로 생길 수 있다.
그래도 초기 경력 노동자는 별도로 봐야 한다. 일부 연구에서는 소프트웨어 개발과 고객 지원처럼 AI 노출이 높은 직종에서 젊은 노동자의 고용과 채용이 약해진 반면, 같은 직종의 고연령 노동자는 상대적으로 안정적이었다. 다만 금리 인상, 팬데믹 시기 과잉 채용, 경기 둔화가 같은 시기에 겹쳤고 감소가 ChatGPT 공개 전부터 시작된 자료도 있다. 인과를 확정하기에는 아직 이르다. 내가 실무에서 더 현실적인 신호로 보는 것은 대규모 해고 발표보다 주니어가 맡던 작은 업무가 줄고, 첫 직무로 진입하는 사다리가 짧아지는가다. 총고용이 유지돼도 학습 경로가 사라지면 몇 년 뒤 숙련 인력의 구성은 달라질 수 있다.
4. LLMs Get Lost in Evolving User Intent: 정답을 알아도 바뀐 요구를 놓치는 모델
LLMs Get Lost in Evolving User Intent는 협업형 에이전트 평가의 빈틈을 다룬 프리프린트다. 기존 벤치마크는 사용자가 처음부터 완성된 요구를 한 번에 전달한다고 가정하는 경우가 많다. 실제 작업에서는 “보고서를 만들어 달라”로 시작했다가 대상 독자를 좁히고, 표의 기준을 바꾸고, 중간 결과를 본 뒤 우선순위를 수정한다. 마지막 요청이 첫 요청과 충돌하는 일도 드물지 않다. 모델이 각 문장을 이해하는 것과 대화 전체에서 현재 유효한 의도를 유지하는 것은 다른 능력이다.
연구진은 새로운 과제를 전부 다시 만드는 대신 기존 단일 턴 과제를 동적인 다중 턴 대화로 변환했다. 사용자 의도가 순서대로 공개되는 경우, 앞선 요구가 수정되는 경우, 작업 방향이 중간에 바뀌는 경우를 만들면서 원래 평가 프로토콜은 유지했다. 이렇게 하면 정적 조건과 변화하는 의도 조건의 차이를 비교할 수 있다. 저자들은 여러 과제와 모델 계열에서 정적 설정의 강한 성능이 동적 설정으로 그대로 이어지지 않았고, 성능 하락이 일관되게 나타났다고 보고한다.
이 결과를 ‘컨텍스트 창이 부족하다’로만 읽으면 해결책을 놓친다. 긴 대화에는 최신 지시, 아직 유효한 제약, 폐기된 요구, 새로 생긴 결정이 함께 들어 있다. 단순히 모든 메시지를 다시 넣으면 서로 충돌하는 문장도 같이 살아난다. 에이전트에는 현재 작업 계약을 별도 상태로 갱신하고, 요구가 바뀐 지점에서 영향받는 산출물과 도구 실행을 다시 계산하는 장치가 필요하다. 중요한 변경은 사용자에게 재확인하고, 이미 수행한 외부 작업은 되돌릴 수 있는지도 알려야 한다. 기억을 많이 보존하는 것보다 어떤 의도가 지금 유효한지 판별하는 상태 관리가 협업 품질을 가른다.
평가 방식에도 같은 구분이 필요하다. 최종 답 하나만 채점하면 모델이 중간 수정 요청을 놓쳤는지, 오래된 조건을 되살렸는지, 새 조건을 반영했지만 실행 결과를 갱신하지 않았는지 알기 어렵다. 의도 변화가 발생한 턴, 상태 갱신 결과, 수정 뒤 다시 실행한 도구, 최종 산출물의 제약 충족 여부를 나눠 기록해야 실패 원인을 설명할 수 있다. 정적인 정답률 옆에 변경 추적과 수정 전파를 별도 지표로 둘 이유다.
네 소식은 서로 반대 방향의 크기를 다루지만 결론은 비슷하다. Sprites는 에이전트의 디스크와 권한을 오래 유지하는 법을 묻고, ESP32 실험은 작은 메모리에서 필요한 가중치만 불러오는 법을 보여 준다. 노동시장 분석은 작업 단위의 속도 향상과 고용 전체의 변화를 분리하고, 변화하는 의도 연구는 과거 대화와 현재 작업 계약을 구분한다. AI 시스템이 실제 환경에 들어갈수록 성능표 하나보다 무엇을 유지하고, 무엇을 분리하며, 변화가 생겼을 때 어디까지 다시 계산하는가가 더 중요한 설계 변수가 된다.