생성형 AI (Generative AI)로 구현을 진행하는 기회가 늘어나고 있습니다.

간단한 CRUD뿐만 아니라, 관리 화면이나 프론트 화면까지 AI에게 만들게 하는 것도 드문 일이 아닙니다.

그러던 중, 실제로 마주친 "AI스러운" 버그를 소개합니다.

이번 시스템은 심플합니다.

• 백오피스에서 기사를 작성한다
• 프론트 화면에서 사용자가 기사를 열람한다
• 사용자는 "좋아요!"나 "문의하기"를 할 수 있다
• 관리 화면에서는 기사 목록을 업데이트 일시 순으로 표시한다

또한, 기사에는 다음 정보를 보유하고 있습니다.

• 조회수
• 좋아요 수
• 문의 수

이것들은 사용자 조작에 따라 카운트업 (Count-up) 되는 사양이었습니다.

테스트 중에 다음 조작을 수행했습니다.

• 며칠 전에 게시한 기사를 연다
• 프론트 화면에서 "좋아요!"를 누른다
• 관리 화면의 기사 목록을 확인한다

그러자, 그 기사가 목록의 맨 위로 이동해 있었습니다.

이유는 단순합니다.

** updated_at 이 업데이트되었기** 때문입니다.

AI의 관점에서 보면, 이 구현은 자연스럽습니다.

좋아요 수가 변한다
↓
DB를 UPDATE한다
...

Laravel や Rails, Prisma 등의 ORM (Object-Relational Mapping)에서도, 통상적인 UPDATE를 실행하면 updated_at은 업데이트됩니다.

즉 AI는,

데이터가 업데이트되었다

라는 사실만을 보고 있습니다.

이번에 업데이트된 것은,

• 좋아요 수

뿐입니다.

기사 본문을 업데이트한 것이 아닙니다.

• 제목
• 본문
• 공개 상태
• 카테고리
• 태그

이것들은 무엇 하나 변하지 않았습니다.

즉,

기사의 업데이트

가 아니라,

리액션 정보의 업데이트

입니다.

이 "속성의 차이"를 AI는 판단할 수 없습니다.

사양서에는,

좋아요 수를 업데이트한다

라고 적혀 있었습니다.

하지만,

좋아요 수·조회수·문의 수의 업데이트로는 기사의 업데이트 일시를 변경하지 않는다

라고는 적혀 있지 않았습니다.

인간끼리라면,

"아니, 그건 기사 업데이트가 아니잖아"

라는 대화가 됩니다.

하지만 AI는 그 암묵지 (Implicit knowledge)를 가지고 있지 않습니다.

처음에는,

• 좋아요 수가 1 증가하는 것

만을 확인하고 있었습니다.

하지만 본래 확인했어야 했던 것은 다음 내용입니다.

updated_at
이 변하지 않는 것

• 관리 화면의 정렬 순서가 변하지 않는 것
• "최근 업데이트한 기사"에 표시되지 않는 것
• 업데이트 알림 대상이 되지 않는 것

정상계 (Happy path) 만을 확인하면 이 버그는 놓치게 됩니다.

최근 느끼는 점은,

AI는

무엇을 업데이트할지

는 매우 잘합니다.

반면,

무엇을 업데이트해서는 안 되는지

는 사양에 적지 않으면 판단할 수 없습니다.

최근에는 사양을 작성할 때 다음과 같은 규칙을 명기하도록 하고 있습니다.

・기사 본문을 업데이트했을 경우에만 updated_at 을 업데이트한다
・조회수
・좋아요 수
...

이 한 문장이 있는 것만으로 방지할 수 있는 버그는 의외로 많습니다.

이번 버그는 화려하지 않습니다.

화면은 정상적으로 작동합니다.

좋아요 수도 늘어납니다.

하지만 업무로서 보면, 기사 목록의 정렬 순서가 바뀌어 관리 화면의 의미 자체가 변해버립니다.

생성형 AI로 구현할 경우에는,

"무엇을 업데이트할 것인가"뿐만 아니라, "무엇을 업데이트해서는 안 되는가"까지 사양에 적는다.

이 관점을 갖는 것만으로도 AI가 만들어내는 버그는 상당히 줄어들 수 있다고 느끼고 있습니다.