사내 메신저에 GitHub·Jira 알림을 받고 봇으로 조회할 수 있나요? 웹훅·봇 API 정리

인사책 사내 메신저는 외부 도구의 알림을 지정한 채널로 받을 수 있습니다.
채널마다 만드는 수신 웹훅 주소에 「text」 칸이 있는 JSON 을 POST 하면 되고,
채널 대화를 읽고 쓰는 봇 API 토큰도 메신저 관리자(admin)가 발급합니다.
다만 GitHub·Jira 가 보내는 원래 형식을 메신저가 직접 해석하는 전용 커넥터와,
메신저 안에서 외부 시스템을 부르는 슬래시 명령·발신 웹훅은 이 글이 확인한 구현에 없어서,
GitHub·Jira 알림은 「text」 칸을 채워 주는 중간 단계(GitHub Actions 단계나 n8n 같은 자동화 도구)를 한 번 거쳐야 하고 명령형 업무는 다른 도구를 함께 검토하셔야 합니다.

사내 메신저는 정상 운영 중입니다.
회사관리자가 켜고 이용 권한을 발급한 직원에게 보입니다.
이 글의 메신저 사양은 2026-10-21 메신저 구현 문서와 코드를 읽어 정리한 것이며,
실제 토큰으로 이벤트를 보내 본 시험은 하지 않았습니다.

한눈에 보는 답

외부 연동을 한 단어로 묻지 않고 「무엇이 → 어디로 → 누구 권한으로」 나눠서 보면 인사책 메신저가 되는 것과 안 되는 것이 갈립니다.
아래 표의 「인사책에서」 칸은 메신저·인사책 구현과 인사책 공개 안내에 정해진 동작을 옮긴 것이며,
실제 고객 계정 시연 결과가 아닙니다.

연동은 세 가지로 나눠 물어야 합니다

연동이라는 한 단어에는 서로 다른 세 가지가 섞여 있습니다.
인사책 메신저는 첫째만 구현이 있고,
둘째는 구현이 없으며,
셋째는 메신저 안의 글·파일까지만 맡습니다.

• 알림을 받는 연동: 외부 앱의 이벤트가 채널에 글로 올라옵니다.
  인사책 메신저는 수신 웹훅으로 이 일을 합니다.
• 메시지에서 명령을 보내는 연동: 채팅창에서 명령을 치거나 메시지에서 동작을 골라 외부 시스템을 부릅니다.
  인사책 메신저에는 슬래시 명령도 발신 웹훅도 이 글이 확인한 구현에 없습니다.
• 두 시스템의 데이터를 바꾸는 연동: 한쪽에서 바꾸면 다른 쪽 원본이 바뀌는 방식입니다.
  인사책 메신저의 봇 API 는 메신저 안의 글과 파일을 읽고 쓰는 데까지이며,
  외부 시스템의 원본을 바꾸는 일은 고객이 만드는 자동화가 맡습니다.

인사책의 Slack 연결은 메신저 연동과 다른 제품 흐름입니다

인사책은 출퇴근 기록을 API 로 Slack 채널에 붙여 줍니다.
이 연결은 인사책에서 Slack 으로 가는 단방향이며,
채널을 정하는 것도 화면 설정이 아니라 문의 접수 → 채널과 범위 정하기 → 채널 게시의 세 단계입니다.
Slack 에서는 출퇴근을 찍을 수 없고,
출퇴근은 인사책에서 회사가 정한 확인 방식(GPS·회사 Wi-Fi·사내망 IP·NFC·QR 등)에 따라 남깁니다.
연동을 끊어도 인사책에 쌓인 기록은 그대로 남고,
직원이 늘어도 요금은 달라지지 않습니다.
이 Slack 연결은 자체 메신저에 GitHub·Jira 같은 외부 앱을 붙이는 기능과 별개이며,
자세한 내용은 슬랙 근태관리 페이지에 있습니다.

메신저로 오는 인사책 알림은 외부에서 부르는 API 가 아닙니다

