[AI 터미널 도구 18~19일차] 프로젝트

Posted Mar 27, 2026

By rkgh17

37 min read

도서명 : AI 자율학습 클로드 코드·코덱스 CLI·제미나이 CLI 완전 활용법

이 포스팅은 길벗 출판사의 코딩 자율학습단 20기 활동의 일환으로, 개인 공부 정리용 포스팅이다.

12장 - 프로젝트 계획 세우기

12.1 - PRD 작성

PRD란

제품 요구 사항 정의서(Product Requirements Document)는 ‘무엇을 만들 것인가’를 정의하는 문서. 전통적 PRD 구성 요소는 다음과 같음

개요
배경
목표/성공 지표
대상 사용자
기능 요구 사항
비기능 요구 사항
제약 사항
범위 및 제외 범위
릴리스 계획

AI기반 개발에서는 이렇게 상세할 필요가 없다. 중요한 것은 AI가 프로젝트 의도, 기능, 범위를 정확히 이해할 만큼 구조화되어 있느냐이다.
PRD는 AI 개발 과정에서 다음과 같은 역할을 한다.

프로젝트 목표와 범위 명확화
AI 코드 생성 시 일관된 방향성 제공
컨텍스트 파일(CLAUDE.md, AGENTS.md, GEMINI.md) 생성의 기반
개발 중 의사결정이 흔들릴 때 기준점 역할

AI와 함께하는 PRD 작성법

최소한으로 필요한 항목
- 제품 개요(한 문장)
- 핵심 기능 3~5개
- 대상 사용자
- 기술 스택
- 비기능 요구 사항(선택)
- 제외 범위(선택)
직접 작성하기
AI에 초안 생성 요청하기
- 개인용 TODO관리 웹 서비스를 만들려고 해. 다음 항목을 포함해 PRD를 작성해줘.-제품개요, 핵심 기능 5개 이하, 기술 스택(FastAPI + HTML/CSS/JavaScript), 비기능 요구사항
작성 시 유의사항
- 지나치게 상세하게 작성할 필요 없음
- 기능 목록을 필요 이상으로 확장하지 않기
- 기술 스택은 반드시 명시하기
- AI에 제공한 파일로 사용할 수 있도록 구조화하기

예시

제품명 : 심플 TODO(simple TODO)

개요 사용자가 할 일을 추가, 조회, 수정, 삭제할 수 있는 웹 기반 TODO 관리 도구입니다.

목표:
1) AI 터미널 도구(Claude Code, Codex, Gemini CLI)를 활용한 풀스택 개발 학습
2) 30분 이내 프로토타입 제작
3) 프런트엔드-백엔드-API 구조를 단일 프로젝트로 경험
   
대상 사용자: 입문자, 개인 사용자, 학습 목적의 실습자

핵심 기능(MVP)
1) 할 일 목록 조회
2) 할 일 추가
3) 완료 처리
4) 삭제

기술 스택
1) 백엔드: FastAPI
2) 프런트엔드: HTML/CSS/JavaScript
3) 저장 방식: 로컬 스토리지(또는 간단한 인메모리 저장)

비기능 요구 사항
1) 직관적인 UI 구성
2) 최신 웹 브라우저에서 정상 동작
3) 입문자도 이해할 수 있는 단순한 구조

제외 범위
1) 사용자 인증(회원가입, 로그인)
2) 데이터베이스 연동
3) 다중 사용자 지원
4) 고급 정렬, 검색 기능
   
API 설계
백엔드 연동 방식으로 학습할 경우 다음과 같은 API를 제공합니다.
1) GET /todos: 할 일 조회
2) POST /todos: 새로운 할 일 추가
3) PUT /todos/{id}: 완료 처리 또는 상태 변경
4) DELETE /todos/{id}: 할 일 삭제

12.2 - 실행 계획과 WBS 작성

실행 계획과 WBS

