꽃미남 프로그래머 김포프가 창립한 탑 프로그래머 양성 교육 기관 POCU 아카데미 오픈!
절찬리에 수강생 모집 중!
프로그래밍 언어 입문서가 아닌 프로그래밍 기초 개념 입문서
문과생, 비전공자를 위한 프로그래밍 입문책입니다.
jobGuid 꽃미남 프로그래머 "Pope Kim"님의 이론이나 수학에 치우치지 않고 실무에 곧바로 쓸 수 있는 실용적인 셰이더 프로그래밍 입문서 #겁나친절 jobGuid "1판의내용"에 "새로바뀐북미게임업계분위기"와 "비자관련정보", "1판을 기반으로 북미취업에 성공하신 분들의 생생한 경험담"을 담았습니다.
Posted by 알 수 없는 사용자

 

지난 회에서는 닌텐도의 2011년 3분기 손익계산서를 통해 매출과 매출총이익, 영업이익 등에 대해서 알아보았습니다. 그러면 이번 포스팅에서는 그에 이어서 손익계산서의 나머지 부분들을 살펴보도록 하죠. 아, 그전에 사실 재무제표 분석법을 설명할 때 가장 먼저 알아야 할 핵심이지만 일부러 뒤로 미뤘던 내용을 먼저 짚고 넘아가봅시다.


제무재표는 목적을 가지고 읽어야 한다


지난 회에서, 재무제표는 한 마디로 기업의 성적표라고 한 적이 있습니다. 즉, 재무제표를 제대로 볼 줄 알면, 그 기업이 어떤 사업을 얼마나 잘했는지를 알 수 있고, 어떤 강점과 어떤 약점이 있는지도 알 수 있죠. 하지만 그 기업과 어떤 관계를 가지고 있느냐에 따라, 즉 그 기업과의 이해관계에 따라 보고 싶거나 중요시 하는 '점수'는 다를 것입니다. 

예를 들어 은행과 같은 채권자라면, 그 기업이 부채를 상환할 수 있는지 여부가 중요할 것이며, 프로젝트(PF) 투자에 출자한 투자자라면 회사가 큰 수익을 내고 있는지가 궁금할 것이고, 벤처기업의 지분 투자자라면 회사가 얼마나 크고 아름답... 빨리 성장할지 여부가 중요할 것입니다. 따라서 재무제표를 볼 때에는 그 이해관계와 목적에 따라 다음과 같은 세 가지 관점에서 분석해야 합니다.

  1. 수익성: 회사가 얼마나 효율적으로 이익을 내고 있는가 (예: 매출액, 이익은 충분한가)
  2. 안정성: 회사가 얼마나 안정적으로 유지되고 있는가 (예: 채무를 갚지 못해 도산할 우려가 없는가)
  3. 성장성: 회사의 규모, 매출, 수익 등이 앞으로 얼마나 발전할 것인가 (예: 향후의 수익성, 안정성은 문제가 없는가)

그러면, 지난 회에서 살펴본 손익계산서는 과연 저 세가지 중에 어떤 성적을 볼 수 있을까요? 손익계산서는 매출액과 더불어 각종 이익과 비용의 규모를 보여주기 때문에 당연히 수익성을 파악하는 도구입니다. 손익계산서에서 매출액이 크고 비용이 적다면 그만큼 이익이 많이 남으므로 수익성이 좋다는 사실을 쉽게 알 수 있겠죠? 하지만 이익이 많이 남았다고 해서 반드시 그회사가 안정적이라고 단정지을 수는 없습니다. (물론 이익을 많이 남기는 회사는 대개 안정성도 갖추고 있지만 항상 그런건 아닙니다)

왜냐하면 회계처리상으로는 이익이 남아도 전부 외상매출이라면, 그 금액이 현금으로 들어오지 않는다면 장부상으로만 이익이 남고 정작 손에 쥔 돈은 한 푼도 없을 수도 있고, 과거에 적자가 누적되어 왔다면 한 번 이익난다고 해도 돈이 쪼들릴 수가 있으니까요. 성장성 또한 마찬가지입니다. 손익계산서는 과거의 매출과 이익을 보여주기 때문에 그 성적이 앞으로 향상될지 아니면 악화될지는 알 수 없습니다. 그렇기 때문에 재무제표를 보는 목적에 따라서 중시해야 할 데이터는 다를 수 밖에 없는 것이죠. 손익계산서 이외의 다른 재무제표는 추후에 다룰 것이니 일단 손익계산서는 기업의 수익성을 보여준다는 점만 기억해 둡시다.





환율이 닌텐도의 목을 졸랐다고?

자 그러면 다시 닌텐도의 손익계산서로 돌아가봅시다. 지난 회에서 언급했듯이, 닌텐도는 2011년 4월 ~ 2012년 3월말까지의 회계연도에 당기순손실이 650억엔이 될 것이라고 예상 실적을 발표했었죠. 그런데 2011년 4월부터 12월말까지 9개월 동안의 영업이익이 △164억엔 적자인데, 그렇다면 나머지 3개월 동안 거의 400억엔 가까운 손실이 더 난다는 얘기일까요? 물론 아닙니다. 왜냐하면 영업이익에서 당기순이익을 계산하기까지 중간에 또 변수가 있기 때문이죠. 손익계산서를 보면서 설명하겠습니다.


일단 위 스샷에서 경상이익 아래 부분은 일단 생략했지만, 2010년 3사분기누계의 당기순이익은 49,557 백만엔이고, 2011년은 △48,351 백만엔 입니다.

손익계산서를 볼 때에는 ① 당기순이익(또는 손실)이 얼마인지를 보고 최종적으로 흑자인지 적자인지를 확인한 다음  ② 맨 위에 있는 매출액 ~ 영업이익까지를 먼저 훑어보고 ③ 아래쪽의 나머지 부분(영업외수익~)을 순서대로 읽는 것이 좋습니다. 그래서 이익이나 손실의 근본 원인이 어디에 있는지를 체크하는 것이죠.

위의 손익계산서에 2011년 3사분기 누계상 영업이익은 △164억엔입니다. 그런데 당기순이익이 △483 억엔이라면, 이말은 즉 통상적인 영업활동 이외의 어딘가에서 319억엔의 손실을 더 보았다는 의미입니다. 아니 도대체 어디서 영업손실의 두 배나 되는 손실이 더 난 걸까요?

지난 회에도 살짝 언급했지만, 재무제표를 볼 때에는 딱 한 기간의 자료만 봐서는 제대로 된 분석을 하기가 어렵고, 최소한 두 기간 이상의 연속된 자료를 비교해야 한다고 했습니다. 그리고 이렇게 비교하는 과정에서 전기(前期)와 크게 달라진 수치가 있다면 주의깊게 봐야 한다고 했었지요. 그러면 위 손익계산서의 영업이익 아래부분에서 작년과 가장 크게 달라진 수치는 뭘까요? 항목이 몇 개 없으니까 금방 눈에 띄겠지만, '영업외비용의 외환차손'항목이 전년에 비해 36.3%나 감소해서 537억엔을 기록한 점입니다.


외환차손이 뭐야?

아, 뭔가 골치 아플듯한 용어가 나와버렸습니다. 하지만 대략 어떤 건지는 그 용어의 뉘앙스만 봐도 대충 짐작이 갈 겁니다. 외환차손(外換差損)이란 외화, 즉 우리나라의 입장에서는 미달러화나 유로화, 엔화와 같은 외국통화로 된 자산을 회수하거나 부채를 상환할 때, 환율의 차이에서 오는 손실입니다. 뭐 뇌입어 사전에서 찾아보면 이 설명 뒤에도 "외화자산을 회수할 때 원화회수가액이 그 외화자산의 장부가액보다 낮은 경우... 주저리 주저리..." 라고 덧붙여져 있는데, 뭐 그걸 읽는다고 해서 별 도움은 안될 겁니다. 설명이 나쁘다기보다는, 해외거래의 회계처리 업무를 해보지 않은 사람은 읽어도 잘 와닿지 않기 때문이죠.

그러면 외국과의 거래는 어떤식으로 회계처리가 되는지를 살펴봅시다. 예를 들어, 미국에 있는 닌텐도 판매법인에서 일본에 있는 닌텐도 본사에 Wii용 게임소프트인 <포프의 전설 - 스카이워드 소드>를 1만장 주문했다고 가정해봅시다. 주문서를 받은 닌텐도 본사에서는 상품을 준비해서 발송을 하겠죠? 그리고 발송하면서, 보통은 출하일에 인보이스(invoice; 송장) 이란걸 매입처에 발행합니다. 그리고 닌텐도 본사의 회계담당자는, 이 인보이스에 기재된 발행일(date of issue)에 매출을 인식하여, 전표를 작성하여 장부에 기장합니다. (물론 무역업의 특성상, 계약조건에 따라 상품의 선적일에 매출을 인식할 수도 있고, 도착지 하역시에 매출을 인식하는 경우도 있습니다. 하지만 이것은 본 포스팅의 주제와 거리가 있는 사항이므로 자세한 설명은 생략합니다) 예를 들어 판매단가가 20 달러라면 1만개 판매니까 총 20만 달러의 매출을 기장하는 것이죠. 만약 인보이스 발행일이 20x1년 5월 1일이라면, 닌텐도 본사에서는 이 날자에 20만 달러의 매출을 인식하고 장부에 올리는 것입니다.

