[실밸개발자] 바이브코딩 클럽

EXECUTIVE SUMMARY

오늘의 흐름을 먼저 한 번에 보기

요약2026-07-07 [실밸개발자] 방은 유효 텍스트 341건, 발화자 80명, 링크 8건으로 중간 밀도의 하루였습니다. 오전에는 Fable 종료와 Claude Code 역사 링크, 낮에는 TDD hooks·인터랙티브 스토리·혈당 앱 아이디어, 오후에는 Fable 비용/라우팅과 서버 로그 보안 런북, 밤에는 에이전트 메모리 하네스와 Sub Agent 권한/캐시 운영이 핵심 흐름이었습니다.

구성

Main 5 · Mini 4 · Watch 3

대화량

메시지 341건 · 발화자 80명 · 링크 8건

카테고리

모델 비용·라우팅 1보안·운영 런북 1에이전트 메모리·하네스 1Sub Agent 권한·캐시 운영 1팀 표준·하네스 채택 1TDD·테스트 1창작 AI·스토리 구조 1개인 앱·데이터 1배포·크로스플랫폼 1모델 전망 1도구 공유 1UI 테스트 1

핵심 카드 빠르게 보기

Fable 구독 종료 D-1은 “막차를 어디에 쓸 것인가”라는 비용·라우팅 토론으로 번졌다
nginx·PM2 로그가 조용해도 안전하다는 뜻은 아니라는 서버 침해 점검 런북이 만들어졌다
30일 뒤 사라지는 세션을 영구 보존하고 self-improve로 되돌리는 agy-harness 설계가 공유됐다
Sub Agent 권한 주입과 모델 전환 캐시는 “부모 권한을 그대로 믿지 말라”는 운영 질문으로 수렴했다
팀 표준 하네스와 AWS AIDLC 비교는 “외부 범용성 vs 내부 규격화”의 의존성 판단으로 정리됐다

Fable 구독 종료 D-1은 “막차를 어디에 쓸 것인가”라는 비용·라우팅 토론으로 번졌다

한줄 결론Fable 막차 논의의 본질은 모델 성능이 아니라 “비싼 판단은 어디까지 쓰고, 구현은 어디로 넘길지”였습니다.

왜 중요했나하루의 가장 넓은 흐름은 Fable이 7월 8일 오후 4시 이후 구독제에서 빠지고 API/추가 과금으로 이동한다는 신호였습니다. 단순 종료 알림이 아니라, 5x/20x 한도, API 환산 비용, 계획은 Fable·실행은 Sonnet/Opus/Codex로 나누는 라우팅 기준까지 이어졌습니다.

무슨 일이 있었나

발단은 오전에 Fable 사용 가능 시점이 공유되면서 시작됐습니다. 이후 방 안에서는 무료 종료인지, 구독제 종료인지, 내일 오후 4시까지인지가 여러 차례 확인됐고 사용량 초기화·플랜 업그레이드 체감까지 붙었습니다.

응답은 “지금 아니면 이 정도 속도로 못 뺀다”는 실제 사용자의 소비 패턴으로 구체화됐습니다. 하루에 max20을 하나씩 끊는 사례, 5시간 세션과 주간 한도, 워커를 Fable로만 돌릴 때의 소모량이 함께 논의됐습니다.

전개에서 중요한 판단은 모델 역할 분리였습니다. 계획과 고난도 판단은 Fable/Opus로 하고, 구현은 Sonnet·Opus·Codex 워커로 넘기자는 쪽입니다. 밤에는 캐시 관점에서 모델을 바꾸면 전체 컨텍스트를 다시 읽을 수 있지만, 큰 작업에서 비싼 모델로 구현까지 계속하는 손해가 더 크다는 설명이 나왔습니다.

실무 결론은 “좋은 모델을 오래 붙잡기”보다, 마감·한도·캐시·작업 역할을 같이 보고 라우팅하는 것입니다. 지수님 관점에서는 Hermes 모델 운영에서도 계획/검토/구현/워커 비용을 분리해 기록해야 특정 구독 이벤트에 과의존하지 않습니다.

용어 쏙쏙 3개

Fable방에서 고성능 Claude 계열 모델로 지칭한 모델
20x MaxClaude 사용량 상위 플랜
캐시이미 읽은 컨텍스트를 재사용해 토큰 비용을 줄이는 구조입니다

추적 방 발언 기준

지수님 포인트

Hermes 모델 라우팅 로그에 “계획/구현/검토 모델과 비용 이벤트”를 같이 남길 후보입니다.

왜 이 액션인가

모델 접근 정책 변화가 실제 작업 비용과 라우팅 기준을 바꿉니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Follow-up

next-review — Hermes 모델 라우팅 로그에 “계획/구현/검토 모델과 비용 이벤트”를 같이 남길 후보입니다.

Wikipatterns/model_routing_costs.md

Cross-room hooksFablemodel routingcache

카카오톡 방 대화 원문 기준입니다.

대화 원문 8개 보기

08:44조이/클코
페이블 7월 8일 오후 4시까지 사용가능하다네요.
09:01실밸/클코
7월 8일 오후 4시 이후로는 사용이 불가한가요?ㅠ
13:57자랑하는 라이언 / 클코
지금 하루에 max20 하나씩 끊고 있네요...
14:05하품하는 죠르디
페이블 20x 맥스 기준으로 5시간 2.5세션이면 끝나긴합니다
14:11하품하는 죠르디
5시간 세션한도이 있는데 페이블로만 전부 작업하는 경우 페이블 한도 약 40프로 가까이 찰때 5시간 한도가 다차더라구요.
16:39아웃라이너/클코덱스
내일 이후로는 구독제 지원 안되고 api로만 지원한다고 하니.. 내일까지 말씀이신가요?
18:42대짱이/코덱스
그러면 보통 계획은 fable한테 .md 같은 문서로 만들어달라하고 실행은 opus 4.8로 돌리는 방식으로 다들 많이 하시나요??
23:23이라페/클코,코덱스
캐시 관련해서는 제가 이해한 내용을 토대로 도와드리자면 1번 프롬프트 초기context(claude.md, handoff와 같이 세션을 처음 열었을때 읽는것) - 전부 읽고 캐시에 저장 2번 프롬프트 1번 프롬프트(캐시로 재사용 - 1/10 비용)+추가된 부분만 처리 3번 프롬프트 반복 결국 중요한건 현재 열린 세션에서 - 모델을 바꾸면 - 캐시로 읽는게 아니라 전체를 다시 읽는다 = 토큰비용 근데 이건 결국 현재 context가 어느정도인지가 중요한것같아요 최고의 방법은 고지능 plan모드 계획서작성 - 핸드오프 - 커밋 - 새세션 - sonnet 구현 < 이게 베스트지만 이미 세션안에서 대화가 많지 않은 상태라면, 그냥 계획서 작성 - sonnet으로 변경해서 바로 구현해도 괜찮다고 생각하고 있습니다 그 이유를 조금 추가설명해드리자면 저는 작업에서 모델을 선택하는 기준은 모델에게 어느정도의 판단력을 요구할것인가를 기준으로 생각하고 있는데, fable, opus같은 모델로 계획서를 작성했다면 이미 판단의 영역은 fable과 opus가 다 해놨기 때문에 fable, opus로 계속 구현하는것보다 sonnet으로 구현하는게 전체 대화를 다 읽어서 생긴 손해보다 (훨씬)작다고 생각해요 - 계획서를 작성할 정도의 구현작업이라면 이미 규모가 크다는거니까요ㅎㅎ.. 그걸 fable, opus로 계속 구현하면 ..어후.. 실제로 저도 좀전에 fable5로 계획서 작성하라고 auto누르고 담배피고왔다가 승인인걸 뒤늦게 깨닫고 작성하던것까지만 하고 멈추라고 한다음에 바로 sonnet으로 바꿨습니다.. fable로 구현하는건 정말 아닌것같아용.,,,

nginx·PM2 로그가 조용해도 안전하다는 뜻은 아니라는 서버 침해 점검 런북이 만들어졌다

한줄 결론“로그가 없다”는 결론이 아니라 “어느 계층 로그를 보고 있나”를 묻는 출발점입니다.

왜 중요했나오후의 보안 흐름은 “공격자가 접속했는데 nginx/pm2 로그가 안 남을 수 있나”라는 질문에서 시작해, 네트워크·시스템·애플리케이션 계층을 분리해 확인하는 런북으로 확장됐습니다.

무슨 일이 있었나

발단은 서비스 오픈 후 보안 로그가 보이지 않는다는 질문이었습니다. 질문자는 실시간 로그라면 지우기는 어렵다고 가정했지만, 답변자들은 먼저 로그가 없는 것이 곧 접근이 없다는 뜻은 아니라고 선을 그었습니다.

응답은 계층별로 갈라졌습니다. nginx access log는 정상 HTTP 요청 처리 기준이고, PM2 로그는 앱 stdout/stderr일 뿐이라 앱이 요청 로그를 안 찍으면 조용할 수 있습니다. SSH, 직접 포트, VNC/관리 패널, 리버스셸, Docker 포트 우회처럼 nginx를 거치지 않는 경로도 지적됐습니다.

전개에서는 즉시 확인 명령이 붙었습니다. nginx 설정·access/error log·pm2 log·auth.log·journalctl·ss·who·ps를 확인하고, Docker iptables와 IPv6까지 보라는 구체 목록입니다. 서버 포트 22/80/443을 닫았다는 설명에는 “닫은 것은 인바운드 통로일 뿐, 봇 코드 취약점·키 유출·호스팅 패널은 별도”라는 반론이 달렸습니다.

실무 결론은 로그 부재를 안심 신호로 쓰지 말고, 경로별 관측 지점을 만들어야 한다는 점입니다. 지수님 적용점은 Hermes/브리핑/봇 서버 운영에서 nginx·앱·시스템·클라우드 패널·비밀키 회전 체크리스트를 분리해 두는 것입니다.