전통적 프로젝트 관리에서의 역할
1. 실행 계획의 역할
  - 타임라인 정의
  - 작업 간 의존성 파악
  - 리소스 배분
  - 주요 마일스톤 설정
2. WBS의 역할
  - 전체 작업 구조 가시화
  - 담당자 및 역할 배정
  - 진행률 추적
  - 위험 요소 관리
AI 시대의 새로운 접근법
- Claude Code, Codex, Gemini CLI는 모두 다음 기능을 내장
  - 작업 단위 자동 분해
  - 구현 순서 설계
  - 작업 간 의존성 분석
  - 부족한 요건이 있을 경우 확인 질문
- PRD만 명확히 정리해두면 AI가 논리적 흐름을 기반으로 계획을 자동 생성

Claude Code의 계획 모드 활용

계획 모드는 다음과 같은 방식으로 실행 가능

CLI에서 바로 실행 : claude --permission-mode plan
대화형 모드에서 전환 : Alt + M
- @PRD.md 파일을 참고해 전체 작업을 단계별로 나누고, 필요한 세부 작업을 정리해줘
- 이후는 개발자가 세세한 단계를 직접 설계할 필요가 없음

Codex와 Gemini CLI 또한 유사한 방식으로 작업 단계를 나눠준다. 위처럼 요청하면 비슷한 수준의 계획을 생성한다.

AI 시대에도 WBS가 필요한 이유

AI가 순서를 제시할 수 있어도 WBS는 개발자에게 다음과 같은 중요한 가치를 제공한다.

요구 사항을 더 구체적으로 파악할 수 있다.
- WBS를 작성하다 보면 다음과 같은 통찰을 얻게 됨
  - 이 기능을 구현하려면 먼저 데이터 모델이 필요하겠구나
  - 삭제 기능은 예외 처리가 꽤 많을 수 있겠네
- 즉, PRD를 더 탄탄하게 보완하는 데 도움이 됨
프로젝트 구조를 직접 설계해볼 수 있다.
- WBS 작성 자체가 문제를 구조화하는 연습이다. 백엔드를 먼저 만들지, 프런트엔드를 먼저 만들지, API가 어떤 순서로 구현되어야 하는지 등 사고 과정은 문제 분해 능력을 길러준다.
AI가 생성한 계획을 검증할 기준이 된다.
- AI의 계획이 항상 최선은 아니다. WBS가 있으면 AI 계획을 평가하고 필요한 수정 방향을 판단할 수 있다.
학습 효과가 매우 크다
- 특히 입문자에게 WBS는 다음과 같은 교육적 효과가 매우 크다
  - 작업을 작은 단위로 분해하는 연습
  - 백엔드, 프런트엔드, 테스트의 관계 이해
  - 전체 개발 흐름 구조화

간단한 WBS 템플릿

Phase 1: 초기 설정
- 프로젝트 폴더 구조 생성
- 백엔드 환경 설정
- 프론트엔드 환경 설정
- Git 저장소 초기화 및 첫 커밋
- 프로젝트 컨텍스트 파일 작성
Phase 2: 백엔드 개발
- 데이터 모델 설계
- API 엔드포인트 구현
 - 조회 API
 - 생성 API
 - 수정 API
 - 삭제 API
- 오류 응답 구조 정의 및 예외 처리
- API 단위 테스트 및 동작 검증
Phase 3: 프런트엔드 개발
- HTML 기본 레이아웃 구성
- CSS 스타일링
- JavaScript 기능 구현
- 프런트엔드 기능 테스트
Phase 4: 통합 및 배포
- 백엔드와 프런트엔드 연동
- 전체 기능 테스트
- 버그 수정 및 리팩터링
- (선택) 배포 환경 구성 및 실제 배포

12.3 - 컨텍스트 파일 작성

세 도구의 공통 컨텍스트 설계 원칙

세 도구 모두 다음과 같은 정보를 이 파일을 통해 공유받는다

