🐳 Docker study 1st

이번 포스팅부터 7주 동안 자율주행 개발자를 목표로 하는 팀원들과 함께 Docker에 대해 공부하고 블로그로 정리하려고 한다. 사실 Docker에 대해서는 컴퓨터를 전공하면서부터 여기저기서 많이 들었던 이름이다. 고래가 컨테이너 박스를 등에 엎고 있는 사진 아마 Docker 이름을 들어본 사람이라면 무슨 그림인지 쉽게 떠올릴 수 있을 것 같다. 실제로 먼저 현업에 나간 선배들의 말을 들어보면 Docker 애찬가도 있어서 배워두며 꽤 유용한 툴인건 확실하다. 하지만 현업의 세상을 모르는 나에게 여전히 Docker는 그저 고래일 뿐이다. 아무튼 이번 좋은 기회로 Docker에 대해 공부해보기로 했으니, 일단 시작해보려고 한다.

앞으로의 포스팅은 <Inflearn 실전도커: 도커로 나만의 딥러닝 클라우드 컴퓨터 만들기>를 공부하고 정리하는 방식으로 진행해보려고 한다. 오늘의 첫번째 포스팅에서는 도커가 왜 자율주행 개발자를 목표로 하는 나에게 필요한지, 도커가 대체 정확히 뭐하는 건지, 그리고 앞으로 자주 쓸 기본 명령어에 대해 간단히 이야기 해보고자 한다.

1. Docker might be essential if you want to work as an autonomous driving developer in the future!

#AI 개발 및 컨테이너화 트랜드 #자동 레이블링 파이프라인 #확장성

‘트랜드’라는 단어가 가장 많이 쓰이는 분야는 어디일까? 일단 나는 패션 산업이 가장 먼저 생각이 든다. 그런데 패션 산업 만큼 트랜드에 민감한 분야가 또 있다. 그건 바로 IT다.

지난 몇십년간 IT분야 만큼 빠르게 변화하는 시장은 찾기 어렵다. 내가 가고 싶어하는 자동차 산업 역시 마찬가지다. 이제 자동차는 단순히 그냥 네바퀴 달린 고철이 아닌지 오래다. 자율주행 소프트웨어 전문 스타트업 고스트 오토노미(Ghost Autonomy)가 ChatGPT LMM을 자율주행에 적용한다는 기사를 읽었다. 대다수의 전문가들은 자율주행에 LMM 적용이 시기상조라는 뜻에 의견을 모으는 것 같다. 하지만 말 그대로 정말 의견일 뿐이다. 여담이긴 하지만 일론머스크가 우주여행 사업을 시작한다고 했을 때 긍정적으로 바라본 사람보다 부정적적으로 바라본 사람이 더 많았다. 하지만 테슬라는 보란 듯이 우주진출을 성공했다.

다시 Docker로 돌아와서 이야기 하자면, 결론은 앞으로의 자동차는 AI가 기본 베이스로 탑재된 형태로 만들어질 것이라는 것이다. 여기서 계속 언급되는 Docker는 차량 AI 모델을 마치 모든 것을 담을 수 있는 상자처럼 컨테이너화시켜 개발자들이 다양한 모델과 아키텍처를 실험할 수 있게 해주는 도구로 이해해보는 것도 좋을 것 같다. 첫번째 키워드는 ‘AI 개발 및 컨테이너화 트랜드’이다.

특히 NVIDIA는 ‘자동 레이블링 파이프라인의 효율성’ 측면에서 Docker가 자율주행 차량의 AI 모델 학습을 최적화하는 데 어떻게 사용되는지 설명하고 있다. 정리하면, 자율주행 시스템은 방대한 양의 데이터를 처리해야 하는데, 이때 데이터를 레이블링하고 모델을 배포하는 과정에서 시간이 많이 소요될 수 있다. 하지만 Docker를 사용하면 이러한 과정을 컨테이너화하여 오버헤드(불필요한 시스템 자원 소모)를 줄일 수 있고, 처리 속도를 크게 향상시킬 수 있다.

예를 들어, 자율주행 차량의 센서에서 수집된 데이터를 레이블링하고, 그 데이터를 AI 모델에 전달해 학습시키는 과정은 매우 복잡하다. 하지만 Docker 컨테이너를 사용하면 동일한 환경에서 일관된 작업을 실행할 수 있어, 작업 속도와 효율성을 높일 수 있을 것이다. 즉, 컨테이너 안에서 모든 모델과 데이터를 처리하니, 별도의 환경 설정이나 복잡한 시스템 조정 없이 빠르고 일관된 성능을 제공하는 것이다.

앞서 자율주행 차량의 센서 데이터를 언급했는데,대표적으로 LiDAR, 레이더, 카메라 등이 있다. 이 세가지 센서의 데이터는 우리가 알고 있듯이 서로 다른 형식과 속성을 가지고 있다. 여기서 Docker의 ‘확장성과 배포’특징이 빛을 낸다.

예를 들어, LiDAR 데이터를 처리하는 컨테이너, 카메라 데이터를 처리하는 컨테이너, 그리고 레이더 데이터를 처리하는 컨테이너를 각각 독립적으로 운영할 수 있다. 각 센서 데이터마다 다른 방식으로 처리가 이루어지더라도, Docker는 그 모든 작업이 동일한 환경에서 실행되도록 보장한다. 이렇게 되면 개발자들이 각각의 데이터를 따로 관리할 필요가 없고, 데이터 간 충돌이나 환경 설정 문제를 최소화할 수 있다.

