48÷2(9+3)

 

1. 개요
2. 각 답에 대한 사람들의 주장
2.1. 답은 2이다
2.2. 답은 288이다
2.3. 수식 자체가 잘못되었다
3. 약간 더 자세한 설명
4. 기타 유사 사례
5. 관련 문서


1. 개요


2011년 초반 인터넷을 달구었던 수학 떡밥. 미국의 한 수학 시험에 출제된 문제로 분명히 수식만 보면 단순해보이나, 실은 이것을 어떻게 해석하느냐에 따라 답이 2와 288로 나뉘게 되어 어느 쪽이 답인가에 대한 논쟁이 일어났다. 결국 미국의 한 인터넷 커뮤니티에서 전파되어 곧 전 세계 커뮤니티와 학계를 뒤흔든 희대의 수학 떡밥이 되었다.
[image]
공학용 계산기 간에도 계산 순서가 다르게 설정되어 있기 때문에 서로 다른 답을 보여준다. #
이를 풀어내기 위해 매스매티카, 파이썬 같은 프로그래밍 언어와 각 회사의 공학 계산기들이 총동원되어 각자 다른 답과 해석을 내놓았으며, 대학교수들의 자문까지 얻으며 2파와 288파로 나뉘어 논쟁이 점점 더 카오스화 되어가고 있다. 한 술 더 떠서 아예 문제 자체에 오류가 있으므로 답이 없다고 주장하는 사람들도 이 논쟁에 가세했다.[1]
더 정확히 말하자면 이것은 '''문제로서 성립하지 못한다.''' 이 문제의 핵심은 위 사진에 나온 규칙 7에도 나온 multiplication by juxtaposition[2](이후 MoJ로 표기.)의 애매모호함이다. 이 MoJ는 계산을 간략히 표기하기 위한 일종의 관습이기도 한데, 이 것을 곱셈 연산 *의 또다른 표기로 보느냐, *와 연산 결과는 같으나 연산의 우선순위는 다른 별도의 연산으로 보느냐에 따라 계산 결과가 달라진다.
아래에 나오는 사람들의 주장도 결국 크게 나누면 'MoJ와 곱셈, 나눗셈은 동등한 우선순위를 지닌다', 혹은 'MoJ는 곱셈, 나눗셈에 우선한다'의 둘 중 한쪽으로 귀결되며, 상세한 관련 예시들을 들어 주장하고 있을 뿐이다.
단순한 문제이지만 수학계에서도 논란이 되었고, 특히 수학교육학에서는 중요한 주제로 다뤄지기도 했다.

2. 각 답에 대한 사람들의 주장



2.1. 답은 2이다


48÷2와 (9+3) 사이에 곱셈 기호가 없기 때문에 2(9+3)을 한 항으로 간주하여 먼저 계산하여야 한다. 그러므로 48÷{2(9+3)}=48÷24=2이다.

2를 지지하는 사람들은 미국 수학협회의 "multiplication indicated by juxtaposition is carried out before division."이라는 규정을 든다. 곱셈 기호가 생략된 병렬항의 경우는 나눗셈에 앞선다는 규정이다. 이 때문에 2(9+3)을 먼저 계산하고 나눗셈을 해야 한다라고 주장한다.
단, 위의 출처라고 할 수 있는 글은 AMS소스가 삭제돼있고, 구글 등 검색엔진에도 AMS소스는 없다. 웹아카이브를 통해 검색한 결과 2001년 까지는 위의 내용이 있었으나 변경된 것으로 확인되었다. 그리고 한 항은 더하기 단위인데 42와 (9+3)사이에는 나눗셈 기호가 있다.
Allendoerfer, Oakley 의 Principles of Mathematics에도 답이 2라는 주장을 뒷받침해준다고 주장한다. 여기서는 "병치로 표시된 곱셈은 나눗셈 이전에 수행한다. 그러므로, 일반적으로, 임의의 a, b, c에 대하여 a/bc=a/(bc)가 될 것이다. (단, b와 c는 0이 아니다)" 라고 설명한다.[3]
또한 이들은 "288이 답이 되려면 1÷2x = 0.5x 도 맞아야 한다."라는 반례를 들기도 한다. 저렇게 적은 경우 x를 분모의 위치로 취급하기 때문에 (9+3)역시 마찬가지라는 주장이다.[4]
일부 공학용 계산기(샤프제 공학계산기, 카시오 계산기 중 일부[5])에 저 수식 그대로 집어넣으면 답이 2라고 나온다. 2를 출력하는 계산기의 경우 48÷2×(9+3)으로 입력하면 역시 288을 출력한다. 즉 이는 생략된 곱셈기호를 계산하는 다른 연산원칙을 따로 지정해주었음을 의미. 앞에서 한 주장과 일치된다.
Maple 14 에서는 48/2(9+3) 을 입력하게 되면

