개발자가 일하는 방식

01 · 시작할 상황

노트북이 어디에 있는지 몰라 매번 물어봅니다

총무 담당자는 누가 어떤 장비를 쓰는지 확인하려고 대화 기록을 뒤집니다. 직원은 빌릴 수 있는 노트북을 찾을 때마다 담당자에게 묻습니다.

이 문서에서는 장비 등록·수정·삭제와 목록 조회, 대여·반납이 가능한 작은 서비스를 만드는 것으로 가정합니다. 장비마다 관리 번호가 있고, 직원은 사용 가능한 장비를 빌립니다. 실제 회사에서 확인한 요구가 아니라 수업용 사례이므로 본인 회사에 적용할 때는 대여 승인이나 분실 처리 규칙을 별도로 확인하세요.

5주차에서 제작 범위를, 6주차에서 사용자 행동과 업무 규칙을 정했다면 이제 개발을 시작할 차례입니다. 앞 강의를 듣지 않았거나 코드가 없어도 이 사례로 출발할 수 있습니다. 가상 장비 NB-001과 가상 직원 김민지를 사용하고, 첫 버전에서는 예약·연체 알림·통계를 제외합니다.

02 · 공개 저장소

프로젝트의 코드와 작업 기록을 모을 곳을 만듭니다

GitHub의 저장소(repository)는 프로젝트 코드와 변경 기록을 보관하는 공간입니다. 할 일과 검토 내용도 함께 남길 수 있습니다.

먼저 GitHub 계정으로 equipment-lab이라는 Public 저장소를 만듭니다. Public은 누구나 코드를 볼 수 있다는 뜻입니다. README는 프로젝트 소개와 실행 방법을 적는 문서입니다. 저장소에 처음 들어온 팀원이 무엇을 만드는 프로젝트인지 이해할 수 있도록 목적·첫 기능·실행 방법을 적습니다.

공개 저장소의 일반 GitHub 제공 실행 환경에서는 GitHub Actions 사용이 무료입니다. Actions는 뒤에서 자동 검사를 실행할 도구입니다. 대형 실행 환경·결과물 보관·배포 서비스·데이터베이스 등은 각각 조건과 비용을 확인해야 합니다. 공개 저장소라고 서비스 운영 전체가 무료가 되는 것은 아닙니다.

수업에서는 공개해도 되는 가상 자료만 씁니다. 실제 사내 프로젝트를 무료 검사 때문에 공개하지는 않습니다. 비밀번호·비밀키는 저장소 밖에서 관리하고, 설정 이름만 보여주는 예시 파일을 남깁니다. 비밀키를 잘못 올렸다면 파일 삭제만으로 과거 기록이 사라지지 않으므로 해당 키 폐기·재발급과 노출 범위 확인이 필요합니다.

1. 01

   공개 저장소 만들기

   왜 하나요? 프로젝트의 공동 작업 공간을 마련합니다.

   할 일 GitHub에서 New repository를 선택하고 이름 equipment-lab, 공개 범위 Public, README 생성을 선택합니다. 로컬 작업 폴더를 연결합니다.

   복사해서 써도 되는 요청

   공개 가능한 수업용 장비관리 프로젝트야. equipment-lab 공개 저장소를 만들고 로컬에 연결해줘. README에 목적과 실행 방법을 적고 비밀키가 올라가지 않게 설정해줘.

   정상이라면 저장소 주소와 로컬 폴더가 연결되고 README가 보입니다. 비밀키 파일은 추적 대상에 없습니다.

03 · Issue

Issue에는 작업과 끝낼 조건을 함께 적습니다

장비 관리 전체를 한 번에 부탁하면 무엇부터 만들고 어디까지 확인할지 흐려집니다. 먼저 장비 등록과 목록 조회를 한 작업으로 정합니다.

Issue는 기능 요청·오류·개선을 적는 작업 카드입니다. 담당자와 완료 조건을 남기면 다른 사람이 이어서 봐도 같은 작업을 이해할 수 있습니다. 예를 들어 “장비 등록과 목록 조회” Issue에는 장비명·관리 번호를 입력하고, 저장한 장비가 새로고침 뒤에도 목록에 보이며, 중복 관리 번호는 거절한다고 적습니다.

