개발전에 읽어야할 개발방법론!

JACKJACK·2023년 8월 21일

개발방법론이란?

개발 방법론은 소프트웨어 개발 프로세스를 계획, 실행 및 관리하기 위한 체계적인 접근 방식을 의미한다.

개발방법론은 개발자, 프로젝트 관리자, 디자이너, 품질 관리자 등의 개발 팀 구성원들이 프로젝트를 효율적으로 진행하고 완성하기 위한 지침과 프레임워크를 제공한다. 개발 방법론은 소프트웨어 생명주기의 다양한 단계에서 활용되며, 주로 다음과 같은 목적으로 사용된다.

1. 조직 및 프로젝트 관리: 개발 방법론은 프로젝트의 일정, 리소스, 비용 등을 관리하며, 프로젝트의 진행 상황을 추적하고 예측하는 데 도움을 준다. 이를 통해 팀은 목표를 달성하기 위한 계획을 수립하고 관리할 수 있다.

2. 품질 관리: 개발 방법론은 품질을 유지하고 개선하기 위한 프로세스와 기법을 제공한다. 품질 관리는 코드의 테스트와 검증, 버그 추적 및 수정, 코드 리뷰 등을 통해 소프트웨어의 안정성과 신뢰성을 높이는 것을 목표로 한다.

3. 효율적인 협업: 개발 방법론은 팀 구성원 간의 협업을 촉진하고 효율적인 의사소통을 돕는 방법을 제시한다. 명확한 역할과 책임, 효과적인 소통 채널을 통해 팀은 정보의 불일치나 중복을 최소화하며 원활한 협업을 실현할 수 있다.

4. 위험 관리: 개발 방법론은 프로젝트 진행 중 발생할 수 있는 위험을 식별하고 관리하는 방법을 제공한다. 위험 분석 및 관리를 통해 프로젝트의 성공 가능성을 높이기 위한 전략을 수립할 수 있다.

5. 프로세스 표준화: 개발 방법론은 팀이 일관된 접근 방식으로 작업하도록 도와 프로젝트 전반에서 일관성을 유지한다. 이를 통해 개발 프로세스를 표준화하고 개발 중 발생하는 혼돈과 혼란을 줄일 수 있다.

소프트웨어 개발 방법론의 종류와 역사 (주먹구구 -> 효율 극대화)

구조적 방법론(~1970s)

우리가 흔히 아는 폭포수 모형의 방법론이 이 구조적 방법론이다. 구조와 흐름이 간단하며 보통 "요구사항 분석 -> 설계 -> 프로그래밍 -> 검증 및 유지보수" 순으로 이루어진다.

장점은 각 단계에서 문서화(DFD,DD,MS)와 검증,검토를 강조하기 때문에 명확한 요구사항을 설계에 반영할 수 있고 신뢰성을 향상 시킨다. 또한 모듈 재사용성을 중요시 해 개발의 효율성을 높이는 장점이 있다.(DFD: 자료 흐름도, DD: 자료사전, MS: 단위 명세서)
단점은 프로젝트 초기의 유연성을 상세하기 정의하기 때문에 요구사항의 변경, 추가가 어려워 유연하지 않다. 또한 체계적인 설계화 문서화로 프로젝트 초기 비용이 많이 든다.

정보 공학적 방법론(1980s)

1980년대부터 정보시스템이 단순히 업무 지원 도구를 넘어서 경영 전략을 창출하는 역할인 경영정보 시스템MIS(Management Information System)으로 진화하게 되었다. 이에 따라 데이터 중심적 관점에서의 데이터 모델링과 데이터베이스 설계를 강조한다.

장점은 데이터 중심의 설계로 데이터의 일관성과 효율성을 높일 수 있으며, 데이터 관리를 효과적으로하고 데이터 변경에 따른 리스크 예측이 가능하다.
단점은 데이터 중심이기 때문에 시스템 기능의 요구사항을 표현하고 다루는데 한계가 있을 수 있다.

