서론

「AI가 사양을 지키지 않는 코드를 계속 내놓고, 심지어 내가 틀린 것처럼 느끼게 만들었다」

이것은 2026년 5월, Microsoft Copilot(데스크톱 버전)과의 ESP32 개발 세션에서 실제로 일어난 일이다. 할루시네이션(Hallucination)과는 다르다. 사실 오인도 아니다. AI가 논리적으로 보이는 형태로 계속 틀리는 현상이었다.

첫 경험이었기에 기록으로 남겨둔다.

무엇을 만들고 있었나

**커피 스케일(Coffee Scale, ESP32 기반)**의 펌웨어다.

측정 중에는 SD 카드를 건드리지 않고, 측정이 종료된 후에 일괄적으로 CSV 로그를 기록한다. 기록 후에는 ESP.restart()로 리셋한다. SD 카드는 나중에 교체하는 소모품이라는 구조로, 양산과 신뢰성을 최우선으로 설계했다.

당초 로그 파일 이름 관리에는 리셋 횟수를 세는 bootCount를 사용할 계획이었다. 나중에 리셋 횟수가 아니라 저장 성공 횟수로 카운트업하여 파일 이름의 중복을 방지한다.

내가 설계한 플로우

SPIFFS의 쓰기 횟수를 최대한 줄이고 싶었다. 그래도 충분한 수명은 있지만, 불필요한 쓰기는 피하고 싶다. 그리고 화면 하단에 「다음에 저장될 파일 이름」을 항상 표시하고 싶었다.

이 두 가지를 동시에 만족하는 플로우를 생각했다.

리셋 시:
SPIFFS에서 bootCount를 읽어온다
bootCount++ (RAM 상에서만, SPIFFS에는 쓰지 않는다)
...

심플하다. 「저장되었을 때만 카운트가 진행된다」는 제품으로서 자연스러운 추적성(Traceability)이다.

Copilot이 내놓은 코드

이 플로우를 Copilot에게 던진 결과, 생성된 코드는 다음과 같았다.

