식당 비유: 당신이 알고 싶었던 것보다 훨씬 더 많은 것

식당 비유: 당신이 알고 싶었던 것보다 훨씬 더 많은 것

1년 전에 저는 유튜브에서 이 노래를 찾았습니다.

여기에 포함된 무수한 식당 비유는 기억 속에 각인되었고, 저는 새로 배운 온갖 분야에 식당 비유를 적용하는 데 집착하게 되었습니다. "컴파일러를 식당으로 비유하면..." "RESTful API를 식당으로 비유하면..." 그리고 거의 1년이 지나서야 이 집착이 실제로 학습에 미치는 영향에 대해 생각해보게 되었습니다.

1.도움이 되는 부분-유추 효과

식당 비유는 분명 어느 선까지는 유용합니다. 가장 큰 장점은 유추를 통한 학습입니다. 즉, 새 개념을 이해하는 데 필요한 구조를 새로 만들지 않고 이미 있는 구조를 빌린다는 것입니다.

컴파일러를 통해 예시를 들어봅시다. 위키백과는 컴파일러를 다음과 같이 설명합니다.

컴파일러는 하나의 프로그래밍 언어(소스 언어)로 작성된 컴퓨터 코드를 다른 언어(타겟 언어)로 번역하는 소프트웨어이다.

식당 비유를 적용하면 이는 다음과 같이 말할 수 있습니다.

식당으로 비유하면, 컴파일러는 손님의 주문을 주문서의 형식에 맞춰 작성하는 웨이터와 같다.

이때 중요한 점은, 당신이 컴파일러를 이해했기 때문이 아니라 식당을 너무 잘 알고 있기 때문에 이해가 일어난다는 것입니다.

단기적으로는 유용할 수 있습니다. 그러나 이것이 어디에서 잘못될 수 있을까요?

2.이해했다는 착각

비유는 추상적 구조를 설명하지만, 수학적·기계적 세부를 지워버립니다. 그러고서 뇌는 종종 이렇게 말합니다.

더 엄밀한 용어로는, 이런 현상을 “설명 깊이의 환상(illusion of explanatory depth)”이라고 합니다. 이에 대해서는 링크에서 자세히 설명하고 있으므로 따로 설명하지는 않겠습니다. 핵심은 얕은 이해를 가질 때, 이를 더 자세히 설명하라는 압력을 받기 전까지 자신이 실제보다 더 잘 알고 있다고 착각한다는 것입니다. 따라서 식당 비유는 얕은 이해를 빠르게 만들고 고착시킬 위험이 있습니다.

또한 식당 비유로 만들어진 이해는 잘못 확장될 수 있습니다. 위의 컴파일러-웨이터 비유를 문자 그대로 받아들여 다음과 같은 질문을 한다고 가정해 봅시다.

"왜 그냥 내가 주문서를 쓸 수 없지?"
"재고가 없으면 웨이터가 주문을 거부할 수 있을까?"

식당 비유 상에서는 타당한 질문일 수 있지만, 원래 설명하고자 했던 컴파일러의 개념에는 전혀 맞지 않는 질문입니다. 첫 번째 질문의 경우, 식당 비유를 확장해 소스 언어-타겟 언어의 변환을 주문-주문서 작성에 비유하고 있습니다. 식당 비유에서는 주문보다 주문서가 더 단순해 보이기 때문에, 애초에 주문서를 전담하는 웨이터가 왜 존재하는지 의문을 가질 수 있습니다. 그러나 원 관념인 컴파일러의 경우, 대개 소스 언어보다 타겟 언어가 훨씬 복잡합니다. 타겟 언어를 직접 작성하는 것이 비효율적이기 때문에 프로그래머는 소스 언어만을 작성하고, 타겟 언어를 생성하는 책임은 컴파일러에 맡기는 것입니다.

소스 언어(C언어)와 타겟 언어(어셈블리)의 예시

두 번째 질문의 경우도 근본적으로 같은 오류입니다. 식당이라면 웨이터가 주방의 상황을 판단하고, 재고가 없는 메뉴를 주문했다면 주문을 거부하는 것이 타당합니다. 그러나 컴파일러의 경우 컴파일러의 책임은 컴파일뿐이고, 그 이후의 결과물에 대해서는 일절 책임지지 않습니다. 사실 이 맥락에서 '재고가 없다'는 것이 무엇에 대응하는지도 명확하지 않습니다.

3.좋은 비유의 조건

그렇다면 비유를 쓰지 말아야 할까요?

그렇지는 않습니다. 비유는 여전히 처음 개념에 진입할 때 매우 강력한 도구입니다. 문제는 비유 그 자체가 아니라, 비유를 다루는 방식입니다.

