🤖
1243 in / 3855 out / 5098 total tokens
🔥 핫 토픽
Our AI started a cafe in Stockholm
Simon Willison이 공유한 이 글은 AI가 자율적으로 스톡홀름에 카페를 열었다는 실험적 프로젝트를 다루고 있다. 물리적 세계에 AI 에이전트가 개입하여 실제 비즈니스를 운영하는 사례다. 단순히 챗봇이나 추천 시스템 수준을 넘어, AI가 의사결정 주체로서 현실 세계에 행동을 취하는 것이다. 이는 곧 AI 에이전트의 자율성 한계와 책임 소재에 대한 근본적인 질문을 던진다.
게임 개발자 시각에서 보면, NPC의 행동 트리나 GOAP(Goal-Oriented Action Planning)를 현실에 구현한 셈이다. 게임에서는 NPC가 세계에 행동해도 리셋 버튼이 있지만, 현실에는 그게 없다. AI 에이전트가 외부 API를 호출해 실제 결제를 하고, 계약을 체결하는 아키텍처는 게임 서버가 외부 결제 시스템과 연동되는 구조와 유사하다. 다만 게임 서버는 트랜잭션 실패 시 롤백이 가능하지만, 현실의 AI 에이전트는 그렇지 않다는 게 핵심 차이다.
이 실험이 업계에서 주목받는 이유는, AI 에이전트의 행동 반경이 디지털 영역을 넘어선 첫 사례 중 하나이기 때문이다. 기존의 AI 비서는 사용자의 명령을 수행하는 도구였다면, 이 카페 프로젝트는 AI가 주체적으로 목표를 설정하고 실행한 사례다. 경쟁 구도에서도 OpenAI, Anthropic 등이 발표하는 "AI 에이전트" 비전이 실제로 어느 정도 실현 가능한지 보여주는 벤치마크가 된다.
실무 개발자에게 이 사례는 AI 에이전트 설계 시 안전장치(safety guardrails)의 중요성을 일깨운다. 게임에서 플레이어가 버그를 악용해 경제를 붕괴시키는 것을 막기 위해 서버 측 검증을 하는 것처럼, AI 에이전트도 행동 전 사전 승인(pre-approval) 단계를 두거나 행동 범위를 샌드박스로 제한해야 한다. 이 카페 프로젝트가 성공이든 실패든, AI 에이전트가 물리적 세계와 상호작용할 때 발생하는 예외 케이스들을 정리한 사례 연구로 활용 가치가 높다.
한 가지 흥미로운 점은 이 프로젝트가 "AI가 시작했다"는 표현을 쓴다는 것이다. 실제로는 인간이 설정한 파라미터와 제약 내에서 AI가 최적화를 수행한 것일 수도 있다. 이 구분은 중요하다. 게임으로 치면, AI 디렉터가 이벤트를 트리거하는 것과 플레이어가 직접 선택하는 것의 차이와 같다. 전자는 연출이고 후자는 에이전시다. 이 프로젝트가 어느 쪽에 가까운지는 전체 아키텍처를 봐야 알 수 있다.
출처: Simon Willison
📰 뉴스
datasette-referrer-policy 0.1
Simon Willison이 자신의 오픈소스 프로젝트인 Datasette에 새 플러그인을 추가했다. datasette-referrer-policy는 HTTP 응답 헤더에 Referrer-Policy를 설정하는 간단한 유틸리티다. 겉보기엔 사소한 업데이트지만, AI 시대에 웹 보안 기본기가 왜 중요한지를 보여준다.
Referrer-Policy는 브라우저가 다른 사이트로 이동할 때 어느 정도의 URL 정보를 전달할지 제어하는 HTTP 헤더다. 예를 들어, Referrer-Policy: no-referrer로 설정하면 외부 링크 클릭 시 참조 URL을 아예 보내지 않는다. 이는 사용자 프라이버시 보호뿐 아니라, 내부 API 엔드포인트가 외부에 노출되는 것을 막는 효과도 있다.
AI 애플리케이션 개발자에게 이게 왜 중요한가. 많은 AI 도구가 웹 기반 인터페이스를 제공하며, 종종 내부 API 키나 세션 토큰이 URL에 포함되기도 한다. LLM 기반 챗봇이 생성한 공유 링크에 사용자의 프롬프트가 그대로 포함된다면, 그 링크를 클릭한 외부 사이트는 사용자의 대화 내용을 Referrer 헤더로 받아볼 수 있다. 게임 개발에서도 유사한 사례가 있다. 웹 기반 게임 클라이언트에서 API 호출 시 인증 토큰이 Referer 헤더로 유출되는 취약점은 꽤 흔하다.
Datasette 자체는 데이터 탐색 및 공유 도구다. CSV, JSON, SQLite 파일을 웹 인터페이스로 탐색하고 쿼리할 수 있게 해준다. AI 파이프라인에서 전처리된 데이터를 빠르게 검증하거나, RAG 시스템의 청킹 결과를 시각적으로 확인할 때 유용하다. 이런 도구에서 Referrer-Policy가 중요한 이유는, Datasette가 종종 사내 데이터에 접근하는 데 사용되기 때문이다. 사내 Datasette 인스턴스에서 외부 링크를 클릭했을 때 내부 URL 구조가 노출되면 보안 위험이 된다.
이 플러그인의 출시는 더 넓은 맥락에서 "AI 프로젝트에서 보안은 나중에 생각할 문제가 아니다"라는 메시지를 준다. 게임 개발에서도 초기에 보안을 고려하지 않으면 나중에 엄청난 기술 부채가 된다. 필드의 경험상, 프로토타입 단계에서부터 CORS, CSP, Referrer-Policy 같은 기본 보안 헤더를 설정해두는 습관이 장기적으로 큰 차이를 만든다.
출처: Simon Willison
🔗 두 뉴스의 연결고리
이 두 소식은表面上 별 관련이 없어 보이지만, "AI 시스템이 외부 세계와 상호작용할 때의 책임"이라는 공통 주제를 공유한다. 카페 프로젝트는 AI가 물리적 세계에 행동할 때의 책임 문제를, Referrer-Policy 플러그인은 AI 도구가 웹 생태계와 상호작용할 때의 정보 유출 방지를 다룬다. 둘 다 "AI 시스템의 경계에서 무엇이 새어나가는가"라는 질문과 연결된다.
앞서 언급한 카페 프로젝트의 AI 에이전트도 웹 인터페이스를 통해 외부 서비스와 통신할 것이다. 그 통신 과정에서 Referrer 헤더로 인해 내부 API 구조가 노출된다면, 에이전트의 행동이 의도치 않게 공개될 수 있다. 게임 서버 아키텍처에서도 비슷하게, 클라이언트-서버 통신 시 불필요한 메타데이터가 노출되면 핵(user exploit)의 단서가 된다. 보안은 계층(layer)별로 쌓아야 한다.
AI 에이전트의 자율성이 높아질수록, 그 에이전트가 세계와 만나는 경계면에서의 보안과 통제는 더 중요해진다. 화려한 AI 데모 뒤에는 항상 HTTP 헤더 하나의 설정이 숨어있다.