(번역) Claude로 UI 버그를 디버깅해 봤습니다. 실제로 어떤 일이 벌어졌을까요?

 

 

원문: https://blog.logrocket.com/debugging-session-with-claude/

⚠️ 현재 원문은 접근되지 않습니다.

 

 

지난 2년 동안 소프트웨어 개발자들은 AI가 우리를 대체할지도 모른다는 이야기를 들어왔습니다. 한편으로는 AI가 개발자를 대체하지는 않고, 강력한 도구가 될 거라고 주장하는 사람들도 있습니다. 최근 저는 유난히 까다로운 UI 버그를 만났고, 이 주장을 직접 검증해 보기로 했습니다. AI는 대체재일까요, 아니면 도구함에 하나 더 얹은 도구일 뿐일까요?

 

배경을 조금 말씀드리면, 저는 10년 넘게 업계 경력을 쌓아 온 풀스택 시니어 소프트웨어 개발자입니다. 컴퓨터 공학 학사 학위를 받고 졸업한 뒤로 헬스케어, 금융, 교육 등 다양한 업계에서 IC와 팀 리드를 두루 거쳤습니다. 그동안 블록체인부터 노코드 플랫폼에 이르기까지 수많은 "파괴적" 기술이 떴다 사라지는 모습을 지켜봤습니다.

 

다만 이번 AI의 물결은 결이 좀 다릅니다. 그 능력이 부정할 수 없을 만큼 인상적이어서, 실제 현장에서는 어떤 모습일지 직접 시험해 보고 싶었습니다.

 

이 글에서는 Claude 모델과 주고받은 대화를 따라가며 실시간 디버깅 여정을 풀어봅니다. 끝부분에는 그 과정에서 느낀 점과 함께 장단점을 정리해 두었습니다.

 

실시간 디버깅 여정

참고. 이해를 돕기 위해 대화는 일부 줄여서 옮겼습니다.

 

상황을 좀 더 설명드리자면, 저는 투자 제안서를 만들어 내는 일을 전문으로 하는 자산운용 회사에서 일하고 있습니다. 사용자, 즉 이 경우엔 재무 자문가가 템플릿을 고르면, 곧바로 사용할 수 있는 제안서를 생성해 줄 양식을 작성하라는 안내를 받습니다. 그 다음에는 템플릿을 바꿀 수 있는데, 템플릿을 바꾸면 다시 양식 화면으로 돌아옵니다. 그런데 이때 양식이 얼어붙어, 어떤 선택지도 클릭되지 않습니다. 해당 페이지는 상단 바, 객관식 답변으로 구성된 두 개의 질문, 그리고 생성 버튼으로 이루어진 평범한 Next.js 페이지입니다. 이 시점에 제가 아는 거라곤, 어느 답변도 클릭되지 않는다는 사실뿐이었습니다.

 

첫 번째 가설: 양식의 비활성화 상태

 

Claude에게 던진 첫 프롬프트.

이상한 버그가 있습니다. 처음 이 페이지에 들어왔을 때는 잘 동작했습니다. 그런데 플로우 도중에 이 페이지로 돌아오면, 페이지는 렌더링되지만 양식 옵션을 어느 것도 클릭할 수 없고, 버튼도 비활성화되어 있습니다. 페이지를 새로고침해야만 다시 동작합니다.

 

처음에 Claude는 Form 컴포넌트를 살펴보고 두 개의 로컬 상태를 짚어 냅니다. isProcessing과 isCreating입니다. Claude가 보는 건 이 컴포넌트뿐이라, 초기 가설은 뮤테이션 액션 쪽으로 향합니다.

 

Claude: AutoCreatePage 컴포넌트를 살펴보니 문제가 보입니다. tRPC에서 받아 온 뮤테이션 상태(autoCreatePresentationMutation과 createPresentationMutation)가 페이지로 다시 돌아왔을 때 로딩 상태나 에러 상태를 그대로 유지하고 있어서, 로컬 isCreating 상태가 제대로 리셋되지 않는 것이 원인일 가능성이 높습니다.

 

이 가설은 성립하지 않습니다. 더 깊이 파고들기 위해 Claude는 상태를 추적하는 console.log 여러 개를 추가하고, 저는 그 결과를 다시 공유합니다.

 

