미확인 영역이 보이는 완료 보고

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

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

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

---

테스트가 통과했다는 말은 내가 실제로 확인한 화면과 입력을 전부 설명해 주지 않는다. 코딩 에이전트가 “완료했습니다”라고 답하고 초록색 로그를 붙여 와도, 그 작업이 어디까지 믿을 수 있는지는 따로 읽어야 한다. 나는 이걸 놓쳐서 몇 번 같은 실수를 했다. 기능은 고쳐졌는데 모바일 폭은 안 봤고, 파서는 통과했는데 빈 문자열 입력은 빠졌고, 버튼은 눌렸는데 권한 없는 계정 흐름은 그대로 남아 있었다. 문제는 에이전트의 성실함보다 완료 보고 안에서 확인한 것과 못 본 것이 섞이는 구조에 가까웠다.

그래서 요즘은 에이전트에게 마지막 답변을 받을 때 “무엇을 바꿨는가”와 함께 “무엇을 아직 못 봤는가”를 먼저 찾는다. 말이 길어질 필요는 없다. 바뀐 것, 확인한 것, 아직 못 본 것. 이 세 줄만 분리되어 있어도 완료 보고는 훨씬 읽기 쉬워진다. 특히 바이브코딩처럼 작은 수정이 빠르게 이어지는 흐름에서는 이 작은 분리가 다음 요청의 크기를 결정한다.

완료 보고를 세 표면으로 나누면, 초록 로그 뒤에 남은 미확인 영역이 바로 보인다.

초록 로그가 말하지 않는 부분

테스트 통과는 좋은 신호다. 다만 테스트 통과가 곧 사용자 흐름 전체의 확인은 아니다. 예를 들어 저장 버튼 오류를 고쳤다고 해도, 실제로 본 것은 데스크톱 Chrome의 로그인된 계정 하나일 수 있다. 모바일 Safari, 권한 없는 계정, 느린 네트워크, 긴 제목 입력은 아직 남아 있을 수 있다. 그런데 완료 보고가 “테스트 통과, 저장 버튼 수정 완료”에서 끝나면 이 남은 영역이 사라진 것처럼 보인다.

나는 이 지점에서 완료 보고를 너무 관대하게 읽었던 것 같다. 에이전트가 파일명과 테스트명을 성실하게 적어 주면 안심했고, 아직 보지 않은 표면은 나중에 생각났다. 하지만 나중에 생각난 미확인 영역은 다음 작업의 시작점으로 남지 않고 재작업의 이유가 된다. 작은 수정일수록 마지막 보고에서 확인 범위의 바깥이 보여야 한다.

내가 요구하는 세 줄

요청문 끝에 붙이는 문장은 길지 않다. 나는 보통 아래처럼 세 줄을 요구한다.

바뀐 것: 사용자 동작 기준으로 한 줄
확인한 것: 실제로 실행하거나 눈으로 본 검증
아직 못 본 것: 남은 입력, 화면, 환경, 권한 흐름

여기서 중요한 건 파일명보다 사용자 동작을 앞에 두는 것이다. “src/form.ts 수정”보다 “저장 버튼 클릭 뒤 toast가 한 번만 뜨도록 변경”이 낫다. 그래야 내가 완료 보고를 읽을 때 코드 위치가 아니라 사용자 흐름부터 확인할 수 있다. 파일명은 그다음에 보면 된다.

확인한 것 칸에는 실제 행동만 들어가야 한다. “확인 예정”, “아마 영향 없음”, “로직상 가능” 같은 말은 검증이 아니다. 반대로 “pytest 세 개 통과”, “375px 화면에서 버튼 줄바꿈 확인”, “빈 값 입력으로 수동 재현”처럼 적혀 있으면 내가 바로 믿을 범위를 잡을 수 있다. 이 칸이 비어 있으면 아직 완료가 아니라 관찰 대기 상태에 가깝다.

미확인은 실패가 아니라 상태다

처음에는 “아직 못 본 것”을 적게 하면 에이전트가 방어적으로 답할까 봐 조금 꺼려졌다. 그런데 실제로는 반대였다. 미확인 영역을 적게 하면 실패 인정처럼 보이기보다, 다음 사람이 바로 이어 볼 수 있는 상태를 남기는 일이 된다. “모바일 폭 미확인”은 부끄러운 문장보다 다음 확인 버튼에 가깝다. “권한 없는 계정 미확인”도 같은 역할을 한다.

