- 실생활·다양한 학문 분야의 문제를 해결하는 프로그램을 모둠원과 협력하여 설계·구현할 수 있다.
- 테스트 케이스로 프로그램의 정확성을, 시간 측정으로 효율성을 평가할 수 있다.
- 평가 결과를 반영해 프로그램을 개선하고, 결과물을 공유할 수 있다.
생각 열기 — 소프트웨어는 팀 스포츠
여러분이 매일 쓰는 앱 중에 한 사람이 혼자 만든 것은 거의 없습니다. 수십~수백 명이 기능을 나눠 맡고, 서로의 코드를 검토하고, 테스트로 품질을 지키며 만들어요. 그래서 이번 차시의 주인공은 문법이 아니라 '함께 만드는 방법'과 '잘 만들었는지 확인하는 방법'입니다. 1차시의 분해 트리가 드디어 진짜 임무 분담표가 되는 순간!
프로젝트의 지도 — 우리가 이미 가진 부품들
단계를 눌러 보세요. 모든 단계를 이미 배웠습니다!
문제 정의·분해
무엇을, 누구를 위해?
설계
데이터와 알고리즘 결정
분담·구현
나눠 맡아 코드로!
평가·개선
정확성과 효율성 검사
공유
발표하고 피드백 받기
모둠과 함께 항목을 채우고 [계획서 생성] — 완성된 계획서로 선생님의 승인을 받고 출발하세요!
| 해결할 문제 | |
| 역할 분담 | |
| 사용 기술 | |
| 테스트 계획 |
성능 평가 ① — 정확한가? 테스트 케이스
"되는 것 같다"와 "된다"는 다르다
프로그램이 정확한지는 느낌이 아니라 테스트 케이스로 확인합니다 — "이 입력을 넣으면 이 출력이 나와야 한다"를 여러 개 만들어 한꺼번에 검사하는 거예요. 특히 경계값(0, 최댓값, 빈 입력)과 특이 케이스를 노리는 것이 프로의 기술!
1900년 테스트가 ❌로 빨갛게 빛나는 순간 — 기분 나빠할 일이 아니라 축하할 일이에요. 사용자가 만나기 전에 버그를 먼저 찾아 준 거니까요. 실제 기업에서는 코드보다 테스트를 먼저 쓰는 개발 방법(테스트 주도 개발, TDD)까지 있답니다.
성능 평가 ② — 빠른가? 시간 측정과 개선
같은 답이라도 더 좋은 풀이가 있다
평가가 끝났다면 개선 → 재평가의 반복입니다. 그리고 마지막은 공유 — 모둠 발표에서는 결과 시연만큼 "어떤 테스트를 만들었고, 무엇이 실패했고, 어떻게 고쳤는가"의 여정을 보여 주세요. 그것이 평가 루브릭의 핵심이기도 합니다!
프로젝트를 마치면(또는 중간 점검 때) 스스로, 그리고 다른 모둠의 발표를 들으며 체크해 보세요. 선택은 자동 저장됩니다.
① 문제가 실생활·학문 분야와 연결되어 있고, 작은 기능들로 잘 분해되었다
② 모둠원 모두가 역할을 맡아 실제로 기여했다 (협력)
③ 테스트 케이스로 정확성을 검사했고, 실패를 찾아 개선했다
④ 과정(분해→설계→구현→평가)이 발표에 잘 드러났고 피드백을 주고받았다 (공유)
확인 문제
바로바로 채점! 해설까지 꼭 읽어 보세요.
9차시 확인 문제
4문항 · 즉시 채점
1프로그램의 정확성을 검사하기 위한 '입력과 기대 출력의 쌍'을 무엇이라고 하는가?
2테스트 케이스를 만들 때 가장 중요한 태도는?
3합계 문제의 풀이 A(반복)와 풀이 B(공식)가 같은 답을 냈다. 두 풀이의 차이를 평가하는 기준은?
4모둠 협력 개발의 방법으로 가장 적절한 것은?
더 알아보기
교육과정 너머, 궁금한 만큼 깊이!
문화전 세계가 한 팀 — 오픈소스와 공유의 힘
여러분이 쓰는 파이썬 자체가 오픈소스 — 소스 코드가 공개되어 누구나 보고, 고치고, 기여할 수 있는 소프트웨어입니다. 안드로이드, 리눅스, 이 교과서의 시뮬레이터들이 쓰는 웹 기술까지, 현대 IT의 토대 대부분이 전 세계 개발자들의 자발적 협력으로 만들어졌어요.
고등학생도 참여할 수 있냐고요? 물론! 오픈소스 프로젝트의 문서 오타 수정부터 시작해 코드 기여로 나아간 한국 고등학생들의 사례가 적지 않아요. '공유와 협력의 문화'는 교과서 속 덕목이 아니라, 소프트웨어 세계가 실제로 굴러가는 방식입니다.
리눅스 커널
전 세계 서버와 안드로이드의 심장. 2005년 이후 누적 기여자 약 2만 명, 참여 회사 1,400곳 이상 수준의 초대형 협업!
파이썬
여러분이 지금 쓰는 그 언어. 한 사람의 취미 프로젝트로 시작해, 누적 기여자 수천 명의 공동 작품이 되었어요.
깃허브(GitHub)
오픈소스의 광장. 개발자 계정 1억 개 이상(2023년 발표) — 문서 오타 수정 한 줄도 훌륭한 첫 기여입니다!
도구"어제 코드로 돌려줘!" — 버전 관리와 깃(Git)
협력 개발의 최대 난제 — "네가 고친 게 내 코드를 덮어썼어!" 이를 해결하는 도구가 버전 관리 시스템, 그중 사실상 표준이 깃(Git)입니다.
- 모든 변경 이력이 저장되어 언제든 과거로 되돌릴 수 있어요 (게임 세이브처럼!)
- 각자 자기 복사본에서 작업한 뒤 병합(merge) — 서로의 작업을 덮어쓰지 않아요
- 깃허브(GitHub) 같은 사이트에 올리면 전 세계와 공유할 수 있어요
지금은 "이런 도구가 있다"만 기억해 두세요 — 소프트웨어 동아리나 진로 선택 과목에서 만나면 바로 친해질 수 있게!
말로만 들으면 아쉬우니, 커밋(저장)과 되돌리기를 미니 깃에서 체험해 보세요.
문화내 코드를 남이 읽는다 — 코드 리뷰 문화
구글, 네이버, 카카오… 어떤 회사든 코드가 제품에 들어가려면 반드시 동료의 검토(코드 리뷰)를 통과해야 해요. 버그를 잡는 것도 목적이지만, 더 큰 목적은 지식의 공유 — 리뷰를 주고받으며 팀 전체가 함께 성장합니다.
모둠 활동에서도 해 보세요. 규칙은 세 가지: ① 사람이 아니라 코드에 대해 말한다("네가 틀렸어" ❌ → "이 변수 이름은 어떤 의미야?" ⭕) ② 칭찬 하나, 제안 하나는 꼭 ③ 받은 제안은 일단 시도해 본다. 단원 도입의 토론 예절과 똑같죠 — 코드 리뷰는 디지털 민주시민의 대화법입니다.
def c(a):
t = 0
for i in a:
t = t + i
return t / len(a)
c만 보고는 무슨 일을 하는지 알 수 없어요. average는 어때요?len(a)가 0이라 나누기 오류가 나요! (경계값 테스트가 잡아낸 버그)def average(scores):
if len(scores) == 0: # 빈 리스트 보호!
return 0
return sum(scores) / len(scores)
sum() 활용 멋져요!도전주말 동안 세상을 바꾸는 대회 — 해커톤
해커톤(hackathon) = 해킹(만들기) + 마라톤. 팀을 짜서 1~2일 안에 아이디어를 동작하는 프로토타입으로 만들어 내는 대회예요. 오늘 배운 사이클(정의→설계→분담→구현→평가→공유)을 압축적으로 경험할 수 있는 최고의 무대죠.
고등학생이 참가할 수 있는 대회도 많아요 — 교육부·과기부 주최 SW 동행 해커톤, 지역 교육청 해커톤, 공공데이터 활용 경진대회(2단원!) 등. 수상보다 값진 것은 "우리 팀이 무언가를 끝까지 만들어 봤다"는 경험. 이번 모둠 프로젝트가 그 첫 리허설입니다!
해커톤의 하루 반 — 오늘 배운 프로젝트 사이클이 그대로 들어 있다
한눈에 정리
- 프로젝트 사이클: 정의·분해 → 설계 → 분담·구현 → 평가·개선 → 공유 — 1~8차시가 모두 부품!
- 협력의 기본: 분해 트리로 역할 분담 + 이름 약속 + 짝 프로그래밍·코드 리뷰
- 정확성 평가 = 테스트 케이스 (경계값·함정을 노려라, 실패는 선물!)
- 효율성 평가 = 시간 측정 — 같은 답이라도 풀이의 효율은 하늘과 땅
- 평가 → 개선 → 재평가의 반복, 그리고 과정을 공유하는 발표가 마침표