길게 주저리 주저리 글을 썼다가 다 지웠다.  결론 부터 간단히 말하겠다.

전공 vs 비전공

압도적으로 전공자가 유리하다. 이건 논란의 여지조차 존재하지 않는다. 대부분의 비 전공자들의 안타까움은 잘 이해하고 있다. 나도 20년간의 개발자 경력동안 어느정도 경력자 사이에서는 전공이 의미가 희미해 지는 순간이 온다는 것을 절대적으로 이해한다. 하지만 신입에서는 이야기가 다르다.

'당신이 그냥 전공자를 편애하는 개발 리더 아닌가?' 라고 말할 수도 있겠지만, 내 인생에서 첫 사수가 역사학과 출신 개발자 였다. 엄청나게 코딩을 잘하시는 훌륭한 개발자셨다. 그리고 오랫동안 같은 팀으로 회사를 옮겨도 같이 일하는 클라이언트 개발자는 처음에 뽑을때부터 비전공자 출신이였다. 나도 비전공자가 훌륭한 개발자가 될 수 있다는 것을 누구보다 잘 아는 개발 리더라는 이야기가 하고 싶은 거다.

그럼에도 불구하고 요즘 학원에서 천편일률적으로 배우고 나오는 비전공 개발자들의 이력서에는 특별함이 존재하지 않다. 즉 나는 현실을 말하는 것이다. 대부분의 사람들 심지어 비전공자 본인 조차도 전공자와의 서류 싸움에서는 힘들 것이라는 것을 이해한다. 비전공 개발자들은 서류 부분 트라이부터 엄청나게 큰 핸디캡을 가지고 전공자들과 싸워야 한다. 단지 학원에서 프로젝트 했다는 것으로는 개발 리더의 흥미를 끌기가 어렵다.

그래서 추천한다. 물론 엄청나게 어려울 것이다. 하지만 그러한 과정을 거치고 나서 당당히 그 내용을 기재했다면 개발 리더는 조금이라도 다르게 지원자를 바라보게 될 것이다. 학원을 졸업해서 취업 준비 기간중에 개인 프로젝트를 하라는 것이다. 아 물론 하는 사람들 엄청나게 많다는 것을 안다. 실제로도 이력서를 보면 개인 프로젝트 엄청나게들 많이 한다. 하지만 그 수 많은 사람중에 실제로 제품화 까지 도달하는 사람은 거의 없다. 개인 프로젝트 라지만 학원 강사의 지원을 받지 않으면 github 에 README 하나 작성하지 못하는 지원자들이 수두룩 하다.

즉 클라이언트라면 실제로 제품을 만들어서 스토어에 올리고, 서버 개발자라면 실제로 제품을 런칭해서 URL 까지 입혀서 출시해서 실제로 클릭해서 동작하게 만들라는 거다. 아 물론 이래도 관심을 가지지 않는 개발 리더가 존재할 수도 있다. 그래도 어쩌겠는가? 개발은 그만큼 전공자가 유리한 필드다. 그 천장을 무너뜨리려면 그정도 정성을 기울여야 이력서를 보고 한 번 이야기라도 할려고 서류를 통과 시킬 것이다.

요약하면 비전공자들은 이력서에 더욱더 노력을 기울이고 '색안경을 끼고' 바라보는 개발 리더가 흥미를 가지게 할려면 무엇을 해야 할지 고민하라는 것이다. 제품을 출시하는 것이 크나큰 강점이 될 것이라는 것이 내 의견이다.

ps. 실제로 나는 클라이언트 개발자가 다른 회사에 거의 50번의 면접에서 떨어지고 우리 회사에 지원 했을 때 그 친구가 만든 제품을 실제로 스토어에 올린것을 깔아보고 나서 면접을 거쳐 뽑게 되었다. 그 친구는 아주 훌륭한 개발자로 성장했다. 

저번 글에 관한 제 실제 사례 언급을 하겠습니다. 

 

패치 전략에 대한 단상에 대한 저번 포스트글

 

[개발자에서 CTO 까지] 과연 거대한 기획이라는것이 의미가 있는지?

  '계획적으로 살아라' , '너는 왜 아무 계획없이 사냐?', '사업은 기획에서 부터 다 결정된다.'   나도 이 말을 맹신하던 시절이 있었다. 물론 아예 기획 없이 진행해야 한다는

crazia.tistory.com

 

사실 이 외에도 많은 실제 사례가 있지만 이게 가장 최근의 사례 입니다. 

참고로 저는 KPOP 관련 회사에서 일하고 있습니다. 

 

1. 회사에서 라이브 방송의 필요를 이야기함.

 새로운 먹거리를 찾기 위해서 이거 저거 시도하는 중에서 나온 이야기 

 

2. 아마존 미디어 라이브를 이용해서 빠르게 구현

 클라이언트 작업량 말고 서버 단에서는 작업 자체는 그리 오래 걸리지 않음, SaaS 를 쓰면 좋은 점중 하나

 

3. 이슈 발생

 - 가격이 쎄다. 1채널 이용시 하루 대략 80만원 비용 나옴 

 - 송출 영상과 클라이언트 간의 영상이 대략 30초 딜레이 발생 (유튜브 12초, 아프리카 6초)

 

4. 직접 솔루션 만들기로 결정

 - 기존에 비싼 AWS 의 트랜스 코더를 직접 만들어서 비용 절감한 케이스가 있어서 생각보다는 쉬울거라 예상 

 - 결국 예상보다 훨씬 빠른 기간 안에 솔루션 완성

 

