# desloppify Long-Running > Author: Tony Lee > Published: 2026-04-13 > URL: https://tonylee.im/zh-TW/blog/desloppify-long-running/ > Reading time: 4 minutes > Language: zh-TW > Tags: ai, builders, notes ## Canonical https://tonylee.im/zh-TW/blog/desloppify-long-running/ ## Rollout Alternates en: https://tonylee.im/en/blog/desloppify-long-running/ ko: https://tonylee.im/ko/blog/desloppify-long-running/ ja: https://tonylee.im/ja/blog/desloppify-long-running/ zh-CN: https://tonylee.im/zh-CN/blog/desloppify-long-running/ zh-TW: https://tonylee.im/zh-TW/blog/desloppify-long-running/ ## Description Blog version of a 2026-04-14 LinkedIn note — same claims, cleaned structure for reading. ## Summary desloppify Long-Running is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts. ## Outline - Context - Links ## Content This is the long-form blog cut of a note I originally posted on LinkedIn. The claims, numbers, and product names are the same; the formatting is for reading on the site. ### Context Original framing (translated in place for key technical posts; substance preserved): > 최근에 Loop 구조가 에이전트의 핵심이라는 이야기를 한 적이 있는데요. > 마침 그 원리를 가장 선명하게 보여주는 프로젝트를 만났습니다. > > desloppify라는 코드 품질 분석 도구인데, 이 도구가 흥미로운 이유는 "한 번 스캔하고 끝"이 아니라 코드를 처음부터 끝까지 이해한 뒤, 고치고, 다시 검증하는 전체 사이클을 스스로 반복한다는 점입니다. > > 구조를 뜯어보면서 long-running 에이전트가 어떻게 작업을 깨뜨리지 않고 완주하는지 정리해봤어요. > > 1️⃣ 코드를 빠짐없이 파악한다: 탐지에서 실행까지 이어지는 해석 파이프라인 > > github repo: https://lnkd.in/gEa3Wiqj > > desloppify가 코드베이스를 처음부터 파악하는 방식이 인상적이에요. > 단순히 린터를 돌리는 게 아니라 여러 계층이 순차적으로 코드를 해석합니다. > > • Detection Layer: AST 파서와 린터로 데드코드, 순환 복잡도, 네이밍 위반 같은 객관적 이슈를 탐지합니다. 모든 탐지 최근에 Loop 구조가 에이전트의 핵심이라는 이야기를 한 적이 있는데요. 마침 그 원리를 가장 선명하게 보여주는 프로젝트를 만났습니다. desloppify라는 코드 품질 분석 도구인데, 이 도구가 흥미로운 이유는 "한 번 스캔하고 끝"이 아니라 코드를 처음부터 끝까지 이해한 뒤, 고치고, 다시 검증하는 전체 사이클을 스스로 반복한다는 점입니다. 구조를 뜯어보면서 long-running 에이전트가 어떻게 작업을 깨뜨리지 않고 완주하는지 정리해봤어요. 1️⃣ 코드를 빠짐없이 파악한다: 탐지에서 실행까지 이어지는 해석 파이프라인 github repo: https://lnkd.in/gEa3Wiqj desloppify가 코드베이스를 처음부터 파악하는 방식이 인상적이에요. 단순히 린터를 돌리는 게 아니라 여러 계층이 순차적으로 코드를 해석합니다. • Detection Layer: AST 파서와 린터로 데드코드, 순환 복잡도, 네이밍 위반 같은 객관적 이슈를 탐지합니다. 모든 탐지기가 detect_*(data, config) → list[dict] 형태의 순수 함수로 구현돼 있어서 언어에 관계없이 동일한 포맷으로 이슈를 출력해요 • Narrative Layer: 탐지된 이슈에 LLM 기반 리뷰로 맥락을 입힙니다. 단순히 "이 함수가 복잡하다"가 아니라 왜 문제인지, 어떻게 고쳐야 하는지 서사를 생성하는 단계예요 • Prioritization Layer: ranking.py가 이슈를 티어(T1~T4) × 영향도 × 신뢰도 × 발생 빈도로 정렬하고, 관련 이슈끼리 클러스터링합니다. 같은 디렉토리의 같은 탐지기가 잡은 이슈들을 묶어서 한 번에 처리할 수 있게 하는 거죠 • Execution Layer: 작업 큐가 todo → in_progress → done 상태를 관리하면서 자동 수정과 수동 수정을 모두 지원합니다 제가 직접 뜯어보면서 감탄한 건, 탐지부터 실행까지 각 단계의 출력 포맷이 완전히 정규화돼 있다는 점이에요. 이게 루프가 깨지지 않는 첫 번째 비결입니다. 2️⃣ 한 번 고치면 끝이 아니다: 영속 상태 위에서 돌아가는 재스캔 루프 대부분의 AI 코드 도구는 한 번 분석하고 결과를 던져주면 끝입니다. desloppify는 .desloppify/ 폴더에 상태를 영속적으로 유지해요. • state.json: 언어별 현재 스캔 상태. 각 이슈에 고유 ID, 탐지기명, 티어, 카테고리, 파일 경로, 신뢰도(0.0~1.0), 영향도(0.0~1.0)가 전부 기록됩니다 • plan.json: 우선순위가 매겨진 작업 큐가 세션을 넘어서도 유지됩니다. plan_pos 값으로 명시적 순서를 지정할 수 있고, 없으면 티어 → 영향도 → 신뢰도 → 발생 횟수 → ID 순으로 자동 정렬돼요 • score-snapshot-*.json: 스코어 히스토리가 시계열로 쌓입니다 핵심은 수정이 끝나면 자동으로 재스캔이 돌아가고, 그 결과가 다시 탐지 단계로 연결된다는 점이에요. 왜 이게 중요하냐면, 코드에서 한 문제를 고치면 그 아래 가려져 있던 다른 문제가 드러나는 경우가 많거든요. 예를 들어 사용하지 않는 함수를 삭제했더니, 그 함수가 유일하게 호출하던 유틸리티도 이제 미사용 코드가 되는 식이죠. desloppify는 이렇게 연쇄적으로 드러나는 이슈를 기존 상태와 자동으로 병합하면서 open, resolved, stale로 분류합니다. 에이전트가 "이제 됐다"고 멈추는 게 아니라 진짜로 깨끗해질 때까지 루프를 계속 도는 거죠. 3️⃣ 수백 회 반복해도 깨지지 않는다: 스키마가 루프를 지탱하는 방식 이 루프가 수십, 수백 회 반복돼도 안정적으로 돌아가는 이유가 있어요. • Phase Execution 패턴: 각 단계가 extractors → detectors → normalize → state.merge() 순서로 엄격하게 실행됩니다. 어느 단계에서 실패해도 이전 상태가 보존되기 때문에 중간에 멈춰도 이어서 돌릴 수 있어요 • 정규화된 Finding 스키마: 모든 탐지기가 동일한 구조(id, detector, tier, category, file, confidence, impact)로 결과를 출력하기 때문에 파이프라인 어디에서든 데이터가 호환됩니다 • Hook Registry: 언어별로 탐지 규칙을 오버라이드할 수 있는 훅 시스템이 있어서, Python의 네이밍 규칙과 Rust의 네이밍 규칙이 다르더라도 같은 루프 안에서 각각 적절하게 처리돼요 에이전트를 운영해보면 절실하게 느끼는 부분인데, long-running 에이전트가 실패하는 가장 흔한 원인이 "중간 단계의 출력 포맷이 다음 단계와 안 맞는 것"입니다. desloppify는 이걸 스키마 레벨에서 원천 차단한 겁니다. 4️⃣ 점수를 속이면 오히려 불리해진다: 안티-게이밍이 루프에 의미를 만드는 법 desloppify는 lenient 점수(열린 이슈만 계산)와 strict 점수(wontfix 포함 전체 계산)를 이중으로 관리합니다. • 문제를 wontfix로 무시하면 lenient 점수는 내려가지만 strict와의 격차가 벌어집니다 • 리뷰를 다시 돌리면 새 이슈가 발견돼서 점수가 오히려 일시적으로 떨어질 수 있어요 • 티어별 가중치(T1=1, T2=2, T3=3, T4=4)에 영향도를 곱해서 산정하기 때문에 사소한 이슈만 골라 고치는 것도 통하지 않습니다 진짜로 코드를 개선하지 않으면 점수가 올라가지 않는 구조. 이게 에이전트가 루프를 의미 있게 돌게 만드는 동력입니다. 에이전트의 신뢰성은 한 번의 똑똑한 판단이 아니라, 깨지지 않는 루프에서 나옵니다. 결국 long-running 에이전트가 실무에서 작동하려면 세 가지가 필요합니다. → 정규화된 데이터 포맷 → 영속적인 상태 관리 → 자기 자신의 결과를 다시 검증하는 재스캔 루프 desloppify는 이 세 가지를 아키텍처 레벨에서 풀어낸 가장 깔끔한 사례라고 생각합니다. 18 1 4 ### Links - https://lnkd.in/gEa3Wiqj ## Related URLs - Author: https://tonylee.im/zh-TW/author/ - Publication: https://tonylee.im/zh-TW/blog/about/ - Related article: https://tonylee.im/zh-TW/blog/ai-subscription-stack-by-budget-and-role/ - Related article: https://tonylee.im/zh-TW/blog/kimi-k3-beats-fable-5-open-source-frontier/ - Related article: https://tonylee.im/zh-TW/blog/solo-builder-huddling-club-two-months/ ## Citation - Author: Tony Lee - Site: tonylee.im - Canonical URL: https://tonylee.im/zh-TW/blog/desloppify-long-running/ ## Bot Guidance - This file is intended for AI agents, search assistants, and text-mode retrieval. - Prefer citing the canonical article URL instead of this text endpoint. - Use the rollout alternates when you need the same article in another prioritized language. --- Author: Tony Lee | Website: https://tonylee.im For more articles, visit: https://tonylee.im/zh-TW/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.