소프트웨어공학

소프트웨어공학(Software Engineering)은 집적 회로 기반 제품 등의 제어를 목적으로 제작하는 모든 종류의 소프트웨어(Software)를 개발하는 방법론을 다루는 학문이다. 컴퓨터공학의 하위 학문으로 분류된다.

소프트웨어공학의 필요성

잘못된 방법론 적용으로 인한 소프트웨어 개발의 실패를 막기 위해서 연구할 필요가 있다.

소프트웨어 개발 프로젝트는 특정한 IT 소프트웨어 제품/서비스의 결과물을 효과적으로 얻기 위한 모든 사업이다. 프로젝트를 제안하는 서류를 작성하고 제출하여 자금 지원들을 받아 프로젝트에 돌입하면 제품을 기획하고 실행하며, 적절한 감시 및 관리를 받아가며 검증하여 프로젝트를 완료하여야 한다. 그런데 이것이 종종 좌초하거나 결과물이 버그투성이로 엉망인 경우가 상당히 많다.

건축공학이나 기계공학 등 다른 분야의 공학을 활용하는 제조업계의 제품 개발 이론과 비교했을 때 소프트웨어 개발 방법에 대한 연구는 그 역사가 몇십 년 수준인데다 현재의 개발 방법론이 30년 전과 크게 다르지 않으며, 이에 따라 소프트웨어 생산성이 사용자들의 서비스에 대한 요구를 따라가지 못하거나, 품질 향상 및 유지보수 난이도가 과도하게 높아지거나, 프로젝트 마일스톤(개발 일정 및 소요 비용 예측)이 부정확한 상황이 자주 발생하는 등 산출물의 품질 제어(Quality Control, QC)가 상대적으로 엉망이다.

이에 따라 소프트웨어 위기(Software Crisis)라는 말까지 등장하여 제대로 된 IT 서비스를 제공하기 위한 방법에 대한 연구가 시급하다. Plan -> Do ->Check ->Action 개념을 반복하는 방법론을 제정하는 PMI의 PMBOK나 소프트웨어 검증 관련 표준인 IEEE1012 같은 가이드라인들이 개발된 것도 그런 이유에 따른다.

종종 건축업계와 소프트웨어업계가 비교되곤 하는데 시공사와 감리사를 나누는 건축업계처럼 '제품 개발 프로세스'뿐만 아니라 '프로젝트 관리 프로세스'를 담당하는 기업의 필요성이 높아졌다. 그러나 현재 대한민국에서는 아직 건축업계의 감리 담당 기업 같은 개념이 덜 잡혀서 그런지 종종 발적화라고 욕먹는 저열한 품질의 소프트웨어가 자주 나온다.

중요 개념

소프트웨어 개발 프로세스

전통적인 공정은 다음과 같다. 보통 이를 '폭포수 모델(Waterfall Model)'이라고 부른다.

• 프로젝트 계획(Project Planning): 프로젝트의 관리, 개발, 품질 보증, 통합, 설치, 유지보수, 훈련, 운영 계획을 각각 수립한다. 여기에는 개별 프로젝트의 통합, 작업할 프로세스 범위, 예산을 맞출 수 있는 원가와 필요한 자산의 조달, 품질 관리, 인력 배치 등의 인적자원 관리, 의사소통 방법 명시, 리스크 관리, 이해관계 규명 등이 고려되어야 한다. 보통 이것은 프로젝트 매니저(PM)을 하나 세워서 감독하게 한다.
• 요구사항 분석(Requirement Analysis): 목표를 정확히 확인하는 시스템 요구사항 분석은 보통 기술적 소양과 원활한 의사소통 능력이 있어야 한다.
• 설계(Design)
• 구현(Implementation)
• 시험(Test)
• 유지보수(Maintenance)

만일 폭포수 모델을 따르는 개발 프로세스에서 특정 단계에 문제가 발생한다면 즉시 그 이전 단계를 점검하게 된다. 문제는 후반의 시험/유지보수 단계에 문제가 발생할 경우 이전 단계를 전부 순회하는 데에 엄청난 시간과 노력이 필요하다. 따라서 대체재로 다음 프로세스들이 제시되었다.

