처음 만든 것, 그리고 왜 실패했나
가장 자연스러운 첫 시도
방향이 정해지고 나서 처음 만든 것은 화면을 옮긴 앱이었다.
기존 해석 프로그램이 무엇을 입력받는지는 이미 알고 있었다. 형상, 재료, 경계조건, 계산 설정. 그러니 그것들을 휴대폰 화면에 맞게 다시 배치하면 된다고 생각했다.
실제로 그렇게 만들었다. 항목을 단계로 쪼개고, 한 화면에 하나씩만 물었다.
1단계에서 형상을 고른다. 사각형, 원, L자 중에서. 2단계에서 치수를 넣는다. 가로 몇 밀리미터, 세로 몇 밀리미터. 3단계에서 재료를 고른다. 목록에서 알루미늄, 강철, 구리. 4단계에서 각 변의 조건을 정한다. 이 변은 200도 고정, 저 변은 공기와 접촉. 5단계에서 계산 설정을 확인한다. 격자 크기, 시간 간격, 총 계산 시간. 그리고 실행.
기술적으로는 잘 돌아갔다. 계산도 맞았고 결과도 나왔다. 앱이 죽지도 않았다.
그런데 아무도 쓰지 않았다. 만든 우리조차.
왜 안 쓰게 되는가
이유를 찾는 데 시간이 좀 걸렸다. 버그가 있는 것도 아니고 느린 것도 아니었으니까.
문제는 5단계를 통과하는 데 드는 마음의 비용이었다.
궁금증이 하나 떠올랐다고 하자. “이 부분을 좀 더 두껍게 하면 온도가 얼마나 내려갈까?” 이 질문에 답을 얻으려면 앱을 열고 다섯 단계를 통과해야 한다. 시간으로는 2~3분이다.
2~3분은 짧다. 그런데 궁금증의 수명보다 길었다.
가벼운 호기심은 30초 정도 살아 있다. 그 사이에 답이 안 나오면 사람은 다른 일로 넘어간다. 5단계를 통과하는 동안, 애초에 무엇이 궁금했는지에 대한 절박함이 식는다.
더 결정적인 것은 반복할 때였다. 두께를 바꿔 다시 보고 싶으면 처음부터 다시 다섯 단계를 지나야 했다. 열 번 시도하려면 다섯 단계를 열 번 통과해야 한다. 그러면 아무도 열 번 시도하지 않는다.
우리가 없애려던 것이 정확히 그것이었는데, 형태만 바꿔서 되돌아왔다.
첫 번째 교훈: 단계를 줄이는 게 아니라 없애야 했다
여기서 처음에는 이렇게 생각했다. 5단계가 많으니 3단계로 줄이자.
그런데 줄여봐도 마찬가지였다. 3단계도 여전히 3단계다. 문제는 개수가 아니라 방식이었다.
사람이 물리 문제를 떠올릴 때, 머릿속에서 그것은 단계로 나뉘어 있지 않다. 하나의 덩어리로 온다.
“알루미늄 팬인데 손잡이는 플라스틱이고, 바닥에서 200도로 가열될 때 손잡이 끝이 몇 도까지 오르는지”
이 한 문장 안에 재료도, 형상도, 경계조건도, 알고 싶은 것도 다 들어 있다. 사람은 이미 문제를 완결된 형태로 갖고 있다. 그런데 우리 앱은 그걸 다섯 조각으로 분해해서 다시 입력하라고 요구했다.
즉 사용자는 자기가 이미 알고 있는 것을 앱의 언어로 번역하는 노동을 하고 있었다. 그 노동이 진입 장벽이었다.
두 번째 시도: 문장을 받아보자
그래서 입력창을 하나만 뒀다. 텍스트 상자 하나. 문장을 그대로 받는 방식이다.
이번엔 반응이 달랐다. 쓰기 시작했다. 그런데 곧 다른 문제가 드러났다.
들어온 문장들이 우리가 예상한 것과 전혀 달랐다.
우리가 상상했던 입력은 앞의 프라이팬 문장처럼 정돈된 것이었다. 실제로 들어온 것은 이런 식이었다.
- “이거 너무 뜨거워지지 않게 하려면 어떻게 해야 함?”
- “알루미늄 대신 스틸 쓰면?”
- “손잡이 부분만 좀 보고 싶은데”
첫 번째는 형상도 치수도 없다. 두 번째는 직전 대화에 이어지는 말이다. “대신”이라는 단어가 이전 상태를 전제한다. 세 번째는 문제 정의가 아니라 결과 표시에 대한 요청이다.
사람은 완결된 문제를 한 번에 서술하지 않는다. 대화를 한다. 조금 말하고, 결과를 보고, 조건을 바꾸고, 다시 묻는다.
세 번째 교훈: 진짜 문제는 생략이었다
정돈된 문장이 들어온 경우에도 문제가 있었다. 다시 그 프라이팬 문장을 보자.
“알루미늄 팬인데 손잡이는 플라스틱이고, 바닥에서 200도로 가열될 때 손잡이 끝이 몇 도까지 오르는지”
여기에 없는 것들을 세어보자.
- 팬의 지름은? 두께는?
- 손잡이 길이는?
- “플라스틱”은 어떤 플라스틱인가. 열전도율이 종류마다 다르다.
- 바닥 200도는 순간적으로 도달하는가, 서서히 오르는가.
- 손잡이 표면은 공기와 열을 주고받는가. 그렇다면 주변 공기는 몇 도인가.
- 정상 상태의 답을 원하는가, 시간에 따른 변화를 원하는가.
- 몇 분 후의 온도인가.
하나도 적혀 있지 않다. 그런데 사람은 이 문장을 듣고 무슨 문제인지 이해한다. 왜냐하면 상식으로 채우기 때문이다. 프라이팬 크기는 대충 짐작하고, 주변 공기는 실온이라고 가정하고, “몇 도까지”라는 표현에서 최종 도달 온도를 묻는다고 읽는다.
계산기는 이걸 못 한다. 계산기에게는 모든 값이 있어야 한다. 하나라도 비면 계산이 시작되지 않는다.
그러니 문장을 받는 것만으로는 부족했다. 생략된 것을 채우는 층이 필요했다.
그래서 무엇이 필요했나
세 번의 실패를 정리하면 요구사항이 이렇게 남았다.
| 실패에서 배운 것 | 그래서 필요한 것 |
|---|---|
| 단계 입력은 궁금증의 수명을 넘긴다 | 한 번에 받는 입력 |
| 사람은 대화하듯 조건을 바꾼다 | 이전 상태를 기억하는 구조 |
| 사람의 말에는 상식이 생략된다 | 빈 값을 합리적으로 채우는 층 |
| 계산기는 모든 값을 요구한다 | 완전하고 정확한 중간 형식 |
마지막 줄이 핵심이다. 사람의 말은 애매하고 불완전하며, 계산기는 명확하고 완전한 것만 받는다. 이 둘 사이에는 다른 종류의 표현이 필요하다.
애매한 말을 받아 명확한 형식으로 옮기고, 그 형식을 사람이 다시 확인하고 고칠 수 있어야 한다. 그리고 그 형식은 계산기가 그대로 실행할 수 있어야 한다.
이 중간 표현을 설계하는 것이 2부의 주제다. 흔히 DSL(도메인 특화 언어)이라 부르는 것이다.
그리고 미리 말해두면, 이 설계에서 가장 어려운 결정은 무엇을 표현할 수 있게 만드느냐가 아니었다. 무엇을 표현할 수 없게 만드느냐였다.
다음 편 예고 — 사람은 물리를 어떻게 말하는가. 실제로 들어온 문장들을 유형별로 나눠 보고, 그 안에서 어떤 규칙성이 보이는지 살펴본다.