[태그:] 한글 입력

확인 방법과 측정 전에 멈춘 기록

한글을 완성하려고 누른 Enter와 보내려고 누른 Enter를 앱이 구별할까? ‘20글자’ 제한은 악센트와 이모지까지 온전히 보존할까? 이를 확인할 시험용 입력창을 준비했지만 측정 실행은 한 번도 하지 않았다. 실제 OS 입력기를 거쳐 한글을 조합했다는 사실을 기록할 방법이 없었고, 완성 문자열을 자동 검사할 도구도 문제가 생겼을 때 멈추고 뒷정리하는 마지막 점검을 통과하지 못했다. 이 글은 무엇을 확인하도록 설계했는지, 준비에서 무엇을 확인했고 왜 멈췄는지를 다룬다. 마지막에는 직접 확인할 때 쓸 기록 양식을 정리했다.

조합 확정과 제출을 따로 정한다

2026년 10월 13일 확인한 문서에 따르면, 입력기로 글자를 조합하는 동안에도 입력창의 내용은 바뀔 수 있다. 조합 중인 글자를 확정하는 일과 앱에 저장을 요청하는 일은 구별해야 한다. 브라우저의 ‘지금 조합 중’ 표시(isComposing)가 있어도, 조합 경계의 키 누름 알림(keydown)은 그 표시가 켜진 구간 밖에 올 수 있다고 문서는 설명한다. 이 표시 하나를 검사한다고 처리가 끝나는 것은 아니다. 이번 준비에서 설치된 브라우저의 실제 이벤트 순서는 관찰하지 않았다. W3C UI Events, MDN 키 입력 안내

이번 입력창에는 다음 약속을 정했다. 조합을 확정하는 Enter에서는 저장하지 않아야 한다. 조합이 끝난 1–20묶음의 입력에 다시 Enter를 누르거나 저장 버튼을 누르면, 독립된 시험에서 명시적 제출 한 번당 한 번 저장해야 한다. 21묶음이면 두 번째 Enter에서도 저장하지 않아야 한다. 이는 이 앱을 위한 제품 규칙이며 모든 입력창이 따라야 할 보편 규칙은 아니다. 한 Enter로 확정과 전송을 함께 하기를 기대하는 경우와도 다르다. 저장 버튼을 확인하는 검사로 두 번째 Enter의 동작까지 증명할 수는 없다.

이를 검사하려면 실제 OS 입력기를 거친 키 조작, 당시 선택된 입력기, 조합 중인 상태와 앱의 이벤트 기록을 함께 남겨야 한다. 완성 문장을 붙여 넣거나 코드로 조합 이벤트를 만들어 보내면 실제 한글 조합을 시험한 것이 아니다. 이번 준비에서는 실제 입력을 수행할 사람이 없었고, 자동화도 실제 OS 입력기를 거쳤다는 근거를 확보하지 못했다. 따라서 조합과 제출을 구별하는지는 여전히 답하지 못했다.

원래 계획은 한 Mac의 Safari와 Chrome에서 완성형 가·각을 각각 19·20·21번 반복한 여섯 입력만 실제 조합으로 다루는 것이었다. 마지막 글자를 조합 중인 상태에서 Enter로 확정하고 500ms 뒤 다시 Enter를 누르는 절차였으며, 빠른 입력이나 모든 입력기를 대표하지 않는다. 한글 두벌식이 환경 설정에 있다는 것만 확인했을 뿐 실제 선택·사용은 입증하지 못했다. 두 브라우저 모두 측정하지 않았다. 분해형 한글·악센트·이모지는 아래의 완성 문자열 검사 대상이다.

‘20글자’의 단위와 원문 보존을 따로 확인한다

길이 제한에는 다른 문제가 있다. 같은 날 확인한 문서에서 HTML의 maxlength는 UTF-16 코드 단위를 센다. 사람이 한 글자처럼 읽는 묶음과 일치하지 않을 수 있다. 준비한 자료에서 e와 그 위에 붙는 결합 악센트 표시는 문자 묶음 규칙상 한 묶음이지만 UTF-16에서는 두 단위다. MDN maxlength 설명

