AI의 출력 대기 시간을 리뷰 준비 시간으로 바꾸기

서론

Claude Code나 Cursor에게 코드를 작성하게 하면 수십 초에서 수 분 정도의 대기 시간이 발생합니다.

처음에는 그 시간을 단순한 대기 시간이라고 생각해서, 생성 중인 화면을 멍하니 바라보거나 Slack을 보거나, X를 열곤 했습니다.

하지만 터미널로 돌아오면 자신이 무엇을 확인하려 했는지 잊어버리거나, 기억이 희미해진다는 것을 깨달았습니다.

지난번에는 AI에게 전부 맡기면 자신에게는 아무것도 남지 않는다는 이야기를 썼습니다.

그 후속 이야기로, AI가 작성한 코드를 리뷰에서 설명할 수 없었던 이야기도 썼습니다.

그때는 AI에게 던지기 '전'의 준비, 즉 설계 메모나 PR 설명, 테스트 관점을 스스로 언어화하는 것에 초점을 맞추고 있었습니다.

이번에는 그 다음 이야기를 해보고자 합니다.

AI에게 던진 '후', 출력을 기다리는 시간을 어떻게 사용할 것인가.

이 부분을 바꾸면 AI의 출력과 함께하는 방식이 상당히 달라질 것 같다는 느낌이 듭니다.

대기 시간에 문맥을 놓치면 AI의 출력에 휩쓸린다

AI 요청 후에 여러분은 시간을 어떻게 사용하시나요?

저는 저도 모르게 Slack, X, 블로그, 다른 Issue, 다른 PR의 리뷰를 해버려서,

돌아왔을 때 무엇을 요청했는지, 무엇을 확인하려 했는지 잊어버리는 경우가 있습니다.

그런 상태에서 AI의 출력을 보면, 코드는 그럴싸하게 정리되어 있고 로컬에서도 동작하기 때문에 "움직일 것 같다", "읽을 수 있겠다"라며 그냥 받아들여 버리게 됩니다.

AI의 출력은 형태를 갖추고 있는 만큼, 판단 기준을 가지고 있지 않은 자신에게는 더욱 올바르게 보입니다.

이것은 단순히 기분의 문제만은 아닌 것 같습니다.

태스크를 전환한 후에도 원래 태스크에 대한 주의가 일부 남아 있다는 Attention Residue(주의 잔류)라는 개념이 있습니다.

제 체감상으로도 AI 대기 시간에 Slack을 본 이후에는, 돌아온 코드를 읽을 때 문맥으로 복귀하는 것이 명확하게 느려집니다.

대기 시간에 다른 작업을 하면 출력 후에 AI의 결과만을 보게 되지만,

무엇을 요청했는지 거슬러 올라가기 → 결과를 이해하기 → 설명을 읽기 → 질문하기

어렴풋이 알 것 같은 기분이 든다. 아니, 그냥 피곤하다.. 같은 상태가 저의 현주소였습니다.

AI의 대기 시간은 리뷰 준비 시간이었다

어느 날, 대기 시간을 "심심한 시간"이 아니라 "리뷰 준비 시간"으로 생각하면 어떨까 하는 생각이 들었습니다.

AI가 코드를 작성하는 동안, 자신은 무엇을 근거로 OK를 할지 결정합니다.

목적·책임·실패 예상·테스트 관점·리뷰 질문.

이런 부분들을 대기 시간 동안 몇 줄의 메모로 남겨둡니다.

혹은 미리 기준을 정해두고, 출력 중에는 머릿속으로 '이러한 코드가 돌아올 것이다'라고 예측을 세웁니다.

그렇게 함으로써, 지금까지는 AI의 출력을 "채택할지 말지"의 관점으로 보았다면, 이제는 "자신의 기준과 맞는지"의 관점으로 볼 수 있게 되었습니다.

개인적으로 이것은 큰 차이였습니다.

리뷰하는 입장에 설 수 있게 되면, AI의 코드에 대해 "이 부분은 다르다"라고 말할 수 있게 됩니다.

대기 시간 길이에 따라 하고 있는 일

매번 전부 다 할 필요는 없다고 생각하지만, 대기 시간의 길이에 따라 하는 일을 바꾸고 있습니다.

대기 시간	하는 일	목적
~30초	요청 내용 다시 읽기	무엇을 부탁했는지 잊지 않기
...

~30초: 요청 내용 다시 읽기

짧은 대기 시간에는 메모를 작성할 여유가 없습니다.

대신에 자신이 AI에게 무엇을 부탁했는지를 다시 읽습니다.

무엇을 부탁했는가
무엇을 기대하고 있는가
어떤 파일·어떤 함수와 관계되는가

이것을 다시 읽는 것만으로도, 돌아온 출력물이 놓일 위치를 이미지화할 수 있는 감각을 잡을 수 있었습니다.

프롬프트를 스크롤해서 다시 확인하는, 그 정도면 충분하다고 생각합니다.

1~3분: AI가 저지를 법한 실수를 3가지 적기

시간이 조금 있을 때는 AI가 실수할 법한 일을 미리 예상해서 적습니다.