자 그러면, 20만 달러의 매출을 장부에 그대로 적으면 될까요? 거래는 달러로 하지만, 전표와 장부에는 엔화로 환산하여 기재해야 합니다. 왜냐하면, 닌텐도 본사는 일본의 기업이고, 일본 기업회계기준상 재무제표에 표시되는 모든 금액을 엔화로 적어야만 하기 때문이죠. (굳이 용어를 쓰자면 기능통화, 표시통화라는 개념이 있는데 이것까지 설명하자면 길어지니까 생략합니다) 그래서 저 20만 달러의 매출액을 송장 발행일의 환율로 계산하여 일본 엔화로 계상해야 합니다. 만약 당일의 달러/엔 기준환율이 1달러 = 80엔 이라고 하면 20만 달러는 1,600만엔으로 환산되겠군요.

그런데, 아직은 이 판매대금이 입금되지는 않은 상태입니다. 매출로 올리긴 했지만 아직 돈을 받은 것은 아니니까 외상매출금이죠. 보통 이러한 거래의 경우, 매입처에서 상품을 받은 후, 기본적인 확인을 완료한 다음에 서로 약정한 날짜에 대금을 결제합니다. 결제한 날자가 인보이스 발행일로부터 2개월 후인 20x1년 7월 1일이라고 가정합시다. 그럼 닌텐도 본사의 외환통장에는 20만 달러가 입금될 것입니다. 그리고 입금이 확인되면, 닌텐도 본사의 회계 담당자는 5월 1일에 기장했던 외상매출금을 입금된 외화예금으로 대체해야 합니다. 쉽게 말하면 외상매출금으로 적어놓은 금액이 이제 입금되었으니 외상(받을돈)이 아니라 예금(받아서 통장에 들어온 돈)이라고 바꿔 적는다는 뜻입니다.

그런데, 환율이란 게 시시각각 변하다보니, 매출을 인식했던 5월 1일보다 환율이 떨어져서 1달러 = 80엔 이었던 것이 1달러 = 70엔이 되었다고 가정해보죠. 그러면 20만 달러의 엔화 환산 가치가 1,600만엔에서 1,400만엔으로 낮아지게 됩니다. 즉, 5월 1일에 물건을 출하하자마자 돈을 받았다서 엔화로 환전했다면 1,600만엔을 벌었을 텐데, 2개월 동안 달러 환율이 떨어지는 바람에(엔고현상) 7월에 달러로 돈을 받고 나니 무려 200만엔이나 환율에 따른 손해를 본 것입니다. 그럼 손해를 본 200만엔은 어떻게 해야 할까요? 이런 경우, 아래 그림과 같이 회계처리가 됩니다.



설명을 하자면, 회계상으로는 5월 1일에 이미 매출을 인식했습니다. 매출을 인식했다는 뜻은 이날에 결산할 경우 1,600만엔의 외상매출금이 손익계산서상의 매출에 포함된다는 말입니다. 물론 아직 돈은 받지 못했지만, 매출은 발생했다고 보는 것이죠. (이런걸 발생주의 회계라고 합니다) 그런데 7월 1일에 외상대금이 입금되고 나니까 환율변동으로 인해 200만엔만큼의 차액을 손해본 것이죠. 이런 경우 그 차액을 외환차손으로 인식하며, 손익계산서 상으로는 매출액은 1,600만엔 그대로 유지되지만, 영업외비용 항목의 외환차손에 200만엔을 넣어 이익 감소를 반영합니다. - 실제로는 지출한 것이 아니라 단지 환율하락에 따른 평가가치가 감소한 것이지만 회계상으로는 '비용'으로 간주하는 셈이죠.

만약, 7월 1일에 들어온 20만 달러를 그대로 외환통장에 보유하고 있다가 8월 1일에 엔화로 환전하는데, 8월 1일의 환율이 더 떨어져서 1달러 = 60엔이 되었다고 가정해봅시다. 그러면 또 외환차손이 발생하는 거죠. 1,400만엔으로 계상해놓았던 외화예금이 1,200만엔이 된 것이니까 외환차손 200만엔이 추가됩니다. 매출금 20만 달러를 매출발생 당시에 1,600만엔으로 인식했는데, 총 400만엔의 외환차손이 발생한 셈이죠. - 외화를 환전하지 않고 보유하고 있어도 기말 결산시에는 결산일의 환율로 환산해서 장부에 반영합니다. 그래서 원래의 환산가액보다 감소했다면 '외화환산평가손실'로 계상하며, 손익계산서에서는 위와 마찬가지로 영업외비용 항목의 외환차손에 반영됩니다. ※물론 이것은 우리나라 기업회계 기준에 해당하지만, 일본의 기업회계기준도 별 차이는 없는 것 같습니다. (굳이 일본의 기업회계기준에 대해 자세히 살펴보고 싶으신 분은 일본 企業会計基準委員会 홈페이지를 참고하시기 바랍니다.)

즉 닌텐도는 2011년 4월 1일부터 12월 31일까지 9개월 동안 이런식의 환율하락(엔화의 가치가 높아져 외화의 가치가 낮아지는 현상)에 따른 환차손으로만 537억엔이라는 막대한 손실을 입은 것입니다. 아마 이 손실을 지켜보는 닌텐도 경영진의 심정은 이럴 겁니다.



그렇다면 닌텐도의 적자는 환차손 문제일까?

환율에 따른 차익이나 차손은 영업활동과는 직접적인 관련이 없는 손익의 변동이므로, 손익계산서에서는 영업외수익 또는 영업외비용의 외환차익이나 외환차손 계정에 계상합니다. 만약 환차익이나 환차손을 영업이익에 반영하면, 실적이 부진해도 환율로 인한 이익 오른다든지 그 반대의 경우가 발생해서 영업실적을 왜곡할 수도 있기 때문이죠. 그래서 기업의 주된 사업이 아닌 루트를 통한 손익, 대표적인 예로 은행예금 이자, 금융상품이나 부동산 투자수익, 환율에 따른 손익 등은 영업이익에 반영하지 않고 영업외수익과 영업외비용 계정에 별도로 계상하는 것입니다.

그런데, 2010년쪽 외환차손과 비교를 해보면 오히려 2010년 3사분기에는 2011년 동기간보다 더 많은 844억엔의 환차손이 발생했었습니다. 그러니까 오히려 환차손은 전년 같은 기간에 비해 33.5%가 줄어든 거죠. 물론 환차손이 줄어든 이유는 닌텐도가 환율대응을 특별히 더 잘했다기보다는 전년에 비해 환율의 하락세가 완만해졌고 매출액이 줄었기 때문이라고 보는게 타당할 것입니다. 간단하게 각 기간별 환차손 ÷ 매출액 으로 계산해보면, 2010년 3사분기는 환차손이 매출액의 10.45%고, 2011년은 9.66%죠. 0.79%p 차이에 불과합니다.

이쯤되면, 닌텐도의 환차손이 큰 것은 사실이지만, 전년의 환차손에 비해 악화되지는 않았다는 사실을 알 수 있을 것입니다. 게다가 2010년 3사분기 누계상으로는 844억엔의 환차손에도 불구하고 당기순이익은 오히려 495억엔을 기록했었죠. 즉 환차손이 문제긴 하지만 막대한 적자의 핵심원인은 환차손이 아니라는 얘기입니다.

그러면 닌텐도 실적 부진의 핵심원인은 어디에 있을까요? 물론 전년에 비해 31.2%나 감소한 매출부진도 큰 원인이고, 매출 감소폭만큼 매출원가와 판매관리비를 절감하지 못한 것도 큰 이유입니다. 그래서 우리는 이 두 가지 요소에 대해서 좀 더 살펴볼 필요가 있어 보입니다.



수익성은 결국 효율성에서 나온다

손익계산서는 보다시피 맨 위에 매출액을 시작으로 해서 아래로 내려가면서 매출원가(-), 판매관리비(-), 영업외수익(+), 영업외비용(-) 등 수익과 비용을 가감하며 매출총이익, 영업이익, 경상이익 등을 구합니다. 그렇기 때문에, 계산의 시작이라 할 수 있는 매출액과 매출원가가 얼마냐가 상당히 중요합니다. 이 시작에서부터 단추를 잘못 잠그면 그 아래쪽에 있는 다른 이익도 대체로 잘 안나오기 때문입니다.

그러면, 아래에 있는 2011년도의 각 분기별 손익계산서를 살펴봅시다. 아래의 분기별 데이터는 분기누계가 아니라 각 분기별로 3개월 동안에 발행한 매출과 비용에 따른 결과값입니다. (닌텐도의 회계연도는 매년 4월부터 시작되기 때문에 1사분기는 2011년 4월 30일부터 6월 30일까지라는 점을 감안하세요)

[자료출처: 일본 MSN マネー  ]
※ 일본은 회계연도를 말할 때 시작일이 아닌 최종 결산일을 기준으로 하기 때문에
자료출처에서는 2011년의 각 분기를 2012년 O분기로 표시한다는 점 착오 없으시기 바랍니다.

