비엔지니어가 매일 배포하기 위한 환경 구축 — AI, GitHub, DeployNow를 헤매지 않고 조작하는 순서

지난번에는 비엔지니어가 AI, GitHub, DeployNow를 사용하여 매일 작은 변경분을 배포할 수 있는 체계를 정리했습니다.

이번에는 그보다 더 운영적인 측면으로 깊이 들어가 봅니다.

매일 배포가 막히는 이유는 코드를 작성할 수 없기만은 아닙니다.

• 어떤 폴더를 열어야 할지 모른다
• GitHub의 어떤 리포지토리가 공개 중인지 알 수 없다
• main 브랜치와 작업용 브랜치의 차이가 모호하다 - DeployNow의 어느 화면에서 결과를 봐야 하는지 모른다
• 로컬에서는 작동하지만, 공개하면 환경 변수가 부족하다
• 문제가 발생했을 때, 마지막으로 정상이었던 상태로 되돌아갈 수 없다

이러한 작은 망설임들이 매일 쌓이면, AI가 구현을 완료했더라도 공개할 수 없게 됩니다.

따라서 이 글에서는 '오늘의 변경분을 만드는 방법'이 아니라, 매일 같은 순서로 조작할 수 있는 작업 환경을 정비하는 방법을 다룹니다.

목표는 컴퓨터를 켰을 때 다음 5가지가 즉시 파악되는 상태입니다.

1. 오늘 수정할 폴더
2. 공개 중인 GitHub 리포지토리와 브랜치
3. DeployNow의 대상 프로젝트
... 

DeployNow에는 AI 에이전트, CLI(Command Line Interface), 브라우저 드래그 앤 드롭, GitHub 연동 등 여러 가지 공개 방법이 있습니다.

선택지가 많다는 것은 편리하지만, 매일 다른 방법을 사용하면 어떤 파일을 공개했는지 추적하기 어려워집니다.

이 글에서는 일상 운영의 경로를 다음 한 가지로 고정합니다.

로컬 작업 폴더
↓
GitHub 작업용 브랜치
... 

작업 내용이 매우 작고 미리보기를 사용하지 않는 경우에도, 최소한 다음 경로는 고정해야 합니다.

로컬 → GitHub의 main → DeployNow → 공개 URL

'오늘은 GitHub, 내일은 폴더를 직접 업로드'와 같이 운영하면, GitHub 내용과 실제 공개 중인 내용이 일치하지 않는 날이 생깁니다. 비상시 대체 경로가 남아있더라도, 일상의 정규 경로는 하나로 통일해야 합니다.

비엔지니어를 위한 환경 정비에서 가장 먼저 효과를 보는 것은 고도화된 자동화보다는 폴더 이름입니다.

저는 하나의 애플리케이션을 하나의 폴더로 분리하고, 공개 대상과 자료를 섞지 않는 방식을 권장합니다.

daily-app/
├── README.md
├── CURRENT_STATUS.md
... 

각 파일의 역할은 다음과 같습니다.

실제 .env에는 비밀 정보가 포함될 수 있으므로, GitHub에 저장하지 않습니다. .env.example에는 값을 적지 않고, 다음과 같이 변수명과 용도만 남깁니다.

PUBLIC_API_URL=
INTERNAL_API_TOKEN=

하지만 변수명에 PUBLIC이 붙어있다고 해서 안전한 것은 아닙니다. AI에게 브라우저로 전달되는 값인지, 서버 내부에서만 사용하는 비밀 정보인지를 확인시켜주고, 사람이 공개 범위를 판단해야 합니다.

AI에게 방대한 과거 로그를 읽게 하기 전에, 현재 위치를 간결하게 만듭니다.

CURRENT_STATUS.md에는 다음 내용만 작성합니다.

# Current Status
확인일: 2026-11-03
공개 URL: https://example.lolipop-now.app
... 

docs/DAILY_CHECK.md에는 조작 순서만 작성합니다.

1. 공개 URL에서 어제 상태 확인
2. CURRENT_STATUS.md 읽기
3. AI에게 오늘의 변경분 1을 요청
... 

매일의 진입점을 두 파일로 줄이면, AI가 바뀌어도 같은 현재 위치에서 시작할 수 있습니다.

폴더 이름, 리포지토리 이름, DeployNow 프로젝트 이름이 모두 다르면, 조작할 때마다 대응 방식을 기억해야 합니다.

완전히 같지 않아도, 공통 부분을 가지게 만듭니다.

로컬 폴더: daily-memo
GitHub 리포지토리: daily-memo
DeployNow: daily-memo
... 

