PASS 로그 앞의 작업 위치 확인

 

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

---

PASS 로그는 현재 경로와 기준 커밋, 검증 입력이 맞을 때만 다음 행동의 근거가 된다.

PASS보다 먼저 작업 위치가 맞아야 한다

코딩 에이전트가 “테스트 통과했습니다”라고 말했는데도 이상하게 불안할 때가 있다. 로그 자체는 초록색인데, 내가 맡긴 저장소가 아니라 옆 폴더에서 돈 결과일 수 있고, 같은 저장소라도 다른 브랜치나 오래된 워크트리에서 나온 PASS일 수 있다. 처음에는 이런 의심이 너무 사소해 보였다. 그런데 monorepo, 예제 앱, 중첩 프로젝트가 섞이면 이 사소한 위치 차이가 꽤 자주 문제를 만든다.

나는 그래서 PASS 로그를 바로 완료 신호로 보지 않고, 그 앞에 작업 위치를 붙여 읽는다. 여기서 위치는 단순한 폴더명이 아니다. 에이전트가 실제로 서 있는 경로, 기준 브랜치, 현재 커밋, 그리고 검증이 읽은 입력 파일까지 포함한다. 이 네 가지가 내가 보고 있는 화면과 맞아야 PASS가 증거가 된다. 하나라도 어긋나면 그 로그는 성과가 아니라 참고 자료에 가깝다.

특히 여러 에이전트를 번갈아 쓰는 날에는 이 차이가 더 잘 숨는다. 한 세션은 루트에서 의존성을 설치하고, 다른 세션은 하위 패키지에서 테스트를 돌리고, 나는 마지막 PASS 문장만 본다. 겉으로는 같은 작업처럼 이어져도 실제 바닥은 다를 수 있다. 그래서 완료 보고를 읽을 때는 성공 여부보다 먼저 “이 로그가 내가 맡긴 바닥 위에서 난 것인가”를 확인한다.

세 줄 위치 영수증만 받아도 흔들림이 줄어든다

긴 설명을 매번 요구할 필요는 없다. 내가 자주 쓰는 방식은 수정 직전이나 검증 직후에 세 줄만 받는 것이다. 첫 줄은 현재 경로, 둘째 줄은 브랜치와 짧은 커밋, 셋째 줄은 방금 돌린 검증 입력이다. 이 세 줄이 붙어 있으면 “PASS”라는 말이 어느 작업면에서 나온 것인지 바로 보인다.

중요한 건 형식을 예쁘게 만드는 게 아니다. 에이전트가 자기 관찰을 사람의 작업 기준선에 맞춰 다시 고정하게 만드는 것이다. 예를 들어 같은 이름의 패키지가 두 폴더에 있으면, 테스트 이름만으로는 부족하다. “api 테스트 통과”보다 어느 api 폴더에서 어떤 HEAD로 돌렸는지가 먼저다. 이 정보가 빠지면 나는 에이전트에게 새 수정을 맡기기보다 위치 확인부터 다시 시킨다.

세 줄은 대략 이런 질문으로 충분하다. “지금 보고 있는 루트는 어디인가”, “내가 기준으로 둔 브랜치와 커밋이 맞는가”, “방금 검증한 입력이 이번 수정 파일을 실제로 지나갔는가”. 이 정도만 고정해도 에이전트의 말이 훨씬 덜 떠다닌다. 나는 이걸 긴 보고서보다 작은 영수증에 가깝게 본다.

monorepo와 중첩 저장소에서는 경로가 곧 범위다

작은 프로젝트에서는 현재 경로 실수가 잘 드러난다. 파일이 없거나 명령이 바로 실패하기 때문이다. 반대로 큰 작업공간에서는 더 위험하다. 비슷한 스크립트, 비슷한 설정 파일, 같은 이름의 테스트가 여러 곳에 있어서 잘못된 폴더에서도 그럴듯한 결과가 나온다. 특히 라이브러리 루트와 데모 앱, 루트 저장소와 하위 저장소가 붙어 있으면 “성공”이 어느 범위의 성공인지 흐려진다.

이때는 변경 반경도 같이 흔들린다. 에이전트가 루트 설정을 고쳐야 하는데 예제 앱 설정을 고치거나, 하위 패키지 테스트만 보고 전체 동작이 안정됐다고 말할 수 있다. 그래서 나는 작업을 맡길 때 “이 폴더 안에서만”이라고 말하는 것보다, 검증도 같은 폴더 안에서 나온 것인지를 같이 본다. 수정 범위와 검증 범위가 달라지는 순간, 완료 판단은 한 번 멈추는 게 맞다.

