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

전공 vs 비전공

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

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

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

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

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

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

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

gtpai 를 이용하니 Multibyte 처리가 안되어 있는 함수를 이용하기 때문에 제대로 동작하지 않는다. 그거와 최대한 유사하게 가장 간단한 기능만을 옮겨봤다. 

 

(defvar gpt-base-url "https://api.openai.com/v1/completions")
(defvar gpt-chat-url "https://api.openai.com/v1/chat/completions")

(defcustom gpt-model ""
  "API Model for OpenAI."
  :type 'string
  :group 'crutil)
(defcustom gpt-api-key ""
  "API key for OpenAI."
  :type 'string
  :group 'crutil)



(defun send-query-to-gpt (text)
  "ask to gpt"
  (interactive
   (list (read-string "물어봐: ")))

  (when (null gpt-api-key)
    (error "OpenAI API key is not set"))

  (let* ((url-headers
	  `(("Content-Type" . "application/json")
	    ("Authorization" . ,(format "Bearer %s" gpt-api-key))))
	 (url-data
	  (json-encode `(("model" . ,gpt-model)
			 ("prompt" . ,text)
			 ("temperature" . 0.7)
			 ("max_tokens" . 1000)))))
    (request
      gpt-base-url
      :type "POST"
      :data url-data
      :headers url-headers
      :parser 'json-read
      :success (cl-function
		(lambda (&key data &allow-other-keys)
		  (insert (cdr (assoc 'text (elt (cdr (assoc 'choices data)) 0))))))))

  )

 

적당히 load 될 수 있는 곳에 이 함수를 만들어 두고 

 

