← 목록
기타 2026-07-06 13KB 읽기 12분

브레인번역 — t1 최대 갭 배선 (코드북 4,167 ko↔en)

개요

브레인t1(하이쿠급 t1 규칙엔진, 토큰0) 시리즈에 6번째 모드 "번역"을 추가했다. 실어휘코드북v2_한글.psv(Concepticon 4,164개념, EN↔KO 대응)을 맵으로 적재해 결정론 단어급 en2ko/ko2en 치환 번역을 수행한다. 미등재 토큰은 창작하지 않고 [원문] 그대로 정직 보존.

무엇을 했는지

  1. 코드북 조사: /Users/ef/crowny-butler/libs/실어휘코드북v2.psv(4,167행)에는
한글 필드가 없음을 확인(col1=영문개념, col5=S순번, col7=온톨로지). 같은 디렉토리의 실어휘코드북v2_한글.psv(235KB, 4,164개념행+5주석행)에서 8번째 열(0-based idx7)에 한글글로스가 이미 존재함을 발견 — 이것을 ko↔en 매핑 소스로 채택. 포맷: 개념|A|P|O|S|의미장|온톨로지|한글글로스. 온톨로지 분포: Thing 2531·Action 850· Property 365·Number 163·Other 209·Classifier 46. 한글글로스 318건 중복(다대일) 확인.

  1. ~/.claude/scripts/브레인번역.한선 (신규, 완전 한선씨):
- 235KB 코드북은 읽기() 64KB캡·문자열 65535캡 둘 다 초과 → 근거DB통합.한선소스적재 패턴을 재사용: 버퍼파일읽기+버퍼바이트읽기 바이트스캔으로 줄 경계를 찾고, 완성된 한 줄만 버퍼잘라+버퍼문자열로 문자열화(짧아서 65535 캡 안전). - 단일 맵생성()"E:개념"→"한글|온톨로지", "K:한글"→"영문소문자|온톨로지" 이중 키로 적재(첫 등재 우선 — 맵있나 가드로 중복 시 later-row가 덮어쓰지 않음). - 온톨로지 어순 규칙 1개: en2ko는 인접 (Action,Thing) 매치쌍 → (Thing,Action)로 스왑(한국어 SOV), ko2en은 반대로 (Thing,Action)→(Action,Thing) 스왑(영어 SVO). 두 토큰이 모두 코드북 매치된 경우에만 적용(미매치=어순 추정 금지, 정직). - 끝 구두점(.,!?;:) 분리 후 재부착 — "dig. plum," → 스왑+구두점 유지 확인. - 방향 자동감지 안전망: 방향 인자가 en2ko/ko2en이 아니면 본문 첫 글자 ASCII 여부로 판정. - VM 함정 실측 발견·수정: 시작하는가()는 0/1이 아니라 참=1/거짓=-1(3값논리) 반환 — == 0으로 비교하면 항상 거짓이 되어 코드북 적재행이 0으로 죽는 버그를 실측→ != 1로 수정(가드레일에 없던 신규 함정, 향후 동일 라이브러리 사용 시 참고).

  1. ~/.claude/scripts/브레인t1.sh: 기존 5모드(요약/정리/변환/문서/검증) 무손상,
번역 <en2ko|ko2en|자동> <파일|-> 6번째 모드 추가(백업: 브레인t1.sh.bak_20260706200801). 변환/문서 모드와 동일한 정화(개행→¶, 20000자 절단, | 보존) + .toau 핀 캐시 패턴 재사용.

  1. ~/.claude/scripts/작업구분.sh: t1 분기에 "번역" 키워드 선시도 블록 추가
(변환/문서/검증 블록과 같은 위치). 명령부에 en2ko/ko2en/영한/한영 명시가 없으면 본문 첫 글자 ASCII 여부로 방향 자동감지 후 브레인t1.sh 번역로 위임, 실패 시 기존 haiku 티켓 폴백 유지.

