AI의 답변이 신뢰할 만한지, 특히 production 코드에 대해 어떻게 판단하나요?

Question

Accepted Answer

AI의 답변을 **박식하지만 믿을 수 없는 동료가 자신 있게 내놓은 초안**으로 다루세요: 유용하고 자주 맞지만, 그 자체만으로 권위 있는 적은 없습니다. 신뢰는 출력이 얼마나 설득력 있게 들리는가가 아니라 *검증*에서 옵니다.

## 핵심 사고방식

**자신감은 정확성과 무관합니다.** LLM은 사실이든 아니든 유창한 텍스트를 생성합니다(사실 저장소가 아니라 다음 토큰 예측기입니다). 지어낸 API와 진짜 API는 똑같이 읽힙니다. 따라서 어조로 신뢰를 판단할 수 없고, 오직 확인할 수 있는 것으로만 판단해야 합니다.

## 실용적 체크리스트

- **실행하라.** 코드의 경우 가장 강력한 신호는 실행입니다: 테스트, 타입 검사기, 린터, 컴파일러. 실제 테스트 스위트를 통과하는 코드는 그저 맞아 보이는 코드보다 훨씬 신뢰할 수 있습니다.
- **지어낸 API를 확인하라.** 모든 함수, 메서드, 플래그, import가 실제로 존재하는지 — 기억이 아니라 문서나 설치된 버전에서 — 검증하세요. 지어냈지만 그럴듯한 API가 대표적인 실패입니다.
- **권위 있는 출처와 대조하라.** 주장을 공식 문서, 표준, 또는 소스 코드와 교차 확인하세요 — 모델 자신의 재진술이 아니라.
- **엣지 케이스와 보안을 따져보라.** null/빈 입력, 동시성, 오류 경로, injection, authz. AI는 흔히 happy path만 처리하고 위험한 구석을 빠뜨립니다.
- **확인할 수 있는 것을 선호하라.** 맹목적으로 믿어야 하는 영리하지만 불투명한 방식보다, 테스트하거나 찾아볼 수 있는 접근을 택하세요.
- **중요 경로에는 사람 검토를 요구하라.** 인증, 결제, 데이터 삭제, 마이그레이션, 인프라 — 답변이 아무리 좋아 보여도 시스템을 이해하는 사람이 승인해야 합니다.

## 빠른 규칙

```text
검증 가능 + 검증함       → 신뢰
검증 가능 + 아직 미확인  → 사용 전 검증
검증 불가능             → 의존하지 말 것
```

## 왜 중요한가

production에서는 *맞아 보이는* 틀린 답이 명백히 망가진 답보다 위험합니다 — 몰래 통과하기 때문입니다. AI가 더 많은 코드를 작성할수록 병목은 *생성*에서 *검증*으로 옮겨갑니다. 시니어의 판단력은 바로 이것입니다: 유창함은 증거가 아니며, **모델의 자신감은 정확성에 대해 아무 정보도 주지 않는다**는 것, 그리고 중요한 무엇이든 신뢰는 테스트와 출처와 사람의 검토를 통해 얻어야 한다는 것을 아는 것. 끝까지 믿을 만한 엔지니어는 믿는 대신 검증하는 사람입니다.