이해를 돕기 위해서 원본에는 없는 매출원가율, 매출총이익률, 영업이익률 표시를 추가했습니다. 보시면 알겠지만 1사분기에는 매출액이 낮은 반면 매출원가율이 88.3%나 되기 때문에 매출총이익률도 낮고 영업이익은 무려 △377억엔이나 적자를 기록합니다. 그러다가 2사분기에 와서는 매출액이 오르면서 매출원가율이 5.5%p 낮아지면서 매출총이익률과 영업이익률이 다소 개선됩니다. 물론 여전히 영업이익이 마이너스긴 하지만 그래도 1사분기에 △40.1%의 영업이익률에서 △16.1%가 되었으니 일단 좋아지는 방향으로 선회를 하긴 한 겁니다. 그러다가 3사분기에서는 2사분기에 비해 매출액이 거의 3배가 되면서 전체적인 지표가 확연히 좋아집니다. 특히 영업이익이 적자에서 408억엔의 흑자전환하는데 성공하고, 영업이익률도 마이너스에서 12%로 회복하게 됩니다.

반복해서 언급하지만, 재무제표를 분석할 때에는 급격한 변화에 특히 주목해야 합니다. 그렇다면, 1사분기에서 3사분기까지 오는 동안 어디서 어디에서 어떤 급격한 변화가 있을까요? 일단 1사분기, 즉 4~6월이 아무리 게임산업의 비수기라고는 하지만, 그래도 닌텐도3DS가 출시된지 얼마 되지 않은 시기인데(닌텐도 3DS는 2011년 2월에 출시) 매출이 다른 기간과 비교했을 때 너무 적게 나왔죠. 참고로 2011년 1~3월, 즉 닌텐도의 회계연도 기준으로 2010년 4분기의 매출액은 2,063억엔입니다.그러니까 2011년 1사분기는, 직전 분기에 비해 매출액이 절반에도 미치지 못한 셈이죠.


▣ 과감한 가격인하로 반전을 노린 닌텐도

그랬던 닌텐도의 매출과 손익이, 2사분기부터 회복세로 돌아선 원인은 2011년 8월에 단행된 파격적인 가격인하 정책이었습니다. 당시에 닌텐도는 3DS의 일본 가격을 2만 5,000엔에서 1만 5,000엔으로 무려 40%나 인하했고, 미국에서도 249.99달러에서 169.99달러로 30% 인하했습니다. 출시된지 불과 6개월 여만에 이렇게 큰 폭의 가격 인하를 할 수 밖에 없었던 것은 닌텐도 3DS에 대한 시장의 초기 반응이 그리 좋지 않았으며 초기 가격정책이 실패했다는 이야기가 되겠죠.

그래서 8월에 3DS의 파격적인 가격인하를 단행하고 나서 판매량이 다소 호조를 보이자 그 실적이 조금 반영된 2사분기(2011년 6월~9월) 매출은 1사분기에 비해 278억엔 증가하고 그에 따라 매출총이익률과 영업이익률이 다소 개선되었습니다. 그리고 3사분기에서는 겨울특수까지 겹쳐지면서 드디어 영업이익이 흑자로 돌아섰죠.

그렇다면, 닌텐도의 성적부진의 원인은 환차손보다 3DS의 매출부진이 더 큰 원인이라고 할 수 있을까요? 적어도 손익계산서상으로만 볼 때에는 그렇습니다. 환차손이 수백억엔에 달해서 무시할 수는 없지만 닌텐도는 지금까지 전통적으로 환차익보다는 환차손을 더 많이 떠안아온 기업입니다. 특히 2008년(2008년 4월~2009년 3월)에는 1,339억엔의 환차손을 보고도 2,790억엔의 당기순이익을 기록하기도 했었죠. 지난 20년 동안 매년 결산기의 환차익과 환차손을 합산 비교해 봐도 합산환차익은 2,734억엔인 반면, 합산환차손은 그 두배에 육박하는 4,999억엔에 달합니다. 이쯤되면 닌텐도에게 있어서 환차손은 적자의 핵심원인이라고 보기는 어렵습니다.


▣ 매출감소도 문제지만 효율성 저하가 더 큰 문제

자 그러면, 단지 3DS의 매출이 잘 안나오는 것이 닌텐도 부진의 핵심원인일까요? 물론 표면적으로는 그렇습니다. 누가 봐도 3DS는 예전의 NDS 시리즈나  Wii와 같은 폭발력을 보여주지 못한 것은 사실이니까요. 하지만 단순히 매출이 양적으로 줄어든 것만이 문제가 아니라 질적인 측면에서도 악화되고 있다는 점이 더 큰 문제입니다. 이게 무슨 소리일까요? 매출액은 수치인데 질적인 측면이 따로 있다니... 일단 아래 표를 한 번 보시죠.


위 표는 닌텐도 Wii와 3DS의 기간별 하드웨어, 소프트웨어 판매량(매출액이 아니라 판매된 숫자) 통계입니다. 자료 원본에는 없지만 각 기간별로 소프트웨어 판매량을 하드웨어 판매량으로 나눈 '배수'라는 데이터를 추가해봤습니다. 즉 하드웨어 판매량에 비해 소프트웨어가 몇 배나 더 팔렸는지를 나타내는 값이죠. 보시면 알겠지만, 3DS는 2.5배 정도에 불과합니다. 아무리 출시 초기에는 하드웨어가 많이 팔릴 수 밖에 없긴 하지만 아무리 그래도 출시 초기부터 5~6배를 넘어선 Wii의 경우와 비교할 때, 3DS의 소프트웨어 판매비율은 실망스럽기 짝이 없습니다.

아직 3DS가 출시된지 1년 정도 밖에 되지 않았기 때문에 단순 비교는 어렵지만 닌텐도의 다른 제품들과 이 배수를 비교해보면 ▲패미컴(NES): 8.1  ▲슈퍼패미컴(SNES): 7.7 ▲닌텐도64: 6.8 ▲게임큐브: 9.6 등으로 3DS보다 소프트웨어 판매비율이 매우 높습니다. 3DS와 같은 제품군인 휴대용 게임기의 비율과 비교하자면, ▲게임보이: 4.2 ▲게임보이어드밴스: 8.7 ▲닌텐도DS시리즈: 5.9 입니다. 즉, 닌텐도DS 하드웨어가 한 대 팔리면 소프트는 6개 가까이 팔렸다는 뜻이 되죠. 반면에 3DS의 소프트 판매 비율은 닌텐도의 어떤 제품과 비교해도 너무 낮습니다.

이말은 즉, 3DS의 판매부진으로 매출액이 적은 것도 문제지만, 소프트 판매비율이 낮아 수익성이 떨어져서 더 큰 문제가 되고 있는 것입니다. 아시다시피 콘솔 게임 산업은 하드웨어보다는 소프트웨어를 팔아야 남는 장사인데, 3DS의 소프트가 좀처럼 팔리지 않고 있으니 닌텐도의 머리는 더욱 아프겠죠. 이 데이터를 놓고 보면, 최근의 손익계산서에서 매출총이익률이 잘 나오지 않는 이유가 분명해집니다. 분기별 손익계산서를 다시 한 번 놓고 보자면, 3DS의 판매량이 적었던 2010년 4사분기(2011년 1월 ~ 3월)에는 매출총이익률이 32.7%였는데, 3DS가 본격 판매되기 시작한 2011년 1사분기와 2사분기에는 11.7%, 17.2% 밖에 나오지 않았습니다. 그러다가 2011년 여름에 파격적인 가격인하를 하고나서야 매출총이익률이 29.1%로 크게 올라선 것이죠.


즉, 2사분기와 3사분기에 들어서면서 매출총이익률과 영업이익률이 개선된 점, 즉 매출의 효율성이 올라간 것은 결국 3DS의 가격인하에 따른 기기 판매량이 늘면서 매출원가율이 낮아졌고, 기기 보급이 확대됨에 따라 소프트 판매량이 증가한 것으로 분석할 수 있겠습니다.

판매량이 증가하면 매출원가율이 낮아지는 이유는?
원가에는 고정비변동비라는 것이 있습니다. 고정비는 생산량의 증감과 관계없이 항상 일정한 비용을 말하며, 변동비는 생산량의 증감에 따라 함께 변하는 비용입니다. 예를 들어 정규직 근로자의 임금, 사무실 임대료, 공장시설의 감가상각비 등은 생산량에 관계없이 일정하게 지출이 발행하므로 고정비에 해당하고, 제품의 재료, 부품, 포장비 등은 생산량에 따라 변하기 때문에 변동비가 됩니다.

원가를 계산할 때에는 단순히 제품에 들어간 부품이나 재료의 비용만 계산하는 것이 아니라, 판매가 가능한 상태까지 만드는데 소요된 각종 시설, 노무, 원재료 등의 경비가 다 반영됩니다. 그래서 고정비가 높은 경우에는 생산량이 적으면 원가가 상승합니다. 예를 들어, 하루 고정비가 2만원이 드는 공장에서 1개당 재료비, 생산비가 100원이 드는 제품을 1000개 만들었다고 하면, 10개를 만드는데 든 원가총액은 2만원 + (100원 x 1000개) = 12만원이 됩니다. 그러면 1개당 제조원가는 120원이 되겠죠. 그런데 이 공장의 생산량이 줄어서 다음날에는 500개만 만들었다면 이날의 원가총액은 2만원 + (100원 x 500개) = 7만원입니다. 이걸 다시 생산개수 500개로 나누면 1개당 제조원가는 140원이 되는 거죠.



  1. 매출액의 규모가 크게 감소하는 추세다.
  2. 지속되는 엔화 강세로 인해 환차손이 전체 매출액 대비 10%를 전후하고 있다
  3. 3DS의 초기 시장진입이 실패했다
  4. 3DS의 소프트 판매비율이 낮아 수익성이 떨어진다
  5. 2011년부터 Wii의 제품수명이 급격히 노후화되기 시작했다





