프로 엔지니어의 워크플로
전 세계 모든 테크 회사가 코드를 출시하는 방식
⏱ 예상 ~13분
01 · 읽기
이제 개별 기술을 다 배웠어요. 터미널, 파일, git, 웹 서버, API, Claude Code, 디버깅, 배포. 이제 이걸 모든 프로 개발 팀이 따르는 워크플로로 묶어볼게요.
도구는 달라요. 어떤 팀은 GitHub 대신 GitLab을 쓰고, 어떤 팀은 Render 대신 AWS에 배포하고, 어떤 팀은 다른 언어를 써요. 하지만 워크플로는 항상 같아요. 이 워크플로를 배우면, 어떤 테크 회사에 가도 그들이 어떻게 소프트웨어를 출시하는지 이해할 수 있어요.
💡 상상해 봐요개별 기술은 드리블, 패스, 슛 연습과 같아요. 프로 워크플로는 실제 경기예요. 배운 걸 어떻게 조합해 결과를 만드는지 조율된 순서를 다루죠. 워크플로를 이해하는 건 코딩을 할 줄 아는 것과 출시할 수 있는 것의 차이예요.
02 · 단계별 설명
완전한 개발 사이클이에요. 모든 기능, 버그 수정, 개선은 이 정확한 루프를 따라요.
1. ISSUE
누군가 버그를 보고하거나 기능을 요청해요. 이건 GitHub Issues, Jira 보드, 또는 단순한 할 일 목록에서 추적돼요. 모든 작업은 명확하게 기술된 문제나 목표에서 시작해요.
2. BRANCH
브랜치를 만드세요: git checkout -b fix-login-bug. main에서 직접 작업하지 마세요. 브랜치가 변경을 격리해서, 아무것도 망가뜨리지 않고 실험할 수 있어요.
3. CODE
Claude Code로 수정이나 기능을 구현하세요. 원하는 걸 명확히 설명하고, 결과물을 검토하고, 맞을 때까지 반복하세요. 실제로 만드는 단계예요.
4. TEST
로컬에서 동작하는지 확인하세요. 엣지 케이스도 확인하고요. 다른 걸 망가뜨리진 않나요? 이상한 입력, 빈 필드, 예상 못 한 시나리오를 시도해 보세요. 자동 테스트가 있다면 돌리세요.
5. REVIEW
git diff를 실행하세요. 자기 변경을 한 줄씩 검토하세요. 다른 사람이 썼다면 승인할까요? 남은 console.log, 하드코딩된 값, 거기 있으면 안 되는 걸 찾으세요.
6. COMMIT
Stage하고 설명적인 메시지로 commit하세요. 논리적 변경 하나당 commit 하나예요. 'Fix login validation to reject empty passwords'는 이야기를 들려줘요. 'Fixed stuff'는 안 들려주죠.
7. PUSH
브랜치를 GitHub에 push하세요: git push -u origin fix-login-bug. 다른 사람이 변경을 보고 리뷰할 수 있게 해줘요.
8. PULL REQUEST
GitHub에서 PR을 만드세요. 뭘 바꿨고 왜 바꿨는지 설명하세요. 팀원(또는 미래의 나)이 라이브로 가기 전에 코드를 리뷰하는 곳이에요. 컨텍스트를 포함하세요: 버그가 뭐였나? 어떻게 고쳤나? 다른 사람이 어떻게 테스트하나?
9. MERGE
리뷰와 승인이 끝나면 main으로 merge하세요. 기능 브랜치는 역할을 다했으니 삭제할 수 있어요. 이제 변경이 공식 코드베이스의 일부예요.
10. DEPLOY
자동 배포가 설정돼 있다면(Render처럼) main에 merge되는 순간 변경이 자동으로 라이브가 돼요. 아니라면 수동 배포를 트리거하세요. 어느 쪽이든 사이클이 완료돼요. 아이디어에서 라이브 기능까지요.
03 · 읽기
이 워크플로의 핵심 git 단계를 직접 해볼게요. 아직 git이 추적하지 않는 프로젝트가 있어요. 초기화하고, 기능 브랜치를 만들고, 변경하고, stage해 볼 거예요.
04 · 터미널 실습
모든 프로젝트는 git init으로 시작해요. 평범한 폴더를 git 리포지터리로 바꿔서 변경을 추적할 수 있게 해요.
(이 섹션은 인터랙티브해요 — JavaScript를 켜 주세요.)
05 · 터미널 실습
1단계: BRANCH — 새 기능 브랜치를 만드세요. main에서 직접 작업하지 마세요. 브랜치는 안전하게 실험할 수 있게 해줘요.
(이 섹션은 인터랙티브해요 — JavaScript를 켜 주세요.)
06 · 터미널 실습
2단계: CODE — 프로젝트를 변경하세요. HTML 파일에 로그인 폼을 추가할게요.
(이 섹션은 인터랙티브해요 — JavaScript를 켜 주세요.)
07 · 터미널 실습
3단계: COMMIT — 파일을 stage하고 설명적인 메시지로 commit하세요. 좋은 commit 메시지는 뭘 바꿨고 왜 바꿨는지 설명해요.
(이 섹션은 인터랙티브해요 — JavaScript를 켜 주세요.)
08 · 읽기
중간 점검 — BRANCH → CODE → COMMIT 완료
방금 프로 엔지니어가 매일 하는 일의 앞 세 단계를 끝냈어요. 브랜치 열기 → 코드 작성 → 설명적인 메시지로 commit. 이 세 단계는 모든 팀이 따르는 거예요. 프로젝트 규모에 상관없이요.
남은 후반전은 PR(pull request) → 코드 리뷰 → merge 예요. 내 브랜치의 변경을 팀의 본류로 합치자고 제안하는 과정이에요.
왜 main에 바로 merge하면 안 될까요? 아무도 리뷰하지 않고 merge하면 버그가 들어가도 막을 사람이 없거든요. PR은 팀원이 내 변경을 보고, 의견을 주고, 문제가 없는지 확인한 다음에 통과시키는 절차예요. 이 절차 층이 프로 엔지니어링의 핵심이에요.
핵심 정리
- 세 단계: branch / code / commit(완료)
- 남은 세 단계: push / pull request / 코드 리뷰 + merge
- Commit 메시지는 뭘 바꿨고 왜 바꿨는지 설명해요 — 미래의 내가 오늘의 나에게 고마워할 거예요
09 · 퀴즈
프로 워크플로에서, 코드를 쓰기 전에 뭘 만드나요?
- 새 리포
- 데이터베이스
- 새 브랜치
- 작업을 기술한 GitHub 이슈
10 · 빈칸 채우기
기능을 완성한 다음, 변경을 merge하자고 제안하려고 pull _____ 을 만들어요.
11 · 읽기
축하해요. 방금 Google, Stripe, Shopify, 그리고 다른 모든 테크 회사가 쓰는 것과 같은 워크플로를 따랐어요. 규모는 다르지만 워크플로는 같아요. 이슈, 브랜치, 코드, 테스트, 리뷰, commit, push, PR, merge, 배포.
큰 회사는 하루에 이 루프를 수백 번 돌려요. 이제 여러분도 똑같이 할 수 있어요.
12 · 퀴즈
방금 기능 브랜치에서 버그 수정을 마쳤어요. Commit 전에 뭘 해야 할까요?
- git diff로 변경을 한 줄씩 검토
- main으로 바로 push
- pull request 생성
- 브랜치 삭제하고 처음부터 다시
13 · 빈칸 채우기
프로 워크플로에서, 모든 작업은 명확하게 기술된 _____ 에서 시작해요. 버그 보고나 기능 요청이죠.
⚠ 전체 인터랙티브 경험에는 JavaScript가 필요해요. JavaScript를 켜고 새로 고침해 주세요.
※ 이 사이트는 독립 운영되는 교육 프로젝트로, Anthropic의 공식 제품이 아니에요. Claude™ 는 Anthropic, PBC 의 상표예요.