예전에는 왜 내가 다른 사람들보다 버그를 훨씬 더 많이 보는지 궁금했다. 나는 일주일에 수백에서 수천 개의 버그를 쉽게 목격하고 아무것도 제대로 작동하지 않는 것 같다고 느끼는데, 정작 이야기를 나눠본 대부분의 사람들은 그런 걸 전혀 보지 못한다고 한다. 오랫동안 나는 내가 컴퓨터를 쓰는 방식 탓이라고 생각했지만, 시간이 지나면서 깨달았다. 대부분의 경우 사람들은 똑같은 버그를 겪으면서도 그냥 알아차리지 못할 뿐이라는 것을.

프로그래머가 아니라면 그건 아마 더 나은 세상을 보는 방식일 것이다. 하지만 프로그래머에게는 품질/버그에 대한 맹점을 고치는 것이 도움이 된다고 생각한다. 나는 지인이나 친구들에게 그냥 버그를 하나하나 짚어주는 방식으로 이걸 여러 번 해봤다. 몇 주가 지나면, 성향이 맞는 사람들은 버그를 알아보기 시작한다.

이런 걸 잘 알아차리다 보니, 여러 직장에서 이사나 VP, 임원 등이 무언가에 대해 진짜 의견을 듣고 싶을 때 나에게 평가를 부탁하곤 했다. 문제를 비교적 잘 찾아내고, 필요하다면 직접 고치거나 고치도록 밀어붙일 가능성이 높은 사람에게서 말이다. 가끔은 아무 문제도 찾지 못할 때도 있다(내가 알아차리지 못하는 종류의 문제가 있을 가능성이 크다). 더 자주 발견하는 건 “가벼운” 수준에서 “보통” 수준 사이의 문제들이다. 그리고 가끔은 문제가 심각해서, 솔직히 말해 그 제품이 아예 작동하지 않는다고 할 정도인 경우도 있다.

이 마지막 부류가 나는 좀 미스터리하게 느껴진다. 어떻게 해서 이렇게 됐는지 내부 논의를 찾아보면, 대개 “좋다”, “잘 작동한다”는 식의 내부 코멘트가 줄줄이 이어지는데, 막상 내가 그걸 열어 직접 써보면 직관적이지 않은 온갖 편법을 동원해야만 겨우 작동하는 상태이기 때문이다. 십중팔구 일반 사용자라면 그걸 제대로 쓸 수 없을 뿐 아니라, 웃기다 못해 화가 날 정도로 끔찍한 경험을 하고는 친구들에게 그 얘기를 퍼뜨릴 것이다.

이 글은 10년쯤 전부터 머릿속에 담아두고 있었다. 하지만 쓰기를 망설였던 건, 마음 한편으로는 혹시 내가 대부분의 사용자가 겪지 않는 희한한 코너 케이스를 나도 모르게 건드리고 있는 건 아닐까 하는 의문이 계속 들었기 때문이다. 그런데 제품이 출시되자마자 내가 봤던 바로 그 문제들 때문에 처참하게 실패하는 경우를 점점 더 많이 보면서, 이제는 내가 일반 사용자가 하지 않을 특이한 행동을 해서 버그를 겪는 게 아니라는 확신이 들었다. 내가 써봤을 때 심각하게 결함이 있어 보인다면, 아마 실제로도 그러하다. 게다가 요즘은 LLM이라는 마법 덕분에, LLM이 다양한 측면에서 일반 사용자처럼 행동하게 해서 그 문제들이 수많은 시나리오에서 재현된다는 걸 보여줄 수도 있다.

몇 가지 예시

내가 직접 잘 작동하는지 평가하는 게 일이었던 구체적인 사례는 들고 싶지 않다. 내부적으로는 건설적이고 누구의 책임도 묻지 않는 취지로 한 이야기라도, 외부에 다시 게시되면 그렇게 읽히지 않을 수 있기 때문이다. 그래서 대신 덜 흥미롭고 근거도 덜 탄탄한 “무작위” 예시 몇 가지를 들겠다.

