brunch

You can make anything
by writing

- C.S.Lewis -

by 치킨모임 배진호 Jun 18. 2019

IT직군별(개발,기획,디자인,마케터,대표) 동상이몽

누구나 한번쯤은 일하면서 겪어 볼만한 지독한 이야기...



커뮤니티를 운영하면서 주로 많은 대화에 함몰되고, 또 대화주제나 소통방식을 보고 느끼고 경험한 것들을 정리해 볼까 합니다.


그리고 여기에서 혹시 많은 문제들의 해답.



왜 그들은 떠나는가


왜 한배를 탈수 없는가


왜 소통이 안되는 걸까


어디까지가 배려이고 어떻게 맞추어야 하는가



이 질문에 대한 대답을 조금이나마 찾으시길 바래봅니다.


위 질문처럼, 팀빌딩을 비롯해서 직군별로 팀을 짜거나 사람들을 만나보면 매우 다른 성향들을 느끼게 됩니다. 그리고 그것이 비단 각각의 사람들간의 성향만이 아닌 직군 별로도 약간의 차이들을 경험하게 되는데요.


이런 성향을 어디까지 이해하고 있는지에 따라서 좋은 사람을 만날수도 혹은 그것이 지속될지의 여부도 결정하게 됩니다.


우리는 그렇다면 그 전에 각 직군의 특성을 더 잘 알고 이해할 필요가 있습니다.




아래와 같은 순서로 하나씩 훑어보겠습니다.




성향 > 니즈 > 갈등 요인 > 해결 방안


개발자



성장에 대한 욕망



작년과 올해가 똑같길 바라는 사람이 있습니다만, 과거보다 나아지기 위해서 기술스펙의 성장이나 회사의 이직, 혹은 경험에 대한 갈망이 있습니다.



기술에 대한 욕망



성장에 대한 방정식은 없지만, 기술=돈 다른 사람이 가지지 못한 기술을 가지고 있으면 몸값이 오른다는 것은 주변 사람들을 통해 확인이 가능합니다. 기술을 배우고 싶고 잘하고자 합니다.



사회적 위치에 대한 욕망



사람마다 차이는 있지만, 직급이나 회사의 위치가 성장했을때 보상이 있습니다. 또한 언제까지 주니어라는 이름으로 있고 싶은 사람은 없죠. CTO가 되고 싶고, PM의 역할에 관심이 있을수도 있고, 잘나가고 싶은 마음이 있습니다. 물론 버티다보면 언젠가 빛이 오겠지라고 생각하면서 1년, 또 1년을 지나기도 하지만요.



분위기와 소통방식



갑갑하고 수직 상하관계의 공간은 개발자 입장에서 쥐약입니다. 답답하기 그지없고, 이 직종을 선택한 근본적인 이유이기도 합니다. 자꾸 통제하려고 하고 여유로운 모습이 답답하게 느껴진다면, 개발자는 그 곳을 벗어나려고 할 것 입니다. 어떤 팀들은 영어 이름으로 부르기도 하고, 누구누구 님으로 부르기도 하고, 수석님으로 직급을 통일하기도 합니다. 마치 군대에서 전우님으로 통일하듯이 말이죠. 소통이 가능한 분위기는 개발자가 바라는 성향중 하나 입니다.



개발 문화에 대한 자부심



개발 문화는 좋은 회사라는 느낌이 들도록 만들어 줍니다. 좋은 툴을 사용하는가의 여부도 중요하지만, 의사결정의 방식이나, 일정 조율에 대한 전반적인 부분 등등, 개발자를 위한 문화가 얼마나 있는지가 개발자 입장에서는 중요한 척도입니다. 자율출근이 가능한지, 맥북은 주는지, 릴리즈 환경은 어떻게 되는지 등등


좋은 사수가 좋은 문화인셈이 될때도 있고 말이죠.



좋은 회사에 다닌다는 느낌



좋은 회사라는 조금은 포괄적인 단어에는 많은 의미들이 내포되어 있습니다.


무분별하지 않은 야근, 합리적인 의사 결정(오늘 개발해서 내일 배포하자라던지 하지 않는…) , 디자인 일정과 개발일정이 따로 있어서 퉁치지 않는 기업, 기획이 늦어지면 그에 따라 개발일정이 늘어나지 않는 기업, 내 연차를 마음대로 쓸 수 있는 기업, 휴가를 3일 이상을 붙여쓰는것이 자유로움, 개발 도구들을 개발자가 사지 않아도 됨, 노트북이 제공 등등 좋은 회사의 조건은 매우 정상적인 것부터 시작해서, 조금은 복지같은 느낌까지 다양한 조건들이 있는데요.


이 조건에 얼마나 부합하는가, 일한 만큼은 주는지 등등이 그 느낌을 결정해주게 됩니다.



비젼에 대한 가치



같은일을 반복하는 일은 매우 지겹습니다. 그것이 일이라면 더 마찬가지죠. 프론트만 10년째, 백엔드만 10년째, 퍼블만 10년째, 같은 직종이라고 해도, 같은 일만 하다보면 매너리즘에 빠지게 되어있습니다. 웹을 하는 사람은 앱도 기웃 거리고, API만 만들던 사람은 프론트도 한번 해보고, 그리고 업종도 같은 업종만을 하다보면, 다른 업종에 대한 호기심도 생기기 마련입니다. 앞으로 무엇을 할 것인지, 어떤 포지션에서 어떤 계획이 있는지 명확하지 않다면 곧 흥미를 잃어버릴 것입니다.


회사는 비젼이 있어야 합니다. 성장에 대한 비젼, 개발자 가치를 신장 시켜줄 비젼, 회사가 글로벌하게 뻗어나가고, 그에 따른 보상 체계를 꿈꾸게 해야 개발자도 함께 꿈을 꾸게되어있습니다. 그렇다고 일만 많은게 아니라, 보상에 대한 단계적 절차도 포함해서 말이죠.



역할에 대한 가치



언제까지 막내이고 싶은 사람은 없습니다. 한 회사에 오래있다보면, 한마디로 군번이 꼬여서, 꽤 오랜시간 사수 밑에 있게 되는 경우들이 있습니다. 흐름을 역행하기란 쉽지 않아서, 보통은 10년 단위 이상으로 그 컨셉을 뒤짚긴 어렵습니다. 나쁜일, 안좋은 부분도 계속 되는 거죠. 직급이 올랐다고 해서 변화가 있을듯하지만, 도통 윗사람은 나가지 않습니다.


그렇기에 이직, 창업, 새로움에 대한 꿈을 꾸게되는 것이고, 아무리 좋은 회사라고 하더라도 사표를 내던질 사유는 충분합니다.


대기업에서 나가는 대부분의 사람에게 왜 좋은데를 버리고 가냐 라고 물어보면 다 이유가 있다는 말을 하죠.


그곳엔 못버틸만한 사람들이 있기 때문입니다.



새로움에 대한 열망



새로움은 비단 기술에 대한 것만은 아닙니다. 하지만 오래된 레거시 환경에 있다보면 뒤처지고 있다는 느낌과 오래지 않아 이직 하더라도 별 효용가치가 없어지리란 예언을 하게 되어있습니다.


하지만 이 새로움이 리스크를 부담하겠단 의미는 아닙니다. 안정+새로움, 이게 핵심입니다. 함께하자고 하면서 리스크를 주면 곧 이유를 모른채 떠난 개발자를 발견할 것입니다.



좋은 기기



좋은 회사의 조건에도 나열했지만, 좋은 기기가 있어야 개발도 잘되는 법입니다. 좋은 뷰나, 좋은 사람들이면 금상 첨화죠.



분업화와 포지션에 대한 프라이드



협업에 대해서는 말할 것도 없습니다. 새로움에 대한 이야기를 했지만, 본인의 가치는 본인의 포지션에 있는 것을 알기 때문에, 백엔드에게 프론트를 시키거나, 프론트에게 백엔드 롤을, 웹을 하는 사람에게 앱을 맡기게 된다면, 대부분은 거절할 것입니다. 맡은 바에 대해서 프라이드를 지켜주시고, 각 역할에 대해서 존중이 필요합니다. 만약 각각의 역할을 존중하지 않는다면, 오래지 않아서 갈등이 생길 것입니다.



재택 근무에 대한 인식 변화



예전처럼, 이제는 꼭 회사에 출근하라는 법은 없습니다. 디지털 노마드, 어디서든 근무할 수 있는 것이 개발자 입니다. 따라서, 점차 재택과 상주를 오가며, 업무 환경과 요건들이 바뀌고 있습니다. 글로벌 리모트 근무를 비롯한 다양한 컨셉의 업무 방향성들에 적응해가고 있습니다.


디자이너



업종에 대한 특화



개발자나 기획자도 마찬가지로 업종에 따라 다름이 있지만, 디자이너도 업종별로 다른 성향이 있습니다. 패키지인지, 편집 디자이너 인지 영상쪽인지, 웹디자인인지, 앱디자인이, ux 업무인지에 따라 특화되어 있고, 하는 업무나 일도 다릅니다. 그림을 잘그리는 사람, 색감각이 좋은 사람, 아트가 뛰어난 디자이너, 사장님의 마음을 잘아는 디자이너, 고객의 마음을 아는 디자이너 등등 사람마다 당연한 차이가 있지만, 이런 업종에 대한 이해가 없다면, 모든 디자인에 대해서 동일한 가치로 보고 오해하다가 어떤일이 벌어질지 장담할 수 없습니다. 상대를 모르고 무슨일이든 진행하면 그 결과는 참혹하겠죠.


앱개발을 하려면 그 단가를,패키지 디자인을 하면 그 단가를, 웹페이지 디자인을 맡기시려면 그 단가에 대해서 명확히 알고 접근하는게 좋을듯합니다.



무던한 대표



무던한게 제일 어려운 겁니다. 보통의 사람 찾는게 어렵죠. 디자이너의 소원은 제발, 제발 평범한 사람이 대표가 되었으면 하는 것입니다.


평범하고 노말하면 됩니다.



가치를 이해해주는 대표



디자이너를 뭐, 이것 저것 다하는 사람으로 보지만 않으면 됩니다. 포장 업무부터 경리까지 하는 디자이너까지 ㅠㅠ 현실적으로 어려운 상황에서 말도 못하는 답답한 상황이 많습니다.


디자인이 없으면, 서비스는 말그대로 뼈다귀입니다. 성장도 고객도 디자인이 얻어냅니다. 가치를 모른다면, 상종도 하지 않을 것입니다.



말이 통하는 사람



말이 통하는건 기본적인 소양입니다. 즉, 기본적인 사람의 도리와 예의, 그리고 일정에 대하는 것도 포함되어 있습니다.


2주안에 디자인 가능하냐고 물어보면,…


아무리 급해도, 상식적으로 시안을 뽑아내려면, 정확한 요구사항이 있어야 하고, 선입금은 있어야 더 아이디어가 잘 떠오르는 거죠.



답답하지 않은 사람



제일 답답한건 말해도 잘 모르는 겁니다. 설명해줘도 이해를 못하는 상황, 꼭 현대적인 트랜드에 익숙할 필요는 없어도, 디자인 퀄리티가 떨어지는데 자꾸 컨펌 되고 하면, 더 잘해줄 의욕이 사라집니다. 무엇이 좋은 디자인인지 최소한 많이 보고서 옳고 그름에 대한 기준이 많아져야 합니다. 그래야, 답답하지 않게됩니다.


디자이너가 제일 힘들어하는건, 이게 내가 했다고 말을 못하겠다는 상황입니다. 포트폴리오를 만들고 싶어도, 컨펌된 프로젝트를 포폴로 못꺼내겠다고 느낄때의 그 참담함…


그리고 글씨 크게 해달라고 해서 기껏 짜놓은 글자와 간격을 다 무시하진 말아주세요. 글씨 크기 하나도 다 디자인입니다.



소통이 되는 느낌



비슷한 표현이지만, 개발자든 기획자든 함께 일을 할때, 척척 맞아떨어지는 그 느낌, 그 RGB 값만 불러주면 디자인을 알아서 바꾸어 준다던지, 가이드를 주면 다시 되물어보지 않는다던지, 제플린 같은 소통 도구를 잘쓴다든지! 디자인의 업무에만 집중할 수 있도록 많은 요인들이 소통이 된다고 느끼게 만들어주고, 업무를 업무답게 처리한다는 느낌을 줄 수 있습니다.


규칙도 없고, 규격도 없이 처리하다가 반복되는 수정 작업은 지치는 요인입니다.



업에 대한 존중



개발직군에 올인한 기업의 경우, 디자인 직무가 없거나 소외되거나, 혹은 평가가 적은 경우도 있습니다. 투자받고 성장하는 많은 기업들이 디자이너에 대한 재평가를 내리고 더 좋은 대우로 사람을 뽑지만, 여전히 많은 기업들은 지속적인 디자인 컨셉을 유지하는 것이 아니라, 앱&웹에 대한 규격과 틀정도를 다 만들고 나면 더이상 디자이너가 할 일이 없거나 역할이 없다고 말하곤 합니다. 그러다보면 디자이너 입장에서는 인하우스 업무와 에이젼시 업무같은 큰틀에서의 고민을 하게되는데, 그것은 좋은 서비스를 만드는 고민으로 이어지는 것이 아니라, 찍어낼 것인지, 하는 일 없는 곳으로 갈 것인지에 대한 두가지 선택의 기로가 되게끔 상황이 유도 됩니다.


실상은 하나의 서비스도 계속적인 변화에 따라 리뉴얼하고 성장해야 하는데 말이죠.


개발은 계속 바꾸는데, 디자인은 거의 유지되는 것이 그 이유입니다. 더 깊은 생각과 고민을 하게끔 이 업종이 만들어주지 않네요…



후려치기 금지



크× , 위시× 등등 좋은 서비스가 많지만, 단가 자체가 평준 하향 되면서 벌어지는 웃지못한 사태들이 많습니다. 5000원, 10000원대에 작업.. 그리고 퀄리티를 보장할수 없는 일. 그에 따라 의뢰자도 재작업을 하게되면서 발생하는 누수들이 생긴다는 점입니다. 가격에 대한 정의가 모호해짐에 따라서 의뢰하는 사람은 정확한 가격에 혼동이 오게되고, 그래서 좋은 퀄리티의 작품을 얻지 못하게되는 악순환이 계속됩니다.


퀄리티를 얻으려면 상호 신뢰를 보증하고, 그에 대한 가치도 인정해야만 합니다.



포토샾과 일러스트도 구분 못하는 사람 경멸



지식이 아니라 기본에 대해서 말하고 있습니다. 조금 더 공부하면 소통이 수월해 집니다.



잦은 수정과 반복 경멸



보통 요청자의 경우 머릿속이 하얀 백지상태로 설명하기 마련입니다. 이제 디자이너의 역할은 심리학 박사. 여기서 부터 문제가 시작됩니다. 계속 원치않는 방향이라면서 재작업이 들어가다보면 모든 것은 시간이라는 비용으로 변경됩니다. 요청자가 밑그림은 그릴줄 알아야 작업 결과도 퀄리티가 생깁니다. 뷰가 같아야 겠죠. 보는 것이 다르면 빙빙 돌게 되어 있습니다.



컨펌에 대한 갈망



.final


.final.final 이렇게 마지막이라는 의미심장한 파일을 계속 본일이 있습니다. 컨펌같지만 컨펌같지 않은 계속적인 수정과 끝없는 요구사항에 지치는 경우들, 자잘하고 끊임없는 변경 사항에 이제 계약 조항으로 수정 제한 계약이 없으면 일을 진행하지 않는 경우도 생기고 있습니다.



연봉 안올려줌에 대한 분노



보통 1년이 지나거나 연차가 쌓이면 응당 점차 다음에 대한 기대를 하기 마련입니다. 이게 업계별로 직군별로 큰 차이가 있긴 하지만 초봉이 적은 경우는 연차가 쌓일때 큰폭은 아니더라도 어느정도의 상승을 기대하기 마련입니다. 이조차 되지 않을때, 탈출을 시도하는 일은 매우 정당합니다. 요새 블랙리스트를 고르는 법중에 하나는 직원을 자주 뽑는 기업을 눈여겨보라고 하곤 합니다. 마찬가지로 연봉 상승 폭이 낫다면 당연지사 직원이 오래 못버티겠죠.



대표 눈치 없음에 대한 분노



직군에 대한 이야기만 그런 것은 아닙니다. 여느 직군이나, 이런 애로사항은 있습니다. 눈치의 종류는 다양합니다. 문제는 노동의 강도에 대한 눈치가 없는 경우입니다. 릴리즈 시점, 혹은 일의 배분, 퇴근 시점에서 일을 던진다던지 하는 여러 가지 부분은 무심코 던진 돌에 개구리 죽는 다는 속담을 여실히 증명합니다.


야근이 잦아지고, 늦은 퇴근을 당연하게 여기는 문화는 점점 회사에 대한 부정적인 인식을 쌓게합니다. 회사의 입장에서야 당연, 헌신적인 직원을 좋게 평가하겠지만 말이죠.


장기적으로 건강하고 건전하고 오래가려면, 휴식의 질이 얼마나 되느냐에 따라 업무 효율이나 더 좋은 질로 화답한다는 것에 한 표를 걸어봅니다.



커리어 패스에 대한 고민



개발이든 기획이든 디자인이든 늘상 고민되는 것은 커리어 패스입니다.


특히 웹쪽 디자인 업무만 했다면, 앱디자인 경험에 대해서도 관심이 있고, 인하우스 업무만 했다면 에이젼시에서 실력을 쌓아보고자 하기도 합니다. 그리고 작은 기업이었다면 큰 기업에서의 업무 프로세스를 경험해보고 싶고 대기업의 연봉에 대한 갈급함도 여전합니다. 또 주변에 프리랜서나 외주로 다른 부수입들을 보고 있노라면, 회사의 일 이외에도 다른 커리어들을 쌓아서, 더 높은 곳을 보고자 하는 것. 디자이너도 꿈꾸는 것은 좋은 커리어 패스를 쌓는 것입니다.


UX 직무에 대해서도 관심을 가지고 확장하는 디자이너, 퍼블리셔의 직무까지 확장 하는 디자이너.


딱 디자인에만 집중하고 그 가치를 인정 받는 디자이너 등등 다양한 개인적이고 개별적인 커리어 패스가 있습니다. 누구나 다양한 업무를 하고 싶어하는 것은 아니고, 또 누구나 하나만 하고 싶어하는 것도 아닙니다.(각자의 길에 존중이 필요)



디자인 외 업무에 대한 실망



디자이너라면 응당 디자인을 해야하지만, 그렇지 않고 다른 업무에 치이는 경우들도 있습니다. 팜플렛이나 광고에 쓰이는 디자인만 뽑다가 문득, 이러다가 이것만 하는것 아닌 가 싶은 회의감이 들기도 하고, 어떤 의사 결정에 디자이너의 디자인 역량이 더 힘을 실었으면 싶은데 기획자의 입김이나 생각에 휘둘리며, 디자이너가 주도적으로 할 수 없다는 생각 때문에 직접 디자인 한 것을 실행해 보고 싶은 경우도 많습니다.


이런 연유로 개발자와 콜라보가 맞는 경우들도 종종 있습니다.


기획자



좋은 사람에 대한 갈망



누구나 좋은 사람에 대한 갈망이 존재하지만, 기획자가 어떤 위치에 있느냐에 따라서 더 좋은 사람에 대한 갈망이 있습니다. 특히 직군의 특성상, 기획자가 개발이나 디자인을 직접할 수 없는 노릇이기 때문에, 아이디어나 브레인 스토밍을 하는 곳이면 기획자는 더 좋은 사람을 만나기 위해서 발품을 팔게 되어있습니다. 잘하는 개발자, 컨셉있는 디자이너를 만날때 시너지가 나는 법입니다. 기획의 롤은 아이디어만 있는것이 아니라, 좋은 아이디어를 구체적으로 구현해 본 경험에 기초해서 좋은 기획자라는 이야기가 나오게 되고, 결과적으로 좋은 사람을 만나게 됩니다.



기획툴을 뭘로할지에 대한 고민



기획자로써 개발자에게 업무를 전달할때 늘 고민하는 부분입니다. xls로 업무리스트를 작성해서 넘길 것인지, 지라나 컨플루언스 같은 업무적으로 스케쥴 및 업무 하달이 가능한 곳인지, 그렇지 않으면, PPT 로 작성해서 넘길 것인지, 아니면 회사에 기획서 툴이 따로 마련되어있거나, 양식이 정해져있든지, 이런 사소하지만, 기획툴이 무엇인지 그렇게 중요하지 않더라도, 이런 양식이 무엇인지에 따라서 효율이 달라지고, 기획자로써는 많이 고민되는 요건중에 하나입니다.



잡다함에 대한 혼란



잡다함이란 다른것보다, 개발자들도 여러가지를 할 때 잡부라는 표현을 쓰지만, 특히나 기획의 롤의 경우는 PL, PM, 업무관리, 일정관리, 아이디어 제공, 기획서 구현, 업무 플로우 구현, R&R 정의, 라이브러리 조사, UX 조사, 설문, 개발자의 기호조사, 디자이너의 기호조사, 일정 조율 등등 하는 역할이 매우 다양하고 세분화 되어있습니다. 때로는 기획서 한번 건드려보지 못한 기획자도 있고, 전략기획이라는 또 새로운 파트에 있으면서 사업 기획이나 전략만 연구하는 경우도 있습니다. 원하는 기획 영역이 있더라도, 이것이 서비스가 달라지거나 업이 달라지는 순간, 완전히 하는 역할도 틀려지기 때문에 과거에 있던 경험들이 무조건 도움이 되지는 않습니다. 다만 다양함과 다양한 사람들을 거쳐오면서, 소통의 스킬은 다른 직군에 비해서 월등하게 높은데요. 그만큼 정체성을 찾아가는 것이 어렵습니다.



뭐든 하게됨



위 내용에 이어서, 기획자로써 어떤 역할에 국한되지 않습니다. 다양하게 합니다. 때로는 대표가 기획의 역할을 하기도 하고, 기획자가 대표가 해야할 많은 고민들을 대신하기도 합니다. 또한 개발자들이 해주리라고 생각했던 화면의 구성과 화면 기획의 역할들도 기획자가 응당해야 하다보니, 만능이 되어가게 되어있습니다. 기획자들은 이런 상황들에 자주 직면하다 보면서, 직접 개발하는게 속편할 것 같다는 생각을 가장 많이 합니다. 개발자에게 시키기 미안하고, 돈이 들어가는걸 보고 있노라면 답이 안나오니, 개발을 안해보았지만, 계속 이 생각이 맴도는 거죠. 정말 그렇게 오래 걸리나? 이런 생각 말이죠.