(require 'cr-utils)
(setq gpt-model "text-davinci-003")
(setq gpt-api-key "<INSERT YOUR API KEY>")

(global-set-key (kbd "C-c o") 'send-query-to-gpt)

맨 위의 cr-utils 는 send-query-to-gpt 함수가 위치한 파일이다. 

 

이러면 편리하게 사용할 수 있다. GPT 는 상당한 구라쟁이지만 말이다. 

이번에 회사에서 새로운 기능을 런칭했다. 내려오는 데이터 량이 좀 된다. 150K 정도 

 

스테이징 서버(한국에 있다)에서 혹독한 테스트를 거쳐도 문제가 없고, 론칭후 테스트에서도 별 이상이 밝혀지지 않았다. WI-FI 환경하에서도 동작을 잘하고 

 

문제는 내 폰에서 발생했다. 참고로 나는 SKT 폰을 사용중이다. SKT 의 LTE 환경하에서는 멈춘거처럼 동작하는 것이다. 150K 다.. 다시 말하면. 그정도 데이터를 내려 봤는데 멈춘다고? 

 

개발자를 소집해서 물어봤더니 전혀 안 느리다고 한다. 내 폰을 실제로 보여주니 개발자들이 다들 당황하는 것이다. 결국 이런 저런 테스트를 통해서 내린 결론은 SKT - LTE 가 완전 개 구리다는 것이다. 국내는 별 문제가 없으나 특히 해외가

 

KT, LG, WI-FI 망에서는 아주 잘 동작한다. 이렇게 쓰는 것도 웃기다. 겨우 150K 인데.. 

 

결국 SKT 의 LTE 환경이 개선되길 바라는 것은 코로나 19가 자연적으로 사라지길 바라는 것만큼 이루어지기 힘든 바람일테니, 우리가 패킷을 다이어트 시켰다. 1/3 로 줄였더니 시간이 많이 단축 됐다. 하.. 5G 시대에 150K 때문에 이런 난리가 일어나다니.. 

 

결론은 SKT-LTE 가 해외에 있는 서버랑 연결할때 극악의 효율을 보여준다는 것이다. 해외 서비스 준비할때 이런 것도 고려해야 할 것이다. 

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

 

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

 

[개발자에서 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) 이 흑인들이 나오는 수사물을 보고 영감을 받아서 노래를 한 곡 작곡합니다. 흑인 분위기만 날뿐 실제로는 프랑크가 노래를 직접 부르고 녹음해서 빠르게 앨범을 내 봤는데 이 앨범이 히트를 쳐서 여기 저기서 공연 요청이 쇄도 했다고 합니다.

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

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

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

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

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

  '계획적으로 살아라' , '너는 왜 아무 계획없이 사냐?', '사업은 기획에서 부터 다 결정된다.'

  나도 이 말을 맹신하던 시절이 있었다. 물론 아예 기획 없이 진행해야 한다는 것은 아니다. 사전 계획은 무슨 일이던 필수이다. 다만 탑-다운 방식으로 성대하게 계획을 하고 세부 계획까지 세우고 일을 진행하는 방식에 회의가 있다는 말이다. 
  
  예전 기록을 살펴보면 탑-다운 식 설계의 유명한 프랭클린 플래너도 샀다. 그리고 열심히 연초에 그 해의 할 일들 이루어 내야 할 일들을 적어내고 그 해에 그걸 지켜보려고 노력을 했다. - 예를 들면 다이어트 -  그리고 연말에 돌이켜 보면 연초에 열심히 계획했던 일이 하나도 지켜지지 않는 상황에 대한 자괴감도 컸던거 같다.

  즉.. 계획한대로 또는 기획한대로 일이 흘러가는건가에 대한 고찰이다. 물론 잘 지켜지는 사람에 대해서는 예외로 한다. 철저하게 나를 중심으로 생각하는 것이다. 나 자신도 내가 계획한대로 흘러가지가 않는데 여러 인격이 모인 팀이나 회사 입장에서 철저하게 세운 계획대로 흘러갈 수 있을까?

  수 많은 기업들이 최초의 계획대로 흘러가는 경우가 얼마나 될까? 본인이 다니는 회사에서도 성대하게 세운 계획하에 진행된 일 보다 시작은 가벼운 기획이 제대로 소비자의 관심을 끌어서 알아서 광고가 되는 경우가 있다.

  구글이 처음부터 지금 같은 회사가 되기를 계획했을까? 시작은 스탠포드 대학교의 검색 라이브러리 였다. 아마존은 지금과 같은 거대한 제국을 이루었을까? 그냥 도서 판매하는 사이트였다. 넷플릭스는 지금처럼 거대한 OTT의 최강자가 되리라고 초반에 DVD 대여 사업을 할 때 생각을 했을까? 페이스북은 하바드대학교의 미녀들 품평하는 사이트에서 지금같은 초 거대 SNS 의 강자가 될 수 있음을 계획했을까?

  가볍게 해외의 예만 적었지만 지금 합병된 카카오의 PC 포탈 플랫폼인 다음은 초창기에 구상했던 사업은 지금과는 전혀 다른 서비스였다. 거대한 IT 회사가 될 수 있게 해준 한메일은 여러가지 사업이 실패하고 재기를 꿈꾸던 포트폴리오의 가장 마지막을 차지했던 서비스였다.

  카카오는 어떤가? 카카오의 전 회사 이름은 기억도 나지 않는다. 카카오톡이 뜨고 나서 회사 이름까지 바꿨으니 카카오톡이 카카오가 진행한 프로젝트중 5번째 프로젝트다. 회사 창업한지 몇 년이 지난 후로 알고 있다.

  앵그리버드는 로비오 엔터테인먼트의 36번째 게임이였다.

  결론을 짜맞춘다고 볼 수도 있지만 결국 핵심은 '실행' 이였던거 같다. 가벼운 생각이 공상이나 망상에 그치지 않게 그 아이디어를 간단하게 기획하고 일단 실행을 하는 것이다. 그리고 상황에 맞게 거기에 '패치' 작업을 하는 것이다.

  패치는 개발 용어로 문제가 생긴 코드나 새로운 기능을 덧붙여서 기존 코드를 변경하거나 추가하는 행위를 말한다.

  왜 이래야 하는걸까? 현실이 너무 많은 변수가 있기 때문에 계획서에 다 담거나 계획서에 쓰여진대로 실행하다가는 현실의 변수를 무시 못하기 때문에 그 과정을 맞춰가며 바꾸다 보면 계획만 하다가 끝나는 경우가 너무 많기 때문이라고 본다.

  즉 머릿속에서 생각하는 환경 자체가 현실하고 동 떨어져 있는 경우가 정말 많다. 게다가 대중의 선택이라는게 그리 쉬운 일은 아닐것이고.

  주저리 주저리 말이 많았지만 하고자 하는 내용의 핵심은

  기획하는데 쏟아낼 수많은 에너지를 '실행'에 집중해라. 일단 '시작' 하고 상황이나 시장의 반응에 맞춰서 기획을 지속적으로 '수정'(패치) 하라. 

예전에는 혼자서 개발하면서 성장할 수 있는 시기가 있었지만, 요즘은 팀단위로 개발을 진행하기 때문에 빠르게 성장할 수 있지만, 자신의 파트에 특화되는 경향이 있습니다. 물론 지금도 파트를 오가면서 개발을 할 수는 있지만 예전만큼 쉽지 않습니다. 저도 실제로 클라이언트 개발을 하다가 서버 사이드로 옮긴 경우 입니다. 


  예전 다니던 회사에서 공개 개발자 모집을 한 적이 있습니다. 들어온 원서의 비율을 체크 해보니 안드로이드, iOS, 백엔드 개발자의 비율이 8:1:1 이였습니다. 클라이언트와 서버 비율로 따져보면 9:1 입니다. 

  클라이언트 사이드에서 안드로이드 개발자가 iOS 보다 많은 이유를 몇 가지 짐작해 볼 수가 있습니다. 

  안드로이드 폰을 가진 사람이 월등하게 많습니다. 자신이 가진 폰에 맞는 앱을 개발하다보면 당연히 안드로이드 개발이 많을 수 밖에 없다고 생각할 수 있습니다. 

  안드로이드 개발 환경 구축이 훨신 쉽습니다. iOS 는 맥에서 개발을 해야 하지만 안드로이드는 일반 윈도우 환경에서도 개발이 가능합니다. 또한 iOS 는 스토어에 올리려면 개발자 인증서를 사야 하는데 이 비용도 초기 비용에 해당합니다. 또한 지금은 추세가 바꼈지만 예전에 iOS 는 object-c 로 개발을 해야 했는데 이는 java 보다 난이도가 높습니다. java 는 학교 수업시간에도 배우는 언어이기 때문입니다. 

  여러가지 이유로 안드로이드 개발이 iOS 보다 많은 이유를 짐작해 볼 수가 있습니다. 

  그러면 클라이언트와 서버 개발은 어째서 차이가 날까? 
  
  클라이언트 개발은 접근성이 편합니다. 그리고 결과물을 바로 볼 수가 있다는 장점이 있기 때문에 개발에 흥미를 가지고 시작하기가 좋습니다. 그리고 개발 -> 개발 완성까지의 가야 하는 길이 짧습니다. 

  서버 사이드는 개발을 시작하기 위해서 알아야 할 것들이 많습니다. 데이타베이스도 알아야 하고 디플로이도 제대로 할려면 리눅스 관련 명령도 배워야 합니다. 요즘은 클라우드가 대세이기 때문에 AWS (Amazon Web Service) 나 GCP (Google Cloud Platform)을 알아야 하는 시기가 됐습니다. 개발 언어도 알아야 하고 웹 서비스면 웹프레임워크도 알아야 합니다. 게다가 국내에서 가장 많이 쓰이는 자바 관련 개발 환경이라면 스프링 프레임워크를 많이 쓰는데 이 또한 학습곡선이 높고 많은 기간을 필요로 합니다. 만약에 결과를 눈으로 확인 하기 위해서는 프론트엔드도 최소한으로 알아야 하는데 이 또한 만만치 않은 노력을 필요로 합니다. 

  즉 클라이언트 개발은 접근성이 좋고 바로 바로 아웃풋이 확인 가능하니 개발의 재미를 줄 수가 있습니다. 서버 개발은 개발 접근성이 좋지 않고 바로 바로 아웃풋 확인 하기까지가 배워야 할 것들이 많습니다. 하지만 이러한 난이도가 시니어급에 이르렀을 때 연봉의 차이를 가져옵니다. 9:1 클라이언트대 서버 개발자의 비율입니다. 이게 펑균이라고 보기에는 사실상 무리가 있는 특이 케이스 일 수도 있지만 인력시장에서 알아보면 확실히 서버 개발자의 숫자가 적습니다. 

  그래서 내가 클라이언트와 서버 개발중에서 어떤걸 할까 고민을 한다면 각각의 특장점이 있습니다. 

  클라 개발에 전념해서 장인급이 되신다면 회사를다니면서 또는 프리랜서를 하시면서 '돈'만 바라보고 여러가지 일을 동시에 진행한다면 단기간에 큰 돈을 벌 수가 있다는 것입니다. 제 주변에는 프리랜서 시절에 연 1억을 넘게 벌어들인 아이폰 개발자와 연 2억을 넘게 돈을 버는 클라이언트 개발자들이 있습니다. 

  서버는 이후에 올라갈 수 있는 테크가 있습니다. 아키텍트 - 개발 총괄 - CTO 등으로 커 나아갈 수 있는 기회가 열려 있습니다. 물론 클라이언트 개발자 출신으로도 가능합니다. 그리고 클라이언트 개발자 분들의 역량을 무시하는 건 절대 아니지만 이후 실제로 서비스를 론칭해서 운영하는 경우에는 절대적으로 서버쪽의 지식이 필요합니다.

  물론 이런 것들이 생각처럼 잘 되기 위해서는 그에 따르는 노력들이 필요하지만 대체로 이렇습니다. 

요즘 왠만한 웹 서비스를 만들어서 런칭을 하는 경우에도 https 를 감안해야 합니다. 아마존 웹 서비스(AWS) 에서 서비스 만들어서 런칭을 할 때도 마련해두면 편하게 작성할 수 있을거 같은 교과서적인 튜토리얼을 발견해서 첨부합니다. 비록 설명은 자바 기반이지만 웹서비스에 대해서 어느정도 관심 있는 분이라면 필히 자신이 쓰는 플랫폼으로 변경해서 적용할 수 있으리라 봅니다. 


  https://goo.gl/1guuCC




프론트 개발이 가능하신 개발자 분들이 제 오픈소스 프로젝트에 참여해서 프론트 엔드를 꾸며 주었군요. 모바일도 적용이 되어 있습니다. 


데모: https://chat.crazia.org/

소스: https://github.com/crazia/NM-chatbot


딥러닝 관련 과거 포스트들: 

1. AI 학 개론 (초보 개발자를 위한 정리) 

2. seq2seq 를 이용한 챗봇 (Neural Network Chatbot)

3. seq2seq 를 이용한 챗봇 - 웹버젼

4. seq2seq 를 이용한 챗봇 - 자동 진화 버젼

5. seq2seq 를 이용한 챗봇 - 형태소 분석을 추가한 버젼



큰 회사를 제외하고 일반적으로 작은 형태의 IT 회사는 다양한 형태가 존재하지만 무리하게 일반화를 굳이 하자면, CTO (Technology) 주도의 회사와 CPO (Product) 주도의 회사가 있습니다. 


쉽게 말하자면 기술 주도의 회사와 기획 주도의 회사 입니다. 각각의 장점이 확실히 존재합니다. 기술 주도는 제품이 단순하고 개발 이터레이션이 짧게 돌아가고, 기획 주도는 창의적이고 다양한 시도를 하기에 기존하고 다른 제품이 나올 확률이 높습니다. 어떤 개발 스타일을 제가 좋아하는 것은 별도로 치고도, 잘 생각해 보면 회사의 개발 방향이 이런 형태중에 한가지에 가까울 수가 있습니다. 


다만 개발자 출신으로서 생각해 보기에는 (초보) 개발자는 기술 주도의 회사가 더 편하겠지요? 아무래도 CTO 가 주도하는 사이클을 몸에 익히면 추후에 팀장이나 또는 본인이 CTO 로 나아갈 때 도움이 됩니다. 


그렇다고 기획 주도의 회사가 (초보) 개발자가 일하기 힘들기만 한 것이냐? 그렇지는 않습니다. 고난 속에서도 배우는 것이 있듯이 나중에 기획이 바꼈을 때 어떻게 기획자들과 싸워서 일정을 쟁취해야 하는지에 대해서 확실히 배울 수가 있습니다. 다만 변경되는 일정에 대한 짜증은 별도이지만요. 즉 심각하게 힘들게 하는 SI 의 대비를 미리 할 수가 있다는 것입니다. 농담 처럼 이야기 하지요 SI 에 계속 있으면 안되지만 군대 가듯이 SI 를 해 볼 필요는 있다고 말이죠. 그리고 이 바닥에서 말하듯이 개발자에게 있어 군대란 .. 


즉 처음의 논조와는 달라졌지만 (초보) 개발자가 기획 주도 회사에서 일할 때 


1. 자주 기획이 변한는 것에 대한 불만

 - 기획이 자주 변경 되는 건 당연한 일이 라고 여겨야 합니다. 

 - 잘 교육된 기획자가 아니면 아닐 수록 생각을 확정 못 시키고 자주 기획이 변경됩니다.


2. 기획이 바꼈는데도 일정을 고정할려고 하면

 - 절대 납득하고 날 새시면 안됩니다. 

 - 그 기획자에게도 기획이 바뀌면 일정이 변경된다는 것을 교육 시켜야 합니다. 그래야 그 분도 나중에 다른 개발자랑 일할 때 신경을 써 줍니다. 


3. 지속적으로 일정 관리에 대한 분위기 조성

 - 어떠한 일이 있더라도 기획이 바뀌면 일정은 무조건 변경되야 한다는 것을 모든 개발 참여자들이 인지하는 분위기를 조성해야 합니다. 

 - 그래서 개발 시작 전에 기획이 확정 되어지고 그 기획은 마일스톤 (or 스프린트) 기간 내에는 변경이 안되게 확답을 받아야 합니다. 

 - 개발 일정이 변경 되는 것에 대한 원인이 기획 변경에 있다는 것이 인지되면 기획자들도 조금 더 노력해서 기획을 확정 지으려고 합니다.


최근 회사 개발자가 확정 안되어진 기획서를 가지고 개발하는 데 짜증을 내길래 달래주다가 정리한 글입니다. 


+ Recent posts