지금까지 본 가장 이상한 버그

이상한 버그의 발견과 해결 과정

• 내부 도구 팀의 온콜 근무 중, 구스토(Gusto)의 내부 소프트웨어를 사용하는 사용자들이 크롬 브라우저 충돌 문제를 경험함.
• 이 문제는 고객 서비스에 다양한 방해를 초래함.
• 문제 해결을 위해 경험 많은 동료, 제품 인프라 팀, IT 팀의 도움을 받음.

첫 번째 단서

• 영향을 받은 사용자들에게 공통점을 찾으려 시도함.
• 모든 구스토 직원이 영향을 받은 것은 아니며, 고객 대면 소프트웨어는 문제가 없음.
• 다른 내부 소프트웨어 웹페이지는 정상 작동함.
• 충돌은 일관성 없이 발생하며, 사파리나 파이어폭스에서는 문제가 발생하지 않음.

두 번째 단서

• 크롬 버전이 문제일 수도 있다는 가설을 세움.
• 일부 사용자가 크롬 버전을 업데이트했을 때 문제가 해결된 것처럼 보였으나, 완전히 해결되지는 않음.
• 크롬 확장 프로그램이 문제일 수도 있다고 추측했으나, 확장 프로그램 없이도 문제가 재현됨.

버그 재현의 어려움

• 인프라 팀이 모든 엔지니어에게 문제 재현을 요청함.
• 터키의 두 엔지니어를 제외하고는 엔지니어 팀에서는 충돌을 보고하지 않음.
• 크롬 충돌 보고 기능이 보안상 비활성화되어 있어 문제 해결에 어려움을 겪음.

행운의 전환점

• 덴버의 한 엔지니어가 그래머리(Grammarly) 데스크톱 앱을 다운로드한 후 문제가 발생했다고 보고함.
• 그래머리 앱을 삭제하고 컴퓨터를 재시작하면 문제가 해결됨을 발견함.

진전

• 디버깅이 가능해지면서, 문제의 원인을 찾기 위해 여러 시도를 함.
• 주요 내부 애플리케이션은 ActiveAdmin을 기반으로 구축되었으나, React를 사용하는 새로운 부분은 충돌하지 않음.
• 공통 코드 부분을 조사하던 중 'My History' 드롭다운 메뉴가 문제의 원인임을 발견함.

문제 해결

• 'loader-spinner.gif' 이미지 파일이 문제를 일으키는 것으로 확인됨.
• 해당 GIF를 다른 이미지로 교체하자 페이지가 더 이상 충돌하지 않음.
• 그래머리나 크롬 중 하나가 문제를 해결했는지, 이제는 원래의 GIF가 크롬을 충돌시키지 않음.

결론

• 예상치 못한 애니메이션 GIF가 디버깅의 해답이었음.
• 호기심과 협력을 통해 문제를 해결함.
• 구스토는 협력적이고 호기심 많은 사람들과 함께 일할 수 있는 기회를 제공함.

GN⁺의 의견

이 글에서 가장 중요한 것은 예상치 못한 원인으로 인한 버그를 발견하고 해결한 과정의 상세한 기술임. 이 글은 소프트웨어 엔지니어링의 복잡성과 예측 불가능성을 보여주며, 팀워크와 끈기 있는 문제 해결 능력이 얼마나 중요한지를 강조함. 엔지니어링 팀이 어떻게 협력하여 난해한 문제를 해결하는지에 대한 흥미로운 사례를 제공하며, 이는 엔지니어링 분야에 관심 있는 사람들에게 매우 매력적인 이야기가 될 것임.

[GN⁺]

Hacker News 의견들