프로젝트 목표 : 무엇을 만드는 프로젝트인지
기술 스택 : 어떤 언어, 프레임워크, 환경에서 작업하는지
코딩 규칙 : 변수명, 함수 분리 원칙, 폴더 구조 등
금지 사항 : 사용하지 말아야 할 라이브러리, 패턴, API 등

세 도구 모두에서 공통으로 유효한 설계 원칙은 다음과 같다.

전역, 프로젝트, 모듈 3단계로 나누기
- 전역 파일 : 개인 선호(언어, 테스트 스타일 등)
- 프로젝트 루트 파일 : 이 프로젝트 전체의 공통 규칙
- 서브폴더 파일 : frontend, backend, 서비스별 특수 규칙
핵시만 남기고 나머지는 별도 문서로 분리
- 컨텍스트 파일은 세션마다 자동으로 로드되므로 길어지면 다음과 같은 문제 발생
  - 토큰 사용량 증가
  - 핵심 내용 파악 어려움
  - 응답 속도 저하
  - 규칙 충돌 가능성 증가
- 따라서 세 도구 모두 다음 네 항목만 담고, 나머지는 별도 문서로 분리하는 방식을 권장한다.
  - 프로젝트 요약(2~3줄)
  - 핵심 작업 규칙(2~3줄)
  - 기술 스택
  - 주요 폴더 및 파일 구조

컨텍스트 파일과 별도 문서의 역할 분리

상세 내용은 다음과 같이 분리하는 것이 가장 효율적이다.

PRD.md : 전체 요구 사항, 기능 목록, 제외 범위 등
api-spec.md, openapi.yaml 등 : 상세 API 스펙
db-schema.md : 데이터베이스 스키마
designs 폴더 : 화면 구조, 컴포넌트 배치, 색상 규치, 크기 규칙 등

13장 - 프로젝트 수행하기

13.1 - 프로젝트 부트스트래핑과 단계발 개발

부트스트래핑 : 초기 실행 환경 만들기

부트스트랩핑(bootstrapping)은 프로젝트를 실행할 수 있는 최소한의 환경을 마련하는 초기 설정 단계를 의미한다. AI 터미널 도구는 PRD, 컨텍스트 파일, WBS를 기반으로 기본 폴더 구조와 초기 파일을 자동 구성할 수 있다.

PRD.md + 컨텍스트 파일 기반 초기 폴더 및 파일 생성
- 이 프로젝트를 시작하려고 해. @PRD.md와 @CLAUDE.md를 참고해 \ FastAPI 백엔드 + 간단한 프런트엔드를 포함한 기본 폴더 구조와 초기 파일을 생성해줘.
필요한 라이브러리 설치 요청
- backend/requirements.txt에 있는 패키지를 설치해줘.
- npm init을 실행하고 필요한 패키지를 설치해줘.
기본 실행 확인
- unicorn main:app --reload로 백엔드를 실행해줘.
- http://localhost:8000/docs가 정상 출력되는지도 확인해줘.

계획 모드에서 만든 plan.md 불러오기

계획 모드에서 만든 개발 계획을 plan.md로 저장해줘.

plan.md 기반 단계별 개발하기

AI 터미널 도구로 개발할 때 효과적인 원칙은 다음 두가지이다.

작은 단위로 단계 실행 요청하기
- @plan.md의 Phase 1을 실행해줘.
- @plan.md의 Phase 1-1 : FastAPI 기본 앱만 생성해줘
- @plan.md의 Phase 1-2 : 프런트엔드 기본 레이아웃만 만들어줘
단계 완료 후 핵심만 확인하기
- 다음 3단계 확인
  - 제대로 실행하는지 : 서버 실행, HTML 로딩 여부 등
  - PRD와 일치하는지 : API 이름, 데이터 구조, 작동 방식 등
  - 불필요한 복잡성이 없는지 : 과도한 추상화, 의미 없는 파일 생성 등
    실전 개발 흐름

