중단된 작업의 기준선과 미확인 영역

 

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

---

중단된 작업은 완료 여부보다 기준선, 변경, 미확인 영역을 먼저 분리해야 다시 들어갈 수 있다.

중단은 작업 실패보다 상태 손실에 가깝다

코딩 에이전트가 파일을 고치던 중간에 다른 요청이 끼어들면, 나는 예전에는 그냥 “여기까지 했고 나중에 이어서 하자” 정도로 넘겼다. 그런데 실제로 다시 돌아오면 문제가 꽤 자주 생겼다. 에이전트는 자기가 마지막으로 본 로그와 방금 바꾼 diff를 한 덩어리로 기억하고, 나는 어느 지점까지가 확인된 사실인지 다시 더듬어야 했다.

특히 여러 파일을 만지는 작업에서는 이 차이가 크다. 테스트 하나가 통과했더라도 그 테스트가 중단 직전의 상태를 대표하는지, 아니면 그 전에 본 낡은 기준선인지 헷갈린다. 새 요청을 처리하고 돌아온 뒤 바로 수정을 이어 가면, 원래 문제를 고치는 건지 새로 생긴 추정을 고치는 건지 섞인다. 그래서 중단은 실패보다 상태를 잃는 사건에 가깝게 보는 편이 더 안전했다.

기준선은 마지막으로 믿을 수 있는 지점이다

중단 시점에 내가 먼저 남기는 것은 진행률이 아니다. “80% 완료” 같은 말은 재개할 때 별 도움이 안 된다. 대신 마지막으로 믿을 수 있는 기준선을 적는다. 예를 들면 마지막 commit, 통과한 테스트 이름, 화면에서 본 정상 동작, 에러 로그의 시각 같은 것들이다. 여기서 중요한 건 기준선이 항상 성공 상태일 필요는 없다는 점이다.

나는 실패 로그도 기준선으로 쓴다. “이 입력에서는 아직 500이 난다”, “이 화면에서는 버튼이 보이지만 클릭 후 응답은 못 봤다”처럼 적어 두면, 다음 세션이 성공한 척 시작하지 않는다. 기준선은 낙관적인 요약보다 다음 확인이 기대어도 되는 마지막 관찰이어야 한다. 이 한 줄이 없으면 에이전트는 중단 전 추정과 실제 확인을 쉽게 섞는다.

변경은 의도와 증거로 적는다

그다음은 변경이다. 여기서도 단순히 파일명을 나열하면 부족하다. 파일 세 개를 바꿨다는 사실보다, 왜 바꿨고 어떤 증거를 보고 바꿨는지가 더 중요하다. 예를 들어 “환경변수 기본값 처리 수정”이라고만 쓰면 재개한 에이전트는 주변 설정 파일까지 넓게 열 수 있다. 반대로 “빈 문자열을 기본 URL로 오해한 재현 입력 때문에 loader 조건문만 바꿨다”라고 적으면 변경 반경이 좁아진다.

이 줄은 나중의 리뷰에도 좋다. 중단 전 변경이 잘못됐다고 판단되면 되돌릴 좌표가 바로 보이고, 맞는 방향이면 어떤 테스트를 이어서 볼지도 보인다. 나는 이때 바뀐 파일, 바꾼 이유, 아직 검증하지 못한 효과를 한 줄에 같이 둔다. diff 자체는 도구가 보여 주지만, diff가 어떤 문제를 향해 있는지는 사람이 남겨야 한다.

미확인 영역은 다음 세션의 첫 행동이 된다

마지막 칸은 미확인 영역이다. 이 칸을 비워 두면 재개한 세션은 자연스럽게 가장 쉬운 테스트나 가장 가까운 파일부터 본다. 하지만 실제 위험은 보통 그 옆에 있다. 권한 흐름, 모바일 화면, 긴 입력, 빈 값, 배포 환경, 브라우저 차이처럼 한 번 더 열어 봐야 하는 표면이 중단 중에 묻힌다.

그래서 나는 미확인 영역을 “나중에 확인”이라고 쓰지 않는다. 가능하면 다음 첫 행동으로 바꾼다. “모바일은 미확인”보다 “모바일에서 같은 입력으로 저장 버튼을 한 번 눌러 본다”가 낫다. “배포 환경 미확인”보다 “스테이징 환경 변수에 빈 문자열이 들어갈 때 fallback이 작동하는지 본다”가 낫다. 미확인은 불안 목록에 머물지 않고 재개 버튼이 되어야 한다.

내가 쓰는 interrupt 메모 형식

