4장. 로컬에서 서비스 만들기 (React + Express + PostgreSQL)

드디어 서비스를 만듭니다. 3장에서 "무엇을 만들지"를 기획으로 정리했으니, 이번 장에서는 그 기획을 실제로 동작하는 서비스로 바꿉니다. 다시 강조하지만, 여러분은 코드를 한 줄도 직접 타이핑하지 않습니다. 3장에서 정리한 기획을 Claude Code에게 넘기고, "요청(프롬프트) → 승인 → 확인"을 반복하며 완성해 나갑니다. 이 장의 핵심은 "어떤 코드가 만들어지는가"가 아니라 "어떻게 요청하고, 무엇을 확인하는가" 입니다.

한 조각을 만들 때마다 눈으로 확인하고 다음으로 넘어갑니다. 그래야 문제가 생겨도 어디서 틀어졌는지 바로 찾을 수 있습니다. 순서대로 따라오세요.

[지금 여기]

우리는 22단계를 거쳐 "라이브 투표 서비스"를 직접 만들고, 컨테이너에 담아, AWS 클라우드에 배포합니다. 아래가 그 전체 여정 지도입니다. 지금은 4단계, 서비스를 처음으로 내 컴퓨터에서 동작시키는 자리에 있습니다.

1. 1장개발 환경 준비 (터미널 / Node.js / Git / GitHub / VS Code / Claude Code)
2. 2장Claude Code 사용법 익히기
3. 3장무엇을 만들지 기획 (라이브 투표 서비스)
4. 4장로컬에서 서비스 만들기 (React + Express + PostgreSQL)
5. 5장Docker 개념
6. 6장Dockerfile 작성
7. 7장컨테이너 빌드·실행
8. 8장AWS 시작 (계정 / IAM / 리전 / 비용)
9. 9장이미지 태깅
10. 10장ECR에 이미지 올리기
11. 11장VPC 네트워크 구성
12. 12장RDS 데이터베이스 생성
13. 13장SSM 터널로 RDS 초기화
14. 14장ECS Fargate + ALB로 배포 (기본 완성)
15. 15장CI/CD (GitHub Actions)
16. 16장IaC (Terraform)
17. 17장배포 자동화 연결
18. 18장현업 운영 구조 이해
19. 19장무중단 배포
20. 20장신규 버전 배포 & 롤백
21. 21장(심화) 프론트를 Vercel로 분리 배포
22. 22장마무리 (회고 + 리소스 삭제)

• 방금 끝낸 것: 3장에서 "라이브 투표 서비스"를 무엇으로 만들지 기획했습니다. 설문·선택지·득표수 데이터 모델과, 서버가 열어 줄 세 개의 창구(엔드포인트)를 종이에 그리듯 정리해 두었습니다.
• 이번 장에서 하는 것: 그 기획을 Claude Code에게 넘겨, 프론트엔드 + API 서버 + 데이터베이스로 이루어진 투표 서비스를 내 컴퓨터(localhost)에서 실제로 동작시킵니다. 마지막에는 GitHub에도 올립니다.

이번 장에서 완성되는 것

한 문장으로: 투표를 만들고, 표를 던지고, 결과를 막대그래프로 보는 웹 서비스가 내 컴퓨터에서 돌아가고, 새로고침해도 결과가 그대로 남습니다.

이렇게 되면 성공입니다: 브라우저에서 http://localhost:5173에 접속해 설문을 만들고 투표한 뒤, 페이지를 새로고침해도 득표수가 사라지지 않고 그대로 보입니다. 그리고 그 코드가 GitHub의 내 비공개 저장소에 올라가 있습니다.

사전 조건

이 장은 1~3장의 결과물 위에서 시작합니다. 아래가 갖춰져 있어야 합니다.

• 1장 완료: Node.js, Git, VS Code, Claude Code가 설치돼 있고, 문서 폴더에 vote-app 폴더가 있으며, VS Code로 그 폴더를 열 수 있습니다.
• 2장 완료: Claude Code에 프롬프트로 지시하고, 오류가 나면 메시지를 붙여넣어 고쳐 달라고 하는 흐름에 익숙합니다.
• 3장 완료: 투표 서비스의 기획(설문 데이터 모델 polls/options, 세 엔드포인트)이 정리돼 있습니다.
• 시작 상태 만들기: VS Code를 실행해 파일 → 폴더 열기(Open Folder)로 vote-app을 엽니다. 터미널 → 새 터미널(New Terminal)로 터미널을 열고, 아래로 위치를 확인한 뒤 claude를 실행합니다.