검증 결과

  • 컴파일 rc=0 (hanseonc_high → 4915 큐브).
  • 표본 en2ko 5단어 실존개념(plum shrub almond yam gourd) → 매핑5/5,
"자두 관목 아몬드 마 박".
  • 온톨로지 어순 규칙 왕복 검증: eat fish → en2ko → "물고기 먹다"(스왑 적용) →
ko2en → "eat fish"(역스왑, 원형 복원) — 양방향 모두 매핑2/2 정확.
  • catch fish → "물고기 잡다"도 동일 규칙 확인.
  • 미등재 혼합 문장(plum xyzfoo shrub) → "자두 [xyzfoo] 관목" — 정직 [원문] 유지 확인.
  • 구두점 처리(dig. plum,) → "자두, 파다." — 스왑+구두점 재부착 정상.
  • 멀티라인(¶ 구분) 본문 3줄 처리 — 줄별 독립 번역 확인.
  • 브레인t1.sh 번역 en2ko - / ko2en - / 자동 - 스모크 3건 전부 정상.
  • 작업구분.sh "번역: eat fish and plum shrub" → t1 판정 → 번역-en2ko 자동선택 →
"물고기 먹다 그리고 자두 관목"(매핑5/5, "and"→"그리고"도 코드북 기능어로 정확 매치). ko2en 방향도 역순 정상.
  • 기존 5모드 회귀: 정리(4항목→3/4 중복제거+정렬+번호) / 요약 둘 다 정상 동작 확인
(브레인t1.sh 편집 후 무손상).
  • ~/.claude/scripts/crownycode-learn.sh add "브레인번역_코드북_t1" "..." 학습 완료
(별칭 "브레인번역" 자동 등록).
  • RPN 동반 파일 브레인번역.rpn.한선 생성(tools/high2rpn.sh, 500줄, 문서 성격 —
실제 실행경로는 기존 5모드와 동일하게 고수준 .한선이 담당, RPN은 동반 자산).

관련 파일

  • /Users/ef/.claude/scripts/브레인번역.한선 (신규 코어)
  • /Users/ef/.claude/scripts/브레인번역.rpn.한선 (신규 RPN 동반)
  • /Users/ef/.claude/scripts/브레인t1.sh (수정, 백업 .bak_20260706200801 존재)
  • /Users/ef/.claude/scripts/작업구분.sh (수정, "번역" 선시도 블록 추가)
  • /Users/ef/crowny-butler/libs/실어휘코드북v2_한글.psv (기존 자산, 매핑 소스로 채택)

잔여 이슈 (정직 — 한글 매핑 소스 및 방향 커버리지)

  • 한글 매핑 소스는 v2_한글.psv col7(8번째 열) 단일 소스 — 별도 "ko↔en 전용 사전"
자산은 crowny-butler 내에서 발견되지 않음(다국어의미어.한선은 3언어 81개 데모 수준, 실사용 규모 아님). v2_한글.psv 자체가 "실어휘코드북v2 + 한글글로스 부착본"이라 양방향(en2ko/ko2en) 완전 지원 — 단방향이 아님.
  • 한글글로스 자동생성 품질 편차: 표본 확인 중 HOUSE·WOOD·FIRE·WATER 등 일부
행은 한글글로스가 영문 그대로 남아있음(생성 누락으로 추정) — 이런 행은 en2ko/ko2en 둘 다 사실상 "영→영"이 되어 매핑률에는 잡히지만 번역 효과는 없음. 코드북 자체의 데이터 품질 이슈이며 본 도구의 로직 결함은 아님(정직 표기).
  • 다대일 한글글로스 318건: ko2en에서 동일 한글 단어가 여러 EN개념에 대응하는 경우
파일 내 첫 등장 행이 결정론적으로 선택됨(재현 가능, but 의미상 최선의 en 선택은 아닐 수 있음).
  • 단어급 한정: 다단어 개념(BEER BANANA, PLANT (SOMETHING) 등)은 정확히 그
