에이전트의 결과를 무작정 승인하지 마세요: ‘AI가 문제를 내서 나를 시험하게 하기’ 등 이해 부채를 갚는 6가지 방법

작성자 주: Addy Osmani의 ‘인지적 항복’과 ‘이해 부채’를 중심으로 PR 병합 전 자가 점검 목록과 프롬프트 템플릿을 정리했어요. 인수 보고서를 활용하는 LobeHub의 검토 방식과도 비교해, 위험도에 맞는 검토 강도를 선택할 수 있도록 돕습니다.

매일 Claude Code, Cursor, Cline으로 코드를 작성한다면 이런 경험이 있을 거예요. 에이전트가 몇 분 만에 수백 줄짜리 PR을 올렸는데, 이름도 규칙에 맞고 구조도 깔끔한 데다 테스트까지 모두 통과해 ‘승인’을 눌렀죠. 그런데 몇 주 뒤 누군가 왜 로직을 그렇게 작성했냐고 물으면 대답하기 어렵습니다. 이 글에서는 ‘AI에게 문제를 내달라고 하기’처럼 바로 실행할 수 있는 점검 방법을 통해, 모든 줄을 검토하지 않더라도 승인한 변경 사항에 책임을 질 수 있도록 돕습니다.

이 글은 다시 코드를 직접 작성하라고 권하는 글이 아니에요. Claude Code 엔지니어 Addy Osmani도 엔지니어에게 코드베이스 전체를 기억하라고 요구하는 사람은 없다고 분명히 말합니다. 중요한 건 모든 줄을 읽느냐가 아니라, 자신이 무엇을 알고 무엇을 모르는지 아느냐예요.

핵심 내용: 이 글을 읽으면 ‘인지적 오프로딩, 판단 위임, 인지적 항복’으로 이어지는 과정을 이해하고, 바로 복사해 쓸 수 있는 병합 전 질문 목록과 프롬프트 템플릿을 얻을 수 있어요. 변경 위험도에 따라 검토 강도를 선택하는 방법도 배웁니다.

Agent의 결과에 도장만 찍지 마세요: 이해 부채 핵심 정리

량쯔웨이(量子位)의 보도(36氪 재전재)에 따르면, 전 Google 엔지니어이자 현재 Claude Code 개발에 참여하는 Addy Osmani가 뼈아픈 문제를 짚었어요. AI가 생성한 결과물이 신뢰할 만해질수록 사람은 오히려 검토에 소홀해진다는 거예요. 그는 이 과정을 몇 단계로 나누고 두 가지 새로운 ‘부채’를 제시했어요. 아래 개념은 모두 언론 보도를 바탕으로 한 것이므로, 정확한 표현은 Addy의 원문을 참고해 주세요.

인지적 항복과 이해 부채가 쌓이는 과정

인지적 항복은 하루아침에 일어나지 않아요. 처음에는 그저 구체적인 작업의 부담을 덜 뿐이에요. 어셈블리 코드를 직접 작성하지 않고 컴파일러를 쓰는 것처럼, 그 자체로는 문제가 없어요. 위험은 두 번째 단계에서 시작돼요. Agent의 결과물이 연달아 믿을 만하면 그 결론이 어느새 기본 전제가 되고, 검증을 건너뛰기 시작해요. 세 번째 단계에 이르면 ‘승인’ 버튼은 도장이 되고, 엔지니어는 도장 찍는 사람으로 바뀌어요.

Addy가 든 전형적인 예가 있어요. Agent가 한 번에 600줄의 코드를 제출했는데, 구조도 깔끔하고 테스트도 통과하자 개발자가 안심하고 병합해요. 하지만 Agent가 눈에 잘 띄지 않는 곳에서 트랜잭션 처리 순서를 바꾸거나 특정 경계 조건을 조정했을 수도 있어요. 이런 변경은 당장 오류를 일으키지 않지만, 실제로 시스템에 문제가 생기면 개발자는 코드가 왜 그렇게 동작하는지 설명하지 못해요. 이것이 바로 이해 부채의 ‘이자’예요. 꼭 가장 곤란한 순간에 갚아야 하죠.

의도 부채는 그보다 앞선 단계에서 발생해요. 요즘 Agent는 요구사항을 보완하는 데 능숙해서, 사용자가 명확히 생각하지 못했더라도 그럴듯한 결과물을 내놓아요. 문제는 명확히 밝히지 않은 목표, 범위, 트레이드오프를 AI가 조용히 대신 결정했다는 거예요. 의도 부채와 이해 부채는 함께 쌓이는 경우가 많아요. 처음에 무엇을 원했는지도, Agent가 결국 무엇을 만들었는지도 모르게 되는 거죠.