UX 단어가 가져오는 파장에 대한 고민



사실 디자이너나 기획자나 마찬가지 입니다. 고객에 대해서 분석은 늘 있어왔습니다. User eXperience . 사용자 경험에 대하여 분석하라는 것인데, 문제는 늘 과도함입니다. 사용자의 경험을 분석하고 적용하는 것은 응당 당연한 일이고, 그것을 해야만 서비스는 고도화 되고 성장할 수 있습니다. 문제는 이 것이 포장되어왔고, 학습과 교육으로 이 사용자 경험을 대폭 향상 시킬 수 있을 것이라는 기대감 때문에 기획자에게 가중되는 업무들이 생겨나게 된 것입니다. 대표가 이 단어에 꽃혔다면, 사용자 경험에 대해서 증명해보라는 것을 할 것입니다. 기획자는 할일이 정말 많습니다. 갑작스럽게 설문도 해야하고, 이 설문도 유저 기반에 따라 작성해야 하고, 또 그리고 증명하기 위해서 사용자 입장에서 다시 설계, 다시 수정해야 할지도 모릅니다. 어쩌면 당연한 절차이고, 기획에 있어서 고민이 없이 무엇인가를 만들었다면, 다시 해야하는 일일지도 모릅니다. 하지만, 이 단어 때문에 디자인도 엮이면서 피곤해 진 사람들이 있는건 또 사실이 아닐까 생각해 봅니다.



대표와의 갈등



개발의 롤이든, 디자인의 롤이든 대표랑 커뮤니케이션 접점에 있는 사람들은 갈등의 상황이 오기 마련입니다. 따라서 기획자가 대표랑 갈등하는 부분이 대수롭지 않게 받아들일 수 있지만, 기획의 입장에서는 업무를 전달하는 입장이 많기 때문에 대표와의 갈등이 가장 심할 경우가 많습니다. 특히나, 대부분은 대표의 입장에서 개발자나 디자이너에게 시간을 주지 않는 경우가 많지만, 개발의 입장과 디자이너 입장의 생각을 해주는 기획자들의 경우 일정 부분을 위해서 대표에게 총대를 메기도 합니다. 사실 이렇게 총대를 메는 기획자가 있다면, 개발자나 디자이너의 신뢰를 얻는 경우도 많습니다. 하지만 쉬운일은 없죠.



고래싸움에 새우같은 느낌



개발자의 입김이 쎈곳, 대표의 입김이 쎈곳에서는 기획자는 능수능란할 필요가 있습니다. 하지만 이 업무 일정간의 간극이 도저히 좁혀지지 않는 경우는 이 모든 책임에 기획자 탓이다라는 괴상한 논리에 빠지게 됩니다. 결국 뭔가 책임도 없고 권한도 없는 상황 때문에 뭔가 회의감이 드는거죠.



생각은 많으나 정리가 안됨



대표의 입장을 정리하는 경우는 오히려 깔끔합니다. 정리하고 보여주고 확인 받으면 됩니다. 그리고 좋은 모델들을 찾아서 분석하고 얻을것과 버릴 것은 취하면 됩니다. 헌데 새로움을 요구하거나, 직접 아이디어를 가지고 뭔가를 기획해야 하는 경우, 정리에는 어려움이 있습니다. 개발자의 경우는 되는 것과 안되는 것에 대한 명확한 생각이 있기 때문에 미리 안된다. 설정하고 가는 경우가 많지만, 기획자의 경우는 그런 제약이 없기 때문에 이것저것 생각해서 구현되기 전에 이미 서비스의 성공을 예단하는 경우도 많습니다. 디자이너의 경우는 아이디어를 들을때 해당 서비스가 보이는 구체적인 부분을 고려하기 때문에 이게 한화면에 모두 담을 수 없는 서비스, 하나에 집중할 수 없는 서비스, 웹인지 모바일인지 각각의 케이스에 따라 달라지는 디자인에 대한 생각들로 정신이 없지만, 기획자는 이 아이디어들이 마구마구 커져가는것을 막기가 쉽지 않습니다. 따라서 기획자의 경우 많은 사람들과 이야기를 토대로, 되는 것과 안되는것, 그리고 할 수 있는것과 할 수 없는 것들을 구분해 두고, 하나씩 열어가는 방식을 택하는 것도 좋은 방향성을 가질 수 있다고 봅니다.



수시로 바뀌는 의사결정에 대한 회의감



기획자는 설득을 절묘하게 잘해야 합니다. 대표의 마음을 사로 잡아야하고, 개발자, 디자이너의 마음을 사로 잡아야 합니다. 하지만, 의사결정은 대표가 내리기 마련이고, 외부활동을 많이 하는 대표의 경우는 다양한 새로움을 접하기 마련입니다. 물론 기획이 바뀌는 경우 전체적인 일정과 리스크라는 판단을 하고 정확하게 지시하고 기다려주는 경우도 많이 있지만, 그렇지 않은 경우라면, 그것을 중간에서 설명해야하는 기획자의 경우, 한마디에 많은 기획 전체가 흔들리는 것을 경험하게 됩니다. 그리고 이것이 반복되면, 기획의 재미보다는 기획에서 오는 피로감과 잦은 밤샘, 회의감이 들기 마련입니다.



찍어내기 식의 기획때문에 고통 받음



기획이라고 하면, 좋은 기획, 좋은 회사들에서 좋은 컨텐츠나 서비스들을 만들어서 잘 나가는 모양들을 보면 기획자라는 직군에 대한 환상이 있기 마련입니다. 하지만, 에이젼시, 혹은 뭔가 기획이 비슷비슷한 경우, 찍어내기식의 기획을 하기 마련입니다. 로그인 페이지 — 메인화면 — 상단 GNB — 메뉴에 들어가는 내용들, 게시판 작업, 이미지 게시판, 일정 관리, 개인화 작업 등등 이 모든 작업들이 비슷비슷하다는 생각을 하게 되고, 새로운 것을 하고 싶은 마음으로 기획에 참여했지만, 찍어내는 느낌 자체는 기획 직군에 대한 회의감에 들게 하기도 합니다. 물론 기획의 영역이 너무나 많기 때문에 매일 새로운 경우도 있지만 말이죠.



디자이너와 일정 협의 후에 개발자와 일정 협의하다보면, 개발자나 기획자는 맨날 논다고 생각하는데 정작, 둘다 바쁜 타이밍이 껴서 쉴틈이 없음



기획자의 억울함입니다. 개발자의 입장에서는 기획이 기획서를 전달하고 나면 논다는 느낌이 드는 경우가 많습니다. 기획자의 입장에서는 더 짧은 시간에 기획서를 만들어야 하기 때문에 기획의 시간을 거의 0에 수렴하도록 하기 위해서 밤을 새야 하는 경우들이 있습니다. 개발의 시작이 늦지 않도록 하기 위함입니다. 그리고 나서 개발이 시작되기 위해서는 디자인을 위한 컨펌 작업도 필요합니다. 당연지사 디자이너에게도 일정을 짧게 주고 그 디자인을 기다렸다가 개발자에게 전달하기 마련인데, 이 두 업종이 바쁜 타이밍이 다릅니다. 하지만 기획자는 두 업종과 커뮤니케이션을 해야하는 이 모든 시간이 야근으로 다가오게 됩니다.



기획롤이 없는 경우 당혹



기획이 중요해지는 시대, 당연지사 모든 업종과 모든 회사에 기획의 롤이 있어야 하리라고 생각하지만, 기획자가 많은 것은 마치 머리가 많은것과 같습니다. 따라서 회사에서는 기획자가 몇안되거나 PM이 기획의 역할을 대신하거나, 혹은 경우에 따라서는 기획의 롤이 아예 없는 경우도 있습니다. 그리고 원하는 직무나 생각과 달리 하는 역할이 다르기도 하고요. 따라서 이직을 하려고 했는데, 그 회사에 아예 그 직무나 롤이 없는 경우도 있습니다. 그래서 이직할 때도, 원하는 회사가 있어도 직무를 찾아내야 하거나 기획 직군의 필요성을 어필해야 하기도 합니다. 이런 경우 매우 당혹 스럽다고 할 수 있습니다. 지금은 조금 더 전문성의 영역이 있어서 큰 기업의 경우 필요하지만, 때에 따라서는 과감하게 없애는 기업들도 있다고 하니 고민이 많겠죠.



가치를 인정 받기 위해선 끊임 없이 어필해야함



기획자가 기획의 가치를 인정 받기 위해서는 자신에 대한 어필이 필요합니다. 이게 특히나 산출물의 경우는 눈에 보이지만 기획은 눈에 보이지 않기 때문에 기획서만으로는 그 가치를 인정받기가 어렵습니다. 따라서 서비스의 성장, 서비스의 성공, 이 사회적 가치와 네임벨류등등 대표가 자신을 어필하듯, 기획자도 자신을 어필해야 하는 경우가 많습니다. 강연이나, 강의 같은 일에도 관심을 가져야 합니다.


마케터



영업과는 다른 직군



마케팅은 영업과는 다른 직군입니다. 어떻게든 이 서비스, 회사를 알리기 위해 다양한 방법을 선택해야 합니다. SNS 를 활용하기도 하고, 마케팅 도구나 광고를 태우기도 합니다. 구글같은 광고 도구나 유투브 같은 도구들이 많아졌기 때문에 마케팅 업종은 확실히 차이가 많아지게 되었습니다.



컨텐츠를 만드는 경우가 많음



마케팅을 하다보면 컨텐츠를 만들어야 하는 상황이 많습니다. 홍보를 해야하는데, 홍보 문구를 정한다던지, 팜플렛이나 광고를 태우기 위해서 해당 스토리에 대한 카드뉴스를 만들어야 한다던지 등등 서비스를 알리기 위해서는 많은 것들을 고려해야 하기 때문입니다. 이렇게 컨텐츠가 살아 움직이게 하고 서비스가 성공에 이르게 하기까지는 많은 비용이 들고 많은 고민이 들어가기 때문에, 보통은 컨텐츠를 위주로 서비스나 제품들을 홍보하게 되어있습니다. 따라서 디자이너와 협업할 일들이 많고, 만약 디자이너가 없는 회사의 경우는 이 역할까지 마케터들이 감당하는 경우들이 많습니다. 이런 요인들이 갈등 요인이 되기도 합니다.



페북,인스타,유투브 등등 마케팅 도구가 너무 많음



예전에는 광고한다고 하면, 버스에 붙이고, 옥외 광고를 하고, 간판을 만들고, 지하철이나 학교에 붙이고, 벽보로 붙이고 하는 광고들이 많았습니다. 아직도 게임 광고나 큰 회사의 광고의 경우는 버스의 밖이나 안에 광고를 하는 경우도 많지만, 사람들의 패턴의 변화(주변을 보는것보다는 핸드폰을 보고 걸음) 로 스마트폰 안에 있는 주요 점유하는 기업들이 광고툴을 사용하게 되었고, 그 것에 대한 사용방법의 익숙함에 따라서 그 마케팅 도구를 잘 사용하는 기업들이 빠르게 성장할 수 있게 된것입니다. 이런 변화에 따라서 단순한 2D 형태의 광고보다 이제는 움직이는 광고, 사람을 쓰는 광고, 유투브 광고와 같이 제품 광고도 실제로 사용 경험에 대한 광고가 많아지게 되었고, 마케터는 그 영역까지도 계속 주시해야 하는 상황이 되었습니다.



돈 안주면서 마케팅을 어떻게든 하라는 대표 때문에 난감



대표의 입장에서 마케팅을 시킬때 간단하게 하는 생각은 마케터를 뽑으면 그 마케터를 뽑는 비용만큼의 마케팅이 될 것이라는 생각입니다. 하지만 실제로 마케터의 경우는 마케팅 비용이 있어야 효율을 낼 수 있습니다. 어떤 방법이든 집행 비용을 집행하는 방법을 잘 고민해주는 사람인 셈이지, 그냥 그 마케터 자체만이 가지고 있는 파워가 큰 경우는 드물다는 것입니다. 물론 페이지 운영자라던지, 자체 맨파워가 강한 사람을 섭외하는 경우는 번외입니다. 대부분의 경우는 마케터를 뽑더라도, 어떤 기존의 마케팅으로 성공 사례가 있더라도, 무에서 유를 창조하는 경우는 드뭅니다. 헌데 그렇게 생각하고, 돈을 주지 않고 마케팅을 하려고 시키는 경우는 너무 머리가 아픈 경우아 아닌가 싶네요.



타겟 광고를 하는데 그외 다른 마케팅을 할려고 해도 돈이 없음


마케팅을 해서 어떻게든 서비스를 올리려는데 마케팅 도구의 로직이 변하면서 잘 안되는 경우가 다반사



페북과 같은 경우, 인스타의 경우도 계속 마케팅 로직이 변합니다. 또 네이버 상위 노출 로직도 꾸준히 바뀝니다. 기업 위주가 아니라 개인 위주로 바뀌면서 광고에 대한 정책들이 바뀌는데 이것을 꾸준히 접근하고 바라보아야 그것을 체감할 수 있습니다. 그렇기 때문에 이런 마케팅 도구의 로직이 변하면, 기존에 잘하던 마케팅 자체도 또 바꿔야 하고 변해야 합니다. 이런 부분이 어찌 보면 또 다른 새로운 리스크이며, 새로운 방식의 마케팅을 고민해야 하는 마케터의 숙명이 아닌가 싶네요.



마케팅이 이제 동영상도 만들어야 하니까 온몸이 힘듬(이젠 인플루언서가 되어야 할판)



이제 동영상도 간섭해야 합니다. 실상 동영상 하나는 제작하기 위해서 드는 비용은 천정 부지입니다. 2000 ~ 4000… 광고 스탭을 비롯해서 장소 섭외, 하다못해 연기자에 간식에 식사 비용까지, 일반 동영상을 빼고 그냥 영상처리로 하려고 해도, 광고 영상을 찍거나 만드는 비용은 예상외로 너무 비쌉니다. 이런 의뢰를 하려다보니, 동영상도 만들어야 할 것 같고 이 비용 청구도 어렵고 그래서 마케터의 입장에서는 이런 비용에 대한 정리, 가격 단가에 대해서 고민을 많이 할 수 밖에 없습니다.



GA 분석을 하라고 하는데, 세팅은 개발자가 해줘야한다.



구글 애널리틱스를 사용하라고 하는데, 세팅도 안되어있는 서비스도 많습니다. 이것을 하려면 또 개발자에게 부탁해야 합니다. 그리고 세팅한다고 해도, 이것이 그냥 처음에는 키워드 유입인지 어디서 서비스에 유입되는지 비교 분석밖에 되진 않습니다. 어디에 포커스를 잡고 또 어떤 부분에서 유입을 확대시켜야 하는지 고민하려고 하면, 실제로 경험한다고 해도 쉽지 않은 부분들입니다. 하지만 하라면 해야겠죠..



SEO 공부를 하고, 수업을 듣는데 어쩌라는 건지 잘 모르겠다.



SEO 관해서 해야 한다는 이야기는 많이 듣습니다만, 이것이 진짜 마케터가 할 수 있는 영역일까요? SEO (검색 엔진 최적화) 방식에 대해서는 개발자가 해주어야 하는 부분이 많습니다. 마케터가 공부한다고 이걸 적용하기에는 무리수가 있는것이죠. 우선 og 태그를 비롯해서, 서비스가 프론트와 백엔드로 분리 되면서 동시에 프론트의 로딩 속도도 빨라야 하고, 또 그리고 네이버 웹마스터 도구나, 구글 웹마스터 도구에 대해서도 알아야 합니다. 그리고 이런 설정은 개발자와 협업을 통해서 할 수 있는 경우가 많습니다. 사실 개발자 입장에서 이런 저런 신경을 쓰기 어려운 경우도 많고 서비스 런칭을 하기 위해 해야할 부분이 너무 많기 때문에 이것을 애초 고려해서 만들고 있지 않을지도 모릅니다. 이걸 마케터가 어떻게 해야한다고 말할 수 있을까요?



대표에게 계속 잘되고 있고 잘될꺼라고 말해줘야 한다.



마케팅 입장에서는 당장의 성과가 보이지 않을 수 있습니다. 대표 입장에서도 어제의 성과 오늘의 성과 당장의 마케팅이 성과로 지표로 나오기를 바라기 때문에 빠르게 뭔가 보이지 않으면 불안에 떨기 마련입니다. 돈이 들었는데, 결과가 없을때의 불안함. 그래서 마케터의 입장에서는 대표에게 늘 믿음을 심어주어야 합니다. 물론 결과는 확언할 수 없지만, 많은 실험을 해야 하고, 그런 광고 단가와 도출되는 그 결과에 대한 결과치를 수치화 해서 대표에게 보여주어야 합니다. 그것이 잘 되는 경우, 광고를 계속 투입하더라도 이익이 나는 이익 관점의 광고가 될 수 있을테니 말이죠.



뭐라도 성과를 내려고 고민이 많다.


운이 좋아서 잭팟처럼 컨텐츠가 하나 터졌는데 다음 컨텐츠는 그게 잘 안된다. (뭐가 잘되는거고 안되는건지 잘 모르겠다)



마케터 입장에서 돌아다니는 짤중에 하나는 그냥 고양이 사진과 개사진이 낫겠다. 뭐 이런 부분이 있습니다. 아무리 인기있는 컨텐츠를 만들어도 그냥 고양이, 개 사진처럼 범용적이고 널리 알려져있는 컨텐츠보다 만들기 힘들다는 것입니다. 잭팟은 우연의 경우가 많고, 실제로 이렇게 컨텐츠를 만들어 하기는 너무 어렵죠.


스타트업 대표



아이디어만 있는 경우가 많음



수많은 잘나가는 대표님은 제외입니다. 이제 회사에 찌들었거나, 이제 새로운 파도를 맞이 하기 위해서 발품을 팔고, 더 이상 가만히 있진 않겠다고 생각하며, 이제 꿈을 꾸기 시작하는 많은 분들, 아이디어가 있고 실행 계획에 특화되지 않은 분들이 많이 있습니다.



뭐든 처음인 경우가 많음



그러다보니, 다양한 업종에 시작을 할 때 처음인 경우가 많습니다. 누구나 처음은 있죠. 다만 이 시행착오를 함께 견디고 싶다고 느끼는 사람은 많이 없습니다. 다만, 이미 겪은 시행 착오 이후에 성숙한 사람을 만나고 싶은것이 사람들의 마음입니다. 처음으로 디자인을 하려고 하다보면 요구사항이 정의 되지 않았고, 처음으로 기획서를 작성하다보면, 고려하지 않은 수백가지 사항들이 나오게 됩니다. 아이디어에서 꼭 필수라고 생각하는 기능들은 수백 수천만원이 들어간다고 해서, 제외되는 경우도 많고, 개발자를 섭외하면 1사람만 섭외하면 될꺼라고 시작했다가, 백엔드니 프론트니 퍼블리싱이니 앱개발이니 점점점 고려해야할 사항이 많아지다보면서, 큰산을 만난것 같은 느낌이 드는 경우도 많습니다.



돈이 없는 경우가 많음



대게 꿈은 누구나 꿀 수 있으니까요. 다만, 이미 정부에서 투자를 받았거나, 다른 기보나 신보, 혹은 잘된 팀빌딩으로 투자를 받고 시작하는 경우는 좋은 시작인 상황입니다. 아예 아이디어 외에는 마음만 있고 뜻만 있고, 아무런 요건이 없이 시작하는 상황이 많습니다.



투자를 받은게 처음인 경우도 있음



돈이 없더라도, 아이디어가 절묘하게 잘맞고, 시장에서 요구하는 느낌이어서 투자를 받았다고 해도, 그것이 투자까지를 설계하고 시작한 경우보다는 어쩌다보니 투자를 받게된 경우도 많습니다. 준비하는 사람이 훨씬 더 우위에 있지만, 준비되지 않고 투자를 받아서 투자금을 어디에 집중해야 할지 모르고, 서비스의 홍보인지, BM 에 투자할 것인지, 사람에 투자할 것인지, 건물에 투자할 것인지 등등. 소모되는 금액을 감당하지 못하고 회사가 단명할 수도 있습니다.



돈을 어떻게 써야 성장하는 지 모르는 경우가 많음



해답은 없습니다. 다만, 성장에 대해서는 각각 큰 기업들은 전략이 있습니다. 페북이나 MS나 삼성, 구글, 애플 등등 그 기업들은 지금을 보는 것이 아니라, 다음을 봅니다. 지금에 투자하는것 이상으로 다음을 바라보지만, 이제 시작하는 기업은 눈앞에 것들에 집중하게 마련입니다. 일단 서비스를 만들자, 이것에만 집중하고, 다음 스탭을 보지 못하면, 만들기만 하고, 운영되지 못하는 경우가 다반사일것입니다. 성장에는 공유를 시키든, 바이럴 전략을 사용하든, 노이징을 비롯해, 강점을 가지고 시장에 흥정할 수 있는것이 있어야 할 것입니다.



개발자를 어떻게 구해야할지 모르는 경우가 많음



모든 스타트업이 개발자가 필요한 것은 아닙니다. 때로는 홈페이지 같은 간단한 것들을 구현할때는 고도몰이나, 윅스, 간단히 수정만으로 구현되는 홈페이지가 필요한 경우도 있습니다. 하지만, IT 플랫폼이나 인터넷을 사용하는 서비스의 대표가 되려고 하는 경우는 개발자가 필수 입니다. 어느 업종을 막론하고, 앱이나 웹, 사람들이 구매를 하게끔 하기 위해서 인터넷 업종에 대한 공부는 필수적입니다. 업종에 대해서는 많은 공부를 하기 때문에 경험으로 단가를 알기도 하고, 부딪히면서 배워 나갑니다. 하지만 개발자에 대해서는 어떤 성향을 가지고 있는지, 외주 업체들은 어떤식으로 구성되는지, 개발자의 단가나 금액에 대해서는 깊게 고민하지 않습니다. 그러다보니, 때로는 개발해 놓고, 수정사항이 생겨도 또 다음 개발자를 구하기가 어려운 경우가 있고, 개발은 했으나, 운영하다가 서버가 죽거나 문제가 생겼을때 뒤처리를 할 수 없는 경우도 있습니다. 그러다가 아 개발을 배워야 하는게 아닌가 생각하는 대표들도 많이 생기는 것입니다. 개발 커뮤니티나 여러 의뢰처들을 많이 알아둘 필요가 있습니다. 그리고 가격 비교도 천차 만별이다보니, 잘알아보아야 하고요.



