지난 글에서는 소마에서의 프로젝트 관리에 대해 이야기했습니다. 이번 글에서는 기획심의 이후 6월에 들어서서 본격적으로 프로젝트를 진행하기 위한 아이디어 구체화에 대해 이야기해보려고 합니다.
기획심의는 6월 말이지만 기획심의 전까지 아이디어를 구체적인 기획안까지 끌어내는 것은 쉽지 않습니다. 현실적으로 기획을 구체화시키는 것은 기획심의 이후인 7월 중에 진행하게 될 겁니다. 이 시기에 진행한 것을 크게 두 부분으로 나누면 기획과 디자인입니다.
자랑은 아닙니다만, 소마를 오래 하신 저희 멘토님 왈 저희만큼 철저하게 프로젝트 관리를 수행한 팀은 없다고 하십니다. 오히려 지나치게 철저히 지킬 거 다 지키며 관리한 나머지 개발이 늦어지고, 나머지 팀원들이 개발 좀 하자며 불만을 토로하기도 했었죠. 그러나 제가 다음에 다시 프로젝트를 진행한다 해도 저는 최대한 형식을 갖추어서 프로젝트를 진행할 것 같습니다. 다른 팀에서 개발 중 발생한 문제들 대부분이 저희의 경우 발생하지 않았기 때문입니다. 기획 단계에서 철저하게 작업과 전체 로드맵이 정의되어 있었던 덕분이죠.
그러나 제가 생각하기에도 소마는 어느 정도 빠르게 개발을 진행할 필요성이 있습니다. 지금 와서 반성하면 가성비가 안 나온 행동들이 많았네요. 특히 디자인에서 많은 반성을 합니다.
기획 구체화
기획심의를 위해 한 달 동안 팀원들끼리 열심히 아이디어를 도출했으니 모두가 같은 생각을 하고 같은 목적지를 바라보고 있다고 생각하기 쉽습니다. 그런 생각으로 개발을 시작하면 실제로는 각자의 생각이 얼마나 멀리 떨어져 있는지 알게 됩니다. 개발을 하다 보면 각자의 생각이 달라지는 부분도 있고, 같은 기능을 개발하더라도 사람마다 중요하게 생각하는 부분이 달라서 결과물이 다르게 나오기도 합니다. 그런 것들이 하나하나 쌓이다 보면 퀄리티가 들쭉날쭉인 결과물이 나오게 되지요. 심지어 각자가 다른 방향으로 개발하다가 방향성이 너무나 틀어져 팀 내에서 분쟁이 일어나기도 합니다.
기획과 계획은 이것을 방지하기 위해 필요합니다. 각자의 머릿속에 있는 아이디어를 세분화하여 구성 요소를 정의하고, 그것을 변하지 않는 텍스트로 기술하여 모두가 동일한 방향성을 가지도록 하는 것입니다. 구성 요소가 정의되면 디자인과 계획이 나오고, 그것을 바탕으로 개발이 진행됩니다.
요구사항 정의서와 기능명세서, 유저 스토리
프로젝트 기획에 흔히 등장하는 것이 요구사항 정의서와 기능명세서입니다. 둘은 비슷해 보이지만 원론적으로는 다른 것이지요. 요구사항 정의서는 개발 팀 외부에서 작업을 요청할 때 구현물에 어떠한 기능들이 왜 필요한지 기술하는 것입니다. 기능 명세서는 요구사항 정의서를 바탕으로 개발 팀 내부에서 요구사항을 만족하기 위해 어떤 기능들이 개발되어야 하는지 목록화하는 것이지요. 요구사항 정의서와 기능명세서에 대해서는 구글링 해보면 많은 정보들이 나올 것이니 굳이 설명하지는 않겠습니다.
소마와 같은 인하우스 프로젝트의 경우 기획자와 개발자가 동일하기 때문에 둘을 모두 작성할 필요가 없습니다. 저희의 경우 유저 스토리를 작성하여 사용자가 프로덕트를 어떤 플로우로, 어떤 기능을 사용하는지 목록화하였습니다. 저희는 고객 페르소나가 여럿이라 각 페르소나에 대한 유저 스토리를 작성했지요.
저희가 작성한 유저 스토리입니다. 게임 개발자, 게임 이용자, 광고주, 서비스 관리자가 사용하는 서비스의 각 기능과 기능을 사용하는 목적을 정의했습니다.
인수조건
개발이 필요한 기능 목록을 정의했다면, 이제 각 기능이 제대로 개발되었는지 검증하기 위한 조건을 기술하는 것이 필요합니다. 이것이 인수조건입니다. 사용자 입장에서 각 기능을 성공적으로 이용하기 위해 어떠한 조건을 만족해야 하는지 기술하는 것이지요. 자연어로 테스트 코드를 짠다고 생각하면 쉽습니다. 인수조건을 잘 작성하기 위해서는 이러한 조건들을 만족하면 됩니다.
- 성공과 실패 케이스를 명확하게 기술하며
- 기능을 세세하게 나누어 가능한 많은 하위 기능을 검증하고
- 구현이 아닌 결과에 대해서만 검증하여 개발 가이드라인은 제시하지 않기
저희가 작성한 인수조건입니다. 각 기능이 성공적으로 개발되었는지 검증하기 위한 조건을 기술했습니다.
저희는 기능별로 여러 시나리오를 나누어 인수조건을 작성했고, 각 시나리오는 Given-When-Then 구조로 작성했습니다. Given은 사전 조건, When은 테스트할 조건, Then은 테스트 결과를 의미합니다. 이렇게 인수조건을 작성하면 이후 와이어프레임을 그리거나 개발을 진행할 때 해당 기능이 제대로 개발되었는지 검증하기 쉽습니다.
디자인
기획을 마치면 본격적인 디자인에 들어가게 됩니다. 추천 사항만 결론적으로 말씀드리면, 팀 내에 디자인이 가능한 사람이 있는 것이 아니라면 와이어프레임만 그린 후 프론트엔드 스타일 라이브러리를 결정하고 디자인은 외주로 처리하는 것이 좋습니다.
저희는 Figma 등의 툴을 사용해본 적이 없음에도 직접 디자인을 진행했습니다. 그 결과 디자인에 생각보다 많은 시간이 소요되었고, 결과물도 만족스럽지 않았습니다. 디자인은 생각보다 전문성이 많이 요구되는 작업이기 때문에, 디자인을 직접 하기 어렵다면 외주로 처리하는 것이 좋습니다. 팀의 생산성은 초반이 가장 높고 가면 갈수록 생산성이 떨어지는데, 초기 2~3주를 디자인만 잡고 있기에는 비용이 너무 큽니다.
소마는 생각보다 짧습니다. 프로젝트 규모에 따라 다르겠지만 개발만 하기에도 생각보다 시간이 부족합니다. 저희 팀에서는 기획과 디자인을 7월 넘어가는 때까지도 잡고 있으니 팀 내의 불만이 폭주했습니다. 심지어 작업을 여유 부리면서 한 것도 아닙니다. 저는 학교 종강하고 1주일은 집 안 가고 센터에서 먹고 자면서 작업했는데도 속도가 그렇게 나왔습니다.
결국 생산성이 중요합니다. 소마는 높은 확률로 팀에 개발자만 3명 있습니다. 팀의 능력을 육각형으로 치면 상당히 한쪽에만 치우쳐 있다는 것이지요. 그러니 필수적으로 팀에서 직접 해야 하는 기획이나 계획 수립을 제외하면 개발과 같이 생산성이 나오는 작업에 집중하고, 생산성이 떨어지는 작업들은 최대한 외주로 처리하는 것이 영리하게 일하는 방법입니다. 잘하는 것은 직접 하고, 잘 못하는 것은 외주를 주세요. 괜히 AI도 있는데 직접 해볼까 하지 말고요. 곧 말씀드리겠지만 AI 디자인은 추천드리지 않습니다.
Wireframe
직접 디자인을 하던 외주를 주던 와이어프레임은 필수로 그려야 합니다. 적어도 스토리보드 정도는 있어야 외주 진행도 원활하게 할 수 있습니다. 와이어프레임을 그리면서 기획에서 작성한 기능들이 다 포함되어 있는지, 각 기능들이 인수조건을 만족하는지 따져보아야 합니다. 또 와이어프레임을 그리면서 해당 페이지 옆에 각 요소에서 만족해야 할 조건들을 써두면 이후 개발을 하거나 외주를 줄 때 유용하게 참고할 수 있겠지요.
제가 분석하여 작성한 경쟁사의 UI 분석입니다. 경쟁사의 화면을 분석하여 우리 서비스에 적용할 수 있는 요소들을 찾아냈습니다.
저는 와이어프레임을 그리기 전에 EasterAd와 유사한 서비스들을 찾아보고, 그 서비스들의 화면이 어떻게 구성되어 있는지 참고했습니다. 실제로 최종 결과물과 비교해보면 많은 부분들이 비슷하게 나왔어요. 아무리 와이어프레임이 간략하더라도 맨땅에 헤딩하는 것보다는 참고할 만한 것들을 찾아보면 확실히 도움이 됩니다.
제가 직접 손으로 그린 와이어프레임입니다. 갤럭시탭의 기본 삼성노트 앱으로 그렸어요.
저는 와이어프레임을 손으로 그렸습니다. 저희 팀의 경우 와이어프레임을 바탕으로 생성형 AI를 써서 Figma 디자인을 뽑아낼 생각이었기에 빠르게 이미지 뽑아내기 좋은 손그림으로 진행했습니다. 와이어프레임 자체가 대강 보는 목적이 크기 때문에 손으로 그려도 큰 문제는 없습니다만, 만약 제가 디자인을 외주를 줄 거라면 Figma로 그린 후에 각 페이지 옆에 인수조건을 써서 외주 업체에게 전달했을 것 같습니다. Figma는 버튼에 링크도 달 수 있어서 클릭했을 때 어느 페이지로 넘어가야 하는지도 표현할 수 있고 말이죠.
Figma
저희 팀이 직접 디자인한 Figma 디자인 중 하나입니다. 필요한 페이지를 모두 디자인하고, 각 페이지 옆에 구현 시의 주의사항을 써두었습니다.
Figma도 요즘은 거의 필수죠. 팀에 디자인이 가능한 사람이 있다면 직접 하거나, 아니면 제가 말했듯 외주를 주고 디자인을 Figma로 받게 될 겁니다. 저는 아무것도 모르는 상태에서 어떻게 만들어보겠다고 열심히 만들었는데 지금 보면 그냥 외주를 주는 것이 현명했습니다. 결과물 퀄리티에 있어서 반성하는 부분은 이런 것들이네요.
- 각 요소들의 컴포넌트화가 잘 되지 않았습니다. 차라리 처음부터 직접 만들었으면 모르겠는데, AI가 생성해준 것을 붙여넣은 다음 수정하는 식으로 작업하다 보니 세세한 부분이 들쭉날쭉 했습니다. 결국 나중 가서는 수정사항 하나만 바꾸려고 해도 전체를 수정해야 하는 경우가 많았습니다.
- 디자인을 먼저 하고, 프론트엔드 컴포넌트 라이브러리를 나중에 결정했습니다. 저희는 Flowbite Svelte라는 컴포넌트 라이브러리를 사용했는데, 원래대로라면 컴포넌트 라이브러리를 먼저 결정하고 그 컴포넌트를 사용해서 디자인을 하는 것이 맞습니다. 그런데 저희는 디자인을 먼저 하는 바람에 Figma는 참고만 하고, 실제 개발은 지원하는 컴포넌트들을 사용하면서 진행했습니다. 진행에 큰 어려움은 없었지만, 최종 결과물과 디자인은 많이 다르게 나왔습니다.
- 가장 중요한 것은, 안 이쁩니다. 제가 이쁜 디자인을 뽑아낼 능력이 없습니다.
역시 외주가 현명합니다. 소마에서 주는 프로젝트 진행비 720만원은 이럴 때 쓰라고 있는 것이니 외주에는 돈을 아끼지 마시기를 바랍니다. 다만 외주를 진행할 때에는 외주를 맡길 후보군을 조사한 후에, 멘토님들과 상의해서 결정하시길 바랍니다. 저희 팀에서 이후 랜딩 페이지 디자인은 외주를 통해 진행했는데, 저희가 보기에는 괜찮은 포트폴리오를 가진 업체에 맡겼지만 결과물은 별로였습니다. 멘토님들에게 외주 업체 선정하는 팁도 배울 겸 같이 진행하는 편이 좋겠습니다.
외주로 하든 직접 디자인하든 그 전에 브랜드 컬러 정도는 정해두는 것이 좋습니다. 이후 대부분의 디자인은 브랜드 컬러를 따라가야 하니까요. 이때 주의하실 점이, 일반 RGB 형식으로 아무 이쁜 색이나 골라서 브랜드 컬러로 사용하면 이후 인쇄물이나 다른 매체에서 색이 다르게 나올 수 있습니다. 따라서 브랜드 컬러는 PMS(Pantone Matching System) 색상을 사용하거나, CYMK 형식으로 변환했을 때 색이 변하지 않는 색을 사용하는 것이 좋습니다.
사소한 이야기지만 로고 디자인은 Adobe Illustrator로 진행했습니다. 즉, 로고도 제가 만들었다는 것이지요. 브랜드 컬러가 CYMK로 변환할 때 색이 달라진다는 것을 제외하면, 저는 로고 디자인은 나름 나쁘지 않게 했다고 만족하고 있습니다.
로고는… 페이지 디자인보다는 나쁘지 않게 한 것 같습니다. 콩깍지일 수도?
비추천: 생성형 AI를 활용한 직접 디자인
저희는 Image나 Text를 입력받아 Figma 디자인을 생성하는 Galileo AI를 사용해서 디자인을 진행했습니다. 사실 디자인을 직접 한 것은 어느 정도 AI를 믿었기 때문인 것도 있습니다. 그러나 AI만 믿고 디자인을 직접 진행하는 것은 추천하지 않습니다. 이유는 다음과 같습니다.
- 생각만큼 와이어프레임대로 잘 뽑아주지 않습니다. 물론 제가 와이어프레임을 너무 간략히 그렸을 수도 있지만, 그걸 고려해도 분명 그렸는데 생략되거나 와이어프레임과 다르게 디자인되는 것이 많았습니다.
- 와이어프레임에 한글이 포함되어 있어도 결과물은 영어로 나옵니다. 애초에 제가 써둔 한글 인식도 잘 못하는 것 같습니다.
- 수정하기 어려운 형태로 디자인이 작성됩니다. 당연히 컴포넌트화는 되어있지 않고, 적절한 계층구조를 따라서 디자인이 되는 것이 아닌 Fixed로 위치가 표현되는 것이 많아서 수동 수정이 어려웠습니다.
- 어차피 Tailwind나 Flowbite 등의 디자인 프레임워크를 쓰게 된다면 대부분의 경우 해당 프레임워크에서 지원하는 컴포넌트를 사용해서 개발을 하게 됩니다. 그러나 AI로 디자인을 뽑아내면 그러한 것과 무관한 디자인만 나오게 됩니다.
- 저보다는 낫지만 별로 안 이쁩니다. 와이어프레임이 문제가 아닌 것이 텍스트로 설명해서 생성해도 안 이쁘게 나옵니다.
전체 로드맵 그리기
기획과 디자인이 어느 정도 끝나면 대충 개발에 필요한 작업량이 어느 정도인지 파악할 수 있습니다. 이때 전체 로드맵을 그려서 개발 일정을 팀원들과 공유하면 좋습니다. 저는 draw.io를 사용해서 로드맵을 그렸습니다.
저희 팀이 막 개발 시작한 7월 초에 처음에 그린 로드맵입니다. 지금 보면 참 욕심이 컸다 싶네요…
물론 로드맵을 그린다고 해서 꼭 일정이 로드맵대로 진행되는 것은 아닙니다. 저도 그려놓고 프로젝트 끝날 때까지 한 여섯 번은 더 수정했습니다. 처음에 욕심 낸 것대로 작업이 진행되지는 않더랍니다.
그럼에도 저는 로드맵을 그리는 것을 추천합니다. 로드맵이 있어야 개발이 어느 정도 진행되었는지 한눈에 파악할 수 있습니다. 작업이 늦어져도 적어도 그 사실을 빨리 알 수 있으니까요. 또 로드맵이 있어야 팀원들도 큰 그림을 같이 따라갈 수 있습니다. 암만 팀장 머릿속에 있는 큰 그림을 열심히 설명해도 뒤돌아서면 까먹습니다. 팀원들이 문제라는 것이 아니라, 사람은 원래 당장 눈에 안 보이는 것은 잘 기억하지 못해요. 그러니 팀원들과 큰 그림을 공유하기 위해서는 머릿속의 큰 그림을 시각적으로 끄집어내서 “지금 여기”라고 보여주는 것이 중요합니다.
To Be Continued…
다음 글에서는 본격적으로 개발 이야기를 해보겠습니다. 사실 개발의 경우는 각 팀마다 너무 방향이 다르기 때문에 구체적인 이야기를 하기는 어렵습니다. 그러니 조금 큰 범위에서 ICT 분야 전반에 적용되는 이야기들과 개발 중에 겪은 이야기들을 이야기해보겠습니다. 그럼 다음 글에서 뵙겠습니다.