VocabX 생성 비용 기준 어휘 선택: Qwen3-4B 채점 모델 비용 77% 절감의 검증 설계

• 보고된 사례의 내용
• 왜 어휘 선택이 비용을 바꾸는가
• 절감 수치 검증 설계
• 도입 시 고려사항
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

Dharma AI는 2026년 10월 21일 VocabX라는 특화 토크나이저로 포르투갈어 에세이 채점 모델(Qwen3-4B 기반)의 측정 추론 비용을 77.0% 줄였다고 밝혔다. 토큰 빈도 대신 생성 비용을 기준으로 어휘를 고른 사례로, 채점 모델을 대량 호출하는 평가 파이프라인에서는 모델 교체보다 입력 설계가 비용을 좌우할 수 있음을 보여준다. 이 글은 사례의 내용을 정리하고, 절감 수치의 측정 조건과 품질 영향을 분리해 검증하는 설계를 정보관리기술사의 관점에서 다룬다.

보고된 사례의 내용

검색된 보도와 PyTorch Korea 정리글 기준으로 다음이 보고되었다. 모두 한 회사의 발표에서 나온 값이며, 발표는 논문 공개 전 프리뷰라 수치가 바뀔 수 있다고 한다.

0.810이라는 점수는 등급 토큰을 분리한 변형에 해당하고, 합친 변형은 점수가 낮은 대신 비용 절감 폭도 다르다. 헤드라인 수치 하나로 요약하면 이런 조건 차이가 가려진다.

왜 어휘 선택이 비용을 바꾸는가

• 출력 계층 비중: LM head는 생성 토큰마다 어휘 전체 행을 점수화한다. Qwen3-4B에서는 이 행렬이 전체 파라미터의 약 10%에 이른다고 보도되었다. 어휘를 줄이면 이 계산이 줄어든다.
• 토큰 수 감소: 특정 도메인(포르투갈어 에세이, 채점 JSON)에 맞춘 어휘는 같은 내용을 더 적은 토큰으로 표현한다. 시스템 프롬프트, 사용자 입력, 응답 필드 각각에서 절감되는 비용을 가중해 토큰을 고른다는 것이 기준 변경의 핵심이다.
• 응답 구조: 응답이 짧아진 데에는 어휘뿐 아니라 출력 형식 설계의 영향이 섞여 있을 수 있어 분리해 봐야 한다.

절감 수치 검증 설계

절감률은 분모(기준 비용)와 측정 조건에 따라 달라진다. 검증은 비용과 품질을 분리해 다음 순서로 진행한다.

flowchart TD
    A["기준 구성 고정: 모델, 서빙 엔진, GPU, 배치 설정"] --> B["동일 요청 세트로 기준·후보 실행"]
    B --> C["비용 지표 측정: 요청당 지연, 토큰, GPU 시간, 단가 환산"]
    B --> D["품질 지표 측정: 채점 일치도, 규칙 위반 탐지율"]
    C --> E["절감 요인 분해: 어휘 크기, 입력 토큰, 응답 길이"]
    D --> F{"품질 허용 범위 이내?"}
    E --> F
    F -->|"예"| G["프로덕션 트래픽 일부로 섀도 검증"]
    F -->|"아니오"| H["변형 재설계 또는 도입 보류"]
    G --> I["절감률과 품질 재보고"]

1. 측정 조건 고정: GPU 종류, 서빙 엔진 버전, 배치 크기, 동시성, 입력 길이 분포를 기록한다. 보도된 500개 요청 규모는 작은 편이므로 자체 트래픽으로 다시 잰다.
2. 비용 지표 정의: 토큰 수만이 아니라 요청당 지연, 처리량, GPU 시간을 단가로 환산한 값을 함께 본다. 추정 비용과 실측 서빙 비용을 섞어 쓰지 않는다.
3. 절감 요인 분해: 어휘 축소(LM head 연산), 입력 토큰 감소, 응답 길이 감소 중 어디서 얼마나 줄었는지 단계별로 나눠 측정한다. 응답이 350에서 101토큰으로 줄어든 효과가 어휘 때문인지 출력 형식 때문인지 구분한다.
4. 품질 별도 평가: 비용과 분리한 평가셋에서 채점 일치도와 규칙 위반 탐지율을 측정한다. 자체 결합 지표 하나에 의존하지 않고 하위 지표를 따로 본다.
5. 분포 점검: 평균이 아니라 긴 에세이, 드문 오류 유형 같은 꼬리 구간에서 품질이 무너지지 않는지 확인한다.
6. 재학습·유지 비용 포함: 어휘를 바꾸면 모델 적응 비용과 토크나이저 호환성 관리 비용이 생긴다. 77%는 추론 비용만의 수치이므로 총소유비용으로 다시 계산한다.

도입 시 고려사항

• 적용 조건: 도메인과 언어가 좁고 출력 형식이 고정된 대량 호출 파이프라인에서 효과가 클 가능성이 높다. 범용 대화 모델에는 그대로 적용된다는 근거가 없다.
• 호환성: 어휘가 달라지면 기존 프롬프트, 캐시, 다른 모델과의 토큰 단위 비교가 깨진다.
• 재현성: 논문과 코드가 공개되기 전이므로 수치는 잠정값으로 보고, 공개 후 재확인한다.
• 저비용 대안 비교: 프롬프트 압축, 응답 형식 단순화, 양자화처럼 더 간단한 수단과 같은 조건에서 비교해 우선순위를 정한다.

마무리

VocabX 사례는 모델을 바꾸지 않고도 어휘 설계로 대량 채점 파이프라인의 비용을 크게 줄일 수 있다는 가능성을 보여 주지만, 수치는 한 회사의 프리뷰 발표이고 변형마다 품질과 절감 폭이 다르다. 절감률은 측정 조건을 고정하고 비용 요인을 분해해 확인하며, 품질은 별도 평가셋과 하위 지표로 독립 검증해야 한다. 총소유비용과 호환성 부담까지 포함해 판단할 때 도입 근거가 된다.

Keywords

VocabX, tokenizer specialization, vocabulary selection, inference cost, LM head, grader model, 생성 비용, 어휘 선택, 채점 모델, 추론 비용

Sources

• VocabX: 토큰 빈도 대신 생성 비용으로 어휘를 골라 Qwen3-4B 채점 모델의 추론 비용을 77% 줄인 사례 - PyTorch Korea
• VocabX: How a Custom SLM Vocabulary Cut Inference Cost 77% - Stack Archive
• VocabX Dharma AI vocabulary specialization cut inference cost 77 percent - explainx.ai
• Dharma AI says a new tokenizer cut its grader's measured inference cost 77% - Zipmex
• VocabX vocabulary specialization reports 77% lower inference cost - remio.ai
• The practical case for specialized vocabulary in small language models - Toksick Magazine

Google Sleep 지속 학습: 컨텍스트 지식을 파라미터로 옮기는 설계

• Sleep 프레임워크의 구조
• 보고된 결과와 해석의 한계
• 컨텍스트 주입과 파라미터 갱신의 경계
• 통합 대상 선별과 망각 방지 설계
• 검증 절차
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

Google Research는 2026년 10월 27일 블로그에서 Sleep 프레임워크를 소개했다. 서비스 중에는 컨텍스트로 새 지식을 받아들이고, 오프라인 통합 단계에서 그 지식을 기존 가중치를 덮어쓰지 않고 새로 추가한 파라미터로 옮기는 지속 학습(continual learning) 연구다. 컨텍스트 엔지니어링으로 관리하던 정보를 모델 갱신으로 넘길 때 무엇을 남기고 무엇을 잊지 않게 할지가 쟁점이므로, 이 글은 컨텍스트 주입과 파라미터 갱신의 경계, 망각 방지와 검증 절차를 정보관리기술사의 관점에서 설계한다.

Sleep 프레임워크의 구조

검색된 요약에 따르면 Google과 Cornell 연구진의 논문이며, 서비스 단계와 수면 단계를 번갈아 수행한다.

망각을 줄이는 방법으로는 기존 가중치를 직접 수정하는 대신 저랭크(low-rank) 전문가를 추가하고 그쪽으로 통합한다고 설명된다. 기존 연결과 간섭하지 않으면서 모델 용량을 늘리는 방식이다.

보고된 결과와 해석의 한계

연속 번역(처음 보는 언어를 단계적으로 학습) 평가에서 다단계에 걸쳐 성능 손실이 거의 없고, ICL·Cartridges·지도 미세조정(SFT)보다 망각이 적다고 보고되었다. 다만 다음 한계를 함께 읽어야 한다.

• 비교 대상(SFT, GRPO, OPSD, SEAL)을 저자가 선택했다. 지속 학습 논문은 설정에 따라 결과가 크게 달라진다.
• 개념 증명 단계이며 실서비스에서의 동작은 알려지지 않았다.
• 뉴스 기사의 수치는 2차 해석이므로 논문과 블로그 원문이 기준이다. 이 글도 원문 전체가 아니라 검색 요약에 의존한다.

컨텍스트 주입과 파라미터 갱신의 경계

모든 정보를 파라미터로 옮길 이유는 없다. 정보의 성질에 따라 두 경로를 나눈다.

특히 개인정보, 권한이 다른 문서, 곧 폐기될 정보는 파라미터로 옮기지 않는다. 한 번 가중치에 들어가면 삭제 요청이나 접근 통제에 대응하기 어렵기 때문이다.

통합 대상 선별과 망각 방지 설계

flowchart TD
    A["서비스 중 컨텍스트 지식 수집"] --> B{"통합 후보 선별"}
    B -->|"변경 잦음, 민감, 출처 필요"| C["컨텍스트로 유지"]
    B -->|"안정적, 반복 사용, 비민감"| D["수면 단계: 새 파라미터로 통합"]
    D --> E["회귀 평가: 기존 능력 보존 확인"]
    E --> F{"신규 지식 습득과 기존 성능 모두 통과?"}
    F -->|"예"| G["버전 태그 후 배포"]
    F -->|"아니오"| H["통합 폐기 또는 파라미터 롤백"]
    G --> I["사후 모니터링과 재통합 주기 점검"]

설계 원칙은 다음과 같다.

1. 통합 후보 기준 명문화: 안정성, 반복 사용 빈도, 민감도, 출처 필요 여부를 점수화한다.
2. 추가형 파라미터 유지: 기존 가중치는 고정하고 추가 모듈만 갱신하면 모듈 단위 롤백이 가능하다.
3. 버전 관리: 통합마다 모듈 버전, 입력 지식 목록, 평가 결과를 함께 기록한다.
4. 합성 데이터 점검: 드리밍이 생성한 연습 데이터는 모델 스스로의 오류를 강화할 수 있으므로 표본을 사람이 검토한다.

검증 절차

• 습득 검증: 통합한 지식을 컨텍스트 없이 묻는 질문으로 확인한다. 표현을 바꾼 질문도 포함해 암기가 아닌 일반화 여부를 본다.
• 망각 검증: 통합 전후에 같은 회귀 평가셋을 돌려 기존 능력 하락 폭을 측정한다. 평가셋은 통합 대상과 무관한 영역까지 넓게 구성한다.
• 누적 검증: 통합을 여러 차례 반복한 뒤의 성능을 본다. 단일 통합에서 괜찮아도 누적하면 간섭이 커질 수 있다.
• ICL 대조군: 같은 지식을 컨텍스트로 줬을 때와 비교해, 파라미터화가 실제로 이득인지 확인한다.
• 독립 재현: 논문의 결과는 저자 설정이므로 자체 데이터로 소규모 재현을 먼저 수행한다.

마무리

Sleep은 컨텍스트에 머물던 지식을 추가 파라미터로 옮겨 망각을 줄이려는 시도이지만, 아직 저자 설정의 개념 증명 결과다. 도입을 검토한다면 변경 주기, 민감도, 출처 요구에 따라 컨텍스트와 파라미터의 경계를 정하고, 습득·망각·누적을 따로 검증하며, 모듈 단위 롤백이 가능한 구조를 갖춰야 한다. 원문 논문과 블로그를 직접 확인해 수치를 재확인하는 것이 선행 조건이다.

Keywords

continual learning, Sleep framework, memory consolidation, catastrophic forgetting, low-rank experts, context engineering, 지속 학습, 기억 통합, 망각 방지, 컨텍스트 엔지니어링

Sources

• The Sleep framework: a new way for LLMs to retain knowledge in continual learning - Google Research
• Google's Sleep Framework Lets AI Models Keep Learning Without Forgetting - AlphaSignal
• Google Research Sleep framework: continual learning, memory consolidation, dreaming - explainx.ai
• Google wants language models to learn while they sleep - GoPenAI
• arXiv 2606.03979 논문 요약 - hyper.ai

Mistral Large 4 오픈 웨이트: 1T MoE 토큰 효율 주장의 검증 설계

• 보도된 사양과 확인되지 않은 부분
• 총 파라미터·활성 파라미터·토큰 사용량의 관계
• 벤더 주장 검증 절차
• 라이선스 조건을 도입 기준에 넣는 설계
• 한계와 주의점
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

Mistral이 약 1조(1T) 파라미터 규모의 MoE(Mixture of Experts) 모델 Mistral Large 4를 2026년 10월 6일 API 프리뷰로 먼저 선보였고, 10월 말 Hugging Face에 가중치를 공개한 것으로 보도되었다. PyTorch Korea는 이 모델이 코딩 성능은 GLM-5.3과 비슷하면서 토큰은 약 절반만 쓴다고 전했으나, 이는 게시물에 담긴 주장이며 독립 검증된 수치가 아니다. 이 글은 총 파라미터, 활성 파라미터, 토큰 사용량을 함께 놓고 벤더 주장을 자체 워크로드로 검증하는 절차와, 라이선스 조건을 도입 기준에 넣는 설계를 정보관리기술사의 관점에서 정리한다.

보도된 사양과 확인되지 않은 부분

보도와 검색 결과를 종합하면 확인된 사실과 불일치하는 부분이 섞여 있다.

활성 파라미터가 49B인지 52B인지처럼 사소해 보이는 불일치도, 비용 산정의 입력값이므로 도입 검토서에는 출처와 함께 범위로 적는 편이 안전하다. 공개 여부와 라이선스 문구는 2차 보도가 아니라 저장소의 LICENSE 파일을 직접 읽어 확인해야 한다.

총 파라미터·활성 파라미터·토큰 사용량의 관계

MoE는 총 파라미터가 커도 토큰마다 일부 전문가만 활성화한다. 그래서 세 값은 서로 다른 비용을 가리킨다.

• 총 파라미터: 가중치 저장과 적재에 필요한 메모리를 결정한다. 1T급이면 데이터센터급 GPU 여러 장이 필요하다.
• 활성 파라미터: 토큰당 연산량을 결정한다. 지연시간과 처리량의 근거가 된다.
• 토큰 사용량: 같은 과제를 끝내기까지 생성하는 토큰 수다. 과금과 총 소요 시간에 곱해진다.

"토큰을 절반만 쓴다"는 주장은 세 번째 값에 대한 것이다. 이것이 곧 총비용 절반을 뜻하지는 않는다. 과제당 비용은 대략 (입력 토큰 × 입력 단가 + 출력 토큰 × 출력 단가)이고, 자체 호스팅이라면 여기에 GPU 상주 비용이 추가된다. 출력 토큰이 절반이어도 총 파라미터가 커서 GPU 대수가 늘면 자체 호스팅 비용은 오히려 높을 수 있다.

벤더 주장 검증 절차

flowchart TD
    A["벤더 주장 수집: 출처와 측정 조건 기록"] --> B["자체 워크로드 평가셋 구성"]
    B --> C["기준 모델과 후보 모델 동일 조건 실행"]
    C --> D["지표 측정: 정확도, 과제당 토큰, 지연, 비용"]
    D --> E{"주장 재현 여부"}
    E -->|"재현"| F["라이선스와 운영 조건 검토"]
    E -->|"불일치"| G["조건 차이 분석 후 도입 보류 또는 재평가"]
    F --> H{"도입 기준 충족?"}
    H -->|"예"| I["단계적 도입과 사후 모니터링"]
    H -->|"아니오"| G

절차의 핵심은 다음과 같다.

1. 주장 분해: "코딩 성능 동급"과 "토큰 절반"을 별개의 검증 항목으로 나누고, 각각의 벤치마크 종류, 추론 설정(사고 예산, 온도), 토큰 계수 방식을 기록한다.
2. 평가셋 구성: 실제 업무의 코드 과제를 난이도별로 추려 쓴다. 공개 벤치마크는 학습 데이터 오염 가능성이 있으므로 보조로만 쓴다.
3. 동일 조건 비교: 같은 프롬프트, 같은 도구 권한, 같은 최대 출력 길이로 기준 모델과 후보를 돌리고, 시도 횟수를 늘려 분산을 확인한다.
4. 토큰은 과제 단위로 측정: 토크나이저가 모델마다 달라 같은 문장도 토큰 수가 다르다. 토큰 수 자체보다 과제당 비용(달러)과 완료까지 시간으로 환산해 비교한다.
5. 품질과 효율을 함께 판정: 토큰이 적어도 성공률이 낮으면 재시도로 총비용이 늘어난다. 성공한 과제당 비용으로 보고한다.