컨설팅 업하는 사람들에게 혹해서 이리저리 끌려다니는 경우가 많음



제일 쉬운 것이 말하는 것입니다. 개발자들은 오히려 말을 힘들어합니다. 그래서 전면에 나서는 경우보다는 다른 업체들 사이에 끼어있는 경우가 많습니다. 그러다보면 컨설팅하는 사람이 주도권을 쥐는 경우도 많습니다. 즉 서비스를 설계해주거나, 전략을 설명해 주면서 지분을 요구하는 경우도 있고, 실제로는 뭔가 진행되고 있는것 같지 않은데도 불구하고 이런 저런 곳에 불려다니거나 하기도 합니다. 자신의 전략이 제일 중요한데 말이죠.



해야할 건 많은데 진전이 없음



이리저리 생각이 많다보면, 사람도 만나야 하고, 투자도 받아야 하고, 기획도 구상해야 합니다. 이런 저런 생각들이 너무 많다보면, 정말 정작 해야할 일들을 놓치기도 합니다. 1년 2년 매우 긴 시간 같지만, 준비하다보면 1~2년은 순식간에 지나가곤 합니다. 기다림이 매우 필요한 순간들입니다.



투자에만 집중하는 경우도 있음



가끔은 BM을 키워서 서비스를 성장시키고, 돈이 되는 회사, 회사가 돈을 벌게 만들도록 구상을 하는 경우도 있지만, 주변에 인수 합병 소식과 EXIT 소식들, 네이버나 라인, 카카오가 이런저런 것들을 인수하는것들을 보고 있으면, 빨리 서비스를 만들어서 인수를 시키고 싶다는 생각이 들게 마련입니다. 정작 투자 받을 서비스들은 이미 성숙한 서비스입니다. 이미 늦었습니다. 그 다음을 내다보고 좋은 BM 으로 성장하고 성숙하게 되면 투자는 자연스러운 이라는 믿음으로 해야 좋은 결과가 있지 않을까요. 이렇게 투자에만 집중에서 성공하는 전략도 있기 때문에 답이 아니라고 할 순 없지만, 이런 경우는 많은 부분을 놓치게 됩니다.



사람에게 관심을 가지는 대표가 좋은 대표



서비스나 업종에 집중하고, 하는 일에 집중하다보면, 사람을 부속품으로 보거나 성공을 이루어주는 도구로 보는 경우도 있습니다. 그것은 스스로도 눈치채기 어려운데, 사람이 쉬고 있는 모습을 볼때, “아 잠깐 쉬고 더 열심히 하려고 하는군아”이런 생각을 하는 것이 아니라, “ 놀고 있는 시간 = 돈나가는 소리 ” 이런 생각을 하고 있다면 의심해봐야 합니다. 어느덧 좋은 사람과 함께 성장하겠다는 생각보다는 성공 때문에 사람을 더 몰아 치는 부분이 생길 수 있습니다. 개인의 성장을 돕고 회사의 성장을 돕고, 함께 성장해야 의미가 있습니다. 키워준다는 빌미로, 야근을 시키거나 해보지 않은 일들에 대해서 짧은 시간에 성취하라고 요구하고 그 결과를 내놓지 못했을때, 다그치는 상황들은 누구도 좋다고 바라보진 않을 것입니다.



본질보다는 외향이나 잭팟에 목매는 경우가 더 있음



핵심가치, 서비스에는 늘 핵심 가치가 있습니다. 타다라는 서비스는 공유 경제로써, 사람들에게 이동의 편리함과 저렴함을 주려는 의도가 있습니다. 에어비엔비도 남는 공간을 활용해서 여러사람에게 이득을 주려고 했습니다. 마찬가지로 여느 서비스든 돈을 번다는 측면에서 사업적인 이윤을 추구하지만, 그 서비스가 가지는 매력과 강점 그리고 본질들이 있습니다. 겉 모습과 외향, 그리고 잭팟만을 바라다가 남들을 따라가기만 한다던지, 누구나 생각할 만한것들을 뒤늦게 접근해서 아무도 관심을 가지지 않는 서비스를 만드는 경우를 버려야 할 것입니다. 물론 실행하는 것이 실행하지 않는것 보다 낫습니다. 많은 새로움에 도전하는 대표님들을 응원합니다.



하려고 하는 일에 대한 경험이나 숙련도가 없는 경우도 있음



대표가 사람을 구할때, 혹은 팀빌딩을 할때, 다른 직군의 사람들이 염두해야 하는 부분중에 하나입니다. 대표라고 해서 모두 해당 직군의 숙련자는 아닙니다. 처음인 경우도 많습니다. 글로벌이 처음임에도 글로벌을 공략하는 경우도 있습니다. 이 부분은 염두하고, 가는 것입니다. 다만, 처음 이후에 익숙해 짐에 대한 속도는 사람마다 엄청나게 다르고, 그것을 보고 비젼을 함께 꿈꾸어 볼 수도 있는것입니다.



마케팅 포인트나 셀링포인트 타게팅이 제대로 되지 않은 경우도 많음



제품의 경우는 제품의 강점이 있어야 합니다. 환경을 생각했다든지, 저렴하다든지, 디자인이 너무 깔끔하다던지, 취향을 저격한다던지 하는 강점이 필요한데, 이 서비스의 핵심이 무엇인가요. 이게 왜 팔리나요? 이걸 누가 사나요? 사람들이 이것을 왜 사야하나요? 라는 질문에 대답하기 어려워하는 경우가 많습니다. 즉, 아이디어에 대한 고민은 있었지만, 제품 검증, 고객 검증, 스스로 확신에 대하여 아직 미지수의 영역이 많다는 것입니다. 개발자도 기획자도 누구도 설득하기 어려울 것입니다.



동종 업계 분석에 별로 신경쓰지 않는 경우도 있음



아이디어가 있는데 부딪혀보지 않은 경우, 시장을 몰라서 이미 나왔던 업체나 기업들이 무엇이 있는지 어떠한 것이 실패를 겪었는지, 실패를 겪은 요인은 무엇 이었는지 분석되지 않은 경우도 많습니다.


많은 앱들이 시장에 나오고 죽어가고 있습니다. 지금 스마트폰에 깔려있는 앱이 몇개나 될까요? 이제 모든 기업들이 앱을 좀 깔아라…라고 하고 있지만, 너무 많은 앱들 사이에서 그냥 순정으로 돌아가자…. 아무것도 안깔고 진짜 필요한 것만 깔게 됩니다. 특히나 폰을 한번 바꾸거나 하면 완전 리셋입니다. 이런 상황에서 새로운 것을 만드는 것, 그리고 고객의 마음을 모르는채로 계속 잘나가는 몇개 기업만 바라보면서 무조건 부딪치는 것은 계란에 바위 치기 일지도 모릅니다. 이미 실패한것들을 분석하고, 성공한 것들을 분석하고, 빈틈을 노리고, 그 사이에서 성공할 수 있는 요인으로 밀어 부딪치다보면 계란에 바위가 깨질 수도 있을 테니까요.



B2C 임에도 고객의 성향이나 니즈를 잘 모르는 경우도 많음



대표님들의 경우 경영학 출신의 경우는 최소한의 B2B, B2C 에 대한 이해부터 SWOT 분석같은 기본적인 부분들은 거쳐오는 경우가 많습니다. 하지만, 고객인 건지 기업인건지 누구에게 발품을 팔아야 하는지, 성장하려면 어디를 공략해야 하는지 조차도 모르는 경우, 많은 시간 낭비 후에 뒤늦게 집중해야 되는 것을 깨닫기도 합니다.



개발자, 디자이너들이 뭘 원하는지 모르는 경우도 많음(돈,명예,가치)



사람을 구한다고 해도, 모두가 돈만을 원하는 것은 아닙니다. 하지만, 때로는 적절한 가치를 주지 않으면 함께 하는 사람도 오래가지 못할 것입니다. 그리고 그 가치는 서비스의 성장에 따라 달라집니다. 같은 금액으로 오래 붙잡으려는 계획은 얼마 못갈 것입니다. 명예를 줄 수 없다면 돈을, 돈을 줄 수 없다면, 이 서비스의 가치, 함께 뭔가를 만들어가는 것에 대한 가치를 서로 느끼는 것이 가장 바람직할 것 입니다.



지분가치에 대해서 쉽게 생각하는 경우도 많음



사람을 모을때 가장 많이 거론되는 것이 지분입니다. 지분은 휴지입니다. 상장한 기업이 상장폐지되면 휴지조각이 되듯, 상장하지 않은 지분은 의미가 없습니다. 이렇기 때문에 지분을 남발하기도 합니다. 이게 쓸모 없다는 걸 서로가 다 아는데 말이죠. 이 지분이 중요한걸 안다면, 앞으로 지분을 희석시킬 계획이 아니라면, 이 지분의 가치는 대표 입장에서도 아주 중요하게 생각해야 합니다. 그렇기 때문에 지분을 마구 주는것은 옳은일이 아닙니다. 지분 대신에 줄 수 있는것들을 생각해야 합니다.



절약 — 아까운 돈.



시작할때는 돈이 제일 아깝습니다. 그렇기 때문에 많은것들을 절약하곤 합니다. 절약하지 않으면 성장도 없습니다. 명백합니다. 후에는 바뀔 수 있습니다만, 지금은 아닙니다. 하지만 사람을 절약 하다가는 서비스가 빛을 보지 못할 수도 있습니다. 시간을 들여야 하는 순간, 돈을 들여야 하는 순간 적재적소에 써야 나중에 더 큰 비용이 드는 일을 막을 수 있습니다.



힘든 성장



회사를 만드는 것도 어렵고, 키우는 것도 어려운데, 실제로 이 부분에 대한 노고와 노력을 어디서 보상받기 힘들때, 무력감이 들곤 합니다. 대부분 함께 하는 사람들보다는 대표의 책임이라고 이야기 할때, 이런 성장의 댓가와 선택의 댓가를 후회하기도 하고, 월급쟁이의 삶이 가장 부럽다고 생각하기도 합니다. 특히나 상황은 매순간 변하고, 그 변하는 상황속에서 아무것도 할 수 없을때, 그리고 크고 먼 비젼을 보고 가는 것이 너무 힘겹다고 느끼는 순간들.. 이 과정의 시간들을 견디는 일이 너무 힘들고, 그리고 이것을 이해하지 못하는 동료들이 야속하기만 한 순간들도 있습니다.




성향 > 니즈 > 갈등 요인 > 해결 방안


개발자



좋은 개발환경



개발자가 기본적으로 필요로 하는 옵션입니다. 장인은 도구를 가리지 않는다는 말이 있지만, 좋은 도구가 아닐때는 효율이 떨어지는 법입니다. 개발하기에 좋은 컴퓨터, 개발하기 좋은 사무실, 개발하기에 좋은 동료, 개발하기 좋은 다른 개발자 이 모든 것들이 갖추어지긴 힘들더라도, 퍼포먼스에 차이를 주는 것이 사실입니다. 기업이란 이런 니즈까지 채워야 하기 때문에 비용이 더 들어가는 것이 사실입니다. 개발자나 대표 모두 이 부분에 대해서 염두는 해야합니다. 무한정으로 비싼 것을 살수는 없지만, 좋은 개발환경도 개발자의 선택 요인이 될 수 있다는 점을요. 그래서 최근에 많은 IT 기업들은 복지의 조건에 이 부분을 명시합니다. 이것만 있으면 복지라 부를 수도 없겠지만 말이죠.



개발 성장 로드맵



스타트업이나 대표입장에서는 서비스의 성장이 목표가 될 수 있지만 개발자 입장에서는 각각의 개발의 성장 로드맵들이 있습니다. 대기업, 중견기업, 중소기업, 스타트업, 개인프리, 상주프리 등등 다양한 기업이 있다면, 초기에 회사를 선택하는 전략중에 순서는 상관 없지만, 대기업에 있다가 스타트업 순서를 꿈꾸기도 하고, 스타트업에 있다가 중견 > 대기업을 꿈꾸기도 합니다. 국내 대기업에서 외국계나 해외로 이직하려는 케이스도 있고, 다양한 회사를 선택하는 전략들이 있기 때문에 그런 개인의 성장 전략에 따라서 원하는 회사의 타입이나 종류가 달라지기도 합니다. 어떤 개발자든 같은 방향만을 추구하지 않는 다는 것입니다. 각기 추구하는 바가 다릅니다.


특히 이 부분은 기술 스팩에서도 분명한 차이를 낳습니다.


처음부터 중견, 대기업에 들어가면서 개발의 모든 프로세스를 배우지 못하고 부분부분만 하는 경우도 있고, 웹을 하고 싶은에 MFC나 C#을 하게된 경우도 있습니다. 오히려 반대의 경우도 있고 아예 펌웨어 개발자가 되는 경우도 있고, 모두가 다른 영역에 속해 있다보니, 해당 업종에 있지 않는 이상은 그 업종에 대해 넘겨짚기도 합니다.


다양한 방향 내에서


프론트 > 백엔드>풀스택(프론트,백엔드)


풀스택(프론트,백엔드)>풀스택(프론트,백엔드)>PL>PM


백엔드>프론트>풀스택(프론트,백엔드)


앱개발>백엔드 개발>프로젝트(앱,백엔드)


안드개발 > 아이폰개발 >(둘다)


이런 여러가지 전략들이 각각에게 생기게 됩니다.( 풀스택이 여러 가지로 쓰이는 상황에서 프론트와 백엔드로 간단하게 묶어서만 표현하겠습니다.)


이렇게 어떤 경우는 개발로만 계속 성장하고 싶어하는 경우도 있고 새로운 기술만 바라보는 경우도 있습니다. 인기있는 언어에 집착하기도 하고, 해외에서 사용하는 성공 사례를 따라가기도 합니다. 이런 모든 개발 성장에 대한 플랜들에 있어서 프로젝트는 포트폴리오로써 중요한 성장 요인이 되기도 합니다. 그래서, 많은 대표들이 프로젝트를 미끼로 개발자들을 찾기도 하지만 말이죠.


하지만 분명한것은 개발자가 성장을 추구한다고 하더라도, 무보수라던지, 어떤 열정만을 강요하는 상황은 누구도 달가워하지 않습니다. 목적을 이루는 것, 이것이 같을수 있지만, 결론적으로는 이 전체적인 프레임과 성장 전략은 뛰어난 개발자, 대접받는 개발자, 성공하는 개발자, 유명해지는 개발자 등등의 모든 요인들을 가지고 있기 때문입니다. 이 나열된 부분에 대해서 보탬이 될 수 없다면, 다른 줄 수 있는 것들이 있어야 서로의 눈높이가 맞을 수 있겠죠.



멘토 — 롤모델



개발자 입장에서 성장 전략이 필요하듯, 같은 회사에 이미 성장을 이루어 가고 있는 멘토의 존재는 매우 필수적입니다. 커뮤니티를 통해서 롤모델을 찾기도 하고, 여러 언론을 통해서 롤모델을 찾기도 하지만, 중요한 것은 보고 배울 수 있는 사람이 가까이 있을때 성장은 더 빠르게 일어날 수 있으니까요. 물론 함정은 강연하는 사람과 함께 일하는 것은 다를 수 있다는 점입니다. 그렇다고 하더라도, 성장의 기법과 요인은 누가 줄 수 없는 부분입니다.



가치와 비젼 실현



개발자의 로드맵중에 가끔은 잭팟, CTO가 되어서 큰 서비스를 성장 운영해보고자 하는 경우도 있습니다. 개발자로써의 가치를 추구한다는 부분과 어떤 성공적인 개발자가 될 것인가 하는 부분은 매우 중요합니다.



아이디어를 실현 시켜줄 디자이너



개발자가 아이디어가 있다면, 개발자에게 아이디어가 있는 경우는 다른 기획자나 대표없이 훨씬 더 빠른길을 갈 수 있는 기회가 열립니다. 개발자의 입장에서 아무리 잘 만들어놓고 동작을 잘하더라도 디자인이 없으면 무용지물인 경우가 부지기수 입니다. 디자이너 입장에서는 이 부분의 니즈를 맞추어보면 성공적인 부수입 전략을 맞추어 볼 수도 있습니다.



포트폴리오를 만들어 나갈 토이프로젝트



중견기업, 큰기업 혹은 특이한 부서들의 경우는 여러가지 개발 경험과 기회를 갖지 못할 수도 있습니다. 따라서 개발자 입장에서 개발을 못하는 아이러니한 상황에 있는 경우, 토이프로젝트를 찾기도 합니다. 너무 스트레스를 받지는 않되, 실력은 키우며, 그 결과에 대해서는 자유롭게… 이 토이프로젝트는 성장에 대한 포폴은 없지만 기술스펙과 기술의 도입 부분에 점수를 받을 수 있습니다. 따라서 디자이너&개발, 디자이너&기획&개발 조합으로 종종 토이프로젝트가 생겨납니다. 이런 기회들을 통해서 좋은 사람과 만나기도 합니다.



새로운 기술을 적용해 볼 수 있는 기회



모든 개발회사들이 새로운 기술에 적합하진 않습니다. 운영업무나 레거시를 경험하거나 현상을 유지하는데 그치기도 합니다. 따라서 신기술을 해보고 싶은 개발자도 있습니다. 적당한 선에서 말이죠.



재미있고 흥미로운 일



새로운 기술과 같이, 새로운 프로젝트의 디자인을 적용해본다던지, 새로나온 기술들을 찾아서 스터디 하기도 합니다.



인공지능 머신러닝 등 새로운 분야에 접점



사회의 변화에 따라서 새로운 영역들이 많이 나타났고 그 전에 그 연봉이 얼마인지 책정하기도 어려운 영역들이 생겼습니다. 데이터를 다루는 분야들인데, 빅데이터가 있었고, 머신러닝 분야가 생겼습니다. 학습이라는 개념이 익숙해졌는데, 데이터 전문가들도 예전에 matlab을 강제로 배우듯이 R, 텐서플로우 파이선같은 것들을 도구로 사용해야하는 상황이 되었고, 기업들은 해당 영역의 실력자를 찾기 위해 여러가지 수소문도 하게 됬습니다. 이에 따라 이직이나 분야를 바꾸고 싶어하는 개발자들도 당연히 나오고 있고, VR AR을 비롯해 IOT 영역들은 여전히 흥미를 느끼는 분야입니다. 다만, 시간이 걸리고, 더 전문적인 일들에 치중하겠지만 말이죠.



가치를 실현 시켜줄 대표를 만나는 것



개발자의 또 다른 니즈 중에 하나는 좋은 대표를 만나는 것입니다. 결론은 큰기업이든 작은 기업이든 로켓기업이든 어떤 결정을 하는 대표에 의해서 많은 일들이 좌지우지 됩니다. 월급이 밀려서 힘들어하기도 하고, 월급이 올라서 좋아하기도 합니다. 지분가치가 없어져서 허탈해하기도 하고, 또 지분가치를 팔수 있는 기회를 얻게되기도 합니다. 이런 모든 과정가운데, 대표의 뜻과 의지가 전적으로 반영되기 때문에 개발자는 좋은 사람의 냄새를 끊임없이 맡습니다. 위험신호를 감지하고 떠나는 것이죠. 가치가 맞는 사람을 만나야 합니다.



개발자 선배의 조언



개발자 선배가 누구나 뛰어난 것은 아닙니다. DB에 집중하기도 하고 분산처리에 특화 되기도 하고, 따라서 연차가 실력을 반증하지는 않습니다. 하지만 신입의 경우 혹은 처음에 무엇을 해야할지 어떤 스탭을 밟아 나아가야할지 잘 모르는 경우는 이 로드맵으로 가는 것이 좋아보인다. 라는 한마디가 인생의 방향을 결정하기도 합니다. 저 또한 이런 조언이 없었다면 스타트업에 발을 담구거나 뛰어들지 못했으리란 생각이 드네요!



일정조율, 설득이 가능한 대표나 기획자



말이 통하는 대표나 기획자는 필수 조건입니다. 무조건 기일을 맞추라고 강조만 하고 앞뒤문맥이 없다면, 결코 그 그일은 일어나지 않습니다. 일어난다고 해도 껍질만 되어있거나 모든 기능은 없어졌을 것입니다. 마냥 기다릴 이유는 없지만, 무엇을 해야하고 무엇이 남아있고 기간을 서로 물어보고 협의하는 과정이 없다면 결코 전진은 없을 것입니다.



기획자와의 트러블 극복



업무 협의를 하다보면 일정이 맞지 않고 감정적 트러블로 번지게 될 수 있습니다. 감정노동히 더해지면 일을 하는데 평정심을 유지하기 어렵죠. 적당한 선과 그리고 협상의 능력 그리고 해야할 때 그것을 빠르게 처리해주는 것으로써 기획자와 협의를 해야합니다.



디자이너와의 트러블 극복



기획자가 끼지 않은 경우 다이렉트로 디자이너와 일정 협의나 소스를 주고 받는 경우들이 있습니다. 서로 소통이 어려운 경우 이 트러블을 극복하는 것을 간절히 원하게 될 수 있습니다. 서로의 작업 방식을 이해하려고 노력해야 합니다.


디자이너



좋은 기기



개발자만 좋은 기기가 필요한건 아닙니다. 특히나 영상을 해야 한다던지, 포토샾, 일러스트, 애프터 이펙트 등등 용량이 크고 렌더링이 필요한 경우 좋은 기기일 수록 효율이 나고 속도가 나는 법입니다.



꿈꾸던 가치랑 맞는 일



누구나 꿈은 꿉니다. 다만 그 꿈과 현실이 다를 뿐입니다. 디자인을 하기 시작했을때, 그림을 그리는 일이 시작이었든, 일러스트가 시작이었든, 혹은 처음부터 서비스에 대한 꿈이 있었든, 남의 일을 해주는 것이 목표는 아니었을 것입니다. 누구나 자기 서비스를 꿈꾸고, 그 서비스의 대세와 함께 하는 것이 또 가치 실현중에 하나가 될 수 있습니다.



디자이너로써 성장 전략



