안녕하세요 msjcard 님. wave 최신 버전으로 받아서 설치부터 우선해주세요. 그냥 한번더 설치하시면 덮어씌워집니다. 재시작한번하시구요. https://github.com/dandacompany/waveterm/releases/tag/v0.17.3 그리고, File Browser가 팝업메뉴에 등장하게 하려면, 터미널 패널 마우스를 두고 오른쪽 마우스를 누르셔야합니다. 또 안되시면 남겨주세요~
안녕하세요, 종태님. SAM 프로필 설정 문제가 아니라 Linux 키링을 실행한 세션과 SAM이 동작하는 세션이 서로 달라서 생긴 현상일 가능성이 큽니다. 키링 암호는 키움에서 발급되는 암호가 아닙니다. App Key·Secret을 암호화해 보관하는 Linux 자격증명 저장소의 잠금 암호이며, 처음 만들 때 사용자가 직접 정합니다. 일반 터미널에서는 잠금이 풀려 있어도 SAM이 백그라운드 서비스나 다른 터미널에서 실행되면 그 잠금 해제 상태를 이어받지 못할 수 있습니다. 먼저 아래 프롬프트로 헤르메스에이전트 세션에 요청을 해보세요. 키움 CLI의 자격증명 저장소를 읽기 전용으로 진단해 줘. 현재 실행되는 kiwoomcli의 실제 설치 위치와 Python 실행 환경을 스스로 찾아서, 그 환경에서 활성화된 Python Keyring 백엔드의 정확한 모듈명과 클래스명을 확인해 줘. 확인 결과가 Linux Secret Service 기반인지, 암호 입력이 필요한 파일형 Keyring인지, 또는 사용할 수 없는 백엔드인지 구분해 줘. 일반 터미널에서는 동작하지만 현재 Sam 세션이나 백그라운드 작업에서는 자격증명을 읽지 못할 가능성도 함께 점검해 줘. App Key, Secret, 토큰, 계좌번호, Keyring 암호는 절대 읽거나 출력하지 마. Keyring을 삭제하거나 변경하거나 새로 만들지 말고 진단만 수행해 줘. 마지막에는 다음 항목만 보고해 줘. (1) 발견한 kiwoomcli 실행 경로 (2) 활성 Keyring 백엔드의 정확한 이름 (3) 현재 실행 환경에서 자격증명 저장소 접근 가능 여부 (4) Secret Service 사용 여부 (5) 대화형 암호 입력이 필요한 백엔드인지 여부 (6) Sam에서 자격증명을 읽지 못하는 원인과 안전한 다음 조치 판단할 근거가 부족하면 정상이라고 추정하지 말고, 확인하지 못한 항목을 그대로 표시해 줘. Ubuntu에서는 gnome-keyring, libsecret-tools, dbus-user-session을 설치하고 Secret Service를 시작·잠금 해제한 동일한 터미널에서 다음 순서로 확인해 주세요. kiwoomcli auth login --alias 모의계좌 --mode demo kiwoomcli auth status --profile 모의계좌 kiwoomcli doctor 세 결과에서 자격 증명 존재, 토큰 유효, 지금 API 호출 가능이 모두 정상인지 확인한 다음, 같은 터미널에서 hermes -p sam을 새로 시작해야 합니다. 기존 SAM이나 백그라운드 Kanban 작업은 이전 키링 환경을 계속 사용하므로 종료 후 새로 시작해 주세요. 위의 백엔드 이름과 auth status, doctor 결과를 키·토큰 값 없이 남겨 주셔야 어느 단계에서 분리됐는지 정확히 확인이 가능할듯합니다.
안녕하세요 정재님. 초기화 할때, profiles/[프로필폴더] 를 다른곳에 백업하시고 삭제하시면되고, 프로필별이 아닌 글로벌 스킬은 하나씩 검토해보시면서 빌트인 스킬 빼고 나머지를 검토하시면서 불필요한건 삭제하시는걸 추천드립니다. 그리고 초기화 자체를 헤르메스 에이전트 세션 내에서 에이전트에게 메타 작업으로 주시면 좋을것 같습니다. 새로 전체를 지우시는것은 그동안의 축적된 것들을 완전 삭제하는거라 쌓인 지식 자산을 보내버리는것이기 때문에 추천드리고 싶지는 않네요. 에이전트 환경 자체를 정리하는것도 일종의 '하네스' 엔지니어링이고 그것을 에이전트에게 시켜서 하나씩 정리하시는것도 좋은 연습이 되실것입니다.
안녕하세요. AJAJ님. 단테입니다. 보여주신 로그는 API 키 입력 오류라기보다 OpenAI Codex 서버가 요청을 처리하는 과정에서 일시적으로 실패한 경우에 가깝습니다. openai-codex, gpt-5.5까지 인식됐고 앞선 파일수정도 진행됐기 때문에 인증 자체는 동작한 것으로 보입니다. 우선 잠시 기다린 뒤 해당 카드를 다시 준비됨(Ready)으로 옮기고 넛지 디스패처를 눌러 재시도해 주세요. 이미 생성된 파일이 있다면 “기존 결과를 확인하고 중단된 지점부터 계속해 줘”라고 남기면 중복 작업을 줄일 수 있어요. 만약 같은 오류가 계속 반복되면 터미널에서 아래 항목을 확인해 주세요. hermes auth status openai-codex hermes status --all hermes logs errors --since 1h 인증 상태가 비정상일 때만 hermes login --provider openai-codex로 다시 로그인하면 됩니다. 정상인데도 반복된다면 새 세션에서 다시 실행하거나 폴백 모델을 설정하는 방법을 권장드립니다.
hyun2597님 안녕하세요. 먼저 Slack 동작은 정상입니다. 나눠서 번호달아 답변드립니다. 1. DM에서 스레드로 답변이 오지 않는 부분 Slack의 1:1 DM은 채팅창 자체가 한 사람과 이어가는 대화 공간입니다. 따라서 Hermes가 별도의 답글 스레드를 만들지 않고 DM 창에 일반 메시지로 답하는 것이 자연스러운 동작입니다. 채널에서는 여러 대화가 섞일 수 있으므로, Hermes를 멘션한 메시지 아래에 스레드를 만들어 답변합니다. 정리하면 다음과 같습니다. - 1:1 DM: DM 채팅창에 일반 메시지로 답변 - Slack 채널: 멘션한 메시지의 스레드로 답변 현재 설정의 reply_in_thread: true는 채널에서 정상적으로 적용되고 있으므로 별도로 수정하지 않으셔도 됩니다. 2. gateway shutting down 표시 첨부해 주신 화면을 보면 gateway 재시작이 정상적으로 완료된것 으로 보입니다. 저 메세지는 오류에 대한 동작이 아닙니다. 게이트웨이의 재시작이 필요할때, 슬랙으로 발송되는 자동 얼럿 메세지입니다. 업데이트를 하거나, 수동으로 게이트웨이 재시작을 하는 경우 계속 저 메세지가 슬랙으로 날아옵니다. 해결하려고 노력하지 않으셔도 됩니다. 저도 아래와 같은 메세지가 동일하게 뜹니다. 정상 동작이니 오해없으시면 좋겠습니다.
허준님 안녕하세요. 말씀하신 Unit 6.4의 Ethan에게 전달하는 블로그 콘텐츠 파이프라인 프롬프트가 기존 강의자료에서 확인하기 어렵게 되어 있었습니다. 현재 수강생 전용관 → 섹션 6 → Unit 6.4 멀티프로필 블로그 파이프라인 자료에 해당 프롬프트를 단계별로 다시 정리해 반영했습니다. Ethan에게 전달하는 파이프라인생성·보강·등록 프롬프트뿐 아니라, Mia 디자인 검증과 개발·운영 발행 승인 프롬프트까지 함께 보완했습니다. 자료 위치를 찾기 어렵게 구성해 둔 점 양해 부탁드립니다. 질문 남겨주셔서 감사합니다.
안녕하세요! 결론부터 말씀드리면 gapo76님께서 놓치신 부분은 없으며, 현재 실습에서는 그룹 ID가 없어도 정상적으로 진행할 수 있습니다. 강의에서 -로 시작하는 그룹 ID를 메모하라고 안내했지만, 이후 실제 Hermes 설정에서는 개인 User ID를 허용 사용자로 등록하고 개인 DM을 홈 채널로 선택했습니다. 그래서 앞에서 기록한 그룹 ID가 설정 단계에 다시 등장하지 않았습니다. 이 부분은 강의 안내가 매끄럽게 이어지지 못한 부분입니다. 두 ID의 역할은 서로 다릅니다. - 개인 User ID: 누가 봇을 사용할 수 있는지 제한하는 보안 설정 - 그룹 ID: 특정 그룹을 알림 수신처로 지정하거나, 봇이 동작할 그룹을 제한할 때 사용하는 선택 설정 따라서 봇과 개인 DM이 정상적으로 되고, 봇을 추가한 그룹에서도 허용된 사용자가 대화할 수 있다면 그대로 다음 강의로 진행하셔도 됩니다. 나중에 해당 그룹을 cron 결과나 알림이 도착하는 기본 채널로 지정하고 싶다면, 현재 Hermes에서는 그 그룹 안에서 다음 명령을 보내면 됩니다. /set-home 이 경우에도 그룹 ID를 직접 찾을 필요가 없습니다. 정리하면, 이번 강의 실습에서는 그룹 ID가 필수값이 아니며, 개인 User ID와 봇 토큰만 제대로 등록하셨다면 정상적으로 완료하신 것입니다. 혼란을 드려 죄송하며 해당 부분은 강의 보충 안내에 반영하겠습니다.
안녕하세요 용민님. config.yaml에 platforms: 로 바로시작하는 키는 없고, 계층 구조가 아래와 같습니다. display: ... platforms: 해당 계층에서 platforms가 안보이신다면, 대시보드 > 설정 > 검색 을 통해서 설정해보시는 방법도 있습니다. 그리고 문제가 해결되지 않으실때는 헤르메스 에이전트 세션 내에서 요청을 해보시는것도 좋습니다. 해당 문제는 일반적인 상황은 아니어서, 짧은 문의 내용 만으로 제가 다 파악하기가 어렵네요. 해결이 잘 되셨으면 좋겠습니다.
안녕하세요! 용민님. 결론부터 말씀드리면, 현재 칸반 강의를 그대로 따라가는 중이라면 Temporary를 선택하시면 됩니다. 화면이 강의와 다른 이유는 Hermes가 강의 녹화 이후 업데이트되면서 카드마다 작업 공간을 선택하는 기능이 추가됐기 때문입니다. 강의는 Desktop v0.16.0 기준이고, 이 선택 화면은 이후 버전에 추가되었습니다. 오류나 설치 문제는 아닙니다. 세 가지 옵션은 다음과 같습니다. - Temporary: 카드 전용 임시 폴더에서 작업합니다. 조사, 요약, 아이디어 작성 등 일반적인 칸반 작업에 사용합니다. 작업 완료 후 임시 폴더는 정리 될 수 있습니다. - Git worktree: Git 프로젝트의 코드를 여러 에이전트가 동시에 수정할 때 사용합니다. 별도의 브랜치와 작업 폴더를 만들어 충돌을 줄여줍니다. - Directory: 이미 만들어진 특정 폴더에서 작업해야 할 때 사용합니다. 결과 파일을 해당 프로젝트 폴더에 계속 남겨야 한다면 이것을 선택하고 폴더경로를 지정합니다. 따라서 현재 3.8 칸반 강의의 MAGMA 카드 실습에서는 Temporary를 선택한 후 카드를 추가해주세요. Git worktree는 Git·GitHub 병렬 개발 실습에 가서 사용하는 고급 옵션이고, Directory는 특정 프로젝트 폴더를 연결할 때 사용합니다. 요컨데, 일반 업무·강의 실습은 Temporary, 기존 폴더에 결과를 남길 때는 Directory, Git 코드 병렬 작업은 Git worktree 이라고 생각하시면 됩니다. 강의 화면과 달라 혼란스러우셨을 텐데, 업데이트로 생긴 정상적인 차이이며 Temporary를 선택하면 다음 단계로 진행할 수 있습니다.