수탁 개발의 PM을 하다 보면, 운영 환경 결함 조사와 고객용 보고서 작성이 빈번하게 발생합니다.

"이거, AI가 '원인은 이것입니다'까지 뽑아줄 수 있다면 최고겠지"라고 생각하지 않으시나요? 저도 그렇게 생각했습니다.

하지만 결함 티켓을 그대로 AI에게 붙여넣고 "원인을 알려줘"라고만 하면, AI가 기분 좋게 '그럴싸한 거짓말'을 내뱉습니다. 내용이 얕고, 가끔 틀리며, 무엇보다 고객에게 제출할 수 없습니다.

여러 가지 시도 끝에 내린 결론은 이것이었습니다.

AI에게 "형식(型)"을 전달하면, AI는 멋대로 폭주하지 않고 올바른 순서로 진정한 원인(Root Cause)까지 안내해 줍니다.

이번에는 그 형식(결함 조사를 9단계로 나눈 워크플로우)을 전달했을 때, AI가 실제로 어떻게 움직이는지를 특정 결함 사례를 통해 소개하겠습니다.

마지막에 GitHub에 전부 공개해 두었으므로, 복사해서 바로 사용할 수 있습니다.

관련 기사도 괜찮으시다면 읽어주세요 🙇

"결함 티켓을 붙여넣을 테니 원인을 알려줘" —— 이 프롬프트는 편하지만, 형식이 없으면 AI는 다음과 같이 폭주합니다.

즉, 문제는 AI의 똑똑함이 아니라 절차(Procedure)가 없다는 것입니다.

그래서 AI에게 "똑똑하게 생각해"가 아니라 **"이 순서대로, 이 게이트(Gate)를 통과하지 않으면 다음으로 넘어가지 마"**라는 형식을 전달합니다.

(저의 근본적인 생각은 **"품질 게이트(Quality Gate)를 시스템으로서 기능하게 한다. 인간의 주의력에 의존하지 않는다"**입니다)

스킬의 내용은 심플합니다. 조사를 9단계로 나누고, 각 단계에 **Exit Gate(이를 충족할 때까지 다음으로 진행할 수 없음)**를 배치했을 뿐입니다.

포인트는 각 단계에서 AI가 스스로 다음 행동을 하는 것입니다. 구체적으로는 다음과 같이 움직입니다.

'똑똑한 AI'라기보다 '절차를 지키는 AI'입니다. 그리고 이 "절차를 지키는 것"이 실용적인 품질을 만드는 데 가장 효과적입니다.

그럼 정말 이렇게 움직이는지, 실례를 통해 보겠습니다.

지금부터는 어떤 결함 조사에서 AI가 실제로 어떻게 행동했는지를 살펴보겠습니다.

(주인공은 버그가 아니라 AI의 움직임입니다. 또한 제품명, 회사명, 관계자, 실제 코드는 모두 숨기고 기술적 현상만을 범용화했습니다)

다룬 결함은 이것입니다 👇

두 개의 영상을 나란히 놓고 비교하는 화면에서,

Chromebook에서만 영상이 "2회 연속"으로 재생된다. Mac이나 Windows의 Edge에서도 아주 가끔 발생한다.

수 주간, 여러 명이 달라붙어 재현에 고전하고 있었다.

처음에 내가 한 일은 AI에게 상황을 전달하는 것이었다.

일반적인 AI라면 즉시 "원인은 이것입니다"라고 말할 법한 상황이지만, 형식을 전달받은 AI는 먼저 확인부터 시작했다. "누구를 위한 보고서인가", "사용 중인 라이브러리는 무엇인가", "기존의 조사 결과가 있는가".

원인을 찾기 전에 토대를 다지러 온 것이다. 사소해 보이지만 이 과정을 건너뛰지 않는 것이 효과적이다.

나는 다음과 같은 가설을 세우고 있었다.

"이거, Chromebook 특유의 영상 재생 라이브러리(HLS 계열) 버그겠지. 라이브러리 측의 기지(Known) 문제를 찾아봐."

