한빛출판네트워크

 

 

아는 것을 말하는 것과 글로 쓰는 것은 다르다. 말은 청자와 대면하기에 화자의 말 외에도 표정, 손짓, 목소리 등으르도 의미를 전달하지만, 글은 그런 부차적인 요소가 없다. 오직 글로만 하고자 하는 말을 전한다. 말은 한 번 내뱉으면 주워 담을 수 없지만, 글은 그렇지 않다. 의미에 맡게, 더 나은 표현으로 수정하기를 끝없이 반복한다. 글은 정해진 끝이 없다. 그래서 흔히 고통에 비유되곤 한다. 

 

우여명 개발자도 AWSKRUG 컨테이너 핸즈온 2018의 발표의 내용을 글로 옮긴 두 달의 시간이‘고통’이었다고 말한다. 그간 무심코 읽어온 책의 저자가 존경스럽기까지 하다고. 그는 AWSKRUG의 컨테이너 소모임의 운영자로, 최근 AWSKRUG 컨테이너 핸즈온의 발표 경험을 글로 공유했다.

 

우여명 AWSKRUG 컨테이너 소모임 운영자 아이스크림에듀 소프트웨어 개발자다. 신림동 프로그래머, 엑스퍼란 개발자 모임에서 활동했고, 최근에는 AWSKRUG 컨테이너 소모임을 만들고 운영자로 활동하고 있다. 서버 사이드 앱 및 프론트엔드 개발, AWS 인프라 등 폭넓은 경험을 쌓았다.

 

 

Q. 백엔드 개발자라 들었다.

백엔드 외에도 프론트엔드도 개발하고 AWS 인프라도 다뤄봤다. 흔히 풀스택 개발자라는 말을 하는 데 난 그 말이 맞지 않다고 본다. ‘개발자’라고 불러줬으면 한다. 내 주력 언어는 자바다. AWSKRUG의 컨테이너 소모임을 운영하고 있다.

 

 

Q. AWSKRUG 컨테이너 소모임은 어떤 모임이고 어떤 활동을 하는가

올해 봄으로 기억한다. 아마 3~4월일 것이다. AWSKRUG 커뮤니티에서 처음 참여한 것은 아키텍처 소모임이었다. 오프라인 소모임 외에도 슬랙(Slack)에서 활동하다가 우연히 컨테이너 소모임이 없는 것을 알게 됐다. 있을 법도 한데 없는 게 의아했다. 호기롭게 컨테이너 모임을 운영해 보겠다고 손을 들었고, 실제로 운영을 하게 됐다. AWSKRUG 커뮤니티 활동 전에는‘신림동 프로그래머’란 지역 기반 커뮤니티와 엑스퍼란 모임에 참여했었다.

 

AWSKRUG 컨테이너 소모임을 만들 당시 난 도커를 한참 빠져있었다. 전 직장에서 AWS를 써서 평소 관심이 많았었다. 첫 직장에서는 오직 개발만 해서 운영과 배포는 별다른 신경을 쓰지 않았다. 두 번째 직장(전 직장)에서는 실제로 AWS 인프라까지 다뤄야 해 이때부터 자연스레 운영과 배포에도 관심을 가지게 됐다. 운영과 배포에 궁금증이 커져가던 차에 컨테이너 소모임 운영하게 됐다. AWS 인프라를 제대로 배울 수 있는 기회라 생각에서였다. 실제로 소모임 활동을 통해서 AWS에 대해서 많이 배울 수 있었다. 컨테이너 소모임은 올해 막 시작됐기에 아직은 참여자가 많지 않다. 이번 인터뷰로 컨테이너 소모임이 더 많이 알려지고 참석해줬으면 하는 바람이다.

 

엘라스틱 컨테이너 서비스(ECS) : AWS의 컨테이너 관리 서비스다. 코드 빌드 : AWS의 빌드 툴이다. 지정된 소스 코드 가져와 빌드와 테스팅 수행한다. 코드 파이프라인 : AWS의 통합 빌드 환경이다. 소스를 가져와 어떤 툴로 빌드하고 어떤 툴로 배포할지 전체 플로우를 관리한다.

 

어렵지 않다. 페이스북의 AWSKRUG 그룹에 가입하면 된다. AWSKRUG의 슬랙에도 가입하면 소통하며 더 많은 정보를 얻을 수 있다. AWSKRUG 소모임은 페이스북 그룹과 슬랙을 통해 공지한다. 관심 있는 주제의 소모임은 밋업(Meetup)을 통해 참가할 수 있다.

단순히 발표를 듣기보다는 발표가 끝난 뒤 있는 뒷풀이 모임에 참석하기 바란다. 발표자에게 더 많이 질문하고 많은 사람과 얘기를 나누는 과정에서 더 많은 것을 얻을 수 있기 때문이다. 이것이 가장 좋은 커뮤니티 활동 방법이라고 생각한다.

 

