LLM이 생성하는 '존재하지 않는 API/라이브러리'를 방지하는 프롬프트 엔지니어링 및 검증 자동화 실천 방법

LLM(대규모 언어 모델)을 코드 생성이나 기술 조사에 활용할 때, 겉보기에는 정상적으로 작동할 것 같은 '존재하지 않는 API', '가상의 라이브러리', '폐지된 메서드'가 그럴듯하게 출력되는 현상(환각, Hallucination)에 직면하는 경우가 있습니다. 이를 그대로 믿고 구현을 진행하면 빌드 오류를 해결하는 데 시간을 낭비하거나, 보안 취약점이 있는 미검증 패키지를 잘못 도입할 위험이 발생합니다.

• LLM이 가상의 API나 라이브러리를 생성해내는 기술적 배경

• 환각 현상을 억제하기 위한 프롬프트 설계 패턴

• 생성된 코드나 라이브러리의 존재를 자동으로 검증하는 메커니즘 구현 예시

• 실무에서 사용할 수 있는 'AI 생성 코드 검증 체크리스트'

• 개발 업무에서 GitHub Copilot, ChatGPT, Claude 등의 코드 생성 AI를 이용하는 엔지니어

• AI가 제안한 라이브러리나 API의 타당성을 효율적으로 검증하고 싶은 개발 리더

• 사전 지식: 기본적인 Python 실행 환경, API 및 패키지 관리(pip 등) 기초 지식

LLM이 가상의 정보를 출력하는 주된 원인은 그 작동 방식에 있습니다.

• 확률적 단어 예측 (Next-Token Prediction)
  LLM은 '다음에 이어질 확률이 가장 높은 단어'를 순서대로 출력할 뿐, 출력 내용의 진위 여부를 실시간으로 검증하는 것이 아닙니다. 그럴듯한 명명 규칙(예: boto3.client('s3').download_file_to_stream과 같이 있어 보이지만 존재하지 않는 메서드)을 확률적으로 합성해낼 수 있습니다.
• 학습 데이터의 컷오프와 정보의 퇴색
  LLM의 학습 데이터는 특정 시점에서 컷오프됩니다. 그 이후에 폐지된 API나 새로 추가된 라이브러리의 사양을 정확하게 파악하지 못하고, 오래된 정보와 새로운 정보를 혼동하여 출력할 수 있습니다.
• '모른다'고 말하지 못하는 편향
  지시(프롬프트)에 대해 어떤 답변이라도 하려고 하는 성질이 있기 때문에, 적절한 제약 조건이 없을 경우 존재하지 않는 라이브러리를 그 자리에서 '창작'하여 답변을 채워 넣게 됩니다.

프롬프트에 명확한 제약 조건과 역할을 부여함으로써 가상의 API 생성을 일정 부분 억제할 수 있습니다. 아래에 '나쁜 예시'와 '좋은 예시'를 보여드립니다.

Python으로 PDF에서 텍스트를 추출하고, 특정 키워드로 필터링하는 코드를 작성해 주세요. 가능한 한 편리한 외부 라이브러리를 사용해 주세요.

문제점: 자유도가 너무 높아 AI가 '편리하지만 존재하지 않는 가상의 PDF 처리 라이브러리'를 창작하여 제안할 가능성이 높습니다.

당신은 신뢰성을 최우선으로 하는 Python 시니어 엔지니어입니다.

Python으로 PDF에서 텍스트를 추출하는 코드를 작성해 주세요.

• 사용하는 외부 라이브러리는 PyPI에서 널리 사용되는 실적 있는 것에 한정해 주세요 (예: pypdf 또는 pdfplumber).
• 존재 여부가 불확실한 서드파티 라이브러리나 자체 래퍼 라이브러리는 절대 제안하지 마세요.
• 사용하는 메서드나 속성은 최신 공식 문서에서 권장하는 것에 한정하고, 비권장(Deprecated)된 것은 피해주세요.
• 만약 특정 처리를 구현하는 표준적인 API나 라이브러리가 불분명한 경우, 가상의 코드를 생성하지 말고 '해당하는 표준 라이브러리를 특정할 수 없었습니다'라고 답변해 주세요.

AI가 제안한 외부 패키지가 실제로 PyPI(Python Package Index)에 존재하는지 여부를 Python 스크립트로 자동 검증하는 메커니즘을 구축합니다. 이를 통해 코드를 실행하기 전에 패키지의 존재 유무를 확인할 수 있습니다.

아래는 지정된 패키 이름이 PyPI에 등록되어 있는지 검증하는 간편한 스크립트입니다.

import requests
import sys
def verify_pypi_package(package_name: str) -> bool:
...

주의: 이 스크립트는 PyPI의 공개 API를 사용합니다. 단시간에 대량의 요청을 전송할 경우 레이트 제한에 도달할 수 있으므로, 실제 운영 환경이나 CI/CD에 통합할 때는 적절한 재시도 처리나 캐싱 메커니즘을 고려해야 합니다.

AI가 생성한 코드를 실제 프로젝트에 병합하기 전에, 다음 체크리스트를 사용하여 리뷰하는 것을 권장합니다.

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

1. 패키지 실재성 | 제안된 서드파티 패키지가 PyPI나 npm 등의 공식 레지스트리에 실제로 존재하는가. | [ ] |
2. 메서드・속성 존재 | 사용되는 API나 메서드가 공식 문서의 최신 버전에 기재되어 있는가. | [ ] |
3. 비권장 기능 배제 | 생성된 코드에 이미 비권장(Deprecated)된 오래된 API가 포함되어 있지 않은가. | [ ] |
4. 보안・취약점 | 제안된 패키지의 유지보수 상황(최종 업데이트일, 스타 수, 미해결 취약점 정보)에 문제가 없는가. | [ ] |
5. 로컬 환경 동작 확인 | 격리된 샌드박스 환경(Docker 등)에서 실제로 코드를 실행하여 임포트 에러나 런타임 에러가 발생하지 않는가. | [ ] |

공식 문서를 '정답'으로 간주할 것

LLM의 출력은 어디까지나 '초안'이나 '아이디어 도출'로 취급하고, 최종적인 API 사양이나 파라미터 지정 방법은 반드시 각 기술의 공식 문서(최신 버전)를 참조하여 검증을 거쳐야 합니다. -
의존 관계의 안이한 추가를 피할 것

AI가 '편리하다'고 제안한 것을 그대로 requirements.txt나 package.json에 추가하면, 공급망 공격(Supply Chain Attack)의 위험이나 프로젝트 의존성 비대화(배포 크기 증가)를 초래합니다. 표준 라이브러리로 대체 가능한지, 또는 이미 프로젝트 내에 도입된 라이브러리로 구현할 수 없는지를 먼저 검토해야 합니다. -
RAG (검색 확장 생성) 활용 검토

사내 고유 API나 최신 라이브러리 사양에 대해 AI에게 코드 생성을 요청하고 싶다면, 프롬프트에 최신 API 레퍼런스(Markdown 또는 JSON 형식)를 컨텍스트로 직접 주입하는 (RAG 또는 컨텍스트 주입) 방식이 유효합니다.

AI를 통한 코드 생성은 개발 효율을 크게 향상시키지만, 환각(Hallucination)으로 인한 '존재하지 않는 API나 라이브러리 생성'은 피할 수 없는 과제입니다. 프롬프트에서의 제약 정의, 외부 레지스트리 API를 이용한 자동 검증, 그리고 개발 프로세스 내의 체크리스트 운영을 결합함으로써 안전하고 효율적으로 AI의 이점을 누릴 수 있습니다.