무엇을 만들지 정하기 — 기획과 요구 사항 도출

생각 열기 — “뭔가 멋진 걸 만들자”

모둠에서 프로그램을 하나 만들기로 했다. 첫 회의에서 이런 말이 오간다.

“학교 생활을 편하게 해 주는 앱을 만들자.” “AI도 넣으면 좋겠는데.” “일단 화면부터 예쁘게 만들어 볼까?”

한 시간이 지났는데 아무것도 정해지지 않았다.

기획 — 만들 것의 크기를 정하는 일

기획(planning) — 무엇을 왜 만드는지 정하고, 만들 범위와 조건을 확정하는 일은 개발 절차의 첫 단계다. 1단원 4차시에서 요구 사항 분석을 다뤘는데, 기획은 그보다 한 걸음 앞이다. 요구 사항을 분석하기 전에, 무엇에 대한 요구 사항인지를 정해야 하기 때문이다.

기획에서 답해야 할 질문은 넷이다.

• 질문 1

  누가 쓰는가

  쓰는 사람이 정해지지 않으면 무엇이 편한지 판단할 수 없다. "학생"보다 "우리 반 총무"처럼 좁힐수록 좋다.

• 질문 2

  어떤 불편을 없애는가

  지금 그 사람이 무엇 때문에 시간을 쓰거나 실수하는지 하나만 고른다.

• 질문 3

  무엇을 넣고 무엇을 뺄 것인가

  넣을 기능 목록보다 빼는 기능 목록이 프로그램의 크기를 정한다.

• 질문 4

  무엇을 지켜야 하는가

  시간·환경·개인정보처럼 반드시 지켜야 할 조건을 미리 확인한다.

사용자를 먼저 좁힌다

“학교 생활을 편하게”가 막막한 이유는 누구의 학교 생활인지 정하지 않아서다. 사용자를 좁히면 요구 사항이 저절로 구체적으로 바뀐다.

사용자를 좁히면 요구 사항이 구체적으로 바뀐다

막연한 사용자	좁힌 사용자	그때 드러나는 요구 사항
학생	체육 대회 기록을 적는 학생	종목별 기록을 넣으면 반별 순위가 나오면 좋겠다
학생	동아리 회비를 걷는 총무	누가 냈는지 표시하고 미납자만 뽑아 보고 싶다
선생님	수행평가 점수를 정리하는 담임	점수를 넣으면 평균과 최고·최저가 바로 나오면 좋겠다

요구 사항을 끌어내는 네 가지 방법

요구 사항 도출(requirements elicitation) — 쓰는 사람에게서 프로그램이 해야 할 일을 끌어내는 활동은 그냥 물어본다고 되지 않는다. 쓰는 사람도 자기가 무엇을 원하는지 정확히 모르는 경우가 많기 때문이다. 그래서 방법을 나눠 쓴다.

① 물어보기 — 면담

가장 먼저 하는 일이다. 다만 “뭐가 필요하세요?“라고 묻지 않는다. 그렇게 물으면 대부분 “글쎄요”라는 답이 돌아온다. 대신 지금 하고 있는 일을 묻는다.

• “지금은 그 일을 어떻게 하고 계세요?”
• “그중 가장 시간이 오래 걸리는 건 뭔가요?”
• “실수가 자주 나는 곳이 있나요?”

② 지켜보기 — 관찰

말로 나오지 않는 요구가 있다. 총무가 회비 장부를 볼 때마다 종이를 넘겨 가며 같은 이름을 세 번 찾는다면, 그 사람은 그것을 불편이라고 말하지 않아도 불편한 것이다. 익숙해진 불편은 말로 안 나온다.

③ 설문

여러 사람에게 같은 것을 물어 공통점을 찾는다. 한 사람의 취향인지 여럿의 필요인지 가릴 수 있다. 다만 설문은 묻지 않은 것은 절대 나오지 않는다. 면담이나 관찰로 후보를 먼저 찾은 뒤에 쓰는 것이 좋다.

④ 비슷한 프로그램 살펴보기

이미 있는 프로그램을 써 보면 “이건 좋다”, “이건 우리에게 필요 없다”가 빠르게 갈린다. 무엇을 빼도 되는지 알아내는 데 특히 도움이 된다.

제약 조건을 미리 확인한다

1단원 5차시에서 다룬 제약 조건은 기획 단계에서 확인해야 한다. 늦게 알면 만든 것을 버려야 하기 때문이다. 학교에서 프로그램을 만들 때 자주 걸리는 조건은 다음과 같다.