3가지면 충분합니다. 너무 많으면 적는 동안 출력이 돌아옵니다.

예를 들어, 다음과 같은 실수를 예상하는 경우가 많습니다.

기존의 책임 분할을 무시함
에러 케이스를 얕게 다룸
테스트를 작성한 것처럼 보이지만 중요한 케이스가 누락됨
UI 측에 도메인 로직을 너무 몰아넣음
기존의 명명 규칙(Naming Convention)과 어긋남
과도하게 범용화함

예상을 적어두면 출력을 보았을 때 위화감을 포착하기 쉬워집니다.

예상이 틀리는 것은 오히려 좋은 일로, AI가 생각보다 더 깊이 있는 제안을 해왔다는 신호가 됩니다.

3~5분: 테스트 관점·리뷰 질문 적기

조금 더 길어질 때는 테스트 관점(Test Perspective)과 리뷰 질문을 작성합니다.

이는 지난 글에서 다룬 '전송 전 준비'와 약간 겹치지만, 대기 시간 동안 작성하는 것은 훨씬 더 거칠어도 괜찮습니다.

테스트 관점이라면 다음과 같은 입도로 나열합니다.

정상계 (Happy Path)
이상계 (Edge Case/Error Case)
권한 없음
데이터 없음
경계값 (Boundary Value)
기존 동작의 회귀 (Regression)

리뷰 질문은 내가 리뷰어라면 무엇을 물어볼지를 작성합니다.

왜 이 계층(Layer)에 배치했는가
이 책임(Responsibility)이 여기서 적절한가
이 테스트로 충분한가

이렇게 적어두면, 출력 후의 셀프 리뷰(Self-review)가 그대로 PR(Pull Request) 설명문의 소재가 됩니다.

5분 이상: 돌아오기 위한 메모를 작성한 뒤 휴식하기

5분 이상의 대기 시간이라면, 굳이 화면 앞에서 대기하지 않아도 된다고 생각합니다.

다만, 자리를 뜨기 전에 "돌아와서 무엇을 볼 것인가"를 가볍게 메모해 두면 좋습니다.

이것을 적지 않고 자리를 뜨면, 저는 돌아왔을 때 상황 파악이 안 되는 경우가 많아서 메모를 작성하도록 하고 있습니다.

메모를 작성해 두면, 커피를 내리는 동안 머리가 쉬더라도 돌아오자마자 즉시 태스크(Task)에 집중할 수 있습니다.

물을 마시거나, 눈을 쉬게 하거나, 일어나서 걷는 정도라면 괜찮다고 생각하며, 실제로 저도 그렇게 하고 있습니다.

다만, Slack이나 X(구 Twitter)를 열면 다른 문맥(Context)으로 덮어씌워지기 때문에, 대기 시간이 길 때일수록 피하려고 노력합니다.

실제로 작성하는 메모

대기 시간 중에 작성하는 메모는 이 정도의 입도로 작성합니다.

에디터 구석에 메모를 열어두고 3분 정도 만에 휘갈겨 씁니다.

## 이번 목적
입력 에러 시, 사용자가 어떤 항목을 수정해야 하는지 알 수 있도록 한다.
## 책임에 대한 가설
...

이 메모는 문서로서 남기기 위한 것이 아닙니다.

직접 써보면 알겠지만, 책임에 대한 가설이나 확인 순서는 AI에게 전송하기 전부터 이미 머릿속에 막연하게 들어 있습니다.

그것을 언어화하여 남기느냐 아니냐에 따라, 출력 후의 자신의 기분이 달라집니다.

반대로, 대기 시간에 하지 않으려고 노력하는 것

대기 시간에 피하려고 하는 것은 다음과 같습니다.

Slack 보기
X 보기
YouTube 보기
다른 Issue로 이동하기
생성 중인 코드를 멍하니 바라보기
출력되자마자 바로 로컬에서 실행하기
실행되자마자 바로 채택하기
AI에게 추가 수정을 계속 요청하며 스스로 읽지 않기

물론 매번 완벽하게 지켜지는 것은 아닙니다. 급할 때는 Slack을 봐버리기도 합니다.

하지만 AI의 대기 시간마다 다른 문맥으로 이동하면, 돌아왔을 때 자신의 판단 기준이 크게 흔들리게 됩니다.

적어도 리뷰가 필요한 변경 사항에 대해서는, 대기 시간에 다른 디지털 정보를 너무 많이 주입하지 않도록 하고 있습니다.

"Slack을 보지 마라"고 말하고 싶은 것이 아니라, AI의 출력에 대해 자신의 판단력을 유지하고 싶다면, 대기 시간에 문맥을 놓지 않는 편이 이득이라는 뜻입니다.

시도해보고 변한 점

대기 시간의 사용법을 바꾼 뒤, 몇 가지 변화가 있었습니다.

AI의 출력에 휩쓸리지 않게 되었다
"이것은 다르다"라고 말하기 쉬워졌다
출력 후의 확인이 빨라졌다
PR 설명문을 쓰기 쉬워졌다
리뷰에서 질문받을 법한 점을 미리 해결할 수 있게 되었다
대기 시간이 단순한 휴식 시간이 아니게 되었다
AI를 사용하고 있음에도, 스스로 생각하고 있다는 감각이 돌아왔다

