한글 글자수 세기 스킬

[vkehfdl1]

자기소개서 작성 등에 중요한 글자 수 세기
한국어 글자 수를 '정확하게' 셀 수 있는 스킬 제작
LLM이 임의대로 글자 수를 "예측" 하는 것은 통하지 않음.
글자의 줄 수 및 byte 수 측정도 포함.

[vkehfdl1]

• AI-understood issue summary

  • 이 이슈는 자기소개서/지원서처럼 글자 수 제한이 중요한 한국어 텍스트를 대상으로, LLM 추정이 아니라 결정론적으로 글자 수를 계산하는 스킬을 만들자는 요청으로 이해했습니다.
  • 결과에는 최소한 글자 수, 줄 수, byte 수가 포함되어야 하며, 어떤 규칙으로 셌는지(예: 줄바꿈/공백/UTF-8 기준 byte)도 명확해야 합니다.

• Why this issue is needed

  • 자기소개서 입력폼은 1~2자 차이도 제출 실패나 내용 잘림으로 이어질 수 있어서 “대충 맞는” 카운트가 통하지 않습니다.
  • 한국어 텍스트는 줄바꿈, 공백, 이모지, 조합 문자, 멀티바이트 인코딩 때문에 단순 length나 LLM 추정으로는 실제 사용 기대치와 어긋날 수 있습니다.
  • 재현 가능한 카운트 규칙을 스킬로 제공하면, 사용자가 같은 입력에 대해 항상 같은 결과를 받을 수 있습니다.

• Why this issue may not be needed

  • 만약 사용자가 원하는 것이 단순 카운트뿐이라면, 별도 스킬 없이 기존 CLI/웹 카운터를 문서화하는 정도로도 충분할 수 있습니다.
  • 또한 “정확한 글자 수”는 서비스마다 정의가 다를 수 있어서, 요구사항이 불명확하면 스킬을 만들어도 실제 제출처 기준과 다를 수 있습니다.
  • 즉, 구현 자체보다도 카운트 기준을 먼저 고정하지 않으면 유지비만 늘 수 있습니다.

• Expected Outcome

  • 텍스트 입력 시 다음을 일관되게 반환하는 스킬:
    • 글자 수
    • 줄 수
    • byte 수
  • byte 수는 UTF-8 기준으로 고정.
  • 줄 수는 빈 문자열, 마지막 개행 포함 여부, CRLF/LF 처리 규칙이 문서화됨.
  • 글자 수는 최소한 테스트 가능한 하나의 기준으로 고정되고, 필요하면 보조 메트릭(예: 코드포인트 기준 vs 사용자 체감 문자 기준)을 추가로 제공.
  • 한국어/영문/숫자/공백/개행/이모지 혼합 입력에 대한 fixture 테스트가 포함됨.

• Concise implementation plan

  1. 먼저 “글자 수/줄 수/byte 수”의 정확한 계산 규약을 문서로 확정합니다.
  2. 카운트 엔진을 순수 함수로 구현하고, byte 수는 Buffer.byteLength(text, 'utf8')처럼 결정론적 방식으로 계산합니다.
  3. 줄 수는 빈 문자열, 마지막 개행, CRLF 정규화 케이스를 포함해 고정된 규칙으로 계산합니다.
  4. 글자 수는 한국어 텍스트에서 오해가 적은 기준을 선택하고, 애매하면 메인 카운트 + 보조 카운트를 함께 노출합니다.
  5. 스킬 입출력 인터페이스를 붙이고, 실제 자기소개서형 예문을 포함한 회귀 테스트를 추가합니다.

• Agent Signature

[vkehfdl1]

굳이 패키지나 스킬을 만들 필요가 있을까? 클로드 정도면 ㅈㄴ 코드 써서 잘 해주지 않을까 하는 비판적 사고를 해봤어

[vkehfdl1]

좋은 비판이라고 생각합니다. 결론부터 말하면 “클로드가 그때그때 코드 써서 계산해주는 것”은 가능하지만, 그걸로 이 이슈가 완전히 대체되지는 않는다 쪽에 가깝습니다.