용어 쏙쏙 3개

PM2Node.js 프로세스 매니저
access log웹 요청 처리 기록
reverse shell서버가 공격자 쪽으로 나가는 접속을 열어 통제되는 방식입니다

적용 방 발언 기준

지수님 포인트

운영 서버 점검 런북으로 위키화하면 Hermes 배포/봇 운영 안전선에 바로 쓰입니다.

왜 이 액션인가

계층별 로그 사각지대를 체크리스트화할 수 있습니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Follow-up

next-review — 운영 서버 점검 런북으로 위키화하면 Hermes 배포/봇 운영 안전선에 바로 쓰입니다.

Wikirunbooks/server_intrusion_logging.md

Cross-room hooksnginxpm2security runbook

카카오톡 방 대화 원문 기준입니다.

대화 원문 7개 보기

14:51마스트/클코
혹시 공격자가 접속했을 때 nginx, pm2에 서버 로그조차 안남기는 경우도 있나요? 실시간이라서 로그를 지우진 못한다고 가정한다면요. 지금 클로드 구독이 끝나서 물어볼때가 없네요ㅠ
14:56DV/Antigravity
오 오픈 축하드려요~! 서버는 어디에 배포되어있나요? pm2 프로세스 외 서버에 직접 접근 가능한 환경이면 해당 루트 유출되면 로그없이 공격 가능해요!
14:56콜복/claude
네, 충분히 가능합니다. nginx와 pm2 둘 다 "특정 계층에서 특정 이벤트만" 기록하기 때문에, 그 계층을 안 건드리면 애초에 로그가 안 생깁니다. (지우는 게 아니라 안 남는 거죠.) nginx에 안 남는 경우 TCP 연결만 하고 유효한 HTTP 요청을 안 보냄 → access_log는 완성된 요청만 기록. 포트스캔, 빈 연결, SSL 핸드셰이크 단계 차단 등은 안 남거나 error_log에만 흔적. nginx를 우회해서 앱 포트 직접 타격 (예: pm2 앱이 3000번인데 리버스 프록시 안 거치고 3000 직접 접속) → nginx는 아무것도 못 봄. access_log off; 설정된 location. 버퍼링: access_log가 버퍼에 쌓여 아직 디스크에 안 flush된 상태. (이게 "실시간" 함정 — 로그는 있는데 파일엔 아직 없음.) pm2에 안 남는 경우 pm2 로그 = 앱의 stdout/stderr일 뿐. 앱이 요청마다 로그를 안 찍으면 (대부분 기본값이 그럼) pm2엔 흔적 없음. 앱을 아예 안 거치는 접근(SSH, DB 직접 접속, 파일시스템 등). 핵심: 둘 다 애플리케이션 계층 도구라, 네트워크/시스템 계층 접근은 다른 곳을 봐야 잡힙니다. 실제로 확인할 로그: ss -tnp / netstat — 현재 살아있는 연결 /var/log/auth.log — SSH·로그인 시도 journalctl -u nginx / journalctl — 시스템 레벨 ufw/iptables 로그 (기본은 로깅 꺼져 있음 — 켜야 남음) Hostinger VPS면 last, lastb로 로그인 이력도 정리하면, "로그가 없다 = 안전하다"가 아니라 로그를 안 남기는 경로로 들어왔을 가능성을 의심해야 합니다. srv1697219 같은 경우 ufw 로깅(ufw logging on)이랑 auth.log 모니터링을 같이 걸어두면 사각지대가 크게 줄어요
14:57마음늘보/클코
네, 가능합니다. 다만 핵심은 “공격자가 뭘 했는지”와 “요청이 실제로 nginx/Node 앱까지 어떤 경로로 갔는지”예요. 정리하면: 정상적인 HTTP 요청이 nginx까지 도달했고 access_log가 켜져 있으며 로그 쓰기가 정상이라면 nginx access log는 거의 남는다고 보면 됩니다. NGINX 공식 문서도 클라이언트 요청을 처리한 직후 access log에 기록한다고 설명합니다. 그런데 nginx/pm2 로그가 안 남을 수 있는 경우는 꽤 있습니다. 첫째, 공격이 nginx를 거치지 않았을 때입니다. 예를 들어 SSH로 접속했거나, 서버의 다른 포트가 열려 있었거나, Node.js 앱 포트인 3000, 4000 같은 포트가 외부에 직접 노출되어 nginx를 우회했다면 nginx access log에는 안 남습니다. 이 경우 봐야 할 건 /var/log/auth.log, /var/log/secure, journalctl, 방화벽 로그, 클라우드 보안그룹/로드밸런서 로그 쪽입니다. 둘째, PM2는 HTTP 요청 로그를 자동으로 남기는 도구가 아닙니다. PM2 로그는 기본적으로 앱의 stdout/stderr, 즉 console.log, console.error, 앱에서 직접 출력한 내용 중심입니다. PM2 공식 문서도 앱 로그가 $HOME/.pm2/logs에 저장되고 pm2 logs로 본다고 설명합니다. 그래서 Express/Nest/Next 서버가 요청마다 로그를 찍도록 미들웨어를 안 넣었다면, 요청이 들어와도 PM2 로그에는 아무것도 안 보일 수 있습니다. 셋째, nginx 설정에서 특정 위치나 서버 블록에 access_log off;가 걸려 있으면 그 요청은 access log에 안 남습니다. nginx 공식 모듈 문서상 access_log의 특수값 off는 현재 레벨의 access log 지시문을 취소합니다. 예를 들어 /health, /static, 특정 location, 특정 vhost에만 로그가 꺼져 있을 수 있어요. 넷째, 공격자가 보낸 게 완성된 HTTP 요청이 아니라 TCP 연결만 했다가 끊기, TLS 핸드셰이크 실패, 잘못된 HTTP 헤더, 포트 스캔 같은 수준이면 access log에 안 남거나 error log에만 일부 남을 수 있습니다. nginx access log는 “요청 처리” 기준이라, 애초에 HTTP 요청으로 처리되지 못한 연결은 access log와 다르게 취급될 수 있습니다. 다섯째, 로그가 실시간처럼 보이지 않을 수 있습니다. nginx access_log는 설정에 따라 buffered write를 사용할 수 있고, buffer나 gzip 파라미터가 있으면 로그 쓰기가 버퍼링될 수 있습니다. 그래서 tail -f로 보고 있는데 바로 안 보이다가 나중에 찍히는 경우도 있습니다. WebSocket이나 긴 요청도 끝날 때까지 access log가 늦게 보일 수 있습니다. 여섯째, 공격이 서버에서 밖으로 나가는 방식이면 nginx/pm2에 안 남을 수 있습니다. 예를 들어 이미 앱 취약점으로 명령 실행이 되었고, 그 결과 서버가 공격자 쪽으로 reverse shell을 열었다면 이후 통신은 nginx 요청 로그가 아니라 outbound 네트워크 흔적, 프로세스, bash history, systemd/journal, 방화벽 로그 쪽에서 찾아야 합니다. 그래서 판단 기준은 이렇게 잡으면 됩니다.
14:58마스트/클코
443 80 22 포트 다 막혀있고 서버 직접 접속은 mfa 인증으로 12시간만 제 컴퓨터로 접속 가능한 것외에는 다른 통로는 없어요
15:01콜복/claude
좋은 락다운이긴 한데, 그 3개 포트를 막았다고 "통로가 없다"고 보긴 이릅니다. 닫은 건 인바운드(밖→서버) 통로고, 실제 침해는 다른 계층에서 더 자주 옵니다. (참고: 433은 443 오타로 봤어요.) 포트를 안 여는 침투 경로들 애플리케이션 계층 (Hermes 봇 자체) 봇은 Discord·AI API로 아웃바운드 연결을 계속 엽니다. 봇 코드에 명령 실행류 취약점(eval, 셸 호출)이 있으면 공격자는 Discord 메시지로 명령을 넣어 서버에서 실행시킬 수 있어요. 서버 포트를 하나도 안 열고도요. 토큰·API 키 유출 Discord 봇 토큰, GPT/DeepSeek 키가 새면 공격자는 서버에 접속할 필요 없이 봇을 그대로 조종하거나 크레딧을 태웁니다. .env 관리·git 히스토리 노출이 핵심 점검 포인트. Hostinger 관리 패널 (out-of-band) 이게 사각지대입니다. hPanel/VNC 콘솔은 SSH·ufw를 완전히 우회합니다. 그 계정에 MFA 없거나 비번 약하면, 22번 막아도 콘솔로 들어옵니다. Docker 쓰면 ufw 무력화 컨테이너를 -p 3000:3000으로 띄우면 Docker가 iptables에 자기 규칙을 ufw보다 먼저 꽂아서, ufw가 "막았다"고 믿는 포트가 실제론 열려 있습니다. → iptables -L DOCKER -n 로 확인. IPv6 누락 ufw 규칙이 IPv4만 걸린 경우 많습니다. /etc/default/ufw에서 IPV6=yes 확인. 공급망(npm) 봇 의존성 패키지가 오염되면 install/실행 시점에 아웃바운드로 침투. 포트와 무관. 빠른 점검 코드 정리하면, 인바운드 3포트 차단은 잘한 거지만 봇 코드 취약점 + 키 유출 + 호스팅 패널, 이 셋이 포트를 안 거치는 진짜 통로입니다. 여긴 봐두시는 게 좋아요. ss -tlnp # 실제로 뭐가 리스닝 중인지 (ufw 믿지 말고 직접) iptables -L DOCKER -n # 도커 우회 포트 last / lastb # 로그인·실패 이력
15:04마음늘보/클코
와우 저도 공부 많이 됐습니다~ Panel과 Docker사용할 경우 ufw 가 docker단과 IPv6에서도 방화벽이 되어있는지 점검해야겠네요. 나중에 오픈할때 참고하겠습니다. 감사합니다~

