AI 제안의 앵커링을 줄이는 반증 설계

1. ‘AI가 이미 답을 냈는데 왜 다시 생각해야 할까?’ 첫 제안이 판단의 닻이 되는 순간

코드 생성 도구가 구현 초안, 원인 분석, 리팩터링 방향을 먼저 보여 주는 일은 이제 일상적인 개발 흐름이 됐다. 이 속도는 분명한 이점이다. 다만 첫 제안이 문제를 이해하기 위한 하나의 가설이 아니라, 팀이 이후 모든 선택지를 비교하는 기준점이 되는 순간 위험이 생긴다. 리뷰어는 “다른 방법은 무엇인가?”보다 “이 답의 어느 줄을 고칠까?”를 먼저 묻게 되고, 설계 토론은 처음 제시된 구조의 주변부에서만 일어난다.

심리학에서 앵커링은 처음 접한 정보가 이후 판단에 과도하게 영향을 줄 수 있는 현상을 가리킨다. 고전 연구는 불확실한 수량 판단에서 임의의 출발값조차 추정에 영향을 줄 수 있음을 보였다. 이를 AI 코딩 도구에 그대로 등치할 수는 없다. 실제 개발은 단순한 수치 추정보다 훨씬 복잡하며, AI의 첫 답이 항상 나쁜 앵커라는 직접적 증거도 아직 충분하지 않다. 그럼에도 ‘먼저 제시된 답이 문제 정의와 탐색 범위를 좁힐 수 있다’는 위험 가설은 운영 절차로 다룰 가치가 있다.

Google Research가 소프트웨어 엔지니어 76명을 대상으로 수행한 과제 기반 연구에서는 대화형 AI 사용 중 자동화 안일성(automation complacency)의 징후와, 과제 진행에 따라 AI 의존이 늘어나는 패턴을 보고했다. 이 결과는 모든 팀이 AI를 과신한다는 뜻이 아니다. 오히려 신뢰와 실제 검증 행동을 같은 것으로 가정하면 안 된다는 경고다. 제안이 그럴듯하고 테스트가 초록색일수록, 문제의 전제·대안·실패 경계를 독립적으로 확인할 절차가 필요하다.

핵심은 AI 제안을 금지하거나, 모든 변경을 백지에서 다시 설계하자는 것이 아니다. 팀이 빠른 초안을 활용하면서도 첫 화면에 보인 해법을 유일한 기준으로 삼지 않게 만드는 것이다. 다음 단계는 신뢰의 크기를 선언하는 대신, 신뢰를 보정할 수 있는 정보 흐름을 만드는 데 있다.

2. ‘답을 지우지 않고도 어떻게 앵커를 약화할까?’ 문제·대안·반증을 분리하는 결정 흐름

앵커를 줄이는 가장 실용적인 방법은 AI에게 답을 늦게 받는 것이 아니라, 답을 받기 전후의 작업을 분리하는 것이다. 먼저 저자는 문제를 한 문장으로 적는다. 어떤 사용자·운영 계약이 깨졌는지, 바꾸지 말아야 할 경계는 무엇인지, 성공과 실패를 어떤 관측으로 구분할지를 적는다. 이 단계에서는 해결책 이름을 쓰지 않는다. ‘Redis로 바꾼다’가 아니라 ‘읽기 경로에서 오래된 권한 상태를 허용하지 않는다’처럼 계약을 적는 편이 좋다.

그다음 AI 제안은 후보 A로 저장한다. 동시에 사람이 독립적으로 후보 B를 만들거나, 다른 프롬프트·다른 모델·다른 담당자에게 동일한 문제 정의만 전달해 후보 B와 C를 얻는다. 이때 중요한 것은 후보 수를 늘리는 일이 아니다. 서로 다른 실패 가정을 가진 후보가 최소 하나는 있어야 한다. 예를 들어 재시도 큐를 추가하는 해법과 멱등 키로 중복을 흡수하는 해법은 같은 장애를 다뤄도 비용·지연·운영 복잡도가 다르다.

[문제 계약] ──> [AI 후보 A] ─┐
                                ├─> [대안 비교] ─> [반증 탐색] ─> [선택 / 보류]
[독립 후보 B·C] ──────────────┘                       │
                                                       └── 실패 가설이 맞으면 후보 단계로 복귀

반증 단계는 “이 후보가 틀렸다고 가정하면 가장 먼저 깨질 약속은 무엇인가?”를 묻는다. API 호환성, 권한, 데이터 중복, 동시성, 관측성, 되돌림 가능성처럼 변경의 성격에 맞는 경계를 하나 이상 고른다. 생성 도구에게도 단순한 구현 요청 대신 “이 설계를 반대할 가장 강한 근거 세 가지와, 그 반대가 성립하는 입력 조건을 제시해 달라”고 요구할 수 있다. 모델의 반론 역시 정답이 아니라 검증 후보로 취급해야 한다.

그렇다면 속도가 사라지지 않을까요? 비교 단계를 모든 저위험 변경에 동일하게 적용하면 그럴 수 있다. 그래서 위험에 비례해 깊이를 정한다. 문구 수정이나 격리된 내부 리팩터링은 문제 계약과 자동 테스트만으로 충분할 수 있다. 반면 권한, 금액, 데이터 삭제, 외부 API 계약, 병렬 실행처럼 되돌림 비용이 큰 변경은 독립 후보와 명시적 반증을 요구한다. 판단 절차의 목표는 생각을 많이 하는 것이 아니라, 잘못된 확신이 비가역적 변경으로 바로 이어지는 경로를 끊는 것이다.