라이선스 조건을 도입 기준에 넣는 설계

오픈 웨이트는 오픈소스와 같은 말이 아니다. 보도된 수정 MIT 조건처럼 사용 범위에 제한이 붙을 수 있으므로 기술 평가와 같은 비중으로 다룬다.

• 상업 이용 범위: 사내 사용, 고객 제공 서비스, 모델 재판매 각각의 허용 여부
• API 제공 제한: 모델을 API로 판매하는 경우의 추가 조건 유무
• 파생물 처리: 파인튜닝·증류한 모델의 공개 의무와 라이선스 승계
• 버전 고정: 라이선스가 바뀔 때 기존 배포본에 적용되는 조건
• 법무 검토 기록: 검토한 라이선스 원문의 해시 또는 커밋을 남겨 추후 감사에 대비

도입 기준표는 성능, 과제당 비용, 인프라 요건(GPU 대수·메모리), 라이선스 적합성, 공급 지속성을 항목으로 두고, 라이선스 부적합은 다른 점수와 무관하게 탈락시키는 필수 조건으로 지정하는 것이 바람직하다.

한계와 주의점

• 이 글의 사양과 공개 사실은 2차 보도와 검색 요약에 의존하며, 원문 저장소와 모델 카드를 직접 열어 확인한 것이 아니다.
• 토큰 절반이라는 수치는 측정 조건이 공개되지 않아 재현 가능성을 알 수 없다.
• 자체 평가셋의 규모가 작으면 결과의 신뢰구간이 넓다. 결론은 범위로 제시한다.

마무리

Mistral Large 4의 토큰 효율 주장은 총 파라미터, 활성 파라미터, 토큰 사용량이 서로 다른 비용을 가리킨다는 점을 구분해야 평가할 수 있다. 벤더 수치는 출처와 측정 조건을 기록한 뒤 자체 워크로드에서 성공한 과제당 비용으로 재측정하고, 라이선스는 성능과 같은 비중의 필수 도입 기준으로 다뤄야 한다. 공개 여부와 사양의 불일치는 원문 저장소에서 직접 확인한 뒤 도입 결정에 반영해야 한다.

Keywords

open-weight model, mixture of experts, active parameters, token efficiency, license review, workload benchmark, 오픈 웨이트, 활성 파라미터, 토큰 효율, 라이선스 검토

Sources

• Mistral launches public preview of AI model with 1 trillion parameters - ForkLog
• Mistral Large 4 preview open weights - BetaNews
• Mistral Large 4 specs, API pricing and open weights for engineers - mer.vin
• Mistral Opens Public Preview of Large 4 - Let's Data Science
• Mistral Large 4 on Hugging Face: Weights, License, vLLM Setup - Developers Digest
• Mistral Large 4 Le Chonk open weights Hugging Face - Pasquale Pillitteri

JavaScript 프레임워크별 AI 개발 비용 비교: 에이전트 시대 프레임워크 선정 기준 설계

• 실험 설계: 12개 조합과 측정 방법
• 비용·시간·토큰 결과
• 코드 크기와 성능 결과
• 대표성의 한계
• 프레임워크 선정 기준 설계
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

Nolan Lawson은 2026년 10월 28일 "The AI cost of JavaScript frameworks"에서 같은 포켓몬 앱을 12개 프레임워크 조합으로 Claude Opus 5.5에 만들게 하고 비용, 소요 시간, 코드 크기, 성능을 비교했다. 프레임워크 선택이 AI 생성 비용과 결과물에 실제로 차이를 만든다는 점을 수치로 보여준 드문 사례다. 이 글은 실험의 결과를 정리하고, 단일 실험의 대표성 한계를 짚은 뒤, 에이전트 기반 개발에서 프레임워크 선정 기준을 토큰 원가, 검증 용이성, 유지보수성의 관점에서 설계하는 방법을 다룬다.

실험 설계: 12개 조합과 측정 방법

모든 에이전트는 샌드박스 안에서 Claude Code를 통해 Claude Opus 5.5(high effort)로 실행되었다. 같은 명세를 받아 PokéAPI 기반의 포켓몬 목록, 타입·기술·게임 데이터, 검색과 필터링 기능을 구현했다.

• 프레임워크: Angular, Astro, Gracile+Lit, Hono+htmx, Next.js, Nuxt, Qwik, React Router, SolidStart, SvelteKit, TanStack Start, 그리고 프레임워크 없이 Vite만 쓰는 Vanilla.
• 반복 횟수: 프레임워크당 5회 실행의 중앙값을 보고한다. Angular는 2회가 측정 가능한 앱을 만들지 못해 일부 지표가 3회 기준이다.
• 제약: Tailwind 같은 컴포넌트 프레임워크는 금지했고, SSR/CSR 구조는 지정하지 않았으며, 성능 최적화를 지시하지 않았다. 사전 생성된 정적 HTML은 금지하고 검사했다.
• 적합성 검증: DOM이 아니라 접근성 트리를 기준으로 한 테스트 스위트를 사용했다.
• 성능 측정: Lighthouse 모바일 에뮬레이션(CPU 4배 스로틀, Slow 4G), 홈 페이지만 대상이다.
• 비용: Claude Code가 보고하는 API 가격 기준이며 실제 지출이 아니다.

일부 프레임워크에는 MCP나 스킬이 주어졌지만 사용은 일관되지 않았다. Angular MCP는 5회 중 3회, SvelteKit MCP는 5회 모두 쓰였고, Nuxt MCP는 한 번도 쓰이지 않았다.

flowchart LR
    A["동일 명세<br/>포켓몬 앱"] --> B["12개 프레임워크 조합"]
    B --> C["Opus 5.5 에이전트<br/>조합당 5회"]
    C --> D["비용·시간·토큰"]
    C --> E["코드 라인 수"]
    C --> F["Lighthouse 모바일"]
    D --> G["중앙값 비교"]
    E --> G
    F --> G

비용·시간·토큰 결과

중앙값 기준으로 가장 저렴한 조합과 가장 비싼 조합의 차이는 약 1.9배, 시간은 약 2배였다.

비용은 대체로 토큰 총량과 함께 움직인다. 다만 실행 간 편차가 크다. Angular의 비용 범위는 3.196.82달러이고 Hono+htmx는 2.233.19달러여서, 두 범위는 경계에서 겹친다. 저자는 SvelteKit의 비용이 새 v3 마이그레이션 가이드를 읽은 영향일 수 있고, Gracile 에이전트는 프레임워크에 어려움을 겪어 소스 코드를 직접 읽었다고 해석한다.

코드 크기와 성능 결과

코드 크기는 비공백 소스 라인 수 중앙값 기준이다. Hono+htmx가 1,370줄로 가장 작고 Nuxt가 1,415줄, Angular가 2,009줄로 가장 크다. Hono+htmx는 Angular 대비 약 68% 분량으로 비슷한 결과를 냈고 더 빨랐다. 저자는 코드 크기를 장기 유지보수 비용으로 본다. 이후 수정 작업마다 에이전트가 읽고 쓰는 토큰이 늘어나기 때문이다.

접근성(Accessibility)은 12개 조합 모두 100점이었고 CLS도 거의 포화 상태였다. 전송되는 JS 양은 클라이언트 프레임워크의 크기를 따라가며, LCP는 번들 크기와 대체로 연동되어 MPA 방식에 유리했다. 주목할 점은 Vanilla(Vite)가 여러 프레임워크보다 낮게 나왔다는 것으로, 저자는 프레임워크가 무프레임워크보다 에이전트 생산성에 유리할 수 있다고 본다. Vanilla 에이전트는 5회 모두 SPA를 만들었고 이것이 LCP와 CLS(0.111)에 영향을 주었다.

대표성의 한계

이 실험은 의미 있는 출발점이지만 결과를 그대로 일반화하기는 어렵다. 저자 스스로 밝힌 한계와 함께 정리하면 다음과 같다.

• 앱 유형: 포켓몬 앱은 Wikipedia에 가까운 콘텐츠형, 저상호작용 사이트다. Figma나 Gmail 같은 고상호작용 대형 앱을 대표하지 못한다.
• 지표 편향: Lighthouse와 Core Web Vitals는 MPA에 유리하다. 인앱 상호작용 지표는 검토했으나 쓰지 않았다.
• 확률적 변동: LLM 출력의 분산이 크고, 일부 실행은 곁길로 새어 토큰을 낭비했다. 5회 중앙값은 표본으로 작다.
• 도구 사용 불균형: MCP와 스킬을 쓴 실행과 안 쓴 실행이 섞였고, 일부 프레임워크에는 도구가 아예 없었다.
• 조건 이탈: Angular 2회는 역방향 프록시 뒤에서 동작해야 한다는 지시를 어긴 SSR 앱을 만들었고, Gracile 2회는 Lit을 쓰지 않았다. 라벨과 실제 구성이 다른 실행이 있다.
• 미검증 영역: Chromium 외 브라우저, 데스크톱, 다른 effort 수준, 다른 에이전트, 다른 프레임워크 버전, MCP/스킬 유무 비교는 다루지 않았다.

정보관리 관점에서 보면, 이 결과는 "프레임워크 A가 B보다 낫다"는 결론이 아니라 "특정 모델·명세·측정 조건에서 이런 분포가 관측되었다"는 증거로 읽어야 한다. 모델이나 프레임워크 버전이 바뀌면 순위는 달라질 수 있다.

프레임워크 선정 기준 설계

실험이 주는 가장 실용적인 교훈은 프레임워크 선정에 새로운 평가 축이 생겼다는 것이다. 익숙함이나 생태계 규모에 더해 다음 세 축을 명시적으로 평가표에 넣을 수 있다.

운영 방식은 다음과 같이 제안할 수 있다.

1. 자체 벤치마크: 조직의 대표 기능 한두 개를 명세로 만들어 후보 프레임워크마다 최소 5회 실행하고, 중앙값과 범위를 함께 기록한다.
2. 자동 검증 게이트: 구현 방식에 의존하지 않는 접근성 트리 테스트처럼, 프레임워크 중립적인 적합성 테스트를 먼저 만든다. 에이전트의 결과를 사람이 일일이 보지 않아도 되는 근거가 된다.
3. 성능 지표 보정: 앱 유형에 맞는 지표를 고른다. 대화형 앱이라면 초기 로드 지표만이 아니라 인앱 상호작용 지표를 포함한다.
4. 재평가 주기: 모델과 프레임워크 버전이 바뀌면 결과가 달라지므로, 주기적으로 재측정하는 절차를 둔다.
5. 도구 효과 분리: MCP와 스킬의 유무를 분리해 측정한다. 저자는 현재의 MCP와 스킬이 득보다 실이 될 수 있다고 의심하는데, 이는 검증되지 않은 가설이므로 조직 환경에서 직접 확인해야 한다.

토큰 원가는 한 번의 생성 비용만이 아니라 이후 수정 작업에 반복 발생한다는 점도 반영해야 한다. 이 실험은 초기 생성만 측정했으므로, 장기 비용은 코드 크기를 대리 지표로 추정할 수밖에 없다.

마무리

12개 조합 실험은 같은 앱이라도 프레임워크에 따라 비용이 최대 약 1.9배, 시간이 약 2배 차이 날 수 있음을 보였다. 다만 콘텐츠형 단일 앱, 5회 중앙값, MPA에 유리한 지표라는 조건 때문에 순위를 일반 법칙으로 받아들이기는 어렵다. 에이전트 기반 개발에서는 토큰 원가, 검증 용이성, 유지보수성을 평가 축으로 삼고, 자체 명세로 반복 측정해 근거 기반으로 프레임워크를 선정하는 절차를 설계하는 것이 합리적이다.

Keywords

AI coding agent, token cost, framework selection, Lighthouse, maintainability, AI 코딩 에이전트, 토큰 원가, 프레임워크 선정, 검증 용이성, 유지보수성

Sources

• The AI cost of JavaScript frameworks (Nolan Lawson, 2026-10-28)
• Software and other dark arts, by Nolan Lawson

EMBRACE: AI 코딩 도구 내장 브라우저의 신뢰 경계 재설계

• EMBRACE 개요
• 도구별 결함 분석
• 공격 흐름과 신뢰 경계
• 벤더 대응의 쟁점: Workspace Trust
• 정보관리기술사 관점의 설계 과제
  • 권한 모델
  • 콘텐츠 격리
  • 도구별 패치 추적 체계
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

2026년 10월 29일 Forever Security는 Cursor, GitHub Copilot, Claude Desktop, VS Code, Codex 등 다섯 가지 AI 코딩 도구의 내장 브라우저에서 같은 계열의 결함을 확인했다고 공개했다. 연구진은 이 결함군을 내장 브라우저(EMbedded BRowser)의 약어인 EMBRACE로 명명했으며, 공통 원인은 내장 브라우저를 일반 브라우저처럼 신뢰하면서도 일반 브라우저에 없는 권한을 부여한 설계에 있다. 개발 도구가 여는 브라우저는 웹 콘텐츠와 개발자 권한이 가까이 있으므로, 웹 콘텐츠를 신뢰하지 않는 경계를 어디에 둘지가 핵심 쟁점이다.

EMBRACE 개요

EMBRACE는 AI 어시스턴트에 내장된 브라우저가 에이전트 제어, 로컬 파일 접근, 명령 실행 승인 UI와 결합되면서 생기는 취약점 계열이다. 일반 브라우저는 페이지를 샌드박스에 가두고 사용자가 주소와 권한을 직접 판단하지만, 내장 브라우저는 에이전트가 대신 조작하고 도구가 생성한 링크를 신뢰된 출처로 제시한다. 연구진은 이 차이가 공격에 필요한 사용자 클릭을 "신뢰된 출처의 한 번의 승인"으로 바꾼다고 지적했다.

도구별 결함 분석

Cursor 사례에서는 악성 페이지가 무해해 보이는 HTML 요소에 명령을 숨기고, 에이전트가 요청한 실행을 사용자가 Enter 한 번으로 승인하면 샌드박스 밖에서 호스트 코드가 실행되었다. 다만 연구진은 이 동작이 모델에 따라 달라 매번 재현되지는 않는다고 밝혔다. 파일 읽기 결함에서는 보고서처럼 보이는 로컬 파일을 열면 웹 워커가 폴더 인덱스를 따라 디스크를 탐색하고, 시험에서 SSH 키, .env, npm 토큰, hosts 파일이 수집되었다.

공격 흐름과 신뢰 경계

flowchart LR
    A["악성 웹/로컬 파일"] --> B["내장 브라우저"]
    B --> C{"신뢰 경계 검사"}
    C -->|"경계 없음"| D["에이전트 지시 주입"]
    C -->|"경계 없음"| E["워커 기반 파일 읽기"]
    D --> F["호스트 코드 실행"]
    E --> G["자격증명 유출"]
    C -->|"격리 적용"| H["차단 및 로그"]

세 가지 경계가 무너졌다. 첫째 콘텐츠와 지시의 경계로, 페이지 텍스트가 에이전트 명령으로 해석되었다. 둘째 출처 표시의 경계로, 페이지가 자기 주소를 스스로 보고하게 두었다. 셋째 파일 시스템의 경계로, 폴더 제한이 워커 같은 부수 실행 컨텍스트에 미치지 못했다.

벤더 대응의 쟁점: Workspace Trust

Anthropic과 Microsoft는 초기 제보를 Workspace Trust 경계상 무효로 분류했다. 사용자가 작업 공간을 신뢰하기로 한 이상 그 안의 파일은 신뢰 대상이라는 논리다. 그러나 Anthropic은 하루 뒤 Noma Security의 동일 제보를 유효로 받아들였다. 이는 "신뢰한 작업 공간"과 "신뢰한 적 없는 외부 콘텐츠를 도구가 열어 주는 행위"를 구분해야 한다는 점을 보여 준다. 도구가 생성한 링크는 사용자가 신뢰를 부여한 것이 아니다.

정보관리기술사 관점의 설계 과제

권한 모델

내장 브라우저의 권한은 최소 권한으로 분리한다. 외부 URL용 컨텍스트에는 에이전트 제어 API, 로컬 파일 접근, 명령 실행 승인 UI를 연결하지 않는다. 로컬 파일 미리보기는 별도 오리진과 읽기 범위 허용 목록으로 제한하고, 웹 워커와 서비스 워커 등 모든 하위 실행 컨텍스트에 같은 정책을 적용한다.

콘텐츠 격리

페이지 콘텐츠는 데이터로만 취급하고 에이전트 입력에서 지시 채널과 분리한다. 샌드박스 차단 시 샌드박스를 스스로 해제하는 동작은 금지하고, 정책 변경은 별도의 명시적 사용자 승인으로만 허용한다. 주소 표시는 페이지 자기 보고가 아니라 브라우저 엔진이 확인한 실제 탐색 URL만 사용한다.

도구별 패치 추적 체계