가끔 IT 회사에 있다보면 디자이너는 필연적으로 성장하는 곳에서 개발자와의 비교가 되기 마련입니다. 그리고 연봉을 함께 비교하더라도, 그냥 직군이 다르다는 이유만으로 어떤 경험이나 능력, 그리고 실력과 상관없이 비젼을 꿈꾸기 어렵다는 차원에서, 여러가지 성장 전략을 가지기 마련입니다.


회사에서는 디자이너에게 퍼블리싱 능력까지 요구합니다. 최근에는 안드로이드의 경우 화면 레이아웃도 개발자가 잡아주어야 하는 측면들이 많아졌기 때문에 이 영역까지도 디자이너에게 넘기려고 하는 부분도 생기고, 그러다 보니 그 접점의 영역들을 디자이너에게 가중시키는 경우가 종종 있습니다.


디자이너 입장에서 온전히 디자인에 집중할 것인가, 기술의 영역도 가져갈 것인지 하는 부분들이 온전히 고민하는 영역 중 하나입니다. 이 기술의 영역에는 배우는 시간, 실행하는 시간이 포함되어있고, 온전히 디자인을 구현하고 성장시키는 시간과는 별개의 시간들이기 때문입니다.


하지만, 돈을 더 받는 부분을 떠나서, 좋은 디자이너, 성장하는 디자이너, 성장하는 회사의 디자이너가 되고자 하는 목표들은 여전히 있습니다. 나의 서비스를 만들고 싶은 목표도 있고요.



좋은 회사



좋은 기기만큼 좋은 회사는 필요합니다. 대부분의 큰 회사가 좋은 복지를 가지고 있고, 좋은 연봉에 좋은 것들을 갖추고 있지만, 기본적으로 야근이 없다던지, 의사결정 수립의 절차가 합리적이라던지, 유연 근무, 자녀의 문제를 고민하지 않도록 만들어주는 시스템, 자택이 가능하거나, 회식의 강요가 없는 회사 등등 좋은 회사는 좋은 환경을 만들어주고, 더 본질에 집중할 수 있도록 해줍니다.



디자인이라는 직군에 전문성 갖추기(체계가 없는 곳이 많고 나름 불만 요인)



UI/UX 에 설문을 한적이 있습니다. 당연 디자인이라는 직군이 전문성이 애초부터 있으리라고 생각하지만, 사수가 없는 경우도 있고, 신입에게 맡기면서, 대표의 생각만이 온전히 의사결정의 잣대가 되는 경우도 있습니다. 개발의 경우는 기술의 발전에 따라서 로그인에 대한 기술적인 부분들이 온전히 검색으로 학습이 가능한 부분이 많고 다른 부분들도 디자인에 의존할 수 있지만, 디자인의 경우 학습에 대한 제약이 있습니다. 특히나 새로운 시스템, 서비스들은 롤모델도 없고, 규칙이 없는 상태로 규칙과 룰을 만들어야 하기 때문에 고객을 생각하면서도 새로움을 만드는 일은 어려운 일입니다. 특히 개인의 디자인 감각에 의존되는 경우가 많기 때문에 협업이 쉽지 않습니다. 따라서 협업적인 체계를 갖추기를 원하는 디자이너가 많습니다. 나름의 의사소통 방식과 디자인에서도 점차 방법론들이 확대되고 있습니다.



신입에 입장에서는 뭐라도 알려주고 시켰으면 하는 바람



경력을 뽑거나, 신입을 뽑거나, 체계가 없는 경우 알아서 적응하고 알아서 해주기를 바라는 문화들이 있습니다. 물론 그런 경우가 경력을 뽑는 이유들이겠지만, 신입을 뽑을때도 알아서 하기를 바라는 경우도 있습니다. 교육과 체계가 없다면 당연히 적응 기간은 길어집니다. 특히 쇼핑몰처럼 해야하는 일이 정해져 있는 곳이면, 적응이 길지 않을 수 있지만, 뭔가 새로운 디자인이 서비스로 변형되고 그것들이 중요한 곳이라고 하면, 어떤 디자인이 좋은 디자인이고 어떤 디자인이 좋지 않은지를 신입 입장에서는 알기 원합니다만, 실제로는 대표나 기획자의 평가에 의존되기 때문에, 이런 평가는 성장에 도움이 되지 않습니다. 전문적인 평가라는 느낌 보다는 그냥 감정적으로 의존한다는 느낌이 들기 때문에 감정의 골만 생기는 거죠. 왜 이 디자인이 별로인지 설명 없이, 마음에 안든다는 표현이 대부분이기 때문인데요. 예를 들어 메인에서는 원래 가독성을 위해서 너무 작은 폰트보다는 조금 더 굵고 큰 폰트들이 배치 되어야 하고, 화면의 크기에 따라서 GNB 위치와 영역이 달라지는 것이 좋다. 이렇게 설명 되어야 할 부분들이, 뭔가 이상한 느낌이다. 라는 표현으로 설명 되다보니 해석에 대해서 시간이 길어집니다.



무에서 유를 창조하지 않기를 바람



대부분 기획서는 있지만, 이 기획서에서 주어지는 느낌들은 너무나 일상적이고 추상적인 표현들입니다. 깔끔한 느낌, 화려하지 않게, 직관적으로, 고객들이 이해하기 좋게, 우리가 누구인지를 잘 설명할 수 있도록, 담백함을 최대한 살려서, 전문적으로. 등등의 표현들을 사용하는데, 디자이너 입장에서는 점점 경험이 쌓일 수록 이 대목들을 잘 해석하게되고, 더 잘 표현하게 되긴 하지만, 처음의 입장에서는 이게 해석과 결과가 다르기 때문에 이 소통의 문제들이 가장 큰 문제로 다가오게 됩니다. 아와 어만 달라도 크게 틀려지는 데 이 디자인의 영역은 생각 자체가 다르다 보니 조율이 어렵습니다. 경험이 많으신 분들은 특히 먼저 디자인 작업을 해서 보여주는 것보다도, 이미 있는 서비스들을 미리 보여주면서 이런 서비스가 맞는지 확인하는 절차들을 통해서 이런 소통 과정의 시간을 단축하고는 합니다.



요구사항과 기획 요청에 대한 디테일



기획자나 대표의 기획이 아이디어 수준일때, 일단 디자인을 해주시면 거기에 맞추어보겠다는 의견을 제시하는 경우들도 있습니다. 가장 난감한 부분인데, 서비스의 핵심적인 플로우들을 디자이너에게 일임시키는 부분입니다. 가장 중요한 사람들의 유입, 가입, 뷰의 차이들이 있는데, 사람들에게 느끼게 하고 싶은 그 요인들에 따라서 디자인의 디테일은 엄청나게 차이가 생깁니다. 예를 들어서 로그인 없이도 사용자에게 데이터를 보여주고 싶은 경우는 아예 로그인 화면 자체를 단촐하게 만들거나 레이어 팝업 형태로 간단하게 로그인을 줄 수도 있습니다. 헌데 로그인 페이지가 아예 생기면서 로직 자체가 로그인 페이지로 가게 만들면서, 사용자 입장에서 화면을 보지 못하게 한다면, 뭔가 기획의 의도는 실패한 셈이 될 수도 있는데요. 이 부분은 디자이너 입장에서는 자세하게 기획서에 나오지 않으면 일반적으로 로그인 페이지를 따로 만드는 것처럼 그렇게 로그인 페이지를 만들 수밖에 없습니다. 측, 전체적인 컨셉에 이어서 디테일한 컨셉도 어느정도 잡혀야지 디자인도 그에 맞추어서 변화가 있을 수 있다는 것입니다.



디자인으로 구현했는데, 개발에서 못한다고 할때



어찌어찌, 기획과 협의가 끝나고 디자인으로 구현을 했으나, 이 부분이 끝나지 않은 산입니다. 개발에서 한번에 통과하면 좋지만, 기획자와 개발자가 충분히 협의 되지 않은 상태에서 구현하기 너무 어려운 디자인을 넘겨주는 경우 개발자 입장에서는 너무 힘들어 질 수가 있습니다. 그래서 디자이너 입장에서 엑션에 대한 기대치를 하고 있다가, 구현이 불가능하다고 하면, 맥이 빠지는 경우들이 있습니다. 동적인 부분들을 구현함으로써 어색한 부분들을 대체하고자 했으나 그 부분이 안되면서, 원하는 구현을 못하는 상황이 발생하기 때문입니다.



기획의 컨셉만으로는 도저히 디자인 컨셉을 구현하기 어려울때 기획을 바꾸고 싶은 마음



위 내용이랑 비슷한데, 기획의 컨셉이 답답한 경우, 기획을 엎어버리고 싶은 순간이 있습니다.



합리적인 일정 프로세스



기획 > 디자인 > 개발 일정의 경우가 많습니다. 기획이 상세하게 되지 않은 경우 이 기획 & 디자인 일정이 디자이너에게 쏠리는 경우가 있는데, 이것들 때문에 일정은 촉박한데, 결과물은 빨리 달라고 하는 경우들이 있습니다. 따라서 합리적인 일정 프로세스는 매우 필요합니다.



디자인에 대한 칭찬이나 가치 인정



칭찬은 바라지도 않고, 일단 컨펌하기를 원하는 경우가 많지만, 대부분 가치를 인정받기 보다는, 계속 대표가 원하는 바와 다르다고 하는 경우가 많기 때문에 이 인정은 필수 적입니다. 물론 대표가 디자인에 대해서 아예 모르고, 그 영역을 간섭하지 않으려고 한다면, 디자인에 대해서 어설프게 알지 않고 디자인 영역을 존중하는 경우는 오히려 나은 경우가 있을 수 있겠네요!



개발자랑 협업해보기



기획자와 주로 소통하고, 개발자와는 한다리 건너 소통하다보면서 답답한 부분들이 있는 경우가 있습니다. 그래서 커뮤니티에 나오는 사람의 경우, 해당 부서의 개발자와 이런 소통을 하길 원하기 보다, 타 커뮤니티에서 같이 일을 해봄으로써 그런 개발자와의 협업 능력을 키우고 싶어하는 경우도 있었습니다. 다른 개발자들과 일해보면서 왜 개발자들이 그렇게 반응하는지, 안하려고 하는지 영역을 고수하려고 하는지 이해해보고 싶은 것이죠.



내 서비스 만들어보기



회사의 서비스 말고, 생각하고 있고, 구현하고 싶어하는 서비스들이 있습니다. 내서비스 만들어보기는 한번쯤 꿈꾸어보는 자신의 목표가 아닌가 싶네요. 숨겨놓은 포트폴리오를 실현해 보고 싶기도 하고, 포폴용으로 소장하고 싶기도 하고요.



개발에 대한 관심



개발에 대한 요구사항이 조금씩 늘어나고 있는 상황에서, 디자인&퍼블의 경우 훨씬 더 많은 비용을 받기도 합니다. 그래서 개발에 대한 지식에 대한 이해를 하고 싶어하고 js, css, html 같은 퍼블리셔 영역들에 대해서는 한번쯤은 생각해 보고 고민해 보는 디자이너도 많아지고 있습니다.


기획자



대표의 마음이 수십번 바뀔때, 기획서도 같이 바뀌지 않았으면 하는 마음



기획자의 기본적인 마음은 더 이상 수정이 없기를 바라는 마음입니다. 물론 기획자가 대표인 경우는 이 마음의 내적 갈등이 가장 많이 있겠지만, 이 분야가 다른 경우는 시키는 기획자의 입장에서는 개발자와 얼굴을 붉히는 일을 피하고 싶기 때문에 한두번정도는 괜찮지만 이게 한계치 이상으로 변경을 요구하는 경우는 미안한 마음 때문에 늘 개발자에게 미안해야 합니다. 따라서 대표의 마음이 정착되었으면 하는 바람이 있습니다. 물론 대표입장에서는 한번의 서비스, 한번의 런칭, 이 시간에 대한 긴박감이 있기 때문에 더 잘하고 싶은 마음이 무조건 적입니다. 이 차이의 갭 때문에 기획자의 니즈는 기획서에 대한 FIX 입니다.



개발자와 일정 조율의 문제



개발자가 많은 부서, 혹은 일정적으로 처음부터 여유있는 경우는 그나마 나은 편입니다. 개발자가 적거나 분량이 상대적으로 많은데 이 일정이 없는 경우는 이 일정을 조율하기가 쉽지 않습니다. 개발의 일정은 백엔드의 개발도 고려해야하고, 퍼블리싱의 일정도 고려해야하고, 프론트 개발의 일정도 고려해야합니다. 모든 개발 일정들을 고려하다보면 시간이 너무 촉박하다는 것들을 늘 체감하게 됩니다. 물론 웹 개발의 예시지만, 앱개발의 경우도 서버 개발자, 앱 개발자의 일정들을 고려해야 하고 조율해야 하기 때문에 일정 문제가 해결되기를 하는 바람이 있습니다.



디자이너와 일정 조율의 문제



디자인 시안이 적은 경우는 무방합니다. 이게 홈페이지나 새로 구축하는 경우 신경 쓸 요인이 엄청 많은데, 반응형까지 고려하다보면 이 시안이 무한적으로 늘어나게 됩니다. 이런 일정들을 소화하는게 무척 어려운일입니다. 일을 덜어내지 않는 이상 디자이너의 일정의 길어짐은 개발 시작 시점의 딜레이를 의미하고, 결과적으로 프로젝트의 지연으로 이어집니다. 빠른 결정과 결단이 필요합니다. 그렇기 때문에 일정 조율은 매우 중요합니다.



기획서 쓸 시간이 없음



개발자와 디자이너와의 일정 조율도 문제인데, 이것을 시키는 입장에서는 이 일정을 딜레이 시키는 책임을 기획자가 지는 경우가 많기 때문에 그 짧은 일정에서 가장 큰 리스크는 기획자에게 돌아갑니다. 따라서 완벽하지 않은 기획서, 그 기획서를 수정하는 시간들이 중간중간 들어가고, 또 그것들은 딜레이로 작용되고, 애초 프로젝트를 시작하는 시점과 기획이 완결 되는 시점이 더 우선되었다면 모르지만, 이미 모든 프로젝트가 시작된 시점에서 기획자는 밤을 샌다던지 여러가지로 빡센 일정들이 기다리고 있습니다.



더 이상 생각할 수 있는게 없을때(이미 시장에 다 나와있음)



대표의 요구사항 중에 시장에 없던 것들을 추구하라는 의견이 나온다면, 공유경제, 제품시장, 커머스시장, 운송시장, 숙박 시장, 푸드테크, 여행업, 전자 기기 시장, 반려 시장, 심리시장, 캐릭터 시장, 인공지능, 운동 시장 등등 대부분의 돈이 되는 시장들은 이미 선점된 기업들이 있고, 더 이상 파고들 부분도 보이지 않습니다. 이렇게 생각할 것들이 없다는 생각이 들면 너무 머리가 아프고, 기획자 입장에서 대표인 경우도 이런 고충 때문에 새로운 아이디어가 번뜩였으면 하는 바람이 있습니다.



개발 용어나 디자인 용어를 좀 더 알았으면 할때가 있음



일정을 조율하거나 소통을 하다보면, 특정 용어들이 기획자를 괴롭히는 경우들이 있습니다. 개발 세팅을 처음 할때라던지, 어떤 것들을 결정해야 할때 언어가 뭔지 백엔드, 프론트가 뭔지, 앱은 왜 따로 뽑아야 하고, 개발자들이 그냥 개발을 하는게 아니라 업무 영역이 다른 것부터 시작해서, 디자이너도 각기 하는 것들이 다를 때, 그리고 서로 파일을 넘겨준다던지, 요구하는 것들중에 용어가 어려운 것들은 좀 쉽게 풀어서 이야기 했으면 하는 바람이 있습니다.



개발자랑 간혹 트러블이 날 때 왜 트러블이 나는지 이해가 안될때 그 속을 알고 싶을때가 있음



디자이너도 그렇지만, 개발자와의 트러블들이 이해가 안되는 경우가 있는데, 개발자의 니즈가 있는데 그런 부분들과 관계있는 경우들이 있습니다. 시간이 없는데 시간을 쪼아야 하는 상황들, 그리고 비용이 너무 적은데 할일을 합리적으로 책정하지 못할때, 그 트러블 입장에서 기획자가 제일 억울한데, 개발자가 억울한 표정을 지을때도 한몫하겠죠. 여러가지 사정들이 있지만, 각각 개인의 사정들이 있다는 부분이 제일 난감하고, 어디까지가 책임의 소재인지 이해되지 않는 경우들입니다.


마케터



좋은 서비스의 마케팅 사례가 자기 사례가 됬으면 하는 바람



마케팅 직군의 니즈는 성향에 따라 다르지만, 마케팅을 토대로 서비스가 널리널리 알려지고 강한 파급력을 가지게 하는 것입니다. 대부분의 성공한 회사들에는 좋은 마케터가 함께 했습니다. 요새 같은 IT 시대에는 마케터 없이 성공한다는것이 거의 불가능할 정도로 마케팅 요인은 중요한 요인이 되었습니다. 여러 서비스들이 강화되고 널리널리 알려지고 있는 가운데, 마케팅하는 회사의 실적이 좋아지는 것은 마케터 입장에서도 중요한 경험입니다.



회사가 돈이 좀 많아서 이것저것 실험해 볼 수 있는 환경



마케터의 니즈중에 하나는 회사에 돈이 좀 넉넉한 것입니다. 투자를 받는 경우 대부분 여러가지 BM , 고객의 니즈가 확실한 경우 마케팅 비용을 태워보기 마련입니다. 이 때에, 공격적인 투자의 의미는 마케팅을 어떻게 할 것인지에 대한 전략입니다. 투자를 받은 입장에서 마케터는 그 동안 어떤 방식으로 돈을 태우는 것이 회사를 성장시키고 알리는 지 테스트 해볼 수 있는 중요한 시점입니다. 적은 비용으로 고 효율의 마케팅의 방법을 발견해 낸다면, 그것이야 말로 명성을 가진 마케터가 되는 길이겠죠. 여러가지 경계에 서있는 마케터 입장에서 투자금을 활용해 볼 수 있는 환경은 축복입니다.



회사가 돈이 많아서 인플루언서들을 고용하거나 실험해볼 수 있다면



또 한편으로 돈이 많을때, 페이스북, 인스타, 유투브와 같은 곳에 일반적인 컨텐츠 형태로의 광고나 마케팅을 진행해 볼 수 있지만, 회사가 돈이 더 있다고 하면, 구독자 50만, 100만, 300만 을 가지고 있는 인풀루언서들과 접점을 토대로 큰 프로젝트를 해볼 수도 있을 것입니다. 구독자들이 직접 혹은 간접적으로 제품을 홍보하는 것은 꽤나 기존의 바이럴 보다도 강력한 소비자들을 만들어내기도 합니다. 구독자들의 연령대는 매우 다양하고 구독자들은 구매력을 갖춘 소비자이기도 하니까요! 이런 함께 프로젝트를 경험하는 것들은 마케터에게 새로운 기회를 주기도 합니다. 물론 이런 것들은 매우 피곤하기도 해서, 안했으면 하는 입장도 있겠지만 말이죠.



컨텐츠를 디자인으로 잘 만들어 줄 디자이너가 회사 내에 있으면 하는 바람



무슨 당연한 소리를, 이라고 생각하는 분들이 계시겠지만, 언제나 악조건은 그 이하의 악조건이 있습니다. 즉 컨텐트 디자이너 없이 시작하는 회사의 경우는 대표가 디자인을 해야하는 경우도 있고 오직 외주나 작은 의뢰에 의존하는 경우도 있습니다. 이런 경우에서 마케터가 조인하게 되면, 마케터의 디자인적 감각은 뒤로 하고, 마케터라 직접 컨텐츠를 만들어야 하는 경우들도 생깁니다. 디자인도 다 돈인 입장에서, 결국 컨텐츠의 위치, 색감, 스토리 등등 다양한 고민을 하는 마케터 입장에서는 디자이너 존재는 매우 절실한 존재입니다.



마케팅 부서가 전문적으로 구성되었으면 하는 바램



마케터 입장에서 부서가 없는 경우도 많습니다. 특히나 SNS 로만 마케팅을 한다던지, 뭔가 매출이 나기는 시작하는데 마케터가 없어서 뭐라도 시키려고 시작하는 시작점에 있는 회사 입장에서는 마케팅 조직을 꾸리긴 어렵습니다. 그래서, 짬짬히 하는 마케터나 여러가지를 시도해 볼 수 있는 마케터들과의 접점들을 생각해 봅니다. 이런 입장에서 마케터는 좋은 회사에서 체계적인 마케팅 방법을 배우고 싶어하기도 합니다. 마케터의 경우도 여러가지 대학에서 배우는 여러거 컨텐츠 관련 학과로 부터 시작하는 경우도 있지만, 다양한 케이스로 업종이 선택되어 지기도 하니 말이죠.



마케팅에 대한 체계적인 교육



전문적으로 부서가 되었으면 하는 바람과 같이 마케팅 교육을 받고자 하는 니즈가 있습니다. 물론 경험자를 토대로 하면 좋겠지만, 그렇지 않더라도, 어떤 방식이 효율이 좋고, 좋은 컨텐츠를 선택하는 방법부터, 지금 잘나가는 매체가 무엇인지, 대부분 마케팅에 대한 결과들은 비밀에 부쳐지기 때문에 비싼 강의를 가야만 들을 수 있는 경우들이 있습니다. 하물며 파워 블로그가 되는 방법 조차도 강의가 있는 입장에서 교육은 필수 적입니다.



분석 결과에 대한 공유 체계 및 실행 계획 필요



마케터 입장에서 서비스를 분석할 수도 있고, 또한 그 서비스에 대한 홍보를 실행할 수도 있는데요. 이런 분석 결과를 본인만 알고 있다면, 이 전략을 대표에게 공유할 수 없다면 무용지물이겠죠. 물론 공유한다고 하더라도 돈이 없어서 계획이 실패하는 경우도 있겠지만 말이죠. 예전에는 문자 발송에 대한 꼼수, 플러스 친구 마케팅 등등 새로운 마케팅 도구에 접근으로 새로운 판로를 꿈꾸어 볼 수 있었지만, 이제는 모든 것들이 돈이 더 들어가고, 이 실행 계획과 돈이 밀접한 관계가 있는 입장에서, 대표나 의사 결정권자를 설득하는 일은 매우 어려워 졌습니다. 특히 어떤 마케팅 도구도 점차 효율이 안나오는 입장에서 얼마의 비용을 투자하면 얼마의 이익을 볼 수 있다고 장담하기 어려워 진거죠. 점점 힘들어 지는게 아닌가 모르겠네요.