요즘은 작업이 끊길 것 같으면 길게 요약하지 않고 아래 세 줄만 남긴다. 첫 줄은 기준선, 둘째 줄은 변경, 셋째 줄은 미확인이다. 이 세 줄이 있으면 다음 세션이 바로 수정을 이어 가기보다, 먼저 기준선을 다시 확인하고 미확인 영역 하나를 닫은 뒤 움직인다.

기준선: 마지막으로 믿을 수 있는 테스트, 화면, 로그, commit은 무엇인가.
변경: 중단 전 실제로 바꾼 파일과 그 이유는 무엇인가.
미확인: 아직 열지 않은 입력, 환경, 권한, 화면은 무엇이며 다음 첫 확인은 무엇인가.

이 메모가 있으면 에이전트를 덜 믿게 만드는 장치가 아니다. 오히려 더 편하게 다시 맡길 수 있다. 기준선이 있으니 확인부터 시작하게 만들 수 있고, 변경이 있으니 diff가 어디까지 퍼졌는지 볼 수 있고, 미확인이 있으니 완료 보고의 빈칸을 바로 찾을 수 있다. 중단된 작업에서는 기억력보다 돌아올 좌표를 작게 남기는 습관이 덜 흔들린다.

끼어든 요청을 처리한 뒤에는 다시 기준선을 묻는다

중간에 들어온 요청이 아주 작아 보여도, 돌아오는 순간에는 원래 작업의 기준선이 한 번 흔들린다. 새 요청을 처리하면서 같은 파일을 열었을 수도 있고, 테스트를 다시 돌렸지만 다른 입력을 봤을 수도 있다. 그래서 나는 “방금 처리한 건 별개였으니 계속하자”라고 하지 않고, 원래 작업의 기준선이 여전히 같은지 먼저 묻는다.

이 질문은 에이전트를 불신해서가 아니다. 오히려 같은 에이전트에게 계속 맡기려면 중간에 생긴 관찰을 원래 diff에 자동으로 합치지 말아야 한다. 새 요청에서 본 로그가 원래 문제의 근거인지, 그냥 옆 작업의 부산물인지 한 번 나누면 다음 수정이 훨씬 덜 커진다. 나는 이때 원래 기준선 유지, 새 요청에서 생긴 변경, 아직 합치면 안 되는 관찰을 따로 둔다.

완료 보고 대신 재개 보고를 받는다

중단된 작업으로 돌아올 때 가장 위험한 문장은 “이어서 진행하겠습니다”다. 듣기에는 자연스럽지만 실제로는 어디서 이어지는지 말하지 않는다. 나는 재개 직전 보고를 짧게 요구하는 편이다. 기준선은 그대로인지, 중간에 바뀐 파일은 무엇인지, 첫 확인은 무엇인지 세 가지를 먼저 말하게 한다. 이 보고가 비어 있으면 아직 수정 재개 전의 상태 복구 단계라고 본다.

예를 들어 에이전트가 “테스트는 아까 통과했습니다”라고 말하면 나는 통과 시점과 현재 diff 사이에 다른 변경이 있었는지 다시 확인한다. “파일은 하나만 바꿨습니다”라고 말하면 그 파일이 원래 작업 파일인지, 끼어든 요청 때문에 열린 파일인지 나눈다. 작은 확인 같지만, 이 과정을 거치면 나중에 왜 고쳤는지 모르는 줄이 줄어든다.

좋은 interrupt 메모와 애매한 메모

애매한 메모는 대체로 감정과 진행률을 많이 담는다. “거의 끝남”, “테스트 조금 더 필요”, “나중에 다시 확인” 같은 표현은 당시에는 충분해 보이지만 다음 세션에서는 판단 재료가 부족하다. 좋은 메모는 더 건조하다. 마지막으로 본 명령, 실제 바뀐 파일, 아직 안 본 입력, 다음 첫 행동이 들어간다. 읽는 맛은 덜하지만 다시 들어가는 속도는 빠르다.

나는 이 차이를 꽤 늦게 체감했다. 에이전트가 똑똑해질수록 긴 설명보다 작은 좌표가 더 중요해졌다. 모델은 빈칸을 그럴듯하게 이어 붙이는 데 능숙해서, 사람이 비워 둔 미확인 영역까지 자연스럽게 메워 버릴 때가 있다. interrupt 메모의 역할은 그 빈칸을 채우는 쪽보다, 빈칸을 빈칸으로 유지한 채 다음 확인으로 넘기는 것에 가깝다.