얼마 전, 나는 몇 가지 웹 검색 쿼리의 결과를 정리해 글을 쓴 적이 있는데, Google, Bing, Kagi 모두 결과가 형편없었다. 전반적으로 주요 검색 엔진들은 해당 쿼리에 대해 좋은 결과를 돌려주지 못하고, 저품질 SEO 스팸으로 가득 찬 페이지는 물론 실제로 사기 사이트까지 반환했다. 참고로, 위에서 말한 기준으로 보면 나는 이 정도를 “보통”으로 분류하고 “심각”으로 보지는 않는다(심각이라면 예를 들어 검색 엔진이 절반의 경우에 500 에러를 내거나, 결과의 대다수가 사기 사이트인 경우 등을 말한다. 내가 말하는 심각의 기준은 사용자가 안 좋은 경험을 하는 정도가 아니라, 일반 사용자가 아예 제품을 쓸 수 없는 수준이다). Google과 Bing 검색 결과에 대한 나의 평가에 이의를 제기한 사람은 거의 아무도 없었다¹. 하지만 Kagi에 대해서는 내가 틀렸다고 말하는 사람들이 있었다. 어떤 경우에는 사람들이 실제 검색 결과를 보내주기도 했다. 그런 경우마다 내가 보기에 검색 결과에는 제대로 된 결과가 하나도 없었고(예를 들어 계절 예보 쿼리에서는 최신 계절 예보를 반환하지 못했다) SEO 스팸으로 가득했다. 한 사람은 Kagi 필터 목록과 함께 자신이 받은 검색 결과를 보내주면서 결과가 좋은지 나쁜지에 대한 주장은 하지 않았지만, 대체로 사람들은 결과가 좋다고 우겼다. 실제로는 유용한 결과로 연결되지도 않고 스팸으로 가득했음에도 말이다. GitHub를 결과 상단에 고정해 두는 식으로 한 경우에만, GitHub에 호스팅된 소프트웨어를 다운로드하는 게 목적인 쿼리에서는 통했지만, 글에 나온 다른 쿼리들에서는 당연히 전혀 통하지 않았다.

추상적으로는, 무언가의 팬인 사람들이 그 대상의 결함에 눈먼다는 걸 이해한다. 예를 들어 나는 아웃 오브 샘플 충돌 테스트에서 Volvo가 보여준 성적을 보고 Volvo를 산 뒤로, 가끔 Volvo 자동차 포럼에서 궁금한 답을 찾는다. 10년도 넘게 존재하는 신뢰성 데이터에 따르면(그리고 Volvo를 다루는 정비사들의 경험담도 이를 뒷받침한다고 생각한다) Volvo의 신뢰성은 보통에서 나쁨 수준인데, 당연히 Volvo 포럼에는 Volvo가 가장 신뢰할 수 있는 차 중 하나이며 데이터가 모두 틀렸다고 주장하는 사람들로 가득하다.

주제에 더 직접적으로 관련된 예로는 Blackboard(수업 관리 소프트웨어)가 있다. 대학에서 수업용으로 가장 널리 쓰이던 시절, 이 소프트웨어는 학생과 교수 모두에게 널리 미움을 받았다. 내 주변에서는 가장 널리 미움받는 소프트웨어였다고 해도 과언이 아닐 것이다(Visual SourceSafe처럼 더 강하게 미움받는 소프트웨어도 있었지만, 그런 소프트웨어는 널리 쓰이지 않아 전체적으로 가장 미움받는 소프트웨어가 될 정도는 아니었다). Wikipedia 페이지에는 이렇게 적혀 있다.

Blackboard는 “교육 분야에서 가장 미움받는 — 심지어 증오받는 — 기업 중 하나가 되었다.”

그리고

2011년 12월, Fast Company는 Amplicate 고객 의견 조사 응답자의 93%가 그 회사를 “증오한다”고 보도했다.

훨씬 어리고 필터 없이 말하던 시절, 나는 Blackboard에서 일하는 사람을 만났을 때 생각 없이 멍청하게도 “그렇게 많은 사람이 싫어하는 소프트웨어를 만드는 건 어떤가요?” 같은 말을 내뱉었다. 다행히 상대방은 전혀 기분 나빠하지 않았고, 오히려 혼란스러워했다. 자신은 그 소프트웨어가 사용자들이 정말 좋아하는, 널리 사랑받는 소프트웨어라고 생각하고 있었기 때문이다. 그는 내 말이 사실일 수 있다고는 전혀 믿지 않았고, 나는 내 착각이었다는 식으로 얼버무리며 대화를 다른 방향으로 돌렸다. 당시 훨씬 어리고 순진했던 나는, 내 주변에서 아마 가장 널리 미움받던 소프트웨어를 그 회사 직원 한 명(그리고 아마 다른 직원들도)은 정말 사랑받는 소프트웨어라고 믿고 있다는 사실에 정말 놀랐다.

