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 Engine은 데몬 형태로 실행하는 컨테이너 엔진 그 자체이고 Docker CLI는 우리가 사용하는 docker 명령어 인터페이스이다. 보통 Docker Engine을 설치할 때 Docker CLI를 같이 설치하기 때문에 우리는 Docker CLI의 존재를 모르고 Docker를 설치했다고 통칭해서 이야기한다.

예를 들어 CentOS에 Docker를 설치할 때 sudo yum install docker-ce docker-ce-cli containerd.io 명령어로 설치를 진행하는데 여기서 docker-ce가 Docker Engine에 해당하고 docker-ce-cli가 Docker CLI에 해당한다.

(참고로 Docker Engine의 경우 Community Edition(CE)과 Enterprise Editoin(EE)이 있는데 Docker Engine CE만 무료이며 여기서는 Docker Engine CE에 대해서만 다루도록 하겠다.)

그리고 아마도 다들 한번 쯤은 docker ps를 쳤을 때 다음과 같은 메세지를 본 적이 있을 것이다.

Is the docker daemon running? 메세지가 말해주듯이 docker 명령어를 연결하여 사용할 Docker Engine이 꺼져있거나 설치되지 않았음을 나타낸다. 다시 말해서 Docker CLI는 준비되었으나 Docker Engine은 준비되지 않았다는 뜻이다.

Docker Desktop?

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를 활용하여 개인 블로그를 만들고 포스팅한 글들도 모두 옮겼다. 물론 사랑하는 아내님의 도움과 함께 아내님의 블로그를 참고하였기에 단기간에 가능한 결과물이었던 것 같다. 앞으로는 개인 블로그에 작성한 글과 공부한 내용 그리고 나의 이력사항을 지속적으로 업데이트할 예정이다.

오픈소스 컨트리뷰톤

Exporterhub.io 프로젝트로 오픈소스에 컨트리뷰톤에 참가하였고 얼떨결에 리드멘티가 되었으나 참여한 프로젝트가 상위 15등끼리 겨루는 본선(?)에 오르지 못해서 안타깝게 수료증만 받고 10월에 종료하였다. 마지막 회식때 알게 되었는데 멘토님들도 프로젝트 막바지에 이직을 하시느라 정신이 없어서 많이 챙겨주지 못해주셔서 미안하다고 하셨다. 아쉽게 수료한 상태로 끝나긴 했지만 함께 프로젝트에 참여했던 멘티 동료의 추천을 통해서 면접을 보게 되었고 그 결과 이직에 성공했는데 이 정도면 엄청난 성과를 얻은 것 같다.

2021 4/4분기 회고

2021/12/23

🏃

Personal

EC2 (Elastic Compute Cloud)

•

클라우드에서 안전하고 규모 조정이 가능한 컴퓨팅 파워를 제공하는 웹 서비스

•

개발자가 보다 쉽게 웹 규모 컴퓨팅 작업을 할 수 있도록 설계

•

새로운 서버 인스턴스를 획득하고 부팅하는 데 필요한 시간을 단 몇 분으로 단축하므로 컴퓨팅 요구 사항의 변화에 따라 신속하게 용량을 확장하거나 축소 가능

•

실제 사용한 만큼만 요금을 지불하면 되므로, 컴퓨팅 비용이 절약

•

개발자와 시스템 관리자에게 오류 발생시 복원력이 뛰어난 애플리케이션을 구축하고 일반적인 장애 상황으로부터 분리하는 도구 제공

장점

•

탄력적인 웹 규모 컴퓨팅

•

완전 제어

•

유연한 클라우드 호스팅 서비스

•

통합: 대부분의 AWS 서비스와 통합되어 있어 다양한 어플리케이션에 걸쳐 컴퓨팅, 쿼리 처리 및 클라우드 스토리지를 제공

•

안정성

•

보안: Amazon VPC 함께 작동하여 사용자 컴퓨팅 리소스에 보안성 및 강력한 네트워킹 기능을 제공

•

저렴한 비용

S3 (Simple Storage Service)

AWS 주요제품요약

2021/12/17

♾️

DevOps

Infrastructure

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

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

개발하고 배포하는 이미지를 만드는 과정은 보통 다음과 같은 세 가지 형태를 띕니다. 첫번째는 도커 없이 개발을 완료한 후에 도커파일로 빌드한 후에 이미지를 푸쉬하는 방식입니다. 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로 확인할 수 있습니다.

gaze로 변경된 파일을 직접 실행할 수도 있습니다.

python flask 프로젝트 구성

python flask로 웹서비스를 개발한다고 가정하고 다음과 같이 간단하게 프로젝트를 구성합니다.

켠김에 빌드까지: 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이 어떻게 일하고 있는지 간접적으로 체험할 수 있다는 점에서 의의가 있고 내용 자체도 어렵지 않으니 시간이 된다면 직접 읽거나 서평을 읽어보는 것을 추천한다.

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

책의 구성

이 책의 구성은 총 4부로 이루어져 있다. 위의 그림에 나오는 좌측에서 우측으로 3단계가 1-3부에 해당하며 상단에서 하단으로 3개의 핵심 가치로 구성되어 있다. 마지막 4부는 넷플릭스가 전 세계에 진출하면서 그 문화를 정착시키면서 겪었던 경험을 컬쳐맵으로 표현하면서 마무리한다.

핵심가치와 문화

1. 인재밀도와 키퍼 테스트