마케팅을 위해서 할당 되는 마케팅을 위한 개발 공수가 필요



마케팅을 하다보면 SEO와 같은 것들을 개발자 입장에서 해줄 필요가 있고, 서비스 내의 공유링크를 만들어 준다던지, 공유시에 op:image 와 같은 것들을 설정해 줄 필요들이 생깁니다. 마케터 입장에서는 이 필요성을 이야기 할수는 있지만, 직접할 수 없기 때문에 이 공수에 대해서는 개발자가 해야하는 경우들이 있는데요. 서비스의 런칭에 있어서 이런 부분들은 매우 중요한 부분이지만, 우선 순위에서 밀리는 경우가 많습니다. 마케터 입장에서는 설득하기에 난감한 부분이 발생하는 것입니다. 특히 파워링크나, 연관 검색어 같은 검색 광고 이외에 상위 노출을 위해서는 마케팅에 대한 개발 지원이 절실하다고 마케터는 늘 느끼고 있습니다.


스타트업 대표



좋은 개발자



대표 입장에서 두말 할것 없이 좋은 개발자는 매우 필요합니다. 포괄적으로 팀원이라고 이야기 할 수도 있지만, 대표의 서비스를 잘 분석해 주고, 이 서비스가 성장 할 수 있는지 없는지 체크해줄 수 있는 개발자. 그리고 해당 개발에 대해서 앱이 좋은지 웹이 좋은지 서비스 성향에서 플랫폼을 추천해 줄 수 있는 개발자, 그리고 시장을 분석해서 앞으로 어떤 부분으로 특화 시킬 것인지를 알려주는 기획적 역량의 개발자 등등의 좋은 개발자를 필요로 합니다. 특히나 그냥 개발만 하는 것이 아니라, 기획이 잘못 되었거나, 가는 방향이 좋지 않다면 올바른 방향으로 설정해 줄 수 있는 개발자를 필요로 합니다. 하지만 시장에 있는 많은 개발자의 경우 배움에 목마른 개발자가 많습니다. 즉 아직은 누군가를 상담해 주거나 누군가와 기획적 가치들을 공유하기엔 애매한 포지션 개발자가 많습니다. 그렇다고 해서, 말을 잘하는 개발자의 경우 또 실력 부분에 있어서 애매한 경우들도 있습니다. 물론 두가지를 갖춘 좋은 개발자도 많습니다. 하지만, 또 그런 경우들은 잘나가는 기업에서 CTO 급으로 영입해서 젊은 나이에도 소위 잘나간다고 하는 로켓에 올라타 있습니다. 그렇기 때문에 간단히 생각해서 공급과 수요의 입장에서만 바라보아도, 이런 개발자들이 턱없이 부족하리라는 것은 예측할 수 있는 것입니다. 하지만 그럼에도 대표입장에서 좋은 개발자는 매우 필요합니다. 특히 IT 를 하려고 한다면 말이죠.



딱 보면 하고자 하는 바를 이해해주는 디자이너



디자이너 입장에서는 대표가 말을 더 많이 해주고, 하고자 하는 바가 더 잘 정리가 되었으면 하지만, 대표 입장에서는 서비스에 대한 가치와 플롯 그리고 어떤 것이 중심인지 키를 잘 잡아주고 그에 대한 서비스의 색깔을 잘 표현해 줄 수 있는 디자이너를 찾습니다. 다만 브랜딩 디자이너가 따로 있을 정도로, 디자인에 있어서 회사의 브랜드와 가치, 그리고 디자인과 브랜딩은 절묘할 정도로 값지고 비싼 것들입니다. 하지만, 작금의 시대에서는 앱디자이너, 웹디자이너에게 로고도 만들어달라고 하고, 디자인도 부탁하고 심지어는 홍보 포스터까지 부탁하는 것이 현실입니다. 누구는 브랜딩 파워로 패키지로 엄청난 보수를 받을 수 있는데 말이죠. 하지만 대표 입장에서는 바짓가랑이라도 부여잡고 싶은 심정입니다. 어떻게든 누구에게든 보여주어야 하니까요. 이런 부분을 감안해 줄 수 있다면, 디자이너 입장에서 많은 수요들이 있습니다. 다만 이것들을 하기엔 가성비가 뛰어나지 않죠. 아무튼 대표의 니즈는 확실합니다.



가치를 실현 시켜줄 팀원



개발자, 디자이너 이외에도 대표와 한배를 타고 갈 사람을 필요로 합니다. 팀원이 마음을 알아주고, 함께 해주고, 또 가끔은 이 어려운 길을 버텨준다면… 이 길이 결코 외롭지만은 않을 텐데 라고 생각하게 됩니다. 좋은 팀원을 만난다면, 꼭 나중에 보답해주세요. 그런 사람 정말 많지 않습니다.



개발을 몰라도 개발 전체를 맡아줄 개발 팀장



개발자를 구하다가 보면, 돈이 있어도 개발자를 구할 수 없으니, 개발자를 구할 수 있는 개발 팀장을 구하기도 합니다. 또 개발 팀장 (PM, PL, CTO) 등등 을 구하려고 하는 이유중 하나는 호스팅이 뭔지 도메인이 뭔지, 서버는 어떻게 구성해야하고, 서버와 프론트를 나누어야 한다는 둥, 혹은 하나로 가도 된다는 둥, 이런 개발자들이 결정하는 수많은 결정 요인에 대해서 어지럽기 때문입니다. 차라리 잘하는 사람이 하나로 딱 결정해주면 좋은 데 이 부분이 어렵습니다. 시장에는 각각 다른 언어를 하고 있는 개발자들이 있고, 그리고 그 개발자들도 서로 다른 언어에 대해서 혼란스러워 합니다. 새로운 언어들이 나오고, 또 기존의 언어들은 계속 유지되고, 그러다 보니 이 모든 것들을 정리해서 하나로 갔으면 하는 바람이 있는 것입니다. 다만 간과 하는 것은 비용입니다. 개발자의 비용도 비싸지만, 개발 팀장의 비용은 개발자를 구하는 일보다도 훨씬 더 과도하기도 합니다. 따라서, 어디까지 발품을 팔아야 하는지 고민이 필요하겠죠. 서비스가 더 성장하게 된다면, 이런것들을 신경쓰지 않아도 돌아가는 놀라운 체계가 완성될 수도 있습니다.



스타트업 멘토



개발자나 디자이너 입장에서는 대표 멘토가 중요하진 않지만, 스타트업의 입장에서는 성공적으로 서비스를 운영하고, 투자를 받았고, 투자를 받을 수 있는 좋은 멘토가 생기기를 원합니다. 그런 연유로, 좋은 멘토가 있는 곳에 일부러 투자를 받아보려고 하기도 합니다. 멘토에게는 좋은 시야가 있기 때문인데요. 현재의 수준과 상황에서 어떤 길로 가야하는지, 어떤 사람을 만나야 하는지 어떤 선택이 올바른 선택인지 그러한 부분들을 체크해 볼 수 있는 좋은 멘토는 스타트업 대표에게 필수적입니다.



유통, 비지니스 파트너



사업을 하다보면, 혼자하는 것이 아니라는 것을 깨닫게 됩니다. 회사에서도 회사의 선배, 후배, 동료들을 신경썼다면, 업계에서는 업계의 선배, 후배들을 살펴야 합니다. 스타트업 모임도 나가야 하고, 또한 이미 선구자 스러운 곳에서도 좋은 파트너들을 발견하기도 합니다. 가지고 있는 좋은 제품이 있다면, 이것들을 팔아줄 좋은 유통처들을 모색하는 것도 필요로 하고, 혼자서 다 할 수 없기에, 함께 서비스들을 알아줄 사람들과의 파트너 쉽이 필수 적입니다.



서비스의 가치를 알아보아 줄 수 있는 엑셀레이터 파트너



서비스의 가치를 알아보아주는 VC 나 엑셀레이터 파트너를 모색하는 일도 중요합니다. 물론 서비스 자체의 매력과 서비스의 간섭 때문에 해당 서비스를 오픈하지 않고, 시장과 다이렉트로 성공하는 경우도 많이 있지만, 좋은 파트너들과 함께 하다보면, 어느새 시장에 입지가 다져지기도 하니까요. 때로는 좋은 파트너와 함께 하는것 자체가 시장에서 홍보 효과를 가지기도 합니다. 그래서 좋은 투자자를 만나는 것, 이것이 대표들이 가지고 있는 니즈이기도 합니다.



그로스 해킹 — 성장 전략 꿈꾸기



최근에 책으로 많이 나고 있습니다. 그로스 해킹, 성장에 대해서 어떤 누수의 부분을 잡아내고 그것들을 공략해서 시장에서 선점하는 것, 시장에 빠져있는 것들이 아무 꼼꼼해서 더이상 파고들 구멍이 없어보이지만, 결과적으로는 이런 것들을 추구합니다. 누구도 아무도 사용하지 않는 서비스를 만들려고 노력하는것은 아닙니다. 이제 한국을 넘어서 글로벌로, 계속적인 성장 전략을 가지고 그런 비젼을 가지고 성장하는 것입니다.



가치 실현



스타트업을 시작하는 경우, 특정 표어들을 마음에 품고 가는 경우들이 많이 있습니다. 그러니까 사회의 문제를 해결하려고 한다던지, 특정 제품군에서 남보다 뛰어나게 혹은 남보다 저렴하게, 혹은 깨끗하고 투명한 것들을 주고자, 사회 의지와 가치들을 가지고 있는 경우가 많습니다. 돈만 벌려고 하는것보다는, 다양한 가치들을 실현하고자 하는데, 그 가치의 실현이 또한 대표님들의 이상과 철학을 담고 있는 경우가 많이 있습니다.



MVP 확립



스타트업 애자일 방법론에 많이 나오는 단어중에 하나입니다. Minimum Viable Product 최소로 실행가능한 제품이라는 뜻인데요. BM에서도 많이 나오는 용어 입니다. 어떤 서비스가 실행하기 위해서는 이런 MVP 가 확립되어야 하는데, 여기에 살이 붙어지면서 서비스는 성장을 하게 됩니다. 이런 최소한의 것들이 없다면, 목적도 없고, 방향도 없는 서비스가 되겠죠. 이 MVP 확립도 사실상 쉬운일이 아닙니다. 재미있는 아이디어가 있어도 이 MVP 의 확립을 하는 것, 대표들이 추구하는 바가 아닐까 합니다.



BM 구축



비지니스 모델, 돈이 되는 서비스가 되고자 합니다. 많은 기업들은 이 BM 없이도 돌아가거나 동작하기도 합니다. 투자금으로 돌아가거나, 혹은 미래에 가치들을 활용하기도 하고 결론적으로 잭팟이 터지면서 BM이 생겨나기도 합니다. 하지만 드문 경우로 그러하고, BM 이 없으면 영업이익이 없고, 결국 적자의 폭으로 말미암아 회사는 곧 사라지고 맙니다. 따라서, 마케팅을 하든 서비스를 굴리든, 직원을 뽑든 이 BM 이 완벽해야 하는데요. 이 비지니스 모델을 고려하지 않으면, 또 이것을 무시하고 공격적인 투자를 하다보면, 결과적으로 돈과 사람을 모두 잃게 될 수 있습니다. 그래서 개발자나 디자이너중에서 꼼꼼히 따지는 사람들의 경우 이 BM이 확실한지를 묻고 함께 하는 경우도 있습니다.



단기성 프로젝트에 그치는 것이 아니라 계속 함께 갈 사람을 찾는 일



대표 입장에서 외주보다 팀원을 찾고자 하는 경우는 그러합니다. 외주는 빠르게 완성하고 끝을 낼 수도 있지만, 그것을 유지보수하고 성장시켜 줄 사람이 없다면, 그 서비스는 그냥 죽어버린 서비스가 될 수 있습니다. 그래서 함께 하는 사람을 찾아서 계속 성장 시켜주기를 바랍니다. 그렇기 위해서는 준비가 되어있어야 겠지만 말이죠.



서비스의 성장에 필요한 시드머니, 성장에 필요한 마케팅 머니



대표가 필요한건 아무래도 돈입니다. 시드 머니가 있어야 하고, 마케팅 머니가 필요합니다. 투자자를 통해서 예비 창업 패키지나, TIPS, 청년 사관학교 등등 여러가지 국내 기관들의 문을 두드려 보기도 합니다.



사람을 찾을 수 있는 곳



평소에는 인맥에 관심을 갖지 않았다고 하더라도, 직접 사람을 구해보게 되면, 생각보다도 사람이 없다는 것을 실감하게 됩니다. 이유는 경기가 어려운 측면도 있지만, 경기가 어려울 수록 사람들은 위험에 대해서 더 도전하기 않게 되고 위축됩니다. 그것은 큰 기업도 마찬가지인데, 현금성 흐름을 확보하기 위해 혈안이 됩니다. 마찬가지도 개인도 위험보다는 안전에 투자하기 마련인데, 결과적으로는 사람 찾기가 더 어려워 집니다. 그래서 대표는 이런 사람 찾을 수 있는 곳이 단비와 같은 곳입니다.



마음이 맞는 사람



설령 여러가지 이유로 사람을 구해진다고 해도, 마음이 맞기란 어렵습니다. 서로의 마음을 맞추는 것은 비단 서비스의 문제가 아닙니다. 서비스에 대한 관점도 맞아야 하지만, 사람의 성향도 맞아야 하고, 일하는 방식도 맞아야 합니다. 하나라도 맞지 않으면 틀어지기 마련입니다. 누가 맞추어야 하는것일까요? 당연히 대표가 돈을 주는 사람이니 대표에게 맞추어야 한다고 생각할 수도 있습니다. 한편으로 반대로 생각하면, 어려운 여건을 함께 해주는 사람이라는 생각을 해보면 당연 한건 없습니다. 같이 맞추다 보면 좋은 일이 생기겠죠!



비젼을 공유할 수 있는 사람



대표가 원하는 사람중에 하나는 비젼을 공유할 수 있는 사람입니다. 드물게도 같은 비젼을 꿈꿀 수 있는 사람들이 있습니다. 하지만 대부분의 경우 비젼은 사람을 움직이게 하지만 배고픔은 사람을 멈추게 만듭니다. 비젼만으로 유지 되는 경우 함께하려고 하던 사람이 아무리 좋아도, 결국엔 힘들어지고 나면 떠나게 되어있습니다. 그 경험을 가진 사람이 다시 이런 일을 할 수 있을까요? 우린 누구나 성공적인 DNA 성공을 유지하고자 합니다. 그렇기 때문에 실패의 경험이 누적되면, 결코 다시 도전하려고 하지 않을 것입니다. 그래서 비젼있는 사람 찾기란 매우 어려운 일입니다. 실패에도 불구하고 다시 일어나야 하니 말이죠.



먹튀하지 않을 수 있는 신뢰있는 사람



먹튀란 단어가 시장에서 쓰이는 바람에 신뢰 체계는 더 힘을 잃었습니다. 계약서 뿐일까요? 시장에 사기꾼이 생겼다는 이야기는 그만큼 시장에서 어떤 일을 하는데 장애가 되는 것들입니다. 정당한 일을하고 정당한 돈을 받으면 당연지사 문제가 되지 않지만, 과도하게 저렴하게 금액을 부르고 일을 해주지 않은채 사라지는 사람들, 일을 크게 벌렸으나 정작일은 하지 않는 사람들, 일을 하기는 했으나 요건을 많이 맞추지 못하는 경우들, 이런 경우들이 쌓이다보니, 대표입장에서도 돌다리를 두드리기 마련입니다. 이런 비용들이 누적되어서, 사업을 포기하고 싶은 심정이 들기도 합니다. 그래서 좋은 사람을 만나는 일이 무엇보다 중요한 것이죠. 신뢰 있는 사람을 찾기 위해서는 다양한 방식으로 그 사람을 알아보고 찾아보고 해야 합니다. 물론 그렇다고 해서 겉모양으로만 모든 것을 판단할 수는 없지만 말이죠.



사업계획서 쓰는 법



대표 입장에서 다양한 투자가 하나의 옵션이라면 이런 사업계획서를 잘 쓰는 것도 하나의 방법입니다. 이미 들어가야 하는 많은 비용들을 아낄 수 있는 방법이 되기도 하니까요? 물론 전략적으로 회사의 일이 아닌 일들을 해야 하는 상황들은 시간이 돈인 회사의 입장에서 실패 요인이 되기도 합니다. 하지만 모든 것들이 잘 맞아 떨어진다면, 돈도 아끼고 성공에도 더 다가갈 수 있을 것입니다.



예비 창업 패키지 | 기타 공모전에 당선 되기



정부 지원 사업이 계속적으로 올라오고 있습니다. 이번에는 비용이 5천만원 내외로 그리 많이 지원되지는 않았다고는 하지만, 그럼에도 불구하고 지원 해주는 금액이 있다는 사실만으로도 도전해볼 가치가 있는 영역입니다. 기타 공모전들도 도전해 보게 된다면, 이런 경험의 누적만으로도 서비스를 가치 있다고 만들 수 있고, 그 신뢰를 바탕으로 좋은 사람을 만나게 될 수도 있습니다.




성향 > 니즈 > 갈등 요인 > 해결 방안


개발자



말이 안되는 일정



갈등 요인으로은 말이 안되는 일정으로 들 수 있습니다. 좋은 회사에서는 개발자나 CTO 가 함께 참여하는 형태로 일정에 대한 논의를 하지만, 좋지 않은 회사에서는 개발자 없이 개발에 대한 이해나 동의 없이 개발 일정이 짜지기도 합니다. 2달에 모든 서비스를 끝낼꺼 처럼…. 이번 년도 안에는 무조건 출시다 같은… 말이 안되는데 헙 소리만 하는 것들이 갈등을 유발합니다.



감당할 수 없는 개발 스케쥴



말이 안되는 일정과 동일합니다. 전체 일정 자체가 말이 안되는 경우도 있지만, 개발 일정만을 따로 때어 두고 생각했을때도 디자인의 일정을 고려한다면, 개발 일정은 훨씬 더 시간이 필요한데도 진행되는 경우도 있습니다. 가끔은 개발자가 많이 투입된 경우는 개발자가 많으니까 가능하다고 생각하는 경우도 있는데요. 다다익선은 여긴 아닌거 같네요. 효율과 별개로 짜임새 있는 일정 개발은 매우 필요 합니다.



기획&디자인이 스케쥴을 맞출 수 없을때



일정을 짜다보면, 개발자의 일정은 괜찮다고 생각했는데, 앞단의 일정이 밀리게 되는 상황들을 많이 봅니다. 나중에는 분명 왜 개발이 늦어졌냐고 이야기가 나올것이 뻔하지만, 제일 마지막에 하는 개발이 덤탱이 쓸때… 분명 할 수 있다고 이야기 한 시점은 앞에서 제대로 넘어올 경우입니다. 이렇게 스케쥴이 꼬이면 어디에 하소연을 하게 될지…



라이브러리도 없는데 만들라고 할 때(무에서 유 창조)



디자인이 넘어 올 때 퍼블리셔가 아닌 디자이너에게 퍼블리싱 스러움들이 요청으로 들어오는 경우들이 있습니다. 퍼블리셔를 뽑아야 할 것 같다고 이야기 하더라도 회사에서는 그 정도의 돈은 없다고 이야기 합니다. 이런 경우 새롭게 움직임을 설정하고 짜야 하는데, 시간이 엄청나게 들어가게 됩니다. 이렇게는 못한다고 이야기 하면, 개발자의 무능력함이 대두 되곤 합니다. 이런 라이브러리가 있다면 그나마 다행, 라이브러리도 없는데 뭔가를 만들어 내기를 원할 때, 큰 마찰이 생기게 됩니다.



쿠팡 같은 서비스 만들어보자고 할때



누구나 포부는 큽니다. 쿠팡 개발자 직원이 700~1000명에 육박하고 있는걸 고려하고 쿠팡 같은 서비스를 만들어 보자고 하는 걸 아는지 모르겠네요. 어 그렇게나 개발자를 많이 뽑아? 왜 그렇게 필요한 걸까? 하고 의구심이 든다면, 개발자가 하는 다양성에 대해서 조금 더 공부가 필요합니다. 갑자기 뜬금없이 우리 페이스북 만들어보자고 하면 모두 안녕이라고 말하게 됩니다.



꿈은 큰데 현실 가능성이 떨어져보일때



쿠팡, 페이스북 이야기과 비슷한 맥락입니다. 현실의 가능성이 정말 중요합니다. 만들 수 있을 것 같은 가능한 모델을 가지고 왔을때 그 때부터가 협상의 시장이 될 수 있습니다. 대화가 통하는 개발자가 없다고 계속 생각해 왔다면, 어디까지 생각을 수정하고 말이 통하는 영역이 어디까지인지 고려해 보는 것도 좋을듯 합니다.



BM에 대한 정확한 모델 없이 플랜이 정신없는 것이 눈에 보일때



비지니스 모델에 대해서 대표는 고민해야 합니다. 이것을 개발자가 대신해 줄리가 없습니다. 하지만 개발자 입장에서 플랜이 없다면, 방향없는 배에 올라타는 느낌일 수 있습니다. 최소한 먹고 살 수 있는 계획을 눈으로 보여주어야 조금이라고 움직일 수 있을 것입니다.



개발을 하는 시간이 아깝다고 느껴질때



개발 하는 시간이 아깝다고 느껴지는 순간은 개발자에게 너무나 많습니다. 게시판 만들기 같은 반복 작업, 로직 수정 같은 반복 작업, 끝없은 일의 양, 끝없는 요구사항, 결과를 알 수 없는 시스템, 같은 기술 작업, 새로움의 부재 등등 좋은 사람들과 함께 하면서 느끼는 좋은 에너지와 그 결과들은 개발자에게 개발에 대한 프라이드를 만들지만, 반복적인 작업과 개선이 없는 프로세스들은 개발자들에게 피로감을 누적시켜 줍니다. 계속 같은 문제로 소통이 안된다고 느끼셨다면, 개발자도 동일하게 그 부분이 개선되지 않음을 피로해 하고 있을 수 있습니다.



레거시를 만져야 하는 상황



