TechToast

위키가 영어로 쓰여 있었다 — 4,382개 중 482개

TechToast — Sun, 2 Aug 2026 09:44:07 +0900

1부의 마지막 편이다. 앞 세 편에서 세컨드브레인을 LLM-Wiki 패턴으로 시작하고, 문서 2만 개를 만나 벡터 검색 계층을 얹고, 온갖 파일 포맷에서 텍스트를 꺼내는 이야기를 썼다.

이 편은, 그렇게 만든 위키를 열어봤을 때 생긴 일이다. 2주쯤 지나 브라우징 화면을 붙였고, 페이지를 넘겨보다가 이상한 걸 발견했다. 일부 페이지가 영어로 쓰여 있었다.

내 자료는 거의 전부 한국어인데, 합성된 페이지가 영어라니, 아무도 부탁하지 않은 번역이다. 왜 그랬는지부터 보자.

원인은 금방 찾았는데, 프롬프트를 열어보니 ingest 시 LLM 에 주는 시스템 프롬프트에 한국어로 작성 지시가 이미 있었다. 지금 규칙은 맞고, 영어 페이지는 초기 버전의 잔재다. 처음엔 프롬프트가 영어였고, 모델이 영어로 답했는데, 나중에 한국어 지시로 고쳤지만 이미 만들어진 페이지에는 아무 일도 일어나지 않았다.

두 번의 청소

먼저 영어 페이지를 찾아야 했는데, 판정 기준은 단순하게 잡았다. 본문에서 한글이 차지하는 비율이 0.10 미만이면 영어 페이지다. 한국어 문서는 영어 용어가 섞여도 0.10 은 넘고, 영어 페이지는 고유명사 말고는 한글이 없어서, 임계값 하나로 갈렸다.

이 기준으로 센 결과, 4,382개 중 482개가 영어였다.

처리 방식은 재합성이었다. 옛 페이지를 지우고, 매니페스트에서 해시를 제거해서 안 한 것으로 되돌리고, 다시 ingest 를 돌리면 지금의 한국어 프롬프트로 새로 합성된다. 문서당 70초, 482개면 8~10시간이다.

스크립트에 두 가지를 넣었다. 터미널을 닫아도 계속 도는 detached 실행, 중단되면 남은 것부터 이어가는 재개 로직. 둘째는 선택이 아니라 필수인데, 8시간 배치는 반드시 끊기고, 재개가 없으면 처음부터라서 영원히 안 끝난다.

돌렸다. 로그가 남았다. 몇 개가 처리됐는지 적어둔 곳은 없다.

이틀 뒤 다시 셌더니, 숫자가 안 맞았다.

매니페스트 기준 처리 대상    4,382개
실제 디스크의 위키 .md      6,809개
────────────────────────────────
1차가 아예 보지 않은 페이지  2,427개
여전히 영어인 페이지          233개

재합성 대상 목록과 실제 산출물이 일치하지 않았다. 1차 스크립트는 매니페스트를 순회했는데, 매니페스트는 처리 기록이라 처리된 것만 알고, 디스크에는 연결되지 않은 페이지가 2,400개 넘게 있었다. 확실한 건, 매니페스트를 순회하면 위키 전체를 순회하지 않는다는 것.

그래서 2차는 접근을 바꿔, 파일시스템을 직접 순회했다. 모든 .md 를 열어 한글 비율을 재고 0.10 미만이면 처리한다. 매니페스트는 안 본다.

그리고 재합성 대신 제자리 번역을 골랐다. 영어 페이지 본문을 번역해서 덮어쓰는 방식인데, 이유는 두 개다. 재합성은 문서당 70초고 번역은 그보다 싸서, 예상 2~3시간이었다. 그리고 재합성하면 내용이 또 달라지는데, 이미 링크가 걸려 있고 손으로 고친 것도 있어서 그걸 전부 날릴 수 없었다.

번역이라서 지켜야 할 게 늘었다. 프론트매터와 위키링크와 약어는 건드리면 안 되는데, 링크를 번역하면 그래프가 끊기고 약어를 풀면 검색이 안 걸린다. 그래서 프롬프트로 그 셋을 보존하게 묶고, 한자 가드를 얹었다. 로컬 모델이 한국어를 만들면서 한자와 CJK 문자를 섞는 경우가 있었는데, 한자가 들어오면 그 페이지는 실패로 처리하게 했다.

곁가지 — 목차도 같이 무너져 있었다

같은 시기, 위키 색인 페이지도 이상했다. index.md 에 항목이 9,532개, 죽은 링크가 422개 이상이었다. 한 페이지에 9,500개가 나열돼 있으면, 그건 목차가 아니다.

태그와 제목 키워드로 상위 카테고리 10개에 분류하는 색인 재생성 스크립트를 새벽마다 돌렸다. 그 분포에서 두 가지가 보였는데, 의료영상·AI연구 1,553개가 제일 큰 건 예상대로였고, 기타가 1,150개였다. 자동 분류의 정직한 성적표다. 그리고 행정 937 + 과제 581 = 1,518개, 위키 5분의 1이 공문과 과제 서류였다. 색인에 뭐가 들어 있는지가 검색 품질을 정한다는 걸, 이때는 아직 몰랐다.

한 달 뒤 — 오염원을 끄는 게 나았다

이 이야기의 중간 결말은, 청소가 성공했다는 게 아니다. 한 달 뒤 재설계할 때 위키를 다시 봤더니, 다국어 오염이 여전했다. 영어만이 아니었다. 러시아어 조각(отсут), 일본어 조각(挙げ), 그리고 파 mesenchymal 처럼 한 단어 안에서 언어가 섞인 것들까지 있었다.

오염원을 찾았더니, 매시간 도는 재합성 크론이었다. 소스가 조금이라도 바뀌면 LLM 이 페이지를 다시 쓰는데, 그때마다 오염이 새로 생길 확률이 있었다. 청소한 만큼 다시 오염되고 있었다.

그래서 결정을 바꿔, 위키를 청소하는 대신 동결했다. 매시간 재합성 크론과 매일 다이제스트 합성을 꺼, 위키를 읽기전용 유물로 남겼다. 근거는 앞 편에서 확인한 사실이었다 — 검색 백본은 위키가 아니라 원본 소스 임베딩이고, 위키는 소스의 파생물이다. 계속 오염되는 파이프라인에서는, 청소가 아니라 정지가 답일 수 있다. 청소 스크립트를 두 번 만들고 나서야 그 판단을 했다.

그래서 끝났나 — 세어봤다

이 글을 '그래서 다 고쳤다'로 마무리하려다 멈췄다. 확인하려고 당시 기록을 다시 열었는데, 완료 기록이 없다. 실행 방법, 예상 소요, 재개 방법은 적어뒀고, 몇 개가 처리되고 몇 개가 남았는지는 어디에도 없다. 배치를 걸고 그걸로 끝냈던 것이다.

그래서 지금, 동결된 위키 아카이브를 같은 판정법으로 전수 조사했다.

위키 페이지          7,008개
영어 판정             72개  (1.0%)
  ├ 제목까지 영어     28개
  └ 제목은 한국어     44개
전원 파일 수정시각    2026-06

6월에 233개였던 것이 72개다. 72개 전원의 수정시각이 6월이라는 게, 동결이 유효했다는 증거다. 위키는 정말 안 움직이고 있다.

그런데 이 72개를 열어보고 알았다 — 남은 것들은 고칠 대상이 아니었다.

제목까지 영어인 28개는, Morphology-guided attention networks for explainable... 처럼 원문이 영어인 논문 전문이었다. 제일 큰 건 62,499자, 파일명이 arXiv id 인 페이지도 12,929자였다. 내 논문 전문을 소화시키는 파이프라인이 따로 넣은 것이다. 이걸 한국어로 번역하는 건 개선이 아니라 훼손이다 — 원문을 그대로 인용할 수 없게 된다.

제목이 한국어인 44개는 더 흥미롭다. 어떤 학사 안내 문서의 한글 비율이 0.099 였는데, 임계값이 0.10 이니 0.001 차이로 영어 페이지가 됐다. 본문에 학번과 코드와 표가 빼곡해서, 숫자와 기호가 한글을 밀어낸 것이다. 멀쩡한 한국어 문서다.

정리하면 문제였던 페이지는 사실상 정리됐고, 남은 72개는 정상 문서 44개와 번역하면 안 되는 영어 원문 28개다. 다만 이건 완료 보고가 아니라, 두 달 뒤에 뒤늦게 센 숫자다.

교훈 세 개

하나는, 규칙을 고쳤다는 것과 데이터가 규칙을 따르게 됐다는 것이 다른 문장이라는 것. 프롬프트를 한국어로 고친 시점에 나는 해결했다고 생각했는데, 코드는 옳았고 그 뒤 페이지들은 전부 한국어였다. 시스템의 상태는 코드가 아니라 축적된 데이터라, 규칙 변경은 그 시점 이후에만 적용되고 이미 쌓인 것에는 아무 일도 하지 않는다. 규칙을 바꿀 때는 새 규칙, 쌓인 데이터를 맞추는 일회성 소급 작업, 끝났는지 확인하는 검증 쿼리가 세트로 필요하다. 검증이 없으면 1차에서 멈춘다.

둘은, 소급 대상 목록을 어디서 뽑는지가 소급의 정확도를 정한다는 것. 나는 매니페스트에서 뽑았는데, 처리 기록이라 처리된 것만 안다. 실제로 존재하는 것을 알려면 파일시스템을 봐야 했다. 기록과 실물이 어긋나 있을 가능성을 아예 고려하지 않은 게 실수였고, 그 어긋남을 1차가 끝난 다음에야 발견한 게 더 큰 실수였다. 검증 쿼리가 있었으면, 1차와 2차 사이에 이틀이 안 걸렸을 것이다.

셋은, 완료를 판정하던 지표가 그 자체로 오탐을 냈다는 것. 한글 비율 0.10 은 영어 페이지를 찾는 데는 잘 작동했고, 482개를 찾아냈는데 대부분 진짜였다. 문제는 같은 지표를 작업이 끝났는지 확인하는 데 쓸 때 생기는데, 원문이 영어인 논문 전문은 영원히 걸리고 표와 코드가 많은 한국어 문서는 0.099 로 걸린다 — 고쳐도 안 사라지는 것과, 문제가 아닌데 걸리는 것.

점검 지표가 오탐을 내면 그 지표로는 완료를 선언할 수 없다. 그리고 완료를 선언할 수 없으면 사람은 확인을 그만둔다.

그러니까 이 지표로는 0을 목표로 삼을 수 없다. 그런데 나는 영어 페이지가 없어지면 끝이라고 생각했는데, 목표가 도달 불가능한 형태였고 그래서 완료 판정을 아예 안 하게 됐다. 배치를 걸고 잊은 이유가 게으름만은 아니었다는 얘기다.

지표를 고쳤어야 했다. 논문 전문 디렉터리를 판정에서 제외하고, 한글 비율 대신 영문 문장 비율을 보고, 임계값 근처인 0.08~0.12 는 사람 검토 큐로 보내는 식이다. 그러면 0이면 끝이 성립한다.

이게 이 시리즈가 계속 부딪히는 문제의 1부 버전이다. 5부에서 같은 모양을 훨씬 큰 규모로 다시 만난다 — 적어둔 것과 실제가 어긋나 있는데, 그걸 확인하는 장치가 그 자체로 고장나 있다.