pwd            # 경로 끝이 /vote-app 이어야 합니다

claude         # Claude Code 실행 (AI 입력창이 뜹니다)

4.1 우리가 만들 서비스의 3층 구조

본격적으로 만들기 전에, 우리가 만들 서비스가 어떤 조각들로 이루어지는지 알아 둡시다. 대부분의 웹 서비스는 세 개의 층으로 나뉩니다.

세 층은 이렇게 협력합니다. 사용자가 화면(프론트엔드)에서 버튼을 누르면, 그 요청이 API 서버(백엔드)로 가고, 서버는 데이터베이스에서 값을 꺼내거나 바꾼 뒤 결과를 화면으로 돌려줍니다.

실제로 어디에 쓰이나. 이 3층 구조는 우리 투표 서비스만의 특별한 방식이 아니라, 여러분이 매일 쓰는 서비스 대부분이 이 구조입니다.

• 쇼핑몰: 상품 목록 화면(프론트) → 주문·결제 처리(API) → 상품·주문 정보 저장(DB).
• SNS: 피드 화면(프론트) → 글 올리기·좋아요 처리(API) → 게시물·댓글 저장(DB).
• 배달 앱: 가게·메뉴 화면(프론트) → 주문 접수·배차(API) → 주문 상태 저장(DB).

공통점이 보이죠. 보여 주는 층 / 처리하는 층 / 저장하는 층을 나누면, 각 층을 따로 만들고 따로 고칠 수 있어 편합니다. 우리도 이 순서대로 프론트 → API → DB를 하나씩 붙여 갑니다. 이 그림을 머릿속에 넣어 두면, 앞으로 무엇을 만드는지 길을 잃지 않습니다.

4.2 프로젝트 뼈대 만들기

이제 3장에서 준비한 기획을 Claude Code에 넣습니다. 곧바로 코드를 만들게 하지 말고, 계획을 먼저 받아 보는 게 좋습니다. 2장에서 배운 대로 "아직 코드는 만들지 말고 계획부터"를 잊지 마세요.

3장에서 정리한 라이브 투표 서비스를 만들려고 해.
프론트엔드는 React, API 서버는 Express, DB는 PostgreSQL을 쓸 거야.
아직 코드는 만들지 말고, 어떤 순서로 만들지 계획부터 알려 줘.

Claude Code가 만들 순서를 계획으로 제시하면, 방향이 맞는지 읽어 봅니다. 프론트 → API → DB 순서로 하나씩 붙이는 계획이면 좋습니다. 확인했으면 뼈대부터 만들라고 승인합니다.

좋아, 이 계획대로 먼저 프로젝트 뼈대만 만들어 줘.
vote-app 안에 frontend 폴더(React)와 backend 폴더(Express)로 나눠 줘.

Claude Code는 뼈대를 만들 때 여러분 대신 명령을 실행합니다. 예를 들어 프론트는 npm create vite@latest frontend -- --template react 같은 명령으로 React 프로젝트를 만들고, 백엔드는 npm init으로 Express 프로젝트를 준비합니다. 이런 명령을 실행하기 전에 Claude Code가 "실행해도 될까요?"라고 물으면, 내용을 보고 승인하면 됩니다. (직접 외워서 칠 필요는 없습니다.)

vote-app/
├── frontend/     프론트엔드(React) 코드가 사는 곳
├── backend/      백엔드(Express) 코드가 사는 곳
└── ...           기타 설정 파일

4.3 프론트엔드 만들기 — 투표 화면

이제 사용자가 볼 화면부터 만들어 달라고 합니다. 화면은 React라는 도구로 만듭니다.

실제로 어디에 쓰이나. React는 취미 프로젝트용 장난감이 아니라, 큰 회사들이 실제 서비스 화면을 만드는 데 씁니다.

• 인스타그램·페이스북을 만든 회사(Meta)가 React를 직접 만들어 씁니다.
• 넷플릭스, 토스, 배달의민족 같은 서비스의 웹 화면도 React 계열로 만들어져 있습니다.
• 사내 관리자 화면(대시보드, 통계 페이지)처럼 데이터가 자주 바뀌는 화면에도 React가 흔히 쓰입니다.

