금액 입력 UX: 통화와 소수 구분자를 명확하게 설계하기

금액 입력란에서는 사용자가 의도한 수치, 그 수치에 붙는 통화, 애플리케이션이 저장할 값이 일치해야 합니다. 통화를 명확히 표시하고 숫자 형식을 정하며, 중요한 작업을 실행하기 전에 해석된 금액을 확인하게 하세요. 보기 좋게 표시하는 과정에서 금액 자체가 조용히 달라져서는 안 됩니다.

먼저 폼 전체의 필드 요구사항을 정한 다음 금액에 필요한 별도 규칙을 추가하세요. 쉼표가 소수 구분자일 수 있고, 붙여넣은 견적에 통화 코드가 포함될 수 있으며, 통화가 바뀌면 허용 소수 자릿수도 달라질 수 있습니다. ‘숫자를 받는다’만으로는 충분하지 않습니다.

금액 입력란의 역할을 구체적으로 정하기

직원이 발주서를 만들기 전에 공급업체의 견적 총액을 기록하는 구매 애플리케이션을 생각해 보겠습니다. 예제 견적은 USD 1,234.50입니다. 이 입력란은 그 총액을 기록할 뿐, 세금을 계산하거나 통화를 환산하거나 결제를 실행하지 않습니다.

이 예제 제품은 USD, EUR, JPY로 된 양수 견적 총액을 받습니다. USD와 EUR에는 소수점 이하 두 자리까지 허용하고, JPY에는 정수 금액만 허용합니다. 이는 예제 애플리케이션의 규칙입니다. 같은 제품 안에서도 단가, 환율, 회계 조정액에는 다른 정밀도나 부호 규칙이 필요할 수 있습니다.

견적의 통화와 사용자의 숫자 표시 환경설정을 분리하세요. 한국어 화면에서도 유로 견적을 기록할 수 있고, 독일식 숫자 형식으로 미국 달러 금액을 표시할 수도 있습니다. USD를 선택했다고 화면 언어까지 바뀌거나, 현재 입력된 텍스트의 해석 방식이 조용히 달라져서는 안 됩니다.

입력란에는 ‘견적 총액’처럼 역할을 나타내는 라벨을 쓰고, 통화 선택에도 별도 라벨을 붙이세요. 통화 목록에서는 ‘USD — 미국 달러’처럼 뜻을 알 수 있는 항목을 제공하며, 금액 가까이에도 코드를 유지합니다. 여러 통화를 다루는 폼에서는 달러 기호 하나만으로 맥락을 충분히 전달하기 어렵습니다.

입력 중인 텍스트, 해석된 금액, 확인용 표시를 구분하기

입력 중인 텍스트는 아직 완성되지 않았을 수 있습니다. 빈 문자열, ‘1234.’, 소수 부분을 선택해 바꾸려는 상태가 모두 가능합니다. 이런 임시 텍스트는 유효한 값으로 받아들인 금액과 다릅니다. 확인 화면의 표시는 같은 금액을 읽기 좋게 표현한 또 다른 형태입니다.

예제에서는 입력란에 ‘1234.50’이 있고, 해석된 금액은 USD 기준 1234.50이며, 확인 화면에는 ‘USD 1,234.50’이 보일 수 있습니다. 세 표현은 서로 일치해야 합니다. 사용자가 보이는 입력란을 미해결 상태로 수정했는데, 예전에 유효했던 숨겨진 값이 그대로 제출 가능하게 남아 있어서는 안 됩니다.

Unicode CLDR의 통화 패턴은 통화 기호의 위치와 자릿수 묶음 등 표시 관례를 설명합니다. 애플리케이션이 붙여넣은 모든 문자열을 어떻게 해석해야 하는지까지 정해 주지는 않습니다. 표시 라이브러리를 완전한 입력 정책으로 착각하지 않도록, 텍스트 해석 규칙과 표시 규칙을 따로 명세하세요.

개발 전달 메모에는 ‘국제 통화 지원’이라는 포괄적인 문구 대신 구체적인 대응 사례를 적으세요. 선택한 숫자 형식, 입력 텍스트, 해석된 금액, 통화, 확인 화면 표시를 한 묶음으로 정리하고 관련 상태 옆에 둡니다. 규칙이 정밀하더라도 사용자가 보는 화면은 간결하게 유지할 수 있습니다.

붙여넣은 구분자의 의미 정하기

다른 애플리케이션에서 복사한 견적은 다른 숫자 형식을 사용할 수 있습니다. 미국식 ‘1,234.50’과 독일식 ‘1.234,50’은 같은 수치를 나타냅니다. 소수 구분자와 자릿수 구분자의 역할을 이해해야 합니다. 쉼표와 마침표를 모두 삭제하는 방식은 안전한 해석 규칙이 아닙니다.

