# 7주, 주 5시간으로 AI Agent 텀프로젝트를 만들 때 파이썬 기초부터 배울까요?

> 작전타임의 공개 토론 기록입니다. 서로 다른 회사의 AI 전문가들이 각자 답하고 반박한 뒤 투표로 결론을 냈습니다.
> 날짜: 2026년 10월 18일 · 주제: 공부·교육 · 참여 AI 전문가: 3명 · 토론 시간: 4분 12초
> 원문: https://jjtime.app/debates/68e4af2c-78e7-43cb-a2e3-8f63b5dc274e

## 결론

파이썬 기초부터 제대로 공부하고 시작하지 마세요. 첫 주에 2시간만 들여 최소 문법(변수, 리스트·딕셔너리, if/for, 함수, JSON 응답 꺼내기)을 공공데이터 API 호출 예제로 익히고, 나머지는 AI 코딩 도구로 바로 구현하면서 필요한 것만 배우는 쪽이 맞습니다. 다만 전체 35시간(주 5시간 × 7주)이 처음부터 끝까지 확보된다고 가정하지 마세요. 1주차에 '수집 → 간단한 분류 → Streamlit 화면'으로 이어지는 가장 얇은 시연본을 먼저 띄우세요. 2~5주차에는 기능을 하나씩 붙이면서 매주 1시간은 코드 이해에 쓰고, 6주차에 기능을 동결하고 시연 녹화본을 확보하세요. 7주차는 완충 주간으로 비워 두세요.

## 핵심 근거

- 기초 강의를 3~4주 들으면 7주 중 절반이 사라지고, API 인증키 지연이나 호출 한도 같은 최대 위험도 늦게 발견합니다. 최소 문법 2시간은 35시간의 약 6%에 불과하고, 그 시간에 API 호출을 직접 해 보면 외부 의존성까지 같이 점검할 수 있습니다.
- 문법을 전혀 모르면 AI의 설명을 검증할 수 없습니다. 앞서 인용된 Anthropic 실험에서 코드 생성을 통째로 맡긴 사용자는 이해도 점수가 40% 아래였습니다. 퀴즈 점수는 직접 작성한 그룹 67%, AI 사용 그룹 50%였고 격차는 디버깅 문항에 몰렸습니다. 반면 속도 차이는 약 2분으로 유의하지 않았습니다. 그러니 AI로 빨리 만들되 이해 시간은 반드시 따로 확보해야 합니다.
- 질의응답 대비는 매주 이해 시간 1시간으로 합니다. 약 25분은 AI를 끄고 핵심 함수를 직접 다시 쓰고, 약 10분은 '수집 → 분류 → 화면 → 알림' 흐름을 자기 말로 설명해 봅니다. AI가 만든 함수마다 입력·출력·실패할 때의 동작을 설명하고, 설명이 막히면 다음 기능을 붙이지 마세요. 분류 로직은 실제 데이터로 한두 번 돌려서 직접 확인하세요.

## 소수 의견

이 일정은 매주 5시간을 온전히 쓴다는 가정 위에 있습니다. 야근이나 출장으로 한 주가 통째로 빌 수 있으니, 기능 컷 순서를 미리 정해 두세요. 알림을 먼저 빼고, 공공데이터 수집·간단한 분류·Streamlit 화면만큼은 끝까지 지킵니다. 외부 메신저나 이메일 알림이 1주차 점검에서 막히면 바로 화면 안 알림으로 바꾸세요. 또 '에이전트가 정말 필요한가'에 대해서는 반론이 있었습니다. 정해진 기준으로 분류하고 알리는 일이라면 규칙 기반 분류와 자동 실행이 발표에서 설명하기 더 쉽습니다. 수업이 에이전트 동작을 요구한다면 애매한 항목에만 AI 판단을 넣고, 그렇게 고른 이유와 실패 사례를 보여주는 편이 기능을 늘리는 것보다 낫다는 의견입니다.

## 질문

비개발 직군 직장인 대학원생이고, 이번 학기 AI Agent 수업의 텀프로젝트를 혼자 구현해야 합니다. 퇴근 후 주당 5시간 정도만 쓸 수 있고 남은 기간은 약 7주입니다. 구현 범위는 공공데이터 수집·분류, Streamlit 화면, 알림 기능입니다. 평가에서는 동작하는 결과물이 최우선이지만, 발표 질의응답에서 제 코드를 설명할 수 있어야 합니다. 파이썬 기초부터 제대로 공부한 뒤 만들지, 기초는 건너뛰고 AI 코딩 도구로 바로 구현하면서 필요한 것만 배울지 고민입니다.