// 생각보다 글이 길어지는군요. 이제 결론 부분이 쪼끔 남았습니다.
반응형
,
Posted by 친절한티스

어디다 병렬 프로그래밍을 써야 할까?
앞서 포스팅에서 OpenMP, TBB, PPL 등 유용한 라이브러리를 통해 병렬 프로그래밍을 보다 손쉽게 ( 그래도 힘들지만 ) 사용할수 있다는 것을 알았습니다. 이제 나도 병렬 프로그래밍을 써먹어 볼수 있겠다는 부푼 꿈을 안고 코딩을 시작합니다. 그런데... 그런데... 대체 어디다 적용하지...?
 

막상 병렬 처리를 적용하려니...

병렬 처리를 하기 위해서는 말그대로 병렬성이 있는 곳. 쉽게 말해 동시성을 찾아내야합니다. 그냥 아무곳에나 병렬 처리를 적용 할수 없는 겁니다. 그럼 게임 로직에서 병렬화를 할수 있는 부분은 어떤게 있을까요? 일단 기본적인 게임 로직 흐름도를 살펴보겠습니다.

기본 적인 흐름도

게임 프로그래밍을 조금이라도 하신 분이라면 굉장히 친숙한 흐름도 일겁니다. 사용자의 입력을 받아, 현 상태를 업데이트 하고, 업데이트한 정보를 토대로 그려냅니다. 여기서 병렬화가 가능 한 곳을 한번 찾아볼까요? 처음 입력 부분을 병렬 처리로 하면 어떨까요? 키보드, 마우스, 조이패드 등등을 동시 입력하는 경우가 많으니 이 입력 장치들을 병렬로 처리 하는 겁니다. 여러 입력 장치에서 입력된 정보를 멀티 코어를 이용해 동시에 파파파파팍!!! 처리 하면... 네 별 효용이 없겠죠. 이미 입력 장치는 병렬 처리 같은거 안하더라도 키나 버튼 입력 상태를 한번에 조사가 가능합니다.

이런 쓸데없는 짓은 하지 맙시다.

다음으로 로직/씬 업데이트 부분은 어떨까요? 이곳은 왠지 병렬화 할수 있는 곳이 많을것 같습니다. 게임에 등장하는 각종 오브젝트며, 효과들 처리가 굉장히 많죠. 또한 게임 실행에 있어 가장 많은 시간을 할애 하는 곳 중 하나 이기도 합니다. 보통 게임 오브젝트를 업데이트 할때 씬그래프라는 트리 구조 형태를 따라 순차적으로 업데이트 할때가 많습니다. 이 것을 병렬로 처리 한다면 왠지 빠를거 같지 않나요? 일단 병렬 처리 후보로 생각해봅니다.


위 그림 처럼 트리 형태의 구조를 밑 그림의 형태와 같이 병렬화를 한다면 어떨까?


다음으로 렌더 부분을 살펴보겠습니다. 보통 업데이트가 끝난 오브젝트들을 화면에 순차적으로 그려 내는 부분입니다. 여기서 각 스레드에 여러 오브젝트를 할당해서 각자 맡은 바를 그리게 할 수 있다면 어떨까요? 동시에 여러 오브젝트들을 그려낼수 있으니 한 화면에 많은 오브젝트들이 등장하는 상황이라면 굉장히 유용할 듯 해보입니다. 하지만 이 부분은 생각처럼 쉽지 않습니다. 비동기적으로 오브젝트들을 그리게 된다면 그리는 순서가 뒤죽박죽 될때고 디바이스 점유 문제도 있습니다. 그래도 답이 없는 것은 아닙니다. 최근 DX11 같은 경우 멀티스레드 환경에서 렌더링을 할수 있는 방법을 제공해주고 있죠.

MS사가 그냥 놀고만 있는 것은 아닙니다.

다른 곳도 찾아보자
위 처럼 각 로직 부분에서 병렬화가 가능 곳을 찾는 것외에도 각 로직 부분 자체를 병렬화 하는 것도 생각해볼만 합니다. 전체적인 게임 실행 흐름도를  다시 봐주세요. 입력을 받고 -> 업데이트 하고 -> (업데이트 내용을 기반으로 애니/물리 연산 ) -> 그린다. 이 흐름을 순차적인 아닌 병렬로 처리하면 어떨까요?



위의 흐름도를 보시면 각 스레드별로 특정 작업을 할당 하고 있습니다. 1번 스레드는 게임 로직을, 2번 스레드는 업데이트된 정보를 기반으로 애니메이션 및 물리 연산을 ,그리고 3번 스레드에서는 최종 계산된 정보를 바탕으로 오브젝트를 그려냅니다.

이 외에 다른 곳에서도 병렬화를 통해 멀티코어 CPU를 활용할수 있습니다. 대표적으로 파티클 시스템이 있습니다. 파티클의 경우 데이터 의존성 문제도 크지 않고, 쉽게 병렬화를 할 수 있는 부분 중 하나입니다. 많은 상용 게임 중에서도 파티클 시스템을 병렬화한 경우를 심심치 않게 볼 수 있습니다.

밸브사의 소스 엔진 파티클 시스템

이뿐만이 아닙니다. 후처리 기법 중 하나인 MLAA (Morphological Anti-Aliasing)를 CPU 단에서 병렬화를 통해 빠른 AA 연산을 할수 있도록 하는 방법도 나와있습니다. 보통 AA 연산은 GPU를 통해 이루어지는데 GPU의 부담을 덜어주고, CPU의 멀티코어를 활용해 보다 빠른 AA 연산을 수행 하는 것이지요.

CPU Based MLAA의 성능 지표. GPU에서 지원하는 MSAA 보다 빠르다!!!

CPU 놀지말고 일해!! 찰싹~ 찰싹~
암달의 법칙을 보면 아무리 병렬화를 통해 속도 업을 꾀하더라도 게임의 수행 속도가 몇배가 되지는 않습니다. 어쩌면 들이는 공에 비해 결과물이 그닥 일수도 있습니다. 하지만 그렇다고 CPU를 놀리는 것도 안타깝죠. 그렇기에 멀티 코어를 이용한 다양한 방법들이 연구되고 있습니다. 위의 CPU Based MLAA 같은 것들이 대표적인 예죠. 최근에는 DOD를 이용해 CPU 활용을 극대화 시키는 방법도 많이 연구되고 있습니다( 맥좀비님의 DOD 포스팅 기대 중. 맥좀비님이 다 해결해주실거야~ )

CPU가 놀고 있으면 썰어주자

대략 멀티코어를 활용할 수 있는 방법들을 훓어 보았으니 다음 강에는 좀더 디테일 하게 파볼 수 있으면 파보겠습니다.
고...
 

너무 마구잡이로 써대서 글이 산만해도 이해해주시기 바랍니다.
오류나 다른 의견 있으신 분은 덧글 남겨주세요. 수정/보완 하도록 하겠습니다.
제목이 병맛 프로그램으로 보이는 건 기분탓이 아닙니다.


반응형
,
Posted by 대마왕J

1. ShaderFX 메터리얼


자... 지금까지 배운 것들을 잠깐 정리해 보겠습니다.

a. 칼라 노드를 만들 수 있게
되었습니다.




원하는 칼라가 출력되는 노드를 만들 수 있게 되었습니다.









b. 텍스쳐 노드를 만들 수
있게 되었습니다.

사실 정식으로 쉐이더 코드를 짜려면, 텍스쳐 샘플러를 선언하고, UV 를 버텍스 쉐이더에서부터 받아서 픽셀 쉐이더로 넘겨오는 과정부터 거쳐야 하지만, 맨 첫 강의때 말했듯 이건 그래픽 디자이너를 위한 강의이므로 '일단 간지나게 만들고 공부는 나중에 한다' 라는 구조로 진행합니다 후후후
그러므로 여러분은 텍스쳐 노드를 만들 수 있게 되었습니다.








c. 텍스쳐 노드의 채널을 따로 따로 다룰 수 있게 되었습니다.



RGBA로 이루어진 텍스쳐 채널 구조를 배우게 되었습니다. 각각은 float으로 이루어진 상수이고, 이것들이 모여서 칼라와 투명도를 정합니다. 그리고 따로 사용할 수도 있습니다.








d.상수를 만들 수 있게 되었습니다.



상수, 별 거 아닙니다. 그냥 숫자입니다. 1+1 같은 공식에서 1이 상수란 말입니다. 여기서는 float 이라고 해도 문제 없겠지요. 어차피 보통 소숫점을 쓰니까요.











e. 연산자를 만들 수 있게 되었습니다.



사칙연산이 가능하게 되었습니다. 이것도 별 거 아니죠. 1+1 에서 +를 만들 수 있게 되었다는 건데... 물론 곱하기나 빼기 등도 만들 수 있게 되었습니다. 거의 사용하지는 않지만 나누기 부호도 만들 수 있게 되었구요.










f. 이 출력물들을 연결할 수 있게
되었습니다 .