몇 차례 주고받은 끝에, Claude는 마침내 진짜 원인을 찾아냅니다. 질문 양식에 disabledclassname이 적용돼 있었습니다. Claude는 disabled prop을 명시적으로 false로 두어 문제를 해결합니다.

 

className={clsx(' px-4', {
  'pointer-events-none select-none opacity-15': disabled,
})}

 

하지만 이 수정으로는 아무것도 해결되지 않았기에, Claude의 첫 가설은 명백히 빗나간 셈입니다. 저는 직접 조사를 좀 해 보면서 Claude의 컨텍스트 한계가 어디까지인지 시험해 봅니다.

 

두 번째 가설: 화면을 막고 있는 로딩 스크린

프롬프트: 계속 테스트해 봤더니, 질문 양식만이 아니라 페이지 전체가 멈춘 것처럼 보였습니다. 상단 바의 뒤로 가기 버튼도, '수동으로 설정' 버튼도 클릭이 안 됩니다. 어떤 원인이 Next.js 페이지를 이 정도로 무반응 상태로 만들 수 있을까요? 위아래 스크롤은 됩니다.

 

그러자 Claude는 컨텍스트를 넓혀 페이지 전체를 읽어보더니, 그 위에 fixed로 자리 잡은 로딩 스크린이 있다는 사실을 발견합니다.

 

<div
  role="status"
  data-testid="loading-screen"
  className="fixed left-0 top-0 z-50 flex h-full w-full flex-col items-center justify-center bg-primary-navy/[.65] p-3"
>

 

Claude는 여전히 isProcessing과 isCreating 두 변수를 기억하고 있어서, 새로운 가설은 첫 번째 양식 제출 이후 isCreating이 false로 리셋되지 않아 페이지가 무반응이 되었다는 쪽으로 흐릅니다.

이 가설은 반박하기 쉬웠습니다. 제가 보고 있는 건 양식이지, 로딩 화면이 아니었기 때문입니다.

이 시점에서 Claude는 아이디어가 바닥났고, 제가 디버깅을 도와줘야 했습니다.

 

Claude: 자, 이제 브라우저에서 다음 항목들을 확인하면서 디버깅을 도와주세요.

• 브라우저 개발자 도구 열기 (F12)
• Elements 탭으로 이동해 페이지 요소 확인
• 다음과 같은 CSS가 걸린 요소 찾기
  • z-index가 높은 position: fixed
  • 부모 요소에 걸린 pointer-events: none
  • 페이지를 덮고 있는 보이지 않는 div
• Console 탭에서 자바스크립트 오류 확인
• 페이지에서 우클릭 시도 — 컨텍스트 메뉴가 뜨는지

 

Claude는 아직 깨닫지 못했지만, 슬슬 올바른 방향으로 들어서고 있었습니다.

 

세 번째 가설: 닫히지 않는 모달

프롬프트: 무반응의 원인을 찾은 것 같습니다. 무언가가 body 전체에 pointer-events: none;을 추가하고 있어요.

 

Claude: 조사한 내용을 종합해 보면, 이 문제는 십중팔구 Radix UI 모달과 관련이 있습니다. (저희 내부 라이브러리의) Modal 컴포넌트가 사용하는 Radix UI는 보통 모달이 열려 있는 동안 뒤쪽 콘텐츠와의 인터랙션을 막으려고 body에 pointer-events: none을 적용합니다.

 

이제 Claude는 모달이 제대로 닫히지 않는 게 문제라고 가정하고, useEffect를 추가해 isModalOpen을 false로 설정합니다. 참고로, 사용자는 'Change template' 옵션을 골라 템플릿을 바꿀 수 있는데, 이 옵션을 누르면 템플릿 목록이 담긴 모달이 열립니다. 사용자가 하나를 고르면 다시 양식 화면으로 돌아옵니다.

 

Claude: TemplateSelectorModal의 onSelectHandler 함수를 보면, SaveTemplateModal에서 우리가 고친 것과 똑같은 패턴이 있습니다. catch 블록에서 에러가 발생하면 모달이 영영 닫히지 않는 거죠.

 