일반적인 AI라면 "그렇군요! 찾아보겠습니다!"라며 나에게 동조했을 상황이었다.

하지만 타입을 전달받은 AI는 video.js / hls.js 등의 GitHub Issue를 횡단 조사한 끝에, 저의 가설을 명확히 부정했습니다.

"'Chromebook에서 2번 재생된다'는 딱 들어맞는 기지(Known) 버그는 존재하지 않습니다. Chromebook + HLS의 기지 문제는 '재생되지 않음/멈춤/종횡비(Aspect Ratio)' 계열뿐이며, '2번 재생' 계열은 나타나지 않습니다.

당신의 예상과는 다른 견해입니다."

발주자(즉, 저)의 선입견을 AI가 근거를 바탕으로 바로잡아 주었습니다. 이것이 정말 효과적이었습니다.

만약 AI가 저에게 동조하여 "환경 특유의 버그군요"라며 진행했다면, 라이브러리 업데이트만 하고 재발하는 루프에 빠졌을 것입니다.

가설이 무너진 후, AI는 코드를 추적하여 진정한 원인(True Cause)으로 내려갔습니다 (파일 + 행 번호 포함). 범인은 훨씬 더 보편적인 것이었습니다.

브라우저의 HTMLMediaElement.play()

는 Chrome 50 이후 **Promise를 반환하는 비동기 처리 (Asynchronous processing)**로, 그 해결 전에 pause() / seek / load()를 호출하면 reject 됩니다.

Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause()

그리고 코드에는 "재생에 실패하면 1초 후 다시 시도한다"는 재시도(Retry) 로직이, **그 누구에게도 취소되지 않는 "고아 setTimeout (Orphan setTimeout)"**으로서 심어져 있었습니다.

