AI 답변이 내 판단을 대신하지 않게 만드는 검토 습관 | DAKER 커뮤니티

Claude Code가 만든 diff가 화면을 가득 채우는 순간, 정말 조심해야 할 것은 병합 버튼 자체가 아닙니다. 대충 맞겠지라고 마음속에서 검토를 끝내는 순간이 더 위험합니다. 그때부터 AI의 답은 참고 자료가 아니라 내 판단을 대신한 결론이 되기 쉽습니다.

요즘처럼 에이전트 코딩이 빨라질수록, 사람에게 더 중요해지는 것은 속도가 아니라 판단의 흔적입니다. Addy Osmani가 말한 cognitive surrender는 바로 이 지점을 짚습니다. 계산과 초안을 맡기는 수준을 넘어, AI 출력이 조용히 내 답이 되어 버리는 상태입니다.

cognitive surrender가 문제인 이유

오늘의 핵심은 Addy Osmani가 말한 cognitive surrender입니다. AI에게 계산과 초안을 맡기는 cognitive offloading은 여전히 사람이 답을 소유하지만, cognitive surrender는 AI 출력이 조용히 내 답이 되고 내가 따로 확인할 것이 없다고 느끼는 상태입니다. 에이전트 코딩에서는 그 경계가 diff, 버그 수정, 설계 선택, 새 라이브러리 학습 화면에서 자주 움직입니다.

AI의 답과 비교할 독립적인 관점을 만들지 못하면, 검토는 쉽게 포기로 바뀝니다.

이 문제는 눈에 띄게 시작되지 않습니다. Claude Code가 600줄짜리 PR을 만들었고 테스트가 초록색일 때, 오류 로그를 붙여 넣었더니 바로 동작하는 패치가 돌아왔을 때, 큐와 직접 호출 중 하나를 고르는 설계 결정을 모델이 자신 있게 설명할 때처럼 그럴듯한 순간에 더 자주 나타납니다. 이때 필요한 질문은 AI가 맞았나 하나가 아니라, 내가 AI의 답과 비교할 독립적인 관점을 만들었나입니다.

겉보기 정답과 시스템 정답은 다를 수 있습니다

생성 코드는 컴파일되고 파일 스타일을 잘 따라갈 수 있습니다. 하지만 그것만으로 시스템 수준에서 맞는 답이라고 보기는 어렵습니다. 트랜잭션 순서, 기본값, 경계 조건처럼 작은 지점 하나가 전체 의미를 바꿀 수 있기 때문입니다.

또 하나의 문제는 신뢰가 쉽게 전염된다는 점입니다. 모델이 단정적인 문장으로 이유를 설명하면, 사람은 그 자신감을 실제 근거처럼 빌려 쓰기 쉽습니다. 그 결과 이해하지 못한 패치, 직접 내리지 않은 설계 선택, 내가 지정하지 않은 테스트가 쌓이면서 이해 부채가 생깁니다. 이 부채는 한 번에 드러나지 않지만, 다음 변경을 점점 더 어렵게 만듭니다.

검증은 그럴듯함이 아니라 구체적인 증거로 끝나야 합니다.

그래서 검증은 종료 조건이어야 합니다. 그럴듯하다는 인상으로 작업을 닫는 것이 아니라, 실행한 테스트, 본 스크린샷, 읽은 diff, 남긴 로그처럼 확인 가능한 증거가 있어야 완료라고 볼 수 있습니다.

에이전트 코딩에서 판단을 남기는 방법

짧게 비유하면, AI 코딩은 운전 보조 장치와 비슷합니다. 핸들을 잠깐 맡길 수는 있지만, 도로를 안 보고 있다는 사실까지 잊으면 보조가 아니라 포기가 됩니다. 다만 이 비유는 태도를 설명할 뿐이고, 실제 판단은 결국 diff와 증거에서 해야 합니다.

작업 전에 예상 결과를 먼저 적습니다

에이전트에게 맡기기 전, 예상 결과를 먼저 적어 두는 것이 좋습니다. 수정될 파일, 바뀌면 안 되는 경계, 성공 증거를 세 줄만 남겨도 AI의 답을 비교할 기준이 생깁니다.

큰 작업은 읽을 수 있는 단위로 나눕니다

사람이 실제로 이해할 수 없는 크기의 PR은 검토가 아니라 승인 의식으로 바뀌기 쉽습니다. 큰 작업일수록 읽을 수 있는 diff 단위로 자르는 편이 좋습니다.

반대 논리를 일부러 넣습니다

모델에게 이 설계가 틀렸다면 어디서 깨지나를 한 번 물어보면, 빌려 온 자신감을 흔드는 값싼 마찰을 만들 수 있습니다. 이 과정은 AI의 답을 무조건 의심하자는 뜻이 아니라, 내 판단이 개입할 자리를 확보하자는 뜻에 가깝습니다.

검증 증거를 종료 조건으로 둡니다

테스트 이름, 실패했다가 통과한 로그, 화면 스크린샷, 리뷰 포인트 중 최소 하나가 없으면 완료로 보지 않는 기준이 필요합니다. 그래야 작업이 인상이나 분위기가 아니라 증거를 중심으로 닫힙니다.

피곤할수록 생성 속도를 늦춥니다

검토할 힘이 없을 때의 에이전트 출력은 생산성이 아니라 다음 날의 이해 부채가 될 수 있습니다. 피곤한 상태에서는 더 빠른 생성보다 더 느린 검토가 도움이 되는 경우가 많습니다.

실수 방지를 위해 기억할 점

테스트가 통과했다는 이유만으로 diff를 읽지 않는 습관은 만들지 않는 것이 좋습니다. 테스트는 필요조건이지 이해의 대체물이 아닙니다.

또 AI가 쓴 설계 설명을 회의에서 그대로 반복하지 않는 편이 좋습니다. 왜 그 선택을 했는지 스스로 재구성할 수 없다면, 아직 내 판단이라고 보기 어렵습니다.

새 라이브러리를 배울 때도 바로 코드 생성부터 시키지 않는 편이 좋습니다. 먼저 개념 질문과 trade-off 탐색을 시켜야 도구가 학습을 깎지 않고 보강합니다.

참고 자료

Addy Osmani 공식 사이트의 글 3개에서 cognitive offloading, cognitive surrender, diff review, debugging, design call, independent view, hard exit criterion, smaller PR, conceptual inquiry 관련 항목 9개를 확인했습니다. 이어 볼 글은 DAKER 클로드 코드 디렉터리에서 확인할 수 있습니다.

AI가 더 빨라질수록, 사람이 남겨야 할 것은 속도가 아니라 판단의 흔적입니다.

여러분은 에이전트가 낸 답을 검토할 때 어떤 방식으로 내 판단의 기준을 남기고 있나요?