Volvo 포럼이 왜 그런 모습이 되는지는 이해할 수 있다. 요즘 차들은 전반적으로 충분히 신뢰할 수 있어서 사람들이 보통 차 고장을 겪지 않기 때문에, “데이터가 틀렸을 거야, 내 차는 한 번도 고장 난 적이 없는데” 라고 생각하기 쉽기 때문이다. 반면 스팸으로 가득한 검색 결과들을 보고도 결과가 얼마나 훌륭한지 설명하는 메시지를 서둘러 써 보내는 사람이 어떻게 있을 수 있는지, 혹은 특정 검색 엔진의 팬이라는 이유만으로 그러는 것이나, 내가 이야기한 모든 사람이(종종 굳이 묻지 않아도 불평하면서) 얼마나 형편없는지 말해주고, 그 소프트웨어가 얼마나 미움받는지에 대한 뉴스 기사가 있으며, 거의 모두가 싫어한다는 내용이 Wikipedia 페이지에까지 적혀 있을 정도로 악명 높게 미움받는 소프트웨어를 두고 사용자들이 대체로 좋아한다고 생각하는 사람이 어떻게 있을 수 있는지는 나에게는 더 미스터리하다. Blackboard와 비슷한 또 다른 예로는 Discourse(포럼 소프트웨어)의 웹 성능이 있을 수 있는데, 이 글을 쓰게 된 계기 중 하나가 이 글을 쓰게 된 동기가 된 Discourse 성능이 훌륭하다고 생각하는 Discourse 직원들과의 대화였다. 그 사례가 흥미로웠던 이유는 Discourse가 실제로 LCP 같은 웹 성능 지표를 속이기 위해 실제 페이지 로드를 늦추는 코드를 넣고 있었기 때문이다. 그건 단순히 벤치마크에 최적화하는 수준을 넘어, 사용자에게 아무 이득도 주지 못할 뿐 아니라 오히려 해를 끼치는 실질적인 부정행위 수준이었다. 어느 정도 선에서는 그런 부정행위를 구현하고, 사용자가 실수로 그 속임수를 무력화하지 않도록 조언하는 프로그래머들이 자신들의 앱 실제 성능이 형편없다는 걸 알 수밖에 없겠지만, 사람들은 이런 종류의 일에 대해 정신적 장벽을 치는 것이 아주 쉽다.

이제 와서는 이런 일을 충분히 많이 봐서, 오히려 일어나지 않는 게 더 놀랍다고 느낄 정도라 놀라진 않는다고 하겠지만, 그래도 이런 일이 일어날 때 사람들의 머리 속에서는 대체 무슨 일이 일어나는 건지 궁금하다.

프로그래밍과 무관한 예로, 우리는 이전에 ‘자명한’ 사실에 대해 사람들이 어떻게 다른 관점을 가지는지에 대한 글에서 언급한 적이 있는데, 주관적으로는 그 시대를 통틀어 가장 더티한 선수로 널리 여겨지는 농구 선수가 있다. NBA는 선수의 더티함을 객관적으로 측정하는 지표를 추적하지 않지만, 그는 다양한 척도에서 압도적으로 보인다. 예를 들어, 1950년 이전의 리바운드처럼 사타구니 타격은 공식 기록으로 집계되지 않지만, 그는 이번 세기 동안 상대 선수의 사타구니를 주먹으로 치고, 발로 차고, 무릎으로 가격하는 등 타격한 횟수에서 분명히 기록을 보유하고 있을 것이다(시대 보정을 하면 역시 1위여야 하겠지만, 80년대와 90년대에 플레이 자체가 전반적으로 훨씬 더 거칠었기 때문에 역대 기록은 아닐 수도 있다). 논의에서, 그 팀 팬들 대부분은 이를 알아차리지 못하는 것 같고, “자연스러운 리바운드 동작”과 “자연스러운 슈팅 동작”이라는 문구는 그 선수가 다른 선수의 사타구니를 가격할 때 몸을 비트는 동작을 정당화하려는 팀 팬들의 둔감함을 비꼬는 유행어가 되었다.

평균적으로 인간은 자신이 팬인 대상, 특히 자신의 작업이나 자기 회사의 작업에 있는 부정적인 측면을 무시하는 능력이 뛰어나다. 좋든 싫든 나는 그 반대인 것 같고, 내 머릿속은 즉시 나와 내 작업의 결함으로 향한다. 블로그 글을 계기로 여러 번 “누가 당신의 작업을 비판하면 기분이 어떻겠냐”거나 “누가 당신의 작업이 별로라고 하면 어떻겠냐”는 식의 메시지를 받은 적이 있다. 전자에 대해서는, 나는 내 논리의 허점을 찌를 수 있는 사람들로부터 비판을 받기 위해 엄청난 노력을 기울이므로, 내 작업에 대해 조금이라도 합리적인 비판을 받는다면 정말 멋진 일이라고 생각한다. 그리고 후자에 대해서는, 나는 내 작업이 대체로 중대한 결함 투성이라고 생각하므로, 음, 그렇다, 별로라고 하는 게 꽤 합리적으로 들린다. 내 작업 중 흥미롭거나 좋다고 생각하는 부분도 있지만, 전반적으로 내가 해온 것 중 좋다고 평가할 만한 게 있는지 모르겠다. 내게 맹점이 없다는 얘기는 아니다. 하지만 이 특정한 맹점에 대해서는 대부분의 사람들보다는 조금 덜 취약하다고 생각한다².