인사책은 결재 요청,
결재 결과,
휴가 결과,
출퇴근 누락 알림을 메신저의 「인사책 알림」 대화로 한 번 더 보냅니다.
이 알림은 인사책 서버가 메신저로 보내는 내부 호출이라 외부에서 부를 수 있는 공개 주소가 없고,
회사가 메신저를 켜고 받는 직원에게 이용 권한을 발급한 상태일 때만 갑니다.
내용은 알림 제목 한 줄이고 최대 1,000자이며,
보내기에 실패해도 다시 보내지 않습니다.
그래서 이 알림은 고객의 앱이 명령을 받아 실행하는 봇이 아니라 알림 전용입니다.

먼저 확인할 질문 6가지

도입 전에 아래 여섯 가지를 먼저 적어 보면 인사책 메신저로 충분한지,
명령 기능이 있는 도구를 함께 봐야 하는지 스스로 판정할 수 있습니다.

1. 필수로 연결해야 하는 앱 12개(또는 그 이상)의 이름과,
   앱마다 필요한 이벤트는 무엇인가요? 알림만 받는지,
   대화를 읽어 가야 하는지,
   명령으로 부르는지부터 나눕니다.
2. GitHub·Jira 같은 앱의 어떤 이벤트를 어느 채널에 보내나요? 한 채널에 모을지,
   앱마다 채널을 나눌지 정합니다.
3. 토큰·사용자 매핑·중복 알림·실패는 누가 관리하나요? 인사책 메신저의 웹훅은 서명 없이 주소 안의 토큰으로 인증하므로 토큰 보관 담당자를 정해야 합니다.
4. 필요한 것이 읽기 전용 조회인가요,
   데이터를 바꾸는 명령인가요? 메신저 안에서 명령을 받아 실행하는 기능이 필수라면 명령 기능이 있는 도구를 봐야 합니다.
5. 명령 실행자의 권한 검사와 승인·감사 기록이 필요한가요? 인사책 메신저는 메신저 쪽에서 명령 권한을 검사해 주는 층이 없습니다.
6. 외부 앱 자체의 요금,
   중간 단계 도구의 요금,
   만들고 유지할 개발 인력까지 계산했나요? 인사책 메신저의 웹훅·봇 API 는 인원 제한 없는 무료 플랜 안에 있지만,
   중간 단계로 쓰는 외부 도구의 요금은 그 도구의 조건을 따릅니다.

계산해 보기 — 가상의 앱 12개를 나눠 보기

아래는 실제 고객이 아니라 설명을 위해 지어낸 가상의 예입니다.
자동화 도구를 많이 쓰는 스타트업이 필수 앱 12개를 인사책 메신저에 연결한다고 가정하고,
앱마다 필요한 일을 네 묶음으로 나눕니다.

이 계산에서 인사책 메신저가 맡는 앱은 8 + 2 + 1 = 11개이고,
명령형 1개는 다른 도구가 필요합니다.
같은 12개를 Slack 의 앱으로 설치한다고 가정하면,
Slack 도움말(2026-10-21 확인)은 무료 플랜에서 서드파티·맞춤 앱을 최대 10개까지 설치할 수 있다고 하므로 12 − 10 = 2개가 한도를 넘습니다.
다만 Slack 의 수신 웹훅이 이 10개 한도에 세어지는지는 이 글이 쓴 출처로는 확인하지 못했습니다.

재전송 예도 하나 봅니다.
장애 알림 1건을 중계 도구가 실수로 5번 보냈을 때,
5번 모두 같은 「client_msg_id」 를 달았다면 채널에는 글이 1개만 남고 나머지 4번의 응답에는 「deduplicated: true」 가 실려 돌아옵니다.
값이 회사 안에서 겹치지 않아야 하므로,
「jira:PROJ-123:updated:2026-10-21T09:05」 처럼 앱 이름·이벤트 번호·시각을 합쳐 만드는 방식을 권합니다.
이 값의 중복 검사는 채널이 아니라 회사 전체를 기준으로 합니다.

인사책에서 하는 법

메신저 화면은 직원이 인사책에 로그인한 상태에서 「메신저」 칸(기본 하단 바 기준)을 누르면 다시 로그인하지 않고 들어갑니다.
웹훅과 봇 토큰은 메신저의 워크스페이스 관리자(admin) 권한이 있는 사람만 만들 수 있고,
그보다 낮은 관리 권한(sub_admin)은 만들 수 없습니다.
메신저를 발급받은 직원 가운데 인사책의 회사관리자 권한을 가진 직원과 대표는 인사책 직원 명단이 메신저에 동기화될 때 메신저 관리자(admin)로 올라가며,
자동으로 내려가지는 않습니다.
실제로 누구에게 웹훅·봇 메뉴가 보이는지는 도입 전에 실제 계정으로 확인하세요.

