Byungwoo의 블로그

Hello

안녕하세요? 대학교를 졸업하고 일상의 문제를 해결하는 소프트웨어의 매력에 빠져서 개발자가 되었습니다. 솔루션 개발자로 커리어를 시작하였고 우연한 계기로 NLP 개발자가 되었지만 나무보다 숲을 보는 것을 좋아하여 DevOps 엔지니어가 되었습니다. 현재에는 클라우드의 매력에 빠져들어 SRE(Site Reliability Engineer)로 일하고 있습니다. 서비스의 운영과 구축에 관심이 있고 함께 일하는 동료와 조직의 생산성 향상을 추구합니다. 최신기술보다 문제를 해결할 수 있는 적정기술을 선호합니다. 혼자서 빠르게 가는 것보다 함께 멀리가는 것을 중요하게 생각합니다.

Recents Postings

Gallery

Postings

Docker Desktop 유료화

Docker Desktop이 유료화됨에 따라서 기업에서 데스크톱용 Docker를 사용하기 위해서는 월 구독료를 지불해야 한다. 2022년 1월까지가 유예기간이었고 2월부터는 250명 이상의 직원이 속한 매출 1,000만 달러 이상의 기업은 무료로 Docker Desktop을 이용할 수 없다.

그렇다면 서버마다 월 구독료를 내야하는 것인가? 그렇지는 않다. 유료화가 진행된 것은 Docker Desktop이지 Docker Engine 자체는 아니기 때문이다. 이게 무슨 말인지 이해하려면 일단 Docker Engine과 Docker CLI를 구별해야 한다.

Docker? Container?

우선 많이들 혼동하는 부분이 있는데 일단 컨테이너와 Docker는 동일한 개념이 아니다. 컨테이너 기술은 여러 컨테이너 런타임으로 구현할 수 있도 Docker는 그 중에 하나일 뿐이다.

Docker Engine? Docker CLI?

Docker Engine(Daemon)과 Docker CLI(Client)를 Docker라는 용어로 묶어서 사용하는데 두 가지는 별도로 설치되고 관리되는 것이기 때문에 구분이 필요하다.

Docker Desktop의 대체재를 찾아보자

2022/02/17

🐳

Container

DevOps & 커리어

3월, 8월, 9월에 서비스를 출시하였고 현재 온프레미스로 구성된 서비스를 클라우드로 전환하는 프로젝트의 시작을 앞두고 있었다. 프로젝트 시작하는 시기인 11월 초에 나의 현재 상태를 돌아보는 시간을 가졌다. 가만히 생각해봐도 지금 클라우드로 전환하는 프로젝트를 하는 것보다는 클라우드를 생각하는 회사를 들어가서 클라우드를 사용하는 커리어를 쌓는게 더 빨리 성장할 수 있을 것 같다는 판단이 들었다.

11월 중순에 아내님과 함께 처음이자 마지막으로 워케이션을 일주일 정도 다녀오고 나서 본격적으로 이직 준비를 11월 말부터 시작하였다. 링크드인에 이력서를 업데이트하자마자 아무래도 경력직인지 여러 회사들의 리크루터(채용담당자)들이 연락이 오기 시작하였다. 부담없이 커피챗(티타임)을 제안하였고 나도 이직에 관심이 있어서 리크루터를 만나서 해당 회사에 대한 서비스를 소개받고 DevOps 엔지니어 직무를 뽑고 있다는 이야기를 들었다. "오 그래 나도 이제 시장에서 잘 팔리는 때구만~"이라고 생각해서 커피챗이 끝나고 이력서를 정리해서 해당 회사에 지원을 하였다. 그러나 정말 슬프게도 리크루터와 실무담당자의 기준은 다른지 클라우드 경력이 부재하다는 이유로 첫 번째 단계에서 부터 탈락하는 곳에 대부분이었고 오랜만에 현실의 쓴 고배를 마시면서 슬픈 나날을 보냈다.