이름에는 고객명, 개인명, 비공개 프로젝트명을 넣지 않도록 주의해야 합니다. 공개 URL의 서브도메인은 제3자에게 노출되기 때문입니다.

또한 GitHub에서는 다음 세 가지를 확인합니다.

소유자: 어떤 계정 또는 Organization인지
리포지토리: 어느 것이 공개 원본인지
프로덕션 브랜치: 어느 브랜치로 push가 이루어져 공개되는지

이 3가지 정보는 CURRENT_STATUS.md에도 기록합니다.

DeployNow와 GitHub를 연결할 때는 GitHub App을 사용합니다.

최초 연결 시에는 GitHub 계정 연동과 리포지토리에 대한 접근 권한 부여가 필요합니다.

작업 순서는 다음과 같습니다.

• DeployNow 프로젝트 목록에서 '새로 만들기'를 클릭합니다.
• GitHub를 통해 배포하는 방법을 선택합니다.
• GitHub 계정 연동 화면으로 이동합니다.
• 대상 리포지토리의 소유자를 선택합니다.
• GitHub App을 설치합니다.
• 접근을 허용할 리포지토리를 선택합니다.
• DeployNow로 돌아가서, 리포지토리 목록을 다시 불러옵니다.

권한 범위에는 All repositories와 Only select repositories가 있습니다. 매일 배포하는 대상이 하나라면, 우선 Only select repositories로 대상을 한정하면 다른 리포지토리를 선택할 실수를 줄일 수 있습니다. 나중에 대상을 늘릴 경우, GitHub 측에서 권한 범위에 리포지토리를 추가할 수 있습니다.

공식 문서에 따르면, GitHub 계정 연동 승인은 약 8시간 후에 만료됩니다. 기한이 지나면 새로운 연결을 생성하거나 리포지토리 목록을 표시하기 전에 재연동이 필요합니다. 다만, 이미 연결된 리포지토리에 대한 자동 배포는 계속 진행됩니다.

만약 '어제까지 작동했는데 리포지토리 목록이 안 보인다'는 경우라면, GitHub App을 바로 다시 설치하기보다는 계정의 재연동과 권한 범위를 먼저 확인합니다.

리포지토리를 선택하면 프로젝트 생성 화면으로 이동합니다. 여기서 최소한 다음 4가지 항목은 반드시 확인해야 합니다.

• 프로젝트명
• 서브도메인
• 프레임워크
• 배포할 브랜치

관리 화면에서 구별하기 쉬운 짧은 이름으로 지정합니다. 프로젝트가 늘어나더라도 무엇을 공개하고 있는지 알 수 있는 이름이어야 합니다.

서브도메인은 공개 URL이 됩니다. 입력 시 개인 정보, 고객명, 사내 용어가 포함되어 있지 않은지 확인해야 합니다.

GitHub에서 프로젝트를 생성할 경우, 공식 문서에 따르면 리포지토리 내용만으로는 프레임워크가 자동으로 감지되지 않습니다. 잘못 선택하면 빌드 실패의 원인이 됩니다.

생성 전에 AI에게 다음과 같이 확인합니다.

이 리포지토리를 DeployNow에 연결합니다.
package.json과 설정 파일을 확인하고, 선택해야 할 프레임워크를 답변해 주세요.
근거가 되는 파일명과 설명을 제시해 주세요.
...

여기서 선택한 브랜치로 push가 이루어지면 프로덕션 자동 배포가 시작됩니다.

일반적으로 main 등 프로덕션용 브랜치를 선택합니다. 작업용 브랜치를 선택할 경우, 확인 중인 변경 사항이 프로덕션에 반영될 수 있으므로, 선택 후 다시 한번 이름을 읽어봅니다.

프로젝트를 생성하면 첫 번째 배포가 시작됩니다.

항상 보게 되는 화면은 다음 3가지로 고정합니다.

1. 배포 진행 상황과 빌드 로그를 확인합니다.
2. '성공'이라면 다음 단계로 진행하고, '실패'라면 로그의 가장 처음 에러 메시지를 읽고 새로운 변경 사항을 추가하지 않습니다.
3. 연결된 리포지토리, 프로덕션 브랜치, 자동 배포 여부, 프리뷰 상태를 확인합니다.

공식 문서에서는 여기서부터 프로덕션 브랜치 전환, 자동 배포의 중단/재개, 프리뷰 활성화/비활성화, GitHub 연결 해제 등의 조작이 가능합니다.

배포 성공 후에는 공개 URL을 별도의 탭에서 열어봅니다.

