*잠깐, 위시켓은 2022년 시밀러웹 방문자 수 기준, 국내 1위 IT아웃소싱 플랫폼입니다. 현재 10만 이상의 개발업체, 개발 프리랜서들이 활동 중이며 무료로 프로젝트 등록이 가능합니다. 프로젝트 등록 한 번으로 여러 개발업체의 견적, 예상기간, 포트폴리오 등을 한 번에 비교해 보세요📝



‘개발 프로세스’에서 데브옵스(DevOps)와 애자일(Agile) 방법론이 떠오르면서 소프트웨어 개발이 쉽고 스트레스 없는 프로세스라고 생각할 수 있습니다. 하지만 그 분야의 개발자들과 실제 이야기를 나눠보면 결코 소프트웨어 개발이 쉽지 않다는 것을 알 수 있습니다. 마감기한을 넘기고, 기술적 부진이 누적되고, 업무적으로 부하가 걸리는 것은 여전히 개발자들이 흔히 겪는 어려움입니다.

여기서 이런 의문점이 제기됩니다. 만약, 애자일(Agile)도 데브옵스(DevOps)도 해결책이 아니라면 어떻게 하시겠습니까?

이 글은 Jon Collins가 대형 기술 서비스 회사의 인프라 기술 솔루션 담당 이사인 Daniel Mostert에게 조언하여 대규모 애플리케이션을 위한 프로젝트를 주도하고 기업이 ‘개발 프로세스’의 어려움을 해결할 수 있도록 조언한 경험담을 기반으로 쓰였습니다.

Jon Collins와 Daniel Mostert는 개발할 때 항상 발생되는 문제들, 그리고 그 프로세스 안에서 애자일(Agile)이 수행할 수 있는 역할, 그리고 매니저가 팀을 참여시키고 예산에 맞게 프로젝트를 제공하는 데 사용할 수 있는 기술에 대해 논의했습니다. 그리고 Mostert가 개발자로서 30여 년간 일한 경력에서 얻은 네 가지 핵심이 중요하다고 생각했습니다.

1. 개발 프로세스 세분화하기

‘개발 프로세스’를 세분화하는 것은 모든 ‘개발 프로세스’를 개선하는 핵심입니다. 다만 ‘개발 프로세스’를 세분화해서 분석한다’라는 것은 너무도 단순한 일이기 때문에 오히려 많은 관리자들이 이를 잊고 있습니다. 그러나 ‘개발 프로세스’를 세분화하고 전체 목표에 대한 각 단계의 중요성을 평가하는 것은, 우선순위를 만들고 팀에서 집중력을 높이는 데 도움을 줍니다.

Mostert는 또한 “저는 기능 설계, 객체 지향, 심지어 규모까지 모든 과정을 분석해 보았습니다. 기본적으로 모두 동일하게 진행됩니다. 과정을 더 작은 조각으로 쪼개고 여러분이 무엇을 하려고 하는지 이해해 보세요. 그게 이 일의 전부입니다. 하지만 우리는 과정들이 모두 다른 것이라고 부릅니다. 그러나 결국, 프로세스를 분석하면 결론적으로 동일하게 됩니다.”라고 설명했습니다.

2. 한 사이즈로는 모든 사이즈를 맞출 수 없음을 이해하기

애자일(Agile)과 데브옵스(DevOps)의 개념을 특정 환경에서 매우 생산적일 수 있지만 다른 환경에서는 그렇지 않을 수 있습니다. 더 높은 생산성을 달성하려면 상황에 맞게 다양한 창의적 관리 기술과 ‘개발 프로세스’를 사용해야 합니다.

대규모 프로젝트에서 매우 명확하게 정의된 기능을 개발하고 있다면 Agile을 사용하는 것에는 여러 가지 이유가 있다고 생각합니다. 일부 시스템 유지 보수와 개선, 개발을 수행하는 복합적인 환경에서 작업하는 경우, 가장 중요한 문제는 ‘그것 중 우선순위가 무엇일까?’가 됩니다. 다양한 환경들과, 각 환경에 대해 서로 다른 접근 방식이 있을 수 있습니다. 하지만 일의 우선순위를 정하는 리더십은 여전히 필수적입니다.

3. 스케줄링의 덫에 걸리지 않기

스케줄을 잘 조절하는 과정은 많은 프로젝트 관리 교육 과정의 핵심 부분입니다. ‘어떻게 일정 관리를 해야 하는가’에 대해서, Mostert는 ‘경영진 측에서 일정을 관리하려다 종종 치명적인 실수를 범한다’라고 주장합니다. 즉, 프로세스를 탑다운(Top down) 방식으로 제어하려고 하면 실제로 프로젝트가 무엇을 필요로 하는지, 그리고 얼마나 오래 걸릴지에 대한 지식이 거의 없는 경우가 많으므로 프로젝트 스케줄링에 실수가 발생한다는 것입니다.

