소프트웨어공학

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

소프트웨어공학의 필요성

잘못된 방법론 적용으로 인한 소프트웨어 개발의 실패를 막기 위해서 연구할 필요가 있다. 소프트웨어 개발 방법에 대한 연구는 건축공학이나 기계공학 등의 다른 공학 분야의 제품 개발에 대한 방법론들과 달리 그 역사가 몇십 년 수준인데다 현재의 개발 방법론이 30년 전과 크게 다르지 않으며, 이에 따라 소프트웨어 생산성이 사용자들의 서비스에 대한 요구를 따라가지 못하거나, 품질 향상 및 유지보수 난이도가 과도하게 높아지거나, 프로젝트 마일스톤(개발 일정 및 소요 비용 예측)이 부정확한 상황이 자주 발생하는 등 산출물의 품질 제어(Quality Control, QC)가 상대적으로 엉망이다. 이에 따라 소프트웨어 위기(Software Crisis)라는 말까지 등장하여 제대로 된 IT 서비스를 제공하기 위한 방법에 대한 연구가 시급하다.

중요 개념

소프트웨어 개발 프로세스

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

• 프로젝트 계획(Project Planning)
• 요구사항 분석(Requirement Analysis)
• 설계(Design)
• 구현(Implementation)
• 시험(Test)
• 유지보수(Maintenance)

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

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