1단계 회사관리자가 메신저를 켜고 직원에게 발급합니다

톱니 ⚙ › 「설정」 › 「기능 켜기·끄기」 칸 › 위쪽 「메신저·연동」 탭의 「사내 메신저」 칸에서 켭니다.
켜기는 회사관리자 역할(대표 포함)만 할 수 있고,
처음 켤 때 사업자 확인을 거칩니다.
켠 뒤 「직원 발급 관리」에서 이름을 검색해 「발급」 을 누를 수 있고,
발급을 받은 직원만 메신저를 씁니다.
한 번에 1~200명까지 발급하거나 취소할 수 있고,
발급을 취소하면 그 직원이 인사책으로 들어온 메신저 접속도 끊깁니다.

2단계 채널에서 수신 웹훅 주소를 만듭니다

메신저 안에서 알림을 받을 채널을 우클릭해 「외부 연동 (웹훅)」 을 엽니다.
연동 이름(최대 80자)을 적고,
알림이 올 때 채널 구성원에게 푸시를 보내려면 「받을 때 채널 멤버 전체에 푸시 알림」 을 체크한 뒤(알림을 「전체 메시지」 로 둔 사람에게 갑니다) 「웹훅 URL 만들기」 를 누릅니다.
주소는 「메신저 주소/api/webhooks/in/웹훅 토큰」 꼴로 화면에 표시되고,
토큰은 128자짜리 무작위 문자열입니다.
웹훅은 만들 때마다 새 토큰이 생기므로 연동 앱마다 하나씩 만드는 편이 폐기와 추적에 좋습니다.

3단계 알림을 보냅니다

보내는 쪽은 JSON 본문에 「text」 를 담아 POST 합니다.
아래는 토큰을 가린 가상의 예입니다.

curl -X POST -H 'Content-Type: application/json' \
  -d '{"text":"[배포] web-api v1.8.2 운영 반영 완료","client_msg_id":"deploy:web-api:v1.8.2"}' \
  https://<메신저 주소>/api/webhooks/in/<웹훅 토큰>

파일은 같은 웹훅 주소 뒤에 「/files」 를 붙여 multipart 로 올리며(필드 이름 file),
「comment」 를 함께 보내면 글과 파일이 한 번에 올라갑니다.
글 보내기에 성공하면 「ok: true」 와 함께 글 번호(message_id)·채널 번호·보낸 client_msg_id 가 돌아오고,
파일 올리기에 성공하면 file_id·글 번호·파일 주소가 돌아옵니다.
본문에 「@이름」 이 회사 직원 이름과 맞으면 그 직원에게 알림이 가고(비공개 채널에서는 그 채널 구성원에게만),
「@channel」·「@here」 는 채널 알림이 됩니다.
글의 보낸이는 항상 회사 단위의 「🔔 알림 봇」 한 명이라,
여러 앱을 한 채널에 모으면 글머리에 「[GitHub]」·「[Jira]」 처럼 출처를 적어야 구분됩니다.

4단계 중복을 막고 스레드로 이어 붙입니다

같은 알림을 다시 보낼 수 있다면 「client_msg_id」(최대 200자) 를 반드시 넣습니다.
같은 이슈의 후속 알림을 한 스레드로 모으려면 첫 글의 번호를 「thread_ts」(또는 「parent_message_id」) 로 보냅니다.
부모 글이 그 채널 소속이 아니면 404 「thread_not_found」 로 거절합니다.
「metadata」 에 JSON 개체를 담으면 2,000자까지 저장되고,
나중에 기록 조회에서 되돌려 받습니다.
누락과 중복을 대조하려면 「GET 웹훅 주소/messages」 에 query·from·to·client_msg_id·cursor·limit(1~100,
기본 50)을 붙여 이 웹훅 채널에서 봇이 보낸 글만 조회합니다.
이 조회로는 사람이 쓴 글을 읽을 수 없습니다.