이걸로 1부를 마친다. 여기까지가 2026년 6월 초순, 시스템을 만든 첫 3주다. 2부에서는 자료가 끊기지 않고 흘러들게 만드는 이야기를 한다. 회의록 자동 녹음과 전사, 그룹웨어 스크래핑, 논문 리캡 — 자동화 8개를 붙였고, 그중 몇 개는 아주 이상한 방식으로 실패했다. 그 이야기는 2부에서 해 보자.

20k 문서를 실제로 읽어들이기 — 로더 지옥

TechToast — Sun, 2 Aug 2026 08:51:48 +0900

앞 편에서 문서 2만 개를 만나 설계를 고친 이야기를 썼다. 벡터 검색 계층을 얹고, 청크로 쪼개서 임베딩하면 된다고 적었는데, 그 문장에는 앞 단계가 하나 빠져 있다.

파일에서 텍스트를 꺼내는 일.

이게 이 프로젝트에서 제일 지루하고, 제일 오래 걸리고, 블로그에서 아무도 안 쓰는 부분이다. RAG 튜토리얼은 대부분 PyPDFLoader 한 줄로 끝난다. 실제 자료는 그렇게 생기지 않았고, 공문 하나만 열어봐도 한글 파일이 나오고, 구형 오피스 파일이 나오고, 스캔 이미지가 나온다. 이 글이 그 삽질을 반복하지 않게 해주면 좋겠다.

처리해야 했던 포맷

드라이브에서 당겨온 파일의 확장자를 세어보고 정리한 목록이다.

pdf   docx   pptx   xlsx   csv   txt   md
hwp   hwpx
doc   ppt    xls    odt    rtf

첫 줄은 예상했던 것들이고, 문제는 아래 두 줄인데, 이 두 줄 때문에 사다리가 생겼다고 봐도 된다. 앞 편 끝에서 "상상보다 더 난장판"이라고 했는데, 목록을 보면 그 말이 왜 나왔는지 보인다.

hwp 는 한국 대학 자료에서 피할 수 없는데, 공문, 계획서, 보고서, 심의 서류가 전부 한글 파일이고, 영어권 도구 생태계에는 이 포맷을 위한 성숙한 로더가 없다. 영어로 검색해봐야 파이썬 패키지 하나로 끝나는 문제가 아니고, 구할 수 있는 것도 대부분 오래전에 방치된 프로젝트다.

구 바이너리 오피스 포맷도 여전히 살아 있는데, 2010년대 초에 만든 발표자료가 .ppt 로 남아 있고, 누가 보내준 .doc 가 그대로 폴더에 남아 있다. 2007년 이후 포맷(docx/pptx/xlsx)과 그 이전 포맷은 파일 구조가 완전히 다른데, 앞은 zip 안의 XML 이고, 뒤는 OLE 복합 문서다. 같은 "문서"라는 이름인데, 내부는 아무 관련이 없다고 봐도 된다.

폴백 사다리로 풀었다

포맷별로 라이브러리를 하나씩 붙이는 대신, 빠른 것부터 시도하고 실패하면 무거운 것으로 내려가는 사다리로 만들었다.

단계	대상	방법
1	pdf	`pdftotext` (poppler)
2	docx · pptx · xlsx · hwpx	표준 라이브러리 zip + XML 파싱
3	hwp	`hwp5txt` / pyhwp
4	doc · ppt · xls · odt · rtf	LibreOffice `soffice` 헤드리스 변환
5	스캔 PDF · 이미지	`pdftoppm` → tesseract OCR (kor+eng)

몇 가지 짚어둘 게 있다. 2단계에 라이브러리를 안 쓴 건 의도적인데, docx·pptx·xlsx·hwpx 는 전부 zip 컨테이너 안에 XML 이 들어 있는 구조라서, 텍스트만 필요하다면 표준 라이브러리의 zipfile 로 열고 텍스트 노드를 긁는 것으로 충분하다. XML 은 사람이 읽기 불편할 뿐, 텍스트를 빼내기에는 충분히 단순하다. 서식이나 표 구조를 살릴 거면 전용 라이브러리가 필요하겠지만, 임베딩에 넣을 텍스트에는 과하다. 의존성이 하나 줄면 3년 뒤에 안 깨질 확률이 올라간다.

4단계 LibreOffice 는 최후의 수단인데, soffice 헤드리스 변환은 파일 하나당 프로세스를 새로 띄우고, 느리고, 간혹 멈춘다. 그래도 구 포맷을 이걸로 넘기는 쪽이 포맷별 파서를 여섯 개 붙이는 것보다 유지보수가 쉽다고 생각한다. 다만 이 경로로 가는 파일 비율이 높아지면 전체 색인 시간이 급격히 나빠지니, 로그를 남겨서 지켜봐야 한다.

5단계 OCR 은 껐다 켤 수 있게 뒀는데, 스캔 PDF 를 tesseract 로 통째로 뜨면 페이지당 수 초가 나가서, 첨부파일 이미지나 스캔 문서에만 걸었다. 한국어 자료라 kor+eng 를 같이 줘야 하는데, kor 만 주면 문서 안의 영어 용어가 망가진다. 사다리의 전제는, 위에서 성공하면 아래를 안 본다는 것이니, 위 단계일수록 조용히 틀리면 안 된다.

수집 — 서버가 드라이브를 직접 당긴다

원래 구조는 맥이 클라우드에서 받아 서버로 밀어주는 것이었는데, 2만 개 53GiB 를 앞두고 그 경로를 버렸다. 맥이 병목이고, 노트북을 닫으면 멈추고, 같은 데이터가 두 번 복사된다. 셋 다 감당할 수 없는 이유였다.

그래서 서버에 rclone(당시 v1.74.2)을 깔고 드라이브를 직접 당기게 했는데, 여기서 정한 것 세 가지가 나중에 다 쓸모가 있었는데, 지금 돌아보면 운 좋게 고른 것 같다.

자체 OAuth 클라이언트를 만들었고, 스코프를 readonly 로 잡았다. rclone 공용 클라이언트를 쓰면 다른 사용자와 API 쿼터를 공유해서 대량 전송에서 막히고, readonly 로 잡으면 스크립트 사고로 원본이 지워질 경로가 아예 없다. 자동화가 남의 클라우드를 만지는 상황에서는 이게 싸고 확실한 안전장치다. 비용도 들지 않으면서, 이 정도 안전장치를 얻는 일은 드물다.

확장자 화이트리스트도 걸었다. --include 로 문서 확장자만 받았는데, 드라이브에는 동영상과 데이터셋이 섞여 있고, 그건 브레인에 넣을 것도 아니면서 용량은 크다. 받을 것을 고르는 게 아니라 받지 않을 것을 나중에 지우는 구조가 되면, 전송 시간과 디스크를 이중으로 낭비한다.

구글 문서 네이티브 파일은 다운로드가 아니라 변환이다. Google Docs/Sheets/Slides 는 바이너리 파일이 아니라 서버 측 객체라서 그냥 가져올 수 없고, --drive-export-formats docx,xlsx,pptx,pdf 를 줘서 어떤 포맷으로 변환해 받을지 지정해야 한다. 이걸 모르면 파일 목록에는 보이는데 받아지지 않는 문서가 대량으로 남고, 로그에는 딱히 에러도 안 남는다.

곁가지 함정 두 개

로더와 직접 상관없지만 같은 시기에 밟았고, 둘 다 조용히 틀린 결과를 만드는 종류라, 꼭 적어두고 싶다.

로컬 LLM 의 추론 태그부터. 당시 쓰던 Nemotron 은 사고 과정을 </think> 로 닫고 답을 내는데, 응답에서 답만 꺼내려면 태그 뒤를 잘라야 한다. 처음에는 단순하게 첫 </think> 뒤를 잘랐는데, 그 문자열이 본문에도 나올 수 있다. 마지막 </think> 를 기준으로 잘라야 한다. 첫 번째 것으로 자르면 추론 산문이 위키 페이지에 그대로 실린다. 태그 하나 때문에, 위키 전체가 오염될 뻔했다.

맥의 기본 도구 버전도 함정이었다. macOS 기본 bash 는 아직 3.2 이고, rsync 는 2.6.9 인데, --info= 같은 옵션이 없고, 빈 배열과 set -u 조합에서 최신 bash 와 다르게 죽는다. 맥에서 돌리는 동기화 스크립트는 이 두 개를 전제로 써야 하고, 로컬에서 brew 로 깐 최신 bash 로 테스트하고 launchd 에 걸면 그때부터 조용히 안 돈다. 로더 문제가 아니라 환경 문제인데, 증상은 똑같이 조용하다.

여기까지가 함정 둘이고, 하나 더는 함정이라기보다 판단인데 같이 적어둔다. 짧은 노트는 위키에서 제외했다. 120자 미만 노트는 LLM 합성 대상에서 빼고 검색 색인에만 넣었는데, 한 줄 메모를 70초 들여 위키 페이지로 만들 이유가 없다. 비용이 문서 개수에 정비례하는 구조에서는 이런 필터 하나가 그대로 시간으로 돌아온다. 로더만 완성하면 끝나는 줄 알았는데, 주변부가 이렇게나 붙어 있었다.

실패한 부분

여기까지가 잘된 이야기고, 안 된 이야기도 써야 정직하다.

드라이브 증분 자동 수집은 결국 제대로 안 굴러갔는데, 초기 적재는 성공했고, 새벽 3시 동기화 크론까지 걸었고, 그때까지는 완벽하게 돌아가는 것처럼 보였다. 두 달 뒤 시스템 전수 점검을 하면서 확인한 상태가 이랬다.

드라이브 소스 폴더    없음
동기화 크론          없음
동기화 스크립트       .sh (리눅스 전용, 이관한 윈도우 호스트에서 실행 불가)
OAuth 토큰           만료 이력 있음

호스트를 리눅스 박스에서 윈도우 머신으로 이관하면서, 셸 스크립트로 된 수집 경로가 통째로 죽었다. 문제는 언제 죽었는지 내가 모른다는 점이다. 전수 점검을 하기로 마음먹은 날 처음 확인했고, 그 사이에 알려준 것은 아무것도 없었다. 자동화가 죽었는데 아무도 모르는 것, 이게 자동화의 가장 흔한 죽음이다.

이게 이 시리즈에서 반복해서 나오는 모양이다. 수집 파이프라인은 에러를 내며 죽지 않고, 처리 건수가 0 이 되면서 죽는다. 그런데 0 은 "새 문서가 없다" 와 구분되지 않고, 평소에도 0 이 정상인 날이 있으니, 로그를 봐도 이상하지 않다.

교훈으로 정리하면 이렇다. 수집 파이프라인에 처리 건수만 남기면 안 되고, 마지막 성공 시각과 소스 측 총 개수를 같이 남겨야 한다. 그러면 "0개 처리" 옆에 "소스에 20,000개 있음 / 마지막 성공 42일 전" 이 찍혀서, 이상함이 눈에 보인다. 숫자 두 개가 나란히 찍히면, 죽음은 조용히 있을 수 없다. 지금은 이런 항목을 매일 아침 점검 규칙으로 박아뒀는데, 그 이야기는 5부에서 한다.

다음 편에서는 그렇게 읽어들여 만든 위키를 열어봤더니 일부가 영어로 쓰여 있던 이야기를 해 보자. 프롬프트를 고친 뒤에도 이미 만들어진 페이지는 그대로였다는, 더 일반적인 문제로 이어진다.

