실패에서 배운 교훈:
소프트웨어 공학의 시작과 AI 시대까지
소프트웨어가 왜 실패했는지, 어떻게 극복했는지,
그리고 AI 시대에 소프트웨어 공학이 어떤 역할을 해야 하는지 배우는 과목
학습 목표
소프트웨어 개발의 흐름
- 소프트웨어는 어떻게 발전해 왔는가
- 왜 소프트웨어 공학이 필요해졌는가
- AI 시대, 소프트웨어 공학의 역할
01. 초기 소프트웨어 개발의 특징_1950~1960
- 하드웨어 중심 시대
1950년대, 60년대 초반에는 컴퓨터 자체가 굉장히 비싼 장비였음
따라서 관심의 중심은 항상 하드웨어였음- 문서/설계 개념 거의 없음
- 테스트나 유지보수 개념 미비
한 사람이 처음부터 끝까지 코드를 작성하는 방식이었기 때문에
프로그램 규모가 커질수록 문제가 발생할 수 밖에 없는 구조
02. 소프트웨어 위기(Software Crisis)
시간이 지날수록 더 느리고, 더 비싸고,
더 고치기 어려운 소프트웨어가 만들어지던 상황소프트웨어 개발의 규모가 커지며 복잡해졌고,
작은 변경에도 전체 구조가 흔들리는 상황이 자주 발생함
(유지관리 문제 발생)
이로 인해 프로젝트는 계획보다 늦어지고,
완성된 시스템도 기대만큼 안정적이지 못함원인
- 요구사항 분석과 설계 과정이 거의 없었음
- 대부분 구현부터 시작하는 방식
- 개발이 개인 역량에 의존
- 표준화된 개발 절차와 검증 방법 부재
- 테스트는 개발 마지막 단계에서 형식적으로 수행
- 문서화 부족으로 시스템 이해가 어려움
사람이 없어서가 아닌, 체계 없이 개발했기 때문에 발생한 문제
사고 사례: Mariner1(1962)
- 금성 탐사 우주선
- 수식의 하이픈(-:) 하나 누락
- 궤도 이탈 → 발사 후 72초만에 폭발
- 약 8천만 달러 손실
사고 사례: Therac 25(1985~1987)
- 의료용 방사선 치료 장비
- 소프트웨어 오류로 과다 방사선 조사
- 최소 6명 사망
- 하드웨어 안전장치 제거
- 테스트 및 검증 부족
Barry Bohem 1988
"당시 우리는 사람의 생명과 직결된 시스템을 만들면서도, 마치 실험용 프로그램을 작성하듯 소프트웨어를 개발하고 있었습니다."이러한 문제의식 속에서 소프트웨어도 공학처럼 체계적으로 만들어야 한다는 인식이 생겨났고, 소프트웨어 공학이 등장하게 되었다.
03. 소프트웨어 공학의 등장
- 체계적인 개발 방법론
- 예측 가능한 일정
- 품질 관리
- 유지보수 가능성 확보
나중에 누가 보더라도 쉽게 이해하고 수정할 수 있도록, 즉 지속 가능한 생명력을 불어 넣는 것이 공학의 핵심
불확실했던 개발 과정을 예측 가능하고 신뢰할 수 있는 공학적 활동으로 전환하려는 위대한 노력
04. 소프트웨어 공학의 주요 분야
1주차 수업
기존의 강의: 전통적 소프트웨어 공학
~3주차: 수시 시험
4주차~: 실습
과제1: 바이브코딩 개념으로 AI를 활용하여 프로젝트 만들기
과제2: AI와 협업하는 방법을 통해 과제1로 만든 프로젝트에
새로운 기능 더하기
이슈와 칸반보드가 채워져 있고 모든 이슈가 Done으로 마무리 되어있을 것
Fork와 template
Docker
내 컴퓨터의 환경을 그대로 컨테이너에 담아서
어디서든 똑같이 실행할 수 있게 해 주는 도구핵심 개념
- 이미지(Image): 프로그램 실행에 필요한 모든 것(코드, 라이브러리, 설정)을 담고 있는 스냅샷 혹은 설계도
- 컨테이너(Container): 이미지를 실행시킨 실체로, 이 내부에서 프로그램이 실제로 실행됨
- 도커 허브(Docker Hub): 전 세계 사람들이 만든 이미지를 저장하는 저장소
반드시 AI를 활용할 수 있어야 함
개발은 누구나 가질 수 있는 지식이 됨
사용 도구 예시
클로드, 제미나이, 캔바, BREW
부족함과 불편함을 느끼는 것을 기회로 삼자
