한국 개발자로 살아간다는 것

Source : http://imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=32089

 

오늘도 개발자들은 고객의 요구사항에 따라 프로그램을 개발한다. 개발하는 틈틈이 최신 기술을 공부하면서 더 효율적이고 생산적으로 개발하는 방법을 익히고자 한다. 필자는 이 글을 통해 앞만 보고 열심히 일하는 개발자들에게 거시적인 관점에서 우리들의 주변 환경이 어떻게 돌아가고 있는지를 되돌아볼 시간을 마련해 주고자 한다.

한 용 희 woom33@korea.com
롯데정보통신 정보기술연구소에 재직 중이며, 닷넷 기반의 여러 프로젝트에 참여했다. 현재 Microsoft Visual C# MVP이며 MSDN 세미나 강사로도 활동 중이다. 처음에는 2D, 3D 게임 프로그래머로 시작하여 SQLServer 튜닝, 응용 애플리케이션 개발에 이르기까지 다양하게 경험하였으며, 주요 관심사는 DB와 애플리케이션의 연동 부분이다.

 

어렸을 적부터 필자는 개발하는 일 자체가 즐거웠다. 내가 어떤 것을 만들 수 있다는 것 자체가 매우 흥분되고 재미있는 일이었다. 기존의 장난감에는 창의력을 불어 넣을 수 없었다. 레고 블록과 같이 모양이 정해진 부품으로는 완전히 새로운 창작물을 만들 수 없었다. 하지만 프로그래밍은 훨씬 더 새로운 작품을 만들 수 있어서 좋았다. 필자는 그렇게 프로그래밍의 재미라는 것을 느꼈고 그 순간부터 커서 개발자가 될 것이라고 마음에 꿈을 가졌다.

프로그래밍의 재미를 알고부터는 시간이 나면 틈틈이 프로그래밍을 했다. 이러한 재미가 직업이 되면서부터 일은 필자에게 돈을 버는 수단인 동시에 재미를 느끼는 수단이 되었다. 하지만 언젠가부터 개발이라는 작업이 내가 원하는 것만 만들 수 있는 것도 아니었고, 내가 원하는 시간에 내 마음대로 혼자서 할 수 있는 것도 아닌 그런 존재가 되었다. 개발이라는 것이 결코 혼자만의 예술 작품이 아니었던 것이다.

필자는 대학 때까지 열심히 프로그래밍 기술을 익히고 기술 공부에 매진했다. 그러다가 지금의 SI 업체에 입사하게 되었는데, 그때 인사과장님이 하시던 말씀이 생각난다. “앞으로 여러분은 회사에 들어가서 열심히 업무를 배워야 합니다. 기술도 중요하지만 앞으로 하게 될 회사 업무(인사, 구매, 회계, 생산, 영업 등)를 파악하는 것이 더 중요합니다. 고객이 원하는 것을 알아야만 개발도 효과적으로 할 수 있기 때문입니다.” 그동안 기술 공부만 열심히 해왔던 필자에게는 충격적인 말이었다. 내가 지금껏 ‘헛공부’를 했단 말인가?

개발자로서 선택할 수 있는 다양한 진로가 존재한다. 대표적인 것이 바로 IT 제조업과 IT 서비스업이다. IT 제조업은 제품을 만드는 것이므로 기술 자체가 중요할지 모르겠다. 하지만 IT 서비스업은 서비스를 만드는 것이므로 그 해당 업무를 잘 아는 것이 더 중요했던 것이다.

필자는 회사에 들어가서 제일 먼저 회계 업무를 맡았다. 개발하는 것 자체에는 아무런 문제가 없었지만 현업이 요구하는 것을 개발하는 데 문제가 생겼다. 회계 업무를 모르다 보니 현업이 하는 말을 알아들을 수 없었고, 현업이 원하는 바를 이해해서 원하는 것을 정확하게 만들 수 없었다. 이때부터 회계 공부를 시작했다. 당장 회계학과 대학생들이 본다는 『회계원리』라는 책을 사서 공부를 시작했다. 하지만 처음부터 회계용어가 눈에 들어올 리가 없었다. 난생 처음 듣는 어려운 용어가 많았다. 그때마다 회계과 직원들의 도움을 받고, 스스로 다른 책도 찾아가면서 회계 공부를 했다.

처음에는 어렵기만 했던 회계 용어가 차츰 눈에 익고, 점점 업무 영역도 확대되어 갔다. 회계, 그룹웨어, 인사 등 여러 업무를 조금씩 하다가 이제는 직접 개발하기보다는 관리, 기획하는 업무의 비중이 점점 늘어가는 것을 느끼게 되었다. 바야흐로 개발자로서 선택의 갈림길이 나타난 것이다. 계속 개발자로 남느냐? 아니면 관리직으로 가느냐?

