에이전트가 방금 내 시스템에서 뭘 했지? — OpenClaw가 Activity 탭으로 답한 방법

오픈소스 개인 AI 어시스턴트 OpenClaw를 집 서버에 올려 쓰다 보면 묘하게 불편한 순간이 온다. 에이전트에게 "이 폴더 정리해 줘" 한마디를 던졌는데, 그 한마디가 내부에서는 셸 명령 실행, 파일 읽기·쓰기, 외부 웹 호출 수십 건으로 풀린다. 화면에는 친절한 답변만 돌아오고, 정작 내 시스템에서 무슨 명령이 돌고 어떤 파일이 건드려졌는지는 보이지 않는다. OpenClaw Control UI(게이트웨이를 브라우저로 조작하는 관리 화면)의 Activity 탭은 바로 이 "방금 뭘 했지?"라는 질문에 답하려고 만들어졌다. 이 글은 그 문제와 OpenClaw가 고른 답을 따라간다.

배경 — 에이전트는 내 시스템을 직접 만진다

단순한 챗봇이라면 텍스트만 주고받으니 추적할 게 없다. 하지만 도구를 쓰는 AI 에이전트는 다르다. 사용자 요청 한 건이 내부에서 여러 개의 도구 호출(tool call — 에이전트가 셸·파일·네트워크 같은 실제 기능을 부르는 단위 동작)로 펼쳐진다. OpenClaw에서 이런 도구 호출은 게이트웨이가 session.tool 이벤트(도구 하나가 시작·진행·종료할 때마다 게이트웨이가 흘려보내는 신호)로 알려 준다.

다이어그램 설명. 이 그림은 사용자의 자연어 요청 한 줄이 실제로는 여러 갈래의 시스템 동작으로 갈라진다는 걸 보여준다. 맨 위 요청이 에이전트를 거쳐 셸 명령 실행, 파일 작업, 웹 호출로 나뉘고, 각각이 일어날 때마다 게이트웨이가 하나의 공통 이벤트 줄기로 그 사실을 흘려보낸다. 핵심은 "보이는 답변 한 줄 뒤에 보이지 않는 동작 여러 개가 숨어 있다"는 점이다 — 그래서 그 동작들을 따로 모아 보여줄 화면이 필요해진다. 흔히 하는 오해는 "챗봇이니 로그 볼 게 없다"는 가정인데, 도구를 쓰는 에이전트는 사실상 내 컴퓨터에서 명령을 대신 치는 작업자에 가깝다.

그래서 이게 사용자에게 주는 가치는 분명하다 — 에이전트가 내 시스템 권한으로 무언가를 할 때, 그 "무언가"를 사람이 눈으로 확인할 통로가 생긴다.

핵심 문제 — 추적은 필요한데, 추적 기록 자체가 새 위험이다

"그럼 모든 도구 활동을 다 기록해서 보여주면 되지 않나?" 싶지만, 순진하게 만들면 세 가지가 동시에 터진다.

다이어그램 설명. 이 그림은 활동을 무턱대고 다 기록할 때 갈라지는 세 가지 실패를 보여준다. 첫째, 도구가 주고받는 값에는 API 키, 비밀번호, /home/사용자명/... 같은 시스템 경로가 섞여 있어 그대로 화면에 띄우거나 저장하면 그 추적 기록이 곧 새로운 정보 유출 통로가 된다. 둘째, 활동을 위해 별도 데이터베이스나 새 이벤트 종류를 게이트웨이에 추가하면 "감시하려고 만든 기능이 감시당해야 할 표면을 늘리는" 모순이 생긴다. 셋째, 며칠씩 켜 두는 개인 서버 특성상 이벤트는 멈추지 않고 쌓여 결국 브라우저 탭이 느려진다. 셋 중 가장 놓치기 쉬운 함정은 첫째다 — "내 화면이니 다 보여도 되겠지" 싶지만, 브라우저 화면에 박힌 토큰은 화면 공유·스크린샷 한 장으로 새어 나간다.

즉 진짜 문제는 "활동을 보여주기"가 아니라 "위험을 새로 만들지 않으면서 활동을 보여주기"다. 추적 도구가 또 다른 보안·운영 부담이 되면 안 된다는 게 핵심 제약이다.

해결 방법 — 기존 이벤트를 재사용하고, 서버·브라우저 이중 redaction을 거쳐 임시 표시

OpenClaw의 답은 세 가지 설계 결정으로 요약된다. (1) 새 데이터 줄기를 만들지 않고 Chat 탭이 이미 쓰던 session.tool 이벤트를 그대로 재사용한다. (2) 활동 목록은 게이트웨이에 따로 저장하지 않고 브라우저 메모리 안에서만 들고 있는다. (3) 민감정보는 서버가 이벤트를 내보내기 전에 먼저 [redacted]로 가리고, 브라우저가 화면에 올리기 전에 한 번 더 거른다 — 이중 방어다. 여기에 출력 길이 자르기까지 더한다. "관찰 전용, 기록 최소, 수명 짧게"가 한 줄 요약이다.

