EMOCON 2015 F/W - Plate 에 대한 이야기

이상한모임 컨퍼런스, 일명 EMOCON 2015 F/W 에 1일차에 ‘카피캣으로 시작하는 오픈소스’ 라는 약을 팔았다. 올해의 목표중 하나가 컨퍼런스 발표였는데 난 아직도 대면은 어려운지라, 이상한 모임 덕분에 올해의 목표를 이룬것 같아서 기분이 좋다. 발표 동영상 자료는 유투브 링크에 가면 볼수가 있고, 다시 한번 이 글을 빌어서 이상한 모임에 감사드린다.

Plate 에 대한 글을 써야지 생각한게 몇 개월인데 쓰지 못하고 있었는데 이렇게 쓰게 되고, 발표 자료외에 질문에 대해서 제대로 답변을 드리지 못한점, 그리고 설명할때 제대로 설명하지 못한 부분에 대해서 몇가지 언급하고자 해서 글을 쓴다.

Plate 의 유래

– 위의 슬라이드에도 있듯이 회사에서 잠깐 API 문서화 관련 툴을 찾다가 Slate 라는 툴을 찾게 되었고, Ruby 기반이다 보니 파이썬으로 변경해보자는 생각에 변환하게 된것이 발단이 되었다. 그리고 까이게 되고, 방치해 두다가 다른쪽 서버 API 작업을 하면서 사용하게 되고, 필요한 기능을 추가 하게 되면서 공개도 하게 된것이다.

기존의 slate-flask 의 이름에서 plate 라는 이름으로 바꾼 이유는 여러가지가 있는데 slate 라는 이름에서 벗어나자는 출사표 같은 의미도 있었고 python임을 강조하고 싶었다. 사실 밝히지는 않았지만, slate-flask 의 이름을 지을때 slate의 원 저작자인 lord 에게 이메일로 물어봤었지만, 자신을 잘 모르겠다는 언급만 한 상태였다.

그리고 Plate-Project 라는 github organization을 만든 이유는 다양한 기능이나 라이브러리, 테마 등을 plate 를 개발하면서 만들게 될 경우, plate 내에 둘수도 있지만, 독립적으로 유지 하는게 더 나을것 같다는 생각도 들었다. 좀더 큰 오픈소스들을 살펴보니 organization 의 형태를 띄고 있는것도 하나의 이유였다.

현재 기능

– 현재 plate 는 markdown 기반의 문서를 웹 페이지로 보여준다는 점, 그리고 API문서내 작성한 프로그래밍 별 코드들을 구분지어서 보여준다는 점이 가장 큰 특징이면서 근본이 되는 기본 기능이다. 그 외에 멀티마크다운 기능은 특정 위치의 마크다운 파일을 지정하는 것이고, 워치독 기능은 해당 문서들의 수정여부를 감시하고 수정시 다음번 웹 페이지 요청이 들어오면 html로 재변환하도록 되어 있다. lunr.js 와 lunr-languages 를 이용해서 다국어 검색이 가능하고, jinja template 를 활용해서 static html 을 만들어 준다.

앞으로의 기능

– 에디터에 대한 부분은 발표에서 summernote를 애기 했는데, 위지윅 오픈소스를 알고 있는게 그것 밖에 없어서 애기한것 같다. 위지윅 에디터를 붙이긴 하겠지만, markdown 에디터이면서 동시에 preview가 되는 것을 붙일 예정이다. 사실 에디터는 조금은 먼 미래의 애기같다. 테스팅도 마찬가지인데, 뾰족한 수가 없어서 생각하고 있는 중이고, 대부분의 금방 추가되는 기능들은 프론트엔드 쪽 일것 같다는 생각이 든다. 보여지는 부분이 중요하기 때문에 바꿀 예정이고, 그래야 slate의 카피캣에서 탈피할수 있을것 같기 때문이다.

궁극적인 기능상의 목표는 에디터와 테스팅이 추가되는 것이다. 그래야 개발자가 쉽게 작성하고 또 다른 개발자가 쉽게 테스팅 할수 있으니까. swagger 나 postman 과의 연계성을 생각해 보고 있다.

Q&A

– EMOCON 당일이나 설문지에 올라온 질문에 대한 답을 드리면.

