2009.11.18 23:25

바른 생활

주저리 2009.11.18 23:25

이라고 부르는 우리의 보통 일상은 아슬아슬하기 짝이없다.

가끔 어떤 인간의 일생을 그리는 영화 중 한 순간의 잘못된(일반적으로 생각하기에..) 선택으로 다시는 보통 일상으로 돌아올 수 없는 그런 영화를 보고나면 왠지 가슴 저 밑에 있는 짜증이 한번에 올라오는 듯 하다. 특히 로드무비같은 장르에서 흔히 볼 수 있는 그런 것들..

한 순간의 실수로 살인을 해서 인생 망가지거나 ... 도박(주식도 포함...)으로 재산 탕진하고 마는 (주인공이 이걸로 끝나버리면 허무하긴 하지. 보통은 주인공 주변인물들이...  ^^;) 그런 영화들..

그런데 중간 과정은 그러했는데 결말은 코믹하거나 아무렇지도 않은 듯 뻔뻔스럽게 일상으로 돌아가는 영화들이 종종 있다. 어쨌든 주인공이 정상으로 돌아가던 말던 내 기분은 더 찜찜해지기도 한다.

이번에 그런 영화를 봤는데... '마더'.

휴가중에 그래도 영화 하나는 봐야 겠다는 신념으로 아기가 자는 시간에 가슴 조마조마하면 봤는데 하필 이런 류의 영화일 줄이야.. ㅠ-ㅜ

된장.... 깔끔한 기분으로 휴가 마치고 싶었는데.. ㅜ-ㅡ

'주저리' 카테고리의 다른 글

응???  (0) 2011.07.03
포카리스웨트 분말 득!!  (0) 2011.06.22
바른 생활  (0) 2009.11.18
9월의 마지막 날  (0) 2009.09.30
코드를 공유한다는 것!  (0) 2009.09.29
일정을 잘 지키는 것  (0) 2009.08.28
2009.10.20 07:21
커뮤니티에 올렸던걸 그래로 옮깁니다. ~ ^^

========================================================

드디어 마지막까지 다 보았습니다. 반전이랄까요. 스포일러가 될지도 모르겠지만.. 그리고 결과로 봤을 때는 다행인지도 모르겠지만...

 

이 글은 2005년 말에서 종료되었지만 챈들러 프로젝트는 계속 진행되었더군요.

 