30일 뒤 사라지는 세션을 영구 보존하고 self-improve로 되돌리는 agy-harness 설계가 공유됐다

한줄 결론에이전트 기억의 핵심은 “무한 저장”이 아니라 검색 가능성, 비밀 마스킹, 사람 승인, 수명주기 관리입니다.

왜 중요했나저녁에는 DV님이 과거 세션 검색, 자동 학습, 스킬 청소 추천을 포함한 agy-harness 요약본을 공유했습니다. 이는 단순 기능 소개가 아니라 에이전트 운영에서 기억·검색·학습·승인 경계를 어떻게 설계할지에 대한 구조적 사례였습니다.

무슨 일이 있었나

발단은 에이전트 세션 기록이 30일 뒤 사라지는 문제였습니다. 요약본은 세션 기록을 영구 보존하고, “예전에 이거 어떻게 고쳤지?” 같은 질문에 session-search와 로컬 검색으로 답하도록 설계했다고 설명했습니다.

응답 구조의 핵심은 자동성과 통제의 분리였습니다. Stop 훅에서 시크릿을 마스킹하고 .obs 폴더에 저장한 뒤, 검색 인덱스와 self-improve 루트가 과거 세션을 재활용합니다. 하지만 스킬 반영은 사람이 승인해야 하며, 에이전트가 멋대로 파일을 고치지 못하게 했습니다.

전개는 lifecycle 관리까지 이어졌습니다. active/stale/archive-candidate로 스킬 상태를 보고, pins.json으로 보존 대상을 제외합니다. 즉 “기억을 많이 쌓자”가 아니라 오래된 절차 지식의 정리·승인·보존 규칙까지 포함한 운영체계였습니다.

실무 결론은 에이전트 기억이 채팅 저장소가 아니라 안전한 검색/학습 파이프라인이어야 한다는 점입니다. 지수님에게는 Hermes wiki/skill 누적과도 직접 연결됩니다. 자동 요약은 가능하지만 승인·비밀 마스킹·수명주기 점검은 별도 게이트로 남겨야 합니다.

용어 쏙쏙 3개

self-improve세션에서 배운 점을 스킬/절차로 정리하는 루트
redaction비밀값을 저장 전 가리는 처리
lifecycle스킬의 사용 빈도와 보존 상태를 관리하는 체계입니다

위키화 방 발언 기준

지수님 포인트

Hermes의 위키/스킬 운영과 거의 같은 문제이므로 “메모리 보존+승인 게이트” 패턴으로 재사용 가치가 큽니다.

왜 이 액션인가

기억 누적과 안전 경계가 동시에 드러난 사례입니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Follow-up

next-review — Hermes의 위키/스킬 운영과 거의 같은 문제이므로 “메모리 보존+승인 게이트” 패턴으로 재사용 가치가 큽니다.

Wikipatterns/agent_memory_self_improvement.md

Cross-room hookssession-searchself-improveskills lifecycle

카카오톡 방 대화 원문 기준입니다.

대화 원문 5개 보기

