AI 코딩 에이전트, 고친 버그를 다시 재현… 해결책 제시

Source: Dev.to

지난 몇 번의 릴리스에서 selvedge는 쓰기 전용 기능에 불과했습니다. AI 에이전트가 컬럼을 수정하고 log_change를 호출하면, 그 이유가 코드 옆에 있는 .selvedge/ 디렉터리 아래의 작은 SQLite 파일에 기록됩니다. 유용하지만 일방향입니다. 에이전트는 스토어에 기록하고는 다시는 보지 않죠.

v0.3.7은 이 흐름이 뒤바뀌는 릴리스입니다. prior_attempts라는 새로운 MCP 도구가 추가됐으며, 이 도구의 핵심 목적은 변경을 수행하기 전에 에이전트가 호출하도록 하는 것입니다—변경 후가 아니라요. users.email을 수정하기 전에, 에이전트는 selvedge에 “마지막으로 누가 이 컬럼을 건드렸을 때 무슨 일이 있었는가? 누가 언제 어떤 시도를 했고, 왜 되돌려졌는가?”를 묻습니다.

이 릴리스는 제품 정체성을 정의하는 만큼, 왜 이렇게 설계했는지 차근차근 설명드리겠습니다.

v0.3.6까지의 selvedge 모습

에이전트가 users.email을 리팩터링하고, 작업이 끝날 무렵 log_change에 이유 문자열을 넘깁니다.

“청구 팀의 요청에 따라 플러스 주소를 거부하도록 이메일 검증 로직을 강화했습니다.”

그 이유가 스토어에 저장됩니다. 이후 사람이 CLI에서 selvedge blame users.email을 실행하면 그 기록을 읽어볼 수 있죠.

이것은 모든 코드 귀속 도구가 갖는 전형적인 흐름입니다. git blame, AgentDiff, Origin 등 모두 캡처‑읽기 구조입니다. 캡처는 특정 시점에 한 번 일어나고, 읽기는 다른 주체(보통 사람)가 별도 시점에 비동기적으로 수행합니다—대개 몇 주 뒤, 이미 뭔가가 깨진 뒤에요.

인간이 만든 코드베이스에서는 괜찮습니다. 사람들은 세션 사이에 컨텍스트를 기억하고, “아, 3월에 그걸 시도했었지”라고 떠올립니다. 감사 로그는 기억을 보조하는 백업일 뿐, 기억 자체는 아닙니다.

prior_attempts는 묻는 원시(asking primitive) 역할을 합니다.

v0.3.7에서 추가된 질문 도구

prior_attempts는 pull‑model입니다—에이전트가 호출하고, selvedge가 푸시하지 않죠. 설명이나 entity_path를 넘겨주면, 같은 경로(또는 같은 형태)에서 이전에 일어난 변경 이벤트들을 반환합니다. 반환 내용에는 이유(reasoning), 변경 종류(change_type), 추론된 결과(outcome)가 포함됩니다.

prior_attempts(entity_path="users.email")

users.email에 대한 두 번의 시도

[2026-03-14]  rename -> users.email_address   (2026-03-17