표시: 메인 화면이 열리는지 확인
조작: 주요 버튼들이 정상적으로 작동하는지 테스트
입력: 정상 입력과 공란 입력을 시도해 보는 등
...

배포 화면에서 성공했다고 끝내서는 안 됩니다.

'로컬에서는 되는데, 공개하면 실패한다'는 원인 중 하나가 환경 변수(Environment Variable)입니다.

DeployNow의 공식 문서에 따르면, .env 파일의 내용은 빌드 시나 배포 시에도 참조되지 않습니다. 필요한 값은 프로젝트 상세의 '환경변수' 화면 또는 CLI를 통해 설정해야 합니다.

따라서 다음 표를 작성합니다.

값 자체는 문서에 기록하지 않고, '설정됨' 또는 '미설정'만을 기록합니다.

프로덕션(본番)과 프리뷰 환경 변수는 별개입니다. 프로덕션의 값은 프리뷰로 자동 전파되지 않습니다. 동일한 변수명이 필요하다면, 프리뷰 측에도 설정해야 합니다.

환경 변수를 변경한 후 반영되는 타이밍도 다릅니다.

• 프로덕션: 재배포(redeploy) 후에 반영
• 프리뷰: 풀 리퀘스트(Pull Request) 브랜치에 다음에 푸시(push)된 배포부터 반영

값을 설정했다고 해서 공개 중인 앱이 즉시 바뀌는 것은 아니므로, 반영을 위한 배포와 공개 URL 확인까지 진행합니다.

배포 대상 파일에도 주의가 필요합니다.

공식 문서에 따르면, Git 관리 하의 디렉터리에서는 Git이 추적하는 파일과, 미추적(untracked) 상태이며 .gitignore에 무시되지 않은 파일이 대상이 됩니다.

중요한 점은, 이미 Git이 추적하고 있는 파일은 나중에 .gitignore에 추가하더라도 포함된 채로 유지된다는 것입니다.

비밀 정보를 실수로 커밋했을 경우에는 단순히 .gitignore를 추가하는 것만으로는 끝나지 않습니다.

• 해당 값을 무효화하거나 재발급합니다.
• Git의 추적 대상에서 제외시킵니다.
• 공개 이력이나 로그에 미치는 영향을 확인합니다.
• DeployNow 환경 변수에 올바르게 설정합니다.
• 재배포하여 확인합니다.

비밀 정보 유출 대응은 영향이 크기 때문에, AI에게 자동 처리를 전적으로 맡기지 않고 사람이 범위를 확인해야 합니다.

GitHub 연동에서는 풀 리퀘스트의 내용을 프로덕션과 다른 URL로 공개할 수 있는 프리뷰를 이용할 수 있습니다.

작업 순서는 다음과 같습니다:

• main에서 작업용 브랜치를 생성합니다. - AI와 변경 사항을 논의합니다.
• 작업용 브랜치에 푸시합니다.
• GitHub에서 풀 리퀘스트(Pull Request)를 만듭니다.
• DeployNow가 프리뷰를 생성합니다.
• 프리뷰 URL로 작업을 진행합니다.
• 문제가 없다면 main으로 반영합니다. - 프로덕션 배포 후 공개 URL을 확인합니다.

프리뷰 URL은 동일한 풀 리퀘스트 브랜치에 푸시할 때마다 업데이트되며, 풀 리퀘스트를 닫기 전까지는 같은 URL을 사용할 수 있습니다.

다만, 공식 문서에서는 프리뷰 URL을 알면 누구나 접근할 수 있으며, DeployNow 측에는 프리뷰 접근 제한 기능이 없다고 안내하고 있습니다.

따라서 다음 내용은 프리뷰에 올리지 않습니다.

• 개인 정보
• 고객의 실 데이터
• 프로덕션의 비밀 정보
• 공개 전에 제3자에게 보여줄 수 없는 내용

프로덕션과 프리뷰에서 환경 변수를 분리하고, 검증용 데이터를 사용합니다.

환경 정비는 코드에만 국한되지 않습니다.

매일 사용하는 화면을 같은 순서로 북마크 폴더에 정리합니다.

01 공개 URL
02 GitHub 리포지토리
03 GitHub 풀 리퀘스트
...

작업 시작 시에는 01 공개 URL에서 엽니다. 변경 전의 정상 상태를 확인하기 위함입니다.

작업 후에는 02 또는 03에서 차이점을 확인하고, 04에서 배포 결과를 보고, 마지막으로 01로 돌아갑니다.

문제가 발생했을 때 채팅 기록을 찾기 시작하면 복구가 지연됩니다.

docs/RECOVERY.md에 다음 카드를 배치합니다.