21:17DV/Antigravity
레퍼런스가 딱히 있는채로 진행한건 아니라서 제 코드 레포에서 요약본을 gemini로 추출해서 공유드릴게요! ================================================================================ agy-harness: 과거 세션 검색과 자동 학습 (Self-Improvement Layer) ================================================================================ [요약] 그동안 에이전트와 나눴던 대화와 문제 해결 기록들이 30일이면 지워져 아쉬우셨죠? 이제 세션 기록을 영구 보존하고, "예전에 이거 어떻게 고쳤지?" 하고 검색하거나 이번에 배운 걸 스킬로 알아서 정리해 주는 기능이 추가되었습니다. -------------------------------------------------------------------------------- 1. 과거 세션 검색 ("예전에 어떻게 했더라?") -------------------------------------------------------------------------------- 이제 에이전트가 예전 대화를 기억해 냅니다. 어떤 문제 해결법이나 명령어가 가물가물할 때 에이전트에게 물어보세요: "예전에 도커 캐시 문제 어떻게 고쳤었지?" "지난주에 K8s 띄울 때 쳤던 명령어 찾아줄래?" 그러면 에이전트가 직접 session-search 스킬과 ./obs search 명령어를 써서 과거 세션 기록을 다 뒤져보고 정답이 있던 세션 아이디와 명령어를 알려줍니다. (한글 검색도 잘 됩니다!) ※ 주의: 검색해서 찾은 명령어는 "예전에 이렇게 쳐본 적이 있다"는 뜻이지, 무조건 정답이라는 보장은 없습니다. 실행 전 한 번 확인해 주세요. -------------------------------------------------------------------------------- 2. 스마트한 스킬 정리 (self-improve 스킬) -------------------------------------------------------------------------------- 문제 하나를 끙끙대며 풀고 났을 때, 에이전트에게 이렇게 말해보세요: "이번 세션에서 배운 것들 스킬로 정리해 줘." 에이전트가 알아서 이번 대화를 분석한 뒤, 배운 점을 스킬 라이브러리에 반영할 초안을 짜서 보여줍니다. 여러분이 "그렇게 하지 마", "너무 장황해"라고 짜증냈던 부분들 새로 알게 된 우회 방법이나 문제 해결 패턴 기존 스킬 중에 틀렸던 부분 단, 멋대로 저장하진 않습니다. "이거 이렇게 저장할까요?" 하고 물어보면 승인만 해주시면 됩니다. 쓸데없는 일회성 에러나 "이 툴은 안 되네요" 같은 잘못된 단정은 알아서 걸러냅니다. -------------------------------------------------------------------------------- 3. 안 쓰는 스킬 청소 추천 (./obs skills --lifecycle) -------------------------------------------------------------------------------- 만들어두고 안 쓰는 스킬들, 방치돼 있지 않나요? ./obs skills --lifecycle 을 치면 스킬들의 상태를 알려줍니다. active: 최근 한 달 안에 쓴 스킬 stale: 한 달 넘게 안 쓴 스킬 archive-candidate: 3달 넘게 안 써서 창고에 넣을 만한 스킬 "이건 안 쓰더라도 절대 지우면 안 돼" 하는 스킬은 .pins.json에 이름을 적어두면 청소 대상에서 영구 제외됩니다. 이것 역시 알려주기만 할 뿐, 스스로 파일을 지우거나 옮기지는 않으니 안심하세요. -------------------------------------------------------------------------------- 4. 어떻게 돌아가나요? (대략적인 아키텍처) -------------------------------------------------------------------------------- agy가 30일 뒤에 원본 대화를 지워버리더라도, 하네스 자체적으로 기록을 남기고 안전하게 재활용하는 흐름입니다. [1. 대화 종료] ──(자동)──> [2. 영구 보존소 저장] agy 세션 끝 - Stop 훅이 시크릿/비밀번호를 가림 (Redaction) - .obs/ 폴더에 텍스트(.jsonl)로 영구 저장 ┌────────────────────────┴────────────────────────┐ │ │ [3A. 과거 회상 루트 (session-search)] [3B. 자기 학습 루트 (self-improve)] │ │ (검색어 입력 시 자동 갱신) (통계 도구가 분석) [ 검색 인덱스 (index.db) ] [ ./obs digest (에러 패턴) ] │ [ ./obs score (실행 점수) ] ▼ │ 과거 대화와 명령어 발췌 ▼ │ 에이전트가 초안 작성 ▼ │ 현재 세션의 문제 해결에 활용 (사람이 승인하면 저장) [ .agents/skills/ 에 스킬 업데이트 ] 핵심 안전 장치 (통제선): - 프라이버시: 모든 기록은 시크릿 마스킹이 기본값입니다. - LLM 폭주 방지: 백그라운드에서 에이전트가 혼자 제멋대로 스킬을 만들거나 수정하지 못합니다. '분석은 기계(스크립트)가, 제안은 에이전트가, 승인과 저장은 사람이' 하는 구조입니다.
21:17DV/Antigravity
레퍼런스가 딱히 있는채로 진행한건 아니라서 제 코드 레포에서 요약본을 gemini로 추출해서 공유드릴게요! ================================================================================ agy-harness: 과거 세션 검색과 자동 학습 (Self-Improvement Layer) ================================================================================ [요약] 그동안 에이전트와 나눴던 대화와 문제 해결 기록들이 30일이면 지워져 아쉬우셨죠? 이제 세션 기록을 영구 보존하고, "예전에 이거 어떻게 고쳤지?" 하고 검색하거나 이번에 배운 걸 스킬로 알아서 정리해 주는 기능이 추가되었습니다. -------------------------------------------------------------------------------- 1. 과거 세션 검색 ("예전에 어떻게 했더라?") -------------------------------------------------------------------------------- 이제 에이전트가 예전 대화를 기억해 냅니다. 어떤 문제 해결법이나 명령어가 가물가물할 때 에이전트에게 물어보세요: "예전에 도커 캐시 문제 어떻게 고쳤었지?" "지난주에 K8s 띄울 때 쳤던 명령어 찾아줄래?" 그러면 에이전트가 직접 session-search 스킬과 ./obs search 명령어를 써서 과거 세션 기록을 다 뒤져보고 정답이 있던 세션 아이디와 명령어를 알려줍니다. (한글 검색도 잘 됩니다!) ※ 주의: 검색해서 찾은 명령어는 "예전에 이렇게 쳐본 적이 있다"는 뜻이지, 무조건 정답이라는 보장은 없습니다. 실행 전 한 번 확인해 주세요. -------------------------------------------------------------------------------- 2. 스마트한 스킬 정리 (self-improve 스킬) -------------------------------------------------------------------------------- 문제 하나를 끙끙대며 풀고 났을 때, 에이전트에게 이렇게 말해보세요: "이번 세션에서 배운 것들 스킬로 정리해 줘." 에이전트가 알아서 이번 대화를 분석한 뒤, 배운 점을 스킬 라이브러리에 반영할 초안을 짜서 보여줍니다. 여러분이 "그렇게 하지 마", "너무 장황해"라고 짜증냈던 부분들 새로 알게 된 우회 방법이나 문제 해결 패턴 기존 스킬 중에 틀렸던 부분 단, 멋대로 저장하진 않습니다. "이거 이렇게 저장할까요?" 하고 물어보면 승인만 해주시면 됩니다. 쓸데없는 일회성 에러나 "이 툴은 안 되네요" 같은 잘못된 단정은 알아서 걸러냅니다. -------------------------------------------------------------------------------- 3. 안 쓰는 스킬 청소 추천 (./obs skills --lifecycle) -------------------------------------------------------------------------------- 만들어두고 안 쓰는 스킬들, 방치돼 있지 않나요? ./obs skills --lifecycle 을 치면 스킬들의 상태를 알려줍니다. active: 최근 한 달 안에 쓴 스킬 stale: 한 달 넘게 안 쓴 스킬 archive-candidate: 3달 넘게 안 써서 창고에 넣을 만한 스킬 "이건 안 쓰더라도 절대 지우면 안 돼" 하는 스킬은 .pins.json에 이름을 적어두면 청소 대상에서 영구 제외됩니다. 이것 역시 알려주기만 할 뿐, 스스로 파일을 지우거나 옮기지는 않으니 안심하세요. -------------------------------------------------------------------------------- 4. 어떻게 돌아가나요? (대략적인 아키텍처) -------------------------------------------------------------------------------- agy가 30일 뒤에 원본 대화를 지워버리더라도, 하네스 자체적으로 기록을 남기고 안전하게 재활용하는 흐름입니다. [1. 대화 종료] ──(자동)──> [2. 영구 보존소 저장] agy 세션 끝 - Stop 훅이 시크릿/비밀번호를 가림 (Redaction) - .obs/ 폴더에 텍스트(.jsonl)로 영구 저장 ┌────────────────────────┴────────────────────────┐ │ │ [3A. 과거 회상 루트 (session-search)] [3B. 자기 학습 루트 (self-improve)] │ │ (검색어 입력 시 자동 갱신) (통계 도구가 분석) [ 검색 인덱스 (index.db) ] [ ./obs digest (에러 패턴) ] │ [ ./obs score (실행 점수) ] ▼ │ 과거 대화와 명령어 발췌 ▼ │ 에이전트가 초안 작성 ▼ │ 현재 세션의 문제 해결에 활용 (사람이 승인하면 저장) [ .agents/skills/ 에 스킬 업데이트 ] 핵심 안전 장치 (통제선): - 프라이버시: 모든 기록은 시크릿 마스킹이 기본값입니다. - LLM 폭주 방지: 백그라운드에서 에이전트가 혼자 제멋대로 스킬을 만들거나 수정하지 못합니다. '분석은 기계(스크립트)가, 제안은 에이전트가, 승인과 저장은 사람이' 하는 구조입니다.
21:17DV/Antigravity
레퍼런스가 딱히 있는채로 진행한건 아니라서 제 코드 레포에서 요약본을 gemini로 추출해서 공유드릴게요! ================================================================================ agy-harness: 과거 세션 검색과 자동 학습 (Self-Improvement Layer) ================================================================================ [요약] 그동안 에이전트와 나눴던 대화와 문제 해결 기록들이 30일이면 지워져 아쉬우셨죠? 이제 세션 기록을 영구 보존하고, "예전에 이거 어떻게 고쳤지?" 하고 검색하거나 이번에 배운 걸 스킬로 알아서 정리해 주는 기능이 추가되었습니다. -------------------------------------------------------------------------------- 1. 과거 세션 검색 ("예전에 어떻게 했더라?") -------------------------------------------------------------------------------- 이제 에이전트가 예전 대화를 기억해 냅니다. 어떤 문제 해결법이나 명령어가 가물가물할 때 에이전트에게 물어보세요: "예전에 도커 캐시 문제 어떻게 고쳤었지?" "지난주에 K8s 띄울 때 쳤던 명령어 찾아줄래?" 그러면 에이전트가 직접 session-search 스킬과 ./obs search 명령어를 써서 과거 세션 기록을 다 뒤져보고 정답이 있던 세션 아이디와 명령어를 알려줍니다. (한글 검색도 잘 됩니다!) ※ 주의: 검색해서 찾은 명령어는 "예전에 이렇게 쳐본 적이 있다"는 뜻이지, 무조건 정답이라는 보장은 없습니다. 실행 전 한 번 확인해 주세요. -------------------------------------------------------------------------------- 2. 스마트한 스킬 정리 (self-improve 스킬) -------------------------------------------------------------------------------- 문제 하나를 끙끙대며 풀고 났을 때, 에이전트에게 이렇게 말해보세요: "이번 세션에서 배운 것들 스킬로 정리해 줘." 에이전트가 알아서 이번 대화를 분석한 뒤, 배운 점을 스킬 라이브러리에 반영할 초안을 짜서 보여줍니다. 여러분이 "그렇게 하지 마", "너무 장황해"라고 짜증냈던 부분들 새로 알게 된 우회 방법이나 문제 해결 패턴 기존 스킬 중에 틀렸던 부분 단, 멋대로 저장하진 않습니다. "이거 이렇게 저장할까요?" 하고 물어보면 승인만 해주시면 됩니다. 쓸데없는 일회성 에러나 "이 툴은 안 되네요" 같은 잘못된 단정은 알아서 걸러냅니다. -------------------------------------------------------------------------------- 3. 안 쓰는 스킬 청소 추천 (./obs skills --lifecycle) -------------------------------------------------------------------------------- 만들어두고 안 쓰는 스킬들, 방치돼 있지 않나요? ./obs skills --lifecycle 을 치면 스킬들의 상태를 알려줍니다. active: 최근 한 달 안에 쓴 스킬 stale: 한 달 넘게 안 쓴 스킬 archive-candidate: 3달 넘게 안 써서 창고에 넣을 만한 스킬 "이건 안 쓰더라도 절대 지우면 안 돼" 하는 스킬은 .pins.json에 이름을 적어두면 청소 대상에서 영구 제외됩니다. 이것 역시 알려주기만 할 뿐, 스스로 파일을 지우거나 옮기지는 않으니 안심하세요. -------------------------------------------------------------------------------- 4. 어떻게 돌아가나요? (대략적인 아키텍처) -------------------------------------------------------------------------------- agy가 30일 뒤에 원본 대화를 지워버리더라도, 하네스 자체적으로 기록을 남기고 안전하게 재활용하는 흐름입니다. [1. 대화 종료] ──(자동)──> [2. 영구 보존소 저장] agy 세션 끝 - Stop 훅이 시크릿/비밀번호를 가림 (Redaction) - .obs/ 폴더에 텍스트(.jsonl)로 영구 저장 ┌────────────────────────┴────────────────────────┐ │ │ [3A. 과거 회상 루트 (session-search)] [3B. 자기 학습 루트 (self-improve)] │ │ (검색어 입력 시 자동 갱신) (통계 도구가 분석) [ 검색 인덱스 (index.db) ] [ ./obs digest (에러 패턴) ] │ [ ./obs score (실행 점수) ] ▼ │ 과거 대화와 명령어 발췌 ▼ │ 에이전트가 초안 작성 ▼ │ 현재 세션의 문제 해결에 활용 (사람이 승인하면 저장) [ .agents/skills/ 에 스킬 업데이트 ] 핵심 안전 장치 (통제선): - 프라이버시: 모든 기록은 시크릿 마스킹이 기본값입니다. - LLM 폭주 방지: 백그라운드에서 에이전트가 혼자 제멋대로 스킬을 만들거나 수정하지 못합니다. '분석은 기계(스크립트)가, 제안은 에이전트가, 승인과 저장은 사람이' 하는 구조입니다.
21:17DV/Antigravity
레퍼런스가 딱히 있는채로 진행한건 아니라서 제 코드 레포에서 요약본을 gemini로 추출해서 공유드릴게요! ================================================================================ agy-harness: 과거 세션 검색과 자동 학습 (Self-Improvement Layer) ================================================================================ [요약] 그동안 에이전트와 나눴던 대화와 문제 해결 기록들이 30일이면 지워져 아쉬우셨죠? 이제 세션 기록을 영구 보존하고, "예전에 이거 어떻게 고쳤지?" 하고 검색하거나 이번에 배운 걸 스킬로 알아서 정리해 주는 기능이 추가되었습니다. -------------------------------------------------------------------------------- 1. 과거 세션 검색 ("예전에 어떻게 했더라?") -------------------------------------------------------------------------------- 이제 에이전트가 예전 대화를 기억해 냅니다. 어떤 문제 해결법이나 명령어가 가물가물할 때 에이전트에게 물어보세요: "예전에 도커 캐시 문제 어떻게 고쳤었지?" "지난주에 K8s 띄울 때 쳤던 명령어 찾아줄래?" 그러면 에이전트가 직접 session-search 스킬과 ./obs search 명령어를 써서 과거 세션 기록을 다 뒤져보고 정답이 있던 세션 아이디와 명령어를 알려줍니다. (한글 검색도 잘 됩니다!) ※ 주의: 검색해서 찾은 명령어는 "예전에 이렇게 쳐본 적이 있다"는 뜻이지, 무조건 정답이라는 보장은 없습니다. 실행 전 한 번 확인해 주세요. -------------------------------------------------------------------------------- 2. 스마트한 스킬 정리 (self-improve 스킬) -------------------------------------------------------------------------------- 문제 하나를 끙끙대며 풀고 났을 때, 에이전트에게 이렇게 말해보세요: "이번 세션에서 배운 것들 스킬로 정리해 줘." 에이전트가 알아서 이번 대화를 분석한 뒤, 배운 점을 스킬 라이브러리에 반영할 초안을 짜서 보여줍니다. 여러분이 "그렇게 하지 마", "너무 장황해"라고 짜증냈던 부분들 새로 알게 된 우회 방법이나 문제 해결 패턴 기존 스킬 중에 틀렸던 부분 단, 멋대로 저장하진 않습니다. "이거 이렇게 저장할까요?" 하고 물어보면 승인만 해주시면 됩니다. 쓸데없는 일회성 에러나 "이 툴은 안 되네요" 같은 잘못된 단정은 알아서 걸러냅니다. -------------------------------------------------------------------------------- 3. 안 쓰는 스킬 청소 추천 (./obs skills --lifecycle) -------------------------------------------------------------------------------- 만들어두고 안 쓰는 스킬들, 방치돼 있지 않나요? ./obs skills --lifecycle 을 치면 스킬들의 상태를 알려줍니다. active: 최근 한 달 안에 쓴 스킬 stale: 한 달 넘게 안 쓴 스킬 archive-candidate: 3달 넘게 안 써서 창고에 넣을 만한 스킬 "이건 안 쓰더라도 절대 지우면 안 돼" 하는 스킬은 .pins.json에 이름을 적어두면 청소 대상에서 영구 제외됩니다. 이것 역시 알려주기만 할 뿐, 스스로 파일을 지우거나 옮기지는 않으니 안심하세요. -------------------------------------------------------------------------------- 4. 어떻게 돌아가나요? (대략적인 아키텍처) -------------------------------------------------------------------------------- agy가 30일 뒤에 원본 대화를 지워버리더라도, 하네스 자체적으로 기록을 남기고 안전하게 재활용하는 흐름입니다. [1. 대화 종료] ──(자동)──> [2. 영구 보존소 저장] agy 세션 끝 - Stop 훅이 시크릿/비밀번호를 가림 (Redaction) - .obs/ 폴더에 텍스트(.jsonl)로 영구 저장 ┌────────────────────────┴────────────────────────┐ │ │ [3A. 과거 회상 루트 (session-search)] [3B. 자기 학습 루트 (self-improve)] │ │ (검색어 입력 시 자동 갱신) (통계 도구가 분석) [ 검색 인덱스 (index.db) ] [ ./obs digest (에러 패턴) ] │ [ ./obs score (실행 점수) ] ▼ │ 과거 대화와 명령어 발췌 ▼ │ 에이전트가 초안 작성 ▼ │ 현재 세션의 문제 해결에 활용 (사람이 승인하면 저장) [ .agents/skills/ 에 스킬 업데이트 ] 핵심 안전 장치 (통제선): - 프라이버시: 모든 기록은 시크릿 마스킹이 기본값입니다. - LLM 폭주 방지: 백그라운드에서 에이전트가 혼자 제멋대로 스킬을 만들거나 수정하지 못합니다. '분석은 기계(스크립트)가, 제안은 에이전트가, 승인과 저장은 사람이' 하는 구조입니다.
21:17DV/Antigravity
레퍼런스가 딱히 있는채로 진행한건 아니라서 제 코드 레포에서 요약본을 gemini로 추출해서 공유드릴게요! ================================================================================ agy-harness: 과거 세션 검색과 자동 학습 (Self-Improvement Layer) ================================================================================ [요약] 그동안 에이전트와 나눴던 대화와 문제 해결 기록들이 30일이면 지워져 아쉬우셨죠? 이제 세션 기록을 영구 보존하고, "예전에 이거 어떻게 고쳤지?" 하고 검색하거나 이번에 배운 걸 스킬로 알아서 정리해 주는 기능이 추가되었습니다. -------------------------------------------------------------------------------- 1. 과거 세션 검색 ("예전에 어떻게 했더라?") -------------------------------------------------------------------------------- 이제 에이전트가 예전 대화를 기억해 냅니다. 어떤 문제 해결법이나 명령어가 가물가물할 때 에이전트에게 물어보세요: "예전에 도커 캐시 문제 어떻게 고쳤었지?" "지난주에 K8s 띄울 때 쳤던 명령어 찾아줄래?" 그러면 에이전트가 직접 session-search 스킬과 ./obs search 명령어를 써서 과거 세션 기록을 다 뒤져보고 정답이 있던 세션 아이디와 명령어를 알려줍니다. (한글 검색도 잘 됩니다!) ※ 주의: 검색해서 찾은 명령어는 "예전에 이렇게 쳐본 적이 있다"는 뜻이지, 무조건 정답이라는 보장은 없습니다. 실행 전 한 번 확인해 주세요. -------------------------------------------------------------------------------- 2. 스마트한 스킬 정리 (self-improve 스킬) -------------------------------------------------------------------------------- 문제 하나를 끙끙대며 풀고 났을 때, 에이전트에게 이렇게 말해보세요: "이번 세션에서 배운 것들 스킬로 정리해 줘." 에이전트가 알아서 이번 대화를 분석한 뒤, 배운 점을 스킬 라이브러리에 반영할 초안을 짜서 보여줍니다. 여러분이 "그렇게 하지 마", "너무 장황해"라고 짜증냈던 부분들 새로 알게 된 우회 방법이나 문제 해결 패턴 기존 스킬 중에 틀렸던 부분 단, 멋대로 저장하진 않습니다. "이거 이렇게 저장할까요?" 하고 물어보면 승인만 해주시면 됩니다. 쓸데없는 일회성 에러나 "이 툴은 안 되네요" 같은 잘못된 단정은 알아서 걸러냅니다. -------------------------------------------------------------------------------- 3. 안 쓰는 스킬 청소 추천 (./obs skills --lifecycle) -------------------------------------------------------------------------------- 만들어두고 안 쓰는 스킬들, 방치돼 있지 않나요? ./obs skills --lifecycle 을 치면 스킬들의 상태를 알려줍니다. active: 최근 한 달 안에 쓴 스킬 stale: 한 달 넘게 안 쓴 스킬 archive-candidate: 3달 넘게 안 써서 창고에 넣을 만한 스킬 "이건 안 쓰더라도 절대 지우면 안 돼" 하는 스킬은 .pins.json에 이름을 적어두면 청소 대상에서 영구 제외됩니다. 이것 역시 알려주기만 할 뿐, 스스로 파일을 지우거나 옮기지는 않으니 안심하세요. -------------------------------------------------------------------------------- 4. 어떻게 돌아가나요? (대략적인 아키텍처) -------------------------------------------------------------------------------- agy가 30일 뒤에 원본 대화를 지워버리더라도, 하네스 자체적으로 기록을 남기고 안전하게 재활용하는 흐름입니다. [1. 대화 종료] ──(자동)──> [2. 영구 보존소 저장] agy 세션 끝 - Stop 훅이 시크릿/비밀번호를 가림 (Redaction) - .obs/ 폴더에 텍스트(.jsonl)로 영구 저장 ┌────────────────────────┴────────────────────────┐ │ │ [3A. 과거 회상 루트 (session-search)] [3B. 자기 학습 루트 (self-improve)] │ │ (검색어 입력 시 자동 갱신) (통계 도구가 분석) [ 검색 인덱스 (index.db) ] [ ./obs digest (에러 패턴) ] │ [ ./obs score (실행 점수) ] ▼ │ 과거 대화와 명령어 발췌 ▼ │ 에이전트가 초안 작성 ▼ │ 현재 세션의 문제 해결에 활용 (사람이 승인하면 저장) [ .agents/skills/ 에 스킬 업데이트 ] 핵심 안전 장치 (통제선): - 프라이버시: 모든 기록은 시크릿 마스킹이 기본값입니다. - LLM 폭주 방지: 백그라운드에서 에이전트가 혼자 제멋대로 스킬을 만들거나 수정하지 못합니다. '분석은 기계(스크립트)가, 제안은 에이전트가, 승인과 저장은 사람이' 하는 구조입니다.