뿐만 아니라, Docker를 통해 이러한 데이터를 병렬로 처리할 수 있어 처리 속도도 크게 향상된다. 기존의 물리적 환경에서는 각 센서 데이터를 따로 처리해야 했기 때문에, 데이터 처리 속도가 느려지고 오류 발생 확률도 높았다. 하지만 Docker는 이러한 문제를 해결하고, 확장성과 유연성을 제공함으로써 자율주행 시스템의 효율성을 크게 높여준다.

잠깐 살펴본거지만 Docker는 분명 기특한 고래가 맞다. 지금 언급한 AI 컨테이너화 트랜드, 자동 레이블링 파이프라인의 효율성, 확장성 이외에도 여러 장점이 있을 것이 분명하다. 이에 대해서는 직접 실습도 해보면서 차차 알아가보면 될 것 같다.

2. 10 Basic Docker Commands

Docker를 사용하며 자주 쓰는 명령어는 10개 정도 되는 것 같다. 처음 Git을 쓸 때, commit, pull, push와 같은 명령어 몇개를 배웠는데, 처음엔 대체 뭔소린가 했다. 그래도 그 덕분인지 처음 도커 명령어를 봤을 때 Git과 비슷하다는 느낌을 받았다. 아래는 대표적인 기본 명령어 10개다.

• docker pull
• docker build «- Dockerfile
• docker run
• docker images
• docker ps (-a)
• docker stop
• docker start
• docker exec -it /bin/bash
• docker rm
• docker rmi

명령어를 보면 ‘images’, ‘container’와 같은 단어가 보인다. 앞서 Git과 유사하다고 했는데, 아래와 같이 정리해봤다. 물론 실제로 완전히 Git과 Docker의 플로우가 똑같다는 건 절대 아니다. (이와 관련된 Docker 운영체제 이야기는 추후 포스팅 예정.) 내가 느끼기에 가상환경에서 작업한다는게 아래 그림처럼 느껴진다는 것이다. Docker에서의 ‘images’를 처음 접했을 때는 무슨 사진을 가져온다는 건가? 라고 처음 이해했다. 알고보니 images는 약간 붕어빵🐟🍞 틀? 같은 거란다. 그럼 ‘container’은 또 무엇인지 궁금해졌다. 대답은 성수, 홍대 라고 한다. (환장..)

처음엔 붕어빵 뭔소린가 할 수 있지만, 결론은 내가 python처럼 원하는 소스를 images로서 Docker Registory에서 당겨올 수 있고(pull), 내 로컬이 아닌 ‘container’라는 가상 환경(Docker daemon)에서 사용할 수 있다는 것으로 일단 이해하고 넘어가도록 하자.

3. Try Using the Basic Commands

붕어빵을 기억하며 직접 실습도 해봤다.

💻 $ docker ps

💻 $ docker ps -a

나의 로컬에 돌아가고 있는 붕어빵들을 볼 수 있는 명령어다. ‘nginx’라는 붕어빵 틀이 ‘reverent_beaver’이라는 곳에서 장사를 하고 있다고 이해하면 된다.

💻 $ docker images

내가 가진 전체 붕어빵 틀을 확인하는 명령어로 총 6개의 images를 확인할 수 있다.

💻 $ docker pull <images name>

위에서 확인했듯이 나는 현재 ‘python’이라는 이름의 붕어빵 틀이 없는 상태다. ‘python’이라는 이름의 붕어빵 틀을 원한다면 Docker registory에서 가져오면 된다. 정상적으로 진행되면 아래와 같이 이전엔 없었던 ‘python’ images가 생성됨을 확인할 수 있다.

💻 $ docker run -it —name <container name> <images>

💻 $ docker exec -it <container name> <images>

붕어빵 틀을 가져왔다면 한번 사용해봐야할 것이다. 붕어빵 틀에 ‘python-container’이라는 이름을 정해주고 실행시켜 보면 실제로 잘 작동하는 것을 확인할 수 있다. 일단 만들어 놓은 붕어빵 틀은 ‘exec’ 명령어로 실행 가능하다.

💻 $ docker stop <container name>

💻 $ docker rm <container name>

💻 $ docker rmi <image name>

필요없는 붕어빵 틀(images)이 새길 수도 있다. 그럴 때는 삭제하면 된다. 주의할 점은 바로 python이라는 이름의 붕어빵 틀을 삭제할 수 없다는 것이다. 필자 역시 이 부분이 한번에 이해가 되지는 않았었다. 결론은 먼저 삭제하고자 하는 container를 중지(stop)한 후 삭제해야 하고, 이후 붕어빵 틀(images) 삭제가 가능하다.

지금까지의 글로 1주차 Docker스터디를 정리해보았다. Docker가 익숙한 개발자라면 붕어빵만 외치는 지금 나의 글이 꽤 유치하다고 할 수도 있다. 아무렴 나는 Docker가 고래 그 이상이 된지 1주차 된 개발자다. 사실 이해가 된 부분도 있는가 하면 완벽히 이해가 되지 않은 부분도 있다. 다음 포스팅에서는 Azure에서 우분투 가상 머신을 구축하는 실습 내용을 이어서 정리해본다면 지금보다는 더 Docker를 이해할 수 있지 않을까 싶다!

Reference

• Docker_cheatsheet