객체지향 개발 방법론(1990s)

소프트웨어 개발을 객체들의 상호작용과 협력에 중점을 둔 개념과 원칙에 기반하여 수행하는 방법론입니다. 이 방법론은 소프트웨어를 클래스, 객체, 상속 등의 객체지향적 개념을 사용하여 설계하고 개발하는 것을 강조(CASE Tool을 사용 UML사용같은 Case Tool은 소프트웨어 개발과정의 일부 또는 전체를 자동화하여 소프트웨어의 품질을 향상하고, 개발기간을 단축)

장점은 시스템을 모듈인 객체로 분할해 설계하기 때문에 코드의 재사용성이 높고, 디버깅/테스팅이 쉬우며, 시스템 확장에 유연하다. 추상화와 모델링으로 비 개발자와 비 전문가 간의 협업에 용이하다.
단점은 학습곡선이 높고 추상화와 모델링에 비용이 많이 들 수 있다. 또 모듈간의 추상화와 상호작용을 강조하므로 추가적인 메모리와 프로세스 리소스가 필요할 수 있다.

CBD 개발 방법론(1990s)

이전까지 monolithic 방식으로 소프트웨어 개발이 이루어졌는데, 이는 유지보수와 확장이 어려워 재사용성이 저하하는 문제점이 발견되었다. 이를 해결하기위에 CBD(Component-Based Deveolopment)가 나왔고, 시스템 여러개를 독립적인 컴포넌트로 분할해 각자 테스트한 후에 조합하는 방식으로 사용하게 되었다.

장점은 컴포넌트 단위 개발로 재사용성이 증가했고, 유지보수와 확장이 용이해졌다. 또한 컴포넌트간 결합도를 낮춰 의존성을 줄이고 독립적인 개발로 협업이 용이해졌다.
단점은 컴포넌트의 상호작용에 필요한 관리가 필요하고, 컴포넌트를 불러오는 통신 과정에서 성능 저하 이슈가 발생할 수 있다.

애자일 개발 방법론(2000s)

과도한 문서화나 형식적인 절차의 비용을 줄이고, 변화에 유연하게 대응해 고객의 요구를 우선시하는 개발 방법론이다. 기존과는 다르게 작은 주기로 프로토 타입을 만들어 지속적으로 고객의 피드백을 수용하고 프로젝트 일정을 조정하는 방법이다.

장점은 고객의 요구와 가치를 최 우선으로 두어, 변경에 유연하고 빠르게 대응해 필요한 기능을 먼저 개발할 수 있다. 지속적인 통합과 테스트를 강조해 높은 품질의 소프트웨어 개발이 가능하다.
단점은 문서화 부족이 일어나 프로젝트 이후 유지보수, 지식전달에 어려움이 생길 수 있다. 변화에 유연하게 대응하기 때문에 개발기간의 초기 예측과 개발비용관리가 어려울수 있다.

데브 옵스(2010s) - 개발문화의 변화

데브옵스는 개발과 운영의 경계를 허물고, 개발팀과 운영팀 간의 협업을 강화하여 소프트웨어의 개발부터 배포, 운영, 유지보수 등의 생명주기 전반을 통합적으로 접근하는 방식을 지향합니다. CI/CD의 자동화로 코드 지속적인 통합과 빠른 배포를 실현할 수 있으며, 개발팀과 운영팀의 협업을 강화해 문제를 빠르게 해결하자는 문화이다.

장점은 릴리스 주기를 단축시켜 새 기능과 버그 수정이 빠르고, 검증 테스트를 지속적으로 수행해 품질이 안정적이다. CI/CD자동화로 비용이 절감되며 개발팀, 운영팀의 협력이 강화된다.
단점은 조직 내부의 문화와 프로세스를 바꾸는 것이므로 적응에 시간과 노력이 들고, CI/CD 자동화를 위한 기술적인 지식과 노력이 필요하다. 또한 릴리스 주기가 짧은만큼 보안과 안정성을 간과할 수 있는 위험이 있다.