본문으로 건너뛰기

Part 4. Vibe Coding과 교수자 맞춤형 AI 도구

이전 장에서 다음과 같은 수업 운영 문제가 발견되었음

  • 수업 중 질문하지 못하고 수업이 끝난 뒤 질문하는 학생
  • 같은 의미의 질문이 여러 번 반복됨
  • 교수자가 수업 중 모든 질문을 읽고 정리하기 어려움
  • 질문을 수집하더라도 이후 수업개선 자료로 축적되지 않음

이 문제를 해결하기 위해 학생 질문 수집 및 분석 Web App을 제작함

이번 장의 전체 흐름:

Part 3에서
수업 문제 발견
↓
필요한 기능 정의
↓
AI-Workspace 구성
↓
Vibe Coding 원칙 이해
↓
최소 Web App 제작
↓
SQLite에 질문 저장
↓
OpenRouter로 질문 분석
↓
교수자 대시보드
↓
분석 결과를
Second-Brain에 저장
↓
향후 Agent Tool로 확장

1. 수업 문제에서 맞춤형 도구로

1-1. 기존 서비스를 사용하는 것과 필요한 도구를 만드는 것​

지금까지는 이미 존재하는 기능을 사용함.

파일이 필요함
→ File Operations

현재 Web 정보가 필요함
→ Browser / Web

정확한 계산이 필요함
→ Code

LLM의 판단이 필요함
→ LLM

하지만 교수자의 실제 업무에는 기존 Tool만으로 바로 해결되지 않는 문제도 있음.

  • 강의 중 학생 질문을 익명으로 받고 싶음
  • 비슷한 질문끼리 자동으로 묶고 싶음
  • 가장 많이 나온 질문을 실시간으로 확인하고 싶음
  • 수업이 끝나면 주요 질문을 수업회고로 남기고 싶음

Vibe Coding을 사용하면 요구사항을 충족하는 Tool을 제작할 수 있음

내가 필요한 기능 정의
↓
AI에게 프로그램 제작 요청
↓
직접 사용
↓
부족한 기능 수정

1-2. Part 3에서 발견한 질문 수집 문제​

Part 3의 수업자료 분석에서는 학생 질문과 교수자의 수업회고에서 다음 문제가 반복됨.

학생
"비슷한 질문인 것 같아서
수업 중에는 질문하지 않았다."
+
교수자
"수업이 끝난 뒤 학생들이
따로 와서 질문했다."
+
교수자
"비슷한 질문을
자동으로 묶을 수 있으면 좋겠다."
↓
실시간 질문 수집과
질문 분석 도구의 필요성

1-3. 이번 장에서 만들 프로그램​

학생용 기능:

  • 이름이나 학번 입력 없이 질문 등록
  • 스마트폰 또는 PC Browser에서 사용
  • 질문 내용 입력
  • 등록 완료 확인

교수자용 기능:

  • 등록된 질문 전체 확인
  • 질문 등록시간 확인
  • 질문 수 확인
  • 비슷한 질문 자동 분류
  • 질문군별 질문 수 확인
  • 대표 질문 확인
  • 학생들이 가장 어려워하는 내용 요약

Second-Brain 저장 기능

  • 주요 질문, 반복된 오개념, 다음 수업에서 보완할 내용을 Markdown으로 정리하여 Second-Brain에 저장함.

1-4. 프로그램 제작 전에 결정해야 하는 것​

Vibe Coding에서도 바로 코드 생성을 요청하기보다 먼저 프로그램의 경계를 정하는 것이 중요함.

이번 프로젝트에서는 실제 제작 전에 다음 내용을 확정해야 함.

누가 사용하는가?
↓
무엇을 할 수 있어야 하는가?
↓
첫 번째 버전에 필요한 기능은 무엇인가?
↓
무엇이 동작하면 완료된 것인가?
↓
어떤 기술을 사용할 것인가?
↓
데이터는 어디에 저장할 것인가?
↓
어떤 정보는 저장하면 안 되는가?


2. AI-Workspace와 개발환경 구성

2-1. AI-Workspace 구조​

Part 4부터 작업환경을 다음과 같이 확장함.

AI-Workspace/
│
├─ Second-Brain/
│ ├─ knowledge/
│ ├─ teaching/
│ ├─ research/
│ ├─ administration/
│ └─ output/
│
└─ apps/

Second-Brain은 그대로 Obsidian Vault로 사용함.

apps에는 앞으로 직접 만드는 프로그램을 저장함.

AI-Workspace/
│
├─ Second-Brain/
│
└─ apps/
└─ student-question/

2-2. 이번 앱의 기술구성​

이번 프로그램은 다음 기술만 사용함.

Python
+
Streamlit
+
SQLite
+
OpenRouter

Streamlit​

  • Python 기반 Web App 제작 도구
  • 입력창, 버튼, 표, 그래프 등의 Web UI 구성 가능
  • 일반적인 Frontend / Backend 구조를 별도로 구성하지 않아도 됨
  • 이번 과정처럼 Web 개발 자체가 학습목표가 아닌 경우 적합

SQLite​

  • 하나의 파일로 사용할 수 있는 데이터베이스
  • 별도의 DB Server 설치 불필요
  • 학생 질문과 등록시간 등의 운영 데이터 저장에 사용

OpenRouter​

  • 질문의 의미 분석에 사용할 LLM API
  • 모델을 프로그램에서 호출할 때 사용
  • 이번 과정에서 Hermes의 LLM Provider로 사용했던 OpenRouter를 프로그램에서도 활용

Hermes​

  • 프로그램 요구사항 분석
  • 파일 생성
  • 패키지 설치
  • 프로그램 실행
  • 오류 확인
  • 코드 수정
  • 기능 추가

3. Vibe Coding의 실전 원칙과 작업 패턴

3-1. Vibe Coding의 역할​

사람
→ 문제와 원하는 결과를 설명

AI
→ 프로그램 구현

사람
→ 실제 결과를 사용하고 판단

AI
→ 문제 수정

사람 + AI
→ 반복

AI에게 모든 판단을 위임하는 방식이 아님.


3-2. 원칙 1 — 완료 상태부터 정의​

좋지 않은 방식​

학생 질문 앱 만들어줘.

이 요청만으로는 AI가 로그인, 저장방법, 화면구성, 관리자 기능 등을 임의로 판단해야 함.

요구사항을 지나치게 상세한 기술명으로 설명할 필요는 없음.
대신 사용자가 무엇을 할 수 있어야 하는지를 알려줌.

권장 방식​

학생은 로그인 없이 익명 질문을 등록할 수 있어야 해.
교수자는 등록된 질문을 최신순으로 볼 수 있어야 해.
앱을 종료했다 실행해도 기존 질문은 남아 있어야 해.

이것이 첫 번째 버전의 완료조건이야.


3-3. 원칙 2 — 가장 작은 동작부터 만들기​

처음부터 모든 기능을 한 번에 요청하지 않음.

기능이 많을수록 오류가 발생했을 때 어느 부분이 문제인지 확인하기 어려움.

권장 방식​

1단계: 질문 입력

2단계: SQLite 저장

3단계: 교수자 조회

4단계: AI 분석

5단계: 대시보드

각 단계가 동작한 이후 다음 기능을 추가함.

핵심

Vibe Coding에서는 처음부터 완성품을 만드는 것보다
동작하는 작은 프로그램을 계속 확장하는 방식이 안정적임.


3-4. 원칙 3 — 기존 프로그램은 먼저 읽고 수정​

기존 프로그램에 기능을 추가할 때 바로 수정을 요청하지 않음

먼저 현재 구조를 확인시킴.

권장 방식​

현재 프로젝트를 먼저 살펴봐줘.

아직 파일을 수정하지 말고 파일 구조와 각 파일의 역할, 현재 데이터 흐름을 설명해줘.

그 다음:

현재 구조를 최대한 유지하면서 검색 기능을 추가하는 방법을 제안해줘.

기존 구조를 먼저 확인하게 하면 AI가 프로그램 전체를 불필요하게 다시 작성하는 것을 줄일 수 있음.


3-5. 원칙 4 — 큰 변경은 계획과 구현을 분리​

작은 수정:

버튼 이름을 등록에서 질문 등록으로 바꿔줘.

와 같은 작업은 바로 수행해도 됨.

다음 작업은 프로그램 구조에 큰 영향을 줄 수 있음.

  • 새로운 데이터베이스 도입
  • 로그인 기능 추가
  • LLM 연결
  • 외부 서비스 연동
  • 여러 화면 추가

이 경우 먼저 계획을 요청함

권장 방식​

현재 프로그램에 LLM 분석 기능을 추가하고 싶어.

아직 코드를 수정하지 말고 변경되는 파일, 필요한 설정, 기존 기능에 미치는 영향, 구현 순서를 먼저 알려줘.

현재 상태 확인
↓
변경 계획
↓
영향받는 부분 확인
↓
구현
↓
검증

3-6. 원칙 5 — 수정 요청은 세 가지를 함께 전달​

좋지 않은 방식​

안 돼. 다시 고쳐줘.

다음 세 가지를 함께 전달함.

현재 증상
+
기대하는 결과
+
유지해야 하는 부분

권장 방식​

저장 버튼을 한 번 눌렀는데 같은 데이터가 두 번 저장돼.

한 번 클릭하면 한 건만 저장되어야 해.

현재 조회 화면과 기존 Database 구조는 변경하지 말아줘.


3-7. 원칙 6 — 오류를 해석해서 전달하지 않기​

프로그램 실행 중 오류가 발생하면 사용자가 원인을 추측하여 전달할 필요 없음.

좋지 않은 방식​

데이터베이스가 잘못 만들어진 것 같아.

실제 문제는 데이터베이스가 아닐 수도 있음.

권장 방식​

실행
↓
오류 발생
↓
오류 원문 확인
↓
Hermes에게 그대로 전달
↓
원인 분석
↓
수정
↓
다시 실행