2009년 10월 현재 제 PC에는 1.0.3버젼이 설치되어 있습니다. (http://chandlerproject.org/ 에서 최신 내용을 확인하실 수 있습니다.)

 

굳이 '읽으면서'로 적고나서 '읽고나서'로 제목을 바꾸어 내용을 덧붙이는 것은 지난번 아래 글을 적을 때 좀 더 저의 감상이 들어가지 못한것이 아쉬워 글을 추가해 봅니다.

 

개인적으로 개론과 관련된  책들은 책상 깊숙히 ... 혹은 사회 환원의 핑계를 들어 재활용 시켜 버리곤 하는데..

 

이 책에 과거 지겹게만 느껴졌던 개발 방법론과 소프트웨어 개발의 역사에 대한 내용 일부분이 나와서 색다르게 느껴지기도 하더군요. 마치 저자가 그 역사의 현장에 같이 있는다는 느낌이 들 정도여서 상당히 새로웠습니다. 교수님들이 말할때는 그렇게나 지겹고 딱딱하게만 느껴지는데다가, 제발 시험에 안나왔으면 하는 "소프트웨어 개발 방법론의 종류를 나열하고 각각에 대한 내용을 나열하시오" 같은 문제들의 내용들이 이 책 중간 중간에 녹아 있으니 말입니다.

 

또 한가지는 그들이 중간 중간에 진행하며 나타나는 여러가지 문제점을 해쳐나가는 방법은 제가 볼 때 상당히 인상 깊었습니다. 알고는 있었지만 그들이 인력을 채용하는 과정에서 묘사된 내용을 보니 좀 더 확실히 느낌이 전달되네요. 이건 동양과 서양의 문화적 차이에서 나타나는 근본적인 문제이며 자주 접하는 내용이기도 한데..

 

동양( 한국, 일본  정도로 시야를 좁혀 보겠습니다. 다른 나라는 간접 경험 조차도 없어서요. ^^;)에서 어떤 프로젝트를 진행할 때 업무의 중요한 부분을 담당하는 인원을 "어느날 하늘에서 떨어진, 게다가 임원진들과 연결고리도 없는 사람을 중책에 임명한다"는 것은 일반적인 사회 통념상으로 생각해 볼 때 결코 쉽지 않은데 이들은 개인의 경력과 실력으로 당연한 듯이 중책을 맡기는 것이 놀라웠습니다. (둘 중 뭔가가 월등히 뛰어나다는 말은 아닙니다. 다 장단점이 있는 것이니까요. 그리고 우리에게도 이런 예가 없는건 아니죠. ^^a 마찬가지고 유럽 혹은 미국에서도 연줄에 의한 낙하산은 당연한 듯이 생각하고 있으니...;;)

 

또한 아마 오픈 소스 프로젝트에 이렇게 많은 비용과 시간을 투자한 회사가 그리 많지는 않겠지요. 게다가 2001년에 시작한 이 오픈소스 프로젝트가 지금까지 초기 목적과 프로젝트 개발 형태를 유지하고 있는 것에 놀랐습니다. 이 프로젝트를 주도하는 미치 케이퍼(로터스 1-2-3의 창시자이자 모질라 재단 회장) 라는 인물을 더 알고 싶어 지네요. 그가 사업에 욕심이 있었다면 빌 케이츠의 부와 비슷한 규모를 가지고 있지 않았을까 생각됩니다.

 

미치 케이퍼씨의 중요한 장점 중 하나는 자신의 부족한 부분을 인정하고 다른 팀원들에게 양해를 구한다는 것입니다. 특히 그가 대단한 업적을 이룬 사람임에도 불구하고 챈들러 프로젝트가 파이썬으로 진행한 것을 꼬집은 파이썬 개발자 필립 J. 에비의 충고를 잘 받아들이는 대목에서는 대인으로서의 모습을 충분히 느낄 수 있었습니다. 이 대목을 보면서 뜨끔했는데 현재 프로젝트의 운영툴을 자바를 이용해서 C++처럼 사용하고 있거든요. ^^ 하지만 되돌릴 생각은 없습니다. 자바야말로 운영툴 제작에 있어서 제가 고민하던 여러가지 문제점들을 해결해 줄 좋은 도구라는걸 충분히 검토한 것이기 때문입니다.

 

그리고 지금 막 느낀 것 하나. 버젼 1.0.3임에도 불구하고 다운로드 받은 후 "Chandler Hub account" 를 만드는 웹페이지의 오류로 인해 아직 계정을 못 만들었다는 것!!!

 

 

이 외에도 소프트웨어 시간, 맨먼스 미신, 래고 가설 등등 .. 우리가 머리 속에서 되내이던 여러가지 이야기들이 이 책에 들어있습니다. 프로그래머라면 꼭 한 번 읽어보시기를 추천하며... 이만 줄이겠습니다. 행복한 저녁 되세요. ^^

 

===========================================

 

예.. 아직 다 읽지 못했습니다. 10월 들어오면서 읽기 시작했는데 .. 아직도 80여 페이지가 남아 있네요.

 

업무 시간과 여과 시간을 모두를 활용하면서 읽었는데 쉽지가 않네요. 집에 가면 아기를 돌봐야 해서 아마 하루에 한 30여페이지도 못 읽은 것 같습니다.

 

원래는 9월쯤 한번 책을 들었다가 ... "뭔 내용이여.. ~ 휙~!!" 그러고 회사 구석에 박아두었습니다.

 

그러다 10월 초에 다시 잡고.. "근성으로라도 한 섹션만 읽어보자" 라고 생각했었는데.. 지금에 와버렸네요.

 

어느 부분부터 이들의 프로젝트 진행에 대한 내용 일부가 저의 프로젝트와 겹치기도 하고 혹은 겨우 겨우 그들의 실수와 동일한 것들을 내가 비켜 갔구나 하는 생각들도 들더군요.

 

특히나 공감했던 부분인 "맨먼스 미신The Mythical Man-Month"에 대한 내용은 저의 신념을 더욱 확실히 해주었습니다. 이 책을 읽기 전까지 왜 그때(올해 초) 상황에서 인력을 더 투입할 경우 프로젝트가 후퇴할지에 대해서 논리적으로 설명할 자신이 없었습니다.

 

올해 초에 3D 메인과 엔진 프로그래머가 나가면서 프로젝트의 위기가 왔었는데 그때 팀장은 제게(저는 프로그램 파트장입니다.) 3D 프로그래머를 추가로 몇명 뽑을 것을 권유(적어도 제게는 강요로 들렸습니다.) 했었습니다. 하지만 그때는 그 두명이 나가면서 벌려둔 각종 버그와 정리되지 않은 엔진 코드들, 그리고 기존 인원들도 추스려야 했기 때문에 만약 신규 인원을 들일 경우에는 정말 저마저도 포기해야 하는 상황이었습니다. 그때는 오직 "최소한 기존 코드를 정리하고 일정을 바로 잡은 후에 받아들인다"라는 생각만으로 팀장의 압력을 버텨냈습니다. 이 책을 읽은 읽다보니 정말 아찔하더군요. 그때는 저마저도 "너무 진행이 더딘게 아닐까? 다른 파트의 인원들이 조급해하지 않을까?"라는 생각이었었는데 지금은 잘 진행되고 있어서 이 책을 보면서 이런 시간을 즐기고 있는게 아닌가 생각됩니다.

 

음.. 뭐랄까요? 맘속에서 '과연 내가 생각하는 이런 방법들이 정말 괜찮은걸까?" 같은 뭔가 손에 잡히지 않은 것들이 책을 읽은 후에 하나씩 확신을 가지는 느낌이랄까요?! 그리고 어떤 것은 "앗!! 나도 저랬는데.. 당장 고쳐야겠다." 하는 것들도 많았습니다.

 

사실 책 본문의 전개 방식은 상당히 맘에 안들었습니다. 마치 내가 원하는 시대로 갈 수 없는 타임머신을 탄 기분이 들게하는 내용 전개였습니다. 그래도 그걸 꾹 참고 마지막 장을 보기 직전에 와 있어서 정말 다행이라는 생각이 드네요.

 

올해는 정말 정신없이 하루하루가 지나가네요. 지금은 게임에 들어갈 트리거 시스템을 정리하고 있는데 이게 마무리 되면 정말 클라이언트와 3D 엔진쪽에는 절반만 발 담그고 나머지 절반은 서버로 돌아갈 수 있게 되었습니다. ^^

 

자... 결론은 그래서 이달의 Off 모임이 늦어졌습니다.  곧 오프모임 글 올리겠습니다.

 

연말이 오기전에 또 한번 모여야죠. ^^

 

즐거운 하루하루 되시고 10월 말에 뵙겠습니다. 오늘도 행복한 하루 되세요.

'게임 - 책 - 영화 - 음악' 카테고리의 다른 글

책 100권 읽기 - 2010년 7월  (0) 2011.06.17
책 100권 읽기 - 2010년 6월  (0) 2011.06.17
책 100권 읽기 - 2010년 5월  (0) 2011.06.17
책 100권 읽기 - 2010년 4월  (0) 2011.06.17
The Road (BOOK)  (0) 2010.01.19
"드리밍 인 코드"를 읽고나서...  (0) 2009.10.20
2009.10.16 08:52
VSI 상에서 기본적인 메모리 릭 찾기 방법은 아래와 같은 것이 있습니다.

_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

이 코드를 프로그램 시작 위치에 기록 한 후 메모리 릭이 발생하면 출력창에 아래 예와 비슷한 결과를 보실 수 있습니다. 

================================
{26734} normal block at 0x0433A1E0, 32 bytes long.
 Data: <                > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
{26733} normal block at 0x04338220, 28 bytes long.
 Data: <8Y              > 38 59 99 04 FF FF FF FF 00 00 00 00 00 00 00 00 
{26732} normal block at 0x0433A160, 64 bytes long.
 Data: <                > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
{26731} normal block at 0x0433A070, 176 bytes long.
 Data: <` 3     $ S   3 > 60 A1 33 04 00 00 00 00 24 8B 53 01 E0 A1 33 04 
e:\work\code\common\wtl_util\cwwdragdrop.h(706) : {26542} normal block at 0x04335EA8, 76 bytes long.
================================

그럼 위 텍스트 중  {26542} 라는 숫자를 

_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );아래 위치 정도에 _CrtSetBreakAlloc(26542); 라고 적도 다시 빌드하여 실행하시면 해당 위치에서 브레이크가 거립니다. 


그리고 유명한 릭 찾기 라이브러리 vld(http://www.codeproject.com/KB/applications/visualleakdetector.aspx)가 있습니다.






'개발/경험' 카테고리의 다른 글

iceScrum - Features  (0) 2011.08.29
Tortoise SVN으로 게임 데이타 패치 만들기  (2) 2011.08.12
자료형은 byte로  (0) 2011.02.27
Doxygen 한글 문제  (0) 2010.12.20
Memory Leak 찾아내기  (0) 2009.10.16
자바 애플릿으로 툴을!!  (0) 2009.09.27
2009.10.14 13:19
제가 밥 안먹고 맨날 달달한 사탕이나 물고 있던 시절에.. 엄마가 무심코 내뱉은 한마디.. (아니.. 한이 서렸을지도.. )

"너도 니같이 밥 안먹는 아들 낳아서 고생 좀 해봐라.!!!"


.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.



낳았다. ㅠ_ㅜ 하도 밥을 안먹어서 평균보다 1KG정도 차이난다. 우리 엄마도 나를 볼기짝 때려서 입에 깔때기 물리고 먹여버리고 싶었을까 ㅠ_ㅜ....

'가족 - 집 - 자동차' 카테고리의 다른 글

안중근 의사님과 어머니의 편지  (0) 2014.02.14
공기 엔진 자동차  (1) 2011.09.25
회사에서 집까지..  (0) 2011.09.16
집에서 회사까지..  (0) 2011.09.14
컬러 인테리어  (0) 2011.08.25
엄마의 한마디..  (0) 2009.10.14
2009.09.30 09:28

9월의 마지막 날

주저리 2009.09.30 09:28
업무적으로 이야기하면 3/4분기의 마지막 날이군요. 파트원들의 업무 진척도도 마무리 해야 하고, 일정도 정리해야 하는 ... 그런 날이네요.

가을과 여름이 만나는 이런 날씨를 좀 더 즐기고 싶은데, 요즘은 의자에서 일어나려면 언제나 용기가 필요하네요.

최근에는 개발 프로세스에 큰 변화가 있었습니다.

이전에는 일에 대한 각 담당자를 정해서 그들이 그들의 업무를 설정하도록 했었습니다. 이렇게 하면 동기부여와 일정 진행에 불만이 없을 거라 생각했죠. 하지만 생각보다 많은 변수들이 발생했고, 이를 수정할 필요가 있다고 생각되었습니다.

내가 전체 개발 프로세스에 대해서 필요한 사항을 시기별로 결정하고, 그 내용을 각 작업자에게 분배하도록 했습니다. 사실 이런 방식이 개인적으로는 자신의 업무 영역을 제한하기 때문에 상당히 비효율적이라고 생각하는데 파트원들은 그렇게 생각을 하지는 않는 것 같더군요. 자신의 일이 제한되어 있어서 딱 그것만 하고 싶은 것 같습니다.

이 방법도 문제점이 발생할 수 있겠죠. 일단 그들이 원한다면 한번 시행해 주는 것도 나쁘지 않을 것 같습니다. 하지만 딱 정해진, 제가 생각하기에 저사람이 이정도는 할 수 있다라고 생각한 그걸 그대로 이루었을 때 전 그사람에게 평균점을 줘야 할까요? 아니면 스페셜을 줘야 할까요?

개인적으로는 그냥 평균점 혹은 좀 더 중책을 하는 사람은 평균보다 약간 높은 점수를 줄겁니다. 평소 그사람이 해왔던 내용을 기준으로 작업 내용을 정하니까요. 만약 그 사람이 그 일을 뛰어넘어 올라온다면 아마 S를 줄 수 있겠죠. 남들과 비슷한 수준의 업무량을 무난히 해결해 간다면 매년 연봉은 그냥 평균으로 올라갈 것을 그사람도 분명 알고 있을까요? 몇년 지내본 결과.. 일은 그대로지만 연봉은 언제난 남들보다 더 높이 받고 싶어했습니다. 자신이 자신이 속한 무리에서 언제나 특별하길 원했죠. 자신이 하는 아무리 작은 작업도 특별하다고 느끼고 있기 때문이기도 했습니다. 가끔은 그들을 이끌어 가는데 제게는 플러스 요인으로 작용하기도 합니다만 ... ^^

다들 자신의 틀을 좀 더 벗어나서 높이 올라오려는 맘이 있을지 궁금합니다. 아무리 이끌어 주려고 해도 그들이 자신의 틀을 깰 생각이 없으면 아무 소용이 없더군요. 연봉을 30%정도 올려도 봤고, 직책도 올려줘 봤지만 .. 어차피 끈기없는 사람은 안되더군요. 중간에 쉽게 쉽게 포기를 해버렸습니다. 어떤 이는 마치 자신이 없으면 프로젝트가 안 될 것 같은 거만함만을 가지고 있기도 합니다.

인력을 관리한다는 것은 내가 코딩을 하는 것과는 많이 다른 그런 것이라는 것을 매년 느끼네요.

지금 있는 인원들은 좀 더 자신의 목표를 높게 잡았으면 하는... 9월 마지막 날의 넋두리 였습니다.

어쨌든 모두 행복한 하루하루가 되었으면 하는 바램입니다. 여러분들도... ^^

'주저리' 카테고리의 다른 글

포카리스웨트 분말 득!!  (0) 2011.06.22
바른 생활  (0) 2009.11.18
9월의 마지막 날  (0) 2009.09.30
코드를 공유한다는 것!  (0) 2009.09.29
일정을 잘 지키는 것  (0) 2009.08.28
미친거 아냐...  (0) 2009.08.27
2009.09.29 01:26

은 쉽지 않은 일이다.

코드 관리를 위한 SVN같은 프로그램들이 아무리 merge 기능이 지원해줘도 누군가 자신이 만든 코드를 다른 사람이 만져서 버그가 발생하면 누구나 짜증나기 마련이니까. 게다가 그 뒷 수습에 들어가는 시간은 짜증을 배로 증가 시키기도 한다.

그래서 사전에 이런 상황을 막기위해 여러가지 시도도 해보았다.

자신이 관리하는 코드에 주석을 달아서 현재 관리자를 표시하고 수정할 내용이 있다면 그에게 이야기할 것!
자신이 작성한 코드에서 중요하게 공유해야할 코드 흐름 혹은 사용 방법들...  이 내용을 게시물에 등록하고 키워드를 등록해서 검색하기 쉽도록 하고, 수정사항이 발생하면 갱신할 것!!

하지만 모두 다 현재는 사용되지 않고 있다.

수시로 갱신되는 코드들을 이렇게 관리하는게 결코 쉬운일은 아니었다. 게시물을 올리더라도 얼마간의 시간이 지나면 쓴 것 자체를 기억못하는 경우도 생기고, 도대체 어디까지 기록해야 하는지도 명문화하지 못해서 힘들기도 하다.

어떤 경우는 다른 사람의 코드를 쓸 때 그 클래스가 초기 목적에는 맞았고 제작자가 테스트시 버그가 없었지만 다른 사람이 사용할 경우 버그가 발생하는 경우도 있어서 불편하다고 한다. 그래서 되물었다.

"처음에 유닛테스트를 하자고 했는데 각자 잘 지키고 있나요?"

질문한 사람 조차도 대답하지 못하고 있었다. 사실 현실적으로 그리 쉬운 문제가 아니라는 것을 나도 잘 알기에 안지켜 지는 것을 보면서도 강요하지는 못했다.

다음 프로젝트가 되면 이런 실패들을 잘 정리해서 과정 자체도 좀 더 발전할 수 있도록 해야겠지.

여러개의 프로젝트를 지금까지 진행해 왔지만 이런 것 조차도 결코 쉽지가 않다. 지금까지도 그래왔듯이 다음 프로젝트의 맴버들도 지금과는 다른 사람들일테니...

인재가 답일지.. 인재가 문제일지.. 가끔은 운에 맞겨지는 느낌이다. 최근에는 실력보다 부디 인간성 좋고 끈기 있는 사람이 들어오길 매일 매일 기도한다.

'주저리' 카테고리의 다른 글

바른 생활  (0) 2009.11.18
9월의 마지막 날  (0) 2009.09.30
코드를 공유한다는 것!  (0) 2009.09.29
일정을 잘 지키는 것  (0) 2009.08.28
미친거 아냐...  (0) 2009.08.27
컴퓨터 게임은 하이테크놀로지를 필요로 하는 엔터테이먼트이다.  (0) 2009.08.27
2009.09.27 02:45
기존 프로젝트의 게임 운영툴은 MFC로 만들었었다. 이때가 아마 2004년도 무렵이지 않을까 생각된다. 이때는 게임 서버와 운영툴 관련 모든 작업을 나 혼자서 만들었을 때라 사실 미래를 생각할 틈이라고는 눈꼽만큼도 없을 정도로 바빴다. 이번에는 인원도 충원되고 해서 운영툴을 자바 애플릿으로 만들어 볼까 생각중이다. 아래와 같은 결론을 내리고 결정을 하게 되었다.

일단 게임 운영툴은 운영자들의 다양한 요구를 충족시켜주는 것을 최우선 목표로 잡았다. 기존 툴은 이를 충분히 반영하지 못해서 운영상의 중요한 요구들을 쉽게 들어주지 못했기 때문이다. 이는 곧 운영팀과 개발팀의 신뢰 저하로 이어졌으며 이로 인해 효율적이지 못한 운영을 하게 되었기 때문이다.

그외에 인터페이스의 쉬운 추가 및 변경(적고 보니 위 이야기에 포함되는 내요이기도 하지만.. 중요한 내용이므로 다시 적어본다.), 전달의 용이함 (해외에도 전달되는데 잦은 변경이 일어날 경우 버젼관리와 패치 처리가 생각보다 번거로웠다.), 자료의 다양한 확장성을 우선적으로 잡았다.

일단 MFC로 일반 윈도우 어플리케이션으로 제작하는 방법은 역시 이에 알맞지 않았다. 

그래서 웹으로 눈을 돌려봤는데 이전에 버그 트래킹 시스템을 .net환경에서 c#을 이용해 보았다. 그런데 이는 사용자들이 더 불편함을 느꼈는데 이유는 아래와 같았다.

 - 웹페이지는 유저와 데이터를 동적으로 주고 받기에 상당히 불편한 인터페이스다. 태생 자체가 정보의 전달을 목적으로 만들어진 것이라 기본 웹 사이트 구축 만으로는 원하는 기능을 모두 채울 수는 없었다.

 - 이벤트에 대한 반응이 일반 어플리케이션과 비교해서 상당히 느렸다. 역시 서버와 온갖 정보를 주고 받아야 하므로 이도 쉽게 풀 수 없는 문제였다.

 - 그리고 UI가 이쁘지 않았다. XP 혹은 VISTA형태의 UI에 익순한 사람들이 단순한 버튼과 텍스트박스의 연속으로 된 이런 웹 페이지에 호감을 느끼는 것 자체가 넌센스였을지 모르겠다.

그래서 좀 더 다른 방법을 생각해 보기로 했다. 일단 바로 생각나는 것은 FLASH의 Action Script를 활용한 것, 그리고 MFC or WTL 로 돌아가는 것, 그리고 c# 혹은 VB을 .net환경에서 이용하도 좀 더 위의 조건을 충족하도록 만족시키는 것이었다.

하지만 기술적으로 약간 미숙한 부분도 있었으며, MFC나 ATL로 돌아가서 이를 유지하기 위해 많은 시간을 들이는 것은 더욱 싫었다.

그때 다른 사람이 멋진 의견을 하나 던졌다.

"자바 애플릿은 어떨까요?"

헉...  왜 내가 진작 생각하지 못했을까.

당장 이클립스와 JDK 최신 버젼을 설치하고 이틀만에 JDBC와 Socket, 그리고 swing을 이용한 UI 디자인 테스트를 비롯한 모든 테스트를 진행했다. 결과는 만족 ^^!! 그 후 전체적인 구조를 설계하고 대략적인 기간을 생각해 보았다. 얼추 개발 기간도 큰 무리는 없을 듯 생각되었다. 비록 현재 자바를 다룰 수 있는 인원은 나뿐이지만 다른 인원들도 금세 따라올 거라 예상된다. 뭐.. 앞으로 수도 없이 겪어야 하는 버그 수정과 인원들에 대한 교육은 힘겹긴 하겠지만, 앞으로 얻을 소득에 비하면 그리 큰 문제는 아니다.

그리고 자바 애플릿 개발에 대한 유용한 몇가지를 생각해 봤다.

일단 운영툴의 많은 기능을 여러 개발자들에게 서로 충돌없고 유연하게 분배할 수 있다는 것이다. 예를들어 MFC에서는 하나의 프로젝트에 탭을 분리하여 작업을 해야 할 것 아닌가.(당신이 만약 계정관리, 캐릭터 데이터 관리, 로그 분석, 통계 처리에 대한 각각의 어플리케이션을 운영자들에게 배포할 마음을 가지고 있다면 말리진 않겠지만 ...) 여러명이 작업을 분산할 경우 리소스 파일 (.rc와 resource.h)의 공유와 새로운 파일 혹은 속성 변경시 프로젝트 파일에 대한 lock 시도에서 많은 충돌과 개발자간의 코드 공유에 일정 시간을 소비하게 될 것이다. 애플릿으로 각 기능을 분리하여 별도의 애플릿으로 제작하되 로그인 세션 유지만 정해진 규칙만 지키면 된다.

SWING의 UI디자인은 지겨워진 윈도우의 UI에 비해 현재 각 팀원들에게 신선한 충격을 줄 수 있을 것이다. 사실 알고보면 겉모습만의 변화지만 많은 이들이 이런 것들에 흥미를 느끼기도 하니까 ~ 웹에서도 (실제로는 자바지만 최종 사용자들이 이런 걸 구별하려고 하지는 않으니..) 이런 다양한 기능들을 사용할 수 있다는걸 알게 된다면 분명 새로운 즐거움으로 다가올 것이다.

'개발/경험' 카테고리의 다른 글

iceScrum - Features  (0) 2011.08.29
Tortoise SVN으로 게임 데이타 패치 만들기  (2) 2011.08.12
자료형은 byte로  (0) 2011.02.27
Doxygen 한글 문제  (0) 2010.12.20
Memory Leak 찾아내기  (0) 2009.10.16
자바 애플릿으로 툴을!!  (0) 2009.09.27
2009.08.28 10:30

일정을 세울 때 언제나 여유를 가진다. 큼직한 작업을 시작하기 전에는 약 이삼일 정도의 시간을 두고 기획서 검토, 개발 흐름 정리, 타 파트와의 해당 작업 진행 사항 체크 등등등...

하지만 예전에 비해서 많은 시간을 공들여 일정을 세워도 일정은 언제나 딱 맞게 지켜지지 않는다.

어떤 사람들은 정말 작업 시간의 두배 정도를 잡아두고 일찍 끝나면 자랑을 하기도 하지만 그 역시도 어긋난 것이 아닌가. (이미 끝내놓고 노는 것 보다야 좀 좋긴 하네.. --; 혹은 그마저도 못 지키던가..)

자신의 역량을 정확히 파악하지 못해서 대충 잡아놓고 맞으면 좋고 안맞으면 뭐.. 좀 추가하고..

하지만 게임 개발이라는게 자기 혼자 운영하는 개발 회사가 아닌 이상 다른 동료들의 일정도 항상 생각해야 한다. 자신의 일정을 대충 잡아 버리면 다른 파트에서 언제나 지켜지지 않는 그런 일정을 보고 한숨을 쉴 뿐이다. 

원래 세운 계획의 10 ~ 15% 정도의 차이에서 일정을 지켜 간다면 아마 정말 잘 지킨 것 같다. 1년 작업이라면 인간이 하는 일이니 한달에서 두달 정도의 차이는 있을 수 있다. 물론 잘 정해서 최대한으로 맞추려고 노력하지 않는다면 문제겠지만... 100%로 맞추는건 사실 불가능에 가까울 것이고 아마 경영진도 그정도를 바라진 않을 것 같다.

매일 매일 새로운 시도를 하고 팀원들과 호흡하며 이런 저런 노력을 하지만... "일정을 잘 지키는 것"은 누구에게나 어려운 숙제일 것 같다.

자.. 빨리 트리거 마무리하고 다시 엔진 리펙토링 하자. 그래픽 파트가 클라이언트 다시 보고 싶다고 우는 소리가 들린다. ^^a


'주저리' 카테고리의 다른 글

바른 생활  (0) 2009.11.18
9월의 마지막 날  (0) 2009.09.30
코드를 공유한다는 것!  (0) 2009.09.29
일정을 잘 지키는 것  (0) 2009.08.28
미친거 아냐...  (0) 2009.08.27
컴퓨터 게임은 하이테크놀로지를 필요로 하는 엔터테이먼트이다.  (0) 2009.08.27
일정
2009.08.27 22:21

미친거 아냐...

주저리 2009.08.27 22:21

난 회사의 사장도 아니고 주인도 아니고 그냥 월급장이야.

하지만 가끔은 이런 사람들 보면 미친거 같아.

왜 일을 그냥 평범하게 하면서 월급이 적다고 불평만 하는거야. 당신도 미친 듯이 일해서 남들에게 자랑할 만한 결과물을 보여봐!! 그게 자신이 없다면 그냥 찌그러져서 주는 월급 받고 그냥 살던가.

일을 안준다고 불평하는거야?

누군가가 당신에게 일을 줘야만 일을 하는 거라면 당신이 당신 동료과의 차이점이 뭔데? 실력이 좋아서 남이 1주일 걸릴 걸 하루만에 끝내고 ... 나머지를 놀고 있다면 그 사람보다 뛰어난 게 뭐지??

만약 당신이 뭔가를 더 원한다면 당신의 상사던 동료든 갈궈서라도 당신의 새로운 일을 찾아. 그리고 남들보다 두배 세배 더 좋고 많은 결과물을 만들어 내라고.

그럼 당신의 그 최악의 성격까지도 사랑스러워 질거니까!!

그리고 당신의 그 꼴도 보기 싫은 상사를 눈앞에서 발로 차버릴 수도 있을 거라고!!

'주저리' 카테고리의 다른 글

바른 생활  (0) 2009.11.18
9월의 마지막 날  (0) 2009.09.30
코드를 공유한다는 것!  (0) 2009.09.29
일정을 잘 지키는 것  (0) 2009.08.28
미친거 아냐...  (0) 2009.08.27
컴퓨터 게임은 하이테크놀로지를 필요로 하는 엔터테이먼트이다.  (0) 2009.08.27
2009.08.27 13:25

라고 공감을 하나요? ^^

이곳에는 제 생각을 여과 없이 담아 보고 싶습니다. 다른 사람들 눈치 보지 않고, 맘 속에 있는 그것 그대로를 말입니다.

사실 이런 내용들이 남들과의 공감을 이끌기 위함이라기 보다는 제 머리 속의 것들을 정리하고 싶은 목적입니다.

그리고 조금은(^^) 다른 분들은 어떻게 생각하는지도 알고 싶습니다.

웹 개발에서 게임 개발이라는 분야로 넘어 온지 이제 10년이 되어가고 있습니다. 한 회사에서 제 청춘과 게임 개발에 대한 열정을 다했는데 이제 잠시 돌아볼 시점이 되지 않았나 싶네요. 주변은 어떻게 변했는지도 보고 싶고요.


그리고 앞으로도 즐겁고 매일매일이 행복한 게임 개발을 위한 하루가 되었으면 합니다.

여러분들도 그러시길 바라면서 ^^



'주저리' 카테고리의 다른 글

바른 생활  (0) 2009.11.18
9월의 마지막 날  (0) 2009.09.30
코드를 공유한다는 것!  (0) 2009.09.29
일정을 잘 지키는 것  (0) 2009.08.28
미친거 아냐...  (0) 2009.08.27
컴퓨터 게임은 하이테크놀로지를 필요로 하는 엔터테이먼트이다.  (0) 2009.08.27
개요, 시작