AI 도구를 설치하거나 업무 자료를 정리할 때 찾아볼 수 있는 글 117편입니다. Claude·Codex·ChatGPT·OpenClaw 사용법과 데이터 처리, 웹사이트 운영, PC 관리 내용을 주제별로 모았습니다.
Claude 활용 시리즈 · 01/13
Claude 01. 처음 켜기: 웹에서 짧은 메모 하나로 시작하기
솔루션 비제트 · Anthropic 공식 문서 참고 가이드 ·
Claude가 어떤 일을 할 수 있는지 목록부터 읽으면 첫 질문이 오히려 막막해집니다. 우선 평소 정리하기 귀찮았던 메모 몇 줄을 준비해 보세요. 회의에서 결정한 일과 아직 정하지 못한 일을 나누는 정도면 첫 대화로 충분합니다.
브라우저에서 먼저 써 보기
공식 시작 안내의 웹 주소는 claude.ai입니다. 접속해 계정을 만들거나 로그인한 뒤 대화를 시작합니다. 별도 설치 없이 요청을 시험해 볼 수 있으므로 처음부터 데스크톱 앱이나 개발 도구를 준비할 필요는 없습니다. 주소가 비슷한 다른 서비스에 로그인하고 있지 않은지도 살펴보세요.
공식 데스크톱 앱과 모바일 앱도 있습니다. 긴 문서를 읽고 고치는 작업이라면 큰 화면이 편하고, 이동 중 짧은 메모를 남길 때는 휴대전화가 편합니다. 앱을 설치할 때는 공식 다운로드 경로를 이용하고, 로그인한 계정이 웹에서 쓰던 계정과 같은지 봅니다.
정해지지 않은 일을 채워 넣지 않게
아래는 실제 회의록이 아닌 연습용 메모입니다. 날짜와 담당자가 비어 있는 부분을 그대로 남기도록 요청했습니다. 정리된 모양보다 원문에 없는 약속이 생기지 않는지가 더 중요합니다.
다음 메모를 결정 사항과 미정 사항으로 나눠 줘.
원문에 없는 담당자와 날짜는 만들지 말고 미정으로 적어 줘.
메모:
안내문은 종이와 이메일로 함께 보낸다.
발송 날짜는 다음 회의에서 정한다.
인쇄 견적은 두 곳에서 받아 보기로 했다. 담당자는 아직 없다.
결과에서 발송일과 견적 담당자가 미정으로 남아 있는지 원문과 대조합니다. 틀렸다면 메모 전체를 다시 설명하기보다 “견적 담당자는 정해지지 않았으니 그 부분만 고쳐 줘”라고 이어가면 됩니다.
앱을 설치하기 전에 알 수 있는 것
이 짧은 대화만으로도 한국어 답변의 길이, 수정 요청을 반영하는 방식, 결과를 복사해 쓰는 흐름을 살펴볼 수 있습니다. 그다음 자주 쓸 작업을 하나 더 시도하세요. 첫날부터 모든 기능을 익히려 하기보다, 내 자료를 어떤 형태로 주면 덜 고쳐도 되는지 알아가는 편이 시작하기 쉽습니다.
“고객에게 보낼 안내문을 써 줘”라고 하면 매끈한 글은 나올 수 있습니다. 하지만 읽는 사람이 신규 고객인지 기존 이용자인지, 무엇을 안내하는지에 따라 필요한 내용은 달라집니다. 답변이 엉뚱할 때는 문장을 더 공손하게 바꾸기 전에 빠뜨린 업무 조건부터 찾아보세요.
요청 한 줄에 모든 배경을 넣을 필요는 없다
배경 설명은 이번 결과를 바꾸는 정보면 됩니다. 납품 일정 안내라면 수신자, 변경 전후 날짜, 변경 사유, 회신이 필요한지가 해당합니다. 회사의 연혁이나 제품의 모든 기능을 붙이면 정작 날짜와 요청 사항이 묻힐 수 있습니다.
원문으로 제공한 내용과 작성 지시를 줄바꿈으로 나눠 적어도 읽기 쉬워집니다. 아래 요청은 일정 변경이라는 한 가지 상황에 한정했습니다. 모든 이메일에 적용할 양식은 아닙니다.
기존 고객에게 보낼 일정 변경 이메일 초안을 써 줘.
제목 한 줄과 본문 세 문단으로 작성해 줘.
확정된 사실:
- 납품일은 11월 4일에서 11월 6일로 변경
- 사유는 부품 입고 지연
- 고객에게 변경 일정으로 진행 가능한지 회신 요청
보상이나 할인은 아직 정하지 않았으니 약속하지 말아 줘.
틀린 답을 보고 조건을 보충한다
초안이 변경 사유를 길게 설명한다면 “사유는 한 문장으로 줄여 줘”라고 고칩니다. 고객의 동의가 이미 끝난 것처럼 쓰였다면 “일정 확정 통보가 아니라 가능 여부를 묻는 메일”이라고 바로잡습니다. 두 문제를 한꺼번에 ‘자연스럽게 수정’하라고 하면 무엇이 잘못됐는지 흐려집니다.
원하는 표현의 예가 있다면 짧게 붙여도 됩니다. 다만 기존 메일 전체를 복사하기보다 인사말이나 회신 요청처럼 필요한 부분만 보여 주세요. 받는 사람 이름과 계약 정보가 이번 연습에 꼭 필요한지도 생각해 볼 만합니다.
문체보다 먼저 날짜와 약속을 읽는다
수정한 초안에서 날짜가 둘 다 맞는지, 보상 약속이 들어가지 않았는지, 회신 요청이 남아 있는지부터 읽습니다. 글이 마음에 든다는 감상과 실제로 보낼 수 있다는 판단은 다릅니다. 사실과 조건이 맞은 뒤 말투를 다듬으면 수정 과정도 짧아집니다.
Anthropic의 요청 작성 문서도 결과를 평가할 기준을 먼저 정하도록 안내합니다. 여기서 기준은 거창한 점수표가 아니라 ‘변경 전후 날짜가 정확하고 승인받지 않은 약속이 없다’ 정도로 잡을 수 있습니다.
안내문을 고쳐 달라고 했더니 제품 장점이 늘어나거나 없던 실적이 붙는 경우가 있습니다. 문체 수정에 사실 보충까지 섞였기 때문입니다. 이미 내용이 정해진 글이라면 무엇을 바꿀 수 있고 무엇을 그대로 둬야 하는지 나눠서 맡기는 편이 낫습니다.
독자가 해야 할 일부터 보이게
“원활한 서비스 이용을 위한 사전 준비 사항을 안내드립니다”보다 “설치 전에 공유폴더 접근 권한을 준비해 주세요”가 행동을 바로 보여줍니다. 긴 표현이 모두 잘못은 아니지만, 날짜·준비물·회신 요청보다 앞에서 자리를 차지한다면 줄여 볼 만합니다.
수정 요청에는 독자와 글의 용도를 적습니다. 블로그 글, 설치 안내, 계약 당사자에게 보내는 이메일은 같은 말투로 쓸 필요가 없습니다. ‘친근하게’ 같은 형용사 하나보다는 “처음 설치하는 사람이 준비물을 찾을 수 있게”처럼 읽는 상황을 설명해 보세요.
아래 문장을 처음 설치하는 사람에게 보낼 안내로 고쳐 줘.
준비 사항은 그대로 두고 막연한 수식어를 줄여 줘.
지원 시간이나 성능 수치는 새로 넣지 말아 줘.
고친 문장 아래에 의미가 달라진 부분이 있는지도 적어 줘.
원문:
원활한 설치 진행을 위하여 공유폴더 주소와 접근 가능한 계정을
사전에 준비해 주시면 보다 효율적인 작업 진행이 가능합니다.
부드러운 말투가 조건까지 지우지 않도록
교정 뒤에는 원문의 명사와 숫자를 따라가며 읽어 봅니다. 위 예에서는 공유폴더 주소와 접근 가능한 계정이 둘 다 남아야 합니다. ‘설치 전 준비’가 ‘가능하면 준비’로 약해졌다면 문장은 부드러워져도 전달할 조건은 달라진 것입니다.
반대로 같은 경고를 여러 문단에서 되풀이하면 독자가 필요한 조치를 놓치기 쉽습니다. 한 번만 설명해도 되는 내용은 모으되, 해당 절차에서 꼭 필요한 조건은 그 자리에 남깁니다. 전체 글에 일괄 치환을 적용하기보다 문단별로 읽어야 하는 이유입니다.
마지막으로 소리 내어 읽어 보기
문장이 길어 숨이 끊기는 곳, 지시 대상이 불분명한 “이를 통해”, 같은 어미가 연이어 나오는 부분을 찾습니다. 모두 짧게 끊을 필요는 없습니다. 앞뒤 관계가 있는 문장은 이어 쓰고 준비물이나 순서처럼 나열해야 하는 것만 목록으로 바꿉니다.
고친 안내문을 읽고 준비할 물건과 다음 행동을 바로 알 수 있다면 교정 목적에 가까워진 것입니다. 그 자리에 없는 실적이나 사용 경험을 덧붙일 필요는 없습니다. 설명을 줄이다가 필요한 조건까지 빠지지 않았는지 마지막으로 원문과 나란히 읽어 보세요.
PDF 요약에 “12쪽 참고”라고 적혀 있어도 파일을 열어 보면 다른 내용이 나올 수 있습니다. 표지와 목차 때문에 뷰어의 페이지 순번과 종이에 인쇄된 쪽수가 어긋나기 때문입니다. 긴 자료를 맡길 때는 처음부터 어느 페이지 번호를 쓸지 정해 두면 대조하기 편합니다.
첨부가 됐다는 것과 글자를 읽었다는 것
입력창의 파일 첨부 기능으로 PDF를 올린 뒤 제목이나 첫 절을 읽어 달라고 짧게 물어봅니다. 스캔이 흐리거나 글자가 잘린 파일은 정상적으로 첨부돼도 내용을 잘못 읽을 수 있습니다. 특히 표의 단위와 각주가 보이는지 봅니다.
공식 문서는 PDF의 길이에 따라 시각 요소 처리 범위가 달라진다고 설명합니다. 확인일 기준 100페이지 이하 PDF에서는 텍스트와 시각 요소를 다루지만, 101~1000페이지는 텍스트만 처리하며 1000페이지를 넘는 PDF는 업로드할 수 없습니다. 차트가 중요한 긴 자료라면 관련 구간을 따로 준비하고 최신 첨부 제한도 확인하세요.
요약보다 찾기부터 맡긴다
첨부한 제품 설명서에서 설치에 필요한 네트워크 조건을 찾아 줘.
PDF 뷰어 기준 페이지 순번과 절 제목을 함께 적어 줘.
표의 값에는 단위와 각주 조건을 붙여 줘.
명시되지 않은 조건은 추정하지 말고 찾지 못했다고 써 줘.
먼저 관련 부분만 정리하고 전체 요약은 하지 말아 줘.
이렇게 범위를 좁히면 직접 원문을 펼쳐 검토할 양도 줄어듭니다. 응답의 페이지 번호로 이동해 절 제목이 맞는지, 조건이 다른 제품에 대한 설명은 아닌지 살펴봅니다. 번호가 어긋났다면 기준을 다시 설명한 뒤 위치부터 고칩니다.
표 한 칸을 읽을 때도 필요한 주변 정보
수치가 50이라고만 적혀 있으면 무엇을 뜻하는지 알 수 없습니다. 온도인지 동시 접속 수인지, 최대값인지 권장값인지가 함께 있어야 합니다. 병합된 머리글이나 다음 페이지로 이어지는 표는 특히 오독하기 쉬우니 원문 표와 나란히 놓고 보세요.
글자가 사진으로만 들어 있는 자료라면 OCR로 추출한 텍스트를 보조 자료로 제공할 수도 있습니다. 다만 OCR 결과 역시 원본은 아닙니다. 모델명에서 숫자 0과 영문 O가 바뀌거나 소수점이 사라지는 부분은 직접 읽어야 합니다.
찾은 내용을 보고서에 옮길 때는 파일명과 자료 발행일도 남겨 둡니다. 다음에 개정판이 나오면 어떤 버전을 근거로 썼는지 알아야 다시 확인할 수 있습니다.
같은 제품에 대해 여러 번 질문할 때마다 설명서를 첨부하는 일은 번거롭습니다. Claude 프로젝트는 이런 자료와 작업 배경을 묶어 두는 데 쓸 수 있습니다. 다만 파일을 많이 넣는 것보다 지금 유효한 자료가 무엇인지 분명한 편이 답변을 검토하기 쉽습니다.
한 제품의 한 가지 업무부터
예를 들어 제품 사용 안내 초안을 만드는 프로젝트를 준비한다면 현재 설명서, 용어 정리, 공개 가능한 기능 목록부터 넣습니다. 영업 협의 메모와 폐기된 설계안까지 한꺼번에 모으기보다 실제로 글에 반영할 자료를 골라 주세요.
프로젝트의 공통 지침에는 여러 요청에서 계속 지킬 사항을 적습니다. 매번 달라지는 글의 주제나 분량은 개별 요청에 두는 편이 관리하기 쉽습니다. 아래는 연습용 소프트웨어 설명 프로젝트에 넣을 수 있는 지침입니다.
독자: 프로그램을 처음 설치하는 사무 담당자
제품명과 메뉴 이름은 제공한 용어표를 따른다.
성능 수치와 출시 일정은 자료에 있는 내용만 쓴다.
자료끼리 충돌하면 파일명과 해당 부분을 먼저 보여 준다.
공개 글에는 내부 검토 메모를 근거로 쓰지 않는다.
개정판이 생기면 파일 관계도 정리한다
이전 설명서를 남겨야 한다면 파일명에 개정일을 붙이고 어느 문서를 우선할지 별도 메모에 적어 둡니다. “최종”, “최종2”, “진짜 최종”처럼 이름만으로 구별하기 어려운 자료는 사람이 다시 읽을 때도 헷갈립니다.
자료를 바꾼 뒤에는 변경된 항목 하나를 물어 새 설명서를 근거로 답하는지 봅니다. 프로젝트에 넣었다는 사실만으로 모든 답변이 최신판과 맞을 것이라고 생각하지 마세요. 가격이나 지원 운영체제처럼 바뀌기 쉬운 내용은 인용된 파일을 직접 펼쳐 보는 것이 좋습니다.
화면이 다른 계정을 만났을 때
공식 안내에는 기존 프로젝트와 단계적으로 배포 중인 새 프로젝트 베타가 함께 설명돼 있습니다. 메뉴 위치와 작업 방식이 다를 수 있으므로 자신이 보는 버전에 맞는 안내를 읽으세요. 자료와 지침을 관리한다는 목적은 같아도 같은 버튼 순서를 모든 계정에 적용할 수는 없습니다.
팀에서 쓸 때는 프로젝트나 대화의 공유 범위도 살펴봅니다. 작성용 자료를 모아 둔 공간과 고객에게 전달할 최종 문서는 따로 관리하세요. 초안을 공유하기 위해 내부 참고 자료까지 모두 공개할 필요는 없습니다.
문장으로 설명하기 어려운 계산은 입력칸 몇 개가 있는 화면으로 보면 이해하기 쉽습니다. Claude의 Artifacts는 대화 옆에서 결과물을 보고 수정하는 데 쓰는 기능입니다. 처음에는 회원 가입이나 외부 데이터 연결 없이 작동하는 작은 도구부터 만들어 보세요.
납품비 계산기로 범위를 줄여 보기
연습 주제는 수량과 단가, 배송비를 넣으면 합계를 보여 주는 계산기입니다. 실제 견적서가 아니라 계산 흐름을 확인하는 예제이므로 세금, 할인, 환율은 이번 범위에서 빼겠습니다. 화면을 그리기 전에 계산식을 먼저 정해 두면 수정할 때 기준이 생깁니다.
수량, 단가, 배송비를 입력하는 계산 화면을 Artifact로 만들어 줘.
합계 = 수량 × 단가 + 배송비로 계산하고 원 단위로 표시해 줘.
빈 입력과 음수는 합계를 내지 말고 안내를 보여 줘.
회원 가입, 결제, 외부 서버 연결, 데이터 저장은 넣지 말아 줘.
휴대전화에서도 입력칸과 결과가 잘리지 않게 배치해 줘.
공식 안내에 따르면 Artifacts를 쓰려면 파일 생성·편집에 해당하는 기능이 켜져 있어야 합니다. 결과가 일반 채팅 답변으로만 나오면 계정의 기능 설정과 현재 지원 범위를 살펴보세요. 템플릿과 공유 기능은 결과 종류와 요금제에 따라 다를 수 있습니다.
그럴듯한 화면과 맞는 계산은 따로 본다
수량 3, 단가 12,000원, 배송비 3,000원을 넣었다면 합계는 39,000원입니다. 이 값을 먼저 대조한 뒤 입력을 비우거나 수량을 음수로 바꿔 봅니다. 안내가 뜬 상태에서 직전 합계가 그대로 남아 오해를 주지 않는지도 살펴볼 수 있습니다.
금액에 쉼표를 넣었을 때, 배송비를 0으로 입력했을 때, 화면 폭을 줄였을 때도 확인합니다. 잘못된 값이 나오면 “계산이 틀린다” 대신 입력한 값과 기대한 합계를 알려 주세요. 색상 수정과 계산 오류 수정을 한꺼번에 맡기지 않으면 바뀐 이유를 따라가기 쉽습니다.
링크를 보내기 전에 담긴 내용을 읽는다
공유할 수 있는 결과라도 바로 공개할 필요는 없습니다. 연습용 수치 대신 고객 단가나 내부 조건을 넣었다면 먼저 지우고 공유 설정을 읽습니다. 링크가 열리는지와 받는 사람이 보게 되는 내용은 별도 창이나 허용된 다른 계정에서 점검할 수 있습니다.
예제 계산기를 업무에 쓰려면 소수점 처리, 세금, 최대 입력값 같은 추가 규칙이 필요합니다. 화면이 만들어졌다는 이유만으로 견적 계산이 검증됐다고 볼 수는 없습니다. 여기서는 위에 정한 계산식과 입력 조건까지만 확인합니다.
세 금액을 부호 그대로 더하면 180,000원입니다. 이 작은 결과를 맞추는지 보고 실제 자료의 규칙을 이어 설명합니다. 같은 거래번호가 여러 줄인 것이 중복 오류인지 품목별 상세인지도 미리 알려줘야 합니다.
파일 형식보다 계산 범위를 먼저 정한다
공식 첨부 안내에는 CSV를 포함한 여러 문서 형식이 나와 있습니다. 다만 첨부 지원과 계산 도구의 실행 여부는 따로 봐야 합니다. 계산을 실행했는지, 텍스트를 읽고 설명한 것인지 결과에서 구별하고 계산식이나 사용한 코드를 요청할 수 있습니다.
이 CSV에서 상태가 확정인 행만 합산해 줘.
금액은 원 단위이고 환불은 이미 음수로 기록돼 있어.
원본은 고치지 말고 포함 행 수, 제외 행 수, 합계를 알려 줘.
거래번호가 반복되면 임의로 지우지 말고 따로 목록을 보여 줘.
실제로 계산에 쓴 식이나 코드를 함께 적어 줘.
빈칸을 0으로 볼 것인가
금액이 비어 있는 행은 합계에 0으로 넣어도 되는지, 입력 누락으로 따로 처리해야 하는지 정합니다. 숫자 열에 “미확정”이라는 문자가 섞였을 때도 마찬가지입니다. 조용히 제외한 뒤 합계만 보고하면 누락을 알아차리기 어렵습니다.
최종 결과는 원본 행 수와 포함·제외 행 수를 대조합니다. 기간 필터를 썼다면 첫날과 마지막 날이 포함됐는지도 봅니다. 합계 하나만 맞추기보다 어떤 행을 계산했는지 남기는 편이 다음 달 자료에도 같은 규칙을 적용하기 쉽습니다.
공유할 표를 따로 만들 때는 고객 연락처처럼 계산에 필요 없는 열을 제거할 수 있습니다. 금액 결과와 개인정보가 담긴 원본을 같은 파일로 전달해야 하는지 한 번 더 판단하세요.
“지금도 무료인가요?”라는 질문은 답변만 읽고 끝내기 어렵습니다. 검색 결과가 예전 행사 안내를 근거로 들었다면 당시에는 맞아도 지금은 다를 수 있기 때문입니다. Claude로 최신 정보를 찾을 때는 요약문과 함께 원문 날짜, 적용 대상, 예외를 살펴봐야 합니다.
무엇을 언제 기준으로 찾는지 적는다
제품명만 주고 장단점을 묻기보다 운영체제, 사용할 기능, 확인 기준일을 적어 보세요. 공식 웹 검색 안내는 검색을 사용할 때 출처 인용을 제공한다고 설명합니다. 실제 답변에서는 검색이 이뤄졌는지, 인용 링크가 붙었는지부터 읽습니다.
오늘 기준으로 이 프로그램의 Windows 설치 지원 정보를 찾아 줘.
제조사의 설치 안내와 릴리스 노트를 우선해 줘.
최소 운영체제, 설치 방식, 공식 다운로드 주소를 정리해 줘.
각 항목에 출처 링크를 달고 문서의 적용 버전도 적어 줘.
서로 다른 안내가 있으면 하나로 합치지 말고 차이를 보여 줘.
검색할 때는 ‘오늘’이 언제인지 결과를 저장할 문서에 날짜로 적어 두면 좋습니다. 같은 질문을 다음 달 다시 해도 당시 무엇을 기준으로 판단했는지 알 수 있습니다. 접속일과 원문 발행일은 각각 남깁니다.
검색을 따로 켜는 화면에서는 입력창의 추가 메뉴에서 웹 검색을 선택합니다. 새 사용 환경에서는 별도 전환 버튼 없이 필요에 따라 검색하므로 버튼이 없다는 이유만으로 기능이 빠졌다고 판단하지 마세요. 조직 계정은 관리자 설정도 영향을 줄 수 있습니다.
제목이 비슷해도 다른 상품일 수 있다
인용을 눌렀다면 본문에서 해당 조건을 찾습니다. 개인용과 기업용, 웹 서비스와 API, 정식판과 미리보기는 요금이나 지원 범위가 다를 수 있습니다. 검색 결과의 짧은 설명만으로 범위를 결정하지 말고 문서 제목과 대상 제품까지 읽어 보세요.
직접 링크를 전달할 수도 있지만 모든 사이트를 읽을 수 있는 것은 아닙니다. 로그인 화면이나 일부만 읽힌 페이지라면 원문 전체를 봤다고 가정하지 않습니다. 필요한 부분을 적법하게 제공하거나 공개된 공식 문서로 바꿔 찾는 편이 낫습니다.
의견을 사실처럼 옮기지 않기
“쓰기 편하다”는 사용자의 평가이고 “Windows를 지원한다”는 확인 가능한 제품 조건입니다. 두 내용을 같은 표에 넣을 때는 평가와 공식 조건을 구별하세요. 후기를 참고하더라도 그 사람이 쓴 버전과 사용 환경이 내 상황과 같은지 봅니다.
찾은 결과를 블로그에 쓸 때는 필요한 사실을 자기 문장으로 정리하고 근거 링크를 가까이에 둡니다. 다른 글의 표현이나 사례를 길게 가져올 필요는 없습니다. 적용 조건이 바뀌었을 때 수정할 수 있도록 자료를 읽은 날짜도 남겨 주세요.
일정을 읽어 달라는 요청과 참석자에게 초대를 보내 달라는 요청은 결과가 다릅니다. Claude의 커넥터는 외부 서비스에서 자료를 찾거나 작업을 하는 연결 수단입니다. 연결 버튼을 누르기 전에 이번에 필요한 일이 읽기인지 실제 변경인지 정해 두면 권한 설명도 이해하기 쉽습니다.
연결할 계정과 서비스부터
커넥터 목록에서 제공자, 읽기·쓰기 기능, 이용 가능한 환경을 읽습니다. 로그인 안내에서 회사 계정과 개인 계정 중 어느 것을 연결하는지 살펴보세요. 서비스에 따라 조직 관리자가 연결을 허용해야 하거나 각 사용자가 별도로 인증해야 할 수 있습니다.
공식 문서에 따르면 일반적으로 연결된 서비스에서 사용자가 가진 권한이 접근 범위에 반영됩니다. 공용 자격 증명을 쓰는 커스텀 커넥터는 그 자격 증명의 범위를 따릅니다. “내 계정으로 로그인했다”는 말만으로 모든 연결의 범위가 같다고 생각하면 안 됩니다.
첫 요청은 찾은 자료를 보여 주는 데까지
연결한 문서 서비스에서 제품 안내문 초안을 찾아 줘.
파일 제목, 수정일, 링크를 먼저 목록으로 보여 줘.
이번 요청은 찾기만 하고 파일 수정이나 메시지 발송은 하지 말아 줘.
같은 제목이 여러 개면 임의로 최종본을 정하지 말고 모두 알려 줘.
검색 결과에서 원본 링크가 열리는지 확인한 뒤 필요한 파일을 지정합니다. 이어서 이메일 초안을 만들더라도 발송할 때는 받는 사람, 본문, 첨부파일, 보내는 계정을 별도로 볼 수 있게 요청하세요. 초안을 만들었다는 설명이 발송 완료를 뜻하지는 않습니다.
연결 해제와 이미 만든 결과
작업이 끝나면 더 이상 필요 없는 연결을 유지할지 판단합니다. 연결을 끊는 것과 이전 대화에 복사된 내용이나 이미 만든 문서를 지우는 것은 별개입니다. 자료를 잘못 가져왔다면 어떤 대화와 출력 파일에 포함됐는지 함께 살펴야 합니다.
개인용 Claude의 모델 개선 설정은 설정의 개인정보 항목에서 변경할 수 있습니다. 이 설정과 외부 서비스 접근 권한도 서로 다른 문제입니다. 회사 자료라면 회사가 허용한 계정과 연결 방식을 먼저 따르세요. 모델 개선 설정만 바꿨다고 사내 문서를 임의로 올려도 되는 것은 아닙니다.
처음부터 메일함 전체나 모든 문서를 대상으로 시험할 필요는 없습니다. 공개해도 되는 연습 파일 하나를 두고 검색 결과와 원문을 대조하면 연결이 어떻게 작동하는지 살펴볼 수 있습니다.
Claude에 코드를 붙여 넣어 질문하는 것과 프로젝트 폴더에서 Claude Code를 실행하는 것은 작업 방식이 다릅니다. 후자는 도구를 통해 파일을 읽고 고치거나 명령을 실행할 수 있습니다. 처음에는 중요한 작업이 진행 중인 폴더 대신 작게 만든 연습 저장소에서 시작하세요.
Windows에서는 설치 경로 하나를 고른다
공식 문서는 네이티브 설치 프로그램, WinGet 등 여러 경로를 안내합니다. 여기서는 WinGet을 쓸 수 있는 Windows에서의 예를 들겠습니다. 이미 다른 방식으로 설치했다면 새로 겹쳐 설치하기 전에 현재 실행 경로와 설치 방식을 살펴보세요.
winget install Anthropic.ClaudeCode
설치가 끝나면 새 터미널을 열어 버전이 출력되는지 봅니다. 아래 명령은 설치 상태와 실행 파일 위치를 알아보는 용도입니다. 버전 번호가 나온다면 실행 파일은 찾은 상태이며, 계정 로그인과 첫 요청은 그다음 단계입니다.
claude --version
Get-Command claude
폴더를 연 다음 로그인한다
파일 탐색기나 터미널에서 연습 프로젝트 위치를 확인하고 그 폴더로 이동한 뒤 claude를 실행합니다. 화면의 로그인 안내에서 사용할 계정과 이용 경로를 선택하세요. 개인 구독과 API 계정은 사용량과 청구 방식이 다를 수 있으므로 이미 가지고 있는 로그인이라는 이유만으로 아무 항목이나 고르지 않습니다.
이 폴더의 파일 역할과 실행 방법을 설명해 줘.
아직 파일은 수정하지 말아 줘.
설명한 내용의 근거가 되는 파일 경로를 함께 적어 줘.
응답에 나온 파일이 실제 폴더에 있는지 보고, 테스트 명령이 있다면 프로젝트에서 쓰는 명령과 맞는지 읽습니다. 구조 설명이 맞은 뒤 오탈자 한 곳 정도의 변경으로 넘어가면 됩니다.
실행되지 않을 때 다시 설치하기 전에
명령을 찾지 못하면 새 터미널에서도 같은지, 설치 경로가 PATH에 들어 있는지부터 살펴봅니다. 버전은 나오는데 로그인에 실패하면 설치보다 인증이나 네트워크 쪽 문제일 수 있습니다. 오류 문구를 남기되 인증 코드나 키는 공개하지 마세요.
WinGet 설치의 업데이트 명령은 winget upgrade Anthropic.ClaudeCode입니다. 네이티브 설치의 자동 업데이트와 관리 방식이 다르므로 처음 선택한 경로에 맞춰 유지합니다. Windows와 WSL 중 어디에 설치했는지, 프로젝트와 필요한 도구가 어디에 있는지도 함께 기록해 두세요.
같은 프로젝트에서 작업할 때마다 “이 폴더는 배포 결과물이니 원본을 고쳐야 한다”고 반복 설명한다면 파일로 남길 만합니다. Claude Code의 CLAUDE.md는 이런 프로젝트 지침을 전달하는 데 씁니다. 길게 쓴 규칙보다 저장소의 실제 작업 방식과 맞는 규칙이 필요합니다.
코드에서 알기 어려운 이유를 적는다
폴더 이름만으로 알 수 없는 운영 사정이나 팀에서 정한 배포 조건을 적어 보세요. 예를 들어 고객에게 전달한 파일명이라 바꾸면 안 되는 경우, 생성 파일 대신 원본을 수정해야 하는 경우가 있습니다. 이유까지 한 줄 덧붙이면 예외 상황에서도 판단하기 쉽습니다.
# 사이트 작업 메모
- docs/generated/는 생성 결과물이다. 수정은 원본 템플릿에서 한다.
- 다운로드 파일명은 기존 고객 안내와 연결돼 있으므로 변경하지 않는다.
- 문의 양식을 바꾼 경우 빈 입력과 정상 입력을 각각 확인한다.
- 테스트를 실행하지 못했다면 이유를 완료 보고에 적는다.
위 경로와 규칙은 설명용입니다. 자신의 저장소에 없는 폴더나 검사 명령을 그대로 복사하지 마세요. 처음에는 실제로 자주 놓치는 조건 서너 개로 시작하고, 작업하면서 불필요한 규칙을 줄여도 됩니다.
자동 메모리와 직접 쓰는 지침
공식 문서는 사용자가 작성하는 지침 파일과 Claude가 작업 중 남기는 자동 메모리를 구별합니다. 직접 관리할 운영 규칙은 지침에 적고, 자동으로 남은 내용도 가끔 읽어 오래된 판단이 있는지 살펴보세요. 둘 다 대화 맥락을 돕는 자료이며 접근 제어 설정을 대신하지는 않습니다.
사용자 전체에 적용할 규칙과 이번 저장소에만 필요한 규칙도 나눕니다. 특정 프로젝트의 파일명 제한을 전역 지침에 넣으면 다른 저장소에서도 불필요한 제약이 될 수 있습니다. 하위 폴더에 별도 지침이 있다면 어느 범위에서 읽히는지도 공식 탐색 규칙과 대조합니다.
지침을 고친 날에는 작은 요청으로 읽어 보기
“현재 작업에 적용되는 지침 파일과 관련 규칙을 알려 줘”라고 요청한 뒤 실제 경로와 설명을 봅니다. 파일명이 틀렸거나 다른 폴더에서 실행했다면 내용을 아무리 강조해도 원하는 지침을 읽지 못할 수 있습니다.
규칙에 적힌 테스트가 없어졌다면 문서도 함께 고칩니다. 모순된 지침을 남긴 채 새 대화마다 예외를 설명하는 방식은 관리하기 어렵습니다. 계정 비밀번호나 API 키는 작업 규칙이 아니므로 이 파일에 넣지 않습니다.
“검색 오류를 고쳐 줘”라는 요청만으로는 어떤 상태가 정상인지 알기 어렵습니다. 빈 검색어에서만 실패하는지, 특정 글자에서 실패하는지부터 좁혀야 합니다. Claude Code에도 같은 입력과 기대 결과를 주면 수정 뒤 무엇을 다시 확인할지가 분명해집니다.
오류가 나는 순서를 적는다
현재 브랜치와 커밋하지 않은 변경을 확인하고 시작합니다. 이미 수정 중인 파일이 있다면 그 목적도 알려 주세요. 재현 정보에는 화면 또는 명령, 입력값, 실제 결과, 기대 결과가 들어가면 됩니다. 로그 전체보다 오류와 직접 관련된 부분을 골라 주는 편이 읽기 쉽습니다.
검색 화면에서 입력칸을 비운 채 조회하면 오류가 발생해.
기대 결과는 오류 없이 빈 검색어 안내를 보여 주는 것이야.
일반 검색과 기존 API 응답 형식은 유지해 줘.
먼저 관련 코드를 찾고 원인을 설명한 뒤 필요한 부분을 수정해 줘.
빈 입력과 일반 입력을 검증하고 실행한 명령과 결과를 알려 줘.
커밋과 푸시는 아직 하지 말아 줘.
원인 설명에 나온 파일과 실제 변경 파일이 이어지는지 봅니다. 단순 입력 오류를 고치면서 인증이나 데이터 형식까지 바뀌었다면 왜 필요한지 검토해야 합니다. 수정 범위를 줄이되 같은 원인에서 생기는 오류까지 놓치지 않도록 관련 호출부를 함께 살펴봅니다.
권한 요청은 실행할 일을 읽는 기회
Claude Code의 동작은 권한 모드와 허용 규칙의 영향을 받습니다. 명령 실행이나 파일 변경을 요청받으면 대상과 이유를 읽으세요. 계획을 세워 달라는 요청과 실제 편집·배포까지 맡기는 요청은 범위가 다릅니다. 작업 지침에 적었다는 이유만으로 실행 권한이 설정되는 것도 아닙니다.
통과했다고 적힌 검사만 보지 않기
테스트가 통과했더라도 빈 입력을 실제로 다루는 검사인지 봅니다. 실행하지 못한 검사는 통과한 검사와 따로 남겨야 합니다. 화면 문제라면 브라우저에서 오류 문구와 입력 유지 여부를 직접 볼 필요도 있습니다.
마지막에는 git diff로 요청과 관계없는 수정이 섞였는지 읽습니다. 테스트를 위해 만든 임시 자료나 로그가 전달 파일에 포함되지 않았는지도 봅니다. 검토할 기준은 최종 요약의 자신감보다 재현 조건, 변경된 코드, 실행 결과가 서로 맞는지입니다.
변경을 확정할 때는 검토한 파일을 커밋하고, 원격 반영과 배포는 요청한 범위에 따라 진행합니다. 로컬에서 고쳤다는 사실만으로 공개 서비스까지 바뀐 것은 아닙니다.
유료 구독인데도 사용량 제한이 나왔다면 결제가 잘못됐다고 단정하기 쉽습니다. 하지만 구독에 포함된 사용량, 추가 사용 크레딧, API 사용 내역은 같은 항목이 아닙니다. 먼저 어느 화면에서 어떤 제한을 보고 있는지 알아야 다음 조치를 정할 수 있습니다.
대화 횟수 하나로 계산하기 어려운 이유
공식 요금 안내는 대화 길이, 모델, 사용 기능 등에 따라 소비량이 달라진다고 설명합니다. 같은 구독이라도 짧은 질문과 긴 파일 분석을 똑같은 한 번으로 볼 수는 없습니다. 웹과 앱, Claude Code가 공유하는 사용량도 있으므로 현재 계정의 사용량 화면을 살펴보세요.
제한 안내에서는 초기화 시각과 어느 항목이 소진됐는지를 기록합니다. 시간대도 함께 보면 기다려야 하는 시간을 오해할 가능성이 줄어듭니다. 고정된 메시지 수를 외워 두기보다 해당 계정에 표시된 남은 사용량을 기준으로 판단하는 편이 낫습니다.
추가 사용을 켜기 전에 지출 한도부터
유료 계정에서 추가 사용 크레딧을 활성화하면 포함 사용량을 넘긴 뒤 별도 비용이 발생할 수 있습니다. 계속 쓰는 것이 목적이라도 월 지출 한도와 자동 충전 여부를 먼저 읽어 보세요. 한도를 무제한으로 바꿔야 작업이 가능하다고 생각할 필요는 없습니다.
사용량을 살펴볼 때 구별할 항목
항목
살펴볼 내용
구독에 포함된 사용량
현재 요금제, 남은 양, 초기화 시각
추가 사용 크레딧
활성화 여부, 잔액, 월 한도, 자동 충전
API 사용
Console의 사용 내역, 청구 대상 조직, 적용 크레딧
API 키를 쓰는 프로그램은 Console에서도 본다
Claude 구독과 API는 용도가 다른 상품이며 청구도 구별됩니다. 일부 요금제에 API 크레딧 혜택이 있어도 API가 무제한 포함된다는 뜻은 아닙니다. API를 호출하는 프로그램이라면 Console에서 사용량과 크레딧 적용 여부를 확인하세요.
문제가 생겼을 때 계정을 바꾸거나 다시 결제하기 전에 로그인 계정과 조직부터 대조합니다. 오류가 로그인 실패인지, 사용량 제한인지, 결제 관련 안내인지 적어 두면 지원을 요청할 때도 상황을 설명하기 쉽습니다. API 키나 결제 정보 자체를 문의 글에 공개하지는 마세요.
긴 작업을 다시 시작하기 위한 짧은 기록
제한 때문에 작업을 멈춰야 한다면 완료한 부분, 남은 질문, 기준 파일의 이름을 남겨 둡니다. 다음 대화에서 모든 자료를 무작정 다시 붙이기보다 아직 필요한 부분을 골라 이어갈 수 있습니다. 요금과 혜택은 바뀔 수 있으므로 결제 직전에는 아래 공식 안내와 본인 계정 화면을 다시 읽어 주세요.
OpenClaw를 시작하기 전에 Gateway, 모델, 채널이 각각 무슨 일을 하는지 알아두면 설치 과정이 덜 헷갈립니다. 첫 목표는 메신저나 자동화 연결이 아니라 짧은 질문에 답을 받는 것으로 잡겠습니다. 기능은 그 뒤에 하나씩 붙이면 됩니다.
요청은 어디로 흘러가나
Gateway는 OpenClaw의 실행과 연결을 관리하는 중심 프로세스입니다. 브라우저의 Control UI나 메시지 채널에서 요청을 받으면 설정한 모델과 도구를 사용해 처리합니다. 모델 공급자는 실제 추론을 제공하고, Telegram·Discord 같은 채널은 대화가 들어오고 나가는 창구입니다.
내 PC에 Gateway가 있다고 모델 추론까지 모두 PC 안에서 실행되는 것은 아닙니다. 외부 API를 선택했다면 입력이 해당 서비스로 전달됩니다. 프로그램 설치 비용과 모델 API·외부 도구 이용 비용도 별도로 확인해야 합니다.
처음에는 모델 하나만
메신저 봇, 스킬, 예약 작업을 동시에 추가하면 실패한 구간을 구분하기 어렵습니다. 먼저 본인 계정으로 모델 하나를 연결하고 대시보드에서 짧은 답변을 받는 것을 첫 목표로 삼으세요. 실제 고객 문서 대신 새로 만든 가상 메모를 사용하면 연결 상태를 확인하기에 충분합니다.
공식 문서와 설치한 릴리스의 기능이 다를 수 있으므로 버전과 도움말을 함께 확인합니다. 이 글의 명령어는 읽고 선택해서 실행할 예시입니다. 명령 블록 전체를 한 번에 복사하기보다 각 단계의 결과를 확인하며 진행하세요.
openclaw --version
openclaw --help
첫 실습의 범위
설치할 PC, 사용할 모델 계정, 허용할 폴더, 결과를 확인할 사람을 미리 정합니다. 첫 성공 기준은 “Gateway가 실행되고, 가상 메모 질문에 답하며, 종료 방법을 안다” 정도로 잡을 수 있습니다. 파일 변경이나 외부 발송은 그 다음에 별도로 시험하세요.
OpenClaw 02. Windows 설치: 데스크톱 앱·PowerShell·WSL2 중 선택하기
솔루션 비제트 · 공식 문서 기반 사용 안내 ·
Windows 설치 문서를 보면 앱, PowerShell, WSL2가 함께 나옵니다. 세 가지를 전부 설치하라는 뜻은 아닙니다. 관리하기 편한 경로 하나를 고르고, 설정과 Gateway가 어느 환경에 생기는지 알아두세요.
화면으로 시작하는 Windows Hub
공식 Windows 문서에서 연결한 Windows Hub 릴리스 페이지를 열고 PC 아키텍처에 맞는 설치 파일을 선택합니다. 설치 뒤 OpenClaw Companion을 실행해 로컬 설정 또는 기존 Gateway 연결을 선택합니다. 현재 Hub의 로컬 설정은 앱이 관리하는 WSL Gateway를 준비하는 방식이므로 단순히 기존 Ubuntu에 설치한 것과 구분해야 합니다.
이미 사용 중인 Gateway가 있다면 새 로컬 인스턴스를 추가하기 전에 연결 대상을 확인하세요. 트레이가 연결 상태를 보여주더라도 모델 답변까지 검증된 것은 아니므로 이후 대화 시험을 진행합니다. 앱과 CLI는 버전 배포 주기가 다를 수 있습니다.
PowerShell에서 CLI 설치
아래는 공식 설치 스크립트 명령입니다. 원격 스크립트를 가져와 실행하므로 공식 도메인과 스크립트 내용을 확인한 뒤 선택한 경로에서 실행하세요. 설치가 끝나면 같은 PowerShell에서 버전과 상태를 확인하고, 명령을 찾지 못하면 새 터미널과 PATH를 점검합니다.
iwr -useb https://openclaw.ai/install.ps1 | iex
openclaw --version
openclaw gateway status
Linux 환경을 쓰려면 WSL2
Linux 환경과의 호환성이 필요한 경우 공식 Windows 문서의 WSL2 절차를 따릅니다. 설치와 실행은 해당 배포판의 Linux 터미널에서 하고, PowerShell용 명령과 섞지 마세요. Windows와 WSL의 경로·환경변수·서비스는 구분해 관리해야 합니다. WSL2를 준비한 뒤에는 다음 편의 Linux 설치 흐름을 참고할 수 있습니다.
macOS나 Linux에서는 공식 설치 스크립트로 CLI를 준비할 수 있습니다. 직접 관리하는 Node.js를 쓸 수도 있으니 현재 버전부터 보세요. Windows에서 WSL2를 골랐다면 아래 명령은 PowerShell이 아니라 Linux 터미널에서 실행합니다.
Node.js 버전부터 확인
터미널에서 Node.js 버전을 확인합니다. 문서 확인일 기준 공식 설치 안내는 Node 24.16 이상 또는 26.1 이상 경로를 제시하고 Node 26을 권장합니다. 오래된 글의 “Node 22면 충분” 같은 조건을 그대로 적용하지 말고 설치할 릴리스의 요구사항을 다시 확인하세요.
node --version
Node가 없는 경우 공식 설치 프로그램이 준비하는 방식과 운영체제 지원 범위를 설치 문서에서 확인합니다. 조직에서 런타임을 관리한다면 승인된 경로를 사용하세요. 소스 빌드용 도구를 처음부터 모두 설치할 필요는 없습니다.
설치 스크립트 실행
아래 명령은 공식 스크립트를 내려받아 실행합니다. 실행 전 주소와 내용을 확인하고, 진행 중 표시되는 설치 경로와 오류를 읽습니다. 보통 설치 후 초기 설정 흐름이 이어지므로 이미 설정을 끝냈다면 다음 편에서 중복 생성하지 않도록 현재 상태부터 확인하세요.
npm으로 직접 설치하는 방법도 있지만 npm 버전에 따라 패키지 설치 스크립트 허용 옵션이 다를 수 있습니다. 직접 설치를 선택했다면 현재 공식 npm 절차를 따르고, 여러 설치 방식을 한꺼번에 적용하지 마세요.
설치됐는데 명령을 못 찾을 때
openclaw를 찾지 못한다면 PATH와 새 터미널 적용 여부, 어떤 Node 환경에 설치했는지 확인합니다. 명령은 실행되는데 Gateway가 멈추는 경우는 다른 단계의 문제입니다. 무조건 관리자 권한으로 다시 설치하기보다 나온 오류와 설치 경로를 기록해 원인을 좁히세요.
설치 뒤에는 온보딩에서 모델 계정과 작업 환경을 연결합니다. 설정이 저장됐다고 모델 응답까지 된 것은 아닐 수 있습니다. 모델 검증 결과를 보고 Gateway가 실행 중인지 확인한 다음 대시보드를 열어보겠습니다.
대화형 초기 설정
openclaw onboard
새 환경에서 Quick start와 Custom setup 같은 선택지가 나오면 필요한 설정 범위에 맞게 고릅니다. 자동 감지된 연결도 어떤 계정과 서비스인지 확인한 뒤 선택하세요. 접근 범위 등을 검토하고 싶다면 상세 설정을 따라가는 편이 좋습니다. 기존 설정이 있으면 화면 흐름이 다를 수 있습니다.
현재 공식 흐름은 선택한 모델 연결을 실제 응답으로 검증할 수 있습니다. 이 검증도 공급자 이용량에 반영될 수 있습니다. “나중에 설정”으로 넘어가 준비만 저장한 상태와 실제 모델 연결이 성공한 상태를 구분해 기록합니다.
전경 실행과 서비스 설치
빠른 시작에서 Gateway가 현재 터미널의 전경 프로세스로 실행된다면 Ctrl+C로 멈출 수 있습니다. 계속 실행할 서비스가 필요할 때는 먼저 전경 Gateway를 멈춘 뒤 공식 서비스 설치 절차를 따릅니다. 같은 포트에 두 프로세스를 동시에 띄우지 않도록 하세요.
openclaw gateway install
openclaw gateway status
서비스 관리 방식은 macOS, Linux·WSL2, 네이티브 Windows가 다릅니다. 재부팅이나 로그아웃 후 동작은 설치 환경에 따라 확인해야 합니다. 상태 출력에서 실행 중인지 확인한 뒤 대시보드를 엽니다.
대시보드에서 첫 답변 받기
openclaw dashboard
대시보드가 열리고 짧은 질문에 답변이 오면 기본 경로를 확인한 것입니다. 채팅이 실패하면 모델 인증 문제인지 Gateway 연결 문제인지 나누어 봅니다. 공급자 변경은 온보딩으로, 추가 설정은 현재 버전의 configure 안내로 진행하며 설정을 통째로 지우지 않습니다.
OpenClaw 06. 작업 공간과 메모리: AGENTS.md·SOUL.md를 관리하는 방법
솔루션 비제트 · 공식 문서 기반 사용 안내 ·
반복해서 설명하는 보고서 규칙은 작업 공간의 지침 파일에 적을 수 있습니다. 먼저 현재 Gateway가 어느 폴더를 쓰는지 찾아보세요. 예전에 만든 비슷한 폴더를 고치면 규칙을 적어도 반영되지 않을 수 있습니다.
지금 쓰는 작업 공간 찾기
기본 작업 공간은 보통 ~/.openclaw/workspace이지만 프로필이나 환경변수, 에이전트 설정에 따라 달라집니다. Windows Hub·WSL2·원격 Gateway를 쓴다면 해당 Gateway 쪽의 경로를 확인하세요. 비슷한 이름의 예전 폴더를 수정해도 현재 에이전트에 반영되지 않을 수 있습니다.
작업 공간은 도구가 사용하는 기본 폴더이며 그 자체가 강제 격리 경계는 아닙니다. 다른 폴더 접근을 기술적으로 제한하려면 샌드박스와 도구 정책을 별도로 설정해야 합니다. 지침 파일에 금지 문장을 쓰는 것만으로 파일 권한이 바뀌지는 않습니다.
작업 규칙과 말투 나눠 적기
AGENTS.md에는 작업 순서와 확인 기준 같은 운영 규칙을, SOUL.md에는 말투와 응답 원칙을 정리할 수 있습니다. 대시보드에서 해당 파일 편집 기능을 제공하면 현재 작업 공간인지 확인한 뒤 수정하세요. 전체 템플릿을 덮어쓰기보다 필요한 항목만 바꾸고 사본을 남깁니다.
# 실습용 운영 규칙 예시
- 실제 파일 변경 전에 대상과 계획을 보여준다.
- 입력에 없는 날짜와 수량은 확인 필요로 표시한다.
- 가상 메모와 실제 고객 자료를 구분한다.
기억할 정보와 남기지 않을 정보
MEMORY.md와 일별 메모 같은 파일은 목적에 맞게 관리하고, 비밀 키를 업무 지침에 적지 않습니다. 모든 대화가 영구적으로 완전하게 저장되거나 자동으로 회상된다고 가정하지 마세요. 메모리 기능과 저장 위치는 사용하는 버전의 공식 안내를 확인하고 오래된 규칙의 폐기 여부도 기록합니다.
대시보드에서 답변을 받았다면 Telegram 봇을 연결해 볼 차례입니다. 토큰은 봇을 연결하는 값이고, 페어링은 대화 상대를 승인하는 절차입니다. 처음에는 본인 DM만 열고 그룹 설정은 나중에 다루겠습니다.
BotFather에서 토큰 받기
Telegram에서 계정명이 정확히 @BotFather인지 확인하고 /newbot을 실행해 안내에 따라 이름과 사용자명을 정합니다. 발급된 토큰은 봇 제어에 필요한 비밀 값이므로 채팅 기록이나 화면 캡처로 공개하지 않습니다. 유출했다면 BotFather에서 교체 절차를 진행해야 합니다.
OpenClaw의 채널 추가 흐름을 열어 Telegram을 선택하고 로컬 설정 단계에서 토큰을 등록합니다. 현재 버전의 입력 옵션은 도움말과 공식 설정 문서를 확인하세요. Telegram은 QR 로그인 채널처럼 channels login telegram을 사용하는 방식이 아닙니다.
openclaw channels add
openclaw channels status --probe
첫 DM의 페어링 승인
Gateway가 실행 중인 상태에서 새 봇에 본인 Telegram 계정으로 메시지를 보냅니다. 페어링 정책에서는 연결 코드가 생성됩니다. Gateway가 있는 환경에서 요청 목록을 확인한 뒤 본인 요청만 승인하세요. 아래 <CODE>는 받은 실제 코드로 바꿉니다.
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>
승인 후 다시 짧은 질문을 보내 응답을 확인합니다. 토큰이 정상이어도 모델 인증이 실패하면 답변은 오지 않을 수 있습니다. 채널 상태와 모델 상태를 별도 확인하고, 오래된 페어링 코드는 새 요청을 만들어 확인하세요.
그룹에 넣을 때의 별도 설정
개인 DM 승인만으로 모든 그룹을 허용한 것은 아닙니다. 그룹 ID, 허용 사용자, 멘션 조건과 Telegram Privacy Mode를 공식 문서에서 확인하세요. 모든 메시지를 읽게 하려고 바로 관리자 권한을 주기보다 필요한 대화 범위부터 정합니다. 처음 실습에서는 그룹 연결을 생략해도 됩니다.
Discord 서버에 봇이 보이는데 답을 하지 않는다면 초대만 끝난 상태일 수 있습니다. 메시지 권한과 Intent, OpenClaw 토큰 설정, 사용자 승인을 차례로 보세요. 시험 서버의 채널 하나로 시작하면 원인을 찾기 쉽습니다.
봇 생성과 초대 권한
Discord Developer Portal에서 새 애플리케이션을 만들고 Bot 설정을 확인합니다. 일반 서버 메시지를 처리하려면 공식 OpenClaw 안내의 Message Content Intent 조건을 검토하세요. 역할 기반 접근 등을 쓴다면 Server Members Intent 필요 여부도 확인합니다. 필요 없는 Presence 기능까지 일괄 활성화하지 않습니다.
OAuth2 초대 설정에서는 bot과 applications.commands 범위, 채널 보기·메시지 보내기·기록 읽기 등 사용할 기능의 권한을 확인합니다. 관리자 전체 권한으로 해결하기보다 실제 사용할 시험 채널로 범위를 제한하세요.
OpenClaw에 토큰 등록
봇 토큰은 대화로 에이전트에게 보내지 않고 OpenClaw의 채널 추가 흐름에서 입력합니다. 아래 명령에서 Discord를 선택하고 현재 안내에 따라 설정한 다음 연결 상태를 확인하세요. 직접 파일로 설정하려면 공식 Discord 설정 문서의 현재 형식을 참고합니다.
openclaw channels add
openclaw channels status --probe
환경변수로 토큰을 주입하는 경우 터미널과 백그라운드 서비스가 같은 값을 읽는지 확인해야 합니다. 셸에서만 설정한 값이 서비스에 자동 전달된다고 가정하지 마세요. 여러 봇을 연결한다면 토큰과 애플리케이션 ID의 대응도 구분합니다.
DM과 서버 채널을 따로 시험
봇에게 DM을 보내 페어링 요청을 만든 뒤 본인 요청만 승인합니다. 다음으로 허용한 시험 채널에서 봇을 멘션해 응답을 확인하세요. DM은 되는데 서버에서 답하지 않으면 Intent, 채널 권한, 허용 목록, 멘션 조건을 차례로 확인합니다.
openclaw pairing list discord
openclaw pairing approve discord <CODE>
스킬이 목록에 있어도 필요한 프로그램이나 계정이 없으면 사용할 수 없습니다. 먼저 현재 준비 상태를 보고 부족한 항목을 찾으세요. 새 스킬은 이름과 인기 순위만 보지 말고 지침, 보조 파일, 필요한 권한까지 읽어본 뒤 설치합니다.
현재 스킬과 준비 상태
openclaw skills list
openclaw skills check
목록에 있어도 실행 프로그램이나 환경변수가 부족해 사용 대상에서 제외될 수 있습니다. 특정 스킬의 정보를 보려면 아래 <name>을 목록에 표시된 실제 이름으로 바꿉니다. 에이전트나 작업 공간이 여러 개라면 어느 환경의 목록인지도 확인하세요.
openclaw skills info <name>
검색 결과에서 읽을 내용
ClawHub는 스킬과 플러그인을 찾는 공개 레지스트리입니다. 현재 CLI에서 지원한다면 검색 명령으로 후보를 찾을 수 있습니다. 스킬 이름뿐 아니라 제작자, 버전, SKILL.md와 포함 스크립트, 필요한 계정·권한을 읽어보세요. 검색 상위나 인기 표시가 동작과 안전성을 보증하지는 않습니다.
openclaw skills search "calendar"
설치를 결정했다면 현재 명령 형식에 맞는 식별자와 버전을 지정합니다. 아래 @owner/<slug>와 <version>은 실제 값으로 바꿔야 합니다. 달력 기능이 필요하지 않다면 예시 검색 결과를 설치할 이유는 없습니다.
에이전트에게는 “페이지 제목과 본문에서 확인되는 내용만 정리하고 입력·전송은 하지 말라”처럼 작은 과제를 줍니다. 스크린샷이 필요하지 않은 텍스트 확인과 실제 버튼 조작을 구분하면 시험 범위가 명확해집니다.
브라우저 도구가 보이지 않을 때
브라우저 명령이 없거나 도구가 비활성화돼 있다면 플러그인과 browser.enabled, 현재 도구 프로필을 공식 설정 문서에 따라 확인합니다. 설치돼 있어도 정책에서 제외되면 사용할 수 없습니다. 기존 허용 목록을 통째로 지우거나 모든 도구를 허용하는 방식으로 해결하지 마세요.
로그인·인증·결제·외부 전송을 포함하는 작업은 해당 계정과 동작 범위를 따로 정해야 합니다. 전용 프로필도 로그인 뒤에는 접근 가능한 자료가 생기므로 자동화 가능 범위를 다시 검토합니다.
예약 기능은 반복 작업보다 일회 알림으로 시작하겠습니다. 등록 목록에 보이는 것과 실제 실행·전달이 끝나는 것은 다르기 때문입니다. 알림 하나의 실행 이력을 읽어본 뒤 시간대와 반복 조건을 붙여 보세요.
일회 알림 등록
현재 공식 문서는 openclaw automations를 기본 관리 명령으로 안내하고 cron을 별칭으로 유지합니다. 설치한 버전에서 명령과 옵션을 먼저 확인하세요. 아래 예시는 약 10분 뒤 메인 세션에 실습 알림 이벤트를 넣는 한 줄 명령이며, 실제 고객 메시지를 발송하는 설정은 아닙니다.
openclaw automations --help
openclaw automations add --name "실습 알림" --at "10m" --session main --system-event "실습 메모 확인 시간입니다." --wake now --delete-after-run
메인 세션 이벤트는 즉시 별도 대화를 시작하는 것과 다를 수 있습니다. 현재 대화나 처리 상태에 따라 수행 시점이 영향을 받을 수 있으므로 정확한 시각 보장이 필요한 업무에는 예약 기능의 동작 조건을 별도로 검토하세요.
작업 ID와 실행 이력
openclaw automations list
openclaw automations runs <job-id>
<job-id>는 생성 결과의 실제 ID로 바꿉니다. 목록에 있다는 사실만 보지 말고 실행 이력과 최종 응답을 확인하세요. 실행은 성공했지만 채널 전송이 실패하는 경우도 있으므로 외부 전달을 추가했다면 전달 상태도 따로 점검합니다. 시험을 중단하려면 현재 버전의 disable 명령으로 해당 ID만 비활성화합니다.
반복 일정과 Heartbeat
정해진 일정의 작업과 대화 맥락을 보며 주기적으로 확인하는 Heartbeat는 사용 목적과 실행 조건이 다를 수 있습니다. 반복 작업에서는 시간대, 실행 빈도, 결과를 보낼 곳, 중복 실행 방지와 중단 조건을 정하세요. 오래된 HEARTBEAT.md 중심 설명을 그대로 적용하기보다 현재 문서를 확인합니다.
한국 기준 일정을 원한다면 Asia/Seoul 같은 시간대를 명시할 수 있는지 확인합니다. 처음부터 짧은 간격의 무한 반복을 만들지 말고 일회 시험과 사용량 확인 뒤 필요한 빈도로 확대하세요. PC가 꺼지거나 Gateway가 중단된 동안의 처리도 운영 조건에 포함합니다.
메신저를 연결하고 도구를 추가했다면 접근 범위를 다시 볼 때입니다. 누가 대화할 수 있는지, 어떤 도구를 쓸 수 있는지, 도구가 어느 환경에서 실행되는지는 다른 설정입니다. 하나를 켰다고 나머지도 제한되는 것은 아닙니다.
대화 상대와 노출 주소
일반 호스트 설치의 Gateway는 기본적으로 로컬 루프백에 연결하도록 안내되지만 컨테이너 등 설치 방식에는 예외가 있습니다. 현재 실제 바인딩 주소와 인증 방식을 확인하세요. 개인 실습에서 외부 공개 포트가 필요한지부터 판단합니다.
채널의 페어링과 허용 목록은 누가 대화를 시작할 수 있는지 제어합니다. 봇에 접근할 수 있는 사람이 많아지면 모델 입력과 도구 요청의 범위도 달라집니다. 서로 신뢰하지 않는 사용자에게 같은 에이전트를 공유하는 환경은 단순 개인 봇과 동일하게 취급하면 안 됩니다.
도구 허용과 파일 격리
도구 정책은 사용할 수 있는 기능을 정하고, 샌드박스는 허용된 도구 실행의 환경과 접근 범위를 제한합니다. 작업 공간 폴더가 있다는 이유만으로 다른 파일 접근이 막히는 것은 아닙니다. 공식 문서상 샌드박스는 기본 비활성 상태일 수 있으므로 실제 유효 설정을 확인해야 합니다.
openclaw security audit
openclaw sandbox explain
샌드박스를 켜려면 선택한 백엔드의 설치와 작업 공간 접근 방식을 준비해야 합니다. 설명 화면에서 실제 모드와 도구 정책을 확인하세요. 호스트 실행으로 벗어나는 elevated 같은 설정도 별도 범위이므로 격리됐다고 단정하지 않습니다.
보안 감사 결과 읽기
보안 감사 결과를 읽고 외부 노출, 인증, 도구 범위 중 어떤 항목이 문제인지 나눕니다. 자동 수정 옵션을 바로 실행하기보다 변경 내용을 검토하고 사본을 남겨두세요. 감사 통과가 모든 입력과 외부 스킬의 안전성을 보증하지는 않으므로 작은 가상 자료로 실제 경계도 시험하세요.
백업 생성과 검증 결과를 확인한 뒤 실제 복원 절차도 공식 문서에서 검토합니다. 운영 환경에 무작정 복원하기보다 별도 시험 위치에서 필요한 자료를 확인해 두세요. workspace만 복사한 것은 전체 상태 백업과 다릅니다.
적용 전 업데이트 계획
CLI·Gateway·데스크톱 앱의 설치 방식에 맞는 업데이트 경로를 선택합니다. 아래 dry-run은 적용 전 계획 확인용입니다. 백업과 서비스 중단 영향을 확인한 뒤 현재 공식 절차로 적용하고, 시작할 때 기록한 버전과 실제 실행기 경로를 다시 확인합니다.
openclaw update --dry-run
업데이트 후 설정 형식이나 데이터 마이그레이션이 바뀌었다면 프로그램만 예전 버전으로 바꿔도 복구되지 않을 수 있습니다. 실패 시 공식 복구 안내에 따라 진행하고 새로운 설정과 예전 실행기를 임의로 섞지 않습니다.
Gateway·모델·채널별 진단
openclaw status
openclaw gateway status
openclaw doctor
openclaw channels status --probe
Gateway가 멈췄는지, 모델 인증이 실패했는지, 채널만 연결되지 않는지 구분합니다. 필요하면 logs --follow로 발생 시점의 오류를 확인하되 원문·토큰이 포함될 수 있는 로그를 그대로 공개하지 않습니다. doctor의 점검과 --fix 같은 변경 작업도 구분해 사용하세요.
괄호가 맞는 JSON이라고 바로 저장해도 되는 것은 아닙니다. 필수 항목이 없거나 수량에 음수가 들어 있어도 문법상으로는 읽힐 수 있습니다. AI 응답을 프로그램에 넘기기 전, 문법과 형식, 업무 규칙을 순서대로 검사해 보세요.
JSON으로 읽히는가
코드 블록 표시나 설명 문장이 함께 오면 그대로 JSON으로 읽히지 않을 수 있습니다. 응답 원문을 별도로 보관하고 파싱 실패를 정상 결과와 구분하세요. Python의 json.loads는 JSON을 Python 값으로 변환하지만, 그 값이 원하는 업무 구조라는 사실까지 확인하지는 않습니다.
필수 필드와 자료형
예를 들어 장비 ID는 문자열, 점검 여부는 불리언, 발견 항목은 배열로 정합니다. 숫자처럼 보이는 식별자를 정수로 강제 변환하지 않습니다. JSON Schema를 활용하면 필수 속성과 허용 속성을 명세할 수 있지만 실제 검사 도구를 연결해야 검증이 실행됩니다.
문법상 올바른 빈 객체도 필수 항목을 만족하지 않으면 거절해야 합니다. 예상하지 못한 열 이름이 생겼을 때 자동으로 기존 항목에 끼워 맞추지 말고, 변환 규칙이 필요한지 먼저 확인하세요.
자료형으로 잡히지 않는 오류
종료 시각이 시작보다 이르거나 수량이 허용 범위를 벗어나는 오류는 자료형 검사만으로 잡히지 않습니다. 해당 업무의 규칙을 별도 코드로 검사하고 실패 이유를 남깁니다. 잘못된 값은 조용히 보정하기보다 확인 대기 목록에 넣어 재검토할 수 있게 하세요.
한글이 깨져 보인다면 그 상태로 다시 저장하기 전에 멈추세요. 화면에서 잘못 읽힌 글자를 원본에 덮어쓸 수 있습니다. 파일 사본을 두고 만든 프로그램과 인코딩을 확인한 다음, BOM이 있는지도 살펴보겠습니다.
원본 사본부터 만들기
텍스트는 저장된 바이트를 어떤 인코딩으로 해석하는지에 따라 표시가 달라집니다. 확장자가 같다고 인코딩까지 같지는 않습니다. 파일을 만든 프로그램과 내보내기 설정을 확인하고, 실패한 상태에서 자동 저장이 원본을 바꾸지 않게 주의하세요.
UTF-8과 BOM
BOM은 파일 앞부분에 붙을 수 있는 표식입니다. Python의 utf-8-sig는 읽을 때 선두의 UTF-8 BOM이 있으면 건너뛰며, 쓸 때는 해당 표식을 추가합니다. 모든 UTF-8 파일에 BOM을 붙여야 하는 것은 아니므로 데이터를 받을 프로그램의 요구사항을 확인하세요.
첫 열 이름이 화면상으로는 같은데 비교가 실패하면 눈에 잘 보이지 않는 선두 문자도 살펴봅니다. 읽기 설정을 조정해야 할 문제를 열 이름 전체 교체로 감추면 다음 파일에서 같은 문제가 반복될 수 있습니다.
오류 무시 옵션을 쓰기 전에
해석되지 않는 문자를 지워서 읽는 설정은 작업을 진행하게 해주지만 데이터 손실을 숨길 수 있습니다. 먼저 엄격하게 읽어 실패 지점을 확인하고, 손상된 파일인지 설정이 틀렸는지 판단하세요. 변환본에는 사용한 인코딩과 변환 날짜를 남깁니다.
같은 고객의 주문이 두 줄 있다고 한 줄을 지우면 정상 주문까지 없어질 수 있습니다. 중복 제거 버튼보다 먼저 필요한 것은 “한 기록”의 정의입니다. 어떤 열을 묶어 같은 사건으로 볼지 정해 보겠습니다.
중복 판단에 쓸 열
모든 열이 같은 행과 일부 식별자만 같은 행은 다릅니다. 주문 번호, 상세 항목, 발생 시각처럼 사건을 구분하는 열을 조합하세요. pandas의 drop_duplicates도 비교할 열과 남길 행을 선택할 수 있으므로 기본 설정을 바로 적용하기보다 기준을 명시하는 편이 좋습니다.
값이 다른 행은 별도 검토
같은 주문 번호인데 금액이나 상태가 다르면 중복 입력보다 변경 이력일 수 있습니다. 최신 행을 남길 때도 파일의 마지막 줄이 실제 최신이라는 보장은 없습니다. 기준 시각의 의미와 수정 순서를 확인하세요.
앞뒤 공백이나 대소문자 차이를 정규화할지는 별도 규칙으로 둡니다. 코드에서 대소문자가 의미를 갖는 업무라면 무조건 소문자로 바꾸면 안 됩니다. 정규화 전후 값을 보관하면 잘못 합쳐진 항목을 찾을 수 있습니다.
지운 행과 합계 남기기
원본 행 수, 중복 후보 수, 최종 행 수를 남기고 제거된 행도 별도 목록으로 보존하세요. 전체 수량이나 금액이 줄었다면 예상한 변화인지 확인합니다. “중복이 줄었다”는 결과만으로 데이터 품질이 좋아졌다고 판단하지 않습니다.
패키지를 업데이트한 뒤 다른 프로그램이 멈췄다면 실행 환경이 섞였을 수 있습니다. 프로젝트별 가상환경을 만들고 설치와 실행에 같은 Python을 쓰면 이런 혼선을 줄일 수 있습니다. 활성화 표시보다 실제 실행 경로를 보겠습니다.
프로젝트 폴더에 환경 만들기
Python의 venv는 가상환경을 만드는 표준 기능입니다. Windows에서 사용할 Python을 확인한 뒤 프로젝트 폴더에서 py -m venv .venv 같은 명령으로 만들 수 있습니다. 여러 Python이 설치돼 있다면 생성에 사용한 버전도 기록하세요.
설치와 실행에 같은 Python 사용
터미널에 환경 이름이 보여도 편집기나 예약 작업은 다른 Python을 쓸 수 있습니다. .venv\Scripts\python.exe -m pip --version처럼 해당 실행기를 직접 지정해 확인할 수 있습니다. 패키지 설치와 실행에 같은 실행기를 사용하는 것이 중요합니다.
PowerShell의 활성화 스크립트가 정책으로 막혔다면 무조건 보안 정책부터 바꾸지 않습니다. 필요한 경우 가상환경의 Python 경로를 직접 지정해 실행할 수 있습니다. 조직 관리 PC에서는 승인된 설치·실행 기준을 따르세요.
복사보다 재생성 준비
가상환경 폴더 자체를 다른 컴퓨터로 옮기는 방식에 의존하지 않습니다. Python 버전과 의존성 목록, 실행 명령을 문서화해 새 환경에서 재구성할 수 있게 하세요. 비밀 값과 실제 입력 자료는 환경 설정 목록과 별도로 관리합니다.
문구를 고쳐 올렸는데 예전 화면이 보인다면 파일부터 다시 수정하지 마세요. 푸시가 됐는지, 배포가 끝났는지, 브라우저가 어떤 파일을 받았는지를 순서대로 보면 됩니다. HTML과 CSS가 서로 다른 시점의 파일일 수도 있습니다.
수정·푸시·배포 상태
내 컴퓨터에서 저장한 상태와 원격 저장소에 올라간 상태는 다릅니다. 배포 서비스가 어느 브랜치와 폴더를 읽는지도 확인해야 합니다. 배포 기록의 커밋이 기대한 변경과 같은지 대조한 뒤 공개 주소를 확인하세요.
HTML과 CSS를 따로 확인
페이지의 문구는 새것인데 디자인만 예전이라면 HTML과 CSS가 서로 다른 시점의 응답일 수 있습니다. 개발자 도구에서 요청 주소와 상태를 확인하고, 필요한 경우 캐시를 비활성화한 상태에서 재현해 보세요. HTTP 캐시는 저장한 응답을 재사용하므로 계층별 상태를 살펴볼 필요가 있습니다.
파일 이름에 버전이나 내용 해시를 넣는 방식은 자산 변경을 구분하는 데 도움이 될 수 있습니다. 모든 방문자가 같은 캐시 정책을 쓴다고 가정하지 말고 실제 응답 헤더와 배포 환경의 기능을 확인하세요.
공개 화면에서 찾을 변경 표시
수정한 문장이나 버전 표시처럼 변경 전후를 구분할 항목을 하나 고릅니다. 홈페이지와 직접 파일 주소를 모두 확인하고, 광고나 외부 스크립트 로딩을 내용 배포 성공과 혼동하지 않습니다. 배포 완료 기록과 실제 공개 응답이 함께 맞아야 확인이 끝납니다.
GitHub Pages에 소개 페이지를 올리는 일과 문의를 저장하는 기능을 붙이는 일은 준비가 다릅니다. Pages는 정적 파일을 제공하는 호스팅입니다. 추가하려는 기능이 브라우저에서 끝나는지 서버 처리가 필요한지부터 보겠습니다.
파일 제공과 서버 실행
GitHub Pages는 저장소의 HTML·CSS·JavaScript 등을 게시하는 정적 사이트 호스팅입니다. 방문할 때마다 서버에서 Python이나 PHP 코드를 실행하는 환경과는 다릅니다. 빌드 과정에서 파일을 생성하는 것과 방문자의 요청을 처리하는 것은 별개입니다.
브라우저 코드에 보이는 내용
공개 페이지의 JavaScript에 API 키를 넣으면 방문자가 확인할 수 있습니다. 비밀 값이 필요한 외부 API 호출이나 데이터 저장은 적절한 서버 측 처리 경로를 설계해야 합니다. 단순히 입력칸을 만들었다고 문의가 저장되거나 담당자에게 전달되지는 않습니다.
외부 폼 서비스를 이용한다면 실제 전송 대상, 실패 처리, 개인정보 안내, 서비스 조건을 확인하세요. 브라우저에서만 계산하는 도구는 가능하지만 새로고침이나 기기 변경 후 자료가 유지되는지도 기능 설명에 반영해야 합니다.
기능별 완료 기준
소개 페이지는 내용과 링크 표시, 다운로드는 파일 접근, 문의 기능은 실제 접수와 실패 안내까지 확인해야 합니다. 겉으로 버튼이 눌리는 것만으로 완료 처리하지 마세요. GitHub Pages 이용 제한과 허용 범위는 현재 공식 문서를 확인합니다.
입력칸 안의 안내 문구는 타이핑을 시작하면 사라집니다. 여러 항목을 채우다 보면 지금 어떤 칸인지 헷갈릴 수 있습니다. 칸 밖에 이름표를 두고 연결하면 다시 읽거나 고치기가 편해집니다.
입력칸과 label 연결
HTML의 label을 입력 요소와 연결하면 항목의 의미를 전달할 수 있습니다. for와 id를 대응시키고 ID를 중복하지 않도록 확인하세요. placeholder는 예시나 보조 안내로 쓸 수 있지만 지속적으로 보이는 이름표를 대체하는 방식에 의존하지 않는 것이 좋습니다.
필수 여부와 오류 이유
별표만 붙이기보다 어떤 항목이 필수인지 설명하고 날짜·전화번호 형식이 필요하면 구체적인 예시를 제공합니다. 불필요하게 엄격한 형식은 정상 입력을 막을 수 있으므로 수집 목적에 필요한 조건인지 먼저 검토하세요.
오류는 “잘못됐습니다”보다 어느 항목을 어떻게 고칠지 알려주는 문장으로 작성합니다. 색만으로 오류를 표시하지 않고 오류 문구와 입력칸의 관계를 전달해야 합니다. 수정할 때 기존 입력이 모두 지워지지 않는지도 확인하세요.
마우스 없이 작성해 보기
이름표를 눌렀을 때 해당 입력칸으로 이동하는지, Tab으로 순서대로 작성할 수 있는지 확인합니다. 제출 중 상태와 성공·실패 메시지도 읽을 수 있어야 합니다. 입력 화면만 잘 보이고 실제 접수가 실패하는 상황은 따로 점검합니다.
무료 AI를 찾더라도 메모 한 장을 정리할 때와 문서 백 개를 자동 처리할 때 필요한 도구는 다릅니다. 웹 채팅으로 충분한지, API가 필요한지부터 정해 보세요. OpenRouter, NVIDIA Build, OmniRoute의 역할도 여기서 갈립니다.
웹 채팅과 API 호출
회의 메모 한 장을 정리하려면 웹 채팅 화면이 간편합니다. 반면 파일이 들어올 때마다 같은 형식으로 요약하려면 프로그램에서 호출하는 API를 검토하게 됩니다. 채팅에서 무료로 쓸 수 있다는 안내가 같은 서비스의 API 무료 사용까지 의미하지는 않습니다. 가입 화면보다 실제 이용할 API의 가격표와 계정 한도를 먼저 확인하세요.
API 실험에는 세 가지 값이 필요합니다. 요청을 보낼 주소, 본인 계정의 API 키, 사용할 모델 ID입니다. 모델의 화면 표시 이름과 요청에 넣는 ID는 다를 수 있습니다. 검색 결과에 나온 옛 이름을 그대로 입력하기보다 현재 모델 상세 화면에서 ID를 복사하면 불필요한 오류를 줄일 수 있습니다.
세 도구가 맡는 일
도구를 선택할 때 먼저 확인할 차이
구분
주된 역할
첫 확인 항목
OpenRouter
여러 공급자의 모델에 접근하는 API 서비스
모델별 가격, 무료 변형, 데이터 처리 설정
NVIDIA Build
모델 카탈로그에서 예제를 보고 호스팅 API를 시험하는 출발점
모델 페이지의 이용 조건과 API 예제
OmniRoute
연결한 공급자로 요청을 전달하는 오픈소스 게이트웨이
프로젝트 신원, 연결할 계정, 실제 공급자 비용
게이트웨이는 연결을 관리하는 도구입니다. 설치 자체가 무료여도 연결한 공급자의 추론 요금까지 없어지는 것은 아닙니다. 또한 게이트웨이를 내 PC에서 실행하더라도 연결 대상이 외부 API라면 입력 내용은 외부로 전달됩니다. “로컬에서 실행”과 “모든 추론이 내 컴퓨터 안에서 실행”을 별도 항목으로 확인해야 합니다.
한 모델에 질문 하나 보내기
가상의 업무 메모 세 문장을 만들고 “담당자와 마감일을 표로 정리하라”처럼 결과를 확인할 수 있는 질문을 준비하세요. 처음에는 파일 업로드, 자동 재시도, 여러 모델 연결을 추가하지 않습니다. 답변 하나가 정상적으로 돌아오면 그때 입력 길이와 처리 개수를 늘립니다. 실패했을 때 어느 단계에서 문제가 났는지 설명할 수 있는 구성이 좋습니다.
작업 기록에는 모델 ID, 실행 날짜, 입력 분량, 응답 시간, 수정한 부분을 적습니다. 무료 모델의 공급 상태나 조건이 달라져도 같은 과제를 다시 실행해 비교할 수 있습니다. 특정 모델이 항상 최고라고 정하기보다 “이 업무의 초안을 검토 가능한 형태로 만들어 주는가”를 성공 기준으로 삼으세요.
OpenRouter 연결은 짧은 질문 하나로 시작하겠습니다. 별도 패키지를 설치하지 않고 Python 표준 라이브러리로 요청을 보내는 예제입니다. 준비할 값은 본인 API 키와 현재 목록에서 고른 무료 모델 ID입니다.
1. 사용 가능한 무료 모델 고르기
OpenRouter의 무료 모델 목록을 열고 모델 상세 화면에서 ID와 입력·출력 가격을 확인합니다. 무료 변형은 ID의 :free 접미사로 구분할 수 있습니다. 같은 계열이라도 접미사가 다른 ID는 가격이 다를 수 있으므로 전체 문자열을 확인하세요. 무료 목록은 고정되지 않기 때문에 이 예제에는 특정 모델명을 박아 넣지 않았습니다.
모델이 텍스트 입력을 지원하는지 확인한 뒤, 계정에서 API 키를 생성합니다. 무료 모델에도 요청 횟수 제한과 공급자 수용량 문제가 있을 수 있습니다. 계정의 잔액·키 한도·일일 이용량을 먼저 확인하고, 처음부터 여러 작업을 동시에 보내지 마세요.
2. PowerShell에 키와 모델 ID 설정
다음 명령은 Windows PowerShell용입니다. 첫 줄의 입력창에 본인 키를 붙여 넣으면 명령문 자체에 키를 직접 적지 않아도 됩니다. 환경변수는 암호 저장소가 아니므로 화면 공유, 로그 수집, 다른 프로그램 실행 시 취급에 주의하세요. 모델 ID는 방금 확인한 무료 변형으로 바꿉니다.
$env:OPENROUTER_API_KEY = Read-Host "본인 OpenRouter API 키"
$env:OPENROUTER_MODEL = "공식_목록에서_확인한_모델_ID:free"
3. first_call.py 저장 후 실행
import json
import os
import urllib.error
import urllib.request
key = os.environ["OPENROUTER_API_KEY"]
model = os.environ["OPENROUTER_MODEL"]
if not model.endswith(":free"):
raise SystemExit("이 실습은 :free 모델 ID만 사용합니다.")
payload = {
"model": model,
"messages": [{"role": "user", "content": "자료 백업의 목적을 두 문장으로 설명해 줘."}],
"max_tokens": 256,
"stream": False,
}
request = urllib.request.Request(
"https://openrouter.ai/api/v1/chat/completions",
data=json.dumps(payload).encode("utf-8"),
headers={"Authorization": "Bearer " + key, "Content-Type": "application/json"},
method="POST",
)
try:
with urllib.request.urlopen(request, timeout=60) as response:
result = json.load(response)
if result.get("error"):
raise SystemExit("응답 오류: " + str(result["error"].get("code", "unknown")))
choices = result.get("choices") or []
if not choices:
raise SystemExit("선택 가능한 응답이 없습니다. 모델 상태를 확인하세요.")
print(choices[0].get("message", {}).get("content") or "텍스트 응답이 비어 있습니다.")
print("사용량:", result.get("usage", {}))
except urllib.error.HTTPError as error:
print("HTTP 오류:", error.code)
print("잔액·키·모델·한도를 확인한 후 다시 시도하세요.")
except (urllib.error.URLError, TimeoutError):
print("연결 또는 시간 초과 오류: 네트워크와 서비스 상태를 확인하세요.")
python first_call.py로 실행합니다. 답변과 사용량이 나오면 기본적인 요청·응답 흐름을 확인한 것입니다. 모델에 따라 출력 한도를 추론 토큰에 소비해 본문이 짧거나 비어 있을 수 있습니다. 이때 한도만 계속 높이기보다 모델 문서와 응답 상태를 먼저 확인하세요. 한 번의 성공이 장시간 자동 처리의 안정성을 보장하지는 않습니다.
4. 응답이 오지 않을 때
KeyError는 환경변수가 현재 Python 프로세스에 전달되지 않았을 때 발생할 수 있습니다. 값을 설정한 같은 터미널에서 실행했는지 확인하세요. HTTP 오류가 나오면 Python 설치부터 다시 하기보다 상태 코드를 기준으로 키 인증, 잔액, 모델 이용 가능 여부를 나누어 점검합니다. 모델 ID 끝에 무료 접미사를 임의로 붙인다고 존재하지 않는 무료 모델이 생기지는 않습니다.
실습이 끝나면 아래 명령으로 이 세션의 값을 제거합니다. 코드를 다른 사람에게 전달할 때는 실제 키와 실행 로그를 제외하고, 설정해야 하는 변수 이름만 안내하세요.
NVIDIA Build에서 모델을 골랐다면 웹 미리보기부터 써보세요. 같은 질문을 API 코드로 옮기면 모델 자체의 결과와 코드 연결 문제를 나눠볼 수 있습니다. 처음에는 텍스트 한 문단으로 시험하겠습니다.
1. 시험할 작업 한 가지
가상의 메모를 요약하거나 공개된 제품 설명에서 항목을 추출하는 등 정답을 확인할 수 있는 입력을 준비하세요. 이미지 분석을 하려면 이미지 입력을 지원하는 모델인지 별도로 봐야 합니다. 모델 이름이 비슷하더라도 지원 입력 형식이나 출력 옵션이 다를 수 있습니다. 처음에는 텍스트 한 문단처럼 단순한 입력을 쓰면 연결 문제와 모델 활용 문제를 구분하기 쉽습니다.
2. 웹 미리보기에서 답변 보기
NVIDIA Build 카탈로그에서 모델을 선택하고 Preview가 제공되면 같은 질문을 입력합니다. 모델 카드의 조건, 제공 예제, 이용 관련 안내를 함께 읽으세요. 답변이 생성되는지만 보지 말고 요청한 언어와 출력 형식을 지키는지 확인합니다. 잘못된 내용을 자신 있게 말하는 경우도 있으므로 익숙한 주제로 시작하는 편이 좋습니다.
예를 들어 “장비 점검 완료. 통신 복구 확인. 다음 주 재점검 예정.”이라는 가상의 문장을 주고, “확인된 사실과 예정된 일을 구분해 작성하라”고 요청할 수 있습니다. 결과가 입력에 없는 날짜나 담당자를 만들어내는지 확인하세요. 실제 고객의 장비 기록을 넣을 필요 없이 출력 습관을 먼저 살펴볼 수 있습니다.
3. 같은 모델의 코드 가져오기
공식 시작 문서는 모델 페이지에서 API 키를 발급하고 Python 예제를 가져오는 흐름을 안내합니다. 화면에서 제공하는 코드의 주소, 모델 ID, 요청 본문을 한 세트로 확인하세요. 다른 글에서 본 주소와 현재 모델의 옵션을 섞으면 잘못된 값을 찾기 어렵습니다. 텍스트 생성 예제가 다른 종류의 모델에도 그대로 통한다고 가정하지 마세요.
예제에 키를 직접 적도록 되어 있더라도 개인 실습 파일에서는 환경변수로 읽도록 바꿀 수 있습니다. PowerShell에서 키를 입력한 뒤, Python에서는 아래처럼 읽습니다. 나머지 요청 부분은 선택한 모델 페이지의 현재 예제를 기준으로 구성하세요.
# PowerShell에서 실행
$env:NVIDIA_API_KEY = Read-Host "본인 NVIDIA API 키"
# Python 예제에서 키를 읽는 부분
import os
api_key = os.environ["NVIDIA_API_KEY"]
4. 체험 조건과 운영 환경
계정에서 제공되는 체험 조건, 요청 제한, 모델별 이용 조건은 실행 시점의 화면과 FAQ를 확인해야 합니다. 예전 블로그의 “무제한 무료”나 분당 요청 수를 영구적인 조건처럼 적용하지 마세요. 일정한 처리량이 필요한 고객 서비스라면 체험 API의 사용 가능 여부와 별개로 운영용 제공 방식과 비용을 검토해야 합니다.
내 컴퓨터에 고성능 GPU가 없어도 호스팅된 API를 호출하는 방식은 사용할 수 있습니다. 반대로 NIM을 자체 서버에 배포하는 일은 서버 자원과 배포 조건을 따로 검토하는 작업입니다. 웹에서 시험했다는 이유로 자체 배포 비용이나 운영 준비가 끝났다고 판단하지 않도록 구분해 기록하세요.
실행 기록에 남길 내용
선택한 모델 페이지 주소와 정확한 모델 ID
웹 미리보기와 API에 넣은 동일한 가상 입력
출력 형식 준수 여부와 사람이 수정해야 했던 문장
오류 코드, 호출 시각, 계정 화면에 표시된 잔여 한도
웹 미리보기는 성공했는데 코드만 실패한다면 키 전달과 요청 형식을 먼저 확인합니다. 둘 다 실패하면 계정 권한과 모델 제공 상태를 확인하세요. 웹과 코드의 결과를 비교하면 어느 쪽 문제인지 좁힐 수 있습니다.
여러 AI 도구의 주소와 키를 관리하다 보면 설정이 뒤섞일 수 있습니다. 게이트웨이는 그 사이에 공통 연결 지점을 둡니다. 여기서는 diegosouzapw/OmniRoute를 다룹니다. 비슷한 이름의 다른 서비스와 혼동하지 않도록 저장소 주소를 먼저 보세요.
클라이언트·게이트웨이·공급자의 연결
내 프로그램 → OmniRoute → 연결한 모델 공급자 순서로 요청이 이동합니다. 공급자 키는 게이트웨이가 공급자에 접근할 때 쓰고, 클라이언트용 키는 내 프로그램이 게이트웨이에 접근할 때 씁니다. 두 키를 같은 칸에 무작정 넣으면 인증 오류의 위치를 파악하기 어렵습니다. 설정 메모에는 키 원문 대신 “어느 구간의 키인가”를 적어두세요.
여러 공급자를 연결하기 전에 한 공급자의 모델 한 개로 기본 동작을 확인해 두세요. 자동 전환을 처음부터 켜면 응답이 어느 공급자에서 왔는지와 실패한 연결이 무엇인지 함께 추적해야 합니다. 연결 하나가 검증된 뒤 대체 경로를 추가하면 점검할 조합을 줄일 수 있습니다.
설치할 버전의 요구사항
프로젝트는 npm 설치 방법과 대시보드 사용법을 안내합니다. 실행 전 현재 README의 Node.js 지원 버전과 설치 절차를 확인하세요. 이 글에서는 설치 명령을 자동으로 실행하거나 특정 버전의 설치 성공을 주장하지 않습니다. 업무용으로 사용하려면 선택한 버전과 설정을 기록하고, 업데이트 전에 기존 설정으로 복구할 방법을 준비하는 편이 좋습니다.
공식 README의 기본 안내에서는 대시보드가 http://localhost:20128, API 기본 주소가 http://localhost:20128/v1입니다. 포트를 변경했다면 실제 실행 로그에 표시된 값을 사용합니다. 주소를 클라이언트에 입력하기 전에 브라우저에서 대시보드가 열리는지 먼저 확인하세요.
안 되는 구간부터 찾기
프로세스가 실행 중인지, 대시보드 주소가 맞는지 확인합니다.
게이트웨이에서 공급자 연결 상태와 이용 가능 모델을 확인합니다.
클라이언트의 API 기본 주소, 클라이언트용 키, 모델 식별자를 대조합니다.
짧은 질문 한 개를 보내고 게이트웨이와 공급자 양쪽의 사용 기록을 확인합니다.
대시보드는 열리는데 답변이 없으면 게이트웨이 실행 자체보다 공급자 인증이나 모델 설정을 살펴볼 단계일 수 있습니다. 반대로 대시보드도 열리지 않으면 포트 충돌과 프로세스 종료부터 봅니다. 재설치에 앞서 어느 구간에서 막혔는지 찾아보세요.
자동 전환의 비용과 데이터 경로
무료 모델이 막혔을 때 유료 모델로 전환하도록 설정하면 실제 비용이 발생할 수 있습니다. 무료 실험에서는 무료 조건을 확인한 연결만 선택하고, 대체 경로도 같은 기준으로 검토하세요. 게이트웨이가 외부 공급자의 한도를 없애주는 것은 아닙니다. 공급자가 허용한 사용 범위 안에서 대기와 재시도를 설계해야 합니다.
외부로 전송할 수 없는 문서를 넣기 전에는 선택한 공급자와 저장되는 로그를 확인해야 합니다. 로컬 대시보드를 인터넷에 공개할 필요가 없는 개인 실습이라면 외부 포트 개방 없이 진행하세요. 연결이 정상이라는 확인과 조직의 문서 취급 기준을 충족한다는 판단은 각각 기록하는 것이 좋습니다.
API가 멈추면 오류 코드부터 남겨두세요. 키가 틀린 문제에 재시도를 반복해도 답은 오지 않습니다. 401·402·403·429가 나왔을 때 무엇을 먼저 볼지 정리했습니다. 세부 의미는 해당 서비스의 응답 본문과 문서로 확인해야 합니다.
오류에 따라 다음 행동을 다르게 정하기
증상
먼저 볼 항목
다음 행동
401
키 누락, 만료, 잘못된 인증 대상
현재 요청 주소와 키 발급 서비스를 대조
402
잔액, 키별 비용 한도, 실행 중 요청의 예상 비용
계정과 오류 메타데이터를 확인
403
접근 정책, 권한, 조직 예산 제한
차단 사유에 맞는 설정 점검
429
분당·일일 한도, 공급자 처리 용량
재시도 안내와 한도 초기화 시각 확인
시간 초과
네트워크, 응답 시간, 요청 크기
작은 입력으로 한 번만 분리 점검
인증 키와 요청 주소
발급받은 키가 정상이어도 다른 서비스 주소로 요청하면 인증에 실패합니다. 게이트웨이를 쓸 때는 공급자용 키와 게이트웨이용 키를 혼동하기도 합니다. 로그에 키 원문을 출력하는 대신 요청 호스트, HTTP 상태, 호출 시각을 기록하세요. 키의 앞뒤 공백과 환경변수 이름 오타를 확인하고, 새 키를 발급했다면 실행 중인 프로그램이 새 값을 읽는지도 봅니다.
402·403의 제한 주체
OpenRouter 문서는 계정 잔액과 키별 한도뿐 아니라 실행 중인 유료 요청의 예상 비용에 따른 제한도 설명합니다. 조직이 설정한 예산 제한은 403으로 보고될 수 있습니다. 같은 상태 코드라도 오류 메타데이터가 가리키는 제한 주체를 확인해야 합니다. 잔액이 보인다는 이유만으로 계정 전체를 정상이라고 판단하지 마세요.
업무 기록에 “잔액 부족”이라고만 적으면 키 한도를 올렸는지, 동시 요청을 줄였는지 나중에 구분할 수 없습니다. 비밀 값을 제거한 오류 종류, 당시 실행 개수, 출력 상한, 계정 화면의 제한 항목을 함께 남겨보세요. 다른 사람이 같은 문제를 재현하지 않고도 조치 이유를 이해할 수 있습니다.
429에서 기다릴 때와 멈출 때
분당 요청 수 초과와 일일 한도 소진은 모두 이용량과 관련되지만 기다려야 하는 시간이 다릅니다. 응답에 Retry-After가 있으면 그 안내를 확인하세요. 일일 한도를 다 쓴 상태라면 몇 초 간격으로 반복해도 해결되지 않습니다. 서비스의 계정 화면이나 한도 API에서 재개 가능한 시점을 확인하고 작업을 중단하는 편이 좋습니다.
자동 처리가 꼭 필요하다면 “최대 세 번만 재시도하고, 실패한 작업은 별도 목록에 저장한다”처럼 종료 조건을 정합니다. 대기 간격을 늘리는 재시도는 일시적인 혼잡을 위한 것이지 인증 실패를 해결하는 방법은 아닙니다. 공급자별 문서에서 실패 요청의 집계 기준도 확인하세요.
시간 초과 뒤 중복 요청
클라이언트가 기다리다 멈췄다고 서버의 작업도 반드시 취소된 것은 아닙니다. 자동으로 같은 요청을 연속 전송하기 전에 사용 기록을 확인하세요. 파일별로 작업 ID와 완료 여부를 기록하면 답변을 두 번 저장하는 일을 줄일 수 있습니다. 이메일 발송 같은 후속 동작이 있다면 답변 생성과 실행 승인을 분리해 두는 편이 점검하기 쉽습니다.
재현용 입력은 개인정보가 없는 짧은 문장으로 바꿉니다. 같은 입력이 단일 요청에서는 성공하고 동시 요청에서만 실패한다면 동시 실행 수를 줄이는 실험부터 시작하세요. 설정은 하나씩 바꾸고 결과를 적어두세요.
예제 폴더를 공유하기 전에 설정 파일과 로그도 열어보세요. 코드에는 키가 없어도 .env나 오류 출력에 남아 있을 수 있습니다. 실제 입력 자료와 공유할 예제를 처음부터 따로 두면 나중에 걸러내는 수고가 줄어듭니다.
키 이름과 실제 키를 따로
공유할 설정 예제에는 변수 이름과 설명만 적습니다. 예를 들어 OPENROUTER_API_KEY=본인_키_입력처럼 대체 문구를 쓰고, 실제 값은 개인 환경에서 관리합니다. 환경변수나 .env 파일을 사용한다고 자동으로 안전해지는 것은 아닙니다. 파일을 읽는 라이브러리의 동작과 저장 위치도 확인해야 합니다.
Git을 사용한다면 다음과 같은 제외 규칙을 검토할 수 있습니다. 프로젝트에 따라 폴더 이름은 조정하세요. 이 예제는 새 실습 프로젝트에 적용할 기본 아이디어이며, 기존 프로젝트에 그대로 덮어쓰는 설정은 아닙니다.
이미 Git이 추적하는 파일은 제외 규칙만 추가해도 기록에서 사라지지 않습니다. 커밋 전에 변경 목록과 스테이징된 차이를 직접 확인하세요. 실제 키를 공개했다면 파일 삭제만으로 해결됐다고 판단하지 말고 해당 서비스에서 키를 폐기하고 새 키로 바꿔야 합니다. 과거 커밋이나 복제본에 남은 값도 더 이상 사용할 수 없게 만드는 것이 우선입니다.
이름만 지우면 충분할까
사람 이름을 “고객 A”로 바꿔도 주소, 전화번호, 장비 식별자, 주문번호가 함께 있으면 실제 대상을 알아볼 수 있습니다. 실습에서는 숫자와 상황까지 새로 만든 가상 문서를 사용하는 편이 낫습니다. 도구가 설치됐는지 확인하는 단계에는 실제 계약서나 고객 명단이 필요하지 않습니다.
문서를 외부 AI로 보내기 전에는 이용하려는 서비스뿐 아니라 실제 추론 공급자의 데이터 처리 조건을 확인합니다. 게이트웨이, 모델 공급자, 오류 수집 도구가 각각 어떤 데이터를 받는지 그려보세요. 같은 모델 이름을 선택했더라도 경로와 설정이 바뀌면 확인할 조건도 달라질 수 있습니다.
로그에 남는 입력과 인증 정보
디버깅을 위해 요청 본문 전체를 출력하면 입력 문서와 인증 헤더가 로그에 섞일 수 있습니다. 기본 기록 항목은 시각, 모델 ID, 작업 ID, 상태 코드, 소요 시간, 토큰 사용량 정도로 설계해 보세요. 원문이 필요한 오류 분석은 별도로 접근 범위와 삭제 시점을 정하는 편이 관리하기 수월합니다.
OpenRouter는 자체 입력·출력 저장 설정과 공급자 측 처리를 구분해 설명합니다. 한 서비스의 저장 옵션을 껐다고 모든 경로에서 저장이 사라졌다고 해석하지 마세요. 계정의 관측·개인정보 설정과 공급자 정책을 각각 확인하고, 조직의 문서 취급 기준에 맞는지 판단해야 합니다.
공유 전에 열어볼 파일
실행 파일과 설정 예제에 실제 키가 없는지 확인합니다.
입력·출력·스크린샷이 모두 가상 데이터인지 확인합니다.
Git 변경 목록과 로그 파일을 확인합니다.
키 없는 새 폴더에서 설정 설명만 보고 실행 준비가 가능한지 점검합니다.
예제의 재현성을 높이려면 사용한 언어 버전, 모델 선택 방법, 필요한 변수 이름을 함께 적습니다. 실제 비밀 값을 넘기지 않고도 받는 사람이 자신의 계정으로 준비할 수 있는 형태가 좋은 공유 예제입니다.
추천 순위가 높아도 내 문서에 맞는지는 직접 봐야 합니다. 같은 메모를 두 모델에 주고 사실 누락, 임의로 추가한 내용, 수정 시간을 적어보세요. 아래 표는 성능 결과가 아니라 비교할 때 채워 쓸 양식입니다.
1. 입력과 기대 결과 준비
다음 문장을 두 모델에 똑같이 넣어보세요. “가상 설비 A의 통신이 오전 9시에 끊겼다. 오전 10시에 통신을 복구했다. 발전량 데이터는 아직 확인하지 못했다. 담당자는 다음 점검 때 데이터 수집 상태를 확인하기로 했다.” 요청은 “확인된 사실, 확인되지 않은 사항, 다음 행동을 구분하라”로 고정합니다.
좋은 답변은 통신이 복구됐다는 사실과 발전량 상태를 모른다는 사실을 구분해야 합니다. “발전이 정상화됐다”거나 구체적인 발전량을 추가하면 입력에 없는 사실을 만든 것입니다. 모델 답변을 본 뒤 기준을 바꾸지 않도록, 평가 전에 금지할 추정과 필수 항목을 적어두세요.
2. 사실·형식·검토 시간을 따로 기록
직접 채워 사용하는 비교 양식 — 측정 결과 아님
평가 항목
기록 기준
모델 A / B
사실 보존
필수 사실을 모두 유지하면 2, 일부 누락 1, 잘못된 사실 추가 0
실행 후 기록
불확실성 구분
미확인 발전량을 명시하면 2, 모호하면 1, 정상으로 단정하면 0
실행 후 기록
형식 준수
세 구역을 모두 지키면 2, 일부만 지키면 1, 구분 없으면 0
실행 후 기록
응답 시간
요청 시작부터 출력 완료까지 초 단위
실행 후 기록
사람 검토 시간
업무에 쓸 초안으로 고치는 데 걸린 시간
실행 후 기록
합계가 같아도 중요한 사실을 만들어낸 모델은 해당 업무의 후보에서 제외할 수 있습니다. 점수 합산 전에 “숫자·날짜를 임의로 추가하면 탈락” 같은 필수 조건을 정하세요. 문장이 자연스러워도 사실이 틀렸다면 별도 오류로 남깁니다.
3. 다른 길이와 누락 조건도 시험
첫 입력이 끝나면 누락된 날짜가 있는 문서, 서로 다른 장비가 섞인 문서, 불필요한 인사말이 긴 문서를 추가합니다. 각 경우의 기대 결과를 먼저 써두고 모델별로 동일한 설정을 사용하세요. 가능하면 같은 입력을 여러 번 실행해 결과가 흔들리는지도 기록합니다. 몇 번의 성공은 운영 안정성 통계가 아니라 다음 실험으로 넘어갈 근거 정도로 해석하는 편이 적절합니다.
모델 ID, 실행일, 출력 한도, 프롬프트 원문을 함께 저장해야 나중에 비교할 수 있습니다. 무료 모델이 교체되거나 제공 경로가 달라지면 이전 표를 그대로 재사용하지 말고 다시 실행하세요. 긴 문서를 처리할 때는 앞부분과 끝부분의 사실이 모두 보존되는지도 별도로 살펴봅니다.
4. 재시도와 수정 시간까지 계산
대기, 재시도, 답변 수정까지 포함한 시간을 확인해야 합니다. 아래 숫자는 계산 방식을 설명하기 위한 가상 예시입니다. 직접 정리하면 10분 걸리는 문서가 AI 호출 1분, 검토 7분, 오류 대응 평균 3분을 요구한다면 총 11분입니다. 호출 비용이 없어도 이 작업에서는 시간을 줄이지 못한 셈입니다.
반대로 수정하기 쉬운 구조화된 초안을 꾸준히 만들고 오류를 알아채기 쉽다면 작은 업무부터 적용해 볼 수 있습니다. 자동 발송이나 확정 처리는 뒤로 두고, 사람이 검토하는 초안 단계에서 효과를 확인하세요. 평가표를 남겨두면 모델을 바꿀 때도 같은 기준으로 재검토할 수 있습니다.
사무실에서 공유폴더가 잘 열린다고 권한 설정까지 적절한 것은 아닙니다. 어느 네트워크에서 열리는지, 누가 쓰기 권한을 갖는지부터 살펴보세요. 윈도우 11에서 점검할 네 가지를 정리했습니다.
1. 신뢰하는 네트워크에서만 공유
윈도우 11의 네트워크 프로필을 공용(Public)이 아닌 개인(Private)으로 정확히 설정하고,
네트워크 검색·파일 및 프린터 공유 기능은 신뢰된 사설망에서만 켜두는 것이 기본입니다.
카페나 외부 공유 와이파이에 노트북을 연결할 때 공용 프로필로 자동 전환되는지 반드시 확인해야 합니다.
2. SMBv1 사용 여부
과거 대규모 랜섬웨어 확산에 악용됐던 구형 프로토콜인 SMBv1은 특별한 legacy 장비 연동 목적이 아니라면
꺼두는 것이 원칙입니다. '제어판 → 프로그램 → Windows 기능 켜기/끄기'에서 SMB 1.0/CIFS 파일 공유 지원 항목을
해제하면 됩니다.
3. 계정별 공유 권한과 NTFS 권한
모두가 모든 폴더에 접근할 수 있도록 'Everyone'에게 전체 읽기/쓰기 권한을 주는 방식은 편리하지만,
한 계정이 뚫리면 회사 전체 자료가 함께 위험해집니다. 부서·직무별로 필요한 폴더에만 접근하도록
공유 권한과 NTFS 권한을 분리해서 관리하고, 퇴사자 계정은 즉시 회수하는 절차를 마련해야 합니다.
4. 접근 로그와 남은 권한
누가 언제 어떤 파일에 접근했는지 감사 로그를 남기면, 이상 징후(대량 파일 이동, 새벽 시간대 접근 등)를
빠르게 발견할 수 있습니다. 소규모 조직이라도 분기에 한 번은 공유 권한 목록을 전체 점검해
더 이상 필요 없는 접근 권한이 남아있지 않은지 확인하는 것을 권장합니다.
공유 설정을 PC마다 반복해서 점검하기 번거로울 때 BZ SMB Settings를 활용할 수 있습니다. 도구를 쓰더라도 허용할 네트워크와 계정, 필요한 권한은 사용 환경에 맞게 정해야 합니다.
태양광 · 에너지
태양광 발전소 모니터링에서 발전량·통신·알림 살펴보기
솔루션 비제트 · 에너지 IT 노트
패널을 눈으로 봐서는 인버터 상태나 수집이 끊긴 시점을 알기 어렵습니다. 현장 방문 사이의 상태를 보려면 모니터링 기록과 알림이 필요합니다. 발전량 수치와 통신 이력을 볼 때 어떤 질문을 해야 할지 정리했습니다.
발전량과 성능비(PR)
단순 발전량은 날씨 영향을 그대로 받기 때문에, 어제보다 적게 발전했다고 해서 바로 이상이라 판단하기
어렵습니다. 반면 성능비(Performance Ratio)는 일사량 대비 실제 발전량의 비율이므로, 날씨와 무관하게
설비 자체의 건강 상태를 보여주는 지표입니다. PR이 평소보다 꾸준히 낮게 나온다면 오염, 음영, 배선 열화,
인버터 효율 저하 등을 의심해볼 수 있습니다.
통신이 끊겼을 때의 알림
인버터가 통신을 멈췄다는 것은 단순 통신 장애일 수도 있지만, 실제 고장의 초기 신호인 경우가 많습니다.
이때 즉시 알림을 받을 수 있는 체계가 없다면, 다음 정기 점검일까지 해당 스트링 전체가 발전을 멈춘 채
방치될 수 있습니다. 특히 임야나 지붕형처럼 접근이 쉽지 않은 발전소일수록 원격 알림의 가치가 커집니다.
모니터링 시스템을 고를 때
알림 채널의 실효성 — 대시보드에만 표시되고 끝나는지, 문자·앱 푸시 등 실제로 확인하게 되는 채널로 오는지
이력 데이터 보존 기간 — 전년 동기 대비 비교가 가능해야 열화나 계절적 저하를 구분할 수 있습니다
국내 통신 환경 호환성 — 통신사·회선 환경에 따라 두절이 잦은 시스템은 오히려 관리 부담을 키웁니다
저희가 함께 다루는 Solar BZ는 한국 발전소 현장의 통신 환경에 맞춰 설계된 모니터링
프로그램으로, 상업적 사용까지 고려해 만들어졌습니다. 어떤 도구를 쓰든, '발전량'이 아니라
'성능비와 알림 체계'를 기준으로 모니터링 방식을 점검해보시길 권합니다.
AI 활용
중소기업 AI 도입, 반복 업무 하나로 시험해 보기
솔루션 비제트 · AI 강연 노트
AI 도입을 생각하면 비용과 전담 인력부터 궁금해집니다. 하지만 어떤 업무에 쓸지 정하지 않으면 도구를 골라도 효과를 판단하기 어렵습니다. 반복하는 일 하나를 골라 결과와 검토 시간을 재보는 데서 시작할 수 있습니다.
첫 대상은 반복 업무 한 가지
견적서 초안 작성, 회의록 요약, 반복 문의에 대한 1차 응대, 엑셀 데이터 정리처럼
매번 비슷한 패턴으로 반복되는 업무가 AI 도입의 첫 대상으로 적합합니다. 판단이 크게 개입하지 않는
업무일수록 결과를 검증하기 쉽고, 실패해도 리스크가 작습니다.
줄이려는 시간을 먼저 정하기
어떤 AI 서비스를 쓸지보다 먼저 정해야 할 것은 목표입니다. "문의 응대 1차 처리 시간을 절반으로
줄인다"처럼 구체적인 목표가 있어야, 도입 후에 실제로 효과가 있었는지 판단할 수 있습니다.
목표 없이 도구부터 도입하면 몇 달 뒤 "그래서 뭐가 좋아졌는지 모르겠다"는 결론에 이르기 쉽습니다.
작은 시험에서 적용 범위 넓히기
한 팀, 한 업무에만 4~6주 정도 파일럿을 돌려보고, 현업 담당자의 피드백을 받아 프로세스를
다듬은 뒤에 다른 팀으로 확대하는 방식이 안전합니다. 처음부터 전사 도입을 목표로 하면
현업의 저항도 크고, 문제가 생겼을 때 원인을 찾기도 어렵습니다.
솔루션 비제트 대표 박영은 엔비디아 공식 AI 활용 역량 인증(DLI)을 개인 자격으로 보유하고 있으며, 기업·기관 대상 강연에서 단계별 AI 활용 방법을 실습 중심으로 안내하고 있습니다.
IT 솔루션
IT 솔루션 계약 전에 확인할 요구사항·연동·지원·비용
솔루션 비제트 · IT 컨설팅 노트
솔루션 시연에서 잘 보이던 기능도 기존 업무에 붙이면 달라질 수 있습니다. 연동과 지원 범위, 유지비를 계약 전에 적어두어야 나중에 비교할 수 있습니다. 도입 검토 때 물어볼 다섯 가지를 모았습니다.
1. 요구사항과 완료 기준
"편리하게 만들어주세요" 같은 막연한 요청으로는 견적도, 완성 기준도 애매해집니다.
지금 어떤 문제를 겪고 있고, 도입 후 어떤 상태가 되어야 성공인지를 문서로 정리한 뒤
공급업체와 논의를 시작해야 오해와 재작업을 줄일 수 있습니다.
2. 기존 데이터와의 연동
아무리 좋은 솔루션도 지금 쓰는 회계·인사·재고 시스템과 데이터를 주고받지 못하면
결국 이중 입력이라는 부가 업무만 늘어납니다. 연동 방식(API, 파일 연동, 수동 입력)이
무엇인지 도입 전에 명확히 확인해야 합니다.
3. 보안 기준과 데이터 보관
개인정보를 다루는 솔루션이라면 관련 법령과 내부 보안 정책을 충족하는지, 데이터가
어디에 저장되고 누가 접근할 수 있는지를 계약 전에 문서로 받아두어야 합니다.
4. 유지보수와 응답 시간
장애가 나면 누가 어떤 방식으로 대응하는지, 응답 시간은 어떻게 정하는지 계약 전에 확인합니다. 지원 가능이라는 안내만으로 판단하기보다 포함되는 작업과 별도 비용 항목을 문서로 받아두세요.
5. 도입 후 비용까지 계산
라이선스 비용만 비교하면 저렴해 보이는 솔루션이, 유지보수비·교육비·연동 개발비를 더하면
오히려 비싼 경우가 많습니다. 최소 3년 단위로 총소유비용을 계산해 비교하는 것을 권장합니다.
솔루션 비제트는 한국소프트웨어산업협회(KOSA)를 통해 관리되는 SW 서비스 업체로서,
도입 전 요구사항 정리 단계부터 함께 참여해 위 다섯 가지 기준을 고객사와 같이 점검하는 방식으로
컨설팅을 진행하고 있습니다.
소프트웨어 개발
프로그램 출시 뒤에 필요한 유지보수와 지원
솔루션 비제트 · 개발팀 노트
출시한 프로그램은 그 상태로 오래 머물지 않습니다. 운영체제와 브라우저가 바뀌고 사용자도 새 요구를 냅니다. 구축 비용을 정할 때 이런 변경을 누가 맡고 어떻게 점검할지 함께 정해두어야 합니다.
미뤄둔 업데이트가 쌓일 때
당장 동작에 문제가 없다는 이유로 업데이트를 미루면, 라이브러리와 프레임워크의 버전이
점점 뒤처지게 됩니다. 어느 순간 보안 패치가 필요해졌을 때, 오래된 코드 기반 위에서
업데이트 한 번이 시스템 전체를 흔드는 대규모 작업이 되어버립니다. 이것이 '기술 부채'이며,
미룰수록 갚아야 할 비용이 커집니다.
보안 패치를 적용할 일정
새로 발견되는 보안 취약점은 대부분 이미 배포된 소프트웨어를 대상으로 합니다.
정기적인 패치 일정 없이 "문제가 생기면 그때 고친다"는 방식은, 문제가 생긴 뒤에는
이미 데이터 유출 등 돌이키기 어려운 결과로 이어질 수 있습니다.
오류 제보를 받는 창구
실제 사용자가 겪는 불편은 개발 단계에서 모두 예측하기 어렵습니다. 오류 제보나 개선 제안을
간단하게 남길 수 있는 창구를 마련해두고, 이를 정기적으로 검토해 반영하는 것만으로도
소프트웨어의 완성도는 꾸준히 올라갑니다.
유지보수 계약의 범위
보안 패치 및 OS·브라우저 호환성 업데이트 주기
장애 발생 시 대응 시간(SLA)과 연락 체계
기능 개선 요청의 처리 절차와 우선순위 기준
정기 점검 보고서 제공 여부
솔루션 비제트는 구축과 출시 후 유지보수를 함께 다루고 있습니다. 계약할 때에는 운영 중 필요한 지원과 변경 작업의 범위를 나눠 확인해 주세요.
원격 근무
원격 근무 보안, VPN과 함께 점검할 네 가지
솔루션 비제트 · IT 인프라 노트
VPN을 연결했더라도 접속 기기와 계정 상태는 따로 봐야 합니다. 감염된 PC나 유출된 계정의 문제까지 VPN 하나로 해결되는 것은 아닙니다. 원격 업무에서는 기기, 인증, 접근 범위를 함께 점검하세요.
1. 접속 기기의 보안 상태
백신 미설치, OS 업데이트 방치 상태의 개인 PC로 VPN에 접속하면, 암호화된 터널을 통해
오히려 사내망까지 위협이 그대로 전달될 수 있습니다. 재택근무용 기기는 최소한의 백신과
OS 자동 업데이트가 켜져 있는지부터 확인해야 합니다.
2. 계정의 다단계 인증
VPN·사내 시스템 계정에 다단계 인증(MFA)을 적용하면, 비밀번호가 유출되더라도
실제 침해로 이어질 확률을 크게 낮출 수 있습니다. 문자·앱 인증 중 하나만 추가해도
효과가 큽니다.
3. 업무에 필요한 시스템만 접근
VPN에 연결되면 사내망 전체에 접근할 수 있도록 설계된 경우, 계정 하나가 뚫리면
피해 범위가 회사 전체로 커집니다. 부서·업무별로 접근 가능한 시스템을 분리하는
최소 권한 원칙을 원격 근무 환경에도 동일하게 적용해야 합니다.
4. 공용 와이파이 사용 기준
카페, 공항 등 공용 와이파이는 중간자 공격에 취약할 수 있습니다. VPN을 켠 상태에서만
업무 시스템에 접속하도록 원칙을 정하고, 구성원들에게 명확히 안내하는 것만으로도
사고 가능성을 줄일 수 있습니다.
원격 근무 환경을 점검할 때는 VPN 연결과 함께 접속 기기, 계정 인증, 허용한 시스템을 살펴보세요. 구성원이 실제로 따를 수 있는 사용 기준도 정해두어야 합니다.
PC 관리
PC가 느려졌을 때 포맷 전에 살펴볼 다섯 가지
솔루션 비제트 · 컴퓨터 활용 노트
PC가 느려졌다고 바로 포맷하면 자료를 옮기고 프로그램을 다시 설치해야 합니다. 우선 작업 관리자와 저장 공간부터 살펴보세요. 언제 느려지는지 기록하며 아래 항목을 보면 원인을 좁히는 데 도움이 됩니다.
1. 시작 프로그램
부팅할 때마다 자동으로 실행되는 프로그램이 많을수록 체감 속도는 크게 떨어집니다.
작업 관리자의 '시작 프로그램' 탭에서 영향이 '높음'으로 표시된 항목 중 당장 필요 없는
것부터 사용 안 함으로 바꿔보세요.
2. 디스크 여유 공간
저장 공간이 90% 이상 차 있으면 운영체제가 임시 파일을 만들 공간이 부족해져
전반적인 속도가 느려집니다. 특히 SSD는 여유 공간이 부족할 때 성능 저하가 더 두드러지므로,
최소 10~15% 이상의 여유 공간을 유지하는 것이 좋습니다.
3. 백그라운드 앱과 동기화
클라우드 동기화 프로그램이나 메신저가 백그라운드에서 계속 파일을 스캔·업로드하고 있는
경우가 의외로 많습니다. 작업 관리자에서 CPU·디스크 사용량이 높은 프로세스를 확인해
불필요한 항목을 종료해보세요.
4. 드라이버와 업데이트
오래된 그래픽·칩셋 드라이버는 성능 저하는 물론 시스템 불안정의 원인이 되기도 합니다.
제조사 사이트에서 최신 드라이버를 확인하고, 윈도우 업데이트가 장기간 밀려 있지 않은지도
점검해야 합니다.
5. 악성코드 검사
이유 없이 CPU·네트워크 사용량이 계속 높게 유지된다면 악성코드 감염을 의심해볼 필요가
있습니다. 신뢰할 수 있는 백신으로 정밀 검사를 진행해 이상 유무를 먼저 확인하세요.
점검 뒤에도 느린 상태가 계속되면 발생 시점과 자원 사용량을 기록해 추가로 원인을 살펴봅니다. 재설치나 하드웨어 교체가 필요한지는 자료 백업과 사용 중인 프로그램을 확인한 뒤 결정하세요.
계정 보안
비밀번호 재사용 줄이기와 다단계 인증
솔루션 비제트 · 계정 보안 노트
복잡한 비밀번호라도 여러 사이트에서 똑같이 쓰면 한 곳의 유출이 다른 계정에 영향을 줄 수 있습니다. 비밀번호를 길게 만드는 것과 함께 재사용 여부, 보관 방법, 다단계 인증을 살펴보세요.
사이트마다 다른 비밀번호
한 사이트에서 유출된 아이디·비밀번호 조합은 다른 사이트에 그대로 대입해보는
'크리덴셜 스터핑' 공격에 악용됩니다. 중요도가 높은 계정(이메일, 업무 시스템, 금융)만이라도
서로 다른 비밀번호를 사용하는 것이 단순 복잡도를 높이는 것보다 훨씬 효과적입니다.
비밀번호 관리 도구
모든 계정마다 다른 비밀번호를 외우기는 현실적으로 어렵습니다. 비밀번호 관리자를 사용하면
긴 무작위 비밀번호를 계정마다 자동으로 생성·저장할 수 있어, 사용자는 관리자 자체의
마스터 비밀번호 하나만 기억하면 됩니다.
이메일과 업무 계정의 MFA
비밀번호가 유출되더라도 다단계 인증이 켜져 있으면 실제 로그인까지 이어지기 어렵습니다.
이메일, 업무용 클라우드 서비스만이라도 우선적으로 MFA를 적용하는 것을 권장합니다.
유출 여부와 변경 시점
특별한 이유 없이 3개월마다 비밀번호를 바꾸도록 강제하는 정책은 오히려 사용자가
예측 가능한 패턴으로 비밀번호를 바꾸게 만들어 실효성이 떨어진다는 연구 결과가 많습니다.
그보다는 내 계정 정보가 유출된 적이 있는지 주기적으로 확인하고, 유출이 확인된 경우에만
즉시 변경하는 방식이 더 실용적입니다.
계정마다 다른 비밀번호를 쓰고, 관리 도구와 다단계 인증을 함께 살펴보세요. 유출 사실을 알게 됐을 때 어떤 계정을 변경해야 하는지도 파악해 두면 대응에 도움이 됩니다.
데이터 백업
로컬과 클라우드 백업, 보관 위치와 복구 방법 비교
솔루션 비제트 · 데이터 관리 노트
외장 저장소와 클라우드 중 어디에 백업할지 고민할 수 있습니다. 복구 속도와 접근 방법, 원본과 함께 손상될 가능성을 각각 따져보세요. 백업 위치를 정한 뒤에는 복원할 파일이 실제로 열리는지 시험해야 합니다.
로컬 백업의 장단점
외장 하드나 NAS를 이용한 로컬 백업은 복구 속도가 빠르고 인터넷 환경에 좌우되지 않는다는
장점이 있습니다. 다만 화재, 침수, 도난처럼 '같은 공간에서 발생하는 재해'에는 원본과
백업본이 동시에 손상될 위험이 있습니다.
클라우드 백업의 장단점
클라우드 백업은 물리적 재해로부터 안전하고 외부 어디서든 접근할 수 있다는 장점이 있지만,
인터넷 회선 속도에 따라 대용량 복구에 시간이 오래 걸릴 수 있고, 랜섬웨어에 감염된 상태로
동기화되면 클라우드상의 파일도 함께 손상될 수 있다는 점을 유의해야 합니다.
복사본을 나누는 3-2-1 원칙
중요 데이터는 최소 3개의 복사본을 유지한다
그중 2개는 서로 다른 저장 매체(예: 내부 디스크 + 외장 디스크)에 보관한다
그중 1개는 물리적으로 다른 장소(클라우드 등 오프사이트)에 보관한다
백업 뒤의 복구 시험
백업 파일이 실제로 정상 복구되는지 정기적으로 테스트하지 않으면, 정작 필요한 순간에
손상된 백업본만 남아있는 상황을 맞을 수 있습니다. 분기에 한 번 정도는 샘플 파일을
실제로 복구해보는 절차를 권장합니다.
백업은 한곳에 모으기보다 각 보관 방식이 어떤 상황에 취약한지 보고 나눠 구성합니다. 선택한 조합으로 필요한 파일을 실제로 복구할 수 있는지도 시험해 보세요.
업무 생산성
보고서 자료를 찾기 쉽게 정리하는 네 가지 습관
솔루션 비제트 · 업무 효율 노트
보고서를 쓰기 전에 자료 찾는 데 시간을 쓰고 있다면 평소 정리 방식부터 손볼 만합니다. 회의 직후 남긴 담당자와 기한, 원본 파일 링크가 있으면 기억을 더듬는 일을 줄일 수 있습니다.
1. 팀에서 같이 쓰는 폴더 규칙
개인마다 다른 방식으로 폴더를 만들면, 본인은 익숙해도 팀 전체로 보면 자료를 찾는 데
시간이 더 걸립니다. 연도-분기-프로젝트명처럼 팀 전체가 동일하게 적용할 수 있는
단순한 규칙 하나를 정해두는 것이 훨씬 효율적입니다.
2. 회의 직후 결정사항 기록
회의가 끝나면 결정사항, 담당자, 기한을 짧게 적어두세요. 며칠 뒤 보고서를 쓸 때 기억에만 의존하지 않고 회의 기록을 다시 볼 수 있습니다.
3. 반복 보고서의 공통 양식
매주·매월 형식이 비슷한 보고서를 매번 새로 작성하고 있다면, 공통 항목을 템플릿으로
만들어두는 것만으로 작성 시간을 크게 줄일 수 있습니다. 바뀌는 숫자와 코멘트만
채워 넣는 구조로 바꿔보세요.
4. 캡처와 함께 원본 링크
화면 캡처 이미지만 저장해두면 나중에 값이 바뀌었을 때 다시 찾아야 합니다.
가능하다면 원본 파일이나 시트에 대한 링크를 함께 기록해두는 습관을 들이면,
최신 데이터를 다시 확인하는 시간을 크게 줄일 수 있습니다.
폴더 규칙과 회의 기록, 반복 보고서 양식을 팀에서 함께 쓰도록 정해보세요. 누가 자리를 비워도 원본 자료를 찾아 이어서 작성할 수 있는지가 기준입니다.
프로그램 비교
알집·반디집·7-Zip, 업무용으로 고를 때 볼 항목
솔루션 비제트 · 프로그램 활용 노트
회사 PC에 압축 프로그램을 설치할 때는 지원 포맷 외에 사용 조건도 봐야 합니다. 개인용 무료 안내가 업무 사용에도 같은지 확인하세요. 알집, 반디집, 7-Zip을 고를 때 살펴볼 항목을 정리했습니다.
알집(ALZip)
국내에서 가장 오래 쓰인 압축 프로그램 중 하나로, 한글 파일명 처리와 국내 사용 환경에
맞춘 인터페이스가 특징입니다. 가정용은 무료로 제공되지만 기업에서 영리 목적으로 사용할 경우
별도의 유료 라이선스가 필요하다는 점을 꼭 확인해야 합니다.
반디집(Bandizip)
가볍고 빠른 압축·해제 속도로 알려져 있으며, 개인 사용자뿐 아니라 상업적 용도로도
무료로 사용할 수 있다는 점이 큰 장점입니다. ZIP, 7Z, RAR 등 주요 압축 포맷을 폭넓게
지원하고, 미리보기 기능이 강점으로 꼽힙니다.
7-Zip
오픈소스 기반의 압축 프로그램으로, 완전 무료이며 상업적 이용에도 제약이 없습니다.
자체 포맷인 7z는 같은 데이터 기준으로 압축률이 높은 편으로 알려져 있으며, 명령줄(CLI)
지원이 되어 개발자나 자동화 스크립트에서도 활용하기 좋습니다. 다만 인터페이스는
상대적으로 단순한 편입니다.
회사에서 설치하기 전에
가볍고 무료로 상업적 이용까지 하고 싶다면 → 반디집 또는 7-Zip
높은 압축률과 명령줄 자동화가 필요하다면 → 7-Zip
익숙한 국내 인터페이스가 우선이라면 → 알집(단, 기업 사용 시 라이선스 확인 필수)
회사에서 설치할 프로그램은 해당 제품과 버전의 이용 조건을 확인하세요. 개인용 무료 안내와 업무 사용 조건이 같은지 따로 읽어보는 것이 좋습니다.
업무 도구
클라우드와 설치형 오피스, 업무 방식에 맞춰 고르기
솔루션 비제트 · 업무 도구 노트
오피스 도구를 바꿀 때는 함께 편집하는 일이 많은지, 복잡한 수식과 인쇄 서식을 쓰는지부터 보세요. 클라우드와 설치형을 하나로 통일하지 않고 업무별로 나눠 쓸 수도 있습니다.
공동 편집과 외부 협업
여러 명이 동시에 한 문서를 편집하거나, 외부 협업이 잦거나, 재택·외근이 많은 조직이라면
실시간 공동 편집과 어디서나 접속 가능한 클라우드 오피스가 유리합니다. 버전 충돌
걱정 없이 항상 최신 문서를 유지할 수 있다는 것도 큰 장점입니다.
복잡한 문서와 불안정한 회선
복잡한 수식이 많은 대용량 엑셀 작업, 정교한 인쇄 레이아웃이 필요한 문서, 인터넷 연결이
불안정한 현장 환경이라면 아직은 설치형 오피스의 처리 속도와 기능 완성도가 더 안정적인
경우가 많습니다.
업무별로 병행하기
실제로는 두 방식을 완전히 하나로 통일하기보다, 협업·회의 문서는 클라우드 오피스로,
정산·보고용 대용량 문서는 설치형 오피스로 나눠 쓰는 조직도 많습니다. 도구를 하나로
강제 통일하기보다 업무 성격에 맞게 병행하는 것이 현실적인 해법이 될 수 있습니다.
도구를 정한 뒤에는 어디에 저장하고 어떤 링크로 공유할지 규칙을 맞춰보세요. 파일 이름과 최신본 기준이 제각각이면 같은 문서를 다시 찾는 문제가 남습니다.
컴퓨터 활용
노트북 배터리 관리, 충전 설정과 발열 살펴보기
솔루션 비제트 · 컴퓨터 활용 노트
노트북을 늘 전원에 꽂아 쓰거나 오래 보관한다면 배터리 관리 방법을 살펴볼 만합니다. 충전 상한 설정이 있는지, 사용 중 열이 잘 빠지는지부터 보세요. 수명은 기기와 사용 조건에 따라 달라집니다.
충전과 완전 방전
배터리를 완전히 방전시킨 뒤 100%까지 꽉 채우는 습관보다는, 20~80% 구간을 유지하며
충전하는 것이 배터리 수명에 더 유리한 것으로 알려져 있습니다. 최근 출시되는 노트북은
충전 상한선을 설정할 수 있는 기능을 제공하는 경우가 많으니 활용해볼 만합니다.
열이 빠질 수 있는 사용 환경
배터리는 열에 특히 취약합니다. 노트북을 이불이나 쿠션 위에 올려두고 장시간 사용하면
내부 온도가 올라가면서 배터리 열화가 빨라집니다. 통풍이 되는 딱딱한 바닥에서 사용하는
것만으로도 배터리 수명에 도움이 됩니다.
장기간 보관할 때의 충전량
노트북을 오래 사용하지 않고 보관해야 한다면, 완전 충전이나 완전 방전 상태보다
50% 내외로 충전해둔 뒤 보관하는 것이 배터리에 더 안전합니다.
업무용 노트북이라면 충전 설정과 통풍이 막히지 않는 사용 위치를 안내해 두세요. 기기별 제공 기능은 제조사 안내와 실제 설정에서 확인할 수 있습니다.
보안 인식
피싱 메일을 의심할 만한 주소·요청·첨부파일
솔루션 비제트 · 보안 인식 노트
문장이 자연스럽고 발신자 이름이 익숙한 메일도 내용을 다시 봐야 할 때가 있습니다. 평소와 다른 송금 요청이나 로그인 링크가 있다면 주소와 첨부파일을 확인하고 다른 연락 수단으로 물어보세요.
1. 표시 이름과 실제 발신 주소
메일 클라이언트에 표시되는 이름은 얼마든지 조작할 수 있습니다. 발신자 이름이
익숙하더라도, 실제 이메일 주소(@ 뒤 도메인)가 평소 쓰던 주소와 미묘하게 다르지는 않은지
반드시 확인하는 습관이 필요합니다.
2. 평소보다 급한 요청
"지금 바로 처리하지 않으면 계정이 정지됩니다", "오늘 중으로 송금 부탁드립니다"처럼
평소보다 유독 긴급함을 강조하는 메일은 판단을 흐리게 만들려는 의도일 가능성이 높습니다.
급할수록 한 박자 쉬고 다른 채널(전화 등)로 재확인하는 것이 안전합니다.
3. 표시 문구와 실제 링크
메일 속 링크에 마우스를 올렸을 때 하단에 표시되는 실제 주소가, 화면에 보이는 텍스트나
익숙한 사이트 이름과 다르다면 클릭하지 말아야 합니다. 로그인 페이지처럼 보이는 가짜
페이지로 연결되는 경우가 많습니다.
4. 첨부파일 확장자
문서 파일처럼 보이지만 실제로는 실행 파일(.exe, .scr 등)인 첨부파일은 특히 위험합니다.
평소 주고받지 않던 형식의 첨부파일이라면 발신자에게 별도 채널로 진위를 확인한 뒤
여는 것이 안전합니다.
의심되는 메일은 바로 처리하지 말고 발신 주소와 링크, 첨부를 살펴보세요. 평소와 다른 요청이라면 이미 알고 있던 연락처로 확인한 뒤 진행합니다.
브라우저 보안
크롬 확장 프로그램 설치 전에 권한과 개발자 확인하기
솔루션 비제트 · 브라우저 보안 노트
확장 프로그램을 설치할 때는 기능 설명 다음에 권한 목록을 읽어보세요. 메모 도구에 모든 사이트의 데이터를 읽는 권한이 필요한지 같은 질문입니다. 개발자와 업데이트 이력, 사용 중인 확장 개수도 함께 볼 만합니다.
1. 기능에 필요한 권한인지
단순 메모 확장 프로그램인데 '모든 웹사이트의 데이터 읽기 및 변경' 권한을 요구한다면
한 번쯤 의심해볼 필요가 있습니다. 설치 전 권한 목록을 읽어보는 습관만으로도
위험한 확장 프로그램을 상당수 걸러낼 수 있습니다.
2. 개발자와 업데이트 이력
스토어 페이지에서 개발자가 명확히 표시되어 있는지, 최근까지 꾸준히 업데이트되고 있는지
확인하세요. 오랫동안 방치된 확장 프로그램은 소유권이 다른 곳으로 넘어가 악성 코드가
추가된 사례도 실제로 보고된 바 있습니다.
3. 쓰지 않는 확장 정리
당장 쓰지 않는 확장 프로그램은 비활성화가 아니라 완전히 삭제하는 것이 안전합니다.
사용하지 않는 확장 프로그램도 백그라운드에서 계속 실행되며 브라우저 정보에 접근할 수
있는 상태로 남아있을 수 있습니다.
4. 업무용 프로필 분리
회사 계정으로 로그인하는 업무용 브라우저 프로필에는 검증되지 않은 확장 프로그램 설치를
최소화하고, 개인적으로 다양한 확장 프로그램을 테스트하고 싶다면 별도 프로필이나
브라우저를 분리해서 사용하는 것을 권장합니다.
설치 전 권한과 개발자를 보고, 사용하지 않는 확장은 정리해 두세요. 업무용 프로필에서는 필요한 기능만 남겨 관리할 항목을 줄일 수 있습니다.