계획 모드에서 전체 계획 수립
대화형 모드에서 전환한 후 단계별 개발 시작
백엔드 구현
기본 동작 테스트
프런트엔드 개발
통합 테스트

단계 요청 -> 코드 확인 -> 다음 단계 진행의 반복은 AI와 협업할 때 가장 안정적이며, 개발자에게도 전체 흐름을 명확히 인식하게 해주는 효과적인 방식이다.

13.2 - AI 기반 개발을 위한 테스트 주도 개발

AI기반 개발은 다음과 같은 문제가 자주 발생함

API 응답 구조가 PRD와 미묘하게 다르게 생성됨
파일 간 연결이 어긋남
모델명이나 필드명이 중간에 바뀜
기능 일부가 누락되거나 과도하게 확장됨 이때 가장 효과적인 해결책은 테스트 주도 개발(TDD, Test-Driven Development)이다

TDD가 AI 기반 개발에 필요한 이유

TDD는 다음과 같은 흐름으로 진행

테스트 작성
- 기능이 어떻게 동작해야 하는지 테스트 코드로 먼저 정의
기능 구현
- 테스트를 통과하는 최소한의 코드 작성
테스트 실행 및 수정
- 실패하면 원인을 분석해 다시 수정
리팩터링
- 테스트가 보호막 역할을 하므로 구조 개선을 안전하게 수행

이는 ‘코드를 먼저 작성하고, 나중에 테스트한다’ 는 전통적 방식과는 정반대 전략이다.
TDD를 적용하면 테스트가 곧 기능의 기준선이 되기 때문에 AI가 코드를 생성하더라도 기준에서 벗어나는 일이 크게 줄어든다. 또한 AI CLI 툴들은 테스트 코드 자체도 자동 생성할 수 있어 입문자라도 TDD 접근을 실전에서 부담 없이 활용할 수 있다.

TODO 추가 기능을 TDD로 구현하기

다음은 TODO 웹앱의 핵심 기능인 할 일 추가 기능을 TDD 방식으로 구현하는 예시이다.

테스트 코드 작성 : add_todo() 함수가 올바르게 작동하는지 검증하는 기본 테스트

  
def test_add_todo():
  # 새 TODO를 추가하면
  response = add_todo("장보기")
  # 성공 응답이 와야 한다.
  assert response.status_code = 200
  assert response.data["title"] = "장보기"
  assert response.data["completed"] is False

위 테스트 코드가 명확하게 정의하는 기준은 다음과 같음
- TODO 추가 요청은 200 OK를 반환해야 한다.
- 응답 데이터에는 입력한 제목 “장보기” 가 포함되어야 한다.
- 기본 완료 상태(completed)는 False여야 한다.
테스트 파일이 곧 이 기능의 요구 사항 문서가 된다.

TDD 개발 계획을 세우도록 AI에 요청
- TODO 웹앱을 TDD 방식으로 개발하려고 해. 기능별로 테스트 코드를 먼저 작성한 뒤 구현하는 계획을 세워줘. 계획은 plan.md로 저장해줘.
plan.md 기반으로 단계별 테스트 코드 생성
- plan.md의 내용을 기준으로 테스트 코드를 먼저 작성하게 한다.
- 테스트 파일 자체가 이미 API의 명세서 역할을 하며, AI가 이 기준에 맞춰 구현 코드를 생성하게 만든다.
테스트를 통과할 기능 구현 요청
- 이제 테스트를 통과하도록 GET /todos API를 구현해줘.
- 테스트가 기준선이 되므로 PRD에서 벗어나는 코드가 자동으로 줄어든다.
테스트 실행 및 피드백 반영
- 테스트 실행을 AI에 요청하고, 실패한다면 오류 메시지를 그대로 전달한다.

프런트엔드 테스트 자동화 : Playwright MCP 활용

