배포 프로세스 알아두기

Chapter 6. 회사 시스템 파악

"배포가 뭔지는 알겠는데... 우리 회사는 어떻게 하는 거지?"

개발 환경 구축을 마치고, 코드도 조금씩 읽기 시작했다. 이제 슬슬 실전이 가까워진다. 그런데 문득 궁금해진다. 내가 짠 코드는 어떻게 실제 서비스에 반영되는 걸까?

학교 프로젝트에서는 로컬에서 돌리고, GitHub에 푸시하면 끝이었다. 부트캠프에서는 Heroku에 배포 버튼 누르면 자동으로 올라갔다. 그런데 회사는 다르다. 배포 승인? 배포 담당자? 배포 시간대? 처음 듣는 단어들이 쏟아진다.

"배포 잘못하면 서비스 다운되는 거 아닌가? 진짜 무섭다."

Slack 채널을 뒤적이다 보면 "#deploy", "#release" 같은 채널이 보인다. 들어가서 메시지를 읽어보지만, 무슨 말인지 하나도 모르겠다.

걱정하지 마라. 배포는 생각보다 복잡하지 않다. 회사마다 방식이 다를 뿐, 기본 원리는 비슷하다. 여기서는 배포가 무엇인지, 회사에서는 어떻게 배포하는지, 그리고 신입 개발자가 알아야 할 배포 프로세스의 기본을 정리했다.

배포가 뭔가요?

배포(Deployment)란 개발한 코드를 실제 사용자가 접근할 수 있는 서버에 올리는 과정이다.

쉽게 말하면, 내가 만든 기능을 실제 서비스에 반영하는 것. 예를 들어 로그인 버튼 색을 파란색에서 빨간색으로 바꿨다면, 그 변경 사항이 실제 사용자 화면에 나타나게 하는 것이 배포다.

왜 배포가 중요할까?

코드를 아무리 잘 짜도, 배포하지 않으면 의미가 없다. 내 노트북에만 있는 코드는 아무도 쓸 수 없다. 배포해야 비로소 사용자가 쓸 수 있고, 서비스에 가치를 만들 수 있다.

하지만 배포는 동시에 위험하다. 잘못된 코드를 배포하면 서비스가 멈출 수 있다. 버그가 있는 코드를 배포하면 수천, 수만 명의 사용자에게 영향을 준다. 그래서 회사는 배포 프로세스를 체계적으로 관리한다.

배포 담당자 또는 자동화 여부

우리 회사는 누가 배포를 하는가?

회사마다 배포 방식이 완전히 다르다. 크게 세 가지 패턴이 있다.

1. 전담 배포 담당자가 있는 경우

회사에 "릴리즈 매니저" 또는 "배포 담당자"가 따로 있다. 개발자들은 코드만 작성하고, 실제 배포는 이 담당자가 진행한다.

이런 회사의 특징:

대기업, 금융권, 공공기관

서비스 안정성이 매우 중요한 회사

대규모 팀

신입 개발자가 할 일:

배포 담당자가 누구인지 파악

배포 요청 방법 숙지 (Jira 티켓, Slack 메시지 등)

배포 일정 확인

친구 회사에 이야기를 들었을때가 바로 이런 경우였다. 릴리즈 매니저가 따로 있었고, 배포는 매주 화요일과 목요일 오후 3시에만 진행된다고 한다. 처음에는 답답해 보였다. '개발자가 만든 기능을 왜 개발자가 배포를 못 하지?' 하지만 시간이 지나니 이해가 됐다고 했다. 금융 서비스 특성상, 한 번 잘못 배포하면 수백만 명의 사용자에게 영향을 준다. 전담 담당자가 체크리스트를 꼼꼼히 확인하고 배포하는 게 훨씬 안전했다.

2. 자동화된 CI/CD 파이프라인

코드를 GitHub에 푸시하고 PR이 머지되면, 자동으로 배포가 진행된다. Jenkins, GitHub Actions, CircleCI, GitLab CI 등의 도구를 사용한다.

이런 회사의 특징:

스타트업, IT 기업