• 프로토타입 패러다임(Prototype Paradigm): 기능의 일부만 구현되었으나 그 자체로는 완전한 기능을 하는 프로토타입(원형)을 먼저 만들어 공개한 다음 모든 요구 사항이 구현된 완성품에 도달할 때까지 기능들을 조금씩 추가해나가는 방법이다. 프로토타입 제작 단계에서 제품 기획 단계에서 생각하지 못한 추가적인 기능과 문제점을 발견 가능하고 기획을 더 명료하게 할 수 있으며, 완성품의 가능성과 유용성을 증명할 수 있다는 점에서 제품/서비스 개발 프로세스를 안정화하기 쉽다. 보통 1자형으로 프로세스가 구성되는 폭포수 모델과 달리 프로토타입 패러다임은 원형으로 프로세스가 구성되어 설계와 개발, 평가와 피드백이 순환하는 구조로 되어 있다. 다만 기능을 계속 추가하다가 시제품과 완제품의 제품 기획과 성격이 판이하게 달라질 수 있다는 위험이 있다.
• 나선형 모델(Spiral Model): 폭포수 모델과 프로토타입 패러다임에 위험 분석을 추가해 각 순환마다 위험 평가를 통해 계속 개발할지, 개발을 중단할지 평가하는 체계다. 보통 장기 프로젝트나 국책 IT 사업에 유리한 모델이나 일반적인 상품 기획법으로는 프로젝트 관리의 기준과 평가에 투입할 자원 문제로 쉽지 않은 방법이다.
• 4세대 기법(4th Generation Techniques): CASE 와 정형 명세 언어로 대표되는 기계적 도구의 도움을 받아 명세서로부터 실행 코드를 자동으로 생성할 수 있는 방법이다. 코드 최적화 난이도가 올라가고 불필요한 코드 추가 가능성으로 인해 코드의 유지보수도 어려워지는 등 생성한 결과의 신뢰성 문제로 아직 도입이 빠르지 않으나 생성형 AI가 이 부분에 있어서 엄청난 발전을 선사할 가능성이 제기되었고, Microsoft Copilot 등의 가시적 성과가 나타나고 있다.
• 애자일 방법론(Agile Method): 21세기 들어서는 시점에서 제안된 방법론으로, 프로세스와 도구 못지 않게 고객과의 원활한 커뮤니케이션이 성공적인 소프트웨어 개발에 중요하다는 관점 하에 모든 개발 요구 사항을 추상적이고 큰 규모의 요구 사항에서 구체적이고 자잘한 수많은 세부 사항으로 나눈 다음 고객과 실시간으로 소통하면서 하나씩 iteration으로 구현해나가는 방법이다. 고객의 요구사항이 한 달 안에 구현할 수 있을 정도로 많지 않지만 자주 변화하는 경우에는 민감하게 반응할 수 있으나, 반대로 한 달 정도로는 끝내지 못할 정도로 요구사항이 많은 거대 프로젝트에서는 프로젝트가 엎어질 위험성이 상당히 크다. 그 외에 애자일 방법론은 기술적 진보가 빠른 경우 요구사항 분석 오류나 아키텍처 상의 오류, 테스트 실수, 문서화 오류로 인해 기술적 부채(Technical Debt)가 빠르게 증가하는 경향을 억제하는 데에 도움이 되는 편이다.
  • 이때 애자일 방법론 적용과 기술적 부채 억제를 병행하려면 객체 지향 프로그래밍 도입과 비효율적으로 작성된 코드를 교체하는 코드 리팩토링은 필수다. 보통 데이터 타입 등만 미세하게 다른 중복된 구조의 코드, 기능을 불필요하게 몰아 넣어 지나치게 길어진 메서드, 너무 거대해진 클래스 등의 객체를 각각 제네릭 타입 사용 코드, 메소드 분할, 객체 분할 및 상속으로 대체하게 된다.
• 컴포넌트 기반 개발: 프로그램을 기능 꾸러미인 컴포넌트(Component)를 조립하는 방식으로 개발하는 방법이다. 컴포넌트는 그 자체로는 이미 완성되었고 단지 독립적인 실행이 되지 않을 뿐이다. 이를 위해서는 컴포넌트 개발 프로세스와 컴포넌트 조립 프로세스가 분리되어야 한다.