블로그

As a beginner in astronomy, I built an automated observing briefing system using Meteoblue and Jarvis to read the urban night sky. The goal is simple: I want to know if tonight is worth going out, what time is best, and what targets are realistic before I carry my gear to the rooftop.

Why I Needed This System

I want astronomy to become more than a one-off hobby. I want to observe, experiment, record what I learn, and eventually turn those records into useful posts for other beginners like me.

The problem is that real life gets in the way. After work, I am tired. I do not want to check multiple weather and astronomy sites every evening and still end up wondering, “Was tonight actually worth it?”

So I decided to make Jarvis do that part for me.

I First Treated It Like a Weather Report, and That Was a Mistake

At first, the idea sounded simple.
Just check the weather and tell me whether tonight is good for observing.

That turned out to be wrong.

For astronomy, especially deep-sky observing, a normal weather forecast is not enough. No rain and light wind do not automatically mean a good observing night. On the other hand, a sky that looks fine at first glance can still be ruined by high cloud.

That is where Meteoblue Astronomy became important.

Meteoblue Astronomy shows data in a way that feels much closer to how an observer actually thinks. The first things I look at are these:

• low cloud
• mid cloud
• high cloud
• seeing
• arc sec
• jet stream
• humidity
• moon phase

The biggest lesson was very simple.

For deep-sky observing, cloud is the first filter.

That does not mean transparency and seeing do not matter. They do. But if cloud is there, especially high cloud, the session can be over before it even starts. High cloud is tricky because it can leave the sky looking “usable” while quietly killing contrast.

So for deep-sky observing, I now check cloud layers first and only then move on to the rest.

How I Redesigned the Briefing System

Instead of asking Jarvis for a general weather-style report, I changed the system into something more practical: a tool that interprets Meteoblue Astronomy and finds the actual observing window.

That means the key question is no longer, “Is tonight good?”

The key questions are these:

• What is the real observing window tonight?
• How long does that window last?
• Is it good enough for deep-sky observing?
• Which telescope should I use?

That led to a much better decision flow.

The New Logic

1. Check low, mid, and high cloud first
2. Find the actual cloud window
3. Check how long that window lasts
4. Then evaluate seeing, arc sec, jet stream, and humidity
5. Finally, recommend targets and gear for that window

In short:

Do not judge the whole night as one block. Find the actual observing window first.

The Briefing Format I Built

The system does not just look at tonight. Meteoblue gives roughly 48 hours of useful data, so I decided the briefing should include both tonight and tomorrow night.

That matters more than I expected. Even if tonight is poor, tomorrow may already look promising enough for me to prepare gear and schedule ahead.

[Image insert: Meteoblue Astronomy screen showing low, mid, high cloud and seeing]

This is the general structure I gave Jarvis.

# Urban Deep-Sky Hunt - Daily Briefing

- Date:
- Location: Wonju Innovation City rooftop

## Tonight
- Summary:
- Main observing window:
- Go / Conditional Go / Not Recommended
- Deep-sky suitability:
- Recommended gear tonight:

## Tomorrow Night Preview
- Summary:
- Expected observing window:
- Forecast confidence:
- Recommended gear tomorrow night:

## Window Analysis
- Tonight primary window:
- Tonight secondary window:
- Tomorrow primary expected window:
- Window length assessment:
- Main risks:

## Technical Data Summary
- Low cloud:
- Mid cloud:
- High cloud:
- Seeing 1:
- Seeing 2:
- Arc Sec.:
- Jet Stream:
- Bad Layers:
- Temp:
- Relative Humidity:
- Dew risk:
- Moon impact:

## Recommended Targets
1.
- Target:
- Type:
- Why it fits:
- Recommended gear:

This format helped immediately. It made the system more actionable, and it also created clean environmental data that I can later paste into my observing log.

I Also Built a Learning Card for Each Target

Once I started getting actual observing briefings, I ran into another problem.

I would get a target recommendation like M44, and then I would immediately think, “Okay, but what exactly should I be looking for?”

If I ask for a random explanation every time, the system becomes messy. So I made a separate format called a Target Learning Card.

The workflow now looks like this:

1. Jarvis gives me the daily briefing
2. I choose a target
3. I ask something like “Provide M44 reference”
4. Jarvis replies in the same fixed format every time

That was the right call. The briefing stays short and practical, but if I want to study a target before heading out, I can do that too.

[Image insert: Example of a target learning card]

This is the structure I settled on.

# Urban Deep-Sky Hunt - Target Learning Card

- Target:
- Type:
- Best season / observing period:
- Recommendation for tonight:

## 1. What is it
- Identity:
- What kind of object it is:
- Distance / size / brightness:
- Constellation:

## 2. Why it matters
- Why it is famous:
- Why it is beginner-friendly:
- Whether it works under urban skies:

## 3. Where to find it
- Position in the sky:
- Reference stars / constellations:
- Star-hopping difficulty:

## 4. What to look for tonight
- What to expect with the naked eye / finder:
- What to expect at low power:
- What to expect at medium power:
- Main visual cue for tonight’s conditions:

## 7. Recommended gear for tonight
- Telescope:
- Eyepiece:
- Magnification direction:
- Imaging setup if relevant:

I like this structure a lot. It works before observing, it works for notes, and it can easily become blog material later.

The Most Practical Lesson I Learned

The biggest lesson was not that I needed more data.
It was that I needed a better order of judgment.

At first, I thought more data automatically meant better decisions. That was not true.

For deep-sky observing, I now think in this order:

• first, cloud
• second, transparency-like sky quality
• third, moon impact
• fourth, dew risk
• fifth, seeing

That order might change for planetary observing.
But for deep-sky work, cloud comes first.

Once I taught Jarvis to think in that order, the system became much more useful. At the very least, it became much better at answering the one question I actually care about before going outside:

Should I go out tonight or not?

Final Thoughts

This system is still evolving. Tomorrow’s 6 PM briefing may reveal new things to improve. But the direction is now clear.

• Meteoblue Astronomy is the main reference
• General weather data is only a backup
• The real question is not whether the night is “good”
• The real question is what the observing window actually is
• Targets and gear should be recommended together
• And if needed, each target should have its own learning card

That already makes astronomy feel much less overwhelming.

If you are a beginner, here is one simple thing you can do tonight:

Before checking anything else, look at low, mid, and high cloud on Meteoblue Astronomy first.

That is where I started, and now Jarvis starts there too.

Today, Jarvis evolves again.

Now I’m heading out to hunt M44.

천체관측 초보인 내가 Meteoblue와 자비스를 이용해 도심 하늘을 읽는 자동 관측 브리핑 시스템을 만들었다. 목적은 단순하다. 오늘 밤 나갈 만한지, 몇 시가 좋은지, 뭘 보면 좋을지를 매일 자동으로 받기 위해서다.

왜 이런 시스템이 필요했나

나는 천체관측을 취미로 더 깊게 해보고 싶었다. 단순히 한 번 보고 끝나는 취미가 아니라, 실험하고 기록하고, 나중에는 블로그나 홈페이지에 남겨서 다른 초보자에게도 도움이 되는 흐름으로 만들고 싶었다.

문제는 현실이었다.
퇴근하고 나면 피곤하다. 하늘이 괜찮은지 매번 여러 사이트를 뒤져야 한다. 그리고 막상 나가도 “오늘은 진짜 나갈 만한 날이었나?”가 늘 애매했다.

이걸 줄이고 싶었다.
그래서 자비스에게 매일 저녁 관측 브리핑을 자동으로 만들어달라고 했다.

처음에는 날씨 브리핑처럼 접근했는데, 그건 틀렸다

처음 생각은 단순했다.
날씨를 보고 오늘 밤 관측 가능성을 알려주면 되지 않을까 싶었다.

그런데 금방 문제가 드러났다.

천체관측, 특히 딥스카이는 일반 날씨 앱식 판단으로는 부족하다.
비가 안 오고 바람이 약하다고 해서 좋은 밤이 아니다. 반대로 겉보기엔 괜찮아 보여도 상층운이 끼면 딥스카이는 바로 망한다.

이때 핵심이 된 게 Meteoblue Astronomy였다.

Meteoblue Astronomy는 일반 날씨보다 천체관측자 관점에 더 가까운 데이터를 보여준다. 내가 제일 먼저 보는 것도 바로 이 부분이다.

• low cloud
• mid cloud
• high cloud
• seeing
• arc sec
• jet stream
• humidity
• moon phase

여기서 깨달은 건 간단했다.

딥스카이 관측에서 1순위는 cloud다.

투명도나 시상이 중요하지 않다는 뜻이 아니다.
하지만 구름이 있으면 아예 못 본다. 특히 high cloud도 만만하지 않다. 하늘이 얼핏 맑아 보여도 상층 운막이 별빛 대비를 다 죽여버린다.

즉 딥스카이 기준으로는 먼저 구름층 데이터를 보고, 그 다음에 seeing이나 다른 데이터를 봐야 한다.

그래서 브리핑 시스템을 이렇게 다시 설계했다

나는 자비스에게 일반 날씨 요약이 아니라, Meteoblue Astronomy를 해독해서 관측 가능한 시간 창을 찾아주는 시스템을 만들게 했다.

핵심은 “오늘 밤이 좋다/나쁘다” 같은 두리뭉실한 말이 아니다.

핵심은 이것이다.

• 오늘 몇 시부터 몇 시까지가 실제 관측 창인지
• 그 창이 짧은지 긴지
• 그 시간에 딥스카이를 노려도 되는지
• 어떤 장비가 더 맞는지

이렇게 바꿨다.

브리핑 판단 순서

1. low / mid / high cloud를 시간대별로 먼저 본다
2. 구름이 비는 시간 창이 있는지 찾는다
3. 그 창이 몇 시간짜리인지 본다
4. 그 다음 seeing, arc sec, jet stream, humidity를 본다
5. 마지막으로 그 시간대에 맞는 대상과 장비를 추천한다

한 줄로 요약하면 이렇다.