한국에서 개발자로 살아가기

개발자로 살아가다 보면 국내에서는 개발자로 살아가기가 힘들다는 소리를 여기저기서 많이 듣게 된다. 지난해 8월 자바개발자협의회(JCO)는 한국의 개발자 1,891명을 대상으로 설문 조사를 실시한 바 있다. 그 결과에 따르면 국내 소프트웨어 개발자의 72.2%는 45세까지(특히 58%는 40세까지)만 개발 업무를 계속하겠다고 응답했다. 대다수가 개발자의 수명을 40세 초반으로 바라보고 있는 셈이다. 경력 분포 면에서는 10년 이상된 개발자가 전체의 9.5% 밖에 되지 않아서 대부분이 경력이 짧은 초중급 개발자로 이뤄져 있음을 알 수 있다. 그만큼 숙련된 개발자가 부족하다는 의미이다.

개발자의 근무 실태를 보면, 응답자의 85%는 주2회 이상 야근을 하며 매일 야근하는 개발자도 28%나 되었다. 하지만 이들에게는 초과 근무 수당이 없는 경우가 대다수였다. 한 예로 노동부에서 2007년 6월부터 서울 지역 IT 업체 104곳을 점검한 결과, 93개 업체가 근로자의 수당을 미지급해서 시정 명령을 받았다고 한다. 

과거 2005년도에는 포털 서비스인 다음의 토론광장(아고라)에 ‘영재들아, 제발 IT로 오지마라’라는 글이 게재되어 한창 화제가 되기도 했다. 이 글은 한국 IT 개발 환경의 문제점을 적나라하게 표현해서 IT 종사자들 사이에서 대단한 관심을 끌었다. 이런 우울한 글을 보고 나면 정말 개발자로 남아서 살아가야 하는지 자신이 없다. 유독 한국의 개발자만 이렇게 고생하는 것은 아닐까?

임금 수준으로 본 우리 IT

이럴 때에는 선진국의 사례를 살펴보면 도움이 된다. 필자는 우리나라보다 IT 산업이 성숙한 미국의 자료를 찾아보기로 했다. PayScale이라는 연봉 정보 공개 사이트에는 각 직업의 연봉 정보가 공개되어 있다. 먼저 미국의 연봉 정보를 보자.

clip_image001
<화면 1>에서 뜻밖에도 고급 개발자(Sr. Software Engineer / Developer / Programmer)의 연봉이 최고 수준으로 나와 있음을 볼 수 있다. 이 사이트에는 한국의 연봉 정보도 함께 소개되어 있다. 비록 등록된 정보가 얼마 없어 절대적인 기준으로 삼기는 어렵지만 그냥 참고용으로는 볼만 하다. <화면 2>는 한국의 연봉 정보를 나타낸 그래프다.

clip_image002
이 자료에는 구체적인 수치가 나와 있진 않지만, 개발자의 임금 수준이 꽤 낮은 수준임을 짐작할 수 있다. 한국소프트웨어진흥원에서 한미일 3국의 소프트웨어 개발자 월평균 임금(2003년 기준)을 조사한 자료가 있는데 그 결과는 <표 1>과 같다.

clip_image003

<표 1>은 해당 국가의 물가를 고려하지 않고 임금을 단순 비교한 자료이므로 이것으로 절대적인 비교는 어렵지만 대략적으로 보면 미국의 임금이 한국의 3배에 이른다. 단순 절대 임금의 비교보다는 상대적 임금 수준을 비교하기 위해 임금 프리미엄이라는 지수를 사용한다. 임금 프리미엄이란 현재 임금에서 기회 임금을 뺀 것으로 그 직업의 상대적인 임금 수준을 측정할 때 유용하다. 즉, 내가 IT 직업을 가짐으로써 다른 직업을 가졌을 때보다 더 많이 받는 수준이 임금 프리미엄이다.

정보통신정책연구원에서 2003년도 발간된 자료를 보면 한국 IT 산업 근로자의 임금 프리미엄은 10%, IT 직종 종사자의 임금 프리미엄은 IT 전문직이 61%, 준 전문직이 11%, 생산직이 3%였다. 반면에 미국 IT 산업 종사자의 임금 프리미엄은 110.8%로 나와 있다. 즉, 미국에 비해서는 그만큼 한국의 IT 직종 종사자가 상대적으로 임금을 덜 받고 있음을 알 수 있다.

근로 환경은 어떤가?
ww.esj.com이라는 사이트에 가보면 미국 IT 종사자에 대한 설문조사 결과를 볼 수 있다. 가장 최근의 자료는 2007년 10월에 조사한 것으로, 이 가운데 먼저 직업 만족도를 보면 <표 2>와 같다.
clip_image004

