이 글은 AI 답변 자체보다, 작업이 끊겼을 때 다시 이어갈 수 있는 운영 기준을 중심으로 정리했습니다.
- 세션, 메모리, 파일, 보고 경로가 남는지 확인합니다.
- 멋진 자동화보다 실패했을 때 추적하고 되돌릴 수 있는지가 기준입니다.
- 처음 쓰는 사람에게는 기능 수보다 재개 가능성과 검증 증거가 더 중요합니다.
글 등록일: 2026-05-21
Markdown 원본은 보존하고, HTML은 빠르게 판단하는 검토 화면으로 활용합니다.
OpenClaw나 AI 에이전트에게 긴 보고서를 받을 때 Markdown 원본과 HTML 검토판을 함께 쓰는 방법을 정리했습니다. Telegram 요약, HTML 파일, 보안 주의점, 실제 프롬프트 예시까지 설명합니다.
OpenClaw 보고서를 HTML로 받으면 좋은 점과 조심할 점
이 글에서 해결하는 문제
OpenClaw를 쓰다 보면 짧은 답변보다 긴 보고서를 받을 일이 많아집니다. 일일 점검, 복구 보고, 자산 상태판, 회의록, 액션아이템처럼 한 번에 봐야 할 정보가 많아지면 Telegram 채팅만으로는 읽기가 불편해집니다.
이 글은 제가 OpenClaw 보고서를 받을 때 왜 HTML 검토판을 같이 만들기 시작했는지, 어떤 장단점이 있었는지, 실제로 어떤 식으로 요청하면 좋은지 정리한 글입니다.
왜 HTML 보고가 필요했나
처음에는 대부분의 보고를 Markdown으로 받았습니다. Markdown은 원본 기록으로 좋습니다. 파일로 남기기도 쉽고, 나중에 검색하거나 다시 편집하기도 편합니다.
하지만 긴 보고서를 사람이 빠르게 판단해야 할 때는 Markdown만으로 부족할 때가 있었습니다. 표가 길어지고, 리스크가 여러 개로 나뉘고, 다음 액션이 섞이면 어디를 먼저 봐야 하는지 흐려집니다.
Telegram에 긴 전문을 그대로 보내는 것도 좋지 않았습니다. OpenClaw의 Telegram 문서에는 메시지 chunk 제한과 media 전송 관련 설정이 있습니다. 긴 보고는 채팅에 전부 밀어 넣기보다, 짧은 요약과 별도 파일로 나누는 편이 더 안정적입니다.
그래서 제가 정한 방식은 단순합니다.
- Markdown은 원본 기록으로 남깁니다.
- HTML은 사람이 빠르게 보는 검토 화면으로 만듭니다.
- Telegram에는 5~10줄 요약과 HTML 파일 경로만 보냅니다.
HTML 보고가 좋은 경우
HTML 보고는 모든 답변에 필요한 것은 아닙니다. 짧은 질문에는 오히려 과합니다.
하지만 아래 같은 경우에는 확실히 도움이 됩니다.
- 일일 종합 보고
- 자산 또는 투자 상태판
- OpenClaw 복구/장애 진단 보고
- 회의록과 액션아이템 정리
- 여러 후보를 비교하는 표
- 리스크 점검표
- 긴 조사 결과 요약
이런 보고는 단순히 글을 읽는 것이 아니라, 상태를 판단해야 합니다. 그래서 카드, 표, 색상, 경고 박스, 다음 액션 영역이 있으면 훨씬 빠르게 볼 수 있습니다.
실제 사용법
제가 쓰는 기본 흐름은 이렇습니다.
- 먼저 Markdown 원본을 만듭니다.
- 그다음 self-contained HTML 검토판을 만듭니다.
- Telegram에는 전체 전문이 아니라 핵심 요약과 HTML 경로만 보냅니다.
- HTML에서 핵심 결론, 표, 리스크, 다음 액션을 빠르게 봅니다.
- 세부 근거가 필요하면 Markdown 원본으로 돌아갑니다.
여기서 중요한 것은 HTML이 원본을 대체하지 않는다는 점입니다. HTML은 보기 좋은 검토 화면이고, 원본 기록은 Markdown에 남기는 편이 안전합니다.
프롬프트 예시
제가 실제로 쓰기 좋은 프롬프트는 이런 형태입니다.
이 내용을 Markdown 원본으로 정리하고,
사람이 검토하기 쉬운 self-contained HTML 보고서도 같이 만들어줘.
HTML에는 핵심 결론 카드 3개, 현재 상태 표, 리스크, 다음 액션을 넣어줘.
외부 CDN, 외부 JS, iframe은 쓰지 말고 CSS만 사용해줘.
Telegram에는 5~10줄 요약과 HTML 파일 경로만 보내줘.
투자나 운영 점검처럼 숫자가 들어가는 보고라면 아래 조건을 더 붙이는 편이 좋습니다.
숫자 그래프를 넣을 때는 출처와 기준선을 함께 적어줘.
출처가 없는 숫자는 그래프로 만들지 말고 텍스트 판단으로만 남겨줘.
복구 보고라면 이렇게 요청할 수 있습니다.
복구 보고서는 변경 전 상태, 수행 조치, 검증 결과, 남은 리스크, 다음 액션으로 나눠줘.
HTML에는 성공/주의/보류 상태가 한눈에 보이게 표시해줘.
실제로 운영하며 확인한 포인트
OpenClaw를 Telegram과 함께 쓰다 보면 긴 보고를 채팅 본문 하나로 모두 처리하는 방식이 생각보다 불편해집니다. 메시지가 길어질수록 읽기도 어렵고, 나중에 다시 찾기도 어렵습니다. 그래서 긴 보고는 채팅에는 요약만 남기고, 원본과 검토용 파일을 따로 두는 편이 더 현실적이었습니다.
여러 agent를 함께 쓰는 구조에서는 장기 세션, 첨부 파일, media 경로, 메시지 전달 상태가 같이 얽힐 수 있습니다. 이때 긴 내용을 계속 채팅에 누적하면 문제를 찾기가 더 어려워집니다. 보고서를 파일로 분리해두면 원본 확인, 재검토, 복구 기록 관리가 훨씬 편해집니다.
또 HTML이나 이미지 보고를 만들 때는 “파일을 만들었다”에서 끝내면 안 됩니다. 로컬에는 파일이 있어도 실제 전달 경로에서 막힐 수 있고, 허용된 media path 밖에 있으면 Telegram 전송이 실패할 수 있습니다. 그래서 파일 생성 후에는 열림 여부와 전달 여부를 같이 확인하는 기준이 필요했습니다.
제 경험상 중요한 것은 HTML이냐 Markdown이냐의 형식 싸움이 아니었습니다. 핵심은 사람이 판단에 개입할 수 있는 구조였습니다. HTML은 예쁘게 꾸미기 위한 기능이 아니라, 긴 AI 결과를 사람이 빠르게 판단할 수 있게 바꾸는 검토 화면에 가깝습니다.
조심할 점
HTML 보고에는 단점도 있습니다.
첫째, 작업 단계가 늘어납니다. Markdown만 만들면 끝나는 일이 HTML 생성, 저장, 검증, Telegram 전송까지 이어집니다.
둘째, 첨부 경로 문제가 생길 수 있습니다. 파일은 로컬에 있는데 Telegram에는 안 보일 수 있고, media path 허용 범위가 맞지 않으면 전송이 실패할 수 있습니다.
셋째, 너무 화려하게 만들면 유지보수가 어려워집니다. 보고서는 보기 좋아야 하지만, 장식이 판단을 방해하면 안 됩니다.
넷째, 보안 기준이 필요합니다. HTML 안에 비밀번호, 토큰, 개인 정보, 내부 credential, 민감한 파일 경로가 들어가면 안 됩니다. 외부 CDN, 외부 JavaScript, iframe도 피하는 편이 안전합니다.
제가 정한 기준
저는 HTML 보고를 만들 때 아래 기준을 씁니다.
- Markdown 원본을 먼저 남긴다.
- HTML은 self-contained로 만든다.
- 외부 CDN, 외부 JS, iframe은 쓰지 않는다.
- 숫자 그래프에는 출처와 기준선을 붙인다.
- Telegram에는 요약과 파일 경로만 보낸다.
- 발행 또는 전달 전 실제 파일이 열리는지 확인한다.
- 완료라고 말하기 전에 공개 URL, 파일 경로, 첨부 여부를 확인한다.
이 기준을 두면 HTML 보고는 꽤 강력한 도구가 됩니다. 특히 복구 보고, 자산 보고, 회의록처럼 나중에 다시 봐야 하는 문서에서 효과가 컸습니다.
마무리
OpenClaw를 단순 채팅 도구로만 쓰면 HTML 보고가 과하게 느껴질 수 있습니다.
하지만 OpenClaw를 일일 점검, 복구, 투자 분석, 업무 정리처럼 실제 운영 시스템에 가깝게 쓰기 시작하면 이야기가 달라집니다. 그때는 답변을 받는 것보다, 받은 결과를 사람이 빠르게 판단하고 다시 열어볼 수 있게 만드는 것이 더 중요해집니다.
그래서 제 결론은 이렇습니다.
HTML 보고는 예쁘게 꾸미는 기능이 아닙니다. 긴 AI 결과를 사람이 빠르게 판단할 수 있게 바꾸는 검토 화면입니다. 원본은 Markdown에 남기고, 판단은 HTML에서 하고, Telegram에는 요약만 받는 구조가 가장 안정적이었습니다.
댓글
댓글 쓰기