// ❌ 문제의 패턴 (간략화된 이미지)
function tryPlayWithRetry(video) {
video.play().catch(() => {
...

사용자가 일시 정지한 후나 재생 종료 후에도 이 고아 타이머가 살아남아 환상의 play() (phantom play)를 실행 → 2번 재생. 이것이 정체였습니다.

이 부분이 AI의 설명 중 가장 납득이 갔던 대목입니다.

"Chromebook은 하드웨어(디코더) 성능이 낮기 때문에, seek 중에 play()가 AbortError로 거부되기 쉽습니다. 그래서 '실패 → 재시도' 경로로 들어가기 쉬우며, 잠재 버그가 현상화되었을 뿐입니다."

Chromebook은 '원인'이 아니라, 원래 있던 경합 버그(Race condition bug)를 "드러내는" 느린 환경이었던 것입니다.

「환경 특유의 버그」라고 생각했던 것이, 사실은 환경에 의해 드러났을 뿐인 잠재 버그였다——이러한 분류(Classification)를 AI가 해냈습니다.

게다가 AI는 해당 파일에 과거의 수정 코멘트가 2곳 남아 있는 것을 찾아냈습니다.

같은 곳을 두 번 고쳤는데도 재발했다는 것은 = **대증요법(Symptomatic treatment)으로는 막을 수 없는 구조적 버그(Structural bug)**라는 무엇보다 확실한 신호입니다. 파일과 라인까지 내려갔기에 포착할 수 있었던 증거입니다.

저는 엔지니어가 아니라 PM이기에 AI에게 이렇게 물었습니다.

"네가 수정 코드를 작성해 주면, 엔지니어는 그걸 교체하기만 하면 되는 거 아냐?"

보통이라면 "좋습니다!"라고 단정 지어 말할 법한 상황이었습니다.

하지만 AI의 대답은 **"하지 않는 것이 좋습니다"**였습니다. 이유는 (1) 해당 코드는 실기기에서 검증되지 않았고, (2) 과거 두 번이나 제대로 고치지 못한 복잡한 부분이며, (3) 모든 상호작용(Interaction)을 완전히 파악하지 못했기 때문입니다. 따라서 단순 교체가 아니라, 우선순위가 포함된 수정 방침 + 실기기 검증 절차를 엔지니어에게 전달하는 형식을 취해야 한다고 했습니다.

제가 항상 소중히 여기는 원칙 그대로였습니다.

「AI의 '출력(Output)'을 검증하는 것만으로는 부족하다. AI의 '행동(Process)'을 검증하라."

AI 스스로가 "자신의 출력을 맹신하지 마라"라고 말했습니다. 여기서 '이 녀석은 신뢰해도 되겠다'라고 생각했습니다.

조사가 끝나면 AI는 마지막으로 **1개 파일로 완결되는 HTML 리포트(표준 13페이지)**를 생성합니다.
다음은 GitHub에 공개되어 있는 **익명 샘플(예제: CSV 내보내기가 1,000건에서 끊기는 결함)**의 실물입니다.

원인을 "도표"로 설명 (As-Is 시퀀스 다이어그램) —— 어디서 무엇이 일어나고 있는지를 문장이 아닌 도표로 보여줍니다.

고객의 예상 질문에 선제 대응 (Q&A 표) —— 보고회에서 나올 질문을 사전에 차단합니다.

은근히 효과적인 것이 용어집 페이지인데, "Promise"나 "경합 상태 (Race condition)" 등을 고객용 용어로 바꾸어 두면 보고회에서 설명이 끊기지 않습니다.

※ 샘플 예제로 「CSV 내보내기 (CSV export)」를 사용한 이유는 실제 프로젝트의 결함을 그대로 공개할 수 없기 때문입니다. 기술적 현상만을 범용적인 예시로 교체하여 익명화했습니다 (이 기사의 영상 속 버그 이야기 역시 같은 이유로 제품명, 회사명, 실제 파일을 숨겼습니다).

• 「Chromebook 고유의 버그입니다」라는 말에서 조사가 멈춤

• 3번째 패치에서 다시 재발함

• 고객에게 "race condition"을 그대로 던져서 회의가 중단됨

• 발주자의 선입견 (Chromebook 고유의 라이브러리 버그)을 AI가 조기에 기각 - 진인 (True cause: play() Promise 경합 ＋ 고아 setTimeout)까지 file/line 정보와 함께 도달 - 「왜 Chromebook에서만 발생하는가」, 「과거의 수정 흔적」까지 설명

• 실기(Actual device)에서의 검증 절차 포함 - 고객도 읽을 수 있는 용어집이 포함된 리포트

「환경 의존성 때문에 아무도 재현할 수 없다」며 멈춰 있던 안건이, AI에게 형식을 전달했더니 반나절 만에 전망이 밝아졌다.

게다가, 검증이라는 "인간이 해야 할 일"은 제대로 남겨준다. 이 점이 가장 좋았던 부분이다.

AI는 제대로 형식을 전달하면 결함의 진인 특정부터 고객용 리포트 작성까지 맡길 수 있습니다.

단, 통째로 맡기는 것은 안 되며, 「절차와 게이트(Gate)」를 구조로 갖추는 것이 요령입니다 (품질 게이트는 인간의 주의력이 아니라 구조로 담보해야 합니다).

스킬 세트 (워크플로우 본체 ＋ 참조 문서 ＋ HTML 리포트 템플릿)는 GitHub에 공개되어 있습니다.

사용법은 간단하며, AI에게 **「이 스킬에 따라, 이 결함을 조사해줘」**라고 전달하기만 하면 됩니다.

제대로 만들어 두면, AI는 갑자기 원인을 맞추려 들지 않고, 처음에 「누구를 위한 것인가?」 「톤앤매너는?」 「기존 분석은?」을 물어옵니다. 이 "멈춤"이 핵심입니다.

마지막으로, 제가 AI에게 조사를 부탁할 때 매번 처음에 전달하는 규칙을 남겨둡니다 (PDF 변환 기사와 동일한, 저의 입버릇입니다).

여기까지 읽어주셔서 감사합니다 🙇

「AI에게 결함 조사를 맡기고 싶지만, 통째로 맡기기에는 불안하다」는 분들은, 꼭 "형식"부터 전달해 보세요. 똑똑함보다 절차입니다.