• 읽으면서 Grammarly 관련 문제가 아닐까 생각했는데, 예전에 비슷한 양상으로 재현은 안 되지만 특정 부서 내부의 많은 사람에게 영향을 주는 버그를 겪은 적이 있음
  결국 공통점이 Grammarly 확장 프로그램 설치였고, 운영 사이트가 아니라 스테이징 미리보기 URL에서만 발생했음
  원인은 Grammarly 확장 프로그램의 잘못된 정규식이었고, 도메인 이름이 약 100자를 넘으면 페이지가 멈췄음
  이번 건이 정말 데스크톱 앱 때문에 생긴 거라면 더 무섭게 느껴짐

  • 결말이 “Grammarly나 Chrome 내부를 볼 수 없어서 GIF 디코딩/렌더링이 왜 크래시를 내는지 모른다”로 끝나서 실망스러웠음
    많은 문제가 특정 조합까지 좁혀지지만, 정작 왜 그런지 모르면 만족스럽지 않음
  • 오늘도 사용자가 폼에 잘못된 값을 넣으면 백엔드를 서비스 거부 상태로 만들 수 있는 정규식을 디버깅했음
    그래서 지금 정규식 엔진을 읽는 중임: https://swtch.com/%7Ersc/regexp/regexp1.html
  • 5년쯤 전 웹 기반 영상 감시 소프트웨어에서 비슷한 일을 겪었음
    Windows 10 전사 업그레이드 과정에서 어떤 매니저의 오래된 노트북을 교체했는데, 소프트웨어와 네트워크 요구사항 점검, 사용자 프로필과 문서 백업 등 절차는 잘 갖춰져 있었음
    장비 평가표에는 10년 된 ThinkPad, RAM 4GB, 전원 케이블을 빼면 꺼진다는 메모가 있었고, 그걸 참고 쓰는 인내심이 대단해 보였음
    새 노트북 배포 후 거의 다 정상인데 Grammarly 라이선스 이전만 안 돼서 요청을 넣었고, 일주일 뒤 라이선스 키가 적용되어 Grammarly도 정상으로 확인됨
    그런데 그날 나중에 보안 카메라 웹페이지가 크래시난다는 연락이 왔고, 헬프데스크가 재부팅, 캐시 삭제, 브라우저 재설치, 프로필 재생성까지 했지만 해결되지 않아 내게 넘어옴
    네트워크, 방화벽 로그, 다른 PC, 현장/외부 접속을 모두 확인했지만 내 쪽에서는 전부 정상이고 다른 사람도 문제가 없었음
    “최근 PC나 사무실에 바뀐 게 있냐”고 묻자 농담처럼 “오늘 Grammarly를 설치했으니 그건가?”라고 했고, 아이디어가 다 떨어져서 진짜로 제거해 봤더니 작동했음
    다시 Grammarly를 켜고 링크를 누르자 확실히 실패했음
    그 카메라 소프트웨어는 아주 낡았고, 맞춤형 홈페이지 링크가 매우 긴 PHP 생성 URL 같은 형태였으며, 현장에서 Grammarly를 쓰는 사람이 그 사람뿐이라 한 번만 보였던 문제였음
  • 웹사이트 버그가 쉽게 풀리지 않으면, 첫 단계로 모든 확장 프로그램 비활성화부터 해야 함
    개발자들은 확장 프로그램이 원인일 수 있다는 생각을 자주 놓치지만, 확장 프로그램은 웹페이지에 별의별 일을 할 수 있음

• 대학 교수님이 논문을 쓰다가 밑줄이 유지되지 않는다고 해서 단순한 사용자 실수라 생각하고 5분이면 도와드릴 줄 알았음
  그런데 3시간 넘게 지나서야 특정 비디오 카드 드라이버 버전과 특정 프린터 드라이버 버전의 조합이 밑줄 출력만 막는다는 걸 알아냈음

  • 스캔한 문서의 숫자를 바꿔버리던 Xerox 버그보다는 낫다 봄
    https://www.zdnet.com/article/xerox-scanners-alter-numbers-i...
  • 그렇게 특이한 조합을 3시간 정도 만에 어떻게 찾아냈는지 궁금함
  • 비디오 카드가 출력에 어떻게 영향을 줄 수 있는지 이해가 안 됨

• 크래시 보고를 꺼뒀더라도 사용자 프로필 디렉터리 어딘가에 .dmp 파일이 생성되어 있을 가능성이 있음
  그 파일을 https://crbug.com/new 버그에 수동 업로드하면 Chrome 개발자가 디버깅할 수 있음
  크래시 보고를 끈 것과 비슷한 이유로 덤프를 공유할 수 없다면 Chromium에서 minidump_stackwalk를 빌드해 심볼 없는 스택 추적을 만들고 버그에 올릴 수 있음
  그러면 Chrome 개발자가 심볼을 붙일 수 있음
  자세한 내용은 https://www.chromium.org/developers/decoding-crash-dumps/에 있음