이 글에서는 확장 자소 군집, 즉 문자들을 규칙에 따라 묶은 단위로 제한을 정한다. 눈에 보이는 글자에 가까운 기준이지만 언제나 한 모양이나 같은 화면 너비를 뜻하지는 않는다. Intl.Segmenter는 이 단위로 나누는 기능을 제공한다. 오래된 브라우저에서는 지원 여부부터 확인해야 한다. 다만 기능이 있다는 사실과 특정 브라우저가 기대한 경계로 나눈다는 확인은 별개다. Unicode 문자 경계 규칙, Intl.Segmenter 설명

시험 자료는 영문, 완성형·분해형 한글, 결합 악센트, 이모지 등 열 종류를 각각 19·20·21묶음으로 반복한 시험용 문자열 30개다. 빈 입력, 1–18묶음이나 서로 다른 종류를 섞은 입력까지 다루는 자료는 아니다. 기대값은 19·20묶음을 명시적 제출 한 번에 원문 그대로 저장하고, 21묶음은 저장하지 않되 이유를 표시하고 전체 내용을 수정할 수 있게 남기는 것이다. 초과분을 잘라 성공으로 처리하지 않는다.

‘그대로’도 화면만 보고 판단하지 않는다. 입력 전·전달 후·저장 후의 코드 포인트(문자의 고유 번호)와 UTF-16 단위의 배열을 비교하도록 했다. 완성형·분해형 한글은 같은 모양으로 보여도 내부 표현이 다를 수 있다. 조합 확정과, 문자 표현을 일정한 형태로 바꾸는 정규화는 다른 일이며, 이번 규칙은 자동 정규화나 공백 제거도 허용하지 않는다. 여기서 저장은 페이지 메모리에 남긴 기록이다. 데이터베이스나 새로고침 뒤 보존을 검사하는 설계는 아니다.

완성 문자열 검사는 코드로 값을 넣고 저장 버튼 호출과 코드로 만든 Enter를 각각 보내는 앱 로직 검사로 설계했으며, 이 검사도 실행하지 않았다. 실제 키보드의 기본 제출 동작이나 OS 조합을 검증하는 방법은 아니다. maxlength도 코드로 넣은 값과 사용자가 편집한 값을 구별하므로, 코드 삽입으로 실제 붙여 넣기 동작을 대신 검증할 수 없다. 별도 maxlength 입력창에 실제로 붙여 넣는 진단도 계획했으나, 전달된 문자열을 확인할 경로가 없어 실행하지 않았다.

준비 검사에서 확인한 범위

2026년 10월 14일에는 입력창 코드, 30개 문자열 목록, 기대 저장값·경계를 담은 정답 자료, 이벤트 기록기를 만들었다. 입력창 핵심 로직과 기록기를 브라우저 없이 확인한 초기 준비 테스트 7개는 통과했다. 실제 브라우저에서 저장 동작을 측정한 결과는 아니다. 이후에는 중복 저장이나 거부된 글자 잘라내기 같은 오류를 일부러 넣어 검사기가 잡는지도 확인했다. 이는 검사 도구의 검증이며, 실제 입력창에서 발견한 오류나 수정 효과가 아니다.

10월 17일 독립 검토는 원문 30개와 정규화 비교용 변환형 60개, 총 90개 표현의 코드 포인트·UTF-16 배열과 문자 묶음 경계를 별도 계산과 대조해 불일치가 없다고 기록했다. 비교에는 Python UCD 13.0.0과 이 자료에 한정한 명시적 경계 규칙을 사용했다. 원문과 변환형이 서로 같다는 뜻은 아니다. Node가 보고한 데이터 버전은 Unicode 17.0이며, 인용한 Unicode 18 규칙 문서는 기준을 설명할 뿐 이 계산의 인증서가 아니다. 이 유한 자료의 일치로 Unicode 18 전체 준수나 브라우저 동작을 인증할 수 없다.

