바이브코딩 Tips 2: 에이전트가 급해질수록 read:edit 비율 먼저 보기

2026년 4월 8일 | 바이브코딩 Tips

---

바이브코딩이 급해질수록 허술해지는 이유를 설명하는 단어로 read:edit 비율만큼 직관적인 것도 드물다. 이건 에이전트가 파일을 몇 번 읽고 나서 한 번 수정하는지 보는 감각이다. GitHub의 Claude Code 이슈 42796에서는 23만 회가 넘는 도구 호출 로그를 분석하면서, 좋은 구간의 read:edit 비율이 6.6이었는데 나빠진 구간은 2.0까지 떨어졌다고 정리했다. 숫자 자체보다 중요한 건 메시지다. 에이전트가 읽는 시간을 건너뛰고 바로 고치기로 들어가면, 결과도 같이 흔들린다는 뜻이다.

이 얘기를 보고 내가 바로 무릎 친 이유는, 요즘 코딩 에이전트가 이상하게 급해 보일 때 체감하는 증상이 거의 똑같기 때문이다. 관련 파일을 덜 읽고, 테스트는 늦게 보고, “가장 단순한 fix”를 빨리 고른다. 그 순간부터 코드는 맞는 듯 보이는데 주변 맥락을 자꾸 놓친다. 주석 블록 사이에 선언이 끼어들고, 이미 있는 헬퍼를 못 보고 비슷한 함수를 또 만들고, 끝났다고 말했는데 막상 돌려보면 경계 케이스가 비어 있다. 나는 예전엔 이걸 그냥 모델 컨디션 문제로만 넘겼는데, 오늘은 조금 더 운영적인 언어로 정리됐다. 수정 전에 읽는 예산이 무너진 상태였던 거다.

Figure 1: 오늘 크게 회자된 Claude Code 이슈 42796. 긴 세션에서 품질이 왜 무너지는지를 로그 기반 지표로 설명한 글이었다.

이 이슈가 좋았던 건 감정 섞인 불만글에서 끝나지 않고, read:edit, edits without prior read, write vs edit 같은 지표로 증상을 설명했다는 점이다. 특히 본문에는 “최근 읽지 않은 파일에 대한 수정” 비율이 좋은 구간 6.2%에서 나빠진 구간 33.7%까지 올라갔다고 나온다. 세 번 중 한 번꼴로 파일을 제대로 읽지 않고 건드린 셈이다. 바이브코딩에서 이 수치가 무서운 이유는, 사람은 에이전트가 뭘 빠뜨렸는지 결과가 망가진 뒤에야 알아차리는 경우가 많기 때문이다. 눈앞의 diff는 멀쩡해 보여도, 주변 규약과 호출 경로를 안 읽은 수정은 나중에 더 크게 틀어진다.

게다가 이 글은 그냥 조용한 버그 리포트도 아니었다. GitHub 반응 수가 1천 개를 넘었고, 같은 이슈를 가리키는 Hacker News 토론도 1천 포인트를 넘게 받았다. 나는 이런 숫자보다도, 많은 사람이 거의 같은 증상을 같은 언어로 말하고 있었다는 점이 더 중요하게 보였다. “모델이 예전보다 급하다”, “읽지 않고 바로 고친다”, “틀린데도 끝났다고 말한다” 같은 체감이 꽤 넓게 공유되고 있었다는 뜻이기 때문이다. 그래서 이 팁은 특정 도구 하나의 팬심 이야기가 아니라, 요즘 에이전트 워크플로 전반에서 바로 써먹을 수 있는 운영 팁으로 읽혔다.

1. 오늘 내가 건진 핵심: edit보다 research를 먼저 보이게 만들기

그래서 나는 긴 작업일수록 프롬프트를 더 예쁘게 다듬는 쪽보다, 수정 전에 읽은 흔적을 남기게 만드는 쪽이 훨씬 낫다고 본다. 핵심은 간단하다. edit를 허용하기 전에 research를 눈에 보이게 강제하는 것이다. 말로만 “충분히 살펴봐”라고 하면 소용없고, 읽은 파일 이름, 검색한 심볼, 확인한 테스트를 먼저 제출하게 해야 한다. 그래야 내가 중간에 끊어도 어디서부터 잘못됐는지 바로 보인다.

Figure 2: 좋은 루프는 수정 전에 읽기와 검색을 먼저 고정하고, 그 다음에만 편집을 허용한다.

나는 이걸 거창하게 운영하지 않는다. 그냥 수정 전에 읽은 증거를 제출하라는 규칙 하나를 먼저 둔다. 관련 파일을 최소 세 개는 읽었는지, 호출 경로를 한 번이라도 검색했는지, 테스트나 로그를 한 번이라도 확인했는지, 그리고 왜 이 수정이 필요한지 세 줄로 설명할 수 있는지. 이 네 가지만 통과하면 그 다음 edit는 꽤 안정적이다. 반대로 이 네 가지가 없으면 에이전트가 영리해 보여도 자주 헛손질한다.

