사람은 물리를 어떻게 말하는가
2부를 시작하며
1부에서 우리는 세 번 실패했다. 단계별 입력은 궁금증의 수명을 넘겼고, 문장을 그대로 받으니 예상과 다른 것들이 들어왔고, 정돈된 문장에도 상식이 잔뜩 생략되어 있었다.
그래서 2부의 주제는 언어다. 사람의 말과 계산기 사이에 무엇을 놓을 것인가.
그런데 무엇을 놓을지 정하려면, 먼저 사람이 실제로 어떻게 말하는지 알아야 한다. 이 편은 그 관찰이다.
네 가지 유형
들어온 입력들을 성격에 따라 나눠 보면 대략 네 종류로 갈린다.
유형 1 — 완결형
“10cm × 5cm 알루미늄 판, 왼쪽 끝 100도 고정, 나머지 면은 25도 공기와 접촉. 정상 상태 온도 분포.”
문제로서 거의 완결되어 있다. 형상, 치수, 재료, 경계조건, 원하는 결과가 다 있다.
이 유형은 다루기 쉽다. 그런데 드물다. 그리고 이렇게 쓸 수 있는 사람은 대개 기존 도구도 다룰 수 있는 사람이다. 우리가 도우려는 대상이 아니다.
유형 2 — 목적형
“이거 손잡이가 안 뜨거워지게 하려면?”
여기엔 문제 서술이 아니라 목표가 들어 있다. 조건도 없고 형상도 없다. 사용자가 원하는 것은 온도 분포 그림이 아니라 판단이다.
흥미로운 것은 이게 가장 자연스러운 형태라는 점이다. 사람은 계산을 하고 싶어서 계산하지 않는다. 결정을 하려고 계산한다.
유형 3 — 변형형
“알루미늄 대신 스틸이면?” “두께 두 배로.”
이전 상태를 전제한다. “대신”과 “두 배”는 기준이 있어야 성립하는 말이다.
그리고 이 유형이 가장 많았다. 당연하다. 앞에서 우리가 원한 것이 열 번 시도하는 것이었으니, 시도의 대부분은 직전 조건의 변형이다.
유형 4 — 관찰형
“손잡이 끝부분만 보여줘.” “시간에 따라 어떻게 변하는지.”
문제를 바꾸는 것이 아니라 결과를 다르게 보고 싶다는 요청이다. 계산을 다시 할 필요가 없을 수도 있다.
유형이 알려주는 것
이 분류에서 두 가지가 드러난다.
첫째, 대화형 구조가 필수다. 유형 3과 4가 전체의 다수인데, 둘 다 이전 상태가 있어야 성립한다. 매번 처음부터 문제를 받는 구조로는 대응할 수 없다. 현재 상태를 어딘가에 붙들고 있어야 한다.
둘째, 입력의 대부분은 “차이”다. 사람이 전체를 다시 서술하는 경우는 처음 한 번뿐이고, 그 뒤로는 무엇이 달라졌는지만 말한다.
이건 설계에 직접 영향을 준다. 사용자의 말을 매번 완전한 문제 정의로 번역하려 하면 안 된다. 현재 상태 + 변경사항으로 다루는 편이 실제 사용에 맞다.
사람 말의 세 가지 특성
유형과 별개로, 표현 자체에도 규칙적인 성질이 있었다.
특성 1 — 상식으로 채운다
앞에서 본 대로다. 프라이팬이라고 하면 대략의 크기가 있고, 실내라면 공기는 실온이고, “몇 도까지 오르나”는 최종 도달 온도를 뜻한다.
이런 것들은 적히지 않는다. 적을 필요가 없기 때문에 적지 않는다. 사람끼리는 통하니까.
여기서 중요한 통찰이 나온다. 이 생략은 게으름이 아니라 효율이다. 그리고 생략된 값들은 대체로 좁은 범위 안에 있다. 실내 온도는 20~25도이고, 프라이팬 지름은 20~30cm다. 아무 값이나 가능한 게 아니다.
즉 채울 수 있다. 정확하지는 않아도 합리적으로.
특성 2 — 물리를 목적으로 말한다
사람은 “열전달 방정식을 풀어달라”고 하지 않는다. “안 뜨거워지게 하고 싶다”고 한다.
전자는 방법이고 후자는 목적이다. 그리고 목적에서 방법으로 가는 길은 하나가 아니다. 손잡이가 뜨거워지지 않게 하는 방법은 두께를 늘리는 것, 재료를 바꾸는 것, 접촉면을 줄이는 것 여러 가지다.
목적형 입력은 문제를 하나로 특정하지 않는다. 그래서 시스템이 “무엇을 계산할 것인지” 스스로 정해야 한다. 이건 번역이 아니라 해석이다.
특성 3 — 단위를 흘린다
“10에 5 알루미늄” “두께 3”
숫자만 있고 단위가 없다. 사람은 맥락에서 안다. 프라이팬 이야기라면 10은 센티미터일 것이고, 반도체 이야기라면 마이크로미터일 것이다.
계산기는 이걸 모른다. 그리고 단위를 잘못 짚으면 결과가 조용히 틀린다. 에러가 나지 않고 그럴듯한 답이 나온다. 이게 가장 위험한 실패다.
그래서 필요한 것
세 특성을 다시 보면 필요한 층이 보인다.
| 사람 말의 특성 | 시스템이 해야 할 일 |
|---|---|
| 상식으로 채운다 | 생략된 값을 합리적으로 보충 |
| 목적으로 말한다 | 목적을 계산 가능한 문제로 특정 |
| 단위를 흘린다 | 맥락에서 단위를 추정하고, 반드시 확인 |
세 줄 모두 공통점이 있다. 시스템이 사용자가 말하지 않은 것을 결정한다.
이게 편리함의 원천이면서 동시에 가장 큰 위험이다. 시스템이 마음대로 정한 값 때문에 결과가 틀렸는데, 사용자는 그 값이 정해진 줄도 모른다면 — 그건 도구가 아니라 함정이다.
그러니 조건이 하나 붙는다. 시스템이 채운 값이 사용자에게 보여야 한다. 그리고 고칠 수 있어야 한다.
여기서 중간 형식이 필요한 진짜 이유가 나온다. 단순히 계산기에 넘길 데이터 구조가 필요한 게 아니다. 사람이 읽고 고칠 수 있는 형태여야 한다.
- 사람의 애매한 말을 받아
- 명확하게 정리하고
- 그 정리를 사람에게 보여주고
- 사람이 고칠 수 있게 하고
- 계산기가 그대로 실행하는
이 다섯 조건을 동시에 만족하는 표현. 그게 우리가 설계해야 하는 것이었다.
다음 편에서는 이 생략의 규모를 구체적으로 들여다본다. 한 문장 안에 몇 개의 결정이 숨어 있는지 세어보면, 이 문제가 왜 만만치 않은지 실감할 수 있다.
다음 편 예고 — “알루미늄 팬” 한마디에 생략된 것들. 문장 하나를 끝까지 분해해서, 계산기가 요구하는 값이 실제로 몇 개인지 확인한다.