“오늘 밤 전체”를 뭉뚱그리지 말고, “실제 관측 가능한 시간 창”을 먼저 뽑는다.

실제로 만든 브리핑 포맷

브리핑은 오늘 밤만 보지 않는다. Meteoblue가 대략 48시간 데이터를 보여주기 때문에, 오늘 밤과 내일 밤 예고를 함께 본다. 이게 꽤 중요하다. 오늘 밤이 별로여도 내일 밤이 좋다면 장비 준비나 시간 계획을 미리 할 수 있기 때문이다.

[이미지 삽입: Meteoblue Astronomy에서 low/mid/high cloud와 seeing이 보이는 화면]

자비스가 쓰도록 만든 브리핑 구조는 대략 이렇다.

# 도심의 딥스카이 사냥 - 일일 브리핑

- 날짜:
- 위치: 원주 혁신도시 옥상

## 오늘 밤
- 총평:
- 핵심 관측 창:
- 출동 권고:
- 딥스카이 적합도:
- 오늘 밤 추천 장비:

## 내일 밤 예고
- 총평:
- 예상 관측 창:
- 예고 신뢰도:
- 내일 밤 추천 장비:

## 창 분석
- 오늘 1차 관측 창:
- 오늘 2차 관측 창:
- 내일 1차 예상 창:
- 창 길이 평가:
- 핵심 리스크:

## 기술 데이터 요약
- Low cloud:
- Mid cloud:
- High cloud:
- Seeing 1:
- Seeing 2:
- Arc Sec.:
- Jet Stream:
- Bad Layers:
- Temp:
- Rel. Hum.:
- Dew risk:
- Moon impact:

## 추천 대상
1.
- 대상명:
- 분류:
- 추천 이유:
- 추천 장비:

이 포맷을 고정해두니까 좋은 점이 있었다.
그날 밤 행동하기 쉬워지고, 관측 후 기록용 데이터로도 바로 붙일 수 있다.

브리핑만으로는 부족해서, 대상 학습 카드도 만들었다

브리핑을 받고 나면 이런 흐름이 생긴다.

“좋아, 오늘 1순위는 M44네. 그런데 M44가 정확히 뭐지?”

이걸 매번 즉흥적으로 설명하면 시스템이 지저분해진다.
그래서 아예 대상 학습 카드라는 별도 포맷도 만들었다.

즉 흐름은 이렇게 간다.

1. 자비스가 브리핑을 준다
2. 내가 오늘 대상을 고른다
3. 예를 들어 “M44 자료 제공”이라고 말한다
4. 자비스가 정해진 카드 형식으로 설명한다

이 방식이 좋은 이유는 브리핑은 짧고 강하게 유지하면서도, 필요할 때는 공부 자료를 깊게 받을 수 있기 때문이다.

[이미지 삽입: 대상 학습 카드 예시 화면]

예를 들어 M44 학습 카드는 이런 구조다.

# 도심의 딥스카이 사냥 - 대상 학습 카드

- 대상명:
- 분류:
- 계절/관측 시기:
- 오늘 기준 추천 여부:

## 1. 이 대상이 뭐냐
- 대상의 정체:
- 어떤 천체인지:
- 거리 / 크기 / 밝기:
- 어느 별자리 소속인지:

## 2. 왜 유명한가
- 대표적인 이유:
- 초보자에게 왜 좋은지:
- 도심에서도 가능한지:

## 3. 어디서 찾나
- 위치 설명:
- 찾는 기준 별/별자리:
- 스타호핑 난이도:

## 4. 오늘 뭘 봐야 하나
- 육안/파인더에서 기대할 것:
- 저배율에서 보일 포인트:
- 중배율에서 보일 포인트:
- 오늘 조건에서 특히 볼 핵심:

## 7. 오늘의 추천 장비
- 경통:
- 접안렌즈:
- 배율 방향:
- 촬영 시 추천 구성:

이 구조는 꽤 마음에 든다.
관측 직전에 보기 좋고, 나중에 블로그 글 재료로도 좋고, 초보자에게 설명할 때도 깔끔하다.

내가 얻은 가장 현실적인 교훈

이 과정을 하면서 느낀 건 딱 하나다.

천체관측 초보자에게 필요한 건 더 많은 정보가 아니라, 더 좋은 판단 순서다.

나도 처음엔 데이터가 많을수록 좋을 줄 알았다.
그런데 실제로는 우선순위가 더 중요했다.

딥스카이 기준이라면 나는 이제 이렇게 본다.

• 첫 번째, cloud
• 두 번째, transparency에 가까운 체감
• 세 번째, 달빛 영향
• 네 번째, 이슬 위험
• 다섯 번째, seeing

행성관측이라면 순서가 조금 바뀔 수 있다.
하지만 딥스카이에서는 일단 구름이 제일 직접적이다.

이 기준을 자비스 시스템에 넣어두니, 적어도 “오늘 나가야 하나 말아야 하나”를 훨씬 덜 헤매게 됐다.

결론, 초보자일수록 관측 브리핑 시스템이 있으면 좋다