개발자 입장에서 큰 회사의 경우 소스를 바꾸고 싶어도 바꿀 수 없는 경우들이 있습니다. 그 소스를 바꾸는 작업이 거의 프로젝트를 진행해야 가능한 수준의 경우 마치 큰 산을 바라보면서 경이로워 하듯, 이 소스를 보고 경이로워 하면서 도저히 난 안되… 라고 생각해 버리고 맙니다. 이런 상황속에서 할 수 있는 것은 현상 유지 입니다. 괜히 시작했다가 끝을 봐야 할 수도 있으니까요!? 물론 예산만 충분하다면…..



억지로 남의 소스를 뜯어보는 상황



레거시를 분석해야 하는 경우들이 이와 같습니다. 또한 잘 짜여진 소스도 있고 아닌 소스도 있지만 남의 소스를 보는 상황은 늘 크게 달가운 상황들은 아닙니다. 이런 이유가 있겠지하고 분석하더라도, 이건 왜그렇게 했을지 이해가 가지 않는 상황들은 매우 피로도가 높아지는 상황중의 하나입니다.



개발에 대해 간섭 받는 상황



개발에는 집중의 시간이 필요합니다. 집중하기 위해서 소모되는 시간이 필요하고, 또 그 집중의 시간이 깨지면 다시 집중하는데 까지 또 걸리는 시간들이 있습니다. 따라서 개발자가 조용히 침묵하며 개발하고 있는 순간에 건드리는 사람은 갈등의 사람으로 당첨입니다. 뭐 사람마다 이 딜레이 시간은 다를 테지만 말이죠.



돈이 안되는 일 때문에 일정 스트레스 받을때



돈 되는 일의 일정의 스트레스는 아 야근비를 치환한다고 마음의 긍정적 변화를 만들고 더 오랜시간 일을 하더라도 마음의 문제에서 자유로워 지기도 합니다. 다만 돈이 안되는 일이 딜레이 되거나 일정의 압박에서 자유롭지 못하게 되는 경우는 과감하게 그 일을 버리려고 하는 순간도 찾아옵니다. 스트레스가 이만저만이 아닐테니 말이죠. 적절한 순간에 포상이 필요한 이유입니다.



지인 찬스 때문에 고통 받는 순간



디자이너도 함께 겪는 고통중에 하나 입니다. 지인이라는게 친구인지 친구의 친구인지, 혹은 그냥 아는사이 였는지는 몰라도, 어쩌다 엮이게 되었을때, 관계의 관계를 생각해서, 안하무인하는 사람에게 도무지 어떤말도 할 수 없게 되었을때 가장 위험합니다. 암이 아마 이때 걸리는 걸지도 모르겠네요. 지인간의 관계가 끊어지고 싶지 않다면 좋은것만 소개해주시길 간곡히…



디자이너가 이미지를 잘라서 주지 않고 통 이미지를 줄때



디자이너와의 소통 문제에 있어서 다양한 문제들이 있을 수 있지만, 픽셀의 문제 모바일 사이즈의 문제, 그리고 RGB 색깔 배열의 문제 등등 다양하게 디자인과 관련된 문제들이 생길 수 있습니다. 특히나 디자이너가 처음인 경우에디자인을 다하고 나서 통으로 넘겨주는 경우가 있는데, 웹의 경우 혹은 앱의 경우라고 하더라도 서로가 난감할 수 있습니다. 이 경우에는 심지어 PSD 파일을 달라고 요청이 오기도 하는데 디자이너 입장에서도 매우 난감해지는 상황입니다. 따라서 이런 일이 없게끔 서로가 어떻게 디자인을 쪼개서 주어야 하는지 협의가 먼저 시작되어야 할 것입니다.



신입때는 원래 굴러야 한다고 별뜻없이 야근 시키는 사수



개발자 입장에서…. 혹은 여타 다른 직군도 마찬가지 입니다. 신입 때 굴러야 하는것은 알겠으나, 야근안해도 충분히 잘 성장하는 경우가 많습니다. 왜 꼭 힘들어야만 성장한다고 생각하는지 … 야근 하지 않는 시간 학원을 가는 사람도 있다는 것을 알았으면 좋겠네요. 구르면 구를 수록 돌이 될 뿐입니다.



기술에 대한 설명 없이 왜 못하냐는 타박 & 비교



누가 설명 좀… 회사의 경우에 여러가지 이유로 타박하기 마련입니다. 제대로된 문서조차 없는데 왜 못하는지 왜 안되는지, 누구는 그냥 한다더라 라던지 비교와 타박들은 신입의 개발자들의 의욕을 꺽는 요인입니다. 처음부터 잘하는 사람이 많으면 그 사람을 뽑던지요… 아니면 경력을 뽑거나, 신입을 교육시켜서 하려고 마음먹었으면 제대로 잘 가르쳐 줄 수 있는 사람부터 있어야 합니다.


디자이너



퍼블리셔가 없는데, 퍼블리싱을 해야하는 상황



퍼블리셔가 없는 회사들이 많다보니, 퍼블리싱의 그 모호한 경계속에서 누가 이 것을 할 것인지에 대해서 눈치 싸움을 하는 경우들이 있습니다. 이런 것을 해주는 사람이 있다면 개발자 입장에서는 매우 편하지만, 디자이너 입장에서 이것까지 해야하는 경우가 생기면 매우 불편해 집니다. 디자인에 집중할 시간이 없다고 말이 분명 나오기 마련입니다. 돈만 훨씬 더 많이 주신다면 생각해 볼 여력이 생기겠지만 꼭 그렇지 않은데도 퍼블리싱을 해야 하거든요…



개발자와 pt, pixel의 안맞는 문제로 안맞는 경우



개발자들의 용어와 디자이너의 용어가 다른 경우들이 있습니다. 일러스트레이터, 포토샾을 하다가 개발자와 또 이런 부분의 접점때문에 고통스러워 하는 부분입니다. 20pt와 20px 의 차이 등등 여러가지 다른 용어들 때문에 고통스러운 경우들이 있습니다. 재작업이 필요할 수 있기 때문입니다. 안드로이드의 경우는 또 이런 기기별로 다른 디자인 때문에 또 고통을 한번 더 받게 됩니다. 디자이너와 개발자들이 갈등을 겪는 요인입니다.



Css 로 처리해도 되는 데 모두 이미지로 뽑아달라고 하는 경우



퍼블리싱 문제 입니다. 개발자가 css 를 안다면, 좀 더 쉬운 문제가 될 수 있지만, 서로가 퍼블리싱을 잘 모르는 경우 이미지로 모든 것을 대체하려고 할 수도 있습니다. 예를 들어 버튼의 경우 radius 를 주면 되는 것을 이미지롤 뽑아서 적용해 하는 경우가 생길 수도 있거든요. 디자이너 입장에서는 이렇게 모두 이미지를 짤라서 주어야 하는 일이 고통 스러운 일입니다.



일정이 너무 촉박할때



디자이너와 기획자와의 갈등 요인이 되기도 합니다. 늘 촉박한 것이 시간이고 일정이지만, 일정의 제일 앞을 차지하고 있는 디자인의 경우 컨펌이 떨어지지 않으면 개발일정이 계속 연기될 수 있습니다. 뭔가 앞을 차지하는 일정이기 때문에 일정 문제는 제일 큰 갈등 요인이 될 수 밖에 없습니다. 그래서 조금은 수정에 대한 계약이나 단가등을 고려한 계약이 나은 경우도 있습니다.



대표가 너무 추상적으로 요구할때



앞서 설명이 되어있지만, 대표나 기획자의 요구가 너무 추상적인 경우 해당 문제에 대해서 표현하고 싶어도, 그 요구사항 만으로는 그림을 그리기 어려운 경우가 많습니다. 서비스를 표현하려고 할 때 디자인의 기술적인 부분도 존재하겠지만, 어떤 서비스의 색깔은 기술로는 한계가 있기 때문입니다.



기획자가 중간에서 일정 조율을 못할때



일정의 부분에 있어서 개발자와 갈등을 겪기도 하고 기획자와 갈등을 겪기도 하는데, 이 일정이 타이트한 상황에서 늘 마음이 급박하고 실수가 잦아 질수 있습니다. 숙련된 경우 조금 여유롭게 시간과 일정을 조율할 수 있지만, 그게 아닌 경우는 이 부분에서 매번 틀릴 수 밖에 없습니다. 일정을 늘려주지는 않되, 조율을 해야 하는 상황이니까요.(이게??)



요구사항이 바뀌면 시간이 당연 늘어나야하는데 일정은 그대로고 요구사항이 변경 될때



당연한게 없습니다. 요구사항이 자주 바뀌는데 일정은 그대로인 경우가 다반사입니다. 요구사항이 변경되었을 때 그것을 감안한 일정의 변경이 일어나지 않을때 한숨만 나오는 경우도 있습니다. 누군가에겐 자잘한 수정이 또 누군가에게는 자잘하지 않은 수정일 수 있으니까요.



팀프로젝트의 경우 개발이 지연되어서 결과를 보기 힘들때



팀 작업, 토이 프로젝트에 참여하는 경우, 개발 기간이 길어지는 경우가 많습니다. 사이드 잡이거나, 본업이 있기 때문인데요. 함께 참여해서 결과를 보고 싶은 디자이너 입장에서는 이 기다리는 시간이 엄청 길게 느껴지기도 합니다. 그래서 결과도 보지 못한채 이탈하기도 하는데, 이 때까지 들어가는 시간들을 참기에는 인내의 한계는 짧습니다.



처음 기획하고 디자인한 결과물들이 개발 상황 때문에 점차 변모 되어갈때



기획 & 디자인이 깔끔한 상황만 있는것은 아닙니다. 개발이 불가능한 이유로 떨어져 나가는 기획량에 비례해서 디자인 요소들도 말없이 삭제 되기도 합니다. 여기에 갈등 상황이 초래 되기도 합니다.



자꾸 폰트 크기가 처음 계획과 달라져 갈때



폰트는 민감함 요소입니다. 디자인의 한 부분이기도 하지만, 가독성의 이유로 모든 폰트들은 늘어나거나 줄어들고는 합니다. 디자인 입장에서는 디자인 자체가 파괴된 느낌을 지울 수 없는데요. 물론 넘어갈 수도 있지만, 한 켠에 마음에는 찝찝한 것이 사실입니다.



대표가 시켜놓고 잊어버릴때



일정 문제 중에 하나인데, 일을 시키고 잊어버린채, 또 다른 일을 시키는 경우입니다. 결과를 보지 않은채로 일의 업무만 가중되고, 이 가중된 업무를 고려해서 일정이 짜지지 않을 때 답답함을 느끼게 됩니다.


기획자



디자이너가 일정내 못한다고 할때



기획자의 대부분의 시간과 관점들은 많은 관리 포인트가 있지만, 시간의 엄수에 대부분의 포인트가 있습니다. 많은 것들을 덜어내더라도 일정에 대해서는 지키고자 하는 것이 대부분입니다. 가이드를 포기해야 할 수도 있고, 많은 부분을 약식으로 처리해야 할수도 있습니다. 어찌 되었든 일정내에 할 수 없다고 하게 될 때 갈등 요인이 발생합니다.



개발자가 일정내 못한다고 할때



개발자는 죽어도 할 수 없다고 사수할 것입니다. 기획자가 그 일정을 맞출 수 있게 해주려면 많은 것을 덜어내어야 할 것입니다. 완료의 기준이 엄청나게 달라지는데 많은 것들을 포기해야 일정을 맞출 수 있게 될 것입니다. (문서는 기대도 못할 것입니다. )



개발 일정이 여러 개발자에게 물어보면 다 달라서 감잡을 수 없을때



개발 일정이 안맞는 경우, 이게 정말로 그렇게 오래걸리는 일인지에 대해서 의구심을 품기 마련입니다. 하지만, 다른 개발자에게 물어본다고 별반 달라지지는 않습니다. 사람마다 생산 속도가 다르고, 또 할 수 있는 범위가 다르고, 남의 일이면 더 쉽게 느껴지기도 합니다. 조언을 구하고 그 조언을 기준으로 삼는 우는 범하지 않으시길 추천드립니다. 어찌 되었든 이렇게 다른 기준이 생기면 또 개발자와 갈등의 요인이 되기도 합니다. 믿어야 하는 개발자를 두고 다른 사람의 이야기를 믿었다는 양상을 띄게 될테니 말이죠.



대표가 일정 맞추라고 쪼는 타이밍



기획자의 입장에서의 또 다른 고충은 대표의 일정 관리 입니다. 대표 입장에서 상세하게 현재 상황에 대해서 보고 받지만, 실제로, 많은 부분이 누락되고 누수가 일어나기 마련입니다. 일정을 맞출 수 있냐고 물어볼때 난감한 기획자는 최대한 이 일이 가능하게 하게끔 하기 위해서 많은 부분들을 빠르게 처리하게 됩니다. 물론 아예 가능하지 못한 경우도 많습니다. 갈등들은 여기서 발생 됩니다.



중간에서 일정 조율, 감정 조율을 모두 해야하는 타이밍



이리 치이고 저리 치이고, 이런 감정 조율의 결과가 좋지 않을때, 그리고 일정 조율이 잘 맞지 않아서, 힘들때 갈등이 일어나게 됩니다.



덜어내야할 걸 덜어내야 일정을 맞출 수 있는데 못덜어낼때



기획자가 덜어내는 역할을 해야하는데, 대표가 그 역할을 해준다면 더할 나위 없지만, 대부분 서비스의 크기가 성공여부를 결정 짓는것처럼 이것저것 해야한다고 느끼는 시기에는 이런 덜어내는 것에 대해서 들리지 않습니다. 그럼 기획자 입장에서도 핵심만 살리고 나머지를 덜어내는것을 하기가 힘들어지는데 이때 대표와 갈등하게 될 수 있습니다.



너무나 복잡하고, 많은데 정리되지 않은 고객의 요구사항



고객은 대표가 될 수도 있고, 고객사가 될 수도 있고, 대중이 될 수도 있습니다. 요건과 요구사항을 내는 입장이 정리가 되어 있지 않을때 기획자는 이런 정리를 요구 받기도 합니다. 정신 없이 많은 자료중에서 가치있는것과 필요 없는 것을 구분하고, 서비스에 필요한 것을 남기도 고객이 원하는 뷰를 설계해서 가져다 주고 컨펌을 받는 일, 본연의 일일수는 있지만, 가끔 이 요구 사항이 진짜 해주길 원하는게 뭔지 잘 모르겠는 난감한 상황에서 또 갈등은 일어나게 됩니다.



생각과 다른 프로세스



대부분 일을 할때는 순서가 있습니다. 요구사항이 있고, 회의하고, 문제를 찾아내고, 해결방법과 적절한 자원들을 배분 하는 것입니다.


물론 이 순서들은 늘상 회사에 따라 대표가 누군지에 따라 달라질 수 있습니다.


하지만, 이런 프로세스의 형태가 없고, 회의도 없고, 기승전결 없이 기결로 끝나고, 어떤 반론도 제기할 수 없이 수용해야 하는 입장이 되거나 협의가 불가능한 차원이라면, 프로세스가 없다고 느껴집니다.



내 생각이 개입될 요소가 없을때



기획자의 입장에서 경험이 풍부한 경우, 대표가 의존하거나 의지하면서 권한이 생깁니다. 간혹 신입 기획의 경우, 혹은 대표의 파워나 의지가 강한 경우, 경험이 개입될 여지보다는 그 대표의 대리인인가 싶을 정도로 대표의 생각대로 기획을 해야하는 경우들이 있습니다. 물론 대표의 마음을 잘 파악해서 해당 부분을 기획해주고, 거기에 문제점을 잡아서 수정해주고 하는 것이 능력이지만, 한편으로는 납득되지 않는 것을 이해하거나 처리해야하는 순간들은 쉽지 않은 순간들 입니다.


마케터



성과가 안나오는 이유에 대한 해답을 찾으라고 요구하는 경우



마케터의 입장에서 고민해야하는 영역이긴 합니다. 다만 기존에 잘나오던 클릭율이 갑작스럽게 잘 안나오는 이유를 찾기란 너무 어려운 영역입니다. 문제가 너무나 산발적이고 복잡한 형태로 발생하기 때문입니다.


여러가지 환경 요인이 순식간에 변하는데


일례로


중국과의 관계변화, 무역수지 변화, 주식상승, 비트코인 주가, 한미 동맹 관계, 부동산 경직, 페이스북 주가 하락, 페이스북 정책 변화, 신규 기업 상장, 반려동물에 대한 기사와 인식변화


이 모든 것들이 마케팅의 결과와 연관이 있습니다. 비약이 아닌가 싶은 정도 이지만, 때로는 언론이 무엇가를 팡팡 때릴때 타이밍이 꼬이면, 홍보를 하고 있는 것들이 무색해질 정도로 묻히기도 하기 때문입니다.


이런 입장에서 이런 요인을 파악하고 분석해야하는 것은 너무 어려운 일입니다. 인과 관계가 하나인 경우는 답을 찾기 쉬워도 복합적인 경우는 그것들의 이해관계가 모두 연결 되어 있어야 할테니 말이죠.



SNS의 잘못된 믿음



마케터를 하는 입장에서 툴과 도구는 다양합니다. 대표입장에서 마케팅이 눈에 보이지 않기 때문에 그 평가는 사용자가 몇명이 보아서 노출 되었는지 몇명이 클릭했는지, 얼마나 사용자가 유입되고 있는지 등등이 지표가 되곤 합니다. 그러다보면 마케터가 SNS를 하지 않을때, SNS를 해서 뭔가 해야하는거 아니냐고 이야기 하기도 합니다. SNS는 마케팅의 하나입니다. 때론 블로그가 되기도 하고 SEO를 쓸수도 있고 SNS 상에서 따로 계정을 키우지 않고도 마케팅 비용을 태워서 효율을 높여볼 수도 있습니다. 각각의 마케터의 성향과 기법이 있는데 존중 받을 필요가 있습니다. 물론 그 성과나 결과는 어떤 방식으로든 필요하겠지만 말이죠. SNS는 시간과 관계가 들어가는 노력이 필요하고, 단기간 성과가 나지 않을 수 있는 대목입니다. 그 점도 염두해야합니다.



마케팅 도구의 진화



너무 많은 마케팅 도구들 때문에 선택의 문제는 갈등 요인이 되곤 합니다.



다양한 마케팅 컨셉과 교육의 필요



마케팅에 대한 컨셉이 필요한데 이 부분이 없는 경우, 그리고 마케터 입장에서도 교육이 필요하지만, 이런 부분에 대해서 직접 발품을 팔아야 하는 경우 보이지 않는 불만과 갈등 상황이 생길 수 있습니다.



스토리 텔링의 한계



마케터가 회사를 성장시킬수 있는 많은 요인중 하나는 스토리 텔링입니다.


스토리텔링을 하려면 회사내에 스토리가 있어야 하고, 성공사례가 있어야 하고, 또 성장에 대한 맥락이 존재해야합니다. 이 것을 뽑아 내려고 아무리 노력해도 그 것을 찾을 수 없다면, 무에서 유를 창조하라는 소리가 아닌가 합니다.



회사가 제대로 성장해야 마케팅할 내용이 존재



마케터와 회사의 성장은 운명을 같이합니다. 물론 제품이 좋아서 회사가 성장하는 경우와 해당 제품의 특성을 잘 살린 컨텐츠가 바이럴을 타는 경우도 있고, 마케터 한명의 아이디어와 컨셉 때문에 회사가 유명해지는 경우들도 있지만, 대부분은 회사의 성장이 뒷받침 될때 마케터는 회사나 제품, 서비스를 어필할 수 있는 부분이 생기게 됩니다. 그게 없다면 땅을 열심히 파다보면 뭐가 나와야하는 상황이 될수도 있는거고 .. 암튼 먹고 사는일은 힘든 겁니다.



제품을 타게팅하든가, 회사를 타게팅하든가, 사람을 타게팅 해야하는데 핵심이 없는데 마케팅 하라고 하는 경우



뭐가 없는데 자꾸 마케팅만으로의 승부를 요구할때 깊은 내면에 올라오는 녀석을 관리해줘야 합니다.



전략의 부재



대부분은 전략이 있습니다. 부동산을 활용한 곳은 부동산의 내부를 얼마나 잘보여줄 것인가, 혹은 고객에게 경험을 얼마나 빠르고 손쉽게 전달할 것인가에 집중하며 서비스를 손봅니다. 만약 컨텐츠회사라면 좋은 컨텐츠의 확보와 사용자의 중독을 전략으로 삼을 수도 있습니다. 사람이 목적인 곳에서는 좋은 사람을 섭외해서 맨파워에 집중하기도 합니다. 아무런 전략이 없다면 마케팅에도 전략을 짜기 어렵겠죠. 함께 전략을 논의할 필요가 있습니다.



서비스의 완성도 문제



서비스가 완성되기도 전에 서비스가 알려지길 바라는 사람은 없을 것입니다. 어느정도 뼈대는 갖추어야 마케팅을 해도 성과를 볼 수 있습니다.



권한의 부족(사업 비용 집행 권한)



마케팅을 할때 제일 부족한건 자금입니다. 이런 자금 집행 비용이 없는데 마케팅을 해야하는 순간이 제일 난감하고 어려운 상황입니다.


스타트업 대표



빠른 개발



속도가 생명인 입장에서 사실 탄탄한 개발에 관심을 가지기 어렵습니다. 나중에 너무 빠른것에 집중하다가 유지보수에서 다시금 후폭풍을 맞이하기도 하지만 현재를 살아가야하는 대표입장에서는 현재 서비스가 얼마나 빠르게 나오느냐가 주 관심사입니다. 이 부분이 안맞으면 갈등이 생깁니다.



정확한 일처리



정확한 일처리, 신뢰와 믿음은 버그가 없는 것에서 생깁니다만, 개발자의 입장에서는 버그가 아예 없을수 없습니다. 처음 일을 시켜보는 대표입장에서는 여러가지 요인과 변수때문에 개발이 지연되는 상황이 이해되지 않고 그 요인도 개발 요건에 포함되어있는것이 아닌가 싶습니다. 이런 깔끔하게 처리되기를 요구하지만 늘 바뀌는 상황들은 갈등 요인입니다.



MVP,BM을 실현해줄 팀원



기본적인 MVP와 BM을 만들어줄 팀원은 필수적 입니다. 하지만 이런 목표의식은 때로 팀원에 대한 목적의식만 남고 팀원의 갈증들은 바라보지 못하게 될 수도 있습니다. 누구나 이루고자 하는 바가 있는데 함께 이루려는 것인지 그렇지 않은지 점검이 필요합니다.