미국의 IT 종사자들은 갈수록 직업 만족도가 떨어지기는 하지만 대체적으로 직업에 만족하고 있음을 알 수 있다. 그럼 이번에는 직업 안정성에 대해 알아보자. 이는 자신의 직장에서 퇴직 당하지 않고 얼마나 안정적으로 일할 수 있는지에 대한 설문조사 결과이다.
clip_image005

<표 3>을 보면 대체적으로 직업 안정성이 높음을 알 수 있다. 마지막으로 주당 근무 시간에 대한 설문 조사 결과는 <표 4>와 같다. 
clip_image006

아무래도 직원보다는 관리자가 더 업무를 오래하는 편인데, 직원들의 주당 근무 시간은 평균 43시간으로 조사됐다. 9시 출근 6시 퇴근이라 하고 점심시간 1시간을 제외하면 일일 근무시간은 8시간이다. 이는 주5일제라고 할 때 주당 40시간이 된다. 미국에서 43시간이라는 것은 결국 어느 정도 야근을 한다는 것을 의미한다.

그럼 우리나라의 경우는 어떨까? 2004년 전국IT산업노동조합연맹이 실시한 실태조사에서 소프트웨어 종사자들의 주당 평균 근로시간은 57.8시간이었다. 이는 미국과 비교해 보면 많은 차이를 나타내는 결과다. 결국 한국에서 개발자로 살아가는 것이 힘들다고 말하는 데에는 이런 이유가 있는 셈이다.

산업 분류에 따른 IT 전망

|앞서 말한 바와 같이 IT 산업은 크게 IT 제조업과 IT 서비스업으로 나눌 수 있다. 이중 우리나라는 IT 제조업의 비중이 매우 높은 편이다. <표 5>는 2005년도 IT 부문별 부가가치 및 고용 비중을 나타낸 것이다.

clip_image007

한편 미국의 경우는 <표 6>과 같다.

clip_image008

미국의 경우 IT 서비스업의 부가가치가 더 크고 인력도 더 많은 것으로 조사됐다. 하지만 우리나라의 경우에는 IT 제조업의 부가가치가 더 크고 인력도 더 많은 것으로 나타났다. 우리나라는 아직까지 IT 산업에 있어서 제조업의 비중이 더 크다는 의미다.

미국의 경우 IT 서비스업의 부가가치나 인력이 더 많은 것은 서비스 부문에서 IT를 활용한 전산화가 생산성 향상을 가져왔기 때문이다. 미국도 1995년 이전에는 제조업의 생산성이 서비스업보다 더 높았다. 하지만 IT 기술이 발전한 1995년 이후에는 IT 기술을 활용한 서비스 분야의 전산화를 통해서 생산성이 크게 향상됐다.

clip_image009

반면에 우리나라의 경우 2000년대 들어 IT 생산 부문은 노동생산성 향상에 크게 기여하고 있으나, IT 이용 서비스의 경우에는 오히려 기여도가 하락하고 있다.

<그림 1>을 보면 우리나라는 생산성을 높이는 데 있어 IT 이용 서비스업의 기여도가 떨어지고 그 비중 또한 작다. IT 제조업의 경우 각종 IT 제품을 통해서 생산성 향상을 가져오는데 반해, IT 서비스업의 경우는 소프트웨어를 통해 업무의 효율화를 가져와야 하는데 그 비중이 작다는 것이다.

우리 개발자의 미래

과거 미국의 경제가 일본에 추월당했다는 소리가 있었지만 미국은 IT를 통한 기술 발전에 힘입어 생산성의 향상을 가져왔고 다시금 경제에 활력을 되찾았다. IT 산업이 경제 성장의 밑거름이 된 것이다. 특히 IT 서비스업의 경우 IT 제조업보다 더 큰 부가가치와 고용 증대 효과를 가져왔다.

clip_image010

앞으로 우리나라도 경제가 더욱 성장하기 위해서는 미국이 그랬던 것처럼 각 산업에서의 생산성 증가가 이뤄져야 한다. 이러한 생산성 증대는 앞으로는 IT 기술을 통해 이뤄질 것이다. 특히 그동안 등한시되었던 IT 서비스를 통한 서비스업의 생산성 증가가 앞으로 중요한 이슈가 될 것이다. 이에 따라 IT 서비스업을 담당하는 소프트웨어 개발자가 앞으로는 더욱 많이 필요해지고 중요한 인력이 될 것으로 보인다.

앞서 살펴본 것처럼 우리나라에서 개발자에 대한 처우는 미국에 비해 그리 좋은 상황은 아니다. 하지만 앞으로 우리가 미국의 모델을 따라 IT 빅뱅을 통한 경제발전을 이룩한다면 소프트웨어 개발자는 그 주요한 원동력이 될 것이다. 필자는 그때쯤이면 우리나라의 개발자도 미국의 그들처럼 대우받지 않을까라는 나름대로 긍정적인 희망을 가져본다.