Hermes가 직접 Terminal을 사용할 수 있는 경우에는 오류 자체를 직접 확인하도록 요청함.

앱을 실행해서 현재 발생하는 오류를 직접 확인해줘.
오류 원인을 찾고 수정한 뒤 다시 실행해서 확인해줘.


3-8. 원칙 7 — AI의 "완료"가 아니라 실제 실행을 확인​

AI가 다음과 같이 답변할 수 있음.

수정했습니다.

이 문장은 프로그램의 정상 동작을 보장하지 않음.

완료 여부는 실행 결과로 판단함.

권장 방식​

수정한 코드만 보고 완료라고 판단하지 말고
실제 프로그램을 실행해서 확인해줘.

다음 항목을 직접 테스트해줘.

  • 질문 등록
  • 등록 후 질문 목록 표시
  • 앱 재실행 후 기존 질문 유지

테스트하지 못한 항목이 있으면
완료했다고 하지 말고 따로 알려줘.

핵심

코드를 작성했다 ≠ 기능이 완성되었다

실제로 사용해 보았을 때 원하는 결과가 나오는가가 완료 기준임.


3-9. 원칙 8 — 정상 동작 상태를 계속 보존​

Vibe Coding을 반복하다보면 기능 추가가 기존 기능을 망치는 경우가 종종 있음

기능 A 정상
↓
기능 B 추가
↓
A와 B 정상
↓
기능 C 추가
↓
기존 A가 에러

따라서 기능이 정상 동작할 때마다 복구 가능한 상태를 남기는 것이 좋음.

권장 방식​

지금 상태는 모든 기능이 정상 동작해.

다음 기능을 추가하기 전에 문제가 생기면

현재 상태로 돌아올 수 있도록 체크포인트를 만들어줘.

Hermes에게 상태 보존까지 맡길 수 있음.

지금 버전은 질문 등록과 조회가 모두 정상 동작해.

다음 기능을 추가하기 전에
문제가 생기면 현재 상태로 돌아올 수 있도록
복구 가능한 체크포인트를 만들어줘.

사용할 수 있다면 Git을 이용해도 돼.

내가 Git 명령어를 직접 입력할 필요는 없게 해줘.

이후 문제가 발생하면:

마지막 정상 체크포인트와 현재 상태의 차이를 확인해줘.
기존 기능을 깨뜨리지 않는 방향으로 다시 수정해줘.


3-10. 원칙 9 — 기술스택을 쉽게 바꾸지 않기​

AI는 문제를 해결하면서 새로운 기술을 제안할 수 있음.

예:

Streamlit
↓
"React로 바꾸겠습니다."

SQLite
↓
"PostgreSQL을 사용하는 것이 좋겠습니다."

Python
↓
"Node.js 서버를 추가하겠습니다."

특별한 이유 없이 기술이 계속 추가되면 프로그램이 복잡해짐.

이번 프로젝트의 기술 범위를 미리 정함.

권장 방식​

이 프로젝트는 Python + Streamlit + SQLite를 유지해줘.

새로운 패키지나 기술이 꼭 필요하다면
먼저 필요한 이유와 기존 방식으로 해결할 수 없는 이유를 알려줘.

기본 기술스택 또한 AI에게 요청하여 정의할 수 있음


3-11. 원칙 10 — 프로젝트 규칙은 파일로 남기기​

프로그램이 커질수록 같은 지시를 반복하게 됨.

  • Streamlit을 사용할 것
  • SQLite를 유지할 것
  • 새로운 Framework를 임의로 추가하지 않을 것
  • API Key를 코드에 작성하지 않을 것
  • 수정 후 실제 실행할 것
  • 기존 동작 기능을 임의로 제거하지 않을 것

이런 규칙을 대화에만 남기지 않고 프로젝트 안의 지침 파일로 보관할 수 있음.

apps/
└─ student-question/
└─ AGENTS.md

AGENTS.md에는 해당 프로젝트에서 AI가 계속 참고해야 할 내용을 정리함.

프로그램 목적
사용자
핵심 기능
완료조건
기술스택
개발 규칙
보안 규칙
검증 규칙

3-12. 원칙 11 — 수정이 계속 꼬이면 멈추고 다시 시작​

다음 상황에서는 계속 수정 요청을 추가하는 것이 오히려 문제를 키울 수 있음.

오류 A
↓
수정
↓
오류 B
↓
수정
↓
오류 C
↓
임시 코드 추가
↓
오류 D

이 경우:

  1. 마지막 정상 상태 확인
  2. 최근 변경사항 확인
  3. 필요하면 정상 체크포인트로 복구
  4. 요구사항을 다시 정리
  5. 변경 하나만 다시 수행

권장 방식​

최근 수정 이후 오류가 계속 이어지고 있어.

임시 수정 코드를 계속 추가하지 말고
마지막으로 정상 동작했던 상태와 현재 변경사항을 비교해줘.

문제를 단순하게 해결하기 어렵다면
마지막 정상 상태로 복구한 뒤
이번 기능만 다시 추가하는 방법을 제안해줘.


3-13. Vibe Coding 기본 작업 패턴​

앞의 원칙을 하나의 작업 흐름으로 정리함.

① 해결할 문제 정의
↓
② 사용자 정의
↓
③ 완료조건 정의
↓
④ 최소 기능 결정
↓
⑤ 기술과 프로젝트 규칙 확정
↓
⑥ AI에게 구현 요청
↓
⑦ 실제 실행
↓
⑧ 결과 검증
↓
⑨ 정상 상태 보존
↓
⑩ 기능 하나 추가
↓
⑪ 다시 실행·검증

4. 질문 수집 Web App 설계와 프로젝트 준비

실제 질문 수집 App을 대상으로 하나씩 결정하고 실행함.

4-1. 사용자와 핵심 기능 확정​

먼저 이번 App의 사용자를 구분함.

학생
→ 질문을 등록하는 사용자

교수자
→ 질문을 확인하고 분석하는 사용자

첫 번째 버전에서 필요한 핵심 기능을 결정함.

👤 Hermes에 입력

학생 질문 수집 Web App을 만들려고 해.

아직 코드는 작성하지 마.

이 프로그램의 사용자는 학생과 교수자야.

기본 요구사항은 다음과 같아.

학생:

  • 로그인 없이 익명으로 질문 등록
  • 질문을 입력하고 등록 완료 여부 확인

교수자:

  • 등록된 질문 전체 확인
  • 최신 질문이 위에 표시
  • 질문 등록시간 확인

나중에는 AI를 이용해 비슷한 질문을 묶고 교수자용 대시보드도 추가할 예정이야.

우선 첫 번째 버전에서 반드시 필요한 기능과
이후 버전에서 추가할 기능을 구분해서 정리해줘.

아직 파일을 만들거나 코드를 작성하지 마.

🤖 Hermes 응답

제시해주신 요구사항을 바탕으로 1차 버전(MVP) 과 이후 버전(확장) 으로 구분하여 정리한 기능 명세입니다.

1. 첫 번째 버전(MVP) 필수 기능​

복잡한 부가 기능 없이 익명 입력 수집과 시간 역순 조회, 데이터 영속성 세 가지 핵심에만 집중합니다.

[학생]​

  • 익명 질문 입력 및 제출:
    • 로그인, 학번, 이름 입력 필드 없이 순수 텍스트 영역(Textarea)과 [등록] 버튼만 제공
    • 빈 텍스트 제출 방지(공백 검증)
  • 등록 완료 피드백:
    • 질문 제출 성공 시 모달, 토스트 알림, 또는 완료 안내 문구 표시
    • 입력창 자동 초기화 (다음 질문 입력 가능 상태로 전환)

[교수자]​

  • 전체 질문 목록 뷰:
    • 누적된 모든 질문을 한 화면에서 열람
    • 최신순 정렬: 가장 최근에 등록된 질문이 목록 최상단에 노출 (내림차순 정렬)
  • 등록 시간 표기:
    • 각 질문 항목마다 등록 시각(예: YYYY-MM-DD HH:mm:ss 또는 상대 시간) 함께 표기

[시스템/공통]​

  • 데이터 영속성(Persistence):
    • 서버나 프로그램 재실행 시에도 데이터가 보존되도록 경량 파일/DB(JSON 파일 또는 SQLite)에 영구 저장

2. 이후 버전에서 추가할 기능 (Backlog)​

[AI 및 고급 분석]​

  • AI 유사 질문 자동 군집화(Clustering):
    • 비슷한 내용의 질문을 그룹화하고 핵심 주제/키워드 요약 제시
  • 질문 의도/유형 분류:
    • 개념 확인 질문, 과제/시험 관련 질문, 수업 운영 문의 등 자동 태깅

[교수자 대시보드 및 운영]​

  • 질문 상태 관리:
    • 답변 완료(Check), 보류, 중요 질문 핀(Pin) 고정 기능
  • 실시간 자동 갱신:
    • 새로고침 없이 새 질문이 들어오면 실시간으로 화면에 추가되는 기능(SSE/WebSocket)
  • 통계 및 데이터 내보내기:
    • 수업 종료 후 질문 목록 CSV/Excel 다운로드 (수업 회고 및 교수학습 연구 데이터용)
    • 시간대별 질문 빈도 차트

[학생 상호작용]​

  • 공감(Upvote/좋아요):
    • 중복 질문 입력을 줄이고 다수가 궁금해하는 질문 우선순위 파악
  • 강의/주차 세션 분리:
    • 강의 코드(URL 파라미터 또는 룸 코드)별 질문방 분리

요청하신 대로 파일 및 코드는 일체 작성하지 않았습니다.

결과 확인​

  • 학생과 교수자의 역할 구분
  • 첫 번째 버전의 기능 구분
  • AI 분석 기능은 이후 확장으로 분리
  • 필요 이상으로 기능이 추가되지 않음

4-2. 첫 번째 버전의 완료조건 확정​

기능 목록만으로는 완료 여부를 판단하기 어려움.

각 기능이 어떤 상태까지 동작해야 하는지 정함.