• 이 버그를 만든 기술 조합이 흥미로움. 2023년의 웹이 딱 이런 모습임
  Chromium 버그가 해결된 건지 알고 싶지만, 이 목록을 탐색하기는 쉽지 않음: https://bugs.chromium.org/p/chromium/issues/list?can=1&q=gif...
  Gusto가 “우리 잘못 아니었다”는 걸 보여주면서 Grammarly를 살짝 디스하려고 이 글을 올린 느낌도 좋음

  • 외부에 보이던 문제가 아니니 책임 소재라기보다는, 그냥 재밌는 이야기이고 무료 홍보라서 올린 것처럼 보임
  • 그 GIF는 꼭 공개해야 함
  • 이런 이슈였을 수도 있음: https://bugs.chromium.org/p/chromium/issues/detail?id=129770...

• Linux로 부팅한 뒤 가끔 소리가 안 나는 문제가 있었는데, 알고 보니 Windows 듀얼 부팅 설정과 관련 있었음
  Windows에서 재시작하면 Realtek 오디오 장치를 완전히 종료하지 않고 절전 상태로만 두고, Linux가 그 장치를 시작하지 못했음
  해결책은 Windows에서 항상 종료한 뒤 전원 버튼을 눌러 켜는 것뿐이었고, 문제는 아직 남아 있음: https://askubuntu.com/questions/1032543/no-sound-in-ubuntu-1...

  • 반대에 가까운 경우도 봤음
    Windows와 Linux를 듀얼 부팅하던 사람이 Windows로 부팅한 뒤 Linux로 재시작해야만 와이파이가 작동했음
    Linux 설치에 와이파이 카드용 펌웨어 패키지가 없어서, Windows에서 재부팅하면 장치가 이미 준비된 상태였지만 Linux로 바로 콜드 부팅하면 안 됐던 것임
  • 반대 방향으로도 비슷한 일이 있었음. Linux에서 재부팅하면 Windows 10이 부팅 중 블루스크린을 냈음
  • 빠른 사용자 전환을 꺼도 해결되지 않았는지 궁금함
  • 몇 년 전 Bluetooth 장치에서도 비슷한 동작을 본 적이 있음

• 결말이 완전히 김빠진다는 데 동의함
  Chrome 소스 코드도 Grammarly 소스 코드도 접근할 수 없으니 추측만 할 수 있다는 식인데, 이게 “오픈 소스” 운동이 만든 결과인지 의문임
  소스 코드 없이는 완전히 길을 잃고 더 깊이 파고들기를 거부하는 개발자들이 생긴 셈이고, 진실을 알리기 싫어하는 기업 입장에서는 이런 태도가 아주 반가울 것임
  예전에는 소스 없이도 프로그램을 디스어셈블하고 이해하고 패치하던 사람이 많았고, 그중 상당수는 직업 개발자도 아니었음
  그냥 소프트웨어를 원하는 대로 움직이게 하려는 동기가 있었고, 그러다 자연스럽게 필요한 만큼 배우게 됐음
  이 글은 전체 스택의 복잡도가 미쳤다는 점도 건드림. 프레임워크 위에 프레임워크가 줄줄이 등장하는 걸 보면 상당 부분은 자초한 일처럼 느껴짐
  loader-spinner.gif, 즉 메뉴 옵션이 로드되는 동안 보여주는 자리표시자를 제거하자 페이지 크래시가 멈췄다는데, 메뉴 옵션 로딩에 애니메이션이 필요할 만큼 오래 걸리는지도 의문임

  • 모든 개발자가 바이너리를 패치할 수 있어야 한다고 기대하는 건 정중히 말해 비현실적임
    소프트웨어 공학의 세계는 엄청나게 넓고, 스택의 모든 부분을 아는 건 오래전부터 거의 불가능해졌음
    게다가 소프트웨어 공학은 학습의 여정이고, 각자는 그 여정의 서로 다른 위치에 있음
  • 오픈 소스가 있어도 실제로 코드를 읽으려는 의지가 전반적으로 부족해 보임
    디스어셈블러를 열거나 디버거를 붙이는 건 말할 것도 없고, 그런 기술은 이제 잘 가르치지 않는 듯함
  • 아마 메뉴 옵션을 가져오려고 네트워크 요청을 할 것임
    보통은 거의 즉시 끝나더라도, 오래 걸릴 경우를 대비해 로딩 스피너를 두는 건 말이 됨

