SM 프로젝트의 현실과 개발자의 경험

"SM 운영팀으로 갔을 때 제일 먼저 한 일이 뭔지 알아? 기존 코드 욕하기였어."

 

SM 프로젝트를 시작하기 전에 꼭 알아야 할 현실들!

개발자라면 누구나 한 번쯤 겪게 될 SM의 세계를 프로젝트 경험과 함께 풀어봅니다.

 

1. SM(System Maintenance) 프로젝트 개요

SM 프로젝트는 기존에 구축된 시스템을 운영하고 유지보수하는 업무를 의미한다.

SI(System Integration) 프로젝트에서 개발된 시스템을 안정적으로 유지하고, 장애 대응, 성능 최적화, 신규 요구사항 반영 등을 수행하는 것이 주요 역할이다.

일반적으로 SI 프로젝트를 진행했던 개발자들은 다음 SI 프로젝트로 이동하는 경우가 많고, SM 전담 팀이 운영을 맡게 되는 경우가 많다. 따라서 초기 개발자의 의도와는 다소 다르게 운영되는 경우가 발생할 수 있다.

---

2. SM 프로젝트의 초기 인수인계 과정

2.1 SI에서 SM으로의 전환 과정

• SI 프로젝트 종료 후, 새로운 운영팀이 인수하여 SM을 담당하게 된다.
• 하지만 초기 개발자들이 명확한 문서나 친절한 인계 과정을 제공하지 않는 경우가 많다.
• 일부 개발자들은 “내가 없으면 이 시스템은 제대로 돌아가지 않을 것이다”라는 생각으로 지식 공유를 최소화하려 하기도 한다.
• 시스템의 오너십을 가진 인력이 부족하기 때문에, SM 팀은 처음부터 시행착오를 겪으며 문제를 해결해 나가야 하는 경우가 많다.

2.2 SI 개발팀에 대한 불만과 현실

• “왜 이딴 식으로 만들어놨냐?”, “쿼리가 개판이다”, “최적화가 안 되어 있다”라는 말은 SM 프로젝트에서 빠지지 않는 단골 멘트다.
• SI 프로젝트 당시 일정에 쫓겨 급하게 개발된 코드들이 SM 운영팀의 골칫거리가 되는 경우가 많다.
• 데이터 모델링이 불완전하거나, 인덱스 설정이 제대로 되어 있지 않아 성능 이슈가 발생하는 경우가 많으며, 이를 운영팀이 하나씩 수정해 나가야 한다.
• “이걸 만든 사람은 이미 떠났고, 우리만 고생한다”라는 불만이 지속적으로 나오게 된다.

2.3 고객과의 관계

• 고객(발주사)은 시스템 운영의 최종 결정권자이므로, SM 팀이 초기 방향을 잘못 잡으면 이를 다시 교정하는 역할을 한다.
• SI에서 빠져나온 초기 개발자의 의도가 남아 있는 시스템이라도, 결국 고객의 요구에 따라 운영 방식이 최적화된다.

---

3. 안정적인 SM 조직의 분위기

3.1 안정적인 운영 환경의 특징

• 이미 운영이 한참 진행된 SM 조직은 매우 안정적이고, 때때로 보수적인 분위기를 가진다.
• 새로운 인력이 투입되었을 때 “우리 방식이 맞다”라는 분위기가 형성되어 있어, 기존 운영 방식을 바꾸기 어렵다.
• 새로운 기술 도입이 쉽지 않으며, 기존 시스템을 유지하는 것이 최우선 목표가 된다.

3.2 기존 인력과의 관계

• 오래 근무한 운영팀은 새로운 인력의 능력을 쉽게 인정하지 않는 경향이 있다.
• 새로운 인력이 시스템을 개선하려고 할 때, “굳이 바꿀 필요 없다”는 반응이 나올 가능성이 높다.

---

4. SM에서 주로 수행하는 업무

4.1 장애 대응 업무 (1순위)

• 빅데이터 SM의 가장 중요한 업무는 장애 대응이다.
• 데이터 파이프라인이 멈추거나, 적재 지연, 성능 저하 등이 발생할 경우 즉시 해결해야 한다.
• 실시간 데이터를 다루는 경우, 장애 발생 시 고객사 업무에 직접적인 영향을 미치므로 긴급 대응 능력이 중요하다.

4.2 데이터 추출 업무

• 운영 중인 빅데이터 플랫폼에서 각종 데이터 추출 요청이 들어온다.
• 예를 들면, 고객이 “어제 광고를 출시했는데, 그 시점 대비 계약 건수 증가와 매출 간의 연관성을 분석해달라”는 요청을 할 수 있다.
• 이런 요청은 오후 4시쯤 들어와서 “내일 아침 대표님 보고 자료로 필요하다”라는 급박한 일정과 함께 오는 경우가 많다.
• 대부분의 경우, 데이터 분석 팀이 요구하는 데이터셋을 생성하는 것이 주 업무가 된다.

4.3 신규 시스템 연동 및 POC(Proof of Concept)

• 기존 운영 시스템과 신규 시스템을 연동하거나, 새로운 기능을 추가하는 경우가 있다.
• 기존 데이터 레이크(HDFS, Iceberg)와 신규 분석 시스템(Snowflake, BigQuery 등)을 연동하는 작업이 필요할 수 있다.
• 새로운 기술 도입이 필요할 경우 POC를 수행하여 성능 및 안정성을 검증해야 한다.

---

5. SM 조직 내부의 미묘한 관계

5.1 팀원 간의 역할 차이

• SM 조직 내에서도 역할에 따라 업무량이 다를 수 있다.
• BI(비즈니스 인텔리전스) 및 OLAP 엔지니어들은 상대적으로 안정적인 업무를 수행하는 반면, ETL 및 데이터 엔지니어들은 업무량이 많다.
• 데이터 분석 팀(데이터 사이언티스트)과의 관계에서 “우리가 다 분석할 데이터를 만들어줬는데, 분석팀이 최종 결과만 보고받고 업적을 가져간다”는 불만이 나오기도 한다.
• 분석팀은 ETL 요청을 많이 하는 입장이라, 데이터 엔지니어와의 관계에서 미묘한 갑/을 구조가 형성되기도 한다.

5.2 야근과 긴급 요청

• SM 조직은 안정적인 환경이긴 하지만, 긴급 요청이 들어오면 즉각 대응해야 한다.
• 특히 빅데이터 SM에서는 데이터 추출 요청이 오후 늦게 들어오는 경우가 많으며, 다음날 오전 보고에 필요하기 때문에 야근이 불가피해진다.

---

6. 결론

SM 프로젝트는 SI와는 다른 특성을 가지며, 시스템 운영의 안정성을 유지하는 것이 최우선 과제이다. 개발보다는 운영, 장애 대응, 데이터 추출, 신규 시스템 연동 등의 업무가 중심이 된다.

그러나 기존 시스템이 이미 자리 잡힌 상태에서 운영되기 때문에 개발자로서의 성장 기회가 줄어들 수 있는 한계점도 존재한다. SM을 통해 시스템 운영 경험을 쌓고, 이후 새로운 프로젝트로 전환하거나, 기술 스택을 확장하는 것이 경력 개발의 중요한 요소가 될 수 있다.