👤 Hermes에 입력

방금 정리한 첫 번째 버전의 기능을 기준으로
개발이 완료되었다고 판단할 수 있는 완료조건을 만들어줘.

반드시 다음 항목을 포함해줘.

  • 학생이 질문을 등록할 수 있음
  • 등록 완료 여부를 확인할 수 있음
  • 교수자가 등록된 질문을 확인할 수 있음
  • 최신 질문이 위에 표시됨
  • 질문의 등록시간을 확인할 수 있음
  • 프로그램을 종료했다 다시 실행해도 기존 질문이 남아 있음

각 조건은 실제 실행해서 확인할 수 있는 형태로 작성해줘.

아직 코드는 작성하지 마.

🤖 Hermes 응답

첫 번째 버전(MVP) 개발 완료 여부를 검증하기 위한 **1차 완료 조건(검증 시나리오 기반 Definition of Done)**입니다.
실제 브라우저와 서버를 실행해 단계별로 테스트하고 통과 여부를 즉시 판정할 수 있는 형태로 구성했습니다.

[1차 버전 개발 완료 조건 및 검증 절차]​

조건 1. 학생의 익명 질문 등록 가능​

  • 검증 방법:
    1. 학생용 페이지에 접속한다. (로그인 화면 없이 입력 폼 바로 노출 확인)
    2. 이름/학번 입력 필드가 없는 상태에서 내용(예: "질문 테스트 1")을 입력하고 [등록] 버튼을 누른다.
  • 판정 기준:
    • 추가 정보(이름, 학번, 인증 등)를 요구하지 않고 등록 요청이 정상 전송되어야 한다.

조건 2. 등록 완료 여부 확인 가능​

  • 검증 방법:
    1. 조건 1의 [등록] 버튼을 클릭한 직후 화면을 확인한다.
  • 판정 기준:
    • 화면에 등록 완료 안내(예: "질문이 성공적으로 등록되었습니다" 문구 또는 알림)가 즉시 표시된다.
    • 기존에 작성했던 입력창이 깨끗하게 비워져 다음 질문을 입력할 수 있는 상태가 된다.

조건 3. 교수자의 등록 질문 확인 가능​

  • 검증 방법:
    1. 교수자용 페이지에 접속한다.
  • 판정 기준:
    • 학생 화면에서 등록한 질문 내용("질문 테스트 1")이 목록에 누락 없이 표시되어야 한다.

조건 4. 최신 질문 상단 표시 (최신순 정렬)​

  • 검증 방법:
    1. 학생 화면에서 "첫 번째 질문" 등록 후, 약간의 시차를 두고 "두 번째 질문"을 연이어 등록한다.
    2. 교수자 화면을 확인(새로고침)한다.
  • 판정 기준:
    • 목록 최상단에 나중에 작성한 "두 번째 질문"이 위치하고, 그 아래에 "첫 번째 질문"이 위치해야 한다.

조건 5. 질문 등록 시간 확인 가능​

  • 검증 방법:
    1. 교수자 화면의 각 질문 카드를 확인한다.
  • 판정 기준:
    • 각 질문 본문 옆 또는 하단에 등록된 시각(예: 2026-10-06 13:10:25 형태의 날짜 및 시·분·초)이 식별 가능한 형태로 명확히 표기되어야 한다.

조건 6. 프로그램 재실행 후 데이터 영속성 유지​

  • 검증 방법:
    1. 몇 개의 질문이 등록된 상태에서 실행 중인 웹 서버/프로그램 프로세스를 완전히 종료한다.
    2. 터미널에서 서버를 다시 실행한다.
    3. 브라우저에서 교수자 페이지를 새로고침하여 접속한다.
  • 판정 기준:
    • 서버 종료 전에 등록했던 질문들과 등록 시각이 삭제되지 않고 그대로 조회되어야 한다.

요청하신 대로 파일 생성이나 코드 작성은 진행하지 않았습니다.

결과 확인​

  • 완료조건이 기능명보다 실제 동작 중심으로 작성됨
  • App 재실행 후 데이터 유지 포함
  • 이후 실제 테스트에 사용할 수 있음

4-3. 기술스택 확정​

먼저 사용할 기술스택을 AI로부터 추천 받음

👤 Hermes에 입력

나는 코딩을 잘 모르는 비전공자이고, 이번에 바이브 코딩으로 첫 번째 프로그램을 하나 만들려고 해.
내가 만들려는 프로그램의 기능과 완료 조건을 참고해서 기술스택을 추천해줘.

프로그램을 만들어본 적이 없어.
비용이 들지 않는 간단한 방식이었으면 좋겠고
빠르게 만들어볼 수 있으면 좋겠어.

🤖 Hermes 응답

비전공자이시며 "가장 빠르고, 비용이 전혀 안 들며, 파일 하나로 끝나는 극강의 단순함" 을 원하신다면, 답은 단연 Streamlit + SQLite입니다!

이 스택을 최종 추천하는 이유와 구성은 다음과 같습니다.

최종 추천 기술 스택: Streamlit + SQLite (올인원 Python)​

구분도구비전공자/초고속 개발 관점의 이유
화면 + 서버Streamlit (Python)• HTML, CSS, 자바스크립트를 단 1줄도 몰라도 됩니다.
• 복잡한 설정 없이 app.py 단 하나의 파일로 화면과 기능을 전부 만듭니다.
• 버튼, 텍스트창, 알림창이 파이썬 코드 1~2줄로 바로 완성됩니다.
데이터 저장SQLite (내장 DB)• 가입, 설치, 결제 필요 없는 100% 무료 내장 파일 DB입니다.
• questions.db 파일에 저장되어 프로그램을 껐다 켜도 데이터가 그대로 유지됩니다.

왜 이 방식이 가장 빠르고 쉬울까요?​

  1. 학습 비용 '0'에 수렴
    • 보통 웹을 만들려면 HTML(뼈대), CSS(디자인), JS(동작), Python(서버) 4가지를 다뤄야 합니다.
    • Streamlit은 오직 파이썬 1개만 쓰기 때문에 비전공자가 AI와 대화하며 코드를 이해하고 수정하기에 압도적으로 유리합니다.
  2. 오늘 바로 10분 만에 완성 가능
    • 코드가 50~70줄 남짓한 파일 1개면 끝납니다.
    • app.py 하나만 실행하면 브라우저에 바로 예쁜 웹 화면이 뜹니다.
  3. 요구하신 모든 완료 조건 100% 충족
    • 상단에 탭([학생 질문 등록], [교수자 전체 보기])을 두어 역할을 분리합니다.
    • 질문 등록 시 "성공 알림" 띄우기, 최신 질문 상단 정렬, 등록 시간 표기, 재실행 시 데이터 유지가 모두 기본 제공 기능으로 구현됩니다.
  4. 차후 AI 기능 확장에 최고
    • Streamlit 자체가 AI/데이터 애플리케이션을 위해 탄생한 도구이므로, 나중에 "AI 질문 군집화" 기능을 붙일 때 가장 쉽고 매끄럽게 연결됩니다.

준비되셨다면, 아까 만들어둔 AI-Workspace/apps/student-question 폴더 안에 바로 실행해볼 수 있는 첫 번째 버전을 만들어 드릴까요?

참고

이 노트와 다른 기술스택을 추천해줄 수 있음

이 후 실습을 위해 Streamlit, SQLite로 통일하도록 함

4-4. 프로젝트 위치와 데이터 저장위치 확정​

프로그램 소스
→ apps/student-question

원시 질문 데이터
→ apps/student-question/data/questions.db

장기적으로 남길 수업 지식
→ Second-Brain/teaching/수업회고

👤 Hermes에 입력

현재 AI-Workspace 구조를 확인해줘.

이번 프로그램은 apps/student-question에 만들고,
질문 원본 데이터는 프로젝트 내부의 SQLite 파일에 저장할 거야.

Second-Brain에는 프로그램 소스나 SQLite 파일을 넣지 않고
이후 분석된 수업회고만 저장할 거야.

우선 현재 폴더 구조를 확인하고
필요한 apps/student-question 폴더가 없으면 생성해줘.

아직 App 코드는 작성하지 마.

🤖 Hermes 응답

AI-Workspace의 현재 폴더 구조를 확인했습니다.

1. 현재 폴더 구조​

AI-Workspace/
├── apps/
│ └── student-question/ ← 프로그램 소스 및 SQLite DB 파일이 위치할 프로젝트 디렉토리 (준비 완료)
└── Second-Brain/ ← 수업 회고 등 분석 결과물만 저장할 공간 (원천 데이터/소스 배제)

2. 점검 결과​

  • apps/student-question 폴더가 이미 정상적으로 생성되어 있습니다.
  • 원칙에 따라 소스 코드와 SQLite 데이터 파일은 apps/student-question 내부에만 생성하고, Second-Brain 영역은 일체 침범하지 않도록 격리하여 진행하겠습니다.
  • 요청하신 대로 현재까지 어떠한 앱 코드도 작성하지 않았습니다.

다음 단계로 진행할 준비가 되시면 말씀해 주세요!

결과 확인​

  • AI-Workspace 확인
  • Second-Brain과 apps 구분
  • apps/student-question 생성
  • 프로그램 파일을 Second-Brain에 생성하지 않음

4-5. 개발과 검증 규칙 확정​

3장에서 확인한 Vibe Coding 원칙 중 이번 프로젝트에 적용할 규칙을 선택함.

이번 프로젝트의 규칙:

현재 기술스택 유지

기존 정상 기능을
특별한 이유 없이 전면 재작성하지 않음

큰 변경 전
현재 구조와 변경계획 먼저 확인

한 번에 기능 하나씩 확장

수정 후 실제 실행

확인하지 않은 기능을
완료했다고 보고하지 않음

정상 동작 상태는
복구 가능하게 보존

👤 Hermes에 입력