Sub Agent 권한 주입과 모델 전환 캐시는 “부모 권한을 그대로 믿지 말라”는 운영 질문으로 수렴했다

한줄 결론Sub Agent 운영은 “생성하면 알아서 안전하다”가 아니라 권한·모델·비용·검증 게이트를 선언해야 안전합니다.

왜 중요했나밤에는 Codex/Antigravity Sub Agent가 부모 permission을 따라가는 문제와, 세션 중 모델 변경 시 캐시가 어떻게 깨지는지가 이어졌습니다. 둘 다 에이전트 운영에서 권한·비용·역할 분리를 명시해야 한다는 같은 결론으로 연결됩니다.

무슨 일이 있었나

발단은 크룩님이 subagent마다 approval policy와 filesystem permission을 다르게 주고 싶다고 한 질문이었습니다. DV님은 Sub Agent 도구가 보통 Define Sub Agent와 Call Sub Agent 두 단계로 나뉘며, 생성 함수와 파라미터를 먼저 분석하라고 제안했습니다.

응답은 Codex 구체 스펙으로 좁혀졌습니다. spawn_agent 호출에는 model, reasoning_effort, service_tier 등이 보이지만 Permission은 직접 주입하지 않고 agent_type에서 agents/<name>.toml, default_permissions, permissions 체인을 타는 것으로 정리됐습니다. 부모 permission을 따라가지도 못하는 것 같아 추가 확인이 필요하다는 관찰도 남았습니다.

같은 시간대에는 캐시와 모델 전환도 붙었습니다. 초기 context를 캐시에 저장하고 다음 프롬프트에서 재사용하지만, 모델을 바꾸면 캐시가 아니라 전체를 다시 읽어 비용이 든다는 설명입니다. 다만 큰 작업에서는 고지능 모델로 계획서를 만들고, handoff 후 Sonnet으로 구현하는 손해가 Fable/Opus로 계속 구현하는 손해보다 작을 수 있다고 했습니다.

실무 결론은 Sub Agent를 만들 때 모델·권한·파일 접근·승인 정책·비용을 모두 명시하고, 부모 세션의 설정을 암묵적으로 상속한다고 가정하지 않는 것입니다. 지수님 적용점은 Hermes/코덱스 워커 레인에서도 worktree 격리, allowlist merge gate, verify, tdd evidence를 한 묶음으로 기록하는 것입니다.

