[링크]

https://docs.google.com/spreadsheets/d/1OHmrl44-e8rLgFvfOi8aadMMYZvA9VriciFgmRMRjKE/htmlview?sle=true#gid=0

크런치(crunch)는 crunch time이라는 숙어 ‘극도의 긴장이 필요한 때’에서 온 것으로 보이는데, 게임업계에서 개발 막바지 일정 기간 동안 야근과 철야를 밥먹듯이 해 개발을 완료해내는 그런 상태를 말한다. 그래서 “오늘부터 1개월간 크런치 모드입니다”라는 말은 “앞으로 한 달 동안은 죽었다고 생각하고 매일 야근 합시다”라는 뜻이다.

이 크런치에 대해서는 업계 내에서 오랫동안 다양한 의견이 있어왔다. 워렌 스펙터는

[…] “크런치는 창조적 매체에서 미지의 요인을 가지고 일하기 때문에 발생하는 결과입니다. 게임 개발은 항상 미지로 가득하기 때문에 퀄리티를 높이려 분투하는 개발사에서는 항상 크런치를 하게 돼요. […] 30년간 게임을 만들었는데 전 아직도 크런치 없이 인정할 만한 수준의 게임을 만드는 마법사는 본적이 없어요.”

라고 이야기를 했다고 하고, 스타독(Stardock)의 데릭 팩스턴은

“게임 업계의 기업들과 사람들은 크런치에 써버린 시간을 훈장처럼 자랑하는짓을 그만둬야 해요. 크런치는 망가진 업무 절차와 관리의 결과입니다. 크런치로 직원들이 희생됩니다. 전 왜 크런치가 다른 업계에서는 이슈가 되지 않는데 왜 게임회사들에만 이슈가 되는지 묻고 싶군요.”

라고 이야기를 했다고 하며, 개인적으로 만나본 여러 개발자들도 크런치의 필요성이나 효과에 대한 다양한 증언이 있었다.

그런데 얼마 전부터 가마수트라에 올라오기 시작한 게임 개발 성과 측정 프로젝트(한국어 번역)에서 분석한바에 따르면

우리의 결과물은 명백하게 크런치가 비범한 결과물을 낳지 않는다는 사실을 보여줍니다. 실제로는 크런치는 항상 게임을 덜 성공적으로 만듭니다. 프로젝트가 크런치를 이용해서 구덩이에서 빠져나오려고 발버둥 치면, 발밑의 구덩이가 더 깊어지는 결과를 낳을 뿐입니다.

이라고 확정적인 결론을 내렸다. 이 연구에서도 언급하지만,

한편, 경영학에서는 방대한 규모의 입증된 연구결과를 통해 연속된 초과근무는 건강, 생산성, 인간관계, 사기, 조직 몰입도,의사 결정 능력을 망치고 심지어 알콜 남용의 위험성을 높인다는 사실이 확인되어 있습니다.

대량의 입증된 경영학 연구에서는 근로자들의 총 생산성이 겨우 몇 주만 초과근무해도 음수로 변한다는 사실을 보여주고 있습니다. 근무시간을 일간 8시간에서 9시간으로 늘리면 총 생산성은 무려 16-20%가 감소합니다. 겨우 몇 주만 50시간을 근무해도 해당 기간 동안의 총 누적 생산량이 주당 40시간 근무했을 때보다 오히려 더 줄어듭니다. – 추가적인 주당 10시간의 근무는 실제로는 근로자들의 총 생산량을 감소시킵니다. 동시에 근로자들의 스트레스를 증가시키며, 인간관계를 목 조르고, 제품의 결함률을 높입니다.

다른 모든 산업에서는 초과 노동이 생산성에 전혀 기여하지 못하고, 오히려 부정적인 효과만 작용을 하는데, SW 업계에서는 이 크런치가 효과가 있다는 믿음을 여전히 가지고 있다는 것이다.

사실 이 문제는 게임 개발의 품질이나 생산성, 열정에 대한 문제 이전에 기본적인 개발자 삶의 질에 대한 이야기에서 출발해야 한다. 2013년 8월 게임 산업 종사자 실태조사에서 출퇴근 시간과 평균 야근 시간을 조사했던 것은 이런 맥락에서였다.

특히나 게임산업이 젊은 개발자들의 열정을 빨아먹는 산업이 아니라 다른 모든 산업들처럼 안정적이고 평범한 산업 환경이 되기 위해서는, 종사자들의 삶이 안정되어야 하고, 그러기 위해서는 일과 삶의 균형을 (개발자 스스로 맞추기에 앞서) 기업이 만들어줘야 하기 때문이다.