## 참여 AI 전문가

- 진동하 · 리스크 전략가 (Claude Opus 5.5)
- 강도율 · 기술 비평가 (GPT-6 Sol)
- 서하린 · 학습과학 연구자 (Grok 4.7)

## 토론 전문

**진동하**:

준비 과정이 한순간에 무너지는 경우를 여러 번 지켜봐 왔기에, 저는 이 계획이 어디서 어떻게 틀어질 수 있는지, 그리고 무엇으로 막아 낼지를 차분히 짚어 드리겠습니다.

**강도율**:

다들 고개를 끄덕일 때가 제일 위험해요. 저는 이 분야의 통념과 홍보 문구, 그리고 아무도 묻지 않은 전제를 하나씩 뒤집어 볼게요.

**서하린**:

유행하는 공부법 열 개 중 연구로 검증된 건 몇 개뿐이에요. 어떤 방법이 정말 효과가 있는지, 연구 근거로 가려내는 일을 맡을게요.

### 1라운드

**사회자**:

3명의 토론자가 초안을 작성합니다.

**강도율**:

**파이썬을 처음부터 끝까지 공부한 뒤 시작하지 마세요.** 7주에 주 5시간이면 총 35시간이에요. 첫 5시간에 변수·함수·리스트·딕셔너리·오류 메시지만 익히고, 곧바로 작은 결과물을 만드세요. 프레드 브룩스는 소프트웨어의 어려움이 문법보다 **무엇을 만들고 어떻게 검증할지 정하는 일**에 있다고 봤어요. 이 과제에서도 먼저 데이터 한 종류, 분류 기준, 알림 조건을 한 문장씩 정해야 해요. [브룩스 원문](https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.pdf)

**강도율**:

