프로그램 개발 절차

생각 열기 — 집을 지을 때 벽돌부터 쌓는가

집을 짓는다고 하자. 벽돌과 시멘트를 사 와서 바로 쌓기 시작하면 어떻게 될까. 방이 몇 개인지, 문이 어디 달리는지, 전선과 수도관이 어디로 지나가는지 정해지지 않은 채 벽이 올라간다. 나중에 화장실을 만들려면 이미 쌓은 벽을 부숴야 한다.

개발 절차 다섯 단계

프로그램을 만드는 일에도 순서가 있다. 크게 다섯 단계로 나눈다.

코드를 쓰는 일은 세 번째 단계다. 앞의 두 단계에서 무엇을 쓸지 정하지 않으면 세 번째 단계에서 손이 멈춘다.

1단계 · 요구 사항 분석 — 무엇을 만들지 정한다

요구 사항(requirements) — 프로그램이 무엇을 해야 하는지 적어 놓은 것은 프로그램이 해야 할 일이다. 이 단계에서는 코드를 한 줄도 쓰지 않는다. 대신 다음을 정한다.

• 이 프로그램이 누구를 위해 무엇을 해 주는가
• 무엇을 입력으로 받고 무엇을 출력으로 내놓는가
• 하지 않아도 되는 일은 무엇인가

마지막 항목이 중요하다. 할 일 목록보다 하지 않을 일 목록이 프로그램의 크기를 정한다. 급식 메뉴를 보여 주는 프로그램에 “회원 가입”과 “메뉴 평점”까지 넣기 시작하면 끝이 없다.

2단계 · 설계 — 어떻게 만들지 정한다

설계(design) — 요구 사항을 어떤 구조와 절차로 만들지 정하는 단계는 집의 설계도를 그리는 일에 해당한다. 여기서 정하는 것은 크게 셋이다.

1. 프로그램을 어떤 덩어리로 나눌지 — 기능별로 나눠 각 덩어리가 할 일을 정한다.
2. 각 덩어리 안의 절차 — 어떤 순서로 처리하면 답이 나오는지 정한다. 이것이 알고리즘이며 6·7차시에서 다룬다.
3. 자료를 어떤 모양으로 담을지 — 값 하나로 둘지, 목록으로 둘지, 표로 둘지 정한다.

설계는 언어와 무관하게 할 수 있다. 순서도와 의사 코드로 그린 설계는 Python으로도 C로도 옮길 수 있다. 그래서 설계를 제대로 해 두면 언어를 바꿔도 다시 하지 않는다.

3단계 · 구현 — 코드로 옮긴다

구현(implementation) — 설계한 내용을 실제 프로그래밍 언어의 코드로 옮기는 단계은 설계를 코드로 옮겨 적는 단계다. 이 단계에서 처음으로 편집기를 열고 문법을 쓴다.

설계가 충분하면 구현은 번역에 가까운 일이 된다. 반대로 설계가 부족하면 코드를 쓰다가 멈추고 “그다음에 뭘 해야 하지”를 고민하게 된다. 구현 중에 자꾸 막힌다면 설계로 돌아가야 한다는 신호다.

4단계 · 테스트 — 제대로 되는지 확인한다

테스트(test) — 프로그램이 요구 사항대로 동작하는지 확인하는 단계는 만든 프로그램이 요구 사항을 지키는지 확인하는 단계다. “실행해 보니 되네”는 테스트가 아니다. 테스트는 미리 정한 입력을 넣고 미리 정한 결과가 나오는지 대조하는 일이다.

여기서 확인해야 할 것은 두 가지다. 프로그램이 해야 할 일을 하는가, 그리고 하면 안 되는 일을 하지 않는가. 빈 값을 넣었을 때, 아주 큰 수를 넣었을 때, 숫자 자리에 글자를 넣었을 때도 프로그램이 무너지지 않아야 한다. 테스트를 어떻게 나눠 하는지는 5차시에서 다룬다.