백엔드 API는 pytest로 비교적 안정적으로 자동 테스트를 수행할 수 있다. 그러나 프런트엔드 테스트는 상황이 다르다. HTML/CSS렌더링, DOM변동, 비동기 처리, UI 이벤트 등 다양한 요소가 결합되기 때문에 테스트 환경을 자동화하기 어려운 영역이다.
이때 Playwright MCP를 활용하면 실제 웹 브라우저를 띄우고, 화면을 클릭하고 입력하는 과정을 자동으로 수행할 수 있다. 즉, 사람이 직접 웹 브라우저에서 눌러보는 과정을 AI가 자동화해주는 것이다.
다음은 기본적인 TODO 흐름을 자동 테스트하는 예시이다.

> Playwright MCP로 다음 시나리오를 테스트해줘.
TODO 웹앱 열기
입력창에 "장보기" 입력
"추가" 버튼 클릭
목록에서 "장보기" 항목이 나타나는지 확인

Playwright MCP는 실제 웹 브라우저를 구동해 다음 순서로 테스트를 실행한다.

웹 브라우저 실행 및 페이지 로드
입력창 요소 탐색 후 텍스트 입력
“추가” 버튼 클릭
DOM 변동 감지 및 목록 업데이트 확인
테스트 리포트 생성

Playwright MCP 사용 시 유의할 점
- UI 요소 동기화 문제
  - UI 렌더링이 끝나기 전에 클릭을 시도하면 실패할 수 있다.
- CSS 선택자 불일치
  - 프런트엔드 구조가 자주 바뀌면 선택자가 맞지 않아 테스트가 실패
- 복잡한 상호작용 자동화 한계
  - 드래그 앤 드롭, 애니메이션, 지연 로딩 등은 자동화 정확도가 떨어질 수 있다.
이러한 한계를 이해하고 사용한다면 Playwright MCP는 다음과 같은 상황에서 탁월한 효율을 보인다
1. 반복적인 시나리오 테스트가 필요할 때
  - TODO 추가 -> 완료 체크 -> 삭제까지 반복 테스트
  - 배포하기 전에 동일 흐름을 매번 점검해야 하는 경우
2. 다양한 UI 케이스를 순차 실행해야 할 때
  - 10개 이상 단계에 걸친 UI 흐름을 자동으로 검증하고 싶은 경우
3. 문서화용 스크린샷 수집이 필요할 때
  - 단계별 화면을 캡처해야 하는 경우 매우 효과적

실전 테스트 중심 개발 흐름

TDD 계획 세우기
- 우선 기능을 테스트 단위로 나누어 계획을 세움
- TODO 앱을 TDD 방식으로 개발하려고 해. 기능별 테스트 케이스를 먼저 정리하고, 테스트 기준으로 정렬된 개발 계획을 만들어줘.
테스트 코드 작성 ```
GET /todos API에 대한 테스트 코드를 작성해줘. 테스트 케이스 :
- 빈 목록 조회
- TODO가 있을 때 목록 조회
- TODO 개수 확인 ```
테스트를 통과하는 최소 코드 구현
- 이 테스트를 통과하도록 GET /todos API를 구현해줘.
- 테스트가 요구하는 만큼만 구현한다. TDD에서 테스트를 통과시키는 최소 코드만 작성한다. 추상화, 성능 고려, 구조 최적화는 나중 단계이다.
테스트 실행 및 피드백 반영
- pytest로 테스트를 실행해줘.
다음 기능 반복
- > 이제 POST /todos API 테스트를 작성해줘.

13.3 - 코드 품질 개선하기

Claude Code 서브에이전트로 코드 리뷰 받기

> security-performance-reviewer 서브에이전트를 사용해 backend/main.py를 보안과 성능 관점에서 리뷰해줘.

보안 이슈
- SQL 인젝션 가능성
- XSS 취약점
- 토큰, 비밀번호 같은 민감 정보의 하드코딩 여부
성능 이슈
- 루프 안에서 반복적인 DB 접근(N+1 문제)
- 중복 연산
- 캐싱 적용 가능 지점
유지보수 및 가독성 개선
- 너무 긴 함수 모듈 분리 필요
- 불명확한 변수명 개선
- 예외 처리 구조 개선