참고 자료

1. 자바개발자협의회 커뮤니티, http://www.jco.or.kr
2. 미국 연봉 정보 사이트, http://www.payscale.com
3. SW인력 임금수준의 국제 비교 - 한국소프트웨어진흥원(박능윤), http://www.software.or.kr
4. IT 인력의 취업률, 전공종사율, 임금수준에 대한 연구 - 정보통신정책연구원, http://www.kisdi.re.kr
5. Enterprise System, http://www.esj.com
6. 주력성장산업으로서 IT 산업에 대한 평가와 시사점 - 한국은행, http://www.bok.or.kr

성공적인 CRM을 위한 레시피

Source : http://www.zdnet.co.kr/itbiz/reports/trend/0,39034651,39167780,00.htm

 

이 글을 보시는 여러분들 중에 CRM라는 단어의 의미를 모르시는 분들은 없으리라 생각이 듭니다.
본 칼럼에서는 CRM과 관련된 기본적인 이론부터 접근해서 실행과 관련된 이슈들을 소개하는 자리를 마련해 보려고 합니다.
특별히 데이터를 중심으로 편성된 eCRM(웹 로그 포함) 분야로 제한하고 말씀드리지는 않겠습니다.
다만 정리된 내용들의 기반은 데이터를 분석하고 해석하는 부분이 많기 때문에 온라인과 관련된 내용이 많다는 점은 분명히 밝혀둡니다. 적어도 설명을 드릴 때 자료의 논리성을 확보하려면 저 역시 데이터에 기반한 논리가 필요하기 때문입니다.
자, 시작해 볼까요?
수익의 극대화라는 절대명제를 가진 기업에서는 궁극적으로 아래의 CRM 구조를 잘 만드는 것이 목표입니다.

clip_image001

오래된 자료이긴 합니다만, CRM의 대부분을 설명할 수 있는 그림 한 장을 뽑으라면 저는 이 그림을 추천해 드립니다.
(1번) 고객상호 작용
(2번) 고객식별
(3번) 고객접근 기록
(4번) (고객에게)적당한 오퍼(보상, 서비스) 결정
(5번) 오퍼(보상, 서비스) 실행
1번부터 3번까지를 ‘고객인지’ 부분이고, 4번부터 5번까지는 ‘고객응대’라고 보셔도 될 것 같습니다. 1번부터 5번까지의 모든 프로세스를 디지털화하여 운영하고 있는 기업도 있고, 직접 손님을 맞이하여 서비스를 제공하고 보내는 아날로그 기업도 있습니다. 또는 일부는 디지털, 나머지는 아날로그 등등 어떠한 형태로든 설명이 가능합니다.
문제는 여기서부터 시작이고 각 단계에서 얼마만큼 효율적으로 대응하는 하는가를 한번쯤 고민해 봐야 할 대목입니다.
Case1) 우리 식당에서는 고객이 방문도 많고 인사도 잘하는데(1번 고객상호작용) 단골 손님들은 없는 거 같네(4, 5번 고객 보상이나 서비스)?
Case2) 우리 웹 사이트 방문자수(3번 고객접근기록)는 감소하는 것 같은데 매출은 그대로네? 사이트 방문이 느는 것 하고 구매 고객(2번 고객식별)의 매출하고는 아무 상관없나 보다.
Case3) 월 매출이 성장해서 기분은 좋은데 이유가 뭐지?
다음으로 생각해 볼 것은 위의 그림에서 효율성 극대를 위해서 문제점을 적극적으로 해결할 수 있는 방안을 모색해야 하고 더 나아서는 각 단계별 처리 속도(고객대응)와 적재적소에서의 리소스 활용이 필요합니다. @

2. 고객알기
숨 고르기, CRM 알고 가자
기업에서의 CRM은 활동은 지난번 소개 드렸던 그림과 같이 순환구조(Closed-Loop)로 이해하셔야 하고, 순환구조의 개선이나 각 단계별로 병목현상이 발생하지 않게 하는 게 가장 중요하다고 볼 수 있겠습니다.
이번 시간의 주제는 “고객알기”입니다.
많은 기업들이 고객에 대한 정보를 획득(Acquisition)하기 위하여 노력하고 있습니다. 하지만 어디서부터 손을 대야 할지, 또는 고객과 관련된 데이터 너무 복잡하거나 많거나 하는 이유로 실제 고객과 관련된 정보에 안테나를 세우고 분석하는 업무담당자는 많지 않은 것 같습니다.
더욱이 오늘날 고객과 관련된 정보는 내부에도 있고 외부에도 많이 존재합니다. 컨설팅 업무를 진행하다 보면 랭키닷컴에 데이터로 이용자들이 경쟁사와 자사를 중복 방문하는 숫자가 점차 증가되고 있는 것을 보아도 쉽게 예측이 가능한 부분입니다.