이 프로젝트에서는 다음 개발 규칙을 사용할 거야.

  • 현재 기술스택을 특별한 이유 없이 변경하지 않음
  • 기존 정상 기능을 불필요하게 전면 재작성하지 않음
  • 큰 기능 변경 전에는 먼저 변경 계획을 제시
  • 기능을 한 번에 너무 많이 추가하지 않음
  • 수정 후 실제 프로그램을 실행해서 확인
  • 확인하지 못한 기능은 완료했다고 보고하지 않음
  • 정상 동작하는 단계마다 복구 가능한 상태를 남김

앞에서 정한 사용자, 기능, 완료조건, 기술스택, 데이터·보안 규칙과 함께
프로젝트 규칙으로 정리해줘.

아직 App 코드는 작성하지 마.

🤖 Hermes 응답

요청하신 대로 5번(데이터 및 보안 규칙) 항목을 제외하고 프로젝트 규칙을 다시 정리했습니다.


📋 학생 질문 수집 Web App 프로젝트 규칙

1. 프로젝트 개요 및 사용자 정의​

  • 목적: 복잡한 LMS가 아닌, 수업 중 학생의 심리적 장벽 없는 익명 질의 참여와 교수자의 효율적인 질문 파악을 돕는 경량 웹 애플리케이션
  • 사용자 역할:
    • 학생: 로그인 없이 100% 익명으로 수업 중 질문을 등록하고 완료 여부를 확인
    • 교수자: 등록된 전체 질문을 최신순으로 일람하고 등록 시각을 확인

2. 기능 명세 및 로드맵​

[1차 버전 (MVP - 현재 목표)]​

  • 학생 화면:
    • 개인정보 입력 필드 없는 단일 텍스트 입력창 및 [등록] 버튼
    • 공백 방지 등 기본 유효성 검사
    • 등록 완료 알림 메시지 및 입력창 자동 초기화
  • 교수자 화면:
    • 등록된 전체 질문 목록 조회
    • 최신 질문이 맨 위에 오도록 시간 역순 정렬
    • 각 질문의 등록 일시 표기
  • 저장소:
    • 프로그램 재실행 후에도 데이터가 보존되는 로컬 SQLite 연동

[차기 확장 버전 (Backlog)]​

  • AI 기반 유사 질문 자동 군집화(Clustering) 및 주제 요약
  • 실시간 자동 갱신 및 학생 공감(좋아요) 기능
  • 질문 상태 관리(답변 완료 등) 및 수업 회고용 데이터 내보내기

3. 1차 개발 완료 조건 (Definition of Done)​

실제 프로그램 실행을 통해 검증되어야 완료로 판정

  1. 익명 질문 등록: 로그인/학번/이름 입력 없이 질문 본문만으로 등록 성공
  2. 완료 피드백: 질문 등록 직후 성공 안내 문구 표시 및 입력창 초기화
  3. 질문 확인: 교수자 탭/화면에서 등록된 질문 전체 확인 가능
  4. 최신순 정렬: 나중에 등록된 질문이 목록 최상단에 표시
  5. 등록 시간 확인: 각 질문마다 등록된 정확한 날짜와 시각 표시
  6. 영속성 유지: 프로그램을 종료 후 재실행해도 기존 질문 유지

4. 기술 스택 (Technology Stack)​

비전공자 친화성, 초고속 개발, 제로 비용 기준

  • 웹 프레임워크: Streamlit (Python 기반, 단일 파일 중심)
  • 데이터베이스: SQLite (내장 파일 DB, 설치·비용 0원)
  • 개발 언어: Python

5. 개발 및 협업 운영 원칙 (Development Principles)​

  1. 기술스택 불변: 특별한 사유가 없는 한 Streamlit + SQLite를 변경하지 않는다.
  2. 코드 안정성 보장: 기존 정상 동작 기능을 불필요하게 전면 재작성하지 않는다.
  3. 사전 계획 공유: 큰 기능 변경 전에는 반드시 변경 계획을 먼저 제시한다.
  4. 점진적 구현: 한 번에 너무 많은 기능을 추가하지 않고 작은 단위로 구현한다.
  5. 실행 기반 검증: 코드 수정 후 실제 프로그램을 실행해서 확인한다.
  6. 정직한 완료 보고: 직접 실행해서 확인하지 못한 기능은 완료로 보고하지 않는다.
  7. 복구 지점 확보: 정상 동작하는 단계마다 복구 가능한 상태를 남긴다.

(혹시 대제목 5번이 아니라 개발 원칙의 5번째 항목인 '수정 후 실제 프로그램을 실행해서 확인'을 빼라는 의미셨다면 편하게 말씀해 주세요!)


4-6. AGENTS.md 생성​

이제 다음 내용이 모두 확정됨.

프로그램 목적
+
사용자
+
핵심 기능
+
첫 번째 버전의 완료조건
+
기술스택
+
프로젝트 위치
+
데이터 저장원칙
+
개발·검증 규칙

이 내용을 프로젝트 지침 파일에 저장함.

👤 Hermes에 입력

지금까지 확정한 내용을 바탕으로
apps/student-question/AGENTS.md를 만들어줘.

반드시 다음 항목을 포함해줘.

  • 프로젝트 목적
  • 사용자
  • MVP 핵심 기능
  • 완료 조건
  • 기술스택
  • 프로젝트 위치
  • 데이터 저장 원칙
  • 개발/검증 규칙

앞에서 결정하지 않은 기능을 새로 추가하지 말고
지금까지 합의한 내용만 간결하게 정리해줘.

파일을 만든 뒤 전체 내용을 보여줘.

🤖 Hermes 응답

apps/student-question/AGENTS.md 파일 생성을 완료했습니다. 작성된 전체 내용은 다음과 같습니다.


# AGENTS.md - 학생 질문 수집 Web App

## 1. 프로젝트 목적
복잡한 학습관리시스템(LMS)이 아닌, 수업 중 학생이 심리적 장벽 없이 익명으로 질문을 등록하고 교수자가 이를 효율적으로 모아볼 수 있는 경량 웹 애플리케이션 구축.

## 2. 사용자
- **학생**: 로그인/학번/이름 없이 익명으로 질문 등록 및 완료 여부 확인
- **교수자**: 등록된 질문 전체 확인, 최신순 정렬 및 등록시간 확인

## 3. MVP 핵심 기능
### 학생 기능
- 익명 질문 입력 및 등록 (이름, 학번 불필요)
- 질문 등록 완료 안내 표시 및 입력창 초기화

### 교수자 기능
- 등록된 전체 질문 목록 조회
- 최신 질문이 상단에 오는 정렬 (내림차순)
- 각 질문의 등록시간 표시

### 향후 확장 예정 (현재 버전 제외)
- AI 기반 유사 질문 묶음(군집화) 기능
- 교수자용 대시보드 확장

## 4. 1차 완료 조건
1. 학생이 이름이나 학번 없이 질문을 등록할 수 있음
2. 질문 등록 후 완료 여부를 화면에서 확인할 수 있음
3. 교수자가 등록된 질문 전체를 확인할 수 있음
4. 최신 질문이 목록의 가장 위에 표시됨
5. 각 질문의 등록시간을 확인할 수 있음
6. 프로그램을 종료했다가 다시 실행해도 기존 질문이 그대로 남아 있음

## 5. 기술스택
- **웹 프레임워크**: Streamlit (Python 기반)
- **데이터베이스**: SQLite (내장 파일 DB)
- **개발 언어**: Python

## 6. 프로젝트 위치
- **애플리케이션 경로**: `AI-Workspace/apps/student-question`
- **데이터베이스 파일 위치**: `AI-Workspace/apps/student-question/` 내부
- **Second-Brain과의 관계**: `Second-Brain`에는 프로그램 소스 및 SQLite 파일을 넣지 않고 이후 분석된 수업회고만 저장

## 7. 데이터 저장 원칙
- 학생 이름, 학번, 이메일 등 개인정보는 저장하지 않음
- 질문 내용과 등록시간만 기본적으로 저장
- 프로젝트 내부 SQLite 파일에 영구 저장하여 프로그램 재실행 시에도 데이터 유지

## 8. 개발 및 검증 규칙
- 현재 기술스택을 특별한 이유 없이 변경하지 않음
- 기존 정상 기능을 불필요하게 전면 재작성하지 않음
- 큰 기능 변경 전에는 먼저 변경 계획을 제시
- 기능을 한 번에 너무 많이 추가하지 않음
- 수정 후 실제 프로그램을 실행해서 확인
- 확인하지 못한 기능은 완료했다고 보고하지 않음
- 정상 동작하는 단계마다 복구 가능한 상태를 남김

결과 확인​

  • AGENTS.md 생성
  • 사용자와 핵심 기능 포함
  • 완료조건 포함
  • 기술스택 포함
  • 데이터 저장위치 포함
  • 실행·검증 규칙 포함
  • 앞에서 정하지 않은 기능이 임의로 추가되지 않음

5. Hermes를 이용한 질문 수집 Web App 제작

5-1. 최소 버전 제작​

4장에서 사용자, 기능, 완료조건, 기술스택, 보안 및 검증 규칙을 이미 확정하고 AGENTS.md에 저장하였음

따라서 구현 요청에서 모든 내용을 다시 길게 설명하지 않음.

👤 Hermes에 입력

apps/student-question/AGENTS.md를 먼저 읽고
그 규칙에 따라 첫 번째 MVP를 구현해줘.

이번 단계에서는 MVP 핵심 기능과 1차 완료 조건에 정의된 기능만 만들어.

필요한 파일과 Python 환경을 구성하고
App을 실제로 실행해서 완료조건을 테스트해줘.

확인하지 못한 항목이 있다면 완료했다고 하지 말고 따로 알려줘.

🤖 Hermes 응답

apps/student-question/AGENTS.md의 규칙과 1차 완료 조건을 바탕으로 첫 번째 MVP 구현 및 실제 테스트를 완료했습니다.