장비 수정·삭제, 대여·반납은 별도 Issue로 순서 있게 진행합니다. 화면 담당·저장 담당으로 나눌 수도 있지만 서로 기다릴 부분이 많습니다. 이번 수업은 등록·조회처럼 실제 행동 하나를 끝낼 수 있는 작업으로 나눕니다. 삭제 시 대여 기록을 보존할지 같은 공통 규칙은 구현 전에 맞춥니다.

장비 등록이 동작하면 담당자가 완료 조건을 실행해 보고 결과를 남깁니다. Issue를 닫았다는 표시만으로 기능이 검증되는 것은 아닙니다. 연결된 코드 변경과 확인 결과가 있어야 무엇이 끝났는지 추적할 수 있습니다.

04 · 라벨 관례

라벨은 작업 카드에 붙이는 분류표입니다

담당자가 대여 관련 오류만 모아 보고 싶어 합니다. Issue를 하나씩 읽는 대신 같은 성격의 작업에 라벨을 붙이면 찾기 쉬워집니다.

새 기능 요청에는 enhancement, 의도와 다르게 동작하는 오류에는 bug, 안내 문서에는 documentation을 사용하는 것이 GitHub의 기본 라벨 예시입니다. 이 이름과 색은 바꿀 수 있습니다. 여기서는 세 이름을 그대로 쓰고 담당 영역 area:loan, 우선순위 priority:high는 직접 만든 라벨로 추가합니다.

#12 “반납 예정일 추가”에는 enhancement와 area:loan을 붙입니다. 이미 저장된 날짜가 하루 밀리는 #19에는 bug와 area:loan을 붙이고, 현재 사용자의 기록에 영향을 주므로 priority:high를 더합니다. 모든 작업을 급하다고 표시하면 구분이 사라지므로 우선순위의 기준을 팀이 정합니다.

기본 라벨은 저장소나 조직 설정에 따라 달라질 수 있습니다. 라벨은 분류용이며 붙인다고 브랜치가 생기거나 병합이 막히지는 않습니다. README에 “작업 종류 하나, 영역은 필요한 만큼, 긴급하면 근거와 함께 priority:high”처럼 사용 규칙을 적으면 팀원이 일관되게 쓸 수 있습니다.

1. 01

   라벨 만들고 적용하기

   왜 하나요? 작업 종류와 담당 영역을 같은 이름으로 구분합니다.

   할 일 저장소 Issues의 Labels에서 기존 라벨을 확인합니다. New label로 area:loan과 priority:high를 만들고 뜻을 적습니다. Issue 오른쪽 Labels에서 필요한 라벨을 선택합니다.

   정상이라면 #12에는 enhancement·area:loan이 보입니다. 같은 라벨을 눌러 관련 작업을 모아 볼 수 있습니다.

05 · main과 브랜치

main을 두고 작업 브랜치를 만듭니다

먼저 #3 “장비 등록” Issue를 준비합니다. 기준 코드 main에서 feature/3-asset-create 브랜치를 만들어 따로 작업합니다.

main은 여러 브랜치 중 팀이 기준으로 정한 이름입니다. 브랜치는 같은 코드에서 갈라져 변경을 진행하는 작업 흐름입니다. 공동 문서의 기준본을 두고 별도 수정안을 만드는 것과 비슷합니다. 다만 브랜치는 문서 사본처럼 파일 전체를 수동으로 복사하는 방식이 아니며, 변경 기록을 바탕으로 다시 합칠 수 있습니다.

첫 장비 등록은 feature/3-asset-create 브랜치에서 만듭니다. 로컬은 내 컴퓨터에서 실행하는 환경입니다. AI에게 완료 조건을 전달하고 구현 후 NB-001을 등록해 새로고침하고, 중복 번호 입력도 확인합니다. 4주차에서 배운 오류 재현은 이때 실패를 좁히는 데 사용합니다.

커밋(commit)은 관련 코드 변경을 묶어 남긴 기록입니다. “장비 등록과 목록 조회 추가”처럼 이유를 알 수 있게 적습니다. push는 이 기록을 GitHub로 보내는 일입니다. 로컬 커밋, GitHub에 push, 사용자에게 배포는 각각 다른 단계입니다.

브랜치를 나눠도 데이터베이스나 계정이 자동으로 분리되지 않습니다. 테스트용 데이터베이스와 가상 자료를 사용하세요. 운영 데이터에 연결한 채 장비를 삭제하면 아직 main에 합치지 않은 코드라도 실제 기록이 사라질 수 있습니다.