이미 그 열악하다던, 흥행 산업의 대명사인 영화 업계도 오랜 부당 노동(초과 근로와 최저 임금에도 못 미치던) 환경을 개선하는 노력으로 노조를 구성했으며, <국제시장>은 표준근로계약서를 도입해 그간 스탭들을 착취하던 관행을 깼다. 심지어는 만화계에서도 처우 개선에 대한 이야기가 시작됐다.

개발자가 게임업체를 다니면서 결혼하고, 자식을 낳고, 키우면서 가족과 행복하게 저녁을 먹는 그런 삶을 누리는 것이, 결국에는 개발자를 재충전하게 해주고 더 좋은 게임을 만들 수 있는 환경이 될 것이다. 그리고 그렇게 ‘안정적인 직업’이 될 때 젊은 지망생과 개발자들이 개발자로 업계에 입문할 꿈을 꾸고 살아가는 그런 환경이 될 것이라고 생각한다.

게임의 흥행 성공률이 낮다는 이유로 개발자들을 싸게 초과 근로를 인사 고과에 반영하면서 갈아 넣어서는, 단기적으로는 프로젝트를 끝낼 수 있겠지만 장기적으로는 경험 있고 실력 좋은 개발자를 업계에서 밖으로 밀어내는 결과를 낳는다.

당장 크런치를 없앨 수는 없을 수 있다. 하지만 적어도 우리가 이런 잘못된 개발 환경으로 인해서 무엇을 놓치고 있는지, 어떻게 개선하면 어떤 것을 얻을 수 있는지는 고민해볼 때가 됐다고 생각한다.

한국에서 게임 개발이 ‘산업’이 된지도 이제 20년이 되어 간다. 생각을 해볼 때다.

출처 : http://nairrti.works/2015/02/27/crunch/

[링크] http://ilikeen.tistory.com/1657

DL, Dl, dl는 다음 뜻을 가지고 있다.

• dL, dl: 부피의 단위 데시리터(1dL=0.1L)
• 데이터 통신을 지칭하는 의미로 데이터 링크라 부르며, 영어 Data Link의 약어이다.
• 데이터 통신에서 서버에서 클라이언트로 데이터를 가져오는 것을 다운로드라고 하며, 영어로 download의 약어이다.
• 델타 항공의 IATA코드이다.
• DL, Distribution List는 메시지 통신 처리환경이 전달하는 정보 대상의 수신자인 사용자들로 구성된, 사전에 지정되어 있는 특정 집단(예:회사·단체 등 조직) 및 그 특정 집단 내의 다른 DL들(부문·부서 등)이다.

출처 : https://ko.wikipedia.org/wiki/DL

예전에 본거지만 다시봐도 좋네요.

출처 : http://www.torrentby.me/humor/317572

출처 : http://www.terms.co.kr/FYI.htm

바이럴 마케팅

출처 : https://namu.wiki/w/%EB%B0%94%EC%9D%B4%EB%9F%B4%20%EB%A7%88%EC%BC%80%ED%8C%85

링크 : http://blog.naver.com/need97/220353122498

링크 : http://www.todayhumor.co.kr/board/view.php?table=bestofbest&no=200961&s_no=200961&page=1

Feature creep이라는 말이 있습니다. 게임 개발 뿐만 아니라 많은 소프트웨어 개발 프로젝트에서 발견할 수 있는 것들입니다.

마침 위키피디아에서 feature creep을 잘 설명한 글이 있습니다. (링크) 요약해보죠.

• 제품을 개발하다보면 사용자들이 원하는 기능과 쓸모있는 기능들을 넣고자 하는 열망이 생긴다. 그리고 그렇게 함으로 매출을 올리고자 한다. 아이러니하게도, 이것이 feature creep의 시작이다.
• feature creep이 지속되면 불필요한 기능들이 자꾸만 들어가게 되고 프로젝트의 복잡도가 증가하며 제품의 특장점과 핵심 기능이 서서히 감춰지게 된다.
• feature creep은 이미 개발된 (혹은 개발중인) 프로젝트를 유지하려는 의지가 원인이 되기도 한다.
• feature creep은 프로젝트의 개발 비용을 과다하게 증가시킬 뿐만 아니라 프로젝트를 죽여버리는 원인이 되기도 한다.

Feature creep으로 진화된 물건. 바지 주머니에 넣으려면?