• 자산 목록: 개발자 단말에 설치된 AI 도구와 내장 브라우저 컴포넌트를 별도 자산으로 등록한다.
• 버전 기준선: Copilot 1.1.29처럼 수정 버전이 확인된 도구는 최소 허용 버전을 정책화한다.
• 상태 분류: 패치됨, 자문 없는 패치, 미패치, 상태 불명으로 구분해 추적한다. Cursor처럼 보안 자문 없이 패치되는 경우를 위해 릴리스 노트 감시를 병행한다.
• 보완 통제: 미패치 도구는 신뢰할 수 없는 로컬 HTML 열기 금지, 비밀 정보가 있는 홈 디렉터리 분리, 단말 로그 모니터링으로 보완한다.

마무리

EMBRACE는 내장 브라우저가 일반 브라우저의 신뢰 모델을 그대로 가정하면서 에이전트 권한까지 얻은 구조적 결함이다. 클릭이나 승인 한 번을 방어선으로 삼는 설계는 도구가 생성한 링크 앞에서 무력해진다. 권한 분리, 콘텐츠와 지시의 격리, 도구별 패치 상태 추적을 하나의 거버넌스 체계로 묶는 것이 필요하다. 다만 일부 도구의 수정 상태는 보도 시점 기준이므로 벤더 공지로 재확인해야 한다.

Keywords

EMBRACE, Embedded Browser, Trust Boundary, Prompt Injection, Workspace Trust, 내장 브라우저, 신뢰 경계, 권한 모델, 콘텐츠 격리, 패치 추적

Sources

• EMBRACE: How We Hacked the Browsers Embedded in Top Five Desktop AI Assistants - Forever Security
• Researchers find bugs in 5 AI developer tools, with OpenAI and Microsoft flaws still unpatched - The Register
• EMBRACE Flaws in 5 AI Coding Tools Enable Code Execution and File Theft - Hackread
• Forever Security 'EMBRACE' Research Breaks Five AI Coding Browsers - AI Weekly

Claude Code 게임 재구현 거부 규칙: 프롬프트 정책과 도구 통제의 역할 분리 설계

• 확인된 사실과 확인되지 않은 부분
• 프롬프트 정책의 성격
• 도구·권한 수준 통제와의 역할 분리
• 원작과 장르의 경계 판정
• 운영상 점검 항목
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

Claude Opus 5.5용 Claude Code 프롬프트에 "특정 타인의 게임을 재구현하지 말라"는 취지의 문장 두 개가 추가된 사실이 알려졌다. 게임 전문 매체 보도에 따르면 Anthropic은 10월 30일 이 변경을 확인했고, 근거로 IP 침해가 사용 정책 위반이라는 점을 들었다. 이 글은 확인된 사실과 확인되지 않은 부분을 구분한 뒤, 프롬프트 수준 정책과 도구·권한 수준 통제의 역할을 어떻게 나눌지, 원작과 장르의 경계를 어떻게 판정할지 정보관리기술사의 관점에서 정리한다.

확인된 사실과 확인되지 않은 부분

웹 검색으로 확인한 내용은 다음과 같다.

규칙의 정확한 문구와 게시 경위는 1차 자료에서 확인하지 못했으므로, 이 글은 보도된 범위만 전제로 설계 논점을 다룬다.

프롬프트 정책의 성격

시스템 프롬프트의 금지 문장은 모델의 기본 행동을 바꾸는 소프트 통제다. 구현 비용이 낮고 배포가 빠르지만 다음 한계가 있다.

• 강제력이 없다: 모델이 문장을 어길 수 있고, 사용자의 표현 우회에 약할 수 있다.
• 판정 기준이 모델 내부에 있다: 어떤 요청이 "특정 타인의 게임"인지는 모델의 해석에 달려 있어 일관성을 감사하기 어렵다.
• 변경 이력이 곧 정책 이력이다: 프롬프트 변경 자체가 정책 변경이므로 버전과 변경 사유를 기록해야 한다.

도구·권한 수준 통제와의 역할 분리

flowchart TD
    A["사용자 요청"] --> B{"프롬프트 정책: 특정 타인의 게임 재현 요청인가?"}
    B -->|"예"| C["거절 및 대안 제시: 장르 기반 오리지널 설계"]
    B -->|"아니오 또는 불명확"| D["작업 진행"]
    D --> E["도구·권한 계층: 외부 자산 반입, 역컴파일, 다운로드 통제"]
    E --> F{"산출물 검토 게이트: 상표, 자산, 고유 표현 포함 여부"}
    F -->|"의심"| G["사람 검토 및 기록"]
    F -->|"통과"| H["산출물 전달"]

권장하는 역할 분담은 다음과 같다.

1. 프롬프트 정책: 의도가 명백한 요청을 초기에 거절하고 대안을 안내한다. 사용자 경험과 정책 의사 표시를 담당한다.
2. 도구·권한 통제: 외부 자산 다운로드, 바이너리 역분석 도구 실행, 네트워크 접근 같은 행위를 허용 목록과 승인 절차로 막는다. 모델의 해석과 무관하게 작동하는 하드 통제다.
3. 산출물 검토 게이트: 생성물에 원작의 고유 자산, 이름, 레벨 구조가 들어갔는지 사후에 점검한다.

프롬프트만으로 IP 위험을 관리한다고 보면 우회에 취약하고, 도구 통제만으로 관리하면 정상적인 장르 작업까지 막는 과차단이 생긴다. 두 계층이 서로의 약점을 보완하도록 설계하는 것이 핵심이다.

원작과 장르의 경계 판정

보도에 따르면 장르 안의 게임은 허용된다. 그러나 "레이싱 게임"과 "특정 프랜차이즈를 본뜬 레이싱 게임"의 경계는 연속적이다. 판정 기준 후보는 다음과 같다.

• 명시성: 요청에 특정 작품명, 캐릭터, 고유 용어가 포함되어 있는가
• 고유 표현의 재현: 장르 관행(조작 방식, 승패 규칙)이 아니라 고유한 캐릭터, 맵, 아트, 스토리를 재현하려는가
• 재현 충실도: 원작과의 일대일 대응을 목표로 하는가
• 사용자 자료의 출처: 사용자가 제공한 자료가 본인의 설계인가, 타인의 자산인가

한계도 분명하다. 게임 규칙 자체는 저작권 보호 범위가 좁은 반면, 표현은 보호받는 등 법적 판단은 관할과 사안에 따라 다르다. 모델이 법적 판단을 대신할 수 없으므로 경계 사례는 사람의 검토나 정책 담당자의 에스컬레이션으로 넘기는 경로가 필요하다.

운영상 점검 항목

• 거절 사례와 허용 사례를 평가 세트로 만들어 프롬프트 변경마다 회귀 점검을 한다.
• 오거절(정상 장르 작업 차단)과 미거절(원작 재현 통과) 비율을 함께 측정한다.
• 거절 시 대안(오리지널 설계로의 전환)을 제시해 사용자 이탈을 줄인다.
• 규칙 변경을 릴리스 노트와 내부 정책 문서에 연결해 감사 추적을 남긴다.

마무리

이번 규칙은 프롬프트 한 줄로 IP 위험의 입구를 줄이는 사례다. 그러나 프롬프트는 강제력이 없는 소프트 통제이므로 도구·권한 통제와 산출물 검토를 함께 두어야 한다. 원작과 장르의 경계는 법적·해석적 불확실성이 크기 때문에, 판정 기준과 에스컬레이션 경로, 오거절·미거절 지표를 설계 단계에서 명문화해야 한다.

Keywords

prompt policy, IP infringement, tool permission control, genre boundary, usage policy, game reimplementation, 프롬프트 정책, 지식재산권, 권한 통제, 장르 경계

Sources

• Anthropic orders AI tool Claude to stop remaking video games - Game Developer
• Anthropic nerfs Claude again to stop users from making AI slop out of any specific existing game - Kotaku
• Anthropic Claude Code rule on existing game recreations - Magica

Claude Code 팀의 코드 리뷰 변경: 처리량과 품질 지표를 함께 읽는 설계

• 보고된 수치와 그 범위
• 리뷰 구조: 다층 검사와 위험도별 사람 승인
• 두 지표를 함께 읽는 이유
• 측정 설계 권장안
• 측정 기간과 표본의 한계
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

Claude Code 팀이 코드 리뷰 방식을 바꾼 뒤 병합 PR이 2배 넘게 늘고 되돌림(revert) 비율은 40% 넘게 줄었다는 내용이 PyTorch Korea 포럼에 번역·정리되었다. 병합 수만 보면 생산성이 올랐다고 읽히고 되돌림율만 보면 품질이 올랐다고 읽히므로, 두 지표는 짝으로 해석해야 한다. 이 글은 보고된 수치와 리뷰 구조를 정리하고, 리뷰 프로세스 변경의 효과를 측정하는 설계와 한계를 정보관리기술사의 관점에서 다룬다.

보고된 수치와 그 범위

PyTorch Korea 정리글이 전하는 원문 기준 수치는 다음과 같다.

내부 리뷰 지표의 비교 기간과 PR 수도 공개되지 않았다. 또 정리글 자체가 GPT 모델로 만든 초안을 바탕으로 한다고 밝히고 있어, 세부는 원문 블로그 확인이 필요하다. 이 글은 원문에 직접 접근하지 못했으므로 정리글과 검색 요약에 의존한다.

리뷰 구조: 다층 검사와 위험도별 사람 승인

정리글이 소개하는 구조는 병합 전 여섯 겹과 병합 후 안전장치로 요약된다.

flowchart TD
    A["작성자 사전 검증과 새 컨텍스트 서브에이전트 리뷰"] --> B["AI 리뷰: 다중 에이전트 탐지와 투표 검증"]
    B --> C["보안 리뷰: 열린 지적이 있으면 병합 불가"]
    C --> D["필수 CI: 린트, 타입, 다중 플랫폼 테스트, 빌드"]
    D --> E{"위험도 분류기"}
    E -->|"낮음"| F["사람 승인 불필요"]
    E -->|"중간"| G["사람 1명 승인"]
    E -->|"높음"| H["사람 2명 승인"]
    F --> I["병합 큐, 기능 플래그, 단계적 배포"]
    G --> I
    H --> I
    I --> J["빠른 롤백과 온콜"]

특징은 위험 등급을 작성자가 아니라 변경 내용을 보는 분류기가 판단한다는 점, 에이전트의 승인은 사람 승인으로 치지 않는다는 점이다. 병합 후에는 플래그 차단과 빠른 롤백으로 대부분의 실수를 몇 분 안에 되돌린다고 한다.

두 지표를 함께 읽는 이유

• 병합 PR 수만 볼 때: 리뷰가 느슨해져 통과가 쉬워진 경우에도 수치가 오른다.
• 되돌림율만 볼 때: 병합 자체가 줄어 위험한 변경이 올라오지 않아도 비율이 내려간다.
• 함께 볼 때: 병합이 늘면서 되돌림 비율이 내려가면, 처리량 증가가 품질 저하로 상쇄되지 않았다는 정황 근거가 된다.

다만 정황일 뿐이다. 비율은 분모가 커지면 분자가 같아도 내려간다. 병합 PR이 2배가 되면 되돌림 건수가 그대로여도 비율은 절반이 되므로, 비율과 함께 절대 건수를 같이 보고해야 한다.

측정 설계 권장안

처리량과 품질 지표를 나누어 정의한다.

1. 처리량 지표: 병합 PR 수, 변경 크기 분포, 리드타임(생성부터 병합까지)
2. 품질 지표: 되돌림 건수와 비율, 병합 후 결함·사고 건수, 롤백까지 걸린 시간
3. 리뷰 과정 지표: 1회차 통과율, 재리뷰 횟수, 잘못된 지적(노이즈) 빈도
4. 보정 변수: PR 크기, 변경 유형, 작성 주체(사람·에이전트) 비율

측정 기간과 표본의 한계

• 기준값 비공개: 상대 변화만 알려져 실제 규모를 판단하기 어렵다.
• 동시 도입: 여러 장치가 함께 도입되어 개별 기여도를 분리할 수 없다.
• 탐지 지연: 잘못된 병합을 알아차리는 일은 여전히 작성자, 온콜, 대시보드에 의존하고, 지표로 승인 기준을 자동 강화하는 서킷 브레이커는 아직 없다고 정리글은 밝힌다.
• 기간 4개월: 되돌림은 병합 후 시간이 지나 발견되는 경우가 있어 최근 병합분은 아직 되돌림이 덜 쌓였을 수 있다.
• 일반화 한계: 자사 제품을 자사 도구로 개발하는 팀의 사례이므로 다른 조직에 그대로 적용된다는 근거는 없다.

따라서 도입 조직은 변경 전 기준선을 먼저 측정하고, 장치를 단계적으로 도입해 효과를 분리하며, 최소 몇 개월의 후행 관찰 기간을 둔 뒤 평가해야 한다.

마무리

병합 PR 증가와 되돌림 감소는 함께 읽을 때 의미가 있으나, 비율 지표의 분모 효과와 기준값 비공개 때문에 단독 근거로 삼기에는 부족하다. 처리량, 품질, 리뷰 과정 지표를 나누고 절대 건수를 병기하며, 변경 전 기준선과 후행 관찰 기간을 확보하는 설계가 필요하다. 위험도별 사람 승인과 롤백 체계를 함께 두는 구조는 참고할 만하되, 효과 크기는 원문과 자체 측정으로 확인해야 한다.

Keywords

code review, merged PR, revert rate, throughput metric, quality metric, risk-tiered approval, 코드 리뷰, 병합 PR, 되돌림 비율, 처리량 지표

Sources

• Claude Code 팀의 코드 리뷰 방식: 병합 PR이 2배로 늘 때 되돌림 비율은 40% 넘게 줄인 방법 - PyTorch Korea
• how claude code team does code review - alexop.dev
• how the claude code team does code review - TechBytes
• Bringing Code Review to Claude Code - Claude Blog

DeepSeek Super-Agent 프로토타입: 팀 채팅 기반 티켓 코딩 에이전트의 구조와 한계

• 공개된 구조
• 처리 흐름
• 명시된 한계
• 프로덕션 기준 검토 항목
  • 채팅 기반 작업 수집의 데이터 경계
  • 저장소 단위 권한 범위
  • 사람의 승인 지점
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

DeepSeek은 MIT 라이선스로 dsh-superagent 프로토타입을 공개했다. GitHub 저장소 하나를 대상으로 요청을 받아 작업 항목 단위로 처리하는 코딩 에이전트이며, README는 이를 연구용 프로토타입이자 공식 제품이 아니라고 명시한다. 이 글은 README에서 확인되는 구조를 정리하고, 정보관리기술사가 프로덕션 도입 기준으로 검토해야 할 데이터 경계, 저장소 단위 권한, 사람의 승인 지점을 다룬다.

공개된 구조

README 기준으로 확인되는 내용은 다음과 같다.

• 대상: GitHub 저장소 하나에 붙는 선제적(proactive) 코딩 에이전트이며 DeepSeek Harness용 번들로 제공된다.
• 입력 채널: 주 채널은 GitHub이고, 팀 채팅 도구로는 Feishu를 선택적으로 연결한다.
• 작업 방식: 허용된 사람이 요청하면 작업 항목을 열고, 별도의 에이전트 세션과 디렉터리에서 실행한 뒤, 원래 대화에 결과(예: Pull Request)를 회신한다.
• 사람 개입 화면: 사람이 처리해야 할 항목을 웹 패널에 모아 보여준다.
• 동작 원칙: 사람의 주의를 최소로 쓰면서 가치를 최대로 전달한다는 원칙 아래, 요청이 있거나 팀이 작성한 규칙이 허용할 때만 동작한다.
• 라이선스: MIT.

권한 모델은 별도 문서(docs/002-authorization.md)에 있는 것으로 안내되며, 이 글 작성 시 해당 문서까지는 확인하지 못했다.

처리 흐름

flowchart LR
    A["팀 채팅 또는 GitHub 이슈"] --> B{"요청자가 허용 목록에 있는가?"}
    B -->|"아니오"| X["무응답 또는 거절"]
    B -->|"예"| C["작업 항목 생성"]
    C --> D["독립 에이전트 세션 및 작업 디렉터리"]
    D --> E["Pull Request 생성"]
    E --> F["원래 대화에 결과 회신"]
    D --> G["웹 패널: 사람 처리 필요 항목"]
    G --> H["사람의 승인 또는 판단"]

명시된 한계

README가 직접 밝힌 한계는 다음과 같다.

• 연구 참고용이며 DeepSeek의 공식 제품이 아니다.
• 버그가 있을 수 있고 코드 스타일과 엔지니어링 관행이 일관되지 않을 수 있다.
• 공개본은 내부 버전이나 관련 글의 설계와 동일하지 않고, 글에서 논한 일부 설계는 미구현의 향후 방향이다.
• 운영자가 자신의 환경에 맞게 검토하고 수정한 뒤 사용해야 한다.

따라서 이 프로토타입의 존재를 근거로 프로덕션 준비 수준을 판단해서는 안 된다. 평가 대상은 "구조 아이디어"이지 "완성된 제품"이 아니다.

프로덕션 기준 검토 항목

채팅 기반 작업 수집의 데이터 경계

팀 채팅은 업무 대화, 고객 정보, 자격 증명이 섞여 있는 비정형 채널이다. 에이전트가 채팅을 "듣는다"는 것은 그 내용이 모델 호출과 로그에 흘러 들어갈 수 있다는 뜻이다.