06 · 브랜치 이름

브랜치 이름에 작업 종류와 Issue 번호를 넣습니다

feature/12-loan-due-date라는 이름을 보면 새 기능이며 #12 Issue와 연결되고 반납 예정일을 다룬다는 것을 추측할 수 있습니다.

이번 팀은 종류/Issue번호-짧은-설명이라는 이름을 쓰기로 합니다. 새 기능 feature/12-loan-due-date, 오류 수정 fix/19-return-date, 안내 문서 docs/23-setup-guide, 개발 환경·자동화 chore/24-ci가 예시입니다. 소문자와 하이픈을 쓰고 설명은 짧게 정합니다. GitHub가 강제하는 공통 표준이 아니라 팀이 합의해 README에 적는 관례입니다.

feat/를 쓰는 팀도 있고 Issue 번호를 생략하는 팀도 있습니다. 어느 한 이름이 정답이라기보다 같은 프로젝트에서 일관되게 사용하는 것이 중요합니다. 급한 수정이라고 main에서 바로 작업하는 대신, 해당 Issue와 fix 브랜치를 만들고 필요한 확인을 거칩니다.

브랜치 이름의 숫자만으로 GitHub가 Issue를 자동 연결하거나 닫지는 않습니다. PR 본문에 “Closes #12”를 적으면 기본 브랜치로 병합될 때 연결된 Issue를 닫을 수 있습니다. PR 제목은 “반납 예정일 추가 (#12)”처럼 쓰고, 완료 조건과 실제 확인 결과도 본문에 적습니다.

• feature/12-loan-due-date: 새 기능인 반납 예정일 추가
• fix/19-return-date: 이미 있는 반납일 표시 오류 수정
• docs/23-setup-guide: 새 팀원을 위한 실행 안내
• chore/24-ci: 자동 검사 환경 설정

07 · PR과 병합

PR은 “이 변경을 검토해서 합쳐 주세요”라는 요청입니다

작업 브랜치를 push한 다음 GitHub에서 main을 대상으로 Pull Request, 줄여서 PR을 엽니다.

PR의 Files changed에서는 실제 바뀐 코드를 비교하고 Checks에서는 자동 검사 결과를 봅니다. 설명에는 연결된 Issue, 바뀐 동작, 확인한 결과, 미확인 항목을 적습니다. 예를 들어 “NB-001 등록·재조회·중복 거절을 확인했고 대여 기능은 다음 Issue에서 진행”이라고 쓰면 검토 범위가 분명합니다.

리뷰는 다른 사람이 변경을 읽고 확인하는 과정입니다. AI에게 요약과 검토를 보조하게 할 수 있지만, 실행하지 않은 검사를 통과했다고 쓰지 않았는지 사람이 확인합니다. 로그인 코드가 함께 바뀌었다면 필요한 이유를 묻고 관련이 없으면 별도 작업으로 분리합니다.

병합(merge)은 검토한 변경을 대상 브랜치에 합치는 일입니다. 첫 버전에서도 PR로 변경을 살펴보고 main에 합칩니다. 이후 협업 단계에서는 쓰기 권한을 가진 실제 팀원에게 검토받고, 보호 정책에서 그 승인을 필수로 설정합니다. 작성자는 자기 PR을 승인할 수 없습니다.

1. 01

   검토할 PR 만들기

   왜 하나요? 팀원이 변경과 확인 결과를 함께 볼 수 있게 합니다.

   할 일 작업 브랜치를 push하고 main 대상 PR을 만듭니다. Issue를 연결하고 변경 전후·검사 결과를 적습니다.

   복사해서 써도 되는 요청

   장비 등록 Issue에 연결된 PR을 만들어줘. 실제 diff를 확인해서 변경 내용과 실행한 검사만 적고, 미확인 항목은 따로 적어줘. 아직 병합하지 마.

   정상이라면 Issue와 연결된 PR이 있고, 실제 변경과 설명이 일치합니다.

08 · 첫 배포

다른 기기에서도 같은 장비 기록을 보게 합니다

내 컴퓨터에서는 등록이 되지만 직원은 내 컴퓨터의 주소로 접속할 수 없습니다. 서비스가 실행될 외부 환경을 준비해야 합니다.