빠른 배포가 중요한 회사

작은 팀, 애자일 문화

신입 개발자가 할 일:

CI/CD 파이프라인 이해하기

main 브랜치나 develop 브랜치에 머지하면 자동 배포되는지 확인

배포 로그 보는 법 배우기

자동화된 배포는 정말 편하다. 코드만 잘 짜면 알아서 배포된다. 하지만 처음에는 무섭다. '내가 실수로 이상한 코드를 푸시하면 어떡하지?' 걱정하지 마라. 대부분의 CI/CD 파이프라인은 테스트를 자동으로 돌리고, 테스트가 통과해야만 배포된다. 그리고 보통은 개발 환경 -> 테스트 환경 -> 운영 환경 순서로 단계적으로 배포되기 때문에, 바로 운영 환경에 반영되는 경우는 드물다.

3. 개발자가 직접 배포

개발자가 배포 스크립트를 직접 실행한다. 보통 쉘 스크립트나 배포 도구(Capistrano, Ansible 등)를 사용한다.

이런 회사의 특징:

소규모 스타트업

개발자의 자율성이 높은 회사

레거시 시스템

신입 개발자가 할 일:

배포 스크립트 위치 파악

배포 명령어 숙지

롤백 방법 미리 알아두기

내 경험상, 직접 배포하는 회사는 처음엔 불편하지만 배우는 게 많다. 배포 스크립트를 직접 실행하면서 서버 구조를 이해하게 되고, 문제가 생겼을 때 빠르게 대응하는 법을 배운다. 물론 실수할 가능성도 높다. 그래서 이런 회사에서는 반드시 선배와 함께 첫 배포를 진행하는 게 좋다.

실전 팁

어떤 방식이든, 첫 배포는 반드시 선배와 함께하자. "제가 배포 한 번 해봐도 될까요?" 이 질문 하나면 된다. 선배가 옆에서 든든하게 지켜보면서 알려줄 것이다. 혼자 하다가 실수하는 것보다 훨씬 안전하다. 그리고 함께 배포하다 실수하면 선배와 함께 책임을 나눌 수있다.

배포 시간대 및 주기

우리 회사는 언제 배포하는가?

배포는 아무 때나 하는 게 아니다. 회사마다 정해진 시간대와 주기가 있다.

배포 시간대가 중요한 이유

만약 월요일 오전 10시에 배포한다고 생각해보자. 이 시간은 사용자들이 가장 많이 접속하는 시간대다. 만약 배포 도중 서비스가 잠깐 멈추거나, 버그가 있는 코드가 올라간다면? 수많은 사용자가 불편을 겪는다. 고객센터에 전화가 쏟아진다. 그래서 대부분의 회사는 사용자가 적은 시간대에 배포한다.

평일 야간 (22:00~01:00)

가장 흔한 배포 시간대. 대부분의 사용자가 자고 있는 시간이라 영향을 최소화할 수 있다. 금융권, 대기업, 대규모 서비스에서 많이 사용한다.

배포가 밤 10시라면 배포 날에는 저녁을 먹고 다시 사무실로 돌아와야 했다. 처음에는 불편했지만, 나중에는 이해가 됐다. 우리 서비스는 낮 시간대 트래픽이 많았기 때문에, 밤에 배포하는 게 훨씬 안전했다. 그리고 배포 후에는 모니터링을 하면서 야식을 먹는 문화가 있었다. 선배들과 치킨을 먹으며 배포 로그를 보던 기억이 난다.

평일 오전 (08:00~09:00)

스타트업이나 B2B 서비스에서 많이 사용한다. 오전에 배포하고, 하루 종일 모니터링하면서 문제가 생기면 바로 대응할 수 있다. 개인적으로 가장 좋아하는 배포시간이다.

평일 오후 (14:00~17:00)

점심시간 직후, 하루 업무가 어느 정도 정리된 시간대. 문제가 생겨도 당일에 대응할 수 있는 시간적 여유가 있다.

금요일 오후는 피한다