CLDR 숫자 기호 안내는 소수 구분 기호와 자릿수 묶음 기호를 구분하고 지역별 형식을 다룹니다. 입력 경험에는 화면에서 명시하거나 사용자가 이미 설정한 숫자 형식을 적용하세요. 구두점 모양만 보고 견적의 통화를 추측해서는 안 됩니다.

여기서는 허용 범위를 의도적으로 제한한 해석 정책을 사용합니다. 제품이 추가 붙여넣기 형식을 신뢰할 수 있게 구분하고 해석 결과도 보여 줄 수 있다면 더 넓게 지원할 수 있습니다. 핵심은 두 가지 해석이 모두 가능할 때 어떻게 처리할지 결정하는 것입니다.

허용하지 않는 형식을 붙여넣었다면 ‘소수점에는 마침표를 사용해 주세요. 예: 1234.50’처럼 다음 행동을 알려 주세요. 숫자 형식 변경을 지원하는 제품이라면 그 경로도 제공합니다. 직원이 견적과 비교할 수 있도록 원래 입력한 텍스트는 그대로 둡니다.

USD가 선택된 상태에서 ‘USD 1,234.50’을 붙여넣었다면, 인식한 USD 표기를 제거해도 의미가 바뀌지 않습니다. 그러나 USD를 선택한 채 ‘EUR 1,234.50’을 붙여넣으면 통화 불일치를 처리해야 합니다. EUR만 조용히 버리면 깔끔해 보이지만 잘못된 통화의 금액이 들어 있는 입력란이 됩니다.

편집을 방해하지 않는 시점에 서식 적용하기

이 발주서 폼에서는 포커스가 있는 동안 쉽게 수정할 수 있는 형태를 유지하고, 완전하고 유효한 입력이 포커스를 잃을 때 서식을 적용합니다. 직원이 ‘1234’를 입력하는 도중 ‘1’을 ‘1.00’으로 바꾸거나, 가운데 숫자를 수정할 때 커서를 끝으로 이동시키지 마세요.

입력과 동시에 서식을 적용하는 방식도 잘 설계할 수 있습니다. 다만 커서 위치, 선택 범위, 삭제, 붙여넣기, 입력기 조합을 세심하게 다뤄야 합니다. 예를 들어 Pega의 통화 입력 컴포넌트는 입력 중 서식 적용을 명시합니다. 이는 그 컴포넌트의 동작이지, 모든 금액 입력란이 따라야 할 보편 규칙은 아닙니다.

실제 수정 작업을 기준으로 선택하세요. ‘1234.50’에서 ‘34’를 바꾸고, 소수 부분을 지우고, 전체 값 위에 붙여넣고, 변경을 실행 취소하게 해 보세요. 흔한 수정 동작과 입력란이 충돌한다면 기본 상태의 숫자가 아무리 보기 좋아도 충분하지 않습니다.

모바일에서는 소수 입력용 키보드 힌트가 도움이 될 수 있습니다. HTML의 inputmode 정의는 소수를 입력하는 방식에 대한 힌트이며, 금액을 검증하는 규칙은 아닙니다. 지원 기기에서 폼이 요구하는 구분자를 실제로 입력할 수 있는지까지 구현된 컨트롤로 확인하세요.

허용하지 않는 소수 자릿수를 임의로 반올림하지 않기

직원이 USD 1,234.567을 입력했다고 해 보겠습니다. 이 견적 총액 규칙에서는 소수점 이하 세 자리를 받지 않습니다. 입력값을 유지하고 ‘USD는 소수점 이하 2자리까지 입력해 주세요’라고 설명하세요. 조용히 1,234.57을 저장하면 애플리케이션이 견적과 다른 총액을 기록하게 됩니다.

제품이 계산 결과를 의도적으로 반올림한다면 반올림 규칙과 결과를 보여 주는 시점을 정해야 합니다. 사용자가 입력한 허용 범위 밖의 값을 규격에 맞추려고 반올림하는 것과는 다른 결정입니다. 버림도 마찬가지입니다. 세 번째 숫자를 화면에서 숨긴다고 안전하게 처리되는 것은 아닙니다.

금액의 정밀도는 화면 뒤에서 수행하는 작업과도 맞아야 합니다. Stripe 통화 문서는 연동 조건을 확인해야 하는 이유를 보여 줍니다. Stripe의 금액 API는 최소 통화 단위를 사용하므로 10 USD는 1000, 10 JPY는 10으로 표현하며, 통화별 예외도 있습니다. 이는 Stripe의 규칙이지 모든 애플리케이션의 금액에 100을 곱하라는 뜻이 아닙니다.