이해 부채를 갚는 6가지 방법

Addy는 긴 글에서 실무에 쓸 수 있는 다양한 조언을 공유했어요. 이를 6가지 방법으로 정리하고, 각각 어떤 부채를 갚는 데 도움이 되는지, 워크플로의 어느 단계에서 활용할 수 있는지 살펴볼게요.

AI에게 시험 문제를 내달라고 하기: 이해 부채를 확인하는 핵심 방법

여섯 가지 방법 중 가장 흥미로운 방법이에요. 에이전트가 대규모 수정을 마쳤다면 바로 승인하지 말고, 먼저 시험관 역할을 맡겨보세요. 어디를 왜 수정했는지 요약하게 한 뒤, 수정 내용을 바탕으로 몇 가지 문제를 내달라고 요청해요. 그리고 모든 문제를 맞혀야 병합한다는 규칙을 세우세요. 이렇게 하면 “대충 이해한 것 같다”는 막연한 느낌을 검증 가능한 결과로 바꿀 수 있어요. 답하지 못한 문제가 바로 이해 부채가 쌓인 지점을 알려줍니다.

승인하지 않은 결정과 테스트하지 않은 부분 묻기

장시간 실행되는 작업에서 에이전트는 기본 매개변수를 직접 선택하거나 구현 범위를 조정하고, 요구사항이 충돌할 때 우선순위를 정하기도 해요. 이런 결정은 “너무 당연하다”는 이유로 최종 요약에 빠질 수 있어요. 따라서 “완료했어?”라고 묻는 것보다 다음과 같이 구체적으로 묻는 편이 효과적이에요. 내가 명시적으로 승인하지 않은 결정은 무엇인가요? 어떤 부분이 자체적인 가정에 의존하나요? 아직 검증하지 않은 것은 무엇인가요? 다른 기능에 영향을 줄 수 있는 변경 사항은 무엇인가요?

테스트도 마찬가지예요. Addy는 테스트 결과가 모두 초록색이어도 테스트가 다룬 조건을 통과했다는 사실만 증명할 뿐이라고 강조해요. 경계 사례를 테스트에 넣지 않았다면 보고서는 여전히 좋아 보일 수 있어요. 먼저 실제로 어떤 테스트를 실행했고 어떤 결과가 나왔는지 확인한 다음, AI가 생성한 요약을 읽는 순서가 좋아요. 위험도가 높은 변경이라면 다른 에이전트에게 독립적으로 다른 관점에서 문제를 찾아달라고 요청할 수도 있어요.

병합 전 셀프 체크 빠른 시작: Agent 결과에 무턱대고 승인하지 않는 5단계

앞서 살펴본 방법을 연결하면 모든 PR을 병합하기 전에 실행할 수 있는 절차가 완성돼요. 코드를 한 줄씩 검토할 필요는 없지만, 각 단계에서 직접 생각하고 확인한 흔적을 남겨야 해요.

1. 작업 전에 기대 결과 적기: 요구사항과 예상되는 결과를 자신의 말로 작성해요. 프롬프트를 두 차례 수정해도 만족스럽지 않다면, 계속 덧붙이기보다 요구사항부터 다시 정리하세요.
2. 결정 사항 설명 요구하기: 작업이 끝나면 Agent에게 명시적으로 허락받지 않은 결정, 가정, 검증하지 않은 항목을 나열하도록 요청해요.
3. 실제 테스트 확인하기: 실제로 실행한 테스트 명령과 출력을 살펴보고, 어떤 경계 조건을 다루지 않았는지 추가로 물어봐요.
4. Agent에게 문제 출제 요청하기: 이번 diff를 바탕으로 문제를 내게 해 스스로 이해도를 확인해요. 틀린 부분은 코드로 돌아가 명확히 이해하세요.
5. 놓친 항목 하나 찾기: Agent가 결과를 제출한 뒤, 확인하지 않았을 만한 항목을 적어도 하나 직접 찾아보세요.

이해 부채 셀프 체크를 위한 간단한 프롬프트 예시

아래는 가장 자주 쓰는 ‘문제 내줘’ 프롬프트예요. Claude Code, Cursor, Cline 대화창에 그대로 붙여 넣어 사용할 수 있어요.