clip_image001[4]

위 표의 왼쪽은 자사 내부에서 관리 하고 있는 정보들입니다. 인구통계학 정보는 기본적으로 사이트에 가입하는 시점에서 기본적으로 획득 가능한 정보이며, 이용행태와 고객성향정보는 웹 로그 분석이나 내부 운영정보에 Transaction(거래발생시 기록되는 정보)로 기록관리가 됩니다.
고객 등급 정보는 기업에 따라서 있는 경우도 있고 부분적으로 있는 경우도 있습니다. 마지막으로 고객 불만사항 정보는 Call Center나 ARS 또는 내부 Q&A를 통해 접수되는 정보들이 되겠습니다.
우측은 외부 고객 정보입니다. 기업에서 외부정보의 중요성은 점차 증대되어 가고 상황이며, 외부 고객 정보를 얻기 위해 다양한 리서치나 컨설팅, 그리고 최근에는 RSS를 통한 커뮤니티정보 획득과 커뮤니티 정보를 얻기 위한 솔루션까지 등장하고 있는 상황입니다.
이 시점에서 귀사의 고객정보들이 현재 파편정보로 획득되고 있지는 않은지, 혹은 이질적인 정보들로 인한 혼선이 생기지 않는지 판단해야 합니다.
좀더 심화하여 고객을 깊게 이해하기 위한 방법 몇 가지를 정리해 보았습니다.
첫째, 내부자료 검토
‘등잔 밑이 어둡다’는 말처럼 지금도 고객사에 방문하여 보면 내부에 엄청난 자료들이 있습니다. 특히 매출과 관련된 자료들은 다양한 분석을 하여 보고서로 활용하고 있습니다. 여기서 말하는 내부자료 검토란, 현재 매출과 상품위주로 구성된 보고서의 내용을 고객과 연결시켜 재검토 하자는 의미입니다.
예를 들어 ‘2007년 11월 A상품이 전월 대비 23% 증가하여 매출의 주요 점유율을 차지하였다.’ 라는 관점에서 ‘A상품은 신규고객의 매출 비중이 높음 상품’ 등의 고객과 관련된 정보를 함께 정리하는 방식입니다. 고객에 관련된 정보를 수록하는 것은 대상 고객층에 대한 마케팅 기획이나 대응논리를 전개해 나갈 수 있는 중요한 논리가 되기 때문입니다.
둘째, 원천 데이터를 분석해 보자
원론적인 이야기가 될 수도 있겠지만 고객의 가치를 산정하는 방식 중에 RFM(Recency, Frequency, Monetary) 방식이 있습니다. 고객 한 명에 대해 매출이 일어나는 시점을 기준으로 하여 최근성, 빈도, 금액의 가중 점수를 부과하여 고객의 점수를 산정하는 방식입니다.
RFM의 점수가 높다는 것은 자주 구매하거나 많은 매출을 발생시키거나 최근에 해당 상품을 인지하는 것을 의미합니다. 물론 기업들은 이러한 방식을 그대로 적용하지는 않습니다. 적용해야 될 변수들이 늘어났고, 이러한 측정치 만으로는 고객을 이해하는 것이 쉽지 않기 때문입니다.
그러나, 저는 이러한 데이터를 분석해 볼 것을 권합니다. 실제 데이터 가지고 분석을 하게 되면 고객에 대한 R/F/M 등과 같은 측정정보들에 대한 분포를 이해 하 실 수 있습니다. 고객들의 평균 객단가 수준이나 방문빈도 정보는 마케팅 기획업무를 하시는데 유용한 정보로 활용이 가능하고 이러한 측정지표를 가지고 응용하여 고객 세분화에 적용 하는 것이 가능합니다.
셋째, 외부 데이터 이용
고객 알기와 관련된 외부 데이터 이용에서는 일단 자사 이외에 고객의 프로파일 정보를 취득이 불가능 합니다. 다만, 고객들의 이용행태와 관련된 정보와 산업적인 특성 정보는 획득 가능한 정보입니다.
현재 랭키닷컴(rankey.com)에서는 기업에서 필요한 다양한 정보들을 제공하고 있습니다.
랭키통계 정보, 사이트 집중분석, 순위동향, 랭키순위 정보는 언제든지 열람이 가능한 형태로 제공되는 정보입니다. 보다 심도 있게 경쟁사와의 비교분석을 원하실 경우는 Insight2(ASP형태의 고급 데이터 제공 서비스)와 컨설팅 서비스(정량/정성분석 등)로 이용이 가능합니다.
넷째, 고객정보의 뷰(View) 작성
구슬도 꿰야 보배가 되듯이 고객과 관련된 정보 역시 정리가 필요합니다.
아래 그림은 고객을 중심으로 한 데이터의 관점을 정리한 것입니다.