핵심은 계산 능력보다 계산 계약(contract)의 고정입니다.

• 클로드/LLM도 실제로는 코드를 써서 byte, line, char를 계산하게 만들 수 있습니다.
• 그런데 문제는 매번 프롬프트와 구현이 조금씩 달라지면
  • 줄 수를 어떻게 셀지
  • 마지막 개행을 어떻게 처리할지
  • CRLF를 어떻게 볼지
  • 글자 수를 UTF-16 length / code point / grapheme 중 무엇으로 셀지
    같은 규칙이 흔들릴 수 있다는 점입니다.
• 자기소개서처럼 1자 차이도 민감한 작업에서는 “이번엔 이렇게 셌고 다음엔 저렇게 샜다”가 제일 위험합니다.

그래서 이 이슈의 필요성은 LLM보다 더 똑똑한 카운터를 만들기 위해서가 아니라,
LLM이 매번 새로 추론하지 않아도 되는 고정 규칙 + 테스트된 실행 경로를 제공하기 위해서라고 보는 게 맞습니다.

다만 반대 논리도 충분히 유효합니다.

• 사용 빈도가 낮고
• 입력 텍스트를 한 번씩만 계산하면 되고
• 사용자가 직접 “이 규칙으로 세라”라고 매번 명시할 수 있다면

굳이 별도 패키지/스킬까지 만들지 않고 짧은 스크립트 템플릿이나 문서화된 one-shot prompt만으로도 충분할 수 있습니다.

그래서 현실적인 타협안은 아래 둘 중 하나라고 봅니다.

1. 경량화된 스킬/유틸로 만든다

   • 내부는 그냥 결정론적 코드 몇 줄이어도 됨
   • 대신 규칙/테스트/출력 형식을 고정
   • 반복 사용성과 재현성을 확보

2. 스킬 대신 레퍼런스 구현 + 테스트 문서만 둔다

   • “이 코드를 항상 써라”는 표준 스니펫 제공
   • 사실상 패키지화는 하지 않되, 계산 규약은 고정

제 의견은, 이 이슈는 **“거대한 패키지를 만들자”가 아니라 “카운트 규칙을 표준화하자”**로 좁히면 살아남을 가치가 있습니다.
즉, 구현 형태는 스킬/패키지/스니펫 중 무엇이든 될 수 있지만, 규칙 고정 + 테스트 보장은 꼭 필요합니다.

[vkehfdl1]

그러면
한국어 환경에서 글자 수와 byte 수를 완벽하게 세기 위한 계산 계약을 검색해서 확정해봐

[vkehfdl1]

검색해본 뒤 결론을 정리하면, “한국어 환경 전체에 통용되는 단 하나의 완벽한 글자수/byte 수 계약”은 찾지 못했습니다.
대신 국제 표준(Unicode/WHATWG) + 한국 도메인별 관행(예: NEIS) 이 공존하고 있어서, 이 이슈에서 확정해야 할 것은 보편 계약 1개 + 호환 프로필 몇 개라고 보는 게 맞습니다.

제가 확인한 근거는 대략 이렇습니다.

• 글자 수(사용자 체감 문자)

  • Unicode UAX #29는 “character counting”에 grapheme cluster 경계를 쓰는 기준을 제공합니다.
  • TC39 Intl.Segmenter 설명도 grapheme이 “accent marks, conjoining Korean characters”를 포함할 수 있다고 적고 있습니다.
  • 따라서 한국어에서 “글자 수”의 기본 계약은 UTF-16 length가 아니라 extended grapheme cluster count로 잡는 게 가장 방어적입니다.

• byte 수

  • WHATWG Encoding Standard는 현대 웹 인코딩 기준으로 UTF-8과 EUC-KR(Windows-949 계열) 을 모두 정의합니다.
  • Node 공식 문서도 Buffer.byteLength(str, 'utf8')처럼 인코딩을 명시한 byte 계산을 표준적인 방식으로 제시합니다.
  • 즉 byte 수는 “문자 종류별 암산”이 아니라 선택한 인코딩으로 실제 인코딩했을 때의 바이트 길이로 정의하는 게 맞습니다.