그러던 중 오픈소스 컨트리뷰톤에서 같이 프로젝트를 진행한 동료 멘티의 회사에서 DevOps 엔지니어를 뽑다는 이야기를 들었고 이번에는 리크루터가 아닌 실무담당자(DevOps)와의 커피챗을 나누었고 이야기를 하면서 해당 팀이 계속 학습하고 성장하는 분위기로 이루어져 있고 현재 모든 서비스가 클라우드에서 운영된다는 점을 알게되어 집에 오자마자 이력서를 작성하여 사내추천 전형으로 지원하였다. 다행히도 서류를 통과하고 과제를 전달받아서 오랜만에 개발 프로젝트를 하게 되었고 과제를 바탕으로 1차 면접을 보았고 최종적으로 2차 면접까지 본 후에 합격하였다.

기간상으로는 지원에서부터 합격이 오래 걸리지는 않았지만 오랜만에 이직이라는 것을 하다보니 실감도 잘 안났고 중간중간에 이게 맞는 길인지 의구심이 들 때가 있었다. 일하면서도 머릿속이 너무 복잡했고 밤에도 잠못 이루거나 자다가 깨는 날도 많았다. 그러나 일단 가려는 곳이 최종 종착지는 아닐 수 있어도 나의 커리어 성장을 위해서는 좋은 디딤돌이라는 생각은 틀림없다고 생각하여 입사하기로 결정하였다.

이직을 하는 곳은 현재 다니는 회사처럼 시작이 IT서비스인 회사는 아니지만 최근에 엔지니어에 대한 투자를 엄청나게 늘리면서 무섭게 성장하고 있는 회사라는 점에서 색다른 경험이 될 것 같다. 회고를 쓰는 이 시점에서 느끼는 것은 지원하기 전까지 너무 많은 고민을 내가 했던 것 같고 생각보다 지원하고 나서 그 회사에 대해서 알아가는 점도 많아서 굳이 이직을 결심하지 않아도 나의 시장성(?)을 검증하기 위한 용도로 다른 회사에 종종 지원하는 것도 괜찮은 경험일 수도 있겠다는 생각이 들었다. 만약 면접보는 것이 부담이라면 (리크루터나 가능하다면 실무자와) 커피챗을 평소에 하면서 궁금한 점들을 물어보면서 나의 다음 정거장을 탐색하는 것도 좋은 커리어 설계 방안이 될 것 같다.

블로그 포스팅 스터디 6기

2021년에는 마음먹고 글을 쓰는 습관을 어느 정도 들이기 위해서 블로그 포스팅 스터디 3기에 참가하였고 정신을 차려보니 어느덧 4/4분기의 6기까지 이어서 활동하고 있다. 6기 동안에는 이직준비를 하느라 정신이 없어서 그런지 한 번 포스팅을 놓쳤고 그 결과 나의 개근(?)이 깨졌다. 그래도 이직을 위한 준비겸 이번에 포스팅한 글들을 모아서 oopy를 활용하여 개인 블로그를 만들고 포스팅한 글들도 모두 옮겼다. 물론 사랑하는 아내님의 도움과 함께 아내님의 블로그를 참고하였기에 단기간에 가능한 결과물이었던 것 같다. 앞으로는 개인 블로그에 작성한 글과 공부한 내용 그리고 나의 이력사항을 지속적으로 업데이트할 예정이다.

2021 4/4분기 회고

2021/12/23

🏃

Personal

도커로 구성하는 개발환경과 운영환경

컨테이너 오케스트레이션이 대중화가 되면서 어플리케이션을 컨테이너화하고 배포하는 일이 많아졌습니다. 더불어 컨테이너화를 통해서 코드와 실행환경을 묶어서 배포할 수 있게 되어서 "로컬에서는 되던데 서버에서는 왜 안되나요?..."라는 질문이 조금씩 사라지고 있습니다.

개발하고 배포하는 이미지를 만드는 과정은 보통 다음과 같은 세 가지 형태를 띕니다. 첫번째는 도커 없이 개발을 완료한 후에 도커파일로 빌드한 후에 이미지를 푸쉬하는 방식입니다. Spring Boot의 경우 ./gradlew bootRun, Flask의 경우 python3 -m flask run의 명령어로 실행한 상태에서 개발을 완료한 후에 이미지를 빌드하는 것입니다. 이 방법은 개발속도는 빠를 수도 있지만 도커 없이 개발하는 상태에서 없었던 문제가 도커파일로 빌드한 후에 나타날 경우 이를 찾거나 해결하는 데에 오래걸릴 수 있다는 단점이 있습니다.