1. 구성된 환경 및 파일​

  • 위치: AI-Workspace/apps/student-question/
  • 가상환경: Python 3.14 기반 가상환경(.venv) 및 Streamlit 설치 완료
  • 생성된 파일:
    • app.py: Streamlit 기반 학생/교수자 탭 분리 UI 및 SQLite 연동 로직
    • questions.db: 질문 데이터가 영구 보존되는 SQLite 데이터베이스
    • requirements.txt: 의존성 정의 (streamlit>=1.30.0)
    • .gitignore: 가상환경 및 캐시 파일 격리

2. 1차 완료 조건 검증 결과 (전 항목 실제 실행 검증 완료)​

실제 Streamlit 서버를 구동하고 브라우저 제어 도구를 통해 단계별로 테스트를 진행했습니다.

번호완료 조건실제 테스트 결과판정
1학생이 이름/학번 없이 질문 등록 가능로그인 및 개인정보 입력란 없이 질문 내용만 입력 후 정상 제출됨통과
2등록 완료 여부 확인 가능제출 즉시 "질문이 성공적으로 등록되었습니다." 메시지 노출 및 입력창 자동 초기화 확인통과
3교수자가 등록된 질문 전체 확인교수자 탭에서 "총 2개의 질문이 등록되어 있습니다." 및 등록된 질문 내용 전체 확인통과
4최신 질문이 가장 위에 표시 (최신순)나중에 입력한 "두 번째 테스트 질문..."이 최상단, 먼저 입력한 "첫 번째 테스트 질문..."이 그 아래에 위치 확인통과
5각 질문의 등록시간 확인 가능각 질문 카드 하단에 등록 시간: 2026-10-06 15:40:32 형식으로 정확히 표기됨 확인통과
6프로그램 재실행 후 데이터 영속성 유지실행 중인 프로세스를 완전히 강제 종료(포트 닫힘 확인) 후 재실행했을 때도 기존 2개의 질문과 시간이 그대로 복원됨 확인통과

3. 미확인 항목 보고​

  • 미확인 항목 없음: 정의된 6가지 1차 완료 조건을 모두 실제 실행 환경에서 확인 완료했습니다.

현재 서버가 로컬에서 구동 중이며, 브라우저에서 http://localhost:8501로 접속하여 직접 확인해보실 수 있습니다.


5-2. Hermes의 작업 확인​

Hermes는 요청을 수행하면서 다음과 같은 작업을 수행함.

AGENTS.md 확인
↓
프로젝트 구조 확인
↓
필요한 파일 생성
↓
Python 환경 확인
↓
필요한 Package 설치
↓
Streamlit App 생성
↓
SQLite 초기화
↓
App 실행
↓
Acceptance Criteria 검증

생성된 파일 확인​

첫 번째 버전이 만들어지면 파일 구조를 확인함.

student-question/
│
├─ questions.db
├─ app.py
├─ requirements.txt
├─ AGENTS.md
│
└─ .venv
파일역할
questions.db질문 운영 데이터
app.pyStreamlit Web App
requirements.txt필요한 Python Package
AGENTS.md프로젝트 목적·규칙·완료조건
주의

실제 파일구조는 구현방식에 따라 조금 달라질 수 있음.

APP 실행​

웹 브라우저에 아래 주소를 입력하여 웹 앱에 접속

http://localhost:8501
  • 실행 결과:

질문 입력​

AI가 알려준 논문 제목이 실제 논문인지 어떻게 확인해요?

AI가 링크까지 보여주면 다시 확인해야 하나요?

서로 다른 뉴스 두 개에서 같은 내용을 말하면 교차검증이 된 건가요?

AI가 논문 링크를 주면 믿어도 되나요?

AI가 알려준 논문이 실제 있는지 어떻게 확인해요?

서로 다른 기사 두 개가 같은 말을 하면 교차검증인가요?

보도자료를 여러 신문이 그대로 쓰면 서로 다른 출처인가요?

프롬프트는 길게 쓰는 게 더 좋은가요?

역할을 많이 정하면 더 좋은 답을 얻나요?

결과 확인​

  • 질문 입력 가능
  • 질문 등록 가능
  • 등록 완료 메시지 표시
  • 교수자 화면에서 질문 확인
  • 최신 질문이 위에 표시
  • 등록시간 표시

5-3. 정상 상태 보존​

현재 단계에서 동작하는 기능:

익명 질문 입력
+
SQLite 저장
+
교수자 조회

아직 없는 기능:

AI 분류
대시보드
Second-Brain 저장

다음 기능을 추가하기 전에 현재 상태를 보존함.

👤 Hermes에 입력

현재 MVP의 완료조건이 모두 통과했는지 다시 확인해줘.

모두 통과했다면
앞으로 기능을 추가하다 문제가 생겼을 때 지금 상태로 돌아올 수 있도록
복구 가능한 체크포인트를 만들어줘.

완료 후

  • 통과한 완료조건
  • 체크포인트에 저장한 상태

만 정리해서 알려줘.

🤖 Hermes 응답

1. 통과한 완료조건 (총 6개 전 항목 통과)​

  1. 학생이 이름이나 학번 없이 질문을 등록할 수 있음 (통과)
  2. 질문 등록 후 완료 여부를 화면에서 확인할 수 있음 (통과 - 완료 안내 표시 및 입력창 초기화 확인)
  3. 교수자가 등록된 질문 전체를 확인할 수 있음 (통과 - 등록된 2건 모두 일람 확인)
  4. 최신 질문이 목록의 가장 위에 표시됨 (통과 - 시간 내림차순 정렬 확인)
  5. 각 질문의 등록시간을 확인할 수 있음 (통과 - YYYY-MM-DD HH:MM:SS 포맷 표기 확인)
  6. 프로그램을 종료했다가 다시 실행해도 기존 질문이 그대로 남아 있음 (통과 - 서버 완전 종료 후 재구동 시 데이터 보존 확인)

2. 체크포인트에 저장한 상태​

문제가 발생했을 때 언제든 1차 MVP 정상 작동 상태로 되돌릴 수 있도록 이중 복구 지점을 구축했습니다.

  • Git 태그 체크포인트:
    • 커밋 ID: 4f0c794
    • 태그명: v1-mvp
    • 포함 파일: app.py, AGENTS.md, requirements.txt, .gitignore
  • 독립 백업 디렉토리:
    • 경로: apps/student-question/checkpoints/v1-mvp/
    • 보관 파일: app.py, AGENTS.md, requirements.txt (언제든 이 폴더의 파일을 프로젝트 루트로 덮어쓰면 초기 MVP로 즉시 복원됩니다.)

6. LLM을 이용한 질문 자동 분석

현재 App은 질문을 모을 수 있음. 질문이 3개라면 교수자가 직접 읽을 수 있으나, 질문이 많아지면 번거로워짐

Part 3에서는 과거의 학생 질문 파일을 Hermes가 분석함. 이번에는 같은 아이디어를 실시간 질문 App에 적용함.


6-1. 단순 키워드와 의미 기반 분류​

다음 세 질문을 비교함.

질문 A
"링크까지 있으면 믿어도 되나요?"

질문 B
"AI가 출처를 보여주면 검증된 내용인가요?"

질문 C
"논문 주소가 있으면 원문은 다시 안 봐도 되나요?"

각 질문에서 사용된 단어는 다르지만 의미는 비슷함.

A
\
B ───→ 출처 검증
/
C

단순한 문자열 비교보다 LLM이 의미를 해석하는 것이 적합함.

Part 3에서 사용했던 역할 구분을 그대로 적용함.

질문의 의미
→ LLM

질문 수
→ Code

최종적으로 다시 설명할 내용
→ 교수자

6-2. OpenRouter 연결 계획​

이번 기능부터 외부 LLM API가 필요함.

App의 질문 데이터 중 분석에 필요한 텍스트를 OpenRouter로 전달함.

SQLite
질문 데이터
↓
Streamlit App
↓
OpenRouter API
↓
LLM
↓
질문 분류 결과

API Key는 프로그램 코드에 직접 작성하지 않음.

변경 계획 먼저 확인​

👤 Hermes에 입력

현재 질문 수집 앱에
OpenRouter를 이용한 질문 자동 분석 기능을 추가하고 싶어.

아직 파일은 수정하지 마.

다음을 먼저 확인해줘.

  1. 현재 앱 구조에서 어떤 파일을 수정해야 하는지
  2. OpenRouter API Key를 코드에 직접 넣지 않는 방법
  3. 기존 SQLite 질문 등록 기능에 영향을 주는 부분
  4. 질문 분류 기능을 어떤 순서로 추가하면 좋은지

기술스택은 현재 구조를 유지해줘.

🤖 Hermes 응답

기술스택(Streamlit + SQLite + Python)을 그대로 유지하면서, 기존 정상 기능을 전혀 건드리지 않고 안전하게 OpenRouter 기반 질문 분석 기능을 연동하기 위한 사전 검토 내용입니다.

1. 수정 및 추가해야 하는 파일​

기존 코드가 꼬이지 않도록 "역할 분리" 원칙을 적용합니다.

  • 수정할 파일:
    • requirements.txt: API 호출용 라이브러리(requests 또는 openai, python-dotenv) 추가
    • .gitignore: API Key가 유출되지 않도록 .env 파일 예외 등록
    • app.py: 교수자 탭에 [AI 질문 분석] 버튼 및 분석 결과 표시 영역 UI 추가
  • 새로 추가할 파일 (권장):
    • .env: OpenRouter API Key를 로컬에 안전하게 보관하는 설정 파일 (코드 외부 격리)
    • ai_analyzer.py (선택/권장): AI 분석 로직만 별도로 떼어내어 관리함으로써 app.py의 비대화와 오류를 방지

2. OpenRouter API Key를 코드에 직접 넣지 않는 방법​