clip_image002

크게 4가지 주제로 고객과 프로모션, 고객과 가치, 고객과 트래픽, 고객과 거래 나눌 수 있으며, 보고서를 작성하거나 내부 리포트를 만드실 경우에 참조로 활용 하시기 바랍니다.
* 프로모션
- 구매 프로세스 이탈고객을 이메일 프로모션 대상 고객으로 활용
- 프로모션의 효율적 의사결정을 위한 분석(프로모션 ROI) 가치
- 기본 관리 항목 도출(기본/구매/회원등급)
관리 포인트 도출(이벤트 효과에 대한 효율분석, 카테고리 연관구매, 반복구매주기 분석, 등급유지 상승을 위한 CSF분석, 회원 프로모션 기획 시 반영)
* 트래픽
- 프로모션 기간 동안 외부 유입경로(배너, 등록기타, 이메일, 직접접속)별 방문과 아이템 매출 연계정보
이벤트 별 방문자가 어떤 외부 유입 경로/서비스로 접근하였는지에 대한 시간적 분석(이벤트 참여자의 구매효과)
- 온라인 활동성과 구매 기여도 측정
- 컨텐츠에 대한 개별 기호도 및 접근경로
* 거래
- 일자 별 매출종합 정보 분석 / 방문한 이용자 매출정보에 대한 분석 @

3. 고객모델 만들기
지금까지 ‘고객알기’를 주제로 해서 내부의 고객정보와 외부의 고객정보에 대한 설명과 고객을 알아가기 위한 방법 네 가지를 설명 드렸습니다.
오늘 이야기 나눌 부분은 ‘고객모델’입니다. 고객모델은 고객의 구매와 온라인의 이용패턴과 관련된 행위 정보를 기반으로 고객을 세분화 하거나 이용등급을 나누는 것을 의미합니다.
가장 궁극적으로 고객의 모델을 만드는 이유는 고객에 대한 전략적 가치 판단의 기준을 찾기 위해서 입니다.
통신사나 금융기관에서는 고객의 정보를 잘 세분화하여 고객들의 프로파일을 관리하고 있습니다. 고객에게 알맞은 요금제도의 설계나 포인트의 사용 정보를 잘 분석하여 고객에 입맛에 맞는 상품들을 추천하기까지 하는 것은 고객들의 모델을 전략적으로 잘 활용하고 있음을 보여주는 예입니다.
만약 기업을 방문하는 고객 전부에게 똑같은 형식의 보상을 주는 방식을 사용하고 계시다면 그것은 고객에 대한 기초적인 분석 활동이 이루어 지지 못했음을 의미하는 것이고, 향후 고객에 대한 전략이 없는 것을 말합니다.

clip_image001[6]

이 같은 고객모델의 구성은 어떻게 할 것인가?
지금 추천해 드리는 방식은 RFM(R : Recency, F : Frequency, M : Monetary)의 고객 가치(CE : Customer Equity)모델과 고객의 생애가치LTV(Life Time Value, 고객생애의 가치 = 거래횟수 X 고객의 잠재수익성 X 고객의 거래 기간)모델을 적절히 배분하여 구성하는 방식입니다. 이는 사업의 성격에 따라 조금씩 상이해 질 수 있는 모델이며, 필요에 의해서는 다양한 구매의 패턴정보도 함께 구성한다면 더욱 고객사에 알맞은 고객 모델이 구성될 것 입니다.
고객모델의 구성은 가장 먼저 고객의 측정 데이터(R/F/M/L)들을 산출하여야 합니다(1). 적어도 6개월에서 1년 전의 고객들의 구매나 온라인의 이용행태에 대한 측정 데이터 기초통계정보를 활용하여 분포도를 확인해 봐야 합니다.
예를 들어 구매빈도(F : Frequency)의 데이터 통계 구성이 1과 4에 집중적으로 구성되어 있다고 한다면 구매빈도의 기준을 1과 4로 각각 잡아서 상-중-하로 구성하는 것도 하나의 고객의 등급 속성별로 구분하는 방식이 될 것입니다.
다른 측정데이터를 모두 분석하여 통계적 기준이나 합의에 의한 기준점을 찾은 이후에는 고객의 데이터 측정값의 기준으로 고객들을 나누어 보는 것입니다(2).
이렇게 하여 나뉘어진 고객의 등급별 정보는 등급별 속성정보로서의 의미와 전략적인 측면에서의 세분화된 정보가 됩니다(3). 여기서 중요한 것은 나누어진 고객의 등급별 속성정보를 지속적으로 관리하고 피드백 해봐야 한다는 것입니다(4). 기준에 의하여 나누어진 고객등급의 고객들이 필요에 의하여 좀더 세분화 될 수도 있고, 비슷한 속성등급으로 병합을 시켜야 할 경우도 필요하기 때문입니다.
장기적으로는 고객모델의 구성 이후에 주간이나 월간 분석자료에 등급별 이용현황(매출, 상품 등의 활동)을 추가로 분석하여 보다 전략적인 측면에서의 고객모델 활용을 만드는 것이 가장 중요합니다. @

