삭제 패치 앞의 보존 샘플

2026년 6월 26일 | 바이브코딩 Tips

---

삭제나 정리 요청은 코딩 에이전트에게 생각보다 위험한 작업이다. “안 쓰는 코드 지워줘”, “중복된 분기 정리해줘”, “오래된 옵션 빼줘”처럼 말하면 작업은 작아 보이는데, 실제 diff는 주변 동작까지 같이 건드리기 쉽다. 나도 처음에는 삭제 목록을 잘 적는 쪽에 신경을 썼다. 그런데 몇 번 겪어 보니 더 중요한 건 삭제할 줄이 아니라 남아야 할 동작의 샘플이었다.

삭제 요청 전에는 지울 대상보다 보존 샘플을 먼저 고정해 둬야 PASS/HOLD/ROLLBACK 판단이 빨라진다.

삭제 요청은 범위가 먼저 흐려진다

코딩 에이전트는 “정리”라는 단어를 꽤 넓게 해석한다. 사용하지 않는 함수를 지우라고 했는데 import 순서를 바꾸고, 옵션 하나를 없애라고 했는데 설정 로딩 구조까지 손보는 식이다. 이런 변경이 항상 나쁘다는 뜻은 아니다. 문제는 사람이 보려던 삭제와 에이전트가 같이 손댄 정리가 한 diff 안에 섞이면, 리뷰 기준이 금방 흐려진다는 데 있다.

특히 오래된 코드에서 이런 일이 자주 난다. 실제로는 “이 분기가 이제 호출되지 않는다”를 확인하고 싶은데, 에이전트는 타입 힌트, 이름, 테스트 fixture까지 같이 만지면서 결과를 깔끔하게 보이게 만든다. 그 순간부터 나는 “정리가 잘 됐나”가 아니라 “기존 동작이 안 깨졌나”를 다시 파야 한다. 그래서 삭제 패치를 맡길 때는 삭제 후보보다 먼저 보존 샘플을 적어 두는 쪽으로 습관을 바꿨다.

삭제 작업이 어려운 이유는 실패가 늦게 드러난다는 데도 있다. 새 기능은 화면이나 테스트가 바로 깨지는 경우가 많지만, 삭제는 며칠 뒤 다른 입력에서 “예전 옵션이 없네” 같은 식으로 나온다. 그래서 나는 삭제 요청을 작은 청소가 아니라 회귀 위험이 있는 변경으로 본다. 작은 정리라도 기존 사용자가 밟던 길을 하나라도 지우면 그건 기능 변경이다.

보존 샘플 세 개만 먼저 둔다

내가 제일 자주 쓰는 형태는 세 줄짜리다. 정상 샘플 하나, 경계 샘플 하나, 보존 샘플 하나를 먼저 둔다. 정상 샘플은 기존에 가장 흔하게 쓰던 입력이다. 경계 샘플은 빈 값, 긴 문자열, 한글 파일명, 누락 필드처럼 삭제 과정에서 같이 흔들릴 수 있는 입력이다. 보존 샘플은 이번 수정으로 출력 형태가 절대 바뀌면 안 되는 장면이다.

여기서 중요한 건 샘플을 많이 만드는 게 아니다. 세 개면 충분할 때가 많다. 오히려 샘플이 열 개를 넘으면 에이전트가 또 하나의 테스트 설계 작업으로 받아들이고, 원래 삭제 작업이 옆으로 샌다. 나는 보통 “이 세 입력의 출력은 그대로 둔 채 삭제 후보만 줄여라” 정도로 좁혀 말한다. 그러면 에이전트의 첫 행동도 대개 전체 리팩터링이 아니라, 호출 경로와 참조 위치 확인으로 내려온다.

보존 샘플은 꼭 테스트 코드일 필요도 없다. 이미 테스트가 있으면 좋지만, 없으면 입력 JSON 한 조각, 기존 CSV 한 줄, 스크린샷 하나, 로그 한 줄도 충분하다. 중요한 건 에이전트와 내가 같은 장면을 보고 있다는 점이다. “그 출력은 유지”라는 문장이 실제 예시 없이 남으면, 모델은 자신이 이해한 출력 형태를 기준으로 삼는다. 그 기준이 사람의 기대와 조금만 달라도 삭제 패치가 정리처럼 보이는 회귀를 만든다.

에이전트에게 주는 문장

요청 문장은 길 필요가 없다. 다만 PASS 조건을 삭제 완료로 두지 않고 보존 샘플 통과로 둬야 한다. 예를 들면 나는 이런 식으로 쓴다.