초보가 오픈소스에 기여하는 방법은 무엇인가요?

– 글쎄요. 저도 초보라서. 관심있는 오픈소스를 찾아서 동작시켜보는게 제일 좋고, 그 부분에 아쉬운게 있다면 개발해서 PR을 보내면 되는데요. 예를 들면, 한국어에 대한 지원이라던지, locale 관련된게 좀 처음에 시작하기 좋은것 같기도 하고 그렇습니다. 절차도 중요한데 어떤 원저작자분들은 이슈를 먼저 제시하거나 이슈에 없는 경우에만 PR을 받아 주는 경우가 있으니 확인해 보는게 좋습니다.

오픈소스 개발자는 생계 유지를 위해 어떻게 해야할까요?

– 저도 이건 잘.. 오픈소스를 하긴 하지만, 전업 오픈소스 개발자는 아니기 때문에. 사실 쉽지 않은 것이라고 생각되고 국내에도 사례가 많지 않으니까요. 그렇지만 확실하게 말씀드릴수 있는건 면접에는 도움이 됩니다. 이건 제가 경험한 거라서 보장합니다.

학부 커리큘럼정도의 지식으로도 카피캣 역할을 할수있나요?

– 크게 상관 없다고 생각하는데요. 학부에서 어떤것을 배웠는지는 알수 없지만(저희때와는 다르겠죠), 결국 카피캣으로 가져와서 내것으로 만드는 작업은 원 소스자체를 분석하면서 공부하는 과정이 선행되어야 하기 때문에 학부지식 보다는 인터넷 검색과 의지만 있다면 가능하다고 생각합니다.

저도 slate 좋아하는데 사내에서 API 문서작업하다보면 swagger같은 류의 라이브 API 문서쪽에 더 맘이 가게 되는데 실제로 만들어서 적용해 보신 의견이 궁금합니다.(오픈 API로 열면 slate류가 더 좋은데 사내에서는 테스트 가능한 API문서가 더 좋더라구요.)

– swagger 같은 라이브 API 문서가 확실히 사용하는 개발자 입장에서는 좀더 좋은것 같습니다. 아무리 설명을 해도 직접 테스트를 해보는것만한 것이 없으니까요. 개인적으로 slate 류는 API에 대해서 자세하게 그림이나 다이어그램, 표 같은 것들을 넣어서 설명할때는 좋은것 같습니다. API의 성격에 따라서 간단하게 보여줄수도 있겠지만, 개발자가 알아야 할 내용들이 많고, 그것들을 그림, 다이어그램, 표 같은것으로 애기 해야 한다면 문서쪽이 좀더 나은것 같습니다. 사용해봤을때 slate류의 단점은 사실 프로그래밍 예제를 구분지어서 보여주는 것이 특징이긴 하지만, API 개발자가 사용해하는 개발자의 주언어를 모르는 경우에는 예제를 작성하기가 어렵습니다. 예를 들면 서버 개발자는 파이썬 개발자인데, API 사용하는 개발자가 아이폰 개발자로 swift로 예제가 제공 되어야 할 경우, 서버개발자가 swift를 알수 없을 경우가 많기에, 이럴경우 예제 작성이 어렵고 이럴 경우에는 차라리 swagger 같은 라이브 API 문서 툴이 더 나을것 같습니다.

Sphinx에 비해 좋은 점이 어떤게 있을까요?

– Sphinx에 비해 좋은점은 문서에 여러가지 프로그래밍 언어로 예제를 작성했을때 구분해서 보여준다는점? 작성한 마크다운 문서를 사용할수 있다는 점인것 같은데요 개인적으로 Sphinx는 프로그램 내의 함수나 동작을 설명하는데는 최고라고 생각하고 있습니다. Sphinx 도 markdown으로 변환해주는 뭔가가 있을것 같은데 활용해 보면 좋을것 같네요.

RAML 같이. 레스트는 표준화진행 같은건 없을까용

– 이 부분은 뭐라고 애기 할수가 없는데 RAML에 대해서 잘 몰라서. 그런데 API 테스팅 툴인 postman 에서는 RAML을 import 해서 쓸수 있긴 한데요. 아직 테스팅과 관련된 표준화는 없는것 같습니다.