BakBiseo

블로그

  • 20년 된 니콘 D70으로 별 찍기 — “잘 찍히면 안 된다”는 발상의 전환

    치과의사가 낡은 DSLR로 별 사진에 입문한 이야기. 장비 경쟁 대신 안시 재현이라는 목표를 세웠더니, 오히려 오래된 카메라가 정답이었다.

    나는 왜 천체사진에 입문하지 못했나

    별 보는 걸 오래 좋아했다.

    그러다 보니 망원경도 몇 개 있다. 언젠가 나도 천체 사진에 도전 할 거라는 생각에 장비 욕심이 더해져 꽤 쓸 만하다는 아스카103 망원경도 샀다. 하모닉 적도의 와 삼각대도 틈틈히 장만했다.

    그런데 정작 사진은 못 찍고 있었다.

    이유는 단순했다. 천체 사진 커뮤니티에서 보이는 사진들이 너무 대단했다.그리고 그 뒤에 숨은 엄청난 장비 투자와 시간을 투입 해야 한다는 걸 알고 나니…

    “잘 찍기”가 아니라 “눈으로 본 느낌”을 남기자

    어느 날 발상을 바꿨다.

    작품 사진이 목표가 아니라 내가 가진 물건으로 눈에 비치는 느낌을 기록으로 남기고 전달하기로

    오리온 대성운을 처음 눈으로 봤을 때의 그 희미한 솜뭉치. 그걸 사진으로 남기고 싶었다. 작품이 아니라 기록으로.

    이게 **안시 재현(眼視 再現)**이라는 개념이다.

    안시(眼視)란 말 그대로 눈으로 보는 것. 안시 재현은 망원경으로 눈에 보이는 느낌을 최대한 사진으로 재현하는 것이다.

    이 목표로 방향을 잡자마자, 가지고 있던 낡은 카메라들이 달리 보이기 시작했다.

    가진 장비를 다시 봤다

    내 손에 있는 것들을 정리해봤다.

    카메라: 니콘 D70 (CCD, 600만 화소, 2004년식) + 니콘 D7000 (CMOS, 1600만 화소,2011년식)

    망원경/렌즈: 아스카103 굴절 망원경, 아버지 물려받은 니콘 80~200mm 줌렌즈, 레오80

    적도의: 하모닉 적도의,EQ5 pro

    전형적인 천체사진 유튜버 시각에서 보면 “D70은 구형이니 D7000 써야지”가 정답이다.

    근데 안시 재현 목표에서 보면 반대다.

    D70이 D7000보다 나은 이유 — 이걸 몰랐다

    D7000은 좋은 카메라다. ISO 성능도 뛰어나고, 화소도 많고, 저조도 성능도 훨씬 낫다. (2011년 구입)

    그게 문제다.

    D7000으로 찍으면 눈에 보이지 않던 것까지 나온다. 성운의 구조가 드러나고, 색이 살아나고, 디테일이 넘쳐난다.

    찍고 나서 “이렇게 안 보이는데?” 하게 된다.

    [이미지 삽입: D70과 D7000 비교 예시 이미지 또는 도식]

    반면 D70은 CCD 센서라 노이즈가 많고, 화소는 600만에 불과하고, ISO 1600이 사실상 한계다.

    안시 재현 목적에서 보면:

    • 어둡게 나온다 → 눈으로 본 밝기 한계에 가깝다
    • 디테일이 제한된다 → 눈으로 본 느낌에 가깝다
    • 노이즈가 있다 → 오히려 아날로그 질감에 가깝다

    “덜 찍히는 게 정답”이었다.

    렌즈 선택 — 망원경 대신 200mm가 먼저

    아스카103이 있으니 그걸 써야 하나 고민했다. 또는 소비를 통한 스트레스 해소로 레드캣51도 틈틈이 노려본다.

    하지만 니콘 80~200mm 줌렌즈의 200mm가 먼저다.

    이유는 시야각이다. 안시 재현에서 너무 좁은 시야는 오히려 눈으로 본 느낌과 멀어진다. 200mm는 오리온자리 같은 대형 천체를 화면에 적당히 담으면서도, 눈으로 본 느낌과 가장 가까운 시야를 준다.

    500mm 이상이 되면 확대가 과해진다. 안시로 그렇게 보이지 않는다.

    아스카103은 더 밝고 크게 찍히지만 — 그건 이미 “눈보다 과장된” 영역이다. 안시 재현 입문으로는 200mm가 더 솔직하다.

    RedCat 51 같은 전용 천체 렌즈는 필요 없다

    천체사진 입문자들이 자주 보게 되는 장비 중 하나가 RedCat 51이다.

    별을 정확한 점으로 찍고, 색수차를 잡고, 화면 가장자리까지 균일하게 담는다. 장노출 스택을 전제로 설계된 “과학적 정확 + 미적 완성” 장비다.

    내 목표와는 방향이 완전히 다르다.

    안시 재현은 오히려 반대를 원한다.

    눈으로 보면 별이 그렇게 선명하지 않다. 성운의 색도 거의 보이지 않는다. 디테일도, 밝기도 제한된다.

    RedCat은 그걸 다 잡아주는 장비다. 즉, 내 목표에는 “너무 좋은” 장비다.

    [이미지 삽입: RedCat 51 사진 또는 비교 도식]

    정리 — 내 세팅 방향

    결국 이렇게 됐다.

    안시 재현 메인 세팅

    • 카메라: 니콘 D70
    • 렌즈: 80~200mm 줌, 200mm 고정
    • ISO: 400~800
    • 노출: 짧게
    • 스택: 거의 안 함
    • 적도의: 하모닉 적도의로 트래킹만

    기록 + 공유용 세팅 (나중에)

    • 카메라: 니콘 D7000
    • 망원경: 아스카103
    • ISO: 800~1600
    • 약간의 스택 허용

    둘 다 가지고 있으니 용도를 나눠 쓰는 게 최선이다.

    오늘 당장 해볼 것

    아직 첫 촬영을 못 했다.

    그래도 지금 할 수 있는 건 있다. D70에 200mm 렌즈를 달고 하모닉 적도의 위에 올려놓는 것. 세팅하고 밤을 기다리는 것.

    목표를 바꿨더니 이미 가진 것으로 시작할 수 있게 됐다.

    장비 경쟁을 포기하는 순간, 이미 충분했다.

    일반인에게 실제 망원경으로 밤 하늘을 보면 어떻게 보이는지 그걸 보여준다는 것도 의미가 있다.

  • 일반인이 구현한 RAG식 지식 관리 방법: 책 OCR과 book_materials 폴더 활용법

    제미나이를 OCR 전용처럼 활용해 책 텍스트를 추출하고, book_materials 폴더에 쌓아 준 RAG 방식으로 검색·정리·집필에 활용하는 실전 방법을 소개합니다.

    책을 읽다가 “이 설명은 나중에 꼭 다시 써먹고 싶다”는 순간이 있다. 특히 로봇 개발, 아두이노, 전자회로처럼 개념이 계속 쌓이는 분야는 좋은 설명과 정확한 문장을 텍스트 자산으로 모아두는 것이 큰 힘이 된다.

    그래서 나는 책 페이지를 사진으로 찍고, 제미나이를 OCR 전용처럼 사용해 텍스트를 추출한 뒤, 그 결과를 book_materials 폴더에 저장하는 방식을 만들었다. 복잡한 데이터베이스나 어려운 서버 구축 없이도 일반인이 충분히 구현할 수 있는 현실적인 RAG식 지식 관리 방법이다.

    제미나이를 OCR 전용처럼 사용한 이유

    생성형 AI는 원래 번역, 요약, 설명, 제안까지 함께 하려는 성향이 있다. 하지만 책 텍스트를 뽑는 작업에서는 이런 기능이 오히려 방해가 된다. 내가 원하는 것은 해설이 아니라 원문 그대로의 텍스트이기 때문이다.

    그래서 일반 대화용 채팅과 분리된 OCR 전용 채팅방을 만들고, 항상 같은 프롬프트를 사용해 텍스트만 출력하도록 규칙을 고정했다. 이렇게 하면 제미나이를 완전히 다른 서비스로 바꾸지 않아도, 사실상 책 OCR 전용 도구처럼 활용할 수 있다.

    💡 솔직히 말하면: 제미나이3가 처음 나왔을 때는 정말 ChatGPT보다 뛰어났다. 그래서 26년 초에 1년 구독을 했는데, 지금 3월 말 기준으로는 성능도 떨어지고 창의성도 없고 답변도 제일 느리다. 구독료가 아까워서 “뽕을 뽑자”는 마음으로 OCR 전용으로 굴리기 시작한 게 숨은 이유다. 🙂

    OCR 전용 운영 방식

    1. 책 페이지 사진 업로드
    2. OCR 전용 프롬프트 고정 사용
    3. 번역, 요약, 해설 없이 텍스트만 추출
    4. 실제 인쇄 페이지 번호 유지
    5. 추출 결과를 book_materials 폴더에 저장

    핵심은 생성형 AI의 자유도를 줄이고, 출력 형식을 강하게 고정하는 것이다. OCR 작업에서는 창의성보다 형식 안정성이 훨씬 중요하기 때문이다.

    실제로 사용한 OCR 전용 프롬프트

    아래는 실제 운영에서 사용한 압축형 프롬프트다. 길고 복잡한 지시보다, 핵심 규칙을 짧고 강하게 주는 편이 더 안정적으로 동작했다.

    OCR 전용 프롬프트

    지금부터 이 방은 전문 OCR 텍스트 추출방이다. 내가 이미지를 올리면 설명 없이 텍스트만 추출하라.