# Recovery
## 먼저 멈추기
- 새로운 변경 사항을 추가하지 않습니다.
...

자동 배포를 중지하더라도, 공식 사양상 공개 사이트와 GitHub 연결은 유지됩니다. 원인 조사 중에 푸시로 업데이트를 반복하고 싶지 않을 때 사용하는 정지 수단으로 활용할 수 있습니다.

다만, 중지 후에는 재개 담당자와 조건을 반드시 기록해야 합니다.

구현 전에 AI에게 환경의 대응 관계를 확인하도록 요청합니다.

이 프로젝트의 공개 환경을 확인해 주세요.
1. 로컬 작업 폴더
2. GitHub 리포지토리명
...

환경 확인과 구현을 한 번에 부탁하지 않는 것이 중요합니다.

대응 관계가 잘못되면, 코드가 올바르더라도 다른 브랜치나 다른 프로젝트를 업데이트할 가능성이 있습니다. 먼저 읽기 전용(read-only)으로만 진행하고, 사람이 확인한 후에 변경을 요청해야 합니다.

마지막으로, 일일 작업을 한 장에 정리합니다.

## 시작 전
- [ ] 공개 URL에서 어제 상태를 확인했다
- [ ] CURRENT_STATUS.md를 읽었다
...

이 글을 작성한 시점(2026년 11월 3일)에 공식 문서에서 다음 사항을 확인했습니다.

• GitHub에서 프로젝트를 만들 때, 프로젝트 이름, 서브도메인, 프레임워크, 배포할 브랜치를 지정한다.
• GitHub 연동에서는 프레임워크가 자동으로 판별되지 않는다.
• 지정된 브랜치로 push하면 자동 배포가 시작된다.
• GitHub App의 접근 권한을 리포지토리 단위로 선택할 수 있다.
• 배포 화면에서 진행 상황과 빌드 로그를 확인할 수 있다.
• 설정 화면에서 프로덕션(Production) 브랜치, 자동 배포, 프리뷰(Preview), 연결 등을 변경할 수 있다.

.env
은 빌드 시점 및 공개 시점의 환경 변수로 참조되지 않는다. (프로덕션과 프리뷰의 환경 변수는 별도로 설정해야 한다.)

• Git 추적 파일은 나중에 .gitignore에 추가해도 대상에서 제외되지 않는다. (프리뷰 URL은 접근 제한 없이, URL을 아는 사람이 열람할 수 있다.)

참고:

매일 배포하기 위한 환경 정비는 특별한 자동화 기능을 늘리는 것만이 아닙니다.

• 일상적인 공개 경로를 하나로 고정한다.
• 작업 폴더, GitHub, DeployNow의 이름을 서로 대응시킨다.
• CURRENT_STATUS.md와 같은 일일 체크를 매일의 진입점으로 삼는다.
• GitHub App의 허가 대상을 필요한 리포지토리로 좁힌다.
• 프로젝트 생성 시 이름, URL, 프레임워크, 프로덕션 브랜치를 확인한다.
• 배포 화면, 설정 화면, 공개 URL 세 곳을 매번 본다.
• .env 대신 DeployNow 측에 환경 변수를 설정한다. (프로덕션과 프리뷰 값을 분리한다.)
• 프리뷰를 프로덕션 전 작업 확인에 사용하고, 비밀 정보는 넣지 않는다.
• 마지막 정상 커밋(commit)과 복구 절차를 미리 준비한다.

비개발자에게 필요한 것은 모든 기술 용어를 암기하는 것이 아닙니다.

'어디를 열 것인가', '어떤 순서로 확인할 것인가', '어디부터 공개할 것인가', '문제 발생 시 어디로 돌아갈 것인가'를 고정하는 것입니다.

이러한 작업 환경이 갖춰지면, AI에게 요청할 내용도 짧아집니다. 매번 프로젝트를 설명할 필요 없이, 현재 위치만 읽히고 오늘 변경된 1가지 내용만을 부탁할 수 있기 때문입니다.

매일 배포하는 체제는 AI의 속도만으로는 지속될 수 없습니다. 인간이 헤매지 않고 조작할 수 있고, 공개 전에 멈출 수 있으며, 실패해도 되돌아갈 수 있는 작업대를 만드는 것. 그 작업대가 비개발자에게 첫 번째 개발 환경입니다.

다음 시간에는 이 환경에서 매일 남는 배포 기록을, 공개 횟수가 아닌 '사용자에게 전달된 가치'와 '되돌리기 용이성'으로 주간 리뷰하는 방법을 정리하겠습니다.