넷플릭스는 2001년 경영이 어려워지면서 전체 직원 120명 중 40명을 정리해고 했다. 정리해고 과정을 거쳤기 때문에 회사의 분위기가 암울할 것이라는 예상과는 달리 오히려 직원들의 분위기와 열정/집중력이 높아졌다고 한다. 다시 말해서 '인재밀도'가 높아진 것이다. 이 경험을 통해 넷플릭스는 평범한 10명 보다는 뛰어난 1명의 인재를 데리고 있는 것이 더 성과에 좋다는 것을 알게 되었으며 뛰어난 인재를 보유하는 것이 곧 뛰어난 인재를 유치하는 최고의 방법이라는 것을 알게 되었다. 최고의 복지는 동료입니다. 뛰어난 인재가 여러명의 평범한 직원을 고용해서 평균적인 연봉을 주는 것보다 더 이득이라고 판단하기 때문에 넷플릭스 직원들은 업계 최고의 연봉으로 대우를 받는다. (평균 연봉 3억 7천만 원?)

넷플릭스는 오히려 평범한 사람이 팀의 성과를 떨어뜨린다고 경계하였고 그 이유는 다음과 같았다.

•

매니저의 기운을 빼 최고의 성과를 내지 못하게 만든다.

•

그룹 토의의 질을 떨어뜨려 팀의 전반적인 IQ를 낮춘다.

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

2021/10/21

🧑‍🤝‍🧑

Startup/Culture

그로스해킹

•

오늘도 개발자가 안된다고 말했다.

•

크래프톤 웨이

•

현재는 '사용자 스토리맵 만들기'를 읽고 있다. 조직문화/서비스기획/애자일에 관한 스터디는 이 책을 마지막으로하고 당분간 기술 공부에 전념하기 위해서 쉴 계획이다.

사이드 프로젝트

업무도 바쁘고 스터디와 다른 활동들로 바쁘다 보니 2/4 분기에 시작했던 사이드 프로젝트는 중단하기로 하였다.

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

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

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

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

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

1) --step 옵션

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

각 태스크마다 태스크를 실행할지(yes), 실행하지 않을지(no, 기본값), 혹은 현재부터 나머지 모두 실행할지(continue)를 선택할 수 있습니다.

나머지 태스크를 모두 yes로 실행하고 싶을 때 continue 옵션은 유용합니다. 참고로 continue를 선택하면 해당 play의 나머지 태스크를 실행하는 것이지 playbook의 나머지 태스크를 실행하는 것은 아닙니다.

(역주: ansible의 구성요소는 playbook > play > task 층위를 가집니다. 예를 들어 nginx를 설치하는 play에 이어서 nginx를 실행하는 play를 하나의 playbook에 넣었을 경우 continue를 선택한 task가 속한 play가 nginx 설치일 겨우 nginx 실행하는 play 실행하기 전까지만 실행합니다.)

엔터키를 눌러서 yes를 손쉽게 입력할 수 있으나 태스크가 많을 경우 본인이 확인하려는 태스크를 지나칠 수도 있으니 주의해야 합니다.

개인적인 생각으로는 ansible이 오픈소스 프로젝트이므로 back, skip 기능을 누군가 추가해주면 좋겠습니다.

2) 인라인 로깅

고전적인 형식의(old-fashioned) 로그를 표시하여 변수를 손쉽게 확인하는 방법도 있습니다. 다음의 코드는 호스트 변수들을 json 형태로 가독성 있게 출력합니다.

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

2021/09/09

♾️

DevOps

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

오픈소스 생태계와 기여

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

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

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

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

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

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

오픈소스 기여의 장벽

'오픈소스 기여'라고 검색하면 다음과 같은 결과가 나옵니다.

좋았어! 시작해보자...

일단 오픈소스 기여를 위해서 필요한 사전지식과 기여할 수 있는 방법들이 검색 결과로 나옵니다.

일단 git을 공부해야 한다고 나오고 github에서 가장 많은 오픈소스 프로젝트가 진행되고 있으니 github에 익숙해져야 한다고 나옵니다.

그리고 웬만한 오픈소스들은 영어로 되어 있으니 영어 공부를 하면 됩니다... 하아...

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

2021/08/12

🧑‍💻

Programming

기초부터 다지는 ElasticSearch 운영 노하우 3장을 읽고 요약하였습니다.

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

•

클러스터와 노드

•

3개 이상의 노드로 구성해야 고가용성(High Availability)를 보장받을 수 있음

•

각 노드는 하나 이상의 역할을 가질 수 있음

•

이외에도 여러가지 역할 이 있지만 검색엔진과 관련이 있는 기본적인 역할만 나열

2. 인덱스와 타입

•

Elasticsearch와 RDBMS 비교

3. 샤드와 세그먼트

•

샤드와 세그먼트의 관계

•

샤드: 인덱스에 색인되는 문서들이 저장되는 '논리적'인 공간

•

세그먼트: 샤드의 데이터들을 가지고 있는 '물리적'인 파일

Elasticsearch를 구성하는 기본 개념

2021/07/28

Database

Docker? Container?

Docker Engine? Docker CLI?

Docker Desktop?

오픈소스 컨트리뷰톤

python flask 프로젝트 구성

책의 구성

핵심가치와 문화

1. 인재밀도와 키퍼 테스트

오픈소스 기여의 장벽

Byungwoo의 블로그

Hello

바로가기

Recents Postings

Docker Desktop 유료화

DevOps & 커리어

블로그 포스팅 스터디 6기

EC2 (Elastic Compute Cloud)

장점

S3 (Simple Storage Service)

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

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

넷플릭스

DevOps

블로그 포스팅 스터디 5기

애자일 스터디

사이드 프로젝트

1) --step 옵션

2) 인라인 로깅

0. 오프닝

1. MLOps가 뭐길래

ML 생애주기

MLOps의 2개의 축

Data Scientists

Data/Software Engineers

DevOps vs. MLOps

오픈소스 생태계와 기여

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

2. 인덱스와 타입

3. 샤드와 세그먼트