// 리셋 시
void loadBootCount() {
prefs.begin("boot", false);
...

언뜻 보기에는 맞아 보인다. 하지만 사양을 충족하지 못하고 있다.

무엇이 문제였나

나의 요구사항은 「화면에 다음에 저장될 파일 이름을 표시하는 것」이다.

Copilot의 코드에서는 리셋 직후의 bootCount가 「이전에 저장한 번호」 그대로 남게 된다. 즉, 화면에는 이전 파일 이름이 표시된다.

내가 지적했다.

「그러면 화면 표시가 이전 카운트 값이 된다」

Copilot의 답변은 다음과 같았다.

「저장 전에 카운트업해야 한다」

순서의 문제로 말을 돌렸다. UI 요구사항은 무시된 채로.

추론 고착화의 발생

여기서부터 여러 차례의 충돌이 일어났다.

Copilot은 「일반적인 boot counter는 기동 시에 늘리지 않는다」라는 범용 패턴에 계속 고집했다. 내가 설계한 「리셋 시에 RAM 상에서 카운트업하고, 저장 성공 시에만 SPIFFS에 커밋한다」라는 구조를 몇 번을 지적해도 올바르게 재통합하지 못했다.

특히 현저했던 것은 이 장면이다. 내가 「loadBootCount()에서 bootCount++를 하지 않으면 화면에 이전 파일 이름이 나온다」라고 설명한 후, Copilot은 일단 인정한 것처럼 보였다. 하지만 몇 턴 후에 다시 「loadBootCount()에서 bootCount++를 해서는 안 된다」라며 역주행했다.

일반화 로직에 대한 고집이 재발했다.

이것은 할루시네이션이 아니다. 존재하지 않는 API를 말한 것도, 사실 오인을 한 것도 아니다. 「다수파의 코드 예시」로부터 도출되는 일반론이 제품 고유의 구체적 로직보다 강하게 추론을 지배했다. 이를 **추론 고착화 (Inference Fixation)**라고 부르기로 한다.

가스라이팅 유사 경험

이 과정에서 나는 스스로 깨닫고 있었다.

「내가 틀린 게 아닐까 하고, 가스라이팅(Gaslighting) 당하는 방향으로 끌려간 것도 사실이다. 그래서 반증의 반증의 반증을 반복했다.」

AI에게 악의는 없다. 하지만 자신만만하게 계속 틀리는 성질이 인간 측에 「내가 잘못하고 있는 것이 아닌가」 하는 자기 의구심을 낳는다.

이것은 가스라이팅과 구조가 닮아 있다. 상대에게 의도는 없더라도 결과적으로 판단력이 침식된다.

결국 나를 구한 것은 「실제로 동작하는 코드의 거동」이었다. 실제로 움직이고 있다는 사실은 AI의 일반론보다 강력한 근거가 되었다.

원인의 구조 분석

이번 현상에는 세 가지 요인이 겹쳐 있었다.

① 사후 요구사항의 충돌

UI 표시 요구사항(다음 파일 이름을 화면에 띄우기)을 나중에 추가했다. Copilot의 초기 전제는 저장 로직 중심으로 구축되어 있었기에, 사후 요구사항을 재통합하지 못했다. 처음부터 모든 요구사항을 갖추어 전달했다면 충돌 확률은 낮아졌을지도 모른다.

② AI의 추론 고착화

사후 요구사항이 나온 시점에서, AI는 전제를 업데이트하지 않고 일반화된 로직 (Generalization Logic)에 계속 집착했다. "기동 시에 bootCount를 늘리지 않는 것이 자연스럽다"라는 다수파 패턴이 제품 고유의 구체적인 로직을 덮어써 버렸다.

③ AI의 "자신감"은 정답의 증명이 아니다

Copilot은 오류를 자신 있게 반복했다. 이것이 인간 측의 자기 의심을 유발하는 구조가 되어 있었다.

책임의 소재에 대하여

"AI는 도구이며, 책임은 인간 측에 있다"는 말은 옳다. 하지만 불충분하다고 생각한다.

이번에 일어난 일은 단순한 실수가 아니라, AI가 논리적으로 보이는 형태로 계속 틀리면서 인간의 판단력이 조금씩 침식되어 가는 프로세스였다.

판단력이 침식되고 있는 도중에 인간은 "침식되고 있다"는 사실을 알아차릴 수 없다. 그렇기에 책임의 소재를 고정할 수 없는 순간이 존재한다.

• 사용하기 시작한 시점에서 리스크를 감수할 책임은 발생한다
• 방어책을 강구하더라도 추론 고착화는 일어날 수 있다
• 상호작용 속에서 판단력이 모호해지는 순간이 있다

따라서 "AI를 너무 신뢰하지 마라"는 것만으로는 부족하다.

"세심한 주의를 기울여도, 이런 일이 일어날 수 있다"라는 인식을 계속 유지하는 것.

그것이 지금 할 수 있는 유일하고도 가장 성실한 방어책이라고 생각한다.

요약: 교훈으로 남길 것

• AI는 사후 요구사항을 제대로 재통합하지 못할 때가 있다
• AI의 추론은 다수파의 코드 예시에 편향된다. 예외적으로 옳은 구조를 부정할 때가 있다
• AI의 "자신감"은 정답의 증명이 아니다
• 인간은 AI의 논리에 끌려가 자기 의심에 빠진다
• 반증할 수 있는 인간만이 AI의 오류를 꿰뚫어 볼 수 있다
• 실제로 동작하는 코드의 거동은 가장 강력한 근거가 된다
• 사양(Specification)은 처음에 모두 갖추어 전달함으로써 리스크를 줄일 수 있다

이것은 코딩을 하며 처음으로 경험한 현상이었다. 같은 함정에 빠지는 사람이 줄어들기를 바라며 기록을 남긴다.

2026-05-22 초고

Discussion