3. ‘반증을 찾았는데도 왜 제안이 통과할까?’ 반대 근거를 승인 흐름에 연결하는 법

반증은 회의에서 한 번 말하고 사라지는 의견이 아니다. 승인 조건과 연결되지 않으면 첫 제안의 관성이 결국 이긴다. 다음 표처럼 각 제안을 같은 질문으로 비교하면, “AI가 추천했다”는 사실은 근거 목록 중 하나로만 남고 선택 그 자체가 되지 않는다.

▲ 반증은 최종 승인에 붙는 경고 문구가 아니다. 대안 비교로 되돌아가게 만드는 운영 경로여야 한다.

이 표를 길고 형식적인 PR 템플릿으로 만들 필요는 없다. 고위험 변경에만 네 줄을 남겨도 충분하다. 예를 들어 ‘후보 A는 AI가 제안한 캐시 무효화 방식, 후보 B는 버전 토큰 방식’, ‘A의 반증은 순서가 뒤바뀐 이벤트에서 오래된 값이 되살아나는지’, ‘이 조건이 재현되면 B 또는 보류로 돌아간다’처럼 간결하게 적는다. 중요한 것은 최종 선택의 이유뿐 아니라, 무엇이 선택을 뒤집을 수 있었는지도 남기는 일이다.

Google의 개발자 AI 신뢰 연구는 신뢰가 사용량과 연결되지만, 신뢰를 키우려면 도구의 한계와 사용 맥락을 함께 다뤄야 한다고 제안한다. 따라서 조직의 목표를 “AI 수용률을 높이자”로 두면 위험하다. 수용률은 빠른 병합을 보여 줄 수 있지만, 비교를 생략했는지·반증을 무시했는지·나중에 다른 경로로 결함이 발견됐는지는 설명하지 못한다. 더 유용한 지표는 AI 후보가 반증으로 수정되거나 철회된 비율, 반증 단계에서 잡힌 고위험 결함, 병합 후 결함이 빠져나간 경계, 그리고 저자가 선택 이유를 재현할 수 있는지다.

4. ‘AI에게 반대 의견까지 시키면 안전해질까?’ 가짜 반대와 과도한 절차의 안티패턴

첫 번째 안티패턴은 같은 대화 안에서 모델에게 찬성·반대를 연속으로 시켜 놓고 독립 검토라고 부르는 것이다. 이 방식은 유용한 질문을 만들 수 있지만, 같은 맥락과 같은 초기 답이 여전히 이후 답을 제한할 수 있다. 독립성이 꼭 다른 사람이나 다른 모델을 뜻하지는 않는다. 최소한 원래 답을 보지 않은 상태에서 문제 계약과 실패 조건을 먼저 쓰고, 그 뒤에 후보를 비교해야 한다.

두 번째는 반대 의견을 무조건 같은 무게로 취급하는 것이다. 모든 변경에는 그럴듯한 우려를 무한히 만들 수 있다. 반증은 ‘싫다’가 아니라, 관측 가능하고 변경의 계약과 연결된 실패 가설이어야 한다. 재현 조건·영향 범위·되돌림 비용이 없는 반대는 기록하되 배포 차단 조건으로 승격하지 않는다. 그렇지 않으면 팀은 앵커링을 피하려다 결정 마비에 빠진다.

세 번째는 작은 변경까지 대안 세 개와 긴 회의를 강제하는 일이다. 판단 절차는 리스크를 줄이는 만큼만 비용을 써야 한다. 저위험 변경은 짧은 문제 계약과 테스트 확인으로 통과시키고, 고위험 변경만 독립 후보·반증·롤백을 요구해야 한다. 차이를 가르는 기준은 코드 줄 수가 아니라 고객 약속의 손상 가능성과 되돌림 난이도다.

5. ‘다음 스프린트부터 어떻게 시작할까?’ AI 제안 신뢰 보정의 3단계 도입법

처음부터 AI 제안의 품질을 점수화하려 들 필요는 없다. 먼저 팀이 어떤 상황에서 첫 답에 머물렀는지, 어떤 반증이 실제로 설계를 바꿨는지, 어느 경계의 결함이 병합 뒤에 발견됐는지를 살피면 된다. 이 기록은 모델을 감시하거나 개인의 판단을 평가하기 위한 자료가 아니다. 도구의 제안과 사람의 검토가 어디에서 서로를 보완하지 못했는지 찾아내는 운영 데이터다.

AI는 좋은 초안을 빠르게 만들 수 있다. 그러나 초안이 빠르다는 이유만으로 그 초안이 팀의 탐색 공간을 정의하게 해서는 안 된다. 문제 계약을 먼저 쓰고, 독립 대안을 하나 만들고, 선택을 뒤집을 반증 조건을 남기는 작은 마찰이 오히려 AI의 속도를 안전한 판단으로 바꾼다. 신뢰할 수 있는 팀은 AI를 덜 쓰는 팀이 아니라, AI가 먼저 말한 답도 필요하면 기꺼이 되돌릴 수 있는 팀이다.

AI 시대의 판단력은 첫 답을 거부하는 데 있지 않다. 첫 답이 틀렸을 때 팀이 더 나은 경로로 돌아갈 수 있게 만드는 데 있다.

공식 참고 자료

• Google Research: Take it, Leave it, or Fix it — Measuring Productivity and Trust in Human-AI Collaboration
• Google Research: Fostering Developers’ Trust in AI
• DORA: 2025 State of AI-assisted Software Development
• Tversky & Kahneman: Judgment under Uncertainty — Heuristics and Biases