내가 만든 시스템은 아직 완성형은 아니다.
내일 실제 저녁 6시 브리핑이 오면 또 손볼 부분이 생길 수 있다. 그래도 방향은 분명하다.

• Meteoblue Astronomy를 메인으로 본다
• 일반 날씨는 보조로만 쓴다
• 오늘 밤 전체가 아니라 관측 가능한 시간 창을 먼저 본다
• 대상과 장비를 같이 추천한다
• 필요하면 대상 학습 카드로 공부까지 이어간다

이 정도만 해도 천체관측이 훨씬 덜 막막해진다.

지금 당장 해볼 수 있는 행동은 하나다.
오늘 밤 관측 전에 Meteoblue Astronomy에서 low, mid, high cloud부터 먼저 보는 습관을 들여보자.

나도 그렇게 시작했고, 자비스도 이제 그 순서로 배우고 있다.
오늘도 자비스는 진보하고 난 M44을 사냥하러 나간다 🙂

지방 도시 옥상 관측대에서 8SE와 C9.25 사이에서 고민한 기록이다. 제미니,지피티,클로드 3가지로 3일간 시뮬레이션까지 돌려봤다.

---

발단: CRUX 170HD가 생기고 나서 고민이 시작됐다

솔직히 말하면, 마운트가 생기기 전에는 경통 업그레이드 생각을 진지하게 안 했다.

그런데 CRUX 170HD 하모닉 드라이브 마운트가 손에 들어오고 나서, 머릿속이 이상하게 돌아가기 시작했다.

“이 마운트, 더 큰 경통도 되지 않나?”

그리고 타이밍 맞게 인터넷에 C9.25 최저가 매물이 올라왔다. 재고는 2개 금액은 231만원…역대급이다. 내가 가진 미사용 8SE는 130에 팔고 얼릉 바꿔 탈까? (실은 지금 거는 두번째 8SE이다. 처음거는 중고로 얼마전 80에 양도했다. 워낙 좋아하는 물건이라 두 번째 장만했던차라…)

원주 혁신도시 건물 옥상 관측대. 쉐드와 5m 이동 거리. 조건은 나쁘지 않았다.

그래서 AI한테 물어봤다. 제대로.

---

8SE 경통, 숫자부터 확인하자

먼저 팩트 확인부터 했다.

Celestron 8SE 경통(OTA) 무게는 공식 스펙 기준 5.4kg(12lbs) 이다.

가볍다. 한 손으로 들고 이동 가능하다. “꺼내서 바로 쓰는” 장비다.

그런데 여기에 파인더, 아이피스, 카메라까지 붙으면?

6~7kg이 된다.

8SE 마운트가 항상 “한계에 걸린 느낌”이 드는 건 이 구조 때문이다. CRUX 170 기준으로는 문제없지만, 원래 포크 마운트와 붙어 다니는 설계라 경통 자체의 한계 설계가 있다.

---

C9.25는 얼마나 다른가

C9.25 OTA 공식 무게는 9.1kg(20lbs) 이다.

8SE 대비 단순 차이: +3.7kg, 약 68% 증가.

숫자로 보면 “조금 무겁네” 싶지만, 실제 취급은 완전히 다른 이야기다.

8SE는 생각 없이 꺼낸다. C9.25는 마음 준비하고 꺼낸다.

부속 포함 최종 무게는 이렇게 된다.

구성	8SE	C9.25
경통	5.4kg	9.1kg
파인더/아이피스/카메라	+1~1.5kg	+1~1.5kg
최종 합산	6~7kg	10~11kg

CRUX 170HD는 스펙상 버틴다. 하지만 “버틴다 ≠ 편하게 쓴다”는 게 핵심이었다.

---

성능 차이는 실제로 얼마나 체감될까

광집광력 기준으로 C9.25는 8SE 대비 약 1.33배(+33%) 다.

숫자만 보면 상당해 보인다.

그런데 천문 관측에서는 오래된 현실이 있다.

“2배 이상 차이가 나야 ‘와, 다르다’ 느낌이 온다.”

AI 시뮬레이션을 돌려보니 체감 증가는 이 정도였다.

항목	체감 변화
성운 밝기	약간 밝아짐
성운 구조	약간 더 보임
은하	조금 더 또렷
행성	거의 차이 없음

행성은 시잉이 90%를 결정한다. 원주처럼 Bortle 6~7 수준의 지방 도시 하늘에서는, 평균 시잉이 구경 차이를 상당 부분 먹어버린다.

평균 시잉에서는 8인치 vs 9.25인치 분해능 차이 거의 안 살아남음 즉 평균 시잉에서는 C8이 C9.25랑 거의 동일한 행성 디테일을 보이고 성능을 끌어 낼때가지 기다리는 시간도 훨씬 길다. 그리고 옥상위 라는 조건도 낮에 받은 열이 식어 가면서 관측에 악영향을 미친다.

결론적으로 성능 증가는 +30%, 체감 증가는 +10~15% 수준이었다. 결정적으로 관리 스트레스와 꺼내고 들이고 하는 과정에서 집중도와 노동력이 훨씬 커진다.

