신입 운영자 두 명이 같은 회사에 들어왔습니다.
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) 규칙의 부재가 문제입니다.
해결 방향(이 트랙에서 깊어짐):
- 일의 종류별로 정식 그릇을 하나씩 못 박는다 — 티켓은 여기, 지식은 여기, 대화는 여기.
- 메신저는 빠른 소통용이되 결론·조치는 반드시 티켓/문서로 되돌려 적는다(흘러가지 않게).
- 같은 내용을 두 곳에 적지 않는다 — 한 곳을 정본으로 정하고 나머지는 링크로 가리킨다.
- 도구를 더 사기 전에 **"우리 일의 흐름과 그 흐름이 어느 그릇에 담기는가"**를 먼저 그린다.
도구가 부족해서 어지러운 경우보다, 규칙 없이 도구만 많아서 어지러운 경우가 현장엔 더 흔합니다.
관리 직무에서 당신은 직접 도구를 깊게 다루는 '파워 유저'가 되기보다, "우리 조직의 일이 어떤 도구 조합에 담기는가"를 설계하고 통제하는 사람에 가깝습니다.
한국 기업의 도구 지형은 조직 규모·업종·예산에 따라 다양하지만, 대체로 이런 경향이 관찰됩니다(절대적 규칙이 아니라 일반적 그림입니다).
- 대기업·금융·공공은 감사·승인·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·메신저 실습 — 현실 도구로 관리대장·대시보드·경영보고·알림 체계 만들기
다음 모듈에서는 이 지형 위에서 AI를 IT PM·운영의 도구로 활용하는 법 — 회의록·문서·일정·장애 대응 보조와 n8n·Claude 자동화 — 으로 넘어갑니다.