개발의 방법론과 스타일 - 애자일과 폭포수

협업을 더욱 스타일리쉬하게

개발자 이해하기

수능 만점자는 교과서 위주로 예습 복습했다고 하고, 창업으로 억만장자가 된 사람은 부지런함이 곧 무기라고 하죠. 뻔한 조언이라 생각할 수 있지만, 무엇이든 잘하기 위해서는 기본적인 방법이 있다는 게 학계의 정설인가봅니다.

​

오늘은 개발자들이 한번쯤은 고민해봤다는 개발의 방법론에 대해서 알아보겠습니다. 개발 잘하기 위해서는 꼭 챙겨야 한다는 개발의 방법론. 당신의 협업을 더욱 스타일리쉬하게 만들어줄 아이디어를 찾아 적용해보세요.

​

잘하는 개발자들은 다 안다는 '그것'

개발 방법론의 정의와 도입 효과

방법론의 목표는 “무엇을, 어떻게 해야하는지를 제시하는 것”입니다. 비즈니스의 성공을 위한 솔루션 개발이나 업데이트 후 발생한 오류의 수정 등이 ‘무엇을’에 해당하는 것들이겠죠. 목적을 정했다면 이제 ‘어떻게’ 할 것인지를 정해야 합니다. 방법론은 주어진 문제를 해결하기 위해서 사용하는 기술 절차를 의미합니다. 또한 가장 효과적으로 일을 처리하는 방법과 그 과정에서 지식을 축적하는 것을 뜻하기도 하죠.

​

개발 방법론의 도입 효과는 다음과 같습니다.

​————————————————————

• 프로젝트의 관리가 가능해짐

　관리의 포인트를 지정할 수 있고, 전체 개발 과정을 한눈에 볼 수 있습니다.

​

• 광범위한 고객의 요구를 수용할 수 있는 체계가 수립됨

　표준 방법과 양식, 전략에 근거한 요구사항을 수집·요구 및 활용할 수 있습니다.

​

• 사용자-개발자간 의견을 원활하게 교환할 수 있음

　공통적인 의사소통 세션을 수행하면서 의사소통의 오류를 최소화합니다.

​

• 개발 과정에서 품질 관리가 용이해짐

　도구와 기법을 활용해 작업의 효율을 극대화하고 작업 기준을 제시할 수 있습니다.

​​————————————————————

요컨대, 방법론을 통해 작업의 전후과정이 더욱 깔끔하게 만들 수 있습니다. 작업의 시작과 완료 기준을 명확하게 정하여 작업 부하를 방지할 수 있죠. 역할과 책임도 분명하게 구분할 수 있기에 협업에 큰 도움이 됩니다. 작업 절차와 제반 문서, 산출물 등의 규격·표준화를 통해 생산성과 재사용성을 높이고, 작업 효율을 극대화됩니다. 또한 향후 개발할 소프트웨어의 품질을 미리 예측할 수도 있고, 개발한 제품의 모니터링이나 품질 검증도 용이해지죠.

​

우리 팀은 어떤 스타일일까?

개발 방법론의 종류와 흐름

개발 방법론에 여러 종류가 있지만, 옳고 그름을 따질 수는 없습니다. 조직의 특성에 따라 어떤 방식이 잘 맞을수도 있고, 아닐 수도 있기 때문이죠. 중요한 건 우리 팀의 스타일에 따라 어떤 방법론이 잘 어울릴지 판단하고 적용하는 것입니다.

​

먼저 어떤 방법론이 있는지 알아봐야겠죠?

​

• 구조적 방법론: 프로세스 중심의 하향식 방법론으로 전체 시스템을 기능에 따라 나누어 개발하고 이를 통합하는 분할과 정복 접근 방식의 방법론

• 정보공학 방법론: 개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론

• 객체지향 방법론: 객체, 클래스, 메시지를 사용해 시스템을 분석 및 설계하는 방법론

• 컴포넌트 기반 방법론: 소프트웨어를 구성하는 컴포넌트를 조립해 하나의 새로운 응용프로그램을 제작하는 방법론으로, 높은 생산성과 확장성을 자랑하며 소프트웨어 재사용이 가능한 방법론

• 애자일 방법론: 절차보다는 사람을 위주로 변화에 유연하고 신속하게 적응하며 효율적으로 시스템을 개발할 수 있는 방법론

• 제품 계열 방법론: 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론

  ​

다양한 장르 중에서도 내가 좋아하는 스타일의 영화나 책을 더 편하게 볼 수 있죠. 어떤 작업 방식을 택하느냐에 따라 효율도 천차만별입니다. 최근 대세는 뭐니뭐니해도 역시 ‘애자일’이지만, 이미 작업 과정이 고착화되어있는 대기업에서는 애자일이 적합하지 않을 수도 있다는 리더들의 의견도 있었습니다. 팀의 운영 방식과 협업 방식에 따라 적합한 방법론을 채택할 수 있도록 관심을 두고 지켜보는 것이 필요합니다.

​