---

그럼 ‘진짜 체감’이 오는 구경은 어디부터인가

여기서 AI가 꽤 냉정한 답을 줬다.

8인치 → 9.25인치: 의미 없음 8인치 → 12인치: 의미 있음 8인치 → 14인치↑: 세계가 바뀜

12인치는 8인치 대비 광집광력이 약 2.25배다. 여기서부터 성운 구조가 살아남기 시작하고, 구상성단 분해가 시작된다.

C9.25는 솔직히 “착각 구간”이다. 돈과 무게는 급증하는데, 눈에 들어오는 변화가 작다.

---

원주 옥상 관측대 기준, 최종 판단

내 환경을 다시 정리하면:

• Bortle 6~7 (지방 도시)
• 건물 옥상 쉐드
• 이동 거리 5m 이내
• CRUX 170HD 마운트

이 조건에서 선택지는 세 가지다.

1️⃣ 8SE 유지 → 가장 오래 쓴다. 후회 없다.

2️⃣ 12인치 돕소니안 → 체감 확실. 현실적으로 가장 효율적인 업그레이드.

3️⃣ C9.25 → 무게 급증, 체감 작음. 가장 비효율 구간.

결론은 생각보다 빨리 나왔다.

C9.25 최저가 매물은 닫았다.

---

지금 내가 선택한 것

8SE를 유지하기로 했다. 그리고 크록스에 물려 옥상에서 관측을 하고 정리하면서 다시 깨달았다. 편하게 자주 쓰는 물건이 최고임을…

CRUX 170HD에 C9.25을 올리면 그 과정이 지금처럼 편하지 않을거다.

장비 업그레이드 욕구는 솔직히 아직 있다. 하지만 지금 가진 장비를 충분히 쓰지도 않고 더 큰 것으로 가는 건, 결국 또 다른 부족함을 향해 달려가는 루프라는 걸 AI가 꽤 직설적으로 알려줬다.

진짜 업그레이드를 하게 된다면, 그때는 12인치부터 진지하게 볼 것이다.

지금은 원주 하늘 아래, 있는 장비로 충분히 보는 게 먼저다.

관측 빈도 유지 (지금처럼 자주 본다) → 8SE 유지

성능 우선 (덜 자주, 대신 더 깊게 본다) → C9.25

난 편하게 자주 보기로 했다. 업그레이드 비용 아꼈고 경위대,삼각대는 50만원에 양도 했다.

다짐: 9.25인치는 광학적으로는 매력적일지 몰라도, “내 몸을 깎아서 우주를 보는 행위”가 될 가능성도 있음을 기억하자

This is a record of a dentist’s journey to understand the fundamental principles of telephoto lenses. From focal length and image circles to angle of view, I stripped it all down to the basics.

---

I Thought Lenses Were Just Magnifying Glasses

As I started astrophotography, I began using telephoto lenses.

Naturally, a question arose: why does a longer focal length make objects look larger?

My initial assumption was simple:

“Light converges to a single point like a magnifying glass, flips upside down as it crosses over, and the sensor sits somewhere behind that point — right?”

Wrong. It took me an hour of debating with an AI to break this misconception.

---

The True Definition of Focal Length: Understanding via the Sun

If you hold a convex lens under sunlight, it burns a hole in paper. The distance from the lens to that burning spot is the focal length (f).

Because the Sun is so far away, its rays enter the lens almost perfectly parallel. Parallel rays converge into a single point. In a 500mm lens, this happens exactly 500mm behind the lens.

This is a fixed value determined at the factory.

---

Real-World Objects Do Not Converge to a Single Point

This is where I got stuck.

Unlike the Sun, light from everyday objects — reflective sources — behaves differently.

Light from Point A on an object → passes through the lens → lands on Position A’ on the sensor. Light from Point B on an object → passes through the lens → lands on Position B’ on the sensor.

Because light enters from various angles, it forms a plane at the focal distance, not a single point.

A lens is not a device that gathers light into a point.

A lens is a transformer — it converts angular information into spatial position.

This one sentence broke my misconception completely.

---

Where is the Sensor? — Warning: Never Aim at the Sun

The sensor is placed exactly on the plane where the image forms — the focal distance.

I realized something here on my own:

“If I aim a camera at the Sun, the sensor will melt.”

This is a real danger. In the film era, sunlight burned holes in shutters. Today, it permanently destroys pixels. The longer the focal length, the more dangerous — energy is concentrated into a much tighter point.

[Image comparing direct sunlight vs. reflected light paths through a camera lens]

---

The Image Circle: A Fixed Property of the Lens

I used to think the image circle changed based on the subject.

Wrong again.

The image circle — the maximum area a lens can project — is a fixed value determined by the lens design. Whether you photograph a mountain or a marble, the circle stays the same. What changes is what fits inside that circle.

This is why Full-Frame and APS-C lenses exist separately. When the sensor is larger than the image circle, the edges go dark. That is called vignetting.

---

Finally — Why Long Focal Lengths Narrow the View and Magnify

Now the core physics.