좋은 비유는 최소한 다음 세 가지 조건을 만족해야 합니다.

조건 1. 대응 관계가 명시적으로 제시되어야 한다

좋은 비유는 “비슷하다”는 느낌에 기대지 않고, 무엇이 무엇에 대응되는지를 명확히 드러냅니다.

  • 무엇 ↔ 무엇
  • 어떤 역할 ↔ 어떤 역할
  • 어떤 제약 ↔ 어떤 제약

이 대응 관계가 독자의 머릿속에서 암묵적으로 형성되도록 방치되면, 비유는 곧바로 오해의 출발점이 됩니다.

조건 2. 비유가 깨지는 지점을 함께 제시해야 한다

모든 비유는 반드시 어긋나는 지점이 있습니다.
좋은 비유는 이를 숨기지 않고 미리 공개합니다.

  • “여기까지는 맞지만, 여기부터는 틀립니다.”
  • “이 질문은 비유 상에서는 자연스럽지만, 실제 개념에는 적용되지 않습니다.”

이 경계를 함께 제시하지 않으면, 독자는 비유를 원 개념보다 더 신뢰할 가능성이 큽니다.

조건 3. 비유는 임시적인 발판이어야 한다

비유는 목표가 아니라 발판입니다.
장기적으로는 정의, 제약 조건, 형식적 구조로 구성된 더 엄밀한 이해로 교체되어야 합니다.

...식당으로 비유하자면, 국물을 내기 위해 멸치를 사용했을 뿐이지, 멸치를 씹어 삼키는 것이 목적은 아니라는 것입니다.

4.참고 자료

비유가 학습에 미치는 영향에 대한 더 진지한 연구를 읽고 싶다면 다음을 참고하세요: https://www.academia.edu/101260724/The_Analysis_of_Mapping_Errors_Induced_in_Learning_the_Concept_of_Reaction_Rate_with_Analogies_and_the_Comparison_of_Mapping_Errors_by_Analogy_Presentation_Types

Read more

좋은 정렬, 나쁜 정렬, 이상한 정렬

좋은 정렬, 나쁜 정렬, 이상한 정렬

서론 세상은 정말로 또 다른 '정렬 알고리즘 설명' 블로그 글을 필요로 할까요? 한편으로는 확실히 그렇습니다. 왜냐하면 정렬 알고리즘은 이미 너무 많이 설명되었기 때문에, 오히려 제대로 설명된 적이 거의 없기 때문입니다. 버블 정렬은 “느리고”, 퀵 정렬은 “빠르며”, 병합 정렬은 “안정적”이라는 문장은 수천 번 반복되었지만, 그 문장을 처음 들었을

By 10% matter
스스로 만든 미로에 갇혀

스스로 만든 미로에 갇혀

1년 전쯤에, 저는 파이썬과 pygame을 이용하여 게임을 만들려고 했습니다. 원래의 목적은 목장이야기 코로보쿠르 스테이션에 evil farming game의 요소를 혼합한 자유도 높은 농사 시뮬레이터 게임을 만드는 것이었습니다. 그러나 실제 개발은 게임에 필요한 기본 요소(플레이어 이동, 농작물 시스템 등)를 만드는 데에서 중단되었습니다. 당시에는 어떤 코드가 좋은 코드인지, 어떻게 프로젝트를 잘

By 10% matter
블로그 디자인 하는 법

블로그 디자인 하는 법

블로그를 시작했으니 이제 현실의 문제를 처리해야 합니다. Ghost 기본 디자인은 적절하다고 생각하지만, 이것으로는 성에 차지 않습니다. 무엇보다도 아직 디자인을 손대지 않은 신생 블로그들과 완전히 똑같아 보일 테니까요. 그러면 좋은 디자인을 어떻게 구현할 수 있을까요? 그보다, 좋은 디자인이란 과연 무엇일까요? 제 대답은... 아무것도 모른다는 겁니다. 하지만 정답을 모른다고 아무것도 안 할

By 10% matter
나는 왜 쓰는가?

나는 왜 쓰는가?

I. 블로그란 무엇일까요? 꽤 오랜 시간 동안 그 답은 명백하다고 생각했습니다 - 검색 결과에 가끔 섞여 들어오는 무작위적인 정보 조각입니다. 가끔 유용할 때도 있지만 대부분은 형편없고, 거의 모두가 정보의 품질이 아닌 광고 수익을 바라보고 글을 올립니다. 여기서 네이버 블로그를 예시로 든 것이 불공평하다고 생각할 수도 있습니다. 실제로 다른 블로그 플랫폼들은

By 10% matter