중첩 저장소에서는 더 조심한다. 겉으로는 한 프로젝트 폴더처럼 보이는데, 실제로는 안쪽 디렉터리가 별도 Git 히스토리를 갖고 있을 때가 있다. 이 상태에서 바깥 저장소의 상태만 보고 “깨끗하다”고 판단하면 안쪽 변경을 놓칠 수 있다. 반대로 안쪽 테스트만 보고 바깥 배포 구성이 맞다고 믿어도 안 된다. 위치 확인은 귀찮은 절차가 아니라 작업 범위를 다시 그리는 행동이다.

PASS 로그에 붙일 질문을 바꿨다

예전에는 에이전트가 PASS를 가져오면 “무슨 테스트 돌렸어?”를 먼저 물었다. 지금은 질문이 조금 바뀌었다. “어디서 돌렸어?”를 먼저 묻는다. 그 다음에 “어떤 기준 커밋에서?”, “어떤 입력으로?”, “수정한 파일과 같은 범위야?”를 본다. 순서가 바뀌면 재시도 비용도 줄어든다. 테스트 종류를 따지기 전에 장소가 틀렸다면, 그 뒤의 해석은 대부분 다시 해야 하기 때문이다.

이 질문은 에이전트를 불신하려는 장치가 아니다. 오히려 같은 에이전트에게 더 오래 맡기기 위한 작은 안전핀에 가깝다. 위치가 고정되어 있으면 사람이 로그를 덜 의심해도 된다. 반대로 위치가 비어 있으면, 아무리 자세한 요약도 근거가 허공에 떠 보인다. 나는 완료 보고에서 경로 없는 PASS를 보면 내용보다 먼저 그 빈칸을 메운다.

좋은 보고는 “테스트 통과”에서 끝나지 않는다. “이 루트, 이 브랜치, 이 입력에서 통과”처럼 말한다. 이 차이는 작지만 리뷰 속도를 바꾼다. 위치가 붙은 PASS는 바로 다음 판단으로 넘어갈 수 있고, 위치가 빠진 PASS는 다시 확인 요청을 만든다. 에이전트가 빠를수록 이런 작은 되묻기가 오히려 전체 시간을 줄인다.

헷갈리는 PASS는 보류로 둔다

가장 애매한 경우는 로그는 맞아 보이는데 위치가 반쯤만 맞을 때다. 예를 들어 같은 브랜치지만 커밋이 하나 앞서 있거나, 같은 폴더지만 입력 fixture가 다른 경우가 있다. 나는 이때 완료와 실패 사이에 보류 칸을 둔다. 보류는 “에이전트가 틀렸다”가 아니라 “이 로그를 아직 결정 근거로 쓰지 않는다”는 뜻이다.

보류 상태에서는 새 수정을 바로 시키지 않는다. 먼저 현재 위치를 다시 고정하고, 같은 입력을 같은 기준선에서 한 번만 재실행한다. 그래도 PASS가 유지되면 그때 완료로 올린다. 반대로 결과가 달라지면 원인은 코드보다 실행 위치일 가능성이 크다. 이렇게 나누면 실패 분석이 훨씬 덜 감정적이고 덜 산만해진다.

위치가 어긋나면 재시도보다 확인이 먼저다

작업 위치가 의심될 때 바로 같은 명령을 다시 돌리면, 실패 원인이 더 흐려질 수 있다. 에이전트가 또 다른 위치에서 실행하거나, 방금 나온 로그를 기준선처럼 기억해 버릴 수 있기 때문이다. 이럴 때는 재시도보다 확인을 먼저 둔다. 현재 경로를 확인하고, 내가 맡긴 브랜치와 맞는지 보고, 수정 파일이 그 범위 안에 있는지 본 뒤에야 같은 검증을 다시 돌린다.

내 기준은 단순하다. PASS가 나왔다는 사실보다, 그 PASS가 내가 판단하려는 변경을 실제로 지나갔는지가 중요하다. 작업 위치 세 줄은 이걸 확인하는 가장 작은 장치다. 에이전트가 점점 자연스럽게 말할수록, 나는 초록 로그의 말맛보다 경로와 기준선의 건조한 숫자를 더 먼저 본다. 그래야 다음 수정도 같은 바닥 위에서 이어진다.