초짜 개발자로서 묻고 싶었으나 창피해서 못 물어본 것
2016년 4월 25일
코드리뷰. 깃헙/깃. 빌드. 디플로이. 스테이징. 프로덕션.
복잡하고 기술적인 문서는 엄청 많으니까 인터넷에서 맘껏 찾아보시고.
개발자를 CJ 푸드 내의 편의점 도시락 개발팀 레시피 연구 직원이라고 하자. 당신의 일은 레시피를 만들고 테스트해서 최종화하고 공장에 넘기는 것이다.
기존의 초히트작 "5천 원 돈가스 도시락" 메뉴를 어떻게 더 맛있게/저렴하게 할까 연구 중이다. 이 때 오리지널 레시피를 당신 맘대로 바꾸면 시말서로 안 끝나겠지. 그래서 당신은 오리지널 레시피를 복사해서 연구실로 가지고 온다(이것을 '마스터'에서 '체크아웃'이라고 한다. 복사본 만들어 온 거다.). 그런데 당신 옆자리 영수도 똑같은 레시피를 연구하고 있다. 당신은 카레 소스를 더할까 하고 있는데 영수는 케첩을 더하고 싶어 한다. 이럴 때 두 사람이 일한 것을 합치면 난리가 나겠으나, 영수는 사실 도시락 메뉴 레이아웃만 바꾸려고 했다면 두 프로젝트를 합쳐도 상관이 없다. 이래서 당신 둘은 "체크아웃" 해서, 각자 프로젝트 "브랜치"를 만든 것을 합치 "merge" 하는 것이다. 이때 둘 다 소스를 바꾸려고 했다면 당연히 에러가 난다. 똑같은 부분을 바꿨으니까 "카레야 케첩이야 하나만 해 하나만"이라는 에러가 뜬다. 아니라면 알아서 잘 합쳐진다. 이렇게 복사본 쉽게 만들고 다시 합하고 체크인하고 하는 등등의 작업을 쉽게 해주는 시스템을 Version control system이라고 하는데 요즘엔 깃헙이나 깃 주로 쓴다(Github/git. 온라인에 호스팅 해주는 github, 내 서버나 회사 서버에 깔아서 쓰는 git).
보통은 레시피를 이렇게 바꾼 다음 혼자 만들어 보고(유닛 테스트), 오, 이 정도면 괜찮다 싶을 때 동료들에게 리뷰를 보낸다. 동료들이 그러면 그 레시피를보고 "야 소금 넘 많지 않냐?" "카레 소스 어디 건데?" "이거 조리 시간 너무 늘어나지 않냐?" 등등의 의견을 낸다. 그것을 조합하고 고칠 건 고치고 그냥 둘 건 두고 하는 것이 코드 리뷰다.
고친 레시피를 지가 만들어 보지도 않는 건(유닛 테스트도 없이, 제대로 된 테스팅 없이 체크인) 심히 맞을 짓이다. 아 그리고 코드 리뷰 하는 동료들은 레시피 고친 것만 보고 이래저래 의견을 내지 자신들도 직접 만들어 보는 일은 별로 없다(static 리뷰).
자, 레시피 리뷰도 다 끝냈으면 이걸 매뉴얼화해서 공장으로 보내야 한다. 이렇게 배포 가능한 레시피 책자로 만드는 것을 "빌드"라고 한다. 보통은 빌드 전에 기본 테스트도 돌린다. 오탈자 확인하고 페이지 확인하고 사진 확인하고 등등. 이 때 기본 테스트 실패하면 빌드 실패가 되고 당신의 체크인은 딱지를 먹는다.
빌드가 제대로 되면 보통은 테스트/integration/스테이징 등의 환경에 디플로이 된다. 이게 뭔 말이냐면, 이쁘게 만들어진 레시피 책자를 가지고 테스트 공장에다 보내보는 것이다. 거기에서 만들고 구내식당 편의점에만 풀어본다. "내가 집에서 했을 때는 맛있었는데..." 이런 거 믿고 전국구에 확 풀어버리면 큰일 나기 때문이다. 스테이징은 전국적인 스케일은 아니더라도 어쨌든 공장에서 만들어 보고 완전 외부인은 아니지만 팀원은 아닌 사람들이 테스트를 해 볼 수 있는 기회다.
여기에서도 괜찮았다 하면 다시 전국적으로 디플로이를 하게 되겠다. 모든 공장에 새로운 레시피를 배포하고, 당신의 새로운 카레 소스 돈가스가 편의점에 깔리는 것이다. 프로덕션이라고도 하고 라이브 사이트라고도 한다. 프로덕션에 디플로이 하는 것을 deploy to prod/go live라고 하는데, 실제 프로덕션으로 디플로이/릴리즈 하는 게 큰 행사인 회사에서는 풀기 전날부터 전쟁 상황실(실제로 war room 이란 명칭 쓴 회사에 다녔다) 오픈해 놓고 데브옵스(devops)들은 내의/커피/베개 챙겨와서 밤샐 준비한다. 반만 농담이다.
일주일에도 몇 번씩 릴리즈하는 팀은 그냥 팀 챗에다가 "디플로이 한다아아아아!!" 경고하고 온 콜 (대기)인 애한테서 욕먹을 준비한다. 그러다가 혹시 뭔가 잘못됐다, 클났다 싶으면... 롤백 (rollback). 디플로이한 새로운 빌드를 없애고 이전 버전으로 돌아가는 것. 어쨌든 이런 이유로 보통 금요일에는 고 라이브 안 한다. 잘못돼서 망하면 모두들 주말 반납해야 하기 때문이다.
뭘 크게 잘못해서 시스템 전체가 다운 됐다(outage) 하면... 그 심각도에 따라서 일 끝나고 나서 post-mortem이 있다. 사후에 요인 분석한다는 뭐 그런. 왜 outage가 일어났는지, 다음에는 어떻게 그런 일이 없도록 대비할 수 있는지 등등에 대한 길고 긴 미팅이 있다.
오옷. A4 한 페이지 정도로 용어 다 정리 끝.
