2026-05-10

• #0005

  #0005에이전트·도구GitHub Trending Weekly3주 전

  `Ouroboros`, 명세 우선 AI 코딩용 `Agent OS`

  `Ouroboros`: spec-first Agent OS for replayable AI coding

  60radar

  OuroborosAI 코딩 Agent OS — 명세 우선 워크플로

  프롬프트를 길게 다듬는 대신 요구사항을 먼저 굳히고 실행을 재현 가능하게 묶는다. 여러 코딩 CLI 위에 얹어 검증 가능한 작업 흐름을 만들고 싶다면 지금 써볼 만함.

  • —핵심 흐름은 interview -> crystallize -> execute -> evaluate -> evolve 5단계. 코드보다 명세를 먼저 잠가 재작업을 줄인다.
  • —지원 범위가 Codex CLI, Claude Code, Copilot CLI, Kiro 등으로 넓다. 특정 에이전트에 덜 묶이는 운영 레이어로 쓸 수 있다.
  • —검증은 3단계 자동 평가 게이트를 전면에 둔다. looks good식 수동 확인보다 배포 전 체크를 구조화하기 쉽다.
  • —진입 방식도 ooo interview "..."처럼 인터뷰형이다. 막연한 한 줄 프롬프트보다 초기 요구사항 수집 품질에 더 유리하다.

  출처: github.com/Q00/ouroboros원문 보기 →
• #0004

  #0004에이전트·도구r/ClaudeAI3주 전

  `Autoharness`, `Claude Code` 하네스를 스스로 튜닝

  `Autoharness` lets `Claude Code` tune its own agent harness

  50radar

  Autoharness하네스 튜닝 도구 — eval 루프로 변경만 검증·채택

  에이전트 품질을 프롬프트 감이 아니라 eval 루프로 올리는 흐름이 한 단계 더 올라왔다. 점수 개선된 하네스 변경만 남기는 방식이라, 커스텀 에이전트 굴리는 쪽이면 바로 훑어볼 가치가 있다.

  • —tau2-airline에서 best-of-N skillbook 스코어링+LLM 심사로 +40.7%. 평가기 설계 자체가 성능 레버로 올라왔다.
  • —리플렉터 하이퍼파라미터 조정만으로 +24.1% 상승. temperature, 서브에이전트 호출 수 같은 기본값도 아직 덜 최적화돼 있다.
  • —각 스텝마다 실행 컨텍스트를 주입하자 +22.2% 개선. step budget, 최근 툴 호출, 최근 결과를 계속 넣는 편이 유리했다.
  • —사용 흐름은 단순하다. 설치 후 Claude Code를 GUIDE.md에 연결하면 변경 제안, eval, 점수 상승분만 채택한다.
  • —숫자는 특정 벤치 기준이라 그대로 믿을 건 아니지만, 하네스를 자동 변이시키고 바로 검증하는 운영 패턴은 재사용성이 높다.

  출처: www.reddit.com/r/ClaudeAI/comments/1t8cn9y/claude_improv원문 보기 →
• #0003

  #0003에이전트·도구r/ClaudeAI3주 전

  이스케이프 한 번 잘못돼 `rd /S /Q \`로 **717GB** 날린 사고

  One Escaping Bug Turned `rd /S /Q \` Into a 717 GB Windows Wipe

  40radar

  폴더 하나 지우려던 명령이 셸을 여러 번 거치며 C:\ 루트 삭제로 바뀌었다. 디스크 작업을 AI에 맡길 때는 네이티브 명령과 -WhatIf 미리보기가 사실상 필수, 바로 적용할 만하다.

  • —원래 의도한 경로는 C:\Users\ADMIN\Desktop\WIP였지만 zsh→tmux→PowerShell→cmd를 지나며 rd /S /Q \로 붕괴됐다.
  • —약 90초 동안 진행돼 사용량이 748GB→31GB로 줄었다. 분리된 HDD 백업이 없었으면 운영체제와 작업물 대부분이 같이 증발했다.
  • —대안은 PowerShell Remove-Item -Path 'C:\absolute\path' -Recurse -Force -WhatIf 조합이다. 경로가 망가지면 실행 전 바로 드러난다.
  • —교훈은 모델 성능보다 운영 설계에 있다. 파괴적 명령은 실행 직전 최종 문자열을 에코하고, 가능하면 cmd /c 우회 없이 한 셸에서 끝내야 한다.

  출처: www.reddit.com/r/ClaudeAI/comments/1t923er/i_deleted_a_g원문 보기 →
• #0002

  #0002인프라·SaaSGeekNews3주 전

  `AWS` 북버지니아 장애 해결, `US-East-1` 과열이 원인

  `AWS` Virginia Outage Resolved After `US-East-1` Overheating Incident

  40radar

  US-East-1AWS 리전 — 북버지니아 기본 리전

  냉각 이슈가 실제 서비스 장애로 번지면서 US-East-1 단일 의존의 취약점이 다시 드러났다. 아직도 한 리전에만 묶여 있으면 멀티리전 대비 비용이 다운타임보다 싸다.

  • —원인은 북버지니아 데이터센터 과열. 단순 상태 페이지 경고가 아니라 리전급 가용성 문제로 번졌다.
  • —영향 사례로 Coinbase, FanDuel이 거론됐다. 결제·트랜잭션 성격 서비스가 직접 흔들렸다는 뜻이다.
  • —AWS는 금요일 오후 3시 29분 ET에 복구를 알렸다. 끝난 장애여도 단일 리전 구조면 같은 유형에 또 맞는다.

  출처: news.hada.io/topic?id=29337원문 보기 →
• #0001

  #0001기타GeekNews3주 전

  `NixOS` 비밀값, `Nix store`에 넣는 순간 읽힌다

  `NixOS` Secrets: Plaintext in `Nix store` Is Readable

  40radar

  NixOS리눅스 배포판 — 설정을 선언형으로 관리하는 OS

  비밀값을 Nix 설정이나 비공개 Git에 숨겨도 배포 뒤엔 Nix store에 남아 머신 접근자가 읽는다. NixOS로 운영 중이면 sops-nix를 기본값으로 깔아야 할 수준이며, 아니면 서버 비밀관리부터 다시 봐야 한다.

  • —Nix 설정에 박아 넣은 비밀값은 배포 후 Nix store로 흘러가고, 여기선 머신 사용자 누구나 읽을 수 있다.
  • —비공개 저장소에 두거나 git-crypt로 관리해도 빌드·배포 시 평문이 store에 남으면 소용없다. 문제 지점이 저장소에서 런타임으로 옮겨갈 뿐.
  • —sops-nix는 .sops.yaml 규칙과 sops 편집 흐름을 붙여 비밀파일을 관리한다. NixOS 운영 스택이면 우선 채택할 만하다.

  출처: news.hada.io/topic?id=29328원문 보기 →