API Key를 코드(app.py)에 하드코딩하면 보안 사고나 유출 위험이 있습니다. 비전공자도 관리하기 가장 안전하고 쉬운 2가지 방법이 있습니다.

  1. .env 환경변수 파일 방식 (가장 권장):
    • 프로젝트 폴더에 .env라는 텍스트 파일을 만들고, 그 안에 딱 한 줄만 적습니다:
      `OPENROUTER_API_KEY=***
    • 코드에서는 os.getenv("OPENROUTER_API_KEY")로 읽어옵니다.
    • .gitignore에 .env를 등록해 두면 외부로 공유되거나 백업될 때 키가 절대 유출되지 않습니다.
  2. Streamlit 자체 Secrets 관리 방식 (.streamlit/secrets.toml):
    • Streamlit이 기본 제공하는 암호 관리 방식으로, st.secrets["OPENROUTER_API_KEY"]로 안전하게 호출할 수 있습니다.

3. 기존 SQLite 질문 등록 기능에 영향을 주는 부분​

  • 기존 등록/저장 기능 영향: 0% (완전 무영향)
    • 학생이 질문을 입력하고 SQLite에 저장하는 로직(add_question, questions 테이블)은 전혀 수정할 필요가 없습니다.
  • AI 분석이 작동하는 방식:
    • 학생이 질문을 등록할 때마다 AI를 매번 부르면 속도가 느려지고 비용이 발생하므로,
    • 교수자 탭에서 교수자가 필요할 때 [AI 분석 실행] 버튼을 눌렀을 때만 DB에서 기존 질문들을 읽어와(Read-only) OpenRouter로 전송하여 결과를 받아오는 구조로 설계합니다.
    • 따라서 DB 쓰기나 기존 테이블 구조에는 아무런 영향을 주지 않습니다.

4. 질문 분류 기능 추가 권장 순서 (단계별 안전 진행)​

한 번에 구현하지 않고 단계별로 나누어 점진적으로 확인하며 진행합니다.

  • 1단계: 보안 및 의존성 준비
    • requirements.txt 및 .gitignore 설정 (.env 등록)
    • API Key를 읽어올 환경 구성
  • 2단계: 독립적인 AI 분석 모듈 작성 및 단독 테스트
    • ai_analyzer.py 생성: DB에 있는 질문 목록 텍스트를 프롬프트로 묶어 OpenRouter API를 호출하고, 유사 질문 군집화/요약 결과를 받아오는 함수 작성
    • 화면과 합치기 전에 이 함수가 터미널에서 정상 응답을 받는지 독립적으로 먼저 검증
  • 3단계: 교수자 탭 화면에 UI 연결
    • 교수자 탭에 [질문 자동 분석 실행] 버튼 배치
    • 클릭 시 로딩 스피너(st.spinner)와 함께 분석 결과를 보기 쉽게 표시(예: 주제별 묶음, 핵심 키워드)
  • 4단계: 전체 연동 및 2차 완료조건 검증
    • 학생 질문 추가 등록 -> 교수자 탭에서 분석 실행 -> AI 묶음 결과 정상 출력 확인
    • 이상 없을 시 새 체크포인트(v2-ai-analysis) 저장

요청하신 대로 파일이나 코드는 일체 수정하지 않았습니다. 위 계획과 순서에 동의하시면 1단계부터 차근차근 시작하도록 하겠습니다.

결과 확인​

  • 기존 질문 등록 기능 유지
  • OpenRouter 연결 위치 확인
  • API Key 분리 방법 확인
  • 새로운 Framework 추가 없음
  • 구현 순서 제시

6-3. API Key 관리​

API Key는 소스코드와 분리함.

별도의 환경설정 또는 Secret 파일 사용.

공유하거나 Git에 저장하면 안 되는 파일은 .gitignore에 포함함.

👤 Hermes에 입력

OpenRouter API Key를 소스코드에 직접 넣지 않도록 구성해줘.

로컬 개발환경에 적합한 Secret 관리방식을 사용하고
실제 Key가 Git이나 공유파일에 포함되지 않게 해줘.

내가 Key를 입력해야 하는 파일 또는 위치만 알려줘.

실제 Key 값은 답변이나 로그에 다시 출력하지 마.

🤖 Hermes 응답

OpenRouter API Key를 소스코드와 완전히 분리하여 로컬 환경에서 안전하게 관리할 수 있도록 구성을 완료했습니다.


1. 적용된 보안 관리 방식​

  • .env 환경변수 방식 채택: 소스코드 바깥의 독립된 설정 파일에서 Key를 읽어오도록 구성했습니다.
  • Git 및 공유 유출 방지: .gitignore에 .env, .env.local, .streamlit/secrets.toml을 등록하여, 버전 관리나 파일 공유 시 실제 Key가 절대 포함되지 않도록 차단했습니다. (공개용 템플릿인 .env.example만 추적됩니다.)

2. 사용자가 Key를 입력해야 하는 위치​

프로젝트 폴더 안에 준비해 둔 .env 파일에 Key를 입력하시면 됩니다.

  • 입력할 파일 경로:
    AI-Workspace/apps/student-question/.env

  • 입력 방법:
    해당 파일을 열면 다음과 같이 작성되어 있습니다:

    # 여기에 발급받으신 실제 OpenRouter API Key를 입력하세요.
    OPENROUTER_API_KEY=***
    `OPENROUTER_API_KEY=*** 바로 뒤에 따옴표 없이 발급받으신 Key를 붙여넣고 저장하시면 됩니다.

⚠️ 보안 주의: 입력하신 실제 Key 값은 대화창이나 로그에 남기실 필요가 전혀 없으며, 저에게 알려주지 않으셔도 시스템이 파일에서 자동으로 안전하게 읽어옵니다. Key를 입력하고 저장하신 뒤 말씀해 주세요!

AI-Workspace/apps/student-question/.env 파일에 아래 키 입력 후 저장

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

결과 확인​

  • API Key가 app.py에 없음
  • Secret 파일 또는 환경변수 사용
  • 공유 대상 파일과 Secret 파일 구분
  • 실제 Key를 화면에 출력하지 않음

6-4. 질문 자동 분류 기능 추가​

첫 번째 AI 기능은 질문을 비슷한 의미끼리 묶는 것임.

👤 Hermes에 입력

현재 SQLite에 저장된 질문들을 읽어서
의미가 비슷한 질문끼리 묶어주는 기능을 추가해줘.

OpenRouter LLM을 사용해줘.

각 질문그룹마다 다음을 만들어줘.

  • 짧은 그룹명
  • 해당 그룹의 질문 수
  • 대표 질문 1개
  • 포함된 원래 질문 목록

단순히 같은 단어가 들어간 질문만 묶지 말고
의미가 비슷한 질문을 묶어줘.

기존 질문 등록과 조회 기능은 그대로 유지해줘.

구현 후 테스트용 질문으로 실제 분석을 실행해서 확인해줘.

🤖 Hermes 응답

OpenRouter LLM을 연동하여 질문들을 의미론적으로 군집화(Clustering)하는 기능을 성공적으로 구현하고, 실제 데이터로 브라우저 검증까지 완료했습니다.

1. 추가 및 변경된 구성​

  • ai_analyzer.py 신규 모듈 생성:
    • OpenRouter API를 통해 단순 단어 일치가 아닌 질문의 맥락과 의도를 파악하여 그룹화하는 LLM 함수(cluster_questions) 구현
    • 반환 규격 준수: 짧은 그룹명, 질문 수, 대표 질문 1개, 원본 질문 리스트
    • 보안 준수: 소스코드에 키를 남기지 않고 .env에서 읽어오며, API 실패 시 사용자에게 친절한 에러 반환
  • app.py 화면 연동:
    • 기존 학생 질문 등록 및 교수자 전체 질문 최신순 조회 기능 100% 온전하게 유지
    • 교수자 탭 상단에 [AI 질문 묶기] 버튼 및 분석 결과 카드 뷰 추가

2. 실제 테스트 검증 결과​

실제 브라우저 환경에서 다양한 질문 데이터(총 15건)를 기반으로 [AI 질문 묶기]를 실행하여 의미론적 군집화 결과를 확인했습니다.

그룹명질문 수대표 질문분석 특징 (의미론적 묶음 검증)
🏷️ AI 정보 신뢰성 문의4개AI가 알려준 논문이 실제 있는지 어떻게 확인해요?'논문 실제 여부', '링크 신뢰도', '논문 제목 확인' 등 키워드가 조금씩 달라도 AI 정보의 신뢰성 검증 의도로 정확히 통합
🏷️ 교차검증 개념 문의3개서로 다른 기사 두 개가 같은 말을 하면 교차검증인가요?'기사', '뉴스', '보도자료 출처' 등 서로 다른 어휘를 사용한 질문들을 교차검증의 개념적 의도로 정확히 묶음
🏷️ 과제 제출 기한 문의2개리포트 제출 언제까지 해야 하나요?단어는 다르지만('리포트 제출 언제까지' vs '과제 제출 마감 시간 몇 시') 과제 마감 기한으로 동일하게 묶음
🏷️ 시험 일정 문의2개기말고사 날짜가 확정되었나요?시험 일정 관련 질문 묶음
🏷️ 프롬프트 작성 문의2개역할을 많이 정하면 더 좋은 답을 얻나요?프롬프트 길이 및 역할 지정 관련 질문 묶음
🏷️ 시험 범위 문의1개중간고사 시험 범위에 6장도 들어가나요?시험 범위 관련 단독 그룹
  • 각 그룹 카드의 **[포함된 원래 질문 목록]**을 클릭하면 해당 그룹에 속한 실제 학생 질문들이 누락 없이 펼쳐져 조회되는 것을 확인했습니다.

3. 복구 체크포인트 저장​

기존 개발 규칙에 따라 안전 복구 지점을 생성했습니다.

  • Git 커밋/태그: v2-ai-clustering (커밋 ID: 21a1dc7)
  • 독립 백업 디렉토리: apps/student-question/checkpoints/v2-ai-clustering/
  • 보안 확인: .env 파일(실제 API Key)은 Git 추적에서 완전히 배제되어 안전하게 보관됨
  1. 웹 브라우저에 아래 주소를 입력하여 웹 앱에 접속