두 번째는 소스폴더를 마운트하여 개발환경을 도커로 구성하는 방법입니다. '도커로 개발환경 구성하기'라고 검색할 경우 가장 많이 나오는 예시입니다. 도커로 어플리케이션을 debug 모드로 소스코드 폴더를 마운트하여 소스코드에서 변경점이 생길 경우 리로드가 되면서 변경사항을 실시간으로 확인할 수 있는 방법입니다. 컨테이너화한 상태에서 개발을 진행하하기는 하지만 프로덕션에서는 앞단에 웹서버를 두거나 WSGI를 두는 경우가 많아서 개발단계에서 사용한 컨테이너와 프로덕션에서 사용되는 컨테이너가 다른 경우가 있습니다. 예를 들어 자바스크립트 프로젝트의 경우 npm run dev로 어플리케이션을 실행하는 방식으로 도커를 실행할 수 있지만 프로덕션에서는 npm run build의 결과물을 웹서버가 실행하는 방식으로 진행되어서 개발용 도커파일과 운영용 도커파일이 달라질 수 있습니다.

마지막으로 운영환경의 도커파일 개발환경 단계에서 사용하는 방법입니다. 다시 말해서 웹서버/WSGI를 갖춘 도커를 개발단계에서 부터 사용하는 것입니다. 운영환경과 가장 유사한 환경에서 개발을 하기 때문에 개발자 역시 프로덕션에 대한 이해도가 생길 수 있고 빌드 후에 생기는 문제에 대해서도 개발단계에서 직접 확인할 수 있습니다. 그러나 이 방법의 가장 큰 단점은 소스코드 변경시 빌드를 다시 실행하고 도커로 실행하기까지 시간이 오래 걸린다는 점이지만 이 단점을 '자동화' 방법으로 어느 정도 극복할 수 있는 방법을 소개합니다.

Gaze - 파일 저장할 때마다 명령 실행하기

자동화에 사용할 오픈소스는 Gaze입니다. Star 수는 많지 않지만 GeekNews에서 소개 되었었고 특정 언어나 도구에 종속되지 않고 감시하는 파일을 설정하고 실행하려는 명령어를 자유롭게 지정할 수 있습니다.

gaze를 설치하고 gaze *.txt -c "echo {{file}}"으로 실행할 경우 해당 폴더에 변화가 생긴 텍스트 파일명을 echo로 확인할 수 있습니다.

켠김에 빌드까지: docker와 gaze로 구성하는 자동화된 개발환경

2021/11/04

♾️

DevOps

넷플릭스

넷플릭스를 모르는 사람은 없을 것이다. 넷플릭스는 전 세계 190개국 이상의, 2.1억 명의 회원을 보유한 스트리밍 엔터테인먼트 기업이다. 드라마 '하우스 오브 카드'로 상승세를 타기 시작하였고 한국에는 2016년 1월에 진출하였으며 최근에는 한국의 '오징어 게임'이 전 세계적으로 흥행을 하면서 큰 성과를 거두었다. ("Netflix and chil?라면 먹고 갈래?"이라는 표현이 유행할 정도면 이미 일상 속에 깊이 들어왔다고 볼 수 있다.)

소프트웨어 엔지니어의 관점에서 넷플릭스는 2018년 미국 기술직 근로자들이 뽑은 ‘가장 일하고 싶은 회사’ 1위, ‘직원이 가장 행복한 기업’ 2위를 기록하고 있다. 전 세계에 비디오를 끊김없이 스트리밍하기 위해서느 높은 수준의 기술이 요구되고 실제로 넷플릭스는 기존 Legacy 시스템을 MSA로 모두 전환하여 운영/개발상의 효율을 극대화한 사례로 평가받고 있다. 더불어 Netflix OSS라는 이름으로 오픈소스에도 기여하고 있으며 Spring 커뮤니티에서도 Netflix의 오픈소스를 적극적으로 통합한 결과 Spring Cloud Netflix가 탄생하였다.