• 수집 범위를 특정 채널과 멘션된 메시지로 제한하고 전체 대화 수집은 금지한다.
• 개인정보와 비밀 값을 모델 입력 전에 마스킹한다.
• 모델 제공자로 나가는 데이터와 저장되는 로그의 보존 기간을 정한다.

저장소 단위 권한 범위

저장소 하나로 범위를 좁힌 설계는 영향 반경을 줄이는 장점이 있다. 다만 다음을 별도로 확인해야 한다.

• 에이전트 계정에 부여된 토큰의 권한이 읽기, 브랜치 푸시, PR 생성 범위를 넘지 않는가
• 기본 브랜치 직접 푸시와 시크릿 접근이 차단되어 있는가
• 작업 디렉터리에서 실행되는 명령의 네트워크와 파일 시스템 접근이 격리되어 있는가

사람의 승인 지점

README는 구체적 승인 게이트 목록을 제시하지 않는다. 도입 조직이 직접 정의해야 한다.

1. 에이전트 PR은 사람 리뷰어의 승인 없이 병합할 수 없게 브랜치 보호 규칙을 건다.
2. 의존성 추가, 설정 변경, 배포 관련 파일 수정은 상위 위험으로 분류해 추가 승인을 요구한다.
3. "허용된 사람"의 목록 변경과 규칙 추가를 별도 승인 대상으로 둔다.
4. 에이전트의 모든 작업 항목과 결과를 감사 로그로 남긴다.

마무리

dsh-superagent는 채팅 요청을 작업 항목과 PR로 연결하는 구조를 보여주는 참고 구현이다. 그러나 연구용 프로토타입이고 일부 설계가 미구현이므로, 도입을 검토한다면 채팅 데이터 경계, 토큰 권한, 승인 게이트를 먼저 자체 정의해야 한다. 코드 품질을 신뢰하기보다 구조를 참조해 통제 요건을 도출하는 접근이 적절하다.

Keywords

coding agent, team chat, ticket-based workflow, data boundary, repository permission, human approval, 코딩 에이전트, 팀 채팅, 티켓 단위 작업, 데이터 경계, 승인 지점

Sources

• dsh-superagent-prototype README - deepseek-ai (GitHub)
• DeepSeek Bot: Community Multi-Agent Framework for Autonomous AI Teams - BestHub

AI 학습 크롤링 옵트아웃 공동 표준: robots.txt 규칙의 범위와 증빙 설계

• 공동 신호의 구조
• 벤더별 적용 시점
• 규칙이 다루는 범위와 다루지 못하는 범위
• 사이트 운영 절차
• 증빙과 준수 확인
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

2026년 10월 30일 Google, Microsoft, OpenAI, Anthropic이 robots.txt에 기반한 단일 AI 학습 옵트아웃 신호를 함께 지원하겠다고 밝혔다. 다만 근거가 되는 문서는 IETF의 개인 제출 드래프트이고 벤더별 적용 시점도 다르다. 이 글은 사이트 운영자가 규칙을 설정할 때 이 신호가 막아 주는 범위와 막지 못하는 범위를 구분하고, 설정과 준수 여부를 증빙으로 남기는 절차를 정리한다. 아래 내용은 2차 보도와 매체 해설에 기반하며, 각 벤더의 1차 발표문은 직접 확인하지 못했으므로 적용 전 원문 확인이 필요하다.

공동 신호의 구조

보도에 따르면 신호의 이름은 __usage_ai-training이며, 기존 robots.txt 문법을 그대로 쓰는 정책 토큰이다. 근거 문서는 Anthropic의 Kevin Kelley가 쓴 draft-kelley-aipref-training-preference-signal로 알려져 있다. 개인 제출 드래프트이므로 IETF가 승인한 표준이 아니며, 버전 00은 2027년 5월 3일에 만료된다고 한다.

사이트 전체에서 학습 사용을 거부하는 최소 규칙은 다음과 같이 보도되었다.

User-Agent: __usage_ai-training
Disallow: /

토큰을 별도 그룹으로 두기 때문에 기존 User-agent: * 규칙과는 독립적으로 동작한다. 한 가지 중요한 점은 * 그룹에 적은 규칙이 이 토큰에 대한 의사 표시로 간주되지 않는다는 것이다. 토큰 그룹이 없으면 운영자가 선호를 밝히지 않은 것으로 취급된다.

벤더별 적용 시점

적용 시점이 다르므로 지금 토큰만 추가하면 일부 벤더에게는 아직 효과가 없다. 이 공백 기간에는 기존 벤더별 토큰을 병행해야 한다.

규칙이 다루는 범위와 다루지 못하는 범위

flowchart LR
    A["운영자 robots.txt"] --> B["__usage_ai-training 그룹"]
    A --> C["벤더별 크롤러 그룹"]
    B --> D["학습 사용 거부 의사"]
    C --> E["크롤링 허용 여부"]
    D --> F["벤더가 준수하면 학습 제외"]
    E --> G["접근 차단은 별도 제어"]
    F --> H["이미 수집된 데이터와 학습된 모델은 영향 없음"]

보도된 한계를 운영 관점으로 옮기면 다음과 같다.

• 크롤링 지시가 아니다. 신호는 콘텐츠를 어떻게 쓸 수 있는지에 대한 선호 표시이며, 접근을 막는 기술적 차단이 아니다. 접근 자체를 막으려면 기존 크롤러 토큰이나 서버 측 제어를 쓴다.
• 학습만 다룬다. AI 답변 생성, 검색, 크롤링은 이 신호의 대상이 아니라고 보도되었다.
• 소급 효과가 없다. 이미 수집되어 학습된 데이터나 모델에서 콘텐츠가 제거되지는 않는다.
• 사적 계약이 우선할 수 있다. 사이트와 AI 기업 사이의 별도 합의가 신호를 덮어쓸 수 있다.
• 검색 노출과의 관계는 벤더 문서로 확인한다. Google은 Google-Extended가 Google 검색에 영향을 주지 않는다고 밝혔고, Microsoft도 Bing 검색 노출은 바뀌지 않는다고 했다. 다만 토큰 자체가 Googlebot에 미치는 영향은 해당 보도에서 다뤄지지 않았으므로 Google 문서에서 확인해야 한다.
• 그라운딩은 별개다. Microsoft의 AI Grounding 차단은 AI 생성 경험에서의 노출을 줄일 수 있으므로 학습 거부와 분리해 결정한다.

사이트 운영 절차

1. 자산 분류: 학습을 거부할 경로를 정한다. 사이트 전체 거부, 보도 자료 같은 일부 경로만 허용하는 방식 모두 가능하다.
2. 규칙 작성: 토큰 그룹과 기존 벤더별 그룹(GPTBot, ClaudeBot, Google-Extended 등)을 병행한다. 병행하는 이유는 적용 시점이 다르기 때문이다.
3. 배포 전 검증: robots.txt가 구문 오류 없이 파싱되는지 확인하고, 변경 이력을 버전 관리에 둔다.
4. 계약 확인: 라이선스나 데이터 제공 계약이 있는 벤더는 계약 조항이 신호보다 우선하는지 확인한다.
5. 재검토 주기: 벤더 적용 시점(2027년 초)과 드래프트 만료일을 달력에 넣고, 드래프트 개정 시 규칙을 재검토한다.

증빙과 준수 확인

신호가 자발적이라는 한계 때문에, 운영자가 확보할 수 있는 증빙은 "내가 어떤 의사를 언제부터 공개했는가"에 한정된다.

• 설정 증빙: 배포 시점의 robots.txt 사본을 날짜와 함께 보관한다. 배포 이력(커밋 해시, 배포 시각)과 수집 시점의 HTTP 응답 스냅샷이 후속 분쟁에서 의사 표시 시점을 보여 준다.
• 접근 로그 점검: 서버 로그에서 GPTBot, OAI-SearchBot, ClaudeBot, Google-Extended 등 알려진 크롤러 토큰의 요청을 확인한다. 다만 보도된 자료는 이 로그가 새 신호의 준수 여부를 반영하는지, 또는 그것을 로그로 검증할 수 있는지는 설명하지 않는다. 즉 준수 여부를 로그만으로 확정할 수 없다는 점을 전제로 둔다.
• 벤더 문서 추적: 각 벤더의 크롤러 문서에서 신호 지원 시점을 확인하고 지원 개시 전후를 구분해 기록한다.
• 미확인 사항 표기: 준수가 확인되지 않은 벤더는 "미확인"으로 기록한다. 준수 주장은 벤더 발표에 기반한 것이지 운영자가 검증한 결과가 아니다.

마무리

공동 옵트아웃 신호는 벤더마다 따로 설정하던 부담을 줄일 수 있는 방향이지만, 현재는 개인 드래프트 단계이고 벤더별 적용 시점이 2027년까지 흩어져 있다. 운영자는 토큰 그룹과 기존 벤더별 규칙을 병행하고, 신호가 크롤링 차단이나 소급 삭제가 아니라는 점을 전제로 설정하는 것이 안전하다. 증빙은 설정 이력과 벤더 지원 시점 기록을 중심으로 남기고, 준수 여부는 확인되기 전까지 미확인으로 표기하는 방식을 권한다.

Keywords

AI training opt-out, robots.txt, IETF draft, crawler control, Google-Extended, GPTBot, policy token, 학습 옵트아웃, 크롤러 제어, 사이트 운영, 준수 증빙

Sources

• Google, Microsoft, OpenAI and Anthropic back one AI training opt-out - The Next Web
• One Opt-Out For AI Training: How To Set It And What To Expect - Best CAD papers
• Google, Microsoft, OpenAI and Anthropic back one AI training opt-out - PPC Land
• OpenAI, Google, Microsoft and Anthropic to support a unified AI training opt-out token in robots.txt - DEV Community
• Google, OpenAI, Anthropic and Microsoft back one AI opt-out - Gagadget
• RFC 9969: IAB AI-CONTROL Workshop Report - IETF Datatracker

에이전트 PR 검증 보고 규약: 검증한 것과 못 한 것을 분리하는 설계

• 왜 "통과"만으로는 부족한가
• 공개된 유사 사례
• PR 템플릿 설계
• 병합 전 확인 절차
• 도입 시 주의할 점
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

에이전트가 만든 PR은 테스트가 초록색이라는 이유만으로 신뢰하기 어렵다. 테스트가 통과했다는 사실은 "테스트가 다룬 범위에서는 문제가 없었다"는 뜻일 뿐, 에이전트가 무엇을 확인하지 못했는지는 알려주지 않는다. 최근 개발자 커뮤니티에서는 PR마다 "검증한 것"과 "못 한 것"을 분리해 적도록 하는 방식이 주목받고 있으며, 이 글은 그 아이디어를 PR 템플릿과 병합 전 확인 절차로 구체화한다.

왜 "통과"만으로는 부족한가

리뷰어가 CI 결과만으로 신뢰를 판단하면 세 가지 사각지대가 생긴다.

• 테스트 범위 밖의 변경: 에이전트가 수정한 코드 경로를 기존 테스트가 실행하지 않을 수 있다.
• 에이전트가 직접 실행하지 못한 검증: 외부 서비스 연동, 권한이 필요한 환경, 수동 UI 확인은 샌드박스에서 돌릴 수 없는 경우가 많다.
• 추측성 변경: 요청 범위를 넘어 "안전해 보여서" 함께 고친 부분은 요청자도 리뷰어도 기대하지 않은 변경이다.

핵심은 미검증 범위가 보고서에 이름으로 남아야 한다는 점이다. 이름이 붙은 사각지대는 리뷰어가 집중해서 볼 위치가 되고, 이름이 없는 사각지대는 신뢰 속에 묻힌다.

공개된 유사 사례

이 규약은 하나의 표준이 있는 것이 아니라 여러 곳에서 비슷한 형태로 나타난다. 아래는 웹 검색으로 확인한 사례이며, GeekNews 원문 자체는 검색에서 확인하지 못했으므로 해당 글의 세부 형식은 원문 확인이 필요하다.

세 사례 모두 "한 것"과 "못 한 것"을 한 문서 안에서 나란히 두는 구조라는 점이 공통이다.

PR 템플릿 설계

아래 템플릿은 위 사례들의 필드를 합쳐 재구성한 예시이며, 특정 도구의 공식 양식이 아니다.

## 목표
요청된 결과를 한 문장으로

## 변경 범위
- 변경한 파일/디렉터리
- 의도적으로 건드리지 않은 범위 (non-goals)

## 검증한 것
- 실행한 명령과 결과 (명령 원문 + 종료 코드)
- 직접 확인한 동작

## 검증하지 못한 것
- 실행하지 못한 검증과 그 이유 (권한, 환경, 시간)
- 테스트가 다루지 않는 변경 경로
- 가정한 사항

## 요청 범위 밖의 변경
- 없으면 "없음"이라고 명시

## 리뷰어 요청
- 사람이 집중해서 봐야 할 지점

설계 시 지킬 원칙은 다음과 같다.

1. "검증한 것"에는 실행 증거를 붙인다. 명령과 결과가 없는 항목은 "확인했다"는 주장에 불과하다.
2. "검증하지 못한 것"을 비워 두지 않는다. 비어 있으면 "없음"이라고 쓰되, 그 판단의 근거를 한 줄 덧붙인다. 빈칸은 누락과 구별되지 않는다.
3. 이유를 함께 적는다. "시간 부족"과 "권한 없음"은 리뷰어의 후속 조치가 다르다.

병합 전 확인 절차

템플릿은 기록 수단일 뿐이고, 병합 전 절차가 이를 실제 판단에 연결한다.

flowchart TD
    A["에이전트 PR 생성"] --> B["PR 본문 필드 검사"]
    B --> C{"'검증하지 못한 것' 필드가 작성되었는가?"}
    C -->|"아니오"| D["작성 요청 후 반려"]
    C -->|"예"| E["변경 파일과 변경 범위 대조"]
    E --> F{"범위 밖 변경이 있는가?"}
    F -->|"예"| G["분리하거나 사유 승인"]
    F -->|"아니오"| H["미검증 항목별 담당자 지정"]
    G --> H
    H --> I{"미검증 항목이 위험도 높음인가?"}
    I -->|"예"| J["사람이 수동 검증 후 기록"]
    I -->|"아니오"| K["후속 이슈로 등록"]
    J --> L["병합"]
    K --> L

단계별 기준은 다음과 같다.

• 필드 검사: 필수 섹션이 없으면 본문 검사 단계에서 자동으로 반려할 수 있다. 이는 CI에서 PR 본문을 정규식으로 확인하는 정도로 구현이 가능하다.
• 범위 대조: 변경 파일 목록이 "변경 범위"에 있는 것과 일치하는지 본다. 의존성, CI 설정, 마이그레이션, 권한 변경은 명시적 승인 대상으로 둔다.
• 미검증 항목 처리: 각 항목을 "병합 전에 사람이 검증", "후속 이슈로 등록", "수용" 중 하나로 분류한다. 분류하지 않은 항목이 남은 채 병합하지 않는다.
• AI 리뷰어의 위치: 자동 리뷰어가 지적한 항목은 사람이 확인한 뒤 요청 사항으로 전환한다.

도입 시 주의할 점

• 자기 보고의 한계: "검증하지 못한 것"도 에이전트가 쓴다. 에이전트가 자신이 놓친 것을 모를 수 있으므로, 이 필드는 사각지대를 전부 드러내는 장치가 아니라 알려진 사각지대를 명시하는 장치다.
• 형식화의 위험: 모든 PR에 같은 문장이 반복되면 리뷰어가 읽지 않는다. 변경 규모가 작은 PR에는 축약형을 허용한다.
• 증거와 주장의 구분: 검증 항목의 주장을 테스트 증거와 자동으로 대조하는 도구도 등장하고 있다. 다만 도구 적용 전에 팀 템플릿이 먼저 안정되어야 한다.

마무리

에이전트 PR의 신뢰는 통과한 테스트의 수가 아니라 확인하지 못한 범위가 얼마나 명확히 적혀 있는가에서 나온다. "검증한 것"에는 실행 증거를, "검증하지 못한 것"에는 이유와 처리 방침을 요구하는 템플릿과 병합 게이트를 함께 도입하면 리뷰어의 주의를 정말 위험한 지점으로 모을 수 있다. 작은 PR부터 적용하고, 반려 사유를 기록하면서 필드 구성을 다듬는 방식을 권한다.

Keywords

agent pull request, verification report, PR template, unverified scope, merge gate, review evidence, 에이전트 PR, 검증 보고, 미검증 범위, 병합 전 확인

Sources

• Reviewing AI-Generated Pull Requests - AI Builder Club
• The AI Pull Request Manifest: The One Page That Makes Agent Code Reviewable - Alex Cloudstar
• How to attach agent session context to GitHub PRs - Warp Docs
• proofcheck-ai - PyPI
• Agentic coding - Meltano Docs

Cisco ASA/FTD SSL VPN DoS CVE-2026-76418: 서비스 거부 취약점이 KEV에 오른 이유와 VPN 가용성 방어 설계

• 사건 개요
  • 타임라인