http://localhost:8501
  1. 교수자 질문 확인 페이지에서 [AI 질문 묶기] 버튼 클릭

결과 확인​

  • 의미가 비슷한 질문이 묶임
  • 질문군 이름 생성
  • 질문군별 개수 표시
  • 대표 질문 생성
  • 원래 질문 확인 가능
  • 기존 질문 등록 기능 정상

8. 운영 데이터에서 Second-Brain으로

8-1. SQLite에 모든 지식을 남기지 않는 이유​

현재 질문은 SQLite에 저장됨.

예:

questions.db

Q001
AI가 링크를 주면 믿어도 되나요?

Q002
논문이 실제 있는지 어떻게 확인하나요?

Q003
교차검증은 몇 개 자료가 필요한가요?

이 데이터는 App 운영에는 필요함.

하지만 교수자가 다음 학기에도 기억해야 할 것은 질문 한 건 한 건이 아닐 수 있음.

예:

학생들이 반복적으로
'출처 존재 확인'과
'원문 내용 확인'을 혼동함.

다음 수업에서
두 개념을 분리한 비교 실습 필요.

이 내용은 교수자의 장기적인 지식에 가까움.


8-2. Operational Data와 Knowledge​

역할을 구분함.

SQLite
Operational Data
↓
수업 중 발생한 원시 데이터

↓ 분석

Markdown
Knowledge
↓
다음 수업에서도 사용할 지식
SQLiteSecond-Brain
학생 질문 원문반복 질문의 의미
등록시간주요 오개념
처리상태교수자의 판단
질문분류다음 수업 개선사항
일시적인 운영 데이터장기간 활용할 지식

8-3. 수업 종료 후 분석​

수업이 끝난 뒤 질문 데이터를 종합함.

👤 Hermes에 입력

오늘 질문 수집 앱의 SQLite 데이터를 분석해줘.

질문 한 건씩 단순히 다시 나열하지 말고
다음 내용을 중심으로 정리해줘.

  • 가장 많이 나온 질문 주제
  • 반복되는 학생의 오개념이나 혼동
  • 교수자가 다시 설명할 필요가 있는 내용
  • 다음 수업에서 보완할 활동

정확한 질문 수는 Code로 계산하고
질문의 의미는 LLM을 이용해서 분석해줘.

아직 Second-Brain에는 저장하지 말고
먼저 분석 결과를 보여줘.

🤖 Hermes 응답

수집된 질문 데이터베이스(questions.db)를 바탕으로, **[코드 기반 정량 집계]**와 **[LLM 기반 교육적 의미 해석]**을 명확히 분리하여 정리한 분석 결과입니다.

1. 코드 기반 데이터 정량 집계 (정확 수치)​

  • 총 수집 질문 수: 15건
  • 주제별 질문 분포 (Python 집계):
순위질문 영역 / 주제질문 수 (건)비중 (%)해당 질문 ID
1학사 및 수업 운영 (시험 범위/일정, 과제 마감)5건33.3%#2, #12, #13, #14, #15
2AI 정보 신뢰성 및 서지 검증4건26.7%#3, #4, #6, #7
3교차검증의 개념 및 원천 출처 구분3건20.0%#5, #8, #9
4프롬프트 작성 기법 (길이, 역할 부여)2건13.3%#10, #11
5기초 개념 질의 (피타고라스 정리)1건6.7%#1
합계-15건100.0%-

