# Phase 123까지 오면서 깨달은 것들 — Claude Code로 교육 플랫폼을 만든 3개월의 기록
Phase 123까지 오면서 깨달은 것들 — Claude Code로 교육 플랫폼을 만든 3개월의 기록
작년 12월, 빈 프로젝트 하나를 열었습니다. Spring Boot와 Next.js로 교육생들이 쓸 LMS를 하나 만들어보자는 생각이었습니다. 혼자서. AI한테 코딩을 시키면서.
2026년 2월 28일 현재, 그 프로젝트의 Phase 번호는 123입니다. 석 달 동안 123번 개선했습니다. 매일 한두 개씩 Phase를 쌓았고, 어떤 날은 하루에 세 개를 밀어 넣기도 했습니다. 그 과정에서 GCP 서버리스에서 출발해 단일 VM으로 옮기고, 다시 OCI ARM 서버로 이사했습니다. HLS 비디오 스트리밍 파이프라인을 정성 들여 만들었다가 통째로 삭제했습니다. 프레임워크 메이저 버전을 세 개 동시에 올리고, 하루 11,000건의 봇 트래픽과 싸우고, 교육생에게 블로그를 써보라고 했는데 아무도 안 써서 결국 블로그 플랫폼 자체를 만들었습니다.
이 글은 그 3개월의 솔직한 기록입니다.
12월: 테이블 16개로 시작한 날
Phase 1의 산출물은 MySQL 테이블 16개와 Spring Boot 엔티티 클래스 묶음이었습니다. User, Course, CourseMember, Classroom, InvitationToken. 교육 플랫폼의 뼈대가 될 스키마를 Claude Code와 함께 설계했습니다. 역할 체계를 시스템 레벨(NORMAL/INSTRUCTOR/ADMIN)과 과정 레벨(INSTRUCTOR/TUTOR/STUDENT)로 나누고, 권한 검사를 CourseAccessChecker라는 단일 게이트키퍼에 모았습니다.
이때는 솔직히 좀 의심이 있었습니다. AI에게 코딩을 시켜서 실제 서비스가 될 만한 걸 만들 수 있을까. Phase 2에서 OAuth2 소셜 로그인(Google, Kakao, Naver)과 JWT 인증을 붙이고, Phase 3~10에서 수업 관리, QR 초대, Q&A 시스템을 올리면서 의심은 조금씩 줄었습니다. 속도가 빨랐거든요. 혼자서 이 속도가 나온다는 게 좀 믿기지 않았습니다.
하지만 속도가 빠르다는 건, 문제도 빠르게 온다는 뜻이었습니다.
1월: 비용과의 전쟁이 시작되다
GCP Cloud Run 위에 서비스를 올리니 첫 달 청구서가 나왔습니다. Cloud Run 세 개(백엔드, 프론트엔드, Playwright), Cloud SQL, 로드밸런서. 동시 접속자가 열 명도 안 되는 서비스에 월 23만~34만 원이 나갔습니다.
Phase 16에서 첫 번째 비용 절감을 시도했습니다. Spring Boot의 @Scheduled 작업들을 GCP Cloud Scheduler HTTP 호출로 바꾸고, Cloud Run의 cpu-throttling을 켰습니다. 비용이 약 40% 줄었습니다. 그런데 아직 비쌌습니다.
Phase 33에서는 Playwright(헤드리스 브라우저로 뉴스를 크롤링하는 용도)를 별도 Cloud Run 서비스로 분리했습니다. 이 과정에서 악명 높은 버그를 만났습니다. Playwright가 Spring Boot Fat JAR 안에서 Chromium 드라이버를 추출하다가 ZipException: read CEN tables failed를 뱉는 문제였습니다. Spring Boot의 Fat JAR 포맷이 중첩 ZIP을 쓰는데, Playwright의 압축 해제 로직이 이걸 처리하지 못한 겁니다. Spring Boot layertools로 JAR을 풀어서 실행하는 방식으로 해결했습니다. 하루를 통째로 썼습니다.
"분명히 주석 처리했는데 왜 429가 나오지?"
1월의 가장 기억에 남는 삽질은 Phase 57입니다. 내가 만든 서비스를 내가 쓰는데 HTTP 429 Too Many Requests가 떴습니다. 사용자라곤 나뿐인 서비스에서.
RateLimitFilter.java를 SecurityConfig에서 주석 처리한 걸 분명히 기억하는데, k6로 부하 테스트를 돌려보니 에러율이 96%였습니다. 원인을 찾는 데 두 시간이 걸렸습니다. @Component 어노테이션이 붙어 있으면 Spring Boot가 SecurityConfig와 무관하게 서블릿 필터로 자동 등록하거든요. SecurityConfig에서 빼봤자 소용없습니다. 파일을 삭제해야 끝나는 문제였습니다.
그런데 진짜 문제는 이게 아니었습니다. 429를 잡고 나서 Cloud Run 로그를 다시 분석했더니 충격적인 숫자가 나왔습니다.
89회 /api/notifications/unread-count ← 전체 API 호출의 89% 2회 /api/site/settings/social 2회 /api/site/pages/business
알림 폴링이 30초마다 돌고, 페이지 이동할 때마다 재시작하고, 브라우저 탭마다 독립적으로 실행되고 있었습니다. 전체 API 호출의 89%가 알림 카운트 조회 한 개. 서비스 전체가 알림 확인 기계가 되어 있었던 겁니다.
폴링 간격을 120초로 늘리고, 탭이 비활성일 때 Page Visibility API로 폴링을 멈추고, 알림 목록은 드롭다운을 열 때만 로드하도록 바꿨습니다. API 호출이 83% 줄었습니다. 코드 몇 줄로.
AI로 개발하면서 자주 겪는 일입니다. Claude Code가 기능을 잘 만들어줍니다. 알림 시스템? 30분이면 되거든요. 그런데 그게 프로덕션에서 어떻게 동작하는지까지는 AI가 알아서 판단하지 않습니다. 로그를 직접 열어보고 숫자를 확인해야 합니다.
Cloud Run은 비슷한 문제를 하나 더 안고 있었습니다. 게시글을 저장하는데 16초가 걸린 겁니다. 백엔드 API는 정상(PUT 85ms, 목록 조회 30ms)인데, 프론트엔드 Cloud Run의 containerConcurrency가 1로 설정되어 있었습니다. Next.js 이미지 최적화가 CPU 0.5 vCPU에서 6~9초씩 걸리는데, 그동안 다른 모든 요청이 차단됩니다. 이미지 최적화 + 새 인스턴스 cold start + 대기 = 16초. 설정 세 줄(Concurrency 80, CPU 1, 메모리 1Gi)로 해결했습니다.
이런 일이 반복되면서 깨달은 게 있습니다. 서버리스의 비용 모델은 "쓴 만큼만 낸다"이지만, "쓴 만큼"의 정의가 생각보다 복잡합니다. 생각지도 못한 곳에서 인스턴스가 뜨고, 거기서 비용이 쌓입니다.
부하 테스트 4라운드: "좀 더 밀어보면 어디서 터질까?"
2월 초, 수업이 다가오고 있었습니다. 교육생 20명이 동시에 접속할 텐데, 서비스가 버틸까. k6로 부하 테스트를 시작했는데, 한 번 시작하니까 호기심을 멈출 수가 없었습니다.
1라운드: db-f1-micro(월 7천 원짜리 MySQL)에서 커넥션 풀을 최적화했습니다. 안전 구간은 동시 10명 정도.
2라운드: DB를 db-g1-small로 업그레이드했습니다. 월 1만 8천 원 추가. 안전 구간이 20명으로 올랐습니다.
3라운드: 여기서 중요한 걸 발견했습니다. 홈 API를 분석했더니 HomeService에서 N+1 쿼리가 돌고 있었습니다. Q&A 게시글 전체를 가져온 다음, 게시글마다 COUNT(*) 쿼리로 답변 수를 세고 있었습니다. 게시글 100개면 쿼리 101개. 이걸 집계 쿼리 하나로 바꾸고 Caffeine 캐시(60초 TTL)를 얹었더니 홈 API의 p95가 1.46초에서 14밀리초로 떨어졌습니다. 비용은 0원이었습니다.
4라운드: 실제 사용 패턴을 반영한 혼합 트래픽 테스트. 동시 200명, TPS 90, 에러율 0%.
돌이켜 보면 최적화 순서가 거꾸로였습니다. 돈을 먼저 쓰고(DB 업그레이드), 나중에 무료 수정(N+1 제거)을 했습니다. 무료 코드 수정이 3배 효과를 냈고, 유료 DB 업그레이드는 2배 효과였습니다. 코드를 먼저 고치고 나서 그래도 모자라면 인프라를 올렸어야 합니다.
11개 Phase에 걸쳐 만든 기능을 삭제했습니다
2월 중순, 가장 어려운 결정을 내렸습니다. 두 달에 걸쳐 11개 Phase로 만든 뉴스 자동화 기능을 전부 삭제한 겁니다.
RSS 수집, OpenAI API로 관련성 점수 매기기, 번역, 카테고리 분류, 자동 게시. Playwright를 별도 서비스로 분리한 것도 이 뉴스 기능 때문이었습니다. 5,673개의 뉴스 아이템이 쌓여 있었습니다.
Google Analytics를 열어봤습니다. 뉴스 페이지의 사용자 행동은 분명했습니다. 들어와서, 뉴스를 읽고, 나갑니다. 강의도 안 보고, Q&A도 안 쓰고, 커뮤니티에도 안 갑니다. 뉴스 페이지는 섬이었습니다. 플랫폼으로 연결되는 다리가 아니었습니다.
번역 품질도 문제였습니다. 비용을 아끼려고 저렴한 모델을 썼더니, 원문 영어를 읽는 게 더 나은 수준이었고요. 솔직히 긱뉴스가 이미 사람 손으로 큐레이션한 한국어 기술 뉴스를 더 잘 제공하고 있었습니다.
주식도 떨어질 때 파는 게 가장 어렵고, 서비스 개발도 만들어 놓고 삭제하는 게 어렵습니다. 만드는 건 재미있었거든요. Phase마다 뭔가 진전하는 느낌이었고, 기술적 문제 하나를 풀면 다음 문제가 자연스럽게 따라왔습니다. 지나고 보니 "이 기능이 필요한가?"가 아니라 "이 기술 문제를 어떻게 풀까?"에 빠져 있었던 겁니다.
비슷한 시기에 HLS 비디오 스트리밍 파이프라인도 정리했습니다. GCS에 원본을 올리면 GCP Transcoder API가 HLS로 변환하고, Cloud CDN + Signed Cookie로 재생하는 구조를 Phase 34~35에 걸쳐 만들었습니다. 크로스 도메인 쿠키 문제, HLS.js의 withCredentials 설정까지 고생하면서 완성했는데, VM으로 이전하면서 CDN 구조가 바뀌어 유지할 이유가 없어졌습니다. VOD 버킷(162MB)을 삭제하고, Transcoder 템플릿을 정리했습니다. 백엔드 코드는 살려뒀습니다. 나중에 다시 필요할 수 있으니까.
Claude Code로 만들면 기능 하나를 뚝딱 올리는 데 하루면 됩니다. 그래서 더 위험합니다. 만드는 비용이 낮으니까 "일단 만들어보자"를 너무 쉽게 결정합니다. 지우는 비용은 만드는 비용과 비례하지 않습니다. 데이터 마이그레이션, 의존성 정리, 삭제된 기능의 참조를 전부 추적해서 걷어내야 합니다. 설계 단계에서 "이게 정말 필요한가"를 묻는 습관이 AI 시대에 오히려 더 중요해졌습니다.
인프라 삼국지: Cloud Run → GCP VM → OCI ARM
1막: 서버리스 탈출 (Phase 104)
2월 16일, Cloud Run에서 단일 GCP VM으로 이사했습니다. e2-highmem-2(2 vCPU, 16GB RAM) 하나에 Docker Compose로 Nginx, Spring Boot, Next.js, MySQL, 이미지 서비스를 전부 올렸습니다.
DNS를 전환하고 한숨 돌리는데, 게시판에서 이미지 업로드가 안 된다는 걸 발견했습니다. TLS 1.3 PSK 세션 바인더 에러였습니다. Chrome이 www.fullstackfamily.com의 TLS 세션을 api.fullstackfamily.com에 재사용하려고 시도하면서 ERR_SSL_PROTOCOL_ERROR가 발생한 겁니다. Nginx에서 ssl_session_tickets on을 설정해서 각 서브도메인이 독립적으로 세션을 관리하도록 바꿨습니다.
버튼 하나 누르는 순간이 좀 떨렸습니다. DNS 전환은 되돌리는 데 전파 시간이 걸리니까. 그래서 이전 Cloud Run 서비스를 2주간 살려두고, 금요일 저녁에 전환해서 주말에 대응할 시간을 확보했습니다.
월 비용이 23만~34만 원에서 10만~14만 원으로 떨어졌습니다.
2막: OCI로 두 번째 이사 (Phase 122)
GCP VM에서 소프트웨어 튜닝은 다 끝냈는데, 부하 테스트의 병목은 분명했습니다. CPU. 2 vCPU로는 동시 300명을 넘기면 요청이 큐에 쌓이기 시작합니다. 코드를 아무리 고쳐도 CPU가 부족하면 소용없습니다. 하드웨어를 바꿔야 했습니다.
Oracle Cloud의 Always Free Tier를 노렸습니다. 4 OCPU ARM, 24GB RAM, 200GB 스토리지. 무료입니다. 같은 Docker Compose를 올리기만 하면 됩니다. ARM 이미지? nginx, mysql:8.0, eclipse-temurin:21, node:20-alpine 전부 공식 ARM 빌드가 있습니다.
그런데 Free Tier VM을 만드는 게 안 됩니다. "Out of host capacity" 에러가 끊임없이 나왔습니다. 60초마다 VM 생성을 재시도하는 스크립트를 돌렸습니다. 며칠을 돌렸습니다. 안 됐습니다. OCI Always Free Tier는 춘천 리전에서 용량이 고갈된 상태였습니다.
결국 PAYG(종량제)로 전환했습니다. 6 OCPU, 32GB RAM, 300GB로 구성하면 월 약 3.5만 원. GCP의 8만 원에서 56% 절감입니다. 그래도 3배 성능입니다.
부하 테스트 결과가 너무 달라서 처음에 테스트를 잘못 돌린 줄 알았습니다.
| 지표 | GCP 2 vCPU | OCI 4 OCPU ARM | 변화 |
|---|---|---|---|
| 초당 처리량 | 35.2 | 70.8 | +2배 |
| 응답 중앙값 | 1.31초 | 0.052초 | -96% |
| p95 | 9.77초 | 3.27초 | -67% |
| 타임아웃 | 28% | 0% | 제거 |
| 월 비용 | ~8만 원 | ~3.5만 원 | -56% |
응답 중앙값이 1.31초에서 52밀리초로 떨어졌습니다. 96% 감소. CPU 코어가 넉넉하니까 요청이 큐에 쌓이지 않고 바로 처리됩니다. 2 vCPU에서는 300개 요청 중 270개가 큐에서 대기했고, 4 OCPU에서는 대기 자체가 사라졌습니다.
인프라 비용의 여정을 정리하면 이렇습니다.
Phase 시작 Cloud Run + Cloud SQL + LB 월 ~34만 원 Phase 16 cpu-throttling 적용 월 ~22만 원 Phase 33 Playwright 분리 월 ~17만 원 Phase 104 단일 GCP VM 월 ~12만 원 Phase 122 OCI ARM VM 월 ~3.5만 원
출발점 대비 90% 절감. 솔직히 처음부터 VM 하나로 시작했으면 됐습니다. 동시 접속자 100명도 안 되는 서비스에 서버리스는 과했습니다.
교육생이 안 써서 직접 만든 것들
이건 기술 이야기가 아니라 교육자의 이야기입니다.
교육생에게 블로그를 써보라고 했습니다. 개발 일지를 남기면 실력이 늘고, 포트폴리오가 되고, 면접에서도 쓸 수 있다고. 아무도 안 썼습니다.
이유를 곰곰이 생각해봤습니다. 초보 개발자가 첫 블로그 글을 쓰는 건 꽤 용기가 필요한 일입니다. 글을 올렸는데 반응이 없으면, 두 번째 글은 안 씁니다. velog나 tistory에 올리면 강사인 제가 그걸 찾아다니면서 댓글을 달아줘야 합니다. 교육생이 50명이면 50개의 블로그를 돌아다녀야 합니다.
그래서 플랫폼 안에 블로그 기능을 만들었습니다. Phase 7개를 들였습니다(Phase 82, 83, 94, 95, 96, 99, 101). "Phase 한두 번이면 될 줄 알았습니다." 처음엔 UnifiedPost 테이블에 확장 테이블 하나 붙이면 된다고 생각했습니다.
현실은 달랐습니다. 가입하면 블로그가 자동으로 생기게 하고, URL을 /@닉네임 형태로 예쁘게 만들고, 시리즈 기능을 달고, 메인 피드에 연동하고. "Phase 한두 번이면 될 줄 알았습니다"가 Phase 7개로 불어났습니다.
가장 중요한 발견은 기술적인 게 아니었습니다. 블로그를 만들고 나서 메인 피드에 블로그 게시글이 안 나오는 걸 발견한 겁니다. 한 줄짜리 플래그 설정이 빠져 있었습니다. 아무도 안 보는 블로그는 없는 것보다 못합니다. 기능을 만드는 것과 기능이 사용되게 하는 건 전혀 다른 문제입니다.
포인트/레벨 시스템(Phase 81)도 같은 맥락이었습니다. 오래 활동한 사람과 방금 가입한 사람이 똑같아 보이면, 활동할 동기가 생기지 않습니다. 글쓰기에 50점, 댓글에 10점, 출석에 20점. 기술적 난이도보다 이 숫자의 밸런스를 잡는 게 훨씬 어려웠습니다. 일일 상한을 몇으로 잡아야 어뷰저를 막으면서 일반 사용자에게 답답하지 않은지. 이건 코드가 아니라 커뮤니티 운영의 영역이었습니다.
프레임워크 세 개를 하루에 올리다
Phase 88, 2월 10일. Next.js 14 → 15, React 18 → 19, Tailwind CSS 3 → 4를 하루에 전부 올렸습니다.
Next.js 14가 2025년 10월에 EOL이 됐는데 3개월 넘게 방치하고 있었습니다. OAuth, 결제(TossPayments), 파일 업로드가 돌아가는 서비스에서 보안 패치가 안 나온다는 건 부담이었습니다.
코드베이스에 TypeScript/TSX 파일이 830개 있었습니다. Next.js 15의 params가 Promise 타입으로 바뀌면서 78개 파일의 340군데를 고쳐야 했고, Tailwind v4에서 rounded 클래스 이름이 바뀌면서 2,002군데가 영향을 받았습니다. border 기본 색상이 gray-200에서 currentColor로 바뀌어서 갑자기 검은 테두리가 나타나는 파일이 65개.
codemod를 최대한 돌리고, 나머지는 수작업으로 고쳤습니다. npm run build 에러 0개 확인까지 하루가 걸렸습니다. Tailwind 설정은 기존 tailwind.config.ts(타이포그래피 커스텀 설정 233줄)를 @config 호환 모드로 유지하는 실용적인 선택이었습니다. 완벽한 마이그레이션보다 동작하는 마이그레이션이 중요하니까요.
봇과의 전쟁, 그리고 매일의 사소한 싸움들
하루 11,000건의 요청이 들어오는데, 30%가 404였습니다. SemrushBot이 혼자서 전체 트래픽의 27%를 차지하고 있었고, 누군가는 wp-login.php와 .env를 두드리고 있었습니다. 이 사이트는 Next.js + Spring Boot인데.
nginx에서 User-Agent 기반으로 차단했습니다. 하루 만에 해결된 일이지만, 이런 게 매일 나옵니다. Cloudflare R2 캐시가 4시간마다 만료되어서 이미지 로딩이 느린 문제, iPhone Chrome에서 유튜브 임베드가 검은 화면으로 나오는 CSP 이슈, 타임존이 UTC와 Asia/Seoul로 섞여서 게시글 시간이 어긋나는 버그, 메인 피드에서 글이 사라지는 published_at 마이그레이션 타이밍 함정.
하나하나는 사소합니다. 하지만 Phase 123까지 쌓이면 이런 사소한 것들의 총합이 서비스의 품질입니다. "하루 만에 만든 서비스"와 "123번 고친 서비스"의 차이는 기능 목록이 아니라 이런 디테일에 있습니다.
Claude Code와 함께 일한다는 것
123개 Phase를 관통하는 도구는 Claude Code였습니다. 커스텀 스킬을 23개 만들었고, CLAUDE.md가 425줄입니다. 솔직히 Claude Code 없이 석 달에 123 Phase는 못 했습니다. 혼자서 Spring Boot 백엔드, Next.js 프론트엔드, MySQL 스키마 설계, Docker 배포, 부하 테스트, 블로그 글까지 동시에 돌리는 건 물리적으로 안 되거든요.
어떻게 일하는지 하나만 보여드리겠습니다. Phase 123, 게시판에 Canvas 그림판을 넣은 작업입니다. /plan-phase로 시작합니다. 이 스킬은 코드베이스를 분석하고, 기존 이미지 업로드 파이프라인의 구조를 파악한 다음 개발계획서를 만들어줍니다. 이때 중요한 건 제가 "백엔드 변경 없이 기존 업로드 API를 재사용해라"라는 방향을 먼저 잡아준 겁니다. AI에게 전체 설계를 맡기면 대개 새 API를 추가하자고 합니다. 기존 구조를 아는 건 사람이니까, 제약 조건은 제가 정하고 구현은 AI가 합니다.
계획이 확정되면 /dev-frontend로 구현에 들어갑니다. DrawingCanvas.tsx 491줄이 나왔는데, 한 번에 완성된 게 아닙니다. 처음 나온 코드에서 Retina 디스플레이 대응이 빠져 있었고, 캔버스를 flex 컨테이너에 넣었더니 max-height: 100%가 안 먹더라고요. 이런 문제를 발견할 때마다 피드백을 주면 Claude Code가 수정합니다. ESC 키를 눌렀을 때 그리는 중에 모달이 닫히는 문제는 제가 직접 재현해서 "캡처 단계 이벤트 리스너로 막아라"고 구체적으로 지시한 거죠. 결과적으로 백엔드 변경 0줄, 프론트엔드만으로 끝났고, MarkdownEditor에 onImageUpload prop이 있는 모든 곳에서 자동으로 그림판이 활성화됐습니다.
Phase 81은 규모가 달랐습니다. 포인트/레벨 시스템, 82개 파일. 백엔드 28개, 테스트 12개, 프론트엔드 28개, 프론트엔드 테스트 13개. 당연히 한 번에 시킨 게 아닙니다. /dev-backend로 엔티티와 서비스를 먼저 만들고, 테스트를 돌려서 통과시키고, 그다음 /dev-frontend로 UI를 올리고, /test-frontend로 빌드와 타입 체크를 확인하는 식으로 Phase 안에서도 단계를 나눴습니다. 비동기 이벤트 처리에서 트랜잭션 경계 문제가 나왔을 때(좋아요를 누른 사용자와 받은 사용자의 경험치를 같은 트랜잭션에서 처리하면 데드락), 이건 Claude Code가 먼저 경고해줬습니다. 별도 이벤트로 분리하라는 제안까지. 이런 부분에서는 AI가 사람보다 꼼꼼하더군요.
그렇다고 AI가 만능이라는 이야기는 아닙니다.
알림 폴링이 API 호출의 89%를 차지하는 걸 AI가 먼저 발견하지는 않았습니다. 뉴스 기능의 GA 지표가 나쁜 걸 보고 삭제를 결정한 것도 제가 했고요. AI는 시키는 걸 잘 만들어주지만, 만들어야 하는지의 판단은 사람의 몫입니다. 만드는 비용이 낮아질수록, 지우는 판단이 더 중요해지고요.
프로덕션 경험도 대체가 안 됩니다. Cloud Run concurrency 1의 함정, TLS 1.3 PSK 세션 에러, OCI Always Free Tier의 capacity 고갈, Cloudflare가 한국 사용자를 시애틀 POP으로 라우팅하는 문제. 코드를 아무리 잘 짜도 실서비스를 운영해봐야 만나는 것들입니다. AI한테 물어봐도 답이 안 나옵니다. 겪어봐야 압니다.
그래서 123 Phase 뒤에 남은 것
3개월 동안 123개 Phase를 돌리고, 인프라를 세 번 옮기고, 월 비용을 34만 원에서 3.5만 원으로 줄이고, 11개 Phase 분량의 기능을 만들었다가 삭제했습니다. 블로그를 50개 넘게 썼습니다.
숫자보다 남는 건 습관입니다. 매 Phase마다 개발계획 문서를 먼저 쓰고, 완료 문서를 남기고, 블로그로 정리하는 루틴이 자리 잡았습니다. Claude Code의 커스텀 스킬로 이 파이프라인을 자동화했습니다. /plan-phase로 계획을 세우고, /start-phase로 브랜치를 만들고, /dev-backend와 /dev-frontend로 구현하고, /finish-phase로 머지합니다. 이 파이프라인 자체도 Phase를 거듭하면서 계속 고쳤습니다. 처음에는 스킬이 5개였고, 지금은 23개입니다.
솔직히 이것도 3개월 뒤에 어떻게 바뀔지 모릅니다. Phase 200쯤 되면 지금 구조를 또 뒤집고 있을 수도 있습니다. GCP에서 VM으로, VM에서 OCI로 옮겼듯이.
Phase 123은 게시판에 Canvas 그림판을 넣은 작업이었습니다. DrawingCanvas.tsx 491줄, 백엔드 변경 0줄. 기존 이미지 업로드 파이프라인을 그대로 재사용했고, MarkdownEditor가 있는 모든 곳에서 자동으로 활성화됐습니다. Phase 1에서 테이블 16개를 설계하던 때와는 감각이 다릅니다. 122번의 시행착오가 만든 감각입니다. 어디를 건드려야 하고 어디를 건드리지 말아야 하는지, 새로 만들어야 하는지 기존 걸 재사용해야 하는지. 이건 AI가 대신 쌓아줄 수 없는 감각입니다.
내일은 Phase 124입니다.
댓글
댓글을 작성하려면 이 필요합니다.