기간 : 2021.08 ~ 2024.12
부서 : 통신사업팀
직급 : 사원
직책 : 팀원
저는 열아홉 살에 첫 직장 생활을 시작했어요. 고등학교 취업 연계로 입사했는데, 학교에서는 뉴미디어 소프트웨어과에서 코딩을 배웠던 터라 당연히 개발 업무를 맡게 될 거라 생각했죠. 그런데 막상 배정된 곳은 운영팀이었고, 솔직히 처음엔 정말 막막했어요.
그럼에도 제 커리어를 정리하는 첫 기록으로 운영팀을 고른 이유가 있어요. 저에게 운영팀은 아무것도 모르는 상태에서 어떻게든 버텨낸 자리이자, 지금의 저를 만든 출발점이기 때문이에요.
한 가지는 미리 짚고 넘어가고 싶어요. 운영팀은 회사마다 부르는 이름이 다 달라요. CS팀, 서비스운영팀, 사업운영팀처럼 다양하게 불리지만, 하는 일의 본질은 비슷하다고 생각해요. 저희 회사에서는 통신사업팀이라 불렀고, 이 글에서는 편하게 운영팀이라 부르되 실제로는 통신사업팀에서 겪은 이야기라는 점을 먼저 밝혀둘게요.
운영팀, 시장에서는 이렇게 불러요
개발자 안에도 프론트엔드, 백엔드, SI처럼 세부 직군이 나뉘듯, "운영팀"이라는 이름 하나에도 실제로는 여러 직무가 섞여 있었어요. 3년 반의 업무를 돌아보며, 이 일들이 채용 시장에서 어떤 이름으로 불리는지 하나하나 찾아봤는데, 대부분 실제로 쓰이는 직무명과 맞아떨어지더라고요.
실제로 했던 일 시장에서 부르는 이름 비중
| CS 상담, 서비스 모니터링(관제), 장애 대응 — 팀 전체가 상시로 짊어지는 공통 업무 | CS·CX 운영, 관제 | 25% |
| 해외 상품 API 연동, 신규 상품 연동·번역·테스트, 재고부족/단종 상품 대체 관리 | 상품운영 | 18% |
| 상품 데이터 분석, 노출 우선순위 조정, 환율 대응 | 상품운영 | 10% |
| 거래명세서(선후불) 정산, 인보이스 발행, SMS 사용량 정산 | 정산 담당자 | 9% |
| 고객 이슈를 재현 경로·오류 로그로 번역해 개발팀에 전달 | 기술지원 | 7% |
| 앱 기능 전수 테스트, 매뉴얼화, 이슈 관리 | QA / 품질관리 | 7% |
| WAF·UTM 방화벽 관리, 부정이용 데이터 분석 | 보안관제 | 7% |
| MVNO별 충전 서비스 작업 스케줄링 | 상품운영 | 5% |
| 서버·DB 흐름 파악, 아키텍처 문서화 | 인프라 운영 | 5% |
| 업무 매뉴얼·SOP 정리, 매니저 교육 자료 제작 및 진행 | 운영 기획 (SOP·매뉴얼 작성) | 5% |
| 개발팀·현지 매니저와의 협업 조율 | 서비스 운영 | 2% |
비중(%)은 정확한 측정치가 아니라, 돌아보며 체감한 정도로 나눈 값이에요.
이렇게 나눠놓고 보니, 운영팀이라는 이름 하나로 뭉뚱그려졌던 3년 반이 실은 상품운영, CS·관제, 정산, 기술지원, QA, 보안관제, 문서화까지 걸친 멀티플레이어의 시간이었다는 게 눈에 보이네요.
운영팀의 기본 업무: CS, 모니터링, 장애 대응
운영팀이라면 누구나 상시로 짊어지는 기본 업무가 있어요. CS 상담, 서비스 모니터링, 장애 대응이 그거예요. 이건 저만 하던 일이 아니라 운영팀 전체가 늘 함께 감당하는 몫이었어요. 순번대로 당직을 서는 날에는 여기에 매니저님들이 남긴 문의 사항을 처리하는 일까지 더해졌어요.
2026.07.22 - [개념정리] - 서비스 장애 대응 매뉴얼: 감지부터 고객 보상까지
가장 힘들었던 건 "서버"였어요
운영팀은 서버가 메인이에요. 그런데 저는 서버를 한 번도 배워본 적이 없었어요. 코딩은 배웠어도 인프라, 네트워크, 서버 운영은 완전히 처음이었으니 출근 첫날부터 낯선 용어들 사이에서 헤맬 수밖에 없었죠. 그래서 모르면 정리부터 하자는 마음으로 하나씩 파고들기 시작했고, 그 정리들이 결국 저를 버티게 해줬어요.
입사 직후, 제가 가장 먼저 한 일들
첫째, 앱의 전 기능에 대한 풀 테스트(QA)를 진행하며 서비스 구조를 익혔어요. 서비스의 역할과 흐름을 이해하려면 결국 사용자가 무엇을 클릭하고 어떤 화면을 보게 되는지부터 알아야 한다고 생각했기 때문입니다.
둘째, 운영 흐름을 분석했어요 (인프라 운영 문서화). 특정 기능을 실행했을 때 요청이 어떤 API와 서버를 타는지, 로그는 어디에 쌓이는지, 그리고 DB로 들어가 어떤 큐와 프로시저를 거치는지 전체 흐름을 하나하나 따라가며 그렸어요. 이 작업 덕분에 서비스가 머릿속에서 하나의 그림으로 이어지기 시작했죠.
셋째, 배운 업무를 표준 작업 절차(SOP)로 문서화하고 교육을 담당했어요. 원래는 제가 보려고 정리했던 전자결재, 장애 확인, 정산, IDC 서버 강제 리부트 절차 등이 회사 내 공식 매뉴얼로 활용되기 시작했죠. 연중무휴 당직 체계에 맞춰 자주 들어오는 고객 문의 답변과 조치 매뉴얼을 제작했고, 실제 구축으로 이어지진 않았지만 고객 응대 효율화를 위한 ARS 서비스 시나리오 로드맵(흐름도)을 직접 구상해 문서화하기도 했어요. 나아가 외국인 매니저들을 위한 교육 자료 제작부터 정기 교육(1~2달 주기)까지 직접 진행했죠.
넷째, 보안 운영도 맡았어요 (보안관제). WAF(웹 방화벽)와 UTM 같은 방화벽을 함께 관리했고, 한때는 WAF 담당자를 맡기도 했어요. 서비스 도용이 발생했을 때는 국가별, 유형별 데이터를 직접 분석해 발생 패턴과 취약 지점을 짚어내는 일도 이 연장선에 있었죠.
다섯째, QA와 풀 테스트를 하며 개발팀과 소통하는 법을 익혔어요 (QA / 협업). 이슈를 어떻게 관리하는지, 매니저님들이 이해할 수 있게 설명하려면 어떻게 말해야 하는지도 이때 배웠어요. 매니저님들이 외국인이었던 덕에, 쉽고 명확하게 전달하는 연습이 자연스럽게 됐죠.
2026.07.23 - [개념정리] - QA 풀 테스트 진행법과 이슈 트래킹 실무
여섯째, 서버 간 아키텍처 토폴로지(Topology)를 시각화했어요. 프록시 서버부터 각 내부 서버로 이어지는 데이터 및 트래픽 흐름도를 Zabbix에 직접 구축했죠. 이 작업을 통해 서비스의 전체 인프라 구조를 통째로 파악할 수 있었어요.
일곱째, 정산 업무도 맡았어요 (정산 담당자). 저희와 연동해 거래하는 업체들의 선후불 거래명세서를 정산했고, 저희가 개발해준 업체들에는 유지보수 비용과 NAS 사용량을 기준으로 인보이스를 발행했어요. 여기에 고객·클라이언트에게 문자와 알림톡을 보내며 발생하는 SMS 사용량 정산까지 더해지니, 어느새 숫자와 청구서를 다루는 일도 제 업무의 한 축이 되어 있었어요.
제 주 업무: 해외 선불 충전 서비스 상품운영
저희 회사는 해외 모바일과 인터넷 데이터를 선물처럼 충전해주는 해외 선불 충전 서비스를 운영했는데 저는 이 상품운영을 전담했고, 이게 제 주 업무였어요.
해외 상품들을 API로 연동해 관리했고 (상품운영), 상품별 데이터를 분석해 통계를 내고 그 결과를 바탕으로 노출 우선순위를 조정했어요. 다국가 서비스이다 보니 각 상품의 환율 대응도 함께 챙겨야 했죠. 재고가 부족해 충전되지 않는 상품은 내렸고, 없어진 상품은 다른 상품으로 대체했으며, 신규 상품이 들어오면 연동하고 번역하고 직접 테스트까지 해보는 과정을 반복했어요.
여기에 더해 MVNO(알뜰폰) 충전 서비스도 지원하고 있어서, MVNO별로 필요한 작업이 있으면 스케줄을 걸어두고 자동으로 처리되게끔 관리했어요.
무엇이 좋았나
막막함을 정리로 하나씩 이겨내다 보니, 어느 순간 서비스 전체를 위에서 내려다보는 시야가 생겼어요. 어느 팀이 무엇을 하는지, 데이터가 어디서 어디로 흐르는지가 머릿속에 그려지니, 문제가 생겨도 이건 어디를 봐야 하는 일인지 빠르게 감이 왔죠. 이 감각은 개발을 하는 지금도 큰 자산이 되고 있어요.
그중에서도 제가 유독 좋아했던 건 로그와 쿼리로 문제를 찾아가는 과정이었어요. 운영팀은 이슈 원인을 정확히 추적하기 위해 결국 데이터를 들여다봐야 하는 자리입니다. 그렇다 보니 서버뿐만 아니라 오라클 같은 데이터베이스를 다루는 능력이 매우 중요했는데, 저는 이 데이터 분석과 프로시저 분석을 통한 트러블슈팅 과정을 특히 즐겼어요. 예를 들어 개발 과정의 허점으로 문제가 생기면, 먼저 로그를 뒤져 어디에서 무엇 때문에 문제가 생겼는지를 확인하고, 그다음 얼마나 많은 사람이 얼마의 금액을, 언제부터, 어떤 앱 버전에서, 혹은 어떤 IP나 국가에서 겪고 있는지를 쿼리로 좁혀 들어갔어요. 로그로 원인을 찾고 쿼리로 범위를 좁혀가는 이 과정이 저에게는 가장 재미있는 작업이었어요.
무엇을 견뎌야 했나
솔직히 정말 치열했어요. 아무것도 모르는 상태에서 시작해 빠르게 업무를 습득해야 했고, 조금 하다 혼나고 다시 배우기를 반복했죠. 게다가 야간으로 대학교도 함께 다니고 있어서, 당직을 서고 수업을 듣고 다시 일하는 날들이 이어졌어요. 예고 없이 터지는 장애에 늘 대비해야 하는 긴장감까지 더해지니 몸도 마음도 쉽지 않았어요. 그래도 그 시간을 버티며 침착함과 우선순위를 판단하는 힘을 배웠어요.
소통은 어떻게 했나
저는 번역가가 되려고 했어요. 고객의 불편을 개발이 이해할 수 있는 언어, 즉 재현 경로와 오류 로그, 추정 원인으로 바꿔 전달하고, 반대로 기술적인 상황은 고객과 매니저가 알아들을 수 있게 풀어서 전했어요. 외국인 매니저님들과 일한 경험 덕분에, 급할수록 감정보다 사실과 순서를 먼저 정리해 쉽게 전하는 습관이 몸에 뱄어요.
누구에게 추천하나
서비스의 전체 구조를 이해하고, 다양한 이해관계자 간의 의견을 조율하는 능력이 뛰어난 분께 잘 어울려요. 더불어 발생한 이슈의 원인을 데이터와 로그 기반으로 파악하는 걸 즐기신다면, 운영팀의 핵심 인재로 성장할 수 있을 거예요.
다만 저처럼 아무것도 모르고 오면 정말 고생해요. 운영팀에 오려면 서버와 네트워크는 물론, 오라클 같은 데이터베이스도 어느 정도 다룰 줄 알면 좋아요. 결국 데이터를 분석해야 하는 일이 많기 때문이에요. 서버 설치하는 법, 서버를 관리하는 법, 로그를 보는 법, 기본적인 SQL 쿼리를 짜는 법 정도만 익히고 와도 시작이 훨씬 수월할 거예요.
마치며
운영팀은 눈에 잘 띄지 않지만, 서비스 곳곳의 신호를 모아 멈추지 않게 연결해 주는 '스위치(Switch)' 같은 자리라고 생각해요.
예전에 대표님께서 이런 말씀을 하신 적이 있어요. "회사가 무너질 위기에 처하면 개발자부터 내보내더라도, 가장 마지막까지 살아남는 건 운영팀이다"라고요. 회사가 어려워지면 새로운 것을 개발하고 확장할 일은 없겠지만, 최소한의 서비스가 돌아가게 하려면 CS부터 인프라, 장애 대응까지 전반적인 흐름을 다 아는 운영팀이 반드시 필요하기 때문이죠.
대표님 말씀처럼 운영팀은 정말 모든 것을 알아야 하는 곳이었어요. 아무것도 모르던 열아홉 살의 저에게는, 이 스위치 같은 자리에서 CS, 상품 운영, 정산, 보안까지 서비스가 어떻게 굴러가는지를 통째로 배울 수 있었던 귀한 시간이었죠.
개발자로 일하는 지금도 그때 길러둔 시야 덕을 톡톡히 보고 있습니다. 지금은 개발 직군에 있으니, 언젠가 이 자리를 떠나게 되면 개발 이야기도 이렇게 따로 정리해 볼 생각이에요.