在我合并这次改动之前，请先做两件事：
1. 用不超过 10 条要点总结本次改了哪些文件、每处改动的原因。
2. 根据本次 diff 给我出 5 道题，重点覆盖：事务/调用顺序、
   边界条件、错误处理、对其他模块的影响。
   先只给题目，等我作答后再批改，并指出我答错的地方对应哪段代码。
规则：我没有全部答对之前，不要建议合并。

# 阶段 A：开工前（偿还意图债，由我先填写）
需求说明：
- 面向谁：
- 要解决的问题：
- 明确不做的事：
- 完成标准（做到什么程度算完成）：
- 我预期的改动范围和结果：

# 阶段 B：任务结束后（请 Agent 逐条回答）
1. 你做了哪些我没有明确授权的决定？请列出决定内容和理由。
2. 哪些地方依赖了你自己的假设？假设不成立时会发生什么？
3. 还有哪些内容没有验证？
4. 哪些改动可能影响其他功能或模块？
5. 你实际运行了哪些测试命令？请贴出原始输出，而不是总结。
6. 哪些边界情况没有写进测试？

# 阶段 C：出题考核（偿还理解债）
请根据本次 diff 出 5 道题，先只给题目。
我作答后请批改，答错的题请定位到具体代码行。
我未全部答对前，不要建议合并。

# 阶段 D：高风险改动追加（可交给另一个独立会话）
请你作为独立审查者，不参考上一个会话的总结，
只基于原始需求和 diff，找出最可能出问题的 3 个地方。

🎯 사용 팁: 단계 A는 Agent에게 대신 작성하게 하지 말고, 반드시 작업 전에 직접 작성하세요. 단계 D는 새 세션에서 진행하는 것이 좋아요. 독립 검토자가 이전 Agent의 요약에 영향을 받지 않도록 하기 위해서예요. 이는 여러 Agent가 정보를 전달하는 과정에서 생기는 손실에 대한 Addy의 지적과도 통하는 방법이에요.

머지 전 질문 체크리스트 요약

AI가 내는 문제로 이해도 점검하기와 인수 보고서 기반 검토 비교

이와는 전혀 다른 접근법도 있어요. 오픈소스 Agent 협업 플랫폼 LobeHub(GitHub 스타 약 8.4만 개)의 사례입니다. 바이징 연구소 보도에 따르면, 이 팀은 “이제 코드를 거의 보지 않는다”고 말하며 Agent의 멀티모달 인수 보고서를 중점적으로 살펴봐요. 자체 개발해 올해 9월 오픈소스로 공개한 Acceptance를 사용하는데요. Agent가 결과물을 전달하기 전 요구사항을 직접 확인할 수 있는 점검 항목으로 나누고, 실제 제품에서 하나씩 실행해 스크린샷, 화면 녹화, 로그와 함께 온라인 보고서로 정리해요. 사람은 전체를 승인하거나 특정 항목만 반려할 수 있어요.

두 가지 검토 방식 비교 분석

인수 보고서 기반 검토: 인수 보고서는 관찰 가능한 동작을 효율적으로 검증하며, 개별 점검 항목에 반려 의견을 남길 수도 있어요. 보도 속 실제 테스트에서는 검토자가 어두운 배경 항목만 반려했고, Agent도 CSS 한 줄만 수정했어요. 다른 파일은 변경되지 않았죠. 다만 요구사항을 관찰 가능한 점검 항목으로 나눌 수 있어야 해요. 보도에서도 복잡한 작업의 보안, 아키텍처, 최종 품질은 여전히 사람이 판단해야 하며, 피드백 전달 과정에도 수작업이 필요한 부분이 있다고 짚었어요. “코드를 거의 보지 않는다”는 팀의 자체 설명이며, 독립적으로 검증된 내용은 아니에요.

문제로 이해도 점검: 문제를 통한 평가는 트랜잭션 순서나 경계 조건처럼 “화면에서는 보이지 않는” 문제를 드러내는 데 더 강해요. 인수 보고서의 사각지대를 보완하는 셈이죠. 하지만 효과는 문제의 품질에 달려 있고, 개발자가 실제로 이해하는 데 시간을 들여야 해요. 두 방식은 서로 배타적이지 않아요. 인수 보고서로 “제대로 만들었는지” 확인하고, 문제로 “왜 이렇게 만들었는지 내가 이해하는지” 확인하는 편이 더 합리적이에요.

변경 위험에 따라 이해 부채 리뷰 강도 정하기