습관화된 우회법

내가 가졌던 비슷한 맹점을 생각해보면, 어렸을 때 친구가 내 컴퓨터를 썼던 일이 바로 떠오른다. 이 이야기를 이해하려면 이게 기계식 마우스 시절이었다는 걸 알아야 한다. 시간이 지나면 먼지가 마우스 볼에 끼어 청소하지 않으면 마우스가 불규칙하게 움직였다.

친구가 내 컴퓨터를 쓰려고 했을 때, 마우스 포인터 움직임이 거의 무작위처럼 보여 마우스를 쓰는 게 불가능하다고 했다. 내가 다시 컴퓨터 앞에 앉아 마우스를 써보니 전혀 문제가 없었지만, 포인터를 직선으로 부드럽게 움직이기 위해 내 손이 뭘 하고 있는지 보니, 손을 사방으로 격렬하게 휘두르고 있었다. 나는 먼지가 쌓이는 동안 점차 그에 적응해서, 마우스의 극도로 불규칙한 움직임을 상쇄하는 불규칙한 손놀림으로 보상하고 있었던 것이다³. 내가 그런 행동을 하고 있다는 걸 전혀 알아차리지 못했다는 사실이 꽤 놀랍다고 생각했고, 지금도 뭔가 비슷한 걸 하고 있는 건 아닌지 항상 궁금하다.

나는 때때로 버그를 우회하기 위해 내가 발전시켜온 모든 완화책들을 생각해본다. 예를 들어 새 Google Docs 문서를 열 때 나는 예전에는 바로 원하는 제목을 입력하곤 했다. 어느 시점, 아마 10년쯤 전에 Google Docs가 일종의 지연을 추가해서 문서를 열자마자 제목 상자에 입력한 내용이 덮어쓰여 버리게 됐고, 그래서 이제는 Google Docs를 연 뒤에 다른 일을 먼저 하고 나서 제목을 바꾸는 습관이 생겼다. 시간이 지나면서 Google Docs에 점점 더 많은 기능이 추가되자, 나는 온갖 함정을 피하기 위한 일련의 습관들을 발전시켰다(예를 들어 “잘못된” 타이밍에 검색을 시도해서 Google Docs 검색 대신 쓸모없는 브라우저 기본 검색이 뜨는 경우 같은 것).

내 느낌으로는 컴퓨터 리터러시와 소프트웨어 리터러시의 상당 부분은 이런 습관들의 방대한 라이브러리를 무의식적인 수준에서 수행하도록 발전시키는 것이다. 이런 것들은 종종 상황에 매우 특화되어 있다. 예를 들어 내가 Microsoft에서 일할 때 생긴 습관으로, 로그인하기 전에 노트북의 WiFi 스위치를 끄는 것이 있었다(다른 사람들도 그렇게 하는 걸 봤다). 당시 어떤 서비스 때문에 “There are currently no logon servers available to service the logon request”라는 메시지와 함께 로그인이 자주 실패했기 때문이다. 하지만 그 서비스가 아예 연결 자체를 못 하면 그 검사가 우회되어 그냥 로그인이 됐다.

품질 맹점

그런 예시들로 글 하나를 가득 채울 수도 있지만, 글의 본론으로 돌아가서, 품질 맹점을 극복하기 위해 흔히 제안되는 방법 중 하나는 사람들이 자신의 소프트웨어를 직접 써보게(dogfooding) 하는 것이다. 평균적으로 이는 전혀 직접 써보지 않는 것보다 훨씬 낫지만, 사람들이 소프트웨어가 가진 문제를 우회하는 습관을 터득하고(그리고는 잊어버리고) 하지 않는 정도까지만 효과가 있다. 평균적으로 프로그래머들은 소프트웨어의 변덕을 우회하는 데 꽤 능숙하다(LLM 이전 시대에 유능한 프로그래머가 되려면 그래야만 했다), 그래서 주의하지 않으면 프로그래머들이 이런 종류의 문제를 알아차리지 못하는 건 매우 쉽다.