업로드한 이미지는 책 페이지 사진이다.

목표:
사진 속 텍스트를 OCR로 추출해 복사 가능한 순수 텍스트로만 출력한다.

규칙:
- 번역, 요약, 해설, 재작성, 질문, 안내문, 인사말, 마무리 멘트, 추가 제안 금지
- 오직 추출된 텍스트만 출력
- 여러 페이지면 사진 속 실제 인쇄 페이지 번호로만 구분 (예: [27], [28])
- 페이지 번호가 안 보이면 [페이지번호확인불가]
- 판독 안 되는 부분만 [판독불가]
- 원문 언어 그대로 유지
- 문단, 목록, 수식, 기호, 숫자, 단위, 그림 캡션은 가능한 한 원형 유지
- 러닝헤더와 쪽번호가 보이면 원문 그대로 유지, 임의로 재배열하지 말 것
- markdown 기호와 코드블록 사용 금지

중요:
응답의 첫 글자부터 마지막 글자까지 OCR 추출 결과만 있어야 한다.
설명이나 코멘트가 한 줄이라도 들어가면 실패다.
사진이 올라오기 전에는 아무것도 출력하지 말고 대기하라.

    아래는 실제 운영 화면이다. 채팅방 이름을 “OCR 텍스트 추출 규칙 설정” 으로 고정해 두고, 책 페이지 사진을 올리면 페이지 번호와 함께 텍스트만 깔끔하게 출력된다.

    이 프롬프트의 핵심은 “무엇을 해라”보다 “무엇을 하지 마라”를 분명히 정하는 데 있다.

    왜 book_materials 폴더를 만들었나

    책에서 중요한 내용을 발견해도 메모 앱이나 여러 문서에 흩어 놓으면, 시간이 지나면서 다시 찾기 어려워진다. 그래서 나는 책 기반 텍스트 자산을 모으는 전용 폴더를 따로 만들었다. 그 폴더가 바로 book_materials다.

    이 폴더는 단순한 저장 공간이 아니다. 책에서 추출한 텍스트를 장기적으로 축적하고, 필요할 때 다시 꺼내 활용하기 위한 지식 자산 저장소다.

    book_materials 폴더의 역할

    • 책에서 추출한 텍스트를 체계적으로 저장
    • 로봇 개발과 전자회로 학습의 참고 자료로 활용
    • 블로그 글과 책 원고의 재료로 재사용
    • 페이지순, 주제순으로 다시 정리 가능

    실제 폴더 구조는 이렇게 운영한다.

    book_materials/
  아두이노_기초_p22-35.txt
  전자회로_입문_p88-91.txt
  링크드라이브_설계참고_p44-50.txt

    파일명에 책 이름과 페이지 범위를 넣어두면, 나중에 검색할 때 어느 책 어느 부분인지 바로 파악할 수 있다. 읽고 지나가는 정보가 아니라 다시 꺼내 쓸 수 있는 자산으로 바꾸는 구조다.

    이 방식이 준 RAG인 이유

    RAG(Retrieval-Augmented Generation)는 필요한 문서를 검색하고, 그 안에서 관련 내용을 꺼내 근거 기반으로 답을 만드는 구조를 말한다. 쉽게 말해 “내가 쌓아둔 문서를 AI가 검색해서 답하게 만드는 방식” 이다.

    현재 내 방식은 정식 벡터 데이터베이스나 자동 인덱싱까지는 아니다. 하지만 텍스트를 쌓아두고, 필요할 때 관련 내용을 검색해 꺼내고, 그 원문을 기반으로 설명과 정리를 만든다는 점에서 충분히 준(準) RAG라고 볼 수 있다.

    내가 지금 할 수 있는 활용 방식

    • 특정 개념 설명 다시 구성
    • 초보자용 문장으로 재설명
    • 블로그 글 재료 추출
    • 책 원고용 문장 재료 정리
    • 비슷한 내용을 주제별로 묶기
    • 여러 책 내용을 비교 정리하기

    완전한 RAG는 아니어도, 실사용 관점에서는 이미 문서 기반 검색형 에이전트처럼 작동한다.

    진짜 RAG는 언제 필요해질까

    처음부터 복잡한 시스템을 만들 필요는 없다. 책 몇 권, 수십 권 수준에서는 폴더 구조와 텍스트 파일만 잘 쌓아도 충분히 활용할 수 있다. 오히려 너무 일찍 RAG를 만들면 관리 포인트만 늘어나고 운영이 복잡해질 수 있다.

    RAG가 필요한 시점

    • 문서가 너무 많아져 직접 찾는 시간이 커질 때
    • 여러 책을 교차 비교하는 질문이 많아질 때
    • 검색, 분류, 요약, 근거 첨부까지 자동화하고 싶을 때

    지금은 가볍게 시작하고, 자료량과 질문 복잡도가 커지면 그때 정식 RAG를 붙이면 된다.

    지금 단계에서 가장 현실적인 선택

    지금 단계에서 중요한 것은 거창한 시스템보다 정확한 원문을 꾸준히 축적하는 일이다. 이미지 원본은 용량이 크지만, 텍스트 파일 자체는 생각보다 매우 가볍다. 일반적인 책 수십 권 분량도 텍스트 기준으로는 큰 부담이 되지 않는다. 내 맥미니 M4 기본 256GB라면 전혀 걱정 없다.

    현재 최적 전략

    1. 제미나이 OCR 전용 채팅방 생성 → 프롬프트 고정
    2. 책 페이지 사진 업로드 → 텍스트 추출
    3. 추출 텍스트를 book_materials에 파일명 규칙대로 저장
    4. 필요할 때 검색, 검수, 정리, 재활용
    5. 문서량과 질문 복잡도가 커지면 RAG 도입 검토

    이 방식의 장점은 지금 바로 시작할 수 있고, 나중에 더 큰 시스템으로 확장하기도 쉽다는 점이다.

    결론

    책을 읽고 끝내는 것과, 책을 지식 자산으로 바꾸는 것은 완전히 다르다. 제미나이를 OCR 전용으로 사용하면 텍스트 추출 속도를 높일 수 있고, book_materials 폴더에 그 결과를 쌓아두면 설명, 집필, 개발 판단에 계속 재사용할 수 있다.

    아직은 정식 RAG까지 갈 필요는 없다. 하지만 지금 쌓는 텍스트들은 분명히 미래의 RAG 자산이 된다. 결국 중요한 것은 화려한 기술보다, 정확한 원문을 꾸준히 축적하는 운영 습관이다.

    지금 바로 제미나이에서 채팅방 하나 새로 만들고, 위 프롬프트를 첫 메시지로 붙여넣기해 보세요. 그게 시작입니다.

  • 일반인이 구현한 RAG식 지식 관리 방법: 책 OCR과 북메티리얼 폴더 활용법


    beginner-rag-book-ocr-book-materials


    제미나이를 OCR 전용처럼 활용해 책 텍스트를 추출하고, 북메티리얼 폴더에 쌓아 준 RAG 방식으로 검색·정리·집필에 활용하는 실전 방법을 소개합니다.

    책을 읽다가 “이 설명은 나중에 꼭 다시 써먹고 싶다”는 순간이 있다. 특히 로봇 개발, 아두이노, 전자회로처럼 개념이 계속 쌓이는 분야는 좋은 설명과 정확한 문장을 텍스트 자산으로 모아두는 것이 큰 힘이 된다.

    그래서 나는 책 페이지를 사진으로 찍고, 제미나이를 OCR 전용처럼 사용해 텍스트를 추출한 뒤, 그 결과를 book_materials 폴더에 저장하는 방식을 만들었다. 이 방식은 복잡한 데이터베이스나 어려운 서버 구축 없이도, 일반인이 충분히 구현할 수 있는 현실적인 RAG식 지식 관리 방법이다.

    제미나이를 OCR 전용처럼 사용한 이유

    생성형 AI는 원래 번역, 요약, 설명, 제안까지 함께 하려는 성향이 있다. 하지만 책 텍스트를 뽑는 작업에서는 이런 기능이 오히려 방해가 된다. 내가 원하는 것은 해설이 아니라 원문 그대로의 텍스트이기 때문이다.

    그래서 일반 대화용 채팅과 분리된 OCR 전용 채팅방을 만들고, 항상 같은 프롬프트를 사용해 텍스트만 출력하도록 규칙을 고정했다. 이렇게 하면 제미나이를 완전히 다른 서비스로 바꾸지 않아도, 사실상 책 OCR 전용 도구처럼 활용할 수 있다.

    쉿 ~진짜 숨은 이유는 제미나이3가 나왔을때는 정말 챗지피티 보다 뛰었났다. 그래서 26년 초에 일년 구독을 했는데 지금 3월 말 현재 제일 구리다. 성능는 떨어지고 창의성도 없고 답변도 제일 느리다. 그래서 구독료가 아까워 제미나이 구독료로 뽕을 뽑고자 한게 숨은 의도이다 🙂

    OCR 전용 운영 방식

    • 책 페이지 사진 업로드
    • OCR 전용 프롬프트 고정 사용
    • 번역, 요약, 해설 없이 텍스트만 추출
    • 실제 인쇄 페이지 번호 유지
    • 추출 결과를 북메티리얼 폴더에 저장

    핵심은 생성형 AI의 자유도를 줄이고, 출력 형식을 강하게 고정하는 것이다.

    실제로 사용한 OCR 전용 프롬프트

    아래는 실제 운영에서 사용한 압축형 프롬프트다. 길고 복잡한 지시보다, 핵심 규칙을 짧고 강하게 주는 편이 더 안정적으로 동작했다.

    OCR 전용 프롬프트

    지금부터 이 방은 전문 OCR 텍스트 추출방이다. 내가 이미지를 올리면 설명 없이 텍스트만 추출하라.

    업로드한 이미지는 책 페이지 사진이다.

    목표:
    사진 속 텍스트를 OCR로 추출해 복사 가능한 순수 텍스트로만 출력한다.

    규칙:

    • 번역, 요약, 해설, 재작성, 질문, 안내문, 인사말, 마무리 멘트, 추가 제안 금지
    • 오직 추출된 텍스트만 출력
    • 여러 페이지면 사진 속 실제 인쇄 페이지 번호로만 구분
    • 예: [27], [28]
    • 페이지 번호가 안 보이면 [페이지번호확인불가]
    • 판독 안 되는 부분만 [판독불가]
    • 원문 언어 그대로 유지
    • 문단, 목록, 수식, 기호, 숫자, 단위, 그림 캡션은 가능한 한 원형 유지
    • 러닝헤더와 쪽번호가 보이면 원문 그대로 유지, 임의로 재배열하지 말 것
    • markdown 기호와 코드블록 사용 금지

    중요:
    응답의 첫 글자부터 마지막 글자까지 OCR 추출 결과만 있어야 한다.
    설명이나 코멘트가 한 줄이라도 들어가면 실패다.
    사진이 올라오기 전에는 아무것도 출력하지 말고 대기하라.

    이 프롬프트의 핵심은 “무엇을 해라”보다 “무엇을 하지 마라”를 분명히 정하는 데 있다. OCR 작업에서는 창의성보다 형식 안정성이 훨씬 중요하기 때문이다.

    왜 북메티리얼 폴더를 만들었나

    책에서 중요한 내용을 발견해도 메모 앱이나 여러 문서에 흩어 놓으면, 시간이 지나면서 다시 찾기 어려워진다. 그래서 나는 책 기반 텍스트 자산을 모으는 전용 폴더를 따로 만들었다. 그 폴더가 바로 book_materials다.

    이 폴더는 단순한 저장 공간이 아니다. 책에서 추출한 텍스트를 장기적으로 축적하고, 필요할 때 다시 꺼내 활용하기 위한 지식 자산 저장소다.

    북메티리얼 폴더의 역할

    • 책에서 추출한 텍스트를 체계적으로 저장
    • 로봇 개발과 전자회로 학습의 참고 자료로 활용
    • 블로그 글과 책 원고의 재료로 재사용
    • 페이지순, 주제순으로 다시 정리 가능

    즉, 읽고 지나가는 정보가 아니라 다시 꺼내 쓸 수 있는 자산으로 바꾸는 구조다.

    이 방식이 준 RAG인 이유

    RAG는 보통 필요한 문서를 검색하고, 그 안에서 관련 내용을 꺼내 근거 기반으로 답을 만드는 구조를 말한다. 전문가들이 RAG를 쓰는 이유는 문서가 많아질수록 모든 내용을 한 번에 읽을 수 없기 때문이다.

    현재 내가 운영하는 방식은 정식 벡터 데이터베이스나 자동 인덱싱까지는 아니다. 하지만 텍스트를 쌓아두고, 필요할 때 관련 내용을 검색해 꺼내고, 그 원문을 기반으로 설명과 정리를 만든다는 점에서 충분히 준 RAG라고 볼 수 있다.

    내가 지금 할 수 있는 활용 방식

    • 특정 개념 설명 다시 구성
    • 초보자용 문장으로 재설명
    • 블로그 글 재료 추출
    • 책 원고용 문장 재료 정리
    • 비슷한 내용을 주제별로 묶기
    • 여러 책 내용을 비교 정리하기

    즉, 완전한 RAG는 아니어도, 실사용 관점에서는 이미 문서 기반 검색형 에이전트처럼 작동한다.

    진짜 RAG는 언제 필요해질까

    처음부터 복잡한 시스템을 만들 필요는 없다. 책 몇 권, 수십 권 수준에서는 폴더 구조와 텍스트 파일만 잘 쌓아도 충분히 활용할 수 있다. 오히려 너무 일찍 RAG를 만들면 관리 포인트만 늘어나고 운영이 복잡해질 수 있다.

    RAG가 필요한 시점

    • 문서가 너무 많아져 직접 찾는 시간이 커질 때
    • 여러 책을 교차 비교하는 질문이 많아질 때
    • 검색, 분류, 요약, 근거 첨부까지 자동화하고 싶을 때

    즉, 지금은 가볍게 시작하고, 자료량과 질문 복잡도가 커지면 그때 정식 RAG를 붙이면 된다.

    지금 단계에서 가장 현실적인 선택

    지금 단계에서 중요한 것은 거창한 시스템보다 정확한 원문을 꾸준히 축적하는 일이다. 이미지 원본은 용량이 크지만, 텍스트 파일 자체는 생각보다 매우 가볍다. 일반적인 책 수십 권 분량도 텍스트 기준으로는 큰 부담이 되지 않는다. 참고로 내 맥미니 m4 기본은 저장 공간이 256GB이다. 내 자비스가 충분하다고 한다 🙂

    현재 최적 전략

    • 제미나이로 OCR 전용 추출 수행
    • 추출 텍스트를 book_materials에 저장
    • 필요할 때 검색, 검수, 정리, 재활용
    • 문서량과 질문 복잡도가 커지면 RAG 도입 검토

    이 방식의 장점은 지금 바로 시작할 수 있고, 나중에 더 큰 시스템으로 확장하기도 쉽다는 점이다.

    결론

    책을 읽고 끝내는 것과, 책을 지식 자산으로 바꾸는 것은 완전히 다르다. 제미나이를 OCR 전용처럼 사용하면 텍스트 추출 속도를 높일 수 있고, book_materials 폴더에 그 결과를 쌓아두면 설명, 집필, 개발 판단에 계속 재사용할 수 있다.

    아직은 정식 RAG까지 갈 필요는 없다. 하지만 지금 쌓는 텍스트들은 분명히 미래의 RAG 자산이 된다. 결국 중요한 것은 화려한 기술보다, 정확한 원문을 꾸준히 축적하는 운영 습관이다. 일반인이 나도 서점에서 AI관련 책들을 잔뜩 사다가 보다보니 이런 RAG라는 것도 접하고 이렇게 나름 활용해보게 된다.

    오늘도 내 자비스 시스템은 이렇게 진보한다!

  • [자비스 프로젝트] AI 에이전트 폴더 구조 최적화: 점점 비대해지는 규칙… 그래서

    나를 도와 로봇제작을 도와주는 자비스가 이제는 책 저술도 도와주게 진화했네요:)

    그래서 문득 시스템 최적화나 구조의 최적화을 화두로 던져 보았습니다.

    AI 에이전트 시스템(OpenClaw )을 직접 구축하다 보면, 어느 순간 SYSTEM.md 파일 하나가 감당할 수 없을 정도로 무거워지는 시점이 옵니다. 오늘은 제가 구축 중인 **’자비스(JARVIS) 시스템’**의 효율을 극대화하기 위해, ‘파일 수’가 아닌 ‘읽기 경로’를 최적화한 폴더 구조에 대해 고민해 본걸 기록합니다.

    1. 기존 구조의 한계: “단순함 속에 숨은 무거움”

    처음에는 관리하기 편하도록 최소한의 파일로 시작했습니다. 하지만 시스템이 고도화될수록 JARVIS_SYSTEM.md 파일 하나에 모든 규칙과 프롬프트가 몰리는 현상이 발생했습니다.

    📋 기존의 단일화된 구조

    workspace/