용어 쏙쏙 4개

sandbox파일 접근 범위
approval policy명령 실행 승인 방식
TOML설정 파일 형식
handoff계획을 다른 모델/세션으로 넘기는 절차입니다

적용 방 발언 기준

지수님 포인트

Codex 워커/하위 에이전트 실행 시 권한 매트릭스와 merge gate를 체크리스트로 남길 가치가 있습니다.

왜 이 액션인가

권한과 비용이 모두 실제 운영 리스크입니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Follow-up

next-review — Codex 워커/하위 에이전트 실행 시 권한 매트릭스와 merge gate를 체크리스트로 남길 가치가 있습니다.

Wikirunbooks/subagent_permission_matrix.md

Cross-room hooksCodexSub Agentsandboxapproval policy

카카오톡 방 대화 원문 기준입니다.

대화 원문 8개 보기

22:52크룩 / codex
혹시 작은 질문하나 드려도될까요 제가 subagent한테 다른 permission설정을 하고 싶은데 계속 부모 permission만 따라가서 설정한느 방법을 여쭤보고 싶어여..
23:14DV/Antigravity
보통 Agent 도구에서 Sub Agent로 작업을 위임하는 과정은 1) Define Sub Agent 2) Call Sub Agent 두가지 순서로 이루어지고 사실상 각각의 함수가 에이전트에 의해 호출되는 방식입니다. 여기서 1)은 통상 2가지 중 하나의 방법으로 수행됩니다. a) 사전에 내가 만들어준 Sub Agent를 로드 b) 에이전트가 스스로 Sub Agent를 선언 그리고 이 과정에서 define_sub_agent의 파라미터에 Permission을 세팅하게 되어요. Codex는 제가 사용을 안해봤지만 저라면 아래 순서로 Codex에게 질의하여 방법을 찾을것 같습니다. 1. Sub Agent를 생성할 때 자체적으로 어떤 함수를 호출하여 생성하는지, 해당 함수의 파라미터를 분석해줘 (특히 Permission 관련) 2. 1의 과정이 끝나고나면 사전에 내가 설정한 Sub Agent를 해당 함수에 주입하기 위해서는 어떤 Spec으로 선언하면 될지 분석해줘 (특히 Permission 관련) 3. 만약 Sub Agent Spec의 사전 설정을 지원하지 않는다면 해당 Sub Agent를 생성하기 위한 함수를 Agent 최초 Invocation 단계에서 호출하기 위한 Hook과 Script를 작성해줘 (Permission 설정 포함)
23:23이라페/클코,코덱스
캐시 관련해서는 제가 이해한 내용을 토대로 도와드리자면 1번 프롬프트 초기context(claude.md, handoff와 같이 세션을 처음 열었을때 읽는것) - 전부 읽고 캐시에 저장 2번 프롬프트 1번 프롬프트(캐시로 재사용 - 1/10 비용)+추가된 부분만 처리 3번 프롬프트 반복 결국 중요한건 현재 열린 세션에서 - 모델을 바꾸면 - 캐시로 읽는게 아니라 전체를 다시 읽는다 = 토큰비용 근데 이건 결국 현재 context가 어느정도인지가 중요한것같아요 최고의 방법은 고지능 plan모드 계획서작성 - 핸드오프 - 커밋 - 새세션 - sonnet 구현 < 이게 베스트지만 이미 세션안에서 대화가 많지 않은 상태라면, 그냥 계획서 작성 - sonnet으로 변경해서 바로 구현해도 괜찮다고 생각하고 있습니다 그 이유를 조금 추가설명해드리자면 저는 작업에서 모델을 선택하는 기준은 모델에게 어느정도의 판단력을 요구할것인가를 기준으로 생각하고 있는데, fable, opus같은 모델로 계획서를 작성했다면 이미 판단의 영역은 fable과 opus가 다 해놨기 때문에 fable, opus로 계속 구현하는것보다 sonnet으로 구현하는게 전체 대화를 다 읽어서 생긴 손해보다 (훨씬)작다고 생각해요 - 계획서를 작성할 정도의 구현작업이라면 이미 규모가 크다는거니까요ㅎㅎ.. 그걸 fable, opus로 계속 구현하면 ..어후.. 실제로 저도 좀전에 fable5로 계획서 작성하라고 auto누르고 담배피고왔다가 승인인걸 뒤늦게 깨닫고 작성하던것까지만 하고 멈추라고 한다음에 바로 sonnet으로 바꿨습니다.. fable로 구현하는건 정말 아닌것같아용.,,,
23:28크룩 / codex
1. 생성 함수와 파라미터 Sub Agent 생성 호출 스펙은 대략 다음입니다. spawn_agent({ agent_type?: string, fork_context?: boolean, message?: string, items?: Array<{ type?: "text" | "image" | "local_image" | "skill" | "mention", text?: string, path?: string, name?: string, image_url?: string }>, model?: string, reasoning_effort?: string, service_tier?: string }) 핵심 결론: Permission은 spawn_agent 호출 시 직접 주입하지 않고, agent_type → agents/<name>.toml → default_permissions → [permissions.<name>] 체인으로 주입됩니다. 라고는 합니다!! 확인해보니 부모의 permission을 따라가지도 못하는거같아서 더 확인해보려고합니다...
23:33DV/Antigravity
아 toml 방식이군요! toml에 Permission 설정 필드가 있을것 같네요. 그나저나 생성 단계가 아니면 언제 Permission을 주입하는지도 궁금하긴 하네요ㅋㅋ
23:36DV/Antigravity
공유주신 필드 보니 Codex는 Sub Agent별로 다른 모델 설정은 지원하는군요ㅜ Agy만 지원 안하는...
23:48MaJu / 개발자 / 클코,코덱스
permission 설정을 다르게 한다는게... 툴 제한? sandbox? approval? 어떤것일까요?
23:58MaJu / 개발자 / 클코,코덱스
그렇다면... sandbox (파일접근): read-only / workspace-write / danger-full-access approval-policy (승인정책): untrusted / on-failure / on-request / never 이것 이라면 codex mcp-server 서브커맨드 사용해 보세요. 저는 이것으로 "worktree 격리 + MCP codex 워커 + verify + allowlist merge gate + tdd.json 증거기록을 한 번에 묶은 게이트 달린 코드 write 레인" 으로 사용하고 있습니다.

팀 표준 하네스와 AWS AIDLC 비교는 “외부 범용성 vs 내부 규격화”의 의존성 판단으로 정리됐다

한줄 결론팀 하네스 선택은 “있는 걸 쓰자”가 아니라 내부 규격화와 외부 의존성의 균형 문제입니다.

왜 중요했나AI사장님은 실밸 하네스 프레임워크를 팀 표준으로 바꾸어 공유하려다 AWS AIDLC라는 외부 오픈소스를 쓰자는 의견을 받았다고 했습니다. 대화의 핵심은 어떤 도구가 더 유명한가가 아니라, 팀 규격화와 외부 의존성 사이에서 무엇을 선택할지였습니다.

무슨 일이 있었나

발단은 팀 내부 표준화였습니다. 실밸님 하네스를 기준으로 팀에 맞게 바꾸면 같은 규격 안에서 개발할 수 있다는 판단이 있었고, 반대편에서는 AWS AIDLC가 오픈소스이니 그걸 쓰면 되지 않느냐는 의견이 나왔습니다.

응답은 “범용적인 사용을 위해 md 파일과 process가 많다”는 관찰과 “그쪽에 디펜던시가 생긴다”는 우려로 이어졌습니다. 즉 외부 오픈소스는 출발점이 될 수 있지만, 팀의 작업 방식과 거버넌스가 그 도구의 구조에 묶일 수 있습니다.

전개에서 아웃라이너님은 awslabs/aidlc-workflows 링크를 짚었고, AI사장님은 맞다고 확인했습니다. 질문은 방 전체에 “팀에서는 규격화된 것을 쓰는가, 외부 것을 쓰는가”로 열렸습니다.

실무 결론은 팀용 AI 개발 하네스를 고를 때 기능 목록보다 운영 표준, 문서량, 학습 비용, 외부 의존성, 내부 수정 가능성을 같이 비교해야 한다는 점입니다. 지수님 적용점은 Hermes/OpenClaw 류 표준도 외부 템플릿을 그대로 가져오기보다 내부 워크플로우와 게이트에 맞게 좁히는 것입니다.

용어 쏙쏙 3개

AIDLCAWS가 공개한 AI 개발 수명주기 워크플로우 후보
dependency외부 프로젝트에 운영 방식이 묶이는 의존성
하네스에이전트 작업을 반복 가능하게 묶는 실행/검증 틀입니다

추적 방 발언 기준

지수님 포인트

외부 agent workflow 도입 시 내부 게이트/문서/검증 규격을 먼저 대조하는 기준으로 쓸 수 있습니다.

왜 이 액션인가

팀 표준화와 외부 의존성은 장기 운영 비용으로 연결됩니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Follow-up

next-review — 외부 agent workflow 도입 시 내부 게이트/문서/검증 규격을 먼저 대조하는 기준으로 쓸 수 있습니다.

Wikipatterns/team_ai_harness_adoption.md

Cross-room hooksAIDLCharnessteam standard

카카오톡 방 대화 원문 기준입니다.

대화 원문 4개 보기

