1 . 소프트웨어 공학 소개

1. 이 과목의 성격

• 자료구조·알고리즘·언어는 미시적: 정확, 수학적, 디테일하다.
• 소프트웨어 공학은 거시적: 범위가 넓고 원론·원리 중심이다. 같은 시간에 큰 주제를 다루니 알고리즘만큼 공식이 떡 떨어지지 않는다.
• 경험적 학문이다. 수학처럼 답이 하나로 떨어지지 않고, 역사적으로 싶은 실패와 성공을 정리한 방법론이다. 그래서 새 방법론이 계속 나온다.
• 이상적인 학습자는 현업에서 개발 고통을 겪어 본 사람이다. 학생 과제 규모(수천~1만 라인) 경험만으로는 감이 안 올 수 있다. 여기서 다루는 문제는 대형 프로젝트 차원이다.

2. 프로그램 vs 소프트웨어

• 프로그램: 원시코드의 정적인 표현.
• 소프트웨어(이 과목의 정의): 프로그램 + 개발·운용·보수에 필요한 관련 문서·정보 일체. 계획서, 요구분석 명세서, 설계, DB 구조, 테스트 결과, 사용자 매뉴얼까지 포함한다.
• 이유: 코드만 보면 2년 전의 자신이거나 다른 사람의 의도·로직이 보이지 않는다. 유지보수·인수인계·기능 추가는 문서가 있어야 가능하다. 현업은 새 코드보다 기존 코드 수정이 더 많다.
• 소프트웨어 시스템: 소프트웨어는 독립적으로 존재하지 않는다. 하드웨어, 문서, DB, 사람, 교육, 유지보수와 연결된다. 예: 은행 전산 — 텔러 터미널 — ATM — 인터넷뱅킹.
• 엔지니어가 잡아야 할 것: 대상 시스템, 서브시스템, 특성·기능, 시스템 경계, 입력/출력, 서브시스템 간 관계.

유형 (슬라이드)

• 응용 SW: 급여·회계·재고·학사·은행 등 기관 내부 업무
• 시스템 SW: OS, 드라이버, 컴파일러, 라이브러리
• 주문형 SW: 특정 고객/기업 요구로 제작
• 패키지 SW: 워드, 스프레드시트, POS, 회계 등 상업 판매
• 임베디드 SW: 다른 시스템(차, 항공기 등)에 내장

3. 소프트웨어의 특징

• 복잡성, 비가시성, 비제조성, 테스트 가능, 변경성, 순응성(시장 변화에 따라 바뀌는 성질)
• 복제 가능, 비마모성, 장수, 응용 의존
• 제조가 아닌 개발: 제조는 틀에 맞춰 결과 편차가 작고, 개발은 개인 능력 차이가 크다.
• 소모가 아닌 품질 저하: HW는 쓸고 고장율이 늘어나는데, SW는 달지 않고 기능은 그대로다. 다만 변경(기능 추가/수정) 때마다 부작용으로 실패율이 다시 뛰는다.
• HW 실패 곡선 = 욕조 곡선(초기 실패 → 안정 → 마모로 재상승).
• 이상적 SW 실패 곡선: 초기 잠복 오류를 잡으면 폐기까지 낮은 실패율 유지.
• 실제 SW 실패 곡선: 변경 → 부작용 → 실패율 급증 → 다시 수정. 이 루프가 반복된다.

4. 소프트웨어 개발이 어려운 이유

규모 비유 (건축)

• 소규모 = 개집: 연장 적고, 설계도 개념적, 혼자 가능. 소웨공 대상 아님.
• 중규모 = 주택: 경험·전문 도구·설계도 필수. 고객 요구가 달라지고, 설계자와 시공자가 나뉘어진다.
• 대규모 = 빌딩: 다양 전문가, 관리, 단계, 하중·내진 등 제약조건. 소프트웨어 개발은 이쪽에 가깝다.

어려움 1 — 복잡함