구매 애플리케이션에서는 정확한 소수 표현 방식을 개발자와 합의하고 확인 화면도 그 값과 맞추세요. 0을 허용하는지, 음수 조정액이 이 흐름에 속하는지, 상한이 있는지도 별도로 정합니다. 필수 입력란이 비어 있다면 사람이 값을 넣기 전까지 빈 상태여야 합니다. ‘0.00’이라는 자리표시자가 실제 총액 0을 만들어서는 안 됩니다.

통화 변경이 환산처럼 보이지 않게 하기

입력란에 1234.50이 남아 있는 상태에서 직원이 USD를 JPY로 바꿉니다. 통화 라벨만 바꾸면 금액의 의미가 달라지고, ‘.50’을 버리면 수치도 달라집니다. 어느 쪽도 통화 환산은 아닙니다.

이 설계에서는 입력한 숫자를 아직 해결되지 않은 초안으로 유지하고, ‘이 폼의 JPY 금액은 정수만 허용합니다. JPY 견적 총액을 입력해 주세요’라고 안내합니다. 이전 USD 확인 값은 더 이상 유효하지 않습니다. 직원은 USD로 돌아가 이전 초안을 복구하거나, 해당 견적에 적힌 실제 JPY 총액을 입력한 뒤 새로 확인할 수 있습니다.

USD에서 EUR로 바꾸면 기존 숫자는 같은 소수 자릿수 규칙을 만족하지만, 여전히 다른 통화의 금액이 됩니다. 숫자는 화면에 남겨 둘 수 있어도 발주서를 만들기 전에 ‘EUR 1,234.50’을 다시 확인해야 한다는 점을 분명히 해야 합니다. 소수 자릿수 오류가 나타나지 않더라도 통화 코드 변경은 의미 있는 변경입니다.

제품이 환산을 제공한다면 별도 동작으로 구분하고, 사용자가 수락하기 전에 원래 금액, 환산 결과, 적용 환율의 맥락, 관련 수수료와 반올림을 보여 주세요. 이 예제는 환산 기능을 제공하지 않으므로 환율 한 줄을 장식처럼 넣으면 오해를 만듭니다.

저장할 금액과 통화를 한 쌍으로 확인하기

발주서 확인 화면에는 공급업체와 견적 참조번호 옆에 통화 코드를 포함한 견적 총액을 표시하세요. ‘수정’ 동작으로 금액 입력란에 돌아갈 수 있어야 합니다. 숫자나 통화 중 하나라도 수정하면 이전 확인 상태는 무효가 됩니다. 오래된 값에 승인 표시가 붙은 채 남아 있어서는 안 됩니다.

통화 정보는 눈에 보이는 접두 기호 외의 방식으로도 전달되어야 합니다. GOV.UK 텍스트 입력 안내는 접두어나 접미어에만 의존하지 말라고 설명합니다. 의미 있는 라벨과 관련 안내를 실제 입력 컨트롤에 연결해, 보조 기술을 쓰는 사용자도 같은 금액 맥락을 알 수 있게 하세요.

저장 후에는 저장이 확인된 금액과 통화를 보여 주세요. 저장 실패가 확실하다면 검토한 금액·통화를 유지해 수정하거나 재시도할 수 있게 하고, 발주서가 저장되지 않았다고 설명합니다. 결과를 알 수 없는 상태라면 다시 만들도록 안내하기 전에 발주서 상태부터 확인해야 합니다. 입력란의 초록색 표시는 입력이 유효하다는 뜻이지 발주서가 완성되었다는 뜻이 아닙니다.

Pixso에서 통화 변경과 확인 화면을 나란히 설계하기

이 견적 입력 작업만을 위한 Pixso 캔버스를 만드세요. USD 편집 상태와 ‘USD 1,234.50’ 확인 상태를 배치하고, ‘1234.50’을 그대로 남긴 JPY 변경 상태에 정수 금액 안내를 추가합니다. 금액 필드 컴포넌트를 재사용하면 각 상태의 라벨, 통화 위치, 메시지 간격을 비교하기 쉽습니다.

통화 변경과 수정 동작을 관련 프레임에 연결해 이동 경로를 미리 보세요. Auto Layout으로 오류 메시지가 길어졌을 때 아래의 견적 참조번호와 버튼에 어떤 영향을 주는지도 확인합니다. Pixso의 화면 연결과 검토 기능은 이 흐름을 검토하는 데 쓰이며, 숫자 해석과 금액 처리 규칙은 애플리케이션 명세에 속합니다.

검토자에게 견적을 입력하고 소수 부분을 바꾼 뒤 통화를 한 번 변경하게 하세요. 확인 상태마다 발주서에 어떤 금액이 들어갈지 물어보고, 답이 엇갈린 부분은 해당 프레임 옆에 댓글로 남깁니다. 구분자의 뜻을 추측하거나 환산이 일어났다고 가정해야만 답할 수 있다면 입력 규칙을 더 분명하게 만들어야 합니다.