"금요일 오후 배포 금지"는 거의 업계 불문율이다. HTML 글자 하나라도 절대 금요일에 배포하지 않는다. 만약 금요일 오후 5시에 배포했는데 문제가 생긴다면? 주말 내내 장애 대응을 해야 한다. 그래서 대부분의 회사는 금요일 오후 배포를 피한다.

예전에 금요일 오후 4시에 "작은 수정"이라며 배포한 적이 있다. "이 정도면 문제없겠지?" 했는데, 배포 후 30분 뒤 에러가 터졌다. 결국 금요일 저녁부터 토요일 새벽까지 장애 대응을 했다. 그 이후로 나는 절대 금요일 오후에 배포하지 않는다.

배포 주기

매일 배포

스타트업, 애자일 문화가 강한 회사일 경우 배포를 매일 하면서 빠르게 프로그램을 완성해 나간다. CI/CD가 잘 갖춰져야 가능하다.

주 2~3회 배포

중간 규모의 회사인 경우가 많다. 화요일, 목요일 같은 정해진 요일에 배포한다. 가장 선호하는 배포 주기다. 개인적으로 주 2회가 가장 적당하다고 생각한다.

주 1회 배포

대기업, 보수적인 회사이다. 보통 화요일이나 수요일에 배포한다. 가장 많이 경험해본 배포 주기다. 주 단위로 스프린트를 전략을 짜기 좋다.

월 1~2회 배포

금융권, 공공기관. 변경 사항을 모아서 한 번에 배포한다. 다양한 기능이 빠르게 출시되는것보다. 시스템 안정도를 더 중요시 하는 경우가 많다.

긴급 배포 (핫픽스)

배포 주기와 상관없이 심각한 버그나 보안 이슈가 발생했을 때는 정해진 주기와 상관없이 즉시 배포한다.

배포 승인 절차

우리 회사는 누가 배포를 승인하는가?

배포는 단순히 코드를 올리는 것만이 아니다. 대부분의 회사는 배포 전에 승인 절차를 거친다.

코드 리뷰 승인

PR(Pull Request)이나 MR(Merge Request)을 올리면, 최소 1~2명의 동료가 코드를 리뷰하고 승인해야 한다. 승인 없이는 머지할 수 없고, 머지하지 않으면 배포할 수 없다.

체크 포인트:

팀에서 코드 리뷰는 몇 명이 필요한가?

누구의 승인이 필요한가? (시니어? 팀장?)

리뷰 대기 시간은 보통 얼마나 걸리나?

QA 승인

테스트 서버에 배포한 후, QA 팀이 테스트를 진행한다. QA가 "문제없음"을 확인해야 운영 배포가 가능하다.

체크 포인트:

QA 팀이 따로 있는가?

테스트 시나리오는 누가 작성하나?

QA 테스트는 보통 얼마나 걸리나?

릴리즈 매니저 승인

대규모 회사에서는 릴리즈 매니저가 최종 승인을 한다. 코드 리뷰도 통과하고, QA도 통과했지만, 릴리즈 매니저가 "지금은 배포하지 말자"고 하면 배포가 미뤄진다.

체크 포인트:

릴리즈 매니저가 누구인가?

배포 승인은 어떻게 요청하나? (Jira, Slack, 이메일?)

승인 소요 시간은?

만약 배포 프로세스가 불명확하다면?

입사 첫 주에 배포 프로세스를 물어봤는데, "아, 그냥 배포하면 돼요"라는 애매한 답변을 들을 수 있다. 특히 소규모 스타트업에서는 배포 프로세스가 문서화되지 않은 경우가 많다. 이럴 때는 어떻게 해야 할까?

1. 실제 배포를 관찰하자

선배가 배포하는 모습을 옆에서 지켜보자. "배포할 때 옆에서 봐도 될까요?" 이 한 마디면 된다. 실제로 어떤 명령어를 입력하는지, 어떤 화면을 보는지, 어떤 메시지를 Slack에 보내는지 직접 보면 훨씬 이해가 빠르다.

2. 배포 히스토리를 확인하자