48/(2*(9+3));

print(`output redirected...`); # input placeholder

2

이렇게 자동으로 2와 (9+3)를 ()로 묶어서 계산하게 된다. 이것은 위에서 언급한 MoJ를 나눗셈보다 우선하여 연산을 수행한 것이다.
4월 11일에는 2를 뒷받침하는 수학 교과서 내용과 강사의 설명 동영상을 모은 이 올라왔고, 4월 13일에는 뉴욕 시립대 대수학 교재를 인용한 이 올라왔다.
한국 교육과정은 위 주장을 지지한다.

2.2. 답은 288이다


48÷2와 (9+3) 사이에는 곱셈 기호가 생략되어 있을 뿐이다. 사칙연산에서 곱셈과 나눗셈은 왼쪽부터 계산한다. 그러므로 48÷2×(9+3)=288이다.

288을 지지하는 사람들은 '답은 2이다.'라는 계산법은 곱셈이 생략되었다는 이유로 기존의 연산식에 없는 괄호를 추가하고, 곱셈과 나눗셈을 오른쪽부터 계산하는 오류를 범하므로 틀렸다고 주장한다. 9+3을 계산하고나면 괄호가 없어지고 12이라는 숫자가 남는다는 게 이유.
사실 곱셈 기호가 생략되었다는 것은 잘못된 주장이다. 곱셈 연산자 ×(*)나 MoJ와 달리 위의 식에서는 피연산자간의 교환을 허용하지 않는다. 즉, 2×(9+3)=(9+3)×2 이지만 (9+3)2는 2(9+3)과 달리 관습적으로도 쓰지 않으므로 식이 아니다. 따라서 답 288을 지지한다면 곱셈 연산자의 생략이 아닌, 의미는 같지만 피연산자간의 교환을 허용하지 않는 구문을 가진 새로운 연산자로 보는 것이 옳다.
덧붙여 위의 수식을 구글 또는 울프람알파와 같은 수식을 계산해 줄 수 있는 엔진[6]에 붙여넣을 경우 288이 나온다. 일부 공학용 계산기(TI-83, TI-84, TI-86, TI-89, TI-Nspire, 카시오제 공학계산기 일부[7], HP 35s)와 스마트폰도 이 답을 출력한다. #. 미국 대학 칼큘러스 시간에 일반적으로 가장 많이 쓰이는 그래핑 계산기인 TI-84 역시 288이라는 답을 내놓았다.
Wolfram Alpha288이라는 답을 내놓았다.
네이버,다음의 계산기도 이 답을 내놓았다.
2를 지지하는 사람들이 언급하는 "1/2x = 0.5x?" 에 대해서는, 문자일때는 2를 계수로 가진 x가 분모로 취급되지만 이번 케이스와 같은 상수에서는 계산 우선권이 없다고 주장한다. 단 이렇게 주장할 경우, 상수를 문자로 치환하거나 그 반대의 경우 계산식의 답이 달라진다는 결과를 낳는 치명적인 문제가 있다. 수와 수가 아닌 수와 괄호사이엔 곱셈의 생략이 가능하다는 정의가 있다. 괄호는 물론 우리는 다른 수학적 기호들 사이에서도 곱셈의 생략을 쓰고있다.(√, log, 삼각함수, 등등)
밑에 인용되어 있듯이 스탠다드 방식으로는 그대로 왼쪽에서 오른쪽으로 계산하여 288이 답인 것이 맞는다고도 주장한다.

2.3. 수식 자체가 잘못되었다


