안녕하세요.
SWIKI 를 만드는 ‘팀 하이에나’ 의 오세용 입니다.
지난주에 업로드했던 SWIKI 개발기 (1) – 애자일 팀을 만들다! 를 많은 분들께서 읽어주시고 공유해주셔서 정말 감사드립니다. 현재(2015.7.6) 350여명이 읽으셨고, 29분이 facebook 에 공유해주셨습니다. 덕분에 SWIKI 유저도 늘어나고 ‘팀 하이에나’ 에도 좋은 활력소가 된 것 같아 기분이 좋네요.
지난주 글을 올리고 많은 피드백을 받았는데요, 아쉽게도 제가 의도한 바와는 다르게 ‘비개발자’ 분들께서 글을 읽기 어렵다는 이야기를 해주셨습니다. 최대한 풀어서 쓴건데 ‘애자일 방법론’, ‘스플린트’ ,’Android, iOS, Server, php, DB, UI, GUI’ 등 IT 업계에서 사용되는 단어를 어려워하시더군요. 애자일 방법론을 제외하고는 딱히 설명이 필요치 않다고 생각했는데 착각이였나 봅니다. 앞으로는 보다 쉽게 쓸 수 있도록 노력하겠습니다.
오늘은 SWIKI 를 만들면서 ‘팀 하이에나’ 가 사용했던, 현재 사용하고 있는 협업 Tool 에 대해서 소개해드릴까 합니다.
‘팀 하이에나’ 는 총 7명으로 주 스킬이 Android, iOS 인 앱개발팀입니다. 때문에 업무시에는 Eclipse, Xcode 를 제외하고는 스토리보드와 디자인가이드를 볼 때 사용하는 Power Point 정도만 사용했습니다. 이런 상황에서 직접 문서를 만들고 공유하는건 상당히 어색한 일이였죠.
SWIKI 프로젝트의 협업 툴(Tool)을 설명하기에 앞서 우리나라 IT 산업의 대부분을 차지하는 SI 프로젝트에 대해 설명을 드리고자 합니다. 이는 SI 프로젝트와 SWIKI 프로젝트에서 사용되는 협업 Tool이 다름을 설명하기 위함이며, 애자일 방법론이 모든 프로젝트에 적용되기는 어렵다는 것을 설명드리기 위해서 입니다. 이미 아시는 분들이 많으시겠지만 글을 읽으시는 ‘비개발자’ 분들의 이해를 돕기 위하여 IT 사업의 구조와 사용되는 Tool 을 설명드리니 이미 아시는 분들은 스킵하시면 되겠습니다.
이 글은 비개발자분들과 간단히 서비스를 오픈해보고 싶으신 개발자분들께 드리는 글 입니다. 수만명을 위한 서비스를 처음부터 준비하시는 분들에게는 맞지 않는 글입니다. 최대한 빠르고 작게 서비스를 오픈하여 유저들의 반응을 보고 싶으신분들은 아래의 이야기를 한번쯤 참고해보셔도 좋습니다.
IT 서비스는 어떻게 만들어 지냐고? SI 프로젝트에서는 무슨 Tool 을 사용하나?
SI (System Integration) 는 직역하면 ‘시스템 통합’ 이며, 주로 고객사의 전산시스템을 구축해주는 사업을 뜻합니다. SI 사업을 진행하는 대기업으로는 삼성SDS, LG CNS, SK C&C 등이 있고, 대다수의 IT 기업들이 SI 사업을 통해 생존하고 있습니다. SI 프로젝트의 발주자로는 관공서, 은행, 대기업 등이 되겠습니다. IT 사업은 초기 사업 구축시기와 유지&운영시기에 필요 인력이 큰 차이가 나기 때문에 대다수의 기업들이 IT 를 담당하는 정직원을 대거 채용하지는 않습니다. 이는 기업을 운영하는 입장에서 피하기 힘든 선택이며, 아쉽게도 이 선택은 소프트웨어 품질과 보안 취약성 등의 주 원인이 되기도 합니다.
SI 프로젝트에 대해서 글을 쓰자면 지면이 더 필요하겠습니다. 이 칼럼에서는 협업 툴을 전달하는게 목적이니 여기까지만 설명드리겠습니다. 어쨌든 국내에서는 SI 프로젝트가 쉽게 사라질 수는 없는 구조이니 IT 서비스에 관심이 있으신 분들은 아래 설명되는 SI 프로젝트의 흐름을 알아두시는게 도움이 될겁니다.
아래 설명되는 사항은 제가 4년간 SI 프로젝트에서 일하면서 느낀점들입니다. 모든 회사가 같은 분위기가 아니듯 SI 프로젝트에서도 다른 방식으로 업무가 진행 될 수도 있습니다. 다만, 제가 주변에서 보고 들은 내용은 대부분 아래 설명과 크게 다르지 않습니다.
모든 SI 프로젝트에선 제품에 대한 ‘요구조건’ 이 있고 이 ‘요구조건’ 에 따라 개발이 진행됩니다. 대부분의 SI 프로젝트는 다음과 같은 프로세스를 따릅니다. (앱개발 중심으로 설명됩니다.)
<SI 프로젝트의 프로세스 / 폭포수모형>
1. 제품 요구조건 정의 : “PM” (Product Manager 또는 Project Manger 프로젝트의 총 책임자.) 과 “갑” (프로젝트 발주자) 이 협의합니다.
2. 개발 가능한 요구조건 정리 및 상세 기획 : 요구조건을 받은 PM 과 각 파트 PL (Project Leader 각 파트의 책임자로 크게 기획, 개발, 디자인으로 나뉘며 개발파트는 좀 더 세분화하여 나누기도 한다. 예를 들면 앱개발 PL, 웹개발 PL 로 나뉘기도 하고 그 안에서 좀 더 세분화하기도 한다. 프로젝트 크기에 따라 다르다.) 이 요구조건을 정리하고 상세 기획을 하게 되는데, 쉽게 말해 “해당 기능을 제한된 시간내에 개발할 수 있는지” 를 논의하게 됩니다. 이 시점에서 개발하기로 했던 기능은 무조건 기간내에 만들어야만 합니다. 대체로 Word 와 Excel 로 업무가 이루어집니다.
3. 화면설계서(스토리보드 stroyboard) 제작 : 요구조건을 정리하고 상세 기획을 한 뒤, 그 기획서를 가지고 “기획자(Designer)” 들이 화면설계서를 만들기 시작합니다. 스토리보드라고도 하죠. 웹/앱 기획자 분들이 이 시점에서 일을 하게 됩니다. 제가 일했던 곳에서는 Power Point로 산출물이 나왔습니다. (영어권에서는 기획자를 Designer 라고 부른다고 합니다.)
4. 디자인가이드 제작 : 화면설계서가 나오면 그 설계서에 맞게 “디자이너(Graphic Designer)” 들이 디자인 가이드를 만듭니다. 앱개발을 위한 디자인 가이드에서는 iOS 와 Android 의 디자인 가이드가 별도로 제작됩니다. iOS 와 Android 는 스크린 사이즈가 다르죠. 때문에 웹디자인을 하시던 분들이 앱디자인을 하게 되면 처음엔 굉장히 어려워하더군요. Power Point나 PDF 파일, PNG 파일 등으로 산출물이 나옵니다. (영어권에서는 한국에서 디자이너라고 부르는 사람을 Graphic Designer 라고 부른다고 합니다.)
5. 개발 시작 : 화면설계서와 디자인가이드가 나오면 “개발자(Developer)” (팀 하이에나의 구성원들은 모두 개발자로 구성되어 있습니다.) 들이 그것을 보고 개발을 시작합니다. 즉, 개발자들은 프로젝트 발주자와 PM, PL, 기획자, 디자이너 를 거치고나서 할 수 있는거죠. 그리고 역할이 다른 이들은 사용하는 언어와 뇌구조가 다르기 때문에 마치 귀에 헤드폰을 끼고 스피드퀴즈를 하듯 처음의 내용이 엉뚱하게 전달되기도 합니다. 개발자들은 Eclipse, intellij, Xcode, vi 등을 사용합니다.
6. 테스트 : 그렇게 개발이 끝나면 전문 테스터들이 테스트를 시작하고 (테스터가 없는 경우 개발자 및 프로젝트 인원들이 직접 테스트를 합니다.) 버그 트래킹 툴 (만들어진 제품과 요구조건을 비교하여 오류 및 개선사항을 모두에게 알리는 툴) 을 사용해서 산출물을 만듭니다. JIRA, Mantis 등이 있습니다.
7. 요구조건 수정 및 개선 : 이시점은 SI 프로젝트의 마지막 부분이고, 야근이 가장 많은 시기입니다. 여기까지 오는데 길게는 2년도 더 걸리는 프로젝트도 있고, 짧게는 6개월 정도가 걸리는 프로젝트도 있습니다. 인원은 많게는 수백명에서 적게는 10명 미만으로 구성되기도 합니다. 이시점에서 프로젝트 발주자들과 PM 의 기싸움이 시작되는데, 조금이라도 더 많은 기능을 넣어 좋은 제품을 만들고 싶어하는 프로젝트 발주자들과 되도록 만들어진 제품을 안정적으로 마무리하고 싶어하는 PM 의 싸움입니다. 어쨌든 이 시점에서 가장 일을 많이 하는 사람은 대부분 개발자들이 됩니다.
8. 오픈! : 거의 모든 프로젝트는 끝나지 않을 것 같지만 끝나게 됩니다. 물론 돌이킬 수 없이 되어버리는 프로젝트도 있다고 하지만 저는 보지 못했네요.
이렇게 “요구조건 -> 기획 -> 디자인 -> 개발 -> 테스트 -> 오픈” 순서대로 진행되는데 이를 “폭포수 개발방법론” 이라고 부릅니다. 폭포가 위에서 아래로 떨어지듯 프로젝트가 진행된다는 것인데요, 대부분의 SI 프로젝트가 이렇게 진행됩니다. 프로젝트를 시작하기 전 제안서와 오픈 뒤의 유지보수 등의 부가적인 업무는 제외하였습니다.
자, 그럼 여기서 사용되는 툴(Tool) 들은 무엇이 있었을까요?
<SI 프로젝트에서 사용되는 Tool>
1. Word, Power Point, Excel 등 MS Office : 업무에서 빼놓을 수 없는 툴이죠? 스킵하겠습니다.
2. eclipse, intellij, Xcode, vi : ‘비개발자’ 분들은 생소하실겁니다. 화면설계서를 그릴때 기획자들이 Eclipse 에서 “Wireframe” 을 사용하기도 하지만 주로 개발자들이 사용하는 툴입니다.
3. JIRA, Mantis : 버그 트래킹 툴인데요, JIRA 는 협업도구 전문기업 아틀라시안(Atlassian) 에서 만드는 소프트웨어로 굉장히 많은 기업들이 사용하고 있습니다. Mantis 도 많이 사용한다고 하네요.
4년간 SI 프로젝트를 진행하면서 위의 소프트웨어에서 벗어난 적은 없었습니다. 대부분 문서 작업은 MS Office 하나로 하고 있었죠. 하지만 많은 사람들이 불편함을 느끼고 협업 툴을 만들어오고 있습니다. 업무를 진행할때 툴을 특히 좋아하는 편이라 다양한 툴을 사용해보았는데, SWIKI 를 개발하면서 툴에 대해 깨달은 점이 있어 공유하고자 합니다.
SWIKI 는 어떤 툴을 사용해서 시간을 단축했나?
사실 SWIKI 가 대단한 소프트웨어를 사용해서 공유하려고 한 것은 아닙니다. 오히려 누구나 아는 소프트웨어를 사용했지요. 위의 소제목처럼 SWIKI 는 툴을 사용해서 시간을 단축했습니다. 하지만 아래 소개하는 툴들을 사용해서가 아닌 “방법론” 의 차이인데요, 그 설명을 하고자 합니다.
1. Google Drive – https://drive.google.com/
SWIKI 협업 툴로 Google Drive 문서 도구를 선택하면서 좀 놀랐습니다. 대부분의 사람들이 사용하고 있다고 생각했는데, 그렇지 않더군요. 구글 드라이브는 MS Office 가 제공하는 대부분의 기능을 제공합니다.
<Google Drive – 출처 : 오세용>
Google Drive 의 가장 큰 장점은 “실시간 수정” 입니다. 팀 하이에나는 전문 기획자가 아니기 때문에 정말 많은 대화를 통해 기능을 정했습니다. 오전에 정한 기능이 오후에 바뀌는 것은 물론, 1시간 단위로 기능이 바뀌기도 했습니다.
처음엔 문서 디자인이 어려워 기능을 간략히 기록하기 시작했는데, 이게 놀라운 것을 깨닫게 해주었습니다.
점차 기능이 변경되는 이유는 “개발의 용이성” 이 가장 컸는데요, 저는 이게 폭포수 모형의 가장 큰 단점이자, 애자일 기법의 가장 큰 장점이라고 생각합니다. 기능을 표현하는 방법은 한 가지가 아닙니다. 같은 기능을 여러가지 방법으로 개발할 수 있죠. PNG 파일로 쉽게 만들 수 있는 기능을 코드로 만들려면 굉장히 복잡해질 수도 있거든요.
개발자들끼리 이야기를 하며 만들다보니 이 점이 가장 훌륭했습니다. 서로 불편한 곳을 잘 알기에 보다 빠르고 편한 방법으로 같은 효과를 내기 위해 이야기를 나눴고, 이는 문서상에 “실시간 수정” 으로 나타났습니다. 예를들면, SWIKI Android 버전에 들어있는 좌측 슬라이드메뉴는 굉장히 많은 오픈소스 라이브러리가 제공되고 있습니다. 팀 하이에나에서는 보다 빠르게 적용할 수 있는 라이브러리를 찾았고, 빠른 적용 후 다른 기능에 좀 더 투자할 수 있었습니다.
실제로 SI 프로젝트에서는 좌측 슬라이드메뉴가 홈메뉴 위로 올라오느냐, 아니면 홈 메뉴를 밀어버리느냐, 그림자 효과를 넣느냐 등의 디테일을 놓고 굉장히 많은 시간을 소요했습니다. 하지만 허무하게도 1달 뒤 논쟁을 벌이며 개발한 메뉴를 논쟁 전 원래의 모습이 가장 낫다며 돌려달라고 했을때 그 기분이란…
어쨌든 애자일 방법론을 택했던 팀 하이에나에서는 무의미한 기능 변경이 아닌, 효율을 위한 기능변경 차원에서 Google Drive 가 MS Office 보다 더 훌륭한 툴 이였습니다.
<SWIKI 화면설계서 – 출처 : 오세용>
위의 화면설계서는 실제 SWIKI 개발에 사용된 화면설계서입니다. (절대 저렇게 밖에 못만들어서 저렇게 만든게 아님… ㅜㅜ) 위의 그림과 같이 최소한의 틀을 잡고 지속적인 대화를 통해 화면을 수정했습니다.
물론, 위처럼 대충 만든 문서가 독이 될 경우도 있겠습니다. 하지만 두, 세명의 사람만 보는 문서는 굳이 반듯한 틀을 갖춰 실제 앱처럼 만들 필요는 없습니다. 앱을 기준으로 개발을 하면 되거든요. 이는 철저히 모두가 개발자인 팀에서만 할 수 있는 장점이기도 합니다.
Google Drive 를 통해 간단하게 UI 를 그리고 앱을 만듭니다. 그리고 지속적인 대화를 통해 문서가 아닌 앱 자체를 수정해 나가는게 SWIKI 개발의 핵심이였습니다.
Google Drive 를 중심으로 한 SWIKI 는 다음과 같이 개발되었습니다.
<SWIKI 개발방법론>
1. 스플린트(2주) 계획을 잡는다 : 정의된 기능 중 몇가지를 팀원이 함께 선택합니다.
2. 해당 기능의 상세 기획을 한다 : 정말 간략하게 해당 기능을 그림으로 그립니다.
3. 빠르게 UI 를 그린다 : 정말 빠르게 UI 를 붙입니다. 그리고 그 UI 를 가지고 디자인을 합니다.
4. 테스트를 진행한다 : UI 를 가지고 직접 개발을 하면 버그를 정말 빠르게 잡을 수 있습니다. 이는 UI 개발에 최적화된 팀 하이에나의 특화 스킬입니다.
5. 2주만에 오픈 : UI 개발을 하면서 바로 테스트를 하고, 개발자들이 이야기를 하면서 진행하기 때문에 기능이 명확하게 전달됩니다.
2. Confluence – https://ko.atlassian.com/software/confluence
Confluence 는 JIRA 를 만든 협업도구 전문기업 아틀라시안(Atlassian) 에서 만든 소프트웨어입니다. 팀 하이에나는 SWIKI의 개발기간을 단축하고자 해당 소프트웨어를 선택하였습니다.
처음 Confluence 를 선택한 계기는 팀 내 Wiki 때문인데요. 팀 내 정보를 공유하자는 차원에서 선택한 Confluence 를 SWIKI 를 개발하게 되면서 CMS (Contents Management System) 로 사용하며, DB 를 쉽게 다루도록 하였습니다. (CMS 는 블로그 등. 컨텐츠를 다루는 시스템으로 글, 사진 등을 저장할 수 있도록 만들어진 소프트웨어를 뜻합니다.)
Confluence 를 처음 설치할 때 DB 에 접근하지 못하는 hsqlDB 로 생성하여 mysql DB 로 어렵사리 마이그레이션 했던 경험은 다음 포스트에서 공유토록 하겠습니다.
<Confluence – 출처 : 오세용>
어쨌든, Confluence 는 글, 사진을 업로드하고 링크를 거는게 구현되어있는 소프트웨어로 SWIKI 가 컨텐츠를 만드는데 굉장히 편리한 경험을 하게 해주었습니다. 현재 SWIKI 는 보다 나은 서비스를 위해 내부 DB 를 커스터마이징 (제공되는 기능이 불완전할때 원하는 기능으로 바꾸는걸 뜻합니다. 맞춤제작이라고 할 수 있겠지요.) 하고 있습니다.
툴은 이렇게 사용해야 한다고 생각합니다. 이미 개발되어있는 것을 적재적소에 사용하는게 현명한 선택 아닐까요? 문서작업을 돕는 도구만이 좋은 툴은 아닙니다.
Confluence 와 관련된 내용은 다시 포스팅 하겠습니다.
최소한의 툴을 사용하는게 좋더라구요.
툴에 관심이 있으신분들은 다들 들어보셨을겁니다. 트렐로, Slack, JIRA, 여러 프로토타입 툴 등 IT 서비스를 만드는 다양한 툴들이 시중에 나와있습니다. 저는 저런 툴들을 너무도 좋아합니다. 많은 툴들을 사용해보았고, 사이드 프로젝트에서 적용해보았습니다.
하지만, 여러 프로젝트 중에서 SWIKI 만큼 툴을 잘 사용한 프로젝트는 없었습니다.
툴은 꼭 필요한 것만 사용하고, 가장 적은 갯수를 사용하는게 좋았습니다. 팀원들에게 툴을 익히게 하는게 굉장한 스트레스를 주며, 많은 시간을 요구한다는걸 알아야만 합니다. Slack 도 어줍잖게 쓰려면 그냥 카톡으로 대화하는게 더 낫고, 트렐로도 어지간하면 그냥 말로하는게 더 낫습니다. Slack 에 트렐로와 깃헙 등을 붙여서 사용해봤지만 10명도 안되는 인원이 사용하면 오히려 커뮤니케이션에 시간이 더 걸리기도 하더군요. 그냥 카톡으로 “나 커밋했어”, “그거 개발 되었어?” 라고 묻는게 몇 배는 더 빨랐습니다.
만약 빠르게 서비스를 오픈하고 싶다면 직접 서버단을 다 개발하지 말고 CMS 툴을 사용하는 것도 추천드립니다. 굉장히 많은 시간을 절약시켜줍니다. 간단히 서비스를 빠르게 오픈해서 반응을 보고 싶은 기획자분들은 개발자분들께 직접 다 개발하지 말라고 이야기하세요. 있는걸 알면서도 직접 하고 싶어서 오~ 래 걸리는 분들도 있거든요.
SWIKI 의 유저가 늘어나고 점점 기능이 많아지면 Confluece 를 떼어내고 직접 DB 를 구성해야 하는 날이 올지도 모릅니다. 그런 날이 온다면 저는 “때땡큐죠” 하지만 그런날이 오기 전 까지는 굳이 자동차 바퀴부터 만들 필요는 없지 않을까요?
아…! 혹시 이 글이 도움이 되셨나요?? 그럼 아래 링크로 가셔서 SWIKI 앱을 다운 받아 주셔야죠 ㅋㅋㅋㅋ
SWIKI Android 다운받기 -> https://goo.gl/brFV6S
긴 글 읽어주셔서 감사합니다. 뭔가 툴에 대한 깨달음을 얻었는데, 글로 전하려니 쉽지 않네요. ㅎㅎ
앞으로도 여러분들에게 도움이 되는 이야기를 들려드리겠습니다.
감사합니다.
Comments