배포는 만든 서비스를 다른 사람이 접속할 수 있는 환경에 반영하는 일입니다. 수업에서는 웹 화면을 Vercel, 서버와 데이터베이스를 Railway에 두는 구성을 예시로 씁니다. 서버는 요청을 처리하고 데이터베이스에 기록을 저장합니다. 이 배치는 수업의 선택이며 모든 프로젝트의 필수 구성은 아닙니다.

화면에서 요청을 보낼 서버 주소를 설정하고, 서버에는 데이터베이스 연결 정보와 허용된 화면 주소 등을 설정합니다. 배포 환경에 넣는 설정값을 환경변수라고 부릅니다. 브라우저에 전달하는 값은 사용자가 볼 수 있으므로 비밀키는 서버에만 둡니다. GitHub에 코드가 올라갔다고 데이터베이스나 배포 설정도 자동으로 완성되지는 않습니다.

첫 배포는 담당자가 직접 실행해 어디에 무엇이 올라가는지 확인합니다. 이후 CI/CD 단계에서 자동으로 이어 붙입니다. 휴대폰으로 NB-001을 등록하고 PC에서 조회한 뒤 대여·반납도 확인하세요. 브라우저 안에만 저장하는 localStorage로 흉내 냈다면 기기 간 공유가 되지 않으므로 실제 데이터 저장 완료와 구분합니다.

09 · 팀 협업

반납 예정일과 검색을 따로 만들고 함께 확인합니다

첫 서비스를 배포하니 “언제 돌아오는지도 알고 싶다”는 요청이 나옵니다. 팀원은 장비 검색이 필요하다고 합니다.

반납 예정일과 검색을 새 Issue로 만들고 각자 담당합니다. main의 최신 변경을 바탕으로 별도 브랜치를 만들며 공통 장비 정보와 상태 이름을 먼저 맞춥니다. 일정이 큰 프로젝트라면 이처럼 작업의 연결 관계와 담당 범위를 반복해 조정합니다. 브랜치 수를 늘리는 것만으로 협업이 완성되지는 않습니다.

같은 줄을 다르게 고치면 Git이 자동으로 결정하지 못하는 충돌이 생길 수 있습니다. AI에게 양쪽 변경의 의도를 설명하게 하고 둘 다 필요한 동작을 유지하도록 해결합니다. 무조건 내 코드나 나중 코드를 선택하면 팀원의 기능이 사라질 수 있습니다.

충돌이 없어도 한 사람은 상태 이름을 “대여 가능”으로 바꾸고 다른 사람은 “사용 가능”으로 검색하면 결과가 누락됩니다. 최신 main을 반영하고 합친 상태에서 검색·대여·반납과 반납일 저장을 함께 확인합니다. 기존 동작을 지키는 검사가 7주차의 협업 과정 안에 들어오는 이유입니다.

10 · CI/CD

CI는 검사대, CD는 배송 과정으로 생각해 봅니다

수정할 때마다 사람이 검사 명령을 입력하고 배포 버튼을 누르다 보면 한 단계를 빠뜨리기 쉽습니다.

CI(Continuous Integration)는 변경을 자주 합치면서 자동 빌드·테스트로 문제를 확인하는 과정입니다. 빌드는 코드를 실행·배포할 수 있는 형태로 준비하는 일입니다. 수업에서는 PR을 올리거나 수정하면 장비 중복 등록 거절과 대여·반납 검사를 자동 실행합니다. 출고 전 정해진 항목을 검사하는 검사대에 비유할 수 있습니다.

CD는 검사한 변경을 배포할 준비까지 자동화하거나 실제 배포까지 이어 가는 흐름입니다. Continuous Delivery는 운영 반영에 사람의 승인을 둘 수 있고, Continuous Deployment는 운영 반영도 자동으로 진행합니다. 수업에서는 main 병합 뒤 검사하고 운영에 자동 배포하는 쪽을 선택합니다. 검사한 물건을 사용자에게 배송하는 과정과 비슷하지만 실제 사용까지 보장하는 것은 아닙니다.

GitHub Actions는 정한 조건에 따라 이 작업들을 실행하는 도구입니다. PR에서는 CI만, main 병합 뒤에는 같은 코드의 검사 성공 후 배포를 실행하도록 연결합니다. Vercel·Railway의 GitHub 자동 배포를 별도로 켜 두면 검사 전에 운영 반영될 수 있으므로, 수업에서는 그 운영 자동 트리거를 끄고 Actions의 배포 작업에서 두 서비스를 반영하는 한 경로로 맞춥니다.