기획 단계에서 미리 확인할 제약 조건

조건	확인할 것	늦게 알면 생기는 일
시간	수업 몇 차시 안에 끝내야 하는가	기능을 절반만 만든 채 끝난다
환경	학교 컴퓨터에 새 프로그램을 설치할 수 있는가	집에서만 돌아가는 프로그램이 된다
인터넷	전산실에서 외부 접속이 되는가	접속이 막혀 아무것도 못 한다
개인정보	실제 이름·학번을 다뤄도 되는가	만든 뒤에 쓸 수 없다는 답을 듣는다
실력	지금 아는 문법으로 만들 수 있는가	구현 단계에서 손이 멈춘다

개인정보 조건은 특히 중요하다. 1단원 9차시에서 다룬 대로 실제 학생 이름과 학번은 코드나 자료 파일에 넣지 않는다. 이 단원의 프로젝트에서도 시험용 자료는 지어낸 값으로만 만든다.

크기를 줄이는 것이 기획이다

기획을 처음 하면 기능이 계속 늘어난다. 회비 관리 프로그램에 로그인, 알림, 통계, 그래프까지 붙이다 보면 한 학기에 못 끝낸다.

그래서 기능을 세 갈래로 나눈다.

• 반드시

  이게 없으면 프로그램이 아니다

  핵심 기능 2~3개. 이것만으로도 쓸 수 있어야 한다.

• 있으면 좋음

  시간이 남으면 붙인다

  먼저 만들지 않는다. 핵심이 돌아간 뒤에 검토한다.

• 하지 않음

  이번에는 만들지 않는다

  적어 두는 것이 중요하다. 적어 두지 않으면 회의 때마다 다시 올라온다.

이 단원에서 만들 것

이 단원은 아홉 차시에 걸쳐 하나의 프로그램을 끝까지 만든다. 기획 → 명세 → 설계 → 알고리즘 → 구현 → 통합 → 테스트 → 수정의 한 바퀴를 실제로 돌아 본다.

본문에서 함께 따라갈 예시는 반 성적 정리 프로그램이다. 1단원 5차시 생각 열기에 나왔던, 3주를 들여 만들었는데 요구 사항이 어긋나 있던 그 프로그램이다. 이번에는 절차를 밟아 제대로 만들어 본다.

예시 프로젝트의 기획 — 네 가지 질문에 답한 결과

질문	답
누가 쓰는가	수행평가 점수를 정리하는 담임 교사. 한 학기에 여러 번, 반마다 한 번씩 쓴다
어떤 불편을 없애는가	점수를 손으로 더해 평균을 내다가 실수가 난다. 잘못 입력된 점수를 눈으로 찾아야 한다
반드시 넣을 것	① 점수 목록을 받는다 ② 잘못된 점수를 걸러 낸다 ③ 인원·평균·최고·최저를 보여 준다
있으면 좋음	등급 나누기, 결과를 파일로 저장하기
하지 않을 것	학생 이름 관리, 성적표 출력, 여러 반 동시 처리
제약 조건	전산실 컴퓨터에서 설치 없이 실행. 실제 이름·학번은 쓰지 않는다. 4차시 안에 구현을 끝낸다

기능이 셋뿐이다. 작아 보이지만 작게 잡아야 끝까지 간다. 남는 시간에 “있으면 좋음”을 붙이는 편이, 크게 잡았다가 절반에서 멈추는 것보다 낫다.

활동

프로젝트

우리 반의 불편함에서 만들 프로그램 주제 찾기

약 40분

모둠별로 이 단원 내내 만들 프로그램의 주제를 정한다. 이번 차시에는 코드를 쓰지 않는다.

1단계 — 불편을 모은다 (10분)

각자 종이에 학교에서 반복해서 하는 일 중 귀찮거나 실수가 나는 것을 세 가지 적는다. “재미있는 앱”이 아니라 이미 하고 있는 일에서 찾는다.

2단계 — 관찰로 확인한다 (10분)

모은 것 중 하나를 골라, 실제로 그 일을 하는 사람에게 지금 어떻게 하는지 물어본다. 물을 수 없으면 직접 그 일을 한 번 해 보며 어디서 시간이 걸리는지 표시한다.

• 이 일을 얼마나 자주 하는가
• 한 번에 얼마나 걸리는가
• 어디서 실수가 나는가