$$x = f \cdot \tan(\theta)$$

$x$: Distance from the sensor center to where the light lands. $f$: Focal length. $\theta$: The angle of the incoming light.

Light entering along the optical axis lands at the center of the sensor. Light entering at an angle lands away from the center — the greater the angle, the further from center it lands.

When $f$ increases, the same angle $\theta$ is projected further from the sensor center.

But the sensor size is fixed.

So the maximum angle that can fit onto the sensor gets smaller. This is why the angle of view narrows.

And that narrow slice of the world is now stretched across the entire sensor. This is why the subject appears magnified.

In one sentence:

A longer focal length accepts only a narrow range of angles, and that narrow range is spread across the entire sensor — so the view narrows and the subject grows larger.

---

Summary

Concept	Core Truth
Focal Length	Distance where parallel rays converge. A fixed lens property.
Real-World Subject	Does not form a point. Forms an image on a plane.
Image Circle	Fixed by lens design. Independent of the subject.
Magnification Principle	Narrower angles projected across the same sensor area.

One thing you can do today. Take a magnifying glass outside and find the point where sunlight burns the tightest spot on paper. That distance is the focal length. Physics is best understood through the fingertips.

Giving you the Universe,

치과의사가 망원렌즈 원리를 이해하려고 AI와 싸운 기록이다. 초점 거리, 이미지 서클, 시야각까지 밑바닥부터 파헤쳤다.

---

나는 렌즈를 돋보기로만 생각했다

천체사진을 찍기 시작하면서 망원렌즈를 쓰게 됐다.

그런데 궁금했다. 왜 초점 거리가 길수록 더 크게 보이는 걸까?

처음엔 당연히 이렇게 생각했다.

“돋보기처럼 빛이 한 점으로 모이고, 그 점에서 빛이 상하로 교차하면서 뒤집히고, 그 너머 어딘가에 센서가 있는 거 아닌가?”

틀렸다. 이 고정관념에서 벗어나는 데 한 시간이 걸렸다.

---

초점 거리의 진짜 정의는 태양으로 이해된다

볼록렌즈를 햇빛 아래 들고 있으면 종이가 탄다. 그 타는 지점까지의 거리가 바로 **초점 거리(focal length)**다.

태양빛은 지구에 도달할 때 거의 평행하게 들어온다. 평행광은 렌즈를 통과하면 딱 한 점으로 모인다. 500mm 렌즈라면 렌즈에서 정확히 500mm 지점에서 한 점으로 모이는 것이다.

이게 초점 거리의 정의다. 렌즈 공장에서 결정되는 고정값이다.

---

일반 피사체는 한 점으로 모이지 않는다

여기서 내가 처음 막혔다.

태양빛은 평행광이라서 한 점으로 모인다. 그런데 일반 피사체, 즉 반사체에서 나오는 빛은 다르다.

피사체의 A점에서 나온 빛 → 렌즈 통과 → 센서의 A’ 위치에 맺힌다 피사체의 B점에서 나온 빛 → 렌즈 통과 → 센서의 B’ 위치에 맺힌다

각 점에서 나온 빛이 각기 다른 각도로 렌즈에 들어오기 때문에, 초점 거리 지점에서 점이 아니라 면으로 맺힌다.

렌즈는 “빛을 한 점으로 모으는 장치”가 아니다.

렌즈는 각도 정보를 위치 정보로 바꾸는 변환기다.

이 문장 하나로 내 고정관념이 무너졌다.

---

그러면 센서는 어디에 있나 — 태양을 찍으면 센서가 탄다

센서는 초점 거리 지점, 즉 상이 맺히는 면 위에 딱 갖다 놓은 것이다.

여기서 내가 스스로 추론해낸 것이 있다.

“그러면 태양을 향해 카메라를 들이대면 센서가 타겠네?”

맞다. 실제로 일어나는 일이다.

필름 카메라 시절에는 태양을 향하면 셔터막이 타서 구멍이 뚫렸다. 디지털 카메라는 센서 픽셀이 영구 손상된다. 망원렌즈일수록 더 위험하다. 초점 거리가 길수록 에너지가 더 좁은 점에 집중되기 때문이다.

---

이미지 서클은 렌즈의 고정값이다

대화를 이어가다가 또 하나의 개념을 정리했다.

이미지 서클(image circle) — 렌즈가 만들어낼 수 있는 최대 이미지 영역이다.

처음엔 피사체가 크면 이미지 서클도 커지는 줄 알았다. 틀렸다.

이미지 서클은 렌즈 설계로 결정되는 고정값이다. 피사체가 뭐든, 거리가 얼마든 바뀌지 않는다. 바뀌는 건 그 서클 안에 무엇이 담기느냐일 뿐이다.

그래서 풀프레임용 렌즈와 크롭용 렌즈가 따로 있다. 센서 크기에 맞게 이미지 서클을 설계하는 것이다. 센서가 이미지 서클보다 크면 가장자리가 까맣게 된다. 이걸 비네팅이라고 부른다.

---

초점 거리가 길면 왜 시야각이 좁아지고 확대될까 — 드디어 답

