설계 ②: 애매함을 어떻게 다룰까
정할 수 없는 것을 정해야 할 때
좁은 언어를 만들어도 입구에 들어오는 말은 여전히 애매하다.
“플라스틱 손잡이”
플라스틱은 수백 가지다. 열전도율이 종류마다 다르고, 그 차이가 결과를 바꾼다. 그런데 사용자는 “플라스틱”이라고만 했다.
시스템이 취할 수 있는 태도가 몇 가지 있다. 하나씩 따져보면 각각의 대가가 보인다.
태도 1 — 거부한다
“플라스틱의 종류를 명확히 지정해 주세요.”
정직하다. 그리고 실패한다.
사용자는 대개 답을 모른다. 프라이팬 손잡이가 페놀수지인지 나일론인지 아는 사람은 드물다. 알아야 할 이유도 없었다.
그리고 이 태도는 우리가 없애려던 것을 되살린다. 정확한 입력을 요구하는 도구는 전문가만 쓸 수 있다. 그게 기존 도구의 문제였다.
태도 2 — 조용히 정한다
목록에서 대표적인 플라스틱을 골라 계산하고, 결과만 보여준다.
편하다. 그리고 위험하다.
사용자는 시스템이 어떤 값을 썼는지 모른다. 결과가 나왔으니 맞다고 믿는다. 만약 실제 재료가 그것과 크게 다르면, 사용자는 틀린 답을 근거로 설계 결정을 내린다.
그리고 이건 조용히 일어난다. 에러도 경고도 없다. 그럴듯한 숫자가 나온다.
수치해석에서 이게 가장 나쁜 실패다. 1편에서 말한 “그럴듯하게 틀린 답”이 바로 이것이다.
태도 3 — 정하고 드러낸다
값을 정해서 계산은 진행하되, 무엇을 정했는지 화면에 보여준다. 그리고 바꿀 수 있게 한다.
우리가 택한 방식이다. DSL 문서가 사용자에게 보인다는 설계가 이걸 가능하게 한다.
사용자가 “플라스틱 손잡이”라고 쓰면, 화면의 DSL에는 이렇게 나타난다.
재료: 페놀수지 ← 자동 선택 (플라스틱)
열전도율: 0.25 W/m·K
계산은 바로 돌아간다. 기다림이 없다. 대신 그 값이 눈에 보인다. 사용자가 “아 이거 나일론인데” 하고 알아채면 그 자리에서 바꿀 수 있다.
핵심은 결정을 숨기지 않는 것이지, 결정을 사용자에게 미루는 것이 아니다.
태도 4 — 여러 답을 보여준다
한 걸음 더 나간 방식도 있다. 값을 하나로 정하지 않고 범위로 계산해서 결과의 폭을 보여주는 것.
“플라스틱 종류에 따라 손잡이 온도는 44~52도 사이”
이 방식의 장점은 정직함이다. 모르는 것을 모른다고 표현한다. 그리고 사용자의 실제 질문 — “손잡이가 위험한가” — 에 더 직접 답한다. 범위 전체가 안전하다면 종류를 몰라도 결론은 같다.
우리는 이걸 애매함이 결과를 크게 바꿀 때만 쓰기로 했다. 판단 기준은 이렇다. 후보 값들로 계산한 결과가 서로 비슷하면 하나만 보여준다. 결과가 크게 갈리면 범위를 보여주고, “이 값을 확인해야 합니다”라고 표시한다.
이러면 사용자가 신경 쓸 곳이 좁혀진다. 스무 개의 자동 결정 중 결과를 좌우하는 것만 눈에 띄게 된다.
애매함의 세 종류
실제 입력을 보다 보니 애매함이 한 종류가 아니었다. 처리 방식도 달라야 했다.
값의 애매함
“플라스틱”, “두꺼운 판”, “뜨겁게”.
후보 범위가 존재한다. 플라스틱의 열전도율은 어떤 값이든 될 수 있는 게 아니라 좁은 대역 안에 있다. 그래서 대표값 + 범위 검사로 다룰 수 있다.
구조의 애매함
“손잡이가 달린 팬” — 손잡이가 몸통에 어떻게 붙었는가. 면 전체로 접합인가, 리벳 두 개인가.
이건 값이 아니라 모델의 형태가 갈리는 문제다. 대표값으로 처리할 수 없다. 우리는 가장 단순한 형태(면 접합)를 기본으로 두고, 접합 면적을 조절 가능한 값으로 노출했다.
의도의 애매함
“이거 안 뜨거워지게 하려면?” — 6편에서 본 목적형 입력이다.
무엇을 계산할지가 정해지지 않는다. 이건 값을 채워서 해결되는 문제가 아니다.
우리 방식은 가장 좁은 해석을 골라 실행하고, 다른 해석을 제안으로 남기는 것이다. “손잡이가 뜨거워지는가”를 먼저 계산해 보여주고, 그 아래에 두께를 바꿔 볼까요 / 재료를 바꿔 볼까요 같은 다음 시도를 버튼으로 둔다.
이러면 사용자가 무엇을 물어야 할지 몰랐어도 결과를 보고 다음 질문을 발견하게 된다. 이게 우리가 원했던 “열 번 시도”의 실제 모습이다.
정리하면
애매함을 다루는 원칙이 세 줄로 정리됐다.
- 막지 않는다. 애매해도 계산은 진행한다. 되묻기는 마찰이다.
- 숨기지 않는다. 시스템이 정한 값은 전부 화면에 보인다.
- 중요한 것만 강조한다. 결과를 크게 바꾸는 값에만 표시를 붙인다.
세 줄 모두 DSL이 사람에게 보인다는 전제에 기대고 있다. 중간 형식을 만든 진짜 이유가 여기서 드러난다. 계산기에 넘길 데이터 구조가 필요했던 게 아니라, 시스템의 판단을 사람이 감사할 수 있는 창구가 필요했던 것이다.
그런데 이 원칙들로도 못 막는 실패가 하나 있다. 애매함이 아니라 오해에서 오는 실패다.
사용자가 “3”이라고 썼고 시스템은 그걸 3밀리미터로 읽었는데 사용자는 3센티미터를 뜻했다면 — 이건 애매한 게 아니다. 양쪽 다 명확한데 서로 다른 것이다. 그리고 결과는 열 배 틀린다.
단위 문제가 왜 특별히 위험한지, 다음 편에서 다룬다.
다음 편 예고 — 설계 ③: 단위와 좌표계라는 함정. 조용히 틀리는 실패 중 가장 흔한 것, 그리고 그것을 막기 위한 설계.