타당한 가정이지만, 이 접근에는 한 가지 걸림돌이 있습니다. 이 가설은 에러가 발생한다는 전제를 깔고 있는데, 실제로는 그렇지 않습니다.

이 시점에서 Claude는 열린 모달이 있는지 추적하는 console.log를 잔뜩 추가하고, 저는 열린 모달이 없다고 보고합니다.

 

// Radix 다이얼로그 오버레이가 있는지 확인합니다 (이로 인해 body에 pointer-events: none이 발생합니다)
console.log('Dialog overlays:', document.querySelectorAll('[data-radix-dialog-overlay]').length);

// 열려있는 모달 대화 상자를 확인합니다
console.log('Open modals:', document.querySelectorAll('[role="dialog"]').length);

// body 스타일을 확인합니다
console.log('Body pointer-events:', getComputedStyle(document.body)['pointer-events']);

// aria-hidden=true 속성을 가진 요소 중에서 화면을 가릴 수 있는 요소를 찾아봅니다
console.log('Hidden overlays:', document.querySelectorAll('[aria-hidden="true"]'));

 

조사를 좀 더 진행한 끝에, pointer-events: none이 자바스크립트로 인라인 스타일에 직접 설정되고 있다는 사실을 알게 됐습니다(document.body.style.pointerEvents = 'none'). CSS 규칙으로 적용되는 게 아니었습니다.

여기서 Claude는 그 스타일이 언제 적용되는지 알아내려고 추적용 코드를 추가하라고 했습니다.

 

Object.defineProperty(document.body.style, 'pointerEvents', {
  get: function () {
    return this._pointerEvents || '';
  },
  set: function (value) {
    console.log('Setting pointerEvents to:', value);
    if (value === 'none') {
      console.trace('Stack trace for setting pointer-events: none');
    }
    this._pointerEvents = value;
  }
});
console.log('Trace set up - now trigger the issue');

 

네 번째 가설: 모달 언마운트 이슈 + Claude의 첫 수정안

 

추적기는 새 템플릿을 고르려고 모달을 열었다가 양식으로 돌아올 때 pointer-events가 추가된다는 사실을 밝혀냅니다.

Claude: 좋습니다! 문제는 TemplateSelectorModal을 열 때 발생하고 있어요. 사실 이건 의도된 동작입니다. Radix UI 모달은 모달이 열릴 때 배경과의 인터랙션을 막으려고 body에 pointer-events: none을 설정합니다.

 

따라서 진짜 문제는 모달이 닫힐 때 그 스타일이 제거되지 않는다는 점입니다.

여기서부터 저는, 모달에서 항목을 선택하자마자 화면 이동이 일어난다고 설명했습니다. 그래서 우리는 화면 이동이 일어나기 전에 모달이 완전히 닫히도록 만들 수 있는 여러 방법을 시도했습니다. 그러던 중 Claude가 인라인 스타일을 정리하는 방안을 제안합니다.

 

첫 번째 수정안: Modal.tsx 안에서

 

// 모달이 닫힐 때 pointer-events가 리셋되도록 보장
// 모달이 열린 상태에서 화면 이동이 일어나면 모달이 언마운트되지 않을 수 있고,
// 그러면 body에 걸린 pointer-events:none이 그대로 남아 새 페이지의 인터랙션을 막을 수 있어 추가함. (Switch template 액션 사례처럼)
useEffect(() => {
  if (open === false) {
    // 모달이 명시적으로 닫힐 때 pointer-events 리셋
    document.body.style.pointerEvents = '';
  }
}, [open]);

 

드디어 실제로 동작하는 수정안이 나왔습니다. 다만 좀 임시방편 같아서, Claude에게 좀 더 꼼꼼하게 따져보라고 했습니다.

 

Claude: Modal 컴포넌트를 살펴보면, 이 컴포넌트는 Radix UI의 dialog 기본 요소를 감싼 래퍼입니다. 문제는 Radix UI가 모달을 열 때 pointer-events: none을 설정하지만, 화면 이동이 일어나면 그 정리가 안정적으로 이루어지지 않을 수 있다는 점입니다.

 