반면, 앱을 사람들이 쓰기 쉽게 만드는 일의 큰 부분은 이런 이상한 습관들을 불필요하게 만드는 것 같다. 말로 들으면 쉬워 보이지만, 사람들이 이런 종류의 피드백을 주려는 걸 여러 번 본 경험에 따르면, 대부분의 개발자들의 반사적인 반응은 “어? X를 하는 건 쉬운데, 그냥 [앱을 여러 번 써보지 않았거나 누가 특별히 설명해주거나 다른 사람이 하는 걸 보지 않았다면 일반인은 절대 생각해내지 못할 복잡한 절차]를 하면 되잖아”라거나 “어? 부록 B 261페이지의 단계를 실행한 뒤 매뉴얼 43페이지에 설명이 명확하게 나와 있는 걸 못 봤어?”라는 식인 것 같다.

그렇다고는 해도, 나는 사람들이 품질 맹점을 고치는 것이 가능하다고 생각한다. 내가 꽤 여러 번 해봤기 때문이다. 이건 상대가 수용적일 때만 제대로 통하는 것 같다. 사람들은 의도적인 맹목에 대해서는 무한한 능력을 가지고 있지만, 수용적인 경우에는 그냥 그들이 못 본 문제를 짚어주는 것만으로도 효과가 있는 것 같다. 몇 년, 심지어 10년 뒤에 사람들이 이제는 어디서나 버그가 보인다고 말해주기도 한다.

이걸 할 가치가 있다고 생각하는 이유는, 품질 맹점이 심한 사람과 팀이 제품 품질 문제 때문에 성공 가능성이 낮아지거나 아예 없어지는 것을 출시하는 걸 봐왔기 때문이다⁴. 속도를 위해 품질을 의도적으로, 또 심사숙고해서 맞바꾸는 건 한 가지 일이지만⁵, 내가 봐온 경우들에서는 프로젝트에 참여한 모든 사람이 실제로는 그렇지 않은데도 자신들이 아주 고품질의 무언가를 출시하고 있다고 믿는 일종의 품질 맹점이 항상 있었다.

이 문제는 예전에도 중요하지 않았던 적이 없지만, 코딩 에이전트와 함께 더 중요해졌다. 저품질 소프트웨어를 찍어내는 것이 그 어느 때보다 쉬워진 동시에, 더 나은 성능이든 더 적은 버그든 품질을 개선하는 것도 그 어느 때보다 쉬워졌기 때문이다.

하지만 그렇게 하려면, 실제로 알아차려야 한다. 품질이 개선될 수 있다는 것을.

Yossi Kreinin, Dennis Snell, Michael Malis, Emu Chu, Gary Bernhardt, Jon Surrell, Matt Mullenweg에게 코멘트/교정/토론에 감사드립니다.

당연하게도, Gary Bernhardt는 이 글의 초안을 읽는 동안 Google Docs 버그를 겪었다.

P.S. 지난 네 개의 글에서 언급했듯이, 나는 글을 더 빠르게 쓰려고 노력하고 있다. LLM 덕분에 데이터를 보고 무언가를 파악하는 것은 훨씬 쉬워졌지만, 나는 LLM으로 글을 쓰지 않기 때문에 글을 작성하는 데 걸리는 시간은 근본적으로 달라지지 않았다. 품질-속도 트레이드오프 공간에서 다른 지점으로 옮겨가고 싶지 않다면 말이다. 이전에는 실험을 돌리고 몇몇 친구들에게 이야기한 뒤, Amdahl의 법칙 때문에 글을 쓰는 것이 실험을 위한 내 대역폭을 사실상 모두 잡아먹어버려 결국 아무 글도 쓰지 않는 결과가 되곤 했다. 실제로 이렇게 하려고 노력했음에도(목표는 글 하나당 작성에 30분을 쓰는 것이다), 지난 글을 쓴 이후로 나는 충분히 괜찮은 블로그 글이 될 만한 결과 세 가지를 아직 글로 쓸 시간이 없었다(업무로 한 것들은 제외인데, 그걸 포함하면 몇 개가 더 늘어난다). LLM이 대신 써주지 않는 한, 글 하나당 시간을 30분보다 훨씬 아래로 줄일 합리적인 방법은 보이지 않는다(그리고 나는 종종 목표를 넘겨 30분보다 더 오래 걸리는 것 같다). 그래서 LLM 없이 선택할 수 있는 옵션은 평소보다 훨씬 엉성한 글(인간적인 의미의 슬롭) 몇 개를 쓰거나, 아니면 거의 글을 쓰지 않는 것이다.

어쨌든, 이런 빠르고(그리고 분명 더 틀릴) 글들에 대해 의견이 있다면 어떻게 생각하는지 알려주세요(X Bsky Mastodon)!