이제 준비가 됐다.

핵심 공식은 이것이다.

x = f · tan(θ)

x = 센서 중심점에서 빛이 맺히는 거리 f = 초점 거리 θ = 빛이 들어오는 각도

광축, 즉 렌즈 정중앙으로 들어온 빛은 센서 중심에 맺힌다. 각도가 있는 빛은 그 중심점에서 벗어난 위치에 맺힌다. 각도가 클수록 중심에서 더 멀리 맺히는 것이다.

초점 거리 f가 길어지면, 같은 각도 θ로 들어온 빛이 센서의 중심점에서 더 멀리 맺힌다.

그런데 센서 크기는 고정이다.

결국 센서 안에 들어올 수 있는 θ의 최대값이 줄어든다. 이게 시야각이 좁아지는 이유다.

그리고 그 좁아진 각도 범위, 즉 좁은 장면이 센서 전체를 가득 채운다. 이게 확대되는 이유다.

한 줄로 정리하면:

초점 거리가 길어지면 좁은 각도만 받을 수 있고, 그 좁은 각도가 센서 전체에 펼쳐지니까 — 시야는 좁아지고 피사체는 커 보인다.

---

오늘 배운 것 한 줄 정리

개념	핵심
초점 거리	평행광이 한 점으로 모이는 거리. 렌즈 고정값
일반 피사체	한 점 아님. 면으로 맺힘
이미지 서클	렌즈 고정값. 피사체와 무관
망원렌즈 확대 원리	좁은 각도 → 센서 전체에 펼쳐짐

오늘 당장 할 수 있는 것 하나. 돋보기를 들고 햇빛 아래 나가서 종이를 태워봐라. 그 타는 지점까지의 거리가 그 렌즈의 초점 거리다. 렌즈 원리가 손끝으로 이해된다.

우주을 너에게 줄게…

OpenClaw 대시보드를 열었더니 “Control UI assets not found” 오류만 떴다. 공식 재설치를 여러 번 해도 똑같았다. 원인은 패키지 배포 버그였고, 해결은 직접 빌드하는 것뿐이었다.

---

사건의 시작은 황당했다

에이전트한테 “바탕화면에 열린 다른 창 닫아라”고 했다. 에이전트가 macOS 단축키 ⌘W를 실행했는데, 그 순간 활성 상태였던 창이 OpenClaw 채팅창이었다. 채팅창이 그대로 닫혀버렸다.

⌘W는 현재 포커스된 창을 닫는 단축키다. 에이전트가 어떤 창이 활성 상태인지 구분 못 한 게 원인이었다.

이후 브라우저에서 http://127.0.0.1:18789 를 다시 열었더니 이 화면만 떴다.

Control UI assets not found. Build them with `pnpm ui:build`
(auto-installs UI deps), or run `pnpm ui:dev` during development.

---

오류의 정체

터미널 로그에도 이렇게 찍혔다.

[gateway] Missing Control UI assets at
/opt/homebrew/lib/node_modules/openclaw/dist/control-ui/index.html.

gateway 자체는 살아 있었다. 문제는 브라우저 화면을 그리는 정적 파일(index.html 등)이 아예 없다는 것이었다.

원인은 Homebrew/npm 패키지 배포 과정의 버그다. 공식 설치 스크립트로 재설치해도 이 파일은 복구되지 않는다. 직접 빌드해서 넣어줘야 한다.

---

해결 방법 — 4단계

1단계 — 설치 경로 확인

ls -la /opt/homebrew/bin/openclaw

/opt/homebrew/lib/node_modules/openclaw/ 경로가 나오면 정상이다.

2단계 — GitHub에서 소스 클론 및 빌드

git clone https://github.com/openclaw/openclaw.git ~/openclaw-src
cd ~/openclaw-src
pnpm install
pnpm ui:build

아래 메시지가 나오면 빌드 성공이다.

✓ built in 561ms

주의: pnpm ui:build 는 반드시 클론한 디렉토리(~/openclaw-src) 안에서 실행해야 한다. 홈 디렉토리나 .openclaw 폴더에서 실행하면 ERR_PNPM_NO_IMPORTER_MANIFEST_FOUND 에러가 난다.

3단계 — 빌드 결과물 복사

cp -r ~/openclaw-src/dist/control-ui /opt/homebrew/lib/node_modules/openclaw/dist/

4단계 — OpenClaw 재시작

새 터미널 탭에서 실행한다.

openclaw gateway --force

브라우저에서 새로고침하면 대시보드가 정상으로 돌아온다.

[이미지 삽입: 정상 복구된 OpenClaw 대시보드 화면]

---

알아두면 좋은 것

OpenClaw를 업데이트하면 같은 증상이 재발할 수 있다. 업데이트할 때마다 2~4단계를 반복하면 된다.

이건 사용자 실수가 아니다. 패키지 배포 버그다.

---

지금 당장 할 수 있는 것

같은 오류를 만났다면 재설치 시도는 그만하고 바로 이 순서로 가자.