이 출력물 노드들을 이리 얽히고 저리 얽히게 만들어서 출력할 수 있게 되었습니다. 그리고 Ambient Color에 연결할 수 있게 되었습니다. (여태까지 Ambient Color에만 연결하신 분은 없으시겠지만)











생각보다 꽤 많은 것을 했네요!







지겨우셨을지도 모르지만, 사실 위 내용은 ShaderFX를 다루기 위한 기본 조작 같은 것입니다. 이제 여기에 함수가 추가되면 재미있는 기능이 발현되게 되지요. 그 때부터는 본격적 실습입니다 실습 !




그러기 위해서 오늘은 ... 배운것을 총 정리하는 겸 해서
ShaderFX 메터리얼을 배워보도록 합시다!
별 거 아닙니다. 이 왼쪽에 있는 진짜 루트 노드 말예요 이거.

여기에 연결하는거 배워보도록 하자는 거지요.
겸해서 라이팅에 대한 기본적인 지식을 쬐끔 배워보는 시간을 가지도록 하겠습니다.

제대로 배우시고 싶다고요? 제대로 배우려면 하나당 한 번의 강의로 해야 해요.
그러니 그건 나중에 , 라이팅을 직접 만들 때가 옵니다. 그 때 알려 드릴께요 .
그전에 실버치매님이 알려주시겠지





오늘 강의를 따라하면 드디어 이런 이미지를 만들 수 있게 됩니다.
그런대로 볼만하지요?




2. Diffuse Color 연결하기

Diffuse Color는, 확산광 (擴散光) 이라고도 불리며[각주:1] , 복잡하게 설명하면 어려워지지만, 간단하게 이렇게 생각하면 일단 편합니다.

"빛 때문에 밝고 어두워지는 색깔"

나중에 자세히 말하겠지만, Diffuse Color에서 가장 밝은 부분은 1이고, 가장 어두운 부분은 0입니다. 당연하게도 중간쯤 밝은 부분은 0.5겠지요.[각주:2]
그리고 이 값이 텍스쳐에 곱셈 연산이 됩니다. 즉 가장 밝은 부분은 텍스쳐의 고유한 색상이 되고, 가장 어두운 부분은 검은색이 되는 거지요.


그러므로, 아래 그림처럼 텍스쳐 노드를 만들고, RGB 채널을 Diffuse Color에 연결해 주면 그것으로 끝입니다.
빛의 밝고 어두움에 따라 음영이 지는 주전자를 볼 수 있습니다.
D_cobblestone.dds 를 적용하였습니다.[각주:3]





2. Ambient Color 만들어 연결하기

지금 당장 책상 아래를 보세요. 빛이 전혀 닿지 않는 곳임에도 불구하고 새카맣지 않고, 어스름히 보입니다.
그렇지 않습니까? 이것은 무엇 때문일까요?

이 세상에는 많은 물체가 있고, 그 물체들은 태양으로부터 나온 빛을 받아 반사하거나 , 흡수하고 있습니다. 때문에 빛이 직접 닿지 않는 곳이라 하더라도 새카맣게 보이는 경우는 없지요.

이 계산을 실제로 한다면 엄청나게 복잡할 수 밖에 없습니다 .때문에 이런 '환경 반사광' 을 직접 계산하지 않고, 단순히 칼라를 더해 (+) 줌으로써 이를 흉내내 주곤 하지요. 이것이 환경광 (Ambient light) 입니다.

이 빛은 방향성도 없고, 그냥 전체 화면에 일정 색을 더해주는 것 뿐입니다. 이것은 어떤 환경이냐 따라 다양한 색을 가지는데요. 쉽게 말해서 석양이 질 때는 붉은 계열 색을, 맑은 날에는 푸른 계열의 색을 쓰는 것이 일반적입니다.

아주 맑은 날은 건물의 어두운 부분이 하늘색입니다. 이것이 Ambient light.
자, 이렇게 Ambient Color에는 그냥 단색 칼라를 연결해 주도록 합시다.[각주:4]

잘 보이게 하기 위해서 조금 강하게 넣었습니다. 조금만 밝아도 화면 전체가 밝아지니, 아주 어두운 색을 조심스럽게 쓰는 것이 요령입니다. 칼라를 조절하고 Set 버튼 누르는 것을 잊지마세요.



3. Specular Color 만들어 연결하기
Specular Color는 정반사 (正反射 : Specular Reflection) 의 색상을 의미합니다. 이것은 광원으로부터 나온 빛이 바로 반사하여 시야에 들어오는 '하이라이트' 를 의미하는데요.
자세한 내용은 실버치매님의 글 http://gamedevforever.com/17 을 읽어보시면 되겠습니다.[각주:5]

여기서는 그냥 색을 넣어주기만 하면 가동됩니다.
일반적으로 아무 생각 없을 때에는 흰 색을 넣는데요. 실버치매님의 글을 읽어보시면 사실 이렇게 간단한게 아니라는걸 아실 수 있으실 겁니다 .

그래도 우리는 초보니까 흰 색을 넣지요 헤헷.

간단하게 Specular 라이팅이 활성화 되면서, 칼라도 들어갔습니다. 물론 흰색은 좀 이상하지요. 원하시는 색으로 바꾸셔도 무방합니다. 정렬의 빨강색이라던가
심지어, float3가 들어가니까 RGB텍스쳐를 따로 만들어 적용하는 것도 가능합니다.[각주:6]



4. Specular Level 연결하여 조정하기

이제 그 아래 있는 Specular level입니다. 이것은 스페큘러의 강도 같은 것을 결정하는건데요, float 하나가 들어간다는 것을 알 수 있습니다. 즉 0~1 사이의 값으로 강도를 조절한다는 거지요.
물론 상수를 하나 만들어서 저기다 연결해도 잘 작동합니다만...

자, 지금 더 돌 재질을 잘 보세요. 무슨 느낌인가요? 마치 덕수궁 돌벽같은 느낌이 아닌가요? 돌이 튀어나와있고 돌들 사이에 시멘트로 매워진 벽 느낌이요.
여기서는 그래서 돌 재질이 있는 부분만 반짝이고, 경계선 부분은 반짝이지 않게 하려면 어떻게 해야 할까요?
뭔가... 마스킹이 있어야 하겠지요? 돌 부분은 살리고 경계선은 죽이는.. 그런 이미지가 필요할겁니다.
그리고 그 마스킹 이미지가 이미 있습니다.

Diffuse Texture 로 사용했던 이미지의 Display Alpha 옵션을 켜보세요. 이건 이 이미지의 알파 채널이 있다면, 그 알파 채널이 어떻게 생겼나 보여주는 겁니다.

그걸 켜 보니까 이미지가 바뀝니다! 흑백의 알파 채널 이미지가 나옵니다.
네, 이 이미지는 알파 채널을 가지고 있었던 겁니다. 그것도 저런 모양으로.
마스킹으로 쓰기에 딱 좋은 이미지로 보입니다.

이전에도 누차 말씀드렸지만, 알파 채널에 그림이 있다고 전부 투명도는 아닙니다. 그 채널을 'Opacity' 에 연결했을때 투명도가 되는거지, 아무 짓도 하지 않으면 어떤 채널에 있는 이미지건 그냥 float 덩어리일 뿐이란 말씀입니다.

이 오브젝트는 투명도가 필요 없습니다. 즉 이미지의 알파 채널은 어차피 쓰지 않는단 말이지요.
그래서 우리는 이 알파 채널을 Spacular level로 쓰기로 결심하였습니다. 이어줍시다.[각주:7]

연결했습니다 . Specular 영역이 잘 보이도록 Specular Color를 빨강으로 바꿔 보았습니다. 어떻게 보입니까?
돌이 있는 부분은 Specular 가 강하게 들어갔고, 돌이 없는 사이의 부분은 매우 약하게 들어갔다는 것을 볼 수 있습니다.
마스킹 이미지도 보시면, 밝은 부분이 아주 흰 색이 아니고 어두운 부분이 아주 검은 색도 아닙니다.
그래서 이렇게 적절한 강도로 들어간 것입니다. 위에 소개한 실버치매님의 글을 읽어 보신분은 아시겠지만, 완전히 Specular가 없는 물체는 없는 법이니까요. 오히려 이게 더 자연스럽다고 할 수 있겠습니다.




5. Glossiness 연결하여 조정하기
Glossiness는 Specular의 퍼짐 정도를 조절하는 메뉴입니다. 둔탁한 오브젝트일수록 Specular가 퍼질 것이고, 유리나 잘 닦은 당구공처럼 매끄러운 오브젝트일수록 Specular가 강하고 얇게 맺힐 것입니다. 이걸 조절하는 겁니다.

이건 단순하게 상수로 조절해 주도록 하겠습니다.
굳이 이젠 설명할 필요도 없겠지요. 직접 비교해 보세요.

1일때에는 넓게 퍼집니다.

10 정도 되니까 좀 줄어드는 군요.

100 정도 되니까 더 작아졌습니다.

물론 이것도 float이기 때문에 아까 Specular level에서 사용한 Alpha 채널을 마스킹으로 이용할 수 있겠습니다만, 그냥은 못쓰고 * 10 정도를 해 줘야 조금 쓸만할 겁니다. 그치만 여기서는 해도 잘 안보일것 같아서 넘어가도록 하지요. 다음에도 할 기회는 충분합니다.

자 이제 값을 20정도로 하고 Speculat Color도 다시 흰 색으로 만들었습니다.





