💧금요일엔...슬픈 전설이 있어...

IT에 관심 있는 밀레니얼 세대를 위한 뉴스레터, 1 STEP입니다.

MEME 사용 설명서는 IT 업계에서 자주 보이는 MEME(짤)에 대해 이야기해보고 이해해 보는 시간입니다!

멀게만 느껴졌던 IT 분야에 한 걸음 한 걸음 나아갈 수 있도록, 1 STEP과 함께해요! 😉

☠️ 오늘의 MEME | 금요일 배포는 죽음 뿐...

난 네가 누군지 모른다...

다만 네가 금요일에 배포를 한다면, 널 찾아내서 널 죽일 것이다...🔫

🙅 No Deploy Fridays

No Deploy Fridays(금요일엔 배포 금지)는 유명한 프로그래밍 조크입니다 (띠용😲). 물론 전혀 웃기지는 않지만 나름 오래된 히스토리를 가진 고전 유우-머이지요. 얼마나 묵히고 묵힌 고전인지 티셔츠부터 머그컵, 폰 케이스, 그리고 마스크 까지 셀러브리티에 버금가는 상품의 규모를 자랑할 지경입니다.

이쯤 되니 굳이 이렇게까지 금요일 배포를 반대하고 나서는 이유가 너무 궁금해지는데요. 도대체 배포라는 것이 무엇이길래 금요일에는 하지 말라며 상품 제작부터 난데없는 살인예고까지 날리게 된 걸까요? 🧐

📍 Deploy (배포하기)

코딩 수업을 들어보신 분들은 배포라는 단어를 한 번쯤 들어보셨을 텐데요. 여기서 배포란 (다수의 사람에게) 나눠준다는 원래 단어의 뜻과 유사하게, 제작한 소프트웨어를 사용자들이 사용할 수 있도록 제공하는 것을 뜻합니다. 이렇게 소프트웨어를 전달하는 배포까지의 과정은 '컴파일* - 빌드** - 배포' 순서로 진행이 되는데요. 다소 생소해 보이는 단어의 조합으로 이루어진 배포 진행 과정을 조금 더 쉽게 이해해볼 수 있도록 번역가가 영화 번역을 하는 상황으로 풀어내 보겠습니다.

*컴파일: 작성한 코드를 컴퓨터가 이해 가능한 언어로 번역하는 것 
**빌드: 컴파일된 코드를 실행할 수 있는 상태로 만드는 것

🍿 관객이 '번역된 자막이 추가된 영화'를 관람하는 것처럼 📂 사용자가 접근할 수 있는 환경에 '빌드된 파일'을 배치하는 것이 바로 배포인 것인데요. 사용자와 직접 맞닿아 있는 단계인 만큼 굉장히 중요해 보이는데, 도대체 왜 금요일에 하지 말라는 것일까요?

🔥 Do Not Deploy on Fridays (금요일에는 배포하지 마세요)

금요일에 배포하라고 했다네...

그래도 괜찮을 거라고 했다네...

금요일에 배포하는 것을 반대하는 개발자들에게는 다양한 반대의 이유가 있습니다. 그중에서도 소프트웨어에 어떠한 문제가 생겼을 때 즉각적인 대응이 힘들다는 이유가 가장 크다고 하는데요. 한마디로 '금요일에 배포만 안 하면 피할 수 있는 위험을 왜 굳이 감수해야 하지?'라는 것이지요.

배포 전에 아무리 충분한 테스트를 실행하고 수정을 거치더라도, 어떠한 서비스나 제품이 문제를 일으키지 않고 원하는 바에 100% 상응하는 퀄리티를 보장하게 할 수는 없는데요. 즉, 배포 후에 벌어질 수 있는 문제 발생 가능성을 완전히 없애는 것은 불가능하다고 할 수 있기에 금요일 배포를 멀리하고 있는 것입니다.

이 외에도 🤯 야근과 주말 출근을 할 확률이 높아지기 때문에 금요일 배포를 피한다고 하는데요. 만약 위에서 언급된 문제 발생 가능성이 실제 버그*로 이어진다면, 이 문제를 해결하기 위해 디버깅**을 해야만 합니다. 그 말인즉슨, 금요일에 진행한 배포로 인한 버그를 고치기 위해 금요일 야근이나 주말에 출근하는 것을 피할 수 없다는 것이지요. 이렇듯 워라밸을 위협할 수 있다는 이유로 금요일에 배포하는 것은 신중해질 수밖에 없는 문제인 것입니다.

*버그: 응용 프로그램이 원하던 결과를 내지 않는 것으로 프로그래머에 의해 생긴 에러
**디버그(디버깅): 프로그램 개발 중에 발생하는 에러를 찾아내고 수정하는 작업

🇳 넷플릭스도 금요일에는 배포 금지?

트위터 블락이요? 헐 ㅎ 근데 금요일 오후 (배포)를 피하는 건 넷플 사내규정 같은 건데요?

-현 넷플릭스 클라우드 컴퓨팅 개발자