5단계 · 유지 보수 — 만든 뒤가 더 길다

유지 보수(maintenance) — 완성한 프로그램을 고치고 기능을 더하며 계속 쓸 수 있게 관리하는 단계는 프로그램을 넘긴 뒤에 시작한다. 그리고 앞의 네 단계를 합친 것보다 오래 이어진다.

유지 보수에서 하는 일은 세 가지다. 뒤늦게 발견된 잘못을 고치는 일, 새로 생긴 요구를 반영하는 일, 그리고 바뀐 환경에 맞추는 일이다. 운영체제가 바뀌고 법이 바뀌고 학교 학사 일정이 바뀐다. 프로그램은 그때마다 손을 봐야 한다.

단계마다 무엇이 남는가

각 단계는 다음 단계가 쓸 결과물을 남긴다. 남는 것이 없으면 그 단계를 한 것이 아니다.

개발 단계별 하는 일과 산출물

단계	하는 일	남는 산출물
1. 요구 사항 분석	무엇을 만들지, 무엇을 만들지 않을지 정한다	요구 사항 명세서 — 기능 목록, 입력과 출력, 제약 조건
2. 설계	구조와 절차, 자료의 모양을 정한다	구조도, 순서도 또는 의사 코드, 화면 초안
3. 구현	설계를 코드로 옮긴다	소스 코드, 코드 안의 주석
4. 테스트	정한 입력으로 정한 결과가 나오는지 대조한다	테스트 계획서와 결과 기록, 발견한 오류 목록
5. 유지 보수	고치고 기능을 더하며 환경 변화에 맞춘다	수정 이력, 갱신된 문서와 코드

절차는 한 방향으로만 흐르지 않는다

다섯 단계를 순서대로 한 번씩 지나가는 방식을 폭포수 모형이라 한다. 물이 위에서 아래로만 떨어지듯 앞 단계로 돌아가지 않는다는 뜻이다. 이해하기 쉽지만 현실과 잘 맞지 않는다. 요구 사항이 처음부터 완벽하게 정해지는 일은 드물기 때문이다.

그래서 실제로는 작게 한 바퀴를 여러 번 돈다. 핵심 기능만 다섯 단계로 만들어 확인받고, 거기에 기능을 하나 더해 다시 다섯 단계를 돈다. 이렇게 하면 잘못된 요구 사항을 일찍 발견한다. 앞의 그림에서 되돌아가는 점선이 이 흐름이다.

• 한 번에

  폭포수 방식

  요구 사항을 모두 정한 뒤 순서대로 한 번 지나간다. 이해하기 쉽지만 늦게 발견한 잘못을 되돌리기 어렵다.

• 여러 번

  반복 방식

  작은 기능 단위로 다섯 단계를 되풀이한다. 잘못을 일찍 발견하고 방향을 고칠 수 있다.

활동

조사

작은 프로그램 하나를 절차에 따라 계획서로 정리하기

약 20분

아래 주제 중 하나를 고른다. 코드는 쓰지 않는다. 1·2단계만 종이에 정리한다.

• 시험 점수 다섯 개를 넣으면 평균과 최고점을 알려 주는 프로그램
• 우리 반 자리를 무작위로 정해 주는 프로그램
• 동아리 회비 납부 여부를 관리하는 프로그램

정리 항목은 다음과 같다.

1. 누가 쓰는가 — 한 문장.
2. 입력 — 무엇을 몇 개 받는가. 값의 범위까지 적는다.
3. 출력 — 무엇을 어떤 형태로 보여 주는가.
4. 하지 않을 일 — 이 프로그램이 다루지 않는 일 두 가지.
5. 덩어리 나누기 — 프로그램을 기능별로 2~4 덩어리로 나누고 각 덩어리의 할 일을 한 줄로 적는다.