배포 작업은 PR에서 실행하지 않고 보호된 main의 변경만 대상으로 합니다. 비밀키는 GitHub Secrets나 배포 서비스의 설정에 보관하고, PR 검사에는 가상 자료와 테스트용 설정을 사용합니다. 외부 기여자의 코드를 실행하면서 운영 비밀키를 제공하지 않습니다. 무료 Actions 사용과 Vercel·Railway 요금은 별도로 확인합니다.

11 · Actions와 runner

Actions는 작업을 실행하고 runner는 명령을 처리합니다

내 노트북에서는 잘 되는데 팀원 컴퓨터에서는 실행되지 않습니다. 내 컴퓨터에만 설치한 도구나 파일이 숨어 있다면 다른 곳에서도 동작하는지 따로 확인해야 합니다.

GitHub Actions는 PR 생성이나 코드 변경 같은 사건을 계기로 정해 둔 작업을 실행하는 서비스입니다. 실제 명령을 실행하는 컴퓨터를 runner라고 부릅니다. 여기서는 ubuntu-latest로 일반 GitHub 제공 Ubuntu Linux 가상 컴퓨터를 선택합니다. Actions가 항상 Linux인 것은 아니며 Windows·macOS도 선택할 수 있습니다.

컴퓨터를 잠깐 빌린다고 생각하면 이해하기 쉽습니다. 작업(job)이 시작되면 별도의 새 환경을 받고, 그 안에서 코드 사본을 내려받아 실행 도구와 필요한 패키지를 준비한 뒤 검사합니다. 같은 작업 안의 단계(step)는 그 컴퓨터에서 순서대로 실행되고, 작업이 끝나면 이 임시 환경은 정리됩니다. 내 컴퓨터가 꺼져 있어도 GitHub에서 실행됩니다.

로컬과 모든 것이 똑같다는 뜻은 아닙니다. Node.js 버전과 설치 목록·검사 명령을 맞추고 운영 비밀키 없이 테스트용 값으로 확인합니다. Linux는 파일 이름의 대소문자 구분 등이 Windows와 달라, 내 컴퓨터에서 놓친 문제가 드러날 수도 있습니다.

이렇게 변경을 자주 합치며 반복 빌드·검사하는 개발 과정이 CI입니다. Actions는 CI를 실행할 수 있는 도구이고, 컴퓨터를 빌리는 행위 자체가 CI는 아닙니다. 빌린 컴퓨터는 서비스를 계속 운영하는 서버도 아닙니다.

12 · 검사 파일

검사 컴퓨터가 할 일을 파일로 적습니다

자동으로 검사하라고만 말하면 컴퓨터는 어떤 명령을 실행할지 모릅니다. 이 프로젝트가 쓰는 실행 도구와 확인 명령을 작업 순서로 적어야 합니다.

워크플로(workflow)는 언제 어떤 작업을 실행할지 적은 파일입니다. 아래 .github/workflows/ci.yml은 Node.js를 사용하는 수업용 장비관리 프로젝트의 CI 예시입니다. 이 강의 사이트에서 실행하는 설정이 아니며, 본인 프로젝트의 package.json에 check·test·build 명령과 실제 검사가 있어야 합니다. 도구가 다르면 설치·검사 명령도 달라집니다.

PR을 올리거나 수정하면 verify라는 작업을 실행합니다. 이 작업의 표시 이름 name을 ci로 정했으므로 PR의 Checks와 보호 설정에서 이 이름을 확인합니다. ubuntu-latest는 빌릴 컴퓨터의 종류입니다. checkout은 코드 내려받기, setup-node는 이 프로젝트의 실행 도구 Node.js를 지정한 버전으로 준비하는 단계입니다.

npm ci는 package-lock.json에 적힌 버전대로 필요한 패키지를 설치하는 명령입니다. 이 명령 이름의 ci와 개발 과정인 CI를 같은 뜻으로 외울 필요는 없습니다. 잠금 파일이 필요하며 package.json과 내용이 맞아야 합니다. 로컬에서도 같은 버전과 설치 목록을 사용해 차이를 줄입니다.

