- 작성일
개발과 운영 기본 용어
- Authors
- Name
- seren-wib
Contents
코드를 어떻게 관리하고, 어떻게 확인하고, 어떻게 실제 서비스에 올리는지에 관한 용어. Git 명령어 자체는 Git / GitHub Cheatsheet에 따로 있다.
1. 코드를 관리하는 방법
레포
코드와 그 변경 기록을 함께 담은 저장소(repository). Git이라는 도구로 관리하고, GitHub 같은 곳에 올려 둔다. 여러 컴퓨터(예: 윈도우 데스크톱과 맥북)에서 같은 레포를 내려받아(클론) 작업하고, 고친 것을 GitHub에 올리면(푸시) 다른 컴퓨터에서 받아 온다(풀).
커밋
코드 변경을 하나의 단위로 저장한 기록. "로그인 페이지 추가" 같은 설명이 붙는다. 게임의 세이브 포인트처럼 언제든 그 시점으로 돌아가거나, 그 변경 하나만 되돌릴 수 있다.
브랜치
본선과 떨어진 작업 공간. 본선 코드를 건드리지 않고 새 기능을 만들다가, 다 되면 본선에 합친다(머지). 실패하면 브랜치만 버리면 된다.
PR
"이 브랜치를 본선에 합쳐 주세요"라는 요청(Pull Request). 무엇을, 왜 바꿨는지 적고, 자동 검사(CI)를 통과한 뒤 머지한다. 혼자 일해도 PR을 만들면 변경마다 설명과 검사 기록이 남는다.
이슈
할 일이나 버그 하나를 적어 두는 카드. "로그인 페이지가 404" 같은 문제를 이슈로 적고, 그걸 고치는 PR에서 "이 PR이 그 이슈를 닫는다"고 연결한다.
Git Flow
브랜치를 용도별로 나누는 규칙. 실제 서비스 중인 코드와 만들고 있는 코드를 섞지 않으려고 쓴다.
| 브랜치 | 용도 |
|---|---|
main | 실제로 서비스 중인 버전. 여기 들어가면 배포된다 |
develop | 다음 출시본을 모으는 곳. 평소 작업은 여기로 모인다 |
feature/* | 기능 하나를 만드는 곳. 끝나면 develop으로 |
release/* | 출시 준비. main으로 들어가며 배포된다 |
hotfix/* | 서비스 중인 버전의 급한 버그 수정. main에서 따서 바로 고친다 |
develop에 다음 출시본이 반쯤 들어가 있어도, 급한 버그는 hotfix로 서비스 중인 버전만 골라 고칠 수 있다.
버전 번호
v0.4.2 같은 출시 번호. 점으로 나뉜 세 숫자는 순서대로 MAJOR(크게 바뀜), MINOR(기능 추가), PATCH(버그 수정)다. 맨 앞이 0이면 "아직 정식 공개 전"이라는 뜻이다. 출시한 시점의 커밋에 버전 이름표를 붙여 두는데, 이걸 태그라고 한다.
2. 코드를 확인하는 방법
TDD
테스트 주도 개발(Test-Driven Development). 코드보다 테스트를 먼저 쓰는 방식.
- "이렇게 동작해야 한다"는 테스트를 먼저 쓴다. 아직 코드가 없으니 당연히 실패한다
- 그 테스트를 통과하는 만큼만 코드를 짠다
- 통과한 상태를 유지하면서 코드를 정리한다
테스트가 곧 "이 기능은 이렇게 동작한다"는 약속이 되고, 나중에 코드를 고치다 그 약속을 깨면 테스트가 바로 알려 준다.
테스트의 종류
| 종류 | 확인하는 것 | 비유 |
|---|---|---|
| 단위 테스트 | 함수 하나가 맞게 동작하는가 | 부품 하나 검사 |
| 통합 테스트 | 여러 부품이 DB와 함께 맞물려 동작하는가 | 엔진 조립 검사 |
| 컴포넌트 테스트 | 화면 한 장이 맞게 그려지는가 | 계기판 하나 검사 |
| 종단(E2E) 테스트 | 실제 서버 환경에서 처음부터 끝까지 되는가 | 완성차 시운전 |
아래 칸으로 갈수록 실제와 가깝지만 느리고 만들기 어렵다. 그래서 위 칸을 많이, 아래 칸을 적게 둔다. 그리고 어떤 테스트도 "실제 서비스 주소에서 진짜로 되는가"까지는 보장하지 못한다. 그건 리허설의 몫이다.
CI
코드를 올릴 때마다 테스트와 검사를 자동으로 돌리는 장치(Continuous Integration). 사람이 깜빡해도 기계가 매번 돌린다. 검사가 실패하면 main에 머지할 수 없게 막아 둔다. GitHub에서는 GitHub Actions가 이 일을 한다. 머지된 코드를 자동으로 서비스에 올리는 것까지 합쳐 CI/CD(Continuous Delivery/Deployment)라고 부른다.
3. 서비스에 올리는 방법
배포
만든 코드를 실제 서비스 서버에 올리는 것. 배포된 실제 서비스 환경을 운영(프로덕션)이라고 하고, 내 컴퓨터에서 돌려 보는 환경을 로컬이라고 한다. 로컬에서 되던 게 운영에서 안 되는 일은 생각보다 자주 생긴다.
시크릿
코드에 적으면 안 되는 비밀 값. 결제사 열쇠, DB 접속 정보, 서명용 비밀 값 같은 것이다. 레포에 올리면 누구나 볼 수 있으니 서버 설정에만 따로 넣는다. 많은 서비스(Cloudflare 포함)는 한 번 넣은 시크릿을 다시 보여 주지 않는다. 그래서 넣기 전에 비밀번호 관리자(1Password, Bitwarden 같은 비밀 값 금고)에 먼저 적어 둬야 한다. 안 그러면 아무도 원래 값을 모르게 된다.
Cron
정해진 시간마다 자동으로 실행되는 작업. "매일 0시에 이 작업을 돌려라" 같은 예약이다. 0 0 * * *는 매일 0시 0분, * * * * *는 매분이라는 뜻이다.
4. 데이터
DB
데이터를 저장하는 곳(데이터베이스). 사용자, 주문, 결제 기록이 엑셀 시트 같은 표에 들어 있다. DB에 데이터를 묻거나 고치는 언어가 SQL이고, 요청 하나를 쿼리라고 한다. SQL 명령어는 SQL 치트시트에 따로 있다.
스키마와 마이그레이션
스키마는 DB 표의 설계도, 마이그레이션은 그 설계도를 바꾸는 작업. "주문 표에 실패 사유 칸을 추가" 같은 변경을 순서대로 번호 붙인 파일로 남겨 두고, 배포할 때 아직 적용 안 된 것부터 차례로 적용한다. 운영 DB의 데이터를 지키면서 구조를 바꾸는 방법이다.
트랜잭션
여러 작업을 "전부 되거나 전부 안 되거나"로 묶는 것. 계좌 이체에서 "A에서 빼기"와 "B에 넣기"는 둘 다 되거나 둘 다 안 돼야 한다. 중간에 실패하면 앞의 작업도 없던 일이 된다. 읽기 전용 트랜잭션은 안에서 쓰기를 아예 못 하게 막은 트랜잭션이다. 운영 DB를 들여다볼 때 실수로 데이터를 바꾸지 않게 쓴다.
5. 문서와 확인
명세서
무엇을, 어떻게 만들지 적은 문서. 소프트웨어공학 수업에서 배우는 산출물이다.
- 계획서: 왜 만드는지, 범위, 위험, 비용, 결정 기록
- SRS(요구사항 명세서): 무엇을 만드는가. 항목마다
FR-3(기능 요구사항 3번) 같은 번호가 붙는다. 자세한 내용은 소프트웨어공학 4장 - SDD(설계 명세서): 어떻게 만드는가. 구조, DB, API 설계
인수 체크리스트
"이 단계를 끝났다고 인정하는" 확인 목록. 항목을 운영 환경에서 하나씩 확인하고 날짜와 함께 체크한다. 전부 체크돼야 다음 단계로 간다.
리허설
실제 서비스 환경에서 미리 해 보는 실전 연습. 테스트는 가짜 환경에서 돌지만, 리허설은 운영 서버에서 실제로 해 본다. 결제라면 운영 서버에 테스트 키로 결제를 일으키고, 결과(주문 상태, 메일, DB 기록)를 하나씩 눈으로 확인한다.
AI 코딩 에이전트
사람의 지시를 받아 코드를 읽고, 쓰고, 명령을 실행하는 AI. 채팅으로 코드 조각을 받는 것과 달리, 레포 전체를 보고 테스트를 돌리고 커밋까지 한다. 사람은 규칙과 결정을 정하고, 에이전트는 그 규칙대로 일한다. 규칙은 레포 안의 문서(CLAUDE.md, CONTRIBUTING.md)에 적어 둔다.