• 어떤 사용자가 특정 폼에 입력한 문구가 저장하면 바뀐다고 했던 일이 가장 이상했음
  처음에는 같은 폼을 다른 사람이 동시에 수정하는 줄 알았지만 로그상 그렇지 않았고, 내 컴퓨터에서는 올바른 문구가 보였음
  그러다 스크린샷에서 일부 메뉴 문구도 이상하다는 걸 발견했고, 원인은 Chrome의 “이 페이지 번역” 옵션이 켜져 있었기 때문이었음
  앱 안에서 올바르게 언어를 바꾸는 방법을 알려주자 문제가 사라졌음

  • Chrome이 페이지를 망가뜨리는 버그를 발견한 뒤, 단일 페이지 웹앱의 모든 페이지에 관련 설정을 추가했음
    이제 앱이나 요소에 적용할 수 있는 새 주문은 이쪽인 듯함. 동적으로 바꾸는 걸 지원하지 않으려고 CSS가 아닌 것 같고 보기엔 못생겼음: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
    가끔 대형 단일 페이지 앱의 메타 태그를 보다가, 그 태그가 왜 필요한지 찾는 과정에서 새로운 공포를 발견하곤 함
  • 이건 정말 짜증남
    일본어 웹사이트를 읽을 때 Google Translate에 자주 의존하는데, React를 쓰는 모든 웹사이트가 깨짐
    React와 Google Translate가 서로를 모른 채 DOM 노드를 업데이트하려 하기 때문임
    나중에 이 문제가 없는 웹 위젯을 다시 만들 수 있을지 보려고 Google Translate 구현을 진지하게 들여다본 적도 있음
    [1] https://bugs.chromium.org/p/chromium/issues/detail?id=872770
  • 영어를 미국어로 번역한 건지 뭔지 궁금함
  • 이 이야기는 DaylyWTF 같은 데 보내도 될 만큼 웃김

• 너무 익숙한 문제임
  예전에 Chrome의 접근성 도구가 드롭다운 메뉴에서 이런 문제를 일으킨 걸 봤고, 아주 작은 HTML만으로도 재현될 정도였음
  2년 전에 내가 밟은 특정 버그는 Chromium-Edge에 있었지만 증상과 원인은 매우 비슷했음
  Grammarly는 거의 확실히 Chrome의 접근성 도구 일부에 기대고 있을 것임
  이런 도구는 Edge, Brave, Chrome 같은 Chromium 계열마다 조금씩 다름

  • 이 가설이라면 Grammarly 데스크톱이 GIF를 보고, 어떻게든 브라우저 접근성 함수를 호출하고, Chrome이 그걸 처리하지 못해 크래시난다는 뜻인지 궁금함

• 다음에 이런 일이 생기면 그냥 다른 브라우저를 쓰게 하는 걸 추천함
  특히 Firefox는 Chrome에서 북마크, 비밀번호 등을 가져오는 기능이 훨씬 좋아졌음
  우주가 이제 갈아탈 때라는 신호를 보낸 것인데, 우리가 신호를 거부할 수는 없음
  참고로 Firefox 엔지니어지만, 이 조언과는 아무 상관 없음

  • 엔지니어 입장에서는 Firefox가 좋은 해법이 맞음
    PM 입장에서는 온보딩을 쉽게 만들려고 4개월을 썼는데, 이제 사람들에게 새 브라우저를 설치하라고 하자는 건가 싶음
  • 링크된 글에 이미 우회책으로 명시되어 있음
  • Chrome은 시장의 절반 이상을 차지함
    브라우저 기반 제품이 세계에서 가장 많이 쓰는 브라우저에서 제대로 작동하지 않는 건 좋은 신호가 아님

• 보안상 이유로 Chrome 크래시 보고는 막아두면서 직원들이 Grammarly 설치는 할 수 있게 하는 기업 보안 정책이 참 마음에 듦