npm run check는 코드의 타입 등 프로젝트가 정한 정적 검사를, npm test는 실제 동작 검사를, npm run build는 배포 가능한 형태로 준비되는지 확인합니다. 브라우저 검사를 사용하는 프로젝트라면 Playwright 브라우저 설치 등 추가 준비도 워크플로에 적어야 합니다. 명령 이름만 적었다고 대여 중복이나 날짜 저장이 자동으로 검사되지는 않습니다.

검사할 코드는 AI에게 작성시킬 수 있습니다. “대여 중인 NB-001을 다시 빌리면 거절되고 기존 사용자와 반납일이 유지되는지 검사해 줘”처럼 기준을 줍니다. 일부러 이 조건을 깨뜨렸을 때 테스트가 실패하는지 확인해야 검사가 무엇을 보호하는지 알 수 있습니다.

실패하면 PR의 Checks 또는 저장소 Actions에서 실행 내역을 열고 실패한 단계의 로그를 봅니다. 패키지 설치 실패라면 버전·잠금 파일을, 동작 검사 실패라면 입력·기대 결과·실제 결과를 살펴봅니다. 이유를 확인하지 않고 실패를 무시하는 설정을 추가하지 않습니다.

name: Equipment CI
on: [pull_request]
permissions:
  contents: read
jobs:
  verify:
    name: ci
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v7
        with:
          node-version: '22'
      - run: npm ci
      - run: npm run check
      - run: npm test
      - run: npm run build

13 · main 보호

지키기로 한 절차를 설정으로 적용합니다

급하다는 이유로 검토 없이 main에 올리면 다른 팀원의 작업과 운영 서비스에 바로 영향을 줄 수 있습니다.

main 보호 정책은 기준 코드에 반영하기 위한 조건입니다. 수업에서는 PR을 거치도록 하고, 쓰기 권한이 있는 다른 팀원 1명의 승인과 필수 자동 검사 통과를 요구합니다. 변경 뒤에는 오래된 승인을 해제해 최신 코드를 다시 검토받습니다. 강제 push와 브랜치 삭제를 허용하지 않고 관리자 우회도 제한합니다.

GitHub 저장소 Settings의 Branches에서 main 대상 보호 규칙을 설정할 수 있습니다. 먼저 자동 검사 작업을 한 번 실행해 정확한 검사 이름을 확인하고 필수 상태 검사로 지정하세요. 존재하지 않는 이름을 요구하면 병합이 계속 막힐 수 있습니다. 실제 계정에서 표시되는 설정과 적용 여부를 확인합니다.

공개 저장소는 GitHub Free에서도 브랜치 보호를 사용할 수 있습니다. 다른 팀원의 승인을 필수로 했다면 혼자 만든 PR을 자기 계정으로 승인할 수 없습니다. 실습 파트너를 Collaborator로 초대하고 쓰기 권한을 확인합니다. 파트너가 없으면 PR 작성과 검사까지 진행하고 승인·병합은 미완료로 남깁니다. 완료를 위해 보호 정책을 꺼 버리지 않습니다.

14 · 필수 검사 설정

검사를 실행하는 것과 병합을 막는 설정은 별개입니다

PR에 빨간 검사 결과가 있는데도 Merge 버튼으로 합칠 수 있다면 검사를 필수 조건으로 적용하지 않았거나 우회할 권한이 있을 수 있습니다.

CI 파일이 있다고 main이 자동 보호되지는 않습니다. PR에서 ci 검사가 실제로 한 번 실행된 뒤 main 보호 규칙에 그 검사 이름을 등록합니다. 워크플로 파일 이름이나 브랜치 이름을 대신 넣지 말고 PR Checks에 표시되는 작업 이름을 확인합니다.

아래는 classic branch protection을 사용하는 한 가지 설정 경로입니다. Rulesets를 쓰는 저장소는 화면이 다르지만 PR·승인·필수 검사·우회 제한이라는 적용 결과를 확인하는 기준은 같습니다. 수업에서는 여러 방식을 섞지 않고 아래 경로 하나로 진행합니다.

장비 반납일 테스트를 일부러 실패시키고 리뷰는 승인된 상태로 둡니다. 그래도 필수 ci가 실패해 병합할 수 없어야 합니다. 테스트를 수정하고 같은 PR의 최신 코드에서 ci가 통과하면 다음 조건으로 넘어갑니다. 팀원의 승인이 부족하면 검사가 통과해도 아직 합칠 수 없습니다.