AWSKRUG 컨테이너 소모임은 이름 그대로 컨테이너에 대한 정보를 교류한다. 컨테이너라고 하면 도커뿐 아니라 AWS 도커 기반의 엘라스틱 컨테이너 서비스(ECS, Elastic Container service), 엘라스틱 컨테이너 서비스 포 쿠버네티스(EKS, Elastic Container Service for kubernetes) 등이다. 기술뿐 아니라 운영에 대해서도 얘기를 나눈다. 아직은 참여자가 적어 질문이 많고 모임의 분위기도 활기차다.

주위를 둘러봐도 많은 회사가 컨테이너 기술을 활용하고 있다. 도커 커뮤니티도 매우 활성화되어 있다. 꼭 AWS 관련 컨테이너 기술이 아니더라도 그런 경험을 가진 분들이 AWSKRUG 컨테이너 소모임에 놀러와 자신의 경험을 얘기해주면 좋겠다.

 

▲ AWSKRUG 회원들

 

Q. 소모임에서 어떤 이야기를 나누는가?

아무래도 AWS의 ECS 이야기가 가장 많다. 내가 ECS에 관심이 많은 탓일지도 모르지만. (웃음) 쿠버네티스 얘기도 빼놓을 수 없다. 도커로 이미지를 어떻게 만드는 게 효과적인지, 도커 기반 컨테이너로 분산된 환경에서 어떻게 메트릭(Matrix)을 수집해야 할지 등 다양한 얘기가 가감 없이 오가고 있다.

 

 

Q. 커뮤니티 활동이 어떤 도움이 되는가?

얻는 게 정말 많다. 가장 큰 것은 ‘키워드’라고 생각한다. 다양한 분들과 얘기하다 보면 키워드라는 힌트를 얻어갈 때가 많다. 예컨대 지표 수집이 요즘의 고민이라 치자. 관련 이야기를 하다가 누군가가 인플럭스 DB를 쓴다 얘기해줬다. 인플럭스 DB란 키워드 하나를 얻어 관련 내용을 살피고 공부하며 때론 업무에 적용하기도 하며 찾는 정답에 한걸음 더 다가갈 때가 많다. 이런 게 굉장히 좋은 커뮤니티의 역할이고 선순환이라고 본다.

이런 키워드는 쉽게 나오는 게 아니다. 경험이 없다면 함부로 다른 이에게 얘기할 수 없다. 정말 많은 ‘삽질(?)’을 한 뒤에 자신의 경험을 얘기해주기 때문에 정말 큰 도움이 된다.

 

 

Q. AWSKRUG 컨테이너 핸즈온에서는 어떤 내용을 발표했나

AWS의 ECS로 서비스를 배포하는 내용을 발표했다. 배포 운영 시스템이나 엔지니어링 개념이 없는 SW 개발자가 서비스 배포를 자동화하거나, 도커 컨테이너를 좀 더 쉽게 배포하고자 할 때 도커 오케스트레이션 중 도커 스윔(Docker Swarm)을 가장 먼저 접하게 된다. 나도 그랬다. 그런데 사용이 쉽지 않더라. 그보다는 ECS가 더 쉬웠다. ECS와 AWS의 몇 가지 도구를 사용하면 더 쉽게 배포를 자동할 수 있었다. 이번 핸즈온에서는 그 경험을 정리해 공유했다.

쉽다 쉽다 말했지만 사실, 정작 구축하려면 입력값이 많아 난이도가 있는 편인데, 핸즈온에 참석한 이들 모두 잘 따라해줬다. 핸즈온에 나와 실습을 도와준 AWSKRUG 멤버의 도움이 컸다.

 

 ▲ 우여명 AWSKRUG 컨테이너 핸즈온 운영자

 

Q. AWS의 ECS, 코드 빌드, 코드 파이프라인의 강점은 무엇인가

CI/CD 도구로는 젠킨스(Jekins)와 트래비스(Travis CI)를 써봤다. 그중 트래비스는 개인 프로젝트에서 사용했었다. 그다음으로는 코드 빌드와 코드 파이프라인을 써봤다. 내 경험으로는 코드 빌드, 코드 파이프라인은 젠킨스, 트레비스와 콘셉트부터가 달랐다. 코드 빌드와 코드 파이프라인은 책임을 더 명확히 나눈 느낌이다. 예컨대 “A를 빌드한다.” 또는 “파이프라인을 구축한다.”와 같은 명확함이 가져오는 차이가 컸다.

 