개인 세컨드브레인을 RAG 없이 시작한 이유

TechToast — Sun, 2 Aug 2026 08:11:15 +0900

의료영상 AI 연구를 하다 보니, 논문이며 회의록, 연구계획서, 강의자료, 과제 문서가 몇 년치 쌓였는데, 어느 순간부터는 어디에 뭐가 있는지 내 머리로 감당이 안 되기 시작했다. 검색을 해도 파일명이 기억나야 찾아지고, 파일명은 당연히 기억나지 않고. 그래서 개인 연구용 세컨드브레인을 만들기로 했다. 2026년 6월 2일이었다.

이 글은 그 첫날에 내린 설계 결정 하나에 관한 이야기다. 요즘 이런 걸 만든다고 하면 거의 자동으로 나오는 답이 있는데, 문서를 청크로 쪼개 임베딩하고 벡터DB에 넣어두고, 질문이 들어오면 비슷한 조각을 꺼내 LLM에 물리는 방식, 그러니까 RAG다. 나는 그걸 안 하기로 시작했다.

두 달 뒤에 이 시스템은 "아무짝에도 쓸모없다"는 말을 듣게 되는데, 미리 밝혀두면 그 원인은 이 결정이 아니었다. 그래도 첫날의 판단부터 적어두는 게 맞다고 생각한다. 나중에 무너지는 게 정확히 어느 층이었는지 가려내려면, 출발점이 남아 있어야 하니까.

대신 고른 것 — 질의 시점이 아니라 수집 시점에 합성한다

Karpathy 가 정리한 LLM-Wiki 패턴을 택했다. 골자는 LLM 이 도는 시점을 앞으로 당기는 것이다.

RAG 는 소스를 원본 그대로 두고, 질문이 올 때마다 조각을 찾아 조립한다. LLM-Wiki 는 반대로, 소스가 들어오는 그 시점에 LLM 이 한 번 읽고 마크다운 페이지로 다시 쓰면서, 다른 페이지로 갈 링크를 본문에 박아 넣는다. 그러면 질문이 들어와도 검색해서 조립할 필요 없이, 이미 정리돼 있는 글을 읽으면 된다.

색칠된 칸이 LLM 이 도는 자리다. RAG 는 질문마다 저기가 돌지만, LLM-Wiki 는 수집할 때 한 번 돌고 끝난다.

이 구조에서는 질의 시점에 임베딩이 아예 필요 없다. 사람이 읽을 수 있는 위키가 이미 만들어져 있고, 페이지끼리 링크로 엮여 있는데, Obsidian 의 위키링크 문법을 그대로 썼으니 그 링크 집합이 곧 지식 그래프가 된다. 그래프DB를 따로 둘 이유가 없었다. v1 에는 벡터DB도 그래프DB도 넣지 않았고, 그건 빠뜨린 게 아니라 결정이었다.

근거가 세 가지였다.

하나, 개인 규모에서는 사전합성이 RAG 를 이긴다. 소스가 수백에서 수천 개 수준이라면, 전부 한 번씩 읽고 정리해두는 비용을 감당할 수 있고, 그러면 질의 시점에는 잘 정리된 글을 읽는 셈이니 답 품질이 조각 검색보다 낫다. 조각 검색의 약점이 꽤 분명해서 그렇게 봤다. 청크는 문서를 기계적으로 자른 것이라, 잘린 자리에서 문맥이 끊기고, 표의 헤더와 값이 서로 다른 청크로 갈라지고, 앞 문단을 알아야 뜻이 통하는 문장이 혼자 떨어져 나오고. 미리 사람이 읽을 글로 다시 써두면 그런 일이 애초에 생기지 않는다. 회사 문서 수십만 건이라면 얘기가 다르겠지만, 내 자료는 그 규모가 아니라고 봤다.

둘, 무거운 GraphRAG 는 비용 대비 이득이 얇다. 개인 메모리 계층을 다루는 쪽(Mem0, PersonalAI)의 보고를 보면, 본격적인 GraphRAG 는 2~3배 비용을 쓰면서 이득은 생각보다 작다. 링크로 엮인 마크다운이 이미 그래프의 90% 를 준다면, 남은 10% 에 3배를 쓸 이유가 없었다. 게다가 마크다운 링크에는 공짜로 따라오는 게 하나 있는데, 사람이 브라우저로 눌러서 돌아다닐 수 있다는 점이다. 그래프DB 안의 간선은 쿼리를 써야 보이지만, 위키링크는 그냥 클릭된다.

셋, 그리고 이게 사실 제일 컸는데 — 벡터DB 를 올릴 자리가 없었다.

하드웨어가 설계를 정했다

서빙 박스는 과제비로 구매한 MSI EdgeXpert 다. NVIDIA GB10 Grace-Blackwell 을 얹은 물건인데, 솔직히 말하면 DGX Spark 의 아류작 혹은 짭퉁이다. 그래도 같은 스펙에 가격이 조금 낮으면, 그깟 금색 커버 아닌들 어떠하리. 책상 위에 놓인 이 네모박스가 은근히 주는 만족감이 아주 크다.

당시 실측 스펙은 이렇다.

통합메모리     약 128GB (가용 121GB)
CPU           ARM64 20코어
디스크         916GB
LLM           NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4
서빙           vLLM, 256K 컨텍스트, OpenAI 호환 API

통합메모리 박스는 CPU 와 GPU 가 같은 메모리를 나눠 쓴다. 120B 급을 단일 박스에 올릴 수 있다는 게 이 구성을 고른 이유였지만, 대신 모델이 올라가면 나머지 전부가 그 뒤에 줄을 서게 된다. 별도 VRAM 이 있는 구성이라면 벡터DB는 시스템 RAM 에 살면 되니 모델과 자리를 다투지 않는데, 통합메모리에서는 그런 구분이 없어서 모델이 먹은 만큼이 그냥 사라진다.

vLLM 을 기본 설정으로 띄웠더니, 가용 121GB 중 119GB 가량을 먹고 2GB 대가 남았다.

여기에 Qdrant 를 띄우고 임베딩 모델까지 상주시킨다는 계획은, 계획이 아니라 농담이다. 상주시켜야 한다는 조건도 중요한데, 임베딩 모델은 로드 자체가 오래 걸려서, 검색 한 번 하려고 매번 올렸다 내리는 구조로는 쓸 수가 없다. 결국 벡터 검색을 붙이려면 메모리에 계속 앉아 있는 프로세스를 하나 더 둬야 하는데, 그 자리가 없었다.

제약은 나중에 조금 풀었다. vLLM 컨테이너를 --gpu-memory-utilization 0.78 로 다시 만들어서 14GB 가량을 회수했고(기본값이 0.9였다), 그 뒤로 가용 RAM 이 16GiB 정도 됐다. 다만 그건 나중 일이고, 첫날의 판단 기준은 "여유가 없다" 였다.

그러니까 벡터DB 없는 설계는 이론적 선호이기도 했지만, 하드웨어가 시킨 것이기도 했다. 이건 미리 밝혀두는 편이 정직하다고 생각한다. 제약 때문에 어쩔 수 없이 고른 걸 나중에 소신처럼 적어두면, 다시 읽을 때 그 판단의 진짜 근거를 알 수 없게 되니까.

첫날 돌아간 것

명령 여섯 개짜리 CLI 로 만들었다.

brain init      저장소 초기화
brain ingest    새 소스를 LLM 이 읽고 위키 페이지로 합성
brain query     위키에서 찾아 답한다
brain lint      죽은 링크·빈 페이지 점검
brain digest    최근 변화 요약
brain status    상태

여기에 웹 리서치를 하나 더 붙였는데, brain ask 는 자체 호스팅한 SearXNG 를 물고 ReAct 루프를 돌려서, 브레인 안에 없는 걸 물으면 웹에서 찾아온다. 검색엔진을 직접 띄운 건 API 키와 쿼터에 묶이지 않으려는 것이었다. 개인 도구가 남의 요금제 위에 서 있으면, 어느 날 조용히 멈춰 버린다.

자동화도 첫날 걸었다. 서버 크론으로 매시간 ingest, 아침 8시 다이제스트, 일요일 9시 lint 를 돌리고, 맥에서는 Obsidian 볼트를 5분마다 동기화했다. 실패하면 폰으로 푸시가 오도록 ntfy 를 붙였고, 6월 2일에 여기까지 엔드투엔드로 돌아가는 걸 확인했다.

기분이 좋았다. 설계가 깔끔했고, 벡터DB 없이도 된다는 걸 증명한 것 같았고, 링크로 엮인 위키가 실제로 브라우징까지 됐고.

lint 가 존재할 수 있다는 것

이 설계에서 내가 제일 마음에 들어했던 건, 명령 목록의 네 번째 줄이었다. brain lint 가 존재할 수 있다는 점.

위키가 링크로 엮인 마크다운이니 점검이 그냥 가능하다. 없는 페이지를 가리키는 링크를 세면 죽은 링크가 나오고, 본문이 비었거나 제목만 있는 페이지도 셀 수 있고, 아무 데서도 링크되지 않은 고아 페이지까지 찾아낼 수 있다. 전부 파일과 문자열을 세는 일이라 특별한 도구가 필요 없어서, 일요일 아침마다 걸어둘 수 있었다.

벡터DB 에는 이에 해당하는 게 없다. 임베딩이 제대로 됐는지 확인하는 표준 점검이라는 게 없어서, 색인이 몇 개인지는 세어도 그 벡터들이 의미 있는 자리에 놓였는지는 세어서 알 수가 없다. 검색 결과가 이상해 보여도, 원래 이 정도인지 망가진 것인지 구별할 기준이 없다.

이 차이가 사전합성 방식의 저평가된 실질적 이점이라고 생각한다. 사람이 읽을 수 있는 산출물은 검증도 사람이 할 수 있다. 위키 페이지가 엉뚱하게 쓰여 있으면 열어보면 보이는데, 벡터가 엉뚱한 자리에 있으면 열어볼 방법이 없다.

경험이 있어서 그렇게 말하는 건데, 벡터 쪽이 티 안 나게 망가지는 걸 나중에 몇 주 동안 모른 채로 겪는다. 그때 증상은 "검색이 안 된다" 가 아니라 "답이 그럴듯한데 틀렸다" 였고, 그게 훨씬 나쁘다.

그래서, 이 결정은 틀렸나

아니다. 지금도 개인 규모에서는 사전합성이 맞다고 생각한다. 이 시리즈 후반에서 무너지는 건 이 결정이 아니라 여기에 급하게 덧붙인 층이고, 둘은 서로 모순되지 않는다.

문제는 다른 데 있었다. 위에서 근거를 적을 때, 나는 이렇게 썼다.

개인 규모(소스 수백~수천 개)에서는 사전합성이 RAG 를 이긴다.

괄호 안이 조건인데, 나는 그걸 근거 문단에만 적고, 설계 문서 어디에도 "이 설계는 소스 N개까지 유효하다"고 적지 않았다. 조건부 명제를 무조건 명제처럼 저장해둔 셈이다.

사소해 보이지만 사소하지 않다. 조건을 적어두면 그 조건을 감시할 수 있어서, 소스 개수가 임계값에 가까워질 때 알림을 걸 수도 있고, 적어도 다음에 이 문서를 읽는 사람이 "지금 몇 개인데?" 하고 물을 수 있다. 조건을 지우고 결론만 남기면, 언제 만료되는지 알 수 없는 문장이 되어 버린다.