다단어 문자열이 입력에 나타나야 매치 — 단일 토큰 n-gram 결합 매칭은 미구현(t1 정직 범위 밖의 과욕으로 판단해 보류).
  • 한국어 조사 미분리: ko2en에서 "쌀을"처럼 조사가 붙은 형태는 코드북의 "쌀"과
정확매치 실패 → 정직하게 [쌀을]로 남음. 형태소 분석은 t1 규칙엔진 범위 밖.
  • 재적재 비용: 호출마다 4,164행 전체를 다시 스캔·맵적재(캐시 없음) — 지연은
체감상 수용 가능한 수준(수초 이내)이나, 고빈도 호출 시 프로세스 상주형 캐시로 개선 여지 있음(후속 과제로 남김, 현재 범위 밖). → 아래 v2에서 해결.
  • 한국어 조사 미분리 항목도 → 아래 v2에서 해결.

고도화 v2 (2026-07-06 — 디스크 캐시 + 조사 분리)

위 "잔여 이슈" 2건(재적재 비용·조사 미분리)을 해결. 백업: 브레인번역.한선.bak-20260706214740 (v1 원본 보존).

1) 디스크 캐시 (방향별 단순 key\|value\|온톨 psv)

  • 신규 캐시 파일: ~/.crownycode/번역캐시_en2ko.psv(4,164행) / _ko2en.psv(3,637행,
한글글로스 중복 제거 후 유니크 수).
  • 신선도 판정: 체계()로 bash [ -f 캐시 ] && [ ! 원본 -nt 캐시 ] 위임(에포크 수동산술
금지 함정 회피). 원본 psv가 캐시보다 새로우면(또는 캐시 부재) STALE→재구축, 아니면 FRESH→해당 방향 캐시 1개만 적재(구버전은 방향 무관 항상 원본 4,164행 전체를 8열 파싱+대소문자 변환+이중키 조립까지 해서 병합 맵 하나를 매번 새로 만들었음 — 이제는 필요한 방향의 사전 계산된 캐시만 읽는다).
  • 실측(같은 문장 "물고기를 먹다" ko2en, 2회 호출):
  • v1(캐시 없음, 매 호출 원본 4,164행 전체파싱): CPU(user+sys) ≈ 2.1~2.6s/회,
  • 반복해도 매번 동일 비용(무캐시).
  • v2 최초 호출(STALE→재구축+캐시기록): CPU ≈ 3.0s(원본 파싱 + 캐시 2파일 기록
  • 7,801줄 write/append 오버헤드 포함, 1회성).
  • v2 이후 호출(FRESH→캐시적재): CPU ≈ 0.47~0.48s/회, 반복 2회 모두 동일하게 빠름 —
  • v1 대비 약 4~5배, 최초 재구축 대비 약 6배 단축.
    • 실측 중 치명 함정 발견+즉시수정(가드레일行): 캐시 라인을 배열(캐시엔줄들)에
    모았다가 합치기()로 통짜 문자열을 만들어 한번에 쓰기()하는 최초 구현은 두 겹의 조용한 절단을 만났다 — ①배열 4095캡: en2ko 4,164개 고유키가 캡을 넘어 마지막 69개가 추가()에서 조용히 버려짐([ARRAY] 배열 캡 도달(4095) 경고 로그로 실측 확인, 캐시 파일이 en2ko=4095/ko2en=3637로 절단) ②문자열 65535B 캡: 절단된 배열조차 합쳐진 문자열이 정확히 65535바이트로 다시 잘려 기록됨(두 캐시 파일이 정확히 65535B로 동일 크기였던 것이 단서). 수정: 배열/통짜문자열을 전혀 쓰지 않고, 코드북을 줄 단위로 스캔하는 도중 신규 키를 발견하는 즉시 쓰기()(최초 1회) /덧쓰기()(이후)로 스트리밍 기록하도록 재구성 — 이제 en2ko=4164/ko2en=3637 전량 보존 확인(마지막 원본 행 BE AT WAR 개념도 캐시에 정확히 존재 검증).

    2) ko2en 조사 분리

    • 매칭 순서: 코어 토큰이 대표 조사(에서/으로/을/를/이/가/은/는/의/에/로/와/과/도/만,
    2글자 조사 우선 검사) 중 하나로 끝나면 그 조사를 뗀 어근으로 먼저 매칭 시도 → 성공하면 조사 드랍(영문은 조사 대응 불필요, 결과어만 사용) → 실패하면(또는 어근이 0글자가 되는 경우, 즉 토큰길이<=조사길이면 애초에 스트립 시도 안 함) 조사 안 뗀 원코어로 재시도 → 그래도 미스면 [원문].
    • 케이스 실측:
    | 입력 | v1(조사분리 전) | v2(조사분리 후) | |---|---|---| | "물고기를 먹다" | 매핑1/2[물고기를] eat | 매핑2/2eat fish | | "자두의 관목" | 매핑1/2[자두의] shrub | 매핑2/2plum shrub | | "자두 관목"(조사無, 대조군) | 매핑2/2plum shrub | 매핑2/2plum shrub(동일, 무손상) |

    • 왕복 회귀: eat fish(en2ko) → 물고기 먹다(매핑2/2, SOV 스왑 정상) →
    물고기 먹다(ko2en, 조사無) → eat fish(매핑2/2) — v1과 동일하게 정상 유지.
    • 미등재 유지 확인: "자두를 asdfqwerty로 던지다"(ko2en) → 매핑2/3,
    plum [asdfqwerty로] cast — 코드북에 없는 어근은 조사 스트립 실패 후 원토큰 그대로 대괄호 보존(창작 없음, 정직 유지).
    • 브레인t1.sh 6모드 전체 스모크: 요약/정리/변환(psv2md)/문서/검증/번역(ko2en·
    en2ko 모두) 전부 래퍼 경유로 정상 출력, 크래시 없음(번역 모드 외 5모드는 이번 변경과 무관 — 무손상 확인용).
    • 캐시 무효화 회귀: 원본 psv touch 후 재호출 → STALE 정확히 재감지→재구축
    (en2ko=4164/ko2en=3637 재기록) → 다음 호출 다시 FRESH 복귀 확인.

    크라우니코드 학습

    crownycode-learn.sh add "브레인번역_디스크캐시_조사분리_v2" 로 이번 두 고도화 패턴(bash test -nt 신선도판정 + 스트리밍 write/append 캡회피 + 조사 스트립 매칭 순서)을 학습DB에 등록.

    관련 파일 (v2 추가/변경)

    • /Users/ef/.claude/scripts/브레인번역.한선 (수정 — 캐시+조사분리, 배열/문자열
    캡 회피 스트리밍 write로 재작성)
    • /Users/ef/.claude/scripts/브레인번역.한선.bak-20260706214740 (v1 백업)
    • ~/.crownycode/번역캐시_en2ko.psv, ~/.crownycode/번역캐시_ko2en.psv (신규 캐시,
    런타임 생성물 — 원본 psv 변경 시 자동 재생성)
    • /Users/ef/.claude/scripts/브레인t1.sh (무변경, 6모드 스모크로 무손상만 확인)

    잔여 이슈 (v2 기준 정직 갱신)

    • 조사 목록은 대표 15종 한정(복합조사 "에서만"·"으로는" 등 조합형은 범위 밖) —
    단일 조사 스트립 1회만 시도, 중첩 스트립(2단 조사) 미구현.
    • 캐시는 이 macOS 호스트의 로컬 파일 기준 mtime만 본다 — 여러 세션이 동시에
    원본 psv를 편집+저장하며 경합하면(드묾) 마지막 쓰기 시각 기준으로만 판단, 파일 내용 해시 비교는 하지 않음(비용 대비 불필요 판단).
    • 어미(용언 활용, "먹다"류)는 범위 밖 유지(과제 지시대로 조사만 처리) — "물고기를
    먹었다"처럼 활용형이 붙으면 "먹다" 코어 매칭 실패 그대로("[먹었다]" 등 정직 표기).