시작하게 된 계기
인스타그램 계정을 키워보고 싶었는데, 어떤 주제로 할지가 고민이었어요. "내가 뭘 만들 수 있는 사람인지 보여주는 계정"으로 방향을 잡았고, 세 가지를 따로 만들지 않고 하나로 연결하기로 했어요.
- AI 에이전트를 공용 브레인으로 설계(코드 리뷰 + 블로그 학습 RAG)
- 그 에이전트를 여러 인터페이스(CLI, VS Code 확장, 디스코드 봇, 포트폴리오 사이트)로 감싸서 재사용
- 만드는 과정을 인스타그램(짧게)·블로그(자세히)·깃허브(코드)에 동시에 기록
"API 하나 배워서 프로젝트 여러 개를 만들었다"는 스토리를 실제로 만들어보는게 목표였어요.
무엇을 만들었나
| 구성요소 | 역할 | 상태 |
|---|---|---|
kodex-code-review-agent | 코드 리뷰 + 블로그 RAG의 핵심 로직(Python) | 완성, VS Code 마켓플레이스 배포 |
kodex-vscode-extension | 위 로직을 화면으로 쓰는 VS Code 확장 | doyu.kodex-code-review 정식 배포 |
kodex-discord-bot | /review, /ask, /usage 슬래시 커맨드 | 완성, 사용량 캡 적용 |
kodex-portfolio-site | Next.js 포트폴리오 사이트 + Kodex 챗 위젯 | Vercel 배포, GitHub 자동 배포 연결 |
핵심 원칙은 하나였어요 — 로직은 한 곳에서만 짜고, 나머지는 전부 재사용한다. 코드 리뷰/블로그 RAG 로직을 Python으로 한 번 만든 뒤, VS Code 확장(TypeScript)과 디스코드 봇(Python, 같은 코드 그대로 import), 포트폴리오 사이트(TypeScript로 포팅)까지 네 개의 인터페이스가 모두 같은 두뇌를 공유해요.
11일 타임라인
| Day | 한 일 |
|---|---|
| 1 | 코드 리뷰 도우미 CLI 완성 (Gemini API 무료 티어) |
| 2 | VS Code 확장 제작. gemini-2.5-flash가 신규 유저에게 막히는 사건 → gemini-flash-latest 별칭으로 전환 |
| 3 | 블로그 학습 AI(RAG) 완성 — 벨로그 글 수집 → 임베딩 → 유사도 검색 → 근거 기반 답변 |
| 4 | RAG를 VS Code 화면 안으로 통합, 503 에러 자동 재시도 로직 추가 |
| 5 | 기능 6종 추가(git diff 리뷰, 품질 점수 등) + 마켓플레이스 정식 배포 |
| 6 | 포트폴리오 사이트(Next.js) 착수 — Hero/Projects/Devlog 3섹션 |
| 7 | 스티키 네비, 스크롤 리빌 애니메이션 등 디테일 polish |
| 8 | About/Contact 섹션 추가, Vercel 실배포로 진짜 URL 획득 |
| 9 | GitHub 레포 연결, push할 때마다 자동 재배포되게 CI/CD 구성 |
| 10 | 디스코드 봇 제작 — /review, /ask 슬래시 커맨드로 에이전트 연결 |
| 11 | Phase 4 마무리 — 사용량 캡(디스코드+사이트), 포트폴리오 사이트에 챗 위젯 삽입, 방문자 추적 파라미터 정리 |
로드맵상 8주로 잡았던 일정(Phase 1~4)을 11일 만에 끝냈어요.
기술적으로 잘한 선택 3가지
1. 모델을 버전으로 고정하지 않은 것.
Day 2에 gemini-2.5-flash가 하루아침에 막히는 걸 겪은 뒤로, 항상 최신 모델을 가리키는 별칭(gemini-flash-latest)만 썼어요. 이후로는 모델 세대가 바뀌어도 코드를 고칠 일이 없었어요.
2. 저장소를 기능이 아니라 생태계 단위로 나눈 것. Python(CLI/봇)과 TypeScript(확장/사이트)를 억지로 한 저장소에 넣지 않고 4개 레포로 분리했어요. 대신 로직은 절대 두 번 짜지 않는다는 원칙을 지켰어요 — 디스코드 봇은 kodex-code-review-agent를 sys.path로 그대로 import했고, 포트폴리오 사이트는 같은 RAG 로직을 TypeScript로 1:1 포팅했어요.
3. "전시용 데모"라는 경계를 처음부터 정해둔 것.
포트폴리오 사이트에 라이브 데모를 넣기로 한 순간부터, 무료 API 한도를 방문자가 다 써버릴 수 있다는 리스크를 로드맵에 미리 적어뒀어요. 그래서 Day 11에 챗 위젯을 넣을 때 방문자당 제한 + 서버 하루 캡을 처음부터 같이 설계할 수 있었어요.
가장 기억에 남는 삽질 3가지
- Day 2, 모델이 하루아침에 사라진 사건 — 확인해보니 Google이 구버전 모델을 신규 유저에게 순차적으로 막고 있었던 것. 별칭 모델로 바꿔서 근본적으로 해결.
- Day 6, 빌드가 막힌 폰트 요청 —
next/font/google이 빌드 시점에 Google Fonts 서버로 요청을 보내는데, 네트워크가 막힌 환경에선 이 요청 자체가 실패. 시스템 폰트로 전환해서 외부 의존성을 없앰. - Day 9, "Repository not found" — GitHub 레포 생성을 깜빡하고 바로
git push부터 실행해서 난 에러. 원인은 허무할 정도로 단순했지만, 배포 자동화의 첫 단추라 제대로 짚고 넘어간 게 도움이 됐음.
배운 점
가장 크게 느낀 건 "새로 만들지 않는 것"이 "새로 만드는 것"보다 어렵다는 거예요. 디스코드 봇과 챗 위젯을 만들 때마다 "그냥 여기서 새로 짜는 게 빠르지 않을까" 하는 유혹이 있었는데, 매번 기존 로직을 재사용하는 쪽을 택했어요. 처음엔 더 오래 걸렸지만, 결과적으로 로직이 한 곳에만 있어서 나중에 무언가 고칠 때 네 군데를 다 고칠 필요가 없어졌어요.
다음 계획
로드맵 Phase 5, 정리와 운영 단계예요. 이 글이 그 시작이고, 이제부터는 새 기능을 급하게 늘리기보다 지금 만든 것들을 다듬고 백로그를 관리하는 데 집중할 계획이에요.
