태양광 패널의 호모그래피를 반복해서 수정하고 있어요.
저자: 김성중 · 작성일: 2026-09-05 00:00:00 · 분야: 피지컬AI
태양광 패널 호모그래피
호모그래피에서 이음(seam)을 개선하기 위해서 Claude Opus와 수 십차례 질의하고 다양한 사이트 정보를 제공했지만, WebODM에 비해 품질이 크게 나쁩니다. 특히 경사면과 건물 옥상에 설치된 태양광 패널에 대해서는 개선의 한계를 경험하고 있습니다.
그러나 정사영상 생성 속도면에서는 Sitemark와 WebODM에 비해 크게 빠르고, 메모리 사용량도 적었습니다.
개선사항
| 내용 | 근거 | RGB | IR | |
|---|---|---|---|---|
| P7 | 초점 보정 기준을 LRF 우선으로 | RelativeAltitude 는 지형 정보 없음 | 필수 | 필수 |
| P2 | 자세 스무딩 앵커 각도 게이트 | R왕복 선회를 넘어 SLERP 하던 것 | 필수 | 필수 |
| P3 | cameras.npz 에 관측 좌표 저장 | 프레임 조건수 진단용 | 진단 | 진단 |
| P4 | 스무딩된 자세를 별도 저장 | cams_opt 은 BA 직후 값 | 진단 | 진단 |
| P1 | QC block 12.5 m / shift 4.0 m | 90 이 max_shift 에 clip | 불가 | 적용 |
| P5 | 평면 계수 직접 지정 | --panel-top 으로 표현 불가 | 불필요 | 필수 |
| P6 | 2층 패널 마스크 보정 제한 | 2층 자체를 쓰지 않음 | 미사용 | 미사용 |
비행방식
① 지형에 맞는 촬영 : 드론이 지면 높낮이를 따라가며 비행, 드론-지면 거리가 어디서나 일정하게 진행합니다. 도장 크기도 고르게 유지되어 빈틈 자체가 줄어듭니다.
② 여러 층 지형 지도 사용 : 평평한 면 하나 대신, 여러 지점의 실측 높이로 울퉁불통한 지형을 그대로 반영합니다. 계단식으로 조성된 부지에 특히 효과적입니다.
③ 구역을 나눠 처리 : 부지를 몇 구역으로 나눠 구역마다 기준 높이를 따로 설정합니다. ②보다 간단하지만 구역 경계에서 다시 어긋날 수 있습니다.
정합 방식
패널 단위
스트링 단위
반사
방향 동일
개선사항
개선 정체
새 맥락 + 진단형 질문 + 실제 결과 데이터 + 명확한 성공 기준, 이 네 가지가 갖춰지면 대부분의 정체는 풀립니다.
같은 질문을 반복해도 나아지지 않는다면, 대개 문제는 모델 성능보다 질문 구조와 피드백 고리에 있습니다. 모델이 새로운 정보 없이 같은 맥락 안에서 계속 답을 짜내고 있는 상태이기 때문입니다. Claude Opus 기준으로 효과가 큰 순서대로 정리해 볼게요.
1. 맥락을 리셋하기
긴 대화에 실패한 시도들이 쌓이면, 모델은 그 시도들에 닻을 내린 채(anchoring) 비슷한 변형만 내놓기 쉽습니다. 새 대화를 열고 확정된 사실, 제약 조건, 목표만 정리해서 넘기세요. "이전에 A, B, C를 시도했고 각각 이런 이유로 실패했다"는 한 줄 요약이면 충분합니다. 이전 답변 원문을 통째로 붙이면 오히려 같은 궤도로 돌아갑니다. 메모리나 Project 지식 파일에 오래된 가정이 남아 있다면 그것도 점검해 볼 만합니다.
2. "개선 방안"이 아니라 "실패 원인"을 묻기
"어떻게 개선할까?"는 일반론을 부르는 질문입니다. 대신 이렇게 바꿔 보세요.
- "지금 결과가 왜 이렇게 나오는지 가능한 원인 가설을 5개 세우고, 각각을 구별할 수 있는 검증 실험을 제안해 줘."
- "내가 지금 틀리게 가정하고 있을 가능성이 가장 높은 전제는 뭐야?"
- "이 접근이 6개월 뒤 실패했다고 가정하고, 그 이유를 써 줘." (pre-mortem)
진단을 먼저 시키면 처방이 훨씬 구체적이 됩니다.
3. 실제 데이터를 피드백으로 주기
모델이 결과를 볼 수 없다면 개선할 근거도 없습니다. 실패한 출력 샘플, 에러 로그, 측정값, "기대한 것 vs 실제 나온 것" 비교를 직접 넣어 주세요. 가능하다면 성공 기준을 수치나 체크리스트로 명시하는 것이 좋습니다. "더 좋게"는 모델이 목표로 삼을 수 없지만, "오탐률 5% 이하"는 삼을 수 있습니다.
4. 탐색 공간을 강제로 넓히기
같은 계열의 답만 나온다면 명시적으로 막아야 합니다.
- "지금까지의 방식과 근본적으로 다른 접근 3가지를 제시해. 파라미터 조정이나 기존 방법의 변형은 제외."
- "이 분야 전문가가 아니라 [다른 분야] 전문가라면 이 문제를 어떻게 볼까?"
- "문제 정의 자체를 다르게 할 수 있다면?"
5. Opus 특성에 맞춘 조정
동의 성향을 깨기. Claude는 사용자의 프레임을 존중하는 쪽으로 기울 수 있습니다. "내 접근 자체가 잘못됐다면 솔직하게 말해 줘", "반대 입장의 리뷰어로서 비판해 줘"처럼 반박을 명시적으로 허용하면 답의 질이 달라집니다.
이유를 함께 주기. 최근 Opus 모델은 지시를 꽤 문자 그대로 따르는 편이라, "무엇을" 원하는지뿐만 아니라 "왜" 원하는지, 어떤 상황에서 쓰이는지를 알려 주면 의도에 맞게 일반화합니다.
사고 시간 확보. extended thinking을 켜거나, "답하기 전에 문제를 단계별로 분석해 줘"라고 요청하세요. XML 태그로 <context>, <failed_attempts>, <goal>처럼 정보를 구분해 주는 것도 도움이 됩니다.
불확실성 표현 허용. "확실하지 않으면 그렇다고 말하고, 판단에 필요한 추가 정보가 뭔지 알려 줘"를 넣으면, 모델이 그럴듯한 답을 억지로 만드는 대신 정보 공백을 짚어 줍니다. 사실 이게 가장 쓸모 있는 답일 때가 많습니다.
6. 루프를 자동으로 닫기
코드나 분석 파이프라인이라면 Claude Code 같은 에이전트 환경에서 테스트나 평가 스크립트를 직접 돌리게 하는 것이 가장 강력합니다. 모델이 스스로 결과를 확인하고 수정하는 순환이 생기면, 사람이 중간에서 "아직 안 돼"라고 전달하는 것보다 훨씬 빠르게 수렴합니다.