그리고 같은 날 오후에, 그 조건이 깨졌다. 문서 2만 개를 만났다.

다음 편에서 그 이야기를 써 보자.

20,000개 문서 앞에서 설계가 무너진 날

TechToast — Sun, 2 Aug 2026 08:01:53 +0900

앞 편에서, 개인 연구용 세컨드브레인을 벡터 RAG 없이 시작한 이야기를 썼다. 소스가 들어올 때 LLM 이 한 번 읽고 링크 걸린 마크다운으로 다시 쓰는 방식(Karpathy 의 LLM-Wiki 패턴)이고, 근거 중 하나가 "개인 규모에서는 사전합성이 RAG 를 이긴다" 였다. 2026년 6월 2일에 그게 엔드투엔드로 돌아가는 걸 확인했다.

같은 날 설계가 깨졌다. 이 편은 그 이야기고, 시리즈에서 제일 중요한 편이라고 생각한다.

산수 한 줄로 끝났다

구글드라이브에는 대학 두 곳에서 일하며 만든 자료가 예전부터 쌓여 있었다. 브레인에 넣을 대상으로 그 폴더를 지정하고, 규모를 세어봤다.

폴더 두 개를 합쳐 문서 20,500개에, 약 53 GiB 였다. 이하 이 글에서는 약 2만 개라고 부르자. 앞 편에서 내가 적어둔 전제는 "수백~수천 개" 였는데, 그림의 빨간 선이 그 상한이고 실제 규모는 그 선을 한참 넘어간 곳에 있었다.

LLM-Wiki 패턴은 문서 하나당 LLM 합성 한 번이다. 소스를 읽고, 요약하고, 링크를 뽑아, 마크다운을 생성하는 일이라 짧게 끝나지 않는데, 당시 이 박스에서 잰 문서당 합성 시간이 약 70초였다. 20,500 곱하기 70초는 1,435,000초, 그러니까 16.6일이다.

이 그림을 그리다가, 내 초고가 틀렸다는 걸 알았다. "수천 개면 하룻밤"이라고 적어뒀는데 5,000개는 이미 4.1일이고, 하룻밤 안에 끝나는 건 1,000개 수준까지다. 문서당 70초에서 하루를 넘기지 않는 한계는, 정확히 1,234개다. 비용이 개수에 정비례하니, 이런 감각은 금방 어긋난다.

16.6일은 그것도 연속으로 16일이고, 그 동안 같은 vLLM 이 다른 일을 못 한다. 브레인의 다른 기능도 그 뒤에 줄을 서고, 회의록 정리도 서고, 논문 요약도 서고. 증분으로 나눠 돌린다 해도 초기 적재를 끝내지 못하면, 시스템 자체가 시작되지 않는다.

여기서 중요한 건, 16일이 "느리다"는 문제가 아니라는 점이다. GPU 를 하나 더 붙이면 8.3일이 되지만, 그래도 답이 아니다. 절반으로 줄여도 여전히 일주일을 넘고 네 배를 붙여도 나흘이니, 깨진 것은 속도가 아니라 전제였다.

문서당 LLM 1회라는 비용 구조는 소스 개수에 정비례한다. 천 개에서는 하룻밤이고, 2만 개에서는 시스템이 성립하지 않는다. 같은 설계가 어느 구간에서는 최적이고 어느 구간에서는 무의미한데, 나는 그 경계를 넘었다는 걸 폴더 크기를 세고 나서야 알았다.

위키를 버리지 않고 층을 하나 얹었다

선택은 두 가지였다. LLM-Wiki 를 버리고 표준 RAG 로 전면 전환하거나, 위키는 남기고 대규모 소스를 감당할 검색 계층을 따로 얹거나.

두 번째를 골랐다. 위키가 사람이 읽는 층으로는 여전히 잘 작동했고, 링크를 따라가며 브라우징하는 건 벡터 검색이 대체할 수 없기 때문이다. 반대로 2만 개 원본 문서에서 "그 숫자가 어디 있었지"를 찾는 일은, 위키가 못 한다. 용도가 다르니 층을 나누는 게 맞다고 판단했다.

임베딩은 fastembed 로 intfloat/multilingual-e5-large 를 썼다. 1024차원에 ONNX 런타임에서 CPU 로 돌린다. 벡터DB 는 도커로 띄운 Qdrant 를 쓰고, 처리 완료분은 매니페스트 파일에 기록해서 증분으로만 색인하게 했다.

CPU 로 임베딩한 이유는, 앞 편의 그 119GB 다. GPU 메모리에 임베딩 모델을 얹을 자리가 없었고, ONNX/CPU 로 돌리면 느리지만 20 코어가 놀고 있었으니 그쪽이 현실적이었다.

e5 를 고른 이유는 한국어였다. 자료가 대부분 한국어인데, 당시 실측에서 한국어 코사인 유사도가 0.8 수준으로 나왔고, 나는 그걸 메모에 장점으로 적어뒀다.

이 문장이 나중에 이 시리즈에서 제일 아픈 대목이 된다. 미리 한 줄만 적어두면, 무관한 문서끼리도 0.8 이 나온다는 건 변별력이 없다는 뜻이었다. 당시엔 한국어를 잘 이해한다는 신호로 읽었다. 5부에서 수치와 함께 다시 나온다.

e5 는 접두사도 요구한다. 질의에는 query:, 문서에는 passage: 를 붙여야 하는데, 안 붙이면 조용히 품질이 떨어진다. 에러가 나지 않으니, 더 위험하다.

같이 미룬 것도 적어두자. 진짜 그래프 추출(LightRAG 류)은 이때 접었다. 엔티티와 관계를 뽑으려면 청크마다 LLM 을 호출해야 하는데, 그건 문서당 70초와 정확히 같은 벽이고, 청크는 문서보다 많으니 더 심하다. 대신 투입 대비 회수가 가장 큰 벡터 의미검색만 먼저 넣었다. 색인된 게 하나도 없는 동안은 예전 위키 어휘검색으로 폴백하게 했는데, 새 계층이 비어 있는 기간에도 시스템은 동작해야 하니까.

곁가지 — 임베딩 데몬을 따로 띄운 이유

이건 같은 걸 만드는 사람에게 바로 쓸모있을 것 같아서, 따로 적어둔다.

brain query 를 처음 구현할 때는, 질의가 들어오면 임베딩 모델을 로드해 질의를 벡터로 바꾸고 Qdrant 에 던졌다. 문제는 로드 시간이었다. 모델이 약 2GB 인데 올리는 데 170초가 걸리고, 정작 질의 자체는 1초도 안 걸린다.

질문 하나에 3분을 기다리는 도구는, 도구가 아니다. 그래서 임베딩만 담당하는 상주 데몬을 따로 뒀다. 부팅 때 한 번 모델을 올린 뒤 죽지 않고 떠 있으면서 색인과 질의 양쪽에 HTTP 로 벡터를 내준다.

교훈은 단순하다. 모델 로드 시간이 요청 처리 시간보다 크면, 프로세스 경계를 다시 그려야 한다. CLI 한 방에 다 넣고 싶은 마음이 들지만 로드가 170초면 그 구조는 성립하지 않는다. 그리고 이 판단은 앞 편의 메모리 제약과 붙어 있다. 상주 데몬을 두려면 메모리에 계속 앉아 있을 자리가 필요하고, 그 자리를 어디서 뺏어올지가 결국 같은 문제였다.

조건부 명제를 조건 없이 저장했다

정리하면 이렇다.

"사전합성이 RAG 를 이긴다"는 규모 조건부 명제였다. 나는 조건을 근거 문단에만 적고, 설계 문서에는 적지 않았다.

기술 결정을 기록할 때 우리는 보통 결론을 적는다. "벡터DB 없이 간다." 그리고 그 결론이 왜 맞는지 근거를 붙인다. 그런데 근거 안에 조건이 숨어 있으면, 그 조건은 결론과 함께 저장되지 않아서, 나중에 문서를 다시 읽는 사람은 — 그게 3주 뒤의 나였다 — 결론만 본다.

지금은 설계 결정을 적을 때, 이런 줄을 같이 적는다.

유효 범위: 소스 1,200개 이하
무효화 조건: 소스 개수 × 문서당 합성 시간 > 24시간

두 줄이 같은 수치를 가리켜야 한다. 처음 이 규칙을 적을 때 나는 유효 범위에 5,000개라고 써놓고 무효화 조건은 24시간으로 뒀는데, 5,000개는 4일이니 두 줄이 서로를 부정한다. 이 편의 그림을 그리다가 그걸 발견했다. 수치를 도표로 옮기면, 앞뒤가 안 맞는 게 눈에 보인다.

조건이 아니라 무효화 조건으로 적는 게 핵심이다. "언제까지 맞다" 보다 "무엇이 관측되면 틀린 것이다" 가, 확인 가능한 문장이기 때문이다. 이건 나중에 이 시리즈의 관통 주제가 된다. 선언을 적을 때 그 선언이 깨졌는지 확인하는 방법을 같이 적어두지 않으면, 선언은 그냥 오래된 낙관으로 남는다.

후일담 — 곁가지가 본체가 됐다

한 달 뒤 시스템을 재설계하면서, 확인한 사실이 있다.

의미검색이 실제 백본이었다. 색인 작업은 원본 소스를 임베딩하고 있었고 LLM 이 재합성한 위키는 색인에서 명시적으로 제외돼 있었으니, 질문에 답할 때 근거로 쓰인 건 위키가 아니라 원본 소스 쪽이었다. 그래서 재설계에서 자동 위키는 동결하고, 읽기전용 유물로 남겼다. 급하게 얹은 곁가지가 본체가 되고, 원래 본체가 유물이 된 셈이다.

이게 앞 편에서 내가 자랑했던 것과 어긋난다는 점도 적어두자. 나는 lint 로 위키를 점검할 수 있다는 걸 이 설계의 장점으로 꼽았는데, 실제로 답의 근거가 된 층은 위키가 아니라 벡터 쪽이었고 그쪽에는 점검할 방법이 없었다. 점검 가능한 층은 점검했고, 점검할 수 없는 층이 정작 일을 하고 있었다.

정직하게 하나 더. 이때 얹은 벡터 계층 자체도, 결국 망가진 채로 몇 주를 돌고 있었다. 위에서 장점이라고 적어둔 그 코사인 0.8 이 원인이었고, 그 진단은 5부에서 수치와 함께 쓴다.

다음 편에서는 그 2만 개를 실제로 읽어들이는 이야기를 해 보자. 한국 대학 자료의 파일 포맷은, 상상보다 더 난장판이다.

Cosmo communicator Genian OS 한글 문제 해결

TechToast — Mon, 29 Jan 2024 16:05:08 +0900

코스모 커뮤니케이터를 패기롭게 사놓고 나서는,

기기의 한계로 안드로이드에서 뭘 더 사용하는건 포기하고 리눅스를 설치했다.

Genian OS 라고 처음들어보는데, Debian / Ubuntu 계열인 듯.

일단 설치하면 US 키보드 배열로 되어 있는데,

쓰는 사람은 알다시피 키보드 배열 중 특수문자 위치가 다르다.

일단 시작부터 문제되는 건,

리눅스 세팅 중 필수적으로 쓰이는 백슬래쉬가 한글 키보드 위치에서는 fn + m 인데, 영문 키보드에서는 shift + , 인 것.

