택배가 왔는지 10분마다 문을 열어 확인하는 일과, 기사가 초인종을 누르면 그때만 나가는 일은 다릅니다. Grok Bot 웹훅은 반복 확인과 실제 작업의 시작을 분리하는 초인종으로 이해할 수 있습니다. 중요한 것은 확인 작업을 없애는 것이 아니라 누가 확인하고 언제 봇을 부르는지 바꾸는 설계입니다. 초인종 원리: 확인과 실행을 분리합니다 공식 문서는 루틴이 한 번 실행될 때마다 사용량을 쓰며, 짧은 간격의 반복은 하루에 일주일분을 쓸 수도 있다고 경고합니다. 많은 자동화가 새 일이 있는지 봇에게 계속 묻는 방식이라면 빈 확인도 실행에 포함됩니다. Grok Bot에서는 루틴마다 고유한 주소가 생기고, 프로그램이 그 주소로 신호를 보내면 봇이 깨어나 일합니다. 공개된 활용법은 반복 조회를 로컬 스크립트에 맡기고 새 일이 있을 때만 웹훅으로 봇을 부르는 방식입니다. 초인종 역할을 맡는 작은 스크립트의 조회에는 봇 사용량이 들지 않습니다. 다만 로컬 스크립트의 반복 조회는 계속 돌아가므로, 그 비용까지 사라지는 것은 아닙니다. 봇 호출을 줄이는 일과 전체 운영 비용을 없애는 일은 구분해야 합니다. 공식 문서가 안내하는 호출 방식 루틴은 일정뿐 아니라 웹훅 호출로도 시작할 수 있습니다. 데스크톱 루틴 화면의 Webhook 칸에는 주소, 비밀 키, 복사할 전체 헤더가 안내됩니다. 항목 공식 안내 요청 HTTP POST로 주소에 전송하며 키는 Authorization Bearer 헤더에 넣습니다. 본문 JSON 본문은 선택이며 봇이 루틴 지시와 함께 받습니다. 응답 200 호출을 받아 실행을 시작했다는 뜻입니다. 완료 결과는 봇 대화에서 확인합니다. 한도 전체 루틴 합쳐 시간당 300회, 개별 루틴 시간당 200회입니다. 한도 초과 실패한 실행은 자동으로 다시 돌지 않으므로 웹훅을 다시 보내야 합니다. 시간 예약 스케줄 루틴의 최소 간격은 5분입니다. 실전 적용은 세 단계입니다 루틴에 웹훅 트리거를 만들고 사건이 오면 할 일을 지시합니다. ...
일반적으로 크롬북의 성능은 Octane Score-Javascript benchmark 측정치 (http://chromium.github.io/octane/)로 가늠을 하곤 한다. 삼성 크롬북 플러스의 Octane Score 는 9480. 참고로 Asus Chromebook Flip 10.2 의 Score 는 4805 그러나 이수치는 단치 참고할 뿐이지 실제 크롬북 전체의 성능을 가늠하는 수치는 아닌 듯 하다. 겨울 날씨 예보에서는 영하 1도이지만 실제 체감 온도는 영하 5도 일 수 있듯이, 크롬북도 실제로 체감속도가 있는 듯 하다. 즉, 사용자의 사용 용도 패턴과 주요 업무가 무엇인가에 따라서, 체감속도는 느릴수도 있고, 빠를 수 도 있을 듯 하다. 1주일간 업무용을 사용해본 소감(체감 속도)은, 우선 이 기기는 ARM CPU 계열인 것을 보면 알수 있듯이, 클릭하면 빠릿 빠릿하게 응답을 하는 그러한 기기는 분명아니다. 하지만, 대부분의 일반 업무용 작업 (G Suite 클라우드 기반) 에서는 아주 문안하게 동작하고 적당한 반응을 (빠른 반응도 아니고, 그렇다고 버벅 되는 랙이 걸리는 것이 아닌 평범한 응답 속도) 보인다. 뿐만아니라, 안드로이드 앱들은 생각보다 정상 동작을 넘어서 기대 이상의 성능을 보이고 있다. (아마도 ARM 칩 계열이 주는 이점중에 하나 인듯) 물론 내 개인적인 업무 패턴에서는 이 삼성 크롬북에서 안드로이드 앱을 사용하는 일은 거의 없다. 단지, 하나외환 은행거래를 주로 모바일에서 사용하고 있어서, 이 금융 앱 (KEB 하나은행)을 설치한 후 공인인증서 가지고 오기까지 무리 없이 동작을 하는 것으로 보고 내심 놀라기도 하였다. 이유는 이전에 Asus Chromebook Flip 10.2 에서는 같은 Chrome OS와 안드로이드 앱이 지원이 되었어도, 이 금융앱은 동작하지 않았기 때문이다. 추측...