즉, 우리가 배우는 도구가 곧 현업에서 쓰는 도구입니다. 이제 투표 화면을 만들어 달라고 요청합시다.

frontend 쪽에 투표 화면을 만들어 줘.
- 설문의 질문과 선택지들이 보이고
- 선택지를 누르면 투표가 되고
- 각 선택지의 득표수가 막대그래프로 표시되면 좋겠어
아직 서버가 없으니, 우선 가짜 데이터로 화면만 확인할 수 있게 해 줘.
그리고 나중에 API를 붙일 때를 위해, API 호출은 절대 주소가 아니라
상대 경로(/api)로 부르게 하고, vite.config에 개발 프록시를 설정해서
/api 요청을 localhost:3000(API 서버)으로 넘기게 해 줘. (CORS 방지)

"우선 가짜 데이터로 화면만"이라고 요청한 데 주목하세요. 서버와 DB가 아직 없어도 화면을 먼저 눈으로 확인하기 위한 요령입니다. 이렇게 조각을 하나씩 확인하며 나아가면 문제가 생겨도 원인을 찾기 쉽습니다. 프롬프트 뒤쪽의 "상대 경로(/api) + 개발 프록시"가 왜 중요한지는 4.5에서 따로 설명합니다. 지금은 그냥 그렇게 시켜 두기만 하면 됩니다.

[맛보기] 만든 화면을 브라우저에 띄워 보기

만들어졌으면 실제로 화면을 띄워, 처음으로 내 손으로 결과를 확인해 봅니다.

프론트엔드 개발 서버를 실행해서 브라우저로 확인할 수 있게 해 줘.
접속 주소도 알려 줘.

Claude Code가 개발 서버를 실행하고 http://localhost:5173 같은 주소를 알려 줍니다. 그 주소를 브라우저 주소창에 입력해, 투표 화면이 뜨는지 눈으로 확인하세요. 아직 가짜 데이터지만 질문·선택지·막대그래프 모양이 잡혔으면 성공입니다.

설문 만들기 화면도 추가하기

투표 화면이 잡혔으니, 새 설문을 직접 만드는 화면도 있어야 3장 완료 기준의 "설문을 만들고"가 채워집니다. 이어서 요청합니다.

홈 화면에 '설문 만들기' 화면을 만들어 줘.
- 질문 입력칸 하나
- 선택지 입력칸 여러 개 (기본 2개, '선택지 추가' 버튼으로 늘리고
  지우기도 가능)
- '설문 만들기' 버튼을 누르면 설문이 만들어지고, 그 설문의 투표
  화면으로 이동
- 빈 질문이거나 선택지가 2개 미만이면 안내 문구를 보여 줘
투표 화면과 어울리는 디자인으로 해 줘.

완성되면 홈 화면이 이렇게 보입니다. (선택지는 아직 서버가 없으니, 이 화면의 "만들기"가 실제로 저장되는 것은 4.4~4.6에서 API와 DB를 붙인 뒤부터입니다.)

4.4 API 서버 만들기 — 설문·투표·결과

화면이 잡혔으니, 이번엔 뒤에서 일할 API 서버를 만듭니다. API 서버는 Express라는 도구로 만듭니다.

실제로 어디에 쓰이나. 우리가 화면에서 무언가를 누를 때, 뒤에서는 거의 항상 이런 API 서버가 요청을 받아 처리합니다.

• 로그인 버튼을 누르면 → "이 아이디·비밀번호가 맞나?"를 확인하는 API가 일합니다.
• 쇼핑몰에서 주문하기를 누르면 → 재고를 줄이고 주문을 기록하는 API가 일합니다.
• 지도 앱에서 길찾기를 누르면 → 경로를 계산해 돌려주는 API가 일합니다.

우리 투표 서비스에서는 3장에서 정리한 세 개의 창구(엔드포인트)를 그대로 요청합니다.

backend 쪽에 Express로 API 서버를 만들어 줘. 엔드포인트는 세 개야.
- POST /api/polls        : 질문과 선택지를 받아 설문을 만든다
- GET  /api/polls/:id    : 설문의 질문·선택지·득표수를 돌려준다
- POST /api/polls/:id/vote : 고른 선택지의 득표수를 1 늘린다
DB는 잠시 뒤에 붙일 거니까, 지금은 서버 메모리에 임시로 저장하는
방식으로 먼저 동작하게 해 줘. 서버는 3000번 포트로 열어 줘.