6. Self - Illumination 만들어 연결하기
Self-illumination (자기 발광 自己光) 은 스스로 빛나는 효과 같은 것을 만들때 사용됩니다. 스스로 빛을 내는 발광체 표현을 할 때 주로 사용되지요. Diffuse Color의 음영값과 상관없이 자신의 칼라가 언제나 나타나게 되는 특징이 있습니다.[각주:8] 셰이더 프로그래밍에서는 Self-illumination이란 말을 거의 쓰지 않고, Emission 이라는 말을 주로 사용합니다


사실 이번엔 안 쓸 재질이지만, 특별히 시험삼아 잠시 텍스쳐를 넣어 보았습니다.
caustics_001.bmp 가 적절해 보이는군요.[각주:9]

뭔가 빛나는 것처럼 보입니다.

시험삼아 넣어본 것이니, 삭제하도록 하겠습니다.





7. Normal map 넣어보기
네에 Normalmap입니다. 뭔가 마법의 텍스쳐같은 Normal맵이죠. 분명 폴리곤이 없는데도 막 울퉁불퉁해지는!!!
그 이유 같은건 역시 나중에 알아보고, 일단 넣어보도록 해보겠습니다.

노말맵을 만들 때에는 일반 텍스쳐처럼 만들면 안됩니다.
빈 화면에서 오른쪽클릭을 하고 Maps/NormalMap을 선택합시다.

일반 텍스쳐를 선택하면 안됩니다. 노말맵은 -1.0~ 1.0 사이의 값이 필요해서, 그냥 텍스쳐 영역을 쓰면 안되거든요.[각주:10]


그리고 여기에 N_cobblestone_ati.dds 를 넣어주겠습니다.
잘 나옵니다



...Opacity는 안넣겠습니다. 뭐 다 알잖아요?



오늘은 이렇게 메터리얼에 값 넣는 것을 해 보았습니다. 중간에 연산자 같은거 넣고 막 이러면... 복잡하게 할 수 있어 보이죠? 앞으로 하다보면 다 하게 됩니다. 힘내세요!

다음 시간에는 뭘 할까요? 이런걸 생각하고 있긴 한데..
- Lerp로 텍스쳐 섞기
- 큐브맵 사용해 보기

  1. 난반사광 이라고도 불리며, 산광이라고 불리는 등, 여러 가지 용어로 불리우고 있습니다. 그냥 Diffuse light 라고 부르는 것이 나을 것 같습니다. [본문으로]
  2. 추후에 이 계산을 직접 수식으로 만들어 보게 됩니다. 그 때 더 자세히 알아보도록 하지요. [본문으로]
  3. 빛을 직접 설치하고 싶으신 분은, Directional light 하나를 설치해 보십시오. 여러 개도 가능하지만, 현재 설정으로는 한 개의 Directional light 밖에 적용되지 않습니다. [본문으로]
  4. 물론, IBL 이나 Ambient Cube 등의 발전된 기법들도 사용됩니다만 아직도 많은 게임들은 단순한 Ambient Color를 쓰는 경우가 많으므로 우리도 그렇게 하는 것이 아무런 문제가 되지 않을것입니다. [본문으로]
  5. 저는 이거보다 더 잘 쓸 자신이 없어서요. 데헷. [본문으로]
  6. 텍스쳐가 한 장 더 필요하게 되므로 리소스도 사용하게 되고 만들기도 귀찮은 작업이 되지만, 최신 게임에서는 실제로 이렇게 만들어서 적용하고 있습니다. 당장 여러분의 다음 프로젝트에서도 쓸 지도 모르지요! 아니면 이미 쓰고 있다던가!!! [본문으로]
  7. 실무에서도 엄청나게 많이 쓰이는 요령입니다. 텍스쳐는 무조건 아껴야 하거든요. 남는 채널이 있으면 무언가의 마스크로 꼭 쓰도록 합시다. [본문으로]
  8. 뭔가 거창해 보입니다만, 사실은 Ambient와 다른게 하나도 없는 녀석입니다. Self - illumination에 넣지 않고 Ambient Color에 넣어도 완전히 똑같이 작동합니다. [본문으로]
  9. 앗! 노드들이 어떻게 저렇게 작은 사이즈로 변했지요? 라고 생각하신다면, 노드를 더블클릭 해 보세요. :) [본문으로]
  10. 뭐 지금부터 알 필요는 없지만.... 0.0~1.0 사이에 있는 값을 -1.0~1.0 으로 확장하는 법은 *2-1 을 해주면 됩니다. 이런 놀라운 (?) 공식을 '매직 넘버' 라고 합니다 :) [본문으로]
반응형
,
Posted by 알 수 없는 사용자

01. what
02. how
03. storytelling
04. prototyping 上
05. prototyping 下

대부분의 경우, 그 어떤 것이든 '만든다'라는 것은 '무엇을(what)', '어떻게(how)' 할 것인가에 대한 생각에서 출발한다. 그렇게 시작된 '무엇을 어떻게 만들 것인가'는 게임에 있어서 플레이어에게 그 무엇을 어떤 재미의 유저경험(User eXperience, 이하 UX)으로 전달할 것인가로 귀결되게 된다. 이러한 what, how, UX에 대해 분명한 의도를 갖고 정리된 형태가 '게임 기획'이라고 볼 수 있다. 이 정의가 매우 간결하고 강력하게 그 일관된 특징을 전달할 수 있다면 그로써 하나의 '디렉션 비전' 즉, 프로젝트의 청사진이 될 수도 있고, 어떤 하나의 기능에 대해 구체적으로 파악할 수 있게 정리된다면 그로써 하나의 '기획서'가 될 수도 있을 것이다.

게임 기획은 크게 시스템이나 메커니즘, 로직을 만들기 위한 시스템 기획과, 스토리와 환경, 레벨을 만들기 위한 컨텐츠 기획으로 구분할 수 있다. 기획서를 작성한다면, 그 기획서는 플레이어와 개발자 양쪽을 모두 고려해 작성되어야 한다. 즉, 플레이어에게 어떤 경험을 하게 만들 것인가의 관점에서의 UX가 시뮬레이션 되어야 하고, 그를 게임에 구현할 개발자가 기획 의도 혹은 목표를 명확히 이해시킬 수 있는가의 관점에서 UX가 정의되고 설계 되어야 하는 것이다.

이러한 '기획하기'에 있어 어떻게 비전을 만들고 그것을 협업할 수 있도록 준비하며 진행해 나가는지에 대해 필자의 경험과 시행착오의 이야기들로 본 연재에서 나눠보고자 한다. 여기서 게임 개발 프로젝트에 있어 비전을 만드는 부분은 디렉터(혹은 PD)의 고유 영역에 속하는 부분일 수도 있겠지만, 개발자라면 누구든 (꼭 온라인 게임이 아니더라도) 자신의 게임을 만들고 싶어할 수 있다고 보기에 넓은 관점에서 정리해 보고자 한다. 하지만 먼저 이 내용들은 모두 필자의 주관에 의한 것이기 때문에!! 업계 표준(그런게 있다면;;)이나 수많은 다른 방법들과 접근을 달리할 수 있기에 절대적으로 좋은 유일한 방법이 아니라는 것을 염두해두었으면 한다.



게임 개발 프로젝트에 있어 비전은 무엇을 어떻게 만들 것인가의 '무엇을(what)'에 해당하는, 개발팀이 모두 같은 꿈을 꾸며 달려가야 할 목표가 되어야 한다. 하지만 what을 정의하기 위해 머리를 굴리다보면 애매모호한 경우에 부딪힐 때가 있다. 일단 다음의 예를 보자.

매우 빠르게 동기화되는 다양한 인터랙션의 논타게팅 온라인 액션게임!!

어떻게 보자면 위와 같은 기술적 정의로 구성된 비전도 what에 포괄될 수 있을 것처럼 보인다. 개발팀에서는 위의 내용만으로도 분명 그 목표점이 명확하게 파악될 수 있을 것이다. 온라인 게임에서 ping이나 network latency 등의 이유로 매우 빠르게 실시간 동기화 되는 것의 한계가 있기 때문에, 플레이어가 눈치채지 못할 정도로 예측 판정해 전투 공방하게 만드는 논타게팅 액션이라는 점은 분명 강조하고 자랑할만한 강점이자 특징이 될 수 있을 것이다.
이렇듯 이런 what만으로도 분명 그 안의 how를 찾아낼 수는 있겠지만, 애매모호하다. 이는 위에 서술된 특징이 유저경험을 파악하기엔 너무나도 개발자만의 관점에서 정의되었기 때문이다. 게다가 개발자라 해도 게임의 스토리라이터나 그래픽디자이너가 공감하고 따르기엔 너무나도 추상적이기 때문에, 역으로 보자면 던전앤파이터, 테라, 드래곤네스트 등 그 어떤 게임이 될 수도 있을 정도다.
때문에 이렇게 광범위하고 구체적이지 못한 정의는 프로젝트 전체의 비전으로 가져가기엔 좀 무리가 있다. 물론 게임이 어느 정도 완성된 이후에 마케팅 포인트로써 강조할만한 특징적 요소일 수는 있겠지만, 처음 게임을 만들기 위한 컨셉 기획 방법으로 what을 정의하는데 있어서는 적합하지 못한 것 같다.

