-
Notifications
You must be signed in to change notification settings - Fork 0
1주차 회고
- 나무런 프로젝트 기획 확정
- 데이터 수집 방법 검토 및 결정 (덤프 데이터 활용)
- 기술 스택 선정
- GitHub 저장소 세팅
- Vite + React + TypeScript + Tailwind v4 프로젝트 초기 셋업 (이슈 #1 완료)
- Claude Code 커스텀 Skill 체계 구축 (
/plan-sprint,/implement,/commit-msg,/create-pr) - 나무위키 덤프 데이터(parquet) 실측 분석 — 컬럼 구조, 링크 추출 패턴, 필터링 전략 확정
- 데이터 파이프라인 설계 문서화
- Agent 개발 워크플로우 문서 작성 및 지속 업데이트중..
파이프라인 코드를 짜기 전에, 실제 parquet 파일을 열어서 컬럼 구조와 데이터 텍스트의 패턴 등을 확인했다. 덕분에 코드를 작성하기 전에 설계를 확정할 수 있었다.
또한, AI 협업 워크플로우를 초반에 잡아뒀다.
/plan-sprint → /implement → /commit-msg → /create-pr 사이클을 세팅해둔 것이 좋았다. 특히 작업 계획을 GitHub Issue 코멘트에 저장하는 방식 덕분에 대화 컨텍스트가 끊겨도 이어서 작업할 수 있었다. 2주차부터 본격적인 구현을 진행하면서 부족한 부분을 보완할 계획이다. 또한 멘토링에서 배운 방식도 조금씩 추가해보면서 AI 협업을 연습할 계획이다.
구현 방향이 바뀔 때(파이프라인 필터링 전략 변경 등) 코드보다 docs를 먼저 수정하는 습관을 들였다. docs와 코드의 불일치가 없어서 나중에 컨텍스트를 다시 잡을 때 혼란이 없었다.
워크플로우 Skill을 처음부터 완벽하게 만들려다 보니 초반 시간이 많이 들었다. 돌아보면 첫 기능을 먼저 직접 구현해보고 반복되는 패턴이 보일 때 Skill로 추출하는 순서가 더 효율적이었을 것 같기도 하다.
/plan-sprint 실행 시 이슈가 추상적이면 Claude가 작업 범위를 파악하는 데 시간이 걸린다. "어떤 파일을 만들고 무엇을 구현하는지"까지 적어두면 작업 계획 수립이 훨씬 빨라진다는 걸 배웠다.
멘토링을 통해 docs는 기획 문서가 아니라 기술 스펙이라는 것을 배웠다. md 파일은 "어떻게 만들지"를 적는 기술 스펙으로 관리해야 한다. 구현이 완료된 후에는 스펙 문서와 실제 코드가 일치하는지 검증하는 흐름이 필요하다. 지금은 docs/를 설계 단계에서 작성하고 있는데, 구현 후 검증까지 이어지는 루틴을 만들어야 할 것이다.
또한 sub skill을 통해 slash command를 적게 유지하면서도 다양한 기능을 담당할 수 있도록 만들어볼 생각이다. 그리고 issue 등록부터 PR까지의 사이클을 하나로 묶는 skill도 만들어보면 좋을 것 같다.
- 데이터 파이프라인 구현 완료 (이슈 #11) — parquet → R2 + Supabase 적재
- Supabase 테이블 생성 및 연동 (이슈 #2)
- R2 fetch 유틸 구현 (이슈 #3)
- Mintlify / GitHub Pages 연동 탐색
- Sub Skill 분리 방향 실험