Gemini Security Extension으로 보안 점검 자동화하기

# 기본 사용
> /security:analyze
# 또는 자연어 요청
> 이 코드에서 보안 취약점을 찾아줘.

Security Extension은 다음과 같은 항목을 주로 점검한다.

비밀 정보 및 자격 증명 관리
- API 키, 비밀번호, 토큰이 코드에 직접 포함되어 있는지
- 환경 변수로 분리해야 할 부분이 있는지
데이터 보호
- 암호화가 필요한 데이터가 평문으로 저장 및 전송되는지
- 민감 정보가 로그에 남는지
인젝션 공격 가능성
- SQL 인젝션, XSS, 커맨드 인젝션처럼 입력 값이 그대로 실행 경로에 들어가는지
인증 및 인가 로직
- 인증 없이 접근 가능한 API가 있는지
- 권한 체크가 누락된 엔드포인트가 있는지
LLM 관련 보안
- 프롬프트 인젝션에 취약한 입력 처리가 있는지
- 외부 입력을 그대로 LLM에 전달하는 경우가 있는지

파일 단위로 점검

프로젝트 전체를 한번에 리뷰해달라고 하면 다음과 같은 문제가 발생함

피드백이 너무 포괄적이어서 구체적으로 어떤 파일부터 손봐야 할 지 감이 오지 않음
각 파일에 대한 설명이 짧고, 중요한 디테일이 빠지기 쉬움
수정 범위가 넓어져 어디까지 반영했는지 추적하기 어려움
실무에서는 파일 단위 접근 방식이 널리 쓰이며, AI 기반 개발에서도 훨씬 명확하고 안정적이다.
- > backend/main.py 파일만 자세히 리뷰해줘.
- > 함수별로 보안과 성능 중심으로 개선점을 알려줘.
리뷰를 반영한 뒤 다음 파일로 넘어간다
- > frontend/script.js를 같은 기준으로 리뷰해줘
파일 단위 접근 방식의 장점은 다음과 같다.
- 문제 위치 명확
  - 어느 파일, 어느 함수에서 문제가 있는지를 바로 파악
- 수정 단위 축소
  - 한 파일씩 정리하고 테스트 하면서 진행 가능
- 진행 상황 추적 용이
  - ‘백엔드 핵심 파일은 정리 완료 -> 프런트엔드로 이동’처럼 단계별 관리 가능

리팩터링으로 코드 개선하기

AI 터미널 도구를 사용하면 다음과 같은 상황이 자주 발생한다.

유사한 코드가 여러 파일에 반복됨
임시로 작성한 구조가 누적됨
여러 번의 부분 수정 과정에서 일관성이 무너짐
기존 코드베이스를 AI가 온전히 고려하지 못해 구조가 점점 어지러워짐

이런 이유로, 주요 기능이 일정 수준까지 구현된 시점에 전체 코드를 정리하는 리팩터링 과정이 필요하다.
리팩터링은 동작은 유지하되, 구조, 가독성, 안정성, 확장성을 개선하는 작업이다.

AI에 리팩터링을 요청하는 가장 효과적인 방법
- 리팩터링도 코드 리뷰처럼 파일 단위로 요청하는 것이 가장 안정적
- 기준을 구체적으로 제시할수록 AI는 일관성 있는 리팩터링을 수행
- 리팩터링 후에는 반드시 테스트를 실행해야 한다. ```
  backend/main.py 파일을 리팩터링해줘. 이때 다음 세 가지 기준을 우선 적용해줘.
- 함수 분리
- 중복 제거
- 변수명 명확화

리팩터링된 코드가 정상 작동하는지 테스트를 다시 실행하고, 문제가 있으면 수정해줘 ```

실전 코드 품질 개선 흐름

