- 인공지능 문제 해결 과정의 단계를 설명할 수 있다.
- 문제 해결 과정에 따라 프로젝트 수행 계획을 세울 수 있다.
- 데이터·일정·역할을 포함한 구체적 계획을 구안할 수 있다.
생각 열기 — 설계도 없이 지은 집
설계도 없이 집을 지으면 어떻게 될까요? 벽을 세우다 문 위치를 바꾸고, 지붕을 올리다 기둥이 모자라고… 결국 무너지거나 끝나지 않죠. AI 프로젝트도 마찬가지예요. "일단 만들어 보자"로 시작하면 데이터가 없어서, 목표가 흐릿해서, 시간이 모자라서 길을 잃기 쉬워요.
다행히 우리에겐 검증된 설계도가 있어요 — 바로 2단원에서 배운 인공지능 문제 해결 과정이에요. 이 과정을 뼈대 삼아 계획을 세우면, 무엇을 언제 해야 할지 또렷해집니다.
1차시에서 정한 프로젝트 주제를 떠올려 보세요. 그 AI를 만들려면 어떤 데이터가 필요할까요? 그 데이터를 정말 구할 수 있을까요? 계획 단계에서 이걸 미리 따져 보지 않으면 어떻게 될까요?
프로젝트의 뼈대 — 인공지능 문제 해결 과정
2단원에서 배운 그 흐름
인공지능 프로젝트는 정해진 단계를 따라가요. 2단원의 'AI 기르는 5단계'를 기억하나요? 그것이 곧 프로젝트의 흐름이에요.
중요한 건 이 과정이 한 방향 직선이 아니라 순환이라는 점이에요. 평가해 보고 부족하면 데이터를 더 모으거나 모델을 바꿔 다시 돌리죠(4차시에서 자세히!). 계획을 세울 때도 이 다섯 단계를 빠짐없이 생각해야 해요.
나의 프로젝트 계획 캔버스
설계도를 직접 채워 보기
이제 직접 계획을 세워 봐요. 아래 캔버스의 각 칸을 채우면 프로젝트 설계도가 완성됩니다. [예시 채우기]로 작성 예를 먼저 본 뒤, 내 주제로 바꿔 보세요. 작성한 계획은 이 브라우저에 저장돼요.
계획을 탄탄하게 — 놓치기 쉬운 것들
데이터·일정·위험 대비
데이터부터 확인
프로젝트 성패는 데이터에서 갈려요. "이 데이터를 정말 구할 수 있나?"를 가장 먼저 확인하세요.
현실적인 일정
늘 생각보다 오래 걸려요. 단계마다 여유를 두고, 안 되면 주제를 더 줄일 각오도.
위험 미리 대비
"데이터가 부족하면?", "모델 성능이 낮으면?" — 플랜 B를 미리 생각해 두세요.
소프트웨어 개발에는 MVP(Minimum Viable Product, 최소 기능 제품)라는 지혜가 있어요. 처음부터 완벽한 걸 만들려 하지 말고, '가장 핵심 기능만 담은 가장 작은 버전'을 먼저 끝까지 만들어 보라는 거예요. 잔반 예측이라면, 거창한 앱 대신 '요일만 보고 잔반량을 대략 예측하는 아주 단순한 모델'부터 완성하는 거죠. 작동하는 작은 버전이 있으면, 거기서부터 하나씩 개선할 수 있어요(4차시!). 완성된 작은 것이 미완성의 거대한 것을 이긴다 — 이것이 모든 프로젝트의 황금률입니다.
확인 문제
바로바로 채점!
2차시 확인 문제
4문항 · 즉시 채점
1인공지능 프로젝트 수행 과정의 순서로 올바른 것은?
2인공지능 문제 해결 과정의 특징으로 옳은 것은?
3프로젝트 계획에서 가장 먼저 현실성을 확인해야 할 것은?
4[OX] 프로젝트는 처음부터 모든 기능을 완벽히 갖춘 큰 버전을 목표로 하는 것이 좋다.
더 알아보기
교과서 너머의 이야기 — 클릭해서 펼쳐 보세요
방법데이터를 어떻게 모을까 — 수집의 세 가지 길
계획에서 가장 막막한 게 데이터예요. 데이터를 구하는 길은 크게 셋이에요. ① 직접 만들기: 설문, 측정, 사진 촬영으로 우리가 직접 모아요(예: 우리 학교 잔반 매일 기록). 우리 문제에 딱 맞지만 시간이 들죠. ② 공개 데이터 활용: 공공데이터포털(data.go.kr), 기상청, 캐글(Kaggle) 같은 곳에 무료로 열린 데이터가 많아요(정보 2단원에서 배웠죠!). ③ 기존 데이터셋 빌리기: 교육용으로 공개된 표준 데이터셋 (손글씨 숫자 MNIST 등)으로 연습할 수 있어요. 중요한 건 계획 단계에서 미리 '구할 수 있는 데이터'에 맞춰 주제를 정하는 것이에요. 멋진 주제라도 데이터가 없으면 만들 수 없으니, 가끔은 '있는 데이터'에서 거꾸로 주제를 찾는 것도 현명한 방법이랍니다.
협업혼자 말고 함께 — 좋은 팀의 역할 분담
AI 프로젝트는 혼자보다 팀으로 할 때 더 멀리 가요(3차시의 협력!). 좋은 팀은 역할을 잘 나눠요 — 누군가는 데이터 수집·정리, 누군가는 모델 제작, 누군가는 발표·문서화를 맡죠. 하지만 역할을 나눈다고 '내 것만' 하면 안 돼요. 좋은 팀의 비결은 ① 자주 소통하기(짧게 자주 만나 진행 상황 공유), ② 기록 남기기(누가 무엇을 했는지, 왜 그렇게 정했는지), ③ 서로 돕기 (막힌 사람을 함께 도와주기)예요. 실제 IT 회사들도 이런 방식으로 일해요 — 매일 짧게 모여 진행을 나누는 '스탠드업 미팅', 작업을 카드로 관리하는 '칸반 보드'처럼요. 좋은 협업은 좋은 코드만큼 중요한 실력이고, 이 협업 경험 자체가 프로젝트의 큰 배움입니다.
심화계획대로 안 될 때 — 애자일(Agile)의 생각법
아무리 잘 세운 계획도 그대로 되는 경우는 드물어요. 데이터가 예상과 다르고, 모델 성능이 안 나오고, 시간이 모자라죠. 그래서 현대의 소프트웨어 개발은 '애자일(Agile)'이라는 생각법을 써요 — 처음에 완벽한 계획을 다 세우고 그대로 따르기보다, 짧은 주기로 만들고-점검하고-고치기를 반복하며 계획을 유연하게 다듬는 거예요. 한 번에 큰 계획을 세워 6개월 뒤 완성하는 대신, 2주마다 작동하는 작은 버전을 만들어 가는 식이죠(MVP와 통해요!). 학교 프로젝트에도 이 생각법이 도움이 돼요 — 계획은 '바뀔 수 있는 출발점'이지 '반드시 지켜야 할 족쇄'가 아니에요. 막히면 멈춰서 다시 계획을 조정하는 것도 실력입니다. 중요한 건 계속 앞으로 나아가며 배우는 것이니까요.