• 구성 요소가 많아 가능한 조합이 폭증하고, 그중 좋은 답을 찾아야 한다.
• 교수 경험: 핸드폰 개발 초기 HW 3명 / SW 3명이었는데, 기능이 늘어날수록 SW만 10~30명으로 늘었다. HW는 부품 선정·조합에 가깝고, SW는 할 일이 계속 늘어난다.
• 규모 예: 넷스케이프 1,700만 라인, 리눅스 150만, Windows XP 4,000만, 보잉 777 700만, 우주선 1,000만 라인.
• 기본 원리는 Divide and Conquer. 소웨공은 이 복잡함을 줄이는 방법·기술을 제시한다.

어려움 2 — 참여 인력

• 사람이 많아지면 의사소통·의사결정·협력이 어려워진다.
• 중간 이직·신규 투입 시 인수인계 비용이 크다. 소프트웨어는 업무가 형식화되어 있지 않아 파악 비용이 크다.
• 그래서 지연되는 프로젝트에 사람을 더 넣으면 더 늦어진다는 말이 나온다.
• 소웨공은 팀 구성·관리 방법을 제시한다. 완벽한 해법은 없다.

어려움 3 — 기간이 긴다

• 원인: 무엇을 만들지 정의하기 어렵다. 고객 요구가 부정확하고, 개발 중에 새 필요가 드러난다.
• 그래서 요구분석이 중요하고, 일정 산정이 어렵다. “모든 소프트웨어 프로젝트는 지연된다”.
• 소웨공에서 시간 = 비용. 체계적 프로젝트 관리가 필요하다.

5. 소프트웨어 위기와 공학의 시작

• 1950~60년대: 게임 등을 그냥 만들면 팔렸다. 이론 없이 만든 스파게티 코드.
• 히트작에 기능을 붙이려 하면 고치기가 새로 만드는 반만큼 어려워졌다.
• 1970년대를 전후로 유지보수 비용 > 개발 비용.
• 1968 NATO 회의에서 소프트웨어 공학이라는 용어·연구가 시작.
• 이후 HW는 상대적으로 써지고, SW 가치가 커졌다.

구조적 프로그래밍 (초기 성과)

• 모든 알고리즘은 순차 / 선택(if) / 반복(for, while) 세 구조의 중첩으로 표현 가능.
• 핵심: goto 금지. 점프 도착지에서 어디서 왔는지 모르면 스파게티가 된다. 지금은 당연하지만 당시에는 혁신이었다.

6. 과학 vs 공학, 그리고 소웨공의 목적

• 과학: 왜 그런가? 관찰–가설–실험–이론. 성과물은 법칙·모델.
• 공학: 어떻게 만들 것인가? 요구분석–설계–구현–테스트. 성과물은 제품·시스템·SW.
• 소웨공 = SW 개발에 공학적 원리를 적용하는 학문.
• 목적 2가지:
  1. 생산성 — 시간/비용 축소
  2. 품질 — 빨리 만들어도 품질이 떨어지면 안 된다

7. 소프트웨어 생명 주기 (SDLC)

계획 → 분석(요구 정의) → 설계 → 구현(코딩) → 테스트 → 출시·사용 → 유지보수 → 폐기 또는 다음 버전 계획

• 계획 단계는 경험 기반의 개략 산정이 많다. 실제 비용은 분석부터 든다.
• 테스트는 구현 만큼 중요하고, 각 단계마다도 검증이 필요하다.
• 교수님의 경험: 개발팀 vs QC/테스트 부서는 출시 전 버그 책임이 달라, 업무상 긴장할 수 있다. 출시 후 중대 버그는 테스트 책임으로 넘어간다.

 

TMI - 이 과목 뒤에는 캡스톤 디자인이라는 이름이 붙어서 신청했다. 그러나 이 교수님은 캡스톤디자인의 뜻을 잘 모르는거같다. 그러지 않고서야 중간 + 기말 합이 70에 과제로 보고서 열심히 쓰고 개발하는게 20일리가 없어... 그래서 드랍한 사람도 한바가지다. 랜덤 팀원 배정인데 이건 교수님의 의도로 나를 설득했기에(인생에 지 맘대로 팀원을 꾸릴수 없다는 이유) 인정하고 하겠지만, 만드는거보다 이론에 시간을 투자하는게 좀 아쉽긴 하다. 그래도 정처기 공부를 미리 한다는 긍정적인 태도로 공부하자!