부록: 광고 맹점

Michael Malis(Freshpaint의 창업자이자 전 CEO)는 (메시지에서 한 말이라 메시지 형식 그대로) 이렇게 언급했다.

비슷하면서도 다른 데이터 포인트로 - 광고와 관련해서도 비슷한 맹점을 봤다. 사람들에게 Freshpaint를 설명할 때, 우리는 병원의 마케팅을 돕는다고 말하곤 했다

흔히 받는 질문 중 하나는 병원이 왜 마케팅을 하냐는 것이다. 이상한 건, 주의 깊게 보면 병원들은 마케팅을 엄청나게 많이 한다는 점이다

SF에는 UCSF/Sutter Health/Stanford와 여러 치료법에 대한 버스 광고와 빌보드가 엄청나게 많다

이건 Michael의 코멘트와도 이 글의 주제와도 다른 이야기지만, 나는 광고가 전혀 효과가 없다고 믿는 사람들을 꽤 많이 만나봤다. 하지만 내가 다녔던 한 대기업에서 광고 A/B 테스트에 대해 데이터 방법론과 판단력을 신뢰하는 사람과 이야기를 나눠봤고, 다른 회사에서는 데이터를 직접 살펴봤는데, 그 경우들에서 광고가 실질적인 리프트를 제공한다는 인과적 증거(광고 비용을 훨씬 넘어서는)가 강하다고 생각했다. 내가 직접 본 경우에는 일부 지역에만 광고를 사고 다른 지역에는 사지 않는 지역 분할 A/B 테스트를 했다(전 세계적으로 진행됐고, 지역은 미국 주, 캐나다 주 등으로 나뉘었다). 이런 종류의 지역 분할은, 크로스 디바이스 추적을 해도 누군가가 광고에 노출됐는지 100% 명확하지 않기 때문에 수행됐다(물론 이런 분할에서도 여전히 그렇고, 나는 인구 밀집 지역에 더 군집화되고 예를 들어 경계 한쪽에서 다른 쪽으로 통근할 가능성이 비교적 높은 사람들을 가르는 식의 분할이 없는 방식을 선호하지만, 이런 종류의 오염은 일반적으로 실제 리프트가 추정된 리프트보다 더 높게 만든다). 그래서 사람들은 때때로 이런 지역 분할 A/B 테스트를 한다.

어쨌든, 이 A/B 테스트들에서 광고 지출 대비 수익률은 직접적인 매출 증가만으로도 꽤 좋았고, 사용자 수 증가도 있었는데 이는 앞으로 더 많은 수익으로 이어질 가능성이 높아 보인다(후속 수익은 분석되지 않았다). 광고 효과 일반론이나 여러분의 특정 광고가 효과적인지에 대해서는 모르겠지만, 광고가 일반적으로 효과가 없다는 흔히 반복되는 생각은 내게는 틀려 보인다.

Michael의 코멘트 주제로 돌아가면, 프로그래머들은 광고를 알아차리지 못하기 쉽다고 생각한다. 내가 아는 거의 모든 프로그래머가 광고 차단기를 쓰고, 현실에서도 그들의 눈은 광고를 그냥 훑고 지나가며 알아차리지 못하는 것 같다. 이게 광고가 효과가 없다는 생각으로 이어지는 건 이해할 수 있다. 도대체 누가 이런 걸 쳐다보겠는가? 하지만 “일반” 사람들과의 교류나 Google 재직 시절 내가 접한 데이터에 따르면, 많은, 어쩌면 대부분의 사람들은 많은 광고가 광고라는 사실조차 깨닫지 못한다. Google에서 검색을 하고 맨 위 결과를 클릭할 때, 그들은 자신이 Google이 “생각하는” 최고의 링크를 보는 게 아니라, 그 광고 슬롯을 사기 위해 Google에 가장 많은 돈을 낸 사람의 링크를 보고 있다는 걸 전혀 모르는 경우가 많다.

부록: 다른 사람들의 코멘트

Em Chu가 말한 습관적인 버그 우회법:

이 섹션에 대한 예시는 무한히 모을 수 있겠지만, 그냥 불평하고 싶다: 노트북(Mac)을 깨워서 잠금 해제할 때, “깨어 있는” 것 같지만 사용할 수 없는 상태(커서만 있는 검은 화면 등)에 빠지기 매우 쉽고, 이는 뚜껑을 물리적으로 닫았다가 다시 열어야만 고칠 수 있다. 이를 우회하기 위해 나는 보통 화면이 켜진 뒤 1초 정도 기다렸다가 트랙패드를 만지고 나서 잠금 해제하는 것 같다. 솔직히 이건 거의 무의식적으로 일어나는 일이고, 한 달에 몇 번씩 아직도 이 버그를 겪는 걸 보면 확실히 더 연습이 필요한 것 같다.