5단계 봇 API 토큰을 발급합니다

대화를 읽거나 파일을 올려야 하면 워크스페이스 메뉴의 「봇 관리 (API 토큰)」 에서 봇을 만듭니다.
봇 이름(최대 80자)과 종류·구분(기본값 「직접 제작」),
읽을 채널을 고르고,
글·파일을 올릴 봇이면 「쓰기도 허용」 을 체크합니다.
토큰 평문은 발급 응답에 한 번만 실리므로 그 자리에서 복사해 보관해야 합니다.
이름에 「인사책」 이 들어가면 인사책 알림 전용 이름이라 400 으로 거절됩니다.

6단계 읽기와 쓰기를 호출합니다

모든 호출에 헤더 「Authorization: Bearer 봇 토큰」 (또는 「X-Bot-Token」) 을 붙입니다.
가상의 값으로 호출 모양만 봅니다.

GET  /api/bot/channels
GET  /api/bot/channels/56/messages?limit=20&before=1200
POST /api/bot/channels/56/messages
     {"text":"일일 리포트 준비됨","client_msg_id":"report:2026-10-21"}
POST /api/bot/channels/56/files      (multipart, 필드 이름 file)

읽기는 limit 이 기본 20,
최대 100 이고 「before」(이 번호보다 앞의 글) 로 앞쪽으로만 넘길 수 있으며,
응답의 글마다 작성자 번호·이름·봇 여부(is_bot)가 실립니다.
「이후」 조건은 없어서 새 글만 받으려면 최근 글을 읽어 글 번호로 이미 처리한 것을 걸러야 합니다.
쓰기는 「text」 또는 「file_ids」 중 하나가 필요하고,
파일 먼저 올린 뒤 받은 file_id 를 글에 붙이는 두 단계 방식과,
파일 호출에 「comment」 를 함께 보내 한 번에 올리는 방식이 모두 됩니다.
봇 API 로 쓴 글은 채널 구성원 중 알림을 「전체 메시지」 로 둔 사람에게 알림이 갑니다(「@멘션만」·음소거는 제외).

7단계 점검과 폐기

웹훅 목록에는 만든 시각과 마지막 사용 시각이,
봇 목록에는 읽기 범위·권한과 마지막 사용 시각이 표시됩니다.
웹훅은 삭제하면 외부 연동이 즉시 멈추고,
봇은 폐기하면 행을 지우지 않고 폐기 시각만 기록합니다.
만들기·수정·삭제·폐기는 워크스페이스 관리 기록(감사 로그)에 남으며,
대화 내용과 토큰 원문은 기록하지 않습니다.

이벤트·필드·인증 한눈에

명령·권한·응답 한눈에

AI 비서(MCP) 길은 봇 토큰과 다릅니다.
로그인한 직원 본인의 권한으로 그 직원이 든 방만 읽고,
읽어도 읽음 처리가 되지 않으며,
보내기는 받는 방과 본문 미리보기를 확인한 뒤에만 나갑니다.
한 번에 본문 8,000자·첨부 3개·합계 5MB 까지 보낼 수 있고 읽을 때 글 하나는 2,000자까지 보입니다.
연결 방법은 MCP 연동 문서 와 사장님 AI 인사책 MCP 연결 가이드 에 있습니다.

오류 응답 읽는 법

개수·호출 한도·요금

• 메신저 저장 용량은 회사 합계 10GB 이고,
  웹훅과 봇 API 로 올린 파일도 여기에 들어갑니다.
• 인사책은 인원 제한 없는 무료 플랜이고 모든 기능을 씁니다.
  같은 무료 플랜 안에서 웹훅과 봇 토큰을 만들 수 있습니다.
• 무료 플랜은 과거 기록 조회 기간·내보내기·AI 연결(MCP) 호출 등 일부 사용량에서 유료 플랜과 차이가 있을 수 있어요
• 웹훅·봇 토큰의 개수 상한과,
  웹훅·봇 API 호출 횟수 상한은 이 글이 읽은 구현에서 찾지 못했습니다.
  상한이 없다는 뜻이 아니라 공개 수치가 없다는 뜻이므로,
  초당 수십 건 이상을 보낼 연동은 도입 전에 시험하세요.
  웹훅·봇 API 에 호출 횟수를 제한하는 코드는 찾지 못했습니다.