• 취약 조건: 보조 인증 구성
• DoS가 KEV에 오르는 이유
• 가용성 방어 우선순위
  • 1단계: 노출과 구성 판정
  • 2단계: 패치 전 임시 완화
  • 3단계: 패치
  • 4단계: 점검과 지속 방어
• 정책으로 정착시키는 방법
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

Cisco Secure Firewall ASA와 FTD의 원격 접근 SSL VPN에서 인증 없이 장비를 재시작시킬 수 있는 서비스 거부 취약점 CVE-2026-76418이 2026년 10월 29일 CISA KEV에 등재되었다. 원격 코드 실행이 아닌 가용성 취약점이 긴급 대응 대상이 된 이유는 실제 악용이 확인되었고, 대상이 조직의 원격 접근 관문이기 때문이다. 이 글에서는 취약 조건, KEV 등재 논리, 패치와 노출 제한의 우선순위를 정보관리기술사의 관점에서 설계한다.

사건 개요

• 대상: Cisco Secure Firewall ASA 및 FTD의 Remote Access SSL VPN 서비스(Cisco 결함 ID CSCwx26625).
• 취약점 유형: 논리 오류로 인한 NULL 포인터 역참조(CWE-690). 장비가 재시작(reload)된다.
• 심각도: CVSS 3.1 기준 8.6. 네트워크 경유, 낮은 복잡도, 인증과 사용자 상호작용 불필요, 영향은 가용성에 한정된다.
• 악용: Cisco PSIRT가 2026년 10월에 실제 악용을 인지했다고 밝혔다. 공개된 개념 증명 코드는 확인되지 않았다.
• 조건: 로그인에 성공하지 않아도 트리거될 수 있다.

타임라인

권고 공개 다음 날 KEV에 오르고 기한이 며칠 안에 끝나는 것은, 방어자에게 주어진 시간이 매우 짧다는 신호다.

취약 조건: 보조 인증 구성

모든 ASA/FTD가 영향을 받는 것은 아니다. 다음 두 조건이 함께 충족될 때 노출된다.

• 하나 이상의 인터페이스에서 webvpn이 활성화되어 있다.
• 터널 그룹 또는 DefaultWEBVPNGroup에 secondary-authentication-server-group이 설정되어 있다.

즉 이중 인증(보조 인증)을 위해 구성한 설정이 오히려 취약 경로를 연다. 이 때문에 영향 범위는 버전 목록뿐 아니라 구성으로도 판정해야 한다.

DoS가 KEV에 오르는 이유

KEV 등재 기준은 코드 실행 여부가 아니라 실제 악용 증거와 명확한 조치 방안이다. VPN 장비의 서비스 거부가 긴급한 이유는 다음과 같다.

1. 원격 접근 관문의 중단: 재택·원격 근무자와 협력사 접속이 한꺼번에 끊긴다.
2. 반복 가능성: 비인증 요청으로 재시작을 유발하므로 공격자가 지속적으로 장애를 만들 수 있다.
3. 장애 시 우회 압력: 가용성이 무너지면 임시 우회 경로가 열려 보안 통제가 약해진다.
4. 정찰·교란 도구화: 다른 공격 중에 방어 장비를 흔드는 용도로 쓰일 수 있다.

따라서 CIA 가운데 가용성(A)만 영향받더라도, 자산이 관문 역할이라면 기밀성 취약점과 같은 우선순위가 정당하다.

가용성 방어 우선순위

flowchart TD
    A["ASA/FTD 인벤토리"] --> B{"webvpn 활성 및 보조 인증 구성?"}
    B -->|"아니오"| Z["정기 패치 주기"]
    B -->|"예"| C["임시 완화 적용"]
    C --> D["고정 수정 버전으로 패치"]
    D --> E["HA 페어 순차 업그레이드"]
    E --> F["재시작 이력 및 접속 로그 점검"]
    F --> G["노출 제한 및 모니터링 정착"]

1단계: 노출과 구성 판정

• show running-config로 webvpn 활성 인터페이스와 secondary-authentication-server-group 설정을 확인한다.
• 인터넷에서 SSL VPN 포털이 도달 가능한 장비를 외부 스캔으로 대조한다.

2단계: 패치 전 임시 완화

완전한 우회책은 없다. Cisco가 안내한 완화는 다음과 같다.

• 사용자 정의 터널 그룹과 DefaultWEBVPNGroup에서 보조 인증을 비활성화한다.
• DefaultWEBVPNGroup이 보조 인증을 쓰지 않으면 no tunnel-group-list enable을 적용한다.
• 보조 인증을 끄면 인증 강도가 낮아지므로, 대체 통제(인증서 기반 인증, 접속 출처 제한, 모니터링 강화)를 같이 정한다.

3단계: 패치

수정 버전은 ASA 9.16.4.104, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48, 9.24.1.27, 9.24.10.1이고, FTD 7.0.11, 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3, 10.1.1이다. 이 목록은 보안 매체 보도 기준이므로 적용 전에 Cisco 권고로 대조한다. HA 구성에서는 대기 장비부터 순차 업그레이드해 서비스 중단을 줄인다.

4단계: 점검과 지속 방어

• 예상 밖 재시작 이력(show version의 업타임, 크래시 정보)과 SSL VPN 요청 급증을 확인한다.
• SSL VPN 포털의 접속 출처를 국가·허용 목록으로 제한하고, 요청률 제한과 위협 탐지를 적용한다.
• VPN 장비를 이중화하고, 장애 시 안전한 절체 절차(우회 금지)를 사전에 정의한다.

정책으로 정착시키는 방법

여기에 구성 기반 영향 판정, 원격 접근 장비의 이중화 점검, 연방 기한 같은 외부 기한의 내부 SLA 반영을 포함한다.

마무리

CVE-2026-76418은 코드 실행이 아니라 장비를 재시작시키는 취약점이지만, 인증 없이 반복 가능하고 이미 악용되며 대상이 원격 접근 관문이라는 점에서 긴급 대응 대상이 된다. 대응은 취약 구성 판정, 보조 인증 비활성화 같은 임시 완화, 수정 버전 패치, 재시작 이력 점검의 순서로 설계한다. 가용성도 보안 속성이라는 관점으로 우선순위를 정하고, 원격 접근 장비는 이중화와 노출 제한으로 단일 장애점을 줄여야 한다.

Keywords

Cisco ASA, Cisco FTD, CVE-2026-76418, SSL VPN, Denial of Service, CISA KEV, 서비스 거부, 가용성, 보조 인증, 패치 우선순위

Sources

• Cisco warns of ASA and FTD VPN flaw exploited to crash devices (BleepingComputer)
• Cisco Secure Firewall vulnerability exploited in SSL VPN (SecurityOnline)
• CVE-2026-76418 (OpenCVE)
• Vulnerability Notification - Cisco ASA and FTD Remote Access VPN DoS Actively Exploited (WaterISAC)
• U.S. CISA adds GitLab and Cisco flaws to its KEV catalog (Security Affairs)

GitLab RCE CVE-2026-97229: Alpine Linux 사고로 확인된 KEV 등재 취약점과 패치 우선순위 설계

• 사건 개요
  • 타임라인
• Alpine Linux 사고가 보여준 것
• 패치 우선순위 설계
• 외부 노출 면과 CI 자격 증명 점검
• 정책으로 정착시키는 방법
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

GitLab의 CI/CD 정규식 컴파일러에서 발견된 정수 오버플로 취약점 CVE-2026-97229(CVSS 10.0)가 2026년 10월 29일 CISA KEV에 등재되었다. 인증 없이 서버에서 임의 코드를 실행할 수 있고, Alpine Linux 프로젝트가 자사 GitLab 서버에서 공격 시도를 겪은 사실이 공개되면서 실제 악용이 확인되었다. 이 글에서는 취약점의 구조, Alpine 사례가 주는 교훈, 셀프호스팅 환경의 패치 우선순위와 CI 자격 증명 점검 절차를 정보관리기술사의 관점에서 설계한다.

참고: 주제 입력에는 "10-20~21 공격 시도는 실패했다"고 적혀 있었다. 작성 시점(2026-10-31)에 확인한 보도에서 Alpine은 공격자가 워커 프로세스를 여덟 번 중단시켰고 그중 네 번은 익스플로잇이 중간 단계까지 진행되었다고 밝혔으며, 로그 일부가 유실되어 코드 실행을 배제하지 못한다고 했다. 따라서 본문은 "실패"가 아니라 "성공 여부를 확인할 수 없는 시도"로 다룬다. 또한 Onigmo 및 Ruby 버전에 관한 설명은 단일 매체 보도에 근거하므로 GitLab 공식 릴리스 노트로 재확인해야 한다.

사건 개요

• 대상: GitLab Community Edition 및 Enterprise Edition(셀프호스팅). GitLab.com은 이미 패치되었고 GitLab Dedicated는 조치가 필요 없다.
• 취약점 유형: 정수 오버플로(CWE-190). CI/CD 설정의 정규식을 컴파일하는 과정에서 검증이 부족하다.
• 인증: 불필요. 조건이 맞으면 비인증 사용자도 서버에서 코드를 실행할 수 있다고 GitLab은 설명한다.
• 영향 범위: 19.2 계열 19.2.8 미만, 19.3 계열 19.3.5 미만, 19.4 계열 19.4.2 미만. 19.1 이하와 19.5는 영향 대상이 아니다.
• 발견 경로: HackerOne 버그 바운티를 통해 제보되었다.

타임라인

GitLab은 초기 권고에서 19.3.4를 수정 버전으로 안내했으나 이후 보도는 19.3.5를 기준으로 한다. 19.3.4에 머문 서버는 같은 달 공개된 또 다른 CVSS 10.0 정규식 컴파일러 취약점 CVE-2026-110264에도 노출되므로, 최신 패치 버전(19.4.3, 19.3.6, 19.2.9 이상)으로 올려야 한다.

Alpine Linux 사고가 보여준 것

Alpine은 19.3.5가 아닌 19.3.4로 잘못 올린 서버에서 신규 가입 계정을 쓴 공격을 받았다. 공격자는 워커 프로세스를 반복해서 중단시켰고, 성공한 코드 실행은 충돌이나 웹 로그에 흔적을 남기지 않을 수 있다. Alpine은 서버를 폐쇄하고 재구축했으며 사용자 비밀번호 초기화와 GitLab 비밀 키 교체를 수행했다. 패키지와 10월 21일 안정 릴리스에 변조는 없었고, 패키지 서명 키는 애초에 GitLab 서버에 저장하지 않았다.

이 사례에서 얻는 교훈은 세 가지다.

1. 버전 한 단계 차이가 곧 노출이다. 수정 버전 번호를 정확히 확인하지 않으면 패치했다고 믿은 서버가 취약한 상태로 남는다.
2. 증거 부재는 안전의 증거가 아니다. 로그가 유실되었거나 흔적이 없는 공격은 침해 가정 대응을 요구한다.
3. 서명 키 분리가 피해를 한정했다. 릴리스 서명 키를 CI 서버 밖에 둔 설계가 공급망 피해를 막았다.

패치 우선순위 설계

셀프호스팅 GitLab은 소스 저장소, CI 러너, 배포 자격 증명이 모이는 지점이어서 침해 시 파급이 크다. 우선순위는 다음 순서로 정한다.

1. KEV 등재와 인터넷 노출: 악용이 확인되었고 가입이 열린 인스턴스라면 최우선이다.
2. 인증 요건: 비인증 경로가 있으면 내부망 한정 인스턴스보다 앞선다.
3. 자산 영향: 배포 키, 클라우드 자격 증명, 서명 키를 CI 변수에 두었는지 확인한다.
4. CVSS·EPSS: 같은 조건 안에서 순서를 가르는 보조 지표다.

flowchart TD
    A["GitLab 인스턴스 인벤토리"] --> B{"영향 버전인가?"}
    B -->|"아니오"| Z["정기 패치 주기"]
    B -->|"예"| C{"인터넷 노출 또는 가입 개방?"}
    C -->|"예"| D["노출 제한 후 즉시 패치"]
    C -->|"아니오"| E["7일 이내 패치"]
    D --> F["침해 흔적 점검"]
    E --> F
    F --> G{"코드 실행 의심?"}
    G -->|"예"| H["재구축 및 비밀 교체"]
    G -->|"아니오"| I["감시 강화 및 종료"]

패치 시 확인할 점은 다음과 같다.

• 목표 버전은 최신 패치 릴리스(19.4.3, 19.3.6, 19.2.9 이상)로 잡는다.
• 단일 매체 보도에 따르면 수정이 패키지에 포함된 Ruby에 있어서, 별도 Ruby를 쓰는 자체 컴파일 설치나 이미지는 Ruby도 갱신해야 한다. 공식 노트로 확인한다.
• 즉시 패치가 불가능하면 익명 접근 제한, 신규 가입 차단, 공개 프로젝트 쓰기 권한 제한, CI 린트 경로 차단 같은 임시 조치를 쓰되 근본 해결이 아님을 명시한다.

외부 노출 면과 CI 자격 증명 점검

• 노출 면: 인터넷에서 접근 가능한 GitLab 인스턴스, 가입 허용 설정, 공개 프로젝트 정책을 점검한다. Shadowserver는 노출된 Community Edition 인스턴스를 약 2,800대로 추적한다.
• 흔적 점검: 워커 프로세스의 반복 중단, 이상한 신규 계정, CI 린트 요청 급증을 확인하고 GitLab이 배포한 탐지 규칙을 적용한다.
• 자격 증명 범위: CI/CD 변수, 러너 등록 토큰, 배포 키, 클라우드 키, 패키지 레지스트리 토큰을 목록화한다.
• 교체 기준: 코드 실행 정황이 있거나 로그 신뢰성이 낮으면 해당 서버가 읽을 수 있던 비밀을 모두 교체한다. GitLab의 secrets.yml 같은 서버 비밀 키도 포함한다.
• 구조 개선: 서명 키와 프로덕션 배포 자격 증명은 CI 서버 밖에 두고, 단기 토큰(OIDC)을 사용해 유출 시 유효 기간을 줄인다.

정책으로 정착시키는 방법

여기에 패치 후 실제 실행 버전 검증, 릴리스 노트 구독, KEV 자동 대조를 절차로 포함한다.

마무리

CVE-2026-97229는 CVSS 10.0이라는 점수보다 KEV 등재와 비인증 접근, CI 서버에 모인 자격 증명이 긴급도를 결정한다. Alpine의 사례는 버전 번호 확인 실수와 흔적 없는 공격이 얼마나 쉽게 겹치는지 보여준다. 패치 전에 노출을 줄이고, 패치 후 실행 버전을 검증하며, 의심되면 재구축과 비밀 교체까지 가야 한다. 서명 키 분리 같은 구조적 통제가 사고의 피해 범위를 한정한다.

Keywords

GitLab, CVE-2026-97229, CISA KEV, Integer Overflow, CI/CD Security, Patch Priority, 정수 오버플로, 패치 우선순위, 자격 증명 교체, 공급망 보안

Sources

• CISA says max severity GitLab flaw now exploited in the wild (BleepingComputer)
• GitLab warns of max severity code execution vulnerability (BleepingComputer)
• CVE-2026-97229: Critical Unauthenticated Remote Code Execution in GitLab (Rapid7)
• CISA Adds GitLab's CVSS 10.0 Flaw to Its Exploited-Vulnerabilities List (PBX Science)
• U.S. CISA adds GitLab and Cisco flaws to its KEV catalog (Security Affairs)

Claude Code 에이전트 요약 호출의 토큰 원가: 보이지 않는 백그라운드 호출을 계측하고 비교하는 기준

• 보고된 내용과 측정 방법
• 요약 호출이 발생하는 방식
• 끄는 방법과 한계
• 검증되지 않은 부분
• 원가 계측 설계
• 기능 가치와 비용 비교 기준
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

Claude Code의 에이전트 패널이 백그라운드 에이전트의 현재 상태를 세 단어 안팎으로 요약하기 위해 호출을 반복하고, 이것이 전체 토큰의 약 15~20%를 쓴다는 분석이 공개됐다. 근거는 한 회사의 개인 gist이고 Anthropic 공식 문서에서 확인된 수치가 아니다. 이 글은 보고된 내용과 측정 방법, 한계를 정리하고, 사용자가 보지 않는 백그라운드 LLM 호출을 원가 계측에 어떻게 잡고 기능 가치와 비교할지를 설계 기준으로 다룬다.

보고된 내용과 측정 방법

gist 작성자(Flamerix AI, 소속 회사 DRIM)는 다음과 같이 측정했다고 밝힌다.

• OpenTelemetry의 claude_code.api_request 이벤트를 query_source별로 묶었다.
• 적용 전 agent_summary는 지출 추정의 16.4%, API 요청 수의 19.7%였고, 적용 후에는 0%가 됐다.
• 지출은 Claude Code가 요청마다 계산한 추정치이며 청구서 금액이 아니다.
• 라이브 테스트는 약 2.5분짜리 실행에서 디버그 로그의 [AgentSummary] Forking 줄을 세는 방식이었다. 훅이 없을 때 약 5회, 훅이 켜지면 0회였다.