이걸 읽고 나는 노트북을 여는 내 방식을 살펴봤고, 다른 노트북 버그들을 우회한 결과 생긴 웃긴 습관들이 있다는 걸 깨달았다. 여기서 언급된 특정 버그는 내 노트북에서는 재현되지 않고, 이전 노트북 때문에 들인 습관적인 우회법을 이제 그만둬도 될 것 같다.

Gary Bernhardt가 이 글 초안을 읽은 경험에 대해

글을 읽는 동안 Google Docs UI가 고장 난 것 같아서, 위로 스크롤해 일부 댓글을 읽는 것이 불가능했다(스크린샷 참조[글에는 표시되지 않음]).

스크린샷을 보니 나는 정확히 같은 버그를 본 적이 있고, 그에 대한 우회법도 몇 가지 가지고 있다(맥락에 따라 다른 것들). 나는 개인적으로 소프트웨어 품질 측면에서 Google Docs를 평균보다 훨씬 높게 평가한다. 주요 대안들(Microsoft Word, OpenOffice, StarOffice나 Lotus 같은 오래전에 사라진 다양한 에디터 등)보다 훨씬 덜 버그가 많고 덜 덜컥거린다고 생각한다. 그럼에도 나는 앉아서 Google Docs 버그와 그에 대한 나의 우회법에 대해 1만 단어짜리 글을 쉽게 쓸 수 있을 것 같다.

때때로 나는 하루 종일 품질 문제만 고치는 일을 할 수 있을지 알아보려 한 적이 있다. 이게 그다지 높은 우선순위가 아니기도 하고, 기업들이 통상적으로 두는 역할이 아니기도 해서 한 번도 성사된 적은 없다. 가끔은 회사에 인턴으로 들어가 몇 달 동안 품질 문제만 고치다 나오는 상상을 하기도 한다. 실제로 그런 일을 맡게 된다면 많은 수정이 막히고 3개월짜리 인턴으로서 변화를 이끌어내기가 매우 어려울 것 같으니, 아무도 내가 뭘 하는지 신경 쓰지 않는 거의 버려진 프로젝트여야 할 것이다(그리고 기업의 우선순위가 기능 출시에만 몰려 있어서 수정 사항이 바로 다시 망가지는 일도 없어야 하고).

@IncidentNoodle

의도치 않게 주제에 부합하는데: <abbr> 태그가 모바일에서 지난주까지는 작동했는데, 이제는 모든 iOS 브라우저(Safari/Chrome/Firefox)에서 작동하지 않고, macOS 브라우저(세 개 모두)에서 hover 시 표시된다는 걸 긴 지연 때문에 파악하기 어려웠다

@[email protected]:

독일어에는 그걸 가리키는 단어가 있다 - Betriebsblindheit

@oulipien.bsky.social:

@danluu.com의 미친 일화인데, 그때 좀 더 직설적으로 이 사람에게 Blackboard가 누구에게도 사랑받고 있다는 믿음을 어디서 얻었는지 물어봤으면 좋았을 텐데. 사용자 설문? 주체(대리인이 아닌) 설문? 내면의 확신??? [Blackboard 일화 스크린샷]

[어떤 변형 : 사람들은 상사 때문에 버그를 못 본다고 말하도록 강요받는다]

나는 이게 글에서 언급된 주요 사례 중 어느 하나와도, 하물며 전부와의 일치는 없다고 생각한다. 위에 언급된 Blackboard 사례를 생각해보자. 나와 그 Blackboard 직원이 만난 다른 사람들이 직원을 점검하는 “미스터리 쇼퍼”일 가능성은 낮고, 그 직원의 반응은 그런 가상의(실제로는 존재하지 않는) 미스터리 쇼퍼가 아닌 누구에게나 명백히 우스꽝스럽게 보인다. 그래서 그렇게 반응하는 건 아무런 이득 없이 만나는 사람 중 상당수에게 다소 우스꽝스럽게 보일 뿐이다(예를 들어 이전 인용문처럼 보이는 전형적인 내부 반응을 보라). 아마 극도로 편집증적인 직원 몇 명은 회사에서 일한다는 걸 아는 상사의 친구나 친척을 만날 가능성에 대비해, 그 이야기가 다시 상사에게 전달되고 상사가 이를 신경 쓸까 봐 이런 태도를 유지할 수도 있겠지만, 이게 (예를 들어) Discourse 성능이 정말 좋다고 설명하러 나에게 연락한 모든 Discourse 직원에게 해당한다고 보기는 전혀 그럴듯하지 않다.