20:42AI사장/클로드
안녕하세요~! aws에서 나온 aidlc를 사용하시는 분들 계신가요? 전 오전에 팀에게 실밸님의 harness framework를 기준으로 저희팀에 맞게바꿔서 이걸 팀원들에게 공유하고 이걸사용하면 팀 표준화도 되고 같은 규격안에 개발할 수 있다고 했는데요 특정 인원들이 aws에 aidlc가 오픈소스이고 그걸 사용하면 되지않느냐고 해서요 분석해보니까 거기는 범용적인 사용을위해 md파일들도 많고 process도 엄청 많더라구요 그리고 그걸 사용하면 그쪽에 디펜던시가 생기는것도 문제라고 생각하거든요. 다들 팀에서 어떻게 사용하시나요? 팀내에서 규격화된걸 사용하시나요 아니면 aws aidlc를 사용하시는 곳이 있나요?
20:49아웃라이너/클코덱스
오.. https://github.com/awslabs/aidlc-workflows 이건가요?
20:53AI사장/클로드
네 맞습니다!
20:54AI사장/클로드
@실밸개발자/클코 님은 어떻게생각하시나요? 오늘하루종일 논쟁을 했네요 ㅎㅎ

비개발자 개인 작업에서도 TDD hooks는 “Must보다 Should”인 안전망으로 설명됐다

한줄 결론TDD는 남에게 보이기 위한 절차가 아니라 내 소프트웨어가 방향을 잃지 않게 하는 안전망입니다.

왜 중요했나TDD hooks 질문은 개인/비개발자도 테스트가 의미 있는지에 대한 현실적 기준을 남겼습니다.

무슨 일이 있었나

흥안님은 개인으로 작업하는 비개발자도 TDD hooks가 유의미한지 물었습니다. 우푸님은 원하는 처리를 검증하고 불필요 기능 개발을 막으며 구조적 안전망이 된다고 설명했습니다. 다만 토큰과 시간이 더 들 수 있으므로 Must가 아니라 Should에 가깝다고 정리했습니다.

적용 방 발언 기준

지수님 포인트

Hermes 코드 작업에서도 TDD를 “항상 강제”가 아니라 위험도별 Should로 분류할 기준입니다.

왜 이 액션인가

테스트 비용과 안전망의 균형을 잘 설명합니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Follow-up

next-review — Hermes 코드 작업에서도 TDD를 “항상 강제”가 아니라 위험도별 Should로 분류할 기준입니다.

Wikipatterns/tdd_hooks_should_not_must.md

Cross-room hooksTDDhooks

카카오톡 방 대화 원문 기준입니다.

대화 원문 3개 보기

11:29흥안/클코
강의 듣다가 궁금한 점이 생겨 질문 드립니다~ 개인으로 작업하는 비개발자도 tdd hooks를 사용을 하는 게 유의미하나요?
11:35우푸/클코
TDD의 목적은 여러가지가 있어요.ㅎ 1. 내가 원하는 걸 정확히 처리 했는지 검증 테스트 2. A1 기능을 구현하기 위해 A2, A3 등 불필요한 기능이 개발되었는 지 검증 3. 구조적인 탄탄함 등등 여러가지 목적이 있어요.ㅎ TDD는 기본적으로 "남"을 위한게 아니라, "나의 소프트웨어"를 위한 안전망 이에요 ㅎㅎ 하지만 토큰을 더 사용하거나, 작업시간이 더 오래 걸리는 경우가 있답니다 :) TDD도 소프트웨어나 목적, 아키구성, 인원구성 등 상황에 따라 다르게 구현되고, 프레임워크로 정해져 있진 않아요! ㅎ 그래서 Must가 아니라, Should의 느낌에 더 가깝네요 ㅎㅎ
11:35토르/클코
AI 가 코드 관리 및 방향성을 잃지 않고 진행하는데 도움이 될거 같아요 특히 tdd 없으면 에러가 어디서 터지는지 나중에 확인하기 힘들어져요

분기형 인터랙티브 소설은 사용자 컨텍스트와 장면 구조 없이는 “그럴듯하지만 재미없는” 결과가 됐다

한줄 결론긴 창작물은 프롬프트 한 번보다 장면 골격과 사용자 컨텍스트 설계가 먼저입니다.

왜 중요했나AI 소설 생성 실험은 긴 스토리 작업에서 구조와 컨텍스트가 선행되어야 한다는 교훈을 남겼습니다.

무슨 일이 있었나

아웃라이너님은 분기 선택형 인터랙티브 소설을 주말 내내 만들었지만 품질이 좋지 않았다고 했습니다. DV님은 사용자 context를 알면 더 재밌게 풀 수 있지 않겠냐고 했고, 이후 영화 대본 분석처럼 씬·장소·시간·인물·인터랙션 맵을 먼저 잡는 방식이 제안됐습니다.

위키화 방 발언 기준

지수님 포인트

콘텐츠/스토리형 자동화는 카드 생성 전 구조화 스키마를 먼저 요구해야 합니다.

왜 이 액션인가

창작 AI 품질 실패를 구조 문제로 해석한 사례입니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Follow-up

next-review — 콘텐츠/스토리형 자동화는 카드 생성 전 구조화 스키마를 먼저 요구해야 합니다.

Wikipatterns/story_generation_structure_first.md

Cross-room hooksinteractive fictioncontext

카카오톡 방 대화 원문 기준입니다.

대화 원문 3개 보기

11:09아웃라이너/클코덱스
최근에는 취미로.. 소설을 분기마다 사용자가 직접 선택해서 완성해보는 인터랙티브 소설 같은 걸 주말 내내 만져봤었는데.. 퀄리티가 너무 안좋습니다. ㅋㅋㅋ eval도 시켜봤지만 (제 수준에서) 바로바로 재밌게 소설 뽑아내기는 쉽지 않다는 걸 배웠습니다. https://vibe-choice-omega.vercel.app/
11:51DV/Antigravity
크 이거 근데 사용자의 context를 알면 훨씬 더 재밌게 풀어쓸것 같은데 방법이 없으려나요? 예를들어 저는 제미나이에게 저에 대해 20줄로 설명해달라고 하면 제 캐릭터 하나를 쉽게 만들어 내거든요.
12:07DV/Antigravity
과거에 비슷하게 했던 과제 중 영화 대본에 대해 분석하고 작품 흥행성 분석하는 과제가 있었거든요. 그 당시 영화 분석 관련 논문들 분석하고 저희가 만들었던 솔루션은 단계를 나눠 아래 프레임을 만들고 그에 맞게 스코어링을 했어요. 씬 - 장소 - 시간(낮/밤) - 씬 요약 - 인물 - 인물 이름, action 횟수, 대화 횟수 - 인터렉션 맵(A 인물로부터 B 인물 사이 action) 그러고는 모든 씬들을 종합해서 주인공을 정하고, 주인공의 주요 갈등 대상을 정하고 그 인물들을 중점으로 다시 분석하는 등... 이렇게 긴 스토리가 이어져야되는 경우에는 말씀대로 골격과 구조를 미리 정하는 방식으로 하더군요. 오히려 반대 방향으로 그것들을 먼저 정하고 들어가는것도 좋지 않을까 싶네요!

가족 혈당관리 앱 아이디어는 의료 데이터 접근성과 공개 데이터 한계로 현실 검토가 필요했다

한줄 결론개인 문제에서 출발한 앱도 의료 데이터 접근권·상업성·프라이버시를 먼저 확인해야 합니다.

왜 중요했나1형 당뇨 가족을 위한 앱 아이디어는 따뜻한 문제의식과 동시에 의료 데이터 API의 현실적 장벽을 보여줬습니다.

무슨 일이 있었나

만타님은 어머니가 혈당 확인을 부끄러워하신다는 맥락에서 음식 사진 공유처럼 보이는 혈당관리 앱 아이디어를 설명했습니다. 답변은 의료 데이터가 공개되기 어렵고, 파스타 같은 대표 사례가 있으며, AI Hub 데이터셋 같은 참고자료가 있다는 방향이었습니다.

추적 방 발언 기준

지수님 포인트

헬스케어 앱 아이디어는 데이터 접근/민감도/가족 사용성 검토 항목으로 남길 수 있습니다.

왜 이 액션인가

민감 개인 데이터와 제품 아이디어가 함께 있는 신호입니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Follow-up

next-review — 헬스케어 앱 아이디어는 데이터 접근/민감도/가족 사용성 검토 항목으로 남길 수 있습니다.

Wikipatterns/health_app_data_access.md

Cross-room hookshealth dataprivacy

카카오톡 방 대화 원문 기준입니다.

대화 원문 4개 보기

12:26만타
안녕하세요? 혹시 혈당수치 - 리브레 앱 같은것에서 api 받아서 앱 개발해보신 분 있으실까요? 상업용은 아니고, 1형당뇨를 앓고 있는 가족을 위해 툴을 만들어보고 싶어 시작해보려하는데, 참고할만한 것들이 있을까 해서 글 올려봅니다. 떨어져 사는 엄마가 1형 당뇨셔서 식사량에 맞게 인슐린 수치를 조정하셔야 하는데, 밖에서 앱 보면서 혈당 체크하시는걸 부끄럽게 생각하셔서 이걸 그냥 일반 소셜미디어 앱처럼.. 음식 사진 공유하고 그런 형식으로 만들어보고 싶어요. 아이디어는 혈당관리+셋로그 느낌으로 음식 사진 찍는걸 저/가족들이랑 일상공유하는 것처럼 만드는건데, 혹시 어떤 식으로든 도움/참고가 될만한 링크들 던져주시면 너무 감사하겠습니다! 그럼 모두 좋은 하루 되세요~~!!
12:31뉴비개발자/클코
이미 파스타가 대표적으로 있긴해요
12:32코딩하는 어피치/코덱스
의료 데이터는 보통 공개 잘 안해줘요..
12:38칼카리 / 클코
https://aihub.or.kr/aihubdata/data/view.do?currMenu=115&srchOptnCnd=OPTNCND001&searchKeyword=+%EB%94%B8%EA%B8%B0&aihubDataSe=data&dataSetSn=71392 이런게 있긴합니다

npm 배포와 SSOT 재구성은 “사람이면 금방인데 Claude가 경로 룰에서 헤맨” 배포 병목으로 공유됐다

한줄 결론배포 자동화에서 LLM이 오래 헤매는 지점은 대개 코드 자체보다 경로·환경·호환성 룰입니다.