표본은 작다. 실행 횟수가 적고 하위 에이전트도 소수이며 주로 Linux에서 시험했다. 다른 사용자의 댓글에는 일주일치 대화 기록(백그라운드 에이전트 190개)에 타이머를 재현해 보니 약 8% 수준이었다는 추정도 있어, 비율은 워크로드에 따라 크게 달라진다.

요약 호출이 발생하는 방식

gist 작성자의 설명에 따르면 다음과 같다.

• 대략 30초마다 백그라운드 에이전트별로 전체 대화 기록을 모델에 보내 최근 동작을 3~5단어로 요약하게 한다.
• 간격은 서버 플래그로 정해지며 30~240초로 제한된다.
• 상호작용형 백그라운드 에이전트는 기본으로 요약되고, 포크된 하위 에이전트와 스킬은 항상 요약된다.
• 환경 변수나 SDK 옵션은 요약을 켜는 방향으로만 작동한다.
• 호출의 약 98%는 프롬프트 캐시에 적중하지만 나머지 약 2%가 비용의 3분의 1 이상을 차지한다고 한다.

Agent View 문서는 행 요약을 Haiku급 모델이 몇 분 간격으로 갱신한다고 설명하는 것으로 전해지지만, 백그라운드 토큰 사용에 대한 문서화는 빠져 있다는 지적이 있다.

끄는 방법과 한계

• preload는 전역 setTimeout을 감싸 요약 타이머 콜백을 거의 무한 지연시키는 방식이다. 이름이 바뀌거나 bind()가 쓰이면 우회될 수 있어 업데이트마다 재검증이 필요하다고 작성자도 적는다.
• Windows에서 머신 전체에 변수를 걸어 두고 파일이 깨지면 claude.exe가 시작하지 못할 수 있다는 경고가 있다.
• 비공식 우회이므로 업무 환경에 넣기 전에 공식 변경 기록과 설정 옵션을 먼저 확인해야 한다.

검증되지 않은 부분

• 15~20%는 한 사용자 환경의 측정이며, 일반 사용자 평균으로 볼 근거가 없다.
• 패널 상태 외에 요약 텍스트가 모델 컨텍스트로 들어가는지에 대해서는 댓글에서 이견이 있다.
• 구독제에서는 비용이 현금이 아니라 사용량 한도의 여유로 나타난다.
• Anthropic의 공식 입장은 확인하지 못했다.

원가 계측 설계

flowchart TD
    A["API 요청 이벤트 수집"] --> B["query_source별 집계"]
    B --> C{"사용자 입력에서 시작된 호출인가?"}
    C -->|"예"| D["작업 원가로 분류"]
    C -->|"아니오"| E["백그라운드 원가로 분류"]
    E --> F["요청 수·토큰·캐시 적중률 기록"]
    F --> G{"전체 대비 비중이 기준 초과?"}
    G -->|"아니오"| H["주기 점검만 유지"]
    G -->|"예"| I["기능 가치와 비교 후 조치"]

1. 호출 출처 태깅: 요청을 사용자 입력 기원과 시스템 기원으로 나눈다. query_source 같은 필드가 있으면 그대로 쓴다.
2. 지표 이원화: 비용 비중뿐 아니라 요청 수 비중도 본다. 이번 보고에서는 요청 19.7%, 지출 16.4%로 달랐다.
3. 캐시 분해: 캐시 적중분과 미적중분을 나눠 기록한다. 미적중 2%가 비용 대부분을 만들 수 있다.
4. 기준선 비교: 기능을 끈 구간과 켠 구간을 같은 워크로드로 비교한다. 작업 종류에 따라 비율이 달라지므로 최소 몇 주의 데이터를 쓴다.
5. 청구와 대조: 도구가 보여 주는 추정 지출을 실제 청구나 한도 소진과 대조해 오차를 기록한다.

기능 가치와 비용 비교 기준

• 가치 측면: 상태 요약이 사용자의 개입 판단(중단, 재지시)에 실제로 쓰이는 빈도를 본다. 패널을 거의 열지 않는다면 가치가 낮다.
• 비용 측면: 위 계측에서 얻은 비중과 사용량 한도 도달 빈도를 쓴다.
• 판단 규칙 예시: 백그라운드 원가 비중이 사전에 정한 기준(예: 10%)을 넘고 해당 기능 사용 빈도가 낮으면 끄는 방안을 검토한다. 기준 값은 팀 상황에 맞게 정한다.
• 조치 순서: 공식 설정 확인, 공식 설정이 없으면 비공식 우회의 위험 평가, 효과 재측정 순으로 한다.

마무리

백그라운드 호출은 사용자가 화면에서 보지 못하기 때문에 계측하지 않으면 원가가 보이지 않는다. 15~20%라는 숫자는 검증이 덜 된 한 사례이지만, 호출 출처별 집계와 켜고 끈 구간 비교라는 방법은 어떤 에이전트 도구에도 적용된다. 수치를 그대로 믿기보다 자기 워크로드로 재측정해 기능 가치와 비교하는 것이 올바른 순서다.

Keywords

Claude Code, Agent Summary, Background LLM Call, Token Cost Metering, OpenTelemetry, Prompt Cache, 백그라운드 호출, 토큰 원가, 에이전트 패널, 사용량 계측

Sources

• Claude Code burns ~15-20% of your tokens on a 3-word status line (GitHub Gist, Flamerix AI)
• Claude Code burns 20% of tokens on status summaries; Bun preload disables it (LAVX News)
• Claude Code Usage Limit Hit Fast? How to Stop Background Agents Burning Tokens (DEV Community)
• What is CLAUDE_CODE_DISABLE_BACKGROUND_TASKS in Claude Code (ClaudeLog)

LLM 문체의 불쾌한 골짜기: AI 말투가 독자에게 주는 거리감과 기술 글 집필 기준

• 파울러의 글이 실제로 말하는 것
• 주제 설명과 원문의 차이
• LLM 문체의 전형적 징후
• 집필 기준
• 검토 단계의 점검 흐름
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

마틴 파울러는 2026년 9월 17일 글 "I don't like LLMs"에서 LLM과 대화할 때 느끼는 거슬리는 말투를 불쾌한 골짜기에 비유했다. 이 비유는 AI 말투가 독자 이탈을 부른다는 논의에서 자주 인용된다. 그러나 원문이 다루는 범위와 인용되는 주장 사이에는 차이가 있다. 이 글은 확인된 내용을 구분하고, 기술 블로그와 문서에서 LLM 특유의 상투 표현을 줄이는 집필 기준과 검토 단계의 점검 방법을 정리한다.

파울러의 글이 실제로 말하는 것

원문을 확인한 결과는 다음과 같다.

• 파울러는 LLM이 대화에서 쓰는 목소리가 거슬리며, 거의 사람 같지만 완전히 그렇지는 않은 불쾌한 골짜기 느낌을 준다고 쓴다.
• 불쾌감은 LLM이 사람인 척하는 데서 오고, 특히 자신이 피하고 싶은 부류의 사람처럼 말할 때 더 크다고 한다.
• LLM이 유용한 답을 주기도 하지만 같은 확신으로 지어내기도 하고, 지적받으면 "가짜 반성"만 보인다고 비판한다.

주제 설명과 원문의 차이

이 글의 요청 주제는 "LLM 특유의 문체가 실제 AI 사용 여부와 무관하게 독자 이탈을 부른다"는 분석을 파울러의 것으로 소개했다. 확인한 범위에서는 이 부분이 원문에 없다.

• 원문의 대상은 파울러 자신이 LLM과 상호작용하는 경험이다. 독자가 글을 AI로 의심할 때 이탈하는지는 다루지 않는다.
• 문장 상투어를 줄이는 집필 지침도 원문에는 없다.
• "AI 말투가 AI 사용 여부와 무관하게 독자를 떠나게 한다"는 주장은 별도의 근거가 필요하다. 검색에서 나온 것은 블로그와 에세이 수준의 2차 논평이며, 그중에는 일반 독자가 AI 글을 불쾌하게 느끼는지에 의문을 제기하는 글도 있다.

따라서 이 글은 파울러를 "AI 말투에 대한 불쾌감을 표현한 사례"로만 인용하고, 독자 이탈 효과는 검증되지 않은 가설로 둔다. 아래 집필 기준은 이 가설과 무관하게, 정보 밀도와 정확성을 높이는 일반 편집 원칙으로 정당화된다.

LLM 문체의 전형적 징후

2차 논평들이 공통으로 드는 징후는 다음과 같다. 이것도 관찰 목록이지 판별 기준이 아니다.

• 부정 병렬 구문("A가 아니라 B다"를 반복하는 문형)
• 과장된 은유와 형용사 나열
• 같은 문장 구조의 반복
• 구체적 근거 없이 매끄럽기만 한 문장

한국어 기술 글에서는 "라는 점에서 의미가 크다", "할 수 있다"를 남발하는 평탄한 어미, 문단마다 반복되는 "결론적으로" 같은 정리 문구가 비슷한 역할을 한다.

집필 기준

1. 주장에는 근거를 붙인다: 수치, 버전, 날짜, 출처 링크가 없는 문장은 삭제하거나 구체화한다.
2. 한 문장에 한 주장: 형용사 나열과 이중 부정을 줄이고 주어와 서술어를 명확히 한다.
3. 문형 다양화: 같은 구조가 3회 이상 이어지면 다시 쓴다.
4. 한정어 정리: "~할 수 있다"는 조건을 명시할 수 있을 때만 쓴다. 불확실하면 무엇이 확인되지 않았는지를 쓴다.
5. 정리 문구 제한: 문단 끝의 반복적 요약과 "결론적으로"를 줄이고, 마무리 섹션에 한 번만 둔다.
6. 일인칭 경험 보존: 직접 확인한 내용과 인용한 내용을 구분해 적는다.
7. AI 사용 표기: 초안 작성에 도구를 썼다면 소속 조직의 정책에 맞게 표기하고, 사실 검증은 사람이 책임진다.

검토 단계의 점검 흐름

flowchart TD
    A["초안 작성"] --> B["사실·수치 검증"]
    B --> C{"근거 없는 문장이 있는가?"}
    C -->|"예"| D["구체화 또는 삭제"]
    D --> B
    C -->|"아니오"| E["문체 점검"]
    E --> F{"반복 문형·상투어가 기준 초과?"}
    F -->|"예"| G["문장 재작성"]
    G --> E
    F -->|"아니오"| H["소리 내어 읽기·동료 검토"]
    H --> I["게시"]

• 사실 검증을 문체 점검보다 먼저 한다. 매끄러운 문장일수록 틀린 내용이 가려지기 쉽다.
• 문체 점검은 체크리스트로 한다. 반복 문형 수, 근거 없는 형용사, 정리 문구 횟수를 센다.
• 자동 탐지기에 의존하지 않는다. AI 글 판별 도구는 오탐이 있고, 기준은 "AI 같은가"가 아니라 "독자에게 정보가 전달되는가"여야 한다.
• 최종 검토는 작성자와 다른 사람이 맡는 것이 좋다. 작성자는 자기 문장의 상투성을 잘 못 본다.

마무리

파울러의 글은 LLM 말투에 대한 개인적 불쾌감을 기록한 것이며, 독자 이탈을 입증한 연구가 아니다. 이 점을 구분하면 AI 글쓰기 논의에서 근거와 의견을 나눠 볼 수 있다. 기술 글에서는 AI 사용 여부와 상관없이 근거 중심 서술, 문형 다양화, 사실 검증 우선의 검토 순서를 기준으로 삼는 것이 안전하다.

Keywords

LLM Prose Style, Uncanny Valley, Technical Writing, Martin Fowler, Review Gate, Writing Standard, LLM 문체, 불쾌한 골짜기, 기술 블로그 집필, 문체 검토

Sources

• I don't like LLMs (Martin Fowler)
• the llm style (Lawyers, Guns & Money)
• The Uncanny Valley of AI Writing (Compare the Cloud)
• The Uncanny Valley of AI Writing (Kenneth Reitz)
• Uncanny valley AI writing trust (Meltwater)

Claude Code VS Code 확장 변조 배포: 마켓플레이스 공급망 위협에 대한 설치 출처·무결성·대응 기준

• 사건 개요
• 페이로드 동작과 지속성
• 확인된 사실과 남은 의문
• 대응 흐름
• 설치 출처 검증과 무결성 확인 기준
• 노출 의심 시 대응 절차
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

2026년 10월 29일 Cursor 마켓플레이스에 anthropic.claude-code 확장 2.1.313이 게시됐고, 이 빌드에는 SSH 백도어를 심는 로더가 들어 있었다. Cursor는 노출 인원을 최대 약 5,000명으로 밝혔고, Anthropic은 해당 빌드를 만들거나 게시하지 않았다고 확인했다. 이 글은 공개된 분석을 바탕으로 사건의 확인된 범위를 정리하고, AI 코딩 도구 확장의 설치 출처 검증, 무결성 확인, 노출 의심 시 대응 절차를 설계 기준으로 제시한다.

사건 개요

보도와 StepSecurity 분석을 종합한 내용은 다음과 같다.

• 변조된 2.1.313은 extension.js에 악성 로더를 담은 채 Cursor 마켓플레이스에 올라왔다. 노출 구간은 10월 29일 약 02:27~13:35 PT(약 11시간)로 보도된다.
• 정상 2.1.312는 10월 27일 Open VSX에 게시됐고, 정상 2.1.314가 10월 30일 Open VSX와 Microsoft Marketplace에 게시됐다.
• Anthropic은 2.1.313이 Open VSX나 Microsoft Marketplace에는 나타난 적이 없고 자사 시스템이 침해되지 않았다고 밝혔다. 즉 문제는 Cursor 마켓플레이스 경로에 한정됐다.
• Cursor는 해당 버전을 내리고 마켓플레이스를 일시 중단해 다른 확장을 점검하고 접근 키를 교체했다고 한다.
• 공격자가 어떤 경로로 게시 권한을 얻었는지는 확인한 자료에서 설명되지 않았다.

페이로드 동작과 지속성

StepSecurity가 정리한 동작은 다음과 같다. 확장 모듈이 로드되면 Node.js 위에서 바로 실행되므로 Claude와의 대화나 패키지 매니저 훅이 필요 없다.

• 공격자 SSH 공개키(주석 svc-telemetry)를 authorized_keys에 심는다.
• 공격자 서버로 역방향 SSH 터널(ssh -N -R)을 연다.
• 호스트 정보를 JSON으로 HTTP POST한다. 환경 변수 이름 중 KEY, TOKEN, SECRET, PASS, AWS, GCP가 포함된 것이 정찰 대상이다.
• macOS에서는 LaunchAgent, Windows에서는 예약 작업과 Startup 스크립트, Linux에서는 @reboot cron으로 지속성을 확보한다.
• 원격 로그인 서비스를 켜려는 시도는 관리자 권한이 필요하므로, Cursor는 macOS와 Windows에서 대체로 활성화에 실패했다고 설명한다.

가장 중요한 점은 확장을 지워도 독립 지속성 스크립트가 남는다는 것이다. 제거만으로는 정리가 끝나지 않는다.

확인된 사실과 남은 의문

• 확인: 변조 버전 번호, 노출 시간대, 정상 버전 번호, 지속성 방식, 침해 지표(IoC)는 여러 매체와 보안 업체 분석이 일치한다.
• 불일치: 일부 매체는 2.1.312도 영향권으로 적었지만 StepSecurity는 2.1.312를 정상 빌드로 분류한다. 점검 시에는 설치된 버전과 해시를 직접 대조해야 한다.
• 미확인: 게시 권한 탈취 경로, 실제 침해된 호스트 수. "최대 5,000명"은 노출 가능 상한이지 침해 확정 수가 아니다.
• IoC 해시와 서버 주소는 시간이 지나면 바뀌므로, 실제 점검은 각 보안 업체의 최신 공지를 기준으로 한다.

대응 흐름

flowchart TD
    A["확장 설치·업데이트"] --> B{"공식 게시자와 출처 일치?"}
    B -->|"아니오"| C["설치 보류"]
    B -->|"예"| D{"버전·해시가 기준과 일치?"}
    D -->|"아니오"| C
    D -->|"예"| E["사용"]
    E --> F{"공급망 침해 공지 발생?"}
    F -->|"아니오"| E
    F -->|"예"| G{"해당 버전 설치 이력 있음?"}
    G -->|"아니오"| H["기록 후 종료"]
    G -->|"예"| I["증거 수집"]
    I --> J["지속성 제거·정상 버전 설치"]
    J --> K["정상 장비에서 자격 증명 교체"]

설치 출처 검증과 무결성 확인 기준

1. 마켓플레이스 단일화: 팀이 허용하는 마켓플레이스와 게시자 ID(anthropic.claude-code)를 목록으로 고정한다. 같은 ID라도 마켓플레이스마다 게시 경로가 다르다는 점이 이번 사건의 핵심이다.
2. 버전 고정: 확장 자동 업데이트를 끄거나 지연 정책을 둔다. 새 버전은 공식 릴리스 노트와 다른 마켓플레이스 게시 여부를 교차 확인한 뒤 올린다.
3. 교차 대조: 같은 버전이 공식 채널(예: Microsoft Marketplace, Open VSX)에도 존재하는지, VSIX 해시가 일치하는지 확인한다. 이번 건처럼 한 마켓플레이스에만 있는 버전은 경고 신호다.
4. 사내 미러: 조직 규모라면 검증을 통과한 VSIX만 담은 내부 저장소에서 배포한다.
5. 인벤토리: 개발자 장비의 설치 확장 목록과 버전을 수집해, 공지가 나왔을 때 조회 한 번으로 노출 여부를 판단한다.
6. 이상 행위 탐지: authorized_keys 변경, 신규 LaunchAgent·예약 작업, 개발 도구 프로세스의 외부 SSH 연결을 알림 대상으로 둔다.