일단 세팅을 해야 하니 부들부들 떨며 짜증팍팍 내며 영어 키보드 자판을 보면서 한다.

1. 레이아웃에 한글 레이아웃 추가

안드로이드에서는 자소분리 일어나긴 했지만 레이아웃을 지원은 했다.

Genian OS 에서는 지원조차 하지않는다.

수정 파일 위치는 /etc/share/X11/xkb/symbols/planet_vndr/cosmo 파일이다.

시작 버튼같은걸 눌러서 kwrite 를 열어서, 저 위치를 찾아 들어가서 연다.

(sudo 안하고 열어도 저장할때 따로 비밀번호 물어보니 다행)

영국놈들 제품이다 보니 gb가 최상위에, 그다음 us, jp, 여러개 세팅 되어 있는데

적당한 위치에다가 아래 텍스트 내용 긁어다 복붙 후 저장.

gb 내용 그대로 긁어다가, 내 꺼 자판에 있는 거 적당한거 채워넣은 거임. 일단 급한대로는 동작함.

xkb_symbols "kr" {
    include "planet_vndr/cosmo(modifiers)"
    include "planet_vndr/cosmo(common_keys)"

    name[Group1]="Cosmo English (KR)";

    key <AE01>  { [         1,      exclam,   asciitilde,    F1 ] };
    key <AE02>  { [         2,          at,        grave,    F2 ] };
    key <AE03>  { [         3,  numbersign,    backslash,    F3 ] };
    key <AE04>  { [         4,      dollar,     EuroSign,    F4 ] };
    key <AE05>  { [         5,     percent,     division,    F5 ] };
    key <AE06>  { [         6, asciicircum,      greater,    F6 ] };
    key <AE07>  { [         7,   ampersand,    braceleft,    F7 ] };
    key <AE08>  { [         8,    asterisk,   braceright,    F8 ] };
    key <AE09>  { [         9,   parenleft,  bracketleft,    F9 ] };
    key <AE10>  { [         0,  parenright, bracketright,   F10 ] };

    key <AD01>  { [         q,          Q,XF86AudioPlay,  Greek_OMEGA ] };
    key <AD02>  { [         w,          W,XF86AudioPrev,      Lstroke ] };
    key <AD03>  { [         e,          E,XF86AudioNext,    trademark ] };
    key <AD04>  { [         r,          R,        Print,   registered ] };
    key <AD05>  { [         t,          T,XF86AudioMute,          yen ] };
    key <AD06>  { [         y,          Y,    leftarrow,   rightarrow ] };
    key <AD07>  { [         u,          U,    downarrow,      uparrow ] };
    key <AD08>  { [         i,          I,         plus,    plusminus ] };
    key <AD09>  { [         o,          O,        minus,     Ooblique ] };
    key <AD10>  { [         p,          P,        equal,        THORN ] };

    key <AC01>  { [         a,          A, XF86TaskPane,              AE ] };
    key <AC02>  { [         s,          S,       ssharp,         section ] };
    key <AC03>  { [         d,          D,  XF86TopMenu,             ETH ] };
    key <AC04>  { [         f,          F,      XF86UWB,     ordfeminine ] };
    key <AC05>  { [         g,          G,          bar,             ENG ] };
    key <AC06>  { [         h,          H,    backslash,  dead_diaeresis ] };
    key <AC07>  { [         j,          J,   underscore, dead_circumflex ] };
    key <AC08>  { [         k,          K,     question,          degree ] };
    key <AC09>  { [         l,          L,    semicolon,      dead_caron ] };
    key <AC11>  { [apostrophe,   quotedbl,        colon,      dead_acute ] };

    key <AB01>  { [         z,          Z,        guillemotleft,        dead_belowdot ] };
    key <AB02>  { [         x,          X,       guillemotright,        dead_abovedot ] };
    key <AB03>  { [         c,          C, XF86AudioLowerVolume,            copyright ] };
    key <AB04>  { [         v,          V, XF86AudioRaiseVolume,  leftsinglequotemark ] };
    key <AB05>  { [         b,          B,XF86MonBrightnessDown,XF86KbdBrightnessDown ] };
    key <AB06>  { [         n,          N,  XF86MonBrightnessUp,  XF86KbdBrightnessUp ] };
    key <AB07>  { [         m,          M,                slash,           dead_grave ] };
    key <AB09>  { [    period,    greater,                U263A,           dead_tilde ] };

    key <AB08>  { [     comma,      less, XF86Option,   multiply ] };

    //key <LALT>  { symbols[Group1] = [ Alt_L, Alt_L, ISO_Last_Group,   ISO_Last_Group ] };
    //key <LALT>  { symbols[Group1] = [ Alt_L, Alt_L, ISO_Last_Group,   ISO_Last_Group ] };
};

영어만 있는 이유는, 아는 사람은 알겠지만 여기다가 유니코드로 ㄱ, ㄲ 같은거 백날 다 넣어봤자 자소분리 일어난다.

저장후, Konsole (terminal) 열어서

setxkbmap -model planetcosmo -layout kr

실행하면 일단 특수문자는 해결된다.

영원히 디폴트로 박으려면,

/etc/default/keyboard 파일을 또 kwrite 로 열어서 수정.

XKBMODEL="planetcosmo"
XKBLAYOUT="kr"

나머지는 비워두거나, backspace 에 guess 라고 되어있는거 그냥 놔두면 됨.

자소분리를 막는 입력기를 이제 골라야 하는데,

fcitx, ibus 는 지금 구버전 개똥버전 QT 업글 안된 버전에서는 오류난다.

ibus 는 엔터키, 백스페이스 키 안먹음 현상 있음. github 에도 이슈되었기 때문에 우리의 개똥버전 genian OS 에서는 사용불가.

fcitx 는 기껏 앞에 수정한 특수문자 배치를 지가 알아서 다른 키보드로 바꿔버려서 특수문자 입력이 불가능.

내가 성공한 건 uim과 uim-byeoru 설치. 이름이 일단 벼루 란다. 맘에듬.

이 분 블로그 참고함.

Ubuntu 18.04 한글 입력기 UIM 설정하기

Ubuntu 에서 한글 입력기 uim 설정하기

progtrend.blogspot.com

일단 터미널에서 설치 때림.

sudo apt install uim uim-byeoru

그리고 im-setting (시작버튼 같은데서는 Input Method 라고 뜸) 에 들어가서,

OK Yes 누르다가 선택메뉴에서 UIM 선택.

그리고 저분 블로그처럼 Input Method (시작 후 uim 입력하면 뜨는게 그거뿐임) 를 고름.

저 블로그에서는 한글로 뜨는데 우리 열악한 상황에선 영어로 뜨니까 대충 알아먹고 고고.

- Global settings 에서 Specify default IM 체크, Default input method 는 Byeoru 선택.

- Global key bindings 1 에서 global on, off 에 shift space 가 있으므로 다 삭제, 어차피 전각/반각 교체하는 바인딩 키인것 같다.

- Byeoru key bindings 1 는 키세팅 바꿀 사람만 고고.
어차피 우리의 코스모 안에서는 한글키를 배정할 키 따윈 없다.

나중에 FN + , (sym) 키 잘 안쓰니까 저기에 hangul 이라고 바인딩해서 써볼까 생각중.

다 끝나고 깔끔하게 sudo reboot.

한글 입력 문제가 (당장은) 해결된 Genian OS 설치된 Cosmo communicator 완성.

아 정말 애증의 제품.

새로 사실 분이 있다면 정말 뜯어말리고 싶다.

스팀덱 배틀넷 회색화면 먹통일때 임시방편 해결법

TechToast — Fri, 1 Dec 2023 23:56:44 +0900

자려고 누워서, 스팀덱으로 디아2나 좀 찌그리다 잘라 했는데

갑자기 배틀넷이 이상하다.

정확히는, 로그인은 되는데 그 이후에 회색창만 덩그러니 떠있다.

뭐 이것저것 낑낑매 봤는데,

레딧에 있는 것이 정답.

현재 배틀넷 업데이트로 인해 프로톤이든 뭐든 부딛히는게 있어서 화면이 안나오는 증상임.

실행 방법은 크게 2가지.

1. 데스크탑 모드에서 배틀넷을 켜면 마찬가지로 회색화면이긴 한데,

트레이바를 우클릭해서 원하는 게임을 키면 게임은 잘 켜짐.

2. 스팀덱 안의 battle.net 이 깔린 폴더로 찾아들어가서,

(STEAM LIBRARY 에서 Battle.net Launcher.exe 파일이 있는 폴더로 가면 된다)

가장 최신 업데이트 내용이 들어있을 것으로 예상되는 Battle.net.14542 버전 폴더를 삭제하거나 이름바꿔놓고,

Battle.net.14494 버전 폴더는 유지한 채 놔둔다.

(

완전 새로 설치한 사람은 이 폴더 없을텐데,

새로 설치한 사람은 다른 유투버가 제안한 방법 쓰기 바람. 이게 더 깔끔함.

https://www.youtube.com/watch?app=desktop&v=R9in9yeY4Jw

혹은, 레딧에 천사같은 분이 올려줌.

https://www.dropbox.com/scl/fi/16to2jpdut7dgk6ww412n/Battle.net.14494.zip?rlkey=j4ncgpszuyifaeqwx56v6dq2m&dl=0

)

그리고 그 상위 폴더로 가서,

battle.net 폴더의 퍼미션을 view only / only owner can change ~ 체크, apply to all subfolders 체크 하고 ㅇㅋ.

이제 배틀넷 켜면 정상동작 함.

자동 업데이트를 꺼놔도,그건 게임 업데이트를 자동으로 하지 못하게 막는거지

어차피 배틀넷앱 업데이트는 자동으로 되어버림.

물론 임시방편이고, view only 로 해놨기 때문에 배틀넷 업데이트는 당분간 안될꺼임.

이 문제가 해소된 버전이 나올때까지 이렇게 쓰고,

해소된 버전이 나오면 view & modify 로 바꿔서 다시 다 체크하고 ㅇㅋ 눌러야 업데이트 될꺼임.

Mac 에서 한컴오피스 네오 설치. (OS X Sonoma, Whisky)

TechToast — Fri, 10 Nov 2023 15:30:54 +0900

몇일 간 난리부르스 치며 고생했던 내용을 기록한다.

OS X Sonoma 가 되면서, 그동안 울며 겨자먹기로 이용하던 맥용 한글 2014 VP 에 치명적인 오류가 생기기 시작했다.

그림이 보이지 않기 시작한 것.

당장 머리속에 떠오른 방법은 Parallels 로 가상 윈도우를 올려, 그 안에 한글을 설치하는 것이지만

내 맥 활용 특성상, VM을 이용한 방식은 램을 너무 많이 잡아먹기도 하고

잡아먹은 만큼의 활용도도 너무 심하게 떨어졌다.

특히, 교육할인을 받아 구매한 Parallels 는 Standard license 라서, 램을 8GB까지밖에 설정하지 못해서

큰 문서를 여는데 답답해서 도저히 사용할 수가 없었다.

그래서 과감하게 환불을 질러버리고.

가장 이상적인 건 Wine stable 8 버전대로 올라온 아이를 이용하여, 설치되는 버전 아무거나라도 동작하면 가장 이상적일 듯 하여

Wine stable, gcenx wineskin 등등을 두루두루 다 이용해 보았다.