정리한 뒤 짝과 종이를 바꾼다. 짝의 계획서만 보고 그 프로그램이 무엇을 하는지 말할 수 있는지 확인한다. 말할 수 없다면 요구 사항이 덜 적힌 것이다.

개념 확인 문제

보기를 누르면 바로 채점된다. 틀려도 해설을 읽으면 된다.

프로그램 개발 절차를 순서대로 바르게 나열한 것은?프그01-02

1. 1설계 → 요구 사항 분석 → 구현 → 테스트 → 유지 보수
2. 2요구 사항 분석 → 설계 → 구현 → 테스트 → 유지 보수
3. 3구현 → 테스트 → 요구 사항 분석 → 설계 → 유지 보수
4. 4요구 사항 분석 → 구현 → 설계 → 유지 보수 → 테스트

요구 사항 분석 단계에서 남는 산출물로 알맞은 것은?프그01-02

1. 1소스 코드
2. 2기능 목록과 입력·출력, 제약 조건을 적은 명세서
3. 3컴파일된 실행 파일
4. 4테스트 결과 기록

개발 과정에서 잘못을 발견하는 시점과 고치는 비용의 관계로 알맞은 것은?프그01-02

1. 1언제 발견하든 고치는 비용은 같다
2. 2늦게 발견할수록 고치는 비용이 커진다
3. 3늦게 발견할수록 고치는 비용이 작아진다
4. 4비용은 발견 시점과 무관하게 코드 줄 수로만 정해진다

[OX] 설계 단계는 사용할 프로그래밍 언어를 먼저 정해야 시작할 수 있다.프그01-02

1. 1⭕ 그렇다
2. 2❌ 아니다

구현 중에 자꾸 손이 멈추고 '다음에 무엇을 해야 하지'를 고민하게 된다. 가장 알맞은 대응은?프그01-02

1. 1더 빠른 컴퓨터로 바꾼다
2. 2다른 프로그래밍 언어로 바꿔 다시 쓴다
3. 3설계 단계로 돌아가 절차를 정리한다
4. 4테스트를 먼저 끝낸 뒤 구현을 마친다

더 알아보기

심화프로그램의 값은 만들 때보다 쓰는 동안 더 든다

소프트웨어를 만드는 데 드는 전체 비용 가운데 절반을 넘는 부분이 유지 보수 단계에서 나간다고 알려져 있다. 만드는 기간은 몇 달이지만 쓰는 기간은 몇 년에서 몇십 년이기 때문이다. 그래서 개발에서 “빨리 만들기”보다 “고치기 쉽게 만들기”를 더 중요하게 보는 판단이 많다. 코드 이름을 알아보기 쉽게 짓는 일, 기능을 덩어리로 나누는 일이 그런 판단에 든다.

심화요구 사항을 캐묻는 일도 기술이다

“학생 명단을 정리하는 프로그램을 만들어 주세요”라는 말만으로는 만들 수 없다. 몇 명인지, 어떤 항목이 있는지, 정렬 기준이 무엇인지, 결과를 화면으로 볼지 파일로 받을지 물어야 한다. 요구하는 사람도 자기가 무엇을 원하는지 정확히 모르는 경우가 많다. 그래서 화면 초안을 종이에 그려 보여 주고 “이런 뜻입니까”라고 확인하는 방법이 자주 쓰인다. 말로 주고받은 요구 사항보다 그림 한 장이 오해를 훨씬 줄인다.

진로이 절차는 프로그램 밖에서도 쓴다

요구 사항을 정하고, 설계하고, 만들고, 확인하고, 고쳐 쓰는 흐름은 프로그램만의 것이 아니다. 학교 축제를 기획하는 일, 동아리 홍보물을 만드는 일, 실험을 계획하는 일에도 그대로 들어맞는다. 무엇을 할지 정하지 않고 시작하면 되돌리는 값이 크다는 원리는 같기 때문이다. 이 단원에서 배우는 절차 감각은 개발자가 되지 않더라도 남는다.