다이어그램 설명. 이 그림은 도구 활동 하나가 화면에 닿기까지의 처리 사슬을 보여준다. 이벤트는 이미 서버가 토큰·비밀번호를 1차로 가린 채 도착하고, 브라우저는 그 값을 받아 한 번 더 거른 뒤, 출력은 2000자로 자르고 인자 값은 아예 저장하지 않은 채 개수만 센다. 이렇게 다듬은 항목을 최대 100건만 메모리에 들고 있다가 화면에 요약으로 보여주고, 점선처럼 새로고침·세션 전환·Clear 중 무엇이든 일어나면 통째로 사라진다. 이 패턴이 좋은 이유는 앞서 본 세 문제를 한 번에 막기 때문이다 — 기존 이벤트 재사용으로 인프라 비대(문제 2)를, redaction으로 정보 유출(문제 1)을, 100건 상한과 휘발성으로 무한 누적(문제 3)을 동시에 끊는다. 놓치기 쉬운 점은 redaction이 한 곳이 아니라 두 곳에서 일어난다는 사실이다 — 서버가 이벤트를 내보내기 전에 먼저 가리고, 브라우저가 화면에 올리기 전에 한 번 더 가린다. 그러면서도 게이트웨이에는 활동을 쌓아 두는 전용 저장소가 새로 생기지 않는다 — redaction은 기존 로깅 경로를 재사용할 뿐이고, 활동 목록 자체는 브라우저 메모리에만 머문다.

왜 게이트웨이가 아니라 브라우저에 두는가 — 두 방식 비교

이 결정이 왜 중요한지는 "활동을 어디에 저장하느냐"를 두 방식으로 나란히 놓고 보면 분명해진다.

▲ 방식 A — 서버에 따로 저장하는 길

다이어그램 설명. 이 그림은 가장 흔히 떠올리는 길 — 게이트웨이 쪽에 활동 전용 저장소를 두는 방식이다. 새 이벤트 종류와 데이터베이스를 만들고 서버에 활동 로그를 영구히 쌓는데, 그 결과 로그 자체가 다시 보호·용량·만료 정책을 요구하는 관리 대상이 된다. 함정은 "서버에 남기면 안전하고 영구적이라 좋다"는 통념이다 — 개인 서버에서는 오히려 영구 로그가 유출 위험과 디스크 압박을 키운다.

▲ 방식 B — 브라우저 안에서만 임시로 보는 길

다이어그램 설명. 이 그림은 OpenClaw가 실제로 택한 길이다. 서버에 아무것도 새로 만들지 않고 이미 흐르던 이벤트를 받아, 민감정보를 가린 다음 메모리에 100건만 들고 있다가 탭을 닫으면 그대로 잊는다. 두 방식을 같은 축에서 비교하면 차이가 분명하다 — 서버에 저장하는 길은 추적을 위해 새로운 영구 자산을 만들어 관리 부담을 늘리고, 브라우저에 두는 길은 추적을 일회용 관찰로 가둔다. "방금 뭘 했지?"는 대개 지금 이 순간의 질문이라, 한 시간 전 기록을 영구 보관할 이유가 거의 없다는 통찰이 이 선택의 바탕이다.

redaction은 정확히 무엇을 가리는가

아래 다섯 갈래는 브라우저 표시 레이어가 출력 미리보기 텍스트에서 거르는 패턴이다. 다만 이 중 인증 헤더·Bearer·키/토큰/비밀번호·사설키 같은 진짜 비밀값은 서버가 이벤트를 내보내기 전에 이미 한 번 가린 상태로 도착하고, 브라우저는 같은 패턴으로 한 번 더 확인한다. 무엇을 가리는지가 곧 "이 추적기가 새 유출 통로가 되지 않는다"는 약속의 실체다.

다이어그램 설명. 이 그림은 도구 출력 원문이 다섯 갈래의 가리기 규칙을 거쳐 안전한 미리보기로 바뀌는 과정을 보여준다. 인증 헤더, Bearer 토큰, 키·토큰·비밀번호처럼 보이는 값, 사설키 블록, 그리고 /home/...·/Users/... 같은 절대경로가 각각 [redacted] 계열로 치환된 뒤 한곳으로 모인다. 이 패턴이 중요한 이유는, 도구 활동에서 새는 정보의 대부분이 바로 이 다섯 종류이기 때문이다. 놓치기 쉬운 함정은 마지막 경로 가리기다 — 단순한 비밀이 아니라 /home/사용자명/ 같은 경로조차 사용자 계정명을 노출하므로 함께 가린다. 그리고 이 경로 가리기는 다른 넷과 달리 브라우저 표시 시점에만 항상 적용된다 — 그래서 경로는 redaction되기 전 상태로 브라우저까지 도달했다가 화면에 닿는 순간 가려진다. 다만 이건 표시용 정규식 기반 가리기라, 형식이 특이한 비밀까지 100% 잡는다고 가정하면 안 된다 — 그래서 인자 값은 아예 저장조차 하지 않는 이중 안전장치를 둔다.

