원본 줄이 빠진 패치 리뷰

시리즈: 바이브코딩 Tips #42

이전: 41편 | 목록 | 다음 없음

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

---

에이전트가 패치를 제안할 때 의외로 자주 비는 칸은 수정 전 원본이다. 바뀐 파일 목록과 “이 조건을 고쳤다”는 설명은 있는데, 실제로 어떤 줄이 어떤 줄로 바뀌었는지 한눈에 보이지 않을 때가 있다. 나도 처음에는 diff가 있으면 충분하다고 생각했다. 그런데 긴 diff 안에서 원래 줄과 바뀐 줄을 따로 잡지 않으면, 리뷰가 금방 분위기 판단이 된다. 설명이 그럴듯하면 통과시키고, 실패하면 그때야 원본을 다시 찾는 식이다.

패치 설명을 읽기 전에 원본 줄과 바뀐 줄을 나란히 두면, 변경 의도와 검증 신호가 같은 지점을 가리키는지 빨리 볼 수 있다.

diff 전체보다 원본 한 줄이 먼저 보일 때

작은 패치는 특히 헷갈린다. 조건문 하나, 기본값 하나, 컬럼 이름 하나가 바뀌었을 뿐인데 주변 문맥이 길게 붙으면 오히려 핵심 줄이 묻힌다. 에이전트는 “관련 테스트를 통과했다”고 말하고, 나는 “그래도 한 줄짜리 수정이니 괜찮겠지”라고 넘긴다. 문제는 그 한 줄이 정말 내가 말한 실패 조건을 겨냥했는지, 아니면 근처에서 가장 만만한 줄을 고른 것인지가 뒤늦게 드러난다는 점이다.

그래서 요즘은 작은 패치일수록 원본 줄과 바뀐 줄을 따로 요구한다. 전체 diff는 나중에 봐도 된다. 먼저 보고 싶은 것은 파일 위치, 수정 전 원문, 수정 후 원문, 확인 신호 네 칸이다. 이 네 칸이 있으면 “설명이 맞는가”보다 “바뀐 줄이 실패 입력과 닿아 있는가”를 먼저 볼 수 있다.

특히 에이전트가 테스트 이름을 함께 말할 때 조심한다. 테스트 이름이 있다고 해서 패치와 테스트가 같은 줄을 보고 있다는 뜻은 아니다. 테스트는 넓은 통과 신호이고, 원본 줄은 좁은 변경 신호다. 둘을 나란히 두면 “이 테스트가 왜 이 줄의 근거인지”를 물을 수 있다. 이 질문이 빠지면 통과한 테스트가 패치의 분위기만 보증하는 장식처럼 붙을 때가 있다.

내가 받는 네 칸

형식은 거창할 필요가 없다. 에이전트에게 패치 설명을 길게 쓰게 하는 것이 아니라, 리뷰할 줄을 작게 접는 정도면 된다. 특히 설정, 파서, export, prompt template처럼 작은 문자열 차이가 결과를 바꾸는 작업에서는 이 네 칸이 꽤 잘 먹힌다.

file: app/exporter.py:42
before: columns = ["id", "name"]
after:  columns = ["id", "name", "tags"]
check: test_export_columns + 샘플 CSV 헤더 확인

여기서 중요한 건 코드 조각 자체가 아니다. before와 after가 같은 위치를 가리킨다는 사실이다. 에이전트가 여러 파일을 고쳤더라도, 핵심 변경 줄 하나를 이렇게 접어 오면 사람이 볼 수 있는 단위가 생긴다. 반대로 이 네 칸을 못 채우는 패치는 아직 적용보다 설명 정리가 먼저일 가능성이 높다.

나는 이 형식을 모든 변경에 강제하지는 않는다. 파일을 새로 만드는 작업이나 큰 구조 변경은 before가 비어 있을 수 있다. 그럴 때는 “새로 생긴 책임”, “연결된 호출부”, “처음 확인할 샘플”을 대신 적게 한다. 중요한 건 원본 줄이라는 이름 자체가 아니라, 변경 전후를 비교할 기준이 대화 안에 남아 있느냐다. 기준이 없으면 리뷰는 결국 에이전트의 설명을 다시 믿는 쪽으로 기울어진다.

설명과 변경 줄을 분리하는 이유

