디지털 노마드를 꿈꾸며
들어가며
웹 서비스를 운영하는 여느 회사들처럼 엘리스의 엔지니어링 팀도 ‘프론트엔드’ 팀과 ‘백엔드’ 팀으로 이루어져 있습니다.
‘프론트엔드’는 앞쪽에서 유저와 직접 맞닿아 있는 부분을 말합니다. 엘리스와 같은 웹 서비스에서는 웹 브라우저에서 유저들에게 보이는 웹페이지를 HTML/CSS/Javascript를 이용해 만드는 사람들이 프론트엔드 엔지니어라고 할 수 있습니다.
‘백엔드’는 유저의 눈에 보이지 않는 뒷부분을 말합니다. 백엔드는 프론트엔드에서 보내는 요청을 처리하고 데이터를 보내주는 역할을 하는데요, 엘리스는 현재 프론트엔드 엔지니어 3명과 백엔드 엔지니어 2명이 서비스 개발을 담당하고 있습니다.
한 가지 놀라운 점은, 엘리스의 엔지니어링 팀을 비롯해 디자인 팀, 운영팀 등이 모두 한 곳에 모여있지 않다는 것입니다. 국내에서는 이러한 형태의 원격 근무를 도입한 회사를 찾아보기 어렵지만, 기술의 발전으로 변화한 환경에서 ‘디지털 노마드’를 하나의 생활 양식으로 도입하고자 하는 목소리는 증가하고 있습니다. 디지털 노마드는 쉽게 말하면 어디든 자신이 일하고 싶은 곳에서 원격으로 근무하는 사람을 뜻합니다. 엘리스는 회사 구성원 전체가 원격 근무가 가능한 디지털 노마드 회사를 꿈꾸고 있습니다.
엘리스의 모든 개발 과정은 디지털 노마드의 꿈에 걸맞게 원격으로 이루어집니다. 물론 원격으로 함께 일하기 위해서는 효과적인 툴의 도움이 필요할텐데요, 디지털 노마드를 실현하기 위해 엘리스에서는 어떤 도구들을 사용하고 있을까요? 이 글에서는 프론트엔드 팀의 관점에서, 엘리스 웹사이트에 기능이 추가되는 과정과 사용되는 협업툴을 2017년 초에 개발된 ‘헬프센터’를 예로 들어 이야기해보겠습니다.
엘리스의 프론트엔드 개발 싸이클
엘리스에서 기능이 개발되는 대략적인 흐름은 다음과 같습니다.
기획 - 디자인 - 구현 - 테스트 - 배포 & 모니터링여기서 각 단계는 엄밀히 나눠져있거나, 무조건 한 방향으로 흐르지는 않습니다. 구현을 하다가도 기획을 수정해야 하면 다시 처음으로 돌아가기도 합니다. 각 단계를 좀 더 자세히 살펴보도록 하죠.
기획 단계
어떤 기능이 왜 필요한지, 필요하다면 일의 중요도와 걸리는 시간은 어떤지 등을 엘리스의 연간 로드맵과 비전에 맞춰 논의하고 계획하는 단계입니다. 거의 모든 논의는 Slack이라는 온라인 협업 툴의 화상채팅에서 이루어집니다. 엘리스에는 ‘기획자’라는 역할이 명확하게 주어진 사람은 없습니다. 기본적으로 팀 리더가 의견을 취합하고 방향성을 제시하지만, 엔지니어링팀, 운영팀, 디자인팀 모두가 의견을 자유롭게 제안할 수 있습니다.
2017년은 엘리스가 처음으로 대학교, 기업 등 기관 고객이 아닌 일반 사용자에게 수업을 제공하기 시작한 해입니다. 우리는 프로그래밍 학습을 하는 데 있어서 아주 중요한 요소 중 하나가 실습을 빠르게 많이 해보고 막혔을 때는 선생님에게 도움을 받을 수 있게 하는 것이라고 생각했습니다. 특히 프로그래밍을 한 번도 접해보지 않은 분들이 엘리스에서 처음으로 코딩학습을 시작하는 경우가 많았기 때문에, 이러한 사람들에게 효과적으로 도움을 줄 수 있는 기능이 무엇일지에 대한 많은 논의를 나눴습니다. 논의의 결과 개발하기로 결정한 것이 헬프센터입니다.
거시적 관점에서의 논의가 어느 정도 정리된 후에는 위 그림과 같이 구글 프리젠테이션으로 빠르게 만든 저수준(Low Fidelity) 디자인이 유용하게 쓰입니다. 이러한 저수준 디자인을 통해 개별 페이지의 상세한 디자인에 착수하기 전에 사용자 인터페이스와 경험(UI/UX)을 미리 설계해서 피드백을 주고받을 수 있습니다.
기획 단계에서는 기능 요구사항이 현재 서비스 구조와 잘 어울리는지, 무엇이 가능하고 무엇이 하기 어려운지 등을 미리 잘 정해두어야 합니다. 그래야 개발 도중에 뒤엎는 일이 적기 때문입니다. 프론트엔드 엔지니어는 기획 단계의 요구사항을 잘 파악한 뒤에, 새로 기능을 개발하는 데 있어서의 제약사항이나 기존 구조에 대한 변경사항 등의 디테일을 백엔드 엔지니어와 함께 논의하면서 자세하게 정의해 나갑니다. 따라서 다른 팀의 사람들과 소통하는 능력은 프론트엔드 엔지니어에게 특히 중요한 역량이라고 할 수 있습니다.
기획 단계에서 주고받은 논의 결과는 엘리스의 위키 페이지에 정리되고, 이슈 관리 도구인 Jira에 등록됩니다. 엘리스의 모든 팀원들은 위키 페이지와 Jira를 통해서 논의된 결과를 확인하고 일의 진행 상황을 파악하게 됩니다.
주 사용 도구: Slack, Google Presentation, Confluence Wiki, Jira
디자인 단계
기능 개발에 필요한 각 페이지의 디자인이 고수준(High Fidelity)으로 만들어지는 단계입니다. 자세한 디자인에 들어가보고 나서야 파악되는 문제도 있기 때문에 디자인 단계에서도 기획에 대한 논의와 수정은 계속됩니다.
디자인 단계에서의 논의 역시 Slack 채널에서 이루어집니다. 프론트엔드 팀과 디자인 팀은 온라인에서 디자인 페이지를 함께 보며 디자인에 대한 논의를 진행합니다.
엘리스 디자인 팀에서는 주로 Sketch로 페이지 디자인을 합니다. Sketch로 디자인이 되고 나면 페이지 단위로 Invision에 업로드되는데, Invision에서는 다른 페이지로 넘어가는 링크뿐만 아니라 페이지 안에서의 인터랙션(스크롤 내리기, 클릭하기 등.)도 어느 정도 표현할 수 있습니다. 또한 각 요소의 색깔, 크기, 다른 요소와의 간격 등을 개발자가 볼 수 있어서 이를 토대로 페이지를 구현하게 됩니다.
새로운 페이지를 만들 때 중요한 것 중 하나는 기존 페이지에서 사용자가 경험했던 것을 비슷하게(Consistent) 유지하는 것입니다. 이는 사용자 경험 측면에서도 좋고, 엔지니어 입장에서도 비슷하지만 조금 다른 코드를 자꾸 만들 필요가 없어서 좋습니다. 엘리스 프론트엔드 팀에서는 일관성 있는 디자인을 돕기 위해 비슷한 상황에서 쓰이는 요소들을 모듈화하여 가져다 쓸 수 있는 elice-blocks라는 것을 만들었습니다.
요즘은 디자인 팀에서 elice-blocks를 최대한 활용하여 페이지 디자인을 하기 때문에 전보다 코드 품질도 올라가고 개발 속도도 더 빨라졌습니다.
새로운 페이지에 대한 디자인이 나오면 프론트엔드 팀과 디자인 팀은 Slack에서 스크린 공유를 통해 Invision 페이지를 함께 보며 elice-blocks가 어떻게 사용되었고 어떻게 업데이트되어야 하는지도 논의합니다.
주 사용 도구: Slack, Sketch, Invision
구현 단계
Jira에 기술된 기능 요구사항과 Invision 페이지를 보며 실제 코딩을 하는 단계입니다. 기획과 디자인 단계에서 충분한 논의가 되었다면 구현 단계에서 걸리는 시간이 많지 않을 수도 있습니다.
현재 프론트엔드 팀은 3명뿐이라서 보통은 한 사람이 기능 하나씩을 맡아서 개발합니다. 이렇게 할 경우 개발 속도는 좀 빨라질 수 있으나 코드의 품질과 안정성이 떨어질 수 있다는 단점이 있습니다. 이를 보완하기 위해 각자가 할 일을 하면서도 짧은 시간 페어 프로그래밍을 하기도 하고, 완료된 기능에 대해서는 코드 리뷰를 진행합니다.
페어 프로그래밍 역시 원격 상황에서 이루어집니다. 하지만 원격으로 안정적인 진행이 쉽지는 않았는데요, 여러 가지를 시도해본 결과 가장 안정적인 것은 Slack으로 화상채팅을 하면서 TeamViwer로 호스트의 컴퓨터를 함께 컨트롤하는 것이었습니다. 3명의 팀원 모두가 함께 진행한 적도 있었는데 무척 재미있더군요.
코드 리뷰는 방대한 기능을 개발했을 경우에 팀 차원에서의 리뷰를 위한 화상 회의를 통해 진행됩니다. 또는 해당 기능을 이용하는 개발을 페어로 하기도 합니다. 기본적으로는 엘리스에서 소스코드 관리 도구로 사용하는 Gitlab 안에서 코드 리뷰가 이루어집니다.
코드 리뷰 이외에 코드 품질을 높이는 비교적 쉬운 방법 중 하나는 팀의 코딩 스타일 가이드를 잘 정하고 이를 따르는 것입니다. 프론트엔드 팀은 Airbnb의 Javascript 스타일 가이드를 입맛에 맞게 수정해서 사용해왔습니다. 지금은 이를 좀 더 엄밀하게 적용할 필요성을 느껴 Javascript에 대해서는 eslint를, CSS에 대해서는 scss-lint를 이용하여 스타일을 맞추고 있습니다. 이 중 eslint는 후술할 테스트 단계에서도 사용됩니다.
참고로 엘리스 프론트엔드는 React 로 구현되어 있는데 페이스북에서 React를 내놓은 아주 초반부터 React를 사용해왔습니다. 그래서 React의 최신 기술이 아닌 오래된 레거시 코드라고 할 만한 부분이 꽤 많습니다. 신규 기능 개발과 더불어 이전 코드를 리팩토링하고 자잘한 버그를 수정하는 것 또한 프론트엔드 엔지니어가 할 일입니다.
주 사용 도구: Jira, Invision, Slack, TeamViwer, Gitlab, eslint, scss-lint
테스트 단계
구현된 기능이 실제로 사용자에게 전달되기 전에 다양한 테스트를 거치는 단계입니다. 가장 기본적인 테스트는 엔지니어가 직접 개발하면서 여러가지 경우의 수에서 의도한 대로 작동하는지 확인하는 것입니다. 여기에 자동화 테스트와 사람이 직접 하는 테스트가 추가됩니다. 엘리스에서 수행하는 자동화 테스트의 종류는 다음과 같습니다.
- 빌드 테스트: 코드가 에러 없이 잘 빌드되는지 확인
- 스타일 테스트: 코드가 엘리스 프론트엔드 팀의 스타일 가이드와 잘 맞는지 확인 (eslint)
- 유닛 테스트: 개별 기능이 잘 동작하는지 확인
- 통합 테스트: 기능의 추가가 전체 시스템에 영향을 미치지는 않았는지 전체 시스템의 동작을 확인
자동화 테스트는 Gitlab의 지속적 통합(CI, Continuous Integration) 도구에 연결해두었기 때문에 Gitlab에서 새로운 커밋이 올라오면 자동으로 해당 테스트들이 통과하는지 확인합니다. 즉 코드 리뷰를 시작하기 전에 이미 자동화 테스트는 수행된 것이라고 볼 수 있습니다. 다만 아직까지 엘리스의 코드 규모에 비해 자동화 테스트가 커버하지 못하는 부분이 많기 때문에 이것을 차차 추가해나가고 있습니다.
이와 같이 구현과 자동화 테스트는 단계를 나누기 모호할 정도로 긴밀하게 연결되어있지만 굳이 단계를 나눈 이유는 사람이 직접 하는 테스트 때문입니다.
자동화 테스트와 리뷰가 끝난 기능은 엘리스의 베타 서버에 올리고, 이를 Slack 채널을 통해 엘리스 팀원들에게 알립니다. 그러면 기획 단계에 참여한 사람들은 베타 서버에서 구현된 기능의 실제 동작을 확인하고 최초의 요구사항을 만족하는지 확인합니다. 확인한 사항에 대한 피드백은 Slack 채널에서 이루어지고 이때 미비한 점이나 버그가 발견되었다고 하면 다시 구현 단계로 돌아가게 됩니다. 요구사항이 잘 만족되었다면 이를 해당 기능에 대한 Jira 이슈에 표시하고 그 기능은 배포가 가능한 상태가 됩니다.
배포 및 모니터링 단계
구현된 기능이 포함된 버전을 실제 프로덕션 서버에 올리고 확인하지 못한 버그가 발생하지 않는지 모니터링하는 단계입니다. 엘리스는 일주일에 한 번 배포를 기본 원칙으로 하는데, 개발된 것을 목요일까지 베타 서버에 올리고 테스트를 거쳐 목요일 밤이나 금요일에 배포합니다.
모니터링을 위해 엘리스에서 사용하고 있는 Sentry는 Google Analytics(GA)와 같은 사용자 로그 수집 도구인데, GA와 다른 점은 에러 로그에 특화되어있다는 것입니다. 사용자가 경험한 자바스크립트 에러는 사용자가 어떤 과정을 거쳐 그 에러를 경험하게 되었는지와 함께 기록되고 리포트됩니다. Sentry로 기록되는 에러를 포함하여 다른 모든 종류의 로그는 자체 개발한 elice-logger를 통해 기록되고 있습니다.
또한 엘리스에서는 Intercom이라는 사용자 소통 도구를 통해 피드백을 수집합니다. 로그인한 사용자라면 누구든지 ‘문의하기’로 엘리스 운영팀에게 메시지를 보낼 수 있습니다. Intercom에서 들어온 메시지는 Slack을 통해 엘리스 팀 전체에게 공유되고, Sentry에서 들어온 메시지 또한 그렇습니다.
Slack으로 사용자 문의가 들어오면 이를 확인한 후에 고쳐야 할 버그라면 수정 작업에 들어갑니다. 버그 수정은 기획-디자인 단계가 문제 제기 단계로 바뀌는 것을 제외하면 기존의 기능 개발 싸이클과 동일합니다.
소프트웨어 환경 A에서 권한 B를 가진 계정으로 행동 C를 할 때 원래 예상되는 결과는 D1이지만 현재는 D2가 일어난다
라는 포맷으로 문제가 제기되면 이를 개발자가 확인한 후에 문제의 심각성을 파악하여 마찬가지로 구현, 테스트, 배포 및 모니터링을 단계를 진행합니다.
주 사용 도구: Jira, Sentry, Intercom, Slack
마치며
이번 글에서는 디지털 노마드를 꿈꾸는 회사로서 엘리스가 어떤 도구들을 이용하여 기능을 추가하고 버그를 수정하는지를 이야기했습니다. 저는 엘리스가 언젠가 겨울에는 호주에서, 여름에는 캐나다에서 개발할 수 있는 회사가 되기를 소망하고 있습니다. 원격근무가 활성화된 것으로 유명한 회사들이 외국에는 많은데(Gitlab, Basecamp 등) 한국에서는 어떤 회사들이 어떤 도구를 이용하여 디지털 노마드를 실현하고 있는지 궁금하군요.
위와 같은 개발 과정을 잘 해나가기 위해 엘리스의 프론트엔드 엔지니어들에게 필요한 역량은 이런 것들입니다.
- 거시적 관점에서 회사의 비전/로드맵과 현재 하는 일이 잘 맞는지 판단하기
- 기획자 역할을 하는 사람의 의도를 파악하고 이를 토대로 백엔드 엔지니어와 소통하여 개발 스펙 산출하기
- 엘리스 프론트엔드의 스타일 가이드와 React의 좋은 패턴을 이용하여 고품질의 코드로 기능 구현하기
- 각자의 일하는 방식을 존중하고, 함께 하는 세션에 적극적으로 참여하기
- 자신이 구현한 기능을 책임지고 테스트와 유지보수하기
- 여러가지 도구를 익숙하게 사용하며, 새로운 도구를 두려워하지 않고 빠르게 학습하기
- elice-blocks와 같이 작지만 유용한 내부 프로젝트들을 구현하기
- 사용자의 메시지에 귀를 기울이지만, 그것을 있는 그대로 받아들이기보다 진짜 문제를 찾아서 해결하기
물론 현재 저를 포함한 엘리스 팀원들 역시 이 모든 것을 유지하고 더 잘하기 위해 열심히 노력하는 중입니다. 본인에게 이러한 역량이 있거나, 그런 주변 사람을 알거나, 함께 디지털 노마드 회사를 만들고 싶거나, 또는 이 글을 읽고 엘리스의 프론트엔드 팀에 관심이 생기셨다면 주저없이, 연락주시기 바랍니다. 읽어주셔서 감사합니다.