농구 사례를 보면, 이는 더욱 터무니없다. 다른 팬들이 가장 터무니없는 합리화를 믿거나 믿는 척하지 않으면 따돌릴 것이라는 식의 논리를 어떻게든 만들어낼 수도 있겠지만, 스포츠 팬들 주변에서 많은 시간을 보낸 사람으로서 나는 일반적으로 그런 경우가 아니라고 봐왔다. 그리고 그런 경우가 아주 약간이라도 어느 정도 해당한다면, 그건 자기 선택의 문제에 가깝다. 가장 극단적인 합리화에 빠진 팬들은 그런 극단적인 합리화에 빠진 팬들끼리 더 많은 시간을 보내고, 덜 빠진 팬들은 덜 빠진 팬들끼리 더 많은 시간을 보내는 식이다.

또한, 이런 것들을 믿지 않고 고치는 사람들의 커리어 경로를 보면, 이런 문제를 알아차리고 고치는 일은 그들에게 매우 잘 풀렸다. 이런 문제가 존재하지 않는 척하는 것(의식적인 수준에서든 아니든)도 잘 통하는 것 같으니, 이런 문제를 고치는 것이 실제로 더 나은 커리어 경로인지는 모르겠지만, 일반적으로 이런 것들이 존재하지 않는 척해야 할 만큼 커리어상의 압박이 의미 있게 존재하는 경우는 아니다. 비록 개별 직책 중에는 이런 문제가 실제로 존재하지 않는 척하라는 직접적인 압박이 있는 경우도 있겠지만.

Daniel Gibson:

스크린세이버를 끌 때 Shift 키를 쓰는 사람 또 누가 있나요? 혹시 이벤트가 실제 프로그램까지 전달되더라도 의도치 않은 효과를 낼 가능성이 가장 적기 때문에?

이건 내가 대기 중인 메시지를 codex에 즉시 보내고 현재 도구 호출을 중단시키고 싶을 때, 손가락을 키 위에 올려놓고 가능한 한 빨리 눌러서 도구 호출이 끝나고 Escape 키가 codex 전체를 멈추는 대신 메시지가 전송되도록 하는 시간 창을 줄이는 걸 떠올리게 한다. 나는 아마 이상한 워크로드 특화 최적화 버전의 ripgrep을 시도해 보는 것처럼, 이 문제와 내가 겪은 몇 가지 다른 문제에 대한 수정 사항이 포함된 codex의 패치 버전을 그냥 실행해야 할 텐데, 그 ripgrep은 다른 스레드에서 매칭 표현식을 컴파일하는 네이티브 코드 컴파일러가 추가되어 검색이 시작되는 동안 컴파일하고 컴파일이 끝나면 전환하는 방식이다. 그러니 내가 워크플로를 개선하기 위해 이상한 패치를 만드는 걸 반대해서가 아니라, 전반적인 대역폭 문제에 가깝다(의심할 여지 없이, 이걸 쓰고 나면 누군가 다른 키를 누르면 됐고 codex에 그 키에 대해 물어보는 데 이 코멘트를 쓰는 데 걸린 시간만 썼어도 알 수 있었다고 말해줄 것이다). Google Docs와 마찬가지로 나는 codex를 해당 분야에서는 소프트웨어 품질 측면에서 평균 이상이라고 평가하지만, 1년도 쓰지 않았는데도 내가 구현한 모든 우회책(습관으로든, 어떤 경우에는 실제로 깨진 동작을 감지하고 수정하는 스크립트로든)에 대해 1만 단어 글을 쉽게 쓸 수 있을 것 같다.

John Regehr:

이 글을 쓰고 발행한 뒤 누군가 John의 글을 링크하기 전까지는 기억하지 못했는데, John Regehr가 내가 블로그를 시작하기 전에 “Operant Conditioning by Software Bugs”를 썼다고 한다! LLM으로 선행 기술을 검색했어야 했을지도 모르지만, 그렇게 했다면 아마 절대 아무것도 쓰지 못했을 것이다. 정말로 새로운 아이디어는 그리 많지 않고 거의 모든 것이 다른 누군가가 말한 것과 비슷할 것이기 때문이다. 좋든 싫든 나는 John보다 훨씬 장황해서, 이 글은 훨씬 더 많은 단어를 쓰고 더 많은 무작위적인 이야기들을 집어넣었다. 내 블로그 글이 너무 길다고 생각하지만 어떻게든 글 하단까지 내려온 분이라면, 아마 내 글보다 John의 글을 더 좋아할 것이다 :-).