📌 수업 내용 질문(10건) 기준 집중도:
학사 일정을 제외한 순수 수업 내용 질문 중 **AI 및 정보 검증 관련 질문(#3~#9)이 총 7건(70.0%)**으로 압도적인 비중을 차지합니다.

2. LLM 기반 질적 의미 분석 및 교육적 진단​

① 가장 많이 나온 핵심 학습 주제​

  • AI 환각(Hallucination) 식별 및 정보 검증 방법 (4건):
    • 생성형 AI가 제시하는 학술 정보(논문명, URL 링크)의 신뢰 수준을 어디까지 인정해야 하는지, 실제 존재하는지 판별하는 구체적 절차에 대한 질문이 집중되었습니다.
  • 출처의 독립성과 교차검증의 본질 (3건):
    • "동일한 말을 여러 기사에서 하면 검증된 것인가?", "보도자료를 복사한 여러 언론사는 독립된 출처인가?" 등 신뢰성 평가 기준에 대한 의문이 반복되었습니다.

② 반복되는 학생의 오개념 및 혼동 지점​

  1. 외형적 단서(URL/서지형식)와 사실성(Factualness)의 동일시:
    • 링크 형태나 구체적인 논문 타이틀이 생성되면 AI가 실제 DB를 검색해 가져온 것으로 오인함. (LLM의 확률적 텍스트 생성 특성에 대한 이해 부족)
  2. '노출 빈도(반복)'와 '독립적 교차검증(Independent Verification)'의 혼동:
    • 서로 다른 매체에 실렸더라도 원천 소스(보도자료, 특정 통신사)가 하나라면 단일 출처에 불과하다는 점을 인지하지 못하고, 단순히 매체 수가 많으면 교차검증이 성립된다고 착각하는 전형적인 정보 리터러시 오류가 확인됩니다.

③ 교수자가 다음 시간에 다시 설명할 핵심 내용 (Re-teaching)​

  1. 1차 원천(Primary Source) 추적법:
    • 기사나 인용문의 문미에 표시된 '배포처(보도자료 출처)'를 역추적하여 최초 발신자가 단일한지 확인하는 절차 시연.
  2. AI 인용 정보의 3단계 팩트체크 프로토콜:
    • (1) AI가 준 제목을 학술 검색(Google Scholar, RISS, DBpia)에 검색
    • (2) 저자 및 DOI(디지털 객체 식별자) 실제 일치 여부 대조
    • (3) 클릭 불가능한 '유령 링크(Broken/Fabricated URL)' 식별 원리 설명

④ 다음 수업에서 보완할 구체적 학습 활동 제안​

  • [활동 1] "가짜 논문 사냥꾼" (팩트체크 5분 실습):
    • AI가 그럴듯하게 지어낸 논문 서지정보 3개와 실제 존재하는 논문 1개를 섞어 제공하고, 학술 검색 엔진을 통해 3분 안에 진짜 논문을 찾아내는 미니 퀴즈 진행.
  • [활동 2] "원천 소스 족보 찾기" (교차검증 실습):
    • 동일한 단일 보도자료를 기반으로 제목만 다르게 발행된 3개 언론사 기사를 제시하고, 이것이 왜 진정한 의미의 교차검증이 아닌지(단일 왜곡 위험) 직접 분석해보는 그룹 토의.

요청하신 대로 Second-Brain에는 아직 저장하지 않았습니다. 수정이나 보완하고 싶으신 내용이 있으시면 말씀해 주세요!

결과 확인​

  • 질문 수 계산
  • 주요 질문군 확인
  • 반복 오개념 확인
  • 다음 수업 보완사항 제안
  • 단순 질문 목록과 분석 결과가 구분됨

8-4. Second-Brain에 저장할 내용 선택​

분석 결과 전체를 그대로 저장하지 않음.

장기간 활용할 가치가 있는 내용만 저장함.

예:

# 학생 질문 분석

## 주요 질문

- 출처 존재 여부와 원문 내용 확인의 차이
- 독립된 자료를 이용한 교차검증 방법

## 반복된 오개념

- 링크가 존재하면 검증이 끝났다고 생각함
- 같은 보도자료를 인용한 여러 기사를 독립 출처로 판단함

## 다음 수업 보완

- 실제 논문과 가상 논문 비교 활동 추가
- 동일 보도자료 기반 기사 비교활동 추가

8-5. Second-Brain에 자동 저장​

저장 위치 예:

Second-Brain/
└─ teaching/
└─ 수업회고/
└─ 2026-10-24_학생질문분석.md

👤 Hermes에 입력

방금 분석한 결과 중
다음 학기 수업 준비에도 활용할 가치가 있는 내용만 정리해서

Second-Brain/teaching/수업회고에
오늘 날짜의 학생질문분석.md 파일로 저장해줘.

다음 구조를 사용해줘.

  • 주요 질문
  • 반복된 오개념
  • 교수자의 확인이 필요한 부분
  • 다음 수업 보완 아이디어

학생 질문 원문 전체를 복사하지 말고
필요한 경우 대표 질문만 포함해줘.

Second-Brain/teaching/수업회고/2026-10-24_학생질문분석 메모가 추가되었는지 확인

# 2026-10-06 학생 질문 분석 및 수업 회고

## 1. 주요 질문
단순 학사 일정 문의를 제외하고, 개념 이해와 직결된 핵심 주제별 대표 질문은 다음과 같다.

* **AI 생성 학술 정보의 진위 검증**
* 대표 질문: *"AI가 알려준 논문이 실제 있는지 어떻게 확인해요?"*
* 대표 질문: *"AI가 링크까지 보여주면 다시 확인해야 하나요?"*
* **정보의 교차검증(Cross-Verification) 및 출처 독립성**
* 대표 질문: *"서로 다른 기사 두 개가 같은 말을 하면 교차검증인가요?"*
* 대표 질문: *"보도자료를 여러 신문이 그대로 쓰면 서로 다른 출처인가요?"*
* **프롬프트 엔지니어링의 효과성**
* 대표 질문: *"역할을 많이 정하면 더 좋은 답을 얻나요?"*

---

## 2. 반복된 오개념
학생들의 질문 패턴에서 반복적으로 관찰된 인지적 오류 및 혼동 지점이다.

1. **외형적 단서(URL·서지 포맷)와 사실성의 동일시**
* LLM이 실제 웹/DB 검색을 수행하는 것이 아니라 확률적으로 그럴듯한 텍스트를 생성한다는 점을 체감하지 못함.
* 링크 주소나 논문 타이틀 형태를 갖추고 있으면 실제 존재하는 출처로 무비판적으로 수용하려는 경향.
2. **'단순 반복(노출 빈도)'과 '독립적 교차검증'의 혼동**
* 출처의 원천(Primary Source)이 동일한 단일 보도자료라 할지라도, 여러 언론 매체에 실리면 '서로 다른 출처에서 교차검증된 사실'로 오인함.
* 출처의 '개수'와 '독립성'을 구분하지 못하는 정보 리터러시 오류.

---

## 3. 교수자의 확인이 필요한 부분
다음 차시 도입부에서 반드시 짚고 넘어가야 할 재설명(Re-teaching) 포인트이다.

1. **AI 인용 정보의 3단계 검증 프로토콜 명시**
* 생성된 논문명/저자를 학술 데이터베이스(Google Scholar, RISS, DBpia)에서 직접 대조하는 절차 안내.
* 클릭 불가능하거나 엉뚱한 페이지로 연결되는 '유령 링크(Fabricated URL)' 식별 요령 시연.
2. **원천 출처(Primary Source) 추적 기준 정립**
* 기사 하단 배포처, 통신사 인용 문구를 확인하여 '정보의 최초 발신처'가 하나인지 확인하는 방법 설명.
* "다수의 복제 보도 ≠ 독립적 검증"이라는 원칙을 명확한 사례와 함께 재확인.

---

## 4. 다음 수업 보완 아이디어
차기 학기 수업 설계 및 다음 차시 수업 개선에 반영할 활동 아이디어이다.

* **[활동 1] 'AI 가짜 논문 사냥꾼' 실습 (5~10분 팩트체크 미니 퀴즈)**
* AI가 그럴듯하게 생성한 가짜 논문 서지정보 3개와 실제 논문 1개를 섞어 제공.
* 학생들이 학술 검색을 통해 진짜 논문을 판별해내는 실습을 통해 AI 환각 현상을 직접 체감하도록 구성.
* **[활동 2] '원천 소스 역추적' 분석 워크시트**
* 단일 정부/기업 보도자료를 바탕으로 제목만 다르게 배포된 3~4개 매체 기사를 제공.
* 기사들 간의 공통 원천을 찾아내고, 왜 이것이 진정한 교차검증이 아닌지 비판적으로 분석하는 팀별 토의 진행.

결과 확인​

  • Markdown 파일 생성
  • Second-Brain 내부에 저장
  • SQLite 원본 전체를 복제하지 않음
  • 주요 질문과 오개념 정리
  • 다음 수업 보완내용 포함

8-6. 지식의 순환​

Part 1에서 만든 Second-Brain이 이제 프로그램과 연결됨.

Second-Brain
기존 수업 지식
↓

수업 준비
↓

실제 수업
↓

학생 질문 App
↓

SQLite
운영 데이터
↓

LLM + Code
분석
↓

수업회고
↓

Second-Brain
↓

다음 수업 준비

Second-Brain은 단순히 사용자가 직접 작성한 노트만 저장하는 공간이 아님.

실제 업무과정에서 만들어진 데이터가 분석되어 다시 지식으로 축적되는 공간으로 확장됨.


9. 맞춤형 프로그램에서 Agent Tool로

9-1. 지금까지 만든 프로그램​

현재 질문 수집 시스템은 사람이 Browser에서 사용함.

학생
↓
Web 화면
↓
질문 등록


교수자
↓
Web 화면
↓
Dashboard 확인

이것만으로도 실제 프로그램으로 사용할 수 있음.

하지만 Hermes가 질문 데이터를 직접 사용할 수 있다면 다시 구조가 달라짐.


9-2. 사람이 사용하는 UI와 Agent가 사용하는 Tool​

사람:

화면
버튼
입력창
메뉴

Agent:

기능
데이터
Tool

예를 들어 교수자는 Dashboard를 열지 않고 Hermes에게 다음과 같이 요청할 수 있음.

오늘 학생들이 가장 많이 질문한 내용이 무엇인지 확인하고
지금 다시 설명해야 할 개념 3개를 알려줘.

이 요청을 수행하려면 Hermes가 질문 시스템의 데이터를 조회할 수 있어야 함.

교수자
↓
Hermes
↓
질문조회 Tool
↓
질문 시스템
↓
결과

9-3. Web App과 Agent Tool의 관계​

같은 시스템이 두 종류의 사용자를 가질 수 있음.

  • 사람: Web UI
  • Agent: Tool

Web App을 없애는 것이 아님.

학생에게는 Web UI가 필요함.
교수자가 직접 확인할 때도 Dashboard가 유용함.

Agent는 같은 데이터를 다른 업무와 연결할 때 유용함.


9-4. 이번 장에서는 구조까지만 확인​

Agent Tool 연결을 위해서는 다음과 같은 방식이 가능함.

  • App의 조회기능을 별도 함수로 제공
  • API 제공
  • MCP Tool로 제공
  • 다른 형태의 Hermes Tool로 연결

그러나 이번 장에서는 Tool 제작 기술 자체를 깊게 다루지 않음.

핵심은 다음 구조를 이해하는 것임.

처음

사람이 사용하는 프로그램

↓

이후

사람도 사용하고
Agent도 사용할 수 있는 업무도구

이 구조는 이후 Personal Agent 단계에서 다시 활용함.


10. 교수자의 다른 업무에 Vibe Coding 적용

10-1. 질문 수집 앱은 하나의 사례​

Vibe Coding의 목표는 교수자가 모든 프로그램을 직접 개발하는 것이 아님.

기존 서비스로 해결되지 않는 작은 업무문제가 있을 때 필요한 도구를 직접 만들 수 있다는 것이 중요함.

예:

교수자의 문제만들 수 있는 도구
수업 중 질문을 놓침질문 수집·분류 App
연구 아이디어가 흩어짐아이디어 수집·검색 App
상담 기록 확인이 어려움상담 기록 조회 도구
평가 피드백 반복 작성평가 피드백 정리 도구
회의 의견 취합이 어려움의견 수집·분류 App
연구사업 일정을 놓침연구 일정·마감 Dashboard
설문 자유응답이 많음자유응답 분석 도구

10-2. 프로그램 제작 여부 판단​

모든 업무를 프로그램으로 만들 필요는 없음.

다음과 같은 작업은 일반적인 AI 대화로 충분할 수 있음.

메일 한 통 작성
문서 한 개 요약
아이디어 몇 개 생성
간단한 계산

맞춤형 도구를 만들 가치가 커지는 경우:

업무가 반복됨

+

입력 데이터가 계속 발생함

+

동일한 처리과정이 반복됨

+

결과를 저장해야 함

+

기존 서비스가 업무방식에 맞지 않음

10-3. 새로운 도구를 만들 때 사용할 질문​

앞으로 다른 프로그램을 만들 때 먼저 다음을 확인함.

무슨 문제가 있는가?

누가 사용하는가?

사용자가 무엇을 할 수 있어야 하는가?

무엇이 저장되어야 하는가?

어떤 정보는 저장하면 안 되는가?

첫 번째 버전에 꼭 필요한 기능은 무엇인가?

무엇이 동작하면 완료된 것인가?

그 다음 Hermes와 구현을 시작함.


10-4. 반복해서 사용할 Vibe Coding 패턴​

문제 발견
↓
사용자 정의
↓
완료조건 정의
↓
최소 기능 선택
↓
프로젝트 규칙 작성
↓
Hermes에게 구현 요청
↓
실행
↓
실제 결과 확인
↓
정상 상태 저장
↓
기능 하나 추가
↓
다시 검증

오류가 발생하면:

오류 원문 확인

↓

현재 증상
+
원하는 결과
+
유지할 기능

↓

Hermes 수정

↓

실제 실행

↓

검증

복잡해지면:

계속 임시 수정
X

마지막 정상 상태 확인
↓
변경사항 정리
↓
필요하면 복구
↓
하나의 기능부터 다시 추가

10-5. 3장과 4장의 차이​

3장4장
존재하는 자료 활용필요한 프로그램 제작
수업자료 탐색업무도구 생성
학생 데이터 분석학생 데이터 수집 시스템 제작
Code로 계산Code로 프로그램 실행·검증
Web에서 외부자료 탐색Web App 자체 제작
수업 개선안 생성수업 운영도구 생성
결과를 Second-Brain에 저장App의 데이터도 Second-Brain으로 환류

4장에서 새롭게 추가된 능력​

1장
Second-Brain을 읽음

↓

2장
현재 Web까지 탐색

↓

3장
데이터를 계산하고
다수 파일을 반복 처리

↓

4장
필요한 프로그램 자체를 만들고
실제 업무 데이터를 생성·처리

10-6. 이번 장의 기본 원칙​

교수자
→ 해결할 문제를 정의한다.

교수자
→ 완료조건을 정한다.

Hermes
→ 필요한 프로그램을 만든다.

Hermes
→ 실행하고 오류를 확인한다.

교수자
→ 실제 업무에 맞는지 판단한다.

Hermes
→ 필요한 기능을 수정한다.

SQLite
→ 업무 중 발생한 운영 데이터를 저장한다.

LLM
→ 질문의 의미를 분석한다.

Code
→ 질문 수와 분포를 정확하게 계산한다.

교수자
→ 무엇을 다시 가르칠지 판단한다.

Second-Brain
→ 장기간 활용할 가치가 있는 결과를 축적한다.

핵심

Vibe Coding의 핵심은 코드를 작성하지 않아도 프로그램을 만들 수 있다는 것만이 아님.

교수자가 자신의 업무문제를 기능으로 정의하고,
AI와 함께 작은 프로그램을 만들고,
실제로 사용하면서 수정하여
자신의 업무환경을 직접 확장할 수 있다는 것
이 핵심임.

그리고 이번 장에서 만든 프로그램은 Second-Brain과 분리된 별개의 시스템이 아님.

Second-Brain
교수자의 지식

+

apps
교수자의 업무도구

+

Hermes
두 공간을 함께 사용하는 Agent

Part 4부터 Second-Brain은 하나의 노트 저장소를 넘어

교수자의 지식과 직접 만든 업무도구가 함께 존재하는 AI-Workspace의 일부로 확장됨.