신입 운영자 두 명이 같은 회사에 들어왔습니다.
C는 첫 주에 "우리 회사는 무슨 도구 써요?"라고 묻고, "ServiceNow랑 Jira랑 Confluence랑 Slack 써요"라는 답을 듣습니다. C는 네 개를 다 외웠지만, 어떤 일이 들어오면 어디를 열어야 하는지는 모릅니다. 고객 장애 전화를 받고 Confluence에 적었다가 "그건 ServiceNow에 티켓 끊으세요"라는 지적을 받습니다.
D는 같은 답을 듣고 한 칸 더 묻습니다. "그럼 고객 장애는 어디에, 우리가 만드는 개발 과제는 어디에, 절차서는 어디에 적나요?" D는 도구 이름이 아니라 일의 종류와 도구의 짝을 먼저 잡았습니다. 그래서 장애 전화엔 티켓을, 개발 과제엔 이슈를, 절차서엔 위키 페이지를 엽니다.
도구를 많이 아는 것보다, 이 일에는 이 그릇이라는 지도를 갖는 게 먼저입니다. 이 모듈은 그 지도를 그립니다.
- 1ITSM·이슈관리·지식문서·커뮤니케이션·범용오피스라는 도구 "범주"와 각 범주의 대표 제품을 구분할 수 있다
- 2ServiceNow·Jira·Jira Service Management·Confluence·Redmine·Notion·Slack·Teams·Excel이 각각 무엇을 위한 도구인지 한 줄로 설명할 수 있다
- 3"이 일에는 어떤 도구"인지를 일의 종류(장애·요청·개발과제·절차서·소통·보고)에 맞게 매핑할 수 있다
- 4도구는 프로세스를 담는 그릇이라는 원칙과, 도구 도입이 프로세스 설계와 함께 가야 하는 이유를 설명할 수 있다
- 5한국 기업에서 이 도구들이 어떻게 조합되어 쓰이는 경향이 있는지 일반적 그림을 그릴 수 있다
도구를 '범주'로 먼저 본다
제품 이름이 아니라 '무엇을 위한 그릇인가'로 묶는다
도구를 처음 접하면 제품 이름의 홍수에 빠지기 쉽습니다. ServiceNow, Jira, Confluence, Redmine, Notion, Slack, Teams, Freshservice… 이름을 외우는 대신, **"이건 무엇을 담는 그릇인가"**로 묶으면 지형이 단순해집니다.
크게 다섯 범주로 나뉩니다.
- ITSM 티켓(서비스데스크) — 들어온 장애·요청·변경을 우선순위·SLA·승인과 함께 접수하고 추적하는 그릇.
- 이슈·프로젝트 관리 — 우리가 만드는 일(개발 과제·작업)을 이슈로 쪼개 진행을 추적하는 그릇.
- 지식·문서 — 절차서·정책·런북처럼 두고두고 찾아볼 지식을 쌓는 그릇.
- 커뮤니케이션 — 처리 과정에서 사람끼리 실시간으로 소통하는 그릇.
- 범용 오피스 — 보고서·표·발표자료 같은 산출물을 만드는 그릇.
| 범주 | 무엇을 담나(용도) | 대표 제품 |
|---|---|---|
| ITSM 티켓 | 장애·요청·변경 티켓, SLA·승인·에스컬레이션 | ServiceNow, Jira Service Management, BMC Helix, Freshservice |
| 이슈·프로젝트 | 개발 과제·작업을 이슈로, 스프린트·보드로 추적 | Jira, Redmine |
| 지식·문서 | 절차서·정책·런북·회의록 등 재사용 지식 | Confluence, Notion |
| 커뮤니케이션 | 실시간 대화·알림·화상회의 | Slack, Microsoft Teams |
| 범용 오피스 | 보고서·집계표·발표자료 | Excel, PowerPoint, Word |
표를 외우려 하지 말고 **"왼쪽 열(범주)이 곧 일의 종류"**라고 읽으세요. 일이 들어오면 그 일이 어느 범주인지부터 정하면, 어떤 제품을 열지는 자연히 따라옵니다.
확대
그림: 도구는 제품 이름이 아니라 '무엇을 담는 그릇인가'로 5범주로 묶는다 — 왼쪽 열이 곧 일의 종류.
헷갈리기 쉬운 짝 — Jira vs JSM, 티켓 vs 지식
같은 회사 제품도 쓰임새가 다르다
도구 지형에서 초보가 가장 많이 헷갈리는 두 지점이 있습니다.
Jira vs Jira Service Management(JSM) — 둘 다 같은 회사(Atlassian) 제품이고 이름도 비슷하지만 향하는 일이 다릅니다.
- Jira는 우리 팀이 안에서 만드는 일을 다룹니다. 기능 개발 과제를 스토리·태스크·버그로 쪼개고, 스프린트와 보드로 진행을 봅니다. 사용자는 보통 내부 개발자·팀원입니다.
- JSM은 밖에서 들어온 요청·장애를 다룹니다. 고객/사내 사용자가 포털로 장애를 신고하고, SLA·승인·에스컬레이션을 걸어 처리합니다. 사용자는 서비스를 받는 쪽입니다.
티켓 vs 지식 — 이것도 자주 섞입니다.
- 티켓 도구(ServiceNow·JSM)는 "이 한 건을 언제 누가 어떻게 처리했는가"라는 이력에 강합니다. 한 번 닫힌 티켓은 흘러가는 기록입니다.
- 지식 도구(Confluence·Notion)는 "이런 상황엔 이렇게 처리한다"라는 재사용 지식에 강합니다. 한 번 잘 쓴 절차서는 백 번 다시 읽힙니다.
좋은 운영은 둘을 나눠 씁니다 — 처리 이력은 티켓에, 처리 방법은 지식 베이스에. 티켓에 절차 전체를 길게 적으면 다음 사람이 못 찾고, 지식 문서에 개별 장애 이력을 쌓으면 지저분해집니다.
확대
그림: Jira vs JSM(만드는 일 vs 들어온 요청), 티켓 vs 지식(처리 이력 vs 재사용 방법) — 이름은 비슷해도 향하는 일이 다르다.
도구는 프로세스를 담는 그릇
그릇을 바꿔도 담을 게 없으면 빈 그릇이다
가장 흔한 오해는 **"좋은 도구를 도입하면 운영이 정리된다"**입니다. 순서가 거꾸로입니다.
도구는 일하는 방식(프로세스)을 담는 그릇입니다. 인시던트를 어떻게 분류하는지, 우선순위는 무엇으로 정하는지, 변경은 누가 승인하는지 — 이 흐름이 먼저 정의되어 있어야 도구가 그것을 자동화하고 강제하고 기록해 줍니다. 흐름이 없으면 ServiceNow 같은 강력한 도구를 깔아도 빈 칸만 늘어난 '비싼 빈 그릇'이 됩니다.
그래서 현장에서는 도구를 이렇게 봅니다.
- 도구 도입은 프로세스 설계와 함께 간다. "무슨 도구 살까"보다 "우리 인시던트·변경 흐름이 뭔가"가 먼저.
- 작은 조직은 Excel·Notion 같은 가벼운 그릇으로도 충분히 시작할 수 있다. 흐름이 단순하면 그릇도 단순해도 된다.
- 조직이 커지고 SLA·감사·승인 요건이 늘면 전용 ITSM 도구의 가치가 커진다. 그릇이 흐름을 못 따라갈 때가 교체 시점.
도구 비교표를 들고 "어느 게 1등이냐"를 다투는 대신, **"우리 일의 흐름에 맞는 그릇이냐"**를 묻는 사람이 좋은 관리자입니다.
직접 해보기 — 들어온 일을 그릇에 담기
아래 6건이 들어왔다고 합시다. 각각 어느 도구 범주가 1차로 맞는지, 그리고 대표 제품 하나를 적어 보세요. 정답은 ObserveBlock에 있습니다.
A. 고객사에서 "결제가 안 됩니다" 장애 신고가 포털로 접수됨
B. 개발팀이 "다음 스프린트에 쿠폰 기능을 만든다"를 과제로 등록하려 함
C. "결제 서버 재기동 절차서"를 팀이 두고두고 찾아볼 수 있게 정리
D. 장애 대응 중 "DB 담당자님 지금 통화 가능?"을 빠르게 묻고 싶음
E. 이번 달 인시던트 건수·평균 처리시간을 경영진 보고용 표로 집계
F. 다음 주 결제 모듈 변경에 대한 승인과 그 기록을 남겨야 함
매핑 직관: **"이 일의 결과물이 무엇으로 남아야 하는가"**를 생각하세요. 추적되는 티켓인지, 진행되는 이슈인지, 찾아볼 지식인지, 흘러갈 대화인지, 제출할 산출물인지.
매핑: ITSM티켓 / 이슈·프로젝트 / 지식·문서 / 커뮤니케이션 / 범용오피스- A = ITSM 티켓 (예: ServiceNow / JSM). 외부 장애를 SLA·우선순위와 함께 접수·추적
- B = 이슈·프로젝트 (예: Jira). 내부 개발 과제를 이슈·스프린트로 — 같은 Jira여도 JSM이 아니라 Jira 쪽
- C = 지식·문서 (예: Confluence·Notion). 재사용·검색이 핵심이므로 위키에
- D = 커뮤니케이션 (예: Slack·Teams). 다만 결론·조치는 반드시 티켓/문서에 다시 남긴다
- E = 범용 오피스 (예: Excel). 집계·보고용 표 — 단 원천 데이터는 티켓 도구의 통계에서 뽑는 게 정확
- F = ITSM 티켓의 변경관리 (예: ServiceNow 변경 모듈). 승인·감사 추적이 필요하므로 메신저나 메일이 아니라 티켓으로
- 핵심 감각: 같은 "일"처럼 보여도 결과물의 성격(이력·진행·지식·대화·산출물)에 따라 그릇이 다르다
현장에서 자주 보는 함정
증상: ServiceNow·Jira·Confluence·Slack을 다 쓰는데도 운영이 더 깔끔해지지 않습니다. 장애 내용은 Slack에 흘러가 사라지고, 절차서는 누군가의 개인 Notion에 있고, 같은 인시던트를 엑셀에도 따로 적고 있습니다. "어디 보면 되냐"는 질문에 아무도 한 곳을 못 댑니다.
원인: 도구를 도입했지만 **"무엇을 어디에 둔다"는 규칙(프로세스)**을 정하지 않았습니다. 그릇은 많은데 무엇을 어느 그릇에 담을지가 합의되지 않아서, 정보가 중복되고 흩어집니다. 도구 수가 아니라 단일 출처(Single Source of Truth) 규칙의 부재가 문제입니다.
해결 방향(이 트랙에서 깊어짐):
- 일의 종류별로 정식 그릇을 하나씩 못 박는다 — 티켓은 여기, 지식은 여기, 대화는 여기.
- 메신저는 빠른 소통용이되 결론·조치는 반드시 티켓/문서로 되돌려 적는다(흘러가지 않게).
- 같은 내용을 두 곳에 적지 않는다 — 한 곳을 정본으로 정하고 나머지는 링크로 가리킨다.
- 도구를 더 사기 전에 **"우리 일의 흐름과 그 흐름이 어느 그릇에 담기는가"**를 먼저 그린다.
도구가 부족해서 어지러운 경우보다, 규칙 없이 도구만 많아서 어지러운 경우가 현장엔 더 흔합니다.
심화 — 도구 선택은 기술 결정만이 아니다
심화: 도입의 조직 정치, 라이선스의 함정, 데이터 주권
"어느 그릇이 우리 흐름에 맞는가"까지가 이 모듈의 본문이었다면, 실제 도입 현장에는 기능 비교표 바깥의 변수가 세 가지 더 붙습니다. 도구 선정 회의가 길어지는 진짜 이유는 대개 여기에 있습니다.
- 조직 정치: 도구를 정하는 것은 곧 일하는 방식을 정하는 것이라, 부서마다 자기 그릇을 표준으로 밀어붙입니다 — 개발팀은 이미 쓰는 이슈 도구를, 운영팀은 ITSM 전용 도구를, 전사 IT는 기존 오피스 제품군과의 통합을 내세웁니다. 각자의 주장에는 수년치 데이터와 몸에 밴 습관이라는 기득권이 걸려 있습니다. 그래서 도구 통합은 기능 싸움이 아니라 전환 비용(마이그레이션·재교육·저항)을 누가 지불하는가의 협상이고, 이를 중재하는 언어가 앞의 범주 지도입니다 — "네 도구가 나쁘다"가 아니라 "그 그릇은 이 범주의 일에 남기고, 이 범주는 여기로 모으자"가 합의 가능한 문장입니다.
- 라이선스의 함정: 도입가만 보면 안 됩니다. 사용자당 과금은 "열람만 하는 사람"까지 시트를 세는지에 따라 총액이 몇 배가 되고, 처리자(에이전트) 수 기준 과금은 조직이 크면서 뛰어오릅니다. 더 큰 변수는 벤더의 정책 변경입니다 — 온프레미스 라이선스 판매 중단, 클라우드 전환 유도, 구독 단가 인상은 몇 년 주기로 실제 일어나는 일이고, 그때 갈아탈 수 없는 조직은 부르는 값을 냅니다. 도입 심사에서 "들어가는 문"만 보지 말고 **"나가는 문"(데이터를 표준 형식으로 통째로 꺼낼 수 있는가)**을 함께 봐야 하는 이유입니다.
- 데이터 주권: SaaS 도구의 데이터는 벤더가 정한 리전에 저장됩니다. 공공·금융처럼 데이터 소재지 규제가 있는 조직, 고객사 계약에 자료 외부 반출 금지가 박힌 SI 현장에서는 "그 도구가 좋은가" 이전에 **"그 도구에 이 데이터를 담아도 되는가"**가 선결 질문입니다. 티켓과 위키에는 장애 이력·고객 정보·시스템 구성이 그대로 담기므로, 폐쇄망·규제 환경에서는 셀프호스트 옵션의 존재 여부가 기능보다 앞서는 선택 기준이 됩니다.
정리하면, 관리자의 도구 심사표에는 기능·가격 옆에 세 칸이 더 필요합니다 — 누가 저항할 것인가(정치), 5년 뒤에도 나올 수 있는가(라이선스·탈출 비용), 이 데이터를 여기 담아도 되는가(주권).
상황: 이슈 관리와 위키를 한 벤더의 온프레미스 제품으로 수년간 운영해 온 SI 조직. 벤더가 온프레미스 서버 라이선스의 판매·지원 종료를 공지했습니다. 남은 길은 둘 — 벤더 클라우드로 이전하거나, 대규모 조직용 상위 온프레미스 라이선스로 올라가거나. 그런데 고객사 보안 규정상 운영 데이터의 외부(국외 리전) 저장이 금지라 클라우드는 불가했고, 상위 라이선스는 기존 예산의 몇 배였습니다. 지원 종료 시한은 다가오는데 갈 곳이 없었습니다.
원인: 도입 심사가 기능과 도입가만 봤고, 벤더 정책 변경이라는 리스크와 탈출 비용을 평가하지 않았습니다. 데이터 주권 요건(외부 저장 금지)은 고객사 계약서에 있었지만 도구 벤더의 로드맵과 대조된 적이 없었고, "나가는 문" — 데이터를 표준 형식으로 꺼낼 수 있는가 — 은 아무도 확인하지 않았습니다. 수년치 티켓·위키가 벤더 고유 형식 안에 쌓이는 동안, 조직은 자신이 잠기고 있다는 것을 몰랐습니다.
진단: 남은 선택지를 데이터 실사로 좁혔습니다 — 경량 오픈소스 도구로의 이관을 검토하며 실제 내보내기를 시험해 보니, 티켓 본문과 첨부는 옮겨져도 권한 체계·문서 매크로·문서 간 연결은 형식 손실로 깨졌습니다. 이관 공수가 라이선스 인상분과 맞먹는 수준임이 드러났고, 어느 쪽이든 대가를 치러야 하는 상황임이 확정됐습니다.
해결: 단기적으로는 지원 종료 전까지의 유예 기간을 확보하고, 정본 가치가 높은 핵심 위키(절차서·런북)부터 도구 중립 형식으로 정리해 이관했습니다 — 전부를 살리는 대신 구할 것의 우선순위를 정한 것입니다. 재발 방지로 도구 도입 심사에 세 항목을 추가했습니다: 셀프호스트 옵션과 데이터 소재지의 규정 적합성, 표준 형식 전체 내보내기 검증(도입 전 실제 수행), 벤더 라이선스 정책 변경을 가정한 탈출 비용 산정. 도구는 언젠가 바뀐다는 전제로 고르는 것 — 그것이 이 사고가 남긴 심사 기준입니다.
관리 직무에서 당신은 직접 도구를 깊게 다루는 '파워 유저'가 되기보다, "우리 조직의 일이 어떤 도구 조합에 담기는가"를 설계하고 통제하는 사람에 가깝습니다.
한국 기업의 도구 지형은 조직 규모·업종·예산에 따라 다양하지만, 대체로 이런 경향이 관찰됩니다(절대적 규칙이 아니라 일반적 그림입니다).
- 대기업·금융·공공은 감사·승인·SLA 요건이 강해 ServiceNow 같은 전용 ITSM 도구나 국산 ITSM 솔루션을 도입하는 경우가 많습니다.
- 개발 조직은 이슈·스프린트 관리에 Jira를, 지식 정리에 Confluence를 함께 쓰는 조합이 흔하고, 서비스데스크가 필요하면 Jira Service Management로 확장하기도 합니다.
- 중소기업·SI 현장은 무료·경량 도구인 Redmine으로 이슈를 관리하거나, 여전히 Excel로 이슈·진척을 관리하는 곳도 적지 않습니다.
- 협업·소통은 Slack 또는 Microsoft Teams가 폭넓게 쓰이며, 사내 표준이 Microsoft 365 기반이면 Teams로 통일되는 경향이 있습니다.
이때 관리자에게 필요한 건 특정 제품의 단축키 숙련이 아니라, (1) 일의 종류와 그릇의 짝을 안다, (2) 도구가 프로세스를 담는 그릇임을 안다, (3) 정보의 정본(Single Source of Truth)을 한 곳으로 정한다는 판단력입니다. 협력사가 어떤 도구를 쓰자고 제안해도, 당신은 "그 그릇이 우리 흐름을 담는가"를 기준으로 판단할 수 있어야 합니다.
도구는 손으로 익혀야 합니다 — 아래 실습(Lab)에서 직접 구성해 보세요:
- Jira 이슈·스프린트 실습 — 프로젝트·워크플로우 설계부터 백로그·스프린트·JQL·번다운까지 직접 굴리기
- Jira Service Management 실습 — 서비스데스크·요청 유형·우선순위·SLA·변경 승인 구성
- Confluence 지식관리 실습 — 런북·장애사례 템플릿, 라벨·검색·버전·정본 관리
- ServiceNow·Redmine 실습 — 엔터프라이즈 CMDB vs 경량 이슈관리 비교·선택 기준
- Excel·PPT·Notion·메신저 실습 — 현실 도구로 관리대장·대시보드·경영보고·알림 체계 만들기
관련 모듈로 더 깊이:
- 인시던트 관리 — 티켓 도구(ITSM)가 실제로 담는 인시던트 처리 프로세스
- 서비스 데스크 — 도구가 받치는 단일 접점(서비스 데스크)의 운영
- 구성 관리와 CMDB — 구성·자산을 담는 CMDB 도구의 역할과 한계
다음 모듈에서는 이 지형 위에서 AI를 IT PM·운영의 도구로 활용하는 법 — 회의록·문서·일정·장애 대응 보조와 n8n·Claude 자동화 — 으로 넘어갑니다.