적은 비용으로 고효율



비용을 적게하는 것, 작은 기업일수록 추구하는 바입니다. 큰기업도 마찬가지로 비용을 줄이고자 하지만 제도적인 차원 때문에 막혀있는 요인들이 있습니다. 작은 기업일 수록 그런 부분이 취약하기 마련입니다. 효율을 추구하다 보면 때로는 그 잦은 과정 자체가 비효율적으로 변할 때도 있습니다. 그리고 제때에 적합하게 연봉을 올려주지 않는다던지 기존의 가치들을 무시한다면, 남는 사람이 없어질 수도 있습니다.



처음엔 지분 쉐어, 이후엔 지분 희석



대표의 태도 변화는 팀원들의 머리를 아프게 하는 요인입니다. 처음엔 무엇이든 줄듯하다가, 먹고 살만해지고, 서비스가 성장하면 서비스를 위한 일이라는 명목으로 기존의 지분체계를 확고히 한다던지, 지분을 사들이거나, 여태 팀에서 가장 열심히 했던 사람에 대한 처우나 가치들을 평가절하하는 경우도 있습니다. 인간적으로 너무 악독한 부분이지만, 회사의 경영상 회사 대표의 지분은 51프로 이상이 되어야할 필요가 있고, 투자를 받다보면 지분의 희석은 비일비재한 일입니다. 조금 더 클리어하게, 해당 부분에 대해서 명쾌하게 정리해주고, 노고를 치하하면서 기존의 지분을 헐값이 아니라 가치를 인정해주면서 사들이는 경우는 인정하지만, 그외 헐값에 가져간다던지, 스톡옵션을 행사할 수 있는 시기가 다가왔을때 어떤 방법으로든 내쫓는다고 한다면, 그 기업을 다시는 돌아보지 않을 것입니다. 잠깐 눈을 감았다가, 큰일을 도모한다는 측면으로 이런 일들이 일어날때 선의의 피해자들이 생기고, 결과적으로는 시장에서 믿음과 신뢰가 사라집니다. 누가 로켓이라는 말을 쓸 수 있을까요. 망가진 로켓입니다. 늘 고장 나니까요. 좋은 BP 사례가 많이 나오길 바랄 뿐입니다. 이런 사례가 누적되면, 결코 화합은 없을 것입니다. 그래서 신뢰가 중요합니다.



최신 트랜드에 발맞추는 인재 섭외



트랜드는 늘 변합니다. 트랜드에 따라서 인재를 섭외하려고만 하게되면, 실제로 비용부터 시작해서, 범용성을 잃어버리도 합니다. 한때 루비온레일즈가 유행하면서 그렇게 개발을 진행후에 유지보수가 어려워서 다시 자바로 전환하는 경우도 종종 보게되는 데요. 언어의 선택부터 시작해서 어떤 인재를 고용해야하는지의 문제도 중요한 문제입니다.



인공지능, 머신러닝에 쏠리는 경우



최근 AR, VR을 비롯한 4차산업혁명이라는 모호한 단어안에 인공지능과 머신러닝의 키워드가 들어가면서, 거품이 많이생겼습니다. 물론 데이터 산업은 꾸준히 성장하고 있고 기존의 데이터 관련 직군의 사람들이 있지만, 이 데이터를 어떻게 활용해야 좋은 성과가 나는지 그리고 학습은 어디에 무엇을 학습시켜야 하는지 뚜렷한 목적 없이, 이 단어를 회사안에 넣기 위해서 인공지능과 머신러닝을 쓰는 경우가 있습니다. 댓가는 비싼 인건비를 치러야 할 것입니다. 그리고 그 결과는 큰 기업이 얻었던 성과 없음과 같은 비슷한 결과에 도달할 수도 있겠죠. 물론 이 도구를 어떻게 쓰느냐에 따라서 이 무기는 엄청 날카로운 칼날이 될 수도 있습니다. 다만 잘써야 한다는 겁니다. 안그러면 돈날립니다.



데이터에 대한 관심으로 필요없는 빅데이터 추구



머신러닝과 다른 특면의 빅데이터, 한때 빅데이터의 인기가 치솟았지만, 실상 이 부분을 효율적으로 잘쓰는 기업은 많지 않았습니다. 필요가 없는 경우입니다. 기업의 특성,서비스의 특성을 고려해서 이런 nosql 이나 빅데이터를 활용해야하는데 그런 고려없이 데이터 구조자체를 빅데이터로만 하자고 하면 문제가 됩니다. 정말 많은 데이터를 처리해야하는 입장이 맞는지, 정형화가 필요한 것이 맞는지 고려하지 않고 추진한다면 개발자와의 갈등상황이 예측됩니다.



생각처럼 빨리 구현되지 않을때 생기는 조급함



대표는 결과가 더 중요합니다. 구현되지 않으면 불안해지고 조급해지고, 그리고 확인하게 됩니다. 갈등 구조에 있어서 설계단계의 기다림이 제일 심할 것입니다. 데이터는 그렇게 쉽게 나오지 않습니다.



개발 견적에 대한 정확한 기준 부재



개발의 견적의 표준이 모호해진 부분이 있습니다. 아직 정부의 표준 단가에 의존하기도 하지만, 그러다 보니 단가체계가 업체별로 매우 다르고, 숙련도에 따라 영업 능력에 따라서, 마진율에 따라 단가가 천차만별로 달라지게됩니다. 이 때문에도 많은 갈등이 있을 수 있는데, 너무 큰 거품에 속아도 안되고, 너무 적은 가격인데 제품퀄리티가 떨어지는 문제도 살펴보아야 합니다. 가격 문제는 뜨거운 감자이고, 숙제인듯 합니다.



디자인 견적에 대한 기준 부재



개발견적과 마찬가지로, 디자인당 견적도 업체별로 상이합니다. 페이지별로 책정하는 경우도 있고 프로젝트별, 혹은 개인의 프리랜서 별로 단가가 다르기 때문에 대표입장에서는 선택의 기준이 모호한 부분이 존재합니다.



기획자가 필요한 이유에 대한 의문



대표가 기획을 하는 경우, 그 기획에 대한 가치와 금액에 대해서 의구심을 가지는 경우가 있습니다. 물론 처음부터 기획의 어려움을 느낄때는 기획자의 필요성을 절실히 느끼게되지만, 한편으로 기획자가 뽑힌 경우라면, 만족스럽지 않다고 느껴지기도 하니까요. 이런 경우 기획자와의 갈등 구조가 일어나게 됩니다.



실제로 기획의 어려움



실제 기획을 해보면 어려움들이 있는데 경험적인 부분과 체계적인 부분에의 경험이 필요로 되어지고 커뮤니케이션의 미스로 인한 문제들을 겪다보면 경험의 중요성을 깨닫게 됩니다. 일정의 차질이나, 생각한 방향과 플로우대로 흘러가지 않을때 어찌어찌 아웃풋이 나오더라도 실제 다운로드가 늘지 않거나 계획한 실행들이 좌절될때 어려움을 느끼게 됩니다.



통제할 수 없는 상황들



대표입장에서는 여러 상황들이 변하기 마련인데, 대출이자의 변동, 임금의 변화, 4대보험금의 상승, 개발자의 변심 등등 통제할 수 없는 많은 상황들에 직면하다보면 스타트업을 유지하는데 많은 어려움이 있게 됩니다. 하지만 그럼에도 헤쳐나가는 것은 그 결과에 대한 책임은 자신이 져야 하지만 그 결과에 대한 좋은 피드백도 가져갈 수 있기 때문이겠죠. 여러 요인과 변수 들어가는 비용들을 예측할 수 없다는 점은 매우 위험한 요인중 하나입니다.




성향 > 니즈 > 갈등 요인 > 해결 방안


개발자



말이 안되는 일정 > 경험, 말솜씨



말이 안되는 일정을 해결하는 방법은 사실 거의 전무합니다. 다만, 일정을 변경하는 것이 보통은 더 어려운일이기 때문에 일정을 유지하되, 1차 개발 2차 개발로 나누든지, 분량을 조절하는 방법를 제안하는 것입니다. 대표입장에서도 어느정도의 조율 과정을 거쳐서 완성 혹은 출시가 중요하기 때문에 한번에 모든것을 끝내려는 부분을 조율하면 됩니다.



감당할 수 없는 개발 스케쥴 > 때려침



때려침이 답은 아닙니다만, 제일 좋은 것은 협상이 가능한 사람입니다. 다만 협상이 불가능 한 경우는 질질 끌려다닐 필요는 없겠죠?



기획&디자인이 스케쥴을 맞출 수 없을때 > 개발 분량 조절



개발자 입장에서 앞쪽의 스케쥴이 밀려서 발생되는 누수에 대한 책임을 져야하는 경우 난감합니다. 앞에서 놀았으니 당연 뒤에서는 야근해도 된다는 논리가 밀려올 수 있기 때문입니다. 노는것도 일입니다. 계획과 달라진 공수에 대한 책임을 개발자에게 돌리는 것은 조금 답답한 일입니다. 하지만 돈을 받는 입장에서, 도와줄 부분들은 있습니다. 따라서 일정이 늘어지는 경우 조금 체력과 집중력을 비축하고 일이 몰릴때 조금 더 빠르게 일을 처리하는 부분도 필요합니다. 다만, 그 속도가 개발자의 업무처리 기준이라고 대표가 오해하지는 않았으면 좋겠네요.



라이브러리도 없는데 만들라고 할 때(무에서 유 창조) > 비슷한 것으로 추천



없는 것을 만들라고 할때는, 최대한 비슷한 것을 추천하는 것도 방법입니다. 미리 비슷한 라이브러리를 획득하고 있으면 개발시간은 많이 단축됩니다.



꿈은 큰데 현실 가능성이 떨어져보일때 > 설득 or Run Away



대표가 꿈이 크면 함께 하면 뭔가 될 것 같지만, 이것 저것 현실 가능성을 살펴보게 됩니다. 이런 경우 가능성이 보이는 방향으로 개발자는 최대한 설득해야 합니다. 그리고 최대한 될 수 있는 가능성들을 제시해서 최대한 가능한 방향으로 함께 가야 하는데, 만약 이 부분이 합의 되지 않고, 결론이 나지 않을것 같다면, 너무 오래 붙잡고 있을 필요는 없습니다.



BM에 대한 정확한 모델 없이, 플랜이 정신없는 것이 눈에 보일때 > 모델 제시 or Run Away



비지니스 모델이나 MVP를 만들지 못하고, 뭔가 그것에 대해서 다른 서비스와의 차별점이 없고, 성장의 변곡점을 만들지 못하겠다고 느낄때는 BM에 대해서도 한번쯤은 경험한 것들을 공유할 필요가 있습니다. 개발자보다는 당연 대표입장에서 더 많은 경험들을 가지고 있겠지만, 때로는 개발자의 시각이 도움이 되기도 합니다. 현금 흐름을 볼 수 없다고 느낀다면, 이상만으로는 버틸 수가 없습니다. 그 시간에 자기가 일을 받아서 외주하는게 나을 수도 있을 것입니다.



개발을 하는 시간이 아깝다고 느껴질때 > Run Away



보통 개발자로써 시간이 금입니다. 실력을 키우든, 개발에 가치있는 일들을 해야 합니다. 헌데 함께 오랜 시간을 보내어도, 아무런 진전이 없다면, 그리고 성장하지 않는다고 느낀다면, 더 오래 있을 필요가 없습니다. 특히나 업계의 빠르게 변하는 상황을 고려했을때, 한군데 오래 있는것이 결코 좋은 선택은 아닙니다.



레거시를 만져야 하는 상황 > 해야할 일을 하되, 계속 신기술 모색



큰 회사의 경우 죽어가는 서비스, 레거시를 만져야 하는 경우가 발생하기도 합니다. 물론 좋은 회사로 이직할 수 있는 기회가 있거나, 차세대 프로젝트에 참여하는 경우가 있을 수도 있습니다만, 보통은 본인이 책임을 져야 하는 경우가 발생할 수도 있습니다. 일단, 모든 것들을 감당하려고 하지는 않되, 차근차근 천천히 해야할일을 하되, 계속 신기술에 대해서는 받아들이려고 노력해야 합니다. 나중에 아무것도 할 수 없는 상황이 발생할 수 있습니다.



억지로 남의 소스를 뜯어보는 상황 > 최소한의 수정, 차세대를 기다리자



인수인계, 대부분 인수인계는 날치기로 진행됩니다. 뭐가 없는 경우가 태반입니다. 억지로 남의 소스를 보아야 하는 상황이라면 그리 좋은 상황은 아닐 것입니다. 우선은 모두 드러내지는 말고 최소한으로 수정하되, 큰 프로젝트를 모색해 보는 것도 방법입니다. 모두 드러내야 한다면 기간이 정말 많이 필요합니다.



개발에 대해 간섭 받는 상황 > 협의, 조율 || Run Away 능력 스킬업



개발에 대해서 간섭받는 상황이 올땐, 최대한 간섭받지 않는 상황을 만들어야 합니다. 그리고, 그 부분에 있어서 규칙과 회의 시간, 그리고 등등 여러가지 조절할 수 있는 상황들은 조절해야 합니다. 만약 이것이 안된다면, 스킬업을 하거나 아니면… 안녕해야 합니다. 물론 인간은 적응의 동물이다보니, 어느 때까지도 적응할 수는 있으나… 답답한 상황은 감내 해야겠죠..



돈이 안되는 일 때문에 일정 스트레스 받을때 > 과감히 버려야 하는 순간, 돈 더 되는 일로 전환



일정의 스트레스가 받더라도, 돈이 되면 참을 힘이 있습니다. 헌데 이게 일정이 길어지면서 돈이 안되는 것들이라면 너무 오래 참으면 안됩니다. 계약서는 꼼꼼히 보고, 너무 오래 기다리는 부분은 피해야 합니다. 참으면 독이 됩니다. 기술을 가지고 있는 입장에서는 수많은 다른 순간들이 돈이 되는 것들이 많습니다. 때로는 피하는것이 상책입니다.



지인 찬스 때문에 고통 받는 순간 > 관계를 더 돈독하게 하기 위해 정당한 댓가를 요구 (그게 더 오래가는 길)



지인 찬스로 고통 받는 순간들이 오는데, 이 때 오히려 관계를 더 돈독하게 하기 위해서는 정당한 댓가로 정확한 피드백과 좋은 것들을 주는것이 상호적으로 좋은 결과를 줄 수 있습니다.



디자이너가 이미지를 잘라서 주지 않고 통 이미지를 줄때 > 마음을 가다듬고, 잘라야 하는 파일을 알려주서나 제플린 교육



우선 디자이너가 협업에 처음이라고 하더라도, 그럴 수 있습니다. 삐긋하기 시작하면 다시 돌아올 수 없는 강을 건너는 것입니다. 마음을 가다듬고 무엇을 어떻게 잘라야 하는지 알려주거나, 제플린이라는 좋은 툴에 대해서 알려주면서 상호 작용해야 합니다.



신입때는 원래 굴러야 한다고 별뜻없이 야근 시키는 사수 > 숨죽이며 실력을 키우거나 야근 안하는 곳으로 Run Away



회사별로 케바케라는 말이 있고, 부바부라는 말도 요새 나오고 있습니다. 모든 것은 알 수 없다는 것입니다. 회사마다 꼭 한두명씩은 말이 안통하는 사람이 있기 마련입니다. 그리고, 야근도 마찬가지 입니다. 누군가에게는 야근이 엄청난 스트레스인 반면 또 야근이 기본인 사람도 있습니다. 그러다 보면 후임에게 야근을 강요하는 일이 당연한 문화가 되는 곳도 있습니다. 그럴 때는 숨죽이면서 기다려야 합니다. 너무 오래 걸릴수도 있습니다. 결국은 정면 승부하거나 피해야 합니다. 뭐 요새는 많이 바뀌긴 했지만, 여전히 분위기상, 혹은 서비스의 속도상, 일정상, 어쩔 수 없다는 말로 야근하는 곳이 많습니다.



기술에 대한 설명 없이 왜 못하냐는 타박 & 비교 > 실력으로 증명 || Run Away



보통은 실력이 있으면 말을 못합니다. 물론 실력이 있어도 트집잡아서 이야기 하는 사람이 있을 수 있습니다. 정 안되면, 다른 곳이 훨씬 더 좋은 대우일 것입니다. 노력하는 사람이 대우를 받지 못하는 경우도 있지만, 결과적으로는 노력하지 않는 곳이 대우 받는 곳에서는 고인물만 남게 되어있습니다.


디자이너



퍼블리셔가 없는데, 퍼블리싱을 해야하는 상황 > 퍼블리싱 비용 청구 || Run Away



퍼블리싱을 해야 하는 상황들이 옵니다. 퍼블리싱을 배워야 하나 고민이 되기도 하지만, 실제로, 이것을 강요하는 회사에서는 오래 있을 필요가 없습니다. 소양으로 배워볼수는 있지만, 프리를 하면 모르겠지만, 이 영역은 완전히 다른 영역입니다. 회사에 사람을 청구하던지 비용을 청구하던지… 설득해야 합니다.



개발자와 pt, pixel의 안맞는 문제로 안맞는 경우 > 웹 가이드 라인 준수 및 해당 영역에 대한 커뮤니케이션



웹의 경우는 그런일을 별로 없지만, 안드로이드의 경우 모바일에 대응하면서 화면 크기에 대해서 많은 처리가 어렵습니다. 이 부분은 웹에 검색해 보면 많이 나오는데, 이런 단위의 차이점 들을 염두해두고 소통할 필요가 있습니다. 웹이나 앱의 여러가지 문제들을 서로 협의하면서 소통하는 것이 중요합니다.



Css 로 처리해도 되는 데 모두 이미지로 뽑아달라고 하는 경우 > css 로 만들어 주거나, 제플린 활용



버튼의 경우 잘 모르는 개발자의 경우 9개의 이미지로 뽑아달라고 한다던지 할 수 있습니다. css 의 경우 Radius 같은 것들로 처리할 수 있는 부분, 혹은 css 처리 가능한 부분은 처리하라고 이야기 해주어야 합니다. 물론 개발자도 퍼블리싱 지식에 대해서 이해할 필요가 있겠죠.



일정이 너무 촉박할때 > 충분히 시간이 주어지지 않을때 퀄리티를 보장 할 수 없음에 대해 설명



일정이 촉박한데 디자이너에게 많은 것을 요구하는 경우들이 있습니다. 협상이 필요한데, 일단 개발 진행 상황과 맞물려서 조절할 필요가 있습니다. 해야할 우선 순위들을 조절하면서, 개발자와 협의해 볼 수도 있을 것입니다. 모든 페이지를 디자인 하고 넘겨주려면 기한이 너무 길어질 수도 있습니다. 이 경우에는 메인만 먼저 넘기고 구조적으로 메뉴 영역 하나만 넘겨주고 나머지 디자인들은 후순위로 처리 한다던지 하는 방식으로 조금 조율 할 수 있는 여지는 주는 것이 좋습니다. 디자인 시간을 벌면서, 우선순위만 바꾸어도 충분히 개발에서 들어가는 시간들을 확보할 수 있을 것입니다.



대표가 너무 추상적으로 요구할때 > 기존의 사례 위주로 추천, 해당 BP 사를 추천 받아서 해당 컨셉을 약간씩 틀어봄



대표의 요구가 너무 추상적인 경우들이 있습니다. 일단 디자이너 입장에서 여러가지 사례들을 들어가면서, 프로젝트 사례를 비롯해서, 여러 성공한 회사들의 레퍼런스를 보여주면서 이야기 하면, 훨씬 더 수월하게 이야기가 풀릴 수도 있습니다. 똑같지는 않지만, 비슷한 맥락을 찾아가면서 대표도 생각하는 것들을 구체화 할 수 있을 것입니다.



기획자가 중간에서 일정 조율을 못할때 > 금액 조절, 혹은 TO BE 에 대해 요구사항으로 기간적인 부분도 명시



물론 회사의 경우는 금액을 조절할 수 없지만, 프리인 경우는 금액을 조절하도록 요구할 수 있습니다. 혹은 기획의 기간이 늘어나서 발생되는 부분에 대해서는 애초 늘어난 기간에 대해서 감안하도록 이야기를 하든, 처음부터 기간에 대해서 명시하거나 수정사항에 대한 조항을 만드는 것도 방법입니다.



팀프로젝트의 경우 개발이 지연되어서 결과를 보기 힘들때 > 디자인 회수 혹은 다른 개발자 섭외



보통 디자인의뢰나 외주의 경우는 개발이 지연되어서 결과를 보기 힘든 경우는 많지 않습니다. 물론 출시가 못하는 경우도 있지만, 디자인이 끝난 상황에서는 크게 상관은 없는 경우입니다. 하지만 팀프로젝트의 경우는 디자인을 완성했지만, 이 개발이 지연되는 경우가 많을 수 있습니다. 이 때 보통 개발자의 경우 전업이 아니라 부업이나 사이드 스럽게 일을하게 되는데 개발자는 늘 상황이 변하기 때문에 팀프로젝트는 지연되거나 어그러지는 경우가 많습니다. 디자인을 회수하거나 다른 개발자를 섭외해야할 수도 있습니다. 그렇지 않으면 질질 프로젝트가 길어질 수도 있습니다.



처음 기획하고 디자인한 결과물들이 개발 상황 때문에 점차 변모 되어갈때 > 상황에 따라 다름, 회사인 경우 포기



회사인 경우 포기하라는 의미는, 회사를 포기하라는 뜻보다는 결과물이 어떻게 변하든 마음을 내려놓을 필요가 있다는 것입니다. 디자인이 개발이 되면서, 기획자와 대표가 의견을 첨가하면서 점점 변하기 시작하는데 거의 본래의 디자인으로 돌아오기 어려워 지는 경우들이 많습니다. 처음에 애정하는 자식같은 디자인이지만, 이제는 다른 아이로 생각해야 할 수 있습니다.



자꾸 폰트 크기가 처음 계획과 달라져 갈때 > 처음부터 반응형, 혹은 폰트에 따라서 사람들이 느끼는 감정과 느낌에 대해서 미리 설명 그리고 그에 따라서 느낌이 달라질때 생기는 괴리감에 대해서 회피



