한국어 터미널과 초성 검색이 매주 수작업이 되는 이유#
입력 중 조합이 어긋나는 현상과 파일에 저장된 글자가 깨져 보이는 현상은 다르게 조사해야 합니다. 이 절의 표는 한국어 작업과 터미널 문제 해결 안내를 정리한 것입니다.
| 상황 | 먼저 확인할 것 | 관련 안내 |
|---|---|---|
| 명령을 한글로 찾기 | / 목록에서 한글 이름이나 초성 검색 | 명령과 단축키 |
| 입력 중 글자 중복 | 일반 편집기와 다른 터미널에서도 같은지 | 한글 입력 문제 |
| 한글 파일명 찾기 | @로 파일을 찾아 선택 | 한국어 작업 |
| 파일 내용이 깨짐 | 원본을 보관하고 인코딩 확인 | 파일 인코딩 문제 |
Before / After: 한국어 터미널과 초성 검색의 현재 비용과 자동화 후 결과#
명령을 찾는 문제라면 목록 검색부터, 입력이 중복된다면 입력기와 터미널 비교부터 시작하세요. 파일 내용이 깨졌다면 화면 설정을 바꾸기 전에 원본 복사본을 보관하세요. 이 페이지는 특정 환경에서 문제가 해결된 전후 실측을 제공하지 않습니다.
단계별로 하기: 입력 규칙 → 실행 → 검증#
- Mirr Code 입력창에서
/를 입력하고 명령의 한글 이름이나 초성으로 찾습니다. 파일을 선택할 때는@를 사용합니다. - 화면과 응답의 기본 언어가 필요하면 문서에 안내된
/language ko를 사용합니다. 이는 언어 설정이지 인코딩 복구 명령이 아닙니다. - 입력 중 문제가 생기면 같은 문장을 일반 편집기와 다른 터미널에서 비교하고 운영체제·입력기·터미널을 기록합니다.
- 파일 내용이 깨졌다면 원본을 복사해 보관하고 에디터의 인코딩 선택으로 확인합니다. CP949나 EUC-KR은 가능한 예일 뿐 모든 파일의 인코딩은 아닙니다. 올바르게 보이는지 확인하기 전에는 변환해 저장하지 마세요.
검증: 테스트 출력과 체크리스트#
명령 목록에서 원하는 항목이 좁혀지는지, 선택한 파일명이 맞는지, 입력을 확정한 후에도 문제가 남는지 확인하세요. 인코딩을 살필 때는 복사본의 내용을 대조하고 원본을 유지합니다.
추가 검증 필요: 초성 입력으로 좁혀진
/명령 목록
초성 검색 화면, @ 파일 선택과 CP949 파일의 전후 화면은 아직 실측하지 않았습니다. 위 내용은 문서에 근거한 확인 절차입니다.
주의할 점과 한계#
터미널의 글꼴·확대 비율·입력기와 파일 인코딩은 서로 다른 문제일 수 있습니다. 화면 증상을 고치려고 프로젝트 파일을 바꾸지 마세요. 도움을 요청할 때는 오류와 화면에서 비밀번호·개인정보를 지웁니다. 파일 수정은 권한과 승인을 확인하고, 복구에 앞서 원본과 필요한 변경을 별도로 보관하세요.
입력·표시·저장 문제를 먼저 나누기#
한글이 이상하게 보인다는 설명만으로는 원인을 고르기 어렵습니다. 입력 중에 조합 글자가 겹치는지, 확정한 뒤에도 중복되는지, 이미 저장한 파일을 열 때만 깨지는지 나눠 적으세요. 같은 문장을 일반 편집기와 터미널 셸, Mirr 입력창에서 비교하면 조사 범위를 좁힐 수 있습니다. 편집기에서는 정상인데 특정 터미널에서만 조합이 어긋나면 파일 인코딩을 바꾸기 전에 터미널과 입력기 조합을 살펴보세요. 저장된 바이트를 바꾸는 작업은 그다음입니다.
재현 문장은 개인정보 없는 짧은 문장으로 정합니다. 한글 자모 조합, 공백, 숫자와 영문을 함께 넣으면 어느 지점에서 문제가 생기는지 설명하기 쉽습니다. 붙여넣기와 직접 타이핑도 구분하세요. 붙여넣기는 정상인데 직접 입력만 실패하면 같은 인코딩 문제라고 단정할 수 없습니다. 복사한 텍스트 자체에 보이지 않는 문자나 다른 정규화 형태가 있을 가능성도 있습니다. 문장을 저장했다면 원본과 복사본을 분리해 비교합니다.
| 비교 결과 | 좁혀 볼 범위 | 먼저 하지 않을 일 |
|---|---|---|
| 모든 앱에서 직접 입력이 이상함 | 운영체제 입력기와 언어 설정 | 프로젝트 전체 파일 변환 |
| 특정 터미널의 조합만 이상함 | 터미널 버전·입력기·표시 설정 | 정상 원본을 다른 인코딩으로 덮어쓰기 |
| 입력은 정상이고 파일 내용만 깨짐 | 파일 바이트와 디코딩 방식 | 오류 문자를 무시하고 저장 |
| 파일명은 보이지만 선택이 안 됨 | 실제 경로·공백·정규화·검색 대상 | 비슷한 이름 파일 일괄 삭제 |
| 선택은 되지만 화면 폭이 어긋남 | 글꼴·글자 폭·확대와 터미널 렌더링 | 소스 내용에 공백을 넣어 맞추기 |
이 표는 진단 가설을 나누는 방법입니다. 특정 운영체제나 입력기의 결함을 재현한 결과가 아닙니다. 버전 변경으로 해결된다고 단정하거나 임의의 설정을 모든 환경에 권하지 않습니다. 도움을 요청할 때 운영체제, 터미널, 입력기, Mirr 버전과 재현 문장을 함께 전달하세요. 화면을 공유하기 전에는 경로의 사용자 이름, 계정 정보와 다른 탭의 내용을 가립니다. 문제를 설명하는 데 필요하지 않은 전체 화면은 수집하지 않는 편이 좋습니다.
초성 명령 검색에서 확인할 것#
초성 검색은 명령 이름을 정확히 기억하지 못할 때 목록을 좁히는 기능으로 접근하세요. / 목록에서 찾고 있는 대상이 명령인지 먼저 확인합니다. 파일을 찾는 @ 검색과 대상이 다릅니다. 검색 결과가 없으면 같은 뜻의 임의 문장을 계속 넣기보다 문서에 있는 명령 이름과 현재 버전의 목록을 대조하세요. 언어 설정, 명령의 한글 이름과 실제 지원 여부를 확인하는 것이 먼저입니다. 이 글은 모든 한글 단어나 초성이 파일 검색에도 적용된다고 주장하지 않습니다.
목록에서 비슷한 항목이 여러 개 나오면 실행 전 설명과 영향을 읽어 보세요. 언어를 바꾸는 명령과 파일을 복구하는 명령은 위험이 다릅니다. 검색으로 항목이 좁혀졌다는 사실은 실행 승인과 별개입니다. 특히 복구·삭제·외부 연결 명령을 실수로 선택하지 않도록 현재 선택 상태와 실행 결과를 확인하세요. 검색 전후 화면이 필요한 경우에는 같은 입력과 같은 버전을 기록해 비교할 수 있어야 합니다. 단순한 웹사이트 화면을 실제 터미널 검색 증거로 대체하지 않습니다.
한글 파일명을 다룰 때#
파일명에는 공백, 괄호, 한글과 숫자가 함께 들어갈 수 있습니다. 셸에서 경로를 직접 쓰는 경우에는 해당 셸의 인용 규칙을 따라 정확한 경로를 전달해야 합니다. @로 선택했다면 표시 이름만 보지 말고 실제 경로가 원하는 파일인지 확인하세요. 같은 이름의 문서가 여러 폴더에 있을 수 있습니다. 저장소 밖의 개인 문서를 잘못 첨부하지 않도록 접근 범위와 선택 결과를 살피는 것이 필요합니다.
겉으로 같은 한글이 내부적으로 다른 유니코드 문자 배열일 수 있습니다. NFC와 NFD 같은 정규화 형태를 비교하는 것은 이런 차이를 조사하는 방법이지 모든 파일명을 일괄 변경하라는 권고가 아닙니다. 파일명을 바꾸면 링크, import와 작업 스크립트가 영향을 받을 수 있습니다. 먼저 복사본에서 문제 경로를 확인하고 이름 변경이 꼭 필요한 경우 호출자와 참조를 함께 검토하세요. 버전 관리에서 보이는 이름과 운영체제가 표시하는 이름도 비교할 수 있습니다.
대소문자나 공백 차이를 무조건 없애는 정리도 피하세요. 서로 다른 파일이 같은 이름으로 합쳐지거나 다른 운영체제에서 충돌할 수 있기 때문입니다. 이름을 바꾸기 전에 충돌 후보를 목록으로 만들고 담당자가 승인한 범위만 처리합니다. 자동화 코드가 경로를 문자열로 이어 붙인다면 사용자 입력을 셸 코드로 삽입하지 않는지도 확인하세요. 한글 지원 문제를 해결하면서 경로 처리의 안전성을 약화시키면 안 됩니다.
CP949와 UTF-8을 비교하는 안전한 순서#
인코딩은 화면에 보이는 문자열과 파일 바이트 사이의 해석 규칙입니다. 파일이 UTF-8인지 CP949인지 모르는 상태에서 저장하면 원래 바이트를 잃을 수 있습니다. 원본을 복사해 보관하고 에디터의 다시 열기 기능이나 승인된 읽기 도구로 다른 인코딩 해석을 확인하세요. 단지 오류가 나지 않았다고 올바른 해석이라고 판단하지 않습니다. 제목, 자주 쓰는 한글 단어와 특수문자를 원본 작성자나 신뢰할 수 있는 사본과 대조해야 합니다.
변환을 한다면 입력 인코딩과 출력 인코딩을 명시하고 다른 파일에 저장합니다. ignore나 replace 같은 오류 처리로 읽히지 않는 바이트를 버리면 문서가 정상처럼 보여도 내용이 사라질 수 있습니다. 허용하지 않은 손실은 실패로 처리하도록 검토하세요. 변환 후에는 줄바꿈, 구분자와 파일 끝의 내용까지 비교합니다. CSV나 설정 파일이라면 글자뿐 아니라 열과 파싱 결과가 유지되는지도 봐야 합니다. 언어 설정을 한국어로 바꾸는 명령은 이 변환을 수행하지 않습니다.
일부 문자는 CP949에서 표현할 수 없을 수 있으므로 어느 방향으로든 변환이 가능하다고 가정하지 마세요. 원본의 인코딩이 잘못 알려진 경우에는 자동 감지 결과만 믿지 않고 사람이 의미를 확인합니다. 잘못된 디코딩 결과를 다시 저장한 파일은 단순히 인코딩을 바꾸는 것으로 복원되지 않을 수도 있습니다. 원본 백업이 중요한 이유입니다. 이미 덮어썼다면 추가 저장을 멈추고 사용할 수 있는 버전 관리와 백업을 확인하세요.
글꼴과 화면 폭 문제를 파일 내용과 분리하기#
한글이 네모로 보이거나 표의 줄이 어긋나는 문제는 파일 내용이 손상된 것과 다를 수 있습니다. 같은 텍스트를 다른 글꼴이나 다른 터미널에서 보는 비교를 계획할 수 있습니다. 확대 비율과 창 크기도 기록하세요. 표를 맞추려고 소스 문자열에 공백을 추가하면 다른 환경에서 더 어긋날 수 있습니다. 화면 표시 문제라면 원본 데이터는 그대로 두고 표시 환경을 먼저 조사하는 편이 안전합니다.
검증 기록에는 입력 전, 입력 확정 후와 파일을 다시 열었을 때를 구분합니다. 스크린샷만으로 저장된 바이트의 정확성을 알 수 없고 바이트 비교만으로 화면의 조합 상태를 알 수도 없습니다. 초성 목록, /language ko, @ 파일 선택과 CP949 전후 화면은 실제 세션에서 확인하세요. 별도의 Python 문자열 실험은 인코딩과 정규화 설명을 보완할 수 있지만 터미널 UI 동작의 증거는 아닙니다.
지원 요청에 필요한 최소 재현 정보#
재현 정보는 환경과 행동, 기대 결과와 실제 결과로 나눠 적습니다. 예를 들어 어떤 입력기에서 어느 창에 문장을 직접 입력했고 확정 후 어느 글자가 중복됐는지 적으면 됩니다. 원본 파일이 필요하다면 개인정보를 제거한 짧은 샘플로 대체할 수 있는지 확인하세요. 설정 전체와 환경 변수를 통째로 보내면 비밀값이 섞일 수 있습니다. 필요한 항목만 골라 공유하고 진단 명령의 출력도 검토합니다.
문제가 간헐적이면 재현하지 못한 조건도 남깁니다. 다른 터미널에서는 발생하지 않았다는 관찰과 모든 터미널에서 해결됐다는 주장은 다릅니다. 조치를 한 번에 여러 개 바꾸지 말고 한 조건씩 비교하면 원인을 설명하기 쉽습니다. 실제로 확인하지 못한 해결책은 제안으로 표시하세요. 이 글의 확인 절차 역시 환경별 성공 보증이 아니며 원본 보관, 권한 확인과 실제 화면 대조를 전제로 합니다.
추가 근거: Python 인코딩과 디코딩, 유니코드 정규화. 문자열 처리의 근거이며 특정 터미널이나 입력기 수정 결과를 뜻하지 않습니다.
직접 실행한 인코딩·정규화 비교#
2026-11-03에 Python 3.13.9에서 합성 문자열 한글 보고서를 CP949 바이트로 만들고 다시 읽었습니다. 같은 바이트를 UTF-8의 strict 방식으로 읽으면 UnicodeDecodeError가 나고 CP949로 읽으면 원래 문자열과 같다는 것을 assertion으로 확인했습니다. NFC 문자열을 NFD로 바꾼 뒤 다시 NFC로 정규화한 결과도 원문과 같았습니다. 이 실험은 새 로컬 파일과 문자열만 사용했으며 Mirr 입력창이나 운영체제 입력기를 조작하지 않았습니다.
text = "한글 보고서"
encoded = text.encode("cp949")
assert encoded.decode("cp949") == text
assert unicodedata.normalize("NFC", unicodedata.normalize("NFD", text)) == text
실제 출력은 encoding: cp949_roundtrip=True utf8_strict_rejected=True NFC_roundtrip=True (no terminal UI)였습니다. UTF-8 오류를 확인하는 코드에서는 예상한 UnicodeDecodeError만 잡고 그 오류가 없으면 검사를 실패시켰습니다. 잘못 읽은 글자를 화면에 만들어 정상·비정상 UI처럼 보여 주지는 않았습니다. 실행 기록에는 소스와 CP949 파일, 환경과 해시를 구분해 보관했습니다. 문자열 검사와 실제 터미널 화면을 혼동하지 않기 위한 구분입니다.
이 결과는 선택한 문자열의 인코딩과 정규화 관계만 보여 줍니다. CP949로 표현할 수 없는 다른 문자가 없다는 뜻도, 어떤 파일의 원래 인코딩을 자동으로 찾았다는 뜻도 아닙니다. 임의 파일에 같은 인코딩을 적용하면 잘못 읽을 수 있습니다. 자동 감지 결과가 있다면 원본의 의미와 함께 대조하고 변환은 별도 복사본에 해야 합니다. 원본 파일이나 이름을 실제로 변환한 작업은 이 검사에 포함되지 않습니다.
unicodedata.normalize는 NFC, NFKC, NFD, NFKD 네 형식을 받습니다(Python unicodedata 문서). 이 글의 검사는 NFC와 NFD만 비교했고, NFKC와 NFKD로 바꾼 결과는 아직 확인하지 않았습니다. 호환용 정규화가 필요한 파일명은 별도 검사로 추가하세요.
초성 검색, /language ko, @ 파일 선택과 IME 조합의 동작도 이 코드로 알 수 없습니다. 그 부분은 실제 Mirr 세션과 터미널 환경에서 확인하세요. CP949 전후 화면 역시 문자열 assertion으로 대체하지 않습니다. 환경마다 같은 현상이 생긴다고 일반화하거나 해결 시간을 제시하지 않는 이유입니다. 이 예제를 지원 요청에 활용한다면 문자열 처리 결과와 실제 화면 증상을 나눠 적으세요.
예를 들어 파일 바이트를 올바르게 읽을 수 있는데 화면에서만 폭이 어긋난다면 표시 환경을 더 조사할 수 있습니다. 반대로 다른 에디터에서도 같은 바이트가 잘못 읽히면 파일의 인코딩과 이전 저장 이력을 검토할 수 있습니다. 이들은 원인을 좁히는 가설이지 자동 진단 결과가 아닙니다. 한 번에 설정과 파일 내용을 모두 바꾸지 않고 비교 조건을 유지하면 어떤 조치가 영향을 주었는지 설명하기 쉽습니다. 실제로 확인하지 않은 조치는 계속 제안으로 남기세요.
설치된 Mirr에서 확인한 한글 파일 한 건#
2026-11-03의 별도 검증에서는 설치된 Mirr v0.6.15, macOS arm64의 빈 임시 프로젝트에서 한글 파일 이름과 본문을 확인했습니다. 실제 write_file은 한글-확인.txt에 38바이트를 썼고, read_file과 xxd 결과를 기록했습니다. 별도의 Node 프로세스가 같은 한글 파일명으로 실제 파일을 읽어 전체 바이트를 독립 기대값과 비교했습니다. 확인한 내용은 다음 한 줄과 마지막 LF입니다.
한글 파일 이름과 내용 확인
SHA-256은 f7948816552a632ec7074879a8356ff34efb38efb3c118e9a92d7cef1f585c09입니다. 이는 이 설치 환경에서 한 파일을 쓰고 다시 읽은 결과만 뒷받침합니다. 새 설치, GUI·IME 조합 입력, 초성 목록, @ 선택 화면과 CP949 화면은 아직 없습니다.
이 실행은 일반 auto 승인 모드였고 기존 규칙 승인과 자동 승인이 기록되어 있습니다. 사람이 승인 창을 보았거나 거부·복구를 검사했다는 뜻은 아닙니다. 앞선 더 큰 CSV 과제에서는 relay가 권한 부여를 거부했고(denied authorization) 실행 오류도 있었으며 정확한 원인은 확인되지 않았습니다. 이 실패는 이번 한 파일의 결과와 분리해 적습니다. 이번 한 파일의 성공으로 이전 실패가 해결됐다고 추정하지 않습니다. 모델 매핑·사용량·비용·성능과 다른 운영체제의 호환성도 이 자료로 판단하지 않습니다.
다음에 읽을 것#
입력 증상별 확인은 터미널과 한글 입력 문제, 명령 목록은 명령과 단축키를 참고하세요.
관련#
편집 메모 (2026-11-02): 명령·파일 검색과 언어·인코딩의 차이를 FAQ로 보충했습니다. 초성 목록, /language ko·@ 파일 선택 실행 화면과 CP949 전후 화면은 아직 없습니다.