'규칙없음'은 넷플릭스의 CEO인 리드 헤이스팅스와 인시아드 경영대 교수 에린 마이어가 대담하는 방식으로 넷플릭스의 경영 방식과 기업문화에 대해서 소개하는 책이다. 실제 전현직 직원을 인터뷰하며 분석하는 기법을 통해서 혁신을 이루어낸 넷플릭스의 원동력은 무엇인지를 보여주고 있다. 현CEO인 리드 헤이스팅스가 직접 집필에 참여했다는 점에서 넷플릭스를 홍보하려는 목적도 어느정도 보이지만 세계적인 IT기업 FAA'N'G의 N이 어떻게 일하고 있는지 간접적으로 체험할 수 있다는 점에서 의의가 있고 내용 자체도 어렵지 않으니 시간이 된다면 직접 읽거나 서평을 읽어보는 것을 추천한다.

(오징어 게임... 아니... 넷플릭스에 오신 여러분을 환영합니다.)

책의 구성

규칙 없음: 넷플릭스, 지구상 가장 빠르고 유연한 기업의 비밀 (No Rules Rules: Netflix and the Culture of Reinvention)

2021/10/21

🧑‍🤝‍🧑

Startup/Culture

원문: Five Ansible Techniques I Wish I’d Known Earlier

Ansible Playbook에서 수많은 task를 테스트할 때마다 많은 시간을 들이고 있다면 이 글은 당신에게 도움이 될 것입니다.

Ansible을 활용하여 디버깅하는 것은 때때로 지루하고 그 과정이 모호할 수 있습니다. (예를 들어 내가 사용하려는 변수는 어떤 것으로부터 값을 추출하여 배열로 만들어서 찾아야하는지 같은 상황이 여기에 해당합니다.) 그래서 저는 이 과정을 빠르게 할 수 있는 방법과 동작하는 내부에서는 어떠한 일들이 일어나고 있는지 이해할 수 있는 방법을 찾기 시작했습니다.

결과적으로는 다음과 같이 도움을 줄 수 있는 5가지 도구 혹은 테크닉을 찾았고 이를 공유합니다.

이 팁들은 사용하기 쉬운 것에서 어려운 것 순으로 나열되어 있습니다.

1) --step 옵션

가장 쉽게 적용하고 따라할 수 있는 테크닉입니다. --step 옵션을 ansible-playbook 명령어에 추가하면 다음과 같은 명령 프롬프트가 나타납니다.

[번역] 미리 알았으면 좋을 Ansible 테크닉들

2021/09/09

♾️

DevOps

 이 글은 오픈소스 기여 활동을 폄하하거나 희화화하려는 목적이 아니라 오픈소스 기여 활동에 좀 더 쉽게 다가갈 수 있도록 그 과정을 단순화하여 작성한 글입니다.

오픈소스 생태계와 기여

우리는 현재 오픈소스의 혜택을 받는 시대에 살고 있습니다. 소프트웨어 개발 경력이 쌓일수록 그리고 오픈소스 생태계와 가까워질수록 자주 듣거나 하는 말이 있이 있습니다.

오픈소스에 기여하자. (유튜브 시작하자.)

물론 사람마다 오픈소스에 기여하려는 이유는 다양합니다.

실력을 향상시키거나 평판/경력을 키울 목적으로 할 수도 있고 다른 사람들과 교류하기 위해서 참여할 수 있습니다.

아니면 단순히 개발이 즐겁고 오픈소스 세계가 흥미로워서 기여하는 사람도 있습니다.

그 동기가 무엇이 되었든 오픈소스 생태계 발전에 기여한다는 것은 매우 칭찬 받을 일이자 개인의 발전에도 도움이 되는 활동입니다.

야, 너두 오픈소스 기여할 수 있어 (feat. 야나두)

2021/08/12

🧑‍💻

Programming

Docker? Container?

Docker Engine? Docker CLI?

책의 구성

Byungwoo의 블로그

Hello

바로가기

Recents Postings

Docker Desktop 유료화

DevOps & 커리어

블로그 포스팅 스터디 6기

EC2 (Elastic Compute Cloud)

장점

도커로 구성하는 개발환경과 운영환경

Gaze - 파일 저장할 때마다 명령 실행하기

넷플릭스

DevOps

블로그 포스팅 스터디 5기

애자일 스터디

1) --step 옵션

0. 오프닝

1. MLOps가 뭐길래

ML 생애주기

오픈소스 생태계와 기여

1. 클러스터와 노드의 의미