손안의 수치해석/1부 문제

계산은 어디서 일어나야 하는가

04 / 30

2026-07-27 · 읽는 데 8분

서버로 보내면 되지 않나

폰의 성능이 부족하다는 이야기를 하면 대부분 같은 해결책을 떠올린다.

“계산은 서버에서 하고, 폰은 결과만 받으면 되잖아.”

맞는 말이다. 실제로 대부분의 모바일 서비스가 그렇게 동작한다. 무거운 일은 데이터센터의 강력한 기계가 하고, 폰은 화면을 그리는 역할만 한다. 지도 앱이 경로를 찾을 때도, 번역 앱이 문장을 옮길 때도 실제 계산은 서버에서 일어난다.

이 방식의 장점은 분명하다. 기기의 성능에 구애받지 않고, 모델을 개선하면 모든 사용자에게 즉시 적용되고, 배터리도 아낀다.

그래서 우리도 처음에는 이 방향을 당연하게 생각했다. 그런데 따져볼수록 걸리는 것들이 나왔다.

첫째, 대기 시간이 다시 생긴다.

목표는 30초 안에 방향을 확인하는 것이었다. 그런데 서버로 보내면 네트워크 왕복이 붙는다. 조건을 올리고, 대기열에 들어가고, 계산되고, 결과가 내려온다. 계산 자체가 1초라도 전체 경험은 몇 초에서 수십 초가 된다.

혼자 쓸 때는 괜찮다. 문제는 사용자가 늘었을 때다. 해석은 웹페이지를 띄우는 것과 달라서 한 번의 요청이 서버 자원을 오래 붙잡는다. 동시에 백 명이 요청하면 대기열이 생기고, 우리가 없애려던 바로 그 대기열이 형태만 바꿔 돌아온다.

둘째, 비용이 사용량에 비례한다.

이건 사업의 문제이면서 동시에 제품의 문제다.

계산을 서버에서 하면 사용자가 해석을 한 번 돌릴 때마다 우리에게 돈이 나간다. 그러면 자연스럽게 제한을 걸게 된다. 하루 몇 회까지, 무료 플랜은 몇 회까지.

그런데 우리가 만들려던 것은 “부담 없이 여러 번 시도하는” 도구였다. 열 번 시도해서 아홉 번 버리는 것이 핵심인데, 시도할 때마다 횟수가 차감된다면 사용자는 다시 질문을 고르기 시작한다. 앞 편에서 이야기한 그 검열이 그대로 재현된다.

계산 비용이 사용자에게 보이는 순간, 시도의 자유가 사라진다.

셋째, 오프라인에서 못 쓴다.

현장에서 쓰겠다는 것이 애초의 목적이었다. 그런데 지하 주차장, 공장 내부, 지방 출장길처럼 정작 확인하고 싶은 곳일수록 네트워크가 불안정한 경우가 많다.

같은 세 항목을 기기 계산으로 바꿔 놓으면 부호가 반대가 된다.

아래 두 줄은 기기 계산에 불리하다. 그런데 위 세 줄이 우리가 세운 목표와 정확히 맞물려 있었다.

특히 비용 구조가 결정적이었다. 사용자가 백 명이든 십만 명이든 계산 비용이 늘지 않는다는 것은, “무제한으로 돌려도 됩니다”라고 말할 수 있다는 뜻이다. 이건 단순한 가격 정책이 아니라 제품의 성격을 바꾸는 조건이다.

물론 공짜는 아니다. 기기에서 돌리기로 하면 감당해야 할 것이 생긴다.

문제 크기를 스스로 제한해야 한다. 사용자가 격자를 지나치게 잘게 나누면 앱이 멈춘다. 그래서 시스템이 한계를 알고 미리 막거나, 자동으로 조정해야 한다. “당신의 기기에서는 여기까지”라는 판단을 대신 내려주는 층이 필요하다.

기기마다 성능이 다르다. 최신 기종에서는 3초에 끝나는 계산이 몇 년 된 기종에서는 30초가 걸릴 수 있다. 같은 앱이 사람마다 다른 경험을 준다.

계산 코드를 앱 안에 넣어야 한다. 서버라면 파이썬으로 편하게 짜고 라이브러리를 마음껏 쓸 수 있다. 기기에서 돌리려면 그 환경에서 동작하는 형태로 다시 만들어야 한다.

결국 우리가 택한 것은 양자택일이 아니었다.

계산은 기기에서, 이해는 서버에서.

사용자가 문장으로 설명한 문제를 해석 조건으로 번역하는 일은 서버(또는 외부 모델)에서 한다. 이건 한 번만 일어나고, 텍스트를 주고받는 것이라 가볍고 빠르다.
번역된 조건으로 실제 방정식을 푸는 일은 기기에서 한다. 이건 반복되고, 무겁고, 대기열을 만든다.

이렇게 나누면 각 부분이 잘하는 일을 맡는다. 언어를 다루는 일은 큰 모델이 잘하고, 정해진 수식을 반복 계산하는 일은 작은 칩도 충분히 한다.

그리고 이 분할에는 부수 효과가 하나 있다. 한 번 번역된 조건은 재사용할 수 있다. 조건을 조금씩 바꿔가며 열 번 돌릴 때, 번역은 처음 한 번만 하면 되고 나머지 아홉 번은 기기에서 즉시 돌아간다.

시도의 비용이 첫 회에만 붙고 그 뒤로는 거의 0에 가까워진다. 우리가 원하던 그림이다.

그런데 이 구조가 성립하려면 전제가 하나 있다. “번역된 조건”이라는 것이 명확한 형태로 존재해야 한다. 사람의 말과 계산기 사이에 놓일, 정확하고 다루기 쉬운 중간 형식.

그게 무엇이어야 하는지가 다음 문제였다.

다음 편 예고 — 처음 만든 것, 그리고 왜 실패했나. 첫 설계에서 우리가 세웠던 가정과, 그것이 실제로 부딪힌 지점을 정리한다.