최종적으로는 성공했고, Whisky 와 automator 를 이용하여 연결해서, .hwp 파일을 더블클릭 했을때 해당 파일이 열리는 것 까지 성공.

일단 Wine stable 에서는, winetricks 를 이용하여 gdiplus, dotnet35sp1 등을 설치하는데 큰 애로사항이 있었고,
터미널에서 사용해야 하는 명령어, DLL 로드, 이제는 관련없을거라 생각했던 opengl32.dll 등이 발목을 잡았다.

wineskin winery 에서는 설치 자체는 정상적으로 잘 성공했고, 해당 방법을 제시한 블로그도 있다.

(그 분의 블로그 링크: https://blog.naver.com/PostView.naver?blogId=k8629030&logNo=222181786903)

나의 최종 목적인 '파일 연결' 에는 불합리했지만, 그래도 기본을 공부할 수 있는 좋은 계기가 되었다.

일단, 클리앙 및 다른 커뮤니티들의 정보를 끌어모아 보니, 2020 이후 버전들에서는 엄청난 오류가 아직 해소가 안 된다고 한다.

화면 상에 나오는 '페이지' 자체가 화면에 나타나지 않는 문제.

마침 내가 가진 설치파일 버전도 2020이라서 테스트 해 보았는데, 역시나 UI 전반적으로는 다 동작하는데 '종이' 가 보이지 않는다.

무슨 말이냐면, 글씨 / 테이블 / 배경 / 여백 등을 세팅하는 하얀색 공간 전체가 안보인다는 거.

안 보이고 나서 허탈해서 캡쳐도 안 해놔서 뭘 증빙자료를 내밀 수 있는게 없네.

암튼 Wine stable 8.0.2 에서도 아직은 안된다.

내 방법은 Whisky 를 이용한 방법이다.

https://getwhisky.app

PlayCover | Run iOS apps and games on your Apple Silicon Mac

PlayCover allows you to run iOS apps and games natively with keymapping on your Apple Silicon Mac!

playcover.io

whisky 를 다운받고, 새 Bottle 을 생성했다. Windows 버전은 만만한 10으로.

그리고, winetricks 버튼을 이용해서 사전에 설치해줘야할 모듈들을 하나씩 설치했다.

gdiplus, dotnet35, dotnet35sp1, dotnet40 을 하나씩 입력했다.

한번에 입력해도 된다는 것 같은데.. 나는 두개 이상 입력하니 오류가 발생해서 어쩔수 없었다.

암튼, 입력하면 터미널창이 열리면서 winetricks 가 실행되어 해당 패키지가 설치되었다.

dotnet35sp1 를 설치하는 데서 문제가 꽤 많이 발생했는데, cabextract 모듈을 brew 에서 받아야 하는 등의 문제가 발생했었다.

나는 직접 명령어로 해소하지 않고, 정상 동작하던 Wineskin winery 에서 winetricks 를 이용해 설치한 prefix location 폴더를 아예 통채로 복사해버렸다. 따라서 이 부분에 대한 해소법은 가지고 있지 않다.

그리고, 실행 버튼으로 install.exe 파일을 실행해서 한컴오피스를 설치. 라이선스 키 입력하고 어쩌구 저쩌구 설치 완료.

그럼 bottle 에 새로 설치된 exe 파일들이 몇개 뜬다. (업데이트 등도 같이 떴었는데 지금은 지운 상태.)

한컴에서 배포하는 한컴네오 패치를 설치를 꼭 해야 클립보드 버그를 해소할 수 있기 때문에

그 부분도 추가로 검색해서 다운 받아 설치하기.

다음은, 정상적으로 동작하는 command line 정보를 얻어내기 위해, 이용하지 않을 바로가기를 하나 만든다.

Hwp 파일 저 아이콘 우클릭 -> 설정 -> 아래쪽에 바로가기 만들기 를 하면 바로가기가 만들어진다.

만든 바로가기를 찾아 패키지 내용 보기 --> Contents --> MacOS --> launch 를 적당한 텍스트 에디터로 열기.

#!/bin/bash

WINEMSYNC=1 LC_ALL=ko_KR.UTF-8 WINEDEBUG=fixme-all DXVK_ASYNC=1 WINEPREFIX=/Users/yangzepa/Library/Containers/com.isaacmarovitz.Whisky/Bottles/B5E1F8F4-5E67-4796-9DF0-747220CC5C2B /Users/yangzepa/Library/Application\ Support/com.isaacmarovitz.Whisky/Libraries/Wine/bin/wine64 start /unix /Users/yangzepa/Library/Containers/com.isaacmarovitz.Whisky/Bottles/B5E1F8F4-5E67-4796-9DF0-747220CC5C2B/drive_c/Program\ Files\ $x86$/HNC/Office\ NEO/HOffice96/Bin/Hwp.exe

그럼 대강 이런 정도의 텍스트가 저장되어 있을 것이다. 이 텍스트만 따다 쓸꺼긴 한데, 아직 지우지 말기.

이제 automator 실행해서 새로운 문서 만들기.

응용 프로그램 -> 유틸리티 -> 셸 스크립트 실행

셸은 나는 bash 를 좋아하니 /bin/bash, 통과 입력은 인수 로 변경.

for f in "$@" 어저구 생기는데 싹 지워버리고, 저 텍스트를 복붙한다.

그리고 맨 마지막에

"${1//\//\\}" &>/dev/null &

를 이어 붙여 놓는다.

저 구문은, Mac OS 파일 문구인 /Users/어쩌구저쩌구/ 형식을, 윈도우 형식에서 열릴 수 있게 \Users\어쩌구저쩌구\ 로 바꿔주는 명령어이다.

그리고 뒤에 /dev/null & 은, 실행할 때 대기하라는 무지개 동그라미를 없애는 문구.

거의 다 왔다. 응용프로그램 폴더에 저장해 놓는다.

다시 응용프로그램에 와서, 방금 저장한 automator 에서 할 일이 2가지 정도 있다.

automator 결과물 우클릭 - 정보 가져오기 해서 열어 두고 일단 킵.

그리고 아까 whisky 의 바로가기 결과물 우클릭 - 정보 가져오기 해서 두개를 연다.

automator 로봇 아이콘이 맘에 안드니까, Hwp (whisky 바로가기) 에서 열린 창 맨 위의 아이콘 클릭 - cmd + C 후

automator 로봇 아이콘 클릭 - cmd + V 하면 아이콘이 대체된다. 예쓰. 이제 닫기.

이젠 whisky 결과물 삭제해도 됨.

다시, automator 우클릭 - 패키지 내용 보기 - contents - info.plist 를 텍스트 에디터로 수정.

지금 내 버전을 첨부한다.

<key>CFBundleDocumentTypes</key>

<array>

<dict>

<key>CFBundleTypeExtensions</key>

<array>

</array>

<key>CFBundleTypeName</key>

<string>HWP Document</string>

<key>CFBundleTypeIconFile</key>

<string>HWPNEO.icns</string>

<key>CFBundleTypeRole</key>

<string>Viewer</string>

<key>LSTypeIsPackage</key>

</dict>

</array>

string 이 * 로 되어 있는데, hwp 로 수정.

뭐 아이콘 수정, 문서 이름 수정 뭐 여러가지 더 할 수 있으니 그 부분은 알아서 추가로 할 것.

BundleTypeName, LSTypeIsPackage 정도만 수정/추가하면 됨.

아이콘은 적용해 봤는데 잘 안 바뀌는 듯. 나중에 방법을 찾아보도록 하고.

자 끝이다.

hwp 파일 아무거나 우클릭해서, 정보 가져오기 해서

다음으로 열기 를 지금 우리가 만든 걸로 바꿔놓으면 된다. 모두 변경 누르면 끝.

자, 이제 문서 다운받고 바로 더블클릭 하면, 한박자 쉬었다가 한컴네오 열리고 문서 수정 복붙 다 잘 된다.

wineskin winery 에서 한컴네오가 잘 열리는데,

winery wrapper 에서 외부 파일을 내부로 연결시키는 데 실패해서 이렇게 돌아옴.

wineskin wrapper 에서는 wine64, prefix, winetricks 가 다 정상 동작하는데

그걸 terminal 에서 다 링크해서 여는데, 왜 계속 에러가 발생하는지.

LR_PORT 오류, 아키텍처 틀리다는 오류 등 벼라별 오류가 다 나서 포기하고 whisky 로 돌아섰다.

대신 whisky 는 위에 이야기한 것 처럼 winetricks 설치 과정에서 오류가 발생한다.

개인적으로는 일단 wineskin winery 를 이용해, 위 블로그 분이 하란 대로 다 설치해서

winetricks, 폰트, 한컴까지 다 설치한 prefix 를 만들어 준비한 다음에,

whisky 에서 bottle 만들어서 그 bottle 의 prefix 위치에 싹 복사해넣어버리는 방법을 추천.

한컴네오 라이선스 다시 입력하라고 하는 창이 한번 뜨긴 하는데,

라이선스 키 입력해 주고 그 다음 창 오류메세지 (인터넷 어쩌구) 하는건 취소 눌러버리면 그 다음부턴 잘 동작한다.

재미로 구매한 Cosmo communicator 에 발등을 찍혔다.

TechToast — Sat, 6 Aug 2022 03:57:20 +0900

이전 모디아 개조 어쩌구 하면서 낑낑 매다가

.. 결국 시간에 부딛혀서

돈으로 해결하는 방법을 선택하고,

그 목표와 가장 근접한 기기인 Cosmo communicator 제품을 구매했다.

뭐 GPD Pocket 같은 다른 선택지도 있었지만,

윈도우 pc 계열에서는 배터리 관리도 그렇고

켜자마자 바로 화면에 노트를 할 수 있는 환경이 나오는 것이 주 목적이었는데

안드로이드가 더 좋은 선택일 것 같고, 조금 더 컴팩트해서 결정했다.

.. 그나저나 뭐 국내에 매물이 있어야 사든 말든 하지.

회사 본사 홈페이지에서 구매하려니 90만원 이상을 육박하는 금액을 제출해야 하고.

중고장터 사이트들을 두루두루 다 뒤져봐도 해당 제품이 매물로 올라오는 것이 없다.

뭐 별 수 있겠어, 이베이로 눈을 돌렸다.

300 파운드에 판매하고 있는 영국 제품을 구입.

배대지 통해서 받고, 관세는 5만원을 육박하는 돈을 지불했다. 구매가가 거의 53만원에 도달함. 쩝

받았더니, 역시 머리속에 설계했던 바로 그 그림이 그대로 그려졌다. 아주 맘에 든다.

하지만, 꽤 여러가지 문제점에 부딛혔다.

첫번 째 문제는 키보드 배열.

영국에서 구매했기에 영국형 자판일 줄 알았는데, 독일형 자판이다. Z와 Y 키보드 위치가 다르다.

뭐 이거 다른건 키보드 레이아웃을 영어식 / 한국식으로 바꾸면 해결될 문제긴 하지만

문제는 특수문자의 위치.

12345 등 숫자열 상에 있는 특수문자는 외웠다고 쳐도

fn 키와 조합하여 입력해야 하는 특수문자들은 더듬더듬 보고 입력해야 하는데..

그 배열의 특수문자 배치까지 머릿속에 외울 수는 없었다.

방법을 끙끙 매다 보니, Vimeo 에 이 회사에서 직접 올린 '키캡 교환법' 에 대한 비디오가 올라와 있었다.

https://vimeo.com/476402575

호오. 이 동영상이 있다는 건, 키캡을 별도로 구매할 수 있다는 말.

독일배치든 영국배치든 한국배치든, 키 배치의 절대값 위치가 일본배치처럼 독특하게 다른 것은 아니기에

키캡만 교체하면 한국어 배치로 키를 사용할 수 있다는 말이다.

근데 홈페이지를 뒤져봐도 키캡을 별도로 파는 데는 못 찾았다.

Vimeo 글에 리플도 달고, 관련 포럼에 질문 글도 올렸는데 방법을 찾지 못했다.

알리 등 여러 사이트에 검색해봐도 답은 없었다.

그래서.. 뭐.. 어쩔 수 없이...

본사의 Customer service 에 연락해서 한국어 키캡을 추가로 주문했다.

젠장. 영국내 배송비 49 파운드에, 배대지 비용으로 또 이중으로 돈이 청구된다.

아직 영국에서 오지 않았기에, 교체한 후에 추가 기술할 예정.

그리고, 두번째 문제는 펌웨어 버전.

구매자가 초기 구매자였는지, 굉장히 초기 버전의 펌웨어가 올라가 있었다.

v16 버전도 사실 완전 초기라고 보긴 어렵지만, 해당 버전에서 현시점 최신 버전인 v25 와는 거리가 멀다.

이런 소규모 중소기업 특성 상 자동 펌웨어 업데이트가 그다지 깔끔하게 동작하지 않았고,

특정 버전 이후부터는 설치되어 있는 안드로이드를 루팅한 후에야 설치가 가능한 펌웨어들이다.

그래서 일단 공식홈에 나와 있는 방법을 따라 펌웨어 업데이트를 시도했는데...

공식 홈에서 나온 리커버리 모드에서 수행할 수 있는 펌웨어 업데이트 기능이, 내 코스모에는 빠져있다.

.. 찾고 찾다 보니, 이 시점 이후 버전으로는 일반 패치 방식으로는 펌웨어 업데이트가 쉽지 않은 것 같다.

.. 에휴. 또 찾아서 해내 봐야지 뭐.

그래서 패기롭게 포럼에 질문 글을 올렸는데,

올리고 나서 보니... 최신 글 업데이트가 ㅁ ㅐ 우 느린 상태이더라.

뭐 이미 나온지 5년이 되어 가는 기기에 이렇게 열정적으로 뭘 하는 사람이 아직 남아있을 리 없다.

그런데 포럼 글을 둘러보니, 과거에 꽤 열정적으로 작업한 이력들이 남아 있는 것 같아 포럼글을 샅샅히 찾아보았다.

역시, 답은 있었다.

순서는 V16 -> V19 버전으로 롬플래쉬 -> V23 버전 업데이트 -> V25 버전 업데이트 순서이다.

v19 버전부터 저 메뉴가 정상적으로 생기기에, 일단 내가 가지고 있는 펌웨어 롬 버전을 v19 버전으로 강제 flashing 해야 한다.

그리곤 v23 버전으로 공식 홈페이지에 나와 있는 방법을 따라 업데이트, 하고,

v25는 v23의 핫픽스 버전 정도이기에, 추가 패치를 하는 느낌으로 업데이트 하면 되는 것으로 결론이 났다.

v19 플러쉬 할 롬 파일 : https://drive.google.com/file/d/1FHukLy_NNEYpGBq79xQhmTNwv1HNO4Jt/view?usp=sharing

V23 버전 : https://support.planetcom.co.uk/index.php/Cosmo_Android_Firmware_Manual_Installation (공식 사이트)

V25 버전 : https://support.planetcom.co.uk/index.php/Rooted_Android_For_Cosmo (공식 서포트 페이지)

미리 깔아둔 v19 는 v19 라는 폴더를 만들어 SD카드에 저장.

v23, v25 버전은 각각 cosmo-customos-installer 폴더 내부에 저장.

일단 v19 flushing은, 일본인 선배가 좋은 조언을 기입해 두었기에 따라 진행을 도전했다.

(https://www.oesf.org/forum/index.php?topic=36448.msg297113#msg297113)

TWRP 라는 방법을 이용하라는데, 안드로이드를 거의 써보지도 않았고, 루팅에 대해서는 관심도 없었어서

관련 키워드를 들어보지도 못해서, 인터넷을 찾아 공부를 했고

결국 커스텀 롬을 안드로이드 시스템에 부어주는 도구인 것으로 파악했다.

dd if= of= 방식은 맥 유저이기 때문에 익숙한 커맨드여서, 바로 롬을 확보하고 맥에 adb 를 설치하여 fastboot 으로 접근했다.

맥에서 adb 를 설치하기 위해 오랫만에 터미널을 열어서, 다음과 같은 명령어를 이용해서 twrp 파티션을 주입했다.

$ brew cask install android-platform-tools %ADB 설치
$ adb reboot bootloader %연결된 안드로이드를 부트로더 모드로 재부팅 : fastboot 형태로 재부팅됨
$ fastboot flush oem %OEM 이 걸려있기에, oem 을 일단 unlock 시켜준다. 이 명령어가 동작했음.
$ fastboot flush recovery unofficial-twrp-cosmo-20191214.img % 리커버리 영역에 twrp 를 주입.
$ fastboot reboot

롬 파일을 만들어 둔 선배가 공개한 사이트는 여기 : https://github.com/Treeki/unofficial-twrp-cosmo/releases

그리곤 재부팅 하고 나니, 뭔가 딸꾹 하다가 TWRP UI가 화면상에 떴다.

storage1 을 마운트 시키니, 관련 파일을 저장해 둔 SD카드가 접근이 가능했다.

그런데, 저 매뉴얼에서 나온것 처럼 adb shell 을 썼는데, 코스모에 쉘접속이 안되는 것이다.

뭔가 꼬였다 싶어 껐다 키려다가..

그래 뭐, 내용 똑같이 한글자 한글자 따라 치지 뭐. 하고 관련 명령어를 죽 기입했다.

하나하나 키보드로 쭉 치면서, '역시 특수문자가 너무 어렵구나' 를 다시한번 뼈저리게 느꼈다.

dd if=/auto0-1/v19/boot.img of=/dev/block/mmcblk0p30 bs=4096
dd if=/auto0-1/v19/cam_vpu1.img of=/dev/block/mmcblk0p22 bs=4096
dd if=/auto0-1/v19/cam_vpu2.img of=/dev/block/mmcblk0p23 bs=4096
dd if=/auto0-1/v19/cam_vpu3.img of=/dev/block/mmcblk0p24 bs=4096
dd if=/auto0-1/v19/dtbo.img of=/dev/block/mmcblk0p32 bs=4096
dd if=/auto0-1/v19/expdb.img of=/dev/block/mmcblk0p4 bs=4096
dd if=/auto0-1/v19/frp.img of=/dev/block/mmcblk0p5 bs=4096
dd if=/auto0-1/v19/lk.img of=/dev/block/mmcblk0p28 bs=4096
dd if=/auto0-1/v19/lk2.img of=/dev/block/mmcblk0p29 bs=4096
dd if=/auto0-1/v19/md1dsp.img of=/dev/block/mmcblk0p16 bs=4096
dd if=/auto0-1/v19/md1img.img of=/dev/block/mmcblk0p15 bs=4096
dd if=/auto0-1/v19/metadata.img of=/dev/block/mmcblk0p8 bs=4096
dd if=/auto0-1/v19/nvcfg.img of=/dev/block/mmcblk0p6 bs=4096
dd if=/auto0-1/v19/nvdata.img of=/dev/block/mmcblk0p7 bs=4096
dd if=/auto0-1/v19/para.img of=/dev/block/mmcblk0p3 bs=4096
dd if=/auto0-1/v19/persist.img of=/dev/block/mmcblk0p12 bs=4096
dd if=/auto0-1/v19/protect1.img of=/dev/block/mmcblk0p9 bs=4096
dd if=/auto0-1/v19/protect2.img of=/dev/block/mmcblk0p10 bs=4096
dd if=/auto0-1/v19/recovery.img of=/dev/block/mmcblk0p2 bs=4096
dd if=/auto0-1/v19/scp1.img of=/dev/block/mmcblk0p18 bs=4096
dd if=/auto0-1/v19/scp2.img of=/dev/block/mmcblk0p19 bs=4096
dd if=/auto0-1/v19/seccfg.img of=/dev/block/mmcblk0p11 bs=4096
dd if=/auto0-1/v19/spmfw.img of=/dev/block/mmcblk0p17 bs=4096
dd if=/auto0-1/v19/sspm_1.img of=/dev/block/mmcblk0p20 bs=4096
dd if=/auto0-1/v19/sspm_2.img of=/dev/block/mmcblk0p21 bs=4096
dd if=/auto0-1/v19/system.img of=/dev/block/mmcblk0p36 bs=4096
dd if=/auto0-1/v19/tee1.img of=/dev/block/mmcblk0p33 bs=4096
dd if=/auto0-1/v19/tee2.img of=/dev/block/mmcblk0p34 bs=4096
dd if=/auto0-1/v19/vendor.img of=/dev/block/mmcblk0p35 bs=4096
sync

그리고 재부팅하니, 평소보다 엄청 늦게 걸리다가 결국 v19 로 재부팅 성공.

바로 v23, v25는 공식 홈페이지에 나와 있는 방법으로 그대로 따라서 진행.

얼추절추 안드로이드 펌웨어는 해결했다.

그런데 큰 문제가 하나가 더 남아있다.

외부 화면에 대한 펌웨어도 따로 업데이트를 해줘야 하는데, 이게 여간 짜증나는 일이 아니다.

모든 단계에서 CoDi 를 정식 업데이트 프로그램으로 업데이트 해주면서 올라와야 하는데,

v25 에서 업데이트를 진행하니 중간단계를 스킵하는 과정에서 리소스 파일이 같이 패치가 되지가 않아

아래와 같은 그림으로만 나타났다.

그래서 일단 또 웹사이트에서 외부 디스플레이에 대한 펌웨어를 다운받았는데,

펌웨어 업데이트 프로그램에서 해당 펌웨어를 수동 업데이트 하려고 파일을 여는 순간

매번 crashed 하고 에러가 나버리는 것이다.

공식 프로그램이 이럴리가 없는데... 하면서 벼라별 짓을 다 해보고,

무슨 비행기모드 / 방해금지모드 같은 개소리를 줄줄 늘어놓는 걸

억지로 믿어주면서 테스트 해봐도 결국 계속 같은 오류로 업데이트가 불가능했다.

개소리1, 개소리2.

그래도 희망을 놓지 않고 계속 포럼을 하루종일 뒤진 결과,

희망찬 한 줄의 글을 찾았다.

아하.

Locale 의 변경 떄문에 /Download 폴더가 /다운로드 로 인식해서, 한글변환 주소를 인식 못하는 오류들 때문에 생겼을 가능성이 높았다.

그래서 별도로 받은 1.14 버전 펌웨어 파일을 안드로이드 루트 폴더에 복사해놓고 업데이트를 실행했더니

크래쉬 오류가 잡히고, 잘 펌웨어 업데이트가 완료 되었다.

(애초에 펌웨어 업데이트가 잘 안된다. fail 이 평균적으로 5번 이상 일어난다. 믿고 계속 해보는 수밖에 없다는 증언들.

그리고 추가 작업을 해 볼 수 있는 사이트도 발견했다.

http://ssipa.web.fc2.com/index_Cosmo_2.html#20220619

시간나면 나중에 더 작업해 봐야지.

다음 문제는, 한영 변환 문제,

의외로 쉽게 해결했다.

맨처음 켜면 나타나는 키보드 마법사 같은 거에서 한국, 한글을 눌러놓으면

물리 키보드 레이아웃이 "한글", "한글 (English)" 두개가 설치된다.

그런데 "한글" 레이아웃은 영어가 아예 입력이 안 되므로, 해당 레이아웃은 제외시키고 "한글 (English)" 만 남겨두었다.

소프트 키보드는 Planet keyboard 에서 GBoard 로 바꿔주었다.

(planet keyboard 는 자소분리 현상이 일어나서,ㅈㅏㅅㅗㅂㅜㄴㄹㅣ 같이 써진다.)

그리곤, 알키보드 apk 파일을 찾아서 별도로 설치해 주고 기본을 알키보드 apk 로 변환했다.

planet keyboard 를 gboard 로 안 바꾸고 가면, 알키보드를 삭제했다가 재 설치해야 해당 문제가 발생하지 않는다.

....

별 생각없이 구매한 기기 하나에,

일주일의 밤이 재미있게 불타버렸다.

다음은, 듀얼유심을 잘 써먹기 위해 알뜰폰 무료 요금제를 하나 가입해야지.

집 현관 게이트 통과 카드를 복사해 보자. (RFID, CUID)

TechToast — Tue, 2 Aug 2022 00:04:08 +0900

나름 유명한 브랜드 아파트에 살고 있다.

얼마전 현관 시스템을 통채로 다 변경해서, 정말 최신식의 출입 게이트로 변경되었다.

집에 발급된 2장의 카드키를 이용해서 출입구 문도 열 수 있고, 집의 도어락도 열 수 있으며

아파트 안에 있는 커뮤니티 센터에서 음식도 먹을 수 있고, 헬스장 출입도 가능하다.

그런데, 와이프가 카드키 맨날 들고 다니기 귀찮다고 한다. 핸드폰으로 띡 되었으면 좋겠다고.

그 의견에 전적으로 동의했고, 할 수 있는 방법을 찾아 헤맸다.

방법은 RFID 카드키 복사.

열심히 공부 및 시행착오를 한 결과를 공유한다.

RFID 카드 복사를 할 수 있는 프로토콜은 당연하게도 매우 여러가지가 있지만,

우리나라에서 활용되는 거의 대부분의 카드는 MIFARE Classic 1K 라는 형식이다.

해당 카드가 우리나라에서 주로 이용되는 보안카드 형식인 것으로 판단한다.

(예전에는 버스카드도 이 형식이었지만, 2010년을 기점으로

거의 대부분 해당 카드형식은 더이상 교통카드로는 이용되지 않는 듯 하다.)

복사할 수 있는 카드는 125KHz니 13.56MHz 니 주파수가 여러가지 있지만,

우리나라에서 월등히 쓰이는 형식은 13.56 MHz 인 것 같으므로 다른 것은 구태여 구매할 필요 없을 듯.

정확하지는 않지만, 문서 등을 보고 판단한 결과로는

RFID 의 구조는 하나의 큰 메모리 변수와, 그에 상응하는 UID 코드로 구성되어 있다.

RFID 에서 값을 저장하는 방식은 해당 RFID 칩/코일에 저장된 일정 길이의 문자열이 있고,

해당 문자열에 원하는 값 혹은 시리얼코드를 입력하여 저장하는 방식이다.

이 메모리 영역에 특정한 값이 랜덤하게 기입되어 있거나 특정 값을 기록할 수 있고,

RFID 가 다른 기기에 접촉했을 때, 이 메모리 안에 저장된 값이 반환되어 기기에서 읽어들이는 방식이다.

이해를 돕기 위해서 그림을 하나 추가했다.

각 모든 RFID 카드에는 UID 가 이미 랜덤한 값으로 부여되어 있으며,

MEMORY 영역에는 RFID Writer 를 이용하여 원하는 특정 값을 기입하게 되어 있다.

하지만 UID 는 "일반적인 상황에서는" 변경이 되지 않는다.

그러나, 추가적으로 CUID 라는 형식의 카드를 발견했다.

해당 카드는 평소에는 일반 UID 카드처럼 동작하나,

(CUID Writing 기능을 가지고 있는) UID Writer 에서 특정한 주파수로 추가적인 전류를 더 흘려보내면

UID 영역에 대한 writing 도 가능한 코일이라고 이해했다.

필자가 확보한 UID, CUID 스티커형 카드.

일반적이고 저렴한, 카드 접촉식 기기는 UID 형태의 카드로만 복사해도 대부분 인식한다.

즉, RFID 카드의 "메모리 영역" 값만 다른 카드에 복사해도 정상적으로 인식한다.

대부분의 집 도어락, RFID 접촉식 출입구, 임직원 출입카드 등이 이에 속한다.

그러나, 우리 아파트에 설치된 신식 출입구의 경우 UID 까지 읽어들이는 것 같다.

단순 UID 카드로 메모리 영역만 복사한 카드로는 출입이 되지 않으며,

위에 명시한 CUID 형식으로 UID 정보까지도 똑같이 복사가 되어야 출입문이 개방된다.

필자가 이용한 RFID Reader / Writer 들이다. 좌측의 검은것이 컴퓨터와 연결하여 정상적으로 CUID 까지 복사할 수 있었고, 우측의 흰색/파란색 버튼의 조잡한 기기는 가격은 더 비쌌으나 CUID 복사는 불가능했다.

필자가 구매한 제품의 알리익스프레스 링크를 남긴다. 이건 광고 아니니까 상관없다.

동일한 다른 더 저렴한 제품이 있을지도 모르니 추가 검색은 필수.

18789.0₩ 30% OFF|RFID 듀얼 주파수 복사기 NFC 스마트 칩 카드 암호화 리더 13.56Mhz 키 복사기 125Khz 토

Smarter Shopping, Better Living! Aliexpress.com

ko.aliexpress.com

더불어 아래가 필자가 구매한 CUID 스티커이다.

동일한 제품 중 더 저렴한 것도 많고 다른 디자인도 있으니 추가 검색은 필수.

6492.0₩ 5% OFF|13.56Mhz CUID RFID UID 안티 메탈 간섭 키 태그 스티커, 레이블 카드 변경 가능 블록 0 NFC m

Smarter Shopping, Better Living! Aliexpress.com

ko.aliexpress.com

필자가 이용한 RFID Reader / Writer 와 연동되는 프로그램 화면 캡쳐이다.

( USB 로 컴퓨터에 연결하면 별도의 외장 드라이브 같은게 추가로 생기며, 해당 링크를 이용해서 인터넷에서 다운받을 수 있었다.)

위 프로그램에서 주로 이용되었던 것은 크게 5~6개의 버튼이 이용되었다.

위에 명시한, 일반적인 형태의 도어락/출입카드의 복사는 주황색 화살표가 가리키는 Card number / Write card 로 읽어들이고 복사를 진행할 수 있고, CUID 에 대한 기록은 Write CUID Card 버튼을 눌러 저장할 수 있었다.

- Start decoding 을 통해 카드의 모든 영역에 저장된 메모리 값을 다 읽어올 수 있었다. 단 내가 가진 카드는 별도의 어려운 암호화가 진행되어 있지 않은 카드기에 쉽게 모든 메모리영역의 데이터를 읽어올 수 있었는데, 신용카드 등을 올려놓고 start decoding 버튼을 누르면 좀처럼 읽어오는 작업을 못 하는 것 같다.

- Card number 버튼을 통해 주로 저장되는 앞의 14바이트 정도의 값을 읽어오고, 나머지 부분은 알아서 채우는 기능인 듯 하다. 앞의 14바이트 정도가 주로 이용되는 카드번호인 것 같아 이런 기능이 있는 것 같으며, 암호화가 되었다고 하더라도 돌려주는 값의 영역인 것으로 이해했다.

- Write card 버튼은, 방금 읽어들인 정보를 카드에 기록하는 형식이다. card number 혹은 start decoding 버튼을 통해 읽어들인 카드의 타입으로 그대로 저장해주는 기능 같은데, 내가 테스트 했을 때는 대부분 UID 형태로만 저장했다. 즉, 아래 Write UID card 버튼과 매번 동일한 기능으로 동작했다.

- Write UID Card / Write MF1 Card 버튼은 위에 명시한대로 UID 카드의 메모리 영역을 저장하는 기능 같고, MF1 버튼은 MIFARE classic 1k 타입으로 저장하는 기능 같다. (이부분은 정확하지 않음)

- Write CUID card 버튼으로, CUID 형태의 카드에 값을 기록할 수 있었다. 육안상이나 메모리창에 나오는 값의 비교로는 복사가 잘 되었는지 안 되었는지 판단할 수 없지만, 복사가 정상적으로 되었을 경우아 안되었을 경우의 메세지가 달라 그걸로 확인할 수 있었다. 아래는 CUID 카드가 아닌 일반 UID 카드를 인식시킨 상태에서 Write CUID 버튼을 눌렀을 때 나오는 메세지이다.

복사가 잘 되었을 경우와 안되었을 경우의 메세지가 다르다.

이 방법으로 필자는 정상적으로 출입문과 도어락, 커뮤니티센터 출입까지 잘 되는 카드를 복사했다.

아래는 테스트 영상.

캡틴아메리카 모양으로 되어있는 것은 CUID 카드가 아니고, 검은색 카드만 CUID 이다.

(CUID 카드라고 샀는데 테스트해보니까 아니어서 조금 화딱지가 났다)

https://www.youtube.com/watch?v=preqVvFtLGs

일반 UID 형태의 복사를 해봤는데도 출입문 개방이 안 된다면, CUID 카드를 추가로 구입해서 시도해보길 추천한다.

특히, 개인 신용카드를 등록해야 정상적으로 출입이 가능하되, 삼성페이/스마트폰 NFC 태깅으로는 등록할 수 없는 경우 대부분 이 형식을 띄고 있을 가능성이 높으므로 이 방식을 테스트해 보는 걸 추천한다.

VR로 업무용 모니터를 대체해 보자 - 1. Oculus Quest 2

TechToast — Fri, 15 Apr 2022 23:43:21 +0900

어렸을 때의 꿈.

공중에 떠 있는 가상 화면으로 무언가 일 할 수 있는 환경.

스타워즈 에서도, 어메이징 스파이더맨 에서도, 아이언맨도 가지고 있는 그런 것이 쓰고 싶었다.

뭐, 언제까지 꿈으로 남아 있겠지만 말이지.

그런데, 무심코 유투브 알고리즘을 타고 흘러가던 중에

Immersed VR 이라는 것을 갑자기 발견했다.

https://youtu.be/meHqf86EGfI

호옹이?

에이, 뭐 거품 잔뜩 들어간 홍보영상 이겠거니.

몇개의 영상을 더 검색해 봤다.

https://youtu.be/1TLC2tdImZ0

워.

정신을 차려보니, 오큘러스 퀘스트 2를 손에 들고 있다.

현재 테스트 4일 째.

익숙해짐의 단계를 슬슬 지나고 나니, 엄청나게 큰 만족도가 밀려오고 있다.

본격적으로 자료를 정리해서 포스팅을 해 볼 예정.