이 구분이 없으면 완료와 미완료 사이가 회색으로 번진다. 에이전트는 열심히 고쳤고, 테스트도 일부 통과했는데, 사람은 여전히 찜찜하다. 이때 찜찜함을 감정으로만 남기면 다음 요청이 커진다. “전체적으로 다시 봐줘” 같은 넓은 말이 나오기 쉽다. 반대로 미확인 영역이 한 줄로 남아 있으면 다음 입력은 작아진다. “모바일 375px에서 저장 버튼만 다시 확인해 줘”처럼 바로 줄일 수 있다.

다음 요청의 크기가 줄어드는 방식

완료 보고가 세 줄로 나뉘면 후속 요청도 세 가지 중 하나로 떨어진다. 바뀐 것이 요구 범위 밖이면 diff를 되돌리거나 분리한다. 확인한 것이 부족하면 검증만 다시 맡긴다. 아직 못 본 것이 위험하면 그 표면만 새 작업으로 연다. 이러면 “다시 고쳐줘”가 아니라 “검증만 추가해 줘”, “이 파일은 되돌리고 나머지만 유지해 줘”, “빈 입력 하나만 재현해 줘” 같은 작은 문장이 나온다.

특히 여러 에이전트나 여러 세션을 오갈 때 이 차이가 크다. 앞 세션의 대화 전체를 다시 읽지 않아도, 마지막 세 줄만 보면 어디까지 믿을지 알 수 있다. 내가 다음 날 작업을 다시 열 때도 마찬가지다. 완료 보고에 미확인 영역이 남아 있으면, 나는 그 작업을 처음부터 다시 해석하지 않고 남은 표면만 이어서 본다. handoff는 긴 요약보다 남은 확인면이 선명할 때 더 잘 된다.

못 돌린 검증도 이름을 붙인다

미확인 영역을 적을 때 조심할 점은 “못 했음”으로만 남기지 않는 것이다. 그렇게 적으면 다음 사람이 다시 무엇을 봐야 하는지 알기 어렵다. 나는 가능하면 못 본 이유와 다시 볼 표면을 같이 붙인다. 예를 들면 “브라우저 없음”보다 “Safari 미확인, 날짜 입력 위젯 확인 필요”가 낫고, “로컬 실행 불가”보다 “DB seed 없음, 주문 취소 fixture에서 재현 필요”가 낫다. 같은 미확인이라도 이름이 붙으면 다음 행동이 훨씬 작아진다.

에이전트에게도 이 방식이 편하다. 단순히 “검증 못 했습니다”라고 쓰면 다음 턴에서 변명이 길어진다. 반대로 “결제 실패 케이스는 테스트 데이터가 없어 미확인, 확인하려면 실패 응답 fixture가 필요”라고 쓰면 사람은 바로 판단할 수 있다. 지금 데이터를 만들지, 해당 검증을 다음 작업으로 미룰지, 아니면 위험을 받아들이고 배포할지 고르면 된다. 미확인은 닫힌 결론이 아니라 다음 판단의 주소가 되어야 한다.

나는 특히 외부 API, 권한 흐름, 브라우저 차이, 시간대 처리에서 이 줄을 자주 쓴다. 이 네 가지는 테스트가 초록색이어도 실제 환경에서 다르게 움직일 수 있다. 그래서 완료 보고에 “외부 API 실패 응답 미확인”, “권한 없는 계정 미확인”, “모바일 Safari 미확인”, “UTC 자정 경계 미확인” 같은 문장이 보이면 오히려 안심한다. 빠진 것을 숨기지 않았다는 뜻이고, 다음 확인이 무엇인지 이미 정해졌다는 뜻이기 때문이다.

짧아야 계속 쓴다

이 방식은 거창한 리뷰 양식이 되면 금방 안 쓰게 된다. 그래서 나는 마지막 보고를 세 줄 이상으로 키우지 않으려고 한다. 바뀐 것 한 줄, 확인한 것 한 줄, 아직 못 본 것 한 줄. 필요하면 파일 목록과 명령 로그는 그 아래에 붙이면 된다. 핵심은 에이전트에게 더 긴 보고서를 요구하는 데 있지 않다. 완료라는 단어 안에 숨어 있던 확인 범위를 밖으로 빼는 데 있다.

바이브코딩의 속도는 마지막 답변을 빨리 믿을 때만 나오지 않는다. 어디까지 믿고, 어디부터 다시 봐야 하는지 빠르게 나눌 때 나온다. 초록 로그는 반갑지만, 초록 로그가 모든 표면을 대신하지는 않는다. 완료 보고에 미확인 영역이 같이 보이면 다음 수정은 더 작아지고, 나도 덜 불안하게 merge 버튼 근처까지 갈 수 있다.

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

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