AI가 만들어낸 가짜 errno 값들, 유닉스 시스템 콜의 위험한 환각

errno가 뭐고, 왜 이게 중요할까요?

C나 시스템 프로그래밍을 해본 분이라면 errno라는 이름이 익숙할 거예요. 유닉스 계열 시스템에서 시스템 콜(예: open, read, write 같은 OS 호출)이 실패하면, 실패 원인을 숫자로 알려주는 전역 변수예요. 예를 들어 errno가 2면 ENOENT (No such file or directory, 파일 없음), 13이면 EACCES (Permission denied, 권한 없음) 이런 식이죠.

이 errno 값들은 POSIX 표준과 각 운영체제별로 엄격하게 정의된 목록이 있어요. macOS, Linux, FreeBSD, NetBSD가 조금씩 다르고, 같은 숫자라도 의미가 다를 수 있어요. 그래서 시스템 프로그래머는 매뉴얼 페이지의 errno(2)를 거의 외우다시피 하면서 코드를 짜요.

그런데 netmeister.org에 올라온 이 글은 "ChatGPT와 다른 LLM들에게 errno 값을 물어보면 어떤 답이 나오는가"를 실험해 본 흥미로운 결과를 정리했어요. 결론부터 말하면, AI는 errno 값을 자주, 그리고 자신만만하게 틀린다는 거예요.

AI의 errno 환각, 구체적으로 뭐가 문제예요?

글쓴이는 여러 LLM에게 "NetBSD에서 errno 47이 뭐냐", "FreeBSD의 ELOOP는 몇 번이냐" 같은 질문을 던졌어요. 그랬더니 AI는 존재하지도 않는 errno 이름을 만들어내거나, 다른 OS의 값을 섞어서 답하거나, 아예 숫자를 잘못 매핑하는 일이 빈번했어요.

예를 들어 어떤 모델은 "errno 47은 EMULTIHOP"이라고 자신 있게 말했는데, 실제로는 OS마다 47번이 가리키는 게 다르고, 어떤 OS에서는 그 번호 자체가 정의돼 있지도 않아요. 더 심각한 건, AI가 그럴듯한 이름을 새로 지어내는 경우도 있었다는 거예요. "ENOSUCHRESOURCE" 같이 들어본 적도 없는 errno를 만들어내고는, 마치 표준인 양 설명을 덧붙이는 거죠.

왜 이런 일이 벌어질까요?

LLM의 작동 원리를 생각해 보면 이해가 쉬워요. LLM은 "다음에 올 토큰의 확률"을 예측하는 모델이에요. errno 이름들은 다 비슷하게 생겼잖아요. E로 시작하고, 대문자 알파벳들의 조합으로 끝나죠. 그러다 보니 모델 입장에서는 "errno 47은 E___"라는 빈칸을 채울 때, 통계적으로 그럴듯한 토큰을 뱉어내는 거예요. 사실관계는 모르고요.

게다가 errno 값은 OS, 버전, 아키텍처마다 다르다는 특성 때문에 학습 데이터에 모순된 정보가 섞여 있을 가능성이 커요. Linux의 errno.h, BSD의 errno.h, macOS의 sys/errno.h가 다 약간씩 다르거든요. AI는 이걸 구분 못 하고 짬뽕해서 답을 내놓는 거죠.

이게 단순히 errno에만 국한된 문제가 아니에요. 시스템 콜의 인자 순서, 라이브러리 함수의 반환값, 컴파일러 플래그, 커널 옵션 등 "OS에 따라 미묘하게 다른 모든 정보"에서 LLM은 비슷한 종류의 환각을 일으켜요. 글쓴이가 errno로 실험한 건 빙산의 일각이고, 사실상 시스템 프로그래밍 영역 전반의 문제를 드러낸 거죠.

비슷한 사례들과 업계 흐름

이런 "AI가 자신만만하게 틀린 답을 내놓는 현상"을 할루시네이션(hallucination, 환각)이라고 부르는데, 이미 여러 분야에서 보고되고 있어요. 법조계에서는 ChatGPT가 존재하지 않는 판례를 만들어내서 변호사가 징계받은 사건이 있었고, 의료계에서는 가짜 약품 상호작용을 답해서 위험을 초래한 사례도 있어요.

프로그래밍 영역에서도 마찬가지예요. "존재하지 않는 npm 패키지 이름"을 추천해서, 악성 사용자가 그 이름으로 실제 패키지를 만들어 공격하는 slopsquatting (AI 추천을 노린 타이포스쿼팅의 일종) 같은 공격 기법까지 등장했어요. 즉, AI의 환각이 보안 취약점으로 직결되고 있는 거예요.

GitHub Copilot, Cursor, Claude Code 같은 코딩 도구들도 비슷한 문제에서 자유롭지 않아요. 다만 이들 도구는 실제 코드베이스나 문서를 참조(RAG, Retrieval Augmented Generation)하는 방식으로 환각을 줄이려고 노력하고 있고, 단순 채팅 모드보다는 훨씬 정확도가 높아진 편이에요.

한국 개발자에게 주는 시사점

첫째, AI의 답을 무조건 믿지 말고 항상 1차 자료를 확인하는 습관이 필요해요. 특히 시스템 프로그래밍, 커널, 임베디드, 보안 같은 영역에서는 errno 같은 미세한 숫자 하나가 버그의 원인이 될 수 있어요. man 페이지, RFC, 공식 문서를 직접 보는 습관을 잃지 마세요.

둘째, AI에게 질문할 때는 컨텍스트를 풍부하게 주는 게 좋아요. "errno 47이 뭐냐"가 아니라 "NetBSD 10.0의 /usr/include/sys/errno.h 기준으로 errno 47의 정의가 뭐냐"라고 물어보면 훨씬 정확한 답을 얻을 수 있어요. 더 좋은 건 그냥 그 헤더 파일을 직접 열어보는 거고요.

셋째, AI 코딩 도구를 쓸 때는 "이상하게 자신만만한 답"을 경계하세요. AI가 "이 함수는 이렇게 동작합니다"라고 단호하게 말할수록 오히려 검증이 필요해요. 진짜 잘 모르는 영역에서는 모델이 더 자신 있게 답하는 경향이 있거든요. 이 패턴을 알고 있으면 디버깅 시간을 많이 줄일 수 있어요.

마무리

AI는 강력한 도구지만, "플랫폼 종속적이고 표준이 갈라진 영역"에서는 특히 신중하게 검증해야 한다는 걸 errno 사례가 잘 보여줘요. 빠르게 답을 받는 편리함과, 그 답이 진짜인지 확인하는 번거로움 사이의 균형을 잘 잡는 게 요즘 개발자의 새로운 역량인 것 같아요.

여러분은 AI가 자신 있게 틀린 답을 내놓아서 디버깅에 시간을 허비한 경험이 있나요? 어떤 영역에서 AI를 가장 신뢰하지 않게 됐는지 궁금해요.