2. 내가 바로 붙이는 미니 계약

내가 요즘 자주 쓰는 건 아래 같은 짧은 계약이다. 중요한 건 장황한 프롬프트를 쓰는 게 아니라, 수정 전에 증거를 먼저 내라고 못 박는 것이다.

1) 수정 전에 관련 파일 최소 3개와 테스트 1개를 먼저 읽어라.
2) rg/grep 결과로 사용처를 확인하고, 바꾸려는 이유를 3줄로 요약해라.
3) 그 다음에만 수정해라.
4) 수정 후에는 diff 요약과 실패/성공 테스트 결과를 같이 보여줘라.

이 계약이 좋은 이유는 프롬프트의 멋이 아니라 순서가 고정된다는 데 있다. 읽기 → 검색 → 요약 → 수정 → 검증이 보이면, 사람이 중간에 개입하기도 쉽고 에이전트가 급해졌는지도 바로 감지된다. 특히 “바로 해봤다”, “간단히 고쳤다”, “가장 단순한 방법으로 처리했다” 같은 말이 빨리 나오면 나는 그 턴을 한 번 의심한다. 정말 단순해서 좋은 해결책일 수도 있지만, 꽤 자주 “지금 당장 덜 생각하고 끝내고 싶다”의 다른 말이기도 하다.

2.5. 수정 직전에 내가 보는 30초 경고 신호

실제로는 거창한 대시보드가 없어도 된다. 나는 수정 직전에 세 가지만 본다. 첫째, 이 파일 말고 같이 읽은 파일 이름이 보이는가. 둘째, 실패를 재현한 명령이나 로그가 있는가. 셋째, 왜 이 위치를 고치는지 한 문장으로 설명할 수 있는가. 셋 중 하나라도 비어 있으면 그 턴은 대개 위험하다. 에이전트가 똑똑해 보일수록 더 그렇다. 말은 그럴듯한데 근거가 비어 있는 상태로 바로 edit에 들어가기 쉽기 때문이다.

• 관련 파일 이름이 안 보이면 아직 맥락을 덜 읽은 상태
• 재현 명령이 없으면 수정이 맞았는지 확인할 기준도 없음
• 이 위치를 왜 고치는지 설명이 흐리면 대안 비교도 안 된 상태

이건 에이전트를 의심하자는 얘기라기보다, 수정의 근거를 밖으로 꺼내 보자는 얘기에 가깝다. 바이브코딩이 길어질수록 사람은 결과만 보고 안심하기 쉽고, 에이전트는 중간 reasoning을 생략한 채 맞는 톤으로 답하기 쉽다. 그래서 나는 구현을 더 시키기 전에 근거가 먼저 보이는지부터 본다. 이 순서 하나만으로도 삽질이 꽤 줄어든다.

3. 쉘에서 먼저 좁혀 두면 더 덜 흔들린다

에이전트가 아무 파일이나 열어보며 헤매는 시간을 줄이려면, 사람 쪽에서도 수사 범위를 먼저 닫아두는 편이 좋다. 예를 들어 retry 버그를 보고 있다면 나는 대충 이런 식으로 시작한다.

rg "RetryPolicy|retry_policy|backoff" app tests
pytest -k retry_policy -q
git diff --stat

이 세 줄만 있어도 에이전트는 최소한 어디를 읽어야 하는지, 어떤 테스트를 기준으로 삼아야 하는지, 지금 변경량이 과한지 감을 잡는다. 바이브코딩이 잘 되는 날은 모델이 특별히 천재라서가 아니라, 사람이 읽어야 할 근거의 테두리를 먼저 그어 둔 날인 경우가 많다. 나도 최근엔 “큰 요구사항을 한 번에 잘 써야지”보다 “읽기 범위를 먼저 닫아 둬야지” 쪽이 결과 편차를 더 줄여 준다고 느낀다.

4. 체크포인트보다 앞단에서 품질을 지키는 법

체크포인트는 망가진 뒤 돌아오는 장치다. read:edit 감각은 그보다 앞에서, 아예 덜 망가지게 만드는 장치다. 둘 다 필요하지만 순서는 다르다. 읽기 비율이 무너진 상태에서 아무리 체크포인트를 잘 남겨도 매번 되돌아갈 뿐, 앞으로 가는 속도는 잘 안 붙는다. 반대로 읽기와 검색이 먼저 살아 있으면 체크포인트 간격도 자연스럽게 길어진다. 오늘 내 결론은 단순하다. 바이브코딩에서 에이전트가 급해 보일수록, 더 똑똑한 프롬프트를 찾기 전에 얼마나 읽고 고치고 있는지부터 보자는 것. 그 숫자 감각이 생기면, 모델이 흔들리는 날에도 내 작업 리듬까지 같이 무너지지는 않는다.

출처

• GitHub Issue 42796 — [MODEL] Claude Code is unusable for complex engineering tasks with the Feb updates
• Hacker News discussion — Issue: Claude Code is unusable for complex engineering tasks with Feb updates
• Hacker News discussion — Claude Code Down