<!doctype html>
2026년 6월 25일 | 바이브코딩 Tips
패치 제안이 길어질수록 나는 설명을 더 많이 받는 쪽보다, 작은 표 하나를 옆에 붙이는 쪽이 낫다고 느낀다. 에이전트가 왜 바꿨는지 말하는 문장은 대체로 그럴듯하다. 문제는 그 설명이 실제 확인 신호와 붙어 있지 않을 때다. 파일은 바뀌었고, 실패 메시지는 사라졌고, 마지막 답변에는 “확인했습니다”가 들어가는데, 무엇을 확인했는지는 흐릿하게 남는다.
그래서 요즘 코딩 에이전트에게 수정안을 받을 때는 패치 설명, 검증 신호, 다음 행동을 한 줄 표로 같이 달라고 한다. 거창한 양식은 아니다. 오히려 칸이 많아지면 또 문서 작업이 된다. 내가 원하는 건 패치를 읽는 사람이 “이 변경을 믿어도 되는가”를 30초 안에 판단할 수 있는 최소 단서다.
설명과 검증은 다른 물건이다
에이전트가 “타임아웃 처리를 분리했습니다”라고 말하면, 그 문장은 변경 의도를 설명한다. 하지만 그 말만으로는 연결 시간 초과와 응답 지연이 실제로 다르게 잡히는지 알 수 없다. “테스트를 통과했습니다”도 마찬가지다. 어떤 테스트인지, 실패하던 입력이 포함됐는지, 수동 확인이 빠졌는지에 따라 의미가 완전히 달라진다.
내가 표를 붙이는 이유는 여기 있다. 설명은 패치의 방향을 알려 주고, 검증 신호는 그 방향이 실제로 닿았는지를 알려 준다. 둘을 한 문단에 섞으면 대충 읽고 넘어가기 쉽다. 반대로 칸을 나누면 설명은 있는데 신호가 없는 패치, 신호는 있는데 다음 행동이 없는 패치가 바로 보인다.
내가 자주 쓰는 세 칸
첫 칸은 “무엇을 왜 바꿨는가”다. 파일명만 쓰지 않고 사용자 증상이나 실패 조건과 연결한다. 예를 들어 “요청 재시도 로직 수정”보다 “두 번째 호출에서만 나던 timeout을 connect/read timeout 분리로 좁힘”이 낫다. 이 칸이 흐리면 패치가 실제 문제를 겨냥했는지 판단하기 어렵다.
둘째 칸은 “무엇으로 확인했는가”다. 테스트 이름, 재현 입력, 로그 한 줄, 화면 확인처럼 사람이 다시 볼 수 있는 신호를 적는다. 여기에는 성공 신호뿐 아니라 못 본 영역도 같이 둔다. 확인하지 못한 것을 같이 쓰는 것이 생각보다 중요하다. 그래야 다음 사람이 같은 빈칸을 성공으로 착각하지 않는다.
셋째 칸은 “다음 행동”이다. PASS면 병합, HOLD면 추가 확인, FAIL이면 되돌림처럼 사람이 바로 선택할 수 있는 말로 적는다. 에이전트 답변이 길어지는 이유 중 하나는 마지막 문장이 판단을 대신하려 하기 때문이다. 나는 판단을 맡기기보다, 판단에 필요한 버튼 세 개를 남기게 하는 편이 덜 불안하다.
표가 막아 주는 실패
이 방식이 특히 유용한 순간은 수정이 작아 보일 때다. 한 줄짜리 조건문, import 위치 변경, 설정 기본값 수정 같은 것들은 리뷰에서 쉽게 지나간다. 하지만 작은 변경일수록 에이전트는 “간단히 고쳤다”는 말로 마무리하려고 한다. 그때 표가 있으면 작은 변경도 어떤 실패 입력을 겨냥했는지 다시 보게 된다.
또 하나는 재시도 루프다. 같은 문제를 두세 번 밀다 보면 답변은 점점 자신만만해지는데, 실제 근거는 비슷한 로그를 반복해서 읽은 것일 때가 있다. 표의 검증 칸을 보면 같은 테스트만 반복했는지, 새로운 실패 조건을 추가했는지가 드러난다. 나는 이 칸이 비어 있으면 패치를 바로 적용하지 않고 HOLD로 둔다.
에이전트에게 주는 요청 문장
실제로는 길게 말하지 않는다. “수정안과 함께 3열 표를 붙여 달라. 열은 변경 의도, 확인 신호, 다음 행동이다. 확인하지 못한 영역은 검증 신호 칸에 같이 적어 달라.” 정도면 충분하다. 코드베이스가 크거나 배포가 얽힌 작업이라면 여기에 “추측한 항목은 추측이라고 표시해 달라”만 더한다.
나는 이 요청을 처음부터 붙일 때도 있고, 에이전트가 첫 수정안을 낸 뒤에 붙일 때도 있다. 처음부터 붙이면 답변이 조금 더 느리지만, 변경 범위가 넓어질 가능성이 있는 작업에서는 그 편이 낫다. 반대로 오타 수정이나 작은 설정 변경처럼 범위가 아주 좁으면, 첫 답변을 본 뒤 표만 추가로 요구해도 충분하다. 핵심은 모든 작업에 같은 양식을 강제하는 것이 아니라, 사람이 판단해야 할 지점에서만 표를 꺼내는 것이다.
표를 요구한다고 해서 에이전트가 늘 정확해지는 것은 아니다. 그래도 답변의 허세는 꽤 줄어든다. 근거 없는 확신은 칸을 채우는 순간 티가 난다. 검증 신호가 “빌드 성공” 하나뿐인데 변경 의도는 사용자 플로우 세 개를 건드렸다면, 아직 끝난 작업이 아니다. 이 불균형을 사람이 빨리 보는 게 핵심이다.
한 줄 예시로 보는 차이
예를 들어 에이전트가 “업로드 실패를 고쳤습니다”라고만 말하면 나는 다시 질문하게 된다. 어떤 업로드인지, 실패 입력이 무엇인지, 서버 응답과 프런트 메시지 중 어디를 바꿨는지 알 수 없기 때문이다. 같은 내용을 표로 받으면 훨씬 빨리 읽힌다. 변경 의도는 “한글 파일명에서 깨지던 multipart filename 처리”, 확인 신호는 “공백·한글·괄호가 들어간 파일명 3개로 재현 테스트”, 다음 행동은 “배포 전 실제 브라우저 업로드 1회 HOLD”처럼 남긴다.
이렇게 쓰면 표가 완벽한 테스트를 대신하지는 않는다. 대신 대화의 다음 질문이 뾰족해진다. “테스트 더 해 봐”가 아니라 “괄호가 있는 한글 파일명은 봤는데, 100MB 이상 파일은 아직 안 봤으니 그쪽만 확인하자”로 좁아진다. 바이브코딩에서 내가 원하는 것은 멋진 답변보다 이런 좁아진 다음 질문이다.
내가 보는 최종 기준
표가 있다고 무조건 좋은 패치는 아니다. 나는 세 가지를 본다. 첫째, 변경 의도가 처음 문제 문장과 직접 이어지는가. 둘째, 검증 신호가 그 의도를 실제로 건드리는가. 셋째, 다음 행동이 너무 낙관적으로 적혀 있지 않은가. 이 셋 중 하나라도 비면, 에이전트에게 코드를 더 쓰게 하기보다 먼저 빈칸을 채우게 한다.
바이브코딩에서 속도는 중요하지만, 빠른 수정보다 더 중요한 건 다음 판단을 망치지 않는 것이다. 패치 제안 옆의 검증 표는 일을 느리게 만드는 문서가 아니라, “어디까지 믿어도 되는지”를 작게 보이게 하는 장치에 가깝다. 나는 이 표가 붙은 패치가 붙지 않은 패치보다 덜 멋있어 보여도, 실제로는 훨씬 다루기 편했다.
특히 여러 파일이 한꺼번에 바뀌는 작업에서는 이 차이가 더 크다. 표가 없으면 나는 diff를 먼저 열고, 로그를 다시 찾고, 대화 위쪽으로 올라가 원래 실패 조건을 복원한다. 표가 있으면 반대로 검증 신호부터 보고 diff를 읽는다. 읽는 순서가 바뀌면 피로도도 바뀐다. 작은 표 하나가 리뷰를 대신하지는 않지만, 리뷰를 시작할 위치는 꽤 정확히 찍어 준다. 다음 확인을 한 문장으로 줄여 주는 셈이고, 그 한 문장이 다음 세션의 입구가 된다.
'[개발 깨알 상식_Tips] > [바이브코딩 Tips]' 카테고리의 다른 글
| 종료 코드가 빠진 에이전트 재시도 (0) | 2026.06.27 |
|---|---|
| 삭제 패치 앞의 보존 샘플 (0) | 2026.06.26 |
| 완료 보고 옆의 결과 파일 (0) | 2026.06.24 |
| 실패 로그 옆의 재현 명령 (0) | 2026.06.23 |
| 컨텍스트 압축 직전의 기준선 세 줄 (0) | 2026.06.22 |