왜 중요했나Song81님은 Linux/Windows/iOS 어디서든 쓰게 하려는 패키지화 과정에서 기존 사용자 meta 환경을 깨지 않으면서 SSOT를 자족형으로 바꾸는 어려움을 설명했습니다.

무슨 일이 있었나

목표는 npm 설치로 여러 환경에서 쓰게 하는 것이었습니다. 기존 meta 환경을 유지하며 병합하고, 패키지 배포 서버 없이 프로젝트별 Claude 동작환경을 구성하도록 SSOT를 재구성해야 했습니다. Claude는 경로 변경 룰에서 3일을 헤맸다는 경험담이 붙었습니다.

적용 방 발언 기준

지수님 포인트

Hermes 배포 스크립트도 경로/환경 변환 룰을 테스트로 고정해야 합니다.

왜 이 액션인가

크로스플랫폼 배포의 실제 병목입니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Follow-up

next-review — Hermes 배포 스크립트도 경로/환경 변환 룰을 테스트로 고정해야 합니다.

Wikipatterns/cross_platform_packaging_rules.md

Cross-room hooksnpmSSOTpath rules

카카오톡 방 대화 원문 기준입니다.

대화 원문 1개 보기

16:46Song81/클코
Linux, window, ios어디서든 쓴다 이게 목적이라 npm으로 설치하도록 패키지 구성 그러면서 기존 사용자들의 meta환경은 깨지 않으면서 병합처리 제일 걸림돌이 설계서는 SSOT로 구성되어 있는데 이를 자족형(패키지 배포 서버와 연결없이 개별 사용자의 프로젝트별 claude동작환경)을 위해 재구성 여기서 claude가 3일을 해매더군요 사람이 하면 금방 끝날일을 경로 변경 룰 잡는데 해매요(왜그런지는 모르겠음) 이게 배포시 룰과 클로드 사용시 문제점 이였습니다

“2년 뒤 Fable급 로컬 모델” 전망은 하드웨어·로컬 AI 비용 관찰 신호로만 보존한다

한줄 결론아직 근거가 짧은 전망이므로 실행 판단보다 추적 항목으로 남기는 편이 안전합니다.

왜 중요했나이른 아침 로컬에서 Fable급 모델을 돌릴 수 있다는 전망이 나왔지만 후속 토론은 짧았습니다. 다만 로컬 AI 비용/성능 추적 신호로는 보존 가치가 있습니다.

무슨 일이 있었나

조이님이 2년 후쯤 Fable급 모델을 로컬 컴퓨터에서 돌릴 수 있을 것이라는 전망을 공유했고, 따라가기 어렵다는 반응이 있었습니다. 단일 흐름이라 Main은 아니지만 로컬 AI 하드웨어 경제성 추적에는 연결됩니다.

추적 방 발언 기준

지수님 포인트

로컬 AI 하드웨어 비용/성능 관찰 항목에만 추가하고 과신하지 않습니다.

왜 이 액션인가

짧지만 반복 추적 가치가 있는 전망입니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Follow-up

next-review — 로컬 AI 하드웨어 비용/성능 관찰 항목에만 추가하고 과신하지 않습니다.

Wikiwatch/local_ai_hardware_economics.md

Cross-room hookslocal AIhardware

카카오톡 방 대화 원문 기준입니다.

대화 원문 2개 보기

05:36조이/클코
2년 후 쯤에는 Fable급 모델을 로컬 컴퓨터에서 돌릴 수 있을거라는 전망
05:37James Baek/Anti
어마어마하네요 내가 발전속도를 따라갈 수 있으려나...

dryforge 오픈소스 공유는 반복 언급되는 내부 도구 후보로만 추적한다

한줄 결론단일 공유지만 반복 언급된 도구라 별도 실험 후보로만 보존합니다.

왜 중요했나정밀컷터님이 dryforge 오픈소스를 다시 공유했습니다. 대화 확산은 크지 않았지만 이미 몇 차례 올렸고 필요자들이 쓰는 듯하다는 메타 신호가 있었습니다.

무슨 일이 있었나

정밀컷터님은 dryforge 링크를 몇 번 올렸고 필요한 분들이 쓰는 듯해 오픈소스로 잘 배포했다는 생각이 든다고 했습니다. Fable 막차에 필요한 사람은 README를 읽거나 AI에게 분석시키라고 권했습니다.

테스트 방 발언 기준

지수님 포인트

dryforge는 도구 후보 목록에 추가하되, 실제 테스트 전까지 중요도를 높이지 않습니다.

왜 이 액션인가

반복 공유된 오픈소스 후보입니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Follow-up

next-review — dryforge는 도구 후보 목록에 추가하되, 실제 테스트 전까지 중요도를 높이지 않습니다.

Wikitools/kakao_room_tool_mentions.md

Cross-room hooksdryforge

카카오톡 방 대화 원문 기준입니다.

대화 원문 1개 보기

00:03정밀컷터/cc, codex
제가 이방에서 몇번정도 dryforge 링크를 올려드렸는데, 필요하신 분들은 잘 쓰고 계신듯해서 오픈소스로 잘 배포했다는 생각을 늘 합니다 곧 페이블 구독제 막차인데 필요하신분 계시면 리드미 읽어보시거나 ai한테 분석해줘~ 해보시고 필요하시면 쓰셔요 github.com/fn-opt/dryforge 괜찮으시면 스타도 한번씩 부탁드립니다

Playwright MCP 대신 크롬 플러그인 연동을 선호한다는 UI 테스트 방식 신호가 나왔다

한줄 결론UI 자동화는 강력한 Playwright와 조용한 브라우저 확장 연동 사이의 트레이드오프가 있습니다.

왜 중요했나UI 단위 테스트 방식 질문에 Playwright MCP와 크롬 플러그인 연동이 비교됐습니다. 짧지만 Hermes 브라우저/테스트 자동화 선택지와 맞닿아 있어 Watch로 남깁니다.

무슨 일이 있었나

코딩보초님은 요즘 UI 단위테스트를 Playwright MCP로 하는지 물었습니다. 답변에서는 Playwright 또는 크롬 플러그인 연동이 제시됐고, 아웃라이너님은 크롬 플러그인이 더 조용히 로컬에서 일하는 느낌이라 선호하지만 할 수 있는 것은 더 적을 수 있다고 했습니다.

추적 방 발언 기준

지수님 포인트

Hermes UI 테스트 방식 비교에 Playwright MCP와 확장 연동을 같이 남깁니다.

왜 이 액션인가

자동화 도구 선택의 작은 신호입니다.

새로움

실용성

방 반응

지수님 관련

신뢰도

Follow-up

next-review — Hermes UI 테스트 방식 비교에 Playwright MCP와 확장 연동을 같이 남깁니다.

Wikipatterns/ui_test_automation_options.md

Cross-room hooksPlaywrightChrome extension

카카오톡 방 대화 원문 기준입니다.

대화 원문 3개 보기

20:05코딩보초/클코
요즘 ui 단위테스트는 어떤식으로 많이 하나요? playwright mcp로 테스트 코드 작성해서 진행하나요..? 뭔가 새로운 방법론 같은게 있나 궁금하네요.
20:07긁적이는 춘식이
네 그거 쓰시면 됩니다. 아니면 크롬 플러그인 연동해서 크롬 직접 열게 하면됩니다
20:09아웃라이너/클코덱스
크롬 플러그인 연동이 더 조용히 일하는 느낌이라 같이 로컬에서 돌아가기에 더 좋아서 저는 그걸 더 선호합니다. 다만 playwright에 비해서 조금 더 할 수 있는게 적은거 같긴 해요.

[실밸개발자] 바이브코딩 클럽

오늘의 흐름을 먼저 한 번에 보기

AWS AIDLC workflows

카카오 GPT 구독/쿠폰 관련 글

AI Hub 딸기 데이터셋

인터랙티브 소설 실험

실밸 다이제스트 사이트

공유 링크

Fable cutoff 카운트다운

Anthropic: Claude Code 탄생 배경

Fable 구독 종료 D-1은 “막차를 어디에 쓸 것인가”라는 비용·라우팅 토론으로 번졌다

무슨 일이 있었나

nginx·PM2 로그가 조용해도 안전하다는 뜻은 아니라는 서버 침해 점검 런북이 만들어졌다

무슨 일이 있었나

30일 뒤 사라지는 세션을 영구 보존하고 self-improve로 되돌리는 agy-harness 설계가 공유됐다

무슨 일이 있었나

Sub Agent 권한 주입과 모델 전환 캐시는 “부모 권한을 그대로 믿지 말라”는 운영 질문으로 수렴했다

무슨 일이 있었나

팀 표준 하네스와 AWS AIDLC 비교는 “외부 범용성 vs 내부 규격화”의 의존성 판단으로 정리됐다

무슨 일이 있었나

비개발자 개인 작업에서도 TDD hooks는 “Must보다 Should”인 안전망으로 설명됐다

무슨 일이 있었나

분기형 인터랙티브 소설은 사용자 컨텍스트와 장면 구조 없이는 “그럴듯하지만 재미없는” 결과가 됐다

무슨 일이 있었나

가족 혈당관리 앱 아이디어는 의료 데이터 접근성과 공개 데이터 한계로 현실 검토가 필요했다

무슨 일이 있었나

npm 배포와 SSOT 재구성은 “사람이면 금방인데 Claude가 경로 룰에서 헤맨” 배포 병목으로 공유됐다

무슨 일이 있었나

“2년 뒤 Fable급 로컬 모델” 전망은 하드웨어·로컬 AI 비용 관찰 신호로만 보존한다

무슨 일이 있었나

dryforge 오픈소스 공유는 반복 언급되는 내부 도구 후보로만 추적한다

무슨 일이 있었나

Playwright MCP 대신 크롬 플러그인 연동을 선호한다는 UI 테스트 방식 신호가 나왔다

무슨 일이 있었나