극적으로 생산성이 올라갔다는 느낌은 없지만, 출력 후에 망설이는 시간이나 리뷰 지적을 받은 후 재작업(Rework)하는 시간은 확실히 줄었습니다.

총 시간으로 따지면 아마 비슷하겠지만, AI 피로도가 크게 개선된 것처럼 느껴집니다.

예상되는 의문

여기까지 쓰다 보니, 스스로도 반론을 제기하고 싶어지는 포인트가 3가지 있습니다.

CLAUDE.md에 적어두면, 매번 실패 예측을 쓰지 않아도 되지 않을까?

Q. Claude Code의 메모리(Memory)와 대기 시간 메모리는 역할이 다르다고 느낍니다.

메모리 / CLAUDE.md는 출력 전에 AI가 준수하도록 만드는 규칙. 프로젝트 전체에 재사용 가능한 것을 두는 장소
대기 시간 메모리는 출력 후에 자신이 판단하기 위한 관점. 이 태스크 고유의 목적·책임·관점을 적는 장소

예를 들어 "기존의 책임 분할을 존중한다"는 CLAUDE.md에 적을 수 있습니다.

하지만 "이번 입력 에러 UI의 책임을 component / hook / pure function 중 어디에 두어야 하는가"는 태스크마다 달라지므로 메모리에 다 적을 수 없습니다.

게다가, CLAUDE.md...

에 적혀 있어도 AI는 보통 실수를 하곤 합니다.

가드(Guard)를 늘린다 해도, 최종적으로 그 코드가 이번 요구사항과 맞는지 판단하는 것은 인간이기에, 대기 시간 메모는 그를 위한 준비로서 작성하고 있다는 것이 저의 정리입니다.

Q. 리뷰도 AI에게 맡기고, 인간은 쉬면 되지 않을까요?

AI에게 리뷰를 시키는 것 자체는 저도 자주 하고 있습니다.

PR(Pull Request)을 올리기 전에 Claude나 CodeRabbit에게 대략적으로 확인받는 것은 편리합니다.

다만, "AI가 작성하고, AI가 리뷰하며, 인간은 Approve 버튼만 누르면 되는" 상태가 되면 조금 위험하다고 느낍니다.

PR을 제출하는 순간, 그 구현은 자신의 판단으로서 기록됩니다. 리뷰어나 장애 대응 상황에서 "왜 이렇게 구현했는가"라는 질문을 받았을 때, "AI 리뷰가 OK를 내보냈기 때문입니다"라는 답변은 통하지 않기 때문입니다.

이는 지난번 글에서 썼던 "리뷰에서 설명하지 못했다"는 문제와 본질적으로 같습니다.

AI 리뷰는 보조선으로는 사용할 수 있지만, 판단의 최종 책임까지 AI에게 넘겨버리면 결국 "설명할 수 없는 코드"를 양산하게 됩니다.

따라서 AI 리뷰를 병행하는 경우라도, 자신만의 판단 기준을 가지고 있을 가치는 있다고 생각합니다.

Q. 애초에 태스크를 작게 나누어 대기 시간 자체를 발생시키지 않는 편이 좋지 않을까요?

완전히 맞는 말씀입니다.

태스크를 작게 구분하면 AI에게 부탁하는 단위도 작아지고, 1회당 대기 시간도 짧아집니다.

리뷰하기도 쉬워지며, AI의 출력 속도에 뒤처지는 느낌도 줄어듭니다.

오히려 태스크를 작게 나눌 수 있는 상황이라면 그쪽을 우선시해야 한다고 생각합니다.

다만, 현실에서는 작게 나눌 수 없는 상황도 있습니다.

기존 코드 조사가 포함된 태스크
리팩터링(Refactoring)이나 책임 재배치처럼, 어느 정도 묶인 단위로 생각하지 않으면 판단할 수 없는 것
사양(Specification) 탐색이 필요하여 애초에 나눌 입도가 결정되지 않은 것

이러한 상황에서는 아무래도 한 번의 요청이 길어지게 됩니다.

이번에 작성한 대기 시간 운용은, 그러한 "작게 나눌 수 없거나, 나누기 어려웠던" 상황에서의 보험으로서 사용하고 있는 이미지입니다.

먼저 태스크를 작게 나누는 것을 시도해 보고, 그럼에도 대기 시간이 발생할 때 이번 내용을 검토한다는 관계가 되어 있다고 생각합니다.

요약

잘 진행되고 있는 이야기들만 썼지만, 역시 피곤하면 아무래도 소홀해지게 됩니다.

한밤중에 작업을 하다 보면 무의식적으로 PR을 만들어 버리는 경우도 있어, 다음 날 체크부터 시작하느라 따라잡는 데 시간이 걸리기도 합니다.

역시 피곤할 때는 얌전하게 잠을 자는 것에 집중하는 것이 좋겠다고 생각했습니다.

앞으로는 AI의 대기 시간 동안 태스크에서 너무 멀어지지 않고 작업에 집중해 나가고 싶습니다.