노출 의심 시 대응 절차

Cursor와 StepSecurity가 공개한 절차를 일반화하면 다음과 같다.

1. authorized_keys에서 svc-telemetry 등 낯선 키를 확인한다.
2. 증거를 먼저 수집한 뒤 지속성 항목(LaunchAgent, 예약 작업, cron, 숨김 파일)을 제거한다.
3. 확장을 지우고 정상 버전(2.1.314 이상)을 설치한다.
4. 해당 장비에서 접근 가능했던 자격 증명(소스 관리, CI/CD, 클라우드, SSH, 레지스트리 토큰)을 정상 장비에서 교체한다.
5. SSH, 셸, 프로세스, 인증 로그를 검토한다. 터널이 연결된 흔적이 있으면 정리보다 장비 재구축이 안전하다.

마무리

이번 사건은 AI 에이전트 자체가 아니라 에이전트를 얹는 확장 배포 경로가 공격 지점이 될 수 있음을 보여 준다. 공식 게시자 ID만 믿지 말고 마켓플레이스별 출처, 버전, 해시를 교차 확인하고, 확장 인벤토리로 공지에 즉시 대응할 수 있게 해 두어야 한다. 의심 시에는 확장 제거에서 멈추지 말고 지속성 제거와 자격 증명 교체까지 진행하는 것이 기준이다.

Keywords

Supply Chain Attack, Trojanized Extension, Cursor Marketplace, SSH Backdoor, Integrity Verification, Indicator of Compromise, 공급망 공격, 확장 변조, 설치 출처 검증, 자격 증명 교체

Sources

• Official Claude Code Extension on Cursor Marketplace Trojanized with Persistent SSH Backdoor (The Hacker News)
• Trojanized Claude Code Extension Delivered Persistent SSH Backdoor to Developer Machines (StepSecurity)
• Malicious Claude Code extension on Cursor planted SSH backdoors (BleepingComputer)
• Malicious Claude Code Extension Affects Up to 5,000 Cursor Users (DevOps.com)
• Cursor Discloses SSH Backdoor Attempt in Malicious Claude Code Extension (Unite.AI)

tstack: PR 병합까지 맡기는 코딩 에이전트 스킬 분해와 변경 증명 설계

• tstack의 구성: 9개 스킬과 의존 관계
• 단계별 완료 조건의 위치
• 변경 증명: 세션에서 직접 관찰한 증거
• 병합 게이트: 최신 커밋 기준 다섯 조건
• 리뷰 봇 대응 설계
• 도입 시 고려사항
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

tstack은 Theo Browne이 Claude Code와 Codex에서 매일 쓰는 워크플로우를 MIT 라이선스로 공개한 9종의 에이전트 스킬 묶음이다. 변경 증명, 리뷰 봇 대응, PR 병합까지를 코딩 에이전트가 사용자 개입 없이 수행하도록 설계되었다. 이 글은 하나의 긴 프롬프트 대신 에이전트 워크플로우를 단계별 스킬로 쪼갤 때, 각 단계의 완료 조건과 병합 게이트를 어디에 둘지 tstack의 구조를 기준으로 정리한다.

tstack의 구성: 9개 스킬과 의존 관계

모든 스킬은 PR을 아이디어에서 병합까지 끌고 가는 작업을 중심으로 한다. 각 스킬의 description은 "full send" 같은 짧은 문구에 반응하도록 작성되어 있어, 사용자는 스킬 이름을 외우지 않고 자연어 트리거로 호출한다.

스킬 간 의존은 조합형이다. full-send는 sol-loop, file-pr, babysit-pr를 호출하고, full-stop은 full-send를 재사용하며, takeover는 modernize, file-pr, babysit-pr, leaving-pr-comments를 호출한다. 실행 전제는 인증된 gh CLI, babysit-pr의 대기 스크립트용 python3, 그리고 다른 제공자 모델을 서브에이전트로 띄울 수 있는 하네스다.

flowchart TD
    A["(1) 최소 수정"] --> B["(2) 변경 증명"]
    B --> C["(3) sol-loop 리뷰"]
    C --> D["(4) file-pr 생성"]
    D --> E["(5) babysit-pr 감시"]
    E --> F{"병합 게이트 통과?"}
    F -->|"아니오"| E
    F -->|"예: full-send"| G["(6) 병합"]
    F -->|"예: full-stop"| H["사용자 병합 대기"]
    G --> I["(7) 결과 보고"]

단계별 완료 조건의 위치

스킬을 쪼갤 때 핵심은 각 스킬이 "언제 끝났다고 말할 수 있는가"를 스스로 정의하게 하는 것이다. tstack은 완료 조건을 세 층으로 나눈다.

• 파이프라인 층(full-send): 7단계를 모두 마치고 보고까지 해야 끝난다. 스킬은 턴을 끝내면 작업이 멈춘다는 점을 명시해, CI나 봇이 대기 중이면 에이전트가 계속 감시하도록 강제한다.
• 리뷰 층(sol-loop, council): 두 에이전트 또는 세 위원이 합의해야 끝난다. council은 10점 만점 점수를 라운드별 표로 PR 설명에 남기고, 점수가 없는 위원은 "no score"로 적으며 값을 지어내지 않는다. 세 제공자에 접근할 수 없으면 대체하지 않고 실행 불가를 보고한다.
• 작업 층(file-pr): PR 생성과 최신 기본 브랜치 기준 리베이스가 끝나면 끝난다.

완료 조건을 파이프라인에 몰지 않고 각 스킬에 분산하면, 개별 스킬을 단독으로 호출해도 종료 시점이 모호해지지 않는다. 다만 babysit-pr나 modernize처럼 공개된 설명에 종료 조건이 명시되지 않은 스킬은 실제 SKILL.md를 읽어 확인해야 한다.

변경 증명: 세션에서 직접 관찰한 증거

tstack에서 증명은 에이전트가 해당 세션에서 직접 관찰한 증거만 뜻한다. 선호 순서는 다음과 같다.

1. 원래 문제를 재현하고, 수정 후 같은 재현이 통과하는지 확인한다.
2. 저장소의 CI 체크(타입 검사, 린트, 테스트)를 실행한다.
3. 수정 전에는 실패하고 수정 후에는 통과하는 테스트를 추가한다.
4. UI나 실행 동작은 앱을 직접 띄워 확인한다. 모의 객체로 만든 녹색 테스트만으로는 사용자 경험이 동작한다는 증거가 되지 못한다.

검증 방법을 찾지 못하면 에이전트는 확신이 없다고 판단하고 사용자에게 질문한다. 증명이 "있다/없다"가 아니라 "diff 전체를 덮는가"로 판정되는 점이 병합 게이트와 연결된다.

병합 게이트: 최신 커밋 기준 다섯 조건

병합 게이트는 마지막 커밋 기준으로 다섯 조건을 모두 충족해야 열린다.

• 증명이 diff 전체를 포함한다.
• 필수 체크가 모두 통과한다.
• 리뷰 봇이 끝났고, 지적 사항은 수정되었거나 이유와 함께 기각되었다.
• 사람의 리뷰에 변경 요청이 없고 팀원이 막고 있지 않다.
• 브랜치가 최신이며 GitHub가 병합 가능하다고 표시한다.

병합은 저장소의 기본 방식과 브랜치 보호 규칙을 따르고 --admin 같은 우회는 쓰지 않는다. 리베이스 후에는 --force-with-lease로 푸시할 수 있다. 게이트를 "최신 커밋 기준"으로 평가하는 이유는, 수정 푸시 이후 이전 커밋에서 받은 통과 결과가 무효가 되기 때문이다.

리뷰 봇 대응 설계

babysit-pr는 에이전트가 sleep 루프를 직접 만들지 못하게 하고, T3 Code에서는 watch_pull_request, 다른 하네스에서는 pr-wait 스크립트로 이벤트가 있을 때만 에이전트를 깨운다. 봇별 취급도 달라서, Greptile과 Macroscope는 기다리고 CodeRabbit은 참고용으로 두며 github-actions와 Vercel 댓글은 건너뛴다. 수정 기준은 실제 버그만 고치는 것이고, 불필요한 테스트, 일어나지 않을 경우를 위한 가드, 추가 호환성 코드는 이유를 적어 기각한다. sol-loop의 지적은 blocker, should, nit으로 나누며, 리뷰 후 diff가 커졌다면 먼저 줄인다.

도입 시 고려사항

• GitHub 종속: GitLab이나 PR 없는 팀이라면 여러 부분을 다시 써야 한다.
• 롤백 체계: full-send는 빠른 롤백이 있을 때 안전하다. 원저자는 6시간마다 nightly 빌드를 배포해 문제를 빨리 발견한다고 설명한다.
• 수치의 해석: 32건 중 27건이 재확인 없이 병합되었다는 수치는 원저자의 로그 기준이며 일반화된 벤치마크가 아니다.
• 자동 병합 위험: 사람의 검토가 필요하다는 자동 리뷰를 에이전트가 확신할 때 무시할 수 있다는 규칙은 팀 정책에 맞게 조정해야 한다. 처음에는 full-stop으로 시작해 신뢰가 쌓인 뒤 full-send로 넘어가는 편이 안전하다.

마무리

tstack은 PR 병합이라는 긴 작업을 증명, 리뷰, 감시, 병합의 스킬로 분해하고 각 단계에 종료 조건을 붙인 사례다. 핵심 설계는 세션에서 직접 관찰한 증거만 인정하는 변경 증명과, 최신 커밋 기준 다섯 조건으로 구성된 병합 게이트다. 병합 권한을 어디까지 위임할지는 full-stop과 full-send의 선택으로 조절할 수 있으므로, 팀의 롤백 능력에 맞춰 단계적으로 도입하는 것이 바람직하다.

Keywords

coding agent, agent skills, merge gate, proof of change, review bot, 코딩 에이전트, 에이전트 스킬, 병합 게이트, 변경 증명, 리뷰 봇

Sources

• tstack de Theo: 9 skills para llevar un PR hasta el merge (Webreactiva)
• tstack t3dotgg agent skills full send council guide 2026 (explainx)
• Theo Browne Open-Sources tstack to Automate the Entire PR Lifecycle (AlphaSignal)
• tstack (EveryDev)

PHP2Shell 연쇄 공격: 방화벽·관리 서버 25대 루트 탈취 경로 분석과 방어 우선순위 설계

• 사건 개요와 확인 수준
• 공격 흐름: 방화벽에서 내부망까지
• 왜 관리 장비가 표적이 되는가
• 방어 우선순위 설계
• 읽을 때 주의할 점
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

2026년 10월 하순 보안업체 Dream은 PHP2Shell 원격 코드 실행 취약점과 리눅스 커널 권한 상승 취약점 Fragnesia를 연결해 미국·일본·대만·한국의 서버 25대에서 루트 권한을 얻은 공격 사례를 공개했다. 표적은 인터넷에 노출된 방화벽과 그 관리 서버였으며, 한 번 장악한 관리 장비가 내부망 침투의 발판이 되었다. 이 글은 공개된 보도를 바탕으로 공격 흐름을 단계별로 정리하고, 패치 이후에도 남는 노출 면에 대한 방어 우선순위를 설계한다. 다만 공격자 귀속과 피해 규모는 대부분 단일 업체의 분석에 근거하므로 확정 사실과 구분해 읽어야 한다.

사건 개요와 확인 수준

정부 관련 서버 수는 매체마다 다르게 보도되었다(3대 또는 2대). 또한 일부 요약이 전하는 "추가 22대의 웹셸 잔존" 주장은 한 곳에서만 확인되어 이 글에서는 근거로 쓰지 않는다.

공격 흐름: 방화벽에서 내부망까지

보도된 공격은 다음 순서로 진행되었다.

1. FOFA로 인터넷 노출 방화벽 약 19,000대를 식별하고, 살아 있는 약 5,000대 가운데 PHP 8.0.30을 쓰는 240대를 추려 표적으로 삼았다.
2. 맞춤 제작한 4단계 PHP2Shell 익스플로잇으로 관리 웹 서비스에서 nobody 권한의 명령 실행을 얻었다.
3. Fragnesia로 루트 권한을 얻고 공개 접근이 가능한 디렉터리에 웹셸을 심어 지속성을 확보했다.
4. 장악한 방화벽을 통해 내부망으로 터널을 만들고, 내부 방화벽 관리 서버에 같은 체인을 재사용했다.
5. 관리 서버에 중앙 저장된 설정에서 복호화 키를 얻어 LDAP 서비스 계정 비밀번호를 해독하고, 도메인 사용자 열거와 비밀번호 스프레이, 백도어 계정 생성, SAML 서명 키 탈취를 시도했다.

초기 접근부터 루트 웹셸까지 전체 체인은 15분 안에 끝난다고 보고되었다. 첫 정부 관련 방화벽은 10월 23일 장악되었으나 약 900MB의 익스플로잇 트래픽 때문에 장비가 멈춘 것으로 추정된다. 백도어 계정과 SAML 키 탈취의 성공 여부는 결과가 관리 서버 파일시스템에 남아 있어 확인되지 않았다.

flowchart TD
    A["인터넷 노출 관리 웹 서비스"] --> B["PHP2Shell 원격 코드 실행"]
    B --> C["nobody 권한 명령 실행"]
    C --> D["Fragnesia 로컬 권한 상승"]
    D --> E["루트 권한과 웹셸 지속성"]
    E --> F["내부망 터널 구성"]
    F --> G["방화벽 관리 서버 재공략"]
    G --> H["설정 복호화 키 확보"]
    H --> I["LDAP 서비스 계정과 AD 공격"]

왜 관리 장비가 표적이 되는가

방화벽과 관리 서버는 세 가지 이유로 공격자에게 가치가 높다.

• 신뢰 위치: 내부망과 외부망의 경계에 있어 장악하면 터널의 출발점이 된다.
• 자격 증명 집중: 중앙 관리 서버는 여러 장비의 설정과 연동 계정(LDAP, SAML 등)을 한곳에 보관한다.
• 관측 사각지대: 폐쇄형 어플라이언스에는 EDR을 설치하기 어려워 침해 탐지가 늦다.

특히 이번 사례는 취약한 애플리케이션이 아니라 PHP 런타임 자체의 결함이 시작점이다. 제품 벤더가 번들한 PHP는 일반 서버처럼 직접 패치할 수 없으므로 벤더 업데이트를 기다려야 하는 구간이 길어진다.

방어 우선순위 설계

패치만으로는 충분하지 않다. 이미 침해된 장비에는 웹셸과 터널이 남고, 중앙에 저장된 비밀값은 이미 유출되었을 수 있다.

우선순위 1: 관리 인터페이스 노출 제거

• 관리 웹 UI를 인터넷에서 접근 불가하게 하고, 전용 관리망이나 VPN 뒤로 옮긴다.
• 이번 사례의 초기 접근 경로가 노출된 관리 서비스였으므로 가장 비용 대비 효과가 크다.

우선순위 2: 두 계층의 패치

• PHP2Shell은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35에서 수정되었다. 번들 PHP는 벤더 권고를 따른다.
• Fragnesia는 2026년 5월 13일 이전 커널이 영향권이며 공개 PoC가 있다. 한 계층만 패치해도 체인은 끊기지만 다른 계층의 결함은 남는다.

우선순위 3: 침해 가정 점검

• 공개 접근 가능한 디렉터리의 신규 파일(웹셸)과 알 수 없는 터널, 비정상 아웃바운드 연결을 점검한다.
• 10월 23일 이후 관리 서비스 접근 로그에서 대용량 요청과 반복 오류를 확인한다.

우선순위 4: 비밀값 회수

• 관리 서버가 보관한 LDAP 서비스 계정 비밀번호를 교체하고, AD의 신규 계정과 권한 변경을 검토한다.
• SAML 서명 키 접근이 의심되면 키를 교체하고 신뢰 관계를 재설정한다.

우선순위 5: 완화 설정과 탐지

• 패치 전에는 session.upload_progress.enabled=0, 요청 본문 크기 제한 등 PHP2Shell 완화책을 적용한다. 임시 조치일 뿐 완전한 해결이 아니다.
• 관리 장비의 로그를 외부 SIEM으로 전송해 장비 내부 로그가 지워져도 추적할 수 있게 한다.

flowchart LR
    A["관리 인터페이스 노출 제거"] --> B["PHP·커널 패치"]
    B --> C["웹셸·터널 점검"]
    C --> D{"침해 징후?"}
    D -->|"예"| E["장비 격리와 비밀값 전량 교체"]
    D -->|"아니오"| F["로그 외부 전송과 모니터링"]
    E --> G["AD·SAML 신뢰 재설정"]

읽을 때 주의할 점