과거 개발 과정은 대부분 폭포수(Waterfall) 방법론을 채택했습니다. 큰 요구사항이 정해져있고, 그 아래의 목표를 개별 개발자에게 할당할 수 있도록 세분화합니다. 원활한 프로젝트를 위해 필요한 것은 1) 요구사항을 명확히 분석하기 위한 심화 활동 2) 변경 사항이 발생하지 않도록 통제/관리할 수 있는 인력이 필요했죠.

​

폭포수 방법론에서 가장 핵심 인력은 PM(Project Management)였습니다. 이들은 정해진 일정에 한정된 리소스를 활용해 고유한 제품이나 서비스, 결과물을 만들어내는 것에 책임을 갖는 사람입니다. 그 과정에서 전반적으로 다양한 역할을 수행해야했죠. 일정을 관리하는 것부터 요구사항 수집, 품질과 자원, 의사소통과 리스크 관리, 모니터링 등 프로젝트의 전반을 다루는 총 책임자였습니다. 하지만 요즘 들어서 PM의 자리는 거의 없어졌다고 해도 무방합니다. 이유가 무엇일까요?

​

내일 일은 아무도 모르는 게 사람 인생. 모든 프로젝트에서 변경 사항은 발생할 수밖에 없습니다. 하지만 폭포수 방법론에서 변수 발생은 치명적입니다. 이런 리스크는 일정 지연과 리소스 추가 투입, 업무 피로도 상승 등의 결과를 낳을 수밖에 없었습니다. 사업 수익성에 부정적인 먹구름이 끼는 것도 당연한 수순이었죠. 또한 소프트웨어가 보급화되면서 사용자의 요구사항이 더 늘어남에 따라 더욱 빠른 개발 방법론이 대두되기 시작했습니다. 이에 모든 프로젝트를 총 지휘하던 PM은 점차 사라지고 그 역할을 세분화한 SM, PO가 중요해지는 추세입니다.

​

지금 가장 트렌디한 방법론 - 애자일

지속 가능한 개발을 위한 시스템

Agile이란 ‘기민한’, ‘날렵한’ 이라는 뜻으로 최근 스타트업뿐만 아니라 대기업에서도 추진하고있는 그야말로 대세 개발 방법론입니다. 앞서 우리는 애자일에 대해 “절차보다는 사람을 위주로 변화에 유연하고 신속하게 적응하며 효율적으로 시스템을 개발할 수 있는 방법론”이라고 정의했는데요. 폭포수 방법론과는 다르게 일정한 주기로 검토 및 요구사항을 반영해가며 개발하는 방식을 의미합니다.

​

애자일은 소통과 협업을 빼고 이야기할 수 없습니다. 개발과 테스트를 동시에 추진할 수 있으며, 그에 따라 피드백을 분석하고 유연하게 대응할 수 있기 때문입니다. 또한 기존의 방법론은 프로젝트의 본질적인 목표보다는 계획을 수립하고 문서화하는 과정이 지나치게 길었습니다. 주요 작업을 성취하기 위해 부수적으로, 또는 추가적으로 수행하는 작업에 인력과 비용을 과소비하고 있었죠. 애자일은 필요한 요구를 그때그때 더하고 수정하는 코드 중심의 점진적 개발 방법입니다.

​

애자일은 분석과 설계, 구현, 시험을 끊임없이 진행하고 반복합니다. 대략 1-2주정도의 짧은 개발기간을 권장하고있죠. 이 기간이 끝나면 데모 버전을 통해 결과를 고객에게 시연하기도 합니다. 사용자의 요구사항이나 상황의 변화에 신속하게 대응하여 고객에게 최고의 가치를 가장 빠르게 전달하는 것이 애자일의 목표입니다.

​

애자일은 요구사항의 변화가 자주 일어나는 곳에 적합합니다. 시스템이 한 번 만들어진 후 어지간하면 바꿀 일이 없는 곳에서는 굳이 애자일 방법론을 사용할 필요가 없습니다. 사실 우리나라에서 애자일 적용은 세계적인 추세에 비하면 낮은 편에 속합니다. 전통적인 기업 문화가 계단식을 띄고 있기 때문인데요. “보고드립니다.”, “컨펌 부탁드립니다.”라는 말이 익숙한 이유죠. 이런 절차지향적인 문화의 틀을 깨지 못한다면 애자일 적용이 어렵거나, 역효과를 일으킬 수도 있습니다.

​

애자일은 보통 소규모 개발진, 혹은 소형 기업에 적합하다고 알려져있습니다. 스타트업에서 많이 사용하는 이유기도 하죠. 하지만 인원이나 기업의 규모에 관계없이 애자일은 상호간의 존중과 신뢰에서 시작하며, 그것을 기반으로 합니다. 사용자와 구성원의 피드백에 빠르게 대응하기 위해서는 서로를 존중하고 스스로 일하는 자발적인 문화가 필요합니다. 단순히 ‘업무 효율이 올라간다더라’는 말에 현혹되지 마세요. 아무런 준비 없이 무작정 시작한다면 당신의 구성원이 ‘애자일 혐오자’가 되는 것도 한순간일 것입니다.