모든 PR에 전체 절차를 적용할 필요는 없어요. Addy도 생성된 콘텐츠가 너무 많아 책임질 수 없는 수준에 이르면, 더 이상 리뷰가 아니라 문제가 없기를 바라는 도박이라고 경고해요. 아래 표는 위험 수준별 참고 기준이에요. 구체적인 기준은 팀 상황에 맞게 조정하세요.

💡 선택 가이드: 팀에 이미 성숙한 자동화 검수 체계가 있다면 이해도 평가는 고위험 변경에 집중해도 좋아요. 그렇지 않다면 최소한 데이터 일관성과 권한이 관련된 PR에서는 “질문에 정확히 답해야 병합한다”는 원칙을 지키세요.

자주 묻는 질문 FAQ

Agent에게 무작정 승인 도장을 찍지 마세요: 이해 부채 핵심 요점 Key Takeaways

• 인지적 항복은 서서히 진행돼요: 인지적 부담을 덜기 시작해 판단을 넘기고, 결국 모든 판단을 맡기게 돼요
• 이해 부채에는 나중에 이자가 붙어요: 코드 작성 속도가 빨라질수록 이해하지 못한 부분이 수정 단계에서 한꺼번에 문제가 돼요
• 의도 부채는 작업 시작 전에 생겨요: 시작 전에 직접 요구사항 목록을 작성하고, 프롬프트를 두 차례 입력해도 결과가 만족스럽지 않으면 요구사항을 다시 정리하세요
• 핵심은 Agent가 내는 문제를 푸는 거예요: Agent에게 변경 사항을 요약하고 문제를 출제하게 한 뒤, 모두 맞혔을 때만 머지하세요
• 테스트가 모두 통과했다고 문제가 없는 건 아니에요: 실제 실행된 테스트의 출력을 먼저 확인하고, 무엇을 테스트하지 않았는지 물어보세요
• 검수 보고서와 문제 풀이는 서로 보완해요: 보고서는 외부 동작을 검증하고, 문제 풀이는 내부 로직을 이해했는지 확인해요
• 위험도에 따라 검토하세요: 검토할 여력이 부족하다면 자동화를 보강하거나 병렬 작업을 줄이세요. 운에 맡기지 마세요

정리

Agent에게 무작정 승인 도장을 찍지 않기 위한 핵심은 다음과 같아요.

1. 단계 인식: ‘AI에게 작업을 맡기는 것’에서 ‘AI에게 판단을 맡기는 것’으로 넘어가지 않도록 주의하세요. 이해 부채와 의도 부채는 모두 이 과정에서 생겨요
2. 실행 방법: 작업 전에 기대 결과를 적고, 결과물을 받으면 승인 없이 내린 결정과 테스트하지 않은 내용을 물어보세요. 머지하기 전에는 AI가 내는 문제를 푸세요
3. 위험도별 선택: 위험도가 낮은 변경은 검수 보고서나 간단한 점검으로 확인하고, 위험도가 높은 변경은 전체 절차에 더해 독립적인 검토까지 거치세요

AI의 코드 작성 속도는 계속 빨라지겠지만, 변경에 책임지는 사람은 언제나 그 변경을 승인한 사람이에요. 다음에 ‘승인’을 누르기 전에 Agent에게 문제 5개를 내달라고 해보세요. 몇 개나 맞힐 수 있는지 확인해 보세요.

📚 참고 자료

1. 量子位: Claude 엔지니어의 Agent 완전 가이드(36 氪 재게재): 인지적 항복, 이해 부채, 의도 부채에 관한 Addy Osmani의 관점과 실천 방법을 소개해요.
2. 링크: 36kr.com/p/4056027738116995

3. 설명: 이 글의 핵심 방법론이 나온 자료로, 미디어가 원문을 재인용한 기사예요.

4. Addy Osmani 원문 게시물: 기사에서 인용한 원문이에요.

5. 링크: x.com/addyosmani/status/2117512471930167377

6. 설명: 정확한 표현은 원문을 확인해 주세요. 링크는 직접 검증해야 해요.

7. 白鲸实验室: Star 8만 개를 받은 AI 회사가 AI에 운영을 맡기기로 했다(36 氪 재게재): LobeHub의 총괄 Agent 아키텍처와 Acceptance 검수 보고서 활용 사례를 소개해요.

8. 링크: 36kr.com/p/4056040123945860
9. 설명: 검수 보고서 방식의 리뷰를 비교하는 데 참고한 자료예요. “코드를 거의 보지 않는다”는 팀이 직접 밝힌 내용이에요.

작성자: APIYI 기술팀