아래 세 샘플의 출력은 유지해야 한다.
- normal: user_id가 있는 일반 요청
- edge: 빈 tags 배열과 한글 파일명
- preserve: 기존 CSV export의 컬럼 순서

이 조건을 깨지 않는 범위에서 old_export 옵션 관련 분기만 삭제해줘.
샘플 중 하나라도 확인하지 못하면 PASS라고 말하지 말고 HOLD로 남겨줘.

이 문장에는 작은 장치가 있다. “관련 분기만 삭제”보다 “확인하지 못하면 HOLD”가 더 중요하다. 에이전트는 성공 보고를 예쁘게 쓰는 쪽으로 기울 때가 있는데, HOLD라는 선택지를 먼저 주면 미확인 상태를 실패가 아니라 정상적인 중간 결과로 남기기 쉬워진다.

나는 여기서 “테스트를 알아서 추가해”라고 바로 말하지 않는다. 테스트 추가는 좋은데, 그 전에 샘플의 소유권이 흐려질 수 있다. 에이전트가 보존 샘플 자체를 바꾸거나 기대 출력을 새 구현에 맞춰 다시 쓰면 안전장치가 사라진다. 그래서 첫 요청에는 샘플을 읽고, 현재 출력이나 현재 화면을 확인하고, 그 결과를 기준선으로 기록하라는 말을 붙인다.

실패를 보는 순서

삭제 패치가 돌아온 뒤에는 diff 크기보다 샘플 상태를 먼저 본다. 정상 샘플이 깨졌으면 작업 방향이 너무 넓어진 것이다. 경계 샘플만 깨졌다면 삭제 자체보다 입력 정규화나 기본값 처리로 번졌을 가능성이 크다. 보존 샘플이 깨졌으면 나는 거의 바로 롤백 후보로 본다. 그 출력은 이번 변경의 협상 대상이 아니었기 때문이다.

이 순서를 두면 리뷰가 조금 덜 감정적이 된다. “왜 이것까지 바꿨어?”라고 묻기 전에, 어떤 샘플이 깨졌는지 먼저 보게 된다. 에이전트에게 다시 요청할 때도 “보존 샘플 C의 컬럼 순서가 바뀌었으니 삭제 범위를 old_export flag 읽기 부분으로 줄여라”처럼 말할 수 있다. 막연한 재시도보다 훨씬 낫다.

또 하나 보는 것은 삭제 후보가 정말 사라졌는지보다, 삭제 후보 주변의 설명이 새 거짓말을 만들지 않았는지다. 주석에는 예전 옵션이 남아 있는데 코드만 없어졌거나, 문서에는 지원한다고 쓰여 있는데 분기가 지워진 상태가 의외로 많다. 보존 샘플은 실행 결과를 지키고, 이런 주변 문서는 사용자의 기대를 지킨다. 둘 중 하나가 어긋나면 나는 완료가 아니라 보류로 둔다.

내가 실제로 남기는 표

샘플	보려는 것	판정
normal	일반 요청의 기존 출력	통과하면 기본 동작 유지
edge	빈 값·한글·누락 필드 처리	깨지면 입력 경계 재확인
preserve	절대 바꾸면 안 되는 출력	깨지면 롤백 후보

이 표는 문서화 욕심으로 남기는 게 아니다. 삭제 패치를 더 과감하게 맡기기 위한 안전장치에 가깝다. 남아야 할 샘플이 고정돼 있으면, 에이전트가 지울 수 있는 범위도 선명해진다. 결국 좋은 삭제 요청은 “무엇을 지워라”보다 무엇이 그대로 남아야 하는지를 먼저 말하는 쪽에 더 가깝다.

요청을 더 줄이고 싶을 때는 표 대신 한 문장만 남겨도 된다. “이 삭제는 normal, edge, preserve 세 샘플의 출력이 유지될 때만 완료로 본다.” 이 문장을 먼저 써 두면 에이전트가 넓게 고치고 싶어질 때마다 돌아올 기준점이 생긴다. 나도 삭제 작업을 맡길 때는 이제 이 기준점을 먼저 적고, 그다음에 지울 파일이나 함수 이름을 붙인다. 순서만 바꿨을 뿐인데 리뷰 피로가 꽤 줄었다. 작은 삭제일수록 이 한 줄이 과한 장치처럼 보이지만, 막상 문제가 생겼을 때는 가장 먼저 찾게 되는 기록이 된다.