바닐라 아이스크림에 알레르기를 보이는 자동차 (2000)
(cs.cmu.edu)- 새 Pontiac 소유자는 저녁마다 아이스크림을 산 뒤 바닐라를 골랐을 때만 차가 시동되지 않는다고 General Motors Pontiac Division에 항의함
- Pontiac 사장은 편지를 의심했지만 엔지니어를 보냈고, 현장에서 바닐라 구매 후 시동 실패가 실제로 재현됨
- 초콜릿과 딸기를 산 날에는 시동이 걸렸지만 바닐라를 산 날에는 다시 실패해, 황당해 보이는 조건이 반복적으로 확인됨
- 엔지니어는 시간, 연료 종류, 왕복 시간, 구매 시간을 기록하다가 바닐라만 매장 앞 별도 냉장고에서 빠르게 살 수 있다는 동선 차이를 발견함
- 원인은 아이스크림 맛이 아니라 짧은 구매 시간 때문에 엔진이 충분히 식지 않아 생긴 vapor lock이었고, 이상한 신고도 관찰과 재현으로 검증해야 함
Pontiac의 이상한 시동 문제
- 한 Pontiac 소유자는 General Motors의 Pontiac Division에 두 번째 편지를 보냄
- 가족은 매일 저녁 식사 후 디저트로 먹을 아이스크림 맛을 투표로 정했고, 그는 매번 차를 몰고 가게에 가서 아이스크림을 사 옴
- 새 Pontiac을 산 뒤 특정 조건에서만 문제가 반복됨
- 바닐라 아이스크림을 사면 가게에서 돌아와 차를 시동할 수 없음
- 다른 맛을 사면 차가 정상적으로 시동됨
- 그는 질문이 어리석게 들릴 수 있음을 인정하면서도, 왜 Pontiac이 바닐라를 살 때만 시동되지 않는지 물음
현장 확인과 반복 재현
- Pontiac 사장은 편지를 회의적으로 봤지만 엔지니어를 보내 직접 확인하게 함
- 엔지니어는 저녁 식사 직후 차주를 만나 함께 아이스크림 가게로 감
- 그날은 바닐라를 사는 날이었고, 두 사람이 차로 돌아오자 실제로 시동이 걸리지 않음
- 이후 사흘 동안 조건을 바꿔 확인한 결과가 뚜렷했음
- 첫날 초콜릿을 샀을 때는 차가 시동됨
- 둘째 날 딸기를 샀을 때도 차가 시동됨
- 셋째 날 바닐라를 샀을 때는 다시 시동에 실패함
관찰 기록에서 나온 단서
- 엔지니어는 차가 바닐라 아이스크림에 알레르기가 있다는 해석을 받아들이지 않음
- 문제를 풀 때까지 계속 방문하기로 하고 여러 데이터를 기록함
- 시간대
- 사용한 연료 종류
- 가게까지의 왕복 시간
- 구매에 걸린 시간
- 결정적인 단서는 바닐라 구매 시간이 다른 맛보다 짧다는 점이었음
- 매장 배치가 시간 차이를 만들고 있었음
- 바닐라는 가장 인기 있는 맛이라 빠르게 집어 갈 수 있도록 매장 앞 별도 냉장고에 있음
- 다른 맛은 매장 뒤쪽 다른 카운터에 있어 맛을 찾고 계산하는 데 훨씬 오래 걸림
실제 원인: vapor lock
- 문제의 핵심은 아이스크림 맛이 아니라 짧은 대기 시간이었음
- 엔지니어는 시간이 원인이라는 점을 파악한 뒤 vapor lock을 원인으로 찾음
- vapor lock은 매일 발생하고 있었지만, 다른 맛을 살 때는 구매 시간이 길어 엔진이 충분히 식었고 시동이 가능했음
- 바닐라를 살 때는 구매 시간이 너무 짧아 엔진이 아직 뜨거웠고, vapor lock이 사라지지 않아 시동이 걸리지 않음
교훈
- 겉보기에는 말이 안 되는 문제라도 관찰된 사실은 사실일 수 있음
- 황당한 증상처럼 보여도 조건을 반복 확인하고 데이터를 모으면 실제 원인을 찾을 수 있음
댓글과 토론
Hacker News 의견들
-
90년대 후반 직장에서 비슷한 일이 있었음. 어떤 직원의 마우스가 하루 중 특정 시간대에만 멈췄고, 아침에는 괜찮다가 점심 무렵 안 되다가 나중에 다시 됐음
흐린 날에는 하루 종일 멀쩡했지만, 맑은 날에는 같은 이상 동작이 반복됐다는 게 결정적 단서였음. 알고 보니 싸구려 볼마우스의 플라스틱 케이스가 너무 얇아서, 맑은 날 햇빛이 X/Y축 센서를 LED보다 압도해 버렸고, 해가 움직여 그림자가 생긴 뒤에야 다시 정상 동작했음. 처음엔 황당했지만 완전히 논리적인 원인이었음- 오래전 iPhone 4에서도 비슷한 문제가 있었음. 어두운 곳에서 부팅하면 Apple 로고에서 무한 부팅 루프에 빠졌음
iOS 7.1.x용 Pangu 탈옥 일부 버전은 주변광 센서 값이 특정 임계값보다 낮으면 부팅 중 크래시가 났던 것으로 보임. 정확한 원인은 아직 모르지만, Pangu에 광센서를 건드리는 불필요한 코드가 들어갔던 듯함 [1]
[1] https://www.reddit.com/r/jailbreak/comments/294wob/jailbreak...
[2] https://www.reddit.com/294wob/ - 반대 방향의 비슷한 문제가 있었음. 집의 케이블 인터넷 속도는 평소엔 괜찮았지만 가끔 죽지는 않고 빙하처럼 느려졌음
온갖 문제를 확인한 끝에 비가 올 때가 아니라, 짙은 안개나 이슬비가 낄 때 문제가 생긴다는 걸 알게 됐음. 케이블 회사 기사 확인 결과 집 안은 멀쩡했고, 메인 라인에서 집으로 오는 케이블에 아주 작은 상처가 있어 주변 습기가 스며들어 연결을 망가뜨리고 있었음 - 집의 조리대용 제빙기도 비슷한 이유로 맑은 날에는 얼음이 걸리고 과도하게 만들어짐
얼음통이 차면 적외선 빔이 막혀서 제빙을 멈춰야 하는데, 맑은 날 주방의 밝은 빛이 센서를 속여 계속 얼음을 만들게 됨. 그래서 임의의 잡지를 위에 올려 제대로 동작하게 해 둠 - 직장의 CI 시스템이 진동에 취약하다는 사실이 드러난 날이 떠오름
어느 날 갑자기 그래픽 X 클라이언트 앱 관련 테스트가 간헐적으로 실패하기 시작했는데, 다른 조건에서는 재현이 안 됐음. 알고 보니 CI 작업은 사내 어딘가에 둔 데스크톱 머신들에서 돌고 있었고, 누군가 한 머신에 마우스를 꽂아 선반 위에 방치했음. 머신 부하가 높아지면 팬이 빨라지고 진동이 커져 마우스가 아주 조금 움직였고, 알 수 없는 이유로 그것이 테스트에 부작용을 냈음. 현장에 있지도 않은 머신을 SSH로 진단해내서 꽤 뿌듯했음 - 맑은 날에는 아내 차가 차고문을 못 열고, 내 차도 아주 가까이 가야 열림. 해가 지면 둘 다 거리에서 바로 열 수 있음
알고 보니 태양광 패널이나 옵티마이저, 인버터가 차고문 리모컨과 간섭하는 무선 주파수를 내고 있었음. 햇빛이 있어 전력을 생산할 때 간섭이 homelink 차고문 오프너보다 강해졌음. 몇 년 전 차고문 오프너가 갑자기 잘 되기 시작했는데, 며칠 뒤 인버터가 고장 났기 때문이라는 걸 알았음. FCC 규정상 설치 업체가 고쳐야 할지도 모르지만, 설치 때 관계가 틀어져서 보증 수리로 상대하느니 리모컨을 포기하는 편이 낫다고 봄
- 오래전 iPhone 4에서도 비슷한 문제가 있었음. 어두운 곳에서 부팅하면 Apple 로고에서 무한 부팅 루프에 빠졌음
-
서버실이 있던 시절의 전해 들은 웃긴 일화임. 친구 회사 서버가 매일 오후 5시쯤 재부팅됐고, 운영체제 쪽으로 가능한 모든 걸 확인해도 원인을 못 찾았음
결국 그 시간에 서버 앞에 서 있기로 했고, 청소 담당자가 방에 들어와 서버 랙 전원을 뽑고 진공청소기를 꽂아 청소한 뒤 다시 서버 랙을 꽂는 장면을 봤음- 직접 방 안에서 디버깅했던 비슷한 일이 있음. 도로 교통량을 세는 스마트 카메라 제품을 만들고 있었고, 시의회 같은 곳에서 도로에 설치해 화물차·승용차·오토바이 통계를 내는 장비였음
어떤 카메라는 매일 거의 같은 시간에 재시작했는데, 정확히 같은 초는 아니고 하루는 19:12:10, 다음 날은 2초 뒤, 그다음 날도 2초 뒤처럼 뚜렷한 패턴이 있었음. 알고 보니 해가 질 때 거리 시설물이 카메라 앞에 그림자를 드리웠고, 소프트웨어가 이를 차량으로 잘못 판단해 분류 정보를 모으기 시작했음. 그림자는 실제 차량보다 훨씬 느리게 움직이기 때문에 프레임 밖으로 나가기 전에 메모리가 고갈됐고, 시스템이 멈춘 뒤 워치독이 재시작시켰음. 시간 패턴은 태양 각도가 매일 바뀌어 그림자가 알고리즘을 조금씩 늦게 속였기 때문이었음 - 이 이야기는 이제 거의 도시전설로 보임. Reddit 스레드[0]에서도 80년대에 돌던 컴퓨터 이야기로 1990년에 수집됐다고 나옴[1]
[0] https://old.reddit.com/r/talesfromtechsupport/comments/5yrs1...
[1] https://www.goodreads.com/book/show/3227607-the-devouring-fu... - 개인적으로도 비슷한 일을 겪었음. 회계법인 서버를 관리했는데, 인쇄 서버가 가끔 오전 9~10시 사이에만 재부팅됐음
그 시간대에 일주일 동안 앉아 있다가 조명이 어두워지고 재부팅이 일어나는 걸 봤음. 옆 사무실 변호사가 출근해서 PC, 프린터, 커피포트를 같은 멀티탭에서 동시에 켰고, 시동 전류 때문에 서버가 물린 회로 전압이 떨어졌음. UPS가 있었지만 당시 소비자용 UPS는 정전만 처리했고, 전압이 85V까지 떨어지는 걸 측정했으며 실제로 95V 이하에서는 재부팅되곤 했음 - 1999년 독일 Stuttgart 남동쪽 작은 지방자치단체 시청에서, 반년 사이 세 번째로 MS SQL DB의 깨진 인덱스를 고치러 현장에 갔음
금요일 이른 오후였고 덥고 습한 날씨에 뇌우가 오려던 참이었는데, 16시쯤 담당자가 와서 17시에 건물 전체 전기를 끊으니 서두르라고 했음. 매주 금요일마다 에너지 절약을 위해 전원을 내리고 있었고, 하필 매주 금요일 16:30에 DB 정리가 예약돼 있었음. 그래서 남은 한 시간 동안 문제를 고치고 그 주 일정을 취소한 뒤 DB 서버를 수동 종료했음. 매주 전원을 강제로 내려 Netware 서버와 수금 소프트웨어 DB 서버에 생산 장애를 만들었고, 유지보수 계약상 매번 우리가 고쳐야 했음. 결국 한 달쯤 지나서야 강제 전원 차단을 토요일 아침으로 미뤄, 백업 작업 완료 뒤 서버가 제대로 종료될 수 있게 했음
- 직접 방 안에서 디버깅했던 비슷한 일이 있음. 도로 교통량을 세는 스마트 카메라 제품을 만들고 있었고, 시의회 같은 곳에서 도로에 설치해 화물차·승용차·오토바이 통계를 내는 장비였음
-
80년대에 처남이 몰던 GM 미니밴이 떠오름. GM 자동차 엔지니어였던 장인이 준 차였는데, 가끔 무작위로 시동이 안 걸리고 전기계통 전체가 죽은 것처럼 보였음
처남은 차를 잘 모르는 사람으로 여겨져 장인은 불평을 진지하게 받아들이지 않았음. 결국 한 달간 차를 바꿔 타기로 했고, GM Technical Center 주차장에서 문제가 재현됐으며, 주변에 모인 GM 엔지니어들도 왜 전기계통이 죽은 것처럼 보이는지 알아내지 못해 처남은 억울함을 풀었음- 2009년식 Mercedes SLK에서도 같은 증상이 있었음. 99.9%는 완벽했지만, 천 번에 한 번꼴로 시동을 걸려는 시도조차 하지 않았고 딸깍 소리도, 키를 돌린다는 인식도 없이 완전히 죽은 것처럼 보였음
몇 시간 뒤에는 아무 일 없었다는 듯 시동이 걸려 서비스센터에서도 진단할 수 없었음. 나중에는 오프로드 캠핑 중에도 시동이 안 걸려 생활에 영향을 주기 시작했고, 결국 집 진입로에서 안 걸린 상태로 독립 정비소에 견인했더니 그곳에서도 재현됐음. 정비사는 ECU 모듈 교체 또는 퓨즈박스 자체 교체를 제안했고, ECU는 수천 달러지만 퓨즈박스 교체는 공임 포함 200달러 미만이라 후자를 골랐음. 6~7년이 지난 지금도 그 차가 주된 유일한 차이고, 이후 기계적 문제가 한 번도 없었음 - 하이젠버그식 버그는 전체 시스템 설계 실패의 징후임. 문제 해결을 쉽게 하도록 설계되지 않았고, 하위 시스템이 강하게 결합돼 있으며, 모든 것이 철사와 껌으로 겨우 붙어 있는 프로젝트에서 나타남
악명 높은 시기의 GM 차량이 사람 미치게 하는 미스터리한 전기 문제를 겪는 건 충분히 그럴듯함 - GM 차는 가끔 악령이 들린 듯한 이상한 문제를 만드는 것으로 악명이 있음. 1990년 이후 GM 차가 전반적 신뢰성에서 일본차에 꽤 가까워졌는데도 그렇다
- 이 스레드에는 간헐적으로 켜지지 않는 차가 많지만, 예전엔 간헐적으로 꺼지지 않는 차도 있었음. 적어도 헤드라이트가 꺼지지 않았음
어디선가 릴레이가 과열돼 닫힌 상태로 남았던 것 같지만, 직접 디버깅하지도 못했고 자동차 정비사였던 사촌도 못 찾았음. 크게 애쓰진 않았고, 그런 일이 생기면 퓨즈를 빼고 다음 날 아침 다시 꽂았음 - 추측하자면 새 배터리가 필요했을 수도 있음. 내 GM 차도 배터리가 오래되면 시동 때 이상한 동작을 보였음
스타터는 잘 돌 때가 많지만, 전자장치가 이상한 상태에 갇혀 배터리를 분리해 하드 리셋해야 풀리곤 했음
- 2009년식 Mercedes SLK에서도 같은 증상이 있었음. 99.9%는 완벽했지만, 천 번에 한 번꼴로 시동을 걸려는 시도조차 하지 않았고 딸깍 소리도, 키를 돌린다는 인식도 없이 완전히 죽은 것처럼 보였음
-
예전 집에서 전자기기와 관련해 이상한 반복 현상을 겪었음. 특정 요일 자정에 고정된 전자기기들에서 2차대전 정치 연설 녹음처럼 들리는 소리가 희미하게 났음
소리가 너무 희미해 한 곳을 특정하기 어려웠고, 말은 알아들을 수 없어서 오래된 녹음이 사방에서 동시에 들리는 것 같았음. 전원을 뽑아도, 집에 정전이 나도 계속됐음. 미치고 있거나 집에 히틀러 유령이 들렸나 생각했는데, 나중에 차 라디오에서 비슷한 걸 듣고 알게 됐음. 가톨릭 AM 라디오 방송국이 같은 요일 같은 시간에 그레고리오 성가와 설교로 송출 시작을 했고, 집 배선이 어떻게든 AM 라디오 수신기처럼 동작해 일부 부품이 무선 신호에 실린 오디오를 진동으로 내고 있었음- AM 라디오는 여러 면에서 끔찍한 전송 형식이지만, 이렇게 소리로 복조하기가 매우 쉽다는 장점도 있음
- 직장 근처 공장 앞 약 25피트 구간에서는 거의 모든 FM 방송국이 Muzak에 눌리는 곳이 있음. 그 공장에서 무슨 일이 벌어지는지 모르겠고, 진지하게 FCC에 연락할까 생각한 적이 있음
- 정말 놀라운 일임. 나였으면 창문 주변에 소금 결계를 치고 있었을 듯함
-
아들이 American Truck Simulator를 할 때마다 노트북 화면이 꺼졌고, 화면이 검은 동안 트럭이 도로 밖으로 나갔음
내가 같은 노트북으로 플레이하면 그런 일이 없어서 아들은 저주받았다고 확신했음. 며칠 동안 반복된 뒤 옆에서 플레이하는 모습을 관찰하다가, 아들의 시곗줄이 자석 잠금식 금속 밴드라는 걸 알아챘음. 손목 위치가 노트북의 홀 센서를 건드려 덮개가 닫혔다고 판단하게 만든 것이었음. 아들과 나, 그리고 아내 모두 그가 저주받지 않았다는 걸 알고 안도했음- 이 버그 때문에 Apple은 화면 각도 센서를 다른 방식으로 바꿨음. 그리고 Apple답게 그 센서를 직렬화할 명분도 생겼음
https://www.ifixit.com/News/33952/apple-put-a-hinge-sensor-i... - 대학 헬프데스크에서도 가끔 맞닥뜨렸음. 열린 MacBook을 닫힌 MacBook 위에 올려놔도 생길 수 있었고, 자석이 쉽게 맞물려 화면이 꺼졌음
- 이 버그 때문에 Apple은 화면 각도 센서를 다른 방식으로 바꿨음. 그리고 Apple답게 그 센서를 직렬화할 명분도 생겼음
-
이런 이야기들이 Car Talk를 그렇게 재미있게 만들었음. 단순히 정비사가 차를 고치는 이야기가 아니라, 상황이 워낙 기묘하고 특이해서 흥미로웠음
오래 일한 정비사들이 이런 이상한 상황을 너무 많이 봐서 오히려 평범하게 받아들이는 걸 듣는 재미도 컸고, 게다가 이야기꾼으로도 훌륭했음- “정비소에 가서 가장 나이 많은 사람을 찾아라. 그 사람은 카뷰레터를 다룰 수 있을지도 모른다”
-
“말도 안 돼 보이는 문제도 때로는 진짜다”가 교훈이라기보다, 내게는 사용자의 문제는 대개 실제로 존재하지만 원인 진단 능력은 믿지 말라가 교훈임
- 다르게 말하면, 이야기 속 관찰된 사실과 추론을 구분해야 함. 추론을 버린다고 해서 관찰 자체까지 무시하면 안 됨. 이는 XY 문제와도 비슷함
- 근접 원인과 근본 원인은 크게 다름. 근접 원인은 바닐라 아이스크림 구매이고, 근본 원인은 베이퍼 록임
편지는 아이스크림이 근본 원인이라고 주장하지 않았고, 근접 원인임을 매우 분명히 했음. Pontiac 사장과 그 “교훈”을 쓴 사람은 둘을 혼동했을 수 있지만, 조사한 엔지니어는 그러지 않았음 - 문제 해결자는 이론 하나에 너무 빨리 갇히면 안 됨. 맞지 않는 다른 정보를 쉽게 놓칠 수 있음
- 제목이 일부러 도발적이었지만 읽자마자 타이밍 문제가 먼저 떠올랐음. 타이밍 문제를 자주 다뤄서 운 좋게 떠올린 것일 수도 있지만, 사용자가 그 정도는 눈치챘을 거라 생각해 그 가설을 버렸음. 아니었음
개발 업무 중 헬프데스크도 해본 경험상, 사용자는 임의의 사실을 문제의 원인으로 쉽게 지정함. “상관관계가 인과관계다”나 post hoc ergo propter hoc 같은 휴리스틱은 도움이 될 수 있지만, 추론을 대체하면 나쁨. 사용자는 자신이 쓰는 물건의 동작 원리를 모르기 때문에 제대로 진단하기 어렵고, “그런 거 좀 안다”고 생각하는 사용자가 오히려 가장 다루기 어려운 편임
-
아내 차는 지금 워셔액이 부족한데, 운전 중 특정 지점에서만 경고가 뜸. 집에서 특정 거리도 아니고 정확한 위치임
처음에는 어딘가 갔다 돌아오는 시간 때문인가 했지만, 그 전까지 5분을 몰았든 5마일이든 1시간이든 60마일이든 항상 그 위치에서 화면과 소리 경고가 뜸. 추가 단서는 그 지점이 대부분의 휴대폰·통신사에서 음영 지역이라는 것뿐임. 워셔액을 채워서 미스터리는 잠복기에 들어갔지만, 모든 경고가 그때 뜨는지 궁금함. 그 지점에서 차량 텔레메트리가 건드려져 깨어나 뭔가 말하는 것 같기도 함- 그 위치의 경사가 센서 지점에서 액체 수위를 낮게 만들 수 있음. 어느 축으로든 특이한 경사가 있나?
- 내 경우도 비슷하지만, 그 위치의 완만한 커브와 비교적 높은 속도가 합쳐져 워셔액이 탱크 한쪽으로 몰리는 것이 분명했음. 센서는 반대편에 달린 것 같음
- 내 Subaru는 고속도로 출구에서만 워셔액 경고를 띄우는데, 속도와 경사 변화 때문임
- 강한 전자기 간섭이 있는 지역처럼 들림. 지하 센서가 있는 신호등, 고압선 아래, 변전소 근처, 고출력 라디오 안테나 근처일 수도 있음
센서를 “충분한 액체”에서 “부족”으로 살짝 밀어낼 만큼 이상한 간섭을 줄 수 있음 - 요즘 2019년식 VW Passat에서 같은 일을 겪고 있음. 가속하거나 브레이크를 밟거나 오래 코너를 돌 때 경고가 뜸
그냥 용기 안에서 액체가 움직이는 문제임. 오늘은 차가 낮은 수위 표시등을 계속 켜 두게 하려고 앞유리를 좀 닦았음
-
컴퓨터공학 실습실에서 Java 과제를 하던 밤, 담당 교수가 지나가며 “아, 그 머신에서는 행운을 빌어야겠네”라고 했음
그 머신은 한때 Java 프로그램은 무엇이든 실행하지 못하고 화려하게 죽었지만, C++나 Python은 괜찮았음. 처음엔 믿지 않았던 교수의 프로그램도 그 머신을 크래시시켰음. 기술자와 교수 둘이 약 2주 동안 확인한 결과, JVM이 시작할 때마다 정수 12를 같은 RAM 주소에 할당했고, 그 하드웨어 주소가 들어 있는 RAM 칩이 고장 나 있었음. 해당 주소에 할당하려 할 때마다 크래시가 났고, 나쁜 RAM 스틱을 교체하자 즉시 해결됐음- “이 시점에서 자연스러운 결론은 둘 중 하나다. 심각한 하드웨어 문제가 있거나, 바이너리에 거친 메모리 손상 버그가 있거나”
https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
결론은 스포일러하지 않겠음. 길고 굽이진 디버깅 여정이라 읽을 만함. HN 토론:
https://news.ycombinator.com/item?id=15845118
- “이 시점에서 자연스러운 결론은 둘 중 하나다. 심각한 하드웨어 문제가 있거나, 바이너리에 거친 메모리 손상 버그가 있거나”
-
이 이야기는 교란 변수의 재미있는 예시임
인과 추론에서 교란 변수는 종속 변수와 독립 변수 모두에 영향을 줘 가짜 연관을 만드는 변수임. 상관관계만으로는 설명할 수 없는 인과 개념이며, “상관관계는 인과관계를 의미하지 않는다”의 중요한 정량적 이유 중 하나임
https://en.wikipedia.org/wiki/Confounding
통계 모형으로 쓰면S = f(H, I, T)처럼 볼 수 있음.S는 차가 시동되는지 여부,H는 엔진 온도,I는 고른 아이스크림 종류,T는 아이스크림을 사는 데 걸린 시간임.T가 짧으면 엔진이 더 뜨거운 상태라 베이퍼 록에 취약해져S에 영향을 주고, 바닐라 아이스크림의 위치가 빨리 살 수 있게 해I와도 연결됨. 그래서I와S사이에 가짜 관계가 생김- 흥미로운 설명이지만,
T가I에 영향을 주는 게 아니라I가T에 영향을 주는 것 아닌가? 아이스크림 종류가 가게 안에서 걸리는 시간을 결정하니까 그렇다
- 흥미로운 설명이지만,