Slack의 "#deploy" 채널을 뒤적여보자. 과거 배포 메시지들을 읽어보면 패턴이 보인다. "언제 배포하는지", "누가 배포하는지", "어떤 형식으로 공지하는지" 알 수 있다.

3. 질문을 구체적으로 하자

"배포는 어떻게 하나요?"보다는:

"배포는 보통 몇 시에 하나요?"

"배포 전에 누구한테 승인받아야 하나요?"

"배포 명령어는 어디서 찾을 수 있나요?"

이렇게 구체적으로 물어보는 게 훨씬 명확한 답을 얻을 수 있다.

4. 배포 문서를 만들자

만약 정말 배포 문서가 없다면, 내가 직접 만들어보자. 첫 배포를 하면서 메모한 내용을 정리해서 사내 위키에 올리는 거다. "배포 프로세스 정리해봤습니다" 하고 공유하면, 팀원들이 고마워할 것이다. 그리고 나중에 또 다른 신입이 들어왔을 때 큰 도움이 된다.

신입 개발자의 첫 배포는 언제?

"나는 언제쯤 배포를 해볼 수 있을까?"

회사마다 다르지만, 보통 입사 후 2주~1개월 사이에 첫 배포를 경험한다. 물론 혼자 하는 게 아니라 선배와 함께한다

첫 배포 시나리오

대부분의 경우, 첫 배포는 아주 작은 변경 사항이다.

예를 들면:

오타 수정

버튼 색상 변경

간단한 텍스트 수정

로그 메시지 추가

이런 작은 변경 사항으로 배포 프로세스를 경험하는 거다. 만약 잘못되더라도 큰 문제가 생기지 않는 범위에서 연습해보자.

나의 첫 배포는 입사하고 한 1~2주 차에 했던거 같다. HTML 글자를 간단하게 바꾸는 아주 작은 변경이었다. 선배가 옆에 앉아서 단계별로 알려줬다. 코드 작성 후, 코드를 리뷰 받고, 테스트 서버에 배포하고, QA 확인받고, 운영 배포하고, 모니터링하고. 그때는 "이렇게 간단한 변경도 이렇게 오래 걸리나?" 싶었지만, 지금 생각하면 그 과정이 필요했다. 배포의 전체 흐름을 이해하는 소중한 경험이었다.

체크리스트: 배포 프로세스 파악 완료

입사 첫 주에 다음 항목들을 확인했는지 체크하자.

배포 담당

배포는 누가 하는가? (담당자 / 자동화 / 개발자 직접)

CI/CD 파이프라인이 있는가?

배포 스크립트는 어디에 있는가?

배포 시간

배포는 언제 하는가? (시간대)

배포 주기는? (매일 / 주 N회 / 월 N회)

금요일 오후 배포 금지 규칙이 있는가?

배포 승인

코드 리뷰는 몇 명이 필요한가?

QA 테스트가 필요한가?

릴리즈 매니저 승인이 필요한가?

배포 체크리스트가 있는가?

배포 공지는 어디에 하는가? (Slack 채널)

배포 문서는 어디에 있는가?

첫 배포는 언제쯤 해볼 수 있나?

배포 프로세스, 이제 조금 알거 같기도..

처음에는 막연하게 무섭기만 했던 배포. 이제 조금 구체적으로 보이기 시작했을 것이다.

배포는 누가 하는지, 언제 하는지, 어떤 승인을 거치는지. 이 세 가지만 알아도 배포에 대한 막연한 두려움은 많이 줄어든다. 물론 실제로 배포를 해보기 전까지는 여전히 긴장될 것이다. 그건 당연하다. 하지만 적어도 "아무것도 모르는 상태"는 아니다. 어떤 과정을 거치는지 알고 있고, 어떻게 준비해야 할지 알고 있다.

그리고 기억하자. 첫 배포는 혼자 하는 게 아니다. 선배가 옆에서 함께한다. 하나씩 알려줄 것이다. 그리고 몇 번 경험하고 나면, 배포는 더 이상 무섭지 않게 된다. 오히려 뿌듯한 순간이 된다.

배포 후에는 반드시 모니터링이 필수라는걸 꼭 명심하길 바란다.