필수 상태 검사는 skipped나 neutral 결과도 허용할 수 있으므로 “초록색이면 모든 검사를 했다”고 단정하지 않습니다. 필수 ci 작업에 조건부 생략이나 continue-on-error를 넣지 않고 필요한 검사가 실제로 실행됐는지 봅니다. 작업 이름을 ci에서 verify로 바꿨다면 필수 검사 이름도 새 실제 이름으로 맞춰야 대기 상태가 풀립니다.

1. 01

   검사를 먼저 실행하고 이름 확인

   왜 하나요? 실제로 존재하는 검사를 병합 조건에 연결합니다.

   할 일 PR의 Checks에서 ci가 실행되는지 확인합니다. Actions 로그에서 설치·check·test·build가 각각 실행된 것도 확인합니다.

   정상이라면 이번 PR의 최신 변경에 대한 ci 결과와 각 단계 기록이 보입니다.

2. 02

   main 보호 규칙 열기

   왜 하나요? 지킬 규칙을 대상 브랜치에 적용합니다.

   할 일 Settings → Branches → Add classic branch protection rule에서 Branch name pattern을 main으로 지정합니다. 기존 main 규칙이 있으면 새로 중복 생성하지 말고 편집합니다.

   정상이라면 다른 브랜치가 아니라 main에 적용될 규칙을 편집하고 있습니다.

3. 03

   PR·승인·필수 검사 설정

   왜 하나요? 동료 검토와 자동 검사를 모두 요구합니다.

   할 일 Require a pull request before merging, Require approvals 1명, Dismiss stale pull request approvals when new commits are pushed를 켭니다. Require status checks to pass before merging에서 ci를 선택하고 Require branches to be up to date before merging을 켭니다.

   정상이라면 승인만으로, 또는 검사만으로는 병합되지 않습니다. 최신 main 변경이 반영되지 않았다면 갱신과 재검사가 필요합니다.

4. 04

   우회 제한하고 실제 실패 확인

   왜 하나요? 관리자도 절차를 건너뛰지 않는지 확인합니다.

   할 일 Do not allow bypassing the above settings를 켜고 강제 push·삭제는 허용하지 않습니다. 저장한 뒤 테스트 브랜치에서 실패하는 PR을 만들어 승인 후에도 병합이 막히는지 확인합니다.

   정상이라면 ci 실패 때문에 병합할 수 없습니다. 원인을 수정하고 최신 검사가 통과한 다음 필요한 승인을 받아 합칩니다.

15 · 배포 후 확인

초록색 표시 뒤에도 실제 서비스를 확인합니다

PR 검사와 승인은 끝났고 main에도 합쳤습니다. 그런데 배포 작업이 실패하면 직원은 아직 새 기능을 사용하지 못할 수 있습니다.

먼저 GitHub Actions의 배포 결과와 실제 배포된 코드 버전을 확인합니다. 휴대폰에서 반납일을 입력하고 PC에서 다시 조회하며 검색·대여·반납도 실행합니다. 자동 검사 성공, 배포 성공, 실제 사용 확인을 나눠 적습니다. 한 서비스만 업데이트된 부분 배포라면 화면과 서버 버전이 맞는지도 확인해야 합니다.

문제가 생기면 배포한 변경과 오류 기록으로 범위를 좁히고 수정 PR 또는 이전 코드 복귀를 결정합니다. 코드 복귀를 위해 새 데이터베이스 구조와의 호환성도 확인합니다. 잘못 저장한 반납일이나 삭제한 대여 기록은 코드가 돌아가도 복구되지 않을 수 있으므로 별도로 확인합니다.

자기 프로젝트에는 전체 서비스를 한 번에 복제하기보다 작업 하나를 이 순서로 적용해 보세요. 저장소 주소, Issue, 작업 브랜치, PR, 검사 결과, 배포 주소와 실제 확인 결과를 남기면 팀원이 이어서 볼 수 있습니다. 아직 계정·동료가 없는 단계는 미완료라고 적고 가능한 단계까지 진행합니다.

1. 01

   배포 확인 기록 남기기

   왜 하나요? 코드 병합과 사용자에게 전달된 결과를 구분합니다.

   할 일 배포한 커밋과 서비스 주소를 적고 서로 다른 기기에서 반납일 저장·조회, 기존 대여·반납을 실행합니다.

   정상이라면 입력한 반납일이 다른 기기에도 같고 기존 동작도 유지됩니다. 실패하면 실제 결과와 다음 조치를 기록합니다.