feature creep은 매우 흔합니다. 당장에 여러분이 참여하고 있는 프로젝트에서도 발견할지도 모릅니다.

feature creep을 일으킬 수 있는 위험인자는 흔하게 널려있습니다. 여러분의 직장 상사, 여러분의 친인척들, 심지어 여러분 자신 및 여러분이 지금 열심히 보고 있는 책에도 있을 수 있습니다. 저 또한 많은 feature creep에서 고생해본 사람이기도 합니다.

어떤 경우에서 생기는지 보도록 하죠.

프로그래머들은 신기술이 나오면 바로 적용해보고 싶어합니다. 뭔가 엘레강스한 대단한 아키텍처(나중에 알고보니 안티패턴임을 뒤늦게 깨달을)를 적용해보고 싶어합니다. 어느날, 모노리스 코드가 만들어지고 심지어 자기 스스로도 감당하기 힘든 복잡도를 가진 괴물을 만들고 맙니다. 그리고 회사가 개발 일정과 (자금이) 나빠지면서 슬슬 구인 게시판을 뒤져보기 시작합니다. 중요한 실력과 정교한 개발보다 많은 시도를 해보고 싶어하는 (나쁘게 말해서 회사를 상대로 실험해보려는) 모험심 강한 (그러나 실력과 책임감이 그만큼 받쳐지지 못하는) 프로그래머에게서 볼 수 있습니다.

게임 기획자들은 대단한 게임을 만들고 싶은 마음에 여러가지 아이디어들을 계속 집어넣습니다. 다른 게임에서 감동한 기능들을 자꾸만 넣습니다. 뭔가 엘레강스한 완성도의 게임을 꿈꾸며 대량의 기획서를 작성합니다. 그리고 플레이를 해보니 별로 재미가 없습니다. 안되겠습니다. 뭔가를 추가해야겠다고 생각합니다. 장르도 늘어납니다. 처음에는 액션 게임이었는데 만들다보니 MMO + RPG + 전략시뮬 + 커뮤니티 + 어드벤처 + 음악댄스 + 영어교육 게임이 되어버립니다.

경영진,마케터,운영팀도 feature creep에 일조합니다. 유저들의 피드백, 시장 현황, 소문 등은 개발 방향에 자꾸만 쓸데없는 암세포를 붙이게 합니다.

횟집은 뭐니뭐니해도 회가 신선하고 맛있어야 합니다. 스끼다시와 매운탕만 잔뜩 줘봤자 회가 물러터졌으면 소용없죠. Feature Creep은 동네 음식점에서도 흔히 볼 수 있습니다.

feature creep으로 고생하는 게임 개발 프로젝트의 공통점은 다음과 같습니다.

• 프로젝트 초기에 만들려고 했던 것이 분명하게 구체화되어있지 않았습니다. 아무것도 구체화되어있지 않으면서 정작 만들고자 하는 것은 거대한 꿈 덩어리입니다.
• 현실 감각을 잊은 지나친 열정을 갖고 있습니다. 단 한개의 궁극 완성도 제품을 만들려는 열망만 가득합니다. 현실적으로, 신차를 개발해도 포니부터 시작해야 소나타도 만들고 그랜저도 만들고 궁극적으로 에쿠스도 만드는건데, 처음부터 페라리를 만들려고 합니다. 즉 프로젝트 범위의 상한선을 미리 그어놓지 않았습니다.
• 디렉터가 중간 결과물이 별로 마음에 들지 않는다는 이유로 당황합니다. 그리고 돌파구를 "더 멋진 시스템의 추가"에서 찾으려만 합니다. 그냥 버리고 완전히 새로운 것을 시작하는게 더 나을 것 같은데 말이죠.

단도직입적으로 말하죠. Feature creep은 가장 쉬우면서 무능력한 개발 방향입니다. 

Feature creep이 "자꾸만 넣는다"인데 이에 반대되는 말은 "더 이상 뺄 것이 없을 때까지 빼기"입니다. 그리고 더 이상 뺄 것이 없을 때까지 빼버리고, 남은 것들에 대해서는 최고의 품질을 만들기 위해 집중을 한 제품 중에서는 시장에서 성공한 것이 많습니다. 제가 생각하는 이러한 예는 비주얼드, 광란의 수족관, 팡야(골프게임), 아이팟입니다. ProudNet을 쓰는 프로젝트 중 몇 개도 있고요.

혹시 여러분의 프로젝트에서는 알게 모르게 feature creep이 범해지고 있지 않나요?

[출처] 게임 개발의 암세포! FEATURE CREEP|작성자 imays