• 한국 도메인별 예외

  • 경기도교육청 공개 PDF의 2023 학교생활기록부 기재요령에는 “입력 글자의 단위는 Byte이며, 한글 1자는 3Byte, 영문·숫자 1자는 1Byte, 엔터는 2Byte” 라고 명시되어 있습니다.
  • 즉 한국 실무에서도 도메인별 계약이 따로 존재합니다. 이 사실 자체가 “한국어는 무조건 2byte/3byte” 같은 단일 규칙이 없다는 증거에 가깝습니다.

그래서 이 이슈에서 제가 제안하는 확정 계약은 아래입니다.

권장 기본 계약(Default Contract)

1. 입력은 원문 그대로 센다.

   • 사용자가 넣은 텍스트를 임의로 trim/정규화/치환하지 않는다.
   • 공백, 개행, 이모지, 조합 문자를 그대로 유지한다.

2. 글자 수 = Unicode extended grapheme cluster 개수

   • 구현 기준: UAX Clawhub support #29 계열
   • JS 런타임에서는 Intl.Segmenter(..., { granularity: 'grapheme' }) 기반이 가장 적합
   • 이유: 한글 자모 조합, 이모지 ZWJ, 결합 문자까지 “사용자 체감 1글자”에 가장 가깝다.

3. byte 수 = 선택 인코딩으로 실제 인코딩한 결과의 byte length

   • 기본 인코딩은 UTF-8
   • 구현 기준: 예를 들어 Node에서는 Buffer.byteLength(text, 'utf8')
   • 이유: 현대 웹/CLI/파일 교환의 기본값과 가장 잘 맞는다.

4. 줄 수 = 줄바꿈 시퀀스 기준

   • CRLF, LF, CR는 각각 1개의 줄바꿈으로 취급
   • 가능하면 U+2028, U+2029도 줄 구분자로 인정
   • 빈 문자열은 0줄, 비어 있지 않으면 줄바꿈 개수 + 1
   • CRLF는 2개가 아니라 1개로 센다.

호환 프로필(Compatibility Profiles)

• NEIS 프로필

  • 한글 3B / 영문·숫자 1B / Enter 2B
  • 공식 문서가 있는 특정 도메인 대응용

• Legacy EUC-KR/CP949 프로필

  • 일부 구형 채용/레거시 폼의 “한글 2byte” 관행 대응용
  • 단, 이건 기본값으로 두면 안 되고, 대상 시스템이 그렇게 명시할 때만 선택해야 합니다.
  • 이유: 현대 Unicode 문자열 전체를 일반화해서 설명하기에 너무 좁고, 비한글/이모지/확장문자에서 깨질 수 있습니다.

정리하면, “완벽하게 센다”는 건 한국어 전체에 대한 보편 진리가 아니라, 목표 시스템의 계약을 정확히 재현한다는 뜻입니다.
따라서 이 스킬이 정말 가치 있으려면:

• 기본값은 Grapheme + UTF-8 + 명시적 line rule
• 필요 시 NEIS / Legacy CP949 같은 프로필 제공
• 결과 출력 시 무슨 계약으로 셌는지 함께 표시

이 3가지를 갖추는 게 가장 설득력 있습니다.

참고한 근거:

• Unicode UAX Clawhub support #29: https://www.unicode.org/reports/tr29/
• Unicode UAX 다이소 상품 조회 스킬 #15: https://www.unicode.org/reports/tr15/
• WHATWG Encoding Standard: https://encoding.spec.whatwg.org/
• Node Buffer.byteLength: https://nodejs.org/api/buffer.html
• 2023 학교생활기록부 기재요령(경기도교육청 PDF): https://www.goe.go.kr/resource/old/BBSMSTR_000000030136/BBS_202302211104253520.pdf

[vkehfdl1]

/approve

[vkehfdl1]

close at #87