비밀키와 유지 책임

• 웹훅 주소는 그 자체가 비밀번호입니다.
  소스 저장소·로그·화면 캡처에 남기지 말고,
  새어 나갔다면 그 웹훅을 삭제하고 새로 만듭니다.
• 봇 토큰은 발급할 때만 보이므로 비밀 저장소에 두고,
  의심되면 폐기 후 재발급합니다.
  읽기 범위는 필요한 채널만 고르고 전체 선택은 피합니다.
• 연동 이름과 종류·구분에 담당 팀과 용도를 적어 두면 목록의 「마지막 사용」 시각과 함께 쓰지 않는 연동을 가려내기 쉽습니다.
• 웹훅은 채널을 삭제하면 함께 지워지지만,
  만든 사람이 퇴사하거나 비활성화될 때 그 사람이 만든 웹훅·봇을 지우는 코드는 찾지 못했습니다.
  퇴사 점검 목록에 연동 확인을 넣으세요.
• 서명 검증이 없으므로 보내는 쪽 IP 제한이나 중계 서버 인증은 고객 쪽에서 둬야 합니다.
  이 글은 메신저 쪽에 IP 허용 목록 기능이 있는지는 확인하지 못했습니다.

인사책이 맞지 않는 경우

아래에 해당하면 인사책 사내 메신저만으로는 요구를 채우지 못하므로 다른 도구를 함께 검토하세요.

• 메신저에서 슬래시 명령이나 메시지 동작으로 사내 시스템을 조회·실행해야 하는 챗옵스 업무: 명령 등록·권한 검사·응답 기능이 구현에 없으므로 명령 기능을 공식 문서로 공개한 도구(예: Dooray!,
  Mattermost)를 권한·감사까지 시험해 비교하세요.
  Slack 은 이 글의 출처로 슬래시 명령 여부를 확인하지 못했으니 Slack 공식 문서에서 따로 확인하세요.
• GitHub·Jira 를 설정 화면에서 골라 바로 연결하는 전용 커넥터: 인사책은 「text」 JSON 을 받는 수신 웹훅뿐이므로,
  중간 단계를 둘 수 없다면 해당 앱을 공식 설명에 명시한 도구(예: 잔디 커넥트)를 함께 보세요.
• 메신저 글이 외부 시스템을 자동으로 호출하는 발신 웹훅,
  서명 검증이 필요한 웹훅,
  이벤트 구독 방식의 앱 설치: 구현에 없습니다.
  인사책 메신저의 「AI에이전트 및 앱」 목록 화면은 구현 문서에서 숨김 처리되어 있고 앱 카탈로그도 「연결 예정」 표시뿐이라,
  앱 설치형 연결은 제공하지 않습니다.
• Slack 안에서 출퇴근을 찍거나,
  결재를 승인하거나,
  슬래시 명령으로 휴가를 신청하는 흐름: 인사책의 Slack 연결은 출퇴근 기록을 보내는 단방향이고 결재 알림의 Slack 경로도 없습니다.
• 앱·호출 횟수의 서비스 수준을 문서로 보장받아야 하는 도입: 공개된 수치가 없습니다.
• 연동마다 보낸이를 따로 보여 주는 구성: 웹훅과 봇 API 의 글은 모두 회사 단위 「알림 봇」 이름으로 올라갑니다.
• 연동에 따라붙는 요건: 손님(게스트) 계정·회사 간 공유 채널,
  회사 자체 로그인 서버(SAML·OIDC),
  메신저 자체 로그인의 2단계 인증(메신저 입장은 인사책 로그인 하나입니다),
  메시지 보관 기간 설정,
  관리자의 대화 내보내기,
  자체 서버 설치는 구현에서 찾지 못했습니다.
  외부 정보보호 인증 심사도 아직 받지 않았습니다. 보안 페이지 에서 현재 상태를 확인하세요.

다른 서비스와 비교할 때

순위를 매기지 않고 「이 조건이면 이 후보」 로 정리합니다.
아래 표의 경쟁사 칸은 각 사 공개 문서를 근거로 한 것이며(출처: 각 사 공개 문서,
2026-10-21 확인),
공개 문서에서 확인하지 못한 칸은 「공개 자료로 확인 못 함」 으로 비웠습니다.
확인하지 못한 것을 지원하지 않는다는 뜻으로 읽지 마세요.

