공대생의 기획
공대 개발 팀플 이런 식으로 했습니다
요약
- 키워드
공대생 기획법, 디자이너 없이 디자인하는 법, 개발 공식 문서, 토이 프로젝트 적용
- 수준
팀플레이가 가능하면 누구나.
여는 글
어떤 것을 만들 것인지, 왜 그걸 만드려고 하는지는 늘 중요합니다.
그것이 프로젝트의 목적이 되기 때문이고, 팀원들과 개인의 동기가 되기 때문입니다. 그렇기에 설계도라고 볼 수 있는 기획 단계가 중요하지만, 공대생의 입장에서 보자면 기획은 참 어렵습니다. 프로젝트를 처음 시작할 때면 막막하죠.
어디까지 설계를 해야 하는지, 혹은 이렇게까지 해야 하나 싶은 의문이 들기 딱 좋은 파트라고 생각합니다.
IT 개발 동아리 운영진을 2년 동안 하면서 늘 기획 파트의 어려움을 느꼈습니다. 기획팀을 따로 뽑지 않았기 때문에, 디자인팀과 개발팀이 직접 실전으로 경험하며 해결책을 찾아보기도 했고, 커리큘럼을 수정할 당시 복전 중인 디지털 인문학에서 해결책을 찾기도 했었죠.
이번 졸업 프로젝트 기획을 9월부터 2달간 진행하면서, 그 경험을 토대로 계획을 세우고 운영을 했습니다.
이 글에서는 주제 선정부터 팀원들의 역량에 따른 일정 작성, 그리고 공식 문서 적용을 통한 기술테스트 방법에 대해 제 나름의 방법을 설명하려고 합니다.
당연히 정석적인 방법이 아닙니다. 방법론 중 일부를 차용한 것도 있고, 제 식으로 변형한 것도 있습니다. 학부생의 입장에서, 대학교 팀플 정도의 레벨로 서술되는 점 참고 부탁드리겠습니다.
어떤 프로젝트를 처음 시작하려는 공대생에게 작게나마 도움이 된다면 기쁠 것 같습니다.
공대생은 어디까지 기획해야 할까?
학부 공대생의 기획은 주제 선정에서 시작해서 기술 설계로 이어집니다. 앞부분의 주제 선정 등은 사실 회사 등에서는 유관 부서에서 따로 일을 해 줄 테지만, 학부생은 A to Z 가내수공업을 해야 하므로 순차적으로 적어보도록 하겠습니다.
당연한 말이지만 스스로 준비해야 하는 몇 가지를 빼면 모든 과정은 팀 단위로 이루어진다는 점을 명심해 주세요.
같은 주제를 두고 서로 다른 이야기를 하는 일이 없도록 충분한 대화가 필요합니다.
기획 1. 브레인스토밍
먼저 해야 하는 건 문제점을 선정하고 주제문을 작성하는 겁니다. 앞으로 프로젝트는 모두 이 주제문에 맞춰서 진행될 테니까요.
주제를 만드는 데는 여러 가지 방법이 알려져 있지만 제가 선호하는 방식은 브레인스토밍입니다. 아마 학창 시절 한 번쯤은 해보셨을 거라 생각되니 자세한 이야기는 줄이고, 저희 팀이 진행했던 방식을 적어보겠습니다.
우선 회의를 진행하며 나온 의견들은 빠짐없이 기록해야 한다는 걸 꼭 명심해 주세요. 아무리 사소한 것이어도 괜찮습니다.
- 미리 자기 주제를 간단하게 정리해 온다.
다른 사람이 내가 관심 있는 것에 대해 잘 모를 수 있습니다. 핵심 단어에 대한 정의, 해당 주제에 대한 배경, 기존의 해결책이나 발전 방향, 내가 생각하는 문제점 정도는 정리해 오도록 합시다.
해결책을 준비해 올 수 있다면 바로 자신의 주제문이 정의되겠지만, 해결책 없이 문제만으로도 괜찮습니다. 의견 교환을 하면서 다시 발전시킬 수도 있으니까요.
주제는 1~2가지 정도면 적당합니다.
- 적절한 시간을 세팅한다.
자기가 해 보고 싶었던 것에 대해 이야기하고 다른 사람의 주제에 살을 붙이는 방식이기 때문에, 너무 길어지면 회의가 루즈해지고 의견을 내는 것도 힘들어집니다.
저희 팀은 1시간 정도로 잡았습니다.
- 다른 사람의 주제에 대해 살을 붙일 때는 이 주제로 프로젝트를 진행한다고 생각하고 최대한 살을 붙인다.
언제까지 살을 붙이냐면, (제 기준으로) 팀원들 간에 해당 주제에 대해 5분 이상의 침묵이 이어진다면 멈춥니다.
저는 일단 20분 정도 진행해 봅니다. 그 이상으로 이어지면 일단 한차례 마무리하고 다음 주제로 넘어가고, 팀원들이 준비해 온 주제들을 전체 한 사이클 돈 후에 마무리를 못했던 주제들에 대해 다시 진행하고 있습니다.
스타트 3팀 브레인스토밍 결과기획 2. 어피니티 다이어그램
어느 정도 의견 교환이 이루어지면, 첫 주제의 기록부터 살펴보며 다음 단계를 거칩니다.
어피니티 다이어그램 (Affinity Diagram) 방식인데, 자료 조사 등의 리서치를 통해 정보를 모은 뒤 이를 분류하고 정리하는 방법입니다. 서로 관련된 기록들을 그룹으로 묶어서 문제점이나 원인을 명확히 만들어줍니다.
- 묶은 그룹을 한 문장이나 단어로 그룹에 라벨링을 해준다.
묶는 과정에서 어떤 기록들이 중복이 된다면, 그런 중복은 제거해 주면 됩니다. 라벨링을 하는 과정에서 새로운 문제나 해결방안을 찾았다면 별도로 기록을 해 줍니다. 이때 공통점들을 지나치게 단순화해서 표현하지 않도록 조심합시다.
- 라벨링을 하는 과정에서 의문점이 생기면 추가 조사를 진행한다.
앞서 충분한 토론이 이루어졌다면 좋았겠지만, 그냥 지나쳤을 애매한 지점이 분명히 남아있을 겁니다. 그 자리에서 찾을 수 있는 정량적인 데이터가 있다면 바로바로 조사를 해서 팀원들에게 요약해서 설명한 뒤 문장을 추가해 줍시다.
단순히 데이터나 정보의 링크만 보내면 안 됩니다.
왜 필요한 추가 조사인지 납득시킬 수 있어야 합니다.
브레인스토밍 주제 중 하나를 디벨롭하던 것. 진행이 막혀서 다른 주제로 다시 진행했었다.기획 3. 처음부터 살펴보기
브레인스토밍을 통해 나온 아이디어들이 그룹화된 문장들과 거기서 파생/새로 도출된 문장들을 처음부터 보며, 팀원들 모두가 흥미롭고 발전시킬 의욕이 있는 아이디어를 고르도록 합시다.
저희 팀 선정 기준으로는
문제가 명확하게 정의되고 해결할 방안이 나온 것
팀원들의 생활에서 밀접하게 연관이 될 것
사용할 데이터로의 접근이 용이할 것
정도가 있었습니다.
기획 4. 타인의 시선 빌려오기
팀에서 선정한 아이디어의 방향이 적절한지 검증을 한 번 거치게 되면, 프로젝트를 진행하다가 막혀서 엎을 가능성을 줄일 수 있습니다. 저희 학교에서는 지도 교수 면담, 외부 현직자 멘토링 등을 지원해주고 있습니다.
그 외에도 대단위 설문조사를 진행하거나, 유저 인터뷰를 진행해 보는 것도 좋은 방법입니다. 설문조사나 유저 인터뷰를 할 때는 질문 구성을 잘해야 합니다. 어떤 질문을 통해 얻고자 하는 정보가 무엇인지 명확해야 합니다.
답이 정해져 있는 질문, 예를 들어 단순한 '이 서비스가 앱스토어에 등록된다면 사용하시겠습니까?'는 지양하는 것이 좋습니다. '기존보다 ~한 이유로 인해 개선된 서비스가 있다면 사용하시겠습니까?'는 좀 더 나은 질문이 됩니다. (물론 이것보다 더 정제된 질문이 좋겠습니다)
기획 5. 문제점 정의 및 해결 방안 선정
앞선 단계 중 하나라도 막혔다면 다시 1단계로 돌아가서 시도하면 됩니다. 4단계까지 모두 마무리가 되었다면 최종적으로 해결할 문제점을 한 문장으로 정의하고, 이에 대한 해결 방안을 선정합니다. 앞서서 이미 결정된 사항들이기 때문에 이 단계는 그렇게 어렵지 않을 겁니다.
주의해서 정리할 부분은
문제점이 명확하고 명료하게 표현되어야 한다
해결 방안이 기존에 있는 서비스들과 어떤 점에서 차별화가 되기 때문에 프로젝트를 진행하려고 한다
해결 방안을 도출하기 어려울 때는 문제점에서 발견된 명확한 타겟층이 어디인지 살펴본다.
정도가 되겠습니다.
예시로, 아래는 현재 졸업 프로젝트로 진행하고 있는 냉장고 자동 관리 서비스를 위한 애플리케이션의 기존 시장 조사를 통해 저희 서비스만의 차별성을 도출한 결과입니다.
냉장고 자동관리 서비스를 위한 애플리케이션 차별점 도출 과정기획 6. 해결 방안을 기술적으로 해결할 건지 디자인적으로 해결할 건지 정한다
같은 말이어도 아 다르고 어 다른 것처럼, 기술적으로 해결해야 하는 부분이 있고 디자인이나 문구를 바꾸어야 하는 부분이 있습니다.
예를 들어 노년층에게 문제시되고 있는 키오스크 주문의 경우, 기술적인 문제보다는 주문 UX/UI 가 복잡하고 요구하는 것이 많아 안내가 부족하다는 점이 있죠. 반면 뉴스레터 제작을 하려고 한다면 필요한 뉴스를 스크랩해야 하는데, 매일 수백 개씩 쏟아지는 기사를 하나하나 인간이 확인하기는 어렵기 때문에 키워드 필터 등을 제작해서 구독할 수 있습니다.
이 부분이 결정되고 나면 이제 서비스의 윤곽이 어느 정도 뚜렷해집니다.
기획 7. 서비스 주요 기능과 IA 작성
문제점이 서비스의 목표가 되고, 해결 방안이 서비스의 주요 기능이 될 겁니다. 이제 서비스의 주요 기능에 대해 바운더리를 정합니다.
이때 최소한 이건 있어야 한다! 하는 것들을 먼저 작성하고, 부가적인 기능들을 후순위로 작성합니다. 순위를 정하기 어렵다면 기대효과를 생각해 보는 것도 좋은 방법입니다. 이 기능을 만들었을 때 기대되는 효과가 문제 해결에 어느 정도 영향을 미치는지 생각해 보도록 합시다.
서비스 주요 기능
기능의 목적과 기대효과
를 정했다면, 이를 토대로 IA를 작성합니다.
IA는 Information Architecture의 약어로, 서비스의 구성 요소를 단계별로 표현한 것을 문서로 정리한 것입니다.
이 부분에서 할 말이 좀 있는데, 사실 우리는 주요 기능을 정하고 나면 보통 바로 화면 구성에 들어갑니다. 저도 여태껏 그랬고요. 하지만 IA를 작성하는 이유는, 그렇게 화면 구성을 했을 때 빠지는 것들이 많기 때문입니다. CRUD 중 Delete가 없거나, Create 버튼이 없을 수도 있죠... IA를 작성하면서 팀원들과 화면을 어떤 식으로 구현할지 충분히 이야기를 하도록 합시다.
양식은 검색을 하면 곧장 찾을 수 있습니다. 팀의 상황에 맞추어 적절히 변형해서 사용하도록 합시다.
양식이 있다고 해서 거기에 매몰되지 않으면 좋겠습니다. 아마추어가 전문가와 똑같이 할 수는 없습니다. 학부생의 사정에 맞춰서 팀원 간 의사소통이 되는 정도로 사용하면 됩니다.
저는 아래 글을 참고해서, 다음과 같이 변형했습니다.
참고 : https://smkdir.tistory.com/3
1. Depth (진입 단계)
2. Component (구성요소) : UI 상 즉, 화면구성을 상상할 수 있도록 기준하여 버튼, 내용, 입력필드 등을 작성
3. Description (개요 및 설명) :실질적으로 이루어지는 행위에 대해 작성
4. Featured (기능) : Component(구성요소)와 매칭하여 기능에 대한 구성요소 수립 여부
5. Data (활용 데이터) : ERD에 사용할 테이블 명. 해당 행위가 이루지는 화면의 구성요소에 적용되는 데 사용될 수 있는 데이터
6. Comment (기타 참고사항 비고) : 참고 주의 사항
팁 아닌 팁이라면, IA를 작성할 때쯤이면 데이터베이스 ERD 구성도 할 수 있을 겁니다. 혹시 컴포넌트가 뭔지 모르겠다면, 디자이너 없이 앱디자인 하는 법 파트를 한 번 읽어보시고 작성하시면 될 것 같습니다.
기획 8. 일정 작성하기
이제 프로젝트 마감 기한에 맞추어 일정을 작성하면 됩니다. 저는 아래와 같은 순서로 작성합니다.
팀원 간 각자 해 봤던 부분과 해보지 못한 부분을 구분하기
해보지 못한 부분은 자료 조사 후 어느 정도 걸릴지 가늠해 보기 => 공식 문서 적용법을 읽어주세요
작은 규모의 마일스톤을 두어서 기한마다 구분을 두되, 일정이 밀릴 것을 대비해서 시작과 프로젝트 마감 기한 중간에 1~2주 정도 빈 주간 만들기
팀원 전체의 목표 1개와 개인 목표 1개 따로 두기
매주 각자 맡은 부분 공유하고 피드백받기
마지막 부분이 가장 중요합니다. 현재 저희 팀의 경우 백엔 2명과 ML 1명으로 이루어져 있습니다. ML에 대해서 모르더라도 상대방의 설명을 듣고 이해할 수 있습니다. 어떤 부분이 이해가 잘 안 가는지, 전체 플로우는 어떻게 되는지, 지금 하고 있는 일은 뭐고 다음에 할 일은 무엇인지 정확하게 파악하도록 합시다.
여기에는 (저희 팀의 경우) 2가지 정도의 이유가 있는데,
하나는 상대방의 개발이 어떤 식으로 이루어지는지 알아야 이쪽에서 개발한 부분과 통신할 때의 데이터 형태를 정할 수가 있고
두 번째로는 작은 인원으로 프로젝트를 진행해서 비는 손이 없어야 원활하게 일이 진행되기 때문입니다.
문서 작업은 아무나 할 수 있고, 개발은 각자의 작업 파트가 있습니다. 본인 파트가 빨리 끝나서 문서 작업을 할 수 있는 사람이 있는데 굳이 일을 미뤄서 진행할 필요는 없으니까요.
팀원 간 러프한 역할 분배 (3인 기준)디자이너 없이 앱 디자인 하는 법
앞의 기획 부분이 완료되었다면 사실 전체 프로젝트의 반쯤은 해결되었습니다.
이제 화면을 그려야 하는데... 공대생의 미적 감각에서 예쁘게라는 것이 세간의 인식과는 거리가 있는 예쁨일 수 있죠.
그러니 사람마다 만족도는 다르겠지만, 저로서는 UX/UI는 깔끔하기만 하면 됩니다. 그래도 버튼 등의 배치 자체에 대한 불안감이 있어서, 학교 외부 멘토링을 통해 도움을 받았습니다. 아래는 그를 통해 배운 몇 가지 팁입니다.
컴포넌트 배치 후 화면을 봤을 때 안 익숙하면 좋은 UI가 아님
메인 화면에 기능은 1개-2개면 충분하다. 너무 많으면 정신없음
기존 앱들의 디자인에서 많이 차용해라. 배치나 사용법 등도 케이스 스터디를 해보면 비슷할 것
이미 구현된 디자인 시스템을 사용하고 싶다면, Material.io 등이 편리하다.
여기서 Material.io 는 구글에서 작성한 오픈소스 디자인 시스템입니다. 설명도 잘 되어있고, 웹, 앱, 안드로이드 등 여러 곳에서 컴포넌트를 적절히 배치만 하면 되기 때문에 저희 같은 공대생에게는 참 편리한 도구입니다. 미리캔버스 같은 거죠. 코드도 이미 다 나와있어서 머리 아프게 프론트 구성을 하지 않아도 되는 점이 제일 좋습니다.
컴포넌트란 사용자 인터페이스를 만들기 위한 일종의 블록이라고 보시면 됩니다. 이를 사용하기 위해서는 약간의 공부는 필요한데,
Figma 기초 사용법을 익히고 (대학생이면 교육 인증을 통해 무료로 모든 기능을 사용할 수 있습니다.)
Get Started에서 What's Material, Using Material, Design 파트를 읽은 후
Develop에서 본인이 사용할 도구 부분을 추가적으로 읽어주면 됩니다.
각 컴포넌트 설명은 Component 페이지에 사용 가이드라인과 함께 나와있습니다. 우리가 할 일은 해당 가이드라인 읽고, 기획에서 작성한 IA에 맞게끔 컴포넌트를 적절히 배치하는 것입니다.
https://www.figma.com/resources/learn-design/getting-started/
Material.io Button 가이드라인
졸프 메인 화면 구성 발전 단계공식 문서 적용법 - 플러터 시작하기
이제 슬슬 자기가 융합콘텐츠 학과를 다니는지 컴퓨터공학과를 다니는지 혼란스러울 때쯤, 이걸 진짜 구현하려면 기술을 빠르게 배워야 하는구나를 느낍니다. 게다가 처음 보는 기술이라면 얼마나 걸릴지 알고 일정을 짜나 싶죠.
이럴 때 필요한 것은 작은 규모의 기술 테스트/토이 프로젝트입니다.
IT 프로덕트는 대부분 공식 문서(Reference/doc)라는 게 존재합니다. 특히 플러터를 만든 기업인 구글은 그런 테크 문서에 진심인 기업 중 하나라서, 공식 문서가 무척 잘 되어있는 편입니다. 코드랩 등을 통한 학습 툴도 지원이 잘 되어 있습니다. 개인적으로는 깃의 공식문서를 좋아하지만, 플러터도 읽기 무척 편했습니다.
공식 문서는 대부분 튜토리얼이 존재하기 때문에, 절차에 따라 진행만 해준다면 괜찮은 첫 프로젝트를 실행할 수 있습니다. 이후로는 깃허브와 스택오버플로우, 공식 문서를 뒤지며 코드를 커스텀하는 일이 남지요. 이렇게 새로운 도구에 대한 경험이 어느 정도 쌓이게 되면 새로운 걸 배우게 되어도 어느 정도의 시간이 걸리면 가능하겠다는 느낌이 있습니다.
저는 졸업 프로젝트를 통해 플러터라는 걸 처음 해보게 되었으니, 이를 예시로 들어 설명드리겠습니다. 플러터의 Get-Started에서 첫 프로젝트를 실행해 보겠습니다.
https://docs.flutter.dev/get-started/install
개발 1. 설치
저는 맥북을 사용하기 때문에 MacOS를 골랐습니다. 아래는 MacOS에서 플러터를 설치하는 목차입니다.
공식문서 목차System Requirements
플러터를 설치하기 위해 필요한 하드웨어 등의 사양을 설명하고 있습니다.
읽어보니 Disck Space 2.8GB가 필요하고, 깃이 깔려있어야 하네요. Xcode 설치도 권장하고 있습니다.
제 경우 깃은 이미 깔려 있으니 건너뛰고, Apple Silicon Mac을 사용 중이라, 주의 사항에서 시키는 대로 Rosetta translation 설치를 해 줍니다.
Get The Flutter SDK
이제 플러터 SDK를 받습니다. SDK는 Software Development Kit의 약어인데, 하드웨어 플랫폼 혹은 운영체제, 프로그래밍 언어 제작사 등이 제공하는 애플리케이션 개발 도구 키트 같은 겁니다. 여기도 인텔 칩이냐 애플 실리콘이냐에 따라 조금 달라지네요. 시키는 대로 커맨드 창에 입력해 줍니다.
이때 경로 설정이 잘 안 되어 있다면 문제가 발생할 수 있습니다. 소제목 중 update your path는 그런 문제에 대해 설명하고 있고, downloading Straight from github instead of using an archive는 말 그대로 깃허브에서 바로 내려받아 설치하는 방법입니다.
저 중 Run Flutter Doctor는 읽어보니 플러터가 제대로 설치되었는지 확인하는 도구입니다. 입력해 보니 저는 이렇게 뜨더라고요.
flutter doctor 입력 결과메시지를 읽어보니 안드로이드 스튜디오나 엑스코드 중 하나는 깔아 둬야 하는데, 둘 다 깔지 않아서 붉은 표시가 납니다. 이게 iOS setup 과 Android setup 입니다. 시키는 대로 설치해 주었습니다. 친절하게 명령어도 가르쳐주네요.
Xcode 설치 결과다시 플러터 닥터를 쳐보니 그래도 경고 표시가 뜨지만, 코코아팟이 설치되지 않아서 뜨는 경고입니다. 띄워주는 주소를 타고 가 가이드를 읽어보니 해당 플러그인을 사용하지 않을 거면 굳이 깔 필요가 없어 보여서 일단 설치하지 않았습니다.
개발 2. 에디터 셋업
플러터 개발을 어디서 할 건지인데, VScode, Android Studio, IntelliJ, Emacs 에서 가능하다고 뜹니다.
개발 3. 테스트 드라이브
앱을 만든 후 빠른 빌딩과 실행 등에 대해 설명해 줍니다. 저는 IntelliJ를 사용하기 때문에 해당 부분을 읽어주었습니다.
개발 4. 첫 앱 만들기
에뮬레이터를 돌려 실제 화면을 볼 수 있는 테스트 앱을 만들어보는 장입니다. 외부 페이지 링크, 위젯 사용, 무한 리스트 뷰, 사용자 프로파일과 배포 등에 대한 전반적인 설명을 해주고 있습니다. 필요시 코드랩으로 돌려볼 수 있도록 제공하고 있으니, 일단 공부부터 하고 싶다면 천천히 읽어보는 것도 괜찮겠습니다.
저는 이론보다는 실전 파라서 시키는 대로 단계를 밟아 진행 한 뒤 실행부터 해봤습니다.
튜토리얼 실행 화면애뮬레이터 속도가 조금 느리긴 해도 잘 돌아가네요. 이제 화면 구성과 관련된 코드를 찾아서 손을 좀 봐주면 될 것 같습니다.
플러터의 언어는 Dart를 사용합니다. 낯선 언어긴 해도 자바와 같이 메인 함수를 사용하고 JS와 유사한 점들이 있어 학습에 큰 어려움이 있을 것 같진 않습니다. 일정을 길게 잡을 필요는 없을 것 같네요.
작은 규모의 토이 프로젝트를 진행해 보면서 학습 속도를 가늠해 볼 수 있을 것 같습니다. 겸사겸사 도구에 익숙도 해질 겸요.
토이프로젝트 뷰마치며
여기까지가 전반적인 기획과 디자인, 기술 테스트에 대한 제 경험입니다. 실제로 진행해 보면 학교 팀프로젝트에서 여러분이 진행하게 되는 방식과 거의 동일합니다. 다만 방식에 대해 이름을 붙이고 정의를 해서 매뉴얼처럼 만든 것이고요.
어떤 물건이나 방식을 사용하기 쉽도록 참고하는 문서를 매뉴얼이라고 하죠. '참고'이기 때문에, 반드시 따라야 하는 강제성이 있지는 않지만요. 다만 제가 이렇게 진행했을 때, 망망대해를 헤쳐나간다는 느낌도 덜했고, 아이디어의 순환 자체가 빨랐기 때문에 애용하고 있습니다.
중간에도 말씀드렸지만, 양식에 매몰되어 일의 진행이 방해가 되는 일은 없어야 합니다. 하고 계시는 일을 유연하게 만드는, 약간의 팁이 되는 정도가 딱 좋을 것 같습니다.
다음 글로는 실제 개발을 진행하면서 겪은 의사소통의 문제, 그리고 깃허브 등의 사용법에 대해 적어보도록 하겠습니다.