패치 설명은 자연어라서 쉽게 넓어진다. “누락된 필드를 보완했다”, “예외 처리를 강화했다”, “경계 조건을 반영했다” 같은 문장은 틀리지 않을 수 있다. 하지만 리뷰에서는 그 말이 실제 줄과 붙어 있어야 한다. 누락 필드를 보완했다면 어떤 배열, 어떤 schema, 어떤 serializer 줄이 바뀌었는지 보여야 한다. 예외 처리를 강화했다면 어떤 exception을 잡았고, 기존 흐름을 삼키지 않는지 확인 신호가 있어야 한다.

나는 이 칸을 일종의 패치 영수증처럼 본다. 계산서 전체가 아니라 핵심 품목 한 줄을 보는 것이다. 원본 줄이 빠지면 되돌릴 때도 느려진다. “어디를 되돌리지?”가 아니라 “before 줄로 돌아가면 되는가, 아니면 주변 상태도 같이 바뀌었는가”를 다시 추적해야 한다. 원본 줄이 남아 있으면 HOLD나 ROLLBACK 판단이 훨씬 짧아진다.

리뷰를 늦추는 것이 아니라 좁히는 장치

이 방식이 매번 필요한 것은 아니다. 큰 리팩터링이나 파일 구조 변경에서는 한 줄로 접는 것이 오히려 거짓 요약이 될 수 있다. 그때는 별도의 변경 반경, 보존 샘플, 검증 표가 더 낫다. 하지만 작은 수정인데도 에이전트 설명이 길어지는 경우라면, 나는 먼저 원본 줄 네 칸을 요구한다. 설명을 더 달라는 뜻이 아니라, 검토할 표면을 줄여 달라는 뜻이다.

이 네 칸은 리뷰 속도를 늦추지 않는다. 오히려 내가 확인할 질문을 줄인다. 파일이 맞는가, 원본 줄이 실제로 있었는가, 바뀐 줄이 요구사항을 과하게 넓히지 않았는가, 확인 신호가 그 줄을 건드렸는가. 이 네 질문에 답이 있으면 패치를 받아도 되고, 하나라도 비면 HOLD로 두면 된다. 애매한 패치를 붙잡고 오래 토론하는 것보다 훨씬 덜 피곤하다.

칸	확인할 것	멈출 신호
file	실제 수정 위치와 허용 반경	관계없는 파일이 함께 바뀜
before	마지막으로 믿는 원본 줄	원본 줄을 설명하지 못함
after	실제 바뀐 줄과 의도 연결	의도는 맞지만 줄이 다른 문제를 건드림
check	그 줄을 확인한 테스트나 샘플	검증이 빌드 성공 하나뿐임

요청 문장 하나

실제로는 이렇게 말하면 충분했다.

패치를 적용하기 전에 핵심 변경 1~2개만 file / before / after / check 형식으로 먼저 보여줘.
원본 줄을 못 특정하는 변경은 적용하지 말고 HOLD로 남겨줘.

마지막에 내가 스스로에게 묻는 질문도 단순하다. “지금 이 패치를 내일 다시 봐도 어디가 바뀌었는지 바로 찾을 수 있는가?” 이 질문에 대답하지 못하면, 당장 통과한 패치라도 기록 품질은 낮은 편이다. 에이전트가 빠르게 고쳐 준 속도보다, 다음에 같은 줄을 다시 열 때 드는 비용이 더 중요할 때가 있다. 원본 줄은 그 비용을 줄이는 작은 표시다. 그래서 나는 빠른 수정일수록 변경 전 한 줄을 더 집요하게 본다. 답이 맞아 보여도, 줄의 출처가 비어 있으면 나는 아직 리뷰가 끝난 것으로 보지 않는다. 짧은 패치일수록 이 확인이 훨씬 더 값지다. 리뷰 시간이 줄어든다.

이 문장이 마음에 드는 이유는 에이전트를 더 묶어 두기 때문이 아니다. 내가 봐야 할 대상을 줄여 주기 때문이다. 바이브코딩에서 위험한 순간은 패치가 많을 때만이 아니다. 작은 변경이 너무 자연스러워 보여서, 원본을 보지 않고 넘어갈 때도 위험하다. 원본 줄 하나를 먼저 받으면 “이 패치가 맞는 방향인가”를 설명이 아니라 증거로 볼 수 있다. 그리고 그 증거가 없으면, 그 자체로 아직 패치를 받을 때가 아니라는 신호가 된다.

시리즈: 바이브코딩 Tips #42

이전: 41편 | 목록 | 다음 없음