오히려 '(동일한) 상상을 할 수 있는' 혹은 '구체화 된 심상의' 방법으로써 레퍼런스형 하이컨셉을 사용해 들어가는 경우가 더 성공적일 때도 있다. 다음의 예를 보자.

악튜러스 + 디아블로 + 하늘사랑 + 하이텔

Arcturus ⓒ Gravity&Sonnori / Diablo2 ⓒ Blizard

뭔가 뜬금없는 조합인듯 하지만, 위의 정의는 2000년부터 몇년동안 필자가 참여했던 MMORPG의 최초 개발 시작 당시 팀 내부에서 공유하던 정의의 방법이였다. 당시 개발팀은 악튜러스라는 패키지 RPG 게임을 막 끝낸 상태였지만 온라인 게임을 개발해 본 경험자가 전혀 없는 상태였고, 기획팀 내 리니지 하드코어 유저가 한명 있긴 했지만 그나마 팀에서 가장 많이 하던 게임이 디아블로2였기 때문에 위와 같이 공감대를 끌어낼 수 있는 하이컨셉화 된 접근을 사용하게 된 것이다.
악튜러스의 그래픽으로 디아블로 같은 멀티플레이/파티 전투를 하며, 하늘사랑 같은 커뮤니티 시스템과 하이텔 장터 같은 거래 시스템을 합쳐낸 게임을 만들자..로 시작한 프로젝트가 바로 라그나로크 온라인이였다. 이러한 접근은 우리가 알고 있고 경험해본 기준들을 참고로 하기에, 그 개발의도나 유저경험을 비교적 빠르고 명확하게 잡아 들어갈 수 있는 장점이 있다.

Ragnarok Online ⓒ Gravity

하지만 이 방법은 좋게 말하면 영감을 주는 롤모델, 나쁘게 말하면 카피한 표절게임을 만들 때에나 적합하지 않냐고 되물을 수 있을 것이다. 근래 들어서 페이스북이나 스마트폰을 통한 소셜 게임 시장이 커지다보니, 유행을 틈타 다수의 유사게임이 등장해 논란이 되기도 하기에 유의해야 할 방법이기도 하다. 하지만 그러한 특징적 메커니즘의 유사성을 띄더라도 넥슨의 페이스북용 메이플스토리 어드벤처처럼 고유의 차별화 된 방법으로 접근한다면 새로운 게임으로써 인식되고 플레이 될 수도 있을 것이다. 때문에 완벽하게 같은 것을 만드는 것이 아닌 이상, 어떠한 영감을 얻어 각각의 요소들이 조합되고 녹아드느냐에 따라 모두 다른 결과물을 낼 수 있는 하나의 기획 과정으로써 하이컨셉의 매쉬업이 좋은 방법이 될 수 있음은 분명할 것이다.

이번에는 스토리를 통한 what의 정의이다. 다음의 이야기를 보자.

추방당한 전쟁의 신의 잔혹한 복수극

이 방법도 사실은 앞서 다뤘던 하이컨셉적인 접근이기는 하다. 헐리우드 영화 업계에서 많이 쓰는 하이컨셉 접근 중에는 타 영화에 대입한 영감으로 샘플링하는 방법과, 간단한 스토리 가정(what if)을 통한 방법을 많이 쓴다고 한다. 앞에서 다룬 내용이 '멈추지 않는 버스 위의 다이하드 (영화 스피드 하이컨셉)' 같은 접근이라면, 스토리를 통한 가정은 '만약 상어가 인간을 공격해 온다면? (영화 죠스 하이컨셉)' 같은 접근 방식이 된다.

추방당한 전쟁의 신이 잔혹하게 복수를 한다면? 이라는 전제 자체가 그 배경 스토리와 캐릭터가 놓여질 상황을 통해 접근하기 때문에, '이미 매우 강력한 영웅적 캐릭터, 엄청 잘 싸우지만 낙오되어 그보다 더 높은 힘에 대항해야 하는 상황이다, 때문에 더 크고 강력한 적에게 대항해 파워업해가며, 복수를 위한 여정을 풀어나간다' 등으로 정리해나가면, 그를 뒷받침하기 위한 높은 수위의 표현, 임팩트 있게 표현되는 액션/리액션, 사지를 찢어발기는 잔혹한 필살기 연출, 단계를 밟아 올라가는 복수 여정의 몰입성 등등으로 어떤 게임의 모습과 유저경험을 만들어 가야할지 모두가 비슷한 상상을 해갈 수 있을 것이다.
이 방법은 그 상황으로 하여금 시스템이나 컨텐츠를 설계해 접근할 수 있도록 하기에 그를 기획하는데 있어 좀더 구체적인 목적성과 통일된 의도를 가지고 설계할 수 있게 만들어 줄 것이다.

 

God of War 3 ⓒ Sony

이렇게 what을 정의하는 것은 개발자나 플레이어 모두가 구체적으로 비슷한 상상을 공유하게 만들어, 그 안에서 만들어야 할 요소와 재미를 찾아가는 최초의 과정이 된다. 그리고 구체적으로 공유하기 위해 가장 좋은 방법은 누구라도 눈으로 확인할 수 있는 이미지를 만들어 접근하는 것이다. 이 방법은 마비노기 영웅전의 이은석 디렉터가 NDC(넥슨개발자컨퍼런스) 포스트모템 강연에서 다루었던, 꿈을 꾸기 위한 1장의 컨셉 이미지와도 닮아있다. 다음의 이미지를 보자.

Uncharted : Golden Abyss ⓒ Sony


위 이미지는 PS vita로 출시된 언차티드의 최신작의 표지 이미지이다. 근래 봤던 게임 패키지 이미지 중 가장 좋아하는 컷이기도 한데, 정글 속 미지의 유적으로의 탐험, 벽 타기를 위시한 수직적 무브먼트, 적과의 총격전, 끊어지는 다리 등 동적인 환경 구성, 상황에 따라 맥락에 맞춰 인터랙션하는 링아웃 리액션 등등.. 언차티드라는 게임이 가지고 있는 대표적인 유저경험의 특징들을 (게임의 스크린샷이 아님에도) 그림 한장에 모두 녹여냈다.
물론 이 이미지는 이미 언차티드란 게임이 3편까지 나온 마당에 처음부터 무엇을 만들어야 할지의 고민으로부터 시작된 그림은 아니겠지만, 마비노기 영웅전의 사례에서 볼 수 있듯 어떤 게임을 만들려고 하느냐에 따라 누구라도 다른 스토리의 유저경험 스케치를 그려낸다면 그것을 비전으로 삼아 공감할 수 있는 좋은 방법이 될 수 있을 것이다.

언차티드의 경우 너티독 측에서 1up.com에 공개한 개발비화를 보면 알 수 있듯, 최초 '3인칭 액션 어드벤처'를 만들겠다는 목표 하에 사전 영상화(Pre-Visualization)을 통해 어떤 플레이가 포괄될 것인가를 영상으로써 구체화하며 접근했다. 이는 갓오브워 시리즈나 스타워즈:포스언리쉬드 등의 차별화된 액션과 연출을 추구하는 작품들에서 많이 사용하는 개발 방법이지만 이 정도까지 하는 것은 기획자가 혼자 할 수 있는 수준이 아니기 때문에, 나중에 storytelling과 prototyping 연재에서 좀더 이야기하도록 하겠다.

이러한 형태로 만들고자하는 프로젝트의 what에 대한 정의를 찾았다면, 그에 대한 커뮤니케이션 오류를 최소화 하면서 밀접하게 피드백을 주고 받으며 구체적인 방향성을 갖는 비전 컨셉으로 만들어가기 위해 how를 고민해야 할 때다. 하지만 기획이 컨셉을 만드는 단계에서 다루는 how는 '어떤 툴을 쓰자, 어떤 로직 메커니즘을 갖는다'에 대한 것으로 시작하지는 않는다. 다음 회에서 이 how에 대한 기획적 접근 방법을 살펴보도록 하자.



반응형
,
Posted by 알 수 없는 사용자

안녕하세요 2일과 17일 담당 박성준입니다. ㅎㅎ
오늘은 게임 오브젝트 설계에 대한 이야기를 해보려고 합니다.
어쩌다보니 연재 형태로 한두편 더 쓰게 될 것 같습니다..


시간이 없어서  할일이 많아서 한번에 다 쓰지 못한것이 아닙니다..
 

회사일이 바빠서 몸이 피곤해서도 아닙니다........
그런데 웬지 눈물이 나네요 ㅠㅠ

어쨌든 허접한 게임 오브젝트 설계 설명을 시작해보겠습니다!



먼저.. 게임 오브젝트가 뭐지?!
게임 오브젝트 설계에 앞서 게임오브젝트가 무엇인지 한번 생각해봅시다!
가장 먼저 떠오르는것은 역시나 
플레이어나 몬스터 같은 캐릭터일 것입니다. 그리고 함정이나 맵에 설치되는 여러가지 엑티브오브젝트들도 역시 게임 오브젝트입니다.


캐릭터나 엑티브 오브젝트외에도, 캐릭터가 서있는 지형도 역시 게임 오브젝트이며, 이렇게 눈에 보이는것들이 아닌 퀘스트나 이벤트를 위한 트리거, 광원, 카메라 등 눈에 보이지 않더라도 오브젝트끼리 무언가 연관되는일을 한다면 모두 게임 오브젝트 라고 할 수 있습니다. 오브젝트끼리 서로 상호작용을 하면서 일어나는 일들이 모여서 하나의 게임을 구성하게 됩니다.