조건별로 먼저 볼 후보는 다음과 같습니다.

• GitHub·Jira 를 설정 화면에서 직접 연결하고 싶다면: 잔디 커넥트가 두 서비스를 공식 설명에 명시하므로 먼저 볼 만합니다.
  토큰·실패·중복 운영은 별도 시험이 필요합니다.
• 슬래시 명령이 필수라면: Dooray! 와 Mattermost 는 공식 문서가 슬래시 명령을 설명하므로 조건부 후보입니다.
  Slack 은 이 글의 출처로 확인하지 못했습니다.
  명령이 있는지와 별개로 사용자 권한과 실행 감사를 시험하세요.
• 연동이 많고 자체 개발 인력과 서버 운영 통제가 필요하다면: Mattermost 는 자체 구축을 공식 소개하므로 검토하되 서버 운영 부담을 함께 계산하세요.
  앱 개수 상한은 공개 자료로 확인하지 못했습니다.
• 무료 Slack 에 이미 앱이 10개 가까이 붙어 있다면: 12개 연결은 무료 플랜 한도를 넘습니다.
  Slack 도움말은 결제 플랜으로 올리면 앱 한도가 없어진다고 안내하므로(SL-S05),
  결제 플랜 전환과 연결 정리 중 무엇이 맞는지 먼저 보세요.
• Microsoft 365 를 쓰는 회사라면: Teams 메시지 동작과 Power Automate 조합을 라이선스까지 포함해 검토하세요.
• 알림만 한 곳으로 모으면 되고 출퇴근·휴가·결재와 한 계정으로 묶고 싶다면: 인사책 메신저의 수신 웹훅과 인원 제한 없는 무료 플랜이 맞습니다.

근거와 확인일

이 글의 인사책 기능 설명은 2026-10-21 인사책·메신저 소스 코드와 메신저 구현 문서 기준입니다.
실제 토큰으로 이벤트를 보내거나 서명·중복·실패를 시험해 보지는 않았습니다.
회사가 메신저를 켜고 이용 권한을 발급한 직원에게는 메신저 「인사책 알림」 대화로 결재 요청 · 결재 결과 · 휴가 결과 · 출퇴근 누락 알림이 옵니다.

• 인사책 공개 페이지: 사내 메신저, 그룹웨어, 슬랙 근태관리, 보안, 업데이트 내역, 요금 안내, MCP 연동 문서
• 법령 조문: 이 글은 법령 판단을 담지 않습니다.
• Slack 무료 플랜 한도: https://slack.com/help/articles/115002422943-Usage-limits-for-free-workspaces (SL-S05,
  2026-10-21 확인)
• Slack 워크플로 빌더: https://slack.com/help/articles/360035692513-Guide-to-Slack-Workflow-Builder (SL-S08,
  2026-10-21 확인)
• Microsoft Teams 메시지에서 클라우드 흐름 시작: https://learn.microsoft.com/en-us/power-automate/trigger-flow-teams-message (SL-S16,
  2026-10-21 확인)
• Teams 요금: https://www.microsoft.com/ko-kr/microsoft-teams/compare-microsoft-teams-business-options (SL-S11,
  2026-10-21 확인)
• 잔디 커넥트: https://support.jandi.com/ko/articles/d63050dd (SL-S22,
  2026-10-21 확인)
• 잔디 요금안내: https://www.jandi.com/landing/kr/pricing (SL-S23,
  본문 추출 불가로 금액 미확정)
• Dooray! 메신저: https://dooray.com/main/service/messenger/ (SL-S24,
  2026-10-21 확인)
• Dooray! 요금안내: https://dooray.com/main/pricing/ (SL-S25,
  2026-10-21 확인)
• Mattermost 제품 소개: https://mattermost.com/platform/secure-messaging-and-collaboration/ (SL-S26,
  2026-10-21 확인)
• Mattermost 에디션·플랜: https://docs.mattermost.com/product-overview/editions-and-offerings (SL-S27),
  https://docs.mattermost.com/product-overview/plans (SL-S28),
  2026-10-21 확인