코드 리뷰 요청
- > backend/main.py를 리뷰해줘. 보안, 성능, 가독성 기준으로 분석해줘.
리뷰 결과 확인 후 우선순위 선정
- 일반적인 우선순위 기준은 다음과 같음
  - 보안 이슈 : 반드시 즉시 수정
  - 성능 이슈 : 실제 성능 지표가 문제가 될 때 수정
  - 가독성 및 구조 이슈 : 일정과 팀 상황에 따라 점진적 개선
우선순위 높은 항목부터 수정
- > 리뷰에서 지적한 SQL 인젝션 위험 부분을 먼저 수정해줘
테스트 실행
- > 수정된 코드가 정상 작동하는지 테스트를 실행해줘.
리팩터링 요청
- > main.py를 더 읽기 좋게 리팩터링해줘.
- > 함수 분리와 중복 제거 중심으로 개선해줘.
리팩터링 후 다시 테스트
다음 파일로 확장
- > 이제 frontend/script.js도 같은 기준으로 리뷰해줘.

13.4 - 배포와 운영

배포와 운영의 기본 개념

배포
- 로컬에서 실행되는 웹앱을 인터넷에서 접근 가능한 형태로 올리는 과정
  - 누구나 웹 브라우저로 접속 가능
  - 24시간 서비스 실행
  - 여러 사용자가 동시에 이용 가능
운영
- 배포된 서비스가 안정적으로 작동하도록 관리하는 과정
  - 오류와 예외 모니터링
  - 성능 지표 확인
  - 장애 발생 시 대비 및 복구
  - 신규 기능 업데이트 및 재배포
  - 데이터 백업과 관리

Claude Code, Codex, Gemini CLI는 배포 자체를 직접 실행하는 플랫폼이 아님. 그러나 AI는 배포에 필요한 파일, 설정, 문서, 가이드를 빠르고 정확하게 생성해 준다.

dockerfile 자동 생성
GitHub Actions(workflow.yml) 파일 생성
Cloudflare, Vercel, Railway 배포 스크립트 작성
환경 변수(env) 구성 문서 자동 생성
배포 오류 로그 분석 및 해결 가이드

주요 배포 서비스 비교

Cloudeflare Pages/Workers - 가장 빠르게 결과를 보고 싶을 때
- 장점
  - 전 세계 CDN 기반 빠른 응답 속도
  - GitHub 자동 배포
  - 무료 플랜이 넉넉함
  - Workers로 간단한 서버 구현 가능
- 단점
  - Node.js 환경과 달라 백엔드 초보자에게 낯설 수 있음
  - FastAPI 같은 독립 서버 직접 호스팅은 어려움
- Cloudflare는 MCP 서버 연결 기능을 제공하기 때문에 AI가 Cloudflare용 설정 파일을 쉽게 생성할 수 있다.
Netlify - 프런트엔드 위주 프로젝트에 최적
- 정적 웹 사이트, 학습용 프런트엔드 앱 배포에 매우 적합
- 장점
  - 무료 플랜 제공
  - Git 기반 자동 배포(CI/CD) 내장
  - Netlify Functions로 간단한 서버 기능 제공
  - Forms 기능 제공
- 단점
  - FastAPI, Express 같은 백엔드 직접 배포 불가
  - SSR 지원이 Vercel보다 제한적
Railway - FastAPI를 포함한 풀스택 입문자에게 가장 현실적
- 다양한 서버 환경을 지원하며 FastAPI 백엔드와 프런트엔드를 함께 배포하기 좋은 서비스이다.
- 장점
  - 서버 언어 다양하게 지원
  - PostgreSQL 같은 DB 제공
  - Docker 배포 가능
  - 설정이 단순해 입문자 친화적
- 단점
  - 무료 플랜이 $5 크레딧으로 제한
  - 대규모 트래픽 처리에는 부족함

Study

AI CLI 코딩 자율학습단 20기

This post is licensed under CC BY 4.0 by the author.