개발 vs 양산, 다른 게임 다른 규칙: 우리 회사 '양산' 프로세스, 괜찮은 걸까?

소프트웨어 개발 현장에서는 크게 두 가지 흐름이 있습니다.

 

 

하나는 새로운 기능을 만들거나 제품을 처음부터 구축하는 '개발'이고, 다른 하나는 이미 사용자에게 전달된 소프트웨어의 문제를 해결하거나 개선하는 '양산(혹은 유지보수)'입니다.

 

개발 프로세스는 1년 정도의 여유를 가지고 폭포수 모델을 따라 체계적으로 진행하지만, 한달 내에 긴급하게 대응해야 하는 양산 프로세스 때문에 고민이 많습니다.

 

처음에는 간단했던 양산 프로세스가 품질 이슈가 터질 때마다 개발 프로세스의 절차를 하나둘 가져오면서, 개발자들의 부담만 커지고 효율은 떨어지는 악순환을 겪고 계신가요?

 

오늘은 이 '양산' 프로세스를 어떻게 가져가야 할지, 다른 곳에서는 어떻게 하는지에 대해 이야기 나눠보려 합니다.

 

 

개발 프로세스: 계획된 여정, 튼튼한 기반

일반적으로 '개발' 단계는 상대적으로 시간적 여유가 있습니다. 요구사항(VOC) 분석부터 시작해서 상세 설계(SRS), 테스트 케이스(TC) 작성까지, 각 단계를 충실히 거치며 산출물을 꼼꼼히 챙깁니다. 마치 건물을 짓듯이, 기초부터 탄탄히 다지고 각 층을 쌓아 올리는 방식이죠. 폭포수 모델이든, 애자일 방법론을 일부 차용하든, 중요한 것은 '계획'과 '문서화'를 통해 전체적인 품질과 방향성을 관리한다는 점입니다. 시간과 자원이 충분하다면 이 방식은 매우 안정적입니다.

 

양산 프로세스: 예측 불가능한 불끄기, 속도와 안정성의 딜레마

문제는 '양산'입니다. 이미 운영 중인 서비스에서 버그가 발생하거나, 고객의 긴급한 개선 요청이 들어옵니다. 시간은 촉박하고(대부분 몇 주 내), 문제는 당장 해결해야 합니다. 범위는 개발보다 작을 수 있지만, 파급 효과는 훨씬 클 수 있습니다.

처음에는 '분석 -> 수정 -> 테스트(TC)' 정도로 간단하게 시작했을 겁니다. 하지만 작은 실수 하나가 큰 장애로 이어지는 경험을 하고 나면, "이것도 추가하자", "저것도 검토해야 한다"며 개발 프로세스의 절차들을 가져오기 시작합니다. SRS까지는 아니더라도 상세 분석서, 영향도 분석, 코드 리뷰 강화, 추가 테스트 단계 등... 점점 무거워지죠.

 

왜 개발 프로세스를 그대로 적용하기 어려울까?

1. 시간 제약: 양산은 '속도'가 생명입니다. 개발처럼 모든 단계를 다 밟을 시간이 절대적으로 부족합니다.
2. 범위의 특수성: 전체 시스템을 보는 개발과 달리, 양산은 특정 문제 지점과 그 영향 범위를 빠르게 파악하는 것이 중요합니다.
3. 목표의 차이: 개발은 '새로운 가치 창출'이라면, 양산은 '기존 가치의 안정적 유지 및 복구'에 가깝습니다.

개발 프로세스를 그대로 가져오는 것은 마치 소방차가 출동하는데 평소처럼 안전 점검 리스트를 처음부터 끝까지 다 확인하는 것과 비슷합니다.

 

꼭 필요한 절차는 지켜야 하지만, 상황에 맞게 최적화된 대응 매뉴얼이 필요한 것이죠.

 

 

그렇다면 양산 프로세스, 어떻게 개선할 수 있을까?

 

다른 도메인이나 성공적인 팀들은 양산(유지보수) 프로세스를 어떻게 운영할까요? 정답은 없지만, 몇 가지 공통적인 접근 방식이 있습니다.

 

1. 가볍고 빠른 '전용' 프로세스 정의: 개발 프로세스를 차용하기보다, 양산의 특성(긴급성, 작은 변경 범위, 높은 안정성 요구)에 맞는 별도의 경량 프로세스를 정의합니다.
   
   예를 들어, 칸반(Kanban) 보드를 활용하여 작업 흐름을 시각화하고 병목 현상을 관리하는 방식이 효과적일 수 있습니다.

 

1. 핵심에 집중: 모든 개발 단계를 다 따르기보다, 양산에서 '반드시' 필요한 핵심 활동에 집중합니다.
   • 정확한 원인 분석(Root Cause Analysis): 단순히 현상만 해결하는 것이 아니라, 근본 원인을 찾아 재발을 방지합니다.
     
     
   • 영향도 분석(Impact Analysis): 수정된 코드가 다른 부분에 미칠 영향을 최소화하고 예측합니다. 이것이 가장 중요합니다!
     
     
   • 최소한의 효과적인 테스트: 전체 회귀 테스트보다는 변경된 부분과 영향받는 주요 기능 위주의 '타겟 테스트' 및 자동화된 테스트를 활용합니다.
     
     
   • 코드 리뷰: 동료 개발자의 리뷰는 실수를 잡는 데 매우 효과적입니다. 단, 양산 상황에 맞게 속도와 효율성을 고려하여 진행합니다.
2. 자동화 활용: 빌드, 테스트, 배포 과정을 최대한 자동화하여 사람의 실수를 줄이고 속도를 높입니다. CI/CD(지속적 통합/지속적 배포) 환경 구축은 양산 효율성 증대에 필수적입니다.
   
   
3. 명확한 '완료' 기준(Definition of Done): 양산 작업이 언제 '끝났다'고 정의할 것인지 명확한 기준을 세웁니다. (예: 원인 분석 완료, 코드 수정 및 리뷰 완료, 타겟 테스트 통과, 고객 확인 완료 등)
   
   
4. 지속적인 회고 및 개선: 양산 프로세스 자체도 완벽할 수 없습니다. 정기적으로 팀원들과 함께 프로세스의 문제점을 되짚어보고 개선해나가야 합니다. (예: "이번 패치는 왜 오래 걸렸을까?", "테스트에서 놓친 부분은 왜 발생했을까?")
   
   

결론: 양산 프로세스, '가볍지만 단단하게'

양산 프로세스는 개발 프로세스의 축소판이 되어서는 안 됩니다.

 

그 자체의 목표와 제약 조건에 맞는 '최적화된 규칙'이 필요합니다.

 

무조건 절차를 늘리는 것이 품질을 보장해주지는 않습니다.

 

오히려 개발자들의 부담을 가중시키고, 정작 중요한 '빠르고 안정적인 문제 해결'이라는 목표 달성을 방해할 수 있습니다.

 

지금 우리 팀의 양산 프로세스가 너무 무겁고 비효율적이라고 느껴진다면, 팀원들과 함께 솔직하게 문제점을 공유하고, 우리 상황에 맞는 '가볍지만 단단한' 프로세스를 만들어나가는 노력이 필요합니다.

 

속도와 안정성 사이의 균형점을 찾는 것이 핵심입니다!