├── AGENTS.md
├── SOUL.md
├── USER.md
├── MEMORY.md
├── JARVIS_SYSTEM.md   <-- ⚠️ 모든 시스템 규칙이 여기에 집중됨
├── TOOLS.md
├── HEARTBEAT.md
├── plans/
│   ├── NEXT_ACTION.md
│   ├── ROADMAP_v1.2_full.md
│   └── ISSUE_TRACKER.md
└── memory/
    └── YYYY-MM-DD.md
    • 문제점: 파일 수는 적어서 깔끔해 보이지만, AI가 매번 읽어야 하는 ‘핵심 컨텍스트’가 점점 무거워집니다. 결국 중요한 규칙이 묻히거나 응답 속도가 저하될 위험이 있습니다.

    2. 향후 최적화 구조: “핵심 헌법과 세부 조례의 분리”

    이번 업데이트의 핵심은 **’파일의 증가’가 아니라 ‘독서량의 감소’**입니다. AI가 매 세션마다 모든 규칙을 다 읽을 필요가 없도록 구조를 세분화했습니다.

    📂 업그레이드된 시스템 구조 (Proposed)

    workspace/
├── AGENTS.md
├── SOUL.md
├── USER.md
├── MEMORY.md
├── JARVIS_SYSTEM.md     # ✅ [Core] 핵심 헌법만 
├── system/              # ✅ [Module] 상황별 세부 규칙 분리
│   ├── SESSION_PROTOCOL.md  # 시작/종료/동기화 프로토콜
│   ├── RESPONSE_RULES.md    # 답변 품질, 장황함 금지 규칙
│   ├── MEMORY_POLICY.md     # 기억 회상 및 저장 우선순위
│   ├── MODE_JARVIS.md       # 기본 범용 자비스 모드 설정
│   └── MODE_WRITER.md       # 작가 모드 (로보틱스 집필 특화)
├── TOOLS.md
├── HEARTBEAT.md
├── plans/
│   ├── NEXT_ACTION.md
│   ├── ROADMAP_v1.2_full.md
│   └── ISSUE_TRACKER.md
└── memory/
    └── YYYY-MM-DD.md

    3. 왜 이 구조가 더 효율적인가? (Key Insight)

    단순히 파일을 쪼갠 것이 아닙니다. AI의 인지 부하(Cognitive Load)를 줄이는 경로 최적화가 본질입니다.

    매 세션 기본 읽기량의 최소화

    • 상시 호출: SOUL.md, USER.md, JARVIS_SYSTEM.md(핵심) 등 정체성에 직결된 문서만 읽습니다.
    • 선택적 호출: 특정 작업(글쓰기 등)을 할 때만 MODE_WRITER.md를 로드하여 토큰 소모를 줄이고 정확도를 높입니다.

    관리의 편의성 증대

    • 답변이 너무 길어진다면 RESPONSE_RULES.md만 수정하면 됩니다. 다른 시스템 로직을 건드릴 필요가 없어 안정적입니다.

    4. 구조 변화에 따른 체감 비교

    구분기존 구조 (Small Files)최적화 구조 (Smart Folders)
    파일 수적음 (관리 용이해 보임)조금 늘어남 (체계적)
    파일당 용량매우 비대함 (Rule 간 충돌 위험)가볍고 명확함 (단일 책임 원칙)
    AI 인지 부하높음 (매번 전체 탐색)낮음 (필요한 경로만 선택)
    확장성낮음 (수정 시 전체 영향)높음 (모듈별 독립 업데이트)

    5. 결론: 겉보기 복잡함보다 실제 협업 효율이 우선이다

    결국 나만의 자비스를 만든다는 것은, AI가 나와 얼마나 더 빠르고 정확하게 소통하느냐의 싸움입니다.

    “파일이 많아지는 것을 두려워하지 마세요. 진짜 두려워해야 할 것은 AI가 읽어야 할 ‘불필요한 텍스트’의 양입니다.”

    이런 구조 변경을 통해 제 자비스는 더욱 가벼워진 핵심 헌법을 바탕으로, 상황에 맞는 전문성을 발휘할 수 있게 될거 같습니다.

    6. 하지만: 먼저 기존 시스템 진단 실시하자

    분리 구조가 잘 되면
    매번 읽는 핵심이 가벼워져서 판단력이 좋아질 가능성이 있지만 분리를 잘못하면
    오히려 파일만 늘고, 어디를 읽어야 하는지 헷갈려서 더 나빠질 수도 있다.
    즉 핵심은:파일을 나누는 것 자체가 답이 아니라,
    “항상 읽는 것”과 “필요할 때만 읽는 것”을 정확히 구분하느냐    다.

    진단도 오픈클로로 구축한 자비스에게 시켜봅니다. 현재 내가 구축한 시스템의 병목은 다른 곳에서 발견되어 우선 그걸 먼저 개선 했습니다.

    JARVIS_SYSTEM.md : 261줄 / 10,722자
    AGENTS.md : 233줄 / 9,188자
    둘 합치면 이미 꽤 무거워 중복된 내용을 다이어트하는걸로만 햐였습니다. 다이어트는 항상 필요합니다:)

    오늘의 최적화 아이디어는 차후 적용 할거 같습니다.

    시간이 가면 한번씩 시스템 최적화를 점검하고 요구해야 겠습니다.

    Tag: #자비스 #AI에이전트 #OpenClaw #폴더구조 #프롬프트엔지니어링 #생산성 #BakBiseo #로보틱스 #AI시스템설계

  • 나만의 홈페이지를 만들었다 — 블로그와 홈페이지 사이에서 고민한 이야기

    시작은 이 질문 하나였다

    “책을 쓰려는데, 블로그가 있으면 도움이 될까?”

    로보틱스 입문서를 집필 중인 나는 어느 날 이 질문을 던졌다. 그리고 그 질문이 오늘, 내가 전 세계 어디서든 접속할 수 있는 나만의 홈페이지 bakbiseo.com을 가진 사람이 되는 여정의 시작이었다.

    치과의사로 28년을 살아온 사람이, 로봇을 만들고 책을 쓰고 싶어서 홈페이지를 만들었다. 오늘 그 과정을 그대로 기록해 둔다. 나처럼 막막했던 누군가에게 이 글이 이정표가 되길 바라면서.

    그리고 같은 취미을 가진 열정있는 사람을 만나 재미난 사업도 하는걸 꿈꾸며.

    블로그 vs 홈페이지 — 도대체 뭐가 달라?

    처음엔 이것부터 헷갈렸다. 둘 다 인터넷에 글을 올리는 거 아닌가?

    결론부터 말하면, 이 둘은 ‘목적과 소유권’이 완전히 다르다.

    블로그는 남의 땅에 세 들어 사는 것이다. 네이버, 티스토리 같은 플랫폼이 땅(서버)도 주고 집(디자인)도 주고, 나는 그냥 글만 쓰면 된다. 쉽고 빠르다. 하지만 플랫폼이 정책을 바꾸거나 서비스를 종료하면, 내 소중한 기록도 함께 위험해진다.

    홈페이지는 내 땅에 내 집을 짓는 것이다. 복잡하다. 설정도 해야 하고, 비용도 든다. 하지만 내 데이터의 주인은 오직 나다. 언제든 이사할 수 있고, 30년 뒤에도 내 기록은 내 손 안에 있다.

    나는 책을 쓰고, 로봇을 만들고, 천체를 관측하고, 캐나다 이민 이야기도 나누고 싶었다. 단순한 일상 기록이 아니라, 쌓이고 쌓여 책이 될 수 있는 아카이브가 필요했다. 그래서 홈페이지를 택했다.

    왜 워드프레스인가?

    홈페이지를 만들기로 했다면 다음 질문은 “어떤 도구로?”다.

    **워드프레스(WordPress)**는 전 세계 웹사이트의 40% 이상이 사용하는 표준 소프트웨어다. 중요한 건 이것이 소프트웨어라는 점이다. 마치 엑셀이나 워드처럼.

    삼성 노트북을 쓰든 LG 노트북을 쓰든, 엑셀 파일은 어디서든 열린다. 마찬가지로 워드프레스로 만든 내 사이트는, 서버 업체를 바꾸더라도 데이터를 통째로 들고 이사할 수 있다. 네이버 블로그는 절대 불가능한 일이다.

    워드프레스 = 설계도 (내 소유)

    서버(호스팅) = 집을 지을 땅 (빌려 쓰는 것)

    네임칩을 선택한 이유

    서버 업체는 **네임칩(Namecheap)**으로 정했다. 이유는 단순하다. 향후 영어권 독자와 아마존 출판을 목표로 하기 때문이다.

    국내 업체(가비아, 카페24 등)를 쓰면 이렇게 된다:

    1. 도메인(주소) 구매
    2. 서버 업체 따로 가입
    3. 두 곳을 연결하는 DNS 설정 직접 수동 작업
    4. 워드프레스 수동 설치
    5. 보안 인증서(SSL) 별도 설치

    초보자에겐 하루가 꼬박 걸리는 고난의 행군이다.

    네임칩의 EasyWP는 이 모든 과정을 자동으로 처리해 준다. 도메인 구매부터 서버 연결, 워드프레스 설치, 보안 인증서 활성화까지. “DNS settings will automatically update”라는 문구 한 줄이 그 복잡한 과정을 대신한다.

    실전 — 이렇게 따라 하면 된다

    1단계: 도메인 이름 정하기

    도메인은 인터넷 세상의 내 주소다. 예를 들어 naver.com, google.com 같은 것. 전 세계에서 단 하나뿐인 주소를 내가 갖게 되는 것이다.

    나는 bakbiseo.com으로 정했다. ‘자비스’처럼 나만의 AI 비서 이름을 갖고 싶었는데, ‘JARVIS’는 이미 상표가 있으니 ‘백비서’를 영문으로 풀었다. 발음도 자연스럽고, 기억하기도 쉽다. ( 그리고 더 깊은 의미는 캐나다,미국 백야드을 관리해주는 로봇플랫폼을 만들어 가는 일을 함께할 AI 에이젼트이기때문이다.)

    도메인 이름을 정할 때 원칙:

    • .com을 고집할 것 (글로벌 신뢰도 최강)
    • 짧고 기억하기 쉽게
    • 나의 정체성이 담길 것

    참고로 도메인은 무조건 소문자로만 등록된다. 대문자로 입력해도 시스템이 소문자로 처리한다. 대신 홈페이지 로고나 제목에는 BakBiseo처럼 대문자를 섞어 브랜딩할 수 있다.

    2단계: 네임칩에서 도메인 구매

    namecheap.com 접속 → 검색창에 원하는 도메인 입력 → “Available” 초록색 체크 확인 → 장바구니 → 결제

    비용: 연간 약 10달러 내외. Domain Privacy(개인정보 보호) 옵션은 반드시 켜둘 것. 네임칩은 이 기능을 평생 무료로 제공한다.

    전화번호 입력 시 주의: 국제 표준 형식은 +82.1012345678 — 010에서 앞의 0을 빼고 입력한다.

    3단계: EasyWP로 워드프레스 설치

    결제 완료 후 네임칩 대시보드에서 “Set up a WordPress site” 클릭.

    • Create a new Website 선택
    • Your Namecheap domain 선택 후 구매한 도메인 연결
    • 플랜: Starter (연간 약 31달러, 초보자에게 충분)
    • 테마: Twenty Twenty-Five (워드프레스 공식 최신 테마, 가볍고 안정적)
    • 플러그인: 전부 체크 해제하고 넘어갈 것 (나중에 필요한 것만 하나씩)

    4단계: 이메일 인증

    설치 후 가입 이메일로 인증 메일이 온다. 반드시 클릭해야 도메인 소유권이 법적으로 확정된다. (인증 이메일 처리후 다시 접속하면 “already been verified”라는 문구가 뜨면 이미 완료된 것이니 안심할 것.)

    5단계: 관리자 화면(Dashboard) 접속

    네임칩 대시보드 → WP Admin 버튼 클릭.

    이때 브라우저에서 “연결이 안전하지 않습니다” 라는 보안 경고창이 뜰 수 있다. 당황하지 말자. 보안 인증서(SSL)가 활성화되는 데 수십 분 정도 걸리기 때문에 나타나는 일시적인 현상이다. **[고급] → [bakbiseo.com으로 계속하기]**를 누르면 관리자 화면으로 진입할 수 있다. 시간이 지나면 이 경고는 자동으로 사라진다.

    관리자 화면 진입 후 첫 번째로 할 일: Settings → General → Site Language → 한국어 선택 → Save Changes

    오늘의 성과 요약

    항목내용비용
    도메인bakbiseo.com (네임칩)약 $10/년
    서버+워드프레스EasyWP Starter약 $31/년
    DNS 연결자동 (네임칩이 처리)무료
    보안 인증서(SSL)자동 활성화무료
    개인정보 보호Domain Privacy무료

    총 비용: 약 $41/년 (한화 약 5~6만 원). 30년의 디지털 기지를 갖는 비용치고는 놀랍도록 저렴하다.

    블로그로 시작해서 홈페이지가 된다

    워드프레스의 가장 큰 매력은 성장하는 플랫폼이라는 것이다.

    지금은 글을 쌓는 블로그로 시작한다. 원고가 쌓이면 메뉴를 구성해 포트폴리오처럼 보이게 된다. 책이 출간되면 “Buy on Amazon” 버튼을 달고 공식 저자 홈페이지로 탈바꿈한다. 디자인(테마)만 바꾸면 그동안 쌓인 글은 그대로 살아남는다.

    블로그 → 포트폴리오 → 저자 공식 홈페이지 이 모든 변화가 하나의 주소(bakbiseo.com) 안에서 이루어진다.

    마치며

    오늘 나는 단순히 홈페이지 하나를 만든 게 아니다. 앞으로 써 내려갈 로봇 제작기와 입문서 원고, 천체 관측 이야기, 그리고 이민자의 솔직한 기록들이 쌓일 나만의 성채를 지었다.

    누군가의 플랫폼에 기대지 않고, 내 데이터의 주인이 되는 것. 그게 오늘 내가 선택한 가치다.

    홈페이지를 갖고 싶었지만 어디서 시작해야 할지 몰랐던 분들께, 이 글이 첫 삽을 뜨는 용기가 되길 바란다.

    다음 글에서는 워드프레스 첫 화면을 꾸미는 법과, 구글·네이버 검색에 내 사이트를 등록하는 방법을 다룰 예정이다.

    #워드프레스홈페이지만들기 #네임칩도메인 #블로그vs홈페이지 #독립형홈페이지 #EasyWP #로보틱스 #나만의홈페이지 #워드프레스초보 #bakbiseo

  • Hello world!

    Welcome to WordPress. This is your first post. Edit or delete it, then start writing!