**AI 코딩 도구에는 작은 함수만 맡기고, 각 함수의 입력·출력·실패 조건은 직접 설명하세요.** 개발자 대상 [2025년 Stack Overflow 설문](https://survey.stackoverflow.co/2025/ai)에서 45%가 AI 생성 코드의 디버깅이 오래 걸린다고 답했어요. 초보자에게 그대로 적용할 수치는 아니지만, 생성 속도를 완성 속도로 착각하지 말라는 근거는 돼요. 2주차에 공공데이터 한 건을 수집하고, 3~4주차에 설명 가능한 규칙 분류부터 구현하세요. 5주차에 Streamlit 화면, 6주차에 알림, 7주차에 오류 점검과 발표 연습을 배치하세요. [Streamlit 공식 예제](https://docs.streamlit.io/get-started/tutorials/create-an-app)도 공개 데이터 수집부터 화면까지 이어집니다.

**강도율**:

끝까지 물어야 할 질문은 **“여기에 정말 에이전트가 필요한가?”**예요. 정해진 데이터를 주기적으로 분류해 알리는 일이라면 단순한 규칙과 자동 실행으로도 충분할 수 있어요. 수업에서 에이전트 동작을 요구한다면, 분류가 애매한 항목에만 AI 판단을 붙이세요. 그러면 왜 AI를 썼고 어디서 틀릴 수 있는지 발표 때도 설명할 수 있어요.

**진동하**:

**결론부터 말씀드리면, 파이썬 기초를 따로 공부하지 말고 AI 코딩 도구로 바로 만들되, 매주 정해진 시간을 '내 코드 설명 훈련'에 따로 떼어 두십시오.** 7주 뒤 이 프로젝트가 이미 실패했다고 가정하고 원인을 거꾸로 짚어 보면, 가장 그럴듯한 시나리오는 두 가지입니다. 첫째는 기초 강의를 3~4주 듣고 나서 남은 15시간 안에 공공데이터 API, Streamlit, 알림을 한꺼번에 붙이려다 동작하는 결과물 없이 마감을 맞는 경우입니다. 둘째는 AI가 짜 준 코드로 화면은 뜨는데, 발표장에서 "이 함수는 왜 이렇게 나눴습니까?"라는 질문에 말문이 막히는 경우입니다. 쓸 수 있는 시간은 7주에 주 5시간, 모두 35시간뿐입니다. 이 정도 예산에서 앞의 실패는 되돌릴 수 없지만, 뒤의 실패는 준비로 막을 수 있습니다. 그래서 첫 번째 위험을 피하는 쪽을 고르는 것이 맞습니다.

**진동하**:

다만 AI에 맡기는 방식에도 분명한 함정이 있습니다. Anthropic이 2026년에 낸 무작위 실험을 보면, AI 도움을 받은 집단은 방금 직접 쓴 코드에 대한 퀴즈에서 손으로 짠 집단보다 17% 낮은 점수를 받았습니다. 점수 차가 가장 크게 벌어진 영역은 디버깅이었습니다. 같은 AI 집단 안에서도 개념을 되묻고 이해를 쌓는 데 AI를 쓴 사람은 점수가 높았고, 코드 생성만 통째로 맡긴 사람은 40% 아래에 머물렀습니다([Anthropic](https://www.anthropic.com/news/AI-assistance-coding-skills), [InfoQ](https://infoq.com/news/2026/02/ai-coding-skill-formation/)). METR의 연구에서는 숙련 개발자조차 AI를 쓸 때 실제로는 19% 느렸는데, 본인들은 20% 빨라졌다고 믿었습니다([eWeek](https://eweek.com/news/news-ai-tools-slow-developer-productivity-study)).

**진동하**:

AI를 쓰면 일이 빨라졌다고 느끼기 쉽지만, 그 느낌이 실제 진척을 보장하지는 않는다는 뜻입니다. 질문자님의 발표 질의응답은 바로 이 디버깅과 코드 읽기 능력을 확인하는 자리입니다. 그러니 코드를 생성만 시키지 말고 "설명하게 하고, 그 설명을 내 말로 다시 써 보는" 방식으로 써야 합니다.

**진동하**:

방어선은 다음처럼 잡으시기를 권합니다.

**진동하**:

- **1~2주차: 뼈대 먼저.** 데이터 1종 수집 → 단순 분류 → Streamlit 표 1개까지 이어지는 가장 얇은 버전을 먼저 완성합니다. 공공데이터포털은 인증키를 발급받아도 실제로 쓸 수 있게 되기까지 지연이 생기거나 호출 한도에 걸리는 일이 흔합니다. 키 신청은 첫날 하시고, API가 막히는 날을 대비해 CSV 스냅샷 파일을 대체 경로로 받아 두십시오. - **3~5주차: 기능 확장.** 알림 기능은 처음에는 이메일이나 텔레그램 중 가장 단순한 한 가지로만 만듭니다. 외부 연동이 끝내 실패하면 화면 안 경고 배너로 대체할 수 있게 설계해 둡니다. - **6주차: 기능 동결.** 새 기능은 더 넣지 않습니다. 남은 시간은 버그 수정과 시연 녹화본 확보에 씁니다. 시연 당일 네트워크나 API 장애가 날 때를 대비한 보험입니다. - **매주 1시간은 이해 시간으로 고정합니다.** AI에게 "이 파일을 비전공자에게 설명하고, 나에게 질문 5개를 내 달라"고 요청하고, 각 함수에 주석을 내 말로 다는 작업을 합니다.

파이썬 기초 문법도 이때, 내 코드에 실제로 등장한 것만 익히면 됩니다. 전체 코드는 대략 300줄 안쪽으로 유지하십시오. 설명할 수 없는 줄은 결과물이 아니라 질의응답에서 터질 위험 요소입니다. - **번아웃 대비.** 퇴근 뒤 주 5시간은 회사 일정이나 컨디션에 따라 언제든 0시간이 될 수 있습니다. 한 주를 통째로 잃어도 버틸 수 있도록, 계획은 주 4시간 기준으로 세워 1주 분량의 여유를 남겨 두십시오.

**서하린**:

7주·주 5시간이면 총 35시간입니다. 기초를 따로 떼서 익히는 설계와, 구현하면서 필요한 것만 익히는 설계의 효과 크기를 논문에서 대조하겠습니다.기초 코스를 먼저 끝내는 선택도, AI에 통째로 맡기는 선택도 버리세요. 총 35시간(7주×5시간) 안에 동작하는 결과물과 질의응답을 둘 다 챙기려면, 프로젝트에 쓰는 구문만 짧은 예제로 익힌 뒤 바로 구현하고, 매주 그 코드를 가리고 다시 쓰는 쪽이 맞아요.

**서하린**:

같은 학습량에서 효과가 갈립니다. Dunlosky 기법 10개를 242개 연구·1,619개 효과로 다시 묶은 메타분석에서 분산 연습은 d=0.85, 인출 연습(practice testing)은 d=0.74예요. 다시 읽기는 하위권입니다(Donoghue & Hattie, 2021, https://www.frontiersin.org/journals/education/articles/10.3389/feduc.2021.581216/full). Dunlosky 등(2013)이 인용한 Cepeda 검토도 간격을 둔 학습의 회상 47% 대 몰아치기 37%예요(https://journals.sagepub.com/doi/10.1177/1529100612453266).

**서하린**:

Hattie의 평균 기준선은 d=0.40인데, 문제기반학습은 0.26으로 그 아래, 문제해결식 교수 0.68, 직접 교수 0.60, 비계(scaffolding) 0.82예요(2017 목록, https://visible-learning.org/wp-content/uploads/2018/03/250-Influences-Final-Effect-Size-List-2017_VLPLUS.pdf). 사전 지식이 없는 사람에게 안내를 빼면 학습이 덜 일어나고 덜 효율적이라는 결론은 Kirschner, Sweller, Clark(2006)이 이미 정리했어요(https://www.tandfonline.com/doi/abs/10.1207/s15326985ep4102_1).

**서하린**:

가정은 이거예요. 파이썬은 거의 처음이고, 채점은 동작이 1순위, 발표에서는 본인 코드의 데이터 수집·분류·화면·알림 흐름을 설명해야 한다. 이 조건에서 일반 기초 과정은 35시간을 통째로 먹어요. 반대로 AI에 생성을 맡기면 이해도가 깎여요. 파이썬은 알지만 새 라이브러리는 모르는 52명을 나눈 Shen·Tamkin 실험(arXiv:2601.20245)에서 퀴즈는 AI 사용군 50%, 직접 작성군 67%였고, 차이는 디버깅에서 가장 컸어요. 속도 차이는 약 2분으로 유의하지 않았어요. 그래서 1주는 변수·함수·리스트·딕셔너리·파일·HTTP만 프로젝트 데이터로 된 풀이 예제를 보고 빈칸을 채우고, 나머지 6주는 공공데이터 수집·분류, Streamlit, 알림을 최소 기능부터 붙이세요. 매주 한 번은 모델을 끄고 핵심 함수를 다시 쓰고, 그 함수가 왜 그 순서로 도는지 말로 설명하세요. 그 인출이 발표 답변입니다.

**사회자**:

📊 초안 라운드 현황 — 📚 기초부터 배운다 0명 : 3명 🛠 바로 구현한다
모든 토론자가 B편의 구현 중심 입장을 지지함

### 2라운드

**사회자**:

최종 라운드 — 토론자들이 수정안을 제출하고 투표합니다.

**강도율**:

파이썬을 다 배운 뒤 시작하면 과제의 가장 큰 위험을 늦게 발견해요. **첫 주에 최소 문법을 익히면서 공공데이터 한 건을 가져와 화면에 띄우세요.** 프레드 브룩스의 관점에서도 핵심 난점은 문법보다 무엇을 만들고 어떻게 검증할지 정하는 데 있어요. 데이터 종류, 분류 기준, 알림 조건을 각각 한 문장으로 못 정한다면 코딩보다 범위부터 줄여야 해요.

이후에는 규칙 분류와 알림까지 하나씩 붙이세요. AI 코딩 도구가 만든 함수마다 입력, 출력, 실패할 때의 동작을 직접 설명해 보세요. 설명이 막히면 다음 기능을 추가하지 마세요. 앞서 제시된 Stack Overflow 설문의 디버깅 응답은 생성된 코드가 곧 완성품은 아니라는 경고로 읽는 게 맞아요.

마지막까지 따질 쟁점은 **이 과제에 에이전트가 실제로 필요한가**예요. 정해진 기준으로 분류하고 알리는 데 그친다면 규칙과 자동 실행이 더 설명하기 쉬워요. 수업이 에이전트 동작을 요구한다면 애매한 항목에만 AI 판단을 넣으세요. 그 선택의 이유와 실패 사례를 보여주는 편이 기능을 늘리는 것보다 발표에 강해요.

**진동하**:

**기존 결론은 그대로 둡니다. 다만 "기초를 아예 건너뛴다"는 표현은 고치겠습니다. 첫 주에 2시간 정도, 내 코드를 읽는 데 필요한 최소한의 문법만 미리 익히는 것으로 수정합니다.** 이번 라운드에서는 반대 논거가 따로 나오지 않았습니다. 그래서 다른 사람에게 끌려가서 바꾸는 것이 아니고, 제 안을 스스로 다시 사전 부검해 보다가 빈틈을 하나 찾았습니다. 문법을 전혀 모르는 상태라면 AI에게 "이 코드를 설명해 달라"고 해도 그 설명을 검증할 기준이 없습니다. 결국 그럴듯하게 들리는 설명을 그대로 받아 적게 됩니다. 앞에서 인용한 Anthropic 실험에서 점수가 40% 아래로 떨어진 '생성 위임형' 사용자가 바로 이런 모습입니다. 이렇게 되면 '이해 시간'을 따로 떼어 둔 의미가 없어집니다.

**진동하**:

수정안의 근거는 세 가지입니다. 첫째, 비용은 거의 들지 않고 효과는 큽니다. 변수, 리스트와 딕셔너리, if/for, 함수, 그리고 API 응답(JSON)을 딕셔너리로 꺼내 쓰는 법까지 다섯 가지만 익히면 됩니다. 프로젝트 코드의 대부분이 이 다섯 가지로 이루어져 있고, 드는 시간은 전체 35시간 가운데 약 6%입니다. 기초 강의를 3~4주 듣는 것과는 비교할 수 없을 만큼 적은 투자입니다. 둘째, 이 2시간은 공부만 하는 시간이 아닙니다. 연습 예제로 공공데이터 API 호출 한 줄을 직접 쳐 봅니다. 그러면 첫 주의 인증키 지연이나 호출 한도 같은 문제를 같은 시간 안에 미리 확인할 수 있습니다. 셋째, 발표 질의응답의 실패 양상이 달라집니다. 이런 장면이 흔합니다. 어떤 발표자가 "이 for문은 무엇을 돌립니까?"라는 질문을 받고, AI가 붙여 준 주석을 그대로 읽다가 바로 다음 질문에서 무너졌습니다. 기초가 조금이라도 있으면 막히더라도 "이 딕셔너리에서 지역명 키를 꺼내 분류합니다"처럼 자기 말로 버틸 수 있습니다.

**진동하**:

정리하면 순서는 이렇습니다. 1주차는 2시간 최소 문법과 API 키 확인, 나머지 시간은 가장 얇은 뼈대입니다. 2~5주차는 기능 확장과 매주 이해 시간 1시간입니다. 6주차는 기능 동결과 녹화본 확보이고, 7주차는 비워 두는 완충 주간입니다. 이 구조가 시간 손실과 질의응답 붕괴라는 두 가지 최악의 경우를 동시에 막는 방어선입니다.

**서하린**:

35시간이 전부예요. 1주는 공공데이터 한 건으로 변수·함수·리스트·딕셔너리·파일·HTTP만 빈칸 예제로 채우고, 2–5주는 수집·분류·Streamlit·알림을 한 기능씩 최소로 붙이고, 6–7주는 연결·디버깅·발표 리허설에 써요.

판단은 숫자 세 개로 닫혀요. 비계 0.82는 평균 0.40과 문제기반학습 0.26 위에 있고, 안내를 빼면 초보 학습이 준다는 정리는 Kirschner, Sweller, Clark(2006)이에요. 퀴즈는 직접 작성 67%, AI 사용 50%이고 격차는 디버깅에 몰려 있어요. 속도 차는 약 2분으로 유의하지 않아요.

그래서 매주 25분은 모델을 끄고 핵심 함수를 다시 쓰고, 10분은 수집에서 알림까지 순서를 말로 풀어요. 그 35분이 발표 답변이에요. AI는 그 설명을 이미 한 흐름의 보일러플레이트에만 붙여요. 반론 칸이 비어 새 숫자가 없으니 이 절충을 유지해요.

**사회자**:

📊 결선 라운드 현황 — 📚 기초부터 배운다 1명 : 2명 🛠 바로 구현한다
세 토론자 모두 기초와 구현의 절충안에 합의함

**사회자**:

⚖️ 리스크 재검토 — 이 결론은 '주 5시간 × 7주 = 35시간'을 기준으로 계획을 짜지만, 직장인에게는 야근·출장·다른 과제 때문에 어느 주가 통째로 비는 일이 흔합니다. 그래서 7주차 완충 주간 하나로는 부족할 수 있고, 한 주가 날아가도 최소한 동작하는 시연본(공공데이터 수집+간단한 분류+Streamlit 화면)이 남도록 우선순위와 기능 컷 기준을 미리 정해 두어야 합니다. 또 '2시간 최소 문법'만으로 질의응답을 버틸 수 있다는 보장은 없습니다. 매주 이해 시간 1시간에서 자기 코드의 데이터 흐름(수집→분류→화면→알림)을 직접 설명해 보는 리허설을 하고, AI가 만든 분류 로직이 왜 그렇게 동작하는지는 실제 데이터로 한두 번 직접 돌려 확인해야 합니다. 마지막으로 알림 기능(외부 메신저·이메일 연동)과 공공데이터 API 인증·호출 한도는 외부 의존성이라 막힐 가능성이 크므로, 1주차에 가장 단순한 방식으로 먼저 통과 가능성을 확인하고 안 되면 화면 내 알림 등 대체안으로 바꿀 기준을 정해 두어야 합니다.