spacectl이란?

소개

spacectl 은 저희팀이 개발하는 서비스인 SpaceONE의 gRPC API request를 CLI로 손쉽게 수행할 수 있도록 해주는 도구입니다. 파이썬을 통해 개발했고 Click 이라는 모듈로 CLI 환경을 손쉽게 사용할 수 있었고, Jinja2를 통해 상세한 Manifest 들에서 변수 치환, 분기 등을 수행할 수 있었습니다.

사용 예시

A simple example

간단하게 spacectl이 어떤 식으로 이용되는 도구인지 예시를 보여드리겠습니다. 아래의 커맨드를 이용해 손쉽게 SpaceONE의 다양한 마이크로서비스들의 API를 이용할 수 있습니다.

$ spacectl list domain
 domain_id           | name   | state   | plugin_id  ...
 domain-abc123abc    | umi0410| ENABLED |            ...
$ spacectl list server -p domain_id=domain-abc123abc
 server_id         | name    | provider ...
 server-abc123abc  | foo     | aws ...

apply command

spacectl apply command는 kubectl의 apply와 유사하게 없으면 만들고, 있으면 업데이트하고 혹은 단순히 어떤 API를 Execute하는 Task들의 플로우를 관리해주는 커맨드 입니다.

아쉽게도 퇴사 전에 마무리를 짓지는 못했습니다. ㅜ.ㅜ 퇴사 전까지 진행한 작업은 일부 리소스에 대한 CRU(create, read, update), 대부분의 리소스에 대한 Excute(execute할 API를 설정)까지입니다.

# main.yaml
import:
  - mongo.yaml # 개별 yaml file에서는 terraform/ansible과 같이 수행할 Task들을 정의
  - root_domain.yaml
  - repository.yaml

var:
  domain_name: root
  domain_owner: admin
  admin_username: admin
  admin_password: admin

$ spacectl apply main.yaml

설계를 하며 느낀 점

이 프로젝트에 대한 실제 개발 업무 이전에는 꽤나 설계 업무가 많았습니다. 저는 그 동안은 혼자 주로 개발을 해왔고, 실행력 좋게 시작은 하지만 설계는 충분하지 않은 채 성급하게 실행에 옮겼던 경험이 많습니다. 또한 학생이었고, 개발 경력이 길지 않았기에 사실상 “개발 = 그때 그때 새로운 내용 공부"와 같은 느낌이었기에 애초에 설계를 하려해도 ‘뭐가 필요하고 뭐가 가능할 것이고 뭐가 힘들 것인가’ 를 판단하기 어려웠습니다.

하지만 팀원들과 함께 개발하면서 밥 먹을 때, 회의 할 때 틈틈히 설계 방식과 요령에 대해 상의했고, 처음으로 설계를 어느 정도 굳힌 뒤 개발에 들어들어갔던 경험이었습니다.

인턴 기간 막바지에 이 설계에 참여하게 된 것은 정말 값진 경험이었다고 생각했습니다. 사실 단순히 데브옵스로서 일할 때는 남들과 의사소통할 일이 그리 많진 않았는데, 이 설계를 맡게 되면서 많은 회의와 대화를 하게되었습니다. 선배 개발자분들과 설계에 대해 잦은 회의를 하면서 제가 어떤 개발자가 되고싶은지 직접 느낄 수 있었던 것 같습니다. 그 배경에는 두 가지 충격이 있었습니다.

1. ‘내가 남의 생각을 잘 읽는 편은 아니었나보군…?’
2. ‘선배 개발자분은 내가 개판으로 설명해도 어떻게 귀신같이 나보다 내 생각을 잘 읽으시지?’ => 마치 축구할 때 노련한 축구선수와 함께 뛰면서 저 행동을 귀신같이 예측하고서는 너무나도 잘 밀어주는 느낌을 받았습니다…

제가 평소에 말을 잘하는 편이라고 생각했는데, 남의 생각을 이해하고 읽어내는 능력은 그리 뛰어나지많은 않구나라는 생각을 하게됐습니다. 설계 내용이 꽤나 추상적으로 구두로 진행되었기에 그랬을 수도 있겠지만, 큰 충격은 선배 개발자분의 노련함이었습니다.

후에 누군가 어떤 개발자가 되고싶냐, 협업할 때 어떤 노하우가 있느냐 이런 내용을 물어보면 자신있게 남의 생각을 잘 이해하고, 알아주는 사람과 관련해 대답할 수 있는 사람이 될 수 있었으면 좋겠습니다.

또한 설계 깊게 진행하기 전에 침착하게 자료 조사를 잘 해야한다는 것을 느꼈습니다.

하나 일화로 원래는 설정 파일에서 ${{ tasks.umi0410.output }} 이런 식의 변수를 이용한 설정을 치환한 뒤 API를 수행해야할 때, 아마 template 언어들을 제가 원하는 대로 사용하기 힘들 것이라 생각하고, 하나하나 함수와 클래스를 만들어가곤했는데, 개발이 거의 완료되어갈쯤 Jinja2의 사용법을 다시 읽다보니 spacectl에 Jinja2를 적절히 사용할 수 있을 것 같았고, 정신이 번뜩 들어 몇 시간만에 수작업으로 짠 코드들을 덜어내고 Jinja2를 이용해 좀 더 깔끔하게 변수 치환 및 추가로 Jinja2의 built-in filter들을 이용할 수 있었습니다!

개발하면서 느낀 점

역시 개발은 남이 만든 패키지를 잘 사용해야한다는 것을 느꼈고, 그냥 복사 붙여넣기만 잘하면 된다는 의미가 아니라, 그런 것들을 빠르게 가져와서 적용시키고 부분 부분 커스터마이징하기 위해서는 기본기가 탄탄해야한다고 느꼈습니다. 물론 수작업으로 만드는 것도 좋을 수 있겠지만, 다양한 엣지케이스가 존재할 수 있고, 그 모든 작업들을 문서로 상세히 설명하는 것이 아니라면, 제작자인 제가 아닌 누군가가 그 기능을 이용하기는 힘들 것입니다. Jinja2를 이용한 템플릿 기능 제공이 이와 관련된 경험이 될 수 있겠습니다.

또한 남의 코드를 자세히 읽어보는 게 처음이었는데, 덕분에 파이썬 프로젝트를 수행할 때 어떤 식으로 디렉토리 스트럭쳐를 짜면 좋을 지 생각해볼 수 있었던 계기였던 것 같습니다. 제가 설계하고, 개발한 내용을 짧게나마 발표한 뒤 리뷰를 받고 수정을 하면 한층 더 코드의 구조와 사용이 간결하고 직관적으로 보인다는 느낌을 받을 수 있었습니다. 이렇게 다양한 가르침을 주신 저희 팀의 선배 개발자분들께 항상 감사드립니다.

Megazone CloudOne 팀의 DevOps 인턴으로서 근무했던 내용에 대한 후기가 거의 끝났습니다. 끝으로 인턴 활동에 대한 종합적인 느낀점을 이어서 보시거나 다시 목차를 보고싶으신 분은 여기를 클릭해주세요.