입사 첫 주, 같은 사무실에 명함이 세 종류입니다.
옆자리 김 책임은 "○○금융 차세대 구축 PM"입니다. 1년 뒤 시스템을 오픈하고 떠납니다. 그 뒤 자리를 지키는 박 선임은 "○○금융 운영 담당"이라 매일 장애 티켓을 받습니다. 회의에 들어온 외부 업체 이 과장은 "저희가 클라우드 운영대행을 맡고 있습니다"라고 합니다. 그리고 발주사 정 차장은 "우리는 그냥 구독해서 쓰는 메일 서비스도 있고, 직접 깔아 쓰는 그룹웨어도 있어요"라고 말합니다.
같은 'IT 일'인데 부르는 이름이 다 다릅니다 — SI, SM, MSP, SaaS, 온프레미스. 게다가 정 차장(발주사)이 김 책임(원청 SI)에게 맡기고, 김 책임은 다시 옆 건물 협력사에 일을 내리고 있습니다. 명함의 회사와 실제 일하는 사람이 다릅니다.
이 다단계 구조와 일하는 방식의 이름을 모르면, "이 일은 누가 책임지고 누구에게 말해야 하는가"를 영영 헷갈립니다. 이 모듈은 한국 IT 산업이 일을 나눠 갖는 방식을 직무 관점에서 정리합니다.
- 1SI·SM·SaaS·온프레미스·MSP의 정의와 차이를 자기 말로 구분해 설명할 수 있다
- 2"만들고 떠나는 SI"와 "남아서 돌보는 SM"의 계약·과금·책임 차이를 말할 수 있다
- 3발주사 → 원청 SI → 하도급(개발·운영·솔루션·인프라) → 실담당자로 이어지는 다단계 구조와, 각 위치의 역할·책임·돈 흐름을 그릴 수 있다
- 4특정 신고/업무가 어느 일하는 방식(SI/SM/MSP/SaaS)에 속하는지 판단할 수 있다
- 5내 직무(기술지원·서비스운영·PMO 보조·고객 커뮤니케이션)가 이 구조의 어디에 가까운지 지도 위에 찍을 수 있다
일하는 방식 다섯 가지 — SI · SM · SaaS · 온프레미스 · MSP
같은 IT라도 '만드는 일'과 '돌보는 일'은 다른 직무다
신입이 가장 먼저 헷갈리는 건 "다 같은 IT인데 왜 이름이 이렇게 많지?"입니다. 이유는 단순합니다. 누가 만들고, 누가 운영하고, 누구 환경에서 도느냐가 다르면 계약·책임·돈의 흐름이 통째로 달라지기 때문입니다. 그래서 산업이 각각에 이름을 붙였습니다.
다섯 가지를 한 줄씩 잡으면:
- SI(System Integration, 신규 구축) — 없던 시스템을 새로 만들어 넘기는 프로젝트. 시작과 끝(오픈·검수)이 있습니다. "○○ 차세대 구축", "주문 시스템 신규 개발"이 SI입니다.
- SM(System Management, 운영·유지보수) — 이미 사는 시스템을 매일 받아 돌보는 계속 계약. 장애 처리·요청 처리·패치·모니터링. 끝나는 날이 없고 계약 기간 동안 계속됩니다.
- SaaS(Software as a Service, 클라우드 서비스) — 공급사가 클라우드에서 소프트웨어를 돌리고, 고객은 구독료를 내고 접속만 합니다. 설치·운영·인프라는 공급사 책임. 사내 메일을 외부 메일 서비스 구독으로 쓰는 게 SaaS입니다.
- 온프레미스(On-Premise, 설치형) — 소프트웨어를 고객사 자체 환경(자체 서버·데이터센터)에 설치해 씁니다. 패치·백업·확장 책임이 고객(또는 그 SM 협력사)에게 있습니다. SaaS의 반대편입니다.
- MSP(Managed Service Provider, 운영대행) — 고객의 클라우드 계정·인프라를 대신 운영해 주는 회사·계약. AWS/네이버클라우드 계정을 고객 대신 설계·운영·비용관리. SM이 '시스템'을 돌본다면 MSP는 주로 '클라우드 인프라'를 돌봅니다.
핵심 감각: SI는 만들고 떠나고, SM은 남아서 돌보고, MSP는 클라우드를 대신 돌보고, SaaS·온프레미스는 "어디서 돌고 누가 인프라를 책임지느냐"의 두 축입니다.
다섯 가지 비교표 — 책임이 어디에 있는가로 읽는다
표로 묶으면 차이가 한눈에 들어옵니다. 읽는 법: 가장 중요한 칸은 **"누가 인프라·운영을 책임지나"**입니다. 이 칸이 계약과 돈의 무게중심을 결정합니다.
| 구분 | 한 줄 정의 | 계약 성격 | 누가 운영·인프라를 책임지나 | 끝나는 날 | 대표 예 |
|---|---|---|---|---|---|
| SI (신규 구축) | 없던 시스템을 새로 만들어 넘김 | 프로젝트(도급) | 구축 중엔 원청 SI, 오픈 후엔 고객/SM에 이관 | 있음(오픈·검수) | 차세대 시스템 구축 |
| SM (운영·유지보수) | 사는 시스템을 매일 받아 돌봄 | 계속(운영) 계약 | 운영 협력사(SM 업체) | 없음(기간 갱신) | 그룹웨어 운영, 장애 대응 |
| SaaS (클라우드 서비스) | 공급사가 돌리고 고객은 구독·접속 | 구독 | 공급사(서비스 제공자) | 없음(구독 유지) | 외부 메일·협업툴 구독 |
| 온프레미스 (설치형) | 고객 자체 환경에 설치해 사용 | 라이선스+구축/SM | 고객사(또는 SM 협력사) | 설치는 끝, 운영은 계속 | 사내 데이터센터 그룹웨어 |
| MSP (운영대행) | 고객 클라우드를 대신 운영 | 운영대행 계약 | MSP 사업자 | 없음(기간 갱신) | AWS/NCP 계정 대행 운영 |
표를 한 문장으로: "이 일은 만드는 일인가(SI) 돌보는 일인가(SM·MSP), 그리고 인프라는 고객 것인가(온프레미스) 공급사 것인가(SaaS)" — 이 두 질문이면 다섯 가지가 정리됩니다.
그림: 만드느냐 돌보느냐, 그리고 인프라가 누구 것이냐 두 축으로 다섯 가지 방식을 가른다.
한국 IT 다단계 구조 — 일은 아래로, 돈과 책임은 위로
발주사 → 원청 SI → 하도급 → 실담당자
한국 IT를 처음 겪는 사람이 가장 당황하는 지점은 **"명함의 회사와 실제 일하는 사람이 다르다"**는 것입니다. 이유는 산업이 다단계 도급 구조로 돌아가기 때문입니다. 일은 위에서 아래로 내려가고, 돈과 책임은 아래에서 위로 모입니다.
위에서 아래로 단계를 펼치면(들여쓰기가 곧 위계입니다):
- 발주사 / 고객사 — 돈을 내고 시스템을 의뢰하는 주체. 은행·공공기관·대기업 등. "이런 시스템이 필요하다"를 정의하고 예산을 집행합니다.
- 원청 SI (또는 그룹사 IT 자회사) — 발주사와 직접 계약하고 **전체 책임(납기·품질·SLA·하자보수)**을 지는 회사. 대형 SI 기업이나, 대기업이라면 그룹 내 IT 자회사가 이 자리를 맡습니다. 직접 다 만들지 않고 일을 쪼개 아래로 재위탁합니다.
- 하도급 — 개발사 — 실제 애플리케이션 코드를 짜는 협력사. 화면·기능·API를 구현합니다.
- 하도급 — 운영사(SM) — 오픈 후 시스템을 받아 장애·요청을 처리하는 협력사.
- 하도급 — 솔루션사(벤더) — DBMS·미들웨어·보안·모니터링 같은 제품을 납품·설치·기술지원하는 회사.
- 하도급 — 인프라사 — 서버·네트워크·클라우드·OS 구축과 운영을 담당하는 협력사.
- 실제 담당자 — 위 협력사 소속으로 현장에서 손을 움직이는 엔지니어·운영자. 명함은 협력사지만 일하는 곳은 발주사 사무실인 경우가 많습니다(상주).
- 원청 SI (또는 그룹사 IT 자회사) — 발주사와 직접 계약하고 **전체 책임(납기·품질·SLA·하자보수)**을 지는 회사. 대형 SI 기업이나, 대기업이라면 그룹 내 IT 자회사가 이 자리를 맡습니다. 직접 다 만들지 않고 일을 쪼개 아래로 재위탁합니다.
읽는 법: 계약선은 한 단계씩만 연결됩니다. 발주사는 원청과, 원청은 각 하도급과 계약합니다. 그래서 발주사가 화가 나도 협력사 엔지니어에게 직접 따지지 않고 원청에게 말하고, 원청이 다시 협력사에 전달합니다. 이 '한 단계 건너 소통'이 한국 SI의 특징이자 답답함의 원인입니다.
그림: 일은 아래로, 돈과 책임은 위로 — 계약선은 한 단계씩만 이어진다.
각 위치의 역할·책임·돈 흐름
같은 프로젝트 안에서도 위치마다 보는 것·책임지는 것·받는 돈의 성격이 다릅니다. 이 표가 이 모듈의 핵심 산출물입니다.
| 위치 | 핵심 역할 | 책임지는 것 | 돈의 흐름 | 자주 쓰는 말 |
|---|---|---|---|---|
| 발주사 / 고객사 | 요구사항 정의·예산 집행·검수 | 사업 목적 달성, 예산 | 돈을 '내는' 쪽(원청에 지급) | "이거 언제 됩니까", "검수 못 합니다" |
| 원청 SI / 그룹사 IT | 전체 사업관리·하도급 관리·발주사 대응 | 납기·품질·SLA·하자보수 전체 | 발주사에게 받고 하도급에 지급(마진) | "범위 밖입니다", "협력사 조율하겠습니다" |
| 하도급 — 개발사 | 기능·화면·API 구현 | 맡은 개발 범위의 품질·납기 | 원청에서 받음(인력·기능 단위) | "스펙대로 했습니다", "추가 요건이네요" |
| 하도급 — 운영사(SM) | 장애·요청 처리, 모니터링, 월간보고 | 합의된 SLA(가용성·응답시간) | 원청/발주사에서 운영비로 받음 | "P1 발생", "이번 달 가용성 99.9%" |
| 하도급 — 솔루션사 | 제품 납품·설치·기술지원 | 자사 제품의 동작·패치 | 라이선스+유지보수료 | "벤더 케이스 열겠습니다" |
| 하도급 — 인프라사 | 서버·네트워크·클라우드 구축·운영 | 인프라 가용성·성능·보안 | 구축비+운영비 | "증설 리드타임 2주", "방화벽 정책 필요" |
| 실제 담당자 | 현장 작업·1차 대응 | 맡은 작업의 실행 | 소속 협력사가 급여 지급 | "지금 보고 있습니다", "원청에 보고했습니다" |
돈 흐름을 한 줄로: 발주사 → 원청(마진 떼고) → 하도급 → 담당자 급여. 위로 갈수록 책임·마진이 크고, 아래로 갈수록 실제 작업이 많아집니다. 이 비대칭을 알면 "왜 협력사가 추가 요건에 예민한가", "왜 원청은 범위를 그렇게 따지는가"가 보입니다 — 각자 자기 위치의 돈·책임을 지키는 것입니다.
직접 해보기 — 업무를 구조 위에 배치하기
아래 5개 상황을 (1) 일하는 방식(SI/SM/SaaS/온프레미스/MSP)으로 분류하고, (2) 등장인물이 다단계 구조의 어느 위치(발주사·원청·하도급·담당자)에 있는지 적어 보세요. 정답은 ObserveBlock에 있습니다.
A. ○○공단이 새 민원시스템을 만들기로 하고, 대형 IT 기업과 1년 계약을 맺었다. 그 기업은 화면 개발을 다시 작은 협력사에 맡겼다.
B. 그 협력사 소속 박 씨는 공단 사무실에 상주하며 매일 화면을 개발한다.
C. 시스템 오픈 6개월 뒤, 다른 업체가 장애 티켓을 받고 매월 가용성 보고서를 낸다.
D. 회사는 메일을 직접 설치·운영하지 않고, 월 사용자당 요금을 내는 외부 메일 서비스로 바꿨다.
E. 스타트업이 자기 AWS를 직접 다룰 인력이 없어, 클라우드 전문 업체에 계정 설계·운영·비용관리를 맡겼다.
판단 직관: 만드는가/돌보는가(SI vs SM·MSP), 누구 인프라인가(온프레미스 vs SaaS), 계약선이 한 단계씩 내려가는가(원청→하도급)를 차례로 물어보세요.
분류: SI / SM / SaaS / 온프레미스 / MSP + 위치- A = SI(신규 구축). ○○공단 = 발주사, 대형 IT 기업 = 원청 SI, 작은 협력사 = 하도급(개발사). 계약은 발주사–원청, 원청–협력사로 한 단계씩.
- B = 박 씨는 하도급(개발사) 소속 "실제 담당자". 일하는 곳은 발주사 사무실(상주)이지만 급여는 협력사가 지급, 발주사와 직접 계약 아님.
- C = SM(운영·유지보수). 오픈 후 운영사가 SLA(가용성)에 따라 장애·보고를 책임지는 계속 계약. SI에서 SM으로 넘어간 전형적 흐름.
- D = SaaS. 설치·운영을 공급사가 하고 고객은 구독·접속만. 온프레미스(직접 설치)에서 SaaS로 전환한 사례.
- E = MSP(운영대행). 고객 클라우드 계정을 전문 업체가 대신 설계·운영·비용관리. SM과 비슷하나 대상이 "클라우드 인프라"라는 점이 다름.
- 핵심 감각: 같은 "IT 업무"라도 (1)만드냐 돌보냐, (2)누구 인프라냐, (3)계약선이 어디까지 내려가냐를 물으면 방식과 위치가 동시에 잡힌다.
현장에서 자주 보는 함정
증상: 발주사나 원청 쪽 신입이 급한 마음에 옆자리 협력사 엔지니어에게 직접 "이것 좀 바꿔 주세요"라고 지시합니다. 그런데 (1) 그 엔지니어가 난색을 표하거나, (2) 며칠 뒤 "그건 계약 범위 밖이라 원청에 정식 요청해야 한다"는 답이 돌아오고, (3) 원청은 "추가 비용·일정 협의 대상"이라며 멈춥니다.
원인: 다단계 도급의 계약선을 건너뛰었기 때문입니다. 협력사 엔지니어는 자기 회사가 원청과 맺은 범위 안에서만 일합니다. 범위 밖 요청은 곧 추가 공수이고, 추가 공수는 추가 계약입니다. 또 직접 지시는 '도급'이 아니라 '파견·지휘'로 해석돼 법적 문제(위장도급)가 될 수도 있어, 현장은 의도적으로 직접 지시를 피합니다.
해결 방향(이 트랙에서 깊어짐):
- 요청은 계약선을 따라 한 단계씩 — 협력사에 직접이 아니라 원청 창구(또는 PM/PMO)를 통해 정식으로 전달.
- "이게 기존 범위인가, 추가 요건인가"를 먼저 가른다 — 범위 안이면 절차로, 밖이면 **변경(추가 계약·일정 협의)**으로.
- 무엇을 누구에게 요청했는지 티켓·문서로 기록 — 구두 지시는 책임 소재가 사라지고 위장도급 리스크를 키운다.
- 급할수록 "누가 책임지는 자리인가"(원청)에게 말한다 — 작업자에게 직접 매달리지 않는다.
다단계 구조는 답답해 보이지만, 책임과 비용을 명확히 가르기 위한 장치입니다. 구조를 우회하지 말고 구조를 '타고' 일하는 것이 빠릅니다.
이 트랙이 향하는 직무를 이 구조 위에 찍어 보면, 당신의 자리는 대개 **발주사 IT 또는 원청 SI 쪽의 '운영·관리 접점'**입니다 — 직접 코드를 짜는 하도급 개발자가 아니라, 운영 중인 서비스의 장애·요청을 받아 처리하고(서비스운영/SM), 협력사 일정과 진행을 챙기며(PMO 보조), 발주사에 진행을 보고하는(고객 커뮤니케이션) 일이 섞인 자리입니다.
구체적으로 당신은 기술지원 + 서비스운영 + PMO 보조 + 고객 커뮤니케이션의 교차점에 섭니다. 협력사 엔지니어가 실제 손을 움직이더라도, "이 신고는 무엇이고, 어느 협력사가, 언제까지, 어떤 절차로 처리하며, 그 결과를 발주사에 어떻게 보고하는가"를 조율·통제하는 것이 당신의 몫입니다. 그래서 SI/SM/MSP/SaaS의 차이와 다단계 구조를 모르면, "이 책임은 누구 것이고 누구에게 말해야 하는가"에서 매번 헤맵니다.
기술을 아는 관리·운영 담당자는 협력사와 대등하게 대화하고, "범위 밖입니다"라는 말이 진짜인지 협상 카드인지 가릴 수 있으며, 발주사에는 산출물("했습니다")이 아니라 결과("이렇게 안정화됐습니다")로 보고합니다. 이 구조 감각이 그 출발점입니다.
다음 모듈에서는 이 구조 안에서 한 프로젝트가 실제로 굴러갈 때 등장하는 프로젝트 역할(PM/PL/PMO/SE/TA/AA/DBA)이 각각 무엇을 책임지고 어떻게 협업하는지를 정리합니다.
관련 모듈로 더 깊이:
- 프로젝트 역할 — 이 구조 안에서 PM·PL·PMO·SE 등 누가 무엇을 책임지는지
- SI 프로젝트 생애주기 — 구축(SI)이 제안부터 오픈·안정화까지 어떤 단계로 흐르는지
- SM 운영·유지보수·하자보수 — 구축이 끝난 뒤 운영(SM)으로 넘어가 시스템이 어떻게 유지되는지
다음 모듈에서는 이 구조 안에서 한 프로젝트가 실제로 굴러갈 때 등장하는 프로젝트 역할(PM/PL/PMO/SE/TA/AA/DBA)이 각각 무엇을 책임지고 어떻게 협업하는지를 직무 관점에서 정리합니다.