계산기 앱 결과 화면, 숫자 하나를 키운 이유

바이브코딩이 대중화되고, 앱 하나 만드는건 정말 딸깍 하면 나오는데요. 그래서 계산기 앱을 만들더라도 계산식이 맞는 것과 사용자가 그 결과를 이해하는 것은 다른 문제였습니다. 연금 계산기 화면을 테스트하다가 이 둘 사이의 간격을 다시 확인했습니다.

목차

• 계산식은 통과했는데, 화면을 열어보니
• 카드가 다 똑같아서 생긴 문제
• 세 가지 질문으로 화면의 무게를 다시 나누다
• 작동하지 않는 버튼은 감췄다
• 다음부터 계산 완료를 끝으로 보지 않기로 했다

---

계산식은 맞는데, 뭔가 이상하다

계산기 앱을 만들 때 가장 먼저 챙기는 것은 계산식입니다. 입력한 값이 맞는지, 공식과 크게 어긋나지 않는지, 예외값에서 화면이 멈추지 않는지부터 확인합니다.

최근 연금과 개인형 퇴직연금(IRP, 회사가 아닌 개인이 직접 굴리는 퇴직 후 자금 계좌) 시뮬레이터를 테스트했을 때도 이 순서를 따랐습니다. 빌드는 통과했고, 입력부터 결과 화면까지 이동하는 흐름도 정상적으로 동작했습니다. 그런데 화면을 직접 열어보니 다른 문제가 보였습니다. 결과 화면에 필요한 정보가 한 번에 너무 많이 놓여 있었고, 어디부터 봐야 하는지 알기 어려웠습니다.

UI는 더 디테일해야한다

처음 화면은 카드 UI(정보를 네모난 상자 단위로 묶어 보여주는 방식)가 전부 비슷했습니다. 흰 배경, 얇은 회색 테두리, 작은 회색 글자. 현재 상태를 보여주는 카드, 다른 선택지를 비교하는 카드, 다음 행동을 알려주는 카드가 모두 같은 무게로 놓여 있었습니다.

정보를 빠짐없이 넣는 데는 성공했지만, 읽는 순서를 설계하지 못한 화면이었습니다. 중요한 숫자도 설명 문장 사이에 그대로 묻혀버렸습니다. 실기기에서 받은 피드백도 단순했습니다. 가독성이 좋지 않다는 말이었습니다.

고민을 더 하다

이 피드백을 받고 글자만 조금 키워서는 안된다고 생각했어요. 먼저 결과 화면에서 사용자가 반드시 알아야 하는 질문을 세 개로 나눴습니다.

• 지금 내 상황을 나타내는 숫자가 무엇인가
• 지금과 다른 선택을 하면 무엇이 달라지는가
• 오늘 당장 확인하거나 결정할 일은 무엇인가

이 세 질문에 맞춰 화면의 무게를 다시 배분했습니다. 가장 중요한 금액은 더 크게 보이게 했고, 다른 선택지를 보여주는 시나리오 카드는 배경색과 왼쪽 선을 달리해 현재 상태 카드와 구분했습니다. 설명 문장의 글자 크기와 대비도 함께 올렸습니다.

항목을 더 넣은 것이 아니라, 이미 있던 정보에 순서를 부여한 것입니다.

작동하지 않는 버튼은 감췄다

이 과정에서 기능 하나도 숨겼습니다. 결과 화면에는 '연금 제도 변경 알림 받기' 버튼이 있었는데, 아직 출시 전이라 알림 동의와 발송 템플릿을 연결할 수 없는 상태였습니다. 코드에는 다음 단계에서 다시 연결할 자리가 있었지만, 사용자 입장에서는 눌러도 반응 없는 버튼일 뿐이었습니다.

기능을 언젠가 만들 수 있다는 이유로 불필요한 버튼까지 있었던거죠. 작동할 때까지는 버튼을 감췄습니다.

앱 구동부터 UX까지

바이브코딩으로 가능한 것이 많지만 기획은 더 꼼꼼해야한다는 것을 알았습니다.

1. 화면을 열고 3초 안에 봐야 하는 숫자가 하나로 보이는가
2. 비교 정보가 현재 상태와 시각적으로 구분되는가
3. 아직 작동하지 않는 기능을 기대감이라는 이유로 노출하고 있지는 않은가

혼자 앱을 만들면 기획자, 개발자, 첫 사용자가 같은 사람인 경우가 많습니다. 그래서 로컬에서 테스트를 통과한 화면을 보며 "이 정도면 됐겠지"라고 넘기기 쉽습니다. 하지만 개발 화면에 익숙한 사람과 처음 결과를 받아 보는 사람은 보는 순서가 다릅니다. 만드는 사람은 카드가 왜 있는지 알고 읽지만, 사용자는 그 설명 없이 숫자와 버튼만 봅니다.

이 차이를 줄이는 가장 저렴한 방법은 완성 직전의 화면을 처음 보는 사람처럼 실제 휴대폰에서 한 번 눌러보는 것입니다. 어떤 숫자에 눈이 가는지, 비교 카드가 선택지로 읽히는지 아니면 장식처럼 보이는지, 버튼을 눌렀을 때 다음 단계가 분명한지만 적어도 확인할 수 있습니다. 화려한 사용성 조사 대신이 아니라, 배포 전에 할 수 있는 최소한의 현실 점검입니다.

이번 수정의 핵심은 디자인을 화려하게 바꾸는 것이 아니었습니다. 중요한 숫자를 더 크게 만들고, 비교해야 할 선택지를 분리하고, 아직 약속할 수 없는 버튼을 감춘 일입니다. 완성도는 구현한 기능의 수가 아니라, 사용자가 망설이지 않고 다음 행동을 고를 수 있는지에서 다시 확인해야 한다는 것을 이번에 배웠습니다.

---

자주 묻는 질문

Q1. 계산기 앱을 만들 때 계산식 검증만으로 충분한가요? 계산식 검증은 필수지만 충분하지 않습니다. 값이 맞아도 사용자가 결과 화면에서 무엇을 먼저 봐야 하는지 알 수 없다면 실제로는 이해하기 어려운 화면이 됩니다.

Q2. 정보를 많이 보여주는 것이 왜 문제가 되나요? 정보가 많을수록 친절하다고 생각하기 쉽지만, 결과 화면에서의 친절함은 정보량이 아니라 어느 정보부터 믿고 판단해야 하는지 알려주는 데서 나옵니다. 정보가 같은 무게로 나열되면 중요한 숫자도 함께 묻힙니다.

Q3. 아직 완성되지 않은 기능은 화면에 어떻게 처리해야 하나요? 작동하지 않는 기능은 화면에서 감추는 것이 안전합니다. 눌러도 반응이 없는 버튼은 기대감을 주는 대신 신뢰를 떨어뜨릴 수 있습니다.

Q4. 1인 개발자가 UX 문제를 어떻게 미리 확인할 수 있나요? 완성 직전의 화면을 실제 휴대폰에서 처음 보는 사람처럼 한 번 눌러보는 방법이 있습니다. 어떤 숫자에 눈이 가는지, 비교 카드가 선택지로 읽히는지를 확인하는 것만으로도 최소한의 현실 점검이 됩니다.

Q5. 이 원칙은 계산기 앱에만 적용되나요? 아니요. 돈이나 제도처럼 숫자와 선택지가 많은 화면이라면 대부분 같은 문제가 생깁니다. 핵심은 정보의 개수가 아니라 읽는 순서를 설계했는지 여부입니다.