푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 889편 · 1 / 89 페이지)
-
지시 파일은 설득이고, 통제는 강제다 — 하네스 5종 비교와 자유도의 6개 축
4a 실습 글은 한 샌드박스 안에서 잠금 장치들을 실측하는 데서 끝났다. 이번 정리는 시야를 넓힌다 — 지금 쓰이는 하네스 5종이 각자 어떤 파일로 지시받고 어떤 층으로 통제되는지, 그리고 통제를 6개 축으로 쪼갰을 때 “자유도 = 공격 표면”이라는 등식이 어떻게 성립하는지다.
-
Module 4a 완료 기록: OpenShell 학습과 에이전트 실행 경계 검증
Module 4a 완료 기록: OpenShell 학습과 에이전트 실행 경계 검증
-
막힌 것 넷보다, 안 막힌 것 둘이 중요하다 — 샌드박스 실습 정리 한 장
바로 앞 글에서 표 한 장을 커널 문서로 되짚었다. 네 가지 OS 메커니즘 — netns, Landlock, seccomp, non-root — 이 각각 어떤 질문에 답하는지까지가 그 글이었다. 그건 설계도였다.
-
샌드박스는 세웠다, 그래도 구멍은 둘 남는다 — 정책 격리 실습(4a)이 눈으로 보여준 것
앞선 검증 실험은 서늘한 질문 하나로 끝났다 — 스스로를 고칠 수 있는 시스템에서, 승인은 어디에 있는가. 이번 4a 실습은 그 질문에 대한 교과서적 답, 즉 정책을 에이전트가 만질 수 없는 곳(커널·네트워크 층)에 두는 구조를 직접 확인한 기록이다. 그리고 정직하게도, 그렇게 다 세운 뒤에도 열려 있는 실패 모드 두 개를 눈으로 보는 데서 끝난다. 이 두 구멍이 이 글의 본론이다.
-
네 줄 다 ✓ 인데 모델이 틀렸다 — 샌드박스 egress 허용목록 검증표 읽는 법
샌드박스 밖으로 나가는 연결 네 개를 정책 파일을 보고 먼저 예측한 다음, 실제로 쳐보고 결과를 적은 표다. 세 번째 칸은 네 줄 모두 ✓ 다.
-
네 가지 OS 메커니즘, 네 가지 검증 가능한 질문 — 표 한 장을 커널 문서로 되짚다
오늘 네 편을 쓰는 동안 같은 결론이 계속 돌아왔다. 정책은 에이전트가 만질 수 없는 곳에 둬야 한다. 브라우저 자바스크립트에 있던 가드레일도, 워크스페이스의
POLICY.md도 같은 이유로 실패한다. -
OpenClaw·OpenShell·NemoClaw 비교: 에이전트 판단·보안 런타임·운영 스택
OpenClaw·OpenShell·NemoClaw 비교
-
도구 0회가 증명하는 것 — OpenClaw 에이전트 검증 실험 로그 6줄 읽기
에이전트가 “제 워크스페이스엔 파일이 7개 있어요”라고 말하면, 그걸 어떻게 믿나. 답은 하나다 — 에이전트 밖에서 같은 사실을 실측해서 대조한다. 아래 표는 샌드박스에 올린 OpenClaw 를 상대로 그 대조를 단계별로 돌린 실험 로그다. 여섯 줄이지만, 에이전트 런타임을 검증하는 방법론과 마지막 줄의 서늘한 발견까지 담겨 있다.
-
표의 '세션' 칸은 기억을 뜻하지 않는다 — 실행 메커니즘 넷이 각각 버리는 것
에이전트의 실행 메커니즘 네 가지를 한 장에 정리한 표를 받았다.
-
도구 호출 0회가 증거다 — 에이전트 실습을 검증 로그로 바꾼 표 한 장
오늘 이 블로그에 같은 실습에서 나온 글이 두 편 올라갔다 — 워크스페이스 문서들의 역할과 에이전트가 자기 파일 일곱 개를 설명한 이야기. 둘 다 무엇이 있는가를 썼다.