활동 한 건의 수명 — 시작에서 종료까지 한 줄로 합쳐진다

같은 도구 호출이 시작·진행·종료하며 이벤트를 여러 번 보내는데, Activity 탭은 이걸 따로따로 늘어놓지 않고 호출 한 건당 한 줄로 묶어 상태만 갱신한다.

다이어그램 설명. 이 그림은 도구 호출 하나가 화면에서 한 줄로 관리되는 흐름을 보여준다. 새 이벤트가 오면 먼저 그 호출이 이미 목록에 있는지 확인해, 없으면 진행 중 상태로 새 줄을 만들고 있으면 기존 줄의 상태와 시간만 덮어쓴다. 종료 신호가 오면 정상 종료는 완료로, 에러 표시나 0이 아닌 종료코드는 실패로 갈린다. 이렇게 묶는 이유는, 같은 호출의 시작·진행·종료를 별도 줄로 늘어놓으면 목록이 금세 지저분해지기 때문이다 — 호출 식별자로 묶어 한 줄을 갱신하면 "지금 무엇이 돌고 있고 무엇이 끝났나"가 한눈에 잡힌다. 놓치기 쉬운 점은 실패 판정 기준인데, 명시적 에러 표시뿐 아니라 0이 아닌 종료코드만으로도 실패로 본다 — 셸 명령이 조용히 비정상 종료해도 빨간 상태로 드러난다.

쌓인 활동을 다루는 도구 — 필터·검색·따라가기

최대 100건이 쌓이면 그중 원하는 것만 골라 보는 장치가 필요하다. Activity 탭은 검색창, 도구별 필터, 상태 필터(running·done·error), 그리고 새 활동을 자동으로 따라 내려가는 auto-follow를 제공한다.

다이어그램 설명. 이 그림은 쌓인 활동을 좁혀 보는 세 가지 필터와 따라가기 장치를 보여준다. 같은 목록에 검색어·도구별·상태별 필터가 각각 걸리고, 셋을 통과한 항목만 화면에 남는다. 그 아래 갈림길은 새 활동이 도착했을 때의 동작인데, 따라가기를 켜면 자동으로 맨 아래로 내려가 최신 활동을 보여주고, 끄면 지금 읽던 자리를 지킨다. 이 구성이 좋은 이유는 두 가지 상반된 욕구를 모두 받아 주기 때문이다 — 실시간으로 흘러가는 활동을 지켜보고 싶을 때(따라가기 켬)와, 특정 과거 활동을 붙잡고 들여다볼 때(따라가기 끔)가 한 화면에서 전환된다. 함정은 검색이 인자 값까지 뒤지지는 못한다는 점이다 — 인자는 저장하지 않으니 검색 대상은 도구명·redaction된 출력·식별자에 한한다.

결과 — 무엇이 좋아졌나

이 설계로 앞서 본 "추적은 필요한데 추적이 새 위험"이라는 딜레마가 이렇게 정리된다.

순진한 활동 추적기	OpenClaw Activity 탭
도구 인자·출력의 토큰·경로가 그대로 노출	출력은 서버·브라우저 이중 redaction 후 표시, 인자 값은 저장조차 안 함(개수만)
새 이벤트·전용 DB·외부 관찰 스트림 추가	기존 session.tool 이벤트 재사용 — 게이트웨이에 새 표면 0
장시간 켜 두면 무한 누적	메모리 100건 상한 + 새로고침·세션전환·Clear 시 휘발
같은 호출이 여러 줄로 흩어져 지저분	호출 식별자로 한 줄에 묶어 상태만 갱신

정리하면, Activity 탭은 "에이전트가 내 시스템에서 한 일을 사람이 그 자리에서 확인하되, 그 확인 행위가 새로운 위험을 만들지 않게" 설계됐다. 셸 명령이 무엇이 돌았는지, 어떤 파일이 건드려졌는지, 어떤 웹 호출이 나갔는지를 실시간으로 훑어볼 수 있으면서도, 그 기록은 토큰을 가린 채 브라우저 안에서만 잠깐 살다 사라진다. 도구를 쓰는 에이전트에게 화려한 기능보다 먼저 필요한 건 이런 "투명성과 절제의 균형"이다 — 내가 무엇을 시켰고 그게 내 시스템에서 실제로 무엇을 했는지를 볼 수 없다면, 에이전트에게 권한을 맡기는 일 자체가 불안해지기 때문이다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.