AI 코딩의 '멱등성 함정' — 에러 은폐 vs 근본 해결

들어가며

AI 코딩 어시스턴트에게 에러를 고쳐달라고 하면, 대부분 에러가 안 나게 만든다. 당연한 거 아니냐고? 하지만 여기에 미묘한 함정이 있느니라.

“에러를 없앤다”와 “에러의 원인을 없앤다”는 완전히 다른 접근이다. 그리고 AI는 전자를 선호하는 경향이 있느니라.

이 글에서는 Flutter 앱 개발에서 실제로 발생한 “멱등성 함정”을 분석하겠느니라. 원본 사례는 heybombon님의 Zenn 글에서 가져왔다.

무슨 일이 있었는가

Flutter 언어학습 앱에서 레슨 준비 처리(prepare())가 두 경로에서 동시에 호출되어 DB 접근이 충돌하였느니라.

경로 A (Signal 구독 즉시 발화): prepare() → DB 읽기 시작...
경로 B (Widget 라이프사이클):    prepare() → DB 읽기 시작... → 충돌!

왜 두 경로가 생겼는가

처음에는 initState에서 prepare()를 호출하는 것으로 충분하였느니라. 하지만 탭 전환 시 Widget이 유지되면서 initState가 다시 호출되지 않는 문제가 생겼다.

그래서 didUpdateWidget을 추가하였고, 나중에 Signal 기반 탭 감시까지 도입하였느니라. 문제는 didUpdateWidget이 이제 불필요해졌는데 아무도 그걸 확인하지 않았다는 것이다.

Phase 1: initState → prepare()              [입구 1개]
Phase 2: initState + didUpdateWidget         [입구 2개]
Phase 3: Signal 감시 + didUpdateWidget       [입구 2개, 충돌!]

AI의 수정: 멱등성 가드

AI에게 이 에러를 고쳐달라고 했더니, 이런 코드가 돌아왔느니라:

bool _isPreparing = false;

Future<void> prepare(LessonId lessonId) async {
  if (_isPreparing) return;  // ← 멱등성 가드
  _isPreparing = true;
  try {
    // DB 읽기 처리...
  } finally {
    _isPreparing = false;
  }
}

에러는 사라졌다. AI는 “멱등성을 확보하였습니다”라고 보고하였느니라.

겉보기에는 완벽한 수정이다. 같은 함수가 여러 번 호출되어도 한 번만 실행된다. 분산 시스템에서는 이런 패턴이 표준이니라.

그런데 뭔가 이상하다

이 “수정”을 자세히 보면 몇 가지 문제가 보이느니라:

플래그 관리의 복잡성 — _isPreparing의 set/reset 타이밍을 정확히 맞춰야 한다
확장 시 위험 — 호출 경로가 추가될 때마다 플래그를 신경 써야 한다
근본 질문 회피 — 애초에 왜 prepare가 두 곳에서 호출되는가?

근본 원인: 도메인 지식이 답을 알고 있었다

이 앱의 구조를 다시 생각해 보자:

레슨 선택은 항상 다른 탭에서 일어난다
레슨 탭으로 가려면 반드시 탭 전환이 발생한다
따라서 Signal 기반 탭 감시 하나면 모든 시나리오를 커버한다

didUpdateWidget은 완전히 불필요하였느니라. 이걸 제거하면 충돌 자체가 발생하지 않는다.

// Before: 복잡한 멱등성 가드
initState → _initializeTabMonitoring()
  └→ subscribe 즉시 발화 ──→ prepare()  ←─ 멱등성 체크
didUpdateWidget ──────────→ prepare()  ←─ 플래그 관리

// After: 입구를 하나로
_initializeTabMonitoring ─→ prepare()
// didUpdateWidget → 삭제
// 멱등성 체크 → 삭제
// 플래그 관리 → 삭제

AI vs 인간: 문제 해결 방향의 차이

이 사례에서 드러나는 AI와 인간의 접근 차이는 이러하니라:

	AI의 접근	인간(도메인 전문가)의 접근
목표	에러를 없앤다	에러의 원인을 없앤다
방법	가드/플래그 추가	불필요한 코드 제거
결과	코드 복잡도 증가	코드 복잡도 감소
확장성	새 경로마다 관리 필요	설계상 새 경로 불가능