넷플릭스의 예시처럼 개발자 개인뿐 아니라, 기업 자체에서 금요일에 배포하지 않도록 사내문화나 규정으로 정하는 경우도 적지 않은데요. 어느 정도 규모 이상의 프로덕션 환경에서는 꼭 배포가 필요한 경우가 아니라면, 앞서 이야기한 것처럼 혹여나 발생할 수 있는 위험을 구태여 감수할 필요가 없다고 여기기 때문이죠. 대신 금요일에는 배포 업무를 진행하지 않고, 📝 서류화 작업이나 🤝 회의 등 배포 외 업무를 진행하도록 권장되는 편입니다.

🤔 Why Not? (금요일 배포 L❤️VE)

물론 금요일 배포를 적극적으로 찬성하는 개발자들도 있습니다. 이들은 단지 금요일이라는 이유만으로 🙅 배포를 회피할 필요는 없다는 의견인데요. 개발자 본인이 작성한 코드를 충분히 이해하고 있다면, 요일에 상관없이 당장 배포하지 않을 이유가 전혀 없다는 것입니다. 자신의 코드가 적합하게 작성되었는지, 의도한 대로 작동하고 있는지 등에 대해 정확하게 파악하고 있기 때문에, 금요일에 배포하고 나서 버그가 생기더라도 비교적 수월한 디버깅을 할 수 있다는 것이지요. 반면, 코드에 대한 이해가 다소 부족한 상황에서는 이보다 더 오랜 시간을 할애하여 문제를 파악하고, 더욱 긴 시간을 쏟아 디버깅을 해야 하기 때문에 금요일에 배포하기를 두려워하게 된다는 것입니다.

이뿐만 아니라, 배포를 주저하게 되는 이유에는 현재 참여하고 있는 프로젝트가 제대로 모니터링 되지 않거나 테스트 커버리지*가 좋지 않기 때문일 수도 있다고 하는데요. 적절한 모니터링과 테스트 커버리지는 예측범위 내의 버그를 빠르게 수정하거나 발생하는 것을 제어할 수 있기 때문에 훨씬 더 효과적인 개발을 할 수 있도록 도와줍니다. 간단히 말하자면, 버그가 개발자보다 사용자에게 먼저 발견되는 상황을 피할 수 있게 도와주는 필수 장치인 것이지요.

이러한 필수 장치의 부족한 점을 보완하지 않게 되면 버그가 사용자에게 무작위로 나타나는 상황이 더욱 자주 발생하게 됩니다. 그렇게 되면 점점 배포가 💣 언제 터질지 모르는 시한폭탄을 사용자에게 선보이는 것처럼 느껴져, 결국 배포하는 행위 자체를 꺼리게 될 수 있는 것인데요. 하지만, 이는 어디까지나 모니터링과 테스트 커버리지 업그레이드를 통하여 개선할 사항이지 배포를 두려워할 이유로 삼을 필요는 없을 것 같습니다.

금요일에는 배포 금지! 이에 대한 팽팽한 양쪽 입장을 보셨는데요. 금요일 배포 YES or NO? 여러분의 선택은 무엇인가요?

*테스트 커버리지: 테스트를 잘하도록 돕는 기법으로 테스트 대상이 실제 얼마나 테스트를 수행했는지에 대한 참조지표

🔖 1분 지식 | 구글은...택시 driver...🚕

최근 웨이모(구글 슬렉스의 연구소에서 개발하는 무인 자동차 기업)에서 내달부터 🤖 세계 최초로 로보택시 🤖 를 상용화하겠다고 발표했습니다. 이 로보택시는 사람의 손을 전혀 거치지 않는  자율주행차*를 사용하여 택시 서비스를 제공하는 것으로, 수년간의 시범 운행과 테스트를 걸친 후 드디어 본격 운영에 나서게 된 것입니다! 🥳

*자율주행차: 무인 자동차라고도 불리며 인간이 운전할 필요 없이 스스로 주행이 가능한 자동차를 뜻함

로보택시 서비스는 우리에게 너무나 친숙한 카카오 택시 어플 사용 방법과 비슷한데요. 먼저 어플로 택시를 호출하고 원하는 목적지만 입력해주면, 택시가 알아서 사용자를 해당 목적지까지 이동 시켜 줍니다.

웨이모에서는 본격 운영에 앞서, 당분간은 수익보다는 기술에 더욱 집중할 것이라고 밝혔으며, 전문가들은 웨이모가 계속해서 자율주행 분야를 리딩해갈 것으로 예측하고 있습니다.

드디어 영화 백투더퓨처의 한 장면일 것만 같던 무인 자동차를 택시로 만나볼 수 있는 걸까요?

오늘 뉴스레터, 어떠셨나요?

피드백은 1 STEP이 더 좋은 콘텐츠를 고민하고 만드는 데 큰 도움이 됩니다.

오늘의 아쉬웠던 점, 칭찬은 여기로 부탁드려요 👐