젠킨스로도 파이프라인을 만들고 자동화 흐름을 구성할 수 있다. 그런데 젠킨스의 파이프라인은 코드 빌드와 배포가 잘 수행됐다 안 됐다 정도만 보여준다면, 코드 빌드와 파이프라인은 어느 시점에서 어떤 문제가 있는지를 더 상세히 알려준다. 물론 젠킨스도 디테일하게 설정하면 이런 부분까지 확인할 수 있다. 기능보다는 편의성에 차이가 있다는 얘기다.  또한 젠킨스는 저수준 작업이 많은 반면, 코드 빌드와 코드 파이프라인은 고수준의 작업으로 파이프라인을 조립할 수 있다. 한마디로 UI 환경에서 더 쉽게 파이프라인을 만들 수 있다.

 

이러한 개발 프로세스를 만드는 작업은 개발자의 역량이 크게 좌우하기 때문에 어느 게 더 좋다 말하기 어렵다. 젠킨스, 트래비스로도 충분히 훌륭한 파이프라인을 만들 수 있지만, 코드 빌드와 코드 파이프라인은 그 정도의 역량이 되지 않는 개발자도 일정 수준 이상의 파이프라인을 좀 더 쉽게 만들 수 있다. 이것이 큰 장점이라고 본다.

 

 

Q. CI/CD 많이 적용하는 요즘 추세인가?

배포까지는 자동화해도 파이프라인까지 구축하는 곳은 많지 않은 듯하다. 대부분은 자동화 테스트는 안 하고 빌드와 배포 정도만 구축한다. 요즘 화두는 ‘코드 리뷰’다. 코드 리뷰까지 포함한 브랜치 전략으로 파이프라인을 구축하는 얘기가 활발하다.

개인적으로 CI/CD는 넓은 의미의 단어고 우리가 하는 것은 배포 자동화라고 생각한다. 데브옵스에서 굉장히 작은 부분이다. CI/CD의 포인트는 검증과 테스트의 자동화다. 자동화된 검증과 테스트를 통해 코드가 배포될 수 있도록 규칙을 정립하고 적용하는 게 가장 중요하다고 생각한다.

 

  ▲ 우여명 AWSKRUG 컨테이너 핸즈온 운영자

 

 

Q. 발표 내용을 무료 전자책으로 배포했다. 어떤 내용을 담았는가?

핸즈온 발표 이후 구글 독스(Google Docs)에 그 내용을 기록했다. 그걸 다듬어 한빛미디어의 리얼타임 무료 Web Book으로도 출판했다.

간단히만 소개하면, ECS 웹 콘솔을 통해 수동으로 주어진 서비스에 대한 배포를 실습한다. 그다음  AWS의 CI/CD 도구인 코드 빌드와 코드 파이프라인으로 배포 자동화를 해본다. 코드 빌드는 이름 그대로 코드 자체를 아티팩트(Artifact)로 만들어주는 도구다. 코드 파이프라인은 CI/CD 과정 하나하나를 파이프라인에 순서대로 정의해 시각화하는 도구다. 

 

파이프라인 세팅은 간단한데, 파이프라인 구성대로 코드를 가져와 컴파일하고 도커 이미지를 만든 후 테스트하고 배포하는 전 과정을 파이프라인에서 설정하고 모니터링할 수 있다. AWS의 ECS를 사용하면 배포, 운영 관련 파이프라인을 정말 쉽게 자동화할 수 있다.

 

 

Q. 시간 내줘서 감사하다.

‘인싸’란 신조어가 있다. 인사이더(Insider)의 줄임말인데, 아웃사이더와 달리 잘 섞여 노는 사람을 의미한다. 난 ‘인싸’는 아니다. 수줍음이 많지만, 더 많은 사람이 나처럼 소모임에 참여하고 함께 지식을 나누었으면 한다.

 

전 직장을 퇴사하고 잠시 쉬는 기간에 핸즈온 발표를 글로 정리하려고 했었다. 한 달 해외여행 기간에서 일주일이면 다 쓰겠지 생각했는데 크나큰 오산이더라. 원고를 탈고하기까지 무려 두 달이나 걸렸다. 책을 쓴다는 게 심리적 저항도 크고 정말 고통스러운 작업임을 처음 알게 되었다. 그래서 이 자리를 빌어서 이 말을 꼭 하고 싶었다. 무심코 읽었던 책들의 저자들에게 존경한다고 꼭 말하고 싶다.

 

 

"AWSKRUG 컨테이너 핸즈온 #2의 내용은 『리얼타임 Web Book | 따라하며 배우는 아마존 ECS』에서 확인할 수 있다."

 

 

 

리얼타임 Web Book(https://realhanbit.co.kr)은 개발자 모두를 위한 IT 출판 서비스입니다. 블로그 연재가 모이면 전자책이, 세미나 발표를 글로 옮겨 전자책을 만들 수도 있습니다. 다양한 주제, 형식의 IT 종사자 여러분의 글을 기다리고 있습니다.