3단계 — 네 가지 질문에 답한다 (10분)

질문	우리 모둠의 답
누가 쓰는가 (한 문장으로 좁혀서)
어떤 불편을 없애는가
반드시 넣을 기능 2~3개
있으면 좋은 기능
하지 않을 기능 2개
제약 조건 (시간·환경·개인정보)

4단계 — 크기를 점검한다 (10분)

옆 모둠과 표를 바꿔 읽고 서로 확인한다.

• “반드시 넣을 기능”이 넷 이상이면 줄이라고 말해 준다.
• “하지 않을 기능”이 비어 있으면 채우라고 말해 준다.
• 사용자가 “학생”, “선생님”처럼 넓으면 좁히라고 말해 준다.

정한 주제는 다음 차시에서 요구 사항 명세서로 옮긴다. 주제는 바꿀 수 있지만 늦어질수록 손해다. 오늘 안에 정한다.

개념 확인 문제

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

프로그램 기획 단계에서 가장 먼저 정해야 할 것은?프그03-01

1. 1사용할 프로그래밍 언어
2. 2누가 쓰는가와 어떤 불편을 없애는가
3. 3화면의 색과 글꼴
4. 4코드를 몇 줄로 만들 것인가

요구 사항을 끌어낼 때 면담에서 던지기에 가장 적절하지 않은 질문은?프그03-01

1. 1지금은 그 일을 어떻게 하고 계세요?
2. 2그중 가장 시간이 오래 걸리는 건 뭔가요?
3. 3실수가 자주 나는 곳이 있나요?
4. 4어떤 프로그램이 필요하세요?

관찰이 면담보다 잘 드러내는 것은?프그03-01

1. 1사용자가 왜 그렇게 하는지에 대한 이유
2. 2여러 사람에게 공통된 요구
3. 3익숙해져서 말로는 나오지 않는 불편
4. 4프로그램에 필요한 예산

기획에서 '하지 않을 기능' 목록을 문서에 적어 두는 이유로 가장 알맞은 것은?프그03-01

1. 1적어 두면 나중에 자동으로 만들어지기 때문이다
2. 2같은 논의가 회의 때마다 되풀이되는 것을 막기 때문이다
3. 3기능을 적을수록 점수가 높기 때문이다
4. 4프로그램의 실행 속도가 빨라지기 때문이다

[OX] 제약 조건은 프로그램을 다 만든 뒤에 확인해도 늦지 않다.프그03-01

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

더 알아보기

실무사용자가 말한 것과 진짜 필요한 것

개발 현장에는 “사용자는 더 빠른 말을 원한다고 말하지만 실제로 필요한 것은 자동차였다”는 식의 이야기가 오래 돌아다닌다. 요점은 사용자가 말한 해결책을 그대로 만들지 말고, 그 뒤에 있는 문제를 찾으라는 것이다. “엑셀에 자동 계산 기능을 넣어 달라”는 요구를 들었다면, 진짜 문제는 “매번 손으로 더하다 실수가 난다”일 수 있다. 그렇다면 해결책은 엑셀이 아니어도 된다. 요구를 들으면 한 번 더 “왜요?“를 물어 보는 습관이 여기서 나온다.

심화기능 요구와 비기능 요구

요구 사항은 두 갈래로 나뉜다. “점수를 넣으면 평균이 나온다”처럼 무엇을 하는가에 대한 것이 기능 요구다. “300명 자료를 3초 안에 처리한다”, “설치 없이 브라우저에서 돌아간다”처럼 어떤 조건을 지키는가에 대한 것이 비기능 요구다. 기능 요구는 빠뜨리면 바로 티가 나지만, 비기능 요구는 다 만든 뒤에야 문제가 드러나 되돌리기 어렵다. 다음 차시에서 이 둘을 나눠 적는 방법을 다룬다.

진로기획만 하는 직무가 따로 있다

규모가 큰 개발에서는 무엇을 만들지 정하는 일만 맡는 사람이 따로 있다. 쓰는 사람을 만나 요구를 끌어내고, 만들 범위를 정하고, 개발자와 일정을 맞춘다. 코드를 직접 쓰지 않더라도 무엇이 만들기 쉽고 어려운지 알아야 하므로 프로그래밍을 이해하는 것이 필요하다. 프로그래밍을 배우면 개발자만 되는 것이 아니다 — 만드는 과정을 아는 사람이 필요한 자리가 그 옆에 여럿 있다.