즉, 게임은 게임 오브젝트들이 만들어내는 상호작용의 모음 이라고도 할 수 있습니다. (라고 저는 생각합니다.)
다른 말로 해보면 '어떠한 작용을 일으키거나 받는 모든것들은 게임 오브젝트라고 생각해야 한다' 라고도 볼 수 있습니다. (반드시 그래야 하는건 아니지만.. 전 그렇게 생각합니다..)


그래서.. 게임 오브젝트 설계는 어떻게?!
게임 오브젝트를 설계하는 방법은 만드는 사람마다 다르고 어떻게 어떤 게임을 만드느냐에 따라 다르겠지만 가장 많이 사용되는 방법들이 몇 가지 있습니다. 프로그래밍도 사람이 하는거니까요.. MMORPG에서도 스탯과 스킬트리를 다양하게 찍을 수 있도록 해놔도 결국엔 많이 해본 몇몇 유저들이 올려놓은 공략을 따라가게 되는것처럼 프로그래밍도 비슷하지 않겠습니까?!

첫번째로.. 계층 구조를 사용한 오브젝트 설계 


그 중에서 첫 번째 방법은 계층구조를 이용하여 게임 오브젝트를 설계하는 방법입니다. 불과 몇 년 전까지만 해도 거의 대부분 이런 방식으로 게임 오브젝트를 만들었었고, 현재도 상당히 많은 프로젝트에서 사용되고 있을것이라고 생각됩니다. 이 방법은 말 그대로 게임 오브젝트가 하는 기능을 중심으로 하나의 계층을 만들어 클래스 설계를 하는 것입니다.

예를 들어 Player, Monster, Prop 오브젝트를 만든다고 가정해봅시다.


아주 간단하게 이렇게 만들 수 있을 것입니다. Player, Monster, Prop의 공통된 부분은 GameObject에서 처리를 하고, 각각 타입에 따라 처리해야 하는 것들은 각각 클래스에서 처리를 합니다. 그런데 Player와 Monster는 움직일 수 있기 때문에 그와 관련된 부분을 하나의 계층을 추가하여 같이 사용할 수 있으면 더 좋을 것 같습니다.


그래서 MovableObject 라는 중간 계층을 하나 더 추가하여 이렇게 만들면 움직임 관련된 처리는 이  MovableObject에서 하게 되면 움직임 관련된 코드가 Player와 Monster에 중복으로 있을 필요가 없어집니다.


이제 여기에 Trigger 오브젝트를 추가한다면 어떻게 될까요? Player, Monster, Prop은 모두 화면에 그려지는 오브젝트이지만 Trigger는 화면에 그려지지 않는 오브젝트입니다. 따라서 GameObject에 화면에 그리는 처리를 넣게 되면 Trigger 입장에서는 불필요한 코드가 들어가게 되는 것입니다.


이 그려지는 부분을 RenderableObject라는 계층을 하나 더 만들어서 사용하게 되면 중복된 코드도 없어지고 더 깔끔하게 해결이 될 것입니다. 이런식으로 공통된 부분들을 묶어서 계층을 추가하여 설계해 나가는 방식이 계층 구조를 사용한 게임 오브젝트 설계 방식입니다.


오늘은 여기까지.. 다음 연재에서는 
계층 구조를 사용한 방식의 문제점과 이 문제를 해결하기 위해 나온 컴포넌트 기반 설계 방식에 대해서 등등을 설명을 해보도록 하겠습니다.. (등등은 시간 관계에 따라서 달라질 수 있...)
 


반응형
,
Posted by 알 수 없는 사용자

0. 지분 그것이 문제로다.

일단 법인을 설립하기 전에 고민하는 과정은 이후에 다시 한번 다룰텐데, 그 전에 회사의 지분을 어떻게 할 것인가에 관해서 한번 다루고 넘어갈까 합니다.  이것 먼저 쓰는 이유는 ""아는 분이 이부분에 관해서 최근에 저한테 문의를 하셨거든요. --;;""  먼저 쓸 별 이유 없는데 사실 생각해보면 매우 중요한 이슈여서 한번 언급하고 가는게 좋겠다 싶어서 입니다. 

그 전에, 여러분께서 게임회사를 주식회사로 만드신다면(아마 100/99이상은 다 이렇겠죠?) 법인 설립하실때 정관을 주의 깊게 체크하시길 바랍니다. 

정관이 뭐냐하면

회사 또는 법인의 자주적 법규. 실질적으로는 단체 또는 법인의 조직·활동을 정한 근본규칙을 뜻하고, 형식적으로는 그 근본규칙을 기재한 서면을 의미한다. 정관은 강행규정이나 사회질서에 반하지 않는 한 회사 또는 법인의 구성원 내지 기관을 구속한다. 주식회사의 이사가 정관에 위반한 행위를 한 때에는 회사에 대하여 손해배상책임을 진다.

정관에는 뭘 쓰냐하면

주식회사 정관의 절대적 기재사항은 회사의 목적 ·상호, 회사가 발행할 주식의 총수, 금액, 회사설립시에 발행하는 주식의 총수, 본점의 소재지, 회사가 공고를 하는 방법, 발기인의 성명 ·주민등록번호 및 주소이다(상법 289조 1항). 


입니다.  

무슨 말인지 잘 못 알아먹겠죠? ^^;;

한마디로 정관은 회사가 뭔지, 어떻게 운영할지를 담는 기본이 되는 문서다.  이정도만 아셔도 됩니다. 

잠깐 이야기가 샜네요. 

자 그럼 지분을 어떻게 나눠야 할지는 바로 이 정관과 매우 관계가 깊어서(특히 한국에서는 -_-, 한국은 상법과 회사법이 참 **같아서) 먼저 말씀을 드린 것입니다.

지분을 나눌때의 핵심은, 사실 누가 책임을 많이 지고, 누가 많이 그 소유권(혹은 혜택)을 가져갈 것인가와 관계된 문제입니다. 

상식적으로 생각하면 회사내에서 혜택을 가져가는 기준은 " 기여를 많이 한 사람"이 가져가면 된다라는 것입니다. ^^;; 그런데 그 기여라는게 사실 명확하지가 않아서, 결국은 지분대로 혜택을 가져가게 됩니다. 따라서 지분이라는게 처음에 어떻게 나누고, 혹은 사업 진행되가면서 어떻게 다시 재분배 할 것인가가 항상 첨예하게 대립되는 문제가 됩니다.

따라서 지분을 어떻게 나누는가는 그 구성원들이 계속 어떤 동기를 통해서 열심히 일을 해 나갈것인가와도 관계가 있기 때문에 잘 분배하는 것이 회사 운영에 아주 중요한 부분으로 자리 잡는다는 것입니다.

1.  중요한 것은 알겠는데 도대체 지분을 구체적으로 어찌 나누라는 것이요?
그래서 애정남에게 물어봤습니다. 쿨럭. -_-;;

일단 지분은 말입니다.  한사람이 100% 다 가지고 있는 것을 권합니다.
솔직히 이게 제일 깔끔합니다.  vc든 어디든간에 투자 받기 전까지 한사람이 다 책임지고 가는 것이 가장 아름다운 지분 구조입니다.  이게 어디 쉽냐고 하신다면 할 말은 없습니다.

문제는 이게 안된다는 것이죠.

그래서 굳이 지분을 나눠서 초기에 회사를 꾸려 나가야 한다면 제가 추천하는 바는

2인일때는 6:4

3인일때는 6:3:1

4인 이상일때는 1인:다수=6:(다른 사람들 합해서 4)

로 하시길 추천하는 바입니다. 

자 왜 이렇게 나누는게 좋을까요?  
이것만해도 굉장히 이야기가 많기 때문에 한주 정도 이 부분만 다루도록 하겠습니다.

일단 핵심은 한사람이 60% 이상 가져서 책임과 권한 자체를 충분히 맡을 사람이 필요하다는 부분 때문입니다.  그러나 나머지 사람들이 40%를 가지고 있어야 하는 것은 1인이 맘대로 회사를 좌지우지해서는 안되기 때문입니다.  왜 이런지는 다음번 글에서 다루도록 하겠습니다.
그리고 주주들끼리는 주주간 계약서를 필히!! 작성하시길 바랍니다.

주주간 계약서에 꼭 포함되어야 할 내용은 우선매수권과 동반매도권 입니다.

이 역시도 상당히 긴 내용이기 때문에 1회에 걸쳐 다루도록 하겠습니다.


이번주의 소 결론

1.  지분은 책임과 권한 모두를 가진다.(물론 상법적으로 책임은 출자한 부분에 대해서만 지지만 그런 뜻이 아닌, 실제 회사를 키워나가는데 있어서 하는 말입니다. ^&^ 오해 마시길.)
2.  주식회사에서 정관이 정말 중요하다
3.  지분은 가능하면 60:40의 비율로 나눠라.(한쪽에서 60을 갖는게 핵심, 그 이상도, 이하도 아닌 60이 적당)
4.  주주간계약서 꼭 작성하고, 그 안에는 우선매수권과 동반매도권 포함시켜라.

이 네가지 입니다.  

 
다음번에 써야할 내용이 우수수 나왔네요.  차근차근 따라가봅시다. 
반응형
,