이 식은 우선 수식 내부에서 /과 ÷는 대개 같이 사용하지 않으며, 곱셈기호를 생략하기 위해서는 대부분 ÷가 아닌 /를 사용한다는 사실을 간과했다. 다시 말해 곱셈기호를 생략할 때 사용하는 2차원 식인 분수를 /를 사용하여 1차원 식으로 표현한 것을 /을 ÷로 바꾸는 바람에 생기는 오류라고 할 수 있다.
실제로 MS Office 엑셀[8] 또는 MATLAB을 이용하여 위의 수식을 계산해보면 오류를 출력하는 것을 볼 수 있다. 즉, 표기의 오류 때문에 위의 식에서 48÷2(9+3)을 한 항으로 해석해야 하는가, 아니면 독립된 항으로 해석해야 하는가를 두고 논란이 일어난 것이다.
'수와 수 사이의 곱셈을 생략하지 않는다.'는 규정은 2×3에서곱셈을 생략할 경우 23이 되므로 자연수 23과 2와 3의 곱이 구분되지 않기 때문이다. 수와 괄호 사이엔 곱셈 생략이 허용된다. '상수만일 경우엔 생략을 하면 안 된다.'는 규칙이 있는 것이 아니라, 일반적으로 할 필요가 없기에 하지 않는다는 것이 맞는 표현이다. 정확히 말하면 굳이 간단히 표기하고 싶으면 3·4 식으로 점을 찍어 표현한다. 따라서 저 정의대로 한다 하더라도 2·(9+3)으로 썼어야 했다는 얘기. 그 밖에도(2)(12)등 여러 표기가 있으나 곱셈기호 생략의 목적이 편의를 위해서인데 더 귀찮아지므로 거의 안 쓴다. 굳이 예를 들면 (1/2)×(1/4)×(1/8)을 (1/2)(1/4)(1/8)로 표기한다든지. 48÷2(9+3)의 경우에는 2에 괄호가 없어서 점점 더 미궁속으로...(대수학에서 문자로 나타낸 식에 대입하는 과정에선 괄호를 한쪽만 쳐도 되지만 이 경우는 아니다.
다른 수식을 예로 들자면, 1/2/4같은 경우가 있다. 1÷2÷4라면 0.125가 답이겠지만, 1/2/4라면 그것이 0.5/4인지 1/0.5인지가 애매하기 때문이란 것. 여기서도 위에서 언급한 MoJ와 ×의 관계처럼, /가 ÷를 표기만 다르게 한 것인지, ÷보다 우선순위가 다른 새로운 연산인지 정해지지 않았다. 이러한 표기에서 비롯되는 해석의 모호성은 수식에서뿐만 아니라 언어에서도 나타난다. 이는 아버지가방에 들어가신다와 같은 맥락.
그러므로 '''애초에 문제에 오류가 있으니 답을 논하는 것 자체가 오류'''라는 것이 핵심이다.
아래의 링크에 비슷한 사례가 있다.
http://jeff560.tripod.com/operation.html

Modern textbooks seem to agree that all multiplications and divisions should be performed in order from left to right. However, in Florida Algebra I published by Prentice Hall (2011), a problem asks the student to evaluate 3st2 ÷ st + 6 for given values of the variables, and the answer provided comes from dividing by st. A representative for the publisher has acknowledged that the expression is ambiguous and promises to use (st) in the next revision.

현대수학은 왼쪽에서 오른쪽으로 계산하는걸 원칙으로한다. 그러나 일부 책에서는 다르게 계산하는 방법으로 풀었는데 다음 개정판에서는 혼동을 방지하기 위해서 괄호를 넣을 것이다.

네이버 캐스트에서 2009년에 사칙연산에 대한 글을 다룬 적이 있는데, 2년이 지나서 이 문제가 떡밥이 되자 그 글에 내용을 추가해서 수식의 잘못을 탓하여 이 논쟁에 젓가락을 얹었다. #

3. 약간 더 자세한 설명


이 문제의 핵심은 연산자 우선 순위에 관련된 형식 문법(Formal grammar)을 어떻게 정의하느냐에 있다. 수학 수식 역시 형식 언어의 일부로 간주될 수 있는데, 이 때 이 수식을 의미론적으로 어떤 의미를 가지는 형태로 변환해야 하느냐에 대한 논쟁인 것이다.
유사한 문제로는 프로그래밍 언어의 수식을 어떻게 해석하느냐의 문제가 있는데, 이 동네에서는 형식 언어론에 의해 언어 자체적으로 엄밀하게 정의한 문법에 기반하여 해석한 뒤, 이를 모호함이 없는 형태의 수식[9]으로 변환하여 처리하므로 이런 문제는 발생하지 않는다. (위에서 언급된 수학 프로그램/계산기는 자체적으로 정의한 문법을 토대로 수식 해석기를 만들어 쓰는데, 이 문법이 서로 다른 것 뿐이다.)
이는 기준이 될 수 있는 문법이 없기 때문에 발생하는 단순 표기법의 문제이며, 실제 문제의 본질과는 아무런 관련이 없다. 즉, 학계에 통용되는 표준 문법이 있다면 이런 문제 자체가 있을 이유가 없지만, 안타깝게도 수학계 전반에서 통용되는 표준 문법이란 현 시점에는 존재하지 않고, 앞으로도 존재하기 힘들 것이다. 대부분의 수학적인 표현법 자체가 파급력 있는 논문에서 임의로 정의된 이후 사람들이 그 논문을 참조하면서 퍼져 나가는 것이기 때문. 논문을 낼 때마다 표기법에 대해 학계 전반의 동의를 구해야 한다면 논문 쓰기 참 힘들 것이다.
참고로, 실제 전공 서적들에서는 애초에 이렇게 모호하게 표기하지 않으며, 하더라도 서장이나 관련 챕터에서 이후에 사용할 표기법에 대한 언급을 해두고 넘어가므로 이런 문제는 발생하지 않는다.
여담으로, 역폴란드 표기법으로는 전자는 48 ↵ 2 ÷ 9 ↵ 3 + ×, 후자는 48 ↵ 2 ↵ 9 ↵ 3 + × ÷ 이다.

4. 기타 유사 사례


과거에는 워크래프트 3의 홈페이지 게시판에서는 111+1×2=224는 맞을까? 라는 문제로 113이 맞다, 224가 맞다로 논쟁을 벌인 적이 있다. 이것의 유래는 111+1×2=224에서 확인할 수 있다. 물론 이건 사칙연산의 규칙만 알면 풀 수 있다. 시사하는 바도 다르고.
참고로 옆나라 일본대만의 인터넷에서도 이와 같은 문제로 시끄러웠던 모양이다. 이쪽은 6÷2(1+2)=9 vs 1. #한국에선 12년 6월 21일에 다시 검색어로 떴다.# 참고로 이 문제는 2015년에도 재조명을 받은 적이 있었다. 2018년도 페이스북에서 다시 떠들썩한 문제다.
물론 이 항목의 수식도 11년 4월경에 그대로 마법의 문장을 쓴채로 아주 많은 기사가 양산되었다.
그리고 2013년 2월 17일 해외에서 7+7÷7+7×7-7=50 or 56이라는 비슷한 것이 나왔지만, 이는 헷갈리기 쉬울 뿐 '곱셈과 나눗셈을 덧셈과 뺄셈보다 우선시한다'는 사칙연산 규칙을 명확히 적용할 수 있기에 논란은 그리 크지 않다.[10]
SBS 《작렬 정신통일》에서 가수 채연두뇌를 풀가동해서 2+2×2를 8로 골랐다가 굴욕을 맛본 적이 있다. 정답은 다 알겠지만 6.
살짝 변형되어 '4÷2(2+2) = ?' 라는 문제로 바뀌어 새로 등장하였다. 숫자만 다를 뿐 본질은 같다.

5. 관련 문서



[1] 이 떡밥으로 조용한 갤러리 축에 들어갔던 디시인사이드 수학갤러리는 하루에 100페이지가 넘는 글들이 난립하게 되었다.[2] a×b를 ab로 표기하는 것[3] multiplication indicated by juxtap-osition is carried out before division. Thus, in general, for any variables a, b and c, we would have a/bc = a/(bc) (assuming, of course, that b and c are nonzero.)[4] 위 출처글의 경우, 6÷2×3의 경우와 a÷bc(단, a=6,b=2,c=3)의 경우 왜 답을 다르게 인식하느냐 하는 예시를 문제로 제시한다. 전자의 경우 순서대로 계산하여 답이 9라고 대답하지만, 후자의 경우 bc가 같이 분모가 되는 것으로 보아 1이라고 대답한다는 것.[5] 특히나 fx-9860G III의 경우 48÷2(9+3)을 입력할 경우 자동으로 괄호가 삽입되어 48÷(2(9+3))이 입력된다. fx-570ES Plus도 2가 나온다.[6] 다만 Mathway 라는 엔진은 예외. 이 엔진은 2(9+3)을 전부 분모로 인식하고 2를 출력한다. 위에서 언급한 것과 같이 이 엔진에도 2*(9+3)으로 입력하면 288을 출력.[7] 카시오에서 제공하는 앱인 ClassPad에서 288을 내놓는다.[8] 사용자가 입력한 수식에 문제가 있습니다. 다음과 같은 수식으로 변경하시겠습니까? =48/2*(9+3) 라고 묻는 창이 뜬다.[9] AST(Abstract syntax tree : 추상 구문 트리)라고 한다.[10] 7÷7과 7×7을 먼저처리하면 7+1+49-7이 된다. 즉, 답은 50이다.