SVC, Tortoise SVN, 소스세이프(Source Safe)를 활용한 로그보기, 업데이트된 곳 찾기, Diff

Source : http://a.tk.co.kr/409

 

개요..

프로그램 개발에서 소스 관리는 매일 강조해도 지나치지 않습니다.

때문에 대부분의 개발자들은 SVC, Tortoise SVN, 소스세이프(Source Safe)등을 활용하여 소스를 관리하는데, 팀 단위 개발은 물론이고 나 홀로 개발일지라도 소스관리 프로그램을 사용하는 것이 안전을 위해서나, 복구, 수정, 확인을 위해서 매우 편리하고 중요한 역할을 합니다.

이번에는 Tortoise SVN 을 활용하여 로그보기, 업데이트된 곳 찾기, Diff등을 활용해봅니다.

로그 보기

다음과 같은 방법으로 SVN 로그 보기를 하면 업데이트된 날짜와 사람, 수정되거나 추가, 삭제된 항목이 화면이 나타납니다.

clip_image001

clip_image003

바뀐점 보기

바뀐점 보기를 사용하면 프로그램 소스코드에서 수정, 삭제, 추가된 부분을 검사할 수 있습니다.

clip_image004

clip_image006

게임 개발자의 자질 [ 프로그래머 편 ]

  프로그래머의 경우는 그냥 컴퓨터라는 것을 잘하면 된다라고 착각하는 경우가 많습니다. 실제로 게임 프로그래머 지망생이나, 게임 프로그래머라고 뽑히는 사람들을 보면, 그런 사람들이 많습니다.

  하지만, 프로그래머라면 반드시 잘 해야 하는 학교 과목이 있습니다. 수학과 물리입니다. 의외일지 모르지만, 사실입니다.

  컴퓨터가 일반적으로 할 수 있는 일, 계산, 문서작업, 음악, 영화플레이, 게임, 그림보기, 인터넷, …  이것은 컴퓨터가 음악을 이해하고, 색깔을 이해해서 할 수 있는 것이 아닙니다. 전부가 숫자를 이용해 그것을 처리하는 것입니다.

  컴퓨터가 아는 것은 10진수도 아닌 2진수입니다. 즉, 1과 0을 조합한 복잡한 숫자( 000101, 0001011101 등 )를 이용해서, 어디로 옮기고, 어떻게 계산하고, 등의 작업을 통해, 모든 일을 합니다.

  예로, 스타크래프트의 적의 움직임 인공지능 역시도 숫자를 이용합니다. 적의 위치가 x, y좌표 어디에 있는가, 거기까지 가는 동안에 장애물이 있는 좌표는 어디고, 그 좌표를 피해서 거기까지 가려면, 어떤 좌표를 지나가야 하는가? 적이 얼마나 가까이에 있는가? 가까이에 있으면, 어떤 공격력으로 공격할 것인가? ( 전부 숫자입니다. )

  음악도 마찬가지입니다. 모든 음을 숫자로 나타내는 겁니다. 간단히 가정을 하면, 도는 0, 레는 1, 미는 2, 파는 3, … 등으로 만들고, 그걸 사운드카드가 플레이 하기 위해 명령어( 이것도 숫자 )를 보내고, 그리고, 사운드카드가 원하는 메모리 공간에 음을 연주할 숫자를 넣어주면 됩니다.

  그림도 음악과 마찬가지입니다.

  3차원 그래픽은 진짜 수학 천지입니다. 기본적으로 행렬부터, Sin, Cos, … 만약 물체의 움직임을 리얼하게 표현하겠다 싶으면 물리의 공식이 잔뜩 들어갑니다. 레이싱 게임의 경우, 물체와 바닥사이의 마찰계수, 가속, 미끄러짐, … 심지어, 비가 오는 날의 마찰력, 가속, 미끄러짐 모두 프로그래머가 계산해야 하는 것 천지입니다. ( 기획자나 그래픽 디자이너가 해줄 수 있는 문제는 절대 아닙니다. )

  조금 구체적으로 이야길 해보죠.

  수학은 크게, 문제 분석력, 문제 해결능력, 공식 조합능력, … 등 을 요구한다고 합니다. 이 모든 것이 사실 수학에서 지겹게 하는 겁니다. 어떤 특정한 문제가 있을 때, 그것을 분석하고, 그걸 해결하기 위해 필요한 공식들을 찾고, 그 공식을 이용해 조합하고, 마지막으로 문제를 종합적으로 해결하는 능력입니다.

  또한 버그가 발생했을 때, 찾아가는 순서도, 수학에서 사용하는 검산과 똑같은 방식을 사용합니다. ( 다시 풀기, 대입법, … )

  간단한 프로그램은 수학을 못해도 할 수 있습니다. 하지만, 앞으로 갈수록 게임은 간단한 프로그래밍 기술로는 불가능합니다. 특히, 간단한 모바일 게임의 경우 누구나 할 수 있는 프로그램이라고 착각하고 한 때, 그렇게 프로그램을 했었지만, 점점, 복잡한 기술과 이론을 사용하기 때문에, 점점 더 수학을 잘 하는 사람을 필요로 할 겁니다.

  수학 못하는 사람 중에 게임 프로그래머로 잘 나가는사람이 있던데요. 그 사람은 크게 3가지 중 하나 입니다. 학교 공부에 적응하지 못해, 수학을 일부러 공부 안한 천재 또는 게임 프로그래머지만 복잡한 프로그램이 아닌 작은 게임이나 알고리즘만 만든 사람 아니면, 말만 그럴듯한 허풍쟁이.

  그 외에 C언어를 완벽히 활용할 수 있을 정도의 능력. ( 다른 자바나 베이직, 플레쉬로도 게임을 만들 수 있지만, 분명히 한계가 있습니다. C#이 차세대 언어가 될 거라는 소리가 있었지만, 역시나 향후 5년 동안도 C언어로 게임을 제작하는 것이 주류가 될 겁니다. 왜냐면, 어셈블리나 기계어와 똑같은 속도를 구현할 수 있는 최적화가 되어 있기 때문입니다.

[ 에이 그럼 느린 게임만 만들면 되지. ]

라고 말하고 싶은 사람도 있을지 모르겠지만, 그럴려면 차라리 빠르게 게임 만들어서 거기에 화면 효과나 다양한 시각효과를 하나라도 더 주자가 게임의 흐름입니다. 단순히 게임만 되는 게임과 스코어나 미니맵 그리고, 타격에 효과처리가 되어 있는 게임은 차원이 다릅니다.

  그리고 영어. 프로그래밍 최신 기술은 영어로 먼저 나옵니다. 알고리즘이나 하드웨어 개발시 프로그래밍 방법은 모두 영어로 먼저 나오기 때문에 빠른 기술 습득에 영어를 잘 하는 것이 좋습니다만, 저는 영어를 못하고도 프로그램을 했었습니다. ( 프로그래밍하면서 영어 잘하는 사람들이 부러웠답니다. )

  또 완벽주의자의 경향이 있어야 합니다. 이것은 게임 개발자의 공통된 자질에서 설명하려고 했습니다만, 여기서 언급하는 이유는 다른 분야 사람들보다 프로그래머는 가장 완벽주의자여야 하기 때문입니다. 완벽하지 못하면, 생기는 문제가 첫째 버그, 둘째 버그, 셋째, 버그, 넷째, 일정 차질입니다.

  첫째부터 셋째가지 버그라고 말장난 한 이유는, 버그가 프로그래머들의 최대 적입니다. 그리고 완벽하게 프로그래밍을 하지 못하면, 항상 생기는 것이 버그기 때문입니다. 일반 업무용 프로그램처럼 [ 판매 후에 패치하지 뭐. ] 이런 생각이라면, 게임을 말아먹겠다는 뜻입니다. 소프트맥스의 [ 마그나카르타 ]사건의 예를 보더라도, 버그가 얼마나 게임에 대한 흥미를 떨어뜨리고, 회사에 얼마나 심한 타격을 주는지 알 수 있습니다.

  C언어를 못하면 배우면 됩니다. 영어 못하면, 국내에 알려진 기술이나, 영어 잘 하는 사람의 도움을 받으면 됩니다. 수학 못하면, 작은 게임만 개발하던가, 보조 프로그래머로만 일하면 됩니다. 하지만, 완벽하게 만들려고 하지 못하는 사람은 게임 개발에 전혀 도움이 안됩니다. 오히려, 개발과 일정에 방해만 됩니다.

  마지막으로 게임 프로그래머로 성공하고 싶으시다면, 수학부터 완벽히 공부하십시오. 완벽히