앱팀장의 스타트업 개발이야기

앱이나 웹에 너무 많은 텍스트가 보이면

보는 사람의 피로도가 높아진다.

그래서 사용하게 되는 것이 아이콘이다.

좋은 아이콘이라면 직관적이어야 한다.

그 말은 보는 순간 뭐라는 걸

알아차리게 해줘야 한다는 뜻이다.

스케치나 포토샵 같은 디자인  툴을  이용하면

유튜브나 블로그 보고 배우면서 적당히 만들 수 있다.

하지만 직관적인 아이콘을 만들려면

디자이너의 전문성이 반드시 필요하다.

이럴 때, 구글 디자이너들의 전문성을 빌릴 수 있다면 어떨까?

원하는 분들은 "material design"이라는 사이트로 가보자.

링크 - https://material.io/resources/icons

아파치 라이선스 2.0가 적용되어 상업적인 이용이 가능하다.

(apache license 2.0, 라이선스에 대한 내용은 위키에서 확인하시길 - https://namu.wiki/w/아파치%20라이선스)

다양한 아이콘 지원

17개의 카테고리로 구성된 약 2,000개의 아이콘이 무료로 사용할 수 있다.

• Action
• Alert
• Av
• Communication
• Content
• Device
• Editor
• File
• Hardware
• Home
• Maps
• Navigation
• Notification
• Places
• Search
• Social
• Toggle

material design icons의 카테고리 목록

아이콘들은 이미 안드로이드 폰에 적용된 거라 사용자에게도 익숙한 모양들이다.

만약, 비디오 혹은 오디오 플레이어를 만들고 싶은 분들이라면 Av 카테고리를 살펴보면 된다.

5가지의 테마를 제공

Filled - 면으로 구성된 디자인

Outlined - 선로 구성된 디자인

Rounded - 둥글둥글한 디자인

Two-Tone - 두 가지 색상으로 표현하는 디자인

Sharp - 날카로운 모양의 디자인

다양한 사이즈 지원과 앱 표준 사이즈 지원

아이콘은 18dp 24dp 36dp 48dp으 기본 사이즈로 지원하며

아이폰과 안드로이드의 표준 해상도 이미지를 한 번에 다운로드할 수 있다.

다양한 플랫폼 지원

앱뿐만 아니라 웹에서도 사용할 수 있다.

웹에서 되니까 하이브리드에서도 사용 가능할 것이다.

스케일러블 벡터그래픽스(svg) 지원

(스케일러블 벡터 그래픽스 내용은 위키에서 확인하시길

- https://ko.wikipedia.org/wiki/스케일러블_벡터_그래픽스)

큰 사이즈에서 흐려지는 래스터 그래픽스와는 달리 

svg는 큰 사이즈에서도 선명도를 유지한다

색과 크기는 커스텀이 가능

약간의 코딩을 통해 색상을 변경하는 것이

앱의 전반적인 색상과 맞추려면 tint속성을 변경해서 색상을 변경할 수 있다.

크기(width/height) 설정을 통해 가능하다.

결론 

초기의 스타트업들에게는 소소한 비용도 부담이 되는 게 현실이다

초반에 좋은 디자인보다는 

좋은 서비스를 만드는데 집중해보자

그래도 운영하면서 서비스의 성장 가능성이 보이기 시작하면

디자인에 투자해 아이덴티티를 확보하는 것이 좋다.

Ps

.무료는 무료일 뿐

.기획자분들도 기획서를 쓸때 이용하면 좋을 것 같다

fin

프로젝트는 크고 작은 문제들이 숨어 있다.

언제 드러날지는 아무도 알 수 없다.

그런데 개발관련 문제들은 

대부분 런칭 직전에 나타난다.

이걸 팀이 수습하지 못하면

불난 프로젝트가 되는 거다.

3번정도 불을 끈적이 경험이 있다.

생각하기 싫은 기억이지만

지금 이 순간에 화재현장에 있을 분들 위해

정리해본다.

현장답사

사고현장은 정신없다.

팀원들과 미팅을 해보면

자잘한 이야기들이 두서없이 오간다.

주로 방화범 찾는 것에 대한 이야기다.

일단 개발자는 없다.

대표는 얼마나 좋은 건지 설명한다.

팀원들은 불평 불만하기 바쁘다.

이와중에 팀원들의 역할을 파악할 수 있다.

그나마 프로젝트를 기획한 사람은

답답함을 토로한다.

"이 사람이다."

이사람과 이야기해서 풀어 나가야한다.

일단은 포기를 권한다.

그래야 팀에 변화가 생기기 때문이다.

팀을 그대로 두고 개발을 찯다시하는건

같은 실패를 반복할 가능성이 높다.

결과물 확인

눈으로 보면 잘못된 부분이 보인다.

만져보면 빠진 것들을 확인할 수 있다.

그러나 이건 결과이다.

개발은 정보가 유통과정이다.

처음 보낸 정보와 비교 해봐야한다.

그래야 잘 못 도착한 것도 찾을 수 있고

아예 보내지도 않은 것들도 찾을 수 있다.

찾은 걸 파악해보면 만들어져야 할 것과

만든 것을 차이가 나타난다.

이게 "해야할 일"이다.

이걸 엑셀에 정리해서 작업목록을 뽑아낸다.

전반적인 완성도도 검토해야한다.

처음 만들때처럼 기획서를 보고 

TODO리스트를 작성한다.

불끄기 위해 손대야 할 것들은 따로 정리해둔다.

소스확인

코드에는 로직만 있는게 아니다.

팀의 태도와 업무방식도 포함되어 있다.

개발자의 눈으로 코드를 보면 이게 보인다.

그래서 자기가 만든 건 잘 보여주지 않는다.

결과물의 문제가 있던 부분으로 가본다.

여러번 수정한 흔적과

임시로 수정한 부분이 많이 보이는 건

그 만큼 기획이 변경되었다는 거다.

전체적인 구성를 살펴보면

구조가 없는 경우도 있는데

이건 초보자가 만들었다는 의미가 된다.

구조가 일관되지 않은 경우라면

프로젝트가 여러명의 개발자를 거쳤다는 의미한다.

이런식으로 살펴보면

전체적인 문제인지 부분적인 문제를 가릴 수 있다.

이걸 가지고 팀에 알려줘야한다.

"내가 이럴 줄 알았다"라는 이야기가

나오도록 사실대로 알려줘야 한다.

현황공유

절체절명의 순간에도 이성은 있다.

그래서 지푸라기도 잡는거다.

현재 상황을 이야기하면 단체멘붕에 빠지지만

곧 "어떻게 해야할까요?"도 나오게 된다.

대표는 결정해야하는 사람이다.

선택할 수 있는 옵션을 알려주고

장단점을 설명해준다.

"싹 뜯어 고칠까? 이건 이런거야"

"급한데로 조금씩 고칠까? 이건 이런거야"

팀원들과는 협력을 해야한다.

각자의 업무에 맞는 준비할 것들을 알려준다.

이때 업무조정이 안되면

대표와 이야기 하도록 해야한다.

불 끌때 가장 중요한 건 속도다

개발속도에 영향을 주는 방해요소는

제거할 수 있도록 협의해야한다.

해결과정

바닥부터 만드는 방식으로 개발되지는 못한다.

일단 팀을 안정화 시켜야 한다.

이미 개발자에게 신뢰는 없다.

보이는 부분부터 만들어 줘야한다.

조금씩 수정하는 경우에는

화면부터 만들어서 연결시킨다.

코드개선할 시간은 따로 시간을 잡아야한다.

그리고 매주 미팅을 진행하고

미팅시 결과를 확인하고 다음주에 확인할 결과를 알려주며 진행해야한다.

처음부터 만드는 경우에는 

지금까지 만들어진 걸 최대한 살려서

껍데기부터 만들어서 연결시켜야한다.

그 다음에 구조를 잡하서 화면 뒷쪽 코드들을 작성한다.

완성되는 결과물은 라이브로 확인 가능하도록 수시로 전달한다.

어느쪽이든 완성도는 떨어진다.

일정과 고민할 시간이 없기 때문이다.

그래서 프로젝트의 미래따위는 접어두고 작업해야한다.

해야할게 있다면 "여러분들 화이팅" 정도?

후기

불끄고 나면 잔해가 남는다.

잔해를 치우는 건 온전히 팀의 몫이다.

나는 떠나야 하는 거다.

팀이 정이되는 경우도 있었고

앱이 런칭되는 경우도 있었다.

서비스가 별로 개선되지는 못했는데

그래도 1-2년은 그럭저럭 돌아갔다.

불난 프로젝트에 가기 싫은 이유는 

끝났을때 아무도 고마워 하지 않기 때문이다.

그들도 잊고 싶은 기억인거다.

나는 그걸 이해하는데 생각보다 오래 걸렸다.

마무리

그런데 불난 팀에 다른 개발자가 있었다면

원래의 계획대로 진행되었을까?

결국 팀에 모인 모든 사람들이 방화범이다.

마음 먹고 "불내지 말자"라고 생각하면 안된다.

시간쓰는 방법과 사람과 관계하는 방법을 바꿔야 한다.

그래야 작은 불이 보인다.

"이런 거 만들어 보려는데, 얼마예요?"

잘못된 질문은 아니다.

스타트업 입장에서는 외주개발이 그 만큼 가치가 낮은 거다.

개발자의 입장도 마찬가지다.

어렵게 만들어놓은 소스가 돈을 벌어다 주는 것도 아니고 쌓이는 지식을 누가 알아 주지도 않는다.

그래서 적당히 시키고 적당히 만든다

돈만 보면 그렇게 된다.

그런데 외주개발에는 돈만 있은게 아니다

스타트업은 대부분 새로운 걸 만들려고 한다.

새로운 것을 만들기 전에,

외주개발을 선택하기 전에

알았으면 하는 것들을 정리해본다.

새로운 것

세상에는 이미 많은 것들이 존재한다.

그래도 새로운 것들은 계속 태어난다.

이전에 있던걸 더 쓸모있게 만들어지는 것도 

새로운 것에 포함되기 때문이다.

적당히 쓸모가 추가되는 것도 새로운 것이긴 하다.

그러나 동시에 아무것도 아닌 것이기도 하다.

아무도 사용하려 들지 않을 것이기 때문이다.

사람들이 경험하고 "다르네"라는 반응해야

진짜 새로운 것이 된다는 뜻이다.

그런 반응을 하게 하려면

이전 경험보다 나은 걸 제공할수 있어야 한다.

그래서 사용자의 지금까지의 경험을 연구해야한다.

연구를 통해 본질을 파악해서

중요한 개선점을 찾아 내는 것이다.

적당히 보는게 아니라 하나하나 탐구해야한다.

그래야만 다른 사람이 못보는 숨은 10%를 찾아 낼수 있다.

그걸 찾아서 제품에 담아내서

사용자와 투자자에게 가져갈 수 있어야만

겨우 평가받을 자격이 생기는 거다.

만들기

나만 쓸걸 만들때는 대충 만들어도 된다.

불만할 사람이 없기 때문이다.

하지만 다른 사람들이 쓰는 것은

좀 더 제대로 된 걸 만들어 줘야 한다.

조금이라도 불만이 생기면 버려버리기 때문이다.

그런걸 만들려면 좋은 감각이 있어야 한다.

타고 나야한다는 말은 아니다.

뚝딱거려서 만들어 놓은걸

보고 만지면서 훈련시켜서 만들어 낼 수 있다.

훈련에는 실패가 따르기 마련이다..

만든 결과물이 아니다 싶을땐 과감히 버려야 한다.

그리고 다음에 만들때는 반드시 아닌걸 개선해야한다.

적당히까지만 하면 적당한 쓰레기가 된다.

완벽하지는 않아도 쓸만해질때까지는 개선해 나가야한다.

근데 잘 훈련되고 있는지 알수 있냐고?

처음 만들었던 걸 확인 해보면 알수 있다,

부끄러움이 느껴진다면 잘 훈련되고 있는 거다.

좋은 감각이 있어야 좋은 제품이 탄생하는 거다.

실패는 여기에 따라야 할 대가에 불과하다.

이 과정을 통해 쌓은 경험은 좋은 경쟁력이 될 수 있다.

따라 만든 사람들은 모르는 것이니까.

다른 사람과 일하기

혼자 일하면 다양한 일을 하게되는데

그만큼 배우는 것도 많아진다.

대신 일의 속도는 느려지게 된다.

일의 속도를 내려면 한번에 많은 일을 진행해야 하는데

그려려면 팀을 구축해서 일해야 한다.

팀원을 뽑아서 데려다 놓고

"일단 해주세요"라고 하는건

"우당탕탕 일하게 될 거에요"라는 말을 

적당한 표현으로 말 한 것이 된다.

팀이 세련되게 일하게 하려면

팀의 목표를 정해서 

팀원들의 할일을 정해주고

팀원이 만들어낼 결과를 팀의 결과에 반영시키는 방법도 고민해야한다.

개인을 통제해서 일의 흐름을 만들어 내는 거다.

그래야만 팀의 일이 효율적으로 돌아가기 때문이다.

외부와 일하기

외부에 일을 맡긴다는 건

또 다른 내부와 일한다는 의미가 된다.

또 다른 내부에서는 나는 외부다.

서로 통제하지 못하는 존재가 된다는 거다.

중간에 마음에 들지 않는게 생겨도

이래라 저래라 할 수가 없다.

그래서 규칙을 정해놓고 일해야 한다.

"이렇게 합시다"가 아니라.

안했을때 받을 불이익을 정하는 거다.

외부와 일할때는 이런 리스크가 있다.

그래서 외부를 선택할 때는 

그만큼의 전문성을 갖춘 곳을 선택해야한다.

외부가 원하는 성과를 내주면

불만도 사라지게되기 때문이다.

전문성을 확보할 수 있을 만한 사람을 못찾으면

책임 있게 일을 해줄만한 사람이라도 선택해야한다.

대신 느낌오면 정리해야만 한다.

개발은 정보의 유통과정이다.

기획자는 머리속에 있는 걸 말과 문서로 설명한다.

개발자는 이걸 읽고 이해해서 머리속에 넣는다.

개발자의 머리속에 정리된걸 기계에게 번역해서 알려준다.

기계는 번역된 내용에 따라 수행한다.

소프트웨어는 기획자의 머리속의 정보를 

기계에게 전달하는 유통과정을 거쳐 만들어지게된다.

기획자가 잘 못 전달하면 다른 결과가 수행된다.

그래서, 기획자가 직접 소프웨어를 만들게 되면 사고가 없다.

좋은 개발자를 구하면 배달품질을 올릴 수 있다.

좋은 개발자는 기획자의 말을 듣고

유추를 통해 정확히 머리속에 그려낼 수 있기 때문이다.

즉, 어느 정도의 오차는 스스로 수정하는 사람들이다.

그러나 모든 개발자가 좋은 개발자는 아니다.

기획자는 오류를 감안해서 결과물을 통해서만 확인해야한다.

말만 듣고 확인해서는 안된다는 거다.

기계에서만 정확하게 확인해야한다.

그래야 배송사고를 확인하여 개선할 수 있다.

기계는 거짓말을 하지 않는다.

지시를 받으면 받은 만큼만 수행해내는 존재다.

유통과정에 있는 기획자도 개발자도 오류를 만들어낸다.

이걸 생각해서 보내야한다.

마무리

뭔가 만들때 보는 설명서의 내용은 간단하다.

그래서 거기에 담긴 지식과 경험이 보이지 않는다.

하지만 설명서를 만들려면 많은 지식과 경험을 필요로 한다.

외주개발은 설명서를 만드는 방식중 하나로 생각되어야 한다.

그리고 누군가 이 방식을 선택한다면

지식과 경험을 쌓을 기회를 잃는 것이다.

가격, 중요하다

그 누구도 중요하지 않은 거라고 생각하지 않는다.

더 중요한게 있는지 한번만 더 생각해보고

제대로 선택하자.