타당해 보이는 지적이라, 팀 리뷰를 받기 위해 PR을 올렸습니다. 그러는 사이 점심 시간이 되어 노트북을 덮고 요리를 시작하러 나섰습니다. 원격 근무의 장점 중 하나죠. 늘 그랬듯, 손이 움직이는 동안 머릿속은 슬그머니 다른 생각으로 흘러갔고 이런 의문이 떠올랐습니다. 왜 하필 지금에서야 문제가 된 걸까?

 

이 기능을 개발하기 전까지는 pointer-events 문제가 한 번도 없었습니다. 제품의 다른 부분에서도 모달은 쓰고 있었지만 이런 문제는 겪은 적이 없었습니다. 정말 화면 이동 때문일까요? 만약 그게 사실이라면, 이렇게 근본적인 문제를 Radix가 진작 손봤을 텐데요. 아무래도 아직 핵심에 닿지 않은 것 같다는 느낌이 가시지 않아, 몇 가지 테스트를 해 봤습니다.

 

저는 모달을 열고 바깥을 클릭하면 모달이 닫히는데, 그 순간에도 pointer-events: none 문제가 그대로 발생한다는 사실을 발견했습니다. 이는 화면 이동이 문제의 원인이라는 가설을 반증합니다.

 

프롬프트: 자, 이 문제로 테스트를 좀 더 해 봤습니다. 다른 방식으로도 pointer-events가 제거되지 않는 상황을 재현할 수 있는지 보고 싶어서, 모달에서 우리가 한 수정을 주석 처리해 봤어요. 그랬더니 다른 모달에서도 모달 페이지 바깥을 클릭해서 열고 닫을 때 똑같은 버그가 재현됩니다. 어떤 이유에서인지 모달이 닫혀도, 화면 이동이 없는데도, pointer-events: none이 추가됩니다.

Claude: 정말 의미 있는 발견이에요! 이걸로 문제가 화면 이동에만 한정된 게 아니라는 점이 확인됐습니다. 오버레이 클릭으로 모달을 닫을 때와 다른 방식으로 닫을 때, Radix UI 모달의 정리 로직이 어떻게 동작하느냐와 얽힌 더 근본적인 문제입니다.

 

이 시점에서 Claude는 Radix의 문제라고 확신하고 있었습니다. 저는 모달에 취소 버튼이 있고, 그 버튼을 클릭해도 같은 문제가 생긴다고 짚었습니다. 또 왜 하필 지금에서야 이 문제가 생기는지가 이상하다는 점도 다시 한번 짚었습니다.

Claude는 Radix UI 라이브러리의 최신 변경 사항을 확인해 무언가 원인이 될 만한 게 있는지 보자는 등의 몇 가지 선택지를 제시했습니다.

 

해결

이쯤 되니 Claude는 아이디어가 바닥났고, Radix 라이브러리가 원인일 거라고 확신하고 있었습니다. 그래서 저는 옛날 방식대로 구글링에 나섰습니다.

 

저는 GitHub 이슈 하나를 발견했는데, 거기서 누군가가 이렇게 댓글을 달아 두었습니다.

이 문제는 모달과, 그것을 트리거하는 데 쓰이는 다른 모달 지원 컴포넌트 사이의 충돌 때문에 발생합니다. 십중팔구 드롭다운이죠. 해결하려면 트리거 컴포넌트에 modal={false}를 추가하면 됩니다.

 

알고 보니 제 모달은 드롭다운 메뉴 안에서 트리거되고 있었고, 그 충돌 때문에 모달이 닫혔는데도 pointer-events: none이 추가되고 있었습니다.

 

이 시점부터는 Claude가 더 필요하지 않아, 직접 수정에 들어갔습니다.

 

최종 수정안:

<DropdownMenu
  ariaLabel={ariaLabel}
  items={menu}
  dataTestId={dataTestId}
  modal={modal}
>
...
</DropdownMenu>

 

Claude와 디버깅하면서 든 느낌

전반적으로 경험은 꽤 긍정적이었습니다. 다른 개발자와 함께 짝 프로그래밍하던 시절이 많이 떠올랐습니다.

 