여기서도 "DB는 나중에, 지금은 임시 저장으로 먼저"라는 단계 나누기를 썼습니다. 서버가 혼자서도 동작하는지 먼저 확인한 뒤 DB를 붙이면, 문제의 원인이 서버인지 DB인지 구분하기 쉽습니다.

[맛보기] API가 실제로 응답하는지 확인하기

API 서버를 실행하고, 세 개의 엔드포인트가 잘 동작하는지
간단히 테스트해서 결과를 보여 줘.

Claude Code가 서버를 실행하고, 스스로 요청을 보내 응답을 확인한 결과를 알려 줍니다. "설문 생성 성공", "투표 후 득표수 증가 확인" 같은 결과가 나오면 서버가 제대로 도는 것입니다. 화면 없이 서버 혼자서도 일을 한다는 걸 눈으로 본 셈입니다.

4.5 왜 상대 경로 /api로 부를까 — CORS와 개발 프록시

이제 화면(5173번)과 API 서버(3000번)가 둘 다 준비됐습니다. 그런데 이 둘을 연결하려 할 때 초보자가 거의 반드시 만나는 문제가 하나 있습니다. 미리 피해 두었으니, 왜 그렇게 했는지 이해하고 넘어갑시다.

그래서 4.3의 프롬프트에서 두 가지를 미리 시켜 둔 것입니다.