때문에 그는 경영진이 엄격한 데드라인을 설정하지 않고, 예상 완료 날짜에 대한 더 나은 추정치를 제공할 수 있기 때문에 개발 팀과 협력하여 대략적인 일정을 만드는 방법을 제시합니다.

그는 경영진이 사람들에게 ‘이 기한 안에 완성하세요.’라고 하면 절대 효과가 없을 것이라고 덧붙입니다.

‘이 기한 안에 완성하는 것이 계획이고 무조건 그 안에 끝내야 한다.’라고 말하는 것은 효과가 없습니다. 소프트웨어 프로젝트를 언제 마무리할 수 있을지 정확히 계산할 수 없기 때문에 작업 관리자 측 입장에서 개발자들은 ‘O월 O일에 작업이 완료될 것입니다.’라고 확실히 말할 수 없습니다. 오히려 프로그램을 작성하는 데 얼마나 걸리나요? 테스트하는 데 얼마나 걸리나요? 시간이 얼마나 걸려요?라고 질문하는 게 더 효율적일 수 있습니다.

4. 창조적 구조, 긍정적인 문화

Mostert는 관리 스타일과 프로세스를 프로젝트에 적용시키는 데 찬성하지만 특정 문제에 대해 몇 가지 ‘역할 분담 모델’을 추천합니다. 모두가 새로운 구조를 믿고 다양한 목표를 달성하기 위해서 서로를 지원하는 긍정적인 팀 문화와 짝을 이루는 것을 긍정적으로 평가합니다. 그러나 이 접근 방식에도 단점이 있을 수 있다고 Mostert는 경고합니다.

그가 흥미를 느낀 한 모델은 버그를 해결하기 위한 ‘소방관’과 기능 개발을 위한 ‘헤드 다운 코더’로 분리하는 모델이었습니다. 좋은 기능을 만들려는 이러한 역할 분담은 프로젝트나 제품 기획 간 발생되는 심각한 기술적 부진과 부담을 피하기 위해 매우 중요하다고 주장합니다.

그는 ‘작업 중에 급작스럽게 우선순위를 변경하는 것 같은 난센스 한 것을 골라낼 수 있는 ‘한 팀’이 되도록 팀을 구성해야 한다’라고 말했습니다. 그러고 나서 ‘팀 내에서는 만들고자 하는 기능으로 롤백 할 수 있는 또 다른 역량이 있어야 한다’라고 말합니다.

위험은 해결되지 않는 기술적 부채를 만드는 것에서 옵니다. 팀은 해결책을 마련하고 추후에 구체화할 계획이겠지만, 결론적으로 그 해결책은 결코 실현되지 않을 겁니다. 당신은 결국 그 혼란 속에서 무슨 일이 일어나고 있는지 제대로 파악하는 소수의 사람들과 함께 할 것이며 그들은 영원히 당장의 문제 해결에 바쁠 것입니다. 그리고 당신은 절대 그 굴레에서 벗어날 수 없을 것입니다.

가장 큰 도전은 서로 다른 구성원이 그룹에 들어오고 나가는 동안 팀과 문화를 온전하게 유지하는 일입니다. 핵심 멤버 한두 명이 떠나면 거의 처음부터 다시 시작하는 것과 같아집니다.

결론

Mostert의 아이디어는 소프트웨어 개발 프로젝트에 접근할 때 유연성의 중요성을 다루는 방식에 중점을 두고 있습니다. 특히 규모에 맞게 운영할 때 프로젝트 관리자가 갖춰야 할 필수적인 자질을 설명합니다.

애자일 개발 프로세스(혹은 DevOps 개발 프로세스)는 소프트웨어 개발의 현대적이고 효율적인 문화를 가능하게 하는 데 매우 중요한 요인이지만, Mostert가 말한 것처럼 모든 환경에 적용 가능한 것은 아닙니다. 프로젝트에 맞게 프로세스와 팀 구조를 변경한다는 그의 철학은 프로젝트 관리자에게 당면한 작업을 평가하고, 간략한 내용과 팀을 평가하며, 전통적인 Agile 구조에 맞을 수도 있고 아닐 수도 있는 창의적인 결정을 내릴 수 있는 요소를 제공합니다.



국내 1위 IT아웃소싱 플랫폼 위시켓에 프로젝트를 등록해 보세요.

6만여 건의 데이터를 바탕으로 프로젝트 견적을 상담해 드립니다.