1. git clone 으로 소스 받기
2. pnpm ui:build 로 빌드
3. dist/control-ui 복사
4. openclaw gateway --force 재시작

재설치로 안 된다면 빌드가 답이다.

복구하고 다시 재회한 화면

오늘도 자비스는 진보한다.

잘 쓰던 OpenClaw에서 갑자기 OAuth 오류가 터졌다. 재인증해도 안 됐던 이유는 따로 있었다.

---

이런 메시지가 떴다

Agent failed before reply: OAuth token refresh failed for openai-codex:
Failed to refresh OpenAI Codex token. Please try again or re-authenticate.

---

재인증 명령어는 이거다

openclaw models auth login

실행하면 브라우저가 열리고 Authentication successful 확인할 수 있다.

재인증 성공했는데도 오류가 반복된다면

UI 세션 모드를 확인해야 한다. ( 오픈클로을 재 설치하기도하고, config 명령어로도 해보고 수십번 이런 저런 시도해서 재인증해 보았다ㅠ)

Heartbeat 모드는 연결 상태만 확인하는 모드다. 대화 세션이 아니다. 인증이 복구돼도 이 모드에선 대화가 열리지 않는다.

Heartbeat → Direct 로 바꾸면 바로 해결된다.

---

중복 프로필 문제도 확인할 것

재인증을 해도 오류가 반복되자, 혹시 프로필 자체가 꼬인 게 아닐까 의심했다.

~/.openclaw/agents/main/agent/auth-profiles.json 을 직접 열어봤더니 프로필이 두 개였다.

• openai-codex:default
• baejunchae878@gmail.com (실제 인증된 계정)

처음 로그인할 때 이메일 확인 전 상태로 저장되면서 default 프로필이 생긴다. 이후 정식 로그인하면 이메일 프로필이 별도로 추가된다. 같은 계정인데 두 개가 공존하는 상태가 되는 것이다.

default 가 문제의 원인일 수 있다고 판단해서 해당 항목을 삭제하고, 실제 인증된 이메일 프로필만 남겼다.

---

해결 순서 요약

1. openclaw models auth login 재인증
2. openclaw gateway restart
3. UI 세션 모드 → Direct 전환
4. auth-profiles.json 에서 default 프로필 삭제 (만약의 경우)

재인증만 하고 안 된다고 멈췄다면, UI 세션 모드가 범인이다.

오늘도 자비스는 진보한다.

그리고 매 번 창을 열때 세션모드을 토글해서 변경해서 사용하다가 2026년 4월 9일 문제의 원인과 해결을 다시 알게 되었다.

즉 상황은 이렇게 정리된다.

• 웹 인터페이스만 쓰던 시기
• agent:main:main 세션이 정상 기본 세션이었다
• 맥에서 텔레그램을 띄워서 대화하기 시작한 뒤
• 실제 주력 대화 세션이 agent:main:telegram:direct:8759881574 로 생겼다
• 그런데 Safari 아이콘은 여전히 기존 main 세션 주소 감각으로 열리니
• heartbeat 세션으로 열리며 인증 에러을 보게 된것이다

즉 핵심은:
웹만 쓸 때는 main 세션이 맞았는데, 텔레그램 직결 세션이 생기면서 주사용 세션이 바뀌었고, 시작 주소는 그 변화를 반영하지 못했다는 거다.

홈페이지 업데이트 문안도 이 반영이 들어가면 더 정확하다.

수정 문안
오늘 OpenClaw 접속 문제를 점검했다. 웹 인터페이스만 사용하던 시기에는 agent:main:main 세션이 기본 진입 세션으로 자연스러웠다. 그런데 이후 Mac에서 텔레그램을 통해 자비스와 직접 대화하기 시작하면서, 실제 주사용 세션이 텔레그램 direct 세션으로 바뀌었다. 문제는 Safari의 OpenClaw 아이콘 시작 주소가 이 변화를 반영하지 못한 채 예전 방식으로 열리고 있었다는 점이다. 그 결과 창을 열면 내가 실제로 쓰는 자비스 세션이 아니라 다른 기본 세션으로 먼저 들어가 혼선이 발생했고, 텔레그램 숫자 ID 세션으로 직접 토글해야 정상 대화가 가능했다. 최종적으로 Safari 아이콘의 시작 주소를 실제 사용하는 세션 URL로 바꾸어 해결했다. 이번 점검을 통해 문제의 본질은 heartbeat가 아니라 사용 세션 변화와 기본 진입 주소 불일치였음을 확인했다.

한 줄 결론:
텔레그램 세션이 새로 주세션이 되면서, 예전 웹 기본세션 주소가 뒤늦게 문제로 드러난 것이다.

치과의사가 낡은 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 렌즈를 달고 하모닉 적도의 위에 올려놓는 것. 세팅하고 밤을 기다리는 것.

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

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

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

---

제미나이를 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 자산이 된다. 결국 중요한 것은 화려한 기술보다, 정확한 원문을 꾸준히 축적하는 운영 습관이다.

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

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라는 것도 접하고 이렇게 나름 활용해보게 된다.

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