5. 베타 방송시 이슈 발생

 - 영상 송출시 윈도우 머신과 nginx 를 이용한 방식이 동시 분배가 안되고 한쪽에 영상이 안나오는 현상 발견

 

6. OSX 에서는 그런 현상이 발견 안되고, 윈도우에서 플러그인으로 해결하는 방식으로 해결

 - 송출하는 프로그램과 연결하는 프로그램에서 문제가 발생하는 것으로 원인 파악 

 

7. 두번째 베타방송시 기술적으로는 성공.

 

결론적으로는 아마존 미디어 라이브 이용시 하루종일 방송하는 것을 기준으로 할때 한달 방송 1채널 2400만원 , 6채널 일때는 1억 4천 400만원 가량 소요 예정 (방송 딜레이 30초)

새로 만든 솔루션을 이용할때는 하루종일 방송한다는 기준으로 한달에 200만원 가량 소요 예정 (방송 딜레이 7-10 초)

 

충분히 아이디어 단으로 기획이 충분하고 개발자들이 개발을 진행할 수 있을 정도로만 정리되는 기획과, 이용할 수 있는게 있으면 빠르게 제품을 제작해서 빠르게 기존 전략을 수정하며 개발 방향도 맞춰서 수정하는 쪽으로 대응하는 방식만으로도 시장 속도에 맞출 수 있게 된다는 것을 알게되는게 충분합니다. 

  저번 글 에서 언급했던 것과 같은 사례가 있어서 소개합니다.  바로 Boney M. 이라는 그룹입니다.

https://www.youtube.com/watch?v=l3QxT-w3WMo


  1974년, 독일의 대중음악 프로듀서 프랑크 파리안(Frank Farian) 이 흑인들이 나오는 수사물을 보고 영감을 받아서 노래를 한 곡 작곡합니다. 흑인 분위기만 날뿐 실제로는 프랑크가 노래를 직접 부르고 녹음해서 빠르게 앨범을 내 봤는데 이 앨범이 히트를 쳐서 여기 저기서 공연 요청이 쇄도 했다고 합니다.

  그래서 빠르게 자메이카 출신들과 다른 한명의 흑인들을 조합해서 그룹을 만들고 그 그룹으로 여기 저기 공연을 다니면서 엄청난 인기를 누렸습니다. 전설적인 그룹 아바 와 유럽 팝계를 양분했을 정도니 어마 어마한 인기였겠지요.

  게다가 그룹의 이름을 유지한 채 , 멤버들이 교체되면 계속 유지하는 전통도 만들어 낸 그룹이라고 합니다.

  빠른 기획 실행의 전형적인 과정입니다.

  재미 있는 아이디어 -> 빠른 기획 (거의 아이디어와 동시에 대충 이렇게 하면 되겠다 정도) -> 초 빠르 실행 (실행하는데 전혀 머뭇거리면 안됩니다.) -> 이슈 발생 (실제로 그룹이 존재하지 않는다) -> 패치 (그러면 그룹을 만들면 되지) -> 이슈 발생(멤버가 나감) -> 패치 (새로 뽑고 기존 멤버는 졸업이라 함 )

  이슈 큰 것만 꼽아 봤는데 긴 기간 동안 얼마나 많은 이슈가 있었을까요? 그 수 많은 이슈를 패치해 가며 그룹 (프러덕트)을 유지해 왔을 것입니다. 



후학들에게 보여주고 싶은 내용입니다. 역시 개발자들이라 그런지 Bottom-up 이라던지 프로토타이핑에 관한 언급이 살짝 살짝 나오는 군요 
나의 모든 디자인 문서들은 신문처럼 '나선형' 방식으로 조직된다. 뉴스 기사의 헤드라인은 전체적인 내용을 얘기해준다. 그 다음에 오는 첫 번째 단락은 같은 얘기를 조금 더 자세하게 설명한다. 다음의 세 단락들은 더 많은 정보들을 포함하여 다시 서술한다. 7단 정도 되는 기사의 나머지 부분에서는 전반적인 이야기를 아주 세부적인 내용까지 전달한다. 이 방식은 독자들이 불필요한 세부 사항에서 헤매지 않고 원하는 내용만 취해서 읽을 수 있게 해준다.
 - 본문 중에서 -


조그만 회사에서 경영한다는 것은 본의 아니게 개발보다는 기획할 일이 많아집니다. 개발자들은 저도 개발자 였지만 모든 것을 자기 뜻대로 결정하고 싶은데, 그것을 태클 받으면 쉽게 이야기 하는 것이 바로 "문서로 주세요,문서로.. 문서 없으면 일 안합니다" 입니다. 보통 이렇게 이야기 나오면 '나 삐졌다' 라는 말과 동의어지요.

그래도 어쩌겠습니까? 일을 시켜야 하는데요. 그러면 문서를 쓰게 되는데 기획이나 디자인 관련 문서들은 써 본 경험이 없지요. 그래서 이 책에 나와 있는 저 방법이 쓸만 했던거 같습니다.뉴스의 단락을 쓰듯이 차례 차례 자세하게 정보가 내려가게 쓰는 것이지요. 아직은 연습중이긴 하지만 조금만 더 연습하면 제대로 쓸 수 있을 것 같습니다.

이런 문서까지 줬는데 일 안하면 옆에 붙어서 딴 짓 못하게 방해하는 거도 효과가 좋습니다. 킬킬

+ Recent posts