1. 화면이 API를 부를 때 절대 주소(http://localhost:3000/...)가 아니라 상대 경로(/api/...)로 부르게 했습니다.
2. vite.config에 개발 프록시를 설정해, /api 요청을 3000번으로 넘기게 했습니다. (Vite가 만들어 준 설정은 대략 이런 모습입니다.)

// frontend/vite.config.js — Claude Code가 만든 설정 예시 (직접 칠 필요 없음)
server: {
  proxy: {
    '/api': {
      target: 'http://localhost:3000',  // /api 요청을 API 서버로 넘김
      changeOrigin: true,
    },
  },
}

실제로 어디에 쓰이나. "화면과 API가 같은 주소인 것처럼 보이게" 하는 이 방식은 개발 현장에서 표준처럼 쓰입니다.

• 개발 중에는 이렇게 Vite 개발 프록시로 화면과 API를 이어 붙입니다.
• 배포할 때는 프록시 역할을 Nginx 같은 웹서버가 대신 맡습니다(2부에서 직접 합니다). 방식이 바뀌어도 화면 코드는 그대로 /api만 부르면 되니, 화면을 고칠 필요가 없습니다.

즉 이 "상대 경로 /api" 습관 하나로 개발할 때도, 나중에 AWS에 배포할 때도 CORS 문제를 아예 겪지 않게 됩니다. 그래서 처음부터 이렇게 시켜 둔 것입니다.

4.6 데이터베이스 붙이기 — 로컬에서 PostgreSQL

지금까지는 서버 메모리에 임시로 저장했습니다. 문제는, 서버를 끄면 그 데이터가 전부 사라진다는 점입니다. 3장 완료 기준의 마지막 항목, "새로고침해도 결과가 유지된다"를 만족하려면 데이터를 진짜 창고(DB)에 저장해야 합니다.

우리가 쓸 DB는 PostgreSQL입니다. 그런데 내 컴퓨터에 PostgreSQL을 직접 설치하는 대신, Docker로 띄웁니다.

왜 설치 대신 Docker로 띄우나. 데이터베이스를 컴퓨터에 직접 설치하면 버전이 꼬이거나, 나중에 지우기가 번거롭습니다. Docker로 띄우면 명령 한 줄로 깨끗하게 시작하고, 필요 없어지면 상자째 지우면 그만이라 내 컴퓨터가 지저분해지지 않습니다. 그래서 로컬 개발용 DB는 Docker로 띄우는 경우가 많습니다.

DB 붙이기 요청

이제 데이터를 PostgreSQL에 저장하도록 바꿔 줘.
- 로컬 개발용 PostgreSQL은 Docker로 띄워 줘
- polls(id, question, created_at), options(id, poll_id, label, votes)
  구조로 테이블을 만들어 줘
- 서버가 임시 저장 대신 이 DB에 저장하고 읽도록 연결해 줘

Claude Code가 Docker로 PostgreSQL을 실행하고(예: docker run 명령으로 postgres 상자를 5432번 포트에 띄웁니다), 테이블을 만들고, 서버가 DB를 쓰도록 코드를 고쳐 줍니다. 중간에 여러 명령을 실행하며 승인을 요청할 텐데, 내용을 보며 승인하면 됩니다.

4.7 전체 흐름 로컬에서 확인하기

이제 세 층(프론트 → API → DB)이 모두 준비됐습니다. 실제로 처음부터 끝까지 이어지는지 확인할 차례입니다.

프론트엔드, API 서버, 그리고 Docker의 DB를 모두 실행해서
전체가 연결된 상태로 확인할 수 있게 해 줘. 접속 주소를 알려 줘.

브라우저에서 알려 준 주소(보통 http://localhost:5173)에 접속해, 3장의 완료 기준을 하나씩 직접 체크해 보세요.

• □ 질문과 선택지를 입력해 설문을 만들 수 있는가
• □ 선택지를 누르면 득표수가 늘어나는가
• □ 결과가 막대그래프로 보이는가
• □ 페이지를 새로고침해도 투표 결과가 그대로 남아 있는가

마지막 항목이 이제 통과되어야 합니다. 새로고침해도 데이터가 유지된다면, 값이 화면이나 서버 메모리가 아니라 DB에 제대로 저장되고 있다는 확실한 증거입니다. 축하합니다. 프론트 + API + DB로 이루어진 진짜 웹 서비스가 내 컴퓨터에서 돌고 있습니다.

선택지를 누르면 아래처럼 득표수가 막대그래프와 퍼센트로 나타납니다.

4.8 환경변수 분리 — 접속 정보를 코드에 넣지 않기

서비스가 동작하니, 넘어가기 전에 한 가지 중요한 습관을 짚습니다. DB에 접속하려면 주소, 사용자 이름, 비밀번호 같은 정보가 필요합니다. 이런 민감한 정보를 코드 안에 그대로 적어 두면 안 됩니다.

왜 코드에 직접 쓰면 안 되나. 두 가지 이유가 있고, 둘 다 실무에서 실제로 사고로 이어지는 것들입니다.

1. 보안: 코드를 GitHub에 올리면, 코드에 박아 둔 비밀번호까지 인터넷에 공개됩니다. 실제로 이렇게 유출된 접속 정보로 남의 DB가 털리는 사고가 흔합니다.
2. 유연성: 내 컴퓨터의 DB와, 나중에 AWS의 DB는 접속 정보가 다릅니다. 코드에 박아 두면 환경이 바뀔 때마다 코드를 고쳐야 합니다. 환경변수로 빼 두면 코드는 그대로 두고 값만 바꾸면 됩니다.

그래서 이런 값들은 보통 .env라는 별도 파일에 모아 둡니다.

DB 접속 정보 같은 민감한 값이 코드에 직접 들어가 있으면
.env 파일로 분리해 줘. 환경변수 이름은 아래 다섯 개로 맞춰 줘.
  DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD
그리고 .env가 실수로 GitHub에 올라가지 않도록
.gitignore에도 추가해 줘. 분리한 뒤에도 서비스가 그대로 동작하는지
확인해 줘.

4.9 Git으로 저장하고 GitHub에 올리기

마지막으로, 지금까지 만든 것을 안전하게 저장하고 GitHub에 올립니다. 2부와 3부의 자동 배포가 이 GitHub 저장소를 기반으로 이루어지므로, 여기서 꼭 올려 둬야 합니다. 1장에서 Git 설치와 GitHub 계정을 준비해 둔 걸 이제 씁니다.

실제로 어디에 쓰이나. 이 커밋·푸시·저장소는 개발자라면 매일 쓰는 기본 도구입니다.

• 백업: 내 컴퓨터가 고장 나도 코드가 GitHub에 안전하게 남아 있습니다.
• 되돌리기: 무언가 잘못 고쳤을 때, 예전 커밋 지점으로 되돌릴 수 있습니다.
• 협업·자동 배포: 팀원과 코드를 공유하고, "GitHub에 코드가 올라오면 자동으로 서버에 배포"하게 만들 수 있습니다(3부에서 직접 합니다).

이 과정도 Claude Code에게 맡길 수 있습니다.

지금까지 만든 걸 git으로 커밋하고, GitHub에 새 저장소를 만들어
올려 줘. 저장소 이름은 vote-app, 프라이빗(비공개) 저장소로 해 줘.

[확인]

이번 장이 제대로 끝났는지 눈으로 확인합니다.

• 브라우저에서 http://localhost:5173에 접속하면 투표 화면이 뜬다.
• 설문을 만들고, 선택지를 눌러 투표하면 득표수가 막대그래프로 늘어난다.
• 페이지를 새로고침해도 득표수가 그대로 남아 있다.
• github.com/내아이디/vote-app에 코드가 올라와 있고, .env는 그 목록에 없다.

여기까지 보였다면, 내 컴퓨터에서 도는 진짜 웹 서비스가 완성된 것입니다.

막히면

이 장에서 자주 나는 오류와 대처법입니다.

• 투표 화면(5173)에서 투표하면 오류가 나거나 아무 반응이 없다. API 서버(3000번)가 안 켜져 있거나, 개발 프록시가 빠졌을 수 있습니다. Claude Code에게 "API 서버가 켜져 있는지, vite 개발 프록시가 /api를 3000번으로 넘기게 돼 있는지 확인해 줘"라고 요청하세요. (4.5 참고.)

• 브라우저 개발자 도구에 CORS 오류가 보인다. 화면이 API를 절대 주소로 부르고 있을 가능성이 큽니다. Claude Code에게 "API 호출을 상대 경로 /api로 바꾸고, vite 프록시로 3000번에 넘기게 해 줘"라고 요청하세요. (4.5의 방식으로 고치면 CORS가 사라집니다.)

• DB 붙이는 단계에서 Docker 관련 오류가 난다. Docker Desktop이 실행 중이 아닐 때가 많습니다. Docker Desktop 앱을 먼저 실행한 뒤(고래 아이콘 확인), Claude Code에게 다시 시도해 달라고 하세요. 5432번 포트가 이미 쓰이고 있다는 오류라면, 예전에 띄운 DB가 남아 있는 것이니 "기존 postgres 컨테이너를 정리하고 다시 띄워 줘"라고 요청합니다.

• 새로고침하면 투표 결과가 사라진다. 아직 데이터가 서버 메모리에 저장되고 있는 것입니다. Claude Code에게 "새로고침하면 결과가 사라져. DB에 저장하고 DB에서 읽어 오는 게 맞는지 확인하고 고쳐 줘"라고 요청하세요. (4.6 참고.)

• GitHub에 올릴 때 인증(로그인)에서 막힌다. 터미널에 나온 안내나 오류 메시지를 그대로 Claude Code에게 붙여넣으세요. gh auth login으로 GitHub에 로그인하도록 안내해 줍니다.

• .env 파일이 GitHub에 올라가 버렸다. Claude Code에게 ".env를 저장소에서 지우고 .gitignore에 넣은 뒤 다시 올려 줘"라고 요청하세요. 비밀번호가 노출됐다면, 그 DB 비밀번호는 새로 바꾸는 게 안전합니다.

[체크리스트]

아래가 모두 됐는지 확인해 보세요. 하나라도 안 됐다면 해당 절로 돌아가 다시 진행합니다.

• □ 프론트엔드 / 백엔드 / 데이터베이스 3층 구조를 설명할 수 있다 (4.1)
• □ vote-app 안에 frontend, backend 폴더로 뼈대가 만들어졌다 (4.2)
• □ 브라우저(localhost:5173)에서 투표 화면이 뜬다 (4.3)
• □ API 서버(3000번)의 세 엔드포인트가 동작하는 걸 확인했다 (4.4)
• □ 화면이 API를 상대 경로 /api로 부르고, 개발 프록시로 이어진다 (4.5)
• □ Docker로 PostgreSQL을 띄우고, 서버가 DB에 저장하도록 연결했다 (4.6)
• □ 투표 후 새로고침해도 결과가 유지된다 (DB 저장 확인) (4.7)
• □ 민감한 정보를 .env로 분리하고 .gitignore에 넣었다 (4.8)
• □ 코드를 GitHub 비공개 저장소에 올렸고, .env는 올라가지 않았다 (4.9)

이제 "내 컴퓨터에서 도는 서비스"가 생겼습니다. 하지만 이걸 다른 사람에게 보여 주려면 내 컴퓨터를 계속 켜 둘 수도 없고, "내 컴퓨터에선 되는데 남의 컴퓨터에선 안 되는" 문제도 있습니다. 이 문제를 푸는 것이 다음 여정, Docker와 클라우드 배포입니다.