외부 요청 없이 로컬에서 검사하려고 시험 컴퓨터에서도 준비 점검을 했다. 10월 17일에는 OS 수준 통신 제한 아래에서 소켓에 주소를 묶는 bind 네 번과 접속을 시도하는 connect 네 번이 모두 권한 오류로 거부됐다. 확인 범위는 이 여덟 시도에 한정한다. Chrome 준비 점검도 실패했다. 이후 조정 기록은 외부 제한 아래에서 Chrome 내부 보호 장치의 초기화가 실패한 것으로 판단했다. 이는 한글 입력 실패가 아니다. 이후 Chrome 자체 보호 장치를 유지하며 브라우저 설정으로 외부 통신을 제한하는 대안을 준비했지만, 설계상 OS 수준 강제보다 약하다는 판단을 기록했다. 실제 차이를 측정한 것은 아니며 후속 컴퓨터 점검도 끝내 수행하지 않았다.

테스트가 통과했는데도 멈춘 이유

검사 도구는 자신이 시작한 브라우저 같은 하위 작업을 추적하고, 문제가 생겨도 종료·정리할 수 있어야 한다. 10월 26일 검토는 이 실행기가 프로세스 상태 확인에 실패했을 때 이를 ‘프로세스 없음’으로 취급하는 결함을 발견했다. 수정 뒤 독립 검토에서는 이 경우 종료 신호를 보내거나 삭제하지 않고 실패로 멈추는 것을 모의 검사로 확인했고, 준비 도구 테스트 40개도 통과했다. 이 통과가 아래의 정리 결함을 해소하지는 못했다.

그럼에도 새 결함이 남았다. 하위 프로세스를 시작한 직후 관리 기록을 쓰는 작업이 실패하면, 그 프로세스의 종료나 대기를 시도하지 않는 경로가 있었다. 일부러 기록 실패를 일으킨 모의 검사에서 드러난 문제다. 실제 프로세스가 유출됐다는 관찰은 아니다.

사전에 정한 마지막 재검토에서도 실행 준비 판정을 받지 못하면 중단한다는 규칙을 적용했다. 시간이 일부 남았어도 추가 수정으로 이어 가지 않았다. 입력창에서 실제 결함이 측정된 경우에만 수정 전후를 비교할 계획이었다. 그런 결함은 확인하지 못했으며, 앞의 실행기 수정과는 별개다. 완성 문자열 측정, 실제 한글 조합 측정, 붙여 넣기 진단과 입력창 수정 전후 비교는 모두 미실행(NOT RUN)이다. 테스트 통과 수를 앱 성공률로 바꿀 수 없고, 어떤 브라우저나 수정 방식이 더 낫다는 결론도 없다.

내 입력창을 확인할 때 남길 기록

다음은 로컬 시험용 입력창에서 사용할 점검 양식이다. 시험용으로 만든 텍스트만 쓰고, 외부로 전송하지 않으며 페이지 메모리에만 저장하는 화면을 사용한다. 키 기록도 시험 입력창으로 한정하며, 실제 개인 텍스트를 기록표에 옮기지 않는다. 양식을 채웠다는 사실만으로 입력 경로가 입증되는 것은 아니며, 확인 수단이 없는 항목은 ‘모름’으로 남긴다. 화면에서는 저장 기록 수와 거부 뒤 남은 글·오류 설명부터 확인할 수 있다. 조합 상태나 내부 값 비교는 이벤트 기록 같은 도구가 필요하다.

실행하지 못한 검사는 ‘미실행’, 시도했으나 입력 출처나 기록이 훼손된 검사는 ‘판정 무효’, 유효한 검사에서 약속을 어긴 경우는 ‘실패’로 구분한다. 미실행·판정 무효도 기록에 남기고, 이들을 지워 성공률을 만들지 않는다. 길이 검사의 일치가 실제 조합 검사를 대신하지도 않는다. 먼저 원하는 Enter 동작과 글자 단위를 적고, 저장 횟수와 원문을 따로 확인한다. 이번 준비가 제공하는 것은 이 확인 방법과 한계이며, 입력창이 제대로 작동한다는 측정 결과는 아니다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조했으며, 작성자가 최종 원고를 검토하고 수정 방향을 결정했습니다.