이 사례의 상세 내용은 Dream의 분석에 크게 의존하며, The Register는 Unit 42가 도구와 결과를 독립적으로 검증했다고 전한다. CISA와 FBI는 논평하지 않았다. 중국 연계 추정은 확정이 아니고, 공격자의 작업 환경에서 Claude Code와 DeepSeek·Kimi 기반 공격 보안 플랫폼이 발견되었으나 완전 자동 공격은 아니라고 보고되었다. 운영자는 귀속 논쟁과 무관하게 노출 면과 비밀값 관리를 점검해야 한다.

마무리

PHP2Shell과 Fragnesia의 연쇄는 취약점 하나가 아니라 "원격 코드 실행 후 로컬 권한 상승"이라는 조합이 관리 장비를 어떻게 무너뜨리는지 보여준다. 패치는 필수이지만 관리 인터페이스의 노출 제거와 중앙 저장 비밀값의 교체가 없으면 침해의 영향은 남는다. 두 계층을 함께 패치하고, 침해를 가정한 점검과 자격 증명 회수까지 하나의 절차로 설계하는 것이 우선순위다.

Keywords

PHP2Shell, Fragnesia, privilege escalation, management plane, web shell, 방화벽 관리 서버, 루트 탈취, 노출 면 축소, 자격 증명 회수, 침해 가정 점검

Sources

• The Register: Suspected Chinese attackers built a custom PHP2Shell exploit and rooted 25 servers
• BleepingComputer: CISA warns of Fragnesia Linux flaw chained in PHP2Shell attacks
• BleepingComputer: CISA confirms PHP2Shell vulnerabilities now exploited in attacks
• Cybersecurity News: Hackers Chain PHP2Shell and Linux Kernel Exploits to Gain Root Access on 25 Servers
• Aviatrix: PHP2Shell CVE-2026-109618 Attack Roots 25 Servers

Runway Praxis-1: 웹 영상 사전학습 로봇 정책 모델의 구조와 공개 전 검증 기준

• 발표 내용
• 핵심 가정과 보고된 근거
• 구조 개념과 검증 흐름
• 공개 전 검증 기준
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

Runway는 웹 영상으로 사전학습한 오픈 웨이트 "월드 액션 모델" Praxis-1을 발표했다. 로봇 행동 데이터를 직접 모으는 대신 대규모 영상에서 물리 세계의 이해를 먼저 학습시킨다는 가정이 핵심이다. 가중치는 앞으로 수개월 안에 공개될 예정이라 현재는 벤더 발표 단계이므로, 이 글은 공개된 주장과 도입 전에 확인해야 할 조건을 구분해 정리한다.

발표 내용

Runway 공식 페이지와 보도에서 확인되는 내용은 다음과 같다.

• 이름과 성격: 일반 월드 모델과 같은 대규모 영상 사전학습 위에 만든 오픈 웨이트 월드 액션 모델이다.
• 상태: 파트너 테스트 중이며 공개는 "앞으로 몇 달 안"이고, 공개 시 오픈 웨이트로 배포된다고 밝혔다.
• 파트너: Noble Machines(양손 조작), Standard Bots(6자유도 팔), Ultra(이동 베이스)가 자사 하드웨어에서 시험 중이다. 이 시험의 결과 수치는 공개되지 않았다.
• 모델 크기, 계층 구성, 학습 설정 등 구조 세부는 해당 페이지에 나와 있지 않다.

핵심 가정과 보고된 근거

가정은 "영상으로 물리 세계를 먼저 이해한 모델은 로봇 행동 데이터만으로 학습한 정책보다 유리하다"이다. 근거로 제시된 수치는 다음과 같다.

여기서 읽어야 할 점은 16.1cm와 16.0cm가 사실상 동등이라는 것이다. 웹 영상이 원격조종 데이터보다 낫다는 결과가 아니라, "수집 비용이 훨씬 낮은 웹 영상으로도 비슷한 수준에 도달했다"는 결과다. 해당 페이지도 오차 막대보다 작은 차이는 유의하지 않다고 적는다. 모든 수치는 Runway 자체 발표이며 독립 검증은 확인되지 않았다.

구조 개념과 검증 흐름

flowchart TD
    A["웹 영상 대규모 사전학습"] --> B["월드 액션 모델"]
    B --> C["소량 로봇 데이터로 미세조정"]
    C --> D["로봇 정책"]
    D --> E["월드 모델 내 시뮬레이션 평가"]
    D --> F["실기기 평가"]
    E --> G{"실기기 결과와 상관 확인"}
    F --> G
    G -->|"통과"| H["도입 검토"]
    G -->|"미달"| I["평가 조건 재설계"]

공개 전 검증 기준

1. 비교 조건 확인: 웹 영상 대 원격조종 비교에서 미세조정 데이터 양, 평가 물체, 반복 횟수, 오차 막대가 같은지 확인한다.
2. 실패 유형 대응: 페이지가 제시한 실패 사례(반복적·강체 물체, 혼잡한 장면, 투명 물체, 천 같은 변형 물체)가 자사 작업에 해당하는지 먼저 따진다. 이는 시연 전용 정책이 흔히 무너지는 지점이며 Praxis-1의 알려진 한계 목록은 아니다.
3. 하드웨어 적합성: 파트너 시험이 팔, 양손, 이동 베이스를 포괄하지만 결과가 없으므로 자사 기체에서의 데이터가 나올 때까지 판단을 보류한다.
4. 시뮬레이션 상관의 범위: 0.95는 특정 평가 집합에서의 값이다. 자사 작업에서 상관이 유지되는지 소규모 실측으로 확인한다.
5. 라이선스·가중치 조건: 오픈 웨이트라도 사용 조건, 모델 크기, 추론 하드웨어 요구량은 공개 시점에 확인해야 한다.
6. 안전 게이트: 실기기 시험은 속도·힘 제한과 비상정지가 있는 환경에서 단계적으로 진행한다.

마무리

Praxis-1은 로봇 데이터 수집 병목을 영상 사전학습으로 완화하려는 시도이며, 현재 근거는 동등 수준의 단일 배치 오차 결과와 시뮬레이션 상관에 한정된다. 가중치가 공개되기 전까지는 벤더 주장으로 두고, 공개 후 자사 작업과 하드웨어 기준으로 재현 평가를 수행하는 것이 현실적이다.

Keywords

Runway Praxis-1, World Action Model, Robot Policy, Video Pretraining, Open Weights, Teleoperation Data, 로봇 정책 모델, 월드 모델, 웹 영상 사전학습, 벤치마크 검증

Sources

• Introducing Praxis 1 (Runway Research)
• Runway introduces Praxis-1 world action model (The Robot Report)
• Runway moves into robotics with open weight Praxis 1 AI model (Robotics & Automation News)

AI 인용 통계 검증 절차: 원출처 대조 없이 AI가 준 수치를 쓰면 안 되는 이유

• 연구가 말하는 것과 한계
• 수치가 어긋나는 경로
• 역추적 검증 흐름
• 게이트 설계
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

AI 어시스턴트가 제시한 통계를 원출처까지 따라가 보면 상당수가 어긋난다. trakkr.ai의 "Zombie Stats" 연구는 5개 AI 서비스가 인용한 통계를 추적해, 원출처와 같은 내용을 말하는 경우가 40% 수준이라고 보고한다. 이 글은 이 연구의 확인된 범위를 짚고, 기술 블로그와 보고서에서 AI가 준 수치를 원출처로 역추적하는 검증 절차와 게이트를 설계한다.

연구가 말하는 것과 한계

확인한 내용은 다음과 같다.

• trakkr.ai Research Study 013 "Zombie Stats"는 5개 AI 어시스턴트에 숫자가 필요한 질문 200개를 던지고, 인용된 통계를 출처까지 추적했다.
• 본문은 1,285건을 추적했다고 하며, 이 중 약 4할이 같은 내용을 말하는 연구에 도달하고 11%는 어디에도 닿지 못했다.
• 숫자를 인용한 페이지 중 원 연구인 것은 21%뿐이었다.
• 5개 서비스 평균은 서비스별 인용 통계 수로 가중한 값이다.

주의할 점도 있다.

• 발행 주체가 AI 검색 가시성 도구 벤더이며 독립 검증은 확인되지 않았다.
• 페이지 구조화 데이터에는 추적 통계가 1,783건으로 적혀 있어 본문의 1,285건과 일치하지 않는다. 표본 크기는 원문 전체 보고서로 확인해야 한다.
• 2025년의 다른 연구(참고문헌 생성 과제)에서는 완전히 정확한 참고문헌이 26.5%였는데, 측정 대상이 달라 직접 비교할 수 없다.

따라서 "40%"를 정확한 오류율로 인용하기보다 "AI 인용 수치는 원출처 대조 없이는 신뢰하기 어렵다는 방향의 증거"로 쓰는 것이 정직하다. 이 글 자체도 같은 기준을 적용한 것이다.

수치가 어긋나는 경로

1. 2차 재인용: 원 연구가 아니라 요약 블로그의 문장을 근거로 삼는다.
2. 수치 변형: 표본, 기간, 단위가 빠져 의미가 달라진다.
3. 출처 소실: 링크는 있지만 해당 수치가 페이지에 없다.
4. 오래된 수치의 순환: 한 번 퍼진 수치가 계속 인용된다. 연구가 "좀비"라 부르는 현상이다.

역추적 검증 흐름

flowchart TD
    A["AI가 제시한 수치"] --> B{"출처 링크가 있는가?"}
    B -->|"아니오"| C["수치 사용 보류"]
    B -->|"예"| D{"링크 페이지에 수치가 있는가?"}
    D -->|"아니오"| C
    D -->|"예"| E{"원 연구인가 2차 인용인가?"}
    E -->|"2차 인용"| F["원 연구로 한 단계 더 역추적"]
    F --> D
    E -->|"원 연구"| G{"표본·기간·단위 일치?"}
    G -->|"아니오"| H["원문 조건으로 문장 수정"]
    G -->|"예"| I["수치 채택, 원출처 링크 기재"]

게이트 설계

1. 수치 목록화: 초안에서 숫자, 비율, 연도가 들어간 문장을 모두 뽑아 표로 만든다.
2. 열 구성: 수치 / AI 제시 출처 / 원출처 URL / 원문 문구 / 표본·기간·단위 / 판정(채택·수정·삭제).
3. 통과 기준: 원출처 원문에서 같은 수치를 직접 확인한 항목만 채택한다. 확인 불가 항목은 삭제하거나 "확인되지 않음"을 명시한다.
4. 2차 출처 규칙: 요약 기사만 확인된 경우 본문에 "보도에 따르면"과 같이 층위를 표시한다.
5. 벤더 연구 표기: 이해관계가 있는 발행 주체의 수치는 그 사실을 함께 적는다.
6. 자동화: 링크 접근과 수치 문자열 검색은 스크립트로 1차 필터링하되, 의미 일치(표본·단위)는 사람이 확인한다.
7. 기록: 검증 표를 초안과 함께 보관해 이후 수정 시 재검증 범위를 알 수 있게 한다.

마무리

AI가 준 수치는 출처 링크가 붙어 있어도 원문에 없거나 조건이 바뀌어 있을 수 있다. 수치별 원출처 확인 표와 채택 기준을 게이트로 두면 이런 오류가 글에 들어가는 것을 줄일 수 있다. 다만 인용 정확도 연구 자체도 벤더 자료이므로 표본과 방법을 확인하며 쓰는 태도가 같은 원칙의 일부다.

Keywords

AI Citation Accuracy, Zombie Stats, Source Verification, Fact-Checking Gate, Hallucinated Statistics, trakkr, AI 인용 통계, 원출처 대조, 수치 검증 절차, 기술 블로그 품질 관리

Sources

• Zombie Stats: Where the Numbers AI Quotes Come From (trakkr.ai)
• AI Search Research (trakkr.ai)
• Study: AI chatbots usually cite incorrect sources (Computerworld)
• Grok and DeepSeek outperform ChatGPT, but non… (arXiv 2505.18059)

Claude Code Write 덮어쓰기 방지: 부분 읽기 후 쓰기를 막는 파일 편집 안전 설계

• 확인 범위
• 문제의 구조
• 쓰기 안전 규칙 흐름
• 설정 파일 관리 절차에 반영할 기준
• 마무리
• Keywords
• Sources

홈랩 구축 체크리스트 — 로컬 LLM을 세우고 Tailscale로 안전하게 잇는 20단계를 A4 한 장으로 정리했습니다.
체크리스트 받기 →

코딩 에이전트가 큰 CLAUDE.md나 규칙 파일을 일부만 읽은 채 Write로 파일 전체를 다시 쓰면, 읽지 않은 부분이 조용히 사라진다. 이번 주제는 Claude Code v2.1.312(10/27)에서 이 문제가 고쳐져 Write가 전체 파일 읽기 또는 편집을 요구하게 됐다는 내용이다. 다만 필자는 공식 변경 이력에서 해당 항목을 직접 확인하지 못했으므로, 이 글은 그 전제를 "보도된 변경"으로 두고 설정 파일 관리 절차에 반영할 기준을 정리한다.

확인 범위

• 검색에서 v2.1.312 항목이나 "부분 읽기 후 Write" 수정은 찾지 못했다. 공식 CHANGELOG(github.com/anthropics/claude-code)에서 해당 버전 문구를 직접 대조해야 한다.
• 관련 선행 변경으로, v2.1.228을 다룬 외부 정리에는 Write 도구가 "새 모델은 세션에서 읽지 않은 기존 파일도 Edit와 같은 규칙으로 덮어쓸 수 있고, 기존 모델은 사전 읽기가 필요"하도록 바뀌었다고 적혀 있다. 즉 읽기 선행 규칙은 모델과 버전에 따라 달라 왔다.
• 따라서 "Write는 언제나 안전하다"고 가정하면 안 되며, 버전별 동작은 사용 중인 버전에서 직접 시험해야 한다.

문제의 구조

대형 규칙 파일은 읽기 도구의 줄 수·크기 제한 때문에 앞부분만 읽히기 쉽다. 이때 에이전트가 수정 의도를 반영해 "전체 내용"을 새로 쓰면 결과는 다음과 같다.

1. 읽은 부분: 의도대로 갱신됨
2. 읽지 않은 부분: 내용이 사라짐
3. 오류 신호: 없음. 쓰기는 성공으로 보고된다

사고가 조용하다는 점이 위험이다. 규칙 파일은 에이전트의 행동 기준이므로, 일부 소실은 이후 세션의 동작 변화로만 드러난다.

쓰기 안전 규칙 흐름

flowchart TD
    A["파일 수정 요청"] --> B{"대상 파일을 전체 읽었는가?"}
    B -->|"예"| C["Write 허용 후 변경 검토"]
    B -->|"아니오"| D{"부분 수정으로 충분한가?"}
    D -->|"예"| E["Edit로 해당 구간만 변경"]
    D -->|"아니오"| F["전체 읽기 후 재시도"]
    C --> G["diff로 소실 줄 수 확인"]
    E --> G
    F --> B

설정 파일 관리 절차에 반영할 기준

1. 기본 도구는 Edit: 규칙 파일 수정은 구간 단위 Edit를 기본으로 하고, Write는 신규 파일이나 전체 재작성에만 쓴다.
2. 전체 읽기 확인: 큰 파일을 Write로 바꿀 때는 읽기 결과가 파일 끝까지 도달했는지(총 줄 수와 비교)를 확인한다.
3. 줄 수 가드: 수정 전후 줄 수와 헤더 목록을 비교해, 의도하지 않은 감소가 있으면 변경을 되돌린다.
4. 버전 관리: CLAUDE.md, 규칙 파일, 스킬 정의를 git으로 관리해 소실 시 복구 경로를 확보한다. 이 레포처럼 커밋 없이도 작업 트리가 곧바로 운영에 쓰이는 환경에서는 특히 중요하다.
5. 파일 분할: 규칙 파일을 주제별로 쪼개 한 번에 읽히는 크기로 유지하면 부분 읽기 자체가 줄어든다.
6. 보호 장치의 한계 인식: 도구가 덮어쓰기를 막아도 읽고 쓴 사이에 외부에서 파일이 바뀌는 경우나 잘못된 내용으로 "정상 덮어쓰기"하는 경우는 막지 못한다. 변경 검토는 여전히 필요하다.

마무리

Write가 전체 읽기 또는 편집을 요구하도록 바뀌었다면, 조용한 내용 소실이라는 실패 유형이 도구 수준에서 줄어드는 것이다. 그래도 설정 파일 관리에서는 Edit 우선, 줄 수 비교, git 이력이라는 절차를 함께 두어야 한다. 해당 수정 항목은 공식 변경 이력으로 확인한 뒤 팀 규칙에 근거로 적는 것이 안전하다.

Keywords

Claude Code, Write Tool, Edit Tool, CLAUDE.md, File Overwrite, Partial Read, 파일 편집 안전, 덮어쓰기 방지, 설정 파일 관리, 변경 이력 검증

Sources

• Claude Code Changelog (anthropics/claude-code)
• Claude Code v2.1.228~v2.1.229 Major Updates (classmethod)
• Claude Code Changelog: Complete Version History (claudefa.st)