폰트는 흔하게 바뀌는 결과물중 하나입니다. 미리 폰트 크기의 느낌을 설명함으로써 폰트 크기의 이유를 어필해 볼 수 있습니다. 하지만 그럼에도 폰트는 바뀌어있을 것입니다. 어쩔 수 없는 경우도 있습니다.



대표가 업무를 시켜놓고 잊어버릴때 > 보고생활을 철처하게 함으로써, 해당 일정들을 짤 때 해당 업무의 일정과 고려해서 더 넓게 잡았다는 사실에 대해서 주지



일단 방법은 없습니다. 일정은 스스로 짜는 경우가 많지는 않지만, 일정에 관여할 수 있다면, 스스로 일정에 대해서 관리하고 어필하지 않으면 점점 일이 쌓여도 누구도 관심을 가지지 않을 것입니다. 결과에 대해서 어필하고 일정을 여유롭게 잡을 수 있어야 합니다.


기획자



디자이너가 일정내에 못한다고 할때 > 일정이 얼마나 필요한지를 되묻기



기획자 입장에서는 일정 산정에 대한 기준이 필요합니다. 어느정도의 일정이 필요한지 물어보면서, 조절할 수 있는 영역이 무엇인지를 확인하는 것이 중요합니다.



개발자가 일정내에 못한다고 할때 > 어떤 개발이 공수가 많이 드는지 되묻기



개발자가 일을 못한다고 하는 것을 일의 양이 많다는 말입니다. 업무별로 시간들을 물어보고 체크해보고 할 수 있는 일의 양을 주어야 합니다. 그것이 조율할 수 있는 유일한 길입니다. 업무의 양 조절을 계속적으로 실패하게 되면, 결과적으로 완성을 시키지 못할 뿐 더러, 개발자도 계속 누적되는 피로감 때문에 살 수가 없습니다.



개발 일정이 여러 개발자에게 물어보면 다 달라서 감잡을 수 없을때 > 다른 개발자와 비교 금지, 다만 그 개발자의 역량 믿어주기. 대신 상식적으로 이해가 가지 않는 일정의 경우는 어디에 로드가 드는지 확인하기



개발 일정을 간혹 다른 사람과의 비교과정을 통해서 알아내려고 할 수 있습니다만, 개발자 본인에게 그 일정에 대해서 물어보는 것이 좋습니다. 그리고 TASK 자체를 너무 크고 러프하지 않게 쪼개서 물어보는 것이 좋습니다. 실제로 일을 나누다 보면 더 짧은 일정에 소화할 수도 있습니다.



대표가 일정 맞추라고 쪼는 타이밍 > 대표를 설득하거나, 일정에 대한 감각 키우기



일정을 쪼는 일은 기획의 역할이기도 하지만, 대표에게 내려오는 지시사항이기 때문에 어쩔 수 없는 경우들이 많습니다. 이 경우 이 타이밍을 알고 미리 보고하는 방법이 있습니다. 그리고 개발자에게 물어봐야할 타이밍, 디자이너에게 물어봐야 하는 타이밍들에 대해서 잘 캐치하는 것이 중요합니다. 일정에 대해서는 왕도가 없는데 가만히 있다가는 아무도 아무것도 안할수도 있고, 그냥 마냥 쪼기만 하면 결과도 없고 모두 도망가게 됩니다. 즉 기획자에게는 상황을 인지하고 파악하고 접근해서 결과를 얻어내는 놀라운 능력이 필요합니다.



중간에서 일정 조율, 감정 조율을 모두 해야하는 타이밍 > 우선 최선의 방법이 무엇인지를 찾아내고, 각각을 설득해서 퍼즐을 맞추어야 함



많은 것들을 조율해야 합니다. 많은 트러블들이 나게 되는데, 최적의 방법을 찾아서 문제가 되는 요인들을 덜어내고, 설득해서 퍼즐을 맞추는 작업을 해야 합니다.



덜어내야할 걸 덜어내야 일정을 맞출 수 있는데 못덜어낼때 > 우선 순위 파악하기



우선순위를 파악하고, 덜어줄 수 있는것을 덜어줄 수 있다면 베스트 입니다.



너무나 복잡하고, 많은데 정리되지 않은 고객의 요구사항 > 문서화 작업, 선택과 집중



고객의 요구 사항을 정리할 필요가 있습니다. 그리고 문서화를 잘하면, 고객 입장에서도 정리가 되면서 필요한것과 필요하지 않을 것을 구분할 수 있게 됩니다.



너무 많은 레퍼런스 > 아주 성과가 좋은 레퍼런스를 기준으로



많은 레퍼런스들을 정리해서 성과가 좋은 사례를 기준으로 다시 재 정리해서 잡아볼 필요가 있습니다.



생각과 다른 프로세스 > 기획자로써 프로세스를 정립하고 R&R 강조



프로세스는 보통 회사별로 어떻게 할 수 없는 경우가 많지만 기획자의 입장에서 이 롤을 정의해야 하는 경우가 있을 수 있습니다. 역할을 정의하고, 배분하고 이것들을 정리만 잘해도 사실 개발의 효율을 높일 수 있습니다.



내 생각이 개입될 요소가 없을때 > 회사에서는 회사 업무에 집중하고, 다른 생각과 아이디어는 다른 곳에서 펼치기



기획자의 입장에서 UI 의 기획서만을 작성하는 기획자가 되는 경우 회사의 일자체가 매우 따분하게 느껴질 수 있습니다. 그 경우 회사 안에서 새롭게 역할을 찾아갈 수도 있지만, 아예 다른 것들을 꿈꾸어 보는 것도 방법일 수 있겠죠.


마케터



성과가 안나오는 이유에 대한 해답을 찾으라고 요구하는 경우 > GA 도구 및 서비스 전반에 대한 분석



성과가 안나오는 해답은 사실 찾기가 너무 어렵습니다. 구글 애널리틱스나 네이버 애널리틱스 등등 여러가지 분석 도구와 툴들을 지속적으로 바라보면서 그런 성과에 대해서 분석하는 방식을 연구하는 것도 중요합니다. 그리고 서비스에 대해서 한번 다시 분석해 볼 필요가 있습니다. 서비스 자체가 시장에 필요한지, 다른 경쟁사가 있지는 않은지 등등을 점검해 봐야 합니다.



SNS의 잘못된 믿음 > SNS 의 한계를 설파, 대신 솔루션을 제시



SNS 가 무조건 답이다라는 잘못된 믿음의 경우 한계가 있음에 대해서 설득해야 합니다. 그리고, 대신에 마케터 입장에서의 본인의 해답들을 제시해 보아야 합니다.



마케팅 도구의 진화 > 마케팅 도구 학습



SEO 와 같은 것이나 구글 애널리틱스 등등의 분석도 중요한데, 페이스북이나 인스타, 유투브, 틱톡 등등 여러가지 도구들이 늘어나고 있습니다. 하나만 해서는 살아 남을 수 없는 세상입니다. 다양한 도구들을 배워야 합니다.



다양한 마케팅 컨셉과 교육의 필요 > 교육 참여



교육에 참여할 수 있다면 교육에 참여하게끔 유도해야 합니다.



스토리 텔링의 한계 > 스토리 텔링 이외의 방법 추구



스토리 텔링만으로 한계가 있다면, 그 외에 다양한 것들을 찾아보아야 합니다. 크라우드 펀딩, 관련 업계 교류 등등을 통해서 다양한 가치와 방향들을 찾아야 합니다.



회사가 제대로 성장해야 마케팅 할 내용이 존재 > 회사의 성장 그래프와 비젼을 계속 공유



마케터 입장에서는 회사의 성장에 대해서 비젼을 공유 받아야 합니다. 계속 회사가 성장하는 것에 대한 지표들을 받고서 함께 성장할 수 있어야 할 듯합니다.



제품을 타게팅하든가, 회사를 타게팅하든가, 사람을 타게팅 해야하는데 핵심이 없는데 마케팅 하라고 하는 경우 > 핵심에 대해서 재정의



마케터 입장에서는 제품이든, 회사든, 사람이든 핵심이 중요합니다. 그 핵심을 찾지 못한다면 마케터도 홍보할 것이 없습니다. 함께 그 핵심을 분석해서 솔루션을 제시 해야합니다. 스터디라고 하면, 어떻게 사람을 모을 것인가, 교육이라고 하면 어떻게 하면 더 강사를 섭외할 수 있는가? 펫 시장이라고 하면, 어떻게 하면 사람들이 이 서비스에 더 관심을 가지게 할 수 있을 것인지에서 아주 본질적인 것들을 고민해야 합니다. 그리고 그 마케터만이 가질 수 있는 시각들을 활용해서 만들어 내야 합니다. 시장은 매일 변합니다. 그리고 마케터가 가지고 있는 시각은 곧 돈입니다.



전략의 부재 > 분석에 이어, 성장 전략을 따로 따로가 아니라 함께 논의



성장전략은 대표가 설정하곤 합니다, 하지만 마케팅 성장 그래프는 마케터의 영역입니다. 물론 대표는 이것을 제일 먼저 고려해야하지만, 마케터 입장에서는 이런 성장에 대한 전략을 함께 할 수 없다면 그 다음을 생각하기 힘들 것입니다. 함께 성장에 대해서 논의해야 합니다.



서비스의 완성도 문제 > 서비스에 대해서 핵심 정보 및 가치들을 계속 쉐어링



서비스의 완성도가 곧 서비스 입니다. 이 부분도 함께 공유되어야 합니다. 영업은 팔아야 할 물건을 알아야 하고, 마케터는 홍보해야하는 서비스를 알아야 합니다.



권한의 부족(사업 비용 집행 권한) > 권한이나 비용을 요청



비용이 없다면 요청해야 합니다. 물론 안되면 가망이 없습니다. 돈없이 할 수 있는 아이디어를 다 짜내어도 안된다면 그곳은 힘들다고 볼 수 있습니다.


스타트업 대표



빠른 개발 > 린 스타트업 방식 도입(모든것을 완벽하게가 아니라 뼈대부터 실행)



답은 없습니다. 빠른 개발에 필요한 것은 뼈대를 만들고 시작해야 합니다. 그리고 살을 붙여가면서 시장의 반응으로 하나씩 키워가는 것입니다. 처음부터 너무 큰걸 시도하다가는 자본이 없습니다.



정확한 일처리 > 속도인지 방향인지를 설정



정확하게 일을 처리하는 것도 중요하지만, 속도가 중요한지, 아니면 속도보다는 정확하게 차근 차근 성장할 것인지를 선택해야 합니다.



BM을 실현해줄 팀원 > 비용을 지출할 것인지, 가치를 설득할 것인지 결정



팀원을 찾기 위해서는 대표는 명확한 논리가 있어야 합니다. 이 팀에 함께 해야하는 논리가 필요합니다. 성장을 함께 하든, 뭔가를 줄 수 있던지 그 무엇도 아니라면, 잘나가고 있는 회사에서 대표와 함께할 이유는 없습니다.



적은 비용으로 고 효율 > 애초 불가능(가능한 많은 지식을 가지고 있어야 함)



보통 적은 비용으로 고효율을 창조하고 싶지만, 이것은 불가능합니다. 다만 이미 많은 지식이 있다면 그것이 이미 자본과도 같습니다. 많은 지식이란 많은 시행착오를 의미합니다. 적당한 크기의 서비스를 만들고 적당한 사람들을 모아서 적당히 서비스를 만들어서 적당하게 팔고, 다시 새롭게 반복할 수 있다면 그것은 효율적인 일이 될 수 있습니다. 하지만 보통의 경우 꿈이 너무 크거나 작거나, 혹은 사람들을 과도하게 뽑거나 없거나, 손을 떼야할 시점을 잡을수도 없고 언제 시작해야할 지 그것을 잡기도 어렵습니다. 개발에 전문가가 필요하다면, 시장도 전문적인 사람밖에 살아남기 어렵습니다.



최신 트랜드에 발맞추는 인재 섭외 > 그만큼의 비용을 고려



트랜드에 따라 발을 맞추는 인재들은 인재입니다. 그들은 자기의 몸값을 알고 있습니다. 그렇기 때문에 언어를 선택할때도 어떤 것들을 선택할지는 매우 중요합니다. 시장에 매우 희소성이 있는 개발자나 언어를 선택했다면, 추후 그에 대해서 큰 비용들을 지불해야 할 것입니다. (Node 와 같이 실험적인 언어도 있고 — 안정되었다고는 하지만, 엥귤러와 같이 소수만 알고 있는 프레임 워크도 있습니다. )



인공지능, 머신러닝 > 서비스에 필요한 것이 무엇인지 확인



정말 이 서비스에서 인공지능이나 머신러닝이 필요한지 확인하고 접근해야 합니다. 운영하는 서비스에 필요한 것들을 우선적으로 자원을 설정하고 미래를 접근해야 합니다.



데이터에 대한 관심 > 서비스에 필요한 것이 무엇인지 확인



데이터도 마찬가지 입니다. 서비스에 빅데이터가 필요하지 않다면, 기존의 데이터의 활용과 수집에 대해서 집중하는 것이 좋습니다. 물론 데이터의 사고파는 영역이 증대되고 있기 때문에 데이터에 대해서는 늘 관심을 가져야 하지만, 무분별한 맹신은 독이 됩니다.



생각처럼 빨리 구현되지 않을때 생기는 조급함 > 시간이 약



아마 제일 어려운 것이 조급함을 버리는 것일 것입니다. 서비스의 출시 시점이 지나가고, 출시할 수 없게 될때, 혹은 출시가 되었는데 다운로드가 늘어나지 않고, 유저가 많아지지 않을때 지루하고 먼 싸움이 될 것입니다. 전략을 점검하고, 어떻게 유저를 붙들 것인지를 고민해야 합니다. 조급함 때문에 기획을 바꾸거나 계속 생각이 바뀌어서 틀이 깨지면 함께 난파합니다. 시간이 서비스를 성장 시켜줄 것입니다.



개발 견적에 대한 정확한 기준 > 비교 문의를 통해 견적에 대한 감잡기, 너무 적은 비용기 기준이 되지 않을것



개발은 천차 만별입니다. 하지만 많은 데이터들을 비교해보면, 그래도 좋은 부분이 생길 수 있습니다. 작은 것부터 시작해서 의뢰를 하다보면 가격에 대한 감과 수지타산을 구분할 수 있게 됩니다.



디자인 견적에 대한 기준 > 퀄리티와 가격에 대한 비교(모든 것은 수지타산)



개발과 마찬가지 입니다. 디자인의 경우도 답이 없는 것이, 대표의 마음에 드는 디자인들이 저렴한 디자인일 수도 있습니다. 물론 그렇다고 해서 그 서비스가 망한다는 것은 아닙니다. 디자인은 어느것도 장담할 수 없습니다. 아무리 예쁜 디자인이어도 성공하지 못할 수도 있고, 고객들의 눈은 누구도 장담할 수 없습니다. 따라서 많이 두들겨 보고 판단하고, 가장 적합한 것들을 찾아야 합니다.



기획자가 필요한 이유에 대한 의문 > 기획자와 협업해보기, 기획에 필요한 많은 제반 사항 파악하기



기획자가 왜 필요한지 의문이 들 때는 기획자와 협업을 토대로 기획자의 필요성에 대해 절감할 필요가 있습니다. 그것이 아니라면 직접 기획서를 작성하고 개발자와 협업을 해보는 것입니다. 그로써 기획자에 대해서 이해할 수 있게 됩니다. 작은 서비스나 기능하나에도 많은 부분들이 고민되어져야 하고, 권한의 문제, 입력 수정의 문제를 비롯해서, 자잘한 많은 사항들을 고려하려면 많은 경험이 필요하다는 것들을 알 수 있을 것입니다.



통제할 수 없는 상황들 > 대비하기, 전략 수립 필요



통제 할 수 없는 상황은 말 그대로 어쩔 수 없는 부분들입니다. 하지만 대비할 필요가 있습니다. 여유자금을 확보하는 것부터, 캐시 플로우의 다른 부분을 미리 마련해야 하고, 또한 개발자의 이탈까지도 고려해야 합니다. 따라서 서비스의 언어를 선택할 때도 범용적인 언어를 선택하고, 경우에 따라서 외주로도 바꿀 수 있거나 유지보수를 맞길 수 있도록 하는 것이 중요합니다. 길고 오래, 살아 남아야 서비스가 빛을 볼 테니 말이죠.


대표님의 입장에서 개발자들이 연봉이 얼마일까? 그리고 개발자에게 적절한 보수를 지급하고 있는 것일까? 이런 의문들을 해소해 드리기 위해 간단히 예측 테이블을 작성해 보았습니다.


물론 +- 폭이 넓기 때문에 모두를 포용할 수는 없습니다. 특별히 업계의 평균이 다르고 다양한 오차들은 있을 수 있습니다만, 생각보다 생각하는 것보다도 요구하는 부분이 크다고 생각할 수 있습니다.


마찬가지입니다. 디자이너, 마케터의 입장에서도 다다익선입니다. 다만, 업계의 평균과 주지 않기 때문인 셈이죠. 더 좋은 조건과 더 나은 대안이 있다면 언제든 떠날 수 있을 것입니다. 미래를 보라고 말하지만, 그 언제까지의 미래가 1년 , 3년, 5년 뒤에도 오지 않을 것 같다고 예감 된다면 누가 그곳에 있을 수 있을까요? 누구나 미래가 빨리 왔으면 하는 바람일 것입니다. 미래에 올 자금을 현재에 쓸 수 없듯이 사람을 붙잡는 것도 마찬가지 입니다.


그외 개발자 연봉 팁 (예측된 결과 이며 실제의 기업 정보와는 무관합니다.)


개발자가 꿈꾸는 연봉 테이블


[백엔드]


1년차 3500만 +-1000
2년차 3800만 +-1000
3년차 4300만 +-1000
4년차 4800만 +-1000
5년차 5500만 +-1000
6년차 6200만 +-1000
7년차 7000만 +-1000
8년차 8000만 +-1000
9년차 9500만 +-1000
10년차 1억 +-1000
11년차 1억 1000만 +-1000


[프론트]


1년차 3000만 +-1000
2년차 3500만 +-1000
3년차 3800만 +-1000
4년차 4200만 +-1000
5년차 4800만 +-1000
6년차 5400만 +-1000
7년차 5800만 +-1000
8년차 6200만 +-1000
9년차 6800만 +-1000
10년차 7200만 +-1000
11년차 7500만 +-1000


[풀스택]


1년차 4000만 +-1000
2년차 5000만 +-1000
3년차 5700만 +-1000
4년차 6400만 +-1000
5년차 7000만 +-1000
6년차 7700만 +-1000
7년차 8500만 +-1000
8년차 9200만 +-1000
9년차 1억 +-1000
10년차 1억 1000만 +-1000
11년차 1억 +@ +-1000


개발자 실제 연봉 테이블


[백엔드]


1년차 3000만 +-1000
2년차 3300만 +-1000
3년차 3500만 +-1000
4년차 3800만 +-1000
5년차 4000만 +-1000
6년차 4500만 +-1000
7년차 4800만 +-1000
8년차 5200만 +-1000
9년차 5600만 +-1000
10년차 6000만 +-1000
11년차 6300만 +-1000


[프론트]


1년차 2700만 +-1000
2년차 3000만 +-1000
3년차 3300만 +-1000
4년차 3500만 +-1000
5년차 3800만 +-1000
6년차 4100만 +-1000
7년차 4300만 +-1000
8년차 4700만 +-1000
9년차 5000만 +-1000
10년차 5200만 +-1000
11년차 5500만 +-1000


[풀스택]



1년차 3000만 +-1000
2년차 3300만 +-1000
3년차 3700만 +-1000
4년차 3900만 +-1000
5년차 4200만 +-1000
6년차 4700만 +-1000
7년차 5000만 +-1000
8년차 5500만 +-1000
9년차 6000만 +-1000
10년차 6300만 +-1000
11년차 6500만 +-1000


대기업 연봉 테이블



1년차 4200만 +-1000
2년차 4700만 +-1000
3년차 5300만 +-1000
4년차 5700만 +-1000
5년차 6000만 +-1000
6년차 6500만 +-1000
7년차 6800만 +-1000
8년차 7000만 +-1000
9년차 7300만 +-1000
10년차 7700만 +-1000
11년차 8000만 +-1000


그외 실제 잘나가는 기업 테이블


1년차 5000만 +-1000
2년차 5300만 +-1000
3년차 5800만 +-1000
4년차 6200만 +-1000
5년차 6800만 +-1000
6년차 7400만 +-1000
7년차 8000만 +-1000
8년차 8500만 +-1000
9년차 9000만 +-1000
10년차 1억 +-1000
11년차 1억+@ +-1000



위의 내용들은, 실제 기업 정보를 오픈해서 확인한 사항은 아닙니다. 주변 사람들과 여타 조사를 통해 획득된 정보들을 토대로 작성된 정보이며, 절대 기준이 될 수 없습니다. 참고적으로 재미 삼아 보거나, 생각해 보는 자료로만 사용하시면 될 것 같습니다.


업계에 대한 인식과 느낌들을 대강 서로 알아야 처우들이 개선될 것이라고 생각해봅니다. (다른 업종도 마찬가지이겠죠 )



맺음말


여러가지 직군에 대해서 입장 차이를 정리해보려고 해보았는데요. 아마도 이 입장차이를 안나고 해도 아무것도 달라지지 않을 수도 있습니다. 기존의 입장을 고수하는 이유가 분명히 있을 테니까요.


하지만, 이유를 모르는 것보다는 이유를 조금이라도 알게 된다면, 노력하는 입장에서는 개선할 포인트를 찾을 수 있다는 점이 달라질 수 있는 영역이 아닌가 생각해 봅니다.


대표입장에서는 그 누구도 적은 돈을 받고 일하고 싶지 않고 좋은 대우를 받고자 한다는것을 이해하고, 개발자나 다른 직군도, 대표라고는 해도 어짜피 살아남기 위해 발버둥 치는중이라고 생각하면 조금은 그 부분에 이해가 되는 부분이 생기지 않을까 생각해봅니다.


물론, 당연한건 없습니다. 이해는 상대에게 강요한다고 일어나는 결과가 아니니까요.


노력하다보면, 가치들을 이루어 내고, 좀 더 대접받고 존중받는 순간들이 오지 않을지 생각해봅니다.


이상 직군별 동상이몽에 대한 말을 마칩니다.



작가의 이전글 치킨 모임 - 어느 개발자의 이야기

매거진 선택

키워드 선택 0 / 3 0
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari
;