몇 년 전, 새 회사에 합류했을 때 저는 첫 한 달을 또 다른 신규 입사자와 짝 프로그래밍을 하면서 코드베이스를 익혔습니다. 그 과정이 정말 즐거웠습니다. 배움이 컸을 뿐 아니라, 협업하면서 여러 아이디어를 시도해 보고, 사실상 깜깜한 어둠 속을 더듬어 가며 무언가를 알아내는 과정 자체가 보람찼습니다. 그런 의미에서 Claude와 일하는 건 그때처럼 서로 주고받으며 길을 찾아가는 느낌과 무척 비슷했습니다.

 

물론 단점도 있습니다. Claude는 당신의 접근 방식에 그다지 이의를 제기하지 않습니다. 일리는 있습니다. Claude는 실행자니까요. 프롬프트를 주면 그대로 수행합니다. 브레인스토밍 상대로는 훌륭하지만, 잘못된 방향으로 가고 있는지 알려 주지는 않습니다.

 

또 자기 아이디어에 좀 갇히는 경향이 있습니다. 한순간 Radix가 문제라고 확신하더니, 거기로 자꾸 회귀하는 모습을 보였습니다. 사람과 함께라면 보통 아이디어가 진화하는 동안 더 활발하게 의견이 오갑니다.

 

결국 Claude는 도구이고, 진짜 질문은 어떻게 효과적으로 쓸 것이냐로 바뀝니다.

 

거기서 또 하나의 생각이 이어집니다. 만약 제가 초반에 조금만 더 조사해 두었다면, 더 빨리 근본 원인에 닿았을까요? 우리는 초반부에 양식에 시간을 너무 들였습니다. 페이지 전체가 얼어붙었다는 사실을 더 빨리 알아챘다면, 제 프롬프트는 더 정확했을 것이고, 그만큼 속도도 빨랐을 가능성이 큽니다. Claude가 내놓는 결과물의 품질은 결국 입력의 품질에 크게 좌우됩니다.

 

그럼에도 저는 이 경험이 진심으로 유용했다고 느낍니다. 브레인스토밍 파트너로서 실제로 가치를 더해 주었습니다. 하루 종일 디버깅했을 법한 일이 이른 오후에 마무리됐습니다. 현실적으로 따지면 약 4시간을 절약해 준 셈입니다.

 

장단점

TL: DR이 필요한 분들을 위해, 제가 메모해 둔 장단점을 정리해 둡니다.

 

Claude가 잘했던 일은 다음과 같습니다.

• 코드베이스에서 문자열 패턴을 검색하고, 다른 컴포넌트나 서비스와 연결 짓기.
• 디버깅 트릭 제안하기. (트래커 기법은 칭찬할 만했는데, Claude 덕분에 알게 됐습니다.)
• 빠르게 대안 가설 내놓기.

 

Claude가 어려워했던 일은 다음과 같습니다.

• 컨텍스트: 좁은 컨텍스트에서 출발하기 때문에, 다른 곳도 살펴보라고 다그쳐야 합니다.
• 자신감: 그럴듯하게 들리지만 미묘하게 틀린 자신만만한 설명을 내놓기도 합니다. 바로 로딩 스크린 가설처럼요.
• 근본 원인: 문제를 해결하는 데만 관심이 있어서, 그게 임시 처방이라도 일단 해결하려 합니다. 별도로 지시하지 않으면 더 깊이 파고들지 않습니다.

 

마치며

결론적으로, 저는 디버깅에 Claude를 다시 쓸 생각입니다. 다만 좀 더 의식적인 방식으로 쓰려고 합니다. 제가 초기 조사를 어느 정도 마치고 문제에 대한 기본적인 이해를 갖춘 뒤에 함께 일할 때, Claude가 가장 효과적이라는 사실을 알게 됐습니다. 그 지점부터 Claude는 가치 있는 아이디어 공급원이 되며, 제가 떠올리지 못한 시각을 더해 줍니다.

 

특히 UI 버그에서는 더욱 그렇습니다. UI 버그는 가정 하나하나가 대화를 엉뚱한 곳으로 밀고 가기 십상이거든요. 브라우저에서 무슨 일이 벌어지고 있는지 단단히 잡아 두면 논의를 이끌어 가는 데 도움이 됩니다. 앞에서도 말씀드렸듯, Claude의 응답 품질은 프롬프트의 품질에 직접 달려 있습니다. 입력이 명확하고 정확할수록, 출력 또한 더 유용하고 적절해집니다.