Numpilot 해부 — Solver Lab / Learn / Models / Projects
5부를 시작하며
지금까지 27편에 걸쳐 설계와 기술을 이야기했다. 5부에서는 그것이 실제 제품에서 어떤 모습인지 본다.
앱은 네 부분으로 되어 있다. Solver Lab, Learn, Models, Projects. 각 부분이 이 연재의 어느 이야기에 대응하는지 짚어가며 정리한다.
Solver Lab — 문제를 풀는 곳
앱의 중심이다. 사용자가 실제로 해석을 돌리는 화면.
화면 구성
위쪽에 텍스트 입력 상자 하나. 5편에서 다섯 단계 입력을 버리고 이걸로 바꾼 그 결정의 결과다.
그 아래에 DSL 카드. 12편의 “제시” 단계다. 시스템이 무엇을 정했는지 ← 사용자 / ← 자동 / ⚠ 로 구분해 보여준다. 접혀 있고, 펼치면 전체가 보인다.
그 아래에 결과. 온도 분포 그림과 관심 지점의 값. 그리고 20편의 신호등.
맨 아래에 다음 시도 버튼들. 10편에서 “의도의 애매함”을 다루며 만든 장치다. 두께를 바꿔볼까요 / 재료를 바꿔볼까요.
설계에서 가장 신경 쓴 것
화면에 보이는 요소의 개수다. 처음 만든 버전에는 정보가 훨씬 많았다. 격자 정보, 반복 횟수, 수렴 이력.
전부 뺐다. 이유는 3편의 목표 때문이다. 궁금증의 수명 안에 답이 나와야 한다. 화면에 읽을 것이 많으면 그 시간이 늘어난다.
대신 필요한 사람이 펼쳐볼 수 있게 접어뒀다. 기본은 최소, 필요하면 전부.
Learn — 배우는 곳
교육용 모드다. 그런데 이건 부가 기능이 아니라 설계상 중요한 자리다.
왜 교육이 들어가나
두 가지 이유가 있다.
첫째, 우리 도구의 한계를 이해해야 제대로 쓸 수 있다. 19편에서 정리한 타협들 — 2차원 근사, 복사 무시, 정상 상태 — 을 모르면 결과를 잘못 읽는다. “이 값은 상한이다”라는 것을 알아야 한다.
그런데 그걸 경고문으로 띄우면 아무도 안 읽는다. 직접 해보면서 알게 하는 편이 낫다.
그래서 Learn에는 이런 것들이 있다. 격자를 성기게 했다가 촘촘하게 해보며 답이 어떻게 변하는지, 경계조건을 바꾸면 결과가 얼마나 달라지는지, 2차원과 3차원이 어떻게 다른지.
둘째, 22편에서 말한 PINN의 교육적 가치. 물리 법칙을 손실에 넣고 학습시키면 모델이 물리를 “발견하는” 과정이 눈에 보인다. 방정식을 외우는 것과 다른 이해를 준다.
교육이 사용자층을 만든다
실용적인 측면도 있다. 수치해석을 처음 접하는 사람 — 학생, 다른 분야 엔지니어 — 이 우리 도구의 잠재 사용자다. 그들에게 필요한 첫 단계는 계산이 아니라 이해다.
25편에서 말한 순환의 입구가 여기 있다. 배우러 온 사람이 쓰는 사람이 된다.
Models — 물리 모델을 고르는 곳
어떤 물리 현상을 다룰지, 어떤 방법으로 풀지 선택하는 곳이다.
지금은 선택지가 좁다. 열전달, 2차원, FDM. 27편의 로드맵에 따라 항목이 늘어날 자리다.
여기서 중요한 설계 결정이 하나 있다. 이 화면은 기본적으로 감춰져 있다.
9편에서 “격자 설정을 노출하지 않는다”고 했다. 같은 원칙이 여기에도 적용된다. 대부분의 사용자는 어떤 방법으로 푸는지 알 필요가 없다. 시스템이 문제를 보고 적절한 것을 고른다.
그럼 왜 화면이 있나. 두 부류의 사용자를 위해서다.
확인하려는 사람. 전문가는 무슨 방법으로 풀렸는지 알고 싶어 한다. 그 정보가 없으면 결과를 신뢰하지 않는다.
배우려는 사람. Learn과 이어진다. 방법을 바꿔가며 차이를 보는 것이 학습이다.
즉 이 화면은 감사와 학습을 위한 창구다. 일상적인 사용 경로에서는 지나간다.
Projects — 작업을 모아두는 곳
한 제품에 대한 여러 시도를 묶어두는 곳이다.
왜 필요한가
6편에서 사용자 입력의 다수가 “변형형”이라고 했다. 조건을 조금씩 바꿔가는 것. 그러면 하나의 문제에 대해 열 개, 스무 개의 변형이 생긴다.
이것들을 흩어놓으면 나중에 무엇을 왜 시도했는지 알 수 없다. 비교할 수 없으면 시도가 축적되지 않는다.
그래서 Projects에서는 변형들을 나란히 놓고 비교할 수 있다. 두께별 결과, 재료별 결과.
그리고 여기가 25편의 데이터가 쌓이는 곳이다. 반복 궤적(③)과 종료 지점(④)이 이 구조에서 자연스럽게 기록된다. 별도로 수집하는 것이 아니라, 사용자가 자기 작업을 정리하는 과정에서 남는다.
25편에서 정한 원칙 — 데이터 수집이 사용 경험을 나쁘게 하는 결정은 하지 않는다 — 가 이렇게 구현된다.
네 부분의 관계
정리하면 이런 구조다.
| 화면 | 역할 | 대응하는 편 |
|---|---|---|
| Solver Lab | 문제를 푼다 | 5·10·12·15편 |
| Learn | 한계를 이해한다 | 19·22편 |
| Models | 방법을 감사한다 | 9·17·20편 |
| Projects | 시도를 축적한다 | 6·25편 |
Solver Lab이 중심이고 나머지 셋이 그것을 받친다.
Learn은 결과를 올바르게 읽게 하고, Models는 방법을 확인하게 하고, Projects는 시도가 흩어지지 않게 한다.
만들면서 배운 것
이 편을 마무리하며 하나 적어두고 싶다.
처음 계획에는 Learn과 Models가 없었다. 계산기만 만들면 된다고 생각했다.
그런데 만들면서 알게 된 것이 있다. 거친 도구는 설명이 필요하다.
정밀한 도구는 “믿고 쓰세요”라고 할 수 있다. 우리 도구는 그럴 수 없다. 19편에 정리한 타협들이 있고, 그 타협을 모르면 잘못 쓴다.
그래서 한계를 가르치는 것이 기능의 일부가 되었다. 이건 부담이 아니라 성격이다. 3편에서 말한 “비어 있는 중간층”의 도구는 원래 그런 것일 수 있다. 빠르고 거칠고, 그래서 사용자가 자기가 무엇을 보고 있는지 알아야 하는 도구.
다음 편에서 그 교육 축을 조금 더 이야기한다.
다음 편 예고 — 교육이라는 또 하나의 축. 계산 도구가 왜 교육으로 이어지는지, 그리고 그것이 사업에 어떤 의미인지.