Wise*racker Developer document site

솔루션이나 Saas기업 중 SDK나 API를 제공하는 회사라면 어떤 회사던지 제대로 된 가이드를 제공하고 싶을 것입니다.

걔 중엔 Zendesk와 같은 타 기업의 제품을 사용하는 곳도 있고 자체 구축하는 곳도 있죠.

최초엔 저희도 Zendesk를 고려해 보았습니다.

 

경쟁사들도 Zendesk를 사용하고 있기도 했고 Zendesk의 타 제품과의 연동, 그리고 관리의 측면에서 유리할 것이라 생각했기 때문입니다.

보통의 가이드 문서는 Markdown의 형식으로 생산이 되었고 일반적인 수준에선 Markdown이 큰 기능 없이 Codeblock만 제대로 표현되면 문제없었습니다.

하지만 저희는 사정이 약간 달랐습니다.

 

Mobile attribution & Analytics의 서비스답게 각 플랫폼에 대한 연동 방법이 세분화되어야 했고 이를 단순하게 md로 제공하게 되면 생산성이 좋지 않을 염려가 있었습니다.

플랫폼마다 md를 생산해야 하고 메뉴도 별도로 제공해야 하며 스펙이 변경되면 해당되는 모든 md를 수정해야 했기 때문입니다.

 

Zendesk를 고려했던 이유는 위의 문제들을 쉽게 해결할 수 있을 것이란 기대가 있었기 때문입니다.

하지만 Zendesk의 가이드 플랫폼은 일반적인 md를 작성하는 서비스였고 각종 custom components를 사용할 수 있는 만만치 않은 가격의 "스킨"은 별도로 구매하거나 직접 개발해야 했습니다.

 

그래서 결정하게 되었습니다.

Markdown을 제대로 제공할 수 있는 가이드 사이트를 직접 만들자.

 

Markdown을 가장 빠른 속도로 유저에게 제공할 수 있는 수단을 찾기 시작했고 이미 생태계가 많이 성숙해진 Gatsby를 이용해 만들기로 결정하였습니다.

React를 이용할 수 있었고 MDX(MD에서 JSX를 사용할 수 있는 포맷)와 GraphQL을 이용할 수 있었습니다.

디자인과 개발까지 빠르게 진행할 수 있는 점도 장점이었고 모두 정적 페이지로 생성이 되어 로딩 속도가 어마어마하게 빨랐습니다.

 

프로젝트 진행 당시 Gatsby와 GraphQL에 대해 아는 것도 없어 러닝 커브가 심했습니다.

특히 MDX에 Custom Components를 만들어 넣는 것과 Codeblock를 튜닝하는 일은 극도의 스트레스를 유발했습니다.

디자이너 입장에서 모든 개발을 직접 진행하는 것은 무리라 판단하고 개발팀의 인원 한 명을 섭외하여 프로젝트 기간을 대폭 단축시켰습니다.

 

개발 경력자는 MDX 포맷에 Custom Components 삽입하는 Provider와 Netlify CMS시스템을 개발해 주었고 저는 그 외에 모든 부분을 개발하였습니다.

Documents site에서 사용한 모든 UI Components는 기존 솔루션에서 만들어둔 디자인 시스템을 이용했기에 디자인에 시간을 많이 투입할 필요가 없었습니다.

 

프로젝트는 2주일간 다른 업무와 병행하며 진행하였고 성공적으로 론칭하였습니다.

현재는 지속적으로 기능 업데이트를 하고 있고 각 플랫폼 담당 개발자들이 md를 생산해 직접 업로드하고 있습니다.

 

Term

2020-04-01 ~
2020-04-15

Worker

모두 본인

Stack

React, GraphQL, Gatsby

Tools & Service

Sketch